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
>