RE: Protocol: control specifications.

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

1. Are they the *new* rules? I've been following the *new* paradigm for some time.
2. It is NOT like rejecting the bind. We are able to process the request; it is the other servers that may not be able to process it. It is like rejecting a bind because *another* server might not handle it correctly!

In short, you are asking one server to behave in a particul;ar way JUST BECAUSE another server may behave differently. The problem is not with THIS server. Therefore, THIS server should not worry about the criticality. It also should not worry about any OTHER server and whether it would do the right thing.

Ron

-----Original Message-----
From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]
Sent: Wednesday, 10 March 2004 13:03
To: Ramsay, Ron
Cc: ietf-ldapbis@OpenLDAP.org
Subject: RE: Protocol: control specifications.


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