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

From: John C Klensin <[email-masked]>
Date: Fri, 17 Jun 2011 12:49:58 -0400

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.  It is troubling
editorially 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.

Recommendation: Let's get it registered.

(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.  

"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.  

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.

(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.

(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.

  best,
     john

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 22 Jun 2011 07:39:07 +0300

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:
> specification, it is pretty troubling.
I may agree here.
>   It is troubling
And here as well.
> comments on the list and my opinion that it isn't worth the
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".
> 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.
> only"about:blank", but  everything the authors think is worth
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.
> 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.
> discouraged except, possibly, in documentation contexts.
I agree here.
> in practice, these URIs are often expected to be direct user
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Lachlan Hunt <[email-masked]>
Date: Thu, 23 Jun 2011 13:16:50 +0200

> troubling, I don't object to remove any mention of them from the document.

The easter eggs are mentioned only in non-normative parts of the 
document, including the abstract and examples, and just reflect the 
reality of what some implementations use about URLs for.  I do not 
understand the objection.

>> combination and some of it actually looks pretty silly.

This feedback is not helpful, as it just vague hand waving and dismissive.

>> the text essentially says that it is reserved except where it

Nonsense.  "about:blank" is clearly defined as reserved, and nowhere 
does it indicate otherwise.  Perhaps you are confused where it excludes 
variations that include query strings?

>> circling around.

The circular definitions have been resolved in the editor's draft.

https://github.com/josephholsten/about-uri-scheme/blob/master/draft-holsten-about-uri-scheme-07.txt

>> 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.

That's the whole point of the unreserved category.

>> 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.

No.  The registry is a completely unnecessary bureaucratic mess that I'm 
strongly fighting against, and will most likely be removing from a 
future draft.  Mykyta added mention of it to the draft* against my 
wishes after I allowed him/her to become an editor even though (s)he has 
still not been able to provide justification for why such a registry is 
necessary.  (However, I allowed the draft to be publicised with it for 
public review and comment.)

* Note: That change hasn't been checked into github, and I don't know
   if Mykyta has those changes somewhere public yet.

The purely informative value of a registry can and has already been 
achieved by Wikipedia.  The three known reserved about URIs (blank, 
legacy-compat and scrdoc) are already documented, as are many other 
unreserved, but recognised application-specific URIs.

Beyond that, the whole concept of reservation only exists to give other 
specifications a clear way to define about URIs for their own purposes 
and doesn't need any formal registration process. It doesn't have any 
impact on any implementations that are not implementing the given 
specification.

>> 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.

It still says that, though the way it is written is a quite ambiguous 
and convoluted and I understand the confusion here.  I'll rephrase the 
section on recognised URIs to address this.

>> normal URI syntax rules unless there is a strong reason not

> 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.

Yes, normalisation requirements will be removed.

> ...

Mykyta, feel free to revise sections 4 and 7 as you see fit.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 24 Jun 2011 06:50:00 +0300

Hello all,

> understand the objection.
As I've already mentioned, I have no any strong position regarding 
"easter eggs".  Yet, my opinion is that mentioning them clarifies the 
usage of about URIs a bit.
> This feedback is not helpful, as it just vague hand waving and 
I wouldn't say so; this remark is quite reasonable.  In our section 
dedicated to categorization we try to normatively specify how about URIs 
are resolved due to the categories we try to create; ibidem we sometimes 
give no clear description of related issue.  Eg., suppose I write my 
browser, YevstifeyevBrowser, which uses the about URI about:bad-guy.  I 
then claim it as "reserved" and, according to our draft, any application 
which is compatible to it must resolve it to what I want.  Suppose 
another browser, FooBrowser, makes use if about:bad-guy as well, but for 
other purpose; but, being compatible with our spec. it can't.  The issue 
is impossibility to rule out which is a priori used internally only and 
is implementation-specific.  Another instance.  Some application may 
treat some about URIs as resolvable while other as unresolvable.  Eg., 
FooBrowser may resolve "unresolvable-as-per-HTML5" about:legacy-compat 
to the page saying it is unresolvable etc.
> does it indicate otherwise.  Perhaps you are confused where it 
> excludes variations that include query strings?
"about:blank" is a special case which is one of the rare instances of 
what is acceptable by almost all browsers.  As for queries - I've 
checked several browsers for their behavior.  Firefox 5.0 - 
about:blank?aa is treated about:blank.  Chrome 12 - the same.  IE8 
treats about:blank?aa as invalid URI returning "going to web page 
canceled".  Opera 11 - as FF.  Finally, Safari 3.2.1 has the same 
behavior.  I see the majority of contemporary browsers treat about:blank 
with query component as if it isn't present.  I personally see no point 
in reserving the about URI with no query only.
> https://github.com/josephholsten/about-uri-scheme/blob/master/draft-holsten-about-uri-scheme-07.txt 
I, as one of the editors, is a bit confused by this draft.  It 
incorporates none of changes I proposed and made after you made it 
available.  My editor's version is from June 14, not April 13, when this 
file was uploaded.
> No.  The registry is a completely unnecessary bureaucratic mess that 
> I'm strongly fighting against, and will most likely be removing from a 
> wishes after I allowed him/her
I'm male, FYI.
> to become an editor even though (s)he has still not been able to 
> provide justification for why such a registry is necessary.  (However, 
> I allowed the draft to be publicised with it for public review and 
> comment.)
>
I have no access to Github but I've sent you the latest edited version 
of the draft in email on 14 June, if you remember.
> Beyond that, the whole concept of reservation only exists to give 
> other specifications a clear way to define about URIs for their own 
> purposes and doesn't need any formal registration process. It doesn't 
> have any impact on any implementations that are not implementing the 
> given specification.
Considering the controversy of this question, I think we may put it 
aside for a time.  Anyway, when the document is published, we can add 
the registry if there is a necessity; please note that my justification 
for the registry was ongoing comments on its necessity during Last Call, 
so IMO, of course, "he has still not been able to provide justification 
for why such a registry is necessary" is probably untrue.

Actually, I have some concerns about section on resolving about URIs.  I 
understand what I propose below surely does not fit in what we have in 
the current draft and, mainly, its concepts.  However, were I to decide 
myself, I would fully rewrite the document is the following way.  First, 
the intended status would be Informational.  Syntax would be left in the 
current form.  More important the semantics probably are.  I'd mention 
that (1) 'about' URIs are used internally only, so any application is 
free to resolve it to any resource with any semantics, except the 
several instances, defined below as "special-purpose 'about' URIs", 
which are permanently reserved for use in a specific manner; (2) a 
special-purpose 'about' URI as an 'about' URI using a particular 
well-known segment and which is defined to be used for a specific 
purpose and MUST be used only and only as defined in a specification of 
such URI; (3) categorization into "resolvable/unresolvable" would be 
eliminated; (4) provisions regarding recognition of the URIs would be 
almost the same.  Encoding considerations would be that about URIs may 
contain characters from UCS first encoded with UTF-8; those UTF-8 
encoded characters which do not fit in the RFC 3986 definition for 
<segment> or <query> SHALL be percent-encoded within corresponding 
part.  Then a registry for special-purpose 'about' URIs would be 
created.  For a number of now-in-use, though not special-purpose, 
'about' URIs the reader would be pointed to 
http://en.wikipedia.org/wiki/About_URI_scheme

I'd like to seek the current editors' opinion on the proposed approach 
above.  IMO, such description is (a) clearer and (b) removes a number of 
controversial issues.
> section on recognised URIs to address this.
See my proposal above.
> Yes, normalisation requirements will be removed.
Probably they aren't to be removed but rather mentioned as 
implementation-specific.
> Mykyta, feel free to revise sections 4 and 7 as you see fit.
All the best,
Mykyta Yevstifeyev