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]

 



(1) This version still has some editor's notes. Are these intended 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?


(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.)

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Truth resides in every human heart, and one has to search for it
there, and to be guided by truth as one sees it.  But no one has
a right to coerce others to act according to his own view of the
truth.                                                  --Gandhi

_______________________________________________

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]