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 "<[EMAIL PROTECTED]>" 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
