Subject: Re: Last Call: <draft-holsten-about-uri-scheme-06.txt> (The 'about' URI scheme) to Proposed Standard

From: SM <[email-masked]>
Date: Thu, 20 Jan 2011 11:18:47 -0800

At 07:56 14-01-11, The IESG wrote:

>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'The 'about' URI scheme'
>   <draft-holsten-about-uri-scheme-06.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

There is a IANA registration in Section 8.  The arguments at 
http://www.ietf.org/mail-archive/web/ietf/current/msg65163.html are 
also applicable to draft-holsten-about-uri-scheme-06.

In Section 5.2:

   "Applications MAY resolve any unreserved "about" URI to any resource,
    either internal or external, or redirect to an alternative URI."

What happens when the unreserved "about" URI becomes a reserved 
"about" URI in future?

Regards,
-sm

---

From: Ted Hardie <[email-masked]>
Date: Thu, 20 Jan 2011 17:13:47 -0800

I agree with SM's concern that the mechanism by which this is
extended is underspecified.  The draft contains one reserved
token, "blank", and a set of examples which make clear that there
is an unwritten set of known and unknown tokens which populate the "segment"
portion of the given ABNF.  Providing a registry for those tokens,
possibly with simple "reserved" status if no specification exists, might
help.  Standardizing a method for querying what about: tokens are
available in a specific context might as well (about:about, for example,
or about:?about).

But the reality is that the behavior resulting from these URIs is totally
non-deterministic and varies from context to context.  In most contexts
outside of a browser location bar, they are meaningless. Inside that
context, the browser's definition seems to be definitive.  If the aim
is only to get about:blank fully specified, I'd suggest saying so outright,
and noting clearly that all other uses are context-dependent, with
returning about:blank recommended practice  for those unknown.

As a thought experiment, would the W3C counsel against the presence
of an about URI in an XML namespace?

Additionally, naming a change controller should generally be a bit more
precise than an organization name.  The W3C director or TAG seems
more appropriate than just "W3C".

regards,

Ted Hardie

On Thu, Jan 20, 2011 at 11:18 AM, SM <[email-masked]> wrote:
> http://www.ietf.org/mail-archive/web/ietf/current/msg65163.html are also
> applicable to draft-holsten-about-uri-scheme-06.
>
> In Section 5.2:
>
> What happens when the unreserved "about" URI becomes a reserved "about" URI
> in future?
>
> Regards,
> -sm
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 21 Jan 2011 09:40:31 +0200

