RFC2919 日本語訳

Network Working Group                                          R. Chandhok
Request for Comments: 2919                                       G. Wenger
Category: Standards Track                                   QUALCOMM, Inc.
                                                                March 2001

Network Working Group R. Chandhok Request for Comments: 2919 G. Wenger Category: Standards Track QUALCOMM, Inc. March 2001

                                List-Id:
                A Structured Field and Namespace for the
                    Identification of Mailing Lists

List-Id: A Structured Field and Namespace for the Identification of Mailing Lists

Status of this Memo

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

Abstract

   Software that handles electronic mailing list messages (servers and
   user agents) needs a way to reliably identify messages that belong to
   a particular mailing list.  With the advent of list management
   headers, it has become even more important to provide a unique
   identifier for a mailing list regardless of the particular host that
   serves as the list processor at any given time.

Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time.

   The List-Id header provides a standard location for such an
   identifier.  In addition, a namespace for list identifiers based on
   fully qualified domain names is described.  This namespace is
   intended to guarantee uniqueness for list owners who require it,
   while allowing for a less rigorous namespace for experimental and
   personal use.

The List-Id header provides a standard location for such an identifier. In addition, a namespace for list identifiers based on fully qualified domain names is described. This namespace is intended to guarantee uniqueness for list owners who require it, while allowing for a less rigorous namespace for experimental and personal use.

   By including the List-Id field, list servers can make it easier for
   mail clients to provide automated tools for users to perform list
   functions.  The list identifier can serve as a key to make many
   automated processing tasks easier, and hence more widely available.

By including the List-Id field, list servers can make it easier for mail clients to provide automated tools for users to perform list functions. The list identifier can serve as a key to make many automated processing tasks easier, and hence more widely available.

1. Introduction

1. Introduction

   Internet mailing lists have evolved into fairly sophisticated forums
   for group communication and collaboration; however, corresponding
   changes in the underlying infrastructure have lagged behind.  Recent

Internet mailing lists have evolved into fairly sophisticated forums for group communication and collaboration; however, corresponding changes in the underlying infrastructure have lagged behind. Recent

Chandhok & Wenger           Standards Track                     [Page 1]

RFC 2919                        List-Id                       March 2001

Chandhok & Wenger Standards Track [Page 1]  RFC 2919 List-Id March 2001

   proposals like [RFC2369] have expanded the functionality that the MUA
   can provide by providing more information in each message sent by the
   mailing list distribution software.

proposals like [RFC2369] have expanded the functionality that the MUA can provide by providing more information in each message sent by the mailing list distribution software.

   Actually implementing such functionality in the MUA depends on the
   ability to accurately identify messages as belonging to a particular
   mailing list.  The problem then becomes what attribute or property to
   use to identify a mailing list.  The most likely candidate is the
   submission address of the mailing list itself.  Unfortunately, when
   the list server host, the list processing software, or the submission
   policy of the list changes the submission address itself can change.
   This causes great difficulty for automated processing and filtering.

Actually implementing such functionality in the MUA depends on the ability to accurately identify messages as belonging to a particular mailing list. The problem then becomes what attribute or property to use to identify a mailing list. The most likely candidate is the submission address of the mailing list itself. Unfortunately, when the list server host, the list processing software, or the submission policy of the list changes the submission address itself can change. This causes great difficulty for automated processing and filtering.

   In order to further automate (and make more accurate) the processing
   a software agent can do, there needs to be some unique identifier to
   use as an identifier for the mailing list.  This identifier can be
   simply used for string matching in a filter, or it can be used in
   more sophisticated systems to uniquely identify messages as belonging
   to a particular mailing list independent of the particular host
   delivering the actual messages.  This identifier can also act as a
   key into a database of mailing lists.

In order to further automate (and make more accurate) the processing a software agent can do, there needs to be some unique identifier to use as an identifier for the mailing list. This identifier can be simply used for string matching in a filter, or it can be used in more sophisticated systems to uniquely identify messages as belonging to a particular mailing list independent of the particular host delivering the actual messages. This identifier can also act as a key into a database of mailing lists.

   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.

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.

