Re: Problems of Internationalized Mail Address eXtensions (IMAX)

Paul Hoffman / IMC <[email protected]> writes:

> At 12:38 PM +0100 2/26/03, Simon Josefsson wrote:
>>My question was sincere.  IMAX appears to be a solution for
>>internationalization of MTAs, at the SMTP layer.  It does not propose
>>solving the internationalization problem for MUAs.
>
> Yes, it does. It shows exactly how an MUA should display ACE names.

Are you referring to the M-* headers?  Those were (rightly) dropped
from IMAX, I believe.  IMAX doesn't mention the term "MUA" at all.
The section regarding M-* headers definitely does not show "exactly"
how an MUA display the ACE names.

>>   Those two
>>distinctions could be investigated in parallel and evaluated on their
>>own merits.
>
> Yes, but we need Internet Drafts before we can do that.

There are two Internet Drafts, with different approaches.  We don't
need more to investigate these two.

>>   If you think this is ludicrous and want this to be a
>>productive discussion, please take the question seriously and explain
>>in technical terms why your proposal is better.
>
> How many times should this be done?

The IMAX draft is only a few weeks old, if you have discussed it many
times before please provide a reference.

> IMAA is certainly going to be simpler than any proposal that
> requires changes to both MTAs and MUAs because it localizes the
> changes to one place (the MUA).

Earlier you said my question whether IMAA was an internationalization
solution for MTAs was ludicrous yet you now say IMAA doesn't require
any changes to the MTA.  Clearly, if you want to internationalization
support in the MTA, you will have to modify it.  Let's take a step
back:

Compare the situation for the MTA with IMAX: if you want
internationalization support in the MTA, can you can implement IMAX,
if you don't want or care about it, don't implement.  Neither choice
will disrupt existing Internet mail services.

Having asserted that a MTA without support for IMAA or IMAX will not
disrupt existing services, for the remaining discussion we can assume
that the MTA do want to be an internationalized product.  I'll call it
an I18NMTA to help keep things apart.  What I'm trying to understand
now whether IMAA or IMAX is the better choice for the I18NMTA.  Some
propositions:

* IMAA requires the I18NMTA to implement punycode.  IMAX doesn't
  (assuming my suggested clarification about treating RHS as a IDNA
  aware domain name slot is adopted).

* You claim that under the IMAA design it is reasonable to implement
  separate applications for viewing log files and editing
  configuration files in the I18NMTA.  IMAX doesn't require this as it
  uses the system's native character set.

* IMAA requires the I18NMTA to support Unicode.  While Unicode is a
  good thing, it can be difficult to implement in existing systems.
  It is potentially disruptive to the Internet Mail system, using your
  terminology.  My idea of using a IMAX solution without fallback do
  not require this.  No, I haven't described this idea in an Internet
  Draft, so you don't have to challenge the proposition, but I'd
  appreciate if you did.

You are welcome to add propositions that are to IMAA's advantage.

> It allows other entities in the Internet Mail system to easily use
> the internationalized email addresses without having to know
> anything about multiple charsets and repertoires.

That isn't true.  Not all systems are using Unicode, but IMAA requires
that they implement Unicode.  Clearly that is forcing them to know
about multiple charsets.

