RE: HOW_TO_IDENTIFY_LOCK_OWNER

It probably is worth looking a bit harder at what exactly would be
the costs of simply recommending some standard elements to go into
the value of the existing DAV:owner element.

I assume that clients today are written to work really well when they
encounter a lock written by clients from the same vendor (since they
would have a detailed knowledge
of the structure of the information in DAV:owner), but at least
"blurt out" the information in DAV:owner when encountering a
lock from some other vendor's client.

If we were to recommend some specific sub-elements for DAV:owner,
then existing clients would be unaffected when running against
existing servers (of course), and new clients would exhibit the
desired improved interoperability when running against new servers.

It is only old clients from a given vendor running against new 
servers from the same vendor that would see a hit, if the new
standardized DAV:owner fields can't be inserted without disrupting
the ability of old clients extracting the old information. 

In particular, since it is the new *clients* that will
be inserting these new fields, if we make sure that the
location of the new standard fields is sufficiently flexible,
then the new clients from a specific vendor
might be able to append these new fields to the
information they currently write in a way
that won't disrupt the ability from old clients *from that vendor*
being able to read the old information.
 
So it might be worthwhile to first find out
if there is some way we could define the
location of the new fields such that new clients from a vendor could
can add them in without disrupting the behavior of their old clients.

If there really is no way to do this, then we could add a second
DAV:formatted:owner field instead.

Cheers,
Geoff



-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Monday, January 28, 2002 12:34 PM
To: Jason Crawford; Daniel Brotsky
Cc: Clemm, Geoff; w3c-dist-auth@w3c.org; Julian Reschke
Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER



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

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

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

Lisa

Received on Monday, 28 January 2002 13:07:02 UTC