5.3.3.  Basic Mappings

5.3.3.1.  Encoded Information Types

   This mapping from MTS.EncodedInformationTypes is needed in
   several disconnected places.  EBNF is defined as follows:

                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)

   MTS.EncodedInformationTypes is mapped onto EBNF.encoded-info.
   MTS.EncodedInformationTypes.non-basic-parameters is ignored.  Built
   in types are mapped onto fixed strings (compatible with X.400(1984)
   and RFC 987), and other types are mapped onto EBNF.object-identifier.

5.3.3.2.  Global Domain Identifier

   The following simple EBNF is used to represent
   MTS.GlobalDomainIdentifier:

                global-id = std-or-address

   This is encoded using the std-or-address syntax, for the attributes
   within the Global Domain Identifier.

5.3.4.  Mappings from the IP Message

   Consider that an IPM has to be mapped to RFC 822.  The IPMS.IPM
   comprises an IPMS.IPM.heading and IPMS.IPM.body.   The heading is
   considered first.  Some EBNF for new fields is defined:

                ipms-field = "Obsoletes" ":" 1#msg-id
                           / "Expiry-Date" ":" date-time
                           / "Reply-By" ":" date-time
                           / "Importance" ":" importance
                           / "Sensitivity" ":" sensitivity

                           / "Autoforwarded" ":" boolean
                           / "Incomplete-Copy" ":"
                           / "Language" ":" language
                           / "Message-Type" ":" message-type
                           / "Discarded-X400-IPMS-Extensions" ":" 1#oid



                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"

   The mappings and actions for the IPMS.Heading is now specified for
   each element.  Addresses, and Message Identifiers are mapped
   according to Chapter 4.  Other mappings are explained, or are
   straightforward (algorithmic).

   IPMS.Heading.this-IPM
        Mapped to "Message-ID:".

   IPMS.Heading.originator
        If IPMS.Heading.authorizing-users is present this is mapped
        to Sender:, if not to "From:".

   IPMS.Heading.authorizing-users
        Mapped to "From:".

   IPMS.Heading.primary-recipients
        Mapped to "To:".

   IPMS.Heading.copy-recipients
        Mapped to "Cc:".

   IPMS.Heading.blind-copy-recipients
        Mapped to "Bcc:".

   IPMS.Heading.replied-to-ipm
        Mapped to "In-Reply-To:".

   IPMS.Heading.obsoleted-IPMs
        Mapped to the extended RFC 822 field "Obsoletes:"

   IPMS.Heading.related-IPMs
        Mapped to "References:".

   IPMS.Heading.subject
        Mapped to "Subject:".  The contents are converted to ASCII
        (as defined in Chapter 3).  Any CRLF are not mapped, but
        are used as points at which the subject field must be
        folded.

   IPMS.Heading.expiry-time
        Mapped to the extended RFC 822 field "Expiry-Date:".

   IPMS.Heading.reply-time
        Mapped to the extended RFC 822 field "Reply-By:".

   IPMS.Heading.reply-recipients
        Mapped to "Reply-To:".

   IPMS.Heading.importance
        Mapped to the extended RFC 822 field "Importance:".

   IPMS.Heading.sensitivity
        Mapped to the extended RFC 822 field "Sensitivity:".

   IPMS.Heading.autoforwarded
        Mapped to the extended RFC 822 field "Autoforwarded:".

   The standard extensions (Annex H of X.420 / ISO 10021-7) are mapped
   as follows:

   incomplete-copy
        Mapped to the extended RFC 822 field "Incomplete-Copy:".

   language
        Mapped to the extended RFC 822 field "Language:", filling in
        the two letter code. If possible, the language-description
        should be filled in with a human readable description of the
        language.

   If the RFC 822 extended header is found, this should be mapped onto
   an RFC 822 header, as described in Section 5.1.2.

   If a non-standard extension is found, it should be discarded, unless
   the gateway understands the extension and can perform an appropriate
   mapping onto an RFC 822 header field.  If extensions are discarded,

   the list should be indicated in the extended RFC 822 field
   "Discarded-X400-IPMS-Extensions:".

   The IPMS.Body is mapped into the RFC 822 message body.  Each
   IPMS.BodyPart is converted to ASCII as follows:

   IPMS.IA5Text
        The mapping is straightforward (see Chapter 3).

   IPMS.MessageBodyPart
        The X.400 -> RFC 822 mapping  should be recursively applied,
        to generate an RFC 822 Message.  If present, the
        IPMS.MessageBodyPart.parameters.delivery-envelope should be
        used for the MTS Abstract Service Mappings.  If present, the
        IPMS.MessageBodyPart.parameters.delivery-time should be
        mapped to the extended RFC 822 field "Delivery-Date:".

   Other
        If other body parts can be mapped to IA5, either by use of
        mappings defined in X.408 [CCITT88a], or by other reasonable
        mappings, this should be done unless content conversion is
        prohibited.

   If some or all of the body parts cannot be converted there are three
   options.  All of these conform to this standard.  A different choice
   may be made for the case where no body part can be converted:

   1.   The first option is to reject the message, and send a non-
        delivery notification.  This must always be done if
        conversion is prohibited.

   2.   The second option is to map a missing body part to something
        of the style:

                *********************************

                There was a foobar here

                The widget gateway ate it

                *********************************

        This will allow some useful information to be transferred.
        As the recipient is a human (IPMS), then suitable action
        should be available.

   3.   Finally both can be done.  In this case, the supplementary
        information in the (positive) Delivery Report should make

        clear that something was sent on to the recipient with
        substantial loss of information.

   Where there is more than one IPMS.BodyPart, the mapping defined by
   Rose and Stefferud in [Rose85a], should be used to map the separate
   IPMS.BodyParts in the single RFC 822 message body.  If this is done,
   a "Message-Type:" field with value "Multiple part" should be added,
   which will indicate to a receiving gateway that the message may be
   unfolded according to RFC 934.

   For backwards compatibility with RFC 987, the following procedures
   should also be followed.  If there are two IA5 body parts, and the
   first starts with the string "RFC-822-Headers:" as the first line,
   then the remainder of this body part should be appended to the RFC
   822 header.

