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

[Alexey Melnikov <[e-mail]>]

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

This also avoids passive voice.
>>    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?
>>   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.

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