[Top] [All Lists]

Re: RFC2821bis-01 Issue 8 number of message transactions per connection ?

2007-03-29 07:46:16

--On Thursday, 29 March, 2007 16:54 +0300 Matti Aarnio
<mea+ietf-smtp(_at_)nic(_dot_)funet(_dot_)fi> wrote:

However, I think the conclusion is the same: since there are
no restrictions on this now and imposing any limits (or
announcement of limits) in the client-server transaction would
require a new extension, it is probably out of scope.  I
imagine we could include some general guidance if there were
sufficiently strong consensus behind it, however.


  I am not asking for a new extension, just clarification of
the specification so that   Joe Random Spamflighter  can easier
understand what is specified, and what is not.

Certainly a reasonable idea in principle.
Perhaps there should be a new Appendix that tabulates limits
in condensed manner making checking them simpler in style of
IEEE 802.* Conformance Pro Formas ? 
It would list limits and references to main text for

Somewhat in style of RFC 1123  "SMTP REQUIREMENTS SUMMARY"
table ? That table is more about "feature checklist" than
protocol parameter profile listing, but applying the idea.

(moved to separate note)

.. and of course, there is completely missing a text about
how many MAIL--DATA transactions there are expected to be
supported in a given connection, and how long that connection
is expected to be alive.   It can be inferred, but explicite
telling is better.

Agree in principle.  In practice, someone needs to make a
proposal as to what that limit should be and get consensus on
it.   I imagine that Jon left it out of 821 because of an
implementation model: The existing maximum and minimum value
specifications tend to talk about lengths and buffers.  Since a
RSET or completion of the DATA command are specified as clearing
all state other than whatever is established by the EHLO itself,
it would seem that there is no justification to specify bounds
on that basis.  However, I think we would all agree that an
implementation that restricted things to one transaction per
connection was weak if not broken.

So I think we need a proposal.

Also, a style issue is that when a chapter is defining more
than one thing, that chapter should have numbered sub-chapters.
It is far easier to point to somebody that "your filter is
violating expectations at of rfc-12345" than ".. at
chapter 1.2.3 paragraphs 7 through 9 of rfc-12345"

(moved to separate note)