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

JEP to XEP

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@29 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-03 22:46:54 +00:00
parent 068e45a04c
commit 89cf5ad3f4
10 changed files with 134 additions and 150 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

86
xep-0030.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>Service Discovery</title>
<abstract>This JEP defines a protocol for discovering (1) information about Jabber entities and (2) the items associated with such entities.</abstract>
<abstract>This document defines an XMPP protocol extension for discovering (1) information about Jabber entities and (2) the items associated with such entities.</abstract>
&LEGALNOTICE;
<number>0030</number>
<status>Final</status>
@ -17,18 +17,18 @@
<spec>XMPP Core</spec>
</dependencies>
<supersedes>
<spec>JEP-0011</spec>
<spec>JEP-0094</spec>
<spec>XEP-0011</spec>
<spec>XEP-0094</spec>
</supersedes>
<supersededby/>
<shortname>disco</shortname>
<schemaloc>
<ns>disco#info</ns>
<url>http://jabber.org/protocol/disco/info.xsd</url>
<url>http://www.xmpp.org/schemas/disco-info.xsd</url>
</schemaloc>
<schemaloc>
<ns>disco#items</ns>
<url>http://jabber.org/protocol/disco/items.xsd</url>
<url>http://www.xmpp.org/schemas/disco-items.xsd</url>
</schemaloc>
<registry/>
&hildjj;
@ -69,7 +69,7 @@
<version>1.8</version>
<date>2004-05-21</date>
<initials>psa</initials>
<remark>Moved remaining feature negotiation text to JEP-0020.</remark>
<remark>Moved remaining feature negotiation text to XEP-0020.</remark>
</revision>
<revision>
<version>1.7</version>
@ -99,7 +99,7 @@
<version>1.3</version>
<date>2004-04-23</date>
<initials>psa</initials>
<remark>Further clarified item-publication protocol; moved some feature negotiation text to JEP-0020; added information about registry of well-known service discovery nodes; added implementation notes regarding tree-walking and large result sets; incorporated additional Call for Experience suggestions.</remark>
<remark>Further clarified item-publication protocol; moved some feature negotiation text to XEP-0020; added information about registry of well-known service discovery nodes; added implementation notes regarding tree-walking and large result sets; incorporated additional Call for Experience suggestions.</remark>
</revision>
<revision>
<version>1.2</version>
@ -111,7 +111,7 @@
<version>1.1</version>
<date>2004-03-15</date>
<initials>psa</initials>
<remark>Described requirements, syntax, and use cases in a more formal manner; corrected several errors in the examples and schemas; defined Jabber Registrar procedures; added a number of references; specified XMPP error handling.</remark>
<remark>Described requirements, syntax, and use cases in a more formal manner; corrected several errors in the examples and schemas; defined XMPP Registrar procedures; added a number of references; specified XMPP error handling.</remark>
</revision>
<revision>
<version>1.0</version>
@ -141,7 +141,7 @@
<version>0.10</version>
<date>2002-11-21</date>
<initials>psa</initials>
<remark>Changed &lt;feature type='foo'/&gt; to &lt;feature var='foo'/&gt; to track changes in feature negotiation (JEP-0020); added initial registry parameters.</remark>
<remark>Changed &lt;feature type='foo'/&gt; to &lt;feature var='foo'/&gt; to track changes in feature negotiation (XEP-0020); added initial registry parameters.</remark>
</revision>
<revision>
<version>0.9</version>
@ -153,7 +153,7 @@
<version>0.8</version>
<date>2002-11-01</date>
<initials>psa</initials>
<remark>Removed the max, start, and total attributes for item queries (this will be handled by a generic paging JEP); added "http://jabber.org/protocol/feature-neg" namespace as a feature to signal negotiability regarding one or more features.</remark>
<remark>Removed the max, start, and total attributes for item queries (this will be handled by a generic paging protocol); added "http://jabber.org/protocol/feature-neg" namespace as a feature to signal negotiability regarding one or more features.</remark>
</revision>
<revision>
<version>0.7</version>
@ -165,7 +165,7 @@
<version>0.6</version>
<date>2002-10-27</date>
<initials>psa</initials>
<remark>Added the 'category' attribute to the &lt;feature/&gt; element; added security, IANA, and Jabber Registrar considerations; added a number of examples.</remark>
<remark>Added the 'category' attribute to the &lt;feature/&gt; element; added security, IANA, and XMPP Registrar considerations; added a number of examples.</remark>
</revision>
<revision>
<version>0.5</version>
@ -200,14 +200,14 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The ability to discover information about entities on the Jabber network is extremely valuable. Such information might include features offered or protocols supported by the entity, the entity's type or identity, and additional entities that are associated with the original entity in some way (often thought of as "children" of the "parent" entity). While mechanisms for doing so are not defined in &xmppcore;, several protocols have been used in the past within the Jabber community for service discovery, specifically &jep0011; and &jep0094;. However, those protocols are perceived to be inadequate for several reasons:</p>
<p>The ability to discover information about entities on the Jabber network is extremely valuable. Such information might include features offered or protocols supported by the entity, the entity's type or identity, and additional entities that are associated with the original entity in some way (often thought of as "children" of the "parent" entity). While mechanisms for doing so are not defined in &xmppcore;, several protocols have been used in the past within the Jabber community for service discovery, specifically &xep0011; and &xep0094;. However, those protocols are perceived to be inadequate for several reasons:</p>
<ol>
<li><p>Neither Jabber Browsing nor Agent Information is easily extensible. For example, the categories and subcategories listed for JID-Types in JEP-0011 are explicitly defined as the only official categories, and any additions to the list of JID-Types would require a modification to JEP-0011. While the Jabber Browsing specification does allow for the use of unofficial categories and types prefixed with the string 'x-', this introduces migration issues. This lack of flexibility violates one of the Jabber community's core &jep0134;.</p></li>
<li><p>Neither Jabber Browsing nor Agent Information is easily extensible. For example, the categories and subcategories listed for JID-Types in XEP-0011 are explicitly defined as the only official categories, and any additions to the list of JID-Types would require a modification to XEP-0011. While the Jabber Browsing specification does allow for the use of unofficial categories and types prefixed with the string 'x-', this introduces migration issues. This lack of flexibility violates one of the Jabber community's core &xep0134;.</p></li>
<li><p>In Agent Information, there is no way to advertise supported features. While Jabber Browsing includes such a mechanism, the only way to express the availability of a feature is to advertise a supported protocol namespace. Yet some features may not be uniquely associated with a protocol namespace, which are one implementation of features but not the only one.</p></li>
<li><p>A Jabber Browsing result returns a combination of (1) namespaces supported by a Jabber Entity, (2) items associated with a Jabber Entity, and (3) namespaces supported by the associated items. This approach mixes information levels and requires parents to know everything about child nodes, thereby introducing significant confusion.</p></li>
<li><p>In both Jabber Browsing and Agent Information, items must be addressable as JIDs; however, this may not be possible in some applications.</p></li>
</ol>
<p>This JEP addresses the perceived weaknesses of both the Jabber Browsing and Agent Information protocols. The result is a standards-track protocol for service discovery (often abbreviated to "disco", as is familiar in protocols such as &w3soap;).</p>
<p>This document addresses the perceived weaknesses of both the Jabber Browsing and Agent Information protocols. The result is a standards-track protocol for service discovery (often abbreviated to "disco", as is familiar in protocols such as &w3soap;).</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
@ -246,7 +246,7 @@
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<p>The target entity then MUST either return an IQ result, or return an error (see the <link url="#errors">Error Conditions</link> section of this document). The result MUST contain a &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/disco#info' namespace, which in turn contains one or more &lt;identity/&gt; elements and one or more &lt;feature/&gt; elements. (Note: Every entity MUST have at least one identity, and every entity MUST support at least the 'http://jabber.org/protocol/disco#info' feature; however, an entity is not required to return a result and MAY return an error, most likely &feature; or &unavailable;, although other error conditions may be appropriate.) Each &lt;identity/&gt; element MUST possess 'category' and 'type' attributes specifying the category and type for the entity, and MAY possess a 'name' attribute specifying a natural-language name for the entity. Each &lt;feature/&gt; element MUST possess a 'var' attribute whose value is a protocol namespace or other feature offered by the entity. Preferably, both the category/type values and the feature values will be registered in a public registry, as described in the <link url="#registrar">Jabber Registrar Considerations</link> section of this document.</p>
<p>The target entity then MUST either return an IQ result, or return an error (see the <link url="#errors">Error Conditions</link> section of this document). The result MUST contain a &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/disco#info' namespace, which in turn contains one or more &lt;identity/&gt; elements and one or more &lt;feature/&gt; elements. (Note: Every entity MUST have at least one identity, and every entity MUST support at least the 'http://jabber.org/protocol/disco#info' feature; however, an entity is not required to return a result and MAY return an error, most likely &feature; or &unavailable;, although other error conditions may be appropriate.) Each &lt;identity/&gt; element MUST possess 'category' and 'type' attributes specifying the category and type for the entity, and MAY possess a 'name' attribute specifying a natural-language name for the entity. Each &lt;feature/&gt; element MUST possess a 'var' attribute whose value is a protocol namespace or other feature offered by the entity. Preferably, both the category/type values and the feature values will be registered in a public registry, as described in the <link url="#registrar">XMPP Registrar Considerations</link> section of this document.</p>
<example caption='Result-set for information request'><![CDATA[
<iq type='result'
from='plays.shakespeare.lit'
@ -465,7 +465,7 @@
]]></example>
</section2>
<section2 topic='Items Nodes' anchor='items-nodes'>
<p>It is possible that an item associated with an entity will not be addressable as a JID; examples might include offline messages stored in an inbox (see &jep0013;), entries in a Jabber-enabled weblog, XML-RPC services associated with a client or component, items available in an online trading system (e.g., a catalog or auction), news postings located at an NNTP gateway, and topics hosted by a &jep0060; component. In order to handle such items, the &lt;item/&gt; element MAY possess an OPTIONAL 'node' attribute that supplements the REQUIRED 'jid' attribute.</p>
<p>It is possible that an item associated with an entity will not be addressable as a JID; examples might include offline messages stored in an inbox (see &xep0013;), entries in a Jabber-enabled weblog, XML-RPC services associated with a client or component, items available in an online trading system (e.g., a catalog or auction), news postings located at an NNTP gateway, and topics hosted by a &xep0060; component. In order to handle such items, the &lt;item/&gt; element MAY possess an OPTIONAL 'node' attribute that supplements the REQUIRED 'jid' attribute.</p>
<p>The value of the node attribute may or may not have semantic meaning; from the perspective of Service Discovery, a node is merely something that is associated with an entity. In order to discover more about the node, the requesting entity MUST query the entity's JID while specifying the node. If the value of the 'node' attribute has semantic meaning, that meaning is provided by the using protocol or application, not by the Service Discovery protocol. A node attribute SHOULD NOT be included unless it is necessary to provide or discover information about an entity that cannot be directly addressed as a JID (i.e., if the associated item can be addressed as a JID, do not include a node). The value of the 'node' attribute MUST NOT be null.</p>
<p>In the following example, a user requests all available items from an online catalog service:</p>
<example caption='Requesting nodes'><![CDATA[
@ -570,7 +570,7 @@
<li><p>Upon querying an entity (JID1+NodeID1) for items, one receives a list of items that cannot be addressed as JIDs; each associated item has its own JID+node, but no such JID+node equals JID1+NodeID1 and each NodeID is unique in the context of the associated JID.</p></li>
</ol>
<p>In addition, the results MAY also be mixed, so that a query to a JID or a JID+node could yield both (1) items that are addressed as JIDs and (2) items that are addressed as JID+node combinations.</p>
<p>Consider the case of an entity that owns multiple publish-subscribe nodes -- for example, a person who owns one such node for each of his music players. The following examples show what the disco#items query and result might look like (using the protocol defined in &jep0118;):</p>
<p>Consider the case of an entity that owns multiple publish-subscribe nodes -- for example, a person who owns one such node for each of his music players. The following examples show what the disco#items query and result might look like (using the protocol defined in &xep0118;):</p>
<example caption='User queries entity regarding tunes'><![CDATA[
<iq from='juliet@capulet.com/chamber'
id='items4'
@ -602,7 +602,7 @@
</section1>
<section1 topic='Publishing Available Items' anchor='publish'>
<p>The server handling rules defined in <strong>XMPP IM</strong> require that the server itself reply on behalf of the user if the 'to' attribute of an IQ get or set is of the form &lt;user@host&gt;. This functionality is currently employed so that the user can "publish" information (e.g., vCard information as specified in &jep0054;) in a way that makes it possible for other entities to retrieve that information even if the user is unavailable. The service discovery specification defined herein builds on that notion by enabling a user to publish some of its service discovery information to the server, which shall store that information in persistent storage and return that information when other entities request it from the user's "bare JID" (user@host), either alone or in combination with a particular node.</p>
<p>The server handling rules defined in <strong>XMPP IM</strong> require that the server itself reply on behalf of the user if the 'to' attribute of an IQ get or set is of the form &lt;user@host&gt;. This functionality is currently employed so that the user can "publish" information (e.g., vCard information as specified in &xep0054;) in a way that makes it possible for other entities to retrieve that information even if the user is unavailable. The service discovery specification defined herein builds on that notion by enabling a user to publish some of its service discovery information to the server, which shall store that information in persistent storage and return that information when other entities request it from the user's "bare JID" (user@host), either alone or in combination with a particular node.</p>
<p>Implementations of service discovery that are built into instant messaging servers SHOULD allow users to publish items in this fashion, although they are not required to do so in order to conform to the service discovery specification. In order to discover whether his or her server supports this publish functionality, the user SHOULD send a disco#info request to his or her server:</p>
<example caption="User sends disco#info request to server"><![CDATA[
<iq from='kinglear@shakespeare.lit'
@ -693,8 +693,8 @@
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>In order to retrieve full information about an entity and its associated items, the requesting application needs to "walk the tree" of items. Naturally, this can result in a large number of requests and responses. The requesting application SHOULD NOT send follow-up requests to all items associated with an entity if the list of such items is long (e.g., more than twenty items). Entities that will routinely host a large number of items (e.g., IRC gateways or NNTP services) SHOULD structure nodes into hierarchies and/or provide more robust searching capabilities, for example via &jep0055;; they SHOULD NOT return extremely large result sets via Service Discovery.</p>
<p>This JEP does not require that a responding entity must return the same results in response to the same request from different requesting entities (e.g., an entity could return a different list of items or features based on the degree to which it trusts the requesting entity, or based on the known capabilities of the requesting entity). However, the responding entity SHOULD return the same &lt;identity/&gt; element (category+type) to all disco#info requests sent to the same JID+node combination.</p>
<p>In order to retrieve full information about an entity and its associated items, the requesting application needs to "walk the tree" of items. Naturally, this can result in a large number of requests and responses. The requesting application SHOULD NOT send follow-up requests to all items associated with an entity if the list of such items is long (e.g., more than twenty items). Entities that will routinely host a large number of items (e.g., IRC gateways or NNTP services) SHOULD structure nodes into hierarchies and/or provide more robust searching capabilities, for example via &xep0055;; they SHOULD NOT return extremely large result sets via Service Discovery.</p>
<p>This document does not require that a responding entity must return the same results in response to the same request from different requesting entities (e.g., an entity could return a different list of items or features based on the degree to which it trusts the requesting entity, or based on the known capabilities of the requesting entity). However, the responding entity SHOULD return the same &lt;identity/&gt; element (category+type) to all disco#info requests sent to the same JID+node combination.</p>
</section1>
<section1 topic='Error Conditions' anchor='errors'>
@ -712,7 +712,7 @@
</iq>
]]></example>
<p>Other error conditions may be appropriate depending on the application.</p>
<p>The following table summarizes the common error conditions that can have special meaning in the context of Service Discovery (for information regarding error condition syntax and semantics, see &jep0086;).</p>
<p>The following table summarizes the common error conditions that can have special meaning in the context of Service Discovery (for information regarding error condition syntax and semantics, see &xep0086;).</p>
<table caption='Error Conditions'>
<tr>
<th>Condition</th>
@ -757,15 +757,15 @@
</ol>
</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-protocol'>
<p>The &REGISTRAR; includes the 'http://jabber.org/protocol/disco#info' and 'http://jabber.org/protocol/disco#items' namespaces in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Registries' anchor='registrar-reg'>
<section3 topic='Identity Categories and Types Registry' anchor='registrar-reg-identity'>
<p>The Jabber Registrar shall maintain a registry of values for the 'category' and 'type' attributes of the &lt;identity/&gt; element in the 'http://jabber.org/protocol/disco#info' namespace; see &lt;<link url="http://www.jabber.org/registrar/disco-categories.html">http://www.jabber.org/registrar/disco-categories.html</link>&gt;.</p>
<p>The XMPP Registrar shall maintain a registry of values for the 'category' and 'type' attributes of the &lt;identity/&gt; element in the 'http://jabber.org/protocol/disco#info' namespace; see &lt;<link url="http://www.jabber.org/registrar/disco-categories.html">http://www.jabber.org/registrar/disco-categories.html</link>&gt;.</p>
<section4 topic='Process' anchor='registrar-identity'>
&REGPROCESS;
<code><![CDATA[
@ -775,14 +775,14 @@
<type>
<name>the name of the specific type (all lower-case)</name>
<desc>a natural-language description of the type</desc>
<doc>the document (e.g., JEP) in which this type is specified</doc>
<doc>the document (e.g., XEP) in which this type is specified</doc>
</type>
</category>
]]></code>
<p>The registrant may register more than one category at a time, each contained in a separate &lt;category/&gt; element. The registrant may also register more than one type at a time, each contained in a separate &lt;type/&gt; child element. Registrations of new types within an existing category must include the full XML snippet but should not include the category description (only the name).</p>
</section4>
<section4 topic='Initial Submission' anchor='registrar-reg-identity-init'>
<p>This JEP defines a "hierarchy" category that contains two and only two types: "branch" and "leaf"; the associated registry submission is as follows:</p>
<p>This document defines a "hierarchy" category that contains two and only two types: "branch" and "leaf"; the associated registry submission is as follows:</p>
<code><![CDATA[
<category>
<name>hierarchy</name>
@ -796,7 +796,7 @@
A "container node" for other entities in a
service discovery node hierarchy.
</desc>
<doc>JEP-0030</doc>
<doc>XEP-0030</doc>
</type>
<type>
<name>leaf</name>
@ -804,42 +804,42 @@
A "terminal node" in a service discovery
node hierarchy.
</desc>
<doc>JEP-0030</doc>
<doc>XEP-0030</doc>
</type>
</category>
]]></code>
</section4>
</section3>
<section3 topic='Features Registry' anchor='registrar-reg-features'>
<p>The Jabber Registrar shall maintain a registry of features for use as values of the 'var' attribute of the &lt;feature/&gt; element in the 'http://jabber.org/protocol/disco#info' namespace; see &lt;<link url="http://www.jabber.org/registrar/disco-vars.html">http://www.jabber.org/registrar/disco-vars.html</link>&gt;.</p>
<p>The XMPP Registrar shall maintain a registry of features for use as values of the 'var' attribute of the &lt;feature/&gt; element in the 'http://jabber.org/protocol/disco#info' namespace; see &lt;<link url="http://www.jabber.org/registrar/disco-vars.html">http://www.jabber.org/registrar/disco-vars.html</link>&gt;.</p>
<section4 topic='Process' anchor='registrar-reg-features-process'>
&REGPROCESS;
<code><![CDATA[
<feature var='name of feature or namespace'>
<desc>a natural-language description of the feature</desc>
<doc>the document (e.g., JEP) in which this feature is specified</doc>
<doc>the document (e.g., XEP) in which this feature is specified</doc>
</feature>]]></code>
<p>The registrant may register more than one feature at a time, each contained in a separate &lt;feature/&gt; element.</p>
</section4>
<section4 topic='Initial Submission' anchor='registrar-reg-features-init'>
<p>This JEP defines a "publish" feature that is not associated with either of the protocol namespaces listed above; the registry submission for this feature is as follows:</p>
<p>This document defines a "publish" feature that is not associated with either of the protocol namespaces listed above; the registry submission for this feature is as follows:</p>
<code><![CDATA[
<feature var='http://jabber.org/protocol/disco#publish'>
<desc>the service discovery "publish" feature</desc>
<doc>JEP-0030</doc>
<doc>XEP-0030</doc>
</feature>
]]></code>
</section4>
</section3>
<section3 topic='Well-Known Nodes' anchor='registrar-reg-nodes'>
<p>A using protocol may specify one or more service discovery nodes that have a special and well-defined meaning in the context of that protocol. For the purpose of reserving these node names globally across all Jabber protocols, the Jabber Registrar shall maintain a registry of well-known service discovery nodes; see &lt;<link url="http://www.jabber.org/registrar/disco-nodes.html">http://www.jabber.org/registrar/disco-nodes.html</link>&gt;.</p>
<p>A using protocol may specify one or more service discovery nodes that have a special and well-defined meaning in the context of that protocol. For the purpose of reserving these node names globally across all Jabber protocols, the XMPP Registrar shall maintain a registry of well-known service discovery nodes; see &lt;<link url="http://www.jabber.org/registrar/disco-nodes.html">http://www.jabber.org/registrar/disco-nodes.html</link>&gt;.</p>
<section4 topic='Process' anchor='registrar-reg-nodes-process'>
&REGPROCESS;
<code><![CDATA[
<node>
<name>the name of the node</name>
<desc>a natural-language description of the node</desc>
<doc>the document (e.g., JEP) in which this node is specified</doc>
<doc>the document (e.g., XEP) in which this node is specified</doc>
</node>
]]></code>
<p>The registrant may register more than one node at a time, each contained in a separate &lt;node/&gt; element.</p>
@ -847,7 +847,7 @@
</section3>
</section2>
<section2 topic='URI Query Types' anchor='registrar-querytypes'>
<p>As authorized by &jep0147;, the Jabber Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).</p>
<p>As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).</p>
<p>The "disco" querytype is defined herein for service discovery interactions, with three keys: (1) "node" (the optional node to query), (2) "request" (with values of "info" to retrieve service discovery information and "items" to retrieve service discovery items), and (3) "type" (with values of "get" for IQ-gets and "set" for IQ-sets).</p>
<example caption='Service Discovery Information Request: IRI/URI'><![CDATA[
xmpp:romeo@montague.net?disco;type=get;request=info
@ -871,7 +871,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items
<name>disco</name>
<proto>http://jabber.org/protocol/disco</proto>
<desc>enables interaction for the purpose of service discovery</desc>
<doc>JEP-0030</doc>
<doc>XEP-0030</doc>
<keys>
<key>
<name>node</name>
@ -925,7 +925,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0030: http://www.jabber.org/jeps/jep-0030.html
XEP-0030: http://www.xmpp.org/extensions/xep-0030.html
</xs:documentation>
</xs:annotation>
@ -983,7 +983,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0030: http://www.jabber.org/jeps/jep-0030.html
XEP-0030: http://www.xmpp.org/extensions/xep-0030.html
</xs:documentation>
</xs:annotation>
@ -1029,4 +1029,4 @@ xmpp:romeo@montague.net?disco;type=get;request=items
<section1 topic='Author Note' anchor='authornote'>
<p>Peter Millard, a co-author of this specification from version 0.1 through version 2.2, died on April 26, 2006.</p>
</section1>
</jep>
</xep>

10
xep-0031.xml
View File

@ -1,11 +1,11 @@
<?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'?>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<jep>
<xep>
<header>
@ -2325,4 +2325,4 @@ more to be added
</section1>
</jep>
</xep>

36
xep-0032.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 URI Scheme</title>
<abstract>A URI scheme for Jabber communications.</abstract>
@ -15,19 +15,9 @@
<jig>Standards JIG</jig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby>draft-saintandre-xmpp-uri</supersededby>
<author>
<firstname>Peter</firstname>
<surname>Saint-Andre</surname>
<email>stpeter@jabber.org</email>
<jid>stpeter@jabber.org</jid>
</author>
<author>
<firstname>Peter</firstname>
<surname>Millard</surname>
<email>me@pgmillard.com</email>
<jid>pgmillard@jabber.org</jid>
</author>
<supersededby><spec>RFC 4622</spec></supersededby>
&stpeter;
&pgmillard;
<revision>
<version>0.4</version>
<date>2003-09-02</date>
@ -54,7 +44,8 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>It is widely acknowledged that it would be good to be able to express a Jabber Identifier (JID) <note>Jabber Identifiers are formally defined in JEP-0029: <link url='http://www.jabber.org/jeps/jep-0029.html'>http://www.jabber.org/jeps/jep-0029.html</link>.</note> as a Uniform Resource Identifier (see &rfc3986;). In addition, there would be value in being able to interact with a JID through a URI scheme (e.g., by sending a message or a presence update).</p>
<p><em>Note: This document has been superseded by &rfc4622;.</em></p>
<p>It is widely acknowledged that it would be good to be able to express a Jabber Identifier (JID) (see &xep0029;) as a Uniform Resource Identifier (see &rfc3986;). In addition, there would be value in being able to interact with a JID through a URI scheme (e.g., by sending a message or a presence update).</p>
<p>Although XMPP enables a wide range of functionality, the authors propose that a Jabber URI scheme needs to support only a limited subset of the possible Jabber functionality. In particular, we see the following as core functions that need to be supported:</p>
<ul>
<li>Sending of basic messages</li>
@ -66,7 +57,7 @@
<p>The syntactic components of a Jabber URI are as follows:</p>
<code>&lt;xmpp&gt;:[&lt;node-identifier&gt;@]&lt;domain-identifier&gt;[?&lt;query&gt;]</code>
<p>This scheme is similar to the mailto URI scheme <note>The mailto URI scheme is described in RFC 2368: <link url='http://www.ietf.org/rfc/rfc2368.txt'>http://www.ietf.org/rfc/rfc2368.txt</link>.</note>. One similarity is that a Jabber URI is, in the terminology of RFC 3986, not hierarchical but opaque. A URI that is hierarchical in nature uses the slash ("/") character in order to separate hierarchical components, as is familiar from HTTP and FTP URIs. By contrast, an opaque URI such as a mailto URI contains only the scheme (e.g., 'mailto'), a colon, an address (e.g., 'user@host'), and an optional query component.</p>
<p>Per the JID definition in JEP-0029, the node identifier is optional (i.e., a mere domain identifier is a valid JID). However, the proposed Jabber URI scheme forbids the inclusion of a resource identifier in the JID, even though JEP-0029 defines this as valid. This is partly because the authors see no compelling reason to include a resource identifier in the Jabber URI scheme, and also because including a resource would necessitate the inclusion of a slash character in an opaque URI, which is contrary to RFC 3986. Finally, the query component is optional.</p>
<p>Per the JID definition in XEP-0029, the node identifier is optional (i.e., a mere domain identifier is a valid JID). However, the proposed Jabber URI scheme forbids the inclusion of a resource identifier in the JID, even though XEP-0029 defines this as valid. This is partly because the authors see no compelling reason to include a resource identifier in the Jabber URI scheme, and also because including a resource would necessitate the inclusion of a slash character in an opaque URI, which is contrary to RFC 3986. Finally, the query component is optional.</p>
</section1>
<section1 topic='URI Characters and Escape Sequences'>
<p>RFC 3986 limits the characters included in a URI to US-ASCII characters, and further defines a number of US-ASCII characters as reserved or otherwise excluded. Reserved characters are special characters used as delimiters withing URIs and whose usage is limited to their reserved purpose as defined in RFC 3986 or a specific URI scheme. Excluded characters are control characters, spaces, and other common (non-URI-specific) delimiters such as angle brackets, double quotes, the number sign, and the percent sign. Reserved characters must be escaped if their usage in a specific context would conflict with their reserved purpose, and excluded characters must always be escaped. The set of disallowed charaacters for any specific URI component consists of the reserved and excluded characters for that component. These are defined below for each component of a Jabber URI.</p>
@ -74,7 +65,7 @@
<p>The scheme component for a Jabber URI is 'xmpp'. This component is delimited from the remainder of the URI by a colon character (':').</p>
</section2>
<section2 topic='Node Identifier Component'>
<p>The node identifier component of a Jabber URI is equivalent to the "userinfo" component of a generic URI. Section 2.3 of JEP-0029 stipulates that a node identifier may contain any Unicode character higher than #x20 with the exception of the following:</p>
<p>The node identifier component of a Jabber URI is equivalent to the "userinfo" component of a generic URI. Section 2.3 of XEP-0029 stipulates that a node identifier may contain any Unicode character higher than #x20 with the exception of the following:</p>
<code>#x22 (") | #x26 (&amp;) | #x27 (') | #x2F (/) |
#x3A (:) | #x3C (&lt;) | #x3E (&gt;) | #x40 (@) |
#x7F (del) | #xFFFE (BOM) | #xFFFF (BOM)</code>
@ -155,4 +146,7 @@ xmpp:user@host?subscribe&amp;type=unsubscribed
</example>
</section2>
</section1>
</jep>
<section1 topic='Author Note' anchor='authornote'>
<p>Peter Millard, co-author of this specification from version 0.1 through version 0.4, died on April 26, 2006.</p>
</section1>
</xep>

34
xep-0033.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0'?>
<!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 Stanza Addressing</title>
<abstract>This document specifies an XMPP protocol extension that enables entities to include RFC822-style address headers within XMPP stanzas in order to specify multiple recipients or sub-addresses.</abstract>
@ -15,13 +15,13 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>address</shortname>
<schemaloc>
<url>http://jabber.org/protocol/address/address.xsd</url>
<url>http://www.xmpp.org/schemas/address.xsd</url>
</schemaloc>
&hildjj;
&stpeter;
@ -37,7 +37,7 @@
<version>1.0</version>
<date>2004-05-10</date>
<initials>psa</initials>
<remark>Per a vote of the Jabber Council, advanced status to Draft; also added Security Considerations in consultation with JEP author.</remark>
<remark>Per a vote of the Jabber Council, advanced status to Draft; also added Security Considerations in consultation with author.</remark>
</revision>
<revision>
@ -88,7 +88,7 @@
level of nesting, since addresses are the only block left.
Made it clearer that the session manager can implement
multicast directly. Removed infobits (needs to be a
separate JEP). Reworked the examples to be more correct.
separate specification). Reworked the examples to be more correct.
Added reply handling rules. Added schema.</remark>
</revision>
@ -133,10 +133,10 @@
<section1 topic='Introduction' anchor='intro'>
<p>On the existing Jabber network, there are many opportunities to optimize stanza traffic. For example, clients that want to send the same stanza to multiple recipients currently must send multiple stanzas. Similarly, when a user comes online the server sends many nearly-identical presence stanzas to remote servers.</p>
<p>The 'http://jabber.org/protocol/address' specification provides a method for both clients and servers to send a single stanza and have it be delivered to multiple recipients, similar to that found in &rfc0822;. As a side-effect, it also provides all of the functionality specified by the old 'jabber:x:envelope' <note><link url='http://www.jabber.org/old-docs/proto-draft/envelope.html'>jabber:x:envelope</link> - Message Envelope Information Extension</note> proposal, which this JEP can supersede.</p>
<p>The 'http://jabber.org/protocol/address' specification provides a method for both clients and servers to send a single stanza and have it be delivered to multiple recipients, similar to that found in &rfc0822;. As a side-effect, it also provides all of the functionality specified by the old 'jabber:x:envelope' <note><link url='http://www.jabber.org/old-docs/proto-draft/envelope.html'>jabber:x:envelope</link> - Message Envelope Information Extension</note> proposal, which this XEP can supersede.</p>
</section1>
<section1 topic='Discovering Server Support' anchor='disco'>
<p>Support for Extended Stanza Addressing in a given server instance SHOULD be determined using &jep0030;. A conforming server MUST respond to disco#info requests.</p>
<p>Support for Extended Stanza Addressing in a given server instance SHOULD be determined using &xep0030;. A conforming server MUST respond to disco#info requests.</p>
<section2 topic='Disco to determine support' anchor='disco-support'>
<p>To determine if a server or service supports Extended Stanza Addressing, the requesting entity SHOULD send a disco#info request to it.</p>
@ -263,7 +263,7 @@
<p>This is the address to which all replies are requested to be sent. Clients SHOULD respect this request unless an explicit override occurs. There MAY be more than one replyto or replyroom on a stanza, in which case the reply stanza MUST be routed to all of the addresses.</p>
</section3>
<section3 topic="Address type='replyroom'" anchor='addr-type-replyroom'>
<p>This is the JID of a &jep0045; room to which responses should be sent. When a user wants to reply to this stanza, the client SHOULD join this room first. Clients SHOULD respect this request unless an explicit override occurs. There MAY be more than one replyto or replyroom on a stanza, in which case the reply stanza MUST be routed to all of the addresses.</p>
<p>This is the JID of a &xep0045; room to which responses should be sent. When a user wants to reply to this stanza, the client SHOULD join this room first. Clients SHOULD respect this request unless an explicit override occurs. There MAY be more than one replyto or replyroom on a stanza, in which case the reply stanza MUST be routed to all of the addresses.</p>
</section3>
<section3 topic="Address type='noreply'" anchor='addr-type-noreply'>
<p>This address type contains no actual address information. Instead, it means that the receiver SHOULD NOT reply to the message. This is useful when broadcasting messages to many receivers.</p>
@ -271,7 +271,7 @@
</section2>
<section2 topic="Extensibility" anchor='extensibility'>
<p>As specified herein, the &lt;address/&gt; element is empty. Implementations or future protocols MAY extend the &lt;address/&gt; element for additional functionality, but any extensions are out of scope for this JEP. Such extensions SHOULD be appropriately qualified with a new namespace, and any extensions that are not understood by an implementation MUST be ignored.</p>
<p>As specified herein, the &lt;address/&gt; element is empty. Implementations or future protocols MAY extend the &lt;address/&gt; element for additional functionality, but any extensions are out of scope for this XEP. Such extensions SHOULD be appropriately qualified with a new namespace, and any extensions that are not understood by an implementation MUST be ignored.</p>
<example caption='Possible future extension'><![CDATA[<message to='groups.jabber.org'>
<addresses xmlns='http://jabber.org/protocol/address'>
@ -566,7 +566,7 @@
</section1>
<section1 topic='Error Conditions' anchor='errors'>
<p>The following error conditions are to be used by implementations (for further information regarding error syntax, see &jep0086;):</p>
<p>The following error conditions are to be used by implementations (for further information regarding error syntax, see &xep0086;):</p>
<table caption='Error Conditions'>
<tr>
<th>XMPP Condition</th>
@ -592,9 +592,9 @@
<p>Furthermore, there exists the potential for abuse related to the 'replyto' and 'replyroom' features (e.g., an entity could send messages with 'replyroom' set to the address of a room that hosts salacious content or with 'replyto' set to the address of a spambot that harvests Jabber addresses). Therefore if a human user's receiving application receives a message with extended stanza addressing that specifies a 'replyto' or 'replyroom' address other than that of the sender, it SHOULD inform the user of that fact. (Naturally, the receiving application MAY also limit the entities to which the recipient can reply using privacy lists as specified in &xmppim;.)</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/address' in its registry of protocol namespaces.</p>
</section1>
@ -611,7 +611,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0033: http://www.jabber.org/jeps/jep-0033.html
XEP-0033: http://www.xmpp.org/extensions/xep-0033.html
</xs:documentation>
</xs:annotation>
@ -664,4 +664,4 @@
<section1 topic='Acknowledgements' anchor='ack'>
<p>Sections of this document were inspired by RFC 822.</p>
</section1>
</jep>
</xep>

14
xep-0034.xml
View File

@ -1,15 +1,15 @@
<?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'?>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<jep>
<xep>
<header>
<title>SASL Integration</title>
<abstract>NOTE WELL: this JEP was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.</abstract>
<abstract>NOTE WELL: this specification was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.</abstract>
&LEGALNOTICE;
<number>0034</number>
<status>Retracted</status>
@ -41,7 +41,7 @@
<version>1.1</version>
<date>2003-11-05</date>
<initials>psa</initials>
<remark>The status of this JEP has been changed to Retracted since it has been superseded by &xmppcore;. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
<remark>The status of this specification has been changed to Retracted since it has been superseded by &xmppcore;. This specification will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
</revision>
<revision>
<version>1.0</version>
@ -246,4 +246,4 @@ S: &lt;iq id=&quot;a2&quot; type=&quot;result&quot;&gt;
</section2>
</section1>
</jep>
</xep>

14
xep-0035.xml
View File

@ -1,11 +1,11 @@
<?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'?>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<jep>
<xep>
<header>
<title>SSL/TLS Integration</title>
@ -119,11 +119,11 @@ S: &lt;stream:stream xmlns=&apos;jabber:client&apos;
</section1>
<section1 topic="Certificate-based authentication">
<p>TLS allows clients to be authenticated by verifying the certificate that they present during the TLS negotiation. This can be done in conjunction with the Jabber SASL profile <note><link url="http://www.jabber.org/jeps/jep-0034.html">JEP-0034</link></note> and the EXTERNAL mechanism.</p>
<p>TLS allows clients to be authenticated by verifying the certificate that they present during the TLS negotiation. This can be done in conjunction with the Jabber SASL profile (see &xep0034;) and the EXTERNAL mechanism.</p>
<p>If a client authenticates with a certificate using the TLS authentication, and the client requests the use of SASL in the second XML stream negotiation (over the secure channel), servers supporting certificate-based authentication should add the EXTERNAL mechanism to the list of supported authentication mechanisms. If the client then requests this mechanism, the server should automatically inform the user that authentication was successful. See <link url="http://www.ietf.org/rfc/rfc2222">RFC 2222</link> and <link url="http://www.jabber.org/jeps/jep-0034.html">JEP-0034</link> for more information.</p>
<p>If a client authenticates with a certificate using the TLS authentication, and the client requests the use of SASL in the second XML stream negotiation (over the secure channel), servers supporting certificate-based authentication should add the EXTERNAL mechanism to the list of supported authentication mechanisms. If the client then requests this mechanism, the server should automatically inform the user that authentication was successful. See &rfc2222; and <cite>JEP-0034</cite> for more information.</p>
<p>Servers implementing STARTTLS functionality are not required to implement certificate-based authentication.</p>
</section1>
</jep>
</xep>

36
xep-0036.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>Pub-Sub Subscriptions</title>
<abstract>A proposal for the subscribe half of a publish-subscribe protocol within Jabber.</abstract>
@ -14,25 +14,15 @@
<type>Standards Track</type>
<jig>Standards</jig>
<supersedes>None</supersedes>
<supersededby>JEP-0060</supersededby>
<supersededby>XEP-0060</supersededby>
<shortname>None</shortname>
<author>
<firstname>Peter</firstname>
<surname>Millard</surname>
<email>pgmillard@jabber.org</email>
<jid>pgmillard@jabber.org</jid>
</author>
<author>
<firstname>Peter</firstname>
<surname>Saint-Andre</surname>
<email>stpeter@jabber.org</email>
<jid>stpeter@jabber.org</jid>
</author>
&pgmillard;
&stpeter;
<revision>
<version>0.2</version>
<date>2003-04-22</date>
<initials>psa</initials>
<remark>At the request of the authors, the status of this JEP has been changed to Retracted since it has been superseded by JEP-0060. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
<remark>At the request of the authors, the status of this specification has been changed to Retracted since it has been superseded by XEP-0060. This specification will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
</revision>
<revision>
<version>0.1</version>
@ -42,7 +32,7 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>The Jabber community needs a cohesive standard for publish-subscribe functionality. Certainly there is interest in developing such a standard, as witness the number of JEPs written on this topic. <note><link url='http://www.jabber.org/jeps/jep-0021.html'>JEP-0021</link>, <link url='http://www.jabber.org/jeps/jep-0024.html'>JEP-0024</link>, <link url='http://www.jabber.org/jeps/jep-0028.html'>JEP-0028</link>.</note> Unfortunately, past discussion of this issue has been clouded by confusion over requirements and even terminology. This JEP seeks to clarify the situation somewhat and to provide a protocol for the subscribe half of publish-subscribe functionality within Jabber.</p>
<p>The Jabber community needs a cohesive standard for publish-subscribe functionality. Certainly there is interest in developing such a standard, as witness the number of proposals written on this topic (&xep0021;, &xep0024;, XEP-0028). Unfortunately, past discussion of this issue has been clouded by confusion over requirements and even terminology. This XEP seeks to clarify the situation somewhat and to provide a protocol for the subscribe half of publish-subscribe functionality within Jabber.</p>
</section1>
<section1 topic='Narrative'>
<p>Traditional pub-sub consists of event notification. This makes it possible for entities to publish data and for other interested entities to receive notification when the data is published. The following are some likely applications of pub-sub functionality within Jabber:</p>
@ -60,7 +50,7 @@
<li>A list of subscribers to items that fit the description</li>
<li>One or more items that fit the description</li>
</ol>
<p>We define an "item" as an instance of data published by the publisher that fits the description associated with a topic. Each item MAY possess a unique identifier that enables the data to be tracked. (NOTE: This JEP does not address the durability of items, i.e., data storage.)</p>
<p>We define an "item" as an instance of data published by the publisher that fits the description associated with a topic. Each item MAY possess a unique identifier that enables the data to be tracked. (NOTE: This XEP does not address the durability of items, i.e., data storage.)</p>
<p>A topic is addressed by means of a unique "topic ID". A topic ID is simply a string with no required semantic meaning. While a topic ID may have semantic meaning (e.g., '/instruments/guitars/electric' or 'rec.music.dylan'), such meaning is not necessary and a topic ID may be any random string (e.g., 'a1gh83jfn342092'). The only requirement is that a topic ID be unique within the context of a specific pub-sub domain (e.g., pubsub.jabber.org).</p>
</section1>
<section1 topic='Protocol Details'>
@ -123,4 +113,8 @@
</section1>
</jep>
<section1 topic='Author Note' anchor='authornote'>
<p>Peter Millard, co-author of this specification, died on April 26, 2006.</p>
</section1>
</xep>

10
xep-0037.xml
View File

@ -1,9 +1,9 @@
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<jep>
<xep>
<header>
<title>DSPS - Data Stream Proxy Service</title>
<abstract>A proposal for proxy support in Jabber.</abstract>
@ -845,4 +845,4 @@ this is the data in ASCII form
</section1>
</jep>
</xep>

16
xep-0038.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>Icon Styles</title>
<abstract>A protocol for specifying exchangeable styles of emoticons and genicons within Jabber IM clients.</abstract>
@ -82,7 +82,7 @@
</section1>
<section1 topic='Specification'>
<p>Because icons in Jabber should be easy to use, extensible, and customizable, they will be created using style definition files which can be exchanged between users and supporting clients. The specification will not require external data, in order to protect the privacy of users, and will not rely on file transfers or directory services in order to not break old clients or components. How these icon styles are exchanged - as well as advertised - is out of the scope of this specification. The text strings representing the icons will be sent like any other text (this JEP doesn't require extra tags or attributes in the messages being sent).</p>
<p>Because icons in Jabber should be easy to use, extensible, and customizable, they will be created using style definition files which can be exchanged between users and supporting clients. The specification will not require external data, in order to protect the privacy of users, and will not rely on file transfers or directory services in order to not break old clients or components. How these icon styles are exchanged - as well as advertised - is out of the scope of this specification. The text strings representing the icons will be sent like any other text (this document doesn't require extra tags or attributes in the messages being sent).</p>
<p>All icons are created by defining each icon then grouping them together into "Icon Definition Files". These files, along with the object files associated with the icons, are called "icon styles". Icon styles may be traded and shared among users of all supporting clients like skins or themes, similar to WinAmp, XMMS, GNOME, and other customizable applications. This creates a platform-independent system, providing a great degree of customization for the user, and allowing client developers to focus on other features.</p>
<section2 topic="Definition File">
@ -358,8 +358,4 @@
</ol>
</section1>
</jep>
</xep>

28
xep-0039.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>Statistics Gathering</title>
<abstract>A protocol to enable gathering statistics from Jabber servers and components.</abstract>
@ -45,7 +45,7 @@
to me by amoungst others Rob Norris that things such as lists of JIDs
and lists in general are really the province of disco and browse and
that at least one of the suggested 'core' statistics doesn't
make sense for all components so removed these from the JEP. This namespace
make sense for all components so removed these from the document. This namespace
was starting to become a generic data gathering namespace and we already
have one of those, so i've reworked yet again hopefully for the
final time it should now be simpler to implement and more consistent in
@ -55,7 +55,7 @@
<version>0.5.0</version>
<date>2002-11-03</date>
<initials>rkd</initials>
<remark>Heavily modified JEP according to suggestions from Matt Miller (linuxwolf). rkd had some additional thoughts on the name attribute, this version reflects those. Reorganized the description section.</remark>
<remark>Heavily modified document according to suggestions from Matt Miller (linuxwolf). rkd had some additional thoughts on the name attribute, this version reflects those. Reorganized the description section.</remark>
</revision>
<revision>
<version>0.4.2</version>
@ -84,7 +84,7 @@
optionally return data in a human readable format. It is nothing
more than a bit of visual fluff but it has potential to be quite
useful. Renumbered the revisions to allow room for stpeter's new
JEP numbering scheme, sorry if it is now confusing but I hadn't
document numbering scheme, sorry if it is now confusing but I hadn't
left much room to grow with the previous revision numbering. A
little more prettying and judicious use of punctuation has occurred.</remark>
</revision>
@ -103,7 +103,7 @@
fixed that now. Clarified error codes and reworked how errors
are indicated to work with the new generic
namespace. Rearranged the order of the sections a bit make this
JEP a more linear read.</remark>
document a more linear read.</remark>
</revision>
<revision>
<version>0.2</version>
@ -112,7 +112,7 @@
<remark>Complete reworking to take into account suggestions made
by Ryan Eatmon and others. Ryan Eatmon added to list of authors to
reflect his significant contribution to the current form of this
JEP. I have also received a few comments that this document
document. I have also received a few comments that this document
previously read like an IETF document. Whether that was a good or
bad thing I was unable to ascertain but I've tried to lighten the
tone a little.</remark>
@ -158,13 +158,13 @@
<initials>rkd</initials>
<remark>Initial version.</remark>
</revision>
<dependencies>JEP-0053 (JANA)</dependencies>
<dependencies>XEP-0053</dependencies>
</header>
<section1 topic='Introduction'>
<p>As things currently stand it is not possible to obtain statistics
from a jabber component or server without resorting to parsing the
various log files. This makes it extremely difficult to obtain statistics
that are of any use in real world situations. This JEP attempts to
that are of any use in real world situations. This document attempts to
rectify this situation by defining a new namespace that would be used
to obtain statistics from a component or server so that they may be
manipulated and used in a useful manner. For the purposes of this namespace
@ -317,7 +317,7 @@
researching to ensure that their desired name is not already
in use and that they adequately document the returned units
type and anything else that would normally be registered.
Hopefully by the time this JEP is formally adopted
Hopefully by the time this document is formally adopted
a central naming authority for the Jabber protocol will be in
place and functional and authors will be then able to register
their names.
@ -369,7 +369,7 @@
statistic is and in what units the value is returned. However if the
application really wants some form of human readable label for the
returned value although not an optimal solution or even recommended by
the authors of this JEP it should be safe for
the authors of this document it should be safe for
it to convert the value of the units attribute into a string and use
that as a label for the returned statistic value.</p>
</section2>
@ -423,4 +423,4 @@
TBD
</section2>
</section1>
</jep>
</xep>