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

"Mykyta Yevstifeyev (М. Євстіфеєв)" <> Mon, 21 November 2011 11:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F069621F8BBB for <>; Mon, 21 Nov 2011 03:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.012
X-Spam-Status: No, score=-3.012 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M+aW6YPdWBXX for <>; Mon, 21 Nov 2011 03:46:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A9BBC21F84A9 for <>; Mon, 21 Nov 2011 03:46:02 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so7389504bkb.31 for <>; Mon, 21 Nov 2011 03:46:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hcG/P+g4WtmYh4kptu6Z3/iC/7B+aWfTebVVU6n71GA=; b=rVy98Y4APnQx4gxZq993Bn8mKTV+hkz+TgOhBqa/VfnKEQPQI/m99CpexLcVXcVyFK VboS3MlgSy+Lnk21YGMsLhMRdibcD60p2Z7SlTV8DvrGMHZSuOxUmt/HyS6dQi2XhdyO lmNAO51nZ2MVmXBZveGZPyBSU1CYGGiggEoFg=
Received: by with SMTP id jd9mr14303601bkc.21.1321875961741; Mon, 21 Nov 2011 03:46:01 -0800 (PST)
Received: from [] ([]) by with ESMTPS id x14sm7052587bkf.10.2011. (version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 03:46:01 -0800 (PST)
Message-ID: <>
Date: Mon, 21 Nov 2011 13:46:52 +0200
From: "\"Mykyta Yevstifeyev (М. Євстіфеєв )\"" <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Alexey Melnikov <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Apps-discuss list <>
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Nov 2011 11:46:04 -0000

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.


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