diff --git a/xep-0001.xml b/xep-0001.xml index 62de3a3b..4b83834f 100644 --- a/xep-0001.xml +++ b/xep-0001.xml @@ -846,6 +846,6 @@ THE SOFTWARE. - ]]> +]]> diff --git a/xep-0003.xml b/xep-0003.xml index f738e08c..55e80758 100644 --- a/xep-0003.xml +++ b/xep-0003.xml @@ -90,14 +90,14 @@ 600 - ]]> +]]> 1.2.3.4 - ]]> +]]>

At this point, the PASS service is now listening on the given IP and port for incoming connections on behalf of the Jabber Entity. The provided IP and port can now be sent to any other entity as a connection point, for file transfers or any other use.

The default behavior for the PASS service is to listen on the port forever, unless the requesting client specifies an <expire/> value (in seconds). If the service is not configured with an expire value, it will not timeout the connection, and will start listening on the port again after one of the two sides disconnects.

@@ -125,7 +125,7 @@ 1.2.3.4 - ]]> +]]> - ]]> +]]>

The entity SHOULD now immediately connect to the given proxy IP and port, and upon connection all data written to that socket will be copied to the client connection, and vice-versa. Any disconnect on either side MUST cause a disconnect on the other (initiated by the service). If the IQ set to the entity fails or returns an error, the client socket MUST be dropped as well. The client XML element provides the information about the remote end of the incoming socket.

Abuse in bandwidth or resources could become an issue, so PASS implementations SHOULD include strict and detailed rate and usage limits, allowing only limited usage by single entities and rate-limiting bandwidth used if necessary for both single connections or overall usage. These limits are implementation-specific.

@@ -152,7 +152,7 @@ 1.2.3.4 - ]]> +]]> - ]]> +]]>

This tells the server to listen once, and then close the port. Even if the <expire/> has not been met, the <oneshot/> overrides that and shuts down the listening port. When this happens the server notifies the client with the following packet:

@@ -175,7 +175,7 @@ 1.2.3.4 - ]]> +]]> - ]]> +]]>

This tells the server to explicitly shut down a listening port. Useful for when the client shuts down and can tell the PASS service to recycle the port. The server sends back:

@@ -197,7 +197,7 @@ 1.2.3.4 - ]]> +]]> - ]]> +]]>
@@ -246,7 +246,7 @@ from='you@jabber.org/resource'> - ]]> +]]>

The other client SHOULD send back:

4.3.2.1 - ]]> +]]>

Obviously the port is not going to be known, but the IP address will let you authenticate the JID via the PASS service since the PASS service tells you the <client/> information upon a connection.

@@ -273,7 +273,7 @@ 1.2.3.4 - ]]> +]]>

Your client would send back:

- ]]> +]]>
Code
@@ -354,6 +354,6 @@ - ]]> +]]> diff --git a/xep-0004.xml b/xep-0004.xml index a884ae48..448f090a 100644 --- a/xep-0004.xml +++ b/xep-0004.xml @@ -169,7 +169,7 @@ - ]]> +]]>

The &X; element qualified by the 'jabber:x:data' namespace SHOULD be included either directly as a first-level child of a &MESSAGE; stanza or as a second-level child of an &IQ; stanza (where the first-level child is an element qualified by a "wrapper" namespace); see also the restrictions enumerated below.

The OPTIONAL <title/> and <instructions/> elements enable the form-processing entity to label the form as a whole and specify natural-language instructions to be followed by the form-submitting entity. The XML character data for these elements SHOULD NOT contain newlines (the \n and \r characters), and any handling of newlines (e.g., presentation in a user interface) is unspecified herein; however, multiple instances of the <instructions/> element MAY be included.

@@ -299,7 +299,7 @@ . . - ]]> +]]>

Each of these elements MUST contain one or more <field/> children. The <reported/> element defines the data format for the result items by specifying the fields to be expected for each item; for this reason, the <field/> elements SHOULD possess a 'type' attribute and 'label' attribute in addition to the 'var' attribute, and SHOULD NOT contain a <value/> element. Each <item/> element defines one item in the result set, and MUST contain each field specified in the <reported/> element (although the XML character data of the <value/> element MAY be null).

 @@ -321,7 +321,7 @@ node='create' action='execute'/> - ]]> +]]>

The hosting service then returns a data form to the user:

- ]]> +]]>

The user then submits the configuration form:

- ]]> +]]>

The service then returns the results to the user:

- ]]> +]]>

Now that the user has created this search bot, let us suppose that one of the friends he has invited decides to try it out by sending a search request:

@@ -485,7 +485,7 @@ node='search' action='execute'/> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> @@ -592,7 +592,7 @@ id='disco1'> - ]]> +]]> - ]]> +]]>

If an entity supports data forms indirectly through inclusion of data forms in a wrapper namespace (rather than directly within a &MESSAGE; stanza), it MUST NOT advertise support for the 'jabber:x:data' namespace, since support is implicit in support for the wrapper protocol.

 @@ -733,7 +733,7 @@ - ]]> +]]>

The following substantive protocol changes have been made while this specification has been in the Final state:

diff --git a/xep-0009.xml b/xep-0009.xml index f956e8ed..69c47f74 100644 --- a/xep-0009.xml +++ b/xep-0009.xml @@ -89,7 +89,7 @@ - ]]> +]]> - ]]> +]]>

If the requesting entity does not have sufficient permissions to perform remote procedure calls, the responding entity MUST return a &forbidden; error:

- ]]> +]]>

If an entity supports the Jabber-RPC protocol, it SHOULD advertise that fact in response to &xep0030; information ("diso#info") requests by returning an identity of "automation/rpc" and a feature of "jabber:iq:rpc":

@@ -137,7 +137,7 @@ id='disco1'> - ]]> +]]> - ]]> +]]>

An entity that supports Jabber-RPC SHOULD establish a "whitelist" of entities that are allowed to perform remote procedure calls and MUST return a &forbidden; error if entities with insufficient permissions attempt such calls.

@@ -324,6 +324,6 @@ - ]]> +]]> diff --git a/xep-0011.xml b/xep-0011.xml index 6736e32d..87c536f3 100644 --- a/xep-0011.xml +++ b/xep-0011.xml @@ -471,7 +471,7 @@ - ]]> +]]>

The 'jabber:iq:browse' namespace has been in use for quite some time. However, live browsing still needs to be better defined by a generic publication/subscription system. It is assumed that when such a system is defined, updates to this document will be made. It is, however, possible that no futher changes to jabber:iq:browse itself may be needed.

diff --git a/xep-0012.xml b/xep-0012.xml index 71a110a7..4e97a390 100644 --- a/xep-0012.xml +++ b/xep-0012.xml @@ -87,7 +87,7 @@ type='get'> - ]]> +]]>

The target entity MUST return either an IQ-result or an IQ-error. When returning an IQ-result, the target entity sends an &IQ; stanza of type='result' containing a &QUERY; element with a REQUIRED 'seconds' attribute and OPTIONAL XML character data.

- ]]> +]]>

The requesting entity interprets the IQ-result based on the responding entity's JID type in order to determine the meaning of the information. Specifically, the information means something different depending on the identity of the responding entity:

  1. An account registered on an XMPP server, with a JID of the form &LOCALBARE;.
    2. @@ -114,7 +114,7 @@ type='get'> - ]]> +]]>

    As specified in &xmppcore; and &xmppim;, an IQ stanza of type "get" sent to a bare JID &LOCALBARE; is handled by the user's server on the user's behalf, not delivered to one or more connected or available resources.

    If the requesting entity is not authorized to view the user's presence information (normally via a presence subscription as defined in XMPP-IM), the user's server MUST NOT return last activity information but instead MUST return a &forbidden; error in response to the last activity request.

    - ]]> +]]>

    If the requesting entity is authorized to view the user's presence information, the server shall return information about the last presence activity recorded by the server for that user.

    Heading Home - ]]> +]]>

    In this example, the user logged out fifteen minutes and three seconds ago, and when they logged out they sent a presence stanza of type='unavailable' whose <status/> element contained the text "Heading Home".

    If the user has at least one connected or available resource when the server receives the request, the response MUST (subject to local security policies) contain an empty <query/> element whose 'seconds' attribute is set to a value of '0'.

    @@ -148,7 +148,7 @@ type='get'> - ]]> +]]>

    In this case, the user's server shall either deliver the IQ to an available resource or respond on behalf of the user.

    In particular, as with the offline query use case above, if the requesting entity is not authorized to view the user's presence information (normally via a presence subscription as defined in XMPP IM), the user's server MUST NOT deliver the IQ-get to an available resource but instead MUST return a &forbidden; error in response to the last activity request.

    - ]]> +]]>

    If the user's server delivers the IQ-get to one of the user's available resources, the user's client MAY respond with the idle time of the user (i.e., the last time that a human user interacted with the client application).

    - ]]> +]]>

    In the foregoing example, the user has been idle for about two minutes.

    Support for this functionality is OPTIONAL. A client that does not support the protocol, or that does not wish to divulge this information, MUST return a &unavailable; error.

    - ]]> +]]>

    If there is no available resource matching the &LOCALBARE; in the 'to' attribute of the request, the server MUST follow the rules in XMPP IM in order to determine what error stanza to return.

    @@ -193,7 +193,7 @@ type='get'> - ]]> +]]> - ]]> +]]>

    In this example, the server has been running for a little more than 34 hours.

     @@ -213,7 +213,7 @@ type='get'> - ]]> +]]> - ]]> +]]>

    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.

     @@ -270,6 +270,6 @@ - ]]> +]]> diff --git a/xep-0013.xml b/xep-0013.xml index 9aa0efad..c4e056f9 100644 --- a/xep-0013.xml +++ b/xep-0013.xml @@ -124,7 +124,7 @@ - ]]> +]]>     - ]]> +]]>

    If the server supports this protocol, it MUST return a <feature/> element in the disco result with the 'var' attribute set to the namespace name for this protocol: 'http://jabber.org/protocol/offline'.

    @@ -144,7 +144,7 @@ - ]]> +]]>

    If the server supports retrieval of the number of messages, it MUST include &xep0128; data specifying the number of messages:

    @@ -164,7 +164,7 @@     - ]]> +]]>

    Upon receiving a service discovery request addressed to a node of "http://jabber.org/protocol/offline" (either a disco#info request as in this use case or a disco#items request as in the next use case), the server MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. Thus the user is now free to send initial presence (if desired) and to engage in normal IM activities while continuing to read through offline messages. However, once the user sends presence, the user's server MUST deliver in-session messages as usual; this document applies to offline messages only. In addition, if the user authenticates and provides presence for another resource while the first (non-flood) resource still has an active session, the server MUST NOT flood the second resource with the offline message queue.

     @@ -174,7 +174,7 @@ - ]]> +]]>

    The server now MUST return headers for all of the user's offline messages. So that the user may determine whether to view a full message, the header information provided MUST include the full Jabber ID of the sender (encoded in the 'name' attribute) and a unique identifier for the message within the user's "inbox" (encoded in the 'node' attribute), so that the user may appropriately manage (view or remove) the message.

    @@ -202,7 +202,7 @@ name='juliet@capulet.com/balcony'/>     - ]]> +]]>

    If the requester is a JID other than an authorized resource of the user (i.e., the user@host of the requester does not match the user@host of the user), the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return an ¬found; error. If there are no offline messages for this user, the server MUST return an empty query as defined in XEP-0030. (For information about the syntax of error conditions, refer to &xep0086;.)

    The syntax and semantics of the attributes are as follows:

      @@ -220,7 +220,7 @@ node='2003-02-27T22:52:37.225Z'/> - ]]> +]]>

      If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return an ¬found; error. Otherwise, the server MUST send the requested message(s) plus an IQ result:

      @@ -231,7 +231,7 @@ - ]]> +]]>

      In order to distinguish incoming messages, each message MUST contain the node value. It is RECOMMENDED for the server to include &xep0091; information in the message.

      @@ -246,11 +246,11 @@ node='2003-02-27T22:52:37.225Z'/> - ]]> +]]>

      If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a ¬found; error. Otherwise, the server MUST remove the messages and inform the user:

      - ]]> +]]>

      The user retrieves all message by sending the "fetch" command:

      @@ -260,7 +260,7 @@ - ]]> +]]>

      If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a ¬found; error. Otherwise, the server MUST retrieve all messages and inform the user:

      @@ -271,7 +271,7 @@ - ]]> +]]>

      A client MAY retrieve all messages without first requesting message headers. In this case, the server MUST return all of the user's offline messages and also MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. That is, the semantics here are the same as for requesting message headers.

       @@ -282,11 +282,11 @@ - ]]> +]]>

      If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a ¬found; error. Otherwise, the server MUST remove all messages and inform the user:

      - ]]> +]]>       @@ -377,7 +377,7 @@ C: request and remove offline messages, send and receive messages, etc. XEP-0013 - ]]> +]]>

      The XMPP Registrar includes "http://jabber.org/protocol/offline" in its registry of well-known Service Discovery nodes.

      @@ -397,7 +397,7 @@ C: request and remove offline messages, send and receive messages, etc. type='text-single' label='N/A'/> - ]]> +]]>       @@ -441,6 +441,6 @@ C: request and remove offline messages, send and receive messages, etc. - ]]> +]]> diff --git a/xep-0016.xml b/xep-0016.xml index f2dd5dc1..81e3e4ee 100644 --- a/xep-0016.xml +++ b/xep-0016.xml @@ -132,7 +132,7 @@ - ]]> +]]>

      If the type is "jid", then the 'value' attribute MUST contain a valid Jabber ID. JIDs SHOULD be matched in the following order:

      1. <user@domain/resource> (only that resource matches)
        2. @@ -176,7 +176,7 @@ - ]]> +]]> @@ -187,14 +187,14 @@ - ]]> +]]> - ]]> +]]> @@ -207,14 +207,14 @@ - ]]> +]]> - ]]> +]]> @@ -227,14 +227,14 @@ - ]]> +]]> - ]]> +]]> @@ -255,7 +255,7 @@ - ]]> +]]>

        In this example, the user has three lists: (1) 'public', which allows communications from everyone except one specific entity (this is the default list); (2) 'private', which allows communications only with contacts who have a bidirectional subscription with the user (this is the active list); and (3) 'special', which allows communications only with three specific entities.

        If the user attempts to retrieve a list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user:

        - ]]> +]]>

        The user is allowed to retrieve only one list at a time. If the user attempts to retrieve more than one list in the same request, the server MUST return a <bad request/> stanza error to the user:

        @@ -282,7 +282,7 @@ xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> - ]]> +]]>

        In order to set or change the active list currently being applied by the server, the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains an empty <active/> child element possessing a 'name' attribute whose value is set to the desired list name.

        @@ -292,11 +292,11 @@ - ]]> +]]>

        The server MUST activate and apply the requested list before sending the result back to the client.

        - ]]> +]]>

        If the user attempts to set an active list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user:

        @@ -308,7 +308,7 @@ xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> - ]]> +]]>

        In order to decline the use of any active list, the connected resource MUST send an empty <active/> element with no 'name' attribute.

        @@ -316,10 +316,10 @@ - ]]> +]]> - ]]> +]]>

        In order to change its default list (which applies to the user as a whole, not only the sending resource), the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains an empty <default/> child element possessing a 'name' attribute whose value is set to the desired list name.

        @@ -329,10 +329,10 @@ - ]]> +]]> - ]]> +]]>

        If the user attempts to change which list is the default list but the default list is in use by at least one connected resource other than the sending resource, the server MUST return a <conflict/> stanza error to the sending resource:

        @@ -344,7 +344,7 @@ xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> - ]]> +]]>

        If the user attempts to set a default list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user:

        @@ -356,7 +356,7 @@ xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> - ]]> +]]>

        In order to decline the use of a default list (i.e., to use the domain's stanza routing rules at all times), the user MUST send an empty <default/> element with no 'name' attribute.

        @@ -364,10 +364,10 @@ - ]]> +]]> - ]]> +]]>

        If one connected resource attempts to decline the use of a default list for the user as a whole but the default list currently applies to at least one other connected resource, the server MUST return a <conflict/> error to the sending resource:

        @@ -379,7 +379,7 @@ xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> - ]]> +]]>

        In order to edit a privacy list, the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains one <list/> child element possessing a 'name' attribute whose value is set to the list name the user would like to edit. The <list/> element MUST contain one or more <item/> elements, which specify the user's desired changes to the list by including all elements in the list (not the "delta").

        @@ -399,10 +399,10 @@ - ]]> +]]> - ]]> +]]>

        Note: The value of the 'order' attribute for any given item is not fixed. Thus in the foregoing example if the user would like to add 4 items between the "tybalt@example.com" item and the "paris@example.org" item, the user's client MUST renumber the relevant items before submitting the list to the server.

        The server MUST now send a "privacy list push" to all connected resources:

        - ]]> +]]>

        In accordance with the semantics of IQ stanzas defined in &xmppcore;, each connected resource MUST return an IQ result to the server as well:

        - ]]> +]]>

        The same protocol used to edit an existing list is used to create a new list. If the list name matches that of an existing list, the request to add a new list will overwrite the old one. As with list edits, the server MUST also send a "privacy list push" to all connected resources.

        @@ -440,10 +440,10 @@ - ]]> +]]> - ]]> +]]>

        If a user attempts to remove a list that is currently being applied to at least one resource other than the sending resource, the server MUST return a <conflict/> stanza error to the user; i.e., the user MUST first set another list to active or default before attempting to remove it. If the user attempts to remove a list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user. If the user attempts to remove more than one list in the same request, the server MUST return a <bad request/> stanza error to the user.

         @@ -461,7 +461,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive messages from the entity with the specified JID.

        @@ -476,7 +476,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive messages from any entities in the specified roster group.

        @@ -491,7 +491,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive messages from any entities with the specified subscription type.

        @@ -503,7 +503,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive messages from any other users.

         @@ -522,7 +522,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive presence notifications from the entity with the specified JID.

        @@ -537,7 +537,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive presence notifications from any entities in the specified roster group.

        @@ -552,7 +552,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive presence notifications from any entities with the specified subscription type.

        @@ -564,7 +564,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive presence notifications from any other users.

        Note: If a client blocks incoming presence notifications from an entity that has been available before, the user's server SHOULD send unavailable presence to the user on behalf of that contact.

         @@ -584,7 +584,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not send presence notifications to the entity with the specified JID.

        @@ -599,7 +599,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities in the specified roster group.

        @@ -614,7 +614,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities with the specified subscription type.

        @@ -626,7 +626,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.

        Note: When a user blocks outbound presence to a contact, the user's server MUST send unavailable presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in RFC 6121).

        @@ -645,7 +645,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from the entity with the specified JID.

        @@ -660,7 +660,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities in the specified roster group.

        @@ -675,7 +675,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities with the specified subscription type.

        @@ -687,7 +687,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any other users.

        @@ -703,7 +703,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, the entity with the specified JID.

        @@ -716,7 +716,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities in the specified roster group.

        @@ -729,7 +729,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities with the specified subscription type.

        @@ -739,7 +739,7 @@ - ]]> +]]>

        As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any other users.

         @@ -757,7 +757,7 @@ id='probing1'> - ]]> +]]> - ]]> +]]>

        If the user attempts to send an outbound stanza to a contact and that stanza type is blocked, the user's server MUST NOT route the stanza to the contact but instead MUST return a ¬acceptable; error:

        @@ -778,7 +778,7 @@ - ]]> +]]>

        When building a representation of a higher-level privacy heuristic, a client SHOULD use the simplest possible representation.

        @@ -801,7 +801,7 @@ - ]]> +]]>         @@ -814,7 +814,7 @@ type='get'> - ]]> +]]> - ]]> +]]> @@ -962,7 +962,7 @@ - ]]> +]]> diff --git a/xep-0020.xml b/xep-0020.xml index d2c1fe08..7e0d9eec 100644 --- a/xep-0020.xml +++ b/xep-0020.xml @@ -120,7 +120,7 @@ - ]]> +]]> - ]]> +]]>

        Note: If the responding entity does not want to reveal presence to the initiating entity for whatever reason then the responding entity's client SHOULD return a &unavailable; error (or return no response or error whatsoever if the offer was wrapped in a &MESSAGE; stanza) - see Security Considerations.

        If the responding entity does not support Feature Negotiation or does not support the specified FORM_TYPE, it SHOULD also return a &unavailable; error:

        - ]]> +]]>

        If the responding entity does not support one or more of the features, it SHOULD return a &feature; error, and SHOULD specify the feature(s) not implemented in the XMPP <text/> element.

        times-to-meet - ]]> +]]>

        If the responding entity supports none of the options offered for one or more of the features, it SHOULD return a ¬acceptable; error, and SHOULD specify the relevant feature(s) in the XMPP <text/> element.

        places-to-meet - ]]> +]]>

        If at least one feature offered by an entity is subject to Feature Negotiation, the entity's response to a service discovery information request MUST include <feature var='http://jabber.org/protocol/feature-neg'/> as one of the features.

        @@ -314,7 +314,7 @@ - ]]> +]]>

        Peter Millard, the primary author of this specification from version 0.1 through version 1.4, died on April 26, 2006. The remaining authors are thankful for Peter's work on this specification.

        diff --git a/xep-0022.xml b/xep-0022.xml index 0dbd76b8..dc2e3b37 100644 --- a/xep-0022.xml +++ b/xep-0022.xml @@ -121,7 +121,7 @@ - ]]> +]]>

        Here we see the sender wants to be notified if the message is stored offline (by the server), notified when the message is delivered (to the client), and notified if the recipient begins replying to the message. In this case, the sender will potentially receive three events based on this request. The first if the recipient is offline and the message is stored on the server, the second when the recipient becomes available and the message is delivered, and the third if the recipient begins composing a reply to the message.

        Note that the &MESSAGE; element requesting event notification contains an 'id' attribute. While these attributes are optional in the Jabber protocol, messages that contain event notification requests MUST contain an 'id' attribute so that raised events may be matched up with their original requests.

        @@ -137,7 +137,7 @@ message22 - ]]> +]]>

        When raising an event, the raiser must send a &MESSAGE; element constructed according to the following rules:

        • The element must contain only a jabber:x:event extension. Standard message elements such as <subject/>, <body/>, MUST NOT be included.
          • @@ -160,7 +160,7 @@ message22 - ]]> +]]> message22 - ]]> +]]>

          The lack of an <composing/> tag (and any other event tag) signifies that the composing event, indicated previously by the id value, has been cancelled. In this example, the composing event being cancelled is that event that was previously raised with the id of message22. After cancelling a composing event, a new one may be raised, following the same rules as before, when the typing of the reply is resumed.

          @@ -186,7 +186,7 @@ SEND: - ]]> +]]>

          Romeo temporarily loses his wireless connection in the Capulet's orchard and therefore his message is stored offline by the montague.net server, which generates the offline event and sends that notification to Juliet.

          message22 - ]]> +]]>

          Romeo reconnects and the message is delivered to his Jabber client, which generates a delivered event and sends it to Juliet's client.

          message22 - ]]> +]]>

          Romeo's Jabber client displays the message and sends a displayed event to Juliet's client.

          message22 - ]]> +]]>

          Romeo begins composing a reply to Juliet's heartfelt question, and his Jabber client notifies Juliet that he is composing a reply.

          message22 - ]]> +]]>

          Romeo realizes his reply is too rash and pauses to choose the right words; his Jabber client senses the delay and cancels the previous composing event.

          message22 - ]]> +]]>

          Romeo starts composing again, and his Jabber client sends a notification to Juliet's client.

          message22 - ]]> +]]>

          Romeo finally sends his reply, and requests composing events related to it.

          @@ -260,7 +260,7 @@ SEND: - ]]> +]]> @@ -319,7 +319,7 @@ SEND: - ]]> +]]> diff --git a/xep-0023.xml b/xep-0023.xml index 301fc177..79f71d66 100644 --- a/xep-0023.xml +++ b/xep-0023.xml @@ -168,7 +168,7 @@ SEND: <message to='sabine@gnu.mine.nu' id='msg811'> - ]]> +]]> diff --git a/xep-0027.xml b/xep-0027.xml index b9336c03..109419e5 100644 --- a/xep-0027.xml +++ b/xep-0027.xml @@ -163,7 +163,7 @@ - ]]> +]]> - ]]> +]]> diff --git a/xep-0030.xml b/xep-0030.xml index c5ee53fb..ad6bab56 100644 --- a/xep-0030.xml +++ b/xep-0030.xml @@ -276,7 +276,7 @@ id='info1'> - ]]> +]]>

          The target entity then MUST either return an IQ result, or return an error (see the Error Conditions section of this document). The result MUST contain a <query/> element qualified by the 'http://jabber.org/protocol/disco#info' namespace, which in turn contains one or more <identity/> elements and one or more <feature/> elements. (Note: Every entity MUST have at least one identity, and every entity MUST support at least the 'http://jabber.org/protocol/disco#info' feature; however, an entity is not required to return a result and MAY return an error, most likely &feature; or &unavailable;, although other error conditions may be appropriate.)

          Each <identity/> element MUST possess the 'category' and 'type' attributes specifying the category and type for the entity, and MAY possess a 'name' attribute specifying a natural-language name for the entity; the <identity/> element MAY also possess a standard 'xml:lang' attribute, which enables the entity to return localized results if desired (i.e., the <query/> element MAY include multiple <identity/> elements with the same category+type but with different 'xml:lang' values, however the <query/> element MUST NOT include multiple <identity/> elements with the same category+type+xml:lang but with different 'name' values).

          Each <feature/> element MUST possess a 'var' attribute whose value is a protocol namespace or other feature offered by the entity, and MUST NOT have any children.

          @@ -304,7 +304,7 @@           - ]]> +]]>

          If the JID of the specified target entity does not exist, the server or other authoritative entity SHOULD return an ¬found; error, unless doing so would violate the privacy and security considerations specified in XMPP Core and &xmppim; or local privacy and security policies (see also the Security Considerations of this document):

          - ]]> +]]>

          If privacy and security considerations or policies prevent the server or other authoritative entity from returning an ¬found; error, it SHOULD return a &unavailable; error instead:

          - ]]> +]]>

          When an entity sends a disco#info request to a bare JID (<account@domain.tld>) hosted by a server, the server itself MUST reply on behalf of the hosted account, either with an IQ-error or an IQ-result. For important rules regarding access to this functionality, see the Security Considerations section of this document. In particular, in response to a disco#info request sent to a bare JID with no node, if access is not denied the server SHOULD return an IQ-result for the bare JID, in which the primary identity SHOULD have a category of "account" with an appropriate type as specified in the Service Discovery Identities registry (most likely, a type of "registered"). Note: This enables authorized or trusted entities to discover whether the account exists and its account type (e.g., in IM systems to determine the existence of an account before adding it to a contact's roster).

          - ]]> +]]>

          Here we assume that shakespeare.lit is trusted by capulet.com and that the account <juliet@capulet.com> is a registered account:

          - ]]> +]]>

          A query sent to an associated entity may result in different or more detailed information. One example is sending a query to a particular conference room rather than the parent conference service:

          - ]]> +]]>

          A disco#info query MAY also be directed to a specific node identifier associated with a JID, although the primary use of nodes is as Items Nodes rather than as info nodes:

          @@ -413,7 +413,7 @@ - ]]> +]]>

          If the request included a 'node' attribute, the response MUST mirror the specified 'node' attribute to ensure coherence between the request and the response.

           - ]]> +]]>           @@ -442,7 +442,7 @@ id='items1'> - ]]> +]]>

          The target entity then MUST either return its list of publicly-available items, or return an error. The list of items MUST be provided in an IQ stanza of type "result", with each item specified by means of an <item/> child of a <query/> element qualified by the 'http://jabber.org/protocol/disco#items' namespace (the <item/> child MUST possess a 'jid' attribute specifying the JID of the item and MAY possess a 'name' attribute specifying a natural-language name for the item):

           - ]]> +]]>

          The <item/> element MUST NOT contain XML character data and SHOULD be empty; while it MAY contain XML data in another namespace, such data MUST be ignored if an implementation does not understand it.

          If there are no items associated with an entity (or if those items are not publicly available), the target entity MUST return an empty query element to the requesting entity:

          - ]]> +]]>

          As with disco#info requests, when an entity sends a disco#items request to a bare JID (<account@domain.tld>) hosted by a server, the server itself MUST reply on behalf of the hosted account. For important rules regarding access to this functionality, see the Security Considerations section of this document. In particular, in response to a disco#items request sent to a bare JID with no node, if access is not denied the server SHOULD return the associated items including connected or available resources as appropriate:

          - ]]> +]]>

          Here we assume that shakespeare.lit is trusted by capulet.com and that the account <juliet@capulet.com> has two available resources:

          - ]]> +]]>

          It is possible that an item associated with an entity will not be addressable as a JID; examples might include offline messages stored in an inbox (see &xep0013;), entries in a Jabber-enabled weblog, XML-RPC services associated with a client or component, items available in an online trading system (e.g., a catalog or auction), news postings located at an NNTP gateway, and topics hosted by a &xep0060; component. In order to handle such items, the <item/> element MAY possess an OPTIONAL 'node' attribute that supplements the REQUIRED 'jid' attribute.

          @@ -512,7 +512,7 @@ id='items2'> - ]]> +]]>

          If there are items associated with the target entity but they are not addressable as JIDs, the service SHOULD then return a list of nodes (where each <item/> element MUST possess a 'jid' attribute, SHOULD possess a 'node' attribute, and MAY possess a 'name' attribute):

           - ]]> +]]>

          There may be futher nodes associated with the "first-level" nodes returned in the above query (e.g., the nodes may be categories that have associated items). The requesting entity can query a node further by sending a request to the JID and specifying the node of interest in the query.

          - ]]> +]]>

          The service then returns the further nodes associated with the "parent" node. In the following example, the service itself enforces an alphabetically-ordered hierarchical structure on the nodes that are returned, but such a structure is a matter of implementation rather than protocol.

          - ]]> +]]>

          The requesting entity can then query further if desired:

          - ]]> +]]> - ]]> +]]>

          The foregoing examples show a hierarchy of nodes, in which some nodes are branches (i.e., contain further nodes) and some nodes are leaves (i.e., do not contain further nodes). The "hierarchy" category SHOULD be used to identify such nodes, where the "branch" and "leaf" types are exhaustive of the types within this category.

          @@ -616,7 +616,7 @@ - ]]> +]]>

          The queried entity now returns a list of publish-subscribe nodes over which it has control, each of which is hosted on a different pubsub service:

           - ]]> +]]>           @@ -667,7 +667,7 @@ - ]]> +]]>

          Other error conditions may be appropriate depending on the application.

          The following table summarizes the common error conditions that can have special meaning in the context of Service Discovery (for information regarding error condition syntax and semantics, see &xep0086;).

Code
@@ -731,7 +731,7 @@ the document (e.g., XEP) in which this type is specified - ]]> +]]>

The registrant may register more than one category at a time, each contained in a separate <category/> element. The registrant may also register more than one type at a time, each contained in a separate <type/> child element. Registrations of new types within an existing category must include the full XML snippet but should not include the category description (only the name).

@@ -760,7 +760,7 @@ XEP-0030 - ]]> +]]> @@ -773,7 +773,7 @@ a natural-language description of the feature the document (e.g., XEP) in which this feature is specified - ]]> +]]>

The registrant may register more than one feature at a time, each contained in a separate <feature/> element.

 @@ -787,7 +787,7 @@ a natural-language description of the nodethe document (e.g., XEP) in which this node is specified - ]]> +]]>

The registrant may register more than one node at a time, each contained in a separate <node/> element.

@@ -797,20 +797,20 @@

The "disco" querytype is defined herein for service discovery interactions, with three keys: (1) "node" (the optional node to query), (2) "request" (with values of "info" to retrieve service discovery information and "items" to retrieve service discovery items), and (3) "type" (with values of "get" for IQ-gets and "set" for IQ-sets).

+]]> - ]]> +]]> +]]> - ]]> +]]>

The following submission registers the "disco" querytype.

@@ -850,7 +850,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items - ]]> +]]> @@ -916,7 +916,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items - ]]> +]]> - ]]> +]]> diff --git a/xep-0033.xml b/xep-0033.xml index ee0c7cab..6d6c5028 100644 --- a/xep-0033.xml +++ b/xep-0033.xml @@ -703,7 +703,7 @@ - ]]> +]]> diff --git a/xep-0038.xml b/xep-0038.xml index ad159104..39decf9c 100644 --- a/xep-0038.xml +++ b/xep-0038.xml @@ -288,7 +288,7 @@ - ]]> +]]> @@ -342,7 +342,7 @@ alert.wav - ]]> +]]> diff --git a/xep-0041.xml b/xep-0041.xml index d62c92bf..c2a52e65 100644 --- a/xep-0041.xml +++ b/xep-0041.xml @@ -264,7 +264,7 @@ - ]]> +]]> diff --git a/xep-0042.xml b/xep-0042.xml index b774ef91..3a3e79ba 100644 --- a/xep-0042.xml +++ b/xep-0042.xml @@ -118,7 +118,7 @@ - ]]> +]]> ... @@ -131,7 +131,7 @@ ... - ]]> +]]> @@ -147,7 +147,7 @@ - ]]> +]]> @@ -161,7 +161,7 @@ expires='30' receivers='1'/> - ]]> +]]>

This creates a session between sender@domain/resource and any one receiver. At this point, the JOBS service is ready to accept connections for this session. The <session/> element describes the details for the session. The value returned in the "id" attribute is the JOBS session ID The exact value of the ID is left to JOBS implementations..

@@ -174,7 +174,7 @@ - ]]> +]]> - ]]> +]]>

The returned <session/> is also prefilled with default values for all known parameters.

@@ -209,7 +209,7 @@ - ]]> +]]> - ]]> +]]>

The above example creates a session that does not timeout. A JOBS service uses values from the default information set for any parameters that are missing.

@@ -239,7 +239,7 @@ - ]]> +]]> - ]]> +]]>

The exact fields present in the form are dependent upon the JOBS implementation. The form SHOULD allow a user to at least specify the <session/> attributes.

Using the form-based approach, the session is then created by sending a <session action='create'/> with a form submission (as defined for "jabber:x:data"):

@@ -275,7 +275,7 @@ - ]]> +]]> - ]]> +]]> @@ -308,7 +308,7 @@ expires='30' receivers='1'/> - ]]> +]]>

When inviting directly, the <session/> MUST contain enough information for a receiver to connect OOB. The required information is:

diff --git a/xep-0047.xml b/xep-0047.xml index b871856e..f094da03 100644 --- a/xep-0047.xml +++ b/xep-0047.xml @@ -133,14 +133,14 @@ sid='i781hf64' stanza='iq'/> - ]]> +]]>

If the responder wishes to proceed with the IBB session, it returns an IQ-result to the initiator.

- ]]> +]]>

If the responder does not support IBB, it returns a &unavailable; or &feature; error.

- ]]> +]]>

If the responder supports IBB but would prefer a smaller block-size, it returns a &constraint; error.

- ]]> +]]>

If the responder supports IBB but does not wish to proceed with the session, it returns a ¬acceptable; error.

- ]]> +]]> @@ -192,7 +192,7 @@ kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA - ]]> +]]>

Each chunk of data is included as the XML character data of the <data/> element after being encoded as Base64 as specified in Section 4 of &rfc4648;. Each block MUST be a valid base64 block with padding at the end if needed.

The <data/> element MUST possess a 'seq' attribute; this is a 16-bit unsigned integer that acts as a counter for data chunks sent in a particular direction within this session. The 'seq' value starts at 0 (zero) for each sender and MUST be incremented for each packet sent by that entity. Thus, the second chunk sent has a 'seq' value of 1, the third chunk has a 'seq' value of 2, and so on. The counter loops at maximum, so that after value 65535 (215 - 1) the 'seq' MUST start again at 0.

The <data/> element MUST also possess a 'sid' attribute that ties the data chunk to this particular IBB session.

@@ -202,7 +202,7 @@ id='kr91n475' to='romeo@montague.net/orchard' type='result'/> - ]]> +]]>

The sender of a data chunk need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize the potential for rate-limiting penalties or throttling.

