XEP-xxxx: Personal Media Network

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document must not be referred to as an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://www.xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.

Table of Contents

1. Introduction

XMPP is designed for instant messaging, but its extensible structure makes it suitable for other use cases including automated client-to-client communication without any user interaction. Ad-Hoc Commands [1] and SOAP over XMPP [2] are only two examples of the usage of XMPP outside the instant messaging domain. XMPP makes it possible for two entities to communicate even if they are in different private networks or have a dynamic IP address. Unlike HTTP both peers can send messages to each other. Today UPnP [3] is used in the local area network for inter-process communication between media devices. UPnP defines a HTTP based core and specific services on top of this core. This architecture works in a closed network environment but is not secure against attackers inside the LAN and does not support entities being outside the LAN. The HTTP based approach makes it impossible to connect to an entity from outside a LAN behind a NAT with a dynamic public IP address.

This document describes a secure client-to-client communication to replace UPnP with an XMPP based core and an additional security layer. This personal media network core can be used by additional XEPs to define UPnP like services such as media player control, media access and recording control. This document is named Personal Media Network but other use cases with secure client-to-client communication such as home automation are also possible.

2. Requirements

The protocol is designed for client-to-client communication, keeping the server requirements to a minimum. Right now a XMPP Basic Server 2008 [4] is sufficient to be used as a server for the personal media network. Later versions of this document may require additional protocols implemented on server side. All entities of a user register with the same bare JID, the number of parallel connected resources on the server limits the size of the media network.

3. Use Cases

There are various use cases for both the integration of XMPP in media devices and for using UPnP like services outside the LAN. It is possible to share information between different media networks and even interact with a friend's media network.

4. Service Provider and Controller

The inter-process communication described in this document is based on a client-server architecture. One node (server) provides a service to other nodes (client). The server part is called Service Provider, the client Controller. One device can provide several services and may also need to control a service on a third node to provide a specific service. The controller needs to discover the different service providers to control them, the service provider needs to support evening to send updates to the controller on the internal status.

A service provider can be controlled by remote procedure calls (RPC) using iq stanzas and can send events about status changes to subscribed controllers. A service provider provides one or more services defined by other XMPP extensions outside the scope of this document. To interact with a service provider a controller MUST send commands to the service provider, a service provider MUST NOT contact a node it never interacted with before. Depending on the service, a service provider MAY interact with another service providers providing the same service for synchronization. If the service provider requires a different service from another entity, it MAY also be a controller for that other service.

5. Security Considerations

The private media network requires end-to-end security between clients defined by Jingle XTLS [6] and Public Key Publishing [7]. These two specifications are not widely deployed yet. Contact me if you are interested in interoperability test since I have a test implementation. Client Certificate Management for SASL EXTERNAL [8] is also nice-to-have but there are no servers implementing it.

6. Service Discovery

To discover a service provider XMPP presence information are used. The service provider and the controller MUST either share the same bare JID or have presence subscription in both ways. This is needed for the controller to locate the service provider and for the service provider to get notified when a controller leaves the network.

A service is described using Service Discovery [9] and announced using Entity Capabilities [10]. Each service is described by a feature. The controller acts as a client to the service provided by the service provider. It has to support the feature of the service from client side but does not offer the service to other entities. This means that a controller is not announcing the service on service discovery.

The following example shows the service discovery from Romeo's mobile phone of a possible future service Remote Media Player provided by one of Julia's devices (see Media Network Interaction).

Example 1. Service Provider Discovery

<iq type='get'
    from='romeo@montague.net/b345687ba7607d3ddf401a0257464843a0a1c0b7'
    to='juliet@capulet.com/da39a3ee5e6b4b0d3255bfef95601890afd80709'
    id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq type='result'
    from='juliet@capulet.com/da39a3ee5e6b4b0d3255bfef95601890afd80709'
    to='romeo@montague.net/b345687ba7607d3ddf401a0257464843a0a1c0b7'
    id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='automation'
        type='service'
        name='Media Player'/>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='urn.xmpp.tmp.media.player'/>
  </query>
</iq>

7. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [11].

8. XMPP Registrar Considerations

The XMPP Registrar Considerations will be included in a later version of this document.

9. XML Schema

The XML schema will be included in a later version of this document.

Appendices

Appendix A: Document Information

Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Standards Track
Version: 0.0.2
Last Updated: 2009-08-13
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: NOT YET ASSIGNED

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata may be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

END