Subject: [apps-discuss] draft-ietf-appsawg-about-uri-scheme

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" <[email-masked]>
Date: Mon, 14 Nov 2011 21:12:21 +0200

Hello,

 From minutes:

> 09:05 draft-ietf-appsawg-about-uri-scheme (chairs)
>
> Room consensus for registry to be FCFS with minimal doc via template.

That is what the WG reached at the previous meeting and what is not 
there currently is in the doc.  Before it became a WG item, the authors, 
ADs and me did have a discussion on this point, but there was no 
agreement - that's why it became WG item.  What I actually think is that 
FCFS should be appropriate, but there is no point of adding a registry 
entry given no specification available whereas the MUST restriction is 
imposed.  Recently Barry has sent me the following proposal: to have the 
policy FCFS but make specification reference mandatory for 
registration.  Therefore, if there is nobody who objects, I may change 
the following text in IANA Considerations:

OLD:

>     The registration policy for new entries is "Specification Required",
>     as defined in RFC 5226 [RFC5226].  Additionally, the following
>     template MUST be provided by the registrant:

NEW:

>     The registration policy for new entries is "First Come First Served",
>     as defined in RFC 5226 [RFC5226].  Additionally, the following
>     template MUST be provided by the registrant:

OLD:

>     o Published specifications:  A reference to the published
>       specification for the registered token.

NEW:

>     o Published specifications:  A reference to the stable specification
>       MUST be provided.  The specification SHALL cover what the SPU
>       with the token being registered ought to resolve to, and SHOULD
>       cover other issues related to SPU usage.

Any comments are welcome.

Mykyta Yevstifeyev

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Nov 2011 02:56:01 +0000

Hi Mykyta,

In Section 1:

    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.

Sorry, are you saying that typing about: URIs into the address bar is 
"friendly" interface?
I think I disagree. Or is "not" missing somewhere?

    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.

URIs are useful in contexts when one wants to reference a resource and
can only pass in a string. So no, about: URIs are not going to go away
and not for reasons you've mentioned. I suggest removing or rewording
this text.

2.1. URI Scheme Syntax

    The 'about' URI MUST syntactically conform to the <about-uri> rule
    below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]:

      about-uri   = "about:" about-token [ about-query ]
      about-token = segment
      about-query = "?" query
      segment     = <as specified in RFC 3986, Appendix A>
      query       = <as specified in RFC 3986, Appendix A>

    In terms of RFC 3986, <about-token> part corresponds to <hier-part>,
    and <about-query> to the query component of URI.

