ietf-smtp
[Top] [All Lists]

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

2007-03-29 07:46:04

<pseudo-chair hat>

  Matti's questions asking for guidance on maximum limits are in scope.

  Asking for an EHLO response to indicate any such limits is out of scope.

</pseudo-chair hat>

<implementor's hat>

  Side note: An implementation is free to respond with 4xx (e.g., 421,
451 or 452) to the MAIL FROM whenever it wants to shut down the
connection. And some implementations *do* choose to do so because of
local policy decisions.

</implementor's hat>

<pseudo-chair hat again>

  Folks, I'd like to request a favor: Please use separate email messages
to the group to totally introduce new topics. An example is the chapter
naming style issue introduced below.

</pseudo-chair hat again>

        Tony Hansen
        tony(_at_)att(_dot_)com

Matti Aarnio wrote:
On Thu, Mar 29, 2007 at 09:11:29AM -0400, John C Klensin 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.

John,

  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.

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 rationales.

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.

.. 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.


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 1.2.3.4.5 of rfc-12345" than
".. at chapter 1.2.3 paragraphs 7 through 9 of rfc-12345"

Similarly, lacking the detailed parameter conformance checklist
means that one has to go through the main text, and to spot
there all small details in very lengthy chapters.

<Prev in Thread] Current Thread [Next in Thread>