[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Protocol: control specifications.

Hallvard,

To answer your question about what X.500 servers do about wrong criticality, I can answer for our implementation of X.500. The answer is nothing. We use the criticalExtensions to determine whether any extensions we do not support are "critical" and if so, we generate an unavailableCriticalExtension error. Otherwise, we ignore the criticalExtensions except where critical extensions have been used to flag different behaviour (a misuse of critical extensions in my opinion), for example useAliasOnUpdate changes the behaviour of the dontDereferenceAliases service control option, rather than indicating the existence of a new flag for this purpose.

We treat the criticality flag in the LDAP controls in the same manner. If we support the control, we ignore the criticality flag.

- Mark.

Hallvard B Furuseth wrote: 
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.