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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf