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

["Murray S. Kucherawy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Jiankang YAO
> Sent: Monday, March 05, 2012 5:01 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt
> 
> 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 [e-mail] or appsawg-
> [e-mail] or editors.
> 
> The WGLC will end on March 20, 2012 at 1:00 UTC.

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