idnits 2.17.1
draft-ietf-sipping-multiple-refer-06.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 20.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 545.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 556.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 563.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 569.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== It seems as if not all pages are separated by form feeds - found 0 form
feeds but 14 pages
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHOULD not' in this paragraph:
The REFER-Recipient SHOULD not create an implicit subscription, and
SHOULD add a Refer-Sub header field set to "false" in the 200 OK response.
-- 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 22, 2006) is 6519 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)
== Outdated reference: A later version (-07) exists of
draft-ietf-sipping-uri-services-05
== Outdated reference: A later version (-07) exists of
draft-ietf-sipping-capacity-attribute-00
== Outdated reference: A later version (-15) exists of
draft-ietf-sip-gruu-07
Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIPPING Working Group G. Camarillo
3 Internet-Draft Ericsson
4 Intended status: Standards Track A. Niemi
5 Expires: December 24, 2006 M. Isomaki
6 M. Garcia-Martin
7 Nokia
8 H. Khartabil
9 Telio
10 June 22, 2006
12 Refering to Multiple Resources in the Session Initiation Protocol (SIP)
13 draft-ietf-sipping-multiple-refer-06.txt
15 Status of this Memo
17 By submitting this Internet-Draft, each author represents that any
18 applicable patent or other IPR claims of which he or she is aware
19 have been or will be disclosed, and any of which he or she becomes
20 aware will be disclosed, in accordance with Section 6 of BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as Internet-
25 Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 This Internet-Draft will expire on December 24, 2006.
40 Copyright Notice
42 Copyright (C) The Internet Society (2006).
44 Abstract
46 This document defines extensions to the SIP REFER method so that this
47 method can be used to refer servers to multiple resources. These
48 extensions include the use of pointers to Uniform Resource Identifier
49 (URI)-lists in the Refer-To header field and the "multiple-refer" SIP
50 option-tag.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
56 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 3
57 4. The multiple-refer SIP Option-Tag . . . . . . . . . . . . . . 4
58 5. Suppressing REFER's Implicit Subscription . . . . . . . . . . 4
59 6. URI-List Format . . . . . . . . . . . . . . . . . . . . . . . 5
60 7. Behavior of SIP REFER-Issuers . . . . . . . . . . . . . . . . 7
61 8. Behavior of REFER-Recipients . . . . . . . . . . . . . . . . . 7
62 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
64 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
66 12.1. Normative References . . . . . . . . . . . . . . . . . . 10
67 12.2. Informational References . . . . . . . . . . . . . . . . 11
68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
69 Intellectual Property and Copyright Statements . . . . . . . . . . 14
71 1. Introduction
73 The SIP [5] REFER method [7] allows a user agent to request a server
74 to send a request to a third party. Still, a number of applications
75 need to request a server to initiate transactions towards a set of
76 destinations. In one example, the moderator of a conference may want
77 the conference server to send BYE requests to a group of
78 participants. In another example, the same moderator may want the
79 conference server to INVITE a set of new participants.
81 We define an extension to REFER so that REFER can be used to refer
82 servers to multiple destinations. In addition, this mechanism uses
83 the suppression of the REFER method implicit subscription specified
84 in RFC 4488 [8] to suppress REFER's implicit subscription.
86 2. Terminology
88 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
89 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
90 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
91 described in BCP 14, RFC 2119 [1] and indicate requirement levels for
92 compliant implementations.
94 We define the following three new terms:
96 REFER-Issuer: the user agent issuing the REFER request.
97 REFER-Recipient: the user agent receiving the REFER request.
98 REFER-Target: the intended final recipient of the request to be
99 generated by the REFER-Recipient.
101 3. Overview of operation
103 This document defines an extension to the SIP REFER method [7] that
104 allows a SIP User Agent Client (UAC) to include a URI-list [9] of
105 REFER-Targets in a REFER request and send it to a server. The server
106 will create a new request for each entry in the list of REFER-Target
107 URIs.
109 The URI-list of REFER-Targets is used in conjunction with the
110 capacity attribute extension [11] to allow the sender indicate the
111 capacity (e.g., 'to', 'cc', or anonymous) in which the REFER-Target
112 is involved in the signalling.
114 We represent the multiple REFER-Targets of a REFER using a URI-list
115 [9]. A UAC (User Agent Client) that wants to refer a server to a set
116 of destinations creates a SIP REFER request. The Refer-To header
117 contains a pointer to a URI-list, which is included in a body part,
118 and an option-tag in the Required header field: "multiple-refer".
119 This option-tag indicates the requirement to support the
120 functionality described in this specification.
122 When the server receives such request it creates a new request per
123 destination and sends them.
125 This document does not provide any mechanism for UACs to find out
126 about the results of a REFER with multiple REFER-Targets.
127 Furthermore, it does not provide support for the implicit
128 subscription mechanism that is part of the SIP REFER method. The way
129 UACs are kept informed about the results of a REFER is service
130 specific. For example, a UAC sending a REFER to INVITE a set of
131 participants to a conference may discover which participants were
132 successfully brought into the conference by subscribing to the
133 conference state event [13].
135 4. The multiple-refer SIP Option-Tag
137 We define a new SIP option-tag for the Require and Supported header
138 fields: "multiple-refer".
140 A user agent including the "multiple-refer" option-tag in a Supported
141 header field indicates compliance with this specification.
143 A user agent generating a REFER with a pointer to a URI-list in its
144 Refer-To header field MUST include the "multiple-refer" option-tag in
145 the Require header field of the REFER.
147 5. Suppressing REFER's Implicit Subscription
149 REFER requests with a single REFER-Target establish implicitly a
150 subscription to the refer event. The REFER-Issuer is informed about
151 the result of the transaction towards the REFER-Target through this
152 implicit subscription. As described in RFC 3515 [7], NOTIFY requests
153 sent as a result of an implicit subscription created by a REFER
154 request contain a body of type "message/sipfrag" [6] that describes
155 the status of the transaction initiated by the REFER-Recipient.
157 In the case of a REFER-Issuer that generates a REFER with multiple
158 REFER-targets, the REFER-Issuer is typically already subscribed to
159 other event package that can provide the information about the result
160 of the transactions towards the REFER-Targets. For example, a
161 moderator instructing a conference server to send a BYE request to a
162 set of participants is usually subscribed to the conference state
163 event package for the conference. Notifications to this event
164 package will keep the moderator and the rest of the subscribers
165 informed of the current list of conference participants.
167 Most of the applications using multiple REFER do not need its
168 implicit subscription. Consequently, a SIP REFER-Issuer generating a
169 REFER request with multiple REFER-Targets SHOULD include the
170 "norefersub" option-tag in a Require header field and SHOULD include
171 a Refer-Sub header field set to "false" to indicate that no
172 notifications about the requests should be sent to the REFER-Issuer.
173 The REFER-Recipient SHOULD honor the suggestion and also include a
174 Refer-Sub header field set to "false" in the 200 OK response. The
175 "norefersub" SIP option-tag and the Refer-Sub header field are
176 specified in RFC 4488 [8].
178 RFC 4488 [8] indicates that a condition for the REFER-Issuer to
179 include a Refer-Sub header is that the REFER-Issue is sure that
180 the REFER request will not fork.
182 At the time of writing, there is no extension that allows to report
183 the status of several transactions over a REFER's implicit
184 subscription. That is the motivation for this document to recommend
185 the usage of the "norefersub" option-tag. If in the future such an
186 extension is defined, REFER-Issuers using it could refrain from using
187 the "norefersub" option-tag and use the new extension instead.
189 6. URI-List Format
191 As described in the Framework and Security Considerations for SIP
192 URI-List Services [10], specifications of individual URI-list
193 services, need to specify a default format for 'recipient-list'
194 bodies used within the particular service.
196 The default format for 'recipient-list' bodies for conferencing UAs
197 (User Agents) and servers is the XML resource list format [9]
198 extended with the XML Format Extension for Representing Capacity
199 Attributes in Resource Lists [11]. UAs handling 'recipient-list'
200 bodies MUST support both of these formats and MAY support other
201 formats.
203 As described in the XML Format Extension for Representing Capacity
204 Attributes in Resource Lists [11], each URI can be tagged with a
205 'capacity' attribute set to either "to", "cc", or "bcc", indicating
206 the capacity or role in which the recipient will get the referred SIP
207 request. However, it must be noted that, depending on the target SIP
208 method, a 'capacity' attribute may not have sense. For example,
209 while a 'capacity' attribute can be applied to INVITE requests, it
210 may not make sense with mid-dialog requests such as BYE requests.
212 In addition to the 'capacity' attribute, URIs can be tagged with the
213 'anonymize' attribute, also specified in the XML Format Extension for
214 Representing Capacity Attributes in Resource Lists [11] to prevent
215 that the server discloses the target URI in a URI-list.
217 Additionally, the XML Format Extension for Representing Capacity
218 Attributes in Resource Lists [11] defines a 'recipient-list-history'
219 body that contains the list of recipients. The default format for
220 'recipient-list-history' bodies for conference services is also the
221 XML resource list document format [7] extended with the XML Format
222 Extension for Representing Capacity Attributes in Resource Lists [8].
223 Conferencing servers MUST support both of these formats; UASes MAY
224 support these formats. Both conferencing servers and UASes MAY
225 support other formats.
227 Nevertheless, the XML resource list document [9] provides features,
228 such as hierarchical lists and the ability to include entries by
229 reference relative to the XCAP root URI, that are not needed by the
230 multiplet REFER service defined in this document. Therefore, when
231 using the default resource list document, SIP REFER-Issuers
232 generating REFERs with multiple REFER-Targets SHOULD use flat lists
233 (i.e., no hierarchical lists) and SHOULD NOT use %lt;entry-ref>
234 elements.
236 A REFER-Recipient receiving a URI-list with more information than
237 what has just been described MAY discard all the extra information.
239 Figure 1 shows an example of a flat list that follows the resource
240 list document.
242
243
246
247
248
249
250
251
253 Figure 1: URI List
255 7. Behavior of SIP REFER-Issuers
257 As indicated in Section 4 and Section 5 a SIP REFER-Issuer that
258 creates a REFER request with multiple REFER-Targets includes a
259 "multiple-refer" and "norefersub" option-tags in the Require header
260 field and, if appropriate, a Refer-Sub header field set to "false".
261 The REFER-Issuer includes the set of REFER-Targets in body whose
262 disposition type is 'recipient-list', as defined in the Framework and
263 Security Considerations for SIP URI-List Services [10]. The URI-list
264 body is further described in Section 6.
266 The Refer-To header field of a REFER request with multiple REFER-
267 Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource
268 Locator (URL) [3] ) that points to the body part that carries the
269 URI-list. The REFER-Issuer SHOULD NOT include any particular URI
270 more than once in the URI-list.
272 8. Behavior of REFER-Recipients
274 The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515
275 [7] to determine the status code of the response to the REFER.
277 The REFER-Recipient SHOULD not create an implicit subscription, and
278 SHOULD add a Refer-Sub header field set to "false" in the 200 OK
279 response.
281 If the URI-list of the REFER request contains a repeated URI, the
282 REFER-Recipient MUST behave as if that URI appeared in the URI-list
283 only once. The REFER-Recipient uses the comparison rules specific to
284 the URI scheme of each of the URIs in the URI-list to determine if
285 there is any URI which appears more than once.
287 The incoming REFER request typically contains a URI-list document or
288 reference with the actual list of recipients. If this URI-list
289 includes resources tagged with the 'capacity' attribute set to a
290 value of "to" or "cc", and if appropriate for the service, e.g., if
291 it is non-mid dialog request, the URI-list server SHOULD include a
292 URI-list in each of the outgoing requests. This list SHOULD be
293 formatted according to the XML format for representing resource lists
294 [9] and the capacity extension [11]. The URI-list server MUST follow
295 the procedures specified in XML format for representing resource
296 lists [9] with respect handling of the 'anonymize', 'count' and
297 'capacity' attributes.
299 If the server includes a URI-list in an outgoing request, it MUST
300 include a Content-Disposition header field [2] with the value set to
301 'recipient-list-history' and a 'handling' parameter [4] set to
302 "optional".
304 The REFER-Recipient follows the rules in RFC 3515 [7] to generate the
305 necessary requests towards the REFER-Targets, acting as if it had
306 received a regular (no URI-list) REFER per each URI in the URI-list.
308 9. Example
310 Figure 2 shows an example flow where a REFER-Issuer sends a multiple-
311 REFER request to the focus of a conference, which acts as the REFER-
312 Recipient. The REFER-Recipient generates a BYE request per REFER-
313 Target. (How to use REFER to remove participants from a conference
314 is specified in [14].)
316 +--------+ +---------+ +--------+ +--------+ +--------+
317 | REFER | | REFER | | REFER | | REFER | | REFER |
318 | issuer | |recipient| |target 1| |target 2| |target 3|
319 +--------+ +---------+ +--------+ +--------+ +--------+
320 | 1. REFER | | | |
321 | ---------------->| | | |
322 | 2. 202 Accepted | | | |
323 |<---------------- | 3. BYE | | |
324 | | ----------->| | |
325 | | 4. BYE | | |
326 | | ----------------------->| |
327 | | 5. BYE | | |
328 | | ----------------------------------->|
329 | | 6. 200 OK | | |
330 | |<----------- | | |
331 | | 7. 200 OK | | |
332 | |<----------------------- | |
333 | | 8. 200K OK| | |
334 | |<----------------------------------- |
335 | | | | |
336 | | | | |
337 | | | | |
339 Figure 2: Example flow or a REFER request containin multiple REFER-
340 Targets
342 The REFER request (1) contains a Refer-To header field that includes
343 a pointer to the message body, which carries a list with the URIs of
344 the REFER-Targets. In this example, the URI-list does not contain
345 the capacity attribute extension. The REFER's Require header field
346 carries the "multiple-refer" and "norefersub" option-tags. The
347 Request-URI is set to a Globally Routable User Agent URIs (GRUU) [12]
348 (as a guarantee that the REFER request will not fork). The Refer-Sub
349 header field is set to "false" to request the suppression of the
350 implicit subscription. Figure 3 shows an example of this REFER
351 request. The resource list document contains the list of REFER-
352 Target URIs along with the method of the SIP request that the REFER-
353 Recipient generates.
355 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0
356 Via: SIP/2.0/TCP client.chicago.example.com
357 ;branch=z9hG4bKhjhs8ass83
358 Max-Forwards: 70
359 To: "Conference 123"
360 From: Carol ;tag=32331
361 Call-ID: d432fa84b4c76e66710
362 CSeq: 2 REFER
363 Contact:
364 Refer-To:
365 Refer-Sub: false
366 Require: multiple-refer, norefersub
367 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
368 Allow-Events: dialog
369 Accept: application/sdp, message/sipfrag
370 Content-Type: application/resource-lists+xml
371 Content-Disposition: recipient-list
372 Content-Length: 362
373 Content-ID:
375
376
378
379
380
381
382
383
385 Figure 3: REFER request with multiple REFER-Targets
387 Figure 4 shows an example of the BYE request (3) that the REFER-
388 Recipient sends to the first REFER-Target.
390 BYE sip:bill@example.com SIP/2.0
391 Via: SIP/2.0/TCP conference.example.com
392 ;branch=z9hG4bKhjhs8assmm
393 Max-Forwards: 70
394 From: "Conference 123" ;tag=88734
395 To: ;tag=29872
396 Call-ID: d432fa84b4c34098s812
397 CSeq: 34 BYE
398 Content-Length: 0
400 Figure 4: BYE request
402 10. Security Considerations
404 The Framework and Security Considerations for SIP URI-List Services
405 [10] discusses issues related to SIP URI-list services. Given that a
406 server accepting REFERs with multiple REFER-targets acts as an URI-
407 list service, implementations of this type of server MUST follow the
408 security-related rules in [10]. These rules include mandatory
409 authentication and authorization of clients, and opt-in lists.
411 Additionally, servers SHOULD only accept REFER requests within the
412 context of an application the server understands (e.g., a
413 conferencing application). This implies that servers MUST NOT accept
414 REFERs for methods they do not understand. The idea behind these two
415 rules is that servers are not used as dumb servers whose only
416 function is to fan-out random messages they do not understand.
418 11. IANA Considerations
420 This document defines a new SIP option-tag: "multiple-refer". This
421 option-tag should be registered in the SIP Parameters registry.
423 SIP user agents that place the "multiple-refer" option-tag in a
424 Supported header field understand REFER requests that contain
425 resource list document describing multiple REFER-Targets.
427 12. References
429 12.1. Normative References
431 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
432 Levels", BCP 14, RFC 2119, March 1997.
434 [2] Troost, R., Dorner, S., and K. Moore, "Communicating
435 Presentation Information in Internet Messages: The Content-
436 Disposition Header Field", RFC 2183, August 1997.
438 [3] Levinson, E., "Content-ID and Message-ID Uniform Resource
439 Locators", RFC 2392, August 1998.
441 [4] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
442 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG
443 Objects", RFC 3204, December 2001.
445 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
446 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
447 Session Initiation Protocol", RFC 3261, June 2002.
449 [6] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
450 November 2002.
452 [7] Sparks, R., "The Session Initiation Protocol (SIP) Refer
453 Method", RFC 3515, April 2003.
455 [8] Levin, O., "Suppression of Session Initiation Protocol (SIP)
456 REFER Method Implicit Subscription", RFC 4488, May 2006.
458 [9] Rosenberg, J., "Extensible Markup Language (XML) Formats for
459 Representing Resource Lists",
460 draft-ietf-simple-xcap-list-usage-05 (work in progress),
461 February 2005.
463 [10] Camarillo, G. and A. Roach, "Framework and Security
464 Considerations for Session Initiation Protocol (SIP) Uniform
465 Resource Identifier (URI)-List Services",
466 draft-ietf-sipping-uri-services-05 (work in progress),
467 January 2006.
469 [11] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language
470 (XML) Format Extension for Representing Capacity Attributes in
471 Resource Lists", draft-ietf-sipping-capacity-attribute-00 (work
472 in progress), February 2006.
474 [12] Rosenberg, J., "Obtaining and Using Globally Routable User
475 Agent (UA) URIs (GRUU) in the Session Initiation Protocol
476 (SIP)", draft-ietf-sip-gruu-07 (work in progress), May 2006.
478 12.2. Informational References
480 [13] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
481 Package for Conference State",
482 draft-ietf-sipping-conference-package-12 (work in progress),
483 July 2005.
485 [14] Levin, O., "Session Initiation Protocol Call Control -
486 Conferencing for User Agents",
487 draft-ietf-sipping-cc-conferencing-07 (work in progress),
488 June 2005.
490 Authors' Addresses
492 Gonzalo Camarillo
493 Ericsson
494 Hirsalantie 11
495 Jorvas 02420
496 Finland
498 Email: Gonzalo.Camarillo@ericsson.com
500 Aki Niemi
501 Nokia
502 P.O. Box 321
503 NOKIA GROUP, FIN 00045
504 Finland
506 Email: Aki.Niemi@nokia.com
508 Markus Isomaki
509 Nokia
510 Itamerenkatu 11-13
511 Helsinki 00180
512 Finland
514 Email: Markus.Isomaki@nokia.com
516 Miguel A. Garcia-Martin
517 Nokia
518 P.O.Box 407
519 NOKIA GROUP, FIN 00045
520 Finland
522 Email: miguel.an.garcia@nokia.com
523 Hisham Khartabil
524 Telio
525 P.O. Box 1203
526 Oslo 0110
527 Norway
529 Email: Hisham.Khartabil@telio.no
531 Full Copyright Statement
533 Copyright (C) The Internet Society (2006).
535 This document is subject to the rights, licenses and restrictions
536 contained in BCP 78, and except as set forth therein, the authors
537 retain all their rights.
539 This document and the information contained herein are provided on an
540 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
541 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
542 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
543 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
544 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
545 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
547 Intellectual Property
549 The IETF takes no position regarding the validity or scope of any
550 Intellectual Property Rights or other rights that might be claimed to
551 pertain to the implementation or use of the technology described in
552 this document or the extent to which any license under such rights
553 might or might not be available; nor does it represent that it has
554 made any independent effort to identify any such rights. Information
555 on the procedures with respect to rights in RFC documents can be
556 found in BCP 78 and BCP 79.
558 Copies of IPR disclosures made to the IETF Secretariat and any
559 assurances of licenses to be made available, or the result of an
560 attempt made to obtain a general license or permission for the use of
561 such proprietary rights by implementers or users of this
562 specification can be obtained from the IETF on-line IPR repository at
563 http://www.ietf.org/ipr.
565 The IETF invites any interested party to bring to its attention any
566 copyrights, patents or patent applications, or other proprietary
567 rights that may cover technology that may be required to implement
568 this standard. Please address the information to the IETF at
569 ietf-ipr@ietf.org.
571 Acknowledgment
573 Funding for the RFC Editor function is provided by the IETF
574 Administrative Support Activity (IASA).