RE: HOW_TO_IDENTIFY_LOCK_OWNER

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
>>  Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER
>>
>>  ...
>>
>>  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 
clients.

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

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