One document matched: draft-ietf-eai-scenarios-03.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-eai-scenarios-03" ipr="full3978">
  <front>
    <title abbrev="UTF8MAIL Scenarios">UTF-8 Mail: Scenarios</title>
    <author fullname="Harald Tveit Alvestrand" initials="H. T." role="editor"
            surname="Alvestrand">
      <organization>Google</organization>

      <address>
        <postal>
          <street>Beddingen 10</street>

          <city>Trondheim</city>

          <region></region>

          <code>7014</code>

          <country>Norway</country>
        </postal>

        <email>harald@alvestrand.no</email>
      </address>
    </author>

    <date day="24" month="January" year="2008" />

    <abstract>
      <t>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.</t>

      <t>One possible set of extensions that can work in these scenarios is
      those described in the UTF8SMTP extension documents.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>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.</t>

      <t>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.</t>

      <section title="Terminology">
        <t>Terminology is inherited from the <xref
        target="RFC4952">UTF8SMTP framework</xref> - 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.</t>

        <t>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.</t>

        <t>The pronouns "he" and "she" are used to indicate a human of
        indeterminate sex.</t>
      </section>

      <section title="User interface issues">
        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>In order to keep this document short, the following capabilities
        are assumed:</t>

        <t><list style="symbols">
            <t>An i18mail user is able to enter and display directly all
            characters of interest to him in his language locale.</t>

            <t>An i18mail user is able to display all valid characters for EAI
            addresses, store them in an address book, and use "reply" without
            damaging the address.</t>

            <t>If the i18mail solution requires keeping extra information
            around for an address in some cases, the i18mail user is capable
            of manipulating that information, including storing that
            information in his address book</t>
          </list>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.</t>
      </section>

      <section title="Ignored issues">
        <t>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.</t>
      </section>
    </section>

    <section title="Important Scenarios">
      <t>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.)</t>

      <t>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.</t>

      <section title="Two i18mail users">
        <t>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.</t>

        <t>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.</t>
      </section>

      <section title="Three i18mail users">
        <t>As above, but A sends his message to both B and C. Both reply to
        all the recipients listed in the message.</t>

        <t>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.</t>
      </section>

      <section anchor="i18maillist" title="i18mail mailing list">
        <t>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.</t>

        <t>Requirement: As above - all messages arrive, with EAI addresses
        preserved for all 3 users.</t>
      </section>

      <section title="One i18mail user sends to one ascii user">
        <t>A, an i18mail user, sends to X, an ascii user. X replies.</t>

        <t>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.</t>

        <t>Precondition: A has to have an ascii address.</t>

        <t>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.</t>

        <t>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.</t>

        <t>Examples of ways this could happen:</t>

        <t><list style="symbols">
            <t>Magic happens in the network: A's message gets converted in the
            network to a format acceptable to X. This may require A to include
            extra information with the message to help the conversion process
            - and may be impossible to do for the general case.</t>

            <t>Sender selection: A's i18mail message gets bounced in the
            network, and the reception of the error report causes A to resend
            the message using a format acceptable to X.</t>

            <t>Conversion at destination: A's message gets accepted, and X has
            facilities available to convert it into a form that allows X to
	    reply to the message, including deriving a valid ASCII address for A.
	    This would require
            knowledge of i18n at X's site, but not necessarily in X's user
            agent.</t>
          </list>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.</t>
      </section>

      <section title="An i18mail user sends to one ascii user and one i18mail user">
        <t>In this scenario, A sends to B and X; both reply.</t>

        <t>Precondition: A and B have to have valid ASCII addresses.</t>

        <t>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.</t>

        <t>Possible non-requirements (for discussion):</t>

        <t><list style="symbols">
            <t>Maybe the messages to B and X don't need to be exactly the
            same.</t>

            <t>Maybe B doesn't need to see or use A's i18n-address when he's
            replying to A and X.</t>

            <t>Maybe X doesn't need to see A's address exactly the same on the
            message from A and the reply from B.</t>
          </list></t>
      </section>

      <section title="An i18mail user sends to a mailing list with a mix of users">
        <t>In this scenario, A sends to L, and L has B and X as subscribers. B
        and X reply.</t>

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

        <t>Notes and non-requirements:</t>

        <t><list style="symbols">
            <t>It may be acceptable for A to have to treat L as if L was an
            ASCII mailing list (LA)</t>

            <t>It may be acceptable for B to see A's ASCII address, not his
            i18n-address</t>

            <t>How one can transition between this and the scenario of<xref
            target="i18maillist"> </xref> is unclear.</t>
          </list></t>
      </section>

      <section title="An i18mail user forwards to an ASCII user">
        <t>In this scenario, A sends to B, and B forwards the message as a
        MIME attachment to X.</t>

        <t>Precondition: B has valid ASCII addresses.</t>

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

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

    <section title="Other scenarios">
      <t>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.</t>

      <section title="Two i18mail users, intermediate non-extended MTA">
        <t>In this scenario, A sends mail to B through an MTA that does not
        support i18mail extensions.</t>

        <t>Requirement: Mail arrives.</t>

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

        <t>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.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Security issues are deliberately left unaddressed in order to reduce
      the size of the document.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t></t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.4952"?>
    </references>
  </back>
</rfc>