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) clarify, before this document is approved, what
the requirements (and "really strong suggestions") actually are
in a way that makes it clear why they should not apply to
documents of this type.
Just my opinion.
john
--On Thursday, March 01, 2012 10:47 -0800 The IESG
<iesg-secretary(_at_)ietf(_dot_)org> 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(_at_)ietf(_dot_)org mailing lists by
2012-03-15. Exceptionally, comments may be sent to
iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf