idnits 2.17.1 draft-ietf-widex-requirements-04.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 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 465. ** 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 (January 8, 2007) is 6317 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: July 12, 2007 W3C/Volantis 6 January 8, 2007 8 Widget Description Exchange Service (WIDEX) Requirements 9 draft-ietf-widex-requirements-04 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 July 12, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2007). 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 68 3.8. State . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1. Architecture Requirements . . . . . . . . . . . . . . . . 6 72 4.2. Service Discovery and Session Setup Requirements . . . . . 6 73 4.3. Widex Objects Requirements . . . . . . . . . . . . . . . . 6 74 4.4. Transport Requirements . . . . . . . . . . . . . . . . . . 7 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 7 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 88 Intellectual Property and Copyright Statements . . . . . . . . . . 11 90 1. Introduction 92 With the Internet reaching out to more and more devices, people are 93 increasingly expecting to have access to services at anytime, from 94 anywhere and using any device. Such services are being developed 95 using Web technologies such as XML and distributed across the network 96 rather than resident on any one device. 98 2. Widex Entities 100 The following picture shows the primary Widex entities in a simple 101 and basic architecture. 103 +--------+ +--------+ 104 | | update interface | | 105 | Widex |----------------->| Widex | 106 | Server |<-----------------|Renderer| 107 | | event interface | | 108 +--------+ +--------+ 110 Figure 1: Widex Entities 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 this context, the user interface is understood as XML [XML1.0] 134 data describing the user interface. Typically, the XML data is 135 manipulated as levels 2 and 3 in the W3C Document Object Model (DOM), 136 see [DOM2.Core], [DOM3.Core], and [DOM2.Events] (W3C has yet to 137 complete work on DOM3 events). Style information associated with the 138 user interface can be manipulated via 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 is to define Widex Objects (WO) that are used to 165 convey information about interface updates and events. Widex Objects 166 are used to keep the rendered user interface synchronised with the 167 application logic. 169 There are two types of Widex Objects: 171 WO Update (WO.Update): 172 WO.Update object contain description of changes to XML DOM trees. 173 The updates can target individual nodes in order to update their 174 properties and attributes, or can target parts of the DOM tree in 175 order change its structure, e.g. add/delete/replace nodes or 176 branches. 178 WO Event (WO.Event): 179 WO.Event objects are primarily used to carry events triggered on 180 the Widex Renderer side so that they can be caught by the 181 application logic event handlers on the Widex Server side. Not 182 all events need to be forwarded to the application logic, as some 183 events have local scope and may be intended for default event 184 handlers or for local scripted event handlers. The application 185 logic in the Widex Server may only be interested in specific 186 events. 188 WO.Event object may carry data according to the type of the event, 189 e.g. application defined events with structured payloads as per 190 Extensible Multi-Modal Annotations [W3C.WD-emma-20050916], which 191 uses XML for annotated interpretations of user input. 193 A secondary use of WO.Event objects is where the application logic 194 itself raises events that may be caught by event handlers 195 associated with the remote user interface, see for example Web 196 Applications 1.0 [WhatWG.WebApps1.0]. 198 3.5. Transport Protocol 200 The Transport Protocol is a protocol that just transports the Widex 201 Objects as a string of bits, without looking at them. 203 3.6. Simple vs. Complex User Interfaces 205 Simple User Interface: 206 A simple user interface allows the user interface to be 207 represented with only one XML DOM object. Typically, a simple 208 user interface is associated with a single modality, e.g. vision 209 modality for graphic user interfaces. 211 Complex User Interface: 212 A complex user interface may include scripted client-side event 213 handlers or there can be more than one XML DOM in the user 214 interface, e.g. different DOMs for different modalities, but see 215 also SVG's XML Binding Language [W3C.WD-sXBL-20050815] for the 216 role of shadow DOMs. 218 3.7. Session 220 The Widex Session is initiated between a Widex Server and a Widex 221 Renderer for exchanging information about user interface updates 222 (e.g. WO.Update) and events (e.g. WO.Event) in order to control 223 applications remotely. A Widex Session relate to a single User 224 Interface, which can be simple or complex. 226 3.8. State 228 The Widex Server is maintaining the state of the user interface. 229 Upon ungraceful session break, the Widex Renderer retrieves the 230 current user interface state from the Widex Server when the session 231 is re-established. 233 Certain UI markup languages allow the remote renderers to operate in 234 disconnected mode. In such cases, the application is responsible for 235 keeping the state on the Widex Server consistent with the changes 236 occured in the Widex Renderer when it operated in disconnected mode. 238 4. Requirements 240 4.1. Architecture Requirements 242 o The service discovery and session setup component MUST be 243 replaceable. 244 o The transport component MUST be replaceable. 245 o Keeping the user interface and the application logic synchronised 246 MUST occur at a fairly loose level that allows for a simple 247 approach to propagating changes. 248 o The framework SHOULD be stateless. 249 o The framework SHOULD be consistent with the W3C Multimodal 250 Architecture [W3C.WD-mmi-arch-20060414]. 252 4.2. Service Discovery and Session Setup Requirements 254 o The service discovery mechanism MUST be able to discover both 255 Widex Renderers and Widex Servers. 256 o The service discovery mechanism MUST be able to negotiate the 257 capabilities of both Widex Renderers and Widex Servers, e.g. 258 supported devices physical characteristics, supported UI markup 259 languages, etc. 260 o The session setup mechanism MUST be able to initiate session 261 establishment from both Widex Renderers and Widex Servers, e.g. 262 remote user interface pull and push. 264 4.3. Widex Objects Requirements 266 o The Widex Objects MUST NOT be aware of the semantics of the UI 267 markup language. 268 o The Widex Objects MUST support client initiated events. 269 o The Widex Objects MUST support server initiated updates. 270 o The Widex Objects MUST contain only information meaningful in the 271 context of the Widex Session. 272 o The Widex Objects MUST indicate the target XML DOM tree when 273 Complex User Interfaces are involved. 274 o The Widex Objects MAY support multimodal interaction, and it is 275 the responsibility of the application to synchronise modalities 276 and not that of the Widex protocol. 278 4.4. Transport Requirements 280 o The Widex protocol MUST deliver Widex Objects in the order 281 determined by the originator regardless of the underlying network 282 topology. The order is relevant within a single Widex Session. 283 The co-ordination between several Widex Sessions in a Widex Server 284 is outside the scope of this document. 285 o The Widex protocol MUST handle each modality within the context of 286 a single Widex Session. 287 o The Widex protocol MUST provide reliable delivery of Widex 288 Objects. If this proves to be impractical in a given situation, 289 the protocol MUST provide the means for application to detect such 290 failures. 291 o The Widex protocol MUST tolerate limitations in available 292 bandwidth. 293 o The Widex protocol MUST tolerate delays caused by network induced 294 latency. Latency and time-outs may need to be handled at the 295 application level. 296 o The Widex protocol MUST have support for authentication and secure 297 sessions, e.g. data privacy and integrity. 299 5. IANA Considerations 301 This document makes no request of IANA. 303 6. Security Considerations 305 As a means to support remote user interfaces, a number of security 306 considerations need to be addressed, including the potential for 307 unauthorized access to application services, monitoring of 308 interactions by unauthorized third parties, spoofing of application 309 services as a means to support phishing attacks, and denial of 310 service attacks. 312 6.1. Privacy Considerations 314 Exposing the capabilities of Widex Servers and Widex Renderers using 315 the appropriate service discovery and session setup mechanism has 316 privacy implications as malicious users may harvest information about 317 physical characteristics and applications hosted by Widex Entities. 318 Implementors should carefully balance which characteristics of the 319 Widex Entities are exposed over the network in accordance with the 320 expected behaviour in their deployment environments as strong privacy 321 measures may lead to degraded usability. 323 For example, a TV set or a smart screen playing the role of the Widex 324 Renderer can be very well used as a secondary display. In such a 325 case, the Widex Renderer must be discoverable and its should expose 326 its capabilities so that a Widex Server will be able to provide the 327 user interface that best matches those capabilities instead of 328 falling back to the default user interface, which generally leads to 329 a degraded user experience. 331 In another example, a Widex Server hosting sensitive applications 332 that are only visible by selected set of users must protect the 333 privacy of the applications during discovery phase so that 334 unauthorised users are not even able to discover the existence of the 335 application before being prevented to initiate Widex sessions. 337 Privacy enforcement MUST allow implementation according to best 338 common practices of the selected service discovery and session setup 339 mechanism. 341 7. Acknowledgements 343 The authors would like to thank Lisa Dusseault and David Black for 344 their comments that made this document more readable. 346 8. References 348 8.1. Normative References 350 [DOM2.Core] 351 Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, 352 J., Champion, M., and S. Byrne, "Document Object Model 353 (DOM) Level 2 Core Specification", W3C Recommendation, 354 November 2000. 356 [DOM2.Events] 357 Pixley, T., "Document Object Model (DOM) Level 2 Events 358 Specification", W3C Recommendation, November 2000. 360 [DOM2.Style] 361 Wilson, C., Le Hegaret, P., and V. Apparao, "Document 362 Object Model (DOM) Level 2 Style Specification", 363 W3C Recommendation, November 2000. 365 [DOM3.Core] 366 Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, 367 J., and S. Byrne, "Document Object Model (DOM) Level 3 368 Core Specification", W3C Recommendation, April 2004. 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, March 1997. 373 [XML1.0] Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C., 374 and E. Maler, "Extensible Markup Language (XML) 1.0 (Third 375 Edition)", W3C Recommendation, February 2004. 377 8.2. Informative References 379 [W3C.NOTE-mmi-framework-20030506] 380 Raman, T., Larson, J., and D. Raggett, "W3C Multimodal 381 Interaction Framework", World Wide Web Consortium 382 NOTE NOTE-mmi-framework-20030506, May 2003, 383 . 385 [W3C.WD-emma-20050916] 386 Johnston, M., Chou, W., McCobb, G., Raggett, D., and D. 387 Dahl, "EMMA: Extensible MultiModal Annotation markup 388 language", World Wide Web Consortium LastCall WD-emma- 389 20050916, September 2005, 390 . 392 [W3C.WD-mmi-arch-20060414] 393 Bodell, M., Wahbe, A., Raggett, D., and J. Barnett, 394 "Multimodal Architecture and Interfaces", World Wide Web 395 Consortium WD WD-mmi-arch-20060414, April 2006, 396 . 398 [W3C.WD-sXBL-20050815] 399 Ferraiolo, J., Hickson, I., and D. Hyatt, "SVG's XML 400 Binding Language (sXBL)", World Wide Web Consortium WD WD- 401 sXBL-20050815, August 2005, 402 . 404 [WhatWG.WebApps1.0] 405 Hickson, I., "Web Applications 1.0", October 2005. 407 Authors' Addresses 409 Vlad Stirbu 410 Nokia 411 Visiokatu 3 412 Tampere 33720 413 Finland 415 Phone: +358 7180 08000 416 Email: vlad.stirbu@nokia.com 418 Dave Raggett 419 W3C/Volantis 420 35 Frome Road 421 Bradford on Avon, Wiltshire BA15 2EA 422 United Kingdom 424 Phone: +44 1225 866240 425 Email: dsr@w3.org 427 Full Copyright Statement 429 Copyright (C) The Internet Society (2007). 431 This document is subject to the rights, licenses and restrictions 432 contained in BCP 78, and except as set forth therein, the authors 433 retain all their rights. 435 This document and the information contained herein are provided on an 436 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 437 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 438 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 439 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 440 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 441 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 443 Intellectual Property 445 The IETF takes no position regarding the validity or scope of any 446 Intellectual Property Rights or other rights that might be claimed to 447 pertain to the implementation or use of the technology described in 448 this document or the extent to which any license under such rights 449 might or might not be available; nor does it represent that it has 450 made any independent effort to identify any such rights. Information 451 on the procedures with respect to rights in RFC documents can be 452 found in BCP 78 and BCP 79. 454 Copies of IPR disclosures made to the IETF Secretariat and any 455 assurances of licenses to be made available, or the result of an 456 attempt made to obtain a general license or permission for the use of 457 such proprietary rights by implementers or users of this 458 specification can be obtained from the IETF on-line IPR repository at 459 http://www.ietf.org/ipr. 461 The IETF invites any interested party to bring to its attention any 462 copyrights, patents or patent applications, or other proprietary 463 rights that may cover technology that may be required to implement 464 this standard. Please address the information to the IETF at 465 ietf-ipr@ietf.org. 467 Acknowledgment 469 Funding for the RFC Editor function is provided by the IETF 470 Administrative Support Activity (IASA).