2. The List Identifier Syntax

2. The List Identifier Syntax

   The list identifier will, in most cases, appear like a host name in a
   domain of the list owner.  In other words, the domain name system is
   used to delegate namespace authority for list identifiers just as it
   has been used to distribute that authority for other internet
   resources.

The list identifier will, in most cases, appear like a host name in a domain of the list owner. In other words, the domain name system is used to delegate namespace authority for list identifiers just as it has been used to distribute that authority for other internet resources.

   Using the domain name system as a basis for the list identifier
   namespace is intended to leverage an existing authority structure
   into a new area of application.  By using the domain name system to
   delegate list identifier namespace authority, it becomes instantly
   clear who has the right to create a particular list identifier, and
   separates the list identifier from any particular delivery host or
   mechanism.  Only the rights-holder of a domain or subdomain has the
   authority to create list identifiers in the namespace of that domain.
   For example, only the rights-holder to the "acm.org" domain has the
   authority to create list identifiers in "acm.org" domain.

Using the domain name system as a basis for the list identifier namespace is intended to leverage an existing authority structure into a new area of application. By using the domain name system to delegate list identifier namespace authority, it becomes instantly clear who has the right to create a particular list identifier, and separates the list identifier from any particular delivery host or mechanism. Only the rights-holder of a domain or subdomain has the authority to create list identifiers in the namespace of that domain. For example, only the rights-holder to the "acm.org" domain has the authority to create list identifiers in "acm.org" domain.

Chandhok & Wenger           Standards Track                     [Page 2]

RFC 2919                        List-Id                       March 2001

Chandhok & Wenger Standards Track [Page 2]  RFC 2919 List-Id March 2001

   While it is perfectly acceptable for a list identifier to be
   completely independent of the domain name of the host machine
   servicing the mailing list, the owner of a mailing list MUST NOT
   generate list identifiers in any domain namespace for which they do
   not have authority.  For example, a mailing list hosting service may
   choose to assign list identifiers in their own domain based
   namespace, or they may allow their clients (the list owners) to
   provide list identifiers in a namespace for which the owner has
   authority.

While it is perfectly acceptable for a list identifier to be completely independent of the domain name of the host machine servicing the mailing list, the owner of a mailing list MUST NOT generate list identifiers in any domain namespace for which they do not have authority. For example, a mailing list hosting service may choose to assign list identifiers in their own domain based namespace, or they may allow their clients (the list owners) to provide list identifiers in a namespace for which the owner has authority.

   If the owner of the list does not have the authority to create a list
   identifier in a domain-based namespace, they may create unmanaged
   list identifiers in the special unmanaged domain "localhost".  This
   would apply to personal users, or users unable to afford domain name
   registration fees.

If the owner of the list does not have the authority to create a list identifier in a domain-based namespace, they may create unmanaged list identifiers in the special unmanaged domain "localhost". This would apply to personal users, or users unable to afford domain name registration fees.

   The syntax for a list identifier in ABNF [RFC2234] follows:

The syntax for a list identifier in ABNF [RFC2234] follows:

   list-id = list-label "." list-id-namespace

list-id = list-label "." list-id-namespace

   list-label = dot-atom-text

list-label = dot-atom-text

   list-id-namespace = domain-name / unmanaged-list-id-namespace

list-id-namespace = domain-name / unmanaged-list-id-namespace

   unmanaged-list-id-namespace    = "localhost"

unmanaged-list-id-namespace = "localhost"

   domain-name = dot-atom-text

domain-name = dot-atom-text

   Where:

Where:

       dot-atom-text is defined in [DRUMS]

dot-atom-text is defined in [DRUMS]

       "localhost" is a reserved domain name is defined in [RFC2606]

"localhost" is a reserved domain name is defined in [RFC2606]

   In addition, a list identifier (list-id) MUST NOT be longer than 255
   octets in length, for future compatibility.  It should be noted that
   "localhost" is not valid for the domain-name rule.

