The 'about' URI scheme
draft-holsten-about-uri-scheme-06

Hi Editors,
Based on IETF Last Call comments it is quite clear that the document needs another revision. For your convenience I've collected the most important comments at the end of this message. You need to either respond to them arguing why no change is needed for a particular reported issue, or you need to update the draft to address the corresponding issue.

The major issue is lack of a [lightweight] registry for components ("blank", "tabs", etc.). It was reported by pretty much every reviewer. I can help you with some text on this, but feel free to take a first stab at it.

My current thinking is that First Come First Served would work just fine (i.e. anybody can register a new component, as long as the name is not already taken. There is no Expert Reviewer involved.

Boris Zbarsky wrote:

> There seem to be two differences between what the draft specifies right now and what Gecko, at least, does:
>
> 1) Section 5.3 says:
>
>    Applications SHOULD resolve unrecognized "about" URIs in the
>    same way as "about:blank".
>
> Gecko treats unknown about:* as unparseable URIs, and is not likely to change that behavior.  While that's allowed by the SHOULD, it's not clear to me why this is a SHOULD as opposed to a MAY, nor is it clear why this is present at all.  In particular, as specified this will cause situations where an empty resource is silently returned instead of a failure that the consumer can notice (e.g. in the DOM case via error event handlers and the like).
>
> 2)  Section 6 says:
>
>  For example, "about:blank", "about:blan%6B" and "about:blan%6b"
>  are equivalent
>
> In Gecko they are not.  The string after ':' is treated as a literal string; when looking up a way to handle the URI the second and third URIs above are treated as unparseable by Gecko in its default configuration.  Changing this has some security implications that would require careful auditing of not only Gecko code but some specifications (e.g. HTML5 defines certain special-case security behavior for about:blank that's not obviously safe to apply to the other strings above).
>
> The same section says:
>
>  Similarly, "about:blank%3F" is not equivalent to "about:blank?".
>
> which I think is trying to explain by example that only unreserved characters need to be unescaped.  But that assumes an implementation of RFC 3986 which may or may not be the case in web browsers (and is NOT the case in Gecko, for example, for various web-compatibility reasons).  Unless there are very strong reasons for it, I would recommend that no normalization is performed on about: URIs, period.



Martin J. Dürst wrote:

> Major Issues:


[...]

> - 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.
>
>
> 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).
>
> - 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
>
> - 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.
>
> - 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.
>
> - 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).
>
> - Section 5.1.1 contains a lone sentence fragment 'i.e. "about:blank".', which seems to be unnecessary.
>
> - 5.4. Examples is inconsistent with final punctuation.



Graham Klyne wrote:

> Alexey Melnikov wrote:
>
>> Hi Graham,
>>
>> Can I ask you for an early review (as the Designated Expert) of
>> ?
>> In particular, I would like to hear your opinion on whether it is suitable as a permanent registration.
>
>
> Broadly, I understand this spec is describing what is in any case more-or-less common practice for modern browsers, and as such it is entirely appropriate for permanent URI scheme registration, especially of this defining document progresses on the standards track.
>
> I think the specification itself could be improved; e.g. some specific oddities I noticed are noted below.  Even though the spec explicitly states that the about: URIs are for internal use by an application (mainly browsers, I suspect), the fact that they occupy the same namespace as more common "externalized" URIs, and the fact that web pages might find reasons to include about: URIs in their content, makes it sensible to register the scheme.
>
> In its current form, only about:blank is defined.  As a secondary issue, it might be worth thinking about creating an IANA registry for the "segment" element of about: URIs, though this might be something to leave until there is an actual need for it.
>
> ...
>
> A couple of specific nits I had with the specification:
>
> 4.  Encoding Considerations
>
> "then only those octets that do not correspond to characters in the unreserved set [RFC3986] SHOULD be percent-encoded."
>
> This seems really oddly worded use of SHOULD to me.  I'd find a re-wording "... octets that correspond ... SHOULD NOT ..." to be more reasonable.
>
>
> 5.  Resolving "about" URIs
>
> The discussion of "reserved" and "unreserved" is a bit lacking... they are defined in terms of "a specification" without saying anything about what constitutes "a specification".



Alexey Melnikov wrote:

> Gabriel Montenegro wrote:
>
>> Hi Alexey,
>
>
> Hi Gabriel/Adrian/Eric,
>
> Sorry for sitting for so long on your comments. I was hoping that the editors would respond to the comments. In order to stimulate the discussion.
>
>> Adrian Bateman, Eric Lawrence and I looked at it and here's some feedback:
>
>
[...]