5.3.5.  Mappings from an IP Notification

   A message is generated, with the following fields:

   From:
        Set to the MTS.MessageDeliveryEnvelope.other-
        fields.originator-name.

   To:  Set to the IPMS.IPN.ipm-originator.

   Subject:
        Set to something of the form "X.400 Inter-Personal Receipt
        Notification".

   Message-Type:
        Set to "InterPersonal Notification"

   References:
        Set to IPMS.IPN.subject-ipm

   The following EBNF is defined for the body of the Message.  This
   format is defined to ensure that all information from an
   interpersonal notification is available to the end user in a uniform
   manner.

           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:"
                             <CRLF> <CRLF> message


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

           non-receipt-reason = "Discarded" / "Auto-Forwarded"

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

           acknowledgement-mode = "Manually" / "Automatically"

   The mappings for elements of the common fields of IPMS.IPN
   (IPMS.CommonFields) onto this structure and the message header are:

        subject-ipm
             Mapped to "References:"

        ipm-originator
             Mapped  to "To:".

        ipm-preferred-recipient
             Mapped to EBNF.preferred-recipient

        conversion-eits
             Mapped to EBNF.encoded-info in EBNF.ipn-extra-information

        The mappings for elements of IPMS.IPN.non-receipt-fields
        (IPMS.NonReceiptFields) are:

        non-receipt-reason
             Used to select between EBNF.ipn-discarded and
             EBNF.ipn-auto-forwarded

        discard-reason
             Mapped to EBNF.discard-reason

        auto-forward-comment
             Mapped to EBNF.auto-comment

        returned-ipm
             If present, the second option of EBNF.ipn-content-return
             should be chosen, and an RFC 822 mapping of the message
             included.  Otherwise the first option should be chosen.

        The mappings for elements of IPMS.IPN.receipt-fields
        (IPMS.ReceiptFields) are:

        receipt-time
             Mapped to EBNF.receipt-time

        acknowledgement-mode
             Mapped to EBNF.acknowledgement-mode

        suppl-receipt-info
             Mapped to EBNF.ipn-suppl

   An example notification is:

      From: Steve Kille <steve@cs.ucl.ac.uk>
      To: Julian Onions <jpo@computer-science.nottingham.ac.uk>
      Subject: X400 Inter-personal Receipt Notification
      Message-Type: InterPersonal Notification
      References: <1229.614418325@UK.AC.NOTT.CS>
      Date: Wed, 21 Jun 89 08:45:25 +0100

      Your message to: Steve Kille <steve@cs.ucl.ac.uk>
      was automatically forwarded.
      The following comment was made:
      Sent on to a random destination

      The following information types were converted: g3fax

      The Original Message is not available

5.3.6.  Mappings from the MTS Abstract Service

   This section describes the MTS mappings for User Messages (IPM and
   IPN).  This mapping is defined by specifying the mapping of
   MTS.MessageDeliveryEnvelope.  The following extensions to RFC 822 are
   defined to support this mapping:

      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
                / "Content-Identifier" ":" printablestring
                / "Priority" ":" priority
                / "Originator-Return-Address" ":" 1#mailbox
                / "DL-Expansion-History" ":" mailbox ";" date-time ";"
                / "Redirection-History" ":" redirection
                / "Conversion" ":" prohibition
                / "Conversion-With-Loss" ":" prohibition
                / "Requested-Delivery-Method" ":"
                                1*( labelled-integer )
                / "Delivery-Date" ":" date-time
                / "Discarded-X400-MTS-Extensions" ":"
                                1#( oid / labelled-integer )


      prohibition     = "Prohibited" / "Allowed"

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

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

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

      redirection     = mailbox ";" "reason" "="
                              redirection-reason
                              ";" date-time

      redirection-reason =
                      "Recipient Assigned Alternate Recipient"
                    / "Originator Requested Alternate Recipient"
                    / "Recipient MD Assigned Alternate Recipient"


      These elements are only appropriate for physical delivery.  They
      are represented as comments in the "X400-Recipients:" field, as
      described in Section 4.6.2.2.

   originator-certificate
   message-token
   content-confidentiality-algorithm-identifier
   content-integrity-check
   message-origin-authentication-check
   message-security-label
   proof-of-delivery-request

      These elements imply use of security services not available in the
      RFC 822 environment.  If they are marked as critical for transfer
      or delivery, then the message should be rejected.  Otherwise they
      should be discarded.

   redirection-history
        Each element is mapped to an extended RFC 822 field
        "Redirection-History:".  They should be ordered in the
        message header, so that the most recent redirection comes
        first (same order as trace).

   dl-expansion-history
        Each element is mapped to the extended RFC 822 field
        "DL-Expansion-History:".  They should be ordered in the
        message header, so that the most recent expansion comes
        first (same order as trace).

   If any MTS (or MTA) Extensions not specified in X.400 are present,
   and they are marked as critical for transfer or delivery, then the
   message should be rejected.  If they are not so marked, they can
   safely be discarded.  The list of discarded fields should be
   indicated in the extended header "Discarded-X400-MTS-Extensions:".

5.3.7.  Mappings from the MTA Abstract Service

   There are some mappings at the MTA Abstract Service level which are
   done for IPM and IPN.  These can be derived from
   MTA.MessageTransferEnvelope.  The reasons for the mappings at this
   level, and the violation of layering are:

   -    Allowing for multiple recipients to share a single RFC 822
        message.

   -    Making the X.400 trace information available on the RFC 822
        side.

   -    Making any information on deferred delivery available.

   The 822-MTS recipients should be calculated from the full list of
   X.400 recipients.  This is all of the members of
   MTA.MessageTransferEnvelope.per-recipient-fields being passed
   through the gateway, where the responsibility bit is set.  In
   some cases, a different RFC 822 message would be calculated for
   each recipient.  If this is due to differing service requests for
   each recipient, then a different message should be generated.
   If it is due only to the request for non-disclosure of
   recipients, then the "X400-Recipients:" field should be omitted,
   and only one message sent.

   The following EBNF is defined for extended RFC 822 headers:

      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-and-mta ";"  ]
                          action-list
                          ";" arrival-time


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


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

   If MTA.PerMessageTransferFields.deferred-delivery-time is present,
   use it to generate a Deferred-Delivery: field.  For some reason,
   X.400 does not make this information available at the MTS level on

   delivery.  X.400 profiles, and in particular the CEN/CENELEC profile
   for X.400(1984) [Systems85a], specify that this element must be
   supported at the first MTA.  If it is not, the function may
   optionally be implemented by the gateway: that is, the gateway should
   hold the message until the time specified in the protocol element.
   Thus, it is expected that the value of this element will often be in
   the past.  For this reason, the extended RFC 822 field is primarily
   for information.

   Merge MTA.PerMessageTransferFields.trace-information, and
   MTA.PerMessageTransferFields.internal-trace-information to produce a
   single ordered trace list.  If Internal trace from other management
   domains has not been stripped, this may require complex interleaving.
   Use this to generate a sequence of "X400-Received:" fields.  The only
   difference between external trace and internal trace will be the
   extra MTA information in internal trace elements.

   When generating an RFC 822 message all trace fields (X400- Received
   and Received) should be at the beginning of the header, before any
   other fields.  Trace should be in chronological order, with the most
   recent element at the front of the message.  A simple example trace
   (external) is:

   X400-Received: by /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ; Relayed ;
           Tue, 20 Jun 89 19:25:11 +0100

   A more complex example (internal):

   X400-Received: by mta UK.AC.UCL.CS in
                                      /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ;
           deferred until  Tue, 20 Jun 89 14:24:22 +0100 ;
           converted (undefined, g3fax) ";" attempted /ADMD=Foo/C=GB/ ;
           Relayed, Expanded, Redirected ; Tue, 20 Jun 89 19:25:11 +0100

5.3.8.  Mappings from Report Delivery

   Delivery reports are mapped at the MTS service level.  This means
   that only reports destined for the MTS user will be mapped.  Some
   additional services are also taken from the MTA service.

