[Top] [All Lists]

Re: rfc2821bis-01 Issue 17: all contination lines must use same code

2007-04-11 05:53:39

--On Tuesday, 10 April, 2007 14:50 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:

David F. Skoll wrote:
Hector Santos wrote:

    Under most scenarios, servers SHOULD use the same reply
    code for each multiline response line when it is going to
    be displayed at the same time. However there are
    scenarios (Keep Alive Client Timeout issues) where
    servers MAY use "150-" as an alternative reply code in a
    continuation line when the server needs to issue a
    heartbeat to keep the client alive during unsual delayed
    backend processing:

I don't like that.  There's no reason to assume that parts of
a multiline response will have any effect on the client
timeout.  It might not reset its timer just because it gets
part of a reply back.  Maybe many current implementations do,
but that's just good luck.

I believe that a proper negotiated ESMTP extension for
"keepalive" intermediate replies should be developed.  We
shouldn't try to hack something in.

Hi David,

I agree 100% and this issue began a few years back including
during the last previous call out for 2821bis discussions
where I brought the "Keep Alive" consideration.  So John is
very aware this isn't a first time discussion.  I might just
go ahead and write a I-D finally.  Back then I had never
written an I-D. But with a few under my belt now, I am more
familiar with the process and more comfortable writing one if
need be.

However, for 2821bis, I just would like make sure that it
doesn't pre-empt such new efforts.   Thats really all I would
like to seek here and thus I go back to my original post to
Frank with a suggested text, which was really just a starting
point and would be very happy for a documentation person to
reword it appropriately:

One small clarification, just to be sure we understand where we
disagree, if at all.  I am not proposing this, just trying to

Suppose 2821bis were clarified in just the way I think you have
been arguing against.   In other words, it clearly said:

        (i) In a multiline reply, all lines MUST use the same
        reply code.
        (ii) 1yz reply codes MUST NOT be sent by a server unless
        they are specified by a specific extension that
        overrides this provision of the specification for a
        specific purpose.
        (iii) multiline replies MUST NOT be used as an attempt
        to affect client timing or timeouts.

I hope everyone understands that nothing in 2821 prevents an
extension from being designed, proposed, and adopted that, if
appropriately agreed to between server and client, changes any
or all of those rules.   If 2821 is not clear on that topic,
then it should be and I would welcome appropriate text for

To the extent to which the concern is that making these rules
more specific (or implied prohibitions more clear) in 2821bis
would prevent such extensions, I think we need to clarify that
the concern is groundless.

Does that bring our positions closer together?


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