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@47 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-04 17:23:05 +00:00
parent 394cb91516
commit de16d33554
10 changed files with 188 additions and 188 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
xep-0150.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>Use of Entity Tags in XMPP Extensions</title>
<abstract>This document defines best practices for the use of Entity Tags in XMPP extensions.</abstract>
@ -17,7 +17,7 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>RFC 2616</spec>
<spec>JEP-0131</spec>
<spec>XEP-0131</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -34,7 +34,7 @@
<version>0.1</version>
<date>2005-06-02</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -45,10 +45,10 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>When a Jabber instant messaging client connects to its server, it typically retrieves a great deal of information, such as a user's roster, privacy lists, and service discovery information. However, this information may not have changed since the client last retrieved the data. In order to improve client start-up time or conserve bandwidth in certain environments, it would be desirable if the client could cache the information and retrieve it only if it has changed.</p>
<p>Such a mechanism exists as part of &rfc2616; in the form of the Entity Tags, which are included in the ETag and If-None-Match headers used for HTTP caching. Since &jep0131; enables an XMPP entity to communicate any HTTP header, it should be possible to re-use existing Entity Tag semantics for caching information sent over an XMPP network. This JEP defines best practices for such functionality, which could be used between any two XMPP entities that support SHIM headers (though it is envisioned to be most useful for clients that retrieve information from servers and services).</p>
<p>Such a mechanism exists as part of &rfc2616; in the form of the Entity Tags, which are included in the ETag and If-None-Match headers used for HTTP caching. Since &xep0131; enables an XMPP entity to communicate any HTTP header, it should be possible to re-use existing Entity Tag semantics for caching information sent over an XMPP network. This document defines best practices for such functionality, which could be used between any two XMPP entities that support SHIM headers (though it is envisioned to be most useful for clients that retrieve information from servers and services).</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 caching of information sent over an XMPP network (i.e., retrieval of information only if it has changed since it was last retrieved).</li>
<li>Re-use existing HTTP Entity Tag semantics.</li>
@ -56,7 +56,7 @@
</section1>
<section1 topic='Concepts and Approach' anchor='approach'>
<p>In HTTP, an "entity" is the information transferred as the payload of a request or response, and an "Entity Tag" is an opaque string that uniquely identifies that payload. For example, when an HTTP server sends an entity in an HTTP response, it can include an ETag header that identifies the payload as cacheable, and the client can cache that entity; in future requests, the client can include the same value in an If-None-Match header and the server will either return an HTTP 304 ("Not Modified") error if the entity has not changed or return the entity in the HTTP response if it has changed. (Note: For information about the semantics of Entity Tags, the ETag header, and the If-None-Match header, refer to Sections 3.11, 14.19, and 14.26 respectively of <cite>RFC 2616</cite>.)</p>
<p>Similarly, the basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP; this is made possible by a straightforward application of SHIM headers as specified in <cite>JEP-0131</cite>. In the context of an IQ request-response interaction, the responding entity will include an ETag SHIM header in its IQ response (indicating that the data can be cached), the requesting entity will include that identical value in an If-None-Match SHIM header when it queries the server for the same entity, and the responding entity will return either an IQ result with the changed entity or an IQ error indicating that the entity has not changed.</p>
<p>Similarly, the basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP; this is made possible by a straightforward application of SHIM headers as specified in <cite>XEP-0131</cite>. In the context of an IQ request-response interaction, the responding entity will include an ETag SHIM header in its IQ response (indicating that the data can be cached), the requesting entity will include that identical value in an If-None-Match SHIM header when it queries the server for the same entity, and the responding entity will return either an IQ result with the changed entity or an IQ error indicating that the entity has not changed.</p>
<p>Here is an example of such a request-response flow (the example is that of roster retrieval):</p>
<example caption='Client Requests Roster'><![CDATA[
<iq type='get'
@ -109,13 +109,13 @@
</error>
</iq>
]]></example>
<p>Note: The &lt;not-modified/&gt; error is not specified as a stanza error in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &jep0086;). The authors of this proposal will request that the &lt;not-modified/&gt; error condition be added to the successor to <cite>RFC 3920</cite> during the process of revising the XMPP specifications within the Internet Standards Process.</p>
<p>Note: The &lt;not-modified/&gt; error is not specified as a stanza error in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &xep0086;). The authors of this proposal will request that the &lt;not-modified/&gt; error condition be added to the successor to <cite>RFC 3920</cite> during the process of revising the XMPP specifications within the Internet Standards Process.</p>
<p>Note: In HTTP, an Entity Tag may be either "strong" or "weak" (see Section 13.3.3 of <cite>RFC 2616</cite>); Entity Tags as used in XMPP extensions MUST be considered strong rather than weak.</p>
<p>Note: The ETag and If-None-Match headers SHOULD be used only in &IQ; stanzas, although they MAY be used in &MESSAGE; stanza interactions if IQ request-response semantics are not appropriate, for example in &jep0072; and in certain applications that use &jep0004;.</p>
<p>Note: The ETag and If-None-Match headers SHOULD be used only in &IQ; stanzas, although they MAY be used in &MESSAGE; stanza interactions if IQ request-response semantics are not appropriate, for example in &xep0072; and in certain applications that use &xep0004;.</p>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Discovering Support' anchor='support'>
<p><cite>JEP-0131</cite> specifies how support for a particular SHIM header can be determined using &jep0030;. To review, the protocol flow between a client and a server would be as follows:</p>
<p><cite>XEP-0131</cite> specifies how support for a particular SHIM header can be determined using &xep0030;. To review, the protocol flow between a client and a server would be as follows:</p>
<example caption='Client Queries Server Regarding SHIM Header Support'><![CDATA[
<iq from='juliet@capulet.com/balcony'
to='capulet.com'
@ -139,7 +139,7 @@
]]></example>
<p>The client now knows that the server supports the ETag and If-None-Match SHIM headers and can proceed accordingly.</p>
<p>Note: If an XMPP entity supports Entity Tags, it MUST at a minimum support both the ETag and If-None-Match SHIM headers.</p>
<p>Note: Even if an entity supports the ETag and If-None-Match SHIM headers, it is not required to support Entity Tag functionality for all namespaces. For example, a server could support Entity Tags only for rosters and privacy lists but not for the 'jabber:iq:last' or 'jabber:iq:version' namespaces. Similarly, a &jep0045; service could support Entity Tags only for room lists (retrieved via a "disco#items" request) but not for other requests. As noted, if an entity does not support Entity Tags for a given namespace or request, it SHOULD proceed as if the ETag or If-None-Match SHIM header had not been included in the request.</p>
<p>Note: Even if an entity supports the ETag and If-None-Match SHIM headers, it is not required to support Entity Tag functionality for all namespaces. For example, a server could support Entity Tags only for rosters and privacy lists but not for the 'jabber:iq:last' or 'jabber:iq:version' namespaces. Similarly, a &xep0045; service could support Entity Tags only for room lists (retrieved via a "disco#items" request) but not for other requests. As noted, if an entity does not support Entity Tags for a given namespace or request, it SHOULD proceed as if the ETag or If-None-Match SHIM header had not been included in the request.</p>
<p>Optionally, an entity MAY communicate the namespaces for which it supports Entity Tag functionality by listing those namespaces in its response to a "disco#info" request sent to a node of "http://jabber.org/protocol/shim#ETag":</p>
<example caption='Client Queries Server Regarding Supported Entity Tag Namespaces'><![CDATA[
<iq from='juliet@capulet.com/balcony'
@ -341,13 +341,13 @@
<section1 topic='IANA Considerations' anchor='iana'>
<p>This proposal requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This proposal requires no interaction with the &REGISTRAR;.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>This JEP describes best practices for use of JEP-0131 and therefore does not require a dedicated schema.</p>
<p>This document describes best practices for use of XEP-0131 and therefore does not require a dedicated schema.</p>
</section1>
<section1 topic='Open Issues' anchor='issues'>
<p>Is the ETag tied to a bare JID or full JID?</p>
</section1>
</jep>
</xep>

24
xep-0151.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>Virtual Presence</title>
<abstract>This JEP proposes extensions to the Jabber groupchat protocol for virtual presence on Web pages.</abstract>
<abstract>This document proposes extensions to the Jabber groupchat protocol for virtual presence on Web pages.</abstract>
&LEGALNOTICE;
<number>0151</number>
<status>Experimental</status>
@ -15,7 +15,7 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0045</spec>
<spec>XEP-0045</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
@ -38,7 +38,7 @@
<version>0.1</version>
<date>2005-06-02</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.8</version>
@ -124,7 +124,7 @@
<p>The traffic goals can be met by using only the initial &PRESENCE; stanza, which carries all required information, so that no peer-to-peer messages are required on entering. VP clients which gather additional information about peers (e.g. avatar images) should cache the data so that it can be re-used. This is especially important since users browsing virtually connected locations (i.e. linked pages) may meet very often in a short time.</p>
<p>The virtual presence extensions make use of Jabber group chat. Virtual locations are implemented as public Jabber chat channels. The proposed protocol works with &jep0045; rooms and GroupChat 1.0 compatible services. Its core functionality described here uses only groupchat features.</p>
<p>The virtual presence extensions make use of Jabber group chat. Virtual locations are implemented as public Jabber chat channels. The proposed protocol works with &xep0045; rooms and GroupChat 1.0 compatible services. Its core functionality described here uses only groupchat features.</p>
<p>The virtual presence extensions are supposed to be implemented by Jabber IM clients in addition to the IM functions or by pure virtual presence (Jabber VP) clients.</p>
@ -201,7 +201,7 @@
<presence from='room1@shakespeare.com/WebGirl' to='romeo@montague.net/garden' />]]>
</example>
<p>Juliet gets the equivalent. Romeo&apos;s VP client shows Juliet&apos;s presence by adding a second avatar to the page. They now engage in a vivid conversation. In deviation to the original text Juliet would not ask &quot;Who art thou, Romeo?&quot;, because she only knows the nickname and on the other hand she actually knows where Romeo is: he is on the same web page. There is nothing new until now. Everything happened according to GroupChat 1.0 (JEP-0045) without MUC features. Of course, users can join the same room with any client that supports GroupChat, if they know the room&apos;s JID.</p>
<p>Juliet gets the equivalent. Romeo&apos;s VP client shows Juliet&apos;s presence by adding a second avatar to the page. They now engage in a vivid conversation. In deviation to the original text Juliet would not ask &quot;Who art thou, Romeo?&quot;, because she only knows the nickname and on the other hand she actually knows where Romeo is: he is on the same web page. There is nothing new until now. Everything happened according to GroupChat 1.0 (XEP-0045) without MUC features. Of course, users can join the same room with any client that supports GroupChat, if they know the room&apos;s JID.</p>
<p>Extensions come into the play in order to make the virtual presence more attractive and more vivid.</p>
</section2>
@ -790,8 +790,8 @@ http://www.shakespeare.com/_vpi.xml]]>
<p>The fact that clients may disclose their JID in order to provide access to their avatar server storage and in order to enable caching is a weak point. A different but equally unique ID could be for caching purposes, provided that it is part of the &PRESENCE; stanza. But traffic restrictions on the client connection prevent that additional data is exchanged between peers in a room. The data could be broadcast to the room, but this could end up in many people always broadcasting avatars while entering a room (web page). The chosen solution is to let peers download from public server storage. A better solution might be to let the conference component fetch from the server storage. In this case clients would need only the room-JID of the user, not the real JID.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<p>These namespaces need to be reviewed and/or registered with the Jabber Registrar as a result of this JEP.
<section1 topic='XMPP Registrar Considerations'>
<p>These namespaces need to be reviewed and/or registered with the XMPP Registrar as a result of this document.
<ul>
<li>firebat:user:jid</li>
<li>firebat:avatar:position</li>
@ -825,4 +825,4 @@ http://www.shakespeare.com/_vpi.xml]]>
There are definitely more features possible. Suggestions are welcome</p>
</section1>
</jep>
</xep>

