Issue 33 assigned. See below.
--On Friday, 27 April, 2007 09:52 -0700 Douglas Otis
On Apr 26, 2007, at 11:41 PM, Frank Ellermann wrote:
John C Klensin wrote:
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.
Would it be possible to use SMTP-Sender instead of just sender?
Possible? yes. I'll have to leave to others to figure out if
this is a priority. Everyone should remember that this was
supposed to be a quick effort; we are already moving out of the
"quick" range, IMO.
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".
It might also be clearer to use "transmitting-client" rather
than just "client" when needed. The section title could
change to "SMTP-Senders and Receivers"".
Speaking as editor but with the usual understanding that I'll do
whatever Tony tells me is the consensus: If we are going to try
to fine-tune this stuff because of perceptions of interactions
with terms used in other documents, I'd rather just declare the
effort to switch to "client-server" terminology a failure. That
would mean going back to the 821 terminology of "sender-SMTP"
and "receiver-SMTP" (or some equivalent, although my instinct
would be to stick with 821) throughout, either just dropping
"SMTP client" and "SMTP server" entirely or noting the
equivalence in the terminology section but not using them
afterwards. That is more work but, if the consensus is that we
have ambiguities here, then I think that is the right cure, not
introducing more and entirely new terminology like "transmitter"
As far as the ability to make global changes is concerned,
please note that the stem "bounc" is relatively rare in a
document like this while "transmit", "client", "receive",
"server", etc., are not.
Coming back to a comment above, my time availability after this
week and the general nature of things is such that, if we try to
make this sort of change, revise the ABNF for completeness and a
different approach (see earlier note about descriptive versus
normative uses of syntax productions), and make the added
changes needed to use RFC 2119, my assumption is that we are
talking about a completion date in the last quarter of this year
at the earliest, not, e.g., the beginning of next month. That
is consistent with Alexey's suggestion that he do a review pass
on the SMTP after Lemonade winds down and the deadlines for
other work (in and out of IETF) for which I have responsibility.
That is just my personal opinion, of course.