Appendix E - BNF Summary

   boolean = "TRUE" / "FALSE"


   numericstring = *(DIGIT / " ")


   printablestring  = *( ps-char )
   ps-restricted-char      = 1DIGIT /  1ALPHA / " " / "'" / "+"
                             / "," / "-" / "." / "/" / ":" / "=" / "?"
   ps-delim         = "(" / ")"
   ps-char          = ps-delim / ps-restricted-char


   ps-encoded       = *( ps-restricted-char / ps-encoded-char )
   ps-encoded-char  = "(a)"               ; (@)
                      / "(p)"               ; (%)
                      / "(b)"               ; (!)
                      / "(q)"               ; (")
                      / "(u)"               ; (_)
                      / "(l)"               ; "("
                      / "(r)"               ; ")"
                      / "(" 3DIGIT ")"

   teletex-string   = *( ps-char / t61-encoded )
   t61-encoded      = "{" 1* t61-encoded-char "}"
   t61-encoded-char = 3DIGIT


   teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ]


   labelled-integer ::= [ key-string ] "(" numericstring ")"

   labelled-integer-2 ::= [ numericstring ] "(" key-string ")"

   key-string      = *key-char
   key-char        = <a-z, A-Z, 0-9, and "-">

   object-identifier  ::= oid-comp object-identifier
                          | oid-comp

   oid-comp ::= [ key-string ] "(" numericstring ")"


   encoded-info    = 1#encoded-type

   encoded-type    = built-in-eit / object-identifier

   built-in-eit    = "Undefined"         ; undefined (0)
                   / "Telex"             ; tLX (1)
                   / "IA5-Text"          ; iA5Text (2)
                   / "G3-Fax"            ; g3Fax (3)
                   / "TIF0"              ; tIF0 (4)
                   / "Teletex"           ; tTX (5)
                   / "Videotex"          ; videotex (6)
                   / "Voice"             ; voice (7)
                   / "SFD"               ; sFD (8)
                   / "TIF1"              ; tIF1 (9)



   encoded-pn      = [ given "." ] *( initial "." ) surname

   given           = 2*<ps-char not including ".">

   initial         = ALPHA

   surname         = printablestring


   std-or-address  = 1*( "/" attribute "=" value ) "/"
   attribute       = standard-type
                   / "RFC-822"
                   / dd-key "." std-printablestring

   std-or-address-input =  [ sep pair ] sep  pair *( sep pair )
                          sep  [ pair sep ]

   sep             = "/" / ";"
   pair            = input-attribute "=" value
   input-attribute = attribute
                   / dd-key ":" std-printablestring


   standard-type   = key-string

   dd-key          = key-string

   value           = std-printablestring

   std-printablestring
                   = *( std-char / std-pair )

   std-char        = <"{", "}", "*", and any ps-char

                                                except "/" and "=" >
   std-pair        = "$" ps-char


   global-id = std-or-address



   mta-field       = "X400-Received" ":" x400-trace
                   / "Deferred-Delivery" ":" date-time
                   / "Latest-Delivery-Time" ":" date-time



   x400-trace       = "by" md-and-mta ";"
                    [ "deferred until" date-time ";" ]
                    [ "converted" "(" encoded-info ")" ";" ]
                    [ "attempted" md-or-mta ";"  ]
                       action-list
                       ";" arrival-time


   md-and-mta       = [ "mta" mta "in" ]  global-id
   mta              = word
   arrival-time     = date-time

   md-or-mta        = "MD" global-id
                    / "MTA" mta

   Action-list      = 1#action
   action           = "Redirected"
                    / "Expanded"
                    / "Relayed"
                    / "Rerouted"

   dr-user-info = dr-summary <CRLF>
                  dr-recipients <CRLF>
                  dr-content-return


   dr-content-return = "The Original Message is not available"
        / "The Original Message follows:"

   dr-summary = "This report relates to your message:" <CRLF>
                   content-correlator <CRLF> <CRLF>
                "of" date-time <CRLF> <CRLF>

   dr-recipients = *(dr-recipient <CRLF> <CRLF>)

   dr-recipient = dr-recip-success / dr-recip-failure

   dr-recip-success =
                   "Your message was successfully delivered to:"
                    mailbox "at" date-time


   dr-recip-failure = "Your message was not delivered to:"
                           mailbox <CRLF>
                   "for the following reason:" *word

   report-point = [ "mta" mta-name "in" ] global-id
   content-correlator = *word
   mta-name = word

      dr-per-message-fields =
                / "X400-Conversion-Date" ":" date-time
                / "X400-Subject-Submision-Identifier" ":"
                                      mts-msg-id
                / "X400-Content-Identifier" ":" printablestring
                / "X400-Content-Type" ":" mts-content-type
                / "X400-Original-Encoded-Information-Types" ":"
                              encoded-info
                / "X400-Originator-and-DL-Expansion-History" ":"
                              mailbox ";" date-time ";"
                / "X400-Reporting-DL-Name" ":" mailbox
                / "X400-Content-Correlator" ":" content-correlator
                / "X400-Recipient-Info" ":" recipient-info
                / "X400-Subject-Intermediate-Trace-Information" ":"
                                        x400-trace
                / dr-extensions


      dr-per-recipient-fields =
                / "X400-Redirect-Recipient" ":" "x400" ";" std-or
                / "X400-Mapped-Redirect-Recipient" ":" "rfc822" ";"
                      mailbox
                / "X400-Converted-EITs" ":" encoded-info ";"
                / "X400-Delivery-Time" ":" date-time
                / "X400-Type-of-MTS-User" ":" labelled-integer
                / "X400-Last-Trace" ":" [ encoded-info ] date-time
                / "X400-Supplementary-Info" ":"
                      <"> printablestring <"> ";"
                / "X400-Redirection-History" ":" redirect-history-item
                / "X400-Physical-Forwarding-Address" ":" mailbox
                / "X400-Originally-Specified-Recipient-Number" ":"
                      integer
                / dr-extensions

      dr-extensions = "X400-Discarded-DR-Extensions" ":"
                        1# (object-identifier / labelled-integer)


      dr-diagnostic = "Reason" labelled-integer-2
                      [ ";" "Diagnostic" labelled-integer-2 ]

      mts-field = "X400-MTS-Identifier" ":" mts-msg-id
                / "X400-Originator" ":" mailbox
                / "X400-Recipients" ":" 1#mailbox
                / "Original-Encoded-Information-Types" ":"
                                encoded-info
                / "X400-Content-Type" ":" mts-content-type
                / "X400-Content-Identifier" ":" printablestring
                / "Priority" ":" priority
                / "Originator-Return-Address" ":" 1#mailbox
                / "DL-Expansion-History" ":" mailbox ";" date-time ";"
                / "Conversion" ":" prohibition
                / "Conversion-With-Loss" ":" prohibition
                / "Delivery-Date" ":" date-time
                / "Discarded-X400-MTS-Extensions" ":"
                             1#( object-identifier / labelled-integer )

      prohibition     = "Prohibited" / "Allowed"

      mts-msg-id       = "[" global-id ";" *text "]"

      mts-content-type = "P2" /  labelled-integer
                      / object-identifier

      priority        = "normal" / "non-urgent" / "urgent"

      ipn-body-format = ipn-description <CRLF>
                      [ ipn-extra-information <CRLF> ]
                      [ ipn-content-return ]

      ipn-description = ipn-receipt / ipn-non-receipt

      ipn-receipt = "Your message to:" preferred-recipient <CRLF>
               "was received at" receipt-time <CRLF> <CRLF>
               "This notification was generated"
                acknowledgement-mode <CRLF>
               "The following extra information was given:" <CRLF>
                ipn-suppl <CRLF>

      ipn-non-receipt = "Your message to:"
              preferred-recipient <CRLF>
              ipn-reason

      ipn-reason = ipn-discarded / ipn-auto-forwarded

      ipn-discarded = "was discarded for the following reason:"
                      discard-reason <CRLF>

      ipn-auto-forwarded = "was automatically forwarded." <CRLF>
                      [ "The following comment was made:"
                              auto-comment ]


      ipn-extra-information =
               "The following information types were converted:"
               encoded-info

      ipn-content-return = "The Original Message is not available"
                      / "The Original Message follows:"

      preferred-recipient = mailbox
      receipt-time        = date-time
      auto-comment        = printablestring
      ipn-suppl           = printablestring


      discard-reason     = "Expired" / "Obsoleted" /
                  "User Subscription Terminated" / "IPM Deleted"

      acknowledgement-mode = "Manually" / "Automatically"


      ipms-field = "Supersedes" ":" 1*msg-id
                 / "Expires" ":" date-time
                 / "Reply-By" ":" date-time
                 / "Importance" ":" importance
                 / "Sensitivity" ":" sensitivity
                 / "Autoforwarded" ":" boolean
                 / "Incomplete-Copy" ":"
                 / "Content-Language" ":" 1#language
                 / "Message-Type" ":" message-type
                 / "Discarded-X400-IPMS-Extensions" ":"
                       1#object-identifier
                 / "Autosubmitted" ":" autosubmitted

      importance      = "low" / "normal" / "high"

      sensitivity     = "Personal" / "Private" /
                             "Company-Confidential"

      language        = 2*ALPHA [ "(" language-description ")" ]

      language-description = printable-string


      message-type    = "Delivery Report"
                      / "InterPersonal Notification"
                      / "Multiple Part"


      autosubmitted   = "not-auto-submitted"
                      / "auto-generated"
                      / "auto-replied"
                      / "auto-forwarded"

      redirect-comment  = redirect-first *( redirect-subsequent )

      redirect-first = "Originally To:"  mailbox  "Redirected on"
               date-time "To:"  redirection-reason

      redirect-subsequent = mailbox  "Redirected Again on"
               date-time "To:"  redirection-reason

      redirection-history-item = "intended recipient" mailbox
               "redirected to"  redirection-reason
               "on" date-time

      redirection-reason =
               "Recipient Assigned Alternate Recipient"
               / "Originator Requested Alternate Recipient"
               / "Recipient MD Assigned Alternate Recipient"
               / "Directory Look Up"
               / "Alias"

      subject-line  = "Delivery-Report" "(" status ")"
                      [ "for" destination ]

      status        = "success" / "failure" / "success and failures"

      destination   = mailbox / "MTA" word

      extended-heading =
          "Prevent-NonDelivery-Report" ":"
          / "Generate-Delivery-Report" ":"
          / "Alternate-Recipient" ":" prohibition
          / "Disclose-Recipients" ":"  prohibition
          / "X400-Content-Return" ":" prohibition

