Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Randall Gellens wrote:
(1) This version still has some editor's notes. Are these intended for publication?
No. The writeup didn't get copied into the Last Call, but as WG chair, I believe that the document is complete if all the editor's notes are deleted. Some of them point to areas that might be improved, but, in my opinion, such improvements are not a requirement for publication.


(2) In section 1.3:
   An "i18mail user" has one or more non-ASCII email addresses.  Such a
   user may have ASCII addresses too; if the user has more than one
   email account and corresponding address, or more than one alias for
   the same address, he or she has some method to choose which address
   to use on outgoing email.  Note that under this definition, it is not
   possible to tell from the address that an email sender or recipient
   is an i18mail user.  There is no such thing as an "i18mail message";
   the term applies only to users and their agents and capabilities.

Does the second-to-last sentence refer to an ASCII address, or any address? The wording implies any address, but if an address is non-ASCII, surely that is a good sign that the owner of that address is an i18mail user?
Right. The situation that is being warned against is taking an ASCII address as a clear sign that the address owner is not an i18mail user.


(3) In section 4.3:
    the risk should be
   minimized by the fact that the selection of submission servers are
   presumably under the control of the sender's client and the selection
   of potential intermediate relays is under the control of the
   administration of the final delivery server.

   [snip]

   For situations in which a client encounters a server that does not
   support UTF8SMTP, there are basically two possibilities:

   o  Reject the message or generate and send a non-delivery message,

   [snip]

   o  Figure out a way to downgrade the envelope or message body in

I apologize if this has already been discussed, but in light of the first quoted sentence, the two possible actions can be augmented by another approach: try an alternate MX host and/or requeue the message and try later. That is, because the mail path is normally under administrative control of the end points or their organizations, it may be reasonable to conclude that UTF8SMTP is normally supported along this path, and if a system is encountered which doesn't support it, this may be a temporary failure. Obviously, if this is tried but persistently fails, one of the other two methods must be used.

(This could also be mentioned in the smtpext document.)

I haven't seen that possibility raised. I'm somewhat skeptical that it would be an improvement (it makes the delay before error reporting variable), but it's worth a discussion. WG?


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]