moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-23 01:32:22 -05:00
Code Issues Releases Wiki Activity

JEP to XEP

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@50 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-04 18:02:04 +00:00
parent 0392f0dfcb
commit 2d4af4ea52
18 changed files with 238 additions and 248 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
xep-0180.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jingle Video Content Description Format</title>
<abstract>This document defines a content description format for Jingle video sessions.</abstract>
@ -16,7 +16,7 @@
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0166</spec>
<spec>XEP-0166</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -31,7 +31,7 @@
<version>0.3</version>
<date>2006-08-23</date>
<initials>psa</initials>
<remark><p>Modified namespace to track JEP-0166.</p></remark>
<remark><p>Modified namespace to track XEP-0166.</p></remark>
</revision>
<revision>
<version>0.2</version>
@ -43,7 +43,7 @@
<version>0.1</version>
<date>2006-03-23</date>
<initials>psa/mc</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -53,7 +53,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&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.</p>
<p>&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.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The Jingle content description format defined herein is designed to meet the following requirements:</p>
@ -73,7 +73,7 @@
<payload-type id='13' name='CN'/>
</description>
]]></example>
<p>The &DESCRIPTION; element is intended to be a child of a &JINGLE; element as specified in <cite>JEP-0166</cite>.</p>
<p>The &DESCRIPTION; element is intended to be a child of a &JINGLE; element as specified in <cite>XEP-0166</cite>.</p>
<p>The defined attributes of the &PAYLOADTYPE; element are as follows:</p>
<table caption='Video Description Attributes'>
<tr>
@ -132,7 +132,7 @@
<p>To follow.</p>
</section1>
<section1 topic='Service Discovery' anchor='disco'>
<p>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.</p>
<p>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.</p>
<example caption="Service Discovery Information Request"><![CDATA[
<iq from='romeo@montague.net/orchard'
id='disco1'
@ -167,19 +167,19 @@
<p>The description of a format for video sessions introduces no known security vulnerabilities.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/jingle/description/video' and 'http://jabber.org/protocol/jingle/info/video' in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Jingle Content Description Formats' anchor='registrar-content'>
<p>The Jabber Registrar shall include the name "video" in its registry of Jingle content description formats. The registration is as follows:</p>
<p>The XMPP Registrar shall include the name "video" in its registry of Jingle content description formats. The registration is as follows:</p>
<code><![CDATA[
<content>
<name>video</name>
<desc>Jingle sessions that support video exchanges</desc>
<doc>JEP-xxxx</doc>
<doc>XEP-xxxx</doc>
</content>
]]></code>
</section2>
@ -235,4 +235,4 @@
<p>To follow.</p>
</section2>
</section1>
</jep>
</xep>

20
xep-0181.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jingle DTMF</title>
<abstract>This document specifies an XML format for encapsulating DTMF data in informational messages sent within the context of Jingle audio interactions.</abstract>
@ -16,7 +16,7 @@
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0166</spec>
<spec>XEP-0166</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -39,7 +39,7 @@
<version>0.1</version>
<date>2006-03-23</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -49,7 +49,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>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.</p>
<p>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.</p>
</section1>
<section1 topic='Tone Format' anchor='format'>
<p>The format for the XML DTMF format is as follows:</p>
@ -121,9 +121,9 @@
<p>This document introduces no known security vulnerabilities.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/jingle/info/dtmf' in its registry of protocol namespaces.</p>
</section2>
@ -173,4 +173,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

20
xep-0182.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Application-Specific Error Conditions</title>
<abstract>This document defines a registry of application-specific error conditions.</abstract>
@ -38,7 +38,7 @@
<version>0.1</version>
<date>2006-03-23</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -62,10 +62,10 @@
]]></example>
<p>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 &REGISTRAR;. 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., &lt;stanza-too-big/&gt; as a particular form of the &notacceptable; condition).</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Application-Specific Error Conditions Registry' anchor='registrar-conditions'>
<p>The Jabber Registrar maintains a registry of application-specific error conditions (see &APPERRORS;).</p>
<p>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.</p>
<p>The XMPP Registrar maintains a registry of application-specific error conditions (see &APPERRORS;).</p>
<p>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.</p>
<section3 topic='Registration Process' anchor='registrar-conditions-process'>
&REGPROCESS;
<code><![CDATA[
@ -87,6 +87,6 @@
<p>This document introduces no known security vulnerabilities.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
</jep>
</xep>

34
xep-0183.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jingle Telepathy Transport</title>
<abstract>This document defines a telepathic transport method for establishing Extra-Sensory Perception (ESP) streams.</abstract>
@ -16,7 +16,7 @@
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0166</spec>
<spec>XEP-0166</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -30,9 +30,9 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&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.</p>
<p>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&#233;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.</p>
<p>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.</p>
<p>&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.</p>
<p>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&#233;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.</p>
<p>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.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The Jingle telepathy transport method is designed to meet the following requirements:</p>
@ -45,7 +45,7 @@
</section1>
<section1 topic='Protocol Description' anchor='protocol'>
<section2 topic='Transport Initiation' anchor='protocol-initiate'>
<p>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 <cite>JEP-0166</cite>. 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.</p>
<p>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 <cite>XEP-0166</cite>. 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.</p>
<p>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:</p>
<example caption="Initiation Example"><![CDATA[
<iq from='medium@example.com/seance' to='psychic@example.net/spiritworld' id='jingle1' type='set'>
@ -68,13 +68,13 @@
<li>The 'name' attribute specifies a unique name for the channel.</li>
<li>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.</li>
<li>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.</li>
<li>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;.</li>
<li>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;.</li>
<li>The 'sign' attribute represents the initiator's Zodiac sign; including this value obviates the need for asking "what's your sign?"</li>
<li>The 'time' attribute is used for diagnostics; the allowable values are "past", "present", and "future".</li>
</ul>
</section2>
<section2 topic='Target Entity Response' anchor='protocol-response'>
<p>As described in <cite>JEP-0166</cite>, to provisionally accept the session initiation request, the target entity returns an IQ-result:</p>
<p>As described in <cite>XEP-0166</cite>, to provisionally accept the session initiation request, the target entity returns an IQ-result:</p>
<example caption="Target Entity Provisionally Accepts the Session Request"><![CDATA[
<iq type='result' from='psychic@example.net/spiritworld' to='medium@example.com/seance' id='jingle1'/>
]]></example>
@ -96,7 +96,7 @@
<iq from='medium@example.com/seance' to='psychic@example.net/spiritworld' id='jingle2' type='result'>
]]></example>
<p>Now the initiating entity and target entity can begin sending appropriate psychical media over the negotiated ESP stream.</p>
<p>In the event that the target entity cannot establish a channel, it SHOULD terminate the session (see <cite>JEP-0176</cite> or <cite>JEP-0177</cite> for examples).</p>
<p>In the event that the target entity cannot establish a channel, it SHOULD terminate the session (see <cite>XEP-0176</cite> or <cite>XEP-0177</cite> for examples).</p>
</section2>
<section2 topic='Informational Messages' anchor='protocol-info'>
<p>Because the informational message payloads specific to the telepathy transport method cannot be tied down to the arbitrary conventions of XML syntax, a &lt;message/&gt; element qualified by the 'http://jabber.org/protocol/info/telepathy' namespace may include any character data that either party feels like communicating.</p>
@ -112,22 +112,22 @@
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/telepathy' and 'http://jabber.org/protocol/jingle/info/telepathy' in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Jingle Transport Methods' anchor='registrar-transports'>
<p>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:</p>
<p>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:</p>
<code><![CDATA[
<transport>
<name>telepathy</name>
<desc>
A method for the negotiation of Extra-Sensory Perception (ESP) streams.
</desc>
<doc>JEP-0183</doc>
<doc>XEP-0183</doc>
</transport>
]]></code>
</section2>
@ -220,4 +220,4 @@
]]></code>
</section2>
</section1>
</jep>
</xep>

42
xep-0184.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Message Receipts</title>
<abstract>This document specifies a protocol for XMPP message receipts.</abstract>
<abstract>This document specifies an XMPP protocol extension for message receipts.</abstract>
&LEGALNOTICE;
<number>0184</number>
<status>Experimental</status>
@ -18,7 +18,7 @@
<spec>XMPP Core</spec>
</dependencies>
<supersedes>
<spec>JEP-0022 (in part)</spec>
<spec>XEP-0022 (in part)</spec>
</supersedes>
<supersededby/>
<shortname>amp-receipts</shortname>
@ -34,7 +34,7 @@
<version>0.1</version>
<date>2006-04-11</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
@ -50,7 +50,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>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.</p>
<p>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.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This document addresses the following requirements:</p>
@ -162,21 +162,21 @@ S R
<p>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.</p>
</section1>
<section1 topic='Protocol Format' anchor='format'>
<p>In order to make it possible for senders to request, and for recipients to generate, message receipts, we define a new <cite>Advanced Message Processing</cite> rule: "receipt". In accordance with <cite>JEP-0079</cite>, we provide the following information about the receipt rule:</p>
<p>In order to make it possible for senders to request, and for recipients to generate, message receipts, we define a new <cite>Advanced Message Processing</cite> rule: "receipt". In accordance with <cite>XEP-0079</cite>, we provide the following information about the receipt rule:</p>
<ul>
<li>The namespace shall be "http://jabber.org/protocol/amp?condition=receipt".</li>
<li>The condition applies only to final receipt by the intended recipient; therefore, the per-hop flag does not apply.</li>
<li>The only defined value of the receipt rule is "received".</li>
<li>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 <note>Therefore this specification does not distinguish between delivery and presentation, as was done in &jep0022;.</note> 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.</li>
<li>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 <note>Therefore this specification does not distinguish between delivery and presentation, as was done in &xep0022;.</note> 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.</li>
</ul>
</section1>
<section1 topic='Protocol Format' anchor='format'>
<p>In order to make it possible for senders to request, and for recipients to generate, message receipts, we define a new <cite>Advanced Message Processing</cite> rule: "receipt". In accordance with <cite>JEP-0079</cite>, we provide the following information about the receipt rule:</p>
<p>In order to make it possible for senders to request, and for recipients to generate, message receipts, we define a new <cite>Advanced Message Processing</cite> rule: "receipt". In accordance with <cite>XEP-0079</cite>, we provide the following information about the receipt rule:</p>
<ul>
<li>The namespace shall be "http://jabber.org/protocol/amp?condition=receipt".</li>
<li>The condition applies only to final receipt by the intended recipient; therefore, the per-hop flag does not apply.</li>
<li>The only defined value of the receipt rule is "received".</li>
<li>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 <note>Therefore this specification does not distinguish between delivery and presentation, as was done in &jep0022;.</note> 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.</li>
<li>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 <note>Therefore this specification does not distinguish between delivery and presentation, as was done in &xep0022;.</note> 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.</li>
<li>Although any defined action may be triggered, the only action needed in order to support message receipts is the "notify" action.</li>
</ul>
<p>The following is an example of a message that includes a request for return receipt.</p>
@ -204,17 +204,17 @@ S R
]]></example>
</section1>
<section1 topic='Business Rules' anchor='rules'>
<p>The general business rules specified for Advanced Message Processing in <cite>JEP-0079</cite> apply to any rule; in addition, the following business rules apply specifically to the receipt rule:</p>
<p>The general business rules specified for Advanced Message Processing in <cite>XEP-0079</cite> apply to any rule; in addition, the following business rules apply specifically to the receipt rule:</p>
<ol start='1'>
<li><p>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;).</p></li>
<li><p>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;.</p></li>
<li><p>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;.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
</ol>
<p>Naturally, the receipt rule can be combined wiith rules specified in <cite>JEP-0079</cite> (e.g., the deliver rule) for more complete reporting.</p>
<p>Naturally, the receipt rule can be combined wiith rules specified in <cite>XEP-0079</cite> (e.g., the deliver rule) for more complete reporting.</p>
</section1>
<section1 topic='Protocol Flows' anchor='flow'>
<p>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.</p>
@ -435,7 +435,7 @@ S R
</section1>
<section1 topic='Service Discovery' anchor='disco'>
<p>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 <cite>Entity Capabilities</cite> or directly via <cite>Service Discovery</cite>.</p>
<p>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 <cite>JEP-0079</cite>:</p>
<p>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 <cite>XEP-0079</cite>:</p>
<example caption="Initial Service Discovery information request"><![CDATA[
<iq from='northumberland@shakespeare.lit/westminster'
to='kingrichard@royalty.england.lit/throne'
@ -532,7 +532,7 @@ S R
<section1 topic='IANA Considerations' anchor='iana'>
<p>No interaction with &IANA; is necessary as a result of this document.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Rule Conditions Registry' anchor='registrar-conditions'>
<p>The &REGISTRAR; maintains a registry of Advanced Message Processing &lt;rule/&gt; conditions (see &AMPCONDITIONS;). The Registrar shall add the following condition to the registry:</p>
<code><![CDATA[
@ -546,19 +546,19 @@ S R
controlled by the intended recipient has received and processed
the message, including presentation to a human user if appropriate.
</processing>
<doc>JEP-xxxx</doc>
<doc>XEP-xxxx</doc>
</condition>
]]></code>
</section2>
<section2 topic='Field Standardization' anchor='registrar-formtype'>
<p>&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:</p>
<p>&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:</p>
<code caption='Registry Submission'><![CDATA[
<form_type>
<name>http://jabber.org/protocol/chatneg</name>
<field
var='http://jabber.org/protocol/amp?condition=receipt'
type='boolean'
label='Whether to enable Message Receipts per JEP-0184'/>
label='Whether to enable Message Receipts per XEP-0184'/>
</form_type>
]]></code>
</section2>
@ -566,4 +566,4 @@ S R
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Joe Kemp for his input.</p>
</section1>
</jep>
</xep>

20
xep-0185.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Dialback Key Generation and Validation</title>
<abstract>This document explains how to generate and validate the keys used in the XMPP server dialback protocol.</abstract>
@ -38,7 +38,7 @@
<version>0.1</version>
<date>2006-04-11</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -242,12 +242,12 @@ SHA1('example.orgexample.com457F9224A0') =
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This JEP introduces no security considerations or concerns above and beyond those discussed in <cite>RFC3920</cite>, but describes what might happen if the security considerations are ignored.</p>
<p>This document introduces no security considerations or concerns above and beyond those discussed in <cite>RFC3920</cite>, but describes what might happen if the security considerations are ignored.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<p>This JEP requires no interaction with the &REGISTRAR;.</p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
</jep>
</xep>

28
xep-0186.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Invisible Command</title>
<abstract>This document specifies an XMPP-compatible protocol for user invisibility.</abstract>
@ -16,7 +16,7 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
@ -26,7 +26,7 @@
<version>0.4</version>
<date>2006-08-09</date>
<initials>psa</initials>
<remark><p>Added Jabber Registrar considerations and XML schema.</p></remark>
<remark><p>Added XMPP Registrar considerations and XML schema.</p></remark>
</revision>
<revision>
<version>0.3</version>
@ -44,7 +44,7 @@
<version>0.1</version>
<date>2006-05-30</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
@ -62,8 +62,8 @@
<section1 topic='Introduction' anchor='intro'>
<p>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:</p>
<ul>
<li><p>&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".</p></li>
<li><p>&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.</p></li>
<li><p>&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".</p></li>
<li><p>&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.</p></li>
</ul>
<p>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.</p>
</section1>
@ -77,7 +77,7 @@
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Discovering Support' anchor='disco'>
<p>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:</p>
<p>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:</p>
<example caption='Service discovery request'><![CDATA[
<iq from='bilbo@tolkien.lit/shire' to='tolkien.lit' type='get' id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@ -106,7 +106,7 @@
<example caption='Invisible command is successful'><![CDATA[
<iq type='result' id='inv1'/>
]]></example>
<p>(Standard XMPP stanza errors apply; see <cite>RFC 3920</cite> and &jep0086;.)</p>
<p>(Standard XMPP stanza errors apply; see <cite>RFC 3920</cite> and &xep0086;.)</p>
<p>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;.</p>
<p>While the client is in invisible mode, the server:</p>
<ol start='1'>
@ -137,9 +137,9 @@
<p>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).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>No interaction with &IANA; is required as a result of this JEP.</p>
<p>No interaction with &IANA; is required as a result of this document.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/invisibility' in its registry of protocol namespaces (see &NAMESPACES;).</p>
</section2>
@ -167,4 +167,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

50
xep-0187.xml
View File

@ -1,6 +1,6 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
<!ENTITY esupy "e<span class='super'>y</span>">
<!ENTITY dsupx "d<span class='super'>x</span>">
@ -40,8 +40,8 @@
<!ENTITY x1xZ "x<span class='sub'>1</span>...x<span class='sub'>Z</span>">
<!ENTITY e1eZ "e<span class='sub'>1</span>...e<span class='sub'>Z</span>">
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Offline Encrypted Sessions</title>
<abstract>This document specifies an end-to-end encryption protocol for offline XMPP communication sessions.</abstract>
@ -57,13 +57,13 @@
<spec>RFC 3526</spec>
<spec>RFC 3548</spec>
<spec>xml-c14n</spec>
<spec>JEP-0004</spec>
<spec>JEP-0020</spec>
<spec>JEP-0068</spec>
<spec>JEP-0079</spec>
<spec>JEP-0116</spec>
<spec>JEP-0155</spec>
<spec>JEP-0163</spec>
<spec>XEP-0004</spec>
<spec>XEP-0020</spec>
<spec>XEP-0068</spec>
<spec>XEP-0079</spec>
<spec>XEP-0116</spec>
<spec>XEP-0155</spec>
<spec>XEP-0163</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
@ -73,19 +73,19 @@
<version>0.2</version>
<date>2006-07-19</date>
<initials>ip</initials>
<remark><p>Removed public key IDs from Offline options; harmonised session termination with the protocol added to JEP-0155; renamed logging field to otr</p></remark>
<remark><p>Removed public key IDs from Offline options; harmonised session termination with the protocol added to XEP-0155; renamed logging field to otr</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2006-07-18</date>
<initials>ip</initials>
<remark><p>Initial version (extracted from JEP-0116 version 0.9).</p></remark>
<remark><p>Initial version (extracted from XEP-0116 version 0.9).</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>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.</p>
<p>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 <link url='#sec'>Security Considerations</link>). However, offline encryption has a long history and is certainly preferable to having no encryption at all. <note>This protocol does not stop paranoid users avoiding sending offline messages.</note> 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:</p>
<p>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.</p>
<p>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 <link url='#sec'>Security Considerations</link>). However, offline encryption has a long history and is certainly preferable to having no encryption at all. <note>This protocol does not stop paranoid users avoiding sending offline messages.</note> 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:</p>
<ul>
<li>Perfect Forward Secrecy <note>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.</note></li>
<li>Other security features described in <cite>Cryptographic Design of Encrypted Sessions</cite></li>
@ -95,10 +95,10 @@
</section1>
<section1 topic="Dramatis Personae" anchor='personae'>
<p>This JEP introduces two characters to help the reader follow the necessary exchanges:</p>
<p>This document introduces two characters to help the reader follow the necessary exchanges:</p>
<ol start='1'>
<li>"Bob" is the name of the online participant in the offline ESession. Within the scope of this JEP, his fully-qualified JID is: &lt;bob@example.com/laptop&gt;.</li>
<li>"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: &lt;alice@example.org/pda&gt;.</li>
<li>"Bob" is the name of the online participant in the offline ESession. Within the scope of this document, his fully-qualified JID is: &lt;bob@example.com/laptop&gt;.</li>
<li>"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: &lt;alice@example.org/pda&gt;.</li>
</ol>
<p>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.</p>
</section1>
@ -110,11 +110,11 @@
<section2 topic="Publishing Offline ESession Options" anchor='init-offline-publish'>
<p>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 <cite>Encrypted Sessions</cite>) 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'.</p>
<p>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 <link url='#sec-expire'>Options Expiry Time</link> Security Considerations).</p>
<p>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 <link url='#sec-expire'>Options Expiry Time</link> Security Considerations).</p>
<p>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).</p>
<p>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'.</p>
<p>Alice MUST also append to the content of the form a list of signatures (see <link url='#sign'>Signature Generation</link>) of the <em>content</em> 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.</p>
<p>Alice MUST publish the ESession options data form through her own server using &jep0163;.</p>
<p>Alice MUST publish the ESession options data form through her own server using &xep0163;.</p>
<p>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 <link url='#sec-identity'>Identity Protection</link> 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.</p>
<example caption='Alice Creates PEP Node for ESession Options for Presence Subscribers'><![CDATA[
<iq from='alice@example.org/pda' type='set' id='create1'>
@ -245,7 +245,7 @@
]]></example>
</section2>
<section2 topic="Requesting Offline ESession Options" anchor='init-offline-request'>
<p>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 <cite>Personal Eventing via Pubsub</cite> (see &jep0189;). <note>There is no need for Bob to discover Alice's support for the Offline ESessions protocol via &jep0030;.</note></p>
<p>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 <cite>Personal Eventing via Pubsub</cite> (see &xep0189;). <note>There is no need for Bob to discover Alice's support for the Offline ESessions protocol via &xep0030;.</note></p>
<p>If Bob is subscribing to Alice's presence he MUST request her ESession Options exclusively for subscribers.</p>
<example caption='Bob asks Alice&apos;s Server for her ESession Options (Subscribers)'><![CDATA[
<iq type='get'
@ -362,7 +362,7 @@
<section1 topic="Exchanging Stanzas" anchor='exchange'>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<example caption='Unencrypted Stanza'><![CDATA[
<message from='bob@example.com/laptop'
to='alice@example.org/pda'
@ -412,11 +412,11 @@
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;. </p>
<p>This document requires no interaction with &IANA;. </p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; shall add 'http://jabber.org/protocol/esession#subscription' to its registry of protocol namespaces.</p>
</section1>
</jep>
</xep>

50
xep-0188.xml
View File

@ -1,6 +1,6 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
<!ENTITY esupy "e<span class='super'>y</span>">
<!ENTITY dsupx "d<span class='super'>x</span>">
@ -40,8 +40,8 @@
<!ENTITY x1xZ "x<span class='sub'>1</span>...x<span class='sub'>Z</span>">
<!ENTITY e1eZ "e<span class='sub'>1</span>...e<span class='sub'>Z</span>">
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Cryptographic Design of Encrypted Sessions</title>
<abstract>This document describes the requirements and cryptographic design that underpin the XMPP protocol extensions Encrypted Sessions and Offline Encrypted Sessions.</abstract>
@ -68,39 +68,39 @@
<version>0.1</version>
<date>2006-07-18</date>
<initials>ip</initials>
<remark><p>Initial version (extracted from JEP-0116 version 0.9).</p></remark>
<remark><p>Initial version (extracted from XEP-0116 version 0.9).</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p><em>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.</em></p>
<p><em>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.</em></p>
<p>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.</p>
<p>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 <cite>RFC 3920</cite>. 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.</p>
<p>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.)</p>
<p>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;).</p>
<p>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.)</p>
<p>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;).</p>
<p>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:</p>
<ul>
<li>Many-to-many sessions, such as a text conference in a chatroom as specified in &jep0045;.</li>
<li>One-to-many "broadcast", such as undirected presence stanzas sent from one user to many contacts (see <cite>RFC 3921</cite>) and data syndication implemented using &jep0060;.</li>
<li>Many-to-many sessions, such as a text conference in a chatroom as specified in &xep0045;.</li>
<li>One-to-many "broadcast", such as undirected presence stanzas sent from one user to many contacts (see <cite>RFC 3921</cite>) and data syndication implemented using &xep0060;.</li>
<li>One-to-one communications that are stored for later delivery rather than delivered immediately, such as so-called "offline messages".</li>
</ul>
</section1>
<section1 topic='Scope' anchor='scope'>
<p>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.</p>
<p>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.</p>
<p>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).</p>
</section1>
<section1 topic='The Session Approach' anchor='approach'>
<p>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 <cite>Current Jabber OpenPGP Usage</cite> uses "old-style" PGP object encryption and <cite>RFC 3923</cite> uses "new-style" S/MIME object encryption, both specify the use of object encryption. <!--(Another object encryption technology is &w3xmlsig;, which was rejected as a possible approach to end-to-end encryption for XMPP systems because of its inherent complexity and difficulty of implementation.)--></p>
<p>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 <cite>Current Jabber OpenPGP Usage</cite> uses "old-style" PGP object encryption and <cite>RFC 3923</cite> uses "new-style" S/MIME object encryption, both specify the use of object encryption. <!--(Another object encryption technology is &w3xmlsig;, which was rejected as a possible approach to end-to-end encryption for XMPP systems because of its inherent complexity and difficulty of implementation.)--></p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>Note: In order to gain a thorough understanding of this JEP, it is recommended that the <cite>Off-the-Record Communication</cite> paper is read first.</p>
<p>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.</p>
<p>Note: In order to gain a thorough understanding of this document, it is recommended that the <cite>Off-the-Record Communication</cite> paper is read first.</p>
</section1>
<section1 topic="Dramatis Personae" anchor='personae'>
<p>This JEP introduces two characters to help the reader follow the necessary exchanges:</p>
<p>This document introduces two characters to help the reader follow the necessary exchanges:</p>
<ol start='1'>
<li>"Alice" is the name of the initiator of the ESession.</li>
<li>"Bob" is the name of the other participant in the ESession started by Alice.</li>
@ -110,7 +110,7 @@
<section1 topic='Requirements' anchor='reqs'>
<section2 topic='Security Requirements' anchor='reqs-sec'>
<p>This JEP stipulates the following security requirements for end-to-end encryption of XMPP communications:</p>
<p>This document stipulates the following security requirements for end-to-end encryption of XMPP communications:</p>
<ul>
<li>Confidentiality</li>
<li>Integrity</li>
@ -135,20 +135,20 @@
<p>The encrypted communication MUST NOT be revealed even if long-lived keys are compromised in the future (e.g., Steve steals Bob's computer). <note>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.</note></p>
</section3>
<section3 topic='Authentication' anchor='reqs-auth'>
<p>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). <note>The reliable association between an entity and its public keys is beyond the scope of this JEP.</note></p>
<p>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). <note>The reliable association between an entity and its public keys is beyond the scope of this document.</note></p>
</section3>
<section3 topic='Identity Protection' anchor='reqs-id-protect'>
<p>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.</p>
</section3>
<section3 topic='Repudiability' anchor='reqs-repudiate'>
<p>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 <em>prove cryptographically</em> that any transcript has not been modified by a third party. <note>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.</note></p>
<p>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 <em>prove cryptographically</em> that any transcript has not been modified by a third party. <note>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.</note></p>
</section3>
<section3 topic='Upgradability' anchor='reqs-upgrade'>
<p>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. <note>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.</note></p>
</section3>
</section2>
<section2 topic='Application Requirements' anchor='reqs-xmpp'>
<p>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:</p>
<p>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:</p>
<ul>
<li>Generality</li>
<li>Implementability</li>
@ -190,7 +190,7 @@
<section1 topic='Cryptographic Origins - SIGMA' anchor='foundations'>
<section2 topic='Introduction' anchor='foundations-intro'>
<p>Authenticated key-exchange is the most challenging part of the design of any secure communication protocol. The ESessions key exchange essentially translates the &sigma;<note>Like <cite>RFC 2409</cite>, this protocol uses <em>variant (ii)</em>, as described in Secion 5.4 of the <cite>SIGMA</cite> paper.</note> 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;).</p>
<p>Note: Although this section provides an overview of SIGMA, it is recommended that the <cite>SIGMA</cite> paper is read first in order to gain a thorough understanding of this JEP.</p>
<p>Note: Although this section provides an overview of SIGMA, it is recommended that the <cite>SIGMA</cite> paper is read first in order to gain a thorough understanding of this document.</p>
<p>The 3-message SIGMA-I-based key exchange protects the identity of the <em>initiator</em> against active attacks. The 4-message SIGMA-R-based key exchange defends the <em>responder's</em> identity against active attacks. The differences between the two versions of the SIGMA protocol are highlighted in the diagrams below.</p>
</section2>
<section2 topic='SIGMA Parameter Descriptions' anchor='foundations-parameters'>
@ -734,15 +734,15 @@ VERIFY(&signB;, &pubKeyB;, &macB;)
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;. </p>
<p>This document requires no interaction with &IANA;. </p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<p>This JEP requires no interaction with the &REGISTRAR;.</p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
<section1 topic='Acknowledgments' anchor='acknowledgments'>
<p>The authors would like to thank Ian Goldberg for the time he spent reviewing this protocol and for his invaluable suggestions and comments.</p>
<p>The author would like to thank Ian Goldberg for the time he spent reviewing this protocol and for his invaluable suggestions and comments.</p>
</section1>
</jep>
</xep>

