On Thu, Feb 28, 2008 at 01:24:43AM +0100, Frank Ellermann wrote:
Mark E. Mallett wrote:
[3.1 3rd paragraph about initial 554]
I believe this is actually a way to reject a "session" and not
a "transaction". Since "transaction" (or "mail transaction")
is a specific term used in this document to refer to something
within a session, I think that it's not correct here.
OTOH 3.1 is "Session initiation", it's not exactly easy to be
confused about the topic... ;-) A 554 in the session initiation
in a certain *IS* a session, and it prohibits to reach a state
where a transaction could begin.
Yeah I see that too. But I think it's less accurate to say that the 554
greeting rejects a "transaction" than it is to say that it rejects a
"session" -- at least a session that will do anything. And: a session
that refuses to process commands is not really a session. But...
reading your remarks, I can see that just substituting "session" for
"transaction" is still not exact (tho I think it's better); what I was
trying to get at was more like you did say. E.g. more like:
The SMTP protocol allows a server to formally enter into a session
where no mail transactions will be accepted, as follows:
or even
The SMTP protocol allows a server to formally enter into a [fruitless]
session where no commands other than "QUIT" will be processed, as
follows:
Basically I think that the term (and the concept of) "transaction" is
fairly important and some of my comments in the original posting were
related to the document being accurate and complete about it. More
exactness may have no practical use at the moment; because indeed the
answer to the question you ask later, "Do you know practical
interoperability issues wrt the end of a transaction ?" is "no." But I
would say that that's not all that evaluating a document is about.
I certainly don't think a big long discussion about any of those points
(related to the definition and specification of "transaction") is an
exciting idea at this late time; I made them because I was already
making some comments, and I could not help but at least think about them
while I was reading the document.
Re some of your other responses: the previous paragraph is the gist of
what I would say, rather than go point-by-point.
That said...
one could believe that another DATA command could be issued
at this point, or that further RCPTs could be given, etc.
The first paragraph of section 3.3 ends with:
| Then a DATA command initiates transfer of the mail data and
| is terminated by the "end of mail" data indicator, which also
| confirms the transaction.
Do you want "unrevocably initiates the end of the transaction",
or similar ?
That is essentially what I was getting at, yes.
Trying to figure out what you mean, IMHO it could
make sense to split section 3.3 into an intro (1st paragraph),
3.3.1 (MAIL FROM, 1st step), 3.3.2 (RCPT TO, 2nd step), and
3.3.3 (DATA, 3rd step).
My point was merely that nothing says the transaction is closed after
DATA, and just numbering the steps wouldn't change that. One might
think that a client could send:
MAIL FROM
RCPT TO
DATA
RCPT TO
DATA
Now, somebody would run into a wall trying to talk to any existing
servers that support this conversation, but again, one should be able
to test correctness against a document as well as against the real world.
(Hmm, and I said I wouldn't go on further about it..)
Yes, that is better. John will anyway hate us for discussing
original 2821 text after the 2821bis Last Call, I would write:
| When normal (2yz or 551) responses are returned from a VRFY
| or EXPN request, the reply MUST include the <Mailbox> name
| with a "<local-part(_at_)domain>" construct, where <Domain> is a
| fully qualified domain name.
that is better, yes.
LOL. Another future erratum bites the dust. Thanks for a review
from scratch, I fear nobody else did this for some months / years.
Well, it's been a while for me, at least. The thing is, one can always
find things (and yes, there were things I *didn't* mention, I do have a
threshold of some sort :) ), so going over and over a document can be a
never-ending process. Doesn't mean people shouldn't do it now and then,
though.
mm