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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf