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

From: Randall Gellens <[email-masked]>
Date: Fri, 2 Mar 2012 16:48:22 -0800

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Mar 2012 16:42:09 -0700

> Hi all,

Hi Randall, thank you for the review and suggested text.

>     "X-Priority" can be confused with "Urgency").

True. If my co-authors agree, I'll add that to our working copy.

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

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

>    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/

---

From: Randall Gellens <[email-masked]>
Date: Tue, 6 Mar 2012 16:16:34 -0800

Hi Peter,

>  versions of those parameters (others here would know better than I do).

Thanks for digging that up.  I think this goes to my point, which is 
that either there are important differences, or there aren't; if 
there are (especially security-related ones) then we don't want to 
treat the old, non-standard and the new standard as equivalent, 
because it isn't safe to treat them as the same.  But if it is safe 
to treat them as the same, then of course it makes sense to do so. 
And this is orthogonal to an attempt to segregate standard and 
non-standard names.  I think it also makes your point, which is that 
the attempt at segregating the names doesn't help; we still want to 
either treat them as the same or not, based on specifics of the 
situation, not the name.  I'd even suggest that this aspect is a 
strong argument in favor of this document: it doesn't work to use the 
names as an automatic discriminator, there needs to be case-by-case 
evaluation.

>  this document is only about parameters).

Sounds good to me.  I only added "protocol element" because I saw it 
elsewhere in the document.

-------------- Randomly selected tag: ---------------
Do not drink coffee in early A.M.  It will keep you awake until noon.