Subject: Bind issues

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 18 Nov 2003 11:41:27 -0800

On 8/4/2003, I asked about PROPFIND results in presence of bindings.  I
don't know that
that has been clarified.
 
On 3/8/2003, I proposed language for clearer requirements on DELETE
behavior. This applies to MOVE too.  The discussion started earlier,
3/4/2003 or before.
 
I believe I asked for more lock requirements -- what the server MUST do when
a client locks a binding.  I haven't found that email yet.
 
It's quite possible that the bind authors believe they've already dealt with
these issues.  If so, I'm unaware of the resolutions.
 
Lisa

-----Original Message-----
From: Geoffrey M Clemm [mailto:[email-masked]] 
Sent: Tuesday, November 18, 2003 5:29 AM
To: Julian Reschke
Cc: Lisa Dusseault; 'Wallmer, Martin'; [email-masked]
Subject: Re: "URI properties", Was: SEARCH for displayname

Like Julian, I have no memory of Lisa raising this issue on 
the mailing list (at least, not since the activity on the BIND 
protocol was resumed a year ago). A pointer to that email would be
appreciated, 
since both Julian and I work very hard to maintain accurate issue 
lists and to make sure that all issues that are raised on the mailing 
list are addressed.  There was a discussion in the design team 4 or 
5 years ago, about whether the spec should leave the question of where 
the state of a binding resides up to the server (i.e. is it in the 
parent collection, the child resource, or both), and the consensus 
was that effective interoperability required us to specify where 
this resides, so that access control and locking behavior could be 
defined (i.e. was the removal/addition of a binding controlled by 
a lock/acl on the parent collection, on the child resource, or both). 
The choice of the parent collection was motivated by the use case 
of two bindings to the same resource in a single collection, and by 
the use case of different collections needing to give different names 
to a single resource. 

Cheers, 
Geoff 

Julian Reschke <[email-masked]> wrote on 11/12/2003 11:00:00 AM:

> Lisa Dusseault wrote:
> 
> > I do plan to raise these issues more generally for bind.  However, I 
> > have also raised them in the past and they do not show up on your list.
> 
> Well, the please re-raise them with a pointer to the original mail on 
> the mailing list.
> 
> > Sorry if my replies are brief to the point of bluntness; I'm trying 
> > to do a bunch of IETF coordination and cross-group work this week and
> > attend other WG meetings at the same time.  I will try to understand
> > the context in which you're saying how things are and must behave.
> 
> Good.
> 
> > In return, please respect that I am challenging the model assumptions
> > I see developing here and in bind discussions.  I hope it's not too
> > late for us to have open minds about how things are defined.
> 
> The model for BIND has been developed in 1999 and has never changed since.
> 
> Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Nov 2003 21:12:35 +0100

> On 8/4/2003, I asked about PROPFIND results in presence of bindings.  I 

I think this is the open issue that I mentioned. The proposal that I 
made two days ago 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0200.html>) 
should take care of the issue you raised.

> behavior. This applies to MOVE too.  The discussion started earlier, 

In draft 02, BIND was rewritten to have both DELETE and UNBIND. As far 
as I can tell this took care of the issues from those who felt 
uncomfortable requiring DELETE to be atomic (this included myself). In 
the current spec, a server can implement DELETE non-atomic.

> I believe I asked for more lock requirements -- what the server MUST do 
> when a client locks a binding.  I haven't found that email yet.

Interaction between locks and multiple bindings is defined in GULP, and 
as far as I can tell, the only missing thing is to integrate it into 
RFC2518bis, just like discussed many times (both on the interim WG 
meeting in January and the mailing list).

> It's quite possible that the bind authors believe they've already dealt 
> with these issues.  If so, I'm unaware of the resolutions.

To summarize:

1) is open (it's the only open issue, and we're just trying to resolve it),

2) DELETE changed in draft 02, so please re-check,

3) there was agreement to do this in RFC2518bis -- if you think there 
are issues left with the latest GULP version, please describe those.

Regards, Julian