> available in a specific context might as well (about:about, for example,

Hello all,

I'd like to agree with the proposition to create the regsitry for
'about' URI tokens  That will allow to track what tokens become
'reserved', 'unreserved', etc. simplier.

Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Fri, 21 Jan 2011 09:28:56 +0100

On 21.01.2011 02:13, Ted Hardie wrote:
> ...
> ...

That sounds reasonable. Let's not make it more complicated than it needs 
to be.

> of an about URI in an XML namespace?

Reminder: the reason this was written down was so that 
"about:legacy-compat" can be specified as XML system identifier in HTML5 
(<http://dev.w3.org/html5/spec/Overview.html#the-doctype>).

> more appropriate than just "W3C".

I just checked an image/svg+xml has "W3C" as change controller. Why 
would the requirement be different here?

Best regards, Julian

---

From: "t.petch" <[email-masked]>
Date: Fri, 21 Jan 2011 12:14:46 +0100

----- Original Message -----
From: "SM" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 20, 2011 8:18 PM
Subject: Re: Last Call: <draft-holsten-about-uri-scheme-06.txt> (The'about' URI
scheme) to Proposed Standard

> also applicable to draft-holsten-about-uri-scheme-06.

Further to that, I did ask IANA if, when carrying out the procedures of
registration in accordance with RFC4395, they performed any checks
on the contact details of the Change Controller for the URI.  So far,
I have heard no more so I am assuming that whatever the IETF and
IESG approves in the I-D is taken as gospel by IANA.

Tom Petch

---

From: Ted Hardie <[email-masked]>
Date: Fri, 21 Jan 2011 08:57:35 -0800

Howdy,

Some comments in-line.

On Fri, Jan 21, 2011 at 12:28 AM, Julian Reschke <[email-masked]> wrote:
> That sounds reasonable. Let's not make it more complicated than it needs to
> be.
>

Okay.
> Reminder: the reason this was written down was so that "about:legacy-compat"
> can be specified as XML system identifier in HTML5

This rationale isn't in the draft, nor is the token legacy-compat.
Having looked
at the section you reference, I see it also defines about:srcdoc as reserved,
unresolvable URI.  It should be included in this doc, if it goes forward.

That said, I note that HTML5 has a number of what it calls "willful violations"
of the URI spec, in which it counsels the reading who actually knows what
the spec says to pretend it was using a term other than URI.  (One of these
is just past the fragment identifier used above).  Most uses of about
are outliers in the URI world by a long chalk.  Why not simply define about
as a different identifier form that happens to have a colon in it
(which, broadly,
it is) and make its use as system identifier in HTML5 a "willful violation" of
the XML spec?  That seems entirely consistent with the document's modus operandi
and save IANA the trouble of setting up a registry.

best regards,

Ted

> I just checked an image/svg+xml has "W3C" as change controller. Why would
> the requirement be different here?
>
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 21 Jan 2011 18:37:48 +0100

> This rationale isn't in the draft, nor is the token legacy-compat.

...because HTML5 defines it... (I think)

> unresolvable URI.  It should be included in this doc, if it goes forward.

I don't think the goal of the registration document is to define all 
about URIs out there. (and I don't think it should).

> of the URI spec, in which it counsels the reading who actually knows what

Sadly.

> and save IANA the trouble of setting up a registry.

:-)

Browsers use "about:" where URIs are entered. So no matter what we 
think, it will be very hard to ever register a "about" URI scheme for 
something else.

Why not just accept it, and have a registration that at least enhances 
the situation (as opposed to it not being registered)?

Also -- the spec doesn't define an IANA registry, so there won't be any 
trouble for them anyway.

Best regards, Julian

---

From: Ted Hardie <[email-masked]>
Date: Fri, 21 Jan 2011 14:49:41 -0800

Howdy,

Some further replies in-line.

On Fri, Jan 21, 2011 at 9:37 AM, Julian Reschke <[email-masked]> wrote:
>>> "about:legacy-compat"

But the question with this how you will get interoperability.  If there is a
token registry, then these should populate that registry pretty much
as soon as the registry opens, as these are entries for which conflict
has a bad result.  The whole point of a registry is to avoid collisions in
the token portion of the identifier space.

> I don't think the goal of the registration document is to define all about
> URIs out there. (and I don't think it should).
>

It goes to significant lengths to define the behavior of about:blank,
and it mentions but does not define others.  That's a bit odd, in
IETF circles, especially when you are defining a protocol  to have
"reserved" and "unreserved" tokens.  This iis why the suggestion
of a registry is being made. That gives a place to look
for behavior definitions and confirm reserved vs. unreserved.

If that is not really wanted, this draft is  reserving a URI scheme on
what looks to me to be closer to provisional terms.

I have enough experience on the URI registration side to understand
that people mint schemes without registration pretty readily, and minting
tokens seems even easier.  If you don't  care at all about interoperability
in this behavior, a registry is not needed, but then I'm not sure why
a permanent URI registration is needed either.   The about: convention
has been around a while, and a provisional to note it seems enough.

> Browsers use "about:" where URIs are entered. So no matter what we think, it
> will be very hard to ever register a "about" URI scheme for something else.
>

I agree, and a provisional to block its registration seems sensible.  But if you
are not eventually trying to get interoperable behavior, having "reserved"
elements for this scheme seems, at best, confusing.

> Why not just accept it, and have a registration that at least enhances the
> situation (as opposed to it not being registered)?
>
The last call invites advice from the community on how to improve the document.
Why not just accept, and trust it enhances the situation?

best regards,

Ted

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Jan 2011 10:47:22 +0100

Hi Ted,

> the token portion of the identifier space.

I can't speak for the author, but I think the believe is that interop is 
only needed for a few specific values (and only realistic for those), 
and thus having them defined *somehwere* (HTML5 or about-URI-spec is 
sufficient).

I agree that it's a bit odd that the HTML5 spec defines some of those, 
but not about:blank.

Maybe all of them should live in the HTML5 spec.

> what looks to me to be closer to provisional terms.

If you look at the document history, it started with "provisional". I 
think this was changed based on early feedback; this is not a 
placeholder registration but *really* all that can be said about "about".

> has been around a while, and a provisional to note it seems enough.

I believe "about" qualifies for permanent as per 
<http://tools.ietf.org/html/rfc4395#section-2>, if there's something 
essential missing, we should fix it.

> elements for this scheme seems, at best, confusing.

In particular,

    Other specifications MAY reserve "about" URIs.  Applications
    attempting to resolve reserved "about" URIs that are not defined to
    be resolvable, MAY treat such URIs as being unreserved.

reads odd.

> Why not just accept, and trust it enhances the situation?

Not arguing with that :-).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Jan 2011 13:50:26 +0100

>> of the URI spec, in which it counsels the reading who actually knows what

BTW: <http://www.w3.org/html/wg/tracker/issues/56>. We should try to 
improve this, maybe during Last Call.

See also: <http://www.w3.org/html/wg/#join>

Best regards, Julian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 24 Jan 2011 10:02:18 -0800

> essential missing, we should fix it.
Hi Julian,

I think the key question is whether this qualifies as well-defined
(section 2.3).
The draft declares some tokens/strings to be "reserved", and names one such
string.  It also declares that other strings may be reserved by other
specifications,
but it provides no way to discover them.  This leads someone who wishes to mint
a new "about" uri with no way of discovering whether a specification
has reserved
it.  To me, that means "reserved" is not currently well-defined.

I would not personally propose HTML5 be the canonical source for reserving these
strings, because I have some serious reservations about that spec's tendency to
fork other specs.  But the conversation thus far leads to believe that the two
probably ways forward are to

1) have a registry and populate it with blank and those
from the HTML5 spec as initial values

2)make HTML5 the only spec which can reserve these strings, an move
blank into it.

I hope this is clear.

best regards,

Ted Hardie

---

From: SM <[email-masked]>
Date: Mon, 24 Jan 2011 15:16:48 -0800

Hi Ted,
>it.  To me, that means "reserved" is not currently well-defined.

Yes.

>2)make HTML5 the only spec which can reserve these strings, an move

Agreed.

Regards,
-sm