From fe1d5643e882b859372d737e12bed8dd28e99494 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 3 Oct 2006 23:25:20 +0000 Subject: [PATCH] JEP to XEP git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@34 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0060.xml | 206 +++++++++++++++++++++++++-------------------------- xep-0061.xml | 14 ++-- xep-0062.xml | 22 +++--- xep-0063.xml | 20 ++--- xep-0064.xml | 20 ++--- xep-0065.xml | 44 +++++------ xep-0066.xml | 26 +++---- xep-0067.xml | 14 ++-- xep-0068.xml | 42 +++++------ xep-0069.xml | 10 +-- 10 files changed, 209 insertions(+), 209 deletions(-) diff --git a/xep-0060.xml b/xep-0060.xml index b2404c02..ea158ab6 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
Publish-Subscribe This document specifies an XMPP protocol extension for generic publish-subscribe functionality. @@ -18,30 +18,30 @@ Standards JIG XMPP Core - JEP-0004 - JEP-0030 - JEP-0068 - JEP-0082 - JEP-0131 + XEP-0004 + XEP-0030 + XEP-0068 + XEP-0082 + XEP-0131 pubsub pubsub - http://jabber.org/protocol/pubsub/pubsub.xsd + http://www.xmpp.org/schemas/pubsub.xsd pubsub#errors - http://jabber.org/protocol/pubsub/errors.xsd + http://www.xmpp.org/schemas/pubsub-errors.xsd pubsub#event - http://jabber.org/protocol/pubsub/event.xsd + http://www.xmpp.org/schemas/pubsub-event.xsd pubsub#owner - http://jabber.org/protocol/pubsub/owner.xsd + http://www.xmpp.org/schemas/pubsub-owner.xsd &pgmillard; @@ -137,7 +137,7 @@ 1.5 2004-07-07 pgm/psa -

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.

 +

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.

 1.4 @@ -161,7 +161,7 @@ 1.1 2004-01-14 psa -

Added Jabber Registrar Considerations subsection for Service Discovery category/type registration.

 +

Added XMPP Registrar Considerations subsection for Service Discovery category/type registration.

 1.0 @@ -197,7 +197,7 @@ 0.12 2003-08-13 pgm/psa -

Defined public vs. private nodes; described how changes to existing nodes might trigger meta-node events (e.g., configuration changes); changed <x/> to <event/> for #events namespace; added meta-data about meta-nodes; fully defined Jabber Registrar considerations.

 +

Defined public vs. private nodes; described how changes to existing nodes might trigger meta-node events (e.g., configuration changes); changed <x/> to <event/> for #events namespace; added meta-data about meta-nodes; fully defined XMPP Registrar considerations.

 0.11 @@ -221,7 +221,7 @@ 0.8 2003-04-03 pgm -

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.

 +

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.

 0.7 @@ -245,13 +245,13 @@ 0.4 2003-01-21 pgm -

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 "last items" to "most recent items". Removed default configuration acceptance -- owners should just cancel. Added the notify_retract configuration option. Clarified error handling for affiliation modifications.

+

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 "last items" to "most recent items". Removed default configuration acceptance -- owners should just cancel. Added the notify_retract configuration option. Clarified error handling for affiliation modifications.

0.3 2003-01-20 pgm -

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.

+

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.

0.2 @@ -364,7 +364,7 @@ And by opposing end them?

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.)

- + @@ -379,7 +379,7 @@ And by opposing end them? - + @@ -419,7 +419,7 @@ And by opposing end them? -

To manage permissions, the protocol defined herein uses a hierarchy of affiliations, similiar to those introduced in &jep0045;.

+

To manage permissions, the protocol defined herein uses a hierarchy of affiliations, similiar to those introduced in &xep0045;.

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.