Appendix F - Text format for MCGAM distribution

1.  Text Formats

   This appendix defines text formats for exchange of four types of
   mapping.

   1.   Domain Name Space -> OR Address Space MCGAM

   2.   OR Address Space -> Domain Name Space MCGAM

   3.   Domain Name Space -> OR Address of preferred gateway

   4.   OR Address Space -> Domain Name of preferred gateway

2.  Mechanisms to register and to distribute MCGAMs

   There is a well known set of MCGAM tables.

   The global coordination of the mapping rules is a part of the DANTE
   MailFLOW Project. New mapping rules may be defined by the authority
   responsible for the relevant name space. The rules need to be
   registered with a national mapping registration authority, which in
   turn passes them on to the central mapping registration authority.
   All the collected mapping rules are merged together into the globally
   coordinated mapping tables by the MailFLOW Project Team. The tables
   are available from the national mapping registration authorities.

   To get a contact address of the mapping registration authority for
   the respective country or more information about the MailFLOW Project
   contact:

      SWITCH
      MailFLOW Project Team
      Limmatquai 138
      8001 Zuerich
      Switzerland

      email: mailflow@mailflow.dante.net
             S=MailFLOW;O=MailFLOW;P=DANTE;A=mailnet;C=fi;

      fax:   +41 1 268 15 68
      tel:   +41 1 268 15 20

