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

"Mykyta Yevstifeyev (М. Євстіфеєв)" <evnikita2@gmail.com> Mon, 28 November 2011 15:16 UTC

Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2283521F8CEE for <apps-discuss@ietfa.amsl.com>; Mon, 28 Nov 2011 07:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level:
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pTS-HWbALc6 for <apps-discuss@ietfa.amsl.com>; Mon, 28 Nov 2011 07:16:53 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3E9221F85FF for <apps-discuss@ietf.org>; Mon, 28 Nov 2011 07:16:52 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so9405753bkb.31 for <apps-discuss@ietf.org>; Mon, 28 Nov 2011 07:16:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C6HqBKkGVYQlmzmrObDUFsFif0dpBOoerpy5qGg5bIM=; b=s32f0ljf8lsqwUP3O8uPEbhahNkpuGMfDnaz5Vqx2XTRZCZWv0EdlmkIZDkkgY6jAx qSpVZhNRjkGbOzEUMOubANITW2/fJlpYgnVTj1k04s3GR8+iYsBAedOHjG/RKy+Zu2aC H45aw/RT7MWYvuH+kANRQ+XMamQTSoJafzEn8=
Received: by 10.205.130.1 with SMTP id hk1mr45390742bkc.68.1322493411713; Mon, 28 Nov 2011 07:16:51 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id hy13sm30263531bkc.0.2011.11.28.07.16.48 (version=SSLv3 cipher=OTHER); Mon, 28 Nov 2011 07:16:49 -0800 (PST)
Message-ID: <4ED3A616.5030600@gmail.com>
Date: Mon, 28 Nov 2011 17:17:42 +0200
From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
References: <4EC16815.80501@gmail.com> <4EC1D4C1.7080406@isode.com> <4EC40EC3.9080304@gmail.com> <4EC8B870.7070105@isode.com> <4ECA3A2C.1010606@gmail.com> <CAC4RtVBDoQj3j9xO4uZZuX-AmLkkwHMFd6y5sVVaj5KqDxcaUQ@mail.gmail.com>
In-Reply-To: <CAC4RtVBDoQj3j9xO4uZZuX-AmLkkwHMFd6y5sVVaj5KqDxcaUQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps-discuss list <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Nov 2011 15:16:54 -0000

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
>