RE: Protocol: control specifications.

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Ramsay, Ron writes:

> I can see no point in discussions of how a server should handle
> incorrect criticality.

Whether there is any point in discussing it anymore I don't know.

I do wish someone knew what some X.500 servers do about wrong
criticality.

> Presumably, if the server knows the criticality
> is wrong then it knows enough to inplement it.

Of course.

> Then, according to the rules, the criticality from the server's
> perspective is TRUE - controls that are implemented have to be
> performed.

The new rules, yes.

> So, you would be asking a server to tell the client either

s/asking/allowing/.

> 2) I didn't do it. I could have but, na-na-na, you got the criticality
> wrong. Let that teach you a lesson!

Yes.  You have a strange way of saying it, but since you do:

> I don't see either as acceptable server behaviour.

And I don't see why servers should be forbidden to catch this particular
client error.  There are plenty of client errors that servers may, but
need not, catch.  I think it's an important client error to catch, since
it can be so damaging.  As important as rejecting cleartext password
binds done without TLS.  After all, rejecting the bind doesn't protect
the password, that has already been sent in the clear.  But it
encourages the client to be fixed.

> I thought this had been settled. I thought I would see no more text on
> this.

I was arguing and arguing against the new rules when they were
suggested, but got little reply except a few misunderstandings.
OK, now I do get replies.

-- 
Hallvard