3.  Syntax Definitions

   An address syntax is defined, which is compatible with the syntax
   used for 822.domains.  By representing the OR addresses as domains,
   all lookups can be mechanically implemented as domain -> domain
   mappings.  This syntax defined is initially for use in table format,
   but the syntax is defined in a manner which makes it suitable to be
   adapted for  use with the  Domain Name Service.  This syntax allows
   for a general representation of OR addresses, so that it can be used
   in other applications.  Not all attributes are used in the table
   formats defined.

   To allow the mapping where a level of the hierarchy is omitted, the
   pseudo-value "@" (not a printable string character) is used to
   indicate omission of a level in the hierarchy.  This is distinct from
   the form including the element with no value, although a correct
   X.400 implementation will interpret both in the same manner.

   This syntax is not intended to be handled by users.

      dmn-or-address  = dmn-part *( "." dmn-part )
      mn-part        = dmn-attribute "$" value
      dmn-attribute  = standard-type
                      /  "~" dmn-printablestring
      value           = dmn-printablestring
                      / "@"
      dmn-printablestring =
                      = *( dmn-char / dmn-pair )
      dmn-char        = <"{", "}", "*", and any ps-char
                                              except ".">
      dmn-pair        = "\."

   An example usage:

      ~ROLE$Big\.Chief.ADMD$ATT.C$US
      PRMD$DEC.ADMD$@.C$US

   The first example illustrates quoting of a "." and a domain define
   attribute (ROLE).  The second  example illustrates omission of the
   ADMD level. There shall be a strict ordering of all components in
   this table, with the most significant components on the RHS.   This
   allows the encoding to be treated as a domain.

   Various further restrictions are placed on the usage of dmn-or-
   address in the address space mapping tables.

   a.   Only C, ADMD, PRMD, O, and up to four OUs may be used.

   b.   No components shall be omitted from this hierarchy, although
        the hierarchy may terminate at any level.  If the mapping is
        to an omitted component, the "@" syntax is used.

4.  Table Lookups

   When determining a match, there are aspects which apply to all
   lookups.  Matches are always case independent. The key for all three
   tables is a domain. The longest possible match shall be obtained.
   Suppose the table has two entries with the following keys:

      K.L
      J.K.L

      Domain "A.B.C" will not return any matches.  Domain "I.J.K.L"
      will match the entry "J.K.L:.

5.  Domain -> OR Address MCGAM format

   The BNF is:

      domain-syntax "#" dmn-or-address "#"

   EBNF.domain-syntax is defined in Section 4.2. Note that the trailing
   "#" is used for clarity, as the dmn-or-address syntax might lead to
   values with trailing blanks.  Lines starting with "#" are comments.

      For example:
      AC.UK#PRMD$UK\.AC.ADMD$GOLD 400.C$GB#
      XEROX.COM#O$Xerox.ADMD$ATT.C$US#
      GMD.DE#O$@.PRMD$GMD.ADMD$DBP.C$DE#

   A domain is looked up to determine the top levels of an OR Address.
   Components of the domain which are not matched are used to build the
   remainder of the OR address, as described in Section 4.3.4.

6.  OR Address -> Domain MCGAM format

   The syntax of this table is:

      dmn-or-address "#" domain-syntax "#"

      For example:

      #
      # Mapping table
      #
      PRMD$UK\.AC.ADMD$GOLD 400.C$GB#AC.UK#

   The OR Address is used to generate a domain key.  It is important to
   order the components correctly, and to fill in missing components in
   the hierarchy.  Use of this mapping is described in Section 4.3.2.

7.  Domain -> OR Address of Preferred Gateway table

   This uses the same format as the domain -> OR address MCGAM table.
   In this case, the restriction to only use C/ADMD/PRMD/O/OU does not
   apply.  Use of this mapping is described in Section 4.3.4. A domain
   cannot appear in this table and in the domain to OR Address table.

8.  OR Addresss -> domain of Preferred Gateway table

   This uses the same format as the OR Address -> domain MCGAM table.
   Use of this mapping is described in Section 4.3.5. An OR Address
   cannot appear in this table and in the OR Address to domain table.

Appendix G - Conformance

   This appendix defines a number of options, which a conforming gateway
   shall specify.  Conformance to this specification shall not be
   claimed if any of the mandatory features are not implemented.  A
   specification of conformance may list the service elements of Chapter
   2, in order to be clear that full conformance is provied.  In
   particular:

   -    Formats for all fields shall be followed.

   -    The gateway shall enable MCGAMs to be used.

   -    Formats for subject lines, delivery reports and IPNs shall
        be followed.   A system which followed the syntax, but
        translated text into a language other than english would be
        conformant.

   -    RFC 1137 shall not be followed when mapping to SMTP.

   -    All mappings of trace shall be implemented.

   -    There shall be a mechanism to access all three global
        mappings.

   -    RFC 2157 shall be followed for mapping body parts.

   -    When it is specified that a MIME format message is
        generated, RFC 2045 shall be followed.

   A gateway shall specify:

   -    Which Interent Message Transport (822-MTS)  protocols are
        supported.  If SMTP is supported, Appendex A of MIXER shall
        be used.

   -    Which X.400 versions  are supported (84, 88, 92).

   -    Which mechanisms (table, X.500, DNS) are supported to access
        MCGAMs.

   -    The mechanism or mechanisms by which the global mapping
        information is accessed.

   The following are optional parts of this specification.  A conforming
   implementation shall specify which of these it supports.

   -    Support for the extension mappings of Appendix C.

   -    Support for returning illegal format content in a delivery
        report

   -    Which address interpretation heuristics are supported
        (4.3.4.1)

   -    If RFC 987 generated message ids are handled in a backwards
        compatible manner (4.7.3.6)

