Re: Last Call: <draft-holsten-about-uri-scheme-06.txt> (The 'about' URI scheme) to Proposed Standard
John C Klensin <klensin@jck.com> Fri, 17 June 2011 16:50 UTC
Return-Path: <klensin@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADB511E81A7 for <ietf@ietfa.amsl.com>; Fri, 17 Jun 2011 09:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.657
X-Spam-Level:
X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tidXljkmuvQE for <ietf@ietfa.amsl.com>; Fri, 17 Jun 2011 09:50:01 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5269A11E80E2 for <ietf@ietf.org>; Fri, 17 Jun 2011 09:50:01 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QXcF4-000AiT-UJ; Fri, 17 Jun 2011 12:49:59 -0400
Date: Fri, 17 Jun 2011 12:49:58 -0400
From: John C Klensin <klensin@jck.com>
To: IETF Discussion <ietf@ietf.org>
Subject: Re: Last Call: <draft-holsten-about-uri-scheme-06.txt> (The 'about' URI scheme) to Proposed Standard
Message-ID: <0EC26EB10287E2A20769C9CC@PST.JCK.COM>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: draft-holsten-about-uri-scheme@tools.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jun 2011 16:50:03 -0000
Given the controversies, I decided I needed to do a careful reading of this document. While I respect and appreciate what the authors are trying to do, as a would-be standards track specification, it is pretty troubling. It is troubling editorially as well. I think all or most of the specific issues have been identified by others, so let me try a different perspective and a 10 km view. (1) There seems to be consensus that registering this URI as a mechanism for accessing built-in functionality and configuration information such as application information, preferences, or settings. (Text derived from the Abstract with "configuration information", which may mean more to some readers, added and "easter eggs" dropped. Dropping "easter eggs" reflects other comments on the list and my opinion that it isn't worth the trouble to define. Recommendation: Let's get it registered. (2) The document itself reflects an attempt to define the undefinable. There is no cross-implementation interoperability issue here; if anything, the document should me more clear that it would be stupid to assume it. The document, nonetheless, tries to define what is done with some specific URIs in some places and then has to turn around and indicate that they may be used in entirely different ways in other places and should not be relied upon. In the process, it skips back and forth between being descriptive and being normative, with some definitions becoming circular in the process. That just isn't a good combination and some of it actually looks pretty silly. "about:blank" is particularly troubling in that regard because the text essentially says that it is reserved except where it isn't. Recommendation: Choose one of the following and redo the document to match. Option 1: Do this descriptively. Strip it down as much as possible, more or less repeating the suggested language above. If the Wikipedia article really contains a better and more authoritative list of applications than the I-D text (and especially if it is being kept up to date), just reference it as a place where a non-normative listing and examples can be found. The effect of doing this at all would be to reserve the name for purposes internal to particular implementations of particular applications, not unlike RFC 1918 addresses. Option 2: Really try to make this normative wrt some subset of URI values. In this approach, stop the extremely confusing circling around. Indicate explicitly that "about" URIs have been used enough and in enough different circumstances that no application should assume that an "about" URI, if encountered, is actually its own and that due caution needs to be taken about non-conforming implementations. Then explicitly reserve, not only "about:blank", but everything the authors think is worth listing in Examples _and_ create an IANA registry for more of them. But, even the second approach is taken, the document should be really clear that all that the use of "about:" really tells someone is that it is application-specific and that a particular implementation of a particular application may do whatever it pleases with them. ---- Smaller issues: (i) Section 6, Normalization, sadly really doesn't belong here unless the authors can show that everyone interprets "about:" according to those rules. Otherwise, it would be better to say that the URI is interpreted in an implementation-specific way and that implementations would be well-advised to conform to normal URI syntax rules unless there is a strong reason not to. (ii) IMO, Section 7, Security Considerations, should be modified to include an explicit statement that, since these things are intended for convenience use within an implementation of an application, passing them between systems (embedded in files or otherwise) is very risky behavior and should generally be discouraged except, possibly, in documentation contexts. (iii) I know this is partially a problem with the general URI and IRI definitions, but I'm supposed to know something about i18n and encoding and Section 4, Encoding Considerations, is almost incomprehensible to me. It isn't quite clear what "this syntax" refers to (if it is "the 'about' variation on the general URI syntax described in Section 3", say that). Then I think it says I may use any Unicode character, but I have to %-encode it, but, if it isn't unreserved, it shouldn't be %-encoded. If there isn't a clearer way to say that, I suggest that almost anyone trying to figure out how to use this URI from the spec is in trouble. And, fwiw, I've seen "about:" URIs that use non-ASCII strings without %-encoding. Whether one calls those IRIs, URIs, or pumpkins, I see absolutely no reason why an implementation that knows it is UTF-8 capable (and clean) should require that an xRI that is intended only for internal use should require %-encoding of UTF-8 strings... especially since, in practice, these URIs are often expected to be direct user input. best, john
- Re: Last Call: <draft-holsten-about-uri-scheme-06… SM
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Ted Hardie
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Mykyta Yevstifeyev
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Julian Reschke
- Re: Last Call: <draft-holsten-about-uri-scheme-06… t.petch
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Ted Hardie
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Julian Reschke
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Ted Hardie
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Julian Reschke
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Julian Reschke
- Last Call: <draft-holsten-about-uri-scheme-06.txt… Boris Zbarsky
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Ted Hardie
- Re: Last Call: <draft-holsten-about-uri-scheme-06… SM
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Mykyta Yevstifeyev
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Julian Reschke
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Mykyta Yevstifeyev
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Andrew Sullivan
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Joel M. Halpern
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Lachlan Hunt
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Julian Reschke
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Lachlan Hunt
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Julian Reschke
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Boris Zbarsky
- Re: Last Call: <draft-holsten-about-uri-scheme-06… John C Klensin
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Mykyta Yevstifeyev
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Mykyta Yevstifeyev
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Barry Leiba
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Mykyta Yevstifeyev
- RE: Last Call: <draft-holsten-about-uri-scheme-06… Murray S. Kucherawy
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Julian Reschke
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Julian Reschke
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Eliot Lear
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Lachlan Hunt
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Michael Richardson
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Barry Leiba
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Boris Zbarsky
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Boris Zbarsky
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Julian Reschke
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Boris Zbarsky
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Mykyta Yevstifeyev
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Lachlan Hunt
- Re: Last Call: <draft-holsten-about-uri-scheme-06… Mykyta Yevstifeyev