TOC 
Network Working GroupH. Alvestrand, Ed.
Internet-DraftGoogle
Intended status: InformationalJanuary 25, 2008
Expires: July 28, 2008 


UTF-8 Mail: Scenarios
draft-ietf-eai-scenarios-03

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 July 28, 2008.

Abstract

This document describes some scenarios in which one can imagine internationalized email addresses deployed, and tries to draw some conclusions about what's acceptable and what's not for users in those scenarios.

One possible set of extensions that can work in these scenarios is those described in the UTF8SMTP extension documents.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].



Table of Contents

1.  Introduction
    1.1.  Terminology
    1.2.  User interface issues
    1.3.  Ignored issues
2.  Important Scenarios
    2.1.  Two i18mail users
    2.2.  Three i18mail users
    2.3.  i18mail mailing list
    2.4.  One i18mail user sends to one ascii user
    2.5.  An i18mail user sends to one ascii user and one i18mail user
    2.6.  An i18mail user sends to a mailing list with a mix of users
    2.7.  An i18mail user forwards to an ASCII user
3.  Other scenarios
    3.1.  Two i18mail users, intermediate non-extended MTA
4.  IANA Considerations
5.  Security Considerations
6.  Acknowledgements
7.  Normative References
§  Author's Address
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

With the advent of internationalized email addresses [ref], there is a very real risk that people using Internet email will have problems communicating that they did not have before. This document tries to sketch some of the scenarios, define what "proper" behaviour would be in the situations, and describe how this will constrain solutions to the "internationalized email" problem.

Because of the well known phenomenon that short documents get more review, the document tries to be as brief as possible, as long as that does not sacrifice clarity.



 TOC 

1.1.  Terminology

Terminology is inherited from the UTF8SMTP framework (Klensin, J. and Y. Ko, “Overview and Framework for Internationalized Email,” July 2007.) [RFC4952] - in particular, the terms "ascii address", "non-ASCII address" or "i18n-address", "ascii user", "i18mail user", "message" and "mailing list" are used with the definitions from section 1.3 of that document.

The term "UTF8SMTP" is used to refer to the particular solution proposed in that framework, while "i18n mail" refers to any solution that could concievably satisfy these scenarios' requirements.

The pronouns "he" and "she" are used to indicate a human of indeterminate sex.



 TOC 

1.2.  User interface issues

In internationalization, one of the thornier issues has always been user interfaces. In particular in this context, the ability to manipulate text strings (email addresses, in this case) in a script that the user does not have familiarity with is an issue.

A main purpose of i18mail is to allow users to avoid doing so when corresponding with users in their own language locale when that locale normally does not use ASCII - but unless we accept an Internet email community of many small fragments, the introduction of "local" characters into email addresses will cause users to be exposed to addresses that they have trouble recognizing, are unable to enter, and in fact may be unable to display; in some cases, even storing the addresses is an issue.

For instance, handling of right-to-left scripts like Arabic in environments used to left-to-right scripts like Thai can be a serious challenge.

In order to keep this document short, the following capabilities are assumed:

One can imagine special circumstances where some of these do not represent an optimal solution (for instance, a Thai user may prefer to handle the ASCII address of an Arabic correspondent rather than his Arabic one), but this is an added complication, and is ignored for the moment.



 TOC 

1.3.  Ignored issues

All the scenarios assume that all parties desire to communicate, that spam filters do not eat messages randomly, and that the mail service behaves according to specification. These are not tenable assumptions in the real world, but considering them would make this document much longer.



 TOC 

2.  Important Scenarios

In the scenario descriptions below, A, B and C are i18mail users. X (and Y and Z if they need to occur) are ascii users. L is an i18n-aware mailing list; LA is a non-i18n-aware mailing list. (LA does not occur in the scenarios, however.)

Apart from the messages being exchanged, and A knowing the addresses of the ones he sends mail to, which are presumed to be made known to A through some other method (business cards, web pages, mail from other users and directories are some examples), there is no communication required between the users.



 TOC 

