[Top] [All Lists]

Re: rfc2821bis-3 nits and typos

2007-04-26 23:58:53

John C Klensin wrote:

2.1. Basic Structure:

  ...delivering a message or properly reporting the failure to
do so.

Nit: Change "reporting failure to do so." to "reporting
failure to the originator address.  When a possibility has
been determined that a failure subsequent to acceptance will
not be reported, refusing the message better retains delivery
status integrity and is generally preferred."

That is not a nit, but part of what is now issue 25.

Yes, and it expresses a part of the solution for "THE" issue.

Nit: Consider changing "Sender" to "Transmitter",
"Transmission Channel", or "Dispatcher" to avoid confusion
with "Sender:".  Perhaps adopt server/client rather than abuse
the word sender.  Although this will touch many sentences,
such a change will provide greater clarity going forward.

IMO, too large a change, expecially since SMTP-Sender and
SMTP-Receiver (the terms used in 821) is the terminology of
last resort when terms based on "client" and "server" are
insufficiently precise.


I can try this if enough people think it is important

It is very important, but I hope it's enough if you replace
some "senders" by "clients" where the latter is what you
really want.  Global changes of terminology are tricky, I'm
glad that it apparently worked for the "bounces".

based on the experience with changing informal text to
SHOULD/ MAY/ MUST terminology --which I now expect to have
to back out--

I don't know why you expect that, I saw only one dubius new
"MUST NOT" in the first three chapters.  Admittedly I also
can't say that I insist on much of the new MUSTard, but the
part about "MUST take the responsibility" sounded good.

if people really want to get this done anytime soon... like
this calendar year.

That's IMO realistic.  No new draft soon, please, I'd hate to
drop all WGs I watch only because 2821bis is more important
than all of them together.


<Prev in Thread] Current Thread [Next in Thread>