On 3/2/12 5:48 PM, Randall Gellens wrote:
> Hi all,
Hi Randall, thank you for the review and suggested text.
> Three suggestions for edits:
>
> First: I suggest adding a brief note to this text in Appendix B:
>
> 2. When parameter names might have significant meaning. However,
> this case too is rare, since implementers can almost always find
> a synonym for an existing term (e.g., "urgency" instead of
> "priority") or simply invent a more creative name (e.g., "get-it-
> there-fast").
>
> At the end, I suggest adding an additional sentence:
>
> The existence of multiple similarly-named paramaters can
> be confusing, but this is true regardless if there is an
> attempt to segregate standard and non-standard (e.g.,
> "X-Priority" can be confused with "Urgency").
True. If my co-authors agree, I'll add that to our working copy.
> Second, consider this the text in Appendix B:
>
> Furthermore, often standardization of a non-standard parameter or
> protocol element leads to subtly different behavior (e.g., the
> standard version might have different security properties as a result
> of security review provided during the standardization process). If
> implementers treat the old, non-standard parameter and the new,
> standard parameter as equivalent, interoperability and security
> problems can ensue.
>
> This is of course true, but I think it is somewhat misleading: If a
> parameter starts out as non-standard, gets some deployment, then as part
> of an effort to standardize it, flaws are discovered which require
> different behavior, I think we want the new, standardized parameter to
> have a different name so it can be distinguished and the new, more
> desirable behavior mandated. This is the same regardless if the old and
> new parameters are, say, "x-priority" and "priority", or "priority" and
> "urgency". In either case, implementers shouldn't treat the old
> parameter as identical to the new, standardized one.
Yet that's what RFC 2068 says:
For compatibility with previous implementations of HTTP,
applications should consider "x-gzip" and "x-compress" to be
equivalent to "gzip" and "compress" respectively.
However, as far as I have been able to determine there were no
significant differences between the "standard" and "non-standard"
versions of those parameters (others here would know better than I do).
> Further, I think it's a good thing when an old, non-standard parameter
> is standardized and flaws are corrected. We should encourage, not
> discourage this.
Indeed.
> It would be good to have at least a little text along these lines.
> Specifically, I suggest adding new text at the end:
>
> Analysis of non-standard parameters and protocol elements
> to detect and correct flaws is in general a good thing and
> is not intended to be discouraged by the lack of
> distinction in element names. Whenever an originally
> non-standard parameter or protocol element is standardized
> and the new form has differences which affect
> interoperability or security properties, implementations
> MUST NOT treat the old form as identical to the new form.
That seems fine (although I would not include "protocol element" because
this document is only about parameters).
> Further in the appendix, justification 1 is over-drawn. I suggest
> toning it down slightly, from:
>
> 1. Implementers are easily confused and can't be expected to know
> that a parameter is non-standard unless it contains the "X-"
> prefix. However, implementers already are quite flexible about
> using both prefixed and non-prefixed names based on what works in
> the field, so the distinction between de facto names (e.g.,
> "X-foo") and de jure names (e.g., "foo") is without force.
>
> To:
>
> 1. Implementers may confuse parameters that have similar
> names; a rigid distinction such as an "X-" prefix can make
> this clear. However, in practice implementers are forced
> to blur the distinction (e.g., by treating "X-foo" as a de
> facto standard) and so it inevitably becomes meaningless.
WFM, let's see if my co-authors agree.
Proposed text is always appreciated.
Peter
--
Peter Saint-Andre
https://stpeter.im/
_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
