Re: http, the whole http, nothing but http

I'm not sure about the utility of this discussion, but what the heck...

I partly agree with what you say here, but I don't think that makes Roy wrong.

I think there are many different ways of specifying "dereferencing" of a 
URI, and to the extent that when followed they all faithfully explain 
observable behaviours then they're all legitimate.  Some may be more 
useful, but that doesn't make the others wrong.

So when we talk about dereferencing a mailto: URI, I can explain that in 
terms of being supplied with a representation, and then doing something 
with that representation (which latter bit I don't think was part of what 
Roy said).  I'd suggest *an* explanation of clicking on a mailto: URI is 
that the user agent is supplied with a representation of a function that 
sends a message, and then executes it.  What representation?  I don't say, 
any more than http: says whether web pages are served as HTML or XHTML or 
something else.  Where does the representation come from?  Again, I don't 
say;  where does the representation of that described by a data: URI come from?

I don't claim that this is *the* way to define dereferencing, or the most 
useful way.  But I do think it is as coherent as other descriptions that 
might be offered.

Maybe we might agree that "supplies representations" is not a *complete* 
description of dereferencing?  (Even for web pages, they still must be 
displayed for the expected behaviour to be observed.)

#g
--

At 23:08 04/10/03 -0700, Larry Masinter wrote:

>In reply to my complaint about
>
> >Roy Fielding wrote:
> > > any URI, no matter how abstract its referent or how obscure the
> > > scheme, can be placed in the context of a dereferencing system
> > > that supplies representations of whatever is supposedly identified
> > > by that URI.
>
>Graham Klyne wrote:
>
> > I read what he said as noting that it is *possible* to treat any
>identifier
> > as dereferencable, not that to do so would always be desirable.
>
>I was complaining about "supplies representations" as a particular
>kind of mode of "dereferencing".  When you "dereference" a "telnet:"
>URI,
>you actually interact with a service. It's a stretch to call it
>"retrieving representations".  When you "dereference" a "mailto:" URI,
>you wind up sending mail to a mailbox. What is the "representation"
>that gets "retrieved".
>
>Before deciding whether it is *possible* to consider all identifiers
>as dereferencable, you'll have to define "dereferencable" in a way
>that doesn't leave the statement empty and yet covers all of the
>ways of interacting with URIs.
>
> >  As such, I
> > regard his comment not as describing a model but explaining a
>possibility,
>
>But the comment says "any URI", not just "some URIs". The model
>either admits this assertion (for any URI, of being dereferencable
>by supplying representations) or it does not.
>
> > which in turn suggests (to me) that a model that depends on
>hard-and-fast
> > distinctions between identifiers and locators doesn't always stand up.
>
>I'm not sure where this came from. I certainly don't believe that
>there can be hard-and-fast distinctions between identifiers and
>locators. I do think there can be general guidelines for naming
>and designing new schemes.
>
>Larry

------------
Graham Klyne
GK@NineByNine.org

Received on Tuesday, 7 October 2003 13:20:44 UTC