Frank Ellermann wrote:
Kari Hurtta wrote:
Seems that http://www.iana.org/assignments/mail-parameters
lists VERB
Interesting, apparently they had some rather odd rules about
registering extensions (Ned 1, Frank 0). But otherwise it
it is a clear "opt-in" extension, both sides are supposed to
know what the effect of VERB is, no problem for 2821(bis).
Is it already clear that "buy the bat book" is not what we
want for registered extensions ?
Frank (page 403, F=I)
If you think thats interesting, check out this *published book" with an
entirely different (and very logical) interpretation for 1yz:
http://www.tcpipguide.com/free/t_SMTPRepliesandReplyCodes-2.htm
1yz Positive Preliminary Reply
An initial response indicating that the command has been
accepted and processing of it is still in progress. The SMTP
sender should expect another reply before a new command may be sent.
Note that while this first digit type is formally defined in the
SMTP specification for completeness, it is not currently actually
used by any of the SMTP commands. That is to say, there are no
reply codes between 100 and 199 in SMTP
WRITTEN AND PUBLISHED IN A TCP/IP GUIDE BOOK FOR PETE'S SAKE!
If makes you wonder why the AUTHOR wrote this and it makes you wonder
the number of *unimportant" in-house SMTP implementator readers actually
followed and implemented it depending on their needs.
The ISSUE I have with all this what I think is being inconsistently
applied here for this issue and Multiple response lines, is that for
some ODD ball reason we don't think locking it down will break code
because a few don't think it its being used the enough "superstars" and
"common systems" when in fact it was always possible in the 25 year
history of SMTP, following a formal specifications (see below), there
was NEVER really a concern that it will break a system if you did use
it. The concern was simply never there following SMTP allowed to do
this without any minor details that it will break a system.
But instead of at least making these two issues a SHOULD, it is
incomprehensibly made a MUST - a lock down - which essentially does
three things:
1) It now makes any system that is using this in a published
and unpublished way, NON-COMPLIANT, including "superstars."
2) If any new SMTP developer followed 2821bis or the new standard
the would come from this work, inevitably, they will come across
a system where they will have a problem reading 1yx response lines.
The end result is that they need to CHANGE their code to support
these "legacy" systems,
3) It literally makes it a SHOW STOPPER for current and future work in
this area - OPES is now completely dead - won't have any chance of
maximizing adoptability.
So never mind about changing a 25 year old written functionality, from
an engineering and practical stand point, it makes absolutely NO sense
to lock down these items simply on the basis that SOME believe it isn't
being used - it isn't simply true.
Finally, I've been ask to write an I-D that will literally propose to
UPDATE and CHANGE the new specs to bring it back to the OLD spec!
Eh? There is something wrong with that approach.
--
HLS