# Re: I-D: How Roy would Implement URNs and URCs Today

Martijn Koster (m.koster@nexor.co.uk)
Wed, 19 Jul 1995 06:54:54 +0100

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Karen R. Sollins: "Re: URI deconstructed"
- Previous message: Daniel LaLiberte: "Re: I-D: How Roy would Implement URNs and URCs Today"
- In reply to: Daniel LaLiberte: "Re: I-D: How Roy would Implement URNs and URCs Today"

    Message-Id: <9507190555.AA12059@mocha.bunyip.com>

    To: liberte@ncsa.uiuc.edu (Daniel LaLiberte)

    Subject: Re: I-D: How Roy would Implement URNs and URCs Today

    In-Reply-To: Your message of "Tue, 18 Jul 1995 17:00:27 CDT."             <9507182200.AA17553@void.ncsa.uiuc.edu>

    Date: Wed, 19 Jul 1995 06:54:54 +0100

    From: Martijn Koster <m.koster@nexor.co.uk>

In message <9507182200.AA17553@void.ncsa.uiuc.edu>, Daniel LaLiberte writes:

> > An expression is obtained only when the URL is combined with an
> > Action (aka Method) like GET. If you change the action (e.g., PUT),
> > the expression changes, but not the URL.
>
> There is an implicit GET that goes along with most URL resolution, and
> we agree that the combination is an expression.

Currently most do, yes, but that happens to be because GET is
virtually all that browsers do at the moment. I hope to see a lot more
methods being created and used, from revision control to annotations.

Then we do need names for resources to perform these methods on.

> In fact, we need a way to represent the full combination of the
> method, the URL, and any additional parameters that were used in
> resolving to the result, if that is what is being done. This full
> expression would be useful in identifying the result for caching
> purposes, for example.

This expression is probably the HTTP Request header. Note this can
potentially be quite big...

I'm not sure it can ever be more than a guess. Already you have
services keying the displayed results on other meta data such as
User-agent. Note sure how desirable this is, but there you are.

At the end of the day a request is handled by a protocol transaction
between client and server. Even an identical request might be handled
differently coming from different IP addresses. You can't shoe-horn
that into an identifier.

> > Identity and behavior are two orthogonal issues, and they must be
> > kept separate. If an identifier implies behavior, then the resource
> > cannot be referenced independent of the desired action.
>
> It's not so simple. An identifier that implies absolutely nothing
> would be useless - you would have no way to interpret it to find out
> what it refers to.

Sure, but you have implications: is a URL starts http://server/ I know I can
use HTTP to that server do whatever I want.

Putting actions into resource identifiers sounds like a bad thing for
the general case, IMHO...

-- Martijn
__________
Internet: m.koster@nexor.co.uk
X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M
WWW: http://web.nexor.co.uk/mak/mak.html

- Next message: Karen R. Sollins: "Re: URI deconstructed"
- Previous message: Daniel LaLiberte: "Re: I-D: How Roy would Implement URNs and URCs Today"
- In reply to: Daniel LaLiberte: "Re: I-D: How Roy would Implement URNs and URCs Today"