--On Wednesday, April 18, 2012 13:57 -0700 The IESG <iesg-secretary@xxxxxxxx> wrote: > > The IESG has received a request from the Applications Area > Working Group WG (appsawg) to consider the following document: > - 'The "about" URI Scheme' > <draft-ietf-appsawg-about-uri-scheme-04.txt> as a Proposed > Standard > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send > substantive comments to the ietf@xxxxxxxx mailing lists by > 2012-05-02. Exceptionally, comments may be sent to > iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. Hi. I've expressed more detailed concerns on the WG list or earlier, but, since those seem to have been in the WG rough, two very general comments: (1) It is not clear that this document benefits from a historical review but, if the authors choose to provide one, it should be accurate. For example, the second paragraph of the Introduction says: > The concept of "about" URIs formed when applications did not > have a "friendly" user interface, to enable access to the > aforementioned resources by typing URIs into an address bar or > similar feature. There were applications with user-friendly interfaces to configuration long before there were URIs, so certainly the above statement cannot be true as written. My recollection is that "about:" came into being because the development team for a particular early browser was unwilling or unable (given resources and other constraints) to spend the time developing what they would have considered an appropriate UI for options they did not expect to be used extensively, but that is rather different. And, fwiw, that actual history puts the origins of "about:" into a category that is often described with language like "quick hack", although that doesn't prevent standardizing just as other quick hacks of that period have been recognized in standards when they were shown to have lasting value. (2) This document is being proposed for Standards Track, but it is not clear what is being standardized. Certainly it registers and reserves the scheme name "about", which I think it a good idea (and agree with the authors that it is overdue). But, as a particularly interesting example, the IANA Template says "see Section 2.2" for "URI scheme semantics", but Section 2.2 doesn't actually specify anything. That is clear from its first couple of paragraphs which start "Generally speaking..." and "However, it is impossible to specify a binding...". Even the special token material is questionable. Certainly we recognize "about:blank", but it is not clear from the text that we really have enough understanding of other things that might be registered to have any idea whether the specifications for the new registry and the registration template are adequate. Perhaps that is the result of trying to generalize from one case, perhaps it is more broadly symptomatic. As an example, the paragraph under the figure in Section 4.2 contains the interesting phrasing "The registrant of the token ought to provide...". Is "ought to" a synonym for SHOULD and, if so, shouldn't the specification contain guidance for IANA as to when they are to make a registration entry even when that information is not provided? Or does it mean something else entirely and, if so, what? I also note that, in general, we ask that information that is required (or even optional) for registration go into the registry but this one expects that material to appear in separate documentation with very little in the registry itself. I'm sure there are registries and registrations out there that provides contact or authority information only by indirection through other documents (documents that are not required to be standards track RFCs or otherwise meeting our requirements for normative references) but they are rare and, IMO, undesirable. Recommendation: Before this specification is adopted as a Proposed Standard, it should be absolutely clear what is standardized, what is general advice, and what is just commentary. Hand waving like "ought to" should be removed in terms of 2119-style requirements statements is requirements are intended or clarified sufficiently to give IANA clear guidance on content and operation of a registry. That is especially important for an FCFS registration spec where, in principle, only IANA evaluates a request for conformance to the specification before modifying the registry. The setup for the token registry reflects the debates about registration conventions that have waged since this document was first proposed. However, it seems to go both ways in that debate. On the one hand, it singles out a single keyword, "blank", for registration. It indicates that there can be more but that they should/will be rare. It does not encourage registration of other keywords to lower the risk of different applications using a given keyword for different purposes. And I can't find any actionable criteria for when something should be registered and when doing so is assumed to be not worth the effort. Our old principle of conflict-reduction would argue for trying to get all keywords registered even if they were used only in a single implementation. If the criterion is actually "it is common knowledge that this is used by almost everyone and used in the same way", then it is not clear what value is added by creating a registry. IMO, the document needs to be much more clear about those issues and what it intends. Once it is, we can have a meaningful discussion about consensus on those points. As it stands today, a claim of consensus would need to be based on the assumption that, somehow, everyone understands what is expected to be done about registration of additional tokens. I just don't believe that is true. Finally the historical descriptions should either be cleaned up or removed. best, john