Subject: Re: Moving forward on BIND

From: Julian Reschke <[email-masked]>
Date: Mon, 04 Apr 2005 22:25:18 +0200

Jim Whitehead wrote:
> Joe writes:
> 
>>My guess for BIND is that either Ted or Scott would want 
>>clarification on a couple of the interoperability questions 
>>that Lisa has raised, regardless of whether the answer can be 
>>inferred by a fully-informed reader. 
> 
> 
> Julian Reschke and I just chatted on the phone. My perception is that we
> both agree that it makes sense to discuss the semantics of all DAV
> properties under BIND, UNBIND, and REBIND. There seem to be differences in
> desired behavior between properties whose semantics originated in WeBDAV
> (which are typically defined on the resource), and ones inherited from HTTP
> (like getlastmodified) which depend on representations of the resource. It
> is likely this discussion will lead to modifications to the bind
> specification.
> 
> Julian said he'd take the first whack at summarizing the technical points.

OK,

I have started a summary of what I think is the relation between HTTP 
header data and WebDAV namespace operations (including but not limited 
to those in BIND). Current draft at: 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs-properties-latest.html>. 
Writing this down makes a lot of sense; let's try to discuss & 
understand the problem first before we argue whether and what BIND needs 
to say about it.

(for those too lazy to read it... :-):

- we can't say anything about properties where we inherit semantics from 
RFC2616 (HTTP), just like Roy F. pointed out a few months ago. This 
includes DAV:getlastmodified and DAV:getetag.

- we could try to say a few words about those properties that are 
defined by RFC2518 and friends (although I'm not convinced it's worth 
the effort).

There are a few issues in BugZilla that have been opened since end of 
WGLC (working group last call) which are related to this analysis:

<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=76>: "What event 
does creationdate refer to" -- I'd like not to say anything particular 
about DAV:creationdate because that would imply it's different from 
other WebDAV properties. However, *if* we say something, at least it 
needs to be both correct and non-misleading (thus we'll need to state 
things about other WebDAV properties as well).

<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=77>: "Do Bind 
operations change the getlastmodified or getetag property values" -- 
Yes, they may. See above. BIND can't IMHO make any new requirements 
here; thus all we could say is that RFC2616 applies (which it does even 
if we don't say so).

<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=78>: Value of 
ETag and getlastmodified properties on multiple bindings> -- same as above.

I'd also like to ask the WG chairs to close the other open issues 
related to BIND 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2>, 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=5>, 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=71>) as agreed 
upon in Last Call process 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0001.html>).

Best regards,

Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 24 Apr 2005 12:03:53 +0200

Hi,

There hasn't been any feedback on my summary. I'd really like to think 
that this is because everybody agrees, but probably this is because 
nobody read it.

So it would be really nice if those who think there are problems with 
the latest BIND draft either follow up on this, or alternatively agree 
to submit it to the IESG for last call.

Best regards,

Julian

---

From: Elias Sinderson <[email-masked]>
Date: Mon, 25 Apr 2005 13:33:27 -0700

Julian Reschke wrote:

> There hasn't been any feedback on my summary. [...]

Sorry, just really busy of late. I've just sent the bugzilla issues list 
to the printer to review... Could we add the bugzilla issues to the HTML 
open issues list? Alternately, perhaps link to the bugzilla issues from 
the HTML issues list?

> to submit it to the IESG for last call. 

+1

Cheers,
Elias

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Apr 2005 22:16:20 +0200

> open issues list? Alternately, perhaps link to the bugzilla issues from 

Actually, most of the open Bugzilla issues should have been closed long 
ago. It's a shame that a new tracking system and last call procedure 
were introduced, and then the WG doesn't stick to the process that was 
agreed upon.

I have trouble taking Issue 76 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=76>) 
seriously; anyway I've replied to it and never heard back from the 
author, and no votes are on it.

Issues 77 and 78 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=77>, 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=78>) now link 
back to 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#2.6_bindings_vs_properties>.

>> to submit it to the IESG for last call. 

Thanks,

Julian

---

From: Elias Sinderson <[email-masked]>
Date: Tue, 26 Apr 2005 14:18:58 -0700

Julian Reschke wrote:

> [...] most of the open Bugzilla issues should have been closed long 
> ago. [...]

After looking over them more closely, I agree with this statement (see 
below).

> It's a shame that a new tracking system and last call procedure were 
> introduced, and then the WG doesn't stick to the process that was 
> agreed upon.

Agreed, however it may be best to get BIND out the door before expending 
any energy on process issues?  :-)

> author, and no votes are on it.

I have no objections to closing this issue, the intended bahavior seems 
perfectly clear from a reading of the two specs.

> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#2.6_bindings_vs_properties>. 

I am satisfied with the current resolution - if there are no objections, 
I would move that the existing language is sufficient and Issues 77 and 
78 should be closed.

Other currently open issues in bugzilla:
2, Bindings needs to completely describe how bindings interact with locks.
This issue appears to have been resolved, with clarifying text added to 
BIND. I move to close the bugzilla issue unless there is an objection.

5, Bindings and DeltaV aren't fully interspecified
See my subsequent message on this topic.

71, Clarify what servers may and may not do with privileges when BIND is 
used
See my subsequent message on this topic.