>>(If you are thinking
>>  > of a protocol that doesn't require punycode but would instead simply
>>>  bounce or lose mail that was sent to MTAs that didn't understand the
>>>  new protocol, please don't bother writing an Internet draft...)
>>
>>Why not?
>
> Because no one who cares about Internet mail wants to start bouncing
> mail messages unpredictably.

Of course not, that is obvious.  How did you infer the bouncing would
be unpredictable?

> Seriously, if you want to do that, don't do it here. Start your own
> mailing list. I'm quite willing to have folks who propose different
> solutions that are as reliable as IMAA-ACE discuss them here, because
> then we can pick just one. But people proposing to make Internet mail
> unreliable aren't welcome.

If you believe IMAX would make Internet mail unreliable, please
explain why.

>>I can only interprete your dismissal of alternative solutions without
>>a serious analysis that you either have done this analysis already and
>>know the answers or that you don't want to see alternative ideas
>>discussed.
>
> The former.
>
>>   In the former case, I think it would be useful to read
>>your analysis.
>
> No analysis needed. A "new and improved" mail system that is less
> reliable is a non-starter.

"New and improved" is a loose term.  IMAA could be considered a "new
and improved" mail system.  I believe analysis is needed if you want
to make good decisions.

>>>>> You are free to say that. Others would disagree. In the case of IMAX,
>>>>> what would you want in your log file. All UTF-8? That means you need
>>>>> converters from every accepted charset to UTF-8. Careful sysadmins
>>>>> would probably want to know *exactly* what came in, not some converted
>>>>> form, but that means that their log file would have multiple charsets
>>>>> in it, which would make display a mess. A reasonable option is to
>>>>> store the addresses as ACE and to have a log-file viewer that converts
>>>>> on display (and has an option for not converting).
>>>>>
>>>>> Again, this is an implementation issue, not a protocol issue.
>>>>
>>>> Yes.  But it is an important point.  A internationalization solution
>>>> that doesn't consider these practical issues is of only theoretical
>>>> value.
>>>>
>>>> I would want the log file to contain characters that can be read
>>>> without special IDNA/IMAA/IMAX aware programs.  I.e., if the system
>>>> uses UTF-8 as the system encoding, I'd want the log file to be in
>>>> UTF-8.  If the system uses ISO-8859-1, the log file should be in
>>>> ISO-8859-1 (and the application must cope with data that can't be
>>>> represented somehow).
>>>>
>>>  Fine. Ask your vendor to include that feature. This is not part of a
>>>  protocol specification.
>>
>>I'm the vendor, and I'm here to understand how to implement it.  If
>>the protocol specification doesn't give guidance or have considered
>>how it will be implemented, I fear it will not work.
>
> Then you're not a useful vendor. Others will be able to easily figure
> out where they want to write raw ACE blobs and where they want to
> convert them into Unicode characters (and, hopefully, which encoding
> to use for the Unicode characters).

And convert them into the system's native character set too, I'm sure.

>>>>> I think I hear you saying that you think that the protocols should
>>>>> allow any repertoire and any encoding of those repertoires. If so, we
>>>>> certainly disagree. The IETF is not very keen on creating protocols
>>>>> for which there would be limited and unpredictable
>>>>> interoperability. Other standards group might not be so picky.
>>>>
>>>> That is stretching it a bit, I think.  I believe that a solution worth
>>>> its salt should consider existing habits, and whether we like it or
>>>> not there is more than charset used on the Internet.  MIME appears to
>>>> acknowledge this and is rather successful.  HTML acknowledge this and
>>>> is rather successful.  Same for HTTP.  Come to think of it, I can't
>>>> recall any successful internationalization product the IETF has
>>>> produced to counter my examples, can you help me?
>>>>
>>>> If you are speaking for IETF, I find it interesting that RFC 2277
>>>> "IETF Policy on Character Sets and Languages" says that protocols MAY
>>>> allow use of any repertoire.  It doesn't say that it is a bad idea to
>>>> allow more than one charset.  I agree with that document, let's
>>>> require the use of UTF-8 in protocols, but allow negotiation of other
>>>> charsets to smooth transition and deployment.
>>>
>>>  You should take this up with Harald Alvestrand, the author of RFC
>>>  2277. Note that IDN chose not to use UTF-8, and Harald (as chair of
>>>  the IESG) approved it to be on standards track.
>>
>>Perhaps he is busy with other things,
>
> He posted 152 messages to the IDN WG mailing list, some of which were
> on this very topic. It seems likely that he was paying attention...
>
>>  but I will ask if the policy in
>>RFC 2277 doesn't apply any more, or where the variance procedure steps
>>for the IDN working group are documented.  Thanks for the suggestion.
>
> Let us know what you find out.

I found out that RFC 2277 hasn't been obsoleted.  So that means you
were wrong saying (see first paragraph of quoted text), that the IETF
is not keen on creating protocols that allow any repertoire and any
repertoire.  The quoted text from RFC 2277 I provided earlier says
that they MAY do this.

For reference, Harald Tveit Alvestrand <[email protected]> writes:

> simon,
> the "escape clause", if you want one, is that DNS names are not, in
> many senses of the word, text; they're names.
> And RFC 2277 says, in extenso:
>
> 2.  Where to do internationalization
>
>    Internationalization is for humans. This means that protocols are not
>    subject to internationalization; text strings are. Where protocol
>    elements look like text tokens, such as in many IETF application
>    layer protocols, protocols MUST specify which parts are protocol and
>    which are text. [WR 2.2.1.1]
>
>    Names are a problem, because people feel strongly about them, many of
>    them are mostly for local usage, and all of them tend to leak out of
>    the local context at times. RFC 1958 [RFC 1958] recommends US-ASCII
>    for all globally visible names.
>
>    This document does not mandate a policy on name internationalization,
>    but requires that all protocols describe whether names are
>    internationalized or US-ASCII.
>
> So IDN is really carrying internationalization outside the scope of
> RFC 2277.
>
> The more basic reason is that the IETF is about doing what's right,
> not what the rules say you have to do - in this particular case, using
> UTF-8
> was debated up the wazoo and far beyond, and the group concluded that
> using Punycode rather than raw UTF-8 encoding was the Right Decision,
> and the IESG backed them on that.
>
> Using up processing time to write a BCP to cover this variance from
> RFC 2277 would not be useful - especially since RFC 2277 can be read
> to say that they didn't have to do this anyway.
>
> Feel free to forward this message wherever you feel like...
>
>                    Harald
>
> --On 26. februar 2003 12:51 +0100 Simon Josefsson <[email protected]> wrote:
>
>> Harald,
>>
>> I'm sure you are busy, but I'd appreciate if you could take time to
>> answer this question.  It was suggested on the IMAA list by Paul
>> Hoffman to ask you how to reconcile RFC 2277 with the approval of IDN.
>> In particular, RFC 2277 says:
>>