RE: [public-webapps] Comments on Widget URI (General)

In reply to http://www.ietf.org/mail-archive/web/uri-review/current/msg01014.html 
(and prompted by a discussion at W3C TAG) I reviewed the proposed "widget:" URI scheme  http://www.w3.org/TR/2009/WD-widgets-uri-20091008/ as well as the (more recent, but dated the same?) editor's draft http://dev.w3.org/2006/waf/widgets-uri/ .

As requested in the original call, I sent comments to public-webapps@w3.org. Rreview comments, responses, and my responses to those comments can be searched for: 
http://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-name=subject&hdr-1-query=widget+URI&index-grp=Public_FULL&index-type=t&type-index=public-webapps

The criteria for permanent URI schemes and the process for registering them are documented in RFC 4395 http://tools.ietf.org/html/rfc4395. Editors of documents attempting to register a new URI scheme (as well as the chairs and W3C staff contacts of the working groups involved) should familiarize themselves with that document. 

The process for registering a new URI scheme:

   The URI registration process is described in the terminology of [3].
   The registration process is an optional mailing list review, followed
   by "Expert Review".  The registration request should note the desired
   status.  The Designated Expert will evaluate the request against the
   criteria of the requested status.  In the case of a permanent
   registration request, the Designated Expert may:

   o  Accept the URI scheme name for permanent registration.
   o  Suggest provisional registration instead.
   o  Request IETF review and IESG approval; in the meanwhile, suggest
      provisional registration.

While the "mailing list review" (on uri-review@ietf.org) is optional, it is recommended, and was started by Art's forward of the last call request referenced above.

While many of my review comments were responded to positively, some were not. In my opinion, the widget URI scheme definition proposed, even as updated in the latest editor's draft, does not meet at least two of the criteria of RFC 4395 for permanent URI scheme registration:

-----------
"2.1 Demonstratable, New, Long-Lived Utility":

   ... New URI schemes SHOULD have clear utility to the broad Internet community, 
    beyond that available with already registered URI schemes.

In my opinion, the utility of "widget:" above "thismessage:" has not been demonstrated. Note that the requirement says nothing about whether the *specifications* for already registered URI schemes are well-written, clear, or even whether significant additional technical clarification might be needed to easly reuse an already registered scheme.  "demonstratable" means a demonstration can be made. I asked for a use case -- some case which would demonstrate that there was new utility for "widget:" over "thismessage:".  Responses discussed the manner in which my comments were made, the history of previous comments and the difficulty of interpreting the (admittedly) poorly-written specification for "thismessage:", but those things are not part of the criteria of RFC 4395. 

Is there, or is there not, any *demonstration* of clear utility, to the broad Internet community, beyond that available with already registered URI schemes? And "thismessage" in particular? In particular, can you please supply a use case.

The first suggestion that the working group consider reusing "thismessage" was made with the assumption that the working group and document editor understood the requirement for demonstratable, new, long-lived utility. My request for a "use case" demonstrating the utility of "widget" over "thismessage" was not merely "repeating the suggestion" expecting different results, it was requesting that the document be updated to meet the requirements of the registration it was intending to make.

The burden of responsibility for demonstrating new utility is on the document registering the new scheme.

I have now (again, further) elaborated why I am making the suggestion and the criteria that I think the reply must contain before it is satisfactory. Bringing this up a third time is not, as you suggested in http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/1320.html "doing the same thing yet again" (since I have elaborated my request each time in greater detail). I am "expecting different results": a sincere attempt to meet, in the registration document you are editing, the requirements of the registration it is attempting.

Doing so is none of " 1) a lack of diligence in paying attention to the outcome from the same action performed previously (i.e. a "drive-by" comment); 2) the proverbial madness; or 3) deliberate process-based obstruction."

but rather a sincere effort to help you actually accomplish what you are puportedly trying to do.  

There is a hurdle you must jump over: getting a permanent URI scheme registered. I'm trying to help you create a document that can do that. So far, I don't think you have. If you were trying to run around the hurdle, get your document approved without actually meeting the criteria, or otherwise dodge the requirements, it would be different, I will assume you're sincerely trying to follow the process.

