idnits 2.17.1 draft-zimmerer-sip-isup-mime-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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 28 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 30 has weird spacing: '...ocument propo...' == Line 69 has weird spacing: '... if the parti...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2048 (ref. '1') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2543 (ref. '2') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Eric Zimmerer 2 Internet Draft ipVerse, Inc. 3 draft-zimmerer-sip-isup-mime-00.txt Aparna Vemuri 4 October 1999 Level 3 Communications 5 Expires: April 2000 7 The SIP ISUP/MIME type 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 1. Abstract 30 This document proposes the definition of an application/ISUP media 31 type, according to the rules defined in RFC 2048 [1]. 33 2. Introduction 35 ISUP (ISDN User part) defined in the ITU-T recommendations Q.761-4 is 36 a signaling protocol used between telephony switches. There exists a 37 need to transport ISUP messages between SoftSwitches as being part of 38 the payload of SIP [2] messages. The following discussion is specific 39 to this usage and would not apply to the transportation of ISUP 40 messages in other applications. 42 3. The application/ISUP media type 44 The ISUP messages are composed of arbitrary binary data. The best way 45 to encode these would be to use binary encoding. This is in 46 conformance with the restrictions imposed on the use of binary data 47 conformance with the restrictions imposed on the use of binary data 48 for MIME (RFC 2045 [3]). It should be noted that the rules mentioned 49 in the RFC 2045 apply to Internet mail messages and not to SIP 50 messages. Binary has been preferred over Base64 encoding because 51 the latter would only result in adding bulk to the encoded messages 52 as well as prove costly in terms of processing power. 53 This media type is defined by the following information: 55 Media type name: application 56 Media subtype name: ISUP 57 Required parameters: none 58 Optional parameters: version 59 Encoding scheme: binary 60 Security considerations: See section 5. 62 Note: It is mandatory for SoftSwitches to specify the 'version' of 63 the ISUP message. Proxies, redirect servers, etc., have no need to 64 process/specify this information. 66 The use of the 'version' parameter allows differentiation between 67 different ISUP variants. This enables the terminating SoftSwitch (also 68 known as media gateway) to recognize and parse the message correctly, 69 or (possibly) to reject the message if the particular ISUP variant is 70 not supported. The idea here is to allow to specify a preference of 71 version, so that the following scenarios are possible: "I only like 72 application/isup;version=lcd" or "I accept application/isup (but don't 73 really know the details; I just pass them on to some other tool that 74 displays/munges them)". 75 The following is how a typical header would look:- 77 Content-Type: application/ISUP; Version=ETSI1 78 Content-Transfer-Encoding: binary 80 Table 1 is a partial list of protocol versions supported by the 81 'application/ISUP' media type. 83 Version Protocol 84 ------- -------- 85 ANSI ANSI ISUP 86 ETSI1 ETSI ISUP v1 87 ETSI2 ETSI ISUP v2 88 GR317 Bellcore ISUP GR-317 89 4. Illustrative example 91 SIP message format requires a Request line followed by Header lines 92 followed by a CRLF separator followed by the message body. To 93 illustrate the use of the 'application/ISUP' media type, below is 94 an INVITE message which has the originating SDP information and 95 an encapsulated ISUP IAM. 97 Note that the two payloads are demarcated by the boundary parameter 98 (specified in RFC 2046 [4]) which in the example has the value 99 "unique-boundary-1". This is part of the specification of MIME 100 multipart and is not related to the 'application/ISUP' media type. 102 INVITE sip:13039263142@Den1.level3.com SIP/2.0 103 From: sip:13034513355@den3.level3.com 104 To: sip:13039263142@Den1.level3.com 105 Call-ID: DEN1231999021712095500999@Den1.level3.com 106 Content-Length: 377 107 Content-Type: multipart/mixed; boundary=unique-boundary-1 108 MIME-Version: 1.0 110 --unique-boundary-1 111 Content-Type: application/SDP; charset=ISO-10646 113 v=0 114 o=ezimmerer 2890844526 2890842807 IN IP4 126.16.64.4 115 s=SDP seminar 116 c=IN IP4 MG122.level3.com 117 t= 2873397496 2873404696 118 m=audio 9092 RTP/AVP 0 3 4 120 --unique-boundary-1 121 Content-type:application/ISUP; Version=ETSI1 122 Content-Transfer-Encoding: binary 124 89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00 125 --unique-boundary-1-- 127 Note: 128 Since binary encoding is used for the ISUP payload, each byte is encoded 129 as a byte, and not as a two-character hex representation. Hex digits were 130 used in the draft because a literal encoding of those bytes would have been 131 confusing and unreadable. 133 5. Security considerations 135 The security mechanisms described in RFC 2543 (SIP - Session 136 Initiation Protocol) should suffice. No new security considerations 137 are thought necessary. 139 6. Authors 141 Eric Zimmerer 142 ipVerse, Inc. 143 1901 Landings Drive 144 Mountain View, CA 94043, USA 145 Phone: 650-919-0648 146 Email: ericz@ipverse.com 148 Aparna Vemuri 149 Level 3 Communications 150 Louisville, CO, USA 151 Phone: 303-926-3768 152 EMail: aparna.vemuri@level3.com 154 7. References 156 [1] Freed, Klensin, Postel, "Multipart Internet Mail Extensions (MIME) 157 Part Four: Registration Procedures" RFC 2048, Internet Engineering 158 Task Force, November 1996. 160 [2] Handley, Schulzrinne, Schooler and Rosenberg, "Session Initiation 161 Protocol (SIP)" RFC 2543, Internet Engineering Task Force, March 1999. 163 [3] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME) Part 164 One: Format of Internet Message Bodies" RFC 2045, Internet Engineering 165 Task Force, November 1996. 167 [4] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME) Part 168 Two: Media Types" RFC 2046, Internet Engineering Task Force, November 169 1996.