diff --git a/xep-0180.xml b/xep-0180.xml index 0762f5b7..42f5352a 100644 --- a/xep-0180.xml +++ b/xep-0180.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
Jingle Video Content Description Format This document defines a content description format for Jingle video sessions. @@ -16,7 +16,7 @@ Council XMPP Core - JEP-0166 + XEP-0166 @@ -31,7 +31,7 @@ 0.3 2006-08-23 psa -

Modified namespace to track JEP-0166.

 +

Modified namespace to track XEP-0166.

 0.2 @@ -43,7 +43,7 @@ 0.1 2006-03-23 psa/mc -

Initial JEP version.

 +

Initial version.

 0.0.1 @@ -53,7 +53,7 @@
-

&jep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. One session type of interest is video exchange. This document specifies a format for describing Jingle video sessions.

+

&xep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. One session type of interest is video exchange. This document specifies a format for describing Jingle video sessions.

The Jingle content description format defined herein is designed to meet the following requirements:

@@ -73,7 +73,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.

The defined attributes of the &PAYLOADTYPE; element are as follows:

@@ -132,7 +132,7 @@

To follow.

-

If an entity supports the Jingle video content description format, it MUST advertise that fact by returning a feature of "http://jabber.org/protocol/jingle/description/video" in response to &jep0030; information requests.

+

If an entity supports the Jingle video content description format, it MUST advertise that fact by returning a feature of "http://jabber.org/protocol/jingle/description/video" in response to &xep0030; information requests.

The description of a format for video 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/video' and 'http://jabber.org/protocol/jingle/info/video' in its registry of protocol namespaces.

 -

The Jabber Registrar shall include the name "video" in its registry of Jingle content description formats. The registration is as follows:

+

The XMPP Registrar shall include the name "video" in its registry of Jingle content description formats. The registration is as follows:

video Jingle sessions that support video exchanges - JEP-xxxx + XEP-xxxx ]]> @@ -235,4 +235,4 @@

To follow.

 - + diff --git a/xep-0181.xml b/xep-0181.xml index 45d60d6b..a292031a 100644 --- a/xep-0181.xml +++ b/xep-0181.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
Jingle DTMF This document specifies an XML format for encapsulating DTMF data in informational messages sent within the context of Jingle audio interactions. @@ -16,7 +16,7 @@ Council XMPP Core - JEP-0166 + XEP-0166 @@ -39,7 +39,7 @@ 0.1 2006-03-23 psa -

Initial JEP version.

 +

Initial version.

 0.0.1 @@ -49,7 +49,7 @@
-

Traditional telephony systems use Dual Tone Multi-Frequency (DTMF) for dialing and to issue commands such as those used in Interactive Voice Response (IVR) applications. Internet telephony systems also use DTMF tones for interoperability with the public switched telephone network (PSTN). XMPP clients that use &jep0166; for voice chat (see &jep0167;) MUST use the protocol described in this document if they wish to support DTMF.

+

Traditional telephony systems use Dual Tone Multi-Frequency (DTMF) for dialing and to issue commands such as those used in Interactive Voice Response (IVR) applications. Internet telephony systems also use DTMF tones for interoperability with the public switched telephone network (PSTN). XMPP clients that use &xep0166; for voice chat (see &xep0167;) MUST use the protocol described in this document if they wish to support DTMF.

The format for the XML DTMF format is as follows:

@@ -121,9 +121,9 @@

This document 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/info/dtmf' in its registry of protocol namespaces.

 @@ -173,4 +173,4 @@ ]]> - + diff --git a/xep-0182.xml b/xep-0182.xml index ae45db8a..486e90f8 100644 --- a/xep-0182.xml +++ b/xep-0182.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
Application-Specific Error Conditions This document defines a registry of application-specific error conditions. @@ -38,7 +38,7 @@ 0.1 2006-03-23 psa -

Initial JEP version.

 +

Initial version.

 0.0.1 @@ -62,10 +62,10 @@ ]]>

Although the inclusion of application-specific error conditions introduces a great deal of flexibility, it may also lead to confusion regarding possible conditions. Therefore, this document defines a registry of application-specific error conditions, to be maintained by the ®ISTRAR;. In addition, this document registers a namespace of 'http://jabber.org/protocol/errors' as a fallback namespace for generalized error conditions that are not specific to a particular protocol (e.g., <stanza-too-big/> as a particular form of the ¬acceptable; condition).

- + -

The Jabber Registrar maintains a registry of application-specific error conditions (see &APPERRORS;).

-

All application-specific error conditions that are defined in Jabber Enhancement Proposals MUST be included in this registry. Application-specific error conditions that are defined outside of the JEP process MAY be included in this registry, but it is not required for them to be so registered.

+

The XMPP Registrar maintains a registry of application-specific error conditions (see &APPERRORS;).

+

All application-specific error conditions that are defined in Jabber Enhancement Proposals MUST be included in this registry. Application-specific error conditions that are defined outside of the Jabber Software Foundation's standards process (see &xep0001;) MAY be included in this registry, but it is not required for them to be so registered.

®PROCESS; This document introduces no known security vulnerabilities.

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 - + diff --git a/xep-0183.xml b/xep-0183.xml index d91a94ea..45df2582 100644 --- a/xep-0183.xml +++ b/xep-0183.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
Jingle Telepathy Transport This document defines a telepathic transport method for establishing Extra-Sensory Perception (ESP) streams. @@ -16,7 +16,7 @@ Council XMPP Core - JEP-0166 + XEP-0166 @@ -30,9 +30,9 @@
-

&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.

-

Typical peer-to-peer session types include voice chat (see &jep0167;) and video chat (see &jep0180;). But Jingle can go farther. Indeed, why not support not only physical multimedia sessions (limited to the five physical senses) but also psychical multimedia sessions (which go beyond the basic physical senses to include advanced, extra-sensory perception)? The media (or medium) may be different, but the underlying principles are the same: fostering freedom of conversation by connecting people (e.g., through mind-reading and séances) and even applications such as accessing information from the future (e.g., in clairvoyance and precognition). Indeed, the ability to communicate with the spirit world will push Jabber/XMPP technologies into a new age of real-time communications (light years ahead of traditional IM and VoIP systems). Beyond Internet telephony, our innovations in Internet telepathy will give new meaning to the term "voice chat" as users are able to hear voices from the past, present, or future.

-

Unfortunately, these advanced session types cannot be supported using existing transport mechanisms such as &jep0176;, &jep0177;, and &jep0179;. Therefore, this document defines a new Jingle transport method for establishing and managing Extra-Sensory Perception (ESP) streams: the "telepathy" method.

+

&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.

+

Typical peer-to-peer session types include voice chat (see &xep0167;) and video chat (see &xep0180;). But Jingle can go farther. Indeed, why not support not only physical multimedia sessions (limited to the five physical senses) but also psychical multimedia sessions (which go beyond the basic physical senses to include advanced, extra-sensory perception)? The media (or medium) may be different, but the underlying principles are the same: fostering freedom of conversation by connecting people (e.g., through mind-reading and séances) and even applications such as accessing information from the future (e.g., in clairvoyance and precognition). Indeed, the ability to communicate with the spirit world will push Jabber/XMPP technologies into a new age of real-time communications (light years ahead of traditional IM and VoIP systems). Beyond Internet telephony, our innovations in Internet telepathy will give new meaning to the term "voice chat" as users are able to hear voices from the past, present, or future.

+