In addition, a list identifier (list-id) MUST NOT be longer than 255 octets in length, for future compatibility. It should be noted that "localhost" is not valid for the domain-name rule.

3. The List-Id Header Field

3. The List-Id Header Field

   This document presents a header field which will provide an
   identifier for an e-mail distribution list.  This header SHOULD be
   included on all messages distributed by the list (including command
   responses to individual users), and on other messages where the
   message clearly applies to this particular distinct list.  There MUST
   be no more than one of each field present in any given message.

This document presents a header field which will provide an identifier for an e-mail distribution list. This header SHOULD be included on all messages distributed by the list (including command responses to individual users), and on other messages where the message clearly applies to this particular distinct list. There MUST be no more than one of each field present in any given message.

Chandhok & Wenger           Standards Track                     [Page 3]

RFC 2919                        List-Id                       March 2001

Chandhok & Wenger Standards Track [Page 3]  RFC 2919 List-Id March 2001

   This field MUST only be generated by mailing list software, not end
   users.

This field MUST only be generated by mailing list software, not end users.

   The contents of the List-Id header mostly consist of angle-bracket
   ('<', '>') enclosed identifier, with internal whitespace being
   ignored.  MTAs MUST NOT insert whitespace within the brackets, but
   client applications should treat any such whitespace, that might be
   inserted by poorly behaved MTAs, as characters to ignore.

The contents of the List-Id header mostly consist of angle-bracket ('<', '>') enclosed identifier, with internal whitespace being ignored. MTAs MUST NOT insert whitespace within the brackets, but client applications should treat any such whitespace, that might be inserted by poorly behaved MTAs, as characters to ignore.

   The list header fields are subject to the encoding and character
   restrictions for mail headers as described in [RFC822].

The list header fields are subject to the encoding and character restrictions for mail headers as described in [RFC822].

   The List-Id header MAY optionally include a description by including
   it as a "phrase" [DRUMS] before the angle-bracketed list identifier.
   The MUA MAY choose to use this description in its user interface;
   however, any MUA that intends to make use of the description should
   be prepared to properly parse and decode any encoded strings or other
   legal phrase components.  For many MUAs the parsing of the List-Id
   header will simply consist of extracting the list identifier from
   between the delimiting angle brackets.

The List-Id header MAY optionally include a description by including it as a "phrase" [DRUMS] before the angle-bracketed list identifier. The MUA MAY choose to use this description in its user interface; however, any MUA that intends to make use of the description should be prepared to properly parse and decode any encoded strings or other legal phrase components. For many MUAs the parsing of the List-Id header will simply consist of extracting the list identifier from between the delimiting angle brackets.

   The syntax of the List-Id header follows:

The syntax of the List-Id header follows:

   list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF

list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF

   where phrase and CRLF are as defined in [DRUMS].  Unlike most headers
   in [RFC822], the List-Id header does not allow free insertion of
   whitespace and comments around tokens.  Any descriptive text must be
   presented in the optional phrase component of the header.

where phrase and CRLF are as defined in [DRUMS]. Unlike most headers in [RFC822], the List-Id header does not allow free insertion of whitespace and comments around tokens. Any descriptive text must be presented in the optional phrase component of the header.

   Examples:

Examples:

List-Id: List Header Mailing List <list-header.nisto.com>
List-Id: <commonspace-users.list-id.within.com>
List-Id: "Lena's Personal Joke List"
         <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost>
List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu>
List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.localhost>

List-Id: List Header Mailing List <list-header.nisto.com> List-Id: <commonspace-users.list-id.within.com> List-Id: "Lena's Personal Joke List" <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu> List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.localhost>

4. Persistence of List Identifiers

4. Persistence of List Identifiers

   Although the list identifier MAY be changed by the mailing list
   administrator this is not desirable.  (Note that there is no
   disadvantage to changing the description portion of the List-Id
   header.)  A MUA may not recognize the change to the list identifier
   because the MUA SHOULD treat a different list identifier as a
   different list.  As such the mailing list administrator SHOULD avoid
   changing the list identifier even when the host serving the list

