Re: [apps-discuss] apps-team review of draft-holsten-about-uri-scheme-06
Mykyta Yevstifeyev <evnikita2@gmail.com> Wed, 15 June 2011 15:24 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 838C421F849F; Wed, 15 Jun 2011 08:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level:
X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1]
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 f4uAHzqLyrAp; Wed, 15 Jun 2011 08:24:02 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 655E721F8493; Wed, 15 Jun 2011 08:23:59 -0700 (PDT)
Received: by fxm15 with SMTP id 15so565897fxm.31 for <multiple recipients>; Wed, 15 Jun 2011 08:23:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZZmwJ/ktzzzR3063P7pQViUholgyEuGU7r6QURRbk6E=; b=bCELpv2PpHdyCNWXuHwDI8GARX/XM6r3mCHK2u29twC/0yqsL52IG97QWJKoQWhTpR bUdvElOw1BnZQi3pqdydHBSb7QAiQkOIqnUrHjJ114+vXFUrt4kAOoAeXn61b1ZcBNMs Ltp+SIDhICRJAKOHvwO4b+jbeLomMOpLIfTok=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=wXbNJ3AfYdgcMm+WdfX2C1RYv4FCBkXnRkDFd75nzFOV4WPvJ9558lGrHmoAuudpXG rp4W90+ttbamHf6pLzT4c6xQWCkdhNNcKJpi/jqTcFXMCM4roy6K49oN4LgHqqRcOznv 9Tr+/T7E65in1DrY/gSaf2bo9pMKrsFStl3dk=
Received: by 10.223.68.193 with SMTP id w1mr771281fai.42.1308151438466; Wed, 15 Jun 2011 08:23:58 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id l26sm281789fah.14.2011.06.15.08.23.55 (version=SSLv3 cipher=OTHER); Wed, 15 Jun 2011 08:23:56 -0700 (PDT)
Message-ID: <4DF8CEB9.9030108@gmail.com>
Date: Wed, 15 Jun 2011 18:24:41 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
References: <4D4FD50E.2020503@it.aoyama.ac.jp> <4D83B681.60906@isode.com>
In-Reply-To: <4D83B681.60906@isode.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "uri-review@ietf.org" <uri-review@ietf.org>, draft-holsten-about-uri-scheme@tools.ietf.org, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, IESG <iesg@ietf.org>
Subject: Re: [apps-discuss] apps-team review of draft-holsten-about-uri-scheme-06
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: Wed, 15 Jun 2011 15:24:07 -0000
18.03.2011 21:46, Alexey Melnikov wrote: > Hi Martin, > As authors didn't respond to your comments and I need to pass on > shepherding of this document to Peter, so I will quickly respond to > clarify where I stand on your comments (as the shepherding AD): Hello all, The authors of draft-holsten-about-uri-scheme allowed me to help them with the draft. The -07 version is almost ready; it is believed to incorporate comments from Martin above. Let me inform what was changed with regard to each of these points. > > Martin J. Dürst wrote: > >> I have been selected as the Applications Area Review Team reviewer for >> this draft (for background on apps-review, please see >> http://www.apps.ietf.org/content/applications-area-review-team). >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> >> Document: draft-holsten-about-uri-scheme-06 >> Title: The 'about' URI scheme >> Reviewer: Martin J. Dürst >> Review Date: February 7, 2011 >> >> >> Summary: This draft is not ready for publication, but because it is >> short, the problems identified below could be fixed soon. >> >> This draft defines the about: URI scheme, a scheme that has been used >> internally, informally by browsers since ages. It's good to see this >> defined and registered finally, but there are some problems that need >> to be fixed. >> >> >> Major Issues: >> >> - Section 5.1: "Other specification MAY reserve "about" URIs.": How >> is this done? And done in a way that gives implementers a chance to >> know about it? Surely if specifications are involved, a very >> lightweight version of IANA registry/process should not be too heavy. >> For my own taste, even a Wikipedia page might do the job, but just >> leaving this open looks like a bad idea. If additions are thought to >> be very infrequent, "updates to this specification" might also do the >> job. > > I think pretty much everybody (including GenArt, Ted Hardie and > myself) spotted this issue. Currently, the registry for 'about' URI tokens is intended to be created. The proposed text is: > 9.2. IANA Registry for Reserved 'about' URIs Tokens > > IANA is asked to create and maintain the registry called "Reserved > 'about' URIs Tokens" following the guidelines below. > > The registry provides a listing of registered reserved 'about' URI > tokens. The reserved 'about' URI token refers to the string used in > the <about-token> part of reserved 'about' URIs, with the syntax > described in Section 2 for this rule. The entries in the registry > MUST refer only to those values that are used in reserved 'about' > URIs, as described in Section 5.1. > > The registration procedures for this registry are 'First Come First > Served', described in RFC 5226 [RFC5226]. The registrant of such > token SHALL also provide the following registration template, that > SHALL be available on IANA web site: > > Reserved 'about' URI Token. REQUIRED field. Desired 'about' URI > token, compliant to the syntax described in Section 2 of this > document for the <about-token> rule > > Intended Usage. REQUIRED field. A short description of intended > usage of 'about' URI with such token > > Resolvable 'about' URI. REQUIRED field. Should be "yes" if > resolvable or "no" if unresolvable, per Section 5.2 of this > document > > Specification. OPTIONAL field. References to the document(s), if > any, that described the registered 'about' URI token > > Assignment Notes. OPTIONAL field. Any additional information > about the assignment > > Contact/Change Controller. REQUIRED field. A person or an > organization, authorized to change this registration, that should > > be contacted for further information on the registered 'about' > URI,with their contact points > > 9.2.1. Initial Contents > > The registry initially contains the following registration: > > 'about' URI token: blank > > Intended usage: The "about:blank" URI returns the blank page > > Resolvable 'about' URI: Yes > > Specification: RFC XXXX (this document - note to RFC Editor) > > Author/Change Controller: W3C <web-human@w3.org> > >> - 6. Normalization: This is confused. There are NO standard URI >> normalization rules, just various choices, in RFC 3986. And the >> choice of normalization rule is NOT a per-scheme choice, it's a >> per-usage choice, where usage for XML namespaces differs widely from >> usage for some protocol-based resolutions, and that again differs >> widely from what spiders and robots do. As an example, when used as >> an XML namespace URI, "about:blank" and "about:blan%6B" identify >> different namespaces. The text should make it excruciatingly clear >> that the normalization rules given there apply ONLY to (browser >> built-in) resolution of about URIs. Also, the phrase "Due to the >> structure of the "about" URI, some normalizations do not apply, >> specifically ..." is inappropriate given the examples following, and >> unnecessary. > > Right. This was considered. The current Section 7 (the renumbered Section 6) reads: > 7. Normalization > > 'about' URIs use the following URI normalization rules of [RFC3986]: > Simple String Comparison, Case Normalization, and Percent-Encoding > Normalization. For example, "about:blank", "about:blan%6B" and > "about:blan%6b" are equivalent, though the percent-encoded forms are > discouraged. > > Note that these normalization rules apply only to the case of > application built-in resolution of 'about' URIs, i.e. "about:blan%6B" > and "about:blank" SHALL be resolved in the same way. Other cases of > these URIs usage would require other normalization rules Some words concerning http://www.ietf.org/mail-archive/web/ietf/current/msg66862.html are also planned to be added, I think. >> Minor Issues: >> >> - The split of about: URIs into three kinds (reserved, unreserved, >> and unrecognized) is highly confusing. It looks as if two binary >> distinctions are conflated: a) The distinction between reserved and >> unreserved, which is a distinction from a specification point. b) The >> distinction between recognized and unrecognized, which is a >> distinction from an implementation (resolution) point. There's >> nothing to rule out reserved but unrecognized about: URIs in the >> future (with only about:blank being standardized at the moment, and >> unrecognized about: URIs defaulting to about:blank, there's currently >> no such case). > > Agreed. I think this is considered in the following paragraph added in Section 5: > The division of 'about' URIs into the reservation and resolution > categories is per-fact while the recognition per-application. > Therefore, while an 'about' URI may be classified as, for example, > reserved and resolvable, it may be not be recognized by all > applications. > >> - The abstract describes the about: scheme. It should explicitly >> contain the wording "defines ... the about: scheme", because that's >> the most important thing done with this document. That will also make >> the Abstract more different from the Introduction; currently the read > > Ok. Current abstract is: > Abstract > > This document specifies the 'about' URI scheme, that may be used by > the applications for almost any desired purpose, such as providing > access to application information, settings, preferences, etc. This > URI scheme has been used by many web browsers for quite a long time > informally, i. e. without being documented; this document is to > remove such uncertainty and give this scheme an official > specification. > >> - The abstract and the text mention "easter eggs". There are large >> parts of the world where Easter isn't known, and nor are Easter eggs >> (in the general sense of fancifully colored eggs). On top of this, >> the use of the term "easter egg" in the document is a very >> specialized hacker jargon use. Proposal: Remove from abstract, add >> explanation in text. > > Possibly. I wouldn't worry too much about this particular issue: I > hope RFC Editor can provide a good advice on this. The reference to http://en.wikipedia.org/wiki/Easter_egg_%28media%29 was added to clarify this. > >> - End of first paragraph of Section 4: "then only those octets that >> do not correspond to characters in the unreserved set [RFC3986] >> SHOULD be percent-encoded." This can very easily be misunderstood. >> The writer seems to want to apply the SHOULD to 'only', but readers >> will apply it to 'percent-encoded', meaning that an implementation >> might be okay even if it didn't percent-encode characters outside the >> unreserved set. The best thing to do here is to not make this >> normative language (because RFC 3986 already defines what's allowed >> and what not). The authors seems to be worried that some people might >> apply percent-escaping to a-z and such, but this is not something to >> worry about in practice. > > I actually found similar text in other RFCs. The sentence was changed to: > those octets that correspond to characters in the unreserved set > [RFC3986] should noy be percent-encoded. > >> - Section 5 starts defining various kinds of "about" URIs. It should >> start by first saying that there are three different kinds of "about" >> URIs, to make the reader's job easier (but see above). Now it is: > 5. Resolving 'about' URIs > > All 'about' URIs are categorized in three ways: > > o Reservation. [ . . . ] >> >> - Section 5.1.1 contains a lone sentence fragment 'i.e. >> "about:blank".', which seems to be unnecessary. Corrected. >> >> - 5.4. Examples is inconsistent with final punctuation. Corrected as well. >> >> - I seem to remember that the change controller for standards track >> stuff is the IESG. But I may be wrong. > > Yes. After some internal discussions it was decided to remain W3C change controller; yet, they will still need IESG approval to make changes to registration. As soon as some other minor issues are considered, I think -07 will be published. At least, at the end of June, I hope. Mykyta Yevstifeyev > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss
- [apps-discuss] apps-team review of draft-holsten-… Martin J. Dürst
- Re: [apps-discuss] apps-team review of draft-hols… Alexey Melnikov
- Re: [apps-discuss] apps-team review of draft-hols… Mykyta Yevstifeyev
- Re: [apps-discuss] apps-team review of draft-hols… Frank Ellermann
- Re: [apps-discuss] [Uri-review] apps-team review … Mykyta Yevstifeyev