Unfortunately, these advanced session types cannot be supported using existing transport mechanisms such as &xep0176;, &xep0177;, and &xep0179;. Therefore, this document defines a new Jingle transport method for establishing and managing Extra-Sensory Perception (ESP) streams: the "telepathy" method.

The Jingle telepathy transport method is designed to meet the following requirements:

@@ -45,7 +45,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 method. If the initiating entity wishes to negotiate the telepathy transport, it MUST include a &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/telepathy' 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 telepathy transport, it MUST include a &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/telepathy' namespace.

This &TRANSPORT; element MUST include one and only one &CANDIDATE; element per channel specifying the parameters that the initiator believes will be most likely to succeed for that channel. (Note: You have to believe.) This is not necessarily the initiator's preferred address for spiritual 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. (Establishing direct spiritual communication is hard enough as it is.) Here is an example:

@@ -68,13 +68,13 @@
  • The 'name' attribute specifies a unique name for the channel.
  • The 'plane' attribute is used for diagnostics; it is an index, starting at 1, referencing which astral plane this candidate is on for a given peer.
  • The 'pulse' attribute specifies the initiator's heart rate at the moment; this helps establish communications through pulse-sending of informational messages in time with the beat of your heart.
    • -
  • The 'psi-sig' attribute is the initiator's Psi Signature or "energy fingerprint"; because scanning people for their psi-sig can take time and is often a challenge, advertising one's psi-sig ahead of time makes it easier to establish a spiritual connection. The format of the 'psi-sig' attribute is a space-delimited set of descriptive words, often including colors, feelings, and emotions characterizing the person's energy state at the moment. Note: A person's psi-sig can change from moment to moment; therefore, it is advisable to also advertise it using &jep0163;.
    • +
  • The 'psi-sig' attribute is the initiator's Psi Signature or "energy fingerprint"; because scanning people for their psi-sig can take time and is often a challenge, advertising one's psi-sig ahead of time makes it easier to establish a spiritual connection. The format of the 'psi-sig' attribute is a space-delimited set of descriptive words, often including colors, feelings, and emotions characterizing the person's energy state at the moment. Note: A person's psi-sig can change from moment to moment; therefore, it is advisable to also advertise it using &xep0163;.
  • The 'sign' attribute represents the initiator's Zodiac sign; including this value obviates the need for asking "what's your sign?"
  • The 'time' attribute is used for diagnostics; the allowable values are "past", "present", and "future".
    •  -

    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:

    ]]> @@ -96,7 +96,7 @@ ]]>

    Now the initiating entity and target entity can begin sending appropriate psychical media over the negotiated ESP stream.

    -

    In the event that the target entity cannot establish a channel, it SHOULD terminate the session (see JEP-0176 or JEP-0177 for examples).

    +

    In the event that the target entity cannot establish a channel, it SHOULD terminate the session (see XEP-0176 or XEP-0177 for examples).

    Because the informational message payloads specific to the telepathy transport method cannot be tied down to the arbitrary conventions of XML syntax, a <message/> element qualified by the 'http://jabber.org/protocol/info/telepathy' namespace may include any character data that either party feels like communicating.

    @@ -112,22 +112,22 @@     -

    This JEP requires no interaction with &IANA;.

    +

    This document requires no interaction with &IANA;.

     - +

    The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/telepathy' and 'http://jabber.org/protocol/jingle/info/telepathy' in its registry of protocol namespaces.

     -

    The Jabber Registrar shall include "http://jabber.org/protocol/jingle/transport/telepathy" in its registry of Jingle transport methods. The registry submission is as follows:

    +

    The XMPP Registrar shall include "http://jabber.org/protocol/jingle/transport/telepathy" in its registry of Jingle transport methods. The registry submission is as follows:

    telepathy A method for the negotiation of Extra-Sensory Perception (ESP) streams. - JEP-0183 + XEP-0183 ]]>     @@ -220,4 +220,4 @@ ]]>         - + diff --git a/xep-0184.xml b/xep-0184.xml index bdfcbb64..e0e4657f 100644 --- a/xep-0184.xml +++ b/xep-0184.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
    Message Receipts - This document specifies a protocol for XMPP message receipts. + This document specifies an XMPP protocol extension for message receipts. &LEGALNOTICE; 0184 Experimental @@ -18,7 +18,7 @@ XMPP Core - JEP-0022 (in part) + XEP-0022 (in part) amp-receipts @@ -34,7 +34,7 @@ 0.1 2006-04-11 psa -

    Initial JEP version.

     +

    Initial version.

     0.0.2 @@ -50,7 +50,7 @@
    -

    While &jep0079; provides message acknowledgements at the server level, it does not extend that model all the way to the client. However, sometimes client-level acknowledgements are needed, for example to provide "receipts". This document defines a mechanism for XMPP message receipts.

    +

    While &xep0079; provides message acknowledgements at the server level, it does not extend that model all the way to the client. However, sometimes client-level acknowledgements are needed, for example to provide "receipts". This document defines a mechanism for XMPP message receipts.

    This document addresses the following requirements:

    @@ -162,21 +162,21 @@ S R

    In Scenario 7, the use case ends unsuccessfully with message delivery and the recipient generating presence unavailable; however, the presence unavailable is not delivered, so the sender retries sending the message and because the recipient is now offline it cannot send a receipt within the sender's timeout period.

     -

    In order to make it possible for senders to request, and for recipients to generate, message receipts, we define a new Advanced Message Processing rule: "receipt". In accordance with JEP-0079, we provide the following information about the receipt rule:

    +

    In order to make it possible for senders to request, and for recipients to generate, message receipts, we define a new Advanced Message Processing rule: "receipt". In accordance with XEP-0079, we provide the following information about the receipt rule:

    • The namespace shall be "http://jabber.org/protocol/amp?condition=receipt".
    • The condition applies only to final receipt by the intended recipient; therefore, the per-hop flag does not apply.
    • The only defined value of the receipt rule is "received".
      • -
    • This condition is met if a message processing application (client) controlled by the intended recipient has received and processed the message; the term "processed" is understood to include presentation to a human user if appropriate Therefore this specification does not distinguish between delivery and presentation, as was done in &jep0022;. or any other application-specific client-side processing, including generation of an error response if the application determines that the message contents cannot be handled.
      • +
    • This condition is met if a message processing application (client) controlled by the intended recipient has received and processed the message; the term "processed" is understood to include presentation to a human user if appropriate Therefore this specification does not distinguish between delivery and presentation, as was done in &xep0022;. or any other application-specific client-side processing, including generation of an error response if the application determines that the message contents cannot be handled.
     -

    In order to make it possible for senders to request, and for recipients to generate, message receipts, we define a new Advanced Message Processing rule: "receipt". In accordance with JEP-0079, we provide the following information about the receipt rule:

    +

    In order to make it possible for senders to request, and for recipients to generate, message receipts, we define a new Advanced Message Processing rule: "receipt". In accordance with XEP-0079, we provide the following information about the receipt rule:

    • The namespace shall be "http://jabber.org/protocol/amp?condition=receipt".
    • The condition applies only to final receipt by the intended recipient; therefore, the per-hop flag does not apply.
    • The only defined value of the receipt rule is "received".
      • -
    • This condition is met if a message processing application (client) controlled by the intended recipient has received and processed the message; the term "processed" is understood to include presentation to a human user if appropriate Therefore this specification does not distinguish between delivery and presentation, as was done in &jep0022;. or any other application-specific client-side processing, including generation of an error response if the application determines that the message contents cannot be handled.
      • +
    • This condition is met if a message processing application (client) controlled by the intended recipient has received and processed the message; the term "processed" is understood to include presentation to a human user if appropriate Therefore this specification does not distinguish between delivery and presentation, as was done in &xep0022;. or any other application-specific client-side processing, including generation of an error response if the application determines that the message contents cannot be handled.
    • Although any defined action may be triggered, the only action needed in order to support message receipts is the "notify" action.

    The following is an example of a message that includes a request for return receipt.

    @@ -204,17 +204,17 @@ S R ]]>     -

    The general business rules specified for Advanced Message Processing in JEP-0079 apply to any rule; in addition, the following business rules apply specifically to the receipt rule:

    +

    The general business rules specified for Advanced Message Processing in XEP-0079 apply to any rule; in addition, the following business rules apply specifically to the receipt rule:

    1. A sender SHOULD NOT include a request for message receipts when sending a message to the bare JID (&BAREJID;) of the recipient, only when sending to a full JID (&FULLJID;).

      2. -

    2. A sender SHOULD NOT include a request for message receipts unless it knows (via &jep0030; or &jep0115;) that the intended recipient supports the protocol described herein or unless the use of message receipts is negotiated via &jep0155;.

      3. +

    3. A sender SHOULD NOT include a request for message receipts unless it knows (via &xep0030; or &xep0115;) that the intended recipient supports the protocol described herein or unless the use of message receipts is negotiated via &xep0155;.

    4. The sender (i.e., the message generating application controlled by the sender) MUST initiate a timeout upon sending each message, which timeout SHOULD be 30 seconds. If the sender does not receive a message receipt (or failure event) within its timeout period, it MUST re-send the message with an identical value of the XMPP 'id' attribute.

    5. The sender MUST NOT send a large number of retries. How many retries are appropriate depends on how important the message is perceived to be. In any case, a sender SHOULD NOT send more than five retries.

    6. The recipient (i.e., the message processing application controlled by the intended recipient that receives a given message) MUST initiate a timeout upon sending each message receipt, which timeout SHOULD be 60 seconds. If the recipient does not receive a re-sent message within its timeout period, it SHOULD stop waiting for a re-sent message and discard memory of that message ID.

    7. The recipient MUST NOT include a request for message receipts in its acknowledgements. If the sender receives a request for message receipts in an acknowledgement, it MUST NOT acknowledge the acknowledement.

    8. The recipient SHOULD send the message receipt once it has processed the message, which may include presenting it to a human user (e.g., visually or aurally). The receiving application SHOULD NOT require a human user to positively affirm that he or she has read and understood the message before sending the receipt, since this is unnecessarily intrusive in the context of instant messaging.

    -

    Naturally, the receipt rule can be combined wiith rules specified in JEP-0079 (e.g., the deliver rule) for more complete reporting.

    +

    Naturally, the receipt rule can be combined wiith rules specified in XEP-0079 (e.g., the deliver rule) for more complete reporting.

    This document covers one use case: sending messages with return receipt requested, for which succcess is defined as the sender receiving a message receipt. As described above, there are seven possible scenarios. These are described in more detail in the following sections.

    @@ -435,7 +435,7 @@ S R

    If a sender wishes to request message receipts, it SHOULD first discover whether the intended recipient supports message receipts. Support can be discovered indirectly via Entity Capabilities or directly via Service Discovery.

    -

    If an entity supports Advanced Message Processing, it MUST report that by including a service discovery feature of "http://jabber.org/protocol/amp" as described in JEP-0079:

    +

    If an entity supports Advanced Message Processing, it MUST report that by including a service discovery feature of "http://jabber.org/protocol/amp" as described in XEP-0079:

    No interaction with &IANA; is necessary as a result of this document.

     - +

    The ®ISTRAR; maintains a registry of Advanced Message Processing <rule/> conditions (see &CONDITIONS;). The Registrar shall add the following condition to the registry:

    - JEP-xxxx + XEP-xxxx ]]>     -

    &jep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace and the Jabber Registrar maintains a registry of such fields (see &FORMTYPES;). The Registrar shall add the following field for use in Chat Session Negotiation forms:

    +

    &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace and the XMPP Registrar maintains a registry of such fields (see &FORMTYPES;). The Registrar shall add the following field for use in Chat Session Negotiation forms:

    http://jabber.org/protocol/chatneg + label='Whether to enable Message Receipts per XEP-0184'/> ]]>     @@ -566,4 +566,4 @@ S R

    Thanks to Joe Kemp for his input.

     -     + diff --git a/xep-0185.xml b/xep-0185.xml index e781e228..294aaced 100644 --- a/xep-0185.xml +++ b/xep-0185.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    Dialback Key Generation and Validation This document explains how to generate and validate the keys used in the XMPP server dialback protocol. @@ -38,7 +38,7 @@ 0.1 2006-04-11 psa -

    Initial JEP version.

     +

    Initial version.

     0.0.1 @@ -242,12 +242,12 @@ SHA1('example.orgexample.com457F9224A0') = -

    This JEP introduces no security considerations or concerns above and beyond those discussed in RFC3920, but describes what might happen if the security considerations are ignored.

    +

    This document introduces no security considerations or concerns above and beyond those discussed in RFC3920, but describes what might happen if the security considerations are ignored.

     -

    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;.

     - + diff --git a/xep-0186.xml b/xep-0186.xml index ada81a1b..cc0112b8 100644 --- a/xep-0186.xml +++ b/xep-0186.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    Invisible Command This document specifies an XMPP-compatible protocol for user invisibility. @@ -16,7 +16,7 @@ XMPP Core XMPP IM - JEP-0030 + XEP-0030 None None @@ -26,7 +26,7 @@ 0.4 2006-08-09 psa -

    Added Jabber Registrar considerations and XML schema.

     +

    Added XMPP Registrar considerations and XML schema.

     0.3 @@ -44,7 +44,7 @@ 0.1 2006-05-30 psa -

    Initial JEP version.

     +

    Initial version.

         0.0.2 @@ -62,8 +62,8 @@

    Jabber instant messaging technologies have long supported the ability for IM users to be online but appear invisible. The existing protocols for doing so are:

      -

    • &jep0018; -- this protocol is not compatible with &xmppcore; and &xmppim;, and it does not provide reliable documentation of the protocol in use since many server implementations support presence of type "invisible" but not presence of type "visible".

      • -

    • &jep0126; -- this protocol is in many ways a mis-use of privacy lists for the temporary purpose of appearing invisible rather than the intended purpose of permanently blocking communications.

      • +

    • &xep0018; -- this protocol is not compatible with &xmppcore; and &xmppim;, and it does not provide reliable documentation of the protocol in use since many server implementations support presence of type "invisible" but not presence of type "visible".

      • +

    • &xep0126; -- this protocol is in many ways a mis-use of privacy lists for the temporary purpose of appearing invisible rather than the intended purpose of permanently blocking communications.

    In order to provide a standards-compliant protocol that can be used in the long term, this document defines an IQ-based protocol that enables an IM user to "go invisible" and "go visible" at will within the context of a given session.

     @@ -77,7 +77,7 @@ -

    In order for a client to discover whether its server supports the protocol defined herein, it MUST send a &jep0030; information request to the server:

    +

    In order for a client to discover whether its server supports the protocol defined herein, it MUST send a &xep0030; information request to the server:

    @@ -106,7 +106,7 @@ ]]> -

    (Standard XMPP stanza errors apply; see RFC 3920 and &jep0086;.)

    +

    (Standard XMPP stanza errors apply; see RFC 3920 and &xep0086;.)

    If the client enters invisible mode after having previously sent undirected presence with no 'type' attribute (e.g., after sending initial presence), the server MUST send &UNAVAILABLE; presence from the client's resource to all contacts who would receive unavailable presence if the client sent &UNAVAILABLE;.

    While the client is in invisible mode, the server:

      @@ -137,9 +137,9 @@

      It is possible to leak presence while in invisible mode (for example, by sending a message, IQ, or presence stanza to a contact). A client SHOULD warn a user before allowing the client to generate any outbound traffic and MUST NOT respond to IQ requests received from entities with which it has not initiated communications while in invisible mode (e.g., by sending messages, IQs, or directed presence).

      -

      No interaction with &IANA; is required as a result of this JEP.

      +

      No interaction with &IANA; is required as a result of this document.

       - +

      The ®ISTRAR; shall include 'http://jabber.org/protocol/invisibility' in its registry of protocol namespaces (see &NAMESPACES;).

       @@ -167,4 +167,4 @@ ]]>       - + diff --git a/xep-0187.xml b/xep-0187.xml index a85cf43c..45f13921 100644 --- a/xep-0187.xml +++ b/xep-0187.xml @@ -1,6 +1,6 @@ - + %ents; y"> x"> @@ -40,8 +40,8 @@ 1...xZ"> 1...eZ"> ]> - - + +
      Offline Encrypted Sessions This document specifies an end-to-end encryption protocol for offline XMPP communication sessions. @@ -57,13 +57,13 @@ RFC 3526 RFC 3548 xml-c14n - JEP-0004 - JEP-0020 - JEP-0068 - JEP-0079 - JEP-0116 - JEP-0155 - JEP-0163 + XEP-0004 + XEP-0020 + XEP-0068 + XEP-0079 + XEP-0116 + XEP-0155 + XEP-0163 None None @@ -73,19 +73,19 @@ 0.2 2006-07-19 ip -

      Removed public key IDs from Offline options; harmonised session termination with the protocol added to JEP-0155; renamed logging field to otr

       +

      Removed public key IDs from Offline options; harmonised session termination with the protocol added to XEP-0155; renamed logging field to otr

       0.1 2006-07-18 ip -

      Initial version (extracted from JEP-0116 version 0.9).

       +

      Initial version (extracted from XEP-0116 version 0.9).
      -

      The convenience of sending stanzas to other entities that are offline ("offline messages") is an important and popular feature of most XMPP implementations (see &jep0160;). Without offline messages delivery would have to wait until both entities managed to be online at the same time. So many urgent messages could not be delivered in time. For example, the sender might want to send an urgent message before jumping on a flight.

      -

      End-to-end encryption is another desirable feature for any communication technology. Unfortunately it is not possible to make offline encryption quite so secure as online encryption (see Security Considerations). However, offline encryption has a long history and is certainly preferable to having no encryption at all. This protocol does not stop paranoid users avoiding sending offline messages. Unfortunately, for reasons described in &jep0188;, the existing proposals (including &jep0027; and &rfc3923;) have not been widely implemented and deployed. This document describes a different approach to offline end-to-end encryption for use by entities that communicate using XMPP. It builds on the existing online &jep0116; protocol. As a result it offers important advantages over the existing "Object Encryption" proposals:

      +

      The convenience of sending stanzas to other entities that are offline ("offline messages") is an important and popular feature of most XMPP implementations (see &xep0160;). Without offline messages delivery would have to wait until both entities managed to be online at the same time. So many urgent messages could not be delivered in time. For example, the sender might want to send an urgent message before jumping on a flight.

      +

      End-to-end encryption is another desirable feature for any communication technology. Unfortunately it is not possible to make offline encryption quite so secure as online encryption (see Security Considerations). However, offline encryption has a long history and is certainly preferable to having no encryption at all. This protocol does not stop paranoid users avoiding sending offline messages. Unfortunately, for reasons described in &xep0188;, the existing proposals (including &xep0027; and &rfc3923;) have not been widely implemented and deployed. This document describes a different approach to offline end-to-end encryption for use by entities that communicate using XMPP. It builds on the existing online &xep0116; protocol. As a result it offers important advantages over the existing "Object Encryption" proposals:

      • Perfect Forward Secrecy Long-lived keys are typically used for a few years, whereas Offline ESession decryption keys typically exist for just a few hours. So the Perfect Forward Secrecy feature significantly enhances the security of Offline ESessions.
      • Other security features described in Cryptographic Design of Encrypted Sessions
        • @@ -95,10 +95,10 @@ -

        This JEP introduces two characters to help the reader follow the necessary exchanges:

        +

        This document introduces two characters to help the reader follow the necessary exchanges:

          -
        1. "Bob" is the name of the online participant in the offline ESession. Within the scope of this JEP, his fully-qualified JID is: <bob@example.com/laptop>.
          2. -
        2. "Alice" is the name of the offline participant in the offline ESession started by Bob. Within the scope of this JEP, we stipulate that her fully-qualified JID is: <alice@example.org/pda>.
          3. +
        3. "Bob" is the name of the online participant in the offline ESession. Within the scope of this document, his fully-qualified JID is: <bob@example.com/laptop>.
          4. +
        4. "Alice" is the name of the offline participant in the offline ESession started by Bob. Within the scope of this document, we stipulate that her fully-qualified JID is: <alice@example.org/pda>.

        While Bob and Alice are introduced as "end users", they are simply meant to be examples of Jabber entities. Any directly addressable Jabber entity may participate in an offline ESession.

         @@ -110,11 +110,11 @@

        In order to publish either set of her offline ESession options Alice MUST create an options data form in exactly the same way as she would create an online ESession request data form (see the ESession Request section in Encrypted Sessions) except she MUST omit The 'accept' and 'pk_hash' fields. Note: The list of stanza types she is willing to decrypt MUST NOT include the value 'iq'.

        -

        Alice MUST append to the content of the form an 'expires' field containing the UTC time (see &jep0082;) that she decides her offline ESession options will expire (see Options Expiry Time Security Considerations).

        +

        Alice MUST append to the content of the form an 'expires' field containing the UTC time (see &xep0082;) that she decides her offline ESession options will expire (see Options Expiry Time Security Considerations).

        Alice MUST store her value of &NsubA; (her ESession ID), all her values of x (one for each MODP group) and the time she decides her offline ESession options will expire in a secure way, so that she can retrieve them when she comes back online (idealy even if that is using a different client and/or a different machine).

        If Alice would not be able to decrypt stanzas if she came back online using a different client and/or a different machine then she SHOULD also encapsulate the resource of her client in a 'match_resource' field and append it to her options data form. In this case, the list of stanza types she is willing to decrypt MUST include only 'message'.

        Alice MUST also append to the content of the form a list of signatures (see Signature Generation) of the content of the data form (excluding the 'signs' field). The list SHOULD include one signature for each of the public signature-verification keys that other entities may use to authenticate her.

        -

        Alice MUST publish the ESession options data form through her own server using &jep0163;.

        +

        Alice MUST publish the ESession options data form through her own server using &xep0163;.

        If the pubkey PEP node does not exist already then Alice MUST create it first. In this case, Alice SHOULD specify the "Presence" access model for the set of options for presence subscribers (or the "Open" model for the set for other entities), unless she wants greater control over access to her identity (see Identity Protection Security Considerations). Alice SHOULD specify that the options will never be pushed to subscribers (even when she publishes new options) - especially if she specifies the "Whitelist" access model.

        @@ -245,7 +245,7 @@ ]]>         -

        If Bob believes Alice is offline he SHOULD request her ESession options and, if he does not have a local copy of any of her public keys, her long-term public signature-verification keys from her server using Personal Eventing via Pubsub (see &jep0189;). There is no need for Bob to discover Alice's support for the Offline ESessions protocol via &jep0030;.

        +

        If Bob believes Alice is offline he SHOULD request her ESession options and, if he does not have a local copy of any of her public keys, her long-term public signature-verification keys from her server using Personal Eventing via Pubsub (see &xep0189;). There is no need for Bob to discover Alice's support for the Offline ESessions protocol via &xep0030;.

        If Bob is subscribing to Alice's presence he MUST request her ESession Options exclusively for subscribers.

        Alice MUST NOT send encrypted content within an offline ESession started by Bob. If Bob is conducting an offline ESession with Alice when she is online (e.g., if he is not subscribing to her presence), then if Alice wants to send a stanza to Bob, she MUST terminate the offline ESession and start a new online ESession first.

        -

        For Offline ESessions, Bob SHOULD include a 'Created' SHIM header in the encrypted content. Assuming she trusts Bob, Alice SHOULD trust this header and ignore the unencrypted &jep0091; element inserted by her server.

        +

        For Offline ESessions, Bob SHOULD include a 'Created' SHIM header in the encrypted content. Assuming she trusts Bob, Alice SHOULD trust this header and ignore the unencrypted &xep0091; element inserted by her server.

        -

        This JEP requires no interaction with &IANA;.

        +

        This document requires no interaction with &IANA;.

        - +

        The ®ISTRAR; shall add 'http://jabber.org/protocol/esession#subscription' to its registry of protocol namespaces.

         - + diff --git a/xep-0188.xml b/xep-0188.xml index 603a6cd4..bdf729bf 100644 --- a/xep-0188.xml +++ b/xep-0188.xml @@ -1,6 +1,6 @@ - + %ents; y"> x"> @@ -40,8 +40,8 @@ 1...xZ"> 1...eZ"> ]> - - + +
        Cryptographic Design of Encrypted Sessions This document describes the requirements and cryptographic design that underpin the XMPP protocol extensions Encrypted Sessions and Offline Encrypted Sessions. @@ -68,39 +68,39 @@ 0.1 2006-07-18 ip -

        Initial version (extracted from JEP-0116 version 0.9).

         +

        Initial version (extracted from XEP-0116 version 0.9).
        -

        Note: The protocols developed according to the requirements and cryptographic design described in this JEP are documented in &jep0116; and &jep0187;. The information in those JEPs should be sufficient for implementors. This purely informative JEP is primarily for people interested in the design and analysis of those protocols.

        +

        Note: The protocols developed according to the requirements and cryptographic design described in this document are described in &xep0116; and &xep0187;. The information in those documents should be sufficient for implementors. This purely informative document is primarily for people interested in the design and analysis of those protocols.

        As specified in &rfc3920;, XMPP is an XML streaming protocol that enables the near-real-time exchange of XML fragments between any two (or more) network endpoints. To date, the main application built on top of the core XML streaming layer is instant messaging (IM) and presence, the base extensions for which are specified in &rfc3921;. There are three first-level elements of XML streams (&MESSAGE;, &PRESENCE;, and &IQ;); each of these "XML stanza" types has different semantics, which can complicate the task of defining a generalized approach to end-to-end encryption for XMPP. In addition, XML stanzas can be extended (via properly-namespaced child elements) for a wide variety of functionality.

        XMPP is a session-oriented communication technology: normally, a client authenticates with a server and maintains a long-lived connection that defines the client's XMPP session. Such stream-level sessions may be secured via channel encryption using Transport Level Security (&rfc2246;), as specified in Section 5 of RFC 3920. However, there is no guarantee that all hops will implement or enforce channel encryption (or that intermediate servers are trustworthy), which makes end-to-end encryption desirable.

        -

        The encrypted stanzas should be understood by an intermediate server only to the extent required to route them. (One complicating factor is that routing information may include not only the stanza's 'to', 'from', 'type, and 'id' attributes, but also &jep0079; extensions.)

        -

        The session metaphor also applies to communication between endpoints: for instance, in IM applications, most instant messaging exchanges occur in bursts within limited time periods (e.g., two people may send a fairly large number of messages during a five-minute chat and then not exchange messages again for hours or even days). The XML stanzas exchanged during such a session may not be limited to &MESSAGE; stanzas; for instance, the session may be triggered by a change in one of the parties' presence status (e.g., changing from away to available) and the session may involve the exchange of &IQ; stanzas (e.g., to transfer a file as specified in &jep0096;).

        +

        The encrypted stanzas should be understood by an intermediate server only to the extent required to route them. (One complicating factor is that routing information may include not only the stanza's 'to', 'from', 'type, and 'id' attributes, but also &xep0079; extensions.)

        +

        The session metaphor also applies to communication between endpoints: for instance, in IM applications, most instant messaging exchanges occur in bursts within limited time periods (e.g., two people may send a fairly large number of messages during a five-minute chat and then not exchange messages again for hours or even days). The XML stanzas exchanged during such a session may not be limited to &MESSAGE; stanzas; for instance, the session may be triggered by a change in one of the parties' presence status (e.g., changing from away to available) and the session may involve the exchange of &IQ; stanzas (e.g., to transfer a file as specified in &xep0096;).

        The foregoing XMPP communications exist in the context of a one-to-one communication session between two entities. However, several forms of XMPP communication exist outside the context of one-to-one communication sessions:

          -
        • Many-to-many sessions, such as a text conference in a chatroom as specified in &jep0045;.
          • -
        • One-to-many "broadcast", such as undirected presence stanzas sent from one user to many contacts (see RFC 3921) and data syndication implemented using &jep0060;.
          • +
        • Many-to-many sessions, such as a text conference in a chatroom as specified in &xep0045;.
          • +
        • One-to-many "broadcast", such as undirected presence stanzas sent from one user to many contacts (see RFC 3921) and data syndication implemented using &xep0060;.
        • One-to-one communications that are stored for later delivery rather than delivered immediately, such as so-called "offline messages".
         -

        Ideally, any technology for end-to-end encryption in XMPP could be extended to cover all the scenarios above as well as one-to-one communication sessions. However, both many-to-many sessions and one-to-many broadcast are deemed out of scope for this JEP.

        +

        Ideally, any technology for end-to-end encryption in XMPP could be extended to cover all the scenarios above as well as one-to-one communication sessions. However, both many-to-many sessions and one-to-many broadcast are deemed out of scope for this document.

        Offline communications are handled via a simple extension to the protocol for one-to-one sessions between two entities that are online simultaneously (see below).

         -

        Existing approaches to encryption of Internet communications have generally assumed that the "thing" to be encrypted has a stable identity or is best understood as a standalone object (e.g., a file or email message); the term "object encryption" well captures this assumption. Both &jep0027; and &rfc3923; assume that XMPP communications are more like the exchange of email messages than they are like an interactive session -- while Current Jabber OpenPGP Usage uses "old-style" PGP object encryption and RFC 3923 uses "new-style" S/MIME object encryption, both specify the use of object encryption.

        +

        Existing approaches to encryption of Internet communications have generally assumed that the "thing" to be encrypted has a stable identity or is best understood as a standalone object (e.g., a file or email message); the term "object encryption" well captures this assumption. Both &xep0027; and &rfc3923; assume that XMPP communications are more like the exchange of email messages than they are like an interactive session -- while Current Jabber OpenPGP Usage uses "old-style" PGP object encryption and RFC 3923 uses "new-style" S/MIME object encryption, both specify the use of object encryption.

        However, because XMPP is a session-oriented communication technology, encryption schemes that are appropriate for other Internet technologies may not be appropriate for XMPP. XMPP, with its in-order delivery of XML stanzas, is able to take advantage of more secure approaches to encryption that are not feasible for less dynamic technologies (like email).

        The session-oriented nature of XMPP implies that the focus should be on "session encryption" rather than "object encryption". The paradigm for XMPP encryption should be something closer to the widely-deployed Secure Shell technology (see &rfc4301; and &rfc4253;) than to traditional encryption of files and standalone email messages.

        -

        Therefore, this JEP specifies a method for encrypted sessions ("ESessions") that takes advantage of the inherent possibilities and strengths of session encryption as opposed to object encryption. The conceptual model for this approach was inspired by "off-the-record" (OTR) communication, as implemented in the Gaim encryption plugin and described in &otr;. The basic concept is that of an encrypted session which acts as a secure tunnel between two endpoints. Once the tunnel is established, the content of all one-to-one XML stanzas exchanged between the endpoints will be encrypted and then transmitted within a "wrapper" protocol element.

        -

        Note: In order to gain a thorough understanding of this JEP, it is recommended that the Off-the-Record Communication paper is read first.

        +

        Therefore, this document specifies a method for encrypted sessions ("ESessions") that takes advantage of the inherent possibilities and strengths of session encryption as opposed to object encryption. The conceptual model for this approach was inspired by "off-the-record" (OTR) communication, as implemented in the Gaim encryption plugin and described in &otr;. The basic concept is that of an encrypted session which acts as a secure tunnel between two endpoints. Once the tunnel is established, the content of all one-to-one XML stanzas exchanged between the endpoints will be encrypted and then transmitted within a "wrapper" protocol element.

        +

        Note: In order to gain a thorough understanding of this document, it is recommended that the Off-the-Record Communication paper is read first.

         -

        This JEP introduces two characters to help the reader follow the necessary exchanges:

        +

        This document introduces two characters to help the reader follow the necessary exchanges:

        1. "Alice" is the name of the initiator of the ESession.
        2. "Bob" is the name of the other participant in the ESession started by Alice.
          3. @@ -110,7 +110,7 @@ -

          This JEP stipulates the following security requirements for end-to-end encryption of XMPP communications:

          +

          This document stipulates the following security requirements for end-to-end encryption of XMPP communications:

          • Confidentiality
          • Integrity
            • @@ -135,20 +135,20 @@

            The encrypted communication MUST NOT be revealed even if long-lived keys are compromised in the future (e.g., Steve steals Bob's computer). Long-lived keys are typically used for a few years, whereas Offline ESession keys are destroyed as soon as the stanza is decrypted - they typically exist for just a few hours. So Perfect Forward Secrecy should significantly enhance the security even of Offline ESessions.

            -

            Each party to a conversation MUST know that the other party is who he says he is (Alice must be able to know that Bob really is Bob, and vice versa). The reliable association between an entity and its public keys is beyond the scope of this JEP.

            +

            Each party to a conversation MUST know that the other party is who he says he is (Alice must be able to know that Bob really is Bob, and vice versa). The reliable association between an entity and its public keys is beyond the scope of this document.

            No other entity should be able to identify Alice or Bob. The JIDs they use to route their stanzas are unavoidably vulnerable to interception. However, the public keys they use SHOULD NOT be revealed to other entities using a passive attack. Bob SHOULD also be able to choose between protecting either his public key or Alice's public key from disclosure through active ("man-in-the-middle") attacks.

             -

            Alice and Bob MUST be able to repudiate any stanza that occurs within an ESession. After an ESession has finished, it SHOULD NOT be possible to prove cryptographically that any transcript has not been modified by a third party. Naturally, it is possible that Alice or Bob may retain cleartext versions of the exchanged communications; however, that threat is out of scope for this JEP.

            +

            Alice and Bob MUST be able to repudiate any stanza that occurs within an ESession. After an ESession has finished, it SHOULD NOT be possible to prove cryptographically that any transcript has not been modified by a third party. Naturally, it is possible that Alice or Bob may retain cleartext versions of the exchanged communications; however, that threat is out of scope for this document.

            The protocol must be upgradable so that, if a vulnerability is discovered, a new version can fix it. Alice MUST tell Bob which versions of the protocol she is prepared to support. Then Bob MUST either choose one or reject the ESession. It is exceptionally difficult to design a truly secure authenticated key-exchange protocol. Weaknesses are often only discovered after years of expert cryptographic analysis. In many cases, only the widespread use of a protocol will motivate experts to undertake exhaustive analyses and recommend enhancements.

             -

            In addition to the foregoing security profile, this JEP also stipulates the following application-specific requirements for encrypted communication in the context of Jabber/XMPP technologies:

            +

            In addition to the foregoing security profile, this document also stipulates the following application-specific requirements for encrypted communication in the context of Jabber/XMPP technologies:

            • Generality
            • Implementability
              • @@ -190,7 +190,7 @@

              Authenticated key-exchange is the most challenging part of the design of any secure communication protocol. The ESessions key exchange essentially translates the σLike RFC 2409, this protocol uses variant (ii), as described in Secion 5.4 of the SIGMA paper. key-exchange protocol into the syntax of XMPP. The SIGMA approach to Diffie-Hellman Key Agreement (see &rfc2631;) underpins several standard key-exchange protocols including the Internet Key Exchange (IKE) protocol versions 1 and 2 (see &rfc2409; and &rfc4306;).

              -

              Note: Although this section provides an overview of SIGMA, it is recommended that the SIGMA paper is read first in order to gain a thorough understanding of this JEP.

              +

              Note: Although this section provides an overview of SIGMA, it is recommended that the SIGMA paper is read first in order to gain a thorough understanding of this document.

              The 3-message SIGMA-I-based key exchange protects the identity of the initiator against active attacks. The 4-message SIGMA-R-based key exchange defends the responder's identity against active attacks. The differences between the two versions of the SIGMA protocol are highlighted in the diagrams below.

               @@ -734,15 +734,15 @@ VERIFY(&signB;, &pubKeyB;, &macB;)               -

              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;.

               -

              The authors would like to thank Ian Goldberg for the time he spent reviewing this protocol and for his invaluable suggestions and comments.

              +

              The author would like to thank Ian Goldberg for the time he spent reviewing this protocol and for his invaluable suggestions and comments.

               - + diff --git a/xep-0189.xml b/xep-0189.xml index a7ac7b56..6425c7b5 100644 --- a/xep-0189.xml +++ b/xep-0189.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
              Public Key Publishing This document specifies how an entity may publish its public keys over XMPP. @@ -15,16 +15,13 @@ Standards JIG XMPP Core - JEP-0060 - JEP-0163 + XEP-0060 + XEP-0163 W3C XML Signature None None pubkeys - - http://jabber.org/protocol/pubkeys/pubkeys.xsd - &ianpaterson; 0.2 @@ -40,7 +37,7 @@
              -

              This JEP defines different methods an entity may use for publishing its long-term public keys:

              +

              This document defines different methods an entity may use for publishing its long-term public keys:

              • Publishing public keys to a set of subscribers.
              • Querying another entity for its public keys.
                • @@ -49,7 +46,7 @@ -

                An entity SHOULD use &jep0163; to publish all its long-term public keys via its own server.

                +

                An entity SHOULD use &xep0163; to publish all its long-term public keys via its own server.

                If the pubkeys PEP node does not exist already then the entity MUST create it first. In this case, the entity SHOULD specify that the keys will only be pushed to subscribers whenever new keys are published (i.e. not when subscribers become newly available or when a new subscription is created). If the user wants to control access to his/her identity (see Security Considerations) then the entity MUST also specify an appropriate access model other than "Open".

                @@ -157,7 +154,7 @@ ]]> -

                Note: The stanza containing the event notification (see example above) MAY also include 'replyto' data (as specified by the &jep0033; protocol) to provide an explicit association between the published data and the resource that published it.

                +

                Note: The stanza containing the event notification (see example above) MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the resource that published it.

                -

                The reliable association between a user or entity and its public keys is beyond the scope of this JEP. However, it is RECOMMENDED that each client maintains its own secure library of the public keys (or the "fingerprints" of the keys) it associates with other users (not necessarily JIDs).

                +

                The reliable association between a user or entity and its public keys is beyond the scope of this document. However, it is RECOMMENDED that each client maintains its own secure library of the public keys (or the "fingerprints" of the keys) it associates with other users (not necessarily JIDs).

                Whenever public keys are published an identity is typically associated with a JID. Although the public keys are public information, it may be critically important for the user of the JID to keep his identity secret from all but a few specified people. Implementors MUST take great care to ensure the identity of the user of a JID is never divulged to anyone except the entities who have been permitted by the user to access the public key.

                 -

                This JEP requires no interaction with &IANA;.

                +

                This document requires no interaction with &IANA;.

                 - +

                The ®ISTRAR; shall add 'http://jabber.org/protocol/pubkeys' to its registry of protocol namespaces.

                 @@ -266,13 +263,6 @@ xmlns='http://jabber.org/protocol/pubkeys' elementFormDefault='qualified'> - - - The protocol documented by this schema is defined in - JEP-0189: http://www.jabber.org/jeps/jep-0189.html - - - @@ -284,4 +274,4 @@ ]]>                 - + diff --git a/xep-0190.xml b/xep-0190.xml index eb9d8732..8def536a 100644 --- a/xep-0190.xml +++ b/xep-0190.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
                Best Practice for Closing Idle Streams This document specifies best practice for closing an idle XMPP stream. @@ -29,7 +29,7 @@ 0.1 2006-07-26 psa -

                Initial JEP version.

                 +

                Initial version.

                 0.0.2 @@ -116,8 +116,8 @@

                This proposal requires no interaction with &IANA;.

                 - +

                This proposal requires no interaction with the ®ISTRAR;.

                 - + diff --git a/xep-0191.xml b/xep-0191.xml index 06753265..cb051530 100644 --- a/xep-0191.xml +++ b/xep-0191.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
                Simple Communications Blocking This document specifies an XMPP protocol extension for simple communications blocking. @@ -16,7 +16,7 @@ XMPP Core XMPP IM - JEP-0030 + XEP-0030 None None @@ -32,7 +32,7 @@ 0.1 2006-08-16 psa -

                Initial JEP version.

                 +

                Initial version.

                 0.0.2 @@ -60,7 +60,7 @@ -

                In order for a client to discover whether its server supports the protocol defined herein, it MUST send a &jep0030; information request to the server:

                +

                In order for a client to discover whether its server supports the protocol defined herein, it MUST send a &xep0030; information request to the server:

                @@ -90,7 +90,7 @@ ]]> -

                (Standard XMPP stanza errors apply; see &xmppcore; and &jep0086;.)

                +

                (Standard XMPP stanza errors apply; see &xmppcore; and &xep0086;.)

                Note: The <block/> element MAY contain more than one <item/> child.

                Once the user has blocked communications from the contact, the user's server MUST NOT deliver any XML stanzas from the contact to the user.

                If the contact attempts to send a stanza to the user (i.e., an inbound stanza from the user's perspective), the user's server shall return an error according to the following rules:

                @@ -165,7 +165,7 @@

                When a server receives a block command from a user, it MAY cancel any existing presence subscriptions between the user and the blocked user and MAY send a message to the blocked user; however, it is RECOMMENDED to deploy so-called "polite blocking" instead (i.e., to not cancel the presence subscriptions or send a notification). Which approach to follow is a matter of local service policy.

                -

                A service MAY also filter blocking users out of searches performed on user directories (see, for example, &jep0055;); however, that functionality is out of scope for this specification.

                +

                A service MAY also filter blocking users out of searches performed on user directories (see, for example, &xep0055;); however, that functionality is out of scope for this specification.

                If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in RFC 3920 and RFC 3921.

                @@ -173,7 +173,7 @@

                No interaction with &IANA; is required as a result of this specification.

                 - +

                The ®ISTRAR; shall include 'http://jabber.org/protocol/blocking' and 'http://jabber.org/protocol/blocking#errors' in its registry of protocol namespaces (see &NAMESPACES;).

                 @@ -259,4 +259,4 @@

                Thanks to Valerie Mercier, Maciek Niedzielski, and Remko Tronçon for their feedback.

                 - + diff --git a/xep-0192.xml b/xep-0192.xml index e00ffa43..de489412 100644 --- a/xep-0192.xml +++ b/xep-0192.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
                Proposed Stream Feature Improvements This document proposes improvements to the XML stream features definition for inclusion in the specification that supersedes RFC 3920. @@ -24,7 +24,7 @@ 0.1 2006-08-16 psa -

                Initial JEP version.

                 +

                Initial version.

                 0.0.1 @@ -257,9 +257,9 @@ S2:

                The improvements described herein do not introduce any new security concerns above and beyond those defined in RFC 3920.

                -

                No interaction with &IANA; is required as a result of this JEP.

                +

                No interaction with &IANA; is required as a result of this document.

                 - +

                The ®ISTRAR; shall include 'http://jabber.org/features/dialback' in its registry of stream features.

                The submission is as follows:

                @@ -448,4 +448,4 @@ S2:

                Thanks to Ralph Meijer and Joe Hildebrand for their comments.

                 - + diff --git a/xep-0193.xml b/xep-0193.xml index 00304d8f..326febbe 100644 --- a/xep-0193.xml +++ b/xep-0193.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
                Proposed Resource Binding Improvements This document proposes improvements to the definition of resource binding for inclusion in the specification that supersedes RFC 3920. @@ -24,7 +24,7 @@ 0.1 2006-08-16 psa -

                Initial JEP version.

                 +

                Initial version.

                 0.0.2 @@ -41,7 +41,7 @@
                &BISNOTE; -

                RFC 3920 introduced the concept of binding a resource to an XML stream (this concept superseded part of the older jabber:iq:auth protocol described in &jep0078;). As defined in RFC 3920, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a client daemon that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.

                +

                RFC 3920 introduced the concept of binding a resource to an XML stream (this concept superseded part of the older jabber:iq:auth protocol described in &xep0078;). As defined in RFC 3920, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a client daemon that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.

                In order to properly manage the resources associated with an XML stream, a client must be able to unbind resources. This shall be completed by sending an IQ-set with a child element of <unbind/> qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, which in turn has a child element of <resource/> whose XML character data specifies the resource to be unbound:

                @@ -202,7 +202,7 @@

                No interaction with &IANA; is required as a result of this document.

                 - +

                No interaction with the ®ISTRAR; is required as a result of this document.

                 @@ -257,4 +257,4 @@ ]]> -                 + diff --git a/xep-0194.xml b/xep-0194.xml index 261aa09c..7028aba7 100644 --- a/xep-0194.xml +++ b/xep-0194.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
                User Chatting This document defines an XMPP protocol extension for communicating information about the chatrooms a user visits. @@ -16,8 +16,8 @@ XMPP Core XMPP IM - JEP-0060 - JEP-0163 + XEP-0060 + XEP-0163 @@ -27,7 +27,7 @@ 0.1 2006-08-30 psa -

                Initial JEP version.

                 +

                Initial version.

                 0.0.1 @@ -37,7 +37,7 @@
                -

                &jep0060; and &jep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about the chatrooms a user visits. This information may be of interest to a user's contacts and can also be used in social networking applications.

                +

                &xep0060; and &xep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about the chatrooms a user visits. This information may be of interest to a user's contacts and can also be used in social networking applications.

                 @@ -75,7 +75,7 @@

                NOTE: The datatypes specified above are defined in &w3xmlschema2;.

                 -

                When a user joins a room, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/chatting"). The chatting information SHOULD be communicated and transported by means of the JEP-0060 protocol, especially the subset specified in JEP-0163 (as shown in the following examples). Because chatroom information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.

                +

                When a user joins a room, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/chatting"). The chatting information SHOULD be communicated and transported by means of the XEP-0060 protocol, especially the subset specified in XEP-0163 (as shown in the following examples). Because chatroom information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.

                @@ -142,7 +142,7 @@

                This document requires no interaction with &IANA;.

                 - +

                The ®ISTRAR; shall include 'http://jabber.org/protocol/chatting' in its registry of protocol namespaces.

                 @@ -170,4 +170,4 @@ ]]>                 -                 + diff --git a/xep-0195.xml b/xep-0195.xml index a6e96ceb..8f8be92f 100644 --- a/xep-0195.xml +++ b/xep-0195.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
                User Browsing This document defines an XMPP protocol extension for communicating information about the web pages a user visits. @@ -16,8 +16,8 @@ XMPP Core XMPP IM - JEP-0060 - JEP-0163 + XEP-0060 + XEP-0163 @@ -27,7 +27,7 @@ 0.1 2006-08-30 psa -

                Initial JEP version.

                 +

                Initial version.

                 0.0.1 @@ -37,7 +37,7 @@
                -

                &jep0060; and &jep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about the web pages a user visits. This information may be of interest to a user's contacts and can also be used in social networking applications (e.g., co-browsing and web swarms).

                +

                &xep0060; and &xep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about the web pages a user visits. This information may be of interest to a user's contacts and can also be used in social networking applications (e.g., co-browsing and web swarms).

                 @@ -82,7 +82,7 @@

                NOTE: The datatypes specified above are defined in &w3xmlschema2;.

                 -

                When a user visits a web page, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/browsing"). The web page information SHOULD be communicated and transported by means of the JEP-0060 protocol, especially the subset specified in JEP-0163 (as shown in the following examples). Because browsing information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.

                +

                When a user visits a web page, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/browsing"). The web page information SHOULD be communicated and transported by means of the XEP-0060 protocol, especially the subset specified in XEP-0163 (as shown in the following examples). Because browsing information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.

                @@ -147,7 +147,7 @@

                This document requires no interaction with &IANA;.

                 - +

                The ®ISTRAR; shall include 'http://jabber.org/protocol/browsing' in its registry of protocol namespaces.

                 @@ -176,4 +176,4 @@ ]]>                 -                 + diff --git a/xep-0196.xml b/xep-0196.xml index d915d5b2..5d938e3e 100644 --- a/xep-0196.xml +++ b/xep-0196.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
                User Gaming This document defines an XMPP protocol extension for communicating information about the games a user plays. @@ -16,8 +16,8 @@ XMPP Core XMPP IM - JEP-0060 - JEP-0163 + XEP-0060 + XEP-0163 @@ -27,7 +27,7 @@ 0.1 2006-08-30 psa -

                Initial JEP version; added several more fields.

                 +

                Initial version; added several more fields.

                 0.0.1 @@ -37,7 +37,7 @@
                -

                &jep0060; and &jep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about the games a user plays. This information may be of interest to a user's contacts and can also be used in social networking applications.

                +

                &xep0060; and &xep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about the games a user plays. This information may be of interest to a user's contacts and can also be used in social networking applications.

                 @@ -103,7 +103,7 @@

                NOTE: The datatypes specified above are defined in &w3xmlschema2;.

                 -

                When a user starts playing a game, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/gaming"). The gaming information SHOULD be communicated and transported by means of the JEP-0060 protocol, especially the subset specified in JEP-0163 (as shown in the following examples). Because gaming information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.

                +

                When a user starts playing a game, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/gaming"). The gaming information SHOULD be communicated and transported by means of the XEP-0060 protocol, especially the subset specified in XEP-0163 (as shown in the following examples). Because gaming information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.

                @@ -170,7 +170,7 @@

                This document requires no interaction with &IANA;.

                 - +

                The ®ISTRAR; shall include 'http://jabber.org/protocol/gaming' in its registry of protocol namespaces.

                 @@ -202,4 +202,4 @@ ]]>                 -                 + diff --git a/xep-0197.xml b/xep-0197.xml index ea98f0d2..3482e475 100644 --- a/xep-0197.xml +++ b/xep-0197.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
                User Viewing This document defines an XMPP protocol extension for communicating information about the television shows, movies, or other videos that a user watches. @@ -16,8 +16,8 @@ XMPP Core XMPP IM - JEP-0060 - JEP-0163 + XEP-0060 + XEP-0163 @@ -33,7 +33,7 @@ 0.1 2006-08-30 psa -

                Initial JEP version.

                 +

                Initial version.

                 0.0.1 @@ -43,7 +43,7 @@
                -

                &jep0060; and &jep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about the television shows, movies, or other videos that a user watches. This information may be of interest to a user's contacts and can also be used in social networking applications (e.g., IPTV systems).

                +

                &xep0060; and &xep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about the television shows, movies, or other videos that a user watches. This information may be of interest to a user's contacts and can also be used in social networking applications (e.g., IPTV systems).

                 @@ -144,7 +144,7 @@

                NOTE: The datatypes specified above are defined in &w3xmlschema2;.

                 -

                When a user starts watching a video, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/viewing"). The viewing information SHOULD be communicated and transported by means of the JEP-0060 protocol, especially the subset specified in JEP-0163 (as shown in the following examples). Because viewing information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.

                +

                When a user starts watching a video, its client may publish that fact to a special pubsub or PEP node (if a PEP node, the NodeID is "http://jabber.org/protocol/viewing"). The viewing information SHOULD be communicated and transported by means of the XEP-0060 protocol, especially the subset specified in XEP-0163 (as shown in the following examples). Because viewing information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.

                @@ -215,7 +215,7 @@

                This document requires no interaction with &IANA;.

                 - +

                The ®ISTRAR; shall include 'http://jabber.org/protocol/viewing' in its registry of protocol namespaces.

                 @@ -254,4 +254,4 @@ ]]>                 -                 +