Widex V. Stirbu Internet-Draft Nokia Intended status: Standards Track June 6, 2006 Expires: December 8, 2006 Using the Widget Description Exchange Service (WIDEX) over the Blocks Extensible Exchange Protocol (BEEP) draft-stirbu-widex-beep-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 8, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a lightweight implementation of a remote user interface protocol, compatible with the Widget Description Exchange Service (Widex) framework. The protocol is using the Block Extensible Exchange Protocol (BEEP) as the application transport substrate for the Widget Description Exchange Service. Stirbu Expires December 8, 2006 [Page 1]
Internet-Draft Widex-BEEP June 2006 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Table of Contents 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 2. BEEP Profile Identification . . . . . . . . . . . . . . . . . 3 2.1. Profile Initialisation . . . . . . . . . . . . . . . . . . 3 3. Widex Message Packages . . . . . . . . . . . . . . . . . . . . 5 4. Widex Message Patterns . . . . . . . . . . . . . . . . . . . . 5 5. URL Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. The widex.beep URL Scheme . . . . . . . . . . . . . . . . 5 5.2. The widex.beeps URL Scheme . . . . . . . . . . . . . . . . 6 6. BEEP Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Registrations . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. BEEP Profile Registration . . . . . . . . . . . . . . . . 6 7.2. The widex.beep URL Scheme Registration . . . . . . . . . . 7 7.3. The widex.beeps URL Scheme Registration . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Stirbu Expires December 8, 2006 [Page 2]
Internet-Draft Widex-BEEP June 2006 1. Introduction and Motivation The proposal in this document describes the Widex application transport binding that uses BEEP [2]. Requirements for Widex Framework and the specification in this document are outlined in Internet-Draft Widex Requirements [4]. The choice of BEEP as the transport protocol substrate is primarily driven by the need to reuse an existing, well-understood protocol with all the necessary features to support the requirements, particularly for peer-to-peer networks where is no need to bypass firewalls. The secondary reason is that BEEP offers two-way multiplexed communication that leads to reduced negotiation and network resource usage, criteria that is important for constrained devices for which it will be too costly to implement an alternative solution based around HTTP [9], ECMAScript [10] and XMLHttpRequest Object [11]. This would give the implementers a wealth of toolkits and debugging gear for use in constructing both Widex Servers and Widex Renderers. 2. BEEP Profile Identification The BEEP profile for Widex is identified as http://iana.org/beep/widex in the BEEP "profile" element during channel creation. In BEEP, when the first channel is successfully created, the "serverName" attribute in the "start" element identifies the "virtual host" associated with the peer acting in the server role, e.g. <start number='1' serverName='applicationserver.example.com'> <profile uri='http//iana.org/beep/widex' /> </start> 2.1. Profile Initialisation The initialisation is used for identifying that each channel bound to the BEEP profile for Widex provides access to a single application on the Widex Server. The DTD syntax for the ready message and its response are: Stirbu Expires December 8, 2006 [Page 3]
Internet-Draft Widex-BEEP June 2006 <!ELEMENT ready EMPTY> <!ATTRLIST ready application CDATA #REQUIRED> <!ELEMENT proceed EMPTY> The ready message contains a mandatory "application" attribute, which identifies the application who's user interface is exported by the Widex Server. If the peer acting in the server role recognises the requested resource, it replies with a proceed response. C: MSG 0 1 . 52 158 C: Content-Type: application/beep+xml C: C: <start number='1' serverName='applicationserver.example.com'> C: <profile uri='http//iana.org/beep/widex'> C: <![CDATA[<ready application='ApplicationName' />]]> C: </start> C: END S: RPY 0 1 . 110 121 S: Content-Type: application/beep+xml S: S: <profile uri='http//iana.org/beep/widex'> S: <![CDATA[<proceed />]]> S: </profile> Otherwise, it the ready message is improperly formed, or if the requested application isn't recognised, the peer acting in the server role replies with an error message. Stirbu Expires December 8, 2006 [Page 4]
Internet-Draft Widex-BEEP June 2006 C: MSG 0 1 . 52 158 C: Content-Type: application/beep+xml C: C: <start number='1' serverName='applicationserver.example.com'> C: <profile uri='http//iana.org/beep/widex'> C: <![CDATA[<ready application='GameName' />]]> C: </start> C: END S: RPY 0 1 . 110 121 S: Content-Type: application/beep+xml S: S: <profile uri='http//iana.org/beep/widex'> S: <![CDATA[<error code='550'>application not supported</error>]]> S: </profile> 3. Widex Message Packages The BEEP profile for Widex transmits Widex messages encoded as UTF-8 using the media type of "application/xml" according to RFC 3023 [6]. 4. Widex Message Patterns The BEEP profile for Widex has a one-to-one message pattern. Each Widex Message is send using a "MSG" message, containing a valid Widex XML instance, and MUST be acknowledged when received completely by an empty "RPY" message. 5. URL Schemes This memo defines two URL schemes, "widex.beep" and "widex.beeps" which identify the use of Widex over BEEP over TCP. 5.1. The widex.beep URL Scheme The "widex.beep" URL scheme uses the "generic URI" syntax defined in Section 3 of RFC 2396 [7], specifically: o the value "widex.beep" is used for the scheme component o the server-based naming authority defined in Section 3.2.2 of [7] is used for the authority component o the path component maps to the "application" component of the boot message sent during the profile initialisation (if absent, it defaults to "/"). Stirbu Expires December 8, 2006 [Page 5]
Internet-Draft Widex-BEEP June 2006 The values of values of both the scheme and authority components are case-insensitive. For example, the URL widex.beep://applicationserver.example.com/ApplicationName might result in the example shown in Section 2.1. 5.2. The widex.beeps URL Scheme The "widex.beeps" URL scheme is identical to the "widex.beep" URL scheme specified in Section 5.1, with the exception that prior to starting the BEEP profile for Widex, the BEEP session must be tunned for privacy. There are two ways to perform privacy tuning on a BEEP session: o a transport security profile is successfully started; o a user authentication profile that supports transport security is successfully started. Regardless of the method used, upon completion of the negotiation process, a tuning reset occurs in which both BEEP peers issue a new greeting. 6. BEEP Mapping The mapping of Widex in this document is specific to RFC 3080 [2]. This mapping MUST use TCP as specified by RFC 3081 [3]. 7. Registrations 7.1. BEEP Profile Registration Profile Identification: http://iana.org/beep/widex Messages exchanged during Channel Creation: ready Messages starting one-to-one exchanges: ready, Widex XML instance Messages in positive replies: proceed Messages in negative replies: error Messages in one-to-many replies: none Stirbu Expires December 8, 2006 [Page 6]
Internet-Draft Widex-BEEP June 2006 Messages Syntax: Widex XML instances as defined by Widex Framework [5]. Messages Semantics: Widex XML instances as defined by Widex Framework [5]. Contact Information: Vlad Stirbu <vlad.stirbu@nokia.com> 7.2. The widex.beep URL Scheme Registration URL scheme name: widex.beep URL scheme syntax: Section 5.1 Character encoding consideration: according to the "generic URI" syntax defined in Section 3 of RFC 2396 [7] Intended usage: identifies an application on a Widex Server who's user interface is made available for rendering on a Widex Renderer using the BEEP profile for Widex Applications using this scheme: defined in Widex Framework [5] Interoperability considerations: n/a Security Considerations: defined in Section 9 Relevant publications: BEEP [2] and Widex Framework [5] Contact Information: Vlad Stirbu <vlad.stirbu@nokia.com> Author/Change controller: the IESG 7.3. The widex.beeps URL Scheme Registration URL scheme name: widex.beeps URL scheme syntax: Section 5.2 Character encoding consideration: according to the "generic URI" syntax defined in Section 3 of RFC 2396 [7] Intended usage: identifies an application on a Widex Server who's user interface is made available for rendering on a Widex Renderer using the BEEP profile for Widex after the BEEP session has been tuned for privacy Applications using this scheme: defined in Widex Framework [5] Stirbu Expires December 8, 2006 [Page 7]
Internet-Draft Widex-BEEP June 2006 Interoperability considerations: n/a Security Considerations: defined in Section 9 Relevant publications: BEEP [2] and Widex Framework [5] Contact Information: Vlad Stirbu <vlad.stirbu@nokia.com> Author/Change controller: the IESG 8. IANA Considerations Registrations with IANA are described in Section 7. 9. Security Considerations Implementers should be fully aware of the security considerations given by Widex Framework [5], BEEP [2], and TLS [8]. Clients SHOULD be prepared to use at least the following BEEP tuning profiles: o http://iana.org/beep/SASL/DIGEST-MD5, for user authentication without the need for session encryption o http://iana.org/beep/TLS using TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher, for encryption o http://iana.org/beep/TLS using TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client client-side certificates, for encryption and user authentication Anonymous client access SHOULD be considered in one of the two methods: 1. when no authentication tuning profile has been used 2. when using the http://iana-org/beep/SASL/ANONYMOUS profile Care should be taken that user authentication mechanisms do not reveal user credentials to untrusted servers. Clients MUST NOT use the http://iana-org/beep/SASL/PLAIN tuning profile without first encrypting the TCP session, such as by using http://iana.org/beep/TLS tuning profile. Section 9 of BEEP [2] contains more details on BEEP-specific security issues. Stirbu Expires December 8, 2006 [Page 8]
Internet-Draft Widex-BEEP June 2006 10. Acknowledgements 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001. [4] Stirbu, V. and D. Raggett, "Widget Description Exchange Service (WIDEX) Requirements", draft-ietf-widex-requirements-02 (work in progress), May 2006. [5] Stirbu, V. and D. Raggett, "Widget Description Exchange Service (WIDEX) Framework", draft-stirbu-widex-framework-01 (work in progress), June 2006. [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 11.2. Informative References [9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [10] ECMA, "ECMAScript Language Specification, 3rd Edition", Standard ECMA-262, December 1999. [11] Jackson, D. and A. Kesteren, "The XMLHttpRequest Object", World Wide Web Consortium WD http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405, April 2006. Stirbu Expires December 8, 2006 [Page 9]
Internet-Draft Widex-BEEP June 2006 [12] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002. Author's Address Vlad Stirbu Nokia Visiokatu 3 Tampere 33720 Finland Phone: +358 7180 60572 Email: vlad.stirbu@nokia.com Stirbu Expires December 8, 2006 [Page 10]
Internet-Draft Widex-BEEP June 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Stirbu Expires December 8, 2006 [Page 11]