Re: HTML5 proposes introduction of new family of URI schemes

On 1/24/2012 10:57 AM, Julian Reschke wrote:
> Hmm? The programmers out there who are going to define these schemes most
> likely aren't active in W3C or IETF...

Well, I think this highlights the crux of the issue. If you believe that 
new URI schemes should be created very, very rarely, then optimizing for 
the use case where "The programmers out there" are creating them seems to 
be a mistake.

The Architecture of the World Wide Web says [1]:

"Good practice: Reuse URI schemes

"A specification SHOULD reuse an existing URI scheme (rather than create a 
new one) when it provides the desired properties of identifiers and their 
relation to resources.:

and [2]:

"One misguided motivation for registering a new URI scheme is to allow a 
software agent to launch a particular application when retrieving a 
representation."

RFC 4395 (Best Current Practice for URI Scheme registration) says [3]:

"2.1. Demonstratable, New, Long-Lived Utility


    The use and deployment of new URI schemes in the Internet
    infrastructure is costly; some parts of URI processing may be
    scheme-dependent, and deployed software already processes URIs of
    well-known schemes.  Introducing a new URI scheme may require
    additional software, not only for client software and user agents but
    also in additional parts of the network infrastructure (gateways,
    proxies, caches) [11].  URI schemes constitute a single, global
    namespace; it is desirable to avoid contention over use of short,
    mnemonic scheme names.  For these reasons, the unbounded registration
    of new schemes is harmful.  New URI schemes SHOULD have clear utility
    to the broad Internet community, beyond that available with already
    registered URI schemes."

I think it would be helpful to see a more detailed analysis in support of 
any claims that web+ URI schemes are intended to be used in a manner 
consistent with these Best Current Practices.

I think what's bothering me might be summed up in this way:

* The pertinent RFCs encourage the resuse of existing URI schemes. The TAG 
has also made clear [4] that there is great value in reusing widely 
deployed URI schemes, most especially http and https.

* Neither http nor https is included in the proposed whitelist, therefore 
none of the power of these client-side mechanisms is available for use with 
resources deployed in the preferred manner on the Web.

I think I'd be happier to see emphasis on an architecture that would 
emphasize use of http-scheme identifiers for, e.g. access to one's mailbox, 
with the flexibility at the client-side to have those handled by a Web 
application in a browser container, or by some native application (which 
might or might not have specialized knowledge of the particular URIs being 
used). That would give me a warm feeling that things will be deployed using 
http- or https- wherever reasonably possible. With that in place, it would 
be easier to judge whether there is incremental value in something like the 
web+ proposal, to handle other cases. My fear is that we'll see a 
proliferation of schemes like web+mailbox to identify a user's e-mail, 
rather than a more appropriate https://example.org/user/bobsmith/mailbox.

Of course, a URI like that gets you at least some Web representation when 
dereference in the obvious manner. What I think I'd like to see is a 
proposal, perhaps involving URI templates [5], that would allow me to 
select as an alternative either a native mail-reader application or perhaps 
a different Web-based application of my choice to handle 
https://example.org/user/{user}/mailbox{restofURI} (I'm not expert on URI 
Template details, but the spirit of this should be clear).

That way, we'd be leveraging the tremendous amount of deployed 
infrastructure and tooling that supports HTTP, we'd be using identifiers 
that at least >could< do something useful with garden-variety browsers that 
know nothing of new whitelist mechanisms or schemes, and we'd be giving 
users of more sophisticated client OS's and browsers the option to use Web- 
or native-applications of their choice for handling such resources.

Noah

[1] http://www.w3.org/TR/webarch/#pr-reuse-uri-schemes
[2] http://www.w3.org/TR/webarch/#URI-registration
[3] http://tools.ietf.org/html/rfc4395
[4] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html#stablelayers
[5] http://tools.ietf.org/html/draft-gregorio-uritemplate-07

Received on Tuesday, 24 January 2012 20:12:55 UTC