idnits 2.17.1 draft-asaeda-mmusic-img-arch-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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 532. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 27, 2006) is 6632 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: '8' is defined on line 458, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '4') (Obsoleted by RFC 4566) == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-sdpng-07 == Outdated reference: A later version (-03) exists of draft-greifenberg-mmusic-img-urn-01 == Outdated reference: A later version (-07) exists of draft-walsh-mmusic-img-envelope-03 -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '14') (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group H. Asaeda 3 Internet-Draft K. Mishima 4 Expires: August, 2006 Keio University 5 Y. Nomura 6 J. Ogawa 7 Fujitsu Labs. 8 February 27, 2006 10 An Architecture for the Access of IMG Metadata 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-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/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document defines an architecture for the access of Internet 42 Media Guide (IMG) metadata. An IMG is a structured collection of 43 multimedia session descriptions expressed using SDP, SDPng or some 44 similar session description format. This document proposes a common 45 architecture that provides the IMG access methods, including the use 46 methods of URN and IMG Envelope. 48 1 Introduction 50 Internet Media Guides (IMGs) [2][3] provide and deliver structured 51 collections of multimedia descriptions expressed using SDP [4], SDPng 52 [5] or other description formats. They are used to describe sets of 53 multimedia services (e.g. television program schedules, content 54 delivery schedules) and refer to other networked resources including 55 web pages. 57 IMG metadata may be delivered to a potentially large audience, who 58 use it to join a subset of the sessions described, and who may need 59 to be notified of changes to the IMG metadata. Since content and its 60 structure described by IMG metadata changes as time elapses, an IMG 61 receiver needs to be notified of changes so that IMG metadata and 62 content do not become stale. 64 This document defines an architecture for the access of IMG metadata, 65 which satisfies the IMG framework [2] and matches the IMG 66 requirements [3]. 68 The IMG framework [2] defines a set of abstract operations for large- 69 scale multicast distribution ("IMG ANNOUNCE"), individual 70 subscription and asynchronous (change) notification ("IMG SUBSCRIBE" 71 and "IMG NOTIFY"), and interactive retrieval ("IMG QUERY" and "IMG 72 RESOLVE"). This document clarifies the common mechanism that 73 provides the IMG access methods, including the use methods of these 74 corresponding operations and specifications. 76 2 Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [1]. 82 Internet Media Guide (IMG): IMG is a generic term to describe the 83 formation, delivery and use of IMG metadata. The definition of 84 the IMG is intentionally left imprecise [2]. 86 IMG Element: The smallest atomic element of metadata that can be 87 transmitted separately by IMG operations and referenced 88 individually from other IMG elements [2]. 90 IMG Metadata: A set of metadata consisting of one or more IMG 91 elements. IMG metadata describes the features of multimedia 92 content used to enable selection of and access to media sessions 93 containing content. For example, metadata may consist of the URI, 94 title, airtime, bandwidth needed, file size, text summary, genre 95 and access restrictions [2]. 97 IMG Operation: An atomic operation of an IMG transport protocol, used 98 between IMG sender(s) and IMG receiver(s) for the delivery of IMG 99 metadata and for the control of IMG sender(s)/receiver(s) [2]. 101 IMG Transport Protocol: A protocol that transports IMG metadata from 102 an IMG sender to IMG receiver(s) [2]. 104 IMG Transport Session: An association between an IMG sender and one 105 or more IMG receivers within the scope of an IMG transport 106 protocol. An IMG transport session involves a time bound series 107 of IMG transport protocol interactions that provide delivery of 108 IMG metadata from the IMG sender to the IMG receiver(s) [2]. 110 IMG Sender: An IMG sender is a logical entity that sends IMG metadata 111 to one or more IMG receivers [2]. 113 IMG Receiver: An IMG receiver is a logical entity that receives IMG 114 metadata from an IMG sender [2]. 116 IMG Pointer: An IMG pointer provides an abstract description that 117 points out IMG metadata. For example, an IMG pointer could be 118 described by URL or IMG URN that locates IMG metadata. An IMG 119 pointer itself does not include IMG metadata. 121 IMG URN: IMG URN defines a Uniform Resource Name (URN) namespace for 122 IMG. It describes a persistent and location-independent 123 identifier for IMG metadata or a list of IMG metadata. It can 124 instantiate an IMG pointer. 126 IMG Envelope: An IMG envelope specifies a common encapsulation format 127 for metadata in support of the IMG operations. 129 Complete IMG Description: A complete IMG description means the 130 complete information of IMG metadata. This does NOT mean 131 "complete IMG metadata", which represents the complete IMG 132 metadata database an IMG sender holds. 134 Delta IMG Description: A delta IMG description provides only part of 135 a complete IMG description, defining the difference from a 136 previous version of the complete IMG description. 138 DDDS: Dynamic Delegation Discovery System (DDDS) [9] [10] [11] [12] 139 is an abstract algorithm for applying dynamically retrieved 140 string transformation rules to an application-unique string. 142 3 Expression of IMG Metadata 144 3.1 IMG Metadata Identification 145 An IMG receiver communicates with an IMG sender to obtain IMG 146 metadata that the IMG receiver is interested in. IMG metadata should 147 be in general uniquely identified. 149 This document uses IMG Uniform Resource Name (URN) for an identifier 150 of IMG metadata. It provides persistent and location-independent 151 information, and any contents can be uniquely identified even with 152 elapsed time. Hence even if the IMG metadata is relayed or cached by 153 different IMG entities, it has the unique identifier in the 154 corresponding IMG URN and can refer the same contents. 156 In addition, IMG URN can be represented in a format depending upon 157 the context of their use. For example, an IMG receiver cannot specify 158 concrete IMG metadata but can specify an abstract description such as 159 "all IMG metadata you know so far". Thus, one IMG URN description may 160 describe the different IMG metadata when IMG URN means the context- 161 dependent IMG metadata. 163 This document does not assume any specific description for IMG URN; 164 however, IMG URN should be specified by another document. An IMG URN 165 scheme is being defined in a companion draft where [6] may be the 166 candidate. 168 An IMG receiver can initiate an IMG transport session with an 169 appropriate IMG sender, after it refers a resolution system (e.g. 170 DDDS, which will be explained later) with IMG URN and resolves the 171 IMG sender that provides corresponding IMG metadata. 173 On the other hand, IMG metadata may be updated with time due to the 174 change of the contents. While an IMG receiver wants to obtain a 175 complete IMG description in the initial access, it may want to obtain 176 a delta IMG description later as it already has obtained the previous 177 complete IMG metadata. To deal with either condition, IMG URN should 178 express the version of IMG metadata. This version expresses update of 179 IMG metadata, and IMG envelope (mentioned in the next section) may 180 also include the same version information. However, the detail 181 discussion regarding how the delta IMG description is expressed is an 182 *open issue* of this document. 184 3.2 IMG URN and IMG Envelope 186 While IMG URN provides an identifier of each IMG metadata, the IMG 187 envelope provides a format to encapsulate and carry IMG metadata, IMG 188 URN, or an IMG pointer used in IMG transport protocols. The IMG 189 envelope is independent from an IMG transport protocol. Encapsulated 190 IMG metadata, IMG URN, or an IMG pointer in the IMG envelope 191 expresses XML based format or MIME based format. 193 An IMG envelope can specify version, update and expiration 194 information of the encapsulated or pointed IMG metadata. The 195 information may be used for an IMG receiver to obtain a delta IMG 196 description and recognize the difference from the IMG metadata the 197 IMG receiver already has. Hence, an IMG envelope must keep 198 consistency with encapsulated information. If an IMG envelope does 199 not encapsulate corresponding IMG URN, it should specify the 200 information. If an IMG envelope encapsulates IMG URN and also 201 specifies the information, it must preserve consistency of the 202 information of the corresponding IMG metadata. 204 This document does not assume any specific description for an IMG 205 envelope; however, an IMG envelope should be specified by another 206 document. There is a candidate document [7] for an IMG envelope. In 207 addition, this document does not mention the use case or the scenario 208 of IMG metadata, IMG URN, or an IMG pointer. It is an *open issue* 209 that in which case IMG envelope encapsulates what kind of information 210 (i.e. IMG metadata, IMG URN, or an IMG pointer). 212 4 Access to IMG Metadata 214 The typical scenario that an IMG receiver obtains IMG metadata 215 consists of the following three phases: (1) an IMG receiver obtains 216 IMG URN, (2) an IMG receiver resolves corresponding IMG sender(s), 217 and (3) an IMG receiver starts an IMG transport session to obtain its 218 interesting IMG metadata from the IMG sender. 220 4.1 Register and Obtain IMG URN 222 As one of the possible systems, this document uses Dynamic Delegation 223 Discovery System (DDDS) [9] [10] [11] [12] to manage IMG URN that 224 expresses IMG metadata. Network administrators or operators, or 225 contents providers register IMG URN in their DDDS. Remember that 226 complete IMG metadata database is maintained by an IMG sender, yet 227 the discussion how they register information of IMG URN is out of 228 scope of this document. 230 To access an IMG sender and obtain IMG metadata from the IMG sender, 231 an IMG receiver needs to know IMG URN beforehand. IMG URN may be 232 obtained from a site-local administrator who maintains the network 233 that the IMG receiver belongs to by an email or other tool. Or, it 234 may be announced by some auto-configuration protocol [13] [14], 235 whereas the operation or the protocol how IMG URN can be obtained 236 dynamically is out of scope of this document. 238 4.2 DDDS-Based URN Resolution and IMG Operation 240 When an IMG receiver does not know the information about a 241 corresponding IMG sender or IMG metadata, it uses the access method 242 of DDDS to resolve IMG URN. DDDS gives (1) a list of corresponding 243 IMG sender address(es) with preference, and (2) an IMG transport 244 protocol each IMG sender uses. 246 Figure 1 shows an IMG operation among an IMG sender, an IMG receiver, 247 and DDDS. It expresses (1) the procedure for an IMG receiver to 248 resolve initial information including an IMG sender, and (2) the 249 operation to obtain complete IMG description from the IMG sender. 251 Register IMG URN and 252 corresponding information---+ 253 | 254 +---Obtain IMG URN | 255 | | 256 V V 257 +--------------+ +------------+ +--------+ 258 | IMG Receiver | | IMG Sender | | DDDS | 259 +--------------+ +------------+ +--------+ 260 | | | 261 |-----------DDDS-Based URN resolution-------->| 262 | | | 263 |<-------------------Response-----------------| 264 | | | 265 |---Start IMG | | 266 | transport session--->| | 267 | | | 268 |<--Obtain IMG metadata--| | 270 Figure 1: DDDS-based URN resolution and an IMG operation 271 to access IMG metadata 273 After DDDS receives a query message from an IMG receiver with IMG 274 URN, DDDS responds to tell a list of IMG senders to the IMG receiver. 275 This list contains available IMG senders in the network the IMG 276 receiver belongs to. When DDDS gives the available IMG senders with 277 preference or with indicating different IMG protocols, the IMG 278 receiver selects an appropriate IMG sender from the list of the 279 available IMG senders. Knowing which IMG sender is appropriate and 280 how an IMG receiver selects an appropriate operation is currently an 281 *open issue* of this document. 283 When an IMG receiver specifies an IMG sender in the DDDS query 284 message and sends the message to DDDS, DDDS replies the availability 285 and an IMG protocol the IMG sender uses. An IMG receiver may not need 286 to resolve the IMG URN. For instance, the IMG receiver obtains the 287 same information to start the IMG transport session as the prior IMG 288 URN which has already been resolved by DDDS. 290 4.3 Obtain IMG Metadata 292 After an IMG receiver decides a corresponding IMG sender and IMG 293 operation, it starts an IMG transport session with the IMG sender to 294 obtain complete or delta IMG descriptions. The IMG transport session 295 and the following procedures depend on the IMG operation and is 296 decided by the IMG protocol the corresponding IMG sender supports. 298 An IMG receiver may request to obtain various sets of IMG metadata, 299 e.g. metadata expressing a single or multiple contents an IMG sender 300 maintains. IMG URN should therefore define the corresponding value to 301 express these sets, whereas its concrete format and value will be 302 defined in another document (e.g. [6]). This requirement may include 303 the specification of filtering unneeded information from the given 304 metadata, because the size of the complete IMG metadata may be huge 305 in some case. This specification will be also included in another 306 document or in this document in the future. 308 4.3.1 IMG ANNOUNCE 310 With the use of an IMG ANNOUNCE, an IMG receiver participates in an 311 IMG transport session without notifying or sending any message to an 312 IMG sender. Only an IMG receiver needs to prepare to receive IMG 313 metadata via an IMG ANNOUNCE. An IMG ANNOUNCE may carry a complete or 314 delta IMG description, or may carry an IMG pointer. In this 315 operation, using broadcast would be common. 317 4.3.2 IMG SUBSCRIBE and IMG NOTIFY 319 An IMG SUBSCRIBE is used to ask IMG metadata to an IMG sender and an 320 IMG NOTIFY is used to notify IMG metadata to an IMG receiver. In 321 these operations, an IMG receiver behaves as an IMG subscriber, and 322 an IMG sender behaves as an IMG notifier. An IMG NOTIFY may carry a 323 complete or delta IMG description, or may carry an IMG pointer. These 324 operations use a bi-directional transport session between an IMG 325 receiver and an IMG sender. 327 4.3.3 IMG QUERY and IMG RESOLVE 329 An IMG QUERY initiates a receiver-driven IMG transport session, and 330 an IMG RESOLVE responds the IMG QUERY and sends IMG metadata to the 331 IMG receiver. An IMG RESOLVE may carry a complete or delta IMG 332 description, or may carry an IMG pointer. These operations use a bi- 333 directional transport session between an IMG receiver and an IMG 334 sender. 336 4.4 Update of IMG Metadata 338 While an IMG receiver may often need to update IMG metadata to the 339 latest one, getting a complete IMG description is not always 340 effective. The IMG framework [2] proposes to use a delta IMG 341 description that provides only part of a complete IMG description, 342 defining the difference from a previous version of the complete IMG 343 description. The framework does not represent a complete set of 344 metadata until it is combined with other metadata that may already 345 exist or arrive in the future. 347 4.4.1 IMG ANNOUNCE or IMG NOTIFY 349 +--------------+ +------------+ 350 | IMG Receiver | | IMG Sender | 351 +--------------+ +------------+ 352 | | 353 |-------- Start IMG transport session ------->| 354 : : 355 : : 356 |<-------- IMG ANNOUNCE or IMG NOTIFY --------| 357 | with delta IMG description | 358 | or | 359 | with IMG pointer to delta IMG description | 361 Figure 2: Update operation by IMG ANNOUNCE or NOTIFY 363 Some IMG sender implementations send the latest complete IMG 364 description repeatedly by an IMG ANNOUNCE or an IMG NOTIFY, and other 365 IMG sender implementations send IMG ANNOUNCE or IMG NOTIFY messages 366 with a delta IMG description or an IMG pointer to a delta IMG 367 description when necessary. 369 To receive IMG NOTIFY messages, an IMG subscriber must initiate an 370 IMG transport session to an IMG notifier by sending an IMG SUBSCRIBE 371 message beforehand. Then, the IMG notifier sends the IMG NOTIFY 372 message when IMG metadata should be updated in the IMG subscriber. 374 4.4.2 IMG QUERY and IMG RESOLVE 376 This query operation is similar to a general polling method. Both of 377 an IMG sender and an IMG receiver need a bi-directional transport to 378 fulfill the operation. In these operations, using unicast or 379 multicast would be common. 381 4.5 Use of IMG Pointer 382 +--------------+ +------------+ +--------+ 383 | IMG Receiver | | IMG Sender | | DDDS | 384 +--------------+ +------------+ +--------+ 385 | | | 386 |-----------DDDS-Based URN resolution-------->| 387 | | | 388 |<-------------------Response-----------------| 389 | | | 390 |---Start IMG | | 391 | transport session--->| | 392 | | | 393 |<--Obtain IMG pointer---| | 394 | | | 395 ( |----Query to know additional information---->| ) 396 ( | | | ) 397 ( |<-------------------Response-----------------| ) 398 | | | 399 |----Start IMG QUERY---->| | 400 | | | 401 |<--Obtain IMG metadata--| | 403 Figure 3: Use case of IMG Pointer 405 If an IMG receiver receives an IMG pointer, it will be able to obtain 406 IMG metadata by additional independent operations. Currently, there 407 would be no contradiction of the use of IMG pointer for any 408 operation, this document needs to clarify the detail and concrete use 409 cases of an IMG pointer. 411 5 Security Considerations 413 TBD 415 6 IANA Considerations 417 This document does not request any IANA action. 419 7 ToDo 421 We recognize the following discussions are needed: (1) use of 422 companion drafts defining the spec of an IMG envelope and IMG URN, 423 (2) definition of use method of DDDS, (3) definition of use method of 424 IMG pointer, and (4) consideration of an IMG transceiver and its role 425 in this architecture. Open issues described above should be also 426 clarified in the revised version of this document. 428 8 Normative References 430 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 431 levels," RFC 2119, March 1997. 433 9 Informative References 435 [2] Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, and H. Schulzrinne, 436 "A framework for the usage of Internet media guides," Internet Draft, 437 draft-ietf-mmusic-img-framework-09, December 2005. Work in progress. 439 [3] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, and H. Schulzrinne, 440 "Requirements for Internet Media Guides," Internet Draft, draft-ietf- 441 mmusic-img-req-08, December 2005. Work in progress. 443 [4] M. Handley and V. Jacobson, "SDP: session description protocol," 444 RFC 2327, April 1998. 446 [5] D. Kutscher, J. Ott, and C. Bormann, "Session description and 447 capability negotiation," Internet Draft, draft-ietf-mmusic-sdpng-07, 448 October 2003. Work in progress. 450 [6] J. Greifenberg, "Identifiers for Internet Media Guides (IMG)," 451 Internet Draft, draft-greifenberg-mmusic-img-urn-01, December 2005. 452 Work in progress. 454 [7] R. Walsh, J-P. Luoma, J. Peltotalo, S. Peltotalo, and J. 455 Greifenberg, "The IMG Envelope," Internet Draft, draft-walsh-mmusic- 456 img-envelope-03, June 2005. Work in progress. 458 [8] J. Ott and K. Loos, "Using HTTP for IMG Transport," Internet 459 Draft, draft-ott-mmusic-img-http-00, October 2005. Work in progress. 461 [9] M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part 462 One: The Comprehensive DDDS," RFC 3401, October 2002. 464 [10] M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part 465 Two: The Algorithm," RFC 3402, October 2002. 467 [11] M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part 468 Three: The Domain Name System (DNS) Database," RFC 3403, October 469 2002. 471 [12] M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part 472 Four: The Uniform Resource Identifiers (URI)," RFC 3404, October 473 2002. 475 [13] R. Droms, "Dynamic Host Configuration Protocol," RFC 2131, March 476 1997. 478 [14] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, and M. 479 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)," RFC 480 3315, July 2003. 482 Authors' Addresses 484 Hitoshi Asaeda 485 Graduate School of Media and Governance 486 Keio University 487 5322 Endo, Fujisawa, 252-8520 Kanagawa, 488 Japan 489 Email: asaeda (at) wide.ad.jp 491 Kazuhiro Mishima 492 Graduate School of Media and Governance 493 Keio University 494 5322 Endo, Fujisawa, 252-8520 Kanagawa, 495 Japan 496 Email: three (at) sfc.wide.ad.jp 498 Yuji Nomura 499 Fujitsu Laboratories Ltd. 500 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki, 211-8588 Kanagawa, 501 Japan 502 Email: nom (at) flab.fujitsu.co.jp 504 Jun Ogawa 505 Fujitsu Laboratories Ltd. 506 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki, 211-8588 Kanagawa, 507 Japan 508 Email: ogawa.jun (at) jp.fujitsu.com 510 Intellectual Property Statement 512 The IETF takes no position regarding the validity or scope of any 513 Intellectual Property Rights or other rights that might be claimed to 514 pertain to the implementation or use of the technology described in 515 this document or the extent to which any license under such rights 516 might or might not be available; nor does it represent that it has 517 made any independent effort to identify any such rights. Information 518 on the procedures with respect to rights in RFC documents can be 519 found in BCP 78 and BCP 79. 521 Copies of IPR disclosures made to the IETF Secretariat and any 522 assurances of licenses to be made available, or the result of an 523 attempt made to obtain a general license or permission for the use of 524 such proprietary rights by implementers or users of this 525 specification can be obtained from the IETF on-line IPR repository at 526 http://www.ietf.org/ipr. 528 The IETF invites any interested party to bring to its attention any 529 copyrights, patents or patent applications, or other proprietary 530 rights that may cover technology that may be required to implement 531 this standard. Please address the information to the IETF at ietf- 532 ipr@ietf.org. 534 Disclaimer of Validity 536 This document and the information contained herein are provided on an 537 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 538 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 539 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 540 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 541 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 542 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 544 Copyright Statement 546 Copyright (C) The Internet Society (2005). This document is subject 547 to the rights, licenses and restrictions contained in BCP 78, and 548 except as set forth therein, the authors retain all their rights. 550 Acknowledgement 552 Funding for the RFC Editor function is currently provided by the 553 Internet Society.