idnits 2.17.1 draft-ietf-widex-requirements-03.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 429. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 453. ** 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 (September 28, 2006) is 6419 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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 Intended status: Informational D. Raggett 5 Expires: April 1, 2007 W3C/Volantis 6 September 28, 2006 8 Widget Description Exchange Service (WIDEX) Requirements 9 draft-ietf-widex-requirements-03 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 1, 2007. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Widex Entities . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Widex Terminology . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. User Interface . . . . . . . . . . . . . . . . . . . . . . 3 62 3.2. Remote User Interface . . . . . . . . . . . . . . . . . . 4 63 3.3. Multimodal Interaction . . . . . . . . . . . . . . . . . . 4 64 3.4. Widex Objects . . . . . . . . . . . . . . . . . . . . . . 4 65 3.5. Transport Protocol . . . . . . . . . . . . . . . . . . . . 5 66 3.6. Simple vs. Complex User Interfaces . . . . . . . . . . . . 5 67 3.7. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Architecture Requirements . . . . . . . . . . . . . . . . 6 71 4.2. Service Discovery and Session Setup Requirements . . . . . 6 72 4.3. Widex Objects Requirements . . . . . . . . . . . . . . . . 6 73 4.4. Transport Requirements . . . . . . . . . . . . . . . . . . 6 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 7 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 87 Intellectual Property and Copyright Statements . . . . . . . . . . 11 89 1. Introduction 91 With the Internet reaching out to more and more devices, people are 92 increasingly expecting to have access to services at anytime, from 93 anywhere and using any device. Such services are being developed 94 using Web technologies such as XML and distributed across the network 95 rather than resident on any one device. 97 2. Widex Entities 99 The following picture shows the primary Widex entities in a simple 100 and basic architecture. 102 +--------+ +--------+ 103 | | update interface | | 104 | Widex |----------------->| Widex | 105 | Server |<-----------------|Renderer| 106 | | event interface | | 107 +--------+ +--------+ 109 Figure 1: Widex Entities 111 The two primary Entities are described as follows: 113 Widex Server (WS): 114 The entity that holds the application logic. 116 Widex Renderer (WR): 117 The entity that renders the user interface. 119 There might be several Widex Servers in the same device, one for each 120 application that can export the user interface and for each Widex 121 Server there might be several Widex Renderers which are rendering the 122 user interface. 124 3. Widex Terminology 126 The terminology and definitions detailed below include both terms 127 that, besides the Widex Entities are used in the requirements section 128 of this document. 130 3.1. User Interface 132 In the context of Widex working group, the user interface is 133 understood as XML [XML1.0] data describing the user interface. 134 Typically, the XML data is manipulated as levels 2 and 3 in the W3C 135 Document Object Model (DOM), see [DOM2.Core], [DOM3.Core], and 136 [DOM2.Events] (W3C has yet to complete work on DOM3 events). Style 137 information associated with the user interface can be manipulated via 138 the DOM, see [DOM2.Style]. 140 3.2. Remote User Interface 142 The Remote User Interface (RUI) is a technique in which a user 143 interface is rendered on another device than the one that runs the 144 application logic while keeping the user interface synchronised with 145 the application logic. 147 3.3. Multimodal Interaction 149 Multimodal interaction provides the user with multiple modes of 150 interfacing with a system beyond the traditional keyboard and mouse 151 input/output. The most common such interface combines a visual 152 modality (e.g. a display, keyboard, and mouse) with a voice modality 153 (speech recognition for input, speech synthesis and recorded audio 154 for output). However other modalities, such as pen-based input or 155 haptic input/output, may be used. 157 For example, W3C has developed a Multimodal Interaction Framework 158 [W3C.NOTE-mmi-framework-20030506] that is intended as a basis for 159 developing multimodal applications in terms of markup, scripting, 160 styling and other resources. 162 3.4. Widex Objects 164 One of the goals of the Widex working group is to define Widex 165 Objects (WO), to be used to convey information about interface 166 updates and events. Widex Objects are used to keep the rendered user 167 interface synchronised with the application logic. 169 There are two types of Widex Objects: 171 WO Update (WO.Update): 172 WO.Update messages contain description of changes to XML DOM 173 trees. The updates can target individual nodes in order to update 174 their properties and attributes, or can target parts of the DOM 175 tree in order change its structure, e.g. add/delete/replace nodes 176 or branches. 178 WO Event (WO.Event): 180 WO.Event messages are primarily used to carry events triggered on 181 the Widex Renderer side so that they can be caught by the 182 application logic event handlers on the Widex Server side. Not 183 all events need to be forwarded to the application logic, as some 184 events have local scope and may be intended for default event 185 handlers or for local scripted event handlers. The application 186 logic in the Widex Server may only be interested in specific 187 events. 189 WO.Event messages may carry data according to the type of the 190 event, e.g. application defined events with structured payloads as 191 per Extensible Multi-Modal Annotations [W3C.WD-emma-20050916], 192 which uses XML for annotated interpretations of user input. 194 A secondary use of WO.Event messages is where the application 195 logic itself raises events that may be caught by event handlers 196 associated with the remote user interface, see for example Web 197 Applications 1.0 [WhatWG.WebApps1.0]. 199 3.5. Transport Protocol 201 The Transport Protocol is a protocol that just transports the Widex 202 Objects as a string of bits, without looking at them. 204 3.6. Simple vs. Complex User Interfaces 206 Simple User Interface: 207 A simple user interface allows the user interface to be 208 represented with only one XML DOM object. Typically, a simple 209 user interface is associated with a single modality, e.g. vision 210 modality for graphic user interfaces. 212 Complex User Interface: 213 A complex user interface may include scripted client-side event 214 handlers or there can be more than one XML DOM in the user 215 interface, e.g. different DOMs for different modalities, but see 216 also SVG's XML Binding Language [W3C.WD-sXBL-20050815] for the 217 role of shadow DOMs. 219 3.7. Session 221 The Widex Session is initiated between a Widex Server and a Widex 222 Renderer for exchanging information about user interface updates 223 (e.g. WO.Update) and events (e.g. WO.Event) in order to control 224 applications remotely. A Widex Session relate to a single User 225 Interface, which can be simple or complex. 227 4. Requirements 229 4.1. Architecture Requirements 231 o The framework MUST be modular, e.g. multiple service discovery and 232 session setup mechanisms may be used. 233 o The synchronisation MUST occur at a fairly loose level that allows 234 for a simple approach to propagating changes. 235 o The framework and the synchronisation protocol SHOULD be 236 stateless. 237 o The framework SHOULD be consistent with the W3C Multimodal 238 Architecture [W3C.WD-mmi-arch-20060414]. 240 4.2. Service Discovery and Session Setup Requirements 242 o The service discovery mechanism MUST be able to discover both 243 Widex Renderers and Widex Servers. 244 o The service discovery mechanism MUST be able to negotiate the 245 capabilities of both Widex Renderers and Widex Servers, e.g. 246 supported devices physical characteristics, supported markup 247 languages, etc. 248 o The session setup mechanism MUST be able to initiate session 249 establishment from both Widex Renderers and Widex Servers, e.g. 250 remote user interface pull and push. 252 4.3. Widex Objects Requirements 254 o The Widex Objects MUST NOT be aware of the semantics of the UI 255 markup language that is synchronized. 256 o The Widex Objects MUST support client initiated updates. 257 o The Widex Objects MUST support server initiated updates. 258 o The Widex Objects MUST contain only information meaningful in the 259 context of the Widex Session. 260 o The Widex Objects MUST indicate the target XML DOM tree when 261 Complex User Interfaces are involved. 262 o The Widex Objects MAY support multimodal interaction, and it is 263 the responsibility of the application to synchronise modalities 264 and not that of the Widex protocol. 266 4.4. Transport Requirements 268 o The Widex protocol MUST deliver Widex Objects in the order 269 determined by the originator regardless of the underlying network 270 topology. The order is relevant within a single Widex Session. 271 The co-ordination between several Widex Sessions in a Widex Server 272 is outside the scope of this document. 274 o The Widex protocol MUST handle each modality within the context of 275 a single Widex Session. 276 o The Widex protocol MUST provide reliable delivery of messages. If 277 this proves to be impractical in a given situation, the protocol 278 MUST provide the means for application to detect such failures. 279 o The Widex protocol MUST tolerate limitations in available 280 bandwidth. 281 o The Widex protocol MUST tolerate delays caused by network induced 282 latency. Latency and time-outs may need to be handled at the 283 application level. 284 o The Widex protocol MUST have support for authentication and secure 285 sessions, e.g. data privacy and integrity. 287 5. IANA Considerations 289 This document makes no request of IANA. 291 6. Security Considerations 293 As a means to support remote user interfaces, a number of security 294 considerations need to be addressed, including the potential for 295 unauthorized access to application services, monitoring of 296 interactions by unauthorized third parties, spoofing of application 297 services as a means to support phishing attacks, and denial of 298 service attacks. Requirements defined in this document MUST allow 299 for the implementation according to best common practices. 301 6.1. Privacy Considerations 303 Exposing the capabilities of Widex Servers and Widex Renderers using 304 the appropriate service discovery and session setup mechanism has 305 privacy implications as malicious users may harvest information about 306 physical characteristics and applications hosted by Widex Entities. 307 Implementors should carefully balance which characteristics of the 308 Widex Entities are exposed over the network in accordance with the 309 expected behaviour in their deployment environments as strong privacy 310 measures may lead to degraded usability. 312 For example, a TV set or a smart screen playing the role of the Widex 313 Renderer can be very well used as a secondary display. In such a 314 case, the Widex Renderer must be discoverable and its should expose 315 its capabilities so that a Widex Server will be able to provide the 316 user interface that best matches those capabilities instead of 317 falling back to the default user interface, which generally leads to 318 a degraded user experience. 320 In another example, a Widex Server hosting sensitive applications 321 that are only visible by selected set users must protect the privacy 322 of the applications during discovery phase so that unauthorised users 323 are not even able to discover the existence of the application before 324 being prevented to initiate Widex sessions. 326 Privacy enforcement MUST allow implementation according to best 327 common practices of the selected service discovery and session setup 328 mechanism. 330 7. Acknowledgements 332 The authors would like to thank Lisa Dusseault for her comments that 333 made this document more readable. 335 8. References 337 8.1. Normative References 339 [DOM2.Core] 340 Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, 341 J., Champion, M., and S. Byrne, "Document Object Model 342 (DOM) Level 2 Core Specification", W3C Recommendation, 343 November 2000. 345 [DOM2.Events] 346 Pixley, T., "Document Object Model (DOM) Level 2 Events 347 Specification", W3C Recommendation, November 2000. 349 [DOM2.Style] 350 Wilson, C., Le Hegaret, P., and V. Apparao, "Document 351 Object Model (DOM) Level 2 Style Specification", 352 W3C Recommendation, November 2000. 354 [DOM3.Core] 355 Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, 356 J., and S. Byrne, "Document Object Model (DOM) Level 3 357 Core Specification", W3C Recommendation, April 2004. 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, March 1997. 362 [XML1.0] Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C., 363 and E. Maler, "Extensible Markup Language (XML) 1.0 (Third 364 Edition)", W3C Recommendation, February 2004. 366 8.2. Informative References 368 [W3C.NOTE-mmi-framework-20030506] 369 Raman, T., Larson, J., and D. Raggett, "W3C Multimodal 370 Interaction Framework", World Wide Web Consortium 371 NOTE NOTE-mmi-framework-20030506, May 2003, 372 . 374 [W3C.WD-emma-20050916] 375 Dahl, D., Chou, W., Johnston, M., Raggett, D., and G. 376 McCobb, "EMMA: Extensible MultiModal Annotation markup 377 language", World Wide Web Consortium LastCall WD-emma- 378 20050916, September 2005, 379 . 381 [W3C.WD-mmi-arch-20060414] 382 Bodell, M., Wahbe, A., Raggett, D., and J. Barnett, 383 "Multimodal Architecture and Interfaces", World Wide Web 384 Consortium WD WD-mmi-arch-20060414, April 2006, 385 . 387 [W3C.WD-sXBL-20050815] 388 Ferraiolo, J., Hickson, I., and D. Hyatt, "SVG's XML 389 Binding Language (sXBL)", World Wide Web Consortium WD WD- 390 sXBL-20050815, August 2005, 391 . 393 [WhatWG.WebApps1.0] 394 Hickson, I., "Web Applications 1.0", October 2005. 396 Authors' Addresses 398 Vlad Stirbu 399 Nokia 400 Visiokatu 3 401 Tampere 33720 402 Finland 404 Phone: +358 7180 08000 405 Email: vlad.stibu@nokia.com 406 Dave Raggett 407 W3C/Volantis 408 35 Frome Road 409 Bradford on Avon, Wiltshire BA15 2EA 410 United Kingdom 412 Phone: +44 1225 866240 413 Email: dsr@w3.org 415 Full Copyright Statement 417 Copyright (C) The Internet Society (2006). 419 This document is subject to the rights, licenses and restrictions 420 contained in BCP 78, and except as set forth therein, the authors 421 retain all their rights. 423 This document and the information contained herein are provided on an 424 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 425 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 426 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 427 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 428 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 429 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 431 Intellectual Property 433 The IETF takes no position regarding the validity or scope of any 434 Intellectual Property Rights or other rights that might be claimed to 435 pertain to the implementation or use of the technology described in 436 this document or the extent to which any license under such rights 437 might or might not be available; nor does it represent that it has 438 made any independent effort to identify any such rights. Information 439 on the procedures with respect to rights in RFC documents can be 440 found in BCP 78 and BCP 79. 442 Copies of IPR disclosures made to the IETF Secretariat and any 443 assurances of licenses to be made available, or the result of an 444 attempt made to obtain a general license or permission for the use of 445 such proprietary rights by implementers or users of this 446 specification can be obtained from the IETF on-line IPR repository at 447 http://www.ietf.org/ipr. 449 The IETF invites any interested party to bring to its attention any 450 copyrights, patents or patent applications, or other proprietary 451 rights that may cover technology that may be required to implement 452 this standard. Please address the information to the IETF at 453 ietf-ipr@ietf.org. 455 Acknowledgment 457 Funding for the RFC Editor function is provided by the IETF 458 Administrative Support Activity (IASA).