Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
Hi. I realize I'm probably in the minority on this, but I think the document overstates its case a bit and, perhaps recognizing the actual complexity of the situation, even may contradict itself a bit. For example, I note that it says: (Section 1) Therefore this document deprecates the X- convention for named parameters in application protocols but (Section 4 (4)) SHOULD identify a convention to allow local or implementation-specific extensions, and reserve delimeters for such uses as needed. presumably as long as those delimiters don't consist of X-. While I believe that the general strategy of treating textual parameters as hierarchical (or consisting of subsets) so that private allocations can exist in a separate tree is a good one, I think we also need to recognize that X- is just one more way to make that division. If it not a wonderful one, and it carries around a lot of baggage, but neither justifies the amount of venom that has been directed toward it over the years nor some of the strong language of this document (which is much better than some of its earlier drafts in that respect). The reality is that, when X- has been used to identify purely private and/or implementation-specific parameters, it has not been a problem. It has been a problem for experimental parameters, but that is a different matter... and a distinction this document fails to make clearly enough, at least IMO. Overstating the case for something like this, e.g., by inserting MUST NOT language where there is little justification for more than SHOULD NOT won't be likely change the behavior of those creating or maintaining implementations. MUST NOTs that are ignored do nothing positive for the reputation or credibility of the IETF. I largely agree with Randy Gellens's reasoning about this. However, I don't think the choice of requirements language is a showstopper: I think it is a judgment call and that, unless there is a basis for strong consensus, judgment calls should generally be resolved in favor of a less-strong requirement. While Appendix A mentions the history of using X (without the dash) for experimental and private command names, the document does not address that issue at all. The second primary objection listed in Appendix B is, IMO, somewhat misstated. It would be more accurate to say, more or less, Collisions are undesirable and it would be bad for a parameter 'foo' to designate two different sets of semantics, whether either of those sets is standard or not. The only ways to avoid that situation are for all parameters to be registered so that someone considering defining a new one can determine whether the name string is already in use _or_ for all parameters to contain a relatively-long randomly-generated substring to make the likelihood of accidental collision infinitesimal. The problem is that it is impossible to achieve universal registration despite the changes represented by more recent registration specifications, so there is some merit to being able to lexically distinguish private use (not to be accepted in interchange without out-of-band knowledge) parameter values from broader-use (and possibly standardized) ones. I note that no one has seriously proposed the random substring solution but, if we were serious about the problem for parameters users are unlikely to see, it is part of the logical solution space. Finally, the effect of this document is to update a rather large collection of existing specifications, not all of which are included in textual discussion or references. Those specifications are not listed in the text or in an updates header, much less called out in the Introduction and/or Abstract. Recommendations: (1) As suggested by several others, remove the MUST from Section 2, replacing it with SHOULD. (2) Clarify whether this document is intended to deprecate giving special treatment to protocol commands starting in X rather than merely parameters starting in X- and why or why not. (3) Clarify the difference between private-use parameters, implementation-specific parameters, and experimental parameters. Strong language discouraging the latter is probably appropriate, but clearly-defined private uses may be reasonable (at least for some protocols), and implementation-specific parameters may fall somewhere in between. (4) Correct the explanation of the counterarguments as outlined above so that the document is not attacking straw men. (5) Either (i) explicitly identify the complete list of specifications that this one updates, doing so with all of the decorations that the IESG has required in other specifications, (ii) incorporate language into this specification and a revised Last Call that identifies the reasons why this specification is exempt, or (iii)
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
On 3/1/12 5:14 PM, Scott Kitterman wrote: Peter Saint-Andre stpe...@stpeter.im wrote: On 3/1/12 12:00 PM, Scott Kitterman wrote: On Thursday, March 01, 2012 10:47:50 AM The IESG wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Deprecating Use of the X- Prefix in Application Protocols' draft-ietf-appsawg-xdash-03.txt as a Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Historically, designers and implementers of application protocols have often distinguished between standard and non-standard parameters by prefixing the latter with the string X- or similar constructions. In practice, this convention causes more problems than it solves. Therefore, this document deprecates the X- convention for textual parameters in application protocols. ... 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general categories of standard and non-standard parameters in programatically different ways within their applications. Shouldn't this restrict itself to the naming of parameters? Perhaps: 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general naming of parameters in programmatically different ways within their applications depending on if they are standard or non-standard. How about this? Implementations of application protocols MUST NOT programatically discriminate between standard and non-standard parameters based solely on the names of such parameters. I'm not quite sure. Is this supposed to be about how one selects names or how one uses them. I'd thought it meant the former, but your revised text sounds like the latter to me. The concept behind this text was always about how one uses names, or more precisely how code implementations treat them, because the authors are of the opinion that it's a bad idea for implementations to hardcode their handling of parameter based solely on the existence of the string 'x-' at the start of the parameter name. I think the revised text I provided captures this more clearly. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
On Tuesday, March 06, 2012 03:19:41 PM Peter Saint-Andre wrote: On 3/1/12 5:14 PM, Scott Kitterman wrote: Peter Saint-Andre stpe...@stpeter.im wrote: On 3/1/12 12:00 PM, Scott Kitterman wrote: On Thursday, March 01, 2012 10:47:50 AM The IESG wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Deprecating Use of the X- Prefix in Application Protocols' draft-ietf-appsawg-xdash-03.txt as a Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Historically, designers and implementers of application protocols have often distinguished between standard and non-standard parameters by prefixing the latter with the string X- or similar constructions. In practice, this convention causes more problems than it solves. Therefore, this document deprecates the X- convention for textual parameters in application protocols. ... 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general categories of standard and non-standard parameters in programatically different ways within their applications. Shouldn't this restrict itself to the naming of parameters? Perhaps: 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general naming of parameters in programmatically different ways within their applications depending on if they are standard or non-standard. How about this? Implementations of application protocols MUST NOT programatically discriminate between standard and non-standard parameters based solely on the names of such parameters. I'm not quite sure. Is this supposed to be about how one selects names or how one uses them. I'd thought it meant the former, but your revised text sounds like the latter to me. The concept behind this text was always about how one uses names, or more precisely how code implementations treat them, because the authors are of the opinion that it's a bad idea for implementations to hardcode their handling of parameter based solely on the existence of the string 'x-' at the start of the parameter name. I think the revised text I provided captures this more clearly. Yes. Thanks for clarifying. Scott K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
On 3/6/12 3:24 PM, Scott Kitterman wrote: On Tuesday, March 06, 2012 03:19:41 PM Peter Saint-Andre wrote: On 3/1/12 5:14 PM, Scott Kitterman wrote: Peter Saint-Andre stpe...@stpeter.im wrote: On 3/1/12 12:00 PM, Scott Kitterman wrote: On Thursday, March 01, 2012 10:47:50 AM The IESG wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Deprecating Use of the X- Prefix in Application Protocols' draft-ietf-appsawg-xdash-03.txt as a Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Historically, designers and implementers of application protocols have often distinguished between standard and non-standard parameters by prefixing the latter with the string X- or similar constructions. In practice, this convention causes more problems than it solves. Therefore, this document deprecates the X- convention for textual parameters in application protocols. ... 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general categories of standard and non-standard parameters in programatically different ways within their applications. Shouldn't this restrict itself to the naming of parameters? Perhaps: 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general naming of parameters in programmatically different ways within their applications depending on if they are standard or non-standard. How about this? Implementations of application protocols MUST NOT programatically discriminate between standard and non-standard parameters based solely on the names of such parameters. I'm not quite sure. Is this supposed to be about how one selects names or how one uses them. I'd thought it meant the former, but your revised text sounds like the latter to me. The concept behind this text was always about how one uses names, or more precisely how code implementations treat them, because the authors are of the opinion that it's a bad idea for implementations to hardcode their handling of parameter based solely on the existence of the string 'x-' at the start of the parameter name. I think the revised text I provided captures this more clearly. Yes. Thanks for clarifying. Thanks for requesting clarification. 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). Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
On Tuesday, March 06, 2012 03:30:44 PM Peter Saint-Andre wrote: On 3/6/12 3:24 PM, Scott Kitterman wrote: On Tuesday, March 06, 2012 03:19:41 PM Peter Saint-Andre wrote: On 3/1/12 5:14 PM, Scott Kitterman wrote: Peter Saint-Andre stpe...@stpeter.im wrote: On 3/1/12 12:00 PM, Scott Kitterman wrote: On Thursday, March 01, 2012 10:47:50 AM The IESG wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Deprecating Use of the X- Prefix in Application Protocols' draft-ietf-appsawg-xdash-03.txt as a Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Historically, designers and implementers of application protocols have often distinguished between standard and non-standard parameters by prefixing the latter with the string X- or similar constructions. In practice, this convention causes more problems than it solves. Therefore, this document deprecates the X- convention for textual parameters in application protocols. ... 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general categories of standard and non-standard parameters in programatically different ways within their applications. Shouldn't this restrict itself to the naming of parameters? Perhaps: 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general naming of parameters in programmatically different ways within their applications depending on if they are standard or non-standard. How about this? Implementations of application protocols MUST NOT programatically discriminate between standard and non-standard parameters based solely on the names of such parameters. I'm not quite sure. Is this supposed to be about how one selects names or how one uses them. I'd thought it meant the former, but your revised text sounds like the latter to me. The concept behind this text was always about how one uses names, or more precisely how code implementations treat them, because the authors are of the opinion that it's a bad idea for implementations to hardcode their handling of parameter based solely on the existence of the string 'x-' at the start of the parameter name. I think the revised text I provided captures this more clearly. Yes. Thanks for clarifying. Thanks for requesting clarification. 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). Peter Looks good to me. Scott K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
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. From RFC 2119: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- Language is a virus from outer space. --William S. Burroughs ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
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. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
Hey Peter, -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Peter Saint-Andre Sent: Tuesday, March 06, 2012 3:32 PM To: Randall Gellens Cc: Mark Nottingham; ietf@ietf.org Subject: Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice 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. So should this document note that it Updates 2068? -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
On 3/6/12 4:46 PM, Murray S. Kucherawy wrote: Hey Peter, Howdy. :) -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Peter Saint-Andre Sent: Tuesday, March 06, 2012 3:32 PM To: Randall Gellens Cc: Mark Nottingham; ietf@ietf.org Subject: Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice 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. So should this document note that it Updates 2068? I don't think so, because x-gzip and gzip were in fact equivalent (as far as I can see), so treating them as equivalent seems just fine. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
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. I don't think harm to the Internet is the bar for MUST. If your implementation would generally be considered broken if you did X, then I think that rates a MUST NOT X. It's often a bit of judgment whether to use MUST NOT or SHOULD NOT, and we have some latitude in making that judgment. I agree with PSA and MNot that this case should be MUST NOT. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
At 7:53 PM -0500 3/6/12, Barry Leiba wrote: 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. I don't think harm to the Internet is the bar for MUST. If your implementation would generally be considered broken if you did X, then I think that rates a MUST NOT X. It's often a bit of judgment whether to use MUST NOT or SHOULD NOT, and we have some latitude in making that judgment. I agree with PSA and MNot that this case should be MUST NOT. Yeah, harm to the Internet is overblown, sorry. But still, if a violation doesn't harm anyone else, then I don't think a MUST NOT is justified. My reading of 2119 is the basis for this: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- He knows nothing, and he thinks he knows everything. That points clearly to a political career. -- George Bernard Shaw ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
On 07/03/2012, at 10:32 AM, 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. To me, the target of that language is software that generically treats protocol elements beginning with x- in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. Regards, -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
At 1:02 PM +1100 3/7/12, Mark Nottingham wrote: On 07/03/2012, at 10:32 AM, 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. To me, the target of that language is software that generically treats protocol elements beginning with x- in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. Hi Mark, The point of the draft is to say that it's a bad idea to do this or to try and have a system where this is expected. The draft does a good job at saying this. I just think a MUST NOT isn't warranted here; I think a SHOULD NOT is justified per RFC 2119. I think a SHOULD NOT makes the point: Doing it makes bad things happen. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- I personally think we developed language because of our deep need to complain.--Lily Tomlin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
On 07/03/2012, at 1:34 PM, Randall Gellens wrote: At 1:02 PM +1100 3/7/12, Mark Nottingham wrote: On 07/03/2012, at 10:32 AM, 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. To me, the target of that language is software that generically treats protocol elements beginning with x- in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. Hi Mark, The point of the draft is to say that it's a bad idea to do this or to try and have a system where this is expected. The draft does a good job at saying this. I just think a MUST NOT isn't warranted here; I think a SHOULD NOT is justified per RFC 2119. I think a SHOULD NOT makes the point: Doing it makes bad things happen. I have to disagree; MUST NOT *is* justified. Deploying systems like this causes real interoperability problems, which is in scope for a MUST NOT. -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
To me, the target of that language is software that generically treats protocol elements beginning with x- in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. clue bat please? is there any general semantic to X-? randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
On 07/03/2012, at 1:52 PM, Randy Bush wrote: To me, the target of that language is software that generically treats protocol elements beginning with x- in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. clue bat please? is there any general semantic to X-? I think one of the main points of the draft is to answer that question with no. -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
But it does clue one in immediately to the fact that the parameter is non-standard. Paul -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark Nottingham Sent: Tuesday, March 06, 2012 11:11 PM To: Randy Bush Cc: Randall Gellens; ietf@ietf.org Subject: Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice On 07/03/2012, at 1:52 PM, Randy Bush wrote: To me, the target of that language is software that generically treats protocol elements beginning with x- in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. clue bat please? is there any general semantic to X-? I think one of the main points of the draft is to answer that question with no. -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
Yes, but (as the draft tries to explain) putting this kind of metadata in a name is prone to issues, because it can change -- i.e., when a header (or other protocol element) becomes standard. On 07/03/2012, at 4:54 PM, Paul E. Jones wrote: But it does clue one in immediately to the fact that the parameter is non-standard. Paul -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark Nottingham Sent: Tuesday, March 06, 2012 11:11 PM To: Randy Bush Cc: Randall Gellens; ietf@ietf.org Subject: Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice On 07/03/2012, at 1:52 PM, Randy Bush wrote: To me, the target of that language is software that generically treats protocol elements beginning with x- in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. clue bat please? is there any general semantic to X-? I think one of the main points of the draft is to answer that question with no. -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
I suppose one could argue that X- should never be on the Public Internet, anyway. But they are. If we remove X-, then what will happen is developers will use names that don't have X-. Will that make things better? No. I'd argue it will make it worse. Non-standard extensions do present issues, that's no in question. However, killing X- will only mean other values will be used. At least X- can be ignored. I'm not going to throw up a roadblock to the draft. Call for the end of X- if you want, but I know it will not stop introduction of non-standard values in protocols, so a problem will remain. One way to help this is to get standards through the IETF faster. Some take forever. Paul -Original Message- From: Mark Nottingham [mailto:m...@mnot.net] Sent: Wednesday, March 07, 2012 12:57 AM To: Paul E. Jones Cc: 'Randy Bush'; 'Randall Gellens'; ietf@ietf.org Subject: Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice Yes, but (as the draft tries to explain) putting this kind of metadata in a name is prone to issues, because it can change -- i.e., when a header (or other protocol element) becomes standard. On 07/03/2012, at 4:54 PM, Paul E. Jones wrote: But it does clue one in immediately to the fact that the parameter is non-standard. Paul -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark Nottingham Sent: Tuesday, March 06, 2012 11:11 PM To: Randy Bush Cc: Randall Gellens; ietf@ietf.org Subject: Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice On 07/03/2012, at 1:52 PM, Randy Bush wrote: To me, the target of that language is software that generically treats protocol elements beginning with x- in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. clue bat please? is there any general semantic to X-? I think one of the main points of the draft is to answer that question with no. -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
At 1:19 AM -0500 3/7/12, Paul E. Jones wrote: I suppose one could argue that X- should never be on the Public Internet, anyway. But they are. If we remove X-, then what will happen is developers will use names that don't have X-. Will that make things better? No. I'd argue it will make it worse. Non-standard extensions do present issues, that's no in question. However, killing X- will only mean other values will be used. At least X- can be ignored. I was quite skeptical for a while, but came around to seeing the case that trying to segregate non-standard parameters ends up creating more problems than it solves. You're right that people will use names without an 'x' and the draft encourages this. So, we'll end up with (as I think the draft suggests), situations where 'priority' is the old, non-standard name, and 'urgency' is the new, standardized name, instead of 'x-priority' and 'priority'. But the fact is that names which start out as non-standard hacks end up being de facto standards. That's no better. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- We adore chaos because we love to produce order. --M. C. Escher ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
On Thursday, March 01, 2012 10:47:50 AM The IESG wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Deprecating Use of the X- Prefix in Application Protocols' draft-ietf-appsawg-xdash-03.txt as a Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Historically, designers and implementers of application protocols have often distinguished between standard and non-standard parameters by prefixing the latter with the string X- or similar constructions. In practice, this convention causes more problems than it solves. Therefore, this document deprecates the X- convention for textual parameters in application protocols. ... 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general categories of standard and non-standard parameters in programatically different ways within their applications. Shouldn't this restrict itself to the naming of parameters? Perhaps: 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general naming of parameters in programmatically different ways within their applications depending on if they are standard or non-standard. Other than that nit, I think it looks good. Scott K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
On 3/1/12 12:00 PM, Scott Kitterman wrote: On Thursday, March 01, 2012 10:47:50 AM The IESG wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Deprecating Use of the X- Prefix in Application Protocols' draft-ietf-appsawg-xdash-03.txt as a Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Historically, designers and implementers of application protocols have often distinguished between standard and non-standard parameters by prefixing the latter with the string X- or similar constructions. In practice, this convention causes more problems than it solves. Therefore, this document deprecates the X- convention for textual parameters in application protocols. ... 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general categories of standard and non-standard parameters in programatically different ways within their applications. Shouldn't this restrict itself to the naming of parameters? Perhaps: 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general naming of parameters in programmatically different ways within their applications depending on if they are standard or non-standard. How about this? Implementations of application protocols MUST NOT programatically discriminate between standard and non-standard parameters based solely on the names of such parameters. Other than that nit, I think it looks good. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
Peter Saint-Andre stpe...@stpeter.im wrote: On 3/1/12 12:00 PM, Scott Kitterman wrote: On Thursday, March 01, 2012 10:47:50 AM The IESG wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Deprecating Use of the X- Prefix in Application Protocols' draft-ietf-appsawg-xdash-03.txt as a Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Historically, designers and implementers of application protocols have often distinguished between standard and non-standard parameters by prefixing the latter with the string X- or similar constructions. In practice, this convention causes more problems than it solves. Therefore, this document deprecates the X- convention for textual parameters in application protocols. ... 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general categories of standard and non-standard parameters in programatically different ways within their applications. Shouldn't this restrict itself to the naming of parameters? Perhaps: 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general naming of parameters in programmatically different ways within their applications depending on if they are standard or non-standard. How about this? Implementations of application protocols MUST NOT programatically discriminate between standard and non-standard parameters based solely on the names of such parameters. I'm not quite sure. Is this supposed to be about how one selects names or how one uses them. I'd thought it meant the former, but your revised text sounds like the latter to me. Scott K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
