This sentiment mostly makes sense. If an endpoint expects SHOULD/MAY items implemented as MUSTs on the remote end, then one should slap the endpoint developer silly. Read the RFC! If it says SHOULD/MAY, then your implementation MUST be able to handle the feature present *and* absent. Note that every SHOULD/MAY in a specification introduces cyclomatic complexity. Every SHOULD/MAY results in at least one "if" statement, to test the presence or absence of the feature in the remote end. Protocols will be much simpler to implement. Moreover, given the results in the software engineering literature that indicate latent defects appear super-linearly with cyclomatic complexity, protocols without (or a minimum) of SHOULD/MAY features will have fewer defects in the field. Remember, we are working on Internet protocols, where a one-in-a-million corner case happens many times per day. On Aug 30, 2011, at 4:00 AM, HLS wrote: > On 8/30/11, Murray S. Kucherawy <msk@xxxxxxxxxxxxx> wrote: > >>> Mark Nottingham: >>> 1) I agree that the "SHOULD... UNLESS" pattern ought be documented. > >> I had never thought of this before. I kind of like the idea, especially since SHOULD >> has always meant "MUST unless you really know what you're doing" > > Such an odd reading. Does it mean you MUST because you could not > handle it otherwise? > > It takes two to tango. One side reasons can be different than the > other. If a software breaks down because it read SHOULD as a MUST and > expected the other end will also view is a MUST, then it didn't know > what it was doing. Things break down. Implementors on either side > can't depend on it and need to function in lieu of it. There is always > the possibility one decided "Nahhhh, not needed, not worth the cost. > Its not required." etc, and no one should die because of that > decision. > > I think it MUST be noted that a Minimum Implementation for a protocol > is all anyone can expect. If a SHOULD item is among the listed minimum > requirements, it MUST be removed from the list or changed to a MUST. > > Maybe the term Minimum Implementation (is part of, is not part of) can > be incorporated into each of the key word text. > > -- > hls > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf
<<attachment: smime.p7s>>
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf