[Top] [All Lists]

Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463

2007-08-06 18:29:04

--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

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

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.

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.