[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc5983                               
Internet Draft: Mailing Lists and Internationalized          R. Gellens
                Email Addresses                                Qualcomm
Document: draft-ietf-eai-mailinglist-02.txt                    E. Chung
Expires: January 2008                                           Afilias
                                                              July 2007


          Mailing Lists and Internationalized Email Addresses


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.


Copyright Notice

    Copyright (C) The IETF Trust (2007).  All Rights Reserved.


Abstract

    This document describes considerations for mailing lists with the
    introduction of internationalized email addressing capabilities.

    Different scenarios involving interaction between mailing lists and
    internationalized email addresses are examined.  Furthermore,
    mailing list header fields are discussed.






Gellens & Chung              [Page 1]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007


    This document makes specific recommendations on how mailing lists
    should act in various situations.

















































Gellens & Chung              [Page 2]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007


Table of Contents

     1  Conventions Used in this Document . . . . . . . . . . . . . .  3
     2  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
     3  Scenarios Involving Mailing Lists   . . . . . . . . . . . . .  5
       3.1  Pure Case Scenarios  . . . . . . . . . . . . . . . . . .   6
       3.2  Mixed Case Scenarios  . . . . . . . . . . . . . . . . . .  7
     4  Capabilities and Requirements  . . . . . . . . . . . . . . .   8
     5  List Header Fields  . . . . . . . . . . . . . . . . . . . . .  9
     6  List Management    . . . . . . . . . . . . . . . . . . . . .  10
     7  Further Discussion  . . . . . . . . . . . . . . . . . . . . . 11
     8  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  12
     9  Security Considerations   . . . . . . . . . . . . . . . . . . 12
    10  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  12
    11  Normative References  . . . . . . . . . . . . . . . . . . . . 12
    12  Informative References . . . . . . . . . . . . . . . . . . .  12
    13  Author's Address  . . . . . . . . . . . . . . . . . . . . . . 13
       Appendix A: Changes from Previous Version . . . . . . . . . .  14
       Intellectual Property Statement  . . . . . . . . . . . . . . . 13
       Full Copyright Statement  . . . . . . . . . . . . . . . . . .  14
    14  Copyright Statement   . . . . . . . . . . . . . . . . . . . . -1


1 Conventions Used in this Document

    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 [KEYWORDS].


2 Introduction

    Mailing lists are an important part of email usage and collaborative
    communications.  The introduction of internationalized email
    addresses affects mailing lists in three main areas: (1) transport
    (receiving and sending messages); (2) message headers of received
    and retransmitted messages; and (3) mailing list operational
    policies.

    A mailing list is a mechanism whereby a message may be distributed
    to multiple recipients by sending to one address.  An agent
    (typically not a human being) at that single address receives the
    message and then causes the message to be redistributed to a list of
    recipients.  This agent sets the envelope return address of the
    redistributed message to a different address from that of the
    original message.  Using a different envelope return address
    (reverse-path) directs error (and other automatically generated)
    messages to an error handling address associated with the mailing
    list. (This avoids having error and other automatic messages go to


Gellens & Chung              [Page 3]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007


    the original sender, who typically doesn't control the list and
    hence can't do anything about them.)

    In most cases, the mailing list agent redistributes a received
    message to its subscribers as a new message, that is, conceptually
    it uses message submission [submit] (as did the sender of the
    original message).  The exception, where the mailing list is not a
    separate agent that receives and redistributes messages in separate
    transactions, but is instead an expansion step within an SMTP
    transaction where one local address expands to multiple local or
    non-local addresses, is out of scope for this document.

    Some mailing lists alter the message header, while others do not.  A
    number of standardized list-related header fields have been defined,
    and many lists add one or more of these headers.  Separate from
    these standardized list-specific header fields, and despite a
    history of interoperability problems from doing so, some lists alter
    or add header fields in an attempt to control where replies are
    sent.  Such lists typically add or replace the "Reply-To" field and
    some add or replace the "Sender" field.  Poorly-behaved lists may
    alter or replace other fields, including "From".

    Among these list-specific header fields are those specified in
    RFC2369 -- The Use of URLs as Meta-Syntax for Core Mail List
    Commands and their Transport through Message Header Fields [List-*]
    and RFC2919 -- List-Id:  A Structured Field and Namespace for the
    Identification of Mailing Lists [List-ID].  For more information,
    see Section 5.

    While the mail transport protocol does not differ between regular
    email recipients and mailing list recipients, lists have special
    considerations with internationalized email addresses because they
    retransmit messages composed by other agents to potentially many
    recipients.  Discussion of the different scenarios involving mailing
    lists and internationalized email addresses is in Section 3.

    There are considerations for internationalized email addresses in
    the envelope as well as header fields of redistributed messages.  In
    particular, an internationalized message cannot be downgraded unless
    envelope addresses are in ASCII (which includes use of ALT-ADDRESS).

    With mailing lists, there are two different types of considerations:
    first, the purely technical ones involving message handling, error
    cases, downgrades, and the like, and second, those that arise from
    the fact that humans use mailing lists to communicate.  As an
    example of the first, mailing lists might choose to reject all
    messages from internationalized addresses that lack an alt-address,
    or even all internationalized messages that can not be downgraded.
    As an example of the second, a user who sends a message to a list


Gellens & Chung              [Page 4]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007


    often is unaware of the list membership.  In particular, the user
    often doesn't know if the members are i18mail users or not, and
    often neither the original sender nor the recipients personally know
    each other.  As a consequence of this, remedies that may be readily
    available for one-to-one communication might not be appropriate when
    dealing with mailing lists.  For example, if a user sends a message
    which is undeliverable, normally the telephone, instant messaging,
    or other forms of communication are available to obtain a working
    address.  With mailing lists, the users may not have any recourse.
    Of course, with mailing lists, the original sender usually does not
    know if the message was successfully received by any list members,
    or if it was undeliverable to some.

    Conceptually, a mailing list's internationalization can be divided
    into three capabilities:  First, does it have a UTF8 submission
    address?  Second, does it accept subscriptions to UTF8 addresses?
    And third, does it accept UTF8SMTP messages?  This is explored in
    Section 4.

    A brief discussion on some key considerations for mailing list
    operation in an internationalized email address environment is
    proposed in Section 6.  This is followed by further discussions in
    Section 7.


3 Scenarios Involving Mailing Lists

    Expanding from Sections 2.3 ("i18mail mailing list") and 2.6 ("An
    i18mail user sends to a mailing list with a mix of users") of the
    Scenarios document [EAI- Scenarios], this section will provide an
    overview of the different scenarios involving mailing lists and
    internationalized email addresses.

    What is worth noting is that generally (and exclusively within the
    scope of this document) the original message is sent to a mailing
    list as a completely separate and independent transaction from the
    mailing list agent sending the retransmitted message to one or more
    list recipients.  In both cases, the message might have only one
    recipient, or might have multiple recipients.  That is, the original
    message might be sent to additional recipients as well as the
    mailing list agent, and the mailing list might choose to send the
    retransmitted message to each list recipient in a separate message
    submission transaction, or might choose to include multiple
    recipients per transaction. (Often, mailing lists are constructed to
    work in cooperation with, rather than include the functionality of,
    a message submission server, and hence the list transmits to a
    single submission server one copy of the retransmitted message, with
    all list recipients specified in the SMTP envelope.  The submission
    server then decides which recipients to include in which


Gellens & Chung              [Page 5]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007


    transaction.)


    [[[EDITOR'S NOTE:  Is there any value to the text starting here?]]]

    The following diagram summarizes the conceptual working of a
    mailing- list (Pure Case):

                                                (b)
                                               -----> User1@exmaple.tld
                       (a)                    / (c)
   User1@example.tld ------> mailing@list.tld ------> User2@example.tld
                                              \ (d)
                                               -----> ...


    As observed above, the mail transport transactions (a), (b), (c) and
    (d) all involves two parties, that is: 1.  The mailing list agent;
    and, 2.  The original author / subscriber.  These scenarios are
    essentially the same as those already described in Sections 2.1 and
    2.4 of the Scenarios document [EAI-Scenarios].

    Multiple recipients are involved when additional addresses are
    included (Mixed Case):


                                               -----> User1@exmaple.tld
                       (a)                    /
   User1@example.tld ---+--> mailing@list.tld ------> User2@example.tld
                        |              ^      \ (d)
                        |              |       -----> ...
                        |              |                      |
                        v              |  (e)                 |
                  cc@example.tld <-----+-------------(reply)--+


    Under this situation, scenarios (a) and (e) resemble the situations
    already described in Sections 2.2 and 2.5 of the Scenarios document
    [EAI-Scenarios].  More specific discussions based on these two
    general cases are included below.

3.1 Pure Case Scenarios

    In the Pure Case described above, the following are possible for
    (a):

       User1@example.tld    mailing@list.tld
   (1)       ASCII               ASCII
   (2)     non-ASCII             ASCII


Gellens & Chung              [Page 6]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007


   (3)       ASCII             non-ASCII
   (4)     non-ASCII           non-ASCII

    Among this set, (1) is simply the conventional case without
    involving any internationalized email address. (2) and (3) are
    scenarios described in Section 2.4 -- One i18nmail user sends to one
    ASCII user -- of the Scenarios document, whereas (4) is described in
    Section 2.1 -- Two i18nmail users [EAI-Scenarios].

    For (d) -- generalizing (b) and (c) -- it may be branched further
    where: (i) Mailing list contains only ASCII email addresses (ii)
    Mailing list contains at least one internationalized email address

    [[[EDITOR'S NOTE:  Is there any value to the text ending here?]]]

    The retransmitted message sent by the mailing list to its
    subscribers might need to be downgraded [EAI-Downgrade].  In order
    for a downgrade to be possible, the return path set by the mailing
    list agent must be an ASCII address or have ALT-ADDRESS specified.

    list (and/or its MTA) must therefore have the alt-address.  In
    general, it may be prudent for mailing list operators to pre-obtain
    an alt-address for all its internationalized member addresses.  This
    will ensure that mailing list transactions within members will be
    able to be delivered and replied to.  Further discussion on mailing
    list policy considerations is included in section 6 of this
    document.

    In the specific case where a non-member with an internationalized
    email address is sending to a mailing list, and that mailing list is
    UTF8SMTP-aware, and the path to a constituent member calls for a
    downgrade, the mailing list (and/or its MTA) may not have the alt-
    address of the non-member's internationalized email address,
    therefore failing to deliver the message to some members.  To
    protect against this, a UTF8SMTP-aware mailing list might prefer to
    reject submissions from internationalized email addresses that lack
    an alt-address.

    (Note that in the situation is not unique to mailing lists.  Mail
    relays that are UTF8SMTP- aware will potentially encounter the same
    situation.) Further discussions are included in section 7 of this
    document.

    [[[EDITOR'S NOTE:  Is there any value to the text starting here?]]]

3.2 Mixed Case Scenarios





Gellens & Chung              [Page 7]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007


    The Mixed Case scenarios are essentially a combination of the
    discussion in section 3.1 above, plus those described in Section
    3.2 -- Three i18nmail users -- and, Section 2.5 -- An i18mail user
    sends to one ascii user and one i18nmail user -- of the Scenarios
    [EAI- Scenarios] document.

    Similar issues arise with regards to members versus non-members,
    especially non-members with an internationalized email address, as
    discussed in the above section.

    [[[EDITOR'S NOTE:  Is there any value to the text ending here?]]]


4 Capabilities and Requirements

    There are three primary internationalization capabilities of mailing
    lists:  First, does it have a UTF8 submission address?  Second, does
    it allow subscriptions from UTF8 addresses?  And third, does it
    accept UTF8SMTP messages?

    In theory, any list can support any combination of these.  In
    practice, only some offer any benefit.  For example, neither
    allowing UTF8 addresses to subscribe, nor accepting UTF8SMTP
    messages, makes much sense without the other (an all-ASCII address
    might or might not be capable of receiving UTF8SMTP messages, but a
    UTF8 address of necessity needs to accept UTF8SMTP messages).
    Likewise, there is no real benefit to a list in using a UTF8
    submission address unless it also accepts UTF8SMTP messages and
    permits UTF8 addresses to subscribe.

    However, requirements for lists can be discussed separately for each
    of the three capabilities.

    1.  If the list uses a UTF8 submission address, it SHOULD specify an
    alt-address for it.  Clearly, it needs to sit behind a
    UTF8SMTP-enabled final-delivery SMTP server and delivery agent.

    The list's return-path address is usually separate from its
    submission address (so that delivery reports and other
    automatically-generated messages are not sent to the submission
    address).  For reliability in receiving delivery status
    notifications, a list MAY choose to use an all-ASCII return-path
    even if it uses a UTF8 submission address.  If the list does use a
    UTF8 return path, it MUST specify an alt-address (or else there is a
    high risk of being unable to receive non-delivery reports).






Gellens & Chung              [Page 8]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007


    It follows that if a list uses a UTF8 submission (or return-path)
    address, then its MSA needs to support UTF8SMTP.

    There are also implications for the List-* headers (see below).

    2.  If it allows UTF8 addresses to subscribe, it MAY require an
    alt-address to be specified for each UTF8 subscriber.

    Naturally, if it permits UTF8 addresses to subscribe, it needs a
    mechanism to accept subscription requests from such addresses
    (preferably specified in the form <utf8@utf8<ascii@ascii>>).
    Likewise, its MSA needs to support UTF8SMTP.

    3.  If it accepts UTF8SMTP messages, its MSA needs to support
    UTF8SMTP.


5 List Header Fields

    A number of header fields specifically for mailing lists have been
    introduced in RFC2369 and RFC2919.  These include, for example:

    List-Id: List Header Mailing List <list-header.nisto.com>
    List-Help: <mailto:list@host.com?subject=help> (List Instructions)
    List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
    List-Subscribe: <mailto:list@host.com?subject=subscribe>
    List-Post: <mailto:list@host.com>
    List-Owner: <mailto:listmom@host.com> (Contact Person for Help)
    List-Archive: <mailto:archive@host.com?subject=index%20list>

    As described in RFC2369, "The contents of the list header fields
    mostly consist of angle-bracket ('<', '>') enclosed URLs, with
    internal whitespace being ignored." [List-*] Whereas RFC2919
    specifies that, "The list identifier will, in most cases, appear
    like a host name in a domain of the list owner." [List-ID]

    These mailing list header fields contain URLs.  The most common
    schemes are generally HTTP, HTTPS, mailto, and FTP.  These header
    fields will need to be extended to support UTF8 addresses.  Except
    for mailto, there are no EAI-specific considerations, since these
    URLs can use RFC3987 "Internationalized Resource Identifier (IRI)"
    [IRI].  Note that mailto is being updated in a separate effort
    (outside of EAI), in [mailto-bis].

    The same mechanism should be used for these fields as with other
    fields specifically discussed in the UTF8-Headers document
    [EAI-UTF8Headers].  Generally therefore, for fields that contain an
    internationalized email address, it is preferable for it to be
    expressed as a UTF8 string.


Gellens & Chung              [Page 9]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007


    [[[EDITOR'S NOTE:  Does RFC 2369 need to be updated to permit the
    use of IRIs?]]]

    Downgrading provisions should also follow the mechanism in the
    downgrading document [EAI-Downgrade].  However, special provisions
    may be helpful for list-specific headers.  In particular, when a
    List-* header contains a UTF8 mailto followed by an ASCII mailto, it
    may be advisable to copy and preserve the original header as usual,
    but also edit the header to remove the UTF8 address. [[[EDITOR'S
    NOTE:  This needs to be vetted by the eai list, and if agreed, the
    eai-downgrade document adjusted, and if not, deleted from here.]]]

    For mailto URIs, an additional consideration is how to include an
    alternative ASCII address (alt-address) for a UTF8 address.  The
    most consistent approach is to extend mailto to permit the same
    syntax for alt-address as is used in address header fields, that is,
    <utf8@utf8 <asciI@ascii>>.  Until this is done, the existing ability
    to specify multiple URLs within each List-* header field provides a
    solution.

    [List-*] says:
       A list of multiple, alternate, URLs MAY be specified by a comma-
       separated list of angle-bracket enclosed URLs.  The URLs have
       order of preference from left to right.  The client application
       should use the left most protocol that it supports, or knows how
       to access by a separate application.

    When a UTF8 mailto is used in a List-* header field, an alt-address,
    if available, SHOULD immediately follow it.

    This is further discussed in Section 7.


6 List Management

    Given the need potentially to deal with non-UTF8SMTP-aware MTAs in
    the path of delivery for different members, it is advisable that
    mailing list operators obtain an alt-address from each member with
    an internationalized email address before adding the member.
    [[[EDITOR's NOTE:  This contradicts an assumption that the group has
    been operating under that the sender obviously won't use UTF8SMTP
    unless his or her MSA and outbound MTAs support it, the recipient
    won't use a UTF8 address unless his or her final-delivery MTA and
    delivery agent support UTF8SMTP, and hence downgrading is unlikely
    in the normal case of UTF8SMTP sender to UTF8SMTP recipient.
    Accordingly, perhaps this requirement should be deleted or
    weakened.]]]




Gellens & Chung              [Page 10]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007


    In consideration for consistent delivery to all members in a
    mailing- list, a mailing list may want to consider rejecting (or
    otherwise obtaining alt-address from) a non-member who is
    interacting with the mailing list from an internationalized email
    address without specifying an alt-address.  This is further
    discussed in Section 7.

    It is important that the final delivery MTA and delivery agent not
    deliver internationalized messages to a mailing list that is not
    capable of receiving and processing them.  Such messages MUST be
    downgraded or rejected unless the list supports internationalized
    email.

    Since a mailing list's MSA needs to support UTF8SMTP in order for it
    to send internationalized messages (including otherwise ASCII
    messages to UTF8 addresses), a list MUST NOT accept subscriptions
    from UTF8 addresses nor accept UTF8SMTP messages unless its MSA
    supports UTF8SMTP or it is prepared and able to downgrade such
    messages.


7 Further Discussion

    While mailing lists do not create a significant additional burden to
    the deployment of internationalized email address functionalities,
    there are some specific areas that need to be considered when the
    operator of a mailing list or of a final delivery MTA that serves a
    mailing list upgrades to internationalized mail.

    Mailing lists face additional complexity since they redistribute
    messages composed by other agents.  Hence, they may be asked to
    accept a message with non-ASCII headers composed by a UTF8SMTP-aware
    user agent, and redistribute it to i18mail and non-i18mail users via
    systems that are not UTF8SMTP-aware.

    1.  Obtaining Downgrade Information -- for a mailing list, or mail
    relay server for that matter, that is UTF8SMTP-aware, receiving mail
    from an internationalized email address, the alt-address is not
    required from the sending MTA for the transport to be complete.
    Thereupon when the mailing list retransmits the message to its
    subscribers, it may encounter paths where a downgrade is called for.
    In order to mitigate this situation, the mailing list might perhaps
    decide to reject all incoming mail from an internationalized email
    address that lacks an alt-address.  However, note that in general,
    downgrades are not expected to be the normal case.






Gellens & Chung              [Page 11]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007


    2.  Downgrading Considerations for mailto URLs -- UTF8 addresses in
    mailto links in List-* headers will be easier to downgrade if they
    contain an alt-address.


8 IANA Considerations

    None.


9 Security Considerations

    Security considerations are discussed in the Framework document
    [EAI-Framework].


10 Acknowledgments

    TBD.


11 Normative References

    [EAI-Framework] J. Klensin and Y. Ko, "Overview and Framework for
    Internationalized Email", draft-ietf-eai-framework-00.txt, May 24,
    2006

    [EAI-Scenarios] H. Alvestrand, "Internationalized Email Addresses:
    Scenarios",draft-ietf-eai-scenarios-00.txt , May 12, 2006

    [EAI-SMTPEXT] J. Yao and W. Mao, "SMTP extension for
    internationalized email address", draft-ietf-eai-smtpext-00.txt, May
    12, 2006

    [EAI-UTF8Headers] J. Yeh, "Internationalized Email Headers", draft-
    ietf-eai-utf8headers-00.txt, May 30, 2006

    [EAI-Downgrade] Y. YONEYA and K. Fujiwara, "Downgrading mechanism
    for Internationalized eMail Address (IMA)",
    draft-ietf-eai-downgrade- 00.txt, May 26, 2006


12 Informative References

    [mailto-bis] M. Duerst and L. Masinter, "The mailto URI scheme",
    draft-duerst-mailto-bis-xx (work in progress).





Gellens & Chung              [Page 12]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007


    [List-*] G. Neufeld and J. Baer, "The Use of URLs as Meta-Syntax for
    Core Mail List Commands and their Transport through Message Header
    Fields", July 1998

    [List-ID] R. Chandhok and G. Wenger, "List-Id:  A Structured Field
    and Namespace for the Identification of Mailing Lists", March 2001

    [IRI] M. Duerst and M. Suignard,"Internationalized Resource
    Identifiers (IRIs)", January 2005


13 Author's Address

    Randall Gellens
    QUALCOMM Incorporated
    5775 Morehouse Drive
    San Diego, CA  92121
    rg+ietf@qualcomm.com

    Edmon Chung
    Afilias
    Suite 204, 4141 Yonge Street,
    Toronto, Ontario,
    Canada M2P 2A8
    edmon@afilias.info


Appendix A:  Changes from Previous Version

    THIS SECTION TO BE REMOVED PRIOR TO PUBLICATION.

    Changes made from version -01 to -02:
    o   Significant changes throughout the document.  Sorry.

    Changes made from version -00 to -01:
    o   Fixed SMTP envelope versus message header confusion.
    o   Fixed erroneous mailing list operation text.
    o   Removed references to ATOMIC.
    o   Removed unneeded scenarios.
    o   Added discussion of human considerations which arise with lists.
    o   Fixed some typos.

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


Gellens & Chung              [Page 13]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007


    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.


Full Copyright Statement

    Copyright (C) The IETF Trust (2007).

    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.

    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, THE
    IETF TRUST 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.

14 Copyright Statement

    Copyright (C) The Internet Society (2007).  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.

    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.



Gellens & Chung              [Page 14]              Expires January 2008

Internet Draft       Mailing Lists and i18mail Addresses       July 2007




Gellens & Chung              [Page 15]              Expires January 2008