Network Working Group                                            M. Wahl
INTERNET-DRAFT                                          ISODE Consortium
Expires in six months from                              23 February 1996
Intended Category: Informational


                    A MIME Content-Type for ASN.1 PDUs
                    <draft-ietf-asid-mime-ber-00.txt>

1.  Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing  contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

2.  Abstract

   The Basic Encoding Rules (BER) [1] are a transfer syntax used in
   several Internet communications protocols, including LDAP [2] and
   SNMP [3]. This document describes how a series of BER-encoded PDUs
   can be represented in a MIME [4] content type.  This may be used to
   transport a side of a communications protocol over protocols
   which carry MIME contents, such as SMTP [5].

3.  MIME Type Registration

   To: ietf-types@uninett.no, IANA@isi.edu
   Subject: Registration of MIME Media Type application/ber-stream

3.1 MIME media type name

   application

3.2 MIME subtype name

   ber-stream

3.3 Required parameters

   protocol


INTERNET-DRAFT     A MIME Content Type for ASN.1 PDUs     February 1996

3.3.1 Required parameter "protocol"

   The "protocol" parameter contains the dotted decimal representation
   of an OBJECT IDENTIFIER.  The OBJECT IDENTIFIER uniquely identifies
   the protocol in which the types for the data values included in the
   content are defined.

   The OBJECT IDENTIFIER must be one that has been defined by one of the
   following procedures:

    - all existing protocols which operate directly above TCP or UDP
      with a well known port number assigned by the IANA have an
      identifier already defined.  A protocol over TCP has an identifier
      of the form <applTCPProtoID>.<port>, and a protocol over UDP has
      an identifier of the form <applUDPProtoID>.<port>, where
      applTCPProtoID and applUDPProtoID are defined in RFC 1565 [6], and
      port is the TCP or UDP port number. For example, LDAP [2] would
      have the following protocol:  1.3.6.1.2.1.27.4.389

    - an enterprise (e.g. an organization) which has been assigned a
      SMI network management private enterprise code by the IANA may
      use this as a prefix for defining their own protocols.  For
      example, if an enterprise was assigned private enterprise code
      1466 by IANA, they might define their protocols as
      1.3.6.1.4.1.1466.1, 1.3.6.1.4.1.1466.2, 1.3.6.1.4.1.1466.3 etc.

    - Protocols assigned under arcs managed or delegated by ISO/ITU are
      also permitted.   (E.g. An organization which has an ANSI OBJECT
      IDENTIFER assigned to it may use theirs as a prefix.)

   To aid interoperability, unassigned identifiers are not permitted,
   and nonnumeric string representations of identifier components must
   not be used.

3.4 Optional parameters

   references

3.4.1 Optional parameter "references"

   The "references" parameter contains a <msg-id> which is a Content-ID
   of another MIME content to which this one refers.  This parameter is
   not the Content-ID of this content; the Content-ID of this content is
   carried in the "Content-ID" header field as is normal for MIME.

   If the protocol is a request-response interaction, in the request
   content the "references" parameter should be absent, and a Content-ID
   should be present, and in the response content the "references"
   parameter should hold the Content-ID of the request content.


INTERNET-DRAFT     A MIME Content Type for ASN.1 PDUs     February 1996

3.5  Encoding considerations

   As specified by the Content-Transfer-Encoding header field.
   "application/ber-stream" will need a Content-Transfer-Encoding of
   base64 or quoted-printable when carried in 7-bit MIME, since the
   output of BER uses the full range of possible byte values.  It is
   recommended that base64 be generated.

3.6 Security considerations

   Unless the content is protected using mechanisms such as those
   defined in MOSS [7], it is subject to viewing and modification in
   transit.  If a request-response protocol is being used over mail, it
   will be subject to the same attacks as a connectionless transport
   mechanism (such as replay).

3.7 Interoperability considerations:

   The protocol which is referenced by the "protocol" parameter defines
   the ASN.1 types for the data values.  It also defines the valid
   ordering of the data values in a content: for example that a bind PDU
   must come first, followed by zero or more request PDUs, followed by
   an unbind PDU.  A protocol may also limit the subset of BER which may
   be used to encode the values.  For example, the LDAP [2] protocol
   forbids a number of possible encodings, including constructed
   encodings for strings.

3.8 Published specification:

   The "application/ber-stream" contains a series of zero or more ASN.1
   data values.  Each data value is encoded according to the Basic
   Encoding Rules (BER).  As each BER PDU is self-delimiting, multiple
   data values may be concatenated.  Note however that when there is
   more than one encoded data value in a content, there is NO tag or
   length octets concerning the content as a whole.  ASN.1 and BER are
   defined in International Standards and ITU Recommendations.

3.9 Person & email address to contact for further information:

   Mark Wahl
   ISODE Consortium Inc.
   3925 West Braker Lane #333
   Austin TX 78759
   USA
   M.Wahl@isode.com

3.10 Author/Change controller:

   Mark Wahl
   ISODE Consortium Inc.
   3925 West Braker Lane #333
   Austin TX 78759
   USA
   M.Wahl@isode.com


INTERNET-DRAFT     A MIME Content Type for ASN.1 PDUs     February 1996

4.  Example

   In this example an SNMP trap is carried as part of an email message.
   This protocol is identified by an OBJECT IDENTIFIER based on UDP port
   162 (assigned in RFC 1157).  The content of the
   application/ber-stream is the base64 representation of a BER encoding
   of a single ASN.1 data value, of type RFC1157-SNMP.Message.  The
   Message.data would contain a "PDUs" value of choice "trap".


        To: manager@nic.any.net
        From: manager@nic.another.net
        Subject: FYI your router rebooted
        Content-Type: multipart/mixed; boundary="woowoo"
        MIME-Version: 1.0

        --woowoo
        Content-Type: text/plain

        Your router rebooted yesterday.  When it restarted it sent this
        trap to my management station.  You may wish to take a look at
        it.

        --woowoo
        Content-Type: application/ber-stream;
         protocol="1.3.6.1.2.1.27.5.162"
        Content-Transfer-Encoding: base64

        MB8CAQAEAKQYBgUownoFAUAEfwAAAQIBAAIBAEMBADAA
        --woowoo--

5.  Security Considerations

   Security considerations are discussed in the "Security
   considerations" section (3.6) of the MIME media type request.

6.  Bibliography

   [1] Specification of Basic Encoding Rules for Abstract Syntax
       Notation One (ASN.1).  CCITT Recommendation X.209, 1988.

   [2] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access
       Protocol", RFC 1777, March 1995.

   [3] M. Schoffstall, M. Fedor, J. Davin, J. Case, "A Simple Network
       Management Protocol (SNMP)", RFC 1157, May 1990.

   [4] N. Borenstein, N. Freed, "MIME  (Multipurpose Internet Mail
       Extensions) Part One:  Mechanisms for Specifying and Describing
       the Format of Internet Message Bodies", RFC 1521, September 1993.

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


INTERNET-DRAFT     A MIME Content Type for ASN.1 PDUs     February 1996

   [6] N. Freed, S. Kille, "Network Services Monitoring MIB", RFC 1565,
       January 1994.

   [7] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security
       Services", RFC 1848, October 1995.

7.  Author's Address

   Mark Wahl
   ISODE Consortium Inc.
   3925 West Braker Lane #333
   Austin TX 78759
   USA

   Phone: +1 (512) 305 0280
   Email: M.Wahl@isode.com