Browse Prior Art Database

Addendum to RFC 987: (Mapping between X.400 and RFC-822) (RFC1026) Disclosure Number: IPCOM000001830D
Original Publication Date: 1987-Sep-01
Included in the Prior Art Database: 2005-May-22
Document File: 7 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S.E. Kille: AUTHOR


(Mapping between X.400 and RFC-822)

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 38% of the total text.

Network Working Group                                          S.E. Kille
Request for Comments 1026                       University College London
                                                           September 1987

                         Addendum to RFC 987

                 (Mapping between X.400 and RFC-822)

Status of this Memo

   This RFC suggest a proposed protocol for the Internet community, and
   requests discussion and suggestions for improvements.  Distribution
   of this memo is unlimited.

   This document specifies a number of additions and corrections to
   RFC-987, aka Mailgroup Note 19.

   The addendum carries equal weight to the original specification,
   which must be used when this mapping is performed on the Internet or
   in the UK Academic Community.  This mapping may also be used within
   the RARE community in Europe.  This specification may be modified in
   the light of implementation experience, but no substantial changes
   are expected.

1.  Errata

   -    In section 4.6.4, replace ".." with ".".

   -    In section 4.2.4, replace three references to 4.3.1 by
        4.2.1, and one reference to 4.2.2 by 4.1.2.

   -    In section 5.2, replace "1  mailbox" with "1#mailbox",
        "1 msg-id" with "1#msg-id" and "1 encoded-type" with

2.  Component Ordering

   In most cases, ordering of O/R name components is not significant for
   the mappings specified by this document.  However, Organisational
   Units and Domain Defined Attributes are specified as SEQUENCE, in
   P1.ORName, and so their order may be significant.  This specification
   needs to take account of this in two ways:

   1)   To allow consistent mapping into the domain hierarchy

   2)   To ensure preservation of order over multiple mappings.

Kille                                                           [Page 1]
RFC 1026                                                  September 1987

There are three places where an order must be specified:

   1)   On the text encoding (std-orname) of P1.ORName as used in the
        local-part of an RFC-822 address, the most significant component
        must be on the RHS.  This applies only to those components which
        may have multiple values (Organisational Unit, and Domain
        Defined Attributes).  Other attributes may be presented in any
        order. Note that in dmn-orname specified in Appendix F, this
        ordering is already implied by the current ordering

   2)   For the Organisational Units (OU) in P1.ORName, the first OU in