s/query/<query> ? (I didn't check RFC 3986)

2.2. URI Scheme Semantics

    However, it is impossible to specify binding between all the possible
    tokens and the semantics of 'about' URIs that would contain such
    tokens.  Therefore any application MAY resolve an 'about' URI to any
    desired resource, and MAY redirect such URIs.

The meaning of redirection is not defined here. Do you mean redirection 
in HTTP sense?
If yes, I think a reference to HTTP (RFC 2616) is needed.

2.2.1. Special-Purpose 'about' URIs

    A small, though expandable, range of <about-token>s are reserved for
    use in special-purpose 'about' URIs, abbreviated "SPU" (special-
    purpose URI).  Such tokens are named "special-purpose 'about' URI
    tokens", and abbreviated "SPT" (special-purpose token).

    An SPU is an 'about' URI containing one of the registered SPTs as the
<about-token> part.  An SPU MUST be handled in strict accordance with
    the rules defined for SPT contained therein.  The SPT specification
    MAY define additional provisions on handling of <about-query> part in
    the corresponding SPU; by default, it MUST be ignored for the purpose
    of handling SPU.

Where is this requirement coming from? Is this common behaviour among
existing browsers?

    SPU MAY be defined to be unresolvable.  This means that an
    application MUST NOT resolve it in some particular resource.  Such
    SPUs may be used as placeholders, or in some other way.

I fail to see utility in this. Can you maybe provide an example
of an unresolvable about URI?
(This might also affect the IANA registration section which includes
this flag in the token registration template.)

2.2.2. Unrecognized 'about' URIs

    Naturally, an application will support only a particular range of
    'about' URIs; also, some applications will support 'about' URIs that
    are not supported by an other one.  This document specifies the rules
    for handling unrecognized 'about' URIs.

    An unrecognized 'about' URIs as a URI that may not be recognized by
    an application.  (Correspondingly, such categorization is per-
    application, not per-fact.)

I don't understand the comment in () and I don't think it adds any value
anyway.

    An unrecognized 'about' URI SHOULD be
    handled as the <about:blank> URI, although other behavior is
    possible.

Is there a reason why this is a SHOULD? This seems rather strong here.
I am thinking that displaying an error about unrecognized token would be
another reasonable choice. In fact it would be my preferred choice.

2.3. Encoding Considerations

    'about' URIs are subject to encoding rules defined in RFC 3986
    [RFC3986].  'about' IRIs [RFC3987] are not permitted.

The last quoted sentence: why?
If an about URI is used to edit configuration, I can see some Unicode being
passed in the query part of such URI.

4.2. A Registry for SPTs

This was already discussed in the face to face meeting and I will 
comment on this separately. (Yes, I think this is too restrictive.)

---

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" <[email-masked]>
Date: Wed, 16 Nov 2011 21:28:03 +0200

> Hi Mykyta,

Hello Alexey.

> I think I disagree. Or is "not" missing somewhere?

Address bar was present in console browsers even, that were far from 
friendly interface, and that is precisely what I have in the doc: "did 
not have the "friendly" user interface"

> and not for reasons you've mentioned. I suggest removing or rewording

I have "still supported" here, and this is an answer to you sentence 2.  
With respect to the first question, this is just what I wanted to say in 
the first paragraph you cited.  So I don't see a need for any text 
change here.

> s/query/<query> ? (I didn't check RFC 3986)

<query> doesn't include "?" - so query component.

> The meaning of redirection is not defined here. Do you mean 
> redirection in HTTP sense?

Yes, redirection needs clarification.  That is not HTTP sense here - I 
meant they can be replaced by some other URIs and than resolved to what 
these URIs refer to, and the latter of them needn't necessarily be 
'http' URIs.

> Where is this requirement coming from? Is this common behaviour among

We still haven't had such a term as 'special-purpose about URI', and so 
we can't speak of common behavior.  IMO, taking into account the 
intended semantics of SPUs, if the meaning of query isn't defined, it 
must be ignored not to eliminate the said semantics and their utility.

> this flag in the token registration template.)

That is what HTML5 wants to define (actually, defines).  we had a 
discussion on this previously.

> I don't understand the comment in () and I don't think it adds any value

It means that 'about' URI can't be defined to be unrecognized - this all 
depends on application.

> another reasonable choice. In fact it would be my preferred choice.

This is for what I place SHOULD.  And this *is* common behavior.

> passed in the query part of such URI.

We have no evidence of use.  That is the reason.

> comment on this separately. (Yes, I think this is too restrictive.)

I'll wait for your further comment on this before replying (though my 
opinion has been stated to WG).

Mykyta Yevstifeyev

---

From: Barry Leiba <[email-masked]>
Date: Wed, 16 Nov 2011 21:23:16 -0500

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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 17 Nov 2011 05:09:41 +0100

> We have no evidence of use.  That is the reason.

Strong objection.  about: URIs are the territory of UA implementors.
They are free to do anything they like as long as it is compatible
with 3986/3987 and doesn't break <about:blank>.

For example they are free to create an equivalent of about:mozilla in
any language plus appropriate script.  They are also free to create
say about:punycode?äöü.de as a service (maybe a stupid plan, but
about: URIs and IRIs can be stupid.)

They are also free to use slashes in their about URIs, and I have no
evidence that this never happened anywhere.  With slashes you'd get
maybe "path-rootless" or similar, not only "segment-nz".

The purpose of the draft should be to get the about: URIs registered
without twisting them into something they are not.  And as user of UAs
with poor documentation which essential about: URIs exist in the UA,
e.g., about:support in newer Firefox versions, I'd really like a hint
that offering an about:about list will beat "Google it" as a manual.

-Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 20 Nov 2011 08:14:17 +0000

On 14/11/2011 19:12, "Mykyta Yevstifeyev (М. Євстіфеєв)" wrote:
> there currently is in the doc.  Before it became a WG item, the 
> authors, ADs and me did have a discussion on this point, but there was 
> no agreement - that's why it became WG item.  What I actually think is 
> that FCFS should be appropriate, but there is no point of adding a 
> registry entry given no specification available whereas the MUST 
> restriction is imposed.  Recently Barry has sent me the following 
> proposal: to have the policy FCFS but make specification reference 
> mandatory for registration.  Therefore, if there is nobody who 
> objects, I may change the following text in IANA Considerations:
>
> OLD:
>
>>       MUST be provided.
I think allowing for specifications in an email message to IANA (or 
similar) should be sufficient, as long as IANA archives a copy of the 
registration on their website.

Otherwise this looks Ok.
>> The specification SHALL cover what the SPU

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 20 Nov 2011 08:21:04 +0000

> 15.11.2011 4:56, Alexey Melnikov wrote:
Hi,

  [...]
