DAV:resourceid

(subject updated)

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Thursday, September 05, 2002 11:47 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: Interoperability for DAV:ishidden?
>
>
>
> > I still don't see your objection to Julian's original proposal,
> > i.e. if your server can (or is willing to) allow a client to operate
> > directly on the resource identified by the DAV:resourceid, then it
> > just makes the value of DAV:resourceid be in the HTTP: namespace.
> >
>
> How does an interoperable client know that it can do this?  Are

It parses the URI and determines whether it's a HTTP: or HTTPS: URL.

> you going to
> allow an optional <href> tag in DAV:resourceid so that the client can know
> to do this?  This just puts the burden on the client writer.

According to the expired bindings draft, DAV:resourceid happens to have the
DAV:href format anyway ([1]).

> > There is value in a DAV:resourceid, even if it isn't something a
> > client can use to directly operate on the resource, so I don't believe
> > it is reasonable to require that the value of DAV:resourceid be in the
> HTTP
> > namespace.
> >
>
> What do you feel is unreasonable?  Finding some obscure part of the HTTP
> namespace on a server to map to?  Handling requests with resource-ids?  It

For instance, you might want to assign resource identifiers that can travel
between servers. Using the HTTP scheme would make this impossible.

> seems to me that this makes resourceid simpler for simple
> repositories that
> may not have GUIDs available, as they can just use the resource's URL if
> they don't allow multiple bindings to a resource.

No, they can't. For instance, the resourceid would change if the resource is
moved. This is not allowed.

Julian

[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-binding-protocol-02.html
#rfc.section.13.2>

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 12 September 2002 03:36:34 UTC