W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002


From: Daniel Brotsky <dbrotsky@adobe.com>
Date: Tue, 29 Jan 2002 11:12:32 -0800
Message-Id: <p05101203b87c9aeb001a@[]>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: <w3c-dist-auth@w3c.org>
At 9:26 AM +0100 1/29/02, Julian Reschke wrote:
>  > From: w3c-dist-auth-request@w3.org
>>  [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
>>  Sent: Tuesday, January 29, 2002 1:42 AM
>>  To: Daniel Brotsky; Julian Reschke
>>  Cc: Jason Crawford; Clemm, Geoff; w3c-dist-auth@w3c.org; Julian Reschke
>>  ...
>>  So my position is pretty similar to Dan's: make it clear that DAV:owner is
>>  owned by clients, and don't add any way for servers to insert lock owner
>>  principal information.  I prefer any other extensions to DAV to be done
>>  outside the base spec since they are clearly not needed for basic
>>  interoperability and would delay Draft Standard.
>One could also take the position that we're *fixing* an interoperability
>problem. The current RFC says [1]:
>"The owner XML element provides information sufficient for either directly
>contacting a principal (such as a telephone number or Email URI), or for
>discovering the principal (such as the URL of a homepage) who owns a lock."
>Right now it doesn't, because it's format is unspecified (and examples in
>the draft are inconsistent).

My intuition is that the quoted paragraph addresses an 
interoperability "problem" that doesn't exist: client programs 
needing to contact people.  The actual interoperability problem faced 
by (at least) Adobe clients was for clients needing to contact 
clients, or more precisely: our clients use specific conventions 
about lock ownership that the spec doesn't provide for, and they need 
to keep this conventional information with the lock in a way that 
works against any server and can be discovered.

Our solution was to interpret this paragraph more along the lines of:

The owner XML element provides a way for clients to store 
owner-controlled conventional information with the lock that other 
clients can discover and make use of.

I would propose that we further clarify this with language along the lines of:

Since the possible client conventions around such information are 
beyond the scope of this specification, servers MUST NOT rewrite such 
information (i.e., the DAV:owner field must be treated as a dead 
property).  In addition, clients who make conventional use of the 
DAV:owner field SHOULD document these conventions for use by other 

>To understand the implications of adding a new field, it would be useful to
>have some idea about which timeframe we speak. Any guess how long it will
>take until a new edition could be submitted? If it's a matter of several
>months, I'd suggest adding the new element (it shouldn't hurt as long it's
>optional, well-defined, and we can demonstrate interoperability).
>[1] <http://www.greenbytes.de/tech/webdav/rfc2518.html#ELEMENT_owner>

My belief is that there are three real-life interoperability problems 
that are left unaddressed by this DAV:owner clarification and that 
would be worth adding a new element for:

1. a way for clients to specify a human-readable string that other 
clients should display in order to identify the lock owner.

2. a way for clients to specify contact addresses in known protocols 
(e.g., mailto:, http:) whereby human users can contact (or get 
information about) the lock owner (or lock purpose, etc.).

I would not be averse to adding a DAV:ownercontact field in this spec 
go-round to address this problem.  In general I'm in agreement with 
Julian that adding a new field to the lock discovery information 
would likely not be damaging to earlier clients.

Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:page-dbrotsky@adobe.com>
Received on Tuesday, 29 January 2002 14:24:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:24 UTC