> <query> doesn't include "?" - so query component.
You misunderstood. You have "about-token" enclosed in <>, I think you 
need <> around "query" as well.
> meant they can be replaced by some other URIs and than resolved to 
> what these URIs refer to, and the latter of them needn't necessarily 
> be 'http' URIs.
I don't know of any better reference than RFC 2616. Conceptually one URI 
is replaced with another, so even if a non HTTP URI is used, this should 
work.
> We still haven't had such a term as 'special-purpose about URI', and 
> so we can't speak of common behavior.  IMO, taking into account the 
It looks like the first part of the sentence is as a recommendation for 
new SPU designers, the second part is a recommendation for developers. 
This adds to confusion and I suggest you reword this, for example:

    The SPT specification MAY define additional provisions on handling 
of <about-query> part in
    the corresponding SPU. Unless specified otherwise, implementations 
MUST ignore the <about-query>
    part when processing SPUs.

This also avoids passive voice.
>>    application MUST NOT resolve it in some particular resource.
Did you mean "context" instead of "resource" here?
>>   Such
I think that if the document wants to talk about these, it needs to 
provide more details.

The fact that some URIs might be unresolvable in some contexts is kind 
of self evident. But maybe it is just me.
> It means that 'about' URI can't be defined to be unrecognized - this 
> all depends on application.
The first sentence quoted above already says that. Besides, I don't 
understand the meaning of "per-fact" in this context.
> We have no evidence of use.  That is the reason.
I suppose I should test browser behaviour in the 2 cases mentioned above.

---

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" <[email-masked]>
Date: Mon, 21 Nov 2011 13:31:59 +0200

20.11.2011 10:14, Alexey Melnikov wrote:
>> authors, ADs and me did have a discussion on this point, but there 
>> was no agreement - that's why it became WG item.  What I actually 
>> think is that FCFS should be appropriate, but there is no point of 
>> adding a registry entry given no specification available whereas the 
>> MUST restriction is imposed.  Recently Barry has sent me the 
>> following proposal: to have the policy FCFS but make specification 
>> reference mandatory for registration.  Therefore, if there is nobody 
>> who objects, I may change the following text in IANA Considerations:
>>
>> OLD:
>>

This can't be allowed as we need to provide a specification in terms of 
what is defined by Section 7 of RFC 2026.  Whenever the special-purpose 
URI is defined, we should ensure that it is the part of some 
standardization effort by some organization, and not me wanting to 
register "about:yevstifeyev" mandatory displaying my name (that's 
actually why I still like Specification required with DE involved, but 
must follow community consensus on this.)

Mykyta Yevstifeyev

---

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" <[email-masked]>
Date: Mon, 21 Nov 2011 13:46:52 +0200

> need <> around "query" as well.

The RFC 3986 <query> production does not include "?" delimiter but only 
the range of chars allowed in the query component while <about-query> 
stands for query itself and the delimiter.  That would be technically 
inaccurate if I mentioned <query>.

>> Yes, redirection needs clarification.  That is not HTTP sense here - 
>> I meant they can be replaced by some other URIs and than resolved to 
> I don't know of any better reference than RFC 2616. Conceptually one 
> URI is replaced with another, so even if a non HTTP URI is used, this 
> should work.

I've added the following text:

>
>    and MAY redirect such URIs, i.e. resolve it to a resource commonly
>    referred to by an other URI.

> It looks like the first part of the sentence is as a recommendation 
> for new SPU designers, the second part is a recommendation for 
> developers. This adds to confusion and I suggest you reword this, for 
> example:
>

Agreed.

> This also avoids passive voice.

What's bad of passive voice, BTW? :-)

> Did you mean "context" instead of "resource" here?

I meant "to" instead of "in" actually.

> I think that if the document wants to talk about these, it needs to 

What are such possible details?

> understand the meaning of "per-fact" in this context.

"per-fact" is meant to be predefined for some particular URI.  However, 
if you insist, I don't object to removing that sentence.

> I suppose I should test browser behaviour in the 2 cases mentioned above.

Case 1 (testing about:yevstifeyev):
FF 7.0.1: a warning and about:blank
IE8: tried to load the error page (res://ieframe.dll/navcancl.htm) but 
failed
Chrome 15: redirected to chrome://yevstifeyev and displayed an error.
Safari 3.2.1 for Win: about:blank.

Conclusion: let's remove the recognized/unrecognized section at all, and 
leave this to app designers.

Case 2: (testing about:євстіфеєв - that's my surname in Ukrainian)
FF: the same
IE: the same
Chrome: translated to chrome://xn--b1aai1cfm2ifp/ and showed an error
Safari: the same

However, that's really not the case for such testing as all 
currently-in-use 'about' RIs are URIs and not IRIs.  Conclusion: no 
change, I think (we'll be able to change this at any time, should we 
need that).

Mykyta Yevstifeyev

---

From: Barry Leiba <[email-masked]>
Date: Tue, 22 Nov 2011 22:07:37 -0500

>> You misunderstood. You have "about-token" enclosed in <>, I think you need
>> <> around "query" as well.
>
> The RFC 3986 <query> production does not include "?" delimiter but only the
> range of chars allowed in the query component while <about-query> stands for
> query itself and the delimiter.  That would be technically inaccurate if I
> mentioned <query>.

You still misunderstand what Alexey was getting at, so let me try to
explain (I misunderstood the first time as well, but I understand his
second explanation):  He's NOT talking about the ABNF.  He's talking

>   and <about-query> to the query component of URI.

He notes that you have put "<about-token>" in angle-brackets,
"<hier-part>" in angle-brackets, and "<about-query>" in
angle-brackets, but you have not done so with "query".  He suggests
that you should say, "to the <query> component of URI."

I think a better way to approach it would be to replace all the
angle-brackets with quotes, so:

NEW
   In terms of RFC 3986, the "about-token" part corresponds to "hier-part",
   and "about-query" to the query component of the URI.

(And I do not think that "query" needs to be in quotes here.)

>>> these URIs refer to, and the latter of them needn't necessarily be 'http'
>>> URIs.
>>

I had suggested text for this in my other note; what do you think of
it?  I like it (obviously):

NEW

>>> we can't speak of common behavior.  IMO, taking into account the intended
>>> semantics of SPUs, if the meaning of query isn't defined, it must be ignored
>>> not to eliminate the said semantics and their utility.
>>
>> new SPU designers, the second part is a recommendation for developers. This
>> adds to confusion and I suggest you reword this, for example:
>>
>>   The SPT specification MAY define additional provisions on handling of
>> <about-query> part in
>>   the corresponding SPU. Unless specified otherwise, implementations MUST
>> ignore the <about-query>

I provided a suggested revision of the whole section in my other note;
please consider that.  It gets rid of the "alphabet soup", which I
think makes things more confusing, and I think it reads much better.

> What are such possible details?

As I said in my other note, I agree with Alexey here: I don't think
this part is appropriate.  (1) If it's here, it needs some text
explaining and justifying it, and (2) the goal here is to keep the
document simple, just doing what's necessary to get this stuff
registered.

> "per-fact" is meant to be predefined for some particular URI.  However, if
> you insist, I don't object to removing that sentence.

"Per-fact" simply doesn't make sense in English.  That is, it's not an
idiom anyone uses, and I doubt anyone has seen it before.  While some
people might be able to make sense out of it (I think I know what you
mean, but I'm not sure), we shouldn't have to guess.

Mostly, see my other note for what I think you should do with section 2.2.2.

> leave this to app designers.

Cool.  I like that.

Barry

---

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" <[email-masked]>
Date: Mon, 28 Nov 2011 17:17:42 +0200

23.11.2011 5:07, Barry Leiba wrote:
>>>>>    The 'about' URI MUST syntactically conform to the<about-uri>  rule
>>>>>      segment     =<as specified in RFC 3986, Appendix A>
>>>>>      query       =<as specified in RFC 3986, Appendix A>
>>>>>
>>>>>    In terms of RFC 3986,<about-token>  part corresponds to<hier-part>,
>>>>>    and<about-query>  to the query component of URI.
>>>>>
>>> You misunderstood. You have "about-token" enclosed in<>, I think you need
>> The RFC 3986<query>  production does not include "?" delimiter but only the
>> range of chars allowed in the query component while<about-query>  stands for
>> mentioned<query>.
>>    In terms of RFC 3986,<about-token>  part corresponds to<hier-part>,
>>    and<about-query>  to the query component of URI.
> "<hier-part>" in angle-brackets, and"<about-query>" in
> that you should say, "to the<query>  component of URI."

And this wouldn't be right, as we have separate terms: <query> ABNF 
production and query component of URI.  I mean the latter here.

I'm following the recommendation of RFC 5234:

>     Unlike original BNF, angle brackets ("<",">") are not required.
>     However, angle brackets may be used around a rule name whenever their
>     presence facilitates in discerning the use of a rule name.

... so I think no change is needed.

>   to its internal "opera" URIs).

Agreed - so I'll change the text.

>>> ignore the<about-query>

I'll look again at your note and notify then.

> document simple, just doing what's necessary to get this stuff

Sp you propose removing this paragraph?

> mean, but I'm not sure), we shouldn't have to guess.

I've removed that sentence.

> Mostly, see my other note for what I think you should do with section 2.2.2.

I'll have a look.

>> leave this to app designers.

Thanks.  I've removed this section.

Mykyta Yevstifeyev

---

From: Barry Leiba <[email-masked]>
Date: Mon, 28 Nov 2011 12:38:54 -0500

> ... so I think no change is needed.

I think it's clearer to the reader with quotation marks than with
angle-brackets, and clarity is what's most important.  But I'm not
going to argue this further -- it's not a big deal, and if you prefer
the brackets, that's OK.

> Sp you propose removing this paragraph?

Yes, I think that's the best approach.

Barry