Subject: Re: [Uri-review] New icon URI scheme vs new URN namespace

From: Graham Klyne <[email-masked]>
Date: Tue, 18 May 2010 11:04:13 +0100

I just realized that I've fallen off the URI-review mailing list, so I missed 
some of this discussion as it happened.

Unfortunately, I think the discussion of URN "persistence" has somewhat 
distracted attention from the primary point of discussion:  what is the 
preferred form of URI for identifying an icon?

Three suggestions have been made:
1. new icon: scheme
2. http: URI with special domain
3. urn namespace

Approach 1 is clearly easy to implement, but IMO falls foul of the concern noted 
in RFC 4395 section 2.1 (http://tools.ietf.org/html/rfc4395#section-2.1): "New 
URI schemes SHOULD have clear utility to the broad Internet community, beyond 
that available with already registered URI schemes.".  I think this qualifies as 
an element of the guidance that has been requested.

Approach 2 is, prima facie, a preferred route for the web/W3C community's 
preference for using http: URIs (e.g. per 
http://www.w3.org/DesignIssues/LinkedData.html).  But in this case, I think it 
could be an inappropriate overloading of http: semantics, as the proposed icon: 
scheme explicitly defines retrieval semantics that are at variance with defined 
http: retrieval semantics.

I would suggest this application is an appropriate use for approach 3.  From a 
philosophical perspective, it broadly matches the goals of URNs.  From a 
practical implementation point of view, I think the implementation should be 
very little changed from an implementation of the proposed icon: scheme.

#g

---

From: David Booth <[email-masked]>
Date: Tue, 18 May 2010 09:54:48 -0400

On Tue, 2010-05-18 at 11:04 +0100, Graham Klyne wrote:
> [ . . . ]  what is the 
[ . . . ]
> http: retrieval semantics.

No, the retrieval semantics would not be at variance with http:
retrieval semantics any more than *caching* is at variance with http:
retrieval semantics.  Presumably, there would be one authoritative
version of each icon, right?  (Otherwise, what's the point in defining
them?)  If the *authoritative* version is identified by an http: URI,
but a persistently *cached* version is normally displayed directly from
inside the user's browser, this seems to me that it would work *very*
well with existing semantics and standards.  And I believe it meets the
objective of having standard, URI-named icons that are display directly
from the browser (without having to retrieve them over the network).
Just think of the browser's treatment of the icons as long-lived,
persistent caching.

-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

---

From: Graham Klyne <[email-masked]>
Date: Wed, 19 May 2010 06:58:46 +0100

> Just think of the browser's treatment of the icons as long-lived,

I did consider that, but I think the intent of the spec is to allow the browser 
to choose an icon image appropriate to the platform, which could not be achieved 
by simple caching.  That is, no *authoritative* version for each icon.  I 
suppose one *could* think of such cacheing as being user-agent-dependent (hence 
Icons retrieved to suit the browser+platform), but this feels to me like it's 
twisting the circumstances to fit a preference.  (Also, I'm not sure that 
user-agent-sensitive cacheing is allowed, and if so I suspect it's not widely 
implemented).

OTOH, an advantage of using HTTP is that it could be supported in browsers that 
don't recognize the special form of icon URIs, which is a moderately compelling 
argument.

I think one may need to review the original end-requirements that the icon spec 
is intending to address to make a fully rational choice.

#g

---

From: David Booth <[email-masked]>
Date: Wed, 19 May 2010 10:44:00 -0400

On Wed, 2010-05-19 at 06:58 +0100, Graham Klyne wrote:
> by simple caching.  That is, no *authoritative* version for each icon.  

Okay, so I guess instead of considering it to be the "authoritative"
version of an icon, it should be considered the nominal or "fallback"
version, and the actual version that is displayed may be platform
dependent.

> I 

But browsers normally do their own local caching, and that certainly is
user-agent-specific.

> don't recognize the special form of icon URIs, which is a moderately compelling 

Yes, it provides a nice fallback.

> is intending to address to make a fully rational choice.

Is there a document that describes the requirements or intent more
fully?
http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-uri-scheme-00.html
is a bit sketchy in this regard.

---

From: Graham Klyne <[email-masked]>
Date: Thu, 20 May 2010 07:34:59 +0100

> But browsers normally do their own local caching, and that certainly is

The *cache* may be UA-specific, but I'd still expect the cache behaviour to 
follow HTTP specifications.  I don't think a browser that says "I know this 
http: URI and I know what I want it to retrieve" falls within what is sanctioned 
by HTTP.

#g
--

---

From: David Booth <[email-masked]>
Date: Wed, 26 May 2010 10:08:00 -0400

> http: URI and I know what I want it to retrieve" falls within what is sanctioned 

Yes, I think it does bring up an interesting question: how much leeway
should a browser have in the way it renders an image?  Certainly a
browser is permitted to degrade an image when the image is rendered, as
different browsers will be able to render the image identically.
Should a browser *also* be permitted to substitute a different image
that it has locally cached?  

Certainly we wouldn't want browsers to *arbitrarily* substitute
different images.  But in this case local substitution is licensed
because it is the explicit intent of how these images were designed to
be used.  So I don't think one would be violating the spirit of the HTTP
specs to handle it this way.  And it would be a simple and fairly
elegant way to do it, since it doesn't require any new URI scheme *and*
it provides a nice fall-back mechanism to display a default image if the
browser doesn't support this feature.

---

From: Graham Klyne <[email-masked]>
Date: Thu, 27 May 2010 10:44:00 +0100

David, you say "But in this case local substitution is licensed..."

This feels problematic to me.  How is a user-agent to know that such 
substitution is licensed? How is anyone to know that substitution is licensed? 
Where's the "follow-your nose" principle at work here?

In this case, I think the potential cost of confusion arising from stretching 
HTTP in unusual ways exceeds the cost of not using HTTP.

#g
--