On 2/6/2007 1:00 PM, Claus Assmann wrote:
Ok, then we are now at the point where we "only" argue about the
"first reply after data"? That is, your current proposal looks like
this:
* Client initiates by sending MAIL with an extension.
* RCPT returns normal reply codes (no 3yz)
* DATA and the last BDAT return (in order):
1. 353 to indicate the start of server responses
1.a. possible optimization: a single {2,4,5}yz reply code
to indicate the overall transaction status.
2. one reply code per recipient which got a 2yz reply.
3. one end of mail reply code (as in the current ESMTP model,
which is the same as the "final" reply code in
draft-hall-deferrals).
Yeah
So we still have to decide between:
(I) get rid of step 1.: 353 (and increase the timeout to the
first deferred RCPT response),
(II) or use 353 with the optimization 1.a.
and keep it as MAY. If we agree on that then the two issues that seem to
still be open:
1) the hard time limits
2) duplicate avoidance technology does not seem to have been resolved to
everyone's satisfaction yet
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/