[Top] [All Lists]

Re: rfc2821bis-01 Issue 14 Continuation of 222 greeting and Issue 15 syntax for multiline replies

2007-04-12 12:48:40

Hi Lisa,

Thank you for the clarification here and in your post regarding I-Ds.

It is my engineering opinion, that we can have new "clarification" statements for existing 2821 statements which will not alter its meaning (as it is currently stated), nor change 25 years of wide practice based on the statement that is currently stated, yet provide the opportunity for new development to continue with legitimacy, and also not force certain undesirable operations (post smtp processing with accept/bounce exploit potential).

A lock down will pretty much force POST-SMTP processing for the new augmenting technologies currently under way.

While an extension is conceivable, it will not have provide the maximum impact for legacy operations as would adding new clarifications will have.

With a lock down, the extension will come in one of two flavors:

  1) "break" (update) the new lock down statements being
      considered for 2821bis:

       - All reply codes in multi-line responses must be the same,
       - "1yz-" must not be used in standard 2821 operations.

  2) Introduce new response codes which implies new client support
     (no legacy support).

#1 will have the highest impact, but I don't think it is desirable to do break or change existing protocol (if it was written in 2821bis).

#2 would be the more practical approach, but will not provide the highest impact.

So at this point, I agree with Hansen the "do nothing" conservative approach is probably the best approach. It will at least allow for extension #1 to have a better change of being proposed.

Yes, if need be, I would be more than happy to author an extension. How it is structure will depend on whats decided here.

Thanks for your consideration.


Lisa Dusseault wrote:
Hi Hector,

John's got my support and Tony's to reject new capabilities, extensions, etc in this round of changes, and he's not enforcing that preferentially. In fact there's strong process pressure to reject any additions in order to achieve the status of Draft Standard, so these are IETF rules, not John's rules.

Do you disagree with John on the basis that your proposed change is too important to be put off ? or that it's not a new capability but merely a clarification?

If it's a new feature, please do consider writing up SMTP extension proposals in I-D form -- the fact that John's working on 2821bis should not prevent people from working on useful extensions. The two efforts can and should be separated as far as we can tell.


On Apr 10, 2007, at 7:04 AM, Hector Santos wrote:

You might be able to overcome some of these difficulties in an

extension, but it certainly does not belong in the base spec.

I disagree but I defer to your rules. Thats too bad because I can't help but feel if someone else would had brought this up, you would take a more open minded consideration. I am sorry to say that only because I find it extremely odd that technical clarity in this case is not taken serious when in reality the less serious nits are being debated else where. The odds are very good systems you will be confronted with this ISSUE more so than some of the other issues that essentially have little to no impact in improving the system.

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