Authorize Access ModelA 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.
Address(1) A JID as defined in &xmppcore;, or (2) the combination of a JID and a &jep0030; node.
Address(1) A JID as defined in &xmppcore;, or (2) the combination of a JID and a &xep0030; node.
Collection NodeA type of node that contains nodes and/or other collections but no published items. Collections make it possible to represent hierarchial node structures.
EntityA JID-addressable Jabber entity (client, service, application, etc.).
EventA change in the state of a node.
OwnerThe manager of a node, of which there may be more than one; often but not necessarily the node creator.
PayloadThe full data associated with an event rather than just the event notification itself.
Open Access ModelA node access model under which any entity may subscribe and retrieve items without approval.
Personal EventingA 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;.
Personal EventingA 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;.
Presence Access ModelA 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.
PublisherAn entity that is allowed to publish items to a node.
Pubsub ServiceAn XMPP server or component that adheres to the protocol defined herein.
@@ -606,7 +606,7 @@ And by opposing end them? -

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. These nodes are equivalent to those used in JEP-0030: Service Discovery.

+

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. These nodes are equivalent to those used in XEP-0030: Service Discovery.

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 RFC 3920.

Consider the following example, in which the pubsub service is located at the hostname pubsub.shakespeare.lit.

@@ -658,11 +658,11 @@ And by opposing end them? ]]> -

The possible pubsub features are noted throughout this document and have been registered as described in the Jabber Registrar Considerations section of this document. For information regarding which features are required, recommended, and optional, see the Feature Summary section of this document.

+

The possible pubsub features are noted throughout this document and have been registered as described in the XMPP Registrar Considerations section of this document. For information regarding which features are required, recommended, and optional, see the Feature Summary section of this document.

 -

If a service implements a hierarchy of nodes (by means of Collection Nodes), it MUST also enable entities to discover the nodes in that hierarchy by means of the Service Discovery protocol, subject to the recommendations in JEP-0030 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.

+

If a service implements a hierarchy of nodes (by means of Collection Nodes), it MUST also enable entities to discover the nodes in that hierarchy by means of the Service Discovery protocol, subject to the recommendations in XEP-0030 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.

Note: Node hierarchies and collection nodes are OPTIONAL. For details, refer to the NodeID Semantics and Collection Nodes sections of this document.

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 Collection Node:

 -

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.

+

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.

Much of the meta-data provided about a node maps directly to selected &DUBLINCORE; meta-data attributes; specifically:

- + @@ -1016,7 +1016,7 @@ And by opposing end them? ]]> -

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.)

+

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.)

@@ -1486,7 +1486,7 @@ And by opposing end them? ]]> -

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 Data Forms 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 pubsub#subscribe_options FORM_TYPE 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).

+

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 Data Forms 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 pubsub#subscribe_options FORM_TYPE 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).

Note: Many of the relevant data form fields are of type "boolean" and MUST be handled accordingly. &BOOLEANNOTE;

There are several reasons why the options request might fail:

    @@ -1998,7 +1998,7 @@ And by opposing end them? ]]> -

    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.)

    +

    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.)

    -

    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).

    +

    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).

    @@ -2902,7 +2902,7 @@ And by opposing end them? ]]> -

    Note: The following example shows some of the possible configuration options that MAY be provided. If an implementation implements these features using the Data Forms 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 pubsub#node_config FORM_TYPE 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.

    +

    Note: The following example shows some of the possible configuration options that MAY be provided. If an implementation implements these features using the Data Forms 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 pubsub#node_config FORM_TYPE 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.

    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.

    -

    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".

    +

    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".

    Entities are required to register before node creation is allowed.
Pubsub FieldDublin Core Meta-Data Attribute
pubsub#creation_dateDate The value SHOULD be a DateTime as defined in JEP-0082, and MUST conform to one of the profiles defined therein.
pubsub#creation_dateDate The value SHOULD be a DateTime as defined in XEP-0082, and MUST conform to one of the profiles defined therein.
pubsub#creatorCreator
pubsub#descriptionDescription
pubsub#languageLanguage
-

Note: Refer to &jep0086; for more information regarding error syntax.

+

Note: Refer to &xep0086; for more information regarding error syntax.

@@ -4787,7 +4787,7 @@ And by opposing end them?

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.

-

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 RFC 3920 and JEP-0086 regarding XMPP error condition semantics):

+

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 RFC 3920 and XEP-0086 regarding XMPP error condition semantics):

  • If the XMPP error is of type "cancel" (e.g., ¬found;), 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.
  • If the XMPP error is of type "auth" (e.g., ®istration;) or "wait" (e.g., &timeout;), or the error condition is &badrequest;, &redirect;, or ¬acceptable;, 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.
    • @@ -4799,10 +4799,10 @@ And by opposing end them? -

    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:

    +

    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:

    • Use presence-based subscription options as described above.
      • -
    • Use delivery semantics as defined by &jep0079;.
      • +
    • Use delivery semantics as defined by &xep0079;.
    • Specify a message type of "headline", which in most existing server implementations will prevent offline storage.
     @@ -4836,7 +4836,7 @@ And by opposing end them?

    How subscription requests are sent to node owners is a matter of implementation. Possibilities include:

      -
    • Send requests to all owners (these may be placed in offline storage as described in JEP-0160) and first approval wins.
      • +
    • Send requests to all owners (these may be placed in offline storage as described in XEP-0160) and first approval wins.
    • The service could subscribe to owner presence, and send only to the owners that are online.
    • All owners vote on the new subscriber.
    • Any owner is allowed to veto the subscriber.
      • @@ -4886,7 +4886,7 @@ And by opposing end them? -

      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 JEP-0030). The potential subscriber may then send a "disco#items" request to the user's bare JID (<user@host>), 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.

      +

      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 XEP-0030). The potential subscriber may then send a "disco#items" request to the user's bare JID (<user@host>), 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.

      ]]> -

      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 JEP-0163.

      +

      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 XEP-0163.

       @@ -4927,7 +4927,7 @@ And by opposing end them?

      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:

        -
      • 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 about the user's geolocation and therefore all replies should go to the user (who is probably the node owner).
        • +
      • 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 about the user's geolocation and therefore all replies should go to the user (who is probably the node owner).
      • 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.
      • 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.
      @@ -4958,7 +4958,7 @@ And by opposing end them? ]]> -

      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 JEP-0163.

      +

      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 XEP-0163.

       @@ -4967,7 +4967,7 @@ And by opposing end them? -

      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;).

      +

      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;).

      The leasing process is shown below.

      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. 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.

      -

      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.

      +

      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.

      A fictional example of the subscription options configuration process for content-based pubsub is shown below.

      -

      This JEP does not require interaction with &IANA;.

      +

      This document does not require interaction with &IANA;.

       - +

      The ®ISTRAR; includes the following namespaces in its registry of protocol namespaces (see &NAMESPACES;):

      @@ -5261,7 +5261,7 @@ O, what a rogue and peasant slave am I!       -

      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:

      +

      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:

      @@ -5273,187 +5273,187 @@ O, what a rogue and peasant slave am I! - +
      collection
      serviceA pubsub service that supports the functionality defined in JEP-0060. Prior to version 1.5 of JEP-0060, this type was called "generic".A pubsub service that supports the functionality defined in XEP-0060. Prior to version 1.5 of XEP-0060, this type was called "generic".

      The registry submission is as follows:

      pubsub - Services and nodes that adhere to JEP-0060. + Services and nodes that adhere to XEP-0060. collection A pubsub node of the "collection" type. - JEP-0060 + XEP-0060 leaf A pubsub node of the "leaf" type. - JEP-0060 + XEP-0060 service - A pubsub service that supports the functionality defined in JEP-0060. - JEP-0060 + A pubsub service that supports the functionality defined in XEP-0060. + XEP-0060 ]]> -

      Future submissions to the Jabber Registrar may register additional types.

      +

      Future submissions to the XMPP Registrar may register additional types.

       -

      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.

      +

      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.

      http://jabber.org/protocol/pubsub#collections Collection nodes are supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#config-node Configuration of node options is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#create-and-configure Simultaneous creation and configuration of nodes is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#create-nodes Creation of nodes is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#delete-any Any publisher may delete an item (not only the originating publisher). - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#delete-nodes Deletion of nodes is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#get-pending Retrieval of pending subscription approvals is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#instant-nodes Creation of instant nodes is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#item-ids Publishers may specify item identifiers. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#leased-subscription Time-based subscriptions are supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#meta-data Node meta-data is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#manage-subscription Node owners may manage subscriptions. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#modify-affiliations Node owners may modify affiliations. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#multi-collection A single leaf node may be associated with multiple collections. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#multi-subscribe A single entity may subscribe to a node multiple times. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#outcast-affiliation The outcast affiliation is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#persistent-items Persistent items are supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#presence-notifications Presence-based delivery of event notifications is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#publish Publishing items is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#publisher-affiliation The publisher affiliation is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#purge-nodes Purging of nodes is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#retract-items Item retraction is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#retrieve-affiliations Retrieval of current affiliations is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#retrieve-default Retrieval of default node configuration is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#retrieve-items Item retrieval is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#retrieve-subscriptions Retrieval of current subscriptions is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#subscribe Subscribing and unsubscribing are supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#subscription-options Configuration of subscription options is supported. - JEP-0060 + XEP-0060 http://jabber.org/protocol/pubsub#subscription-notifications Notification of subscription state changes is supported. - JEP-0060 + XEP-0060 ]]>       -

      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:

      +

      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:

      1. Authorization of subscriptions using the 'http://jabber.org/protocol/pubsub#subscribe_authorization' namespace.
      2. Configuration of subscription options using the 'http://jabber.org/protocol/pubsub#subscribe_options' namespace.
        3. @@ -5461,13 +5461,13 @@ O, what a rogue and peasant slave am I!
      3. Setting of meta-data information using the 'http://jabber.org/protocol/pubsub#meta-data' namespace.

      The registry submissions associated with these namespaces are defined below.

      -

      Note: There is no requirement that configuration fields need to be registered with the Jabber Registrar. However, as specified in Section 3.4 of JEP-0068, names of custom (unregistered) fields MUST begin with the characters "x-" if the form itself is scoped by a registered FORM_TYPE.

      +

      Note: There is no requirement that configuration fields need to be registered with the XMPP Registrar. However, as specified in Section 3.4 of XEP-0068, names of custom (unregistered) fields MUST begin with the characters "x-" if the form itself is scoped by a registered FORM_TYPE.

      http://jabber.org/protocol/pubsub#subscribe_authorization - JEP-0060 + XEP-0060 Forms enabling authorization of subscriptions to pubsub nodes http://jabber.org/protocol/pubsub#subscribe_options - JEP-0060 + XEP-0060 Forms enabling configuration of subscription options for pubsub nodes http://jabber.org/protocol/pubsub#node_config - JEP-0060 + XEP-0060 Forms enabling configuration of pubsub nodes http://jabber.org/protocol/pubsub#meta-data - JEP-0060 + XEP-0060 Forms enabling setting of meta-data information about pubsub nodes       -

      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:

      +

      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:

      pubsub#collection The collection via which a notification was received from the originating node. - JEP-0060 + XEP-0060
