Subject: Newbie questions

From: [email-masked] (Alan Kent)
Date: Tue, 19 Jun 2001 14:13:43 +1000 (EST)

Hi. I am new to this list so I appologise if these are ignorant questions.
I have been reading all the WebDAV (and DeltaV) documents I can get my hands
on, but have a few issues that I do not understand.

Q1: When are null resources created? You can "lock a null resource in order
    to lock the name". Is it that if you do a lock on a name that does not
    exist as a resource, a null resource is created? Are there other ways
    that null resources can be created? The text says you lock a null resource
    to create a lock-null resource. A lock-null resource has properties and
    appears under its parent container. A null resource does not appear under
    its parent. The definition of null resource is that it is a resource
    that responds to requests, which implies that it exists.

    My guess is that any URI that is not bound to a resource is implicitly
    bound to a null resource which has no properties or any other state.
    When you lock a null resource, a lock-null resource is created allowing
    it to be placed under its parent container and have properties.
    Is this correct?

Q2: Are locks on resources or URIs identifying resources? The DeltaV
    documentation I have read I think said that locks are applied to the
    resources identified by a URL.

Q3: The MOVE documentation says that a successful MOVE on a write locked
    resource must not move the write lock. (It then talks about collections
    and locks.) If the resource being moved is locked (that is, the resource
    itself, not the collection it is in), why is the lock removed when the
    resource is moved? If the lock is applied to a URI, does this mean a
    lock-null is left for the old URI?  If the lock is applied to a resource,
    why does not the lock stay with the resource that is locked?
    Or is the text in sectino 7.7 only relating to parent collections that
    have been locked and has nothing to do with locks directly on resources?

Q4: PROPFIND in section 8.1 talks about responses and errors and multistatus
    XML elements. I have read the text several times but is confusing.
    It says servers must support returning a multistatus element. (It does not
    say that it must *always* return one, just that it must support it.) It
    then says errors must be returned as 404 *if* a multistatus element is
    returned. etc. It was not clear when a multistatus element must be
    returned - is it optional or mandatory? Related, how to know when to
    return multistatus elements in general? Examples of packet communications
    are given, but no formal request/response packet grammar is given.

Q5: MKCOL behaviour with message bodies is not defined in the standard
    (section 8.3.1) but may be "defined elsewhere". Is there any such
    defintion around? Or is the body of MKCOL not important for
    interoperability.

Q6: Is there any clear definitative list of which properties are "live"
    properties? My understanding that any property that is not a live property
    is a dead property, therefore if I used a property name such as DAV:xyz
    which is currently not defined, its dead, but later if DAV defines xyz,
    then it would suddenly become live. I assume the protection here
    is that I should never use DAV: because its a DAV namespace.

Q7: DELETE is defined to delete a non-collection resource, removing all URIs
    to that resource, not just the URI passed to the DELETE command
    (section 8.6.1). Other sections such as MOVE and COPY talk about deleting
    the destination. To me this therefore means that if /foo/a and /bar/a
    are bound to resource R1, then a COPY with overwrite to /foo/a will delete
    the URIs /foo/a and /bar/a and resource R1 then create a new resource R2
    and only bind /foo/a to the new resource R2. Or should /foo/a and /bar/a
    both bind to R2? I noticed that DeltaV changes the DELETE semantics
    relating to versioning.

Q8: In DeltaV, versions are given stable URLs such as /his/73/vr/1. Should
    these URLs be made visible via containers? Ie: should /his be a container,
    and /his/73, and /his/73/vr? Or are these URLs hidden from containers?
    My understanding that there is no standard for "/his", its whatever the
    system chooses. It just seemed a potentially very expensive operation to
    get a listing of the contents of "/his" as a container since it would
    contain a child container for *every* versioned resource history resource.

A short background - we have a document management system are trying to
work out how hard it is to support first DAV and then DeltaV. The document
management system uses the DMA versioning model, hence any experiences
of relating DeltaV to DMA would also be appreciated - although this is
probably the wrong list for DeltaV questions.

Thanks for any help people can provide. I relise mail with lots of questions
can be a pain, but it was either that or send in lots of separate ones
(which I find worse)! Hopefully there are simple answers to the above.

Alan Kent

---

From: "Tim Ellison" <[email-masked]>
Date: Tue, 19 Jun 2001 16:54:54 +0100

[email-masked] (Alan Kent) wrote:
>     exist as a resource, a null resource is created?

When you do a LOCK on a null resource then a lock-null resource is created.

>     Are there other ways

I also find this confusing, and I posted a message in response to Jim
Whitehead's explanation which explains my confusion.  If I get a reply it
may answer both our questions :-)
(see
http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0285.html)

>     bound to a null resource which has no properties or any other state.

Not _any_ URI, but any URI where the immediate parent collection already
exists.

>     it to be placed under its parent container and have properties.

You are as close to understanding it as I am :-)

>     resources identified by a URL.

Essentially both.  The lock applies to the resource (you cannot change its
content or dead properties) and to the internal members along the URI path
(you cannot remove or rebind those members i.e. by DELETE or MOVE or COPY)
so that the resource cannot disappear out from under you.

Caveat: I've built my own mental model of how this works because, IMHO,
RFC2518 does a poor job of describing it.  I stand to be corrected ...
better still I'd sit to have it explained clearly to me.

>     resource is moved?
>     If the lock is applied to a URI, does this mean a

See http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html

>     are given, but no formal request/response packet grammar is given.

I agree that this text is confusing.  FWIW my rule of thumb is that if the
status code applies _only_ to the resource at the request-URI then 207
Multi Status is not used (i.e. 404 Not Found, 301 Moved Permanently, and so
on).  207 Multi Status is returned when the result applies to the resource
identified by the request-URI and other resources (i.e. depth > 0) *or* the
response applies to any number of properties.

For a discussion of this topic see
http://lists.w3.org/Archives/Public/w3c-dist-auth/2000AprJun/0042.html

>     defintion around? Or is the body of MKCOL not important for

There is no such definition around to my knowledge.  I also haven't heard
of anyone using a body for MKCOL for their own devious means -- did you
have a plan?

>     properties?

Do you mean in the spec. or in the world in general?
In the spec. it is those properties whose syntax and semantics are enforced
by the server, i.e. all those in Section 13.  In the world there is no such
registry.

>     My understanding that any property that is not a live property

You are expected not to use the DAV namespace (despite what you might see
in some implementations).

>     (section 8.6.1).

Strange isn't it?!  BTW this is explicitly overruled by the bindings
protocol.

>     Other sections such as MOVE and COPY talk about deleting

I believe this is the issue OVERWRITE_DELETE_ALL_TOO_STRONG on the WebDAV
issues list http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html

>     and /his/73, and /his/73/vr? Or are these URLs hidden from
containers?

That is your choice as a server implementer.  These URLs to a version are
server generated and servers are not obliged to expose "/his/" as a
resource.

>     contain a child container for *every* versioned resource history
resource.

Agreed.

> A short background - we have a document management system are
> trying to work out how hard it is to support first DAV and then
> DeltaV. The document management system uses the DMA versioning
> model, hence any experiences of relating DeltaV to DMA would
> also be appreciated - although this is probably the wrong list
> for DeltaV questions.

Check out http://www.webdav.org/deltav/ for instructions on subscribing to
the DeltaV list.

> Thanks for any help people can provide. I relise mail with lots
> of questions can be a pain, but it was either that or send in
> lots of separate ones (which I find worse)! Hopefully there are
> simple answers to the above.

The questions were clearly written and beautifully formatted :-)
Shame about the answers.

Tim

---

From: "Hall, Shaun" <[email-masked]>
Date: Wed, 20 Jun 2001 10:05:14 +0100

Apologies for long post. Corrections please if my interpretation is wrong as
its all IMHO...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 19 June 2001 05:14
> To: [email-masked]
> Subject: Newbie questions
> 
> 

Null resources are not created, they don't exist in the first place as far
as the server is concerned. At least thats a convenient way of thinking
about them. In other words, any URL that is not bound to an existing
resource on the server is a null resource. The server detects that the
requested URL doesn't exist, and depending upon the request, will return 404
(e.g. for a GET) or whatever is appropriate.

One imperfect way of visualling this is if you tried to GET a file (on a
file system implementation), the server would respond with a 404 because it
cannot find the requested file (URL). Thus the requested URL is a null
resource. However, you could PUT the file there (assuming all
checks/permissions/etc passed).

When you lock a null resource (assuming parent existed), you get a lock null
resource (LNR), which has all the DAV properties and thus has state. LNRs
are purely to reserve the name (URL) and nothing else, in an attempt to
reduce conflict issues (as per the rest of locking). The general exected
behaviour is for a client to "create" an LNR (with a LOCK request) and then
do a PUT or MKCOL. Example, after a PUT the LNR is no longer locked (unless
its parent is infinitely depth locked) and is a "normal" resource, with
"entity data", in which you can GET it. Imagine multiple clients attempting
to perform PUTs on the same URL at the same time without LNRs.

Side note, LNRs can be returned to a null resource if server only implements
timed out locks, the timeout period expires and the server UNLOCKs the LNR -
see secs 9.8 and 7.4.

Maybe the spec could be better phrased as the use of the word "resource" in
so many different ways seems to fuel the confusion.

>     it to be placed under its parent container and have properties.

Yep, though most DAV properties will be empty for the LNR.

>     are given, but no formal request/response packet grammar is given.

Generally, 207 if a problem exists on a resource that was not the URL in the
request e.g. "recursive" operations such as DELETE, COPY etc. For PROPFIND
though, you might get a 207 because of multiple returned
problems/values/etc.

For example, you did a PROPFIND on a null resource, you shouldn't get a 207,
but a plain vanilla 404 as its the requested URL and its more meaningful.

If the PROPFIND request contained certain properties to be returned and as
an example, some of the properties didn't exist, server would return a 207
but contain 404 inside the XML for those properties that didn't exist. For
the properties that were found, their values would also be returned in the
207. This should indicate to the client that the requested resource existed,
but some of the properties don't.

>     defintion around? Or is the body of MKCOL not important for

No definition that I know of.

In theory you could create an entire server with *one* MKCOL request e.g.
your request could create a collection which is a direct child off root, all
the descendants for the collection and all their properties. Hope your not
doing this down a 56k line :-)

> Alan Kent

Regards

Shaun Hall
Xerox Europe