idnits 2.17.1 draft-ietf-asid-mime-ber-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2], [3], [4], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 22 has weird spacing: '...listing conta...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (23 February 1996) is 10287 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 193 looks like a reference -- Missing reference section? '2' on line 196 looks like a reference -- Missing reference section? '3' on line 199 looks like a reference -- Missing reference section? '4' on line 202 looks like a reference -- Missing reference section? '5' on line 206 looks like a reference -- Missing reference section? '6' on line 209 looks like a reference -- Missing reference section? '7' on line 212 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Wahl 2 INTERNET-DRAFT ISODE Consortium 3 Expires in six months from 23 February 1996 4 Intended Category: Informational 6 A MIME Content-Type for ASN.1 PDUs 7 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 2. Abstract 29 The Basic Encoding Rules (BER) [1] are a transfer syntax used in 30 several Internet communications protocols, including LDAP [2] and 31 SNMP [3]. This document describes how a series of BER-encoded PDUs 32 can be represented in a MIME [4] content type. This may be used to 33 transport a side of a communications protocol over protocols 34 which carry MIME contents, such as SMTP [5]. 36 3. MIME Type Registration 38 To: ietf-types@uninett.no, IANA@isi.edu 39 Subject: Registration of MIME Media Type application/ber-stream 41 3.1 MIME media type name 43 application 45 3.2 MIME subtype name 47 ber-stream 49 3.3 Required parameters 51 protocol 52 3.3.1 Required parameter "protocol" 54 The "protocol" parameter contains the dotted decimal representation 55 of an OBJECT IDENTIFIER. The OBJECT IDENTIFIER uniquely identifies 56 the protocol in which the types for the data values included in the 57 content are defined. 59 The OBJECT IDENTIFIER must be one that has been defined by one of the 60 following procedures: 62 - all existing protocols which operate directly above TCP or UDP 63 with a well known port number assigned by the IANA have an 64 identifier already defined. A protocol over TCP has an identifier 65 of the form ., and a protocol over UDP has 66 an identifier of the form ., where 67 applTCPProtoID and applUDPProtoID are defined in RFC 1565 [6], and 68 port is the TCP or UDP port number. For example, LDAP [2] would 69 have the following protocol: 1.3.6.1.2.1.27.4.389 71 - an enterprise (e.g. an organization) which has been assigned a 72 SMI network management private enterprise code by the IANA may 73 use this as a prefix for defining their own protocols. For 74 example, if an enterprise was assigned private enterprise code 75 1466 by IANA, they might define their protocols as 76 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. 78 - Protocols assigned under arcs managed or delegated by ISO/ITU are 79 also permitted. (E.g. An organization which has an ANSI OBJECT 80 IDENTIFER assigned to it may use theirs as a prefix.) 82 To aid interoperability, unassigned identifiers are not permitted, 83 and nonnumeric string representations of identifier components must 84 not be used. 86 3.4 Optional parameters 88 references 90 3.4.1 Optional parameter "references" 92 The "references" parameter contains a which is a Content-ID 93 of another MIME content to which this one refers. This parameter is 94 not the Content-ID of this content; the Content-ID of this content is 95 carried in the "Content-ID" header field as is normal for MIME. 97 If the protocol is a request-response interaction, in the request 98 content the "references" parameter should be absent, and a Content-ID 99 should be present, and in the response content the "references" 100 parameter should hold the Content-ID of the request content. 102 3.5 Encoding considerations 104 As specified by the Content-Transfer-Encoding header field. 105 "application/ber-stream" will need a Content-Transfer-Encoding of 106 base64 or quoted-printable when carried in 7-bit MIME, since the 107 output of BER uses the full range of possible byte values. It is 108 recommended that base64 be generated. 110 3.6 Security considerations 112 Unless the content is protected using mechanisms such as those 113 defined in MOSS [7], it is subject to viewing and modification in 114 transit. If a request-response protocol is being used over mail, it 115 will be subject to the same attacks as a connectionless transport 116 mechanism (such as replay). 118 3.7 Interoperability considerations: 120 The protocol which is referenced by the "protocol" parameter defines 121 the ASN.1 types for the data values. It also defines the valid 122 ordering of the data values in a content: for example that a bind PDU 123 must come first, followed by zero or more request PDUs, followed by 124 an unbind PDU. A protocol may also limit the subset of BER which may 125 be used to encode the values. For example, the LDAP [2] protocol 126 forbids a number of possible encodings, including constructed 127 encodings for strings. 129 3.8 Published specification: 131 The "application/ber-stream" contains a series of zero or more ASN.1 132 data values. Each data value is encoded according to the Basic 133 Encoding Rules (BER). As each BER PDU is self-delimiting, multiple 134 data values may be concatenated. Note however that when there is 135 more than one encoded data value in a content, there is NO tag or 136 length octets concerning the content as a whole. ASN.1 and BER are 137 defined in International Standards and ITU Recommendations. 139 3.9 Person & email address to contact for further information: 141 Mark Wahl 142 ISODE Consortium Inc. 143 3925 West Braker Lane #333 144 Austin TX 78759 145 USA 146 M.Wahl@isode.com 148 3.10 Author/Change controller: 150 Mark Wahl 151 ISODE Consortium Inc. 152 3925 West Braker Lane #333 153 Austin TX 78759 154 USA 155 M.Wahl@isode.com 156 4. Example 158 In this example an SNMP trap is carried as part of an email message. 159 This protocol is identified by an OBJECT IDENTIFIER based on UDP port 160 162 (assigned in RFC 1157). The content of the 161 application/ber-stream is the base64 representation of a BER encoding 162 of a single ASN.1 data value, of type RFC1157-SNMP.Message. The 163 Message.data would contain a "PDUs" value of choice "trap". 165 To: manager@nic.any.net 166 From: manager@nic.another.net 167 Subject: FYI your router rebooted 168 Content-Type: multipart/mixed; boundary="woowoo" 169 MIME-Version: 1.0 171 --woowoo 172 Content-Type: text/plain 174 Your router rebooted yesterday. When it restarted it sent this 175 trap to my management station. You may wish to take a look at 176 it. 178 --woowoo 179 Content-Type: application/ber-stream; 180 protocol="1.3.6.1.2.1.27.5.162" 181 Content-Transfer-Encoding: base64 183 MB8CAQAEAKQYBgUownoFAUAEfwAAAQIBAAIBAEMBADAA 184 --woowoo-- 186 5. Security Considerations 188 Security considerations are discussed in the "Security 189 considerations" section (3.6) of the MIME media type request. 191 6. Bibliography 193 [1] Specification of Basic Encoding Rules for Abstract Syntax 194 Notation One (ASN.1). CCITT Recommendation X.209, 1988. 196 [2] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access 197 Protocol", RFC 1777, March 1995. 199 [3] M. Schoffstall, M. Fedor, J. Davin, J. Case, "A Simple Network 200 Management Protocol (SNMP)", RFC 1157, May 1990. 202 [4] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail 203 Extensions) Part One: Mechanisms for Specifying and Describing 204 the Format of Internet Message Bodies", RFC 1521, September 1993. 206 [5] D. Crocker, "Standard for the format of ARPA Internet text 207 messages", RFC 822, August 1982. 209 [6] N. Freed, S. Kille, "Network Services Monitoring MIB", RFC 1565, 210 January 1994. 212 [7] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security 213 Services", RFC 1848, October 1995. 215 7. Author's Address 217 Mark Wahl 218 ISODE Consortium Inc. 219 3925 West Braker Lane #333 220 Austin TX 78759 221 USA 223 Phone: +1 (512) 305 0280 224 Email: M.Wahl@isode.com