pubsub#expire The DateTime at which a pubsub leased subscription will end or has ended. - JEP-0060 + XEP-0060
pubsub#subid A subscription identifer within the pubsub protocol. - JEP-0060 + XEP-0060
]]> -

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.

+

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.

-

As authorized by &jep0147;, the Jabber Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).

+

As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).

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).

pubsub http://jabber.org/protocol/pubsub enables interaction with a publish-subscribe service - JEP-0060 + XEP-0060 action @@ -5853,7 +5853,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings 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 @@ -6061,9 +6061,9 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings 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 @@ -6153,7 +6153,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings 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 @@ -6297,7 +6297,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings 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 @@ -6426,4 +6426,4 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings

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.

- + diff --git a/xep-0061.xml b/xep-0061.xml index a3080d92..f8fabeb8 100644 --- a/xep-0061.xml +++ b/xep-0061.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
Shared Notes A simplistic mechanism for shared notes, modeled after common stickie note applications. @@ -27,7 +27,7 @@ 0.2 2003-09-30 psa - 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. + 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. 0.1 @@ -51,7 +51,7 @@ default on a save action by the user).

1X544O Council Votes - Need votes from bob, tom, and jane yet for JEP-0000 + Need votes from bob, tom, and jane yet for XEP-0000 #001122 #221100 @@ -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.

