Jeff Macdonald | 8 May 04:31 2009

transaction commands, errors and 'same state'


I was reviewing 5321 and I see that it states for HELO/EHLO and MAIL
that if there is an error, that the server must stay in the same state
(section 4.1.4). This paragraph starts talking about MAIL (well, I
think it is):

If the transaction beginning command argument is not acceptable, a 501
failure reply MUST be returned and the SMTP server MUST stay in the
same state.  If the commands in a transaction are out of order to the
degree that they cannot be processed by the server, a 503 failure reply
MUST be returned and the SMTP server MUST stay in the same state.

but the last sentence seems to be talking about RCPT & DATA and only
says stay in the same state regarding command sequence. But an error
for RCPT should also keep the server in the 'same state' too, right?
Perhaps this is mentioned else where, but the words 'same state' are
only used in section 4.1.4.

Would clarifying this be acceptable? Or am I nit picking?

--

-- 
Jeff Macdonald
jmacdonald <at> e-dialog.com

SM | 8 May 06:05 2009
Picon

Re: transaction commands, errors and 'same state'


Hi Jeff,
At 19:31 07-05-2009, Jeff Macdonald wrote:
>I was reviewing 5321 and I see that it states for HELO/EHLO and MAIL
>that if there is an error, that the server must stay in the same state
>(section 4.1.4). This paragraph starts talking about MAIL (well, I
>think it is):

That section is about the "order of commands".

>If the transaction beginning command argument is not acceptable, a 501
>failure reply MUST be returned and the SMTP server MUST stay in the
>same state.  If the commands in a transaction are out of order to the
>degree that they cannot be processed by the server, a 503 failure reply
>MUST be returned and the SMTP server MUST stay in the same state.
>
>
>but the last sentence seems to be talking about RCPT & DATA and only
>says stay in the same state regarding command sequence. But an error
>for RCPT should also keep the server in the 'same state' too, right?
>Perhaps this is mentioned else where, but the words 'same state' are
>only used in section 4.1.4.

If there is an error for RCPT, e.g. invalid recipient, the server 
must be kept in the same state.  The "state" refers to the command 
sequence.  The paragraph you are referring to covers MAIL, RCPT and 
DATA.  See section 3.3 too as that section discusses about mail transactions.

>Would clarifying this be acceptable? Or am I nit picking?

(Continue reading)

Pete Resnick | 14 May 05:23 2009

email-arch intro


Hi all,

In among all of the other balls I have been juggling (or dropping 
depending on your view of it), I've definitely let this one get far 
too close to the ground. I've been talking to Klensin about his 
earlier expressed concerns regarding the doc, and found talking to 
Crocker who (shock of all shocks) seems to agree with the overarching 
concern. What it comes down to is that the email-arch doc ought not 
turn into a club with which to beat other standards (or the 
applications that implement them). The architecture presented in the 
document is a model under which we believe our protocols work, but 
there is always a difference between architecture and implementation 
and sometimes it is perfectly fine for protocols to break with the 
architecture.

So, I think the architecture document needs an intro somewhere saying 
as much. Here's an attempt taken from my conversations with both of 
them:

---
1.3 The Role of This Architecture

An Internet service is an integration of related capabilities among 
two or more participating nodes. The capabilities are accomplished 
across the Internet by one or more protocols. What connects a 
protocol to a service is an architecture. An architecture specifies 
how the protocols implement the service by defining the logical 
components of a service and the relationships among them. From that 
logical view, a service defines what is being done, an architecture 
(Continue reading)

Dave CROCKER | 14 May 14:38 2009
Picon

Re: email-arch intro


Pete Resnick wrote:
> In among all of the other balls I have been juggling (or dropping 
> depending on your view of it), I've definitely let this one get far too 
> close to the ground. 

Folks,

Alexey is including email-arch in the next IESG telechat.  Unfortunately, this 
means that he needs me to submit a revised, post-last call version by tomorrow, 
Friday.  So we have only today to discuss the text that Pete has circulated. 
Fortunately, the text is non-normative.

Also fortunately, I think the draft that Pete circulated does its job pretty 
well.  I think the IETF really does not have all that much experience producing 
architecture documents and explaining their role in relation to the service they 
describe or the protocols they engender.  So as a community, we do not have a 
lot of shared perspective or language for this sort of exercise.

