Network Working Group J. Klensin Internet-Draft November 1, 2005 Expires: May 5, 2006 Considerations in Downgrading Internationalized Email draft-klensin-ima-downgradeissues-0X.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 5, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract If electronic mail is to extended to permit internationalized addresses and headers, the question immediately arises about how such messages should be handled if a server is encountered that does not support the extensions. There have been a number of proposals for how to "downgrade" the messages to conventional ASCII-only form and perhaps to "upgrade" them again. This document discusses some of the issues with those proposals and mechanisms. NOTE: While formatted and organized as an Internet-Draft, this Klensin Expires May 5, 2006 [Page 1] Internet-Draft IMA Downgrade Considerations November 2005 document was prepared only for informal use as part of the "IEE" BoF discussion at IETF 64. If it appears useful to do so, a subsequent version may be prepared for posting as an Internet-Draft. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology Note . . . . . . . . . . . . . . . . . . . . . . . 3 3. Difficulties with the Yoneya and Fujiwara Approach . . . . . . 4 3.1. Uses and Decomposition of Local-Parts . . . . . . . . . . 4 3.2. From Whence an ACE . . . . . . . . . . . . . . . . . . . . 5 3.3. Header Retention and Loss . . . . . . . . . . . . . . . . 5 3.4. Encoding Information in Headers . . . . . . . . . . . . . 5 4. Putting Downgrading in Perspective . . . . . . . . . . . . . . 6 4.1. Where is Downgrading Needed? . . . . . . . . . . . . . . . 6 4.2. Transitional Pain or Long-term Kludges . . . . . . . . . . 7 4.3. Learning from 8BITMIME . . . . . . . . . . . . . . . . . . 7 5. Some Alternate Mechanisms . . . . . . . . . . . . . . . . . . 8 5.1. Identification of an Alternate Address . . . . . . . . . . 8 5.2. Asserting that the Address is Atomic . . . . . . . . . . . 8 5.3. An Alternate Address Directory . . . . . . . . . . . . . . 9 5.4. Encoding and Encapsulating . . . . . . . . . . . . . . . . 9 5.5. Just Reject the Message . . . . . . . . . . . . . . . . . 10 6. Internationalization Considerations . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 10. Some Conclusions . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Klensin Expires May 5, 2006 [Page 2] Internet-Draft IMA Downgrade Considerations November 2005 1. Introduction A recent draft for downgrading of internationalized email addresses by Yoneya and Fujiwara [Yoneya-downgrade] proposes a mechanism for downgrading internationalized messages in transit to conventional ASCII-only formats as described in [RFC2821] and its predecessors. The proposal was developed to work in the context of the email internationalization framework described in [IMA-Framework] and associated documents. Downgrade mechanisms and supporting features proposed in the context of other approaches may be less relevant and will be discussed here only if needed to clarify alternatives. However, the discussions of downgrading in earlier drafts (most of them now expired) may be helpful in providing additional perspective on the issues identified below. Those drafts include the "ALT- ADDRESS" originally mechanisms described in [Klensin-emailaddr] and the encapsulation mechanism outlined in earlier versions of that draft and the alternate headers of [Hoffman-UTF8-headers]. This document suggests that the Yoneya and Fujiwara draft (sometimes just referred to as "the proposal", below) is inadequate in several respects and that its use would cause difficulties with some conforming implementations and existing uses of Internet mail. It then provides an introduction to some alternatives but is not itself a proposal for any of them, partially because of the issue raised in Section 4. 2. Terminology Note The abbreviation used to refer to internationalized email addresses prior to the introduction of this work into the IETF (i.e., starting with the "IEE BoF" scheduled for IETF-64) was "IMA". That string was used in the file names and titles of various documents, and in the discussion within them. However, the term has already been used for a working group in the IETF and is hence unsuitable for the name of a new working group and may create confusion with internal references. The string "IEE", while appropriate to designate the BoF, was the name of one of the associations that came together to form the IEEE, an organization of which many IETF participants are members and with which the IETF has close working relationships in several areas. In an attempt to migrate from "IMA" to something that is clear and unambiguous, this document generally uses the terms "i18n email", "i18n addresses", and "i18n headers", or spells "i18n" out as "internationalization" or "internationalized", where appropriate. It is reasonable to treat those terms as near-synonyms for "IMA", especially when reading the document described in [IMA-Framework] Klensin Expires May 5, 2006 [Page 3] Internet-Draft IMA Downgrade Considerations November 2005 3. Difficulties with the Yoneya and Fujiwara Approach 3.1. Uses and Decomposition of Local-Parts Over the years, local-parts of email addresses have been used, not only to identify simple mailboxes and their names, but for a variety of other purposes. Those have included mail routing paths and principles (both within and between enterprises), to identify special-purpose subaddresses, to encapsulate commands for various systems, and for a variety of other purposes, some using these techniques in combination. The key reason why all of these options and variations have worked is that there has always been a strong rule that no mail handling system, other than the server to which final delivery is made, is permitted to parse or interpret the contents and structure of the local-part of a mail address. SMTP also does not specify the order in which the final delivery server is to evaluate and process the local-part. For many SMTP implementations, the order in which operations are performed on a message being received is a critical element to the internal architecture of their designs. Imposing a requirement that, in practice, in order to obtain the advantages of i18n email, all receiving servers will be required to perform the steps associated with receiving mail in a particular order is almost certain to significantly retard i18n email implementation: extensions that require that servers be completely rewritten are unlikely to take hold. In addition, the use of a downgrade procedure that is based exclusively on conversion of the local-part to an ACE form, with the assumption that the receiving server (whether upgraded to support i18n email or not) will recognize that ACE form and process it to the extent required, ignores two important realities of Internet mail. The first of these realities is that many of the uses of internal structure in local-parts impact the delivery structure and logic of the final delivery MTA. If the address is encoded such that the MTA cannot "see" special characters or structure that might trigger special actions early enough to apply them, then such encoding will certainly fail to provide the intended function. Second, unlike the DNS, where applications have long been restricted to the letter- digit-hyphen combination for hostnames, SMTP imposes essentially no limitations on the characters that can be used in a local-part (even though some of them require quoting). Because of the wide variety of conventions used for various types of information encoded into those addresses and because there is no equivalent to sweeping the DNS tree looking for unused sequences of introducer characters, it is not reliably possible, absent the SMTP extension that identifies i18n email, to know whether a particular sequence is a prefix identifying a special type of ACE or whether it is just an ordinary, although Klensin Expires May 5, 2006 [Page 4] Internet-Draft IMA Downgrade Considerations November 2005 somewhat strange-looking, address. Unless users of Internet mail are to be faced with a choice between the use of these advanced features and the use of i18n addresses, i.e., that the advanced features will be available only to those who use traditional ASCII addresses, great care must be taken with any system for encoding addresses during downgrading. That choice is unlikely to be acceptable in the long term, since the users of i18n- enabled systems will certainly discover the advantages of the capability for structured mail addresses as the more email- experienced, ASCII-based users and addresses have done. 3.2. From Whence an ACE The proposal specifies that local-parts of addresses will be converted using the basic IDNA mechanisms ([RFC3490]), resulting in a punycode encoding, but with a different prefix. Unfortunately, several of the operations and nameprep tables used for IDNA are specifically tailored to the character constraints for "hostname" (LDH) DNS names. If the system of the proposal were otherwise workable, which other sections of this document argues that it is not, it would almost certainly still be necessary to design a new ACE form, supported by different stringprep profile(s) and nameprep- equivalent operations. 3.3. Header Retention and Loss Any system that depends on message headers other than those specified in [RFC2822] to encode information about downgrading, such as the X-IMA-Downgraded header of the Yoneya and Fujiwara proposal, must be aware that such headers are often lost or destroyed in mail gateways, spam and other filtering systems, firewall SMTP implementations, and so on. Since the semantics of such headers cannot be assumed except by mutual consent of the exchanging parties, dropping such headers is often an important security precaution. Of course, if the X-IMA- Downgrade header is really unnecessary and does not community any important information, the potential loss of that header should not be a major concern. 3.4. Encoding Information in Headers The current standard for encoding non-ASCII information in specific fields of specific headers into "encoded words" [RFC2047], [RFC2231] is very specific about that information, where it is placed, and how it is represented. Statements such as "Encode UTF-8 part of headers by base64 of MIME with UTF-8 tag" (Section 3.3(2) of the proposal) are not conformant to, or at least not well-defined by, that standard. If the authors intend extensions or changes to that header Klensin Expires May 5, 2006 [Page 5] Internet-Draft IMA Downgrade Considerations November 2005 encoding standard, they should specify what they have in mind. And they should specify how existing implementations of that standard will be aware of, and respond to, the uses and extensions proposed in their proposal. 4. Putting Downgrading in Perspective 4.1. Where is Downgrading Needed? Downgrading of an i18n email address, or of UTF-8 headers, to traditional ASCII forms is needed only when the sending user anticipates that i18n addresses or headers can be used but some intermediate system or relay does not have the needed facilities to support those addresses or headers. If the sending user knows that the target system cannot support these internationalization extensions, then no sensible system or user will send such addresses or headers. Indeed, the receiving user of a non-upgraded system will have little incentive to announce a non-ASCII address. So a key question is where these non-upgraded relays come from. Within the Internet mail environment, and with source routing deprecated since [RFC1123], there are no relays in the message path whose behavior should be a surprise to the sender and receiver. The sender selects the submission server and can presumably determine its capabilities. If that submission server is not i18n email-capable, it is foolish for the sender to try to send such mail. Through the MX records that are specified, all subsequent relays are selected by, and presumably under the control of, the server identified by the forward-path email address. If the user whose email address is on that server understands that intermediate MX-specified relays are not i18n-capable, giving out i18n addresses is probably unwise. There is an edge case involving someone sending out an i18n reverse path to target systems that are not i18n capable, but it is not completely obvious that it is important enough to justify a complex downgrading infrastructure (see Section 4.3, below). Instead, it is likely that these extensions, like others, will be deployed within communities --linguistic ones in this case-- that need them, and will be deployed by community. Downgrade procedures that are designed to work across communities, e.g., to permit users who are literate only in Chinese to type and utilize Arabic addresses and text are unlikely to be important in practice, simply because the barriers to such communications are the traditional ones about communication across different languages and scripts: email addresses are a tiny part of that more general issue. Klensin Expires May 5, 2006 [Page 6] Internet-Draft IMA Downgrade Considerations November 2005 4.2. Transitional Pain or Long-term Kludges It is, or should be, almost axiomatic that any extension to support more internationalization in email should be designed so that a smoothly-operating and cleanly designed system is left after whatever transition period is needed. Mechanisms developed to enhance compatibility with legacy systems should largely disappear when those legacy systems do, rather than becoming permanent overly-complex and distorted ways of providing internationalization. The general set of proposals outlined in [IMA-Framework] and the subject downgrading proposal, even with the modifications outlined below, meets this criterion; some of the other approaches that have been suggested for internationalized addressing do not. 4.3. Learning from 8BITMIME When MIME [RFC1341] (now [RFC2045]) was first designed, one of the objectives of several of its supporters was to use it to provide direct (rather than additionally encoded) transmission of eight bit character data. To permit this, an SMTP extension, 8BITMIME [RFC1652], was defined. The history of deployment of that extension is interesting because, similar to the one proposed here, it had significant effects on both the transport framework for mail and on representation of message bodies. If a message was sent out in eight bit form, but reached a server that did not support the extension, a moderately complex downgrading procedure was defined as part of the extension specification. The alternative, for SMTP implementations that did not wish to include code for the downgrade procedure, was to simply reject (or "bounce") an eight bit message if it could not be transmitted to the next hop in eight bit form. Many, if not most, SMTP implementations were sufficiently "eight bit clean" that implementation of 8BITMIME merely required advertising the extension and then removing restrictions, so quickly supported the extension. However, especially for them, actual implementation of the downgrade procedure would have required significant additional work. At least in part because their implementers expected rapid and wide deployment of the extension, the downgrade procedure was much less frequently implemented than the extension itself. We expect that deployment of internationalized email addresses and transport will follow a similar pattern. For those implementations for which the requirement for seven bit local parts is merely a restriction to be removed, the most difficult part of implementation will be support for internationalized domain names via IDNA [RFC3490]. However, downgrade procedures that preserve maximum information are going to be inherently complex and implementations may, in practice, just choose to avoid them. As a result, an attempt to require that all i18n email implementations support a downgrading Klensin Expires May 5, 2006 [Page 7] Internet-Draft IMA Downgrade Considerations November 2005 capability at every stage is likely to either be ignored or to impede, rather than facilitate, the deployment of internationalized address and email forms. 5. Some Alternate Mechanisms A number of suggestions to assist in downgrading have been made and discussed during the work that led up to the IMA Framework document [IMA-Framework]. Those suggestions included approaches for indentifying an all-ASCII address, when appropriate, to be used in downgrading. Such an address would provide an alternative to arbitrarily encoding the i18n address into an ACE in ways that would mask or destroy any internal structure in the address. Some of those approaches are summarized below. 5.1. Identification of an Alternate Address The idea of an "alternate address", supplied as an ALT-ADDRESS parameter to enhanced MAIL or RCPT commands, is described briefly in [IMA-SMTPext]. If such an address were supplied by the sending user, and downgrading were necessary, the address could be used as a substitute for the i18n one. The idea is not without its limitations. In particular, the address would need to come from somewhere, presumably a query to, or being spontaneously supplied by, the recipient for forward-pointing address fields. MUA modifications, potentially quite extensive ones, would be needed to keep track of these addresses (e.g., in address books) and to supply them to the first-hop SMTP server. Given the principles discussed in Section 4.1, it is likely that a user who would be supplied an alternate address might just decide to send a message with traditional addresses, rather than incurring the entirely predictable downgrade conversion. On the other hand, use of ALT-ADDRESS might make a good deal of sense for backward-pointing (MAIL FROM) addresses. 5.2. Asserting that the Address is Atomic Another alternative that was discussed is probably complementary to ALT-ADDRESS rather than a replacement for it. While we prohibit mail systems from making assumptions about the structure of addresses in transit or at the sending system, we do not impose such a requirement on users. If the intended recipient has told the sending one, perhaps as part of supplying the address, that the address is, in fact, not structured and that ACE encodings will be accepted by the final delivery MTA and its processing systems, then (and only then, given the discussion above) it is possible to apply an ACE encoding to the entire local part. That assertion could be reflected in Klensin Expires May 5, 2006 [Page 8] Internet-Draft IMA Downgrade Considerations November 2005 transport by a different extension parameter on address fields, e.g., by a keyword indicating the local part could be treated as atomic. The "ATOMIC" parameter should have been included in [IMA-SMTPext] but was apparently accidentally omitted. For ATOMIC and ALT-ADDRESS, if neither parameter is provided but downgrading turns out to be necessary, the message would be rejected at the downgrade point. In essence, failure to supply either parameter would be taken as an assertion on the part of the sender that downgrading was not appropriate. 5.3. An Alternate Address Directory While it has not been explored in any detail, it would clearly be possible to set up some sort of directory-search protocol, possibly identified via SRV or NAPTR records associated with the domain of the email address, so that a system that needed to downgrade could query the directory with the i18n address and get back an appropriate substitute ASCII address. As with the two optional parameters, failure to find a directory, or an address in the directory, would be taken as an assertion that no downgrading was appropriate. 5.4. Encoding and Encapsulating Downgrading of addresses in an email envelope is fundamentally easy: one needs to only figure out who to obtain a set of traditional-style addresses and then substitute them for the i18n addresses. Traditional-style addresses can be found from a command parameter, from a directory, or, if the user asserts (based on good information from the intended recipient) that the address is atomic and will be processed correctly in the receiving systems, by conversation to some ACE. Headers are inherently more difficult, as discussed above. The encoded word mechanism cannot easily be generalized so that new field encodings will be decoded by receiving systems. While i18n addresses being downgraded in headers could be encoded into name phrases to preserve information for the user (another suggestion from earlier meetings on which this proposal does not incorporate), newly-supplied headers are subject to getting lost. While the general proposal would need more work, some variation on the type of message encapsulation provided by the "message/rfc822" MIME content type or that associated with batch SMTP [RFC2442] might be used to completely encapsulate the non-trace information of a message with i18n headers so that no information is lost. Of course, making effective use of such a mechanism in, e.g., message replies, would require an implementation of the new content type in receiving MUAs that corresponded roughly to mechanisms used to deconstruct multipart/ digest types and reply to individual messages in them. This general approach is outlined briefly in [Klensin-emailaddr] Klensin Expires May 5, 2006 [Page 9] Internet-Draft IMA Downgrade Considerations November 2005 5.5. Just Reject the Message The email i18n features for both addresses and headers include, and are protected by, an SMTP extension. As a result, the simple failure and/or return of a message that requires these features is not, from the standpoint of the existing email infrastructure, a failure. Instead, such a failure is simply an acknowledgement that the message could not be delivered as sent; if the sender wants a message delivered, it should be a different message. This is, in essence, an "address undeliverable" or "message undeliverable" condition. As such, it is not much different from the "undeliverable address" conditions of traditional Internet mail. While SMTP was originally designed to enable address correction while a message was in transit, the facilities have fallen into disuse because they are too complex and raise too many other issues, including security ones. Instead, we normally just reject messages that are undeliverable as addressed or formatted and let the sender figure things out and, preferably, adopt different behavior for the future. (See the discussion of "Forwarding for Address Correction or Updating" in Section 3.4 of [RFC2821] for a perspective on this issue.) It is plausible to believe that i18n email addresses that cannot be delivered are quite similar to conventional ones that have become obsolete and that they should be treated the same way, i.e., rejected rather than "corrected". 6. Internationalization Considerations This entire specification addresses issues in internationalization and especially the boundaries between internationalization and localization and between network protocols and client/user interface actions. 7. IANA Considerations This specification does not contemplate any IANA registrations or other actions. 8. Security Considerations It is worth noting that various proposals for digitally-signed and authenticated header fields, including those under discussion in the "DKIM" context, may be incompatible with in-transit address rewriting as part of a downgrade procedure. That issue is not identified in the present proposal, nor is it discussed in [IMA-Framework]. Of course, the discussion is not necessary in the latter, at least as Klensin Expires May 5, 2006 [Page 10] Internet-Draft IMA Downgrade Considerations November 2005 long as that document assumes that downgrading is not a requirement of the framework. ... More to be supplied ... 9. Acknowledgements The discussion in this document builds upon extensive discussion during the JET meeting in Beijing in September 2005. The contributions of all participants in that meeting are gratefully acknowledged. 10. Some Conclusions Downgrading is a difficult business. One must try to preserve all information but still work within the existing Internet email environment, guaranteeing that non-upgraded SMTP and MUA implementations will not malfunction with downgraded versions of i18n messages. To perform i18n address downgrading in the general case, there must be either an external source for a traditional address or a user assertion that it is safe to translate the address mechanically. Many possible approaches, including the one proposed by Yoneya and Fujiwara, fail the information preservation requirement and retain some risk of traditional conforming email implementations failing to perform as expected when comfronted with the type of downgraded address they propose. draft-yoneya-ima-downgrade-00 does not define a useful, safe, and fully-compatible downgrade mechanism. It ignores fundamental principles of Internet email addressing and address management, does not adequately specify an appropriate ACE and how it can be safely used, and does not adequately define safe and information-preserving transformations between UTF-8 headers. It can probably be fixed by incorporating some of the ideas discussed above and others. On the other hand, if it turned out to be the best we can do -- if all other possible solutions turned out to be too complex from an implementation, deployment, or operational standpoint -- then it would become a powerful argument as to why downgrading is inappropriate for i18n email messages. At least in the opinion of this author, a faulty downgrade mechanism is worse than no downgrade mechanism at all. Faulty mechanisms can be a threat to the Internet's infrastructure for reliable non-i18n mail. By contrast, the absence of a downgrade mechanism merely results in i18n messages that cannot be delivered as i18n messages being rejected and returned to the sender. It is important to Klensin Expires May 5, 2006 [Page 11] Internet-Draft IMA Downgrade Considerations November 2005 remember that the "IMA" collection of i18n email specifications will work adequately without any downgrade mechanism being specified at all: there is no practical operational requirement for a downgrade mechanism, much as it would be useful. So, while the development of a useful downgrade mechanism is to be encouraged, it is not a subject on which the IMA/ i18n email effort should get blocked. 11. References [Hoffman-IMAA] Hoffman, P. and A. Costello, "Internationalizing Mail Addresses in Applications (IMAA)", draft-hoffman-imaa-03 (work in progress), October 2003. [Hoffman-UTF8-headers] Hoffman, P., "SMTP Service Extensions for Transmission of Headers in UTF-8 Encoding", draft-hoffman-utf8headers-00 (work in progress), December 2003. [IMA-Framework] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", draft-klensin-ima-framework-00 (work in progress), September 2005. [IMA-SMTPext] Yao, J., Ed., "SMTP Extension for Internationalized Email Address", draft-yao-smtpext-00 (work in progress), September 2005. [JET-IMA] Yao, J. and J. Yeh, "Internationalized eMail Address (IMA)", draft-lee-jet-ima-00 (work in progress), June 2005. [Klensin-emailaddr] Klensin, J., "Internationalization of Email Addresses", draft-klensin-emailaddr-i18n-03 (work in progress), July 2005. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, June 1992. [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", Klensin Expires May 5, 2006 [Page 12] Internet-Draft IMA Downgrade Considerations November 2005 RFC 1652, July 1994. [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels'", RFC 2119, March 1997. [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [RFC2442] Freed, N., Newman, D., and Hoy, M., "The Batch SMTP Media Type", RFC 2442, November 1998. [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [Yoneya-downgrade] YONEYA, Y., Ed., "Downgrading mechanism for Internationalized eMail Address (IMA)", October 2005. Klensin Expires May 5, 2006 [Page 13] Internet-Draft IMA Downgrade Considerations November 2005 Author's Address John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 Email: john-ietf@jck.com Klensin Expires May 5, 2006 [Page 14] Internet-Draft IMA Downgrade Considerations November 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Klensin Expires May 5, 2006 [Page 15]