Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER

From: "Jason Crawford" <[email-masked]>
Date: Mon, 28 Jan 2002 10:07:04 -0500

Julian's XLink based proposal sounds fine to me.

Dan, I assume you understand and sympathize with Geoff's hesitance to
having the server try to reveal the creator of the lock. Is there any other
info about a lock that ACL's don't provide that you feel needs to be
provided?

Geoff, Julian, are we sure we can't just define DAV:owner (rather than a
new field) more restrictively to comply with your Julian's proposal?

Lisa, Geoff, Julian, Can you think out the interoperability scenarios and
issues of Julian's proposal?  (I wasn't at the interops so I'm not familiar
with the current uses of DAV:owner and how Julian's proposal affects the
currently deployed systems and if there are transition issues.)

J.

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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 28 Jan 2002 09:34:25 -0800

> new field) more restrictively to comply with your Julian's proposal?

We can't redefine DAV: owner.  As you suggest, there are current deployed
uses of DAV:owner and there would indeed be transition issues.

> currently deployed systems and if there are transition issues.)

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 28 Jan 2002 16:11:15 +0100

> From: Jason Crawford [mailto:[email-masked]]
> Sent: Monday, January 28, 2002 4:07 PM
> To: Daniel Brotsky
> Cc: Clemm, Geoff; [email-masked]; Julian Reschke
> Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER
>
>
>

My understanding is that recent interoperability tests have shown that
existing clients WILL break if the server doesn't round-trip whatever the
client provided. So we can't restrict it.

> currently deployed systems and if there are transition issues.)

My proposal shouldn't affect interoperability because it's a new child
element.

---

From: Daniel Brotsky <[email-masked]>
Date: Mon, 28 Jan 2002 16:06:51 -0800

So I have followed Julian's advice and gone back and reviewed all the 
mail around this.  Here's my interpretation:

1. There are only 5 people participating in this thread (Geoff, 
Julian, Lisa, Jason, and me).  I note this only because it's 
worrisome to me to declare "consensus" based on such a small 
discussion.  Also because it explains why the rest of this analysis 
actually names names, so to speak :^).

2. All 5 of us seem to feel that leaving DAV:owner alone and under 
the control of clients is the only thing that will allow existing 
clients to keep working.

Conclusion: I think we have "consensus" that DAV:owner should be 
under client control and that the spec should state this.

3. Geoff and Julian seem to feel that we should "deprecate" 
DAV:owner, which I think means they want the spec to say that clients 
should not rely on the DAV:owner field.  They argue that clients can 
not "interoperate" using this field because its value is unspecified. 
I strongly disagree with this, for reasons I've often stated but will 
reiterate briefly: I claim that having a "guaranteed dead" property 
writeable as part of a LOCK request is a very valuable feature of the 
protocol precisely because it allows clients to interoperate using 
conventions *outside* of the protocol.

Conclusion: We don't have consensus about deprecating DAV:owner.

4. Lisa and I (more me than her, but maybe I convinced her :^) both 
seemed to feel that clients should have a way of asking about who 
owns a lock in order to figure out whether a discovered lock is owned 
by them.  Geoff replied that, since we're leaving DAV:owner in the 
hands of the client, then presumably a client could use that field to 
determine whether he owned a lock.  I take from Lisa's lack of 
response that she found that argument persuasive.  I certainly did. 
(Geoff and maybe Julian also seemed to feel strongly that it's 
insecure for servers to give out this kind of information, but while 
I agree with this I don't think that argument is on point: we weren't 
talking about mandating it, just allowing it.)

Conclusion: We have consensus that servers shouldn't have to tell 
clients who owns locks, and further that we don't need a standard way 
for clients to ask about this.

5. Geoff and Julian both seem to feel strongly that there should be 
some protocol-specified way for clients to communicate conventionally 
with each other about who owns a lock.  They seem to feel that this 
was what DAV:owner was intended to be about in the first place, so I 
think they are both agreed about introducing DAV:lockowner as such a 
thing and deprecating DAV:owner.  Jason seemed to find this proposal 
sensible given the conclusion of (2).  Neither Lisa nor I have had 
anything to say about this.

Conclusion: There's a proposal on the table to add DAV:lockowner 
that's probably linked to the proposal to deprecate DAV:owner.  But 
there's been essentially no discussion of it, even by the 5 people 
who've been active so far.

Bottom line: At this point, I think our two points of consensus are:

1. DAV:owner is owned by clients, and the spec should say this.

2. We are not going to add a way for clients to ask who owns a lock.

I would suggest we close out this issue on that consensus.  I have no 
objection to adding an issue about adding a DAV:lockowner field 
(based on Julian's proposal), but I have not seen any evidence that 
actual clients are asking for this; it seems to be more of a hygiene 
issue than anything else.

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:[email-masked]>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 28 Jan 2002 16:41:37 -0800

> issue than anything else.

I should also make it clear that there are two possible ways to add a
feature like DAV:lockowner:
(a) Add it to the base DAV spec when we rewrite it to go to Draft Standard.
Then we would be delayed getting an RFC number with Draft Standard until we
prove interoperability with DAV:lockowner

(b) Add it to a DAV extension.

When it comes to adding features, I much prefer (b).  We can delete and
disambiguate features in RFC2518 and move toward Draft Standard status
quickly, based on much existing proven interoperability.  We cannot add
features with the same speed because it requires us to wait for product
implementors to get around to doing the new feature.

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.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 29 Jan 2002 09:26:24 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Tuesday, January 29, 2002 1:42 AM
> To: Daniel Brotsky; Julian Reschke
> Cc: Jason Crawford; Clemm, Geoff; [email-masked]; Julian Reschke
> ...

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

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>

---

From: Daniel Brotsky <[email-masked]>
Date: Tue, 29 Jan 2002 11:12:32 -0800

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

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