idnits 2.17.1 draft-stirbu-widex-requirements-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 423. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 407. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 413. ** 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 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 (October 17, 2005) is 6759 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WIDEX V. Stirbu 3 Internet-Draft Nokia 4 Expires: April 20, 2006 D. Raggett 5 W3C/Canon 6 October 17, 2005 8 Widget Description Exchange Service (WIDEX) Requirements 9 draft-stirbu-widex-requirements-00 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 April 20, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 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 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC 2119 [RFC2119]. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Widex Entities . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Widex Terminology . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. User Interface . . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Remote User Interface . . . . . . . . . . . . . . . . . . 4 62 3.3. Remote User Interface Objects . . . . . . . . . . . . . . 4 63 3.4. Transport Protocol . . . . . . . . . . . . . . . . . . . . 5 64 3.5. Simple vs. Complex User Interfaces . . . . . . . . . . . . 5 66 4. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 5 67 4.1. Scenario 1: Widex Server and Renderer Located in 68 Internet . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.2. Scenario 2: Widex Server Located in Internet . . . . . . . 5 70 4.3. Scenario 3: Widex Renderer and Server in the Same 71 Network . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 5.1. Architecture Requirements . . . . . . . . . . . . . . . . 6 75 5.2. Discovery and Session Setup Requirements . . . . . . . . . 7 76 5.3. Remote UI Objects Requirements . . . . . . . . . . . . . . 7 77 5.4. Transport Requirements . . . . . . . . . . . . . . . . . . 7 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 90 Intellectual Property and Copyright Statements . . . . . . . . . . 11 92 1. Introduction 94 With the Internet reaching out to more and more devices, people are 95 increasingly expecting to have access to services at anytime, from 96 anywhere and using any device. Such services are being developed 97 using Web technologies such as XML and distributed across the network 98 rather than resident on any one device. 100 2. Widex Entities 102 The following picture shows the primary Widex entities in a simple 103 and basic architecture. 105 +--------+ +--------+ 106 | | update interface | | 107 | Widex |----------------->| Widex | 108 | Server |<-----------------|Renderer| 109 | | event interface | | 110 +--------+ +--------+ 112 The two primary Entities are described as follows: 114 Widex Server (WS): 115 The entity that holds the application logic. 117 Widex Renderer (WR): 118 The entity that renders the user interface. 120 There might be several Widex Servers in the same device, one for each 121 application that can export the user interface and for each Widex 122 server there might be several Widex Renderers which are rendering the 123 user interface. 125 3. Widex Terminology 127 The terminology and definitions detailed below include both terms 128 that, besides the Widex entities are used in the requirements section 129 of this document. 131 3.1. User Interface 133 In the context of Widex working group, the user interface is 134 understood as XML [XML1.0] data describing the user interface. 135 Typically, the XML data is manipulated as levels 2 and 3 in the W3C 136 Document Object Model (DOM), see [DOM2.Core], [DOM3.Core], and 137 [DOM2.Events] (W3C has yet to complete work on DOM3 events). Style 138 information associated with the user interface can be manipulated via 139 the DOM, see [DOM2.Style]. 141 3.2. Remote User Interface 143 The Remote User Interface (RUI) is a technique in which a user 144 interface is rendered on another device than the one that runs the 145 application logic while keeping the user interface synchronised with 146 the application logic. 148 3.3. Remote User Interface Objects 150 One of the goals of the Widex working group is to define Remote User 151 Interface Objects (RUIO), to be used to convey information about 152 interface updates and events. RUIOs are used to keep the rendered 153 user inteface synchronised with the application logic. 155 There are three types of RUIOs: 157 RUIO Update (RUI.Update): 158 RUI.Update messages are sent by the Widex Server in order to 159 update XML DOM nodes and associated style properties. 161 RUIO Mutation (RUI.Mutation): 162 RUI.Mutation messages are sent by the Widex Server in order to 163 modify the structure of the XML DOM on the Widex Renderer side, 164 e.g. add/remove XML DOM nodes. 166 RUIO Event (RUI.Event): 167 RUI.Event messages are used to carry events triggered on the Widex 168 Renderer side so that they can be caught by the application logic 169 event handles on the Widex Server side. Not all events needs to 170 be forwarded to the application logic. Some events may be 171 intended for default event handlers or for local scripted event 172 handlers. The application logic in the RUI server may only be 173 interested in specific events. 175 RUI.Event messages may carry data according to the type of the 176 event, e.g. application defined events with structured payloads as 177 per [EMMA], which uses XML for annotated interpretations of user 178 input. 180 It might be possible for the application logic to raise events 181 itself which can then be caught by event handlers associated with 182 the remote user interface (RUI), see e.g. [WhatWG.WebApps1.0]. 184 3.4. Transport Protocol 186 The Transport Protocol is a protocol that just transports the RUIOs 187 as a string of bits, without looking at them. 189 3.5. Simple vs. Complex User Interfaces 191 Simple User Interface: 192 A simple user interface allows the user interface to be 193 represented with only one XML DOM object. 195 Complex User Interface: 196 A complex user interface may include scripted client-side event 197 handlers or there can be more than one XML DOM in the user 198 interface, e.g. different DOMs for different modalities, but see 199 also [sXBL] for the role of shadow DOMs. 201 4. Scenarios and Explanatory Discussion 203 In this section we introduce short scenarios to illustrate how Widex 204 services can be deployed in some environments. 206 4.1. Scenario 1: Widex Server and Renderer Located in Internet 208 In this scenario both the Server and Rendere are located somewhere in 209 the Internet and are globally accessible via public IP addresses 210 (and/or FQDN). 212 +--------+ _____ 213 | Widex | _,-'' `--. +--------+ 214 | Server |---/ ` | Widex | 215 +--------+ \ Internet ,'---|Renderer| 216 `._ _,' +--------+ 217 ``-----' 219 4.2. Scenario 2: Widex Server Located in Internet 221 In this scenario the Server is located somewhere in the Internet, has 222 a globally routable, public IP address (and/or FQDN), and the client 223 is behind a NAT device. The access network is a network where 224 private IP addresses are used and NAT is required in order to access 225 the public network, e.g. a home network, a hotspot. 227 +--------+ _____ 228 | Widex | _,-'' `--. 229 | Server |---/ ` 230 +--------+ \ Internet ,' 231 `._ _,' 232 ``-----' 233 / 234 +--------+ 235 | NAT | 236 +--------+ 237 ____/ 238 _,-'' `--. 239 / Access ` +--------+ 240 \ Network ,'--| Widex | 241 `._ _,' |Renderer| 242 ``-----' +--------+ 244 4.3. Scenario 3: Widex Renderer and Server in the Same Network 246 In this scenario the Server is located behind the same NAT device as 247 the Renderer. 248 +--------+ 249 | NAT | 250 +--------+ 251 ____/ 252 _,-'' `--. 253 +--------+ / Home ` +--------+ 254 | Widex |----\ Network ,'--| Widex | 255 | Server | `._ _,' |Renderer| 256 +--------+ ``-----' +--------+ 258 The network might be managed in which case a centralised service 259 discovery and session setup mechanism should be used, or unmanged and 260 a peer-to-peer service discovery and session setup mechanism should 261 be used. 263 5. Requirements 265 5.1. Architecture Requirements 267 o The framework MUST be modular, e.g. multiple session setup 268 mechanisms may be used. 269 o The synchronisation MUST occur at a fairly loose level that allows 270 for a simple approach to propagating changes. 271 o The framework and the synchronisation protocol SHOULD be 272 stateless. 274 o The framework SHOULD be consistent with the W3C Multimodal 275 Architecture, see [MMI.Arch]. 277 5.2. Discovery and Session Setup Requirements 279 o The service discovery mechanism MUST be able to discover both 280 Widex Renderers and Widex Servers. 281 o The service discovery mechanism MUST be able to negotiate the 282 capabilities of both Widex Renderers and Widex Servers, e.g. 283 supported devices physical characteristics, supported markup 284 languages, etc. 285 o The session setup mechanism MUST be able to establish sessions 286 from both Widex Renderers and Widex Servers, e.g. remote user 287 interface pull and push. 289 5.3. Remote UI Objects Requirements 291 o The RUIOs MUST NOT be aware of the semantics of the markup that is 292 synchronized. 293 o The RUIOs MUST support client initiated updates. 294 o The RUIOs MUST support server initiated updates. 296 5.4. Transport Requirements 298 o The protocol MUST deliver RUIOs regardless of the undelying 299 network topology. 300 o The protocol MUST be reliable. 301 o The protocol MUST tolerate limitations in available bandwidth. 302 o The protocol MUST tolerate delays caused by network induced 303 latency. 304 o The protocol MUST have support for authentication and secure 305 sessions. 307 6. IANA Considerations 309 This document makes no request of IANA. 311 7. Security Considerations 313 As a means to support remote user interfaces, a number of security 314 considerations need to be addressed, including the potential for 315 unauthorized access to application services, monitoring of 316 interactions by unauthorized third parties, spoofing of application 317 services as a means to support phishing attacks, and denial of 318 service attacks. 320 8. Acknowledgements 322 T.B.D. 324 9. References 326 9.1. Normative References 328 [DOM2.Core] 329 Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, 330 J., Champion, M., and S. Byrne, "Document Object Model 331 (DOM) Level 2 Core Specification", W3C Recommendation, 332 November 2000. 334 [DOM2.Events] 335 Pixley, T., "Document Object Model (DOM) Level 2 Events 336 Specification", W3C Recommendation, November 2000. 338 [DOM2.Style] 339 Wilson, C., Le Hegaret, P., and V. Apparao, "Document 340 Object Model (DOM) Level 2 Style Specification", 341 W3C Recommendation, November 2000. 343 [DOM3.Core] 344 Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, 345 J., and S. Byrne, "Document Object Model (DOM) Level 3 346 Core Specification", W3C Recommendation, April 2004. 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [XML1.0] Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C., 352 and E. Maler, "Extensible Markup Language (XML) 1.0 (Third 353 Edition)", W3C Recommendation, February 2004. 355 9.2. Informative References 357 [EMMA] Johnston, M., Chou, W., Dahl, D., McCobb, G., and D. 358 Raggett, "Extensible Multi-Modal Annotations (EMMA)", 359 W3C Last Call Working Draft, September 2005. 361 [MMI.Arch] 362 Barnett, J., "Multimodal Architecture and Interfaces", 363 W3C Working Draft, April 2005. 365 [WhatWG.WebApps1.0] 366 Hickson, I., "Web Applications 1.0", October 2005. 368 [sXBL] Ferraiolo, J., Hickson, I., and D. Hyatt, "SVG's XML 369 Binding Language (sXBL)", W3C Working Draft, August 2005. 371 Authors' Addresses 373 Vlad Stirbu 374 Nokia 375 Visiokatu 3 376 Tampere 33720 377 Finland 379 Phone: +358 7180 60572 380 Email: vlad.stibu@nokia.com 382 Dave Raggett 383 W3C/Canon 384 35 Frome Road 385 Bradford on Avon, Wiltshire BA15 2EA 386 United Kingdom 388 Phone: +44 1225 866240 389 Email: dsr@w3.org 391 Intellectual Property Statement 393 The IETF takes no position regarding the validity or scope of any 394 Intellectual Property Rights or other rights that might be claimed to 395 pertain to the implementation or use of the technology described in 396 this document or the extent to which any license under such rights 397 might or might not be available; nor does it represent that it has 398 made any independent effort to identify any such rights. Information 399 on the procedures with respect to rights in RFC documents can be 400 found in BCP 78 and BCP 79. 402 Copies of IPR disclosures made to the IETF Secretariat and any 403 assurances of licenses to be made available, or the result of an 404 attempt made to obtain a general license or permission for the use of 405 such proprietary rights by implementers or users of this 406 specification can be obtained from the IETF on-line IPR repository at 407 http://www.ietf.org/ipr. 409 The IETF invites any interested party to bring to its attention any 410 copyrights, patents or patent applications, or other proprietary 411 rights that may cover technology that may be required to implement 412 this standard. Please address the information to the IETF at 413 ietf-ipr@ietf.org. 415 Disclaimer of Validity 417 This document and the information contained herein are provided on an 418 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 419 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 420 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 421 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 422 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 423 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 425 Copyright Statement 427 Copyright (C) The Internet Society (2005). This document is subject 428 to the rights, licenses and restrictions contained in BCP 78, and 429 except as set forth therein, the authors retain all their rights. 431 Acknowledgment 433 Funding for the RFC Editor function is currently provided by the 434 Internet Society.