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

[Barry Leiba <[e-mail]>]

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

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

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


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

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

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

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

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

Barry