Although the list identifier MAY be changed by the mailing list administrator this is not desirable. (Note that there is no disadvantage to changing the description portion of the List-Id header.) A MUA may not recognize the change to the list identifier because the MUA SHOULD treat a different list identifier as a different list. As such the mailing list administrator SHOULD avoid changing the list identifier even when the host serving the list

Chandhok & Wenger           Standards Track                     [Page 4]

RFC 2919                        List-Id                       March 2001

Chandhok & Wenger Standards Track [Page 4]  RFC 2919 List-Id March 2001

   changes.  On the other hand, transitioning from an informal
   unmanaged-list-id-namespace to a domain namespace is an acceptable
   reason to change the list identifier.  Also if the focus of the list
   changes sufficiently the administrator may wish to retire the
   previous list and its associated identifier to start a new list
   reflecting the new focus.

changes. On the other hand, transitioning from an informal unmanaged-list-id-namespace to a domain namespace is an acceptable reason to change the list identifier. Also if the focus of the list changes sufficiently the administrator may wish to retire the previous list and its associated identifier to start a new list reflecting the new focus.

5. Uniqueness of List Identifiers

5. Uniqueness of List Identifiers

   This proposal seeks to leverage the existing administrative process
   already in place for domain name allocation.  In particular, we
   exploit the fact that domain name ownership creates a namespace that
   by definition can be used to create unique identifiers within the
   domain.

This proposal seeks to leverage the existing administrative process already in place for domain name allocation. In particular, we exploit the fact that domain name ownership creates a namespace that by definition can be used to create unique identifiers within the domain.

   In addition, there must be a mechanism for identification of mailing
   lists that are administrated by some entity without administrative
   access to a domain.  In this case, general heuristics can be given to
   reduce the chance of collision, but it cannot be guaranteed.  If a
   list owner requires a guarantee, they are free to register a domain
   name under their control.

In addition, there must be a mechanism for identification of mailing lists that are administrated by some entity without administrative access to a domain. In this case, general heuristics can be given to reduce the chance of collision, but it cannot be guaranteed. If a list owner requires a guarantee, they are free to register a domain name under their control.

   It is suggested, but not required, that list identifiers be created
   under a subdomain of "list-id" within any given domain.  This can
   help to reduce internal conflicts between the administrators of the
   subdomains of large organizations.  For example, list identifiers at
   "within.com" are generated in the subdomain of "list-id.within.com".

It is suggested, but not required, that list identifiers be created under a subdomain of "list-id" within any given domain. This can help to reduce internal conflicts between the administrators of the subdomains of large organizations. For example, list identifiers at "within.com" are generated in the subdomain of "list-id.within.com".

   List-IDs not ending with ".localhost" MUST be globally unique in
   reference to all other mailing lists.

List-IDs not ending with ".localhost" MUST be globally unique in reference to all other mailing lists.

   List owners wishing to use the special "localhost" namespace for
   their list identifier SHOULD use the month and year (in the form
   MMYYYY) that they create the list identifier as a "subdomain" of the
   "localhost" namespace.  In addition, some portion of the list
   identifier MUST be a randomly generated string.  List owners
   generating such identifiers should refer to [MSGID] for further
   suggestions on generating a unique identifier, and [RFC1750] for
   suggestions on generating random numbers.  In particular, list
   identifiers that have a random component SHOULD contain a hex
   encoding of 128 bits of randomness (resulting in 32 hex characters)
   as part of the list identifier

List owners wishing to use the special "localhost" namespace for their list identifier SHOULD use the month and year (in the form MMYYYY) that they create the list identifier as a "subdomain" of the "localhost" namespace. In addition, some portion of the list identifier MUST be a randomly generated string. List owners generating such identifiers should refer to [MSGID] for further suggestions on generating a unique identifier, and [RFC1750] for suggestions on generating random numbers. In particular, list identifiers that have a random component SHOULD contain a hex encoding of 128 bits of randomness (resulting in 32 hex characters) as part of the list identifier

   Thus, list identifiers such as
   <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> and
   <da39efc25c530ad145d41b86f7420c3b.051998.localhost> conform to these
   guidelines, while <lenas-jokes.021999.localhost> and

