Subject: [EAI] A few comments on SMTPEXT-00 I-D

From: Yangwoo Ko <[email-masked]>
Date: Sun, 04 Jun 2006 17:23:45 +0900

Dear Jiankang and others,

(1) ALT-ADDRESS and ATOMIC should have no relationship.

smtpext-00 says:
 > The value of "ALT-ADDRESS" may be set by sender or be
 > gotten by using some algorithmic transformation according
 > to the value of "ATOMIC".

The above quote tries to tightly connect ALT-ADDRESS with
ATOMIC. But, it is just too complicated. My understanding
can be written as:

 > Alternative address for downgrading can be obtained from
 > the value of "ALT-ADDRESS" set by sender or can be gotten
 > by using some algorithmic transformation if the value of
 > "ATOMIC" is "y".

(2) ATOMIC should be clarified a lot more.

The rationale behind the idea of automatic conversion is
given in section 2.4. However, the following quote
potentially widens applicability of ATOMIC. It reads;

 > the primary address(IMA) can be safely transformed or
 > converted to the respect ASCII email address via ACE

If we stick to this explanation, we can set ATOMIC to "y"
even if it is NOT atomic. If there is any way to handle
ACE encoded email addresses regardless of their atomicity,
we can safely encode them.

We have two choices. First, we just stick to the concept
atomic. So, even though the final delivery can handle ACE
encoded addresses with embedded commands, non atomic addresses
should NOT declared as ATOMIC.

Second, we extend the coverage that is supported by ATOMIC
option. If encoded addresses can be handled by the final
delivery correctly, they should be declared as ATOMIC.
(In this case, ATOMIC needs to be replaed with better term
such as SAFE-TO-DOWNGRADE.)

(3) Editorial suggestion

(3-1) The last sentence of section 2.2;

 > If it is replaced, the replacement
 > MUST be either the ASCII-only address specified with the ALT-ADDRESS
 > parameter or with an address obtained from some algorithmic
 > conversions of the primary address that conforms to the syntax rules
 > of RFC 2821, which is defined in [IMA-downgrading].

"which" in the last line is very confusing. I want that part as a
separate sentence.

(3-2) Section 2.4

You include too much stuffs that should be covered by downgrade
document. I want to leave only rationale part and a very brief
usage.

Regards

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: John C Klensin <[email-masked]>
Date: Sun, 04 Jun 2006 18:10:58 -0400

Hi.

For whatever it is worth...

(i) I agree with Yangwoo's analysis on (1) and (2).

(ii) I continue to believe that we need to get these issues 
worked out and properly and clearly reflected in the downgrade 
document, then remove all of the specifics from SMTPEXT.  In 
essence, SMTPEXT should contain a minimal explanation about what 
these parameters are about, identify their syntax, indicate 
that, if a legacy server is encountered, one must downgrade or 
bounce, and then defer the explanation of how to downgrade 
--including what these parameters are about-- to the downgrade 
document.  So I am in strong agreement with YangWoo's last point 
as well.

     john

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 04 Jun 2006 15:33:03 -0700

John C Klensin wrote:

> (ii) I continue to believe that we need to get these issues worked out 
> and properly and clearly reflected in the downgrade document, then 
> remove all of the specifics from SMTPEXT.  In essence, SMTPEXT should 
> contain a minimal explanation about what these parameters are about, 
> identify their syntax, indicate that, if a legacy server is 
> encountered, one must downgrade or bounce, and then defer the 
> explanation of how to downgrade --including what these parameters are 
> about-- to the downgrade document.  So I am in strong agreement with 
> YangWoo's last point as well. 

I also agree with Yangwoo's and Klensin's analysis.

I hope the interim meeting (which starts in 1.5 hours) can help clarify 
the dividing line between these two documents.

                   Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 05 Jun 2006 10:20:59 +0100

> such as SAFE-TO-DOWNGRADE.)

I think the word you are looking for is "DOWNGRADABLE".
> "which" in the last line is very confusing. I want that part as a

How about:

If it is replaced, the replacement MUST be either the ASCII-only address  
specified with the ALT-ADDRESS parameter or with an address obtained from  
some algorithmic conversions, (as defined in [IMA-downgrading]) of the  
primary address (that conforms to the syntax rules of RFC 2821).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5