Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme

[Barry Leiba <[e-mail]>]

Responding to Alexey's comments and Mykyta's response to them, and
adding my own review:

I find the Introduction section to be pontificating, and I suggest
avoiding that.  I'm talking about the reference to "Easter Eggs"
and the rambling about the friendliness of about URIs compared
with point-and-click interfaces.  I'm not going to pick on that
further, but just think about taking some of that out.

In the ABNF in 2.1:

- By defining about-token as "segment", you're allowing these:

  about:
  about:?banana
  about::::

  Are you sure you don't want to define it as "segment-nz", or
  even "segment-nz-nc".

- I think the definition of "about-query" is correct.

With reference to Alexey's comment about "redirect", if you hadn't
ignored my review comments before, when you sent the wrong version
for review, you'd have seen that I had comments on that as well.
It's just wrong, and it needs to be fixed.

In fact, let me take this opportunity to repeat the essence of my
ignored comments.  Please do not ignore them this time.

One general comment:
Throughout the document, there are non-normative "may" and "should".
People -- WG participants, last-call commenters, and ADs -- often push
on those and look to have them changed to words that don't look so
much like 2119 keywords, despite their being in lower case.  We
usually change "may" to "might" or "can", depending upon context.  The
"should" cases are harder, but do try to rephrase things to avoid
using "should".  I hate this silly exercise, but it does save trouble
with the nitpickers later.

Also, I suggest changing the single quote to a double quote, so
"about" instead of 'about' (and I think the RFC Editor will do this
anyway, if you don't).  You can do this in the XML by switching the
quote marks:
OLD: <section anchor="s-purp" title="Special-Purpose 'about' URIs">
NEW: <section anchor="s-purp" title='Special-Purpose "about" URIs'>

[...] I also don't like
how the "redirect" part is put, because I think it might lead some to
think that "about" URIs might often redirect to other resources on the
Internet (imagine, say, "about:me?barryleiba" redirecting to my web
site, Facebook page, or some such).  How about this?:

OLD
   Therefore any application MAY resolve an 'about' URI to any
   desired resource, and MAY redirect such URIs.  Several exceptions are
   defined, though; they are named "special-purpose 'about' URIs" and
   MUST be handled in strict accordance with provisions set in Section
   2.2.1.

NEW
  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).


Section 4.1:
OLD
   IANA is asked to update the register the 'about' URI scheme
   using the following template, per [RFC4395]:

It's useful to be very specific about the registry you want.

NEW
  IANA is asked to register the "about" URI scheme in the
  "URI Schemes" registry defined in section 5.4 of RFC 4395
  [RFC4395]:


I don't think it's appropriate to specify the general IETF
discussion list as the contact point (Author/Change controller).
Put something "real" in there.


Section 4.2:
OLD
   IANA is asked to set up a new registry entitled "'about'
   URIs SPTs" following the guidelines below.

In English, we don't use plurals like this.  We say "tool box", not
"tools box", for example.  We should also expand the "SPT"
abreviation in the registry name.

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


Now, back to the new stuff.  I think the whole section on
special-purpose stuff (2.2.1) becomes convoluted by being full of
"SPT" and "SPU".  It's excessive.  Let me try to re-work the whole
section here.  The "unresolvable" paragraph makes no sense to me,
and I see no use case for it.  Unless there's been a documented
need for it, we should not have it here.  I've eliminated that
paragraph in my re-write.  I know you said something about HTML5,
but you need to be more specific before we can add this.
Remember: as a document editor, you may not just add things as you
please.  We need consensus to add them.

NEW
--------------------------

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

A special-purpose URI is an 'about' URI that has a special-purpose
token as its <about-token> part.  Such URIs MUST be handled in
strict accordance with the rules defined in the special-purpose
token registry (see Section 4.2).  The registered entry MAY also
define additional provisions for handling of the <about-query>
part.  If no such provisions are defined, the query part has no
meaning, and MUST be ignored.

This document defines one special-purpose token: "blank".
The URI "about:blank" MUST resolve to a blank page, as seen by
the end user. There is no additional handling of the query
component in "about:blank" URIs.

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.

--------------------------

Section 2.2.2

The first paragraph is pointless; please remove it.

The second paragraph is full of problems, some of which Alexey
commented on:

OLD
 An unrecognized 'about' URIs as a URI that may not be recognized by
 an application.  (Correspondingly, such categorization is per-
 application, not per-fact.)  An unrecognized 'about' URI SHOULD be
 handled as the <about:blank> URI, although other behavior is
 possible.

For the first sentence, I think you mean, "An unrecognized URI is
a URI that is not recognized by a particular application."
Again, that's kind of pointless, but OK for now.  The sentence in
parentheses is simply not comprehensible.  I *think* you mean what
I've captured in my rewrite of the first sentence, by adding the
word "particular".  So let's remove that.

But the main point is this: how is *interoperability* affected by
the SHOULD in the third sentence?  Not at all.  In any case, I
can't see any justification for something as strong as SHOULD.
I suggest that this whole thing be made non-normative, this way:

NEW
When an application does not recognize a particular "about" URI,
common practice is to handle it in the same way as "about:blank",
though other handling is possible.


Now for the meaty issue: the registration policy for the new
registry in Section 4.2.  As I suggested in my ignored message:

I don't think the registry needs "Specification Required", which
implies expert review; I think that's overkill, and that there's no
need for any expert review to be done.  I think we should use First
Come First Served, and specify the level of documentation we want
available.  Something like this (adjust as needed):

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:
...
    Specification.  REQUIRED field.  This provides documentation
    at a level that could be used to create a compliant, interoperable
    implementation of the registered "about" URI.  The full
    specification SHOULD be included here, but it MAY be a
    reference to a document published elsewhere, if there is 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.

This provides for a sort of "expert review" only to determine whether
the documentation is suitable, and does not have an expert at the gate
to block registrations.  I think this is a perfect example of a
registry where we'd rather have things registered and documented than
not, so encouraging that with minimal hassle and minimal risk for
rejection is best.

This mechanism is what had consensus in the room in Taipei.  We
can discuss it on the mailing list now.

Barry