It is possible that delivery of the stanza might fail, in which case the sender's or recipient's server shall return an appropriate error:

    @@ -229,14 +229,14 @@ type='set'> - ]]> +]]>

    The receiving party then acknowledges that the bytestream has been closed by returning an IQ-result (however, the receiving party might wait until it has had a chance to send any remaining data in the other direction, if the bytestream is bidirectional; in this case, the party that sent the original <close/> element SHOULD wait to receive the IQ response from the receiving party before considering the bytestream to be closed).

    - ]]> +]]>

    It is possible that the recipient of the close notification does not know about the bytestream, in which case it would return an ¬found; error.

    - ]]> +]]>

    In either case, both parties MUST consider the bytestream to be closed.

    @@ -271,7 +271,7 @@ kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA - ]]> +]]> @@ -362,7 +362,7 @@ - ]]> +]]> diff --git a/xep-0048.xml b/xep-0048.xml index fd2ca446..ecdb5914 100644 --- a/xep-0048.xml +++ b/xep-0048.xml @@ -120,7 +120,7 @@ Puck - ]]> +]]>

    This bookmark would be displayed as 'Council of Oberon' and, if activated, would attempt to join the conference room 'council@conference.underhill.org' with nickname 'Puck'.

    Note: A bookmark set may contain any number of conference rooms.

    @@ -152,7 +152,7 @@ - ]]> +]]>

    This bookmark would be displayed in the client as 'Complete Works of Shakespeare' and would take the user to <http://the-tech.mit.edu/Shakespeare/> when selected.

    Note: A bookmark set can contain any number of URLs.

    @@ -191,10 +191,10 @@ - ]]> +]]> - ]]> +]]>

    The stored data is automatically pushed to all of the user's connected resources.

    @@ -236,7 +236,7 @@ - ]]> +]]>

    In order to retrieve stored data without receiving notifications (e.g., upon initial login), the user's client sends a retrieve-items request as specified in XEP-0060.

    @@ -246,7 +246,7 @@ - ]]> +]]> - ]]> +]]>     @@ -338,7 +338,7 @@ - ]]> +]]> diff --git a/xep-0049.xml b/xep-0049.xml index f91986df..7bbe1420 100644 --- a/xep-0049.xml +++ b/xep-0049.xml @@ -112,7 +112,7 @@ SERVER: from="hamlet@shakespeare.lit/denmark" to="hamlet@shakespeare.lit/denmark" id="1001"/> - ]]> +]]> - ]]> +]]>

    If a user attempts to get or set jabber:iq:private data that belongs to another user, the server MUST return a "Forbidden" or "Service Unavailable" error to the sender (the latter condition is in common use by existing implementations, although the former is preferable).

    - ]]> +]]>

    If a user attempts to perform an IQ get without providing a child element, the server SHOULD return a "Bad Format" error (however, some existing implementations return a "Not Acceptable" error in such circumstances):

    - ]]> +]]>

    Certain namespaces are reserved in Jabber (namespaces beginning with 'jabber:' or 'http://jabber.org/', as well as 'vcard-temp'). If a user attempts to get or set jabber:iq:private data in a reserved namespace, historically some server implementations have chosen to return an error (commonly "Not Acceptable") to the sender. Such behavior is OPTIONAL, but may be encountered by clients when interacting with some existing server implementations.

    - ]]> +]]>     @@ -247,6 +247,6 @@ SERVER (optional error): - ]]> +]]> diff --git a/xep-0050.xml b/xep-0050.xml index c8be61ec..c724d98c 100644 --- a/xep-0050.xml +++ b/xep-0050.xml @@ -169,7 +169,7 @@ from='requester@domain'> - ]]> +]]> - ]]> +]]>

    To find what commands an entity provides, the requester uses Service Discovery. Each command is a node of the responder, under the fixed node "http://jabber.org/protocol/commands" (for which the service discovery identity category is "automation" and type is "command-list"). Use of a fixed node for all commands of an entity allows for immediate retrieval of commands.

    @@ -193,7 +193,7 @@ - ]]> +]]> - ]]> +]]>

    The result can then be used by the client to populate a menu, a dialog of buttons, or whatever is appropriate to the current user interface. The responder is not required to send the same list of commands to all requesters.

    If additional information about a command is desired, the requester queries for disco information on the command node:

    - ]]> +]]>     - ]]> +]]>

    A responder MUST at least provide <identity category='automation' type='command-node'/> and <feature var='http://jabber.org/protocol/commands'/>, and SHOULD include <feature var='jabber:x:data'/>. It is not required to support additional information about a command. If the command is not available to the requester, the responder SHOULD respond with a 403 "Forbidden" error.

    @@ -274,7 +274,7 @@ name='Restart Service'/> - ]]> +]]>

    The only portion required is <query xmlns='http://jabber.org/protocol/disco#items'/>. Any other information (such as the <subject/> in the foregoing example) is OPTIONAL.

     @@ -286,7 +286,7 @@ node='list' action='execute'/> - ]]> +]]>

    The requester MAY include the "action='execute'", although this is implied.

    If the command does not require any user interaction (returns results only), the responder sends a packet similar to the following:

    - ]]> +]]>

    The above example shows the command execution resulting in a "jabber:x:data" form. It is also possible that one or more URLs (specified via &xep0066;) could be returned.

    @@ -339,7 +339,7 @@ node='config' action='execute'/> - ]]> +]]> - ]]> +]]>

    The <command/> SHOULD include an <actions/> element, which specifies the details of what the allowed actions are for this stage of execution. Each element within <action/> matches a possible value for the <command/> element's "action" attribute. The "execute" attribute defines which of the included actions is considered the equivalent to "execute" for this stage. In the above example, the only allowed action is to progress to the next stage, which is also the default.

    The requester then submits the form, maintaining the command node and sessionid:

    - ]]> +]]>

    The responder then provides the next stage's form in the result Note that the second stage can be reverted to the first stage or completed (signaled by the inclusion of the <prev/> and <complete/> elements), and that the default action is to complete execution (signaled by the "execute" attribute's value of "complete").:

    @@ -410,7 +410,7 @@ - ]]> +]]>

    The requester then submits the second stage's form, again maintaining the node and sessionid:

    @@ -427,7 +427,7 @@ - ]]> +]]> Service 'httpd' has been configured. - ]]> +]]>

    If the requester wishes to revert to the previous stage, it sends an &IQ; with the command's node and sessionid, and "action='prev'":

    @@ -446,7 +446,7 @@ node='config' action='prev'/> - ]]> +]]>

    If the responder accepts this, it responds with the previous stage's command The responder MAY present "remembered" field values, but doing so is OPTIONAL.:

    @@ -471,7 +471,7 @@ - ]]> +]]>

    In the case where a command has multiple stages, the requester may wish to cancel at some point. To cancel, the requester sends the continuing command request with an "action='cancel'":

    @@ -482,7 +482,7 @@ node='config' action='cancel'/> - ]]> +]]>

    This enables the responder to free any resources allocated during the process. The responder MUST reply with the success of the command:

    @@ -491,7 +491,7 @@ node='config' status='canceled'/> - ]]> +]]>     @@ -552,7 +552,7 @@ node='list' action='execute'/> - ]]> +]]> - ]]> +]]>

    Within the "http://jabber.org/protocol/commands" schema, the language/locale applies only to the human-readable character data for <info/> elements. It SHOULD also apply to all payload elements, appropriate to their respective specifications.

    Responders MUST take this into consideration, and properly account for the language/locale settings within payloads. If the responder cannot accomodate the requested language/locale, it SHOULD respond with a <bad-request/> (<bad-locale/>) error condition.

    - ]]> +]]> - ]]> +]]> @@ -831,7 +831,7 @@ XEP-0050 - ]]> +]]>

    The XMPP Registrar includes "http://jabber.org/protocol/commands" in its registry of well-known Service Discovery nodes.

    @@ -841,12 +841,12 @@

    The "command" querytype is defined herein for interaction with entities that support the ad-hoc command protocol, with keys of "action" and "node".

    +]]> - ]]> +]]>

    The following submission registers the "command" querytype.

    @@ -887,7 +887,7 @@ xmpp:montague.net?command;node=stats - ]]> +]]>     @@ -994,7 +994,7 @@ xmpp:montague.net?command;node=stats - ]]> +]]> diff --git a/xep-0051.xml b/xep-0051.xml index 6681acdc..f6c2ec46 100644 --- a/xep-0051.xml +++ b/xep-0051.xml @@ -80,7 +80,7 @@ 123.123.123.122 - ]]> +]]> @@ -88,7 +88,7 @@ server2.jabber.org - ]]> +]]> @@ -96,7 +96,7 @@ server3.jabber.org:6222 - ]]> +]]> @@ -104,7 +104,7 @@ jabber.org - ]]> +]]>

    To follow.

    diff --git a/xep-0052.xml b/xep-0052.xml index 2235731f..34b1fab8 100644 --- a/xep-0052.xml +++ b/xep-0052.xml @@ -289,7 +289,7 @@ - ]]> +]]>

    The <file/> element is the "workhorse" element. This element is used to convey meta-data and report file transfer actions. This elemnt contains attributes for file meta-data and actions, and MAY contain a <desc/>, a <range/>, and zero or more <feature xmlns='jabber:iq:negotiate'/> (&xep0020;) elements.

    diff --git a/xep-0054.xml b/xep-0054.xml index e5283d24..b8e79add 100644 --- a/xep-0054.xml +++ b/xep-0054.xml @@ -69,7 +69,7 @@ type='get'> - ]]> +]]>

    If a vCard exists for the user, the server MUST return in an IQ-result:

     - ]]> +]]>

    If no vCard exists, the server MUST return a stanza error (which SHOULD be ¬found;) or an IQ-result containing an empty <vCard/> element.

    - ]]> +]]> - ]]> +]]>

    A user may publish or update his or her vCard by sending an IQ of type "set" with no 'to' address, following the format in the previous use case.

    @@ -194,13 +194,13 @@ - ]]> +]]>

    The server then returns an IQ-result (or an IQ-error).

    - ]]> +]]>

    Notice that the previous IQ-set included only one changed element (the <DESC/> element). Currently there is no method for partial updates of a vCard, and the entire vCard must be sent to the server in order to update any part of the vCard.

    If a user attempts to perform an IQ set on another user's vCard (i.e., by setting a 'to' address to a JID other than the sending user's bare JID), the server MUST return a stanza error, which SHOULD be &forbidden; or ¬allowed;.

    - ]]> +]]>

    A user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID.

    @@ -222,7 +222,7 @@ type='get'> - ]]> +]]>

    In accordance with &xmppcore;, a compliant server MUST respond on behalf of the requestor and not forward the IQ to the requestee's connected resource.

    jer@jabber.org     - ]]> +]]>

    If no vCard exists or the user does not exist, the server MUST return a stanza error, which SHOULD be either &unavailable; or ¬found; (but the server MUST return the same error condition in both cases to help prevent directory harvesting attacks).

    - ]]> +]]>

    Note: The use of vCards is not limited to accounts associated with human users. For example, an XMPP server could itself have a vCard that defines the server's hosting organization, physical location, and relevant contact addresses.

         @@ -265,7 +265,7 @@ id='disco1'> - ]]> +]]> - ]]> +]]>

    This information can also be encapsulated via &xep0115; for entities who share presence.

    @@ -296,12 +296,12 @@

    The "vcard" querytype is registered as a vCard-related action.

    +]]> - ]]> +]]>

    The following submission registers the "vcard" querytype.

    @@ -310,7 +310,7 @@ xmpp:romeo@montague.net?vcard enables retrieval of an entity's vCard data XEP-0054 - ]]> +]]> @@ -643,6 +643,6 @@ PARTICULAR PURPOSE. - ]]> +]]> diff --git a/xep-0055.xml b/xep-0055.xml index 6ff2b7dd..e4f55ed5 100644 --- a/xep-0055.xml +++ b/xep-0055.xml @@ -70,7 +70,7 @@ xml:lang='en'> - ]]> +]]>

    The service MUST then return the possible search fields to the user, and MAY include instructions:

     - ]]> +]]>

    The user MAY then submit a search request, specifying values for any desired fields:

    Capulet     - ]]> +]]>

    The service SHOULD then return a list of search results that match the values provided:

    - ]]> +]]>

    If there are no matching directory entries, the service MUST return an empty <query/> element:

    - ]]> +]]> @@ -148,7 +148,7 @@ xml:lang='en'> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]>

    The intent of the <first/> and <last/> elements (and associated data form fields) is that they map to given name and family name, respectively. Therefore, cultures that place the family name first and the given name second (e.g., as is done in China) would use <first/> for the given name and <last/> for the family name, NOT the other way around.

    @@ -253,7 +253,7 @@ Kong - ]]> +]]>

    There are no security features or concerns related to this proposal.

    @@ -290,7 +290,7 @@ type='text-single' label='Email Address'/> - ]]> +]]>     @@ -342,6 +342,6 @@ - ]]> +]]> diff --git a/xep-0059.xml b/xep-0059.xml index af95a72f..0c5d7491 100644 --- a/xep-0059.xml +++ b/xep-0059.xml @@ -145,7 +145,7 @@ - ]]> +]]>

    The responding entity then returns the first items of the result set in order. The number of items is limited to the requested size:

    @@ -165,7 +165,7 @@ - ]]> +]]>

    An entity often needs to retrieve a page of items adjacent to a page it has already received. For examples, when retrieving a complete result set in order page by page, or when a user 'scrolls' forwards one page.

    @@ -188,7 +188,7 @@ - ]]> +]]>

    Responding entity support for paging through a result set is optional. If it does support paging (not just Limiting the Number of Items), then in each page it returns, the responding entity MUST include <first/> and <last/> elements that specify the unique ID (UID) for the first and last items in the page. If there is only one item in the page, then the first and last UIDs MUST be the same. If there are no items in the page, then the <first/> and <last/> elements MUST NOT be included.

    The responding entity may generate these UIDs in any way, as long as the UIDs are unique in the context of all possible members of the full result set. Each UID MAY be based on part of the content of its associated item, as shown below, or on an internal table index. Another possible method is to serialize the XML of the item and then hash it to generate the UID. Note: The requesting entity MUST treat all UIDs as opaque.

    The responding entity SHOULD also include the number of items in the full result set (which MAY be approximate) encapsulated in a <count/> element. The <first/> element SHOULD include an 'index' attribute. This integer specifies the position within the full set (which MAY be approximate) of the first item in the page. If that item is the first in the full set, then the index SHOULD be '0'. If the last item in the page is the last item in the full set, then the value of the <first/> element's 'index' attribute SHOULD be the specified count minus the number of items in the last page.

    @@ -216,7 +216,7 @@ - ]]> +]]>

    The requesting entity can then ask for the next page in the result set by including in its request the UID of the last item from the previous page (encapsulated in an <after/> element), along with the maximum number of items to return. Note: If no <after/> element is specified, then the UID defaults to "before the first item in the result set" (i.e., effectively an index of negative one).

    @@ -228,7 +228,7 @@ - ]]> +]]>

    The first item in the page returned by the responding entity MUST be the item that immediately follows the item that the requesting entity indicated in the <after/> element:

    @@ -253,7 +253,7 @@ - ]]> +]]>

    It may sometimes be necessary to return an empty page to the requesting entity. For example, with dynamic result sets the responding entity MAY delete some items from the full result set between requests. Another example occurs when the requesting entity specifies "0" for the maximum number items to return (see Getting the Item Count).

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

    If there are no items whatsoever in the full result set, the responding entity MUST return a response that adheres to the definition of the wrapper protocol (e.g., "jabber:iq:search", "http://jabber.org/protocol/disco#items", or "http://jabber.org/protocol/pubsub"). For both XEP-0055 and XEP-0030, that means the responding entity shall return an empty &QUERY; element; for XEP-0060, that means the responding entity shall return an empty <pubsub/> element; for XEP-0136, that means the responding entity shall return an empty <list/> or <store/> element.

     @@ -278,7 +278,7 @@ - ]]> +]]>

    The last item in the page returned by the responding entity MUST be the item that immediately preceeds the item that the requesting entity indicated it has already received:

    @@ -303,7 +303,7 @@ - ]]> +]]>

    The responding entity MUST reply with an 'item-not-found' error if all the following circumstances apply:

    @@ -325,7 +325,7 @@ - ]]> +]]>

    The requesting entity MAY ask for the last page in a result set by including in its request an empty <before/> element, and the maximum number of items to return.

    @@ -339,7 +339,7 @@ - ]]> +]]>

    The requesting entity MAY choose not to retrieve pages from the result set in order. (For example, when its user drags a user-interface slider to a radically new position within a very large result set.)

    @@ -355,7 +355,7 @@ - ]]> +]]>

    The responding entity SHOULD derive the first UID from the specified index (the method used MAY be approximate) before returning the requested result set page in the normal way. If the specified index was "0" then the responding entity SHOULD derive the UID that is the first in the full result set.

    Note: The 'index' attribute of the <first/> element MUST be the same as the index specified in the request. If the index specified by the requesting entity is greater than or equal to the number of items in the full set then the responding entity MUST return an empty page (see Paging Forwards Through a Result Set).

    - ]]> +]]>

    If it would be either impossible or exceptionally resource intensive for the responding entity to derive the first UID from the specified index with reasonable accuracy then the responding entity MAY return a &e501; error.

    @@ -396,7 +396,7 @@ - ]]> +]]>

    In order to get the item count of a result set without retrieving the items themselves, the requesting entity simply specifies zero for the maximum size of the result set page:

    @@ -409,7 +409,7 @@ - ]]> +]]>

    The responding entity then returns the item count, which MAY be approximate rather than precise if determining the exact number of items would be resource-intensive:

    @@ -419,7 +419,7 @@ - ]]> +]]>

    Note: The <count/> element MAY be omitted, but only if it would be either impossible or exceptionally resource intensive to calculate reasonably accurate values.

    Note: If there are no items in the full result set then the responding entity MUST return a response that adheres to the definition of the wrapper protocol (see Paging Forwards Through a Result Set).

     @@ -434,7 +434,7 @@ - ]]> +]]> @@ -465,7 +465,7 @@ - ]]> +]]> @@ -475,7 +475,7 @@ - ]]> +]]>

    In order for a requesting entity to determine if a responding entity supports result set management, it SHOULD send a Service Discovery information request to the responding entity:

    @@ -486,7 +486,7 @@ id='disco1'> - ]]> +]]> - ]]> +]]>

    An entity SHOULD NOT include the result set management extensions defined in this document in its requests if it does not have positive knowledge that the responding entity supports the protocol defined herein. If the responding entity does not understand result set management, it MUST ignore such extensions.

    Note: Even if a responding entity understands the result set management protocol, its support for result set management in the context of any given "using protocol" is OPTIONAL (e.g., an implementation could support it in the context of the 'jabber:iq:search' namespace but not in the context of the 'http://jabber.org/protocol/disco#items' namespace). Currently the only way for a requesting entity to determine if a responding entity supports result set management in the context of a given "using protocol" is to include result set management extensions in its request. If the responding entity does not include result set management extensions in its response, then the requesting entity SHOULD NOT include such extensions in future requests wrapped by the "using protocol" namespace.

     @@ -553,7 +553,7 @@ - ]]> +]]>

    Thanks to Olivier Goffart, Jon Perlow, and Andrew Plotkin for their feedback.

    diff --git a/xep-0060.xml b/xep-0060.xml index f5a25a7b..8c099df9 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -5828,7 +5828,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae XEP-0060 - ]]> +]]>

    Future submissions to the XMPP Registrar may register additional types.

    @@ -6048,7 +6048,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae Notification of subscription state changes is supported. XEP-0060 - ]]> +]]> @@ -6085,7 +6085,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae type='text-single' label='The subscription identifier associated with the subscription request'/> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> @@ -6429,7 +6429,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae A subscription identifer within the pubsub protocol. XEP-0060 - ]]> +]]>

    Future submissions to the XMPP Registrar may register additional SHIM headers that can be used in relation to the pubsub protocol, and such submission may occur without updating this specification.

     @@ -6493,7 +6493,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings - ]]> +]]>     @@ -6743,7 +6743,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings - ]]> +]]> @@ -6851,7 +6851,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings - ]]> +]]> @@ -7017,7 +7017,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings - ]]> +]]> @@ -7167,7 +7167,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings - ]]> +]]> diff --git a/xep-0061.xml b/xep-0061.xml index 810bb38a..d9472ba0 100644 --- a/xep-0061.xml +++ b/xep-0061.xml @@ -64,7 +64,7 @@ default on a save action by the user).

    auto|user - ]]> +]]>

    Any element not specified in the note should use the last known setting or client defaults, so that when a change is sent, only the changed elements are returned.

    diff --git a/xep-0065.xml b/xep-0065.xml index 2d6ab771..da8162d3 100644 --- a/xep-0065.xml +++ b/xep-0065.xml @@ -211,7 +211,7 @@ type='get'> - ]]> +]]> - ]]> +]]> @@ -234,7 +234,7 @@ type='get'> - ]]> +]]>

    The server will return all of the items it knows about.

     - ]]> +]]>

    In this case, the "streamer.example.com" is a bytestreams proxy.

    For each item in the disco#items result, the Requester needs to query to determine if it is a bytestreams proxy.

    - ]]> +]]>

    The proxy returns its information and the Requester inspects it to determine if it contains an identity of category "proxy" and type "bytestreams".

    - ]]> +]]>

    Next the Requester needs to request the full network address to be used for bytestreaming through the Proxy. This is done by sending an IQ-get to the proxy containing a &QUERY; element qualified by the bytestreams namespace (not the service discovery namespace). Before version 1.8 of this specification, the &QUERY; element in this use case possessed a 'sid' attribute; however, it is unnecessary for the Requester to specify the StreamID here and it would be harmful for the Proxy to reserve the StreamID at this point because the StreamID might never be used (thus forcing the Proxy to establish and maintain state about the bytestream) and because the Requester might use the Proxy's services for multiple different streams.

    - ]]> +]]>

    The Proxy replies by returning an IQ-result that contains its network address, structured using the <streamhost/> child of the &QUERY; element; the <streamhost/> element MUST possess the following attributes:

    • host = the IP address or DNS domain name of the StreamHost for SOCKS5 communication over TCP (if the value is an IPv6 address, it MUST be formatted according to &rfc5952;, as is done in &xmppcore;)
      • @@ -300,7 +300,7 @@ port='7625'/> - ]]> +]]>

      If the Requester does not have permissions to initiate bytestreams on the Proxy for whatever reason (e.g., a proxy implementation might enable administrators to ban JIDs or domains from using the Proxy), the Proxy MUST return a &forbidden; error to the Requester.

      - ]]> +]]>

      If the Proxy is unable to act as a StreamHost, the Proxy MUST return an error to the Requester, which SHOULD be ¬allowed;.

      - ]]> +]]>

      If the Proxy is unable to act as a StreamHost, the Proxy MUST return an error to the Requester, which SHOULD be ¬allowed;.

      - ]]> +]]> @@ -375,7 +375,7 @@ Requester Target | Exchange data over S5B | | <============================> | | | - ]]> +]]> @@ -394,7 +394,7 @@ Requester Target port='5086'/> - ]]> +]]>

      If the request is malformed (e.g., the &QUERY; element does not include the 'sid' attribute), the Target MUST return an error of &badrequest;.

      Else if the Target is unwilling to accept the bytestream, it MUST return an error of ¬acceptable; to the Requester.

      - ]]> +]]>

      If the Target is willing to negotiate a bytestream, it proceeds as shown in the following sections.

       @@ -426,10 +426,10 @@ CMD = X'01' ATYP = X'03' DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID) 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.

      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.

      - ]]> +]]>

      After the Target has authenticated with the StreamHost/Requester, 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 StreamHost/Requester).

      @@ -456,7 +456,7 @@ STATUS = X'00' - ]]> +]]>

      At this point, the Requester knows which StreamHost was used by the Target and the parties are able to use the StreamHost/Requester to exchange data over the bytestream.

             @@ -520,7 +520,7 @@ Requester Proxy Target | Exchange data over S5B | | <=============================================================> | | | | - ]]> +]]> @@ -539,7 +539,7 @@ Requester Proxy Target port='7625'/> - ]]> +]]>

      If the Target is willing to negotiate a bytestream, it proceeds as shown in the following sections.

       @@ -557,10 +557,10 @@ CMD = X'01' ATYP = X'03' DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID) DST.PORT = 0 - ]]> +]]> +]]>

      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.

       @@ -575,7 +575,7 @@ STATUS = X'00' - ]]> +]]>

      At this point, the Requester knows which StreamHost was used by the Target.

       @@ -585,10 +585,10 @@ CMD = X'01' ATYP = X'03' DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID) DST.PORT = 0 - ]]> +]]> +]]>

      Next the Requester needs to activate the bytestream with the Proxy. This is done by sending an IQ-set to the Proxy, including an <activate/> element whose XML character data specifies the full or bare JID of the Target.

      @@ -602,7 +602,7 @@ STATUS = X'00' target@example.org/bar - ]]> +]]>

      Using this information, with the SID and from address on the packet, the Proxy is able to activate the stream by hashing the SID + Requester JID + Target JID and comparing the result against the DST.ADDR it has received from the Target and Receiver. Although this provides a reasonable level of trust that the activation request came from the Requester, it does not guard against active or even passive attacks against the bytestreams negotiation (see the Security Considerations for information about potential hijacking of the negotiation).

      If the Proxy can fulfill the request, it MUST respond to the Requester with an IQ-result.

      - ]]> +]]>

      At this point the parties can begin exchanging data over the bytestream.

      If the Proxy cannot fulfill the request, it MUST return an IQ-error to the Requester; the following conditions are defined:

        @@ -640,7 +640,7 @@ STATUS = X'00' port='7625'/> - ]]> +]]>

        The MUC room will then forward the IQ-set to the Target's real JID with a 'from' address of the Requester's room JID.

        - ]]> +]]>

        Now the parties can proceed as defined for the direct or mediated connection. See the Security Considerations for information about potential hijacking of the negotiation.

        @@ -671,7 +671,7 @@ STATUS = X'00' type='get'> - ]]> +]]>

        If the Target supports UDP associations, it MUST include a feature of 'http://jabber.org/protocol/bytestreams#udp' in the service discovery result.

         - ]]> +]]>

        UDP associations are requested by setting the 'mode' attribute to a value of "udp" rather than "tcp".

        @@ -705,7 +705,7 @@ STATUS = X'00' port='5086'/> - ]]> +]]>

        There is one main difference between UDP mode and TCP mode: rather than simply establishing a TCP connection, the Target and/or Requester MUST (1) establish a UDP association and then (2) initialize the UDP channel. In particular:

        @@ -721,11 +721,11 @@ CMD = X'03' ATYP = X'03' DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID) DST.PORT = 0 - ]]> +]]>

        The StreamHost then acknowledges this request:

        +]]>

        After connecting to the StreamHost, the Target (direct connection) or both Target and Requester (mediated connection) MUST initialize the UDP channel. In order to do so, each sending entity MUST send a SOCKS5 UDP packet to the StreamHost on the same port used for the initial TCP connection (in the foregeoing example, a host of 192.168.4.1 and port of 5086), with DST.PORT set to '1' and DATA containing the sending entity's JID (i.e, the JID of either the Target or Requester).

        @@ -734,7 +734,7 @@ ATYP = X'03' DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID) DST.PORT = 1 DATA = Target or Requester JID - ]]> +]]>

        Upon successful receipt by the StreamHost, the StreamHost MUST reply with a message notification indicating success:

        - ]]> +]]>

        The <udpsuccess/> element indicates that the StreamHost has received a UDP initialization packet. This element has a single attribute containing the DST.ADDR that was used in the UDP packet.

        If Target is unable to initialize the UDP channel, it MUST return a &remoteserver; error to RequesteRequester.

        Note: Since UDP is not reliable, the Target SHOULD resend the UDP packet if the reply notification is not received within a short time (a 5-second retry is RECOMMENDED). The StreamHost SHOULD ignore duplicate UDP initialization packets once it has replied with a notification.

        @@ -758,7 +758,7 @@ ATYP = X'03' DST.ADDR = SHA1 Hash of: (SID + Requester JID + Target JID) DST.PORT = 0 DATA = (payload) - ]]> +]]>

        UDP packets sent from the StreamHost do not have any SOCKS5 headers, and so the payload shall be delivered as-is.

        The programming interface for a SOCKS5 Bytestreams-aware UDP MUST report an available buffer space for UDP datagrams that is smaller than the actual space provided by the operating system and SOCKS5 layer if applicable. In other words, 4 more octets smaller.

         @@ -874,7 +874,7 @@ DATA = (payload) XEP-0065 - ]]> +]]> @@ -954,7 +954,7 @@ DATA = (payload) - ]]> +]]> diff --git a/xep-0066.xml b/xep-0066.xml index f1361fbc..504bb1ec 100644 --- a/xep-0066.xml +++ b/xep-0066.xml @@ -99,14 +99,14 @@ A license to Jabber! - ]]> +]]>

        The expected result is for the recipient to retrieve the file via an HTTP GET request and to then inform the sender of successful receipt of the file. The receiving application MUST NOT send the IQ result until it has retrieved the complete file (e.g., it MUST NOT send the IQ result if it has merely attempted to retrieve the file or the URL provided seems to be valid):

        - ]]> +]]>

        If the recipient attempts to retrieve the file but is unable to do so, the receiving application MUST return an &IQ; of type 'error' to the sender specifying a Not Found condition:

        - ]]> +]]>

        If the recipient rejects the request outright, the receiving application MUST return an &IQ; of type 'error' to the sender specifying a Not Acceptable condition:

        - ]]> +]]>

        The 'jabber:x:oob' namespace is used to communicate a URI to another user or application. This is done by including an &X; child element qualified by the 'jabber:x:oob' namespace in either a &MESSAGE; and &PRESENCE; stanza; the &X; child MUST contain a <url/> child specifying the URL of the resource, and MAY contain an optional <desc/> child describing the resource.

        @@ -148,7 +148,7 @@ http://www.jabber.org/images/psa-license.jpg - ]]> +]]>

        If an entity supports the out of band data protocol, it MUST report that by including a service discovery feature of "jabber:iq:oob" and/or "jabber:x:oob" in response to a &xep0030; information request:

        @@ -159,7 +159,7 @@ id='disco1'> - ]]> +]]> - ]]> +]]>

        The value of the <url/> element is not limited to URIs that conform to the http: URI scheme (as specified by &rfc2616;). For example, file transfers could also be effected using ftp: URIs as (specified by &rfc0959;). Going further afield, several existing Jabber clients use the callto: URI scheme to initiate voice conferencing via NetMeeting or GnomeMeeting. Other out-of-band communications could be initiated in a similar way via URI schemes such as sip: (as specified by &rfc3261;). All of these usages are allowed by the existing OOB namespaces, as long as the value of the <url/> element is a valid URI (as specified by &rfc3986;).

        @@ -205,7 +205,7 @@ - ]]> +]]> - ]]> +]]> http://www.shakespeare.lit/files/letter.txt - ]]> +]]> - ]]> +]]>

        As with any mechanism that communicates a URI, care must be taken by the receiving application to ensure that the resource retrieved does not contain harmful or malicious data (e.g., a virus-infected file).

        @@ -283,7 +283,7 @@ - ]]> +]]> - ]]> +]]>         diff --git a/xep-0068.xml b/xep-0068.xml index eefe04eb..fe19bfb7 100644 --- a/xep-0068.xml +++ b/xep-0068.xml @@ -138,7 +138,7 @@ - ]]> +]]>

        In the following example, the FORM_TYPE is 'http://jabber.org/protocol/pubsub', all of the fields whose names start with "pubsub#" are registered with the XMPP Registrar (see &xep0060;), and the custom "time_restrictions" field defined by the organization at example.com uses Clark Notation in the field name.

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

        The following example shows a user's interaction with a Multi-User Chat room in order to register with the room.

        @@ -201,7 +201,7 @@ id='reg1'> - ]]> +]]> - ]]> +]]> - ]]> +]]>         @@ -322,7 +322,7 @@ type='the_field_type' label='natural-language description of field'/> - ]]> +]]>

        The registrant MAY register more than one FORM_TYPE at a time, each contained in a separate <form_type/> element. The registrant MAY also register more than one field at a time, each contained in a separate <field/> child element. Registrations of new fields within an existing FORM_TYPE MUST include the full XML snippet but SHOULD NOT include the FORM_TYPE description (only the name and the XEP number or other document identifier). Note that for ease of use the format for the <field/> element in the registry submission is the same as that defined in XEP-0004; in addition, the value of the 'type' attribute MUST be one of those defined in XEP-0004.

        In addition, a registrant MAY also register particular field option values for fields of type 'list-single' and 'list-multi'. The format for such submissions is as follows:

        - ]]> +]]> diff --git a/xep-0070.xml b/xep-0070.xml index 308776b8..dc5f853a 100644 --- a/xep-0070.xml +++ b/xep-0070.xml @@ -167,7 +167,7 @@

        An example is provided below:

        +]]>

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

        @@ -181,7 +181,7 @@ WWW-Authenticate: Digest realm="xmpp", nonce="ec2cc00f21f71acd35ab9be057970609", qop="auth", algorithm="MD5" - ]]> +]]>

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

        @@ -195,7 +195,7 @@ WWW-Authenticate: Digest realm="xmpp",

        (Refer to RFC 2617 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.

        @@ -210,7 +210,7 @@ Authorization: Digest username="juliet@capulet.com", cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" - ]]> +]]>

        The HTTP Server MAY offer any other valid authentication scheme, instead of or in addition to the Basic and Digest schemes mentioned above, as long as the scheme makes it possible to specify a userid (JID) and transaction identifier as described above. However, it is RECOMMENDED to implement both the Basic and Digest authentication schemes.

        @@ -235,7 +235,7 @@ Authorization: Digest username="juliet@capulet.com", method='GET' url='https://files.shakespeare.lit:9345/missive.html'/> - ]]> +]]> - ]]> +]]>

        If the confirmation request was provided via an &IQ; stanza, the XMPP Client MUST respond to the request by sending an &IQ; stanza back to the XMPP Server. If the user wishes to confirm the request, the &IQ; response stanza MUST be of type "result" and MAY contain the original <confirm/> child element (although this is not necessary since the XMPP 'id' attribute can be used for tracking purposes):

        @@ -268,7 +268,7 @@ Authorization: Digest username="juliet@capulet.com", from='juliet@capulet.com/balcony' to='files.shakespeare.lit' id='ha000'/> - ]]> +]]>

        If the user wishes to deny the request, the &IQ; response stanza MUST be of type "error", MAY contain the original <confirm/> child element (although this is not necessary since the XMPP 'id' attribute can be used for tracking purposes), and MUST specify an error, which SHOULD be ¬authorized;:

        - ]]> +]]>

        If the confirmation request was provided via a &MESSAGE; stanza and the &MESSAGE; contains a human-readable &BODY; or does not contain a &BODY; but the XMPP Client understands the 'http://jabber.org/protocol/http-auth' namespace, the XMPP Client SHOULD respond to the request by sending a &MESSAGE; stanza back to the XMPP Server. If the user wishes to confirm the request, the &MESSAGE; response stanza SHOULD be of type "normal", MUST mirror the <thread/> ID (if provided by the XMPP Server), and MUST contain the original <confirm/> child element:

        - ]]> +]]>

        If the user wishes to deny the request, the &MESSAGE; response stanza MUST be of type "error", MUST mirror the <thread/> ID (if provided by the XMPP Server), MUST contain the original <confirm/> child element, and MUST specify an error, which SHOULD be ¬authorized;:

        - ]]> +]]>

        Once the XMPP Client has successfully confirmed the request, the XMPP Server forwards that confirmation to the HTTP Server, which allows access:

        @@ -319,11 +319,11 @@ Content-Type: text/html Content-Length: 3032 ... - ]]> +]]>

        If the XMPP Client denied the request, the HTTP Server MUST return a Forbidden error:

        +]]>         @@ -392,6 +392,6 @@ Content-Length: 3032 - ]]> +]]> diff --git a/xep-0071.xml b/xep-0071.xml index 0eabf2dd..cc6c0ff3 100644 --- a/xep-0071.xml +++ b/xep-0071.xml @@ -237,7 +237,7 @@ - ]]> +]]>

        Technically speaking, there are three aspects to the approach taken herein:

        1. Definition of the <html/> "wrapper" element, which functions as an XMPP extension within XMPP <message/> stanzas.
          2. @@ -605,7 +605,7 @@ - ]]> +]]>

          This could be rendered as follows:

          Wow, I'm green with envy!

          @@ -625,7 +625,7 @@ - ]]> +]]>

          This could be rendered as follows:

          As Emerson said in his essay Self-Reliance:

          @@ -649,7 +649,7 @@ - ]]> +]]>

          This could be rendered as follows:

          Hey, are you licensed to Jabber?

          @@ -684,7 +684,7 @@ - ]]> +]]>

          This could be rendered as follows:

          Here's my .plan for today:

          @@ -729,7 +729,7 @@ That seems fine to me. - ]]> +]]>

          Although quoting received messages is relatively uncommon in IM, it does happen. This could be rendered as follows:

          You wrote:

          @@ -757,7 +757,7 @@ That seems fine to me. - ]]> +]]>

          How multiple bodies would best be rendered will depend on the user agent and relevant application. For example, a specialized Jabber client that is used in foreign language instruction might show two languages side by side, whereas a dedicated IM client might show content only in a human user's preferred language as captured in the client configuration.

          @@ -795,7 +795,7 @@ That seems fine to me. - ]]> +]]>

          Let us assume that the recipient's user agent recognizes neither the <acronym/> element (which is discouraged in XHTML-IM) nor the 'type' and 'start' attributes of the <ol/> element (which, after all, were deprecated in HTML 4.0), and that it does not render nested elements (e.g., the <p/> elements within the <li/> elements); in this case, it could render the content as follows (note that the element value is shown as text and the attribute value is not rendered):

          The XHTML user agent conformance requirements say to ignore elements and attributes you don't understand, to wit:

          @@ -816,7 +816,7 @@ That seems fine to me. id='disco1'> - ]]> +]]>

          If the queried entity supports XHTML-IM, it MUST return a <feature/> element with a 'var' attribute set to a value of "http://jabber.org/protocol/xhtml-im" in the IQ result.

          - ]]> +]]>

          Naturally, support can also be discovered via the dynamic, presence-based profile of service discovery defined in &xep0115;.

          @@ -866,7 +866,7 @@ That seems fine to me.

          The Formal Public Identifier (FPI) for the XHTML-IM document type definition is:

          +]]>

          The fields of this FPI are as follows:

          1. The leading field is "-", which indicates that this is a privately-defined resource.
            2. @@ -963,7 +963,7 @@ That seems fine to me. - ]]> +]]>

            The following schema defines the modularization schema driver for XHTML-IM.

            @@ -1031,7 +1031,7 @@ That seems fine to me. schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-struct-1.xsd"/> - ]]> +]]>

            The following schema defines the content model for XHTML-IM.

            @@ -1255,7 +1255,7 @@ That seems fine to me. - ]]> +]]>             diff --git a/xep-0072.xml b/xep-0072.xml index 2f6b1988..1263e664 100644 --- a/xep-0072.xml +++ b/xep-0072.xml @@ -142,7 +142,7 @@ type='get'> - ]]> +]]>

            If the responding entity supports the SOAP XMPP Binding and the requesting entity is not blocked from communicating with the responding entity, the responding entity MUST include a feature of "http://jabber.org/protocol/soap" in its reply and SHOULD specify a service discovery identity of "automation/soap".

             - ]]> +]]>

            When a requesting entity wants to interact with a responding entity via the SOAP XMPP Binding, it faces a fundamental choice: to use &IQ; stanzas or to use &MESSAGE; stanzas. The following guidelines may prove useful:

            @@ -210,7 +210,7 @@ - ]]> +]]>

            If the responding entity does not support the SOAP XMPP Binding, it SHOULD return a &unavailable; error:

            @@ -218,7 +218,7 @@ - ]]> +]]>

            If a SOAP-related fault occurs, the mappings in Error Handling SHOULD be used.

            @@ -244,7 +244,7 @@ - ]]> +]]>

            If the responding entity does not return an error, it MUST respond with an IQ of type "result":

            - ]]> +]]>

            At this point the requesting entity could send another IQ-set:

            - ]]> +]]>

            The process for exchanging SOAP messages using the XMPP &MESSAGE; stanza type is effectively no different from the use with &IQ; stanzas, except that message stanzas may be sent to bare JIDs (user@host) rather than full JIDs (user@host/resource), message stanzas may be stored for later delivery, etc. The following business rules apply:

            @@ -403,7 +403,7 @@ date='2005-11-01T23:11Z'/> - ]]> +]]>

            The entity that is to receive the file SHOULD initiate the file transfer process sending an IQ-get to the sender, using the <start xmlns='http://jabber.org/protocol/sipub'/> element. This element contains the 'id' attribute to specify which published stream to retrieve:

            - ]]> +]]>

            If the sender accepts the request, it responds with an IQ-result containing a <starting/> element. This element indicates the stream initiation identifier to be used:

            - ]]> +]]>

            Then the sender begins the stream initiation negotiation:

            - ]]> +]]>

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

             @@ -480,7 +480,7 @@ John Q. Public - ]]> +]]>

            Alternatively, if all else fails, the file may be included as a SOAP representation header:

            - ]]> +]]>

            Naturally, in order to maximize the likelihood that the receiver will be able to retrieve the file, the sender MAY include the SI-pub extension, out-of-band-data extension, and SOAP representation header in the message stanza:

            John Q. Public - ]]> +]]>             @@ -615,7 +615,7 @@ - ]]> +]]>

            Although there is no standard procedure for publishing WSDL documents, usually they are made available through HTTP at some URL discoverable with public registries such as UDDI servers. WSDL descriptions for XMPP bindings MAY follow the same publishing process, or MAY be discoverable through Jabber/XMPP specific mechanisms such as &xep0030; or &xep0060;.

                         @@ -1112,7 +1112,7 @@ XEP-0072 - ]]> +]]> @@ -1150,7 +1150,7 @@ - ]]> +]]> @@ -1187,7 +1187,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.

            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-0074.xml b/xep-0074.xml index 0aa8ca82..070cd1e2 100644 --- a/xep-0074.xml +++ b/xep-0074.xml @@ -49,7 +49,7 @@ oper="uri://capulet.com/inventory#obtain" target="poison"/> - ]]> +]]>

            Here we have the inventory.capulet.com component querying the security component as to whether juliet@ may obtain the requested poison.

            @@ -64,7 +64,7 @@ - ]]> +]]>

            Unfortunately, the response is in the affirmative and the romantic tragedy follows.

            @@ -88,7 +88,7 @@ - ]]> +]]> - ]]> +]]> No information available - ]]> +]]> @@ -127,7 +127,7 @@ type="get" id="1234"> - ]]> +]]>

            The to jid must then respond with a list of operations, if the jid supports SAC.

            @@ -141,7 +141,7 @@             - ]]> +]]>             diff --git a/xep-0075.xml b/xep-0075.xml index 821493dd..371345f9 100644 --- a/xep-0075.xml +++ b/xep-0075.xml @@ -592,7 +592,7 @@ to='TrackSegment@trainset.example.com/134' > - ]]> +]]>

            The instance returns this stanza to the JOAP client.

            - ]]> +]]>

            In return, the instance would send this stanza to the client:

            @@ -717,7 +717,7 @@ cars - ]]> +]]>

            In return, the instance would send this stanza to the client:

            @@ -799,7 +799,7 @@ PassengerCar@trainset.example.com/866 - ]]> +]]>

            Note that the class created a new instance identifier, 866, for the new instance. Further communications from the client would use the full instance address returned.

            @@ -854,7 +854,7 @@ - ]]> +]]>

            The client would return the following stanza:

            - ]]> +]]>

            If a client wanted to change the name of a Building, it would send the following stanza to the instance:

            - ]]> +]]>

            The results would be as follows:

            Building@trainset.example.com/SmithFamilyHome - ]]> +]]>

            Note that the instance indentifier, and thus the instance address, of the instance has changed. The from part of the IQ, however, contains the old address.

            @@ -1814,6 +1814,6 @@ boolean switchTo(TrackSegment) Station: TrackSegment, Building - ]]> +]]>             diff --git a/xep-0076.xml b/xep-0076.xml index 96553590..826827ac 100644 --- a/xep-0076.xml +++ b/xep-0076.xml @@ -54,7 +54,7 @@ - ]]> +]]>

            If an evil entity sends evil presence information, it MUST include an appropriately namespaced extension in the presence stanza:

            @@ -64,7 +64,7 @@ Fomenting dissension - ]]> +]]>

            If an evil entity provides evil information in an IQ exchange, it MUST include an appropriately namespaced extension in the IQ stanza:

            @@ -79,7 +79,7 @@ - ]]> +]]>             @@ -91,7 +91,7 @@ type='get'> - ]]> +]]> - ]]> +]]>

            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.

             diff --git a/xep-0077.xml b/xep-0077.xml index f64940c9..da2823a0 100644 --- a/xep-0077.xml +++ b/xep-0077.xml @@ -168,7 +168,7 @@ - ]]> +]]>

            If the entity is not already registered and the host supports In-Band Registration, the host MUST inform the entity of the required registration fields. If the host does not support In-Band Registration, it MUST return a &unavailable; error. If the host is redirecting registration requests to some other medium (e.g., a website), it MAY return an <instructions/> element only, as shown in the Redirection section of this document.

            @@ -182,7 +182,7 @@ - ]]> +]]>

            If the host determines (based on the 'from' address) that the entity is already registered, the IQ result that it sends in response to the IQ get MUST contain an empty <registered/> element (indicating that the entity is already registered), SHOULD contain the registration information currently on file for the entity (although the <password/> element MAY be empty), and SHOULD contain an <instructions/> element (whose XML character data MAY be modified to reflect the fact that the entity is currently registered).

            If the host is an instant messaging server, it SHOULD assume that the requesting entity is unregistered at this stage unless the entity has already authenticated (for details, see the Registration with a Server section below).

            juliet@capulet.com - ]]> +]]>

            If the entity is not already registered, the entity SHOULD provide the required information.

            @@ -204,11 +204,11 @@ bard@shakespeare.lit - ]]> +]]>

            Note: The requesting entity MUST provide information for all of the elements (other than <instructions/>) contained in the IQ result.

            - ]]> +]]>

            Alternatively, registration may fail. Possible causes of failure include a username conflict (the desired username is already in use by another entity) and the fact that the requesting entity neglected to provide all of the required information.

            @@ -221,7 +221,7 @@ - ]]> +]]>

            If the requesting entity does not provide all of the requested information during registration This includes providing an empty password element or a password element that contains no XML character data, i.e., either <password/> or <password></password>. then the server or service MUST return a ¬acceptable; error to the requesting entity.

            @@ -233,7 +233,7 @@ - ]]> +]]>

            If the host requires additional information above and beyond the data elements specified in the schema, it SHOULD use Data Forms as described in the Extensibility section of this document. (The next three examples show registration of an existing account with a third-party service, not of an entity with a server for the purpose of account registration.)

            - ]]> +]]> - ]]> +]]>

            The user then SHOULD return the form:

            - ]]> +]]>

            Special care must be taken when an unregistered entity interacts with a server rather than a service. Normally, a server enables in-band registration so that entities can "bootstrap" their participation in the Jabber network; this bootstrapping happens when an unregistered and unauthenticated entity opens a TCP connection to a server and immediately completes the registration use case with the server, then authenticates using the newly-registered identity. As noted, when a server receives an IQ-get for registration information, it SHOULD assume that the requesting entity is unregistered unless the entity has already authenticated.

            Depending on local service provisioning, a server MAY return a ¬acceptable; stanza error if an unregistered entity attempts to register too many times before authenticating or if an entity attempts to register a second identity after successfully completing the registration use case; a server MAY also return a <not-authorized/> stream error if the unregistered entity waits too long before authenticating or attempts to complete a task other than authentication after successfully completing the registration use case.

            @@ -319,10 +319,10 @@ - ]]> +]]> - ]]> +]]>

            There are two scenarios:

            1. If the entity cancels its registration with its "home" server (i.e., the server at which it has maintained its XMPP account), then the entity SHOULD NOT include a 'from' or 'to' address in the remove request the server SHOULD then return a <not-authorized/> stream error and terminate all active sessions for the entity. The server SHOULD perform the remove based on the bare JID &LOCALBARE; associated with the current session or connection over which it received the remove request. If the server is an instant messaging and presence server that conforms to &xmppim;, the server SHOULD also cancel all existing presence subscriptions related to that entity (as stored in the entity's roster).

              2. @@ -343,21 +343,21 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]>

              A given deployment MAY choose to require additional information (such as the old password or previously-gathered personal information) before cancelling the registration. In order to do so, the server or service SHOULD return a Data Form in the error stanza:

              @@ -383,7 +383,7 @@ - ]]> +]]>

              The user then SHOULD return the form:

              @@ -404,7 +404,7 @@ - ]]> +]]>

              The 'jabber:iq:register' namespace enables a user to change his or her password with a server or service. Once registered, the user can change passwords by sending an XML stanza of the following form:

              @@ -415,12 +415,12 @@ newpass - ]]> +]]>

              Because the password change request contains the password in plain text, a client SHOULD NOT send such a request unless the underlying stream is encrypted (using SSL or TLS) and the client has verified that the server certificate is signed by a trusted certificate authority. A given deployment MAY choose to disable password changes if the stream is not properly encrypted, to disable in-band password changes, or to require additional information (such as the old password or previously-gathered personal information) before changing the password.

              If the user provides an empty password element or a password element that contains no XML character data (i.e., either <password/> or <password></password>), the server or service MUST NOT change the password to a null value, but instead MUST maintain the existing password.

              - ]]> +]]>

              Several error conditions are possible:

@@ -436,21 +436,21 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]>

In order to require additional information before changing the password, the server or service SHOULD return a Data Form in the error stanza:

@@ -479,7 +479,7 @@ - ]]> +]]>

The user then SHOULD return the form:

@@ -503,7 +503,7 @@ - ]]> +]]> @@ -533,7 +533,7 @@ - ]]> +]]>

Given the foregoing discussion, it is evident that an entity could receive any combination of iq:register, x:data, and x:oob namespaces from a service in response to a request for information. The precedence order is as follows:

@@ -604,7 +604,7 @@ - ]]> +]]>

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

 @@ -619,7 +619,7 @@ type='get'> - ]]> +]]> - ]]> +]]>

Although connecting clients typically determine support during stream negotiation via the stream feature, the service discovery feature is helpful for server-to-server connections as well as for clients that are already connected (e.g., to determine if password changes are possible in-band).

 @@ -652,13 +652,13 @@

The 'jabber:iq:register' namespace include a mechanism for creating a registration. The registered querytype for doing so is "register".

+]]>

Because registration is a two-step process, the application MUST then send an IQ-get to the entity in order to retrieve the required registration fields:

- ]]> +]]> @@ -666,7 +666,7 @@ xmpp:marlowe.shakespeare.lit?register - ]]> +]]>

The application MUST then present an appropriate interface that enables the user to complete the registration form. Once the user provides the information, the application MUST send an IQ-set to the entity.

@@ -675,7 +675,7 @@ xmpp:marlowe.shakespeare.lit?register R0m30 - ]]> +]]>

The following submission registers the "register" querytype.

@@ -684,20 +684,20 @@ xmpp:marlowe.shakespeare.lit?register enables registering with a server or service XEP-0077 - ]]> +]]>

The 'jabber:iq:register' namespace include a mechanism for cancelling an existing registration. The registered querytype for doing so is "unregister".

+]]> - ]]> +]]>

The following submission registers the "unregister" querytype.

@@ -706,7 +706,7 @@ xmpp:marlowe.shakespeare.lit?unregister enables cancellation of a registration with a server or service XEP-0077 - ]]> +]]> @@ -786,7 +786,7 @@ xmpp:marlowe.shakespeare.lit?unregister type='text-single' label='Session key for transaction (obsolete)'/> - ]]> +]]> - ]]> +]]> - ]]> +]]> @@ -894,7 +894,7 @@ xmpp:marlowe.shakespeare.lit?unregister - ]]> +]]> - ]]> +]]> diff --git a/xep-0078.xml b/xep-0078.xml index cb7500b1..f9a78b6c 100644 --- a/xep-0078.xml +++ b/xep-0078.xml @@ -185,7 +185,7 @@ - ]]> +]]> @@ -195,7 +195,7 @@ - ]]> +]]>

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.

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

@@ -208,7 +208,7 @@ globe - ]]> +]]>

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

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

    @@ -225,12 +225,12 @@ globe - ]]> +]]>

    The character data shown in the <digest/> element is the output produced as a result of following the algorithm defined above when the stream ID is '3EE948B0' and the password is 'Calli0pe'.

    If the credentials provided match those known by the server, the client will be successfully authenticated.

    - ]]> +]]>

    Alternatively, authentication may fail. Possible causes of failure include:

    1. The user provided incorrect credentials.
      2. @@ -244,21 +244,21 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]> @@ -271,7 +271,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).

       @@ -333,7 +333,7 @@ - ]]> +]]> - ]]> +]]> diff --git a/xep-0079.xml b/xep-0079.xml index c16b2547..7d1f3125 100644 --- a/xep-0079.xml +++ b/xep-0079.xml @@ -175,7 +175,7 @@ type='get'> - ]]> +]]> - ]]> +]]>

      A server SHOULD also maintain a service discovery node named "http://jabber.org/protocol/amp", at which it advertises the individual actions and conditions it supports. If an entity needs to determine whether the server supports individual actions and conditions, it SHOULD send a service discovery information request to that node; the server then MUST either return the list of supported actions and conditions or return an error such as &feature;. (Note: If the server does not provide information for this disco node, the requesting entity MUST assume that all actions and conditons are supported for each reported action set or condition set.)

      Each supported action shall be reported as a feature using the following format:

      http://jabber.org/protocol/amp?action={action} @@ -201,7 +201,7 @@ - ]]> +]]> - ]]> +]]>

      Once support is determined, the sender can attach the desired delivery semantics to the message:

      @@ -236,7 +236,7 @@ value='2004-01-01T00:00:00Z'/> - ]]> +]]>

      The semantics are defined as a set of <rule/> elements within the <amp/> root element. Each <rule/> declares the condition to trigger on and the action to execute if triggered.

      By default, the ruleset applies only to the "edge servers": those servers to which the sending and receiving entities are connected. (Note: For the purposes of Advanced Message Processing, "server" is defined as in XMPP Core and does not include any internal components, such as connection managers, that may provide functionality within a server implementation or installation.)

      The ruleset MAY be applied to all server-to-server "hops" along the route from the sending and receiving entities by adding the "per-hop' attribute to the <amp/> element. The value of this attribute is either "true" (apply rules to all hops) or "false" (follow default behavior, i.e., apply rules at the edge servers only).

      @@ -253,7 +253,7 @@ value='2004-01-01T00:00:00Z'/> - ]]> +]]>

      For examples of validation failure, refer to the Error Handling section of this document.

      Note: Even if "per-hop" processing is requested, each server in the route MUST ignore rules that cannot apply to it; the Defined Conditions outline if they can be applied per-hop.

       @@ -420,7 +420,7 @@ - ]]> +]]>

      The "drop" action silently discards the message from any further delivery attempts and ensures that it is not placed into offline storage. The drop MUST NOT result in other responses.

      @@ -445,7 +445,7 @@ - ]]> +]]>

      Note that the error SHOULD be of type "modify", and the general error condition SHOULD be <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>.

       @@ -461,7 +461,7 @@ - ]]> +]]> @@ -707,7 +707,7 @@ - ]]> +]]>

      In the above case, the sender would receive an error reply if the message could not be delivered specifically to "francisco@hamlet.lit/pda" by the specified time. For example, if the intended resource went offline before the message could be delivered, the processing server would return the following error:

      - ]]> +]]>

      Time-sensitive messages are a frequent occurrence in some environments (e.g., front-office personnel routinely notify others of "events" such as guests, unexpected refreshments, and ad-hoc gatherings). To send a time-sensitive message, the sending entity includes a <rule action='drop' condition='expire-at'/> with the time when the event is to occur:

      @@ -742,7 +742,7 @@ - ]]> +]]>

      In the above case, the server for "linuxwolf@outer-planes.net" would not deliver the message once 23:00 UTC (3:00 PM Pacific Daylight Time) has passed.

       @@ -757,7 +757,7 @@ - ]]> +]]>

      Alternatively, the sending entity includes a <rule action='alert' condition='deliver' value='stored'/> to be alerted instead of having the message silently dropped:

      - ]]> +]]> - ]]> +]]>       @@ -858,7 +858,7 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> @@ -1011,7 +1011,7 @@ - ]]> +]]>

      Most AMP conditions could be used by unauthorized individuals to gain access to presence information about users of IM servers and other presence-based messaging systems. For example, consider the following scenario: the user <romeo@montague.net> is not an authorized subscriber to the presence of the user <nurse@capulet.com>, but sends a &MESSAGE; stanza with a "deliver" rule of "stored" and an action of "alert" to that address; if the Nurse is not online, Romeo would receive an AMP alert that the message has been stored offline, in the process discovering that the Nurse is offline. Similar scenarios are possible with the "match-resource" rule (send to the user's usual resource) and the "expire-at" rule (send messages every minute to poll for presence). If a server implements presence subscriptions as specified in &rfc3921;, it SHOULD NOT return alerts, errors, or other AMP notifications to senders who are not authorized to view the recipient's presence information (via a subscription of "both" or "from") if the notification would reveal the recipient's status as online or offline. An exception might be fully-trusted or closed networks. @@ -1053,7 +1053,7 @@ values that result in message processing the document (e.g., XEP) in which this condition is specified - ]]> +]]>

      The registrant may register more than one condition at a time, each contained in a separate <condition/> element.

      Note: The namespace for the condition set shall be included in the Service Discovery features registry.

      @@ -1104,7 +1104,7 @@ XEP-0079 - ]]> +]]> @@ -1118,7 +1118,7 @@ the expected behavior if the rule is triggered the document (e.g., XEP) in which this action is specified - ]]> +]]>

      The registrant may register more than one action at a time, each contained in a separate <action/> element.

      Note: The namespace for the action set shall be included in the Service Discovery features registry.

      @@ -1162,7 +1162,7 @@ XEP-0079 - ]]> +]]>       @@ -1230,7 +1230,7 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]>       diff --git a/xep-0080.xml b/xep-0080.xml index bace23da..b441c692 100644 --- a/xep-0080.xml +++ b/xep-0080.xml @@ -335,7 +335,7 @@ - ]]> +]]> @@ -353,7 +353,7 @@ - ]]> +]]>

      In order to indicate that the user is no longer publishing any location information, the user's client shall send an empty <geoloc/> element, which can be considered a "stop command" for geolocation:

      - ]]> +]]> @@ -379,7 +379,7 @@ - ]]> +]]>       @@ -558,6 +558,6 @@ - ]]> +]]> diff --git a/xep-0081.xml b/xep-0081.xml index ad01ac3a..2d054c16 100644 --- a/xep-0081.xml +++ b/xep-0081.xml @@ -90,7 +90,7 @@ - ]]> +]]>

      The browser passes this file to the helper application, which shall instantiate an appropriate interface for sending a single message to the JID defined in the file. If the user completes the interface, the helper application shall then send a message stanza of type='normal' as specified in &xmppim;, first authenticating with the user's Jabber/XMPP server if necessary.

      @@ -99,7 +99,7 @@ - ]]> +]]>

      The browser passes this file to the helper application, which shall instantiate an appropriate interface for chatting with the JID defined in the file. If the user completes the interface, the helper application shall then send a message stanza of type='chat' as specified in XMPP IM, first authenticating with the user's Jabber/XMPP server if necessary.

       @@ -108,7 +108,7 @@ - ]]> +]]>

      The browser passes this file to the helper application, which shall instantiate an appropriate interface for sending a presence subscription request to the JID defined in the file (e.g., specifying a name and/or group for the contact). If the user completes the interface, the helper application shall then send a presence stanza of type='subscribe' as specified in XMPP IM, first authenticating with the user's Jabber/XMPP server if necessary. The helper application SHOULD perform a "roster set" before sending the presence subscription request, as described in XMPP IM.

       @@ -117,7 +117,7 @@ - ]]> +]]>

      The browser passes this file to the helper application, which shall instantiate an appropriate interface for joining the conference room associated with the JID defined in the file. If the user completes the interface, the helper application shall then send a directed presence stanza to the JID (appending a room nickname to the JID as the resource identifier) as described in &xep0045;, first authenticating with the user's Jabber/XMPP server if necessary.

       @@ -126,7 +126,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.

       @@ -179,7 +179,7 @@ Work - ]]> +]]>

      The username, password, and resource are not required if there is some other extension inside authenticate, that, e.g. does SSO. Authenticate is mostly useful only for these SSO situations, anyway. If the user is already connected, the application SHOULD ignore the <connect/> block.

      --> @@ -219,7 +219,7 @@ Person and email address to contact for further information: XMPP Registrar, Intended usage: COMMON Author/Change controller: XSF, XMPP Registrar - ]]> +]]> @@ -259,7 +259,7 @@ Author/Change controller: XSF, XMPP Registrar - ]]> +]]>
        diff --git a/xep-0083.xml b/xep-0083.xml index 1f2e1c22..d36ce0ad 100644 --- a/xep-0083.xml +++ b/xep-0083.xml @@ -73,7 +73,7 @@ SERVER: :: - ]]> +]]>

        Now that the client has a delimiter, we can retrieve and parse the roster properly.

        @@ -116,7 +116,7 @@ SERVER: - ]]> +]]>

        Bottom, Quince and Snug should be grouped together in a group 'Actors' underneath the group 'Midsummer'. Theseus and Hippolyta should be grouped together in a group 'Royalty' under 'Midsummer'. Robin Goodfellow, meanwhile, being in a class unto himself, is a plain contact under the 'Midsummer' group rather than in an actual sub-group. The group Hamlet, containing only one melancholy prince and his mother, contains no sub-groups at all.

        As should be apparent, a client which does not support the delimiter will instead create a separate group -- such as 'Midsummer::Actors' -- and thus will still have each set of contacts grouped with the other appropriate contacts.

         @@ -151,6 +151,6 @@ SERVER: - ]]> +]]> diff --git a/xep-0084.xml b/xep-0084.xml index 9507baa5..3940e1da 100644 --- a/xep-0084.xml +++ b/xep-0084.xml @@ -176,10 +176,10 @@ - ]]> +]]> - ]]> +]]>

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

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

        The following example shows metadata specifying avatar data that is available at an HTTP URL.

        @@ -220,7 +220,7 @@ - ]]> +]]>

        The user's virtual pubsub service would then send the metadata notification to entities that have subscribed to the user's metadata node or contacts who have advertised an interest in receiving avatar metadata by including a &xep0115; feature of "urn:xmpp:avatar:metadata+notify".

        @@ -243,7 +243,7 @@
        - ]]> +]]>

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

        @@ -260,7 +260,7 @@ - ]]> +]]>

        The PEP service running at the user's server then SHOULD return the avatar data.

        - ]]> +]]>

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

         @@ -292,7 +292,7 @@ - ]]> +]]>

        As before, subscribers to the metadata node would then receive the notification.

        @@ -304,7 +304,7 @@ - ]]> +]]>

        Note: In an earlier version of this specification, the user indicated that it wanted to disable publishing by sending a <metadata/> element containing a <stop/> child element. For consistency with other PEP payload formats, support for the <stop/> element is deprecated.

         @@ -321,7 +321,7 @@ IMAGE DATA - ]]> +]]>

        The XML character data MUST represent the image data for the avatar with a content-type of "image/png", Base64-encoded in accordance with Section 4 of &rfc4648;. (Note: Line feeds SHOULD NOT be added but MUST be accepted.)

        The <data/> element MUST NOT possess any attributes.

        Support for the <data/> element is REQUIRED.

        @@ -345,7 +345,7 @@ url='HTTP-URL-for-image-data' width='image-width-in-pixels'/> - ]]> +]]>

        The <info/> child element MUST be empty.

        The defined attributes of the <info/> element are specified in the following table.

ConditionDescription
@@ -395,7 +395,7 @@ ... APPLICATION-SPECIFIC DATA ... - ]]> +]]>

The <pointer/> element MAY possess the following attributes if the publishing application has the relevant information:

diff --git a/xep-0090.xml b/xep-0090.xml index 40ce69b0..e99f780d 100644 --- a/xep-0090.xml +++ b/xep-0090.xml @@ -68,7 +68,7 @@ id='time_1'> - ]]> +]]> Tue Sep 10 12:58:35 2002 - ]]> +]]>

The standard error conditions described in &xep0086; apply (e.g., service unavailable if the entity does not support the namespace).

@@ -127,6 +127,6 @@ - ]]> +]]> diff --git a/xep-0091.xml b/xep-0091.xml index 8d5164c8..a5c8908c 100644 --- a/xep-0091.xml +++ b/xep-0091.xml @@ -98,7 +98,7 @@ Offline Storage - ]]> +]]> anon! @@ -108,7 +108,7 @@ from='juliet@capulet.com/balcony' stamp='20020910T23:41:07'/> - ]]> +]]> - ]]> +]]>

&xep0082; defines the lexical representation of dates, times, and datetimes in Jabber protocols. Unfortunately, the 'jabber:x:delay' namespace predates that definition, and uses a datetime format ("CCYYMMDDThh:mm:ss") that is inconsistent with XEP-0082 and &w3xmlschema2;. Because a large base of deployed software uses the old format, this document specifies that applications using 'jabber:x:delay' SHOULD use the old format, not the format defined in XEP-0082. The timezone is be understood as UTC.

@@ -171,6 +171,6 @@ - ]]> +]]> diff --git a/xep-0092.xml b/xep-0092.xml index 06fe5257..3c803c2b 100644 --- a/xep-0092.xml +++ b/xep-0092.xml @@ -63,7 +63,7 @@ id='version_1'> - ]]> +]]> Windows-XP 5.01.2600 - ]]> +]]>

The standard error conditions described in &xep0086; apply (e.g., service unavailable if the entity does not support the namespace).

@@ -87,7 +87,7 @@ id='disco1'> - ]]> +]]> - ]]> +]]>

Revealing the application's underlying operating system may open the user or system to attacks directed against that operating system; therefore, an application MUST provide a way for a human user or administrator to disable sharing of information about the operating system.

@@ -137,6 +137,6 @@ - ]]> +]]> diff --git a/xep-0093.xml b/xep-0093.xml index 4f1431b7..8ef7d429 100644 --- a/xep-0093.xml +++ b/xep-0093.xml @@ -80,7 +80,7 @@ - ]]> +]]>

There are no security features or concerns related to this proposal.

@@ -130,6 +130,6 @@ - ]]> +]]> diff --git a/xep-0094.xml b/xep-0094.xml index dcfea0b9..78b84f44 100644 --- a/xep-0094.xml +++ b/xep-0094.xml @@ -63,7 +63,7 @@ - ]]> +]]> - ]]> +]]>

There are no security features or concerns related to this proposal.

@@ -137,6 +137,6 @@ - ]]> +]]> diff --git a/xep-0095.xml b/xep-0095.xml index 45d44514..dbe29ee3 100644 --- a/xep-0095.xml +++ b/xep-0095.xml @@ -113,7 +113,7 @@ id='info1'> - ]]> +]]>

The Receiver advertises the "http://jabber.org/protocol/si" namespace as a feature to represent that they implement this document. The specific profiles are also announced this way; they can be found by looking for "http://jabber.org/protocol/si/profile/profile-name". Shown in the result is a potential file transfer profile:

- ]]> +]]>

Once support is determined, the Sender starts the negotiation with the Receiver by sending an &IQ; stanza of type "set", such as in the following example from &xep0096;:

@@ -153,7 +153,7 @@ - ]]> +]]>

At this point the Receiver can view the profile and other information to decide if they wish to accept the Stream Initiation. If acceptable the Receiver MUST select one of the presented stream types to use.

- ]]> +]]>

If the profile describes data to be sent back in the result it MUST be present as described in the profile's specification.

@@ -185,7 +185,7 @@ - ]]> +]]>

If none of the stream types are acceptable, or if the profile is not understood, the Receiver MUST reply with a "bad request" error:

@@ -194,7 +194,7 @@ - ]]> +]]> @@ -202,7 +202,7 @@ - ]]> +]]>

If the Receiver rejects the request, they reply with a "forbidden" error:

@@ -211,7 +211,7 @@ Offer Declined - ]]> +]]>

At this point, the Sender and Receiver make any preparations necessary for the stream to be used. The exact process is specific to each protocol, and is beyond the scope of this document. This step now marks the end of SI's responsibilities.

@@ -317,7 +317,7 @@ The specification that defines the profile A natural-language description of the profile - ]]> +]]> @@ -371,6 +371,6 @@ - ]]> +]]> diff --git a/xep-0096.xml b/xep-0096.xml index 96e1f161..6188c12d 100644 --- a/xep-0096.xml +++ b/xep-0096.xml @@ -197,7 +197,7 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]>

This range should retrieve 256 bytes from the beginning of the file:

- ]]> +]]>

This range should retrieve 256 bytes starting from the 128th byte in the file:

- ]]> +]]>

This range should retrieve the remainder of the file starting at the 128th byte in the file:

- ]]> +]]>

This range is the same as having not sent the range request and the entire file is sent:

- ]]> +]]> @@ -293,7 +293,7 @@ XEP-0096 A profile for file transfer between any two entities. - ]]> +]]>

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

@@ -302,7 +302,7 @@

To enable a second entity to send a file, the IRI/URI is of the following form:

+]]>

The application SHOULD then present an interface enabling the user to provide information about the file to be sent (e.g., by "browsing" the file system of the user's computer in order to choose a file). As a result, the application SHOULD then send a &xep0137; message to the XMPP address encapsulated in the IRI/URI:

@@ -316,7 +316,7 @@ xmpp:romeo@montague.net/orchard?sendfile date='2005-11-29T11:21Z'/> - ]]> +]]>

The following submission registers the "sendfile" querytype.

@@ -325,13 +325,13 @@ xmpp:romeo@montague.net/orchard?sendfile enables initiation of an inbound file transfer to XMPP entity XEP-0096 - ]]> +]]>

To enable a second entity to receive a file, the IRI/URI is of the following form:

+]]>

That IRI/URI is equivalent to the following XML stanza:

@@ -344,13 +344,13 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain;name= size='2048'/> - ]]> +]]>

In accordance with XEP-0137, the application SHOULD then initiate a file transfer exchange with by sending a stanza of the following form:

- ]]> +]]>

Note well that the request to begin the stream is sent to the full JID (user@host/resource) of the XMPP entity identified by the XMPP IRI/URI. Therefore, the IRI/URI SHOULD include a full JID. If it does not, the receiver MUST discover a full JID via presence or service discovery. If the receiver cannot discover a full JID for the sender (e.g., in the last resort through sending a presence subscription request to the sender and receiving presence from the sender's resources), then it SHOULD abort the file transfer exchange.

The following submission registers the "recvfile" querytype.

- ]]> +]]> @@ -438,6 +438,6 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain;name= - ]]> +]]> diff --git a/xep-0098.xml b/xep-0098.xml index d342a2c5..9e8cac96 100644 --- a/xep-0098.xml +++ b/xep-0098.xml @@ -107,7 +107,7 @@ SERVER: from="hamlet@shakespeare.lit/denmark" to="hamlet@shakespeare.lit/denmark" id="1001"/> - ]]> +]]> - ]]> +]]>

If a user attempts to get or set http://jabber.org/protocol/private-xml data that belongs to another user, the server must return an error to the sender. The error commonly used is 503 (Service Unavailable).

Service Unavailable - ]]> +]]>

If a user attempts to perform a get without providing a child element, the server should return a 406 (Not Acceptable) error:

Not Acceptable - ]]> +]]>

Certain namespaces are reserved in Jabber (namespaces beginning with 'jabber:' or 'http://jabber.org/', as well as 'vcard-temp'). If a user attempts to get or set http://jabber.org/protocol/private-xml data in a reserved namespace, historically some server implementations have chosen to return an error (commonly 406 [Not Acceptable]) to the sender. Such behavior is not required in order to comply with this document, but may be encountered by clients when interacting with some current server implementations.

Not Acceptable - ]]> +]]>

The server always replies to a properly formatted get query with a result response rather than some form of 'not found' error. @@ -213,7 +213,7 @@ SERVER (does not have data in "imaginary" namespace, returns empty element): - ]]> +]]>

Finally, the client can delete data from the server using the delete query action.

- ]]> +]]> @@ -250,7 +250,7 @@ SERVER (server responds with success): - ]]> +]]> diff --git a/xep-0099.xml b/xep-0099.xml index 93753114..b9efee78 100644 --- a/xep-0099.xml +++ b/xep-0099.xml @@ -124,7 +124,7 @@ RECIPIENT: from="hamlet@shakespeare.lit/denmark" to="hamlet@shakespeare.lit/denmark" id="1001"/> - ]]> +]]>

With strict actions enabled, conflict data will cause the create action to fail when existing data is on the recipient node. Here we show iq:private, and strict actions with existing data on the server.

- ]]> +]]> @@ -194,7 +194,7 @@ RECIPIENT: - ]]> +]]>

With strict actions enabled, the absence of matching data will cause the read action to fail. Here we show iq:private, and strict actions with no matching data on the server.

- ]]> +]]>

With strict actions disabled, the absence of matching data will cause the read action to return an 'empty' result. Here we show iq:private, and strict actions disabled with no matching data on the server.

@@ -236,7 +236,7 @@ RECIPIENT: - ]]> +]]> @@ -275,7 +275,7 @@ RECIPIENT: from="hamlet@shakespeare.lit/denmark" to="hamlet@shakespeare.lit/denmark" id="1001"/> - ]]> +]]>

With strict actions enabled, the absence of existing data will cause the update action to fail. Here we show iq:private, and strict actions with no existing data on the server.

- ]]> +]]> @@ -337,7 +337,7 @@ RECIPIENT: from="hamlet@shakespeare.lit/denmark" to="hamlet@shakespeare.lit/denmark" id="1001"/> - ]]> +]]>

With strict actions enabled, the absence of existing data will cause the delete action to fail. Here we show iq:private, and strict actions with no existing data on the server.

- ]]> +]]>

With strict actions disabled, the absence of existing data will not cause the delete action to fail. Here we show iq:private, and strict actions with no existing data on the server.

- ]]> +]]> diff --git a/xep-0100.xml b/xep-0100.xml index 65dfc5e4..d7977db1 100644 --- a/xep-0100.xml +++ b/xep-0100.xml @@ -158,7 +158,7 @@ id='disco1'> - ]]> +]]> - ]]> +]]>