34
xep-0152.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>Reachability Addresses</title>
<abstract>This document defines an XMPP protocol extension for communicating reachability information related to non-XMPP devices.</abstract>
@ -33,7 +33,7 @@
<version>0.1</version>
<date>2005-06-16</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -45,14 +45,14 @@
<section1 topic='Introduction' anchor='intro'>
<p>Sometimes it is desirable or necessary to switch from instant messaging (IM) to another real-time communications medium, such as a telephone conversation conducted over the traditional public switched telephone network (PSTN) or more recent Voice over Internet Protocol (VoIP) applications. In order to facilitate switching from IM to telephony or some other medium, a user needs to advertise the address(es) at which they can be reached. There are several possible ways to do this:</p>
<ul>
<li><p>Publish the reachability address(es) in the user's vCard (see &jep0054;); this is convenient, but is not very dynamic (e.g., reachability addresses might change when the user moves to a new conference room in an office building).</p></li>
<li><p>Publish the user's reachability status (but not addresses) as a feature bundle within &jep0115; information; this is somewhat dynamic (subscribers can be informed when reachability information is available) but requires every interested subscriber to perform service discovery in order to determine the reachability address(es).</p></li>
<li><p>Send the reachability address(es) within a &PRESENCE; stanza; this option is described in the <link url='#transport-presence'>Presence Broadcast</link> section of this JEP and is consistent with Section 5.1.2 of &rfc3921; since reachability is one aspect of a user's availability for communication.</p></li>
<li><p>Send reachability address(es) to the appropriate &jep0163; node; this option is described in the <link url='#transport-pep'>PEP Transport</link> section of this JEP but may not be available at all service providers.</p></li>
<li><p>Publish the reachability address(es) in the user's vCard (see &xep0054;); this is convenient, but is not very dynamic (e.g., reachability addresses might change when the user moves to a new conference room in an office building).</p></li>
<li><p>Publish the user's reachability status (but not addresses) as a feature bundle within &xep0115; information; this is somewhat dynamic (subscribers can be informed when reachability information is available) but requires every interested subscriber to perform service discovery in order to determine the reachability address(es).</p></li>
<li><p>Send the reachability address(es) within a &PRESENCE; stanza; this option is described in the <link url='#transport-presence'>Presence Broadcast</link> section of this document and is consistent with Section 5.1.2 of &rfc3921; since reachability is one aspect of a user's availability for communication.</p></li>
<li><p>Send reachability address(es) to the appropriate &xep0163; node; this option is described in the <link url='#transport-pep'>PEP Transport</link> section of this document but may not be available at all service providers.</p></li>
</ul>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This JEP addresses the following requirements:</p>
<p>This document addresses the following requirements:</p>
<ul>
<li>Enable clients to dynamically publish reachability addresses.</li>
<li>Minimize network traffic.</li>
@ -80,12 +80,12 @@
]]></example>
</section1>
<section1 topic='Data Transport' anchor='transport'>
<p>As described below, this JEP specifies two methods of advertising reachability addresses:</p>
<p>As described below, this document specifies two methods of advertising reachability addresses:</p>
<ul>
<li>Presence broadcast</li>
<li>Personal eventing via publish-subscribe (PEP)</li>
</ul>
<p>This JEP does not recommend one transport method over the other.</p>
<p>This document does not recommend one transport method over the other.</p>
<p>In addition, a contact MAY request a user's reachability addresses using an &IQ; request-response sequence.</p>
<section2 topic='Presence Broadcast' anchor='transport-presence'>
<p>In order to broadcast reachability addresses in presence information, a user's client includes the &lt;reach/&gt; element in the &PRESENCE; stanza it sends to its server:</p>
@ -111,7 +111,7 @@
]]></example>
</section2>
<section2 topic='Personal Eventing' anchor='transport-pep'>
<p>In order to publish reachability via the publish-subscribe transport, an entity MUST first create the appropriate node as explained in <cite>JEP-0060</cite>. Here we assume that the node already exists.</p>
<p>In order to publish reachability via the publish-subscribe transport, an entity MUST first create the appropriate node as explained in <cite>XEP-0060</cite>. Here we assume that the node already exists.</p>
<example caption='Entity publishes reachability addresses'><![CDATA[
<iq type='set'
from='romeo@montague.net'
@ -154,7 +154,7 @@
]]></example>
</section2>
<section2 topic='IQ Request' anchor='transport-iq'>
<p>If a client supports the reachability addresses protocol described herein, it SHOULD include a &jep0030; feature of 'http://jabber.org/protocol/reach' in its replies to disco#info requests:</p>
<p>If a client supports the reachability addresses protocol described herein, it SHOULD include a &xep0030; feature of 'http://jabber.org/protocol/reach' in its replies to disco#info requests:</p>
<example caption="Service Discovery Interaction"><![CDATA[
<iq from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard' id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@ -195,12 +195,12 @@
<p>If included, the &lt;desc/&gt; element SHOULD possess an 'xml:lang' attribute specifying the language of the human-readable descriptive text for a particular address.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This document introduces no security considerations above and beyond those described in RFC 3920, RFC 3921, and (for the personal eventing transport) JEP-0163.</p>
<p>This document introduces no security considerations above and beyond those described in RFC 3920, RFC 3921, and (for the personal eventing transport) XEP-0163.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/reach' in its registry of protocol namespaces.</p>
</section2>
@ -237,4 +237,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

28
xep-0153.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-Based Avatars</title>
<abstract>This document provides historical documentation of a vCard-based protocol for exchanging user avatars.</abstract>
@ -17,13 +17,13 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0054</spec>
<spec>XEP-0054</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>vcard-avatar</shortname>
<schemaloc>
<url>http://jabber.org/protocol/vcard-avatar/vcard-avatar.xsd</url>
<url>http://www.xmpp.org/schemas/vcard-avatar.xsd</url>
</schemaloc>
&stpeter;
<revision>
@ -70,7 +70,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>There exist several proposed protocols for communicating user avatar information over Jabber/XMPP (see &jep0008; and &jep0084;). This document describes another such protocol that is in use today on the Jabber/XMPP network. This document is historical and does not purport to propose a standards-track protocol. However, a future protocol may improve on the approach documented herein.</p>
<p>There exist several proposed protocols for communicating user avatar information over Jabber/XMPP (see &xep0008; and &xep0084;). This document describes another such protocol that is in use today on the Jabber/XMPP network. This document is historical and does not purport to propose a standards-track protocol. However, a future protocol may improve on the approach documented herein.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The protocol described herein seems to have been designed with the following requirements in mind:</p>
@ -83,7 +83,7 @@
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='User Publishes Avatar' anchor='publish'>
<p>Before informing contacts of the user's avatar, the user's client first publishes the avatar data to the user's public vCard using the protocol defined in &jep0054;.</p>
<p>Before informing contacts of the user's avatar, the user's client first publishes the avatar data to the user's public vCard using the protocol defined in &xep0054;.</p>
<example caption="User&apos;s Client Publishes Avatar Data to vCard"><![CDATA[
<iq from='juliet@capulet.com'
type='set'
@ -121,7 +121,7 @@
<p>The user's server then broadcasts that presence information to all contacts who are subscribed to the user's presence information.</p>
</section2>
<section2 topic='Contact Retrieves Avatar' anchor='retrieve'>
<p>When the recipient's client receives the hash of the avatar image, it SHOULD check the hash to determine if it already has a cached copy of that avatar image. If not, it retrieves the sender's full vCard in accordance with the protocol flow describerd in <cite>JEP-0054</cite> (note that this request is sent to the user's bare JID, not full JID):</p>
<p>When the recipient's client receives the hash of the avatar image, it SHOULD check the hash to determine if it already has a cached copy of that avatar image. If not, it retrieves the sender's full vCard in accordance with the protocol flow describerd in <cite>XEP-0054</cite> (note that this request is sent to the user's bare JID, not full JID):</p>
<example caption="Contact&apos;s Client Requests User&apos;s vCard"><![CDATA[
<iq from='romeo@montague.net/orchard'
to='juliet@capulet.com'
@ -160,7 +160,7 @@
<section2 topic='Inclusion of Update Data in Presence' anchor='bizrules-presence'>
<p>The following rules apply to inclusion of the update child element (&lt;x xmlns='vcard-temp:x:update'/&gt;) in presence broadcasts:</p>
<ol>
<li><p>If a client supports the protocol defined herein, it MUST include the update child element in every presence broadcast it sends and SHOULD also include the update child in directed presence stanzas (e.g., directed presence sent when joining &jep0045; rooms).</p></li>
<li><p>If a client supports the protocol defined herein, it MUST include the update child element in every presence broadcast it sends and SHOULD also include the update child in directed presence stanzas (e.g., directed presence sent when joining &xep0045; rooms).</p></li>
<li>
<p>If a client is not yet ready to advertise an image, it MUST send an empty update child element, i.e.:</p>
<example caption="User Is Not Ready to Advertise an Image"><![CDATA[
@ -240,12 +240,12 @@
<p>If the image data exceeds the 8 KB restriction, the processing application SHOULD process the data.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This document introduces no security considerations above and beyond those described in &rfc3920;, &rfc3921;, and &jep0054;.</p>
<p>This document introduces no security considerations above and beyond those described in &rfc3920;, &rfc3921;, and &xep0054;.</p>
</section1>
<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; includes 'vcard-temp:x:update' in its registry of protocol namespaces (see &NAMESPACES;).</p>
</section2>
@ -263,7 +263,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0153: http://www.jabber.org/jeps/jep-0153.html
XEP-0153: http://www.xmpp.org/extensions/xep-0153.html
</xs:documentation>
</xs:annotation>
@ -281,4 +281,4 @@
<section1 topic='Acknowledgements' anchor='ack'>
<p>The author wishes to thank the helpful developers who have implemented this protocol and provided feedback regarding its documentation.</p>
</section1>
</jep>
</xep>

102
xep-0154.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>User Profile</title>
<abstract>This document specifies how to represent and manage profile data about IM users and other XMPP entities using the XMPP Data Forms extension.</abstract>
@ -16,13 +16,13 @@
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0004</spec>
<spec>JEP-0060</spec>
<spec>JEP-0068</spec>
<spec>JEP-0163</spec>
<spec>XEP-0004</spec>
<spec>XEP-0060</spec>
<spec>XEP-0068</spec>
<spec>XEP-0163</spec>
</dependencies>
<supersedes>
<spec>JEP-0054</spec>
<spec>XEP-0054</spec>
</supersedes>
<supersededby/>
<shortname>profile</shortname>
@ -31,7 +31,7 @@
<version>0.5</version>
<date>2006-08-02</date>
<initials>psa</initials>
<remark><p>Updated to reflect changes to JEP-0163; added some mappings to the eduPerson object class.</p></remark>
<remark><p>Updated to reflect changes to XEP-0163; added some mappings to the eduPerson object class.</p></remark>
</revision>
<revision>
<version>0.4</version>
@ -55,7 +55,7 @@
<version>0.1</version>
<date>2005-06-16</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.5</version>
@ -89,27 +89,27 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>It is widely acknowledged within the Jabber/XMPP community that the &jep0054; specification (<cite>JEP-0054</cite>) has outlived its usefulness. There are several reasons for this conclusion:</p>
<p>It is widely acknowledged within the Jabber/XMPP community that the &xep0054; specification (<cite>XEP-0054</cite>) has outlived its usefulness. There are several reasons for this conclusion:</p>
<ol>
<li><cite>JEP-0054</cite> is not fully consistent with the Internet-Draft on which it was based.</li>
<li><cite>XEP-0054</cite> is not fully consistent with the Internet-Draft on which it was based.</li>
<li>The Internet-Draft on which it was based was never approved by the IETF.</li>
<li>Because of confusion over aspects of the vcard-temp specification, there exist incompatible implementations.</li>
<li>vCard (&rfc2426;) captures only a limited set of information.</li>
<li>vCard (even in its XML representation <note>For links to the experimental XML representation of vCard, see <cite>JEP-0054</cite>.</note>) is not easily extensible, leading those who develop profiles for specialized communities to "roll their own" protocols, to the detriment of interoperability.</li>
<li>vCard (even in its XML representation <note>For links to the experimental XML representation of vCard, see <cite>XEP-0054</cite>.</note>) is not easily extensible, leading those who develop profiles for specialized communities to "roll their own" protocols, to the detriment of interoperability.</li>
<li>vCard data tends to be monolithic (the basic unit of information is the full vCard, not parts thereof).</li>
<li>The publication model for JEP-0054 is to set the full vCard, rather than only the parts that need to be modified.</li>
<li>The retrieval model for JEP-0054 is to get the full vCard, rather than only the parts that have been modified.</li>
<li>The publication model for XEP-0054 is to set the full vCard, rather than only the parts that need to be modified.</li>
<li>The retrieval model for XEP-0054 is to get the full vCard, rather than only the parts that have been modified.</li>
</ol>
<p>Given the weaknesses of vCard, there is interest across the broader Internet community in replacing vCard with something more modern and extensible. Unfortunately, no other standards development organization has developed an alternative to vCard. Part of the challenge is that quite detailed ontologies have been developed that might replace parts of the vCard specification (e.g., the <cite>Extensible Name and Address Language</cite> <note>See &lt;<link url='http://xml.coverpages.org/xnal.html'>http://xml.coverpages.org/xnal.html</link>&gt;.</note> developed by &OASIS;) while less-formal ontologies are being used to represent other parts of the problem space (e.g., &foaf;). The relevant protocols are in flux and it is unclear when (or even if) stability will emerge.</p>
<p>Because of the unsettled landspace and the strong desire within the Jabber/XMPP community to move beyond JEP-0054, this JEP specifies methods for the representation of profile data in terms of the &jep0004; protocol (further qualified using the standardization concepts specified in &jep0068;) and for the management of profile data using standard IQ request-response semantics as well as, for more frequently-modified data, &jep0060; semantics (specifically the simplified subset of those semantics specified in &jep0163;). The rationale behind these design decisions is provided below.</p>
<p>Because of the unsettled landspace and the strong desire within the Jabber/XMPP community to move beyond XEP-0054, this document specifies methods for the representation of profile data in terms of the &xep0004; protocol (further qualified using the standardization concepts specified in &xep0068;) and for the management of profile data using standard IQ request-response semantics as well as, for more frequently-modified data, &xep0060; semantics (specifically the simplified subset of those semantics specified in &xep0163;). The rationale behind these design decisions is provided below.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This JEP addresses the following requirements for data management:</p>
<p>This document addresses the following requirements for data management:</p>
<ol>
<li>Enable an entity to publish profile data about itself.</li>
<li>Enable requesting entities to retrieve profile data about other entities.</li>
</ol>
<p>This JEP addresses the following requirements for data representation:</p>
<p>This document addresses the following requirements for data representation:</p>
<ol>
<li>Specify how to represent profile data in an XMPP-friendly manner for communication over the wire.</li>
<li>Ensure that the protocol is extensible (e.g., not limited to existing vCard fields).
@ -124,11 +124,11 @@
<ol>
<li>
<p><strong>IQ (request-and-response) semantics.</strong></p>
<p>In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &jep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://jabber.org/protocol/profile' namespace.</p>
<p>In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &xep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://jabber.org/protocol/profile' namespace.</p>
</li>
<li>
<p><strong>Pubsub (publish-and-subscribe) semantics.</strong></p>
<p>A more complex model is for an entity to publish its profile data to a publish-subscribe node or nodes and allow other entities to subscribe to that node or nodes, thus receiving notifications whenever the profiled entity updates its data. This model is more appropriate for entities that modify their profile data on a regular basis or when other entities wish to be informed when the profile data changes. Because this model will most likely be used most often by IM users and other intermittently-connected network endpoints, we use the simplified subset of the XMPP publish-subscribe extension defined in <cite>JEP-0163</cite> to implement this model.</p>
<p>A more complex model is for an entity to publish its profile data to a publish-subscribe node or nodes and allow other entities to subscribe to that node or nodes, thus receiving notifications whenever the profiled entity updates its data. This model is more appropriate for entities that modify their profile data on a regular basis or when other entities wish to be informed when the profile data changes. Because this model will most likely be used most often by IM users and other intermittently-connected network endpoints, we use the simplified subset of the XMPP publish-subscribe extension defined in <cite>XEP-0163</cite> to implement this model.</p>
</li>
</ol>
</section2>
@ -136,7 +136,7 @@
<p>As with data management, there are several possible approaches to representing profile data for communication over XMPP networks, including the following:</p>
<ul>
<li>
<p><strong>Structured data formats, such as &jep0080; and &jep0112;.</strong></p>
<p><strong>Structured data formats, such as &xep0080; and &xep0112;.</strong></p>
<p>Such data formats have the advantage of being human-readable. However:</p>
<ol>
<li>They are not easily extensible: developers of specialized community services would need to write their own structured data formats, even to add one new field.</li>
@ -148,26 +148,26 @@
<p><strong>A format represented by means of &w3rdf;.</strong></p>
<p>An argument could be made that RDF is a reasonable approach for representing profile data for communication over the XMPP network; however, such an argument will not be made in the current proposal. The author has considered RDF and has concluded that there are several reasons why RDF is undesirable as an XMPP wire protocol:</p>
<ol>
<li>RDF exists in an XML representation but the semantics of RDF impose a more complex conceptual structure (data triples) than does XML, which is sub-optimal since unnecessary complexity is to be avoided (see &jep0134;).</li>
<li>RDF exists in an XML representation but the semantics of RDF impose a more complex conceptual structure (data triples) than does XML, which is sub-optimal since unnecessary complexity is to be avoided (see &xep0134;).</li>
<li>RDF requires a specialized parser rather than the normal XML parser that comes standard with all XMPP implementations.</li>
<li>As long as it is possible to define a consistent mapping of profile data to RDF representations, it should be straightforward to convert the XMPP data formats into those RDF representations if desired (e.g., to output a FOAF file).</li>
</ol>
</li>
<li>
<p><strong>A format represented by means of Data Forms (JEP-0004).</strong></p>
<p>The Data Forms protocol defined in JEP-0004 has several advantages for use over XMPP:</p>
<p><strong>A format represented by means of Data Forms (XEP-0004).</strong></p>
<p>The Data Forms protocol defined in XEP-0004 has several advantages for use over XMPP:</p>
<ol>
<li>It can be parsed using an off-the-shelf XML parser.</li>
<li>It is already widely deployed in existing Jabber/XMPP clients, servers, and components.</li>
<li>The data forms protocol is easily extensible.</li>
<li>The Jabber/XMPP community possesses consistent methods for profiling and scoping data forms (as specified in <cite>JEP-0068</cite>).</li>
<li>The Jabber/XMPP community possesses consistent methods for profiling and scoping data forms (as specified in <cite>XEP-0068</cite>).</li>
<li>Data forms have a generic schema that is easy to map to common data storage mechanisms (usually databases).</li>
<li>Data forms provide a consistent abstraction layer for XMPP applications, thus shielding them from changes in the profile data formats being defined by other Internet projects and standards development organizations.</li>
<li>The use of data forms as the medium of representation for communication over the wire does not prevent applications from storing backend profile data in some other underlying format (e.g., RDF or a database).</li>
</ol>
</li>
</ul>
<p>Therefore, this proposal specifies that profile data shall be scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', in accordance with the field standardization methods defined in <cite>JEP-0068</cite>. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the &REGISTRAR; (although they may or may not be defined in a Jabber Enhancement Proposal). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of <cite>JEP-0068</cite>. <note>Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.</note></p>
<p>Therefore, this proposal specifies that profile data shall be scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', in accordance with the field standardization methods defined in <cite>XEP-0068</cite>. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the &REGISTRAR; (although they may or may not be defined in a Jabber Enhancement Proposal). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of <cite>XEP-0068</cite>. <note>Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.</note></p>
<p>The following is a simple and incomplete example of profile data represented via the Data Forms protocol, containing two registered data fields and one unregistered field:</p>
<example caption='A Basic Example'><![CDATA[
<profile xmlns='http://jabber.org/protocol/profile'>
@ -190,7 +190,7 @@
]]></example>
<p>By specifying that all fields are scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'http://jabber.org/protocol/profile' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.</p>
<p>However, scoping all data fields with a single FORM_TYPE implies it is necessary to define separate data fields for similar kinds of information. For example, the vCard specification (<cite>RFC 2426</cite>) defines "types" for certains kinds of data, such as email addresses, telephone numbers, and physical addresses, making it possible to specify that a telephone number corresponds to a fax machine or mobile phone or that a physical address corresponds to one's home or work location. In the Data Forms representation, any desired piece of information (e.g., work phone) must be represented with a separate data field.</p>
<p>In order to address most (if not all) of the pieces of information described in existing profile specifications, this JEP defines a great number of data fields. Even so, the data fields specified herein are not exhaustive, and it is expected that additional fields will be registered in the future through the mechanisms specified in the <link url='#registrar'>Jabber Registrar Considerations</link> section of this JEP.</p>
<p>In order to address most (if not all) of the pieces of information described in existing profile specifications, this document defines a great number of data fields. Even so, the data fields specified herein are not exhaustive, and it is expected that additional fields will be registered in the future through the mechanisms specified in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
</section2>
</section1>
<section1 topic='Producer Use Cases' anchor='producer'>
@ -226,7 +226,7 @@
<p>Otherwise it MUST return an error. If the server does not support the profile data functionality, the error MUST be &unavailable;.</p>
</section2>
<section2 topic='Updating One or More Profile Fields' anchor='producer-pub'>
<p>In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "http://jabber.org/protocol/profile" at its server using the PEP subset of the publish-subscribe extension, as specified in <cite>JEP-0163</cite>.</p>
<p>In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "http://jabber.org/protocol/profile" at its server using the PEP subset of the publish-subscribe extension, as specified in <cite>XEP-0163</cite>.</p>
<example caption='Account owner publishes profile field(s)'><![CDATA[
<iq type='set' id='pub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
@ -270,7 +270,7 @@
</section1>
<section1 topic='Consumer Use Cases' anchor='consumer'>
<section2 topic='Discovering Support' anchor='consumer-disco'>
<p>If an entity can provide profile data directly using the standalone 'http://jabber.org/protocol/profile' namespace, it SHOULD advertise that feature in response to &jep0030; information requests:</p>
<p>If an entity can provide profile data directly using the standalone 'http://jabber.org/protocol/profile' namespace, it SHOULD advertise that feature in response to &xep0030; information requests:</p>
<example caption='A request for service discovery information'><![CDATA[
<iq type='get'
from='bard@shakespeare.lit/globe'
@ -423,7 +423,7 @@
</pubsub>
</iq>
]]></example>
<p>If the server allows the subscription, it MUST return an IQ-result (see <cite>JEP-0163</cite> for error scenarios):</p>
<p>If the server allows the subscription, it MUST return an IQ-result (see <cite>XEP-0163</cite> for error scenarios):</p>
<example caption='Server allows subscription'><![CDATA[
<iq type='result'
from='hamlet@denmark.lit'
@ -452,7 +452,7 @@
</section2>
</section1>
<section1 topic='Data Representation' anchor='fields'>
<p>The following subsections specify common fields for defining various aspects of a person, which shall form the initial submission to the Jabber Registrar; many of these fields map to elements specified in vCard, xNAL, FOAF, LDAP (see &rfc2252;, &rfc2256;, and &rfc2798;) <note>This specification does not require that profile data fields mapped to LDAP fields must adhere to the X.500 data types that are re-used by LDAP. However, implementations MAY enforce those data types if desired.</note>, and LDAP object classes such as Person, organizationalPerson, inetOrgPerson, and eduPerson.</p>
<p>The following subsections specify common fields for defining various aspects of a person, which shall form the initial submission to the XMPP Registrar; many of these fields map to elements specified in vCard, xNAL, FOAF, LDAP (see &rfc2252;, &rfc2256;, and &rfc2798;) <note>This specification does not require that profile data fields mapped to LDAP fields must adhere to the X.500 data types that are re-used by LDAP. However, implementations MAY enforce those data types if desired.</note>, and LDAP object classes such as Person, organizationalPerson, inetOrgPerson, and eduPerson.</p>
<section2 topic='Name Data Aspects' anchor='fields-name'>
<p>Mappings are provided to vCard, LDAP, xNAL, and FOAF.</p>
<section3 topic='Display Name' anchor='display_name'>
@ -586,16 +586,16 @@
</section3>
</section2>
<section2 topic='Physical Address Data Aspects' anchor='fields-physicaladdress'>
<p>Mappings are provided to vCard, xNAL, and JEP-0112 (&jep0112;).</p>
<p>Mappings are provided to vCard, xNAL, and XEP-0112 (&xep0112;).</p>
<section3 topic='Country' anchor='country'>
<p>A country is the sovereign nation in which a person is located. Sometimes also called a "nation".</p>
<p>The Data Forms fields that represent a country are "country", "home_country", and "work_country" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard COUNTRY (or JEP-0054 CTRY), optionally supplemented with the "HOME" or "WORK" type</li>
<li>vCard COUNTRY (or XEP-0054 CTRY), optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP c</li>
<li>xNAL CountryName</li>
<li>JEP-0112 country</li>
<li>XEP-0112 country</li>
</ul>
<example caption='Country'><![CDATA[
<field var='country'>
@ -612,7 +612,7 @@
<li>vCard REGION, optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP st</li>
<li>xNAL AdministrativeAreaName</li>
<li>JEP-0112 region</li>
<li>XEP-0112 region</li>
</ul>
<example caption='Region'><![CDATA[
<field var='region'>
@ -628,7 +628,7 @@
<li>vCard LOCALITY, optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP l</li>
<li>xNAL LocalityName</li>
<li>JEP-0112 locality</li>
<li>XEP-0112 locality</li>
</ul>
<example caption='Locality'><![CDATA[
<field var='locality'>
@ -642,7 +642,7 @@
<p>This field maps to:</p>
<ul>
<li>xNAL DependentLocalityName</li>
<li>JEP-0112 area</li>
<li>XEP-0112 area</li>
</ul>
<example caption='Area'><![CDATA[
<field var='area'>
@ -658,7 +658,7 @@
<li>vCard STREET, optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP street</li>
<li>xNAL ThoroughfareNumber + ThoroughfareName</li>
<li>JEP-0112 street</li>
<li>XEP-0112 street</li>
</ul>
<example caption='Street'><![CDATA[
<field var='street'>
@ -673,7 +673,7 @@
<ul>
<li>vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type</li>
<li>xNAL BuildingName</li>
<li>JEP-0112 building</li>
<li>XEP-0112 building</li>
</ul>
<example caption='Building'><![CDATA[
<field var='building'>
@ -688,7 +688,7 @@
<ul>
<li>vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type</li>
<li>xNAL SubPremiseNumber</li>
<li>JEP-0112 floor</li>
<li>XEP-0112 floor</li>
</ul>
<example caption='Floor'><![CDATA[
<field var='floor'>
@ -704,7 +704,7 @@
<li>vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP roomNumber</li>
<li>xNAL SubPremiseNumber</li>
<li>JEP-0112 room</li>
<li>XEP-0112 room</li>
</ul>
<example caption='Room'><![CDATA[
<field var='room'>
@ -734,7 +734,7 @@
<li>vCard PCODE, optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP postalCode</li>
<li>xNAL PostalCodeNumber</li>
<li>JEP-0112 postalcode</li>
<li>XEP-0112 postalcode</li>
</ul>
<example caption='Postal Code'><![CDATA[
<field var='postalcode'>
@ -760,13 +760,13 @@
</section3>
</section2>
<section2 topic='Geolocation Data Aspects' anchor='fields-geoloc'>
<p>Mappings are provided to vCard and JEP-0080 (&jep0080;).</p>
<p>Mappings are provided to vCard and XEP-0080 (&xep0080;).</p>
<section3 topic='Altitude' anchor='alt'>
<p>Altitude is a person's height or depth in relationship to sea level, where positive altitude is meters above sea level and negative altitude is meters below sea level.</p>
<p>The Data Forms field that represents altitude is "alt".</p>
<p>This field maps to:</p>
<ul>
<li>JEP-0080 alt</li>
<li>XEP-0080 alt</li>
</ul>
<example caption='Altitude'><![CDATA[
<field var='alt'>
@ -780,7 +780,7 @@
<p>This field maps to:</p>
<ul>
<li>vCard LAT</li>
<li>JEP-0080 lat</li>
<li>XEP-0080 lat</li>
</ul>
<example caption='Latitude'><![CDATA[
<field var='lat'>
@ -794,7 +794,7 @@
<p>This field maps to:</p>
<ul>
<li>vCard LON</li>
<li>JEP-0080 lon</li>
<li>XEP-0080 lon</li>
</ul>
<example caption='Latitude'><![CDATA[
<field var='lon'>
@ -1920,16 +1920,16 @@ XhK8hFkPvXjudl7xAJ95+2fAHfmHheZJVaO8VaJiL54Tvw==
<p>Profile data can be personally significant and even security critical. Due care should be taken in determining who shall have access to such information. In particular, an entity SHOULD ensure that its public profile contains only information that it deems safe to be world-readable, SHOULD ensure that any pubsub node it may create for profile data has an access model of "presence" or "roster", and SHOULD NOT publish private or restricted data except to such a pubsub node.</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='Field Standardization' anchor='registrar-formtype'>
<p>To follow.</p>
<!--
<code caption='Registry Submission'><![CDATA[
<form_type>
<name>http://jabber.org/protocol/profile</name>
<doc>JEP-0154</doc>
<doc>XEP-0154</doc>
<desc>Forms for entity profile data.</desc>
<field
var='given_name'
@ -1944,4 +1944,4 @@ XhK8hFkPvXjudl7xAJ95+2fAHfmHheZJVaO8VaJiL54Tvw==
-->
</section2>
</section1>
</jep>
</xep>

44
xep-0155.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>Chat Session Negotiation</title>
<abstract>This document specifies a feature negotiation profile for initiating a one-to-one chat session.</abstract>
@ -17,8 +17,8 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0020</spec>
<spec>JEP-0068</spec>
<spec>XEP-0020</spec>
<spec>XEP-0068</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -35,7 +35,7 @@
<version>0.7</version>
<date>2006-07-14</date>
<initials>psa</initials>
<remark><p>Added secure field from JEP-0116.</p></remark>
<remark><p>Added secure field from XEP-0116.</p></remark>
</revision>
<revision>
<version>0.6</version>
@ -65,7 +65,7 @@
<version>0.2</version>
<date>2005-07-15</date>
<initials>psa</initials>
<remark><p>Further described contexts in which chat session negotiation could be useful; added more examples; added reference to SIP RFC and explained basic mapping to SIP INVITE method; added Jabber Registrar considerations.</p></remark>
<remark><p>Further described contexts in which chat session negotiation could be useful; added more examples; added reference to SIP RFC and explained basic mapping to SIP INVITE method; added XMPP Registrar considerations.</p></remark>
</revision>
<revision>
<version>0.1</version>
@ -83,12 +83,12 @@
<section1 topic='Introduction' anchor='intro'>
<p>The traditional model for one-to-one chat "sessions" in Jabber/XMPP is for a user to simply send a message to a contact without any formal negotiation of chat session parameters (e.g., see &xmppim;). This informal approach to initiation of a chat session is perfectly acceptable in many contexts, environments, and cultures. However, it may be desirable to formally request the chat and negotiate its parameters before beginning the chat session in some circumstances, such as:</p>
<ul>
<li>Whenever parameters specific to a chat session must be agreed. e.g., security and privacy parameters (see &jep0116; and &jep0136;).</li>
<li>The parties are unknown to each other, have not exchanged presence, or have not discovered their respective capabilities via &jep0030; or &jep0115;.</li>
<li>Whenever parameters specific to a chat session must be agreed. e.g., security and privacy parameters (see &xep0116; and &xep0136;).</li>
<li>The parties are unknown to each other, have not exchanged presence, or have not discovered their respective capabilities via &xep0030; or &xep0115;.</li>
<li>When an XMPP-based system interfaces with a SIP-based system built on top of &rfc3261;. <note>In essence, a chat state negotiation request as specified herein is functionally equivalent to a SIP INVITE request, and acceptance of such a request is functionally equivalent to sending a SIP 200 OK response; see Section 17 of <cite>RFC 3261</cite>.</note></li>
<li>Within an organization or culture in which one would not simply begin chatting with another person (e.g., a superior) without first receiving permission to do so.</li>
</ul>
<p>This proposal defines best practices for such a negotiation, re-using the protocol defined in &jep0020;.</p>
<p>This proposal defines best practices for such a negotiation, re-using the protocol defined in &xep0020;.</p>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Initiating a Chat' anchor='initiate'>
@ -140,7 +140,7 @@
</feature>
</message>
]]></example>
<p>In the foregoing example, Romeo requests a chat with Juliet and also queries her regarding whether she wants to disable all message logging (see &jep0136;) <note>A client MUST NOT set the 'otr' field to 'true' unless it has confirmed that its server will allow it to switch off Automated Archiving (see <cite>Message Archiving</cite>).</note> and support &jep0071; and &jep0085; extensions during this chat session. (Note: These fields are examples only; a full set of chat session negotiation parameters will be registered as described in the <link url='#registrar'>Jabber Registrar Considerations</link> section of this document.)</p>
<p>In the foregoing example, Romeo requests a chat with Juliet and also queries her regarding whether she wants to disable all message logging (see &xep0136;) <note>A client MUST NOT set the 'otr' field to 'true' unless it has confirmed that its server will allow it to switch off Automated Archiving (see <cite>Message Archiving</cite>).</note> and support &xep0071; and &xep0085; extensions during this chat session. (Note: These fields are examples only; a full set of chat session negotiation parameters will be registered as described in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.)</p>
<p>Juliet's server delivers Romeo's request to her most available resource (which happens to be "balcony").</p>
<p>In any response to the request, the contact's client MUST mirror the 'id' attribute and &THREAD;value so that the user's client can correctly track the response.</p>
<p>We assume that Juliet accepts the chat and specifies that she does not want to log messages or use XHTML formatting but that she does want to use Chat State Notifications:</p>
@ -486,7 +486,7 @@
<section1 topic='Implementation Notes' anchor='impl'>
<p>A client MAY require a human user to approve each chat session negotiation request or MAY auto-accept and auto-reject requests based on some user-configurable policy.</p>
<p>If a party receives XMPP presence of type "unavailable" from the full JID (&FULLJID;) of the other party (i.e., the resource with which it has had an active session) during a chat session, the receiving party MAY assume that the other client will still be unable to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated chat until it reconnects and receives "offline" messages).
However, if the receiving party assumes that the other client will <em>not</em> be able to continue the session, then it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Chat</link>) - since its assumption could be incorrect. If the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the chat session, it MUST initiate a new chat session (including a newly-generated ThreadID) with the other party rather than renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in <cite>JEP-0085</cite>.)</p>
However, if the receiving party assumes that the other client will <em>not</em> be able to continue the session, then it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Chat</link>) - since its assumption could be incorrect. If the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the chat session, it MUST initiate a new chat session (including a newly-generated ThreadID) with the other party rather than renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in <cite>XEP-0085</cite>.)</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>If a contact accepts a user's request or returns an error to the user, the user will effectively discover the contact's presence (at least the presence of one of the contact's resources). Due care must therefore be exercised in determining whether to accept the request or return an error. For examples, the contact's client SHOULD NOT <em>automatically</em> (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribing to the contact's presence (and the contact's presence is not currently "invisible" to the user). Furthermore, the contact's client MUST NOT take either action if the user is in the contact's block list.</p>
@ -494,23 +494,23 @@ However, if the receiving party assumes that the other client will <em>not</em>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP 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 Features' anchor='registrar-features'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/chatneg' in its registry of Service Discovery features.</p>
<code caption='Registry Submission'><![CDATA[
<var>
<name>http://jabber.org/protocol/chatneg</name>
<desc>Support for Chat Session Negotiation and its FORM_TYPE</desc>
<doc>JEP-0155</doc>
<doc>XEP-0155</doc>
</var>
]]></code>
</section2>
<section2 topic='Field Standardization' anchor='registrar-formtype'>
<p>&jep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields shall be registered for use in 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 Chat Session Negotiation:</p>
<code caption='Registry Submission'><![CDATA[
<form_type>
<name>http://jabber.org/protocol/chatneg</name>
<doc>JEP-0155</doc>
<doc>XEP-0155</doc>
<desc>
Forms enabling negotation of a one-to-one
chat session between two entities.
@ -522,15 +522,15 @@ However, if the receiving party assumes that the other client will <em>not</em>
<field
var='http://jabber.org/protocol/chatstates'
type='boolean'
label='Whether to enable Chat State Notifications per JEP-0085'/>
label='Whether to enable Chat State Notifications per XEP-0085'/>
<field
var='http://jabber.org/protocol/xhtml-im'
type='boolean'
label='Whether to enable XHTML-IM formatting per JEP-0071'/>
label='Whether to enable XHTML-IM formatting per XEP-0071'/>
<field
var='otr'
type='boolean'
label='Off-The-Record: whether to disable absolutely all message logging including automatic archiving - see JEP-0136'/>
label='Off-The-Record: whether to disable absolutely all message logging including automatic archiving - see XEP-0136'/>
<field
var='reason'
type='text-single'
@ -552,9 +552,9 @@ However, if the receiving party assumes that the other client will <em>not</em>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>This proposal re-uses the format defined in JEP-0020 and therefore does not require a separate schema.</p>
<p>This proposal re-uses the format defined in XEP-0020 and therefore does not require a separate schema.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Thomas Charron and Jean-Louis Seguineau for their feedback.</p>
</section1>
</jep>
</xep>

24
xep-0156.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 DNS TXT Resource Record Format for XMPP Connection Methods</title>
<abstract>This document defines a DNS TXT Resource Record format for use in specifying methods of connecting to an XMPP server.</abstract>
@ -61,7 +61,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Although &rfc3920; specifies the use of TCP as the method of connecting to an XMPP server, other connection methods are possible. These include the older &jep0025; method, the more recent &jep0124; method, and less common methods such as &wap;. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTP URL of an alternative connection manager. Currently, if a client application needs to discover connection methods before connecting to an XMPP service, the relevant information must be provided manually by a human user, which is cumbersome and error-prone. Thankfully, there are several potential ways to complete this pre-connection service discovery in an automated fashion:</p>
<p>Although &rfc3920; specifies the use of TCP as the method of connecting to an XMPP server, other connection methods are possible. These include the older &xep0025; method, the more recent &xep0124; method, and less common methods such as &wap;. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTP URL of an alternative connection manager. Currently, if a client application needs to discover connection methods before connecting to an XMPP service, the relevant information must be provided manually by a human user, which is cumbersome and error-prone. Thankfully, there are several potential ways to complete this pre-connection service discovery in an automated fashion:</p>
<ol>
<li><p>Specify a &w3wsdl; definition (or other XML file format) and a canonical URL for that definition at a domain that offers XMPP services. Unfortunately, this approach requires access to the HTTP server for the domain (and quite possibly to the root directory thereof), which may be difficult for XMPP server administrators to arrange. In addition, it requires a client to retrieve the relevant file via HTTP before performing DNS lookups and XMPP connection; it would be more efficient to use recognized DNS methods since DNS lookups are already required by <cite>RFC 3920</cite>.</p></li>
<li><p>Specify a way to define the required service discovery information as part of the existing DNS SRV records (see &rfc2782;) for a domain that offers XMPP services. While this approach sounds promising, it is not feasible since the DNS SRV Target field can be used only to specify domain names and cannot be used to specify full URIs (such as the URL for an HTTP connection manager).</p></li>
@ -81,7 +81,7 @@
<li>It is RECOMMENDED for the owner to be "_xmppconnect".</li>
<li>The class field SHOULD be IN.</li>
<li>The ttl field is OPTIONAL.</li>
<li>The attribute name SHOULD begin with the string "_xmpp-client-" or "_xmpp-server-" and SHOULD be registered as described in the <link url='#registrar'>Jabber Registrar Considerations</link> section of this document.</li>
<li>The attribute name SHOULD begin with the string "_xmpp-client-" or "_xmpp-server-" and SHOULD be registered as described in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</li>
<li>If the txt-data field contains only an attribute name (i.e., no unquoted "=" character followed by additional characters), the receiving application SHOULD interpret it as indicating the presence of the attribute or feature with no defined value.</li>
<li>If the txt-data field contains an unquoted "=" character, it MUST also contain an attribute value.</li>
</ol>
@ -95,7 +95,7 @@
</ol>
</section1>
<section1 topic='Examples' anchor='examples'>
<p>The following examples show three DNS TXT resource records: the first indicates support for the httpbind connection method defined in JEP-0124 including the appropriate URL, the second indicates support for the httppoll connection method defined in JEP-0025 including the appropriate URL, and the third indicates support for WAP connections including the appropriate URL.</p>
<p>The following examples show three DNS TXT resource records: the first indicates support for the httpbind connection method defined in XEP-0124 including the appropriate URL, the second indicates support for the httppoll connection method defined in XEP-0025 including the appropriate URL, and the third indicates support for WAP connections including the appropriate URL.</p>
<example caption='TXT Resource Records'><![CDATA[
_xmppconnect IN TXT "_xmpp-client-httpbind=https://webconnect.jabber.org:8080/bind.cgi"
_xmppconnect IN TXT "_xmpp-client-httppoll=https://webconnect.jabber.org:8081/poll.cgi"
@ -108,9 +108,9 @@ _xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector.cgi"
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='DNS TXT Records Registry' anchor='registrar-dnstxt'>
<p>The Jabber Registrar shall maintain a registry of attributes for use in DNS TXT resource records that advertise XMPP connection methods.</p>
<p>The XMPP Registrar shall maintain a registry of attributes for use in DNS TXT resource records that advertise XMPP connection methods.</p>
<section3 topic='Process' anchor='registrar-dnstxt-process'>
&REGPROCESS;
<code><![CDATA[
@ -129,14 +129,14 @@ _xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector.cgi"
<name>_xmpp-client-httpbind</name>
<desc>the HTTP Binding connection method</desc>
<value>the http: or https: URL at which to contact the HTTP Binding connection manager or proxy</value>
<doc>JEP-0124</doc>
<doc>XEP-0124</doc>
</attribute>
<attribute>
<name>_xmpp-client-httppoll</name>
<desc>the HTTP Polling connection method</desc>
<value>the http: or https: URL at which to contact the HTTP Polling connection manager or proxy</value>
<doc>JEP-0025</doc>
<doc>XEP-0025</doc>
</attribute>
<attribute>
@ -157,4 +157,4 @@ _xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector.cgi"
</section3>
</section2>
</section1>
</jep>
</xep>

22
xep-0157.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>Contact Addresses for XMPP Services</title>
<abstract>This document defines a method for specifying contact addresses related to an XMPP service.</abstract>
@ -43,13 +43,13 @@
<version>0.1</version>
<date>2005-09-08</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2005-09-06</date>
<initials>psa</initials>
<remark><p>Added security considerations and Jabber Registrar considerations.</p></remark>
<remark><p>Added security considerations and XMPP Registrar considerations.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -70,7 +70,7 @@
</section1>
<!--
<section1 topic='Extended Server Information' anchor='disco'>
<p>The administrators of a Jabber/XMPP service may desire to advertise more detailed contact information related to that service. This contact information may include email addresses, web URLs, and JIDs for specific roles and functions such as abuse reports, customer feedback, sales inquiries, technical support, and security concerns. For this purpose, domains MUST support the electronic mailboxes required by <cite>RFC 2142</cite>. However, additional contact mechanisms may be desirable, and it would be helpful if those who want to initiate contact could discover the contact information using standard XMPP extensions, specifically &jep0030;. To make such discovery possible, we specify a &jep0128; mechanism that a server MAY return in response to service discovery information ("disco#info") requests sent to the bare domain of the server. This information SHOULD be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as already specified in <cite>JEP-0128</cite>) and data form fields registered for this purpose as defined in the <link url='#registrar'>Jabber Registrar Considerations</link> section of this document.</p>
<p>The administrators of a Jabber/XMPP service may desire to advertise more detailed contact information related to that service. This contact information may include email addresses, web URLs, and JIDs for specific roles and functions such as abuse reports, customer feedback, sales inquiries, technical support, and security concerns. For this purpose, domains MUST support the electronic mailboxes required by <cite>RFC 2142</cite>. However, additional contact mechanisms may be desirable, and it would be helpful if those who want to initiate contact could discover the contact information using standard XMPP extensions, specifically &xep0030;. To make such discovery possible, we specify a &xep0128; mechanism that a server MAY return in response to service discovery information ("disco#info") requests sent to the bare domain of the server. This information SHOULD be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as already specified in <cite>XEP-0128</cite>) and data form fields registered for this purpose as defined in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
<p>To illustrate this usage, consider the following example of a disco#info request sent to the mythical shakespeare.lit XMPP server:</p>
<example caption='Entity queries server for information'><![CDATA[
<iq from='juliet@capulet.com/chamber'
@ -124,14 +124,14 @@
<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 include the following information in its registries.</p>
<section2 topic='Field Standardization' anchor='registrar-formtype'>
<p>&jep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and <cite>JEP-0128</cite> describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "http://jabber.org/network/serverinfo" FORM_TYPE.</p>
<p>&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and <cite>XEP-0128</cite> describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "http://jabber.org/network/serverinfo" FORM_TYPE.</p>
<code caption='Registry Submission'><![CDATA[
<form_type>
<name>http://jabber.org/network/serverinfo</name>
<doc>JEP-0157</doc>
<doc>XEP-0157</doc>
<desc>
Forms enabling the communication of contact addresses
and other server information.
@ -161,4 +161,4 @@
</section2>
</section1>
-->
</jep>
</xep>

40
xep-0158.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>Robot Challenges</title>
<abstract>This document specifies an XMPP protocol extension that entities may use to discover whether the sender of an XML stanza is a human user or a robot.</abstract>
@ -16,8 +16,8 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0004</spec>
<spec>JEP-0066</spec>
<spec>XEP-0004</spec>
<spec>XEP-0066</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
@ -45,7 +45,7 @@
<version>0.1</version>
<date>2005-09-14</date>
<initials>ip</initials>
<remark>Initial JEP version.</remark>
<remark>Initial version.</remark>
</revision>
<revision>
<version>0.0.1</version>
@ -59,7 +59,7 @@
<p>The appearance of large public IM services based on &rfc3920; and &rfc3921; makes it desirable to implement protocols that <em>discourage</em> the sending of large quantities of IM SPAM (SPIM) from XMPP clients (connected to legitimate servers) and XMPP servers (with virtual clients) -- all hosted on networks of 'zombie' machines. SPIM is defined here as any type of unsolicited XMPP stanza sent by a 'robot' and delivered to a human, including messages and subscription requests. SPIM has the potential to disrupt people even more than SPAM, because each message interrupts the receiver (humans typically filter SPAM in batch mode).</p>
<p>Several of the most effective techniques developed to combat SPAM require humans to be differentiated from bots using a "Completely Automated Public Turing Test to Tell Computers and Humans Apart" or CAPTCHA (see &lt;<link url='http://www.captcha.net/'>http://www.captcha.net/</link>&gt;). These challenge techniques are easily adapted to discourage SPIM. The very occasional inconvenience of responding to a CAPTCHA (for example, when creating an IM account or sending a message to a new correspondent) is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day.</p>
<p>An alternative technique to CAPTCHAs requires Desktop PC clients to undertake a <span class='ref'>Hashcash</span> <note>Hashcash &lt;<link url='http://hashcash.org/'>http://hashcash.org/</link>&gt;.</note> challenge. These are completely transparent to PC users. They require clients to perform specified CPU-intensive work, making it difficult to send large amounts of SPIM.</p>
<p>The generic challenge protocol described in this document is designed for incorporation into other protocols like &jep0077; and &jep0159;.</p>
<p>The generic challenge protocol described in this document is designed for incorporation into other protocols like &xep0077; and &xep0159;.</p>
</section1>
<section1 topic='Requirements' anchor='require'>
@ -72,7 +72,7 @@
</section1>
<section1 topic='Media Element' anchor='media'>
<p>This protocol requires multimedia to be included within &jep0004;. This section defines a new namespace ('http://jabber.org/protocols/media') for that purpose. The root element for the namespace is &lt;media/&gt;. It MUST be contained within a &lt;field/&gt; element qualified by the 'jabber:x:data' namespace.</p>
<p>This protocol requires multimedia to be included within &xep0004;. This section defines a new namespace ('http://jabber.org/protocols/media') for that purpose. The root element for the namespace is &lt;media/&gt;. It MUST be contained within a &lt;field/&gt; element qualified by the 'jabber:x:data' namespace.</p>
<p>If the media is an image or video then the &lt;media/&gt; element SHOULD include 'width' and 'height' attributes specifying the recommended display size of the media in pixels.</p>
<p>The &lt;media/&gt; element SHOULD contain at least one &lt;uri/&gt; element to specify the out-of-band location of the media data. <note>Constrained execution environments prevent some clients rendering media unless it has been received out-of-band (e.g., Web clients).</note> The &lt;uri/&gt; element MUST contain a URI that indicates the location.</p>
<p>The &lt;media/&gt; element MAY also contain one or more &lt;data/&gt; elements for distributing the media in-band. The &lt;data/&gt; element MUST contain the Base64 encoded (in accordance with Section 3 of &rfc3548;) media data. The <em>encoded</em> data SHOULD NOT be larger than 8 KB. Note that if a stanza contains more than one &lt;data/&gt; element then the sending entity MUST take care not to trigger karma limits.</p>
@ -102,8 +102,8 @@
</message>
]]></example>
<section3 topic='Challenge Stanza' anchor='protocol-challenge'>
<p>Each of the challenge form's &lt;field/&gt; elements (see <cite>Data Forms</cite>) that are not hidden MAY contain a different challenge and any media required for the challenge. The hidden 'from' field MUST contain the value of the 'to' attribute of the client's stanza that triggered the challenge. If the stanza from the client included an 'id' attribute then the hidden 'sid' field MUST be set to that value. The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the client. The hidden 'FORM_TYPE' field MUST have a value of "http://jabber.org/protocol/challenge" in accordance with &jep0068;.</p>
<p>The challenger SHOULD include an explanation (in the &BODY; element) for clients that do not support this protocol. The challenger MAY also include a URL (typically a Web page with instructions) using &jep0066; as an alternative for clients that do not support the challenge form. Note: even if it provides a URL, a challenger MUST always provide a challenge form. <note>A constrained client, like a mobile phone, cannot present a Web page to its user.</note></p>
<p>Each of the challenge form's &lt;field/&gt; elements (see <cite>Data Forms</cite>) that are not hidden MAY contain a different challenge and any media required for the challenge. The hidden 'from' field MUST contain the value of the 'to' attribute of the client's stanza that triggered the challenge. If the stanza from the client included an 'id' attribute then the hidden 'sid' field MUST be set to that value. The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the client. The hidden 'FORM_TYPE' field MUST have a value of "http://jabber.org/protocol/challenge" in accordance with &xep0068;.</p>
<p>The challenger SHOULD include an explanation (in the &BODY; element) for clients that do not support this protocol. The challenger MAY also include a URL (typically a Web page with instructions) using &xep0066; as an alternative for clients that do not support the challenge form. Note: even if it provides a URL, a challenger MUST always provide a challenge form. <note>A constrained client, like a mobile phone, cannot present a Web page to its user.</note></p>
<example caption='Server Offers a Choice of Challenges to a Client'><![CDATA[
<message from='victim.com'
to='robot@spimmer.com/zombie'
@ -542,16 +542,16 @@
</section1>
<section1 topic='Security Considerations' anchor='sec'>
<p>This JEP introduces no security considerations above and beyond those described in <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</p>
<p>This document introduces no security considerations above and beyond those described in <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</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>Upon approval of this JEP, the &REGISTRAR; shall register the following protocol namespaces:</p>
<p>Upon approval of this document, the &REGISTRAR; shall register the following protocol namespaces:</p>
<ul>
<li>http://jabber.org/protocol/challenge</li>
<li>http://jabber.org/protocol/media</li>
@ -559,11 +559,11 @@
</section2>
<section2 topic='Field Standardization' anchor='registrar-formtypes'>
<section3 topic='challenge FORM_TYPE' anchor='registrar-formtypes-challenge'>
<p>Upon approval of this JEP, the <cite>Jabber Registrar</cite> shall register the following new FORM_TYPE. Additional fields will be defined in future submissions.</p>
<p>Upon approval of this document, the <cite>XMPP Registrar</cite> shall register the following new FORM_TYPE. Additional fields will be defined in future submissions.</p>
<code><![CDATA[
<form_type>
<name>http://jabber.org/protocol/challenge</name>
<doc>JEP-0158</doc>
<doc>XEP-0158</doc>
<desc>forms enabling robot challenges</desc>
<field
var='answers'
@ -625,11 +625,11 @@
]]></code>
</section3>
<section3 topic='jabber:iq:register FORM_TYPE' anchor='registrar-formtypes-register'>
<p>Upon approval of this JEP, the <cite>Jabber Registrar</cite> shall register the following new fields for the existing jabber:iq:register FORM_TYPE. Additional fields will be defined in future submissions.</p>
<p>Upon approval of this document, the <cite>XMPP Registrar</cite> shall register the following new fields for the existing jabber:iq:register FORM_TYPE. Additional fields will be defined in future submissions.</p>
<code><![CDATA[
<form_type>
<name>jabber:iq:register</name>
<doc>JEP-0077</doc>
<doc>XEP-0077</doc>
<field
var='answers'
type='hidden'
@ -756,4 +756,4 @@
<section1 topic='Open Issues' anchor='open'>
<p>Another protocol could allow users to edit the challenges their server will make on their behalf. For example, the number of SHA-256 bits, a personal or original question and answer, a picture, a video, or a sound recording... Of course Aunt Tillie would typically only use this feature if she was plagued by SPIM.</p>
</section1>
</jep>
</xep>

26
xep-0159.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>SPIM-Blocking Control</title>
<abstract>This JEP allows clients to control how their servers may block SPIM that is addressed to them. It specifies a default privacy list fall-through action.</abstract>
<abstract>This document defines an XMPP protocol extension that enables clients to control how their servers may block SPIM that is addressed to them. It specifies a default privacy list fall-through action.</abstract>
&LEGALNOTICE;
<number>0159</number>
<status>Deferred</status>
@ -16,7 +16,7 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
@ -26,7 +26,7 @@
<version>0.1</version>
<date>2005-09-14</date>
<initials>ip</initials>
<remark>Initial JEP version.</remark>
<remark>Initial version.</remark>
</revision>
<revision>
<version>0.0.1</version>
@ -45,7 +45,7 @@
<li>Client implementations are simplified.</li>
<li>Client-to-server bandwidth is saved.</li>
<li>Consistency with the stanza blocking protocol specified by <cite>RFC 3921</cite>.</li>
<li>The use of interactive SPIM recognition techniques (like &jep0158;) does not leak information about the destination client's presence.</li>
<li>The use of interactive SPIM recognition techniques (like &xep0158;) does not leak information about the destination client's presence.</li>
<li>If the destination client is not online when the stanza is sent, then all SPIM would need to be stored by the server until the user comes back online to decide if it is SPIM.</li>
<li>Furthermore, if the sending client is no longer online when the stanza is received, then it would not be possible for the receiving client to use interactive SPIM recognition techniques.</li>
</ul>
@ -78,7 +78,7 @@
</section1>
<section1 topic='Discovery' anchor='disco'>
<p>A client MAY confirm that its server supports SPIM-Blocking Control using &jep0030;.</p>
<p>A client MAY confirm that its server supports SPIM-Blocking Control using &xep0030;.</p>
<example caption='Initial Service Discovery Information Request'><![CDATA[
<iq type='get'
from='victim@mydomain.com/laptop'
@ -222,15 +222,15 @@
</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='Well-Known Service Discovery Nodes' anchor='registrar-nodes'>
<p>Upon approval of this JEP, the <cite>Jabber Registrar</cite> shall register the following well-known Service Discovery node:</p>
<p>Upon approval of this document, the <cite>XMPP Registrar</cite> shall register the following well-known Service Discovery node:</p>
<ul>
<li>http://jabber.org/protocol/spim-control</li>
</ul>
</section2>
</section1>
</jep>
</xep>