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

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  
> 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
> >
> > 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.
>
> 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.
>
> > > What is our take on Forced-Authenticate. Do we have a use case  
> that requires
> > > 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.
>
> Cheers,
> Geoff
>