W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: New compliance class - was Re: [Bug 200] remove "bis" compliance class

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Wed, 14 Dec 2005 12:27:12 -0500
To: Jim Whitehead <ejw@soe.ucsc.edu>
Cc: WebDav <w3c-dist-auth@w3.org>
Message-ID: <OF4426ABA9.7B76390E-ON852570D7.005F433D-852570D7.005FDE17@us.ibm.com>
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 


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:

Julian wrote on 12/13/2005 10:01:35 PM:

> Cullen Jennings wrote:
> > 
> > I just read section 17 and, well, I'm certainly not clear how 
> > works. 
> > 
> > Is there a need for a client to do something different based on if it 
> > talking to a server that does all the MUST in 2518  and a server that 
> > 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 

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 
that unless such a compelling use case is identified very soon, this 
be resolved by not introducing a new compliance class. 

> > What is our take on Forced-Authenticate. Do we have a use case that 
> > us to create a new class for this?
> As far as I can tell, the consensus was to remove it.

That was my understanding as well. 

Received on Wednesday, 14 December 2005 17:28:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC