idnits 2.17.1 draft-ietf-widex-requirements-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 585. ** 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 issues found here. 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 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 (April 11, 2006) is 6583 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4213' is defined on line 510, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4214 (Obsoleted by RFC 5214) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WIDEX V. Stirbu 3 Internet-Draft Nokia 4 Intended status: Informational D. Raggett 5 Expires: October 13, 2006 W3C/Volantis 6 April 11, 2006 8 Widget Description Exchange Service (WIDEX) Requirements 9 draft-ietf-widex-requirements-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 13, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document defines functional requirements for a framework and a 43 protocol used to support XML-based user interfaces, where the user 44 interface and application logic may be on different machines, and 45 coupled via an exchange of XML DOM events and update/mutation 46 operations. 48 Requirements Language 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [RFC2119]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Widex Entities . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Widex Terminology . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. User Interface . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Remote User Interface . . . . . . . . . . . . . . . . . . 5 63 3.3. Widex Objects . . . . . . . . . . . . . . . . . . . . . . 5 64 3.4. Transport Protocol . . . . . . . . . . . . . . . . . . . . 6 65 3.5. Simple vs. Complex User Interfaces . . . . . . . . . . . . 6 66 3.6. Session . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 6 69 4.1. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1.1. Scenario 1: Widex Server and Renderer Located in 71 Internet . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1.2. Scenario 2: Widex Server Located in Internet . . . . . 7 73 4.1.3. Scenario 3: Widex Renderer and Server in the Same 74 Network . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.2. IPv4-IPv6 Interworking . . . . . . . . . . . . . . . . . . 8 76 4.2.1. Dual-Stack Widex Element Communicating with 77 IPv4-Only Widex Element Using IPv4 . . . . . . . . . . 9 78 4.2.2. Dual-Stack Widex Elements Communicating over IPv4 79 Segment using IPv6 . . . . . . . . . . . . . . . . . . 9 80 4.2.3. IPv4-Only Widex Element communicating with an 81 IPv6-Only Widex Element . . . . . . . . . . . . . . . 9 82 4.2.4. Application Aspects of IPv6 Transition . . . . . . . . 10 84 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 5.1. Architecture Requirements . . . . . . . . . . . . . . . . 10 86 5.2. Discovery and Session Setup Requirements . . . . . . . . . 10 87 5.3. Widex Objects Requirements . . . . . . . . . . . . . . . . 10 88 5.4. Transport Requirements . . . . . . . . . . . . . . . . . . 11 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 100 Intellectual Property and Copyright Statements . . . . . . . . . . 14 102 1. Introduction 104 With the Internet reaching out to more and more devices, people are 105 increasingly expecting to have access to services at anytime, from 106 anywhere and using any device. Such services are being developed 107 using Web technologies such as XML and distributed across the network 108 rather than resident on any one device. 110 2. Widex Entities 112 The following picture shows the primary Widex entities in a simple 113 and basic architecture. 115 +--------+ +--------+ 116 | | update interface | | 117 | Widex |----------------->| Widex | 118 | Server |<-----------------|Renderer| 119 | | event interface | | 120 +--------+ +--------+ 122 Figure 1: Widex Entities 124 The two primary Entities are described as follows: 126 Widex Server (WS): 127 The entity that holds the application logic. 129 Widex Renderer (WR): 130 The entity that renders the user interface. 132 There might be several Widex Servers in the same device, one for each 133 application that can export the user interface and for each Widex 134 server there might be several Widex Renderers which are rendering the 135 user interface. 137 3. Widex Terminology 139 The terminology and definitions detailed below include both terms 140 that, besides the Widex entities are used in the requirements section 141 of this document. 143 3.1. User Interface 145 In the context of Widex working group, the user interface is 146 understood as XML [XML1.0] data describing the user interface. 147 Typically, the XML data is manipulated as levels 2 and 3 in the W3C 148 Document Object Model (DOM), see [DOM2.Core], [DOM3.Core], and 149 [DOM2.Events] (W3C has yet to complete work on DOM3 events). Style 150 information associated with the user interface can be manipulated via 151 the DOM, see [DOM2.Style]. 153 3.2. Remote User Interface 155 The Remote User Interface (RUI) is a technique in which a user 156 interface is rendered on another device than the one that runs the 157 application logic while keeping the user interface synchronised with 158 the application logic. 160 3.3. Widex Objects 162 One of the goals of the Widex working group is to define Widex 163 Objects (WO), to be used to convey information about interface 164 updates and events. WOs are used to keep the rendered user interface 165 synchronised with the application logic. 167 There are two types of WOs: 169 WO Update (RUI.Update): 170 WO.Update messages contain description of changes to XML DOM 171 trees. The updates can target individual nodes in order to update 172 their properties and attributes, or can target parts of the DOM 173 tree in order change its structure, e.g. add/delete/replace nodes 174 or branches. 176 WO Event (WO.Event): 177 WO.Event messages are primarily used to carry events triggered on 178 the Widex Renderer side so that they can be caught by the 179 application logic event handlers on the Widex Server side. Not 180 all events need to be forwarded to the application logic, as some 181 events are have local scope and may be intended for default event 182 handlers or for local scripted event handlers. The application 183 logic in the Widex Server may only be interested in specific 184 events. 186 WO.Event messages may carry data according to the type of the 187 event, e.g. application defined events with structured payloads as 188 per Extensible Multi-Modal Annotations [EMMA], which uses XML for 189 annotated interpretations of user input. 191 A secondary use of WO.Event messages is where the application 192 logic itself raises events that may be caught by event handlers 193 associated with the remote user interface, see for example Web 194 Applications 1.0 [WhatWG.WebApps1.0]. 196 3.4. Transport Protocol 198 The Transport Protocol is a protocol that just transports the RUIOs 199 as a string of bits, without looking at them. 201 3.5. Simple vs. Complex User Interfaces 203 Simple User Interface: 204 A simple user interface allows the user interface to be 205 represented with only one XML DOM object. 207 Complex User Interface: 208 A complex user interface may include scripted client-side event 209 handlers or there can be more than one XML DOM in the user 210 interface, e.g. different DOMs for different modalities, but see 211 also SVG's XML Binding Language [sXBL] for the role of shadow 212 DOMs. 214 3.6. Session 216 The Widex Session is initiated between a Widex Servers and a Widex 217 Renderer for exchanging information about user interface updates and 218 events in order to control applications remotely. A Widex Session 219 relate to a single User Interface, which can be simple or complex. 221 4. Scenarios and Explanatory Discussion 223 In this section we introduce short scenarios to illustrate how Widex 224 services can be deployed in some environments. 226 4.1. NAT Traversal 228 In the following sections we will describe some of the common 229 scenarios involving Widex Elements and NAT traversal. 231 4.1.1. Scenario 1: Widex Server and Renderer Located in Internet 233 In this scenario both the Server and Renderer are located somewhere 234 in the Internet and are globally accessible via public IP addresses 235 and/or Fully Qualified Domain Name (FQDN). 237 ************** 238 +--------+ * Public * +--------+ 239 | Widex |--* Network *--| Widex | 240 | Server | * * |Renderer| 241 +--------+ ************** +--------+ 243 Figure 2: Widex Server and Renderer Located in Internet 245 4.1.2. Scenario 2: Widex Server Located in Internet 247 In this scenario the Server is located somewhere in the Internet, has 248 a globally routable, public IP address (and/or FQDN), and the client 249 is behind a NAT device. The access network is a network where 250 private IP addresses are used and NAT is required in order to access 251 the public network, e.g. a home network, a hotspot. 253 +--------+ ************** 254 | Widex | * Public * 255 | Server |--* Network * 256 +--------+ * * 257 ************** 258 / 259 +--------+ 260 | NAT | 261 +--------+ 262 / 263 ************** 264 * Private * +--------+ 265 * Network *--| Widex | 266 * * |Renderer| 267 ************** +--------+ 269 Figure 3: Widex Server located in Internet 271 4.1.3. Scenario 3: Widex Renderer and Server in the Same Network 273 In this scenario the Server is located behind the same NAT device as 274 the Renderer. 276 ************** 277 * Public * 278 * Network * 279 * * 280 ************** 281 | 282 +--------+ 283 | NAT | 284 +--------+ 285 | 286 ************** 287 +--------+ * Local Area * +--------+ 288 | Widex |---* Network *---| Widex | 289 | Server | * * |Renderer| 290 +--------+ ************** +--------+ 292 Figure 4: Widex Renderer and Server in the same private network 294 The network might be managed in which case a centralised service 295 discovery and session setup mechanism should be used, or unmanaged 296 and a peer-to-peer service discovery and session setup mechanism 297 should be used. 299 4.2. IPv4-IPv6 Interworking 301 The global deployment of IPv6 is underway, creating an IPv4/IPv6 302 Internet consisting of IPv4-only and dual-stack IPv4/IPv6 networks 303 and nodes. There may also be IPv6-only nodes. It is highly probable 304 that there will be situations when IPv4-only Widex entities will want 305 to communicate with dual-stack IPv4/IPv6 Widex entities. Also, a 306 valid scenario is where two dual-stack IPv4/IPv6 Widex entities are 307 communicating over a network that includes an IPv4-only segment. In 308 these scenarios, it is expected that at least one Widex Element will 309 be attached to an unmanaged network or to a 3GPP network; IPv6 310 transition scenarios for unmanaged networks are described in RFC 3750 311 [RFC3750] and for 3GPP networks are described in RFC 3574 [RFC3574]. 313 A good guideline, when talking about migrating from IPv4 to IPv6, is 314 to select such protocols that do not have big issues with NAT 315 traversal and IPv6 transition mechanisms. 317 In the following sections, we will describe some of the common 318 scenarios involving Widex Elements and IPv4-IPv6 interworking. 320 4.2.1. Dual-Stack Widex Element Communicating with IPv4-Only Widex 321 Element Using IPv4 323 +---------+ +---------+ 324 | Widex | | Widex | 325 | Element | *********** | Element | 326 +---------+ * * +---------+ 327 |IPv4/IPv6|--* IPv4/IPv6 *--|IPv4-only| 328 +---------+ * * +---------+ 329 *********** 331 Figure 5: Dual-stack WE communicating with IPv4 only WE using IPv4 333 4.2.2. Dual-Stack Widex Elements Communicating over IPv4 Segment using 334 IPv6 336 +---------+ +---------+ 337 | Widex | | Widex | 338 | Server | *********** *********** *********** | Renderer| 339 +---------+ * * * * * * +---------+ 340 |IPv4/IPv6|--* IPv4/IPv6 *--* IPv4-only *--* IPv4/IPv6 *--|IPv4/IPv6| 341 +---------+ * * * * * * +---------+ 342 *********** *********** *********** 344 Figure 6: Dual-stack WE communicating over IPv4 segment using IPv6 346 When dual-stack Widex Elements communicate using IPv6 over an IPv4- 347 only segment, tunneling mechanisms such as 6to4 [RFC3056], ISATAP 348 [RFC4214] or Teredo [RFC4380] MAY be used by the intermediate nodes 349 or by the nodes hosting the Widex Elements to tunnel the IPv6 traffic 350 over the IPv4-only segment. 352 4.2.3. IPv4-Only Widex Element communicating with an IPv6-Only Widex 353 Element 355 +---------+ +---------+ 356 | Widex | | Widex | 357 | Element | *********** +----------+ *********** | Element | 358 +---------+ * * | Protocol | * * +---------+ 359 |IPv4-only|--* IPv4-only *--|Translator|--* IPv6-only *--|IPv6-only| 360 +---------+ * * | /ALG | * * +---------+ 361 *********** +----------+ *********** 363 Figure 7: IPv4-Only WE communicating with an IPv6-Only WE 365 Protocol translation / Application Level Gateway (ALG) functionality 366 is necessary in the network in order to enable the communication 367 between an IPv4-only Widex Element with an IPv6-only Widex Element. 369 This is not a typical case as the assumption is that IPv6-only nodes 370 will not be common in the near future. 372 4.2.4. Application Aspects of IPv6 Transition 374 Application developers, implementing the Widex framework and 375 services, which want to enable IPv6 support in implementations 376 running on IPv6 hosts or want to develop IP version-independent 377 implementations SHOULD consider recommendations written in RFC 4038 378 [RFC4038]. 380 5. Requirements 382 5.1. Architecture Requirements 384 o The framework MUST be modular, e.g. multiple session setup 385 mechanisms may be used. 386 o The synchronisation MUST occur at a fairly loose level that allows 387 for a simple approach to propagating changes. 388 o The framework and the synchronisation protocol SHOULD be 389 stateless. 390 o The framework SHOULD be consistent with the W3C Multimodal 391 Architecture [MMI.Arch]. 393 5.2. Discovery and Session Setup Requirements 395 o The service discovery mechanism MUST be able to discover both 396 Widex Renderers and Widex Servers. 397 o The service discovery mechanism MUST be able to negotiate the 398 capabilities of both Widex Renderers and Widex Servers, e.g. 399 supported devices physical characteristics, supported markup 400 languages, etc. 401 o The session setup mechanism MUST be able to establish sessions 402 from both Widex Renderers and Widex Servers, e.g. remote user 403 interface pull and push. 405 5.3. Widex Objects Requirements 407 o The WOs MUST NOT be aware of the semantics of the markup that is 408 synchronized. 409 o The WOs MUST support client initiated updates. 410 o The WOs MUST support server initiated updates. 411 o The WOs MUST contain only information having remote scope. 412 o The WOs MUST indicate the target XML DOM tree when Complex User 413 Interfaces are involved. 415 o The WOs MAY support multiple modes of interaction, and it is the 416 responsibility of the application to synchronise modalities and 417 not that of the Widex protocol. 419 5.4. Transport Requirements 421 o The Widex protocol MUST deliver WOs in the order determined by the 422 originator regardless of the underlying network topology. The 423 order is relevant within a single Widex Session. The co- 424 ordination between several Widex Sessions in a Widex Server is 425 outside the scope of this document. 426 o The Widex protocol MUST provide reliable delivery of messages. If 427 this proves to be impractical in a given situation, the protocol 428 MUST provide the means for application to detect such failures. 429 o The Widex protocol MUST tolerate limitations in available 430 bandwidth. 431 o The Widex protocol MUST tolerate delays caused by network induced 432 latency. Latency and time-outs may need to be handled at the 433 application level. 434 o The Widex protocol MUST have support for authentication and secure 435 sessions, e.g. data privacy and integrity. 437 6. IANA Considerations 439 This document makes no request of IANA. 441 7. Security Considerations 443 As a means to support remote user interfaces, a number of security 444 considerations need to be addressed, including the potential for 445 unauthorized access to application services, monitoring of 446 interactions by unauthorized third parties, spoofing of application 447 services as a means to support phishing attacks, and denial of 448 service attacks. Requirements defined in this document MUST allow 449 for the implementation according to best common practices. 451 8. Acknowledgements 453 The authors would like to thank Juha Wiljakka for good input and 454 comments that helped writing this document. 456 9. References 457 9.1. Normative References 459 [DOM2.Core] 460 Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, 461 J., Champion, M., and S. Byrne, "Document Object Model 462 (DOM) Level 2 Core Specification", W3C Recommendation, 463 November 2000. 465 [DOM2.Events] 466 Pixley, T., "Document Object Model (DOM) Level 2 Events 467 Specification", W3C Recommendation, November 2000. 469 [DOM2.Style] 470 Wilson, C., Le Hegaret, P., and V. Apparao, "Document 471 Object Model (DOM) Level 2 Style Specification", 472 W3C Recommendation, November 2000. 474 [DOM3.Core] 475 Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, 476 J., and S. Byrne, "Document Object Model (DOM) Level 3 477 Core Specification", W3C Recommendation, April 2004. 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, March 1997. 482 [XML1.0] Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C., 483 and E. Maler, "Extensible Markup Language (XML) 1.0 (Third 484 Edition)", W3C Recommendation, February 2004. 486 9.2. Informative References 488 [EMMA] Johnston, M., Chou, W., Dahl, D., McCobb, G., and D. 489 Raggett, "Extensible Multi-Modal Annotations (EMMA)", 490 W3C Last Call Working Draft, September 2005. 492 [MMI.Arch] 493 Barnett, J., "Multimodal Architecture and Interfaces", 494 W3C Working Draft, April 2005. 496 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 497 via IPv4 Clouds", RFC 3056, February 2001. 499 [RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", 500 RFC 3574, August 2003. 502 [RFC3750] Huitema, C., Austein, R., Satapati, S., and R. van der 503 Pol, "Unmanaged Networks IPv6 Transition Scenarios", 504 RFC 3750, April 2004. 506 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 507 Castro, "Application Aspects of IPv6 Transition", 508 RFC 4038, March 2005. 510 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 511 for IPv6 Hosts and Routers", RFC 4213, October 2005. 513 [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 514 "Intra-Site Automatic Tunnel Addressing Protocol 515 (ISATAP)", RFC 4214, October 2005. 517 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 518 Network Address Translations (NATs)", RFC 4380, 519 February 2006. 521 [WhatWG.WebApps1.0] 522 Hickson, I., "Web Applications 1.0", October 2005. 524 [sXBL] Ferraiolo, J., Hickson, I., and D. Hyatt, "SVG's XML 525 Binding Language (sXBL)", W3C Working Draft, August 2005. 527 Authors' Addresses 529 Vlad Stirbu 530 Nokia 531 Visiokatu 3 532 Tampere 33720 533 Finland 535 Phone: +358 7180 08000 536 Email: vlad.stibu@nokia.com 538 Dave Raggett 539 W3C/Volantis 540 35 Frome Road 541 Bradford on Avon, Wiltshire BA15 2EA 542 United Kingdom 544 Phone: +44 1225 866240 545 Email: dsr@w3.org 547 Full Copyright Statement 549 Copyright (C) The Internet Society (2006). 551 This document is subject to the rights, licenses and restrictions 552 contained in BCP 78, and except as set forth therein, the authors 553 retain all their rights. 555 This document and the information contained herein are provided on an 556 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 557 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 558 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 559 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 560 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 563 Intellectual Property 565 The IETF takes no position regarding the validity or scope of any 566 Intellectual Property Rights or other rights that might be claimed to 567 pertain to the implementation or use of the technology described in 568 this document or the extent to which any license under such rights 569 might or might not be available; nor does it represent that it has 570 made any independent effort to identify any such rights. Information 571 on the procedures with respect to rights in RFC documents can be 572 found in BCP 78 and BCP 79. 574 Copies of IPR disclosures made to the IETF Secretariat and any 575 assurances of licenses to be made available, or the result of an 576 attempt made to obtain a general license or permission for the use of 577 such proprietary rights by implementers or users of this 578 specification can be obtained from the IETF on-line IPR repository at 579 http://www.ietf.org/ipr. 581 The IETF invites any interested party to bring to its attention any 582 copyrights, patents or patent applications, or other proprietary 583 rights that may cover technology that may be required to implement 584 this standard. Please address the information to the IETF at 585 ietf-ipr@ietf.org. 587 Acknowledgment 589 Funding for the RFC Editor function is provided by the IETF 590 Administrative Support Activity (IASA).