Appendix H - Change History: RFC 987, 1026, 1138, 1148

   RFC 987 was the original document, and contained the key elements of
   this specification.  It was specific to X.400(1984).  RFC 1026
   specified a small number of necessary changes to RFC 987.

   RFC 1138 was based on the RFC 987 work.  It contained an editorial
   error, and was reissued a few months later as RFC 1148.  RFC 1148
   will be referred to here, as it is the document which is widely
   referred to elsewhere. The major goal of RFC 1148 was to upgrade RFC
   987 to X.400(1988).  It did this, but did not obsolete RFC 987, which
   was recommended for use with X.400(1984).  This appendix summarises
   the changes made in going from RFC 987 to RFC 1148.

   RFC 1148 noted the following about its upgrade from RFC 987:
   Unnecessary change is usually a bad idea.  Changes on the RFC 822
   side are avoided as far as possible,  so that RFC 822 users do not
   see arbitrary differences between systems conforming to this
   specification, and those following RFC 987.  Changes on the X.400
   side are minimised, but are more  acceptable, due to the mapping onto
   a new set of services and protocols.

1.  Introduction

   The model has shifted from a protocol based mapping to a service
   based mapping.  This has increased the generality of the
   specification, and improved the model.  This change affects the
   entire document.

   A restriction on scope has been added.

2.  Service Elements

   -    The new service elements of X.400 are dealt with.

   -    A clear distinction is made between origination and
        reception

3.  Basic Mappings

   -    Add teletex support

   -    Add object identifier support

   -    Add labelled integer support

   -    Make PrintableString <-> ASCII mapping reversible

   -    The printable string mapping is aligned to the NBS mapping
        derived from RFC 987.

4.  Addressing

   -    Support for new addressing attributes

   -    The message ID mapping is changed to not be table driven

5.  Detailed Mappings


   -    Define extended IPM Header, and use instead of second body
        part for RFC 822 extensions

   -    Realignment of element names

   -    New syntax for reports, simplifying the header and
        introducing a mandatory body format (the RFC 987 header
        format was unusable)

   -    Drop complex autoforwarded mapping

   -    Add full mapping for IP Notifications, defining a body
        format

   -    Adopt an MTS Identifier syntax in line with the OR Address
        syntax

   -    A new format for X400 Trace representation on the RFC 822
        side

6.  Appendices

   -    Move Appendix on restricted 822 mappings to a separate RFC

   -    Delete Phonenet and SMTP Appendixes

Appendix I - Change History: RFC 1148 to RFC 1327

1.  General

   -    The scope of the document was changed to cover X.400(1984),
        and so obsolete RFC 987.

   -    Changes were made to allow usage to connect RFC 822 networks
        using X.400

   -    Text was tightened to be clear about optional and mandatory
        aspects

   -    A good deal of clarification

   -    A number of minor EBNF errors

   -    Better examples are given

   -    Further X.400 upper bounds are handled correctly

2.  Basic Mappings

   -    The encoding of object identifier is changed slightly

3.  Addressing

   -    A global mapping of domain to preferred gateway is
        introduced.

   -    An overflow mechanism is defined for RFC 822 addresses of
        greater than 128 bytes

   -    Changes were made to improve compatibility with the PDAM on
        writing OR Addresses.

   +         The PD and Terminal Type keywords were aligned to the
             PDAM.  It is believed that minimal use has been made of
             the RFC 1148 keywords.

   +         P and A are allowed as alternate keys for PRMD and ADMD

   +         Where keywords are different, the PDAM keywords are
             alternatives on input.  This is mandatory.

4.  Detailed Mappings

   -    The format of the Subject: lines is defined.

   -    Illegal use (repetition) of the heading EXTENSION is
        corrected, and a new object identifier assigned.

   -    The Delivery Report format is extensively revised in light
        of operational experience.

   -    The handling of redirects is significantly changed, as the
        previous mechanism did not work.

