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

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.
Thanks

--
HLS





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.
>
>         hp