Hi Ted,
On 21.01.2011 23:49, Ted Hardie wrote:
This rationale isn't in the draft, nor is the token legacy-compat.
...because HTML5 defines it... (I think)
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 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.
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.
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.
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".
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.
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.
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.
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 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?
Not arguing with that :-).
...
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf