diff --git a/xep-0001.xml b/xep-0001.xml index 2061c3f3..4272b3e7 100644 --- a/xep-0001.xml +++ b/xep-0001.xml @@ -217,7 +217,7 @@ -

The &XSF; adheres to an open standards process that enables interested parties to document existing protocols used within the Jabber/XMPP developer community and to submit proposals that define new protocols; with a few exceptions, Effectively the only such exceptions are protocols that were superseded by RFC 3920 and RFC 3921. such protocols can be considered extensions to the Extensible Messaging and Presence Protocol (XMPP) approved by the &IETF; in &xmppcore; and &xmppim;. The focal point of the process is a series of protocol specifications called XMPP Extension Protocols or XEPs. The JEP (now XEP) concept as exemplified in version 1.0 of this document (approved in July of 2001) was borrowed from the Python community (see PEP-1). Subsequent revisions have been based on the Jabber/XMPP developer community's experience with this standards process, as well as insights gleaned from the standards processes followed by the IETF (&rfc2026;), the &W3C; (&w3process;), and other standards development organizations. (Note: The term "XEP" is normally pronounced "zepp".)

+

The &XSF; adheres to an open standards process that enables interested parties to document existing protocols used within the Jabber/XMPP developer community and to submit proposals that define new protocols; with a few exceptions, Effectively the only such exceptions are protocols that were superseded by &rfc3920; and RFC 3921. such protocols can be considered extensions to the Extensible Messaging and Presence Protocol (XMPP) approved by the &IETF; in &xmppcore; and &xmppim;. The focal point of the process is a series of protocol specifications called XMPP Extension Protocols or XEPs. The JEP (now XEP) concept as exemplified in version 1.0 of this document (approved in July of 2001) was borrowed from the Python community (see PEP-1). Subsequent revisions have been based on the Jabber/XMPP developer community's experience with this standards process, as well as insights gleaned from the standards processes followed by the IETF (&rfc2026;), the &W3C; (&w3process;), and other standards development organizations. (Note: The term "XEP" is normally pronounced "zepp".)

Advancement of a XEP through the XSF's standards process is contingent on three factors:

@@ -933,7 +933,7 @@ And by opposing end them? Collection - A node that contains nodes and/or other collections but no published items. Collections make it possible to represent more sophisticated relationships among nodes. For details, refer to XEP-0248. + A node that contains nodes and/or other collections but no published items. Collections make it possible to represent more sophisticated relationships among nodes. For details, refer to &xep0248;. @@ -951,11 +951,11 @@ And by opposing end them? Presence - Any entity with a subscription of type "from" or "both" may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems (see RFC 3921). + Any entity with a subscription of type "from" or "both" may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems (see &rfc3921;). Roster - Any entity in the specified roster group(s) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems (see RFC 3921). + Any entity in the specified roster group(s) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems (see &rfc3921;). Authorize @@ -973,7 +973,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 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 This rule does not apply to the root collection node, if any.). 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.

+

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 This rule does not apply to the root collection node, if any.). 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 &rfc3920;.

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

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

If a pubsub node is addressable as a JID plus node, the NodeID MUST be the value of both the Service Discovery 'node' attribute and the pubsub 'node' attribute; i.e., for discovery purposes, a pubsub node is equivalent to a Service Discovery node. If a pubsub node is addressable as a JID plus node, the pubsub service SHOULD ensure that the NodeID conforms to the Resourceprep profile of Stringprep as described in RFC 3920.

+

If a pubsub node is addressable as a JID plus node, the NodeID MUST be the value of both the Service Discovery 'node' attribute and the pubsub 'node' attribute; i.e., for discovery purposes, a pubsub node is equivalent to a Service Discovery node. If a pubsub node is addressable as a JID plus node, the pubsub service SHOULD ensure that the NodeID conforms to the Resourceprep profile of Stringprep as described in &rfc3920;.

Consider the following example, in which the (virtual) pubsub service is located at hamlet@denmark.lit.

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

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.

+

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 &xep0030; 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:

These error cases are described more fully in the following sections.

-

When requesting subscription options, the subscriber MUST specify the JID that is subscribed to the node and SHOULD specify a node (if no node is specified, i.e. via node="", the service MUST assume that the requesting entity wishes to request subscription options for its subscription to the root collection node; refer to XEP-0248 for details).

+

When requesting subscription options, the subscriber MUST specify the JID that is subscribed to the node and SHOULD specify a node (if no node is specified, i.e. via node="", the service MUST assume that the requesting entity wishes to request subscription options for its subscription to the root collection node; refer to &xep0248; for details).

The service MUST validate that the entity making the request is authorized to set the subscription options for the subscribed entity. If the subscriber's JID is of the form &FULLJID;, a service MUST perform this check by comparing the &BAREJID; part of the two JIDs to ensure that they match. If the bare JID portions of the JIDs do not match and the requesting entity is not authorized to modify subscription options for the JID (e.g., because it is not a service-wide admin or authorized proxy), the service MUST return a &forbidden; error.

]]> -

The process for retrieving the default subscription configuration options for collection nodes is described in XEP-0248.

+

The process for retrieving the default subscription configuration options for collection nodes is described in &xep0248;.

If no error occurs, the node MUST return the default subscription configuration options.

@@ -2492,7 +2492,7 @@ O, what a rogue and peasant slave am I! ]]> -

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 XEP-0059 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 the service or node does not support item retrieval (e.g., because the node is a collection node as described in XEP-0248), the service MUST return a &feature; error to the subscriber, specifying a pubsub-specific error condition of <unsupported/> and a feature of "retrieve-items".

+

If the service or node does not support item retrieval (e.g., because the node is a collection node as described in &xep0248;), the service MUST return a &feature; error to the subscriber, specifying a pubsub-specific error condition of <unsupported/> and a feature of "retrieve-items".

 -

If the node does not support item publication (e.g., because it is a collection node as described in XEP-0248), the service MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "publish".

+

If the node does not support item publication (e.g., because it is a collection node as described in &xep0248;), the service MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "publish".

]]> -

The <publish-options/> element MUST contain a data form (see XEP-0004), whose FORM_TYPE MUST be "http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068).

+

The <publish-options/> element MUST contain a data form (see &xep0004;), whose FORM_TYPE MUST be "http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068).

Each form field denotes a precondition to publishing the request. A pub-sub service advertising support for publishing options MUST check each precondition field against the node configuration of the same name, and it MUST reject the publication upon encountering unknown fields.

Preconditions MUST be processed as follows:

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

    (For error handling if the service does not support the specified node type, refer to XEP-0248.)

    +

    (For error handling if the service does not support the specified node type, refer to &xep0248;.)

    If an implementation allows node configuration (see the Configure a Node section of this document), it SHOULD allow node creation requests to contain the desired node configuration in the node creation request.

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

    If the "pubsub#notify_config" option is set to true, the service MUST notify subscribers of the configuration change. (A service SHOULD support this option for leaf nodes and MUST support it for collection nodes as described in XEP-0248.) If the node configuration is set to notification-only, the notification MUST consist of an empty <configuration/> element whose 'node' attribute is set to the NodeID of the node; if the node configuration is set to full payloads, the <configuration/> element MUST in addition contain the node configuration as represented via the Data Forms protocol.

    +

    If the "pubsub#notify_config" option is set to true, the service MUST notify subscribers of the configuration change. (A service SHOULD support this option for leaf nodes and MUST support it for collection nodes as described in &xep0248;.) If the node configuration is set to notification-only, the notification MUST consist of an empty <configuration/> element whose 'node' attribute is set to the NodeID of the node; if the node configuration is set to full payloads, the <configuration/> element MUST in addition contain the node configuration as represented via the Data Forms protocol.

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

    There are several reasons why the node deletion request might fail:

    1. The requesting entity does not have sufficient privileges to delete the node.
      2. -
    2. The node is the root collection node, which cannot be deleted (see XEP-0248).
      3. +
    3. The node is the root collection node, which cannot be deleted (see &xep0248;).
    4. The specified node does not exist.

    These error cases are described more fully in the following sections.

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

    If the service or node does not persist items (e.g., because the node is a collection node as described in XEP-0248), it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "persistent-items".

    +

    If the service or node does not persist items (e.g., because the node is a collection node as described in &xep0248;), it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "persistent-items".

    -

    Publish-subscribe functionality can be integrated into existing instant messaging and presence services (see RFC 3921), such that each registered account functions as a virtual pubsub service (sometimes called "pubsub-on-a-JID"). In such deployments, the root pubsub node for each virtual pubsub service has the same address as the bare JID &BAREJID; of the account, which is typically associated with an IM user (e.g., <hamlet@denmark.lit>). Since an IM user typically has a roster of "buddies" and shares presence information with those buddies, the virtual pubsub service can use roster and presence information to provide some helpful shortcuts for subscribers, in particular the auto-subscribe and filtered-notifications features described in this section.

    +

    Publish-subscribe functionality can be integrated into existing instant messaging and presence services (see &rfc3921;), such that each registered account functions as a virtual pubsub service (sometimes called "pubsub-on-a-JID"). In such deployments, the root pubsub node for each virtual pubsub service has the same address as the bare JID &BAREJID; of the account, which is typically associated with an IM user (e.g., <hamlet@denmark.lit>). Since an IM user typically has a roster of "buddies" and shares presence information with those buddies, the virtual pubsub service can use roster and presence information to provide some helpful shortcuts for subscribers, in particular the auto-subscribe and filtered-notifications features described in this section.

    Note: PEP ties the receipt of PEP notifications to the subscriber's presence, but does not tie the generation of PEP notifications to the publisher's presence. If the publisher wishes to stop generating PEP events (or to generate an "empty" event as can be done for some PEP payloads) before ending its presence session, the publisher MUST direct its client to do so and MUST NOT depend on the PEP service to automatically "zero out" its PEP information when the PEP service receives unavailable presence from the publisher.

    If an instant messaging and presence account is also a virtual pubsub service, service discovery information ("disco#info") responses from the bare JID of the account MUST include a feature of "http:/jabber.org/protocol/pubsub#pubsub-on-a-jid":

    ]]> -

    Note: Because the account owner's bare JID is the default destination address for any stanzas a client generates, clients often omit the "to" attribute on such stanzas; on this point, see RFC 6120 and (with regard to rosters) RFC 6121.

    +

    Note: Because the account owner's bare JID is the default destination address for any stanzas a client generates, clients often omit the "to" attribute on such stanzas; on this point, see &rfc6120; and (with regard to rosters) RFC 6121.

    When a contact is affiliated with the account owner through sharing of XMPP presence, the "auto-subscribe" feature greatly simplifies the subscription process. In particular, support for the "auto-subscribe" has the following implications:

    @@ -5019,13 +5019,13 @@ And by opposing end them?     -

    A contact might not want to receive notifications for all the nodes hosted at a user's virtual pubsub service. A contact SHOULD signal its preferences to the account owner's server by including XEP-0115 information that specifies the NodeIDs for which the contact wishes to receive notifications (if any). This information is used by a pubsub service that supports the "filtered-notifications" feature to send notifications only from those NodeIDs that match the subscriber's preferences.

    -

    In order to make this possible, all possible NodeIDs can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the specified NodeID. Thus if Romeo wants to receive notifications for location data (&xep0080;) and tune data (&xep0118;) but not activity data (&xep0108;), his client would advertise support for the following strings in the disco#info results it sends: Including, say, the 'http://jabber.org/protocol/geoloc' NodeID indicates that the client understands the geolocation namespace described in XEP-0080, whereas including the 'http://jabber.org/protocol/geoloc+notify' namespace indicates that the client wishes to receive notifications related to geolocation, where the NodeID is the same as the geolocation namespace 'http://jabber.org/protocol/geoloc' (in this case there is a one-to-one correspondence between the namespace name and the NodeID).

    +

    A contact might not want to receive notifications for all the nodes hosted at a user's virtual pubsub service. A contact SHOULD signal its preferences to the account owner's server by including &xep0115; information that specifies the NodeIDs for which the contact wishes to receive notifications (if any). This information is used by a pubsub service that supports the "filtered-notifications" feature to send notifications only from those NodeIDs that match the subscriber's preferences.

    +

    In order to make this possible, all possible NodeIDs can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the specified NodeID. Thus if Romeo wants to receive notifications for location data (&xep0080;) and tune data (&xep0118;) but not activity data (&xep0108;), his client would advertise support for the following strings in the disco#info results it sends: Including, say, the 'http://jabber.org/protocol/geoloc' NodeID indicates that the client understands the geolocation namespace described in &xep0080;, whereas including the 'http://jabber.org/protocol/geoloc+notify' namespace indicates that the client wishes to receive notifications related to geolocation, where the NodeID is the same as the geolocation namespace 'http://jabber.org/protocol/geoloc' (in this case there is a one-to-one correspondence between the namespace name and the NodeID).

    • http://jabber.org/protocol/geoloc+notify
    • http://jabber.org/protocol/tune+notify
    -

    This set of strings would then be advertised by including them in the identity+features hash encapsulated via the 'ver' attribute as described in XEP-0115.

    +

    This set of strings would then be advertised by including them in the identity+features hash encapsulated via the 'ver' attribute as described in &xep0115;.

    ]]> -

    It is the responsibility of the account owner's server to cache XEP-0115 information. When the server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the desired NodeIDs for the contact's client. The server MUST NOT send notifications related to any NodeIDs that the contact's client has not asked for via the relevant "NodeID+notify" disco#info feature. This enables a client to turn off all notifications (e.g., because of bandwidth restrictions) and to easily receive all desired data formats simply by adding support for the appropriate "NodeID+notify" combination in its disco#info results and client capabililies. However, it also implies that a client can request notifications only on a global basis and cannot request, say, mood information only from certain contacts in the user's roster. Community consensus is that this is an acceptable tradeoff. Also, note that this works only if the account owner has a presence subscription to the contact and the contact has a presence subscription to the account owner.

    +

    It is the responsibility of the account owner's server to cache &xep0115; information. When the server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the desired NodeIDs for the contact's client. The server MUST NOT send notifications related to any NodeIDs that the contact's client has not asked for via the relevant "NodeID+notify" disco#info feature. This enables a client to turn off all notifications (e.g., because of bandwidth restrictions) and to easily receive all desired data formats simply by adding support for the appropriate "NodeID+notify" combination in its disco#info results and client capabililies. However, it also implies that a client can request notifications only on a global basis and cannot request, say, mood information only from certain contacts in the user's roster. Community consensus is that this is an acceptable tradeoff. Also, note that this works only if the account owner has a presence subscription to the contact and the contact has a presence subscription to the account owner.

    Some examples may help to illustrate the concept of notification filtering. Here we show presence generated by two of the contacts listed above (benvolio@montague.lit does not have any presence subscriptions to or from juliet@capulet.lit and therefore is not involved in these protocol flows).

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

    (As noted in XEP-0115, the server MUST check the hash provided in the 'ver' attribute against the generation method to ensure that no poisoning has occurred.)

    +

    (As noted in &xep0115;, the server MUST check the hash provided in the 'ver' attribute against the generation method to ensure that no poisoning has occurred.)

    Now we revisit account owner publication and server generation of notifications, with filtering enabled because the server has caps information:

    • If Juliet publishes a tune item to the presence-access "http://jabber.org/protocol/tune" node, her server will send notifications to <nurse@capulet.lit/chamber> and <romeo@montague.lit/orchard> (full JIDs).

      • @@ -5264,7 +5264,7 @@ And by opposing end them? collections Collection nodes are supported. OPTIONAL - Refer to XEP-0248 + Refer to &xep0248; config-node @@ -5360,7 +5360,7 @@ And by opposing end them? multi-collection A single leaf node can be associated with multiple collections. OPTIONAL - Refer to XEP-0248 + Refer to &xep0248; multi-items @@ -5560,7 +5560,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 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 XEP-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 &rfc3920; and &xep0086; 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.
        • @@ -5610,7 +5610,7 @@ And by opposing end them? -

        Implementations of pubsub MAY deliver event notifications only when the subscriber is online. In these cases, the option may be a node configuration option as shown in the examples above. To facilitate this, the pubsub service needs to subscribe to the subscriber's presence and check the subscriber's current presence information before sending any event notifications (as described in RFC 3921). Presence subscriptions MUST be based on the subscribed JID.

        +

        Implementations of pubsub MAY deliver event notifications only when the subscriber is online. In these cases, the option may be a node configuration option as shown in the examples above. To facilitate this, the pubsub service needs to subscribe to the subscriber's presence and check the subscriber's current presence information before sending any event notifications (as described in &rfc3921;). Presence subscriptions MUST be based on the subscribed JID.

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

        If a service understands the semantics for a particular payload type and an entity's subscription is so configured (by the "pubsub#include_body" subscription option to true), the service SHOULD include an appropriate XMPP &BODY; child element along with the payloads it sends in event notifications for a given node, where the body's XML character data summarizes or represents the information contained in the payload (this enables clients that do not understand the payload format to present the appropriate information to an end user). For example, the Atom <summary/> element (see RFC 4287) could be mapped to the XMPP &BODY; element. A service MUST NOT provide the "pubsub#include_body" subscription option for a node if it does not have a defined way to transform part or all of the payload format into a sensible message body. A node owner MAY define an XSLT for transforming the payload format into a message body, via the "pubsub#body_xslt" node configuration option. This XSLT is applied by the pubsub service after receiving a publish request and before sending the appropriate notifications, not by the client before sending a publish request.

        +

        If a service understands the semantics for a particular payload type and an entity's subscription is so configured (by the "pubsub#include_body" subscription option to true), the service SHOULD include an appropriate XMPP &BODY; child element along with the payloads it sends in event notifications for a given node, where the body's XML character data summarizes or represents the information contained in the payload (this enables clients that do not understand the payload format to present the appropriate information to an end user). For example, the Atom <summary/> element (see &rfc4287;) could be mapped to the XMPP &BODY; element. A service MUST NOT provide the "pubsub#include_body" subscription option for a node if it does not have a defined way to transform part or all of the payload format into a sensible message body. A node owner MAY define an XSLT for transforming the payload format into a message body, via the "pubsub#body_xslt" node configuration option. This XSLT is applied by the pubsub service after receiving a publish request and before sending the appropriate notifications, not by the client before sending a publish request.

        If the service does not understand the semantics for a particular payload type and therefore cannot transform the payload into a human-readable message body, it SHOULD NOT include a <body/> child.

        If a subscriber has multiple subscriptions to the same node, where some of the SubIDs have include_body set to true and others have include_body set to false, the service SHOULD include a body with all notifications.

         @@ -5654,7 +5654,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 XEP-0160) and first approval wins.
          • +
        • Send requests to all owners (these may be placed in offline storage as described in &xep0160;) 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.
          • @@ -5700,7 +5700,7 @@ And by opposing end them? -

          NodeIDs MAY have semantic meaning in particular profiles, implementations, or deployments of pubsub. However, it is STRONGLY RECOMMENDED that such semantic meaning not be used to encapsulate the hierarchical structure of nodes; instead, node hierarchy SHOULD be encapsulated using collections and their associated child nodes as described in XEP-0248.

          +

          NodeIDs MAY have semantic meaning in particular profiles, implementations, or deployments of pubsub. However, it is STRONGLY RECOMMENDED that such semantic meaning not be used to encapsulate the hierarchical structure of nodes; instead, node hierarchy SHOULD be encapsulated using collections and their associated child nodes as described in &xep0248;.

           @@ -5709,7 +5709,7 @@ And by opposing end them?
        • Sending notifications regarding newly-published items as described in the Publish an Item to a Node use case.
        • Sending notifications regarding deleted items as described in the Delete an Item from a Node use case.
        -

        The SHIM headers are generated by the node to which the subscriber has a subscription, which may be either a leaf node or a collection node (refer to XEP-0248).

        +

        The SHIM headers are generated by the node to which the subscriber has a subscription, which may be either a leaf node or a collection node (refer to &xep0248;).

        SHIM headers are not to be included when the content does not differ based on subscription ID, e.g., when a node sends notification of a configuration change to the node itself, notification that the node has been purged, or notification that the node has been deleted.

         @@ -5746,7 +5746,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 XEP-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 &xep0163;.

        @@ -6414,7 +6414,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
      • Setting of metadata 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 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.

+

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

Next the Target attempts to open a standard TCP socket on the network address of the StreamHost/Requester (for information about UDP usage, see the Optional UDP Support section of this document).

Note: If the Requester provides more than one StreamHost, the Target SHOULD try to connect to them in the order of the <streamhost/> children within the &QUERY; element. &xep0260; modifies this rule by providing explicit priorities for each streamhost candidate.

-

If the Target is able to open a TCP socket on a StreamHost/Requester, it MUST use the SOCKS5 protocol to establish a SOCKS5 connection. In accordance with RFC 1928, the Target might need to authenticate in order to use the proxy. However, any authentication required is beyond the scope of this document.

+

If the Target is able to open a TCP socket on a StreamHost/Requester, it MUST use the SOCKS5 protocol to establish a SOCKS5 connection. In accordance with &rfc1928;, the Target might need 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 StreamHost/Requester, it sends a CONNECT request (CMD = X'01') in order to continue the negotiation. The following rules apply:

  1. The hostname MUST be SHA1(SID + Requester JID + Target JID) where the definition of the SHA1 hashing algorithm is as specified by &rfc3174; and the output is hexadecimal-encoded (not binary); as noted above and under Use with Multi-User Chat, the DST.ADDR value might have been provided directly from the Requester to the Target).
    2. @@ -425,7 +425,7 @@ DST.PORT = 0 -

    When replying to the Target in accordance with Section 6 of RFC 1928, the StreamHost MUST set the BND.ADDR and BND.PORT to the DST.ADDR and DST.PORT values provided by the client in the connection request.

    +

    When replying to the Target in accordance with Section 6 of &rfc1928;, the StreamHost MUST set the BND.ADDR and BND.PORT to the DST.ADDR and DST.PORT values provided by the client in the connection request.

    If the Target tries but is unable to connect to any of the StreamHosts and it does not wish to attempt a connection from its side, it MUST return an ¬found; error to the Requester.

    Next the Target attempts to open a standard TCP socket on the network address of the Proxy.

    -

    If the Target is able to open a TCP socket on the Proxy, it uses the SOCKS5 protocol to establish a SOCKS5 connection. In accordance with RFC 1928, the Target might need to authenticate in order to use the proxy. However, any authentication required is beyond the scope of this document.

    +

    If the Target is able to open a TCP socket on the Proxy, it uses the SOCKS5 protocol to establish a SOCKS5 connection. In accordance with &rfc1928;, the Target might need 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, it sends a CONNECT request (CMD = X'01') in order to continue the negotiation. The following rules apply:

    1. The hostname MUST be SHA1(SID + Requester JID + Target JID) where the definition of the SHA1 hashing algorithm is as specified by &rfc3174; and the output is hexadecimal-encoded (not binary); as noted above and under Use with Multi-User Chat, the DST.ADDR value might have been provided directly from the Requester to the Target).
    2. The port MUST be 0 (zero).
    3. The JIDs provided MUST be the JIDs used for the IQ exchange between the Requester and the Target, which MAY be full JIDs &FULLJID; or bare JIDs &BAREJID;.
      4. -
    4. The appropriate stringprep profiles (as specified in RFC 6122) MUST be applied to the JIDs before application of the SHA1 hashing algorithm.
      5. +
    5. The appropriate stringprep profiles (as specified in &rfc6122;) MUST be applied to the JIDs before application of the SHA1 hashing algorithm.
    -

    When replying to the Target in accordance with Section 6 of RFC 1928, the Proxy MUST set the BND.ADDR and BND.PORT to the DST.ADDR and DST.PORT values provided by the client in the connection request.

    +

    When replying to the Target in accordance with Section 6 of &rfc1928;, the Proxy MUST set the BND.ADDR and BND.PORT to the DST.ADDR and DST.PORT values provided by the client in the connection request.

    After the Target has established a SOCKS5 connection with the Proxy, it replies to the initiate request with an IQ-result whose &QUERY; element contains a <streamhost-used/> child that specifies which StreamHost was used (in this case, the Proxy).

    @@ -773,7 +773,7 @@ DATA = (payload)

    The <streamhost/> element contains the bytestream connection information. This element has attributes for the StreamHost's JID, network host/address, and network port. This element MUST NOT contain any XML character data or child elements.

    The "jid" attribute specifies the StreamHost's JID. This attribute MUST be present, and MUST be a valid JID for communication over XMPP.

    The "host" attribute specifies the host to connect to. This attribute MUST be present. The value MUST be either an IPv4 or IPv6 address, or a resolvable DNS domain name.

    -

    The "port" attribute specifies the port to connect to. This attribute MAY be present. The value MUST be a valid port number in decimal form. If not specified, the port value is "1080" (in accordance with RFC 1928).

    +

    The "port" attribute specifies the port to connect to. This attribute MAY be present. The value MUST be a valid port number in decimal form. If not specified, the port value is "1080" (in accordance with &rfc1928;).

    When communicating the available hosts, the Requester MUST include the host and port.

    diff --git a/xep-0066.xml b/xep-0066.xml index 849190f9..81f74101 100644 --- a/xep-0066.xml +++ b/xep-0066.xml @@ -89,7 +89,7 @@

    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.

    +

    To initiate an out-of-band file transfer with an intended recipient using the 'jabber:iq:oob' namespace (whether or not negotiated via &xep0096;), 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 document inherits terminology about the HyperText Transfer Protocol from RFC 2616 and RFC 2617.

    +

    This document inherits terminology about the HyperText Transfer Protocol from &rfc2616; and RFC 2617.

     @@ -164,7 +164,7 @@

    This process flow is described in more detail in the following sections.

    -

    Let us stipulate that an XMPP user (say, <juliet@capulet.com>) learns of an HTTP URL (e.g., <https://files.shakespeare.lit:9345/missive.html>). The user then attempts to retrieve the URL using her HTTP Client, which opens a TCP connection to the appropriate port of the host and sends an HTTP request as defined in RFC 2616. The request method MAY be any valid HTTP request method, including user-defined methods.

    +

    Let us stipulate that an XMPP user (say, <juliet@capulet.com>) learns of an HTTP URL (e.g., <https://files.shakespeare.lit:9345/missive.html>). The user then attempts to retrieve the URL using her HTTP Client, which opens a TCP connection to the appropriate port of the host and sends an HTTP request as defined in &rfc2616;. The request method MAY be any valid HTTP request method, including user-defined methods.

    An example is provided below:

    In order to avoid a round trip, the initial request MAY contain HTTP authorization credentials as described below.

     -

    If the user did not provide authorization credentials in the initial request, the HTTP Server then MUST respond with a (401) Authenticate response as defined in RFC 2616. The response MUST contain an HTTP 401 error and one WWW-Authenticate header for each authentication scheme recognized by the HTTP Server. In order to provide verification via XMPP, at least one of these headers MUST specify a realm of "xmpp" (case-sensitive).

    +

    If the user did not provide authorization credentials in the initial request, the HTTP Server then MUST respond with a (401) Authenticate response as defined in &rfc2616;. The response MUST contain an HTTP 401 error and one WWW-Authenticate header for each authentication scheme recognized by the HTTP Server. In order to provide verification via XMPP, at least one of these headers MUST specify a realm of "xmpp" (case-sensitive).

     -

    The HTTP Client responds with an Authorization Request as defined in RFC 2616. The following rules apply:

    +

    The HTTP Client responds with an Authorization Request as defined in &rfc2616;. The following rules apply:

    1. The request MUST include the Jabber Identifier (JID) of the user making the request. This SHOULD be the full JID (<user@host/resource>) of a client that supports the protocol defined herein, although it MAY be the user's bare JID (<user@host>) instead.
    2. The request MUST include a transaction identifier for the request. This identifier MUST be unique within the context of the HTTP Client's interaction with the HTTP Server. If the HTTP request is generated by the XMPP Client (e.g., because the HTTP URL was discovered via &xep0066;) then the transaction identifier SHOULD be generated by the client; if not, the transaction identifier SHOULD be provided by the human user who controls the HTTP Client.

    The Authorization Request process is described in the following subsections.

    -

    The Basic Access Authentication scheme is defined in RFC 2617. This scheme specifies that the authorization information shall consist of a userid and password, separated by a ':' character and then encoded using Base64. When the realm is "xmpp", the profile defined herein further specifies that the userid MUST be a valid JID as described above, that the password entity MUST be a transaction identifier as described above, that any character in the JID or transaction identifier that is outside the range of the US-ASCII coded character set MUST be transformed into a percent-encoded octet as specified in Section 2.1 of &rfc3986; prior to Base64 encoding, and that Base64 encoding MUST adhere to Section 4 of &rfc4648;.

    -

    (Refer to RFC 2617 for specification of the syntax of the Basic Access Authentication scheme; that information is not duplicated here.)

    +

    The Basic Access Authentication scheme is defined in &rfc2617;. This scheme specifies that the authorization information shall consist of a userid and password, separated by a ':' character and then encoded using Base64. When the realm is "xmpp", the profile defined herein further specifies that the userid MUST be a valid JID as described above, that the password entity MUST be a transaction identifier as described above, that any character in the JID or transaction identifier that is outside the range of the US-ASCII coded character set MUST be transformed into a percent-encoded octet as specified in Section 2.1 of &rfc3986; prior to Base64 encoding, and that Base64 encoding MUST adhere to Section 4 of &rfc4648;.

    +

    (Refer to &rfc2617; for specification of the syntax of the Basic Access Authentication scheme; that information is not duplicated here.)

     -

    The Digest Access Authentication scheme is defined in RFC 2617. This scheme specifies that the authorization information shall consist of the MD5 checksum of the username, a cnonce generated by the client, a nonce value provided in the challenge, the HTTP method, and the requested URL. When the realm is "xmpp", the profile defined herein further specifies that prior to creating the MD5 checksum the username MUST be a valid JID as described above, that the cnonce MUST be a transaction identifier as described above, and that any character in the JID or transaction identifier that is outside the range of the US-ASCII coded character set MUST be transformed into a percent-encoded octet as specified in Section 2.1 of RFC 3986.

    -

    (Refer to RFC 2617 for specification of the syntax of the Digest Access Authentication scheme; that information is not duplicated here.)

    +

    The Digest Access Authentication scheme is defined in &rfc2617;. This scheme specifies that the authorization information shall consist of the MD5 checksum of the username, a cnonce generated by the client, a nonce value provided in the challenge, the HTTP method, and the requested URL. When the realm is "xmpp", the profile defined herein further specifies that prior to creating the MD5 checksum the username MUST be a valid JID as described above, that the cnonce MUST be a transaction identifier as described above, and that any character in the JID or transaction identifier that is outside the range of the US-ASCII coded character set MUST be transformed into a percent-encoded octet as specified in Section 2.1 of RFC 3986.

    +

    (Refer to &rfc2617; for specification of the syntax of the Digest Access Authentication scheme; that information is not duplicated here.)

    To reduce the likelihood of man-in-the-middle attacks, channel encryption SHOULD be used for both the XMPP channel and the HTTP channel. In particular:

    1. The channel used for HTTP requests and responses SHOULD be encrypted via SSL (secure HTTP via https: URLs) or TLS (&rfc2817;).
      2. -
    2. If the standard binding of XMPP to TCP is used, TLS SHOULD be negotiated for the XMPP channel in accordance with RFC 6120.
      3. -
    3. If a binding of XMPP to HTTP is used (e.g., as specified in XEP-0124), exchanges between the XMPP Client and XMPP Server (connection manager) SHOULD be sent over a channel that is encrypted using SSL or TLS.
      4. +
    4. If the standard binding of XMPP to TCP is used, TLS SHOULD be negotiated for the XMPP channel in accordance with &rfc6120;.
      5. +
    5. If a binding of XMPP to HTTP is used (e.g., as specified in &xep0124;), exchanges between the XMPP Client and XMPP Server (connection manager) SHOULD be sent over a channel that is encrypted using SSL or TLS.
     diff --git a/xep-0072.xml b/xep-0072.xml index 75616a44..8e48bcde 100644 --- a/xep-0072.xml +++ b/xep-0072.xml @@ -134,9 +134,9 @@ -

    The usual architecture of XMPP is described in RFC 6120. In essence, XMPP is most commonly deployed using a client-server (or logical peer-to-peer) architecture quite similar to that of the email system, except that XMPP does not have multiple hops between servers, enforces domain names to prevent address spoofing, and enables channel encryption (via TLS) and authentication (via SASL) between client and server as well as among servers.

    +

    The usual architecture of XMPP is described in &rfc6120;. In essence, XMPP is most commonly deployed using a client-server (or logical peer-to-peer) architecture quite similar to that of the email system, except that XMPP does not have multiple hops between servers, enforces domain names to prevent address spoofing, and enables channel encryption (via TLS) and authentication (via SASL) between client and server as well as among servers.

    The binding of SOAP to XMPP assumes that most SOAP-enabled XMPP entities will be implemented as XMPP clients that communicate with other entities as logical peers. However, in order to deploy more scalable services, such entities could also be implemented as server-side components (see &xep0114;) or even as special-purpose XMPP servers.

    -

    The SOAP specification defines the concepts of "SOAP intermediary" and "ultimate SOAP receiver" (see Section 1.5.3 of SOAP Version 1.2 Part 1). In general, this specification assumes that XMPP entities that support the SOAP XMPP Binding will be ultimate SOAP receivers, since SOAP intermediaries tend to be artifacts of the existing SOAP bindings (HTTP and SMTP) rather than applicable to all possible bindings. SOAP intermediaries are usually deployed in order to (1) cross trust boundaries in protocols that do not enforce domain names or authenticate end-points, (2) ensure scalability, (3) secure messages sent over unencrypted channels, and (4) provide message tracing. However, these issues are addressed natively in XMPP (e.g., channel encryption is defined in RFC 6120), in XMPP extensions (e.g., message tracing is defined in &xep0079;), or in deployment decisions such as business level agreements between XMPP domains. One final justification for SOAP intermediaries is to act as gateways between different transport mechanisms (e.g., between HTTP and SMTP), and XMPP entities may well be SOAP intermediaries for that reason. For further details about gateways between XMPP and other SOAP bindings, refer to the Implementation Notes section of this document.

    +

    The SOAP specification defines the concepts of "SOAP intermediary" and "ultimate SOAP receiver" (see Section 1.5.3 of SOAP Version 1.2 Part 1). In general, this specification assumes that XMPP entities that support the SOAP XMPP Binding will be ultimate SOAP receivers, since SOAP intermediaries tend to be artifacts of the existing SOAP bindings (HTTP and SMTP) rather than applicable to all possible bindings. SOAP intermediaries are usually deployed in order to (1) cross trust boundaries in protocols that do not enforce domain names or authenticate end-points, (2) ensure scalability, (3) secure messages sent over unencrypted channels, and (4) provide message tracing. However, these issues are addressed natively in XMPP (e.g., channel encryption is defined in &rfc6120;), in XMPP extensions (e.g., message tracing is defined in &xep0079;), or in deployment decisions such as business level agreements between XMPP domains. One final justification for SOAP intermediaries is to act as gateways between different transport mechanisms (e.g., between HTTP and SMTP), and XMPP entities may well be SOAP intermediaries for that reason. For further details about gateways between XMPP and other SOAP bindings, refer to the Implementation Notes section of this document.

     @@ -368,8 +368,8 @@

    The recommended approaches (file transfer and including a link) are described more fully below.

    -

    The recommended method for sending associated data is to use the file transfer protocol described in XEP-0096. Because this is the common and standardized method for XMPP entities to transfer large or binary files outside the XMPP band, it SHOULD be used.

    -

    In particular, the entity that has the file SHOULD advertise the availability of the associated stream using XEP-0137 by including the SI-pub data extension along with the XMPP &MESSAGE; stanza with which the data is associated: In accordance with RFC 6120, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.

    +

    The recommended method for sending associated data is to use the file transfer protocol described in &xep0096;. Because this is the common and standardized method for XMPP entities to transfer large or binary files outside the XMPP band, it SHOULD be used.

    +

    In particular, the entity that has the file SHOULD advertise the availability of the associated stream using &xep0137; by including the SI-pub data extension along with the XMPP &MESSAGE; stanza with which the data is associated: In accordance with &rfc6120;, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.

    ]]> -

    For details regarding file transfer and advertising of file transfer stream initiation requests, refer to XEP-0096 and XEP-0137.

    +

    For details regarding file transfer and advertising of file transfer stream initiation requests, refer to &xep0096; and XEP-0137.

     -

    If the file transfer method is not possible (e.g., because file transfer is not implemented or transfer attempts fails), the entity that is sending the associated data MAY as a fallback publish the associated data as a file (e.g., at an HTTP or FTP URL) and include a link to the file as out-of-band content by including the out-of-band data extension along with the XMPP &MESSAGE; stanza with which the data is associated: As above, in accordance with RFC 6120, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.

    +

    If the file transfer method is not possible (e.g., because file transfer is not implemented or transfer attempts fails), the entity that is sending the associated data MAY as a fallback publish the associated data as a file (e.g., at an HTTP or FTP URL) and include a link to the file as out-of-band content by including the out-of-band data extension along with the XMPP &MESSAGE; stanza with which the data is associated: As above, in accordance with &rfc6120;, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.

    -

    Section 4 of &w3soap1; defines a SOAP Protocol Binding Framework; two instantiations of that framework are the SOAP HTTP Binding (specified in Section 7 of &w3soap2;) and the &w3soapemail;. (Additionally, a binding to BEEP is described in RFC 4227.) As an alternative to the HTTP and Email bindings, this section formally defines the SOAP XMPP Binding in accordance with the SOAP Protocol Binding Framework.

    +

    Section 4 of &w3soap1; defines a SOAP Protocol Binding Framework; two instantiations of that framework are the SOAP HTTP Binding (specified in Section 7 of &w3soap2;) and the &w3soapemail;. (Additionally, a binding to BEEP is described in &rfc4227;.) As an alternative to the HTTP and Email bindings, this section formally defines the SOAP XMPP Binding in accordance with the SOAP Protocol Binding Framework.

    Note: The SOAP XMPP Binding is optional, and SOAP nodes are not required to implement it. A SOAP node that correctly and completely implements the SOAP XMPP Binding as described herein may be said to "conform to the SOAP 1.2 XMPP Binding".

    The SOAP XMPP Binding is identified by the following URI:

    @@ -637,7 +637,7 @@     -

    XMPP is a pure XML streaming protocol used to exchange snippets of structured data called "XML stanzas" (see RFC 6120) between any two network endpoints.

    +

    XMPP is a pure XML streaming protocol used to exchange snippets of structured data called "XML stanzas" (see &rfc6120;) between any two network endpoints.

    Because XMPP is a direct messaging protocol, it does not possess the equivalent of web methods such as the HTTP GET, PUT, POST, and DELETE methods. Therefore, it is NOT RECOMMENDED for a SOAP node that supports only the SOAP XMPP Binding to provide the "SOAP Web Method Feature" described in Section 6.4 of SOAP Version 1.2 Part 2. (A SOAP gateway between XMPP and HTTP should support the SOAP Web Method Feature in order to ensure interoperability; however, description of such gateways is outside the scope of this document.)

    Because XMPP is a pure XML protocol, it does not use MIME types (&rfc2045;) or XML media types (&rfc3023;), but rather sends XML directly over the wire. Therefore, it is NOT RECOMMENDED for a SOAP node that supports only the SOAP XMPP Binding to provide the "SOAP Action Feature" described in Section 6.5 of SOAP Version 1.2 Part 2. (A SOAP gateway between XMPP and HTTP should support the SOAP Action Feature in order to ensure interoperability; however, description of such gateways is outside the scope of this document.)

     @@ -653,7 +653,7 @@
  2. A SOAP node instantiated at an XMPP entity may assume the role (i.e., the http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role property) of "RequestingSOAPNode".
  3. A SOAP node instantiated at an XMPP entity may assume the role (i.e., the http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role property) of "RespondingSOAPNode".
    4. -

    The remainder of this section describes the message exchange pattern (MEP) state machine and its relation to XMPP as described in RFC 6120. For the sake of brevity, relative URIs are used (the base URI being http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role), the string "fail:" is used as a conventional prefix for the namespace http://www.example.org/2001/12/soap/mep/FailureReasons/, and the string "reqresp:" is used as a conventional prefix for the namespace http://www.example.org/2001/12/soap/mep/request-response/. In the state tables below, the states are defined as values of the http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State property (see Section 6.2 of SOAP Version 1.2 Part 2) and are of type xs:anyURI.

    +

    The remainder of this section describes the message exchange pattern (MEP) state machine and its relation to XMPP as described in &rfc6120;. For the sake of brevity, relative URIs are used (the base URI being http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role), the string "fail:" is used as a conventional prefix for the namespace http://www.example.org/2001/12/soap/mep/FailureReasons/, and the string "reqresp:" is used as a conventional prefix for the namespace http://www.example.org/2001/12/soap/mep/request-response/. In the state tables below, the states are defined as values of the http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State property (see Section 6.2 of SOAP Version 1.2 Part 2) and are of type xs:anyURI.

    The overall flow of the behavior of a Requesting SOAP Node follows the outline state machine description contained in Section 6.2 of SOAP Version 1.2 Part 2. The following subsections describe each state in more detail, where "Requesting SOAP Node" is to be understood as a logical entity made up of the binding and the local SOAP node associated with the XMPP entity that generates a SOAP request.

    @@ -784,7 +784,7 @@ fail:ReceptionFailure -

    For a listing of relevant XMPP error conditions, refer to RFC 6120.

    +

    For a listing of relevant XMPP error conditions, refer to &rfc6120;.

    The following table formally describes the "Sending+Receiving" state of the Requesting SOAP Node in the SOAP XMPP Binding:

    @@ -841,7 +841,7 @@ fail:BadRequestMessage -

    For a listing of relevant XMPP error conditions, refer to RFC 6120.

    +

    For a listing of relevant XMPP error conditions, refer to &rfc6120;.

    A given instance of a request-response transport message exchange terminates when the state "Success" or "Fail" is reached; control over the transport message exchange context returns to the Requesting SOAP Node.

    @@ -904,7 +904,7 @@ fail:BadRequestMessage -

    For a listing of relevant XMPP error conditions, refer to RFC 6120.

    +

    For a listing of relevant XMPP error conditions, refer to &rfc6120;.

    The following table formally describes the "Receiving" state of the Responding SOAP Node in the SOAP XMPP Binding:

    @@ -1046,12 +1046,12 @@

    This specification addresses SOAP 1.2 only. This specification may be superseded or supplemented in the future by a XMPP Extension Protocol specification that defines methods for encapsulating content defined by future versions of SOAP as published by the W3C.

     -

    Per RFC 6120, XMPP supports XML 1.0 only. If future versions of XMPP support XML 1.1 or subsequent versions, this specification may be modified to address handling of SOAP messages that are encoded in versions other than XML 1.0.

    +

    Per &rfc6120;, XMPP supports XML 1.0 only. If future versions of XMPP support XML 1.1 or subsequent versions, this specification may be modified to address handling of SOAP messages that are encoded in versions other than XML 1.0.

         -

    SOAP provides its own encoding scheme for errors due to message processing or application execution, and it uses SOAP envelopes for reporting. In the SOAP HTTP Binding, these errors are mapped to corresponding HTTP status codes. In the SOAP XMPP Binding, they are mapped to the catch-all XMPP error of &undefined; along with application-specific error condition elements qualified by the 'http://jabber.org/protocol/soap#fault' namespace (this is consistent with RFC 6120, see also &xep0086;). The element names of these application-specific error conditions map directly to the SOAP fault codes specified in Section 5.4.6 of SOAP Version 1.2 Part 1.

    +

    SOAP provides its own encoding scheme for errors due to message processing or application execution, and it uses SOAP envelopes for reporting. In the SOAP HTTP Binding, these errors are mapped to corresponding HTTP status codes. In the SOAP XMPP Binding, they are mapped to the catch-all XMPP error of &undefined; along with application-specific error condition elements qualified by the 'http://jabber.org/protocol/soap#fault' namespace (this is consistent with &rfc6120;, see also &xep0086;). The element names of these application-specific error conditions map directly to the SOAP fault codes specified in Section 5.4.6 of SOAP Version 1.2 Part 1.

    The following table provides a mapping between SOAP, HTTP, and application-specific XMPP errors.

    @@ -1090,7 +1090,7 @@ -

    Because XMPP does not require the parsing of arbitrary and complete XML documents and does not require implementations to support the full XML specification, transported SOAP envelopes MUST comply with the XML restrictions specified in RFC 6120. In particular, all envelope elements MUST be properly namespaced (SOAP allows elements within the default namespace, but they are deprecated since SOAP 1.2).

    +

    Because XMPP does not require the parsing of arbitrary and complete XML documents and does not require implementations to support the full XML specification, transported SOAP envelopes MUST comply with the XML restrictions specified in &rfc6120;. In particular, all envelope elements MUST be properly namespaced (SOAP allows elements within the default namespace, but they are deprecated since SOAP 1.2).

    SOAP envelopes may contain arbitrary data encoded in valid XML as well as byte arrays encoded with SOAP-specific elements. The SOAP specification recommends to encode byte arrays in Base 64 (see &rfc3548;), with the result that envelopes with binary data can be transported within regular XMPP stanzas. All the remaining PCDATA MUST be encoded as UTF-8 in order to match the XML stream encoding.

         @@ -1195,7 +1195,7 @@ ]]> -

    Generic XMPP routers that conform to RFC 6120 may also "store and forward" Jabber messages. This feature is usually called "offline message handling": the router makes a decision as to whether to deliver the message to the local intended recipient based on the recipient's presence, and if the recipient is offline when the router processes the message then it may store the message for delivery when the recipient next comes online (rather than returning an error to the sender). Although it is possible to write an XMPP router that directly supports the SOAP XMPP binding and implements the SOAP processing model, generic XMPP routers do not contain such support. Accordingly, generic XMPP routers will not forward an XMPP message to an alternate SOAP transport such as HTTP or SMTP, or provide other functions of a SOAP intermediary or ultimate receiver. When a generic XMPP router delivers a message to the intended recipient (whether immediately or as delayed in "offline storage") and the intended recipient supports the SOAP XMPP binding, SOAP processing is performed; such an intended recipient MAY act either as a SOAP intermediary or as an ultimate SOAP receiver.

    +

    Generic XMPP routers that conform to &rfc6120; may also "store and forward" Jabber messages. This feature is usually called "offline message handling": the router makes a decision as to whether to deliver the message to the local intended recipient based on the recipient's presence, and if the recipient is offline when the router processes the message then it may store the message for delivery when the recipient next comes online (rather than returning an error to the sender). Although it is possible to write an XMPP router that directly supports the SOAP XMPP binding and implements the SOAP processing model, generic XMPP routers do not contain such support. Accordingly, generic XMPP routers will not forward an XMPP message to an alternate SOAP transport such as HTTP or SMTP, or provide other functions of a SOAP intermediary or ultimate receiver. When a generic XMPP router delivers a message to the intended recipient (whether immediately or as delayed in "offline storage") and the intended recipient supports the SOAP XMPP binding, SOAP processing is performed; such an intended recipient MAY act either as a SOAP intermediary or as an ultimate SOAP receiver.

    With regarding to exchange of associated data, an XMPP entity that functions as a gateway to other SOAP bindings it SHOULD use W3C-recommended protocols for transporting SOAP attachments over non-XMPP SOAP bindings (e.g., HTTP and SMTP) when communicating with non-XMPP entities.

    diff --git a/xep-0073.xml b/xep-0073.xml index 12f66474..f8df52f0 100644 --- a/xep-0073.xml +++ b/xep-0073.xml @@ -132,7 +132,7 @@

    The software developed in the Jabber community is built on the foundation of XML streams, a consistent addressing scheme (JIDs), channel encryption, authentication of an entity (client or server) with a server, three core data elements (&MESSAGE;, &PRESENCE;, and &IQ;), and proper handling of XML namespaces. These foundational building blocks have been formalized within RFC 3920, support for which is REQUIRED by this protocol suite.

    However, XMPP Core is not fully congruent with the core of what has traditionally been known as "Jabber", and this divergence needs to be captured in the Basic IM Protocol Suite. For the sake of backward compatibility, support for &xep0078; is RECOMMENDED for servers (but not clients) as a fallback method of authentication by older deployed clients. Older software also used port 5223 for SSL-enabled communications between a client and a server, rather than upgrading port 5222 as is done during TLS negotiation (the equivalent for server-to-server communications was never implemented). Support for this behavior is OPTIONAL on the part of servers for backwards-compatibility with older deployed clients. In addition, support for the error 'code' attribute specified in &xep0086; is RECOMMENDED for both clients and servers.

    -

    RFC 3920 does not define everything that is normally expected of even a minimal instant messaging and presence application (in effect, it defines the transport layer rather than the IM and presence application layer). Much of this IM and presence functionality is defined in RFC 3921 in order to meet the requirements of RFC 2779. In particular, RFC 3921 defines roster management, presence subscriptions, and routing and delivery guidelines for clients and servers. Therefore, support for RFC 3921 is REQUIRED.

    +

    RFC 3920 does not define everything that is normally expected of even a minimal instant messaging and presence application (in effect, it defines the transport layer rather than the IM and presence application layer). Much of this IM and presence functionality is defined in RFC 3921 in order to meet the requirements of RFC 2779. In particular, RFC 3921 defines roster management, presence subscriptions, and routing and delivery guidelines for clients and servers. Therefore, support for &rfc3921; is REQUIRED.

    Furthermore, Jabber instant messaging and presence applications typically include the ability to discover information about other entities on the network, and to reply to queries for information. This behavior is extremely helpful because it ensures that entities on the network can determine each other's capabilities and thus understand how to communicate together. Therefore, support for &xep0030; is REQUIRED by this protocol suite, as is (for clients) the dynamic profile of service discovery specified in &xep0115;.

    Traditionally, Jabber servers (and some services) have also offered the ability for clients to register accounts "in-band" (see &xep0077;) in order to bootstrap participation on the network; support for that protocol is RECOMMENDED but any given server deployment MAY disable in-band registration as a matter of service provisioning.

    Thus we define the Basic IM Protocol Suite as follows:

    @@ -172,7 +172,7 @@
    -

    RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. The older authentication method specified in XEP-0078: Non-SASL Authentication is now deprecated; however, support for it is still recommended in server implementations for the sake of backward compatibility (see XEP-0078 regarding the proper order of precedence between SASL authentication and non-SASL authentication).

    +

    RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. The older authentication method specified in XEP-0078: Non-SASL Authentication is now deprecated; however, support for it is still recommended in server implementations for the sake of backward compatibility (see &xep0078; regarding the proper order of precedence between SASL authentication and non-SASL authentication).

    This document requires no interaction with &IANA;.

    diff --git a/xep-0077.xml b/xep-0077.xml index 94bb26bd..0cc18b73 100644 --- a/xep-0077.xml +++ b/xep-0077.xml @@ -600,7 +600,7 @@

    The <key/> element was also used during registration removal.

     -

    RFC 6120 defines methods for advertising feature support during stream negotiation. For the sake of efficiency, it may be desirable for a server to advertise support for in-band registration as a stream feature. The namespace for reporting support within <stream:features/> is "http://jabber.org/features/iq-register". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server returns a stream header to the client and MAY announce support for in-band registration by including the relevant stream feature:

    +

    &rfc6120; defines methods for advertising feature support during stream negotiation. For the sake of efficiency, it may be desirable for a server to advertise support for in-band registration as a stream feature. The namespace for reporting support within <stream:features/> is "http://jabber.org/features/iq-register". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server returns a stream header to the client and MAY announce support for in-band registration by including the relevant stream feature:

    diff --git a/xep-0078.xml b/xep-0078.xml index ab166fa9..7bc82831 100644 --- a/xep-0078.xml +++ b/xep-0078.xml @@ -197,8 +197,8 @@ ]]> -

    If the client included a username with the IQ-get but there is no such username, the server SHOULD NOT return an error, but instead SHOULD return the normal authentication fields (this helps to prevent unknown users from discovering which usernames are in use). If the server does not support non-SASL authentication (e.g., because it supports only SASL authentication as defined in RFC 6120), it MUST return a &unavailable; error. If the client previously attempted SASL authentication but that attempt failed, the server MUST return a <policy-violation/> stream error (see RFC 6120 regarding stream error syntax).

    -

    Both the username and the resource are REQUIRED for client authentication using the 'jabber:iq:auth' namespace; if more flexible authentication and resource provisioning are desired, a server SHOULD implement SASL authentication and resource binding as defined in RFC 6120 (e.g., to enable the server to provide the resource). The <username/> and <resource/> elements MUST be included in the IQ result returned by the server in response to the initial IQ get, and also MUST be included in the IQ set sent by the client when providing authentication credentials.

    +

    If the client included a username with the IQ-get but there is no such username, the server SHOULD NOT return an error, but instead SHOULD return the normal authentication fields (this helps to prevent unknown users from discovering which usernames are in use). If the server does not support non-SASL authentication (e.g., because it supports only SASL authentication as defined in &rfc6120;), it MUST return a &unavailable; error. If the client previously attempted SASL authentication but that attempt failed, the server MUST return a <policy-violation/> stream error (see RFC 6120 regarding stream error syntax).

    +

    Both the username and the resource are REQUIRED for client authentication using the 'jabber:iq:auth' namespace; if more flexible authentication and resource provisioning are desired, a server SHOULD implement SASL authentication and resource binding as defined in &rfc6120; (e.g., to enable the server to provide the resource). The <username/> and <resource/> elements MUST be included in the IQ result returned by the server in response to the initial IQ get, and also MUST be included in the IQ set sent by the client when providing authentication credentials.

    The foregoing stanza shows that the server supports both plaintext authentication (via the <password/> element) and digest authentication with SHA1-encrypted passwords (via the <digest/> element).

    Therefore, in order to successfully authenticate with the server in this example, a client MUST provide a username, a resource, and one of password or digest.

    ]]> -

    Plaintext passwords are straightforward (obviously, characters that map to predefined XML entities MUST be escaped according to the rules defined in section 4.6 of the XML specification, and any non-US-ASCII characters MUST be encoded according to the encoding of XML streams as specified in RFC 6120, i.e., UTF-8 as defined in &rfc3629;).

    +

    Plaintext passwords are straightforward (obviously, characters that map to predefined XML entities MUST be escaped according to the rules defined in section 4.6 of the XML specification, and any non-US-ASCII characters MUST be encoded according to the encoding of XML streams as specified in &rfc6120;, i.e., UTF-8 as defined in &rfc3629;).

    The value of the <digest/> element MUST be computed according to the following algorithm:

    1. Concatenate the Stream ID received from the server with the password. In Digest authentication, password characters that map to predefined XML entities SHOULD NOT be escaped as they are for plaintext passwords, but non-US-ASCII characters MUST be encoded as UTF-8 since the SHA-1 hashing algorithm operates on byte arrays.
      2. @@ -238,7 +238,7 @@
    2. There is a resource conflict (i.e., there is already an active session with that resource identifier associated with the same username). The RECOMMENDED behavior is for the server to terminate the existing session and create the new one; however, the server MAY provide the opposite behavior if desired, leading to a conflict error for the newly requested login.
    3. The user did not provide all of the required information (e.g., did not provide a username or resource).
    -

    Although RFC 6120 specifies that error stanzas SHOULD include the original XML sent, error stanzas qualified by the 'jabber:iq:auth' namespace SHOULD NOT do so given the sensitive nature of the information being exchanged.

    +

    Although &rfc6120; specifies that error stanzas SHOULD include the original XML sent, error stanzas qualified by the 'jabber:iq:auth' namespace SHOULD NOT do so given the sensitive nature of the information being exchanged.

    @@ -263,7 +263,7 @@     -

    RFC 6120 defines methods for advertising feature support during stream negotiation. It may be desirable for a server to advertise support for non-SASL authentication as a stream feature. The namespace for reporting support within <stream:features/> is "http://jabber.org/features/iq-auth". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server that returns stream features SHOULD also announce support for non-SASL authentication by including the relevant stream feature. Exactly when a server advertises the iq-auth stream feature is up to the implementation or deployment (e.g., a server MAY advertise this feature only after successful TLS negotiation or if the channel is encrypted via the older SSL method). Obviously, this does not apply to servers that do not support stream features (e.g., older servers that do not comply with XMPP 1.0).

    +

    &rfc6120; defines methods for advertising feature support during stream negotiation. It may be desirable for a server to advertise support for non-SASL authentication as a stream feature. The namespace for reporting support within <stream:features/> is "http://jabber.org/features/iq-auth". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server that returns stream features SHOULD also announce support for non-SASL authentication by including the relevant stream feature. Exactly when a server advertises the iq-auth stream feature is up to the implementation or deployment (e.g., a server MAY advertise this feature only after successful TLS negotiation or if the channel is encrypted via the older SSL method). Obviously, this does not apply to servers that do not support stream features (e.g., older servers that do not comply with XMPP 1.0).

    @@ -276,7 +276,7 @@

    A server SHOULD NOT advertise non-SASL authentication to another server (i.e., if the initial stream header was qualified by the 'jabber:server' namespace).

     -

    As defined herein, the 'jabber:iq:auth' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in RFC 6120. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both.

    +

    As defined herein, the 'jabber:iq:auth' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in &rfc6120;. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both.

    In accordance with Section 8 of &xep0001;, on 2004-10-20 this document was advanced to a status of Final with the understanding that it would expire in six months. On 2006-09-13, the Jabber Council (now XMPP Council) changed the status of this document to Deprecated. The Jabber Council will review this document every six months to determine whether to change its status to Obsolete or to extend the expiration date for an additional six months; this process will continue until the document is obsoleted. For the latest expiration date, refer to the XEP Information block at the beginning of this document.

    diff --git a/xep-0081.xml b/xep-0081.xml index fcc1b411..96bc96a9 100644 --- a/xep-0081.xml +++ b/xep-0081.xml @@ -128,7 +128,7 @@ ]]>     -

    The browser passes this file to the helper application, which shall send an IQ stanza of type='get' to the service associated with the JID defined in the file in order to determine the registration requirements (first authenticating with the user's Jabber/XMPP server if necessary), as described in &xep0077;. The helper application shall then instantiate an appropriate interface for registering with the service. If the user completes the interface, the helper application shall then send an IQ stanza of type='set' to the JID as described in XEP-0077.

    +

    The browser passes this file to the helper application, which shall send an IQ stanza of type='get' to the service associated with the JID defined in the file in order to determine the registration requirements (first authenticating with the user's Jabber/XMPP server if necessary), as described in &xep0077;. The helper application shall then instantiate an appropriate interface for registering with the service. If the user completes the interface, the helper application shall then send an IQ stanza of type='set' to the JID as described in &xep0077;.

    -

    Detailed security considerations for instant messaging and presence protocols are given in &rfc2779; (Sections 5.1 through 5.4), and for XMPP in particular are given in RFC 3920 (Sections 12.1 through 12.6). In addition, all of the security considerations specified in RFC 3023 apply to the "application/jabber+xml" media type.

    +

    Detailed security considerations for instant messaging and presence protocols are given in &rfc2779; (Sections 5.1 through 5.4), and for XMPP in particular are given in &rfc3920; (Sections 12.1 through 12.6). In addition, all of the security considerations specified in RFC 3023 apply to the "application/jabber+xml" media type.

    When a helper application has finished processing a file of type "application/jabber+xml", it SHOULD discard the file; this helps to prevent security-related problems that may result from HTTP caching.

     diff --git a/xep-0084.xml b/xep-0084.xml index 045c6a57..8217d7ef 100644 --- a/xep-0084.xml +++ b/xep-0084.xml @@ -179,7 +179,7 @@
  4. Optionally, user disables avatar display.

This process flow is described more fully in the following sections.

-

Note: Before publishing avatar data and metadata, the user MUST determine if his or her server supports the PEP subset of pubsub by following the procedures specified in XEP-0163, since such support simplifies avatar publication. The following examples assume the availability of a PEP service.

+

Note: Before publishing avatar data and metadata, the user MUST determine if his or her server supports the PEP subset of pubsub by following the procedures specified in &xep0163;, since such support simplifies avatar publication. The following examples assume the availability of a PEP service.

Before updating the avatar metadata node, the publisher MUST make sure that the avatar data is available at the data node or URL. When publishing the avatar data to the data node, the publisher MUST ensure that the value of the pubsub ItemID is a SHA-1 hash of the data for the "image/png" content-type (this is used by the subscriber to determine if a locally cached copy can be displayed).

The following example illustrates the XML structure to be sent when publishing avatar data to the data node.

@@ -199,7 +199,7 @@ ]]> -

If the avatar will be made available via HTTP instead of a pubsub data node, the publisher MUST either verify that the avatar exists at the HTTP URL or publish it via standard HTTP methods (such methods are out of scope for this specification; refer to RFC 2616).

+

If the avatar will be made available via HTTP instead of a pubsub data node, the publisher MUST either verify that the avatar exists at the HTTP URL or publish it via standard HTTP methods (such methods are out of scope for this specification; refer to &rfc2616;).

Whenever the publisher wishes to change its current avatar, it MUST update the metadata node. As with the data node, the publisher MUST ensure that the value of the pubsub ItemID is a SHA-1 hash of the data for the "image/png" content-type (the match between the ItemID of the data node and metadata node is used by the subscriber to determine if a locally cached copy can be displayed).

@@ -263,7 +263,7 @@ ]]> -

As shown, depending on node configuration, the item may include &xep0033; information about the publishing resource (see XEP-0060 for details).

+

As shown, depending on node configuration, the item may include &xep0033; information about the publishing resource (see &xep0060; for details).

Upon receiving the notification, each subscriber SHOULD determine if it has a locally cached copy of that avatar (which it can do by searching for an image identified by the ItemID). If the subscriber already has a locally cached copy of the avatar image, it MUST NOT retrieve the image data.

@@ -297,7 +297,7 @@ ]]> -

If the <info/> element sent to the metadata node possesses a 'url' attribute, the avatar data is hosted at a URL. Therefore, in order to retrieve the avatar image data for that content-type, the requesting entity MUST send an HTTP request to the specified URL. Methods for doing so are out of scope for this specification (see RFC 2616).

+

If the <info/> element sent to the metadata node possesses a 'url' attribute, the avatar data is hosted at a URL. Therefore, in order to retrieve the avatar image data for that content-type, the requesting entity MUST send an HTTP request to the specified URL. Methods for doing so are out of scope for this specification (see &rfc2616;).

In order to temporarily disable avatar publishing, the user publishes an empty <metadata/> element to the metadata node.

@@ -519,7 +519,7 @@ ]]> -

The contact then MAY subscribe to the metadata node following the protocol specified in XEP-0060. However, the contact SHOULD NOT subscribe to the data node (instead, it SHOULD simply retrieve items from that node when needed, as described above).

+

The contact then MAY subscribe to the metadata node following the protocol specified in &xep0060;. However, the contact SHOULD NOT subscribe to the data node (instead, it SHOULD simply retrieve items from that node when needed, as described above).

 @@ -527,7 +527,7 @@

If a user has multiple online resources at the same time, each resource MAY publish a different avatar. The PEP service SHOULD include the "replyto" address of the publishing resource as shown above in order to facilitate differentiation between per-resource avatars.

-

When a user logs in with a new resource and before publishing an avatar, its client SHOULD retrieve its last published avatar, either automatically by sending presence with the appropriate entity capabilities information (see XEP-0115) or using the "retrieve-items" method described in XEP-0060.

+

When a user logs in with a new resource and before publishing an avatar, its client SHOULD retrieve its last published avatar, either automatically by sending presence with the appropriate entity capabilities information (see &xep0115;) or using the "retrieve-items" method described in XEP-0060.

It is the responsibility of the receiving application to determine which avatar format to retrieve (e.g., "image/gif" rather than "image/png") and to determine the appropriate method for retrieval (e.g., HTTP rather than pubsub).

@@ -536,7 +536,7 @@ -

See XEP-0060 and XEP-0163 regarding security considerations related to the underlying transport protocol.

+

See &xep0060; and XEP-0163 regarding security considerations related to the underlying transport protocol.

It is possible that output of the SHA-1 hashing algorithm can result in collisions; however, the use of SHA-1 in producing a hash of the avatar data is not security-critical.

 diff --git a/xep-0085.xml b/xep-0085.xml index 783353d7..7ba0fb7b 100644 --- a/xep-0085.xml +++ b/xep-0085.xml @@ -145,7 +145,7 @@ -

Many instant messaging systems include notifications about the state of one's conversation partner in a one-to-one chat (or, sometimes, in a many-to-many chat). Usually these are limited to notification that one's partner is currently typing -- e.g., the Composing event in the older (deprecated) &xep0022; protocol. However, a composing event is essentially information about a person's participation in or involvement with the chat "session" and therefore is really a session-level state rather than a per-message event (in contrast to the Delivered and Displayed events in XEP-0022). While the composing event is interesting, the concept of a session-level state can be extended to answer a variety of questions about the participation of a person in a real-time chat conversation, such as:

+

Many instant messaging systems include notifications about the state of one's conversation partner in a one-to-one chat (or, sometimes, in a many-to-many chat). Usually these are limited to notification that one's partner is currently typing -- e.g., the Composing event in the older (deprecated) &xep0022; protocol. However, a composing event is essentially information about a person's participation in or involvement with the chat "session" and therefore is really a session-level state rather than a per-message event (in contrast to the Delivered and Displayed events in &xep0022;). While the composing event is interesting, the concept of a session-level state can be extended to answer a variety of questions about the participation of a person in a real-time chat conversation, such as:

Note: Clients that only support Polling Sessions MAY prevent the connection manager from waiting by setting 'wait' or 'hold' to "0". However, polling is NOT RECOMMENDED since the associated increase in bandwidth consumption and the decrease in responsiveness are both typically one or two orders of magnitude!

-

A connection manager MAY be configured to enable sessions with more than one server in different domains. When requesting a session with such a "proxy" connection manager, a client SHOULD include a 'route' attribute that specifies the protocol, hostname, and port of the server with which it wants to communicate, formatted as "proto:host:port" (e.g., "xmpp:example.com:9999"). Although the syntax of the 'route' attribute bears a superficial resemblance to a URI or IRI, it is not a URI/IRI and MUST NOT be processed in accordance with the rules specified in RFC 3986, RFC 3987, or (for XMPP) RFC 5122. A connection manager that is configured to work only with a single server (or only with a defined list of domains and the associated list of hostnames and ports that are serving those domains) MAY ignore the 'route' attribute. (Note that the 'to' attribute specifies the domain being served, not the hostname of the machine that is serving the domain.)

-

The <body/> element of the first request MAY also possess a 'from' attribute, which specifies the originator of the first stream and which enables the connection manager to forward the originating entity's identity to the application server (e.g., the JabberID of an entity that is connecting to an XMPP server; see XEP-0206).

+

A connection manager MAY be configured to enable sessions with more than one server in different domains. When requesting a session with such a "proxy" connection manager, a client SHOULD include a 'route' attribute that specifies the protocol, hostname, and port of the server with which it wants to communicate, formatted as "proto:host:port" (e.g., "xmpp:example.com:9999"). Although the syntax of the 'route' attribute bears a superficial resemblance to a URI or IRI, it is not a URI/IRI and MUST NOT be processed in accordance with the rules specified in &rfc3986;, RFC 3987, or (for XMPP) RFC 5122. A connection manager that is configured to work only with a single server (or only with a defined list of domains and the associated list of hostnames and ports that are serving those domains) MAY ignore the 'route' attribute. (Note that the 'to' attribute specifies the domain being served, not the hostname of the machine that is serving the domain.)

+

The <body/> element of the first request MAY also possess a 'from' attribute, which specifies the originator of the first stream and which enables the connection manager to forward the originating entity's identity to the application server (e.g., the JabberID of an entity that is connecting to an XMPP server; see &xep0206;).

A client MAY include an 'ack' attribute (set to "1") to indicate that it will be using acknowledgements throughout the session and that the absence of an 'ack' attribute in any request is meaningful (see Acknowledgements).

Some clients are constrained to only accept HTTP responses with specific Content-Types (e.g., "text/html"). The <body/> element of the first request MAY possess a 'content' attribute. This specifies the value of the HTTP Content-Type header that MUST appear in all the connection manager's responses during the session. If the client request does not possess a 'content' attribute, then the HTTP Content-Type header of responses MUST be "text/xml; charset=utf-8".

@@ -927,7 +927,7 @@ Content-Length: 132

In any response it sends to the client, the connection manager MAY return a fatal error by setting a 'type' attribute of the <body/> element to "terminate". These binding errors imply that the HTTP session is terminated (unless a 'stream' attribute is specified -- see Multiple Stream Error Conditions).

-

Note: Although many of these conditions are similar to the XMPP stream error conditions specified in RFC 6120, they are not to be confused with XMPP stream errors. In cases where BOSH is being used to transport XMPP, any fatal XMPP stream error conditions experienced between the connection manager and the XMPP server SHOULD only be reported using the "remote-stream-error" condition as described below.

+

Note: Although many of these conditions are similar to the XMPP stream error conditions specified in &rfc6120;, they are not to be confused with XMPP stream errors. In cases where BOSH is being used to transport XMPP, any fatal XMPP stream error conditions experienced between the connection manager and the XMPP server SHOULD only be reported using the "remote-stream-error" condition as described below.

-

HTTP pipelining allows a client to send multiple requests over the same HTTP socket connection without waiting for the corresponding responses. However, RFC 2616 notes that only idempotent methods should be allowed to use HTTP pipelining, which does not include the POST method used extensively by BOSH. Furthermore, there is no guarantee that pipelining will succeed because intermediate proxies might not support it. Therefore, clients and connection managers SHOULD NOT use HTTP Pipelining.

+

HTTP pipelining allows a client to send multiple requests over the same HTTP socket connection without waiting for the corresponding responses. However, &rfc2616; notes that only idempotent methods should be allowed to use HTTP pipelining, which does not include the POST method used extensively by BOSH. Furthermore, there is no guarantee that pipelining will succeed because intermediate proxies might not support it. Therefore, clients and connection managers SHOULD NOT use HTTP Pipelining.

 diff --git a/xep-0126.xml b/xep-0126.xml index ecd79955..4b5f0b97 100644 --- a/xep-0126.xml +++ b/xep-0126.xml @@ -60,7 +60,7 @@ -

Several popular instant messaging services implement a feature known as invisibility: the ability to remain online yet appear offline to some or all of one's contacts. A number of Jabber servers and clients have also implemented such a feature, using special values of the &PRESENCE; element's 'type' attribute (e.g., <presence type='invisible'/>). Unfortunately, such implementations are not compliant with &xmppcore; and &xmppim;, which specify that only the 'type' attribute values defined in the XML schema for the 'jabber:client' and 'jabber:server' namespaces are allowed in XMPP (and those values do not include "invisible"). However, RFC 3921 also defines a privacy lists protocol (i.e., the 'jabber:iq:privacy' namespace) that can be used to implement invisibility in an XMPP-compliant manner. This specification documents how to do just that.

+

Several popular instant messaging services implement a feature known as invisibility: the ability to remain online yet appear offline to some or all of one's contacts. A number of Jabber servers and clients have also implemented such a feature, using special values of the &PRESENCE; element's 'type' attribute (e.g., <presence type='invisible'/>). Unfortunately, such implementations are not compliant with &xmppcore; and &xmppim;, which specify that only the 'type' attribute values defined in the XML schema for the 'jabber:client' and 'jabber:server' namespaces are allowed in XMPP (and those values do not include "invisible"). However, &rfc3921; also defines a privacy lists protocol (i.e., the 'jabber:iq:privacy' namespace) that can be used to implement invisibility in an XMPP-compliant manner. This specification documents how to do just that.

This document addresses the following requirements:

@@ -410,7 +410,7 @@

Privacy lists can become complex and must be carefully managed by clients. For example, let us imagine that the user is currently applying another active list unrelated to visibility (e.g., a list that blocks communications with a stalker); if the user then clicks "Go Invisible" and the client is not smart, it could overwrite the stalker blocking. Therefore, if the user has an active list that incorporates rules other than those related to visibility/invisibility, the client SHOULD either assume that visibility/invisibility is an overlay on the list currently in use (generating an appropriate privacy list that takes both into account) or prompt the user regarding their intentions. In the absence of privacy lists unrelated to visibility/invisibility, the client may proceed in a less cautious fashion.

 -

For security concerns related to privacy lists, refer to RFC 3921. Care must be taken regarding privacy lists, especially so that visibility/invisibility rules do not overwrite existing rules the user has set for the sake of security and privacy; for details, see the Implementation Notes section of this document.

+

For security concerns related to privacy lists, refer to &rfc3921;. Care must be taken regarding privacy lists, especially so that visibility/invisibility rules do not overwrite existing rules the user has set for the sake of security and privacy; for details, see the Implementation Notes section of this document.

It is important to recognize that invisibility can be defeated without more advanced privacy lists than those defined above and an awareness of context on the part of a client. For example, if a user usually logs in as the same resource (e.g., "Home"), a contact can send an IQ request to that resource's full JID using &xep0012;, &xep0030;, &xep0090;, or &xep0092; and receive a reply, thus providing information that reveals the user's availability. In addition, Last Activity requests sent by a subscribed contact to the user's bare JID will normally reveal the user's availability as well. To help ensure that the user's invisibility cannot be defeated in this way, the user's client SHOULD add IQ blocking to the relevant privacy list. Finally, the user's client SHOULD NOT return "is-composing" events as defined in &xep0022; or &xep0085;.

 @@ -420,6 +420,6 @@

No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this specification.

 -

The XML schema for the 'jabber:iq:privacy' namespace is defined in RFC 3921.

+

The XML schema for the 'jabber:iq:privacy' namespace is defined in &rfc3921;.

 diff --git a/xep-0129.xml b/xep-0129.xml index 6505ec7a..8f2268ef 100644 --- a/xep-0129.xml +++ b/xep-0129.xml @@ -57,7 +57,7 @@ -

This document inherits terms from RFC 2518, &rfc2616;, and &rfc2617;.

+

This document inherits terms from &rfc2518;, &rfc2616;, and &rfc2617;.

The client SHOULD attempt to PUT the file on the server. Alternatively, the client MAY first attempt one or more HEAD requests to determine a unique URL. The PUT request MUST include an "If-None-Match" header as well as an "Authorization" header that specifies appropriate authentication information.

@@ -158,7 +158,7 @@ url='https://files.shakespeare.lit:9345/missive.html'/> ]]> -

If the XEP-0070 verification is successful, the server then allows the file to be retrieved:

+

If the &xep0070; verification is successful, the server then allows the file to be retrieved:

The user now knows that the "files.shakespeare.lit" service supports this protocol.

 -

See RFC 2518, XMPP Core, and XEP-0070 for security considerations related to those protocols, which are used by the profile defined herein. The initiating client MUST ensure that appropriate access controls are specified, normally by performing a PROPPATCH request to set the list of Jabber IDs authorized to retrieve the file. The server MUST NOT allow access to the file until access controls have been specified. In addition, the server MUST NOT allow access to the file by any unauthorized entity.

+

See &rfc2518;, XMPP Core, and &xep0070; for security considerations related to those protocols, which are used by the profile defined herein. The initiating client MUST ensure that appropriate access controls are specified, normally by performing a PROPPATCH request to set the list of Jabber IDs authorized to retrieve the file. The server MUST NOT allow access to the file until access controls have been specified. In addition, the server MUST NOT allow access to the file by any unauthorized entity.

This document requires no interaction with &IANA;.

diff --git a/xep-0130.xml b/xep-0130.xml index 5d1ac7f7..6ce7a71a 100644 --- a/xep-0130.xml +++ b/xep-0130.xml @@ -530,7 +530,7 @@ ]]> -

As described below, various error conditions may occur. (For information about error syntax, refer to RFC 6120 and &xep0086;.)

+

As described below, various error conditions may occur. (For information about error syntax, refer to &rfc6120; and &xep0086;.)

If the IM User provided a URI whose scheme is not supported, WaitingListService MUST return a &badrequest; error to the IM User and MUST NOT add the Contact to the WaitingList.

Date formats differ widely. &xep0082; defines the Date, DateTime, and Time profiles of &iso8601;, which correspond to the Date, DateTime, and Time headers registered herein. The SHIM Date header also corresponds to the Date metadata element used in &DUBLINCORE; as specified in &rfc2413;.

-

However, many Internet standards use a different datetime format that ultimately derives from &rfc0822; as updated by &rfc1123;; specifically, that format is used by email (RFC 2822), the World Wide Web (RFC 2616), and the Session Initiation Protocol (RFC 3261). To map dates to and from these protocols, we define the SHIM RFC2822Date header.

+

However, many Internet standards use a different datetime format that ultimately derives from &rfc0822; as updated by &rfc1123;; specifically, that format is used by email (&rfc2822;), the World Wide Web (RFC 2616), and the Session Initiation Protocol (RFC 3261). To map dates to and from these protocols, we define the SHIM RFC2822Date header.

In general, security considerations are the responsibility of the "using protocol".

diff --git a/xep-0133.xml b/xep-0133.xml index 35474044..41eb065b 100644 --- a/xep-0133.xml +++ b/xep-0133.xml @@ -1000,7 +1000,7 @@ ]]> -

The service may enable an administrator to define one or more service-wide whitelists (lists of entities that are allowed to communicate the service). For example, a publish-subscribe may allow only a select list of users to publish or subscribe to nodes hosted on the service. An entity added to a whitelist MAY be a JID of any form as specified in RFC 6120; the order of JID matching SHOULD be that specified for privacy lists in &xep0016;.

+

The service may enable an administrator to define one or more service-wide whitelists (lists of entities that are allowed to communicate the service). For example, a publish-subscribe may allow only a select list of users to publish or subscribe to nodes hosted on the service. An entity added to a whitelist MAY be a JID of any form as specified in &rfc6120;; the order of JID matching SHOULD be that specified for privacy lists in &xep0016;.

As with blacklists, a whitelist may prevent inbound communications, outbound communications, or both; whether to offer only bidirectional blocking or a more granular choice of inbound or outbound blocking is a matter of implementation or deployment policy. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#add-to-whitelist" if blocking is bidirectional; "http://jabber.org/protocol/admin#add-to-whitelist-in" for inbound blocking only; and "http://jabber.org/protocol/admin#add-to-whitelist-out" for outbound blocking only.

A sample protocol flow for this use case is shown below.

 -

It may be helpful to enable an administrator to retrieve the number of registered users who are online at any one moment. By "online user" is meant any user or account that currently has at least one connected or available resource as specified in RFC 6120 and RFC 6121, whether that user is actively sending XML stanzas or is idle. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-online-users-num".

+

It may be helpful to enable an administrator to retrieve the number of registered users who are online at any one moment. By "online user" is meant any user or account that currently has at least one connected or available resource as specified in &rfc6120; and RFC 6121, whether that user is actively sending XML stanzas or is idle. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-online-users-num".

A sample protocol flow for this use case is shown below.

The content of each <to/> or <from/> element SHOULD depend on the user's Archiving Preferences. <to/> or <from/> elements MUST NOT be empty. Note: A server MAY be configured to return a <feature-not-implemented/> error if any <to/> or <from/> element contains anything other than &BODY; elements.

 -

The <note/> element specifies a private note about the conversation. The absolute time the note was created SHOULD be specified with a 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in XEP-0082). Inclusion of the <note/> element is OPTIONAL.

+

The <note/> element specifies a private note about the conversation. The absolute time the note was created SHOULD be specified with a 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in &xep0082;). Inclusion of the <note/> element is OPTIONAL.

 @@ -703,7 +703,7 @@
  • A client wants to maintain a unified archive for messages that were transmitted both in and out-of-band (e.g. SMS or email)
  • A client wants to append private notes to a conversation
    • -

    Therefore, often a client will want to send or receive a sequence of messages, optionally add private notes to the sequence, optionally encrypt the sequence (see XEP-0241), and then ask the server to archive it. Such messages and notes SHOULD be stored on the server in the form of a "collection".

    +

    Therefore, often a client will want to send or receive a sequence of messages, optionally add private notes to the sequence, optionally encrypt the sequence (see &xep0241;), and then ask the server to archive it. Such messages and notes SHOULD be stored on the server in the form of a "collection".

    A collection of messages and notes is uploaded to the server encapsulated in a <save/> element.

    @@ -779,7 +779,7 @@ ]]>     -

    The client MAY specify an absolute time for any message by providing a 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in XEP-0082) instead of a 'secs' attribute. The absolute time MAY be earlier than the start time of the collection:

    +

    The client MAY specify an absolute time for any message by providing a 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in &xep0082;) instead of a 'secs' attribute. The absolute time MAY be earlier than the start time of the collection:

    @@ -872,7 +872,7 @@ ]]> -

    As described in XEP-0241, the content of the uploaded x:data form MAY be encrypted.

    +

    As described in &xep0241;, the content of the uploaded x:data form MAY be encrypted.

         @@ -935,7 +935,7 @@

    Requirements and protocol flows for each of these use cases are defined below. The protocols to retrieve a list of collections and an indivdual collection both make extensive use of &xep0059;. Clients and servers SHOULD support all the features defined in that protocol.

    -

    To request a list of collections, the client sends a <list/> element. The 'start' and 'end' attributes MAY be specified to indicate a date range (the values of these attributes MUST be UTC and adhere to the DateTime format specified in XEP-0082). The 'with' attribute MAY specify the JIDs of XMPP entities (see the JID Matching section of this document).

    +

    To request a list of collections, the client sends a <list/> element. The 'start' and 'end' attributes MAY be specified to indicate a date range (the values of these attributes MUST be UTC and adhere to the DateTime format specified in &xep0082;). The 'with' attribute MAY specify the JIDs of XMPP entities (see the JID Matching section of this document).

    If the 'with' attribute is omitted then collections with any JID are returned. If only 'start' is specified then all collections on or after that date should be returned. If only 'end' is specified then all collections prior to that date should be returned.

    The client SHOULD use Result Set Management to limit the number of collections returned by the server in a single stanza, taking care not to request a page of collections that is so big it might exceed rate limiting restrictions.

    Refer to Result Set Management to learn more about the various ways that the pages of the list may be accessed.

     -

    To request a page of messages from a collection the client sends a <retrieve/> element. The 'with' and 'start' attributes specify the participating JID and the start time (see XEP-0082). Both attributes MUST be included to uniquely identify a collection.

    +

    To request a page of messages from a collection the client sends a <retrieve/> element. The 'with' and 'start' attributes specify the participating JID and the start time (see &xep0082;). Both attributes MUST be included to uniquely identify a collection.

    Note: the <retrieve/> SHALL NOT possess the 'exactmatch' attribute, because exact JID matching is always implied for this command (see the JID Matching section of this document). This is done to prevent the return of multiple collections in response to the <retrieve/> command.

    The client SHOULD use Result Set Management to limit the number of messages returned by the server in a single stanza, taking care not to request a page of messages that is so big it might exceed rate limiting restrictions.

    This section describes how a client can replicate an archive locally. Clients that run in constrained environments may not be able to implement replication if they are prevented from accessing (sufficient) local storage. The existence of a local copy of the archive enables clients to search the content of all messages (including collections saved by another client machine). Since collections SHOULD be stored on the server in a form that it cannot decrypt, server-side searching of the content of messages is beyond the scope of this protocol.

    The client can "synchronize" its local copy of the archive with the "primary" archive on the server at any time. The first step is to request the list of collections that the server has modified (created, changed, or removed) in its primary archive since the last update to the client's copy of the archive.

    Replication uses the <modified/> element. The list of collections that have been modified since a given time is requested by sending a <modified/> element to the server. The server then returns the list of collections that have been created, changed, or removed. A collection that has been created or changed is specified with a <changed/> element (with version zero for created collections), and a collection that has been removed is specified with a <removed/> element.

    -

    When requesting the list of modified collections, the client MUST embed appropriate Result Set Management data in the <modified/> element. The <modified/> element MUST include a 'start' attribute that specifies a UTC datetime (see XEP-0082) that it has previously received from the server or that it has determined locally (e.g., when synchronizing for the first time the client SHOULD choose a suitable time for the first page request, such as 1970-01-01T00:00:00Z).

    +

    When requesting the list of modified collections, the client MUST embed appropriate Result Set Management data in the <modified/> element. The <modified/> element MUST include a 'start' attribute that specifies a UTC datetime (see &xep0082;) that it has previously received from the server or that it has determined locally (e.g., when synchronizing for the first time the client SHOULD choose a suitable time for the first page request, such as 1970-01-01T00:00:00Z).

    -

    If automatic archiving defaults to enabled then that creates serious privacy issues for users of legacy clients that do not support this protocol, and (more seriously) for those contacts who they unwittingly mislead by agreeing to disable logging (via the 'logging' field defined in XEP-0155).

    +

    If automatic archiving defaults to enabled then that creates serious privacy issues for users of legacy clients that do not support this protocol, and (more seriously) for those contacts who they unwittingly mislead by agreeing to disable logging (via the 'logging' field defined in &xep0155;).

    If a server deployment enables automatic archiving by default, then it MUST return a stream feature containing an empty <default/> element (see the Stream Feature section of this document).

     diff --git a/xep-0137.xml b/xep-0137.xml index 21347d06..8c6cae84 100644 --- a/xep-0137.xml +++ b/xep-0137.xml @@ -82,7 +82,7 @@ ]]>     -

    This format is nearly identical to that for the stream initiation <si/> element (see XEP-0095). The major difference is the lack of the feature negotiation for the stream methods, and the addition of a 'from' attribute.

    +

    This format is nearly identical to that for the stream initiation <si/> element (see &xep0095;). The major difference is the lack of the feature negotiation for the stream methods, and the addition of a 'from' attribute.

    The 'from' attribute SHOULD be present, and MUST be present if the stanza containing the <sipub/> is not from the stream owner (e.g., if the stream is advertised at a publish-subscribe node). If present, this attribute MUST be the valid JID for the stream owner.

    The 'id' attribute is an opaque identifier. This attribute MUST be present, and MUST be a valid non-empty string. It uniquely identifies the published request at the potential sender.

    As with stream initiation, the 'profile' attribute MUST be present, and MUST be the namespace URI governing the profile information. It identifies the format for the SI profile.

    @@ -152,7 +152,7 @@

    One of the goals of sipub is to integrate Stream Initiation with Data Forms to provide a "file upload" capability. This is accomplished via the datatypes specified in &xep0122;. Each datatype is specific to the profile desired.

    -

    For example the datatype "sipub:file-transfer" is used to identify the file upload field(s) corresponding to XEP-0096:

    +

    For example the datatype "sipub:file-transfer" is used to identify the file upload field(s) corresponding to &xep0096;:

    -

    This document introduces no security concerns beyond those specified in XEP-0060 and the relevant Stream Initiation profile in use.

    +

    This document introduces no security concerns beyond those specified in &xep0060; and the relevant Stream Initiation profile in use.

    This document requires no interaction with &IANA;.

    diff --git a/xep-0138.xml b/xep-0138.xml index 1cdedd48..88f49331 100644 --- a/xep-0138.xml +++ b/xep-0138.xml @@ -139,7 +139,7 @@ ]]> -

    Both entities MUST now consider the previous (uncompressed) stream to be null and void, just as with TLS negotiation and SASL negotiation (as specified in RFC 3920) and MUST begin compressed communications with a new (compressed) stream. Therefore the initiating entity MUST initiate a new stream to the receiving entity:

    +

    Both entities MUST now consider the previous (uncompressed) stream to be null and void, just as with TLS negotiation and SASL negotiation (as specified in &rfc3920;) and MUST begin compressed communications with a new (compressed) stream. Therefore the initiating entity MUST initiate a new stream to the receiving entity:

    ]]> -

    Finally an example of a required form submission before a user is allowed to the workgroup queue for support@workgroup.example.com. The data form in this example is trivial; please see XEP-0004 for a complete data form example. The example begins as normal, but the workgroup returns a &e406; error.

    +

    Finally an example of a required form submission before a user is allowed to the workgroup queue for support@workgroup.example.com. The data form in this example is trivial; please see &xep0004; for a complete data form example. The example begins as normal, but the workgroup returns a &e406; error.

    -

    The server sends an invitation to the user to begin their conversation with an agent, structured according to the format defined in XEP-0045. The 'from' attribute of the <invite/> element MUST be set to the JID of the workgroup. The invitation indicates that the user is no longer in the workgroup queue. The user MUST NOT receive any more user queue status updates once they receive an invitation.

    +

    The server sends an invitation to the user to begin their conversation with an agent, structured according to the format defined in &xep0045;. The 'from' attribute of the <invite/> element MUST be set to the JID of the workgroup. The invitation indicates that the user is no longer in the workgroup queue. The user MUST NOT receive any more user queue status updates once they receive an invitation.

    There are no defined error conditions for user invitations.

     @@ -664,7 +664,7 @@ S:
    • <position> - The user's zero-based position in the queue.
    • <time> - Estimated time in seconds remaining before the user is routed to an agent.
      • -
    • <join-time> - The datetime when the user joined the queue (MUST conform to the DateTime profile defined in XEP-0082).
      • +
    • <join-time> - The datetime when the user joined the queue (MUST conform to the DateTime profile defined in &xep0082;).

    There are no defined error conditions for workgroup queue status updates.

    @@ -899,7 +899,7 @@ Agent Service |<-----------------------------| | | ]]>     -

    The server sends an invitation to the agent to begin their conversation with the user, structured according to the format defined in XEP-0045. The 'from' attribute of the <invite/> element MUST be set to the JID of the workgroup.

    +

    The server sends an invitation to the agent to begin their conversation with the user, structured according to the format defined in &xep0045;. The 'from' attribute of the <invite/> element MUST be set to the JID of the workgroup.

    In order to match invitations to offers, all invitations SHOULD include metadata in the <offer/> element, with the JID of the user specified via the 'jid' attribute. The typical metadata fragment would appear as:

    diff --git a/xep-0143.xml b/xep-0143.xml index 1e52406d..588676b3 100644 --- a/xep-0143.xml +++ b/xep-0143.xml @@ -87,7 +87,7 @@

    After completing this research, the prospective author might conclude that a new protocol extension is needed. If so, the author is strongly advised to do the following:

      -
    1. Review XEP-0001 and the &xep0134;.
      2. +
    2. Review &xep0001; and the &xep0134;.
    3. Understand the Submission Process.
    4. Become familiar with the XEP XML Format.
    5. Then and only then write a proposal that includes all of the appropriate Sections of a XEP.
      6. @@ -115,7 +115,7 @@
    6. Create a pull request from your fork to the master branch at the GitHub mirror.

    The XMPP Extensions Editor team will then process your pull request, seek Council approval if necessary, and publish an updated version of your XEP.

    -

    NOTE: As explained in XEP-0001, updated versions of XEPs in the Experimental state are published without the need for approval by the XMPP Council. However, updated versions of XEPs in the Active, Draft, or Final state must be approved by the XMPP Council to ensure proper change control regarding approved protocols.

    +

    NOTE: As explained in &xep0001;, updated versions of XEPs in the Experimental state are published without the need for approval by the XMPP Council. However, updated versions of XEPs in the Active, Draft, or Final state must be approved by the XMPP Council to ensure proper change control regarding approved protocols.

    @@ -137,8 +137,8 @@

    The XML character data of the <type/> element SHOULD be either "Standards Track" or "Informational" (there are also Historical, Humorous, and Procedural XEPs, but these are uncommon and usually written by the XMPP Extensions Editor team). A Standards Track XEP defines an XMPP extension intended to be used as a common part of XMPP technologies. An Informational XEP defines best practices or a usage profile related to XMPP or an XMPP Extension Protocol (e.g., &xep0175;).

    The XML character data of the <approver/> element SHOULD be "Council".

    The <dependencies/> element is used to specify RFCs, XMPP Extension Protocols, and other specifications on which your proposal depends in a normative fashion (i.e., specifications that MUST or SHOULD be understood in order to implement your proposed protocol). Each specification MUST be identified by a distinct <spec/> child element (see existing XEP specifications for clues regarding document identifiers, or consult with the XMPP Extensions Editor team).

    -

    The <supersedes/>, <supersededby/>, <shortname/>, and <schemaloc/> elements are for use by the XMPP Extensions Editor team; however, if your document supersedes an existing XMPP Extension Protocol, feel free to include a <spec/> child element specifying the document identifier (e.g., XEP-0093) for the protocol that is being superseded.

    -

    Include one <author/> element for each co-author. Note well that the <firstname/> and <surname/> elements are REQUIRED per XEP-0001, as is some combination of the <email/>, <jid/>, and <uri/> elements so that appropriate contact information is available.

    +

    The <supersedes/>, <supersededby/>, <shortname/>, and <schemaloc/> elements are for use by the XMPP Extensions Editor team; however, if your document supersedes an existing XMPP Extension Protocol, feel free to include a <spec/> child element specifying the document identifier (e.g., &xep0093;) for the protocol that is being superseded.

    +

    Include one <author/> element for each co-author. Note well that the <firstname/> and <surname/> elements are REQUIRED per &xep0001;, as is some combination of the <email/>, <jid/>, and <uri/> elements so that appropriate contact information is available.

    Include one <revision/> element for each revision of your document. The XML character data of the <version/> element SHOULD be "0.0.1" for your initial submission to the XMPP Extensions Editor team, and the <remark/> SHOULD be "First draft."; for each revision, you will include another <revision/> element (place it before the existing <revision/> elements) and iterate the <version/> element (e.g., "0.0.2" after "0.0.1" or "0.10" after "0.9"). The format for the <date/> element is yyyy-mm-dd.

     @@ -189,7 +189,7 @@ ]]> -

    If your proposal defines a number of error and status codes (as is done in XEP-0045), it is a good idea to include a table of all the codes defined in your document.

    +

    If your proposal defines a number of error and status codes (as is done in &xep0045;), it is a good idea to include a table of all the codes defined in your document.

    You may want to include a section describing various business rules (essentially, a variety of MUSTs, SHOULDs, and MAYs regarding application behavior). This is not required but can be helpful to implementers.

    @@ -201,7 +201,7 @@

    If there are any internationalization or localization issues related to your proposal (e.g., whether to include the 'xml:lang' attribute), define them in this optional section.

     -

    Your proposal MUST include a section entitled "Security Considerations". Even if there are no security features or concerns related to your proposal, you MUST note that fact. For helpful guidelines, refer to &rfc3552;; the core XMPP specification (RFC 6120) also includes a very thorough security considerations section that can be used as an examplar.

    +

    Your proposal MUST include a section entitled "Security Considerations". Even if there are no security features or concerns related to your proposal, you MUST note that fact. For helpful guidelines, refer to &rfc3552;; the core XMPP specification (&rfc6120;) also includes a very thorough security considerations section that can be used as an examplar.

    This section is REQUIRED. The IANA is &IANA;, the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. Most proposals do not require interaction with the IANA, in which case the text of this section SHOULD read "This document requires no interaction with the Internet Assigned Numbers Authority (IANA)." If your proposal requires interaction with the IANA, discuss the matter with the XMPP Extensions Editor team in their role as the XMPP Registrar. Do not contact the IANA on your own!

    @@ -266,14 +266,14 @@ echo -n 'bard@shakespeare.lit' | openssl enc -nopad -base64

    When talking about an element by name, refer to it as an empty XML element. Example: the <query/> element.

    -

    The top-level &MESSAGE;, &PRESENCE;, and &IQ; elements are actually XML stanzas (see RFC 6120); please refer to them as stanzas, not elements.

    +

    The top-level &MESSAGE;, &PRESENCE;, and &IQ; elements are actually XML stanzas (see &rfc6120;); please refer to them as stanzas, not elements.

    Elements possess attributes and contain character data and/or child elements; do not confuse these terms.

    Do not use the term "tag" when you mean "element".

    Do not add a possessive to the element itself. Negative example: the <body/>'s character data. Positive example: the <body/> element's character data.

    Note: There are shortcuts for stanza names and some common element names in the xep.ent file.

     -

    When talking about an error condition, use the XML element names defined in RFC 6120 rather than the old HTTP-style code numbers. Example: the <feature-not-implemented/> error.

    +

    When talking about an error condition, use the XML element names defined in &rfc6120; rather than the old HTTP-style code numbers. Example: the <feature-not-implemented/> error.

    Note: There are shortcuts for the stanza errors in the xep.ent file.

     diff --git a/xep-0144.xml b/xep-0144.xml index ed8bafe9..39431b12 100644 --- a/xep-0144.xml +++ b/xep-0144.xml @@ -106,7 +106,7 @@
  • Enable an entity to send one or more roster items to another entity, with the suggestion that the roster item(s) be deleted from the recipient's roster.
  • Enable an entity to send one or more roster items to another entity, with the suggestion that the roster item(s) be modified in the recipient's roster.
    • -

    This document deliberately speaks of rosters and roster items, not presence subscriptions. Although rosters and subscriptions are closely connected (as explained in RFC 3921), they are not identical. The protocol defined herein enables an entity to suggest that another entity might want to add, delete, or modify roster items only, and does not dictate the suggested presence subscription state associated with those roster items. This is intentional.

    +

    This document deliberately speaks of rosters and roster items, not presence subscriptions. Although rosters and subscriptions are closely connected (as explained in &rfc3921;), they are not identical. The protocol defined herein enables an entity to suggest that another entity might want to add, delete, or modify roster items only, and does not dictate the suggested presence subscription state associated with those roster items. This is intentional.

    @@ -134,7 +134,7 @@
  • If the item does not already exist in the roster, the receiving application SHOULD prompt a human user for approval regarding that item and, if approval is granted, MUST add that item to the roster.
  • If the item already exists in the roster but not in the specified group, the receiving application MAY prompt the user for approval and SHOULD edit the existing item so that will also belong to the specified group (in addition to the existing group, if any).
    • -

    If the roster item addition stanza will result in adding the item to the roster, the receiving application MUST (either with approval by a human user or automatically subject to configuration) send a roster set to the user's server containing the new item as described in RFC 3921. After completing the roster set, the receiving application SHOULD also send a &PRESENCE; stanza of type "subscribe" to the JID of the new item.

    +

    If the roster item addition stanza will result in adding the item to the roster, the receiving application MUST (either with approval by a human user or automatically subject to configuration) send a roster set to the user's server containing the new item as described in &rfc3921;. After completing the roster set, the receiving application SHOULD also send a &PRESENCE; stanza of type "subscribe" to the JID of the new item.

    For a description of the recommended application behavior when a roster item addition stanza actually results in editing of an existing roster item, refer to the Suggesting Roster Item Modification section of this document.

     @@ -161,7 +161,7 @@
  • If the item exists in the roster but not in the specified group, the receiving application MUST NOT prompt the user for approval and MUST NOT delete the existing item.
  • If the item exists in the roster and is in both the specified group and another group, the receiving application MAY prompt the user for approval and SHOULD edit the existing item so that it no longer belongs to the specified group.
    • -

    If the item is to be deleted, the receiving application SHOULD remove the item from the roster by sending a roster set to the user's server with the 'subscription' attribute set to a value of "remove" as described in RFC 3921, since this results in generation of the appropriate &PRESENCE; stanzas by the user's server.

    +

    If the item is to be deleted, the receiving application SHOULD remove the item from the roster by sending a roster set to the user's server with the 'subscription' attribute set to a value of "remove" as described in &rfc3921;, since this results in generation of the appropriate &PRESENCE; stanzas by the user's server.

    In order to programatically suggest that the receiving entity should modify one or more items from its roster, the sending entity MUST send a &MESSAGE; or &IQ; stanza containing an &X; element qualified by the 'http://jabber.org/protocol/rosterx' namespace; the &X; element in turn MUST contain one or more <item/> child elements, each of which MUST possess an 'action' attribute whose value is "modify", MUST possess a 'jid' attribute that specifies the JabberID of the item to be modified, MAY possess a 'name' attribute that specifies a natural-language name or nickname for the item, and MAY contain one or more <group/> elements specifying roster groups into which to place the item. If a &MESSAGE; stanza is sent, it MAY contain a &BODY; element but SHOULD NOT contain any other child elements. Here is an example:

    @@ -188,7 +188,7 @@
  • If the item exists in the roster and the modification results in adding the item to a new group in addition to its existing group, the receiving application MAY prompt the user for approval and SHOULD add the item to the specified group.
  • If the item exists in the roster and the modification results in a change of name only, the receiving application MAY prompt the user for approval and SHOULD modify the name to that specified in the modification suggestion.
    • -

    If a roster item addition, deletion, or modification stanza will result in editing of an existing item in the roster, the receiving application MUST (either with approval by a human user or automatically subject to configuration) send a roster set to the user's server with no changes to the 'subscription' attribute but rather with appropriate changes to the value of 'name' attribute or the <group/> child element or elements, as described in RFC 3921.

    +

    If a roster item addition, deletion, or modification stanza will result in editing of an existing item in the roster, the receiving application MUST (either with approval by a human user or automatically subject to configuration) send a roster set to the user's server with no changes to the 'subscription' attribute but rather with appropriate changes to the value of 'name' attribute or the <group/> child element or elements, as described in &rfc3921;.

         diff --git a/xep-0145.xml b/xep-0145.xml index f3d31dfc..f9078841 100644 --- a/xep-0145.xml +++ b/xep-0145.xml @@ -87,7 +87,7 @@

    Note: All notes are stored as a "bundle" within the same <storage/> element.

    -

    Retrieving notes uses the protocol described in XEP-0049.

    +

    Retrieving notes uses the protocol described in &xep0049;.

    ]]> -

    For error conditions please refer to XEP-0049.

    +

    For error conditions please refer to &xep0049;.

     -

    Security considerations related to private XML storage are described in XEP-0049.

    +

    Security considerations related to private XML storage are described in &xep0049;.

     diff --git a/xep-0147.xml b/xep-0147.xml index 941cca44..d51eb85a 100644 --- a/xep-0147.xml +++ b/xep-0147.xml @@ -86,8 +86,8 @@ -

    &rfc5122; defines a Uniform Resource Identifier (URI) scheme for use in forming URIs and Internationalized Resource Identifiers (IRIs) On the difference between IRIs and URIs, see RFC 3987. from the addresses of entities that can communicate using the Extensible Messaging and Presence Protocol (see &xmppcore;). Such identifiers enable identification of and interaction with XMPP entities by non-native applications such as databases and web browsers.

    -

    However, RFC 5122 intentionally leaves the potential values of the query component open-ended, does not provide a list of common "actions" for queries (e.g., send message or join chatroom), and does not specify recommended "key-value" pairs to be used in the context of such actions. Therefore, this document defines a registry of such actions and key-value pairs (to be maintained by the ®ISTRAR;) and specifies a set of initial values for that registry.

    +

    &rfc5122; defines a Uniform Resource Identifier (URI) scheme for use in forming URIs and Internationalized Resource Identifiers (IRIs) On the difference between IRIs and URIs, see &rfc3987;. from the addresses of entities that can communicate using the Extensible Messaging and Presence Protocol (see &xmppcore;). Such identifiers enable identification of and interaction with XMPP entities by non-native applications such as databases and web browsers.

    +

    However, &rfc5122; intentionally leaves the potential values of the query component open-ended, does not provide a list of common "actions" for queries (e.g., send message or join chatroom), and does not specify recommended "key-value" pairs to be used in the context of such actions. Therefore, this document defines a registry of such actions and key-value pairs (to be maintained by the ®ISTRAR;) and specifies a set of initial values for that registry.

    This document is organized as follows:

    • The registry is defined in the XMPP IRI/URI Querytype Registry section.
      • @@ -95,10 +95,10 @@
    • A corresponding initial submission to the registry is specified in the Initial Registration section.
    • The process for submitting additional values to the registry is specified in the Registration Process section.
    -

    Note: The format of the XMPP URI scheme, including the format of the query component, is fully specified and formally defined in RFC 5122; this document does not modify the xmpp URI scheme in any way and assumes that the reader is familiar with all aspects of RFC 5122.

    +

    Note: The format of the XMPP URI scheme, including the format of the query component, is fully specified and formally defined in &rfc5122;; this document does not modify the xmpp URI scheme in any way and assumes that the reader is familiar with all aspects of RFC 5122.

     -

    This document inherits terminology from &rfc3986;, &rfc3987;, and RFC 5122.

    +

    This document inherits terminology from &rfc3986;, &rfc3987;, and &rfc5122;.

    The range of actions that might be triggered by interaction with an XMPP entity by means of an XMPP IRI/URI is potentially as wide as the range of extensions to XMPP. This document does not seek to exhaustively define all such potential actions. However, the following actions might be of general interest:

    @@ -114,8 +114,8 @@
  • Registering with another entity via &xep0077;.
  • Initiating a file transfer with another entity (see &xep0096;).
    • -

    For each such action, the XMPP Registrar maintains a RECOMMENDED "querytype" (this can be thought of as an action name or "verb"; see RFC 5122 for syntax and semantics) as well as an OPTIONAL list of keys to be used in key-value pairs if appropriate.

    -

    The querytypes and key-value pairs related to RFC 3920 and RFC 3921 are defined herein; the querytypes and key-value pairs related to protocols defined in the XMPP Standards Foundation's XEP series are defined in the relevant XMPP Extension Protocol specifications.

    +

    For each such action, the XMPP Registrar maintains a RECOMMENDED "querytype" (this can be thought of as an action name or "verb"; see &rfc5122; for syntax and semantics) as well as an OPTIONAL list of keys to be used in key-value pairs if appropriate.

    +

    The querytypes and key-value pairs related to &rfc3920; and RFC 3921 are defined herein; the querytypes and key-value pairs related to protocols defined in the XMPP Standards Foundation's XEP series are defined in the relevant XMPP Extension Protocol specifications.

    It may desirable for an XMPP IRI/URI to trigger a specialized interface for sending an XMPP message stanza. The RECOMMENDED querytype for this action is "message". If no key-value pair is provided, interacting with an XMPP IRI/URI that contains a querytype of "message" SHOULD trigger an interface that enables the user to input the text of an XMPP message and other relevant parameters (e.g., a message subject or &xep0071; markup).

     -

    The 'jabber:iq:roster' namespace provides a mechanism for managing an XMPP roster (also called a "contact list"). This namespace is defined in RFC 3921. The following actions are defined.

    +

    The 'jabber:iq:roster' namespace provides a mechanism for managing an XMPP roster (also called a "contact list"). This namespace is defined in &rfc3921;. The following actions are defined.

    The registered querytype for adding items to the roster or editing items in the roster is "roster" (effectively there is no difference between adding and editing). An XMPP IRI/URI containing a "roster" querytype MAY also include at most one "name" key whose value maps to the 'name' attribute of the <item/> element within the 'jabber:iq:roster' namespace, and MAY contain one "group" key whose value maps to the character data of the <group/> child element of <item/>.

     -

    Closely coupled with roster management is presence subscription management. In XMPP, subscription management is handled via special values of the &PRESENCE; stanza, as described in RFC 3921. The following actions are defined

    +

    Closely coupled with roster management is presence subscription management. In XMPP, subscription management is handled via special values of the &PRESENCE; stanza, as described in &rfc3921;. The following actions are defined

    -

    When an entity subscribes to another entity's presence by means of an XMPP IRI/URI, the invoked XMPP application SHOULD first send a roster add stanza as shown below (this is consistent with the recommendations in RFC 3921).

    +

    When an entity subscribes to another entity's presence by means of an XMPP IRI/URI, the invoked XMPP application SHOULD first send a roster add stanza as shown below (this is consistent with the recommendations in &rfc3921;).

    @@ -225,11 +225,11 @@ xmpp:romeo@montague.net?unsubscribe     -

    Internationalization considerations for XMPP IRIs/URIs are specified in RFC 5122; the reader is referred to that document for a complete discussion of the relevant issues.

    +

    Internationalization considerations for XMPP IRIs/URIs are specified in &rfc5122;; the reader is referred to that document for a complete discussion of the relevant issues.

    Localization of application-specific data presented to a human user (e.g., as encapsulated in key-value pairs) is the responsibility of the "using protocol".

     -

    Security considerations for XMPP IRIs/URIs are specified in RFC 5122.

    +

    Security considerations for XMPP IRIs/URIs are specified in &rfc5122;.

    Completion of some of the actions defined herein will cause changes to an entity's account, subscriptions to information, registration with services, communication with other entities, completion of ad-hoc commands, and the like. Naturally, such changes, information, services, and communications are potentially undesirable (e.g., joining a chatroom whose discussion topic is not of interest to, or even patently offensive to, the joining user). The invoked application SHOULD appropriately warn a human user regarding the potential consequences of the action about to be completed.

     diff --git a/xep-0149.xml b/xep-0149.xml index 057a9377..dc3a38d2 100644 --- a/xep-0149.xml +++ b/xep-0149.xml @@ -67,7 +67,7 @@

    In order to specify the time period for a state, event, or activity, the generating entity SHOULD include both "Start" and "Stop" SHIM headers that specify the dateTimes at which the time period starts and stops. The following rules apply:

      -
    1. All start and stop dates MUST conform to the dateTime profile specified in XEP-0082.
      2. +
    2. All start and stop dates MUST conform to the dateTime profile specified in &xep0082;.
    3. All dateTime information MUST be expressed in UTC (i.e., with no timezone offsets).
    4. Start and stop times SHOULD be understood by the recipient as estimates or approximations.
    5. If both a start time and a stop time are specified, the stop time MUST be later than the start time.
      6. @@ -89,7 +89,7 @@ ]]> -

      An XMPP extension for user activity is specified in XEP-0108. It may be desirable to include time period information when publishing one's activity.

      +

      An XMPP extension for user activity is specified in &xep0108;. It may be desirable to include time period information when publishing one's activity.

       -

      An XMPP extension for user mood is specified in XEP-0107. It may be desirable to include time period information when publishing one's mood.

      +

      An XMPP extension for user mood is specified in &xep0107;. It may be desirable to include time period information when publishing one's mood.

      -

      In HTTP, an "entity" is the information transferred as the payload of a request or response, and an "Entity Tag" is an opaque string that uniquely identifies that payload. For example, when an HTTP server sends an entity in an HTTP response, it can include an ETag header that identifies the payload as cacheable, and the client can cache that entity; in future requests, the client can include the same value in an If-None-Match header and the server will either return an HTTP 304 ("Not Modified") error if the entity has not changed or return the entity in the HTTP response if it has changed. (Note: For information about the semantics of Entity Tags, the ETag header, and the If-None-Match header, refer to Sections 3.11, 14.19, and 14.26 respectively of RFC 2616.)

      -

      The basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP (although we use the term "data object" to refer to the payload); this is made possible by a straightforward application of SHIM headers as specified in XEP-0131. In the context of an IQ request-response interaction, the responding entity will include an ETag SHIM header in its IQ response (indicating that the data object can be cached), the requesting entity will include that identical value in an If-None-Match SHIM header when it queries the server for the same data object, and the responding entity will return either an IQ result with the changed data object or an IQ error indicating that the data object has not changed.

      +

      In HTTP, an "entity" is the information transferred as the payload of a request or response, and an "Entity Tag" is an opaque string that uniquely identifies that payload. For example, when an HTTP server sends an entity in an HTTP response, it can include an ETag header that identifies the payload as cacheable, and the client can cache that entity; in future requests, the client can include the same value in an If-None-Match header and the server will either return an HTTP 304 ("Not Modified") error if the entity has not changed or return the entity in the HTTP response if it has changed. (Note: For information about the semantics of Entity Tags, the ETag header, and the If-None-Match header, refer to Sections 3.11, 14.19, and 14.26 respectively of &rfc2616;.)

      +

      The basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP (although we use the term "data object" to refer to the payload); this is made possible by a straightforward application of SHIM headers as specified in &xep0131;. In the context of an IQ request-response interaction, the responding entity will include an ETag SHIM header in its IQ response (indicating that the data object can be cached), the requesting entity will include that identical value in an If-None-Match SHIM header when it queries the server for the same data object, and the responding entity will return either an IQ result with the changed data object or an IQ error indicating that the data object has not changed.

      Here is an example of such a request-response flow (the example is that of roster retrieval):

      ]]>

      Note: The <not-modified/> error condition is not specified as a stanza error condition in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &xep0086;). However, the <not-modified/> error condition is included in &xmppcore;.

      -

      Note: In HTTP, an Entity Tag may be either "strong" or "weak" (see Section 13.3.3 of RFC 2616); Entity Tags as used in XMPP extensions MUST be considered strong rather than weak.

      +

      Note: In HTTP, an Entity Tag may be either "strong" or "weak" (see Section 13.3.3 of &rfc2616;); Entity Tags as used in XMPP extensions MUST be considered strong rather than weak.

      Note: The ETag and If-None-Match headers SHOULD be used only in &IQ; stanzas, although they MAY be used in &MESSAGE; stanza interactions if IQ request-response semantics are not appropriate, for example in &xep0072; and in certain applications that use &xep0004;.

       -

      As specified in &xmppim;, an XMPP instant messaging client will typically store its "roster" (contact list) on the server so that any connecting client for that account can retrieve the roster at will. Since RFC 6121 defines no upper limit on the number of items allowed in the roster, it is possible for a roster to become quite large (e.g., there are known cases of rosters with more than 1,000 items). Therefore a server may support Entity Tag functionality with regard to roster management. The process is as follows.

      +

      As specified in &xmppim;, an XMPP instant messaging client will typically store its "roster" (contact list) on the server so that any connecting client for that account can retrieve the roster at will. Since &rfc6121; defines no upper limit on the number of items allowed in the roster, it is possible for a roster to become quite large (e.g., there are known cases of rosters with more than 1,000 items). Therefore a server may support Entity Tag functionality with regard to roster management. The process is as follows.

      First, the client requests its roster:

       -

      XEP-0131 specifies how support for a particular SHIM header can be explicitly determined using &xep0030;. To review, the protocol flow between a client and a server is as follows:

      +

      &xep0131; specifies how support for a particular SHIM header can be explicitly determined using &xep0030;. To review, the protocol flow between a client and a server is as follows:

      -

      To publish reachability addresses via the personal eventing protocol (XEP-0163), the entity publishes data to the "urn:xmpp:reach:0" node.

      +

      To publish reachability addresses via the personal eventing protocol (&xep0163;), the entity publishes data to the "urn:xmpp:reach:0" node.

      The user's server then broadcasts that presence information to all contacts who are subscribed to the user's presence information.

       -

      When the recipient's client receives the hash of the avatar image, it SHOULD check the hash to determine if it already has a cached copy of that avatar image. If not, it retrieves the sender's full vCard in accordance with the protocol flow described in XEP-0054 (note that this request is sent to the user's bare JID, not full JID):

      +

      When the recipient's client receives the hash of the avatar image, it SHOULD check the hash to determine if it already has a cached copy of that avatar image. If not, it retrieves the sender's full vCard in accordance with the protocol flow described in &xep0054; (note that this request is sent to the user's bare JID, not full JID):

      -

      It is widely acknowledged within the Jabber/XMPP community that the &xep0054; specification (XEP-0054) has outlived its usefulness. There are several reasons for this conclusion:

      +

      It is widely acknowledged within the Jabber/XMPP community that the &xep0054; specification (&xep0054;) has outlived its usefulness. There are several reasons for this conclusion:

        -
      1. XEP-0054 is not fully consistent with the Internet-Draft on which it was based.
        2. +
      2. &xep0054; is not fully consistent with the Internet-Draft on which it was based.
      3. The Internet-Draft on which it was based was never approved by the IETF.
      4. Because of confusion over aspects of the vcard-temp specification, there exist incompatible implementations.
      5. vCard (&rfc2426;) captures only a limited set of information.
        6. -
      6. vCard (even in its XML representation For links to the experimental XML representation of vCard, see XEP-0054.) is not easily extensible, leading those who develop profiles for specialized communities to "roll their own" protocols, to the detriment of interoperability.
        7. +
      7. vCard (even in its XML representation For links to the experimental XML representation of vCard, see &xep0054;.) is not easily extensible, leading those who develop profiles for specialized communities to "roll their own" protocols, to the detriment of interoperability.
      8. vCard data tends to be monolithic (the basic unit of information is the full vCard, not parts thereof).
      9. The publication model for XEP-0054 is to set the full vCard, rather than only the parts that need to be modified.
      10. The retrieval model for XEP-0054 is to get the full vCard, rather than only the parts that have been modified.
        11. @@ -140,7 +140,7 @@

      11. Pubsub (publish-and-subscribe) semantics.

        -

        A more complex model is for an entity to publish its profile data to a publish-subscribe node or nodes and allow other entities to subscribe to that node or nodes, thus receiving notifications whenever the profiled entity updates its data. This model is more appropriate for entities that modify their profile data on a regular basis or when other entities wish to be informed when the profile data changes. Because this model will most likely be used most often by IM users and other intermittently-connected network endpoints, we use the simplified subset of the XMPP publish-subscribe extension defined in XEP-0163 to implement this model.

        +

        A more complex model is for an entity to publish its profile data to a publish-subscribe node or nodes and allow other entities to subscribe to that node or nodes, thus receiving notifications whenever the profiled entity updates its data. This model is more appropriate for entities that modify their profile data on a regular basis or when other entities wish to be informed when the profile data changes. Because this model will most likely be used most often by IM users and other intermittently-connected network endpoints, we use the simplified subset of the XMPP publish-subscribe extension defined in &xep0163; to implement this model.

       @@ -172,14 +172,14 @@
    6. It can be parsed using an off-the-shelf XML parser.
    7. It is already widely deployed in existing Jabber/XMPP clients, servers, and components.
    8. The data forms protocol is easily extensible.
      9. -
    9. The Jabber/XMPP community possesses consistent methods for profiling and scoping data forms (as specified in XEP-0068).
      10. +
    10. The Jabber/XMPP community possesses consistent methods for profiling and scoping data forms (as specified in &xep0068;).
    11. Data forms have a generic schema that is easy to map to common data storage mechanisms (usually databases).
    12. Data forms provide a consistent abstraction layer for XMPP applications, thus shielding them from changes in the profile data formats being defined by other Internet projects and standards development organizations.
    13. The use of data forms as the medium of representation for communication over the wire does not prevent applications from storing backend profile data in some other underlying format (e.g., RDF or a database).
    -

    Therefore, this proposal specifies that profile data shall be represented in data forms scoped by a FORM_TYPE of 'urn:xmpp:tmp:profile' &NSNOTE;, in accordance with the field standardization methods defined in XEP-0068. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (although they may or may not be defined in a XMPP Extension Protocol specification). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of XEP-0068. Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.

    +

    Therefore, this proposal specifies that profile data shall be represented in data forms scoped by a FORM_TYPE of 'urn:xmpp:tmp:profile' &NSNOTE;, in accordance with the field standardization methods defined in &xep0068;. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (although they may or may not be defined in a XMPP Extension Protocol specification). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of XEP-0068. Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.

    The following is a simple and incomplete example of profile data represented via the Data Forms protocol, containing two registered data fields and one unregistered field:

    @@ -201,7 +201,7 @@ ]]>

    By specifying that all fields are scoped by a FORM_TYPE of 'urn:xmpp:tmp:profile', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'urn:xmpp:tmp:profile' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.

    -

    However, scoping all data fields with a single FORM_TYPE implies it is necessary to define separate data fields for similar kinds of information. For example, the vCard specification (RFC 2426) defines "types" for certains kinds of data, such as email addresses, telephone numbers, and physical addresses, making it possible to specify that a telephone number corresponds to a fax machine or mobile phone or that a physical address corresponds to one's home or work location. In the Data Forms representation, any desired piece of information (e.g., work phone) must be represented with a separate data field.

    +

    However, scoping all data fields with a single FORM_TYPE implies it is necessary to define separate data fields for similar kinds of information. For example, the vCard specification (&rfc2426;) defines "types" for certains kinds of data, such as email addresses, telephone numbers, and physical addresses, making it possible to specify that a telephone number corresponds to a fax machine or mobile phone or that a physical address corresponds to one's home or work location. In the Data Forms representation, any desired piece of information (e.g., work phone) must be represented with a separate data field.

    In order to address most (if not all) of the pieces of information described in existing profile specifications, this document defines a great number of data fields. Even so, the data fields specified herein are not exhaustive, and it is expected that additional fields will be registered in the future through the mechanisms specified in the XMPP Registrar Considerations section of this document.

     @@ -238,7 +238,7 @@

    Otherwise it MUST return an error. If the server does not support the profile data functionality, the error MUST be &unavailable;.

    -

    In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "urn:xmpp:tmp:profile" at its server using the PEP subset of the publish-subscribe extension, as specified in XEP-0163.

    +

    In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "urn:xmpp:tmp:profile" at its server using the PEP subset of the publish-subscribe extension, as specified in &xep0163;.

    @@ -427,7 +427,7 @@ ]]>     -

    In order to receive updated fields for a contact's profile, an entity shall encapsulate a feature of "urn:xmpp:tmp:profile+notify" in its &xep0115; data. If the contact's server supports the personal eventing profile of XMPP Publish-Subscribe as described in XEP-0163, the entity will receive notifications whenever the contact sends updated profile fields to the profile node:

    +

    In order to receive updated fields for a contact's profile, an entity shall encapsulate a feature of "urn:xmpp:tmp:profile+notify" in its &xep0115; data. If the contact's server supports the personal eventing profile of XMPP Publish-Subscribe as described in &xep0163;, the entity will receive notifications whenever the contact sends updated profile fields to the profile node:

    @@ -1543,7 +1543,7 @@

    Everyone knows at least one language well (e.g., they are able to speak or write the language with a fair degree of fluency). Determination of whether someone knows a language "well" or "fluently" is left to the user.

    -

    The value of this field MUST be an abbreviation for a language as specified in RFC 4646.

    +

    The value of this field MUST be an abbreviation for a language as specified in &rfc4646;.

    The Data Forms field that represents a language known well is "languages_well".

    This field maps to:

      diff --git a/xep-0155.xml b/xep-0155.xml index d670df7a..c5f1623f 100644 --- a/xep-0155.xml +++ b/xep-0155.xml @@ -145,7 +145,7 @@
      • Whenever parameters specific to a stanza session must be agreed. e.g., security and privacy parameters (see &xep0116; and &xep0136;).
      • The parties are unknown to each other, have not exchanged presence, or have not discovered their respective capabilities via &xep0030; or &xep0115;.
        • -
      • When an XMPP-based system interfaces with a SIP-based system built on top of &rfc3261;. In essence, a stanza session negotiation request as specified herein is functionally equivalent to a SIP INVITE request, and acceptance of such a request is functionally equivalent to sending a SIP 200 OK response; see Section 17 of RFC 3261.
        • +
      • When an XMPP-based system interfaces with a SIP-based system built on top of &rfc3261;. In essence, a stanza session negotiation request as specified herein is functionally equivalent to a SIP INVITE request, and acceptance of such a request is functionally equivalent to sending a SIP 200 OK response; see Section 17 of &rfc3261;.
      • Within an organization or culture in which one would not simply begin interacting with another person (e.g., a superior) without first receiving permission to do so.

      This proposal defines best practices for such a negotiation, re-using the protocol defined in &xep0020;.

      @@ -669,7 +669,7 @@ PENDING o---------------+

      If a party receives an XMPP presence stanza of type "unavailable" from the full JID &LOCALFULL; of the other party (i.e., the resource with which it has had an active session) during a session, the receiving party SHOULD assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated session until it reconnects and receives "offline" messages).

      -

      However, the receiving party MAY assume that the other client will not be able to continue the session. In general, if a party is not subscribing to the other party's presence then it will never assume the other party is is unable to continue a session. In that case it MUST explicitly terminate the session (see Terminating a Session) -- since its assumption could be incorrect. If after terminating the session the receiving party later receives available presence (i.e., a &PRESENCE; stanza with no 'type' attribute) from that same resource or another resource associated with the other party and the receiving party desires to restart the session, then it MUST initiate a new session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in XEP-0085.)

      +

      However, the receiving party MAY assume that the other client will not be able to continue the session. In general, if a party is not subscribing to the other party's presence then it will never assume the other party is is unable to continue a session. In that case it MUST explicitly terminate the session (see Terminating a Session) -- since its assumption could be incorrect. If after terminating the session the receiving party later receives available presence (i.e., a &PRESENCE; stanza with no 'type' attribute) from that same resource or another resource associated with the other party and the receiving party desires to restart the session, then it MUST initiate a new session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in &xep0085;.)

      When mapping instant messaging flows to SIP, implementations SHOULD adhere to &rfc7572;.

      @@ -684,7 +684,7 @@ PENDING o---------------+ -

      If a contact does not share its presence information with a user through a presence subscription (see RFC 3921) or if it blocks outbound presence notifications to the user (see &xep0016;), then it will effectively expose its presence if it accepts the user's stanza session negotiation request or returns an error to the user. Therefore, due care must be exercised in determining whether to accept the request or return an error. The contact's client SHOULD NOT automatically (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribed to the contact's presence and the contact is not blocking outbound presence notifications to the user. Note: There should be no need for the contact's client to consult the contact's block list (see &xep0191;), since if the user is on the block list then the contact would not receive the request from the user in the first place.

      +

      If a contact does not share its presence information with a user through a presence subscription (see &rfc3921;) or if it blocks outbound presence notifications to the user (see &xep0016;), then it will effectively expose its presence if it accepts the user's stanza session negotiation request or returns an error to the user. Therefore, due care must be exercised in determining whether to accept the request or return an error. The contact's client SHOULD NOT automatically (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribed to the contact's presence and the contact is not blocking outbound presence notifications to the user. Note: There should be no need for the contact's client to consult the contact's block list (see &xep0191;), since if the user is on the block list then the contact would not receive the request from the user in the first place.

      If a client is configured to show a request <form/> to a human user instead of responding automatically, it SHOULD replace the content of the <title/> element and of all label attributes of the known and registered <field/> and <option/> elements with its own localised versions before showing the form to the user -- even if the form already appears to be in the correct language.

      diff --git a/xep-0156.xml b/xep-0156.xml index 7c533fc8..d887c5e1 100644 --- a/xep-0156.xml +++ b/xep-0156.xml @@ -181,14 +181,14 @@
      1. host-meta files MUST be fetched only over HTTPS, and MUST only use connection URLs starting with 'https://' or 'wss://'. This provides secure delegation, meaning you SHOULD send SNI matching the host of the URL from the connection URL and validate that the certificate is valid for that host *or* the XMPP domain.
      2. Services implementing this XEP MUST offer the information in the Extensible Resource Descriptor (XRD) format and SHOULD additionally provide the JRD format (both formats are specified in &rfc6415;).
        3. -
      3. HTTPS queries for host-meta information MUST be used only as a fallback after the methods specified in RFC 6120 have been exhausted.
        4. -
      4. A domain SHOULD NOT present information in host-meta link records that is available via the DNS SRV records defined in RFC 6120.
        5. +
      5. HTTPS queries for host-meta information MUST be used only as a fallback after the methods specified in &rfc6120; have been exhausted.
        6. +
      6. A domain SHOULD NOT present information in host-meta link records that is available via the DNS SRV records defined in &rfc6120;.
      7. The order of XMPP related link entries in the host-meta file SHOULD NOT be interpreted as significant by the presenting domain or the receiving entity.
       -

      The following examples show two host-meta link records: the first indicates support for the XMPP Over BOSH connection method defined in XEP-0124 and XEP-0206 and the second indicates support for the XMPP Over WebSocket connection method defined in &rfc7395;.

      +

      The following examples show two host-meta link records: the first indicates support for the XMPP Over BOSH connection method defined in &xep0124; and XEP-0206 and the second indicates support for the XMPP Over WebSocket connection method defined in &rfc7395;.

      ... diff --git a/xep-0157.xml b/xep-0157.xml index 7e2e1e3c..0b73aa41 100644 --- a/xep-0157.xml +++ b/xep-0157.xml @@ -105,12 +105,12 @@

      &rfc2142; specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as security@domain.tld, usenet@domain.tld, and abuse@domain.tld). However, no such conventional email address or XMPP address has been specified for XMPP services (e.g., in &rfc3920;). This document remedies that oversight, and the email recommendation specified here has been incorporated into &rfc6120;.

       -

      Consistent with RFC 2142, a domain that offers a Jabber/XMPP service SHOULD provide an Internet mailbox of "XMPP" for inquiries related to that service.

      +

      Consistent with &rfc2142;, a domain that offers a Jabber/XMPP service SHOULD provide an Internet mailbox of "XMPP" for inquiries related to that service.

      The administrators of an XMPP service may desire to advertise contact information related to that service. Many existing Jabber/XMPP server implementations use the bare domain &DOMAINBARE; of the server (e.g., "example.org") as an alias for the server administrators, such that a &MESSAGE; stanza addressed to that domain name is delivered to the JIDs of the server administrators. (Currently, this functionality does not apply to &IQ; or &PRESENCE; stanzas.) Unfortunately, using the "domain.tld" address as a way to direct messages to the server administrators may result in overloading of the bare domain address (i.e., it may be desirable to send messages to the server's address without having those messages delivered to the server admins, for example if the server doubles as a &xep0060; service). Therefore, it is instead RECOMMENDED to support service discovery of contact addresses as specified herein. - This contact information may include email addresses, web URLs, and JabberIDs for specific roles and functions such as the service administrators, abuse reports, customer feedback, sales inquiries, technical support, and security concerns. For this purpose, domains SHOULD support the electronic mailboxes required by RFC 2142. However, additional contact mechanisms may be desirable, and it would be helpful if those who want to initiate contact could discover the contact information using standard XMPP extensions, specifically &xep0030;. To make such discovery possible, we specify a &xep0128; mechanism that a server SHOULD return in response to service discovery information ("disco#info") requests sent to the bare domain of the server. This information MUST be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as already specified in XEP-0128) and data form fields registered for this purpose as defined in the XMPP Registrar Considerations section of this document.

      + This contact information may include email addresses, web URLs, and JabberIDs for specific roles and functions such as the service administrators, abuse reports, customer feedback, sales inquiries, technical support, and security concerns. For this purpose, domains SHOULD support the electronic mailboxes required by &rfc2142;. However, additional contact mechanisms may be desirable, and it would be helpful if those who want to initiate contact could discover the contact information using standard XMPP extensions, specifically &xep0030;. To make such discovery possible, we specify a &xep0128; mechanism that a server SHOULD return in response to service discovery information ("disco#info") requests sent to the bare domain of the server. This information MUST be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as already specified in &xep0128;) and data form fields registered for this purpose as defined in the XMPP Registrar Considerations section of this document.

      Values of 'status-addresses' form field MUST be valid URIs, i.e. comply with the 'xs:anyURI' datatype of &w3xmlschema2;. Values of the 'abuse-addresses', @@ -184,7 +184,7 @@

      The ®ISTRAR; includes the following information in its registries.

      -

      &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and XEP-0128 describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "http://jabber.org/network/serverinfo" FORM_TYPE.

      +

      &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and &xep0128; describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "http://jabber.org/network/serverinfo" FORM_TYPE.

      http://jabber.org/network/serverinfo diff --git a/xep-0158.xml b/xep-0158.xml index a7812f69..6c8cfdaf 100644 --- a/xep-0158.xml +++ b/xep-0158.xml @@ -399,8 +399,8 @@       -

      This section shows how challenges SHOULD be combined with the existing In-Band Registration protocol according to the rules defined in the Extensibility section of XEP-0077.

      -

      Note: The <challenge/> wrapper element is not included, because XEP-0077 specifies that data forms shall be contained as the direct children of the &QUERY; element.

      +

      This section shows how challenges SHOULD be combined with the existing In-Band Registration protocol according to the rules defined in the Extensibility section of &xep0077;.

      +

      Note: The <challenge/> wrapper element is not included, because &xep0077; specifies that data forms shall be contained as the direct children of the &QUERY; element.

      @@ -464,7 +464,7 @@       -

      A service that hosts multi-user chat rooms in accordance with XEP-0045 MAY challenge unknown entities that seek to join such rooms or that send messages in such rooms.

      +

      A service that hosts multi-user chat rooms in accordance with &xep0045; MAY challenge unknown entities that seek to join such rooms or that send messages in such rooms.

      @@ -688,7 +688,7 @@       -

      It is RECOMMENDED that entities employ other techniques to combat abusive stanzas in addition to those described in this document (e.g., see XEP-0161 and &xep0205;).

      +

      It is RECOMMENDED that entities employ other techniques to combat abusive stanzas in addition to those described in this document (e.g., see &xep0161; and &xep0205;).

      It is expected that this protocol will be an important and successful tool for discouraging abusive traffic. However, much of its success is dependent on the quality of the CAPTCHAs and other puzzles employed by a particular implementation.

      The administrator of an application that functions as a challenger SHOULD discontinue the use of CAPTCHA forms under the following circumstances:

        @@ -703,7 +703,7 @@ -

        The use of CAPTCHAs is not a panacea, and should be combined with other anti-abuse mechanisms, such as those described in XEP-0161 and XEP-0205. For example, the task of finding solutions to CAPTCHAs and other computational puzzles is becoming easier for computer programs, and in any case can be farmed out to third parties. Therefore challengers should limit the number of triggering stanzas (e.g., registration attempts, subscription requests, or chatroom joins) allowed per JabberID or IP address during any given time period, and may simply refuse repeated stanzas by terminating an XML stream with a &policy; stream error or returning a ¬acceptable; stanza error as appropriate. In addition, a challenger should feel free to deploy additional anti-abuse mechanisms as needed.

        +

        The use of CAPTCHAs is not a panacea, and should be combined with other anti-abuse mechanisms, such as those described in &xep0161; and XEP-0205. For example, the task of finding solutions to CAPTCHAs and other computational puzzles is becoming easier for computer programs, and in any case can be farmed out to third parties. Therefore challengers should limit the number of triggering stanzas (e.g., registration attempts, subscription requests, or chatroom joins) allowed per JabberID or IP address during any given time period, and may simply refuse repeated stanzas by terminating an XML stream with a &policy; stream error or returning a ¬acceptable; stanza error as appropriate. In addition, a challenger should feel free to deploy additional anti-abuse mechanisms as needed.

         diff --git a/xep-0159.xml b/xep-0159.xml index c01ee925..6fa7ac60 100644 --- a/xep-0159.xml +++ b/xep-0159.xml @@ -83,8 +83,8 @@
      -

      The stanza blocking protocol defined in XEP-0016 enables a client to control explicitly which senders its server must block stanzas from. Such explicit blocking is suitable for privacy control, but not for filtering spim.

      -

      This document contradicts an assumption expressed in the standard blocking protocol in order to extend client control to spim blocking. More specifically, it simply defines a spim recognition privacy-list fall-through action that is different from the 'allow' default assumed in XEP-0016. The language used in XEP-0016 appears to be deliberately vague (informative rather than normative) in order to permit other default fall-through actions. The protocol defined in this document is therefore (arguably) compatible with XEP-0016.

      +

      The stanza blocking protocol defined in &xep0016; enables a client to control explicitly which senders its server must block stanzas from. Such explicit blocking is suitable for privacy control, but not for filtering spim.

      +

      This document contradicts an assumption expressed in the standard blocking protocol in order to extend client control to spim blocking. More specifically, it simply defines a spim recognition privacy-list fall-through action that is different from the 'allow' default assumed in &xep0016;. The language used in XEP-0016 appears to be deliberately vague (informative rather than normative) in order to permit other default fall-through actions. The protocol defined in this document is therefore (arguably) compatible with XEP-0016.

      The various spim recognition procedures that may be employed by the server are beyond the scope of this document. No single measure can differentiate all spim perfectly. It is RECOMMENDED that servers implement a combination of complementary spim recognition techniques (and other anti-spim techniques Other examples of anti-spim policies and protocols include: requiring a user to pass a robot challenge before registering a new account, invite-only and/or out-of-band user account registration, providing a standard protocol for reporting spim to both the servers involved, server-to-server connection dialback, karma (client-to-server and server-to-server), legal agreements not to send spim during user account registration, and IP blocking.).

      @@ -116,7 +116,7 @@ -

      This section specifies server functionality not defined in XEP-0016. This document will not reach Draft status until Server-Based Privacy Rules has been modified to permit this functionality.

      +

      This section specifies server functionality not defined in &xep0016;. This document will not reach Draft status until Server-Based Privacy Rules has been modified to permit this functionality.

      A server that supports this protocol MAY maintain a separate If the server were to maintain a single unified list of the correspondents of all its users, then spimmers would only need to pass a single spim recognition test before being allowed to send spim to all the server's users. list of each user's correspondents. Each list contains all the bare JIDs the user has either sent a stanza to or received a stanza from (over the past few weeks or months).

      Note: When it blocks a stanza, the server MUST NOT add the 'from' attribute of the stanza to the correspondents list.

      @@ -143,7 +143,7 @@       -

      This informative section requires no client or server functionality beyond that defined in XEP-0016.

      +

      This informative section requires no client or server functionality beyond that defined in &xep0016;.

      The client SHOULD use the 'subscription' type to exclude all JIDs on the user's roster from spim blocking (see the items with order 20, 30 and 40 in the example below).

      @@ -194,12 +194,12 @@
      • simply send him a message, so her server adds him to her correspondents list
      • add his JID to her active privacy list with action='allow'
        • -
      • add him to her roster (either in a group whose stanzas are allowed in her active privacy list, or with a subscription type that is allowed The subscription type SHOULD never be 'none' because XEP-0016 specifies that, for the purposes of blocking, all JIDs not on the roster also have the subscription type 'none'.)
        • +
      • add him to her roster (either in a group whose stanzas are allowed in her active privacy list, or with a subscription type that is allowed The subscription type SHOULD never be 'none' because &xep0016; specifies that, for the purposes of blocking, all JIDs not on the roster also have the subscription type 'none'.)
       -

      If stanzas from a spim robot running on a zombie domain somehow manage to get past the server's spim recognition then the client MAY use the 'jid' type to block one or all JIDs from the domain. (XEP-0016 already enables this functionality.)

      +

      If stanzas from a spim robot running on a zombie domain somehow manage to get past the server's spim recognition then the client MAY use the 'jid' type to block one or all JIDs from the domain. (&xep0016; already enables this functionality.)

      diff --git a/xep-0160.xml b/xep-0160.xml index f47d0a28..dd19caca 100644 --- a/xep-0160.xml +++ b/xep-0160.xml @@ -55,13 +55,13 @@ -

      &xmppcore; and &xmppim; specify general rules for handling XML stanzas, but explicitly do not address how to handle message stanzas sent to recipients (e.g., IM users or other nodes) that are offline, except to say that a server MUST return a &unavailable; error if offline message storage or message forwarding is not enabled (see RFC 6121). This document fills the gap by specifying best practices for storage and delivery of so-called "offline messages".

      +

      &xmppcore; and &xmppim; specify general rules for handling XML stanzas, but explicitly do not address how to handle message stanzas sent to recipients (e.g., IM users or other nodes) that are offline, except to say that a server MUST return a &unavailable; error if offline message storage or message forwarding is not enabled (see &rfc6121;). This document fills the gap by specifying best practices for storage and delivery of so-called "offline messages".

      The RECOMMENDED process flow is as follows:

        -
      1. Sender generates XMPP message stanza This document does not discuss IQ or presence stanzas, handling of which is described in RFC 6120 and RFC 6121. for delivery to a recipient such as an IM user or other node, where the 'to' address is of the form <node@domain> or <node@domain/resource> (see RFC 6121 for rules regarding server handling of such XMPP message stanzas).
        2. -
      2. Recipient's server determines that the intended recipient has no available resources that have specified non-negative presence priority. As specified in RFC 6121, available resources that have specified a negative presence priority shall never receive message stanzas addressed to <node@domain>.
        3. +
      3. Sender generates XMPP message stanza This document does not discuss IQ or presence stanzas, handling of which is described in &rfc6120; and RFC 6121. for delivery to a recipient such as an IM user or other node, where the 'to' address is of the form <node@domain> or <node@domain/resource> (see RFC 6121 for rules regarding server handling of such XMPP message stanzas).
        4. +
      4. Recipient's server determines that the intended recipient has no available resources that have specified non-negative presence priority. As specified in &rfc6121;, available resources that have specified a negative presence priority shall never receive message stanzas addressed to <node@domain>.
      5. Recipient's server determines that if the server can store offline messages on behalf of the intended recipient; if not (e.g., because the recipient's offline message queue is full), the server returns a &unavailable; error to the sender.
      6. Recipient's server does not return a &unavailable; error but instead stores the message stanza for later delivery.
      7. When the recipient next sends non-negative available presence to the server, the server delivers the message to the resource that has sent that presence. (Alternatively, the server may support &xep0013;, although that functionality is not described herein.)
        8. @@ -100,7 +100,7 @@ ]]> -

        Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in RFC 6121):

        +

        Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in &rfc6121;):

        • normal -- Messages with a 'type' attribute whose value is "normal" (or messages with no 'type' attribute) SHOULD be stored offline.

        • chat -- Messages with a 'type' attribute whose value is "chat" SHOULD be stored offline, with the exception of messages that contain only &xep0085; content (such messages SHOULD NOT be stored offline).

          • @@ -129,7 +129,7 @@

          A message stored offline may not be readable by the recipient if the message was encrypted using a session-based encryption method such as &xep0116; or if the key used in object encryption is revoked after the message was sent but before it is read.

          In certain countries, offline storage of message stanzas may introduce legal requirements or privacy vulnerabilities that do not apply to messages that are delivered immediately and never stored on an intermediate server.

          -

          See XEP-0203 for security considerations regarding the inclusion and processing of delayed delivery notations.

          +

          See &xep0203; for security considerations regarding the inclusion and processing of delayed delivery notations.

          This document requires no interaction with &IANA;.

          diff --git a/xep-0163.xml b/xep-0163.xml index a4afddf4..b722ee1f 100644 --- a/xep-0163.xml +++ b/xep-0163.xml @@ -164,7 +164,7 @@

          Personal eventing provides a way for a Jabber/XMPP user to send updates or "events" to other users, who are typically contacts in the user's roster. An event can be anything that a user wants to make known to other people, such as those described in &xep0080;, &xep0107;, &xep0108;, and &xep0118;. While the XMPP &xep0060; extension ("pubsub") can be used to broadcast such events associated, the full pubsub protocol is often thought of as complicated and therefore has not been widely implemented. Instead, many "extended presence" formats are currently sent using the &PRESENCE; stanza type; unfortunately, this overloads presence, results in unnecessary presence traffic, and does not provide fine-grained control over access. The use of publish-subscribe rather than presence is therefore preferable. To make publish-subscribe functionality more accessible (especially to instant messaging and presence applications that conform to &xmppim;), this document defines a simplified subset of pubsub that can be followed by instant messaging client and server developers to more easily deploy personal eventing services across the Jabber/XMPP network. We label this subset "Personal Eventing Protocol" or PEP.

          -

          Note: Any use cases not described herein are described in XEP-0060. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in XEP-0060. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension. This document merely defines a "subset" or "profile" of XMPP publish-subscribe.

          +

          Note: Any use cases not described herein are described in &xep0060;. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in XEP-0060. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension. This document merely defines a "subset" or "profile" of XMPP publish-subscribe.

          This section provides a friendly introduction to personal eventing via pubsub (PEP).

          @@ -292,7 +292,7 @@ ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/> ]]> -

          Your server knows to send tune information to Romeo because when the server unpacks the value of the 'ver' attribute ("054H4A7280JuT6+IroVYxgCAjZo=") in accordance with XEP-0115, it discovers that Romeo's client advertises a service discovery feature of "http://jabber.org/protocol/tune+notify", where the "+notify" suffix indicates interest in receiving notifications of the node whose NodeID precedes the suffix (see XEP-0060 § 9.2). The server can verify this support if needed by sending a service discovery request to Romeo's full JID, where the response would be as follows:

          +

          Your server knows to send tune information to Romeo because when the server unpacks the value of the 'ver' attribute ("054H4A7280JuT6+IroVYxgCAjZo=") in accordance with &xep0115;, it discovers that Romeo's client advertises a service discovery feature of "http://jabber.org/protocol/tune+notify", where the "+notify" suffix indicates interest in receiving notifications of the node whose NodeID precedes the suffix (see XEP-0060 § 9.2). The server can verify this support if needed by sending a service discovery request to Romeo's full JID, where the response would be as follows:

          Each messaging and presence account simply is a virtual publish-subscribe service.
        • The default access model is "presence".
        • A contact's subscription to an account owner's personal eventing data is automatically created because the contact has an XMPP presence subscription (the "auto-subscribe" feature).
          • -
        • Services take account of subscriber presence in the generation of notifications. This works only if the subscription state is "both" (see RFC 3921).
          • +
        • Services take account of subscriber presence in the generation of notifications. This works only if the subscription state is "both" (see &rfc3921;).
        • A service automatically sends notifications to all of the account owner's connected resources (subject to notification filtering).

        These uses of presence simplify the task of developing compliant clients (cf. &xep0134;).

        @@ -351,7 +351,7 @@         -

        An account owner publishes an item to a node by following the protocol specified in XEP-0060:

        +

        An account owner publishes an item to a node by following the protocol specified in &xep0060;:

        @@ -369,8 +369,8 @@ ]]> -

        If the node does not already exist, the PEP service MUST create the node. This "auto-create" feature (defined in XEP-0060) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in XEP-0060 before attempting to publish an item.)

        -

        A PEP service SHOULD also support the "publish-options" feature defined in XEP-0060.

        +

        If the node does not already exist, the PEP service MUST create the node. This "auto-create" feature (defined in &xep0060;) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in XEP-0060 before attempting to publish an item.)

        +

        A PEP service SHOULD also support the "publish-options" feature defined in &xep0060;.

        If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the Receiving Event Notifications section of this document, as well as to any of the account owner's available resources.

        Note: PEP ties the receipt of PEP notifications to the subscriber's presence, but does not tie the generation of PEP notifications to the publisher's presence. If the publisher wishes to stop generating PEP events (or to generate an "empty" event as can be done for some PEP payloads) before ending its presence session, the publisher MUST direct its client to do so and MUST NOT depend on the PEP service to automatically "zero out" its PEP information when the PEP service receives unavailable presence from the publisher.

         @@ -378,15 +378,15 @@

        An entity shall receive event notifications if:

          -
        1. The node has an open access model and the entity has explicitly or implicitly subscribed to the node as explained in XEP-0060.
          2. -
        2. The entity shares presence with the account owner (see Presence Sharing), is authorized to receive events from the node in accordance with the node access model (see XEP-0060), and advertises an interest in the payload type (see Notification Filtering).
          3. +
        3. The node has an open access model and the entity has explicitly or implicitly subscribed to the node as explained in &xep0060;.
          4. +
        4. The entity shares presence with the account owner (see Presence Sharing), is authorized to receive events from the node in accordance with the node access model (see &xep0060;), and advertises an interest in the payload type (see Notification Filtering).
        5. The entity is the account owner itself, in which case the PEP service shall send notifications to all of the account owner's available resources (subject to notification filtering).
        -

        A PEP service MUST support the "auto-subscribe" feature defined in Section 9.1 of XEP-0060. This implies that when a user has an XMPP presence subscription to the account owner's presence, the user automatically also has the right to subscribe to any of the account owner's PEP nodes (if the access model is the default of "presence") and to retrieve items from such PEP nodes.

        +

        A PEP service MUST support the "auto-subscribe" feature defined in Section 9.1 of &xep0060;. This implies that when a user has an XMPP presence subscription to the account owner's presence, the user automatically also has the right to subscribe to any of the account owner's PEP nodes (if the access model is the default of "presence") and to retrieve items from such PEP nodes.

         -

        A PEP service MUST support the "filtered-notifications" feature defined in Section 9.2 of XEP-0060. This implies that when an automatic subscriber can specify which event payloads it wants to receive by including appropriate feature bundles in the XEP-0115 information it broadcasts.

        +

        A PEP service MUST support the "filtered-notifications" feature defined in Section 9.2 of &xep0060;. This implies that when an automatic subscriber can specify which event payloads it wants to receive by including appropriate feature bundles in the XEP-0115 information it broadcasts.

         @@ -400,19 +400,19 @@

        1. If an entity subscribed using a full JID &FULLJID; or a bare domain identifier &DOMAINBARE;, a PEP service MUST send one notification only, addressed to the subscribed JID.

          2. -

        2. If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID &LOCALBARE; of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with XEP-0115 data that indicates interest in the relevant data format.)

          3. -

        3. If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID &FULLJID; of each of the subscriber's available resources that have included XEP-0115 information indicating an interest in the data format.

          4. +

        4. If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID &LOCALBARE; of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with &xep0115; data that indicates interest in the relevant data format.)

          5. +

        5. If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID &FULLJID; of each of the subscriber's available resources that have included &xep0115; information indicating an interest in the data format.

        1. When an account owner publishes an item to a node, a PEP service MUST generate a notification and send it to all appropriate subscribers (where the number of notifications is determined by the foregoing rules).

          2. -

        2. When a PEP service receives initial presence By "initial presence" is meant a presence stanza with no 'type' attribute that the PEP service receives after the subscriber was previously unavailable; any subsequent presence stanza with no 'type' attribute that the PEP service receives after the initial presence notification but before the subscriber against goes offline MUST NOT trigger sending of a new pubsub notification. from a subscriber's resource including XEP-0115 information that indicates an interest in the data format, it MUST generate a notification containing at least the last published item for that node and send it to the newly-available resource; see below under Sending the Last Published Item.

          3. +

        3. When a PEP service receives initial presence By "initial presence" is meant a presence stanza with no 'type' attribute that the PEP service receives after the subscriber was previously unavailable; any subsequent presence stanza with no 'type' attribute that the PEP service receives after the initial presence notification but before the subscriber against goes offline MUST NOT trigger sending of a new pubsub notification. from a subscriber's resource including &xep0115; information that indicates an interest in the data format, it MUST generate a notification containing at least the last published item for that node and send it to the newly-available resource; see below under Sending the Last Published Item.

        4. As an exception to the foregoing MUST rules, a PEP service MUST NOT send notifications to a subscriber if the user has blocked the subscriber from receiving the kind of stanza used for notifications (typically message stanzas) by means of communications blocking as specified in &xep0016; or &xep0191;.

         -

        As mentioned, a PEP service MUST send the last published item to all new subscribers and to all newly-available resources for each subscriber, including the account owner itself. (That is, the default value of the "pubsub#send_last_published_item" node configuration field must be "on_sub_and_presence"; this behavior essentially mimics the functionality of presence as defined in XMPP IM.) When processing a new subscription, the service MAY send not only the last published item but instead all items that are currently associated with the node (i.e., up to the maximum number of items at the node, which might be one if the node is a "singleton node" as described in XEP-0060). If the service has knowledge about the datetime that a subscriber's newly-available resource last received updated information from the node (e.g., as described in &xep0256;), then it MAY also send more items than only the last published item to the newly-available resource.

        +

        As mentioned, a PEP service MUST send the last published item to all new subscribers and to all newly-available resources for each subscriber, including the account owner itself. (That is, the default value of the "pubsub#send_last_published_item" node configuration field must be "on_sub_and_presence"; this behavior essentially mimics the functionality of presence as defined in XMPP IM.) When processing a new subscription, the service MAY send not only the last published item but instead all items that are currently associated with the node (i.e., up to the maximum number of items at the node, which might be one if the node is a "singleton node" as described in &xep0060;). If the service has knowledge about the datetime that a subscriber's newly-available resource last received updated information from the node (e.g., as described in &xep0256;), then it MAY also send more items than only the last published item to the newly-available resource.

        Note: The "on_sub_and_presence" setting relates to the subscriber's presence, not the publisher's presence.

        @@ -458,7 +458,7 @@

        A PEP service MUST:

          -
        • Support the node discovery, node creation, node deletion, publish item, subscribe, unsubscribe, and item retrieval use cases specified in XEP-0060.
          • +
        • Support the node discovery, node creation, node deletion, publish item, subscribe, unsubscribe, and item retrieval use cases specified in &xep0060;.
        • Support the "auto-create", "auto-subscribe", and "filtered-notifications" features.
        • Support the "owner" and "subscriber" affiliations.
        • Support the "presence" access model and set it to the default.
          • @@ -481,7 +481,7 @@ ]]> -

          If the account owner's server supports PEP and the account is provisioned for PEP, the server MUST return an identity of "pubsub/pep" on behalf of the account (as well as a list of the namespaces and other features it supports, including all supported XEP-0060 features):

          +

          If the account owner's server supports PEP and the account is provisioned for PEP, the server MUST return an identity of "pubsub/pep" on behalf of the account (as well as a list of the namespaces and other features it supports, including all supported &xep0060; features):

          -

          A contact MAY send service discovery requests to the account owner's bare JID &BAREJID;. If the contact already has a subscription to the account owner's presence, this is not necessary in order to receive notifications from the account owner via personal eventing. However, a user without a presence subscription needs to do so in order to discover if the account owner is a virtual pubsub service and to discover the account owner's eventing nodes. The relevant protocol flows are demonstrated in XEP-0060.

          +

          A contact MAY send service discovery requests to the account owner's bare JID &BAREJID;. If the contact already has a subscription to the account owner's presence, this is not necessary in order to receive notifications from the account owner via personal eventing. However, a user without a presence subscription needs to do so in order to discover if the account owner is a virtual pubsub service and to discover the account owner's eventing nodes. The relevant protocol flows are demonstrated in &xep0060;.

          Note: When returning disco#items results, the account owner's server MUST check the access model for each of the account owner's PEP nodes and MUST return as service discovery items only those nodes to which the contact is allowed to subscribe or from which the contact is allowed to retrieve items without first subscribing.

           @@ -519,7 +519,7 @@
        • A presence subscription state changes (e.g., when a subscription request is approved).
        • A roster item is modified (e.g., when the item is moved to a new roster group).
      -

      If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY send a message to the (former) subscriber informing it of the cancellation (for information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of XEP-0060).

      +

      If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY send a message to the (former) subscriber informing it of the cancellation (for information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of &xep0060;).

      An earlier version of this document specified that there could be only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there could be only one pubsub node for geolocation events, one node for tune events, and one node for mood events, etc.). However, this rule is now considered overly restrictive because some data formats can be used to encapsulate many different kinds of information; the usual example is Atom as defined in &rfc4287;, for which many extensions exist. Therefore, this document now does not specify that there is a one-to-one relationship between NodeIDs and payload namespaces.

      @@ -556,7 +556,7 @@       -

      Because PEP simply reuses the protocol specified in XEP-0060, a separate schema is not needed.

      +

      Because PEP simply reuses the protocol specified in &xep0060;, a separate schema is not needed.

       diff --git a/xep-0164.xml b/xep-0164.xml index c49e44ba..cb97ad6a 100644 --- a/xep-0164.xml +++ b/xep-0164.xml @@ -54,7 +54,7 @@ -

      To illustrate the functionality of this protocol, we will first request a standard vCard. As shown in XEP-0054, a user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID. A compliant server MUST return the vCard to the requestor and not forward the IQ to the requestee's connected resource.

      +

      To illustrate the functionality of this protocol, we will first request a standard vCard. As shown in &xep0054;, a user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID. A compliant server MUST return the vCard to the requestor and not forward the IQ to the requestee's connected resource.

      The ®ISTRAR; shall add 'vcard-temp-filter' to its registry of official namespaces.

       -

      The schema for the 'vcard-temp-filter' namespace re-uses the element names from the DTD described in XEP-0054.

      +

      The schema for the 'vcard-temp-filter' namespace re-uses the element names from the DTD described in &xep0054;.

      diff --git a/xep-0165.xml b/xep-0165.xml index d8c229fc..040bd59f 100644 --- a/xep-0165.xml +++ b/xep-0165.xml @@ -96,7 +96,7 @@

      1. The JID "stpeter@jabber.org" is globally unique on the Jabber/XMPP network, but it is not necessarily memorable.

      2. The nickname "psa" (asserted by the user associated with the address "stpeter@jabber.org") is globally memorable but not necessarily unique; see &xep0172; for more information about user-asserted nicknames.

        3. -

      3. The handle or petname "that protocol dude" (assigned by a contact who adds "stpeter@jabber.org" to her contact list) is privately memorable and unique If not shared or leaked, it may even be securely unique. but is by no means global since it has meaning only to the person who assigns it; for consistency with XEP-0172 and &xmppim; we refer to this as a "handle". In RFC 6121 this was referred to as an "alias".

        4. +

      4. The handle or petname "that protocol dude" (assigned by a contact who adds "stpeter@jabber.org" to her contact list) is privately memorable and unique If not shared or leaked, it may even be securely unique. but is by no means global since it has meaning only to the person who assigns it; for consistency with &xep0172; and &xmppim; we refer to this as a "handle". In &rfc6121; this was referred to as an "alias".

      A client SHOULD require an end user to assign a handle for every contact added to the person's roster, which SHOULD be stored in the roster as the value of the <item/> element's 'name' attribute (see the Security Considerations section of this document for further discussion). A client SHOULD then present that handle instead of or in addition to the contact's JID or nickname (e.g., in the user's roster and in chat interfaces). This will help to discourage mimicked addresses from being presented as equivalent to the address that is being mimicked.

       @@ -139,7 +139,7 @@ ]]> -

      Naturally, based on the JID, it is possible to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or future profile system (see &xep0154;). However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender (encapsulated via the format specified in XEP-0172) and the sender's key or keys.

      +

      Naturally, based on the JID, it is possible to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or future profile system (see &xep0154;). However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender (encapsulated via the format specified in &xep0172;) and the sender's key or keys.

      psa diff --git a/xep-0166.xml b/xep-0166.xml index 620c34e3..7caa2210 100644 --- a/xep-0166.xml +++ b/xep-0166.xml @@ -1259,7 +1259,7 @@ PENDING o-----------------------+ | disposition - How the content definition is to be interpreted by the recipient. The meaning of this attribute matches the "Content-Disposition" header as defined in &rfc2183; and applied to SIP by RFC 3261. The value of this attribute SHOULD be one of the values registered in the &ianadispositions;. The default value of this attribute is "session". + How the content definition is to be interpreted by the recipient. The meaning of this attribute matches the "Content-Disposition" header as defined in &rfc2183; and applied to SIP by &rfc3261;. The value of this attribute SHOULD be one of the values registered in the &ianadispositions;. The default value of this attribute is "session". OPTIONAL @@ -1486,7 +1486,7 @@ PENDING o-----------------------+ |
      1. How successful application format negotiation occurs.
      2. A &DESCRIPTION; element and associated semantics for representing the application format.
        3. -
      3. If and how the application format can be mapped to the Session Description Protocol, including the appropriate SDP media type (see Section 8.2.1 of RFC 4566).
        4. +
      4. If and how the application format can be mapped to the Session Description Protocol, including the appropriate SDP media type (see Section 8.2.1 of &rfc4566;).
      5. Whether the media data for the application format shall be sent over a streaming transport method or a datagram transport method (or, if both, which is preferred).
      6. If the chosen transport handles "components", define how the components shall be identified and assigned.
      7. Exactly how the media data is to be sent and received over a streaming or datagram transport.
        8. @@ -1754,7 +1754,7 @@ PENDING o-----------------------+ |
      8. Define a full-featured protocol for XMPP signalling.

      Implementation experience indicates that a dual-stack approach might not be feasible on all the computing platforms for which Jabber clients have been written, or even desirable on platforms where it is feasible. For example, one large ISP decided to switch to a pure XMPP approach after having implemented and deployed a dual-stack client for several years. Therefore, it seemed reasonable to define an XMPP signalling protocol that could provide the necessary session management semantics while also making it relatively straightforward to interoperate with existing Internet standards.

      -

      As a result of feedback received on XEP-0111, the original authors of this document (Joe Hildebrand and Peter Saint-Andre) began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team, Google Talk is an instant messaging and voice/video chat service and client provided by Google; see <http://www.google.com/talk/>. it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified herein is, therefore, substantially equivalent to the original Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication by the XMPP Standards Foundation.

      +

      As a result of feedback received on &xep0111;, the original authors of this document (Joe Hildebrand and Peter Saint-Andre) began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team, Google Talk is an instant messaging and voice/video chat service and client provided by Google; see <http://www.google.com/talk/>. it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified herein is, therefore, substantially equivalent to the original Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication by the XMPP Standards Foundation.

      The authors would like to thank Rohan Mahy for his valuable input on early versions of the Jingle specifications. Thiago Camargo, Diana Cionoiu, Olivier Crête, Dafydd Harries, Antti Ijäs, Tim Julien, Lauri Kaila, Justin Karneges, Jussi Laako, Steffen Larsen, Marcus Lundblad, Dirk Meyer, Anthony Minessale, Akito Nozaki, Matt O'Gorman, Mike Ruprecht, Rob Taylor, Will Thompson, Matt Tucker, Justin Uberti, Saku Vainio, Unnikrishnan Vikrama Panicker, Brian West, Jeff Williams, and others have also provided helpful input. Thanks also to those who have commented on the &SSIG; and Jingle Before this specification was formally accepted by the XMPP Standards Foundation as an XMPP Extension Protocol, it was discussed on the semi-private <jingle@jabber.org> mailing list. This list has since been resurrected as a special-purpose venue for discussion of Jingle protocols and implementation; interested developers can subscribe and access the archives at at <http://mail.jabber.org/mailman/listinfo/jingle/>. mailing lists.

      diff --git a/xep-0167.xml b/xep-0167.xml index 7466fb96..f547e9d5 100644 --- a/xep-0167.xml +++ b/xep-0167.xml @@ -321,7 +321,7 @@       -

      In accordance with Section 10 of XEP-0166, this document specifies the following information related to the Jingle RTP application type:

      +

      In accordance with Section 10 of &xep0166;, this document specifies the following information related to the Jingle RTP application type:

      1. The application format negotiation process is defined in the Negotiating a Jingle RTP Session section of this document.

      2. The semantics of the &DESCRIPTION; element are defined in the Application Format section of this document.

        3. @@ -340,13 +340,13 @@

        A Jingle RTP session is described by a content type that contains one application format and one transport method. Each <content/> element defines a single RTP session. A Jingle negotiation MAY result in the establishment of multiple RTP sessions (e.g., one for audio and one for video). An application SHOULD consider all of the RTP sessions that are established via the same Jingle negotiation to be synchronized for purposes of streaming, playback, recording, etc.

        -

        RTP as defined in RFC 3550 is used in the context of various "profiles" that are defined by other specifications. Jingle RTP treats RTP profiles as follows:

        +

        RTP as defined in &rfc3550; is used in the context of various "profiles" that are defined by other specifications. Jingle RTP treats RTP profiles as follows:

        1. By default the RTP profile in Jingle RTP MUST be considered "RTP/AVP" as defined in &rfc3551;.
        2. If the session initiation request contains an <encryption/> element to specify use of SRTP as described under Negotiation of SRTP, then the RTP profile MUST instead be considered "RTP/SAVP" as defined in &rfc3711;.
        3. Future versions of this specification might define how to use other RTP profiles, such as "RTP/AVPF" and "RTP/SAVPF" as defined in &rfc4585; and &rfc5124; respectively.
        -

        The application format consists of one or more encodings contained within a wrapper <description/> element qualified by the 'urn:xmpp:jingle:apps:rtp:1' namespace &VNOTE;. In the language of RFC 4566 each encoding is a payload-type; therefore, each <payload-type/> element specifies an encoding that can be used for the RTP stream, as illustrated in the following example.

        +

        The application format consists of one or more encodings contained within a wrapper <description/> element qualified by the 'urn:xmpp:jingle:apps:rtp:1' namespace &VNOTE;. In the language of &rfc4566; each encoding is a payload-type; therefore, each <payload-type/> element specifies an encoding that can be used for the RTP stream, as illustrated in the following example.

        @@ -362,10 +362,10 @@ ]]> -

        The &DESCRIPTION; element is intended to be a child of a Jingle &CONTENT; element as specified in XEP-0166.

        +

        The &DESCRIPTION; element is intended to be a child of a Jingle &CONTENT; element as specified in &xep0166;.

        The &DESCRIPTION; element MUST possess a 'media' attribute that specifies the media type, such as "audio" or "video", where the media type SHOULD be as registered at &ianamedia;.

        -

        The &DESCRIPTION; element MAY possess a 'ssrc' attribute that specifies the 32-bit synchronization source for this media stream, as defined in RFC 3550.

        -

        After inclusion of one or more &PAYLOADTYPE; child elements, the &DESCRIPTION; element MAY also contain a <bandwidth/> element that specifies the allowable or preferred bandwidth for use by this application type. The 'type' attribute of the <bandwidth/> element SHOULD be a value for the SDP "bwtype" parameter as listed in the &ianasdp;. For RTP sessions, often the <bandwidth/> element will specify the "session bandwidth" as described in Section 6.2 of RFC 3550, measured in kilobits per second as described in Section 5.2 of RFC 4566.

        +

        The &DESCRIPTION; element MAY possess a 'ssrc' attribute that specifies the 32-bit synchronization source for this media stream, as defined in &rfc3550;.

        +

        After inclusion of one or more &PAYLOADTYPE; child elements, the &DESCRIPTION; element MAY also contain a <bandwidth/> element that specifies the allowable or preferred bandwidth for use by this application type. The 'type' attribute of the <bandwidth/> element SHOULD be a value for the SDP "bwtype" parameter as listed in the &ianasdp;. For RTP sessions, often the <bandwidth/> element will specify the "session bandwidth" as described in Section 6.2 of &rfc3550;, measured in kilobits per second as described in Section 5.2 of RFC 4566.

        Also, the &DESCRIPTION; element MAY contain a <rtcp-mux/> element that specifies the ability to multiplex RTP Data and Control Packets on a single port as described in &rfc5761;.

        The encodings SHOULD be provided in order of preference by placing the most-preferred payload type as the first &PAYLOADTYPE; child of the &DESCRIPTION; element and the least-preferred payload type as the last child.

        The attributes of the &PAYLOADTYPE; element are as follows:

        @@ -413,7 +413,7 @@ OPTIONAL -

        In Jingle RTP, the encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in RFC 3551 (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of RFC 3551. The payload IDs are represented in the 'id' attribute.

        +

        In Jingle RTP, the encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in &rfc3551; (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of RFC 3551. The payload IDs are represented in the 'id' attribute.

        Each <payload-type/> element MAY contain one or more child elements that specify particular parameters related to the payload. For example, as described in &rfc5574;, the "cng", "mode", and "vbr" parameters can be specified in relation to usage of the Speex See <http://www.speex.org/>. codec. Where such parameters are encoded via the "fmtp" SDP attribute, they shall be represented in Jingle via the following format:

        @@ -492,7 +492,7 @@ Initiator Responder ]]> -

        Upon receiving the session-initiate stanza, the responder determines whether it can proceed with the negotiation. The general Jingle error cases are specified in XEP-0166 and illustrated in the Scenarios section of this document.

        +

        Upon receiving the session-initiate stanza, the responder determines whether it can proceed with the negotiation. The general Jingle error cases are specified in &xep0166; and illustrated in the Scenarios section of this document.

        If there is no immediate error, the responder acknowledges the session initiation request.

        -

        The SDP media type for Jingle RTP is "audio" (see Section 8.2.1 of RFC 4566) for audio media, "video" (see Section 8.2.1 of RFC 4566) for video media, etc. The media type is reflected in the Jingle 'media' attribute.

        +

        The SDP media type for Jingle RTP is "audio" (see Section 8.2.1 of &rfc4566;) for audio media, "video" (see Section 8.2.1 of RFC 4566) for video media, etc. The media type is reflected in the Jingle 'media' attribute.

        The Jingle <bandwidth/> element SHALL be mapped to an SDP b= line; in particular, the value of the 'type' attribute SHALL be mapped to the SDP <bwtype> parameter and the XML character data of the Jingle <bandwidth/> element SHALL be mapped to the SDP <bandwidth> parameter.

        -

        If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to an m= line as defined in RFC 4566. The generic format for this line is as follows:

        +

        If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to an m= line as defined in &rfc4566;. The generic format for this line is as follows:

        ]]> diff --git a/xep-0169.xml b/xep-0169.xml index 5d4683b1..65fe54a1 100644 --- a/xep-0169.xml +++ b/xep-0169.xml @@ -569,7 +569,7 @@ | |-- blitzen |-- santa et al. ]]>         -

        In addition, we assume that the twas-the-night.lit server is running a virtual pubsub service for each account it hosts (in accordance with XEP-0163) and that the users "narrator", "mama", and "child" publish information to personal pubsub nodes related to mood (XEP-0107), activity (XEP-0108), and physical location (XEP-0112).

        +

        In addition, we assume that the twas-the-night.lit server is running a virtual pubsub service for each account it hosts (in accordance with &xep0163;) and that the users "narrator", "mama", and "child" publish information to personal pubsub nodes related to mood (XEP-0107), activity (XEP-0108), and physical location (XEP-0112).

        * Because millions of people track the movements and activities of Santa, northpole.lit runs a highly scalable, standalone pubsub service instead of PEP at Santa's bare JID.

        ** The U.S. Military divides its operations geographically among NORTHCOM, SOUTHCOM, EUCOM, and PACOM. Given the scale of operations implemented by Santa's workshop, it comes as no surprise that the command center at the North Pole is known as POLECOM. Naturally POLECOM subscribes to the pubsub feeds for Santa's geolocation and activity, as well as the sleigh's geolocation, just in case a search and rescue mission needs to be initiated.

         diff --git a/xep-0171.xml b/xep-0171.xml index 56b0db5f..187ae857 100644 --- a/xep-0171.xml +++ b/xep-0171.xml @@ -384,7 +384,7 @@

        Note: The 'reviewed' and 'pivotable' attributes are of type "boolean" and MUST be handled accordingly. &BOOLEANNOTE;

        -

        In order to properly process multi-language messages, clients MUST implement support for multiple message bodies differentiated by the 'xml:lang' attribute as described in RFC 6120.

        +

        In order to properly process multi-language messages, clients MUST implement support for multiple message bodies differentiated by the 'xml:lang' attribute as described in &rfc6120;.

        Potential attacks may be easier against services that implement translation because of the potential disclosure of information regarding language pairings, engines, and dictionaries used however no specific vulnerabilities are introduced.

        diff --git a/xep-0172.xml b/xep-0172.xml index dbf7f647..43ca98fc 100644 --- a/xep-0172.xml +++ b/xep-0172.xml @@ -164,11 +164,11 @@
      3. Waiting lists
    -

    As defined in RFC 6121, a presence subscription request contains only the JID of the sender:

    +

    As defined in &rfc6121;, a presence subscription request contains only the JID of the sender:

    ]]> -

    Naturally, based on the JID of the sender, it is possible for the client to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or XEP-0154 store. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender:

    +

    Naturally, based on the JID of the sender, it is possible for the client to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or &xep0154; store. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender:

    Ishmael @@ -255,7 +255,7 @@ . . ]]> -

    If a client does not support XEP-0060 or the subset thereof specified in XEP-0163, it MAY send one &MESSAGE; stanza to each of its contacts, containing the updated nickname (note: the client SHOULD send the messages in a staggered fashion in order to avoid server-enforced rate limiting, commonly known as "karma").

    +

    If a client does not support &xep0060; or the subset thereof specified in XEP-0163, it MAY send one &MESSAGE; stanza to each of its contacts, containing the updated nickname (note: the client SHOULD send the messages in a staggered fashion in order to avoid server-enforced rate limiting, commonly known as "karma").

    CallMeIshmael @@ -267,14 +267,14 @@     -

    An IM client MAY use the user's own nickname as all or part of the "display name" shown to the user of that client (e.g., as the sending name in one-to-one chats and groupchats). For example, if the user whose JID is narrator@moby-dick.lit asserts that his nickname is "Ishmael", that user's client may show "Ishmael" as all or part of the user's display name. How the client shall store the display name is out of scope for this document; possible mechanisms include the user's local vCard, an organizational LDAP directory, &xep0049;, or XEP-0154.

    +

    An IM client MAY use the user's own nickname as all or part of the "display name" shown to the user of that client (e.g., as the sending name in one-to-one chats and groupchats). For example, if the user whose JID is narrator@moby-dick.lit asserts that his nickname is "Ishmael", that user's client may show "Ishmael" as all or part of the user's display name. How the client shall store the display name is out of scope for this document; possible mechanisms include the user's local vCard, an organizational LDAP directory, &xep0049;, or &xep0154;.

    Earlier versions of this document described how to include the User Nickname extension in presence stanzas and invitations sent in relation to &xep0045; rooms. Based on deployment experience, that usage is now discouraged, since it is confusing to display multiple nicknames to an end user and inclusion of user-generated nicknames can override or work around local service policies for "nick lockdown" in chatrooms.

    Earlier versions also described usage in relation to the &xep0130; protocol. Because that protocol is now obsolete, documentation of such usage has been removed from this specification.

     -

    A nickname is a memorable, friendly name asserted by a user. There is no guarantee that any given nickname will be unique even within a particular community (such as an enterprise or university), let alone across the Internet through federation of communities. Clients SHOULD warn users that nicknames asserted by contacts are not unique and that nickname collisions are possible. Clients also MUST NOT depend on nicknames to validate the identity of contacts; instead, nicknames SHOULD be used in conjunction with JIDs (which are globally unique) and user-assigned handles (which are private and unique) as described in XEP-0165 in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.

    +

    A nickname is a memorable, friendly name asserted by a user. There is no guarantee that any given nickname will be unique even within a particular community (such as an enterprise or university), let alone across the Internet through federation of communities. Clients SHOULD warn users that nicknames asserted by contacts are not unique and that nickname collisions are possible. Clients also MUST NOT depend on nicknames to validate the identity of contacts; instead, nicknames SHOULD be used in conjunction with JIDs (which are globally unique) and user-assigned handles (which are private and unique) as described in &xep0165; in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.

    This document requires no interaction with &IANA;.

    diff --git a/xep-0174.xml b/xep-0174.xml index 83cb494b..8dc82cd2 100644 --- a/xep-0174.xml +++ b/xep-0174.xml @@ -340,7 +340,7 @@ juliet@pronto._presence._tcp.local. IN TXT "vc=CA!" "ver=QgayPKawpkPSDYmwT/WM94uAlu0="" ]]>     -

    The IPv4 and IPv6 addresses associated with a machine might vary depending on the local network to which the machine is connected. For example, on an Ethernet connection the physical address might be "192.168.0.100" but when the machine is connected to a wireless network the physical address might change to "10.10.1.187". See RFC 3927 for details.

    +

    The IPv4 and IPv6 addresses associated with a machine might vary depending on the local network to which the machine is connected. For example, on an Ethernet connection the physical address might be "192.168.0.100" but when the machine is connected to a wireless network the physical address might change to "10.10.1.187". See &rfc3927; for details.

    If the machine name asserted by a client is already taken by another machine on the network, the client MUST assert a different machine name, which SHOULD be formed by adding the character "-" and digit "1" to the end of the machine name string (e.g., "pronto-1"), adding the character "-" and digit "2" if the resulting machine name is already taken (e.g., "pronto-2"), and similarly incrementing the digit until a unique machine name is constructed.

    If the username asserted by a client is already taken by another application on the machine, the client MUST assert a different username, which SHOULD be formed by adding the character "-" and digit "1" to the end of the username string (e.g., "juliet-1"), adding the character "-" and digit "2" if the resulting username is already taken (e.g., "juliet-2"), and similarly incrementing the digit until a unique username is constructed.

    @@ -368,7 +368,7 @@ juliet@pronto._presence._tcp.local. IN TXT -

    In order to exchange serverless messages, the initiator and recipient MUST first establish XML streams between themselves, as is familiar from RFC 6120.

    +

    In order to exchange serverless messages, the initiator and recipient MUST first establish XML streams between themselves, as is familiar from &rfc6120;.

    First, the initiator opens a TCP connection at the IP address and port discovered via the DNS lookup for an entity and opens an XML stream to the recipient, which SHOULD include 'to' and 'from' address:

    @@ -379,7 +379,7 @@ I: to='juliet@pronto' version='1.0'> ]]> -

    Note: If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in RFC 6120, then it SHOULD include the version='1.0' flag as shown in the previous example.

    +

    Note: If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in &rfc6120;, then it SHOULD include the version='1.0' flag as shown in the previous example.

    The recipient then responds with a stream header as well:

    @@ -390,7 +390,7 @@ R: to='romeo@forza' version='1.0'> ]]> -

    If both the initiator and recipient included the version='1.0' flag, the recipient SHOULD also send stream features as specified in RFC 6120:

    +

    If both the initiator and recipient included the version='1.0' flag, the recipient SHOULD also send stream features as specified in &rfc6120;:

    @@ -433,7 +433,7 @@ I:     -

    Because serverless communication does not involve the exchange of XMPP presence, it is not possible to use &xep0115; for capabilities discovery. Therefore, it is RECOMMENDED to instead include the node, hash, and ver TXT record parameters (and OPTIONAL to include the ext parameter). The values of these parameters MUST be the same as the values for the 'node', 'hash', 'ver', and 'ext' attributes that are advertised for the application in normal XMPP presence (if any) via the Entity Capabilities protocol as described in XEP-0115.

    +

    Because serverless communication does not involve the exchange of XMPP presence, it is not possible to use &xep0115; for capabilities discovery. Therefore, it is RECOMMENDED to instead include the node, hash, and ver TXT record parameters (and OPTIONAL to include the ext parameter). The values of these parameters MUST be the same as the values for the 'node', 'hash', 'ver', and 'ext' attributes that are advertised for the application in normal XMPP presence (if any) via the Entity Capabilities protocol as described in &xep0115;.

    As with Entity Capabilities over native XMPP networks, a client might not know the &xep0030; features associated with the 'ver' value advertised by another entity. However, in the case of serverless messaging there is no way for the client to discover the entity's supported features without initiating an XML stream to that entity and then sending a Service Discovery information ("disco#info") request over the negotiated stream.

    Unfortunately, full stream negotiation (including TLS and SASL if appropriate) can require a large number of packets. Therefore, as an optimization, it is RECOMMENDED for the receiving entity in a serverless XML stream negotiation to include its disco#info data (including node) as a stream feature, as shown in the following examples.

    -

    RFC 1035 does not allow characters outside the &ascii; character range in DNS A records. Therefore the "machine" portion of an A record as used for serverless messaging MUST NOT contain characters outside the US-ASCII character range.

    -

    Although RFC 2317 and RFC 2782 do not allow characters outside the US-ASCII character range in PTR and SRV records respectively, Section 4.1 of DNS-Based Service Discovery recommends support for UTF-8-encoded Unicode characters in the <Instance> portion of Service Instance Names, which in serverless messaging is the "user@machine" portion of the PTR or SRV record. This document adheres to the recommendation in DNS-Based Service Discovery. However, as mentioned above, the "machine" portion of the <Instance> portion MUST NOT contain characters outside the US-ASCII range.

    -

    Although RFC 1464 does not allow characters outside the US-ASCII character range in TXT records, Section 6.5 of DNS-Based Service Discovery mentions support for UTF-8-encoded Unicode characters in text record values (e.g., values of the TXT "msg" name). This document adheres to the recommendation in DNS-Based Service Discovery.

    +

    &rfc1035; does not allow characters outside the &ascii; character range in DNS A records. Therefore the "machine" portion of an A record as used for serverless messaging MUST NOT contain characters outside the US-ASCII character range.

    +

    Although &rfc2317; and RFC 2782 do not allow characters outside the US-ASCII character range in PTR and SRV records respectively, Section 4.1 of DNS-Based Service Discovery recommends support for UTF-8-encoded Unicode characters in the <Instance> portion of Service Instance Names, which in serverless messaging is the "user@machine" portion of the PTR or SRV record. This document adheres to the recommendation in DNS-Based Service Discovery. However, as mentioned above, the "machine" portion of the <Instance> portion MUST NOT contain characters outside the US-ASCII range.

    +

    Although &rfc1464; does not allow characters outside the US-ASCII character range in TXT records, Section 6.5 of DNS-Based Service Discovery mentions support for UTF-8-encoded Unicode characters in text record values (e.g., values of the TXT "msg" name). This document adheres to the recommendation in DNS-Based Service Discovery.

    XMPP networks use TLS (&rfc5246;) for channel encryption, SASL (&rfc4422;) for authentication, and the Domain Name System (&rfc1034;) for weak validation of server hostnames; these technologies help to ensure the identity of sending entities and to encrypt XML streams. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, serverless messaging does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between entities.

    -

    To secure communications between serverless entities, it is RECOMMENDED to negotiate the use of TLS and SASL for the XML stream as described in RFC 6120. However, subject to client configuration and local service policies, an entity MAY accept an unauthenticated and unencrypted channel, in which case the client SHOULD warn the human user that the channel is unauthenticated and unencrypted.

    +

    To secure communications between serverless entities, it is RECOMMENDED to negotiate the use of TLS and SASL for the XML stream as described in &rfc6120;. However, subject to client configuration and local service policies, an entity MAY accept an unauthenticated and unencrypted channel, in which case the client SHOULD warn the human user that the channel is unauthenticated and unencrypted.

     -

    Because of fundamental differences between a true XMPP network and a serverless client "mesh", entities communicating via serverless messaging MUST NOT attempt to inject serverless traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated in accordance with the rules defined in RFC 6120. However, a client on a serverless mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a serverless client mesh to a contact on an XMPP network).

    +

    Because of fundamental differences between a true XMPP network and a serverless client "mesh", entities communicating via serverless messaging MUST NOT attempt to inject serverless traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated in accordance with the rules defined in &rfc6120;. However, a client on a serverless mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a serverless client mesh to a contact on an XMPP network).

    Because there is no mechanism for validating the information that is published in DNS TXT records, it is possible for clients to "poison" this information (e.g., by publishing email addresses or Jabber IDs that are controlled by or associated with other users).

    diff --git a/xep-0175.xml b/xep-0175.xml index f78d8529..a5c26112 100644 --- a/xep-0175.xml +++ b/xep-0175.xml @@ -66,7 +66,7 @@

    An XMPP server implementation SHOULD NOT enable the SASL ANONYMOUS mechanism by default, but instead SHOULD force the administrator of a given service to explicitly enable support in the context of that deployment.

    When a client authenticates using SASL ANONYMOUS, an XMPP server SHOULD assign a temporary, unique bare JID &LOCALBARE; to the client. Although the method for ensuring the uniqueness of the localpart is a matter of implementation, it is RECOMMENDED for the localpart to be a UUID as specified in &rfc4122;.

    -

    Although RFC 4505 allows the client to provide so-called "trace data" when authenticating via SASL ANONYMOUS, it is NOT RECOMMENDED for the client to include trace data as the XML character data of the <auth/> element (instead, the <auth/> element SHOULD be empty). However, if trace data is included, the server MUST NOT use it for any purpose other than tracing (e.g., not use it as the resource identifier of the anonymous user's full JID).

    +

    Although &rfc4505; allows the client to provide so-called "trace data" when authenticating via SASL ANONYMOUS, it is NOT RECOMMENDED for the client to include trace data as the XML character data of the <auth/> element (instead, the <auth/> element SHOULD be empty). However, if trace data is included, the server MUST NOT use it for any purpose other than tracing (e.g., not use it as the resource identifier of the anonymous user's full JID).

    Because an anonymous user is unknown to the server, the server SHOULD appropriately restrict the user's access in order to limit the possibility of malicious behavior (such as denial of service attacks as described in &xep0205;), especially on public deployments. The following restrictions are encouraged on public deployments. Administrators of private deployments and specialized deployments are advised to take these restrictions into account when configuring their services, but can reasonably relax these restrictions if they have appropriate access controls in place or their deployment requirements cannot be met using the more restrictive profile applied in public deployments.

    1. During resource binding, the server MAY ignore the resource identifier provided by the client (if any) and instead assign a resource identifier that it generates on behalf of the client.

      2. @@ -77,7 +77,7 @@
    -

    The RECOMMENDED protocol flow following TLS negotiation (refer to RFC 3920) is as follows:

    +

    The RECOMMENDED protocol flow following TLS negotiation (refer to &rfc3920;) is as follows:

    1. Client initiates stream to server.

      @@ -183,7 +183,7 @@ ]]> -

      The security considerations discussed in RFC 3920 and RFC 4505 apply to the use of SASL ANONYMOUS in XMPP; specific suggestions regarding usage restrictions for anonymous users are provided under the Recommendations section of this document.

      +

      The security considerations discussed in &rfc3920; and RFC 4505 apply to the use of SASL ANONYMOUS in XMPP; specific suggestions regarding usage restrictions for anonymous users are provided under the Recommendations section of this document.

      This document requires no interaction with &IANA;.

      diff --git a/xep-0176.xml b/xep-0176.xml index e764c5f7..d070e404 100644 --- a/xep-0176.xml +++ b/xep-0176.xml @@ -250,7 +250,7 @@
    -

    In accordance with Section 10 of XEP-0166, this document specifies the following information related to the Jingle ice-udp transport method:

    +

    In accordance with Section 10 of &xep0166;, this document specifies the following information related to the Jingle ice-udp transport method:

    1. The transport negotiation process is defined in the Protocol Description section of this document.

    2. The semantics of the &TRANSPORT; element are defined in the ICE Negotiation section of this document.

      3. @@ -287,7 +287,7 @@ INITIATOR RESPONDER

      Note: The examples in this document follow the scenario described in Section 17 of &icecore;, except that we substitute the Shakespearean characters "Romeo" and "Juliet" for the generic entities "L" and "R".

      -

      In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in XEP-0166. If the initiator wishes to negotiate the ice-udp transport method for an application format, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:ice-udp:1' namespace &VNOTE;. This element SHOULD in turn contain one &CANDIDATE; element for each of the initiator's higher-priority transport candidates as determined in accordance with the ICE methodology, but MAY instead be empty (with each candidate to be sent as the payload of a transport-info message).

      +

      In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in &xep0166;. If the initiator wishes to negotiate the ice-udp transport method for an application format, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:ice-udp:1' namespace &VNOTE;. This element SHOULD in turn contain one &CANDIDATE; element for each of the initiator's higher-priority transport candidates as determined in accordance with the ICE methodology, but MAY instead be empty (with each candidate to be sent as the payload of a transport-info message).

       -

      As described in XEP-0166, to acknowledge receipt of the session initiation request, the responder immediately returns an IQ-result.

      +

      As described in &xep0166;, to acknowledge receipt of the session initiation request, the responder immediately returns an IQ-result.

      The initiator and responder negotiate connectivity over ICE by exchanging XML-formatted transport candidates for the channel. This negotiation proceeds immediately in order to maximize the possibility that connectivity can be established (and therefore media can be exchanged) as quickly as possible. In order to expedite session establishment, the initiator SHOULD include transport candidates in its session-initiate message but MAY also send additional transport candidates as soon as it learns of them, even before receiving acknowledgement of the session-initiate message (i.e., the initiator MUST consider the session to be live as soon as it sends the session-initiate message). Given in-order delivery as mandated by &xmppcore;, the responder will receive such transport-info messages after receiving the session-initiate message; if not, it is appropriate for the responder to return <unknown-session/> errors since according to its state machine the session does not exist.

      The first step in negotiating connectivity is for each party to send transport candidates to the other party. The fact that both parties send candidates means that Jingle requires each party to be a full implementation of ICE, not a lite implementation as specified in &icecore;. These candidates SHOULD be gathered by following the procedure specified in Section 4.1.1 of &icecore; (typically by communicating with a standalone STUN server in order to discover the client's public IP address and port) and prioritized by following the procedure specified in Section 4.1.2 of &icecore;.

      Each candidate shall be sent as a <candidate/> child of a &TRANSPORT; element qualified by the 'urn:xmpp:jingle:transports:ice-udp:1' namespace. The &TRANSPORT; element is sent via a Jingle message of type session-initiate, session-accept, or transport-info.

      -

      Either party MAY include multiple <candidate/> elements in one &TRANSPORT; element, especially in the session-initiate and session-accept messages sent at the beginning of the session negotiation. Including multiple candidates in the session-initiate and session-accept messages can help to ensure interoperability with entities that implement the SDP offer/answer model described in RFC 3264; in particular, an entity SHOULD include multiple candidates in its session-initiate or session-accept message if the other party advertises support for the "urn:ietf:rfc:3264" service discovery feature as described in the SDP Offer / Answer Support section of this document. However, including one candidate per subsequent transport-info message typically results in a faster negotiation because the candidates most likely to succeed are sent first (in the session-info and session-accept messages) and it is not necessary to gather all candidates before beginning to send any candidates; furthermore, because certain candidates can be more "expensive" in terms of bandwidth or processing power, either party might not want to advertise the existence of such candidates unless it is necessary to do so after other candidates have failed.

      +

      Either party MAY include multiple <candidate/> elements in one &TRANSPORT; element, especially in the session-initiate and session-accept messages sent at the beginning of the session negotiation. Including multiple candidates in the session-initiate and session-accept messages can help to ensure interoperability with entities that implement the SDP offer/answer model described in &rfc3264;; in particular, an entity SHOULD include multiple candidates in its session-initiate or session-accept message if the other party advertises support for the "urn:ietf:rfc:3264" service discovery feature as described in the SDP Offer / Answer Support section of this document. However, including one candidate per subsequent transport-info message typically results in a faster negotiation because the candidates most likely to succeed are sent first (in the session-info and session-accept messages) and it is not necessary to gather all candidates before beginning to send any candidates; furthermore, because certain candidates can be more "expensive" in terms of bandwidth or processing power, either party might not want to advertise the existence of such candidates unless it is necessary to do so after other candidates have failed.

      If the party that receives a candidate in a Jingle message can successfully process a given candidate or set of candidates, it returns an IQ-result (if not, for example because the candidate data is improperly formatted, it returns an IQ-error). At this point, the receiving entity is only indicating receipt of the candidate or set of candidates, not telling the other party that the candidate will be used.

      The initiator can keep sending candidates (without stopping to receive an acknowledgement of receipt from the responder for each candidate) until it has exhausted its supply of possible or desirable transport candidates. The responder can also keep sending potential candidates, which the initiator will acknowledge.

       @@ -592,7 +592,7 @@ INITIATOR NAT RESPONDER ]]>

      (In accordance with Jingle core, the responder will also acknowledge the transport-info message.)

      -

      In the unlikely event that one of the parties determines that it cannot establish connectivity even after sending and checking lower-priority candidates, it SHOULD terminate the session as described in XEP-0166.

      +

      In the unlikely event that one of the parties determines that it cannot establish connectivity even after sending and checking lower-priority candidates, it SHOULD terminate the session as described in &xep0166;.

      Even after media has begun to flow, either party MAY continue to send additional candidates to the other party (e.g., because the user agent has become aware of a new media proxy or network interface card). Such candidates are shared by sending a transport-info message.

      @@ -888,7 +888,7 @@ Romeo Gateway Juliet

      In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

       -

      If an entity supports the SDP offer / answer model described in RFC 3264 and therefore prefers to receive multiple candidates in a single transport-info message, it MUST advertise support for the "urn:ietf:rfc:3264" service discovery feature. Typically this feature will be advertised only by gateways between Jingle and SIP.

      +

      If an entity supports the SDP offer / answer model described in &rfc3264; and therefore prefers to receive multiple candidates in a single transport-info message, it MUST advertise support for the "urn:ietf:rfc:3264" service discovery feature. Typically this feature will be advertised only by gateways between Jingle and SIP.

      By definition, the exchange of transport candidates results in exposure of the sender's IP addresses, which comprise a form of personally identifying information. A Jingle client MUST enable a user to control which entities will be allowed to receive such information. If a human user explicitly accepts a session request, then the client SHOULD consider that action to imply approval of IP address sharing. However, waiting for a human user to explicitly accept the session request can result in delays during session setup, since it is more efficient to immediately begin sharing transport candidates. Therefore, it is RECOMMENDED for the client to immediately send transport candidates to a contact (without waiting for explicit user approval of the session request) in the following cases:

      1. The user has permanently and formally authorized the contact to view the user's presence information via a presence subscription as reflected in an XMPP roster item (see &xmppim;).
        2. -
      2. The user has temporarily and dynamically shared presence with the contact via "directed presence" as described in RFC 3921.
        3. +
      3. The user has temporarily and dynamically shared presence with the contact via "directed presence" as described in &rfc3921;.
      4. The user has explicitly added the contact to a list of entities who are allowed to access the user's personally-identifying information.
       @@ -955,7 +955,7 @@ Romeo Gateway Juliet &NSVER; -

      If an entity supports the SDP offer / answer model described in RFC 3264 and therefore prefers to receive one transport-info message with multiple candidates, it MUST advertise support for the "urn:ietf:rfc:3264" feature.

      +

      If an entity supports the SDP offer / answer model described in &rfc3264; and therefore prefers to receive one transport-info message with multiple candidates, it MUST advertise support for the "urn:ietf:rfc:3264" feature.

      The registry submission is as follows.

      diff --git a/xep-0177.xml b/xep-0177.xml index 12196275..860a3a32 100644 --- a/xep-0177.xml +++ b/xep-0177.xml @@ -181,7 +181,7 @@ -

      In accordance with Section 10 of XEP-0166, this document specifies the following information related to the Jingle Raw UDP transport type:

      +

      In accordance with Section 10 of &xep0166;, this document specifies the following information related to the Jingle Raw UDP transport type:

      1. The transport negotiation process is defined in the Protocol Description section of this document.

      2. The semantics of the &TRANSPORT; element are defined in the Transport Initiation section of this document.

        3. @@ -211,7 +211,7 @@ INITIATOR RESPONDER -

        In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in XEP-0166. If the initiator wishes to negotiate the Raw UDP transport for a given content type, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:raw-udp:1' namespace &VNOTE;, which MUST This is required to avoid a round trip and help expedite the negotiation. include the initiator's Raw UDP candidate via the 'ip', 'port', 'generation', and 'id' attributes of the &CANDIDATE; element. The &TRANSPORT; element MAY include more than one &CANDIDATE; element (typically one for RTP and another for RTCP).

        +

        In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in &xep0166;. If the initiator wishes to negotiate the Raw UDP transport for a given content type, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:raw-udp:1' namespace &VNOTE;, which MUST This is required to avoid a round trip and help expedite the negotiation. include the initiator's Raw UDP candidate via the 'ip', 'port', 'generation', and 'id' attributes of the &CANDIDATE; element. The &TRANSPORT; element MAY include more than one &CANDIDATE; element (typically one for RTP and another for RTCP).

        Server reflexive or peer reflexive candidate discovered via STUN (see &rfc5389;) -

        If the client is aware of which type of candidate it is sending, the candidate element MAY contain a 'type' attribute. Although this information is merely a hint about the candidate type, this information can help the recipient be aware of how permissive the peer's NAT or firewall is. The values of the 'type' attribute are "host", "prflx", "relay", and "srflx" (as in the ICE specification and XEP-0176).

        +

        If the client is aware of which type of candidate it is sending, the candidate element MAY contain a 'type' attribute. Although this information is merely a hint about the candidate type, this information can help the recipient be aware of how permissive the peer's NAT or firewall is. The values of the 'type' attribute are "host", "prflx", "relay", and "srflx" (as in the ICE specification and &xep0176;).

         -

        As described in XEP-0166, to acknowledge the session initiation request, the responder returns an IQ-result:

        +

        As described in &xep0166;, to acknowledge the session initiation request, the responder returns an IQ-result:

        XMPP as specified in &rfc3920; and updated in &rfc6120; allows the use of any SASL (&rfc4422;) mechanism in the authentication of XMPP entities. This document specifies a recommended protocol flow for use of the SASL EXTERNAL mechanism with PKIX (&rfc5280;) certificates This specification focuses on the use of the SASL EXTERNAL mechanism with X.509 certificates. Future specifications might document best practices for use of SASL EXTERNAL outside the context of the X.509 infrastructure, for example via Internet Protocol Security (IPSec) as specified in &rfc4301;., especially when an XMPP service indicates that TLS is mandatory-to-negotiate.

        -

        As specified in RFC 3920 and updated in RFC 6120, during the stream negotiation process an XMPP client can present a certificate (a "client certificate"). If a JabberID is included in a client certificate, it is encapsulated as an id-on-xmppAddr Object Identifier ("xmppAddr"), i.e., a subjectAltName entry of type otherName with an ASN.1 Object Identifier of "id-on-xmppAddr" as specified in Section 13.7.1.4 of RFC 6120.

        +

        As specified in &rfc3920; and updated in RFC 6120, during the stream negotiation process an XMPP client can present a certificate (a "client certificate"). If a JabberID is included in a client certificate, it is encapsulated as an id-on-xmppAddr Object Identifier ("xmppAddr"), i.e., a subjectAltName entry of type otherName with an ASN.1 Object Identifier of "id-on-xmppAddr" as specified in Section 13.7.1.4 of RFC 6120.

        There are three possible cases:

        1. The certificate includes one xmppAddr.
          2. @@ -187,7 +187,7 @@ ]]>
        2. -

          Server advertises SASL mechanisms. Because the client presented a client certificate, here the server offers the SASL EXTERNAL mechanism (see Section 6.3.4 of RFC 6120 for recommendations regarding the conditions under which to offer the SASL EXTERNAL mechanism).

          +

          Server advertises SASL mechanisms. Because the client presented a client certificate, here the server offers the SASL EXTERNAL mechanism (see Section 6.3.4 of &rfc6120; for recommendations regarding the conditions under which to offer the SASL EXTERNAL mechanism).

          @@ -199,7 +199,7 @@ ]]>
        3. -

          Client considers EXTERNAL to be its preferred SASL mechanism so it attempts to complete SASL negotiation using that mechanism. The following paragraphs illustrate several possible paths, depending on whether the client includes an authorization identity (for the official rules regarding when to include the authorization identity, see Section 6.3.8 of RFC 6120).

          +

          Client considers EXTERNAL to be its preferred SASL mechanism so it attempts to complete SASL negotiation using that mechanism. The following paragraphs illustrate several possible paths, depending on whether the client includes an authorization identity (for the official rules regarding when to include the authorization identity, see Section 6.3.8 of &rfc6120;).

          1. If the client certificate contains only one JID, then the client MAY include an authorization identity, but only if it desires to be authorized as a JID other than the address in the client certificate; else it MUST NOT include an authorization identity (this is shown in the following example by setting the XML character data of the <auth/> element to "=").

            @@ -269,12 +269,12 @@
        4. -

          If SASL authentication succeeded, the client opens a new stream, then client and server proceed with resource binding as described in RFC 6120.

          +

          If SASL authentication succeeded, the client opens a new stream, then client and server proceed with resource binding as described in &rfc6120;.

         -

        RFC 3920 specified that if a JabberID is included in a certificate intended for use by an XMPP server (a "server certificate"), it shall be encapsulated as an xmppAddr. That recommendation is updated in RFC 6120 through a reference to &rfc6125;, which prefers use of a dNSName and/or SRVName entry in the Subject Alternative Name. The DNS domain name contained in the certificate can be a fully-qualified domain name ("FQDN") or a so-called "wildcard" with the '*' character as the complete left-most label (see RFC 6125 for complete details).

        +

        &rfc3920; specified that if a JabberID is included in a certificate intended for use by an XMPP server (a "server certificate"), it shall be encapsulated as an xmppAddr. That recommendation is updated in RFC 6120 through a reference to &rfc6125;, which prefers use of a dNSName and/or SRVName entry in the Subject Alternative Name. The DNS domain name contained in the certificate can be a fully-qualified domain name ("FQDN") or a so-called "wildcard" with the '*' character as the complete left-most label (see RFC 6125 for complete details).

        The RECOMMENDED protocol flow for server-to-server use of SASL EXTERNAL with server (domain) certificates is as follows:

        1. @@ -326,10 +326,10 @@

          Server2 requests, and Server1 presents, Server1's certificate during TLS negotiation.

        2. -

          Server2 validates certificate in accordance with the rules from RFC 6120 and RFC 6125.

          +

          Server2 validates certificate in accordance with the rules from &rfc6120; and RFC 6125.

          1. -

            If certificate is unacceptable for the reasons explained in RFC 6120 and RFC 6125, Server2 closes Server1's TCP connection.

            +

            If certificate is unacceptable for the reasons explained in &rfc6120; and RFC 6125, Server2 closes Server1's TCP connection.

          2. Else Server2 completes successful TLS negotiation and Server1 sends a new initial stream header to Server2 over the encrypted TCP connection.

            @@ -357,7 +357,7 @@ ]]>
          3. -

            Server2 advertises SASL mechanisms. If the 'from' attribute of the stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from RFC 6125, Server2 SHOULD advertise the SASL EXTERNAL mechanism. If no match is found, Server2 MAY either close Server1's TCP connection or continue with a &xep0220; negotiation.

            +

            Server2 advertises SASL mechanisms. If the 'from' attribute of the stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from &rfc6125;, Server2 SHOULD advertise the SASL EXTERNAL mechanism. If no match is found, Server2 MAY either close Server1's TCP connection or continue with a &xep0220; negotiation.

            @@ -367,7 +367,7 @@ ]]>
          4. -

            Server1 considers EXTERNAL to be its preferred SASL mechanism. For server-to-server authentication, the <auth/> element MAY include an authorization identity, however a future version of this specification might disallow use of the authorization identity in server-to-server authentication (in the following example, Server1 includes an empty response of "=" as shown in RFC 6120).

            +

            Server1 considers EXTERNAL to be its preferred SASL mechanism. For server-to-server authentication, the <auth/> element MAY include an authorization identity, however a future version of this specification might disallow use of the authorization identity in server-to-server authentication (in the following example, Server1 includes an empty response of "=" as shown in &rfc6120;).

            = @@ -378,7 +378,7 @@

            Server2 determines if hostname is valid.

            1. -

              If the 'from' attribute of stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from RFC 6125, Server2 returns success.

              +

              If the 'from' attribute of stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from &rfc6125;, Server2 returns success.

              ]]> @@ -398,7 +398,7 @@
            -

            This document introduces no security considerations or concerns above and beyond those discussed in RFC 6120 and RFC 6125.

            +

            This document introduces no security considerations or concerns above and beyond those discussed in &rfc6120; and RFC 6125.

            This document requires no interaction with &IANA;.

            diff --git a/xep-0179.xml b/xep-0179.xml index 14aa5cfb..c648e827 100644 --- a/xep-0179.xml +++ b/xep-0179.xml @@ -79,7 +79,7 @@             -

            In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in XEP-0166. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the IAX transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/iax' namespace.

            +

            In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in &xep0166;. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the IAX transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/iax' namespace.

            -

            As described in XEP-0166, to provisionally accept the session initiation request, the target entity returns an IQ-result:

            +

            As described in &xep0166;, to provisionally accept the session initiation request, the target entity returns an IQ-result:

            ]]> diff --git a/xep-0180.xml b/xep-0180.xml index 39b9507e..32d0fe06 100644 --- a/xep-0180.xml +++ b/xep-0180.xml @@ -140,7 +140,7 @@             -

            In accordance with Section 8 of XEP-0166, this document specifies the following information related to the Jingle Video via RTP application type:

            +

            In accordance with Section 8 of &xep0166;, this document specifies the following information related to the Jingle Video via RTP application type:

            1. The application format negotiation process is defined in the Negotiating a Jingle Video Session section of this document.

            2. The semantics of the &DESCRIPTION; element are defined in the Application Format section of this document.

              3. @@ -156,7 +156,7 @@ -

              A Jingle video session is described by a content type that contains one application format and one transport method. The application format consists of one or more encodings contained within a wrapper <description/> element qualified by the 'urn:xmpp:tmp:jingle:apps:video-rtp' namespace &NSNOTE;. In the language of RFC 4566 each encoding is a payload-type; therefore, each <payload-type/> element specifies an encoding that can be used for the audio stream, as illustrated in the following example.

              +

              A Jingle video session is described by a content type that contains one application format and one transport method. The application format consists of one or more encodings contained within a wrapper <description/> element qualified by the 'urn:xmpp:tmp:jingle:apps:video-rtp' namespace &NSNOTE;. In the language of &rfc4566; each encoding is a payload-type; therefore, each <payload-type/> element specifies an encoding that can be used for the audio stream, as illustrated in the following example.

              @@ -171,7 +171,7 @@ ]]> -

              The &DESCRIPTION; element is intended to be a child of a &CONTENT; element as specified in XEP-0166.

              +

              The &DESCRIPTION; element is intended to be a child of a &CONTENT; element as specified in &xep0166;.

              The &DESCRIPTION; element SHOULD possess a 'profile' attribute that specifies the profile of RTP in use as would be encapsulated in SDP (e.g., "RTP/AVP" or "UDP/TLS/RTP/SAVP"). If not included, the default value of "RTP/AVP" MUST be assumed.

              The encodings SHOULD be provided in order of preference by placing the most-preferred &PAYLOADTYPE; element as the first child of the &DESCRIPTION; element (etc.).

              The allowable attributes of the &PAYLOADTYPE; element are as follows:

              @@ -207,7 +207,7 @@ RECOMMENDED for static payload types, REQUIRED for dynamic payload types -

              In Jingle Video, the encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in &rfc3551; (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of RFC 3551. The payload IDs are represented in the 'id' attribute.

              +

              In Jingle Video, the encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in &rfc3551; (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of &rfc3551;. The payload IDs are represented in the 'id' attribute.

              Each <payload-type/> element MAY contain one or more child elements that specify particular parameters related to the payload. For example, as described in &rtptheora;, the "configuration", "configuration-uri", "delivery-method", "height", "sampling", and "width" parameters may be specified in relation to usage of the Theora See <http://www.theora.org/>. codec. Where such parameters are encoded via the "fmtp" SDP attribute, they shall be represented in Jingle via the following format:

              @@ -244,7 +244,7 @@ ]]> -

              Upon receiving the session-initiate stanza, the responder determines whether it can proceed with the negotiation. The general Jingle error cases are specified in XEP-0166 and illustrated &xep0167;. In addition, the responder must determine if it supports any of the payload types advertised by the initiator; if it supports none of the offered payload types, it must reject the session by returning a ¬acceptable; error with a Jingle-Video-specific condition of <unsupported-codecs/>:

              +

              Upon receiving the session-initiate stanza, the responder determines whether it can proceed with the negotiation. The general Jingle error cases are specified in &xep0166; and illustrated &xep0167;. In addition, the responder must determine if it supports any of the payload types advertised by the initiator; if it supports none of the offered payload types, it must reject the session by returning a ¬acceptable; error with a Jingle-Video-specific condition of <unsupported-codecs/>:

              ]]> -

              After successful transport negotiation (for the ICE-UDP method, see XEP-0176), the responder then accepts the session:

              +

              After successful transport negotiation (for the ICE-UDP method, see &xep0176;), the responder then accepts the session:

              ]]> -

              Note: For more examples, see XEP-0167.

              +

              Note: For more examples, see &xep0167;.

               -

              The SDP media type for Jingle Video via RTP is "video" (see Section 8.2.1 of RFC 4566).

              -

              If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to a media field defined in RFC 4566. The generic format for the media field is as follows:

              +

              The SDP media type for Jingle Video via RTP is "video" (see Section 8.2.1 of &rfc4566;).

              +

              If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to a media field defined in &rfc4566;. The generic format for the media field is as follows:

              ]]> diff --git a/xep-0181.xml b/xep-0181.xml index ee6f5c5b..d04a0d8e 100644 --- a/xep-0181.xml +++ b/xep-0181.xml @@ -283,6 +283,6 @@ ]]>               -

              Thanks to Diana Cionoiu, Olivier Crête, Robert McQueen, and Paul Witty for their feedback. Several sentences were borrowed from RFC 4733.

              +

              Thanks to Diana Cionoiu, Olivier Crête, Robert McQueen, and Paul Witty for their feedback. Several sentences were borrowed from &rfc4733;.

               diff --git a/xep-0183.xml b/xep-0183.xml index 7ec344b2..9d56a9fb 100644 --- a/xep-0183.xml +++ b/xep-0183.xml @@ -45,7 +45,7 @@ -

              In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in XEP-0166. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the telepathy transport, it MUST include a &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/telepathy' namespace.

              +

              In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in &xep0166;. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the telepathy transport, it MUST include a &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/telepathy' namespace.

              This &TRANSPORT; element MUST include one and only one &CANDIDATE; element per channel specifying the parameters that the initiator believes will be most likely to succeed for that channel. (Note: You have to believe.) This is not necessarily the initiator's preferred address for spiritual communication, but instead is the "address most likely to succeed", i.e., the address that is assumed to be reachable by the vast majority of target entities. (Establishing direct spiritual communication is hard enough as it is.) Here is an example:

              @@ -74,7 +74,7 @@               -

              As described in XEP-0166, to provisionally accept the session initiation request, the receiver returns an IQ-result:

              +

              As described in &xep0166;, to provisionally accept the session initiation request, the receiver returns an IQ-result:

              ]]> @@ -96,7 +96,7 @@ ]]>

              Now the initiating entity and receiver can begin sending appropriate psychical media over the negotiated ESP stream.

              -

              In the event that the receiver cannot establish a channel, it SHOULD terminate the session (see XEP-0176 or XEP-0177 for examples).

              +

              In the event that the receiver cannot establish a channel, it SHOULD terminate the session (see &xep0176; or XEP-0177 for examples).

              Because the informational message payloads specific to the telepathy transport method cannot be tied down to the arbitrary conventions of XML syntax, a <message/> element qualified by the 'http://jabber.org/protocol/info/telepathy' namespace may include any character data that either party feels like communicating.

              diff --git a/xep-0185.xml b/xep-0185.xml index 3d017c5b..6d96d7da 100644 --- a/xep-0185.xml +++ b/xep-0185.xml @@ -69,7 +69,7 @@ -

              &rfc3920; does not specify in detail a recommended algorithm for generating the keys used in the server dialback protocol. This document provides such a recommendation as an aid to implementors of XMPP servers. This document is not meant to supersede any text in RFC 3920; however, the recommendations in this document have been incorporated into &xep0220;.

              +

              &rfc3920; does not specify in detail a recommended algorithm for generating the keys used in the server dialback protocol. This document provides such a recommendation as an aid to implementors of XMPP servers. This document is not meant to supersede any text in &rfc3920;; however, the recommendations in this document have been incorporated into &xep0220;.

              The process for generating and validating a dialback key SHOULD take into account the following four inputs:

              @@ -101,7 +101,7 @@ key = HMAC-SHA256
            -

            This document closely follows the description of the dialback protocol in RFC 3920 and XEP-0220, but omits steps that are not important for the generation and validation of the dialback keys. For ease of comparison the numbering of the steps is the same as in section 8.3 of RFC 3920 and Appendix C.3 of XEP-0220. Any line breaks in the examples are included for the purpose of readability only.

            +

            This document closely follows the description of the dialback protocol in &rfc3920; and &xep0220;, but omits steps that are not important for the generation and validation of the dialback keys. For ease of comparison the numbering of the steps is the same as in section 8.3 of RFC 3920 and Appendix C.3 of XEP-0220. Any line breaks in the examples are included for the purpose of readability only.

            The following data values are used in the examples:

            @@ -194,7 +194,7 @@ key = HMAC-SHA256( ]]> -

            This document introduces no security considerations or concerns above and beyond those discussed in RFC 3920 and XEP-0220.

            +

            This document introduces no security considerations or concerns above and beyond those discussed in &rfc3920; and &xep0220;.

            This document requires no interaction with &IANA;.

            diff --git a/xep-0186.xml b/xep-0186.xml index ea3290dc..a9c5aab8 100644 --- a/xep-0186.xml +++ b/xep-0186.xml @@ -164,7 +164,7 @@ id='d1s4pp34r2' type='result'/> ]]> -

            (Standard XMPP stanza errors apply; see RFC 6120.)

            +

            (Standard XMPP stanza errors apply; see &rfc6120;.)

            When the client enters invisible mode during a presence session (i.e., after having previously sent undirected available presence with no 'type' attribute), the server MUST send &UNAVAILABLE; from the specified resource to all contacts who would receive unavailable presence if the client itself were to send &UNAVAILABLE;.

            The following sections define server and client handling of inbound and outbound XML stanzas while the client is invisible.

            @@ -174,7 +174,7 @@

          5. MUST deliver outbound directed presence stanzas generated by the client.

          6. MUST generate or not generate outbound presence probes in accordance with the value of the 'probe' attribute.

          7. MUST deliver inbound &PRESENCE; stanzas.

            8. -

          8. SHOULD deliver inbound &MESSAGE; stanzas whose 'to' address is the bare JID &LOCALBARE; of the user (subject to standard XMPP stanza handling rules from RFC 6120 and RFC 6121).

            9. +

          9. SHOULD deliver inbound &MESSAGE; stanzas whose 'to' address is the bare JID &LOCALBARE; of the user (subject to standard XMPP stanza handling rules from &rfc6120; and RFC 6121).

          10. MUST deliver inbound &MESSAGE; and &IQ; stanzas whose 'to' address is the full JID &LOCALFULL; corresponding to the resource of the client.

          11. MUST deliver outbound &MESSAGE; and &IQ; stanzas generated by the client (for an important note regarding presence leaks, see the Security Considerations section of this document).

          12. diff --git a/xep-0188.xml b/xep-0188.xml index 1851d76b..78548c42 100644 --- a/xep-0188.xml +++ b/xep-0188.xml @@ -64,7 +64,7 @@

            Note: The protocols developed according to the cryptographic design described in this document are described in &xep0116;, &xep0217;, &xep0187; and &xep0200;. The information in those documents should be sufficient for implementors. This purely informative document is primarily for people interested in the design and analysis of those protocols.

            As specified in &rfc3920;, XMPP is an XML streaming protocol that enables the near-real-time exchange of XML fragments between any two (or more) network endpoints. To date, the main application built on top of the core XML streaming layer is instant messaging (IM) and presence, the base extensions for which are specified in &rfc3921;. There are three first-level elements of XML streams (&MESSAGE;, &PRESENCE;, and &IQ;); each of these "XML stanza" types has different semantics, which can complicate the task of defining a generalized approach to end-to-end encryption for XMPP. In addition, XML stanzas can be extended (via properly-namespaced child elements) for a wide variety of functionality.

            -

            XMPP is a session-oriented communication technology: normally, a client authenticates with a server and maintains a long-lived connection that defines the client's XMPP session. Such stream-level sessions may be secured via channel encryption using Transport Level Security (&rfc2246;), as specified in Section 5 of RFC 3920. However, there is no guarantee that all hops will implement or enforce channel encryption (or that intermediate servers are trustworthy), which makes end-to-end encryption desirable.

            +

            XMPP is a session-oriented communication technology: normally, a client authenticates with a server and maintains a long-lived connection that defines the client's XMPP session. Such stream-level sessions may be secured via channel encryption using Transport Level Security (&rfc2246;), as specified in Section 5 of &rfc3920;. However, there is no guarantee that all hops will implement or enforce channel encryption (or that intermediate servers are trustworthy), which makes end-to-end encryption desirable.

            This document specifies a method for encrypted sessions ("ESessions") that takes advantage of the inherent possibilities and strengths of session encryption as opposed to object encryption. The detailed requirements for encrypted sessions are defined in &xep0210;.

            The conceptual model for the approach specified in this document was inspired by "off-the-record" (OTR) communication, as implemented in the Gaim encryption plugin and described in &otr;. The basic concept is that of an encrypted session which acts as a secure tunnel between two endpoints. Once the tunnel is established, the content of all one-to-one XML stanzas exchanged between the endpoints will be encrypted and then transmitted within a "wrapper" protocol element.

            Note: In order to gain a thorough understanding of this document, it is recommended that the Off-the-Record Communication paper and &rfc6189; are read first.

            @@ -81,7 +81,7 @@ -

            Authenticated key-exchange is the most challenging part of the design of any secure communication protocol. The ESessions key exchange essentially translates the σLike RFC 2409, this protocol uses variant (ii), as described in Secion 5.4 of the SIGMA paper. key-exchange protocol into the syntax of XMPP. The SIGMA approach to Diffie-Hellman Key Agreement (see &rfc2631;) underpins several standard key-exchange protocols including the Internet Key Exchange (IKE) protocol versions 1 and 2 (see &rfc2409; and &rfc4306;).

            +

            Authenticated key-exchange is the most challenging part of the design of any secure communication protocol. The ESessions key exchange essentially translates the σLike &rfc2409;, this protocol uses variant (ii), as described in Secion 5.4 of the SIGMA paper. key-exchange protocol into the syntax of XMPP. The SIGMA approach to Diffie-Hellman Key Agreement (see &rfc2631;) underpins several standard key-exchange protocols including the Internet Key Exchange (IKE) protocol versions 1 and 2 (see &rfc2409; and &rfc4306;).

            Note: Although this section provides an overview of SIGMA, it is strongly recommended that the SIGMA paper is read first in order to gain a thorough understanding of this document.

            The 3-message SIGMA-I-based key exchange protects the identity of the initiator against active attacks. This SHOULD NOT be used to establish client to client sessions since the responder's identity is not protected against active attacks. However, it SHOULD be used to establish client to service (server) sessions, especially where the identity of the service is well known to third parties.

            The two 4-message SIGMA-R-based key exchanges with hash commitment defend the responder's identity against active attacks and facilitate detection of a Man in the Middle attack. They SHOULD be used to establish client to client sessions.

            diff --git a/xep-0189.xml b/xep-0189.xml index b3ebd168..e2a60645 100644 --- a/xep-0189.xml +++ b/xep-0189.xml @@ -146,7 +146,7 @@
            13. - + @@ -226,7 +226,7 @@ - +
            <end/>The UTC DateTime after which the key shall not be considered valid, formatted according to XEP-0082.The UTC DateTime after which the key shall not be considered valid, formatted according to &xep0082;.
            <jid/>
            <revocationtime/>The UTC DateTime at which the key was revoked, formatted according to XEP-0082.The UTC DateTime at which the key was revoked, formatted according to &xep0082;.

            The data that is signed MUST be the revoked public key (i.e., the XML character data of the <key/> element), the fingerprint of the revoked public key (i.e., the XML character data of the <keyprint/> element), the fingerprint of the key used to sign the revocation (i.e., the XML character data of the <revocationprint/> element), and the time of the revocation (i.e., the XML character data of the <revocationtime/> element), concatenated together with no spaces or other additional characters.

            @@ -292,7 +292,7 @@ <signtime/> - The UTC DateTime at which the key was signed, formatted according to XEP-0082. + The UTC DateTime at which the key was signed, formatted according to &xep0082;.

            The data that is signed MUST be the user's public key (i.e., the XML character data of the <key/> element), the fingerprint of the user's public key (i.e., the XML character data of the <keyprint/> element), the signer's JID (i.e., the XML character data of the <signerjid/> element), the fingerprint of the signer's key (i.e., the XML character data of the <signerprint/> element), and the time of the attestation (i.e., the XML character data of the <signtime/> element), concatenated together with no spaces or other additional characters.

            diff --git a/xep-0190.xml b/xep-0190.xml index b0cedad6..30a9a523 100644 --- a/xep-0190.xml +++ b/xep-0190.xml @@ -61,7 +61,7 @@ -

            RFC 3920 describes several ways to terminate an XML stream, but does not always make a clear statement about which to use. This can lead to faulty implementations. In particular, closing a stream that has not been in use for a while is very often achieved using a connection-timeout error, then closing the socket. This can lead to loss of data. Therefore this document proposes a practice that will avoid such data loss.

            +

            &rfc3920; describes several ways to terminate an XML stream, but does not always make a clear statement about which to use. This can lead to faulty implementations. In particular, closing a stream that has not been in use for a while is very often achieved using a connection-timeout error, then closing the socket. This can lead to loss of data. Therefore this document proposes a practice that will avoid such data loss.

            Note: The recommendation described herein has been incorporated into &rfc6120;.

             diff --git a/xep-0191.xml b/xep-0191.xml index c9b0ee2f..35b4e1f0 100644 --- a/xep-0191.xml +++ b/xep-0191.xml @@ -94,7 +94,7 @@ -

            &rfc3921; includes an XMPP protocol extension for communications blocking, which has since been moved to &xep0016;. Unfortunately, because the privacy lists extension is quite complex, it has not been widely implemented in servers and has been implemented virtually not at all in clients. This is problematic, since the ability to block communications with selected users is an important feature for an instant messaging system (and is required by &rfc2779;). However, the full power of privacy lists is not needed in order to block communications, so this document proposes a simpler blocking protocol that meets the requirement specified in RFC 2779 and can be implemented more easily in XMPP clients and servers.

            +

            &rfc3921; includes an XMPP protocol extension for communications blocking, which has since been moved to &xep0016;. Unfortunately, because the privacy lists extension is quite complex, it has not been widely implemented in servers and has been implemented virtually not at all in clients. This is problematic, since the ability to block communications with selected users is an important feature for an instant messaging system (and is required by &rfc2779;). However, the full power of privacy lists is not needed in order to block communications, so this document proposes a simpler blocking protocol that meets the requirement specified in &rfc2779; and can be implemented more easily in XMPP clients and servers.

             @@ -180,7 +180,7 @@ ]]>

            If the <block/> element does not contain at least one <item/> child element, the server MUST return a &badrequest; error. The <block/> element MAY contain more than one <item/> child. Other standard XMPP stanza errors also apply; see &xmppcore; and &xep0086;.

            -

            When the user blocks communications with a JID, the user's server MUST send unavailable presence information to the JID (but only if the JID is allowed to receive presence notifications from the user in accordance with the rules defined in RFC 3921).

            +

            When the user blocks communications with a JID, the user's server MUST send unavailable presence information to the JID (but only if the JID is allowed to receive presence notifications from the user in accordance with the rules defined in &rfc3921;).

            Once the user has blocked communications with a JID, the user's server MUST NOT deliver any XML stanzas from the JID to the user. The block remains in force until the user subsequently unblocks commmunications with the JID (i.e., the duration of the block is potentially unlimited and applies across sessions).

            If a blocked JID attempts to send a stanza to the user (i.e., an inbound stanza from the user's perspective), the user's server shall handle the stanza according to the following rules:

              @@ -228,7 +228,7 @@ ]]> -

              When the user unblocks communications with a JID, the user's server MUST send the user's current presence information to the JID (but only if the JID is allowed to receive presence notifications from the user in accordance with the rules defined in RFC 3921).

              +

              When the user unblocks communications with a JID, the user's server MUST send the user's current presence information to the JID (but only if the JID is allowed to receive presence notifications from the user in accordance with the rules defined in &rfc3921;).

              After the user has unblocked communications with a JID, the user's server MUST deliver any subsequent XML stanzas from the JID to the user.

              @@ -264,7 +264,7 @@ -

              The communications blocking protocol specified herein is intended to be a user-friendly "front end" to a subset of the functionality defined by the privacy lists protocol (XEP-0016). If a service deploys both privacy lists and the blocking command, the service MUST use the same back-end data store for both protocols. (Note: Wherever possible, this document attempts to define a protocol that is fully consistent with XEP-0016; if a particular aspect of functionality is not specified herein, the relevant text in XEP-0016 shall be taken to apply.)

              +

              The communications blocking protocol specified herein is intended to be a user-friendly "front end" to a subset of the functionality defined by the privacy lists protocol (&xep0016;). If a service deploys both privacy lists and the blocking command, the service MUST use the same back-end data store for both protocols. (Note: Wherever possible, this document attempts to define a protocol that is fully consistent with XEP-0016; if a particular aspect of functionality is not specified herein, the relevant text in XEP-0016 shall be taken to apply.)

              When implementing both XEP-0191 and XEP-0016, a service SHOULD map the blocklist to the default privacy list, where each blocked JID is represented as a privacy list item of type "jid" and action "deny". An implementation MUST NOT block communications from one of a user's resources to another, even if the user happens to define a rule that would otherwise result in that behavior. If this is done and none of the user's clients ever use the privacy lists protocol, then the blocklist will always apply. This mapping has the following implications:

              1. If all of a user's clients always use the blocking command, then the default privacy list will be equivalent to the blocklist and the default privacy list will be a kind of "virtual list" (in the sense that it is never modified directly by any of the clients).

                2. @@ -278,7 +278,7 @@ -

                Matching of JIDs as specified in the 'jid' attribute of the <item/> element SHOULD proceed in the following order (this is consistent with XEP-0016):

                +

                Matching of JIDs as specified in the 'jid' attribute of the <item/> element SHOULD proceed in the following order (this is consistent with &xep0016;):

                1. <user@domain/resource> (only that resource matches)
                2. <user@domain> (any resource matches)
                  3. @@ -288,7 +288,7 @@ -

                  If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in RFC 3920 and RFC 3921.

                  +

                  If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in &rfc3920; and RFC 3921.

                   diff --git a/xep-0192.xml b/xep-0192.xml index 0b65e309..4b4a73b1 100644 --- a/xep-0192.xml +++ b/xep-0192.xml @@ -61,7 +61,7 @@ -

                  RFC 3920 introduced the concept of stream features. Implementation experience has revealed several shortcomings in the current definition and usage of stream features:

                  +

                  &rfc3920; introduced the concept of stream features. Implementation experience has revealed several shortcomings in the current definition and usage of stream features:

                  • Because not all stream features include a mechanism for specifying that negotiation of the feature is required, servers and clients cannot know with certainty when the stream negotiation has been completed and therefore when it is acceptable to begin sending XML stanzas over the stream.
                  • The server dialback protocol does not have a stream feature associated with it.
                    • @@ -70,7 +70,7 @@

                    Note: The recommendations from this document were NOT incorporated into &rfc6120; and this document is Obsolete.

                    -

                    The XMPP stream feature for Transport Layer Security (TLS) includes a <required/> child element that can be used to indicate that negotiation of TLS must be completed before proceeding with the rest of the stream negotiation. However, as defined in RFC 3920 the remaining stream features do not include the ability to flag that negotiation of the feature is required in order to (1) proceed with the negotiation or (2) begin sending XML stanzas. Because the non-TLS features lack a required flag, it is not possible for the initiating entity to know definitively how to proceed at any given stage in the stream negotiation, and the only way for the initiating entity to know whether it may begin sending XML stanzas is to attempt to send them (the receiving entity will return a ¬authorized; stream error if not all required features have been negotiated). This state of affairs is suboptimal. Therefore, every stream feature must include the ability to flag the feature as required or not required. When the initiating entity receives a stream features element with no features containing a <required/> element, it knows thatt the receiving party will accept XML stanzas over the stream.

                    +

                    The XMPP stream feature for Transport Layer Security (TLS) includes a <required/> child element that can be used to indicate that negotiation of TLS must be completed before proceeding with the rest of the stream negotiation. However, as defined in &rfc3920; the remaining stream features do not include the ability to flag that negotiation of the feature is required in order to (1) proceed with the negotiation or (2) begin sending XML stanzas. Because the non-TLS features lack a required flag, it is not possible for the initiating entity to know definitively how to proceed at any given stage in the stream negotiation, and the only way for the initiating entity to know whether it may begin sending XML stanzas is to attempt to send them (the receiving entity will return a ¬authorized; stream error if not all required features have been negotiated). This state of affairs is suboptimal. Therefore, every stream feature must include the ability to flag the feature as required or not required. When the initiating entity receives a stream features element with no features containing a <required/> element, it knows thatt the receiving party will accept XML stanzas over the stream.

                    The following examples show a possible flow of stream negotiation between a client and a server, using the required flag for all but one of the features and following the order specified in &xep0170;. (This example is more verbose than a typical stream negotiation flow, but is provided here for the sake of completeness.)

                    ]]>                     -

                    As specified in RFC 3920, support for the server dialback protocol is currently adverised through inclusion of a dialback namespace prefix in the stream header:

                    +

                    As specified in &rfc3920;, support for the server dialback protocol is currently adverised through inclusion of a dialback namespace prefix in the stream header:

                    ]]>                     -

                    The improvements described herein do not introduce any new security concerns above and beyond those defined in RFC 3920.

                    +

                    The improvements described herein do not introduce any new security concerns above and beyond those defined in &rfc3920;.

                    No interaction with &IANA; is required as a result of this document.

                    diff --git a/xep-0193.xml b/xep-0193.xml index ff065ad9..1588d870 100644 --- a/xep-0193.xml +++ b/xep-0193.xml @@ -71,7 +71,7 @@ -

                    RFC 3920 introduced the concept of binding a resource to an XML stream (this concept superseded part of the obsolete jabber:iq:auth protocol described in &xep0078;). As defined in RFC 3920, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a daemon process that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.

                    +

                    &rfc3920; introduced the concept of binding a resource to an XML stream (this concept superseded part of the obsolete jabber:iq:auth protocol described in &xep0078;). As defined in RFC 3920, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a daemon process that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.

                    Note: The recommendations from this document were NOT incorporated into &rfc6120; and this document is Obsolete.

                     @@ -96,14 +96,14 @@ -

                    When a client binds multiple resources to the same stream, proper management of 'from' addresses is imperative. In particular, a client MUST specify a 'from' address on every stanza it sends over a stream to which it has bound multiple resources, where the 'from' address is the full JID &LOCALFULL; associated with the relevant resource. If a client does not specify a 'from' address on a stanza it sends over a stream to which it has bound multiple resources (or if it specifies as the 'from' address a full JID other than one of the bound resources), the server MUST return the stanza to the client with an <unknown-sender/> stanza error. Currently there is no <unknown-sender/> stanza defined in RFC 3920. The author will work to add such an error condition (with a type of "modify") to the document that revises RFC 3920.

                    -

                    Naturally, the existing rules from RFC 3920 regarding validation of asserted 'from' addresses still apply.

                    +

                    When a client binds multiple resources to the same stream, proper management of 'from' addresses is imperative. In particular, a client MUST specify a 'from' address on every stanza it sends over a stream to which it has bound multiple resources, where the 'from' address is the full JID &LOCALFULL; associated with the relevant resource. If a client does not specify a 'from' address on a stanza it sends over a stream to which it has bound multiple resources (or if it specifies as the 'from' address a full JID other than one of the bound resources), the server MUST return the stanza to the client with an <unknown-sender/> stanza error. Currently there is no <unknown-sender/> stanza defined in &rfc3920;. The author will work to add such an error condition (with a type of "modify") to the document that revises RFC 3920.

                    +

                    Naturally, the existing rules from &rfc3920; regarding validation of asserted 'from' addresses still apply.

                    In instant messaging and presence applications, an XMPP server manages a session on behalf of a connected client. A server MUST create and manage a separate session for each distinct resource, even if there are multiple resources associated with a given XML stream. In particular:

                    1. A server MUST consider each resource to be a distinct source of presence information, both with regard to presence notifications and with regard to presence probes.
                      2. -
                    2. A server MUST manage rosters (see RFC 3920) and &xep0016; separately for each resource.
                      3. +
                    3. A server MUST manage rosters (see &rfc3920;) and &xep0016; separately for each resource.
                                         @@ -151,7 +151,7 @@ S: ]]> -

                    If the server does not allow entities to bind multiple resources to the stream, it MUST return a ¬allowed; error as described in RFC 3920.

                    +

                    If the server does not allow entities to bind multiple resources to the stream, it MUST return a ¬allowed; error as described in &rfc3920;.

                    Now the client sends more stanzas.

                    @@ -228,7 +228,7 @@ S: ]]>                     -

                    If properly implemented, the modifications described herein do not introduce any new security concerns above and beyond those defined in RFC 3920. However, care must be taken to properly manage 'from' addresses in order to avoid the delivery of stanzas from an unintended resource (which may, for example, leak presence information).

                    +

                    If properly implemented, the modifications described herein do not introduce any new security concerns above and beyond those defined in &rfc3920;. However, care must be taken to properly manage 'from' addresses in order to avoid the delivery of stanzas from an unintended resource (which may, for example, leak presence information).

                    No interaction with &IANA; is required as a result of this document.

                    diff --git a/xep-0198.xml b/xep-0198.xml index d2a3342a..c4544f30 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -235,8 +235,8 @@
                  • Stanza Acknowledgements -- the ability to know if a stanza or series of stanzas has been received by one's peer.
                  • Stream Resumption -- the ability to quickly resume a stream that has been terminated.
                  -

                  Stream management implements these features using short XML elements at the root stream level. These elements are not "stanzas" in the XMPP sense (i.e., not &IQ;, &MESSAGE;, or &PRESENCE; stanzas as defined in RFC 6120) and are not counted or acked in stream management, since they exist for the purpose of managing stanzas themselves.

                  -

                  Stream management is used at the level of an XML stream. To check TCP connectivity underneath a given stream, it is RECOMMENDED to use whitespace keepalives (see RFC 6120), &xep0199;, or TCP keepalives. By contrast with stream management, &xep0079; and &xep0184; define acks that are sent end-to-end over multiple streams; these facilities are useful in special scenarios but are unnecessary for checking of a direct stream between two XMPP entities.

                  +

                  Stream management implements these features using short XML elements at the root stream level. These elements are not "stanzas" in the XMPP sense (i.e., not &IQ;, &MESSAGE;, or &PRESENCE; stanzas as defined in &rfc6120;) and are not counted or acked in stream management, since they exist for the purpose of managing stanzas themselves.

                  +

                  Stream management is used at the level of an XML stream. To check TCP connectivity underneath a given stream, it is RECOMMENDED to use whitespace keepalives (see &rfc6120;), &xep0199;, or TCP keepalives. By contrast with stream management, &xep0079; and &xep0184; define acks that are sent end-to-end over multiple streams; these facilities are useful in special scenarios but are unnecessary for checking of a direct stream between two XMPP entities.

                  Note: Stream Management can be used for server-to-server streams as well as for client-to-server streams. However, for convenience this specification discusses client-to-server streams only. The same principles apply to server-to-server streams.

                   @@ -274,7 +274,7 @@ ]]>

                  The <enabled/> element MAY include a 'max' attribute to specify the server's preferred maximum resumption time.

                  -

                  The <enabled/> element MAY include a 'location' attribute to specify the server's preferred IP address or hostname (optionally with a port) for reconnection, in the form specified in Section 4.9.3.19 of RFC 6120 (i.e., "domainpart:port", where IPv6 addresses are enclosed in square brackets "[...]" as described in &rfc5952;); if reconnection to that location fails, the standard XMPP connection algorithm specified in RFC 6120 applies.

                  +

                  The <enabled/> element MAY include a 'location' attribute to specify the server's preferred IP address or hostname (optionally with a port) for reconnection, in the form specified in Section 4.9.3.19 of &rfc6120; (i.e., "domainpart:port", where IPv6 addresses are enclosed in square brackets "[...]" as described in &rfc5952;); if reconnection to that location fails, the standard XMPP connection algorithm specified in RFC 6120 applies.

                  The client MUST NOT attempt to negotiate stream management until it is authenticated; i.e., it MUST NOT send an <enable/> element until after authentication (such as SASL, &xep0078; or &xep0220;) has been completed successfully.

                  For client-to-server connections, the client MUST NOT attempt to enable stream management until after it has completed Resource Binding unless it is resuming a previous session (see Resumption).

                  The server SHALL enforce this order and return a <failed/> element in response if the order is violated (see Error Handling).

                  @@ -392,7 +392,7 @@
                3. Server sends stream features, offering the SM feature.
                4. Client requests resumption of the former stream.
                -

                Note: The order of events might differ from those shown above, depending on when the server offers the SM feature, whether the client chooses STARTTLS, etc. Furthermore, in practice server-to-server streams often do not complete SASL negotiation or even TLS negotiation. The foregoing text does not modify any rules about the stream negotiation process specified in RFC 6120. However, since stream management applies to the exchange of stanzas (not any other XML elements), it makes sense for the server to offer the SM feature when it will be possible for the other party to start sending stanzas, not before. See also &xep0170;.

                +

                Note: The order of events might differ from those shown above, depending on when the server offers the SM feature, whether the client chooses STARTTLS, etc. Furthermore, in practice server-to-server streams often do not complete SASL negotiation or even TLS negotiation. The foregoing text does not modify any rules about the stream negotiation process specified in &rfc6120;. However, since stream management applies to the exchange of stanzas (not any other XML elements), it makes sense for the server to offer the SM feature when it will be possible for the other party to start sending stanzas, not before. See also &xep0170;.

                To request resumption of the former stream, the client sends a <resume/> element qualified by the 'urn:xmpp:sm:3' namespace. The <resume/> element MUST include a 'previd' attribute whose value is the SM-ID of the former stream and MUST include an 'h' attribute that identifies the sequence number of the last handled stanza sent over the former stream from the server to the client (in the unlikely case that the client never received any stanzas, it would set 'h' to zero).

                -

                If an error occurs with regard to an <enable/> or <resume/> element, the server MUST return a <failed/> element. This element SHOULD contain an error condition, which MUST be one of the stanza error conditions defined in RFC 6120.

                +

                If an error occurs with regard to an <enable/> or <resume/> element, the server MUST return a <failed/> element. This element SHOULD contain an error condition, which MUST be one of the stanza error conditions defined in &rfc6120;.

                An example follows.

                diff --git a/xep-0199.xml b/xep-0199.xml index 8ec426ec..13a92cc4 100644 --- a/xep-0199.xml +++ b/xep-0199.xml @@ -116,7 +116,7 @@ ]]> -

                The other error conditions defined in RFC 6120 could also be returned if appropriate.

                +

                The other error conditions defined in &rfc6120; could also be returned if appropriate.

                A client may also ping its server by sending an IQ-get over the stream between the two entities.

                @@ -139,7 +139,7 @@ ]]>                 -

                The other error conditions defined in RFC 6120 could also be returned if appropriate.

                +

                The other error conditions defined in &rfc6120; could also be returned if appropriate.

                Pings can also be used to test a server-to-server connection. This is done by sending an IQ-get over the stream from one server to another.

                @@ -161,7 +161,7 @@ ]]> -

                The other error conditions defined in RFC 6120 could also be returned if appropriate.

                +

                The other error conditions defined in &rfc6120; could also be returned if appropriate.

                Pings can also be used for client-to-client (i.e., end-to-end) pings.

                @@ -193,7 +193,7 @@ ]]> -

                The other error conditions defined in RFC 6120 could also be returned if appropriate.

                +

                The other error conditions defined in &rfc6120; could also be returned if appropriate.

                Pings can also be used for component-to-client pings, for example from a &xep0045; component to a client.

                @@ -213,7 +213,7 @@ id='comp1' type='result'/> ]]> -

                If the pinged entity does not support the ping namespace, RFC 6120 requires it to return a &unavailable; error:

                +

                If the pinged entity does not support the ping namespace, &rfc6120; requires it to return a &unavailable; error:

                ]]> -

                The other error conditions defined in RFC 6120 could also be returned if appropriate.

                +

                The other error conditions defined in &rfc6120; could also be returned if appropriate.

                                 @@ -259,7 +259,7 @@ -

                If a server receives a ping request directed to a full JID &LOCALFULL; associated with a registered account but there is no connected resource matching the 'to' address, RFC 6120 requires it to reply with a &unavailable; error and set the 'from' address of the IQ-error to the full JID provided in the 'to' address of the ping request. If a connected resource receives a ping request but it does not want to reveal its network availability to the sender for any reason (e.g., because the sender is not authorized to know the connected resource's availability), then it too MUST reply with a &unavailable; error. This consistency between the server response and the client response helps to prevent presence leaks.

                +

                If a server receives a ping request directed to a full JID &LOCALFULL; associated with a registered account but there is no connected resource matching the 'to' address, &rfc6120; requires it to reply with a &unavailable; error and set the 'from' address of the IQ-error to the full JID provided in the 'to' address of the ping request. If a connected resource receives a ping request but it does not want to reveal its network availability to the sender for any reason (e.g., because the sender is not authorized to know the connected resource's availability), then it too MUST reply with a &unavailable; error. This consistency between the server response and the client response helps to prevent presence leaks.

                 diff --git a/xep-0201.xml b/xep-0201.xml index 9ee969f1..1f862e71 100644 --- a/xep-0201.xml +++ b/xep-0201.xml @@ -173,7 +173,7 @@ -

                Several security considerations related to XMPP threads are described in RFC 6121.

                +

                Several security considerations related to XMPP threads are described in &rfc6121;.

                This document requires no interaction with &IANA;.

                diff --git a/xep-0202.xml b/xep-0202.xml index d9f85b55..0f0483cd 100644 --- a/xep-0202.xml +++ b/xep-0202.xml @@ -73,12 +73,12 @@

                Although the XMPP protocol extension defined in &xep0090; provides a way to discover the time at another entity, it has several limitations:

                  -

                • The 'jabber:iq:time' namespace specified in XEP-0090 requires communication of time only in UTC. While this is useful for UTC synchronization (e.g., if a client wants to synchronize with its server), it does not enable one entity to know the other entity's offset from UTC.

                  • +

                • The 'jabber:iq:time' namespace specified in &xep0090; requires communication of time only in UTC. While this is useful for UTC synchronization (e.g., if a client wants to synchronize with its server), it does not enable one entity to know the other entity's offset from UTC.

                • The timezone may be specified in a natural language (English) name via the <tz/> element, but not in a numeric offest. The name may be not understood by the requesting entity since there is no reliable and canonical list of timezone names A list of English-language time zone names and abbreviations is located at <http://www.timeanddate.com/library/abbreviations/timezones/>, but it is not a canonical list and there are no such localized lists for all languages. and in practice the XML character data of the <tx/> element is effectively useless.

                • The responding entity may provide a user-friendly datetime format via the <display/> element, but this too is effectively useless since datetime formats vary widely by culture and nation.

                  • -

                • The 'jabber:iq:time' namespace specified in XEP-0090 (first developed in 1999 or 2000) is not consistent with the recommended date and time profiles for XMPP protocols defined in &xep0082; (written in 2003).

                  • +

                • The 'jabber:iq:time' namespace specified in &xep0090; (first developed in 1999 or 2000) is not consistent with the recommended date and time profiles for XMPP protocols defined in &xep0082; (written in 2003).

                -

                To overcome these limitations, this document defines a replacement for XEP-0090 which enables communication of an entity's UTC time and numeric time zone offset while adhering to XEP-0082.

                +

                To overcome these limitations, this document defines a replacement for &xep0090; which enables communication of an entity's UTC time and numeric time zone offset while adhering to XEP-0082.

                The protocol defined herein provides a standard way for XMPP entities to exchange information about the local time. The information is communicated in a request/response pair using an &IQ; element that contains a <time/> element qualified by the 'urn:xmpp:time' namespace. The following children of the <time/> element are defined for use in IQ stanzas of type 'result':

                @@ -90,12 +90,12 @@ <tzo/> - The entity's numeric time zone offset from UTC. The format MUST conform to the Time Zone Definition (TZD) specified in XEP-0082. + The entity's numeric time zone offset from UTC. The format MUST conform to the Time Zone Definition (TZD) specified in &xep0082;. REQUIRED <utc/> - The UTC time according to the responding entity. The format MUST conform to the dateTime profile specified in XEP-0082 and MUST be expressed in UTC. + The UTC time according to the responding entity. The format MUST conform to the dateTime profile specified in &xep0082; and MUST be expressed in UTC. REQUIRED @@ -146,8 +146,8 @@ ]]>                 -

                This protocol was designed in a way that makes migration from XEP-0090 straightforward. This document specifies a different format for the XML character data of the <utc> element (compliant with XEP-0082) and specifies a new <tzo> element for the numeric offset from UTC, while removing the formerly optional and effectively useless <display/> and <tz/> elements.

                -

                Implementations that support XEP-0090 should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in XEP-0090 for backwards compatibility until the status of that specification is changed to Obsolete.

                +

                This protocol was designed in a way that makes migration from &xep0090; straightforward. This document specifies a different format for the XML character data of the <utc> element (compliant with XEP-0082) and specifies a new <tzo> element for the numeric offset from UTC, while removing the formerly optional and effectively useless <display/> and <tz/> elements.

                +

                Implementations that support &xep0090; should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in XEP-0090 for backwards compatibility until the status of that specification is changed to Obsolete.

                Revealing an entity's numeric time zone offset may leak limited information about the entity's current location. If the entity's understanding of UTC is far off from actual UTC, revealing that discrepancy may make it possible for an attacker to send XML stanzas that appear to be in the past or future even though they are not; therefore an entity should use the Network Time Protocol (&rfc0958;) or a similar technology to stay synchronized with actual UTC.

                diff --git a/xep-0203.xml b/xep-0203.xml index 6b706cd7..2b29bb74 100644 --- a/xep-0203.xml +++ b/xep-0203.xml @@ -65,7 +65,7 @@ -

                Although the XMPP protocol extension defined in &xep0091; provides a way to communicate that an XML stanza (typically a &MESSAGE; or &PRESENCE; stanza) has been delivered with a delay, the timestamp format defined in that document does not adhere to the recommended date and time profiles for XMPP protocols defined in &xep0082;. Therefore, this document defines a replacement for XEP-0091 which enables communication of delayed delivery information while adhering to XEP-0082.

                +

                Although the XMPP protocol extension defined in &xep0091; provides a way to communicate that an XML stanza (typically a &MESSAGE; or &PRESENCE; stanza) has been delivered with a delay, the timestamp format defined in that document does not adhere to the recommended date and time profiles for XMPP protocols defined in &xep0082;. Therefore, this document defines a replacement for &xep0091; which enables communication of delayed delivery information while adhering to XEP-0082.

                The XML namespace defined herein is used to provide timestamp information about data stored for later delivery. The most common uses of this namespace are to stamp:

                @@ -88,7 +88,7 @@ stamp - The time when the XML stanza was originally sent. The format MUST adhere to the dateTime format specified in XEP-0082 and MUST be expressed in UTC. + The time when the XML stanza was originally sent. The format MUST adhere to the dateTime format specified in &xep0082; and MUST be expressed in UTC. REQUIRED @@ -140,8 +140,8 @@ ]]>                 -

                This protocol was designed in a way that makes migration from XEP-0091 straightforward. All attributes present in the 'jabber:x:delay' namespace are present in the namespace defined herein. However, this document specifies a different format for the value of the <stamp> attribute (compliant with XEP-0082).

                -

                Implementations that support XEP-0091 should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in XEP-0091 for backwards compatibility until the status of that specification is changed to Obsolete.

                +

                This protocol was designed in a way that makes migration from &xep0091; straightforward. All attributes present in the 'jabber:x:delay' namespace are present in the namespace defined herein. However, this document specifies a different format for the value of the <stamp> attribute (compliant with XEP-0082).

                +

                Implementations that support &xep0091; should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in XEP-0091 for backwards compatibility until the status of that specification is changed to Obsolete.

                Delayed delivery data can expose information about the sender's presence on the network at some time in the past. However, this introduces no new vulnerabilities, since the same information would have been available in real time.

                diff --git a/xep-0205.xml b/xep-0205.xml index 9f5c8f74..5cce7285 100644 --- a/xep-0205.xml +++ b/xep-0205.xml @@ -75,7 +75,7 @@

                A key factor in the reliability and security of network infrastructure is its resilience in the face of denial of service attacks (see &rfc4732;). Although the existing network of servers and clients that communicate via the Extensible Messaging and Presence Protocol (&xmppcore;) has not yet been subject to such attacks, that is no cause for complacency. Therefore this document specifies a set of best practices that server implementations and deployments can follow in order to reduce the likelihood of denial of service attacks on the Jabber network.

                 -

                RFC 4732 defines denial of service as follows:

                +

                &rfc4732; defines denial of service as follows:

                A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work. The victim can be a network server, client or router, a network link or an entire network, an individual Internet user or a company doing business using the Internet, an Internet Service Provider (ISP), country, or any combination of or variant on these.

                The authors list a number of attacks, of which the following seem most likely against XMPP systems:

                  @@ -92,9 +92,9 @@

                  Numerous potential solutions have been suggested to deal with the threat of denial of service attacks against XMPP servers, including the following:

                  1. Limiting the number of connections that a server will accept from a given IP address at any one time. Such a limit may help to prevent automated processes from exhausting the server's resources (such as available ports or XML parser processing resources).

                    2. -

                  2. Limiting the number of connection attempts (via the TCP binding specified in RFC 6120 or via the &xep0124;) that a server will accept from a given IP address in a given time period. Such a limit may help to prevent automated processes from exhausting the server's resources (such as available ports or XML parser processing capacity).

                    3. +

                  3. Limiting the number of connection attempts (via the TCP binding specified in &rfc6120; or via the &xep0124;) that a server will accept from a given IP address in a given time period. Such a limit may help to prevent automated processes from exhausting the server's resources (such as available ports or XML parser processing capacity).

                  4. Limiting the number of authentication attempts for a given Jabber ID in a given time period. While such a limit may seem beneficial, in fact it might result in locking out the legitimate owner of a Jabber ID if a malicious entity attempts a large number of illegitimate authentication attempts for the Jabber ID; therefore such a limit is not recommended except as described in Section 6.4.5 of &rfc6120;, and it is instead recommended to limit the number of connections and connection attempts on a per-IP basis.

                    5. -

                  5. Disallowing unauthenticated connections from clients and from peer servers; as mentioned below, this is required by RFC 6120.

                    6. +

                  6. Disallowing unauthenticated connections from clients and from peer servers; as mentioned below, this is required by &rfc6120;.

                  7. Limiting the number of XMPP resource identifiers allowed to an account at any one time. This may help to prevent a rogue account from creating an unlimited number of sessions and therefore exhausting the resources of the server's session manager.

                  8. Limiting the absolute size in bytes of XML stanzas accepted by the server, or of particular aspects of an XML stanza (e.g., attribute values, element names, XML character data). Limits on particular aspects of an XML stanza are probably not needed, as long as it is possible to limit the absolute size of each XML stanza, since such a limit may help to prevent exhaustion of server resources (e.g., XML parser processing capacity).

                  9. Limiting the number of bytes or XML stanzas that a server will accept over a given TCP connection or for a given JabberID in a given time period. Such a limit, which helps to prevent rogue accounts or hijacked clients from flooding the server, is common in existing XMPP server implementations and often goes by the name "karma".

                    10. @@ -115,7 +115,7 @@

                    If an entity attempts to connect but the maximum number of connection attempts has been reached, the receiving server MUST NOT allow the new connection to proceed. There are no XMPP errors associated with this behavior, since it occurs at the binding (TCP or HTTP) level before an XML stream is initiated.

                    -

                    In accordance with RFC 6120, a server MUST NOT process XML stanzas (i.e., &MESSAGE;, &PRESENCE;, or &IQ;) from clients that have not yet provided appropriate authentication credentials, and MUST NOT process XML stanzas from peer servers whose identity it has not either authenticated via SASL (see &rfc4422;) or verified via server dialback.

                    +

                    In accordance with &rfc6120;, a server MUST NOT process XML stanzas (i.e., &MESSAGE;, &PRESENCE;, or &IQ;) from clients that have not yet provided appropriate authentication credentials, and MUST NOT process XML stanzas from peer servers whose identity it has not either authenticated via SASL (see &rfc4422;) or verified via server dialback.

                    A server implementation SHOULD enable a server administrator to limit the number of resources it will allow an account to bind at any one time.

                    @@ -181,7 +181,7 @@
            -

            An implementation of a service that enables traffic amplification (e.g., multi-user chat or publish-subscribe) SHOULD enable an administrator of that service to limit (based on JabberID or other characteristics) what entities may send information through the service. (See XEP-0045 regarding methods of banning users from multi-user chat rooms and XEP-0060 regarding methods for prohibiting users from interacting with publish-subscribe nodes.)

            +

            An implementation of a service that enables traffic amplification (e.g., multi-user chat or publish-subscribe) SHOULD enable an administrator of that service to limit (based on JabberID or other characteristics) what entities may send information through the service. (See &xep0045; regarding methods of banning users from multi-user chat rooms and XEP-0060 regarding methods for prohibiting users from interacting with publish-subscribe nodes.)

            In fact, the "session manager" of an XMPP presence server also acts as just such an amplifier, since presence information is broadcast to all subscribers. Any such service SHOULD enable an administrator to limit the number of stanzas sent through the service in any given period of time (presence changes in a session manager, presence changes or messages in a chatroom, published items in a pubsub service).

             diff --git a/xep-0207.xml b/xep-0207.xml index 16492682..4f34dff1 100644 --- a/xep-0207.xml +++ b/xep-0207.xml @@ -36,7 +36,7 @@

            Jabber technologies as invented by Jeremie Miller started out as a relatively lightweight XML messaging transport, but they have become unnecessarily -- even ridiculously -- bloated over the years. Formalization of the core Jabber protocols as the Extensible Messaging and Presence Protocol (XMPP) within the IETF seemed like a good idea at the time, but the extensible nature of the core protocols has tempted the developer community to extend XMPP six ways from Sunday. The result has been a plethora of different conceptual models for various extensions, such as &xep0045; for multi-user communication and &xep0050; for structured entity-to-entity request/response semantics. These different models are inelegant and unnecessary. Indeed, even the inclusion of three different basic packet types (presence, message, and IQ) in the core protocol is overkill.

            -

            We can do better. In fact, we can reduce all the communication types and styles that are currently defined within the XMPP ecosystem to one model: publish-subscribe as specified in XEP-0060.

            +

            We can do better. In fact, we can reduce all the communication types and styles that are currently defined within the XMPP ecosystem to one model: publish-subscribe as specified in &xep0060;.

            Consider:

            • It has often been observed that presence (see &xmppim;) is a form of publish-subscribe. See, for instance, <http://mail.jabber.org/pipermail/xmppwg/2003-February/000636.html>.
              • @@ -450,7 +450,7 @@ -

              Because XMPP Eventing via Pubsub simply reuses the protocol specified in XEP-0060, a separate schema is not needed.

              +

              Because XMPP Eventing via Pubsub simply reuses the protocol specified in &xep0060;, a separate schema is not needed.

               diff --git a/xep-0208.xml b/xep-0208.xml index fe9a9ba3..54385a2a 100644 --- a/xep-0208.xml +++ b/xep-0208.xml @@ -68,10 +68,10 @@

              In order to initiate a Jingle session, the initiator must determine which of the responder's XMPP resources is best for the desired application format. The following approach may be helpful to implementors:

                -

              1. If the intended responder shares presence with the initiator (see &xmppim;) and has only one available resource, the initiator SHOULD attempt to negotiate a Jingle session with that resource unless the initiator knows via &xep0030; or &xep0115; that the resource does not support Jingle and the desired application format. Naturally, instead of sending service discovery requests to every contact in a user's roster, it is more efficient to use Entity Capabilities, whereby support for Jingle and various Jingle application formats and transport methods is determined for a client version in general (rather than on a per-JID basis) and then cached. Refer to XEP-0115 for details.

                2. +

              2. If the intended responder shares presence with the initiator (see &xmppim;) and has only one available resource, the initiator SHOULD attempt to negotiate a Jingle session with that resource unless the initiator knows via &xep0030; or &xep0115; that the resource does not support Jingle and the desired application format. Naturally, instead of sending service discovery requests to every contact in a user's roster, it is more efficient to use Entity Capabilities, whereby support for Jingle and various Jingle application formats and transport methods is determined for a client version in general (rather than on a per-JID basis) and then cached. Refer to &xep0115; for details.

              3. If the intended responder shares presence with the initiator and has more than one available resource but only one of the resources supports Jingle and the desired application format, the initiator SHOULD initiate the Jingle session with that resource.

              4. If the intended responder shares presence with the initiator and has more than one available resource but more than one of the resources supports Jingle and the desired application format, the initiator SHOULD use &xep0168; in order to determine which is the best resource with which to initiate the desired Jingle session.

                5. -

              5. If the intended responder does not share presence with the initiator, the initiator SHOULD first send a &xep0155; request to the responder in order to initiate the exchange of XMPP stanzas. The request SHOULD include a RAP routing hint as specified in XEP-0168 and the &MESSAGE; stanza containing the request SHOULD be of type "headline" so that (typically) it is not stored offline for later delivery. The stanza session negotiation SHOULD result in temporary sharing of presence between the parties via the "presence" field as described in XEP-0155.

                6. +

              6. If the intended responder does not share presence with the initiator, the initiator SHOULD first send a &xep0155; request to the responder in order to initiate the exchange of XMPP stanzas. The request SHOULD include a RAP routing hint as specified in &xep0168; and the &MESSAGE; stanza containing the request SHOULD be of type "headline" so that (typically) it is not stored offline for later delivery. The stanza session negotiation SHOULD result in temporary sharing of presence between the parties via the "presence" field as described in XEP-0155.

               @@ -95,14 +95,14 @@ ]]> -

              If none of the errors specified in XEP-0166 occurs, the responder acknowledges the session initiation request.

              +

              If none of the errors specified in &xep0166; occurs, the responder acknowledges the session initiation request.

              ]]> -

              If no negotiation is required (e.g., to modify the port number or transport method), the responder simply accepts the session. (Alternatively, if the responder wants to use a port other 17777, it SHOULD negotiate the port using a Jingle content-modify action; see XEP-0166 for details and examples.)

              +

              If no negotiation is required (e.g., to modify the port number or transport method), the responder simply accepts the session. (Alternatively, if the responder wants to use a port other 17777, it SHOULD negotiate the port using a Jingle content-modify action; see &xep0166; for details and examples.)

              -

              Existing approaches to encryption of XMPP communications have generally assumed that each stanza to be encrypted is a standalone storeable object; the term "object encryption" well captures this assumption. Both &xep0027; and &rfc3923; assume that no interactive session exists, and that XMPP communications are similar to the exchange of files or email messages - where the receiver is typically not connected to its server at the time the message is sent. Although Current Jabber OpenPGP Usage uses "old-style" PGP object encryption and RFC 3923 uses "new-style" S/MIME object encryption, both specify the use of object encryption. Any new protocol based on &w3xmlenc; and &w3xmlsig;, would also be an "object encryption" protocol.

              +

              Existing approaches to encryption of XMPP communications have generally assumed that each stanza to be encrypted is a standalone storeable object; the term "object encryption" well captures this assumption. Both &xep0027; and &rfc3923; assume that no interactive session exists, and that XMPP communications are similar to the exchange of files or email messages - where the receiver is typically not connected to its server at the time the message is sent. Although Current Jabber OpenPGP Usage uses "old-style" PGP object encryption and &rfc3923; uses "new-style" S/MIME object encryption, both specify the use of object encryption. Any new protocol based on &w3xmlenc; and &w3xmlsig;, would also be an "object encryption" protocol.

              However, encryption schemes that are appropriate for less dynamic Internet technologies are not appropriate for session-oriented communication technologies like XMPP. With XMPP the receiver is typically connected to its server at the time the message is sent, so XMPP can take advantage of much more secure session-oriented approaches to encryption - approaches that are not feasible for less dynamic technologies like email. Most importantly, XMPP can benefit from Perfect Forward Secrecy and Identity Protection.

              Therefore, for XMPP, the focus should be on "session encryption" rather than "object encryption". The paradigm should be something closer to the widely-deployed Secure Shell technology (see &rfc4253;) or &rfc6189; (an acclaimed SRTP - &rfc3711; - key agreement protocol) or TLS (see &rfc5246;) or IPsec (see &rfc4301;) than to the traditional encryption of files and email messages.

              The session metaphor applies to communication between any two XMPP endpoints. For instance, in IM applications, most instant messaging exchanges occur in bursts within limited time periods (e.g., two people may send a fairly large number of messages during a five-minute chat and then not exchange messages again for hours or even days). The XML stanzas exchanged during such a session may not be limited to &MESSAGE; stanzas; for instance, the session may be triggered by a change in one of the parties' presence status (e.g., changing from away to available) and the session may involve the exchange of &IQ; stanzas (e.g., to transfer a file as specified in &xep0096;).

              diff --git a/xep-0217.xml b/xep-0217.xml index e25207bb..7035bc76 100644 --- a/xep-0217.xml +++ b/xep-0217.xml @@ -68,7 +68,7 @@               -

              Before attempting to engage in an ESession with Bob, Alice MAY discover whether he supports this protocol, using either &xep0030; or the presence-based profile of XEP-0030 specified in &xep0115;.

              +

              Before attempting to engage in an ESession with Bob, Alice MAY discover whether he supports this protocol, using either &xep0030; or the presence-based profile of &xep0030; specified in &xep0115;.

              The disco#info request sent from Alice to Bob might look as follows:

            • &xep0188;

              -

              Strictly speaking, a developer does not implement this specification, since it describes the theory behind the process of upgrading from cleartext to encryption that is defined in XEP-0116. However it is useful background knowledge for developers who implement XEP-0116.

              +

              Strictly speaking, a developer does not implement this specification, since it describes the theory behind the process of upgrading from cleartext to encryption that is defined in &xep0116;. However it is useful background knowledge for developers who implement XEP-0116.

          Naturally, when developing from the library/API level up to the client/interface level, the order should be (roughly) reversed.

          diff --git a/xep-0219.xml b/xep-0219.xml index b1832a2b..ebdfaea2 100644 --- a/xep-0219.xml +++ b/xep-0219.xml @@ -184,7 +184,7 @@
        3. If the respondent does not support the hopcheck namespace, it MUST return a &unavailable; error.
        4. If the <hopcheck/> element does not include a 'to' attribute, the respondent MUST return a &badrequest; error.
        5. If the 'to' or 'for' attribute of the <hopcheck/> element contains a JID that is malformed, the respondent MUST return a &badjid; error.
          6. -
        6. If the respondent is a server and the sender is a full JID &LOCALFULL;, the server MUST verify that the JID is a connected resource of the server (per RFC 6120); if it is not, then the respondent MUST return a &forbidden; error.
          7. +
        7. If the respondent is a server and the sender is a full JID &LOCALFULL;, the server MUST verify that the JID is a connected resource of the server (per &rfc6120;); if it is not, then the respondent MUST return a &forbidden; error.
        8. If both the sender and the respondent are servers and the domain identifier of the <hopcheck/> element's 'to' attribute does not match a validated domain of the respondent, the respondent MUST return a ¬found; error.
        9. If both the sender and the respondent are servers, the JID of the <hopcheck/> element's 'to' is a connected resource of the respondent server, and the JID of the <hopcheck/> element's 'for' is not authorized to know the presence of the target (either via presence subscription or temporary presence sharing via directed presence as defined in &xmppim;), then the respondent MUST return a &forbidden; error.
          10. diff --git a/xep-0220.xml b/xep-0220.xml index 935822b2..626d6fa7 100644 --- a/xep-0220.xml +++ b/xep-0220.xml @@ -203,7 +203,7 @@

          Since October 2000, the use of Server Dialback (even absent DNSSEC) has made it more difficult to spoof the hostnames of servers (and therefore the addresses of sent messages) on the XMPP network.

          Server Dialback is unidirectional, and results in verification for one XML stream in one direction. Because traditionally Server-to-Server connections are used unidirectionally, Server Dialback needs to be completed in each direction in order to enable bidirectional communication between two domains (unless &xep0288; is used).

          Furthermore, because a separate TCP connection is mandated for each domain pair, the use of server dialback results in significant scalability challenges for large XMPP service providers that host many domains (see &rfc7712; for a possible solution).

          -

          Finally, dialback signalling can be used without basing the identity verification on checking of the dialback key provided by the Initiating Server. As one example, if Transport Layer Security (TLS) is used then the Receiving Server can attempt to verify the certificate presented by the Initiating Server, either according to the PKIX-based rules specified in &xep0178;, RFC 6120, and &rfc6125; or by checking that the public key or certificate of the Initiating Server matches a public key or certificate obtained via &posh;. However, this technique of using dialback signalling without verifying the dialback key (sometimes called "dialback without dialing back" since the Receiving Server does not contact the Authoritative Server) is not described in this document.

          +

          Finally, dialback signalling can be used without basing the identity verification on checking of the dialback key provided by the Initiating Server. As one example, if Transport Layer Security (TLS) is used then the Receiving Server can attempt to verify the certificate presented by the Initiating Server, either according to the PKIX-based rules specified in &xep0178;, &rfc6120;, and &rfc6125; or by checking that the public key or certificate of the Initiating Server matches a public key or certificate obtained via &posh;. However, this technique of using dialback signalling without verifying the dialback key (sometimes called "dialback without dialing back" since the Receiving Server does not contact the Authoritative Server) is not described in this document.

          @@ -492,7 +492,7 @@ recv: Authorize inbound connections, i.e., act as a Receiving Server in relation to an Initiating Server; this is described under Section 2.2.1.
        10. Answer verification requests about the validity of dialback keys, i.e., act as an Authoritative Server in relation to a Receiving Server; this is described under Section 2.2.2.
        -

        Note that, unless XEP-0288 is used, the 'type' should not be set on either <db:result/> or <db:verify/> elements received on an inbound connection.

        +

        Note that, unless &xep0288; is used, the 'type' should not be set on either <db:result/> or <db:verify/> elements received on an inbound connection.

        This subsection describes the interaction between the server hosting capulet.example (acting as an Initiating Server) and the server hosting montague.net (acting as a Receiving Server), from the inbound perspective of the Receiving Server (i.e., this section is the mirror image of Section 2.1.1).

        @@ -505,7 +505,7 @@ recv:

        Before the Receiving Server allows the Initiating Server to send stanzas from the Sender Domain (here "capulet.example") to the Target Domain (here "montague.example"), it MUST verify the identity of the Initiating Server. Depending on how the server dialback protocol is used, this can be done by verifying the dialback key or by using some out-of-band method as in the POSH prooftype for XMPP domain name associations. Note that the verification process might fail prematurely, for example, if the Receiving Server's policy states that connections from the Initiating Server or the Sender Domain are not allowed.

        Note: The Receiving Server MUST continue to accept and process stanzas for already verified domain pairs, and MUST continue to process both <db:result/> and <db:verify/> elements.

        -

        If the Target Domain as given in the 'to' attribute of the element is not a configured domain of the Receiving Server, this results in a dialback error. This error, which is explained further under Section 2.4.2, is not a stream error and therefore MUST NOT result in closing of the stream as described in Section 4.4 of RFC 6120, since the stream might already be used to exchange XML stanzas for other domain pairs.

        +

        If the Target Domain as given in the 'to' attribute of the element is not a configured domain of the Receiving Server, this results in a dialback error. This error, which is explained further under Section 2.4.2, is not a stream error and therefore MUST NOT result in closing of the stream as described in Section 4.4 of &rfc6120;, since the stream might already be used to exchange XML stanzas for other domain pairs.

        ]]> -

        If the Target Domain as given in the 'to' attribute of the element does not match a configured local domain according to the Authoritative Server, this results in a dialback error. This error, which is explained further under Section 2.4, is not a stream error and therefore MUST NOT result in closing of the stream (as described in Section 4.4 of RFC 6120), since the stream might already be used for sending XML stanzas for other domain pairs. (The following example is the same as Example 8.)

        +

        If the Target Domain as given in the 'to' attribute of the element does not match a configured local domain according to the Authoritative Server, this results in a dialback error. This error, which is explained further under Section 2.4, is not a stream error and therefore MUST NOT result in closing of the stream (as described in Section 4.4 of &rfc6120;), since the stream might already be used for sending XML stanzas for other domain pairs. (The following example is the same as Example 8.)

        -

        The result of the protocol exchanges shown in the foregoing two sections is that the server hosting montague.example has verified the identity of the server hosting capulet.example. Since XMPP Server-to-Server connections are unidirectional (unless XEP-0288 is used), dialback needs to be completed in each direction before XML stanzas can be exchanged over the two TCP connections between the servers.

        +

        The result of the protocol exchanges shown in the foregoing two sections is that the server hosting montague.example has verified the identity of the server hosting capulet.example. Since XMPP Server-to-Server connections are unidirectional (unless &xep0288; is used), dialback needs to be completed in each direction before XML stanzas can be exchanged over the two TCP connections between the servers.

         -

        Support for the traditional server dialback protocol (originally specified in RFC 3920) is indicated by inclusion of the dialback namespace declaration in the stream header.

        +

        Support for the traditional server dialback protocol (originally specified in &rfc3920;) is indicated by inclusion of the dialback namespace declaration in the stream header.

        ]]> -

        Note: Although in general advertising protocol support by means of an XML namespace declaration has been superseded by the use of stream features as originally defined in RFC 3920 and updated in RFC 6120, the server dialback protocol predates the existence of stream features and therefore the namespace declaration method is still used in this instance.

        +

        Note: Although in general advertising protocol support by means of an XML namespace declaration has been superseded by the use of stream features as originally defined in &rfc3920; and updated in RFC 6120, the server dialback protocol predates the existence of stream features and therefore the namespace declaration method is still used in this instance.

        Note: It is conventional to use a namespace prefix of "db" for Server Dialback elements. Although the prefix is allowed to be other than "db" according to the XML namespaces specification (&w3xmlnamespaces;), some existing implementations and deployments might accept only the "db" prefix.

         @@ -621,8 +621,8 @@ send: -

        RFC 3920 introduced stream errors for any errors related to dialback. However, this turned out to be overly aggressive, particularly if the XML stream was used to multiplex stanzas for more than one domain pair (since closing the stream would result in throwing away accumulated dialback state for a potentially large number of domain pairs). Therefore this specification defines a third value for the 'type' attribute: "error".

        -

        This usage of the 'error' value for the 'type' attribute is not fully backward compatible with RFC 3920. However, the server that generates the error SHOULD still attempt to send the dialback error instead of terminating the stream, as the worst thing that can happen is that the remote server terminates the stream if it does not understand the error or if it eventually times out the connection. Dialback errors are to be considered non-fatal for the XML stream, but the Initiating Server MUST return queued stanzas to the respective senders with a &timeout; stanza error. If an error is encountered in Step 3 of the dialback negotiation, the Receiving Server MUST send a <remote-server-not-found/> dialback error to the Initiating Server.

        +

        &rfc3920; introduced stream errors for any errors related to dialback. However, this turned out to be overly aggressive, particularly if the XML stream was used to multiplex stanzas for more than one domain pair (since closing the stream would result in throwing away accumulated dialback state for a potentially large number of domain pairs). Therefore this specification defines a third value for the 'type' attribute: "error".

        +

        This usage of the 'error' value for the 'type' attribute is not fully backward compatible with &rfc3920;. However, the server that generates the error SHOULD still attempt to send the dialback error instead of terminating the stream, as the worst thing that can happen is that the remote server terminates the stream if it does not understand the error or if it eventually times out the connection. Dialback errors are to be considered non-fatal for the XML stream, but the Initiating Server MUST return queued stanzas to the respective senders with a &timeout; stanza error. If an error is encountered in Step 3 of the dialback negotiation, the Receiving Server MUST send a <remote-server-not-found/> dialback error to the Initiating Server.

        When the <db:verify/> or <db:result/> element is of type "error", the element MUST contain an <error/> element (implicitly qualified by the 'jabber:server' namespace), which MUST in turn contain an XML element qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace (i.e., a stanza error condition) as those errors are defined in RFC 6120. The following table provides additional guidance regarding the most relevant stanza error conditions:

        @@ -672,7 +672,7 @@ send: - +
        &constraint;The Receiving Server lacks the resources to add the requested domain pair to the list of connections authorized for this connection. The initiating server should attempt to establish a new TCP connection to the target domain using the process described in RFC 6120 and give up when receiving the same error on the new connection.The Receiving Server lacks the resources to add the requested domain pair to the list of connections authorized for this connection. The initiating server should attempt to establish a new TCP connection to the target domain using the process described in &rfc6120; and give up when receiving the same error on the new connection. Step 4
        @@ -709,7 +709,7 @@ home.montague.example. 86400 IN A 10.44.0. -

        Server Dialback helps protect against domain spoofing, thus making it difficult to spoof the origin of XML stanzas. Absent the use of DNS security (DNSSEC, RFC 4033), Server Dialback does not provide a mechanism for authenticating a stream, as is done via TLS and SASL, and results in weak verification of server identities only. Furthermore, if DNSSEC is not used then it is susceptible to DNS poisoning attacks.

        +

        Server Dialback helps protect against domain spoofing, thus making it difficult to spoof the origin of XML stanzas. Absent the use of DNS security (DNSSEC, &rfc4033;), Server Dialback does not provide a mechanism for authenticating a stream, as is done via TLS and SASL, and results in weak verification of server identities only. Furthermore, if DNSSEC is not used then it is susceptible to DNS poisoning attacks.

        If DNSSEC is used, Server Dialback provides stream authentication only (i.e., a strong association between a domain name and an XML stream). However, Server Dialback by itself does not provide confidentiality, data integrity, or stream encryption. Some existing implementations are known to support dialback over TLS. In this case, Server Dialback is typically carried out the same way as without TLS, but gains from the use of channel encryption.

        In mid-2012, several implementations turned out to be vulnerable to a number of attacks against the protocol described in this document. These attacks were based on sending verify (STEP 3) or result (STEP 4) responses without an associated request, in an unexpected direction and/or on an unexpected XML stream. Failure to reject those 'unsolicited' responses lets an attacker either spoof stanzas with an arbitrary sender domain or enables him to impersonate any target domain.

        diff --git a/xep-0221.xml b/xep-0221.xml index 8f4d4d91..45a8255d 100644 --- a/xep-0221.xml +++ b/xep-0221.xml @@ -93,7 +93,7 @@ ]]>

        The cid: URI points to data that can be retrieved using the protocol described in &xep0231; and the data element would be included along with the XMPP stanza containing the data form.

        -

        The following example is provided only for the purpose of illustration; consult the specifications for using protocols (e.g., XEP-0158) to see canonical examples.

        +

        The following example is provided only for the purpose of illustration; consult the specifications for using protocols (e.g., &xep0158;) to see canonical examples.

        [ ... ] diff --git a/xep-0222.xml b/xep-0222.xml index 9203fbf2..3f8f8112 100644 --- a/xep-0222.xml +++ b/xep-0222.xml @@ -171,16 +171,16 @@ -

        The best practices described herein re-use the concepts already defined in XEP-0060 and XEP-0163. In order to optimize for object persistence instead of transient event notifications, a node MUST be configured as follows:

        +

        The best practices described herein re-use the concepts already defined in &xep0060; and XEP-0163. In order to optimize for object persistence instead of transient event notifications, a node MUST be configured as follows:

        1. Set pubsub#persist_items to true.
        2. Set pubsub#send_last_published_item to "never".
        -

        The access model MAY be any model defined in XEP-0060.

        +

        The access model MAY be any model defined in &xep0060;.

         -

        An account owner publishes an item to a node by following the protocol specified in XEP-0060:

        +

        An account owner publishes an item to a node by following the protocol specified in &xep0060;:

        @@ -196,8 +196,8 @@ ]]> -

        If the node does not already exist, the virtual pubsub service MUST create the node. As described in XEP-0163, this "auto-create" feature (defined in XEP-0060) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in XEP-0060 before attempting to publish an item.)

        -

        In order for the client to reliably persist objects, the virtual pubsub service must also support the "publish-options" feature defined in XEP-0060. Typically, a client will publish with options so that the object is properly persisted.

        +

        If the node does not already exist, the virtual pubsub service MUST create the node. As described in &xep0163;, this "auto-create" feature (defined in XEP-0060) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in XEP-0060 before attempting to publish an item.)

        +

        In order for the client to reliably persist objects, the virtual pubsub service must also support the "publish-options" feature defined in &xep0060;. Typically, a client will publish with options so that the object is properly persisted.

        @@ -232,7 +232,7 @@ ]]> -

        If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the Receiving Event Notifications section of XEP-0163.

        +

        If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the Receiving Event Notifications section of &xep0163;.

         @@ -267,7 +267,7 @@ -

        This document introduces no security considerations above and beyond those specified in XEP-0060 and XEP-0163.

        +

        This document introduces no security considerations above and beyond those specified in &xep0060; and XEP-0163.

         diff --git a/xep-0223.xml b/xep-0223.xml index 73c988f6..acdd473f 100644 --- a/xep-0223.xml +++ b/xep-0223.xml @@ -157,7 +157,7 @@ -

        The best practices defined herein re-use the concepts already defined in XEP-0060 and XEP-0163. In order to optimize for object persistence of private information instead of transient event notifications related to semi-public data, a node MUST be configured as follows:

        +

        The best practices defined herein re-use the concepts already defined in &xep0060; and XEP-0163. In order to optimize for object persistence of private information instead of transient event notifications related to semi-public data, a node MUST be configured as follows:

        1. Set pubsub#persist_items to true.
        2. Set pubsub#access_model to "whitelist".
          3. @@ -165,7 +165,7 @@ -

          An account owner publishes an item to a node by following the protocol specified in XEP-0060:

          +

          An account owner publishes an item to a node by following the protocol specified in &xep0060;:

          @@ -183,8 +183,8 @@ ]]> -

          If the node does not already exist, the virtual pubsub service MUST create the node. As described in XEP-0163, this "auto-create" feature (defined in XEP-0060) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in XEP-0060 before attempting to publish an item.)

          -

          In order for the client to reliably persist private information, the virtual pubsub service must also support the "publish-options" feature defined in XEP-0060. Typically, a client will publish with options so that the object is privately stored.

          +

          If the node does not already exist, the virtual pubsub service MUST create the node. As described in &xep0163;, this "auto-create" feature (defined in XEP-0060) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in XEP-0060 before attempting to publish an item.)

          +

          In order for the client to reliably persist private information, the virtual pubsub service must also support the "publish-options" feature defined in &xep0060;. Typically, a client will publish with options so that the object is privately stored.

          @@ -215,7 +215,7 @@ ]]> -

          If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the Receiving Event Notifications section of XEP-0163.

          +

          If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the Receiving Event Notifications section of &xep0163;.

           @@ -252,7 +252,7 @@

          Since private data is to be stored in a mechanism originally intended to publish data, it is REQUIRED for entities to ensure that the restrictive <publish-options/> will actually be honored by the server by performing the feature discovery procedure as specified in Determining Support. If an entity using that procedure finds that the server does not support <publish-options/>, it MUST NOT store private data in PubSub, unless it can ensure privacy of the data with other means.

          The configuration of a local pubsub node does not prevent an attacker or a contact with a misconfigured node from sending pubsub events with the same payload. Therefore clients MUST verify that the ‘from’ attribute on incoming event messages is either absent or equal to their own account JID.

          -

          The Security Considerations specified in XEP-0060 and XEP-0163 need to be taken into account.

          +

          The Security Considerations specified in &xep0060; and XEP-0163 need to be taken into account.

           diff --git a/xep-0225.xml b/xep-0225.xml index 544b24e2..81d0f53a 100644 --- a/xep-0225.xml +++ b/xep-0225.xml @@ -68,7 +68,7 @@
        -

        The protocol defined in XEP-0114 depended on use of the 'to' address in the stream header to specify the hostname of the component. By contrast, client-to-server connections use stream establishment is followed by binding of a resource to the stream (in fact multiple resources can be bound to the stream). This protocol emulates client-to-server connections by using a hostname binding process that is similar to the resource binding process specified in XMPP Core.

        +

        The protocol defined in &xep0114; depended on use of the 'to' address in the stream header to specify the hostname of the component. By contrast, client-to-server connections use stream establishment is followed by binding of a resource to the stream (in fact multiple resources can be bound to the stream). This protocol emulates client-to-server connections by using a hostname binding process that is similar to the resource binding process specified in XMPP Core.

        If a server offers component binding over a stream, it MUST advertise a feature of "urn:xmpp:component:0".

        ]]> -

        If the hostname cannot be bound, the server MUST return an IQ-error, which SHOULD be &badrequest;, &conflict;, ¬allowed;, or &constraint;, just as with client resource binding as specified in RFC 3920.

        +

        If the hostname cannot be bound, the server MUST return an IQ-error, which SHOULD be &badrequest;, &conflict;, ¬allowed;, or &constraint;, just as with client resource binding as specified in &rfc3920;.

        Note: Although the JID asserted during STARTTLS and SASL negotiation MUST be of the form <domain> (i.e., an XMPP domain identifier), the <hostname/> element MAY be of the form <domain/resource>. This form can be used for application-specific functionality (e.g., load balancing), but such functionality is out of scope for this specification.

        A component can send a subsequent bind request to bind another hostname (a server MUST support binding of multiple hostnames).

        ]]>         -

        This protocol improves upon the earlier component protocol defined in XEP-0114 by specifying the use of Transport Layer Security (TLS) for channel encryption and the Simple Authentication and Security Layer (SASL) for authentication. Because this protocol re-uses the XML stream establishment processes defined in XMPP Core, the security considerations from RFC 3920 and RFC 6120 apply to this protocol as well.

        +

        This protocol improves upon the earlier component protocol defined in &xep0114; by specifying the use of Transport Layer Security (TLS) for channel encryption and the Simple Authentication and Security Layer (SASL) for authentication. Because this protocol re-uses the XML stream establishment processes defined in XMPP Core, the security considerations from RFC 3920 and RFC 6120 apply to this protocol as well.

        This document requires no interaction with &IANA;.

        diff --git a/xep-0229.xml b/xep-0229.xml index 5b304152..eb92dc58 100644 --- a/xep-0229.xml +++ b/xep-0229.xml @@ -43,7 +43,7 @@ -

        &xep0138; specifies an extensible framework for XML stream compression and defines a registry for compression methods (see &COMPRESSMETHODS;). However, XEP-0138 registers only the ZLIB method (see &rfc1950;). This document specifies usage of the LZW compression method.

        +

        &xep0138; specifies an extensible framework for XML stream compression and defines a registry for compression methods (see &COMPRESSMETHODS;). However, &xep0138; registers only the ZLIB method (see &rfc1950;). This document specifies usage of the LZW compression method.

         @@ -68,12 +68,12 @@ lzw ]]>         -

        The initiating entity and receiving entity then MUST attempt to negotiate use of the LZW algorithm in accordance with XEP-0138.

        +

        The initiating entity and receiving entity then MUST attempt to negotiate use of the LZW algorithm in accordance with &xep0138;.

        If the use of the LZW algorithm is negotiated, the usage SHOULD follow the definition in ECMA-151.

        -

        The LZW algorithm is OPTIONAL to implement for XEP-0138 implementations and this specification does not define a mandatory-to-implement technology.

        +

        The LZW algorithm is OPTIONAL to implement for &xep0138; implementations and this specification does not define a mandatory-to-implement technology.

         diff --git a/xep-0231.xml b/xep-0231.xml index bdeee2c4..355143f5 100644 --- a/xep-0231.xml +++ b/xep-0231.xml @@ -200,7 +200,7 @@

        It is RECOMMENDED for the recipient to cache data; however, the recipient MAY opt not to cache data, for example because it runs on a device that does not have sufficient space for data storage.

        The default behavior is for the recipient to cache the data only for the life of the entity's application session (not a client's presence session with the server or the controlling user's communication session with the contact from whom the user received the data); that is, the recipient would clear the cache when the application is terminated or restarted.

        -

        As a hint regarding the suggested period for caching the data, the sender MAY include a 'max-age' attribute whenever it sends a <data/> element. The meaning of the 'max-age' attribute exactly matches that of the Max-Age attribute from RFC 2965.

        +

        As a hint regarding the suggested period for caching the data, the sender MAY include a 'max-age' attribute whenever it sends a <data/> element. The meaning of the 'max-age' attribute exactly matches that of the Max-Age attribute from &rfc2965;.

        If it is not suggested to cache the data (e.g., because it is ephemeral), the value of the 'max-age' attribute MUST be "0" (the number zero).

        A recipient SHOULD cache data based on the hash of the data as encapsulated in the cid. However, if a hash cannot be extracted from the cid, if the recipient does not support the hashing algorithm used, or the recipient does not support hashes, then the recipient SHOULD cache based on the JID of the sender.

         diff --git a/xep-0232.xml b/xep-0232.xml index c6b56a93..ee2aaf9d 100644 --- a/xep-0232.xml +++ b/xep-0232.xml @@ -62,7 +62,7 @@ -

        &xep0128; defines a way for an XMPP entity to include extended information in its responses to &xep0030; information requests. This document specifies a usage of XEP-0128 whereby an XMPP entity can provide detailed data about itself in such responses. This protocol is intended to replace &xep0092; for software information discovery (thus reducing or eliminating the need for distinct software version requests) and also provides a format that can be encapsulated into &xep0115; notifications.

        +

        &xep0128; defines a way for an XMPP entity to include extended information in its responses to &xep0030; information requests. This document specifies a usage of &xep0128; whereby an XMPP entity can provide detailed data about itself in such responses. This protocol is intended to replace &xep0092; for software information discovery (thus reducing or eliminating the need for distinct software version requests) and also provides a format that can be encapsulated into &xep0115; notifications.

         @@ -137,7 +137,7 @@

        The ®ISTRAR; shall include the following information in its registries.

        -

        &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and XEP-0128 describes how to use field standardization in the context of service discovery. This section registers fields for software information scoped by the "urn:xmpp:dataforms:softwareinfo" FORM_TYPE.

        +

        &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and &xep0128; describes how to use field standardization in the context of service discovery. This section registers fields for software information scoped by the "urn:xmpp:dataforms:softwareinfo" FORM_TYPE.

        urn:xmpp:dataforms:softwareinfo diff --git a/xep-0233.xml b/xep-0233.xml index 0931cd05..9e86c464 100644 --- a/xep-0233.xml +++ b/xep-0233.xml @@ -91,21 +91,21 @@

        The Kerberos Network Authentication Service (V5) is described in &rfc4120;. An application can call the Kerberos library through the Generic Security Services Application Programming Interface (GSS-API) described in &rfc4121; or the proprietary Microsoft Windows Security Service Provider Interface (SSPI).

        -

        The Simple Authentication and Security Layer or SASL (&rfc4422;) is a framework for adding authentication support to connection-based protocols. The SASL mechanism used in environments that make use of Kerberos V5 is called "GSSAPI" and is described in &rfc4752;. Note that the RFC 4121 API has a hyphen and the SASL mechanism does not.

        +

        The Simple Authentication and Security Layer or SASL (&rfc4422;) is a framework for adding authentication support to connection-based protocols. The SASL mechanism used in environments that make use of Kerberos V5 is called "GSSAPI" and is described in &rfc4752;. Note that the &rfc4121; API has a hyphen and the SASL mechanism does not.

        Before using the "GSSAPI" SASL mechanism to authenticate to an XMPP server (which is referred to as the "acceptor" in Kerberos terminology), a connecting client needs to obtain a Kerberos ticket from the Key Distribution Centre (KDC). For this the client needs to determine the Kerberos principal name of the XMPP server. This scenario was not addressed in &rfc3920; or &rfc6120;.

        This specification sets out the rules that must be followed when registering the Kerberos principal name of an XMPP server. It also details how a client can determine the hostname of the XMPP server which can then be used to construct the Kerberos principal name.

        An XMPP client will initiate a connection to the XMPP server.

        -

        The XMPP server will communicate its hostname in a child element of the <mechanisms/> element during SASL negotation, as allowed by RFC 6120 (see Section 6.3.5 and the schema for the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in Appendix A.4).

        +

        The XMPP server will communicate its hostname in a child element of the <mechanisms/> element during SASL negotation, as allowed by &rfc6120; (see Section 6.3.5 and the schema for the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in Appendix A.4).

        This child element is <hostname/> qualified by the 'urn:xmpp:domain-based-name:1' namespace. &NSNOTE;.

        The XML character data of the <hostname/> element specifies the fully-qualified name of the XMPP server. This should be used for constructing the Kerberos principal name and is independent of the usual rules that an XMPP client uses for establishing a network connection to the XMPP server which may use insecure DNS queries (also see &rfc4120;).

        When the XMPP server is implemented using GSS-API, the domain-based service name (&rfc5178;, &rfc5179;) is used as the Kerberos principal name. Domain-based service names contain a domain name in addition to a hostname. This allows naming clustered servers after the domain which they service.

        -

        The domain-based service name is mapped to the Kerberos principal name following the format specified in RFC 5179 (i.e., "service/hostname/domain@REALM") and setting the values as follows:

        +

        The domain-based service name is mapped to the Kerberos principal name following the format specified in &rfc5179; (i.e., "service/hostname/domain@REALM") and setting the values as follows:

        • The service string MUST be "xmpp".
        • The hostname string MUST be the hostname of the XMPP server, as provided by the server in the XML character data of the <hostname/> element during SASL negotiation.
          • @@ -116,7 +116,7 @@

          Microsoft Windows provides the proprietary SSPI to support the "GSSAPI" SASL mechanism. This section describes the Windows equivalent of the domain-based service name for an XMPP server.

          -

          In the Microsoft Windows environment, the concept of Service Principal Name (SPN) is used, which is specified in https://msdn.microsoft.com/en-us/library/ms677601%28v=vs.85%29.aspx. This format ("service class/host:port/service name") is similar to the one specified in RFC 5179. The SPN can be generated by setting the values as follows:

          +

          In the Microsoft Windows environment, the concept of Service Principal Name (SPN) is used, which is specified in https://msdn.microsoft.com/en-us/library/ms677601%28v=vs.85%29.aspx. This format ("service class/host:port/service name") is similar to the one specified in &rfc5179;. The SPN can be generated by setting the values as follows:

          • The service class string MUST be "xmpp".
          • The host string MUST be the hostname of the XMPP server, as provided by the server in the XML character data of the <hostname/> element during SASL negotiation.
            • @@ -151,7 +151,7 @@ -

            The communication of the XMPP server's hostname during SASL negotiation is not known to introduce new security vulnerabilities, as long as it is done after the underlying channel has been secured using Transport Layer Security (TLS; &rfc5246;) as described for XMPP in RFC 6120. For additional security considerations, refer to RFC 5178 and RFC 5179.

            +

            The communication of the XMPP server's hostname during SASL negotiation is not known to introduce new security vulnerabilities, as long as it is done after the underlying channel has been secured using Transport Layer Security (TLS; &rfc5246;) as described for XMPP in &rfc6120;. For additional security considerations, refer to RFC 5178 and RFC 5179.

             diff --git a/xep-0234.xml b/xep-0234.xml index 6e270a7f..440d3927 100644 --- a/xep-0234.xml +++ b/xep-0234.xml @@ -266,7 +266,7 @@

      To overcome these drawbacks, this specification defines a file transfer negotiation method that meets the following requirements:

        -

      • Use the session negotiation semantics from XEP-0166.

        • +

      • Use the session negotiation semantics from &xep0166;.

      • Use any reliable Jingle transport mechanism, including but not limited to:

          @@ -275,7 +275,7 @@
        • In-Band Bytestreams &xep0261;
        • -

      • Define a file description format that, unlike XEP-0096, enables hash agility (via &xep0300;).

        • +

      • Define a file description format that, unlike &xep0096;, enables hash agility (via &xep0300;).

      • Define a clear upgrade path from SI File Transfer to Jingle File Transfer.

      Note that Jingle file transfer is only as reliable as the transports on which it depends. In particular, SOCKS5 Bytestreams ("S5B") does not always result in NAT or firewall traversal. To work around that problem, this specification requires all implementations to support as a fallback mechanism In-Band Bytestreams ("IBB"), which usually results in a successful (if slow) file transfer. A more robust and adaptable option is ICE-TCP (RFC 6544); at the time of writing &xep0176; is being updated to include the ability to negotiate ICE-TCP candidates.

      @@ -303,7 +303,7 @@       -

      In accordance with Section 12 of XEP-0166, this document specifies the following information related to the Jingle File Transfer ("Jingle FT") application type:

      +

      In accordance with Section 12 of &xep0166;, this document specifies the following information related to the Jingle File Transfer ("Jingle FT") application type:

      1. The application format negotiation process is defined in the Negotiating a Jingle File Transfer Session section of this document.

      2. The semantics of the &DESCRIPTION; element are defined in the Application Format section of this document.

        3. @@ -364,7 +364,7 @@ algo='sha-1'>w0mcJylzCn+AfvuGdqkty2+KP48= ]]>         -

        The &DESCRIPTION; element is intended to be a child of a Jingle &CONTENT; element as specified in XEP-0166.

        +

        The &DESCRIPTION; element is intended to be a child of a Jingle &CONTENT; element as specified in &xep0166;.

        The child elements of the <file/> element are as follows:

        @@ -516,7 +516,7 @@ Initiator Responder id='nzu25s8' to='romeo@montague.example/dr4hcr0st3lup4c' type='result'/>]]> -

        The initiator then attempts to initiate a SOCKS5 Bytestream with the responder as described in XEP-0260 and XEP-0065. In the meantime, the responder returns a Jingle session-accept. In the session-accept message, the <file/> element MAY contain a <range/> element to indicate that the receiver also supports ranged transfers as described below under Ranged Transfers. If the responder includes a <range /> element with a limit or offset, the File Sender SHOULD respect the provided range settings.

        +

        The initiator then attempts to initiate a SOCKS5 Bytestream with the responder as described in &xep0260; and XEP-0065. In the meantime, the responder returns a Jingle session-accept. In the session-accept message, the <file/> element MAY contain a <range/> element to indicate that the receiver also supports ranged transfers as described below under Ranged Transfers. If the responder includes a <range /> element with a limit or offset, the File Sender SHOULD respect the provided range settings.

        -

        As in XEP-0096, a transfer can include only part of a file (e.g., to restart delivery of a truncated transfer session at a point other than the start of the file). This is done using the <range/> element. The usage is illustrated in the following examples.

        +

        As in &xep0096;, a transfer can include only part of a file (e.g., to restart delivery of a truncated transfer session at a point other than the start of the file). This is done using the <range/> element. The usage is illustrated in the following examples.

        Let us imagine that the parties negotiate a file transfer session using, say, In-Band Bytestreams. During the transfer, the recipient goes offline unexpectedly and IBB stanzas from the File Sender to the File Receiver begin to bounce. When the recipient comes back online, the File Sender could initiate a new Jingle session and specify that it wants to send all chunks after byte 270336 (which might be the 66th chunk of size 4096).

        -

        All implementations MUST support the Jingle In-Band Bytestreams Transport Method (XEP-0261) as a reliable method of last resort. An implementation SHOULD support other transport methods as well, especially ICE-TCP (RFC 6544) and the Jingle SOCKS5 Bytestreams Transport Method (XEP-0260).

        +

        All implementations MUST support the Jingle In-Band Bytestreams Transport Method (&xep0261;) as a reliable method of last resort. An implementation SHOULD support other transport methods as well, especially ICE-TCP (RFC 6544) and the Jingle SOCKS5 Bytestreams Transport Method (XEP-0260).

        An application MAY present transport methods in any order, except that the Jingle In-Band Bytestreams Transport Method MUST be the lowest preference.

         -

        Support for Jingle file transfer can be determined through discovery of the 'urn:xmpp:jingle:apps:file-transfer:5' namespace &VNOTE;, via either service discovery (XEP-0030) or entity capabilities (XEP-0115). If the initiator knows that the responder supports Jingle file transfer, it SHOULD first attempt negotiation using Jingle rather than Stream Initiation.

        +

        Support for Jingle file transfer can be determined through discovery of the 'urn:xmpp:jingle:apps:file-transfer:5' namespace &VNOTE;, via either service discovery (&xep0030;) or entity capabilities (XEP-0115). If the initiator knows that the responder supports Jingle file transfer, it SHOULD first attempt negotiation using Jingle rather than Stream Initiation.

                 @@ -990,9 +990,9 @@ a=file-range:1024-*]]>

        Caution needs to be exercised when using the <name/> of a file offer or request to control any interaction with a file system. For example, a malicious user could request a file with <name>/etc/passwd</name> or include file system specific control patterns such as <name>../../private.txt</name> to try and access a sensitive file outside of the set of files intended to be shared. Or a malicious user could offer a file named "/etc/passwd" to try and trick the receiver into overwriting that or other sensitive files. Therefore, implementations SHOULD escape any file system path separators in the <name/> before using that value in any file system calls.

        -

        It is RECOMMENDED for implementations to use the strongest hashing algorithm available to both parties. See XEP-0300 for further discussion.

        -

        In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the transport method being used. For example, end-to-end encryption can be negotiated over either SOCKS5 Bytestreams or In-Band Bytestreams as described in XEP-0260 and XEP-0261.

        -

        Refer to XEP-0047, XEP-0065, XEP-0096, XEP-0176, XEP-0260, XEP-0261, and RFC 6544 for related security considerations.

        +

        It is RECOMMENDED for implementations to use the strongest hashing algorithm available to both parties. See &xep0300; for further discussion.

        +

        In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the transport method being used. For example, end-to-end encryption can be negotiated over either SOCKS5 Bytestreams or In-Band Bytestreams as described in &xep0260; and XEP-0261.

        +

        Refer to &xep0047;, XEP-0065, XEP-0096, XEP-0176, XEP-0260, XEP-0261, and &rfc6544; for related security considerations.

         diff --git a/xep-0238.xml b/xep-0238.xml index 0cc526da..fcf2bb71 100644 --- a/xep-0238.xml +++ b/xep-0238.xml @@ -70,7 +70,7 @@         - + @@ -3763,7 +3763,7 @@ -

        As explained in RFC 3920 and XEP-0220, Server Dialback does not provide authentication.

        +

        As explained in &rfc3920; and &xep0220;, Server Dialback does not provide authentication.

        In the absence of out-of-band key exchange, acceptance of a self-signed certificate does not result in authentication of a peer and therefore should be followed by Server Dialback to weakly verify peer identity.

        Acceptance of a certificate issued by a trusted root CA results in some level of authentication and therefore should be followed by SASL negotiation using the EXTERNAL mechanism.

         diff --git a/xep-0241.xml b/xep-0241.xml index f46fefd8..14d728ed 100644 --- a/xep-0241.xml +++ b/xep-0241.xml @@ -39,7 +39,7 @@

        Clients SHOULD encrypt manually-archived collections (although early implementations of this protocol MAY prefer to defer encryption and decryption to later releases). Servers MUST support the manual-archiving of encrypted collections.

        Before uploading a sequence of messages to a collection, the client SHOULD select a symmetric data encryption algorithm, generate a suitable random encryption key, give the key a unique (for the user) name, encrypt the symmetric key with one of the user's public keys, and wrap the result inside one or more <EncryptedKey/> elements, as specified in &w3xmlenc;.

        -

        To ensure that all its user's clients will be able to decrypt the collection, the client SHOULD create one <EncryptedKey/> element for each of its user's public keys that are being published using &xep0189;. However, the client MUST NOT create an <EncryptedKey/> element for any public key until it has confirmed that it belongs to the user. Note: The fact that a public key is being published using XEP-0189 is not sufficient proof of ownership, since the user's server may have been compromised at some stage. The method of confirmation is beyond the scope of this document.

        +

        To ensure that all its user's clients will be able to decrypt the collection, the client SHOULD create one <EncryptedKey/> element for each of its user's public keys that are being published using &xep0189;. However, the client MUST NOT create an <EncryptedKey/> element for any public key until it has confirmed that it belongs to the user. Note: The fact that a public key is being published using &xep0189; is not sufficient proof of ownership, since the user's server may have been compromised at some stage. The method of confirmation is beyond the scope of this document.

        The client SHOULD use the symmetric key to encrypt the joined sequence of <to/>, <from/> and <note/> elements, base64 encode the resulting sequence of bytes, and wrap it inside an <EncryptedData/> element, as described in XML Encryption.

        Clients may add one or more <EncryptedData/> or <EncryptedKey/> elements to a collection using exactly the same method as for <to/>, <from/> and <note/> elements (see Uploading Messages to a Collection). One collection may contain <EncryptedData/> elements encrypted with different symmetric keys.

        When appending <EncryptedData/> elements to a collection, the client MAY reuse a symmetric Key that has already been uploaded to the collection. In this case the client SHOULD NOT resend <EncryptedKey/> elements.

        @@ -79,7 +79,7 @@ ]]>

        The <CipherData/> child of each <EncryptedData/> element contains the base64-encoded symmetric-encrypted messages. The <EncryptionMethod/> and <KeyInfo/> children specify the symmetric encryption algorithm and the name of the symmetric key used to encrypt the messages.

        -

        The <CarriedKeyName/> child of each <EncryptedKey/> element contains the name of the symmetric key it contains. The name is referenced by the <KeyName/> child of the <KeyInfo/> child of an <EncryptedData/> element. The <CipherData/> child of each <EncryptedKey/> element contains the base64-encoded public-key-encrypted symmetric key. The <EncryptionMethod/> and <KeyInfo/> children specify the public key encryption algorithm and the name of the public key used to encrypt the symmetric key. The name of the public key MAY refer to the name in the <KeyName/> child of one of the <KeyInfo/> elements that are being published using XEP-0189.

        +

        The <CarriedKeyName/> child of each <EncryptedKey/> element contains the name of the symmetric key it contains. The name is referenced by the <KeyName/> child of the <KeyInfo/> child of an <EncryptedData/> element. The <CipherData/> child of each <EncryptedKey/> element contains the base64-encoded public-key-encrypted symmetric key. The <EncryptionMethod/> and <KeyInfo/> children specify the public key encryption algorithm and the name of the public key used to encrypt the symmetric key. The name of the public key MAY refer to the name in the <KeyName/> child of one of the <KeyInfo/> elements that are being published using &xep0189;.

        @@ -144,7 +144,7 @@ ]]>

        If the server supports encryption (see Determining Server Support), it MUST encrypt all the messages that it archives automatically (including any message collections that are currently being recorded) by following exactly the same procedure as clients use when manually archiving collections (see Encryption).

        -

        The client MAY also specify one or more public keys (in addition to any public keys that the user may be publishing using XEP-0189). The server MUST use them all to encrypt all the symmetric keys it generates and add these to the collection wrapped in <EncryptedKey/> elements.

        +

        The client MAY also specify one or more public keys (in addition to any public keys that the user may be publishing using &xep0189;). The server MUST use them all to encrypt all the symmetric keys it generates and add these to the collection wrapped in <EncryptedKey/> elements.

        -

        The initiator and recipient essentially follow the process defined in RFC 6120 to establish XML streams between themselves.

        +

        The initiator and recipient essentially follow the process defined in &rfc6120; to establish XML streams between themselves.

        First, the initiator opens an XML stream to the recipient over the negotiated transport.

        ]]> -

        In accordance with RFC 6120, the initial stream header SHOULD include the 'to' and 'from' attributes. In the case of XEP-0174, these SHOULD be the username@machine-name advertised in the PTR record. In the case of Jingle XML Streams, these SHOULD be the bare JIDs &BAREJID; of the entities as communicated via XMPP.

        -

        If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in RFC 6120, then it SHOULD include the version='1.0' flag as shown in the previous example.

        +

        In accordance with &rfc6120;, the initial stream header SHOULD include the 'to' and 'from' attributes. In the case of &xep0174;, these SHOULD be the username@machine-name advertised in the PTR record. In the case of Jingle XML Streams, these SHOULD be the bare JIDs &BAREJID; of the entities as communicated via XMPP.

        +

        If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in &rfc6120;, then it SHOULD include the version='1.0' flag as shown in the previous example.

        The recipient then responds with a stream header as well:

        ]]> -

        If both the initiator and recipient included the version='1.0' flag, the recipient SHOULD also send stream features as specified in RFC 6120:

        +

        If both the initiator and recipient included the version='1.0' flag, the recipient SHOULD also send stream features as specified in &rfc6120;:

        @@ -84,7 +84,7 @@

        The mere exchange of stream headers results in an unencrypted and unauthenticated channel between the two entities. The entities SHOULD upgrade the channel to an encrypted stream using the XMPP STARTTLS command defined in &xmppcore; using &rfc5246;, optionally followed by SASL negotiation for mutual authentication (see &rfc4422;).

        -

        End-to-end XML streams can be negotiated between two XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream, such as a remote &xep0045; room), or between two remote XMPP services. Therefore, if standard X.509 certificates are used then a party to an e2e XML stream will present either a client certificate or a server certificate as appropriate. If X.509 certificates are used, they MUST at a minimum be generated and validated in accordance with the certificate guidelines guidelines provided in &rfc6120;; however, applications of end-to-end XML streams MAY define supplemental guidelines for certificate validation in the context of particular architectures, such as XEP-0174 for link-local streams and XEP-0247 for direct or mediated streams negotiated through XMPP servers.

        +

        End-to-end XML streams can be negotiated between two XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream, such as a remote &xep0045; room), or between two remote XMPP services. Therefore, if standard X.509 certificates are used then a party to an e2e XML stream will present either a client certificate or a server certificate as appropriate. If X.509 certificates are used, they MUST at a minimum be generated and validated in accordance with the certificate guidelines guidelines provided in &rfc6120;; however, applications of end-to-end XML streams MAY define supplemental guidelines for certificate validation in the context of particular architectures, such as &xep0174; for link-local streams and XEP-0247 for direct or mediated streams negotiated through XMPP servers.

        To ease the transition from the PGP-based object encryption method specified in &xep0027;, clients using TLS for e2e streams MAY use the OpenPGP TLS extension defined in &rfc5081; (if available).

        Use of other TLS extensions MAY be appropriate as well, including those defined in &rfc5246; and &rfc5054;.

         diff --git a/xep-0247.xml b/xep-0247.xml index 654a8252..e356909b 100644 --- a/xep-0247.xml +++ b/xep-0247.xml @@ -63,10 +63,10 @@

        The initiator then sends a Jingle session-initiation request to the responder. The content-type of the request specifies three things:

        1. An application type of "urn:xmpp:jingle:apps:xmlstream:0".

          2. -

        2. Options for the streaming transport method, such as In-Band Bytestreams ("IBB") as defined in XEP-0261 or SOCKS5 Bytestreams ("S5B") as defined in XEP-0260.

          3. +

        3. Options for the streaming transport method, such as In-Band Bytestreams ("IBB") as defined in &xep0261; or SOCKS5 Bytestreams ("S5B") as defined in XEP-0260.

        Note: It is STRONGLY RECOMMENDED to encrypt all end-to-end XML streams as described in Jingle-XTLS (currently located at <http://xmpp.org/extensions/inbox/jingle-xtls.html>). Those security flows are NOT described here.

        -

        In this example, the initiator is <romeo@montague.lit>, the responder is <juliet@capulet.lit>, and the initiation request specifies a transport method of "jingle-ibb" (i.e., XEP-0261).

        +

        In this example, the initiator is <romeo@montague.lit>, the responder is <juliet@capulet.lit>, and the initiation request specifies a transport method of "jingle-ibb" (i.e., &xep0261;).

        The flow is as follows.

        ]]>         -

        Note: In accordance with &xmppim;, the initial stream header SHOULD include the 'to' and 'from' attributes, which SHOULD specify the full JIDs of the clients. If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in RFC 3920, then it SHOULD include the version='1.0' flag as shown in the previous example.

        +

        Note: In accordance with &xmppim;, the initial stream header SHOULD include the 'to' and 'from' attributes, which SHOULD specify the full JIDs of the clients. If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in &rfc3920;, then it SHOULD include the version='1.0' flag as shown in the previous example.

        -

        An implementations MUST support the Jingle IBB Transport Method (XEP-0261) as a dependable method of last resort. An implementation SHOULD support other streaming transport methods as well, such as the Jingle S5B Transport Method (XEP-0260).

        +

        An implementations MUST support the Jingle IBB Transport Method (&xep0261;) as a dependable method of last resort. An implementation SHOULD support other streaming transport methods as well, such as the Jingle S5B Transport Method (XEP-0260).

        An application MAY present transport methods in any order, except that the Jingle IBB Transport Method MUST be the lowest preference.

        diff --git a/xep-0248.xml b/xep-0248.xml index f70d4f27..96d8451a 100644 --- a/xep-0248.xml +++ b/xep-0248.xml @@ -73,7 +73,7 @@

        In addition to simplifying the subscriber's usage, collection nodes also allow the owner to describe almost any type of relationship between nodes. Using various access models on different nodes the owner can also create almost any desired authorization semantics on a set of leaf nodes.

        -

        Note: Any use cases not described herein are described in XEP-0060. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in XEP-0060. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension.

        +

        Note: Any use cases not described herein are described in &xep0060;. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in XEP-0060. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension.

         @@ -311,7 +311,7 @@

        A service that implements collection nodes SHOULD allow entities to subscribe to collection nodes (subject to access models and local security policies).

        -

        In addition to the subscription configuration options already defined in XEP-0060, there are two subscription configuration options specific to collection nodes:

        +

        In addition to the subscription configuration options already defined in &xep0060;, there are two subscription configuration options specific to collection nodes:

        • pubsub#subscription_type

          @@ -575,7 +575,7 @@ -

          In addition to the node configuration options specified in XEP-0060, there are three additional node configuration options that a service which supports collection nodes MUST supply.

          +

          In addition to the node configuration options specified in &xep0060;, there are three additional node configuration options that a service which supports collection nodes MUST supply.

          • pubsub#node_type @@ -947,7 +947,7 @@ -

            Note: These options are in addition to the standard options described in XEP-0060 and related XEPs.

            +

            Note: These options are in addition to the standard options described in &xep0060; and related XEPs.

            -

            &xep0045; defines a protocol for groupchat over XMPP. That specification includes a method for inviting a contact to a room, where the invitation is mediated by the room itself: the user sends the invitation to the room, which in turn sends it to the contact. Unfortunately, a mediated invitation might not be delivered to the contact, for example if the contact blocks communication with entities not in its roster as specified in &xep0016;. As privacy lists have become more common, MUC invitations have been increasingly blocked at the server side, resulting in an undesirable user experience. Therefore, this specification defines a method for sending an invitation directly from the user to the contact, which re-uses the original 'jabber:x:conference' namespace in use before XEP-0045 was written (with the addition of 'reason', 'continue', and 'thread' attributes for feature parity with mediated invitations).

            +

            &xep0045; defines a protocol for groupchat over XMPP. That specification includes a method for inviting a contact to a room, where the invitation is mediated by the room itself: the user sends the invitation to the room, which in turn sends it to the contact. Unfortunately, a mediated invitation might not be delivered to the contact, for example if the contact blocks communication with entities not in its roster as specified in &xep0016;. As privacy lists have become more common, MUC invitations have been increasingly blocked at the server side, resulting in an undesirable user experience. Therefore, this specification defines a method for sending an invitation directly from the user to the contact, which re-uses the original 'jabber:x:conference' namespace in use before &xep0045; was written (with the addition of 'reason', 'continue', and 'thread' attributes for feature parity with mediated invitations).

             @@ -125,7 +125,7 @@ thread='e0ffe42b28561960c6b12b944a092794b9683a38'/> ]]> -

            Upon receiving a direct invitation, the contact's client SHOULD present the invitation to the contact so that the contact can accept it or decline it. If the contact accepts the invitation, the contact's client shall join the room as described in XEP-0045. If the contact declines the invitation, it shall silently discard the invitation.

            +

            Upon receiving a direct invitation, the contact's client SHOULD present the invitation to the contact so that the contact can accept it or decline it. If the contact accepts the invitation, the contact's client shall join the room as described in &xep0045;. If the contact declines the invitation, it shall silently discard the invitation.

             @@ -153,7 +153,7 @@

            Before inviting a contact to a members-only room, a user SHOULD check to see if the contact is already a member and, if not, add the contact to the member list (or ask a room administrator to do so).

            -

            If a client receives multiple invitations to the same room (e.g., a mediated invitation as defined in XEP-0045 and a direct invitation as defined here), the client SHOULD present only one of the invitations to a human user. If a client receives an invitation to a room in which the user is already an occupant, the client SHOULD silently discard the invitation.

            +

            If a client receives multiple invitations to the same room (e.g., a mediated invitation as defined in &xep0045; and a direct invitation as defined here), the client SHOULD present only one of the invitations to a human user. If a client receives an invitation to a room in which the user is already an occupant, the client SHOULD silently discard the invitation.

             diff --git a/xep-0251.xml b/xep-0251.xml index a9cddd56..ebb1ff03 100644 --- a/xep-0251.xml +++ b/xep-0251.xml @@ -178,7 +178,7 @@ Caller Attendant Callee ]]> -

            If the caller understands the transfer request, it acknowledges the request (if not, it MUST return a &feature; error as specified in XEP-0166).

            +

            If the caller understands the transfer request, it acknowledges the request (if not, it MUST return a &feature; error as specified in &xep0166;).

            ]]> -

            If the caller understands the transfer request, it acknowledges the request (if not, it MUST return a &feature; error as specified in XEP-0166).

            +

            If the caller understands the transfer request, it acknowledges the request (if not, it MUST return a &feature; error as specified in &xep0166;).

            The cross domain security restrictions of some runtime environments permit clients to access pure XML text only if it was received from a specific server (e.g., the hostname a Web client was downloaded from). Surprisingly, the same environments typically permit clients to receive and execute scripts from any server. The Security Considerations section below describes the significant risks of deploying Script Syntax.

            To enable domain-restricted clients to use BOSH with any connection manager, this section proposes an optional alternative to the standard "BOSH Pure Syntax" defined in &xep0124;. The "BOSH Script Syntax" defined here essentially inserts each <body/> element sent by the client into an HTTP GET header instead of into the body of a POST request. Each <body/> element sent by the connection manager is wrapped inside an &ecma262; string and function call. No changes to the <body/> element or to any other aspects of the BOSH protocol are needed.

            -

            If, and only if, a client is unable to use the Pure Syntax defined in XEP-0124, then it MAY instead request the use of the Script Syntax defined herein.

            +

            If, and only if, a client is unable to use the Pure Syntax defined in &xep0124;, then it MAY instead request the use of the Script Syntax defined herein.

             @@ -97,7 +97,7 @@ Cache-Control: no-cache Pragma: no-cache Content-Length: 0 ]]> -

            Although RFC 2616 does not limit the length of HTTP URIs, the runtime environment of the client might restrict the length of the URI that it can include in each GET request. Internet Explorer versions 4.0 thru 7.0 have a maximum path length of 2048 characters and a maximum URL length of 2083 characters. Other popular browsers appear to have no limit. In these cases the client MUST reduce the content of the <body/> element accordingly and send the remaining content in subsequent HTTP GET requests wrapped in new <body/> elements (with incremented 'rid' attributes). This is possible since, unlike Pure Syntax, with Script Syntax the connection manager MUST treat the string of characters between the opening and closing <body> tags of each request as part of an octet stream instead of as a set of complete XML stanzas. The content of any one <body/> element MUST NOT be parsed in isolation from the rest of the stream.

            +

            Although &rfc2616; does not limit the length of HTTP URIs, the runtime environment of the client might restrict the length of the URI that it can include in each GET request. Internet Explorer versions 4.0 thru 7.0 have a maximum path length of 2048 characters and a maximum URL length of 2083 characters. Other popular browsers appear to have no limit. In these cases the client MUST reduce the content of the <body/> element accordingly and send the remaining content in subsequent HTTP GET requests wrapped in new <body/> elements (with incremented 'rid' attributes). This is possible since, unlike Pure Syntax, with Script Syntax the connection manager MUST treat the string of characters between the opening and closing <body> tags of each request as part of an octet stream instead of as a set of complete XML stanzas. The content of any one <body/> element MUST NOT be parsed in isolation from the rest of the stream.

            Connection managers MUST make the following changes to convert their responses to Script Syntax:

            diff --git a/xep-0253.xml b/xep-0253.xml index 7f545821..cced3e06 100644 --- a/xep-0253.xml +++ b/xep-0253.xml @@ -159,7 +159,7 @@             -

            When a chaining node delivers a notification to its subscribers, it SHOULD include an &xep0033; header of "ofrom" to specify the chained node or service that generated the notification (note: this header is not yet defined in XEP-0033).

            +

            When a chaining node delivers a notification to its subscribers, it SHOULD include an &xep0033; header of "ofrom" to specify the chained node or service that generated the notification (note: this header is not yet defined in &xep0033;).

            ]]>

            Note: The subscriber SHOULD NOT commit any pending transactions until it receives the delete notification.

            -

            If the item does not exist, the service MUST return an ¬found; error as described in XEP-0060.

            -

            If the entity that attempts to delete the item is not the subscriber that received the item, the service MUST return a &forbidden; error as described in XEP-0060.

            -

            If the item is locked by another subscriber, the service MUST return a &conflict; error (this flow is not defined in XEP-0060.

            +

            If the item does not exist, the service MUST return an ¬found; error as described in &xep0060;.

            +

            If the entity that attempts to delete the item is not the subscriber that received the item, the service MUST return a &forbidden; error as described in &xep0060;.

            +

            If the item is locked by another subscriber, the service MUST return a &conflict; error (this flow is not defined in &xep0060;.

            ]]> -

            If the subscriber that received the item attempts to delete the item but the item is no longer locked by the subscriber (e.g., because of a race condition or a lost notification), the service MUST return an &unexpected; error (this flow is not defined in XEP-0060.

            +

            If the subscriber that received the item attempts to delete the item but the item is no longer locked by the subscriber (e.g., because of a race condition or a lost notification), the service MUST return an &unexpected; error (this flow is not defined in &xep0060;.

         - + @@ -703,7 +703,7 @@ -

        The location results SHOULD be distributed means of &xep0060; or the subset thereof specified in &xep0163;. This can be done automatically by requesting the "publish" location query result format, in which case the location server will publish the results on the user's behalf. Alternatively the it can be done client side as outlined in XEP-0080.

        +

        The location results SHOULD be distributed means of &xep0060; or the subset thereof specified in &xep0163;. This can be done automatically by requesting the "publish" location query result format, in which case the location server will publish the results on the user's behalf. Alternatively the it can be done client side as outlined in &xep0080;.

         @@ -906,7 +906,7 @@ ]]>         -

        Note: the schema for the location results is given by XEP-0080.

        +

        Note: the schema for the location results is given by &xep0080;.

        diff --git a/xep-0259.xml b/xep-0259.xml index 379f90af..ff0ae586 100644 --- a/xep-0259.xml +++ b/xep-0259.xml @@ -97,7 +97,7 @@ ]]> -

        Clients that support this protocol MUST support XEP-0115, and MUST add the +

        Clients that support this protocol MUST support &xep0115;, and MUST add the 'urn:xmpp:tmp:mine:0' feature to their entity capabilities, in order to allow for potential server optimizations.

        -

        &xep0166; defines a framework for negotiating and managing data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor application formats, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data exchanges between XMPP entities using the existing SOCKS5 Bytestreams (S5B) protocol specified in &xep0065;. This "jingle-s5b" method results in a streaming transport method suitable for use in Jingle application types where packet loss cannot be tolerated (e.g., file transfer). Jingle-S5B reuses the protocol flow from XEP-0065 for the communication with a SOCKS5 streamhost; the communication between two clients to negotiate the possible candidates differs from XEP-0065 and shares similarities with &xep0176;

        +

        &xep0166; defines a framework for negotiating and managing data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor application formats, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data exchanges between XMPP entities using the existing SOCKS5 Bytestreams (S5B) protocol specified in &xep0065;. This "jingle-s5b" method results in a streaming transport method suitable for use in Jingle application types where packet loss cannot be tolerated (e.g., file transfer). Jingle-S5B reuses the protocol flow from &xep0065; for the communication with a SOCKS5 streamhost; the communication between two clients to negotiate the possible candidates differs from XEP-0065 and shares similarities with &xep0176;

         @@ -180,12 +180,12 @@ Initiator Responder

        If the client knows it is behind a NAT and the router announces UPnP IGD or NAT-PMP support, the client SHOULD map the open port to the external interface of the router and include the public IP address and port information in the <candidate/> offers. To increase the chance of success without using a proxy, this specification encourages the responder to also send offers, effectively equivalent to the "fast-mode" for SOCKS5 Bytestreams as previously described at <http://delta.affinix.com/specs/stream.html>.

         -

        Once the initiator has a set of candidates, it sends a Jingle session-initiate request that contains one or more transport candidates which are a mixture of XEP-0065 streamhosts and ICE candidates used in XEP-0176.

        -

        Just as with the &QUERY; element from XEP-0065, here the <transport/> element contains the candidates. The following rules apply to the defined attributes of the <transport/> element when sent by the initiator in a Jingle session-initate message:

        +

        Once the initiator has a set of candidates, it sends a Jingle session-initiate request that contains one or more transport candidates which are a mixture of &xep0065; streamhosts and ICE candidates used in XEP-0176.

        +

        Just as with the &QUERY; element from &xep0065;, here the <transport/> element contains the candidates. The following rules apply to the defined attributes of the <transport/> element when sent by the initiator in a Jingle session-initate message:

        1. The 'sid' attribute MUST be included. This attribute specifies the Stream ID for this bytestream.
          2. -
        2. The 'dstaddr' attribute SHOULD be included if the initiator includes at least one candidate of the "proxy" type. This attribute enables the initiator to communicate the value it has calculated for the SOCKS5 DST.ADDR field (see Section 5.3.2 and Section 7 of XEP-0065) so that the responder can provide an accurate value to the proxy during SOCKS5 negotiation. Here the value is calculated as SHA1(SID + Initiator JID + Responder JID) since the initiator will be the entity that activates the bytestream at the proxy. In XEP-0065, the DST.ADDR is always calculated as SHA1(SID + Requester JID + Target JID); in XEP-0260 the Jingle "initiator" is the SOCKS5 Bytestreams "requester" and the Jingle "responder" is the SOCKS5 Bytestreams "target", so for proxy candidates sent from the initiator/requester to the responder/target the DST.ADDR is calculated as SHA1(SID + Initiator JID + Responder JID). Note well that the calcuation for proxy candidates sent from the responder/target to the initiator/requester is SHA1(SID + Responder JID + Initiator JID); this scenario is not covered by XEP-0065 since in that specification only the SOCKS5 Bytestreams "requester" provides candidates.
          3. -
        3. The 'mode' attribute MAY be included. This attribute specifies whether the underlying transport for the bytestream will be TCP (a value of "tcp", which is the default) or UDP (a value of "udp", see Section 8 of XEP-0065).
          4. +
        4. The 'dstaddr' attribute SHOULD be included if the initiator includes at least one candidate of the "proxy" type. This attribute enables the initiator to communicate the value it has calculated for the SOCKS5 DST.ADDR field (see Section 5.3.2 and Section 7 of &xep0065;) so that the responder can provide an accurate value to the proxy during SOCKS5 negotiation. Here the value is calculated as SHA1(SID + Initiator JID + Responder JID) since the initiator will be the entity that activates the bytestream at the proxy. In XEP-0065, the DST.ADDR is always calculated as SHA1(SID + Requester JID + Target JID); in XEP-0260 the Jingle "initiator" is the SOCKS5 Bytestreams "requester" and the Jingle "responder" is the SOCKS5 Bytestreams "target", so for proxy candidates sent from the initiator/requester to the responder/target the DST.ADDR is calculated as SHA1(SID + Initiator JID + Responder JID). Note well that the calcuation for proxy candidates sent from the responder/target to the initiator/requester is SHA1(SID + Responder JID + Initiator JID); this scenario is not covered by XEP-0065 since in that specification only the SOCKS5 Bytestreams "requester" provides candidates.
          5. +
        5. The 'mode' attribute MAY be included. This attribute specifies whether the underlying transport for the bytestream will be TCP (a value of "tcp", which is the default) or UDP (a value of "udp", see Section 8 of &xep0065;).

        In the following example, Romeo's client has two interfaces, one on port 5086 and the other on port 5087. The provided candidates are the IPv4 address of one interface, the IPv4 address of the second interface, and a proxy address at streamer.shakespeare.lit. Because Romeo's client has included a proxy candidate, it includes its computed value for the DST.ADDR field in the 'dstaddr' attribute (here computed as the SHA-1 hash of "vj3hs98yromeo@montague.lit/orchardjuliet@capulet.lit/balcony").

        The following rules apply to the defined attributes of the <transport/> element when sent by the responder in a Jingle session-accept message:

        1. The 'sid' attribute MUST be included and MUST be the same Stream ID communicated by the initiator in the Jingle session-initiate message.
          2. -
        2. The 'dstaddr' attribute SHOULD be included if the responder includes at least one candidate of the "proxy" type. This attribute enables the responder to communicate the value it has calculated for the SOCKS5 DST.ADDR field (see Section 5.3.2 and Section 7 of XEP-0065) so that the initiator can provide an accurate value to the proxy during SOCKS5 negotiation. Here the value is calculated as SHA1(SID + Responder JID + Initiator JID) since the responder will be the entity that activates the bytestream at the proxy. As noted, the calculation for proxy candidates sent from the responder/target to the initiator/requester is SHA1(SID + Responder JID + Initiator JID); this scenario is not covered by XEP-0065 since in that specification only the SOCKS5 Bytestreams "requester" provides candidates.
          3. +
        3. The 'dstaddr' attribute SHOULD be included if the responder includes at least one candidate of the "proxy" type. This attribute enables the responder to communicate the value it has calculated for the SOCKS5 DST.ADDR field (see Section 5.3.2 and Section 7 of &xep0065;) so that the initiator can provide an accurate value to the proxy during SOCKS5 negotiation. Here the value is calculated as SHA1(SID + Responder JID + Initiator JID) since the responder will be the entity that activates the bytestream at the proxy. As noted, the calculation for proxy candidates sent from the responder/target to the initiator/requester is SHA1(SID + Responder JID + Initiator JID); this scenario is not covered by XEP-0065 since in that specification only the SOCKS5 Bytestreams "requester" provides candidates.
        4. The 'mode' attribute MUST NOT be included since the underlying transport for the bytestream is determined by the initiator.

        In the following example, Juliet's client opens one port. The provided candidates are the (private) IPv4 address of the interface, a (public) IPv6 address, the public IPv4 address created by mapping the private IP address/port using NAT-PMP, and a proxy address. Because Juliet's client has included a proxy candidate, it includes its computed value for the DST.ADDR field in the 'dstaddr' attribute (here computed as the SHA-1 hash of "vj3hs98yjuliet@capulet.lit/balconyromeo@montague.lit/orchard").

        @@ -327,7 +327,7 @@ priority = (2^16)*(type preference) + (local preference)

        The local preference is used to rate different candidates of the same type, e.g. a DSL link might be preferred over a VPN connection. The value of the local preference SHOULD be between 0 and 65535. The proposed values are only guidelines. If a client wants to increase or decrease the value of a specific candidate it is free to do so. For instance, a client might have an expensive UMTS link as a last resort and might rate this link lower than all SOCKS5 relays.

         -

        After receiving its peer's candidates, a client start to connect to them in order of the priority. A detailed description of the protocol can be found in XEP-0065.

        +

        After receiving its peer's candidates, a client start to connect to them in order of the priority. A detailed description of the protocol can be found in &xep0065;.

        Once one client has successfully created a connection, it sends the <candidate-used/> element to the peer inside a Jingle transport-info message. If a client receives a candidate-used notification it SHOULD continue trying to connect to candidates sent by its peer if it has not tried all candidates with a higher priority than the one successfully used by the peer.

        If both parties send a candidate-error notification then the SOCKS5 negotiation has failed and the parties need to fall back to some other transport method, typically (but not necessarily) IBB; see the Fallback Methods section of this document for details.
      3. If one of the parties sends a candidate-error notification and the other party sends a candidate-used notification, then the candidate-used shall be considered the nominated candidate.
      4. If both parties send a candidate-used notification but the candidates have a different priority, then the candidate with the higher priority shall be considered the nominated candidate.
        5. -
      5. If both parties send a candidate-used notification with candidates having the same priority, then the candidate chosen by the initiator shall be considered the nominated candidate (this is consistent with the rules in XEP-0166).
        6. +
      6. If both parties send a candidate-used notification with candidates having the same priority, then the candidate chosen by the initiator shall be considered the nominated candidate (this is consistent with the rules in &xep0166;).

        7. The parties shall use the nominated candidate for the data transfer. However, if the nominated candidate is of the "proxy" type, then the peer has no way to know when it can send data. Therefore the party that offered the nominated candidate MUST do two things...

        -

        First, it activates the bytestream, as described in XEP-0065:

        +

        First, it activates the bytestream, as described in &xep0065;:

        The parties shall then consider the bytestream unsuccessful and SHOULD attempt to fall back to another transport as described in Fallback Methods.

         -

        Once the parties have chosen (and if necessary activated) a streamhost, they can exchange data as defined in XEP-0065.

        +

        Once the parties have chosen (and if necessary activated) a streamhost, they can exchange data as defined in &xep0065;.

        Once the parties have finished using the bytestream (e.g., because a complete file has been sent), either party can send a Jingle session-terminate action.

        @@ -557,11 +557,11 @@ Romeo Juliet to='romeo@montague.lit/orchard' type='result'/> ]]> -

        Now the parties can send data using In-Band Bytestreams as defined in XEP-0261 and XEP-0047.

        +

        Now the parties can send data using In-Band Bytestreams as defined in &xep0261; and XEP-0047.

        -

        The same processing rules and usage guidelines defined in XEP-0065 apply to the Jingle S5B Transport Method. This document adds the following implementation suggestions in the context of Jingle:

        +

        The same processing rules and usage guidelines defined in &xep0065; apply to the Jingle S5B Transport Method. This document adds the following implementation suggestions in the context of Jingle:

        1. Try the offered candidates in the order of their priority, from highest to lowest.
        2. Stagger the connection attempts (e.g., initiate communications with the highest-priority candidate, then wait 200ms before initiating communications with the second-highest-priority candidate).
          3. @@ -598,7 +598,7 @@ Romeo Juliet

          The exchange of candidates might result in exposure of the sender's IP addresses, which comprise a form of personally identifying information. A Jingle client MUST enable a user to control which entities will be allowed to receive such information. If a human user explicitly accepts a session request, then the client can consider that action to imply approval of IP address sharing.

          -

          This specification, like XEP-0065 before it, does not directly support end-to-end encryption of the media sent over the transport.

          +

          This specification, like &xep0065; before it, does not directly support end-to-end encryption of the media sent over the transport.

           diff --git a/xep-0261.xml b/xep-0261.xml index 1cc560ea..ab88a821 100644 --- a/xep-0261.xml +++ b/xep-0261.xml @@ -96,7 +96,7 @@

          &xep0166; defines a framework for negotiating and managing data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor application formats, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data exchanges between XMPP entities using the existing In-Band Bytestreams (IBB) protocol specified in &xep0047;. This "jingle-ibb" method results in a streaming transport method suitable for use in Jingle application types where packet loss cannot be tolerated (e.g., file transfer); however, because the "jingle-ibb" transport method sends data over the XMPP channel itself (albeit not the Jingle signalling channel), it is intended as a transport of last resort when other streaming transports (e.g., &xep0260;) cannot be negotiated.

          -

          The approach taken in this specification is to use the existing IBB mechanisms described in XEP-0047 for transporting the data, and to define Jingle-specific methods only to start and end the in-band bytestream.

          +

          The approach taken in this specification is to use the existing IBB mechanisms described in &xep0047; for transporting the data, and to define Jingle-specific methods only to start and end the in-band bytestream.

           @@ -154,7 +154,7 @@ Initiator Responder ]]> -

          Note: The default value of the 'stanza' attribute is "iq", signifying use of &IQ; stanzas for data exchange; a value of "message" signifies that &MESSAGE; stanzas are to be used for data exchange. See XEP-0047 for further discussion regarding use of these stanza types for data exchange.

          +

          Note: The default value of the 'stanza' attribute is "iq", signifying use of &IQ; stanzas for data exchange; a value of "message" signifies that &MESSAGE; stanzas are to be used for data exchange. See &xep0047; for further discussion regarding use of these stanza types for data exchange.

          The responder immediately acknowledges receipt (but does not yet accept the session).

          ]]> -

          In essence, the foregoing Jingle negotiation replaces the <open/> element from XEP-0047. However, to provide consistent layering of Jingle on top of IBB (thus enabling separation of existing IBB code from new Jingle code), the initiator now MUST also send the <open/> element, with the same 'block-size' and 'sid' values as for the Jingle <transport/> element it negotiated with the recipient (i.e., if the recipient sent a modified <transport/> element element containing a different block size, the initiator MUST use the negotiated values). This adds a roundtrip to the negotiation and could be considered a "no-op", but the extra roundtrip is inconsequential given that the parties will be exchanging base64-encoded data in-band.

          +

          In essence, the foregoing Jingle negotiation replaces the <open/> element from &xep0047;. However, to provide consistent layering of Jingle on top of IBB (thus enabling separation of existing IBB code from new Jingle code), the initiator now MUST also send the <open/> element, with the same 'block-size' and 'sid' values as for the Jingle <transport/> element it negotiated with the recipient (i.e., if the recipient sent a modified <transport/> element element containing a different block size, the initiator MUST use the negotiated values). This adds a roundtrip to the negotiation and could be considered a "no-op", but the extra roundtrip is inconsequential given that the parties will be exchanging base64-encoded data in-band.

          ]]> -

          However, one of the errors described in XEP-0047 might occur; in particular, if the value of the IBB 'block-size' attribute sent by the initiator in the <open/> element does not match the value of the 'block-size' attribute communicated by the responder in the Jingle session-accept message then the responder SHOULD return a &constraint; error as described in XEP-0047.

          +

          However, one of the errors described in &xep0047; might occur; in particular, if the value of the IBB 'block-size' attribute sent by the initiator in the <open/> element does not match the value of the 'block-size' attribute communicated by the responder in the Jingle session-accept message then the responder SHOULD return a &constraint; error as described in XEP-0047.

          -

          Now the initiator can begin sending IBB packets using an IQ-set for each chunk as described in XEP-0047, where the responder will acknowledge each IQ-set in accordance with &xmppcore;.

          +

          Now the initiator can begin sending IBB packets using an IQ-set for each chunk as described in &xep0047;, where the responder will acknowledge each IQ-set in accordance with &xmppcore;.

          -

          As IBB is defined in XEP-0047, there is one session per bytestream (which can be used in both directions). However, because Jingle-IBB provides a management layer on top of IBB, it can be used to run multiple IBB sessions over a single bytestream. This can be done by sending a transport-info message that authorizes an additional session, as shown in the following example (although this example shows the initiator adding a session, the responder could just as well do so).

          +

          As IBB is defined in &xep0047;, there is one session per bytestream (which can be used in both directions). However, because Jingle-IBB provides a management layer on top of IBB, it can be used to run multiple IBB sessions over a single bytestream. This can be done by sending a transport-info message that authorizes an additional session, as shown in the following example (although this example shows the initiator adding a session, the responder could just as well do so).

          ]]> -

          The parties can then exchange data over the second session (see XEP-0047).

          -

          If a party wishes to close one session within a bytestream, it sends an IBB <close/> element as defined in XEP-0047 specifying the appropriate IBB SessionID.

          +

          The parties can then exchange data over the second session (see &xep0047;).

          +

          If a party wishes to close one session within a bytestream, it sends an IBB <close/> element as defined in &xep0047; specifying the appropriate IBB SessionID.

          Whenever a party is finished with a particular session within the bytestream, it SHOULD send an IBB <close/> as shown above. This applies to all sessions, including the last one.

          -

          To close the bytestream itself (e.g., because the parties have finished using all sessions associated with the bytestream), a party sends a Jingle session-terminate action as defined in XEP-0166.

          +

          To close the bytestream itself (e.g., because the parties have finished using all sessions associated with the bytestream), a party sends a Jingle session-terminate action as defined in &xep0166;.

          -

          The same processing rules and usage guidelines defined in XEP-0047 apply to the Jingle IBB Transport Method.

          +

          The same processing rules and usage guidelines defined in &xep0047; apply to the Jingle IBB Transport Method.

           @@ -340,10 +340,10 @@ Initiator Responder -

          This specification, like XEP-0047 before it, does not directly support end-to-end encryption of the media sent over the transport.

          +

          This specification, like &xep0047; before it, does not directly support end-to-end encryption of the media sent over the transport.

           -

          See XEP-0047 for security considerations related to the use of Base64.

          +

          See &xep0047; for security considerations related to the use of Base64.

                     diff --git a/xep-0262.xml b/xep-0262.xml index 17b37a57..9e4f9b8d 100644 --- a/xep-0262.xml +++ b/xep-0262.xml @@ -207,7 +207,7 @@ a=zrtp-hash:1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46d           -

          Security considerations for ZRTP itself are provided in RFC 6189.

          +

          Security considerations for ZRTP itself are provided in &rfc6189;.

          XMPP stanzas such as Jingle invite messages and service discovery exchanges are not encrypted or signed. As a result, it is possible for an attacker to intercept these stanzas and modify them, thus convincing one party that the other party does not support ZRTP and therefore denying the parties an opportunity to use ZRTP. However, because the zrtp-hash is mostly advisory, the parties could still use ZRTP even if the signalling channel is compromised.

           diff --git a/xep-0266.xml b/xep-0266.xml index f048ef90..fa97705c 100644 --- a/xep-0266.xml +++ b/xep-0266.xml @@ -184,7 +184,7 @@           -

          For security considerations related to Jingle RTP sessions, refer to XEP-0167. This document introduces no new security considerations. See also the security considerations described in the relevant codec specifications.

          +

          For security considerations related to Jingle RTP sessions, refer to &xep0167;. This document introduces no new security considerations. See also the security considerations described in the relevant codec specifications.

           diff --git a/xep-0268.xml b/xep-0268.xml index 67881046..85f55b23 100644 --- a/xep-0268.xml +++ b/xep-0268.xml @@ -335,7 +335,7 @@
          • "xmpp" -- the network role of an XMPP service or core router as defined by &rfc6120; and &rfc6121;
          • "xmpp-bytestreams" -- the network role of an XMPP SOCKS5 byestreams service as defined by &xep0065;
            • -
          • "xmpp-muc" -- the network role of an XMPP multi-user chat service as defined by XEP-0045
            • +
          • "xmpp-muc" -- the network role of an XMPP multi-user chat service as defined by &xep0045;
          • "xmpp-pubsub" -- the network role of an XMPP pubsub service as defined by &xep0060;
          diff --git a/xep-0269.xml b/xep-0269.xml index df91063a..35fb7a1a 100644 --- a/xep-0269.xml +++ b/xep-0269.xml @@ -40,7 +40,7 @@

          The term "early media" refers to media that is exchanged before a responder has definitively accepted a session request generated by an initiator or before end-to-end connectivity has been established (e.g., the media could be generated by an intermediate call manager or media relay). Early media is typically used to send ringing tones and announcements, using either audio streams or Dual Tone Multi-Frequency (DTMF) events.

          -

          In Jingle, the exchange of early media is established through use of the "content-add" action. In order to match the usage specified in &rfc3959; and &rfc3960;, when adding a content definition for early media the value of the &CONTENT; element's 'disposition' attribute MUST be "early-session" for mapping to a SIP Content-Disposition header value of "early-session". This enables endpoints or intermediate gateways to apply the application server model described in RFC 3960.

          +

          In Jingle, the exchange of early media is established through use of the "content-add" action. In order to match the usage specified in &rfc3959; and &rfc3960;, when adding a content definition for early media the value of the &CONTENT; element's 'disposition' attribute MUST be "early-session" for mapping to a SIP Content-Disposition header value of "early-session". This enables endpoints or intermediate gateways to apply the application server model described in &rfc3960;.

          An entity that generates a content-add message for early media SHOULD specify the same codecs for both session media and early media (however, it is possible that the entity that generates the early media does not generate the session media, for example in the case of an intermediate gateway or application server; in this case the entity MUST use one of the codecs advertised by the initiator).

          Upon receiving a content-add message specifying the use of early media, the initiator's client SHOULD acknowledge the content-add, complete any required transport negotiation, and then send a content-accept (or content-reject) to the sender. When the responder subsequently sends a session-accept message, the acceptance MUST NOT be construed to include the content definition whose disposition is "early-session".

          In handling early media and deciding whether to generate local ringing or to play early media received from the responder or an intermediate gateway, the initiator's client SHOULD proceed as follows:

          @@ -247,7 +247,7 @@ Romeo Gateway Juliet to='romeo@montague.lit/orchard' type='result'/> ]]> -

          Because Romeo has attempted to send test media to the gateway as described in XEP-0177, he has exposed an IP/port to which the gateway can now send early media via the media relay that it hosts.

          +

          Because Romeo has attempted to send test media to the gateway as described in &xep0177;, he has exposed an IP/port to which the gateway can now send early media via the media relay that it hosts.

          Eventually, the responder sends a session-accept.

          -

          For security considerations, refer to XEP-0167.

          +

          For security considerations, refer to &xep0167;.

           diff --git a/xep-0271.xml b/xep-0271.xml index 7c5d1841..33c9bac4 100644 --- a/xep-0271.xml +++ b/xep-0271.xml @@ -114,7 +114,7 @@ xmpp:romeo@example.org?;node=foo

          An XMPP node can include any UTF-8 character.

           -

          This specification introduces no security considerations above and beyond those discussed in RFC 6120, XEP-0030, XEP-0060.

          +

          This specification introduces no security considerations above and beyond those discussed in &rfc6120;, &xep0030;, XEP-0060.

          This document requires no interaction with &IANA;.

          diff --git a/xep-0273.xml b/xep-0273.xml index 0c98d98f..46c140fb 100644 --- a/xep-0273.xml +++ b/xep-0273.xml @@ -294,7 +294,7 @@ ]]>           -

          To enable clients to cache information about supported features, a server SHOULD return &xep0115; data via stream features as described in XEP-0115.

          +

          To enable clients to cache information about supported features, a server SHOULD return &xep0115; data via stream features as described in &xep0115;.

          To enable sifting of stanzas, the client sends an IQ-set to the server containing a <sift/> child element that in turn contains an <iq/> element, a <message/> element, a <presence/> element, or some combination of those elements. Each of these elements MAY include a 'recipient' attribute whose value is "all", "bare", or "full" (defaulting to "all"). Each of these elements MAY also include a 'sender' attribute whose value is "all", "local", "others", "remote", or "self" (defaulting to "all").

          @@ -344,7 +344,7 @@ ]]> -

          Similarly, the following example shows how a client would filter inbound presence notifications to only receive notifications that contain entity capabilities data as specified in XEP-0115.

          +

          Similarly, the following example shows how a client would filter inbound presence notifications to only receive notifications that contain entity capabilities data as specified in &xep0115;.

          -

          This specification re-uses the schema for the Atom content format, i.e., the 'http://www.w3.org/2005/Atom' namespace (see RFC 4287).

          +

          This specification re-uses the schema for the Atom content format, i.e., the 'http://www.w3.org/2005/Atom' namespace (see &rfc4287;).

           diff --git a/xep-0280.xml b/xep-0280.xml index d6299f33..51791ec5 100644 --- a/xep-0280.xml +++ b/xep-0280.xml @@ -154,7 +154,7 @@ 0.9 2013-10-17 mm -

          Reorganized to emphasize uses; removed discussion on error conditions required of "non-supporting" entities; relaxed multiple enables/disables to effectively no-ops; removed requirement for <private/> to be stripped from messages processed by the sending server; reworded "Interaction with Chat States" to be consistent with RFC 2119 language; updated mobile considerations to include battery life; changed all examples to use ".example" for the domainpart.

           +

          Reorganized to emphasize uses; removed discussion on error conditions required of "non-supporting" entities; relaxed multiple enables/disables to effectively no-ops; removed requirement for <private/> to be stripped from messages processed by the sending server; reworded "Interaction with Chat States" to be consistent with &rfc2119; language; updated mobile considerations to include battery life; changed all examples to use ".example" for the domainpart.

           0.8 @@ -373,7 +373,7 @@           -

          When the server receives a &MESSAGE; eligible for carbons delivery addressed to a client JID (either bare or full), it delivers the &MESSAGE; according to RFC 6121 § 8.5.3, and then delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID recipient that did not receive it under the RFC 6121 delivery rules.

          +

          When the server receives a &MESSAGE; eligible for carbons delivery addressed to a client JID (either bare or full), it delivers the &MESSAGE; according to &rfc6121; § 8.5.3, and then delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID recipient that did not receive it under the RFC 6121 delivery rules.

          Each forwarded copy is wrapped using &xep0297; with the following properties:

          • The wrapping message SHOULD maintain the same 'type' attribute value;
            • @@ -432,7 +432,7 @@ -

            When a client sends a &MESSAGE; eligible for carbons delivery, its sending server delivers the &MESSAGE; according to RFC 6120 and RFC 6121, and delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID sender, excluding the sending client. Note that this happens irrespective of whether the sending client has carbons enabled.

            +

            When a client sends a &MESSAGE; eligible for carbons delivery, its sending server delivers the &MESSAGE; according to &rfc6120; and RFC 6121, and delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID sender, excluding the sending client. Note that this happens irrespective of whether the sending client has carbons enabled.

            Each forwarded copy is wrapped using &xep0297; with the following properties:

            • The wrapping message SHOULD maintain the same 'type' attribute value;
              • @@ -489,7 +489,7 @@

              Interoperability note: earlier versions of this XEP required or recommended the removal of the <private/> element (albeit not of the <no-copy/> hint) by one of the involved servers, but this behavior was considered as a potential security issue as the sender could silently manipulate the delivery of messages, so that the requirement was lifted. However, clients MUST NOT assume that a message without the element was actually routed to all other resources of the account.

              Note: Use of the private mechanism might lead to partial conversations on other devices. This is the intended effect. - If the private &MESSAGE; stanza is addressed to a bare JID, the receiving server still delivers it according to RFC 6121. This might result in a copy being delivered to each resource for the recipient, which effectively negates the behavior of the <private/> element for recipients.

              + If the private &MESSAGE; stanza is addressed to a bare JID, the receiving server still delivers it according to &rfc6121;. This might result in a copy being delivered to each resource for the recipient, which effectively negates the behavior of the <private/> element for recipients.

              Note: &xep0085; recommends sending chat state notifications as chat type messages, which means that they will be subject to Carbon-copying. This is intentional.

              -

              Additionally, there are other considerations for clients that implement Carbons and XEP-0085:

              +

              Additionally, there are other considerations for clients that implement Carbons and &xep0085;:

              • Upon receiving an inbound or outbound <gone/> chat state (as a carbon copy) for a given conversation, the client SHOULD visually indicate the conversation is terminated.
              • In order to prevent unwanted termination of conversations on other resources, clients SHOULD NOT send <gone/> chat states on logout, instead
                • @@ -538,7 +538,7 @@

                The following rules prevent some of the half-failure modes that have been an issue in other protocols:

                • When a server attempts to deliver a (locally generated) carbon copy, and that carbon copy bounces with an error for any reason, the server MUST NOT forward that error back to the original sender.
                  • -
                • The server MUST NOT rely on the <sent/> or <received/> elements in the bounce to determine that an error is from a carbon-copied message, because entities are not required to include the original XML in their error replies as per RFC 6120, §8.3.1.
                  • +
                • The server MUST NOT rely on the <sent/> or <received/> elements in the bounce to determine that an error is from a carbon-copied message, because entities are not required to include the original XML in their error replies as per &rfc6120;, §8.3.1.
                diff --git a/xep-0281.xml b/xep-0281.xml index 59b0e02d..7a54e9a6 100644 --- a/xep-0281.xml +++ b/xep-0281.xml @@ -55,7 +55,7 @@ -

                &xep0045; defines a full-featured technology for multi-user text conferencing in XMPP. By design, XEP-0045 assumes that a conference room is hosted at a single service, which can be accessed from any point on the network. However, this assumption introduces a single point of failure for the conference room, since if occupants at a using domain lose connectivity to the hosting domain then they also lose connectivity to the room. In some deployment scenarios (and even on the open Internet) this behavior is suboptimal. Therefore, this document attempts to define a technology for distributing MUC rooms across multiple services.

                +

                &xep0045; defines a full-featured technology for multi-user text conferencing in XMPP. By design, &xep0045; assumes that a conference room is hosted at a single service, which can be accessed from any point on the network. However, this assumption introduces a single point of failure for the conference room, since if occupants at a using domain lose connectivity to the hosting domain then they also lose connectivity to the room. In some deployment scenarios (and even on the open Internet) this behavior is suboptimal. Therefore, this document attempts to define a technology for distributing MUC rooms across multiple services.

                 @@ -87,7 +87,7 @@ -

                This document adds the following terms to those defined in XEP-0045:

                +

                This document adds the following terms to those defined in &xep0045;:

                • Firsthost -- The MUC service at which a room is created.
                • Peerhost -- Any MUC service (other than the firsthost) that hosts an instance of the room.
                  • @@ -224,7 +224,7 @@ from='coven@chat.shakespeare.lit' type='result'/> ]]> -

                  The new shadow SHOULD request the room history. This is done by sending an IQ-get from the shadow to the source, containing a <history/> element qualified by the 'http://jabber.org/protocol/muc' namespace (the syntax and semantics of this element are described in XEP-0045).

                  +

                  The new shadow SHOULD request the room history. This is done by sending an IQ-get from the shadow to the source, containing a <history/> element qualified by the 'http://jabber.org/protocol/muc' namespace (the syntax and semantics of this element are described in &xep0045;).

                  ]]> -

                  The responder indiciates the reason for refusing the session by including a "reason" element. The following reasons are suggested (see also XEP-0166):

                  +

                  The responder indiciates the reason for refusing the session by including a "reason" element. The following reasons are suggested (see also &xep0166;):

                  • alternative-session -- the responder already has an active session with the initiator and wishes to use that session instead.
                  • decline -- the responder formally declines the session.
                    • @@ -311,8 +311,8 @@ ]]> -

                    Such presence can be broadcast or can be sent in the context of a multi-user chat room (see XEP-0045).

                    -

                    However, presence is not sent when operating in a serverless messaging environment (see XEP-0174). Instead, DNS TXT records are published. Two new key-value pairs are used to advertise a session id ("sxe_id") and session name ("sxe_name") when using serverless messaging.

                    +

                    Such presence can be broadcast or can be sent in the context of a multi-user chat room (see &xep0045;).

                    +

                    However, presence is not sent when operating in a serverless messaging environment (see &xep0174;). Instead, DNS TXT records are published. Two new key-value pairs are used to advertise a session id ("sxe_id") and session name ("sxe_name") when using serverless messaging.

                    diff --git a/xep-0288.xml b/xep-0288.xml index 52718712..73ca0423 100644 --- a/xep-0288.xml +++ b/xep-0288.xml @@ -248,9 +248,9 @@ http://www.ietf.org/mail-archive/web/xmpp/current/msg00664.html ]]> -

                    This specification introduces no security considerations above and beyond those discussed in RFC 6120 or XEP-0220. +

                    This specification introduces no security considerations above and beyond those discussed in &rfc6120; or &xep0220;. - Note that the impact of the "unsolicited server dialback" attack described in XEP-0220 is considerably larger for bidirectional streams, e.g. a vulnerability which allows spoofing might also route messages to the wrong targets. Additionally, dialback elements with a "type" attribute also need to be handled in incoming connections.

                    + Note that the impact of the "unsolicited server dialback" attack described in &xep0220; is considerably larger for bidirectional streams, e.g. a vulnerability which allows spoofing might also route messages to the wrong targets. Additionally, dialback elements with a "type" attribute also need to be handled in incoming connections.

                    This document requires no interaction with &IANA;.

                    diff --git a/xep-0292.xml b/xep-0292.xml index 92ae1795..b20cdd8e 100644 --- a/xep-0292.xml +++ b/xep-0292.xml @@ -143,8 +143,8 @@

                    This specification was designed with the following requirements in mind.

                      -
                    1. Reuse vCard4 as defined in RFC 6350.
                      2. -
                    2. Reuse the vCard4 XML format as defined in RFC 6351.
                      3. +
                    3. Reuse vCard4 as defined in &rfc6350;.
                      4. +
                    4. Reuse the vCard4 XML format as defined in &rfc6351;.
                    5. Ensure that clients and servers can easily migrate from vcard-temp to the new encapsulation format.
                    6. Notify interested parties of changes to vCard data using standard XMPP extensions, specifically &xep0163;.
                    7. Support vCards for non-human entities such as XMPP servers and &xep0045; rooms.
                      8. @@ -375,7 +375,7 @@ -

                      Because contact vCards are private information, they are best stored using &xep0223;. The canonical location is a well-known pubsub node "urn:xmpp:contacts". In accordance with XEP-0223, this node MUST have an access type of "whitelist" by default. When a client stores items at this node, it MUST include an ItemID set to the bare JID of the contact.

                      +

                      Because contact vCards are private information, they are best stored using &xep0223;. The canonical location is a well-known pubsub node "urn:xmpp:contacts". In accordance with &xep0223;, this node MUST have an access type of "whitelist" by default. When a client stores items at this node, it MUST include an ItemID set to the bare JID of the contact.

                      @@ -604,7 +604,7 @@

                      Several of the properties in vcard-temp are defined differently in vCard3. In fact, the definitions even differ from those provisionally made in the so-called "Dawson drafts" from which vcard-temp was supposedly derived (for reference, the last of these is archived at <http://www.watersprings.org/pub/id/draft-dawson-vcard-xml-dtd-03.txt>). The reasons for these discrepancies are unknown. However, care must be taken in correctly mapping these properties from vcard-temp to vCard4.

                      -

                      The DTD in XEP-0054 provided this definition for the KEY element:

                      +

                      The DTD in &xep0054; provided this definition for the KEY element:

                      ]]> @@ -621,7 +621,7 @@ property-key = element key {

                      The source of the spurious <TYPE/> and <CRED/> elements is unknown. The vcard-temp <CRED/> element is mapped to the vCard4 value-text construction.

                       -

                      The DTD in XEP-0054 provided this definition for the SOUND element:

                      +

                      The DTD in &xep0054; provided this definition for the SOUND element:

                      ]]> @@ -632,7 +632,7 @@ property-key = element key {

                      The source of the spurious vcard-temp <PHONETIC/> element is unknown. However, it does not exist in vCard4 and therefore is simply discarded when mapping. The vcard-temp <BINVAL/> element is mapped to the vCard4 b64bin construction and the vcard-temp <EXTVAL/> element is mapped to the vCard4 extref construction.

                       -

                      As explained in XEP-0054, the <VERSION/> element from the final Dawson draft was not used in vcard-temp; instead, the vcard-temp protocol used a 'version' attribute (in fact the Dawson drafts were inconsistent, since the DTD defined a <VERSION/> element and the body of the specification used a 'version' attribute).

                      +

                      As explained in &xep0054;, the <VERSION/> element from the final Dawson draft was not used in vcard-temp; instead, the vcard-temp protocol used a 'version' attribute (in fact the Dawson drafts were inconsistent, since the DTD defined a <VERSION/> element and the body of the specification used a 'version' attribute).

                                             @@ -703,7 +703,7 @@ property-key = element key {

                      This section contains three tools that are intended to help developers in migrating from vcard-temp to vCard4 XML:

                      1. An Extensible Stylesheet Language Transformation (XSLT) script for automatically translating the vcard-temp XML format into the vCard4 XML format.
                        2. -
                      2. An example of vcard-temp data that uses most of the elements defined in XEP-0054 that can be mapped to vCard4 properties (note that some of these elements were never used in practice).
                        3. +
                      3. An example of vcard-temp data that uses most of the elements defined in &xep0054; that can be mapped to vCard4 properties (note that some of these elements were never used in practice).
                      4. An example of vCard4 XML data showing the transformation of the vcard-temp example using the XSLT stylesheet.

                      The tools are purely informational and are not a normative part of this specification.

                      diff --git a/xep-0293.xml b/xep-0293.xml index 66a78447..83c748b0 100644 --- a/xep-0293.xml +++ b/xep-0293.xml @@ -173,7 +173,7 @@ milliseconds for this media session. It corresponds to the elements it wants to keep as-is without modifying them in the <session-accept/>

                      -

                      To conform with the negotiation rules outlined in RFC 4585 Section 4, +

                      To conform with the negotiation rules outlined in &rfc4585; Section 4, the responder MUST send any <rtcp-fb/> element as-is if it accepts it. It MUST NOT change any parameter. It MUST NOT add any <rtcp-fb/> element that was not offered by the initiator. It @@ -186,7 +186,7 @@ milliseconds for this media session. It corresponds to the <rtcp-fb-trr-int/> element, then this value is "0".

                      Example negotiation where the initiator requests Packet Loss - Indications (pli) as defined in RFC 4585 on both H.263 and H.264, + Indications (pli) as defined in &rfc4585; on both H.263 and H.264, but also requests Slice Loss Indications for H.264 with a minimum interval between regular full compound RTCP packets of 100 milliseconds.

                      diff --git a/xep-0294.xml b/xep-0294.xml index 76d4ee0d..4439f847 100644 --- a/xep-0294.xml +++ b/xep-0294.xml @@ -87,7 +87,7 @@

                      The Jingle extension defined herein is designed to meet the following requirements:

                      1. Enable negotiations of the RTP Header extensions as defined in - RFC 8285.
                        2. + &rfc8285;.
                      2. Map these parameters to Session Description Protocol (SDP; see &rfc4566;) to enable interoperability.
                      @@ -209,15 +209,15 @@

                      The <rtp-hdrext/> element maps to the "a:extmap=" SDP line - defined in RFC 8285. The ID is mapped to the 'id' attribute, the + defined in &rfc8285;. The ID is mapped to the 'id' attribute, the direction to the 'senders' attribute and the URI to the 'uri' attribute.

                      The <extmap-allow-mixed/> element maps to the "a=extmap-allow-mixed" SDP line - defined in RFC 8285. Note that a session-level line might need to be mapped + defined in &rfc8285;. Note that a session-level line might need to be mapped to all <description/> elements.

                      -

                      Example conversion of an incomplete SDP sample fragment taken from RFC 8285 section 7 into equivalent XMPP:

                      +

                      Example conversion of an incomplete SDP sample fragment taken from &rfc8285; section 7 into equivalent XMPP:

                    8. Reuse the existing format and XML schema already - defined in RFC 4575.
                      9. + defined in &rfc4575;.
                    9. Impose no requirements on agents joining the call other than those necessary to establish a regular one-to-one call.
                    10. Allow straightforward interoperability with other conferencing @@ -289,7 +289,7 @@ explicit service discovery instead.

                      -

                      PENDING: RFC 4575 mostly talks about authentication +

                      PENDING: &rfc4575; mostly talks about authentication conference-info subscriptions but these are not part of this specification. The authors are hence currently unaware of any other Coin specific security considerations

                      diff --git a/xep-0299.xml b/xep-0299.xml index d04ad3fd..94803199 100644 --- a/xep-0299.xml +++ b/xep-0299.xml @@ -128,7 +128,7 @@                       -

                      For security considerations related to Jingle RTP sessions, refer to XEP-0167. This document introduces no new security considerations. See also the security considerations described in the relevant codec specifications.

                      +

                      For security considerations related to Jingle RTP sessions, refer to &xep0167;. This document introduces no new security considerations. See also the security considerations described in the relevant codec specifications.

                       diff --git a/xep-0305.xml b/xep-0305.xml index ac3a3adf..75723739 100644 --- a/xep-0305.xml +++ b/xep-0305.xml @@ -57,8 +57,8 @@ -

                      In accordance with &rfc6120;, before attempting to establish a stream over TCP the initiating entity needs to determine the IP address and port at which to connect, usually by means of DNS lookups as described in Section 3.2 of RFC 6120. Implementations SHOULD cache the results of DNS lookups in order to avoid this step whenever possible. Similar considerations apply to connections established over one of the HTTP bindings, i.e., either BOSH (see &xep0124; and &xep0206;) or WebSocket (see &rfc6455; and &rfc7395;).

                      -

                      XMPP applications SHOULD cache whatever information they can about the peer, especially stream features data and &xep0030; information. To facilitate such caching, servers SHOULD include &xep0115; data in stream features as shown in Section 6.3 of XEP-0115. Note that for maximum benefit the server MUST include all of the stream features it supports in its replies to "disco#info" queries (i.e., not advertise such features only during stream establishment).

                      +

                      In accordance with &rfc6120;, before attempting to establish a stream over TCP the initiating entity needs to determine the IP address and port at which to connect, usually by means of DNS lookups as described in Section 3.2 of &rfc6120;. Implementations SHOULD cache the results of DNS lookups in order to avoid this step whenever possible. Similar considerations apply to connections established over one of the HTTP bindings, i.e., either BOSH (see &xep0124; and &xep0206;) or WebSocket (see &rfc6455; and &rfc7395;).

                      +

                      XMPP applications SHOULD cache whatever information they can about the peer, especially stream features data and &xep0030; information. To facilitate such caching, servers SHOULD include &xep0115; data in stream features as shown in Section 6.3 of &xep0115;. Note that for maximum benefit the server MUST include all of the stream features it supports in its replies to "disco#info" queries (i.e., not advertise such features only during stream establishment).

                      XMPP clients SHOULD cache roster information, and servers SHOULD make such caching possible, using &xep0237; as subsequently included in Section 2.1.1 of &rfc6121;.

                       @@ -75,11 +75,11 @@

                      If an XMPP server supports pipelining, it MUST advertise a stream feature of <pipelining xmlns='urn:xmpp:features:pipelining'/>.

                      -

                      As noted, a server SHOULD also include its entity capabilities data in stream features as shown in Section 6.3 of XEP-0115.

                      +

                      As noted, a server SHOULD also include its entity capabilities data in stream features as shown in Section 6.3 of &xep0115;.

                       -

                      If both parties support pipelining, they can proceed as follows over the TCP binding (the examples use the XML from Section 9.1 of RFC 6120 for the client-server stream establishment, but the same principles apply to server-to-server streams).

                      +

                      If both parties support pipelining, they can proceed as follows over the TCP binding (the examples use the XML from Section 9.1 of &rfc6120; for the client-server stream establishment, but the same principles apply to server-to-server streams).

                      In the client-to-server half of the first exchange, the client assumes that the server supports the XMPP STARTTLS extension so it pipelines its initial stream header, the <starttls/> command, and the TLS ClientHello message.

                      ]]> -

                      In response, the client pipelines its initial stream header with the command for initiating the SASL authentication process (including, if appropriate for the SASL mechanism used, the "initial response" data as explained in Section 6.3.10 of RFC 6120).

                      +

                      In response, the client pipelines its initial stream header with the command for initiating the SASL authentication process (including, if appropriate for the SASL mechanism used, the "initial response" data as explained in Section 6.3.10 of &rfc6120;).

                      ]]> -

                      The server then informs the client of SASL success (including "additional data with success" as explained in Section 6.3.10 of RFC 6120), sends a response stream header and stream features, and informs the client of successful resource binding.

                      +

                      The server then informs the client of SASL success (including "additional data with success" as explained in Section 6.3.10 of &rfc6120;), sends a response stream header and stream features, and informs the client of successful resource binding.

                      dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289 @@ -413,7 +413,7 @@ Content-Length: 674

                      The pain of multiple round trips is magnified if the initiating entity needs to reconnect frequently (e.g., because of intermittent network outages). Although XEP-0124 can be used to mitigate the pain, BOSH is not appropriate for all scenarios and is not currently used in others (e.g., server-to-server streams).

                      To minimize the speed of reconnection, implementations are strongly encouraged to support TLS Session Resumption (&rfc5077;) in addition to the technologies already mentioned.

                      -

                      Reconnection can be further enhanced by using the stream resumption feature defined in &xep0198;. XEP-0198 does not legislate exactly when it is safe for the server to allow the client to send the <resume/> request. Clearly, sending it before the stream is encrypted would increase the possibility of replay attacks. However, sending it after TLS negotiation (Step 4 above) but before SASL authentication and resource binding (Steps 5 through 8) would enable the client to begin sending stanzas more quickly. It is a matter of server policy whether to advertise the SM feature after TLS negotiation or only after SASL negotiation.

                      +

                      Reconnection can be further enhanced by using the stream resumption feature defined in &xep0198;. &xep0198; does not legislate exactly when it is safe for the server to allow the client to send the <resume/> request. Clearly, sending it before the stream is encrypted would increase the possibility of replay attacks. However, sending it after TLS negotiation (Step 4 above) but before SASL authentication and resource binding (Steps 5 through 8) would enable the client to begin sending stanzas more quickly. It is a matter of server policy whether to advertise the SM feature after TLS negotiation or only after SASL negotiation.

                      Because pipelining does not skip any channel encryption or authentication steps, but merely packs them into a smaller number of TCP packets or HTTP request/response pairs, it is unlikely that the foregoing quickstart methods introduce security vulnerabilities. However, the server needs to be careful not to send stream features that it would not otherwise send before a security context is established.

                      diff --git a/xep-0306.xml b/xep-0306.xml index 025c496a..fe484bb4 100644 --- a/xep-0306.xml +++ b/xep-0306.xml @@ -172,7 +172,7 @@                       -

                      The security considerations of XEP-0045 apply.

                      +

                      The security considerations of &xep0045; apply.

                       diff --git a/xep-0307.xml b/xep-0307.xml index 67109dd5..de06d712 100644 --- a/xep-0307.xml +++ b/xep-0307.xml @@ -64,7 +64,7 @@ ]]>

                      The service MAY refuse to return a unique room name to entities that are not entitled to create rooms, entities that have sent an excessive number of requests for unique room names, etc.

                      -

                      The service MAY use any algorithm that ensures the creation of a room name that will be permanently unique in the context of the service (e.g., a cryptographic hash of the requesting JID, datetime, and random salt), or simply use a UUID as defined by RFC 4122.

                      +

                      The service MAY use any algorithm that ensures the creation of a room name that will be permanently unique in the context of the service (e.g., a cryptographic hash of the requesting JID, datetime, and random salt), or simply use a UUID as defined by &rfc4122;.

                      The room creator would then use the XML character data of the <unique/> element as the node identifier portion of the room JID it requests:

                      Just as &xep0163; defines a profile of &xep0060; that enables an instant messaging user to send updates or "events" to other users, this specification defines a profile that enables a room occupant or the chatroom itself to send notifications in the context of &xep0045; chatroom.

                      -

                      Note: Any use cases, error flows, and other protocols details not described herein are described in XEP-0060. This document merely defines a "subset" or "profile" of XMPP publish-subscribe.

                      +

                      Note: Any use cases, error flows, and other protocols details not described herein are described in &xep0060;. This document merely defines a "subset" or "profile" of XMPP publish-subscribe.

                       @@ -108,7 +108,7 @@ ver='054H4A7280JuT6+IroVYxgCAjZo='/> ]]> -

                      That chatroom knows to send conference-info notifications to crone1@shakespeare.lig because when the room unpacks the value of the 'ver' attribute ("054H4A7280JuT6+IroVYxgCAjZo=") in accordance with XEP-0115, it discovers that her client advertises a service discovery feature of "urn:ietf:params:xml:ns:conference-info+notify", where the "+notify" suffix indicates interest in receiving notifications related to the protocol that precedes the suffix. The server can verify this support if needed by sending a service discovery request to crone1's full JID (see XEP-0115 for details).

                      +

                      That chatroom knows to send conference-info notifications to crone1@shakespeare.lig because when the room unpacks the value of the 'ver' attribute ("054H4A7280JuT6+IroVYxgCAjZo=") in accordance with &xep0115;, it discovers that her client advertises a service discovery feature of "urn:ietf:params:xml:ns:conference-info+notify", where the "+notify" suffix indicates interest in receiving notifications related to the protocol that precedes the suffix. The server can verify this support if needed by sending a service discovery request to crone1's full JID (see XEP-0115 for details).

                       @@ -197,7 +197,7 @@

                      A MEP service MUST:

                        -
                      • Support the node discovery, node creation, node deletion, publish item, subscribe, unsubscribe, and item retrieval use cases specified in XEP-0060.
                        • +
                      • Support the node discovery, node creation, node deletion, publish item, subscribe, unsubscribe, and item retrieval use cases specified in &xep0060;.
                      • Support the "auto-create", "auto-subscribe", and "filtered-notifications" features.
                      • Support the "owner" and "subscriber" affiliations.
                      • Support the "presence" access model and set it to the default.
                        • @@ -282,7 +282,7 @@ -

                        Because MEP simply reuses the protocol specified in XEP-0060, a separate schema is not needed.

                        +

                        Because MEP simply reuses the protocol specified in &xep0060;, a separate schema is not needed.

                         diff --git a/xep-0319.xml b/xep-0319.xml index b7e99a0d..afe67ceb 100644 --- a/xep-0319.xml +++ b/xep-0319.xml @@ -71,7 +71,7 @@
                      • Distinguishing between the idle and last online use cases is very difficult.
                      • It is desirable to have idle time indiciated for &PRESENCE; <show/> values other than "away" and "xa".
                      -

                      Updating XEP-0256 directly would be problematic as it would break compatibility with existing implementations. Instead a new protocol is described for handling the idle time use case; the last online use case is handled by &xep0312;.

                      +

                      Updating &xep0256; directly would be problematic as it would break compatibility with existing implementations. Instead a new protocol is described for handling the idle time use case; the last online use case is handled by &xep0312;.

                      There are two main use cases for this extension, explained in more detail in the following sections.

                      @@ -122,7 +122,7 @@

                      Thanks to Florian Schmaus, Christian Schudt, and Lance Stout for their helpful comments.

                       -

                      The security considerations of XEP-0082 apply to this protocol.

                      +

                      The security considerations of &xep0082; apply to this protocol.

                      This specification introduces no new security or privacy concerns. While including a last user interaction notation in &PRESENCE; updates can enable recipients to determine exactly when a user has stopped interacting with her XMPP client or even their system, this information is in essence already available if the user's client publishes timely presence updates.

                       diff --git a/xep-0320.xml b/xep-0320.xml index 61935ece..c8071825 100644 --- a/xep-0320.xml +++ b/xep-0320.xml @@ -102,7 +102,7 @@ a=fingerprint:hash-func fingerprint a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2 -

                      Additionally, the SDP setup attribute defined in &rfc4145; must be mapped, whose usage for DTLS-SRTP is defined in RFC 5763.

                      +

                      Additionally, the SDP setup attribute defined in &rfc4145; must be mapped, whose usage for DTLS-SRTP is defined in &rfc5763;.

                      a=setup:role @@ -267,7 +267,7 @@ a=setup:role                       -

                      Security considerations for DTLS-SRTP itself are provided in RFC 5763.

                      +

                      Security considerations for DTLS-SRTP itself are provided in &rfc5763;.

                      XMPP stanzas such as Jingle messages and service discovery exchanges are not encrypted or signed. As a result, it is possible for an attacker to intercept these stanzas and modify them, thus convincing one party that the other party does not support DTLS-SRTP and therefore denying the parties an opportunity to use DTLS-SRTP.

                       diff --git a/xep-0327.xml b/xep-0327.xml index df2f86bd..e3b50ea7 100644 --- a/xep-0327.xml +++ b/xep-0327.xml @@ -3049,7 +3049,7 @@ Art thou not Romeo, and a Montague?

                      The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.

                      -

                      If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

                      +

                      If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of &xep0053;.

                      The XMPP Registrar maintains a registry of Rayo components. All component registrations with the exception of those defined above shall be defined in separate specifications (not in this document). Components defined within the XEP series MUST be registered with the XMPP Registrar, resulting in protocol URNs of the form "urn:xmpp:rayo:component_name:X" (where "component_name" is the registered name of the component and "X" is a non-negative integer).

                      diff --git a/xep-0338.xml b/xep-0338.xml index b684067a..71dfe796 100644 --- a/xep-0338.xml +++ b/xep-0338.xml @@ -52,7 +52,7 @@

                      It is anticipated that the primary use of this is with the &bundle; framework used in WebRTC.

                       -

                      The SDP format defined in RFC 5888 is shown below.

                      +

                      The SDP format defined in &rfc5888; is shown below.

                      a=group:semantics identification-tag @@ -100,7 +100,7 @@ a=group:LS voice webcam

                      Note: the identification-tags correspond to the <content/> 'name' attributes. These in turn map to the 'mid' attribute in SDP.

                       -

                      If an entity supports the grouping framework described in RFC 5888, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of 'urn:ietf:rfc:5888':

                      +

                      If an entity supports the grouping framework described in &rfc5888;, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of 'urn:ietf:rfc:5888':

                      -

                      The SDP format defined in RFC 5576 is shown below.

                      +

                      The SDP format defined in &rfc5576; is shown below.

                      a=ssrc:<ssrc-id> <attribute> a=ssrc:<ssrc-id> <attribute>:<value> @@ -88,7 +88,7 @@ a=ssrc:1656081975 msid:MLTJKIHilGn71fNQoszkQ4jlPTuS5vJyKVIv MLTJKIHilGn71fNQoszk ]]>                       -

                      The SDP format defined in RFC 5576 is shown below.

                      +

                      The SDP format defined in &rfc5576; is shown below.

                      a=ssrc-group:<semantics> <ssrc-id> ...

                      This maps to Jingle as a <ssrc-group/> element qualified by the 'urn:xmpp:jingle:apps:rtp:ssma:0' namespace. Like the <source/> element, this is included as child of the Jingle <description/> element. The SDP 'semantics' parameter is mapped to the semantics attribute (for consistency with &xep0338;) and the list of ssrc-ids is mapped to <source/> elements whole 'ssrc' attribute is set to the ssrc-id.

                      @@ -141,7 +141,7 @@ a=ssrc:2613715171 cname:f83avsiw6n1m7vi ]]>                       -

                      If an entity supports source specific media attributes as described in RFC 5576, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of 'urn:ietf:rfc:5576':

                      +

                      If an entity supports source specific media attributes as described in &rfc5576;, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of 'urn:ietf:rfc:5576':

                      - RFC 3550 defines a translator as "an intermediate + &rfc3550; defines a translator as "an intermediate system that forwards RTP packets with their synchronization source identifier intact." This specification respects that definition but it also uses "RTP Translation" in opposition diff --git a/xep-0341.xml b/xep-0341.xml index 051ffcf6..d8572b67 100644 --- a/xep-0341.xml +++ b/xep-0341.xml @@ -262,7 +262,7 @@

                      The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.

                      -

                      If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

                      +

                      If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of &xep0053;.

                       diff --git a/xep-0342.xml b/xep-0342.xml index 7248efd6..f35e02b5 100644 --- a/xep-0342.xml +++ b/xep-0342.xml @@ -296,7 +296,7 @@

                      The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.

                      -

                      If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

                      +

                      If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of &xep0053;.

                                             diff --git a/xep-0343.xml b/xep-0343.xml index 34b4a0b5..aab03d17 100644 --- a/xep-0343.xml +++ b/xep-0343.xml @@ -74,7 +74,7 @@
                    -

                    In accordance with Section 10 of XEP-0166, this document specifies the following information related to the Jingle DTLS/SCTP transport method:

                    +

                    In accordance with Section 10 of &xep0166;, this document specifies the following information related to the Jingle DTLS/SCTP transport method:

                    1. The transport negotiation process is defined in the Protocol Description section of this document.

                    2. The semantics of the &SCTPMAP; element are defined in the Syntax section of this document.

                      3. @@ -84,7 +84,7 @@

                      This protocol requires the Stream Control Transmission Protocol (SCTP) to run within the security context of the Datagram Transport Layer Security (DTLS) protocol. As determined by RTCWeb Data Channels running SCTP on top of DTLS is preferred, as in this order the control messages are encrypted as well and the DTLS channel can be shared with several applications

                      -

                      In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in XEP-0166. If the initiator wishes to negotiate the SCTP transport method for an application format, it MUST include a &SCTPMAP; child element qualified by the 'urn:xmpp:jingle:transports:dtls-sctp:1' namespace &VNOTE;. The &TRANSPORT; element SHOULD in turn contain one &CANDIDATE; element for each of the initiator's higher-priority transport candidates as determined in accordance with the ICE methodology, but MAY instead be empty (with each candidate to be sent as the payload of a transport-info message).

                      +

                      In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in &xep0166;. If the initiator wishes to negotiate the SCTP transport method for an application format, it MUST include a &SCTPMAP; child element qualified by the 'urn:xmpp:jingle:transports:dtls-sctp:1' namespace &VNOTE;. The &TRANSPORT; element SHOULD in turn contain one &CANDIDATE; element for each of the initiator's higher-priority transport candidates as determined in accordance with the ICE methodology, but MAY instead be empty (with each candidate to be sent as the payload of a transport-info message).

                      The attributes of the <channel/> element map directly to the attributes of the RTCDataChannelInit dictionary as defined in &w3-webrtc-draft;.

                       -

                      As described in XEP-0166, to acknowledge receipt of the session initiation request, the responder immediately returns an IQ-result.

                      +

                      As described in &xep0166;, to acknowledge receipt of the session initiation request, the responder immediately returns an IQ-result.

                      The ®ISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.

                       -

                      If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

                      +

                      If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of &xep0053;.

                       diff --git a/xep-0357.xml b/xep-0357.xml index 04b12a81..351bf822 100644 --- a/xep-0357.xml +++ b/xep-0357.xml @@ -97,7 +97,7 @@
                    3. Eliminate the need for clients to proxy a user's XMPP session in order to enable push notifications.
                  -

                  Note: Any publish-subscribe use cases not described herein are described in &xep0060;. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in XEP-0060. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension. This document merely defines a "subset" or "profile" of XMPP publish-subscribe.

                  +

                  Note: Any publish-subscribe use cases not described herein are described in &xep0060;. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in &xep0060;. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension. This document merely defines a "subset" or "profile" of XMPP publish-subscribe.

                  @@ -197,7 +197,7 @@ -

                  An XMPP Push Service is a PubSub service as defined by the XMPP XEP-0060 extension. The functional difference between a Push Service and a generic pubsub service is that a Push Service will generally summarize and forward published content via non-XMPP mechanisms.

                  +

                  An XMPP Push Service is a PubSub service as defined by the XMPP &xep0060; extension. The functional difference between a Push Service and a generic pubsub service is that a Push Service will generally summarize and forward published content via non-XMPP mechanisms.

                  Note: a Push Service is provided by a specific client application as part of the App Server. A user's XMPP server will typically not act as a Push Service itself, but will instead publish to the Push Services for the user's client applications.

                  diff --git a/xep-0358.xml b/xep-0358.xml index 9155eca5..4dd9d8a8 100644 --- a/xep-0358.xml +++ b/xep-0358.xml @@ -280,7 +280,7 @@ xmpp:files.montague.net?jingle;id=9559976B-3FBF-4E7E-B457-2DAA225972BB]]> -

                  This document introduces no security concerns beyond those specified in XEP-0060 and the relevant Jingle application format in use.

                  +

                  This document introduces no security concerns beyond those specified in &xep0060; and the relevant Jingle application format in use.

                  This document requires no interaction with &IANA;.

                  diff --git a/xep-0370.xml b/xep-0370.xml index e95d55d7..3ab992f0 100644 --- a/xep-0370.xml +++ b/xep-0370.xml @@ -70,7 +70,7 @@                   -

                  In accordance with Section 12 of XEP-0166, this document specifies the following information related to both the Jingle http-download and http-upload transport methods:

                  +

                  In accordance with Section 12 of &xep0166;, this document specifies the following information related to both the Jingle http-download and http-upload transport methods:

                  1. The transport negotiation process for http-download is defined in the Negotiating HTTP Download section of this document, and the negotation process for http-upload is defined in the Negotiating HTTP Upload section of this document.

                  2. The semantics of the &TRANSPORT; element are defined in the Negotiating HTTP Download and Negotiating HTTP Upload sections of this document.

                    3. diff --git a/xep-0371.xml b/xep-0371.xml index 9818ac14..800fcea7 100644 --- a/xep-0371.xml +++ b/xep-0371.xml @@ -122,7 +122,7 @@
                  -

                  In accordance with Section 10 of XEP-0166, this document specifies the following information related to the Jingle ICE transport method:

                  +

                  In accordance with Section 10 of &xep0166;, this document specifies the following information related to the Jingle ICE transport method:

                  1. The transport negotiation process is defined in the Protocol Description section of this document.

                  2. The semantics of the &TRANSPORT; element are defined in the ICE Negotiation section of this document.

                    3. @@ -159,7 +159,7 @@ INITIATOR RESPONDER

                    Note: The examples in this document follow the scenario described in Section 15 of &rfc8445;, except that we substitute the Shakespearean characters "Romeo" and "Juliet" for the generic entities "L" and "R".

                    -

                    In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in XEP-0166. If the initiator wishes to negotiate the ICE transport method for an application format, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:ice:0' namespace &VNOTE;. This element SHOULD in turn contain one &CANDIDATE; element for each of the initiator's higher-priority transport candidates as determined in accordance with the ICE methodology, but MAY instead be empty (with each candidate to be sent as the payload of a transport-info message).

                    +

                    In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in &xep0166;. If the initiator wishes to negotiate the ICE transport method for an application format, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:ice:0' namespace &VNOTE;. This element SHOULD in turn contain one &CANDIDATE; element for each of the initiator's higher-priority transport candidates as determined in accordance with the ICE methodology, but MAY instead be empty (with each candidate to be sent as the payload of a transport-info message).

                     -

                    As described in XEP-0166, to acknowledge receipt of the session initiation request, the responder immediately returns an IQ-result.

                    +

                    As described in &xep0166;, to acknowledge receipt of the session initiation request, the responder immediately returns an IQ-result.

                    The initiator and responder negotiate connectivity over ICE by exchanging XML-formatted transport candidates for the channel. This negotiation proceeds immediately in order to maximize the possibility that connectivity can be established (and therefore media can be exchanged) as quickly as possible. In order to expedite session establishment, the initiator SHOULD include transport candidates in its session-initiate message but MAY also send additional transport candidates as soon as it learns of them, even before receiving the IQ-result that acknowledges the session-initiate message (i.e., the initiator MUST consider the session to be live as soon as it sends the session-initiate message). Given in-order delivery as mandated by &xmppcore;, the responder will receive such transport-info messages after receiving the session-initiate message; if not, it is appropriate for the responder to return <unknown-session/> errors since according to its state machine the session does not exist.

                    The first step in negotiating connectivity is for each party to send transport candidates to the other party. The fact that both parties send candidates means that Jingle requires each party to be a full implementation of ICE, not a lite implementation as specified in &rfc8445;. These candidates SHOULD be gathered by following the procedure specified in Section 5.1.1 of &rfc8445; (typically by communicating with a standalone STUN server in order to discover the client's public IP address and port) and prioritized by following the procedure specified in Section 5.1.2 of &rfc8445;.

                    Each candidate shall be sent as a <candidate/> child of a &TRANSPORT; element qualified by the 'urn:xmpp:jingle:transports:ice:0' namespace. The &TRANSPORT; element is sent via a Jingle message of type session-initiate, session-accept, or transport-info.

                    -

                    Either party MAY include multiple <candidate/> elements in one &TRANSPORT; element, especially in the session-initiate and session-accept messages sent at the beginning of the session negotiation. Including multiple candidates in the session-initiate and session-accept messages can help to ensure interoperability with entities that implement the SDP offer/answer model described in RFC 3264; in particular, an entity SHOULD include multiple candidates in its session-initiate or session-accept message if the other party advertises support for the "urn:ietf:rfc:3264" service discovery feature as described in the SDP Offer / Answer Support section of this document. However, including one candidate per subsequent transport-info message typically results in a faster negotiation because the candidates most likely to succeed are sent first (in the session-info and session-accept messages) and it is not necessary to gather all candidates before beginning to send any candidates; furthermore, because certain candidates can be more "expensive" in terms of bandwidth or processing power, either party might not want to advertise the existence of such candidates unless it is necessary to do so after other candidates have failed.

                    +

                    Either party MAY include multiple <candidate/> elements in one &TRANSPORT; element, especially in the session-initiate and session-accept messages sent at the beginning of the session negotiation. Including multiple candidates in the session-initiate and session-accept messages can help to ensure interoperability with entities that implement the SDP offer/answer model described in &rfc3264;; in particular, an entity SHOULD include multiple candidates in its session-initiate or session-accept message if the other party advertises support for the "urn:ietf:rfc:3264" service discovery feature as described in the SDP Offer / Answer Support section of this document. However, including one candidate per subsequent transport-info message typically results in a faster negotiation because the candidates most likely to succeed are sent first (in the session-info and session-accept messages) and it is not necessary to gather all candidates before beginning to send any candidates; furthermore, because certain candidates can be more "expensive" in terms of bandwidth or processing power, either party might not want to advertise the existence of such candidates unless it is necessary to do so after other candidates have failed.

                    If the party that receives a candidate in a Jingle message can successfully process a given candidate or set of candidates, it returns an IQ-result (if not, for example because the candidate data is improperly formatted, it returns an IQ-error). At this point, the receiving entity is only indicating receipt of the candidate or set of candidates, not telling the other party that the candidate will be used.

                    The initiator can keep sending candidates (without stopping to receive an acknowledgement of receipt from the responder for each candidate) until it has exhausted its supply of possible or desirable transport candidates. The responder can also keep sending potential candidates, which the initiator will acknowledge.

                     @@ -548,7 +548,7 @@ ENTITY IP Address Mnemonic name ]]>

                    (In accordance with Jingle core, the responder will also acknowledge the transport-info message.)

                    -

                    In the unlikely event that one of the parties determines that it cannot establish connectivity even after sending and checking lower-priority candidates, it SHOULD terminate the session as described in XEP-0166, or alternatively it may do content-remove or transport-replace.

                    +

                    In the unlikely event that one of the parties determines that it cannot establish connectivity even after sending and checking lower-priority candidates, it SHOULD terminate the session as described in &xep0166;, or alternatively it may do content-remove or transport-replace.

                    Even after media has begun to flow, either party MAY continue to send additional candidates to the other party (e.g., because the user agent has become aware of a new media proxy or network interface card). Such candidates are shared by sending a transport-info message.

                    @@ -871,7 +871,7 @@ Romeo Gateway Juliet

                    In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

                     -

                    If an entity supports the SDP offer / answer model described in RFC 3264 and therefore prefers to receive multiple candidates in a single transport-info message, it MUST advertise support for the "urn:ietf:rfc:3264" service discovery feature. Typically this feature will be advertised only by gateways between Jingle and SIP.

                    +

                    If an entity supports the SDP offer / answer model described in &rfc3264; and therefore prefers to receive multiple candidates in a single transport-info message, it MUST advertise support for the "urn:ietf:rfc:3264" service discovery feature. Typically this feature will be advertised only by gateways between Jingle and SIP.

                    By definition, the exchange of transport candidates results in exposure of the sender's IP addresses, which comprise a form of personally identifying information. A Jingle client MUST enable a user to control which entities will be allowed to receive such information. If a human user explicitly accepts a session request, then the client SHOULD consider that action to imply approval of IP address sharing. However, waiting for a human user to explicitly accept the session request can result in delays during session setup, since it is more efficient to immediately begin sharing transport candidates. Therefore, it is RECOMMENDED for the client to immediately send transport candidates to a contact (without waiting for explicit user approval of the session request) in the following cases:

                    1. The user has permanently and formally authorized the contact to view the user's presence information via a presence subscription as reflected in an XMPP roster item (see &xmppim;).
                      2. -
                    2. The user has temporarily and dynamically shared presence with the contact via "directed presence" as described in RFC 3921.
                      3. +
                    3. The user has temporarily and dynamically shared presence with the contact via "directed presence" as described in &rfc3921;.
                    4. The user has explicitly added the contact to a list of entities who are allowed to access the user's personally-identifying information.
                     @@ -938,7 +938,7 @@ Romeo Gateway Juliet &NSVER; -

                    If an entity supports the SDP offer / answer model described in RFC 3264 and therefore prefers to receive one transport-info message with multiple candidates, it MUST advertise support for the "urn:ietf:rfc:3264" feature.

                    +

                    If an entity supports the SDP offer / answer model described in &rfc3264; and therefore prefers to receive one transport-info message with multiple candidates, it MUST advertise support for the "urn:ietf:rfc:3264" feature.

                    The registry submission is as follows.

                    diff --git a/xep-0373.xml b/xep-0373.xml index 0659bae6..d6c0fd1a 100644 --- a/xep-0373.xml +++ b/xep-0373.xml @@ -340,7 +340,7 @@ -

                    The public key data, as specified in RFC 4880, is stored in a PEP data +

                    The public key data, as specified in &rfc4880;, is stored in a PEP data node. Note that OpenPGP's ASCII Armor is not used, instead the XMPP client MUST encode the public key using Base64. The id of the node MUST be "urn:xmpp:openpgp:0:public-keys:" followed by the fingerprint string of the OpenPGP public-key contained in the data node.

                    @@ -357,7 +357,7 @@ used by GnuPG minus the SPACE separation..

                    The publishing entity SHOULD set the PubSub item ID to the time the item is published encoded - as DateTime format specified in XEP-0082.

                    + as DateTime format specified in &xep0082;.

                    The data node MUST contain an <pubkey/> element qualified by the 'urn:xmpp:openpgp:0' namespace. The element MUST include a <data/> element which contains the data of the key @@ -405,7 +405,7 @@ or more <pubkey-metadata/> elements. Every pubkey-metadata element MUST have a 'v4-fingerprint' attribute, containing the OpenPGP v4 fingerprint string, and a 'date' attribute, containing the time the key was published or updated in DateTime format of - XEP-0082. An OpenPGP V4 fingerprint MUST NOT occur in the list more than once.

                    + &xep0082;. An OpenPGP V4 fingerprint MUST NOT occur in the list more than once.

                    @@ -519,7 +519,7 @@ may want to limit the results to the most recent item using the 'max_items' attribute set to '1'. Clients could alternatively use &xep0059; as an alternative to 'max_items' but accoding to - XEP-0060 RSM is not (yet) mandatory for PubSub + &xep0060; RSM is not (yet) mandatory for PubSub services.

                    Some XMPP services may not provide the Personal Eventing @@ -535,7 +535,7 @@ nodes by setting 'pubsub#deliver_payloads" configuration field to 'false'.

                    Entities which are subscribed to the metadata node or advertise the - "urn:xmpp:openpgp:0:public-keys+notify" feature via &xep0030; (see XEP-0060 § 9.2) receive a notification upon a node update. Entities subscribed to PEP nodes defined herein MUST be prepared that PubSub notifications may be without the payload and only contain the published item's ID.

                    @@ -731,7 +731,7 @@ url='http://tools.ietf.org/html/rfc4880#section-11.2'>§ 11.1). The octet indicating string-to-key usage conventions MUST be set to zero in the corresponding Secret-Key Packet(s) - (RFC 4880 § 5.5.3). + (&rfc4880; § 5.5.3). The secret key material will be encrypted in step 4 using a Symmetric-Key Encrypted Session Key Packet. @@ -754,7 +754,7 @@ used as a string to encrypt the concatenated transferable keys as an OpenPGP message. More precisely: It is used as the symmetric-key for a Symmetric-Key Encrypted Session Key Packet - according to RFC 4880 § 5.3; the symmetric-key is thus 29 characters long including the dashes. The encryption algorithm MUST be one of @@ -784,7 +784,7 @@

                    The Public-Key metadata node and the Secret-Key node SHOULD be configured to either never send the latest item, or to send the latest item only when a new entity subscribed. Thus the nodes 'send_last_published_item' configuration option SHOULD be set to either 'never' or - 'on_sub' (see XEP-0060 § 16.4.4).

                     @@ -917,7 +917,7 @@ encrypting of the element. The scope of the specification was deliberately limited to OpenPGP.

                    -

                    Features like signed presences, which is provided by XEP-0027, +

                    Features like signed presences, which is provided by &xep0027;, may be added later on as add-on XEP to this.

                     @@ -937,13 +937,13 @@

                    OpenPGP User IDs normally consist of a name - email address pair, e.g., - "Juliet <juliet@example.org>" (RFC 4880 § 5.11). For this XEP, we require User IDs of the format "xmpp:juliet@example.org". First, it is required to have at least one User ID indicating the use of this OpenPGP key. When doing certification of keys (key signing), the partner must know what User ID she actually certifies. - Second, this format uses the standardized URI from XEP-0147 to indicate + Second, this format uses the standardized URI from &xep0147; to indicate that this User ID corresponds to a key that is used for XMPP. Third, having the Real Name inside provides no additional security or guideline if this key should be certified. The XMPP address diff --git a/xep-0374.xml b/xep-0374.xml index 79781728..502d1e15 100644 --- a/xep-0374.xml +++ b/xep-0374.xml @@ -135,14 +135,14 @@ to store OpenPGP key information in the Domain Name System (DNS). This specification does not restrict the mechanism of key discovery and retrieval, but compliant clients MUST support - the public key announcement as described in XEP-0373 + the public key announcement as described in &xep0373; § 4.

                    After the required public keys have been discovered, XMPP clients engage in an OpenPGP secured IM conversation by exchanging &openpgp; extension elements. They MUST use the &signcrypt; OpenPGP content element specified in - XEP-0373§ 3.1.

                    + &xep0373;§ 3.1.

                    The child elements of the OpenPGP content element's &payload; can be seen as stanza extension elements which are encrypted and @@ -246,7 +246,7 @@

                    This XEP does not define a Schema, since it exclusively uses elements from - XEP-0373 and other XEPs.

                    + &xep0373; and other XEPs.

                    @@ -254,7 +254,7 @@

                    Please refer to the Acknowledgements section - of XEP-0373 since the two XEPs where designed together. + of &xep0373; since the two XEPs where designed together.

                    diff --git a/xep-0379.xml b/xep-0379.xml index b408165a..61f7ce95 100644 --- a/xep-0379.xml +++ b/xep-0379.xml @@ -148,7 +148,7 @@ Romeo mongatague.net capulet.net Juliet

                    Whenever Romeo wishes to invite somebody to his roster, his client will generate an invitation link that contains a new authentication token. - This document extends the "roster" URI action defined in XEP-0147 with + This document extends the "roster" URI action defined in &xep0147; with a new key-value parameter named "preauth" to store the generated token. Romeo's client will create an xmpp: link containing Romeo's JID, the "roster" action, the "preauth" parameter with the token value, and diff --git a/xep-0384.xml b/xep-0384.xml index c1868c40..73285e65 100644 --- a/xep-0384.xml +++ b/xep-0384.xml @@ -151,7 +151,7 @@ 0.3.0 2018-07-31 egp -

                    Make examples show items published to the id "current", as per XEP-0060 §12.20.

                    +

                    Make examples show items published to the id "current", as per &xep0060; §12.20.

                     0.2.2 @@ -452,13 +452,13 @@ ]]> -

                    NOTE: as per XEP-0060 §12.20, it is RECOMMENDED for the publisher to specify an ItemID of "current" to ensure that the publication of a new item will overwrite the existing item.

                    +

                    NOTE: as per &xep0060; §12.20, it is RECOMMENDED for the publisher to specify an ItemID of "current" to ensure that the publication of a new item will overwrite the existing item.

                    This step presents the risk of introducing a race condition: Two devices might simultaneously try to announce themselves, unaware of the other's existence. The second device would overwrite the first one. To mitigate this, devices MUST check that their own device id is contained in the list whenever they receive a PEP update from their own account. If they have been removed, they MUST reannounce themselves.

                    Furthermore, a device MUST publish its IdentityKey, a signed PreKey, and a list of PreKeys. This tuple is called a bundle and is provided by OMEMO libraries. Bundles are maintained as multiple items in a PEP node called &nsbundles;. Each bundle MUST be stored in a seperate item. The item id MUST be set to the device id.

                    A bundle is an element called 'bundle' in the &ns; namespace. It has a child element called ‘spk’ that contains the public part of the signed PreKey as base64 encoded data, a child element called ‘spks’ that contains the signed PreKey signature as base64 encoded data and a child element called ‘ik’ that contains the public part of the IdentityKey as base64 encoded data. PreKeys are multiple elements called ‘pk’ that each contain the public part of one PreKey as base64 encoded data. PreKeys are wrapped in an element called ‘prekeys’ which is a child of the bundle element. The ‘spk’ and the ‘pk’s are tagged with an ‘id’-attribute which is a positive integer between 1 and 2^31 - 1 (the positive numbers of a signed 32 bit integer, without 0) that uniquely identifies the keys. The ‘spk’ and the ‘pk’s are considered separate, which means that an ‘spk’ can have the same ‘id’ as a ‘pk’. These ids are used to save bandwidth during key exchanges, which refer to the keys using their id instead of their full public parts.

                    -

                    When publishing bundles a client MUST make sure that the &nsbundles; node is configured to store multiple items. This is not the default with &xep0163;. If the node doesn’t exist yet it can be configured on the fly by using publish-options as described in XEP-0060 §7.1.5. The value for 'pubsub#max_items' in publish_options MUST be set to 'max'. If the node did exist and was configured differently the bundle publication will fail. Clients MUST then reconfigure the node as described in XEP-0060 §8.2.

                    +

                    When publishing bundles a client MUST make sure that the &nsbundles; node is configured to store multiple items. This is not the default with &xep0163;. If the node doesn’t exist yet it can be configured on the fly by using publish-options as described in &xep0060; §7.1.5. The value for 'pubsub#max_items' in publish_options MUST be set to 'max'. If the node did exist and was configured differently the bundle publication will fail. Clients MUST then reconfigure the node as described in XEP-0060 §8.2.

                    @@ -638,7 +638,7 @@

                    A Multi-User Chat room that supports OMEMO MUST be configured non-anonymous and SHOULD be configured members-only.

                    A participant wanting to send a message to a group chat MUST first retrieve the members list and then fetch the device list for each member (via pubsub and to their real JIDs) and then subsequently fetch all bundles referenced by the device lists.

                    -

                    On join a participant MUST request the member list, the admin list and the owner list as described in XEP-0045 §9.5, XEP-0045 §10.8, and XEP-0045 §10.5 respectively. The real JIDs from those three lists MUST be combined as the recipients of OMEMO encrypted messages. This includes recipients who are currently offline. Once joined a participant MUST keep track of affiliation changes that occur in the room. This is both for removals (users getting banned or have their affiliation set to none) and users becoming members, admins or owners.

                    +

                    On join a participant MUST request the member list, the admin list and the owner list as described in &xep0045; §9.5, XEP-0045 §10.8, and XEP-0045 §10.5 respectively. The real JIDs from those three lists MUST be combined as the recipients of OMEMO encrypted messages. This includes recipients who are currently offline. Once joined a participant MUST keep track of affiliation changes that occur in the room. This is both for removals (users getting banned or have their affiliation set to none) and users becoming members, admins or owners.

                    Before sending a message a participant MUST explicitly fetch device lists (if not already cached) for each of the members.

                    @@ -715,7 +715,7 @@

                    While OMEMO uses a Pubsub Service (&xep0060;) on the user’s account it has more requirments than those defined in &xep0163;. The requirements are:

                    • The pubsub service MUST persist node items, i.e., the feature 'persistent-items' is announced by the service.
                      • -
                    • The pubsub service MUST support publishing options as defined in XEP-0060 §7.1.5.
                      • +
                    • The pubsub service MUST support publishing options as defined in &xep0060; §7.1.5.
                    • The pubsub service MUST support 'max' as a value for the 'pubsub#persist_items' node configuration.
                    • The pubsub service MUST support the 'open' access model for node configuration and 'pubsub#access_model' as a publish option.
                    diff --git a/xep-0390.xml b/xep-0390.xml index 65dd0f32..7ec51db4 100644 --- a/xep-0390.xml +++ b/xep-0390.xml @@ -96,11 +96,11 @@

                    XMPP applications often face choices based on the disco#info (see &xep0030;) exposed by other entities. For example, for a client, knowledge about whether a roster entry is a &xep0369; entity or a normal client is important for user experience. It may also be desirable to provide indicators on the type of client a contact is using (mobile or not).

                    -

                    The canonical way to do so has been issueing XEP-0030 requests to the entities emitting presence. This, with the evergrowing featureset of XMPP, induces a lot of traffic for all involed parties, especially during startup. This is a waste of resources, as XEP-0030 information rarely changes and even more, common client configurations and versions share exactly the same information.

                    +

                    The canonical way to do so has been issueing &xep0030; requests to the entities emitting presence. This, with the evergrowing featureset of XMPP, induces a lot of traffic for all involed parties, especially during startup. This is a waste of resources, as XEP-0030 information rarely changes and even more, common client configurations and versions share exactly the same information.

                    &xep0115; has provided the XMPP ecosystem with a way to share this information with less bandwith. Entities using that protocol send a hash of their disco#info result along with presence or stream features. As those hashes can be cached, entities receiving these hashes only need to query the information for each hash once, greatly reducing the Service Discovery traffic.

                    -

                    However, XEP-0115 has two main flaws:

                    +

                    However, &xep0115; has two main flaws:

                      -
                    • The hash agility mechanism is underspecified. While it is possible to change the hash function, there is no clearly defined way to send multiple hashes at once to allow for a transition period. Even though it is technically not forbidden to send multiple XEP-0115 <c/> elements with different hashes at once, it is unclear how implementations behave when this happens. Possible issues lie in the use of caps optimization, as well as clients expecting only one <c/> element.
                      • +
                    • The hash agility mechanism is underspecified. While it is possible to change the hash function, there is no clearly defined way to send multiple hashes at once to allow for a transition period. Even though it is technically not forbidden to send multiple &xep0115; <c/> elements with different hashes at once, it is unclear how implementations behave when this happens. Possible issues lie in the use of caps optimization, as well as clients expecting only one <c/> element.
                    • The algorithm to generate the input for the hash function has flaws as pointed out by Waqas Hussain &mlwaqas1;. Even though these flaws have partially been fixed and worked around, the fundamental problem that the structural information of the individual strings from the disco response is lost persists.
                     @@ -127,8 +127,8 @@
                    Capability Hash
                    A tuple of hash function and hash value generated as described in the Hash Function Input section.
                    Capability Hash Cache
                    A mapping which maps &hashes; to disco#info <query/> responses with an empty 'node' attribute.
                     -
                    Cabability Hash Node
                    The name of a XEP-0030 'node' for a given &hash;. See Construction of Capability Hash Nodes.
                     -
                    Capability Hash Set
                    A set of &hashes; which cover the same XEP-0030 response, possibly in the form of a <c/> element with &xep0300; <hash/> children.
                     +
                    Cabability Hash Node
                    The name of a &xep0030; 'node' for a given &hash;. See Construction of Capability Hash Nodes.
                     +
                    Capability Hash Set
                    A set of &hashes; which cover the same &xep0030; response, possibly in the form of a <c/> element with &xep0300; <hash/> children.
                    Generating Entity
                    An entity which emits a &hashset; to other entities.
                    Processing Entity
                    An entity which receives and processes a &hashset; from a &genent;.
                    Query Interception
                    Server-side processing of disco#info queries directed to a resource based on the &hashsets; published by that resource.
                     @@ -199,7 +199,7 @@ -

                    The entity picks a set of hash functions it wishes to use. The set of hash functions MUST include at least one hash function which MUST be implemented according to &xep0300; and SHOULD NOT include any hash functions which MUST NOT be supported according to XEP-0300.

                    +

                    The entity picks a set of hash functions it wishes to use. The set of hash functions MUST include at least one hash function which MUST be implemented according to &xep0300; and SHOULD NOT include any hash functions which MUST NOT be supported according to &xep0300;.

                    Using the algorithm from the previous subsection, the entity calculates the input for the hash functions. It then runs the input through each hash function individually. The resulting tuples of hash algorithm and hash values constitute the &hashset;.

                     @@ -845,8 +845,8 @@ cDp0aW1lHxw=

                    It is RECOMMENDED that entities use the caching mechanisms outlined in the Caching Business Rules. Entities MAY share caches among connections and accounts.

                    -

                    &genents; are encouraged to also emit &xep0115; <c/> elements in their presence updates (as specified in XEP-0115) for a reasonable transition period.

                    -

                    When receiving a &hashset; along with XEP-0115 capabilities, a &procent; MAY obtain the disco#info <query/> for verification from a XEP-0115 based cache instead of querying the &genent; directly. A &procent; MUST NOT use disco#info data from a XEP-0115 cache without verification if a ∩︀ <c/> element is available.

                    +

                    &genents; are encouraged to also emit &xep0115; <c/> elements in their presence updates (as specified in &xep0115;) for a reasonable transition period.

                    +

                    When receiving a &hashset; along with &xep0115; capabilities, a &procent; MAY obtain the disco#info <query/> for verification from a XEP-0115 based cache instead of querying the &genent; directly. A &procent; MUST NOT use disco#info data from a XEP-0115 cache without verification if a ∩︀ <c/> element is available.

                     @@ -971,8 +971,8 @@ cDp0aW1lHxw=

                    Thanks to the authors of &xep0115; for coming up with the original idea of using presence broadcast to convey service discovery information, as well as the optimization strategies.

                    -

                    The note below the example in Advertisement of Support and Capabilities by Servers has been copied verbatimly from XEP-0115.

                    -

                    Thanks to Waqas Hussain for originally (to my knowledge) pointing out the security flaws in XEP-0115 (see &mlwaqas1;).

                    +

                    The note below the example in Advertisement of Support and Capabilities by Servers has been copied verbatimly from &xep0115;.

                    +

                    Thanks to Waqas Hussain for originally (to my knowledge) pointing out the security flaws in &xep0115; (see &mlwaqas1;).

                    Thanks to Dave Cridland, Georg Lukas, Link Mauve, Sebastian Riese, Florian Schmaus and Sam Whited for their input, editorial and otherwise.

                     diff --git a/xep-0395.xml b/xep-0395.xml index b592c3d0..3b16b50c 100644 --- a/xep-0395.xml +++ b/xep-0395.xml @@ -143,7 +143,7 @@ O, what a rogue and peasant slave am I! -

                    In order to atomically compare-and-publish an item, a client sends a XEP-0060 <publish/> IQ +

                    In order to atomically compare-and-publish an item, a client sends a &xep0060; <publish/> IQ with a 'pubsub#prev_item_cap_value' precondition publishing option, set to the value of the currently assumed CAP-V of the latest item of the node.

                    diff --git a/xep-0396.xml b/xep-0396.xml index 305453b2..cbc3331b 100644 --- a/xep-0396.xml +++ b/xep-0396.xml @@ -57,14 +57,14 @@

                    &xep0391; can be used to utilize different end-to-end encryption methods to secure Jingle Transports, eg. in the context of &xep0234;. This document aims to extend &xep0391; to allow the use of OMEMO encryption with Jingle transports. To achieve this goal, this protocol extension makes use of OMEMOs KeyTransportElements.

                    -

                    Conveniently the OMEMO protocol already provides a way to transport key material to another entity. So called KeyTransportElements are basically normal OMEMO MessageElements, but without a payload, so the contained key can be used for something else (see Section 4.6 of XEP-0384). This extension uses the key encrypted in the KeyTransportMessages <key> attribute and initialization vector from the <iv> attribute to secure Jingle Transports. The key corresponds to the Transport Key of XEP-0391, while the iv corresponds to the Initialization Vector. The KeyTransportMessage is the equivalent to the Envelope Element. Note that within the Envelope Element, the Transport Key is encrypted with the OMEMO ratchet.

                    +

                    Conveniently the OMEMO protocol already provides a way to transport key material to another entity. So called KeyTransportElements are basically normal OMEMO MessageElements, but without a payload, so the contained key can be used for something else (see Section 4.6 of &xep0384;). This extension uses the key encrypted in the KeyTransportMessages <key> attribute and initialization vector from the <iv> attribute to secure Jingle Transports. The key corresponds to the Transport Key of XEP-0391, while the iv corresponds to the Initialization Vector. The KeyTransportMessage is the equivalent to the Envelope Element. Note that within the Envelope Element, the Transport Key is encrypted with the OMEMO ratchet.

                    Unfortunately &xep0384; determines the type of the transported key to be AES-128-GCM-NoPadding, so no other configuration can be used in the context of this extension.

                    Since OMEMO deviceIds are not bound to XMPP resources, the initiator MUST encrypt the Transport Key for every device of the recipient.

                     -

                    In order to transport a key to the responder, the initiator creates a fresh AES-128-GCM-NoPadding Transport Key and Initialization Vector and generates an OMEMO KeyTransportElement from it as described in XEP-0384. This is then added as a child of the JET <security> element. The 'cipher' attribute MUST be set to 'aes-128-gcm-nopadding:0' (see the ciphers section of XEP-0391). The value of the 'type' attribute must be set to the namespace of the used version of XEP-0384 &VNOTE;.

                    +

                    In order to transport a key to the responder, the initiator creates a fresh AES-128-GCM-NoPadding Transport Key and Initialization Vector and generates an OMEMO KeyTransportElement from it as described in &xep0384;. This is then added as a child of the JET <security> element. The 'cipher' attribute MUST be set to 'aes-128-gcm-nopadding:0' (see the ciphers section of XEP-0391). The value of the 'type' attribute must be set to the namespace of the used version of XEP-0384 &VNOTE;.

                    Compared to the existing stream resumption mechanism of XEP-0198 + url='http://xmpp.org/extensions/xep-0198.html#resumption'>&xep0198; § 5, the approach defined herein reduces the round trips required to resume a stream to exactly one. This is achieved by using just a secure short-lived token to resume the @@ -227,12 +227,12 @@

                    1. The host provided in the optional 'location' attribute qualified by the 'https://xmpp.org/extensions/isr/0' namespace found in the - <enabled/> element of XEP-0198 (the + <enabled/> element of &xep0198; (the "isr:location").
                    2. The hosts determined by means of &xep0368;.
                    3. The host announced in the 'location' attribute of the - <enabled/> Nonza defined in XEP-0198.
                      4. + <enabled/> Nonza defined in &xep0198;.
                    4. Standard host lookup mechanisms.
                    diff --git a/xep-0398.xml b/xep-0398.xml index 22b1c7c0..610506a3 100644 --- a/xep-0398.xml +++ b/xep-0398.xml @@ -67,11 +67,11 @@ -

                    &xep0084; and &xep0153; are usually considered to stand in competition with each other. XEP-0084 even talks about superseding XEP-0153 in the future. While XEP-0084 provides a more efficient interface to upload avatars by separating metadata and data (thus saving the client from having to download its own avatar on every connect) it has the significant downside of not working with &xep0045;.

                    -

                    Server implementations can aid to resolve this conflict by automatically putting avatars uploaded with XEP-0084 into XEP-0153 storage and vice versa. This allows clients to use the more efficient XEP-0084 for uploading avatars and XEP-0153 to retrieve avatars in Multi-User Chats.

                    +

                    &xep0084; and &xep0153; are usually considered to stand in competition with each other. &xep0084; even talks about superseding XEP-0153 in the future. While XEP-0084 provides a more efficient interface to upload avatars by separating metadata and data (thus saving the client from having to download its own avatar on every connect) it has the significant downside of not working with &xep0045;.

                    +

                    Server implementations can aid to resolve this conflict by automatically putting avatars uploaded with &xep0084; into XEP-0153 storage and vice versa. This allows clients to use the more efficient XEP-0084 for uploading avatars and XEP-0153 to retrieve avatars in Multi-User Chats.

                     -

                    The conversion is transparent to the uploading entity. However an entity might want to discover if a service will be performing the conversion from XEP-0084 to XEP-0153 so it doesn’t have to maintain a vCard avatar itself.

                    +

                    The conversion is transparent to the uploading entity. However an entity might want to discover if a service will be performing the conversion from &xep0084; to XEP-0153 so it doesn’t have to maintain a vCard avatar itself.

                    The service MUST include a &xep0030; feature of "urn:xmpp:pep-vcard-conversion:0" on the account.

                    ]]>                     -

                    Modern clients are expected to use PEP (XEP-0084) as the interface to upload their avatar and use vCard (XEP-0153) only as a read only fallback. Thus a service MUST support conversion from PEP to vCard. A service MAY support conversion from vCard to PEP in order to display avatars in clients that only support XEP-0084.

                    +

                    Modern clients are expected to use PEP (&xep0084;) as the interface to upload their avatar and use vCard (XEP-0153) only as a read only fallback. Thus a service MUST support conversion from PEP to vCard. A service MAY support conversion from vCard to PEP in order to display avatars in clients that only support XEP-0084.

                    Upon receiving a publication request to the 'urn:xmpp:avatar:metadata' node the service MUST look up the corresponding item published in the 'urn:xmpp:avatar:data' node and store the content of the data element as a photo in the vcard. Services MUST consider the fact that the metadata node might contain multiple info elements and MUST pick the info element that does not point to an exernal URL. Services SHOULD verify that the SHA-1 hash of the image matches the id.

                     -

                    Upon receiving a vCard publication request with a valid photo attached to it a service MUST first publish an item to the 'urn:xmpp:avatar:data' node on behalf of the requesting entity. The id of that item MUST be the SHA-1 hash of the image as described in XEP-0084. Afterwards the service MUST publish a new item to the 'urn:xmpp:avatar:metadata' node with one info element that represents the newly published image using the type value from the vCard as a type attribute in the info element.

                    +

                    Upon receiving a vCard publication request with a valid photo attached to it a service MUST first publish an item to the 'urn:xmpp:avatar:data' node on behalf of the requesting entity. The id of that item MUST be the SHA-1 hash of the image as described in &xep0084;. Afterwards the service MUST publish a new item to the 'urn:xmpp:avatar:metadata' node with one info element that represents the newly published image using the type value from the vCard as a type attribute in the info element.

                    After publication the service SHOULD send out notification messages to all subscribers of the metadata node.

                                         -

                    The “Business Rules” section of XEP-0153 tells entities to include a hash of the vCard avatar in their presence. However this requires clients to retrieve the avatar on every connect to calculate the hash. To avoid this, services MUST include the hash on behalf of their users in every available presence that does not contain an empty photo element wrapped in an x element qualified by the 'vcard-temp:x:update' namespace. Empty x elements qualified by the 'vcard-temp:x:update' namespace (those without a photo element as child) MUST be overwritten. Presences where the content of the photo element is not empty and not equal to the hash calculated by the service MAY be overwritten.

                    +

                    The “Business Rules” section of &xep0153; tells entities to include a hash of the vCard avatar in their presence. However this requires clients to retrieve the avatar on every connect to calculate the hash. To avoid this, services MUST include the hash on behalf of their users in every available presence that does not contain an empty photo element wrapped in an x element qualified by the 'vcard-temp:x:update' namespace. Empty x elements qualified by the 'vcard-temp:x:update' namespace (those without a photo element as child) MUST be overwritten. Presences where the content of the photo element is not empty and not equal to the hash calculated by the service MAY be overwritten.

                    ]]> -

                    Implementing clients SHOULD use the more efficient XEP-0084 to access their own avatar storage and implement XEP-0153 only to download avatars from other entities if they do not have mutual presence subscription with said entity. (For example participants in a Multi-User Chat.)

                    +

                    Implementing clients SHOULD use the more efficient &xep0084; to access their own avatar storage and implement XEP-0153 only to download avatars from other entities if they do not have mutual presence subscription with said entity. (For example participants in a Multi-User Chat.)

                    Services will inject the hash in directed presences automatically but will not resend the presence if the avatar gets updated. Thus clients MAY resend directed available presence to all Multi-User Chats after receiving a 'urn:xmpp:avatar:metadata' update notification. The service will then inject an updated version of the hash. To avoid sending unnecassary presence updates, resending should only occur if the service annouces the 'urn:xmpp:pep-vcard-conversion:0' feature.

                     diff --git a/xep-0401.xml b/xep-0401.xml index 2c6e7516..78e12b6b 100644 --- a/xep-0401.xml +++ b/xep-0401.xml @@ -111,7 +111,7 @@

                    This specification makes use of XMPP URIs. The basic URI scheme for XMPP is defined in &rfc5122; and extended in &xep0147; and &xep0379;. Furthermore, this heavily builds upon the blocks provided in - XEP-0379 for landing page and roster subscription. + &xep0379; for landing page and roster subscription.

                    To create out-of-band invitation links, Romeo's server needs to implement @@ -212,7 +212,7 @@

                    The landing page that the generated URL points to should correspond to - the format described in XEP-0379 §3.3, and it needs to + the format described in &xep0379; §3.3, and it needs to convey the following information:

                    • A short text that this is an XMPP invitation from Romeo.
                      • @@ -239,7 +239,7 @@ action for the presented xmpp:inviter@example.com?roster;... URI is to add the inviter to Juliet's roster. This should be performed as described in - §3.4 of XEP-0379, by sending a presence subscription + §3.4 of &xep0379;, by sending a presence subscription request containing the 'preauth' token.

                      If Juliet already has Romeo in her roster, her client should open the appropriate chat interface instead.

                      @@ -262,7 +262,7 @@ added to her roster with a full presence subscription.

                      If Juliet chooses to login or register with a different server, her client must complete the respective process and issue a subscription - request as described in §3.4 of XEP-0379.

                      + request as described in §3.4 of &xep0379;.

                      diff --git a/xep-0402.xml b/xep-0402.xml index 1970caca..43fa5c52 100644 --- a/xep-0402.xml +++ b/xep-0402.xml @@ -454,7 +454,7 @@ -

                      Security considerations related to object persistence via publish-subscribe are described in XEP-0060 and XEP-0223.

                      +

                      Security considerations related to object persistence via publish-subscribe are described in &xep0060; and XEP-0223.

                      The client needs to make sure that the server actually supports the "http://jabber.org/protocol/pubsub#publish-options" feature, before relying on it. If it's not supported, the client should configure the '&namespace;' node first (see xep-0060), before adding any bookmarks.

                       diff --git a/xep-0418.xml b/xep-0418.xml index 57dc7574..586b7ae9 100644 --- a/xep-0418.xml +++ b/xep-0418.xml @@ -94,7 +94,7 @@ ]]> -

                      The other error conditions defined in RFC 6120 could also be returned if appropriate.

                      +

                      The other error conditions defined in &rfc6120; could also be returned if appropriate.

                       @@ -149,7 +149,7 @@ not.

                      In the absence of DNSSEC information, a DoX resolver can give a requestor invalid data in response to a DNS query. A DoX capable requestor MUST discard any responses not specifically requested, this prohibition does not guarantee protection against invalid data, but it does reduce the risk.

                      -

                      If a server receives a dns request directed to a full JID &LOCALFULL; associated with a registered account but there is no connected resource matching the 'to' address, RFC 6120 requires it to reply with a &unavailable; error and set the 'from' address of the IQ-error to the full JID provided in the 'to' address of the dns request. If a connected resource receives a dns request but it does not want to reveal its network availability to the sender for any reason (e.g., because the sender is not authorized to know the connected resource's availability), then it too MUST reply with a &unavailable; error. This consistency between the server response and the resolver response helps to prevent presence leaks.

                      +

                      If a server receives a dns request directed to a full JID &LOCALFULL; associated with a registered account but there is no connected resource matching the 'to' address, &rfc6120; requires it to reply with a &unavailable; error and set the 'from' address of the IQ-error to the full JID provided in the 'to' address of the dns request. If a connected resource receives a dns request but it does not want to reveal its network availability to the sender for any reason (e.g., because the sender is not authorized to know the connected resource's availability), then it too MUST reply with a &unavailable; error. This consistency between the server response and the resolver response helps to prevent presence leaks.

                       diff --git a/xep-0436.xml b/xep-0436.xml index f7612354..59f6e6d0 100644 --- a/xep-0436.xml +++ b/xep-0436.xml @@ -153,16 +153,16 @@

                      A MUC that supports presence versioning MUST broadcast presence for all affiliated users, including those who are currently 'unavailable'. - XEP-0045 documents the status code '102', which is used to indicate that a MUC shows unavailable members. + &xep0045; documents the status code '102', which is used to indicate that a MUC shows unavailable members.

                      The only exception is when a MUC has been explicitly configured to only broadcast presence from occupants above a certain affiliation, - (see the presence broadcast section of XEP-0045). + (see the presence broadcast section of &xep0045;).

                      In order for a user to permanently join a room, and therefore become affiliated so that they are included in presence broadcasts, they MAY be allowed to register themselves as members in the MUC. - XEP-0045 describes in section 7.10 "Registering with a Room + &xep0045; describes in section 7.10 "Registering with a Room how a user may register themselves with a room, thereby receiving the "member" affiliation and having their preferred nickname reserved in that room.

                      diff --git a/xep-0445.xml b/xep-0445.xml index 9e464343..42dec2b4 100644 --- a/xep-0445.xml +++ b/xep-0445.xml @@ -99,7 +99,7 @@ indicate that the token can also be used to register an account on that server (ibr=y). If the receiving client already has an account configured, it may skip account registration and simply add the contact - as defined in XEP-0379. The client may also register a new + as defined in &xep0379;. The client may also register a new account on the domain of the proposed contact, allowing the user to enter the desired account name.

                      xmpp:romeo@example.com?roster;preauth=TOKEN;ibr=y diff --git a/xep-0455.xml b/xep-0455.xml index 86498ac1..fafa3259 100644 --- a/xep-0455.xml +++ b/xep-0455.xml @@ -63,7 +63,7 @@                       -

                      To make such discovery possible, we specify a &xep0128; mechanism that a server SHOULD return in response to service discovery information ("disco#info") requests sent to the bare domain of the server. This information MUST be scoped using a FORM_TYPE of "urn:xmpp:sos:0" (as already specified in XEP-0128) and data form fields registered for this purpose as defined in the XMPP Registrar Considerations section of this document.

                      +

                      To make such discovery possible, we specify a &xep0128; mechanism that a server SHOULD return in response to service discovery information ("disco#info") requests sent to the bare domain of the server. This information MUST be scoped using a FORM_TYPE of "urn:xmpp:sos:0" (as already specified in &xep0128;) and data form fields registered for this purpose as defined in the XMPP Registrar Considerations section of this document.

                      Values of 'external-status-addresses' form field MUST be valid URIs, i.e. comply with the 'xs:anyURI' datatype of &w3xmlschema2;.

                      The ®ISTRAR; includes the following information in its registries.

                      -

                      &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and XEP-0128 describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "urn:xmpp:sos:0" FORM_TYPE.

                      +

                      &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and &xep0128; describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "urn:xmpp:sos:0" FORM_TYPE.

                      urn:xmpp:sos:0 diff --git a/xep-0472.xml b/xep-0472.xml index 74364b19..e98f5052 100644 --- a/xep-0472.xml +++ b/xep-0472.xml @@ -381,7 +381,7 @@

                      This specification re-uses the schema for the Atom content format, i.e., the 'http://www.w3.org/2005/Atom' namespace (see - RFC 4287 + &rfc4287; ).

                      diff --git a/xep-0473.xml b/xep-0473.xml index a65a25ef..2358bc7d 100644 --- a/xep-0473.xml +++ b/xep-0473.xml @@ -125,7 +125,7 @@

                      Juliet wants to create a private blog (using &xep0277;) that she only share with her confidante and her lover. To make sure that her family, who manages her XMPP server, can't read the content, she want to use end-to-end encryption.

                      To do so, her client creates a "shared secret" by generating a cryptographically strong key that will be used to symmetrically encrypt new items. This key MUST be associated with an ID, which MUST be an unique sequence of characters usable in an XML attribute. She will later share this key with entities allowed to access or publish on the blog as explained below.

                      From now on, all items that Juliet publishes on the node SHOULD be symmetrically encrypted with the shared secret by using OpenPGP symmetric encryption.

                      -

                      To publish an encrypted item, an <encrypted/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace MUST be used as payload. This element MUST contain a 'secret' attribute whose value is the ID of the shared secret used. The content of the element is a base64 encoded Symmetric-Key Encrypted Session Key Packet as specified at RFC 4880 § 5.3 (in a similar way as secret key backup is encoded in XEP-0373). The encrypted content is the item payload that would normally be used.

                      +

                      To publish an encrypted item, an <encrypted/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace MUST be used as payload. This element MUST contain a 'secret' attribute whose value is the ID of the shared secret used. The content of the element is a base64 encoded Symmetric-Key Encrypted Session Key Packet as specified at &rfc4880; § 5.3 (in a similar way as secret key backup is encoded in XEP-0373). The encrypted content is the item payload that would normally be used.

                      The encrypted node SHOULD have a "whitelist" access model as specified in &xep0060;. Juliet's client ensure that either by creating a new node with suitable access model, or by changing the access model of existing node.

                      The ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

                       -

                      &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and XEP-0128 describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "http://jabber.org/network/serverinfo" FORM_TYPE.

                      +

                      &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and &xep0128; describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "http://jabber.org/network/serverinfo" FORM_TYPE.

                      http://jabber.org/network/serverinfo
        Type 2 Verified Acceptable Self-signedXMPP 1.0 "XMPP 1.0" is defined in RFC 3920 and includes STARTTLS and SASL negotiation. and Server DialbackXMPP 1.0 "XMPP 1.0" is defined in &rfc3920; and includes STARTTLS and SASL negotiation. and Server Dialback type2.lit juliet@type2.lit
        timestamp xs:datetimeUTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of XEP-0082)UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of &xep0082;) 2004-02-19T21:12Z Piped directly through from query timestamp field.