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