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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello John,

Thanks for your thoughts and proposals. Please see my comments (as one of the document co-authors) in-line.

17.06.2011 19:49, John C Klensin wrote:
Given the controversies, I decided I needed to do a careful
reading of this document.  While I respect and appreciate what
the authors are trying to do, as a would-be standards track
specification, it is pretty troubling.
I may agree here.
  It is troubling
editorially as well.
And here as well.
I think all or most of the specific issues have been identified
by others, so let me try a different perspective and a 10 km
view.

(1) There seems to be consensus that registering this URI as a
mechanism for accessing built-in functionality and configuration
information such as application information, preferences, or
settings.   (Text derived from the Abstract with "configuration
information", which may mean more to some readers, added and
"easter eggs" dropped.  Dropping "easter eggs" reflects other
comments on the list and my opinion that it isn't worth the
trouble to define.
With regard to easter eggs I have no strong position. If it is troubling, I don't object to remove any mention of them from the document.
Recommendation: Let's get it registered.
That's what we're trying to do. But see the paragraph before "Smaller issues".
(2)  The document itself reflects an attempt to define the
undefinable.  There is no cross-implementation interoperability
issue here; if anything, the document should me more clear that
it would be stupid to assume it.  The document, nonetheless,
tries to define what is done with some specific URIs in some
places and then has to turn around and indicate that they may be
used in entirely different ways in other places and should not
be relied upon.  In the process, it skips back and forth between
being descriptive and being normative, with some definitions
becoming circular in the process.   That just isn't a good
combination and some of it actually looks pretty silly.
I may partly agree with you. Reading the document for a number of times I've also noticed this. A logical conclusion of everything aforementioned is below.
"about:blank"  is particularly troubling in that regard because
the text essentially says that it is reserved except where it
isn't.

Recommendation:  Choose one of the following and redo the
document to match.

Option 1: Do this descriptively.  Strip it down as much as
possible, more or less repeating the suggested language above.
If the Wikipedia article really contains a better and more
authoritative list of applications than the I-D text (and
especially if it is being kept up to date), just reference it as
a place where a non-normative listing and examples can be found.
The effect of doing this at all would be to reserve the name for
purposes internal to particular implementations of particular
applications, not unlike RFC 1918 addresses.

Option 2: Really try to make this normative wrt some subset of
URI values.  In this approach, stop the extremely confusing
circling around.  Indicate explicitly that "about" URIs have
been used enough and in enough different circumstances that no
application should assume that an "about" URI, if encountered,
is actually its own and that due caution needs to be taken about
non-conforming implementations.  Then explicitly reserve, not
only"about:blank", but  everything the authors think is worth
listing in Examples _and_ create an IANA registry for more of
them.
Actually your Option 2 is what we were trying to do all the time. However, considered a number of existing implementations, each one having their own behavior with regard to about URIs, I actually don' think is is possible. Option 1 seems to be much more realistic; in fact what we had in -00 (http://tools.ietf.org/id/draft-holsten-about-uri-scheme-00.txt) seems the best of any further version of the draft. -00 said that "applications are free to resolve any about URI to any resource, either internal or external, or redirect to an alternative URI, with about:blank being the only exception". That's indeed better that what we have in the -06. Currently, I even question me whether we need to have an RFC published for the purpose of reservation of the scheme. The situation is probably the same as with the view-source URIs. It was ultimately registered with IANA upon a simple request whereas the initial intent was to publish the Informational RFC (see http://www.iana.org/assignments/uri-schemes/prov/view-source; https://datatracker.ietf.org/doc/draft-yevstifeyev-view-source-uri/). RFC 4395 intended the URI scheme registration to be lightweight - template provided is everything you need. So we could just process this registration in such way, as Permanent registration, without any separate specification.
But, even the second approach is taken, the document should be
really clear that all that the use of "about:" really tells
someone is that it is application-specific and that a particular
implementation of a particular application may do whatever it
pleases with them.


  ----
Smaller issues:

(i) Section 6, Normalization, sadly really doesn't belong here
unless the authors can show that everyone interprets "about:"
according to those rules.  Otherwise, it would be better to say
that the URI is interpreted in an implementation-specific way
and that implementations would be well-advised to conform to
normal URI syntax rules unless there is a strong reason not to.
Agree here. This thread restarted with the response to Boris's comment regarding Gecko's normalization rules. This was to claim that no unified rules for the scheme which is a priori used by the applications on their own. As I proposed below, if no document is to be written, the template may contain such statement about implementation-specific normalization rules.
(ii) IMO, Section 7, Security Considerations, should be modified
to include an explicit statement that, since these things are
intended for convenience use within an implementation of an
application, passing them between systems (embedded in files or
otherwise) is very risky behavior and should generally be
discouraged except, possibly, in documentation contexts.
I agree here.
(iii) I know this is partially a problem with the general URI
and IRI definitions, but I'm supposed to know something about
i18n and  encoding and Section 4, Encoding Considerations, is
almost incomprehensible to me.  It isn't quite clear what "this
syntax" refers to (if it is "the 'about' variation on the
general URI syntax described in Section 3", say that).   Then I
think it says I may use any Unicode character, but I have to
%-encode it, but, if it isn't unreserved, it shouldn't be
%-encoded.  If there isn't a clearer way to say that, I suggest
that almost anyone trying to figure out how to use this URI from
the spec is in trouble.  And, fwiw, I've seen "about:" URIs that
use non-ASCII strings without %-encoding.   Whether one calls
those IRIs, URIs, or pumpkins, I see absolutely no reason why an
implementation that knows it is UTF-8 capable (and clean) should
require that an xRI that is intended only for internal use
should require %-encoding of UTF-8 strings... especially since,
in practice, these URIs are often expected to be direct user
input.
Section 4 is what is also questionable. This issue was raised during Last Call and I think can be resolved by saying that an about URIs may contain UTF-8 encoded characters in the <segment>, as suggested by RFC 3986 and that's all.

Mykyta Yevstifeyev
   best,
      john



_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]