On 07/03/2012, at 1:34 PM, Randall Gellens wrote: > At 1:02 PM +1100 3/7/12, Mark Nottingham wrote: > >> On 07/03/2012, at 10:32 AM, Peter Saint-Andre wrote: >> >>> On 3/6/12 4:19 PM, Randall Gellens wrote: >>>> At 3:30 PM -0700 3/6/12, Peter Saint-Andre wrote: >>>> >>>>> In my working copy I've changed that paragraph to: >>>>> >>>>> Implementations of application protocols MUST NOT programatically >>>>> discriminate between "standard" and "non-standard" parameters based >>>>> solely on the names of such parameters (i.e., based solely on >>>>> whether the name begins with 'x-' or a similar string of characters). >>>> >>>> I like this wording, especially because it more clearly gets at the >>>> heart of the document, which is to not discriminate based only on the >>>> name prefix. >>>> >>>> One question, though: should this be "SHOULD NOT" rather than "MUST >>>> NOT"? The interoperability doesn't depend on implementations >>>> refraining from doing so, rather, we consider it more problematic to do >>>> so than not, so we are making a strong recommendation to not to so. >>>> Hence, "SHOULD NOT". >>> >>> Hi Randall, >>> >>> My co-author Mark Nottingham feels even more strongly about this issue >>> than I do, so I will let him comment. >> >> To me, the target of that language is software that generically treats protocol elements beginning with "x-" in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. > > Hi Mark, > > The point of the draft is to say that it's a bad idea to do this or to try and have a system where this is expected. The draft does a good job at saying this. I just think a "MUST NOT" isn't warranted here; I think a "SHOULD NOT" is justified per RFC 2119. I think a "SHOULD NOT" makes the point: Doing it makes bad things happen. I have to disagree; MUST NOT *is* justified. Deploying systems like this causes real interoperability problems, which is in scope for a MUST NOT. -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf