Subject: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 6 Mar 2012 09:00:43 +0800

Dear colleagues,

This message starts a two-week WGLC on the draft
draft-ietf-appsawg-about-uri-scheme-03.txt. 

Please help to review this draft.  If you support publication, please state as
much on the list.  If you are opposed to publication, please state
that on the list as well.  It is more/only helpful if you give your reasons for
your position as part of your statement.  

Pls send your comments to [email-masked] or [email-masked] or editors. 

The WGLC will end on March 20, 2012 at 1:00 UTC.

Best regards,
Jiankang Yao(as a co-chair of APPSAWG)

---

From: "t.petch" <[email-masked]>
Date: Tue, 20 Mar 2012 10:41:27 +0100

The I-D points out the impossibility of specifying how to handle the many
different tokens that  a browser may encounte and then goes on to tell us what
Opera does.

I am uncomfortable with a Standards Track document telling us about the
behaviour of one and only one product, with, the text being in the body of the
I-D, an implication that this text has Normative status (earlier versions of
this I-D also included Mozilla Firefox).

Nothing wrong with the web browser mentioned but I think that having just the
one example is inappropriate; other examples should be mentioned (and they all
could be in an Informative appendix).

I note too that this has been 'quiet long-lasting'; an interesting combination.

Tom Petch

----- Original Message -----
From: "Jiankang YAO" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 06, 2012 2:00 AM
Subject: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt

> Pls send your comments to [email-masked] or
[email-masked] or editors.
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Mar 2012 23:58:57 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiankang YAO
> Sent: Monday, March 05, 2012 5:01 PM
> To: [email-masked]
> Cc: [email-masked]
> This message starts a two-week WGLC on the draft draft-ietf-appsawg-
> about-uri-scheme-03.txt.
> 
> Please help to review this draft.  If you support publication, please
> state as much on the list.  If you are opposed to publication, please
> state that on the list as well.  It is more/only helpful if you give
> your reasons for your position as part of your statement.
> 

This is coming in a bit late, and apologies for that (and shame on me for complaining about other people who come in late on my drafts!), but the points should be easily resolved.

[Relatively] Major Issues:

In Section 4.2, you talk about the Intended Usage field of the registration being "what they must be resolved to, if resolvable."  Why would you allow registration of something that can't resolve to something?

Section 4.2 also talks about referencing a document that allows one to create an "interoperable" implementation of the "about" URI being registered.  I know we talked about this in the WG, but a new reader might well ask "interoperable with what?"  You might want to answer that question before the IESG asks it.  :-)

[Relatively] Minor Issues:
I'm not so sure about use of RFC2119 language in the IANA Considerations section.  You're not really describing interoperability requirements with IANA.

[Absolutely] Nits:
All of these are either reductions of overly-wordy text or fixes to minor grammar nits, or both.

Section 1:

	OLD
		scheme, that is currently widely used by Web browsers and some other

	NEW
		scheme, which is currently widely used by Web browsers and some other

Also, I'm not sure that "Web" is a proper noun, so it should probably be "web".

	OLD
		The concept of "about" URIs has been formed at the times when the
		applications did not have the "friendly" user interface, in order to
		provide an access to the aforementioned resources via typing the URIs
		in the address bar.  Even though the user interface of current
		Internet-targeted software effectively rescinds the issue, and
		"about" URIs can be thought to be a rudimentary phenomenon, they are
		still supported by a variety of Web browsers and are not going to cease
		to exist.

		As use of "about" URIs has been quiet long-lasting, and the URIs have
		been used without any proper registration and absent any proper
		specification, the necessity for the latter two actions arises.
		The purpose of this document is to provide a stable specification for
		"about" URI scheme and correspondingly register it in the IANA
		registry.  Along, several provisions for handling the "about" URIs
		Are set.

	NEW
		The concept of "about" URIs formed when applications did not have a
		"friendly" user interface, to enable access to the aforementioned
		resources by typing URIs into an address bar or similar feature.
		They have however become commonplace in modern user applications.

		Given their current ubiquity, their absence from the URI scheme
		registry and lack of a defining document is conspicuous.  Therefore,
		this document provides a stable specification for the "about"
		URI scheme and registers it with IANA.

