Subject: [apps-discuss] APPSDIR review of draft-ietf-appsawg-about-uri-scheme-04

From: Tim Bray <[email-masked]>
Date: Sun, 29 Apr 2012 22:16:28 -0700

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

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-ietf-appsawg-about-uri-scheme-04
Title: The "about" URI Scheme
Reviewer: Tim Bray
Review Date: April 29th

Summary: This feels like it should perhaps be an informational RFC,
since in reality no sane software developer should rely on the
semantics of any particular “about” token.  Also, it claims to
establish a registry which can impose normative requirements on
browser builders; no standards organization has ever succeeded in
doing this, so why should an RFC include such an implausible
construct?  Aside from that, it feels like a useful reference
document.

Major Issues: [list any major issues such as security concerns,
preferably by section number]

Section 2.2.1 says that tokens defined in the registry MUST be handled
like the registry says. This sounds like putting something in the
registry imposes a normative requirement on Web browsers, which
history has shown no standards organization has ever accomplished.  So
I really don’t see the point.

Minor Issues: [list any minor issues such as text that is unclear or
confusing, preferably by section number]

The terms “resolution” and “resolve” are used incorrectly.  They are
defined in RFC3986, chapter 5, which describes the process of turning
a relative to an absolute URI reference.  Running through this draft
looking at usages:
2.2, both instances of “resolves” should be “refers”
2.2.1 2nd para should say “"about:blank" MUST refer to a resource
represented in the browser by a blank page” - similarly fix the
“blank” token template in 4.2
4.2, 2nd bullet, “to which they should refer”

2.3 “about” IRIs are not permitted. Huh? Why not? I assume this is a
reasonable choice, but it would be friendly to say why this is the
case.

Nits:
1. Introduction - spurious comma after "scheme". Also, "which" would
be better than "that"
1. Introduction "and some other applications" and later "commonplace
in modern user applications", and the claim of other applications also
appears in 4.1 under “Applications/protocols that use the scheme”. I
know of no applications other than browsers, so a citation would be
helpful to support this claim
2.2 "The resource referenced ... is application-specific" - I get what
you’re saying, but might it be clearer to say “not portable between
applications”?
2.2 "Applications MAY use internal redirects..." This whole sentence
is unnecessary; the term “internal redirect” is undefined, and anyhow
who cares what the browser does internally?
2.2.1, last para: split infinitive, “to strongly connect”
3. missing “the” after “apply to”
3. spurious “a” before “sensitive”

---

From: Barry Leiba <[email-masked]>
Date: Mon, 30 Apr 2012 08:45:32 -0400

> Summary: This feels like it should perhaps be an informational RFC,

Yes, that seems to be the consensus in last-call review.  The IESG
will decide the ultimate target status, and see the comment about this
in the shepherd writeup.

> like the registry says.

I agree that we should remove 2119 language from this document,
regardless of what status it winds up with.

> 1. Introduction - spurious comma after "scheme". Also, "which" would

No, you can't have it both ways.  Either we remove the comma and make
the "that..." part restrictive, OR we change "that" to "which", making
the "which..." part non-restrictive.  The intent here is the latter,
so the comma should stay there, and "that" should become "which".

> who cares what the browser does internally?

This struck me as well in my AD review, but I decided to leave it to
the editor.  Now that there's another opinion too, I think the
sentence should come out.

> 2.2.1, last para: split infinitive, “to strongly connect”

Oy.  This is not a rule in English; it's fine as it is.

Barry