Jacob Palme wrote:

>To discourage what you do not like by not mentioning it is dangerous,
>some implementors may implement it, others not, and then their software
>may not co-work well. Thus, a standard may have to include explicit
>mention and examples of not-very-nice practice in order to ensure
>that implementors will support it at receipt. If a standard wants
>certain practice to be allowed on receipt, but not recommended in
>what you send, the standard should say so explicitly.
>
>I have always been critical of the IETF golden rule "be liberal in
>what you accept, conservative in what you send", because it is too
>vague, I think a standard should explicitly state, when needed,
>a different send and receipt format, i.e. explain what ins included
>in "liberal" but not in "conservative", and not leave this decision
>up to the implementors.

Jacob, I think your suggestion is fair (and fits with the spirit of the
"IETF golden rule", but it needs to be done clearly, as in "Don't send this.
However if you ever receive it you should probably act like this..." The one
danger with going down that road is that sometimes an implementor might rely
on that "if you receive it" behavior (when generating something) and get
burned when it isn't implemented consistently. In any case the behavior for
receiving incorrect values needs to be clearly marked and should probably
not be normative. This also of course needs to be clearly different than
things like "resolution of CID URLS outside of Multipart/related" which do
not fit into the category of "Don't send this".

Alex Hopmann
Microsoft Corporation