On Thu, 9 Jan 1997 23:34:44 EST Roger Fajman <[log in to unmask]> said:
>(2) The notary codes are described in RFC 1893, a standards-track
>RFC. This is not a "semi-standard list of codes."
What I meant is that these codes are similar in nature to the SMTP reply
codes. If you look in the RFC, you will find (just taking a few common
examples, and trying not to pick the exotic ones):
550 Requested action not taken: mailbox unavailable
553 Requested action not taken: mailbox name not allowed
554 Transaction failed
In practice, the actual error that the MTA is trying to convey can vary
widely from the descriptions given above, and it is common for a given
product to have different messages associated with the same formal reply
code, to describe different errors where the desired response from the
MTA at the other end is the same. This is not to say that the official
descriptions convey no information, but you cannot reasonably claim that
the official description always matches the reported problem, even
setting aside cases where people have used the wrong codes, or just
couldn't find a code that was a reasonable match for what they had to
report.
>(3) I don't understand why you say that the same code can mean
>different things in different contexts.
I imagine that sendmail, an X.400 gateway, an All in one mail router, a
cc:Mail gateway, a firewall and a BITNET mailer will have widely varying
phrasing and interpretations of the codes.
>(4) The Status field of a DSN (Delivery Status Notification),
>defined in RFC 1894 (also standards-track), does not require
>error message text.
This is correct, however the same could be said about SMTP reply codes.
If I want to write a SMTP agent that just replies with a number, this is
a perfectly valid implementation, and as you know other MTAs are
forbidden from even looking at the text. Luckily all (as far as I know)
SMTP developers understood the merit of providing human-readable text
that describes the actual error that they were trying to report.
Similarly, there is a "Diagnostic-Code:" field in the DSN which LISTSERV
does use when present.
What I am trying to say is that a MTA that says 5.1.1 is no different
from a SMTP server that says "554 ERR" or just "554". LISTSERV treats
these two situations in the same manner, the only difference is that SMTP
servers typically provide a descriptive error text whereas, DSN being new
and all that, not all MTAs that use DSN fill in the "Diagnostic-Code:",
even though (being for the most part existing products into which DSN was
retrofitted) they do have code to generate these one-line descriptions
everywhere that they occur. They just haven't had the time to add a
"Diagnostic-Code:" field with these errors, or maybe they haven't
realized the need. This is a new standard and we need to give people some
time to implement it.
>(5) The first section of the multipart/report structure used for
>DSNs is available for a text description of the error. This is
>for users whose systems don't understand DSNs. LISTSERV discards
>this section in Auto-delete processing.
Yes but this is not computer parseable, and LISTSERV needs a reasonably
short (1-2 line) error description.
>(6) You shouldn't just say "5.4.5 Network Congestion". It should
>at least be "5.4.5 Permanent error, network congestion" or, more
>likely, "4.4.5 Persistent transient error, network congestion".
>But RFC 1893 contains longer descriptions of the meaning of the
>codes and you are free to use those or reword them.
For the auto-deletion report, I need something that fits on a line or
two. Quite honestly, I have no idea what this network congestion code is
for (if the network is congested you should just try again later), but I
assume it has uses or it wouldn't be in there. If phrased in a more
specific context, I don't doubt that I would understand what it means. I
must be missing the obvious, but I think this illustrates the problem
with these generic codes.
Basically I don't understand why you seem to think that accurate failure
information can be omitted at the source because it can be regenerated
from a static, high-level table of generic meanings at the destination.
Eric
|
