Subject: [Bug 5] Bindings and DeltaV aren't fully interspecified

From: [email-masked]
Date: Thu, 2 Dec 2004 16:59:07 -0800

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=5

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |

------- Additional Comments From [email-masked]  2004-12-02 16:59 -------
Can a client replace a Working Resource with a binding to some existing
resource?  If so, what does that do when it does CHECKIN that working resource?

can a client use BIND to create a binding to a workspace?  Can a client use BIND
to create a binding to an activity?  etc. for each new resource type defined in
RFC3253... MUST the server support each of these operations?

When a property contains an href, and that href points to a resource with
multiple bindings, "it doesn't matter which binding is reported by the server".
 Ok, fine -- so we need to state that the server could show any binding URL and
the client MUST be able to handle that.

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 2 Dec 2004 22:02:38 -0500

So what is the process here?  How does one ever close out a bug if
the original author can just re-open it at will?

In particular, I suggest that at a minimum, someone other than the 
original
reporter of the bug be required to re-open it, to indicate that there is 
at
least one other person that feels it is not resolved.

Otherwise any individual can effectively block progress in any spec.

Cheers,
Geoff

> to create a binding to an activity?  etc. for each new resource 
typedefined in

---

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Dec 2004 09:16:31 +0100

> the original author can just re-open it at will?

I don't think there's a way to prevent it.

> In particular, I suggest that at a minimum, someone other than the original
> reporter of the bug be required to re-open it, to indicate that there is at

Not really. I don't consider the particular state of an issue entered on 
BugZilla of any relevance on the process, unless there is working group 
consensus that this is the case.

Now *how* working group consensus is determined is an interesting 
question, and I hope that at some point of time (hopefully soon), Joe H. 
will tune in and discuss with us how he plans to proceed in general (and 
with BIND in particular). If we can't get the chair's attention (for 
whatever reason), we'll probably have to discuss alternative routes.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 3 Dec 2004 10:17:22 -0800

> Not really. I don't consider the particular state of an issue 
> entered on BugZilla of any relevance on the process, unless 
> there is working group consensus that this is the case.

Reopening an issue in Bugzilla indicates that there is not *exact* consensus
on an issue. However, IETF rules only require *rough* consensus. While IETF
rules only discuss entire specifications, and not individual issues, it does
seem reasonable to use rough consensus as the yardstick for determining how
to proceed on individual issues.

One implication of this is that an individual cannot block progress on a
specification in this way.

That all said, I'll note that I just reopened the same issue, and even
though there are several thousand kilometers separating me from Julian, I
think I can still hear his cries of anguish :-)
(FWIW, I do have technical concerns here, I didn't reopen just to be moot).

- Jim