Re: Last Call: <draft-ietf-appsawg-xdash-03.txt> (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice

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

 



At 4:32 PM -0700 3/6/12, 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.

 However, note the existence of things like the "x-gzip" and "gzip"
 content codings in HTTP, which RFC 2068 says are equivalent. An
 implementation that programmatically discriminated between "standard"
 and "non-standard" parameters based solely on the parameter names might
 automatically reject entities for which a content-coding of "x-gzip" is
 specified, but automatically accept entities for which a content-coding
 of "gzip" is specified. IMHO that's just wrong, and MUST NOT is appropriate.

Hi Peter,

Is the hypothetical application discriminating between all "x-" and everything else, or is it only doing so for parameters it does not recognize? In the case of "x-gzip" and "gzip", wouldn't the application be doing whatever it does based on recognizing that this is gzip?

Anyway, it's hard for me to imagine a real application doing something like what the text suggests (say, bouncing email with "x-gzip" or refusing to expand an file or attachment of "x-gzip"), and even if there were such an application, it would be a very broken implementation, but not something that harmed the Internet or even anyone else whose applications worked properly. At most it would harm its own user, who I assume would quickly dump it.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Computers are not intelligent.  They only think they are.
_______________________________________________
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]