Section 2.2:

	OLD

		Generally speaking, the resource a particular "about" URI resolves to
		is denoted by <about-token> part of the URI, and <about-query>
		specifies additional information concerning its handling and/or the
		information that should be returned in the resource a URI is resolved
		to.

		However, it is impossible to specify binding between all the possible
		tokens and the semantics of "about" URIs that would contain such
		tokens, which this document does not attempt to do.  Therefore, any
		application resolving an "about" URI MAY choose the resource it is
		resolved to at its own discretion, with the exception of those
		defined below as 'special-purpose "about" URIs'.  They MAY use
		internal redirection to accomplish this (for instance, Opera
		redirects all "about" URIs except "about:blank" to its internal
		"opera" URIs).

	NEW

		Generally speaking, the resource to which a particular "about" URI resolves
		is denoted by <about-token> part of the URI, and <about-query>
		specifies additional information concerning its handling and/or the
		information that should be returned in the resource to which the URI
		resolves.

		However, it is impossible to specify a binding between all the possible
		tokens and the semantics of "about" URIs that would contain such
		tokens.  Therefore, the resource referenced by the URI is
		application-specific, except for those listed below as 'special-purpose
		"about" URIs'.  Applications MAY use internal redirection to accomplish
		this (for instance, the Opera web browser redirects all "about" URIs except
		"about:blank" to its internal "opera" URIs).

Section 2.2.1:

	OLD

		A small, though expandable, range of <about-token>s are reserved for
		special purposes ("special-purpose tokens").

	NEW

		A small, though extensible, range of <about-token>s is reserved for
		Special purposes ("special-purpose tokens").

	OLD

		Additional special-purpose tokens can be defined by registering an
		registry created in Section 4.2. Special-purpose "about" URIs are
		intended to be uncommon, and new ones should be defined only when
		there is a need to strongly connect a particular <about-token> with a
		particular function in all applications.

	NEW

		Additional special-purpose tokens can be defined by updating the
		registry created in Section 4.2. Special-purpose "about" URIs are
		intended to be uncommon, and new ones only need to be defined when
		there is a need to strongly connect a particular <about-token> with a
		particular function in all applications.

Section 3:

	OLD

		Generic security considerations for URIs are discussed in Section 7
		of RFC 3986 [RFC3986].  However, many of those provisions hardly
		apply to "about" URI scheme, as they are mainly scoped to schemes
		used in the Internet, not internally.

		"about" URIs may sometimes refer to a sensitive information, such as
		user passwords stored in a cache, or parameter that, if changed, may
		affect user's data.  The application should therefore ensure that
		user's data is in the safety, and no threats are imposed by "about"
		URIs.

	NEW

		Generic security considerations for URIs are discussed in Section 7
		of RFC 3986 [RFC3986].  However, few of those provisions
		apply to the "about" URI scheme, as they are mainly scoped to schemes
		used in the Internet, not internally.

		"about" URIs can sometimes refer to a sensitive information, such as
		user passwords stored in a cache, or parameters that, if changed, could
		affect user's data.  The application therefore needs to ensure that
		the user's data is secured, and no threats are imposed by "about"
		URIs.

Section 4.2:

	OLD

		o Intended usage:  A short description of how "about" URIs with the
		  registered token must be handled; especially, what they must be
		  resolved to, if resolvable.

		o Handling query component:  It should be mentioned whether there are
		  some provisions on handling query components in the "about" URIs
		  with the registered token.

		o Contact/Change controller:  An individual or an organization which
		  (1) should be contacted for more details, and (2) is authorized to
		  change the registration.

		o Specification.  This provides documentation at a level that could
		  be used to create a compliant, interoperable implementation of the
		  registered "about" URI.  The reference to a full specification MUST
		  be provided here, and there should be a reasonable expectation that
		  the documentation will remain available.  IANA will consult with
		  the IESG or its specified delegate if there is doubt about whether
		  the specification is adequate for the purpose.

		The following is a template for "blank" token:

	NEW
		o Intended usage:  A short description of how "about" URIs with the
		  registered token must be handled; especially, to what resource
		  they are to resolve.

		o Handling query component:  Describe any requirements for handling
	        query components in "about" URIs that contain the registered
		  token.

		o Contact/Change controller:  An individual or an organization that
		  (1) should be contacted for more details, and (2) is authorized to
		  change the registration.

		o Specification.  A permanent reference to a specification that can
		  be used to create a compliant, interoperable implementation of the
		  registered "about" URI.  IANA will consult with
		  the IESG or its specified delegate if there is doubt about whether
		  the specification is adequate for this purpose.

		The following is a template for the "blank" token:

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 Mar 2012 22:34:57 -0400

