idnits 2.17.1 draft-zimmerer-mmusic-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 is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 29 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-mmusic-sip-isup-mime-00.txt Aparna Vemuri 4 August 1999 Level 3 Communications 5 Expires: February 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-Type: Application/ Multipart 107 Content-Length: 327 109 MIME-Version: 1.0 110 Content-Type: multipart/mixed; boundary=unique-boundary-1 112 --unique-boundary-1 113 Content-Type: application/SDP; charset=ISO-10646 115 v=0 116 o=ezimmerer 2890844526 2890842807 IN IP4 126.16.64.4 117 s=SDP seminar 118 c=IN IP4 MG122.level3.com 119 t= 2873397496 2873404696 120 m=audio 9092 RTP/AVP 0 3 4 122 --unique-boundary-1 123 Content-type:application/ISUP; Version:ETSI1 124 Content-Transfer-Encoding: binary 126 89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00 128 --unique-boundary-1-- 129 5. Security considerations 131 The security mechanisms described in RFC 2543 (SIP - Session 132 Initiation Protocol) should suffice. No new security considerations 133 are thought necessary. 135 6. Authors 137 Eric Zimmerer 138 ipVerse, Inc. 139 1901 Landings Drive 140 Mountain View, CA 94043, USA 141 Phone: 650-919-0648 142 Email: ericz@ipverse.com 144 Aparna Vemuri 145 Level 3 Communications 146 Louisville, CO, USA 147 Phone: 303-926-3768 148 EMail: aparna.vemuri@level3.com 150 7. References 152 [1] Freed, Klensin, Postel, "Multipart Internet Mail Extensions (MIME) 153 Part Four: Registration Procedures" RFC 2048, Internet Engineering 154 Task Force, November 1996. 156 [2] Handley, Schulzrinne, Schooler and Rosenberg, "Session Initiation 157 Protocol (SIP)" RFC 2543, Internet Engineering Task Force, March 1999. 159 [3] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME) Part 160 One: Format of Internet Message Bodies" RFC 2045, Internet Engineering 161 Task Force, November 1996. 163 [4] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME) Part 164 Two: Media Types" RFC 2046, Internet Engineering Task Force, November 165 1996.