- + diff --git a/xep-0062.xml b/xep-0062.xml index 2ad819b1..22a25170 100644 --- a/xep-0062.xml +++ b/xep-0062.xml @@ -1,13 +1,13 @@ - + %ents; ]> - + - +
Packet Filtering A framework for packet filtering rules. @@ -16,7 +16,7 @@ Deferred Informational Standards JIG - XMPP Core, JEP-0030 + XMPP Core, XEP-0030 None None Not yet assigned @@ -30,7 +30,7 @@ 0.2 2003-09-30 psa - 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. + 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. 0.1 @@ -49,7 +49,7 @@
  • Bugs in the service often caused the Jabber server to crash.
    • -

    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;.

    +

    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;.

    However, packet filtering (as opposed to the subset of JID blacklisting) is still of use, for the following tasks:

    @@ -327,7 +327,7 @@ -

    Ruleset processing should be the first thing that a service does when it receives a packet - even before processing privacy rules per JEP-0016.

    +

    Ruleset processing should be the first thing that a service does when it receives a packet - even before processing privacy rules per XEP-0016.

    Rules must be processed in the order they are given, and must be returned to a requesting entity in the same order.

     @@ -337,11 +337,11 @@ -

    This JEP requires no interaction with the IANA.

    +

    This document requires no interaction with the IANA.

     -

    No namespaces or parameters need to be registered with JANA as a result of this JEP.

    +

    No namespaces or parameters need to be registered with JANA as a result of this document.

     - + diff --git a/xep-0063.xml b/xep-0063.xml index 35653cc7..3bd1d9b0 100644 --- a/xep-0063.xml +++ b/xep-0063.xml @@ -1,13 +1,13 @@ - + %ents; ]> - + - +
    Basic Filtering Operations A module that provides basic conditions and actions for packet filtering. @@ -16,7 +16,7 @@ Deferred Informational Standards JIG - JEP-0062 + XEP-0062 None None Not yet assigned @@ -30,7 +30,7 @@ 0.2 2003-09-30 psa - 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. + 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. 0.1 @@ -41,7 +41,7 @@
    -

    This document defines a module for &jep0062; that provides some basic conditions and actions to perform common packet filtering tasks.

    +

    This document defines a module for &xep0062; that provides some basic conditions and actions to perform common packet filtering tasks.

    This module operates in the "http://jabber.org/protocol/filter/basic" namespace.

     @@ -97,11 +97,11 @@ -

    This JEP requires no interaction with the IANA.

    +

    This document requires no interaction with the IANA.

     -

    No namespaces or parameters need to be registered with JANA as a result of this JEP.

    +

    No namespaces or parameters need to be registered with JANA as a result of this document.

     -     + diff --git a/xep-0064.xml b/xep-0064.xml index ee5d7c19..e7f9798d 100644 --- a/xep-0064.xml +++ b/xep-0064.xml @@ -1,13 +1,13 @@ - + %ents; ]> - + - +
    XPath Filtering A module that provides an XPath matching condition for packet filtering. @@ -16,7 +16,7 @@ Deferred Informational Standards JIG - JEP-0062 + XEP-0062 None None Not yet assigned @@ -30,7 +30,7 @@ 0.2 2003-09-30 psa - 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. + 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. 0.1 @@ -41,7 +41,7 @@
    -

    This document defines a module for &jep0062; that provides an XPath matching condition for packet filtering.

    +

    This document defines a module for &xep0062; that provides an XPath matching condition for packet filtering.

    This module operates in the "http://jabber.org/protocol/filter/xpath" namespace.

     @@ -68,11 +68,11 @@ -

    This JEP requires no interaction with the IANA.

    +

    This document requires no interaction with the IANA.

     -

    No namespaces or parameters need to be registered with JANA as a result of this JEP.

    +

    No namespaces or parameters need to be registered with JANA as a result of this document.

     -     + diff --git a/xep-0065.xml b/xep-0065.xml index 113d010f..06641848 100644 --- a/xep-0065.xml +++ b/xep-0065.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
    SOCKS5 Bytestreams - This JEP defines a protocol for establishing an out-of-band bytestream between any two Jabber entities. + This document defines an XMPP protocol extension for establishing an out-of-band bytestream between any two Jabber entities. &LEGALNOTICE; 0065 Draft @@ -17,13 +17,13 @@ XMPP Core RFC 1928 RFC 3174 - JEP-0030 + XEP-0030 bytestreams - http://jabber.org/protocol/bytestreams/bytestreams.xsd + http://www.xmpp.org/schemas/bytestreams.xsd &dizzyd; &linuxwolf; @@ -50,7 +50,7 @@ 1.3 2003-09-24 psa - Added disco#info <identity/> and corresponding Jabber Registrar submission; added XMPP error handling. + Added disco#info <identity/> and corresponding XMPP Registrar submission; added XMPP error handling. 1.2 @@ -114,16 +114,16 @@
    -

    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:

    +

    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:

    • Bytestreams are established over standard TCP connections (&rfc0793;) or UDP associations (&rfc0768;), where TCP support is REQUIRED and UDP support is OPTIONAL
    • Sockets may be direct (peer-to-peer) or mediated (established through a bytestreaming service)
    • Where possible, standard wire protocols are used
    -

    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.)

    +

    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.)

     -

    The following terms are used throughout this JEP.

    +

    The following terms are used throughout this document.

    @@ -191,7 +191,7 @@ -

    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:

    +

    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:

    ]]> -

    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;):

    +

    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;):

    ]]> -

    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.

    +

    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.

    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., <user@host/resource>); 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.

     -

    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.

    +

    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.

     -

    This JEP requires no interaction with &IANA;.

    +

    This document requires no interaction with &IANA;.

     - +

    The ®ISTRAR; includes 'http://jabber.org/protocol/bytestreams' in its registry of protocol namespaces.

     -

    The Jabber Registrar shall includes 'http://jabber.org/protocol/bytestreams#udp' in its registry of service discovery features.

    +

    The XMPP Registrar shall includes 'http://jabber.org/protocol/bytestreams#udp' in its registry of service discovery features.

     -

    The Jabber Registrar includes the "proxy" category and associated "bytestreams" type in the Service Discovery registry. The registry submission is as follows:

    +

    The XMPP Registrar includes the "proxy" category and associated "bytestreams" type in the Service Discovery registry. The registry submission is as follows:

    proxy @@ -740,7 +740,7 @@ DATA = (payload) bytestreams A proxy for SOCKS5 bytestreams - JEP-0065 + XEP-0065 ]]> @@ -759,7 +759,7 @@ DATA = (payload) 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 @@ -824,4 +824,4 @@ DATA = (payload) ]]>     - + diff --git a/xep-0066.xml b/xep-0066.xml index a2bfec53..27c04927 100644 --- a/xep-0066.xml +++ b/xep-0066.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    Out of Band Data This document provides canonical documentation of two XMPP protocol extensions for communicating URIs. @@ -21,11 +21,11 @@ oob jabber:iq:oob - http://jabber.org/protocol/oob/iq-oob.xsd + http://www.xmpp.org/schemas/iq-oob.xsd jabber:x:oob - http://jabber.org/protocol/oob/x-oob.xsd + http://www.xmpp.org/schemas/x-oob.xsd &stpeter; @@ -44,7 +44,7 @@ 1.3 2004-10-18 psa -

    Added non-normative section on integration with stream initiation (JEP-0095); added optional sid attribute to jabber:iq:oob schema.

     +

    Added non-normative section on integration with stream initiation (XEP-0095); added optional sid attribute to jabber:iq:oob schema.

         1.2 @@ -87,8 +87,8 @@

    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.

    -

    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;.

    -

    To initiate an out-of-band file transfer with an intended recipient using the 'jabber:iq:oob' namespace (whether or not negotiated via JEP-0096), 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 <url/> child specifying the URL of the file to be transferred, and MAY contain an optional <desc/> child describing the file. This usage is shown in the following example.

    +

    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;.

    +

    To initiate an out-of-band file transfer with an intended recipient using the 'jabber:iq:oob' namespace (whether or not negotiated via XEP-0096), 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 <url/> child specifying the URL of the file to be transferred, and MAY contain an optional <desc/> child describing the file. This usage is shown in the following example.

    This section is non-normative.

    -

    &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.

    +

    &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.

    A sample protocol flow is shown below.

    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 @@ -274,7 +274,7 @@ 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 @@ -291,4 +291,4 @@ ]]>     - + diff --git a/xep-0067.xml b/xep-0067.xml index bd61768f..93e29014 100644 --- a/xep-0067.xml +++ b/xep-0067.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    Stock Data Transmission This JEP specifies a data format for stock data distribution in the Jabber community. @@ -13,7 +13,7 @@ Deferred Standards Track Standards JIG -JEP-0060 +XEP-0060 Ulrich Staudinger @@ -44,7 +44,7 @@

    -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.

    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 - + diff --git a/xep-0068.xml b/xep-0068.xml index 84debd94..88bd037f 100644 --- a/xep-0068.xml +++ b/xep-0068.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +

    Field Standardization for Data Forms - This JEP specifies how to standardize field variables used in the context of jabber:x:data forms. + This document specifies how to standardize field variables used in the context of jabber:x:data forms. &LEGALNOTICE; 0068 Active @@ -15,7 +15,7 @@ Standards JIG XMPP Core - JEP-0004 + XEP-0004 @@ -55,9 +55,9 @@
    -

    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).

    +

    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).

    The 'jabber:x:data' namespace provides an adequate mechanism for both of these uses, as long as computer processes can rely on the var="" names on a particular type of form.

    -

    This JEP proposes a specific mechanism for the ®ISTRAR; 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.

    +

    This document proposes a specific mechanism for the ®ISTRAR; 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.
      @@ -76,10 +76,10 @@

      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".

      -

      The first decision-point is whether a FORM_TYPE needs to be registered with the Jabber Registrar. The following rules apply:

      +

      The first decision-point is whether a FORM_TYPE needs to be registered with the XMPP Registrar. The following rules apply:

        -
      1. If the FORM_TYPE is used in the context of a form defined in a JEP, it MUST be registered.
        2. -
      2. 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.
        3. +
      3. If the FORM_TYPE is used in the context of a form defined in a XEP, it MUST be registered.
        4. +
      4. 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.
      5. If the FORM_TYPE is used in the context of a custom protocol, it MAY be registered.
       @@ -92,15 +92,15 @@
    -

    For FORM_TYPEs that are registered with the Jabber Registrar, the field names MUST conform to one of the following two conditions:

    +

    For FORM_TYPEs that are registered with the XMPP Registrar, the field names MUST conform to one of the following two conditions:

      -
    1. 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.
      2. +
    2. 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.
    3. If the field name is unregistered, the field name MUST begin with "x-".

    If the FORM_TYPE is not registered, the field name MAY have any name (presumably managed by the namespace "owner").

     -

    Field values may also be registered; refer to the Jabber Registrar section of this document.

    +

    Field values may also be registered; refer to the XMPP Registrar section of this document.

         @@ -132,7 +132,7 @@ ]]> -

    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.

    +

    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.

    @@ -329,13 +329,13 @@     -

    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.

    +

    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.

     - + -

    The Jabber Registrar shall maintain a registry of information about submitted FORM_TYPEs.

    +

    The XMPP Registrar shall maintain a registry of information about submitted FORM_TYPEs.

    ®PROCESS; ]]> -

    The registrant MAY register more than one FORM_TYPE at a time, each contained in a separate <form_type/> element. The registrant MAY also register more than one field at a time, each contained in a separate <field/> 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 <field/> 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.

    +

    The registrant MAY register more than one FORM_TYPE at a time, each contained in a separate <form_type/> element. The registrant MAY also register more than one field at a time, each contained in a separate <field/> 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 <field/> 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.

    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:

    FORM_TYPE namespace or namespace derivative - associated JEP or other document + associated XEP or other document natural-language description of form type     - + diff --git a/xep-0069.xml b/xep-0069.xml index 26a225a6..14f05a4f 100644 --- a/xep-0069.xml +++ b/xep-0069.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    Compliance JIG A proposal to form a JIG devoted to issues related to protocol compliance. @@ -48,4 +48,4 @@
  • Logo requirements
    • - +
    TermDescription