Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01

[John C Klensin <[e-mail]>]

--On Monday, July 12, 2010 16:57 +0000 Shawn Steele
<[e-mail]> wrote:

> Sorry, I cut too much context.  I was replying to Ernie's
> reply where he said:
> 
> 	3.2. The UTF8SMTPbis Extension
> 	(last paragraph)  
> 
> 	   If a server advertises UTF8SMTP and the client does not
> recognize the 	   extension, the client may send a regular
> message [RFC2821 <http://tools.ietf.org/html/rfc2821>] and
> [RFC2822 <http://tools.ietf.org/html/rfc2822>].  In this case,
> the client may continue to use the 	   [RFC3490
> <http://tools.ietf.org/html/rfc3490>] or [RFC5890
> <http://tools.ietf.org/html/rfc5890>] ToAscii() to encode the
> domain portion of an 	   address.

Aha.  I rewrote that very severely before putting it into -02,
so couldn't find what you were quoting.

> 	The second sentence is not very clear. Is the following what
> is meant
> 
> 	>>    In this case, the client will not be able to transmit
> any 	>>    messages which contain non-ASCII characters in the
> 	>>    local-part of any email addresses. If the non-ASCII 	>>
> characters are confined only to the domain portion of the 	>>
> address, such a client will be able to transmit messages 	>>
> if it uses [RFC3490] or [RFC5890] ToAscii() to encode the 	>>
> domain portions of these addresses.
> 
> So I suggested:
> 
>>    In this case, the client will not be able to transmit any
>> messages    which contain non-ASCII characters in the
>> local-part of any email    addresses. If the client has an
>> ASCII only address available, such    as an alias, or by
>> applying [RFC3490bis] ToAscii to the domain    portion of the
>> address, then it may be able to send the mail in    ASCII as
>> per [RFC2821].
> 
> Where you replied:
> 
> 	That statement would be true, but a lot less helpful than I
> think you want, if the last part of it read something like
> "...then it may be able to send a similar, transformed,
> message in ASCII as..."
> 
> The original idea seems to be that "If UTF8SMTP isn't
> supported, you might be able to try the old way by doing
> XXXXX".  Since we expect at least some users to have ASCII
> addresses, then XXXXX has more options than what Ernie's
> suggestion allowed.  That's all I was trying to say.  Even
> using Punycode as in the original idea would be a
> "transformed" message.

I don't know what Ernie intended, but I took it as closer to
"you either support the extensions or you are on your own with
the traditional/legacy system".

> I'm not sure we need this text, since, of course, if the
> server doesn't support UTF8SMTP, the existing standards still
> work :)  It seems like there's no harm in pointing that out,
> but I don't want to be overly restrictive in our wording.

Right.   Joseph's interpretation is, I think, close to mine.
Have a look at the -02 text and see if you like it any better.
I do have one observation about his comments -- see below.


> Re: transcriptions, I think I was confusing.  We're
> expecting admins/users to create a Unicode address for their
> mailbox, and, likely, an ASCII address, which, in some cases,
> is probably a transcription chosen by the admin or user.
> (Eg: Tarek, my manager, instead of however that's spelled in
> Arabic).

I think that, as you move around the world and look at names
written in Roman characters for people whose native language
isn't normally written that way, you will find transcriptions,
transcriptions, translations, and more or less fanciful
alternatives in some proportions.  Note that, strictly speaking,
Chinese cannot be transliterated, only transcribed (Japanese
Kana     can be transliterated into Romanji).  If you take the
three active participants in the WG who are of Chinese descent
as examples, we see (I hope they will correct me if I have this
wrong):

 o Joseph (probably not a transcription*; I don't know
	whether it is a translation of something else or not)
 o Jiankang (I presume a transcription*; but he has
	also sometimes used "Health", which I understand to be a
	translation)
 o XiaoDong (a transcription*; but he sometimes also
	has used "Sheldon", which sounds somewhat alike but it
	neither a translation or transcription)

	* Note that while Hanyu Pinyin is now the standard
	transcription system in the PRC and some other places,
	there are a huge number of mutually-incompatible
	transcription systems for Chinese.  And, of course,
	transcription systems, by definition, reflect spoken
	languages, not written ones.

Similar issues apply with other languages and names.  Knowing
the personal name doesn't tell you what convention is being used
for a name in a different language/cultural environment.   As an
example that you and I should find mutually amusing, Иван
usually makes it into Roman characters as "Ivan", but Johann,
John, and even Sean or Shawn, (but not Jon or Jonathan) are not
unreasonable: all derive down different paths from יוחנן.


--On Monday, July 12, 2010 14:00 -0400 Joseph Yee
<[e-mail]> wrote:

> The discussion on encoding domain part with RFC3490 or RFC5890
> is focus on what may/can do immediately with
> ascii-only@utf8-domain address (following the discussion that
> narrow down the scenario).  Your concern of too restrictive
> choices was addressed on section 7.1 in Framework-02 of what
> MUA and user can do.  The text there mentions wide range of
> approaches.  

In going through what became -02 over the weekend, I discovered
several clusters of text that are somewhat redundant with each
other or that might be organized to be more easily found or
understood.  While I fixed those that I found and for which the
fixes seemed straightforward, there are almost certainly others
left.  Suggestions about what material can safely be eliminated
as covered elsewhere in document, what might better be
reorganized and how, and where cross-references are needed would
be most welcome.

    john