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

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

23.11.2011 5:07, Barry Leiba wrote:
>>>>>    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.1. URI Scheme Syntax
>>>>
>>>> <query>  doesn't include "?" - so query component.
>>> 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
> about this sentence after it:
>
>>    In terms of RFC 3986,<about-token>  part corresponds to<hier-part>,
>>    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."

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

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.

>
> (And I do not think that "query" needs to be in quotes here.)
>
>>>> 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.
>>> 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.
> I had suggested text for this in my other note; what do you think of
> it?  I like it (obviously):
>
> 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).

Agreed - so I'll change the text.

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

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

>
>>>> That is what HTML5 wants to define (actually, defines).  we had a
>>>> discussion on this previously.
>>> I think that if the document wants to talk about these, it needs to
>>> provide more details.
>> 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.

Sp you propose removing this paragraph?

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

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.

>
>>> 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.
> Cool.  I like that.

Thanks.  I've removed this section.

Mykyta Yevstifeyev

>
> Barry
>