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

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.

> 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?

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.

> 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.


Best regards, Julian

Received on Wednesday, 14 December 2005 03:03:27 UTC