idnits 2.17.1 draft-rosenberg-sip-app-media-tag-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 10, 2009) is 5314 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) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Standards Track September 10, 2009 5 Expires: March 14, 2010 7 A Session Initiation Protocol (SIP) Media Feature Tag for MIME 8 Application Sub-Types 9 draft-rosenberg-sip-app-media-tag-04 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on March 14, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 The caller preferences specification for the Session Initiation 58 Protocol (SIP) allows a caller to express preferences that the call 59 be routed to a User Agent (UA) with particular capabilities. 60 Similarly, a specification exists to allow a UA to indicate its 61 capabilities in a registration. Amongst those capabilities are the 62 type of media streams the agent supports, described as top-level MIME 63 types. The 'application' MIME type is used to describe a broad range 64 of stream types, and provides insufficient granularity as a 65 capability. This specification allows a UA to indicate which 66 application sub-types the agent supports. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. sip.app-subtype Media Feature Tag . . . . . . . . . . . . . . . 5 73 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 The caller preferences specification [RFC3841] for the Session 84 Initiation Protocol (SIP) [RFC3261] allows a user to express 85 preferences for the routing of SIP requests. These preferences are 86 expressed as a set of desired capabilities and characteristics of a 87 receiving agent. When a user agent registers to the SIP network, it 88 includes, as part of its registration, its own capabilities and 89 characteristics [RFC3840]. These capabilities are stored as part of 90 the registration, and then made available to the proxy in the 91 network. When a request arrives at the proxy with caller 92 preferences, the preferences in the request are compared with the 93 supported characteristics and capabilities stored in the 94 registrations, and the result is used to select the target user 95 agents for the request. 97 RFC 3840 makes use of media feature tags [RFC2506]. Each tag has a 98 name and a type. The tags defined in RFC 3840 describe some of the 99 basic characteristics of user agents, including whether they are 100 automata or not (the sip.automata tag), their class (the sip.class 101 tag), whether they support media in one or both directions (the 102 sip.duplex), and whether they are a conference focus (sip.isfocus). 103 These tags also include SIP protocol capabilities, including the 104 schemes supported by the agent (sip.schemes), the methods 105 (sip.methods), and the event packages [RFC3265] (sip.events). 107 RFC 3840 also defines media feature tags for multimedia stream types. 108 There is a media feature tag defined for each top-level media type - 109 sip.audio for audio streams, sip.video for video streams, and so on. 110 The primary use case for this is to correctly deliver multimedia 111 sessions to the user agent that supports that media type. Consider a 112 caller on a videophone that wants to have a video call with another 113 user. That user has two devices - a mobile phone that only supports 114 audio, and a videophone. We'd like to deliver the videophone call to 115 the videophone as a first priority, and only 'ring' the mobile device 116 for an audio-only call if the user is not present on the videophone. 118 RFC 3840 defines media feature tags for each and every top-level 119 media type, including 'application'. This media type covers an 120 extremely broad range of subtypes - multiplayer games of all sorts, 121 shared whiteboards and application sharing, and so on. With audio 122 and video, where there is often a common codec supported by agents 123 (i.e., a common subtype). Consequently, if a caller wants an audio 124 session, routing the request to any user agent that supports audio is 125 likely to result in successful communications. However, with 126 application streams, just routing a request to an agent that supports 127 *some* application stream isn't useful; application streams for 128 different applications are wildly different. Consequently, the 129 application media feature tag does not provide sufficient granularity 130 for call preferences. The specific application sub-type needs to be 131 indicated as well. 133 To remedy this, this specification defines a new media feature tag 134 that indicates which application sub-types are supported by the agent 135 for streaming. The name of this media feature tag is 'sip.app- 136 subtype'. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 3. sip.app-subtype Media Feature Tag 146 The 'sip.app-subtype' media feature tag is of type token with a case- 147 insensitive equality relationship. Its value can be any registered 148 or private MIME application sub-type compliant to the subtype-name 149 grammar defined in [RFC4288]. When included in the Contact header 150 field of a REGISTER request, an agent SHOULD include all application 151 subtypes that it can support as streaming formats. An application 152 sub-type is supported if the user agent would be capable of 153 processing an Session Description Protocol (SDP) [RFC4566] offer 154 [RFC3264] that contained that sub-type as a format in the m-line of 155 the SDP. 157 When included in the Accept-Contact or Reject-Contact header field, 158 it indicates a desire on the part of a UAC to be connected to a UAS 159 which can support, or cannot support respectively, streaming using 160 that application sub-type. 162 It is important to note that this media feature tag is only 163 indicating the streaming media types that a user agent is capable of 164 supporting. It says nothing about the functionality provided by the 165 user agent itself, or the MIME types that the agent can send or 166 receive in SIP messages or emails. For example, let us assume that a 167 SIP user agent is capable of supporting a chess game. The game is 168 played by each user sending chess moves as binary objects over UDP 169 between a pair of user agents. Those objects have a MIME type of 170 "application/example". When a UA includes the sip.app-subtype media 171 feature tag in a Contact header field with a value of "example", it 172 means that the UA can handle a SIP INVITE that contained an SDP with 173 an application media line and format of "example". It does not mean 174 that the SIP user agent is a chess application, or that the user 175 agent can accept SIP requests that include bodies of type 176 "application/example". To indicate that a user agent can accept SIP 177 requests that include bodies of type "application/example", the agent 178 would utilize the "type" media feature tag as defined in [RFC3840]. 180 A consequence of this is that, as new streaming media type formats 181 are defined (such as game stream formats, whiteboard session formats, 182 and so on, they SHOULD be defined using the SDP application stream, 183 and utilize a MIME application sub-type. 185 4. Example 187 The following is an example SIP REGISTER message fragment indicating 188 usage of this media feature tag. The REGISTER indicates that the UA 189 can particiate in application media sessions utilizing exchange of 190 objects of type "application/example". 192 REGISTER sip:example.com SIP/2.0 193 To: sip:Y@example.com 194 Contact: 195 ;methods="INVITE,ACK,OPTIONS,BYE,CANCEL" 196 ;uri-user="" 197 ;uri-domain="example.com" 198 ;audio 199 ;schemes="sip" 200 ;mobility="fixed" 201 ;class="personal" 202 ;+sip.app-subtype="example" 204 Such a registration indicates that an INVITE of the following form: 206 INVITE sip:Y@example.com SIP/2.0 207 To: sip:Y@example.com 208 Content-Type: application/sdp 209 Content-Length: ... 211 v=0 212 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 213 c=IN IP4 192.0.1.2 214 t=0 0 215 m=audio 49170 RTP/AVP 0 216 m=application 8493 udp example 218 would be accepted by the UA. The SDP in the INVITE indicates an 219 audio session and an application session which runs over UDP and 220 exchanges "application/example" object formats. 222 5. Security Considerations 224 When present in a REGISTER request, this media feature tag gives 225 information on the set of supported application media streams. It is 226 possible that this information is sensitive, providing insight into 227 the capabilities of a product. These considerations are already 228 discussed in RFC 3840, and those considerations apply here as well. 229 Applications which utilize this media feature tag SHOULD provide a 230 means for ensuring its integrity. Similarly, the media feature tag 231 should only be trusted as valid when it comes from the user or user 232 agent described by the feature tag. As a result, mechanisms for 233 conveying the feature tag SHOULD provide a mechanism for guaranteeing 234 authenticity. 236 6. IANA Considerations 238 This specification adds a new media feature tag to the SIP Media 239 Feature Tag Registration Tree defined in RFC 3840 [RFC3840]. 241 Media feature tag name: sip.app-subtype 243 ASN.1 Identifier: 1.3.6.1.8.4.24 245 Summary of the media feature indicated by this tag: This feature tag 246 indicates the MIME application sub-types supported by the agent 247 for purposes of streaming media. 249 Values appropriate for use with this feature tag: Token (equality 250 relationship). 252 The feature tag is intended primarily for use in the following 253 applications, protocols, services, or negotiation mechanisms: This 254 feature tag is most useful in a communications application, for 255 describing the capabilities of a device, such as a phone or PDA. 257 Examples of typical use: Routing a call to a phone that can support 258 a multiplayer game. 260 Related standards or documents: RFC XXXX [[Note to IANA: Please 261 replace XXXX with the RFC number of this specification.]] 263 Security Considerations: Security considerations for this media 264 feature tag are discussed in Section 5 of RFC XXXX . [[Note to 265 IANA: Please replace XXXX with the RFC number of this 266 specification.]] 268 7. References 270 7.1. Normative References 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, March 1997. 275 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 276 with Session Description Protocol (SDP)", RFC 3264, 277 June 2002. 279 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 280 "Indicating User Agent Capabilities in the Session 281 Initiation Protocol (SIP)", RFC 3840, August 2004. 283 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 284 Registration Procedures", BCP 13, RFC 4288, December 2005. 286 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 287 Description Protocol", RFC 4566, July 2006. 289 7.2. Informative References 291 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 292 A., Peterson, J., Sparks, R., Handley, M., and E. 293 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 294 June 2002. 296 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 297 Event Notification", RFC 3265, June 2002. 299 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 300 Preferences for the Session Initiation Protocol (SIP)", 301 RFC 3841, August 2004. 303 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 304 Registration Procedure", BCP 31, RFC 2506, March 1999. 306 Author's Address 308 Jonathan Rosenberg 309 Cisco 310 Edison, NJ 311 US 313 Email: jdrosen@cisco.com 314 URI: http://www.jdrosen.net