W3C home > Mailing lists > Public > www-tag@w3.org > March 2005

RE: [schemeProtocols-49] New issue on relationship of URI schemes to protocols and operations

From: Larry Masinter <LMM@acm.org>
Date: Tue, 15 Mar 2005 21:24:23 -0800
To: noah_mendelsohn@us.ibm.com
Cc: www-tag@w3.org
Message-id: <0IDF001IHJ0NWV@mailsj-v1.corp.adobe.com>

> Right, although I think there may be some subtlties in the case where you 
> do own a DNS name, have never in history deployed an ftp server at that 
> address, have chosen to assign names there using the ftp scheme names, and

> for whatever reason are serving representation using the HTTP protocol. 

The fact that people continue to employ this kind of reasoning
is the reason I argued against the "URI ownership" terminology
in WebARCH.  The idea that 'ownership' of a DNS name might allow
you to say "well, when I say ftp://mydnsname.com/blah, I don't really
mean 'use the ftp protocol to connect to mydnsname.com and access
'blah', I really mean 'use the http protocol' -- well, it's nonsense.
It's a Humpty Dumpty kind of argument, where words mean whatever
the speaker wants them to mean, outside of any intrinsic or social
meaning.  URIs have meaning that is delegated through the scheme
definition, and resource owners can merely manipulate the resources
so that the URIs match what the resource owners might want the
URIs to connect to.

> I think you have to tell a slightly more subtle story along the lines of:
> own the DNS name and the fact that I (a) could have deployed 
> an actual ftp server for this resource and (b) warrant that in any case I
will not 
> deploy what I consider to be a different resource using ftp at that same 
> URI name, together license my use of the ftp scheme for this resource." 
> Agreed?

Disagree. There is no requirement to warrant anything. The URI
"ftp://mydnsname.com/blah" has a meaning, no matter what the
"owner" of "mydnsname.com" wants it to mean. The URI 
"http://mydnsname.com/something/blah" has a different meaning.
The "owner" of "mydnsname.com" may be able to arrange for there
to be a FTP server and for it to respond to requests (or not),
and for there to be an HTTP server on the same host, and for
it to reply with similar state/activity given similar requests,
but the "owner" isn't changing the meaning of the URIs, the owner
is changing the state and behavior of the resources.

> I also think there is something squishy about the claims that operations 
> follow from the URI scheme, but we can serve resources from one scheme 
> using another.

I think the only squishy part here is the idea of "serve resources
from one scheme using another". Two different URIs with different
schemes are different resources, although they may share some 
resource state in common.

>   It feels like we need to tell a story about the operations 
> either being the same or somehow mappable.

I don't see this. The operations available should be part of
the scheme definition. In some cases we've been sloppy about
enforcing this. Different schemes admit different operations.

>  Not quite sure what that story 
> should be (and I'm not the best expert in these areas in any 
> case, which is among the reasons I cc:'d you.)

I think the best thing to do is to be more careful about
separating "meaning" from "possible action".

> > I suggest you include the uri@w3.org mailing list
> > (both IETF and W3C URI interest group) in
> > discussions, if any.
> I tend to feel that long-term cross posting is messy, and this is likely 
> to be a protracted discussion.   That said, it's OK with me if other tag 
> members agree.  I'll hold off for a day or two, and if we decide to do 
> that, I'll send uri@w3.org an intro note with links to correspondence 
> already missed. OK? 

There are lots of ways of accomplishing collaboration, e.g.,
summarize the discussion from one list in a separate posting
on the other, and vice versa.

The main request is to not assume you have "rough consensus" merely
through a discussion on one list without consulting the other.

Received on Wednesday, 16 March 2005 05:24:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:08 UTC