Added XML schema; fixed a number of minor issues.
Clarified a number of issues; cleaned up specification.
First (semi) complete version supporting all use cases.
First rough draft.
The &rfc3283; describes the relationship between various internet calendaring specifications like this: "&rfc2445; is the language used to describe calendar objects. &rfc2446; (Transport-Independent Interoperability Protocol) describes a way to use the iCalendar language to do scheduling. &rfc2447; (Message-Based Interoperability Protocol) describes how to do iTIP scheduling via e-mail."
+Recently another standard track protocol for calendar and scheduling access has appeared. &rfc4791; (Calendaring Extensions to WebDAV) is a &rfc4918; (Web-based Distributed Authoring and Versioning) based mechanism for manipulating internet calendars, and viewing free/busy lists, and via a planned &draft-sched;, could be used for proposing calendar events as well.
+This specification defines calendaring extensions to &xep0060; for the purposes of group calendaring and scheduling between "Calendar Users" (CUs) as defined by iTIP. Additionally, it defines extensions for accessing, managing, and sharing calendaring and scheduling information on a calendar server, reusing the syntax and semantics defined by CalDAV. Finally, it defines a mechanism for reminding of upcoming events by alarm notifications.
+The protocol enables all common transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components, as well as search for busy time information. The protocol is a superset of Publish-Subscribe and will gracefully degrade to Publish-Subscribe for clients that do not support the calendaring extensions defined.
+This specification follows the same pattern as the Internet calendaring and scheduling standards by developing all features based on a well-described data model. This model is described in Calendaring Data Model. As a brief overview, calendars are modeled as nodes of a calendaring-aware publish-subscribe service; each calendar node contains a number of items representing calendar objects. Each item representing a calendar object (event, to-do, journal entry, or other calendar components) is called a "calendar item".
+Calendar objects are represented using &draft-xcal;. The format is not an alternative or next generation of iCalendar but defines how to use XML to represent iCalendar objects in XML. For example, both examples below describe the same single event that begins on July 14, 1997 at 00:00 UTC and ends on July 15, 1997 at 03:59 UTC.
+This specification is structured as follows: Discovering Support describes how to discover support for the calendaring extensions defined by this specification. An entity may create new calendar nodes as described in Creating Calendars. The section on Scheduling Calendar Entries provides the transport specific information necessary to convey iTIP messages over Publish-Subscribe which enables transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. The sections Retrieving Calendar Entries and Retrieving Free/Busy Time define how to retrieve items from a calendar node, and how to search for busy time information. Alarm Notifications provide a mechanism for setting up and subscribing to alarm notifications.
+In order to refer to elements of the calendaring and scheduling model, core object or interoperability protocol defined in RFC 2445 and RFC 2446 several formatting conventions have been utilized.
+Calendaring and scheduling roles are referred to in quoted-strings of text with the first character of each word in upper case. For example, "Organizer" refers to a role of a "Calendar User" (CU) within the scheduling protocol defined by RFC 2446.
+Scheduling methods defined by RFC 2446 are referred to with capitalized, quoted-strings of text. For example, "REQUEST" refers to the method for requesting a scheduling calendar component be created or modified, "REPLY" refers to the method a recipient of a request uses to update their status with the "Organizer" of the calendar component.
+Calendar components defined by RFC 2445 are referred to with capitalized text. All calendar components start with the letter "V". For example, VEVENT refers to the event calendar component, VTODO refers to the to-do calendar component and VJOURNAL refers to the daily journal calendar component.
+Properties defined by RFC 2445 are referred to with capitalized, quoted-strings of text, followed by the word "property". For example, "ATTENDEE" property refers to the iCalendar property used to convey the calendar address of a "Calendar User". Property parameters are referred to with lower case, quoted-strings of text, followed by the word "parameter". For example, "value" parameter refers to the iCalendar property parameter used to override the default data type for a property value. Values are referred to with quoted-strings of text, either alone or followed by the word "value".
+Implementers will need to be familiar with several other specifications that describe the Internet calendaring and scheduling standards. The related documents are:
+This specification is an extension of the Publish-Subscribe protocol specified by XEP-0060, so implementers will need to be familiar with that as well.
+This specification does not attempt to repeat the specification of concepts or definitions from these other specifications. Where possible, references are made to the specification that provides that provides the relevant concepts or definitions.
+A calendar service is a calendaring-aware engine combined with a publish-subscribe service. A publish-subscribe service enables XMPP entities to create nodes and publish information at those nodes; an event notification (with or without payload) is then broadcasted to all entities that have subscribed to the node.
+A calendar service MAY include calendar data in some of its nodes, and non-calendaring data in others.
+A publish-subscribe service can advertise itself as a calendar service if it supports the functionality defined in this specification at any of its nodes. That might mean that calendar nodes are spread throughout the service and mixed with non-calendar nodes. Calendaring features are only required in the nodes that are calendar nodes.
+The calendar service is the canonical location for calendar data and state information. Entities may submit requests to change data or download data. Entities may store calendar objects offline and attempt to synchronize at a later time. However, entities MUST be prepared for calendar data on the service to change between the time of last synchronization and when attempting an update, as calendar nodes may be shared and accessed by multiple entities.
+A calendar node contains calendar items that represent calendar components within a calendar. A calendar node is manifested to entities as a publish-subscribe node identified by a NodeID. A calendar node MUST report the '&NS;' feature &VNOTE; in the result of a 'disco#info' query. A calendar service MUST persist items for a calendar node.
+A calendar node can be created through provisioning (i.e., automatically created when a user's account is provisioned), or it can be created with the publish-subscribe <create/> request (see section Creating Calendars). It can be useful for a user to create additional calendars (e.g., soccer schedule) or for users to share a calendar (e.g., team events or conference rooms). However, note that this specification doesn't define the purpose of calendar nodes. Users may use the 'pubsub#title' and 'pubsub#description' fields in node meta-data to find out what a calendar node is for.
+Calendar nodes MUST only contain calendar items. This ensures that entities do not have to deal with non-calendar data in a calendar node.
+Calendar items in a calendar node MUST NOT contain more than one type of calendar component (e.g., VEVENT, VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE components, which MUST be specified for each unique "TZID" parameter value specified in the iCalendar object. For instance, a calendar item can contain one VEVENT component and one VTIMEZONE component, but it cannot contain one VEVENT component and one VTODO component. Instead, the VEVENT and VTODO components would have to be stored in separate calendar items in the same node.
+Calendar object items in calendar collections MUST NOT specify the iCalendar "METHOD" property.
+The "UID" property value of the calendar components contained in a calendar item MUST be unique in the scope of the calendar node in which they are stored.
+Calendar components in a calendar node that have different "UID" property values MUST be stored in separate calendar items.
+Calendar components with the same "UID" property value, in a given calendar node, MUST be contained in the same calendar item. This ensures that all components in a recurrence "set" are contained in the same calendar item. It is possible for a calendar item to just contain components that represent "overridden" instances (ones that modify the behavior of a regular instance, and thus include a "RECURRENCE-ID" property) without also including the "master" recurring component (the one that defines the recurrence "set" and does not contain any "RECURRENCE-ID" property).
+This specification uses methods defined by RFC 2446 for exchanging calendar objects for the purposes of group calendaring and scheduling between "Calendar Users" (CUs). CUs take on one of two roles in iTIP. The CU who initiates an exchange takes on the role of "Organizer". For example, the CU who proposes a group meeting is the "Organizer". The CUs asked to participate in the group meeting by the "Organizer" take on the role of "Attendee".
+Note: "role" is also a descriptive parameter to the "ATTENDEE" property. Its use is to convey descriptive context to an "Attendee" such as "chair", "req-participant" or "non-participant" and has nothing to do with the calendaring workflow.
+A calendar entry is created and managed by an "Organizer". The "Organizer" interacts with other CUs by sending one or more requests specifying the "REQUEST" method to a calendar service which will forward these to "Attendees" (and send notifications to pubsub subscribers). "Attendees" use the same requests specifying the "REPLY" method to communicate their status back to the calendar service. "Attendees" cannot make any changes to the calendar entry except for their own status. They can, however, use requests specifying the "COUNTER" method to suggest changes to the "Organizer". In any case, the "Organizer" has complete control over the master calendar entry.
+| Method | +Description | +
|---|---|
| PUBLISH | +Used to publish a calendar object to a calendar node and when sending notifications to pubsub subscribers. There is no interactivity between the publisher and any other calendar user. An example might include a baseball team publishing its schedule to the public. | +
| REQUEST | +Used to schedule a calendar entry with other Calendar Users. Requests are interactive in that they require the receiver to respond using the Reply methods. Invitations and the assignment of To-Dos to other Calendar Users are examples. Requests are also used by the "Organizer" to update the status of a calendar entry. | +
| REPLY | +A Reply is used in response to a Request to convey "Attendee" status to the calendar service (which will forward it to the "Organizer"). Replies are commonly used to respond to meeting and task requests. | +
| ADD | +Add one or more instances to an existing VEVENT, VTODO, or VJOURNAL. | +
| CANCEL | +Cancel one or more instances of an existing VEVENT, VTODO, or VJOURNAL. This does not remove the calendar entry from persistent storage. | +
| COUNTER | +The Counter method is used by an "Attendee" to negotiate a change in the calendar entry. Examples include the request to change a proposed Event time or change the due date for a To-Do. | +
The methods listed above and their usage and semantics are defined in section 3 of RFC 2446.
+The other methods defined by RFC 2446, REFRESH and DECLINECOUNTER, are not used and MUST NOT be specified by requesting entities. Entities SHOULD use the reporting methods defined in this specification to request the latest version of a calendar entry. "Organizers" MAY decline a proposed counter-proposal by sending a rude chat message to the "Attendee" who proposed the counter-proposal.
+Subscriptions to a calendar node may exist in three different ways.
+ +&TODO;
+Group scheduling is accomplished using the set of "request" and "response" methods described above. To manage permissions, this specification builds on the hierarchy of affiliations defined by XEP-0060. Therefore, a calendar service MUST support and adhere to the requirements of pubsub affiliations. Calendaring permissions are calculated from the pubsub affiliation of the XMPP entity and, if applicable, the properties of the calendar item involved in an operation.
+ +&TODO;
+There are two distinct states relevant to calendar entries: the overall state of the entry and the state associated with an "Attendee" to that entry.
+The state of an entry is defined by the "STATUS" property and is controlled by the "Organizer." There is no default value for the "STATUS" property. The "Organizer" sets the "STATUS" property to the appropriate value for each calendar entry.
+The state of a particular "Attendee" relative to an entry is defined by the "partstat" parameter in the "ATTENDEE" property for each "Attendee". When an "Organizer" issues the initial entry, "Attendee" status is unknown. The "Organizer" specifies this by setting the "partstat" parameter to "needs-action". Each "Attendee" modifies their "ATTENDEE" property "partstat" parameter to an appropriate value.
+The "SEQUENCE" property is used by the "Organizer" to indicate revisions to the calendar item. The rules for incrementing the "SEQUENCE" number for a given "UID" in a calendar component are as follows:
+The value of the "SEQUENCE" property contained in a response from an "Attendee" may not always match the current revision of the master calendar entry. Implementations may choose to indicate to the "Attendee" that the response is to an entry that has been revised and allow the CU to decide whether or not to send the response.
+Calendar services must often correlate a component in a calendar node with a component received in a pubsub request. For example, an event may be updated with a later revision of the same event. To accomplish this, a calendar service must correlate the version of the event already in the calendar node with the version sent in the pubsub request. In addition to this correlation, there are several factors that can cause requests to arrive in an unexpected order. That is, a calendar service could receive a reply to an earlier revision of a component AFTER receiving a reply to a later revision.
+To maximize interoperability and to handle messages that arrive in an unexpected order, implementations SHOULD follow the rules in section 2.1.5 of RFC 2446. Hence, a calendar service must persist the following component properties: "UID", "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property of a component a calendar service must persist the "SEQUENCE" and "DTSTAMP" property values associated with the "Attendee's" response.
+A calendar service MUST respond to service discovery information requests qualified by the 'http://jabber.org/protocol/disco#info' namespace. The "disco#info" result returned by a calendar service MUST indicate the identity of a pubsub service and indicate which pubsub features are supported. A calendar service supporting the features described in this specification MUST also include "&NS;" as a feature in the "disco#info" result. A feature of "&NS;" &VNOTE; in the result MUST indicate that the service supports all MUST level requirements in this specification.
+A calendar service MUST also allow entities to query individual nodes for the information associated with that node. A calendar service supporting the features described in this specification MUST include "&NS;" &VNOTE; as a feature in the "disco#info" result for a calendar node. It MUST NOT include the feature in the result for a non-calendar node. The "disco#info" result MAY include detailed meta-data about the node as described in section 5.4 of XEP-0060.
+An entity may want to create a new calendar node. Support for this feature is RECOMMENDED. However, a calendar service MAY disallow creation of calendar nodes based on the identity of the requesting entity, or MAY disallow calendar node creation altogether (e.g., reserving that privilege to a service-wide administrator).
+The methods to create a node are explained in section 8.1 of XEP-0060. To create a new calendar node, the requesting entity MUST include a Data Form containing a 'pubsub#type' field whose <value/> is "urn:ietf:params:xml:ns:xcal".
+If calendar nodes are supported and none of the general or method-specific errors has occurred, the calendar service SHOULD create the node and inform the requesting entity of success.
+In addition to the errors already defined for leaf nodes by XEP-0060, there are several reasons why the calendar node creation request might fail:
+These error cases are described more fully in the following sections.
+ +If the calendar service does not allow new calendar nodes to be created, it MUST respond with a ¬allowed; error.
+If the requesting entity has insufficient privileges to create new calendar nodes, the service MUST respond with a &forbidden; error.
+A calendar service MUST offer a couple of node configuration options that are specific to calendar nodes and not provided by standard pubsub leaf nodes. The following table shows these configuration options and defines a mapping to the calendar properties specified by RFC 4791:
+| Configuration option | +Type | +Description | +CalDAV property | +
|---|---|---|---|
| pubsub#title | +text-single | +Provides a human-readable description of the calendar node. | +calendar-description | +
| &SN;#timezone | +text-single | +Specifies a time zone on a calendar node. | +calendar-timezone | +
| &SN;#component_set | +text-multi | +Specifies the calendar component types (e.g., VEVENT, + VTODO, etc.) that calendar items can contain in the calendar + node. | +supported-calendar-component-set | +
| pubsub#type | +text-single | +Specifies what media types are allowed for calendar items in + a calendar node. | +supported-calendar-data | +
| pubsub#max_payload_size | +text-single | +Provides a numeric value indicating the maximum size of a + resource in octets that the calendar service is willing to accept + when a calendar item is stored in a calendar node. | +max-resource-size | +
| &SN;#min_date_time | +text-single | +Provides a DATE-TIME value indicating the earliest date and + time (in UTC) that the calendar service is willing to accept for + any DATE or DATE-TIME value in a calendar item stored in a calendar + node. | +min-date-time | +
| &SN;#max_date_time | +text-single | +Provides a DATE-TIME value indicating the latest date and + time (in UTC) that the calendar service is willing to accept for + any DATE or DATE-TIME value in a calendar item stored in a calendar + node. | +max-date-time | +
| &SN;#max_instances | +text-single | +Provides a numeric value indicating the maximum number of + recurrence instances that a calendar item stored in a calendar + node can generate. | +max-instances | +
| &SN;#max_attendees_per_instance | +text-single | +Provides a numeric value indicating the maximum number of + "ATTENDEE" properties in any instance of a calendar item stored + in a calendar node. | +max-attendees-per-instance | +
An entity SHOULD should specify the 'pubsub#title' field for a human-readable name of the calendar when configuring a calendar node. The entity SHOULD NOT set the 'pubsub#title' field to be the same as any other calendar node owned by the same entity. When displaying calendar nodes to users, clients SHOULD check the 'pubsub#title' field and use that value as the name of the calendar. In the event that the 'pubsub#title' field is empty, the client MAY use the NodeID of the calendar as the name; however, the NodeID may be "opaque" and not represent any meaningful human-readable text.
+An entity may schedule calendar entries by sending a <publish/> request to the calendar service. Support for this feature is REQUIRED.
+The syntax is as follows:
+The example below publishes a single event that begins on July 1, 1997 at 20:00 UTC. This event contains the minimum set of properties for publishing an event to a calendar.
+If the calendar service can successfully process the request, it MUST inform the publisher of success. If the publish request did not include an ItemID, the IQ-result SHOULD include an empty <item/> element that specifies the ItemID of the published item.
+Note: If the publisher previously published an item with the same ItemID, successfully processing the request means that the service MUST proceed as described in RFC 2446 for the calendaring-specific method used. This usually means that the service MUST overwrite the old calendar entry with a modified entry and then proceed as follows.
+The calendar service MUST then send one &MESSAGE; stanza containing a pubsub event notification to each entity that meets the criteria for receiving a notification, as described in section 7.1.2 of XEP-0060. Event notifications MUST be sent specifying the "PUBLISH" method, even if the event notification results from a publishing request that specified a different method.
+In addition to the errors already defined for publish requests by XEP-0060, there are several reasons why the request might fail:
+These error cases are described more fully in the following sections.
+ +If the namespace of the root payload element submitted in the request does not match the configured namespace for the node (i.e., the 'urn:ietf:params:xml:ns:xcal' namespace) or the payload does not conform to the syntax of the 'urn:ietf:params:xml:ns:xcal' namespace, the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of <invalid-payload/>.
+If the calendar component submitted in the request does not contain a type of calendar component that is supported in the calendar node (see section Calendar Node Configuration), the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of <item-forbidden/>.
+If the calendar component submitted in the request does not obey all restrictions specified in section Calendar Items (e.g., calendar items MUST NOT contain more than one type of calendar component), in section Request (e.g., the request MUST specify an iCalendar "METHOD" property, etc.), and/or those defined for the specified iCalendar method, the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of <invalid-payload/>.
+If the calendar component submitted in the request does not conform to the configuration of the calendar node where the component will be stored (see section Calendar Node Configuration), the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition. The following rules apply:
+A calendar service MUST allow entities to request existing calendar items from a calendar node. The reporting method described in this section is an extension of the pubsub <items/> request (defined in section 6.4 of XEP-0060), but can involve much more complex processing. This is valuable in cases where the calendar service has access to all of the information needed to perform the complex request (such as a query), and where it would require multiple requests for the client to retrieve the information needed to perform the same request.
+The <calendar-query/> report performs a search for all calendar items that match a specified filter. The response of this report will contain all the calendar item data specified in the request. In the case of the <calendar-data/>, one can explicitly specify the calendar components and properties that should be returned in the calendar item data that matches the filter.
+Support for the <calendar-query/> report is REQUIRED.
+The syntax is as follows:
+If the calendar service can successfully process the request, it SHOULD return all requested calendar item data, although it MAY truncate the result set if it contains a large number of items.
+In addition to the errors already defined for retrieval requests by XEP-0060, there are several reasons why the request might fail:
+These error cases are described more fully in the following sections.
+ +If the <filter/> element does not conform to the syntax of the 'urn:ietf:params:xml:ns:caldav' namespace, the service MUST respond with a &badrequest; error. For instance, a <filter/> cannot nest a <comp name='VEVENT'/> element in a <comp name='VTODO'/> element, and a <filter/> cannot nest a <time-range start='...' end='...'/> element in a <prop name='SUMMARY'/> element.
+If any <comp-filter/>, <prop-filter/>, or <param-filter/> element used in the <filter/> element in the report request makes a reference to components, properties, or parameters for which queries are not supported by the server (i.e., if the <filter/> element attempts to reference an unsupported component, property, or parameter), the service MUST respond with a &badrequest; error.
+If the reporting request does not conform to the configuration of the calendar node being queried (see section Calendar Node Configuration), the service MUST respond with a &badrequest; error. The following rules apply:
+If any XML attribute specifying a collation does not specify a collation supported by the calendar service as described in section 7.5 of RFC 4791, the service MUST respond with a &badrequest; error.
+The <free-busy-query/> report generates a VFREEBUSY object containing free busy information for all the calendar items targeted by the request and that have the "read-free-busy" or "read" privilege granted to the requesting entity. The reporting method described in this section is an extension of the pubsub <items/> request (defined in section 6.4 of XEP-0060).
+Support for the <free-busy-query/> report is REQUIRED.
+Only VEVENT objects without a "TRANSP" property or with the "TRANSP" property set to "opaque", and VFREEBUSY components SHOULD be considered in generating the free busy time information.
+In the case of VEVENT objects, the free or busy time type ("fbtype" parameter) of the "FREEBUSY" properties in the returned VFREEBUSY object SHOULD be derived from the value of the "TRANSP" and "STATUS" properties; see section 7.10 of RFC 4791.
+Duplicate busy time periods with the same "fbtype" parameter value SHOULD NOT be specified in the returned VFREEBUSY component. A calendar service SHOULD coalesce consecutive or overlapping busy time periods of the same type. Busy time periods with different "fbtype" parameter values MAY overlap.
+The syntax is as follows:
+In the following example, Juliet requests the server to return free busy information on the calendar "ccfc0b59-b9d9-4d0f-ac2f-829e7077640e", between 9:00 A.M. and 5:00 P.M. EST (2:00 P.M. and 10:00 P.M. UTC) on the January 4, 2006.
+If the calendar service can successfully process the request, it MUST return the generated VFREEBUSY object. The example indicates two busy time intervals of one hour, one of which is tentative.
+There are no errors in addition to those already defined for retrieval requests by XEP-0060.
+ +An "ORGANIZER" MAY include a VALARM calendar component in any VEVENT or VTODO component. A VALARM calendar component is a grouping of component properties that is a reminder or alarm for an event or a to-do. For example, it may be used to define a reminder for a pending event or an overdue to-do.
+The following example publishes an event with a VALARM calendar component that specifies an audio alarm that will sound at a precise time and repeat 4 more times at 15 minute intervals:
+When an entity wishes to subscribe to a calendar node, it sends a subscription request to the calendar service using the <subscribe/> element described in section 6.1 of XEP-0060. To subscribe to alarm notifications, an entity MAY configure its subscription to have the "&SN;#notify_alarm" configuration option set to "true". The entity MAY subscribe and provide the subscription options in the same stanza (as described in 6.3.7 of XEP-0060), or configure the subscription at any time after subscribing (as described in section 6.3 of XEP-0060).
+When an alarm is triggered, the calendar service MUST send one &MESSAGE; stanza containing a alarm notification to each entity that meets the criteria for receiving a alarm notification (typically to each approved subscriber who configured its subscription to have the "calendar#notify_alarm" configuration option set to "true"). Depending on the node configuration, the alarm notification either will or will not contain the payload, as shown below.
+If the node is configured to include payloads, the subscribers will receive payloads with the alarm notifications.
+If the node is configured to not include payloads, the subscribers will receive alarm notifications only. (If payloads are not included, subscribers may request the calendar item via the protocol defined in the Retrieving Calendar Entries section of this document.)
+&TODO;
+ +&TODO;
+ +&TODO;
+ + + + +&TODO;
+ +&TODO;
+ +&TODO;
+&TODO;
+&TODO;
+This document introduces no additional security considerations above or beyond those defined in the documents on which it depends.
+This document does not require interaction with &IANA;.
+This specification defines the following XML namespaces:
+Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespaces to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.
+If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.
+&TODO;
+&TODO;
+
+
+
+
+
+
+ The protocol documented by this schema is defined in
+ XEP-xxxx: http://www.xmpp.org/extensions/xep-xxxx.html
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+First draft.
Updated after further analysis of edge cases.
At the time of original writing of this XEP, many XMPP servers + handle message stanzas sent to a user@host (or "bare") JID with no + resource by delivering that message only to the resource with the + highest priority for the target user. Some server implementations, + however, have chosen to send these messages to all of the online + resources for the target user. If the target user is online with + multiple resources when the original message is sent, a conversation + ensues on one of the user's devices; if the user subsequently + switches devices, parts of the conversation may end up on the + alternate device, causing the user to be confused, misled, or + annoyed.
+ +This XEP defines an approach for ensuring that all of my devices + get both sides of all conversations in order to avoid user + confusion. As a pleasant side-effect, information about the current + state of a conversation is shared between all of a user's clients + that implement this protocol.
+If a server implements the Message Carbons capability, it MUST specify the + 'urn:xmpp:carbons:0' feature in its service discovery + information features as specified in &xep0030; or section 6.3 of &xep0115;. + Clients MUST NOT enable or disable Carbons if their server does + not support this feature.
+Servers MUST NOT enable the Carbons protocol for a client by + default, since unmodified clients might be confused by the new + protocol. When a client wants to participate in the Carbons + protocol, it sends an IQ set to enable the protocol.
+Carbons will generally be enabled before the client sends the + first undirected presence, to ensure that all inbound messages + will be delivered according to the Carbon rules. The server will + respond with an IQ result when Carbons are enabled:
+Some clients might want to disable Carbons. An example of this + might be a mobile client that wants Carbons when the application + is in the foreground, and disabled when it is in the background. + To disable Carbons, clients send an IQ set:
+The server will respond with an IQ result when Carbons are disabled:
+Enabling or disabling Carbons may fail in the several ways. If + one of these errors is returned, the server MUST keep the previous + state, where the initial state is Carbons disabled. For example, + if the first enable returns an error, the server MUST NOT enable + Carbons.
+The sender has sent a stanza containing XML that does not + conform to the appropriate schema or that cannot be processed. + One example is an IQ stanza that includes an unrecognized value + of the 'type' attribute. Another is changing to the state that + is already in effect (enabling Carbons a second time).
+The sender has sent an enable or disable request to a server + that does not support the protocol. This SHOULD NOT happen in + practice, because clients MUST check for server support before + sending their request.
+The sender does is forbidden by policy from enabling or + disabling Carbons.
+The receiver does not allow any entity to turn on Carbons. + This might occur in a multi-domain deployment, where + administrators of one domain allow Carbons, but another does + not.
+Messages of type chat that are addressed to the bare JID + (localpart@domain) MUST be copied by the receiving server to all of the + resources for that user that have non-negative presence priority + and have not filtered messages through some other means. The + process of making copies is known as "forking." The receiving + server SHOULD NOT modify the 'to' address of the forked + messages.
+ +Messages of type "chat" that are addressed to a full JID + (localpart@domain/resource) MUST be sent by the receiving server to the + addressed resource, and MUST also be sent to all of the + Carbons-enabled resources for the receiving user. The goal of + the copies to Carbons-enabled resources is to allow those clients + to have both halves of *all* IM conversations, including messages + that are sent from clients that lock in to particular resources.
+Once most of the clients that are deployed have implemented + Carbons, clients MAY choose to always send chat type messages to + the bare JID. Until then, traditional resource locking is + RECOMMENDED. (Note: another XEP might be written to document + traditional resource locking, if the documentation in &rfc3921bis; + is not sufficient.)
+ +Also note that &xep0085; recommends sending chat state + notifications as chat type messages, which means that they will be + subject to Carbon-copying. This is intentional.
+Carbons clients want to have copies of messages going in + both directions for other resources associated with the + same user. To that end, messages of type chat that are sent from + any resource MUST be copied by the sending server to each of the + resources that have enabled Carbons, but are not the sending + resource. Note that the 'to' address will be the original target of + the message (bare JID, as above), and the 'from' address will + contain the full JID (localpart@domain/resource) of the sending + resource. The 'to' address not matching the JID of the session is + somewhat unprecedented in XMPP, which is why Carbons must be + explicitly enabled.
+ +Messages that have carbon copies sent back to Carbons-enabled + resources MUST NOT be copied back to the originating client. The + copies MUST have the full JID (localpart@domain/resource) of the sender + as the 'from' address. The copies MUST include a sent element in + the urn:xmpp:carbons:0 namespace.
+ +Some clients might want to avoid carbons on a single message, + while still keeping all of the other semantics of Carbon support. + This might be useful for clients sending end-to-end encrypted + messages, for example.
+ +To avoid a message being Carbon-copied to its other resources, + the sending client MUST add a private element in the + urn:xmpp:carbons:0 namespace. When the sending server receives + the message, it MUST NOT make carbon copies to the other + Carbons-enabled resources, and MUST remove the private element + before forwarding the message to the intended recipient.
+ +Note: use of the private mechanism will lead to partial + conversations on other devices. This is the intended effect.
+ +Clients that implement Carbons MAY take special use of + &xep0085; notifications.
+It is RECOMMENDED that upon receiving an outbound gone + chat state (as a carbon copy) for a given conversation, that + conversation be removed from user display as if the user on the + copied client had terminated the conversation. In order to + prevent unwanted termination of conversations on other resources, + clients SHOULD NOT send gone chat states on logout, but + instead SHOULD count on the unavailable presence to convey the change + in attention.
+Upon receiving an outbound notification of any chat state other + than gone, the copied client MAY conclude that the + sending client has taken responsibility for the conversation, and + make appropriate user interface modifications. For example, + notifications could be muted on non-primary devices.
+When a receiving server attempts to deliver a forked message, + and that message bounces with an error for any reason, the + receiving server MUST NOT forward that error back to the original + sender. The receiving server SHOULD use the sent element in the + bounce to determine that an error is from a forked message.
+This rule is used to prevent some of the half-failure modes + that have been an issue in other prototocols.
+Clients that automatically respond to messages for any reason + (e.g. when in DND presence state) MUST take adequate care when + enabling Carbons in order to prevent storms or loops. Carbon + copies of outbound messages MUST NOT be auto-replied to under any + circumstances. Forked inbound messages SHOULD NOT be auto-replied + to, unless the client has some way of knowing that the receiver + will not receive more than one auto-reply from other similar + clients for the same user.
+Since mobile devices often must pay for network traffic based + on usage, the enablement of Carbons for such devices should be + undertaken advisedly. More complicated mechanisms for controlling + the Carbon-copying or forking of individual conversations may need + to be added to deal with mobile clients in the future.
+The security model assumed by this document is that all of the + resources for a single user are in the same trust boundary.
+Outbound chat messages that are encrypted end-to-end are not often + useful to receive on other resources. As such, they should use the + private element specified above to avoid such copying, unless the + encryption mechanism is adjusted to have knowledge of Carbons.
+This document requires no interaction with &IANA;.
+This specification defines the following XML namespace:
+Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+
+Rewrote the introduction, clarified the security considerations, requested issuance of an appropriate URN from the XMPP Registrar.
First draft.
Various XMPP extensions, such as &xep0166;, require additional support from clients, advertised in presence via &xep0115;, or require that IQ stanzas are sent to a particular resource. For instance, Jingle calls can be made only by sending an IQ to a particular resource. However, two parties who wish to communicate do not always shared presence information and therefore cannot use &xep0115; to determine the correct resource (full JID) for communication. Indeed, one of the parties might not even use XMPP: e.g., a remote user on the other side of a gateway to a network based on the Session Initiation Protocol (SIP; &rfc3261;) or to the Public Switched Telephone Network (PSTN). It would be helpful if a user could make a call through such a gateway by typing the SIP URI or telephone number of an arbitrary contact, without first exchanging presence.
+ +This document defines an XML protocol extension to request that enables two parties to temporarily reveal their presence to each other through an intentional presence leak that we call "decloaking".
+ +Note: This protocol has already been implemented using an XML namespace of "&DECLOAK;" but the ®ISTRAR; is requested to issue the XMPP URN "urn:xmpp:decloak:0" upon publication of this proposal in the &xep0001; series.
+ +An entity should be able to attempt to initiate a communication session that requires IQs and/or capability negotiation (Jingle, a file transfer, end-to-end encryption, or other similar communication modes) with an arbitrary entity.
+ +If the receiving entity agrees to divulge their presence in this way, minimal presence (with no 'type' attribute, &SHOW; element, avatar hash, etc.) and capabilities should be communicated to the initiating entity, so that the initiating entity can continue to initiate the communication session.
+ +Suppose that Juliet wishes to make a media call to Tybalt, but the two parties do not share presence information in accordance with &xmppim;. Suppose also that Juliet and Tybalt have the following presence, although neither can initially see the other's presence:
+ +Juliet requests that Tybalt divulges his availability and capabilities, by sending directed presence to his bare JID <tybalt@shakespeare.lit>, where the presence stanza contains a <decloak/> element.
+ +Tybalt MAY decloak one or more resources in response, by sending directed presence from those resource(s) to Juliet's bare JID.
+ +Once Juliet has received the decloaked presence from Tybalt, if necessary she can perform service discovery to find out the meaning of the entity capabilities hashes (if unknown), then proceed to make a Jingle call, initiate a file transfer, or complete some other use case.
+ +Alternatively, Tybalt MAY ignore the request (in particular, this will happen for any resource that does not implement this specification).
+ +Let us now suppose that Juliet wishes to make a media call to Romeo, who does not use XMPP but who has a SIP URI of sip:romeo@shakespeare.lit, which can be called via an XMPP-to-SIP gateway.
+ +Juliet requests that the SIP contact representing Romeo on the gateway shall divulge its availability and capabilities, by sending directed presence to its bare JID at the gateway containing a <decloak/> element.
+ +In response, the SIP gateway automatically decloaks on behalf of that JID, in order to tell Juliet what the gateway's capabilities are.
+ +As above, Juliet can now complete service discovery and any protocol-specific use cases.
+ +To signal the type of communication that is desired, the entity that first decloaks MAY include a 'reason' attribute on the <decloak/> element. The following values for the 'reason' attribute are defined:
+ +Inclusion of the 'reason' attribute can be interpreted by the receiving client as a signal that communication is about to start; for instance, a call accept/reject dialog could double as a UI for accepting or rejecting a decloaking request.
+ +To limit the extent of the presence leak, the receiving entity SHOULD send only bare presence without the XMPP &PRIORITY;, &SHOW;, or &STATUS; element. Unfortunately, this has two implications:
+ +The initiating entity cannot know which of the receiving entity's resources is more likely to engage in communication. This might imply that the initiating entity will need to send a session initiation request or other communication to more than one of the receiving entity's resources (and then retract the session initiation requests that are not answered by the receiving entity). Solutions to that problem are out of scope for this specification.
Set up of a session might be delayed (e.g., because in Jingle it is desirable to start negotiating candidates as soon as possible but a user interface that prompts the receiving entity to explicitly approve of divulging presence will tend to delay call setup). As a result, it may be advantageous to have a way to configure unconditional decloaking in certain deployments, at least within the same trust domain.
Because decloaking is a presence leak (albeit intentional), an XMPP client that implements the receiving side of this specification MUST disable decloaking by default and MUST enable the feature only as a result of explicit user configuration. (Gateways and other non-user entities MAY divulge their own presence and capabilities unconditionally, if that is appropriate for the service policy at the gateway.)
+ +This document requires no interaction with &IANA;.
+The XMPP Registrar is requested to issue an initial namespace of "urn:xmpp:decloak:0".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+The need for this protocol extension, and a rough proposal for solving the problem, were originally determined at XMPP Summit 5 in the summer of 2007. Thanks to Diana Cionoiu, Justin Karneges, and Justin Uberti for their input to those discussions.
+Simplified the protocol to use a master-slave approach; modified terminology.
First draft.
&xep0045; defines a full-featured technology for multi-user text conferencing in XMPP. By design, XEP-0045 assumes that a conference room is hosted at a single service, which can be accessed from any point on the network. However, this assumption introduces a single point of failure for the conference room, since if occupants at a using domain lose connectivity to the hosting domain then they also lose connectivity to the room. In some deployment scenarios (and even on the open Internet) this behavior is suboptimal. Therefore, this document attempts to define a technology for distributing MUC rooms across multiple services.
+This specification addresses the following requirements:
+The basic approach to distribution of MUC rooms is as follows:
+The room IDs of source rooms SHOULD be opaque to users and unique across all possible peerhosts, for example by generating a UUID in accordance with &rfc4122; or by hashing the human-readable name of the room using the SHA-256 algorithm in accordance with &nistfips180-2;.
+This document adds the following terms to those defined in XEP-0045:
+In this document, the examples use the following entities.
+When the original room owner creates the room (or subsequently configures the room), the service MAY offer the option of making the room a "distributed room". This is done by including the "muc#roomconfig_distributed" feature in the room configuration form:
+The room owner specifies a value of "1" or "true" &BOOLEANNOTE; if room distribution is desired:
+Alternatively, the firsthost can choose to perform room distribution in the background, rather than exposing the 'muc#roomconfig_distributed' option to the user.
+When a firsthost would like a peerhost to provide a shadow, it sends a replication request to the peerhost.
+If the peerhost is willing and able to replicate the room, it returns an IQ-result:
+Several error cases are possible (the peerhost is resource constrained, the firsthost is forbidden to peer with the peerhost, etc.); these will be specified more fully in a future version of this specification.
+Once the peerhost acknowledges that it is willing and able to replicate the room, four things happen:
+The new shadow SHOULD request the room history. This is done by sending an IQ-get from the shadow to the source, containing a <history/> element qualified by the 'http://jabber.org/protocol/muc' namespace (the syntax and semantics of this element are described in XEP-0045).
+The history request MAY include any of the attributes specified in XEP-0045:: 'maxchars', 'maxstanzas', 'seconds', and 'since'.
+The firsthost also informs other connected peerhosts about the new peerhost.
+When a user attempts to join a source room, the firsthost determines if it will invite the user to join a shadow at a peerhost instead. The process for determining when to send invitations is implementation specific and might be subject to configuration at the firsthost (e.g., the firsthost might send invitations only to users of a domain associated with the peerhost and only after a certain number of such users have joined the room at the firsthost).
+To begin, a user at the peerhost attempts to join the source room at the firsthost:
+The source room returns a <redirect/> presence error to the user and invites the user to join a shadow room instead.
+Then the source invites the user to the shadow using the protocol defined in &xep0249;.
+The user then joins the shadow.
+The shadow then informs the source (and any other shadows) of the user's presence; it does so by sending presence from the roomjid of the user at the shadow to a roomjid with the same roomnick at the source and shadow(s).
+The source then delivers that presence stanza to its local users. (Note: The shadow needs to send only one presence stanza to the source, thus reducing the number of stanzas sent over the server-to-server link between the peerhost and the firsthost.)
+When a user sends a message to an instance, the instance sends the message to its local occupants and to other instances.
+The source then delivers that message stanza to its local users. (Note: The shadow needs to send only one message stanza to the source, thus reducing the number of stanzas sent over the server-to-server link between the peerhost and the firsthost.)
+To follow.
+If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" &NSVER; in response to &xep0030; information requests.
+To follow.
+This document requires no interaction with &IANA;.
+This document requires no interaction with the ®ISTRAR;.
+Thanks to Jay Carlson, Boyd Fletcher, and Michael Krutsch for their early conversations regarding distributed chatrooms.
+To follow.
+First draft.
As large hosting providers begin providing XMPP services for multiple domains, several issues with previous mechanisms for server-to-server federation have become apparent.
+A large number of sockets are currently required between hosting providers. Although servers MAY attempt to piggyback whenever possible, the possibility exists that 2*N*M sockets will be created (where N is the number of domains on one hosting provider, and M is the number of domains on another hosting provider). The goal would be that the number of sockets was dependent on load or deployment considerations.
+In order to enable or require encryption, the hosting provider needs to create a separate socket for each hostname pair and have access to a X.509 certificate that is signed by a widely-trusted CA and includes both the public and private keys. Customers of hosting providers might be uncomfortable with the level of trust this requires.
+This document describes an approach known as Domain Name Assertions (DNA) that allows providers to effectively host XMPP services on behalf of other companies, and might be expanded later to support other protocols.
+The DNA mechanism can be used for multiple different protocols. In particular, client-to-server XMPP and server-to-server XMPP are discussed herein, but the general approach could be used for non-XMPP protocols such as SMTP. As such, the protocol syntax offered here is normative for XMPP, but merely illustrative for other protocols, which will need their own protocol bindings.
+The following domain names are used in the examples:
+The asserting entity asserts a domain name through the use of an assert element. Assertions MUST contain a "from" attribute naming the domain name that is being asserted.
+When the validating entity has been satisified that the asserting entity is authoritative for the domain name asserted, it MUST send a <valid/> element. At this point, the asserting entity can send stanzas to the validating entity containing "from" addresses in the asserted and validated domain.
+Validating entities SHOULD respond to a domain name assertion without asking for further proof when the domain name asserted is represented in the certificate offered by the asserting entity according to the rules set out in &rfc3920bis;.
+Validating entities MAY respond to a domain name assertion without asking for further proof when the domain name asserted is known to be associated with the asserting entity through some other secure means such as DNSSEC (&rfc4033;), caching, or local knowledge. In the DNSSEC case, the server hostname in the SRV record used to connect SHOULD be looked for in the certificate offered by the asserting entity, according to the rules set out in rfc3920bis.
+When the validating entity does not accept proof offered by the asserting entity, or it no longer trusts the proof (for example due to the proof timing out or being revoked), it sends the asserting entity an <invalid/> element. The asserting entity MUST NOT send any stanzas to the validating entity containing "from" addresses in the invalidated domain without performing another validation.
+Invalid responses MAY be given in direct response to an assertion if the validating entity has reason to believe that no proof is possible. Examples that would cause this response include a blocking list or a negative cache.
+If an assertion cannot be validated immediately, the validating entity MAY ask for further proof. In the "prove-it" request, at least one form of proof that will be acceptable MUST be disclosed to the asserting entity.
+A proof type MUST be a valid URI. A registry of proof types will be created. Standard proof types will begin with "urn:xmpp:dna:proof:". Custom proofs SHOULD be signaled with a type attribute value containing a full URI under the control of the defining party. Proof types MUST be compared for equality using the rules for URIs (see &rfc3986;).
+Some proof types MAY require information or nonces from the validating entity. If so, the specification for that proof type MUST specify extensions to the proof element in a new namespace.
+In some protocols, a challenge MAY be sent without an assertion, if the validating entity has reason to believe that the entity with which it is talking is authoritative for a given domain (for example, through a DNS lookup).
+If the validating entity requires proof, but will not accept proof by a means that the asserting entity has available for the asserted domain, the asserting entity MUST respond with an <impossible/> element. The validating entity MUST NOT send a <valid/> or <invalid/> element in response, and MUST NOT accept stanzas from the asserted domain on this connection unless some other assertion works in the future.
+The <impossible/> element MAY be sent after full validation, if the asserting entity would like to retract the assertion.
+If an asserting entity thinks it can prove a given assertion when challenged, it sends that proof in a <proof/> element. The REQUIRED 'type' attribute specifies the chosen proof type, and the REQUIRED 'from' attribute specifies the domain being proved. Each proof type MUST specify the format of the contents of the proof element. Suggestions for formats include base64-encoded binary as character data or structured XML in a new namespace.
+This section is preliminary.
+When an asserting entity has been delegated responsibility for hosting a given domain, an Attribute Certificate (as specified in &rfc3281;) can be used to prove the delegation. The proof type URI associated with attribute certificates SHALL be 'urn:xmpp:dna:proof:attribute-cert' (EDITOR'S NOTE: let's come up with a new, good URN prefix for these. If we move this to an I-D, it should be an IETF URN.)
+Each protocol that is delegated will be assigned its own OID for an attribute type. (EDITOR's NOTE: fill in OIDs for xmpp-server and xmpp-client delegation). The values associated with a given attribute are a list of references to hosting provider certificates, one of which MUST have been offered by the asserting entity and accepted by the validating entity (except for name) during the TLS certificate exchange. (EDITOR's NOTE: normative language required for the form of certificate references).
+The certificate that signed the attribute certificate MUST have been acceptable as proof of ownership of a given domain for the protocol in question, according to the rules in rfc3920bis. Validating entities SHOULD try prepending the asserted domain with "www." and re-checking for name matches before rejecting the signing certificate, in order to allow for easier deployments using existing web certificates as proof.
+The attribute certificate is encoded as PKCS12 (see http://www.rsa.com/rsalabs/node.asp?id=2138), including the signing certificate and all of the CA certificates in the trust chain of the signing certificate, back to a trust anchor. The certificate is then ascii-armored according to (?), and transmitted as the character data of a proof element.
+Two XMPP servers, each of which hosts multiple domains that they do not directly control, desire to connect in order to exchange traffic for at least two of those domains, one on either side (we call this a "dimain pair").
+The following domain names are used in the examples:
+In a delegated hosting scenario, DNS SRV records are REQUIRED, since otherwise the hosting provider will never be contacted for the target domain. As specified by &rfc3920; the originating server looks up the target domain to find a list of receiving servers. If the originating server already has a connection to the IP address represented by one of these servers (perhaps because it is communicating with another domain hosted by this provider), it MAY reuse that stream (see Stream Reuse). If the originating server does not have a connection it wants to reuse, it performs the SRV algorithm to select an SRV record and makes a TCP connection to the server and port specified by the selected SRV record.
+Unless assured by a mechanism such as DNSSEC, the originating server MUST NOT trust the information received from the DNS SRV as proof that the target domain has been delegated to the receiving server.
+The first step during stream negotiation MUST be Start-TLS. The receiving server MUST offer a certificate signed by a widely-trusted CA. The receiving server MUST require a client certificate. The certificate offered by the originating server MUST be signed be a widely-trusted CA. Each side MUST check the certificate offered to it for validity (e.g. time period, signatures, and trust anchor), but MUST NOT disconnect when the certificate received does not contain a name matching its expectations.
+The names on these certificates SHOULD be associated with the relevant hosting provider, and need not be related to the domains being hosted. If the certificates have the name of the server offered in the SRV record, it MAY be possible to use DNSSEC for proof in the future.
+The "to" and "from" addresses are REQUIRED on the stream:stream tag. These represent the first domain pair associated with this stream, and are the domain names from the stanza that caused this connection to be established.
+ +To announce its support for DNA, the receiving server asserts its identity in the stream features following TLS negotiation.
+If the originating server supports DNA, it looks for an assertion in the stream features. If it finds none, it MAY fall back on another means of verifying the identity of the target server, if allowed by local policy.
+Originating servers that support DNA talking to target servers that declare support for DNA MUST NOT send protocol other than DNA negotations until they are able to validate the assertion offered by the target server in the stream features. The first validation proves to the originating server that it is talking to a server authoritative for the target domain, so that it is safe to use this domain in "to" addresses on this stream.
+Once an originating server completes this first validation it signals that it is willing and able to participate in bi-directional XMPP federation traffic, as long as all of the domains required have been asserted and validated at least once on this stream.
+If the originating server does not require more proof (due to a certificate match or DNSSEC-verified delegation), it MAY send a valid element without requesting proof first, as in all DNA interactions.
+Before either side sends stanzas on a given stream, it MUST ensure that the other side will accept those stanzas by asserting the domain in the "from" attribute of those stanzas, and waiting for a <valid/> response before sending the stanzas in question.
+The originating server MUST therefore send its own assertion after accepting the target domain's assertion.
+Before either side sends stanzas on a given stream, it MUST ensure that the other side is authoritative for the domain in the "to" attribute on those stanzas. If the sender has already accepted an assertion on this stream, and that assertion has not been revoked with an <impossible/> element, no action is required. Otherwise, the sender can proactively request proof for that domain by sending a challenge even though the other side has not sent an assertion for that domain yet.
+When two hosting providers connect, they might have previous knowledge (perhaps from a cache) of which domains they will trust on the new connection. If so, either side MAY send as many <valid/> elements as desired, even though the other side has not sent assertions for those domains.
+The server receiving these proactive validations MUST NOT change its self-image (i.e., the list of domains for which it is authoritative), but SHOULD NOT send assertions for these domains on this stream. If the server receiving a proactive validation is no long authoritative for a given domain, it MUST send an <impossible/> element, at which point the sender MUST remove the receiver from any cache and not send any stanzas on this stream to the given domain.
+Any cache of DNA information SHOULD be associated with the certificate offerred by the relevant server, and SHOULD be checked for revocation if possible, according to local policy.
+DNA streams are bi-directional, and might have an arbitrary number of domains validated in either direction, at any point in the lifetime of the stream. Before sending a stanza on a given stream, the sender MUST ensure that <valid/> elements have been exchanged according to the above rules for both the "to" and "from" address, and that no <invalid/> or <impossible/> element has revoked an assertion.
+An <impossible/> or <invalid/> element SHOULD NOT cause the rest of the stream to become invalidated in either directions. When these elements are seen, they SHOULD merely change the list of domains that are valid on that stream. If no domains are valid on the stream, the stream MAY be closed immediately, or MAY be left open if desired. If left open, the stream MUST NOT be used for stanza traffic until domains are asserted as needed for the desired domains.
+Domains that are marked as <invalid/> or <impossible/> SHOULD NOT be retried on the same stream unless new information has become available, in order to prevent assertion storms.
+If the first server-to-server validation exchange fails, the parties MAY keep the connection open (perhaps for a shorter period than is usual) in case another domain pair would need a connection between these servers.
+The parties SHOULD ensure that only one challenge is outstanding on a given connection for a given domain, and that only one assertion or one proof is outstanding on a given connection for a given domain.
+Hosting providers have a similar problem for client-to-server connections. Clients need to ensure that they are talking to an authoritative server for the domain they intend to log in to. Typically, this is done by examining the certificate offered by the server during TLS negotiation, according to the rules in rfc3920bis. However, hosting providers will typically not have access to a valid certificate for the target domain and its associated private key. DNA can be used for the hosting provider to prove that hosting services have been delegated to it.
+ +To announce its support for DNA, the server asserts its identity in the stream features following TLS negotiation. The server MUST offer the identity of the domain specified in the client's stream header "to" attribute.
+To utilize the server's DNA assertion, the client performs Start-TLS per rfc3920bis, however, if the client does not find a name match on the offered certificate, it does not disconnect immediately. Instead, if the server offers an assertion, it can use the name from that assertion to ask the server for proof of delegation.
+Subsequent protocol follows the generic use cases above, with the exception that alternate or additional domain names MUST NOT be asserted. If the server returns an <impossible/> element, the server MUST terminate the stream. If the client sends an <invalid/> element, the client MUST terminate the stream.
+The domains offered are International Domain Names, as specified in rfc3920bis.
+For the urn:xmpp:dna:proof:attribute-cert proof type, the trust path for an assertion flows from two different trust anchors, one that proves the identity of the hosting provider, and another that proves the identity of the delegating party.
+All proof types SHALL have a mechanism to limit the period of availability.
+All proof types SHALL include a mechanism for revocation.
+A new registry of proof types will be required, which might be maintained by the ®ISTRAR; or by &IANA;. These proof types have URI syntax.
+To follow.
+Proto-XEP draft.
+Digital signatures may be used to provide a number of security services, including message + authentication, message integrity and non-repudiation. There are many use cases for Digital + Signatures in the Extensible Messaging and Presence Protocol (&xmpp;).
+XMPP can be described as a mean for exchanging structured information or stanzas between two + or more entities. To accomplish this exchange, a number of other entities may be involved. For + instance, communication of a stanza between two client entities will typically involve one or + more server entities. Entities may exchange stanzas through service entities, such as a chat + room service, to effect one-to-many communications.
+Any entity involved in the exchange of a stanza may have wish to include one or more digital + signatures for the benefit of any entity involved in the exchange:
+Digital signatures are provided to serve specific purposes. These purposes might include + authentication of a particular entity involved in the exchange and integrity of information + that entity provided.
+ +This document discusses considerations for the design of + general-purpose digital signature extension for XMPP. The document discusses use cases and requirements, as well as explores the + solution space. The document also discusses existing solutions in + this area.
+ +This document contains a numerous examples intended to aide in the discussion of design + issues. The examples are examples generally abbreviated and often use informal syntaxes.
+Directed one-to-one stanzas are stanzas which are exchanged between two entities, the + originator of the stanza and intended recipient of that stanza, without exchanging through + services which provide re-direction of stanzas (such as a groupchat service). The stanza may + be handled by one or more other entities.
+Examples of directed one-to-one stanzas include chat &MESSAGE; used in one-to-one chat + sessions and &IQ; stanzas (excepting those exchanged through services providing re-direction).
+The originator may wish to provide a signature for the benefit of the intended recipient. + The intended recipient could use this signature to authenticate the originator and to ensure + integrity of originator provided information.
+Entities handling the stanza may wish to provide a signature for the benefit of the + intended recipient. For instance, where a originator is a client and does not provide a + signature, the client's server may wish to provide a signature for the benefit of the + intended recipient. The intended recipient could use this signature to authenticate this + server and to ensure integrity of the information as forwarded by this server.
+Redirected one-to-one stanzas which are exchanged between two entities, the originator of + the stanza and intended recipient of that stanza, through a service which provides + re-direction of stanzas. The stanza may be handled by one or more other entities.
+A multi-user chat (MUC) 'private message' is an example of redirected one-to-one + stanza.
+The originator's server may wish to provide a signature for the benefit of the re-direction + service. The service could use this signature to authenticate the originator and to ensure + integrity of originator provided information.
+The originator may wish to provide a signature for the benefit of the intended recipient. + The intended recipient could use this signature to authenticate the originator and to ensure + integrity of originator provided information. However, this signature would by itself not + establish any relationship between the signer and 'from' address in the stanza as received, + nor does it establish this signature establish that the stanza was processed by the + re-direction service. As in the directed one-to-one + stanza, a originating client's server may wish to provide a signature for the + benefit of the intended recipient.
+The re-direction service may wish to provide a signature for the benefit of the intended + recipient. The intended recipient could use this signature to authenticate the service and + hence establish the service processed the stanza. The intended recipient could also use the + signature to ensure the integrity of the information as redirected by the service.
+Redirected one-to-many stanzas which are exchanged between two or more entities, the + originator of the stanza and a group of recipients, through a service which provides + re-direction of stanzas of a single stanza to a set of recipients. The stanza may be handled + by one or more other entities.
+A multi-user chat (MUC) message to all occupants is an example of redirected one-to-group + stanza.
+The originator's server may wish to provide a signature for the benefit of the re-direction + service. The service could use this signature to authenticate the originator and to ensure + integrity of originator provided information.
+The originator may wish to provide a signature for the benefit of each recipient in the + group. Each recipient could use this signature to authenticate the originator and to ensure + integrity of originator provided information. However, this signature would by itself not + establish any relationship between the signer and the 'from' address in the stanza as + received, nor does it establish this signature establish that the stanza was processed by + the re-direction service. As in the directed one-to-one + stanza, a originating client's server may wish to provide a signature for the + benefit of the each recipient.
+The re-direction service may wish to provide a signature for the benefit of each recipient + in the group. Each recipient could use this signature to authenticate the service and hence + establish the service processed the stanza. Each could also use the signature to ensure the + integrity of the information as redirected by the service.
+The presence can be viewed as a specialized "publish-subscribe" mechanism. Commonly the + publishing entity sends a &PRESENCE; stanza to a presence service and the presence + service than forwards the stanza to each subscriber. In basic user presence, the publishing + entity is the user's client and the presence service is presence service is the provided by + this client's server. In this case, the 'to' address is empty.
+The publisher may wish to sign the signature for the benefit of each subscriber. Each + subscriber could use this signature to authenticate the publisher and to ensure integrity of + publisher provided information.
+The presence service may wish to provide a signature for the benefit of each subscriber. + Each subscriber could use this signature to authenticate the service and hence establish the + service processed the stanza. Each could also use the signature to ensure the integrity of + the information as redirected by the service.
+A presence stanza may also directed to another entity, possibly through a re-direction + service. This use is similar to the directed one-to-one + and redirected one-to-one cases detailed above.
+For the purposes of this memo, the following requirements are stipulated:
+The &IETF; standardized a signing and encryption facility for XMPP known as + &xmppe2e;. XMPP E2E is based upon Secure/Multipurpose Internet Message Extensions + (&SMIME;) and the Cryptographic Message Syntax (&CMS;). As it's name implies, XMPP + E2E is intended to be an end-to-end solution. That is, it enables a sender to sign content + sent to a specific recipient.
+An advantage of the XMPP E2E approach is that it uses an encapsulating signature which + protects the signed content from alteration as it is exchanged over an XMPP network. A + disadvantage is that implementations which do not support XMPP E2E cannot make use of the + signed content.
+At the time of this writing, XMPP E2E has not been widely implemented. XMPP E2E appears to + have limited applicability.
+Alternative approaches have been developed. For instance, the Cross Domain Collaborative + Information Environment (&CDCIE;) Client Chat Protocol (&CDCIE-CCP;), an XMPP-based + protocol, supports signing of XMPP stanzas utilizes XML digital signatures (&XMLDSIG;) + "enveloped" signatures over the whole stanza.
+An advantage of the CDCIE-CCP approach is that, because it uses an encapsulated signature, + implementations need not support CDCIE-CPP to make use of the stanza. The disadvantage is + that the signature always over the entire stanza. Alteration of the stanza, as is common + (often required) when exchanging stanzas over an XMPP network, will invalidate the + signature.
+While this approach has been implemented and deployed to some extent, the approach appears + to have applicability limited to the CDCIE.
+An encapsulating signature is a signature approach that encapsulates the signed content + within the signature syntax. An encapsulated signature is a signature approach where the + signature syntax in encapsulated within the structure of the signed content. XMPP E2E is an + example of the former. CDCIE-CCP is an example of the latter.
+ +The following example illustrates, using pseudo language, an encapsulating signature over a + &MESSAGE; stanza.
+To transfer a signed &MESSAGE; using an encapsulating signature, one needs to send it + within &MESSAGE; stanza.
+The following example illustrates, using pseudo language, an encapsulated signature over a + &MESSAGE; stanza.
+Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E, are + generally limited to end-to-end use cases. That is, cases where the originator of a stanza + signs the stanza and send it through the XMPP network to its intended recipient, and only + the intended recipient is expected to make use of the signed content. Entities between the + signer and the intended recipient are expected to forward of the stanza without regard to + the encapsulating signature, and without themselves signing the stanza. The approach does + not require forwarding entities to support the signing extension.
+Simple encapsulating signatures have limited applicability in MUC and PubSub use cases. For + instance, an occupant can sign its submissions to the service for the benefit of the service + and the service can sign reflected stanzas to occupants. In providing non-anonymous chat + rooms, in addition to signing the reflected content, the service should include and sign the + stanza it received when it was signed. This allows the occupants verify the content the + service purports to have received, and to determine whether the reflected content is + consistent given this. The following example illustrates an encapsulating signature over a + groupchat &MESSAGE; stanza.
+The following examples illustrates the signed reflection of the above stanza.
+In encapsulated signature solutions, as in CDCIE-CCP, any entities can make use of the + signed content even if they do not support the signing extension. If the signature is over + the entire stanza, as in CDCIE-CCP, the signature is likely not to be valid when the stanza + is passed through multiple entities prior to verification. Hence, when the signature is over + the entire stanza, the encapsulating signature approach applicability is generally limited + to cases where there no entities between the signer and verifier. However, as discussed + below, encapsulated selective signatures are generally + more applicable.
+While an entity could provide a signature to be over the entire stanza, such signatures are + likely be invalidated as the stanza exchanged over the XMPP. This is because XMPP allows + and, in many cases, requires stanza to be modified as they are forwarded.
+For instance, a client with the JID "juliet@example.com/Balcony" might send the following + signed stanza:
+The example.com server is required, per &rfc3920;, to add a 'from' attribute to the + &MESSAGE; element before forwarding it to the example.net server. The example.net server + is required to replace the 'to' attribute with the full JID of the romeo@example.net client + it intends to forward the message to. These alternatations will "break" the signature.
+ +XMLDSIG provides for a facility to selective sign XML content. For instance, the client + could sign the &SUBJECT; and &BODY; element and their content. However, this by + itself would not cover key aspects of the stanza, such that it was a chat &MESSAGE; + addressed to a particular JID and sent from a particular JID. XMLDSIG allows for enveloping + signatures, that is a signature that signs a data object contained within the + &SIGNATURE; element. The solution could define an element, such as &XMPPprop; used + below, for including properties of the stanza in the signature.
+The signature in Example 1 does not provide any protection against replay attack. To + address replay attack, as well as other concerns, XMLDSIG defines the + &SIGNATUREPROPERTIES; element for including information items about the generation of + the Signature, such as the date/time the signature was generated.
+While one could have &SIGNATURE; which included a &REFERENCE; element for each of + four elements discussed above within its &SIGNEDINFO; element, this would require + reference validation for each &REFERENCE; (See 2.3 of XMLDSIG). To provide greater + flexibility over handling of absent references and broken digest values, a &MANIFEST; + can be constructed and only it signed.
+ + +Putting all of the above together, the client might send the following signed stanza:
+The signature references needs to unambiguously identify content in stanza even in face of + subsequent modification of that stanza. Failure to unambiguously identify signed content + would also be problematic.
+ +In the above example, signed child elements of the stanza were identified by 'id' + attribute. As stanzas may be forwarded into any XMPP stream, such identifiers needs to + remain unique.
+ +Use of an extension attribute to identify elements may be problematic. In particular, the + XMPP specifications provide no assurance that this attribute would be forwarded with + element. While one could identify signed content by other means, such as &XPointer;, + these means would not unambiguously identify the signed content in the face of subsequent + stanza modification.
+ +The an 'id' attribute is could be used (or possibly 'xml:id'), it may be appropriate for + the XMPP entity inserting a child element into a stanza to provide an 'xml:id' attribute + regardless of what stanza content it might sign.
+Multiple entities can sign a stanza. A single entity may sign a stanza multiple times, + typically on different occasions.
+ +Each signer simply adds their &SIGNATURE; element to the stanza, typically as the last + element. A &SIGNATURE; may sign other signatures, or portions thereof.
+ +While a simple chat &MESSAGE; typically transits through only one or two XMPP servers + and a groupchat &MESSAGE; may typically transits one to three XMPP servers, a stanza + might include far more than four &SIGNATURE; elements.
+One possible signing solution is for stanzas to carry alternative sets of content, an + unsigned content alternative and a signed content alternative. An entity supporting the + signing extension could make use of the signed content alternative while an entity not + supporting the signing extension could make use of the unsigned content alternative. The + following example not only illustrate this approach, but a significant issue with this + approach:
+Note that the &BODY; element values differ in the two alternatives.
+An attacker could alter the unsigned content without alerting entities making use the + signed content.
+Instead of treating the signed and unsigned content as alternatives, the solution could + limit use of the signed content to the validation of the unsigned data. However this + solution suffers from many same issues encapsulated signatures suffer from, as well as + suffering from unnecessary bloat.
+Dual content approaches should be avoided.
+While a signer may provide a &KEYINFO; element within the &SIGNATURE;, doing so + will significantly increase the size of the &SIGNATURE; element. As implementations may + enforce a maximum stanza size as small as 10,000 bytes, use of &KEYINFO; in stanza + signatures should be limited.
+It is also noted there are cases where the signer may not want to expose the key + information to all entities involved in the exchange of stanza.
+There are a number of ways key information may be published, such as in user's vCard. Key + information can also be provided at request, such as by &IQ;.
+Care must be taken in the design of not only ensure it provides an effective digital + signature solution for XMPP, but is designed itself with security in mind. This section + discussions some security issues in providing a digital signature solution. The design should + consider a general digital signature issues as well issues specific to the technologies + used/involved, and particulars of the solution.
+Due to the nature of XML and XMPP, an effective general digital signing solution for XMPP is + likely to be quite complex. This document suggests nothing less. With complexity comes + significant security risk. To minimize this risk, the solutions should avoid reinvention of + needed technology, such as signature and key information syntaxes, by reusing well established + and understood technologies such as XMLDSIG. Solutions should also favor simple and widely + used features of such technologies over esoteric or rarely used features
+Designers of the solution should be mind full of security considerations discussed in XMLDSIG + (regardless of whether XMLDSIG is used in the solution)
+If XMLDSIG is used, a number of security considerations would be introduced into the + solution. Implementations need to take special care in processing XMLDSIG &SIGNATURE; + elements to avoid a wide range of attacks. For instance, an attacker could attempt to mount a + Denial of Service attack by sending a &SIGNATURE; purporting to sign arbitrary large and + complex content. Or an attacker could attempt to mount a Distributed Denial of Service sending + a message to a chatroom that containing &SIGNATURE; with multiple references to large + content hosted at the attack target in hopes that each room participant will repeated fetch + it. A &SIGNATURE; element might also contain circler references.
+Proto-XEP draft.
+This document provides a technical specification for Digital Signatures in Extensible + Messaging and Presence Protocol (&xmpp;) based upon End-to-End Object Encryption + (&E2EEncrypt;) "work in progress".
+The S/MIME approach defined in &rfc3923; has never been implemented in XMPP clients to the + best of our knowledge, but has some attractive features, especially the ability to + store-and-forward a signed message at a user's server if the user is not online when the + message is received (in the XMPP community this is called "offline storage" and the message is + referred to as an "offline message"). The authors surmise that RFC 3923 has not been + implemented mainly because it adds several new dependencies to XMPP clients, especially MIME + (along with the CPIM and MSGFMT media types). This document explores the possibility of an + approach that is similar to but simpler than RFC 3923.
+The process that a sending agent follows for securing stanzas is very similar regardless of + the form of stanza (i.e., <iq/>, <message/>, or <presence/>).
+The sender begins with the cleartext version of the <message/> stanza "S":
+The sender then performs the steps 1 through 4 from above to generate:
+And then performs steps 5 through 9 steps, causing the following to be sent:
+To be added....
+The following limitations and caveats apply:
+ +Several scenarios are possible when an entity receives an encrypted stanza:
+ +In Case #1, the receiving application MUST do one and only one of the following: (1) ignore + the <signed/> extension, (2) ignore the entire stanza, or (3), except where precluded by + the protocol (&rfc3920bis;), return a <service-unavailable/> error to the sender.
+In Case #2, the receiving application MUST NOT return a stanza error to the sender, since + this is the success case.
+In Case #3, the receiving application MAY, except where precluded by the protocol, return a + <not-acceptable/> error to the sender, optionally supplemented by an + application-specific error condition element of <bad-timestamp/> as shown below:
+In Case #4, the receiving application SHOULD, except as precluded by the protocol, return a + <bad-request/> error to the sender, optionally supplemented by an application-specific + error condition element of <bad-signature/> as shown below:
+Additionally in Case #4, the receiving application SHOULD NOT present the stanza to the + intended recipient (human or application) and SHOULD provide some explicit alternate + processing of the stanza (which may be to display a message informing the recipient that it + has received a stanza that cannot be verified).
+Timestamps are included to help prevent replay attacks. All timestamps MUST conform to + &DATETIME; and be presented as UTC with no offset, always including the seconds and fractions + of a second to three digits (resulting in a datetime 24 characters in length). Absent a local + adjustment to the sending agent's perceived time or the underlying clock time, the sending + agent MUST ensure that the timestamps it sends to the receiver increase monotonically (if + necessary by incrementing the seconds fraction in the timestamp if the clock returns the same + time for multiple requests). The following rules apply to the receiving application:
+ +The foregoing timestamp checks assume that the recipient is online when the message is + received. However, if the recipient is offline then the server will probably store the message + for delivery when the recipient is next online (offline storage does not apply to <iq/> + or <presence/> stanzas, only <message/> stanzas). As described in &xep0160;, when + sending an offline message to the recipient, the server SHOULD include delayed delivery data + as specified in &xep0203; so that the recipient knows that this is an offline message and also + knows the original time of receipt at the server. In this case, the recipient SHOULD verify + that the timestamp received in the encrypted message is within five minutes of the time + stamped by the recipient's server in the <delay/> element.
+All implementations MUST support the following algorithms. Implementations MAY support other + algorithms as well.
+To participate in end-to-end signing using the methods defined in this document, a client + needs to possess an X.509 certificate. It is expected that many clients will generate their + own (self-signed) certificates rather than obtain a certificate issued by a certification + authority (CA). In any case the certificate MUST include an XMPP address that is represented + using the ASN.1 Object Identifier "id-on-xmppAddr" as specified in Section 5.1.1 of + RFC 3920bis.
+TBD.
+A URN sub-namespace of signed content for the Extensible Messaging and Presence Protocol + (XMPP) is defined as follows.
+This document borrows ideas and text from End-to-End Object Encryption "work in progress" by + Matthew Miller and Peter Saint-Andre.
+Changed service discovery feature to urn:xmpp:forwarding:0 in compliance with XMPP Registrar processes.
Specified that from address of forwarded stanza must be JID of forwarding address (not server).
Split forwarding semantics and forwarding request process into separate specifications; defined security considerations.
Added confirmation protocol flow.
First draft.
The concept of communications forwarding is familiar from email and, before that, from postal mail: communications sent to one address are automatically re-directed to another address. Such forwarding can help make communications smoother when, for instance, people or applications move to new locations. In postal mail systems, such functionality is usually implemented by the entity responsible for delivery of communications within the locality of the original address (e.g., a local post office), as initiated by the person or organization that requires the change of address. The model is similar in electronic mail systems, often implemented by means of a .forward file.
+This document specifies syntax and semantics for delivery of forwarding stanzas in XMPP systems. A companion document defines a method for setting up forwarding at a server.
+This proposal addresses the following requirements:
+Before stanzas can be forwarded, forwarding needs to be established from an old address to a new address. Methods for doing so are out of scope for this specification.
+Once forwarding is established, the server MUST redirect all stanzas sent to the old address (including any resource thereof) to the new address.
+Before the server forwards the stanza, it MUST add a NumForwards &xep0131; header to the stanza (whose character data is the number "1") if there is no such header already included in the stanza, or if the stanza already includes such a header it MUST increment the value of the NumForwards header by 1 and include the revised NumForwards header in the stanza. (Inclusion and incrementing of the NumForwards header helps to prevent infinite forwarding loops; see the Security Considerations.)
+In addition, the server MUST include 'oto' and 'ofrom' &xep0033; addresses so that the final recipient can determine the provenance of the stanza.
+Note: The 'oto' and 'ofrom' address types are not yet specified in the Extended Stanza Addressing specification; they will be added if this document advances to a status of Draft within the standards process of the &XSF;.
+If an entity supports the protocol specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:forwarding:1" in response to &xep0030; information requests &NSNOTE;.
+In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
+Deployment of stanza forwarding introduces the possibility of a denial of service attack if infinite loops occur; therefore, a server that implements stanza forwarding MUST also implement checking and incrementing of the NumForwards header. In particular, a server MUST be configured with a reasonable default limit for the maximum number of acceptable forwards (e.g., 10), which MAY be further configurable by the server administrator but which MUST NOT be removable (or changeable to an unreasonable value).
+This specification requires no interaction with &IANA;.
+The ®ISTRAR; shall include 'urn:xmpp:forwarding' in its registry of service discovery features.
+The XMPP Registrar shall include the following entry in its registry of SHIM headers.
+
+ NumForwards
+ The number of times a stanza has been forwarded (must be a positive integer).
+ XEP-xxxx
+
+ ]]>
+ Per Council feedback, moved server rosters to a separate specification.
Refactored XML format; added elements for sub-categories, locations, related incidents, solutions, and suggestions.
First draft.
As XMPP technologies have been deployed more widely, the open XMPP network has become a more significant target for attacks. This specification defines ways for XMPP server deployments to share information with each other and therefore handle such attacks in a more real-time fashion. In particular, it defines a format for sharing incident reports among XMPP server deployments. (For some related considerations, see &rfc2350;, &rfc3067;, and &rfc5070;.)
+An incident report consists of an XMPP &MESSAGE; stanza containing an <incident/> child element that includes an 'id' attribute whose value is a UUID as described in &rfc4122;. An example is shown below. A server deployment SHOULD send incident reports only to peer servers that it trusts, for example peers that are in its "server roster".
+The defined children of the <description/> element are as follows:
+| Element Name | +Description | +
|---|---|
| <discuss/> | +This element contains the JID of the server admin who generated the incident report (<admin/>), as well as a &xep0045; room where the incident can be discussed (<muc/>). | +
| <info/> | +Structured information about the incident. The defined values of the <category/> and <type/> elements shall be provided via a registry. It is envisioned that the <category/> values shall be "muc" for &xep0045; incidents, "pubsub" for &xep0060; incidents, "reg" for account registration (&xep0077;) incidents, and "stanzas" for general XMPP traffic incidents. | +
| <locs/> | +The place or places on the XMPP network where the incident has occurred (such as a multi-user chat room, a publish-subscribe service, or a general XMPP server), each contained in a separate <loc/> element. | +
| <rels/> | +The IDs of one or more incidents to which this incident might be related, each contained in a separate <rel/> element. | +
| <severity/> | +The seriousness of the problem, from 5 (least serious) to 1 (most serious). | +
| <source/> | +The IP address(es) and JabberID(s) where the incident originated. | +
| <text/> | +A natural-language description of the event. This element SHOULD possess an 'xml:lang' attribute. Multiple <text/> elements MAY be included, each with a different 'xml:lang' value. | +
| <time/> | +The time when the incident began and ended (include an empty <end/> element if the incident is still happening) and, optionally, was reported. The dates MUST conform to the DateTime profile specified in &xep0082; | +
If the reporting entity determines a solution to the problem, it MAY send out a revised incident report containing a <solution/> element.
+Further definition of the <solution/> element will be provided in a future version of this specification.
+If an entity that receives an incident report has a suggested solution to the problem, it MAY send an incident message containing a <suggestion/> element.
+Further definition of the <suggestion/> element will be provided in a future version of this specification.
+To follow.
+To follow.
+To follow.
+To follow.
+First draft.
+ Many modern instant messenger networks support playing games. + Still, XMPP mostly lacks this kind of support. + Therefore, this document describes a base protocol for game playing over XMPP. +
++ This protocol is not by itself sufficient to play games. + It just describes a basic protocol framework which game-specific protocols can use. +
++ This document addresses the functionality which is needed to play games over the XMPP. + In particular this functionality consists of: +
++ The following section describes the use cases associated with one-to-one instant gaming. + It is not supposed to provide professional gaming capabilites with independent move validation, spectators, etc. + Instead, it only supports two player games without spectators and no move validation. +
++ Despite the existence of Multi-User Gaming, Instant Gaming is considered important for making gaming over XMPP popular. + Rapid deployment of new two-player games is possible without waiting for server support or finding a suitable server. + +
+An implementation of Instant Gaming MUST support &xep0030;.
++ A Jabber entity may wish to discover if another entity implements the Instant Gaming protocol; + in order to do so, it sends a service discovery information ("disco#info") query to the other entity's full JID: +
++ The entity MUST return the features it supports. + Game protocols SHOULD include a &FEATURE; element with their namespace in the response, too. +
+ ++ In order to invite someone to a game, the initiator sends a message to her/his opponent containing an &INVITE; element, + which MUST specify the invitation type (see Table 1). +
++ Furthermore, a &GAME; element with a "var" attribute containing the namespace of the game protocol is REQUIRED. + It MAY also contain additional information which SHOULD then be specified using &xep0004;. + Such information might be used to state the rules or other slight variations for the particular game. + If an invitation with unsupported rules or options is received, + a ¬acceptable; error of type "modify" SHOULD be send to the inviting entity. +
++ The &THREAD; element MUST be present and it MUST contain a unique ID which identifies the current match. + The ID MAY for example consist of the initiator's and the opponent's (bare) JID, + the game name, the current datetime (which then SHOULD conform to the DateTime profile specified in &xep0082;) and + a random number, all separated by hyphens. + It is not supposed to get parsed and is only used to uniquely identify the game. +
+| Invitation Type | +Meaning | +
|---|---|
| new | +The game is totally new and contains no data of previous games. | +
| renew | +The game is over and shall be recreated from the beginning with the same match ID. | +
| adjourned | ++ This invitation is to resume an adjourned game. + It MUST only be send to the same opponent as from the beginning of the game and MUST contain the same game id. + Further information provides Game Loading + | +
| constructed | +This type states that the game will start with a state which is different from the state new games have. | +
+ An invitation of type "renew" SHOULD contain the same match ID and &GAME; element as the initial "new" invitation. + It MUST only be send when the previous match with the same match ID has been terminated. + If it is received earlier, an &unexpected; error SOULD be send to the sender of the premature invitation. + Game protocols SHOULD switch the beginning player and leave all other options the same. +
++ In the unlikely but possible event + that an invitation of type "renew" is received immediately after one has been send with the same match ID, + this invitation SHOULD be treated as if it were a &MESSAGE; with a &JOIN; element. + Invitations with match IDs that are already assigned to a running game SHOULD be ignored. +
+ ++ The opponent SHOULD NOT ignore the invitation. + If she/he does not want to play, the invitation SHOULD be declined. + In order to decline the invitation, the opponent MUST send a message of the following form to the initiator. +
++ In order to join a game, a &MESSAGE; stanza has to be send to the initiator's full JID. + The &MESSAGE; stanza MUST contain the ID of the match to which the opponent wants to join in the &THREAD; element. + Besides that, a &JOIN; element qualified by the namespace 'http://jabber.org/protocol/games' is REQUIRED + and the &BODY; element is OPTIONAL. +
+ ++ A successful join MUST be confirmed by sending the same message (with different sender and recipient) back to the opponent. +
++ The initiator might refuse the join by sending a &MESSAGE; stanza of 'type' "error". + It then MUST mirror the &THREAD; ID and the original &JOIN; child element. + The &ERROR; element MAY contain a &TEXT; element with a human-readable description of the error. +
++ A turn in a game is sent in a message (of type "chat") to the other player's full JID. + The &MESSAGE; stanza contains a &TURN; element which contains the element, representing the desired action (e.g. &MOVE;) qualified by the namespace of the particular game. + The action itself can be further described by attributes or child elements (see corresponding game protocol). +
++ A human-readable comment MAY be sent with the move in the &BODY; element of the &MESSAGE;. + In order to track the game to which the move belongs, the match ID is REQUIRED to be in the &THREAD; element. +
+A receipt for each message MAY be requested in accordance with &xep0184;.
++ While playing a game, it might be desirable to interrupt playing and resume it at a later time. + Games with complete knowledge can be saved at any time by each of the players without sending messages. + But the client of the saving player SHOULD inform the other player that the game was saved by sending the following message. +
+ +After receiving such an notification, an implementation MAY decide to save the game, too.
+ ++ When playing games with incomplete knowledge, + it is desirable that both players save the game at the same time in order to save a clean game state. + The game protocol MUST define whether its game has to be saved independently or mutually. +
+ ++ If a game needs to be saved mutually by both players, + one of the players requests the game to be saved by sending a message with a &SAVE; child element as follows. +
++ The recipient of the above message MUST confirm a successful saving process + using a &SAVED; element as above. +
++ To ensure that both players save the same game state, + the sender MUST NOT send any game moves until he receives confirmation from the other player and + the receiver MUST NOT send any game moves after receiving the request for saving until he has responded to it. +
++ If the sender of the saving request receives a game move before getting confirmation of a successful saving process, + she/he MUST NOT save the game and MUST send the following error message. +
++ If one of the player's client encounters an error during the saving process, it MUST send an error message, too. + This time it SHOULD NOT use a &conflict;, but an &undefined; error condition. +
++ An XMPP entity that wishes to resume a saved game has to send an invitation + of "type" 'adjourned' to the same opponent it began playing with. + It MAY also resume the game with another opponent, but then it MUST use the "type" 'constructed' and a new match ID. +
++ In case the game requires mutual saving by both players and the game was saved this way, + one of the players simply sends an invitation of "type" 'adjourned' with the match ID of the saved game to the other player. + After the invitee has successfully joined the game, it begins at the point where it was saved. +
++ If the game was only saved by one of the players, the inviting player MUST send the saved game state in the invitation. + This SHOULD be done by including an &X; element in the &MESSAGE; stanza of the 'jabber:x:data' namespace. + The exact representation of the game state is up to the game protocol, but SHOULD use &xep0004;. + E.g. the state MAY also be encoded in a history of game moves. +
++ The Tic Tac Toe game state information in this example is entirely fictional and only for demonstration purposes. +
++ An implementation MAY present the game in the saved state to the user along with the invitation. + It MAY also compare the state it received with the state it saved by its own and + inform the user about any mismatches. +
++ An implementation SHOULD send the following &MESSAGE; to end the game. + The "reason" attribute is always REQUIRED. +
+ ++ This &MESSAGE; SHOULD also be send by one of the players + before she/he changes her/his presence to unavailable, + though a different "reason" MAY be used. + For a list of possible reasons and their meaning see Table 2. +
++ In case one player changes her/his presence to unavailable without sending a termination message, + the other player might just wait or MAY save the game (if possible) and + send a termination message with reason 'adjourn'. +
++ A terminating &MESSAGE; with reason 'cheating' SHOULD be send, if an illegal move is received. + If one entity receives a terminating &MESSAGE; although it already send one by it's own, it MUST ignore it. +
+ +| Reason | +Meaning | +
|---|---|
| won | +The player sending the message has won the game. | +
| lost | +The player sending the message has lost the game. | +
| draw | +The game is over and nobody has won. | +
| resign | +The player sending the message capitulates and quits. | +
| adjourn | +The game is not over and might be resumed at a later time. | +
| cheating | +The player receiving the message has submitted an illegel game move. | +
Initiator -- an entity who started a game.
+Opponent -- in an One-to-One gaming context, the entity who was invited to play and did not start the game.
+Spectator -- an entity who does not actually plays the game but watches it.
+OPTIONAL.
+OPTIONAL.
+OPTIONAL.
+REQUIRED.
+REQUIRED.
+REQUIRED.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+&xep0166; defines a framework for negotiating and managing data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor application formats, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data exchanges between XMPP entities using the existing In-Band Bytestreams (IBB) protocol specified in &xep0047;. This "jingle-ibb" method results in a streaming transport method suitable for use in Jingle application types where packet loss cannot be tolerated (e.g., file transfer); however, because the "jingle-ibb" transport method sends data over the XMPP channel itself (albeit not the Jingle signalling channel), it is intended as a transport of last resort when other streaming transports cannot be negotiated.
+The approach taken in this specification is to use the existing IBB mechanisms described in XEP-0047 for transporting the data, and to define Jingle-specific methods only to start and end the in-band bytestream.
+|
+ | ack |
+ |<---------------------------|
+ | session-accept |
+ |<---------------------------|
+ | ack |
+ |--------------------------->|
+ | IBB "SESSION" |
+ |<==========================>|
+ | session-terminate |
+ |<---------------------------|
+ | ack |
+ |--------------------------->|
+ | |
+ ]]>
+ This flow is illustrated in the following examples (to prevent confusion these use a "stub" transport instead of a real application type).
+First the initiator sends a Jingle session-initiate request.
+Note: The Jingle IBB Transport Method defines one attribute in addition to those defined in XEP-0047: the 'stanza' attribute. This attribute specifies whether the initiator intends to send IBB data using &MESSAGE; or &IQ; stanzas, but is purely advisory. The default value is "iq", and it is RECOMMENDED to send IBB data using IQ stanzas instead of message stanzas because IQ stanzas provide feedback to the sender regarding delivery to the recipient (e.g., if the recipient is on a small pipe and cannot handle a large volume of IBB packets in quick succession).
+The responder immediately acknowledges receipt (but does not yet accept the session).
+If the offer is acceptable, the responder returns a Jingle session-accept and the initiator acknowledges the session-accept.
+The initiator then immediately begins sending IBB packets using an IQ-set for each chunk as described in XEP-0047, and the responder acknowledges each IQ-set.
+Once the parties have finished using the bytestream (e.g., because a complete file has been sent), either party can send a Jingle session-terminate action.
+The other party then acknowledges the session-terminate and the Jingle session is finished.
+The same processing rules and usage guidelines defined in XEP-0047 apply to the Jingle IBB Transport Method.
+The same security considerations defined in XEP-0047 apply to the Jingle IBB Transport Method.
+This document requires no interaction with &IANA;.
+This specification defines the following XML namespace:
+Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.
+The XMPP Registrar shall add to its registry of Jingle transport methods a definition for the "jingle-ibb" transport method. The registry submission is as follows:
+
+ ibb
+ A method for exchanging data over In-Band Bytestreams.
+ streaming
+ XEP-xxxx
+
+ ]]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+First draft.
++Jingle Nodes is an XMPP Based Relay Service providing standard UDP/TCP Relay, but negotiated via XMPP. +Jingle Relay Nodes are intend to provide easy to use Jingle Relay Type Candidates that can be used in ICE-UDP, RAW-UDP, TCP Jingle Sessions. +Relay Candidates can provide NAT Traversal for Jingle users with or without STUN/TURN Support. +The main benefits of Jingle Relay Nodes is the easy to use candidates, Jingle Clients can became a Node and Jingle Relay Nodes are published via XMPP, meaning every Client or Server can also act as a tracker of another Nodes.
+Jingle Relay Nodes MUST be binded directly to a Public IP address without firewall for traffic on the port range reserved to be used by relay candidates. This is the main and unique requirement for a peer provide Relay Nodes Service. +All signalling, request, response and publishing is done via XMPP, not requiring any extra stack or protocol in the Client or Server, for usage and discoveral of Nodes.
+| Term | +Definition | +
|---|---|
| Relay | +Relays are mainly used to transfer traffic to servers located on a NAT:ed (masqueraded) network, where the IP addresses on the NAT:ed network cannot be accessed from the outside. When you use an IP address that is for local use only, you must use NAT and relays because these IP addresses cannot be accessed in any other way. Relays can also be used for non-NAT:ed networks. | +
| Jingle Relay Node | +Is an instance of a Relay Service that is negotiable via XMPP, following the procedures described on this Extension. | +
| Tracker | +Is the entity that trackers Jingle Relay Nodes and also publishes the list upon request. Potentially all Jingle Clients might act as a Node Tracker. | +
| Channel | +Is the UDP/TCP Relay Channel, provided by the a Jingle Relay Node. The channel act as a NAT Traversal Channel in order to delivery and receive media. | +
| Requester | +Is the Jingle Client that makes requests and make use of a Channel. The Requester receives a relay Transport Candidate that can be used with Jingle ICE-UDP Transport Method or Jingle Raw UDP Transport Method. | +
In diagrams, the following conventions are used:
+After the Jingle Clients gets succesfully connected to the XMPP Server, it MAY want to start discoverying available Relay Services in order to cache some entries. Having cached Relay Service Addresses is recommended as it speeds up the session setup time as the Client don't need to search for available Relay Services right before a session is started or received.
+ +A Jingle Client MAY start the search for Relay Services by querying his own XMPP Server Domain.
++ Note: This is a good implementation practice. +
+A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on the known Tracker Services.
+A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on his Roster Items until find the desired amount of Relay Services, or while it does NOT exceed a search depth or ANY other Client implementation policy. The Client SHOULD keep a list of visited Tracker Services in order to avoid searching twice in same Service Entity.
+In this example 'juliet@capulet.lit/balcony' returned a Relay Service entry that is restricted to its roster. This Service is usable as the requester has 'juliet@capulet.lit/balcony' on its roster. Although, services with policy 'roster' MUST NOT be listed in Tracker Responses expects in Tracker Responses that comes from the Service Entity itself, in this case 'juliet@capulet.lit/balcony'.
+In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry. +A Jingle Client with direct access to a public IP can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...
++ Note: It is NOT mandatory to became a Jingle Relay Node it is OPTIONAL and SHOULD be done ONLY under user awareness and concentiment. +
+After receiving the &CHANNEL; the requester MUST send his stream to 'host' and 'localport' pair and send a &CANDIDATE; containing the 'host' and 'remoteport' values.
+A Relay Channel Service is responsible for providing the actual Relay Services. It will receive Channel Requests, allocate the Relay Channel and return the ready to use details. If a Jingle Client knows the service address of one valid and reliable Relay Service, that is enough for place and receive Jingle Calls and transmit both ways media streams based on UDP.
+Relay Channel Services support can be discovered by searching using Tracker Services. It can also be discovered by service discovery described in this document.
++ Note: Jingle Relay Channels can be used with RAW-UDP and ICE-UDP Jingle Transports. +
+A Tracker Service is responsible for providing addresses of known Relay Channel Services and other Tracker Services as well.
+Tracker entries MUST contain a 'type' attribute that represents the usage policy according to the table below:
+| Type | +Definition | +
|---|---|
| public | +Relays Services that are meant and opened for public usage, SHOULD use the type 'public'. Meaning that every user can make use of its services. This type SHOULD be published by Tracker Services. | +
| roster | +Relay Services that only provides Channels for users that are in it own roster, SHOULD use the type 'roster'. Meaning that only presence subscribed buddies can make use of its service. Common usage is XMPP Clients with Relay Services Capabilities. This type SHOULD NOT be published by Tracker Services as if it is roster only, the requester SHOULD have the entity already added to his roster, which also mean that it SHOULD be discoverable on roster level. | +
The &CHANNEL; element MUST be empty.
+The attributes of the &CHANNEL; element are as follows.
+| Attribute | +Definition | +Inclusion | +
|---|---|---|
| id | +A random candidate identifier generated by the Relay Service, which effectively maps to the created Channel; this SHOULD match the XML Nmtoken production |
+ REQUIRED on response, NOT RECOMMENDED on requests | +
| host | +The IP address or Host address of the Relay Channel. | +REQUIRED on response | +
| localport | +The port number to be used by the channel requester. | +REQUIRED on response | +
| remoteport | +The port number to be offered to the remote party. | +REQUIRED on response | +
| protocol | +The protocol supported by the retrieved channel. | +REQUIRED on response | +
| maxkbps | +The maximum bandwidth supported by the channel. | +OPTIONAL on response, NOT RECOMMENDED on requests. | +
| expire | +The maximum amount of seconds that the channel can stay without receiving packets, without being deactivated and closed. | +REQUIRED | +
The value of the 'host' attribute MUST be one IP address or a DNS resolvable address. That is the address to be used on candidate offering and also the IP to be used when sending out the media traffic.
+The value of the 'localport' attribute MUST be a valid IP Port number. This port MUST be used as the media traffic destination port of the channel requester. Session Initiator and responder MUST NOT offer this port.
+The rule is simple and unique, the requester of the channel MUST send the media streams to 'localport' and use 'remoteport' in the 'candidate' element to be offered in the Jingle Session.
+For transparent compatibility with major RTP Proxy Deployments, an RCTP Port is allocated and defined by default at Localport Attribute Value plus one. (Localport + 1)
+The value of the 'remoteport' attribute MUST be a valid IP Port number. This port MUST be used as media traffic destination port of the other party. Channel requester MUST use this port value in the candidate offer in combination with the 'host' attribute. Channel requester MUST NOT send any media stream to this port.
+For transparent compatibility with major RTP Proxy Deployments, an RCTP Port is allocated and defined by default at Remoteport Attribute Value plus one. (Localport + 1)
+The value of the 'protocol' attribute MUST be a valid protocol value: 'udp' or 'tcp' as also defined in the XML Schema
+The value of the 'maxkbps' attribute MUST be a valid integer value representing the maximum kilobits per seconds the channel supports. This attribute is optional and MAY be used in Relay Channel with bandwidth limitation.
+The value of the 'expire' attribute MUST be a valid integer value representing the maximum seconds that the channel can stay without receiving any traffic without being deactivated and closed. This attribute is required and SHOULD be used in all Relay Channels.
+The &SERVICES; element MAY be empty or contain &RELAY; and/or &TRACKER; elements.
+The attributes of the &RELAY; and &TRACKER; element are as follows.
+| Attribute | +Definition | +Inclusion | +
|---|---|---|
| policy | +The policy of the service. If the service is public, MUST be 'public' if it is restricted to roster, MUST be 'roster'. | +REQUIRED | +
| address | +The IP address or Host address of the Relay Channel. | +REQUIRED | +
| protocol | +The protocol supported by the retrieved service. | +REQUIRED | +
To advertise its support for the Jingle Nodes support, when replying to &xep0030; information requests an entity MUST return URNs for any version of this protocol that the entity supports -- e.g., "http://jabber.org/protocol/jinglenodes" for this version&VNOTE;.
+If the entity supports, Jingle Nodes as a Tracker, it MUST reply to &xep0030; with "http://jabber.org/protocol/jinglenodes". If it also provides the Jingle Nodes Relay Services, it MUST reply with the URN "http://jabber.org/protocol/jinglenodes#channel".
+For optimization purpose the Client SHOULD check for Jingle Nodes support based on entity presence capabilities &xep0115;, which SHOULD contain the keywork "jn-v0".
+In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
+A Jingle Client with only RAW-UDP support and any NAT detection mechanism can make use of Jingle Nodes. Although the traversal is not guarantee due problem with NAT configuration or firewalls, this method is fairly efficient as most SIP legacy services still provides their services in a similar way, meaning that this has the exactly same accertivity and reliability than regular SIP Services. This method is extremelly useful specially for simple platforms like mobile and clients in early stage of development that still wants to offer voice and video support.
++ Note: This use case is also similar to a Jingle to SIP Interoperability Service. +
+A Jingle Client with STUN support but no TURN support can use Relay Node Services as the fallback candidate instead of a TURN candidate. For instance, after a connectivity check proccess, none of the direct candidates worked. The Client can use the Relay Node Candidate as the fallback candidate(the lowest priority candidate).
+A Jingle Client with STUN and TURN support still might need a Relay Candidate, specially as TURN servers are not widely deployed and don't have any mechanism to publish available services for users. TURN servers also requires specific UDP traffic in specific port ranges which can be blocked by users networks. In this case is very useful to have an extra fallback candidate that can be negotiated via XMPP rather than over UDP.
++ Note: Jingle Relay Nodes Services are much more likely to be found and be available than TURN servers, as users can also provide Jingle Relay Nodes services themselves or provide a list of known and available services, in this last case behaving a tracker. Is very likely that Jingle Relay Nodes will be available and discovered more easily and often than TURN servers. +
+A XMPP Client or Component with direct access to a public IP can potentially provide the UDP Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...
++ Note: It is NOT mandatory to became a Jingle Relay Node. This is OPTIONAL and SHOULD be done with user awareness and concentiment. +
+When using a candidate provided by a Jingle Relay Service, the Jingle Client MUST set the candidate attribute to 'relay'. In order to make sure the other client won't allocate another channel as well. Which would lead in audio connectivity issues. In brief, if the caller is using a Relay Candidate the calle MUST NOT use another Relay Candidate discovered by itself. If a caller is not using a Relay Candidate(which can be determined by the candidate 'type' attribute) the callee MAY use a Relay Candidate in order to ensure communication.
+Relay Channels auto expires MUST expire on traffic inactivity. The inactivity timeout recommended is 60 seconds.
+It is heavily recommended that the Super Node implements throttle:
++
+
+
+
+
+
+
+
+ The protocol documented by this schema is defined in
+ XEP-0177: http://www.xmpp.org/extensions/xep-0177.html
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+Clarified status of H.264.
Rewrote document based on developer feedback and Council discussion.
Added more information about video codecs.
First draft, copied from XEP-0167 with slight revisions and addition of requirements section.
&xep0167; defines the &xep0166; signalling exchanges needed to establish voice and video chat using the Real-time Transport Protocol &rfc3550;; however, it does not discuss the matter of voice and video codecs, since the state of codec technologies is more fluid than the signalling interactions. This document fills that gap by providing guidance to Jingle developers regarding voice and video codecs.
+Because codec technologies are typically subject to patents, the topics discussed here are controversial. This document attempts to steer a middle path between (1) specifying mandatory-to-implement technologies that realistically will not be implemented and deployed and (2) providing guidelines that, while realistic, do not encourage the implementation and deployment of patent-clear technologies.
+Please note that this document is strictly informational and does not (yet) provide binding recommendations to the XMPP developer community regarding mandatory-to-implement technologies; however, it is expected that this document will provide input that the &XSF; could use in making such recommendations. Furthermore, it is expected that any recommendations that might be made by the XSF would need to be modified over time as the technology landscape changes.
+The ideal codec would meet the following criteria:
+Unfortunately, not all codecs are ideal. In the next section we discuss the audio and video codecs that are most attractive for implementation in Jingle RTP applications.
+Note: In general, audio codecs are more mature than video codecs. As a result, there are more patent-clear options for audio than for video. Although most XMPP developers would prefer to implement codecs that are patent-clear (both for ethical reasons and to produce free or at least affordable software), such options are not always widely implemented and deployed. This document takes these factors into account.
+According to the speex.org website, the Speex codec is "an Open Source/Free Software patent-free audio compression format designed for speech". Speex was developed by Jean-Marc Valin and is maintained by the Xiph.org Foundation. The following table summarizes the available information about Speex.
+| Quality | +Packetization | +Availability | +Patents | +
|---|---|---|---|
| Good quality; optimized for voice; can be used for wide-band audio. | +See &rtpspeex;. | +Freely downloadable under a revised BSD license at <http://speex.org/> and commonly deployed on Internet (VoIP) systems; not commonly deployed on non-Internet systems. | +Designed to be patent-clear. | +
G.711 refers to the Pulse Code Modulation (PCM) codec defined in &ITU; recommendation G.711, which is widely used on the public switched telephone network (PSTN) and by many voice over Internet Protocol (VoIP) providers. There are two versions: the μ-law ("U-law") version is widely deployed in North America and in Japan and the A-law version is widely deployed in the rest of the world. The following table summarizes the available information about G.711.
+| Quality | +Packetization | +Availability | +Patents | +
|---|---|---|---|
| Good quality; no wide-band mode. | +See &rfc5391;. | +Commonly deployed in both PSTN and VoIP systems. | +Developed in 1972; patents have expired. | +
According to the theora.org website, the Theora codec is "a free and open video compression format". Theora is based on the VP3 codec originally developed by On2 Technologies and is now maintained by the Xiph.org Foundation. The following table summarizes the available information about Theora.
+| Quality | +Packetization | +Availability | +Patents | +
|---|---|---|---|
| Acceptable quality. | +See &rtptheora;. | +Freely downloadable under a revised BSD license at <http://theora.org/>; not yet commonly deployed, especially on devices that have deployed H.264 instead. | +On2's patents over VP3 were contributed to the Xiph.org Foundation in 2001. | +
H.264 is a technology for video compression jointly designed by the ITU and the &ISO;. The following table summarizes the available information about H.264.
+| Quality | +Packetization | +Availability | +Patents | +
|---|---|---|---|
| High quality. | +See &rfc3984;. | +Commonly deployed in commercial video systems. Not freely downloadable; both software implementations and service deployments can be subject to royalty payments for commercial use. | +Patented. | +
Given that both Speex and G.711 are patent-clear, freely implementable, and commonly deployed, this document suggests that implementors strongly consider including support for both codecs in audio applications of Jingle RTP sessions.
+The situation regarding video codecs is more murky, and implementors face difficult tradeoffs. While Theora is patent-clear and freely implementable, it is not yet commonly deployed. On the other hand, deployment of H.264 is fairly common, but it is not patent-clear or freely implementable. For many open-source / free software projects and smaller technology vendors, implementation of H.264 is either impossible (because of patents and licensing restrictions) or prohibitively expensive (because of royalty payments). These developers are strongly encouraged to implement Theora and also to urge wider adoption of Theora among larger technology vendors. However, this document acknowledges that it may take some time before Theora is commonly deployed (especially on mobile devices) and that systems based on H.264 might be dominant in the marketplace for several years. This situation is unfortunate but cannot be directly changed by the XMPP developer community.
+This document suggests that both Speex and G.711 could be recommended as mandatory-to-implement technologies for audio codecs, should the XSF decide to make such recommendations.
+This document suggests that at this time it is not possible for the XSF to recommend a mandatory-to-implement technology for video codecs, but that it might be possible for the XSF to recommend Theora in the future if Theora is more widely adopted.
+For security considerations related to Jingle RTP sessions, refer to XEP-0167. This document introduces no new security considerations. See also the security considerations sections of the relevant codec specifications.
+This document requires no interaction with &IANA;.
+This document requires no interaction with the ®ISTRAR;.
+Thanks to Olivier Crête, Dave Cridland, Justin Karneges, Tobias Markmann, Jack Moffitt, Jeff Muller, Arc Riley, Kevin Smith, Justin Uberti, and Paul Witty for their feedback.
+Added more information about video codecs.
First draft, copied from XEP-0167 with slight revisions and addition of requirements section.
&xep0167; defines the &xep0166; signalling exchanges needed to establish voice and video chat using the Real-time Transport Protocol &rfc3550;; however, it does not specify the recommended voice and video codecs, since the state of codec technologies is more fluid than the signalling interactions. This specification defines the recommended codecs for the sake of interoperability between Jingle voice and video applications.
+The following requirements apply to codec recommendations.
+The Speex codec is an open source / free software, patent-free, audio compression format for the encoding of human speech; it is developed and maintained by xiph.org. The following table summarizes the available information about Speex.
+| Quality | +RTP Packetization | +Availability | +Patent Encumbrance | +
|---|---|---|---|
| Good quality; optimized for voice; can be used for wide-band audio. | +See &rtpspeex;. | +Widely available and freely downloadable under a revised BSD license at <http://speex.org/>. | +Designed to be patent-free. | +
G.711 refers to the Pulse Code Modulation (PCM) codec defined in &ITU; recommendation G.711, which is widely used on the public switched telephone network (PSTN) and by many voice over Internet Protocol (VoIP) providers. There are two versions: the μ-law ("U-law") version is widely deployed in North America and in Japan and the A-law version is widely deployed in the rest of the world. The following table summarizes the available information about G.711.
+| Quality | +RTP Packetization | +Availability | +Patent Encumbrance | +
|---|---|---|---|
| Good quality; no wide-band mode. | +See &rfc5391;. | +Widely supported in PSTN and VoIP systems. | +Developed in 1972; patents have expired. | +
The Theora codec is an open source / free software, patent-free, video compression format developed and maintained by xiph.org. The following table summarizes the available information about Theora.
+| Quality | +RTP Packetization | +Availability | +Patent Encumbrance | +
|---|---|---|---|
| Unknown. | +See &rtptheora;. | +Widely available and freely downloadable under a revised BSD license at <http://theora.org/>. | +Designed to be patent-free. | +
H.264 is a technology for video compression jointly designed by the ITU and the &ISO;. The following table summarizes the available information about Theora.
+| Quality | +RTP Packetization | +Availability | +Patent Encumbrance | +
|---|---|---|---|
| Unknown. | +See &rfc3984;. | +Unknown. | +Patented. | +
For security considerations, refer to XEP-0167.
+This document requires no interaction with &IANA;.
+This document requires no interaction with the ®ISTRAR;.
+Thanks to Olivier Crête, Dave Cridland, Justin Karneges, Tobias Markmann, Jeff Muller, Arc Riley, Kevin Smith, Justin Uberti, and Paul Witty for their feedback.
+Clarified order of events to be consistent with raw-udp and ice-udp.
Add additional text to use NAT assisting protocols and allow the responder to also send <streamhost/> information. This change required the introduction of streamhost-used and streamhost-error.
Rough draft.
&xep0166; defines a framework for negotiating and managing data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor application formats, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data exchanges between XMPP entities using the existing SOCKS5 Bytestreams (S5B) protocol specified in &xep0065;. This "jingle-s5b" method results in a streaming transport method suitable for use in Jingle application types where packet loss cannot be tolerated (e.g., file transfer).
+It is RECOMMENDED that a client offers as much <streamhost/> elements with itself as StreamHost as possible. This includes opening the TCP port on all available interfaces the user wants to use (e.g. maybe not an expensive UMTS link), both the IPv4 and IPv6 of that interface (if available), and using an assisting NAT protocol if possible. If the client knows it is behind and the router announces UPnP IGD or NAT-PMP support, the client SHOULD map the open port to the external interface of the router and include the public IP address and port information in the <streamhost/> offers. To increase the chance of success without using a proxy, this specification allows the responder to also send offers.
+|
+ | ack |
+ |<---------------------------------|
+ | session-accept |
+ | (with S5B info) |
+ |<---------------------------------|
+ | ack |
+ |--------------------------------->|
+ | streamhost transport-info |
+ |<---------------------------------|
+ | ack |
+ |--------------------------------->|
+ | streamhost-used transport-info |
+ |--------------------------------->|
+ | ack |
+ |<---------------------------------|
+ | S5B "SESSION" |
+ |<================================>|
+ | session-terminate |
+ |<---------------------------------|
+ | ack |
+ |--------------------------------->|
+ | |
+ ]]>
+ This flow is illustrated in the following examples (to prevent confusion these use a "stub" transport instead of a real application type).
+First the initiator sends a Jingle session-initiate request that contains one or more transport candidates, which in jingle-s5b are XEP-0065 streamhosts.
+The responder immediately acknowledges receipt.
+Depending on the application type, a user agent controlled by a human user might need to wait for the user to affirm a desire to proceed with the session before continuing. When the user agent has received such affirmation (or if the user agent can automatically proceed for any reason, e.g. because no human intervention is expected or because a human user has configured the user agent to automatically accept sessions with a given entity), it returns a Jingle session-accept message. This message MUST contain a &TRANSPORT; element qualified by the 'urn:xmpp:jingle:transports:s5b:0' namespace, which SHOULD in turn contain one <streamhost/> element for each SOCKS5 Bytestreams candidate generated by or known to the responder, but MAY instead be empty if the responder does not wish to offer any streamhosts or wishes to send each candidate as the payload of a transport-info message.
+Note: If the responder sends streamhost candidates, the chances of a successful connection are increased. For example, the initiator might be behind a NAT or might have no access to a proxy, whereas the responder might have a public IP address, might know about a streamhost proxy, or might have NAT penetration support like NAT-PMP in the router.
+In the following example, Juliet's client is the StreamHost and opens one port. The provided <streamhost/> elements are the (private) IPv4 address of the interface, a (public) IPv6 address, and the public IPv4 address created by mapping the private IP address/port using NAT-PMP.
+The initiator acknowledges receipt and tries to connect to the offered StreamHosts.
+Once one client has successfully created a connection with a StreamHost, it sends the <streamhost-used/> element defined in XEP-0065 to the peer; as a result, both clients will stop trying to connect to other candidates.
The peer immediately acknowledges receipt.
+The initiator can then immediately begin sending data over the SOCKS5 bytestream as described in XEP-0065 (in fact the streamhost is bidirectional, so the responder can use it as well).
+Once the parties have finished using the bytestream (e.g., because a complete file has been sent), either party can send a Jingle session-terminate action.
+The other party then acknowledges the session-terminate and the Jingle session is finished.
+The session flow is as follows.
+|
+ | ack |
+ |<---------------------------------|
+ | session-accept |
+ | (with S5B info) |
+ |<---------------------------------|
+ | [ SOCKS5 failure! ] |
+ |x--------------------------------x|
+ | transport-replace (IBB) |
+ |--------------------------------->|
+ | ack |
+ |<---------------------------------|
+ | IBB "SESSION" |
+ |=================================>|
+ | terminate |
+ |<---------------------------------|
+ | ack |
+ |--------------------------------->|
+ | |
+ ]]>
+ The protocol flow is as follows.
+First the initiator sends a Jingle session-initiate, in this case with a transport of SOCKS5 Bytestreams.
+The responder acknowledges receipt of the session-initiate and sends a session-accept.
+The initiator acknowledges receipt and tries to connect to the offered StreamHosts.
+If initiator or responder is unable to connect to any of the StreamHosts, it MUST send a <streamhost-error/> transport-info to the peer.
+The peer immediately acknowledges receipt.
+If the initiator receives such an error message from the responder and was also unable to connect to any StreamHosts (or did not receive any from the responder), it MUST either terminate the Jingle session with a Jingle reason of <connectivity-error/> or replace the transport by something else using the transport-replace action. Typically the fallback option is &xep0047;. Therefore the initiator sends a transport-replace action including a transport of IBB.
+The responder then acknowledges the transport-replace action.
+If the transport replacement is acceptable, the responder then sends a transport-accept action to the initiator (if not, the responder sends a transport-reject action).
+The initiator acknowledges the Jingle transport-accept action.
+Now the initiator sends data using In-Band Bytestreams as defined in XEP-0047.
+The same processing rules and usage guidelines defined in XEP-0065 apply to the Jingle S5B Transport Method. Additional implementation suggestions are:
+The same security considerations defined in XEP-0065 apply to the Jingle S5B Transport Method.
+This document requires no interaction with &IANA;.
+The XMPP Registrar shall add to its registry of Jingle transport methods a definition for the "jingle-s5b" transport method. The registry submission is as follows:
+
+ s5b
+ A method for exchanging data over SOCKS5 Bytestreams.
+ streaming
+ XEP-xxxx
+
+ ]]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+Improved the documentation about exchanging passwords and certificates.
Simplified the syntax; added sections on requirements and approach; more clearly specified methods of bootstrapping trust on the first communication session.
Clarified order of events to be consistent with jingle-s5b; used TLS-SRP for password based authentication; added some documentation about password authentication in general.
First draft, based on previous attempts for end-to-end security.
End-to-end encryption of traffic sent over the Extensible Messaging and Presence Protocol (XMPP) is a desirable goal. The Jabber/XMPP developer community has experimented with several such technologies, including OpenPGP (&xep0027;), S/MIME (&rfc3923;), and encrypted sessions or "ESessions" (&xep0218;). For various reasons, these technologies have not been widely implemented and deployed. When the &XSF; asked various Internet security experts to complete a security review of encrypted sessions, it was recommended to explore the possibility of instead using the Transport Layer Security (TLS; see &rfc4346;) as the base technology for XMPP. That possibility is explored in this document.
+TLS is the most widely implemented protocol for securing network traffic. In addition to applications in the email infrastructure, the World Wide Web (HTTP Over TLS; see &rfc2818;), and datagram transport for multimedia session negotiation (DTLS; see &rfc4347;), TLS is used in XMPP to secure TCP connections from client to server and from server to server, as specified in &xmppcore;. Therefore TLS is already familiar to XMPP developers.
+This specification, called "XTLS", defines a method whereby any &xep0166; application can use TLS semantics for end-to-end encryption, whether the application data is sent over a streaming transport (like TCP) or a datagram transport (like UDP). The most common use case is to tunnel XMPP stanzas between two clients for end-to-end secure chat with &xep0247;. However, XTLS is not limited to client-to-client encryption, since it can be used between two XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream, such as a &xep0045; chatroom), or between two remote XMPP services. Furthermore, XTLS can be used for encrypted file transfer (see &xep0234;), for encrypted voice or video sessions using &xep0167; and &dtlssrtp;, and other applications.
+Note: This specification is a work in progress and does not yet define all uses of XTLS.
+This specification is intended to meet the requirements defined in &xep0210; using building blocks that are already widely supported in XMPP clients, such as TLS, Jingle, and &xep0047;. It is possible that some of those requirements can be met only with particular TLS cipher suites, or cannot be met at all without defining extensions to TLS itself. A full gap analysis has not yet been completed.
+In broad outline, XTLS takes the following approach to end-to-end encryption of XMPP traffic:
+We assume that all XMPP entities will have X.509 certificates, typically self-signed and automatically generated by an XMPP client (although CA-issued certificates are acceptable).
We use the XMPP Jingle extensions as the negotiation framework.
We define a <security/> element that can be included in any Jingle negotiation, and a new "security-info" Jingle action for sending security-related information.
When an entity wishes to encrypt its communications with a second entity, it sends a Jingle session-initiate request that specifies the desired application type (e.g., file transfer), a possible transport (e.g., SOCKS5 bytestreams), and security information such as the sender's X.509 fingerprint and supported TLS methods (e.g., secure remote password).
If both parties support XTLS, the first data sent over the negotiated transport is TLS handshake data, not application data. Once the TLS handshake has finished, the parties can then send application data over the now-encrypted transport.
The simplest scenario is end-to-end encryption of traditional XMPP text chat using end-to-end XML streams, in-band bytestreams, and previously-accepted X.509 certificates.
On first use of end-to-end encryption between two entities, it is encouraged to use secure remote passwords rather than leap-of-faith to bootstrap the subsequent use of the client-generated X.509 certificates.
More complex scenarios are theoretically supported (e.g., encrypted file transfer using SOCKS5 bytestreams and encrypted voice chat using DTLS-SRTP) but have not yet been fully defined.
XTLS theoretically can be used to establish a TLS-encrypted streaming transport or a DTLS-encrypted datagram transport, but integration with DTLS (&rfc4347;) has not yet been prototyped so use with streaming transports is the more stable scenario.
We expand on this approach in the following section.
+The basic flow for an XTLS session is as follows, where traffic represented by single dashes (---) is sent over the XMPP signalling channel and traffic represented by double lines (===) is sent over the negotiated transport.
+|
+ | ack |
+ |<---------------------------|
+ | session-accept |
+ |<---------------------------|
+ | ack |
+ |--------------------------->|
+ | open transport |
+ |<==========================>|
+ | TLS ClientHello |
+ |===========================>|
+ | TLS ServerHello, [...] |
+ |<===========================|
+ | TLS [...], Finished |
+ |===========================>|
+ | TLS [...], Finished |
+ |<===========================|
+ | application data |
+ |<==========================>|
+ | session-terminate |
+ |<---------------------------|
+ | ack |
+ |--------------------------->|
+ | |
+ ]]>
+ To simplify the description we assume here that the parties already trust each other's certificates. See the next section for information about bootstrapping of certificate trust on the first communication.
+First the initiator sends a Jingle session-initiate request (here the simple case of an end-to-end text chat session using the &xep0261;). This request includes a <security/> element that contains the fingerprint of the certificate that the initiator will use during the TLS negotiation.
+The responder immediately acknowledges receipt of the session-initiate.
+Depending on the application type, a user agent controlled by a human user might need to wait for the user to affirm a desire to proceed with the session before continuing. When the user agent has received such affirmation (or if the user agent can automatically proceed for any reason, e.g. because no human intervention is expected or because a human user has configured the user agent to automatically accept sessions with a given entity), it returns a Jingle session-accept message. This message will typically contain the offered application type, transport method, and a <security/> element that includes the fingerprint of the responder's X.509 certificate as well as the responder's supported TLS methods.
+The following rules apply to the responder's handling of the session-initiate message:
+If the responder does not support Jingle-XTLS it will silently ignore the <security/> element in the offer and therefore will return a session-accept message without a <security/> element.
If the responder supports Jingle-XTLS it SHOULD return a session-accept message that contains a <security/> element.
If the responder thinks it will be able to verify the initiator's certificate, it MUST include the fingerprint for the responder's certificate in the <security/> element of the session-accept message. This is the "happy path" and will occur when the parties have already verified each other's certificates.
If the responder thinks it will not be able to verify the initiator's certificate, it MAY omit the fingerprint for the responder's certificate in the <security/> element of the session-accept message. This indicates that certificate-based authentication is not possible. In this case the responder SHOULD signal that it wishes to use some other authentication method, such as secure remote passwords (see the next section).
If the responding client cannot verify the initiator's certificate, it SHOULD ask the responding user if a password was exchanged between the parties that can be used for TLS-SRP. If this is not the case, setting up a mutually-authenticated link will fail and the responder MAY terminate the session. Alternatively it could send its own fingerprint knowing it cannot authenticate the initiator, in which case the responder has to trust that there is no man-in-the-middle (see next section).
When the responder sends the session-accept message, the initiator acknowledges receipt.
+The following rules apply to the initiator's handling of the session-accept message:
+If the initiator receives a session-accept without a <security/> element, setting up a secure transport layer has failed. The initiator MAY terminate the session at this point or instead proceed without securing the transport. The client SHOULD ask the initiating user how to processed. This depends on the Jingle application and the initiator's preferences: it makes no sense to use end-to-end XML streams without encryption, but the initiator might continue a file transfer without encryption.
If the initiating client cannot verify the responder's certificate it SHOULD ask the initiating user if a password was exchanged between the parties that can be used for TLS-SRP. If this is not the case, setting up a mutually-authenticated link will fail and the responder MAY terminate the session or proceed with leap-of-faith (see next section).
The initiator can now determine if X.509 certificate based authentication will work or if TLS-SRP will be used. It sends an additional security-info message to the responder to signal its choice. This step is not really necessary because the responder will see the initiator's choice in the first message of the TLS handshake, but it can help an implementation to set up its TLS library properly. Because in this section we assume that the parties already have validated each other's certificates, the security method signalled here is "x509".
+The responder acknowledges receipt.
+Parallel to the security-info exchange the clients set up a transport for the Jingle session. This example uses &xep0261; which does not require any additional messages (other transport like &xep0260; and &xep0176;) need more time to set up). Each transport MUST define a specific time when both cients know that the transport is ready. When XTLS is not used, the Jingle implementation would signal to the using application that the transport is open when the session-accept is sent or received, or when connectivity checks determine media can flow over one of the transport candidates. When XTLS is used, the Jingle implementation starts a TLS handshake on the transport and signals to the using application that the transport is open only after the four-way TLS handshake is finished successfully.
+During the TLS handshake, the responder MUST take the role of the TLS server and the initiator MUST take the role of the TLS client. During the handshake, the responder (acting as the TLS server) MUST send a CertificateRequest.
+If either client cannot verify the certificate of the peer or receives an invalid message on the TLS layer, it shall terminate the Jingle session immediately, including a Jingle reason of <security-error/>.
+The other party then acknowledges the session-terminate and the Jingle session is finished.
+If the TLS negotiation succeeds, then the Jingle implementation shall signal to the using application that the transport is open. The parties can then exchange application data over the encrypted transport.
+When two parties first attempt to use XTLS, their certificates might not be accepted (e.g., because they are self-signed or issued by unknown certification authorities). Therefore each party needs to accept the other's certificate for use in future communication sessions. There are several ways to do so:
+Leap of faith. The recipient can hope that there is no man-in-the-middle during the first communication session. If the certificate does not change in future sessions, the recipient at least knows that it is talking with the same entity it talked with during the first session. However, that entity might be a man-in-the-middle rather than the assumed communication partner. Therefore, leap of faith is discouraged.
Check fingerprints. The parties could validate the certificate fingerprints via some trusted means outside the XMPP band, such as in person, via encrypted email, or over the phone. This is not user-friendly because certificate fingerprints consist of long strings of letters and numbers. As a result, few humans check certificate fingerprints in protocols such as Secure Shell.
One-time password. The parties can exchange a user-friendly password known only to themselves and verify it out of band before the TLS handshake finishes. For this purpose, it is REQUIRED for implementations to support at least one TLS cipher that uses Secure Remote Password (SRP) as defined in &rfc5054;.
Channel binding. It is possible that a future version will describe how to use an appropriate Simple Authentication and Security Layer (SASL) mechanism, such as &scram;, to authenticate the XTLS channel after the TLS handshake finishes using the concept of channel bindings (see &rfc5056;).
If the parties use a password or channel binding via SASL, the process needs to be completed only once. After the clients have authenticated with the shared secret, they can exchange their certificates for future communication.
+To retrieve the certificate of the peer for future communications, a client SHOULD request the certificate according to XEP-0189 over the secure connection. This only works if XTLS was used to set up an end-to-end secure XML stream defined in XEP-0247; exchanging certificates if XTLS was used for other purposes like file transfer is not possible. A client MUST NOT request the certificate over the insecure stream based on the connection to the XMPP server.
+The peer MUST return its own client certificate. If the user has different clients with different client certificates and one user certificate, the user certificate SHOULD also be returned. The user certificate allows it to verify other client certificates using public key retrieval described in XEP-0189.
+If one of the parties is a "bot" (e.g., an automated service or a device such as a set-top box), the password exchange is a bit more complicated. It is similar to Bluetooth peering if the user has access to both clients at the same time. One of the following scenarios might apply:
+The bot can be controlled via a remote control input device. The human user can enter the same password or "PIN" on both the bot and the XMPP client.
If the bot has no user input but does have a small display, it could display a random password. The human user can then enter the provided password on the XMPP client.
The bot might have not enough buttons for input and has no output device. In that case the password is fixed. Similar to Bluetooth peering with simple devices such as a headset, the password will be written in the manual or printed on the device. For security reasons the device SHOULD NOT use password-based authentication without any user input. Many Bluetooth devices have at least one button to set the device into peering mode.
A bot may be associated with a web service and could display a random password when the user has logged in to the web site using HTTPS. This assumes that an attacker does not have control over the web server and can perform a man-in-the-middle attack on XMPP level at the same time. If the web service knows the GPG-key of the user (e.g. launchpad) it could send an encrypted email.
A user might have different X.509 certificates for each device. &xep0189; can be used to manage the user's certificates. A client SHOULD check the peer's PubSub node for certificates. This makes it possible to use the password method only once between two users even if one or both users switch clients. This makes it also possible for a user to communicate with a friend's bots. They first open a secure link between two chat clients with a password and exchange the user certificates. After that each user can verify all devices of the other without the need of a password.
+The retrieved certificate from the PubSub node may be signed by a CA the client can verify. In that case the client MAY skip the password authentication and rely on the X.509 certificate chain. The client SHOULD ask the user if the certificate should be accepted or if a password exchange is desired.
+If an entity wishes to request the use of XTLS, it SHOULD first determine whether the intended responder supports the protocol. This can be done directly via &xep0030; or indirectly via &xep0115;.
+If an entity supports XTLS, it MUST report that by including a service discovery feature of "urn:xmpp:jingle:security:xtls:0" in response to disco#info requests &NSNOTE;.
+Both service discovery and entity capabilities information could be corrupted or intercepted; for details, see the Denial of Service section of this document.
+This entire document addresses security. Particular security-related issues are discussed in the following sections.
+An implementation MUST at a minimum support the "srp" and "x509" methods. A future version of this specification will document mandatory-to-implement TLS ciphers.
+As noted, XTLS can be used between XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream), or between remote XMPP services. Therefore, a party to an XTLS bytestream will present either a client certificate or a server certificate as appropriate. Such certificates MUST be generated and validated in accordance with the certificate guidelines guidelines provided in &rfc3920bis;.
+A future version of this specification might provide additional guidelines regarding certificate validation in the context of client-to-client encryption.
+The Jingle stanzas are not encrypted or signed; the same is true of service discovery exchanges and entity capabilities data. Therefore it is possible for an attacker to intercept these stanzas and modify them, thus convincing the initiator that the responder does not support XTLS and therefore denying the parties an opportunity to use XTLS.
+A future version of this specification might address this problem.
+This document requires no interaction with &IANA;.
+This specification defines the following XML namespace:
+Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.
+The XMPP Registrar shall create a registry of TLS methods that can be used in the context of XTLS.
+
+ the XML character data of the TLS method name
+ a natural-language description of the method
+ the document that specifies or registers the method
+
+ ]]>
+ The registrant can register more than one TLS method at a time, each contained in a separate <method/> element.
+The initial registration is as follows.
+
+ openpgp
+ exchange of OpenPGP keys
+ RFC 5081
+
+
+
+ srp
+ exchange of secure remote passwords
+ RFC 5054
+
+
+
+ x509
+ exchange of X.509 certificates
+ RFC 5246
+
+ ]]>
+ The XML schema will be provided in a later version of this document.
+Defined dedicated namespace for the zrtp-hash element to improve service discovery and handling of session-info message; clarified protocol flow and security considerations.
First draft, copied from XEP-0167.
&xep0167; recommends the use of the Secure Real-time Transport Protocol (SRTP) for end-to-end encryption of RTP sessions negotiated using &xep0166;. An alternative approach to end-to-end encryption of RTP traffic is provided by &zrtp;. Although negotiation of ZRTP mainly occurs in the media channel rather than the signalling channel, the ZRTP specification defines one SDP attribute called "zrtp-hash" (this communicates the ZRTP version supported as well as a hash of the Hello message).
+The SDP format is shown below.
+
+a=zrtp-hash:zrtp-version zrtp-hash-value
+
+ An example follows.
+
+a=zrtp-hash:1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df
+
+ This SDP attribute can be translated into Jingle as a <zrtp-hash/> element, as shown below.
+zrtp-hash-value
+ ]]>
+ An example follows.
+fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df
+ ]]>
+ If either party to a Jingle RTP session wishes to use ZRTP, the party SHOULD send a Jingle session-info message that includes a <zrtp-hash/> element qualified by the 'urn:xmpp:jingle:apps:rtp:zrtp:0' namespace, as shown in the following example.
+In accordance with XEP-0166, if the receiving party does not understand the payload of the session-info message then it MUST return a &feature; error.
+However, if the receiving party also supports and wishes to use ZRTP, it too SHOULD send a session-info message containing a zrtp-hash element.
+If an entity supports the zrtp-hash session-info message, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:jingle:apps:rtp:zrtp:0":
+In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
+Security considerations for ZRTP itself are provided in draft-zimmermann-avt-zrtp.
+XMPP stanzas such as Jingle session-info messages and service discovery exchanges are not encrypted or signed. As a result, it is possible for an attacker to intercept these stanzas and modify them, thus convincing one party that the other party does not support ZRTP and therefore denying the parties an opportunity to use ZRTP. However, because the zrtp-hash is mostly advisory, the parties could still use ZRTP even if the signalling channel is compromised.
+This document requires no interaction with &IANA;.
+See the XML Schemas section of this document.
+If this specification is advanced to a status of Draft, the XMPP Registrar shall add the following element definition to the schema for the 'urn:xmpp:jingle:apps:rtp:info:1' namespace defined in XEP-0167:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+First draft.
+ Linked Process is a protocol for Internet-scale, general-purpose distributed computing. With an implementation of this protocol, any computing device with an Internet connection can contribute computing resources to a user-generated compute cloud. +
+ Within the category of computing devices, Linked Process makes a distinction between resource consumers (devices making use of non-local computing resources) and a resource providers (devices offering computing resources)
+ Linked process is unlike Remote Procedure Call (RPC) and Web Service models, where the means by which resources are consumed are defined apriori by the deployer of the service (in the way of functions/methods that can be remotely executed/invoked). The benefit of this protocol is that computing resources that exist elsewhere on the Internet can be leveraged by code that was not developed/created/inteded by the owner/provider of those resources. +
++ Linked Process was developed to address the following two distributed computing requirements: Internet-scale and general-purpose. These requirements imply yet more requirements which accompany their description below. +
+
+ The introduction discussed the physical devices and the roles that they serve as the hardware infrastructure of a Linked Process cloud. This glossary provides a summary of the entites that yield the software instructure of a Linked Process cloud. The following entities make up the core of the Linked Process protocol
+ In short, a resource consumer maintains a villein that communicates with a resource provider's farm in order to spawn and compute with a virtual machine that leverages the computing resources of the provider. +
+ ++ Given that Linked Process provides an Internet-scale, general-purpose compute cloud, there are many use cases. Before listing a collection of general use case scenarios, the following subsections will present the possible interactions that can occur in a Linked Process cloud. These interactions are specified with protocol examples. Once the specifics of the protocol are understood, the end of this section will discuss more generalized scenarios in which Linked Process can be useful. +
++ This is the list of the XMPP stanzas (i.e. packets) that MUST be supported by a farm implementation. +
+
+ The farm specification for <presence/> is built on the specification as defined by the Instant Messaging XMPP specification
+ There are three types of non-subscription-based <presence/> stanzas that a farm produces. +
+
+ A <spawn_vm/> element is wrapped by an <iq/> element. The purpose of <spawn_vm/> is to have a farm create a new virtual machine. It is through a virtual machine that a villein is able to access the computing resources of the physical device that hosts the farm (i.e. the resource provider). A virtual machine will maintain a state throughout a villein "session" with that virtual machine. The only way to alter the state of a virtual machine is through submitting jobs and updating its variable bindings
+ A <submit_job/> element is wrapped by an <iq/> element. The purpose of <submit_job/> is to send code (i.e. expressions, statements, instructions) to a virtual machine for execution (i.e. evaluation, interpretation). The expression SHOULD be respective of the virtual machine's language (i.e. the virtual machine's species). If they are not, then evaluation errors SHOULD occur. The expression submitted through a <submit_job/> stanza can be short (e.g. set a variable value, get a variable value) or long (e.g. define a class/method, execute a long running body of statements). The submitted expression is called a job in Linked Process and is assigned a job_id as specified by the <iq/> id attribute value. That is, the staza id of the <submit_job/> is the job's id. +
++ The virtual machine's state exists over the villein's session with the virtual machine. Thus, note the result of the following <submit_job/>. +
++ A <ping_job/> element is wrapped by an <iq/> element. The purpose of <ping_job/> is to determine the status (i.e. progress, state) of a previously submitted <submit_job/> stanza (i.e. job) that has yet to complete. +
++ An <abort_job/> element is wrapped by an <iq/> element. The purpose of <abort_job/> is to cancel (i.e. quit, stop, halt) a previously submitted, yet not completed <submit_job/> stanza (i.e. job). +
++ A <manage_bindings/> element is wrapped by an <iq/> element. The purpose of <manage_bindings/> is to allow a villein to get and set variables in the variable space of a virtual machine. The definition of the "variable space" is up to the implementation of the virtual machine. In general, this is the set of all global variables for the virtual machine. +
+
+ After the previous <manage_bindings/> stanza has been processed by the virtual machine, it is possible to use the bindings in a statement. For example, in JavaScript
+
+ var fact = name + " knows josh and peter";
+
+ will set fact to the value "marko knows josh and peter" as well as make it an accessible binding.
+
+ A useful aspect of <manage_bindings/> is that it can be used to track the state of a variable during the execution of a job. For example, suppose the following job is submitted to a JavaScript virtual machine.var x = 1.0;
+while(true) {
+ x = x + 0.0001;
+}
+ This job will continue indefinitely (or until it is timed out by the virtual machine). However, during its execution, it is possible to determine the current state of x using <manage_bindings/>. Each get-based <manage_bindings/> call should return a larger x value.
+
+ A <terminate_vm/> element is wrapped by an <iq/> element. The purpose of a <terminate_vm/> is to shutdown (i.e. quit, exit, halt) the virtual machine. Upon termination, the virtual machine will lose its state and will no longer be able to be communicated with. +
++ A farm uses the XEP-0030 XMPP extension for allowing villeins to discover what features and permissions a farm and its spawned virtual machines support. +
++ The <identity/> of a farm MUST be of category="client" and type="bot". The name attribute is up to the implementation. +
++ The following <feature/>s MUST be supported by a farm: +
++ The http://linkedprocess.org/2009/06/Farm# <feature/> denotes that the XMPP client is in fact a farm. +
+
+ For presenting permissions, configurations, and statistics, a farm uses the data forms XEP-0004 XMPP extension in its disco#info response. The following list of <field/> variables (var) are presented below with their requirements specification. What is published by the farm's data form MUST be what is implemented by the farm and its spawned virtual machines. In other words, the data form MUST be consistent with the behavior of the farm and the virtual machines
| Field | +Type | +Option | +Status | +Label | +
|---|---|---|---|---|
| farm_password | +boolean | +false | +REQUIRED | +Denotes whether a password is required to spawn virtual machines. | +
| ip_address | +list-single | +false | +RECOMMENDED | +The IP address of the device hosting the farm. | +
| vm_species | +list-single | +true | +REQUIRED | +The virtual machine species supported by the farm. | +
| vm_time_to_live | +list-single | +false | +REQUIRED | +The number of milliseconds for which a virtual machine may exist before it is terminated by the farm. A value of -1 means infinite. | +
| job_timeout | +text-single | +false | +REQUIRED | +The number of milliseconds for which a virtual machine may exist before it is terminated by the farm. A value of -1 means infinite. | +
| job_queue_capacity | +text-single | +false | +RECOMMENDED | +The number of jobs which a virtual machine can hold in its queue before it rejects requests to submit additional jobs. A value of -1 means infinite. | +
| max_concurrent_vms | +text-single | +false | +RECOMMENDED | +The number of concurrent virtual machines which the farm can support before it rejects a request to spawn a new virtual machine. A value of -1 means infinite. | +
| farm_start_time | +text-single | +false | +RECOMMENDED | +The xs:dateTime at which this farm was started. | +
| read_file | +list-multi | +false | +RECOMMENDED | +The directories/files that virtual machine's have read access to. | +
| write_file | +list-multi | +false | +RECOMMENDED | +The directories/files that virtual machine's have write access to. | +
| delete_file | +list-multi | +false | +RECOMMENDED | +The directories/files that virtual machine's have delete access to. | +
| open_connection | +boolean | +false | +RECOMMENDED | +Whether a socket connection is allowed by the virtual machine. | +
| listen_for_connection | +boolean | +false | +RECOMMENDED | +Whether a socket connection can be listened for by the virtual machines. | +
| accept_connection | +boolean | +false | +RECOMMENDED | +Whether a socket connection can be accepted by the virtual machines. | +
| perform_multicast | +boolean | +false | +RECOMMENDED | +Whether an IP multicast can be initiated by the virtual machines. | +
+ The previously defined interactions can be used in concert to perform some distributed computing task. A list of general use cases are presented below. +
++ The previous list has a collection of more specific application scenarios that are itemized below. Please note that this list is not intended to be exhaustive and provides points of inspiration for the development of more use cases for Linked Process. +
++ This is the list of the stanzas that MUST be supported by a registry. +
++ A registry makes use of <presence/> stanzas for determining the availability of farms on a countryside. In order to monitor <presence/> stanzas emanating from a countryside, a countryside MUST subscribe to and be subscribed from a registry. In Instant Messaging, this is handled using this sequence of <presence/> communication. +
++ After a subscription pairing has been established, the registry will then monitor all <presence/> stanza emanating from the countryside of the subscribing XMPP client. When a registry receives a <presence type="available"/> stanza from a farm (determined through disco#info), then the registry will add the countryside (the bare JID of the farm) to its index. When the registry receives a <presence type="unavailable"/> stanza from a farm, it will only remove that farm's countryside from its index if no other active farms are available at that countryside. In short, a registry only publishes countrysides (i.e. bare JIDs), not farms (i.e. fully-qualified JIDs). However, the determinant for publishing countrysides is the availability of active farms based off the bare JID countryside. +
++ A registry uses the XEP-0030 XMPP extension as the communication protocol for publishing farm-active countrysides. The registry's index is provided to any XMPP client performing a disco#info query. The <item/> elements denote countrysides. For example, <item jid="lanl_countryside@lanl.linkedprocess.org"/> denotes that there is at least one active farm at lanl_countryside@lanl.linkedprocess.org. +
++ A registry uses the XEP-0030 XMPP extension for allowing villeins to discover what features a registry supports. +
++ The <identity/> of a registry MUST be of category="client" and type="bot". The name attribute is up to the implementation. +
++ The following <feature/>s MUST be supported by a registry: +
++ The http://linkedprocess.org/2009/06/Registry# <feature/> denotes that the XMPP client is in fact a registry. +
++ The error codes associated with the http://linkedprocess.org/2009/06/Farm# namespace are fairly complicated as there are various states that a farm and its virtual machines can be in. The following error codes are summarized in the table below. For detailed information about mapping legacy error codes to XMPP-style error types and conditions, refer to Error Condition Mappings. Implementations SHOULD support both legacy and XMPP error handling. +
+| Code | +Type | +Condition | +Specific | +Element | +Purpose | +
|---|---|---|---|---|---|
| 400 | +Modify | +bad-request | +malformed_packet | +all | +The provided stanza was not properly constructed. | +
| 401 | +Auth | +not-authorized | +wrong_farm_password | +spawn_vm | +The supplied farm password was incorrect. | +
| 409 | +Cancel | +conflict | +internal_error | +all | +An error internal to the farm has occurred. | +
| 503 | +Cancel | +service-unavailable | +farm_is_busy | +spawn_vm | +The farm is out of resources and can not spawn a new virtual machine. | +
| 400 | +Modify | +bad-request | +species_not_supported | +spawn_vm | +The provided virtual machine species is not supported by the farm. | +
| 404 | +Cancel | +item-not-found | +vm_not_found | +all except spawn_vm | +The virtual machine id does not point to an existing virtual machine. | +
| 503 | +Cancel | +service-unavailable | +vm_is_busy | +submit_job | +The virtual machine has too many jobs in its queue and will not accept anymore. | +
| 400 | +Modify | +bad-request | +evaluation_error | +submit_job | +The supplied job expression threw an error in the virtual machine. | +
| 403 | +Auth | +forbidden | +permission_denied | +submit_job | +The supplied job expression violated a security permission in the virtual machine. | +
| 409 | +Cancel | +conflict | +job_already_exists | +submit_job | +The supplied job identifier already exists in the virtual machine. | +
| 408 | +Cancel | +request-timed-out | +job_timed_out | +submit_job | +The submitted job timeout and is no longer executing. | +
| 404 | +Cancel | +item-not-found | +job_not_found | +ping_job and abort_job | +The queried job identifier does not point to an existing job. | +
| 405 | +Cancel | +not-allowed | +job_aborted | +submit_job | +The submitted job was canceled. | +
| 400 | +Modify | +bad-request | +unknown_datatype | +manage_bindings | +The provided datatype is an unsupported datatype. | +
| 400 | +Modify | +bad-request | +invalid_value | +manage_bindings | +The provided value can not be converted according to the provided datatype. | +
+ This specification does not stipulate values of the XMPP <text/> element associated with the foregoing error conditions. +
++ Linked Process can be a very dangerous protocol if implemented incorrectly. The reason for this is that foreign code is executed on devices that are unaware of the intention or purpose of the code. Thus, if farm and virtual machine implementations do not correctly respect the permissions stated by the farm (as specified in the disco#info of the farm), then it is possible for malicious or poorly written code to destroy the integrity of the executing device (i.e. the resource provider). Moreover, Linked Process devices can be utilized for nefarious purposes. +
++ The following is a list of potentially dangerous behaviors that can be executed if a Linked Process farm and virtual machine is not implemented correctly and/or exposes permission that are too "loose." +
++ It is strongly RECOMMENDED that the implementors of a Linked Process farm and virtual machine have considerable knowledge in the area of software security and operating system engineering. +
++ This document requires no interaction with the Internet Assigned Numbers Authority (IANA) +
+
+
+
+
+
+
+ The protocol documented by this schema is defined in
+ Linked Process XEP-XXX: http://www.xmpp.org/extensions/xep-xxx.html
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+]]>
+
++An acknowledgement of contribution must be given to Peter Neubauer (Neo Technology). Peter contributed to the testing of an implementation of the protocol that was developed in concert with this specification. Through the testing process, many issues were identified, rectified, and incorported into the protocol specification. +
+First draft. Also John's birthday.
The use of XMPP on mobile devices is little understood, since few XMPP implementors have good mobile knowledge, and few mobile engineers have good XMPP knowledge. In addition, as the mobile landscape has changed, optimal protocol designs and usage patterns have also changed. This has led to the sub-optimal combination of a large amount of mostly undocumented lore, as well as several outdated concepts being discussed as fact.
+This XEP aims to provide useful background knowledge of mobile handset behaviours, and essentially distills a number of conversations with experienced mobile engineers and XMPP implementors, providing useful background as general suggestions.
+Mobile handsets typically have two constraints - power and bandwidth. The advent of 3G technology and beyond has tended to mean that bandwidth is radically higher, and comparable to broadband speeds - however many operators still charge based on transferred data, hence bandwidth remains an important issue for cost purposes.
+The major cost of power in the handset for our purposes is the radio - here, too, bandwidth plays a part, but as this document will show, the time the radio is forced to be available to receive also costs substantially.
+Whilst this document refers to &xmppcore;, implementors are advised to take note of &rfc3920bis;.
+XMPP is known to compress well. Both TLS, part of &xmppcore;, and &xep0138; can provide access to the DEFLATE codec (RFC 1951
Compression ratios vary with usage, however, typical usage by a general client appears to show a 20% ratio (an 80% reduction in bandwidth) in longer sessions
At an exemplary point in one experiment, the author found the following figures
| Window Bits | +Compression Ratio (approx) | +
|---|---|
| 15 | +20% | +
| 14 | +22% | +
| 13 | +25% | +
| 12 | +30% | +
| 11 | +38% | +
| 10 | +43% | +
| 9 | +60% | +
Although there is an equal cost for the mobile device to compress, it is considered that the compression codec memory and CPU costs - while certainly translating into power cost - are outweighed by two factors. Firstly, they're likely to reduce the transmission cost by a greater amount, and secondly they will also reduce the encryption cost in TLS.
+Care, however, should be taken not to use XEP-0138 compression when TLS compression is in effect.
+Mobile handsets have a number of levels for radio activity. 3G radios can be either Idle, or else in an increasingly capable - and increasingly power-hungry - series of levels, through FACH to DCH.
+For the purposes of investigating this, power consumption (or rather battery depletion rate, as current) and timeouts where measured on the 3UK network, with a Nokia E71, using the Energy Profiler. A "typical handset" mentioned here has a 1000mAh battery - some smartphones have up to 1500mAh. Note that all timeouts are under the control of the network operator, not the handset or application.
+Idle state is when the radio is neither receiving nor transmitting. It may have live (although silent) TCP connections. The cost is low. There is also a PCH level, which is similarly low-power, and again is only used when the radio is silent.
+The current here was measured as 8mA - likely affected more by the energy profiler than much else.
+FACH uses a shared channel for low-bandwidth communications. Packet sizes must be small - around 128 octets maximum, although this is operator controlled. Raising to this state takes around 2.5 seconds before the data can flow - although the power cost rises instantly - and after the session has returned to silence, it will remain at FACH level for some time.
+Note that this threshold includes the overheads from TCP and TLS, which are 52 and 5 octets respectively, leaving around 70 octets for the payload data.
+Here, the current was measured as 140mA, and a timeout of 8 seconds - this timeout is at the lower end of the expected range, which could be up to around 2 minutes. On a typical handset, this will exhaust the battery in around 7 hours.
+DCH uses a dedicated channel for high bandwidth communications. Again, raising to this state takes 2.5 seconds at the DCH power level, and there is a timeout before dropping back. Some operators will drop back to FACH for the duration fo the FACH timeout - others will drop back to Idle/PCH.
+Sending more than the FACH threshold will raise the radio all the way to DCH - taking, again, 2.5 seconds.
+The measurements here were 380mA and 8 seconds - this is sufficient to flatten a typical handset battery in less than 3 hours, and the figures are considered normal.
+Transmission of data can use up to 2W
Experimentation suggests that uncompressed XMPP will never trigger the FACH state, leaping directly into the more costly DCH state. However, compression does make FACH possible, if rare.
+As with anything, there are no hard and fast rules. If there were, they might look like these. First, for devices:
+And for servers, similar rules apply:
+Finally, protocol designers should aim to minimize any responses required from the handset, and ensure keepalive traffic, if any, fits inside FACH wherever possible.
+This section provides pointers to other documents which may be of interest to those developing mobile clients, or considering support for them in servers.
+&xep0138; provides application stream level compression, useful if the device TLS stack does not support TLS-based compression.
+&xep0115; provides a mechanism for caching, and hence eliding, the disco#info requests needed to negotiate optional features.
+&xep0237; provides a relatively widely deployed extension for reducing the roster fetch bandwidth, in most cases reducing it to a simple affirmation that the client has the current roster. This saves not only bandwidth, but also reduces local storage writes.
+&xep0198; provides session resumption over TCP, enabling a client to handle the case where the coverage is patchy. The <r/> and <a/> elements also provide a keepalive facility in a small number of octets.
+&xep0273; provides a mechanism which, amongst other things, would allow a presence "hush", buffering presence during certain states.
+The author is not a mobile expert, and relied on the knowledge and patient help of several others. In particular, thanks are due to Jussi Laako, Markku Vampari, and Markus Isomaki of Nokia, and Simon Tennant of Buddycloud.
+The attribution of any mistakes herein is zealously guarded by the author, however.
+This document does not discuss a protocol, thus introduces no new security considerations.
+None.
+None.
+Modified syntax to use 'old' and 'new' attributes.
+Added one-way subscription section
+Change MUST NOT to SHOULD NOT for clients auto-subscribing back; differentiate between inbound and outbound subscriptions.
+Add one-way subscription comments.
Minor tweaks.
First draft.
There are a variety of reasons why a user may wish to change + their JID. For example, a surname change because of marriage or simply + an easier JID to remember. +
+ +This XEP defines an approach for communicating that your JID has + moved to a new JID, extending the existing subscription protocol documented + in &rfc3921;. The steps outlined here may be done either through a client + or automated by a server. +
+In this scenario user@example.com moves to user2@example2.com. + Both the user@example.com and user2@example2.com accounts have been + created and still exist. The roster for user@example2.com is empty + and the user wants to populate it with their entries from + user@example.com.
+ +Because the original JID is no longer going to be used, the user SHOULD + unsubscribe from all the outbound subscriptions user@example.com had. + These can be identified as those in the 'to' or 'ask' states as + defined in the 'jabber:iq:roster' protocol in &rfc3921;.
+ +To unsubscribe all outbound subscriptions for the original JID send an + unsubscribe &PRESENCE; stanza to all the old contacts with a &MOVED; + element containing the new JID.
+ +There is the potential for other users to send a malicious unsubscribe + containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT + automatically subscribe to the JID contained in the &MOVED; stanza when + receiving a subscribe &PRESENCE; stanza without displaying the &MOVED; + JID to the user. See the Security Considerations section for + details.
+ +Because the original JID is no longer going to be used, the user SHOULD + unsubscribe from all contacts the user@example.com had an inbound + subscription from. These can be identified as those in the 'from' + subscription state as defined in in the 'jabber:iq:roster' protocol + in &rfc3921;.
+ +To unsubscribe all inbound subscriptions send an unsubscribed + &PRESENCE; stanza to all the old contacts with a &MOVED; element + containing the new JID.
+ +There is the potential for other users to send a malicious unsubscribed + containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT + automatically subscribe to the JID contained in the &MOVED; stanza + without displaying the &MOVED; JID to the user. See the Security + Considerations section for details.
+ +Once the new JID has been created on a server it is possible for the + new JID to subscribe to the contacts they had on the original JID's + roster. This is done by sending a new subscription request with a + &MOVED; element containing the new JID. +
+ +The new subscription MUST come from the new JID's server.
+ +There is the potential for other users to send a malicious subscribe + request and spoof the content of the &MOVED; element identifying an + original JID. Therefore, clients SHOULD NOT automatically unsubscribe + an existing roster entry if is listed as the target in the &MOVED; + element when a subscribe is received. See the Security + Consideration section for details.
+ +Clients accepting the moved subscription SHOULD indicate to the + user that that this subscription request was the result of a move + operation and because of potential malicious behavior SHOULD NOT + auto-accept the subscription without displaying the &MOVED; JID to the + user.
+ +&rfc3920bis; clarifies that an incoming subscribe &PRESENCE; stanza + MUST be preserved by the server and &PRESENCE; stanzas of type + unsubscribe and unsubscribed are not preserved on the server. + Therefore, for a contact who is offline, their servers MAY have + automatically removed the original roster entry when seeing the + unsubscribe and unsubscribed stanzas. At the time of writing this XEP, + NOT saving and forwarding the presence stanzas will be the default + behavior of most servers. +
+ +What this means is that a contact coming online after the rename + outlined above MAY only see the &PRESENCE; of type 'subscribe' with + the &MOVED; element. Clients should be aware of this behavior. +
+In following the principle of least surprise, it is considered good + practice to send the subscribe stanza after the unsubscribe and unsubscribed + stanzas. +
+One of the side effects of this scheme is the potential for a contact + to lose the groups to which it had organized the original JID. Clients + aware of the &MOVED; element can mitigate this with the following rules. +
+ +As discussed in 'Contacts Offline at the Time the Rename Occurs', a + server MAY automatically handle the unsubscribe and unsubscribed stanzas. + If this occurs it will be impossible to preserve the original groups. +
+ +If the original JID, user@example.com, had only an inbound subscription + (from or pending in), then the contact will only receive an + unsubscribed &PRESENCE; stanza. The contact's client, knowing the + state of the subscription (which is 'to' or 'none' with 'ask='subscribe' + from the contact's perspective), at that point MAY choose to prompt the + user to subscribe to the new JID listed in the &MOVED; element.
+ +Because of the ability to spoof the &MOVED; element, the client SHOULD + NOT automatically subscribe to the &MOVED; element target, but SHOULD + present the new JID to the contact before sending out a subscription + request.
+If the original JID, user@example.com, had only an outbound + subscription (to or ask), then the contact SHOULD only receive an + unsubscribe &PRESENCE; stanza. The contact's client, knowing the + state of the subscription (which is 'from' from the contact's perspective), + at that point MAY choose to prompt + the user to subscribe to the new JID listed in the &MOVED; element.
+ +Because of the ability to spoof the &MOVED; element, the client SHOULD + NOT automatically subscribe to the &MOVED; element target
. +| Server state | +Client state (jabber:iq:roster) | +Send unsubscribe from original JID | +Send unsubscribed from original JID | +Send subscribe from new JID | +
| none | +none | ++ | + | + |
| none + pending out | +none + ask='subscribe' | +yes | ++ | yes | +
| none + pending in | +n/a | ++ | yes - server only | ++ |
| none + pending in/out | +none + ask='subscribe' | +yes | +yes - server only | +yes | +
| to | +to | +yes | ++ | yes | +
| to + pending in | +to | +yes | +yes - server only | +yes | +
| from | +from | ++ | yes | ++ |
| from + pending out | +from/none + ask='subscribe' | +yes | +yes | +yes | +
| both | +both | +yes | +yes | +yes | +
It is not intended for servers to strip any &MOVED; elements from + &PRESENCE; stanzas sent in from a client. This allows clients as well as + servers to implement these same procedures.
+ +In order to prevent other users from maliciously altering contacts + the client SHOULD NOT automatically subscribe to a &MOVED; JID when it + receives an unsubscribe and SHOULD NOT automatically unsubscribe to + a &MOVED; JID when it receives a subscribe.
+ +The following illustrates an example malicious attack.
+ +A similar attack can be done with a new subscribe request causing users + by guessing which users are subscribed to a contact.
+ +This document requires no interaction with &IANA;.
+This specification defines the following XML namespace:
+Upon advancement of this specification from a status of Experimental + to a status of Draft, the ®ISTRAR; shall add the foregoing namespace + to the registry located at &NAMESPACES;, as described in Section 4 of + &xep0053;. +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+The author wishes to thank Doug Abbink, Mikhail Belov, Peter Saint-Andre, and Peter Sheu for their feedback.
+Second rough draft.
+ Joining a conference is done in two stages. The first step is to
+ declare that preparations are being done to either join or start a muji
+ session inside the MUC. This is indicated by the client sending a presence
+ stanza to the MUC with a preparing element in muji section.
+
+
+
+
+ + When a client adds a payload ID to a content description, it MUST have the + same codec name and receiving parameters as the corresponding entries in + other participants' payload maps for that content. For instance, if Alice + defines a payload type with ID 98, codec Speex and a a clock rate of 8000 + for a content called “voice0”, then Bob must define payload type 98 + identically or not at all for that content. +
+ ++ Furthermore, each content description MUST include at least one payload type + that every other participant supports. In other words, the intersection of + payload type mappings in descriptions for a content must not be the empty + set. This avoids clients having to encode the same stream multiple times, + which can be very costly, and also allows sending the encoded data only once + where the transport makes this possible (e.g. IP multicast). +
+ ++ Once a client has constructed content descriptions and advertised them in + its MUC presence, it MUST initiate a Jingle session with every other + participant. The requirement that it is the joining participant that + initiates sessions avoids race conditions. +
+ ++ + Jingle sessions are initiated between the MUC JIDs of participants. That is, + the Jingle session-initiate stanza is sent from one MUC JID to another. This + allows participants to easily identify sessions as belonging to a Muji + conference. Content names inside Muji-related Jingle sessions always refer + to the content with the same name inside the Muji conference. +
++ To leave a conference the Muji information MUST first be removed from the + participant's presence; subsequently it SHOULD terminate all Jingle sessions + related to that conference. Updating the presence first reduces the + likelihood of situations where new participants initiate sessions with + participants who are leaving the conference. +
+
+ Adding a stream follows a process similar to the joining a conference. As a
+ first step an updated presence stanza MUST be send which contains a preparing
+ element as part of the Muji section.
+
+
+
+
+ The client MUST then wait until the MUC rebroadcasts its presence message,
+ after which it MUST wait for all other participants that had a preparing
+ element in their presence to finish their changes.
+
+ Afterwards the client should add the new content to the muji section of its
+ presence and add the content to all the jingle sessions it had with
+ participants it shared the content with.
+
+
+
+
+ To remove a content the participant SHOULD first sent an updated presence + without the content in its muji section. Afterwards it MUST the content from + all the jingle sessions it has open. +
++ When scaling to conferences with a big number of participants or when + clients it's no longer viable for all participants to have direct + connections. + + On connections where upstream bandwidth is the limiting factor an RTP a + RTP relay which is able to relay the stream to multiple participants on + the behalf of the clients and which forwards the streams of other + participants back to the client can be used. + + If the limiting factor is either CPU or downstream bandwidth then a mixer + can be used, which receives the media streams from other participants and + mixes them on behalf of the client, so that the client only has to deal + with receiving and decoding a single stream for each media type. On the + sending side a mixer acts like a relay and relays the clients stream to all + other participants. + + Both these services can either be provided by dedicated services or by + other clients. +
+Added sections about entering non-anonymous, semi-anonymous and fully-anonymous rooms.
Second draft.
First draft.
+ Many modern instant messenger networks support playing games. + Still, XMPP mostly lacks this kind of support. + Therefore, this document (Multi-User Gaming or MUG) describes a base protocol for game playing over XMPP. +
++ This protocol is not by itself sufficient to play games. + It just describes a basic protocol framework which game-specific protocols can use. +
++ This document addresses the functionality which is needed to play multi-user games over XMPP. + In particular this functionality consists of: +
++ In addition, this document provides protocol elements for supporting the following room types: +
++ The following requirements are explicitly not adressed, but might be realized by seperate XEPs. +
++ The extensions needed to implement these requirements are qualified by the 'http://jabber.org/protocol/mug' namespace + (and the #owner, and #user fragments on the main namespace URI). +
+Game -- a XEP which defines the rules of a match
+Initiator -- the entity that started a game.
+Match -- represents a specific instance of a game played in a room.
+Member -- a user with an affiliation of type "member" in the context of member-only games.
+Owner -- a priviledged entity that owns a game.
+Player -- a user in a match who has a defined game role
+Role -- role in the game (e.g. 'black' and 'white' in chess)
+Room -- a game room in which matches are played
+Room JID -- + the &ROOMJID; by which an occupant is identified within the context of a match; + contrast with Bare JID and Full JID.
+Spectator -- an entity who does not actually plays the game but watches it.
+Occupant -- a player or spectator who is currently in the match.
+Unmoderated Room -- + The owner has limited rights. The match cannot be saved; antonym: Moderated Room.
+Moderated Room -- + The owner is allowed to kick users, revoke roles and save the match; antonym: Unmoderated Room.
+ +Hidden Room -- + a room that cannot be found by any user through normal means such as searching and service discovery; + antonym: Public Room.
+Public Room -- + a room that can be found by any user through normal means such as searching and service discovery; + antonym: Hidden Room.
+ +Members-Only Room -- + a room that a user cannot enter without being on the member list; + antonym: Open Room.
+Open Room -- + a room that anyone may enter without being on the member list; + antonym: Members-Only Room.
+ +Password-Protected Room -- + a room that a user cannot enter without first providing the correct password; + antonym: Unsecured Room.
+Unsecured Room -- + a room that anyone is allowed to enter without first providing the correct password; + antonym: Password-Protected Room.
+ +Fully-Anonymous Room -- + a room in which the full JIDs or bare JIDs of occupants cannot be discovered by anyone, + including the room owner; contrast with Non-Anonymous Room and Semi-Anonymous Room.
+Semi-Anonymous Room -- + a room in which an occupant's full JID can be discovered by the room owner only; + contrast with Fully-Anonymous Room and Non-Anonymous Room.
+Non-Anonymous Room -- + a room in which an occupant's full JID is exposed to all other occupants; + contrast with Semi-Anonymous Room and Fully-Anonymous Room.
+active -- room that is currently in use
+adjourned -- 'saved' room
++ There are three different match status: +
+created -- before the initial room configuration is done
+inactive -- before and after a match, turns are not possible, options can be changed
+active -- within a match, turns are possible, options cannot be changed
+paused -- halted within a match, turns are not possible, options cannot be changed
+| Room Nickname | Full JID | Affiliation | Game Role | +
|---|---|---|---|
| damsel | miranda@shakespeare.lit/desktop | Owner | White | +
| lad | ferdinand@shakespeare.lit/laptop | None | Black | +
| KingOfNaples | alonso@shakespeare.lit/pda | None | None | +
| prospero | prospero@shakespeare.lit/cell | None | None | +
+ Support for the all affiliations is REQUIRED. + (The "None" affiliation is the absence of an affiliation.) +
++ If a user without a defined affiliation enters a match, the user's affiliation is defined as "None". +
++ The member affiliation provides a way for room owners to specify a "whitelist" of users + who are allowed to enter a members-only match. + When a member enters a members-only match, his or her affiliation does not change. +
++ Information about affiliations MUST be sent in all presence stanzas generated or reflected by the match and sent to occupants. +
+ +| Room Type | +Configure | +Save/Load | +Grant Member | +Revoke Member | +Assign Role | +Revoke Role | +
|---|---|---|---|---|---|---|
| moderated match | +inactive | +all status | +all status | +all status | +all status | +all status | +
| unmoderated match | +inactive | +inactive | +all status | +inactive | +inactive and paused | +inactive and paused | +
+ A MUG implementation MUST support &xep0030;, &xep0128; and &xep0055;. +
++ A Jabber entity may wish to discover if a service implements the + Multi-User Game protocol; in order to do so, it sends a service + discovery information ("disco#info") query to the service's JID: +
++ The service MUST return its identity and the features it supports: +
++ The service discovery items ("disco#items") protocol enables a user to query a + service for a list of associated items, which in the case of a game service would + consist of the active game rooms hosted by the service. +
++ The service SHOULD return a full list of the active and public rooms it hosts. +
++ If the full list of rooms is large (see &xep0030; for details), + the service MAY return only a partial list of rooms. + If it does so, it SHOULD include a <set/> element (as defined in &xep0059;) + to indicate that the list is not the full result set. +
++ It is RECOMMENDED that a user uses &xep0055; to search for active or adjourned rooms. + At first the user needs to discover what search fields are supported by the service: +
++ The service MUST then return the possible search fields to the user, and MAY include instructions: +
++ The Saved Room option allows to search for active or adjourned rooms (see Room Status). + The Game Category field is to classify the game and to be able to only search for certain types of games. + Every game protocol MUST define its category in the corresponding game XEP. +
++ After having received the possible search fields, + the user MAY then submit a search request, specifying values for any desired fields: +
++ The submitting entity MAY submit the 'category' or 'game' field but MUST NOT submit both. + Sending an empty form adds up to searching for all games. +
++ The service SHOULD then return a list of search results that match the values provided: +
+ ++ If the full list of rooms is large, + the service MAY return only a partial list of rooms. + If it does so, it SHOULD include a <set/> element (as defined in &xep0059;) + to indicate that the list is not the full result set. +
+ ++ Using the disco#info protocol, a user may also query a specific room for + more detailed information about the room. A user MAY do so before entering a + room in order to discover the room configuration. +
++ The room then MUST return its identity and the features it supports. +
++ A room MUST also return more detailed information in its disco#info response + using &xep0128;, identified by inclusion of a hidden FORM_TYPE field whose + value is "http://jabber.org/protocol/mug#matchinfo". + It MUST include a 'mug#game' field specifiying the namespace of the + game. + Optional information MAY include a more verbose description of the room + and the current number of occupants and players in the match or + 'mug#match_chat' field specifiying a URI for the chat. + This is usually a &xep0045;. +
++ See Room Types for details. +
++ A user MAY also query a specific match for its associated items (occupants): +
++ An implementation MAY return a list of existing occupants if that + information is publicly available, or return no list at all if this + information is kept private. +
++ Note: These <item/> elements are qualified by the disco#items namespace, + not the mug namespace; this means that they cannot possess 'role' attributes, + for example. +
++ If a non-occupant attempts to send a disco request to an address of the form + &ROOMJID;, a MUG service SHOULD return the request to the entity and specify a + &badrequest; error condition. If an occupant sends such a request, the service + MAY pass it through the intended recipient. +
++ A Jabber user may want to discover if one of the user's contacts supports the + Multi-User Game protocol. This is done using Service Discovery. +
++ The client SHOULD return its identity and the features it supports: +
++ A user may also query a contact regarding which room the contact is in. + This is done by querying the contact's full JID (<user@host/resource>) + while specifying the Service Discovery node + 'http://jabber.org/protocol/mug#matches': +
++ The requested client MAY list the active rooms as response; + see the Implementation Guidelines section of this document for details. +
++ Optionally, the contact MAY include its room nick as the value of the 'name' attribute: +
+
+ ...
+ ]]>
+ + The client MAY implement &xep0196; to announce running games. + To publish a running game the user sends: +
++ When the user stops playing the game (i.e. leaves the game room), + the user's client SHOULD send an empty &GAME; element with the same ItemID: +
++ The &ROOM; itself MUST then add a 'from' address to the &INVITE; element whose value is the room JID of the invitor + and send the invitation to the invitee specified in the 'to' address. + The room SHOULD add the password if the room is password-protected: +
++ If the room is members-only, the service MAY also add the invitee to the member list. + If the invitor supplies a non-existent JID, the room SHOULD return an ¬found; error to the invitor. + The invitee MAY choose to formally decline (as opposed to ignore) the invitation; + and this is something that the sender may want to be informed about. + In order to decline the invitation, + the invitee MUST send a message of the following form to the &ROOM; itself: +
++ Invitations MAY be based on room JIDs rather than bare JIDs + (so that, for example, an occupant could invite someone from one match to + another without knowing that person's bare JID). + Thus the service MUST handle both the invites and declines. +
++ A User enters a room as follows: +
++ The service MAY assign a free role to the user. +
++ If the service is able to add the user to the room, + it MUST send presence from all the existing occupants' room JIDs to the new occupant's full JID, + including extended presence information about roles in a &GAME; element + qualified by the 'http://jabber.org/protocol/mug' namespace + and containing an &ITEM; child with the 'affiliation' attribute + set to a value of "owner", "member", or "none" as appropriate: +
++ The service MUST also send the new occupant's presence to all occupants including the new occupant. + If a role was assigned to the new occupant, it MUST be included in the presence + in order to notify the new and all other occupants about the new occupant's role. +
++ Note: The order of the presence stanzas sent to the new occupant is important. + The service MUST first send the complete list of the existing occupants to the + new occupant and only then send the new occupant's own presence to the new + occupant. This helps the client know when it has received the complete + "room roster". +
++ If the room is non-anonymous, the service MUST send the new occupant's full JID + to all occupants using extended presence information in an &GAME; element qualified + by the 'http://jabber.org/protocol/mug' namespace and containing an &ITEM; child + with a 'jid' attribute specifying the occupant's full JID: +
++ If the room is semi-anonymous, the service MUST send presence from the new occupant + to all occupants as specified above, but MUST include the new occupant's full JID + only in the presence notifications it sends to the room owner and not to any other + occupant. +
++ If the room is fully-anonymous, the service MUST send presence from the new occupant + to all occupants as specified above, but MUST NOT include the new occupant's full JID + to any other occupant. +
++ If the room requires a password and the user did not supply one (or the password + provided is incorrect), the service MUST deny access to the room and inform the + user that they are unauthorized; this is done by returning a presence stanza of + type "error" specifying a ¬authorized; error: +
++ Passwords SHOULD be supplied with the presence stanza sent when entering the room, + contained within an <game/> element qualified by the + 'http://jabber.org/protocol/mug' namespace and containing a <password/> child. + Passwords are to be sent as cleartext; no other authentication methods are supported + at this time, and any such authentication or authorization methods shall be defined + in a separate specification (see the Security Considerations + section of this document). +
++ If the room is members-only but the user is not on the member list, the service MUST + deny access to the room and inform the user that they are not allowed to enter the + room; this is done by returning a presence stanza of type "error" specifying a + ®istration; error condition: +
++ If the room already contains another user with the nickname desired by the user + seeking to enter the room (or if the nickname is reserved by another user on the + member list), the service MUST deny access to the room and inform the user of the + conflict; this is done by returning a presence stanza of type "error" specifying a + &conflict; error condition: +
++ However, if the bare JID &USERJID; of the present occupant matches the bare JID + of the user seeking to enter the room, then the service SHOULD allow entry to the user, + so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. + If a service allows more than one occupant with the same bare JID and the same room nickname, + it SHOULD route in-room messages and presence to all of the user's resources + and allow all of the user's resources to send messages to the room; + it is up to the implementation to determine how to route + private messages to all or only one resource + (based on presence priority or some other algorithm). +
++ If the room has reached its maximum number of occupants, the service SHOULD + deny access to the room and inform the user of the restriction; this is done + by returning a presence stanza of type "error" specifying a &unavailable; + error condition: +
++ Alternatively, the room could kick an "idle user" in order to free up space. +
++ If a user attempts to enter a room while it is "locked" (i.e., before the room creator + provides an initial configuration and therefore before the room officially exists), the + service MUST refuse entry and return an ¬found; error to the user: +
++ If the room does not already exist when the user seeks to enter it, the service SHOULD + create it; however, this is not required, since an implementation or deployment MAY + choose to restrict the privilege of creating rooms. For details, see the + Creating a Room section of this document. +
++ When a user wants to take a free role, + he sends the following presence to &ROOM;. +
++ After the role has been successfully assigned to the requesting occupant, + the service MUST send the new presence to all occupants. +
+If the role is already taken, the service must return the following error.
+ ++ If the requested role doesn't exist in the match, the service MUST return a not-acceptable error. +
++ After the match is ready to be started (as to be defined by the game protocol), + all players MUST send start messages in order to start the game. +
+ ++ In order to see what players are ready to start, the service MUST reflect + the start message from each player to all players. +
+ ++ If the match is not ready, the service MUST send the following error. +
+ ++ After the service received messages from all players, + it MUST update the match status from inactive to active by a + presence broadcast to all occupants. + If the owner changes the configuration or roles change after a player sent his message + and before the service sends presence broadcast indicating the game status active, + the player MUST send the message again. +
+ ++ Note that the spectator alonso recieves the start presence, too. +
++ In order to make a move in a match, a &MESSAGE; stanza MUST be send to &ROOMJID; + containing a &TURN; element qualified by 'http://jabber.org/protocol/mug#user' namespace. + Game protocols SHOULD place own elements defining the turn inside the &TURN; element. +
++ A service MUST validate the player's move before passing it to the occupants. + If the turn is invalid, as defined by the game protocol, + the service MUST return an error and kick the player + unless the player is the owner of the room, in which case he SHOULD lose his game role. +
+ ++ If a spectator sends a turn the service MUST return the following error. +
+ ++ If a player sends a turn while the match status is 'inactive' or 'paused' + the service MUST send this error: +
+ ++ If the move is valid, the service MUST distribute the turn. + The occupants, who receive the turn are defined by the game protocol. + However, the turn MUST be reflected to the sender. +
+ ++ If a client wants to resign, he sends the following. +
++ Afterwards, the service decides whether to cancel or pause the match + based on the game specification. +
++ The game protocol respectively the game protocol implementation decides when a match is over. + In the case of game termination, + the service MUST notify every player through updated presence including the resulting final state. +
+To change his nickname, an occupant sends the following presence.
+ +The service must send the updated presence to all occupants.
+ ++ If the room already contains another user with the nickname the same rules apply + as on entering a room. +
+ ++ Since each occupant has a unique room JID, an occupant MAY send a "private message" to a + selected occupant via the service by sending a message to the occupant's match JID. The message + type SHOULD be "chat", or MAY be left unspecified (i.e., a normal message). This privilege + SHOULD be allowed to any occupant (even a spectator in a moderated room). +
++ The service is responsible for changing the 'from' address to the sender's match JID and + delivering the message to the intended recipient's full JID. +
++ If the sender attempts to send a private message to a room JID that does not exist, + the service MUST return an ¬found; error to the sender. +
++ If the sender is not an occupant of the room in which the intended recipient is visiting, + the service MUST return a ¬acceptable; error to the sender. +
++ If allowed in accordance with room configuration, an occupant MAY be allowed to + retrieve the list of room members. For details, see the + Modifying the Member List section of this document. +
++ In order to exit a multi-user game room, an occupant sends a presence stanza + of type "unavailable" to the &ROOMJID; it is currently using in the room. +
++ If the leaving occupant had a role that was indispensable, the service MUST pause or cancel the game. +
+ ++ To resume the game, all players have to send <start/> messages again. +
+ +To create a room a user sends the following presence to the room.
+ ++ If the priviledge to create a room is restricted to certain users + and the room cannot be created, + the service MUST reply with the following error. +
+ ++ If a game element or the var attribute with the game namespace is + missing then the service MUST deny creating a room and send a + presence with a bad request error back to the user. +
+ ++ If this user is allowed to create a room and the room does not yet exist, + the service MUST create the room according to some default configuration, + assign the requesting user as the initial room owner, + and add the owner to the room but not allow anyone else to enter the room + (effectively "locking" the room). + The initial presence stanza received by the owner from the room MUST include + extended presence information indicating the user's status as an owner + and acknowledging that the room is awaiting configuration and that the initial + match status is 'created'. +
+ ++ The role attribute is only necessary if the service assignes roles automatically. +
+ ++ To request a room with the default configuration the owner sends the following query. +
+ ++ If the user wants to configure the room, he MAY first request the configuration form. +
+ ++ If no configuration is possible, the service MUST return the following error. +
+ ++ The service then sends the initial configuration form to the user. +
+ ++ To finish the configuration, the user MUST submits the completed form to the service. +
+ ++ In addition to the room configuration, the user MAY also supply a custom initial state for the match. +
+ ++ Valid states are defined by the game protocol + and may consist of the explicit current state in form of a data form + or the series of turns that led to the state. +
+ +
+ If the room creation fails because the specified room configuration options violate
+ one or more service policies (e.g., because the password for a password-protected room is blank),
+ the service MUST return a
Alternatively, the room owner MAY cancel the configuration process:
+ ++ If the room owner cancels the initial configuration, the service SHOULD destroy the room, making sure to send unavailable presence to the room owner (see the "Destroying a Room" use case for protocol details). +
+ ++ The owner may change the configuration whenever the match status is 'inactive'. +
+ ++ If there are no configuration options available, + the service MUST return an empty query element to the owner as shown in the previous use case. +
++ The owner SHOULD then submit the form with updated configuration information. +
+ ++ If as a result of a change in the room configuration the room type is changed to members-only, + any occupants MUST become members and the service MUST reflect the updated presence to all. +
+ ++ A room MUST send notification to all occupants when the room configuration changes. + If the game configuration changed, the game MUST also specify an adequate match state. +
+ ++ The owner may save the room whenever the match status is 'inactive' and + save the room including the match state in a moderated room. +
+ ++ If saving is allowed, the service MUST inform all occupants and remove them from the room. +
+ ++ After saving the room, nobody can join it until it is loaded by the owner. +
+ ++ For Discovering of Saved Rooms see search for rooms. + Send an iq stanza to request loading a the room as follows: +
++ After loading, the match status is 'paused' if the match was 'active' before saving. + Alternatively, the match status is set to 'inactive' if the match was inactive. + The service SHOULD send an invitation to all occupants that were present in the game when saved. +
++ Players entering the room SHOULD be assigned the role they had when the room was saved. +
++ In the context of a members-only match, the member list is essentially a + "whitelist" of people who are allowed to enter the match. Anyone who is not + a member is effectively banned from entering the match. +
++ In the context of an open match, the member list is simply a list of users + (bare JID and reserved nick) who are registered with the match. Such users + may appear in a match roster, have their match nickname reserved, be + returned in search results, and the like. +
++ It is RECOMMENDED that only the room owner + has the privilege to modify the member list in members-only rooms. + To do so, the owner first requests the member list by querying the room + for all users with an affiliation of "member": +
++ Note: A service SHOULD also return the member list to any occupant in a + members-only room; i.e., it SHOULD NOT generate a &forbidden; error when + a member in the room requests the member list. + This functionality may assist clients in showing all the existing members + even if some of them are not in the room, e.g. to help a member determine + if another user should be invited. + A service SHOULD also allow any member to retrieve the member list even + if not yet an occupant. +
++ The service MUST then return the full member list to the owner qualified + by the 'http://jabber.org/protocol/mug#owner' namespace; each item MUST + include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and + 'role' attributes for each members that is currently an occupant. +
++ The owner MAY then modify the member list. In order to do so, the owner MUST + send the changed items (i.e., only the "delta") to the service; each item MUST + include the 'affiliation' attribute (normally set to a value of "member" or "none") + and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include + the 'role' attribute (which is used to manage game roles in a room): +
++ The service MUST modify the member list and then inform the owner of success: +
++ The service MUST change the affiliation of any affected user. + If the user has been removed from the member list, the service MUST change the user's + affiliation from "member" to "none". + If the user has been added to the member list, the service MUST change the user's affiliation to "member". +
++ If a removed member is currently in a members-only room, the service SHOULD kick + the occupant by changing the removed member's affiliation to "none" and send appropriate + presence to the removed member as previously described. + No matter whether the removed member was in or out of a members-only room, the service MUST + subsequently refuse entry to the user. +
++ For all room types, the service MUST send updated presence from this individual to all occupants, + indicating the change in affiliation by including an <game/> element qualified by the + 'http://jabber.org/protocol/mug' namespace and containing an <item/> child with the + 'affiliation' attribute set to a value of "none". +
++ In addition, the service SHOULD send an invitation to any user who has been added to the + member list of a members-only room if the user is not currently affiliated with the + room, for example as an owner (such a user would by definition not be + in the match; note also that this example includes a password but not a reason -- + both child elements are OPTIONAL): +
++ While only the owner SHOULD be allowed to modify the member list, + an implementation MAY provide a configuration option that opens invitation privileges + to any member of a members-only match. In such a situation, any invitation sent SHOULD + automatically trigger the addition of the invitee to the member list. + However, if invitation privileges are restricted to the owner and a mere member attempts + to a send an invitation, the service MUST deny the invitation request and return a + &forbidden; error to the sender: +
++ Invitations sent through an open room MUST NOT trigger the addition of the invitee + to the member list. +
++ If a user is added to the member list of an open room and the user is in the room, + the service MUST send updated presence from this individual to all occupants, + indicating the change in affiliation by including an <game/> element qualified by + the 'http://jabber.org/protocol/mug' namespace and containing an <item/> + child with the 'affiliation' attribute set to a value of "member". +
++ The room owner may decide to modify the assigned game roles in a room. + To do so, the owner first requests a list of the occupants + and assigned roles by querying the room: +
++ Note: The role 'all' is a reserved name for querying the list of + active players and MUST NOT be redefined by games for other purposes. +
++ The service SHOULD then return the full list of all occupants qualified by + the 'http://jabber.org/protocol/mug#owner' namespace; each item MUST include the + 'role' and 'nick' attributes and MAY include the 'jid' and 'affiliation' attributes for each + occupant in the room. +
++ The service MUST send a &forbidden; error if the owner has not the + required Privileges. +
++ The owner MAY then modify the roles assigned by occupants. + In order to do so, the owner MUST send the changed items (i.e., only the "delta") to the service; + each item MUST include the 'roles' attribute + and 'nick' attribute but SHOULD NOT include the 'jid' attribute and MUST NOT include + the 'affiliation' attribute: +
++ The service MUST modify the roles of the occupants and then inform the owner of success: +
++ The service MUST change the roles of any affected user and + MUST send updated presence to all occupants, + indicating the changed role by including an <game/> element qualified by the + 'http://jabber.org/protocol/mug' namespace and containing an <item/> child with the + 'role' attribute. +
++ The room owner may decide to transfer the ownership to another occupant. +
+OPTIONAL.
+The following guidelines may assist client and component developers in creating MUG implementations.
+ ++ In order to allow supporting multiple games on the service the component + may offer a game plugin interface. +
++ To manage team games, the service should offer game plugins an + API and leave game turn message routing to the game plugins. +
++ In case of loading a room the service SHOULD remember each player's role, + so it can assign the roles properly when the room is loaded. +
++ The game service MAY offer a managed multi-user chatroom. + This can be done by creating a new chat room and keep membership + synchronized with the game room. +
++ In order to respect the users privacy the jabber client SHOULD + hide active matches for discovering as default behavior. + However jabber clients MAY offer a setting to enable the active match discovery. +
++ MUG clients MAY highlight users that participate in a room chat somehow. + The highlighting could be done with a small speech balloon icon behind the players name. +
+OPTIONAL.
+REQUIRED.
+REQUIRED.
++ If this protocol will be accepted by the XMPP Standards Foundation, the ®ISTRAR; + should includes the following information in its registries. +
++ The XMPP Registrar includes the following MUG-related namespaces in its registry of protocol namespaces: +
++ A Multi-User Game service or match is identified by the "game" category + and the "multi-user" type within Service Discovery. +
++ There are many features related to a MUG service or match that can be + discovered by means of Service Discovery. The most fundamental of these + is the 'http://jabber.org/protocol/mug' namespace. In addition, a MUG match + SHOULD provide information about the specific match features it implements, + such as password protection and match moderation. +
++ The "play" querytype is registered as a MUG-related action, with keys of "game" and "password". +
++ The application MUST either present an interface enabling the user to provide a room nickname + or populate the room nickname based on configured preferences or nickname discovery. +
++ If the application doesn't know the game namespace of the room it MUST + query for room information to receive the game namespace. +
++ In order to avoid sending the service discovery query, + the play action SHOULD include the game namespace for the room. +
++ The play action MAY include a password for the room. + Naturally, access to a URI that includes a room password MUST be appropriately controlled. +
++ The following submission registers the "play" querytype. +
+
+ play
+ http://jabber.org/protocol/mug
+ enables joining a multi-user game room
+ XEP-XXXX
+
+
+ game
+ the game namespace required to enter a multi-user game room
+
+
+ password
+ the password required to enter a multi-user game room
+
+
+
+ ]]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+ Simplify Example; Restrict Usage; Add abort
First draft
XMPP uses one XML stream between two peers, either between client and server, between servers, or between clients directly. If a client sends a stanza to a client, either routed over the server or directly, it can not send another stanza at the same time. If an XMPP extension defines very large stanzas, the communication is blocked until this stanza is fully sent to the server. A client or server may also define a maximum stanza size for communication. A future extension to query a remote file server could create such huge stanzas: a directory listing with thousands of photos, each with additional metadata, could produce stanzas of one megabyte or longer. The same is true for TV listings of a remote TV tuner device. Besides text data, a stanza may also contain binary data Base64 encoded. This also increases the stanza size.
+This document defines a mechanism to transmit parts of a stanza over a separate end-to-end connection using Jingle. XML data and binary data (without being Base64 encoded) can be transmitted over the external link to keep the actual XML stanza small.
+If a client wants to send a large stanza to a peer, it can remove large elements from the stanza and replace it with a <oob/> element of the 'urn:xmpp:jingle:apps:out-of-band:0' namespace. The definition of "large" depends on the use case and available bandwidth of the stream to the server. It is RECOMMENDED to send stanzas smaller than 4096 Bytes directly because the overhead of the additional stream is too high. If a client knows in advance that it will send or receive several large stanzas or binary data it SHOULD open the out-of-band data stream. One larger chunk may not be worth opening a Jingle session. A client MUST NOT send In-Band Bytestream stanzas out of band because there may be a reason why it is an In-Band Bytestream and not something else such as SOCKS5.
+Before a client sends such a stanza to its peer, it MUST open the out of band stream first. It has to initiate a Jingle session and MUST NOT send the stanza it wants to send until the out-of-band stream is open. The following example is based on 'Discovering the Items Associated with a Jabber Entity' &xep0030;.
+Normally we would expect the peer to answer with an IQ return stanza with the list of items. But if the listing is very large, the client may decide to send it over an extra stream. Instead of sending the IQ result, it opens a Jingle session.
+The clients open a Jingle session according to &xep0166; with a &xep0260;. For the sake of simplicity this protocol flow is not described here. If the clients opened the Out-of-Band Data Stream, the listing is sent over that stream and a reference is returned in the IQ result of the original request.
+The receiver MUST replace the <oob/> element with the content with the given id from the Out-of-Band Data Stream. The size and hash arguments are optional, the type MUST be 'text/xml' since an IQ stanza MUST have one child element. The content send out of band MUST have a valid XML header <?xml version='1.0' ?> with one root element. The XML header is ignored and the root element MUST replace the <oob> element.
+It is possible to use out of band data everywhere in the XML stream and not only as first element child of the IQ stanza. The XML schema MUST explicit allow the usage of the <oob/> element; it is not possible to replace any arbitrarily part of a stanza with the <oob/> element. The reason for this restriction is to keep implementations simpler if they do not have to expect out of band data everywhere and to keep the stream compliant to the XML schemas.
+If the <oob/> element is not the top level child of an IQ or message stanza, the type attribute does not has to be 'text/xml' and may even be omitted. In that case the content with the given id send out of band MUST be treated as if it was embedded in the XML stream using Base64 encoding. This is useful for sending larger chunks of binary data.
+The Out-of-Band Data Stream multiplexes several items into one stream to re-use the stream for several XML elements or binary data without blocking the out-of-band stream with one large item. This avoids negotiating a new Jingle session for each piece of data. The syntax is similar to HTTP 1.1 chunked transfer. Each chunk of data has a one line header with the number of bytes in hex of the data and the content identifier. The last chunk of each piece of content is always a chunk with a length of 0.
+In the given example the <oob/> element specifies that the query result is sent out of band and has a size of 6022 bytes. The out of band content requires a valid XML header which adds another 23 bytes. If each chunk has 4096 bytes (0x1000 in hex) the data is split into two chunks (4096 and 1949 bytes). The following data is sent over the out of band stream:
+If a client is not not interested in the out of band data (anymore) it MAY abort the sending of a content with a given identifier to save bandwidth. This may happen for large binary data and the client was only interested in the first bytes, e.g. to detect the file type and that it can not decode it.
+The peer SHOULD send a last chunk with the length of zero out of band and acknowledge the abortion.
+The Jingle session SHOULD include TLS as specified in &xtls;. Even if the peers can not verify each others certificates, the leap of faith approach provides at least the same amount of security as if the data where send inside the XML stream.
+This document requires no interaction with &IANA;.
+XMPP Registrar considerations will be provided in a later version of + this document.
+The XML schema will be provided in a later version of this document.
+First draft.
As XMPP technologies have been deployed more widely, the open XMPP network has become a more significant target for attacks. This specification defines ways for XMPP server deployments to share information with each other and therefore handle such attacks in a more real-time fashion.
+The basic approach is two-fold:
+To establish a trust relationship with a peer, a server shall send a presence subscription request to the peer, just as is done between XMPP users.
+The XMPP server software running at the peer MUST prompt the server administrators to approve the request. Methods for doing so are out of scope for this specification.
+A problem report consists of an XMPP &MESSAGE; stanza containing a <problem/> child element. The following is an example.
+The defined child elements are as follows:
+| Element Name | +Description | +
|---|---|
| <contact/> | +The JID of a person to contact directly. | +
| <end/> | +The time when the problem ended. Send empty element if still happening. Must conform to &xep0082; | +
| <incident/> | +An incident number. MUST be a UUID as described in &rfc4122;. | +
| <ip/> | +The IP address where the problem originates. | +
| <jids/> | +Each <jid/> child contains the JabberID of an entity that is causing trouble. | +
| <room/> | +A chatroom where the problem can be discussed. | +
| <severity/> | +The seriousness of the problem, from 5 (least serious) to 1 (most serious). | +
| <start/> | +The time when the problem started. Send empty element if unknown. | +
| <text/> | +A natural-language description of the event. This element SHOULD possess an 'xml:lang' attribute. Multiple <text/> elements MAY be included, each with a different 'xml:lang' value. | +
| <type/> | +The type of problem. Defined values are "muc" for &xep0045; abuse, "pubsub" for &xep0060; abuse, "reg" for account registrations (e.g., via &xep0077;), "spam" for | +
To follow.
+To follow.
+To follow.
+To follow.
+First draft.
Reputation systems are used in many online communities to increase trust and to encourage communication, commerce, and other forms of interaction. The public XMPP network might benefit from instituting a reputation system for servers, for end users, or both. The benefits might include fast blacklisting of rogue servers and other bad actors, differential quality of service based on reputation, delayed entry to &xep0045; rooms for low-reputation users, integration with &xep0016;, and the like.
+The following terms identify the entities mentioned in this document:
+The approach taken here is that an XMPP entity (a "Subject") is innocent until proven guilty, so it starts out with a score of zero. Good behaviors will increase a Subject's score (up to a maximum of +127), whereas bad behaviors will decrease a Subject's score (potentially down to a minimum of -128). Any entity (a "Relying Party") can query another entity (a "Vouching Party") about the reputation score of a Subject. A Vouching Party might be a fellow IM user (e.g., a buddy in one's roster as defined in &xmppim;), the server to which a client connects, a fellow server to which a server connects (see &xep0267;), or a specialized reputation service (similar to a DNSBL on the email network). Changes in reputation scores can also be sent in real time to Relying Parties, either as part of &xep0268; or as separate notifications.
+To determine reputation in an objective way, it is important to define the specific behaviors that are used as measurable dimensions of good or bad reputation. The following sections attempt to do so for XMPP servers and XMPP users, with some rough point values.
+On the theory that it is more important to reward positive behavior than to punish negative behavior, we first define a number of criteria for increasing the reputation score of an XMPP server (naturally this list of criteria is not meant to be exclusive).
+| Criterion | +Suggested Point Value | +
|---|---|
| Presents a certificate issued by a recognized certification authority. | ++15 | +
| Requires CAPTCHAs or other hurdles for account registration (see &xep0158;). | ++5 | +
| Supports XEP-0268: Incident Reporting. | ++5 | +
| Supports reputation scores for its users (i.e., this protocol). | ++5 | +
| Requires use of Transport Layer Security (TLS) for client-to-server connections. | ++5 | +
| Provides the _xmpp-client DNS SRV record. | ++5 | +
| Provides the _xmpp-server DNS SRV record. | ++5 | +
| Provides a website with accurate information and contact addresses. | ++5 | +
| Service answers &xep0030; information requests sent to bare JIDs, including identification of admin accounts and anonymous users. | ++5 | +
| Administrator answers email sent to mailto:xmpp@domain.tld (see &xmppcore;) and takes appropriate actions to solve reported issues. | ++5 | +
| Time online (e.g., based on whois lookup or known deployment of an XMPP service). | ++3 for each year | +
| Admin factor (average of admins' reputation scores, divided by ten and rounded up). | +Varies | +
For example, a server that (1) meets all of the foregoing criteria, (2) has been online for 7 years, and (3) whose admins have an average score of 37 would have a reputation number of 15+5+5+5+5+5+5+5+5+5+4+21 = 85.
+By constrast, a server that does not have a CA-issued cert, does not require CAPTCHAs for account registration, does not support incident reporting, does not support reputation scores, does not require TLS, does have SRV records (+10), has no website, does not answer service discovery requests about its users, has not verified the xmpp@domain.tld email address, has been online for 1 week, and whose administrators are unknown would have a reputation score of 10.
+The reputation associated with an XMPP account (typically but not always a user) is harder to quantify and easier to fake than server reputation. The following are some possible criteria.
+| Criterion | +Suggested Point Value | +
|---|---|
| Account has service discovery identity of account/admin | ++15 | +
| Account has service discovery identity of account/registered | ++5 | +
| Age of account | ++5 for each year | +
| Verified email address | ++5 | +
| Verified website | ++5 | +
| Password strength | +Measured on a scale from 0 (e.g., "password") to 5 | +
| Reputation of buddies known to server | +Divide average reputation by 10 | +
| User has PGP key, X.509 certificate, or other public key | ++10 | +
| User has passed a CAPTCHA test (e.g., during account provisioning) | ++5 | +
| Chatroom ownership / administration | +For each room owned, divide room's reputation by 10; for each room administered, divide room's reputation by 20 (e.g., +6 and +3 for a room with a reputation of 60). | +
| Chatroom banning | +For each room in which the user is banned (XEP-0045 "outcast"), divide the room's reputation by 10 and decrement the user's score by the result (e.g., -6 for a room with a reputation of 60). | +
| Rate limiting | +For each rate limiting incident, -5. | +
| Incident reports | +For each validated incident report, -10. | +
For example, an account that is an admin of a server (+15), has been online for 5 years (+25), has a verified email address (+5) and website (+5), has a strong password (+5), has a "buddy reputation average" of 40 (+4), uses a public key (+10), has passed a CAPTCHA test (+5), owns 3 chatrooms with an average reputation of 30 (+9), and has not been banned from any chatrooms, rate limited, or been the subject of any incident reports would have a reputation number of 83.
+By contrast, an account that is registered (+5), was just created, has no verified email address or website, has a strong password (+5), has a "buddy reputation average" of 10 (+1), does not use a public key, has not passed a CAPTCHA test, owns or administers no chatrooms, has been banned from 3 chatrooms with an average reputation of 30 (-9), has been rate limited twice (-10), and has been the subject of 2 incident reports (-20) would have a reputation number of -28.
+Any entity can have a reputation score: servers, end-user accounts, chatrooms, chatroom servers, publish-subscribe servers, vouching services, etc. Criteria for entities other than servers and accounts are yet to be described.
+In order to query a Vouching Party about the reputation of a Subject, a Relying Party sends an IQ stanza of type "get" containing a <score/> element qualified by the 'urn:xmpp:reputation:0' namespace &VNOTE;.
+The Vouching Party would then return an error or a score.
+Any XMPP error might be appropriate (e.g., &forbidden; if the Relying Party is not trusted at all by the Vouching Party).
+To advertise its support for reputation scores, when replying to &xep0030; information requests an entity MUST return a feature for 'urn:xmpp:reputation:0'.
+In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
+Any entity can keep a reputation score for any other entity. Although some entities might be considered more knowledgeable than others, that judgment is up to the entity that makes a request for a reputation score and is not a feature of the network itself.
+This document requires no interaction with &IANA;.
+To follow.
+To follow.
+Thanks to Dan Brickley, Kevin Smith, Mike Taylor, and Matthew Wild for their feedback.
+First draft, split from the incident reporting proposal.
In XMPP, rosters and presence subscriptions have been used to date only among IM users (see &xmppim;). However, nothing prevents the application of these concepts to other XMPP entities, such as components and servers. Given that a presence subscription typically indicates some level of trust in a peer, server deployments can use the sharing of XMPP presence information as a way to indicate that a given server has a trust relationship with a peer server. The server might then share certain kinds of additional information only with trusted peers (for example, incident reports).
+To establish a trust relationship with a peer, a server shall send a presence subscription request to the peer, just as is done between XMPP users.
+A server MUST NOT send such a presence subscription request unless explicitly requested to do so by the server administrator(s).
+Upon receiving such a presence subscription request, the XMPP server software running at the peer MUST prompt the server administrator(s) to approve the request, rather than automatically approving it. Methods for doing so are out of scope for this specification.
+If the server administrator(s) approve the request, the peer server shall then inform the originating server that the request has been approved.
+The peer SHOULD also send a subscription request to the originating server.
+If an XMPP server implementation supports this usage of presence subscriptions, it MUST keep a list of approved entities, which we denote a "server roster". The implementation MAY use that roster for access control purposes defined in other specifications.
+To follow.
+This document requires no interaction with &IANA;.
+First draft.
XMPP-powered applications which run inside of Web browsers typically use &xep0124; to create a link to an XMPP server. Unfortunately Web applications do not have control over some interactions, such as a user opening a link in a new tab. This means that an application can end up with multiple simultaneous BOSH connections, each of which is a fully addressable XMPP endpoint. Complex applications often need to share some state, and managing this over an arbitrary number of individual connections can be problematic.
+This specification defines a mechanism for a connection manager to allow multiple clients to share the same underlying XMPP connection. Additionally, the connection manager will notify all clients of inbound stanzas. Similar functionality exists in specific areas of the XMPP protocol; for example, roster changes are broadcast to all connected resources so each resource can keep roster state synchronized.
+As an example, consider an application which is open in two tabs (or two windows) in a Web browser. In the first tab, the application subscribes to some pubsub node it is interested in. The BOSH connection manager would send this subscription request to the other connected clients (in this case, just the second tab) so that they are aware that a subscription has been requested. When the subscription acknowledgement is received by the connection manager, it will broadcast it to all clients.
+Shared BOSH must meet the following requirements:
+In addition to these, the intention is for this extension to be easy to implement in current BOSH implementations.
+In order to establish a sharable connection which is then shared across two clients, the following steps take place. The mechanism for sharing the secret below is just one possible mechanism.
+A client can create a sharable BOSH connection by providing the 'shared:key' attribue to the connection manager in the initial <body/> element.
+ +If the connection manager supports sharable connections, it will include the 'shared:result' attribute in its response. Since this is a new sharable connection and not an attachment to an existing sharable connection, the value of the 'shared:result' attribute is 'created'.
+ +If the connection manager does not support this extension, it will ignore the 'shared:key' attribute and will not include one in its response.
+Attaching to a connection is performed in the same manner as creating a sharable connection. The client provides the secret key of an existing connection as the value of the 'shared:key' attribute. If the key matches, the connection manager will respond with a 'shared:result' attribute with a value of 'attached'.
+In order to easily maintain state across shared BOSH clients, the connection manager must deliver inbound traffic to the server from one client to all the other clients sharing the connection. Applications which use shared connections must be written so that they can deal with this extra traffic; they cannot assume that all stanzas received are outbound.
+In order to protect against unauthorized or unintended connection sharing, this specification uses a shared secret. It is important that this secret be hard to guess and long enough that it is resistant to brute force attack.
+It is necessary for a client to communicate the shared secret to the other clients. Since Web browser security policy prevents most ways of achieving this, it is necessary to store the secret somewhere the other clients can find this. Implementors must be care that this storage is robust to attack.
+Two options are recommended for secret storage:
+Generate the secret on the server side (for example, in the Web application framework that generates your HTML pages). Please note that the secret should not be transmitted alongside the HTML as this would allow anyone reading the HTML to share the connection. Instead, the BOSH connection should be bootstrapped before page delivery.
Generate the secret on the client side, and store it within the XMPP server using some available mechanism. For example, a client could use &xep0049; or a private &xep0163; node.
This document requires no interaction with &IANA;.
+This XEP proposes the namespace 'urn:xmpp:tmp:shared-bosh:0' be added to the registry.
+To follow.
+Removed client inclusion of its IP address; added IPv6 example.
First draft.
There are times when a client might want or need to discover what its external Internet Protocol (IP) address is, e.g. when gathering transport candidates for &xep0065; or &xep0176;. One way to do so is for the client to ask the XMPP server to which it has connected. This simple specification defines such a method.
+First the client sends an IQ-get request to its server.
+The server then returns an IQ-result containing an <ip/> element whose XML character data specifies the client's IP address according to the server.
+The IP address could be IPv4 or IPv6.
+If an entity supports this protocol, it MUST report that by including a service discovery feature of "urn:xmpp:sic:0" in response to disco#info requests &NSNOTE;.
+&rfc3920; specifies that client IP addresses shall not be made public. If a client requests its own IP address, that policy is not violated. However, a server MUST NOT return the IP address of another client (e.g., if a connected client sends a SIC request to the bare JID of another user); instead, it MUST return a &forbidden; error.
+This document requires no interaction with &IANA;.
+This specification defines the following XML namespace:
+Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.
+
+
+
+
+
+ ]]>
+Thanks to Thiago Camargo and Diana Cionoiu for their prodding to define this extension.
+Clarified service and feature discovery processes, error flows, and other small matters in the text.
Defined IQ-get for retrieving supported SIFT features; added support for sifting based on sender type; removed restriction on matching against only the bare JID of the recipient and defined support for sifting on the bare JID, full JID, or both.
Added requirements section; clarified relation to negative presence priorities.
More clearly distinguished between interception and filtering usages; clarified business rules.
Added information about service discovery; clarified several small matters in the text.
Clarified that SIFT applies to interception of message and presence stanzas directed to the bare JID and to filtering of IQ stanzas directed to the full JID; corrected syntax to match those semantics; added use cases; defined XML schema.
Slight clarifications and corrections.
First draft.
In some scenarios a client might want to control the XML stanzas it will receive over its stream with the server. Some potential use cases include:
+The following taxonomy of client types is not exhaustive but might assist developers in understanding the scenarios in which SIFT might be useful.
+| Type | +Sends Presence | +Receives Presence | +Receives Messages | +
|---|---|---|---|
| Normal User | +Yes | +Yes | +Yes | +
| Invisible User | +No | +Yes | +Yes | +
| Large-Scale Bot | +Yes | +No | +Yes | +
| Presentity | +Yes | +Yes | +No | +
| Presence Watcher | +No | +Yes | +No | +
| Presence Publisher | +Yes | +No | +No | +
| Message Subscriber | +No | +No | +Yes | +
| Message Publisher | +No | +No | +No | +
Note: Although &rfc3921; specifies the use of a negative presence priority to block inbound message delivery, it does not enable the client to block inbound presence notifications, filter inbound IQ stanzas, or otherwise exercise fine-grained control over the delivery of inbound stanzas. While it would be possible to define particular values of negative presence priorities for some delivery control methods (e.g., <priority>-2<priority> could be hardcoded to mean "don't send me messages or presence"), that would be an ugly hack and thus inconsistent with &xep0134;. Therefore, this specification defines a stanza interception and filtering technology (a.k.a. "SIFT") that is more consistent with the underlying design of XMPP.
+The SIFT protocol is designed to meet the following requirements.
+The SIFT protocol is used to intercept or filter inbound stanzas only, not outbound stanzas sent by the client to the server or other entities. By "intercept" is meant that the server will not deliver any such stanza kind (message, presence, or IQ) to the client, and by "filter" is meant that the server will apply a rule to determine if the specific stanza will be delivered to the client (e.g., matching against a payload namespace); in general we refer to these actions as "sifting". The SIFT protocol enables the server to support only basic interception (even here to support interception only for particular kinds of stanzas), basic filtering as defined by the rules described in this specification, or advanced filtering using extensions to SIFT defined in other specifications. Each of the features supported by the server can be discovered by the client for maximum interoperability. The features, the process for discovering them, and the process for enabling them are described in the following sections.
+SIFT supports the following features.
+A server MAY support any combination of sifting IQ, message, or presence stanzas. For each kind of stanza that can be sifted, the server shall include in the features discovery result an <iq-sift/>, <message-sift/>, or <presence-sift/> element, respectively.
+A server MAY enable the client to sift based on sender. The following values are supported.
+These values are child elements of the <iq-sift/>, <message-sift/>, and <presence-sift/> elements when the server returns a features discovery result, whereas they are values of the 'sender' attribute when the client enables sift support.
+A server MAY enable the client to filter based on recipient. The following values are supported.
+These values are child elements of the <iq-sift/>, <message-sift/>, and <presence-sift/> elements when the server returns a features discovery result, whereas they are values of the 'recipient' attribute when the client enables sift support.
+A server MAY enable the client to sift based on the XML namespace and element name of the payload(s) that the client allows for delivery. If so, the server shall include in the features discovery result an <allow/> element for the relevant kind of stanza.
+A server could match based on more complex criteria, e.g. Regular Expressions or XPath Expressions; such functionality is implicitly allowed because the XML schema specifies the <xs:any/> notation, but any such advanced matching shall be defined in separate specifications.
+If a server supports the SIFT protocol, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:sift:1":
+This response enables the client to know that the server supports SIFT in general, but particular SIFT features. In order to discover which SIFT features are supported, a client sends an IQ-get containing a <features/> element qualified by the 'urn:xmpp:sift:1' namespace.
+The server then returns a list of the particular SIFT features it supports.
+The foregoing IQ-result indicates that montague.net supports only message and presence sifting, allows the client to filter those kinds of stanzas only from all entities or from other entities (but not from local entities, remote entities, or itself), allows the client to filter those kinds of stanzas only to both the bare JID and full JID (but not to the bare JID or the full JID alone), and does not support filtering based on payload.
+Naturally, the server could return the typical XMPP error conditions, such as &unavailable; if the server does not support the SIFT protocol or the version specified by the client.
+To enable sifting of stanzas, the client sends an IQ-set to the server containing a <sift/> child element that in turn contains an <iq/> element, a <message/> element, a <presence/> element, or some combination of those elements. Each of these elements MAY include a 'recipient' attribute whose value is "all", "bare", or "full" (defaulting to "all"). Each of these elements MAY also include a 'sender' attribute whose value is "all", "local", "others", "remote", or "self" (defaulting to "all").
+Note: The last SIFT request sent from the client to the server overrides all previous SIFT requests; SIFT requests are not cumulative. Therefore, each SIFT request needs to contain all the SIFT rules that the client wishes the server to enforce, not a delta from the previous request.
+The foregoing IQ-set means "sift messages from others and presence from all senders, no matter if the recipient is my bare JID or my full JID".
+Each of the child elements &IQ;, &MESSAGE;, and &PRESENCE; MAY also contain one or more <allow/> children whose 'name' attribute specifies the element name and whose 'ns' attribute specifies the XML namespace of stanza payloads the client would like to allow. If no <allow/> elements are included, then sifting of that kind of stanza is completed without reference to the payload.
+The foregoing IQ-set means "filter out inbound IQ stanzas except if the payload matches <jingle xmlns='urn:xmpp:jingle:1'/> or <query xmlns='http://jabber.org/protocol/disco#info'/>".
+In XMPP, an IQ stanza can contain only one payload element, so the filtering logic is straightforward. However, a message or presence stanza can contain multiple payload elements (cf. &xep0226;). Therefore, filtering for message and presence stanzas means that if the stanza contains the defined payload or payloads (perhaps in addition to other payloads), the server shall deliver it to the client.
+For instance, the following example shows how a client would filter inbound messages and IQs to only receive SOAP payloads as specified in &xep0072;.
+Similarly, the following example shows how a client would filter inbound presence notifications to only receive notifications that contain entity capabilities data as specified in &xep0115;.
+Naturally, the server could return the typical XMPP error conditions, such as &unavailable; if the server does not support the SIFT protocol or the version specified by the client, &feature; if the server does not support a particular feature (e.g., &IQ; sifting) requested by the client, &badrequest; if the request is malformed, &internalserver; if the server experiences a malfunction while attempting to process the request, and so on.
+When the client indicates that it wishes to receive inbound presence notifications, the server SHOULD send outbound presence probes on the client's behalf. Responses to these presence probes are addressed to the bare JID of the account and then broadcasted to all of the resources that have expressed interest in receiving inbound presence notifications.
+If the client subsequently indicates that it wants the server to intercept inbound presence notifications, the server MUST NOT deliver to the client presence notifications that are addressed to the bare JID or full JID as defined by the 'recipient' attribute.
+If the client then indicates again that it wishes to receive inbound presence notifications, the server shall resynchronize the client regarding the presence states of its contacts (how it does so is implementation-specific, e.g. whether it queues received presence notifications or re-probes the user's contacts).
+When a client indicates that it wishes to receive messages, the server SHOULD deliver to the client all messages in the offline message queue and MUST deliver to the client any subsequent messages that would normally be delivered to the client in accordance with the rules defined in &xmppcore; and &xmppim;.
+If the client subsequently indicates that it wants the server to intercept inbound messages (and there are no other connected or available resources that have expressed interest in receiving inbound messages), the server SHOULD treat messages as if there were no connected or available resources (e.g., storing them offline for later delivery); if the client then indicates again that it wishes to receive inbound messages, the server SHOULD send those queued messages to the client so that it can get back in sync regarding messages received from its contacts.
+If the client does not request filtering of inbound IQ stanzas, the server MUST pass through to the client all IQ stanzas that are addressed to the full JID of the client (subject to appropriate security controls as defined in the relevant RFCs and XEPs).
+If the client requests filtering of inbound IQ stanzas, for unfiltered payload name+namespace combinations the server MUST pass through to the client all IQ stanzas that are addressed to the full JID of the client (subject to appropriate security controls as defined in the relevant RFCs and XEPs), whereas for filtered payload name+namespace combinations the server MUST respond to all IQ stanzas in a way consistent with the specification for the given payload namespace (if defined) or as specified in &xmppcore; and &xmppim; for IQs where no full JID &LOCALFULL; matches; typically that means returning a &unavailable; error.
+Naturally, if the server advertises support for the SIFT protocol but the client does not send any IQ-set stanzas containing SIFT payloads, the server MUST proceed as it normally would in accordance with the core XMPP specifications.
+In order to be invisible at the start of a session, a client can register for (i.e., not request interception of) inbound messages and presence notifications without sending initial presence.
+The server would then probe the user's contacts and return the resulting presence notifications to the client, as well as allow inbound message and IQ stanzas.
+If the user wants to "go visible", the client will send initial presence.
+The user can later go invisible again by sending presence of type "unavailable" without modifying the SIFT rules or closing the stream.
+RFC 3921 defines the concept of negative values for the presence <priority/> element, where a negative value instructs the server to not deliver to the client any messages that are directed to the bare JID of the user. This behavior can be emulated using SIFT by asking the server to intercept inbound message stanzas for the bare JID, but not presence notifications or IQ stanzas.
+If a client requests message sifting, but sends presence, it SHOULD specify a negative priority as a hint to contacts.
+Because inbound presence notifications can be "chatty", mobile clients and other entities with limited battery life might want to "hush" the presence session by asking the server to intercept inbound presence notifications but not message stanzas.
+To follow.
+This document requires no interaction with &IANA;.
+This specification defines the following XML namespace:
+Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+The authors wish to acknowledge feedback received from Dave Cridland, Jack Erwin, Waqas Hussein, Craig Kaes, Dirk Meyer, Robert Quattlebaum, Mike Taylor, Matthew Wild, and Jiří Zárevúcký, as well as from the participants at XMPP Summit 7 on July 20-21, 2009.
+Updated Jingle namespaces, transport definitions, reason codes, and other syntax; improved feature discovery and session advertisement; updated namespace to be urn:xmpp:sxe:0 for future-compatibility.
Added session signalling via presence.
Wording changes. Changes to how set content/move element conflict is handled.
Initial version of the SXdE proposal after splitting the previous whiteboarding proposal.
Initial version.
This specification defines a protocol for collaboratively editing XML data. Essentially, this protocol provides a simple way of synchronizing an unordered set of records across several endpoints. Additionally, this protocol defines a mapping between such a set of records and the Document Object Model (DOM).
+A special feature of this protocol compared to most other collaborative editing tools is that no master or server entity is required. A &xep0045; component or specialized editing component can be used for sessions that have a large number of participants, that need to be persistent, or that require more granular access control. However, the client implementation is minimally different whether such a specialized component is used or whether the session is one-to-one or multi-user.
+Requirements for shared editing are provided in &xep0228;.
+GUID: a Globally Unique Indentifier, used as the identifier for a shared editing session.
+Host: The JID to which the SXE messages are sent for relaying to other members of the session; this can be the initiator of the session (e.g., in a one-to-one session or small multi-user session) or a multi-user chat room or specialized shared editing component.
+RID: the Record ID given to a record when it is created.
+State: In the context of a new user joining, the state refers to the set of records that describes the edited object, including all previous versions of each record. All entities involved in the session are REQUIRED to keep this state unless a specialized component handles user joins.
+Weight: Primarily, the weight of a node is represented by the 'primary-weight' field of the corresponding record. Secondarily, if the values of the 'primary-weight' of two records are equal, the first differing characters of the rids are compared by their Unicode values. The higher the character the higher the weight of the node is.
+When used in the context of XMPP, Shared XML Editing relies on &xep0166; for overall session management. In Jingle terms, SXE defines a "transport method" that can be used for multiple "application types" such as XHTML documents, SVG whiteboards, &xep0204;, or any other XML data format.
+In order to initiate a shared editing session, one party sends a Jingle session-initiate request to another party. Here the <transport/> element indicates support for exchanging SXE information over XMPP and the <description/> element indicates support for editing of XHTML documents (this application type has not been defined yet and is used here only as an example). The <transport/> element MUST include at least one <host/> element that specifies the entity that serves as the host for the session. The host can be the initiator of the session (and must be for a one-to-one session) or a multi-user chat room or specialized reflector where the session is hosted.
+The responder immediately acknowledges receipt of the session-initiate.
+In order to definitively accept the session, the responder sends a session-accept to the initiator.
+The initiator immediately acknowledges receipt of the session-accept.
+In order to decline the session, the responder sends a session-terminate to the initiator.
+The responder indiciates the reason for refusing the session by including a "reason" element. The following reasons are suggested (see also XEP-0166):
+The initiator immediately acknowledges receipt of the session-terminate.
+Before connecting to a session, a party MUST determine the &xep0030; identity and supported features of the host. In many situations the party already knows this information (e.g., if the host is the initiator of the Jingle session). In other situations the party will need to send a service discovery information request to the host.
+If the host supports Shared XML Editing over XMPP, it MUST return features of "urn:xmpp:sxe:0" and "urn:xmpp:jingle:transports:sxe" &NSNOTE;:
+An entity that is engaged in a session can advertise that fact by including the session id and descriptive name in its XMPP presence.
+Such presence can be broadcast or can be sent in the context of a multi-user chat room (see XEP-0045).
+However, presence is not sent when operating in a serverless messaging environment (see XEP-0174). Instead, DNS TXT records are published. Two new key-value pairs are used to advertise a session id ("sxe_id") and session name ("sxe_name") when using serverless messaging.
+In order to synchronize its local state with the existing state of the edited object, an entity sends a connection request to the host. The identity learned through service discovery determines what kind of message the joining party sends (e.g., type='groupchat' if the host is a MUC room).
+To connect to a session, the joiner MUST send an SXE <connect/> element to the host.
+When a joining user sends a connect request, the joiner must retrieve the state of the session from an existing participant. The following ruules apply:
+The state offer MUST contain the <description/> element or elements that were included in the Jingle session-initiate request.
+The joiner accepts a state offer by sending an <accept-state/> element to one of the entities that offer to send the state. The joiner MUST store all the <sxe/> elements it receives after the <state-offer/> element it decides to accept. It MUST also abort the negotiation with the other users that offered to send the state.
+Once the other entity receives the <accept-state/> element it MUST proceed sending the state as described in the next section.
+If a multiple state offers were received, one should be accepted and the others should be refused by sending a <refuse-state/> element.
+The process of sending the state is following:
+The state can be sent in any number of <sxe/> elements but the user sending the state MUST NOT send any new <sxe/> elements between sending the <document-begin/> (i.e. taking the snapshot) and the <document-end/> element.
+The state SHOULD include a version of each element that was synchronized, and hence won't be undone, as well as all the later versions. In practice this can often be impossible to know in a session without a specialized MUC component so it may be safest to send version 0 and all the later edits to each element. Version 0 is implied if the version element is missing.
+If the session is already in progress, the entity sends the snapshot.
+Once a participant has received initial state, he can participate in the editing session.
+Here is another edit in the session.
+This basic editing session results in the following XML.
+It's good to be the king!
+It certainly is!
+ + + ]]>All SXE elements MUST be contained in a <sxe/> element. This element MUST posess the following attributes:
+| Attribute | +Description | +
|---|---|
| xmlns | +REQUIRED and MUST be "urn:xmpp:sxe:0" | +
| session | +REQUIRED and MUST be a GUID of the session. | +
| id | +REQUIRED and MUST be unique within the set of <sxe/> elements sent by the user to the session. | +
The prolog of the XML document cannot be edited after the session has been established.
+If an XML Schema Definition is specified for the document and the processing of an <sxe/> element results in a noncompliant document, the receiving client SHOULD reply with edits that effectively undo the offending edits. TODO: the offending client should probably be notified.
+A record contains the following fields and corresponds to a single DOM node:
+| Field Name | +Mutable | +Applies to nodes of type | +Description | +
|---|---|---|---|
| rid | +no | +all | +The GUID of the record. | +
| type | +no | +all | +The type of DOM node (element, attr, etc.). | +
| version | +Indirectly | +all | +The current version of the record. | +
| parent | +yes | +all | +The record id of the record corresponding to the parent node. | +
| primary-weight | +yes | +all | +The primary weight used to determine the order of sibling nodes corresponding to the records. | +
| ns | +yes (TODO: is this reasonable?) | +element, attr | +The namespace of the element or attribute | +
| name | +yes (TODO: is this reasonable?) | +element, attr | +The name of the element or attribute. | +
| chdata | +yes | +text, attr, comment | +The content of a text node or a comment or the value of the attribute. | +
| pitarget | +yes (TODO: is this reasonable?) | +proccessinginstruction | +The target of the processing instruction. | +
| pidata | +yes | +proccessinginstruction | +The data of the processing instruction. | +
Whenever a record is added, modified, or removed, the client MUST ensure that the DOM nodes corresponding to the records meet the following criteria:
+| rid | +type | +version | +parent | +primary-weight | +ns | +name | +chdata | +pitarget | +pidata | +
|---|---|---|---|---|---|---|---|---|---|
| GUID0 | +element | +0 | ++ | 0 | +http://www.w3.org/2000/svg | +svg | +N/A | +N/A | +N/A | +
| GUID1 | +element | +0 | +GUID0 | +0 | ++ | path | +N/A | +N/A | +N/A | +
| GUID2 | +attr | +0 | +GUID1 | +0 | ++ | d | +M10 10L20 20L20 10Z | +N/A | +N/A | +
| GUID9 | +element | +0 | +GUID0 | +3.4 | ++ | g | +N/A | +N/A | +N/A | +
| GUID5 | +element | +0 | +GUID0 | +3.4 | ++ | circle | +N/A | +N/A | +N/A | +
| GUID6 | +attr | +3 | +GUID5 | +0 | ++ | cx | +10 | +N/A | +N/A | +
| GUID7 | +attr | +1 | +GUID5 | +1 | ++ | cy | +20 | +N/A | +N/A | +
| GUID8 | +attr | +0 | +GUID5 | +2 | ++ | r | +5 | +N/A | +N/A | +
Changes to the records can be divided into two categories: commutative and non-commutative edits.
+Commutative edits are commutative with all edits and are never "undone" so keeping a history of them is NOT REQUIRED. Edits that add or remove records are commutative.
+An edit that changes an existing record is called non-commutative because it may not be commutative with edits that change the same record. Hence these changes may need to be undone so keeping a history of the changes caused by such edits is REQUIRED. The breadth of this required history depends on the role of the entity and on whether the session works through a server component:
+| + | By server | +By client | +
|---|---|---|
| Server exists | +All non-commutative edits, that have not been undone to records that have not been removed; must store the creator and last modifier of each node (to be included as 'creator' and 'last-modified-by' attributes in <new/> elements sent to joining clients). | +Non-commutative edits sent by the client itself. May be removed once a further non-commutative edits to the same record from another entity is received. | +
| Server does not exists | +--- | +All non-commutative edits, that have not been undone, to records that have not been removed. | +
The server MUST apply commutatative edits to its local copy like a client and pass on the edits without changes.
+The server component intercepts and modifies non-commutative edits in order to reduce the history requirements of the clients as indicated above. Once it receives a non-commutative edit, it MUST take the following action depending on whether the version number of the edit is "in-order" (one higher than the current version) or "out-of-order":
+A client can add a new node to the document by adding a record with the <new/> element.
+ +| Attribute | +Description | +
|---|---|
| rid | +REQUIRED. MUST be a GUID. | +
| version | +OPTIONAL. MUST be a non-negative integer. Assumed to be 0 if not present. | +
| parent | +REQUIRED (Except at top level.) | +
| primary-weight | +OPTIONAL. MUST be a float. Assumed to be 0 if not present. | +
| type | +REQUIRED. MUST be 'element', 'attr', 'text', 'comment', or 'processinginstruction' | +
| ns | +OPTIONAL if 'type' is 'element' or 'attr'. Not allowed otherwise. | +
| name | +REQUIRED if 'type' is 'element' or 'attr'. Not allowed otherwise. | +
| chdata | +REQUIRED if 'type' is 'attr', 'text', or 'comment'. Not allowed otherwise. | +
| pitarget | +REQUIRED if 'type' is 'processinginstruction'. Not allowed otherwise. | +
| pidata | +REQUIRED if 'type' is 'processinginstruction'. Not allowed otherwise. | +
| creator | +OPTIONAL. MUST be the JID or room nick of the creator of the node. | +
| last-modified-by | +OPTIONAL. MUST be the JID or room nick of the user who last modified the node. | +
To process a <new/> element the client MUST create a new record with the values of the attributes stored in the corresponding fields.
+A client can remove any node in the document by removing the corresponding record with the <remove/> element.
+ +| Attribute | +Description | +
|---|---|
| target | +REQUIRED and MUST be the record id of the node to be removed. | +
A client MUST NOT send a <remove/> element that removes a node that has child nodes without explicitly removing the records of those nodes first.
+ +To processes a <remove/> element the client MUST remove the record specified by the 'target' attribute.
+If the node corresponding to the target record has child nodes, the receiver MUST send <remove/> elements for each of them as described above.
+The <set/> element is used to modify an existing record.
+ +| Attribute | +Description | +
|---|---|
| target | +REQUIRED and MUST be the record id of the node being modified. | +
| version | +REQUIRED and MUST be the current version of the node incremented by one. | +
| parent | +OPTIONAL. | +
| primary-weight | +OPTIONAL. | +
| ns | +OPTIONAL but only allowed if the target record is of type 'element' or 'attr'. | +
| name | +OPTIONAL but only allowed if the target record is of type 'element' or 'attr'. | +
| chdata | +OPTIONAL but only allowed if the target node is of type 'attr', 'text', or 'comment'. | +
| pitarget | +OPTIONAL but only allowed if the target record is of type 'processinginstruction'. | +
| pidata | +OPTIONAL but only allowed if the target record is of type 'processinginstruction'. | +
| replacefrom | +replace from position. OPTIONAL but only allowed if 'chdata' and 'replacen' attributes are also included. MUST be a non-negative integer. | +
| replacen | +replace n characters. OPTIONAL but only allowed if 'chdata' and 'replacefrom' attributes are also included. MUST be a non-negative integer. | +
To processes a <set/> element the client MUST follow the following steps:
+If the version of of the target record is now equal to the 'version' attribute of the <set/> element, the client MUST store the values of the attributes of the <set/> element as updated values of the corresponding fields in the record. The only exception occurs when 'chdata', 'replacefrom', and 'replacen' are specified: in that case, n characters starting from the f'th character of the existing 'chdata' field MUST be replaced by c, where n, f, and c are the values of the 'replacen', 'replacefrom', and 'chdata' attributes respectively.
+Otherwise all fields of the record, except for the 'version' field, must be reverted to version (v - 1), where v is the value of the 'version' attribute of the received <set/> element.
+It should be noted that given the MUC specification and the requirement of this protocol to send a connect request message to all room members in order to join an existing session, you effectively can not use the visitor role of MUC with a regular MUC server component. However, the specialized MUC component, if used, MUST accept and respond to the connection requests even if they come from users who do not have voice in the room.
+To follow.
+This XEP requires no interaction with &IANA;.
+Until this specification advances to a status of Draft, its associated namespaces shall be:
+Upon advancement of this specification, the ®ISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.
+The following namespaces are requested, and are thought to be unique per the XMPP Registrar's requirements:
+The ®ISTRAR; shall add the type of "sxe" to the "collaboration" category in its registry of service discovery identities.
+The XMPP Registrar shall include "sxe" in its registry of Jingle transport methods. The registry submission is as follows:
+
+ sxe
+ A method for exchanging Shared XML Editing data over XMPP.
+ reliable
+ XEP-xxxx
+
+ ]]>
+ To follow.
+The theory behind the synchronization of an individual entity (a record) was put forward by Mats Bengtsson (http://coccinella.sourceforge.net/docs/MemoSyncSVG-XMPP.txt). He also provided other input that helped form this XEP. Thanks to Dmitriy Chervov for his feedback based on implementation experience.
+Split use-case section into "Introduction", "Requirements", and "Use case".
+Removed service disovery. +Added missing namespace on thumnail elements.
+First draft.
The current methods for file transfers include basic meta data about the +file being offered (name, size, and date). There currently is no way to provide an image thumbnail for files such as photos.
+This documents defines a way to include a thumbnail image as an additional metadata in a file transfer.
+When a client wishes to supply a thumbnail in a transfer offer, it can do so by including an extra ]]> element as show in the following exaples.
+The receiver MAY now request the data using the protocol defined in XEP-0231.
+The following attributes are defined for the <thumbnail/> element.
+| Attribute | +Description | +Inclusion | +
|---|---|---|
| cid | +A Content-ID that can be mapped to a cid: URL as specified in &rfc2111;. The 'cid' value SHOULD be of the form algo+hash@bob.xmpp.org, where the "algo" is the hashing algorithm used (e.g., "sha1" for the SHA-1 algorithm as specified in &rfc3174;) and the "hash" is the hex output of the algorithm applied to the binary data itself. | +REQUIRED | +
| mime-type | +The value of the 'mime-type' attribute MUST match the syntax specified in &rfc2045;. That is, the value MUST include a top-level media type, the "/" character, and a subtype; in addition, it MAY include one or more optional parameters (e.g., the "audio/ogg" MIME type in the example shown below includes a "codecs" parameter as specified in &rfc4281;). The "type/subtype" string SHOULD be registered in the &ianamedia;, but MAY be an unregistered or yet-to-be-registered value. | +RECOMMENDED | +
| width | +The intended display width of the thumbnail image. Used as a hint for the receiving client to prepare i.e. a dialog window. | +OPTIONAL | +
| height | +The intended display height of the thumbnail image. Used as a hint for the receiving client to prepare i.e. a dialog window. | +OPTIONAL | +
The inclusion of an image thumbnail may leak information about a transfer +otherwise taking place on an e2e encrypted file transfer stream. A client MAY +wish to not include a thumbnail.
+This document requires no interaction with &IANA;.
+This specification defines the following XML namespace:
+The ®ISTRAR; includes this namespace in the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.
+If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.
+
+
+
+
+
+
+ The protocol documented by this schema is defined in
+ xxx
+
+
+
+
+
+
+
+
+ ]]>
+First Draft.
++ It is quite common to play games over IM networks. + Since Tic-tac-toe is a well-known and simple game, + it's a good example for a server-based game protocol. +
++ This document addresses the requirements for a game protocol as defined by &xep-mug;. + In particular this consists of: +
++ The extensions needed to implement these requirements are qualified by the 'http://jabber.org/protocol/mug/tictactoe' namespace. +
++ An entity implementing this protocol MUST also support &xep-mug; and answer to disco requests accordingly + including both the Multi-User Gaming and the game &FEATURE; elements in the response. +
++ A Tic-tac-toe game uses two game roles, "x" and "o". + Both roles have to be assigned to exactly one player to start a match. + If one role gets unassigned or a player gets unavailable the match has to be paused. +
++ A service SHOULD offer a configuration form with the following options: +
++ An implementation MUST be able to handle the a board with three cols and rows + and three respective marks to win. + Everything beyond that is OPTIONAL. +
++ Submitting a strike option value bigger than the number of rows or columns SHOULD + result in ¬acceptable; error. +
++ The state in a Tic-tac-toe match represents the match configuration, + the player who makes the next turn + and the current state of the board. Every state is distributed to all occupants. +
++ After a valid turn, the state gets updated with the corresponding mark. +
++ The match is considered terminated when the board is full or + when one player reaches the number of respective marks as defined by the strike option. + After termination the service broadcasts the final state including either a <draw> + or <won> (including a game role) element to indicate the resulting score + and the initial state of the next round. +
++ During the game, players change in turn, each of them MUST send only one move at a time. + It MUST possess these attributes: +
| Name | +Type | +Description | +
| 'id' | +REQUIRED | +The number of the move. First move is 1. | +
| 'row' | +REQUIRED | +The horizontal position of the mark. | +
| 'col' | +REQUIRED | +The vertical position of the mark. | +
+ The author is not aware of any security issues introduced by this protocol extension. +
+This document requires no interaction with &IANA;.
+The ®ISTRAR; shall include 'http://jabber.org/protocol/mug/tictactoe' in its registry of protocols.
+First Draft.
++ It is quite common to play games over IM networks. + Since Tic-tac-toe is a well known game, XMPP needs a protocol to support it. +
++ This protocol should provide all means to play a regular game of Tic-tac-toe over XMPP. +
++ Tic-tac-toe is also one of the simplest games and played "just for fun". + Therefore no validation support is needed. + The typical duration is below one minute and the matches are not of great interest for non-players. + Therefore spectators do not have to be supported as well. + That is why this document only describes the protocol to play a Tic-tac-toe as a One-to-One match + without support for game saving and resuming. +
++ An entity implementing this protocol MUST also support &xep-game; and answer to disco requests accordingly + including both the Instant Gaming and the game &FEATURE; elements in the response. +
++ When inviting to a game of Tic-tac-toe, an entity SHOULD use &xep0004; to specify game options in the REQUIRED &GAME; element. + Possible options are "role" (of the inviting player), "rows" (height), "cols" (width) and "strike" (number of marks in a row needed to win). + If these options are missing, all but role default to '3' and role defaults to 'x'. + An implementation MUST be able to handle the default values. + Everything beyond that is OPTIONAL. +
++ When sending an invitation of type "renew", + the role option MUST be changed to the opposite of the role the inviting player had in the previous match with that match ID. + So both players essentially switch their roles. + All other options MUST stay the same. +
++ During the game, players change in turn, each of them sending one move at a time. + The player with the role 'x' makes the first move. + A game move is represented as a &MESSAGE; stanza addressed to the full JID of the other player. + It MUST have a &THREAD; child element which specifies the match ID. + Furthermore, the &MESSAGE; stanza contains a &TURN; element which in turn contains exactly one &MOVE; element + qualified by 'http://jabber.org/protocol/games/tictactoe'. + It MUST possess these attributes: +
| Name | +Type | +Description | +
| 'id' | +REQUIRED | +The number of the move. First move is 1. | +
| 'row' | +REQUIRED | +The horizontal position of the mark. | +
| 'col' | +REQUIRED | +The vertical position of the mark. | +
+ Notifying the players whether they have won or lost is in responsibility of the game client. + The game is considered terminated when the board is full, i.e. nine moves have been made. + For further termination conditions see the appropriate section of &xep-game;. +
++ The author is not aware of any security issues introduced by this protocol extension. +
+This document requires no interaction with &IANA;.
+The ®ISTRAR; shall include 'http://jabber.org/protocol/games/tictactoe' in its registry of protocols.
+
+
+
+
+
+
+
+
+
+
+ ]]>
+First draft, based on suggestions from Eric Rescorla.
End-to-end encryption of traffic sent over the Extensible Messaging and Presence Protocol (XMPP) is a desirable goal. The Jabber/XMPP developer community has experimented with several such technologies, including OpenPGP (&xep0027;), S/MIME (&rfc3923;), and encrypted sessions or "ESessions" (&xep0218;). For various reasons, these technologies have not been widely implemented and deployed. When the &XSF; asked various Internet security experts to complete a security review of encrypted sessions, it was recommended to explore the possibility of instead using the Transport Layer Security (TLS; see &rfc4346;) as the base technology for end-to-end encryption XMPP traffic. That possibility is explored in this document.
+TLS is the most widely implemented protocol for securing network traffic. In addition to applications in the email infrastructure, the World Wide Web (HTTP Over TLS; see &rfc2818;), and datagram transport for multimedia session negotiation (DTLS; see &rfc4347;), TLS is used in XMPP to secure TCP connections from client to server and from server to server, as specified in &xmppcore;. Therefore TLS is already a familiar technology for many XMPP developers.
+The basic idea behind XTLS is that two XMPP entities negotiate an encrypted "tunnel" between themselves over XMPP. The tunnel is negotiated using standard TLS handshake data, contained in XMPP &IQ; stanzas and encapsulated as Base64-encoded payloads of a <data/> element qualified by a dedicated namespace. The entities can then exchange TLS-encrypted XMPP stanzas over that tunnel.
+XTLS is not limited to client-to-client encryption, since it can be used between two XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream, such as a &xep0045; chatroom), or between two remote XMPP services.
+It is intended that this specification will address the requirements specified in &xep0210;, or some reasonable subset thereof (yet to be defined). However, there is no guarantee that this specification addresses those requirements in its current form. Detailed analysis will need to be performed in order to determine whether XTLS meets the full requirements for end-to-end encryption of XMPP traffic.
+In XTLS, the initiator functions as a TLS client and the responder functions as a TLS server.
+To start the use of XTLS, the initiator sends an IQ-set containing a <start/> element qualified by the 'urn:xmpp:tmp:xtls' namespace &NSNOTE;.
+(Note: This is the functional equivalent of the <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> command for direct XML streams as specified in RFC 3920.)
+If the responder supports XTLS and agrees to start the use of XTLS, it returns an IQ-result containing a <proceed/> element qualified by the 'urn:xmpp:tmp:xtls' namespace &NSNOTE;.
+(Note: This is the functional equivalent of the <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> command for direct XML streams as specified in RFC 3920.)
+If the responder does not support XTLS, in accordance with core XMPP semantics it MUST return a &unavailable; error.
+If the responder supports XTLS but does not wish to proceed with the use of XTLS, it MUST return a ¬acceptable; error.
+It is possible that both parties will attempt to start the use of XTLS at the same time
In this example, juliet@capulet.com/balcony is sorted before romeo@montague.net/orchard and therefore her XTLS start stanza has a higher priority. Therefore she would return a conflict error to Romeo if they both send an XTLS start stanza at the same time.
+&xep0250; defines an IQ stanza to determine which TLS method shall be used for client-to-client STARTTLS as described in &xep0246;. The initiator MAY exchange the XEP-0250 offers first, but MAY instead include the offers in the XTLS <start/> stanza to save a round trip. A client supporting XTLS and XEP-0250 MUST support offer exchange in the XTLS <start/> stanza.
+If the responder supports XTLS, agrees to start the use of XTLS, and can verify the X.509 fingerprint, it returns an IQ-result containing a <proceed/> element with its offer.
+If the initiator detects that a TLS handshake will fail based on the received offers (e.g. the peer only supports X.509 certificates and the client is unable to verify the certificate), the initiator MUST close the tunnel immediately (see Closing the XTLS Tunnel).
+Before sending encrypted data, the parties MUST perform a TLS handshake to establish the the XTLS tunnel. The TLS library sends the handshake and all encrypted data in-band as Base64-encoded payload of a <data> element qualified by the 'urn:xmpp:tmp:xtls' namespace &NSNOTE;. (This is similar to how data is sent in-band using &xep0047;, but in a dedicated namespace to work around the potential blockage of IBB exchanges by server administrators.) During the handshake, the responder (which functions as the TLS server) SHOULD send a CertificateRequest if X.509 certificates are used, since mutual authentication is desired. The first stanza MUST include a 'method' attribute defining the TLS method to be used. Possible values are 'x509', 'openpgp', and 'srp'. While this information is also included in the TLS handshake message itself, it can be useful for the recipient to know this before sending the data to the TLS library in use, e.g. when SRP is used the client might need to provide the password to the TLS library before decoding any data.
+Note: It is possible that XTLS stanzas will not respect TLS message boundaries; therefore the number of IQ stanzas depends on the TLS implementation.
+The responder then acknowledges the stanza and, if the stream contains the complete ClientHello message, it continues with the TLS handshake. Otherwise it will wait for more messages from the initiator.
+After the TLS handshake has been completed, the parties exchange encrypted data over the tunnel. Because the routing information is already present in the IQ stanzas used by XTLS, it is OPTIONAL for the stanzas encapsulated in the XTLS stream to include routing information (i.e., the 'from' and 'to' attributes). In that case, the entity receiving the data MUST supply the 'from' and 'to' addresses of the IQ stanza that contains the encrypted data.
+The sender's client would strip off the routing information.
+This message is then encrypted and sent in one or more stanzas over the XTLS tunnel.
+Either party can close the XTLS tunnel; this is done by sending an IQ-set containing an empty <close/> element qualified by the 'urn:xmpp:tmp:xtls' namespace &NSNOTE;. However, if the entities have a mutual presence subscription then it is RECOMMENDED for the entities to maintain the tunnel until one entity becomes unavailable. Keeping the XTLS tunnel open does not require significant resources and prevents the need for a new TLS handshake.
+The other party then acknowledges that the tunnel is closed by sending an IQ-result containing an empty <closed/> element qualified by the 'urn:xmpp:tmp:xtls' namespace &NSNOTE;.
+If the tunnel is unknown to the receiving party, it MUST return an ¬found; error.
+If an error is detected, the tunnel MUST be considered closed and invalid.
+As mentioned, XTLS is intended to address the requirements specified in XEP-0210 (or a reasonable subset thereof). This section compares XTLS against the requirements and points out gaps that might need to be filled with changes to XTLS or to TLS itself.
+If an entity wishes to request the use of XTLS, it SHOULD first determine whether the intended responder supports the protocol. This can be done directly via &xep0030; or indirectly via &xep0115;.
+If an entity supports XTLS, it MUST report that by including a service discovery feature of "urn:xmpp:tmp:xtls" in response to disco#info requests &NSNOTE;.
+Both service discovery and entity capabilities information could be corrupted or intercepted; for details, see the Denial of Service section of this document.
+This entire document addresses security. Particular security-related issues are discussed in the following sections.
+An implementation MUST at a minimum support the TLS_RSA_WITH_3DES_EDE_CBC_SHA and TLS_DH_RSA_WITH_AES_256_CBC_SHA ciphers. An implementation MAY support other ciphers as well.
+As noted, XTLS can be used between XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream), or between remote XMPP services. Therefore, a party to an XTLS tunnel will present either a client certificate or a server certificate as appropriate. Such certificates MUST be generated and validated in accordance with the certificate guidelines guidelines provided in &rfc3920bis;.
+A future version of this specification might provide additional guidelines regarding certificate validation in the context of client-to-client encryption.
+The XTLS start stanzas and proceed stanzas are not encrypted or signed; the same is true of service discovery exchanges and entity capabilities data. Therefore it is possible for an attacker to intercept these stanzas and modify them (e.g., by spuriously returning a &unavailable; error), thus convincing the initiator that the responder does not support XTLS and therefore denying the parties an opportunity to use XTLS.
+A future version of this specification might address this problem.
+This document requires no interaction with &IANA;.
+Until this proposal is accepted for publication by the XSF, its associated namespace shall be "urn:xmpp:tmp:xtls". Upon publication as a XEP, the ®ISTRAR; shall issue an initial namespace in accordance with the process defined in Section 4 of &xep0053;. The namespace "urn:xmpp:xtls:0" is requested and is thought to be unique per the XMPP Registrar's requirements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+The authors wish to thank Eric Rescorla for initial suggestions regarding the use of TLS for application-layer encryption in XMPP. Thanks also to Joe Hildebrand and Remko Tronçon for their comments and suggestions.
+