> I'm not so sure about use of RFC2119 language in the IANA Considerations
> section.  You're not really describing interoperability requirements with IANA.

I'm sure.  And it's my text -- this is one that Mykyta doesn't like.
The three MUSTs in there are not directed at IANA, but at people
writing new registrations.  They tell those people what their
registrations have to look like, and I wanted to use MUST to stress
that even though this is an FCFS policy, there are requirements
nonetheless.

> All of these are either reductions of overly-wordy text or fixes to minor grammar nits, or both.
...
>                provide an access to the aforementioned resources via typing the URIs
...
>                resources by typing URIs into an address bar or similar feature.
...

Yeah, good luck with that.  I tried to convince Mykyta to tone the
rhetoric down in there, and he declined... and I didn't see it as
important enough to fight about.

Barry

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Mar 2012 07:44:40 +0100

> that even though this is an FCFS policy, there are requirements

I'm with Murray here. This is something RFC 2119 keywords are not for.

Best regards, Julian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 21 Mar 2012 07:45:16 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Tuesday, March 20, 2012 7:35 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt
> 
> > I'm not so sure about use of RFC2119 language in the IANA
> > Considerations section.  You're not really describing
> > interoperability requirements with IANA.
> 

I think my point is that the IANA Considerations section spells out the rules for a new registry when the registry is created, especially when conformant with RFC5226.  Everything in such a section is essentially a MUST, because you're either filling out or defining a template and the registry's initial entries.  I can't imagine a "This field SHOULD/MAY contain..." anywhere in an IANA Considerations section, except maybe optional fields, but they're typically labeled as such in the first place.

In the case of this draft, the second MUST in particular seems unnecessary.  If the first one were changed to "has to" or similar, I have some doubts that IANA would start slipping in invalid tokens.  And for the third one, they're already pretty good at preferring (or even requiring?) permanent document links without this document having to say so.

I don't feel particularly strongly about this.  It just seems unnecessary.

> important enough to fight about.

Well, parts of it are grammatically incorrect and the RFC Editor will have to fix them anyway, but a lot of my nits attempted to simplify needlessly wordy or overly formal paragraphs.  I hope the authors will give them a second look.

-MSK

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 21 Mar 2012 15:22:55 +0200

21 марта 2012 г. 1:58 пользователь Murray S. Kucherawy
<[email-masked]>написал:

> > From: [email-masked] [mailto:
> [email-masked]] On Behalf Of Jiankang YAO
> This is coming in a bit late, and apologies for that (and shame on me for
> complaining about other people who come in late on my drafts!), but the
> points should be easily resolved.
>
> In Section 4.2, you talk about the Intended Usage field of the
> registration being "what they must be resolved to, if resolvable."  Why
> would you allow registration of something that can't resolve to something?
>

This is what we had from the previous version of the document when we had
resolvable/unresolvable distinction.  We've dropped it, so I think I'll
drop these words as well.  (Actually, this document was originally written
"for" HTML5 'about' URIs, which are unresolvable, but later we reached an
agreement on not introducing this in the document.)

>
> Section 4.2 also talks about referencing a document that allows one to
> create an "interoperable" implementation of the "about" URI being
> registered.  I know we talked about this in the WG, but a new reader might
> well ask "interoperable with what?"  You might want to answer that question
> before the IESG asks it.  :-)
>

I believe this isn't an important matter.  "interoperable" is quite usual
term, and I don't think we need to detalize this.

> section.  You're not really describing interoperability requirements with

I'll reply to a later message.

> Also, I'm not sure that "Web" is a proper noun, so it should probably be

Fixed.

>                URI scheme and registers it with IANA.

Quite agree with this text.

>                "about:blank" to its internal "opera" URIs).

Changed.

>                particular function in all applications.

Taken into account.

>                The following is a template for the "blank" token:

Accepted.

Thanks you for your assistance.

Mykyta Yevstifeyev

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 21 Mar 2012 15:26:17 +0200

21 марта 2012 г. 9:45 пользователь Murray S. Kucherawy
<[email-masked]>написал:

> > From: [email-masked] [mailto:
> [email-masked]] On Behalf Of Barry Leiba
> > Subject: Re: [apps-discuss] WGLC:
> draft-ietf-appsawg-about-uri-scheme-03.txt
> >
> I think my point is that the IANA Considerations section spells out the
> rules for a new registry when the registry is created, especially when
> conformant with RFC5226.  Everything in such a section is essentially a
> MUST, because you're either filling out or defining a template and the
> registry's initial entries.  I can't imagine a "This field SHOULD/MAY
> contain..." anywhere in an IANA Considerations section, except maybe
> optional fields, but they're typically labeled as such in the first place.
>
> In the case of this draft, the second MUST in particular seems
> unnecessary.  If the first one were changed to "has to" or similar, I have
> some doubts that IANA would start slipping in invalid tokens.  And for the
> third one, they're already pretty good at preferring (or even requiring?)
> permanent document links without this document having to say so.
>

I see we've agreed on dropping 2119 language here.  I'll change this to
non-normaitve equivalents.

> Well, parts of it are grammatically incorrect and the RFC Editor will have
> to fix them anyway, but a lot of my nits attempted to simplify needlessly
> wordy or overly formal paragraphs.  I hope the authors will give them a
> second look.
>

Again thanks to Murray for these nits.

Mykyta Yevstifeyev

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Mar 2012 10:19:33 -0400

I said...
>> that even though this is an FCFS policy, there are requirements

Julian says...
> I'm with Murray here. This is something RFC 2119 keywords are not for.

OK... and given the conversations that Pete and I have had recently
(we're both in favour of less unnecessary all-caps 2119 stuff), I
think a change is appropriate.  Let's lower-case (or remove) those
three "MUST"s (and there are three others that are already in lower
case, which is fine).

Section 4.2:
OLD
   The registry entries consist of 3 fields: Special-Purpose Token,
   Description and Reference.  The Special-Purpose Token field MUST
   conform to <about-token> production defined in Section 2.1.
NEW
   The registry entries consist of 3 fields: Special-Purpose Token,
   Description and Reference.  The Special-Purpose Token field
   conforms to the <about-token> production defined in Section 2.1.

OLD
   The registration procedures for this registry are "First Come First
   Served", described in RFC 5226 [RFC5226], with supporting
   documentation meeting the requirements below.  The registrant of the
   token MUST provide the following registration template, which will be
   made available on IANA web site:
NEW
   The registration procedures for this registry are "First Come First
   Served", described in RFC 5226 [RFC5226], with supporting
   documentation meeting the requirements below.  The registrant of the
   token must provide the following registration template, which will be
   made available on IANA web site:

OLD
   o Specification.  This provides documentation at a level that could
     be used to create a compliant, interoperable implementation of the
     registered "about" URI.  The reference to a full specification MUST
     be provided here, and there should be a reasonable expectation that
     the documentation will remain available.
NEW
   o Specification.  This provides documentation at a level that could
     be used to create a compliant, interoperable implementation of the
     registered "about" URI.  The reference to a full specification must
     be provided here, and there should be a reasonable expectation that
     the documentation will remain available.

Mykyta, please note those changes, address Murray's other comments,
and push out a new rev of the draft (email TXT and XML to
[email-masked] and CC [email-masked] to get
permission).

Barry

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Mar 2012 15:25:41 +0100

> three "MUST"s (and there are three others that are already in lower

+1, except that I would replace "must" by "needs to" (otherwise somebody 
else will point out that RFC2119 doesn't require the keywords to be in 
uppercase).

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 22 Mar 2012 20:51:53 +0200

So all,

I've emailed the new version with issues raised in WGLC considered to
[email-masked], Secretariat and cc'ed Pete as sponsoring AD.  I'm
waiting for some reaction from the Secretariat.

Mykyta Yevstifeyev

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 24 Mar 2012 13:29:43 +0100

On 06/03/2012 01:00, Jiankang YAO wrote:
> Pls send your comments [email-masked]  [email-masked]  or editors.
>
Hi,
Sorry, I've missed the WGLC. A couple of nits:

1. Introduction

s/quiet/quite

    specification, the necessity for the the latter two actions arises.
    are set.

4.2. A Registry for Registered Tokens

    IANA is asked to set up a new registry entitled "'about' URI Special
    Purpose Tokens" following the guidelines below.

    The registry entries consist of 3 fields: Special-Purpose Token,
    Description and Reference.

Below you also have "Contact/Change Controller", so 4 or 5 fields, 
depending how you count.

---

From: Larry Masinter <[email-masked]>
Date: Wed, 28 Mar 2012 01:42:19 -0700

rfc4395 and http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-04 both use 2119 keywords in the same way:

   Within this document, the key words MUST, MAY, SHOULD, REQUIRED,
   RECOMMENDED, and so forth are used within the general meanings
   established in [RFC2119], within the context that they are
   requirements on future registration specifications.

i.e., just in the sense that "about:" is establishing a second-level registration.

Is a FCFS policy by itself consistent with having MUST and SHOULD requirements on the registration? 

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Wed, 28 Mar 2012 04:54:25 -0400

On Wednesday, March 28, 2012, Larry Masinter <[email-masked]> wrote:
> rfc4395 and http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-04both use 2119
> keywords in the same way:

Nevertheless, we've come to the decision to change it to lower-case words
here.

> Is a FCFS policy by itself consistent with having MUST and SHOULD
requirements
> on the registration?

Sure; we're starting with FCFS (as in BCP 26), and then adding
requirements.  Perfectly fine.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Mar 2012 10:58:40 +0200

On 28/03/2012 10:54, Barry Leiba wrote:
> On Wednesday, March 28, 2012, Larry Masinter <[email-masked] 
> <mailto:[email-masked]>> wrote:
  [...]
> requirements.  Perfectly fine.
I think the question is who is going to enforce RFC 2119 language.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 28 Mar 2012 05:04:29 -0400

> I think the question is who is going to enforce RFC 2119 language.

Well, IANA's going to make sure the registration request contains the
required information.  And that's all we have there.

b

---

From: Ned Freed <[email-masked]>
Date: Wed, 28 Mar 2012 16:01:06 -0700 (PDT)

> I'm with Murray here. This is something RFC 2119 keywords are not for.

The about: URI registration procedure can do whatever it wants to - the usage
of RFC 2119 compliance language there is pretty limited and I don't think it
will make a significant difference either way.

That said ...

<rant>

The notion that this usage was inappropriate is overly pedantic nonsense.
Nothing more and nothing less.

Both RFC 1123 and RFC 2119 agree: Compliance keywords are used in the context
of compliance with a specification. There doesn't have to be a protocol,
format, or anything else involved.

Now, RFC 2119 does go further and talk about when compliance language needs to
be used in order to insure interoperability. But nowhere does it say, or even
imply, that interoperability considerations are the sole justification for
using these terms.

And even if it did, so what? Are you seriously going to try and argue that
failure to follow these or any other registration mandates can under no
circumstances cause interoperability problems? No, I didn't think so.

Besides, we've been using compliance language in registration procedures
for a long time. The media types registration procedure is one example; other
messages have pointed out various other ones.

And as for Alexey's question about who enforces these rules, in the case of
registration procedures that would be the registration process itself. The
media types registration form won't accept invalid values for many fields.  And
I refuse to accept violations of the MUSTs and push back on violations of the
SHOULDs in media type registrations on a regular basis.

And even if this weren't true, I again have to ask: So what? I haven't noticed
the Internet Protocol Police arresting any of the MIME scoff-MUSTs out there.

In fact I'd have to say that in the case of a registraton process, these
keywords are actually carry more weight than they do in protocol
specifications.  Fail to meet a MUST in a registration document, your
registration is rejected. Whereas in protocol implementations often as not they
are seen as, well, suggestions.

And finally, I thought making registrations processes easier for people to
use was something of an overarching goal here. To that end, don't you
think highlighting the actual requirements in these document so they stand
out at least a little might be somewhat helpful to the casual reader?

</rant>

				Ned