RE: RFC2518 issue: DAV:href format

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Vasta, John
> Sent: Thursday, February 28, 2002 7:00 PM
> To: 'Julian Reschke'; w3c-dist-auth@w3c.org
> Subject: RE: RFC2518 issue: DAV:href format
>
>
> The specific reference in RFC2518 is to the definition of "URI" in section
> 3.2.1 in RFC2068, which corresponds to the definition of
> "URI-reference" in
> section 4 of RFC2396. In both places, the definition is
>
>   [ absoluteURI | relativeURI ] [ '#' fragment ]
>
> which seems clear to me that the content of a DAV:href element
> can be either
> an absolute or relative URI.

Indeed. I got confused by the usage of "URI".

So we still need to update RFC2518:

a) refer to the current RFC,

b) don't use the term URI when what is meant is a "URI reference".

c) clarify what the base URI for resolving a relative URI reference is.

> Also, as an implementor of a mod_dav "repository provider", I can say that
> it would be difficult to construct absolute URI's in the layer of
> code which
> generates DAV:href elements, since that layer has no access to the Apache
> request info needed to construct an absolute URI.
>
> So relative URI's are desirable, both from an implementor's
> standpoint, and
> >from the fact that they reduce message size somewhat. From the above
> definitions, RFC2518 clearly allows relative URI's in DAV:href elements. I
> agree that it should be clarified what the base URI is; since all the
> clients I've looked at assume it is the request URI, then that seems like
> the right thing to say.
>
> John
>
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > Sent: Thursday, February 28, 2002 9:39 AM
> > To: w3c-dist-auth@w3c.org
> > Subject: RFC2518 issue: DAV:href format
> >
> >
> > See <http://www.greenbytes.de/tech/webdav/rfc2518.html#ELEMENT_href>.
> >
> > RFC2518 says that the contents of DAV:href is a URI as
> > defined by RFC2068
> > (which should be updated to refer to RFC2396).
> >
> > The spec seems to be consistent with this (all examples
> > include protocol and
> > authority).
> >
> > However, Apache moddav only returns relative URI references
> > (protocol and
> > authority are missing), so technically doesn't return URIs at
> > all. Microsoft
> > IIS returns correct URIs. All clients seem to be happy with both.
> >
> > So,
> >
> > 1) either Apache moddav should be fixed, or
> > 2) RFC2518 should allow relative URI references.
> >
> > *If* we go with 2), the spec will have to define which base
> > URI needs to be
> > used to resolve the URI reference to a full URI (the request
> > URI comes to
> > mind). Note that this would allow new kinds of PROPFIND responses that
> > *will* not interoperate with many clients:
> >
> > PROPFIND /foo/bar
> > Depth: 1
> >
> > ..
> >
> > <multistatus>
> >   <reponse>
> >     <href/>
> >     ...
> >   </response>
> >   <response>
> >     <href>child-of-bar</href>
> >     ..
> >   </response>
> > </multistatus>
> >
> >
> > (This could be avoided by saying that the base URI *always* is
> > "<protocol>://<host>:<port>/").
> >
> >
> >
> >
> >
> >
> >
>

Received on Thursday, 28 February 2002 13:37:04 UTC