[Top] [All Lists]

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

2007-04-22 12:20:40

Frank Ellermann wrote:
Kari Hurtta wrote:

Seems that
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:

  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


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.


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