Please edit the specification to demonstrate the new, long-lived utility; if, for some reason, you cannot demonstrate any new utility, don't register a new scheme but reuse an old one (repairing its definition if needed.) 

------------------------------
RFC 4395 Section 2.3 Well-Defined:

   In many cases, new URI schemes are defined as ways to translate
   between other namespaces or protocols and the general framework of
   URIs.  For example, the "ftp" URI scheme translates into the FTP
   protocol, while the "mid" URI scheme translates into a Message-ID
   identifier of an email message.  For such schemes, the description of
   the mapping must be complete, and in sufficient detail so that the
   mapping in both directions is clear: how to map from a URI into an
   identifier or set of protocol actions or name in the target
   namespace, and how legal values in the base namespace, or legal
   protocol interactions, might be represented in a valid URI.  In
   particular, the mapping should describe the mechanisms for encoding
   binary or character strings within valid character sequences in a URI
   (See Section 2.6 for guidelines).  If not all legal values or
   protocol interactions of the base standard can be represented using
   the URI scheme, the definition should be clear about which subset are
   allowed, and why.


In my opinion, the registration document does not meet the criterion: "The description of the mapping must be complete", in at least two ways.

1. A "description of a mapping" that allows syntactic components (authority and query) whose use is not defined but, rather, reserved for future, is not "complete". It isn't "complete" exactly because it leaves part of he mapping undefined and allows that part of the mapping to be defined later.

Complete is antithetical to "reserved for future use". There may be reasons in SOME specifications to reserve some values or components for future use, but this kind of future definition is *not* compatible with the requirements for a permanent URI scheme registration. The "widget:" authority and query components do not participate in the mapping from a widget URI to a resource, and so the description is not "complete".

2. The "description of the mapping" is not "in sufficient detail so that the mapping in both directions is clear." In this case, the word "clear" is used in the sense of "easily understood; without ambiguity: clear, concise answers."

A "clear" description would be something that someone consulting the specification can read and determine facts about the mapping without having to resort to reading a large number of other documents, reverse-engineering complex algorithmic descriptions, or obtaining additional background information.

You may, in fact, believe that the mapping is adequately or unambiguously defined by some combination of documents and passages that you cite in your email, but, your explanation lead me to believe that the definition is not "without ambiguity" and in any case, the description of the mapping is not "easily understood", both of which are required for it to be "clear".

For example, I don't think all operating systems consistently use the same normalization for file names; some use combining characters and others may use precombined characters. If Widget packages are expected to be produced with ordinary ZIP tools, a codepoint-by-codepoint comparison of Unicode characters (or a byte-by-byte comparison UTF-8 characters) will not produce a mapping that is compatible or will not fail if a package is unzipped and rezipped. Does the mapping allow for matching URIs vs. file names with differences between with combining characters and combined characters? Or not?  Where is the "clear" definition of how this case is handled?  

In a recent email message, you wrote: "The Widget P+C specification states that it is recommended to use UTF-8 for the file name field of the local file header of a file entry. One may indeed be able to use something else, and user agents may indeed be able to do something with that, but really all bets are off.". A mapping which has situations where "all bets are off" is not "clear"; it isn't "without ambiguity". How is the mapping performed if the ZIP package _doesn't_ use UTF-8?

I think these problems in lack of clarity can be fixed, but that doing so requires some significant editing of the registration document. If you want to meet the criteria for registering a permanent URI scheme, you should provide a clear description of how URI path names are matched to file names in the ZIP package. The current reference to  http://www.w3.org/TR/widgets/#rule-for-finding-a-file-within-a-widget- is *not* clear in the sense of "easily understood". Maybe W3C is willing to publish documents that are not "clear", but that is the requirement here.

============
Summary: please review RFC 4395 and adjust http://dev.w3.org/2006/waf/widgets-uri/ so that it actually meets the criteria for new permanent URI schemes. 

I have done commenting on this document and its replies. I am not a gatekeeper or the Designated Expert for URI schemes. If, after reviewing RFC 4395, you need any further explanation of the criteria for new permanent URI schemes, please ask on uri@w3.org; if you want further evaluation of whether the widget URI scheme document meets the registration criteria, please ask on uri-review@ietf.org.

Larry
--
http://larry.masinter.net

Received on Friday, 18 December 2009 23:21:12 UTC