Internet DRAFT - draft-stirbu-widex-beep
draft-stirbu-widex-beep
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]
