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:
250-winserver.com, Pleased to meet you.
250-SIZE 5120000
250-SUBMITTER
250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
250-AUTH=LOGIN
250 HELP
- One that uses the compares each code as a integrity checker:
250-winserver.com, Pleased to meet you.
garbage
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.
--
HLS