[Top] [All Lists]

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

2007-04-11 04:26:17

John C Klensin wrote:

> All that I have been objecting to is trying to use 1yz replies
> in a continuation context to fake up that "keep alive" behavior.
> And I object to it largely because of a sense that too many
> clients will impose logic that will ignore those intermediate
> responses and time out anyway.  Certainly there is nothing in
> 821 or any of its successors that suggests restarting a timer
> that is waiting on a reply code with each line of the reply that
> is received.  Of course, some systems might do that, but it is
> nothing on which a server should depend.... again, absent an
> extension that is used to get specific agreement from the client
> about how the intended "keep alive" is to be expressed and
> interpreted.

From the onset, I tried to approach this from a technical clarification standpoint with no mentioning of "keep alive":

   Only the final or last reply-code is important in a multiline
   response. The client MUST|SHOULD use the final line as the ultimate
   server response.  It is possible for a server to use a
   preliminary reply code 150- as part of multiline response
   with a final non-continuation completion code.

But in practice, I couldn't find any other reason for the last sentence to exist other than to use an example that illustrated a "keep alive" or "please wait" concept, and to tie it with other official IETF WG efforts, OPES. So I showed this too:

   For example:

   354 Please Start sending....
       [ client uploads message ]
   150-Please Wait...
   150-Please Wait...
   451 Sorry, Rejected, try again later

But I always thought it wasn't necessary, and simply having a clarification on three key questions would be sufficient:

  - Must all the reply codes be the same?
  - If not, the final return code (last line) is valid code?
  - 150 SHOULD/MUST NOT be used without extended clients?

I think once this is clear, then you lay the ground work for such ideas as the official IETF synergistic efforts such as OPES, DKIM to have a enhanced chance of implementation where is it very realistically conceivable there might be "time out" issues.

I think this more about clarifying what already exist and not introducing new functionality. However, the benefits from the clarification is new functionality.

The specific "keep alive" functionality still needs to widely tested. But the proof of concept is well established. It does work and there is no surprise from a programmability technical standpoint that it does. Most, if not all, timeout logics are based on "silence" or "idleness" so it was not difficult the extension of the FTP usage to SMTP as well.

So can a server depend on it? I say it is damn good engineering guess that will work. :-) and it did.

But am I suggesting that it should be WRITTEN as such?

No, not until you have the 3 questions above first clarified and go from there.

Like I said, you do have 3 type of clients:

 - One that uses the first reply-code and assumes it will be the
   same for all subsequent lines:

   example:, Pleased to meet you.
   250-SIZE 5120000
   250 HELP

 - One that uses the compares each code as a integrity checker:, Pleased to meet you.
   250 HELP

 - and one that simply looks for the last line and ignores
   all preceding lines.

By far, the last logic is what I find in the field, but I've seen the others in smaller smtp client scripts, logic, etc. But we shouldn't be surprise because 4.2.1 does recommend that only the last line is important.

Is the statement current in 4.2.1 enough? Maybe it is. Maybe that explains the proof of concept does work because most SMTP clients do follow the 4.2.1 last line suggestion.

So in that vain, maybe Hansen is right with his personal hat suggestion:

   "This can be translated as: don't do anything now that would
    prevent such an extension from being written."

But I do think some simple clarification may prevent such heartaches in the future and may also begin to prepare clients to naturally consider such things in their 2821bis improved software.

Maybe the only question for consideration is this sentence:

   The client SHOULD use the final line as the ultimate
   server response.

in combination or replacement of the last paragraph in 4.2.1:

   In many cases the SMTP client then simply needs to search for a line
   beginning with the reply code followed by <SP> or <CRLF> and ignore
   all preceding lines.  In a few cases, there is important data for the
   client in the reply "text".  The client will be able to identify
   these cases from the current context.