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

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 15 November 2011 02:56 UTC

Return-Path: <alexey.melnikov@isode.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 1A0BE1F0D61 for <apps-discuss@ietfa.amsl.com>; Mon, 14 Nov 2011 18:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.399
X-Spam-Level:
X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 J-Q1cxt8+HLw for <apps-discuss@ietfa.amsl.com>; Mon, 14 Nov 2011 18:56:11 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6D71F0D60 for <apps-discuss@ietf.org>; Mon, 14 Nov 2011 18:56:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1321325770; d=isode.com; s=selector; i=@isode.com; bh=7qZ2UiXn2ZBuhwGtkshXUwOFT7WUk/pk+91PssYwRmE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=aooJQhpaDZXJHv32U5XU9wbjNPOrs6wuigH9AyPJd15J3yd0mLV25euZAwkL0qUjRy2W0I Q9hyP4e5J3JHrYH2S2Spm1R5kZS32+Q0fIdaaNrP9mrfnPs5hLJ0VBH648HVeJuCmGkChI uxMmavQj9QYXUkGW5UVQLzOlgGkh1Bk=;
Received: from [192.168.174.158] (60-251-183-229.HINET-IP.hinet.net [60.251.183.229]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TsHUxgAFEFco@rufus.isode.com>; Tue, 15 Nov 2011 02:56:08 +0000
Message-ID: <4EC1D4C1.7080406@isode.com>
Date: Tue, 15 Nov 2011 02:56:01 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: "\"Mykyta Yevstifeyev (М. Євстіфеєв)\"" <evnikita2@gmail.com>
References: <4EC16815.80501@gmail.com>
In-Reply-To: <4EC16815.80501@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Apps-discuss list <apps-discuss@ietf.org>
Subject: [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: Tue, 15 Nov 2011 02:56:12 -0000

Hi Mykyta,

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?

    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.



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)


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.


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?

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


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.

    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.

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.



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