Thus, list identifiers such as <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> and <da39efc25c530ad145d41b86f7420c3b.051998.localhost> conform to these guidelines, while <lenas-jokes.021999.localhost> and

Chandhok & Wenger           Standards Track                     [Page 5]

RFC 2919                        List-Id                       March 2001

Chandhok & Wenger Standards Track [Page 5]  RFC 2919 List-Id March 2001

   <mylist.localhost> do not.  A particular list owner with several
   lists MAY choose to use the same random number subdomain when
   generating list identifiers for each of the lists.

<mylist.localhost> do not. A particular list owner with several lists MAY choose to use the same random number subdomain when generating list identifiers for each of the lists.

   List-IDs ending with ".localhost" are not guaranteed to be globally
   unique.

List-IDs ending with ".localhost" are not guaranteed to be globally unique.

6. Operations on List Identifiers

6. Operations on List Identifiers

   There is only one operation defined for list identifiers, that of
   case insensitive equality (See Section 3.4.7., CASE INDEPENDENCE
   [RFC822]).  The sole use of a list identifier is to identify a
   mailing list, and the sole use of the List-Id header is to mark a
   particular message as belonging to that list.  The comparison
   operation MUST ignore any part of the List-Id header outside of the
   angle brackets, the MUA MAY choose to inform the user if the
   descriptive name of a mailing list changes.

There is only one operation defined for list identifiers, that of case insensitive equality (See Section 3.4.7., CASE INDEPENDENCE [RFC822]). The sole use of a list identifier is to identify a mailing list, and the sole use of the List-Id header is to mark a particular message as belonging to that list. The comparison operation MUST ignore any part of the List-Id header outside of the angle brackets, the MUA MAY choose to inform the user if the descriptive name of a mailing list changes.

7. Supporting Nested Lists

7. Supporting Nested Lists

   A list that is a sublist for another list in a nested mailing list
   hierarchy MUST NOT modify the List-Id header field; however, this
   will only be possible when the nested mailing list is aware of the
   relationship between it and its "parent" mailing lists.  If a mailing
   list processor encounters a List-Id header field from any unexpected
   source it SHOULD NOT pass it through to the list.  This implies that
   mailing list processors may have to be updated to properly support
   List-Ids for nested lists.

A list that is a sublist for another list in a nested mailing list hierarchy MUST NOT modify the List-Id header field; however, this will only be possible when the nested mailing list is aware of the relationship between it and its "parent" mailing lists. If a mailing list processor encounters a List-Id header field from any unexpected source it SHOULD NOT pass it through to the list. This implies that mailing list processors may have to be updated to properly support List-Ids for nested lists.

8. Security Considerations

8. Security Considerations

   There are very few new security concerns generated with this
   proposal.  Message headers are an existing standard, designed to
   easily accommodate new types.  There may be concern with headers
   being forged, but this problem is inherent in Internet e-mail, not
   specific to the header described in this document.  Further, the
   implications are relatively harmless.

There are very few new security concerns generated with this proposal. Message headers are an existing standard, designed to easily accommodate new types. There may be concern with headers being forged, but this problem is inherent in Internet e-mail, not specific to the header described in this document. Further, the implications are relatively harmless.

   As mentioned above, mail list processors SHOULD NOT allow any user-
   originated List-Id fields to pass through to their lists, lest they
   confuse the user and have the potential to create security problems.

As mentioned above, mail list processors SHOULD NOT allow any user- originated List-Id fields to pass through to their lists, lest they confuse the user and have the potential to create security problems.

   On the client side, a forged list identifier may break automated
   processing.  The list identifier (in its current form) SHOULD NOT be
   used as an indication of the authenticity of the message.

On the client side, a forged list identifier may break automated processing. The list identifier (in its current form) SHOULD NOT be used as an indication of the authenticity of the message.

Chandhok & Wenger           Standards Track                     [Page 6]

