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.