Subject: [EAI] 5336bis

From: Shawn Steele <[email-masked]>
Date: Fri, 3 Dec 2010 21:04:48 +0000

I was asked to look at 5336bis a bit more:

UTF8SMTPbis needs fixed everywhere (obviously).  IMO it should stay UTF8SMTP.

3.3 Extended mailbox address syntax says: “to permit either the definition above or…” in two places.  It would be easier for me if it said “to permit either the [RFC5321] definition above, or…”

ABNF & I don’t get along well, but nothing jumps out to me in that section.

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.

- Shawn

 
http://blogs.msdn.com/shawnste
(Selfhost 7891)

---

From: Shawn Steele <[email-masked]>
Date: Fri, 3 Dec 2010 21:34:43 +0000

Specifically, I’m happy if the RFC were published as it is, except obviously the UTF8SMTPbis MUST be fixed.

I assume I’m just missing something obvious about my last question.

-Shawn

From: Shawn Steele
Sent: Friday, December 03, 2010 1:05 PM
To: [email-masked]; Alexey Melnikov ([email-masked])
Subject: 5336bis

- Shawn

 

---

From: John C Klensin <[email-masked]>
Date: Fri, 24 Dec 2010 23:21:07 -0500

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
<[email-masked]> 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

---

From: Shawn Steele <[email-masked]>
Date: Sat, 25 Dec 2010 04:39:01 +0000

Thanks, I hadn't seen a reply yet.  I understand, but this is the kind of "leaking" that makes IDN horrible to interoperate with.  Sure, the tools may not be Unicode aware, but they also may not be Punycode aware, meaning that someone has to figure out how to translate it.

IMO the headers are EAI, so these should only happen on an EAI aware system, in which case the tools should be updated :)  Eg: something could be broken no matter what, so I'd prefer it was broken in a forward-looking way, then at least when the tools got fixed they wouldn't always have to have the punycode hack.

And this doesn't help much for other data in the header, or local parts.

-Shawn

 

________________________________________
From: John C Klensin [[email-masked]]
Sent: Friday, December 24, 2010 8:21 PM
To: Shawn Steele; [email-masked]; Alexey Melnikov
Subject: Re: [EAI] 5336bis

Shawn,

best,
     john

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Dec 2010 00:53:09 -0500

--On Saturday, December 25, 2010 04:39 +0000 Shawn Steele
<[email-masked]> wrote:

> Thanks, I hadn't seen a reply yet.  I understand, but this is
> the kind of "leaking" that makes IDN horrible to interoperate
> with.  Sure, the tools may not be Unicode aware, but they also
> may not be Punycode aware, meaning that someone has to figure
> out how to translate it.
> 
> IMO the headers are EAI, so these should only happen on an EAI
> aware system, in which case the tools should be updated :)
> Eg: something could be broken no matter what, so I'd prefer it
> was broken in a forward-looking way, then at least when the
> tools got fixed they wouldn't always have to have the punycode
> hack.
> 

Yes.  Added to my notes, we now have a pretty good summary of
the tradeoffs.  In fairness, I should also note that we made
that decision at a time when in-transit downgrade was still in
the system and avoiding having to downgrade Received headers was
another important consideration.

While I still think the decision we made was the right one, this
is one of many decisions that makes me wish we could declare and
enforce a flag day and just stop trying to game out the
implications of different transition strategies.  While I'm
wishing for the impossible, I'd suggest that Jan 1 2011 would be
a good candidate :-(

     john