TOC |
|
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 20, 2002.
Copyright (C) The Internet Society (2001). All Rights Reserved.
1 This specification defines a form of URI to be used to identify email and MIME message headers, defined by RFC 2822 and related documents.
TOC |
TOC |
2 This specification defines a form of URI to be used to identify email and MIME message headers, defined by RFC 2822 [19] and related documents. The URI scheme used is 'urn:' as defined by RFC 2141 [11], and the URN namespace used is 'ietf', defined by RFC 2648 [18] and extended by RFC ???? [25] to include names for IETF protocol parameters.
3 RFC 2822 [19] defines a general syntax for Internet message headers. It also defines a number of headers to be used with Internet mail. Other specifications define additional headers that can appear in an Internet message: RFC 1036 [1], RFC 2156 [12], RFC 1496 [2], RFC 1766 [4], RFC 2183 [13], RFC 1864 [5], RFC 2421[15] and RFC 2045 [6], to name a few.
4 Internet message headers convey a range of message metadata information that can be useful to applications other than message transfer programs. Many programs are being developed to use XML [22] as their main data exchange format. Using XML namespace URIs [23] and a URI+local part concatenation convention introduced by RDF [24], each element- or attribute-name in an XML document can be identified with a URI.
5 A goal of this specification is to define a URI form for Intenet message headers that allows them to be incorporated into XML formatted data, as in "An XML format for mail and other messages" [26]. It also provides a URI form for use with non-XML specifications that employ the URI-based XML namespace extensibility model, such as the commpon profile for instant messaging format specification [27].
TOC |
6 The URN sub-namespace for message headers is defined as follows.
- Registry name:
- 7 rfc822
- Specification:
- 8 RFC 2822 [16].
- Repository:
- 9 The primary definition of Internet message headers is RFC 2822 [16]. Currently, there is no IANA registry for Internet message headers, and additional header names are defined in a variety of standards-track RFC documents, including: RFC 1036 [1], RFC 1496 [2], RFC 1505 [3], RFC 1766 [4], RFC 1864 [5], RFC 2156 [12], RFC 2183 [13], RFC 2045 [6], RFC 2110 [8], RFC 2298 [9], RFC 2369 [10], RFC 2421 [15], RFC 2912 [20] and RFC 2919 [21].
A summary of defined message headers can be found in RFC 2076 [7], and updates [28].- Index value:
- 10 The header name is the index value. RFC 2822 allows a header name to contain any printable, non-space US-ASCII character (i.e., characters that have US-ASCII codes between 33 and 126, inclusive), except colon (":"). Header names are case-insensitive.
- URN formation:
- 11 The URN for a media feature tag is formed as: "urn:ietf:params:rfc822:<header-name>", where <header-name> is the message header index value.
RFC 2141 [11] defines the format of URNs. Allowable characters include upper- or lower-case ASCII letters, decimal digits, "(", ")", "+", ",", "-", ".", ":", "=", "@", ";", "$", "_", "!", "*" and "'". Any other character that appears as part of a header name should be replaced by its %-encoded equivalent (per URI specification [14]); e.g. '%' is represented as '%25', and '/' as '%2f'.
URNs are defined by RFC 2141 [11] as lexically equivalent if they are identical following case normalization of the urn scheme name, the namespace name and any %-escaping used. Header names are defined such that upper- and lower-case ASCII characters are not distinguished. Thus, in forming a URN, all ASCII characters in the header name must be expressed in lower case.
TOC |
12 This table lists some header names, and the corresponding urn: URIs.
- From:
- 13 urn:ietf:params:rfc822:from
- To:
- 14 urn:ietf:params:rfc822:to
- X-=Envelope-From:
- 15 urn:ietf:params:rfc822:x-envelope-from
- Content-MD5:
- 16 urn:ietf:params:rfc822:content-md5
TOC |
17 This document calls for the creation of a new IETF sub-namespace, per RFC???? [25]. Registration details are in the preceding section.
TOC |
18 No security considerations are introduced by the specification beyond those already inherrent in use of media feature tags.
TOC |
TOC |
Graham Klyne | |
MIMEsweeper Group | |
1310 Waterside | |
Arlington Business Park | |
Theale, Reading RG7 4SA | |
UK | |
Phone: | +44 118 903 8000 |
Fax: | +44 118 903 9000 |
EMail: | Graham.Klyne@MIMEsweeper.com |
TOC |
56 (This section to be removed on final publication)
57
- 00a
- 58 19-Sep-2001: document initially created.
TOC |
59 (This section to be removed on final publication)
TOC |
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.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.