[Top] [All Lists]

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

2007-04-12 05:38:12

Thanks for your comment.

First let me say, as a problem solver and modern developer, we are always looking for solutions to today issues, problems and future issues as you can come about.

Clearly, one would naturally assume the prefix numbers would be the same. Sorta born from a EDI or PUNCH code mentality with a 5 digit numeric column, with a 6th column, if punched, relates to a continuation. Anyone with development experience will know that in principle.

But when you are confronted with a problem, you need to sometimes to think out of the box, to explore, and then, see, as in this case, if you can make it work with the current system. That would be ideal.

To put this into context, the "idea" was born from a real timeout issue with FTP client software. We needed a solution PRONTO to solve large file upload backend processing with our FTP hosting system specializing in the Medical, Insurance, Payroll business.

The problem was solved with a similar "150-" continuation line concept to keep the FTP client alive which has a DOCUMENTED behavior of using a ~30 second SOCKET timeout to wait on the completed file upload server response. That was nearly 6 years ago. Keep in mind that making this a server driven solution was vital and the customer client base was wide and had no control over the FTP client (i.e., we could not mandate a client change).

Move to SMTP, with the advent of AVS solution adventures and other SMTP level backend processing needs, it was clearly envisioned similar timeout issues would be very possible.

The idea was tested for SMTP but not in a full blown effort.

I believe it was IETF OPES WG where I brought up the potential need for a timeout solution for these new "HOOKS" or "SHIMS" or "PROXY" processing ideas for SMTP. It was the first time where we had an "official IETF" incentive to research a similar solution for SMTP. That was done and the proof of concept was tested and confirmed with various MUAs and a few MTAs, including our own. The "150-" was also a solution for SMTP to prevent client timeouts.

I should note, that I checked using the "same code" idea first but found that didn't work well because some of the clients were looking for 2xx-, 4xx-, 55x- and ignoring 150-. But that was ok, because it didn't make sense to use 2xx-, 4xx-, 5xx- since the whole point is that you don't know what is the final result until it reaches that point.

Those experiences were expressed in OPES and here.

What does that mean?

Well, we have two choices:

1) Ignore it, and if someone needs this, you can suggest extensions.
   That doesn't solve the compatibility problem.

2) We can embrace it and use the idea to solve a potential problem
   and to help new developments currently going on.

There is really nothing in 821 or 2821 that prevents the idea. There is the natural presumption that all codes must be the same, but that isn't confirm 100% and also 821 give you the 25 year old suggestion to consider just the last line and that is very important.

The 1yz description has a "view" that it is only usable in extensions only, but that isn't clear either.

Hence, IMV, I believe using 150- for SMTP to resolve a the potential TIMEOUT issue with backward compatibility is a valuable and viable solution.

I can understand the technical documentation consistency issues and I can understand the affinity for documentation people to get it all right.

If that is where it must go, fine.  If it reduces confusion, fine.

But consider whose is being confused? Not me. Not people who see the potential problem, not people who are looking for a solution. We understand the issue. We know what we are facing. It will hurt the efforts to improve the system, and in this particular case, I believe very strongly the *proper and responsible* solution is to embrace it and legitimize it. Not close the "Loophole, the Hack, or Trick" as it has been improperly labeled.



Peter J. Holzer wrote:
On 2007-04-11 15:07:22 -0400, Hector Santos wrote:
John C Klensin wrote:
But, as several people have pointed out, there is ample reason
to infer an assumption that all codes in a multiline reply will
be the same from the text.
You know thats fine, and its a natural assumption. But its doesn't represent reality and that reality has evolved from the fact it has been possible all along to have inconsequential and different reply codes in continuation lines.

Remember the ONLY thing that a developer has to go by is a 25 year old suggestion and it is the ONLY thing to go by for implementing a extremely no brainer concept that the only ultimate reply code is the last one, hence why it is in place in wide practice. It is not by coincidence. Why would any system not USE the only logical suggestion for a reply code design is beyond me.

One reason why a system might use the first instead of the last code is
that it just collects the whole reply before looking for a return code.
In this case it is a lot easier to just use the first three bytes of the
reply than scan backwards for the penultimate CRLF sequence and use the
next 3 bytes after that. In just about any programming language except C
and Fortran that approach sounds at least as "logical" to me as using
the last code.

I honestly don't grasp the resistance.

My understanding of the RFC has always been that an SMTP command can have only
one result code and that in multiline replies this (singular!) code must
be repeated on every line. Others seem to have interpreted this the same.
You are the first person I know who interpretes this differently.
Therefore I think your suggestion is a change in the RFC as it is
commonly understood, and not just a clarification. Such a change would
move the RFC back to "proposed standard".

If this has all to to do with your RFC time-line, thats one thing, but
lets not try to continue to look for reasons to not legitimize what is
really a wide practice.

Is it wide practice? I never encountered it, but I do admit that I don't
habitually scan SMTP connections.


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