That said, I think that the text does serve to help the reader understand the 
place that this sort of document should occupy amongst a set of technical 
specifications -- both the uses and the limits.

Given the time limit, I'll ask folk to draw a very sharp distinction between 
major objections -- problems with the text that are so serious the text MUST NOT 
be used in its current form -- versus minor ones -- tweaks that could make it 
better.

For major objections, please make very clear why you think disaster will befall 
the Internet if we use the text.  (Of course, suggestions for remedying this are 
(Continue reading)

SM | 14 May 15:36 2009
Picon

Re: email-arch intro


Hi Pete,
At 20:23 13-05-2009, Pete Resnick wrote:
>In among all of the other balls I have been juggling (or dropping 
>depending on your view of it), I've definitely let this one get far 
>too close to the ground. I've been talking to Klensin about his 
>earlier expressed concerns regarding the doc, and found talking to 
>Crocker who (shock of all shocks) seems to agree with the 
>overarching concern. What it

I'm glad to hear that you agree with each other.

>  comes down to is that the email-arch doc ought not turn into a 
> club with which to beat other standards (or the applications that 
> implement them). The architecture presented in
>  the document is a model under which we believe our protocols work, 
> but there is always a difference between architecture and 
> implementation and sometimes it is perfectly fine for protocols to 
> break with the architecture.

One of the reasons not to have a rigid architecture (after that fact) 
is that the protocols won't be an exact fit.

>So, I think the architecture document needs an intro somewhere 
>saying as much. Here's an attempt taken from my conversations with 
>both of them:
>
>1.3 The Role of This Architecture
>
>An Internet service is an integration of related capabilities among 
(Continue reading)

Jeff Macdonald | 14 May 16:15 2009

Re: email-arch intro


On Thu, May 14, 2009 at 06:36:30AM -0700, SM wrote:

<snip>

> One of the "problems" with the email-arch is that the document does not 
> constrain itself to the higher level only.  It would have made matters 
> easier if the document was descriptive instead of prescriptive.
>

<snip>

> If I understand correctly, the last part of the last sentence excludes 
> existing protocols from having to explain the variance.  What you are 
> proposing is to have designers explain the differences between the 
> architecture and core protocol documents.  That presumes that the 
> designers have a good understanding of these documents.  The documents 
> are already quite lengthy and I think that we will see more 
> inconsistencies once we go down that path.

Since this seems to be the first document of this type for the IETF, I
suspect it will take some time to perfect the type of language such a
document should have. But we have to start from somewhere and I believe
this is excellent start.

So +1 to Pete's text.

--

-- 
Jeff Macdonald
jmacdonald <at> e-dialog.com
(Continue reading)

Jeff Macdonald | 14 May 16:51 2009

Re: transaction commands, errors and 'same state'


On Thu, May 07, 2009 at 09:05:47PM -0700, SM wrote:

> If there is an error for RCPT, e.g. invalid recipient, the server must be 
> kept in the same state.  The "state" refers to the command sequence.  The 
> paragraph you are referring to covers MAIL, RCPT and DATA.  See section 
> 3.3 too as that section discusses about mail transactions.
>
>> Would clarifying this be acceptable? Or am I nit picking?
>
> If you can come up with better text, please send it.

I will. May take some time, but I will.

--

-- 
Jeff Macdonald
jmacdonald <at> e-dialog.com

John Levine | 14 May 17:29 2009

Re: email-arch intro


> The architecture presented in the document is a model under which we
>believe our protocols work, but there is always a difference between
>architecture and implementation and sometimes it is perfectly fine
>for protocols to break with the architecture.

Your proposed text looks fine.  I hope we don't have to worry about
people appointing themselves as architecture purity police, but this
is a reasonable explanation of why anyone so inclined needn't bother.

R's,
John

J.D. Falk | 14 May 18:29 2009

Re: email-arch intro


Jeff Macdonald wrote:

> So +1 to Pete's text.

+1

--

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Tony Hansen | 14 May 18:52 2009
Picon

Re: email-arch intro


+1

	Tony Hansen
	tony <at> att.com

Pete Resnick wrote:
> 
> ...
> So, I think the architecture document needs an intro somewhere saying as
> much. Here's an attempt taken from my conversations with both of them:
> ...


Gmane