Re: WHY we need do "Divide the sequence into segments"

John C Klensin <[email protected]> Fri, 04 Jun 2004 09:01:23 -0400
Newsgroups gmane.ietf.imaa
Message-ID <[email protected]>
--On Friday, 04 June, 2004 17:15 +0800 dongxiaoli
<[email protected]> wrote:

> Hello everyone.
> 
>        Have anybody can tell me WHY we need do "*Divide the
> sequence into segments*" in the ToASCII process  as described
> in the
> IMAA draft (draft-hofmann-imaa-03.txt)??

In many circumstances, there is a good deal of information that
is already encoded into email local-parts.  The most common of
these, these days, are subaddresses and internal routing codes,
but external routing and address component identification, such
as those used for X.400 addresses and fax-like attribute
identification when those are mapped to the Internet, have been
common (and probably still are) in some communities.

In many of those cases, the presence of the encoding and its
components must be recognized by the delivery MTA or, at the
boundary of an outright violation of the standards (however
necessary) by organizational-boundary relays such as
SMTP-handling firewalls.  If the clues that the codings are
present are hidden by the i18n encoding, we gain
internationalization at the cost of the features supported by
that information-encoding.  

We have no standard for any of those information encodings --
they have, so far, been protected by an extremely strong rule
that no MTA before the final delivery one is permitted to
interpret the contents of a local-part in any way.   All
previous systems and MTAs, including the originating user and
MUA, are required to treat the entire local-part address an an
atomic and opaque string.

The segments and delimiters of draft-hoffman-imaa-03 are
intended to alleviate the problem with hiding these encodings
while providing internationalization for the various address
components.

This issue was the original philosophical departure point
between draft-hoffman-imaa and draft-klensin-emailaddr-i18n.
The latter takes a somewhat stronger and more protective view of
the local-part addresses, noting particularly that the approach
in draft-hoffman-imaa will not protect either information in
local-parts that is length-encoded (e.g., "the address contains
a 'project distribution' component beyond the mailbox name for
the recipient; the last three characters are the project
identifier, the other characters are the mailbox name") or
information that is separated by non-ASCII delimiters.  For
example, were you to want to use subaddresses with a mailbox
whose name was in Chinese, the rules of draft-hoffman-imaa would
require that you separate the mailbox and subaddress elements
with an ASCII delimiter, not one that might appear more
appropriate for Chinese, if the classification and action were
to be done by an MTA that did not, itself, run ToUnicode.
There is some additional discussion on this issue in
draft-klensin-emailaddr-i18n-02.txt. 

>         And  another question: "The "*protected code points"
> are 0..40, 5B..60, 7B..7F (in other words, those corresponding
> to ASCII characters other than letters and digits). *" is from
> draft-hofmann-imaa-03.txt.  But the code points of digits
> range between 0...40,so why said the *digits is not  protected
> code points*?

Paul or Adam will need to answer this one.

best,
    john