5.  Appendices

   -    An SMTP appendix is added, allowing optional use of the VRFY
        command to improve probe information.

   -    Handling of JNT Mail Acknowledge-To is changed slightly.

   -    A DDA JNT-MAIL is allowed on input.

   -    The format definitions of Appendix F are explained further,
        and a third table definition added.

   -    An appendix on use with X.400(1984) is added.

   -    Optional extensions are defined to give RFC 822 access to
        further X.400 facilities.

   -    An appendix on conformance is added.

Appendix J - Change History: RFC 1327 to this Document

1.  General

   This update is primarily for stability, and to fold in compatibility
   for MIME and to add support for the new NOTARY delivery status
   notifications.  Other general changes:

   -    Various editorial updates

   -    Minor EBNF errors

   -    Reference to mapping table support by DNS and X.500.

   -    Alignment to X.400(92)

   -    Assignment of a new object identifier

   -    Removal of specification relating to body mapping, which is
        now defined in RFC 2157.

2.  Service Elements

   -    Support of Auto-Submitted service

3.  Basic Mappings

   -    Comments shall not be used in new headers, to remove parsing
        ambiguity

   -    RFC 1522 encoding may be used as an alternative to X.408
        downgrade, where appropriate.

   -    Correct handling of RFC 822 four year dates.

4.  Addressing

   -    Replaced the mandatory global address mapping with MCGAMs.

   -    Add codes and add a heuristic to align to the standard X.400
        form of writing OR Addresses.

   -    Improved text on ordering heuristic

   -    Leading "/" interpretation added

   -    All bar one of the address mapping heuristics made
        mandatory.

   -    Interpretation of domain defined attribute "RFC-822" made
        mandatory in all cases

   -    Make report request comments optional

5.  Detailed Mappings

   -    Comments no longer maps to separate body part

   -    Allow Languages to be multi-valued

   -    Change Content-Identifier to X400-Content-Identifier, in
        order to avoid confusion with MIME.

   -    Reverse mapping of MIXER defined fields made mandatory

   -    "Expiry-Date:" changed to "Expires:".

   -    "Obsoletes:" changed to "Supersedes:".

   -    Define correct handling when "Resent-Date:" is present.

6.  Appendices

   -    Change "Content-Return" to "X400-Content-Return" in Appendix
        C.

   -    Relaxation of restrictions on mapping 3 in Appendix F.

   -    Add linkage to HARPOON in Appendix B.

   -    RFC 2157 added to the conformance statement of Appendix
         G.

   -    Added Appendix L, with ASN. Summary.

Appendix L - ASN.1 Summary

   MIXER Definitions { iso org(3) dod(6) internet(1) mail(7)
         mixer(1) mixer-core(3) definitions(1) }

   DEFINITIONS IMPLICIT TAGS ::=

   BEGIN

   -- exports everything

   IMPORTS

   EXTENSION FROM
     MTSAbstractService {join-iso-ccit mhs-motis(6) mts(3)
           modules(0) mts-abstract-service(1) }

     HEADING-EXTENSION FROM
       IPMSAbstractService {join-iso-ccit mhs-motis(6) ipms(1)
             modules(0) abstract-service(3) }



   rfc-822-field HEADING-EXTENSION
           VALUE RFC822FieldList
           ::= id-rfc-822-field-list


   RFC822FieldList ::= SEQUENCE OF RFC822Field

   RFC822Field ::= IA5String



   dsn-header-list EXTENSION
      RFC822FieldList
      ::= id-dsn-header-list

   dsn-field-list EXTENSION
      RFC822FieldList
      ::= id-dsn-field-list

   internet ::= OBJECT IDENTIFIER  { iso org(3) dod(6) 1 } -- from RFC
   1155

   mail OBJECT IDENTIFIER ::= { internet 7 }  -- IANA assigned

   mixer OBJECT IDENTIFIER ::= { mail mixer(1) } -- inherited from RFC
   1495
   mixer-core OBJECT IDENTIFIER ::= { mixer core(3) }

   id-rfc-822-field-list OBJECT IDENTIFIER ::= {mixer-core 2}
   id-dsn-header-list OBJECT IDENTIFIER ::= {mixer-core 3}
   id-dsn-field-list OBJECT IDENTIFIER ::= {mixer-core 4}

   eit-mixer OBJECT IDENTIFIER ::= {mixer-core 5}
                   -- the MIXER pseudo-EIT


   END -- MIXER ASN.1

