Re: RFC2518 ambiguity on creationdate/lastmodifieddate

(I've seen the whole thread on this topic; this just seems to be the 
most appropriate message to respond to...)

On Thursday, February 7, 2002, at 09:54 AM, Clemm, Geoff wrote:

> 2518 is at best ambiguous, and a worst, contradictory on this topic.

Amen.

>
> I would vote for (a) property not found.

So do I.

>
> (b) is a possible interpretation, but an empty value
> violates the DTD for this property.
> The comment about "mandatory properties" in section 7.4 is not
> very useful, because "mandatory properties" is never defined in 2518.

Actually I believe this language in section 7.4 is causing problems all 
over the place, and should become an issue in its own right (unless it's 
already in the lock-null resource issues elsewhere).  As far as I can 
tell, it's the only place where the notion of "having no value" is 
suggested as a possibly different from and preferable to "not 
existing".  The problem is this language

...Additionally the lock-null resource MUST have
    defined on it all mandatory DAV properties.  Most of these
    properties, such as all the get* properties, will have no value as a
    lock-null resource does not support the GET method.

First of all, as Geoff points out, there is no definition of "mandatory" 
properties anywhere.

Second, this offhand "MUST have defined on it all mandatory DAV 
properties" is really bad language for a spec: the lock-null resource is 
either a resource (in which case the spec says elsewhere what MUST be 
true about it) or it's not (in which case this section should say 
explicitly how it MUST behave).

Finally, the sentence starting "Most of these properties..." contradicts 
the example in 8.1.2, where a resource that doesn't support GET 
explicitly doesn't have the get* properties.  I very much think the 
phrase "will have no value" was simply a think-o, and was meant to mean 
"will not be present on the resource".

I really think we need to exorcise this language from the spec, and if 
we do there's no reason that I can see not to have (a) be the proper 
response when a specific property that's not present is asked for by 
name.  This includes creationdate, which says in its description:

The creationdate property should be defined on all DAV
    compliant resources.  If present, it contains a timestamp of the
    moment when the resource was created (i.e., the moment it had non-
    null state).

     dan

P.S. Yes I know that my own company's products are not consistent in 
their notions of what responses are appropriate for "mandatory" 
properties.  But I don't think this paticular one is an issue where 
backwards-compatibility concerns should block fixing this 
ambiguity/self-contraduction in the spec: it may just be that older 
clients (some of which are Adobe's) will complain (hopefully not break) 
until they get upgraded. -d.

P.P.S. I know there was discussion about the "empty vs. missing" 
property issue earlier, at least on dav-dev, but I don't have access to 
the archives right now.  Do we have an issue about this already? -d.

Received on Wednesday, 13 February 2002 13:09:11 UTC