Subject: Re: Last Call: <draft-ietf-appsawg-about-uri-scheme-04.txt> (The "about"URI Scheme) to Proposed Standard

From: t.p. <[email-masked]>
Date: Thu, 19 Apr 2012 14:52:33 +0200

The I-D points out the impossibility of specifying how to handle the many
different tokens that  a browser may encounter in the about: scheme and then
goes on to tell us what Opera does.

I am uncomfortable with a Standards Track document telling us about the
behaviour of one and only one product, with, the text being in the body of the
I-D, an implication that this text has Normative status (earlier versions of
this I-D also included Mozilla Firefox).

The web browser mentioned is a fine web browser but I think that having just the
one example is inappropriate; other examples should be mentioned (and they all
should be in an Informative appendix).

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 18, 2012 10:57 PM
>
> 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
> [email-masked] mailing lists by 2012-05-02. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
> This document specifies the "about" URI scheme, which is widely used
>    by web browsers and some other applications to designate access to
>    their internal resources, such as settings, application information,
>    hidden built-in functionality, and so on.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-about-uri-scheme/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-about-uri-scheme/ballot/
>
> No IPR declarations have been submitted directly on this I-D.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 19 Apr 2012 10:48:18 -0400

> From: t.p. [[email-masked]]
> 

I have the sense that we aren't looking at the same draft.  My copy of
draft-ietf-appsawg-about-uri-scheme-04 doesn't contain a list of the
Opera uses of "about:".  The only mentions of Opera are 'for instance,
the Opera web browser redirects all "about" URIs except "about:blank"
to its internal "opera" URIs' and (implicitly) a description of how
Opera acts on "about:blank".  What I see in -04 looks quite reasonable
to me regarding this issue.

On the other hand, I think an improvement could be made in the
terminology.  The draft uses "special-purpose" to mean what is
normally called "standardized", that is, all applications are expected
to handle it in the same way.  The "application-specific" values are
what is normally called "proprietary", but "application-specific" is a
reasonable synonym.

In any case, it is a good idea to properly document and standardize
the "about" URI scheme itself, which this draft is needed for.

Dale

---

From: John C Klensin <[email-masked]>
Date: Thu, 19 Apr 2012 15:29:56 -0400

--On Wednesday, April 18, 2012 13:57 -0700 The IESG
<[email-masked]> wrote:

> 
> The IESG has received a request from the Applications Area
> Working Group WG (appsawg) to consider the following document:
> 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 [email-masked] mailing lists by
> 2012-05-02. Exceptionally, comments may be sent to
> [email-masked] instead. In either case, please retain the

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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 19 Apr 2012 15:47:15 -0400

>   <draft-ietf-appsawg-about-uri-scheme-04.txt> as a Proposed Standard

I read this document.  I have no strong objection to it, but I can see
no reason whatever that it should be on the standards track, because
AFAICT it doesn't standardize anything.  I seem to recall saying
something similar in the WG some time ago, but I suspect I missed the
WGLC for this draft or I would have said the same thing there.

It should not be on the standards track because it fails a minimal
test for interoperability.  Section 2 makes clear that there is no
common meaning of about: URIs.  This means that there is no reason to
suppose a URI of the form about:foo accesses the same resource when
accessed from different products.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 23 Apr 2012 13:00:10 +0300

Hello,

As I guess no other initial comments are going to come, let me present my
opinion on the raised issues.

With respect to Standards Track - I actually agree this document is not to
be on Standards Track, as this can't be standard anyway.  But I can't agree
the draft must be published as Informational, because in RFC 2026 meaning
Informational RFCs are to make a record of an 'outer-space' protocol to
IETF.  But here are some other thoughts of mine:

I should note that 'about' URI scheme is very similar to 'view-source' URI,
which I once proposed to document (
https://datatracker.ietf.org/doc/draft-yevstifeyev-view-source-uri/).
After discussion on uri-review list we reached consensus on that it isn't
necessary to document the scheme in separate document, and an only template
may be enough to enter a scheme in the IANA registry (
http://www.iana.org/assignments/uri-schemes/prov/view-source).

I should also note that the document which is now in IETF Last Call was
primarily created for HTML5 specification, and, specifically, to allow
standardizing 2 'about' URIs which are used in HTML5 draft.  There wasn't
the specification for 'about' URI scheme, and I guess somebody though IETF
has an authority to provide one.  This is very disputable, as 'about'
scheme is not a protocol, or anything else, but just a now-common internal
tool in some software.

Now, re-reading the draft, I see it's not a standard as we understand it,
and it can't be.  So, if we take this into account, let's answer:

Do we need to document 'about' URI at all, or we just need to enter it in
the registry 'for the record', or we need to do nothing?  It's very distant
from Internet Standard of any kind, and from IETF as well.  I also think
HTML5 as standard itself, and I hope it'll be widely recognized as
standard, may specify the two 'about' URIs it needs without our (IETF's)
help.  Any thoughts?..

Last Call ends on 2 May, and I hope we'll be able to reach some consensus
on this.

Mykyta Yevstifeyev

19 апреля 2012 г. 22:47 пользователь Andrew Sullivan <[email-masked]
> написал:

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 23 Apr 2012 11:37:36 -0400

> From: Mykyta Yevstifeyev [[email-masked]]
> 
> I should also note that the document which is now in IETF Last Call
> was primarily created for HTML5 specification, and, specifically, to
> allow standardizing 2 'about' URIs which are used in HTML5 draft.

Why doesn't the draft mention this, and describe those two URIs?

Dale

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 24 Apr 2012 12:42:20 +0300

> Why doesn't the draft mention this, and describe those two URIs?

HTML5 specification is expected to do this.  This document is created to
allow 'standardizing' 'about' URIs, which I personally think isn't a good
thing.

Mykyta Yevstifeyev

---

From: Barry Leiba <[email-masked]>
Date: Tue, 24 Apr 2012 11:35:38 -0400

> IETF.

I have no idea what the second sentence means.

But, yes, to clarify the point on the intended status: It's a procedural thing.
The working group had some uncertainty about whether the IESG would
accept an Informational document to do this registration.  My sense is
that the WG would prefer Informational.  But here's the procedural
point:
- If we last-called this as Informational and the IESG were to decide
that it needs to be Standards Track, we'd require a new last call for
the status change.
- If we last-called this as Proposed Standard and the IESG were to
decide that it should be Informational, it could just be changed by
the IESG, without a second last call.

And, in fact, the PROTO writeup says this, in answer to the first
question on intended status:
"The requested RFC is Standards Track (Proposed Standard ).
There are some concerns whether we can register a URI in the Permanent
registry if the document status is Informational. If this is not a problem, this
document can be informational."

So from a procedural point of view, it was better to last-call it as
Proposed Standard and get the comments.  And that was useful: we have
comments expressing a preference for NOT putting this on Standards
Track, and that's valuable input for the IESG.

Barry