[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

Network working group              G. Klyne, Content Technologies Ltd.
Internet draft                                         18 October 2000
                                                   Expires: April 2001

                    XML coding of RFC822 messages

Status of this memo

  This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 of RFC 2026.

  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-

  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

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

Copyright Notice

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


  This document describes a coding of RFC822 messages using XML.

Discussion of this document

  Please send comments to:  <IMXPwg@lists.invisibleworlds.com>.

  To subscribe:  send a message with the body 'subscribe' to

Klyne                       Internet draft                    [Page 1]

XML coding of RFC822 messages                          18 October 2000

Table of contents

1. Introduction.............................................3
  1.1 Structure of this document ...........................3
  1.2 Document terminology and conventions .................4
  1.3 About MIME and XML ...................................5
2. Message structures.......................................6
  2.1 Message header overview ..............................6
  2.2 Multipart/related message structure ..................7
  2.3 Inline XML message structure .........................8
  2.4 Content type Message/RFC822+XML ......................8
3. Message header...........................................9
  3.1 The <message> element ................................9
  3.2 Content of <message> element .........................10
  3.3 Use of XML namespaces ................................10
  3.4 The <message-content> element ........................10
  3.5 General form of header field elements ................11
  3.6 RFC822 header fields .................................11
  3.7 Header fields containing addresses ...................12
  3.8 Header fields containing human readable text .........13
  3.9 MIME header fields ...................................13
  3.10 Other header fields .................................14
     3.10.1 Mandatory extensions............................14
4. Conversion to and from RFC822 format.....................15
5. IANA considerations......................................15
6. Internationalization considerations......................16
  6.1 International URIs in XML ............................16
7. Security considerations..................................17
8. Acknowledgements.........................................17
9. References...............................................17
10. Author's address........................................21
Appendix A: Message/RFC822+XML content-type registration....21
Appendix B: DTD for RFC822 message format...................21
Appendix C: XML schema for RFC822 message format............21
Appendix D: Amendment history...............................22
Full copyright statement....................................22

Klyne                       Internet draft                    [Page 2]

XML coding of RFC822 messages                          18 October 2000

1. Introduction

  This document describes a coding of RFC822 messages [1] using XML
  [2], described here as the RFC822+XML message format.

  The coding is designed to address the following goals:

  o  to fully capture the semantics of RFC822 [1].

  o  to extend the scope of address information that can be conveyed
     to arbitrary URIs [3].

  o  to take account of 8-bit clean transfer environments.

  o  to fully support, where applicable, international character sets
     and languages within the message header and content [4] [5].

  o  to be usable in MIME [6] and pure XML [2] transfer environments.

  o  to support easy conversion to and from RFC822 message format [1]
     (for messages that follow RFC822 constraints).

  o  to be fully compliant with the XML [2] and XML namespace [9]

  o  to allow header information to be easily mapped to RDF format
     [10] for generalized metadata processing.

  This specification has been prepared with a view to using the
  relevant elements of RFC822 message structures with instant
  messaging systems, proposals for which use XML syntax for
  structured information.

1.1 Structure of this document

  Section 2 describes the overall message structure, showing how the
  message header and message content can be conveyed in MIME and XML
  transfer environments.

  Section 3 describes the message header in greater detail, with
  particular reference to differences in the value of individual
  fields compared their RFC822 counterparts.

  Section 4 discusses issues that may arise when converting between
  traditional RFC822 and the RFC822+XML message format described

Klyne                       Internet draft                    [Page 3]

XML coding of RFC822 messages                          18 October 2000

  Appendix A contains a MIME content-type registration for

  Appendix B contains a DTD for the RFC822+XML message format.

  Appendix C contains an XML schema for the RFC822+XML message
  format.  (XML schema are set to replace DTDs are the prferred way
  to describe XML docoment content.)

1.2 Document terminology and conventions

  Message   an assemblage of information that constitutes a
            communication of information from a ssender to one or
            more recipients.  Consists of a message header and
            message content.

  Message header
            contains information about the message that is conveyed
            between message user agents, and not used by the message
            transfer mechanisms.  This may include who the message is
            from, who it is addressed to, other parties to whom it
            has been copied, subject of the message, date the message
            was composed, etc.

  Message content
            some arbitrary data carried in a message.

            is the message format defined by this document.  (The
            name derives from the XML content type labelling
            convention [11].)

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  this document are to be interpreted as described in RFC 2119 [19].

       NOTE:  Comments like this provide additional nonessential
       information about the rationale behind this document.
       Such information is not needed for building a conformant
       implementation, but may help those who wish to understand
       the design in greater depth.

  [[[Editorial comments and questions about outstanding issues are
  provided in triple brackets like this.  These working comments
  should be resolved and removed prior to final publication.]]]

Klyne                       Internet draft                    [Page 4]

XML coding of RFC822 messages                          18 October 2000

1.3 About MIME and XML

  There has been much discussion about the relative merits of MIME
  and XML.  The position of this document is that they serve
  different purposes, and are complementary rather than alternatives.

  MIME is a framework primarily for encapsulating and composing
  arbitrary data entities, and offers the following capabilities:

  o  Content type labelling.

  o  Transfer encoding for handling arbitrary data on restricted

  o  Assembly of different kinds of data into composite entities.

  o  End of data detection without need to parse or understand the
     data content.

  XML is a framework primarily for describing data structures,
  including semi-structured document data, and offers the following

  o  Construction of arbitrary data structures based on an annotated
     tree model.

  o  Fine-grained labelling of structure components and data

  o  Cross-linking between data structure components.

  o  A standard format for interchange of structured information
     between diverse systems.

  There is, of course, some overlap in capabilities, and reasonable
  people may disagree about the appropriateness of using MIME and/or
  XML in particular circumstances.

  This document is predicated on the idea that XML is a useful
  mechanism (in addition to existing facilities) for structuring
  message header information.  It aims to be agnostic with regard to
  using MIME or some other framework for composing and encapsulating

Klyne                       Internet draft                    [Page 5]

XML coding of RFC822 messages                          18 October 2000

2. Message structures

  A message consists of a message header and message content:

  o  The message header contains information about the message:  who
     it was sent by, who it is addressed to, its subject, date it was
     sent, and many other related pieces of information.

  o  The message content is any data that is carried by the message:
     e.g. a text message, fax image, voice message or arbitrary
     application data.  In principle, any data that can be transfered
     as a MIME object can be message content, though specific
     applications may limit the kinds of data that can be transferred.

  The RFC822+XML message format uses a URI-reference [3] in the
  message header to reference the message content.  Thus, the message
  content MAY be conveyed completely separately from the message
  header;  the message header is the root information of a message.

  Two specific message structure scenarios are contemplated here:

  o  Multipart/related, and

  o  An XML element within the message header.

  These are described below.  Other message structures are possible
  (e.g. multiple channels in a multiplexed protocol), but are not
  described here.

2.1 Message header overview

  The message header is an XML document whose root element is
  <Message>.  This contains a number of elements that correspond to
  RFC822 message headers.

  The message content is indicated by an attribute of the <Message>
  element whose value is a URI for the content.

  The message header is discussed in greater detail in section 3

Klyne                       Internet draft                    [Page 6]

XML coding of RFC822 messages                          18 October 2000

2.2 Multipart/related message structure

  A message whose content is formatted as a MIME object [6] may be
  sent as a Multipart/related object [15]:

     Content-type: Multipart/related
     Content-Type: multipart/related; boundary="boundary";

     Content-Type: Message/RFC822+XML
     Content-ID: <1@100Aker.org>

       <rfc822:subject>Woozle Hunting</rfc822:subject>
     Content-Type: text/plain;charset=UTF-8
     Content-ID: <2@100Aker.org>

     I have Been Foolish and Deluded
     I am a Bear of No Brain at All

  In this case, the Multipart/related contains two MIME parts:

  o  the message header, and

  o  the message content.

  The Multipart/related content-type header indicates the root of the
  message by its Content-ID value [6].  In turn, the message header
  refers to the message content with a <message> element 'content='
  attribute whose value is a 'cid:' URI [16].

Klyne                       Internet draft                    [Page 7]

XML coding of RFC822 messages                          18 October 2000

2.3 Inline XML message structure

  When the message content can be expressed as simple text or XML, it
  may be included within the message header using a <message-content>

     Content-Type: Message/RFC822+XML

       <rfc822:subject>Re: Woozle hunting</rfc822:subject>
       <rfc822:message-content name='message-text' type='text/plain'>
         You're the Best Bear in All the World

  This example shows the message contained within a single
  Message/RFC822+XML MIME object.

  The <message> element 'content=' attribute that references the
  message is a lone URI fragment identifier [3] [17], indicating a
  named element within the current XML entity.

  The <message-content> element contains the message content.  When
  present, this element MUST be the last element contained in a
  <message> element.

  The 'name=' attribute of the <message-content> element names the
  content, so that it can be referenced from the <message> element.
  (In the DTD/schema for the RFC822+XML message format, this 'name='
  attribute is declared as having an attribute type of 'ID' [2],
  meaning that it identifies the contained element.  The XML pointer
  specification (section 2.1.2) defines an XML document fragement
  identifier as indicating an element thus named.

2.4 Content type Message/RFC822+XML

  This specification defines a new MIME content-type called

  A Message/RFC822+XML entity contains an XML document conforming to
  the DTD known by the SYSTEM identifier 'URN:IANA:DOCTYPE:RFC822'.
  The document may contain <?XML?> and <!DOCTYPE> declarations, but
  these are not required.

Klyne                       Internet draft                    [Page 8]

XML coding of RFC822 messages                          18 October 2000

  The body of the document is a <message> element, as described

  The character set encoding used in a Message/RFC822+XML entity is

  A Content-type registration template for Message/RFC822+XML is
  contained in Appendix A of this document.

3. Message header

  The RFC822+XML message header contains header fields based on
  RFC822, and coded in XML.

  The message header contains information about the message that is
  conveyed between message user agents, and not used by the message
  transfer mechanisms.  This may include who the message is from, who
  it is addressed to, other parties to whom it has been copied,
  subject of the message, date the message was composed, etc.

  The message header also contains a reference to the message
  content, as described in the previous section.

3.1 The <message> element

  The <message> element contains the message header, and references
  the message content.

  Possible attributes are:

  o  'xmlns=' or 'xmlns:tag=' is used to indicate a default XML
     namespace or XML namespace tag [9] that applies to the entire
     <message> element.

  o  'content=' specifies a URI-reference [3] that references the
     message content.  Typically, the value is a 'cid:' URI, or a
     fragment identifier, as described in the previous section.  Other
     message content URI values are possible, but such use is beyond
     the scope of this specification.

  o  'xml:lang=' [2] may be used, in which case it specifies the
     language of any text in the message header, except where
     overridden by an 'xml:lang=' attribute of an enclosed element.

Klyne                       Internet draft                    [Page 9]

XML coding of RFC822 messages                          18 October 2000

3.2 Content of <message> element

  The content of a <message> element is:

  o  a sequence of zero of more header field elements, and

  o  an optional <message-content> element.

  Header field elements may appear in any order.  When present, the
  <message-content> element MUST the last one in the <message>.

3.3 Use of XML namespaces

  The <message> element, RFC822 header field names and the <message-
  content> element name are associated with the namespace identified
  as 'URN:IANA:message:rfc822:'.  (This namespace identifier is based
  on [[[a work-in-progress]]] [20].)

  The namespace must be declared, either as a default namespace or as
  a namespace prefix (which is an arbitrary local name).  The
  namespace declaration may appear as an attribute of the <message>
  element, or in the surrounding XML context.

  The message examples in section 2 use a namespace prefix 'rfc822';
  any XML name could be used here.  Here is a different message
  example using a default namespace rather than a namespace prefix:

     Content-Type: Message/RFC822+XML

       <message-content name='message-text' type='text/plain'>
         Inasmuch as which?

  (Apart from the 'xmlns' attribute, this is very like basic XML
  without namespaces, and may be the preferred form for many

3.4 The <message-content> element

  The <message-content> element is used to include the message
  content as text or XML data in the message header.

Klyne                       Internet draft                   [Page 10]

XML coding of RFC822 messages                          18 October 2000

  Possible <message-content> attributes are:

  o  'name=' is required, and identifies the <message-content>
     element.  This value is used to define an XML fragment identifier
     for the element.

  o  'type=' is optional, and indicates the MIME content-type of the
     message content.  If not specified, a content type pof "text/xml"
     is assumed.

     (Whatever MIME content-type may be declared, the message content
     must be well-formed XML or character data.  In practice, this
     means the content must be some character-based data

  o  'xml:lang=' [2] may be used, in which case it specifies the
     language of the message content.

  The character encoding for the message content is the same as that
  used for the surrounding XML.  This is typically UTF-8, from the
  character set encoding of the MIME content-type

  The message content may be any well-formed XML, which includes
  simple character data.  Characters '<' and '&' that are not part of
  XML markup MUST be represented as '&lt; and '&amp;' respectively.
  The character '>' appearing in the sequence ']]>', other than at
  the end of a CDATA section, MUST be represented as '&gt;'.

3.5 General form of header field elements

  Each header field is represented by an XML element that identifies
  the field.

  The element content is the header field value.  For RFC822 and MIME
  header fields, the field value is character data in which the
  characters '<', '&' and '>' are represented as for character data
  in <message-content>.

3.6 RFC822 header fields

  RFC822 header field elements have names based on RFC822 header
  names, using all lower-case characters (noting that XML element
  names are case sensitive.)

Klyne                       Internet draft                   [Page 11]

XML coding of RFC822 messages                          18 October 2000

  RFC822 header field names are associated with an XML namespace, as
  noted above at section 3.3, and may need to be combined with a
  namespace prefix if it is not the default namespace.  (See examples
  in sections 2.2 and 2.3.)

  RFC822 header field contents are the same syntax and meaning as
  corresponding RFC822 header values, except that:

  o  Characters are not limited to US-ASCII.  UTF-8 character set
     encoding is typically used.

  o  Encoded words ('=?...?=') are not needed, and no special
     processing is defined for sequences of this form.

  o  Special considerations apply to fields containing address vales
     (from, to, etc.) -- see section below.

  o  Special considerations apply to fields containing human-readable
     text values (subject, comments, etc.) -- see section below.

3.7 Header fields containing addresses

  The biggest change from RFC822 header fields is that all addresses
  are presented as URIs, rather than as RFC822 'addr-spec' values.
  E-mail addresses (the only kind that appear in RFC822 headers) are
  expressed as 'mailto:' URLs [21].

  This change anticipates that XML-based message headers may be used
  with a variety of different protocols with different addressing

  Note that characters in URIs are drawn from a limited repertoire;
  the URI '%' escape sequence may be used to represent other
  characters that are legal for the URI scheme used [14].

  The RFC822 structures using 'group', 'phrase and 'route-addr' are
  supported.  Note that angle brackets surrounding a 'route-addr'
  must be escaped as '&lt;' and '&gt;'.

Klyne                       Internet draft                   [Page 12]

XML coding of RFC822 messages                          18 October 2000

  RFC822 'comment' values within address values are not supported.
  Thus, RFC822 e-mail addresses that might be expressed as:

     Piglet@TrespassersW.100Aker.org (MR SANDERS)

  must be presented in the form:

     MR SANDERS <mailto:Piglet@TrespassersW.100Aker.org>

  which is contained within an XML element as:

     MR SANDERS &lt;mailto:Piglet@TrespassersW.100Aker.org&gt;

3.8 Header fields containing human readable text

  Header fields that contain human readable text MAY have an
  'xml:lang=' attribute of the header element to indicate a language
  for the contained text.

3.9 MIME header fields

  MIME content header fields MAY be part of the message header, in
  addition to RFC822 message header fields, using the same general
  format as RFC822 header fields (i.e. element name based on the MIME
  header field name, and associated with the same XML namespace).

  But note that most MIME header fields are not appropriate for use
  with the RFC822+XML message format.  When the message content is
  supplied as a separate MIME entity then MIME content header fields
  SHOULD be applied to that entity.

  It is expected that MIME header fields may be useful in the
  following circumstances:

  o  When the message content is included as inline XML, to convey
     information about it that cannot be conveyed using native XML
     mechanisms;  e.g. the Content-features header [22].

  o  MIME headers, not having an obvious XML counterpart, that express
     information that might be taken as metadata applying to the
     message as a whole, in isolation from the specific message
     content;  e.g. the Content-description header field.

Klyne                       Internet draft                   [Page 13]

XML coding of RFC822 messages                          18 October 2000

3.10 Other header fields

  A message header MAY contain header fields that are not derived
  from RFC822 or MIME.  Any such header fields used MUST be
  associated with a different namespace.

  This specification does not define any such additional header

3.10.1 Mandatory extensions

  In general, a message handler should ignore any header fields that
  it does not understand -- it "sees no evil".

  But sometimes it is desirable to introduce new header fields that
  must be understood for proper processing of the message to take
  place.  This specification defines an XML attribute 'seeNoEvil='
  which indicates whether or not the element to which it applies must
  be understood by a message processor:

  seeNoEvil='true'    is the default case, and indicates that the
                      corresponding element MAY safely be ignored.

  seeNoEvil='false'   indicates that the element to which it applies
                      MUST be processed, OR processing of the entire
                      message (or message header) MUST be abandoned.

  In XML namespace terms [9], the 'seeNoEvil=' attribute belongs to a
  "per-element-type namespace partition".  Interpretation of the
  attribute is a property of the element to which it applies.  In any
  case, the DTD or XML schema must declare that the element is
  allowed on any particular XML element type.  It is strongly
  recommended that any header elements used within an RFC822+XML
  message header allow this attribute with the interpretation
  described here.

  Non-validating XML processors used to handle RFC822+XML message
  headers MAY interpret the 'seeNoEvil=' attribute appearing on any
  header field element as described here.

Klyne                       Internet draft                   [Page 14]

XML coding of RFC822 messages                          18 October 2000

4. Conversion to and from RFC822 format

  RFC822 fields treated as addresses:


  RFC822 fields treated as human-readable text:


  Other RFC822 fields:


5. IANA considerations

  This specification calls for the registration of the new MIME
  content-type Message/RFC822+XML.  The registration template is at
  appendix A.

  [[[XML document identifier -- URN from IANA space?]]]

  [[[XML namespace identifier -- URN from IANA space?]]]

  [[[Waiting on [20]...]]]

Klyne                       Internet draft                   [Page 15]

XML coding of RFC822 messages                          18 October 2000

6. Internationalization considerations

  This specification attempts to relax the restriction of
  international data imposed by RFC822.

  RFC822 limits characters in address local parts to US-ASCII.  This
  specification uses a URI-based address format and relaxes that
  constraint so that foreign language personal names can be
  represented.  Character restrictions apply to URIs, and the
  %-escape mechanism defined by RFC2396 must be followed for
  representing non-URI characters.  The character encoding used is
  dependent on the URI scheme, but UTF-8 is a popular choice.

  Similarly, the characters that can be used in domain names are
  currently severely constrained.  Work is under way to define
  international forms for domain names.

  Message content is tagged using standard MIME capabilities (charset
  parameter for text data [13], and Content-language header for
  language tagging [22]).  Mandating handling of international data
  formats is a matter for particular applications;  it is recommended
  that applications using the RFC822+XML message format be required
  to process UTF-8 coded character data.  That does not necessarily
  mean that all characters received can be displayed.

  For content included in an XML element, language tagging can be
  achieved by including an 'xml:lang=' attribute [16] in the
  <message-content> element (subject to appropriate DTD or XML schema
  permission to use that attribute).

6.1 International URIs in XML

  This sub-section is commentary, not part of this specification:

  In a message to the W3C URI mailing list
  (http://lists.w3.org/Archives/Public/uri/2000Oct/0008.html), Martin
  Duerst wrote:

     The original XML spec says (http://www.w3.org/TR/1998/REC-xml-

       An XML processor should handle a non-ASCII character in a URI
       by representing the character in UTF-8 as one or more bytes,
       and then escaping these bytes with the URI escaping mechanism
       (i.e., by converting each byte to %HH, where HH is the
       hexadecimal notation of the byte value).

Klyne                       Internet draft                   [Page 16]

XML coding of RFC822 messages                          18 October 2000

     This says that the XML processor should do this for you, and
     therefore it should be okay for you to put in the original
     characters. But there are three problems here:

     o It says 'should', not must.

     o It's not clear whether it applies to all URIs, or just to the
       URIs used in System Identifiers, and in the former case, it's
       not clear how an XML processor would find all URIs in a
       document (without e.g. Schema information).

     o The text in the second edition of XML
       (http://www.w3.org/TR/REC-xml#sec-external-ent) is much
       clearer about how the conversion has to take place;
       unfortunately, it doesn't make clear who should do this
       conversion (the original document producer or the XML
       processor). The idea was not to change this for the second
       edition, but somehow it got lost. I'm following up on this.

7. Security considerations

  This document for the most part describes an alternative coding of
  an existing message structure, and is not believed to introduce any
  new security exposure not already inherent in existing systems.

  MIME based messages may be protected using existing MIME security
  frameworks, such as S/MIME [12], OpenPGP [13], etc.

  Using a non-MIME, pure XML message format means that alternative
  security frameworks may be applicable, such as XML digital
  signatures [14].

8. Acknowledgements

  The author thanks the following for their contributions:  [[[...]]]

9. References

[1]  Crocker, D.,
     "Standard for the format of ARPA Internet text messages",
     RFC 822, STD 11,
     August 1982.

Klyne                       Internet draft                   [Page 17]

XML coding of RFC822 messages                          18 October 2000

[2]  Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen,
     "Extensible Markup Language (XML) 1.0",
     W3C recommendation: <http://www.w3.org/TR/REC-xml>,
     10 February 1998.

[3]  Berners-Lee, T., Fielding, R.T. and L. Masinter,
     "Uniform Resource Identifiers (URI): Generic Syntax",
     RFC 2396,
     August 1998.

[4]  Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson,
     R., Crispin, M., Svanberg, P.,
     "Report from the IAB Character Set Workshop",
     RFC 2130,
     April 1997.

     Alvestrand, H,
     "IETF Policy on Character Sets and Languages",
     RFC 2277, BCP 18,
     January 1998.

     Freed, N., and J. Postel,
     "IANA Charset Registration Procedures",
     BCP 19, RFC 2278,
     January 1998.

[[[Is there a more definitive reference?]]]

[5]  Alvestrand, H.,
     "Tags for the Identification of Languages",
     RFC 1766,
     March 1995.
     (Defines Content-language header.)

[6]  Freed, N. and N. Borenstein,
     "Multipurpose Internet Mail Extensions (MIME) Part One: Format of
     Internet Message Bodies",
     RFC 2045,
     November 1996.

[7]  Freed, N. and N. Borenstein,
     "Multipurpose Internet Mail Extensions (MIME) Part Two: Media
     RFC 2046
     November 1996.

Klyne                       Internet draft                   [Page 18]

XML coding of RFC822 messages                          18 October 2000

[8]  Freed, N., Klensin, J., and J. Postel,
     "Multipurpose Internet Mail Extensions (MIME) Part Four:
     Registration Procedures",
     RFC 2048, BCP 13,
     November 1996.

[9]  Tim Bray, Dave Hollander, and Andrew Layman
     "Namespaces in XML",
     W3C recommendation: <http://www.w3.org/TR/REC-xml-names>,
     14 January 1999.

[10] Lassila, O. and R. Swick,
     "Resource Description Framework (RDF) Model and Syntax
     W3C recommendation: <http://www.w3.org/TR/REC-rdf-syntax>,
     22 February 1999.

[11] Kohn, D., Murata, M. and S. St.Laurent,
     "XML Media Types",
     September 2000.
     (Introduces '+XML' content-type naming convention.)

[12] Ramsdell, B.,
     "S/MIME Version 3 Message Specification",
     RFC 2633,
     June 1999.

[13] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
     "OpenPGP Message Format",
     RFC 2440,
     November 1998.

[14] Eastlake, D., Reagle, J. and D. Solo,
     "XML-Signature Syntax and Processing",
     Work in progress: <draft-ietf-xmldsig-core-09.txt>,
     August 2000.

[15] Levinson, E.,
     "The MIME Multipart/Related Content-type",
     RFC 2387,
     August 1998.

[16] Levinson, E.,
     "Content-ID and Message-ID Uniform Resource Locators",
     RFC 2392,
     August 1998.

Klyne                       Internet draft                   [Page 19]

XML coding of RFC822 messages                          18 October 2000

[17] Daniel, R., DeRose, S. and E. Maler
     "XML Pointer Language (XPointer) Version 1.0",
     W3C Candidate Recommendation: <http://www.w3.org/TR/xptr>
     7 June 2000.

[18] Fallside, D.,
     "XML Schema Part 0: Primer",
     W3C Working Draft: <http://www.w3.org/TR/xmlschema-0/>,
     22 September 2000.

     Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn
     "XML Schema Part 1: Structures",
     W3C Working Draft: <http://www.w3.org/TR/xmlschema-1/>
     22 September 2000.

     Biron, P. and A. Malhotra,
     "XML Schema Part 2: Datatypes",
     W3C Working Draft: <http://www.w3.org/TR/xmlschema-2/>
     22 September 2000.

[19] Bradner, S.,
     "Key words for use in RFCs to Indicate Requirement Levels",
     RFC 2119,
     March 1997.

[20] Mealling, M.,
     [[[URN namespace for IANA registries]]],
     (work in progress),

[21] Hoffman, P., Masinter, L., and J. Zawinski,
     "The mailto URL scheme",
     RFC 2368,
     July 1998.

[22] Klyne, G.,
     "Indicating Media Features for MIME Content",
     RFC 2912,
     September 2000.

Klyne                       Internet draft                   [Page 20]

XML coding of RFC822 messages                          18 October 2000

10. Author's address

  Graham Klyne
  Content Technologies Ltd.
  1220 Parkview,
  Arlington Business Park
  Reading, RG7 4SA
  United Kingdom

  Telephone: +44 118 930 1300
  Facsimile: +44 118 930 1301
  E-mail:    GK@ACM.ORG

Appendix A: Message/RFC822+XML content-type registration


Appendix B: DTD for RFC822 message format


Appendix C: XML schema for RFC822 message format


Klyne                       Internet draft                   [Page 21]

XML coding of RFC822 messages                          18 October 2000

Appendix D: Amendment history

  00a  13-Oct-2000  Memo initially created.

  00b  16-Oct-2000  Add reference to XML spec note about non-ASCII
                    text in a URI.

  00c  18-Oct-2000  Change RFC822|XML to RFC822+XML (per later XML-
                    MIME spec).

Full copyright statement

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

Klyne                       Internet draft                   [Page 22]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/