5.3.8.1.  MTS Mappings

   A Delivery Report service will be represented as
   MTS.ReportDeliveryEnvelope, which comprises of per-report-fields
   (MTS.PerReportDeliveryFields) and per-recipient-fields.

   A message should be generated with the following fields:

   From:
        An administrator at the gateway system.  This is also the
        822-MTS originator.

   To:  A mapping of the
        MTA.ReportTransferEnvelope.report-destination-name.  This is
        also the 822-MTS recipient.

   Message-Type:
        Set to "Delivery Report".

   Subject:
        Something of the form "X.400 Delivery Report".

   The format of the body of the message is defined to ensure that all
   information is conveyed to the RFC 822 user in a consistent manner.
   This gives a summary of critical information, and then a full listing
   of all parameters:


   dr-body-format = dr-summary <CRLF>
                    dr-recipients <CRLF>
                    dr-extra-information <CRLF>
                    dr-content-return


   dr-content-return = "The Original Message is not available"
                   / "The Original Message follows:"
                     <CRLF> <CRLF> message

   dr-summary = "This report relates to your message:" <CRLF>
                content-correlator <CRLF> <CRLF>
                "of" date-time <CRLF> <CRLF>
                "It was generated by:" report-point <CRLF>
                "at" date-time <CRLF> <CRLF>
                "It was later converted to RFC 822 by:" mailbox <CRLF>
                "at" 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


   dr-extra-information =
    "-----------------------------------------------" <CRLF> <CRLF>
    "The following information is derived from the Report" <CRLF>
    "It may be useful for problem diagnosis:" <CRLF> <CRLF>
    drc-field-list

   drc-field-list       = *(drc-field <CRLF>)

   drc-field = "Subject-Submission-Identifier" ":"
                           mts-msg-id
             / "Content-Identifier" ":" printablestring
             / "Content-Type" ":" mts-content-type
             / "Original-Encoded-Information-Types" ":"
                           encoded-info
             / "Originator-and-DL-Expansion-History" ":"
                           dl-history
             / "Reporting-DL-Name" ":" mailbox
             / "Content-Correlator" ":" content-correlator
             / "Recipient-Info" ":" recipient-info
             / "Subject-Intermediate-Trace-Information" ":"
                           x400-trace


   recipient-info  = mailbox "," std-or ";"
                   report-type
                   [ "converted eits" encoded-info ";" ]
                   [ "originally intended recipient"
                            mailbox "," std-or ";" ]
                   [ "last trace" [ encoded-info ] date-time ";" ]
                   [ "supplementary info" <"> printablestring <"> ";" ]
                   [ "redirection history" 1#redirection ";"
                   [ "physical forwarding address"
                                         printablestring ";" ]


   report-type     = "SUCCESS" drc-success
                   / "FAILURE" drc-failure

   drc-success     = "delivered at" date-time ";"
                   [ "type of MTS user" labelled-integer ";" ]

   drc-failure     = "reason" labelled-integer ";"
                   [ "diagnostic" labelled-integer ";" ]

   report-point = [ "mta" word "in" ] global-id
   content-correlator = *word
   dl-history = 1#( mailbox "(" date-time ")")

   The format is defined as a fixed definition.  The only exception is
   that the EBNF.drc-fields should follow RFC 822 folding rules.

   The elements of MTS.ReportDeliveryEnvelope.per-report-fields are
   mapped as follows onto extended RFC 822 fields:

   subject-submission-identifier
        Mapped to EBNF.drc-field (Subject-Submission-Identifier)

   content-identifier
        Mapped to EBNF.drc-field (Content-Identifier)

   content-type
        Mapped to EBNF.drc-field (Content-Type)

   original-encoded-information-types
        Mapped to EBNF.drc-field (Encoded-Info)

   The extensions from
   MTS.ReportDeliveryEnvelope.per-report-fields.extensions are
   mapped as follows:

   originator-and-DL-expansion-history
        Mapped to EBNF.drc-field (Originator-and-DL-Expansion-
        History)

   reporting-DL-name
        Mapped to EBNF.drc-field (Reporting-DL-Name)

   content-correlator
        Mapped to EBNF.content-correlator, provided that the
        encoding is IA5String (this should always be the case).
        This is used in EBNF.dr-summary and EBNF.drc-field-list.
        In the former, LWSP may be added, in order to improve the
        layout of the message.

   message-security-label
   reporting-MTA-certificate
   report-origin-authentication-check

      These security parameters should not be present.  If they are,
      they should be discarded in preference to discarding the whole
      report.

   For each element of MTS.ReportDeliveryEnvelope.per-recipient-fields,
   a value of EBNF.dr-recipient, and an EBNF.drc-field (Recipient-Info)
   should be generated.  The components are mapped as follows.

   actual-recipient-name
        Used to generate the first EBNF.mailbox and EBNF.std-or in
        EBNF.recipient-info.  Both RFC 822 and X.400 forms are
        given, as there may be a problem in the mapping tables.  It
        also generates the EBNF.mailbox in EBNF.dr-recip-success or
        EBNF.dr-recip-failure.

   report
        If it is MTS.Report.delivery, then set EBNF.dr-recipient to
        EBNF.dr-recip-success, and similarly set EBNF.report-type,
        filling in EBNF.drc-success.  If it is a failure, set
        EBNF.dr-recipient to EBNF.dr-recip-failure, making a human
        interpretation of the reason and diagnostic codes, and
        including any supplementary information.  EBNF.drc-failure
        should be filled in systematically.

   converted-encoded-information-types
        Set EBNF.drc-field ("converted eits")

   originally-intended-recipient
        Set the second ("originally intended recipient") mailbox

        and

        std-or in EBNF.drc-field.

   supplementary-info
        Set EBNF.drc-field ("supplementary info"), and include this
        information in EBNF.dr-recip-failure.

   redirection-history
        Set EBNF.drc-field ("redirection history")

   physical-forwarding-address
        Set ENBF.drc-field ("physical forwarding address")

   recipient-certificate
        Discard

   proof-of-delivery
        Discard

   Any unknown extensions should be discarded, irrespective of
   criticality.

   The original message should be included in the delivery port.  The
   original message will usually be available at the gateway, as
   discussed in Section 5.2.

5.3.8.2.  MTA Mappings

   The single 822-MTS recipient is constructed from
   MTA.ReportTransferEnvelope.report-destination-name, using the
   mappings of Chapter 4.  Unlike with a user message, this information
   is not available at the MTS level.

   The following additional mappings should be made:

   MTA.ReportTransferEnvelope.report-destination-name
        This should be used to generate the To: field.

   MTA.ReportTransferEnvelope.identifier
        Mapped to the extended RFC 822 field "X400-MTS-Identifier:".
        It may also be used to derive a "Message-Id:" field.

   MTA.ReportTransferEnvelope.trace-information
        and

   MTA.ReportTransferEnvelope.internal-trace-information
        Mapped onto the extended RFC 822 field "X400-Received:", as
        described in Section 5.3.7.  The first element should also
        be used to generate the "Date:" field, and the
        EBNF.failure-point.

      MTA.PerRecipientReportTransferFields.last-trace-information
      Mapped to EBNF.recipient-info (last trace)
      MTA.PerReportTransferFields.subject-intermediate-trace-information
      Mapped to EBNF.drc-field (subject-Intermediate-Trace-Information).
      These fields should be ordered so that the most recent trace element
      comes first.

5.3.8.3.  Example Delivery Report

   This is an example, of a moderately complex report.

   From: The Postmaster <postmaster@cs.ucl.ac.uk>
   To: jpo@computer-science.nottingham.ac.uk
   Subject: X.400 Delivery Report
   Message-Type: Delivery Report
   Date: Wed, 21 Jun 89 08:45:25 +0100
   X400-MTS-Identifier: /PRMD=UK.AC/ADMD=Gold 400/C=GB/;13412345235

   This report relates to your message:
     Date: Wed, 21 Jun 89 06:15:43 +0000
     Message-ID:  <8907140715.aa09015@CS.Nott.AC.UK>
     Subject: Now it's the fine tuning .... !
     To: Piete Brooks (Postmaster) <pb@computer-lab.cambridge.ac.uk>

   of Wed, 21 Jun 89 06:15:43 +0000

   It was generated by mta PK in /PRMD=UK/ADMD=DBP/C=DE/
   at Wed, 21 Jun 89 08:45:25 +0100

   It was later converted to RFC 822 by: Mail-Gateway@oxbridge.ac.uk
   at Wed, 21 Jun 89 08:45:26 +0100

   Your message was not delivered to: bad-user@nowhere
   for the following reason: Rendition problem with punctuation
           (Umlaut failure)

   -----------------------------------------------

   The following information is derived from the Report
   It may be useful for problem diagnosis:

   Subject-Submission-Identifier:
                          [/PRMD=UK.AC/ADMD=Gold 400/C=GB/;148996]
   Content-Identifier:  X.400 Delivery Report
   Content-Type: P2-1988 (22)
   Original-Encoded-Information-Types: ia5
   Content-Correlator: Date: Wed, 21 Jun 89 06:15:43 +0000
       Message-ID:  <8907140715.aa09015@CS.Nott.AC.UK>
       Subject: Now it's the fine tuning .... !
       To: Piete Brooks (Postmaster) <pb@computer-lab.cambridge.ac.uk>
   Recipient-Info:
       bad-user@nowhere, /S=bad-user/PRMD=nowhere/ADMD=DBP/C=DE/ ;
       FAILURE reason Physical-Rendition-Not-Performed (3) ;
       diagnostic Punctuation-Symbol-Loss (23) ;
       supplementary info Umlaut failure

   The Original Message follows:

   Subject: Now it's the fine tuning .... !
   Date: Wed, 21 Jun 89 06:15:43 +0000
   From: Julian Onions <jpo@computer-science.nottingham.ac.uk>
   To: Piete Brooks (Postmaster) <pb@computer-lab.cambridge.ac.uk>
   Cc: bad-user@nowhere
   Message-ID:  <8907140715.aa09015@CS.Nott.AC.UK>

   A short test

5.3.9.  Probe

   This is an MTS internal issue.  Any probe should be serviced by the
   gateway, as there is no equivalent RFC 822 functionality.  The value
   of the reply is dependent on whether the gateway could service an MTS
   Message with the values specified in the probe.  The reply should
   make use of MTS.SupplementaryInformation to indicate that the probe
   was serviced by the gateway.

Appendix A - Differences with RFC 987

   This appendix summarises changes between this document and RFC
   987/RFC 1026.

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 O/R 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 B - Mappings specific to the JNT Mail

   This Appendix is specific to the JNT Mail Protocol.  It describes
   specific changes in the context of this protocol.

1.  Introduction

   There are five aspects of a gateway which are JNT Mail Specific.
   These are each given a section of this appendix.

2.  Domain Ordering

   When interpreting and generating domains, the UK NRS domain ordering
   must be used.

3.  Acknowledge-To:

   This field has no direct functional equivalent in X.400.  However, it
   can be supported to an extent, and can be used to improve X.400
   support.

   If an Acknowledge-To: field is present when going from JNT Mail to
   X.400, MTS.PerRecipientSubmissionFields.originator-request-
   report.report shall be set for each recipient.  If there is more that
   one address in the Acknowledge-To: field, or if the one address is
   not equivalent to the 822-MTS return address, then:

      1.   Acknowledgement(s) should be generated by the gateway.  The
           text of these acknowledgements should indicate that they are
           generated by the gateway.

      2.   The Acknowledge-To: field should also be passed as an
           extension heading.

   When going from X.400 to JNT Mail, in cases where
   MTA.PerRecipientMessageTransferFields.per-recipient-indicators.
   originator-report is set, the copy of the message to that recipient
   should have an Acknowledge-To: field containing the
   MTS.OtherMessageDeliveryFields.originator-name.  No special treatment
   should be given when MTA.PerRecipientMessageTransferFields.per-
   recipient-indicators.  originating-MTA-report is set.  No attempt
   should be made to map Receipt notification requests onto
   Acknowledge-To:, as no association can be guaranteed between IPMS and
   MTS level addressing information.

4.  Trace

   JNT Mail trace uses the Via: syntax.  When going from JNT Mail to
   X.400, a mapping similar to that for Received:  is used. No
   MTS.GlobalDomainIdentifier of the site making the trace can be
   derived from the Via:, so a value for the gateway should be used.
   The trace text, including the "Via:", should be unfolded, truncated
   to MTS.ub-mta-name-length (32), and mapped to
   MTA.InternalTraceInformationElement.mta-name.  There is no JNT Mail
   specific mapping for the reverse direction.

5.  Timezone specification

   The extended syntax of zone defined in the JNT Mail Protocol should
   be used in the mapping of UTCTime defined in Chapter 3.

6.  Lack of 822-MTS originator specification

   In JNT Mail the default mapping of the
   MTS.OtherMessageDeliveryFields.originator-name is to the Sender:
   field.  This can cause a problem when going from X.400 to JNT Mail if
   the mapping of IPMS.Heading has already generated a Sender: field.
   To overcome this, new extended JNT Mail field is defined.  This is
   chosen to align with the JNT recommendation for interworking with

   full RFC 822 systems [Kille84b].

      original-sender     = "Original-Sender" ":" mailbox

   If an IPM has no IPMS.Heading.authorising-users component and
   IPMS.Heading.originator.formal-name is different from
   MTS.OtherMessageDeliveryFields.originator-name, map
   MTS.OtherMessageDeliveryFields.originator-name, onto the Sender:
   field.

   If an IPM has a IPMS.Heading.authorising-users component, and
   IPMS.Heading.originator.formal-name is different from
   MTS.OtherMessageDeliveryFields.originator-name,
   MTS.OtherMessageDeliveryFields.originator-name should be mapped onto
   the Sender: field, and IPMS.Heading.originator mapped onto the
   Original-Sender: field.

   In other cases the MTS.OtherMessageDeliveryFields.originator-name, is
   already correctly represented.

Appendix C - Mappings specific to UUCP Mail

   Gatewaying of UUCP and X.400 is handled by first gatewaying the UUCP
   address into RFC 822 syntax (using RFC 976) and then gatewaying the
   resulting RFC 822 address into X.400.  For example, an X.400 address:

      Country         US
      Organisation    Xerox
      Personal Name   John Smith

   might be expressed from UUCP as

      inthop!gate!gatehost.COM!/C=US/O=Xerox/PN=John.Smith/

   (assuming gate is a UUCP-Internet gateway and gatehost.COM is an
   Internet-X.400 gateway) or

      inthop!gate!Xerox.COM!John.Smith

   (assuming that Xerox.COM and /C=US/O=Xerox/ are equivalent.)

   In the other direction, a UUCP address Smith@ATT.COM, integrated into
   822, would be handled as any other 822 address.  A non-integrated
   address such as inthop!dest!user might be handled through a pair of
   gateways:

      Country         US
      ADMD            ATT

      PRMD            Internet
      Organisation    GateOrg
      RFC-822         inthop!dest!user@gatehost.COM

   or through a single X.400 to UUCP gateway:

      Country         US
      ADMD            ATT
      PRMD            UUCP
      Organisation    GateOrg
      RFC-822         inthop!dest!user

Appendix D - Object Identifier Assignment

   An object identifier is needed for the extension IPMS element.  The
   following value should be used.

      rfc-987-88 OBJECT IDENTIFIER ::=
          {ccitt data(9) pss(2342) ucl(234219200300) rfc-987-88(200)}

      id-rfc-822-field OBJECT IDENTIFIER ::= {rfc987-88 field(0)}

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

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


   object-identifier ::= [ defined-value ] oid-comp-list

   oid-comp-list ::= oid-comp oid-comp-list
                   | oid-comp

   defined-value ::= key-string

   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"
                   / registered-dd-type
                   / dd-key "." std-printablestring
   standard-type   = key-string

   registered-dd-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


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


   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-and-mta ";"  ]
                       action-list
                       ";" arrival-time

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


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


   dr-body-format = dr-summary <CRLF>
                    dr-recipients <CRLF>
                    dr-extra-information <CRLF>
                    dr-content-return


   dr-content-return = "The Original Message is not available"
                   / "The Original Message follows:"
                     <CRLF> <CRLF> message

   dr-summary = "This report relates to your message:" <CRLF>
                   content-correlator <CRLF> <CRLF>
                "of" date-time <CRLF> <CRLF>
                "It was generated by:" report-point <CRLF>
                "at" date-time <CRLF> <CRLF>
                "It was later converted to RFC 822 by:" mailbox <CRLF>
                "at" 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


   dr-extra-information =
    "-----------------------------------------------" <CRLF> <CRLF>
    "The following information is derived from the Report" <CRLF>

    "It may be useful for problem diagnosis:" <CRLF> <CRLF>
   drc-field-list

   drc-field-list       = *(drc-field <CRLF>)

   drc-field = "Subject-Submission-Identifier" ":"
                                   mts-msg-id
             / "Content-Identifier" ":" printablestring
             / "Content-Type" ":" mts-content-type
             / "Original-Encoded-Information-Types" ":"
                           encoded-info
             / "Originator-and-DL-Expansion-History" ":"
                           dl-history
             / "Reporting-DL-Name" ":" mailbox
             / "Content-Correlator" ":" content-correlator
             / "Recipient-Info" ":" recipient-info


   recipient-info  = mailbox "," std-or ";"
                   report-type
                   [ "converted eits" encoded-info ";" ]
                   [ "originally intended recipient"
                           mailbox "," std-or ";" ]
                   [ "supplementary info" <"> printablestring <"> ";" ]
                   [ "redirection history" 1#redirection ";"
                   [ "physical forwarding address"
                                         printablestring ";" ]


   report-type     = "SUCCESS" drc-success
                   / "FAILURE" drc-failure

   drc-success     = "delivered at" date-time ";"
                   [ "type of MTS user" labelled-integer ";" ]

   drc-failure     = "reason" labelled-integer ";"
                   [ "diagnostic" labelled-integer ";" ]


   report-point = [ "mta" word "in" ] global-id
   content-correlator = *word
   dl-history = 1#( mailbox "(" date-time ")")


   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
             / "Content-Identifier" ":" printablestring
             / "Priority" ":" priority
             / "Originator-Return-Address" ":" 1#mailbox
             / "DL-Expansion-History" ":" mailbox ";" date-time ";"
             / "Redirection-History" ":" redirection
             / "Conversion" ":" prohibition
             / "Conversion-With-Loss" ":" prohibition
             / "Requested-Delivery-Method" ":"
                             1*( labelled-integer )
             / "Delivery-Date" ":" date-time
             / "Discarded-X400-MTS-Extensions" ":"
                             1#( oid / labelled-integer )


   prohibition     = "Prohibited" / "Allowed"

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

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

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

   redirection     = mailbox ";" "reason" "="
                           redirection-reason
                           ";" date-time
   redirection-reason =
             "Recipient Assigned Alternate Recipient"
           / "Originator Requested Alternate Recipient"
           / "Recipient MD Assigned Alternate Recipient"


   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:"
                   <CRLF> <CRLF> message


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


   non-receipt-reason = "Discarded" / "Auto-Forwarded"

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

   acknowledgement-mode = "Manually" / "Automatically"


   ms-field = "Obsoletes" ":" 1#msg-id
            / "Expiry-Date" ":" date-time
            / "Reply-By" ":" date-time
            / "Importance" ":" importance
            / "Sensitivity" ":" sensitivity
            / "Autoforwarded" ":" boolean
            / "Incomplete-Copy" ":"
            / "Language" ":" language
            / "Message-Type" ":" message-type
            / "Discarded-X400-IPMS-Extensions" ":" 1#oid

   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"


Appendix F - Format of address mapping tables

   There is a need to specify the association between the domain and
   X.400 namespaces described in Chapter 4.  The use of this association
   leads to a better service on both sides of the gateway, and so
   defining mappings and distributing them in the form defined in this
   appendix is strongly encouraged.

   This syntax defined is initially in table form, but the syntax is
   defined in a manner which makes it suitable for use with domain
   nameservices (such as the Internet Domain nameservers or the UK NRS).
   The mapping is not symmetric, and so a separate table is specified
   for each direction.  If multiple matches are possible, the longest
   possible match should be used.

   First, an address syntax is defined, which is compatible with the
   syntax used for 822.domains.  It is intended that this syntax may be
   used in conjunction with systems which support this form of name.

   To allow the mapping of null attributes  to be represented, 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 )
      dmn-part        = attribute "$" value
      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 the second
   omission of the ADMD level.

   Various further restrictions are placed on the usage of dmn-or-
   address:

   1.   Only C, ADMD, PRMD, O, and OU may be used.

   2.   There must be a strict ordering of all components, with the
        most significant components on the RHS.

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

   For domain -> X.400:

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

   Note that the trailing "#" is used for clarity, as the dmn-or-
   address syntax can lead to values with trailing blanks.   Lines
   staring 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#

   For X.400 -> domain:

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

      For example:

      #
      # Mapping table

      #
      PRMD$UK.AC.ADMD$GOLD 400.C$GB#AC.UK#

