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

["Mykyta Yevstifeyev (М. Євстіфеєв)" <[e-mail]>]

Hi Barry,

I really don't know how I managed not to notice this note - so please 
excuse me for the late response (and I was additionally busy with some 
other work).

17.11.2011 4:23, Barry Leiba wrote:
> 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.

I think I've said in Introduction what I really had to say.  As this is 
the minor issue, I don't think some change is needed.

>
> 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".

<about:> should be allowed, but colons shouldn't.  However, as there is 
no evidence of use of 'about' URIs wtth tokens containing any of 
<sub-delims>, should we define:

*( unreserved / pct-encoded )


?

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

In what exact way?

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

I'll have look at such occurrences in the doc.

>
> 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 think I agree here.

>
> [...] 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).

I've already fixed this.

>
>
> 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]:

Fixed.

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

For example?

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

Corrected.

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

Agreed on changing this.

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

I think there is consensus on removing this paragraph, which I have 
already done, bas in of my text's results.

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

I agree with such wording.  What I added is:

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

Thanks for your assistance with text, Barry!  As soon as I receive a 
response to some of my remarks, I'll upload the -01 version of the draft.

Mykyta Yevstifeyev

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