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

RE: Protocol: control specifications.

So you summary tells me that:
a) The issue regarding whether the server should check the validity of the criticality is a dead horse.
b) More discussion regarding the current wording needs to take place.
I suggest (unless there are other reasons I'm not seeing) that we drop the (a) discussion.

>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 3/8/04 11:44:15 AM >>>
Ramsay, Ron writes:
> I can't help feeling that you have answered your own question.

I'm not sure which question you are referring to. You are just
describing some of the semantics of the current draft. I'm asking for
responses to my arguments against the change from rfc2251 to that
semantics. The original change I suggested in the other direction has
been discussed to death, but the change which was actually made has not.

> The server response is (...)

Yes, that's what the current text says. It's not what rfc2251 said.

John McMeeking writes:

> I think Hallvard is arguing that 1B -- a control incorrectly marked
> with criticality = FALSE -- should result in a failure.

Well, that's what I want (with s/should/SHOULD/), but I've given up that
as a lost cause. What I'm asking for now is response to my arguments
against even removing the MAY and the change to demote _required_
criticality to mere advice, and for clarification to some of the text
about the latter.

> Here's what I can find in X5.11 (1993 & 2001) on critical extensions:
> (...)
> The "shalls" cover what the DUA is supposed to do. I don't know what the
> DSA is supposed to do in response to a request that uses a critical
> extension but does not have the criticality bit set.

Yes, I'd like to know what X.500 servers actually do in that case.

BTW, I'm sorry about the sour note I restarted this thread with. I
guess it's because I wrote it at "33:45 o'clock" and was rather tired
after a long night.