Hello,

As I proposed below, I've made some changes to produce an "alternative" 
about URI scheme draft.  As no one of the current editors responded to 
this message (and, explicitly, my actual proposals), I'd like to bring 
them in form of the remade draft to the public discussions.  You may 
find it attached to this message.

Thanks,
Mykyta Yevstifeyev

24.06.2011 6:50, Mykyta Yevstifeyev wrote:
> Hello all,
>
> 23.06.2011 14:16, Lachlan Hunt wrote:
>> On 2011-06-22 06:39, Mykyta Yevstifeyev wrote:
>>>> (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.
>>
>> 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.
> 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.
>>
>>>> (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.
>>
>> This feedback is not helpful, as it just vague hand waving and 
>> dismissive.
> 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.
>>
>>> 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.
>>
>> 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?
> "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.
>>
>>>> Option 2: Really try to make this normative wrt some subset of
>>>> URI values. In this approach, stop the extremely confusing
>>>> 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 
>>
> 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.
>>
>>>> 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
> 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.)
>>
>> * Note: That change hasn't been checked into github, and I don't know
>>   if Mykyta has those changes somewhere public yet.
> 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.
>>
>> 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.
> 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.
>>
>>>> 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.
> See my proposal above.
>>
>>>> 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
>>
>>> 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.
>>
>> Yes, normalisation requirements will be removed.
> Probably they aren't to be removed but rather mentioned as 
> implementation-specific.
>>
>>>> (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.
>>> ...
>>> 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, feel free to revise sections 4 and 7 as you see fit.
>>
> All the best,
> Mykyta Yevstifeyev
>