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

[Mykyta Yevstifeyev <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>