36
xep-0189.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Public Key Publishing</title>
<abstract>This document specifies how an entity may publish its public keys over XMPP.</abstract>
@ -15,16 +15,13 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0060</spec>
<spec>JEP-0163</spec>
<spec>XEP-0060</spec>
<spec>XEP-0163</spec>
<spec>W3C XML Signature</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>pubkeys</shortname>
<schemaloc>
<url>http://jabber.org/protocol/pubkeys/pubkeys.xsd</url>
</schemaloc>
&ianpaterson;
<revision>
<version>0.2</version>
@ -40,7 +37,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>This JEP defines different methods an entity may use for publishing its long-term public keys:</p>
<p>This document defines different methods an entity may use for publishing its long-term public keys:</p>
<ul>
<li>Publishing public keys to a set of subscribers.</li>
<li>Querying another entity for its public keys.</li>
@ -49,7 +46,7 @@
</section1>
<section1 topic='Public Key Publication and Retrieval via PEP' anchor='usecases-pubsub'>
<p>An entity SHOULD use &jep0163; to publish all its long-term public keys via its own server.</p>
<p>An entity SHOULD use &xep0163; to publish all its long-term public keys via its own server.</p>
<p>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 <link url='#security'>Security Considerations</link>) then the entity MUST also specify an appropriate access model other than "Open".</p>
<example caption='Entity Creates Public Keys Publishing Node'><![CDATA[
<iq from='juliet@capulet.com/balcony' type='set' id='create1'>
@ -157,7 +154,7 @@
</addresses>
</message>
]]></example>
<p>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 <em>resource</em> that published it.</p>
<p>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 <em>resource</em> that published it.</p>
<example caption='Subscriber Requests Keys from Account'><![CDATA[
<iq type='get'
to='juliet@capulet.com'
@ -244,15 +241,15 @@
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>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).</p>
<p>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).</p>
<p>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.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; shall add 'http://jabber.org/protocol/pubkeys' to its registry of protocol namespaces.</p>
</section1>
@ -266,13 +263,6 @@
xmlns='http://jabber.org/protocol/pubkeys'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0189: http://www.jabber.org/jeps/jep-0189.html
</xs:documentation>
</xs:annotation>
<xs:element name='pubkeys'>
<xs:complexType>
<xs:choice maxOccurs='unbounded'>
@ -284,4 +274,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

