wdiff draft-chandhok-listid-03.txt draft-chandhok-listid-04.txt

INTERNET-DRAFT Ravinder Chandhok
draft-chandhok-listid-03.txt Geoffrey Wenger
Expires: May 24, 1999 Within Technology, Inc.
November 24, 1998
A new Request for Comments is now available in online RFC libraries.

RFC 2919

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

Status of this Memo

This document is an Internet-Draft. 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.''

To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast).

Abstract
Author(s): R. Chandhok, G. Wenger
Status: Standards Track
Date: March 2001
Mailbox: chandhok@within.com, wenger@within.com
Pages: 9
Characters: 18480
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-chandhok-listid-04.txt

URL: ftp://ftp.rfc-editor.org/in-notes/rfc2919.txt

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

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.

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.

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

In order to further automate (and make more accurate) the
processing is now a software agent can do, there needs to be some
unique identifier to use as Proposed Standard Protocol.

This document specifies an identifier Internet standards track protocol for
the mailing list.
This identifier can be simply used Internet community, and requests discussion and suggestions
for string matching in a
filter, or it can be used in more sophisticated systems to
uniquely identify messages as belonging improvements. Please refer to a particular mailing
list independent the current edition of the particular host delivering
"Internet Official Protocol Standards" (STD 1) for the actual
messages. This identifier can also act as a key into a database
standardization state and status of mailing lists.

2. The List Identifier Syntax

The list identifer will, in most cases, appear like a host name
in a domain this protocol. Distribution
of the list owner. In other words, the domain name
system this memo 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 unlimited.

This announcement is intended sent to leverage an existing authority
structure into a new area of application. By using the domain
name system to delegate IETF 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.

While it is perfectly acceptable for a list identifier RFC-DIST list.
Requests 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 added 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 deleted from 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:

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

list-label = dot-atom-text

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

unmanaged-list-id-namespace = "localhost"

domain-name = dot-atom-text

Where:

dot-atom-text is defined in [DRUMS]

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

In addition, a list identifier (list-id) MUST NOT be longer than
255 octets in length, for future compatibility.

3. The List-Id Header Field

This document presents a header field which will provide an
identifier for an e-mail IETF 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 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 list header fields are subject sent 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 "quoted-string" [DRUMS] before the
angle-bracketed list identifier. The MUA MAY choose IETF-REQUEST@IETF.ORG. Requests to use
this description in its user interface.

The syntax of the List-Id header follows:

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

where quoted-string and CRLF are as defined in [DRUMS].

Examples:

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

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
added 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 changes. On the other hand,
transitioning or deleted from an informal unmanaged-list-id-namespace to a
domain namespace is an acceptable reason to change the RFC-DIST distribution 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

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 should
be used sent to create
unique identifiers within the domain.

In addition, there must RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be a mechanism for identification of
mailing lists that are administrated obtained 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 sending
an EMAIL message to register a domain name under their control.

List-IDs not ending rfc-info@RFC-EDITOR.ORG with ".localhost" MUST be globally unique
in reference to all other mailing lists.

List owners wishing to use the special "localhost" namespace message body
help: ways_to_get_rfcs. For example:

To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs

help: ways_to_get_rfcs

Requests 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 special distribution 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
<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.

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 addressed to identify a mailing list, and either the sole use
author 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

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

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 RFC in Internet
e-mail, not specific question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the header described in this document.
Further, the implications RFC itself, all RFCs 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.

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.

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.

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

References

[DRUMS] P. Resnick, Editor, "Internet Message Format Standard",
March 13 1998.
<ftp://ietf.org/internet-drafts/draft-ietf-drums-msg-fmt-05.txt>

[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>

[MSGID] J. Zawinski, M. Curtin, "Recommendations for generating
Message IDs", July 22 1998.
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-usefor-message-id-01.txt>

[RFC822] David H. Crocker, "Standard
unlimited distribution.echo
Submissions for the Format of ARPA
Internet Text Messages" RFC 822, August 1982.

[RFC1750] D. Eastlake, 3rd, S. Crocker & J. Schiller. "Randomness
Recommendations Requests for Security" Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 1750, December 1994.

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

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

[RTLDN] D. Eastlake, 3rd, S. Panitz. "Reserved Top Level DNS
Names", July 1998.
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-test-tlds-11.txt>

Authors' Addresses

Ravinder Chandhok
Within Technology, Inc.
RD#1 Box 228
Waynesburg PA 15370 USA
Email: chandhok@within.com
Web: http://www.within.com/~chandhok

Geoffrey Wenger
Within Technology, Inc.
RD#1 Box 228 Waynesburg
PA 15370 USA
Email: wenger@within.com
Web: http://www.within.com/~wenger

draft-chandhok-listid-03.txt
Expires: May 24, 1999 further information.