From 8de3ee3a29a5216cf84f62824e4ee2071db1dcd6 Mon Sep 17 00:00:00 2001
From: Sam Whited 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. 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: 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 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 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:
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.
@@ -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.
-
-
+
+]]>
-
The additional error information provide includes:
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).
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 @@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.
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 @@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 @@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:
-Protocol | Description | Ref | Address | Port (default) | User | Pass | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
sipub (REQUIRED) | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
sipub (REQUIRED) | OPTIONAL | N/A | N/A | N/A | N/A | N/A |
Transaction Type | -Purpose | -Associated Ad-Hoc Command | -REQUIRED for generic XEP compatibility | -Contained Elements | -
---|
Transaction Type | +Purpose | +Associated Ad-Hoc Command | +REQUIRED for generic XEP compatibility | +Contained Elements | +
---|---|---|---|---|
io-schemata-get | To request the schemata of input and output. | @@ -221,16 +219,14 @@ if (function instanceof IoDataFunction) {
Transaction Type | -Purpose | -Associated Ad-Hoc Command status value | -REQUIRED for generic XEP compatibility | -Contained Elements | -
---|
Transaction Type | +Purpose | +Associated Ad-Hoc Command status value | +REQUIRED for generic XEP compatibility | +Contained Elements | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
io-schemata-result | To return the schemata of input and output. | @@ -281,16 +277,14 @@ if (function instanceof IoDataFunction) {
Ad-Hoc Command | -Keyword | -Associated Transaction Type | -Subsequently allowed commands | -Status description | -
---|
Ad-Hoc Command | +Keyword | +Associated Transaction Type | +Subsequently allowed commands | +Status description | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
execute | Get Schemata | 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 @@ ]]>
Character | Unicode Code Point Value | Escape sequence |
---|---|---|
" | U+0022 | \" |
Line Feed (New Line) | U+000A | \n |
Carriage Return | U+000D | \r |
Line Separator | U+2028 | \u2028 |
Paragraph Separator | U+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.
+Character | Unicode Code Point Value | Escape sequence |
---|---|---|
" | U+0022 | \" |
Line Feed (New Line) | U+000A | \n |
Carriage Return | U+000D | \r |
Line Separator | U+2028 | \u2028 |
Paragraph Separator | U+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).
Element Name | Datatype | Definition | Example | -Notes | |
---|---|---|---|---|---|
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.99 | -See notes for lat | +See notes for lat |
alt | xs:decimal | Altitude in meters above or below sea level | @@ -443,48 +442,48 @@Optional. 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 alt | +See notes for alt |
datum | xs:string | GPS datum (See XEP-0080) | - | See notes for alt | +See notes for alt |
accuracy | xs:decimal | Horizontal GPS accuracy in meters | 10 | -See notes for lat | +See notes for lat |
speed | xs:decimal | The speed at which the entity is moving, in meters per second | 52.69 | -See notes for alt | +See 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. |
Element Name | Datatype | Definition | @@ -492,28 +491,28 @@Notes | ||
---|---|---|---|---|---|
id | xs:string | -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 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 |
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;). | @@ -523,22 +522,22 @@
Element Name | Datatype | Definition | Example | Notes | |
---|---|---|---|---|---|
alt | xs:decimal | Altitude in meters above or below sea level | 1609 | -Piped 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 | @@ -546,15 +545,15 @@|||
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 | @@ -562,7 +561,7 @@|||
country | xs:string | The nation where the user is located | @@ -570,14 +569,14 @@|||
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 location | @@ -585,15 +584,15 @@If 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 | 10 | -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. | +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 | @@ -601,16 +600,16 @@|||
lat | xs:decimal | Latitude in decimal degrees North | 39.75 | -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. | +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 | @@ -618,15 +617,15 @@|||
lon | xs:decimal | Longitude in decimal degrees East | -104.99 | -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. | +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 | @@ -634,7 +633,7 @@|||
region | xs:string | An administrative region of the nation, such as a state or province | @@ -642,7 +641,7 @@|||
room | xs:string | A particular room in a building | @@ -650,15 +649,15 @@|||
speed | The speed at which the entity is moving, in meters per second | 52.69 | xs:decimal | -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. | +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 | @@ -666,7 +665,7 @@|||
text | xs:string | A catch-all element that captures any other information about the location | @@ -674,15 +673,15 @@Best 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:12Z | -Piped directly through from query timestamp field. | +Piped directly through from query timestamp field. |
uri | A URI or URL pointing to information about the location | @@ -694,7 +693,7 @@
NOTE: The datatypes specified above are defined in &w3xmlschema2;.
- +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)
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [7].
+This document requires no interaction with the &IANA;.
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:
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 ++ specification.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.
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.
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:
-
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.
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.
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.
+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.
+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.
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.
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:
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 @@
- alice@wonderland.lit - User on wonderland.lit
- hatter@wonderland.lit - User on wonderland.lit
- rabbithole@rooms.wonderland.lit - MUC room / FMUC node.
-
- denmark.lit - service, likely connected to wonderland.lit over constrained link
- talk.denmark.lit - MUC service on denmark.lit.
- hamlet@denmark.lit - User on denmark.lit
- ophelia@denmark.lit - User on denmark.lit
- elsinore@talk.denmark.lit - MUC room / FMUC node.
-
@@ -371,8 +369,6 @@
-
-