--On Tuesday, 10 April, 2007 17:24 -0700
ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
...
Enhanced status codes, OTOH, are only used by a single
protocol - SMTP - that's incredibly widely deployed.
Interoperability and security considerations are of paramount
importance here. It is therefore essential that any codes that
are defined be carefully and completely reviewed for conflicts
and clarity and there can easily be serious security
considerations attached to their definition and use. While I
think the chances are excellent that the IESG would, upon
reviewing any independent submission that defined such codes
improperly, tell the RFC Editor that the document is in
conflict with the IETF's ongoing work on SMTP, that therefore
it should not be published, and that the RFC Editor would
agree, I don't want to take even a small risk.
While I agree with you in principle, I think we need to be a bit
careful here. If the goal is to prevent the same code from
being used for different purposes, I think it is an unpleasant
necessity to recognize and register codes acquired by squatting
based on non-conforming code that has become deployed widely
enough to be significant.
If so, that is NOT an argument for the "RFC Required" model - I see essentially
no chance that a code-squatter is going to write an RFC of any sort, let alone
write one but then send it to the RFC Editor instead of putting it through the
IETF process.
And there's plenty of "running code" in this space - for example, there are
heaven knows how many nonstandard header field in use, but aside from the
attempts by Jacob Palme and other third parties leading up to the current
header registration model, how many independent RFC submissions have there been
by authors seeking to document their header usage?
Have a look at the registration-specification language in
draft-klensin-smtp-code-registry-00 (a parallel development to
Tony's draft that I hope will be quickly consolidated with it)
and let us know what you think.
You have gone with the "specification required" approach. This is in one sense
more lenient than the "RFC Required" since it allows for non-RFC specificaitons
and would avoid the problem that code-squatters rarely if ever seem to be
willing to write RFCs to document their usage.
However, in another sense it is less lenient since it requires approval by a
designated expert. I think this is sufficient (barely) to address my concerns
about overlapping or poorly defined codes getting into the registry.
However, one of the requirements for expert review is that the review
criteria be clearly spelled out in the registration document. I don't
think what you have is sufficient in this regard. I think it needs to have
a list of requirements, such as:
(1) The meaning of the code must be clearly defined.
(2) The code most not duplicate the functionality of a previously defined
code.
(3) Whenever possible the use-cases new codes should not overlap the use-cases
for existing codes, except when a new code is intended to allow
identification of a more specific subcase of an existing code.
Finally, the document should say that exceptions to the rules can be made
when an unregistered code has achieved significant deployment since
the main purpose of the registry is to document all code use in order to avoid
confusion and prevent multiple different definitions for the same code.
Ned