14
xep-0190.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Best Practice for Closing Idle Streams</title>
<abstract>This document specifies best practice for closing an idle XMPP stream.</abstract>
@ -29,7 +29,7 @@
<version>0.1</version>
<date>2006-07-26</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
@ -116,8 +116,8 @@
<section1 topic='IANA Considerations' anchor='iana'>
<p>This proposal requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This proposal requires no interaction with the &REGISTRAR;.</p>
</section1>
</jep>
</xep>

22
xep-0191.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Simple Communications Blocking</title>
<abstract>This document specifies an XMPP protocol extension for simple communications blocking.</abstract>
@ -16,7 +16,7 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
@ -32,7 +32,7 @@
<version>0.1</version>
<date>2006-08-16</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
@ -60,7 +60,7 @@
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='User Discovers Support' anchor='disco'>
<p>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:</p>
<p>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:</p>
<example caption='Service discovery request'><![CDATA[
<iq from='bilbo@tolkien.lit/shire' to='tolkien.lit' type='get' id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@ -90,7 +90,7 @@
<example caption='Block command is successful'><![CDATA[
<iq type='result' id='block1'/>
]]></example>
<p>(Standard XMPP stanza errors apply; see &xmppcore; and &jep0086;.)</p>
<p>(Standard XMPP stanza errors apply; see &xmppcore; and &xep0086;.)</p>
<p>Note: The &lt;block/&gt; element MAY contain more than one &lt;item/&gt; child.</p>
<p>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.</p>
<p>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:</p>
@ -165,7 +165,7 @@
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</p>
@ -173,7 +173,7 @@
<section1 topic='IANA Considerations' anchor='iana'>
<p>No interaction with &IANA; is required as a result of this specification.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/blocking' and 'http://jabber.org/protocol/blocking#errors' in its registry of protocol namespaces (see &NAMESPACES;).</p>
</section2>
@ -259,4 +259,4 @@
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Valerie Mercier, Maciek Niedzielski, and Remko Tron&#231;on for their feedback.</p>
</section1>
</jep>
</xep>

16
xep-0192.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Proposed Stream Feature Improvements</title>
<abstract>This document proposes improvements to the XML stream features definition for inclusion in the specification that supersedes RFC 3920.</abstract>
@ -24,7 +24,7 @@
<version>0.1</version>
<date>2006-08-16</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -257,9 +257,9 @@ S2: <stream:features>
<p>The improvements described herein do not introduce any new security concerns above and beyond those defined in <cite>RFC 3920</cite>.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>No interaction with &IANA; is required as a result of this JEP.</p>
<p>No interaction with &IANA; is required as a result of this document.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Stream Features' anchor='registrar-stream'>
<p>The &REGISTRAR; shall include 'http://jabber.org/features/dialback' in its registry of stream features.</p>
<p>The submission is as follows:</p>
@ -448,4 +448,4 @@ S2: <stream:features>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Ralph Meijer and Joe Hildebrand for their comments.</p>
</section1>
</jep>
</xep>

16
xep-0193.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Proposed Resource Binding Improvements</title>
<abstract>This document proposes improvements to the definition of resource binding for inclusion in the specification that supersedes RFC 3920.</abstract>
@ -24,7 +24,7 @@
<version>0.1</version>
<date>2006-08-16</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
@ -41,7 +41,7 @@
</header>
<section1 topic='Introduction' anchor='proto'>
&BISNOTE;
<p><cite>RFC 3920</cite> 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 <cite>RFC 3920</cite>, 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.</p>
<p><cite>RFC 3920</cite> 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 <cite>RFC 3920</cite>, 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.</p>
</section1>
<section1 topic='Unbinding a Resource' anchor='unbind'>
<p>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 &lt;unbind/&gt; qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, which in turn has a child element of &lt;resource/&gt; whose XML character data specifies the resource to be unbound:</p>
@ -202,7 +202,7 @@
<section1 topic='IANA Considerations' anchor='iana'>
<p>No interaction with &IANA; is required as a result of this document.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>No interaction with the &REGISTRAR; is required as a result of this document.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
@ -257,4 +257,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

22
xep-0194.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>User Chatting</title>
<abstract>This document defines an XMPP protocol extension for communicating information about the chatrooms a user visits.</abstract>
@ -16,8 +16,8 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0060</spec>
<spec>JEP-0163</spec>
<spec>XEP-0060</spec>
<spec>XEP-0163</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -27,7 +27,7 @@
<version>0.1</version>
<date>2006-08-30</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -37,7 +37,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&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.</p>
<p>&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.</p>
</section1>
<section1 topic='Protocol' anchor='protocol'>
<section2 topic='Container Element and Child Elements' anchor='protocol-elements'>
@ -75,7 +75,7 @@
<p>NOTE: The datatypes specified above are defined in &w3xmlschema2;.</p>
</section2>
<section2 topic='Transport Mechanism' anchor='protocol-transport'>
<p>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 <cite>JEP-0060</cite> protocol, especially the subset specified in <cite>JEP-0163</cite> (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.</p>
<p>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 <cite>XEP-0060</cite> protocol, especially the subset specified in <cite>XEP-0163</cite> (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.</p>
<example caption='User Publishes Chatting Information'><![CDATA[
<iq type='set' from='stpeter@jabber.org/work' id='chatting1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
@ -142,7 +142,7 @@
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/chatting' in its registry of protocol namespaces.</p>
</section2>
@ -170,4 +170,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

22
xep-0195.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>User Browsing</title>
<abstract>This document defines an XMPP protocol extension for communicating information about the web pages a user visits.</abstract>
@ -16,8 +16,8 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0060</spec>
<spec>JEP-0163</spec>
<spec>XEP-0060</spec>
<spec>XEP-0163</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -27,7 +27,7 @@
<version>0.1</version>
<date>2006-08-30</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -37,7 +37,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&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).</p>
<p>&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).</p>
</section1>
<section1 topic='Protocol' anchor='protocol'>
<section2 topic='Container Element and Child Elements' anchor='protocol-elements'>
@ -82,7 +82,7 @@
<p>NOTE: The datatypes specified above are defined in &w3xmlschema2;.</p>
</section2>
<section2 topic='Transport Mechanism' anchor='protocol-transport'>
<p>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 <cite>JEP-0060</cite> protocol, especially the subset specified in <cite>JEP-0163</cite> (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.</p>
<p>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 <cite>XEP-0060</cite> protocol, especially the subset specified in <cite>XEP-0163</cite> (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.</p>
<example caption='User Publishes Browsing Information'><![CDATA[
<iq type='set' from='stpeter@jabber.org/work' id='browsing1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
@ -147,7 +147,7 @@
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/browsing' in its registry of protocol namespaces.</p>
</section2>
@ -176,4 +176,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

22
xep-0196.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>User Gaming</title>
<abstract>This document defines an XMPP protocol extension for communicating information about the games a user plays.</abstract>
@ -16,8 +16,8 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0060</spec>
<spec>JEP-0163</spec>
<spec>XEP-0060</spec>
<spec>XEP-0163</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -27,7 +27,7 @@
<version>0.1</version>
<date>2006-08-30</date>
<initials>psa</initials>
<remark><p>Initial JEP version; added several more fields.</p></remark>
<remark><p>Initial version; added several more fields.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -37,7 +37,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&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.</p>
<p>&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.</p>
</section1>
<section1 topic='Protocol' anchor='protocol'>
<section2 topic='Container Element and Child Elements' anchor='protocol-elements'>
@ -103,7 +103,7 @@
<p>NOTE: The datatypes specified above are defined in &w3xmlschema2;.</p>
</section2>
<section2 topic='Transport Mechanism' anchor='protocol-transport'>
<p>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 <cite>JEP-0060</cite> protocol, especially the subset specified in <cite>JEP-0163</cite> (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.</p>
<p>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 <cite>XEP-0060</cite> protocol, especially the subset specified in <cite>XEP-0163</cite> (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.</p>
<example caption='User Publishes Gaming Information'><![CDATA[
<iq type='set' from='stpeter@jabber.org/work' id='gaming1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
@ -170,7 +170,7 @@
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/gaming' in its registry of protocol namespaces.</p>
</section2>
@ -202,4 +202,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

22
xep-0197.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>User Viewing</title>
<abstract>This document defines an XMPP protocol extension for communicating information about the television shows, movies, or other videos that a user watches.</abstract>
@ -16,8 +16,8 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0060</spec>
<spec>JEP-0163</spec>
<spec>XEP-0060</spec>
<spec>XEP-0163</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -33,7 +33,7 @@
<version>0.1</version>
<date>2006-08-30</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -43,7 +43,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&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).</p>
<p>&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).</p>
</section1>
<section1 topic='Protocol' anchor='protocol'>
<section2 topic='Container Element and Child Elements' anchor='protocol-elements'>
@ -144,7 +144,7 @@
<p>NOTE: The datatypes specified above are defined in &w3xmlschema2;.</p>
</section2>
<section2 topic='Transport Mechanism' anchor='protocol-transport'>
<p>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 <cite>JEP-0060</cite> protocol, especially the subset specified in <cite>JEP-0163</cite> (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.</p>
<p>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 <cite>XEP-0060</cite> protocol, especially the subset specified in <cite>XEP-0163</cite> (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.</p>
<example caption='User Publishes Viewing Information'><![CDATA[
<iq type='set' from='stpeter@jabber.org/work' id='viewing1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
@ -215,7 +215,7 @@
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/viewing' in its registry of protocol namespaces.</p>
</section2>
@ -254,4 +254,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>