Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 7 Feb 2002 12:54:56 -0500

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

I would vote for (a) property not found.

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

(c) violates the requirement in 8.1 that missing
property errors be reported

(d) is just obviously wrong (:-).

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 12:02 PM
To: Julian Reschke; [email-masked]
Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate

Hey everyone...

The following posting about four months ago was not answered.   Do we have
an answer?   Is this a general problem for properties?  Let's hear what you
think...

BTW... I'd like to mention, but not necessarily recommend an option.  See
(d) below.

>
> Hi,
>
> if for some reason a server doesn't have one of these timestamps for a
> resource, what should it report on PROPFIND for these properties?
>
> a) Property not found (HTTP 404),
>
> b) Empty property (this seem to be backed by the wording in section 7.4
> [1],
> but is reported as error by Adobe GoLive,
>
> c) Property silently suppressed (not reported at all) -- this
> seems to work
> with GoLive.

 d) Return a fixed but not correctly supported value.  For example, always
    respond with 1/1/1990.

>
> In addition, how should the server behaviour upon a PROPFIND/propname on
> this resource?
>
> Julian
>

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 7 Feb 2002 19:00:47 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Thursday, February 07, 2002 6:55 PM
> To: [email-masked]

Why would that be a violation?

---

From: Daniel Brotsky <[email-masked]>
Date: Wed, 13 Feb 2002 09:09:58 -0800

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

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

Amen.

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

So do I.

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