Subject: [Bug 200] remove "bis" compliance class

From: [email-masked]
Date: Mon, 12 Dec 2005 11:54:38 -0800

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

------- Additional Comments From [email-masked]  2005-12-12 11:54 -------
This should be discussed during the teleconference. If there is no agreement, we should ask Cullen to 
make a consensus call. There appears to be a fundamental disagreement here.

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

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Dec 2005 15:04:53 -0800

I just read section 17 and, well, I'm certainly not clear how versioning
works. 

Is there a need for a client to do something different based on if it is
talking to a server that does all the MUST in 2518  and a server that does
all the MUST in bis. If so, the description in 17.1 may be problematic. If
this is the case, can someone provide an concrete example of this? If there
is no case of this, we can use the same class for all the MUSTs in bis. If
not we will need a way to tell if a server does all the MUST in 2518 or all
the MUST in bis. 

The description in 17.2 leaves me very unclear of what needs to be
implemented to be class 2. By "support" do you mean implement the MUSTs? The
SHOULDs?  the MAYs?

Any reason not to rename "class bis" to "class 3".

What is our take on Forced-Authenticate. Do we have a use case that requires
us to create a new class for this?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2005 04:01:35 +0100

> all the MUST in bis. If so, the description in 17.1 may be problematic. If

I don't think so. As a matter of fact, unless somebody can come up with 
as use case, defining a new compliance class seems to be completely useless.

> implemented to be class 2. By "support" do you mean implement the MUSTs? The

I agree that the distinction is extremely unclear. As far as I can tell, 
there are lots of MUST level requirements in the spec which are about 
locking, thus do not need to be implemented on a non-class-2 resource.

> Any reason not to rename "class bis" to "class 3".

People may read "3" as including "2", which would be a bad thing. 
Locking is optional in RFC2518, and it still is in BIS. Again, we 
wouldn't need to think about this if we didn't have that new compliance 
class at all.

It would be nice if those who think we need it could provide an example 
where a client would actually be able to make use out of this information.

> us to create a new class for this?

As far as I can tell, the consensus was to remove it.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 13 Dec 2005 22:38:02 -0500

> as use case, defining a new compliance class seems to be completely 
useless.

I agree with Julian, and I haven't yet seen an even partially compelling
use case that motivates the introduction of a new compliance class.  I 
suggest
that unless such a compelling use case is identified very soon, this 
matter
be resolved by not introducing a new compliance class.

> As far as I can tell, the consensus was to remove it.

That was my understanding as well.

Cheers,
Geoff

---

From: Jim Whitehead <[email-masked]>
Date: Wed, 14 Dec 2005 09:08:30 -0800

My rationale for adding a new compliance class is to ensure that  
clients know whether a server is using the 2518 semantics or 2518bis  
semantics. There are a lot of minor changes in semantics between the  
two specifications. I imagine there are some cases where a client  
would want to know this.

Let me push back, and say that, given we are adding many MUST and  
SHOULD level requirements to the specification, I think the burden of  
proof lies on showing that there is no possible reason why a client  
would ever want to discover whether a server supports 2518 or  
2518bis. I haven't yet heard even a partially compelling argument for  
this :-)

- Jim

On Dec 13, 2005, at 7:38 PM, Geoffrey M Clemm wrote:

> use case that motivates the introduction of a new compliance  
> class.  I suggest
> that unless such a compelling use case is identified very soon,  
> this matter

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 14 Dec 2005 12:27:12 -0500

One doesn't (or at least, I don't :-) add things to a specification based 
on "not being able to prove they aren't needed".

You cannot think of a single compelling case where a client would want to 
be able to distinguish the 2518bis semantics from the 2518 semantics?

I'd suggest we just take this as a sign that we have succeeded in 
achieving backward compatibility, and so no new compliance class is 
needed.

Cheers,
Geoff

My rationale for adding a new compliance class is to ensure that clients 
know whether a server is using the 2518 semantics or 2518bis semantics. 
There are a lot of minor changes in semantics between the two 
specifications. I imagine there are some cases where a client would want 
to know this.

Let me push back, and say that, given we are adding many MUST and SHOULD 
level requirements to the specification, I think the burden of proof lies 
on showing that there is no possible reason why a client would ever want 
to discover whether a server supports 2518 or 2518bis. I haven't yet heard 
even a partially compelling argument for this :-)

- Jim

Cheers, 
Geoff