moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

JEP to XEP

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@42 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-04 16:21:54 +00:00
parent a4cfd1ab6b
commit a76c0f0930
10 changed files with 211 additions and 243 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
xep-0110.xml
View File

@ -1,29 +1,22 @@
<?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>Generic Maps</title>
<abstract>A protocol for transport of generic maps (graphical displays of specific subsets of buddies).</abstract>
<!-- the following line pulls in the standard legal notice, comment it out if you are viewing your XML file in a browser that does not support external entities (e.g., Mozilla) -->
&LEGALNOTICE;
<!-- uncomment the following line to view your XML file in Mozilla (and maybe IE)
<legal>This Jabber Enhancement Proposal is copyright 1999 - 2003 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy (http://jabber.org/jsf/ipr-policy.php). This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).</legal>
-->
<number>0110</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<dependencies>None</dependencies>
<!-- the following 3 elements are for use by the JEP Editor -->
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>Not yet assigned</shortname>
<!-- firstname, surname, email, and jid are all MANDATORY per JEP-0001 -->
<!-- include one author section for each co-author -->
<author>
<firstname>Jiri</firstname>
<surname>Komzak</surname>
@ -45,7 +38,7 @@
</header>
<section1 topic='Introduction'>
<p>Generic maps provide a way to extending the roster into a general display showing contacts (JIDs) together with further additional information. The further information is provided by the position in the map (and possibly by the dot type - e.g. shape or colour). In addition to showing people belonging to one roster group, it is possible to cluster people, use more detailed inset maps etc. each of these features providing a unique context.</p>
<p>The motivations for this JEP are:</p>
<p>The motivations for this document are:</p>
<ul>
<li>It is faster and easier to find people using a rich graphical view as compared to linear lists/trees</li>
<li>Maps provide easily understandable further information (context) about the contact</li>
@ -85,7 +78,7 @@
<p>The map in Example 1 uses an implicit map projection assuming that attributes x and y are directly the co-ordinates of a particular entity (e.g. buddy1@jabber.org) in the image (ortho_0.gif) expressed in pixels.</p>
</section2>
<section2 topic='Definition of projection'>
<p>A similar map with coordinates specified using geographic latitude + longitude (possibly obtained using Geographic Location Information <note>JEP-0080: Geographic Location Information <link url='http://www.jabber.org/jeps/jep-0080.html'>http://www.jabber.org/jeps/jep-0080.html</link></note> extension) is shown in Example 2 (only the map tag is shown).</p>
<p>A similar map with coordinates specified using geographic latitude + longitude (possibly obtained using Geographic Location Information <note>XEP-0080: Geographic Location Information <link url='http://www.xmpp.org/extensions/xep-0080.html'>http://www.xmpp.org/extensions/xep-0080.html</link></note> extension) is shown in Example 2 (only the map tag is shown).</p>
<example caption='Generic map tag using geographic coordinates'><![CDATA[
<map xmlns='http://jabber.org/protocol/map' id='map2.ygf'>
<layer id='inset_1' offset_x='0' offset_y='0' scale='1'>
@ -114,9 +107,6 @@
]]></example>
</section2>
</section1>
<!-- section1 topic='Error Codes'>
<p>If your proposal defines a number of error and status codes (as is done in JEP-0045), it is a good idea to include a table of all the codes defined in your document. This will help developers who want to implement your JEP.</p>
</section1 -->
<section1 topic='Implementation Notes'>
<p>The following guidelines may assist the developers of a mapping plug-in in the Jabber clients.</p>
<section2 topic='Parsing equations for map projections'>
@ -126,7 +116,7 @@
<p>The image files (maps) are transferred as an extra extension of packet using the filename as a unique id.</p>
</section2>
<section2 topic='Attributes for determination of coordinates'>
<p>The attributes are either specified in the &lt;map/&gt; tag or known in the environment (e.g. presence), but they could be also provided by a subscribed service using Publish-Subscribe <note>JEP-0060: Publish-Subscribe <link url='http://www.jabber.org/jeps/jep-0060.html'>http://www.jabber.org/jeps/jep-0060.html</link></note> (e.g. GPS or LBS from a mobile operator).</p>
<p>The attributes are either specified in the &lt;map/&gt; tag or known in the environment (e.g. presence), but they could be also provided by a subscribed service using Publish-Subscribe <note>XEP-0060: Publish-Subscribe <link url='http://www.xmpp.org/extensions/xep-0060.html'>http://www.xmpp.org/extensions/xep-0060.html</link></note> (e.g. GPS or LBS from a mobile operator).</p>
</section2>
<section2 topic='Clusters - accumulation of attribute values'>
<p>The clustering of items can be specified directly in the map tag or done using a pixel resolution of the display available.</p>
@ -138,19 +128,7 @@
<section1 topic='IANA Considerations'>
<p>No IANA interaction required.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<p>The Jabber Registrar <note>The Jabber Registrar maintains a list of reserved Jabber namespaces as well as a registry of parameters used in the context of JEPs approved by the JSF. For further information, see <link url='http://www.jabber.org/registrar/'>http://www.jabber.org/registrar/</link></note> will need to register the new namespace of "http://jabber.org/protocol/map".</p>
<section1 topic='XMPP Registrar Considerations'>
<p>The &REGISTRAR; will need to register the new namespace of "http://jabber.org/protocol/map".</p>
</section1>
<!-- section1 topic='Formal Definition'>
<section2 topic='Schema'>
<p>An XML Schema is required in order for a Standards-Track JEP to advance to a status of Draft or Final. The JEP Editor can assist you in defining an XML Schema for the protocol you are proposing.</p>
</section2>
<section2 topic='DTD'>
<p>A Document Type Definition (DTD) is optional.</p>
</section2>
</section1 -->
<!-- section1 topic='Conclusion'>
<p>For further information about the JEP process, please familiarize yourself with JEP-0001. For examples of formatting, refer to this template and also to existing JEPs. For an understanding of current issues of interest to the Jabber community and to follow discussions of the Jabber protocol, make sure you are subscribed to the mailing list of the Standards JIG <note><link url='http://mailman.jabber.org/listinfo/standards-jig/'>http://mailman.jabber.org/listinfo/standards-jig/</link></note>.</p>
<p>If you have any questions or have difficulties writing your JEP, feel free to contact the JEP Editor via email at editor@jabber.org.</p>
</section1 -->
</jep>
</xep>

32
xep-0111.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>A Transport for Initiating and Negotiating Sessions (TINS)</title>
<abstract>This document defined a SIP-compatible transport for initiating and negotiating sessions using SDP over XMPP.</abstract>
@ -20,7 +20,7 @@
</dependencies>
<supersedes/>
<supersededby>
<spec>JEP-0166</spec>
<spec>XEP-0166</spec>
</supersededby>
<shortname>tins</shortname>
&hildjj;
@ -29,7 +29,7 @@
<version>0.8</version>
<date>2005-12-21</date>
<initials>psa/jjh</initials>
<remark>Retracted in favor of Jingle (JEP-0166).</remark>
<remark>Retracted in favor of Jingle (XEP-0166).</remark>
</revision>
<revision>
<version>0.7</version>
@ -41,7 +41,7 @@
<version>0.6</version>
<date>2004-10-26</date>
<initials>psa/jjh</initials>
<remark>Added extended addresses and SHIM headers to examples in order to illustrate the use of JEP-0033 and JEP-0121.</remark>
<remark>Added extended addresses and SHIM headers to examples in order to illustrate the use of XEP-0033 and XEP-0121.</remark>
</revision>
<revision>
<version>0.5</version>
@ -75,13 +75,13 @@
</revision>
</header>
<section1 topic="Introduction" anchor='intro'>
<p><em>Note Well: This proposal has been retracted by the authors in favor of &jep0166;.</em></p>
<p><em>Note Well: This proposal has been retracted by the authors in favor of &xep0166;.</em></p>
<p>The Session Description Protocol (SDP; see &rfc2327;) provides a mechanism for describing multimedia sessions that are advertised and negotiated over the Internet. The "Transport for Initiating and Negotiating Sessions" (TINS) specified herein describes how to use SDP to build a framework for media stream/session initiation and negotiation between entities that natively support XMPP (see &rfc3920;).
<note>The approach taken herein is to send pure SDP. While earlier versions of this document used &sdpng; (an XML representation of SDP), SDPng is a more experimental technology; by contrast, SDP is a stable protocol and there is broad support for it by existing gateways and devices. The use of SDP rather than SDPng thus enables the Jabber/XMPP community to implement solutions that are deployable on the Internet today.</note>
In particular, TINS provides an XMPP representation of standard session management semantics such as those provided by the Session Initiation Protocol (SIP; see &rfc3261;). As a result, native XMPP clients that support TINS can negotiate out-of-band multimedia sessions (e.g., use of the Real-Time Transport Protocol or RTP; see &rfc3550;) and XMPP services that support TINS can easily interoperate with SIP services through gateways.</p>
</section1>
<section1 topic="Requirements" anchor='reqs'>
<p>This JEP addresses the following requirements:</p>
<p>This document addresses the following requirements:</p>
<ol>
<li>Enable an XMPP entity to negotiate an out-of-band multimedia session with another XMPP entity.</li>
<li>Enable an XMPP entity to negotiate an out-of-band multimedia session with a non-XMPP entity through a gateway.</li>
@ -102,14 +102,14 @@
Any restricted XML characters in the SDP data (i.e., &amp; &apos; &lt; &gt; &quot;) MUST be properly escaped when contained in the XML character data of the &lt;sdp/&gt; element (for example, the ' character MUST be escaped to &amp;apos;). It is the responsibility of the XMPP recipient or translating gateway to unescape these restricted characters for processing.</p>
<p>The request stanza MAY also include either or both of the following:</p>
<ul>
<li>Header information or Internet metadata (such as that defined by <cite>RFC 3261</cite>) in the format specified by &jep0131;.</li>
<li>Multicast addresses as specified by &jep0033;.</li>
<li>Header information or Internet metadata (such as that defined by <cite>RFC 3261</cite>) in the format specified by &xep0131;.</li>
<li>Multicast addresses as specified by &xep0033;.</li>
</ul>
<p>In reply to a request, the receiver MUST send zero or more replies, with the value of the 'method' attribute set to a value of "result" and the value of the 'code' attribute set to one of the valid SIP response codes as specified in Section 21 of <cite>RFC 3261</cite>.</p>
</section1>
<section1 topic="Discovering Support" anchor='discovery'>
<p>Before initiating a TINS negotiation, an XMPP entity SHOULD determine that the target entity supports the 'http://jabber.org/protocol/tins' namespace. Such discovery SHOULD occur by means of &jep0030;, either directly by querying the target entity or indirectly by means of &jep0115;. If the target entity is a non-XMPP entity that is contacted through a gateway, the gateway itself SHOULD reply to service discovery queries on behalf of the non-XMPP entity and SHOULD insert a client capabilities extension into the presence stanzas it generates on behalf of the non-XMPP entity.</p>
<p>If an XMPP entity receives, or a gateway handles, a &MESSAGE; stanza containing a &lt;tins/&gt; element qualified by the 'http://jabber.org/protocol/tins' namespace but it does not understand the TINS protocol, it SHOULD either silently ignore it or return a &unavailable; error (see &jep0086; for error syntax).</p>
<p>Before initiating a TINS negotiation, an XMPP entity SHOULD determine that the target entity supports the 'http://jabber.org/protocol/tins' namespace. Such discovery SHOULD occur by means of &xep0030;, either directly by querying the target entity or indirectly by means of &xep0115;. If the target entity is a non-XMPP entity that is contacted through a gateway, the gateway itself SHOULD reply to service discovery queries on behalf of the non-XMPP entity and SHOULD insert a client capabilities extension into the presence stanzas it generates on behalf of the non-XMPP entity.</p>
<p>If an XMPP entity receives, or a gateway handles, a &MESSAGE; stanza containing a &lt;tins/&gt; element qualified by the 'http://jabber.org/protocol/tins' namespace but it does not understand the TINS protocol, it SHOULD either silently ignore it or return a &unavailable; error (see &xep0086; for error syntax).</p>
</section1>
<section1 topic="Examples" anchor='examples'>
<section2 topic="Negotiating a Voice Call" anchor='examples-call'>
@ -279,10 +279,10 @@
</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/tins' in its registry of protocol namespaces.</p>
</section2>
@ -332,4 +332,4 @@
</section2>
</section1>
</jep>
</xep>

54
xep-0112.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>User Physical Location</title>
<abstract>This document defines a protocol for communicating information about the current physical location of a Jabber entity. NOTE WELL: The protocol defined herein has been folded into JEP-0080.</abstract>
<abstract>This document defines a protocol for communicating information about the current physical location of a Jabber entity. NOTE WELL: The protocol defined herein has been folded into XEP-0080.</abstract>
&LEGALNOTICE;
<number>0112</number>
<status>Obsolete</status>
@ -15,16 +15,13 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0060</spec>
<spec>XEP-0060</spec>
</dependencies>
<supersedes/>
<supersededby>
<spec>JEP-0080</spec>
<spec>XEP-0080</spec>
</supersededby>
<shortname>physloc</shortname>
<schemaloc>
<url>http://jabber.org/protocol/physloc/physloc.xsd</url>
</schemaloc>
&stpeter;
<revision>
<version>1.0</version>
@ -54,19 +51,19 @@
<version>0.5</version>
<date>2004-05-11</date>
<initials>psa</initials>
<remark>Changed root element, namespace, and shortname to physloc to prevent conflict with JEP-0033.</remark>
<remark>Changed root element, namespace, and shortname to physloc to prevent conflict with XEP-0033.</remark>
</revision>
<revision>
<version>0.4</version>
<date>2004-04-25</date>
<initials>psa</initials>
<remark>Corrected several errors; added reference to JEP-0033.</remark>
<remark>Corrected several errors; added reference to XEP-0033.</remark>
</revision>
<revision>
<version>0.3</version>
<date>2004-02-19</date>
<initials>psa</initials>
<remark>Revived JEP upon modifications to JEP-0080; changed root element, namespace, and shortname to 'address'.</remark>
<remark>Revived document upon modifications to XEP-0080; changed root element, namespace, and shortname to 'address'.</remark>
</revision>
<revision>
<version>0.2</version>
@ -82,8 +79,8 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p><em>NOTE WELL: The protocol defined herein has been folded into &jep0080;.</em></p>
<p>This JEP defines an extension mechanism for capturing "extended presence" information about a user's current physical location. The information structures defined herein are intended to provide a format for describing a location or address that may change fairly frequently (e.g., one's location on a campus or in a large building) in situations where the user or application does not possess, or does not wish to communicate, detailed latitude/longitude data of the type defined in <cite>JEP-0080</cite>.</p>
<p><em>NOTE WELL: The protocol defined herein has been folded into &xep0080;.</em></p>
<p>This document defines an extension mechanism for capturing "extended presence" information about a user's current physical location. The information structures defined herein are intended to provide a format for describing a location or address that may change fairly frequently (e.g., one's location on a campus or in a large building) in situations where the user or application does not possess, or does not wish to communicate, detailed latitude/longitude data of the type defined in <cite>XEP-0080</cite>.</p>
</section1>
<section1 topic='Protocol' anchor='protocol'>
<p>Information about the user's location is provided by the user and propagated on the network by the user's client. The information is structured by means of an &lt;physloc/&gt; element that is qualified by the 'http://jabber.org/protocol/physloc' namespace. The location information itself is provided as the XML character data of the following children of the &lt;physloc/&gt; element:</p>
@ -102,7 +99,7 @@
</table>
</section1>
<section1 topic='Usage' anchor='usage'>
<p>The &lt;physloc/&gt; information SHOULD be communicated by means of &jep0060;. Because physical location information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.</p>
<p>The &lt;physloc/&gt; information SHOULD be communicated by means of &xep0060;. Because physical location information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.</p>
<example caption='User Publishes Address'><![CDATA[
<iq type='set'
from='stpeter@jabber.org/laptop'
@ -146,7 +143,7 @@
.
.
]]></example>
<p>As mentioned in JEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &jep0033; protocol) to provide an explicit association between the published data and the user:</p>
<p>As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:</p>
<example caption='Event notification with extended stanza addressing'><![CDATA[
<message
from='pubsub.jabber.org'
@ -171,12 +168,12 @@
]]></example>
</section1>
<section1 topic='Mapping to Other Formats' anchor='mapping'>
<p>There are many XML data formats for physical location or address information. It is beyond the scope of this JEP to provide a mapping from the extension defined herein to every such format. However, it would be valuable to provide a mapping from the Jabber/XMPP format to the formats used in other presence or extended presence protocols. The two main protocols of interest are:</p>
<p>There are many XML data formats for physical location or address information. It is beyond the scope of this document to provide a mapping from the extension defined herein to every such format. However, it would be valuable to provide a mapping from the Jabber/XMPP format to the formats used in other presence or extended presence protocols. The two main protocols of interest are:</p>
<ol>
<li><p>The Wireless Village (now "IMPS") specifications for mobile instant messaging; these specifications define a presence attribute for address information as encapsulated in the IMPS "Address" element <note>The Wireless Village Initiative: Presence Attributes v1.1 (WV-029); for further information, visit &lt;<link url='http://www.openmobilealliance.org/tech/affiliates/wv/wvindex.html'>http://www.openmobilealliance.org/tech/affiliates/wv/wvindex.html</link>&gt;.</note>.</p></li>
<li><p>The SIP-based SIMPLE specifications; in particular, the IETF's GEOPRIV Working Group has defined an extension to the IETF's &pidf; for location information, as specified in &rfc4119; (also known as "PIDF-LO").</p></li>
</ol>
<p>The following table also maps the format defined herein to the vCard XML format specified in &jep0054;.</p>
<p>The following table also maps the format defined herein to the vCard XML format specified in &xep0054;.</p>
<table caption='Mapping Jabber Physical Location to IMPS, PIDF-LO, and vCard'>
<tr>
<th>Jabber/XMPP</th>
@ -189,7 +186,7 @@
<td align='center'>&lt;Country/&gt;</td>
<td align='center'>&lt;country/&gt;</td>
<td align='center'>&lt;CTRY/&gt;
<note>As noted in JEP-0054, the XML vCard format defined in draft-dawson-vcard-xml-dtd-01 specified a &lt;COUNTRY/&gt; element rather than a &lt;CTRY/&gt; element; refer to JEP-0054 for details.</note>
<note>As noted in XEP-0054, the XML vCard format defined in draft-dawson-vcard-xml-dtd-01 specified a &lt;COUNTRY/&gt; element rather than a &lt;CTRY/&gt; element; refer to XEP-0054 for details.</note>
</td>
</tr>
<tr>
@ -253,7 +250,7 @@
<tr>
<td align='center'>--</td>
<td align='center'>&lt;Accuracy/&gt;
<note>This element provides accuracy in meters. The geolocation protocol defined in JEP-0080 specifies such an element for Jabber/XMPP, which SHOULD be used when mapping from IMPS to Jabber.</note>
<note>This element provides accuracy in meters. The geolocation protocol defined in XEP-0080 specifies such an element for Jabber/XMPP, which SHOULD be used when mapping from IMPS to Jabber.</note>
</td>
<td align='center'>--</td>
<td align='center'>--</td>
@ -275,11 +272,11 @@
<p>It is imperative to control access to location information, at least by default. Imagine that a stalker got unauthorized access to this information, with enough accuracy and timeliness to be able to find the target person. This scenario could lead to loss of life, so please take access control checks seriously. A user SHOULD take care in approving subscribers and in characterizing his or her current physical location.</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; includes 'http://jabber.org/protocol/physloc' in its registry of protocol namespaces.</p>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/physloc' in its registry of protocol namespaces, but the namespace is deprecated.</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
@ -292,13 +289,6 @@
xmlns='http://jabber.org/protocol/physloc'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0112: http://www.jabber.org/jeps/jep-0112.html
</xs:documentation>
</xs:annotation>
<xs:element name='physloc'>
<xs:complexType>
<xs:sequence>
@ -319,4 +309,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

22
xep-0113.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 Whiteboarding</title>
<abstract>A proposal for an extremely simple whiteboarding protocol over Jabber.</abstract>
@ -37,14 +37,14 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>As explained in the now obsolete JEP-0010: Whiteboarding <note>JIG JEP-0010: Whiteboarding JIG <link url="http://www.jabber.org/jeps/jep-0010.html">http://www.jabber.org/jeps/jep-0010.html</link></note>: "Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value".</p>
<p>As explained in the now obsolete XEP-0010: Whiteboarding <note>JIG XEP-0010: Whiteboarding JIG <link url="http://www.xmpp.org/extensions/xep-0010.html">http://www.xmpp.org/extensions/xep-0010.html</link></note>: "Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value".</p>
<p>The increasing penetration of pen-based devices, such as PDAs and tablet PCs, makes the need for a protocol that allows for sending freehand drawing information more urgent.</p>
<p>Several attempts have been made to create a whiteboarding protocol for Jabber:</p>
<ol>
<li>Collaborative Imaging (Whiteboarding via Streaming XPM) <note>XPM over Jabber (<link url="http://docs.jabber.org/draft-proto/html/sxpm.html">http://docs.jabber.org/draft-proto/html/sxpm.html</link>)</note> describes a protocol that sends partial bitmaps. This protocol is not suitable for freehand drawing and has not been implemented.</li>
<li>Jabber Whiteboarding using SVG <note>Jabber Whiteboarding using SVG <link url="http://www.protocol7.com/jabber/whiteboard_proposal.txt">http://www.protocol7.com/jabber/whiteboard_proposal.txt</link></note> describes a protocol that uses a subset of SVG. It refers to a missing DTD that describes the precise subset, but there is little doubt that that subset will be hard to implement. This protocol has not been implemented.</li>
<li>Coccinella <note>Coccinella Project Information - JabberStudio <link url="http://www.jabberstudio.org/projects/coccinella/project/view.php">http://www.jabberstudio.org/projects/coccinella/project/view.php</link></note> is an open source implementation of a whiteboarding protocol. However, the protocol has not been documented and does not seem easy to implement. In fact it is mostly raw TCL, making an implementation of that protocol in a language other than TCL rather difficult.</li>
<li>Tkabber <note>Tkabber Project Information - JabberStudio <link url="http://http://www.jabberstudio.org/projects/tkabber/project/view.php">http://www.jabberstudio.org/projects/tkabber/project/view.php</link></note> has a whiteboard plugin. The protocol has not been documented, but it uses a subset of SVG, similar to the one defined in this JEP.</li>
<li>Tkabber <note>Tkabber Project Information - JabberStudio <link url="http://http://www.jabberstudio.org/projects/tkabber/project/view.php">http://www.jabberstudio.org/projects/tkabber/project/view.php</link></note> has a whiteboard plugin. The protocol has not been documented, but it uses a subset of SVG, similar to the one defined in this document.</li>
</ol>
</section1>
<section1 topic='Requirements'>
@ -177,7 +177,7 @@
</section1>
<section1 topic='Implementation Notes'>
<section2 topic='The GUI'>
<p>Usually when a user wants to send a message to a contact, the client will present her with a choice between sending a message or starting a chat. If the client implements the present protocol, the client can add the options of sending a whiteboard message and starting a whiteboard chat. Whether the client offers these options for an individual contact could be based on standard &jep0030; or &jep0011; techniques.</p>
<p>Usually when a user wants to send a message to a contact, the client will present her with a choice between sending a message or starting a chat. If the client implements the present protocol, the client can add the options of sending a whiteboard message and starting a whiteboard chat. Whether the client offers these options for an individual contact could be based on standard &xep0030; or &xep0011; techniques.</p>
<p>Presentation of a path in case of a "Single whiteboard message" is rather obvious. The presentation of multiple-user whiteboards, either chat or conference, leaves more to the imagination of the implementor. The implementor could decide to use different colors for paths drawn by different users. The saturation of a path could decrease with age.</p>
</section2>
<section2 topic='Karma'>
@ -220,10 +220,10 @@
<p>There are no security features or concerns related to this proposal.</p>
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with the &IANA;.</p>
<p>This document requires no interaction with the &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<p>This JEP requires registration of the namespace "http://jabber.org/protocol/swb" by the &REGISTRAR;.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>This document requires registration of the namespace "http://jabber.org/protocol/swb" by the &REGISTRAR;.</p>
</section1>
<section1 topic='Formal Definition'>
<section2 topic='Schema'>
@ -380,4 +380,4 @@
<section1 topic='Acknowledgements'>
<p>The author would like to thank Alexey Shchepin for helpful comments.</p>
</section1>
</jep>
</xep>

28
xep-0114.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>Jabber Component Protocol</title>
<abstract>This specification documents the existing protocol used for communication between servers and "external" components over the Jabber network.</abstract>
@ -21,11 +21,11 @@
<shortname>component</shortname>
<schemaloc>
<ns>jabber:component:accept</ns>
<url>http://jabber.org/protocol/component/accept.xsd</url>
<url>http://www.xmpp.org/schemas/component-accept.xsd</url>
</schemaloc>
<schemaloc>
<ns>jabber:component:connect</ns>
<url>http://jabber.org/protocol/component/connect.xsd</url>
<url>http://www.xmpp.org/schemas/component-connect.xsd</url>
</schemaloc>
&stpeter;
<revision>
@ -72,14 +72,14 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Jabber network has long included a wire protocol that enables trusted components to connect to Jabber servers. While this component protocol is minimal and will probably be superseded by a more comprehensive component protocol at some point, informational documentation of the existing protocol would be helpful for component and server developers. This JEP provides such documentation.</p>
<p>The Jabber network has long included a wire protocol that enables trusted components to connect to Jabber servers. While this component protocol is minimal and will probably be superseded by a more comprehensive component protocol at some point, informational documentation of the existing protocol would be helpful for component and server developers. This specification provides such documentation.</p>
</section1>
<section1 topic='Concepts' anchor='concepts'>
<p>Traditionally there have been two basic kinds of server-side components: "internal components" (which utilize the internal API of a server, in the past particularly the &jabberd; server) and "external components" (which communicate with a server over a wire protocol and therefore are not tied to any particular server implementation). The wire component protocol in use today enables an external component to connect to a server (with proper configuration and authentication) and to send and receive XML stanzas through the server. There are two connection methods: "accept" and "connect". When the "accept" method is used, the server waits for connections from components and accepts them when they are initiated by a component. When the "connect" method is used, the server initiates the connection to a component. The "accept" method is by far the most common method, but both are documented herein. (In the past, there has been one other connection method for external components: "execute". However, this method is obsolete and is not documented herein.)</p>
<p>An external component is called "trusted" because it authenticates with a server using authentication credentials that include a shared secret. This secret is commonly specified in the configuration files used by the server and component, but could be provided at runtime on the command line or extracted from a database. An external component is commonly trusted to do things that clients cannot, such as write 'from' addresses for the server's domain(s). Some server may also allow components to send packets that are used by the server's internal protocol (e.g., &lt;log/&gt; and &lt;xdb/&gt; packets in the jabberd 1.x series); however, those internal protocols are out of scope for this JEP.</p>
<p>An external component is called "trusted" because it authenticates with a server using authentication credentials that include a shared secret. This secret is commonly specified in the configuration files used by the server and component, but could be provided at runtime on the command line or extracted from a database. An external component is commonly trusted to do things that clients cannot, such as write 'from' addresses for the server's domain(s). Some server may also allow components to send packets that are used by the server's internal protocol (e.g., &lt;log/&gt; and &lt;xdb/&gt; packets in the jabberd 1.x series); however, those internal protocols are out of scope for this document.</p>
</section1>
<section1 topic='Protocol Flow' anchor='proto'>
<p>The main difference between the jabber:component:* namespaces and the 'jabber:client' or 'jabber:server' namespace is authentication. External components do not use the older &jep0078; protocol (i.e., the 'jabber:iq:auth' namespace), nor do they (yet) use SASL authentication as defined in &xmppcore; (although a future component protocol would most likely use SASL). Instead, they use a special &lt;handshake/&gt; element whose XML character data specifies credentials for the component's session with the server. The protocol flow for stream negotiation and authentication using jabber:component:accept is as follows:</p>
<p>The main difference between the jabber:component:* namespaces and the 'jabber:client' or 'jabber:server' namespace is authentication. External components do not use the older &xep0078; protocol (i.e., the 'jabber:iq:auth' namespace), nor do they (yet) use SASL authentication as defined in &xmppcore; (although a future component protocol would most likely use SASL). Instead, they use a special &lt;handshake/&gt; element whose XML character data specifies credentials for the component's session with the server. The protocol flow for stream negotiation and authentication using jabber:component:accept is as follows:</p>
<example caption='Component sends stream header to server'><![CDATA[
<stream:stream
xmlns='jabber:component:accept'
@ -117,9 +117,9 @@
<p>Given that an external component is trusted to write 'from' addresses for any user at the component's hostname, server administrators SHOULD make sure that they in fact do trust the component software.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with the &IANA;</p>
<p>This document requires no interaction with the &IANA;</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; includes 'jabber:component:accept' and 'jabber:component:connect' in its registry of protocol namespaces.</p>
</section1>
<section1 topic='XML Schemas' anchor='schema'>
@ -139,7 +139,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0114: http://www.jabber.org/jeps/jep-0114.html
XEP-0114: http://www.xmpp.org/extensions/xep-0114.html
</xs:documentation>
</xs:annotation>
@ -343,7 +343,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0114: http://www.jabber.org/jeps/jep-0114.html
XEP-0114: http://www.xmpp.org/extensions/xep-0114.html
</xs:documentation>
</xs:annotation>
@ -532,4 +532,4 @@
]]></code>
</section2>
</section1>
</jep>
</xep>

44
xep-0115.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>Entity Capabilities</title>
<abstract>This JEP defines a protocol for broadcasting and discovering client, device, or generic entity capabilities in a way that minimizes network impact.</abstract>
<abstract>This document defines an XMPP protocol extension for broadcasting and discovering client, device, or generic entity capabilities in a way that minimizes network impact.</abstract>
&LEGALNOTICE;
<number>0115</number>
<status>Draft</status>
@ -16,13 +16,13 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>caps</shortname>
<schemaloc>
<url>http://jabber.org/protocol/caps/caps.xsd</url>
<url>http://www.xmpp.org/schemas/caps.xsd</url>
</schemaloc>
&hildjj;
&stpeter;
@ -87,14 +87,14 @@
<p>It is often desirable for a Jabber/XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include:</p>
<ul>
<li>Showing a different set of icons depending on the capabilities of other clients.</li>
<li>Not sending &jep0071; content to plaintext clients such as cell phones.</li>
<li>Not sending &xep0071; content to plaintext clients such as cell phones.</li>
<li>Allowing the initiation of Voice over IP (VoIP) sessions only to clients that support VoIP.</li>
<li>Not showing a "Send a File" button if another user's client does not support &jep0096;.</li>
<li>Not showing a "Send a File" button if another user's client does not support &xep0096;.</li>
</ul>
<p>Recently, some existing Jabber clients have begun sending &jep0092; requests to each entity from which they receive presence. That solution is impractical on a larger scale, particularly for users or applications with large rosters. This JEP proposes a more robust and scalable solution: namely, a presence-based mechanism for exchanging information about entity capabilities. <note>This proposal is not limited to clients, and could be used by any entity that exchanges presence with another entity, e.g., a gateway. However, this JEP uses the example of clients throughout.</note></p>
<p>Recently, some existing Jabber clients have begun sending &xep0092; requests to each entity from which they receive presence. That solution is impractical on a larger scale, particularly for users or applications with large rosters. This document proposes a more robust and scalable solution: namely, a presence-based mechanism for exchanging information about entity capabilities. <note>This proposal is not limited to clients, and could be used by any entity that exchanges presence with another entity, e.g., a gateway. However, this document uses the example of clients throughout.</note></p>
</section1>
<section1 topic='Assumptions' anchor='assumptions'>
<p>This JEP makes several assumptions:</p>
<p>This document makes several assumptions:</p>
<ul>
<li>The type of client I am using is of interest to the people on my roster.</li>
<li>Clients for the people on my roster might want to make user interface decisions based on my capabilities.</li>
@ -111,11 +111,11 @@
<section1 topic='Requirements' anchor='reqs'>
<p>The protocol defined herein addresses the following requirements:</p>
<ol>
<li>Clients MUST be able to participate even if they support only &xmppcore;, &xmppim;, and &jep0030;.</li>
<li>Clients MUST be able to participate even if they are on networks without connectivity to other XMPP servers, services offering specialized XMPP extensions, or HTTP servers.<note>These first two requirements effectively eliminated &jep0060; as a possible implementation of entity capabilities.</note></li>
<li>Clients MUST be able to participate even if they support only &xmppcore;, &xmppim;, and &xep0030;.</li>
<li>Clients MUST be able to participate even if they are on networks without connectivity to other XMPP servers, services offering specialized XMPP extensions, or HTTP servers.<note>These first two requirements effectively eliminated &xep0060; as a possible implementation of entity capabilities.</note></li>
<li>Clients MUST be able to retrieve information without querying each user.</li>
<li>Since presence is normally broadcasted to many users, the byte size of the proposed extension MUST be as small as possible.</li>
<li>It MUST be possible to write a &jep0045; implementation that passes the given information along.</li>
<li>It MUST be possible to write a &xep0045; implementation that passes the given information along.</li>
<li>It MUST be possible to publish a change in capabilities within a single session.</li>
<li>Server infrastructure above and beyond that defined in <cite>XMPP Core</cite> and <cite>XMPP IM</cite> MUST NOT be required for this approach to work, although additional server infrastructure MAY be used for optimization purposes.</li>
</ol>
@ -147,7 +147,7 @@
</section2>
<section2 topic="Discovering Capabilities" anchor='discover'>
<p>Once someone on my roster knows what client I am using, they need to be able to figure out what features are supported by that client. The client that received the annotated presence sends a <strong>disco#info</strong> request (as defined in <strong>JEP-0030: Service Discovery</strong>) to <em>exactly</em> one of the users that sent a particular combination of <strong>node</strong> and <strong>ver</strong>. If the requestor has received the same annotation from multiple JIDs, the requestor SHOULD pick a random JID from that list to which the requestor will send the <strong>disco#info</strong> request.</p>
<p>Once someone on my roster knows what client I am using, they need to be able to figure out what features are supported by that client. The client that received the annotated presence sends a <strong>disco#info</strong> request (as defined in <strong>XEP-0030: Service Discovery</strong>) to <em>exactly</em> one of the users that sent a particular combination of <strong>node</strong> and <strong>ver</strong>. If the requestor has received the same annotation from multiple JIDs, the requestor SHOULD pick a random JID from that list to which the requestor will send the <strong>disco#info</strong> request.</p>
<p>The <strong>disco#info</strong> request is sent to a JID + node combination that consists of the chosen <strong>&lt;user@host/resource&gt;</strong> JID and a service discovery <strong>node</strong> that is constructed as follows: concatenate (1) the value of the caps <strong>'node'</strong> attribute, (2) the "#" character, and (3) the version number specified in the caps <strong>'ver'</strong> attribute.</p>
@ -239,19 +239,19 @@
</section1>
<section1 topic='Error Codes' anchor='error'>
<p>No application-specific error codes are defined by this document. See <strong>JEP-0030: Service Discovery</strong> for a list of potential service discovery error codes.</p>
<p>No application-specific error codes are defined by this document. See <strong>XEP-0030: Service Discovery</strong> for a list of potential service discovery error codes.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Use of the protocol specified in this JEP might make some client-specific forms of attack slightly easier, since the attacker could more easily determine the type of client being used. However, since most clients respond to <strong>jabber:iq:version</strong> requests without performing access control checks, there is no new vulnerability. Entities that wish to restrict access to capabilities information SHOULD use the privacy lists protocol defined in <strong>XMPP IM</strong> to define appropriate communications blocking (e.g., an entity MAY choose to allow IQ requests only from "trusted" entities, such as those with whom it has a subscription of "both").</p>
<p>Use of the protocol specified in this document might make some client-specific forms of attack slightly easier, since the attacker could more easily determine the type of client being used. However, since most clients respond to <strong>jabber:iq:version</strong> requests without performing access control checks, there is no new vulnerability. Entities that wish to restrict access to capabilities information SHOULD use the privacy lists protocol defined in <strong>XMPP IM</strong> to define appropriate communications blocking (e.g., an entity MAY choose to allow IQ requests only from "trusted" entities, such as those with whom it has a subscription of "both").</p>
<p>It is possible (though unlikely) for a bad actor or rogue application to poison other entities by providing incorrect information in response to disco#info requests. To guard against such poisoning, a requesting entity MAY send disco#info requests to multiple entities that match the same <strong>node</strong>/<strong>ver</strong> or <strong>node</strong>/<strong>ext</strong> combination and then compare the results to ensure consistency. The requesting entity SHOULD NOT send the same request to more than five entities and MUST ensure that the entities are truly different by not sending the same request to multiple entities for which the &lt;user@host&gt; portion matches.</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>Upon advancement of this JEP to a status of Draft, the &REGISTRAR; shall add <strong>'http://jabber.org/protocol/caps'</strong> to its registries of protocol namespaces and service discovery features.</p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/caps' in its registries of protocol namespaces and service discovery features.</p>
<p>If it is useful or interesting, the Registrar may also provide registration of the URIs to be used in the <strong>'node'</strong> attribute, but since these URIs can be scoped according to well-defined existing rules, this is not necessary.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
@ -267,7 +267,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0115: http://www.jabber.org/jeps/jep-0115.html
XEP-0115: http://www.xmpp.org/extensions/xep-0115.html
</xs:documentation>
</xs:annotation>
@ -292,4 +292,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

66
xep-0116.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,11 +40,11 @@
<!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>Encrypted Sessions</title>
<abstract>This JEP specifies a protocol for session-based, end-to-end encryption of XMPP communications.</abstract>
<abstract>This document specifies an XMPP protocol extension for session-based, end-to-end encryption.</abstract>
&LEGALNOTICE;
<number>0116</number>
<status>Experimental</status>
@ -57,11 +57,11 @@
<spec>RFC 3526</spec>
<spec>RFC 3548</spec>
<spec>xml-c14n</spec>
<spec>JEP-0004</spec>
<spec>JEP-0020</spec>
<spec>JEP-0030</spec>
<spec>JEP-0068</spec>
<spec>JEP-0155</spec>
<spec>XEP-0004</spec>
<spec>XEP-0020</spec>
<spec>XEP-0030</spec>
<spec>XEP-0068</spec>
<spec>XEP-0155</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
@ -73,13 +73,13 @@
<version>0.11</version>
<date>2006-10-02</date>
<initials>ip</initials>
<remark><p>Harmonised session termination with the protocol added to JEP-0155; added XML schema; minor clarifications</p></remark>
<remark><p>Harmonised session termination with the protocol added to XEP-0155; added XML schema; minor clarifications</p></remark>
</revision>
<revision>
<version>0.10</version>
<date>2006-07-18</date>
<initials>ip</initials>
<remark><p>Added Upgradability requirement; added expires field to offline options; updated in line with latest version of PEP; moved some content to new JEPs (0187, 0188 and 0189)</p></remark>
<remark><p>Added Upgradability requirement; added expires field to offline options; updated in line with latest version of PEP; moved some content to new XEPs (0187, 0188 and 0189)</p></remark>
</revision>
<revision>
<version>0.9</version>
@ -121,7 +121,7 @@
<version>0.3</version>
<date>2005-08-02</date>
<initials>ip/psa</initials>
<remark><p>Restored status to Experimental; complete rewrite; new Introduction, Background, Requirements and Security Considerations; new OTR-inspired protocol; JEP-0155-based negotiation; counter mode encryption; more secure hashes; offline sessions; re-keying; mac publishing; preliminary key and options publishing protocol.</p></remark>
<remark><p>Restored status to Experimental; complete rewrite; new Introduction, Background, Requirements and Security Considerations; new OTR-inspired protocol; XEP-0155-based negotiation; counter mode encryption; more secure hashes; offline sessions; re-keying; mac publishing; preliminary key and options publishing protocol.</p></remark>
</revision>
<revision>
<version>0.2</version>
@ -138,24 +138,24 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>End-to-end encryption is a desirable feature for any communication technology. Ideally, such a technology would design encryption in from the beginning and would forbid unencrypted communications. Realistically, most communication technologies have not been designed in that manner, and Jabber/XMPP technologies are no exception. In particular, the original Jabber technologies developed in 1999 did not include end-to-end encryption by default. PGP-based encryption of message bodies and signing of presence information was added as an extension to the core protocols in the year 2000; this extension is documented in &jep0027;. When the core protocols were formalized within the Internet Standards Process by the IETF's XMPP Working Group in 2003, a different extension was defined using S/MIME-based signing and encryption of CPIM-formatted messages (see &rfc3862;) and PIDF-formatted presence information (see &rfc3863;); this extension is specified in &rfc3923;.</p>
<p>For reasons described in &jep0188;, the foregoing proposals (and others not mentioned) have not been widely implemented and deployed. This is unfortunate, since an open communication protocol needs to enable end-to-end encryption in order to be seriously considered for deployment by a broad range of users.</p>
<p>End-to-end encryption is a desirable feature for any communication technology. Ideally, such a technology would design encryption in from the beginning and would forbid unencrypted communications. Realistically, most communication technologies have not been designed in that manner, and Jabber/XMPP technologies are no exception. In particular, the original Jabber technologies developed in 1999 did not include end-to-end encryption by default. PGP-based encryption of message bodies and signing of presence information was added as an extension to the core protocols in the year 2000; this extension is documented in &xep0027;. When the core protocols were formalized within the Internet Standards Process by the IETF's XMPP Working Group in 2003, a different extension was defined using S/MIME-based signing and encryption of CPIM-formatted messages (see &rfc3862;) and PIDF-formatted presence information (see &rfc3863;); this extension is specified in &rfc3923;.</p>
<p>For reasons described in &xep0188;, the foregoing proposals (and others not mentioned) have not been widely implemented and deployed. This is unfortunate, since an open communication protocol needs to enable end-to-end encryption in order to be seriously considered for deployment by a broad range of users.</p>
<p>This proposal describes a different approach to end-to-end encryption for use by entities that communicate using XMPP. The requirements and the consequent cryptographic design that underpin this protocol are described in <cite>Cryptographic Design of Encrypted Sessions</cite>. 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 each one-to-one XML stanza exchanged between the endpoints will be encrypted and then transmitted within a "wrapper" stanza.</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. 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 other participant in the ESession started by Alice. 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 initiator of the ESession. Within the scope of this document, we stipulate that her fully-qualified JID is: &lt;alice@example.org/pda&gt;.</li>
<li>"Bob" is the name of the other participant in the ESession started by Alice. Within the scope of this document, his fully-qualified JID is: &lt;bob@example.com/laptop&gt;.</li>
<li>"Aunt Tillie" the archetypal typical user (i.e. non-technical, with only very limited knowledge of how to use a computer, and averse to performing any procedures that are not familiar).</li>
</ol>
<p>While Alice and Bob are introduced as "end users", they are simply meant to be examples of Jabber entities. Any directly addressable Jabber entity may participate in an ESession.</p>
</section1>
<section1 topic='Discovering Support' anchor='disco'>
<p>Before attempting to engage in an ESession with Bob, Alice SHOULD discover whether he supports this protocol, using either &jep0030; or the presence-based profile of <cite>JEP-0030</cite> specified in &jep0115;.</p>
<p>The normal course of events is for Alice to authenticate with her server, retrieve her roster (see <cite>RFC 3921</cite>), send initial presence to her server, and then receive presence information from all the contacts in her roster. If the presence information she receives from some contacts does not include capabilities data (per <cite>JEP-0115</cite>), Alice SHOULD then send a service discovery information ("disco#info") request to each of those contacts (in accordance with <cite>JEP-0030</cite>). Such initial service discovery stanzas MUST NOT be considered part of encrypted communication sessions for the purposes of this JEP, since they perform a "bootstrapping" function that is a prerequisite to encrypted communications. The disco#info request sent from Alice to Bob might look as follows:</p>
<p>Before attempting to engage in an ESession with Bob, Alice SHOULD discover whether he supports this protocol, using either &xep0030; or the presence-based profile of <cite>XEP-0030</cite> specified in &xep0115;.</p>
<p>The normal course of events is for Alice to authenticate with her server, retrieve her roster (see <cite>RFC 3921</cite>), send initial presence to her server, and then receive presence information from all the contacts in her roster. If the presence information she receives from some contacts does not include capabilities data (per <cite>XEP-0115</cite>), Alice SHOULD then send a service discovery information ("disco#info") request to each of those contacts (in accordance with <cite>XEP-0030</cite>). Such initial service discovery stanzas MUST NOT be considered part of encrypted communication sessions for the purposes of this document, since they perform a "bootstrapping" function that is a prerequisite to encrypted communications. The disco#info request sent from Alice to Bob might look as follows:</p>
<example caption='Alice Queries Bob for ESession Support via Disco'><![CDATA[
<iq type='get'
from='alice@example.org/pda'
@ -182,7 +182,7 @@
<section1 topic="Online ESession Negotiation" anchor='init'>
<p>The process for establishing a secure session over an insecure transport is essentially a negotiation of various ESession algorithms and other parameters, combined with a translation into XMPP syntax of the &sigma; approach to key exchange (see <cite>Cryptographic Design of Encrypted Sessions</cite>).</p>
<p>If Alice believes Bob may be online then she SHOULD use the protocol specified in &jep0155; and in this section to negotiate the ESession options and the keys.</p>
<p>If Alice believes Bob may be online then she SHOULD use the protocol specified in &xep0155; and in this section to negotiate the ESession options and the keys.</p>
<p>Note: If Alice believes Bob is offline then she SHOULD NOT use this negotiation protocol. However, she MAY use the protocol specified in <cite>Offline Encrypted Sessions</cite> to establish the ESession options and keys. Alternatively, she MAY send stanzas without encryption - in which case her client MUST make absolutely clear to her that the stanzas will not be protected and give her the option not to send the stanzas.</p>
<p>Note: In any case, Alice MUST NOT initiate a new ESession with Bob if she already has one established with him.</p>
<section2 topic="ESession Request" anchor='init-online-request'>
@ -834,7 +834,7 @@
<ul>
<li>none (no compression, the output MUST be the same as the input)</li>
</ul>
<p>Support for other algorithms is NOT RECOMMENDED since compression partially defeats the <link url='#reqs-repudiate'>Repudiability</link> requirement of this JEP by making it more difficult for a third party (with some knowledge of the plaintext) to modify a transcript of an encrypted session in a meaningful way. However, encrypted content is pseudo-random and cannot be compressed, so, in those cases where bandwidth is severely constrained, an implementation of ESession MAY support the following algorithms to compress content before it is encrypted:</p>
<p>Support for other algorithms is NOT RECOMMENDED since compression partially defeats the <link url='#reqs-repudiate'>Repudiability</link> requirement of this document by making it more difficult for a third party (with some knowledge of the plaintext) to modify a transcript of an encrypted session in a meaningful way. However, encrypted content is pseudo-random and cannot be compressed, so, in those cases where bandwidth is severely constrained, an implementation of ESession MAY support the following algorithms to compress content before it is encrypted:</p>
<ul>
<li>lzw (see &ecma151;)</li>
<li>zlib (see &rfc1950;)</li>
@ -844,12 +844,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='Namespaces' anchor='registrar-ns'>
<p>Upon approval of this JEP, the &REGISTRAR; shall register the following namespaces:</p>
<p>Upon approval of this document, the &REGISTRAR; shall register the following namespaces:</p>
<ul>
<li>http://jabber.org/protocol/esession</li>
<li>http://jabber.org/protocol/esession#init</li>
@ -857,11 +857,11 @@
</ul>
</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. The following fields shall be registered for use in <em>both</em> Encrypted Sessions and Chat Session Negotiation:</p>
<p>&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields shall be registered for use in <em>both</em> Encrypted Sessions and Chat Session Negotiation:</p>
<code caption='Registry Submission'><![CDATA[
<form_type>
<name>http://jabber.org/protocol/esession</name>
<jep>JEP-0116</jep>
<jep>XEP-0116</jep>
<desc>ESession negotiation forms</desc>
<field
var='match_resource'
@ -898,7 +898,7 @@
<field
var='ver'
type='list-single'
label='Supported versions of JEP-0116'/>
label='Supported versions of XEP-0116'/>
<field
var='rekey_freq'
type='text-single'
@ -931,7 +931,7 @@
<form_type>
<name>http://jabber.org/protocol/chatneg</name>
<jep>JEP-0155</jep>
<jep>XEP-0155</jep>
...
</form_type>
]]></code>
@ -984,19 +984,19 @@
<li>Standardise on the X.509 public key and signature formats?</li>
<li>What challenges exist to make the OTR Gaim Plugin use this protocol natively when talking to Jabber entities? Can these be mitigated by 'non-critical' protocol changes?</li>
<li>Would anything in this protocol (e.g., its dependency on in-order stanza delivery) prevent an XMPP entity using it to exchange encrypted messages and presence with a user of a non-XMPP messaging system, assuming that the gateway both supports this protocol and is compatible with a purpose-built security plugin on the other user's client (e.g. a Gaim plugin connects to the gateway via a non-XMPP network)?</li>
<li>Could use &jep0013; (FOMR) instead of AMP to prevent any offline ESessions Bob can't decrypt being delivered to him. (Each &lt;item/&gt; that corresponds to an ESession message would have to contain a &lt;ESessionID/&gt; child, to allow Bob to discover which of his stored values of y was used to encrypt the message.)</li>
<li>Could use &xep0013; (FOMR) instead of AMP to prevent any offline ESessions Bob can't decrypt being delivered to him. (Each &lt;item/&gt; that corresponds to an ESession message would have to contain a &lt;ESessionID/&gt; child, to allow Bob to discover which of his stored values of y was used to encrypt the message.)</li>
</ol>
</section2>
<section2 topic='To Do' anchor='open-todo'>
<ol>
<li>Ask the authors of AMP to explain how to achieve the match_resource functionality specified in JEP-0187.</li>
<li>Ask the authors of AMP to explain how to achieve the match_resource functionality specified in XEP-0187.</li>
<li>Define names for X.509 SubjectPublicKeyInfo public key formats (different to X.509 certificates). This format must be used when keys are distributed within session negotiation.</li>
<li>Add non-repudiable signing option</li>
<li>Perhaps the JEP needs to specify more carefully how block counters are handled between messages, especially in the event of partial blocks?</li>
<li>Perhaps the document needs to specify more carefully how block counters are handled between messages, especially in the event of partial blocks?</li>
<li>Give examples of specific errors and discuss error scenarios throughout document (e.g., what should Bob do if he is not offline and he receives an offline key exchange stanza?).</li>
<li>Define an <em>optional</em> protocol that would allow Alice to store values of &NsubA; and x (and the PKIDs she trusts) 'securely' on her own server (before she goes offline).</li>
</ol>
</section2>
</section1>
</jep>
</xep>

68
xep-0117.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>Intermediate IM Protocol Suite</title>
<abstract>This JEP defines a recommended suite of Jabber/XMPP protocols to be supported by intermediate instant messaging and presence applications.</abstract>
<abstract>This document defines a recommended suite of Jabber/XMPP protocols to be supported by intermediate instant messaging and presence applications.</abstract>
&LEGALNOTICE;
<number>0117</number>
<status>Draft</status>
@ -16,11 +16,11 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0045</spec>
<spec>JEP-0071</spec>
<spec>JEP-0073</spec>
<spec>JEP-0096</spec>
<spec>JEP-0115</spec>
<spec>XEP-0045</spec>
<spec>XEP-0071</spec>
<spec>XEP-0073</spec>
<spec>XEP-0096</spec>
<spec>XEP-0115</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -42,13 +42,13 @@
<version>0.6</version>
<date>2005-06-02</date>
<initials>psa</initials>
<remark>Per Council discussion, modified the JEP-0045 profile to require all MUC use cases.</remark>
<remark>Per Council discussion, modified the XEP-0045 profile to require all MUC use cases.</remark>
</revision>
<revision>
<version>0.5</version>
<date>2005-04-21</date>
<initials>psa</initials>
<remark>Modified the JEP-0045 profile to require occupant use cases and instant room creation only.</remark>
<remark>Modified the XEP-0045 profile to require occupant use cases and instant room creation only.</remark>
</revision>
<revision>
<version>0.4</version>
@ -76,15 +76,15 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The &jep0073; introduced the concept of a "protocol suite". This document extends the basic support specified in <cite>JEP-0073</cite> by specifying an Intermediate IM Protocol Suite.</p>
<p>The &xep0073; introduced the concept of a "protocol suite". This document extends the basic support specified in <cite>XEP-0073</cite> by specifying an Intermediate IM Protocol Suite.</p>
</section1>
<section1 topic='Requirements and Approach' anchor='intro'>
<p>This document follows the same approach as <cite>JEP-0073</cite>. By design, the Basic IM Protocol Suite does not include more advanced instant messaging functionality; the present document fills the need for a protocol suite that addresses such functionality.</p>
<p>This document follows the same approach as <cite>XEP-0073</cite>. By design, the Basic IM Protocol Suite does not include more advanced instant messaging functionality; the present document fills the need for a protocol suite that addresses such functionality.</p>
<p>A protocol is deemed worthy of inclusion in this protocol suite if:</p>
<ul>
<li>It addresses common needs of instant messaging users that are addressed by virtually all other popular IM services or systems.</li>
<li>It is more advanced than basic IM and presence.</li>
<li>It has achieved a status of at least Draft within the Jabber Software Foundation's standards process (as defined in &jep0001;).</li>
<li>It has achieved a status of at least Draft within the Jabber Software Foundation's standards process (as defined in &xep0001;).</li>
</ul>
</section1>
<section1 topic='Definition' anchor='def'>
@ -95,45 +95,45 @@
<th>Requirement Level</th>
</tr>
<tr>
<td><strong>JEP-0073: Basic IM Protocol Suite</strong></td>
<td><strong>XEP-0073: Basic IM Protocol Suite</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td>&jep0045;</td>
<td>&xep0045;</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>&jep0071;</td>
<td>&xep0071;</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>&jep0096;</td>
<td>&xep0096;</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>&jep0115;</td>
<td>&xep0115;</td>
<td>REQUIRED</td>
</tr>
</table>
<p>Note well that the foregoing protocols apply to clients only (i.e., they do not introduce new requirements for servers). In addition, these protocols have their own dependencies, which include the following JEPs (as well as various IETF RFCs and W3C specifications):</p>
<p>Note well that the foregoing protocols apply to clients only (i.e., they do not introduce new requirements for servers). In addition, these protocols have their own dependencies, which include the following XEPs (as well as various IETF RFCs and W3C specifications):</p>
<ul>
<li>&jep0004;</li>
<li>&jep0020;</li>
<li>&jep0047;</li>
<li>&jep0065;</li>
<li>&jep0068;</li>
<li>&jep0082;</li>
<li>&jep0095;</li>
<li>&xep0004;</li>
<li>&xep0020;</li>
<li>&xep0047;</li>
<li>&xep0065;</li>
<li>&xep0068;</li>
<li>&xep0082;</li>
<li>&xep0095;</li>
</ul>
<p>In addition, because the intermediate suite builds on the basic suite, by definition all protocols required by <cite>JEP-0073</cite> are also required by the intermediate suite (refer to <cite>JEP-0073</cite> for details).</p>
<p>In addition, because the intermediate suite builds on the basic suite, by definition all protocols required by <cite>XEP-0073</cite> are also required by the intermediate suite (refer to <cite>XEP-0073</cite> for details).</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This JEP introduces no additional security considerations above and beyond those defined in the documents on which it depends.</p>
<p>This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.</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>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this JEP.</p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this document.</p>
</section1>
</jep>
</xep>

34
xep-0118.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>User Tune</title>
<abstract>This JEP defines a protocol for communicating information about the music to which a user is listening.</abstract>
<abstract>This document defines an XMPP protocol extension for communicating information about the music to which a user is listening.</abstract>
&LEGALNOTICE;
<number>0118</number>
<status>Draft</status>
@ -16,13 +16,13 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0060</spec>
<spec>XEP-0060</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>tune</shortname>
<schemaloc>
<url>http://jabber.org/protocol/tune/tune.xsd</url>
<url>http://www.xmpp.org/schemas/tune.xsd</url>
</schemaloc>
&stpeter;
<revision>
@ -59,7 +59,7 @@
<version>0.6</version>
<date>2004-04-25</date>
<initials>psa</initials>
<remark>Corrected several errors; added reference to JEP-0033.</remark>
<remark>Corrected several errors; added reference to XEP-0033.</remark>
</revision>
<revision>
<version>0.5</version>
@ -93,7 +93,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>This JEP defines a protocol for communicating information about the music to which a user is listening. Such information may be seen as a kind of "extended presence", and users may want to communicate such information to their contacts on the network as a fun add-on to traditional IM applications or to provide integration with common music-player applications.</p>
<p>This document defines a protocol for communicating information about the music to which a user is listening. Such information may be seen as a kind of "extended presence", and users may want to communicate such information to their contacts on the network as a fun add-on to traditional IM applications or to provide integration with common music-player applications.</p>
</section1>
<section1 topic='Protocol' anchor='protocol'>
<section2 topic='Container Element and Child Elements' anchor='protocol-elements'>
@ -139,7 +139,7 @@
<p>NOTE: The datatypes specified above are defined in &w3xmlschema2;.</p>
</section2>
<section2 topic='Transport Mechanism' anchor='protocol-transport'>
<p>Tune information SHOULD be communicated and transported by means of the &jep0060; protocol. Because tune information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.</p>
<p>Tune information SHOULD be communicated and transported by means of the &xep0060; protocol. Because tune information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.</p>
<example caption='User Publishes Tune Information'><![CDATA[
<iq type='set'
from='stpeter@jabber.org/work'
@ -183,7 +183,7 @@
.
.
]]></example>
<p>As mentioned in JEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &jep0033; protocol) to provide an explicit association between the published data and the user:</p>
<p>As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:</p>
<example caption="Event notification with extended stanza addressing"><![CDATA[
<message
from='pubsub.jabber.org'
@ -206,7 +206,7 @@
</addresses>
</message>
]]></example>
<p>Naturally, further extensions could be included, e.g., using &jep0066; to specify a URL where one could buy the recording.</p>
<p>Naturally, further extensions could be included, e.g., using &xep0066; to specify a URL where one could buy the recording.</p>
<example caption="Tune info with URL"><![CDATA[
<message
from='pubsub.jabber.org'
@ -269,12 +269,12 @@
<p>If the length is unknown (e.g., the user is listening to a stream), the &lt;length/&gt; element SHOULD NOT be included.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This protocol introduces no security considerations above and beyond those defined in <cite>Publish-Subscribe</cite> (JEP-0060).</p>
<p>This protocol introduces no security considerations above and beyond those defined in <cite>Publish-Subscribe</cite> (XEP-0060).</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; includes 'http://jabber.org/protocol/tune' in its registry of protocol namespaces.</p>
</section2>
@ -292,7 +292,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0118: http://www.jabber.org/jeps/jep-0118.html
XEP-0118: http://www.xmpp.org/extensions/xep-0118.html
</xs:documentation>
</xs:annotation>
@ -311,4 +311,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

64
xep-0119.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>Extended Presence Protocol Suite</title>
<abstract>This document specifies a set of XMPP extensions that provide support for extended presence information. Note: This document has been retracted since its functionality is handled by JEP-0163.</abstract>
<abstract>This document specifies a set of XMPP extensions that provide support for extended presence information. Note: This document has been retracted since its functionality is handled by XEP-0163.</abstract>
&LEGALNOTICE;
<number>0119</number>
<status>Retracted</status>
@ -16,18 +16,18 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0060</spec>
<spec>JEP-0073</spec>
<spec>JEP-0080</spec>
<spec>JEP-0084</spec>
<spec>JEP-0107</spec>
<spec>JEP-0108</spec>
<spec>JEP-0112</spec>
<spec>JEP-0163</spec>
<spec>XEP-0060</spec>
<spec>XEP-0073</spec>
<spec>XEP-0080</spec>
<spec>XEP-0084</spec>
<spec>XEP-0107</spec>
<spec>XEP-0108</spec>
<spec>XEP-0112</spec>
<spec>XEP-0163</spec>
</dependencies>
<supersedes/>
<supersededby>
<spec>JEP-0163</spec>
<spec>XEP-0163</spec>
</supersededby>
<shortname>N/A</shortname>
&stpeter;
@ -35,13 +35,13 @@
<version>0.8</version>
<date>2006-08-08</date>
<initials>psa</initials>
<remark><p>Retracted: superseded by Personal Eventing via Pubsub (JEP-0163).</p></remark>
<remark><p>Retracted: superseded by Personal Eventing via Pubsub (XEP-0163).</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2006-01-19</date>
<initials>psa</initials>
<remark><p>Updated to reflect Personal Eventing via Pubsub (JEP-0163).</p></remark>
<remark><p>Updated to reflect Personal Eventing via Pubsub (XEP-0163).</p></remark>
</revision>
<revision>
<version>0.6</version>
@ -81,14 +81,14 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p><em>Note: This document has been retracted since its functionality is handled by &jep0163;.</em></p>
<p><em>Note: This document has been retracted since its functionality is handled by &xep0163;.</em></p>
<p>A number of network services enable the exchange of information about an entity's availability for communications over the network. This information is usually called "presence". Examples include a person's availability to talk over a traditional or mobile telephony network, chat over an instant messaging (IM) network, or participate in a video conference. In this core sense, presence is a boolean, "on/off" indicator of network availability.</p>
<p>Over time, this core notion of presence has been extended to include other information about the entity that either (1) changes quickly or (2) affects the entity's interest in or ability to engage in communications. Examples of such "extended presence" include a person's proximity to or interaction with a user agent (e.g., "away" or "do not disturb"), activity (e.g., "driving"), ambient environment (e.g., "noisy"), and mood (e.g., "grumpy"). Related information includes data about the person's available devices (e.g., "phone" or "IM"), current contact modes or address, and date/time ranges for availability. Because extended presence information can change quite often (e.g., several times in the course of a typical IM session), it is distinct from more stable information about the individual (such as is captured in a vCard or other user profile).</p>
<p>This document describes a unified approach to the provision and communication of extended presence information using the Extensible Messaging and Presence Protocol (XMPP), in the form of a "protocol suite" that incorporates by reference a number of existing XMPP extensions.</p>
</section1>
<section1 topic='Background' anchor='background'>
<p>XMPP began life as a dedicated instant messaging and presence protocol within the Jabber community. The needs of this community were not advanced (simple IM and presence), and the presence model designed by that community mainly takes account of basic presence only (i.e., on/off availability on an IM network). Within this model (and using the terminology of &rfc2778;), the only watchers are those in the principal's contact list (in XMPP called a "roster"). In addition, authorization to receive basic presence broadcasts is handled by the principal through a combination of roster management and basic presence subscriptions as defined in &xmppim;. The presence service is tied to the principal's session with a server, and the server's internal session manager handles both presence and instant messaging functionality (although IM and presence can be separated in system configuration or "on the fly" via negative presence priorities).</p>
<p>This basic presence model was not designed for the more advanced world of extended presence. While some existing IM clients publish extended presence information as XML extensions to the XMPP &PRESENCE; stanza, that model does not scale well, does not respect the bandwidth restrictions of many clients on the network, and does not provide for more granular control over information access (anyone who receives presence will also receive geolocation data and the like). However, there is a more advanced protocol that is specially designed to fully implement the publish-subscribe design pattern on top of XMPP, specified in <strong>JEP-0060:</strong> &jep0060;. The publish-subscribe protocol can be used to create a service that provides full control over each type of extended presence data, sending that data only to those specifically authorized to receive it and those who have an active interest in each extension. In particular, for extended presence related to IM users, we specify the use of the personal eventing subset of <cite>JEP-0060</cite>, as defined in <cite>JEP-0163</cite>.</p>
<p>This basic presence model was not designed for the more advanced world of extended presence. While some existing IM clients publish extended presence information as XML extensions to the XMPP &PRESENCE; stanza, that model does not scale well, does not respect the bandwidth restrictions of many clients on the network, and does not provide for more granular control over information access (anyone who receives presence will also receive geolocation data and the like). However, there is a more advanced protocol that is specially designed to fully implement the publish-subscribe design pattern on top of XMPP, specified in <strong>XEP-0060:</strong> &xep0060;. The publish-subscribe protocol can be used to create a service that provides full control over each type of extended presence data, sending that data only to those specifically authorized to receive it and those who have an active interest in each extension. In particular, for extended presence related to IM users, we specify the use of the personal eventing subset of <cite>XEP-0060</cite>, as defined in <cite>XEP-0163</cite>.</p>
<p>The provision and communication of extended presence information follows the classic publish-subscribe design pattern: an individual publishes information such as geographical location data, and the data is broadcasted to all subscribers who are authorized to receive that data. (Alternatively, the data can be published on behalf of the individual, such as by a mobile telephony service that has knowledge of the individual's geographical location and authorization to act as a publisher of that data.) In general, the relationship between the publisher and subscriber is mediated by a service that receives publication requests, broadcasts data to subscribers, and enables the individual to manage lists of entities that are authorized to publish or subscribe to the data. This model makes it possible to deploy highly flexible extended presence services within the context of XMPP.</p>
<p>The following diagram provides a schematic representation of such a service.</p>
<code>
@ -113,11 +113,11 @@ Service | Manager
<p>In this example, there are six different extended presence nodes (these might be, for example, geographical location, avatar, activity, mood, network availability, etc.). The principal is authorized to publish to all six, a Mobile Telephony Service is also authorized to publish to Node 1 (e.g., geolocation), and an XMPP Session Manager is also authorized to publish to Node 6 (e.g., network availability). There are five subscribers: Subscriber 1 is authorized to receive data from Node 1 and Node 2, Subscriber 2 is authorized to Node 2 and Node 3, Subscriber 3 is authorized to receive data from Node 4 and Node 6, and Subscribers 4 and 5 are authorized to receive data from Node 6 only.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This document follows the same approach as &jep0073;. By design, the Basic IM Protocol Suite does not include more advanced functionality related to "extended presence"; the present document fills the need for a protocol suite that addresses such functionality.</p>
<p>This document follows the same approach as &xep0073;. By design, the Basic IM Protocol Suite does not include more advanced functionality related to "extended presence"; the present document fills the need for a protocol suite that addresses such functionality.</p>
<p>A protocol is deemed worthy of inclusion in this protocol suite if:</p>
<ul>
<li>It addresses "extended presence" data that is defined in other presence services or protocols (e.g., Wireless Village or SIMPLE), or that is felt to be needed within the Jabber/XMPP community.</li>
<li>It has achieved a status of at least Draft within the Jabber Software Foundation's standards process (as defined in &jep0001;).</li>
<li>It has achieved a status of at least Draft within the Jabber Software Foundation's standards process (as defined in &xep0001;).</li>
</ul>
</section1>
<section1 topic='Extended Presence Protocol Suite' anchor='suite'>
@ -128,35 +128,35 @@ Service | Manager
<th>Requirement Level</th>
</tr>
<tr>
<td><strong>JEP-0073: Basic IM Protocol Suite</strong></td>
<td><strong>XEP-0073: Basic IM Protocol Suite</strong></td>
<td>REQUIRED (prerequisite)</td>
</tr>
<tr>
<td><strong>JEP-0163: Personal Eventing via Pubsub</strong></td>
<td><strong>XEP-0163: Personal Eventing via Pubsub</strong></td>
<td>REQUIRED (prerequisite)</td>
</tr>
<tr>
<td>&jep0080;</td>
<td>&xep0080;</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>&jep0112;</td>
<td>&xep0112;</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>&jep0108;</td>
<td>&xep0108;</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>&jep0107;</td>
<td>&xep0107;</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>&jep0084;</td>
<td>&xep0084;</td>
<td>REQUIRED *</td>
</tr>
</table>
<p><em>* Note: The User Avatar specification (<cite>JEP-0084</cite>) has not yet advanced to a status of Draft within the JSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.</em></p>
<p><em>* Note: The User Avatar specification (<cite>XEP-0084</cite>) has not yet advanced to a status of Draft within the JSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.</em></p>
</section1>
<section1 topic='Node Discovery' anchor='discovery'>
<p>Discovery of extended presence pubsub nodes is expedited through the use of <cite>Personal Eventing via Pubsub</cite> (PEP), since in PEP services there is a one-to-one relationship between payload types and NodeIDs. The NodeIDs MUST be as follows:</p>
@ -173,9 +173,9 @@ Service | Manager
<p>This document introduces no new security considerations above and beyond those defined in the documents on which it depends. Because publicly exposing some forms of extended presence information (e.g., geolocation information) may lead to unnecessary risks, care should be taken in setting the access model for the relevant pubsub nodes (minimally, an access model of "presence" to take advantage of the bidirectional authorization scheme inherent in XMPP presence subscriptions).</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>