If there is further discussion on any of the above issues, please break 
it out into a seperate thread with the issue number and description in 
the subject line. IFAICT, the only issues that should still be open are 
5 and 71, addressed in my forthcoming missives.

Best,
Elias

---

From: Elias Sinderson <[email-masked]>
Date: Tue, 26 Apr 2005 14:20:30 -0700

Julian Reschke wrote:

> [...] most of the open Bugzilla issues should have been closed [...]

5, Bindings and DeltaV aren't fully interspecified
The discussion of the issue seems to have stalled, with no additional 
text being suggested or discussion of the issue for three months. Julian 
seems to take the position that DeltaV servers can always choose to fail 
a BIND request if the implementors don't want to deal with it, while 
Lisa seems to want to at least state that interactions when a binding is 
created are unspecified. Personally, I feel that the interactions should 
have been specified in 3253, as bindings existed prior to 3253 being 
published. This implies that any clarifications of these interactions 
belong as errata against the same and if any additional text is 
required, I would suggest that the reader is told as much.

Comments?

Cheers,
Elias

---

From: Elias Sinderson <[email-masked]>
Date: Tue, 26 Apr 2005 14:21:35 -0700

71, Clarify what servers may and may not do with privileges when BIND is 
used
As ACLs are defined on resources, not bindings, I don't see how the spec 
can say much that hasn't already been said. There are, however, 
potential issues with bindings across different security domains. If 
anything, I would advocate a restrictive approach to permissions. That 
is, permissions on bindings SHOULD default to those of the resource 
where possible, but MAY be restricted when bindings are made across 
namespaces with different permissions. Permissions MUST NOT be granted 
or extended in the above scenario. As I see it, this is the prudent 
thing to do in this situation. The only other option would be to forbid 
bindings across security domains that cannot maintain the existing 
permissions exactly as they are on the resource (if, for example, a 
given principledid not exist and could not be created).

Comments?

Best,
Elias

---

From: Eric Sedlar <[email-masked]>
Date: Tue, 26 Apr 2005 15:01:50 -0700

I think that BINDing's across security domains will in practice only 
occur across multiple instances of a product from a single vendor.  In 
those cases, I don't see why a BINDing across across security domain 
will necessarily behave any differently. 

--Eric

Elias Sinderson wrote:

> 71, Clarify what servers may and may not do with privileges when BIND 
> is used
> As ACLs are defined on resources, not bindings, I don't see how the 
> spec can say much that hasn't already been said. There are, however, 
> thing to do in this situation. The only other option would be to 
> forbid bindings across security domains that cannot maintain the 
> existing permissions exactly as they are on the resource (if, for 
> example, a given principledid not exist and could not be created).
>
> Comments?
>
>
> Best,
> Elias
>

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 26 Apr 2005 23:03:04 -0400

Elias:

I don't quite follow what you are suggesting here.  To make this
more concrete, what additional language do you think needs to be
added to the method or properties being defined in the binding spec?

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 26 Apr 2005 23:06:31 -0400

I agree with Elias.  Multiple bindings are explicitly identified in
DeltaV as something created when you have a version-controlled resource
for a given version history as an immediate member of more than one
collection in that workspace.  Therefore, if anything is unclear about
this in RFC-3253, please submit this as a bug against RFC-3253, and I'll
make sure it gets addressed in RFC-3253bis.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Apr 2005 14:29:31 +0200

> After looking over them more closely, I agree with this statement (see 

Thanks.

> any energy on process issues?  :-)

Agreed. Althogh it seems that it's the process issues that have 
prevented us from getting it out of the door, not technical issues :-).

> ...

Will do.

Thanks for the feedbback,

Julian

---

From: Elias Sinderson <[email-masked]>
Date: Wed, 27 Apr 2005 14:50:05 -0700

Geoffrey M Clemm wrote:

> DeltaV [...] if anything is unclear about this in RFC-3253, please 
> submit this as a bug against RFC-3253, and I'll make sure it gets 
> addressed in RFC-3253bis.

I move to close Issue 5 as resolved, with no additional text being 
required in the BIND specification. It is superfluous to mention what 
the BIND spec doesn't address.

Cheers,
Elias

---

From: Elias Sinderson <[email-masked]>
Date: Wed, 27 Apr 2005 14:54:44 -0700

Eric Sedlar wrote:

> occur across multiple instances of a product from a single vendor. [...]

I would think that this will be the case most, but not all, of the time. 
However, even if the respositories are of the same pedigree, their 
respective configuration or product version differences may impact the 
ability to preserve principles and permissions.

Cheers,
Elias

> In those cases, I don't see why a BINDing across across security 
> domain will necessarily behave any differently.
> --Eric
>
> Elias Sinderson wrote:
>
>>
>> Julian Reschke wrote:
>>
>> anything, I would advocate a restrictive approach to permissions. 
>> That is, permissions on bindings SHOULD default to those of the 
>> resource where possible, but MAY be restricted when bindings are made 
>> across namespaces with different permissions. Permissions MUST NOT be 
>> granted or extended in the above scenario. As I see it, this is the 
>> prudent thing to do in this situation. The only other option would be 
>> to forbid bindings across security domains that cannot maintain the