Re: The possibilities for identifier resolution

On Sat, Jun 16, 2001 at 12:02:56PM -0700, Tim Kindberg wrote:
> At 05:56 PM 6/15/01 -0700, Roy T. Fielding wrote:
> >So, regarding the issue at hand, there are only three possibilities:
> >
> >    1) the mechanism of contacting the naming authority is defined by
> >       the URL scheme, as is the case for http (HTTP via TCP) and https;
> 
> You speak of contacting a naming authority when what is needed is to 
> contact a binding authority (one that knows bindings from the identifier to 
> (addresses of) resources) -- and that's not necessarily the same, even 
> though it is the same in http. Naming authorities mint and (usually) bind 
> names; others can bind those names, too.

I was referring to naming authorities in the sense of RFC 2396.  I don't
find that other distinction useful -- all bindings are names, all names are
bindings, and only the manager of a namespace can be authoritative about
whether the binding of name --> resource --> representation is valid.

> >    2) the mechanism is encoded as part of the authority component, just
> >       as the TCP port number is defined in many schemes; or,
> 
> Do you have an example of such a mechanism in mind? I don't see how it 
> could encode more than a name or address where such a mechanism is 
> implemented and a protocol for talking to it -- in which case we're back at 
> (1).

I was only referring to the contact protocol stack, just as "http" URLs
imply that the port number (defaulting to 80) is TCP even though HTTP can
be transmitted over many different transport protocols.  An example would be

    http://example.com:scp.tcp.8000/foo
    http://example.com:sctp.80/foo

which modifies the authority syntax to indicate other transports than TCP.
In general, though, I feel that is less readable than new scheme names.

Received on Monday, 18 June 2001 01:31:47 UTC