2.1.  Two i18mail users

One i18mail user (A) sends a message to another i18mail user (B), and desires to use his i18n-address. The recipient replies to the message.

Requirement: The message must arrive at the recipient. The reply must arrive at the sender. The email addresses visible to the sender and recipient must be the i18n-addresses.



 TOC 

2.2.  Three i18mail users

As above, but A sends his message to both B and C. Both reply to all the recipients listed in the message.

Requirement: As above - B and C must get the message, A and C must get the reply from B, A and B must get the reply from C. The email addresses visible to A, B and C must all be the i18n-addresses.



 TOC 

2.3.  i18mail mailing list

A sends his message to L, a mailing list, which has subscribers B and C. Both reply to the mailing list. The mailing list is i18n aware.

Requirement: As above - all messages arrive, with EAI addresses preserved for all 3 users.



 TOC 

2.4.  One i18mail user sends to one ascii user

A, an i18mail user, sends to X, an ascii user. X replies.

In this scenario, it is a given that A, the sender, has to have some facility for handling ASCII; he has to at least be able to display and enter an ASCII address.

Precondition: A has to have an ascii address.

Requirement: There must be an algorithmic series of steps that A can follow in order to get a message to X, and where X's reply gets back to A.

There is no requirement that X sees the i18n-address of A, or that the address of A that X sees be one that A knows about beforehand; the requirement is that the messages get there. This non-requirement applies to all the following cases too.

Examples of ways this could happen:

This is NOT an exhaustive list, and is NOT part of the requirements of the scenarios. A given protocol for i18mail will in turn impose new requirements on the scenarios - for instance, if extra information is included with the message, a user interface may need to exist to allow the sender to manipulate this information.



 TOC 

2.5.  An i18mail user sends to one ascii user and one i18mail user

In this scenario, A sends to B and X; both reply.

Precondition: A and B have to have valid ASCII addresses.

Requirement: Through some series of steps, A must be able to get a message to both B and X; through some series of steps, B and X must be able to reply to each other and to A. X must not require information outside of what is included in the message to get a message to B.

Possible non-requirements (for discussion):



 TOC 

2.6.  An i18mail user sends to a mailing list with a mix of users

In this scenario, A sends to L, and L has B and X as subscribers. B and X reply.

Requirement: Messages get there. A will not have to know anything about X in order to make the messages go through.

Notes and non-requirements:



 TOC 

2.7.  An i18mail user forwards to an ASCII user

In this scenario, A sends to B, and B forwards the message as a MIME attachment to X.

Precondition: B has valid ASCII addresses.

Requirement: The message from B to X should arrive whether or not A's address is usable by X.

Desirable property: If A's address is downgradable, it should be usable by X for generating a message.



 TOC 

3.  Other scenarios

This section collects scenarios that have been discussed, but where there is no WG consensus on whether or not they are important enough to influence the design of UTF8SMTP.



 TOC 

3.1.  Two i18mail users, intermediate non-extended MTA

In this scenario, A sends mail to B through an MTA that does not support i18mail extensions.

Requirement: Mail arrives.

Desirable property: B can see A's I18mail address in his user interface, and use that to reply.

The reason this may not be an important scenario is that due to the largely end-to-end nature of SMTP, if the end users have upgraded their systems, there should be very little reason to go via a non-upgraded MTA.



 TOC 

4.  IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.



 TOC 

5.  Security Considerations

Security issues are deliberately left unaddressed in order to reduce the size of the document.



 TOC 

6.  Acknowledgements



 TOC 

7. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4952] Klensin, J. and Y. Ko, “Overview and Framework for Internationalized Email,” RFC 4952, July 2007 (TXT).


 TOC 

Author's Address

  Harald Tveit Alvestrand (editor)
  Google
  Beddingen 10
  Trondheim, 7014
  Norway
Email:  harald@alvestrand.no


 TOC 

Full Copyright Statement

Intellectual Property