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