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

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

20.11.2011 10:21, Alexey Melnikov wrote:
> On 16/11/2011 19:28, "Mykyta Yevstifeyev (М. Євстіфеєв)" wrote:
>> 15.11.2011 4:56, Alexey Melnikov wrote:
>>> Hi Mykyta,
>> Hello Alexey.
> Hi,
>
>  [...]
>>>    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>.

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

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

>
> This also avoids passive voice.

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

>>>    SPU MAY be defined to be unresolvable.  This means that an
>>>    application MUST NOT resolve it in some particular resource.
> Did you mean "context" instead of "resource" here?

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

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

>
> The fact that some URIs might be unresolvable in some contexts is kind 
> of self evident. But maybe it is just me.
>>> 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.
>> 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.

>>>    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.
>> This is for what I place SHOULD.  And this *is* common behavior.
>>> 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.
>> We have no evidence of use.  That is the reason.
> 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

>
>
>