RFC 2919                        List-Id                       March 2001

Chandhok & Wenger Standards Track [Page 6]  RFC 2919 List-Id March 2001

9. Acknowledgements

9. Acknowledgements

   The numerous participants of the List-Header [LISTHEADER] and
   ListMom-Talk [LISTMOM] mailing lists contributed much to the
   formation and structure of this document.

The numerous participants of the List-Header [LISTHEADER] and ListMom-Talk [LISTMOM] mailing lists contributed much to the formation and structure of this document.

   Grant Neufeld <grant@acm.org> focused much of the early discussion,
   and thus was essential in the creation of this document.

Grant Neufeld <grant@acm.org> focused much of the early discussion, and thus was essential in the creation of this document.

References

References

   [LISTHEADER] "List-Header" Mail list. list-header@list.nisto.com
                <http://www.nisto.com/listspec/mail/>
                <http://www.nisto.com/listspec/>

[LISTHEADER] "List-Header" Mail list. list-header@list.nisto.com <http://www.nisto.com/listspec/mail/> <http://www.nisto.com/listspec/>

   [LISTMOM]    "ListMom-Talk" Mail list. listmom-talk@skyweyr.com
                <http://cgi.skyweyr.com/ListMom.Home>

[LISTMOM] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com <http://cgi.skyweyr.com/ListMom.Home>

   [MSGID]      J. Zawinski, M. Curtin, "Recommendations for generating
                Message IDs", Work in Progress.

[MSGID] J. Zawinski, M. Curtin, "Recommendations for generating Message IDs", Work in Progress.

   [RFC822]     Crocker, D., "Standard for the Format of ARPA Internet
                Text Messages", RFC 822, August 1982.

[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982.

   [RFC1750]    Eastlake, D., Crocker S. and J. Schiller, "Randomness
                Recommendations for Security", RFC 1750, December 1994.

[RFC1750] Eastlake, D., Crocker S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.

   [RFC2234]    Crocker, D. and P. Overell. "Augmented BNF for Syntax
                Specifications: ABNF", RFC 2234, November 1997.

[RFC2234] Crocker, D. and P. Overell. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

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

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

   [RFC2606]    Eastlake, 3rd, D., and S. Panitz. "Reserved Top Level
                DNS Names", BCP 32, RFC 2606, June 1999.

[RFC2606] Eastlake, 3rd, D., and S. Panitz. "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.

   [RFC2822]    Resnick, P., Editor, "Internet Message Format Standard",
                STD 11, RFC 2822, March 2001.

[RFC2822] Resnick, P., Editor, "Internet Message Format Standard", STD 11, RFC 2822, March 2001.

Chandhok & Wenger           Standards Track                     [Page 7]

RFC 2919                        List-Id                       March 2001

Chandhok & Wenger Standards Track [Page 7]  RFC 2919 List-Id March 2001

Authors' Addresses

Authors' Addresses

   Ravinder Chandhok
   QUALCOMM, Inc.
   5775 Morehouse Drive
   San Diego, CA 92121 USA

Ravinder Chandhok QUALCOMM, Inc. 5775 Morehouse Drive San Diego, CA 92121 USA

   EMail: chandhok@qualcomm.com

EMail: chandhok@qualcomm.com

   Geoffrey Wenger
   QUALCOMM, Inc.
   5775 Morehouse Drive
   San Diego, CA 92121 USA

Geoffrey Wenger QUALCOMM, Inc. 5775 Morehouse Drive San Diego, CA 92121 USA

   EMail: gwenger@qualcomm.com

EMail: gwenger@qualcomm.com

Chandhok & Wenger           Standards Track                     [Page 8]

RFC 2919                        List-Id                       March 2001

Chandhok & Wenger Standards Track [Page 8]  RFC 2919 List-Id March 2001

Full Copyright Statement

Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright (C) The Internet Society (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgement

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Funding for the RFC Editor function is currently provided by the Internet Society.

Chandhok & Wenger           Standards Track                     [Page 9]

Chandhok & Wenger Standards Track [Page 9]