idnits 2.17.1 draft-andreasen-mmusic-sdpcapneg-att-del-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 535. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 190 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (June 7, 2007) is 6167 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: 'RFC3264' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC3407' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'RFC3605' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'RFC4234' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'RFC2327' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'RFC3388' is defined on line 421, but no explicit reference was found in the text == Unused Reference: 'RFC3551' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'SRTP' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC3851' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'RFC4091' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'AVPF' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'I-D.jennings-sipping-multipart' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'SAVPF' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'SDES' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'SDPng' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'BESRTP' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'KMGMT' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'SDPCapNegRqts' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'SDPCapNeg' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'MIKEY' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'ICE' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'ICETCP' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC3312' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'SMIME' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC4474' is defined on line 497, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4091 (Obsoleted by RFC 5245) -- Duplicate reference: RFC3851, mentioned in 'SMIME', was also mentioned in 'RFC3851'. -- Obsolete informational reference (is this intentional?): RFC 3851 (ref. 'SMIME') (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 5 errors (**), 0 flaws (~~), 31 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group F. Andreasen 3 Internet-Draft Cisco Systems 4 Intended Status: None June 7, 2007 5 Expires: December 2007 7 SDP Capability Negotiation: 8 Deleting and Replacing Attributes 9 draft-andreasen-mmusic-sdpcapneg-att-del-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on December 7, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 The current SDP Capability Negotiation solution includes the ability 44 for a potential configuration to delete and replace individual 45 attributes from the actual configuration. This capability introduces 46 some complexity into the SDP Capability Negotiation framework and 47 this document examines the need for having this feature and proposes 48 a way forward. 50 Table of Contents 52 1. Introduction...................................................2 53 2. Conventions used in this document..............................2 54 3. To Add, Delete or Replace Attributes...........................2 55 3.1. Deleting Attributes.......................................3 56 3.1.1. 1) Unintended processing of a well-known attribute when 57 parts of the SDP is changed.................................4 58 3.1.2. Unclear interactions between two different attributes 59 (for example two different attribute names).................6 60 3.2. Replace Attributes........................................7 61 4. Conclusion.....................................................8 62 5. Security Considerations........................................9 63 6. IANA Considerations............................................9 64 7. References....................................................10 65 7.1. Normative References.....................................10 66 7.2. Informative References...................................10 67 Author's Addresses...............................................12 68 Intellectual Property Statement..................................13 69 Full Copyright Statement.........................................13 70 Acknowledgment...................................................13 72 1. Introduction 74 The current SDP Capability Negotiation solution [sdpcapneg] includes 75 the ability for a potential configuration to delete and replace 76 individual attributes from the actual configuration. This capability 77 introduces some complexity into the SDP Capability Negotiation 78 framework. In this document, we examine the need for having this 79 feature in Section 3. and then propose a way forward in Section 4. 81 It is assumed that the reader is familiar with the [sdpcapneg]. 83 2. Conventions used in this document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 3. To Add, Delete or Replace Attributes 91 In the SDP Capability Negotiation framework solution [sdpcapneg] the 92 SDP provided includes attributes as part of the actual configuration 93 in the offer (and answer) SDP. If one or more attributes are unknown 94 or unsupported, the answerer will ignore those attributes per normal 95 SDP rules [RFC4566]. 97 The SDP Capability Negotiation framework defines attribute 98 capabilities, and enables one or more of those attribute capabilities 99 to be used in one of the potential configuration SDPs, whereby it 100 becomes part of the alternative offer. The potential configuration 101 SDP is formed by taking the actual configuration SDP (the offer) and 102 add the attribute capability values that are referenced by the 103 potential configuration. 105 The primary reason for doing this is to control which attribute 106 capability values are part of a potential configuration SDP. This 107 enables alternative attribute types and values to be ordered by 108 preference and for different attributes (including different types, 109 e.g. keying mechanisms) to be chosen for a particular potential 110 configuration. 112 The SDP Capability Negotiation framework currently also defines 113 mechanisms for: 115 1) DELETING one or more attributes from the actual configuration SDP 116 when forming the potential configuration SDP 118 2) REPLACING one or more attributes from the actual configuration SDP 119 with an attribute capability value when forming the potential 120 configuration SDP. 122 The ability to delete and replace attributes from the actual 123 configuration SDP adds some complexity to the SDP Capability 124 Negotiation framework. The question has been raised whether these 125 features are necessary. Below we provide motivation for each. 127 3.1. Deleting Attributes 129 When it comes to the need for deleting attributes from the actual 130 configuration SDP, the basic question is whether presence of a 131 particular SDP attribute can cause unintended operation to occur, 132 i.e., can an SDP attribute actually be harmful. Since SDP will always 133 ignore unknown attributes, harmful operation can occur only when a 134 particular attribute is supported by the recipient (answerer). 136 At the heart of this issue is how SDP attributes are processed, and 137 in particular whether presence of what appears to be a meaningless 138 SDP attribute can interfere with normal or intended offer/answer 139 processing. For example, if a UDP-based media stream is being 140 established, and TCP-based parameters are included (e.g. per RFC 141 4145), will those parameters be ignored, or will the answerer instead 142 view the SDP (or media stream) as malformed and reject it ? 144 Since SDP requires unknown attributes to be ignored, and general IETF 145 principles prescribe being liberal in what you receive, we will 146 *assume*, that in the absence of specific rules to the contrary, an 147 SDP implementation will indeed ignore not only unknown SDP 148 attributes, but also SDP attributes that do not otherwise seem to 149 apply to a given SDP. Without this assumption, the issue at hand is 150 closed inasmuch as we clearly would need the ability to delete 151 attributes. 153 With the above assumption, we are left with two classes of problems 154 for specific well-known attributes: 156 1) Unintended processing of a well-known attribute when parts of the 157 SDP is changed. 159 2) Unclear interactions between two different attributes (for example 160 two different attribute names). 162 Below, we look at each of these separately and provide example 163 scenarios 165 3.1.1. 1) Unintended processing of a well-known attribute when parts of 166 the SDP is changed. 168 An example of this is when the actual configuration offers an SRTP 169 media stream, and the alternative potential configuration uses plain 170 RTP. In the following example, the actual configuration includes 171 keying material in a "crypto" attribute as illustrated below: 173 v=0 174 o=alice 2891092738 2891092738 IN IP4 lost.example.com 175 s= 176 t=0 0 177 c=IN IP4 lost.example.com 178 m=audio 59000 RTP/SAVP 0 179 a=crypto:1 AES_CM_128_HMAC_SHA1_32 180 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 181 a=tcap RTP/SAVP RTP/AVP 182 a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 183 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 184 a=pcfg:1 a=1 t=1 185 The resulting potential configuration SDP for the plain RTP 186 alternative (the actual configuration, which by default is the least 187 preferred alternative) would look like this, if we don't delete the 188 actual configuration attributes: 190 v=0 191 o=alice 2891092738 2891092738 IN IP4 lost.example.com 192 s= 193 t=0 0 194 c=IN IP4 lost.example.com 195 m=audio 59000 RTP/AVP 0 196 a=crypto:1 AES_CM_128_HMAC_SHA1_32 197 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 199 Note that we have a "crypto" attribute with a plain RTP media stream. 201 When processing this potential configuration, it would be best to 202 delete the "crypto" attribute from the configuration. Otherwise, the 203 media stream could get rejected. From RFC 4568, Section 5.1.2: 205 206 When the answerer receives the initial offer with one or more crypto 207 attributes for a given unicast media stream, the answerer MUST either 208 accept exactly one of the offered crypto attributes, or the offered 209 stream MUST be rejected. 210 212 Section 5 in RFC 4568 is transport protocol agnostic, with Section 7 213 providing the SRTP specific behavior. Section 7.1.2 says: 215 216 When the initial answer is generated, the answerer MUST follow the 217 steps in Section 5.1.2, as well as the following steps. 218 For each unicast media line that uses the secure RTP transport and 219 contains one or more "a=crypto" lines in the offer, the answerer MUST 220 either accept one (and only one) of the crypto lines for that media 221 stream, or it MUST reject the media stream. 222 224 and later on 226 227 If the answerer cannot find any valid crypto line that it supports, 228 or if its configured policy prohibits any cryptographic key parameter 229 e.g., key length) or cryptographic session parameter (e.g., KDR, 230 FEC_ORDER), it MUST reject the media stream, unless it is able to 231 successfully negotiate use of SRTP by other means outside the scope 232 of this document (e.g., by use of MIKEY [mikey]). 233 235 It is somewhat open to interpretation whether Section 7.1.2 implies 236 that the crypto operation will only happen if we actually have an 237 SRTP stream in the "m=" line. However, if we want to be on the safe 238 side, we should not provide any crypto attribute with a vanilla RTP 239 stream, and that is part of the reason for having the "delete" 240 semantics in the SDP Capability Negotiation. 242 3.1.2. Unclear interactions between two different attributes (for 243 example two different attribute names). 245 An example of this is the "keymgt" and "crypto" attributes used for 246 SRTP keying. Assume the actual configuration offers an SRTP media 247 stream using the "crypto" attribute as the keying mechanism, whereas 248 an alternative potential configuration suggests use of MIKEY or DTLS- 249 SRTP. 251 The actual configuration SDP could look like this: 253 v=0 254 o=alice 2891092738 2891092738 IN IP4 lost.example.com 255 s= 256 t=0 0 257 c=IN IP4 lost.example.com 258 m=audio 59000 RTP/SAVP 0 259 a=crypto:1 AES_CM_128_HMAC_SHA1_32 260 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 261 a=tcap:1 RTP/SAVP UDP/TLS/RTP/AVP 262 a=acap:1 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 263 a=acap:2 a=setup:actpass 264 a=acap:3 a=connection:new 265 a=acap:4 a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:... 266 a=pcfg:1 t=1 a=1 267 a=pcfg:2 t=2 a=2,3,4 269 The resulting potential configuration SDP for SRTP using MIKEY would 270 look like this: 272 v=0 273 o=alice 2891092738 2891092738 IN IP4 lost.example.com 274 s= 275 t=0 0 276 c=IN IP4 lost.example.com 277 m=audio 59000 RTP/SAVP 0 278 a=crypto:1 AES_CM_128_HMAC_SHA1_32 279 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 280 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 282 There are two issues with this potential configuration SDP. First of 283 all, it contains both a crypto and a key-mgmt attribute, however only 284 one of these should be used for negotiating SRTP security parameters. 285 Fortunately, RFC 4568 (Section 7.5) specifically addresses this 286 interaction issue by mandating that only of them is actually 287 processed, however it nevertheless illustrates the interaction issue. 289 The resulting potential configuration SDP for DTLS-SRTP would look 290 like this: 292 v=0 293 o=alice 2891092738 2891092738 IN IP4 lost.example.com 294 s= 295 t=0 0 296 c=IN IP4 lost.example.com 297 m=audio 59000 UDP/TLS/RTP/AVP 0 298 a=crypto:1 AES_CM_128_HMAC_SHA1_32 299 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 300 a=setup:actpass 301 a=connection:new 302 a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:... 304 This potential configuration SDP suffers from the same issue as the 305 plain RTP one in the previous scenario; presence of the crypto 306 attribute with a transport protocol for which it is not to be used. 308 3.2. Replace Attributes 310 Attribute replacement is similar deleting an attribute and then 311 adding another one, however the issues behind this feature differ 312 from that of simple deletion. The basic problems motivating this 313 feature are: 315 1) An attribute value may conflict with another attribute value. 317 Examples of this include "rtpmap" and "fmtp" parameters. If the SDP 318 contains an "rtpmap:96 PCMU" and the potential configuration adds 319 "rtpmap:96 G729", then which mapping is actually the right one to use 320 ? To avoid this ambiguity, RFC 4566 states that 322 323 Up to one rtpmap attribute can be defined for each media format 324 specified. 325 327 The issue is similar for the "fmtp" parameter. 329 A possible alternative solution to replacing attributes would be to 330 define an order in which attributes are added to the potential 331 configuration SDP, and then define conflict resolution for well - 332 known attribute types (such as fmtp and rtpmap), however the concern 333 with doing so is that it is not a general solution. We cannot specify 334 rules for attributes that are yet to be defined, and we miss some 335 attribute types. 337 4. Conclusion 339 We have presented the rationale behind 341 - deleting attributes in an actual configuration SDP 343 - replacing attributes in an actual configuration SDP 345 In terms of deleting attributes, we made an important assumption 346 about implementations generally ignoring SDP attributes that do not 347 seem to otherwise apply for a particular SDP. This left us with the 348 problem of dealing only with attributes that may result in unintended 349 processing when the SDP changes or attributes that have unclear 350 interactions. We have looked at a variety of different SDP attributes 351 for this class of problems, however our primary use cases seem to 352 center around SRTP key management. This suggests that the problem is 353 somewhat limited in scope when it comes to current SDP parameters. 355 In terms of replacing attributes, there are clear use cases for this, 356 notably in the areas of the "fmtp" and "rtpmap" attributes. Both of 357 these are outside the scope of the core SDP capability negotiation 358 document, however they are within scope of the media capabilities 359 negotiation work. 361 While there is little doubt (in the author's mind at least) that 362 there is an important general problem here, it could be argued that 363 it would be sufficient to provide a solution in the core document 364 that does not define how individual attributes are deleted from the 365 actual configuration. If that path is followed, it is the author's 366 opinion that we should still provide the ability to delete all 367 attributes from the existing SDP (at the media and/or session-level) 368 thereby providing a simple (albeit somewhat inefficient in terms of 369 message size) solution to the general problem, that all 370 implementations are guaranteed to support. 372 5. Security Considerations 374 None. 376 6. IANA Considerations 378 None. 380 7. References 382 7.1. Normative References 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 388 with Session Description Protocol (SDP)", RFC 3264, June 389 2002. 391 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 392 Capability Declaration", RFC 3407, October 2002. 394 [RFC3605] C. Huitema, "Real Time Control Protocol (RTCP) attribute in 395 Session Description Protocol (SDP)", RFC 3605, October 396 2003. 398 [RFC4234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 399 Specifications: ABNF", RFC 4234, October 2005. 401 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 402 Description Protocol", RFC 4566, July 2006. 404 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 405 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 406 October 1998. 408 7.2. Informative References 410 [RFC2046] Freed, N., and N. Borensteain, "Multipurpose Internet Mail 411 Extensions (MIME) Part Two: Media Types", RFC 2046, 412 November 1996. 414 [RFC2327] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 415 Description Protocol", RFC 2327, April 1998. 417 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 418 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 419 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 421 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 422 Schulzrinne, "Grouping of Media Lines in the Session 423 Description Protocol (SDP)", RFC 3388, December 2002. 425 [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and 426 Video Conferences with Minimal Control", RFC 3551, July 427 2003. 429 [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 430 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 431 RFC 3711, March 2004. 433 [RFC3851] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 434 (S/MIME) Version 3.1 Message Specification", RFC 3851, July 435 2004. 437 [RFC4091] Camarillo, G., and J. Rosenberg, The Alternative Network 438 Address Types (ANAT) Semantics for the Session Description 439 Protocol (SDP) Grouping Framework, RFC 4091, June 2005. 441 [AVPF] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 442 "Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF)", 443 Work in Progress, August 2004. 445 [I-D.jennings-sipping-multipart] Wing, D., and C. Jennings, "Session 446 Initiation Protocol (SIP) Offer/Answer with Multipart 447 Alternative", Work in Progress, March 2006. 449 [SAVPF] Ott, J., and E Carrara, "Extended Secure RTP Profile for 450 RTCP-based Feedback (RTP/SAVPF)", Work in Progress, 451 December 2005. 453 [SDES] Andreasen, F., Baugher, M., and D. Wing, "Session 454 Description Protocol Security Descriptions for Media 455 Streams", RFC 4568, July 2006. 457 [SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session Description 458 and Capability Negotiation", Work in Progress, February 459 2005. 461 [BESRTP] Kaplan, H., and F. Audet, "Session Description Protocol 462 (SDP) Offer/Answer Negotiation for Best-Effort Secure Real- 463 Time Transport Protocol, Work in progress, August 2006. 465 [KMGMT] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 466 Carrara, "Key Management Extensions for Session Description 467 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 468 RFC 4567, July 2006. 470 [SDPCapNegRqts] Andreasen, F. "SDP Capability Negotiation: 471 Requirementes and Review of Existing Work", work in 472 progress, December 2006. 474 [SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", work in 475 progress, March 2007. 477 [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 478 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 479 August 2004. 481 [ICE] J. Rosenberg, "Interactive Connectivity Establishment 482 (ICE): A Methodology for Network Address Translator (NAT) 483 Traversal for Offer/Answer Protocols", work in progress, 484 January 2007. 486 [ICETCP] J. Rosenberg, "TCP Candidates with Interactive Connectivity 487 Establishment (ICE)", work in progress, October 2006. 489 [RFC3312] G. Camarillo, W. Marshall, and J. Rosenberg, "Integration 490 of Resource Management and Session Initiatio Protocol 491 (SIP)", RFC 3312, October 2002. 493 [SMIME] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 494 (S/MIME) Version 3.1 Message Specification", RFC 3851, July 495 2004. 497 [RFC4474] J. Peterson, and C. Jennings, "Enhancements for 498 Authenticated Identity Management in the Session Initiation 499 Protocol (SIP)", RFC 4474, August 2006. 501 [sprecon] Andreasen, F. and D. Wing, "Security Preconditions for 502 Session Description Protocol Media Streams", Work in 503 Progress, October 2006. 505 Author's Addresses 507 Flemming Andreasen 508 Cisco Systems 509 Edison, NJ 511 Email: fandreas@cisco.com 513 Intellectual Property Statement 515 The IETF takes no position regarding the validity or scope of any 516 Intellectual Property Rights or other rights that might be claimed to 517 pertain to the implementation or use of the technology described in 518 this document or the extent to which any license under such rights 519 might or might not be available; nor does it represent that it has 520 made any independent effort to identify any such rights. Information 521 on the procedures with respect to rights in RFC documents can be 522 found in BCP 78 and BCP 79. 524 Copies of IPR disclosures made to the IETF Secretariat and any 525 assurances of licenses to be made available, or the result of an 526 attempt made to obtain a general license or permission for the use of 527 such proprietary rights by implementers or users of this 528 specification can be obtained from the IETF on-line IPR repository at 529 http://www.ietf.org/ipr. 531 The IETF invites any interested party to bring to its attention any 532 copyrights, patents or patent applications, or other proprietary 533 rights that may cover technology that may be required to implement 534 this standard. Please address the information to the IETF at 535 ietf-ipr@ietf.org. 537 Full Copyright Statement 539 Copyright (C) The IETF Trust (2007). 541 This document is subject to the rights, licenses and restrictions 542 contained in BCP 78, and except as set forth therein, the authors 543 retain all their rights. 545 This document and the information contained herein are provided on an 546 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 547 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 548 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 549 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 550 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 551 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 553 Acknowledgment 555 Funding for the RFC Editor function is currently provided by the 556 Internet Society.