idnits 2.17.1 draft-ietf-widex-requirements-02.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 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 586. ** 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 (May 14, 2006) is 6550 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4214 (Obsoleted by RFC 5214) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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: November 15, 2006 W3C/Volantis 6 May 14, 2006 8 Widget Description Exchange Service (WIDEX) Requirements 9 draft-ietf-widex-requirements-02 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 November 15, 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 (WO.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 WOs as 199 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 Server 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 RFC 4213 [RFC4213]. There may also be IPv6-only nodes. It 304 is highly probable that there will be situations when IPv4-only Widex 305 entities will want to communicate with dual-stack IPv4/IPv6 Widex 306 entities. Also, a valid scenario is where two dual-stack IPv4/IPv6 307 Widex entities are communicating over a network that includes an 308 IPv4-only segment. In these scenarios, it is expected that at least 309 one Widex Element will be attached to an unmanaged network or to a 310 3GPP network; IPv6 transition scenarios for unmanaged networks are 311 described in RFC 3750 [RFC3750] and for 3GPP networks are described 312 in RFC 3574 [RFC3574]. 314 A good guideline, when talking about migrating from IPv4 to IPv6, is 315 to select such protocols that do not have big issues with NAT 316 traversal and IPv6 transition mechanisms. 318 In the following sections, we will describe some of the common 319 scenarios involving Widex Elements and IPv4-IPv6 interworking. 321 4.2.1. Dual-Stack Widex Element Communicating with IPv4-Only Widex 322 Element Using IPv4 324 +---------+ +---------+ 325 | Widex | | Widex | 326 | Element | *********** | Element | 327 +---------+ * * +---------+ 328 |IPv4/IPv6|--* IPv4/IPv6 *--|IPv4-only| 329 +---------+ * * +---------+ 330 *********** 332 Figure 5: Dual-stack WE communicating with IPv4 only WE using IPv4 334 4.2.2. Dual-Stack Widex Elements Communicating over IPv4 Segment using 335 IPv6 337 +---------+ +---------+ 338 | Widex | | Widex | 339 | Server | *********** *********** *********** | Renderer| 340 +---------+ * * * * * * +---------+ 341 |IPv4/IPv6|--* IPv4/IPv6 *--* IPv4-only *--* IPv4/IPv6 *--|IPv4/IPv6| 342 +---------+ * * * * * * +---------+ 343 *********** *********** *********** 345 Figure 6: Dual-stack WE communicating over IPv4 segment using IPv6 347 When dual-stack Widex Elements communicate using IPv6 over an IPv4- 348 only segment, tunneling mechanisms such as 6to4 [RFC3056], ISATAP 349 [RFC4214] or Teredo [RFC4380] MAY be used by the intermediate nodes 350 or by the nodes hosting the Widex Elements to tunnel the IPv6 traffic 351 over the IPv4-only segment. 353 4.2.3. IPv4-Only Widex Element communicating with an IPv6-Only Widex 354 Element 356 +---------+ +---------+ 357 | Widex | | Widex | 358 | Element | *********** +----------+ *********** | Element | 359 +---------+ * * | Protocol | * * +---------+ 360 |IPv4-only|--* IPv4-only *--|Translator|--* IPv6-only *--|IPv6-only| 361 +---------+ * * | /ALG | * * +---------+ 362 *********** +----------+ *********** 364 Figure 7: IPv4-Only WE communicating with an IPv6-Only WE 366 Protocol translation / Application Level Gateway (ALG) functionality 367 is necessary in the network in order to enable the communication 368 between an IPv4-only Widex Element with an IPv6-only Widex Element. 370 This is not a typical case as the assumption is that IPv6-only nodes 371 will not be common in the near future. 373 4.2.4. Application Aspects of IPv6 Transition 375 Application developers, implementing the Widex framework and 376 services, which want to enable IPv6 support in implementations 377 running on IPv6 hosts or want to develop IP version-independent 378 implementations SHOULD consider recommendations written in RFC 4038 379 [RFC4038]. 381 5. Requirements 383 5.1. Architecture Requirements 385 o The framework MUST be modular, e.g. multiple session setup 386 mechanisms may be used. 387 o The synchronisation MUST occur at a fairly loose level that allows 388 for a simple approach to propagating changes. 389 o The framework and the synchronisation protocol SHOULD be 390 stateless. 391 o The framework SHOULD be consistent with the W3C Multimodal 392 Architecture [MMI.Arch]. 394 5.2. Discovery and Session Setup Requirements 396 o The service discovery mechanism MUST be able to discover both 397 Widex Renderers and Widex Servers. 398 o The service discovery mechanism MUST be able to negotiate the 399 capabilities of both Widex Renderers and Widex Servers, e.g. 400 supported devices physical characteristics, supported markup 401 languages, etc. 402 o The session setup mechanism MUST be able to initiate session 403 establishment from both Widex Renderers and Widex Servers, e.g. 404 remote user interface pull and push. 406 5.3. Widex Objects Requirements 408 o The WOs MUST NOT be aware of the semantics of the UI markup 409 language that is synchronized. 410 o The WOs MUST support client initiated updates. 411 o The WOs MUST support server initiated updates. 412 o The WOs MUST contain only information having remote scope. 413 o The WOs MUST indicate the target XML DOM tree when Complex User 414 Interfaces are involved. 416 o The WOs MAY support multiple modes of interaction, and it is the 417 responsibility of the application to synchronise modalities and 418 not that of the Widex protocol. 420 5.4. Transport Requirements 422 o The Widex protocol MUST deliver WOs in the order determined by the 423 originator regardless of the underlying network topology. The 424 order is relevant within a single Widex Session. The co- 425 ordination between several Widex Sessions in a Widex Server is 426 outside the scope of this document. 427 o The Widex protocol MUST provide reliable delivery of messages. If 428 this proves to be impractical in a given situation, the protocol 429 MUST provide the means for application to detect such failures. 430 o The Widex protocol MUST tolerate limitations in available 431 bandwidth. 432 o The Widex protocol MUST tolerate delays caused by network induced 433 latency. Latency and time-outs may need to be handled at the 434 application level. 435 o The Widex protocol MUST have support for authentication and secure 436 sessions, e.g. data privacy and integrity. 438 6. IANA Considerations 440 This document makes no request of IANA. 442 7. Security Considerations 444 As a means to support remote user interfaces, a number of security 445 considerations need to be addressed, including the potential for 446 unauthorized access to application services, monitoring of 447 interactions by unauthorized third parties, spoofing of application 448 services as a means to support phishing attacks, and denial of 449 service attacks. Requirements defined in this document MUST allow 450 for the implementation according to best common practices. 452 8. Acknowledgements 454 The authors would like to thank Juha Wiljakka for good input and 455 comments that helped writing this document. 457 9. References 458 9.1. Normative References 460 [DOM2.Core] 461 Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, 462 J., Champion, M., and S. Byrne, "Document Object Model 463 (DOM) Level 2 Core Specification", W3C Recommendation, 464 November 2000. 466 [DOM2.Events] 467 Pixley, T., "Document Object Model (DOM) Level 2 Events 468 Specification", W3C Recommendation, November 2000. 470 [DOM2.Style] 471 Wilson, C., Le Hegaret, P., and V. Apparao, "Document 472 Object Model (DOM) Level 2 Style Specification", 473 W3C Recommendation, November 2000. 475 [DOM3.Core] 476 Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, 477 J., and S. Byrne, "Document Object Model (DOM) Level 3 478 Core Specification", W3C Recommendation, April 2004. 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, March 1997. 483 [XML1.0] Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C., 484 and E. Maler, "Extensible Markup Language (XML) 1.0 (Third 485 Edition)", W3C Recommendation, February 2004. 487 9.2. Informative References 489 [EMMA] Johnston, M., Chou, W., Dahl, D., McCobb, G., and D. 490 Raggett, "Extensible Multi-Modal Annotations (EMMA)", 491 W3C Last Call Working Draft, September 2005. 493 [MMI.Arch] 494 Barnett, J., "Multimodal Architecture and Interfaces", 495 W3C Working Draft, April 2005. 497 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 498 via IPv4 Clouds", RFC 3056, February 2001. 500 [RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", 501 RFC 3574, August 2003. 503 [RFC3750] Huitema, C., Austein, R., Satapati, S., and R. van der 504 Pol, "Unmanaged Networks IPv6 Transition Scenarios", 505 RFC 3750, April 2004. 507 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 508 Castro, "Application Aspects of IPv6 Transition", 509 RFC 4038, March 2005. 511 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 512 for IPv6 Hosts and Routers", RFC 4213, October 2005. 514 [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 515 "Intra-Site Automatic Tunnel Addressing Protocol 516 (ISATAP)", RFC 4214, October 2005. 518 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 519 Network Address Translations (NATs)", RFC 4380, 520 February 2006. 522 [WhatWG.WebApps1.0] 523 Hickson, I., "Web Applications 1.0", October 2005. 525 [sXBL] Ferraiolo, J., Hickson, I., and D. Hyatt, "SVG's XML 526 Binding Language (sXBL)", W3C Working Draft, August 2005. 528 Authors' Addresses 530 Vlad Stirbu 531 Nokia 532 Visiokatu 3 533 Tampere 33720 534 Finland 536 Phone: +358 7180 08000 537 Email: vlad.stibu@nokia.com 539 Dave Raggett 540 W3C/Volantis 541 35 Frome Road 542 Bradford on Avon, Wiltshire BA15 2EA 543 United Kingdom 545 Phone: +44 1225 866240 546 Email: dsr@w3.org 548 Full Copyright Statement 550 Copyright (C) The Internet Society (2006). 552 This document is subject to the rights, licenses and restrictions 553 contained in BCP 78, and except as set forth therein, the authors 554 retain all their rights. 556 This document and the information contained herein are provided on an 557 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 558 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 559 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 560 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 561 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 562 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 564 Intellectual Property 566 The IETF takes no position regarding the validity or scope of any 567 Intellectual Property Rights or other rights that might be claimed to 568 pertain to the implementation or use of the technology described in 569 this document or the extent to which any license under such rights 570 might or might not be available; nor does it represent that it has 571 made any independent effort to identify any such rights. Information 572 on the procedures with respect to rights in RFC documents can be 573 found in BCP 78 and BCP 79. 575 Copies of IPR disclosures made to the IETF Secretariat and any 576 assurances of licenses to be made available, or the result of an 577 attempt made to obtain a general license or permission for the use of 578 such proprietary rights by implementers or users of this 579 specification can be obtained from the IETF on-line IPR repository at 580 http://www.ietf.org/ipr. 582 The IETF invites any interested party to bring to its attention any 583 copyrights, patents or patent applications, or other proprietary 584 rights that may cover technology that may be required to implement 585 this standard. Please address the information to the IETF at 586 ietf-ipr@ietf.org. 588 Acknowledgment 590 Funding for the RFC Editor function is provided by the IETF 591 Administrative Support Activity (IASA).