Re: Last Call: <draft-ietf-appsawg-xdash-03.txt>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

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").


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.

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.

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.

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.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
There is only one thing in the world worse than being talked about, and
that is not being talked about.     --Oscar Wilde
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]