RE: New RFC2518bis draft, property values after LOCK of unmapped URL

What are other people's views on this? Should live properties for which
the server doesn't have an easy value be left blank or should the
property not exist?


My reasoning was that live properties like "getcontentlanguage" should
be required, thus should exist on every WebDAV resource, even if the
value must be blank. Otherwise a server can completely omit these
properties and still claim compliance.


(Side note: If required live properties like "getcontentlanguage" can be
missing on a WebDAV resource, then we need to clarify under what
conditions they may be missing.  I'm thinking along these lines: "If the
latest client PUT request contains a Content-Language header, the value
of this header MUST be preserved in the getcontentlanguage property
value. If the Content-Language header is never provided, then the server
MAY omit this property, or it MAY calculate a value or choose a
reasonable default value.")




-----Original Message-----
From: Julian Reschke [] 
Sent: Monday, July 22, 2002 1:47 PM
To: Jason Crawford;
Subject: RE: New RFC2518bis draft, property values after LOCK of
unmapped URL


I think the standard WebDAV properties MUST reflect the values of the
HTTP entity headers one would get upon HEAD or GET. So it doesn't make
any sense to require that a value must be present, if it's purely
optional in HTTP.


For instance, if a server doesn't have a content-language for a
resource, it MUST NOT report it upon GET (see [1]): "If no
Content-Language is specified, the default is that the content is
intended for all language audiences. This might mean that the sender
does not consider it to be specific to any natural language, or that the
sender does not know for which language it is intended.". So: if you
don't have the language, don't report it. A blank value is an illegal
language tag.



	-----Original Message-----
[]On Behalf Of Jason Crawford
	Sent: Monday, July 22, 2002 10:04 PM
	Subject: RE: New RFC2518bis draft, property values after LOCK of
unmapped URL

	Section 4.2: Lock-null resources removed
	Text mentions: "SHOULD default to reasonable, or reasonably
blank, values
	for other properties like getcontentlanguage"
	I disagree: unknown properties should be treated as not being
present (just
	like the relevant HTTP headers), NOT as blank.
	If a server creates a resource as a result of a LOCK request on
an unmapped URL, I believe Julian is suggesting that if there is any
doubt about what the property value should be, the property should not
be created rather than set to NULL.
	Julian, did I get that right? Would you care to elaborate? What
about a few examples?
	Phone: 914-784-7569,

Received on Tuesday, 23 July 2002 18:05:51 UTC