Subject: RE: Interoperability for DAV:ishidden?

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 5 Sep 2002 14:53:30 -0400

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:[email-masked]]
Sent: Thursday, September 05, 2002 2:35 PM
To: [email-masked]
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" <[email-masked]>
To: "Eric Sedlar" <[email-masked]>; "Julian Reschke"
<[email-masked]>; <[email-masked]>
Sent: Thursday, September 05, 2002 11:32 AM
Subject: RE: Interoperability for DAV:ishidden?

> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Eric Sedlar
> > Sent: Thursday, September 05, 2002 8:12 PM
> > To: Julian Reschke; [email-masked]
> > 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
>
>

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 5 Sep 2002 15:53:11 -0700

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

> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Thursday, September 05, 2002 11:54 AM
> To: [email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 6 Sep 2002 10:35:31 +0200

> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Friday, September 06, 2002 12:53 AM
> To: [email-masked]

Well, that's a property of *all* URIs :-)

> working groups too, I imagine.

Yes.

I think a UUID based URI scheme is what we need, and we should NOT define
this in a WebDAV RFC (like it happened for "opaquelocktoken:"). Instead, a
separate RFC should be authored, finally defining the URN "uuid" namespace.

Note that "urn:uuid:..:" is already in use by published software, yet the
URN namespace has *not* been registered (see http://uri.net).

> "guid:" URI will respond with the correct state, etc.

I don't understand that. How do you apply an HTTP method to a non HTTP-URL?

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

I'm not sure what this is good for. The binding draft requires a unique URI
for each resource that will never change and will never be assigned again.
IMHO,

- servers should be completely free in choosing a URI scheme for that URI,
as long as it has the desired properties

- in particular (like Geoff said), a server can choose to generate URIs with
these properties inside it's own URL namespace, in which case HTTP methods
can be applied to that URI -- but I don't think it makes sense to *require*
this

If we really need a reverse-lookup (from resource id to valid HTTP URL), I'd
make that a REPORT.

Julian

---

From: "Eric Sedlar" <[email-masked]>
Date: Thu, 5 Sep 2002 14:46:56 -0700

> just makes the value of DAV:resourceid be in the HTTP: namespace.

How does an interoperable client know that it can do this?  Are 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.

> it is reasonable to require that the value of DAV:resourceid be in the
HTTP

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
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.

--Eric

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 12 Sep 2002 09:36:01 +0200

(subject updated)

> Sent: Thursday, September 05, 2002 11:47 PM
> To: [email-masked]
> 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

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

> 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.

> 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>