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@34 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-03 23:25:20 +00:00
parent 7a35010424
commit fe1d5643e8
10 changed files with 209 additions and 209 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

206
xep-0060.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;
<!ENTITY ITEM "&lt;item/&gt;">
<!ENTITY ITEMS "&lt;items/&gt;">
<!ENTITY PUBSUB "&lt;pubsub/&gt;">
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Publish-Subscribe</title>
<abstract>This document specifies an XMPP protocol extension for generic publish-subscribe functionality.</abstract>
@ -18,30 +18,30 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0004</spec>
<spec>JEP-0030</spec>
<spec>JEP-0068</spec>
<spec>JEP-0082</spec>
<spec>JEP-0131</spec>
<spec>XEP-0004</spec>
<spec>XEP-0030</spec>
<spec>XEP-0068</spec>
<spec>XEP-0082</spec>
<spec>XEP-0131</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>pubsub</shortname>
<schemaloc>
<ns>pubsub</ns>
<url>http://jabber.org/protocol/pubsub/pubsub.xsd</url>
<url>http://www.xmpp.org/schemas/pubsub.xsd</url>
</schemaloc>
<schemaloc>
<ns>pubsub#errors</ns>
<url>http://jabber.org/protocol/pubsub/errors.xsd</url>
<url>http://www.xmpp.org/schemas/pubsub-errors.xsd</url>
</schemaloc>
<schemaloc>
<ns>pubsub#event</ns>
<url>http://jabber.org/protocol/pubsub/event.xsd</url>
<url>http://www.xmpp.org/schemas/pubsub-event.xsd</url>
</schemaloc>
<schemaloc>
<ns>pubsub#owner</ns>
<url>http://jabber.org/protocol/pubsub/owner.xsd</url>
<url>http://www.xmpp.org/schemas/pubsub-owner.xsd</url>
</schemaloc>
&pgmillard;
@ -137,7 +137,7 @@
<version>1.5</version>
<date>2004-07-07</date>
<initials>pgm/psa</initials>
<remark><p>Fixed typos. Added more details to the section on collections. Added paragraph to create node use case to allow the service to change the requested node-id to something which it creates. Added text about bouncing publish requests when the request does not match the event-type for that node. Added disco features for the jabber registrar. Changed affiliation verbiage to allow publishers to remove any item. Tweaked verbiage for create node, eliminated extra example. Fully defined Jabber Registrar submissions. Corrected schemas.</p></remark>
<remark><p>Fixed typos. Added more details to the section on collections. Added paragraph to create node use case to allow the service to change the requested node-id to something which it creates. Added text about bouncing publish requests when the request does not match the event-type for that node. Added disco features for the jabber registrar. Changed affiliation verbiage to allow publishers to remove any item. Tweaked verbiage for create node, eliminated extra example. Fully defined XMPP Registrar submissions. Corrected schemas.</p></remark>
</revision>
<revision>
<version>1.4</version>
@ -161,7 +161,7 @@
<version>1.1</version>
<date>2004-01-14</date>
<initials>psa</initials>
<remark><p>Added Jabber Registrar Considerations subsection for Service Discovery category/type registration.</p></remark>
<remark><p>Added XMPP Registrar Considerations subsection for Service Discovery category/type registration.</p></remark>
</revision>
<revision>
<version>1.0</version>
@ -197,7 +197,7 @@
<version>0.12</version>
<date>2003-08-13</date>
<initials>pgm/psa</initials>
<remark><p>Defined public vs. private nodes; described how changes to existing nodes might trigger meta-node events (e.g., configuration changes); changed &lt;x/&gt; to &lt;event/&gt; for #events namespace; added meta-data about meta-nodes; fully defined Jabber Registrar considerations.</p></remark>
<remark><p>Defined public vs. private nodes; described how changes to existing nodes might trigger meta-node events (e.g., configuration changes); changed &lt;x/&gt; to &lt;event/&gt; for #events namespace; added meta-data about meta-nodes; fully defined XMPP Registrar considerations.</p></remark>
</revision>
<revision>
<version>0.11</version>
@ -221,7 +221,7 @@
<version>0.8</version>
<date>2003-04-03</date>
<initials>pgm</initials>
<remark><p>Clarified the affiliations table and the semantics around subscribing and unsubscribing. Added protocol to get all of your affiliations in the service. Added protocol for services informing subscribers that configurable subscription options are available. Added protocol for obtaining existing node configuration settings and for concatenating configuration and node creation requests into a single stanza. Added meta-node implementation notes and specified the interaction with the Jabber Registrar and the meta NodeIDs. Added authorization notes to subscription options.</p></remark>
<remark><p>Clarified the affiliations table and the semantics around subscribing and unsubscribing. Added protocol to get all of your affiliations in the service. Added protocol for services informing subscribers that configurable subscription options are available. Added protocol for obtaining existing node configuration settings and for concatenating configuration and node creation requests into a single stanza. Added meta-node implementation notes and specified the interaction with the XMPP Registrar and the meta NodeIDs. Added authorization notes to subscription options.</p></remark>
</revision>
<revision>
<version>0.7</version>
@ -245,13 +245,13 @@
<version>0.4</version>
<date>2003-01-21</date>
<initials>pgm</initials>
<remark><p>Clarified in-band and out-of-band configuration requirement. Added Delete Item privilege for all affiliations to the table. Added Delete item protocol for publishers and owners. Added 401 error case for subscribing to an illegal jid. Changed subscription request form. Added defaults to configuration form, and clarified role of the Jabber Registrar for the features show. Added text explaining the max_items attribute. Changed &quot;last items&quot; to &quot;most recent items&quot;. Removed default configuration acceptance -- owners should just cancel. Added the notify_retract configuration option. Clarified error handling for affiliation modifications. </p></remark>
<remark><p>Clarified in-band and out-of-band configuration requirement. Added Delete Item privilege for all affiliations to the table. Added Delete item protocol for publishers and owners. Added 401 error case for subscribing to an illegal jid. Changed subscription request form. Added defaults to configuration form, and clarified role of the XMPP Registrar for the features show. Added text explaining the max_items attribute. Changed &quot;last items&quot; to &quot;most recent items&quot;. Removed default configuration acceptance -- owners should just cancel. Added the notify_retract configuration option. Clarified error handling for affiliation modifications. </p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2003-01-20</date>
<initials>pgm</initials>
<remark><p>Added subscription attribute for entities. Removed subscriber from the affiliations table. Clarified configuration details. Clarified JabberID usages. Added Jabber Registrar Considerations. Added link to JEP-0068 about the FORM_TYPE element in subscription request notifications. Fixed some typos in examples. Added unsupported configuration namespace to example. Added a default configuration example. </p></remark>
<remark><p>Added subscription attribute for entities. Removed subscriber from the affiliations table. Clarified configuration details. Clarified JabberID usages. Added XMPP Registrar Considerations. Added link to XEP-0068 about the FORM_TYPE element in subscription request notifications. Fixed some typos in examples. Added unsupported configuration namespace to example. Added a default configuration example. </p></remark>
</revision>
<revision>
<version>0.2</version>
@ -364,7 +364,7 @@ And by opposing end them?
<p>The following terms are used throughout this document to refer to elements, objects, or actions that occur in the context of a pubsub service. (Note: Some of these terms are specified in greater detail within the body of this document.)</p>
<table caption='Publish-Subscribe Terms'>
<tr><td>Authorize Access Model</td><td>A node access model under which an entity can subscribe only through having a subscription request approved by a node owner (subscription requests are accepted but only provisionally) and only subscribers may retrieve items.</td></tr>
<tr><td>Address</td><td>(1) A JID as defined in &xmppcore;, or (2) the combination of a JID and a &jep0030; node.</td></tr>
<tr><td>Address</td><td>(1) A JID as defined in &xmppcore;, or (2) the combination of a JID and a &xep0030; node.</td></tr>
<tr><td>Collection Node</td><td>A type of node that contains nodes and/or other collections but no published items. Collections make it possible to represent hierarchial node structures.</td></tr>
<tr><td>Entity</td><td>A JID-addressable Jabber entity (client, service, application, etc.).</td></tr>
<tr><td>Event</td><td>A change in the state of a node.</td></tr>
@ -379,7 +379,7 @@ And by opposing end them?
<tr><td>Owner</td><td>The manager of a node, of which there may be more than one; often but not necessarily the node creator.</td></tr>
<tr><td>Payload</td><td>The full data associated with an event rather than just the event notification itself.</td></tr>
<tr><td>Open Access Model</td><td>A node access model under which any entity may subscribe and retrieve items without approval.</td></tr>
<tr><td>Personal Eventing</td><td>A simplified subset of Publish-Subscribe for use in the context of instant messaging and presence applications, whereby each IM user's JID is a virtual pubsub service; for details, see &jep0163;.</td></tr>
<tr><td>Personal Eventing</td><td>A simplified subset of Publish-Subscribe for use in the context of instant messaging and presence applications, whereby each IM user's JID is a virtual pubsub service; for details, see &xep0163;.</td></tr>
<tr><td>Presence Access Model</td><td>A node access model under which any entity that is subscribed to the owner's presence with a subscription of type "from" or "both" (see &rfc3921;) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems.</td></tr>
<tr><td>Publisher</td><td>An entity that is allowed to publish items to a node.</td></tr>
<tr><td>Pubsub Service</td><td>An XMPP server or component that adheres to the protocol defined herein.</td></tr>
@ -419,7 +419,7 @@ And by opposing end them?
<section1 topic='Preliminaries' anchor='preliminaries'>
<section2 topic='Affiliations' anchor='affiliations'>
<p>To manage permissions, the protocol defined herein uses a hierarchy of affiliations, similiar to those introduced in &jep0045;.</p>
<p>To manage permissions, the protocol defined herein uses a hierarchy of affiliations, similiar to those introduced in &xep0045;.</p>
<p>Support for the "owner" and "none" affiliations is REQUIRED. Support for all other affiliations is RECOMMENDED. Particular kinds of pubsub services MAY enforce additional requirements.</p>
<table caption='Affiliations and their Privileges'>
<tr>
@ -606,7 +606,7 @@ And by opposing end them?
</section2>
<section2 topic='Addressing' anchor='addressing'>
<p>If a pubsub node is addressable, it MUST be addressable either (1) as a JID or (2) as the combination of a JID and a node. <note>These nodes are equivalent to those used in <cite>JEP-0030: Service Discovery</cite>.</note></p>
<p>If a pubsub node is addressable, it MUST be addressable either (1) as a JID or (2) as the combination of a JID and a node. <note>These nodes are equivalent to those used in <cite>XEP-0030: Service Discovery</cite>.</note></p>
<section3 topic='JID' anchor='addressing-jid'>
<p>If a pubsub node is addressable as a JID, the NodeID MUST be the resource identifier, and MUST NOT be specified by the "user" portion (node identifier) of the JID (e.g. "domain.tld/NodeID" and "user@domain.tld/NodeID" are allowed; "NodeID@domain.tld" is not allowed). JID addressing SHOULD be used when interacting with a pubsub node using a protocol that does not support the node attribute. For example, when a service makes it possible for entities to subscribe to nodes via presence, it would address nodes as JIDs. If a pubsub node is addressable as a JID, the pubsub service MUST ensure that the NodeID conforms to the Resourceprep profile of Stringprep as described in <cite>RFC 3920</cite>.</p>
<p>Consider the following example, in which the pubsub service is located at the hostname pubsub.shakespeare.lit.</p>
@ -658,11 +658,11 @@ And by opposing end them?
</query>
</iq>
]]></example>
<p>The possible pubsub features are noted throughout this document and have been registered as described in the <link url='#registrar'>Jabber Registrar Considerations</link> section of this document. For information regarding which features are required, recommended, and optional, see the <link url='#features'>Feature Summary</link> section of this document.</p>
<p>The possible pubsub features are noted throughout this document and have been registered as described in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document. For information regarding which features are required, recommended, and optional, see the <link url='#features'>Feature Summary</link> section of this document.</p>
</section2>
<section2 topic='Discover Nodes' anchor='entity-nodes'>
<p>If a service implements a hierarchy of nodes (by means of <link url='#collections'>Collection Nodes</link>), it MUST also enable entities to discover the nodes in that hierarchy by means of the <strong>Service Discovery</strong> protocol, subject to the recommendations in <cite>JEP-0030</cite> regarding large result sets (for which &jep0055; or some other protocol SHOULD be used). The following examples show the use of service discovery in discovering the nodes available at a hierarchical pubsub service.</p>
<p>If a service implements a hierarchy of nodes (by means of <link url='#collections'>Collection Nodes</link>), it MUST also enable entities to discover the nodes in that hierarchy by means of the <strong>Service Discovery</strong> protocol, subject to the recommendations in <cite>XEP-0030</cite> regarding large result sets (for which &xep0055; or some other protocol SHOULD be used). The following examples show the use of service discovery in discovering the nodes available at a hierarchical pubsub service.</p>
<p>Note: Node hierarchies and collection nodes are OPTIONAL. For details, refer to the <link url='#impl-semantics'>NodeID Semantics</link> and <link url='#collections'>Collection Nodes</link> sections of this document.</p>
<p>In the first example, an entity sends a service discovery items ("disco#items") request to the root node (i.e., the service itself), which is a <link url='#collections'>Collection Node</link>:</p>
<example caption='Entity requests all first-level nodes'><![CDATA[
@ -767,7 +767,7 @@ And by opposing end them?
]]></example>
</section2>
<section2 topic='Discover Node Meta-Data' anchor='entity-metadata'>
<p>The "disco#info" result MAY include detailed meta-data about the node, encapsulated in the &jep0004; format as described in &jep0128;, where the data form context is specified by including a FORM_TYPE of "http://jabber.org/protocol/pubsub#meta-data" in accordance with &jep0068;. If meta-data is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like.</p>
<p>The "disco#info" result MAY include detailed meta-data about the node, encapsulated in the &xep0004; format as described in &xep0128;, where the data form context is specified by including a FORM_TYPE of "http://jabber.org/protocol/pubsub#meta-data" in accordance with &xep0068;. If meta-data is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like.</p>
<example caption='Entity queries a node for information'><![CDATA[
<iq type='get'
from='francisco@denmark.lit/barracks'
@ -828,7 +828,7 @@ And by opposing end them?
<p>Much of the meta-data provided about a node maps directly to selected &DUBLINCORE; meta-data attributes; specifically:</p>
<table caption='Dublin Core Meta-Data Mapping'>
<tr><th>Pubsub Field</th><th>Dublin Core Meta-Data Attribute</th></tr>
<tr><td>pubsub#creation_date</td><td>Date <note>The value SHOULD be a DateTime as defined in <cite>JEP-0082</cite>, and MUST conform to one of the profiles defined therein.</note></td></tr>
<tr><td>pubsub#creation_date</td><td>Date <note>The value SHOULD be a DateTime as defined in <cite>XEP-0082</cite>, and MUST conform to one of the profiles defined therein.</note></td></tr>
<tr><td>pubsub#creator</td><td>Creator</td></tr>
<tr><td>pubsub#description</td><td>Description</td></tr>
<tr><td>pubsub#language</td><td>Language</td></tr>
@ -1016,7 +1016,7 @@ And by opposing end them?
</pubsub>
</iq>
]]></example>
<p>The service MAY also send the last published item to the new subscriber. The message containing this item SHOULD be stamped with extended information qualified by the 'jabber:x:delay' namespace (see &jep0091;) to indicate it is are sent with delayed delivery. (Note that in this example the message notification is sent to the bare JID since that is the subscribed JID.)</p>
<p>The service MAY also send the last published item to the new subscriber. The message containing this item SHOULD be stamped with extended information qualified by the 'jabber:x:delay' namespace (see &xep0091;) to indicate it is are sent with delayed delivery. (Note that in this example the message notification is sent to the bare JID since that is the subscribed JID.)</p>
<example caption='Service sends last published item'><![CDATA[
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@ -1486,7 +1486,7 @@ And by opposing end them?
</pubsub>
</iq>
]]></example>
<p>Note: The foregoing example shows some (but by no means all) of the possible configuration options that MAY be provided. If an implementation provides these options using the <strong>Data Forms</strong> protocol, it MUST use the field variables that are registered with the Jabber Registrar in association with the 'http://jabber.org/protocol/pubsub' namespace (a preliminary representation of those field variables is shown above and in the <link url='#registrar-formtypes-options'>pubsub#subscribe_options FORM_TYPE</link> section of this document, but MUST NOT be construed as canonical since the Jabber Registrar may standardize additional fields at a later date without changes to this document).</p>
<p>Note: The foregoing example shows some (but by no means all) of the possible configuration options that MAY be provided. If an implementation provides these options using the <strong>Data Forms</strong> protocol, it MUST use the field variables that are registered with the XMPP Registrar in association with the 'http://jabber.org/protocol/pubsub' namespace (a preliminary representation of those field variables is shown above and in the <link url='#registrar-formtypes-options'>pubsub#subscribe_options FORM_TYPE</link> section of this document, but MUST NOT be construed as canonical since the XMPP Registrar may standardize additional fields at a later date without changes to this document).</p>
<p>Note: Many of the relevant data form fields are of type "boolean" and MUST be handled accordingly. &BOOLEANNOTE;</p>
<p>There are several reasons why the options request might fail:</p>
<ol>
@ -1998,7 +1998,7 @@ And by opposing end them?
</error>
</iq>
]]></example>
<p>A service MAY allow entities to request the most recent N items by using the 'max_items' attribute. When max_items is used, implementations SHOULD return the N most recent (as opposed to the N oldest) items. (Note: A future version of this specification may recommend the use of &jep0059; instead of the 'max_items' attribute.)</p>
<p>A service MAY allow entities to request the most recent N items by using the 'max_items' attribute. When max_items is used, implementations SHOULD return the N most recent (as opposed to the N oldest) items. (Note: A future version of this specification may recommend the use of &xep0059; instead of the 'max_items' attribute.)</p>
<example caption='Subscriber requests two most recent items'><![CDATA[
<iq type='get'
from='francisco@denmark.lit/barracks'
@ -2312,7 +2312,7 @@ And by opposing end them?
.
.
]]></example>
<p>If a single entity is subscribed to a node multiple times, the service SHOULD notate the event notification so that the entity can determine which subscription identifier(s) generated this event. If these notations are included, they MUST use the &jep0131; format and SHOULD be included after the event notification information (i.e., as the last child of the &MESSAGE; stanza).</p>
<p>If a single entity is subscribed to a node multiple times, the service SHOULD notate the event notification so that the entity can determine which subscription identifier(s) generated this event. If these notations are included, they MUST use the &xep0131; format and SHOULD be included after the event notification information (i.e., as the last child of the &MESSAGE; stanza).</p>
<example caption='Subscriber receives notated event notification'><![CDATA[
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@ -2902,7 +2902,7 @@ And by opposing end them?
</pubsub>
</iq>
]]></example>
<p>Note: The following example shows some of the possible configuration options that MAY be provided. If an implementation implements these features using the <strong>Data Forms</strong> protocol, that implementation MUST use the fields that are registered with the Jabber Registrar in association with the 'http://jabber.org/protocol/pubsub' namespace (a preliminary representation of those field variables is shown below and in the <link url='#registrar-formtypes-config'>pubsub#node_config FORM_TYPE</link> section of this document, but MUST NOT be construed as canonical, since the Jabber Registrar may standardize additional fields at a later date without changes to this document). An implementation MAY choose to specify different labels, values, and even field types, but MUST conform to the defined variable naming scheme.</p>
<p>Note: The following example shows some of the possible configuration options that MAY be provided. If an implementation implements these features using the <strong>Data Forms</strong> protocol, that implementation MUST use the fields that are registered with the XMPP Registrar in association with the 'http://jabber.org/protocol/pubsub' namespace (a preliminary representation of those field variables is shown below and in the <link url='#registrar-formtypes-config'>pubsub#node_config FORM_TYPE</link> section of this document, but MUST NOT be construed as canonical, since the XMPP Registrar may standardize additional fields at a later date without changes to this document). An implementation MAY choose to specify different labels, values, and even field types, but MUST conform to the defined variable naming scheme.</p>
<example caption='Service responds with configuration form'><![CDATA[
<iq type='result'
from='pubsub.shakespeare.lit'
@ -3666,7 +3666,7 @@ And by opposing end them?
]]></example>
<p>The service MUST check the "pubsub#allow" field to see if the subscription should be allowed or denied. If the owner cancels the Data Form, then the subscription request MUST remain in the pending state.</p>
<section3 topic='Request All Pending Subscription Requests' anchor='owner-subreq-all'>
<p>A service MAY allow owners to request all the current pending subscription requests for all of their nodes at the service. Implementations MUST use the &jep0050; protocol to provide this functionality. The command name ('node' attribute of the command element) MUST have a value of "http://jabber.org/protocol/pubsub#get-pending".</p>
<p>A service MAY allow owners to request all the current pending subscription requests for all of their nodes at the service. Implementations MUST use the &xep0050; protocol to provide this functionality. The command name ('node' attribute of the command element) MUST have a value of "http://jabber.org/protocol/pubsub#get-pending".</p>
<example caption='Owner requests pending subscription requests'><![CDATA[
<iq type='set'
from='hamlet@denmark.lit/elsinore'
@ -4776,7 +4776,7 @@ And by opposing end them?
<td>Entities are required to register before node creation is allowed.</td>
</tr>
</table>
<p>Note: Refer to &jep0086; for more information regarding error syntax.</p>
<p>Note: Refer to &xep0086; for more information regarding error syntax.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
@ -4787,7 +4787,7 @@ And by opposing end them?
<section2 topic='Handling Notification-Related Errors' anchor='impl-bounce'>
<p>As noted above, a pubsub service SHOULD ensure that the &MESSAGE; stanza for each event notification it generates possesses an 'id' attribute with a unique value. (This notification ID is not to be confused with either the node ID or the item ID.) This ID MUST be unique within the context of the pubsub service in order to ensure proper tracking of any delivery-related errors.</p>
<p>Exactly how a service shall handle delivery-related errors is a matter of implementation. In general, such handling is effectively similar to the bounce processing performed by other message delivery systems, such as mail transfer agents and mailing list software. The following are some suggested guidelines regarding the handling of XMPP-specific error conditions in relation to pubsub event notifications (see <cite>RFC 3920</cite> and <cite>JEP-0086</cite> regarding XMPP error condition semantics):</p>
<p>Exactly how a service shall handle delivery-related errors is a matter of implementation. In general, such handling is effectively similar to the bounce processing performed by other message delivery systems, such as mail transfer agents and mailing list software. The following are some suggested guidelines regarding the handling of XMPP-specific error conditions in relation to pubsub event notifications (see <cite>RFC 3920</cite> and <cite>XEP-0086</cite> regarding XMPP error condition semantics):</p>
<ul>
<li>If the XMPP error is of type "cancel" (e.g., &notfound;), or the error condition is &gone;, the pubsub service SHOULD terminate the subscription of the entity to that node and MAY terminate the subscription of that entity to all nodes hosted at the service.</li>
<li>If the XMPP error is of type "auth" (e.g., &registration;) or "wait" (e.g., &timeout;), or the error condition is &badrequest;, &redirect;, or &notacceptable;, the pubsub service SHOULD increment a bounce counter for that entity and MAY attempt to resend the event notification after some configurable amount of time. The service MAY terminate the subscription of the entity to that node if the bounce counter has reached some configurable limit.</li>
@ -4799,10 +4799,10 @@ And by opposing end them?
</section2>
<section2 topic='Not Routing Events to Offline Storage' anchor='impl-offline'>
<p>Sending events to users of existing Jabber servers may force event notifications to be routed to offline storage for later delivery (as described in &jep0160;). This may not always be desirable. The possible ways of preventing this behavior include:</p>
<p>Sending events to users of existing Jabber servers may force event notifications to be routed to offline storage for later delivery (as described in &xep0160;). This may not always be desirable. The possible ways of preventing this behavior include:</p>
<ul>
<li>Use presence-based subscription options as described above.</li>
<li>Use delivery semantics as defined by &jep0079;.</li>
<li>Use delivery semantics as defined by &xep0079;.</li>
<li>Specify a message type of "headline", which in most existing server implementations will prevent offline storage.</li>
</ul>
</section2>
@ -4836,7 +4836,7 @@ And by opposing end them?
<section2 topic='Authorizing Subscription Requests (Pending Subscribers)' anchor='impl-authorize'>
<p>How subscription requests are sent to node owners is a matter of implementation. Possibilities include:</p>
<ul>
<li>Send requests to all owners (these may be placed in offline storage as described in <cite>JEP-0160</cite>) and first approval wins.</li>
<li>Send requests to all owners (these may be placed in offline storage as described in <cite>XEP-0160</cite>) and first approval wins.</li>
<li>The service could subscribe to owner presence, and send only to the owners that are online.</li>
<li>All owners vote on the new subscriber.</li>
<li>Any owner is allowed to veto the subscriber.</li>
@ -4886,7 +4886,7 @@ And by opposing end them?
</section2>
<section2 topic='Multiple Node Discovery' anchor='impl-multiple'>
<p>A user may publish information that adheres to a certain profile at multiple pubsub nodes, and a potential subscriber may want to discover all of these pubsub nodes. The user may make a list of pubsub nodes publicly available for querying even when the user is offline by using the Service Discovery mechanism for "publishing" items (see Section 4 of <cite>JEP-0030</cite>). The potential subscriber may then send a "disco#items" request to the user's bare JID (&lt;user@host&gt;), including the 'node' attribute set to the value of the namespace to which the desired information adheres. The user's server then returns a list of pubsub nodes that meet that criterion (with each pubsub node being a separate Service Discovery item). Here is an example.</p>
<p>A user may publish information that adheres to a certain profile at multiple pubsub nodes, and a potential subscriber may want to discover all of these pubsub nodes. The user may make a list of pubsub nodes publicly available for querying even when the user is offline by using the Service Discovery mechanism for "publishing" items (see Section 4 of <cite>XEP-0030</cite>). The potential subscriber may then send a "disco#items" request to the user's bare JID (&lt;user@host&gt;), including the 'node' attribute set to the value of the namespace to which the desired information adheres. The user's server then returns a list of pubsub nodes that meet that criterion (with each pubsub node being a separate Service Discovery item). Here is an example.</p>
<example caption='Discovering multiple nodes'><![CDATA[
<iq type='get'
from='francisco@denmark.lit/barracks'
@ -4911,7 +4911,7 @@ And by opposing end them?
</query>
</iq>
]]></example>
<p>Alternatively, a user may be registered with a server that offers personal eventing services, in which case the user will have one node per namespace as described in <cite>JEP-0163</cite>.</p>
<p>Alternatively, a user may be registered with a server that offers personal eventing services, in which case the user will have one node per namespace as described in <cite>XEP-0163</cite>.</p>
</section2>
<section2 topic='Inclusion of SHIM Headers' anchor='impl-shim'>
@ -4927,7 +4927,7 @@ And by opposing end them?
<section2 topic='Associating Events and Payloads with the Generating Entity' anchor='impl-association'>
<p>An implementation MAY enable the node configuration to specify an association between the event notification and the entity to which the published information pertains, but such a feature is OPTIONAL. Here are some possible examples:</p>
<ul>
<li>In the context of a geolocation notification service using &jep0080;, the user may generate the geolocation information or the information may be generated by an automated service (e.g., a service offered by a mobile telephony provider), but in either case the information is <em>about</em> the user's geolocation and therefore all replies should go to the user (who is probably the node owner).</li>
<li>In the context of a geolocation notification service using &xep0080;, the user may generate the geolocation information or the information may be generated by an automated service (e.g., a service offered by a mobile telephony provider), but in either case the information is <em>about</em> the user's geolocation and therefore all replies should go to the user (who is probably the node owner).</li>
<li>In the context of a group weblog, different users might publish to the weblog and replies might go to the publisher of an entry rather than to the weblog owner.</li>
<li>In the context of an integrated pubsub and multi-user chat system, the node owner might be the room owner but all replies need to be sent to the room rather than to the owner.</li>
</ul>
@ -4958,7 +4958,7 @@ And by opposing end them?
</addresses>
</message>
]]></example>
<p>Alternatively, if a service implements the personal eventing subset of this protocol, the virtual pubsub service is the account owner's bare JID and notifications are sent from that JID; for details, refer to <cite>JEP-0163</cite>.</p>
<p>Alternatively, if a service implements the personal eventing subset of this protocol, the virtual pubsub service is the account owner's bare JID and notifications are sent from that JID; for details, refer to <cite>XEP-0163</cite>.</p>
</section2>
<section2 topic='Chaining' anchor='impl-chaining'>
@ -4967,7 +4967,7 @@ And by opposing end them?
</section2>
<section2 topic='Time-Based Subscriptions (Leases)' anchor='impl-leases'>
<p>In some systems it may be desirable to provide a subscription "leasing" feature in order to expire old or stale subscriptions. Leases can be implemented using configurable subscription options; specifically, when an entity subscribes, the service would require configuration of subscription options and the configuration form would contain a field of "pubsub#expire". This field MUST contain a dateTime (as specified in &jep0082;).</p>
<p>In some systems it may be desirable to provide a subscription "leasing" feature in order to expire old or stale subscriptions. Leases can be implemented using configurable subscription options; specifically, when an entity subscribes, the service would require configuration of subscription options and the configuration form would contain a field of "pubsub#expire". This field MUST contain a dateTime (as specified in &xep0082;).</p>
<p>The leasing process is shown below.</p>
<example caption='Leasing process'><![CDATA[
<iq type='set'
@ -5114,7 +5114,7 @@ And by opposing end them?
<section2 topic='Content-Based Pubsub Systems' anchor='impl-content'>
<p>A service MAY enable entities to subscribe to nodes and apply a filter to notifications (e.g., keyword matching such as "send me all news entries from Slashdot that match the term 'Jabber'"). Such a content-based service SHOULD allow an entity to subscribe more than once to the same node and, if so, MUST use subscription identifiers (SubIDs) to distinguish between multiple subscriptions. In order to prevent collisions, a service that supports content-based subscriptions using SubIDs SHOULD generate SubIDs on behalf of subscribers rather than allowing subscribers to set their own SubIDs. <note>Another way to implement content-based subscriptions is to host one node per keyword or other filter; however, this is likely to require an extremely large number of nodes.</note></p>
<p>Content-based services SHOULD use subscription options to specify the filter(s) to be applied. Because there many possible filtering mechanisms (many of which may be application-specific), this JEP does not define any such method. However, filtering mechanisms may be defined in separate specifications.</p>
<p>Content-based services SHOULD use subscription options to specify the filter(s) to be applied. Because there many possible filtering mechanisms (many of which may be application-specific), this document does not define any such method. However, filtering mechanisms may be defined in separate specifications.</p>
<p>A fictional example of the subscription options configuration process for content-based pubsub is shown below.</p>
<example caption='A content-based subscription'><![CDATA[
<iq type='set'
@ -5245,10 +5245,10 @@ O, what a rogue and peasant slave am I!
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP does not require interaction with &IANA;.</p>
<p>This document does not require 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 the following namespaces in its registry of protocol namespaces (see &NAMESPACES;):</p>
@ -5261,7 +5261,7 @@ O, what a rogue and peasant slave am I!
</section2>
<section2 topic='Service Discovery Category/Type' anchor='registrar-disco'>
<p>The Jabber Registrar includes a category of "pubsub" in its registry of Service Discovery identities (see &DISCOCATEGORIES;), as well as three specific types within that category:</p>
<p>The XMPP Registrar includes a category of "pubsub" in its registry of Service Discovery identities (see &DISCOCATEGORIES;), as well as three specific types within that category:</p>
<table caption='Service Discovery Types in Pubsub Category'>
<tr>
<td>collection</td>
@ -5273,187 +5273,187 @@ O, what a rogue and peasant slave am I!
</tr>
<tr>
<td>service</td>
<td>A pubsub service that supports the functionality defined in JEP-0060. <note>Prior to version 1.5 of JEP-0060, this type was called "generic".</note></td>
<td>A pubsub service that supports the functionality defined in XEP-0060. <note>Prior to version 1.5 of XEP-0060, this type was called "generic".</note></td>
</tr>
</table>
<p>The registry submission is as follows:</p>
<code><![CDATA[
<category>
<name>pubsub</name>
<desc>Services and nodes that adhere to JEP-0060.</desc>
<desc>Services and nodes that adhere to XEP-0060.</desc>
<type>
<name>collection</name>
<desc>A pubsub node of the "collection" type.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</type>
<type>
<name>leaf</name>
<desc>A pubsub node of the "leaf" type.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</type>
<type>
<name>service</name>
<desc>A pubsub service that supports the functionality defined in JEP-0060.</desc>
<doc>JEP-0060</doc>
<desc>A pubsub service that supports the functionality defined in XEP-0060.</desc>
<doc>XEP-0060</doc>
</type>
</category>
]]></code>
<p>Future submissions to the Jabber Registrar may register additional types.</p>
<p>Future submissions to the XMPP Registrar may register additional types.</p>
</section2>
<section2 topic='Service Discovery Features' anchor='registrar-features'>
<p>The Jabber Registrar maintains a registry of service discovery features (see &DISCOFEATURES;), which includes a number of features that may be returned by pubsub services. The following registry submission has been provided to the Jabber Registrar for that purpose.</p>
<p>The XMPP Registrar maintains a registry of service discovery features (see &DISCOFEATURES;), which includes a number of features that may be returned by pubsub services. The following registry submission has been provided to the XMPP Registrar for that purpose.</p>
<code><![CDATA[
<var>
<name>http://jabber.org/protocol/pubsub#collections</name>
<desc>Collection nodes are supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#config-node</name>
<desc>Configuration of node options is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#create-and-configure</name>
<desc>Simultaneous creation and configuration of nodes is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#create-nodes</name>
<desc>Creation of nodes is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#delete-any</name>
<desc>Any publisher may delete an item (not only the originating publisher).</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#delete-nodes</name>
<desc>Deletion of nodes is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#get-pending</name>
<desc>Retrieval of pending subscription approvals is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#instant-nodes</name>
<desc>Creation of instant nodes is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#item-ids</name>
<desc>Publishers may specify item identifiers.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#leased-subscription</name>
<desc>Time-based subscriptions are supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#meta-data</name>
<desc>Node meta-data is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#manage-subscription</name>
<desc>Node owners may manage subscriptions.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#modify-affiliations</name>
<desc>Node owners may modify affiliations.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#multi-collection</name>
<desc>A single leaf node may be associated with multiple collections.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#multi-subscribe</name>
<desc>A single entity may subscribe to a node multiple times.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#outcast-affiliation</name>
<desc>The outcast affiliation is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#persistent-items</name>
<desc>Persistent items are supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#presence-notifications</name>
<desc>Presence-based delivery of event notifications is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#publish</name>
<desc>Publishing items is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#publisher-affiliation</name>
<desc>The publisher affiliation is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#purge-nodes</name>
<desc>Purging of nodes is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#retract-items</name>
<desc>Item retraction is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#retrieve-affiliations</name>
<desc>Retrieval of current affiliations is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#retrieve-default</name>
<desc>Retrieval of default node configuration is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#retrieve-items</name>
<desc>Item retrieval is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#retrieve-subscriptions</name>
<desc>Retrieval of current subscriptions is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#subscribe</name>
<desc>Subscribing and unsubscribing are supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#subscription-options</name>
<desc>Configuration of subscription options is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#subscription-notifications</name>
<desc>Notification of subscription state changes is supported.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</var>
]]></code>
</section2>
<section2 topic='Field Standardization' anchor='registrar-formtypes'>
<p>JEP-0068 defines a process for standardizing the fields used within Data Forms scoped by a particular namespace, and the Jabber Registrar maintains a registry of such FORM_TYPES (see &FORMTYPES;). Within pubsub, there are four uses of such forms:</p>
<p>XEP-0068 defines a process for standardizing the fields used within Data Forms scoped by a particular namespace, and the XMPP Registrar maintains a registry of such FORM_TYPES (see &FORMTYPES;). Within pubsub, there are four uses of such forms:</p>
<ol>
<li>Authorization of subscriptions using the 'http://jabber.org/protocol/pubsub#subscribe_authorization' namespace.</li>
<li>Configuration of subscription options using the 'http://jabber.org/protocol/pubsub#subscribe_options' namespace.</li>
@ -5461,13 +5461,13 @@ O, what a rogue and peasant slave am I!
<li>Setting of meta-data information using the 'http://jabber.org/protocol/pubsub#meta-data' namespace.</li>
</ol>
<p>The registry submissions associated with these namespaces are defined below.</p>
<p>Note: There is no requirement that configuration fields need to be registered with the Jabber Registrar. However, as specified in Section 3.4 of <cite>JEP-0068</cite>, names of custom (unregistered) fields MUST begin with the characters "x-" if the form itself is scoped by a registered FORM_TYPE.</p>
<p>Note: There is no requirement that configuration fields need to be registered with the XMPP Registrar. However, as specified in Section 3.4 of <cite>XEP-0068</cite>, names of custom (unregistered) fields MUST begin with the characters "x-" if the form itself is scoped by a registered FORM_TYPE.</p>
<section3 topic='pubsub#subscribe_authorization FORM_TYPE' anchor='registrar-formtypes-auth'>
<code><![CDATA[
<form_type>
<name>http://jabber.org/protocol/pubsub#subscribe_authorization</name>
<jep>JEP-0060</jep>
<jep>XEP-0060</jep>
<desc>Forms enabling authorization of subscriptions to pubsub nodes</desc>
<field
var='pubsub#allow'
@ -5492,7 +5492,7 @@ O, what a rogue and peasant slave am I!
<code><![CDATA[
<form_type>
<name>http://jabber.org/protocol/pubsub#subscribe_options</name>
<jep>JEP-0060</jep>
<jep>XEP-0060</jep>
<desc>Forms enabling configuration of subscription options for pubsub nodes</desc>
<field
var='pubsub#deliver'
@ -5566,7 +5566,7 @@ O, what a rogue and peasant slave am I!
<code><![CDATA[
<form_type>
<name>http://jabber.org/protocol/pubsub#node_config</name>
<jep>JEP-0060</jep>
<jep>XEP-0060</jep>
<desc>Forms enabling configuration of pubsub nodes</desc>
<field var='pubsub#access_model'
type='list-single'
@ -5726,7 +5726,7 @@ O, what a rogue and peasant slave am I!
<code><![CDATA[
<form_type>
<name>http://jabber.org/protocol/pubsub#meta-data</name>
<jep>JEP-0060</jep>
<jep>XEP-0060</jep>
<desc>Forms enabling setting of meta-data information about pubsub nodes</desc>
<field var='pubsub#contact'
type='jid-multi'
@ -5764,28 +5764,28 @@ O, what a rogue and peasant slave am I!
</section3>
</section2>
<section2 topic='SHIM Headers' anchor='registrar-shim'>
<p>The Jabber Registrar includes "pubsub#collection", "pubsub#expire", and "pubsub#subid" in its registry of SHIM headers (see &SHIMHEADERS;). The registry submission is as follows:</p>
<p>The XMPP Registrar includes "pubsub#collection", "pubsub#expire", and "pubsub#subid" in its registry of SHIM headers (see &SHIMHEADERS;). The registry submission is as follows:</p>
<code><![CDATA[
<header>
<name>pubsub#collection</name>
<desc>The collection via which a notification was received from the originating node.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</header>
<header>
<name>pubsub#expire</name>
<desc>The DateTime at which a pubsub leased subscription will end or has ended.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</header>
<header>
<name>pubsub#subid</name>
<desc>A subscription identifer within the pubsub protocol.</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
</header>
]]></code>
<p>Future submissions to the Jabber Registrar may register additional SHIM headers that can be used in relation to the pubsub protocol, and such submission may occur without updating this specification.</p>
<p>Future submissions to the XMPP Registrar may register additional SHIM headers that can be used in relation to the pubsub protocol, and such submission may occur without updating this specification.</p>
</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 "pubsub" querytype is defined herein for interaction with pubsub services, with two keys: (1) "action" (whose defined values are "subscribe" and "unsubscribe") and (2) "node" (to specify a pubsub node).</p>
<example caption='Pubsub Subscribe Action: IRI/URI'><![CDATA[
xmpp:pubsub.shakespeare.lit?pubsub;action=subscribe;node=princely_musings
@ -5813,7 +5813,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
<name>pubsub</name>
<proto>http://jabber.org/protocol/pubsub</proto>
<desc>enables interaction with a publish-subscribe service</desc>
<doc>JEP-0060</doc>
<doc>XEP-0060</doc>
<keys>
<key>
<name>action</name>
@ -5853,7 +5853,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0060: http://www.jabber.org/jeps/jep-0060.html
XEP-0060: http://www.xmpp.org/extensions/xep-0060.html
</xs:documentation>
</xs:annotation>
@ -6061,9 +6061,9 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
<xs:annotation>
<xs:documentation>
This namespace is used for error reporting only, as
defined in JEP-0060:
defined in XEP-0060:
http://www.jabber.org/jeps/jep-0060.html
http://www.xmpp.org/extensions/xep-0060.html
</xs:documentation>
</xs:annotation>
@ -6153,7 +6153,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0060: http://www.jabber.org/jeps/jep-0060.html
XEP-0060: http://www.xmpp.org/extensions/xep-0060.html
</xs:documentation>
</xs:annotation>
@ -6297,7 +6297,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0060: http://www.jabber.org/jeps/jep-0060.html
XEP-0060: http://www.xmpp.org/extensions/xep-0060.html
</xs:documentation>
</xs:annotation>
@ -6426,4 +6426,4 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
<p>Peter Millard, primary author of this specification from version 0.1 through version 1.7, died on April 26, 2006. The remaining co-authors are indebted to him for his many years of work on publish-subscribe technologies.</p>
</section1>
</jep>
</xep>

14
xep-0061.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>Shared Notes</title>
<abstract>A simplistic mechanism for shared notes, modeled after common stickie note applications.</abstract>
@ -27,7 +27,7 @@
<version>0.2</version>
<date>2003-09-30</date>
<initials>psa</initials>
<remark>At the request of the author, changed the status of this JEP to Deferred pending development of an implementation; also changed the type to Informational.</remark>
<remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
</revision>
<revision>
<version>0.1</version>
@ -51,7 +51,7 @@ default on a save action by the user).</p>
<message from="jer@jabber.org/foo" to="stpeter@jabber.org/bar">
<thread>1X544O</thread>
<subject>Council Votes</subject>
<body>Need votes from bob, tom, and jane yet for JEP-0000</body>
<body>Need votes from bob, tom, and jane yet for XEP-0000</body>
<note xmlns="http://www.jabber.org/protocol/sharednote">
<color>#001122</color>
<bgcolor>#221100</bgcolor>
@ -79,5 +79,5 @@ haven't been sent and an update comes in on the same thread the client should pr
changes offering to replace or save their changes.</p>
</section1>
</jep>
</xep>

22
xep-0062.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'?>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<jep>
<xep>
<header>
<title>Packet Filtering</title>
<abstract>A framework for packet filtering rules.</abstract>
@ -16,7 +16,7 @@
<status>Deferred</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<dependencies>XMPP Core, JEP-0030</dependencies>
<dependencies>XMPP Core, XEP-0030</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>Not yet assigned</shortname>
@ -30,7 +30,7 @@
<version>0.2</version>
<date>2003-09-30</date>
<initials>psa</initials>
<remark>At the request of the author, changed the status of this JEP to Deferred pending development of an implementation; also changed the type to Informational.</remark>
<remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
</revision>
<revision>
<version>0.1</version>
@ -49,7 +49,7 @@
<li>Bugs in the service often caused the Jabber server to crash.</li>
</ul>
<p>The most common use for this service was to provide server-side blacklists. Unforuntately, mod_filter was overpowered even by this relatively simple form of packet filtering (matching the sending JID and dropping the packet if necessary), so this need has been neatly filled by &jep0016;.</p>
<p>The most common use for this service was to provide server-side blacklists. Unforuntately, mod_filter was overpowered even by this relatively simple form of packet filtering (matching the sending JID and dropping the packet if necessary), so this need has been neatly filled by &xep0016;.</p>
<p>However, packet filtering (as opposed to the subset of JID blacklisting) is still of use, for the following tasks:</p>
@ -327,7 +327,7 @@
</section1>
<section1 topic='Implementation notes'>
<p>Ruleset processing should be the first thing that a service does when it receives a packet - even before processing privacy rules per JEP-0016.</p>
<p>Ruleset processing should be the first thing that a service does when it receives a packet - even before processing privacy rules per XEP-0016.</p>
<p>Rules must be processed in the order they are given, and must be returned to a requesting entity in the same order.</p>
</section1>
@ -337,11 +337,11 @@
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with the IANA.</p>
<p>This document requires no interaction with the IANA.</p>
</section1>
<section1 topic='JANA Considerations'>
<p>No namespaces or parameters need to be registered with JANA as a result of this JEP.</p>
<p>No namespaces or parameters need to be registered with JANA as a result of this document.</p>
</section1>
</jep>
</xep>

20
xep-0063.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'?>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<jep>
<xep>
<header>
<title>Basic Filtering Operations</title>
<abstract>A module that provides basic conditions and actions for packet filtering.</abstract>
@ -16,7 +16,7 @@
<status>Deferred</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<dependencies>JEP-0062</dependencies>
<dependencies>XEP-0062</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>Not yet assigned</shortname>
@ -30,7 +30,7 @@
<version>0.2</version>
<date>2003-09-30</date>
<initials>psa</initials>
<remark>At the request of the author, changed the status of this JEP to Deferred pending development of an implementation; also changed the type to Informational.</remark>
<remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
</revision>
<revision>
<version>0.1</version>
@ -41,7 +41,7 @@
</header>
<section1 topic='Introduction'>
<p>This document defines a module for &jep0062; that provides some basic conditions and actions to perform common packet filtering tasks.</p>
<p>This document defines a module for &xep0062; that provides some basic conditions and actions to perform common packet filtering tasks.</p>
<p>This module operates in the "http://jabber.org/protocol/filter/basic" namespace.</p>
</section1>
@ -97,11 +97,11 @@
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with the IANA.</p>
<p>This document requires no interaction with the IANA.</p>
</section1>
<section1 topic='JANA Considerations'>
<p>No namespaces or parameters need to be registered with JANA as a result of this JEP.</p>
<p>No namespaces or parameters need to be registered with JANA as a result of this document.</p>
</section1>
</jep>
</xep>

20
xep-0064.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'?>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<jep>
<xep>
<header>
<title>XPath Filtering</title>
<abstract>A module that provides an XPath matching condition for packet filtering.</abstract>
@ -16,7 +16,7 @@
<status>Deferred</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<dependencies>JEP-0062</dependencies>
<dependencies>XEP-0062</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>Not yet assigned</shortname>
@ -30,7 +30,7 @@
<version>0.2</version>
<date>2003-09-30</date>
<initials>psa</initials>
<remark>At the request of the author, changed the status of this JEP to Deferred pending development of an implementation; also changed the type to Informational.</remark>
<remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
</revision>
<revision>
<version>0.1</version>
@ -41,7 +41,7 @@
</header>
<section1 topic='Introduction'>
<p>This document defines a module for &jep0062; that provides an XPath matching condition for packet filtering.</p>
<p>This document defines a module for &xep0062; that provides an XPath matching condition for packet filtering.</p>
<p>This module operates in the "http://jabber.org/protocol/filter/xpath" namespace.</p>
</section1>
@ -68,11 +68,11 @@
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with the IANA.</p>
<p>This document requires no interaction with the IANA.</p>
</section1>
<section1 topic='JANA Considerations'>
<p>No namespaces or parameters need to be registered with JANA as a result of this JEP.</p>
<p>No namespaces or parameters need to be registered with JANA as a result of this document.</p>
</section1>
</jep>
</xep>

44
xep-0065.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>SOCKS5 Bytestreams</title>
<abstract>This JEP defines a protocol for establishing an out-of-band bytestream between any two Jabber entities.</abstract>
<abstract>This document defines an XMPP protocol extension for establishing an out-of-band bytestream between any two Jabber entities.</abstract>
&LEGALNOTICE;
<number>0065</number>
<status>Draft</status>
@ -17,13 +17,13 @@
<spec>XMPP Core</spec>
<spec>RFC 1928</spec>
<spec>RFC 3174</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>bytestreams</shortname>
<schemaloc>
<url>http://jabber.org/protocol/bytestreams/bytestreams.xsd</url>
<url>http://www.xmpp.org/schemas/bytestreams.xsd</url>
</schemaloc>
&dizzyd;
&linuxwolf;
@ -50,7 +50,7 @@
<version>1.3</version>
<date>2003-09-24</date>
<initials>psa</initials>
<remark>Added disco#info &lt;identity/&gt; and corresponding Jabber Registrar submission; added XMPP error handling.</remark>
<remark>Added disco#info &lt;identity/&gt; and corresponding XMPP Registrar submission; added XMPP error handling.</remark>
</revision>
<revision>
<version>1.2</version>
@ -114,16 +114,16 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>XMPP is designed for sending relatively small fragments of XML between network entities (see &xmppcore;) and is not designed for sending binary data. However, sometimes it is desirable to send binary data to another entity that one has discovered on the XMPP network (e.g., to send a file). Therefore it is widely recognized within the Jabber community that it would be valuable to have a generic protocol for streaming binary data between any two entities on the network. The main application for such a bytestreaming technology would be file transfer, for which there are currently a number of incompatible protocols (resulting in a lack of interoperability). However, other applications are possible, which is why it is important to develop a generic protocol rather than one that is specialized for a particular application such as file transfer. This JEP proposes a protocol that meets the following conditions:</p>
<p>XMPP is designed for sending relatively small fragments of XML between network entities (see &xmppcore;) and is not designed for sending binary data. However, sometimes it is desirable to send binary data to another entity that one has discovered on the XMPP network (e.g., to send a file). Therefore it is widely recognized within the Jabber community that it would be valuable to have a generic protocol for streaming binary data between any two entities on the network. The main application for such a bytestreaming technology would be file transfer, for which there are currently a number of incompatible protocols (resulting in a lack of interoperability). However, other applications are possible, which is why it is important to develop a generic protocol rather than one that is specialized for a particular application such as file transfer. This document defines a protocol that meets the following conditions:</p>
<ul>
<li>Bytestreams are established over standard TCP connections (&rfc0793;) or UDP associations (&rfc0768;), where TCP support is REQUIRED and UDP support is OPTIONAL</li>
<li>Sockets may be direct (peer-to-peer) or mediated (established through a bytestreaming service)</li>
<li>Where possible, standard wire protocols are used</li>
</ul>
<p>Specifically, this JEP proposes that the Jabber community make use of the SOCKS 5 protocol, which is an IETF-approved, IPv6-ready technology for bytestreams. (Note: Because this proposal uses a subset of the SOCKS5 protocol that is specially adapted for Jabber bytestreams, existing SOCKS5 proxies cannot be used to implement this proposal without modifications.)</p>
<p>Specifically, this document proposes that the Jabber community make use of the SOCKS 5 protocol, which is an IETF-approved, IPv6-ready technology for bytestreams. (Note: Because this proposal uses a subset of the SOCKS5 protocol that is specially adapted for Jabber bytestreams, existing SOCKS5 proxies cannot be used to implement this proposal without modifications.)</p>
</section1>
<section1 topic='Terminology' anchor='terms'>
<p>The following terms are used throughout this JEP.</p>
<p>The following terms are used throughout this document.</p>
<table caption='Glossary of Entities'>
<tr>
<th>Term</th><th>Description</th>
@ -191,7 +191,7 @@
</section1>
<section1 topic='Protocol' anchor='proto'>
<section2 topic='Initiator Queries Target Regarding Bytestreams Support' anchor='proto-disco'>
<p>Before attempting to initiate a bytestream, the Initiator may want to know if the Target supports the bytestream protocol. It may do so using &jep0030; as follows:</p>
<p>Before attempting to initiate a bytestream, the Initiator may want to know if the Target supports the bytestream protocol. It may do so using &xep0030; as follows:</p>
<example caption='Initiator Sends Service Discovery Request to Target'><![CDATA[
<iq type='get'
from='initiator@host1/foo'
@ -308,7 +308,7 @@
</query>
</iq>
]]></example>
<p>If the Initiator does not have permissions to initiate bytestreams on the Proxy for whatever reason (e.g., a proxy implementation may enable administrators to ban JIDs or domains from using the Proxy), the Proxy MUST return a &forbidden; error to the Initiator (for information about error syntax, refer to &jep0086;):</p>
<p>If the Initiator does not have permissions to initiate bytestreams on the Proxy for whatever reason (e.g., a proxy implementation may enable administrators to ban JIDs or domains from using the Proxy), the Proxy MUST return a &forbidden; error to the Initiator (for information about error syntax, refer to &xep0086;):</p>
<example caption='Proxy Returns Error to Initiator'><![CDATA[
<iq type='error'
from='initiator@host1/foo'
@ -385,7 +385,7 @@
</error>
</iq>
]]></example>
<p>If the Target is able to open a TCP socket on a StreamHost, it MUST utilize the SOCKS5 protocol specified in &rfc1928; to establish the connection with the StreamHost. In accordance with the SOCKS5 RFC, the Target MAY have to authenticate in order to use the proxy. However, any authentication required is beyond the scope of this JEP.</p>
<p>If the Target is able to open a TCP socket on a StreamHost, it MUST utilize the SOCKS5 protocol specified in &rfc1928; to establish the connection with the StreamHost. In accordance with the SOCKS5 RFC, the Target MAY have to authenticate in order to use the proxy. However, any authentication required is beyond the scope of this document.</p>
<p>Once the Target has successfully authenticated with the Proxy (even anonymously), it SHOULD send a CONNECT request to a host named: SHA1(SID + Initiator JID + Target JID), port 0, where the SHA1 hashing algorithm is specified by &rfc3174;. The JIDs provided MUST be full JIDs (i.e., &lt;user@host/resource&gt;); furthermore, in order to ensure proper results, the appropriate stringprep profiles (as specified in &xmppcore;) MUST be applied to the JIDs before application of the SHA1 hashing algorithm.</p>
<example caption='Target Connects to StreamHost'><![CDATA[
CMD = X'01'
@ -719,20 +719,20 @@ DATA = (payload)
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This proposal does not include a method for securing or encrypting SOCKS5 bytetreams. If such security is desired, it MUST be negotiated over the bytestream (once established) using standard protocols such as SSL or TLS. Negotiation of such security methods is outside the scope of this JEP.</p>
<p>This proposal does not include a method for securing or encrypting SOCKS5 bytetreams. If such security is desired, it MUST be negotiated over the bytestream (once established) using standard protocols such as SSL or TLS. Negotiation of such security methods is outside the scope of this document.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/bytestreams' in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Service Discovery Features' anchor='registrar-discovar'>
<p>The Jabber Registrar shall includes 'http://jabber.org/protocol/bytestreams#udp' in its registry of service discovery features.</p>
<p>The XMPP Registrar shall includes 'http://jabber.org/protocol/bytestreams#udp' in its registry of service discovery features.</p>
</section2>
<section2 topic='Service Discovery Category/Type' anchor='registrar-discoid'>
<p>The Jabber Registrar includes the "proxy" category and associated "bytestreams" type in the Service Discovery registry. The registry submission is as follows:</p>
<p>The XMPP Registrar includes the "proxy" category and associated "bytestreams" type in the Service Discovery registry. The registry submission is as follows:</p>
<code><![CDATA[
<category>
<name>proxy</name>
@ -740,7 +740,7 @@ DATA = (payload)
<type>
<name>bytestreams</name>
<desc>A proxy for SOCKS5 bytestreams</desc>
<doc>JEP-0065</doc>
<doc>XEP-0065</doc>
</type>
</category>
]]></code>
@ -759,7 +759,7 @@ DATA = (payload)
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0065: http://www.jabber.org/jeps/jep-0065.html
XEP-0065: http://www.xmpp.org/extensions/xep-0065.html
</xs:documentation>
</xs:annotation>
@ -824,4 +824,4 @@ DATA = (payload)
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

26
xep-0066.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>Out of Band Data</title>
<abstract>This document provides canonical documentation of two XMPP protocol extensions for communicating URIs.</abstract>
@ -21,11 +21,11 @@
<shortname>oob</shortname>
<schemaloc>
<ns>jabber:iq:oob</ns>
<url>http://jabber.org/protocol/oob/iq-oob.xsd</url>
<url>http://www.xmpp.org/schemas/iq-oob.xsd</url>
</schemaloc>
<schemaloc>
<ns>jabber:x:oob</ns>
<url>http://jabber.org/protocol/oob/x-oob.xsd</url>
<url>http://www.xmpp.org/schemas/x-oob.xsd</url>
</schemaloc>
&stpeter;
<revision>
@ -44,7 +44,7 @@
<version>1.3</version>
<date>2004-10-18</date>
<initials>psa</initials>
<remark><p>Added non-normative section on integration with stream initiation (JEP-0095); added optional sid attribute to jabber:iq:oob schema.</p></remark>
<remark><p>Added non-normative section on integration with stream initiation (XEP-0095); added optional sid attribute to jabber:iq:oob schema.</p></remark>
</revision>
<revision>
<version>1.2</version>
@ -87,8 +87,8 @@
<p>This document defines two XMPP protocol extensions for communicating URIs between Jabber entities, where the data formats are qualified by the 'jabber:iq:oob' and 'jabber:x:oob' namespaces. Although these mechanisms were originally used for out-of-band (OOB) data transfer, they are also used more generally to exchange or communicate URIs.</p>
</section1>
<section1 topic='jabber:iq:oob' anchor='iq-oob'>
<p>The intent of the 'jabber:iq:oob' was to provide a "least common denominator" mechanism for basic file transfers. Although &jep0096; defines a more generic method for communicating file exchange options, the 'jabber:iq:oob' namespace can be included as one option therein since it provides a fallback mechanism when clients do not support file transfer options such as those defined in &jep0065; and &jep0047;.</p>
<p>To initiate an out-of-band file transfer with an intended recipient using the 'jabber:iq:oob' namespace (whether or not negotiated via <cite>JEP-0096</cite>), the sending application sends an &IQ; of type 'set' to the recipient containing a &QUERY; child element qualified by the 'jabber:iq:oob' namespace; the &QUERY; MUST in turn contain a &lt;url/&gt; child specifying the URL of the file to be transferred, and MAY contain an optional &lt;desc/&gt; child describing the file. This usage is shown in the following example.</p>
<p>The intent of the 'jabber:iq:oob' was to provide a "least common denominator" mechanism for basic file transfers. Although &xep0096; defines a more generic method for communicating file exchange options, the 'jabber:iq:oob' namespace can be included as one option therein since it provides a fallback mechanism when clients do not support file transfer options such as those defined in &xep0065; and &xep0047;.</p>
<p>To initiate an out-of-band file transfer with an intended recipient using the 'jabber:iq:oob' namespace (whether or not negotiated via <cite>XEP-0096</cite>), the sending application sends an &IQ; of type 'set' to the recipient containing a &QUERY; child element qualified by the 'jabber:iq:oob' namespace; the &QUERY; MUST in turn contain a &lt;url/&gt; child specifying the URL of the file to be transferred, and MAY contain an optional &lt;desc/&gt; child describing the file. This usage is shown in the following example.</p>
<example caption="Sender Initiates Request-Response"><![CDATA[
<iq type='set'
from='stpeter@jabber.org/work'
@ -155,7 +155,7 @@
</section1>
<section1 topic='Integration With Stream Initiation' anchor='si'>
<p><em>This section is non-normative.</em></p>
<p>&jep0095; defines methods for negotiating content streams between any two entities, and JEP-0096 defines a profile of stream initiation for file transfer. Although the use of jabber:iq:oob is not recommended by JEP-0096, it could be offered as one option (e.g., a fallback if SOCKS5 Bytestreams and In-Band Bytestreams are not available). If so, the value of the feature negotiation option MUST be "jabber:iq:oob" and the &QUERY; element within the &IQ; stanza qualified by the 'jabber:iq:oob' namespace MUST possess a 'sid' attribute whose value is the StreamID negotiated by stream initiation.</p>
<p>&xep0095; defines methods for negotiating content streams between any two entities, and XEP-0096 defines a profile of stream initiation for file transfer. Although the use of jabber:iq:oob is not recommended by XEP-0096, it could be offered as one option (e.g., a fallback if SOCKS5 Bytestreams and In-Band Bytestreams are not available). If so, the value of the feature negotiation option MUST be "jabber:iq:oob" and the &QUERY; element within the &IQ; stanza qualified by the 'jabber:iq:oob' namespace MUST possess a 'sid' attribute whose value is the StreamID negotiated by stream initiation.</p>
<p>A sample protocol flow is shown below.</p>
<example caption='Stream Initiation Offer'>
<![CDATA[
@ -244,7 +244,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0066: http://www.jabber.org/jeps/jep-0066.html
XEP-0066: http://www.xmpp.org/extensions/xep-0066.html
</xs:documentation>
</xs:annotation>
@ -274,7 +274,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0066: http://www.jabber.org/jeps/jep-0066.html
XEP-0066: http://www.xmpp.org/extensions/xep-0066.html
</xs:documentation>
</xs:annotation>
@ -291,4 +291,4 @@
]]></code>
</section2>
</section1>
</jep>
</xep>

14
xep-0067.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>Stock Data Transmission</title>
<abstract>This JEP specifies a data format for stock data distribution in the Jabber community.</abstract>
@ -13,7 +13,7 @@
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<dependencies>JEP-0060</dependencies>
<dependencies>XEP-0060</dependencies>
<author>
<firstname>Ulrich</firstname>
<surname>Staudinger</surname>
@ -44,7 +44,7 @@
<section1 topic='Introduction'>
<p>
Usage of jabber/xmpp for stock data transmission would be a nice-to-have. This jep defines transmission of stock ticker values via XMPP based on publish/subscribe. A component, client or alike may publish stock data in this specified way, after creating a node. However, first of all a node on the pub/sub server must be created, this jep recommends creation of the node in the domain 'stocks/', with specific stock value published in the ticker name domain space, i.e. 'stocks/CATG.DE' or 'stocks/602345'. This jep uses the domain 'stocks/' for example data.
Usage of jabber/xmpp for stock data transmission would be a nice-to-have. This xep defines transmission of stock ticker values via XMPP based on publish/subscribe. A component, client or alike may publish stock data in this specified way, after creating a node. However, first of all a node on the pub/sub server must be created, this xep recommends creation of the node in the domain 'stocks/', with specific stock value published in the ticker name domain space, i.e. 'stocks/CATG.DE' or 'stocks/602345'. This xep uses the domain 'stocks/' for example data.
</p>
<p>
So, what this JEP comes down to: it defines the data architecture for stock data and it specifies, that a 'stocks/' node is recommended to exist, which again holds all symbols as subnodes, which again hold either '/realtime', '/bar' or '/news' as subnodes. The 'bar' subnode contains a 'time descriptor' subnode. The sort of the symbols is defined through the service provider, who can i.e. support Y!ahoo finance symbols, (german) WKNs or official stock symbols.
@ -196,5 +196,5 @@ The 'StockComponent' (http://www.die-horde.de) is a partial component implementa
</jep>
</xep>

42
xep-0068.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>Field Standardization for Data Forms</title>
<abstract>This JEP specifies how to standardize field variables used in the context of jabber:x:data forms.</abstract>
<abstract>This document specifies how to standardize field variables used in the context of jabber:x:data forms.</abstract>
&LEGALNOTICE;
<number>0068</number>
<status>Active</status>
@ -15,7 +15,7 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0004</spec>
<spec>XEP-0004</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -55,9 +55,9 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Now that &jep0004; has been finalized, several uses of jabber:x:data forms have been put on the standards track, including &jep0045;. These protocols typically need a way to gather data from both humans (using a GUI format) and computer processes (using a pre-defined but flexible format).</p>
<p>Now that &xep0004; has been finalized, several uses of jabber:x:data forms have been put on the standards track, including &xep0045;. These protocols typically need a way to gather data from both humans (using a GUI format) and computer processes (using a pre-defined but flexible format).</p>
<p>The 'jabber:x:data' namespace provides an adequate mechanism for both of these uses, as long as computer processes can rely on the var=&quot;&quot; names on a particular type of form.</p>
<p>This JEP proposes a specific mechanism for the &REGISTRAR; to standardize these form field variable names. Thus this JEP enables existing clients to process forms as they have to this point, but enables JEP authors to specify a mechanism for non-GUI processors of those forms to determine the semantic meanings of those forms.</p>
<p>This document proposes a specific mechanism for the &REGISTRAR; to standardize these form field variable names. Thus this document enables existing clients to process forms as they have to this point, but enables protocol authors to specify a mechanism for non-GUI processors of those forms to determine the semantic meanings of those forms.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<ol>
@ -76,10 +76,10 @@
<p>Within Jabber, namespaces are used to scope data that conforms to a schema (often data that extends the core protocol in some fashion). In addition, namespaces can also provide context for the field variable names used in jabber:x:data forms and reports. This proposal makes that link explicit by defining a mechanism for linking a namespace name with a form and the field names and types used in that form. Specifically, the namespace name is specified in the form as the value of a hidden variable called "FORM_TYPE".</p>
</section2>
<section2 topic='Whether to Register' anchor='approach-register'>
<p>The first decision-point is whether a FORM_TYPE needs to be registered with the Jabber Registrar. The following rules apply:</p>
<p>The first decision-point is whether a FORM_TYPE needs to be registered with the XMPP Registrar. The following rules apply:</p>
<ol>
<li>If the FORM_TYPE is used in the context of a form defined in a JEP, it MUST be registered.</li>
<li>If the FORM_TYPE is used in the context of a JSF-managed protocol but the form is not defined in a JEP, it MAY be registered.</li>
<li>If the FORM_TYPE is used in the context of a form defined in a XEP, it MUST be registered.</li>
<li>If the FORM_TYPE is used in the context of a JSF-managed protocol but the form is not defined in a XEP, it MAY be registered.</li>
<li>If the FORM_TYPE is used in the context of a custom protocol, it MAY be registered.</li>
</ol>
</section2>
@ -92,15 +92,15 @@
</ol>
</section2>
<section2 topic='Field Names' anchor='approach-fieldnames'>
<p>For FORM_TYPEs that are registered with the Jabber Registrar, the field names MUST conform to one of the following two conditions:</p>
<p>For FORM_TYPEs that are registered with the XMPP Registrar, the field names MUST conform to one of the following two conditions:</p>
<ol>
<li>If the field name is defined by the relevant JEP or by registration, the field name MUST be registered with the Jabber Registrar and MAY have any name (except a name that begins with "x-"), subject to approval by the Jabber Registrar.</li>
<li>If the field name is defined by the relevant XEP or by registration, the field name MUST be registered with the XMPP Registrar and MAY have any name (except a name that begins with "x-"), subject to approval by the XMPP Registrar.</li>
<li>If the field name is unregistered, the field name MUST begin with "x-".</li>
</ol>
<p>If the FORM_TYPE is not registered, the field name MAY have any name (presumably managed by the namespace "owner").</p>
</section2>
<section2 topic='Field Values' anchor='approach-values'>
<p>Field values may also be registered; refer to the <link url='registrar'>Jabber Registrar</link> section of this document.</p>
<p>Field values may also be registered; refer to the <link url='registrar'>XMPP Registrar</link> section of this document.</p>
</section2>
</section1>
@ -132,7 +132,7 @@
]]></example>
</section2>
<section2 topic='Correctly Specified FORM_TYPE' anchor='usecases-correct'>
<p>In the following example, the FORM_TYPE is 'http://jabber.org/protocol/pubsub', and all of the fields whose var names start with pubsub_ would be registered with the Jabber Registrar, associated with that namespace.</p>
<p>In the following example, the FORM_TYPE is 'http://jabber.org/protocol/pubsub', and all of the fields whose var names start with pubsub_ would be registered with the XMPP Registrar, associated with that namespace.</p>
<example caption='Message with FORM_TYPE'><![CDATA[
<message to="node-owner" from="pubsub.jabber.org">
@ -329,13 +329,13 @@
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA; for now. However, if this JEP is submitted to the IETF later, IANA should be used to standardize the field names rather than the Jabber Registrar.</p>
<p>This document requires no interaction with &IANA; for now. However, if this document is submitted to the IETF later, IANA should be used to standardize the field names rather than the XMPP Registrar.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Registries' anchor='registrar-reg'>
<section3 topic='FORM_TYPEs Registry' anchor='registrar-reg-formtypes'>
<p>The Jabber Registrar shall maintain a registry of information about submitted FORM_TYPEs.</p>
<p>The XMPP Registrar shall maintain a registry of information about submitted FORM_TYPEs.</p>
<section4 topic='Process' anchor='registrar-reg-formtypes-process'>
&REGPROCESS;
<code><![CDATA[
@ -349,12 +349,12 @@
label='natural-language description of field'/>
</form_type>
]]></code>
<p>The registrant MAY register more than one FORM_TYPE at a time, each contained in a separate &lt;form_type/&gt; element. The registrant MAY also register more than one field at a time, each contained in a separate &lt;field/&gt; child element. Registrations of new fields within an existing FORM_TYPE MUST include the full XML snippet but SHOULD NOT include the FORM_TYPE description (only the name and the JEP number or other document identifier). Note that for ease of use the format for the &lt;field/&gt; element in the registry submission is the same as that defined in JEP-0004; in addition, the value of the 'type' attribute MUST be one of those defined in that JEP-0004.</p>
<p>The registrant MAY register more than one FORM_TYPE at a time, each contained in a separate &lt;form_type/&gt; element. The registrant MAY also register more than one field at a time, each contained in a separate &lt;field/&gt; child element. Registrations of new fields within an existing FORM_TYPE MUST include the full XML snippet but SHOULD NOT include the FORM_TYPE description (only the name and the XEP number or other document identifier). Note that for ease of use the format for the &lt;field/&gt; element in the registry submission is the same as that defined in XEP-0004; in addition, the value of the 'type' attribute MUST be one of those defined in that XEP-0004.</p>
<p>In addition, a registrant MAY also register particular field option values for fields of type 'list-single' and 'list-multi'. The format for such submissions is as follows:</p>
<code><![CDATA[
<form_type>
<name>FORM_TYPE namespace or namespace derivative</name>
<doc>associated JEP or other document</doc>
<doc>associated XEP or other document</doc>
<desc>natural-language description of form type</desc>
<field
var='the_field_name'
@ -371,4 +371,4 @@
</section2>
</section1>
</jep>
</xep>

10
xep-0069.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>Compliance JIG</title>
<abstract>A proposal to form a JIG devoted to issues related to protocol compliance.</abstract>
@ -48,4 +48,4 @@
<li>Logo requirements</li>
</ul>
</section1>
</jep>
</xep>