That order MUST be followed if no other stream features are negotiated.
&jep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:
+&xep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:
The &jep0077; protocol can be used to establish an account before logging in. That step would be completed before SASL because an entity cannot authenticate if it does not first create an account. Therefore the following order is RECOMMENDED:
+The &xep0077; protocol can be used to establish an account before logging in. That step would be completed before SASL because an entity cannot authenticate if it does not first create an account. Therefore the following order is RECOMMENDED:
The legacy &jep0078; protocol can be used by clients to log into older (pre-XMPP) servers. In essence the "jabber:iq:auth" protocol is an older way of doing what the XMPP RFCs specify in the SASL, resource binding, and IM session stream features. Therefore the following order is RECOMMENDED:
+The legacy &xep0078; protocol can be used by clients to log into older (pre-XMPP) servers. In essence the "jabber:iq:auth" protocol is an older way of doing what the XMPP RFCs specify in the SASL, resource binding, and IM session stream features. Therefore the following order is RECOMMENDED:
Support for the &jep0079; protocol is advertised as a stream feature but its use is not negotiated; therefore no recommendation is needed.
+Support for the &xep0079; protocol is advertised as a stream feature but its use is not negotiated; therefore no recommendation is needed.
&jep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation fo both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:
+&xep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation fo both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:
The order of negotiated stream features has security implications and may be security-critical. In particular, TLS MUST be negotiated first.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
This JEP requires no interaction with the Jabber Registrar.
+This document requires no interaction with the XMPP Registrar.
When connected to a server, a XMPP entity can locate translation providers by asking a server which translation providers are attached to the server; this MUST be done using &jep0030;. The server SHOULD return the availability of of translation providers and language pairings for which the user has rights to use.
+When connected to a server, a XMPP entity can locate translation providers by asking a server which translation providers are attached to the server; this MUST be done using &xep0030;. The server SHOULD return the availability of of translation providers and language pairings for which the user has rights to use.
This possible weakness can be mitigated by not returning specifics to requesting entities and the responding entity MAY perform authorization checks in order to determine how to respond.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; shall include 'http://jabber.org/protocol/langtrans' and 'http://jabber.org/protocol/langtrans#items' in its registry of protocol namespaces.
The Jabber Registrar shall add a type of "translation" to the "automation" category in its registry of service discovery identities.
+The XMPP Registrar shall add a type of "translation" to the "automation" category in its registry of service discovery identities.
To reflect use of dedicated namespace, (1) changed JEP type from Informational to Standards Track and (2) updated Jabber Registrar Considerations.
To reflect use of dedicated namespace, (1) changed JEP type from Informational to Standards Track and (2) updated XMPP Registrar Considerations.
Added wrapper element from JEP-0154.
Added wrapper element from XEP-0154.
This document defines best practices that enable IM users to advertise their preferred nicknames over Jabber/XMPP instant messaging networks.
@@ -141,9 +141,9 @@ ]]>A nickname of this form has the same semantic meaning as the following data fields:
Naturally, based on the JID of the sender, it is possible for the client to pull information about the sender from a persistent data store such as an LDAP database, &jep0054; node, or JEP-0154 store. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender:
+Naturally, based on the JID of the sender, it is possible for the client to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or XEP-0154 store. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender:
&jep0045; defines a protocol for groupchat rooms. A user specifies a "room nickname" when joining such a room (the resource identifier of the 'to' address):
+&xep0045; defines a protocol for groupchat rooms. A user specifies a "room nickname" when joining such a room (the resource identifier of the 'to' address):
&jep0130; defines a protocol that enables a user to be informed when a contact signs up for an IM account. The user MAY include his or her nick in the request so that the contact can associate a nickname with the request.
+&xep0130; defines a protocol that enables a user to be informed when a contact signs up for an IM account. The user MAY include his or her nick in the request so that the contact can associate a nickname with the request.
In order for a user to modify his or her nickname and notify contacts of that change, it is RECOMMENDED for clients to use &jep0163; (a.k.a. PEP).
+In order for a user to modify his or her nickname and notify contacts of that change, it is RECOMMENDED for clients to use &xep0163; (a.k.a. PEP).
If a JEP-0163-compliant personal eventing service is not available, a client SHOULD use a standalone &jep0060; service.
+If a XEP-0163-compliant personal eventing service is not available, a client SHOULD use a standalone &xep0060; service.
If a client does not support JEP-0060 or the subset thereof specified in JEP-0163, it MAY send one &MESSAGE; stanza to each of its contacts, containing the updated nickname (note: the client SHOULD send the messages in a staggered fashion in order to avoid server-enforced rate limiting, commonly known as "karma").
+If a client does not support XEP-0060 or the subset thereof specified in XEP-0163, it MAY send one &MESSAGE; stanza to each of its contacts, containing the updated nickname (note: the client SHOULD send the messages in a staggered fashion in order to avoid server-enforced rate limiting, commonly known as "karma").
An IM client MAY use the user's own nickname as all or part of the "display name" shown to the user of that client (e.g., as the sending name in one-to-one chats and groupchats). For example, if the user whose JID is narrator@moby-dick.lit asserts that his nickname is "Ishmael", that user's client may show "Ishmael" as all or part of the user's display name. How the client shall store the display name is out of scope for this document; possible mechanisms include the user's local vCard, an organizational LDAP directory, &jep0049;, or JEP-0154.
+An IM client MAY use the user's own nickname as all or part of the "display name" shown to the user of that client (e.g., as the sending name in one-to-one chats and groupchats). For example, if the user whose JID is narrator@moby-dick.lit asserts that his nickname is "Ishmael", that user's client may show "Ishmael" as all or part of the user's display name. How the client shall store the display name is out of scope for this document; possible mechanisms include the user's local vCard, an organizational LDAP directory, &xep0049;, or XEP-0154.
A nickname is a memorable, friendly name asserted by a user. There is no guarantee that any given nickname will be unique even within a particulat community (such as an enterprise or university), let alone across the Internet through federation of communities. Clients SHOULD warn users that nicknames asserted by contacts are not unique and that nickname collisions are possible. Clients also MUST NOT depend on nicknames to validate the identity of contacts; instead, nicknames SHOULD be used in conjunction with JIDs (which are globally unique) and user-assigned handles (which are private and unique) as described in JEP-0165 in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.
+A nickname is a memorable, friendly name asserted by a user. There is no guarantee that any given nickname will be unique even within a particulat community (such as an enterprise or university), let alone across the Internet through federation of communities. Clients SHOULD warn users that nicknames asserted by contacts are not unique and that nickname collisions are possible. Clients also MUST NOT depend on nicknames to validate the identity of contacts; instead, nicknames SHOULD be used in conjunction with JIDs (which are globally unique) and user-assigned handles (which are private and unique) as described in XEP-0165 in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.
This JEP requires no interaction with &IANA;.
The ®ISTRAR; includes 'http://jabber.org/protocol/nick' in its registry of protocol namespaces (see &NAMESPACES;).
Thanks to Ian Paterson for his feedback.
-Unbeknownst to the authors of this document, work on user nicknames was previously done by Richard Dobson (see <http://richard.dobson-i.net/jep.php?html=jep-01xx.xml>).
+Unbeknownst to the authors of this document, work on user nicknames was previously done by Richard Dobson (see <http://richard.dobson-i.net/xep.php?html=xep-01xx.xml>).
Initial JEP version; changed title to Pubsub Subscription Storage; changed namespace to storage:pubsubs for consistency with other storage JEPs.
Initial version; changed title to Pubsub Subscription Storage; changed namespace to storage:pubsubs for consistency with other storage XEPs.
&jep0060; allows Jabber entities to subscribe to various kinds of information, but provides no way of remembering which nodes a user has subscribed to. Other protocols (e.g. &jep0080;, &jep0084;) allow information about a certain entity to be published to a Pubsub node. These protocols use &jep0030; to allow other entities to find the pubsub node used by a certain entity, but provide no way of performing the opposite mapping, from pubsub node to information source. This JEP attempts to fill that void, using &jep0049; for storing information about subscriptions.
+&xep0060; allows Jabber entities to subscribe to various kinds of information, but provides no way of remembering which nodes a user has subscribed to. Other protocols (e.g. &xep0080;, &xep0084;) allow information about a certain entity to be published to a Pubsub node. These protocols use &xep0030; to allow other entities to find the pubsub node used by a certain entity, but provide no way of performing the opposite mapping, from pubsub node to information source. This document attempts to fill that void, using &xep0049; for storing information about subscriptions.
This protocol enables Jabber clients to do the following:
@@ -112,8 +112,8 @@Due to the nature of JEP-0049, incremental updates are not possible; a client MUST send the entire <subscriptions/> node for each update. Before performing the update, the client SHOULD retrieve the stored subscriptions, and incorporate any changes.
-In this example, the user has just subscribed to Romeo's tune (see &jep0118;). Assuming that retrieving happened as in the previous use case, updating the subscriptions proceeds as follows:
+Due to the nature of XEP-0049, incremental updates are not possible; a client MUST send the entire <subscriptions/> node for each update. Before performing the update, the client SHOULD retrieve the stored subscriptions, and incorporate any changes.
+In this example, the user has just subscribed to Romeo's tune (see &xep0118;). Assuming that retrieving happened as in the previous use case, updating the subscriptions proceeds as follows:
Pubsub events offer an opportunity to spoof sender addresses e.g. through 'replyto' data (as specified by the &jep0033; protocol). This protocol attempts to close that hole. It does so by the following rules and assumptions:
+Pubsub events offer an opportunity to spoof sender addresses e.g. through 'replyto' data (as specified by the &xep0033; protocol). This protocol attempts to close that hole. It does so by the following rules and assumptions:
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this JEP.
+No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this document.
]]>
Initial JEP version; changed title to Link-Local Messaging.
Initial version; changed title to Link-Local Messaging.
The p2pj port number 5298 is not included in the &ianaports; maintained by &IANA;. The author will investigate whether that port number (or some other port number) needs to be registered.
This document requires no interaction with the ®ISTRAR;.
Thanks to Justin Karneges, Jens Alfke, and Marc Krochmal for their input.
This JEP requires no interaction with &IANA;.
This JEP requires no interaction with the ®ISTRAR;.
Specified that DTMF must use in-band signalling (JEP-0181).
Specified that DTMF must use in-band signalling (XEP-0181).
&jep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor content (session) types, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data connections between XMPP entities, using the &ice; methodology currently being developed within the IETF.
+&xep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor content (session) types, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data connections between XMPP entities, using the &ice; methodology currently being developed within the IETF.
The process for ICE negotiation is largely the same in Jingle as it is in draft-ietf-mmusic-ice. There are several differences:
In order for the initiator in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in JEP-0166. This stanza MUST include at least one transport method. If the initiator wishes to negotiate the ICE transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/ice' namespace.
+In order for the initiator in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in XEP-0166. This stanza MUST include at least one transport method. If the initiator wishes to negotiate the ICE transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/ice' namespace.
As described in JEP-0166, to provisionally accept the session initiation request, the responder returns an IQ-result:
+As described in XEP-0166, to provisionally accept the session initiation request, the responder returns an IQ-result:
If the responder provisionally accepts the session initiation request as shown above, both initiator and responder MUST immediately negotiate connectivity over the ICE transport by exchanging XML-formatted candidate transports for the channel. This negotiation proceeds immediately in order to maximize the possibility that media can be exchanged as quickly as possible.
If the responder provisionally accepts the session initiation request as shown above, both initiator and responder MUST immediately negotiate connectivity over the ICE transport by exchanging XML-formatted candidate transports for the channel. This negotiation proceeds immediately in order to maximize the possibility that media can be exchanged as quickly as possible.
The candidate syntax and negotiation flow are described below.
The following is an example of the candidate format:
@@ -378,7 +378,7 @@If an entity supports this specification, it MUST return a feature of "http://jabber.org/protocol/jingle/transport/ice" in response to &jep0030; information requests.
+If an entity supports this specification, it MUST return a feature of "http://jabber.org/protocol/jingle/transport/ice" in response to &xep0030; information requests.
As mentioned in the Deployment Notes of this document, server administrators may wish to deploy STUN servers in order to ease the process of negotiating use of the Jingle ICE transport. If a STUN server is accessible via XMPP, it SHOULD be advertised by returning an appropriate item in response to service discovery item requests sent to the address of an XMPP server:
If it is necessary to send Dual Tone Multi-Frequency (DTMF) tones, it is REQUIRED to use the XML format specified &jep0181;.
+If it is necessary to send Dual Tone Multi-Frequency (DTMF) tones, it is REQUIRED to use the XML format specified &xep0181;.
&jep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor content (session) types, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data between XMPP entities using a raw User Datagram Protocol (UDP) connection (see &rfc0768;).
+&xep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor content (session) types, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data between XMPP entities using a raw User Datagram Protocol (UDP) connection (see &rfc0768;).
The Jingle transport method defined herein is designed to meet the following requirements:
@@ -52,7 +52,7 @@In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in JEP-0166. This stanza MUST include at least one transport methods. If the initiating entity wishes to negotiate the Raw UDP transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/raw-udp' namespace.
+In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in XEP-0166. This stanza MUST include at least one transport methods. If the initiating entity wishes to negotiate the Raw UDP transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/raw-udp' namespace.
As described in JEP-0166, to provisionally accept the session initiation request, the target entity returns an IQ-result:
+As described in XEP-0166, to provisionally accept the session initiation request, the target entity returns an IQ-result:
Once the session is provisionally accepted, each entity should send one &TRANSPORT; element in a transport-info meessage, containing exactly one &CANDIDATE; element per channel, whose 'ip' and 'port' attributes specify the IP address and port number of the candidate that the initiator has reason to believe will be most likely to succeed for that channel. (Note: In older versions of JEP-0166, this was referrred to as the "default candidate".) This is not necessarily the initiator's preferred address for communication, but instead is the "address most likely to succeed", i.e., the address that is assumed to be reachable by the vast majority of target entities. To determine reachability, the client needs classify ahead of time the permissiveness of the firewall or network address translator (NAT) it is behind, if any. If the NAT is symmetric (not permissive), the candidate SHOULD specify a relay address. Otherwise it SHOULD be an address derived via prior discovery using &rfc3489;, which will be an address on the outside of the firewall or NAT.
+Once the session is provisionally accepted, each entity should send one &TRANSPORT; element in a transport-info meessage, containing exactly one &CANDIDATE; element per channel, whose 'ip' and 'port' attributes specify the IP address and port number of the candidate that the initiator has reason to believe will be most likely to succeed for that channel. (Note: In older versions of XEP-0166, this was referrred to as the "default candidate".) This is not necessarily the initiator's preferred address for communication, but instead is the "address most likely to succeed", i.e., the address that is assumed to be reachable by the vast majority of target entities. To determine reachability, the client needs classify ahead of time the permissiveness of the firewall or network address translator (NAT) it is behind, if any. If the NAT is symmetric (not permissive), the candidate SHOULD specify a relay address. Otherwise it SHOULD be an address derived via prior discovery using &rfc3489;, which will be an address on the outside of the firewall or NAT.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/raw-udp' in its registry of protocol namespaces.
The Jabber Registrar shall include "http://jabber.org/protocol/jingle/transport/raw-udp" in its registry of Jingle transport methods. The registry submission is as follows:
+The XMPP Registrar shall include "http://jabber.org/protocol/jingle/transport/raw-udp" in its registry of Jingle transport methods. The registry submission is as follows:
®PROCESS;
raw-udp
A method for exchanging data over a raw UDP connection.
- JEP-0176
+ XEP-0176
]]>
Initial JEP version.
Initial version.
The SASL EXTERNAL mechanism can be used outside the context of X.509 certificates, for example via Internet Protocol Security (IPSec) as specified in &rfc4301;. A future version of this specification may document best practices for use of SASL EXTERNAL outside the context of the X.509 infrastructure.
This JEP introduces no security considerations or concerns above and beyond those discussed in RFC 3920.
+This document introduces no security considerations or concerns above and beyond those discussed in RFC 3920.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
This JEP requires no interaction with the ®ISTRAR;.
+This document requires no interaction with the ®ISTRAR;.
Peter Millard, co-author of the initial version of this specification, died on April 26, 2006. The remaining author appreciates his assistance in defining the best practices described herein.
Initial JEP version.
Initial version.
&jep0166; defines a framework for negotiating and managing out-of-band multimedia sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor media (session) types, leaving that up to separate specifications. The current document defines a transport method for establishing and managing &iax; sessions between XMPP entities.
+&xep0166; defines a framework for negotiating and managing out-of-band multimedia sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor media (session) types, leaving that up to separate specifications. The current document defines a transport method for establishing and managing &iax; sessions between XMPP entities.
IAX is a peer-to-peer media and signaling protocol, where the endpoints maintain state machines. With respect to media, sequencing and timing information is included into IAX frames, without the use of Real-Time Transport Protocol (RTP) for the media.
In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in JEP-0166. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the IAX transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/iax' namespace.
+In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in XEP-0166. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the IAX transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/iax' namespace.
As described in JEP-0166, to provisionally accept the session initiation request, the target entity returns an IQ-result:
+As described in XEP-0166, to provisionally accept the session initiation request, the target entity returns an IQ-result:
In both cases, the Asterisk PBX has to be logged into the Jabber network and implement the Jingle extension like a channel (Asterisk terminology).
If it is necessary to send Dual Tone Multi-Frequency (DTMF) tones, it is RECOMMENDED to use the IAX-native methods specified in draft-ietf-guy-iax. The XML format specified &jep0181; MAY be used only as a fallback.
+If it is necessary to send Dual Tone Multi-Frequency (DTMF) tones, it is RECOMMENDED to use the IAX-native methods specified in draft-ietf-guy-iax. The XML format specified &xep0181; MAY be used only as a fallback.
To follow.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/iax' and 'http://jabber.org/protocol/jingle/info/iax' in its registry of protocol namespaces.
The Jabber Registrar shall include the name "iax" in its registry of Jingle transport descriptions. The registration is as follows:
+The XMPP Registrar shall include the name "iax" in its registry of Jingle transport descriptions. The registration is as follows:
iax
Jingle IAX sessions.
- JEP-0179
+ XEP-0179
]]>