[Top] [All Lists]

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

2007-04-11 20:04:50

--On Wednesday, 11 April, 2007 16:03 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:

or with its symmetric relative
   550- Don't think I can reach that one
   250  Ah, I found a path

No, that is illogical and that was discovered with FTP as
well. You want to use a inconsequential code that is would not
be interpretation as either negative or positive.

You need to use a code that is not typically used to interpret
an initial negative or positive condition. It would be
illogical do to so.
Doesn't apply because it wouldn't be how it be used.  It needs
to be an inconsequential code not a "heads up" code that may
change status as you point out.

But, Hector, it is exactly this sort of comment that has
convinced me that we need to change the text to prohibit
mixed-code multiline replies.  What I think you are saying is
that mixed-code multiline replies should be permitted iff the
intermediate codes are "inconsequential".   But there is no
concept of an "inconsequential code" in 2821 so, if we were to
write such a rule, we would need to then put in text defining a
new class of codes, presumably with semantics of "ignore" or
"ignore and wait", at least in multiline replies.  But then we
run into the problem that there are no codes which can be use
only in the non-terminal lines of multilines and not as replies,
so we would need to deal with that case, presumably identifying
them and prohibiting their use.  By the time we got that far, we
would be in big trouble because:

(i) Whatever 821 (and 2821) are interpreted as saying about 1yz
codes, it isn't "ignore", "ignore and wait", "inconsequential",
"can't use in final code of multiline reply or in a reply by
itself".   Instead, it assigns at least the outline of semantics
to those codes -- the client has to issue either a "continue" or
"abort" command.   So that would be a clear and incompatible
change to the current standard definition, even if one
interprets the text as permitting 1yz in the first place.

(2) We would need to add several new concepts ("inconsequential
codes", etc.) to the document, concepts that we couldn't
possibly justify adding in at this stage even if they
represented established practice... which I suggest that they do
not in any general way, regardless of what you may be able to
show about one particular case.


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