diff --git a/xep-0204.xml b/xep-0204.xml index 18961b27..30125b6f 100644 --- a/xep-0204.xml +++ b/xep-0204.xml @@ -571,10 +571,10 @@ A CDO client can query the server to determine the specific state of a particula ]]> -Note an event type of info. This requires all attributes for the data-sync element and items be present +

Note an event type of info. This requires all attributes for the data-sync element and items be present

-In some cases a client may be interested in the state of all CDOs belonging to a specific endpoint - for example a chat room. +

In some cases a client may be interested in the state of all CDOs belonging to a specific endpoint - for example a chat room.

@@ -595,18 +595,17 @@ In some cases a client may be interested in the state of all CDOs belonging to a type="cdo:Location" event="info" xmlns="http://www.xmpp.org/extensions/xep-0204.html#ns"/> - ... - + ... ]]> -Note the value of the uuid for the cdo tag above uses an asterisk (*) to indicate all CDOs +

Note the value of the uuid for the cdo tag above uses an asterisk (*) to indicate all CDOs

If desired, Client A can then query the Server for the details on the state of a specific CDO using the protocol described earlier.

-When two endpoints (client A and client B) wish to create a new CDO. Each client and server MUST follow this algorithm: +

When two endpoints (client A and client B) wish to create a new CDO. Each client and server MUST follow this algorithm:

]]> -Here client A, has created a packetID and set event=create in both <data-sync> and <item>. The version MUST be set to zero +

Here client A, has created a packetID and set event=create in both <data-sync> and <item>. The version MUST be set to zero

Next, the message is intercepted by Server X. Server X is the IM server that both clients are connected to. When the server receives the message, it MUST increment the version number and assign a uuid for both the <data-sync> and <item>. Once processed @@ -675,10 +674,10 @@ Server X MUST send a copy of the message back to client A as a receipt that the ]]> -Once this is completed, both clients have a synchronized CDO message with a uuid and a version number assigned by the server. +

Once this is completed, both clients have a synchronized CDO message with a uuid and a version number assigned by the server.

 -When client A wishes to create a new Item on an existing CDO, he sends the following information to client B +

When client A wishes to create a new Item on an existing CDO, he sends the following information to client B

]]> -Once this is completed, both clients have a synchronized CDO message with a new item. The new item has been assigned a uuid and a version number by the server. +

Once this is completed, both clients have a synchronized CDO message with a new item. The new item has been assigned a uuid and a version number by the server.

 -When client A wishes to update an item on an existing CDO, he sends the following information to client B +

When client A wishes to update an item on an existing CDO, he sends the following information to client B

]]> -Once this is completed, both clients have a synchronized CDO message with an updated item. The updated item has the version number incremented. +

Once this is completed, both clients have a synchronized CDO message with an updated item. The updated item has the version number incremented.

There are two types of behaviors associated with an item update: inclusive and exclusive. For an inclusive update, the content of the item element @@ -832,35 +831,35 @@ Once this is completed, both clients have a synchronized CDO message with an upd Assume that client A has created a CDO cdo_1. This CDO has an item item_1 with the attribute named attr_1 set. If A wants to update item_1 with a value for the attribute named attr_2 without destroying the previously set value for attr_1, the following data synchronization packets are equivalent:

- 

-  
     old value
     new value
   
 
-     ]]>
- 

+        
-  
        new value
-   
+  
 
-     ]]>
+]]> -When client A wishes to delete an item on an existing CDO, he sends the following information to client B +

When client A wishes to delete an item on an existing CDO, he sends the following information to client B

]]> -Once this is completed, both clients have a synchronized CDO message with a deleted item. +

Once this is completed, both clients have a synchronized CDO message with a deleted item.

@@ -990,7 +989,7 @@ message back to client A as a receipt that the message has been processed by Ser ]]> -Once this is completed, both clients have retired (deleted) the CDO. +

Once this is completed, both clients have retired (deleted) the CDO.

 @@ -1590,12 +1589,12 @@ containing at least one overlapping item. When this occurs, the first packet to reported back to the client of the second packet MAY be extended to describe the notional conflict. This additional error information is meant to facilitate collaboration between the clients.

-The additional error information provide includes: +

The additional error information provide includes:

+
  • The resource identifier of the client originating the data sync packet with which this error conflicts.
    • +
  • The timestamp of when the originating data sync packet was executed.
    • +
  • The item element of the originating data sync packet with which this error conflicts.
    • + diff --git a/xep-0209.xml b/xep-0209.xml index 3e45177c..5dcdd0e9 100644 --- a/xep-0209.xml +++ b/xep-0209.xml @@ -54,11 +54,11 @@     - The metacontact storage is achieved through the use of private data storage. In order to achieve the resilience described above, the private storage of each account is used to store the metacontact membership of Jids in the roster of that account. The metacontacts are stored within private data storage of each account simply as an unordered collection of meta tags. +

    The metacontact storage is achieved through the use of private data storage. In order to achieve the resilience described above, the private storage of each account is used to store the metacontact membership of Jids in the roster of that account. The metacontacts are stored within private data storage of each account simply as an unordered collection of meta tags.

    ]]> - In this example, the 'jid' specifies that the roster entry 'romeo@montague.net' is a member of a metacontact. The 'tag' provides a key for a metacontact; in this example all metacontacts with a tag of 'd93nov' (across all accounts) refer to the same entity. The 'order' denotes the priority of this Jid over other Jids within the metacontact, with it being preferable to use Jids with higher priority (this is roughly analogous to the 'priority' on presence stanzas when a Jid has multiple online resources in XMPP). +

    In this example, the 'jid' specifies that the roster entry 'romeo@montague.net' is a member of a metacontact. The 'tag' provides a key for a metacontact; in this example all metacontacts with a tag of 'd93nov' (across all accounts) refer to the same entity. The 'order' denotes the priority of this Jid over other Jids within the metacontact, with it being preferable to use Jids with higher priority (this is roughly analogous to the 'priority' on presence stanzas when a Jid has multiple online resources in XMPP).

    Below are example of setting and retrieving metacontacts for an account. When using metacontacts across multiple accounts, the steps are identical and the 'tag' attributes and used across accounts (that is: when the same tag is used for multiple contacts, all entries with the tag are merged into a single metacontact whether they reside on the same of different accounts).

    @@ -114,7 +114,6 @@     @@ -122,10 +121,10 @@ - Creation of a metacontact is uncomplicated; the simple addition of meta tag with a common tag results in a new metacontact. +

    Creation of a metacontact is uncomplicated; the simple addition of meta tag with a common tag results in a new metacontact.

     - Similarly, to remove a metacontact all that is required is to remove the meta tags which contribute to the metacontact. +

    Similarly, to remove a metacontact all that is required is to remove the meta tags which contribute to the metacontact.

    Although it is unavoidable that multiple contacts within a metacontact MAY have the same order (due to potentially unavailable information from other accounts), clients SHOULD NOT apply the same order to multiple members of the same metacontact where it is possible to avoid it. If multiple members of a metacontact have the same order, the behaviour is dependent upon the client; it MAY apply rules itself to determine which member to communicate with (based upon presence, recent activity or other methods) it MAY present the user with the option to sort the members such that the orders are again unique, or it MAY employ another appropriate action.

    diff --git a/xep-0214.xml b/xep-0214.xml index 7607e41e..cbdd47b1 100644 --- a/xep-0214.xml +++ b/xep-0214.xml @@ -12,7 +12,7 @@ 0214 Deferred Standards Track - Standards JIG + Standards Council XMPP Core @@ -98,16 +98,11 @@     -

    The following use cases describe tasks which are already covered by &xep0060; in a more generic context. These tasks are again being provided here in order to demonstrate the functionality provided by this protocol and convey the structure and syntax of the file listing. As a result of this close relationship, many details of PubSub are omitted here for brevity. Consult &xep0060; and &xep0248; for the full specification of node and user management commands as well as their server responses.

    - - -

    Juliet wishes to make her sonnets available for retrieval by the public. She creates a Root Pubsub Collection Node which will contain her file listing:

    - - @@ -140,11 +135,9 @@ - ]]> - +]]>

    Juliet also wishes to add a subsection for her sonnets about Romeo. She creates another PubSub Collection Node under the Root Node:

    - - @@ -178,14 +171,11 @@ - ]]> - +]]>     -

    Romeo wishes to view all of Juliet's shared sonnets. To do this, Romeo subscribes to the Root Collection Node:

    - - @@ -202,14 +192,11 @@ - ]]> - +]]>     -

    Juliet has just finished a new sonnet and wishes to announce its availability on her File Listing. She adds the sonnet as a new PubSub Node stored in her Collection Node, then inserts a first revision of her sonnet as an Item within that Node:

    - - @@ -311,8 +298,7 @@ -]]> - +]]>

    The Item ID is set to 1, signifying the first revision for this file. Subsequent revisions/items will have incremented ID values, like one would see in a versioning system such as CVS or SVN. Implementations MAY follow this convention, but are not required to do so. For example, a given implementation may instead mark revisions using version numbers ("Beta 1", "6.2", etc) or use other arbitrary strings. However, no two revisions of a given file may share the same ID.

    Node IDs MAY take the form of "path/to/file.ext", rather than the randomized string "a6190c5d38e22452041d1c5798eff3f5" provided in the above use case. For example, Juliet's sonnet MAY instead use a Node ID of "juliets_sonnets/sonnet.txt", as long as this ID is unique within the PubSub server. Randomized strings are used in this document to illustrate that Node IDs SHOULD NOT be used for providing information about files.

    Here is a listing of the possible metadata in a file revision (Item), each field is OPTIONAL:

    @@ -326,8 +312,7 @@ MirrorsA list of mirrors; their properties are defined below. If no downloads are available, MAY be left empty or removed entirely.

    Because Romeo is now subscribed, he receives notice of Juliet's addition:

    - - + @@ -374,16 +359,14 @@ -]]> - +]]>

    The above examples give a listing of several possible file transfer protocols in example configurations. Only the sipub mirror type is REQUIRED; the other types are OPTIONAL. Here is a full listing of those protocols and their available settings:

    - - + @@ -419,7 +402,7 @@

    Juliet has revised her sonnet and wishes to publish the new version, while still leaving the original copy available for retrieval. To do this, she inserts a new Item, representing her new revision, into the file's Node:

    - @@ -458,14 +441,11 @@ - ]]> - +]]> -

    Juliet has uploaded a copy of her revised sonnet to a new mirror, and wishes to let her subscribers know about this secondary source. She is able to do this by modifying the revision in question to include a reference to her website, overwriting the existing mirrors in the Item with an updated list:

    - - @@ -501,11 +481,10 @@ - ]]> + ]]>

    Juliet now wishes to allow others to contribute to her sonnet collection. She gives owner access for the entire Listing to Romeo, and publisher access to her nurse:

    - - @@ -516,11 +495,11 @@ - ]]> +]]>

    Romeo uses his owner access to remove the older revision of Juliet's sonnet:

    - @@ -530,18 +509,17 @@ - ]]> +]]>

    Other deletion, modification, and user management operations are available as described in &xep0060; and &xep0248;.

     -

    Romeo is interested in seeing what files Juliet has made available. To do this, Romeo sends a request to Juliet for repositories which she is associated with:

    - @@ -549,11 +527,11 @@ - ]]> +]]>

    Juliet responds with a list of PubSub nodes where she has published files or which she believes would be interesting to Romeo. If no such locations exist, Juliet SHOULD respond with an empty list.

    - @@ -564,18 +542,17 @@ - ]]> +]]>

    After browsing Juliet's repository, Romeo has chosen to download her sonnet. The most recent revision of this file contains a listing of available mirrors, and Romeo sees that one of them is an SI stream. Romeo sends an SI request to that mirror:

    - - - ]]> + ]]>

    The rest of the negotiation and file transfer occurs as described in &xep0137;.

     diff --git a/xep-0220.xml b/xep-0220.xml index 035b7323..22027c94 100644 --- a/xep-0220.xml +++ b/xep-0220.xml @@ -52,20 +52,20 @@ 0.15 - psa/ph 2013-08-27 + psa/ph

    Addressed Last Call feedback and made editorial improvements.

         0.14 - ph 2012-08-21 + ph

    Updated the Security Considerations to describe the 'Unsolicited Dialback Attack' and added recommendations to avoid this attack.

         0.13 - ph/psa 2012-08-08 + ph/psa
    • Allowed same SRV target in multiplexing business
      • diff --git a/xep-0224.xml b/xep-0224.xml index 280273f1..644ce35c 100644 --- a/xep-0224.xml +++ b/xep-0224.xml @@ -91,15 +91,14 @@ ]]> -

      The following rules apply to generating and processing of the attention extension. -

        -
      1. Before sending an attention message stanza, the client SHOULD confirm support for it in the other client as described under Determining Support.
        2. -
      2. The message stanza containing the attention extension MAY contain a body and/or other extensions, which is to be displayed along with executing the attention event.
        3. -
      3. In message stanzas containing either &xep0203; data, attention extensions MUST be ignored, since the attention request is an instant event which SHOULD NOT be replayed after a delay.
        4. -
      4. Messages containing an attention extension SHOULD use the headline message type to avoid offline storage.
        5. -
      5. The attention extension MUST NOT be sent in &IQ; stanzas, since use of this feature is part of a messaging conversation.
        6. -
      -

      +

      The following rules apply to generating and processing of the attention extension.

      +
        +
      1. Before sending an attention message stanza, the client SHOULD confirm support for it in the other client as described under Determining Support.
        2. +
      2. The message stanza containing the attention extension MAY contain a body and/or other extensions, which is to be displayed along with executing the attention event.
        3. +
      3. In message stanzas containing either &xep0203; data, attention extensions MUST be ignored, since the attention request is an instant event which SHOULD NOT be replayed after a delay.
        4. +
      4. Messages containing an attention extension SHOULD use the headline message type to avoid offline storage.
        5. +
      5. The attention extension MUST NOT be sent in &IQ; stanzas, since use of this feature is part of a messaging conversation.
        6. +

      If an entity wishes to receive the attention extension, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:attention:0":

      diff --git a/xep-0226.xml b/xep-0226.xml index f9303178..7d4a15de 100644 --- a/xep-0226.xml +++ b/xep-0226.xml @@ -20,7 +20,6 @@ profiles &infiniti; &stpeter; - 0.3 2008-11-05 diff --git a/xep-0244.xml b/xep-0244.xml index 06f8edfa..4dd74de6 100644 --- a/xep-0244.xml +++ b/xep-0244.xml @@ -181,16 +181,14 @@ if (function instanceof IoDataFunction) { ]]> -
    Protocol DescriptionRef AddressPort (default) UserPass
    sipub (REQUIRED)
    sipub (REQUIRED) OPTIONALN/A N/AN/A N/AN/A
    - - - - - - - - - +
    Transaction TypePurposeAssociated Ad-Hoc CommandREQUIRED for generic XEP compatibilityContained Elements
    + + + + + + + @@ -221,16 +219,14 @@ if (function instanceof IoDataFunction) {
    Transaction TypePurposeAssociated Ad-Hoc CommandREQUIRED for generic XEP compatibilityContained Elements
    io-schemata-get To request the schemata of input and output.
    - - - - - - - - - - +
    Transaction TypePurposeAssociated Ad-Hoc Command status valueREQUIRED for generic XEP compatibilityContained Elements
    + + + + + + + @@ -281,16 +277,14 @@ if (function instanceof IoDataFunction) {

    Commands (= remote procedures) executed with Ad-Hoc Commands and IO Data SHOULD NOT keep the requester in an uncertain state. This means the responder SHOULD respond to the requester always as fast as possible. Thereby the requester acquires the sessionid. (As some remote procedures/calculations are cost-intensive and/or time-consuming the requester MUST "save" this sessionid for the case a network problem occurs.)

    The Ad-Hoc Command logic applied for the IO Data data container should be associated with the following rules and keywords:

    -
    Transaction TypePurposeAssociated Ad-Hoc Command status valueREQUIRED for generic XEP compatibilityContained Elements
    io-schemata-result To return the schemata of input and output.
    - - - - - - - - - +
    Ad-Hoc CommandKeywordAssociated Transaction TypeSubsequently allowed commandsStatus description
    + + + + + + + diff --git a/xep-0245.xml b/xep-0245.xml index 54b6a481..255ac5e3 100644 --- a/xep-0245.xml +++ b/xep-0245.xml @@ -68,7 +68,7 @@ ]]>

    Each recipient's client would then show the message with a special presentation, such as:

    -* Atlas shrugs in disgust +* Atlas shrugs in disgust

    If the receiving client does not find a match on the string "/me " in the first four characters of the message body, it SHOULD NOT present the text in a special way. For example, the following message bodies do not match:

    &xep0045; rooms send XMPP presence stanzas when people leave and join the room, and receiving clients typically show these presence changes as the equivalent of in-room messages, such as the following transformation of a presence stanza of type unavailable:

    -*** Atlas has left the room +*** Atlas has left the room

    A sender could attempt to spoof such a leave message by sending an XMPP groupchat message stanza whose body text is "/me has left the room". Although the presentation of presence joins and leaves is determined by the receiving client and therefore such a notification cannot be universally spoofed for all receivers, a client SHOULD differentiate between presence notifications and /me commands (e.g., with different colors and different prepended characters, such as several asterisks for presence notifications and one asterisk for /me commands).

    diff --git a/xep-0248.xml b/xep-0248.xml index def51f91..5d89640a 100644 --- a/xep-0248.xml +++ b/xep-0248.xml @@ -77,19 +77,29 @@
    Collection Node
    A type of node that contains other nodes but no published items (c.f. Leaf Node).
    +     +
    Leaf Node
    A type of node that contains published items but no other nodes (c.f. Collection Node).
    +     +
    Node Graph
    The network of nodes emitting from a given node which contains all its descendants.
    +     +
    Root Node
    An anonymous collection node used as the de facto beginning of a service's node graph.
    +     +
    Subscription Depth
    How deep the collection node graph will be traversed when determining whether notifications will be sent. May be any integer, 0 or greater, or "all".
    +     +
    Subscription Type
    The type of notification, either "nodes", "items", or "all" which the subscriber is interested in.
     diff --git a/xep-0252.xml b/xep-0252.xml index 71430b77..2fae41e6 100644 --- a/xep-0252.xml +++ b/xep-0252.xml @@ -101,23 +101,23 @@ Content-Length: 0

    Connection managers MUST make the following changes to convert their responses to Script Syntax:

    -
      -

    1. Certain characters within the <body/> element MUST be replaced according to the rules for escaping characters within strings defined by ECMAScript. The necessary substitutions are summarised in the table below.

      -
    Ad-Hoc CommandKeywordAssociated Transaction TypeSubsequently allowed commandsStatus description
    execute Get Schemata
    - - - - - - - -
    CharacterUnicode Code Point ValueEscape sequence
    "U+0022\"
    Line Feed (New Line)U+000A\n
    Carriage ReturnU+000D\r
    Line SeparatorU+2028\u2028
    Paragraph SeparatorU+2029\u2029
    \U+005C\\
    -

    Each Unicode format-control character (i.e., the characters in category "Cf" in the Unicode Character Database, e.g., LEFT-TO-RIGHT MARK or RIGHT-TO-LEFT MARK) MUST also be substituted by its Unicode escape sequence (e.g. \u200e or \u200f).

    -

  • The following eight characters MUST be prepended to the <body/> element: _BOSH_("

    • -

  • The following two characters MUST be appended to the <body/> element: ")

    • -

  • If the client request does not possess a 'content' attribute, then the HTTP Content-Type header of responses MUST be either "text/javascript; charset=utf-8" or "application/x-javascript; charset=utf-8".

    • -

  • Include extra HTTP headers to prevent caching or storage by any intermediary.

    • - +

    1. Certain characters within the <body/> element MUST be replaced according to the rules for escaping characters within strings defined by ECMAScript. The necessary substitutions are summarised in the table below.

    + + + + + + + + +
    CharacterUnicode Code Point ValueEscape sequence
    "U+0022\"
    Line Feed (New Line)U+000A\n
    Carriage ReturnU+000D\r
    Line SeparatorU+2028\u2028
    Paragraph SeparatorU+2029\u2029
    \U+005C\\
    +

    Each Unicode format-control character (i.e., the characters in category "Cf" in the Unicode Character Database, e.g., LEFT-TO-RIGHT MARK or RIGHT-TO-LEFT MARK) MUST also be substituted by its Unicode escape sequence (e.g. \u200e or \u200f).

    +

    2. The following eight characters MUST be prepended to the <body/> element:

    + _BOSH_(" +

    3. The following two characters MUST be appended to the <body/> element:

    + ") +

    4. If the client request does not possess a 'content' attribute, then the HTTP Content-Type header of responses MUST be either "text/javascript; charset=utf-8" or "application/x-javascript; charset=utf-8".

    +

    5. Include extra HTTP headers to prevent caching or storage by any intermediary.

    Note: All line breaks in the bodies of the HTTP responses in the following two examples are included only to improve readability. In practice there MUST be no line breaks.

    -

    Information about location references in the entity's surrounding, and, if available, the entity's own geodetic coordinates, are provided by the entity and propagated on the network by the entity's associated application (usually a client). The information is structured by means of a <locationquery/> element that is qualified by the 'urn:xmpp:locationquery:0' namespace and nested with in a <iq> element with type set to get. The location result is provided by the location server and returned to the client in a <iq> element with type set to result. The location result is structured by means of a <geoloc/> element that is qualified by the 'http://jabber.org/protocol/geoloc' namespace (see XEP-0080).

    +

    Information about location references in the entity's surrounding, and, if available, the entity's own geodetic coordinates, are provided by the entity and propagated on the network by the entity's associated application (usually a client). The information is structured by means of a <locationquery/> element that is qualified by the 'urn:xmpp:locationquery:0' namespace and nested with in a <iq> element with type set to get. The location result is provided by the location server and returned to the client in a <iq> element with type set to result. The location result is structured by means of a <geoloc/> element that is qualified by the 'http://jabber.org/protocol/geoloc' namespace (see XEP-0080).

    - + - - + - + - + - + - + - + @@ -443,48 +442,48 @@ - + - + - + - + - + - + - + - + - + - +
    Element Name Datatype Definition ExampleNotes
    timestamp xs:datetime UTC time-stamp (MUST conform to the DateTime profile of &xep0082;). 2004-02-19T21:12Z Optional. If individual location references contain own timing information, this time-stamp shall represent GPS time only, otherwise it shall represent all provided info in the query. If not set, the server may assume current time.
    publish xs:boolean A flag specifying whether or not the server should publish the location result to subscribers of the submitting user's XEP-0080 compatible geoloc pub-sub node instead of returning it directly to the submitting user. true Optional. If present and "true", the server shall publish the entity's location details whenever it changes (suitable for periodic queries) and respond to the query with an empty <iq> stanza with type set to "result". If not specified or "false" the server shall return the location results to the submitting user in the form of a geoloc stanza (XEP-0080) embedded in a <iq> with type set to "result". Default is "false"
    lat xs:decimal Latitude in decimal degrees @@ -428,14 +427,14 @@ 39.75 Required if no location references present, otherwise optional. If present, this shall also be present in the result stanza. If not present, the location server SHOULD estimate a value based on submitted reference data and return with result stanza. The location server is free to decide if the value of this field should be piped directly through to result, or if it should be modified based on reference data or time history information. For instance: if the entity is indoors, the GPS signal will be inaccurate and unstable over time. If wifi references are submitted, the location server may decide that the entity is inside a known building, and return the latitude of this instead.
    lon xs:decimal Longitude in decimal degrees East -104.99See notes for latSee notes for lat
    alt xs:decimal Altitude in meters above or below sea levelOptional. If present, this shall also be present in the result stanza with identical value.
    bearing xs:decimal GPS bearing (direction in which the entity is heading to reach its next waypoint), measured in decimal degrees relative to true north See notes for altSee notes for alt
    datum xs:string GPS datum (See XEP-0080) See notes for altSee notes for alt
    accuracy xs:decimal Horizontal GPS accuracy in meters 10See notes for latSee notes for lat
    speed xs:decimal The speed at which the entity is moving, in meters per second 52.69See notes for altSee notes for alt
    references locationquery:reference A list of identifiable location references observed by the entity Required if no lat and lon values specified, otherwise optional. See Table 2 for type definition.Required if no lat and lon values specified, otherwise optional. See Table 2 for type definition.
    - + @@ -492,28 +491,28 @@ - + - + - + - + - + @@ -523,22 +522,22 @@
    Element Name Datatype DefinitionNotes
    id xs:stringA world-wide unique reference identifier. This SHALL be composed as follows:

    For cell towers: "MCC:MNC:LAC:CID" where MCC is the mobile country code Values of Mobile Country Codes (MCC) are specified by Annex to ITU Operational Bulletin No. 897 – 1.XII.2007.), MNC is the network carrier code, LAC is the area code and CID is the cell ID.

    For wireless access points and Bluetooth devices: The device MAC address.

    For IP addresses: the IP address itself (either IPv4 or IPv6).    		A world-wide unique reference identifier. This SHALL be composed as follows: For cell towers: "MCC:MNC:LAC:CID" where MCC is the mobile country code Values of Mobile Country Codes (MCC) are specified by Annex to ITU Operational Bulletin No. 897 – 1.XII.2007.), MNC is the network carrier code, LAC is the area code and CID is the cell ID. For wireless access points and Bluetooth devices: The device MAC address. For IP addresses: the IP address itself (either IPv4 or IPv6). 207:02:12643:78596 Required
    type xs:string Reference type as maintained in the registry specified under Reference Types Registry "cell" Required.
    signalstrength xs:int Reference signal strength in dBM. Only appliccable to actively transmitting references (cell towers, wifi access points, Bluetooth devices) -64 Optional.
    timestamp xs:datetime UTC time-stamp (MUST conform to the DateTime profile of &xep0082;).
    - + - + - + - + @@ -546,15 +545,15 @@ - + - + - + @@ -562,7 +561,7 @@ - + @@ -570,14 +569,14 @@ - + - + - + @@ -585,15 +584,15 @@ - + - + - + @@ -601,16 +600,16 @@ - + - + - + @@ -618,15 +617,15 @@ - + - + - + @@ -634,7 +633,7 @@ - + @@ -642,7 +641,7 @@ - + @@ -650,15 +649,15 @@ - + - + - + @@ -666,7 +665,7 @@ - + @@ -674,15 +673,15 @@ - + - + - + @@ -694,7 +693,7 @@
    Element Name Datatype Definition Example Notes
    alt xs:decimal Altitude in meters above or below sea level 1609Piped directly through from query alt field if set.Piped directly through from query alt field if set.
    area xs:string A named area such as a campus or neighborhood
    bearing xs:decimal GPS bearing (direction in which the entity is heading to reach its next waypoint), measured in decimal degrees relative to true north Piped directly through from query bearing field if set.Piped directly through from query bearing field if set.
    building xs:string A specific building on a street or in an area
    country xs:string The nation where the user is located
    datum xs:string GPS datum (See notes for XEP-0080) Piped directly through from query datum field if set.Piped directly through from query datum field if set.
    description xs:string A natural-language name for or description of the locationIf location is mapped to a place in a place oriented service, this should hold the place description.
    accuracy xs:decimal Horizontal GPS accuracy in meters 10Piped directly through from query accuracy field or estimated by location server using based on the other information in query and, if possible, differences between several queries over time.Piped directly through from query accuracy field or estimated by location server using based on the other information in query and, if possible, differences between several queries over time.
    floor xs:string A particular floor in a building
    lat xs:decimal Latitude in decimal degrees North 39.75Piped directly through from query lat field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.Piped directly through from query lat field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.
    locality xs:string A locality within the administrative region, such as a town or city
    lon xs:decimal Longitude in decimal degrees East -104.99Piped directly through from query lon or estimated by location server based on the other information in query and, if possible, differences between several queries over time.Piped directly through from query lon or estimated by location server based on the other information in query and, if possible, differences between several queries over time.
    postalcode xs:string A code used for postal delivery
    region xs:string An administrative region of the nation, such as a state or province
    room xs:string A particular room in a building
    speed The speed at which the entity is moving, in meters per second 52.69 xs:decimalPiped directly through from query speed field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.Piped directly through from query speed field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.
    street xs:string A thoroughfare within the locality, or a crossing of two thoroughfares
    text xs:string A catch-all element that captures any other information about the locationBest practice tip: This field can be used by the server to combine several fields in a natural language style, suitable for simple one-line location presence text. Example: "Near Bob's place" (description + accuracy), "On the road in New York" (locality + speed)
    timestamp xs:datetime UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of XEP-0082) 2004-02-19T21:12ZPiped directly through from query timestamp field.Piped directly through from query timestamp field.
    uri A URI or URL pointing to information about the location

    NOTE: The datatypes specified above are defined in &w3xmlschema2;.

    - +     @@ -714,7 +713,7 @@     -

    For the reasons mentioned above, it is recommended that the client supply both GPS coordinates as well as nearby location references when possible. Also it is recommended that the client submit queries frequently enough to allow the server to analyze changes over time (or lack thereof) to obtain a better result. When possible, the client should include wifi access points in the queries, as these yield much more precise results than cell towers alone (due to the much more limited range). This must however all be weighted against the increased power consumption resulting from keeping network sockets open, scanning for access points and driving a GPS receiver.

    For optimal results, clients SHOULD post a location query any time when the set of observed location references change (e.g. a new cell tower is seen or an old one is not seen any more)

    +

    For the reasons mentioned above, it is recommended that the client supply both GPS coordinates as well as nearby location references when possible. Also it is recommended that the client submit queries frequently enough to allow the server to analyze changes over time (or lack thereof) to obtain a better result. When possible, the client should include wifi access points in the queries, as these yield much more precise results than cell towers alone (due to the much more limited range). This must however all be weighted against the increased power consumption resulting from keeping network sockets open, scanning for access points and driving a GPS receiver. For optimal results, clients SHOULD post a location query any time when the set of observed location references change (e.g. a new cell tower is seen or an old one is not seen any more)

         @@ -729,7 +728,7 @@ -

    This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [7].

    +

    This document requires no interaction with the &IANA;.

     diff --git a/xep-0258.xml b/xep-0258.xml index e2ff3bbe..edd8088c 100644 --- a/xep-0258.xml +++ b/xep-0258.xml @@ -198,14 +198,16 @@

    The document details when security label meta-data should or should not be provided, and how this meta-data is to be processed.

    -

    This document does not provide:

    Such mechanisms may be introduced in subsequent documents.

    +

    This document does not provide:

    + +

    Such mechanisms may be introduced in subsequent documents.

    This document does not discuss how one might securely bind a security label to a stanza. It is expected a subsequent document will tackle this topic.

    @@ -320,10 +322,10 @@ (based upon the user's authorization) in a particular context (such as in chat room). A catalog may not include the complete set of labels available for the use by the client in the context.

    -
    Note: the single catalog per context approach used here is likely inadequate in +

    Note: the single catalog per context approach used here is likely inadequate in environments where there are a large number of labels in use. It is expected that a more sophisticated approach will be introduced in a subsequent revision of this - specification.

    + specification.

    As each service domain may have different support for security labels, servers should advertise and clients should perform appropriate discovery lookups on a per service basis.

    @@ -334,17 +336,14 @@ attribute represents the item's placement in a hierarchical organization of the items. If one item has a selector= attribute, all items should have a selector= attribute. The value of the selector= attribute conforms - to the selector-value ABNF production:
    - "|")* -]]> -
    + to the selector-value ABNF production:

    + "|")*]]>

    where &ITEM; is a sequence of characters not including "|".

    A value of "X|Y|Z" indicates that this item is "Z" in the the "Y" subset of the "X" subset of items. This information may be used, for instance, in generating label selection menus in graphical user interfaces.

    -
    Note: use of unnecessarily deep hierarchies should be avoided.
    +

    Note: use of unnecessarily deep hierarchies should be avoided.

    "|")* -

    "|")* - ]]> A copy of this schema is available at - http://xmpp.org/schemas/sec-label.xsd.

    +]]> +

    A copy of this schema is available at + http://xmpp.org/schemas/sec-label.xsd.

     -

    "|")* - ]]> A copy of this schema is available at - http://xmpp.org/schemas/sec-label-catalog.xsd.

    +]]> +

    A copy of this schema is available at + http://xmpp.org/schemas/sec-label-catalog.xsd.

     -

    "|")* - ]]> A copy of this schema is available at - http://xmpp.org/schemas/sec-label-ess.xsd.

    +]]> +

    A copy of this schema is available at + http://xmpp.org/schemas/sec-label-ess.xsd.

         diff --git a/xep-0260.xml b/xep-0260.xml index 3d262b6d..2ebd6857 100644 --- a/xep-0260.xml +++ b/xep-0260.xml @@ -127,7 +127,7 @@ - The basic flow is as follows. +

    The basic flow is as follows.

    -&xep0166; is used to negotiate peer to peer media sessions. -Muji (short for Multiparty Jingle) is a way to coordinate Jingle sessions between a group of people. -Muji conferences are held in &xep0045; rooms. +

    + &xep0166; is used to negotiate peer to peer media sessions. + Muji (short for Multiparty Jingle) is a way to coordinate Jingle sessions + between a group of people. + Muji conferences are held in &xep0045; rooms. +

    -A Muji conference has a number of contents, each of which has unique name. -content type, and an encoding. Each participant may provide a stream for each -content, and communicates which contents they are willing to provide streams -for, along with encoding information, in their MUC presence. This serves two -purposes. Firstly, so that each participant knows which contents every other -participant provides. Secondly, so that there is a global payload type (PT) -mapping for the various contents, so that clients only need to encode and -payload each content that they provide once. +

    + A Muji conference has a number of contents, each of which has unique name, + content type, and an encoding. + Each participant may provide a stream for each content, and communicates + which contents they are willing to provide streams for, along with encoding + information, in their MUC presence. + This serves two purposes. Firstly, so that each participant knows which + contents every other participant provides. + Secondly, so that there is a global payload type (PT) mapping for the + various contents, so that clients only need to encode and payload each + content that they provide once. +

    + +

    + Participants are not required to participate all the contents that are + available. + For example, a Muji client might choose to only request audio streams. +

    -Participants are not required to participate all the contents that are -available. For example, a Muji client might choose to only request audio -streams.

    - Joining a conference is done in two stages. The first step is to - declare that preparations are being done to either join or start a muji - session inside the MUC. This is indicated by the client sending a presence - stanza to the MUC with a preparing element in muji section. - - - - - - - - ]]> - - The client MUST then wait until the MUC rebroadcasts its presence message, - after which it MUST wait for all other participants that had a preparing - element in their presence to finish preparation. Afterwards it should finish - it's own preparation by updating its presence with the contents it wants to - take part in. - - - - - - - - - - - - - - - - - - ]]> + Joining a conference is done in two stages. The first step is to + declare that preparations are being done to either join or start a muji + session inside the MUC. This is indicated by the client sending a presence + stanza to the MUC with a preparing element in muji section.

    -

    + + + + + + +]]> +

    + The client MUST then wait until the MUC rebroadcasts its presence message, + after which it MUST wait for all other participants that had a preparing + element in their presence to finish preparation. Afterwards it should finish + it's own preparation by updating its presence with the contents it wants to + take part in. +

    + + + + + + + + + + + + + + + + +]]> + +

    When a client adds a payload ID to a content description, it MUST have the same codec name and receiving parameters as the corresponding entries in other participants' payload maps for that content. For instance, if Alice @@ -171,9 +181,10 @@ streams.

    - Adding a stream follows a process similar to the joining a conference. As a - first step an updated presence stanza MUST be send which contains a preparing - element as part of the Muji section. + Adding a stream follows a process similar to the joining a conference. As a + first step an updated presence stanza MUST be send which contains a + preparing element as part of the Muji section. +

    ]]> - The client MUST then wait until the MUC rebroadcasts its presence message, - after which it MUST wait for all other participants that had a preparing - element in their presence to finish their changes. +

    + The client MUST then wait until the MUC rebroadcasts its presence message, + after which it MUST wait for all other participants that had a preparing + element in their presence to finish their changes. +

    - Afterwards the client should add the new content to the muji section of its - presence and add the content to all the Jingle sessions it had with - participants it shared the content with. +

    + Afterwards the client should add the new content to the muji section of its + presence and add the content to all the Jingle sessions it had with + participants it shared the content with. +

    ]]> -

    diff --git a/xep-0273.xml b/xep-0273.xml index b6cd9376..73138d68 100644 --- a/xep-0273.xml +++ b/xep-0273.xml @@ -186,10 +186,16 @@
    urn:xmpp:sift:stanzas:iq
    The server enables the client to sift all &IQ; stanzas or ones that match the specified criteria.
    +     +
    urn:xmpp:sift:stanzas:message
    The server enables the client to sift all &MESSAGE; stanzas or ones that match the specified criteria.
    +     +
    urn:xmpp:sift:stanzas:presence
    The server enables the client to sift all &PRESENCE; notifications (i.e., presence stanzas with no 'type' or with a type of "unavailable") or ones that match the specified criteria.
    +     +
    urn:xmpp:sift:stanzas:sub
    The server enables the client to sift all subscription-related &PRESENCE; stanzas (i.e., presence stanzas with a type of "subscribe", "subscribed", "unsubscribe", or "unsubscribed") or ones that match the specified criteria.
     @@ -201,12 +207,20 @@
    urn:xmpp:sift:senders:all
    The server shall sift this kind of stanza no matter who the sender is. This is the default.
    +     +
    urn:xmpp:sift:senders:local
    The server shall sift this kind of stanza only from entities associated with the same local domain as the user itself (not from remote domains).
    +     +
    urn:xmpp:sift:senders:others
    The server shall sift this kind of stanza only from other entities (not from the user itself).
    +     +
    urn:xmpp:sift:senders:remote
    The server shall sift this kind of stanza only from entities associated with remote domains (not from the same local domain as the user itself).
    +     +
    urn:xmpp:sift:senders:self
    The server shall sift this kind of stanza only from the user itself (not from other entities).
     @@ -219,8 +233,12 @@
    urn:xmpp:sift:recipients:all
    The server shall sift this kind of stanza if the recipient is the bare JID &LOCALBARE; of the user or the full JID &LOCALFULL; of the particular resource. This is the default.
    +     +
    urn:xmpp:sift:recipients:bare
    The server shall sift this kind of stanza only if the recipient is the bare JID &LOCALBARE; of the user.
    +     +
    urn:xmpp:sift:recipients:full
    The server shall sift this kind of stanza only if the recipient is the full JID &LOCALFULL; of the particular resource.
     diff --git a/xep-0276.xml b/xep-0276.xml index ea71db26..ffd19d6d 100644 --- a/xep-0276.xml +++ b/xep-0276.xml @@ -173,15 +173,18 @@

    To signal the type of communication that is desired, the entity that first shares session presence MAY include a 'reason' attribute on the <decloak/> element. The following values for the 'reason' attribute are defined:

    -
    media
    -
    Presence is requested for a voice and/or video call, e.g. via &xep0167;.
    - -
    text
    - -
    Presence is requested for a textual conversation using an extension that requires capabilities to be disclosed, such as &xep0071;, &xep0085;, &xep0301;, or end-to-end encryption.
    - -
    file
    -
    Presence is requested for one or more file transfers, e.g. via &xep0234; or &xep0095;.
    + +
    media
    +
    Presence is requested for a voice and/or video call, e.g. via &xep0167;.
    +     + +
    text
    +
    Presence is requested for a textual conversation using an extension that requires capabilities to be disclosed, such as &xep0071;, &xep0085;, &xep0301;, or end-to-end encryption.
    +     + +
    file
    +
    Presence is requested for one or more file transfers, e.g. via &xep0234; or &xep0095;.
    +

    Inclusion of the 'reason' attribute can be interpreted by the receiving client as a signal that communication is about to start; for instance, a call accept/reject dialog could double as a UI for accepting or rejecting a session presence request.

    @@ -191,7 +194,6 @@

    To limit the extent of the presence leak, the receiving entity SHOULD send only bare presence without the XMPP &PRIORITY;, &SHOW;, or &STATUS; element. Unfortunately, this has two implications:

    -

    1. The initiating entity cannot know which of the receiving entity's resources is more likely to engage in communication. This might imply that the initiating entity will need to send a session initiation request or other communication to more than one of the receiving entity's resources (and then retract the session initiation requests that are not answered by the receiving entity). Solutions to that problem are out of scope for this specification.

    2. Establishment of a session might be delayed (e.g., because in Jingle it is desirable to start negotiating candidates as soon as possible but a user interface that prompts the receiving entity to explicitly approve of divulging presence will tend to a delay in call setup). As a result, it may be advantageous to have a way to configure unconditional sharing of session presence in certain deployments, at least within the same trust domain.

      3. diff --git a/xep-0278.xml b/xep-0278.xml index 5da6b23e..c4043bfd 100644 --- a/xep-0278.xml +++ b/xep-0278.xml @@ -118,8 +118,8 @@ All signalling, request, response and publishing is done via XMPP, not requiring ]]> -In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services. - +

      In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.

      +

      A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on the known Tracker Services.

      ]]> -In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services. -       +

      In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services.

      +

      A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on his Roster Items until find the desired amount of Relay Services, or while it does NOT exceed a search depth or ANY other Client implementation policy. The Client SHOULD keep a list of visited Tracker Services in order to avoid searching twice in same Service Entity.

      - ]]> + ]]>

      In this example 'juliet@capulet.lit/balcony' returned a Relay Service entry that is restricted to its roster. This Service is usable as the requester has 'juliet@capulet.lit/balcony' on its roster. Although, services with policy 'roster' MUST NOT be listed in Tracker Responses expects in Tracker Responses that comes from the Service Entity itself, in this case 'juliet@capulet.lit/balcony'.

      -In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry. -       +

      In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.

      +

      A Jingle Client with Internet connectivity wheter with direct access to a public IP or not, can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...

      @@ -188,7 +188,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring maxkbps='120' expire='60'/> ]]> -

      After receiving the &CHANNEL; the requester MUST send his stream to 'host' and 'localport' pair and send a &CANDIDATE; containing the 'host' and 'remoteport' values.

      +

      After receiving the &CHANNEL; the requester MUST send his stream to 'host' and 'localport' pair and send a &CANDIDATE; containing the 'host' and 'remoteport' values.

       @@ -234,30 +234,30 @@ All signalling, request, response and publishing is done via XMPP, not requiring id A random candidate identifier generated by the Relay Service, which effectively maps to the created Channel; this SHOULD match the XML Nmtoken production See <http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken> so that XML character escaping is not needed for characters such as '&'. In some situations the Jingle session identifier might have security implications. See &rfc4086; regarding requirements for randomness. REQUIRED on response, NOT RECOMMENDED on requests - + host - The IP address or Host address of the Relay Channel. + The IP address or Host address of the Relay Channel. REQUIRED on response localport - The port number to be used by the channel requester. + The port number to be used by the channel requester. REQUIRED on response remoteport - The port number to be offered to the remote party. + The port number to be offered to the remote party. REQUIRED on response protocol - The protocol supported by the retrieved channel. + The protocol supported by the retrieved channel. REQUIRED on response maxkbps - The maximum bandwidth supported by the channel. + The maximum bandwidth supported by the channel. OPTIONAL on response, NOT RECOMMENDED on requests. @@ -277,10 +277,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring

      The value of the 'remoteport' attribute MUST be a valid IP Port number. This port MUST be used as media traffic destination port of the other party. Channel requester MUST use this port value in the candidate offer in combination with the 'host' attribute. Channel requester MUST NOT send any media stream to this port.

      For transparent compatibility with major RTP Proxy Deployments, an RCTP Port is allocated and defined by default at Remoteport Attribute Value plus one. (Localport + 1)

      -       +

      The value of the 'protocol' attribute MUST be a valid protocol value: 'udp' or 'tcp' as also defined in the XML Schema

      -       +

      The value of the 'maxkbps' attribute MUST be a valid integer value representing the maximum kilobits per seconds the channel supports. This attribute is optional and MAY be used in Relay Channel with bandwidth limitation.

       @@ -375,15 +375,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring

      Relay Channels auto expires MUST expire on traffic inactivity. The inactivity timeout recommended is 60 seconds.

      It is heavily recommended that the Super Node implements throttle:

        -

      • Based on JID, allowing the control of how many concurrent channels an specific JID can have.
        • -

        -

      • Based on JID, allowing the control of how many channel requests an specific JID can request in a time period.
        • -

        -

      • Based on Bandwidth, allowing the control of how much bandwidth a channel can use. The maximum bandwidth SHOULD be included on the candidate element provided by a Super Node on the attribute maxkbps. If no attribute is present, it means that it has no bandwidth control.
        • -

        +
      - ]]> - +]]>

      The focus of this specification is instant messaging applications and so those (and only those) &MESSAGE; stanzas used for instant messaging SHOULD be delivered as Carbons. Defining precisely which messages are used for instant messaging and which are not is difficult, as future specifications may add additional payloads used for, or not used for, instant messaging; as such, the rules for which messages are eligible for carbons delivery is left as an implementation detail for servers. The following is a suggested set of rules a server MAY use, or it MAY use its own; in either case it SHOULD follow the general intent of these rules:

      -

      Possible delivery rules: -

        -
      • A &MESSAGE; is eligible for carbons delivery if it is of type "chat".
        • -
      • A &MESSAGE; is eligible for carbons delivery if it is of type "normal" and it contains a <body> element.
        • -
      • A &MESSAGE; is eligible for carbons delivery if it is of type "error" and sent in response to a &MESSAGE; that was itself eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).
        • -
      • A &MESSAGE; is not eligible for carbons delivery if it is determined to have been sent by a MUC room or service, even if it would be otherwise eligible (this also includes private messages from MUC participants).
        • -
      • A &MESSAGE; is not eligible for carbons delivery if it does not meet any of these criteria.
        • -
      -

      +

      Possible delivery rules:

      +
        +
      • A &MESSAGE; is eligible for carbons delivery if it is of type "chat".
        • +
      • A &MESSAGE; is eligible for carbons delivery if it is of type "normal" and it contains a <body> element.
        • +
      • A &MESSAGE; is eligible for carbons delivery if it is of type "error" and sent in response to a &MESSAGE; that was itself eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).
        • +
      • A &MESSAGE; is not eligible for carbons delivery if it is determined to have been sent by a MUC room or service, even if it would be otherwise eligible (this also includes private messages from MUC participants).
        • +
      • A &MESSAGE; is not eligible for carbons delivery if it does not meet any of these criteria.
        • +

      As this is a implementation detail of servers, clients MUST NOT rely on the server implementing a particular set of rules for which messages are eligible for Carbons delivery.

      Future specifications may have more precise requirements on which messages need to be eligible for carbons delivery; such future specifications will provide their own discovery and negotiation mechanisms, such that a client negotiating Carbons using the protocol defined in this specification will cause the server to consider messages eligible for Carbons delivery based on the requirements described herein.

      Note: previous versions of this specification limited eligible messages to those of type "chat" - however, this was generally found to be inadequate due to the proliferation of type "normal" messages used in instant messaging.

      diff --git a/xep-0281.xml b/xep-0281.xml index fa871496..57d5b010 100644 --- a/xep-0281.xml +++ b/xep-0281.xml @@ -51,7 +51,7 @@ -

      Note: This document has been retracted by the author in favor of &xep0289;.

      +

      Note: This document has been retracted by the author in favor of &xep0289;.

      &xep0045; defines a full-featured technology for multi-user text conferencing in XMPP. By design, XEP-0045 assumes that a conference room is hosted at a single service, which can be accessed from any point on the network. However, this assumption introduces a single point of failure for the conference room, since if occupants at a using domain lose connectivity to the hosting domain then they also lose connectivity to the room. In some deployment scenarios (and even on the open Internet) this behavior is suboptimal. Therefore, this document attempts to define a technology for distributing MUC rooms across multiple services.

      @@ -459,7 +459,7 @@       -

      If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" &NSVER; in response to service discovery information requests.

      +

      If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" in response to service discovery information requests.

       diff --git a/xep-0283.xml b/xep-0283.xml index b5d4dd8b..0347905f 100644 --- a/xep-0283.xml +++ b/xep-0283.xml @@ -110,18 +110,22 @@

      In this scenario user@example.com moves to user2@example2.com. - Both the user@example.com and user2@example2.com accounts have been - created and still exist. The roster for user@example2.com is empty - and the user wants to populate it with their entries from - user@example.com.

      + Both the user@example.com and user2@example2.com accounts have been + created and still exist. The roster for user@example2.com is empty + and the user wants to populate it with their entries from + user@example.com.

      -
      original JID
      -
      user@example.com
      -
      new JID
      -
      user2@example2.com
      + +
      original JID
      +
      user@example.com
      +       + +
      new JID
      +
      user2@example2.com
      +
      - +

      Because the original JID is no longer going to be used, the user SHOULD @@ -140,14 +144,12 @@ JID to the user. See the Security Considerations section for details.

      - - I've changed JIDs from user@example.com to user2@example2.com -]]> - +]]>       diff --git a/xep-0284.xml b/xep-0284.xml index 5c43fd81..c8744bfc 100644 --- a/xep-0284.xml +++ b/xep-0284.xml @@ -12,6 +12,7 @@ 0284 Deferred Standards Track + Standards Council XMPP Core diff --git a/xep-0287.xml b/xep-0287.xml index 93be5c2d..7bd414cb 100644 --- a/xep-0287.xml +++ b/xep-0287.xml @@ -42,15 +42,14 @@ -

      There are various spim protection methods exist in XMPP: &xep0016;, &xep0158;, &xep0191;, &xep0268; and &xep0275;. But they may not be sufficient enough: -

        -
      • &xep0016; and &xep0191; define blocking mechanism only which is not always appropriate.
        • -
      • &xep0158; interacts badly with automated software such as gateways.
        • -
      • &xep0268; implies trusted network of servers.
        • -
      • &xep0275; concentrates on ranking only.
        • -
      - Service administrators might want to deploy server-based spim recognition software to fill in the gaps. However, every automated spim recognition suffers from false positives - situations where a stanza incorrectly qualified as spim. To avoid them, a spim filter doesn't block suspicious stanza, but marks it and sends to a client in a regular manner. A client software doesn't need to interrupt a user when processing such marked stanzas: for example, it may put them silently in "SPAM" folder, so a user can look through them at any time later. Furthermore, a spim filter may take user's experience into account. When a user receives an unsolicited stanza, he or she can mark it as spim. In this case a client software sends an automatic complaint to a server-based spim filter. This specification deals with both cases. Thus, in contrast to &xep0159;, it doesn't introduce any spim blocking techniques. Also, the various spim recognition procedures that may be employed by the server are beyond the scope of this document. -

      +

      There are various spim protection methods exist in XMPP: &xep0016;, &xep0158;, &xep0191;, &xep0268; and &xep0275;. But they may not be sufficient enough:

      +
        +
      • &xep0016; and &xep0191; define blocking mechanism only which is not always appropriate.
        • +
      • &xep0158; interacts badly with automated software such as gateways.
        • +
      • &xep0268; implies trusted network of servers.
        • +
      • &xep0275; concentrates on ranking only.
        • +
      +

      Service administrators might want to deploy server-based spim recognition software to fill in the gaps. However, every automated spim recognition suffers from false positives - situations where a stanza incorrectly qualified as spim. To avoid them, a spim filter doesn't block suspicious stanza, but marks it and sends to a client in a regular manner. A client software doesn't need to interrupt a user when processing such marked stanzas: for example, it may put them silently in "SPAM" folder, so a user can look through them at any time later. Furthermore, a spim filter may take user's experience into account. When a user receives an unsolicited stanza, he or she can mark it as spim. In this case a client software sends an automatic complaint to a server-based spim filter. This specification deals with both cases. Thus, in contrast to &xep0159;, it doesn't introduce any spim blocking techniques. Also, the various spim recognition procedures that may be employed by the server are beyond the scope of this document.

      An implementation compliant with this document MUST support spim markers as described in Spim Marker use case. Support for spim reports, as described in Spim Report use case, is RECOMMENDED.

      @@ -142,13 +141,12 @@

      A filtering entity SHOULD only add <mark/> or <report/> elements and a receiving entity SHOULD only process those elements if the corresponding stanza envolves an interaction with a human user: subscription requests, messages, conference invites, voice calls, etc. For example, it doesn't make a lot of sense to mark &xep0232; stanzas.

      -

      To avoid obvious false positives and user confusions, a filtering entity SHOULD NOT add <mark/> or <report/> elements to a stanza and a receiving entity SHOULD ignore <mark/> and <report/> elements of a stanza if: -

        -
      • The receiving entity has the sender's subscription information of the type "both", "from" or "to".
        • -
      • The receiving entity has pending subscription to the sender, i.e. subscription of type "none" and ask='subscribe'.
        • -
      • The receiving entity has sent direct presence to the sender.
        • -
      -

      +

      To avoid obvious false positives and user confusions, a filtering entity SHOULD NOT add <mark/> or <report/> elements to a stanza and a receiving entity SHOULD ignore <mark/> and <report/> elements of a stanza if:

      +
        +
      • The receiving entity has the sender's subscription information of the type "both", "from" or "to".
        • +
      • The receiving entity has pending subscription to the sender, i.e. subscription of type "none" and ask='subscribe'.
        • +
      • The receiving entity has sent direct presence to the sender.
        • +

      If an entity supports the spim markers, it MUST report that by including a service discovery feature of "urn:xmpp:spim-marker:0" in response to a &xep0030; information request. If an entity supports the spim reports, it MUST report that by including a service discovery feature of "urn:xmpp:spim-report:0" in response to a &xep0030; information request:

      diff --git a/xep-0289.xml b/xep-0289.xml index c373861f..43055d3d 100644 --- a/xep-0289.xml +++ b/xep-0289.xml @@ -81,14 +81,12 @@
    3. alice@wonderland.lit - User on wonderland.lit
    4. hatter@wonderland.lit - User on wonderland.lit
    5. rabbithole@rooms.wonderland.lit - MUC room / FMUC node.
      6. -
    6. denmark.lit - service, likely connected to wonderland.lit over constrained link
    7. talk.denmark.lit - MUC service on denmark.lit.
    8. hamlet@denmark.lit - User on denmark.lit
    9. ophelia@denmark.lit - User on denmark.lit
    10. elsinore@talk.denmark.lit - MUC room / FMUC node.
      11. -

      @@ -371,8 +369,6 @@ -
        -