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.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly selected tag: ---------------
I personally think we developed language because of our
deep need to complain. --Lily Tomlin
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf