RE: Interoperability for DAV:ishidden?

I like the idea of having a URI namespace for unique identifiers for
resources. Since we use the DAV: namespace exclusively for protocol
elements, I tihnk it's a bad idea to reuse the DAV: URI space for this
purpose. But, a "guid:" URI scheme could be very useful to us, and to other
working groups too, I imagine.

Now, a "guid:" URI is just an identifier, and is not explicitly defined to
be a locator, like a URL. However, we could easily say that each DAV server
understands how to resolve a subset of the overall GUID space, and if you
somehow know one of the GUIDs a server can resolve, a GET request on that
"guid:" URI will respond with the correct state, etc.

Just to make sure we're all on the same page, I'm proposing that in addition
to the current situation where there can be multiple URLs mapped to a single
resource:

URL (n)-->(1) resource

We would additionally have a 1 to 1 mapping of guid: URI to resource:

guid: (1)-->(1) resource

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Thursday, September 05, 2002 11:54 AM
> 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.
>
> 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.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
> Sent: Thursday, September 05, 2002 2:35 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: Interoperability for DAV:ishidden?
>
>
>
> didn't think about that problem...
>
> What I'd like to be able to do is to have a URL-based scheme for accessing
> resources by resource ID, without having to run a REPORT or
> SEARCH method or
> something to find a URL for it, especially since that will be yet another
> spec.
>
> OK, how about if we make resource IDs <href>s that are guaranteed to be
> unique?  We had to do the same thing with principals in the ACL spec to
> uniquely identify them.  So, rather than treating resource ID as an opaque
> string, we can do something with it.  On a server storing GUIDs for each
> resource, you could return:
>
> http://myserver/sys/ids/<GUID>
>
> as the string rather than just
>
> GUID
>
> --Eric
>
> ----- Original Message -----
> From: "Julian Reschke" <julian.reschke@gmx.de>
> To: "Eric Sedlar" <eric.sedlar@oracle.com>; "Julian Reschke"
> <julian.reschke@gmx.de>; <w3c-dist-auth@w3.org>
> Sent: Thursday, September 05, 2002 11:32 AM
> Subject: RE: Interoperability for DAV:ishidden?
>
>
> > > -----Original Message-----
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > > Sent: Thursday, September 05, 2002 8:12 PM
> > > To: Julian Reschke; w3c-dist-auth@w3.org
> > > Subject: Re: Interoperability for DAV:ishidden?
> > >
> > > ..
> > >
> > > What is needed is an interoperable way, given a resource ID, to
> > > operate on a
> > > resource with that ID on the server.  If the mapping between
> > > resource-ID and
> > > implementation is server-defined, we can't do that.
> Requiring the DAV:
> > > namespace to respond to these requests is probably the easiest
> > > thing to do,
> > > since this will work with other methods, like LOCK and so
> forth.  REPORT
> > > doesn't handle that case.
> >
> > Eric,
> >
> > WebDAV is an HTTP extension. There's simply no way to directly
> manipulate
> a
> > resource identified by a DAV: URI using HTTP/WebDAV. Is this
> *really* what
> > you're proposing, or am I missing something?
> >
> > Julian
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
> >

Received on Thursday, 5 September 2002 18:56:19 UTC