SECURITY CONSIDERATIONS

   Security issues are not discussed in this memo.

AUTHOR'S ADDRESS

   Steve Kille
   Isode Ltd
   The Dome
   The Square
   Richmond
   TW9 1DT
   England

   Phone: +44-181-332-9091
   Internet EMail: S.Kille@ISODE.COM

   X.400 Email: I=S; S=Kille; P=Isode; A=Mailnet; C=FI;

   UFN:  S.Kille, Isode, GB

References

   1.   CCITT , "Recommendations X.400", Message Handling Systems:
        System Model - Service Elements, October 1984.

   2.   Allocchio, C., "MaXIM11 - Mapping between X.400 / Internet
        Mail and Mail-11 mail", RFC 2162, January 1998.

   3.   Allocchio, C., "Using the Internet DNS to Distribute MIXER
        Conformant Global Address Mapping (MCGAM)", RFC 2163,
        January 1998.

   4.   Alvestrand, H., Kille, S., Miles, R., Rose, M., and S.
        Thompson, "Mapping between X.400 and RFC-822 Message
        Bodies", RFC 1495, August 1993.

   5.   Alvestrand, H., Romaguera, J., and K. Jordan, "Rules for
        Downgrading Messages for X.400(88) to X.400(84) When MIME
        Content-Types are Present in the Messages (Harpoon)", RFC
        1496, August 1993.

   6.   Alvestrand, H., and S. Thompson, "Equivalences between X.400
        and RFC-822 Message Bodies", RFC 1494, August 1993.

   7.   Alvestrand, H., "Tags for the Identification of Languages",
        RFC 1766, March 1995.

   8.   Alvestrand, H., "Mapping between X.400 and RFC-822/MIME
        Message Bodies", RFC 2157, January 1998.

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

   10.  Braden, R., "Requirements for Internet Hosts -- Application
        and Support", STD 3, RFC 1123, October 1989.

   11.  CCITT/ISO, "CCITT Recommendations X.420/ ISO/IEC 10021-7,"
        Message Handling Systems: Interpersonal Messaging System,
        Dec 1988.

   12.  CCITT/ISO, "CCITT Recommendations X.411/ ISO/IEC 10021-4,"
        Message Handling Systems: Message Transfer System: Abstract
        Service Definition and Procedures, Dec 1988.

   13.  CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1,"
        Message Handling: System and Service Overview , Dec 1988.

   14.  CCITT/ISO, "Specification of Abstract Syntax Notation One
        (ASN.1)," CCITT Recommendation X.208 / ISO/IEC 8824, Dec
        1988.

   15.  CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1,"
        Message Handling: System and Service Overview , Dec 1992.

   16.  Crocker, D., "Standard of the Format of ARPA Internet Text
        Messages", STD 11, RFC 822, August 1982.

   17.  Kille, S., "Mapping Between X.400 and RFC 822", UK Academic
        Community Report (MG.19) / RFC 987, June 1986.

   18.  Kille, S., "Addendum to RFC 987", UK Academic Community
        Report (MG.23) / RFC 1026, August 1987.

   19.  Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
        822", RFC 1138, October 1989.

   20.  Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
        822", RFC 1148, March 1990.

   21.  Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
        822", RFC 1327, May 1992.

   22.  Kille, S., "X.400 1988 to 1984 downgrading", RFC 1328, May
        1992.

   23.  Kille, S., "A String Encoding of Presentation Address", RFC
        1278, November 1992.

   24.  Kille, S., "A String Representation of Distinguished Name",
        RFC 1485, January 1992.

   25.  Kille, S., "Using the OSI Directory to achieve User
        Friendly Naming", RFC 1484, January 1992.

   26.  Kille, S., "Use of an X.500/LDAP directory to support MIXER
        address mapping", RFC 2164, January 1998.

   27.  Koorland, N., "Message Attachmment Work Group (MAWG): MAWG
        Feasibility Project Guide," EMA Report, Version 1.5, Nov
        1995.

   28.  Moore, K., and G. Vaudreuil, "An Extensible Message Format for
        Delivery Status Notifications", RFC 1894, January 1996.

   29.  Moore, K., "SMTP Service Extensions for Delivery Status
        Notifications", RFC 1891, Januaty 1996.

   30.  Postel, J., "SIMPLE MAIL TRANSFER PROTOCOL", STD 10, RFC 821,
        August 1982.

Full Copyright Statement

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