idnits 2.17.1 draft-ietf-sigtran-mime-isup-00.txt: 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: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 2, 1999) is 9032 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 100, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 104, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 108, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 112, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 116, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 119, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2234 (ref. '5') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2048 (ref. '6') (Obsoleted by RFC 4288, RFC 4289) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Christian Huitema 3 INTERNET DRAFT Bellcore 4 February 2, 1999 Expires August 2, 1999 5 7 The application/ISUP media type 9 Status of this document 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference material 21 or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 26 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 27 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 This document proposes the definition of an application/ISUP media type, 32 according to the rules defined in RFC 2048. 34 1. Motivation 36 Many signalling exchanges between telephony switches follow the "ISDN 37 User Part of Signalling System No. 7" (ISUP), that the ITU defines in 38 recommendation Q.761, Q.762, Q.763 and Q.764, or one of its national 39 variants. As gateways between the Internet and the public, there is a 40 need to transport ISUP messages as "content" or "body parts" of Internet 41 messages. 43 This memo proposes a definition of an "application/ISUP" media type, 45 Huitema [Page 1[]] 46 Internet draft The application/ISUP media type February 2, 1999 48 according to the rules defined in RFC 2048. 50 This memo does not attempt to define when and how such messages could be 51 used. 53 2. The application/isup media type 55 The corresponding media type is defined by the following information: 57 Media Type name: application 58 Media subtype name: ISUP 59 Required parameters: none 60 Optional parameters: variant, headers 61 Encoding considerations: binary or base64 62 Security considerations: see section 5. 63 Published specification: ITU recommendation Q.763 65 The variant parameter is used to denote the presence of a "national 66 variant" of the ISUP protocol. The syntax of this parameter is defined 67 by the following ABNF notations (as defined in RFC 2234): 69 parameter = "content" "=" value 70 value = DQUOTE national-variant-code DQUOTE 72 The national variant code is normally set to the 2 upper case letter 73 country-code of the nation defining the variant, such as "BR" for Bra- 74 zil. 76 The format of the ISUP message is specified in Q.763. Messages confor- 77 maing to this specification include five parts: the Routing label, the 78 Circuit identification code, the Message type code, the Mandatory fixed 79 part, the Mandatory variable part and the Optional part. The "headers" 80 parameter is used to identify whether the body part includes the Routing 81 label and the Circuit Identification Code (CIC). The syntax of this 82 parameter is defined by the following ABNF notations: 84 parameter = "header" "=" header-value 85 header-value = (DQUOTE "routing" DQUOTE) 86 / (DQUOTE "CIC" DQUOTE) 87 / (DQUOTE "none" DQUOTE) 89 The value "routing" indicates that both the routing label and the CIC 90 are included in the body part. The value "CIC" indicates that the rout- 91 ing label is not included, but that the CIC is included. The value 92 "none" indicates that neither the routing lable nor the CIC are 93 included. 95 Huitema [Page 2[]] 96 Internet draft The application/ISUP media type February 2, 1999 98 3. References 100 [1] ITU-T, Recommendation Q.761, "Functional Description of the ISDN 101 User Part of Signalling System No. 7", (Malaga-Torremolinos, 1984; 102 modified at Helsinki, 1993) 104 [2] ITU-T, Recommendation Q.762, "General Function of Messages and Sig- 105 nals of the ISDN User Part of Signalling System No. 7", (Malaga- 106 Torremolinos, 1984; modified at Helsinki, 1993) 108 [3] ITU-T, Recommendation Q.763, "Formats and Codes of the ISDN User 109 Part of Signalling System No. 7", (Malaga-Torremolinos, 1984; modi- 110 fied at Helsinki, 1993) 112 [4] ITU-T, Recommendation Q.764, "Formats and Codes of the ISDN User 113 Part of Signalling System No. 7, ISDN User Part Signalling Pro- 114 cedures", (Malaga-Torremolinos, 1984; modified at Helsinki, 1993) 116 [5] Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications: 117 ABNF", RFC 2234, November 1997. 119 [6] Freed, N., J. Klensin, J. Postel. "Multipurpose Internet Mail 120 Extensions (MIME) Part Four: Registration Procedures." RFC 2048, 121 November 1996. 123 4. Authors' Addresses 125 Christian Huitema 126 Bellcore 127 MCC 1J236B 128 445 South Street 129 Morristown, NJ 07960 130 U.S.A. 132 Phone: +1 973-829-4266 133 EMail: huitema@bellcore.com 135 Huitema [Page 3[]]