Note: Although many existing gateway implementations support only the older Agent Information protocol, it is RECOMMENDED that gateways support the Service Discovery protocol, since the former protocol is deprecated in favor of the latter. Until existing gateways are upgraded, clients SHOULD support both.

  • @@ -186,7 +186,7 @@ - ]]> +]]> - ]]> +]]>

    Note: Given the foregoing, a client can determine the identity of the gateway, specifically (1) that it is a gateway and (2) to which legacy service it provides a gateway.

  • @@ -213,7 +213,7 @@ id='reg1'> - ]]> +]]>

  • Gateway returns IQ-result to Jabber User, specifying information that is required in order to register.

    @@ -230,7 +230,7 @@ - ]]> +]]>

  • Jabber User sends IQ-set qualified by the 'jabber:iq:register' namespace to Gateway, containing information required to register.

    @@ -244,7 +244,7 @@ ILoveJuliet - ]]> +]]>

    Note: The XML character data of the <username/> element SHOULD be the Jabber User's LegacyUserAddress as described under Addressing, such as an AOL screen name, ICQ number, Windows Live Messenger (formerly MSN Messenger) address, or Yahoo! ID.

  • @@ -254,7 +254,7 @@ from='aim.shakespeare.lit' to='romeo@montague.lit/orchard' id='reg2'/> - ]]> +]]>

  • If Gateway logged into Legacy Service in preceding step, Gateway buffers any translatable events (e.g., messages and presence) queued up for Jabber User on Legacy Service.

  • @@ -267,12 +267,12 @@ - ]]> +]]> - ]]> +]]>

  • Gateway sends subscription request to Jabber User (i.e., by sending a presence stanza of type "subscribe" to Jabber User's bare JID).

    @@ -280,7 +280,7 @@ - ]]> +]]>

  • Jabber User's client SHOULD approve the subscription request (i.e., by sending a presence stanza of type "subscribed" to Gateway).

    @@ -288,7 +288,7 @@ - ]]> +]]>

    Note: As specified in RFC 6121, Jabber User's server will generate a "roster push" at this point if client did not previously perform a roster set to add Gateway to user's roster (as mentioned above).

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

  • Gateway sends approves subscription request (i.e., by sending a presence stanza of type "subscribed" to Jabber User's bare JID).

    @@ -305,7 +305,7 @@ - ]]> +]]>

  • Execute "Log In" use case.

  • Gateway sends any buffered messages to Jabber User.

    • @@ -332,7 +332,7 @@ xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> - ]]> +]]>

  • Use Case Ends unsuccessfully.

    • @@ -353,7 +353,7 @@ id='edit1'> - ]]> +]]>

  • Gateway returns IQ-result to Jabber User, specifying registration information on record and including empty <registered/> element to signify that user is already registered. The fact that the Gateway can determine the Jabber User's legacy username based on the JID of the 'from' address indicates that the client proxy model assumes one registration per Jabber User.

    @@ -368,7 +368,7 @@ ILoveJuliet - ]]> +]]>

  • Jabber User sends IQ-set qualified by the 'jabber:iq:register' namespace to Gateway, containing all information (i.e., not just the "delta").

    @@ -382,7 +382,7 @@ B4lc0ny - ]]> +]]>

  • Gateway verifies that, if changed, information provided by Jabber User is still valid (using whatever means appropriate for the Legacy Service) and informs Jabber User of success [A1].

    @@ -391,7 +391,7 @@ from='aim.shakespeare.lit' to='romeo@montague.lit/orchard' id='edit2'/> - ]]> +]]>
    • @@ -415,7 +415,7 @@ xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> - ]]> +]]>

  • Use Case Ends unsuccessfully.

    • @@ -438,7 +438,7 @@     - ]]> +]]>

  • Gateway sends unavailable presence from Jabber User to Legacy Users and logs Jabber User out of Legacy Service.

  • Gateway deletes Jabber User's information.

    • @@ -449,7 +449,7 @@ from='aim.shakespeare.lit' to='romeo@montague.lit/orchard' id='unreg1'/> - ]]> +]]>

  • Gateway cancels subscriptions.

    @@ -461,7 +461,7 @@ - ]]> +]]>

  • Gateway sends unavailable presence to Jabber User.

    @@ -469,7 +469,7 @@ - ]]> +]]>

  • Jabber User's client SHOULD delete from the user's roster (1) the gateway itself, and (2) all legacy Contacts associated with the gateway.

  • Use Case Ends.

    • @@ -487,14 +487,14 @@

    Jabber User sends available presence broadcast to Server or sends directed presence to Gateway or a Legacy User.

    - ]]> +]]> ... - ]]> +]]>

  • Upon receiving the first presence notification stanza from Jabber User to Gateway or Legacy User, Gateway logs Jabber User into Legacy Service [A1].

  • @@ -502,7 +502,7 @@ - ]]> +]]>

  • Optionally, Gateway handles Legacy Service contact list; see the Contact Lists section of this document.

  • @@ -512,7 +512,7 @@ to='romeo@montague.lit'> away - ]]> +]]>

    Note: If the Legacy Service to which the Gateway connects does not support the concept of "resources", the 'from' address of presence notification stanzas generated by a gateway SHOULD NOT include a resource identifier (i.e., they SHOULD be of the form <user@host> rather than <user@host/resource>). However, the 'from' address MAY include a resource if the Gateway determines that this is appropriate in the context of its communications with the Legacy Service.

  • @@ -523,7 +523,7 @@ dnd Wooing Juliet - ]]> +]]>

  • Use Case Ends.

    • @@ -543,7 +543,7 @@ xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> - ]]> +]]>

  • Use Case Ends unsuccessfully.

    • @@ -559,12 +559,12 @@

    Jabber User sends unavailable presence broadcast to Server or sends directed presence stanza of type "unavailable" to Gateway or (if Gateway does not support directed presence) Legacy User.

    - ]]> +]]> - ]]> +]]>

  • Gateway transforms unavailable presence stanzas received from the Jabber User's server and routes them to all of the Jabber User's contacts on Legacy Service.

  • Gateway logs Jabber User out of Legacy Service [A1].

    • @@ -574,7 +574,7 @@ - ]]> +]]>

  • Use Case Ends.

    • @@ -589,7 +589,7 @@ - ]]> +]]>

  • Use Case Ends.

    • @@ -607,7 +607,7 @@ - ]]> +]]>

    Note: As specified in RFC 6121, sending this packet will result in a "roster push" from the Server to all of the Jabber User's available resources.

  • Gateway transforms subscription request and routes it to Legacy User.

    • @@ -617,14 +617,14 @@ - ]]> +]]>

  • Gateway sends available presence stanza to Jabber User on behalf of Legacy User.

    - ]]> +]]>

  • Gateway sends presence stanza of type "subscribe" to Jabber User on behalf of Legacy User.

    @@ -632,7 +632,7 @@ - ]]> +]]>

  • Jabber User sends presence stanza of type "subscribed" to Legacy User.

    @@ -640,7 +640,7 @@ - ]]> +]]>

  • Use Case Ends.

    • @@ -656,7 +656,7 @@ - ]]> +]]>

  • Use Case Ends unsuccessfully.

    • @@ -679,7 +679,7 @@ subscription='remove'/>     - ]]> +]]>

  • Server sends normal "roster push" to Jabber User (see RFC 6121) and sends presence stanzas of type "unsubscribe", "unsubscribed", and "unavailable" to Legacy User.

    @@ -695,7 +695,7 @@ - ]]> +]]>

  • Gateway cleans up subscription state, informs Legacy User that Jabber User is unavailable, and MUST NOT send future changes in Jabber User's presence to Legacy User.

  • Use Case Ends.

    • @@ -717,7 +717,7 @@ type='chat'> Neither, fair saint, if either thee dislike. - ]]> +]]>

  • Gateway transforms message to legacy protocol and sends to Legacy User [A1].

  • Use Case Ends.

    • @@ -752,7 +752,7 @@ - ]]> +]]>

  • Jabber User approves subscription request by sending presence stanza of type "subscribed" to Legacy User [A1].

    @@ -760,7 +760,7 @@ - ]]> +]]>

  • Gateway sends Jabber User's presence information to Legacy User.

  • @@ -769,7 +769,7 @@ - ]]> +]]>

  • Gateway sends presence stanza of type "subscribed" to Jabber User on behalf of Legacy User.

    @@ -777,14 +777,14 @@ - ]]> +]]>

  • Gateway sends Legacy User's presence information to Jabber User.

    - ]]> +]]>

  • Use Case Ends.

    • @@ -799,7 +799,7 @@ - ]]> +]]>

  • Gateway cleans up subscription state and MUST NOT send Jabber User's presence to Legacy User.

  • Use Case Ends unsuccessfully.

    • @@ -827,7 +827,7 @@ - ]]> +]]>

  • Jabber User's server performs defined functionality for handling presence stanzas of type "unsubscribe" and "unsubscribed" (see RFC 6121).

  • Use Case Ends.

    • @@ -849,7 +849,7 @@ to='romeo@montague.lit'> Art thou not Romeo, and a Montague? - ]]> +]]>

    Note: If the Legacy Service to which the Gateway connects does not support a concept equivalent to that of Jabber "resources" as described in &rfc6120;, the 'from' address of message stanzas generated by a gateway SHOULD NOT include a resource identifier (i.e., they SHOULD be of the form <user@host> rather than <user@host/resource>). However, the 'from' address MAY include a resource if the Gateway determines that this is appropriate in the context of its communications with the Legacy Service.

  • Jabber User's Server delivers message or (optionally) stores it for later retrieval.

    • @@ -886,7 +886,7 @@ - ]]> +]]> @@ -897,7 +897,7 @@ Contact ID - ]]> +]]>

    The following table is intended to assist implementors with mapping of gateway identities to English-language prompt names and text.

    @@ -939,14 +939,14 @@ Foo Bar - ]]> +]]> FooBar@aim.jabber.org - ]]> +]]> @@ -1021,6 +1021,6 @@ - ]]> +]]> diff --git a/xep-0103.xml b/xep-0103.xml index 227c8a9e..999ebeca 100644 --- a/xep-0103.xml +++ b/xep-0103.xml @@ -75,7 +75,7 @@ xmlns='http://jabber.org/protocol/url-data' target='http://festhall.outer-planes.net/d20M/announce/latest/'/> - ]]> +]]>

    If more information is necessary for successfully using the URL, the sender includes meta-information in a scheme-specific format such as that defined in &xep0104;:

    jsessionid=1324123wdwfq341w1243asdf' - ]]> +]]>

    The above example illustrates supplying a HTTP URL with a cookie header. Additional information could be provided, such as HTTP authentication requirements or even POST data.

    To support the use of bulk publishing methods such as &xep0060; or messages of type "headline", the <desc/> element is used to provide a textual description:

    Greyhawk in 3rd Edition - ]]> +]]>

    To use "url-data" in conjunction with SI, the "sid" attribute of <url-data/> is used. This attribute MUST be equal to the SI session id.

    @@ -156,7 +156,7 @@ - ]]> +]]>

    The receiver then accepts the request, specifying "url-data" as the stream method:

    @@ -170,7 +170,7 @@ - ]]> +]]>

    The sender then sends an &IQ; with type "set" to the receiver, providing the <url-data/> element with the URL in the "target" attribute:

    @@ -178,7 +178,7 @@ sid='a0' target='http://pass.jabber.org:8519/test.txt'/> - ]]> +]]>

    The receiver attempts to retrieve the data from the given URL. The receiver MUST NOT respond to the &IQ; until the data is completely retrieved, or an error occurs. If the retrieval is successful, the receiver responds with an "iq-result":

    @@ -186,7 +186,7 @@ sid='a0' target='http://pass.jabber.org:8519/test.txt'/> - ]]> +]]>

    Including the <url-data/> element in the result is NOT REQUIRED.

    If the receiver does not understand or support the URL, it responds with an "iq-error" with the <malformed-url/> condition:

    - ]]> +]]>

    If the receiver fails to retrieve data from the URL, it responds with an "iq-error" with the <transfer-failed/> condition:

    @@ -211,7 +211,7 @@ - ]]> +]]>

    If the receiver refuses to accept the URL, it responds with an "iq-error" with the <transfer-refused/> condition:

    @@ -223,7 +223,7 @@ - ]]> +]]>     @@ -320,7 +320,7 @@ - ]]> +]]> diff --git a/xep-0104.xml b/xep-0104.xml index e13b1474..5b3f3a28 100644 --- a/xep-0104.xml +++ b/xep-0104.xml @@ -73,7 +73,7 @@ - ]]> +]]>

    To provide additional parameters (such as a realm and username/password), the <auth-param/> element is used:

    @@ -87,7 +87,7 @@     - ]]> +]]>

    Cookie information is provided by the <cookie/> element. This element can provide all of the information of the "Set-Cookie" response header"Set-Cookie" is a message header for the HTTP response, and the <header/> element represents only message headers for HTTP requests. Therefore, cookies are handled differently.. The simplest usage is:

    @@ -99,7 +99,7 @@ - ]]> +]]>

    The above cookie is considered "transient", and will terminate when the HTTP session ends. Additional information about the cookie can be provided:

    @@ -116,7 +116,7 @@ value='1243asd234190sa32ds'/> - ]]> +]]>

    As demonstrated, the <cookie/> provides all the attributes provided by the "Set-Cookie" header. The only attributes required are "name" and "value".

     @@ -129,7 +129,7 @@ - ]]> +]]>     @@ -222,7 +222,7 @@ - ]]> +]]> diff --git a/xep-0105.xml b/xep-0105.xml index 2d9032a7..2b29e29c 100644 --- a/xep-0105.xml +++ b/xep-0105.xml @@ -116,7 +116,7 @@ - ]]> +]]> @@ -129,7 +129,7 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]>

    Above is repeated for ft2, ft3, etc...

     @@ -194,6 +194,6 @@ - ]]> +]]> diff --git a/xep-0107.xml b/xep-0107.xml index 711384bf..c8727c67 100644 --- a/xep-0107.xml +++ b/xep-0107.xml @@ -91,7 +91,7 @@ Yay, the mood spec has been approved! - ]]> +]]>

    In addition, an application MAY provide a more specific mood value as a properly-namespaced child of the defined element, which extension MUST be ignored if the receiving application does not understand the extended namespace. Here is an example:

    @@ -100,7 +100,7 @@     Yay, the mood spec has been approved! - ]]> +]]>

    Mood information SHOULD be communicated and transported by means of the &xep0060; subset specified in &xep0163;. Because mood information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.

    @@ -119,7 +119,7 @@ - ]]> +]]>

    The mood is then delivered to all subscribers:

    - ]]> +]]>

    In order to indicate that the user is no longer publishing moods, the user's client shall send an empty <mood/> element, which can be considered a "stop command" for user moods:

    - ]]> +]]> - ]]> +]]>

    A user MAY provide a mood extension in a specific IM message in order to lend a defined emotional tone to text of that particular message. (This does not override the user's more general mood and is not intended to replace PEP as a more general transport method for user moods.)

    @@ -176,7 +176,7 @@ - ]]> +]]>     @@ -407,6 +407,6 @@ - ]]> +]]> diff --git a/xep-0108.xml b/xep-0108.xml index a70a777f..ac9f22f2 100644 --- a/xep-0108.xml +++ b/xep-0108.xml @@ -87,7 +87,7 @@ My nurse's birthday! - ]]> +]]>

    Instead of (but not in addition to) one of the specific activity elements defined herein, an application MAY include a properly-namespaced child element for the specific activity. Here is an example:

    @@ -95,7 +95,7 @@ - ]]> +]]>

    Finally, one of the specific activity elements defined herein MAY itself contain a properly-namespaced child element that provides more detailed information about the specific activity. Here is an example:

    @@ -105,7 +105,7 @@ - ]]> +]]>

    In accordance with &xmppcore;, the receiving application MUST ignore a specific activity element or detailed activity element if it does not understand the namespace that qualifies the element.

    @@ -127,7 +127,7 @@ - ]]> +]]>

    The activity is then delivered to all subscribers:

    - ]]> +]]>

    In order to indicate that the user is no longer publishing activities, the user's client shall send an empty <activity/> element, which can be considered a "stop command" for user activities:

    - ]]> +]]> - ]]> +]]>     @@ -512,6 +512,6 @@ - ]]> +]]> diff --git a/xep-0109.xml b/xep-0109.xml index 64cf9c31..beafdb25 100644 --- a/xep-0109.xml +++ b/xep-0109.xml @@ -128,7 +128,7 @@ - ]]> +]]> - ]]> +]]>

    The <start/> and <end/> elements define the times between which this vacation message should be considered valid by a supporting client; the times are in @@ -162,7 +162,7 @@ - ]]> +]]> @@ -190,7 +190,7 @@ - ]]> +]]> - ]]> +]]>

    The meaning of each element is as outlined above. All elements are required.

    @@ -260,14 +260,14 @@ - ]]> +]]> - ]]> +]]>

    TODO: Is the Delete And Notify functionality described in XEP-0060 7.2.2.1 widely implemented? If so, should that case be included here?

    @@ -340,7 +340,7 @@ - ]]> +]]> diff --git a/xep-0110.xml b/xep-0110.xml index e5bc986f..1df90090 100644 --- a/xep-0110.xml +++ b/xep-0110.xml @@ -72,7 +72,7 @@ ortho_0.gif - map for map1.ygf - ]]> +]]>

    Each map consists of one or more layers. The main purpose of layers is to combine maps and views to deliver information suitable for a particular context, and to offer greater flexibility to the user in respect to customization.

    Layers can be defined either inline or by a reference to another map. Each layer has a specified position in the map, a scale and a priority. The maps defined inline contain also projection, underlying image and a list of entities lying inside it (i.e. typically JIDs or clusters of JIDs). The underlying images are sent out of band using the jabber:x:oob namespace or possibly defined in some other way (e.g. xml-based SVG).

    The map in Example 1 uses an implicit map projection assuming that attributes x and y are directly the co-ordinates of a particular entity (e.g. buddy1@jabber.org) in the image (ortho_0.gif) expressed in pixels.

    @@ -88,7 +88,7 @@ - ]]> +]]>

    As can be seen in Example 2, the projection can be specified using any parameters either explicitly set in the item tags or obtained for the particular JID from some other source (e.g. JUD or LDAP).

    @@ -104,7 +104,7 @@ - ]]> +]]> diff --git a/xep-0111.xml b/xep-0111.xml index 8e468d37..77ae42a2 100644 --- a/xep-0111.xml +++ b/xep-0111.xml @@ -143,7 +143,7 @@
    - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]>

    More examples to follow.

    @@ -313,7 +313,7 @@ - ]]> +]]> - ]]> +]]> diff --git a/xep-0112.xml b/xep-0112.xml index a6a0c303..30006149 100644 --- a/xep-0112.xml +++ b/xep-0112.xml @@ -119,7 +119,7 @@ - ]]> +]]>

    The location information is then delivered to all subscribers:

    +]]>

    As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:

    - ]]> +]]>

    There are many XML data formats for physical location or address information. It is beyond the scope of this document to provide a mapping from the extension defined herein to every such format. However, it would be valuable to provide a mapping from the Jabber/XMPP format to the formats used in other presence or extended presence protocols. The two main protocols of interest are:

    @@ -307,6 +307,6 @@ - ]]> +]]>     diff --git a/xep-0113.xml b/xep-0113.xml index 944e3a5b..abcdccbd 100644 --- a/xep-0113.xml +++ b/xep-0113.xml @@ -79,7 +79,7 @@ - ]]> +]]>

    The path node is a simplified SVG path node that allows only 'M', 'm', 'L' and 'l' commands. 'M' ('m') command is a (relative) moveto command, 'L' ('l') is a (relative) lineto command. All four commands take one or more coordinate pairs (in pixels). 'M' sets the current point to the coordinate pair. 'm' adds the coordinate pair to the current point. 'L' draws a line from the current point to the point designated by the coordinate pair and sets the current point to the coordinate pair. 'l' draws a line from the current point to the sum of the currentpoint and the coordinate pair and adds the coordinate pair to the current point. The optional stroke attribute indicates the color of the path and defaults to black, the optional stroke-width indicates the width of the path in pixels and defaults to 1. The id attribute can be used for later reference to the path. If there is no id attribute, the path can not be referred to.

    The path in example 1, draws a red triangle with vertices (100,100), (300,100) and (200, 300)

    Other respresentations of the same path are 'M100.0,100.0L300.0,100.0,200.0,300.0,100.0,100.0', 'M100,100l200,0-100,200-100-200' and 'M100,100l200,0L200,300,100,100'. Note that in the second representation some commas can be left out because the sign indicates that a new coordinate is starting. This fact can be used to reduce data size as much as possible to avoid karma problems. A precise grammar of the "d" attribute is given below.

    @@ -98,7 +98,7 @@ - ]]> +]]>

    In this case the dialog will not close. At the destination client a similar dialog will pop up, allowing the user at the other end to add her own part of the drawing. The resulting message will look like this (line breaks provided for readability only):

    - ]]> +]]>

    It is left as a mental exercise to the reader to imagine Laertes answer. Alternatively the reader could build this protocol into her favorite Jabber client, set a breakpoint, and paste the path above at the appropriate place.

    Alternatively Laertes could respond like:

    - ]]> +]]>

    This would move the King's triangle 100 pixels to the left and top, to the upper left corner of the screen.

    If Laertes were bold enough he might even answer:

    - ]]> +]]>

    This would remove King Claudius's triangle from the screen.

    @@ -172,7 +172,7 @@ - ]]> +]]> @@ -209,7 +209,7 @@ currentPathSet.back ().push_back (myPoint); // pen is down add a new point to the latest path } } - ]]> +]]>

    The string 'Jabber' would be encoded as the path 'M24 59l0,16-1,3-1,1-2,1-2,0-2-1-1-1-1-3 0-2M43 66l0,14M43 69l-2-2-2-1-3,0-2,1-2,2-1,3 0,2 1,3 2,2 2,1 3,0 2-1 2-2M51 59l0,21M51 69l2-2 2-1 3,0 2,1 2,2 1,3 0,2-1,3-2,2-2,1-3,0-2-1-2-2M70 59l0,21M70 69l2-2 2-1 3,0 2,1 2,2 1,3 0,2-1,3-2,2-2,1-3,0-2-1-2-2M88 72l12,0 0-2-1-2-1-1-2-1-3,0-2,1-2,2-1,3 0,2 1,3 2,2 2,1 3,0 2-1 2-2M107 66l0,14M107 72l1-3 2-2 2-1 3,0', which is 357 characters long. That is no more than twice the size of a typical groupchat text message.

    @@ -268,7 +268,7 @@ - ]]> +]]> - ]]> +]]>

    The grammar of the "d" attribute below is a slight simplification of section 8.3.9 in Scalable Vector Graphics (SVG) 1.0 Specification, section 8.3.1.: The grammar for path data http://www.w3.org/TR/SVG/paths.html#PathDataBNF.

    @@ -371,7 +371,7 @@ wsp: (#x20 | #x9 | #xD | #xA) - ]]> +]]>     diff --git a/xep-0114.xml b/xep-0114.xml index 25158498..155cb359 100644 --- a/xep-0114.xml +++ b/xep-0114.xml @@ -91,7 +91,7 @@ xmlns='jabber:component:accept' xmlns:stream='http://etherx.jabber.org/streams' to='plays.shakespeare.lit'> - ]]> +]]>

    Note: In the 'jabber:component:accept' namespace, the value of the 'to' address is the component name, not the server name; In the 'jabber:component:connect' namespace, the server would set the 'from' attribute to the component name. this enables the server to determine whether it will service a component of that name (e.g., based on server configuration or some other implementation-specific mechanism). If so, the server MUST reply with a stream header.

    - ]]> +]]>

    If the server will not service the component name specified in the 'to' attribute of the stream header, it MUST return a stream error (e.g., <conflict/> or <host-unknown/>). If the server does not recognize or support the namespace specified in the stream header (e.g., it does not support streams qualified by the 'jabber:component:accept' namespace), it MUST return an <invalid-namespace/> stream error. For all errors related to the stream header, the server MUST follow the rules in Section 4.7.1 of XMPP Core by returning an opening stream tag, stream error element, and closing stream tag rather than merely a stream error element (refer to RFC 3920 for details).

    After receiving the stream header reply from the server, the component MUST send a <handshake/> element with appropriate contents. The handshake value is always supplied by the initiator. Thus for jabber:component:accept connections, the handshake value is provided by the component, whereas for jabber:component:connect connections, the handshake value is provided by the server.

    aaee83c26aeeafcbabeabfcbcd50df997e0a2a1e - ]]> +]]>

    The XML character data of the handshake element is computed according to the following algorithm:

    1. Concatenate the Stream ID received from the server with the shared secret.
      2. @@ -116,7 +116,7 @@

      If the credentials are acceptable, the receiving application (in this case the server) MUST return an empty <handshake/> element.

      - ]]> +]]>

      Once authenticated, the component can send stanzas through the server and receive stanzas from the server. All stanzas sent to the server MUST possess a 'from' attribute and a 'to' attribute, as in the 'jabber:server' namespace. The domain identifier portion of the JID contained in the 'from' attribute MUST match the hostname of the component. However, this is the only restriction on 'from' addresses, and the component MAY send stanzas from any user at its hostname.

      @@ -335,7 +335,7 @@ - ]]> +]]> - ]]> +]]> diff --git a/xep-0115.xml b/xep-0115.xml index 86419945..e54a3bd8 100644 --- a/xep-0115.xml +++ b/xep-0115.xml @@ -155,7 +155,7 @@ node='http://code.google.com/p/exodus' ver='QgayPKawpkPSDYmwT/WM94uAlu0='/> - ]]> +]]>

      The 'node' attribute represents the client software Romeo is using. The 'ver' attribute is a specially-constructed string (called a "verification string") that represents the entity's service discovery identity (category and type as registered at &DISCOCATEGORIES;, as well as, optionally, xml:lang and name) and supported features (as registered at &DISCOFEATURES; as well as, optionally, extended service discovery information data registered at &FORMTYPES;).

      At this point, your client has no idea what the capabilities are of someone with a verification string 'QgayPKawpkPSDYmwT/WM94uAlu0='. Your client therefore sends a service discovery query to Romeo, asking what his client can do.

      - ]]> +]]>

      The response is:

      - ]]> +]]>

      At this point, your client knows that a contact who advertises a verification string of 'QgayPKawpkPSDYmwT/WM94uAlu0=' supports &xep0045; and the other features returned by Romeo because the contact in fact uses the same version of the same client software as Romeo, with the same enabled features, plugins, presented client name(s), and the like (i.e., the same input to the verification string generation method). The string can be relied upon because of how it is generated and checked, as explained later in this document. Your client remembers this information, so that it does not need to explicitly query the capabilities of a contact with the same verification string. For example, your Nurse may use the same client that Romeo does:

      @@ -191,7 +191,7 @@ node='http://code.google.com/p/exodus' ver='QgayPKawpkPSDYmwT/WM94uAlu0='/> - ]]> +]]>

      Therefore you know that she also supports the same features that Romeo does.

      On the other hand, for a person with the following presence ...

      - ]]> +]]>

      ... or the following presence ...

      @@ -210,7 +210,7 @@ node='http://www.chatopus.com' ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/> - ]]> +]]>

      ... you have no information about what this contact's client is capable of unless you have cached previous entity capabilities information; therefore you need to query for capabilities explicitly again via service discovery.

      @@ -444,7 +444,7 @@ node='http://code.google.com/p/exodus' ver='QgayPKawpkPSDYmwT/WM94uAlu0='/> - ]]> +]]>

      If the supported features change during a generating entity's presence session (e.g., a user installs an updated version of a client plugin), the application MUST recompute the verification string and SHOULD send a new presence broadcast.

      @@ -453,7 +453,7 @@ node='http://code.google.com/p/exodus' ver='66/0NaeaBKkwk85efJTGmU47vXI='/> - ]]> +]]> @@ -467,7 +467,7 @@ - ]]> +]]>

      The disco#info request is sent by the requesting entity to the generating entity. The value of the 'to' attribute MUST be the exact JID of the generating entity, which in the case of a client will be the full JID &LOCALFULL;.

      Note: The generating entity SHOULD NOT include the "caps node" in the list of entities it returns in its disco#items responses; i.e., the caps node is a kind of virtual or phantom node, not a true items node that is associated with the generating entity for service discovery purposes.

      @@ -488,7 +488,7 @@       - ]]> +]]>

      Note: If the generating entity incorporated multiple identities with different xml:lang values in its verification string, it MUST return all of the identities even if the request specified a particular xml:lang.

      @@ -503,7 +503,7 @@ node='http://jabberd.org' ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/> - ]]> +]]>

      When a connected client or peer server sends a service discovery information request to determine the entity capabilities of a server that advertises capabilities via the stream feature, the requesting entity MUST send the disco#info request to the server's JID as provided in the 'from' attribute of the response stream header (the 'from' attribute was recommended by &rfc3920; and is required by &rfc6120;). To enable this functionality, a server that advertises support for entity capabilities MUST provide a 'from' address in its response stream headers, in accordance with RFC 6120.

       @@ -517,7 +517,7 @@ type='get'> - ]]> +]]> - ]]> +]]>

      If a server supports the Caps Optimization functionality, it MUST also return a feature of 'http://jabber.org/protocol/caps#optimize' in response to service discovery information requests.

      - ]]> +]]> - ]]> +]]> diff --git a/xep-0116.xml b/xep-0116.xml index c9cf0836..aec0c2d2 100644 --- a/xep-0116.xml +++ b/xep-0116.xml @@ -161,7 +161,7 @@ id='disco1'> - ]]> +]]>

      If Bob sends a disco#info reply and he supports the protocol defined herein, then he MUST include a service discovery feature variable of "http://www.xmpp.org/extensions/xep-0116.html#ns" &NSNOTE;.

      - ]]> +]]>       @@ -308,7 +308,7 @@ - ]]> +]]>

      The first message of a 3-message negotiation is identical except there MUST be no 'sas_algs' field and a 'dhkeys' field MUST be included instead of the 'dhhashes' field:

      @@ -335,7 +335,7 @@ - ]]> +]]> @@ -356,7 +356,7 @@ - ]]> +]]>

      If Bob supports none of the options for one or more ESession fields, then he SHOULD return a ¬acceptable; error specifying the field(s) with unsupported options:

      - ]]> +]]>

      Either Bob or Alice MAY attempt to initiate a new ESession after any error during the negotiation process. However, both MUST consider the previous negotiation to have failed and MUST discard any information learned through the previous negotiation.

      If Bob is unwilling to start an ESession, but he is ready to initiate a one-to-one stanza session with Alice (see Stanza Session Negotiation), and if Alice included an option for the "security" field with the value "none" or "c2s", then Bob SHOULD accept the stanza session and terminate the ESession negotiation by specifying "none" or "c2s" for the value of the "security" field in his response.

      - ]]> +]]>       @@ -456,7 +456,7 @@ - ]]> +]]> @@ -532,7 +532,7 @@ - ]]> +]]> @@ -602,7 +602,7 @@ ** Base64 encoded a_mac ** - ]]> +]]>

      Note: If Alice also includes a 'terminate' field with its value set to "1" or "true" (see ESession Termination) within the form then the ESession is terminated immediately. Note: This special case, where a single stanza is encrypted and sent in isolation, is equivalent to object encryption (or object signing if no encryption is specified) and offers several significant advantages over non-session approaches - including perfect forward secrecy.

      In the case of a 4-message negotiation Alice MUST also include in the data form her Base64 encoded values of e (wrapped in a 'dhkeys' field) and the Base64 encoded HMAC (using HASH and the key &NsubA; The HMACs of the retained secrets are generated using Alice's unique session nonce to prevent her being identified by her retained secrets (only one secret changes each session, and some might not change very often).) of each secret that Alice has retained from her previous session with each of Bob's clients (wrapped in a 'rshashes' field) - see Sending Bob's Identity. Note: Alice MUST also append a few random numbers to the 'rshashes' field to make it difficult for an active attacker to discover if she has communicated with Bob before or how many clients Bob has used to communicate with her.

      - ]]> +]]> @@ -684,7 +684,7 @@ - ]]> +]]>

      Finally, Bob MUST destroy all his copies of the old retained secret (SRS) he was keeping for Alice's client, and calculate a new retained secret for this session:

      HMAC(HASH, K, "New Retained Secret")

      Bob MUST securely store the new value along with the retained secrets his client shares with Alice's other clients.

      @@ -722,7 +722,7 @@ ** Base64 encoded a_mac ** - ]]> +]]>

      When Bob receives a termination stanza he MUST verify the MAC (to be sure he received all the stanzas Alice sent him during the ESession) and immediately send an encrypted termination acknowledgement form (as specified in the Termination section of Stanza Session Negotiation) back to Alice. Note: He MAY publish any old values of &KMsubA; or &KMsubB; within the acknowledgement stanza. He MUST then securely destroy all keys associated with the ESession.

      @@ -733,7 +733,7 @@ ** Base64 encoded b_mac ** - ]]> +]]>

      When Alice receives the stanza she MUST verify the MAC to be sure she received all the stanzas Bob sent her during the ESession. Once an entity has sent a termination or termination acknowledgement stanza it MUST NOT send another stanza within the ESession.

       @@ -1011,7 +1011,7 @@ XEP-0155 ... - ]]> +]]> diff --git a/xep-0118.xml b/xep-0118.xml index 8f69bbf7..023686f3 100644 --- a/xep-0118.xml +++ b/xep-0118.xml @@ -183,7 +183,7 @@ - ]]> +]]>

      The tune information is then delivered to all subscribers:

      - ]]> +]]>

      In order to indicate that the user is no longer listening to any tunes (or has simply disabled publication), the user's client shall send an empty <tune/> element, which can be considered a "stop command" for user tunes:

      - ]]> +]]> - ]]> +]]> @@ -289,6 +289,6 @@ - ]]> +]]> diff --git a/xep-0120.xml b/xep-0120.xml index e92a95d9..6467bb5d 100644 --- a/xep-0120.xml +++ b/xep-0120.xml @@ -86,7 +86,7 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]>

      This set of examples is borrowed from &xep0118;.

      @@ -195,7 +195,7 @@ - ]]> +]]> - ]]> +]]>       @@ -253,7 +253,7 @@ second value - ]]> +]]> @@ -296,7 +296,7 @@ - ]]> +]]>

      Before defining a new protocol for metadata, the primary author of this proposal investigated several promising technologies that could be used to meet the above requirements -- in particular, the Friend of a Friend (FOAF) vocabulary, which is a subset of the Resource Description Framework (RDF). Ultimately, the primary author concluded that, while FOAF and RDF have many merits, they are not ideal for use on the Jabber network. In particular:

      diff --git a/xep-0121.xml b/xep-0121.xml index cc23b4e7..045fae2d 100644 --- a/xep-0121.xml +++ b/xep-0121.xml @@ -87,7 +87,7 @@ - ]]> +]]>

      The following is an example of metadata for a conference room.

       - ]]> +]]>

      This document introduces no security considerations above and beyond those already defined in XEP-0120.

      @@ -191,6 +191,6 @@ - ]]> +]]>       diff --git a/xep-0122.xml b/xep-0122.xml index dd04da69..60b1f94d 100644 --- a/xep-0122.xml +++ b/xep-0122.xml @@ -104,7 +104,7 @@ datatype='xs:dateTime'/> 2003-10-06T11:22:00-07:00 - ]]> +]]>

      The preceding example demonstrates a field that is expected to contain a date/time value.

      The 'datatype' attribute specifies the datatype. This attribute is OPTIONAL, and defaults to "xs:string". It MUST meet one of the following conditions:

        @@ -133,7 +133,7 @@ 2003-10-06T11:22:00-07:00 - ]]> +]]>

        Using <basic/> validation, the form interpreter MUST follow the validation rules of the datatype (if understood) and the field type.

        The <basic/> element MUST be empty (i.e., not contain any character data or child elements) and MUST NOT possess any attributes.

        @@ -151,7 +151,7 @@ - ]]> +]]>

        The <open/> validation method applies to "text-multi" differently; it hints that each value for a "text-multi" field shall be validated separately. This effectively turns "text-multi" fields into an open-ended "list-multi", with no options and all values automatically selected.

        The <open/> element MUST be empty (i.e., not contain any character data or child elements) and MUST NOT possess any attributes.

        @@ -166,7 +166,7 @@ 2003-10-06T11:22:00-07:00 - ]]> +]]>

        The 'min' and 'max' attributes of the <range/> element specify the minimum and maximum values allowed, respectively.

        The 'max' attribute specifies the maximum allowable value. This attribute is OPTIONAL. The value depends on the datatype in use.

        The 'min' attribute specifies the minimum allowable value. This attribute is OPTIONAL. The value depends on the datatype in use.

        @@ -183,7 +183,7 @@ ([0-9]{3})-([0-9]{2})-([0-9]{4}) - ]]> +]]>

        The XML character data of this element is the pattern to apply. The syntax of this content MUST be that defined for POSIX extended regular expressionsThe "best" definition of this syntax can be found in the re_format(7) man page, including support for UnicodeGuidelines for adapting regular expressions to support Unicode is defined at http://www.unicode.org/reports/tr18/.

        The <regex/> element MUST contain character data only (i.e., not contain any child elements) and MUST NOT possess any attributes.

        @@ -205,7 +205,7 @@ - ]]> +]]>

        The <list-range/> element SHOULD be included only when the <field/> is of type "list-multi" and SHOULD be ignored otherwise.

        The 'max' attribute specifies the maximum allowable number of selected/entered values. This attribute is OPTIONAL. The value MUST be a positive integer.

        The 'min' attribute specifies the minimum allowable number of selected/entered values. This attribute is OPTIONAL. The value MUST be a positive integer.

        @@ -244,7 +244,7 @@ - ]]> +]]>

        This document relies on the internationalization/localization mechanisms provided by &xmppcore;. As much as possible, all datatype formats MUST be locale-independent.

        @@ -352,7 +352,7 @@ a natural-language description of the datatype family the document in which datatype family is specified - ]]> +]]>

        The registrant may register more than one prefix at a time, each contained in a separate <datatype-prefix/> element.

        @@ -368,7 +368,7 @@ A "standard" datatype as defined in XML Schema Part 2 XML Schema Part 2 - ]]> +]]> @@ -383,7 +383,7 @@ the minimum value for the datatype (if any) the maximum value for the datatype (if any) - ]]> +]]>

        The registrant may register more than one datatype at a time, each contained in a separate <datatype/> element.

        @@ -480,7 +480,7 @@ N/A N/A - ]]> +]]>         @@ -552,6 +552,6 @@ - ]]> +]]> diff --git a/xep-0123.xml b/xep-0123.xml index 3b1c6345..1efeef73 100644 --- a/xep-0123.xml +++ b/xep-0123.xml @@ -75,7 +75,7 @@ id='disco1'> - ]]> +]]>

        The entity returns its associated items:

        - ]]> +]]>

        In order to request the advertised metadata, the requesting entity sends a disco#info request to the 'metadata' node of the JID communicated in the previous result.

        @@ -102,7 +102,7 @@ - ]]> +]]>

        The entity returns its metadata to the requestor.

         - ]]> +]]>         diff --git a/xep-0124.xml b/xep-0124.xml index f8fbb014..c9bda5ad 100644 --- a/xep-0124.xml +++ b/xep-0124.xml @@ -214,7 +214,7 @@ | [HTTP + wrapper] | Client - ]]> +]]>

        This specification covers communication only between a client and the connection manager. It does not cover communication between the connection manager and the server, since such communications are implementation-specific (e.g., the server might natively support this HTTP binding, in which case the connection manager will be a logical entity rather than a physical entity; alternatively the connection manager might be an independent translating proxy such that the server might believe it is talking directly to the client over TCP; or the connection manager and the server might use a component protocol or an API defined by the server implementation).

        Furthermore, no aspect of this protocol limits its use to communication between a client and a server. For example, it could be used for communication between a server and a peer server if such communication can occur for the relevant application (e.g., in XMPP). However, this document focuses exclusively on use of the transport by clients that cannot maintain arbitrary persistent TCP connections with a server. We assume that servers and components are under no such restrictions and thus would use the native connection transport for the relevant application. (However, on some unreliable networks, BOSH might enable more stable communication between servers.)

         @@ -301,7 +301,7 @@ first socket second socket | |*| | +-+ | | - ]]> +]]>

        The requirements of RFC 2616 MUST be met for both requests and responses. Additional HTTP headers not specified herein MAY be included, but receivers SHOULD ignore any such headers. Clients and connection managers MAY omit headers that are not mandated by RFC 2616 and would otherwise be ignored (e.g. if the client has constrained bandwidth), but clients are advised that network and proxy policies could block such requests.

        @@ -1164,7 +1164,7 @@ Content-Length: 65 - ]]> +]]>

        Thanks to Dave Cridland, Mike Cumings, Tomas Karasek, Steffen Larsen, Tobias Markmann, Matt Miller, Chris Seymour, Safa Sofuoğlu, Stefan Strigler, Mike Taylor, Winfriend Tilanus, Matthew Wild, Kevin Winters, and Christopher Zorn for their feedback.

        diff --git a/xep-0126.xml b/xep-0126.xml index e913e306..1f4a17b6 100644 --- a/xep-0126.xml +++ b/xep-0126.xml @@ -99,14 +99,14 @@         - ]]> +]]>

        Naturally, the user could have defined this list during a previous session and could simply set the relevant list as active when logging in, rather than defining the list on login. Both steps are shown here for completeness.

        The user may now send initial presence to the server.

        I'm not really here, you understand! - ]]> +]]>

        Even though the user has sent initial presence, that presence information will not be broadcasted to any of the user's contacts, since the active privacy list blocks all outbound presence notifications.

        @@ -140,14 +140,14 @@ - ]]> +]]>

        The foregoing privacy list blocks outbound presence notifications to every JID except one.

        In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but the specified JID:

        I'm not really here, you understand! - ]]> +]]> - ]]> +]]>

        The foregoing privacy list blocks outbound presence notifications to every JID except those in a certain roster group. In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but those JIDs in the specified roster group:

        I'm not really here, you understand! - ]]> +]]>

        Becoming visible or invisible by subscription type is probably much less likely than becoming visible by JID or roster group; however, it is described here for the sake of completeness.

        @@ -204,14 +204,14 @@ - ]]> +]]>

        The foregoing privacy list blocks outbound presence notifications to every JID except those that are in the user's roster with a subscription type of "both".

        In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but those JIDs with the specified subscription type:

        I'm not really here, you understand! - ]]> +]]>         @@ -232,7 +232,7 @@ - ]]> +]]>

        Because globally allowing outbound presence notifications is most likely the default behavior of any server, a more straightforward way to become globally visible is to decline the use of any active rule (the equivalent, as it were, of taking off a magic invisibility ring):

        @@ -240,13 +240,13 @@ - ]]> +]]>

        In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but the specified JID:

        I'm back! - ]]> +]]>

        Let us now suppose that the user no longer wants to be globally visible, but desires to be invisible only to some -- but not all -- contacts. As with visibility, here again the 'jabber:iq:privacy' namespace gives the user three options:

        @@ -267,7 +267,7 @@

        First, the user sends unavailable presence for broadcasting to all contacts:

        - ]]> +]]>

        The server then broadcasts that presence to all of the user's contacts.

        Second, the user defines and sets a privacy rule that allows selective invisibility:

        - ]]> +]]>

        The foregoing privacy list allows outbound presence notifications to every JID except one.

        In order to appear selectively invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to the specified JID:

        I'm back! - ]]> +]]>

        First, the user sends unavailable presence for broadcasting to all contacts:

        - ]]> +]]>

        The server then broadcasts that presence to all of the user's contacts.

        Second, the user defines and sets a privacy rule that allows selective invisibility:

        - ]]> +]]>

        The foregoing privacy list allows outbound presence notifications to every JID except those in a certain roster group.

        In order to appear selectively invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to those in the specified roster group:

        I'm back! - ]]> +]]>

        Becoming visible or invisible by subscription type is probably much less likely than becoming visible by JID or roster group; however, it is described here for the sake of completeness.

        First, the user sends unavailable presence for broadcasting to all contacts:

        - ]]> +]]>

        The server then broadcasts that presence to all of the user's contacts.

        Second, the user defines and sets a privacy rule that allows selective invisibility:

        - ]]> +]]>

        The foregoing privacy list allows outbound presence notifications to every JID except those that are in the user's roster with a subscription type of "to".

        In order to appear selectively invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to those with the specified subscription type:

        I'm back! - ]]> +]]>         @@ -384,7 +384,7 @@

        First, the user sends unavailable presence for broadcasting to all contacts:

        - ]]> +]]>

        Second, the user sets as active the global invisibility list previously defined:

        @@ -392,13 +392,13 @@ - ]]> +]]>

        In order to appear globally invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all contacts:

        I'm not really here, you understand! - ]]> +]]>         diff --git a/xep-0127.xml b/xep-0127.xml index 810f2b82..8aa0a67a 100644 --- a/xep-0127.xml +++ b/xep-0127.xml @@ -109,7 +109,7 @@ - ]]> +]]>

        The publish-subscribe protocol defined in XEP-0060 provides a way to send information to a number of subscribers, and to control the list of subscribers.

        @@ -168,7 +168,7 @@ - ]]> +]]>

        If the pubsub node is configured to deliver payloads, the information is then sent to all subscribers.

        +]]>         diff --git a/xep-0128.xml b/xep-0128.xml index 6ef50fe6..51ed03e9 100644 --- a/xep-0128.xml +++ b/xep-0128.xml @@ -110,7 +110,7 @@ - ]]> +]]>

        The following is an example of including a disco extension in the IQ result sent by a Multi-User Chat room.

        @@ -152,7 +152,7 @@ - ]]> +]]>         diff --git a/xep-0129.xml b/xep-0129.xml index 4021a7f6..efdb14aa 100644 --- a/xep-0129.xml +++ b/xep-0129.xml @@ -69,12 +69,12 @@ Content-Type: text/html [body omitted] - ]]> +]]>

        Prior to storing the file, the server MUST verify the user's authentication credentials via any supported method. When the file is stored, the server also MUST set the owner "live" property to ensure that only the user that originally posted this file is allowed to modify the file in any way. Other users MAY be allowed to see properties and retrieve the file (upon authentication) but MUST NOT be able to perform operations such as DELETE, MOVE, and PROPPATCH.

        +]]>

        In the absence of any other authorization method (e.g., &rfc3744; or &saml;) in use by the deployed WebDAV server, the client SHOULD perform a PROPPATCH request to set the list of Jabber IDs authorized to retrieve this file, and the server MUST NOT allow access until this configuration is completed.

        - ]]> +]]>

        Note: The semantics of the JID list defined above are:

        • If a JID is a bare JID (no resource), any fully-qualified form of that JID may access this resource (in the example above, this means that any resource of juliet@capulet.com may access this URL).
          • @@ -117,7 +117,7 @@ - ]]> +]]>

          Now that the file is available via WebDAV and the client has specified what Jabber IDs may access the URL, the sender sends a message to the target user(s) containing the URL of the file, encapsulated via &xep0066;. (The example below shows the file being sent to multiple users using the &xep0033; protocol.)

          @@ -130,7 +130,7 @@ http://files.shakespeare.lit/missive.html - ]]> +]]>

          When the target recipients have received the message, they may then perform an HTTP GET to download the file (the following request is from juliet@capulet.com).

          +]]>

          The server then checks to ensure that the provided JID was specified via the jidlist property. If not, the server MUST return an HTTP 403 (Forbidden) error; if so, the server attempts to authorize the user via &xep0070;:

          - ]]> +]]>

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

          +]]>

          In order to discover a WebDAV server that supports this protocol, a client SHOULD use &xep0030;. Support for this protocol MUST be advertised by means of a service discovery feature named "http://www.xmpp.org/extensions/xep-0129.html#ns" &NSNOTE;. An example of the discovery flow is shown below.

          @@ -187,7 +187,7 @@ ... - ]]> +]]> - ]]> +]]>

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

           @@ -240,7 +240,7 @@ - ]]> +]]>

          Thanks to Lisa Dusseault and Julian Reschke for their feedback.

          diff --git a/xep-0130.xml b/xep-0130.xml index eeac8730..f3956190 100644 --- a/xep-0130.xml +++ b/xep-0130.xml @@ -405,7 +405,7 @@ - ]]> +]]> @@ -417,12 +417,12 @@ ... - ]]> +]]> - ]]> +]]> @@ -432,7 +432,7 @@ ... - ]]> +]]> - ]]> +]]>

          The WaitingListService SHOULD return detailed information about the service it provides, including the URI schemes it supports (see also the Service Discovery Features section of this document).

          - ]]> +]]>

          Once an IM User has discovered the WaitingListService, the user's client SHOULD request its current Waiting List. This is done by sending an IQ-get to the WaitingListService containing an empty <query/> element qualified by the 'http://jabber.org/protocol/waitinglist' namespace:

          - ]]> +]]>

          Upon request, the WaitingListService MUST return the current WaitingList to the IM User:

          - ]]> +]]>

          Each ItemID MUST be unique within the scope of the client's WaitingList items. The value of the ItemID is an opaque string; an implementation MAY assign semantic meaning to the ItemID (e.g., id="John Smith (mobile)" rather than id="12345"), but such meaning is implementation-specific and outside the scope of the protocol defined herein. The user MAY include a <name/> element containing a natural-language name for the Contact.

          The WaitingList MAY contain an item for which a JID has been discovered.

          - ]]> +]]>

          Once an IM User's client has discovered the WaitingListService and requested the user's WaitingList, the user can add Contacts to the WaitingList based on the Contact's URI. (Note: This document uses the example of phone numbers via the 'tel' URI scheme, but the same rules apply to WaitingList items based on email addresses or other URI schemes.)

          @@ -522,7 +522,7 @@ - ]]> +]]>

          As described below, various error conditions may occur. (For information about error syntax, refer to RFC 6120 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.

          - ]]> +]]>

          If the IM User included a JID in the request, WaitingListService MUST return a &badrequest; error to IM User and MUST NOT add the Contact to the WaitingList. (Note: A WaitingListService MUST NOT return a non-XMPP URI to an IM User based on the Contact's JID; see the Security Considerations section of this document.)

          - ]]> +]]>

          If the IM User provided an invalid URI (e.g., a phone number with too many digits or an email address with no '@' character), WaitingListService MUST return a ¬acceptable; error to the IM User and MUST NOT add the Contact to the WaitingList.

          - ]]> +]]>

          If one of the foregoing errors was generated (all of which have a type of "modify"), IM User SHOULD modify the request and re-submit it.

          If none of the "modify" errors was generated, WaitingListService MUST inform the IM User that the request was successfully received, including a unique ID number for the new WaitingList item.

          - ]]> +]]>

          If none of the "modify" errors was generated and WaitingListService knows Contact JID when the IQ result is returned to the user (e.g., because Contact is served by ServiceProvider), WaitingListService MAY include the WaitingList item in the IQ result: Even if WaitingListService returns Contact JID in the IQ-result, it MUST also send a "JID push" message.

          - ]]> +]]>

          If none of the "modify" errors was generated and WaitingListService does not know Contact JID when the IQ result is returned to the user, it needs to contact InteropPartners in order to determine if the Contact is associated with one of the InteropPartners. Thus before it returns the Contact JID to the IM User, it needs to wait for the one of the InteropPartners to return Contact JID or for all of the InteropPartners to return errors.

          If all of the InteropPartners return an error of type "cancel" (typically ¬found; and/or ¬authorized;) to WaitingListService, WaitingListService MUST return an ¬found; error (or local equivalent) to the IM User (and IM User SHOULD complete IM User Removes Contact from WaitingList use case).

          - ]]> +]]>

          If the connection to at least one of the InteropPartners times out (a &timeout; error), WaitingListService MUST return an IQ-result as described above (indicating that the request was received) and resend the request to the InteropPartners that timed out. If connections continue to time out (over some configurable time period and for some configurable number of retries), WaitingListService SHOULD then return a &timeout; error to IM User via a "JID push" message as shown below.

          If InterPartner's WaitingListService knows the Contact JID, it sends it to ServiceProvider's WaitingListService as shown in the ServiceProvider's WaitingListService Adds Contact to WaitingList section of this document.

          If WaitingListService knows Contact JID (or learns Contact JID from InteropPartner), it MUST inform IM User through a "JID push" message, which consists of a message stanza that contains a <waitlist/> element qualified by the 'http://jabber.org/protocol/waitinglist' namespace: @@ -637,7 +637,7 @@ - ]]> +]]>

          Note: The JID push uses an XMPP <message/> stanza because the WaitingListService has no knowledge of the user's presence and therefore cannot assume that an &IQ; stanza will be received by the user at a specific resource.

          If WaitingListService learns that Contact's URI is not handled by any InteropPartner, it MUST inform IM User through a "JID push" message:

          - ]]> +]]>

          After receiving the "JID push" message, IM User SHOULD complete the IM User Removes Contact from WaitingList use case.

           @@ -675,14 +675,14 @@ - ]]> +]]>

          If WaitingListService previously recorded request, WaitingListService removes request from list and returns result to IM User.

          - ]]> +]]>

          If WaitingListService did not previously record this request, WaitingListService MUST return an ¬found; error to the IM User.

          @@ -695,7 +695,7 @@ - ]]> +]]>           @@ -712,7 +712,7 @@ id='agent2'> - ]]> +]]> - ]]> +]]> - ]]> +]]> @@ -745,7 +745,7 @@ ... - ]]> +]]> - ]]> +]]> - ]]> +]]>

          Once a ServiceProvider's WaitingListService has discovered the InteropPartner's WaitingListService and requested its WaitingList, the ServiceProvider's WaitingListService can add items to its WaitingList based on URI.

          @@ -780,7 +780,7 @@ - ]]> +]]>

          If InteropPartner refuses to provide service to ServiceProvider, it MUST return a ¬authorized; error to the ServiceProvider:

          - ]]> +]]>

          If Contact's URI is not associated with a person served by this InteropPartner, the InteropPartner MUST return an ¬found; error to the ServiceProvider.

          - ]]> +]]>

          If ServiceProvider's WaitingListService receives ¬authorized; and/or ¬found; errors from all InteropPartners, it returns a ¬found; error to IM User:

          - ]]> +]]>

          If Contact's URI is associated with a person served by this InteropPartner, InteropPartner MUST return acknowledgement of the WaitingList addition to the ServiceProvider's WaitingListService.

          - ]]> +]]>

          If Contact is an IM User served by InteropPartner, InteropPartner's WaitingListService pushes Contact's JID to ServiceProvider's WaitingListService.

          - ]]> +]]> - ]]> +]]>

          After receiving acknowledgement (but not before), InteropPartner's WaitingListService MUST remove that item from the WaitingList for the ServiceProvider's WaitingListService.

           @@ -875,14 +875,14 @@ - ]]> +]]>

          If item exists on WaitingList, InteropPartner's WaitingListService removes item from list and returns result to ServiceProvider's WaitingListService.

          - ]]> +]]>

          If item does not exist on WaitingList, InteropPartner's WaitingListService MUST return an ¬found; error to the ServiceProvider's WaitingListService.

          - ]]> +]]>           @@ -1048,6 +1048,6 @@ - ]]> +]]> diff --git a/xep-0131.xml b/xep-0131.xml index 551598df..b7c8dbfb 100644 --- a/xep-0131.xml +++ b/xep-0131.xml @@ -112,7 +112,7 @@ to='juliet@capulet.com/balcony'> - ]]> +]]> @@ -122,7 +122,7 @@ ... - ]]> +]]>

          It can be desirable (and, in some contexts, necessary) to determine if the intended recipient of an XML stanza supports a specific header (e.g., the "Classification" header) before sending information that may depend on that header. Therefore, implementations of this protocol MUST advertise which particular SHIM headers they support when queried via disco#info at the well-known service discovery node 'http://jabber.org/protocol/shim'.

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

          The values of the 'var' attribute MUST be of the form "http://jabber.org/protocol/shim#header", where "header" is to be replaced with the name of the header as registered with the ®ISTRAR; (see below).

           @@ -162,7 +162,7 @@
          shakespeare,<xmpp/>
          - ]]> +]]>

          In accordance with &xmppcore;, an &IQ; stanza must not contain more than one non-error child element; this places constraints on the location of SHIM headers in the XML hierarchy. Specifically, the <headers/> wrapper element MUST NOT be a direct child of &IQ; and instead SHOULD be a grandchild of &IQ; and a direct child of the content-bearing child element of &IQ; (e.g., &QUERY;, not <error/>).

          - ]]> +]]>

          All public headers SHOULD be registered with the XMPP Registrar following the process specified in the XMPP Registrar Considerations section of this document. Many such headers are defined by other protocol specifications, such as RFCs 2045, 2616, 2617, 2822, and 3261; implementors MUST refer to those specifications for definition of the relevant headers.

          @@ -203,7 +203,7 @@
          3600
          - ]]> +]]>

          Another potential application is specifying a time to live for Service Discovery results, which helps other entities know how long to cache such information:

          - ]]> +]]>

          It can be useful to specify that the information contained in a stanza is more or less time-sensitive (e.g., in order to help the recipient determine whether to attend to the information immediately or to delay attending to the information). Such is the function of the "Urgency" header, the value of which is "high", "medium", or "low". One use of the header is Sieve notifications (see &sievenotify;) sent via XMPP, as specified in &sievenotifyxmpp;.

          @@ -234,7 +234,7 @@
          high
          - ]]> +]]>           @@ -265,7 +265,7 @@ a natural-language description of the header the document in which this header is specified - ]]> +]]>

          The registrant may register more than one header at a time, each contained in a separate <header/> element.

          @@ -894,7 +894,7 @@ RFC 2616 - ]]> +]]>           @@ -934,6 +934,6 @@ - ]]> +]]> diff --git a/xep-0132.xml b/xep-0132.xml index 54af4e7b..55cdc7d5 100644 --- a/xep-0132.xml +++ b/xep-0132.xml @@ -50,7 +50,7 @@ id='poke1'> - ]]> +]]>

          If the user's server does not support the POKE protocol, it SHOULD ignore the extension and treat the presence stanza as a normal (non-IRL) presence probe. However, the user's server MAY return a "Service Unavailable" error to the requesting entity to inform the requesting entity that IRL probes are not supported (for details regarding error syntax, refer to &xep0086;):

          - ]]> +]]>

          If the user's server supports the POKE protocol, it MUST first perform appropriate access checks to determine if the requesting entity has permission to view the user's presence (e.g., by checking presence subscriptions and privacy lists). If the user's server determines that the requesting entity is not allowed to learn the user's physical presence information, it MUST return a "Forbidden" error:

          - ]]> +]]>

          If the requesting entity has permission to discover the user's physical presence, the server SHOULD attempt to determine if the user is physically present. Methods for doing so are implementation-specific and therefore out of scope for this document, but possible mechanisms might include:

          1. sending messages to contacts in the user's roster who would be likely to have knowledge of the user's whereabouts (perhaps derived from physical proximity information gleaned from &xep0054; or &xep0080; data)
            2. @@ -93,7 +93,7 @@ id='poke1'> - ]]> +]]>

            The server SHOULD NOT wait an inordinate amount of time before returning the presence information (e.g., usually not more than two minutes), but the timeout period SHOULD be configurable. If the request times out, the server SHOULD return a "Request Timeout" error to the requesting entity:

            - ]]> +]]>

            The server SHOULD NOT return a "Not Found" error unless the user does not exist. If the server determines that the user has died, it MAY return a "Gone" error with appropriate descriptive text, although it SHOULD wait to do so pending notification of next-of-kin; note well that such notification is out of scope for this document (though this seems like a sensible application of the &xep0060; protocol):

            - ]]> +]]>

            If the requesting entity knows at least one resource with which the user is currently connected, it MAY send an IQ to the user's full JID (<user@host/resource>) instead of sending a probe to the user's server.

            @@ -136,7 +136,7 @@ - ]]> +]]>

            The same errors as shown above for presence stanzas SHOULD be used by clients responding to IQ stanzas containing POKE protocols (e.g., "Request Timeout" if the user cannot be found in some reasonable period of time), and therefore are not repeated here.

            Note that the preceding example includes the optional 'method' attribute. If the target entity does not support the specified method, it MAY return a "Feature Not Implemented" error:

            - ]]> +]]>

            Alternatively, it MAY choose to use some other method that it does implement, in which case it SHOULD specify the method used in the IQ result (this is the recommended behavior).

            If the client determines that the user is physically present, it SHOULD return presence to the requesting entity (subject to privacy lists and any other appropriate access controls):

            - ]]> +]]>

            The following values of the 'method' attribute are defined and SHOULD be supported by a compliant implementation:

            @@ -238,6 +238,6 @@ - ]]> +]]> diff --git a/xep-0133.xml b/xep-0133.xml index 4e271c26..523b2adb 100644 --- a/xep-0133.xml +++ b/xep-0133.xml @@ -146,7 +146,7 @@ action='execute' node='http://jabber.org/protocol/admin#add-user'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

            - ]]> +]]> - ]]> +]]> - ]]> +]]>

            Notification of completion MAY include the processed data in a data form of type "result".

             @@ -250,7 +250,7 @@ action='execute' node='http://jabber.org/protocol/admin#delete-user'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

            - ]]> +]]>

            Note: If the entity is an end user, the JID SHOULD be of the form <user@host>, not <user@host/resource>.

            - ]]> +]]> - ]]> +]]>

            An administrator may need to temporarily disable a user account. Disabling a user MUST result in the termination of any active sessions for the user and in the prevention of further user logins until the account is re-enabled (this can be thought of as "banning" the user). However, it MUST NOT result in the destruction of any implementation-specific data for the account (e.g., database entries or a roster file). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#disable-user".

            @@ -324,7 +324,7 @@ action='execute' node='http://jabber.org/protocol/admin#disable-user'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

            - ]]> +]]>

            Note: If the entity is an end user, the JID SHOULD be of the form <user@host>, not <user@host/resource>.

            - ]]> +]]> - ]]> +]]>

            An administrator may need to re-enable a user account that had been temporarily disabled. Re-enabling a user MUST result in granting the user the ability to access the service again. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#reenable-user".

            @@ -398,7 +398,7 @@ action='execute' node='http://jabber.org/protocol/admin#reenable-user'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

            - ]]> +]]>

            Note: If the entity is an end user, the JID SHOULD be of the form <user@host>, not <user@host/resource>.

            - ]]> +]]> - ]]> +]]>

            An administrator may need to terminate one or all of the user's current sessions, but allow future logins (this can be thought of as "kicking" rather than "banning" the user). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#end-user-session".

            @@ -472,7 +472,7 @@ action='execute' node='http://jabber.org/protocol/admin#end-user-session'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

            - ]]> +]]>

            Note: If the JID is of the form <user@host>, the service MUST end all of the user's sessions; if the JID is of the form <user@host/resource>, the service MUST end only the session associated with that resource.

            - ]]> +]]> - ]]> +]]>

            An administrator may need to retrieve a user's password. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-user-password".

            @@ -546,7 +546,7 @@ action='execute' node='http://jabber.org/protocol/admin#get-user-password'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

            - ]]> +]]>

            Note: If the entity is an end user, the JID SHOULD be of the form <user@host>, not <user@host/resource>.

            - ]]> +]]>

            Naturally, the data form included in the IQ result will include the user's password.

            - ]]> +]]>

            An administrator may need to change a user's password. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#change-user-password".

            @@ -633,7 +633,7 @@ action='execute' node='http://jabber.org/protocol/admin#change-user-password'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

            - ]]> +]]>

            Note: If the entity is an end user, the JID SHOULD be of the form <user@host>, not <user@host/resource>.

            - ]]> +]]> - ]]> +]]>

            An administrator may need to retrieve a user's roster (e.g., to help verify the user's ownership of the account before reminding the user of the password). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-user-roster".

            @@ -715,7 +715,7 @@ action='execute' node='http://jabber.org/protocol/admin#get-user-roster'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

            - ]]> +]]>

            Note: If the entity is an end user, the JID SHOULD be of the form <user@host>, not <user@host/resource>.

            - ]]> +]]>

            The data form included in the IQ result will include the user's roster, formatted according to the 'jabber:iq:roster' protocol defined in &xmppim;.

            - ]]> +]]>

            An administrator may need to retrieve a user's last login time (e.g., to help verify the user's ownership of the account before reminding the user of the password). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-user-lastlogin".

            @@ -817,7 +817,7 @@ action='execute' node='http://jabber.org/protocol/admin#get-user-lastlogin'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

            - ]]> +]]>

            Note: If the entity is an end user, the JID SHOULD be of the form <user@host>, not <user@host/resource>.

            - ]]> +]]>

            The data form included in the IQ result will include the user's last login time (which SHOULD conform to the DateTime profile specified in &xep0082;).

            - ]]> +]]>

            An administrator may want to gather statistics about a particular user's interaction with the service (roster size, bandwidth usage, logins, IP address, etc.). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#user-stats".

            @@ -904,7 +904,7 @@ action='execute' node='http://jabber.org/protocol/admin#user-stats'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

            - ]]> +]]> - ]]> +]]> - ]]> +]]>

            The service may enable an administrator to define one or more service-wide blacklists (lists of entities that are blocked from communications to or from the service). For example, a multi-user chat service may forbid a certain user from joining any room on the service, or may block entire domains from accessing the service. An entity specified on the blacklist 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;.

            @@ -1000,7 +1000,7 @@ action='execute' node='http://jabber.org/protocol/admin#edit-blacklist'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

            - ]]> +]]> - ]]> +]]> - ]]> +]]>

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

            @@ -1078,7 +1078,7 @@ action='execute' node='http://jabber.org/protocol/admin#edit-whitelist'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

            - ]]> +]]> - ]]> +]]> - ]]> +]]>

            It may be helpful to enable an administrator to retrieve the number of registered users. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-registered-users-num".

            @@ -1159,7 +1159,7 @@ action='execute' node='http://jabber.org/protocol/admin#get-registered-users-num'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD simply return the number of registered users.

            - ]]> +]]>

            Given that admins may be able to disable user accounts, it may be helpful to enable an administrator to retrieve the number of disabled users. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-disabled-users-num".

            @@ -1197,7 +1197,7 @@ action='execute' node='http://jabber.org/protocol/admin#get-disabled-users-num'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD simply return the number of disabled users.

            - ]]> +]]>

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

            @@ -1235,7 +1235,7 @@ action='execute' node='http://jabber.org/protocol/admin#get-online-users-num'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD simply return the number of online users.

            - ]]> +]]>

            Some services may distinguish users who are online and actively using the service from users who are online but idle. Therefore it may be helpful to enable an administrator to retrieve the number of online users who are active at any one moment. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-active-users-num".

            @@ -1273,7 +1273,7 @@ action='execute' node='http://jabber.org/protocol/admin#get-active-users-num'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD simply return the number of active users.

            - ]]> +]]>

            Some services may distinguish users who are online and actively using the service from users who are online but idle. Therefore it may be helpful to enable an administrator to retrieve the number of online users who are idle at any one moment. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-idle-users-num".

            @@ -1311,7 +1311,7 @@ action='execute' node='http://jabber.org/protocol/admin#get-idle-users-num'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD simply return the number of idle users.

            - ]]> +]]>

            On a server or service without many registered users, it may be helpful to enable an administrator to retrieve a list of all registered users. The service may need to truncate the result-set, since it could be quite large (however, any ability to limit or page through the result-set is outside the scope of this document). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-registered-users-list".

            @@ -1349,7 +1349,7 @@ action='execute' node='http://jabber.org/protocol/admin#get-registered-users-list'/> - ]]> +]]>

            Unless an error occurs (see the Error Handling section below), the service SHOULD do one of the following:

            1. If there are not many registered users, the service MAY simply return the list of registered users.
              2. @@ -1388,7 +1388,7 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]>

              The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.

              The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.

              @@ -1467,7 +1467,7 @@ action='execute' node='http://jabber.org/protocol/admin#get-disabled-users-list'/> - ]]> +]]>

              Unless an error occurs (see the Error Handling section below), the service SHOULD do one of the following:

              1. If there are not many disabled users, the service MAY simply return the list of disabled users.
                2. @@ -1506,7 +1506,7 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]>

                The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.

                The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.

                @@ -1566,7 +1566,7 @@ action='execute' node='http://jabber.org/protocol/admin#get-online-users-list'/> - ]]> +]]>

                Unless an error occurs (see the Error Handling section below), the service SHOULD do one of the following:

                1. If there are not many online users, the service MAY simply return the list of online users.
                  2. @@ -1605,7 +1605,7 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]>

                  The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.

                  The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.

                  @@ -1675,7 +1675,7 @@ action='execute' node='http://jabber.org/protocol/admin#get-active-users'/> - ]]> +]]>

                  Unless an error occurs (see the Error Handling section below), the service SHOULD do one of the following:

                  1. If there are not many active users, the service MAY simply return the list of active users.
                    2. @@ -1714,7 +1714,7 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]>

                    The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.

                    The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.

                    @@ -1777,7 +1777,7 @@ action='execute' node='http://jabber.org/protocol/admin#get-idle-users'/> - ]]> +]]>

                    Unless an error occurs (see the Error Handling section below), the service SHOULD do one of the following:

                    1. If there are not many idle users, the service MAY simply return the list of idle users.
                      2. @@ -1816,7 +1816,7 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]>

                      The service MAY return an error (rather than a list) if the number of items is excessive or the max_items value is unnacceptable.

                      The service MAY specify additional fields that restrict the scope of the user list (e.g., regular expression matching for Jabber IDs), and such fields MAY be registered in the future with the XMPP Registrar; however, such fields are not defined herein.

                      @@ -1881,7 +1881,7 @@ action='execute' node='http://jabber.org/protocol/admin#announce'/> - ]]> +]]>

                      Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

                      - ]]> +]]> - ]]> +]]> - ]]> +]]>

                      Administrators of some existing Jabber servers have found it useful to be able to send a "message of the day" that is delivered to any user who logs in to the server that day (e.g., to announce service changes); @@ -1961,7 +1961,7 @@ action='execute' node='http://jabber.org/protocol/admin#set-motd'/> - ]]> +]]>

                      Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

                      - ]]> +]]> - ]]> +]]> - ]]> +]]>

                      After setting a message of the day, an administrator may want to edit that message (e.g., in order to correct an error). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#edit-motd".

                      @@ -2040,7 +2040,7 @@ action='execute' node='http://jabber.org/protocol/admin#edit-motd'/> - ]]> +]]>

                      Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form, which SHOULD include the current message of the day if one has already been set.

                      - ]]> +]]> - ]]> +]]> - ]]> +]]>

                      Sometimes a previously-set "message of the day" is no longer appropriate and needs to be deleted. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#delete-motd".

                      @@ -2124,7 +2124,7 @@ action='execute' node='http://jabber.org/protocol/admin#delete-motd'/> - ]]> +]]>

                      Unless an error occurs (see the Error Handling section below), the service SHOULD simply delete the message of the day.

                      - ]]> +]]>

                      Some existing Jabber servers send an informative "welcome message" to newly registered users of the server when they first log in; this concept can be extended to any service (such as a multi-user chat service or a gateway to a foreign IM service). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#set-welcome".

                      @@ -2152,7 +2152,7 @@ action='execute' node='http://jabber.org/protocol/admin#set-welcome'/> - ]]> +]]>

                      Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form, which SHOULD include the current welcome message if one has already been set.

                      - ]]> +]]> - ]]> +]]> - ]]> +]]>

                      Sometimes a previously-set "welcome message" is no longer appropriate and needs to be deleted. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#delete-welcome".

                      @@ -2233,7 +2233,7 @@ action='execute' node='http://jabber.org/protocol/admin#delete-welcome'/> - ]]> +]]>

                      Unless an error occurs (see the Error Handling section below), the service SHOULD simply delete the welcome message.

                      - ]]> +]]>

                      An administrator may want to directly edit the list of users who have administrative privileges. Whether there are distinctions between service-level administrators (e.g., owner, admin, moderator), and thus in what types of administrators are allowed to edit administrative privileges, is a matter for the implementation or local service policy and is not specified herein. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#edit-admin".

                      @@ -2261,7 +2261,7 @@ action='execute' node='http://jabber.org/protocol/admin#edit-admin'/> - ]]> +]]>

                      Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

                      - ]]> +]]> - ]]> +]]> - ]]> +]]>

                      A service may allow an administrator to restart the service. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#restart".

                      @@ -2339,7 +2339,7 @@ action='execute' node='http://jabber.org/protocol/admin#restart'/> - ]]> +]]>

                      Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

                      - ]]> +]]> - ]]> +]]> - ]]> +]]>

                      A service may allow an administrator to shut down the service. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#shutdown".

                      @@ -2425,7 +2425,7 @@ action='execute' node='http://jabber.org/protocol/admin#shutdown'/> - ]]> +]]>

                      Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

                      - ]]> +]]> - ]]> +]]> - ]]> +]]>                       @@ -2638,7 +2638,7 @@ type='jid-multi' label='A list of entities with whom communication is allowed'/> - ]]> +]]> diff --git a/xep-0135.xml b/xep-0135.xml index 61a14bcc..8d3e3e89 100644 --- a/xep-0135.xml +++ b/xep-0135.xml @@ -54,7 +54,7 @@ id='disco1'> - ]]> +]]> - ]]> +]]>

                      This document stipulates that communications regarding files MUST occur by sending stanzas to the well-known service discovery node "files" (or sub-nodes thereof as defined below). Therefore, even if (as in the foregoing example) the file owner directly supports the protocol defined herein, the requesting entity MUST send subsequent file-related service discovery requests to the node "files" (or sub-nodes thereof). The file owner also SHOULD list that node in its response to a service discovery items request, as shown in the following example:

                      - ]]> +]]> - ]]> +]]>

                      It is possible that the file owner does not directly support the protocol defined herein and therefore that the offering entity has a JID different from that of the file owner. In this case, the file owner MUST NOT include a feature of "http://jabber.org/protocol/files" in its response to a service discovery information request, as shown in the following example (an end user querying another end user):

                      @@ -100,7 +100,7 @@ id='disco3'> - ]]> +]]> - ]]> +]]>

                      However, in this case the file owner SHOULD still include the offering entity (e.g., a hosting service) in its response to a service discovery items request:

                      - ]]> +]]> - ]]> +]]>                       @@ -147,7 +147,7 @@ - ]]> +]]>

                      If the requesting entity is not allowed to view the offering entity's files (the requesting entity is not an occupant of a chatroom, is not registered with the offering entity, is not a contact in a user's roster, etc.) or the offering entity has no files to share, the offering entity SHOULD return an empty &QUERY; element:

                      - ]]> +]]>

                      If the requesting entity is allowed to view the offering entity's files and the offering entity has files to share, the offering entity SHOULD return a list of items:

                       - ]]> +]]>

                      Note: The NodeID MUST begin with the string 'files' followed by the '/' character followed the name of the directory or file; further subdirectories or files within a directory MUST follow the same pattern (e.g., "files/somedir/anotherfile"). Thus the protocol defined herein enforces semantic meaning on NodeIDs; this is OPTIONAL within Service Discovery but REQUIRED by this document.

                      If the offering entity has only a few files to share, it may be appropriate to make them available via service discovery only, thus requiring the requesting entity to "walk the tree" of directories and files as described in the Finding All Files via Service Discovery section. However, if the offering entity has a larger number of files to share, the number of service discovery requests and responses required to "walk the tree" of all directories and files might result in excessive amounts of traffic between the requesting entity and the offering entity; in this case, the offering entity SHOULD provide a "tree file" that defines the hierarchy of directories and files in the standardized format specified in the Retrieving the Tree File section. The number of files that counts as "large" is not defined herein and is left up to the implementation or deployment; in practice, it is RECOMMENDED for the offering entity to provide a tree file if it has more than five (5) files to share.

                      @@ -187,7 +187,7 @@ - ]]> +]]>

                      If the item is a directory, the offering entity SHOULD return information about the directory, including an identity whose category is "filesys" and whose type is "directory":

                       - ]]> +]]>

                      If the requesting entity wants information about every item, it MUST query each item individually:

                      - ]]> +]]>

                      If the item is a file, the offering entity SHOULD return information about the file, including an identity whose category is "filesys" and whose type is "file":

                      - ]]> +]]>

                      Note: The offering entity MAY also include detailed information about the file, as described in the Determining File Details section of this document.

                      If the requesting entity wants to find all files, it needs to send a disco#items query to the directory:

                      - ]]> +]]>

                      The offering entity will then return a list of files and directories contained within the queried directory:

                      - ]]> +]]>

                      The requesting entity then needs to send further disco#info and disco#items requests to the offering entity, specifying the appropriate service discovery nodes...

                      - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]> - ]]> +]]>

                      In this scenario, we can reconstruct the file tree as follows:

                      +]]>

                      Obviously, finding all files via service discovery is a tedious process. Therefore, it is RECOMMENDED that the offering entity provide a "tree file" if it has more than five (5) files to share. The format of the tree file is defined by the 'http://jabber.org/profile/si/profile/tree-transfer' namespace that is specified in &xep0105;. The tree file MUST be named "tree.xml" and MUST be available at the well-known service discovery node "tree.xml". The offering entity MAY create a different tree file for each requesting entity (depending on the requesting entity's permissions to view certain directories and files); for this reason, the tree file SHOULD NOT be contained in the root "files" directory itself (note that its NodeID is "tree.xml", not "files/tree.xml").

                      @@ -353,7 +353,7 @@ share - ]]> +]]> - ]]> +]]>

                      If the offering entity includes a service discovery item whose NodeID is "tree.xml", the requesting entity SHOULD retrieve that file (using the protocol specified in the Retrieving a File section) before sending any further service discovery requests to the offering entity.

                      The following example shows the exact format of the tree file that would represent the file and directory hierarchy discovered via service discovery in the preceding section:

                      - ]]> +]]>

                      If the offering entity provides a tree file, it is RECOMMENDED (but not required) for the offering entity to also make information about its files discoverable via Service Discovery as described in the following section.

                       @@ -402,7 +402,7 @@ share - ]]> +]]> - ]]> +]]>

                      The fields shown are RECOMMENDED, and are specified more fully in the XMPP Registrar Considerations section of this document.

                                             @@ -447,12 +447,12 @@ share - ]]> +]]>

                      Note: If the requested file was found by means of the tree file rather than service discovery, the NodeID of the retrieve request MUST be constructed according to the rules specified above for service discovery NodeIDs (i.e., 'files' followed by the '/' character followed by the name of the directory or file, followed by additional '/' characters and subdirectory or file names as needed).

                      If the offering entity agrees to share the file with the requesting entity, it MUST return an IQ result to the requesting entity and then immediately initiate a file transfer to the requesting entity following the protocol defined in &xep0096;:

                      - ]]> +]]> - ]]> +]]>

                      The value of the <si/> element's 'id' attribute MUST be the same as the value of the 'sid' attribute communicated in the tree file or the 'name' attribute communicated via service discovery; for this reason, the service discovery 'name' attribute is REQUIRED for NodeIDs that correspond to files, and its value MUST follow the rules for the 'sid' attribute specified in XEP-0105.

                      Upon receiving the file transfer initiation from the offering entity, the requesting entity SHOULD check the SI 'id' in order to correlate the file transfer with the request; if there is a match, the requesting entity SHOULD silently accept the file transfer and not require intervention by a human before proceeding.

                      If the offering entity does not agree to share the file with the requesting entity, it MUST return an appropriate IQ error to the requesting entity, such as "Not Authorized", "Forbidden", "Payment Required", "Registration Required", or "Not Found" (see &xep0086; regarding error syntax).

                      @@ -525,7 +525,7 @@ share type='text-single' label='Equivalent to size attribute from XEP-0096'/> - ]]> +]]> @@ -555,6 +555,6 @@ share - ]]> +]]> diff --git a/xep-0136.xml b/xep-0136.xml index 21659560..4c7e5e2a 100644 --- a/xep-0136.xml +++ b/xep-0136.xml @@ -222,7 +222,7 @@ - ]]> +]]>

                      The <auto/> element specifies the current Automatic Archiving settings for this stream.

                      This element MUST be empty and MUST include a boolean 'save' attribute &BOOLEANNOTE; that specifies whether automatic archiving is enabled or disabled for this stream. The element MAY include a 'scope' attribute that specifies how long this setting is true. The allowable values are:

                      @@ -341,7 +341,7 @@ - ]]> +]]>

                      The server responds with the default Save Mode and OTR Mode (a single <default/> element) and any specific Save Modes and OTR Modes for individual contacts (zero or more <item/> elements).

                      @@ -356,7 +356,7 @@ - ]]> +]]>

                      The foregoing preferences can be explained as follows:

                      1. By default, message bodies should be saved (according the preferred method specified later), communications may be off the record if requested, and any saved messages should be expired after 1 year.
                        2. @@ -378,7 +378,7 @@ - ]]> +]]>

                        Once it has received a request for archiving preferences from the client, the server MUST send any subsequent changes to any of the user's archiving preferences to the client until the stream is closed (see below). Note: changes to the <auto/> element MUST NOT be replicated in this way.

                        @@ -389,11 +389,11 @@ - ]]> +]]>

                        If the server can process the request, it acknowledges the change:

                        - ]]> +]]>

                        The server then MUST inform all of the user's connected resources that have previously requested the user's archiving preferences:

                        @@ -407,7 +407,7 @@ - ]]> +]]>

                        If the server does not allow the saving of full message stanza content, the client set the value of the 'save' attribute to 'message' or 'stream', and any of the user's connected resources have Automatic Archiving enabled, then the server SHOULD return a &feature; error.

                        If administrator policies require that at least the <body/> elements (or the full content) of every message must be logged automatically and the client attempts to set the value of the 'save' attribute to 'false' or 'body', then the server SHOULD return a ¬acceptable; error.

                         @@ -419,10 +419,10 @@ - ]]> +]]> - ]]> +]]> @@ -435,7 +435,7 @@ - ]]> +]]>

                        The same error cases apply as when Setting Default Modes.

                        In order to remove all preferences for a contact, the client shall send an <itemremove/> element to the server.

                        - ]]> +]]> - ]]> +]]>

                        A client may use a similar protocol to set the Modes for a particular chat session. A chat session is identified by its unique 'thread' attributes in <message> stanza (see &xep0155;).

                        @@ -457,10 +457,10 @@ - ]]> +]]> - ]]> +]]> @@ -473,7 +473,7 @@ - ]]> +]]>

                        The same error cases apply as when Setting Default Modes.

                        In order to remove a preference for a chat session, the client shall send an <sessionremove/> element to the server.

                        - ]]> +]]> - ]]> +]]>

                        The client can set one or more method preferences by sending an IQ-set containing a <pref/> element that in turn contains one or more <method/> elements.

                        @@ -497,10 +497,10 @@ - ]]> +]]> - ]]> +]]>

                        If the client includes less than three <method/> elements, the server MUST NOT modify the unspecified methods and MUST leave them as currently stored on the server. However, when the server pushes the method preferences it MUST include all of the preferences, not only those that were set by the client.

                        @@ -518,7 +518,7 @@ - ]]> +]]>

                        Most archiving preferences are designed for interpretation only by the client. The server MUST NOT take into account any of the archiving preferences when server administration policies require that every message is to be logged automatically. Otherwise, the server MUST interpret the following archiving preferences (and SHOULD NOT interpret any other ones):

                        @@ -708,7 +708,7 @@ - ]]> +]]>

                        If the collection does not exist then the server MUST create a new collection and inform the client that the collection version number is zero.

                        @@ -720,7 +720,7 @@ version='0'/> - ]]> +]]>

                        If the collection already exists then the server MUST append the messages to the existing collection (which MAY involve adding messages that appear to be duplicates, i.e., messages that have identical <from/> elements, <to/> elements, and dateTimes).

                        @@ -732,7 +732,7 @@ version='1'/> - ]]> +]]>

                        Note: Clients MUST take care to append each sequence of messages to the collection before the sequence becomes so large that uploading it may violate common rate limiting restrictions (in Jabber systems, often called "karma").

                        If the server cannot service an upload request because the collection is too large then it MUST return a ¬acceptable; error:

                        - ]]> +]]>

                        If the client specifies a new value for the 'subject' attribute of any existing collection then the server MUST update the existing value and increment the collection version. Note: The client cannot specify new values for the 'with' or 'start' attributes. The only way to change these values is to delete the collection (see Removing a Collection) and then create a new one.

                        @@ -753,7 +753,7 @@ subject='She speaks twice!'/> - ]]> +]]> @@ -763,7 +763,7 @@ version='1'/> - ]]> +]]>

                        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:

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

                        A client MAY archive messages that it receives from &xep0045; rooms. The 'with' attribute MUST be the bare JID of the room. The client MUST include a 'name' attribute for each <from/> element to specify the room nickname of the message sender and MAY include a 'jid' attribute to specify the full or bare JID of the sender (if available).

                        @@ -794,7 +794,7 @@ - ]]> +]]>

                        Collections MAY be linked together by including a <previous/> and/or <next/> element. Each such element MUST include both a 'with' and a 'start' element to identify the other collection to which the collection is linked. For example, the <previous/> and <next/> elements in the two examples below are being used to link a groupchat between Romeo, Benvolio and Mercutio to a private chat that Romeo was having with Benvolio before they invited Mercutio to join them. Note: Collections MAY be linked in only one direction, they are not required to be double-linked in the way the examples below are.

                        @@ -809,7 +809,7 @@ - ]]> +]]> @@ -822,7 +822,7 @@ - ]]> +]]>

                        A collection MUST NOT contain more than one <previous/> and one <next/> element. If a <previous/> element is uploaded to a collection that already contains one then the older <previous/> element MUST be discarded. The same requirement applies for <next/> elements.

                        When a collection is retrieved (see Retrieving a Collection) the <previous/> and <next/> elements MUST appear as the first elements in the collection, whatever order they were uploaded in.

                        <previous/> and <next/> elements MAY be removed from a collection simply by uploading a <previous/> and/or <next/> element without any 'with' or 'start' attributes. Note: The server SHOULD NOT return an error if it finds that a link to be deleted does not exist.

                        @@ -836,7 +836,7 @@ - ]]> +]]>

                        A client MAY append attributes to a collection by including an x:data form of type 'submit' (see &xep0004;) when it uploads to a collection.

                        @@ -858,7 +858,7 @@ - ]]> +]]>

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

                         @@ -875,7 +875,7 @@ WARNING: All messages that you send or receive will be recorded by the server. - ]]> +]]>

                        Otherwise:

                        • Automatic archiving MUST default to enabled or disabled when each stream is opened according to the last value of <auto/> element if 'scope' was set to 'global' (see Auto element), else Automatic archiving MUST default disabled.
                          • @@ -888,7 +888,7 @@ - ]]> +]]>

                          If the server does not support the saving of full message stanza or stream content and the user has specified the 'message' or 'stream' Save Mode in one of its Archiving Preferences, the server MUST return a &feature; error.

                          @@ -896,13 +896,13 @@ - ]]> +]]>

                          The client can disable auto-archiving by setting the 'save' attribute to "false" or "0".

                          - ]]> +]]>

                          If service policies require that every message is logged automatically, the server MUST return a ¬allowed; error.

                          @@ -910,7 +910,7 @@ - ]]> +]]> @@ -934,7 +934,7 @@ - ]]> +]]> - ]]> +]]> - ]]> +]]>

                          The server MUST list the collections (empty <chat/> elements including all attributes) in chronological order when responding to any request.

                          Note: In accordance with Result Set Management, the client MUST assume that the unique IDs it receives in the <first/> and <last/> elements are opaque. Servers MAY adopt a unique ID format other than the one suggested in the example above.

                          If no collections correspond to the request the server MUST return an empty <list/> element:

                          @@ -964,7 +964,7 @@ - ]]> +]]> - ]]> +]]>

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

                          @@ -992,7 +992,7 @@ - ]]> +]]> - ]]> +]]>

                          Note: In accordance with Result Set Management, the client MUST assume the unique IDs it receives in the <first/> and <last/> elements are opaque. Servers MAY adopt a unique ID format other than the one suggested in the example above.

                          If the specified collection does not exist then the server MUST return an ¬found; error:

                          - ]]> +]]>

                          If the requested collection is empty the server MUST return an empty <chat/> element:

                          @@ -1039,7 +1039,7 @@ subject='She speaks!' version='5'/> - ]]> +]]> - ]]> +]]>

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

                           @@ -1062,7 +1062,7 @@ with='juliet@capulet.com/chamber' start='1469-07-21T02:56:15Z'/> - ]]> +]]>

                          The client MAY remove several collections at once. The 'start' and 'end' elements MAY be specified to indicate a date range. The 'with' attribute MAY specify JID of XMPP entities, see the JID Matching section of this document.

                          @@ -1071,7 +1071,7 @@ start='1469-07-21T02:00:00Z' end='1469-07-21T04:00:00Z'/> - ]]> +]]>

                          If the 'with' attribute is omitted then collections with any JID are removed.

                          If the end date is in the future then all collections on or after the start date are removed.

                          - ]]> +]]>

                          If the start date is before all the collections in the archive then all collections prior to the end date are removed.

                          @@ -1088,12 +1088,12 @@ start='0000-01-01T00:00:00Z' end='1469-07-21T04:00:00Z'/> - ]]> +]]> - ]]> +]]>

                          If the value of the optional 'open' attribute is set to 'true' then only collections that are currently being recorded automatically by the server (see Automatic Archiving) are removed.

                          @@ -1101,13 +1101,13 @@ with='juliet@capulet.com/chamber' open='true'/> - ]]> +]]> - ]]> +]]>

                          If the specified collection (or collections) do not exist then the server MUST return an ¬found; error:

                          @@ -1118,7 +1118,7 @@ - ]]> +]]>                           @@ -1136,7 +1136,7 @@ - ]]> +]]>

                          The server MUST return the changed collections in the chronological order that they were changed (most recent last). If a collection has been modified, created, or removed after the time specified by the 'start' attribute, then the server MUST include it in the returned result set page of collections (unless the specified maximum page size would be exceeded). Each <changed/> or <removed/> collection element (for modified/created, or removed collections respectively) in the returned list MUST include the 'with' and 'start' attribues. The XML character data of the <last/> element is a unique, persistent identifier created by the server, which MUST be treated as opaque by the client.

                          @@ -1154,7 +1154,7 @@ - ]]> +]]>

                          Note: The server should remember the 'with' and 'start' attribues and the time of removal of all deleted collections. If this "state" cannot be maintained indefinitely, then unless all the user's clients replicate before the server deletes its memory of a removal it will not be reflected in all the local copies of the archive.

                          Note: Along with its copy of the archive the client SHOULD save the most recent <last/> identifier that it received from the server. The next time it synchronizes with the server it SHOULD specify that identifier when requesting the first result set page by including it as the XML character data of the <after/> element in Result Set Management.

                          - ]]> +]]>

                          After receiving each result set page the client SHOULD delete from its local archive any collections that have been removed from the master archive. The client should also retrieve from the server the content of each collection that has been modified (see Retrieving a Collection) and add it to its local copy of the archive (deleting any older version of the same collection that it may already have).

                          @@ -1181,7 +1181,7 @@ type='get'> - ]]> +]]>

                          For each feature defined herein, if the server supports that feature it MUST return a <feature/> element with the 'var' attribute set to 'urn:xmpp:archive:[name]', where '[name]' is 'auto' for the Automatic Archiving feature, 'manage' for the Archive Management feature, 'manual' for the Manual Archiving feature, and 'pref' for the Archiving Preferences feature.

                           - ]]> +]]> @@ -1233,13 +1233,13 @@ - ]]> +]]> - ]]> +]]> @@ -1564,7 +1564,7 @@ - ]]> +]]>

                          Thanks to Alexey Melnikov and Alexander Tsvyashchenko for their comments and suggestions.

                          diff --git a/xep-0137.xml b/xep-0137.xml index 3212e76c..44b08b35 100644 --- a/xep-0137.xml +++ b/xep-0137.xml @@ -74,7 +74,7 @@ mime-type='mime/type'> - ]]> +]]>

                          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.

                          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.

                          @@ -103,7 +103,7 @@ - ]]> +]]> @@ -125,7 +125,7 @@ - ]]> +]]>

                          The <sipub/> element MAY also be included directly within a &MESSAGE; stanza sent to another entity (or multiple entities, e.g., in &xep0045; or via &xep0033;). This can be especially useful for informing an offline entity about an available stream.

                          @@ -141,7 +141,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.

                          @@ -151,7 +151,7 @@ - ]]> +]]>

                          When submitting such a form, a field's value(s) MUST be the <sipub/> identifier(s). Also, the submitter MUST provide an <sipub/> element within the data form for each file to be uploaded:

                          @@ -168,7 +168,7 @@ date='2005-07-21T11:21Z'/> - ]]> +]]>

                          The form processor will use this to retrieve the file(s) to be uploaded.

                           @@ -181,7 +181,7 @@ - ]]> +]]>

                          If the sender accepts the request, it responds with an IQ-result containing a <starting/> element. This element indicates the stream initiation identifier to be used:

                          - ]]> +]]>

                          Then the sender begins the stream initiation negotiation:

                          - ]]> +]]>

                          If the requested identifier is not valid, the sender SHOULD respond with a ¬acceptable; error:

                          - ]]> +]]>

                          If the receiver does not have permission to request the data stream, the sender SHOULD respond with a &forbidden; error:

                          - ]]> +]]>                           @@ -261,7 +261,7 @@ Datatype for publishing an SI using the File Transfer Profile XEP-0096 - ]]> +]]> @@ -315,6 +315,6 @@ - ]]> +]]> diff --git a/xep-0138.xml b/xep-0138.xml index 0c366e3a..8ef5ab2a 100644 --- a/xep-0138.xml +++ b/xep-0138.xml @@ -106,39 +106,39 @@ lzw - ]]> +]]>

                          Note: The <compression/> element MUST contain at least one <method/> child element. Each <method/> element MUST contain XML character data that specifies the name of a compression method, and such method names SHOULD be registered as described in the Compression Methods Registry section of this document. The methods SHOULD be provided in order of preference.

                          The initiating entity then MAY request compression by specifying one of the methods advertised by the receiving entity:

                          zlib - ]]> +]]>

                          Note: If the initiating entity did not understand any of the advertised compression methods, it SHOULD ignore the compression option and proceed as if no compression methods were advertised.

                          If the initiating entity requests a stream compression method that is not supported by the receiving entity, the receiving entity MUST return an <unsupported-method/> error:

                          - ]]> +]]>

                          If the receiving entity finds the requested method unacceptable or unworkable for any other reason, it MUST return a <setup-failed/> error:

                          - ]]> +]]>

                          Note: Failure of the negotiation SHOULD NOT be treated as an unrecoverable error and therefore SHOULD NOT result in a stream error. In particular, the initiating entity is free to retry the compression negotiation if it fails.

                          If no error occurs, the receiving entity MUST inform the initiating entity that compression has been successfully negotiated:

                          - ]]> +]]>

                          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:

                          - ]]> +]]>

                          If compression processing fails after the new (compressed) stream has been established, the entity that detects the error SHOULD generate a stream error and close the stream:

                          @@ -148,7 +148,7 @@ - ]]> +]]> @@ -203,7 +203,7 @@ a natural-language description of the compression method the document that specifies or registers the compression method - ]]> +]]>

                          The registrant may register more than one compression method at a time, each contained in a separate <method/> element.

                          @@ -213,7 +213,7 @@ the ZLIB compression method RFC 1950 - ]]> +]]>                           @@ -245,7 +245,7 @@ - ]]> +]]> - ]]> +]]> diff --git a/xep-0140.xml b/xep-0140.xml index 67e40835..9c2cd973 100644 --- a/xep-0140.xml +++ b/xep-0140.xml @@ -71,13 +71,13 @@ - ]]> +]]> - ]]> +]]>

                          There are two steps to adding a member to a group, which SHOULD be performed in this order:

                          @@ -98,13 +98,13 @@ - ]]> +]]> - ]]> +]]>

                          (Naturally, a member of a shared group need not be informed of changes to the group, and an entity that is informed of changes to the group need not be a member of the group. However, in most applications a group member will be a pubsub subscriber and vice-versa.)

                          Now the admin publishes information about the member to the group node.

                          - ]]> +]]>

                          The member information is then delivered to all subscribers:

                          +]]>

                          Note: It is the receiving application's responsibility to add the newly-published roster item to the recipient's roster by following the protocols defined in XMPP IM. The receiving application SHOULD NOT prompt the recipient regarding whether or not to add the roster item, but if and only the roster item is received via pubsub (i.e., it SHOULD prompt the user when roster items are received from individual users and not via pubsub).

                           @@ -167,13 +167,13 @@ - ]]> +]]> - ]]> +]]>

                          (As noted, the group member need not be a pubsub subscriber, in which case the foregoing step may not be necessary.)

                          Now admin can remove the member from the shared group.

                          - ]]> +]]>

                          All remaining subscribers are then informed that the node has been deleted:

                          +]]>                           diff --git a/xep-0141.xml b/xep-0141.xml index a8ed7ac4..bad908fc 100644 --- a/xep-0141.xml +++ b/xep-0141.xml @@ -94,7 +94,7 @@ - ]]> +]]>

                          Note: Any newlines in the following examples are provided for the purpose of legibility only.

                          One of the simplest layout usages is to partition fields into pages. This is done by including one or more <page/> elements within the x:data form. Each <page/> element SHOULD possess a "label" attribute to label the page, MAY contain a <text/> child element for additional information, and SHOULD contain a <fieldref/> element for each field to be included in the page. To reference an x:data field, the <fieldref/> element's "var" attribute MUST be the same as the intended <field/> element's "var" attribute.

                          @@ -158,7 +158,7 @@ - ]]> +]]>

                          Note: The preceding example partitions the fields into three pages, labeled "Personal Information", "Community Activity", and "Plans and Reasonings".

                           @@ -222,7 +222,7 @@ - ]]> +]]>

                          Note: The preceding example demonstrates a layout similar to the previous example, but using three sections within one page instead of three pages.

                          As shown in the following example, sections may be nested to produce a more granular partitioning of fields.

                          - ]]> +]]>

                          Note: The preceding example partitions the fields into one page and three sections, with the first section being further partitioned into two sub-sections and one free-standing field reference.

                           @@ -392,7 +392,7 @@ - ]]> +]]>                           diff --git a/xep-0142.xml b/xep-0142.xml index f642723f..abf4ffaf 100644 --- a/xep-0142.xml +++ b/xep-0142.xml @@ -133,7 +133,7 @@ +-----------+ | Chat room | +-----------+ - ]]> +]]>

                          Packets are exchanged between the user and service to trigger state changes in the user. These packet exchanges are described next.

                          @@ -147,7 +147,7 @@ User Service | Join Response | |<-----------------------------| | | - ]]> +]]>

                          The user sends a join request to the workgroup service in order to join the workgroup queue. The workgroup service may either accept or reject the request. A user session (e.g. user@example.net/home) may have only one active join request. Subsequent, simultaneous joins MUST result in an error.

                          @@ -162,12 +162,12 @@ U: U: U: U: - ]]> +]]>

                          The request may contain application-specific meta-data to help the service determine queuing of the user or Data Forms data when submitting form information (definition of such data is out of scope for this document). In addition, the <join-queue> element MAY contain a standard <queue-notifications/> element, which indicates that the user would like to receive user status updates about their state in the queue.

                          A successful join results in a success response:

                          - ]]> +]]>

                          If the user indicated interest in their queue status information, the supported status updates MUST be sent by the server. Compliant implementations do not have to support any status update types. Status updates requested by the user and supported by the server MUST be pushed to the user by the service until the user departs or is invited to a chat room.

    @@ -212,7 +212,7 @@ S: - ]]> +]]>

    The following XML is another example where meta-data is sent by the user to assist the workgroup server in queuing and routing (naturally, the custom namespace that qualifies the <crm/> element in this example would be defined outside the context of this specification).

    - ]]> +]]>

    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.

    S: S: S:     - ]]> +]]>

    The &e406; error indicates that a data form is required. The user requests the required data form from the workgroup.

    S: S: S: - ]]> +]]>

    After presenting the form to the user and gathering the form data, the user submits the form data to the workgroup and the workgroup accepts it. The user is now in the queue.

    - ]]> +]]> @@ -318,19 +318,19 @@ Requester Service | Depart Response | |<-----------------------------| | | - ]]> +]]>

    The service notifies the user that they have been removed from the workgroup queue.

    +]]> U: U: - ]]> +]]>

    In the typical case, the sender is the user departing the queue. However, it is possible for other users (system administrators for example) to request that another user be removed from the queue. In this case, the jid of the user who is departing is included in the depart request:

    @@ -338,18 +338,18 @@ U: U: user@example.net/home U: U: - ]]> +]]>

    It is expected that implementations will determine who is allowed to remove other users from the queue based on an implementation specific permissions model. These administrator depart requests may result in &e401; errors (see error section). A user removing their own queue entry MUST NOT receive unauthorized errors (the workgroup service MUST NOT prevent a user from departing the queue).

    The sender of the depart request receives a successful result packet:

    - ]]> +]]>

    And the user who is departing receives a depart message (the user may not have been the sender of the request):

    S: S: - ]]> +]]>

    The user will not be in the queue after a response is received unless the error response code is &e401;.

    @@ -383,7 +383,7 @@ S: type='result'/> S: S: S: - ]]> +]]>

    An administrator removes a user from the workgroup queue support@workgroup.example.com. Notice that the depart-queue message is sent to the user that has left the queue.

    S: S: S: - ]]> +]]> @@ -418,7 +418,7 @@ User Service | User Status Response | |<-----------------------------| | | - ]]> +]]>

    The workgroup service pushes updates to the user as their queue status changes. Furthermore, the user may request their queue status at any time.

    User status updates are contained in a <queue-status/> element that updates the user on their queue position and estimated time. The position contained in a <position> sub-element is a non-negative integer indicating the number of queue entries that must be routed to an agent before the user is routed to an agent. A position of 0 (zero) indicates the user is currently being routed. Clients may use this information to display the current queue position to the user.

    @@ -431,7 +431,7 @@ S: 4 S: S: S: - ]]> +]]>

    Alternately the client may poll their position:

    @@ -443,7 +443,7 @@ S: 4 S: S: S: - ]]> +]]>
    @@ -470,7 +470,7 @@ User Service | User Invite | |<-----------------------------| | | - ]]> +]]>

    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.

    There are no defined error conditions for user invitations.

    @@ -490,7 +490,7 @@ S: S: S: S: - ]]> +]]>     @@ -507,7 +507,7 @@ S: | | |Agent | | Status | |Presence | +--------+ +---------+ - ]]> +]]>

    Once an agent has joined a workgroup and is available, the agent will receive offers to chat with users by the workgroup service. Chat offers will be made to the agent and the agent has the opportunity to accept or reject each offer. The workgroup service may also revoke an offer. For example, a service may revoke chat offers if the offer is not responded to within a certain period of time to ensure fast responses to user chat requests.

    Once an offer has been accepted, the agent must wait for a standard groupchat invitation from the workgroup service. The workgroup service may revoke the offer at this stage of the protocol as well. This enables workgroup services to send offers to several agents in parallel, and choose the 'best' agent that accepts. A diagram showing the agent workgroup sub-states and transitions is shown below:

    +-----------+ | Chat room | +-----------+ - ]]> +]]>

    Packets are exchanged between the agent and service to trigger state changes in the agent client. These packet exchanges are described next.

    @@ -545,7 +545,7 @@ Agent Service | Presence Update | |----------------------------->| | | - ]]> +]]>

    The agent must inform the workgroup of its presence by sending it a directed (not broadcast) presence update packet. Agent presence updates use standard XMPP presence with optional meta-data. However, there must always be an agent-status workgroup sub-element in the presence packet to indicate that the presence update relates to agent workgroup presence. Agent workgroup presence is designed to allow a separation between the agent's normal XMPP presence (server-managed via rosters) and their presence with the workgroup.

    @@ -553,7 +553,7 @@ U: U: count U: U: - ]]> +]]>

    Agent presence updates use standard XMPP presence packets and should contain the normal sub elements as needed (e.g. &SHOW;, &STATUS;, etc) and can be of type='unavailable' to indicate the agent is not available for workgroup routing or for receiving workgroup agent updates. The standard XMPP show states have specific meaning within the context of the workgroup protocol:

    @@ -260,7 +260,7 @@ INITIATOR RESPONDER id='tp2hd816' to='romeo@montague.lit/orchard' type='result'/> - ]]> +]]>

    Depending on the application type, a user agent controlled by a human user might need to wait for the user to affirm a desire to proceed with the session before continuing. When the user agent has received such affirmation (or if the user agent can automatically proceed for any reason, e.g. because no human intervention is expected or because a human user has configured the user agent to automatically accept sessions with a given entity), it returns a Jingle session-accept message. This message MUST contain a &TRANSPORT; element qualified by the 'urn:xmpp:jingle:transports:raw-udp:1' namespace, which SHOULD in turn contain one &CANDIDATE; element for each Raw UDP candidate generated by or known to the responder.

    - ]]> +]]>

    (Notice that the foregoing example includes two &CANDIDATE; elements, one for RTP and the other for RTCP.)

    The initiator then acknowledges the session acceptance.

    - ]]> +]]> @@ -317,14 +317,14 @@ INITIATOR RESPONDER - ]]> +]]>

    The other party then acknowledges termination of the session.

    - ]]> +]]>     @@ -337,7 +337,7 @@ INITIATOR RESPONDER type='get'> - ]]> +]]> - ]]> +]]>

    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.

    @@ -387,7 +387,7 @@ INITIATOR RESPONDER datagramXEP-0177 - ]]> +]]> @@ -448,7 +448,7 @@ INITIATOR RESPONDER - ]]> +]]> diff --git a/xep-0178.xml b/xep-0178.xml index 89551aa7..359de488 100644 --- a/xep-0178.xml +++ b/xep-0178.xml @@ -118,7 +118,7 @@ from='juliet@example.com' to='example.com' version='1.0'> - ]]> +]]>

  • Server replies with stream header.

    @@ -130,7 +130,7 @@ from='example.com' to='juliet@example.com' version='1.0'> - ]]> +]]>

  • Server advertises TLS stream feature, which might indicate that TLS is mandatory-to-negotiate.

    @@ -140,19 +140,19 @@ - ]]> +]]>

  • Client sends STARTTLS command to server.

    - ]]> +]]>

  • Server informs client to proceed.

    - ]]> +]]>

  • Server requests, and client presents, the client certificate during TLS negotiation.

    @@ -166,7 +166,7 @@ from='juliet@example.com' to='example.com' version='1.0'> - ]]> +]]>

  • Server replies with response stream header.

    @@ -178,7 +178,7 @@ from='example.com' to='juliet@example.com' version='1.0'> - ]]> +]]>

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

    @@ -190,7 +190,7 @@ ANONYMOUS - ]]> +]]>

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

    @@ -200,21 +200,21 @@ = - ]]> +]]>

  • If the client certificate contains more than one JID, then the client MUST include an authorization identity so that the server can determine which JID to use (this is shown in the following example by setting the XML character data of the <auth/> element to "anVsaWV0QGV4YW1wbGUuY29t", which is the base 64 encoding for "juliet@example.com").

    anVsaWV0QGV4YW1wbGUuY29t - ]]> +]]>

  • If the client certificate does not contain a JID, then the client MAY include an authorization identity, but only if it desires to be authorized as a JID other than the address specified during SASL negotiation; 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 "=").

    = - ]]> +]]>
    • @@ -225,40 +225,40 @@

    If (1) the certificate presented by the client contains only one valid XMPP address that corresponds to a registered account on the server and (2) the client did not pass an authorization identity in the SASL exchange, then the server SHOULD allow authentication and authorization of that JID.

    - ]]> +]]>

  • If the certificate contains more than one valid XMPP address that corresponds to a registered account on the server (e.g., because the server offers virtual hosting) and during the SASL exchange the client specified an authorization identity that corresponds to one of the JIDs presented in the client certificate, then the server SHOULD allow authentication and authorization of the JID specified as the authorization identity.

    - ]]> +]]>

    If no authorization identity is included, then the server SHOULD return a SASL failure case of <invalid-authzid/> and close the stream.

    - ]]> +]]>

  • If the certificate does not contain an XMPP address, then the server MAY attempt to determine if there is a registered account associated with the user, for example by performing an LDAP lookup based on the Common Name or other information presented by the client in the certificate; if such a JID mapping is successful and the mapped JID matches the authorization identity provided, then the server SHOULD allow authentication and authorization of that mapped JID.

    - ]]> +]]>

    If JID mapping is unsuccessful, then the server SHOULD return a SASL failure condition of <not-authorized/> and close the stream.

    - ]]> +]]>

    If JID mapping is successful but the mapped JID does not match the authorization identity provided (if any), then the server SHOULD return a SASL failure condition of <invalid-authzid/> and close the stream.

    - ]]> +]]>
    • @@ -280,7 +280,7 @@ from='conference.example.org' to='example.com' version='1.0'> - ]]> +]]>

  • Server2 replies with stream header.

    @@ -292,7 +292,7 @@ from='example.com' to='conference.example.org' version='1.0'> - ]]> +]]>

  • Server2 advertises TLS stream feature, which might indicate that TLS is mandatory-to-negotiate.

    @@ -302,19 +302,19 @@ - ]]> +]]>

  • Server1 sends STARTTLS command to Server2.

    - ]]> +]]>

  • Server2 informs Server1 to proceed.

    - ]]> +]]>

  • Server2 requests, and Server1 presents, Server1's certificate during TLS negotiation.

    @@ -334,7 +334,7 @@ from='conference.example.org' to='example.com' version='1.0'> - ]]> +]]>
    • @@ -348,7 +348,7 @@ from='example.com' to='conference.example.org' version='1.0'> - ]]> +]]>

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

    @@ -358,14 +358,14 @@ EXTERNAL - ]]> +]]>

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

    = - ]]> +]]>

    Interoperability Note: Previous versions of this specification stated that the receiving server always relied on the connecting server's inclusion of the authorization identity. Even though this is no longer required, the connecting server SHOULD include the authorization identity for backward compability.

  • @@ -375,7 +375,7 @@

    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.

    - ]]> +]]>

    Implementation Note: If Server2 needs to assign an authorization identity during SASL negotiation, it SHOULD use the value of the 'from' attribute of the stream header sent by Server1.

  • @@ -385,7 +385,7 @@ - ]]> +]]>
    • diff --git a/xep-0179.xml b/xep-0179.xml index 4d93bce1..14aa5cfb 100644 --- a/xep-0179.xml +++ b/xep-0179.xml @@ -94,7 +94,7 @@ - ]]> +]]> @@ -102,7 +102,7 @@

    As described in XEP-0166, to provisionally accept the session initiation request, the target entity returns an IQ-result:

    - ]]> +]]>

    To accept the IAX transport method, the target entity MUST send a &JINGLE; element with an action of 'transport-accept', specifying the transport method desired.

    This &TRANSPORT; element MUST include two &CANDIDATE; element per channel, whose 'ip' and 'port' attributes specify the IP address and port number of the candidate that the initiator has reason to believe will be most likely to succeed for that channel. The two candidates are the local and remote one. NAT type doesn't matter because the IAX protocol by itself addresses the problem of NAT traversal. We differentiate the two candidates with name attribute.

    The transport attributes are:

    @@ -140,7 +140,7 @@     - ]]> +]]>

    The syntax and semantics informational message payloads specific to the IAX transport method will be defined in a future version of this specification.

    @@ -183,7 +183,7 @@ Jingle IAX sessions. XEP-0179 - ]]> +]]>     diff --git a/xep-0180.xml b/xep-0180.xml index e73f8085..39b9507e 100644 --- a/xep-0180.xml +++ b/xep-0180.xml @@ -170,7 +170,7 @@ - ]]> +]]>

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

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

    @@ -211,7 +211,7 @@

    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:

    - ]]> +]]>

    Note: The parameter names are effectively guaranteed to be unique, since &IANA; maintains a registry of SDP parameters (see <http://www.iana.org/assignments/sdp-parameters>).

    @@ -243,7 +243,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/>:

    - ]]> +]]>

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

    - ]]> +]]>

    If the responder wishes to accept the content definition, it MUST send a content-accept action to the initiator, which SHOULD include a list of the payload types that it can send and/or receive. The list that the responder sends MAY include any payload types (not a subset of the payload types sent by the initiator) but SHOULD retain the ID numbers specified by the initiator. The order of the &PAYLOADTYPE; elements indicates the responder's preferences, with the most-preferred types first.

    - ]]> +]]>

    The initiator acknowledges the 'content-accept' with an empty IQ result:

    - ]]> +]]>

    After successful transport negotiation (for the ICE-UDP method, see XEP-0176), the responder then accepts the session:

    - ]]> +]]>

    And the initiator acknowledges session acceptance:

    - ]]> +]]>

    Note: For more examples, see XEP-0167.

    @@ -356,26 +356,26 @@

    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:

    - ]]> +]]>

    In the context of Jingle video sessions, the <media> is "video", the <port> is the preferred port for such communications (which may be determined dynamically), the <transport> is whatever profile is negotiated via the 'profile' attribute of the &CONTENT; element in the Jingle negotiation (e.g., "RTP/AVT"), and the <fmt list> is the payload-type ID.

    For example, consider the following static payload-type:

    - ]]> +]]>

    That Jingle-formatted information would be mapped to SDP as follows:

    +]]>

    If the payload type is dynamic (payload-type IDs 96 through 127 inclusive), it SHOULD be mapped to an SDP media field plus an SDP attribute field named "rtpmap".

    For example, consider a VC-1 payload such as that described in &rfc4425;:

    - ]]> +]]>

    That Jingle-formatted information would be mapped to SDP as follows:

    +]]>

    As noted, if additional parameters are to be specified, they shall be represented as attributes of the <payload-type/> element or its child <parameter/> element, as in the following example.

    @@ -385,14 +385,14 @@ a=rtpmap:98 vc1/90000     - ]]> +]]>

    That Jingle-formatted information would be mapped to SDP as follows:

    +]]> @@ -420,7 +420,7 @@ delivery-method=inline; configuration=somebase16string; type='get'> - ]]> +]]> - ]]> +]]>

    Naturally, support may also be discovered via the dynamic, presence-based profile of service discovery defined in &xep0115;.

     @@ -478,7 +478,7 @@ delivery-method=inline; configuration=somebase16string; lossy XEP-0180 - ]]> +]]> @@ -532,7 +532,7 @@ delivery-method=inline; configuration=somebase16string; - ]]> +]]> - ]]> +]]> diff --git a/xep-0181.xml b/xep-0181.xml index b808bf4c..ee6f5c5b 100644 --- a/xep-0181.xml +++ b/xep-0181.xml @@ -114,7 +114,7 @@ code='0-9,#,*,A-D' duration='milliseconds' volume='0-63'/> - ]]> +]]>

    The <dmtf/> element MUST be empty.

    The attributes of the <dmtf/> element are as follows.

    @@ -159,14 +159,14 @@ volume='42'/> - ]]> +]]>

    The receiving entity MUST send an IQ result if it can process the DTMF:

    - ]]> +]]>

    If the receiving entity does not support this protocol, it MUST return a &unavailable; stanza error.

    - ]]> +]]>

    If the receiving entity supports this protocol but does not understand the specified code, it MUST return a &feature; stanza error.

    - ]]> +]]>

    If the receiving entity is using or wishes to use a different method for exchanging DTMF events (e.g., the methods specified in &rfc2833; or its successor &rfc4733;), it MUST return a ¬acceptable; stanza error.

    - ]]> +]]> @@ -280,7 +280,7 @@ - ]]> +]]>

    Thanks to Diana Cionoiu, Olivier Crête, Robert McQueen, and Paul Witty for their feedback. Several sentences were borrowed from RFC 4733.

    diff --git a/xep-0182.xml b/xep-0182.xml index ab43a689..73da535f 100644 --- a/xep-0182.xml +++ b/xep-0182.xml @@ -65,7 +65,7 @@ - ]]> +]]>

    Although the inclusion of application-specific error conditions introduces a great deal of flexibility, it may also lead to confusion regarding possible conditions. Therefore, this document defines a registry of application-specific error conditions, to be maintained by the ®ISTRAR;. In addition, this document registers a namespace of 'urn:xmpp:errors' as a fallback namespace for generalized error conditions that are not specific to a particular protocol (e.g., <stanza-too-big/> as a particular form of the ¬acceptable; condition).

     @@ -81,7 +81,7 @@ a natural-language description of the error condition the document in which the condition is specified - ]]> +]]>

    The registrant may register more than one condition at a time, each contained in a separate <condition/> element.

    diff --git a/xep-0183.xml b/xep-0183.xml index d2f0045d..7ec344b2 100644 --- a/xep-0183.xml +++ b/xep-0183.xml @@ -61,7 +61,7 @@ - ]]> +]]>

    The attributes of the <candidate/> element are as follows: