[apps-discuss] 'about' URI scheme draft and AppsAWG

[Mykyta Yevstifeyev <[e-mail]>]

Dear all,

Today AppsAWG chairs announced that based on discussions on IETF meeting 
the EG is going to adopt draft-holsten-about-uri-scheme as WG item.  
Previously I volunteered to become an additional author, and both 
current authors, AD and doc. shepherd agreed on this.  I suppose the 
authors didn't change their mind, and WG won't object to this.

Now I'd like to present my view on what basic changes should be made 
prior to publishing the draft as AppsAWG document.  First, the semantics 
should be amended as follows.  I propose to mention that

(1) broadly speaking, the meaning if the particular 'about' URI is 
denoted by the token in its <hier-part>, but

(2) any application which handles the URI is free to resolve it to any 
resource; ie. handle it solely (well, almost solely; see bullet 3) 
internally.

(3) A special range of 'about' URI tokens is defined to be 
"special-purpose",
(3a) they are to be registered with IANA and
(3b) must be used only and only for the defined reason.

The corresponding IANA registry (see below) should be lightweight 
enough, as the "special-purpose token" should be used as the last resort 
only.  (I understand that many won't agree with me, but) the 
Specification Required may be sufficient for such purpose.  FCFS isn't 
appropriate because the MUST requirement is a very string regulation and 
some formal review is necessary; the discussion mailing list is also an 
option, but Spec. Required alone should also be OK (see justification 
below).  Next,

(4) the registration of the token should have clear regulations 
regarding the use of the corresponding 'about' URI, eg. "The 'about' URI 
with "legacy-compat" token MUST only be used in HTML <more specifically, 
etc.>".  For the purpose of the documentation clarity, the Specification 
Required policy is an ideal way, but for the purpose of being 
lightweight Expert Review is more appropriate.  I'll let the WG to 
decide, but please consider that Specification Required is what I 
*personally* prefer.

(5) the categorization regarding resolvable/unresolvable should be 
dropped.  I suppose (2) fully covers handling of those URIs which can be 
defined to be "unresolvable" (I mean the situation when an app resolves 
eg. <about:legacy-compat> to the web page saying this URI may not be 
resolved elsewhere).

(6) The categorization regarding reserved/unreserved should be dropped 
in favor of (3).

(7) Encoding considerations are defined to be application-specific;
(7a) 'about' IRIs should be disallowed.

(8) The requirement for mandatory support of "about:blank" is 
unreasonable and should be dropped.

I suppose AppsAWG participants will express their opinion with respect 
to these issues prior to publishing AppsAWG draft.

Thanks,
Mykyta Yevstifeyev