--On Tuesday, 10 April, 2007 17:24 -0700
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.
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.
p.s. still hoping to see some text for RFC2821bis from you.