Subject: [EAI] Comments on Internationalized Email Headers

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 7 Apr 2006 16:59:00 +0200

All,

these are my comments on draft-yeh-ima-utf8headers-01. I haven't been 
following the last discussions in the list. If some of these issues (or 
any of those in my following mails) have already been dealt with, then 
just give me a pointer.

* Abstract: "and to use international characters in envelope addresses". 
That's a bit unlucky formulation. What about "to use non-ASCII 
characters"?
* Abstract: "the base form for Internet email header fields". For the sake 
of correctness I would find better "the base form for Internet email 
header field bodies". This correction should be made a couple of other 
times in the document.
* Section 1.1: The UTF-8 issue is addressed here for the first time. 
Colour me purist, but I think that the actual encoding of the header field 
bodies should be a transport issue, and that this header document should 
only talk about "non-ASCII" or "Unicode characters" instead of "UTF-8 
characters" (besides the fact, that ASCII are UTF-8 characters, too).
* Section 2: "This protocol specifies UTF-8 as the encoding to represent 
email header messages". What is meant with "email header message"? Maybe 
"email header body"?
* Section 2: The concept "IMA mailbox names" appears for the first time 
and is not introduced.
* Section 2: "if other header fields (particularly trace header fields 
such as "Received:") contain non-ASCII character". It would be helpful to 
make a complete list (well, probably not here in the introduction) of 
which fields are those. I couldn't find it. But "Received" is defined in 
ima-smtp-ext-02 section 2.5.2 to preferably remain ASCII, so this is 
probably not a good example to mention.
* Section 4: "Sending MUAs that follow this protocol MUST create.." is not 
2119-coherent with the next sentence "MUAs MAY continue to use MIME..".
* Section 5: s/identifiction/identification/
* Section 5: "Checking the presence of UTF-8 characters in the header". 
Such a thing is not possible: you will find two bytes with the highest bit 
set and won't be able to determine whether you are dealing with two 
Latin-1 chars or one UTF-8 char.
* Section 5: s/the its/the/
* Section 5: "sending MUA should insert a new header". My opinion is that 
"sending MUA MUST insert a new header", otherwise there is no 100% 
reliability.
* Section 5: "i18n-mail" is a bit strange nomenclature. "i18n" stands for 
"internationalization" and not for "internationalized" (which should be 
i15d). Besides, "i18n mail" just doesn't flow out of the tongue. Couldn't 
we think of something else?
* Section 5: "There should be more useful information [that] can be 
place[d] in the new header field". Something concrete in mind?
* Section 5, 1st bullet: "'i18n-mail' header field MUST be inserted by the 
originating MUA". Fine, but cf "should" three bullets in this mail ago.
* Section 5: "..MUST be inserted by the final delivery MTA if not 
presented". I don't know if this is for robustness or what, but it should 
be unnecessary, provided that the sending MUA did. And which are the 
criteria for inserting it, if not present? Statistical mechanisms to 
determine the presence UTF-8 encoding?
* Section 6: "the rules in RFC 2822 for header names are not changed". 
Just delete the sentence. It was stated one sentence ago.
* Section 6: s/extensionextension/extension/
* Section 6: s/IEE smtp extension/IMA SMTP extension/
* Section 6: Where does the magic number 558 come from? I mean "55" stands 
for "permanent negative in the mail system", but the remaining 8?
* Section 6: "any data or instructions embedded in the email address". 
This should be ellaborated a bit more, maybe with one example (we are 
talking about "+" encodings, aren't we?)
* Section 6, ATOMIC bullet: "<mailbox> remains the same to RFC2822. The 
only difference..". It either remains the same or there is some 
difference.
* Section 6, ATOMIC bullet: "The only difference is that the <local-part> 
and <domain> of <addr-spec> allows UTF-8 characters". This is not enough 
for a formal syntax definition. It must be clearly enumerated which 
characters are allowed and how many of them. The encoding (UTF-8) is not 
relevant for the syntax, though it could effect the max. number of 
characters fitting there.
* Section 6, ALT-ADDRESS bullet: What is the need for supporting the "obs" 
formats?
* Section 6, ALT-ADDRESS bullet: "new-addr-spec =/ addr-spec" Isn't that 
line in the BNF unnecessary?
* Section 7.1: "MAY need to be updated". RFC 2119 language is not 
necessary here, and by now, we know the are being updated.
* Section 8: "that user SHOULD have both addresses in the identity". That 
"SHOULD" shouldn't be normative, and I even think it should be "may".
* Section 8: "Lines that are longer than 78 octects could possibly cause 
mail user agents to fail". I would recommend then to proceed with folding, 
if encodings are longer than 78 octects. Talking about folding: What do 
you think about updating the definition of folding points in RFC 2822? 
Something like allowing for folding at codepoints with the Zs-property, 
instead of only whitespaces.

Best regards,
Marcos

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

---

From: "Jeff Yeh" <[email-masked]>
Date: Fri, 28 Apr 2006 17:42:41 +0800

Sorry that I failed to catch up with the mailing list.
Feel free to correct me if I miss anything.
My response embedded.
Thank you for your comment and attention.

Jeff Yeh

> -----Original Message-----
> From: Marcos Sanz/Denic [mailto:[email-masked]] 
> Sent: Friday, April 07, 2006 10:59 PM
> To: [email-masked]
> Subject: [EAI] Comments on Internationalized Email Headers
> 
> All,
> 
OK. Will update in next version.

> header field bodies". This correction should be made a couple 
Will update in next version.

> characters" (besides the fact, that ASCII are UTF-8 characters, too).
Yes, but we're trying to limit the unicode usage in only UTF-8 format.
And also avoid the necessary of having a characterset tag.

> email header messages". What is meant with "email header 
Will update in next version.

> * Section 2: The concept "IMA mailbox names" appears for the 
Will change to "internationalized email addresses".

> probably not a good example to mention.
I'll add the list about trace fields in the next version.
IMO, the final MTA acts no different.  If one support IMA, the trace field
can be handled in non-ASCII.
If one couldn't, he will get the message in downgraded form (or not to
receive).
What they do is put the original form into trace field.

