idnits 2.17.1 draft-burger-sipping-msuri-01.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 259 has weird spacing: '...Service draf...' -- 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 (November 21, 2001) is 8189 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) -- Missing reference section? '1' on line 14 looks like a reference -- Missing reference section? '2' on line 231 looks like a reference -- Missing reference section? '3' on line 51 looks like a reference -- Missing reference section? '4' on line 101 looks like a reference -- Missing reference section? '6' on line 210 looks like a reference -- Missing reference section? '7' on line 243 looks like a reference -- Missing reference section? '8' on line 282 looks like a reference -- Missing reference section? '10' on line 244 looks like a reference -- Missing reference section? '9' on line 291 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Van Dyke 3 Internet Draft E. Burger 4 Document: draft-burger-sipping-msuri-01.txt SnowShore Networks, Inc. 5 Category: Standards Track November 21, 2001 6 Expires: May 2002 8 SIP URI Conventions for Media Servers 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Discussion of this document is on the SIPPING discussion list. The 30 SIPPING list is at . 32 1. Abstract 34 Application Servers, SIP Proxies, and SoftSwitches (a.k.a. Media 35 Gateway Controllers) act as SIP [2] User Agents to control the media 36 processing capabilities of media servers. The SIP Request URI 37 identifies the desired service and provides a context for the media 38 server to interpret the SIP message. This document describes a 39 standard SIP addressing mechanism to address specific services. 40 Because of SIP's flexibility, the existing protocol accommodates 41 these services. This document proposes a standard URI scheme for 42 important media services such as announcements and conferencing. 44 SIP Media Server URI Conventions November 2001 46 2. Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 50 this document are to be interpreted as described in RFC-2119 [3]. 52 FORMATTING NOTE: Notes, such at this one, provide additional, 53 nonessential information that the reader may skip without missing 54 anything essential. The primary purpose of these non-essential 55 notes is to convey information about the rationale of this document, 56 or to place this document in the proper historical or evolutionary 57 context. Readers whose sole purpose is to construct a conformant 58 implementation may skip such information. However, it may be of use 59 to those who wish to understand why we made certain design choices. 61 Table of Contents 63 1. Abstract...........................................................1 64 2. Conventions used in this document..................................2 65 3. Overview...........................................................2 66 4. Service Definition.................................................3 67 5. Service Indicators and URI Signatures..............................3 68 6. Operation..........................................................4 69 7. Formal Syntax......................................................5 70 8. Security Considerations............................................5 71 9. IANA Considerations................................................5 72 10. Examples..........................................................6 73 10.1. Announcement....................................................6 74 10.2. Conference......................................................7 75 11. References........................................................7 76 12. Changes Made in Version 01........................................8 77 13. Acknowledgments...................................................8 78 14. Author's Addresses................................................8 80 3. Overview 82 Media servers are devices that perform media processing on real-time 83 packet media. Examples of such processing are tone detection and 84 generation, packet recording (usually with transcoding), packet 85 playing (usually with transcoding - also known as prompting), and 86 mixing (also known as conferencing). 88 These services are of general utility to a wide array of SIP UA's 89 including application servers, softswitches and proxy servers. In 90 addition, the behaviors and semantics of these services are well 91 understood. For these reasons, it is both desirable and possible to 92 create standard SIP interfaces for these services. 94 SIP Media Server URI Conventions November 2001 96 4. Service Definition 98 A service is a set of related media processing features with a well- 99 defined set of properties. The defining properties of a service are 100 its SIP URI signature, the MIME types it accepts and any 101 SUBSCRIBE/NOTIFY [4] event packages it supports. The SIP URI 102 signature consists of the service indicator, instance ID and any 103 associated URI parameters. 105 Services MUST have a unique SIP URI signature. Services MAY offer 106 support for MIME types other than "application/sdp" and 107 SUBSCRIBE/NOTIFY event packages if required to implement service 108 features. 110 In the context of SIP control of media servers, we take advantage of 111 the fact that the standard SIP URI has a user part [2]. Media 112 processing services may be thought of as user automatons that 113 participate in SIP sessions. It naturally follows that the user 114 address, or the left-hand-side of the URI, should be utilized as a 115 service indicator. 117 Media servers commonly offer multiple services at a single host 118 address. Use of the user part as a service indicator enables 119 service consumers to direct their requests without ambiguity. It 120 has the added benefit of enabling media services to register their 121 availability with SIP Registrars just as any "real" SIP user would. 122 This maintains consistency and provides enhanced flexibility in the 123 deployment of media services in the network. 125 For per-service security, the media server MAY use any of the 126 security protocols described in [2]. 128 Following [2], the media server MAY issue 401 challenges for 129 authentication. 131 The media server, upon receiving the INVITE, notes the service 132 indicator. Depending on the service indicator, the media server 133 will either honor the request or return a failure response code. 135 5. Service Indicators and URI Signatures 137 The service indicator is the concatenation of the service name and 138 an optional service instance identifier, separated by an equal sign. 139 The service name MAY be modified by an optional service namespace. 141 There has been much discussion about the potential for confusion if 142 media services URIs are not readily distinguishable from other types 143 of SIP UA's. The use of a service namespace provides a mechanism to 144 unambiguously identify standard interfaces while not constraining 145 the development of private or experimental services. 147 SIP Media Server URI Conventions November 2001 149 It is proposed that standard services, such as the announcement and 150 conferencing services described here, be registered with IANA using 151 the "org.iana" service namespace. 153 Service developers MAY use a service namespace other than "org.iana" 154 for private or experimental services. 156 Per [2], the service indicator is case insensitive. The service 157 name MUST be from the set alphanumeric characters plus dash (US- 158 ASCII %2C). The service name MUST NOT include an equal sign (US- 159 ASCII %3C). 161 The service name MAY have long- and short-forms, as SIP does for 162 headers. 164 A given service indicator MAY have an associated set of parameters. 165 Such parameters MUST follow the convention set out in [2] for SIP 166 URI parameters. That is, a semi-colon separated list of 167 keyword=values. 169 Certain services may have an association with a unique service 170 instance on the media server. For example, a given media server can 171 host multiple, separate conference sessions. To identify unique 172 service instances, a unique identifier modifies the service name. 173 The unique identifier MUST meet the rules for a legal user part of a 174 SIP URI as set out in [2]. An equal sign, US-ASCII %3D, MUST 175 separate the service indicator from the unique identifier. 177 Note that since the service indicator is case insensitive per [2], 178 the service instance identifier is also case insensitive. 180 6. Operation 182 The requesting client issues a SIP INVITE to the media server, 183 specifying the requested service and any appropriate parameters. 185 If the media server can perform the requested service, it does so, 186 following the processing steps described in the service definition 187 document (see IANA Considerations, below). 189 If the media server cannot perform the requested service or does not 190 recognize the service indicator, it MUST respond with the response 191 code 488 NOT ACCEPTABLE HERE. This is appropriate, as 488 refers to 192 a problem with the user part of the URI. Moreover, 606 is not 193 appropriate, as some other media server may be able to satisfy the 194 request. [2] describes the 488 and 606 response codes. 196 Some services require a unique identifier. Most services 197 automatically create a service instance upon the first INVITE with 198 the given identifier. However, if a service requires an existing 199 service instance, and no such service instance exists on the media 200 server, the media server MUST respond with the response code 404 NOT 201 SIP Media Server URI Conventions November 2001 203 FOUND. This is appropriate as the service itself exists on the 204 media server, but the particular service instance does not. It is 205 as if the user was not home. 207 7. Formal Syntax 209 The following syntax specification uses the augmented Backus-Naur 210 Form (BNF) as described in RFC-2234 [6]. 212 SERVICE-URL = "sip:" [srvc-namespace] srvc-ind "@" hostport 213 url-parameters [headers] 215 srvc-namespace = ("org.iana" "." | 1*nmspc-part) 217 nmspc-part = 1*(ALPHA | DIGIT) "." 219 srvc-ind = srvc-name [ "=" instanceId ] 221 srvc-name = "annc" | "conf" | token 223 instanceId = token 225 Section 2 of [2] defines the elements hostport and token. See the 226 IANA Considerations section for procedures for adding new service 227 indicators. 229 8. Security Considerations 231 The security issues are the same as for SIP [2], as the media server 232 is simply a SIP User Agent. 234 9. IANA Considerations 236 This document describes an extensible set of SIP Media Server 237 Service Indicator types. To promote interoperability and coherent 238 interpretations of different types, we need a central repository for 239 well-known service indicator types. 241 IANA will create a repository for service indicator types called 242 "SIP Media Server Service Indicator Types". Following the policies 243 outlined in [7], this repository is "Specification Required by RFC." 244 The documents [8] and [10] describe the initial values for the 245 repository. For reference, the values are as follows. 247 NOTE: Drafts describing service indicators for conferencing, 248 transcoding and IVR are currently being developed. 250 SIP Media Server URI Conventions November 2001 252 SIP Media Server Service Indicator Types 253 ======================================== 255 Value Meaning Reference 256 ----- -------------- --------- 257 Parameter Values 258 ----------- ------ 259 annc Announcement Service draft-burger-sipping-netann-01.txt 260 play= URI or provisioned sequence identifier 261 early= ( "yes" | "no" ) 262 repeat= Integer, number of repetitions 263 delay= Integer, delay between repetitions 264 duration= Integer, max. prompt duration 265 locale= Language and country codes 266 param[n]= Variable values to be substituted in 267 a sequence 269 conf Conference Service 270 272 10. Examples 274 These examples are informative. For the normative definitions of 275 the given services, see the referenced documents. 277 NOTE: The line wrapping (backslash, CRLF, and spacing before 278 continued lines) in the examples is for readability purposes only. 280 10.1. Announcement 282 The document [8] fully specifies the announcement service. In 283 brief, the announcement service can play a prompt as early media or 284 after the establishment of a connection. 286 The announcement service indicator is "annc". The service has 287 several associated parameters that control the content and delivery 288 of the announcement. 290 In the following example, the media server at ms2.carrier.net 291 retrieves an audio file using HTTP [9] from the server 292 prompts.carrier.net and plays it as early media. 294 sip:annc@ms2.carrier.net; \ 295 play="http://prompts.carrier.net/audio/allcircuitsbusy.g711"; 296 \ 297 early=yes 298 SIP Media Server URI Conventions November 2001 300 10.2. Conference 302 The conference service creates a conference upon the first instance 303 of a unique service instance identifier. The media server places 304 subsequent requests with the same service instance identifier into a 305 conference. 307 The conference service indicator is "conf". There are no parameters 308 for the conference service. 310 In the following example, the media server at ms2.carrier.net 311 creates (or places into conference) the stream associated with the 312 SDP in the INVITE to the conference identified by the identifier 313 "q4unfcqdscQS". 315 sip:conf=q4unfcqdscQS@ms2.carrier.net 317 NOTE: A draft describing the conference service in detail is in 318 progress. 320 11. References 322 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 323 9, RFC 2026, October 1996. 325 2 Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J., "SIP: 326 Session Initiation Protocol", draft-ietf-sip-rfc2543bis-03.txt, 327 May 2001, work in progress. 329 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 330 Levels", BCP 14, RFC 2119, March 1997. 332 4 Roach, A., "SIP-Specific Event Notification, "draft-ietf-sip- 333 events-01.txt, November 2001, work in progress. 335 6 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 336 Specifications: ABNF", RFC 2234, November 1997. 338 7 Alvestrand, H. and Narten, T., "Guidelines for Writing an IANA 339 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 341 8 O'Connor, W., Burger, E., "Network Announcements with SIP", 342 draft-burger-sipping-netann-01.txt, November 2001, work in 343 progress. 345 9 Fielding, R., Gettys, D., Mogul, J., Frystyk, H., Masinter, L., 346 Leach, P., and Berners-Lee, T., "Hypertext Transfer Protocol -- 347 HTTP/1.1", RFC 2616, June 1999. 349 12. Changes Made in Version 01 350 o Added additional explanatory text to explain motivations for 351 use of service indicators and benefits of the proposed format. 352 o Updated description of the announcement service to be 353 consistent with draft-burger-sipping-netann-01.txt. 354 o Proposed an option for implementing a namespace for service 355 indicators. 357 13. Acknowledgments 359 We would like to offer our thanks to Jonathan Rosenberg of 360 dynamicsoft for his constructive comments. 362 14. Author's Addresses 364 Jeff Van Dyke 365 SnowShore Networks, Inc. 366 285 Billerica Rd. 367 Chelmsford, MA 01824-4120 368 USA 370 Phone: +1 978/367-8405 371 Email: jvandyke@snowshore.com 373 Eric Burger 374 SnowShore Networks, Inc. 375 285 Billerica Rd. 376 Chelmsford, MA 01824-4120 377 USA 379 Phone: +1 978/367-8403 380 Email: eburger@snowshore.com 381 SIP Media Server URI Conventions November 2001 383 Full Copyright Statement 385 Copyright (C) The Internet Society (2001). All Rights Reserved. 387 This document and translations of it may be copied and furnished to 388 others, and derivative works that comment on or otherwise explain it 389 or assist in its implementation may be prepared, copied, published 390 and distributed, in whole or in part, without restriction of any 391 kind, provided that the above copyright notice and this paragraph are 392 included on all such copies and derivative works. However, this 393 document itself may not be modified in any way, such as by removing 394 the copyright notice or references to the Internet Society or other 395 Internet organizations, except as needed for the purpose of 396 developing Internet standards in which case the procedures for 397 copyrights defined in the Internet Standards process must be 398 followed, or as required to translate it into languages other than 399 English. 401 The limited permissions granted above are perpetual and will not be 402 revoked by the Internet Society or its successors or assigns. This 403 document and the information contained herein is provided on an "AS 404 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 405 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 406 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 407 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 408 OR FITNESS FOR A PARTICULAR PURPOSE. 410 Acknowledgement 412 The Internet Society currently provides funding for the RFC Editor 413 function.