Subject: RE: Issue: URI_URL, proposed changes

From: "Larry Masinter" <[email-masked]>
Date: Wed, 10 Jul 2002 16:05:32 -0700

I would like to -- but am having trouble -- extracting from
this discussion a set of requirements that a revised RFC 2396
URI specification would need to meet.

What about the usage of the terms URI, URL and URN do you
actually need?

In what way does the definition of these terms affect the 
WebDAV specification? Most of the terminology is really just
advisory.

Another alternative would be to establish specific WebDAV terminology
and then define that terminology in terms of the various URI
RFCs.

Stefan Eissing wrote on June 27:

> As an addendum to this: there is work in progress on a new
> version of RFC 2396, which should also include clarifications
> about the usage of terms URI, URL and URN - among other things.
> 
> I think Larry Masinter has taken the lead on this activity and
> I would consider it prudent to align the wording of a future
> 2518 with his findings. Maybe Larry can give us a hint at his
> schedule?
> 
> //Stefan
> 
> Am Donnerstag den, 27. Juni 2002, um 00:42, schrieb Julian Reschke:
> 
> >
> > I think it is a good idea to delay this change. The whole
terminology needs
> > to be checked carefully if we update the draft to refer to RFC2396
rather
> > than RFC2068 (because the *meaning* of the term "URI" changed
between the
> > two RFCs!).
> >
> > Some more comments inline.
> >
> >>  - Change to refer to URL whenever we refer to the address of a
collection
> >> or resource.  This replaces the definition of "Member URI" with
"Member URL"
> >> in the Terminology section, and replaces URI with URL in the
definition of
> >> that.  Same with "Internal Member URI" to "Internal Member URL".
Many other
> >> instances of URI will be replaced with URL according to this new
terminology
> >> approach.  E.g. throughout sections 5.2, 5.4, 7.5, 8.1, and 8.10.3
.
> >
> > When 5.4 refers to source URIs, it needs to continue to do so.
Source
> > resources may not be HTTP resources at all.
> >
> > 8.1:
> >
> > "Each response XML element MUST contain an href XML element that
gives the
> > URI of the resource on which the properties in the prop XML element
are
> > defined"
> >
> > needs to be fixed in that the DAV:href element must be defined to be
a "URI
> > reference to be resolved relative to the request URI" (1). If we
require a
> > URI (or URL), we wouldn't be allowed to return absolute URI
references such
> > as "/collection/resource" (this isn't syntactically a URL or URI).
> >
> > 8.10.3: don't agree - resources may have alternate URIs which do not
happen
> > to be URLs.
> >
> >>  - Change the language to refer to what the Destination header
contains as a
> >> URL, not a URI.
> >>
> >>  - Continue to refer to URI when discussing lock tokens. E.g.
section 6.3,
> >> 6.4
> >>
> >>  - Continue to refer to the "Request-URI" as that is the way the
address in
> >> the first line of a request is named.
> >>
> >>  - Continue to refer to tokens in the IF header as URIs.
> >>
> >>  - Continue to use URI in section 9.7, where the Status-URI
response header
> >> is defined to contain a URI.
> >
> > I think that's a section that we may have to remove anyway (issue:
> > INTEROPERABILITY_OF_102PROCESSING_STATUS_DEMONSTRATED).
> >
> >>  - Continue to define the <href> element in section 12.3 as
containing a
> >> URI, because to do otherwise would change the specificaiton, not
clarify it.
> >
> > Actually, this needs to be fixed. The definition should refer to
RFC2396,
> > and use the term "URI reference".
> >
> >> Likewise for <src>, <dst> and <owner> elements.
> >>
> >>  - Continue to define the property name as a URI in section 16.
> >
> > As mentioned before, properties do not have URIs (at least there's
no
> > one-to-one mapping unless we define it ourselves). The entire
paragraph in
> > section 16 needs to be removed or rewritten.
> >
> >>  - Continue to use the term URI in IANA considerations, where the
property
> >> name and lock token URIs are discussed.
> >
> > Again -- needs to be fixed.
> >
> >>  - Continue to use the term URL as in "HTTP URL Namespace" (e.g.
section
> >> 5.1).  Continue using the term URL wherever it is used.
> >>
> >> I will not be able to get this done by the draft deadline (Monday)
since I'm
> >> taking a long weekend to celebrate Canada Day ;)  But I'll gather
the
> >> feedback after that and incorporate it later.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 31 Jul 2002 15:10:27 -0400

According to RFC2518, the primary purpose of the source link is
specifically that it "identifies the resource that contains the
unprocessed source of the link's source" (RFC2518, 13.10).
Furthermore "there is typically only one destination (dst) of the
link, which is the URI where the unprocessed source of the resource
may be accessed."  Thus it not only identifies the unprocessed source,
but it typically allows you to access it at that URI.

Furthermore, in the section 5.4 motivating the DAV:source property, it is
stated: "if remote editing of the source resource(s) is desired, the
source resource(s) should be given a location in the URI namespace."
This provides further motivation for understanding the DAV:source
property as intended to identify the location in the URI namespace for
editing.

So perhaps this just a question of guidance to a DAV:src implementor:

- Best: Provide an authorable URL (where of course both READ and WRITE
privileges are controlled by the ACL of the resource at that URL)

- Better than nothing: Provide a URL, where you can at least view the 
unprocessed source, or information about the unprocessed source.

- Just slightly better than nothing: A URI that identifies the unprocessed
source, but does let you either access it there (either for READ or WRITE).

Cheers,
Geoff

-----Original Message-----
From: Roy T. Fielding [mailto:[email-masked]]

>> In order to author a resource via the DAV:dst URI,
>> minimally, you have to locate the resource (i.e. the
>
> I don't agree that it's a requirement that the resource being referred to
> must be authorable. For a server, it's almost impossible to decide which
> kinds of URIs are useful to an authoring client. So I wouldn't restrict 
> them
> at all.

Right.  It would also be useful to be able to tell the authoring
client which sources are not authorable by them, but the best we can
do is give the client a URI that they may or may not be able to author.
The primary purpose of the source link is to provide metadata about
the resource to the user of the authoring client.

Cheers,

Roy T. Fielding, Chief Scientist, Day Software
                  ([email-masked]) <http://www.day.com/>

                  Chairman, The Apache Software Foundation
                  ([email-masked])  <http://www.apache.org/>

---

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 31 Jul 2002 15:25:21 -0400

Arghh.  Bad proofreading ... 
Below it should say "DAV:source implementor", not "DAV:src implementor",
and more significantly (although probably obviously), it should say:
"but does not let you access it there (either for READ or WRITE)", not
"but does let you either access it there (either for READ or WRITE)".

Sorry about that.

Cheers,
Geoff

-----Original Message-----
From: Clemm, Geoff [mailto:[email-masked]]
Sent: Wednesday, July 31, 2002 3:10 PM
To: 'Webdav WG (E-mail)'
Subject: RE: Issue: URI_URL, proposed changes

Cheers,
Geoff

-----Original Message-----

Cheers,