[Top] [All Lists]

Re: rfc2821bis-01 Issue 18: Usability of 1yz replies

2007-04-11 11:15:53

Hector Santos wrote:

What it probably interested here is that its uses a non-standard less
than 100 code for "informational", so something like this is valid under

    250 whatever

Or even:
   099 Info
   099 Info
   250 Whatever

Very interesting.

Unused in practice, I believe.


I'll say it again this way: this is a common "method" concept in C/S
(Client/Server) designs, especially in a TCP/IP environment. The point
here is that C/S (or even P2P) communication timeouts is generally based
on channel idleness.

I don't disagree.  I merely make the point that a server SHOULD NOT
rely on this design.  I also make the point that modern conditions
on the Internet MAY make a client choose an overall timeout rather
than an idleness timeout.

I believe the RFC should be
reworded to make it clear that all reply codes in a multiline reply
MUST be the same code.  

That would be an unnecessary restriction. Clients or servers doen't
require this tightness.

I believe it was intended by the original authors.  In fact, I think
they didn't even imagine the possibility of different return codes on
different lines.  But I don't know for sure; we'd have to ask.

IMV, this is backwards. This is a server driven control concept.

No, it's *not*.  A server *cannot* expect a client to increase its
timeout just because the server wants it to.  A client and server must
*agree* on a mechanism for processing-in-progress messages.  Just
because your hack happens to work with many SMTP clients today doesn't
mean it's a good design or should be blessed by an RFC.



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