moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

JEP to XEP

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@48 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-04 17:36:03 +00:00
parent de16d33554
commit 60c37405ae
10 changed files with 181 additions and 181 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
xep-0160.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 Practices for Handling Offline Messages</title>
<abstract>This document specifies best practices to be followed by Jabber/XMPP servers in handling messages sent to recipients who are offline.</abstract>
@ -17,7 +17,7 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -39,7 +39,7 @@
<version>0.1</version>
<date>2005-10-05</date>
<initials>psa</initials>
<remark>Initial JEP version.</remark>
<remark>Initial version.</remark>
</revision>
<revision>
<version>0.0.1</version>
@ -54,10 +54,10 @@
<section1 topic='Process Flow' anchor='flow'>
<p>The RECOMMENDED process flow is as follows:</p>
<ol>
<li>Sender generates XMPP message stanza <note>This JEP does not discuss IQ or presence stanzas, handling of which is described in <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</note> for delivery to a recipient such as an IM user or other node, where the 'to' address is of the form &lt;node@domain&gt; or &lt;node@domain/resource&gt; (see <cite>RFC 3921</cite> for rules regarding server handling of such XMPP message stanzas).</li>
<li>Sender generates XMPP message stanza <note>This document does not discuss IQ or presence stanzas, handling of which is described in <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</note> for delivery to a recipient such as an IM user or other node, where the 'to' address is of the form &lt;node@domain&gt; or &lt;node@domain/resource&gt; (see <cite>RFC 3921</cite> for rules regarding server handling of such XMPP message stanzas).</li>
<li>Recipient's server determines that the intended recipient has no available resources that have specified non-negative presence priority. <note>As specified in <cite>RFC 3920</cite>, available resources that have specified a negative presence priority shall never receive message stanzas addressed to &lt;node@domain&gt;.</note></li>
<li>Recipient's server does not return a &unavailable; error but instead stores the message stanza for later delivery.</li>
<li>When the recipient next sends non-negative available presence to the server, the server delivers the message to the resource that has sent that presence. (Alternatively, the server may support &jep0013;, although that functionality is not described herein.)</li>
<li>When the recipient next sends non-negative available presence to the server, the server delivers the message to the resource that has sent that presence. (Alternatively, the server may support &xep0013;, although that functionality is not described herein.)</li>
</ol>
<p>This flow is described more fully below.</p>
<p>First, the sender (in this example, romeo@montague.net) sends a message to an intended recipient (juliet@capulet.com).</p>
@ -77,7 +77,7 @@
<priority>1</priority>
</presence>
]]></example>
<p>The recipient's server now delivers the offline message to that resource (it is RECOMMENDED for the server to add a &jep0091; extension to indicate that the message was stored offline).</p>
<p>The recipient's server now delivers the offline message to that resource (it is RECOMMENDED for the server to add a &xep0091; extension to indicate that the message was stored offline).</p>
<example caption='Recipient&apos;s Server Delivers Message'><![CDATA[
<message from='romeo@montague.net/orchard' to='juliet@capulet.com'>
<body>
@ -95,14 +95,14 @@
<p>Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in <cite>RFC 3921</cite>):</p>
<ul>
<li><p><strong>normal</strong> -- Messages with a 'type' attribute whose value is "normal" (or messages with no 'type' attribute) SHOULD be stored offline.</p></li>
<li><p><strong>chat</strong> -- Messages with a 'type' attribute whose value is "chat" SHOULD be stored offline, with the exception of messages that contain only &jep0085; content (such messages SHOULD NOT be stored offline).</p></li>
<li><p><strong>groupchat</strong> -- Messages with a 'type' attribute whose value is "groupchat" SHOULD NOT be stored offline, since by definition a user without online presence cannot be in a &jep0045; room.</p></li>
<li><p><strong>chat</strong> -- Messages with a 'type' attribute whose value is "chat" SHOULD be stored offline, with the exception of messages that contain only &xep0085; content (such messages SHOULD NOT be stored offline).</p></li>
<li><p><strong>groupchat</strong> -- Messages with a 'type' attribute whose value is "groupchat" SHOULD NOT be stored offline, since by definition a user without online presence cannot be in a &xep0045; room.</p></li>
<li><p><strong>headline</strong> -- Messages with a 'type' attribute whose value is "headline" SHOULD NOT be stored offline, since such messages are usually time-sensitive.</p></li>
<li><p><strong>error</strong> -- Messages with a 'type' attribute whose value is "error" SHOULD NOT be stored offline, although a server MAY store &jep0079; error messages offline.</p></li>
<li><p><strong>error</strong> -- Messages with a 'type' attribute whose value is "error" SHOULD NOT be stored offline, although a server MAY store &xep0079; error messages offline.</p></li>
</ul>
</section1>
<section1 topic='Service Discovery' anchor='disco'>
<p>If a server supports offline message handling as described herein, it SHOULD return a "msgoffline" feature in response to &jep0030; information requests:</p>
<p>If a server supports offline message handling as described herein, it SHOULD return a "msgoffline" feature in response to &xep0030; information requests:</p>
<example caption='Recipient Queries Server About Support'><![CDATA[
<iq from='juliet@capulet.com/chamber' to='capulet.com'>
<query xmlns='http://jabber.org/disco#info'/>
@ -118,13 +118,13 @@
]]></example>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>A message stored offline may not be readable by the recipient if the message was encrypted using a session-based encryption method such as &jep0116; or if the key used in object encryption is revoked after the message was sent but before it is read.</p>
<p>A message stored offline may not be readable by the recipient if the message was encrypted using a session-based encryption method such as &xep0116; or if the key used in object encryption is revoked after the message was sent but before it is read.</p>
<p>In certain countries, offline storage of message stanzas may introduce legal requirements or privacy vulnerabilities that do not apply to messages that are delivered immediately and never stored on an intermediate server.</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; includes "msgoffline" in its registry of service discovery features (see &DISCOFEATURES;).</p>
</section1>
</jep>
</xep>

22
xep-0161.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>SPIM Reporting</title>
<abstract>This document specifies an XMPP protocol extension for reporting unsolicited bulk instant messages (SPIM).</abstract>
@ -17,7 +17,7 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -33,7 +33,7 @@
<version>0.1</version>
<date>2005-10-19</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -138,7 +138,7 @@
<section2 topic='Initial Processing' anchor='processing-initial'>
<p>The following rules and guidelines apply to initial processing of a SPIM report.</p>
<ol>
<li>Before processing the report, the processor MAY respond to the report by sending a challenge to the sender (e.g., using &jep0158;) in order to make sure that the sender is not sending spurious reports or otherwise abusing the SPIM reporting system.</li>
<li>Before processing the report, the processor MAY respond to the report by sending a challenge to the sender (e.g., using &xep0158;) in order to make sure that the sender is not sending spurious reports or otherwise abusing the SPIM reporting system.</li>
<li>The processor MUST add the report to a list or database of pending SPIM reports.</li>
<li>If the suspected spimmer is not already on the processor's list of known spimmers, the processor SHOULD use the report in determining whether the suspected spimmer is an actual spimmer (see next section).</li>
<li>The processor MAY report the SPIM stanza to one or more dedicated SPIM reporting services if available.</li>
@ -164,7 +164,7 @@
</section2>
</section1>
<section1 topic='Discovering Support' anchor='disco'>
<p>In order to discover whether another entity supports SPIM reporting, &jep0030; SHOULD be used. If an entity supports SPIM reporting, it MUST return a feature of "http://jabber.org/protocol/spimreport" in responses to service discovery information requests, as shown in the following examples:</p>
<p>In order to discover whether another entity supports SPIM reporting, &xep0030; SHOULD be used. If an entity supports SPIM reporting, it MUST return a feature of "http://jabber.org/protocol/spimreport" in responses to service discovery information requests, as shown in the following examples:</p>
<example caption='User Queries Server Regarding Protocol Support'><![CDATA[
<iq from='unsuspectinguser@example.net'
to='example.net'
@ -193,7 +193,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'>
<p>The &REGISTRAR; shall add 'http://jabber.org/protocol/spimreport' to its registry of protocol namespaces.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
@ -208,7 +208,7 @@
<xs:import
namespace='jabber:client'
schemaLocation='http://xmpp.org/schemas/client.xsd'/>
schemaLocation='http://www.xmpp.org/schemas/jabber-client.xsd'/>
<xs:element name='spim'>
<xs:complexType>
@ -224,4 +224,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

18
xep-0162.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 Practices for Roster and Subscription Management</title>
<abstract>This document specifies best practices for roster and subscription management in Jabber/XMPP clients.</abstract>
@ -33,7 +33,7 @@
<version>0.1</version>
<date>2005-10-19</date>
<initials>lnu</initials>
<remark>Initial JEP version.</remark>
<remark>Initial version.</remark>
</revision>
<revision>
<version>0.0.3</version>
@ -60,7 +60,7 @@
<p>&rfc3921; explains how subscriptions and rosters integrate. However,
several points are left to the client author's discretion, and this can lead
to some confusion among client developers. This JEP specifies best practices
to some confusion among client developers. This document specifies best practices
that enable all Jabber clients to manage subscriptions and roster in a coherent
way, thus making sure that such clients will not surprise end users with
unexpected behavior.</p>
@ -183,10 +183,10 @@
<p>The name of the 'Hidden' group can be managed in two different ways :</p>
<ul>
<li>It could always be named 'Hidden' but be displayed translated by the client ;</li>
<li>It could be named as the user wants. Its name could then be stored using jabber:iq:private, like the delimiter for nested groups in &jep0083;.</li>
<li>It could be named as the user wants. Its name could then be stored using jabber:iq:private, like the delimiter for nested groups in &xep0083;.</li>
</ul>
<p>This is left as an open issue since no clients (to the author's knowledge) implement this 'Hidden' group. But the preference should go to the first solution, which avoids relying on &jep0049;.</p>
<p>This is left as an open issue since no clients (to the author's knowledge) implement this 'Hidden' group. But the preference should go to the first solution, which avoids relying on &xep0049;.</p>
</section2>
</section1>
</jep>
</xep>

76
xep-0163.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>Personal Eventing via Pubsub</title>
<abstract>This document specifies XMPP semantics for using the publish-subscribe protocol to broadcast state change events associated with an instant messaging and presence account.</abstract>
@ -17,9 +17,9 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>JEP-0060</spec>
<spec>JEP-0115</spec>
<spec>XEP-0030</spec>
<spec>XEP-0060</spec>
<spec>XEP-0115</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -71,13 +71,13 @@
<version>0.10</version>
<date>2006-07-07</date>
<initials>psa</initials>
<remark><p>Updated to reflect version 1.8 of JEP-0060.</p></remark>
<remark><p>Updated to reflect version 1.8 of XEP-0060.</p></remark>
</revision>
<revision>
<version>0.9</version>
<date>2006-06-15</date>
<initials>psa</initials>
<remark><p>Updated to reflect use of data forms in JEP-0060.</p></remark>
<remark><p>Updated to reflect use of data forms in XEP-0060.</p></remark>
</revision>
<revision>
<version>0.8</version>
@ -119,13 +119,13 @@
<version>0.2</version>
<date>2006-01-11</date>
<initials>psa</initials>
<remark><p>Updated to reflect proposed JEP-0060 modifications.</p></remark>
<remark><p>Updated to reflect proposed XEP-0060 modifications.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2005-11-02</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
@ -142,8 +142,8 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The XMPP &jep0060; extension ("pubsub") can be used to broadcast state change events associated with a Jabber/XMPP account or user, such as those described in &jep0080;, &jep0107;, &jep0108;, and &jep0118;. <note>Currently, many "extended presence" formats are sent using the &PRESENCE; stanza type; however, this overloads presence, results in unnecessary presence traffic, and does not provide fine-grained control over access. The use of publish-subscribe rather than presence is therefore preferable.</note> However, the full, generic pubsub protocol is often thought of as complicated and therefore has not been widely implemented. To make publish-subscribe functionality more accessible (especially to instant messaging and presence applications that conform to &xmppim;), this document defines simplified protocol semantics that can be followed by instant messaging client and server developers, hopefully resulting in the deployment of personal eventing services across the Jabber/XMPP network.</p>
<p><em>Note: This document does not show error flows related to the various publish-subscribe use cases referenced herein, since they are exhaustively defined in <cite>JEP-0060</cite>. The reader is referred to <cite>JEP-0060</cite> for all relevant protocol details related to the XMPP publish-subscribe extension.</em></p>
<p>The XMPP &xep0060; extension ("pubsub") can be used to broadcast state change events associated with a Jabber/XMPP account or user, such as those described in &xep0080;, &xep0107;, &xep0108;, and &xep0118;. <note>Currently, many "extended presence" formats are sent using the &PRESENCE; stanza type; however, this overloads presence, results in unnecessary presence traffic, and does not provide fine-grained control over access. The use of publish-subscribe rather than presence is therefore preferable.</note> However, the full, generic pubsub protocol is often thought of as complicated and therefore has not been widely implemented. To make publish-subscribe functionality more accessible (especially to instant messaging and presence applications that conform to &xmppim;), this document defines simplified protocol semantics that can be followed by instant messaging client and server developers, hopefully resulting in the deployment of personal eventing services across the Jabber/XMPP network.</p>
<p><em>Note: This document does not show error flows related to the various publish-subscribe use cases referenced herein, since they are exhaustively defined in <cite>XEP-0060</cite>. The reader is referred to <cite>XEP-0060</cite> for all relevant protocol details related to the XMPP publish-subscribe extension.</em></p>
</section1>
<section1 topic='Concepts and Approach' anchor='approach'>
@ -174,10 +174,10 @@
<li>A contact's subscription to an account owner's personal eventing data is normally handled via the existence of an XMPP presence subscription.</li>
<li>Services take account of subscriber presence in the generation of notifications. <note>This works only if the subscription state is "both" (see <cite>RFC 3921</cite>).</note></li>
</ul>
<p>These uses of presence simplify the task of developing compliant clients (cf. &jep0134;).</p>
<p>These uses of presence simplify the task of developing compliant clients (cf. &xep0134;).</p>
</section2>
<section2 topic='Filtered Notifications' anchor='approach-filter'>
<p>By default, the existence of an XMPP presence subscription is used to establish a PEP subscription to the account owner's personal eventing data. In order to filter which notifications are sent by the PEP service, the contact's client includes extended &jep0115; information in the presence notifications it sends to the account owner, and the PEP service sends only those notifications that match the contact's expressed notification preferences.</p>
<p>By default, the existence of an XMPP presence subscription is used to establish a PEP subscription to the account owner's personal eventing data. In order to filter which notifications are sent by the PEP service, the contact's client includes extended &xep0115; information in the presence notifications it sends to the account owner, and the PEP service sends only those notifications that match the contact's expressed notification preferences.</p>
</section2>
<section2 topic='Smart Defaults' anchor='approach-defaults'>
<p>Most pubsub configuration options and metadata are not needed for personal eventing. Instead, PEP services offer smart defaults to simplify node creation and management.</p>
@ -210,7 +210,7 @@
</section1>
<section1 topic='Account Owner Service Discovery' anchor='owner-disco'>
<p>Naturally, before an account owner attempts to complete any PEP use cases, its client SHOULD determine whether the account owner's server supports PEP; to do so, it MUST send a &jep0030; information request to the server:</p>
<p>Naturally, before an account owner attempts to complete any PEP use cases, its client SHOULD determine whether the account owner's server supports PEP; to do so, it MUST send a &xep0030; information request to the server:</p>
<example caption='Account owner queries server regarding protocol support'><![CDATA[
<iq from='juliet@capulet.com/balcony'
to='capulet.com'
@ -219,7 +219,7 @@
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<p>If a server supports PEP, it MUST return an identity of "pubsub/pep" (as well as a list of the namespaces and other features it supports, including all supported <cite>JEP-0060</cite> features):</p>
<p>If a server supports PEP, it MUST return an identity of "pubsub/pep" (as well as a list of the namespaces and other features it supports, including all supported <cite>XEP-0060</cite> features):</p>
<example caption='Server communicates protocol support'><![CDATA[
<iq from='capulet.com'
to='juliet@capulet.com/balcony'
@ -242,7 +242,7 @@
</section1>
<section1 topic='Account Owner Node Creation' anchor='owner-create'>
<p>When an account owner attempts to publish an item to a PEP node and that node does not already exist, the PEP service MUST automatically create the node with default configuration. <note>This similar to the room creation process in <cite>JEP-0045: Multi-User Chat</cite>.</note> However, if the account owner wishes to create a node with a configuration other than the default (e.g., a node with an access model of "open", "roster", or "whitelist"), the account owner MUST follow the node creation protocol specified in <cite>JEP-0060</cite>.</p>
<p>When an account owner attempts to publish an item to a PEP node and that node does not already exist, the PEP service MUST automatically create the node with default configuration. <note>This similar to the room creation process in <cite>XEP-0045: Multi-User Chat</cite>.</note> However, if the account owner wishes to create a node with a configuration other than the default (e.g., a node with an access model of "open", "roster", or "whitelist"), the account owner MUST follow the node creation protocol specified in <cite>XEP-0060</cite>.</p>
<p>For example, Juliet would send the following stanzas in order to create the nodes mentioned above:</p>
<example caption='Account owner creates open node for tune data'><![CDATA[
<iq from='juliet@capulet.com/balcony' type='set' id='create-open'>
@ -415,7 +415,7 @@
</section1>
<section1 topic='Contact Subscription' anchor='contact-subscribe'>
<p>If an entity is not subscribed to the account owner's presence, it MUST subscribe to a node using the protocol defined in <cite>JEP-0060</cite>. For instance, here is how benvolio@montague.net would subscribe Juliet's tune information:</p>
<p>If an entity is not subscribed to the account owner's presence, it MUST subscribe to a node using the protocol defined in <cite>XEP-0060</cite>. For instance, here is how benvolio@montague.net would subscribe Juliet's tune information:</p>
<example caption='Unaffiliated entity subscribes to an open node'><![CDATA[
<iq type='set'
from='benvolio@montague.net/home'
@ -463,7 +463,7 @@
</section1>
<section1 topic='Account Owner Publishing' anchor='owner-publish'>
<p>An account owner publishes an item to a node by following the protocol specified in <cite>JEP-0060</cite>:</p>
<p>An account owner publishes an item to a node by following the protocol specified in <cite>XEP-0060</cite>:</p>
<example caption='Account owner publishes item'><![CDATA[
<iq from='juliet@capulet.com/balcony' type='set' id='pub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
@ -482,7 +482,7 @@
</iq>
]]></example>
<p>As a result, the account owner's server generates notifications and sends them to all subscribers who have requested or are interested in the data as described in the <link url='#notifications'>Contact Notification Filtering</link> and <link url='#notifications'>Generating Notifications</link> sections of this document.</p>
<p>The server MUST set the 'from' address on the notification to the bare JID (&BAREJID;) of the account owner (in this example, "juliet@capulet.com"). When sending notifications to an entity that has a presence subscription to the account owner, the server SHOULD include an &jep0033; "replyto" extension specifying the publishing resource (in this example, "juliet@capulet.com/balcony"); this enables the subscriber's client to differentiate between information received from each of the account owner's resources (for example, different resources may be in different places and therefore may need to specify distinct geolocation data). However, a server MUST NOT include the "replyto" address when sending a notification to an entity that does not have a presence subscription to the account owner. In addition, any errors related to the notification MUST be directed to the JID of the 'from' address on the notification (i.e., the bare JID) so that bounce processing can be handled by the PEP service rather than by the publishing client.</p>
<p>The server MUST set the 'from' address on the notification to the bare JID (&BAREJID;) of the account owner (in this example, "juliet@capulet.com"). When sending notifications to an entity that has a presence subscription to the account owner, the server SHOULD include an &xep0033; "replyto" extension specifying the publishing resource (in this example, "juliet@capulet.com/balcony"); this enables the subscriber's client to differentiate between information received from each of the account owner's resources (for example, different resources may be in different places and therefore may need to specify distinct geolocation data). However, a server MUST NOT include the "replyto" address when sending a notification to an entity that does not have a presence subscription to the account owner. In addition, any errors related to the notification MUST be directed to the JID of the 'from' address on the notification (i.e., the bare JID) so that bounce processing can be handled by the PEP service rather than by the publishing client.</p>
<p>Assuming that all three entities previously mentioned would receive the notifications, the PEP service would generate the following stanzas:</p>
<example caption='Server sends notification to subscribers'><![CDATA[
<message from='juliet@capulet.com'
@ -552,13 +552,13 @@
</section1>
<section1 topic='Contact Notification Filtering' anchor='contact-filter'>
<p>A contact may not want to receive notifications for all payload types. A contact SHOULD signal its preferences to the account owner's server by including <cite>JEP-0115</cite> information that specifies the namespaces for which the contact wishes to receive notifications (if any).</p>
<p>A contact may not want to receive notifications for all payload types. A contact SHOULD signal its preferences to the account owner's server by including <cite>XEP-0115</cite> information that specifies the namespaces for which the contact wishes to receive notifications (if any).</p>
<p>In order to make this possible, all possible payload namespaces can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the payload format. Thus if Romeo wants to receive notifications for activity data and geolocation data but not tune data, his client would advertise support for the following namespaces in the disco#info results it sends: <note>Including, say, the 'http://jabber.org/protocol/geoloc' namespace indicates that the client understands the geolocation namespace, whereas including the 'http://jabber.org/protocol/geoloc+notify' namespace indicates that the client wishes to receive notifications related to geolocation.</note></p>
<ul>
<li>http://jabber.org/protocol/activity+notify</li>
<li>http://jabber.org/protocol/geoloc+notify</li>
</ul>
<p>This set of namespaces would then be advertised as a <cite>JEP-0115</cite> "ext" value, such as the following:</p>
<p>This set of namespaces would then be advertised as a <cite>XEP-0115</cite> "ext" value, such as the following:</p>
<example caption='Contact sends presence with caps'><![CDATA[
<presence from='romeo@montague.net/orchard'>
<c xmlns='http://jabber.org/protocol/caps'
@ -567,8 +567,8 @@
ext='foobar pres+'/>
</presence>
]]></example>
<p>Note: In <cite>JEP-0115</cite>, the "ext" values are opaque strings with no semantic meaning.</p>
<p>It is the responsibility of the account owner's server to cache <cite>JEP-0115</cite> information (including "ext" values and their associated namespaces). When the server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the desired namespaces for the contact's client. The server MUST NOT send notifications related to any data formats that the contact's client has not asked for via the relevant "namespace+notify" disco#info feature. This enables a client to turn off all notifications (e.g., because of bandwidth restrictions) and to easily receive all desired data formats simply by adding support for the appropriate "namespace+notify" combination in its disco#info results and client capabililies. However, it also implies that a client can request notifications only on a global basis and cannot request, say, mood information only from certain contacts in the user's roster. Community consensus is that this is an acceptable tradeoff. Also, note that this works only if the account owner has a presence subscription to the contact and the contact has a presence subscription to the account owner.</p>
<p>Note: In <cite>XEP-0115</cite>, the "ext" values are opaque strings with no semantic meaning.</p>
<p>It is the responsibility of the account owner's server to cache <cite>XEP-0115</cite> information (including "ext" values and their associated namespaces). When the server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the desired namespaces for the contact's client. The server MUST NOT send notifications related to any data formats that the contact's client has not asked for via the relevant "namespace+notify" disco#info feature. This enables a client to turn off all notifications (e.g., because of bandwidth restrictions) and to easily receive all desired data formats simply by adding support for the appropriate "namespace+notify" combination in its disco#info results and client capabililies. However, it also implies that a client can request notifications only on a global basis and cannot request, say, mood information only from certain contacts in the user's roster. Community consensus is that this is an acceptable tradeoff. Also, note that this works only if the account owner has a presence subscription to the contact and the contact has a presence subscription to the account owner.</p>
<p>Some examples may help to illustrate the concept of notification filtering. Here we show presence generated by two of the contacts listed above (benvolio@montague.net does have any presence subscriptions to or from juliet@capulet.com and therefore is not involved in these protocol flows).</p>
<example caption='Presence with caps'><![CDATA[
<presence from='nurse@capulet.com/chamber'>
@ -644,14 +644,14 @@
<section2 topic='Number of Notifications' anchor='notifications-num'>
<ol start='1'>
<li><p>If a subscriber subscribed using a full JID (&FULLJID;), domain identifier (&DOMAIN;), or domain plus resource (&DOMAINRES;), a PEP service MUST send one notification only, addressed to the subscribed JID.</p></li>
<li><p>If a subscriber subscribed using a bare JID (&BAREJID;) and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID (&BAREJID;) of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with non-negative priority and <cite>JEP-0115</cite> data that indicates interest in the relevant data format.)</p></li>
<li><p>If a subscriber subscribed using a bare JID (&BAREJID;) and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID (&FULLJID;) of each of the subscriber's available resources that have specified non-negative presence priority and included <cite>JEP-0115</cite> information that indicates an interest in the data format.</p></li>
<li><p>If a subscriber subscribed using a bare JID (&BAREJID;) and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID (&BAREJID;) of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with non-negative priority and <cite>XEP-0115</cite> data that indicates interest in the relevant data format.)</p></li>
<li><p>If a subscriber subscribed using a bare JID (&BAREJID;) and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID (&FULLJID;) of each of the subscriber's available resources that have specified non-negative presence priority and included <cite>XEP-0115</cite> information that indicates an interest in the data format.</p></li>
</ol>
</section2>
<section2 topic='When to Generate Notifications' anchor='notifications-when'>
<ol start='1'>
<li><p>When an account owner publishes an item to a node, a PEP service MUST generate a notification and send it to all appropriate subscribers (where the number of notifications is determined by the foregoing rules).</p></li>
<li><p>When a PEP service receives initial presence information from a subscriber's resource with a non-negative priority and including <cite>JEP-0115</cite> information that indicates an interest in the data format, it MUST generate a notification containing the last published item for that node and send it to the newly-available resource.</p></li>
<li><p>When a PEP service receives initial presence information from a subscriber's resource with a non-negative priority and including <cite>XEP-0115</cite> information that indicates an interest in the data format, it MUST generate a notification containing the last published item for that node and send it to the newly-available resource.</p></li>
<li><p>As an exception to the foregoing MUST rules, a PEP service MUST NOT send notifications to a subscriber if the user has blocked the subscriber from receiving all or any kinds of stanza (presence, message, IQ, or any combination thereof) using communiations blocking as specified in <cite>XMPP IM</cite>.</p></li>
</ol>
</section2>
@ -699,13 +699,13 @@
</section1>
<section1 topic='Private Data Storage' anchor='privatedata'>
<p>As noted, PEP services may be used to implement private data storage, such as defined in &jep0049;. A future version of this document will specify this usage in more detail.</p>
<p>As noted, PEP services may be used to implement private data storage, such as defined in &xep0049;. A future version of this document will specify this usage in more detail.</p>
</section1>
<section1 topic='Recommended Defaults' anchor='defaults'>
<p>A PEP service MUST:</p>
<ul>
<li>Support the node discovery, node creation, node deletion, publish item, subscribe, unsubscribe, and item retrieval use cases specified in <cite>JEP-0060</cite>.</li>
<li>Support the node discovery, node creation, node deletion, publish item, subscribe, unsubscribe, and item retrieval use cases specified in <cite>XEP-0060</cite>.</li>
<li>Support the "owner" and "subscriber" affiliations.</li>
<li>Support the "presence" access model and set it to the default.</li>
<li>Support the "open", "roster", and "whitelist" access models.</li>
@ -724,7 +724,7 @@
<li>A presence subscription state changes (e.g., when a subscription request is approved).</li>
<li>A roster item is modified (e.g., when the item is moved to a new roster group).</li>
</ol>
<p>If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY send a message to the (former) subscriber informing it of the cancellation (for information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of <cite>JEP-0060</cite>).</p>
<p>If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY send a message to the (former) subscriber informing it of the cancellation (for information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of <cite>XEP-0060</cite>).</p>
</section2>
</section1>
@ -733,12 +733,12 @@
</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='Service Discovery Category/Type' anchor='registrar-disco'>
<p>The &REGISTRAR; includes a category of "pubsub" in its registry of Service Discovery identities (see &DISCOCATEGORIES;); as a result of this JEP, the Registrar includes a type of "pep" to that category.</p>
<p>The &REGISTRAR; includes a category of "pubsub" in its registry of Service Discovery identities (see &DISCOCATEGORIES;); as a result of this document, the Registrar includes a type of "pep" to that category.</p>
<p>The registry submission is as follows:</p>
<code><![CDATA[
<category>
@ -747,9 +747,9 @@
<name>pep</name>
<desc>
A personal eventing service that supports the
publish-subscribe subset defined in JEP-0163.
publish-subscribe subset defined in XEP-0163.
</desc>
<doc>JEP-0163</doc>
<doc>XEP-0163</doc>
</type>
</category>
]]></code>
@ -757,11 +757,11 @@
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>Because Personal Eventing via Pubsub simply reuses the protocol specified in <cite>JEP-0060</cite>, a separate schema is not needed.</p>
<p>Because Personal Eventing via Pubsub simply reuses the protocol specified in <cite>XEP-0060</cite>, a separate schema is not needed.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>The authors wish to thank the participants in the XMPP Interoperability Testing Event held July 24 and 25, 2006, who provided valuable feedback that resulted in radical simplification of the protocol.</p>
</section1>
</jep>
</xep>

26
xep-0164.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>vCard Filtering</title>
<abstract>This document specifies a mechanism for requesting specific sections of a vCard.</abstract>
@ -16,7 +16,7 @@
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0054</spec>
<spec>XEP-0054</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -31,7 +31,7 @@
<version>0.1</version>
<date>2005-11-16</date>
<initials>psa</initials>
<remark>Initial JEP version.</remark>
<remark>Initial version.</remark>
</revision>
<revision>
<version>0.0.2</version>
@ -47,14 +47,14 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Because XML vCards (see &jep0054;) are now actively used for storing avatars (see &jep0153;), the ability to retrieve only portions of a vCard has become desirable. This JEP can eliminate unnecessary bandwidth usage when larger elements of a vCard are not needed.</p>
<p>Because XML vCards (see &xep0054;) are now actively used for storing avatars (see &xep0153;), the ability to retrieve only portions of a vCard has become desirable. This protocol can eliminate unnecessary bandwidth usage when larger elements of a vCard are not needed.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>Any entity supporting this extension MUST be prepared to accept more fields than were requested, in case the target does not support this extension. A compliant target SHOULD exclude any fields listed in the filter element. In the event that the filter element does not exist or is empty, the target MUST return the entire vCard as it would without this extension.</p>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic="Retrieving Another User's vCard Without The JABBERID Element">
<p>To illustrate the functionality of this JEP, we will first request a standard vCard. As shown in <cite>JEP-0054</cite>, a user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID. A compliant server MUST return the vCard to the requestor and not forward the IQ to the requestee's connected resource.</p>
<p>To illustrate the functionality of this protocol, we will first request a standard vCard. As shown in <cite>XEP-0054</cite>, a user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID. A compliant server MUST return the vCard to the requestor and not forward the IQ to the requestee's connected resource.</p>
<example caption="Requesting Another User's vCard"><![CDATA[
<iq to='jer@jabber.org'
from='stpeter@jabber.org/home'
@ -116,16 +116,16 @@
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This JEP introduces no new security concerns beyond those already involved in implementation and deployment of the 'vcard-temp' protocol.</p>
<p>This document introduces no new security concerns beyond those already involved in implementation and deployment of the 'vcard-temp' protocol.</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 'vcard-temp-filter' to its registry of official namespaces.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>The schema for the 'vcard-temp-filter' namespace re-uses the element names from the DTD described in <cite>JEP-0054</cite>.</p>
<p>The schema for the 'vcard-temp-filter' namespace re-uses the element names from the DTD described in <cite>XEP-0054</cite>.</p>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
@ -181,4 +181,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

28
xep-0165.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>Prevention of JID Spoofing</title>
<abstract>This document recommends best practices to prevent the spoofing of Jabber IDs.</abstract>
@ -17,7 +17,7 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0172</spec>
<spec>XEP-0172</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -33,13 +33,13 @@
<version>0.2</version>
<date>2006-03-28</date>
<initials>psa</initials>
<remark><p>Updated to use JEP-0172 syntax for nicknames.</p></remark>
<remark><p>Updated to use XEP-0172 syntax for nicknames.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2005-11-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>
@ -77,8 +77,8 @@
<p>As explained in &petnames;, no one naming or address scheme can provide names that are simultaneously global, memorable, and unique. However, certain <em>combinations</em> of names and addresses can provide all three properties, and such combinations are commonly called "petname systems". Consider the following combination of names:</p>
<ol>
<li><p>The JID "stpeter@jabber.org" is globally unique on the Jabber network, but it is not necessarily memorable.</p></li>
<li><p>The nickname "psa" (asserted by the user associated with the address "stpeter@jabber.org") is globally memorable but not necessarily unique; see &jep0172; for more information about user-asserted nicknames.</p></li>
<li><p>The handle or petname <note>For consistency with other XMPP specifications, wee use the term "alias" rather than "petname".</note> "that JSF dude" (assigned by a contact who adds "stpeter@jabber.org" to her contact list) is privately memorable and unique <note>If not shared or leaked, it may even be securely unique.</note> but is by no means global since it has meaning only to the person who assigns it; for consistency with <cite>JEP-0172</cite> we refer to this as a "handle".</p></li>
<li><p>The nickname "psa" (asserted by the user associated with the address "stpeter@jabber.org") is globally memorable but not necessarily unique; see &xep0172; for more information about user-asserted nicknames.</p></li>
<li><p>The handle or petname <note>For consistency with other XMPP specifications, wee use the term "alias" rather than "petname".</note> "that JSF dude" (assigned by a contact who adds "stpeter@jabber.org" to her contact list) is privately memorable and unique <note>If not shared or leaked, it may even be securely unique.</note> but is by no means global since it has meaning only to the person who assigns it; for consistency with <cite>XEP-0172</cite> we refer to this as a "handle".</p></li>
</ol>
<p>A client SHOULD require an end user to assign a handle for every contact added to the person's roster, which SHOULD be stored as the value of the &lt;item/&gt; element's 'name' attribute qualified by the 'jabber:iq:roster' namespace (for details regarding roster syntax, refer to &rfc3921;). A client SHOULD then present that handle instead of or in addition to the contact's JID or nickname (e.g., in the user's roster and in chat interfaces). This will help to prevent mimicked addresses from being presented as equivalent to the address that is being mimicked.</p>
</section2>
@ -87,7 +87,7 @@
<p>Unfortunately, cryptographic identities such as keys, certificates, and fingerprints are even less memorable than JIDs, which makes assigning a handle even more important. Therefore, if a contact provides such a cryptographic identity, a client MUST reliably associate it with the contact in a user's roster (including, as mentioned, an alias for each contact) in order to further strengthen the petname system.</p>
</section2>
<section2 topic='Referrals' anchor='rec-referrals'>
<p>In order to strengthen the web of interaction and trust between Jabber/XMPP users, it is helpful for them to share roster items. In particular, when a user wants to subscribe to the presence of a potential contact, the user SHOULD seek a referral from a third person who knows both the user and the contact. Such a referral consists of a roster item sent from the third person to the potential contact, encapsulated using the &jep0144; protocol:</p>
<p>In order to strengthen the web of interaction and trust between Jabber/XMPP users, it is helpful for them to share roster items. In particular, when a user wants to subscribe to the presence of a potential contact, the user SHOULD seek a referral from a third person who knows both the user and the contact. Such a referral consists of a roster item sent from the third person to the potential contact, encapsulated using the &xep0144; protocol:</p>
<example caption='A Basic Referral'><![CDATA[
<message from='peter@saint-andre.com' to='MaineBoy@jabber.org'>
<x xmlns='http://jabber.org/protocol/rosterx'>
@ -96,7 +96,7 @@
</message>
]]></example>
<p>Here, the 'name' attribute encapsulates what in petname systems is known as an "alleged name", that is, the name for an entity proposed by a third party.</p>
<p>Such a referral SHOULD also include the user's nick as understood by the third person (encapsulated in the format defined in &jep0172;) and fingerprint of the user as understood by the third person (encapsulated in the format defined in the proposal available at &lt;<link url='http://www.jabber.org/jeps/inbox/fingerprint.html'>http://www.jabber.org/jeps/inbox/fingerprint.html</link>&gt;:</p>
<p>Such a referral SHOULD also include the user's nick as understood by the third person (encapsulated in the format defined in &xep0172;) and fingerprint of the user as understood by the third person (encapsulated in the format defined in the proposal available at &lt;<link url='http://www.jabber.org/jeps/inbox/fingerprint.html'>http://www.jabber.org/jeps/inbox/fingerprint.html</link>&gt;:</p>
<example caption='Referral With Nickname and Fingerprint'><![CDATA[
<message from='peter@saint-andre.com' to='MaineBoy@jabber.org'>
<x xmlns='http://jabber.org/protocol/rosterx'>
@ -116,7 +116,7 @@
<example caption='A Basic Subscription Request'><![CDATA[
<presence from='stpeter@jabber.org to='MaineBoy@jabber.org' type='subscribe'/>
]]></example>
<p>Naturally, based on the JID, it is possible to pull information about the sender from a persistent data store such as an LDAP database, &jep0054; node, or future profile system. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender (encapsulated via the format specified in <cite>JEP-0172</cite>) and the fingerprint of the sender's certificate or key.</p>
<p>Naturally, based on the JID, it is possible to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or future profile system. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender (encapsulated via the format specified in <cite>XEP-0172</cite>) and the fingerprint of the sender's certificate or key.</p>
<example caption='Subscription Request With Nickname and Fingerprint'><![CDATA[
<presence from='stpeter@jabber.org to='MaineBoy@jabber.org' type='subscribe'>
<nick xmlns='http://jabber.org/protocol/nick'>psa</nick>
@ -135,7 +135,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'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
</jep>
</xep>

40
xep-0166.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</title>
<abstract>This document defines a framework for initiating and managing peer-to-peer sessions (e.g., voice and video exchanges) between Jabber/XMPP clients in a way that is interoperable with existing Internet standards.</abstract>
@ -66,7 +66,7 @@
<version>0.4</version>
<date>2006-03-01</date>
<initials>psa/jb</initials>
<remark><p>Added glossary; clarified state machines; updated to reflect publication of JEP-0176 and JEP-0177.</p></remark>
<remark><p>Added glossary; clarified state machines; updated to reflect publication of XEP-0176 and XEP-0177.</p></remark>
</revision>
<revision>
<version>0.3</version>
@ -84,7 +84,7 @@
<version>0.1</version>
<date>2005-12-15</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.10</version>
@ -114,7 +114,7 @@
<version>0.0.6</version>
<date>2005-10-27</date>
<initials>psa</initials>
<remark><p>Added Jabber Registrar considerations; defined schema; completed slight syntax cleanup.</p></remark>
<remark><p>Added XMPP Registrar considerations; defined schema; completed slight syntax cleanup.</p></remark>
</revision>
<revision>
<version>0.0.5</version>
@ -148,14 +148,14 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>There exists no widely-adopted standard for initiating and managing peer-to-peer (p2p) interactions (such as voice, video, or file sharing exchanges) from within Jabber/XMPP clients. Although several large service providers and Jabber/XMPP clients have written and implemented their own proprietary XMPP extensions for p2p signalling (usually only for voice), those technologies are not open and do not always take into account requirements to interoperate with the Public Switched Telephone Network (PSTN) or emerging SIP-based Internet voice networks. By contrast, the only existing open protocol has been &jep0111;, which made it possible to initiate and manage p2p sessions, but which did not provide enough of the key signalling semantics to be easily implemented in Jabber/XMPP clients. <note>It is true that TINS made it relatively easy to implement an XMPP-to-SIP gateway; however, in line with the long-time Jabber philosophy of "simple clients, complex servers", it would be better to force complexity onto the server-side gateway and to keep the client as simple as possible.</note></p>
<p>There exists no widely-adopted standard for initiating and managing peer-to-peer (p2p) interactions (such as voice, video, or file sharing exchanges) from within Jabber/XMPP clients. Although several large service providers and Jabber/XMPP clients have written and implemented their own proprietary XMPP extensions for p2p signalling (usually only for voice), those technologies are not open and do not always take into account requirements to interoperate with the Public Switched Telephone Network (PSTN) or emerging SIP-based Internet voice networks. By contrast, the only existing open protocol has been &xep0111;, which made it possible to initiate and manage p2p sessions, but which did not provide enough of the key signalling semantics to be easily implemented in Jabber/XMPP clients. <note>It is true that TINS made it relatively easy to implement an XMPP-to-SIP gateway; however, in line with the long-time Jabber philosophy of "simple clients, complex servers", it would be better to force complexity onto the server-side gateway and to keep the client as simple as possible.</note></p>
<p>The result has been an unfortunate fragmentation within the XMPP community regarding signalling protocols. There are, essentially, two approaches to solving the problem:</p>
<ol>
<li>Recommend that all client developers implement a dual-stack (XMPP + SIP) solution.</li>
<li>Define a full-featured protocol for XMPP signalling.</li>
</ol>
<p>Implementation experience indicates that a dual-stack approach may not be feasible on all the computing platforms for which Jabber clients have been written, or even desirable on platforms where it is feasible. <note>For example, one large ISP recently decided to switch to a pure XMPP approach after having implemented and deployed a dual-stack client for several years.</note> Therefore, it seems reasonable to define an XMPP signalling protocol that can provide the necessary signalling semantics while also making it possible to interoperate with existing Internet standards.</p>
<p>As a result of feedback received on <cite>JEP-0111</cite>, the second and fourth authors of this document began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team, <note>Google Talk is a messaging and voice chat service and client provided by Google; see &lt;<link url='http://www.google.com/talk/'>http://www.google.com/talk/</link>&gt;.</note> it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified therein is, therefore, substantially equivalent to the existing Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication within the Jabber Software Foundation's standards process.</p>
<p>As a result of feedback received on <cite>XEP-0111</cite>, the second and fourth authors of this document began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team, <note>Google Talk is a messaging and voice chat service and client provided by Google; see &lt;<link url='http://www.google.com/talk/'>http://www.google.com/talk/</link>&gt;.</note> it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified therein is, therefore, substantially equivalent to the existing Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication within the Jabber Software Foundation's standards process.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The protocol defined herein is designed to meet the following requirements:</p>
@ -167,7 +167,7 @@
</ol>
<p>This document defines the signalling protocol only. Additional documents specify the following:</p>
<ul>
<li><p>Various content description formats (audio, video, etc.) and, where possible, mapping those types to the Session Description Protocol (SDP; see &rfc4566;); one example is &jep0167;.</p></li>
<li><p>Various content description formats (audio, video, etc.) and, where possible, mapping those types to the Session Description Protocol (SDP; see &rfc4566;); one example is &xep0167;.</p></li>
<li><p>Various content transport methods.</p></li>
<li><p>Procedures for mapping the Jingle signalling protocol to existing signalling standards such as the IETF's Session Initiation Protocol (SIP; see &rfc3261;) and the ITU's H.323 protocol (see &h323;).</p></li>
</ul>
@ -192,7 +192,7 @@
</tr>
<tr>
<td>Transport Method</td>
<td>The method for establishing data stream(s) between entities. Possible transports might include &jep0176;, &jep0177;, inband data, etc. This is the 'how' of the session. In Jingle XML syntax this is the namespace of the &TRANSPORT; element. The content transport method defines how to transfer bits from one host to another.</td>
<td>The method for establishing data stream(s) between entities. Possible transports might include &xep0176;, &xep0177;, inband data, etc. This is the 'how' of the session. In Jingle XML syntax this is the namespace of the &TRANSPORT; element. The content transport method defines how to transfer bits from one host to another.</td>
</tr>
<tr>
<td>Component</td>
@ -271,7 +271,7 @@ PENDING o---------------------+ |
</ol>
<p>The &CONTENT; element also specifies who will be sending content (the initiator, the recipient, or both).</p>
<section3 topic='Content Description Formats' anchor='concepts-description'>
<p>When negotiating the session and its content type, the entities involved in the session need to exchange content description formats. The approach taken herein is to specify pure session description information in separate specifications, one for each content description format (audio, video, etc.). <note>While it is possible to send raw Session Description Protocol (SDP) data for the session descriptions (the approach that was taken in <cite>JEP-0111</cite>), this is not necessarily helpful, since SDP is not structured data, not all SDP data is needed or used in the most common use cases, and SDP has been heavily extended in several useful directions that are not captured in the core SDP specification.</note> The session negotiation must contain some content description format(s), which are defined in separate specifications. Those specifications also define the state chart for the content description format in question.</p>
<p>When negotiating the session and its content type, the entities involved in the session need to exchange content description formats. The approach taken herein is to specify pure session description information in separate specifications, one for each content description format (audio, video, etc.). <note>While it is possible to send raw Session Description Protocol (SDP) data for the session descriptions (the approach that was taken in <cite>XEP-0111</cite>), this is not necessarily helpful, since SDP is not structured data, not all SDP data is needed or used in the most common use cases, and SDP has been heavily extended in several useful directions that are not captured in the core SDP specification.</note> The session negotiation must contain some content description format(s), which are defined in separate specifications. Those specifications also define the state chart for the content description format in question.</p>
<p>The generic state machine for management of any given content description format is as follows:</p>
<code>
START
@ -366,10 +366,10 @@ PENDING o---------------------+ |
</section1>
<section1 topic='Protocol' anchor='protocol'>
<section2 topic='Resource Determination' anchor='protocol-resource'>
<p>In order to initiate a Jingle session, the initiating entity must determine which of the target entity's XMPP resources is best for the desired content description format. If a contact has only one XMPP resource, this task MUST be completed using &jep0030; or the presence-based profile of service discovery specified in &jep0115;.</p>
<p>Naturally, instead of sending service discovery requests to every contact in a user's roster, it is more efficient to use <cite>Entity Capabilities</cite>, whereby support for Jingle and various Jingle content description formats and content transport methods is determined for a client version in general (rather than on a per-JID basis) and then cached. Refer to <cite>JEP-0115</cite> for details.</p>
<p>In order to initiate a Jingle session, the initiating entity must determine which of the target entity's XMPP resources is best for the desired content description format. If a contact has only one XMPP resource, this task MUST be completed using &xep0030; or the presence-based profile of service discovery specified in &xep0115;.</p>
<p>Naturally, instead of sending service discovery requests to every contact in a user's roster, it is more efficient to use <cite>Entity Capabilities</cite>, whereby support for Jingle and various Jingle content description formats and content transport methods is determined for a client version in general (rather than on a per-JID basis) and then cached. Refer to <cite>XEP-0115</cite> for details.</p>
<p>If a contact has more than one XMPP resource, it may be that only one of the resources supports Jingle and the desired content description format, in which case the user MUST initiate the Jingle signalling with that resource.</p>
<p>If a contact has more than one XMPP resource that supports Jingle and the desired content description format, it is RECOMMENDED for a client to use &jep0168; in order to determine which is the best resource with which to initiate the desired Jingle session.</p>
<p>If a contact has more than one XMPP resource that supports Jingle and the desired content description format, it is RECOMMENDED for a client to use &xep0168; in order to determine which is the best resource with which to initiate the desired Jingle session.</p>
</section2>
<section2 topic='Initiation' anchor='protocol-initiate'>
<p>Once the initiating entity has discovered which of the target entity's XMPP resources is ideal for the desired content description format, it sends a session initiation request to the target entity. This request is an IQ-set containing a &JINGLE; element qualified by the 'http://jabber.org/protocol/jingle' namespace. The &JINGLE; element MUST possess the 'action', 'initiator', and 'sid' attributes (the latter two uniquely identify the session). For initiation, the 'action' attribute MUST have a value of "session-initiate" and the &JINGLE; element MUST contain one or more &CONTENT; elements, each of which defines a content type to be transferred during the session; each &CONTENT; element in turn contains one &DESCRIPTION; child element that specifies a desired content description format and one or more &TRANSPORT; child elements that specify potential content transport methods.</p>
@ -697,15 +697,15 @@ PENDING o---------------------+ |
</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' and 'http://jabber.org/protocol/jingle#errors' in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Jingle Content Description Formats Registry' anchor='registrar-content'>
<p>The Jabber Registrar shall maintain a registry of Jingle content description formats. All content description format registrations shall be defined in separate documents (not in this JEP). Content description formats defined within the JEP series MUST be registered with the Jabber Registrar, resulting in protocol URIs of the form "http://jabber.org/protocol/jingle/description/name" (where "name" is the registered name of the content description format).</p>
<p>The XMPP Registrar shall maintain a registry of Jingle content description formats. All content description format registrations shall be defined in separate specifications (not in this document). Content description formats defined within the XEP series MUST be registered with the XMPP Registrar, resulting in protocol URIs of the form "http://jabber.org/protocol/jingle/description/name" (where "name" is the registered name of the content description format).</p>
&REGPROCESS;
<code><![CDATA[
<content>
@ -716,7 +716,7 @@ PENDING o---------------------+ |
]]></code>
</section2>
<section2 topic='Jingle Content Transport Methods Registry' anchor='registrar-transports'>
<p>The Jabber Registrar shall maintain a registry of Jingle content transport methods. All content transport method registrations shall be defined in separate documents (not in this JEP). Content transport methods defined within the JEP series MUST be registered with the Jabber Registrar, resulting in protocol URIs of the form "http://jabber.org/protocol/jingle/transport/name" (where "name" is the registered name of the content transport method).</p>
<p>The XMPP Registrar shall maintain a registry of Jingle content transport methods. All content transport method registrations shall be defined in separate specifications (not in this document). Content transport methods defined within the XEP series MUST be registered with the XMPP Registrar, resulting in protocol URIs of the form "http://jabber.org/protocol/jingle/transport/name" (where "name" is the registered name of the content transport method).</p>
&REGPROCESS;
<code><![CDATA[
<transport>
@ -823,4 +823,4 @@ PENDING o---------------------+ |
<section1 topic='Acknowledgements' anchor='ack'>
<p>The authors would like to thank Rohan Mahy for his valuable input on early versions of this document. Rob Taylor, Dafydd Harries, Jussi Laako, Saku Vainio, Antti Ij&#228;s, Brian West, Anthony Minessale, Matt O'Gorman, and others have also provided helpful input. Thanks also to those who have commented on the &SJIG; and (earlier) Jingle <note>Before this specification was accepted as a Jabber Enhancement Proposal, it was discussed on the semi-private &lt;jingle@jabber.org&gt; mailing list; although that list is no longer used (the Standards-JIG list is the preferred discussion venue), for historical purposes it is publicly archived at &lt;<link url='http://mail.jabber.org/pipermail/jingle/'>http://mail.jabber.org/pipermail/jingle/</link>&gt;.</note> mailing lists.</p>
</section1>
</jep>
</xep>

38
xep-0167.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 Audio Content Description Format</title>
<abstract>This document defines a content description format for Jingle audio 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/>
@ -28,13 +28,13 @@
<version>0.5</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.4</version>
<date>2006-07-12</date>
<initials>se/psa</initials>
<remark><p>Specified when to play received audio (early media); specified that DTMF must use in-band signalling (JEP-0181).</p></remark>
<remark><p>Specified when to play received audio (early media); specified that DTMF must use in-band signalling (XEP-0181).</p></remark>
</revision>
<revision>
<version>0.3</version>
@ -46,13 +46,13 @@
<version>0.2</version>
<date>2006-02-13</date>
<initials>psa</initials>
<remark><p>Defined info message for busy; added info message examples; recommended use of Speex; updated schema and Jabber Registrar considerations.</p></remark>
<remark><p>Defined info message for busy; added info message examples; recommended use of Speex; updated schema and XMPP Registrar considerations.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2005-12-15</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.3</version>
@ -64,7 +64,7 @@
<version>0.0.2</version>
<date>2005-10-27</date>
<initials>psa</initials>
<remark><p>Added SDP mapping, security considerations, IANA considerations, Jabber Registrar considerations, and XML schema.</p></remark>
<remark><p>Added SDP mapping, security considerations, IANA considerations, XMPP Registrar considerations, and XML schema.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -74,7 +74,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. The first session type of interest is audio chat. This document specifies a format for describing Jingle audio sessions.</p>
<p>&xep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. The first session type of interest is audio chat. This document specifies a format for describing Jingle audio sessions.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The Jingle content description format defined herein is designed to meet the following requirements:</p>
@ -102,7 +102,7 @@
<payload-type id="13" name="CN"/>
</description>
]]></example>
<p>The &lt;description/&gt; element is intended to be a child of a &JINGLE; element as specified in <cite>JEP-0166</cite>.</p>
<p>The &lt;description/&gt; element is intended to be a child of a &JINGLE; element as specified in <cite>XEP-0166</cite>.</p>
<p>When the session is provisionally accepted, as indicated by the target entity sending an empty IQ result in response to an 'initiate' message, both receiving and sending entities SHOULD start listening for audio as defined by the negotiated transport method. For interoperability with telephony systems, each entity SHOULD play any audio received at this time, before the target sends an 'accept' message.</p>
</section1>
<section1 topic='Mapping to Session Description Protocol' anchor='sdp'>
@ -129,7 +129,7 @@ a=rtpmap:98 L16/16000/2
]]></example>
</section1>
<section1 topic='Service Discovery' anchor='disco'>
<p>If an entity supports the Jingle audio content description format, it MUST advertise that fact by returning a feature of "http://jabber.org/protocol/jingle/description/audio" in response to &jep0030; information requests.</p>
<p>If an entity supports the Jingle audio content description format, it MUST advertise that fact by returning a feature of "http://jabber.org/protocol/jingle/description/audio" in response to &xep0030; information requests.</p>
<example caption="Service Discovery Information Request"><![CDATA[
<iq from='romeo@montague.net/orchard'
id='disco1'
@ -256,26 +256,26 @@ a=rtpmap:98 L16/16000/2
<p>Support for the Speex codec <note>See &lt;<link url='http://www.speex.org/'>http://www.speex.org/</link>&gt;.</note> is RECOMMENDED.</p>
</section2>
<section2 topic='DTMF' anchor='impl-dtmf'>
<p>Support for Dual Tone Multi-Frequency (DTMF) MUST use the protocol described in &jep0181;.</p>
<p>Support for Dual Tone Multi-Frequency (DTMF) MUST use the protocol described in &xep0181;.</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>The description of a format for audio 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/audio' and 'http://jabber.org/protocol/jingle/info/audio' 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 "audio" in its registry of Jingle content description formats. The registration is as follows:</p>
<p>The XMPP Registrar shall include the name "audio" in its registry of Jingle content description formats. The registration is as follows:</p>
<code><![CDATA[
<content>
<name>audio</name>
<desc>Jingle sessions that support audio exchanges</desc>
<doc>JEP-0167</doc>
<doc>XEP-0167</doc>
</content>
]]></code>
</section2>
@ -347,4 +347,4 @@ a=rtpmap:98 L16/16000/2
]]></code>
</section2>
</section1>
</jep>
</xep>

28
xep-0168.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>Resource Application Priority</title>
<abstract>This document defines an XMPP protocol extension to indicate the presence priority of XMPP resources for applications other than messaging.</abstract>
@ -17,7 +17,7 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -40,7 +40,7 @@
<version>0.1</version>
<date>2005-12-15</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.6</version>
@ -81,7 +81,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Within the Extensible Messaging and Presence Protocol (XMPP; see &rfc3920;), presence indicates availability for communication -- specifically, communication via XMPP messaging (usually in the form of "instant messaging" or IM as described in &rfc3921;). However, a wide variety of entities might provide XMPP presence, including entities that are not primarily focused on IM (e.g., phones) or even entities that do not support XMPP messaging at all.</p>
<p>Consider a scenario in which a contact wants to initiate a voice chat (e.g., via &jep0166;) with a user who has the following three XMPP resources:</p>
<p>Consider a scenario in which a contact wants to initiate a voice chat (e.g., via &xep0166;) with a user who has the following three XMPP resources:</p>
<table caption='Application Presence'>
<tr>
<th>Resource</th>
@ -158,7 +158,7 @@
<p>In the interest of saving bandwidth, a server MAY choose to strip all RAP data out of presence stanzas and instead provide RAP data only on request via IQ interactions.
A likely scenario is as follows:</p>
<ol start='1'>
<li><p>Contact's client sends &jep0030; information request to user's client or receives &jep0115; data from user's client, and thereby discovers that user's client supports the 'http://jabber.org/protocol/rap' namespace.</p></li>
<li><p>Contact's client sends &xep0030; information request to user's client or receives &xep0115; data from user's client, and thereby discovers that user's client supports the 'http://jabber.org/protocol/rap' namespace.</p></li>
<li><p>User's client publishes RAP extensions but user's server strips them out in presence broadcasts.</p></li>
<li><p>Contact decides to initiate a non-IM interaction with user.</p></li>
<li><p>Contact's client notices the lack of RAP data from user (despite discovered support) and sends disco#info request to user's server, which signals that it supports the 'http://jabber.org/protocol/raprequest' namespace.</p></li>
@ -194,7 +194,7 @@
<p>Note: The XML data of the server's response to a RAP request may seem to be potentially confusing, but it is fully consistent with &w3xmlnamespaces; as well as the schemas for the 'jabber:client' and 'http://jabber.org/protocol/raprequest' namespaces.</p>
</section1>
<section1 topic='Service Discovery' anchor='disco'>
<p>In order to discover whether a server or other entity supports this protocol, an entity MUST use &jep0030;.</p>
<p>In order to discover whether a server or other entity supports this protocol, an entity MUST use &xep0030;.</p>
<example caption='Entity queries a server regarding protocol support'><![CDATA[
<iq type='get'
from='juliet@capulet.com/balcony'
@ -238,7 +238,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 the following namespaces in its registry of protocol namespaces:</p>
<ul>
@ -247,7 +247,7 @@
</ul>
</section2>
<section2 topic='Application Types Registry' anchor='registrar-apps'>
<p>The Jabber Registrar shall maintain a registry of application types. Although strictly speaking this should not be necessary, it is desirable to maintain a list of "short names" for various application types rather than using long XML namespaces, especially in presence broadcasts. For example, a short name of "jingle-audio" is only 12 characters long, whereas the full XML namespace "http://jabber.org/protocol/jingle/description/audio" is 48 characters long. The difference can be quite significant when many presence stanzas are sent.</p>
<p>The XMPP Registrar shall maintain a registry of application types. Although strictly speaking this should not be necessary, it is desirable to maintain a list of "short names" for various application types rather than using long XML namespaces, especially in presence broadcasts. For example, a short name of "jingle-audio" is only 12 characters long, whereas the full XML namespace "http://jabber.org/protocol/jingle/description/audio" is 48 characters long. The difference can be quite significant when many presence stanzas are sent.</p>
<section3 topic='Process' anchor='registrar-apps-process'>
&REGPROCESS;
<code><![CDATA[
@ -265,14 +265,14 @@
<name>jingle-audio</name>
<ns>http://jabber.org/protocol/jingle/description/audio</ns>
<desc>Jingle audio sessions</desc>
<doc>JEP-0167</doc>
<doc>XEP-0167</doc>
</app>
<app>
<name>jingle-video</name>
<ns>http://jabber.org/protocol/jingle/description/video</ns>
<desc>Jingle video sessions</desc>
<doc>JEP-0180</doc>
<doc>XEP-0180</doc>
</app>
<app>
@ -338,4 +338,4 @@
]]></code>
</section2>
</section1>
</jep>
</xep>

52
xep-0169.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>Twas The Night Before Christmas (Jabber Version)</title>
<abstract>The classic Christmas poem annotated with Jabber/XMPP protocols.</abstract>
@ -16,14 +16,14 @@
<approver>Council</approver>
<dependencies>
<spec>XMPP IM</spec>
<spec>JEP-0045</spec>
<spec>JEP-0060</spec>
<spec>JEP-0080</spec>
<spec>JEP-0090</spec>
<spec>JEP-0107</spec>
<spec>JEP-0108</spec>
<spec>JEP-0112</spec>
<spec>JEP-0163</spec>
<spec>XEP-0045</spec>
<spec>XEP-0060</spec>
<spec>XEP-0080</spec>
<spec>XEP-0090</spec>
<spec>XEP-0107</spec>
<spec>XEP-0108</spec>
<spec>XEP-0112</spec>
<spec>XEP-0163</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -33,7 +33,7 @@
<version>1.0</version>
<date>2005-12-19</date>
<initials>psa</initials>
<remark>Happy Holidays!</remark>
<remark><p>Happy Holidays!</p></remark>
</revision>
</header>
@ -483,14 +483,14 @@
<p>This document makes reference to the following Jabber/XMPP protocols:</p>
<ul>
<li>&rfc3921;</li>
<li>&jep0045;</li>
<li>&jep0060;</li>
<li>&jep0080;</li>
<li>&jep0090;</li>
<li>&jep0107;</li>
<li>&jep0108;</li>
<li>&jep0112;</li>
<li>&jep0163;</li>
<li>&xep0045;</li>
<li>&xep0060;</li>
<li>&xep0080;</li>
<li>&xep0090;</li>
<li>&xep0107;</li>
<li>&xep0108;</li>
<li>&xep0112;</li>
<li>&xep0163;</li>
</ul>
<p>Note: For the sake of brevity, not all protocol exchanges are shown above. Refer to the appropriate specifications for detailed protocol descriptions.</p>
</section1>
@ -519,7 +519,7 @@
| |-- blitzen
|-- santa et al.
]]></code>
<p>In addition, we assume that the twas-the-night.lit server is running a virtual pubsub service for each account it hosts (in accordance with <cite>JEP-0163</cite>) and that the users "narrator", "mama", and "child" publish information to personal pubsub nodes related to mood (<cite>JEP-0107</cite>), activity (<cite>JEP-0108</cite>), and physical location (<cite>JEP-0112</cite>).</p>
<p>In addition, we assume that the twas-the-night.lit server is running a virtual pubsub service for each account it hosts (in accordance with <cite>XEP-0163</cite>) and that the users "narrator", "mama", and "child" publish information to personal pubsub nodes related to mood (<cite>XEP-0107</cite>), activity (<cite>XEP-0108</cite>), and physical location (<cite>XEP-0112</cite>).</p>
<p>* The U.S. Military divides its operations geographically among NORTHCOM, SOUTHCOM, EUCOM, and PACOM. Given the scale of operations implemented by Santa's workshop, it comes as no surprise that the command center at the North Pole is known as POLECOM. Naturally POLECOM subscribes to the pubsub feeds for Santa's geolocation and activity, as well as the sleigh's geolocation, just in case a search and rescue mission needs to be initiated.</p>
</section1>
@ -532,11 +532,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'>
<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>