Re: [EAI] 5336bis

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

Shawn,

It isn't clear to me that anyone ever responded to this comment.
If they have, I apologize for the duplication.  If not...

--On Friday, December 03, 2010 21:04 +0000 Shawn Steele
<[e-mail]> wrote:

>...
> In 3.6.3 I don't get why received fields have to use
> A-labels at all?  I assume I missed a discussion?  It would
> seem to me that the end-points are all EAI aware, so it's
> unclear to me why A-labels are necessary anywhere.
>...

Claudio pointed out in his review of 5336bis that there there
are whole array of databases and tools surrounding the email
environment.  His particular concerns were to warn about logs
and the like, but the issue is more general: neither tools nor
people should ever actually need to look at a Trace ("Received")
field unless something has gone wrong or is suspected of having
gone wrong.  Those tools (or people) may not be EAI-aware, may
not have fonts appropriate to display of arbitrary Unicode
strings, may not be able to read such strings (even to iterate
the characters) even if they can display them, etc.    There is
very little advantage in internationalizing those fields and, if
we were to require it, the net effect would either be less
stable operation or delays in deploying EAI as more
infrastructure and training are required to be put in place.

The A-label requirement does require that a MTA that uses a
universal "name resolution" API (the problem discussed in
draft-iab-idn-encoding) perform a U-label to A-label conversion,
but the main issue in draft-iab-idn-encoding really doesn't
apply here: think of the requirement as applying to 

   Received: from ... with smtp ...

or with any of the other "with" keywords specified in 5336bis or
the IANA registry.  "with smtp" is pretty much defined in 5321
as running over TCP.  If one had

   Received: from ... with Proprietary-Email-Transport-XYZ ...

then one would be far enough outside of the combination of 5321
and 5336bis that, if a name (domain or otherwise) is expressed
in UTF-8 (or UTF-16 for that matter), the implementation would
not be significantly more outside the specs.

best,
     john