--On Saturday, 04 August, 2007 19:09 -0400 Jeff Macdonald
<jmacdonald(_at_)e-dialog(_dot_)com> wrote:
...
John and Ned, you both mentioned 'worth the effort'. Is that
because you both believe the RFC wouldn't be an "Independent
Submission"? I'm very new to this whole process, so forgive me
if this is a stupid question.
It is certainly not a stupid question. The question (at least
my version -- Ned might have a different one) is whether it
would be worth the trouble for existing server implementations
to change their code and existing client implementations to
adapt to the new subseries. Clearly the latter should fall
back to "first digit" if they don't recognize the second one or
what is going on generally, but we've had a lot of nasty
experiences with implementations that think they know more than
the specs think they ought to know and that might balk at a new
subseries.
I see that as an issue for SMTP status codes but not for enhanced status codes.
More specifically, Appendix E of RFC 821 (Theory of Reply Codes) gives lists of
the possible values of the first and second digits of SMTP replies and says
nothing about how new values would ever be defined. It is therefore a
reasonable inference that values not on the list are a protocol error. As for
the third digit, again the text is silent but since there's no list giving all
possible values, merely collections of the codes mentioned in the document, it
is a lot harder to argue that values not given in RFC 821 are an error.
But none of this is the case for exhanced status codes. The specifications
for these are quite clear in regards to extensibility. RFC 1893 said:
New subject and detail codes will be added over time. Because the
number space is large, it is not intended that published status codes
will ever be redefined or eliminated. Clients should preserve the
extensibility of the code space by reporting the general error
described in the subject sub-code when the specific detail is
unrecognized.
There just isn't a reasonable way to derive the idea that 5.8.n is an error
from these specifications. The worst case issue I suspect you're going to see
is some sort of "error subject is unknown" message come out, and given the
relative paucity of MUAs that do this sort of interpretation even this is going
to be unusual.
So the question is whether this change would have enough value
to tell the community that they should go change things
But in a compliant implementation there just isn't that much - if anything - to
change. And while I have some sympathy for implementors who in good fairh read
RFC 821 as restricting the available status code values, I have ZERO sympathy
for people who read RFC 1893 this way. At some point we have to draw the line
and call broken implementation what they are: Broken.
and
whether the implementer community would believe it has enough
value to be worth the trouble to make those changes. I have my
doubts about both.
My issue is with moving some 7.n codes to 8.m codes. I see no problem with
defining 8 as the place for all future policy codes and putting a bunch of them
in there.
Ned