>> 2. Requiring applications to support "about:blank" seems rather unnecessary, since there are many types of user-agent for which there is no need to support this URI.
>
>
> Can you think of an application that would support "about:" but wouldn't support "about:blank"?
>
>> FYI: IE does not currently match the definition of "about:blank". IE returns a resource of length 13 containing the fixed string:
>
>
> I think it would be easy to tweak the draft to make sure that IE complies with it. I don't see a reason why not do that in this particular case.
>
>> 3. The "Security considerations" section would be far more valuable if it explained WHY it suggests the SHOULD NOT behaviors that it does, lest a developer ignore the guidance in this section.
>
>
> Probably a good idea.

[...]

>> 5. Might be good to have some background (just a sentence or two) about the motivation behind this, namely, this URI scheme is now being leveraged elsewhere so proper registration is in order, e.g., documents generated from XSLT may have such a URI (http://www.w3.org/html/wg/tracker/actions/103 and http://www.w3.org/html/wg/tracker/issues/54).
>
>
> Right.
>
>> Gabriel

GenArt review by Suresh Krishnan :

Summary: This draft is almost ready for publication as Proposed Standard
but has a minor issue that needs to be clarified.

* Minor
=======

The draft talks about reserved "about" URIs without talking about how an
application can actually recognize the reserved URIs. Is there an expectation that many more reserved about URIs will be created in the future? (I found 3 in total with two of them defined to be unresolvable). Is there going to be an IANA registry set up for this purpose? If so, this document needs to instruct IANA to create such a registry and provide the initial entries there.

Upon approval of this document, IANA will register the following in the
permanent URI scheme registry at

http://www.iana.org/assignments/uri-schemes.html

URI Scheme Description Reference
---------- ----------- ---------
about about [RFC-to-be]

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (The 'about' URI scheme) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'The 'about' URI scheme'
  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@ietf.org mailing lists by 2011-02-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-holsten-about-uri-scheme/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-holsten-about-uri-scheme/

[Note that the comments below were edited, answers/comments from Alexey.]
The following comments were received from Gabriel Montenegro (Microsoft) and his co-workers.

1. Some concerns of why this is targeted at PS and not Informational. This is still being debated.

> 2. Requiring applications to support "about:blank" seems rather unnecessary, since there are
> many types of user-agent for which there is no need to support this URI.

Can you think of an application that would support "about:" but wouldn't support "about:blank"?

> FYI: IE does not currently match the definition of "about:blank". IE returns a resource of length
> 13 containing the fixed string:

I think it would be easy to tweak the draft to make sure that IE complies with it. I don't see a reason why not do that in this particular case.

> 3. The "Security considerations" section would be far more valuable if it explained WHY it
> suggests the SHOULD NOT behaviors that it does, lest a developer ignore the guidance in this
> section.

+1.

> 4. It doesn't appear to impose any rules regarding how "about:" URIs are combined.

> 5. Might be good to have some background (just a sentence or two) about the motivation behind
> this, namely, this URI scheme is now being leveraged elsewhere so proper registration is in order,
> e.g., documents generated from XSLT may have such a URI
>(http://www.w3.org/html/wg/tracker/actions/103 and http://www.w3.org/html/wg/tracker/issues/54).

+1.

The following comments were received from Gabriel Montenegro  (on behalf of some people from Microsoft). While authors don't necessarily have to agree/act on all of them, they must at least review and respond to them:

1. This is " to be used internally by applications "  which seems akin to an API as opposed to a protocol with on-the-wire implications. Accordingly, would it make more sense to publish as informational, rather than standards track?

2. Requiring applications to support "about:blank" seems rather unnecessary, since there are many types of user-agent for which there is no need to support this URI. FYI: IE does not currently match the definition of "about:blank". IE returns a resource of length 13 containing the fixed string: 

3. The "Security considerations" section would be far more valuable if it explained WHY it suggests the SHOULD NOT behaviors that it does, lest a developer ignore the guidance in this section.

4. It doesn't appear to impose any rules regarding how "about:" URIs are combined.

5. Might be good to have some background (just a sentence or two) about the motivation behind this, namely, this URI scheme is now being leveraged elsewhere so proper registration is in order, e.g., documents generated from XSLT may have such a URI (http://www.w3.org/html/wg/tracker/actions/103 and http://www.w3.org/html/wg/tracker/issues/54).