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

"Mykyta Yevstifeyev (М. Євстіфеєв)" <> Wed, 16 November 2011 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8E9A1F0C6E for <>; Wed, 16 Nov 2011 11:27:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.33
X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U8BP0FyXM2PA for <>; Wed, 16 Nov 2011 11:27:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5EF371F0C60 for <>; Wed, 16 Nov 2011 11:27:17 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so1165052bkb.31 for <>; Wed, 16 Nov 2011 11:27:16 -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=C2a7de2FudHh91jLBIM7B6ieqg4DtzzJGYTnc1vPx2M=; b=F1lwzfjar+A9oZoCEg42inZvTRFXY9wsJprIuTsW8E5ptU+yLWCZIUopwSNgknJJUf eQzWHNz6up2vUdi9iYAYSww4i79VeoOXkqxAD3FiUQVEedtDU5AjVUpH8L8XsfNMA1aR dDn6qiU7Jw0Zu8eguvQlJw97rsJitRaHKQnXU=
Received: by with SMTP id gg11mr1186284bkc.67.1321471636419; Wed, 16 Nov 2011 11:27:16 -0800 (PST)
Received: from [] ([]) by with ESMTPS id j4sm3889155fae.3.2011. (version=SSLv3 cipher=OTHER); Wed, 16 Nov 2011 11:27:13 -0800 (PST)
Message-ID: <>
Date: Wed, 16 Nov 2011 21:28:03 +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: 7bit
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: Wed, 16 Nov 2011 19:27:26 -0000

15.11.2011 4:56, Alexey Melnikov wrote:
> Hi Mykyta,

Hello Alexey.

> In Section 1:
>    The concept of 'about' URIs has been formed at the times when the
>    applications did not have the "friendly" user interface, in order to
>    provide an access to the aforementioned resources via typing the URIs
>    in the address bar.
> Sorry, are you saying that typing about: URIs into the address bar is 
> "friendly" interface?
> I think I disagree. Or is "not" missing somewhere?

Address bar was present in console browsers even, that were far from 
friendly interface, and that is precisely what I have in the doc: "did 
not have the "friendly" user interface"

>    Even though the user interface of current
>    Internet-targeted software effectively rescinds the issue, and
>    'about' URIs can be thought to be a rudimentary phenomenon, they are
>    still supported by a variety of Web browsers and are not going to
>    cease to exist.
> URIs are useful in contexts when one wants to reference a resource and
> can only pass in a string. So no, about: URIs are not going to go away
> and not for reasons you've mentioned. I suggest removing or rewording
> this text.

I have "still supported" here, and this is an answer to you sentence 2.  
With respect to the first question, this is just what I wanted to say in 
the first paragraph you cited.  So I don't see a need for any text 
change here.

> 2.1. URI Scheme Syntax
>    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)

<query> doesn't include "?" - so query component.

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

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

>    SPU MAY be defined to be unresolvable.  This means that an
>    application MUST NOT resolve it in some particular resource.  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.

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

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

> 4.2. A Registry for SPTs
>    The registration policy for new entries is "Specification Required",
> This was already discussed in the face to face meeting and I will 
> comment on this separately. (Yes, I think this is too restrictive.)

I'll wait for your further comment on this before replying (though my 
opinion has been stated to WG).

Mykyta Yevstifeyev