> 2119-coherent with the next sentence "MUAs MAY continue to 
Ok. I'll remove the "MUAs MAY continue to use MIME part"
It preferred not to use MIME in this spec, though we couldn't force people
to do that.

> * Section 5: s/identifiction/identification/
Thanks.

> Latin-1 chars or one UTF-8 char.
Actually it does.
You can find Chris' thread on
http://www1.ietf.org/mail-archive/web/ima/current/msg00188.html

> * Section 5: s/the its/the/
Thanks.

> "sending MUA MUST insert a new header", otherwise there is no 100% 
Agree to change should to MUST, will update in next version.
However, it still can not 100% sure the header goes to the final MTA. 
Because some MTA do filter/block those header they don't know. (I can't
recall, but I'm sure this was being discussed)

> we think of something else?
Maybe use "I-Email" will be better. Since there's no other concern about the
new header name.

> place[d] in the new header field". Something concrete in mind?
Since we're going to invent new header, it good to make more use of this
slot.
I have no idea yet, but maybe downgrading information could take advantage
of this new header.
This was being discuss on the list about invent new header or not.
To invent a new header like "i18n-mail: 1.0" seems to fall into the
experience of "MIME-Version: 1.0".
As a spec level, I prefer to have a header to identify i18n-email to
traditional email.
Where implementers check it or not, is nothing we can control at all.

> originating MUA". Fine, but cf "should" three bullets in this 
Thanks.

> determine the presence UTF-8 encoding?
Response in the previous questions.

> * Section 6: s/IEE smtp extension/IMA SMTP extension/
Thanks, will update in next version.

> for "permanent negative in the mail system", but the remaining 8?
Sorry, will change to 550.

> talking about "+" encodings, aren't we?)
Good idea, will put some in next version.

> only difference..". It either remains the same or there is some 
I'll change the text more clear, thanks.

> characters fitting there.
Detail ABNF will be prepared.

> * Section 6, ALT-ADDRESS bullet: What is the need for 
Since ALT-ADDRESS is a ASCII address, defined the same in RFC 2822.
I don't see what need to support.
Or I reading your question wrong? 

> necessary here, and by now, we know the are being updated.
Yes, will remove.

> "SHOULD" shouldn't be normative, and I even think it should be "may".
Agree to put in MAY.

> instead of only whitespaces.
I think white space folding is just enough.  What is "Zs-property" by the
way?