References

   [Braden89a]  Braden, R., Editor, "Requirements for Internet Hosts --
   Application and Support", RFC 1123, USC/Information Sciences
   Institute, October 1989.

   [CCITT88a]  CCITT, "CCITT Recommendations X.408", Message Handling
   Systems: Encoded Information Type Conversion Rules, CCITT, December
   1988.

   [CCITT/ISO88a]  CCITT/ISO, "CCITT Recommendations X.400/ ISO IS
   10021-1", Message Handling: System and Service Overview, CCITT/ISO,
   December 1988.

   [CCITT/ISO88b]  CCITT/ISO, "CCITT Recommendations X.420/ ISO IS
   10021-7", Message Handling Systems: Interpersonal Messaging System,
   CCITT/ISO, December 1988.

   [CCITT/ISO88c]  CCITT/ISO, "CCITT Recommendations X.411/ ISO IS
   10021-4", Message Handling Systems: Message Transfer System: Abstract
   Service Definition and Procedures, CCITT/ISO, December 1988.

   [CCITT/ISO88d]  CCITT/ISO, "Specification of Abstract Syntax Notation
   One (ASN.1)", CCITT Recommendation X.208 / ISO IS 8824, CCITT/ISO,
   December 1988.

   [Crocker82a]  Crocker, D., "Standard of the Format of ARPA Internet
   Text Messages", RFC 822, August 1982.

   [Horton86a]  Horton, M., "UUCP Mail Interchange Format Standard", RFC
   976, February 1986.

   [Kille84b]  Kille, S., "Gatewaying between RFC 822 and JNT Mail", JNT
   Mailgroup Note 15, May 1984.

   [Kille84a]  Kille, S., Editor, "JNT Mail Protocol (revision 1.0)",
   Joint Network Team, Rutherford Appleton Laboratory, March 1984.

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

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

   [Kille89a]  Kille, S., "A String Encoding of Presentation Address",

   UCL Research Note 89/14, March 1989.

   [Kille89b]  Kille, S., "Mapping Between Full RFC 822 and RFC 822 with
   Restricted Encoding", RFC 1137, December 1989.

   [Larmouth83a]  Larmouth, J., "JNT Name Registration Technical Guide",
   Salford University Computer Centre, April 1983.

   [Mockapetris87a]  Mockapetris, P., "Domain Names - Concepts and
   Facilities", RFC 1034, USC/Information Sciences Institute, November
   1987.

   [Postel82a]  Postel, J., "Simple Mail Transfer Protocol", RFC 821,
   USC/Information Sciences Institute, August 1982.

   [Rose85a]  Rose M., and E. Stefferud, "Proposed Standard for Message
   Encapsulation", RFC 934, January 1985.

   [Systems85a]  CEN/CENELEC/Information Technology/Working Group on
   Private Message Handling Systems, "FUNCTIONAL STANDARD A/3222",
   CEN/CLC/IT/WG/PMHS N 17, October 1985.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Steve Kille
   University College London
   Gower Street
   WC1E 6BT
   England

   Phone: +44-1-380-7294

   EMail: S.Kille@Cs.Ucl.AC.UK