|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: invalid key valueI think the statement in the spec that "proprietary digest algorithms may also be negotiated" settles the matter for the case of the digest negotiation: an unrecognized value means a proprietary algorithm you don't know of, and clearly you have to keep scanning for another value that you *do* support. You can't just quit immediately, because that would conflict with the rule permitting proprietary key values. For other keys, that reasoning doesn't necessarily apply (i.e., if proprietary key values aren't explicitly listed as legal). You can then do one of two things: 1. Insist that the receiver should be extremely picky. If so, then you will *force* a version number change for every tiny change in the set of allowed values. 2. Expect the receiver to ignore values it doesn't understand, and not complain so long as one of the alternatives offered is one it *does* both understand and support. This is an application of the protocol design principle "be strict in what you send, lenient in what you receive". It's not an absolute rule, but as a design guideline it has served well for many decades. One reason why is that it eliminates the need to change version numbers except when you make "large" changes to the protocol. Nitpicking changes like adding new alternatives for keys are not changes that require version number incrementing, provided that you use this rule. Having had to deal with both approaches, I am strongly of the opinion that #1 is a bad idea and #2 is the only correct approach. paul
Home Last updated: Fri Jan 25 14:17:55 2002 8482 messages in chronological order |