The RECOMMENDED process flow is as follows:
This flow is described more fully below.
First, the sender (in this example, romeo@montague.net) sends a message to an intended recipient (juliet@capulet.com).
@@ -77,7 +77,7 @@The recipient's server now delivers the offline message to that resource (it is RECOMMENDED for the server to add a &jep0091; extension to indicate that the message was stored offline).
+The recipient's server now delivers the offline message to that resource (it is RECOMMENDED for the server to add a &xep0091; extension to indicate that the message was stored offline).
Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in RFC 3921):
normal -- Messages with a 'type' attribute whose value is "normal" (or messages with no 'type' attribute) SHOULD be stored offline.
chat -- Messages with a 'type' attribute whose value is "chat" SHOULD be stored offline, with the exception of messages that contain only &jep0085; content (such messages SHOULD NOT be stored offline).
groupchat -- Messages with a 'type' attribute whose value is "groupchat" SHOULD NOT be stored offline, since by definition a user without online presence cannot be in a &jep0045; room.
chat -- Messages with a 'type' attribute whose value is "chat" SHOULD be stored offline, with the exception of messages that contain only &xep0085; content (such messages SHOULD NOT be stored offline).
groupchat -- Messages with a 'type' attribute whose value is "groupchat" SHOULD NOT be stored offline, since by definition a user without online presence cannot be in a &xep0045; room.
headline -- Messages with a 'type' attribute whose value is "headline" SHOULD NOT be stored offline, since such messages are usually time-sensitive.
error -- Messages with a 'type' attribute whose value is "error" SHOULD NOT be stored offline, although a server MAY store &jep0079; error messages offline.
error -- Messages with a 'type' attribute whose value is "error" SHOULD NOT be stored offline, although a server MAY store &xep0079; error messages offline.
If a server supports offline message handling as described herein, it SHOULD return a "msgoffline" feature in response to &jep0030; information requests:
+If a server supports offline message handling as described herein, it SHOULD return a "msgoffline" feature in response to &xep0030; information requests:
A message stored offline may not be readable by the recipient if the message was encrypted using a session-based encryption method such as &jep0116; or if the key used in object encryption is revoked after the message was sent but before it is read.
+A message stored offline may not be readable by the recipient if the message was encrypted using a session-based encryption method such as &xep0116; or if the key used in object encryption is revoked after the message was sent but before it is read.
In certain countries, offline storage of message stanzas may introduce legal requirements or privacy vulnerabilities that do not apply to messages that are delivered immediately and never stored on an intermediate server.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; includes "msgoffline" in its registry of service discovery features (see &DISCOFEATURES;).
Initial JEP version.
Initial version.
The following rules and guidelines apply to initial processing of a SPIM report.
In order to discover whether another entity supports SPIM reporting, &jep0030; SHOULD be used. If an entity supports SPIM reporting, it MUST return a feature of "http://jabber.org/protocol/spimreport" in responses to service discovery information requests, as shown in the following examples:
+In order to discover whether another entity supports SPIM reporting, &xep0030; SHOULD be used. If an entity supports SPIM reporting, it MUST return a feature of "http://jabber.org/protocol/spimreport" in responses to service discovery information requests, as shown in the following examples:
This document requires no interaction with &IANA;.
The ®ISTRAR; shall add 'http://jabber.org/protocol/spimreport' to its registry of protocol namespaces.
&rfc3921; explains how subscriptions and rosters integrate. However, several points are left to the client author's discretion, and this can lead - to some confusion among client developers. This JEP specifies best practices + to some confusion among client developers. This document specifies best practices that enable all Jabber clients to manage subscriptions and roster in a coherent way, thus making sure that such clients will not surprise end users with unexpected behavior.
@@ -183,10 +183,10 @@The name of the 'Hidden' group can be managed in two different ways :
This is left as an open issue since no clients (to the author's knowledge) implement this 'Hidden' group. But the preference should go to the first solution, which avoids relying on &jep0049;.
+This is left as an open issue since no clients (to the author's knowledge) implement this 'Hidden' group. But the preference should go to the first solution, which avoids relying on &xep0049;.
-Updated to reflect version 1.8 of JEP-0060.
Updated to reflect version 1.8 of XEP-0060.
Updated to reflect use of data forms in JEP-0060.
Updated to reflect use of data forms in XEP-0060.
Updated to reflect proposed JEP-0060 modifications.
Updated to reflect proposed XEP-0060 modifications.
Initial JEP version.
Initial version.
The XMPP &jep0060; extension ("pubsub") can be used to broadcast state change events associated with a Jabber/XMPP account or user, such as those described in &jep0080;, &jep0107;, &jep0108;, and &jep0118;.
Note: This document does not show error flows related to the various publish-subscribe use cases referenced herein, since they are exhaustively defined in JEP-0060. The reader is referred to JEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension.
+The XMPP &xep0060; extension ("pubsub") can be used to broadcast state change events associated with a Jabber/XMPP account or user, such as those described in &xep0080;, &xep0107;, &xep0108;, and &xep0118;.
Note: This document does not show error flows related to the various publish-subscribe use cases referenced herein, since they are exhaustively defined in XEP-0060. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension.
These uses of presence simplify the task of developing compliant clients (cf. &jep0134;).
+These uses of presence simplify the task of developing compliant clients (cf. &xep0134;).
By default, the existence of an XMPP presence subscription is used to establish a PEP subscription to the account owner's personal eventing data. In order to filter which notifications are sent by the PEP service, the contact's client includes extended &jep0115; information in the presence notifications it sends to the account owner, and the PEP service sends only those notifications that match the contact's expressed notification preferences.
+By default, the existence of an XMPP presence subscription is used to establish a PEP subscription to the account owner's personal eventing data. In order to filter which notifications are sent by the PEP service, the contact's client includes extended &xep0115; information in the presence notifications it sends to the account owner, and the PEP service sends only those notifications that match the contact's expressed notification preferences.
Most pubsub configuration options and metadata are not needed for personal eventing. Instead, PEP services offer smart defaults to simplify node creation and management.
@@ -210,7 +210,7 @@Naturally, before an account owner attempts to complete any PEP use cases, its client SHOULD determine whether the account owner's server supports PEP; to do so, it MUST send a &jep0030; information request to the server:
+Naturally, before an account owner attempts to complete any PEP use cases, its client SHOULD determine whether the account owner's server supports PEP; to do so, it MUST send a &xep0030; information request to the server:
If a server supports PEP, it MUST return an identity of "pubsub/pep" (as well as a list of the namespaces and other features it supports, including all supported JEP-0060 features):
+If a server supports PEP, it MUST return an identity of "pubsub/pep" (as well as a list of the namespaces and other features it supports, including all supported XEP-0060 features):
When an account owner attempts to publish an item to a PEP node and that node does not already exist, the PEP service MUST automatically create the node with default configuration.
When an account owner attempts to publish an item to a PEP node and that node does not already exist, the PEP service MUST automatically create the node with default configuration.
For example, Juliet would send the following stanzas in order to create the nodes mentioned above:
If an entity is not subscribed to the account owner's presence, it MUST subscribe to a node using the protocol defined in JEP-0060. For instance, here is how benvolio@montague.net would subscribe Juliet's tune information:
+If an entity is not subscribed to the account owner's presence, it MUST subscribe to a node using the protocol defined in XEP-0060. For instance, here is how benvolio@montague.net would subscribe Juliet's tune information:
An account owner publishes an item to a node by following the protocol specified in JEP-0060:
+An account owner publishes an item to a node by following the protocol specified in XEP-0060:
As a result, the account owner's server generates notifications and sends them to all subscribers who have requested or are interested in the data as described in the Contact Notification Filtering and Generating Notifications sections of this document.
-The server MUST set the 'from' address on the notification to the bare JID (&BAREJID;) of the account owner (in this example, "juliet@capulet.com"). When sending notifications to an entity that has a presence subscription to the account owner, the server SHOULD include an &jep0033; "replyto" extension specifying the publishing resource (in this example, "juliet@capulet.com/balcony"); this enables the subscriber's client to differentiate between information received from each of the account owner's resources (for example, different resources may be in different places and therefore may need to specify distinct geolocation data). However, a server MUST NOT include the "replyto" address when sending a notification to an entity that does not have a presence subscription to the account owner. In addition, any errors related to the notification MUST be directed to the JID of the 'from' address on the notification (i.e., the bare JID) so that bounce processing can be handled by the PEP service rather than by the publishing client.
+The server MUST set the 'from' address on the notification to the bare JID (&BAREJID;) of the account owner (in this example, "juliet@capulet.com"). When sending notifications to an entity that has a presence subscription to the account owner, the server SHOULD include an &xep0033; "replyto" extension specifying the publishing resource (in this example, "juliet@capulet.com/balcony"); this enables the subscriber's client to differentiate between information received from each of the account owner's resources (for example, different resources may be in different places and therefore may need to specify distinct geolocation data). However, a server MUST NOT include the "replyto" address when sending a notification to an entity that does not have a presence subscription to the account owner. In addition, any errors related to the notification MUST be directed to the JID of the 'from' address on the notification (i.e., the bare JID) so that bounce processing can be handled by the PEP service rather than by the publishing client.
Assuming that all three entities previously mentioned would receive the notifications, the PEP service would generate the following stanzas:
A contact may not want to receive notifications for all payload types. A contact SHOULD signal its preferences to the account owner's server by including JEP-0115 information that specifies the namespaces for which the contact wishes to receive notifications (if any).
+A contact may not want to receive notifications for all payload types. A contact SHOULD signal its preferences to the account owner's server by including XEP-0115 information that specifies the namespaces for which the contact wishes to receive notifications (if any).
In order to make this possible, all possible payload namespaces can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the payload format. Thus if Romeo wants to receive notifications for activity data and geolocation data but not tune data, his client would advertise support for the following namespaces in the disco#info results it sends:
This set of namespaces would then be advertised as a JEP-0115 "ext" value, such as the following:
+This set of namespaces would then be advertised as a XEP-0115 "ext" value, such as the following:
Note: In JEP-0115, the "ext" values are opaque strings with no semantic meaning.
-It is the responsibility of the account owner's server to cache JEP-0115 information (including "ext" values and their associated namespaces). When the server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the desired namespaces for the contact's client. The server MUST NOT send notifications related to any data formats that the contact's client has not asked for via the relevant "namespace+notify" disco#info feature. This enables a client to turn off all notifications (e.g., because of bandwidth restrictions) and to easily receive all desired data formats simply by adding support for the appropriate "namespace+notify" combination in its disco#info results and client capabililies. However, it also implies that a client can request notifications only on a global basis and cannot request, say, mood information only from certain contacts in the user's roster. Community consensus is that this is an acceptable tradeoff. Also, note that this works only if the account owner has a presence subscription to the contact and the contact has a presence subscription to the account owner.
+Note: In XEP-0115, the "ext" values are opaque strings with no semantic meaning.
+It is the responsibility of the account owner's server to cache XEP-0115 information (including "ext" values and their associated namespaces). When the server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the desired namespaces for the contact's client. The server MUST NOT send notifications related to any data formats that the contact's client has not asked for via the relevant "namespace+notify" disco#info feature. This enables a client to turn off all notifications (e.g., because of bandwidth restrictions) and to easily receive all desired data formats simply by adding support for the appropriate "namespace+notify" combination in its disco#info results and client capabililies. However, it also implies that a client can request notifications only on a global basis and cannot request, say, mood information only from certain contacts in the user's roster. Community consensus is that this is an acceptable tradeoff. Also, note that this works only if the account owner has a presence subscription to the contact and the contact has a presence subscription to the account owner.
Some examples may help to illustrate the concept of notification filtering. Here we show presence generated by two of the contacts listed above (benvolio@montague.net does have any presence subscriptions to or from juliet@capulet.com and therefore is not involved in these protocol flows).
If a subscriber subscribed using a full JID (&FULLJID;), domain identifier (&DOMAIN;), or domain plus resource (&DOMAINRES;), a PEP service MUST send one notification only, addressed to the subscribed JID.
If a subscriber subscribed using a bare JID (&BAREJID;) and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID (&BAREJID;) of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with non-negative priority and JEP-0115 data that indicates interest in the relevant data format.)
If a subscriber subscribed using a bare JID (&BAREJID;) and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID (&FULLJID;) of each of the subscriber's available resources that have specified non-negative presence priority and included JEP-0115 information that indicates an interest in the data format.
If a subscriber subscribed using a bare JID (&BAREJID;) and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID (&BAREJID;) of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with non-negative priority and XEP-0115 data that indicates interest in the relevant data format.)
If a subscriber subscribed using a bare JID (&BAREJID;) and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID (&FULLJID;) of each of the subscriber's available resources that have specified non-negative presence priority and included XEP-0115 information that indicates an interest in the data format.
When an account owner publishes an item to a node, a PEP service MUST generate a notification and send it to all appropriate subscribers (where the number of notifications is determined by the foregoing rules).
When a PEP service receives initial presence information from a subscriber's resource with a non-negative priority and including JEP-0115 information that indicates an interest in the data format, it MUST generate a notification containing the last published item for that node and send it to the newly-available resource.
When a PEP service receives initial presence information from a subscriber's resource with a non-negative priority and including XEP-0115 information that indicates an interest in the data format, it MUST generate a notification containing the last published item for that node and send it to the newly-available resource.
As an exception to the foregoing MUST rules, a PEP service MUST NOT send notifications to a subscriber if the user has blocked the subscriber from receiving all or any kinds of stanza (presence, message, IQ, or any combination thereof) using communiations blocking as specified in XMPP IM.
As noted, PEP services may be used to implement private data storage, such as defined in &jep0049;. A future version of this document will specify this usage in more detail.
+As noted, PEP services may be used to implement private data storage, such as defined in &xep0049;. A future version of this document will specify this usage in more detail.
A PEP service MUST:
If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY send a message to the (former) subscriber informing it of the cancellation (for information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of JEP-0060).
+If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY send a message to the (former) subscriber informing it of the cancellation (for information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of XEP-0060).
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; includes a category of "pubsub" in its registry of Service Discovery identities (see &DISCOCATEGORIES;); as a result of this JEP, the Registrar includes a type of "pep" to that category.
+The ®ISTRAR; includes a category of "pubsub" in its registry of Service Discovery identities (see &DISCOCATEGORIES;); as a result of this document, the Registrar includes a type of "pep" to that category.
The registry submission is as follows:
@@ -747,9 +747,9 @@
pep
A personal eventing service that supports the
- publish-subscribe subset defined in JEP-0163.
+ publish-subscribe subset defined in XEP-0163.
- JEP-0163
+ XEP-0163
]]>
@@ -757,11 +757,11 @@
Because Personal Eventing via Pubsub simply reuses the protocol specified in JEP-0060, a separate schema is not needed.
+Because Personal Eventing via Pubsub simply reuses the protocol specified in XEP-0060, a separate schema is not needed.
The authors wish to thank the participants in the XMPP Interoperability Testing Event held July 24 and 25, 2006, who provided valuable feedback that resulted in radical simplification of the protocol.
Because XML vCards (see &jep0054;) are now actively used for storing avatars (see &jep0153;), the ability to retrieve only portions of a vCard has become desirable. This JEP can eliminate unnecessary bandwidth usage when larger elements of a vCard are not needed.
+Because XML vCards (see &xep0054;) are now actively used for storing avatars (see &xep0153;), the ability to retrieve only portions of a vCard has become desirable. This protocol can eliminate unnecessary bandwidth usage when larger elements of a vCard are not needed.
Any entity supporting this extension MUST be prepared to accept more fields than were requested, in case the target does not support this extension. A compliant target SHOULD exclude any fields listed in the filter element. In the event that the filter element does not exist or is empty, the target MUST return the entire vCard as it would without this extension.
To illustrate the functionality of this JEP, we will first request a standard vCard. As shown in JEP-0054, a user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID. A compliant server MUST return the vCard to the requestor and not forward the IQ to the requestee's connected resource.
+To illustrate the functionality of this protocol, we will first request a standard vCard. As shown in XEP-0054, a user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID. A compliant server MUST return the vCard to the requestor and not forward the IQ to the requestee's connected resource.
This JEP introduces no new security concerns beyond those already involved in implementation and deployment of the 'vcard-temp' protocol.
+This document introduces no new security concerns beyond those already involved in implementation and deployment of the 'vcard-temp' protocol.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; shall add 'vcard-temp-filter' to its registry of official namespaces.
The schema for the 'vcard-temp-filter' namespace re-uses the element names from the DTD described in JEP-0054.
+The schema for the 'vcard-temp-filter' namespace re-uses the element names from the DTD described in XEP-0054.
@@ -181,4 +181,4 @@
]]>
Updated to use JEP-0172 syntax for nicknames.
Updated to use XEP-0172 syntax for nicknames.
Initial JEP version.
Initial version.
As explained in &petnames;, no one naming or address scheme can provide names that are simultaneously global, memorable, and unique. However, certain combinations of names and addresses can provide all three properties, and such combinations are commonly called "petname systems". Consider the following combination of names:
The JID "stpeter@jabber.org" is globally unique on the Jabber network, but it is not necessarily memorable.
The nickname "psa" (asserted by the user associated with the address "stpeter@jabber.org") is globally memorable but not necessarily unique; see &jep0172; for more information about user-asserted nicknames.
The handle or petname
The nickname "psa" (asserted by the user associated with the address "stpeter@jabber.org") is globally memorable but not necessarily unique; see &xep0172; for more information about user-asserted nicknames.
The handle or petname
A client SHOULD require an end user to assign a handle for every contact added to the person's roster, which SHOULD be stored as the value of the <item/> element's 'name' attribute qualified by the 'jabber:iq:roster' namespace (for details regarding roster syntax, refer to &rfc3921;). A client SHOULD then present that handle instead of or in addition to the contact's JID or nickname (e.g., in the user's roster and in chat interfaces). This will help to prevent mimicked addresses from being presented as equivalent to the address that is being mimicked.
@@ -87,7 +87,7 @@Unfortunately, cryptographic identities such as keys, certificates, and fingerprints are even less memorable than JIDs, which makes assigning a handle even more important. Therefore, if a contact provides such a cryptographic identity, a client MUST reliably associate it with the contact in a user's roster (including, as mentioned, an alias for each contact) in order to further strengthen the petname system.
In order to strengthen the web of interaction and trust between Jabber/XMPP users, it is helpful for them to share roster items. In particular, when a user wants to subscribe to the presence of a potential contact, the user SHOULD seek a referral from a third person who knows both the user and the contact. Such a referral consists of a roster item sent from the third person to the potential contact, encapsulated using the &jep0144; protocol:
+In order to strengthen the web of interaction and trust between Jabber/XMPP users, it is helpful for them to share roster items. In particular, when a user wants to subscribe to the presence of a potential contact, the user SHOULD seek a referral from a third person who knows both the user and the contact. Such a referral consists of a roster item sent from the third person to the potential contact, encapsulated using the &xep0144; protocol:
Here, the 'name' attribute encapsulates what in petname systems is known as an "alleged name", that is, the name for an entity proposed by a third party.
-Such a referral SHOULD also include the user's nick as understood by the third person (encapsulated in the format defined in &jep0172;) and fingerprint of the user as understood by the third person (encapsulated in the format defined in the proposal available at <http://www.jabber.org/jeps/inbox/fingerprint.html>:
+Such a referral SHOULD also include the user's nick as understood by the third person (encapsulated in the format defined in &xep0172;) and fingerprint of the user as understood by the third person (encapsulated in the format defined in the proposal available at <http://www.jabber.org/jeps/inbox/fingerprint.html>:
Naturally, based on the JID, it is possible to pull information about the sender from a persistent data store such as an LDAP database, &jep0054; node, or future profile system. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender (encapsulated via the format specified in JEP-0172) and the fingerprint of the sender's certificate or key.
+Naturally, based on the JID, it is possible to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or future profile system. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender (encapsulated via the format specified in XEP-0172) and the fingerprint of the sender's certificate or key.
This document requires no interaction with &IANA;.
This document requires no interaction with the ®ISTRAR;.
Added glossary; clarified state machines; updated to reflect publication of JEP-0176 and JEP-0177.
Added glossary; clarified state machines; updated to reflect publication of XEP-0176 and XEP-0177.
Initial JEP version.
Initial version.
Added Jabber Registrar considerations; defined schema; completed slight syntax cleanup.
Added XMPP Registrar considerations; defined schema; completed slight syntax cleanup.
There exists no widely-adopted standard for initiating and managing peer-to-peer (p2p) interactions (such as voice, video, or file sharing exchanges) from within Jabber/XMPP clients. Although several large service providers and Jabber/XMPP clients have written and implemented their own proprietary XMPP extensions for p2p signalling (usually only for voice), those technologies are not open and do not always take into account requirements to interoperate with the Public Switched Telephone Network (PSTN) or emerging SIP-based Internet voice networks. By contrast, the only existing open protocol has been &jep0111;, which made it possible to initiate and manage p2p sessions, but which did not provide enough of the key signalling semantics to be easily implemented in Jabber/XMPP clients.
There exists no widely-adopted standard for initiating and managing peer-to-peer (p2p) interactions (such as voice, video, or file sharing exchanges) from within Jabber/XMPP clients. Although several large service providers and Jabber/XMPP clients have written and implemented their own proprietary XMPP extensions for p2p signalling (usually only for voice), those technologies are not open and do not always take into account requirements to interoperate with the Public Switched Telephone Network (PSTN) or emerging SIP-based Internet voice networks. By contrast, the only existing open protocol has been &xep0111;, which made it possible to initiate and manage p2p sessions, but which did not provide enough of the key signalling semantics to be easily implemented in Jabber/XMPP clients.
The result has been an unfortunate fragmentation within the XMPP community regarding signalling protocols. There are, essentially, two approaches to solving the problem:
Implementation experience indicates that a dual-stack approach may not be feasible on all the computing platforms for which Jabber clients have been written, or even desirable on platforms where it is feasible.
As a result of feedback received on JEP-0111, the second and fourth authors of this document began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team,
As a result of feedback received on XEP-0111, the second and fourth authors of this document began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team,
The protocol defined herein is designed to meet the following requirements:
@@ -167,7 +167,7 @@This document defines the signalling protocol only. Additional documents specify the following:
Various content description formats (audio, video, etc.) and, where possible, mapping those types to the Session Description Protocol (SDP; see &rfc4566;); one example is &jep0167;.
Various content description formats (audio, video, etc.) and, where possible, mapping those types to the Session Description Protocol (SDP; see &rfc4566;); one example is &xep0167;.
Various content transport methods.
Procedures for mapping the Jingle signalling protocol to existing signalling standards such as the IETF's Session Initiation Protocol (SIP; see &rfc3261;) and the ITU's H.323 protocol (see &h323;).
The &CONTENT; element also specifies who will be sending content (the initiator, the recipient, or both).
When negotiating the session and its content type, the entities involved in the session need to exchange content description formats. The approach taken herein is to specify pure session description information in separate specifications, one for each content description format (audio, video, etc.).
When negotiating the session and its content type, the entities involved in the session need to exchange content description formats. The approach taken herein is to specify pure session description information in separate specifications, one for each content description format (audio, video, etc.).
The generic state machine for management of any given content description format is as follows:
START
@@ -366,10 +366,10 @@ PENDING o---------------------+ |
- In order to initiate a Jingle session, the initiating entity must determine which of the target entity's XMPP resources is best for the desired content description format. If a contact has only one XMPP resource, this task MUST be completed using &jep0030; or the presence-based profile of service discovery specified in &jep0115;.
- Naturally, instead of sending service discovery requests to every contact in a user's roster, it is more efficient to use Entity Capabilities, whereby support for Jingle and various Jingle content description formats and content transport methods is determined for a client version in general (rather than on a per-JID basis) and then cached. Refer to JEP-0115 for details.
+ In order to initiate a Jingle session, the initiating entity must determine which of the target entity's XMPP resources is best for the desired content description format. If a contact has only one XMPP resource, this task MUST be completed using &xep0030; or the presence-based profile of service discovery specified in &xep0115;.
+ Naturally, instead of sending service discovery requests to every contact in a user's roster, it is more efficient to use Entity Capabilities, whereby support for Jingle and various Jingle content description formats and content transport methods is determined for a client version in general (rather than on a per-JID basis) and then cached. Refer to XEP-0115 for details.
If a contact has more than one XMPP resource, it may be that only one of the resources supports Jingle and the desired content description format, in which case the user MUST initiate the Jingle signalling with that resource.
- If a contact has more than one XMPP resource that supports Jingle and the desired content description format, it is RECOMMENDED for a client to use &jep0168; in order to determine which is the best resource with which to initiate the desired Jingle session.
+ If a contact has more than one XMPP resource that supports Jingle and the desired content description format, it is RECOMMENDED for a client to use &xep0168; in order to determine which is the best resource with which to initiate the desired Jingle session.
Once the initiating entity has discovered which of the target entity's XMPP resources is ideal for the desired content description format, it sends a session initiation request to the target entity. This request is an IQ-set containing a &JINGLE; element qualified by the 'http://jabber.org/protocol/jingle' namespace. The &JINGLE; element MUST possess the 'action', 'initiator', and 'sid' attributes (the latter two uniquely identify the session). For initiation, the 'action' attribute MUST have a value of "session-initiate" and the &JINGLE; element MUST contain one or more &CONTENT; elements, each of which defines a content type to be transferred during the session; each &CONTENT; element in turn contains one &DESCRIPTION; child element that specifies a desired content description format and one or more &TRANSPORT; child elements that specify potential content transport methods.
@@ -697,15 +697,15 @@ PENDING o---------------------+ |
- This JEP requires no interaction with &IANA;.
+ This document requires no interaction with &IANA;.
-
+
The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle' and 'http://jabber.org/protocol/jingle#errors' in its registry of protocol namespaces.
- The Jabber Registrar shall maintain a registry of Jingle content description formats. All content description format registrations shall be defined in separate documents (not in this JEP). Content description formats defined within the JEP series MUST be registered with the Jabber Registrar, resulting in protocol URIs of the form "http://jabber.org/protocol/jingle/description/name" (where "name" is the registered name of the content description format).
+ The XMPP Registrar shall maintain a registry of Jingle content description formats. All content description format registrations shall be defined in separate specifications (not in this document). Content description formats defined within the XEP series MUST be registered with the XMPP Registrar, resulting in protocol URIs of the form "http://jabber.org/protocol/jingle/description/name" (where "name" is the registered name of the content description format).
®PROCESS;
@@ -716,7 +716,7 @@ PENDING o---------------------+ |
]]>
- The Jabber Registrar shall maintain a registry of Jingle content transport methods. All content transport method registrations shall be defined in separate documents (not in this JEP). Content transport methods defined within the JEP series MUST be registered with the Jabber Registrar, resulting in protocol URIs of the form "http://jabber.org/protocol/jingle/transport/name" (where "name" is the registered name of the content transport method).
+ The XMPP Registrar shall maintain a registry of Jingle content transport methods. All content transport method registrations shall be defined in separate specifications (not in this document). Content transport methods defined within the XEP series MUST be registered with the XMPP Registrar, resulting in protocol URIs of the form "http://jabber.org/protocol/jingle/transport/name" (where "name" is the registered name of the content transport method).
®PROCESS;
@@ -823,4 +823,4 @@ PENDING o---------------------+ |
The authors would like to thank Rohan Mahy for his valuable input on early versions of this document. Rob Taylor, Dafydd Harries, Jussi Laako, Saku Vainio, Antti Ijäs, Brian West, Anthony Minessale, Matt O'Gorman, and others have also provided helpful input. Thanks also to those who have commented on the &SJIG; and (earlier) Jingle Before this specification was accepted as a Jabber Enhancement Proposal, it was discussed on the semi-private <jingle@jabber.org> mailing list; although that list is no longer used (the Standards-JIG list is the preferred discussion venue), for historical purposes it is publicly archived at <http://mail.jabber.org/pipermail/jingle/>. mailing lists.
-
+
diff --git a/xep-0167.xml b/xep-0167.xml
index d71a2340..a43ba30f 100644
--- a/xep-0167.xml
+++ b/xep-0167.xml
@@ -1,10 +1,10 @@
-
+
%ents;
]>
-
-
+
+
Jingle Audio Content Description Format
This document defines a content description format for Jingle audio sessions.
@@ -16,7 +16,7 @@
Council
XMPP Core
- JEP-0166
+ XEP-0166
@@ -28,13 +28,13 @@
0.5
2006-08-23
psa
- Modified namespace to track JEP-0166.
+ Modified namespace to track XEP-0166.
0.4
2006-07-12
se/psa
- Specified when to play received audio (early media); specified that DTMF must use in-band signalling (JEP-0181).
+ Specified when to play received audio (early media); specified that DTMF must use in-band signalling (XEP-0181).
0.3
@@ -46,13 +46,13 @@
0.2
2006-02-13
psa
- Defined info message for busy; added info message examples; recommended use of Speex; updated schema and Jabber Registrar considerations.
+ Defined info message for busy; added info message examples; recommended use of Speex; updated schema and XMPP Registrar considerations.
0.1
2005-12-15
psa
- Initial JEP version.
+ Initial version.
0.0.3
@@ -64,7 +64,7 @@
0.0.2
2005-10-27
psa
- Added SDP mapping, security considerations, IANA considerations, Jabber Registrar considerations, and XML schema.
+ Added SDP mapping, security considerations, IANA considerations, XMPP Registrar considerations, and XML schema.
0.0.1
@@ -74,7 +74,7 @@
- &jep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. The first session type of interest is audio chat. This document specifies a format for describing Jingle audio sessions.
+ &xep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. The first session type of interest is audio chat. This document specifies a format for describing Jingle audio sessions.
The Jingle content description format defined herein is designed to meet the following requirements:
@@ -102,7 +102,7 @@
]]>
- The <description/> element is intended to be a child of a &JINGLE; element as specified in JEP-0166.
+ The <description/> element is intended to be a child of a &JINGLE; element as specified in XEP-0166.
When the session is provisionally accepted, as indicated by the target entity sending an empty IQ result in response to an 'initiate' message, both receiving and sending entities SHOULD start listening for audio as defined by the negotiated transport method. For interoperability with telephony systems, each entity SHOULD play any audio received at this time, before the target sends an 'accept' message.
@@ -129,7 +129,7 @@ a=rtpmap:98 L16/16000/2
]]>
- If an entity supports the Jingle audio content description format, it MUST advertise that fact by returning a feature of "http://jabber.org/protocol/jingle/description/audio" in response to &jep0030; information requests.
+ If an entity supports the Jingle audio content description format, it MUST advertise that fact by returning a feature of "http://jabber.org/protocol/jingle/description/audio" in response to &xep0030; information requests.
Support for the Speex codec See <http://www.speex.org/>. is RECOMMENDED.
- Support for Dual Tone Multi-Frequency (DTMF) MUST use the protocol described in &jep0181;.
+ Support for Dual Tone Multi-Frequency (DTMF) MUST use the protocol described in &xep0181;.
The description of a format for audio sessions introduces no known security vulnerabilities.
- This JEP requires no interaction with &IANA;.
+ This document requires no interaction with &IANA;.
-
+
The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle/description/audio' and 'http://jabber.org/protocol/jingle/info/audio' in its registry of protocol namespaces.
- The Jabber Registrar shall include the name "audio" in its registry of Jingle content description formats. The registration is as follows:
+ The XMPP Registrar shall include the name "audio" in its registry of Jingle content description formats. The registration is as follows:
audio
Jingle sessions that support audio exchanges
- JEP-0167
+ XEP-0167
]]>
@@ -347,4 +347,4 @@ a=rtpmap:98 L16/16000/2
]]>
-
+
diff --git a/xep-0168.xml b/xep-0168.xml
index 03fbe303..95275893 100644
--- a/xep-0168.xml
+++ b/xep-0168.xml
@@ -1,10 +1,10 @@
-
+
%ents;
]>
-
-Initial JEP version.
Initial version.
Within the Extensible Messaging and Presence Protocol (XMPP; see &rfc3920;), presence indicates availability for communication -- specifically, communication via XMPP messaging (usually in the form of "instant messaging" or IM as described in &rfc3921;). However, a wide variety of entities might provide XMPP presence, including entities that are not primarily focused on IM (e.g., phones) or even entities that do not support XMPP messaging at all.
-Consider a scenario in which a contact wants to initiate a voice chat (e.g., via &jep0166;) with a user who has the following three XMPP resources:
+Consider a scenario in which a contact wants to initiate a voice chat (e.g., via &xep0166;) with a user who has the following three XMPP resources:
Resource | @@ -158,7 +158,7 @@
---|