or
the server MUST NOT decide whether or not to propose the <registration/> feature based on the existence of the JID filled in 'from'. Doing so would leak away information about the existence of a JID which could therefore be sent undesirable messages. Being consistent on showing the feature forces to try to register which can already eliminates part of the risk if the challenge provides some bot protection (for instance CAPTCHAs).
+A perfectly valid alternative would be to always provide the <registration/> feature when no "from" is filled but never provide it when a "from is filled" (no matter it is an existing JID or not). This consistent logics does not leak information.
Do not modify the SASL authentication's mechanisms listed in the <mechanisms/> feature depending on the 'from'. Even though a given JID might not be able to connect with some mechanisms because the credentials storage is incompatible, this would leak information on the kind of storage mechanism used for this user. This information would allow attackers to determine, then target, users whose storage would be weaker.
+Of course this particular point might cause issues for users regularly changing their clients or log in from various computer. For instance the SCRAM-SHA-1 and SCRAM-SHA-256 storage are incompatible. If you first registered by specifying the SCRAM-SHA-256 storage, then on another client which does not support SCRAM-SHA-256 or even who supports it, but for some reason always try and gives priority to SCRAM-SHA-1, the user could be found in a situation where he never manages to authenticate while providing the right password. For this reason, it could be wiser for server deployments to choose compatible mechanisms, when possible. On client side, if they are provided a raw password, instead of pre-computed data for a specific mechanism, then they should intelligently try the various mechanisms, starting from the one they consider the stronger. Hence try SCRAM-SHA-256, then SCRAM-SHA-1 if the first failed, then only if both failed, tell the user that authentication failed (note that the client should not try PLAIN as a last fallback, because we remind that any SCRAM-* storage is compatible with the SASL PLAIN mechanism. Trying PLAIN would therefore be a security risk.
First draft.
The Buddycloud project is a set of independently deployable services, that inter-operate to create a rich collaboration service. @@ -188,7 +134,7 @@
Each XMPP domain can have one Buddycloud server that serves user's channels.
Buddycloud clients and servers need to be able to discover the authoratative
Buddycloud server. find the
@@ -196,7 +142,7 @@
To find the correct remote Buddycloud service for a domain, the Buddycloud
- server should:
+ server should:
-
The Buddycloud service first sends an items discovery request to the domain @@ -274,12 +219,12 @@
This example delegates all the Buddycloud service to an XMPP component running the Buddycloud named - buddycloud-component.verona.lit + buddycloud-component.verona.lit .
Upon connection to the buddycloud server a user should send a register stanza.
@@ -300,15 +245,16 @@Node metadata is used to describe the channel to users. All nodes in a channel have the same metadata and permission.
-- using disco-info + with the node specified - using &xep0060; 5.4 Discover Node Metadata
set Not sure what + goes here?
minimum setting/optional recommended fallbacks @@ -401,7 +347,6 @@
Channel owners and moderators can also set the default affiliation for the channel
-
| Channel Type | @@ -429,8 +374,6 @@
|---|
| Access Model | @@ -455,7 +398,6 @@
|---|
Buddycloud is designed to be extended with new node and content types. To @@ -523,16 +465,14 @@
Buddycloud adapts XEP-0060's machine-to-machine design goals with logic and presets that work better in a social person-to-person and person-to-group environment. For example, to discourage "glorifying the wicked", the list of banned users is only presented to the channel's moderators.
-
| Property | Access model | @@ -544,8 +484,6 @@Anonymous (e.g. web) | Banned users |
|---|---|---|---|
| channel name | all | @@ -665,12 +603,8 @@no | no |
| Property | Producer | @@ -680,8 +614,6 @@Anonymous (e.g. web) | Banned users |
|---|---|---|---|
| change channel name | only at creation time | @@ -745,9 +677,7 @@no | no |
A Buddycloud server MUST maintain similar affiliations and permissions for a subscribed @@ -762,7 +692,7 @@
Many of the item use cases follow those from XEP-0060. This section notes
the departures from the parent XEP and specific requirements.
@@ -864,8 +794,8 @@
A retraction message is sent to all online clients, with an Atom tombstone to + replace the deleted post
The minimal payload for a publish request must be formatted as follows:
Posts in Buddycloud can be formed into threads consisting of a parent post - and comments to a maximum thread depth of 1. Posts follow the - ATOM threading specification + and comments to a maximum thread depth of 1. Posts follow the &rfc4685; and utilise the & thread ; namespace with the 'ref' attribute referring to the full global ID of the @@ -992,7 +922,7 @@ ]]>
Within a single thread comments can reference other comments or the parent item. This is for the purpose of making a comment to a post further back in the thread. @@ -1052,6 +984,7 @@ +
By making use of the & @@ -1119,13 +1052,13 @@
Buddycloud clients follow XEP-0060 subscription mechanisms for following and unfollowing a channel.
- Buddycloud channels build on XEP-0060's node affiliations. + Buddycloud channels build on XEP-0060's node affiliations.
| XEP-0060 Affiliation | @@ -1183,10 +1116,9 @@RECOMMENDED |
|---|
The Buddycloud server should make sure that the remote server
diff --git a/inbox/cap.xml b/inbox/cap.xml
new file mode 100644
index 00000000..92dfd031
--- /dev/null
+++ b/inbox/cap.xml
@@ -0,0 +1,169 @@
+
+
+%ents;
+]>
+
+ First draft. This specification provides a mechanism to atomically publish
+ items to a PubSub node depending on the item ID of the node's latest
+ item. This allows to prevent race conditions and avoids data
+ loss in certain situations. If an entity supports the Compared-And-Publish feature it MUST
+ advertise the fact by returning a <feature/> with the 'var'
+ attribute set to 'urn:xmpp:pubsub:cap:0' in response to a &xep0030;
+ query for information. In order to atomically compare-and-publish an item, a client
+ sends an &IQ; with a 'pubsub' element qualified by the
+ 'urn:xmpp:pubsub:cap:0' namespace. The element MUST contain the same
+ attributes and elements as the <publish/> element defined in
+ &xep0060; and it MUST contain a previd attribute containing
+ an item ID. The PubSub service MUST only publish the item if the node's
+ latest item ID is equal to the ID found in the 'previd'
+ attribute. If the 'previd' matched the latest item's ID and if the service
+ was able to successfully process the request then the protocol
+ continues as defined in XEP-0060 7.1.2. In case the Compare-And-Publish operation failed because the
+ latest node id is not the same as given in the 'previd' attribute
+ in the request, the server returns an &IQ; result with 'pubsub'
+ element qualified by the 'urn:xmpp:pubsub:cap:0' namespace which
+ contains a <compare-and-publish-failed/> element. The
+ element MUST have a 'id' attribute with the ID of the lastest
+ item. All other error cases are handled as specified in
+ XEP-0060 § 7.1.3 This extension protocol does not add any further security
+ considerations to the ones mentioned in XEP-0060 §
+ 14.. This document requires no interaction with the Internet Assigned
+ Numbers Authority (IANA). This specification defines the following XML namespaces: TODO: Add after the XEP leaves the 'experimental' state. An entity advertises support for this protocol by including the 'urn:xmpp:cmr:0' feature in its service discovery information features as specified in Service Discovery (XEP-0030) or section 6.3 of Entity Capabilities (XEP-0015). If allowed and supported by the server, clients are able to annotate message stanza with a routing hint, that SHOULD affect the used message routing algorithm for the annotated stanza.
Algorithm Namespace: 'urn:xmpp:cmr:all'
Deliver to all non-negative resources with share the same maximum priority. And if message type is 'chat', only to those that have opted in to receive chat messages.
Algorithm Namespace: 'urn:xmpp:cmr:mostactive'
Deliver the message to the "most available" resource or resources, depending on the server's implementation.
Algorithm Namespace: 'urn:xmpp:cmr:roundrobin'
Deliver the message to the next resource selected by a round-robin algorithm.
Algorithm Namespace: 'urn:xmpp:cmr:weighted'
Deliver the message to a resource selected by a weighted round-robin algorithm. The weight of a resource is determined by its priority. First draft. Colors provide a valuable visual cue to recognize text. Recognition of colors works much faster than recognition of text. Together with the length and overall shape of a piece of text (such as a nickname), a color provides a decent amount of entropy to distinguish a reasonable amount of entities. The color generation mechanism should provide the following features: To generate a color from a string of text, the follownig algorithms are applied in order: Implementations may colorize the participants of a conversation with an individual color to make them easier to distinguish. In such cases, the color SHOULD be generated as described in the Generating a color section. The input used SHOULD be, in descending order of preference, (a) the name assigned in the roster, (b) the nickname from the conversation, (c) the bare JID. Implementations may want to show a picture in connection with a contact even if the contact does not have an avatar defined (e.g. via &xep0084;). In such cases, auto-generating an avatar SHOULD happen as follows: Input: An identifier, encoded as octets of UTF-8 (&rfc3269;). Output: Angle in the CbCr plane. Note: The goal of this algorithm is to convert arbitrary text into a scalar value which can then be used to calculate a color. As it happens, the CbCr plane of the YCbCr space determines the color (while Y merely defines the lightness); thus, an angle in the CbCr plane serves as a good scalar value to select a color. Input: Angle in the CbCr plane. Output: Angle in the CbCr plane. Note: This algorithm will re-map the angle to map it away from ranges which can not be distinguished by people with the respective &cvds;. Divide the angle by two. Divide the angle by two and add π/2 (half Pi). Input: Angle in the CbCr plane, from the previous algorithm. Output: Values for Cb and Cr in the YCbCr BT.601 color space in the range from -0.5 to 0.5. Form a vector from the angle and project it to edges of a quad in 2D space with edge length 1 around (0, 0). The resulting coordinates are Cb and Cr: Input: Values for Cb and Cr in the YCbCr BT.601 color space in the range from -0.5 to 0.5; Value for Y. Output: Values for Red (R), Green (G) and Blue (B) in the RGB color space in the range from 0 to 1. Note: The recommended value for Y is 0.732. See Gamma Correction for a discussion on the choice of Y. Input: RGB values for the color to adapt (Ri, Gi, Bi) and for the background color to adapt to (Rb, Gb, Bb), in the range from 0 to 1 each. Output: Values for Red (Rc), Green (Gc) and Blue (Bc) in the RGB color space in the range from 0 to 1. Input: Values for Red (R), Green (G) and Blue (B) in the RGB color space in the range from 0 to 1. Output: Values for Cb and Cr in the YCbCr BT.601 color space in the range from -0.5 to 0.5; Value for Y. Calculate Y, Cb and Cr according to BT.601: Input: A set of RGB colors (each component from 0 to 1). Output: A mapping from CbCr pairs (each component from -0.5 to 0.5) to RGB colors. Note: when the algorithm finishes, the mapping maps CbCr values (rounded to two decimal places) to the R, G, B triples which come closest to the desired color and lightness. Input: A set of colors (the palette) as tuples of Cbp and Crp and a color to map to the closest palette color as Cb and Cr value. Output: A palette color as Cbr and Crr values. Note: the distance metric is simply the euclidian distance in the CbCr plane. This section holds test vectors for the different configurations. The test vectors are provided as Comma Separated Values. Strings are enclosed by single quotes ('). The first line contains a header. Each row contains, in that order, the original text, the text encoded as UTF-8 as hexadecimal octets, and the Cb, Cr, Red, Green, and Blue values. The used palette can be generated by sampling the RGB cube evenly with six samples on each axis (resulting in 216 colors). The resulting palette is commonly known as the palette of so-called "Web Safe" colors. An implementation may choose a different value for Y depending on whether the sink for the R, G and B values expects Gamma Encoded or Gamma Decoded values. The recommended default of 0.732 is 0.5 to the power of 0.45, that is, a Gamma Encoded 0.5. Modifications to Y SHOULD NOT be used to correct for bright/dark backgrounds. Implementations SHOULD instead use the algorithm described in Adapting the Color for specific Background Colors for that. As outlined above, implementations MUST offer the &rgblind; and &bblind; corrections as defined in the Corrections for &cvds; section. Users MUST be allowed to choose between: The last option is important for users with monochromatic view. Some sources on the internet indicate that people with &cvds; may profit from having larger areas of color to be able to recognize them. This should be taken into consideration when selecting font weights and line widths for colored parts. This specification extracts a bit more information from an entity and shows it alongside the existing information to the user. As the algorithm is likely to produce different colors for look-alikes (see &xep0165; for examples) in JIDs, it may add additional protection against attacks based on those. Due to the limited set of distinguishable colors, possible &cvds; and/or use of palettes, entities MUST NOT rely on colors being unique in any context. This section provides an overview of design considerations made while writing this specification. It shows alternatives which have been considered, and eventually rejected. The other common YCbCr variants, BT.709 and BT.2020, do not achieve a brightness across the color space as uniform as BT.601 does. Adapting the Y value for uniform luminosity across the range for CbCr would have complicated the algorithm with little or no gain. The HSV and HSL color spaces fail to provide uniform luminosity with fixed value/lightness and saturation parameters. Adapting those parameters for uniform luminosity across the hue range would have complicated the algorithm with litte to no gain. Given a fixed-size and finite palette of colors, it would be possible to ensure that, until the number of entities to color exceeds the number of colors, no color collisions happen. There are issues with this approach when the set of entities is dynamic. In such cases, it is possible that an entity changes its associated color (for example by re-joining a colored group chat), which defeats the original purpose. In addition, more state needs to be taken into account, increasing the complexity of choosing a color. This specification needs to collapse an arbitrarily long string into just a few bits (the angle in the CbCr plane). To do so, a CRC32 sum is used. An alternative, which may yield better distribution of colors, would have been to use a cryptographic hash function. However, the performance and implementation cost for a cryptographic hash function is considerable compared with a simple CRC32, especially on small (less than 1 kiB) inputs. This document requires no interaction with &IANA;. This document requires no interaction with the ®ISTRAR;. Thanks to Daniel Gultsch, Georg Lukas, and Tobias Markmann. To signal the type of communication that is desired, the entity that first decloaks MAY include a 'reason' attribute on the <decloak/> element. The following values for the 'reason' attribute are defined: 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 decloaking request. If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" &NSVER; in response to &xep0030; information requests. If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" in response to &xep0030; information requests.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ abs(cb)) {
+ factor = 0.5 / abs(cr);
+} else {
+ factor = 0.5 / abs(cb);
+}
+cb = cb * factor;
+cr = cr * factor;
+]]>
+
+
+
+
+
+
+
+
+
+
+
+ D = sqrt((Cbp-Cb)*(Cbp-Cb) + (Crp-Cr)*(Crp-Cr)).
+
+
+
+
+
+
+
+
-
The following is a list of goals for the design of this extension: +
The following is a list of goals for the design of this extension:
The following JIDs are used in this document.
To determine if a server or service supports Distributed MUC, the requesting entity SHOULD send a disco#info request to it.
First draft.
diff --git a/inbox/iot-events.xml b/inbox/iot-events.xml
index 97905ebf..2de007fd 100644
--- a/inbox/iot-events.xml
+++ b/inbox/iot-events.xml
@@ -367,7 +367,7 @@
-
To unsubscribe a subscription, send the unsubscribe element in a request to the Thing with the seqnr sequence number corresponding to the
subscription. The Thing responds with an empty response to acknowledge the un-subscription, regardless if the subscription existed or not.
@@ -726,4 +726,4 @@
First draft
Jingle Encrypted Transports (JET) strives to provide a modular and easily extensible way to wrap Jingle Transports in an additional end-to-end encryption layer. The focus of this specification lays on being modular. It should be possible to extend existing Jingle use scenarios with end-to-end encryption by simply adding a JET element to the negotiation.
+JET uses multiple encryption layers, so it is necessary to declare a distinct denomination for the different keys involved.
+| Designation | +Abbrevation | +Usage | +
|---|---|---|
| Transport Key | +TK | +(Symmetric) key that is used to encrypt/decrypt the bytestreams sent/received through Jingle transports. This key encrypts the data two entities want to exchange. Examples for TK can be found under "Ciphers". | +
| Initialization Vector | +IV | +Initialization vector that is used together with TK. | +
| Transport Secret | +TS | +Serialization of TK and TI. | +
| Envelope Element | +EE | +Output element of an established end-to-end encryption method when encrypting TS. | +
Lets assume Romeo wants to initiate an encrypted Jingle session with Juliet. Prior to the Jingle session initiation, an already existing, established and (ideally) authenticated end-to-end encryption session between Romeo and Juliet MUST exist. This session is needed to transfer the Transport Secret from Romeo to Juliet.
+When this precondition is met, Romeo initially generates a transport key (TK) and associated initialization vector (IV). These will later be used by the sender to encrypt, and respectively by the recipient to decrypt data that is exchanged. This protocol defines a set of usable ciphers from which Romeo might choose. TK and IV are serialized to create the transport secret (TS).
+Next Romeo uses her established encryption session with Juliet to encrypt TS. The resulting envelope element (EE) will be part of the Jingle session initiation as child of the JET &secret; element.
+When Juliet receives Romeos session request, she decrypts EE to retrieve TS, from which she can deserialize TK and IV. Now she and Romeo can go on with the session negotiation. Once the session is established, data can be encrypted and exchanged. Both parties MUST keep a copy of TS in cache until the Jingle session is ended.
+&xep0234; has the disadvantage, that transmitted files are not encrypted (aside from regular TLS transport encryption), which means that intermediate nodes like XMPP/proxy server(s) have access to the transferred data. Considering that end-to-end encryption becomes more and more important to protect free speech and personal expression, this is a major flaw that needs to be addressed.
+In order to initiate an encrypted file transfer, the initiator includes a JET &secret; in the Jingle file transfer request.
+ +In this scenario Romeo wants to send an encrypted text file over to Juliet. First, he generates a fresh AES-256 transport key and IV. TK and IV are serialized into TS which is then encrypted using Romeos end-to-end-encryption session with Juliet.
+The resulting envelope element (EE) is sent as part of the security element along with the rest of the jingle stanza over to Juliet.
+Juliet decrypts the envelope element (EE) using her session with Romeo to retrieve TS from which she deserializes TK and IV. Both Juliet and Romeo then carry on with the session negotiation as described in &xep0234;. Before Romeo starts transmitting the file, he encrypts it using TK and IV. He then transmitts the encrypted file over to Juliet.
+When Juliet received the file, she uses the TK and IV to decrypt the received file.
+Juliet might want to request a file transfer from Romeo. This can be the case, when Romeo hosts the file. In order to do so, she sends generates TK and IV, creates TS from those and encrypts TS with an encryption method of her choice to get EE. TK and IV will be used by Romeo to encrypt the requested file before sending it to Juliet.
+&xep0234; defines a way for parties to request ranged transfers. This can be used to resume interrupted transfers etc. In case of an interrupted transfer, the receiving party might be able to decrypt parts of the received file. When requesting a resumption of the transfer, the recipient therefore can use the index of the last successfully decrypted byte of the file as offset in the ranged transfer. Since a resumed transfer takes place in a new session, the old transport secret might no longer be available to either party. For that reason the receiver creates a new TS for the session-initiation. The sending party then encrypts and sends only the requested parts of the file.
+In order to encrypt the transported bytestream, the initiator must transmit a cipher key to the responder. There are multiple options available:
+| Namespace | +Type | +Length (bits) | +Parameters | +Serialization | +
|---|---|---|---|---|
| urn:xmpp:ciphers:aes-128-gcm-nopadding:0 | +AES | +128 | +GCM/NoPadding | +128BitKey::96BitIV | +
| urn:xmpp:ciphers:aes-256-gcm-nopadding:0 | +AES | +256 | +GCM/NoPadding | +256BitKey::96BitIV | +
The column 'serialization' describes, how the key and iv are serialized. "::" means plain concatenation of byte arrays.
+To advertise its support for the Jingle Encrypted Transports, when replying to service discovery information ("disco#info") requests an entity MUST return URNs for any version, or extension of this protocol that the entity supports -- e.g., "urn:xmpp:jingle:jet:0" for this version, or "urn:xmpp:jingle:jet-stub:0" for a stub encryption method &VNOTE;.
+In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
+The initiator SHOULD NOT use the generated key TK as IV, but instead generate a seperate random IV.
+Instead of falling back to unencrypted transfer in case something goes wrong, implementations MUST instead abort the Jingle session, informing the user.
+IMPORTANT: This approach does not deal with metadata. In case of &xep0234;, an attacker with access to the sent stanzas can for example still see the name of the file and other information included in the <file/> element.
+The responder MUST check, whether the envelope element belongs to the initiator to prevent MitM attacks
+This is only a rough draft and there is still a ton of questions left to be answered. Here is a small non-exhaustive list of things I can think of:
+The basic flow is as follows.
+ Jingle Nodes
Thiago
Camargo
thiago@xmppjingle.com
@@ -120,7 +120,7 @@ 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.
@@ -139,7 +139,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
type='result'>
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.
@@ -161,7 +161,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
]]>
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 direct access to a public IP 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...
@@ -372,15 +372,9 @@ 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.
-
+ - 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 basic flow is as follows.
+ rfc3920bis RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-saintandre-rfc3920bis>. " >
%ents;
]>
diff --git a/inbox/jingle-zrtp.xml b/inbox/jingle-zrtp.xml
index 8088e0b8..85058b08 100644
--- a/inbox/jingle-zrtp.xml
+++ b/inbox/jingle-zrtp.xml
@@ -40,7 +40,7 @@
- &xep0167; recommends the use of the Secure Real-time Transport Protocol (SRTP) for end-to-end encryption of RTP sessions negotiated using &xep0166;. An alternative approach to end-to-end encryption of RTP traffic is provided by &zrtp;. Although negotiation of ZRTP mainly occurs in the media channel rather than the signalling channel, the ZRTP specification defines one SDP attribute called "zrtp-hash" (this communicates the ZRTP version supported as well as a hash of the Hello message).
+ &xep0167; recommends the use of the Secure Real-time Transport Protocol (SRTP) for end-to-end encryption of RTP sessions negotiated using &xep0166;. An alternative approach to end-to-end encryption of RTP traffic is provided by &rfc6189;. Although negotiation of ZRTP mainly occurs in the media channel rather than the signalling channel, the ZRTP specification defines one SDP attribute called "zrtp-hash" (this communicates the ZRTP version supported as well as a hash of the Hello message).
The SDP format is shown below.
a=zrtp-hash:zrtp-version zrtp-hash-value
diff --git a/inbox/json.xml b/inbox/json.xml
index 4c754345..f05c4271 100644
--- a/inbox/json.xml
+++ b/inbox/json.xml
@@ -48,13 +48,11 @@
The following design requirements reflect the need to offer performance as close as possible to standard XMPP-based stanza handling.
-
- JSON default character set must be UTF-8
- JSON stanza must contain (or retain) all XMPP stanza content and hierarchy
- Server must support both XML and JSON content-types.
-
Intent for following use-cases is to support JavaScript-based clients which typically start XMPP-session from HTTP-dialog, and then depending on network environment and run-time support end using BOSH or C2S through Web Sockets.
@@ -69,23 +67,23 @@
Client (and server) implementation needs to take care of using such JSON object format which retains all structure of all XMPP XML stanzas.
- Following http-header is used to communicate with server using JSON playload:
-
+ Following http-header is used to communicate with server using JSON playload:
+
POST /http-bind HTTP/1.1
Host: httpcm.jabber.org
Accept-Encoding: gzip, deflate
Content-Type: application/jsonrequest
Content-Length: 230
-
+
+
HTTP/1.1 200 OK
Content-Type: application/jsonrequest
Content-Length: 513
-In following example server name is modified so content length is not accurate. Also JSON payload is modified for better clarity of its structure.
- In following example server name is modified so content length is not accurate. Also JSON payload is modified for better clarity of its structure. JSON data is typically converted to JS-object in browser client. Practically this means that tag string name / value string pairs are converted to tag name / value string pairs. Example: JSON data is typically converted to JS-object in browser client. Practically this means that tag string name / value string pairs are converted to tag name / value string pairs. Example:
+
POST /http-bind HTTP/1.1
Host: httpcm.jabber.org
Accept-Encoding: gzip, deflate
@@ -106,8 +104,8 @@ Content-Length: 230
"@xmpp" : "urn:xmpp:xbosh" }
}
}
-
+
HTTP/1.1 200 OK
Content-Type: application/jsonrequest
Content-Length: 513
@@ -141,140 +139,139 @@ Content-Length: 513
}
}
}
-
-
+
<tag>txt-value</tag>
-
- JSON:
+ JSON:
+
{ "tag" : "txt-value" }
-
-
+
<tag>
<tag2>txt-value</tag2>
</tag>
-
- JSON:
+ JSON:
+
{ "tag" : {
"$" : {
"tag2" : "txt-value" }
}
}
-
-
+
<tag>
<tag2>txt-value1</tag2>
<tag2>txt-value2</tag2>
</tag>
-
- JSON:
+ JSON:
+
{ "tag" : {
"$" : {
"tag2" : [ "txt-value1", "txt-value2" ] }
}
}
-
-
+
<tag attr="attr-value" />
-
- JSON:
+ JSON:
+
{ "tag" : { "attr" : "attr-value" } }
-
-
+
<tag attr="attr-value1" attr="attr-value2" />
-
- JSON:
+ JSON:
+
{ "tag" : {
"attr" : [ "attr-value1", "attr-value2" ] }
}
-
-
+
<tag>
<tag2 attr="attr-value1" />
<tag2 attr="attr-value2" />
</tag>
-
- JSON:
+ JSON:
+
{ "tag" : {
"tag2" : [
{ "attr" : "attr-value1" },
{ "attr" : "attr-value2" } ]
}
}
-
-
+
<tag xmlns:ns="ns-value" />
-
- JSON:
+ JSON:
+
{ "tag" : {
"xmlns" : {
"@ns" : "attr-value" }
}
}
-
-
+
<tag xmlns="root-value" xmlns:ns="ns-value" />
-
- JSON:
+ JSON:
+
{ "tag" : {
"xmlns" : {
"$" : "root-value",
"@ns" : "attr-value" }
}
}
-
-
+
<ns:tag attr="attr-value" />
-
- JSON:
+ JSON:
+
{ "tag" : {
"$$" : "ns",
"attr" : "attr-value" }
}
-
-
+
<tag attr="attr-value">txt-value</tag>
-
- JSON:
+ JSON:
+
{ "tag" : {
"attr" : "attr-value",
"$" : "txt-value" }
}
-
-
+
<ns:tag attr="attr-value">txt-value</tag>
-
- JSON:
+ JSON:
+
{ "tag" : {
"$$" : "ns",
"attr" : "attr-value",
"$" : "txt-value" }
}
-
+
+
var s = '{ "key" : "value" }';
var sObj = JSON.parse(s); // sObj = { key : "value" };
var sStr = JSON.stringify(sObj); // sStr = '{"key":"value"}';
-
Javascript variable naming doesn't support full colon characters ':'. Intented conversion between JSON and JS-objects is based on native JavaScript class JSON, more spesifically methods JSON.stringify() for converting object to JSON, and JSON.parse() from JSON to object.
- Because of this namespace definitions are constructed hiearchically and their scope is within tag it is defined. Currently only reserved namespace name is 'xml'.
Linked Process is a protocol for Internet-scale, general-purpose distributed computing. With an implementation of this protocol, any computing device with an Internet connection can contribute computing resources to a user-generated compute cloud. +
Within the category of computing devices, Linked Process makes a distinction between resource consumers (devices making use of non-local computing resources) and a resource providers (devices offering computing resources)
- After the previous <manage_bindings/> stanza has been processed by the virtual machine, it is possible to use the bindings in a statement. For example, in JavaScript + After the previous <manage_bindings/> stanza has been processed by the virtual machine, it is possible to use the bindings in a statement. For example, in JavaScript
var fact = name + " knows josh and peter";
- will set fact to the value "marko knows josh and peter" as well as make it an accessible binding.
+ will set fact to the value "marko knows josh and peter" as well as make it an accessible binding.
- A useful aspect of <manage_bindings/> is that it can be used to track the state of a variable during the execution of a job. For example, suppose the following job is submitted to a JavaScript virtual machine.var x = 1.0;
+ A useful aspect of <manage_bindings/> is that it can be used to track the state of a variable during the execution of a job. For example, suppose the following job is submitted to a JavaScript virtual machine.
var x = 1.0;
while(true) {
x = x + 0.0001;
}
- This job will continue indefinitely (or until it is timed out by the virtual machine). However, during its execution, it is possible to determine the current state of x using <manage_bindings/>. Each get-based <manage_bindings/> call should return a larger x value.
+ This job will continue indefinitely (or until it is timed out by the virtual machine). However, during its execution, it is possible to determine the current state of x using <manage_bindings/>. Each get-based <manage_bindings/> call should return a larger x value.
The following namespaces are defined by Linked Process:
As with anything, there are no hard and fast rules. If there were, they might look like these. First, for devices:
And for servers, similar rules apply:
Finally, protocol designers should aim to minimize any responses required from the handset, and ensure keepalive traffic, if any, fits inside FACH wherever possible.
Because of the ability to spoof the &MOVED; element, the client SHOULD - NOT automatically subscribe to the &MOVED; element target
. + NOT automatically subscribe to the &MOVED; element target.The client MAY include initial configuration and occupant list (the list MUST NOT include the creator). The server MAY allow sending incomplete configuration form. In such case the server MUST use default values for missing fields. The server MAY enforce a minimal occupant list length.
The service MAY either give the creator the 'owner' or 'member' status. In the latter case all users are equal.
Upon room creation success, the service MUST reply with an empty IQ result.
-The following rules (similar to the ones relevant to the affiliation change request) apply to the occupant list: -
The following rules (similar to the ones relevant to the affiliation change request) apply to the occupant list:
+After the room is created (but before receiving IQ result), new occupants (including creator) receive &MESSAGE; from the room with their affiliations (stanza MUST include only recipient's affiliation) and initial room version. <prev-version /> element MUST NOT be included.
On success the server will reply with result IQ with all changed items. BEFORE returning the IQ result, the service MUST route a message with affiliation change to all relevant users.
+On success the server will reply with result IQ with all changed items. BEFORE returning the IQ result, the service MUST route a message with affiliation change to all relevant users.
Newcomers, i.e. users that were not occupants before the change, SHOULD receive only their own affiliation and SHOULD NOT receive <prev-version /> element.
The notifications must include both the new and old room version (<version /> and <prev-version /> respectively) string (except for the ones directed to users that have been removed from the room).
The notifications contain a list of items. The item list may be different from the list in IQ set, because some of the changes may require additional operations, e.g. choosing new owner when the old one leaves. Users, that are still in the room after change, will receive full change list. Users, that have been removed from the room with the request, will get only one item: themselves with affiliation 'none'.
@@ -1007,13 +1006,12 @@If the request sender does not have sufficient privileges (but is a room occupant), the service MUST reply with a 'not-allowed' error.
-It occurs in the following cases: -
It occurs in the following cases:
+MUC Light service may be abused by malicious users, e.g. due to replicating single message for every room occupant. The list below contains suggested configurable limits that SHOULD be implemented.
The service features that might vary depending on specific application are included as well.
--
Jingle XEP-0166 is used to negotiate peer to peer media sessions. Muji is a way to coordinate Jingle sessions between a group of people. -Muji conferences are held in XEP-0045 rooms. +Muji conferences are held in XEP-0045 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. +payload each content that they provide once.
-Participants are not required to participate all the contents that are +Participants are not required to participate all the contents that are available. For example, a Muji client might choose to only request audio -streams. +streams.
]]>
- The client MUST then wait until the MUC rebroadcasts its presence message,
+ 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. + take part in.
]]>
-
- - - When a client adds a payload ID to a content description, it MUST have the +
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 defines a payload type with ID 98, codec Speex and a a clock rate of 8000 @@ -170,7 +167,7 @@ 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. + element as part of the Muji section.
]]>
- The client MUST then wait until the MUC rebroadcasts its presence message,
+ 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. + element in their presence to finish their changes.
- Afterwards the client should add the new content to the muji section of its +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. + participants it shared the content with.
]]>
-
First draft.
@@ -197,8 +197,8 @@
Most of the examples in this document use the scenario of Miranda and Ferdinand playing chess in Act V, Scene I of Shakespeare's The Tempest,
+ represented here as the "island-chess@games.shakespeare.lit" room. The characters are as follows: The following affiliations are defined: Owners are allowed to do what they like (saving/loading, change match options, etc.)
except in unmoderated matches. This match type restricts the use of owner privileges to specific room statuses.
Users with no affiliation SHALL NOT enter members-only matches.
- Besides that, these users have the same privileges as members.
+ Besides that, these users have the same privileges as members. The ways in which a user's affiliation changes are well-defined.
Sometimes the change results from the user's own action (e.g., registering as a member of the match),
whereas sometimes the change results from an action taken by an owner.
If a user's affiliation changes, a MUG service implementation MUST change the user's affiliation to reflect the change
- and communicate that to all occupants.
+ and communicate that to all occupants. It can be useful to invite other users to a room in which one is an occupant.
To do this, a MUG client sends XML of the following form to the &ROOM; itself
adding an &INVITE; element for every invitee.
- (the reason is OPTIONAL and the message MUST be explicitly or implicitly of type "normal"):
+ (the reason is OPTIONAL and the message MUST be explicitly or implicitly of type "normal"): A given deployment MAY wish to redirect users to another medium (e.g., a website) for further stages of registration, rather than allowing in-band registration. The recommended approach is to include only the A given deployment MAY wish to redirect users to another medium (e.g., a website) for further stages of registration, rather than allowing in-band registration. The recommended approach is to include only the <instructions/> element rather than the required fields or a data form in the IQ result, as well as a URL encoded using &xep0066; While SASL provides an excellent framework that has served us well over the past 18 years, a number of shortcomings in the profile - the syntax binding to XMPP - that is in use. This specification addresses a number of shortfalls: The new SASL profile documented herein is primarily a syntactic change to allow extensibility, combined with removal of the (largely) redundant stream restart, and additional results beyond total success or abject failure. Although initiating entities, in general, use SASL, and receiving entities offer it, the SASL specification and common parlance both use "Client " and "Server"; this specification uses Client and Server and assumes C2S links. This is not intended to preclude use of this SASL profile on S2S links. The term "SASL2" is used to mean the new SASL profile specified in this document; however the same RFC 4422 definition of SASL (and SASL profiles) applies. Examples often use hypothetical SASL mechanisms and sub-extensions; this specification does not intend to make a position on any particular SASL mechanism, and the Mandatory To Implement mechanisms are unaffected. Servers capable of SASL2 offer a stream feature of <mechanisms/>, qualified by the "urn:xmpp:sasl:0" namespace. This in turn contains one or more <mechanism/> elements in the same namespace, and potentially other elements (for example, the <hostname/> element defined within XEP-0233). Note that SASL2 is impossible for clients to initiate without at least one mechanism being available, and therefore MUST NOT be offered. The feature so advertised, and its child content, SHOULD be stable for the given stream to and from attributes and encryption state, and therefore MAY be cached by clients for later connections. The Service Name used by XMPP is unchanged from RFC 6120. In all cases, both Clients and Servers encode SASL exchanges using Base 64 encoding. This SHOULD NOT include any line wrapping or other whitespace. As the form <element/> is equivalent to <element></element>, these both indicate an empty string, which is used to indicate no data (ie, the absence of the data). In order to explicitly transmit a zero-length SASL challenge or response, the sending party sends a single equals sign character ("="). Clients, upon observing this stream feature, initiate the authentication by the use of the <authenticate/> top-level element, within the same namespace. The nature of this element is to inform the server about properties of the final stream state, as well as initiate authentication itself. To achieve the latter, it has a single mandatory attribute of "mechanism", with a string value of a mechanism name offered by the Server in the stream feature, and an optional child element of <initial-response/>, containing a base64-encoded SASL Initial Response. On subsequent connections, if a Client has previously cache the stream feature, the Client MAY choose to send it before seeing the stream features - sending it "pipelined" with the Stream Open tag for example. In order to provide support for other desired stream states beyond authentication, additional child elements are used. For example, a hypothetical XEP-0198 session resumption element might be included, and/or Resource Binding requests. Server Challenges MAY then be sent. Each Challenge MUST be responded to by a Client in a Client Response. These are not extensible, and contain the corresponding base64 encoded SASL data: At any time while authentication is in progress, neither Client nor Server sends any element (including stanzas) or other data except the top-level elements defined herein. Clients MUST NOT send whitespace, and MUST send only <response/> elements as appropriate or an <abort/> element to immediately cause an error. Servers MUST disconnect Clients immediately if any other traffic is received. Servers are similarly REQUIRED to send no whitespace, and only the <response/> and completion elements from the section below. Authentication may complete in one of three ways. It may complete successfully, in which case the client is authenticated. It may also fail, in which case the client is not authenticated and the stream and session state remain entirely unchanged. Finally, it may have completed successfully, but further interaction is required - for example, a password change or second-factor authentication. If the Client is now authenticated, the Server sends a <success/> element, which contains an OPTIONAL <additional-data/> element containing SASL additional data. It also contains a <authorization-identity/> element containing the negotiated identity - this is a bare JID, unless resource binding has occurred, in which case it is a full JID. Other extension elements MAY also be contained by the <success/> element. Any security layer negotiated SHALL take effect after the ">" octet of the closing tag (ie, immediately after "</success>"). A <failure/> element is used by the server to terminate the authentication attempt. It MAY contain application-specific error codes, and MAY contain a textual error. It MUST contain one of the SASL error codes from RFC 6120 Section 6.5. A <continue/> element is used to indicate that while the SASL exchange was successful, it is insufficient to allow authentication at this time. This can be used to indicate that the Client needs to perform a Second Factor Authentication ("2FA"), or is required to change password. These are conducted as additional SASL mechanisms. Such SASL mechanisms MUST NOT change the authorization identifier, or introduce any security layer. The authorization identifer transmitted during the subsequent <success/>, and any security layer which comes into effect after the eventual <success/>, therefore MUST be that of the first mechanism. The element contains a <mechanisms/> element, as defined above as a stream feature, containing suitable mechanisms. It MAY contain an <additional-data/> element, as the <success/> element does. Finally, it MAY contain a <text/> element, which can contain human-readable data explaining the nature of the step required. Clients respond with a <next-authenticate/> element, which has a single mandatory attribute of "mechanism", containing the selected mechanism name, and contains an OPTIONAL base64 encoded initial response. This provides pointers and/or clarifications to the in the order and manner defined in RFC 4422, section 4. The service name SHALL be "xmpp", as defined by RFC 6120. Servers list mechanisms during stream features (See ) and within the <continue/> element (See ). TODO: Neither this specification nor RFC 6120 allow clients access to the mechanism list after SASL negotiation...? Clients initiate using the <authenticate/> top level element (See , and after any <continue/> with the <next-authenticate/> message (See ). See . See . If a Client specifies an authorization string which is non-empty, the identifier is normalized by treating it as a JID, and performing normalization as described in RFC 7622. Clients MAY abort unilaterally by sending <abort/> as specified in . Servers MAY abort unliterally by sending <failure/> with the <aborted/> error code as defined in . See . Option (a) is used - any SASL Security Layer is applied first to data being sent, and TLS applied last. Although the <continue/> concept does use multiple SASL sequences, only the first SASL mechanism used is considered an authentication, and only the first can negotiate a security layer. In particular, once <success/> has been sent by the server, any further <authenticate/> element MUST result in a stream error. Relative to the SASL profile documented in RFC 6120, this introduces more data unprotected by any security layer negotiated by SASL itself. This XEP requires no interaction with &IANA;. None. The author wishes to share any credit with many members of the community, including Lance Stout, Ralph Meijer, and Florian Schmaus. Adapter publishes device meta data: To make it easier for agents to sort through available devices and seonsors, it is desirable for implementations to use a common set of types. The following device types are defined:
-After specifying the units of the transducer device, you can then also specify an SI scalar value as powers of 10. The following example shows how to specify a sensor in centimeters.
+After specifying the units of the transducer device, you can then also specify an SI scalar value as powers of 10. The following example shows how to specify a sensor in centimeters. The following example shows how to specify a sensor in kilograms. The following example shows how to specify a sensor in kilowatt-second with a resolution to the nearest 0.1 kWh. If no unitScaler value is specified, then a unitScaler of 0 (aka 10**0 = 1) is assumed.
Values for a transducer are published via the data value node: OPTIONAL: Instead of putting all of the transducer values into a single data value node, an adapter MAY want to break up the transducer values into multiple nodes.
For example, an adapter may want to do this for reasons of security (allow some entities to subscribe/publish to transducer Y1 and a different set of entities to subscribe/publish to transducer Y2).
@@ -804,7 +796,7 @@ The information in the meta node is used by consumers to determine which node th
Values for a transducer can also be set by publishing to the data value node. Actuation takes place as a split-phase operation with an action signal (publish) followed by a completion callback (subscribed message).
@@ -1153,12 +1143,11 @@ Event Node ID: 4d4335b5-4134-11e0-9207-0800200c9a66_data
]]>
- Two things to note:
+ Two things to note:
To continue this example further, let's assume an agent is subscribed to the data value node and can also publish to the tid2 node which controls the light.
In this case, an agent will receive notification that movement was sensed and can take action.
@@ -1302,7 +1291,7 @@ If an adapter chooses to publish a subset of transducer data (for example, only
the changed values), it is possible for consumers who are off line or recently
activated to miss older values.
There are a variety of ways to handle this depending on the needs of the
-implementor including (but not limited to):
+implementor including (but not limited to): If an implementaion chooses to put some transducers values into their own nodes
(instead of putting them all into the data value node), remember that a transducer value MUST appear in either the data value node or its own node, but not both.
The meta node indicates to consumers which node they should subscribe to in order to be notified when new data is available for their chosen transducer.
There are various spim protection methods exist in XMPP: &xep0016;, &xep0158;, &xep0191;, &xep0268; and &xep0275;. But they may not be sufficient enough:
+ There are various spim protection methods exist in XMPP: &xep0016;, &xep0158;, &xep0191;, &xep0268; and &xep0275;. But they may not be sufficient enough: 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.
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:
+ 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: 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:
During the game, players change in turn, each of them MUST send only one move at a time.
It MUST possess these attributes:
-
@@ -164,8 +164,8 @@
Note: The text that follows assumes that implementors have
- read and understood XEP-0050, password
- generation algorithms described in &rfc4226; and RFC 6238,
+ read and understood &xep0050;, password
+ generation algorithms described in &rfc4226; and &rfc6238;,
and randomness requirements described in &rfc4086;,
and know about one-time pads and perfect secrecy.
Time-Based One-Time Password (TOTP) algorithm described in
- RFC 6238 is an extension of the HMAC-based
- One-Time Password (HOTP) algorithm defined in RFC 4226,
+ &rfc6238; is an extension of the HMAC-based
+ One-Time Password (HOTP) algorithm defined in &rfc4226;,
to support the time-based moving factor. In TOTP, time
reference and a time step replaces the counter in the HOTP
computation.
@@ -431,14 +431,14 @@
- In each case, the Verifier MAY check Prover's JID right after
+ In each case, the Verifier MAY check Prover's JID right after
receiving the first Ad-Hoc command or after a succesful verification
- process.
+ process. If Prover's JID is not approved, the Verifier SHOULD
+ reply with &forbidden; error message. After the a succesful verification the Verifier can, e.g., A user may obtain their own rating by sending an IQ-get with no to address and an element qualified by the ‘rating’ namespace. The server should return an IQ result stanza with <rating/> element: In installations that run as chat servers, moderation of spam users can be delivered to online users and administrators. Users receiving spam from a bare JID can send an IQ stanza to the server that increases the user rating.
JIDs that are critical to server functionality or admins should have a
- permanent OPTIONAL. The five XEP types are described in the following sections. The approving body for all Standards Track, Informational, and Historical XEPs is the XMPP Council; the approving body for Humorous XEPs in the XMPP Extensions Editor; and the approving body for Procedural XEPs may be either the &BOARD; or the XMPP Council. The approving body for all Standards Track, Informational, and Historical XEPs is the XMPP Council; the approving body for Humorous XEPs is the XMPP Extensions Editor; and the approving body for Procedural XEPs may be either the &BOARD; or the XMPP Council. This document focuses primarily on Standards Track XEPs since they are the vehicle for defining new protocols, but also discusses the other XEP types. A Standards Track XEP defines one of the following: Every XMPP Extension Protocol specification must contain a section entitled "Security Considerations", detailing security concerns or features related to the proposal; in particular, a Standards Track XEP should list the security threats that the protocol addresses and does not address, as well as security issues related to implementation of the protocol and deployment of such implementations. XEP authors should refer to &rfc3552; for helpful information about documenting security considerations and should also confer with the XMPP Extensions Editor and/or XMPP Council regarding this important task. Some XMPP Extension Protocols may require interaction with &IANA;. The IANA acts as a clearinghouse to assign and coordinate the use of numerous Internet protocol parameters, such as MIME types and port numbers (e.g., the TCP ports 5222, 5269, and 5280 used by the XMPP developer community are registered with the IANA). Whether or not a XEP requires registration of parameters with the IANA, that fact must be noted and explained in a distinct section of the XEP entitled "IANA Considerations". Registration with the IANA must not occur until the registration has been approbved by the XMPP Council (e.g., by advancement of a XEP to a status of Draft or Active), and must be initiated by the XMPP Registrar in consultation with the XEP author, not by the XEP author directly with the IANA. Some XMPP Extension Protocols may require interaction with &IANA;. The IANA acts as a clearinghouse to assign and coordinate the use of numerous Internet protocol parameters, such as MIME types and port numbers (e.g., the TCP ports 5222, 5269, and 5280 used by the XMPP developer community are registered with the IANA). Whether or not a XEP requires registration of parameters with the IANA, that fact must be noted and explained in a distinct section of the XEP entitled "IANA Considerations". Registration with the IANA must not occur until the registration has been approved by the XMPP Council (e.g., by advancement of a XEP to a status of Draft or Active), and must be initiated by the XMPP Registrar in consultation with the XEP author, not by the XEP author directly with the IANA. The ®ISTRAR; performs a function similar to the IANA, although limited to the XMPP developer community. It does so by reserving protocol namespaces and by uniquely assigning parameters for use in the context of XMPP protocols (for example, the categories and types used in &xep0030;). XML schema modified so that no ordering is required between disco#info children. Clarify wording for a client re-syncing to a MUC Introduce <x/> tag in MUC-PMs to support better Carbon delivery. Before attempting to enter the room, a MUC-compliant client SHOULD first discover its reserved room nickname (if any) by following the protocol defined in the Discovering Reserved Room Nickname section of this document. When a MUC service receives an <x/> tagged join stanza from an already-joined client (as identified by the client's full JID), the service should assume that the client lost its synchronization, and therefore it SHOULD send exactly the same stanzas to the client as if it actually just joined the MUC. The server MAY also send a presence update to the other participants according to the received join presence. Since each occupant has its own occupant JID, an occupant can send a "private message" to a selected occupant via the service by sending a message to the intended recipient's occupant JID. The message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified (i.e., a normal message). This privilege is controlled by the "muc#roomconfig_allowpm" room configuration option. To allow for proper synchronization of these messages to the user's other clients by &xep0280;, the sending client SHOULD add an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace to the message. Note: because this requirement was only added in revision 1.28 of this XEP, receiving entities MUST NOT rely on the existence of the <x/> element on private messages for proper processing. The service is responsible for changing the 'from' address to the sender's occupant JID and delivering the message to the intended recipient's full JID. The service is responsible for changing the 'from' address to the sender's occupant JID and delivering the message to the intended recipient's full JID. The service SHOULD add the <x/> element if the message does not contain it already. If the sender attempts to send a private message of type "groupchat" to a particular occupant, the service MUST refuse to deliver the message (since the recipient's client would expect in-room messages to be of type "groupchat") and return a &badrequest; error to the sender: Fix examples using invalid XEP-0082 dates. Clarify behaviour of publish-options. Fields must be registered The <publish-options/> element SHOULD contain a data form (see XEP-0004), whose FORM_TYPE SHOULD be "http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068). How the fields are to be handled is up to the the pubsub service, which in the language of XEP-0004 functions as a form-processing entity. For example, the service may treat the field as a precondition, in which case the service should proceed as follows: The <publish-options/> element MUST contain a data form (see XEP-0004), whose FORM_TYPE MUST be "http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068). Fields and their behaviour MUST be registered with the XMPP Registrar. Each field MUST specify whether it defines METADATA to be attached to the item, a per-item OVERRIDE of the node configuration, or a PRECONDITION to be checked against the node configuration. A pubsub service advertising support for publishing options MUST reject publications with unknown fields. A field defined as a precondition MUST be processed as follows: If the Proxy is unable to act as a StreamHost, the Proxy MUST return an error to the Requester, which SHOULD be ¬allowed;. If the Proxy is unable to act as a StreamHost, the Proxy MUST return an error to the Requester, which SHOULD be ¬allowed;. Make use of <hash-used/> from XEP-0300. One or more <hash/> elements MUST be present when offering a file, but those elements MAY be empty if the hash has not yet been computed. If there is no computed hash value, the <hash/> element(s) MUST possess an 'algo' attribute specifying which hash algorithm will be used. Once a hash has been calculated by the File Sender, the File Sender SHOULD inform the File Receiver of the hash value as described in Checksum. One or more <hash/> elements MUST be present when offering a file, but those elements MAY be empty if the hash has not yet been computed. If there is no computed hash value, the <hash/> element(s) MUST possess an 'algo' attribute specifying which hash algorithm will be used. Once a hash has been calculated by the File Sender, the File Sender SHOULD inform the File Receiver of the hash value as described in Checksum. Additional elements MAY be included as children of the <file/> element to provide additional metadata about the file, such as &xep0264;. The optional <range/> element MAY possess two attributes: At any time during the lifetime of the file transfer session, the File Sender can communicate the checksum of the file to the File Receiver. This can be done in the session-initiate message if the File Sender already knows the checksum, as shown above in Example 3. After the session-initiate message, this can also be done by sending a session-info message containing a <checksum/> element qualified by the 'urn:xmpp:jingle:apps:file-transfer:5' namespace. The <checksum/> element SHOULD contain 'creator' and 'name' attributes sufficient to identitfy the content the checksum belongs to. Additionally, the <checksum/> element MUST contain a <file/> element which MUST contain at least one <hash/> element qualified by the 'urn:xmpp:hashes:2' namespace. Each <hash/> element contains a checksum of the file data produced in accordance with the hashing function specified by the 'algo' attribute, which MUST be one of the functions listed in the &ianahashes;. After the session-initiate message, this can also be done by sending a session-info message containing a <checksum/> element qualified by the 'urn:xmpp:jingle:apps:file-transfer:5' namespace. In such a case however, the session-initiate message MUST contain a <hash-used/> element. The <checksum/> element SHOULD contain 'creator' and 'name' attributes sufficient to identitfy the content the checksum belongs to. Additionally, the <checksum/> element MUST contain a <file/> element which MUST contain at least one <hash/> or <hash-used/> element qualified by the 'urn:xmpp:hashes:2' namespace. Each <hash/> element contains a checksum of the file data produced in accordance with the hashing function specified by the 'algo' attribute, which MUST be one of the functions listed in the &ianahashes;. Thanks to Diana Cionoiu, Olivier Crête, Viktor Fast, Philipp Hancke, Waqas Hussain, Justin Karneges, Steffen Larsen, Yann Leboulanger, Marcus Lundblad, Robert McQueen, Joe Maissel, Glenn Maynard, Ali Sabil, Sjoerd Simons, Will Thompson, Matthew Wild, and Jiří Zárevúcky for their feedback. Thanks to Diana Cionoiu, Olivier Crête, Viktor Fast, Philipp Hancke, Waqas Hussain, Justin Karneges, Steffen Larsen, Yann Leboulanger, Marcus Lundblad, Robert McQueen, Joe Maissel, Glenn Maynard, Ali Sabil, Sjoerd Simons, Will Thompson, Matthew Wild, Paul Schaub and Jiří Zárevúcky for their feedback. Added TURN Credentials Service Support. 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. A Jingle Client can request volative TURN credentials, to be used in cases where connectivity check is a requirement. Like, for example, WebRTC. The concept and mechanism is quite similar to the RFC draft REST API For Access To TURN Services'. TURN provides an access control mechanism described in &rfc5389;, where long-term credentials are provided as part of the TURN protocol. Therefore the credentials provided in this Jingle Nodes mechanism are time-limited, but SHOULD be used as long-term credentials, when authentication against a TURN Server.
+
+ Note: There is no need to run TURN server or support within a Jingle Relay. This mechanism allows decoupled deployment of distributed TURN Servers, without the requirement of database based authentication.
+ The &SERVICES; element MAY be empty or contain &RELAY; and/or &TRACKER; elements. The &SERVICES; element MAY be empty or contain &RELAY;, &STUN; and/or &TRACKER; elements. The attributes of the &RELAY; and &TRACKER; element are as follows. The attributes of the &TURN; element are as follows. The duration in seconds for which the provided credentials are valid. The usual and recommended value is 86400 seconds (one day). The TURN Server URI as described in I-D.petithuguenin-behave-turn-uris WebRTC's TURN request uses the 'username' value for its USERNAME and PASSWORD attributes, for the input to the MESSAGE-INTEGRITY hash. Along with 'username', WebRTC's TURN request uses the 'password' value for its USERNAME and PASSWORD attributes, for the input to the MESSAGE-INTEGRITY hash. To advertise its support for the Jingle Nodes support, when replying to &xep0030; information requests an entity MUST return URNs for any version of this protocol that the entity supports -- e.g., "http://jabber.org/protocol/jinglenodes" for this version&VNOTE;. A Jingle Client that uses WebRTC, therefore requiring a TURN Server and its credentials to successfully alocate channels. This specification describes a simple way of discovering TURN Services and retrieving credentials to successfully allocate channels.
+ This also simplifies deployment and distribution of TURN servers, since its stateless authentication does not require connectivity to database authoriztion services. A Jingle Client with STUN support but no TURN support can use Relay Node Services as the fallback candidate instead of a TURN candidate. For instance, after a connectivity check proccess, none of the direct candidates worked. The Client can use the Relay Node Candidate as the fallback candidate(the lowest priority candidate).
While the CPU cost of compression may directly translate to higher power
@@ -122,13 +135,10 @@
power per bit than 3G networks as will be seen later in this document.
However, CPU usage is also not guaranteed to rise due to compression.
In the aforementioned deployment of stream compression, a
- decrease in CPU utilization by a factor of 0.60 was observed due
- to the fact that there were fewer packets that needed to be handled by the
- OS (which also takes CPU time), and, potentially more importantly, less
- data that needed to be TLS-encrypted (which is a much more CPU-expensive
- operation than compression).
+ decrease in CPU utilization by a factor of 0.60 was observed,
+ presumably due to reductions in TLS and packet handling overhead.
Therefore CPU time spent on compression (for ZLIB, at least; other
- algorithms were not tested) should be considered negligable.
+ algorithms were not tested) can be considered negligable.
Supporting compression and performming a full flush on stanza boundaries
@@ -140,12 +150,10 @@
While the wide spread adoption of LTE has dramatically increased available
bandwidth on mobile devices, it has also increased power consumption.
According to one study, early LTE devices consumed 5–20% more power
- than their 3G counterparts
-
XMPP server and client implementers, bearing this increased power usage in
@@ -153,12 +161,11 @@
traffic to minimize network usage.
For the downlink, LTE user equipment
(UE) utilizes Orthogonal Frequency Division Multiplexing (OFDM), which is
- somewhat inefficient
-
If one is on 3G, transmitting a small amount of data will cause the
radio to enter FACH mode which is significantly cheaper than its high
power mode.
On LTE radios, however, transmitting small amounts of data is vastly
- more expensive per bit due to the higher tail-times (the time it takes
- for the radio to change state).
+ more expensive per bit due to the higher tail-time (the time it takes
+ for the radio to change state) of approximately 11 seconds&huang12;.
On LTE radios, one should transmit as much data from the client as
possible when the radio is already on (eg. by placing messages in a send
queue and executing the queue as a batch when the radio is on).
@@ -199,10 +206,8 @@
These rules also apply to server operators: If the server receives data,
- the phones radio is already on therefore you should send any pending
- data.
- Batching data to be sent and sending it all at once will help reduce
- power consumption.
+ the phones radio is already on, therefore you should flush any pending
+ data as soon as possible after receiving data from a client.
&xep0138; provides stream level compression. &xep0322; allows XMPP streams to use the EXI XML format.
&xep0115; provides a mechanism for caching, and hence eliding, the
disco#info requests needed to negotiate optional features.
@@ -247,8 +251,8 @@
This XEP was originally written by Dave Cridland, and parts of his
original work were used in this rewrite.
- Thanks to Atlassian for allowing me to release hard numbers from their
- XMPP compression deployment.
+ Thanks to Atlassian (HipChat) for allowing me to release numbers from
+ their XMPP compression deployment.
Clarify textual content of the <hash/> element. Add hash-used element An XMPP protocol can include more than one instance of the <hash/> element, as long as each one has a different value for the 'algo' attribute: In certain scenarios it makes sense to communicate the hash algorithm that is used prior to the calculation of the hash value. The value of the 'algo' attribute MUST be one of the values from the &ianahashes; maintained by &IANA;, or one of the values
defined in the following table. Thanks to Dave Cridland, Waqas Hussain, Glenn Maynard, Remko
- Tronçon, Christian Schudt, and Florian Schmaus for their input. Make the schema more precise about a date being a xs:dateTime. Be precise about the &xep0082; profile used. This protocol describes a way to communicate a user's last interaction time with other XMPP entities over &PRESENCE; stanzas. For the purposes of this document, user interaction here refers to a human end user interacting with her device by means of a keyboard, mouse, touch screen, and so on. Based on this information XMPP clients can display the time a contact went idle or a duration for how long a contact has been idle, thereby allowing end users to estimate the expected responsiveness of their contacts. This protocol uses absolute timestamps formatted according to &xep0082;, indicated as value of the 'since' attribute in the <idle/> element. This protocol uses absolute timestamps formatted according to the DateTime profile of &xep0082;, indicated as value of the 'since' attribute in the <idle/> element. Experience has shown a number of issues with &xep0256;: This document addresses the following requirements: The user's server SHOULD then generate a form request using &xep0004; to client in order to ask user if he's OK with granting the permission to the remote entity. The "challenge" form field is generated by the server and is used to identify the client's response. The server also MUST immediatly answer to the request IQ. The user's server SHOULD then generate a form request using &xep0004; to client in order to ask user if they are OK with granting the permission to the remote entity. The "challenge" form field is generated by the server and is used to identify the client's response. The server also MUST immediatly answer to the request IQ. NOTE: if the entity is already granted with the permission, the server SHOULD immediatly answer with a success response and skip querying the user. User can ask the server to provide a list of components or servers which have permissions to edit their roster. Clarify that the CSI state is not restored when the stream is resumed. After a previous stream was resumed using mechanisms like
+ &xep0198;, the CSI state is not restored. That is, stream
+ resumption does not affect the current CSI state, which always
+ defaults to 'active' for new and resumed streams. Clients wishing
+ to immediately go to the inactive state should do so after stream
+ resumption. To protect the privacy of users, servers MUST NOT reveal the clients active/inactive state to other
@@ -182,4 +196,7 @@ and responds to the ping with a pong -->
]]>
Thanks to Florian Schmaus for his feedback. Each PubSub node is a delivery target for the Push Service, which could represent multiple devices for a single user. In order to prevent information leaks, each node SHOULD be configured with a 'whitelist' access model so that only trusted entities are able to view or subscribe to published notifications. Furthermore, the 'publish-only' affiliation SHOULD be used to allow acceptable entities (such as the user's bare JID) to publish to the node to trigger notifications. Care SHOULD be taken to ensure that publish requests are coming from the user's server and not from other third-party client applications using the full JID of a user. A Push Service MAY opt to only accept or further process publish requests from bare JIDs to ensure that only a user's server is able to publish, but it SHOULD instead use publish options with credentials shared only with the user's server (see Enabling Notifications). In order to prevent information leaks, each node SHOULD be configured with a 'whitelist' access model so that only trusted entities are able to view or subscribe to published notifications. Furthermore, the 'publish-only' affiliation SHOULD be used to allow acceptable entities (such as the server JID and the user's bare JID) to publish to the node to trigger notifications. Care SHOULD be taken to ensure that publish requests are coming from the user's server and not from other third-party client applications using the full JID of a user. A Push Service MAY opt to only accept or further process publish requests from server JIDs and bare user JIDs to ensure that only a user's server is able to publish, but it SHOULD instead use publish options with credentials shared only with the user's server (see Enabling Notifications). Other elements MAY be included if relevant for the notification. This XEP introduces unique and stable IDs for stanzas, which are beneficial in various ways. For example, they can be used together with &xep0313; to uniquely identify a message within an archive. They are also useful in the context of &xep0045; conferences, as they allow to identify a message reflected by a MUC service back to the originating entity. This XEP introduces unique and stable IDs for messages, which are beneficial in various ways. For example, they can be used together with &xep0313; to uniquely identify a message within an archive. They are also useful in the context of &xep0045; conferences, as they allow to identify a message reflected by a MUC service back to the originating entity. In order to create a &stanza-id; extension element, the creating XMPP entity generates and sets the value of the 'id' attribute, and puts its own XMPP address as value of the 'by' attribute. The value of the 'id' attribute must be unique and stable, i.e. it MUST NOT change later for some reason within the scope of the 'by' value. Thus the IDs defined in this extension MUST be unique and stable within the scope of the generating XMPP entity. It is RECOMMENDED that the ID generating service uses UUID and the algorithm defined in &rfc4122; to generate the IDs. An entity that follows the business rules, especially the rule on overriding the ID in elements where the by atttribute matches the entities own XMPP address, SHOULD announce the 'urn:xmpp:sid:0' namespace in its disco features allowing other entities to verify that those business rules are properly enforced. The value of the 'id' attribute should not provide any further information besides the opaque ID itself. Entities observing the value MUST NOT be able to infer any information from it, e.g. the size of the message archive. The value of 'id' MUST be considered a non-secret value. Before processing the stanza ID of a message and using it for deduplication purposes or for MAM catchup, the receiving entity SHOULD ensure that the stanza ID could not have been faked, by verifying that the entity referenced in the by attribute does annouce the 'urn:xmpp:sid:0' namespace in its disco features. This document requires no interaction with &IANA;.
+ Remove Legacy MIX Namespace;
+ Add mix element in message to hold MIX additional information;
+ Roster Update Clarifications;
+ Clarify when messages are delivered to clients;
+ Extend Roster Get to select format;
+ Ensure that text defining attributes and elements reference the namespace;
+ Change mix_nick_register to nick-register;
+ Separate namespace for roster information;
+ rename jidmap2 to jidmap-visible;
+ Namespace bump to mix:1;
+ Correct from in response of join/leave IQs;
+ Add capability for MIX in client's server;
+ Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. The nick associated with the user is mandatory and is stored in the item. The nick for each channel participant MUST be different to the nick of other participants.
+ Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:1' namespace. The nick associated with the user is mandatory and is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants.
When a user joins a channel, the user's bare JID is added to the participants node by the MIX service. When a user leaves a channel, they are removed from the participants node. The participants node MUST NOT be directly modified using pubsub.
@@ -499,7 +518,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel.
+ The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap'. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel.
Each item is identified by proxy bare JID, mapping to the real bare JID. This node is used to give administrator access to real JIDs and participant access to real JIDs in jid-visible channels. This node MUST NOT be modified directly using pubsub.
- In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. The JID Maybe Visible Map node is a similar node to the JID Map node that is used in addition to the JID Map Node in JID Maybe Visible channels. All participants may subscribe to and access this node. It uses the same encoding as JID Map node and all participant JIDs MUST be included. Where a participant's preference is to not share the JID, the encoded participant value is the proxy JID. This will enable a user looking up a JID to clearly determine that the user preference is to not share the JID and to clearly distinguish this case from an erroneous proxy JID.
+ The JID Maybe Visible Map node is a similar node to the JID Map node that is used in addition to the JID Map Node in JID Maybe Visible channels. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap-visible'. All participants may subscribe to and access this node. It uses the same encoding as JID Map node and all participant JIDs MUST be included. Where a participant's preference is to not share the JID, the encoded participant value is the proxy JID. This will enable a user looking up a JID to clearly determine that the user preference is to not share the JID and to clearly distinguish this case from an erroneous proxy JID.
- The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence. Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence stanza. The full proxy JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control MAY be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list.
+ The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence. Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence stanza using a <presence/> element qualified by the 'jabber:client' namespace. The full proxy JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control MAY be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list.
@@ -574,7 +592,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
- The MIX specification is built on layered services that have defined errors. This enables the core MIX specification to reflect primarily the successful use case, as in almost all cases the error reporting of the layer service provides what is needed. A message sender MUST be prepared to handle any valid error from the layer services. When a message receiver encounters an error situation, it MUST use the most appropriate layer server error to report this issue back to the sender. For example a message receiver might use the "not authorized" IQ error in response to a MIX disco that is not authorized. Errors for the following layer services need to be handled for MIX:
+ The MIX specification is built on layered services that have defined errors. This enables the core MIX specification to reflect primarily the successful use case, as in almost all cases the error reporting of the layer service provides what is needed. A message sender MUST be prepared to handle any valid error from the layer services. When a message receiver encounters an error situation, it MUST use the most appropriate layer server error to report this issue back to the sender. For example a receiving entity might use the "not authorized" error in response to a disco query that is not authorized. Errors for the following layer services need to be handled for MIX:
The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:0' feature, and the identity MUST have a category of 'conference' and a type of 'text', as shown in the following example: The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:1' feature, and the identity MUST have a category of 'conference' and a type of 'text', as shown in the following example:
- A MIX service MUST return the 'urn:xmpp:mix:0' feature and MAY return the other features listed here:
+ A MIX service MUST return the 'urn:xmpp:mix:1' feature and MAY return the other features listed here:
A MIX service MUST NOT advertise support for &xep0313;, as MAM is supported by the channels and not by the service. A MIX service MUST NOT advertise support for generic &xep0060;, as although MIX makes use of PubSub it is not a generic PubSub service. A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, and presence.
- This will lead to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.
+ A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to both messages and presence nodes. A user will typically subscribe to at least the message and/or presence nodes but MAY join and not subscribe to any nodes. The <join/> is a child element of <iq/> element. The <join/> element is qualified by the 'urn:xmpp:mix:1' namespace. The channel is specified by a 'channel' attribute in the <join/> element. The requested nodes are encoded as <subscribe/> child elements of the <join/> element.
+ The join leads to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.
The default MIX model is that only channel participants are allowed to subscribe to nodes. A MIX channel MAY allow non-participant subscription. This will be handled by clients directly subscribing to the desired PubSub nodes.
- If a user cannot be subscribed to one or more of the requested nodes (e.g., because the node does not exist), but can be subscribed to some the response simply lists the nodes successfully subscribed. If none of the nodes requested are successfully subscribed to, an error response is sent indicating the reason that the first node requested was not subscribed to. This error response will also include other nodes requested where subscription failed for the same reason.
The following response example shows a successful response to the initial request example where
@@ -1029,7 +1047,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
-
- A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request, as shown in the following example. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action.
+ A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/$gt; child element of <iq/> element. The <update-subscription/$gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The requested notes are encoded as <subscribe/> child elements of the <update-subscription/$gt; element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.
The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. This query is direct from the client to the MIX channel. The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. The request is encoded as a <user-preference/> child element of <iq/>. <user-preference/> is qualified by the 'urn:xmpp:mix:1' namespace. The result is encoded as a form child element in the <user-preference/> element. Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, a user sends a MIX "leave" command to the channel. When a user leaves the channel, the user's server will remove the channel from the user's roster. Leave commands are sent indirectly through the user's server, to enable roster removal. Leaving is initiated by a client request, as shown in the following example. Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, a user sends a MIX "leave" command to the channel. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:1' namespace, with the channel specified as a 'channel" attribute. When a user leaves the channel, the user's server will remove the channel from the user's roster. Leave commands are sent indirectly through the user's server, to enable roster removal. Leaving is initiated by a client request, as shown in the following example. When the user leaves the channel, the MIX service is responsible for unsubscribing the user from all nodes in the channel and for removing the user from the participants and presence list. If the user has online presence when the user leaves the channel, the change of presence status caused by removing the user's entry or entries from the presence node will ensure that subscribers to the presence node are correctly updated on presence status.
@@ -1342,21 +1360,21 @@ This approach enables flexible support of multiple clients for a MIX channel pa
- A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result.
+ A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. This command is a <setnick/> child element of <iq/> element. The <setnick/> element is qualified by the 'urn:xmpp:mix:1' namespace. The nick is encoded as a <nick/> child element of the <setnick/> element. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result.
- The channel will return the nick that is to be used, noting that this MAY be different to the requested nick. MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;.
+ On successful nick assignment, the channel will return the nick that is to be used, noting that this MAY be different to the requested nick. MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;. The channel MAY return a conflict error or other appropriate error.
- The response will be a list of features of the MIX channel. If Nick Registration is supported, then the result set will include <feature var="urn:xmpp:mix:0#mix_nick_register"/>.
+ The response will be a list of features of the MIX channel. If Nick Registration is supported, then the result set will include <feature var="urn:xmpp:mix:1#nick-register"/>.
To register a nick with the MIX service the user sends
- a <register/> command to the service. If the requested nick is already taken, the MIX service returns a <conflict/> error: If the requested nick is already taken and the MIX service does not assign an alternate nick, the MIX service MUST return a <conflict/> error: If the register request does not contain a <nick/> element, then the MIX service assigns one. It is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.
+ If the register request does not contain a <nick/> element, then the MIX service MUST assign one. It is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.
- A user setting status is now used as an example. Unlike in &xep0045; where coming online is a special action, coming online in MIX is implicit when presence status is set. Going offline is a achieved by setting presence status to unavailable, which removes the client full JID entry from the presence node. When a user sets a presence status, the user's server sends updated presence to the MIX channel, and the MIX service then publishes the user's availability to the "urn:xmpp:mix:nodes:presence" node. If there is not an item named by the full JID of the client with updated presence status, this item is created.
+ The server then sends the presence information to roster entries. The following example then shows the presence message from the client's server to the MIX channel.
+ The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier (the proxy JID). The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node. The presence stanza is sent from the full proxy JID of the user.
- Note that presence is associated with a client and so will have a full JID as it comes directly from the client and not from the user's server. The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier (the proxy JID). The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node. The presence stanza is sent from the full proxy JID of the client updating status.
+ Note that presence is associated with a client and so will have a full JID. The following example shows a presence message as distributed by the server to a presences subscriber.
+ The MIX channel then adds information to the message using a <mix> element qualified by the 'urn:xmpp:mix:1' namespace. This element contains two child elements:
+ The MIX channel then puts a copy of the message into the MAM archive for the channel and sends a copy of the message to each participant in
- standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's local server. The message from value is the JID of the channel. To enable sender identification, the Nick and bare proxy JID of the sender are included in the message as MIX parameters. The id of the message is the ID from the MAM archive and NOT the id used by the sender. The message placed in the MAM archive is the reflected message without a 'to' element.
- The messages sent to participants have a different message id to the originally submitted message. This does not impact most recipients, but it does not allow the message originator to correlate the message with the submitted message. To address this the MIX channel MUST include an additional element of the message copy going back to the originator's bare JID that includes the original id. This enables the originator to correlate the received message with the message submitted.
+ The messages sent to participants have a different message id to the originally submitted message. This does not impact most recipients, but it does not allow the message originator to correlate the message with the submitted message. To address this the MIX channel MUST include an additional <submission-id> element in the <mix> element of the message copy going back to the originator's bare JID. The <submission-id> element holds the original id provided by the sender. This enables the originator to correlate the received message with the message submitted.
- A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by a message with a <retract> element as shown in the following example.
+ A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by adding to the message a <retract> element qualified by the 'urn:xmpp:mix:1' namespace. The <retract> element MUST include an <id> attribute that holds the id of the original message. A message and it's retraction shown in the following example.
@@ -1706,7 +1753,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
The second approach is to leave a tombstone, which if taken MUST be done in the following manner. This is appropriate where it is desired to leave a record of the message that was redacted.
- With this approach, the original message <body> is removed and replaced with a tombstone using the <retracted> element that shows the JID of user performing the retraction and the time of the retraction.
+ With this approach, the original message <body> is removed and replaced with a tombstone using the <retracted> element qualified by the 'urn:xmpp:mix:1' namespace that shows the JID of user performing the retraction and the time of the retraction.
- The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time.
+ The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. The invitation request is encoded as an <invite/> child element of an <iq/> element. The <invite/> element is qualified by the 'urn:xmpp:mix:1' namespace. <invite/> contains an <invitation/> child element, which contain <inviter/>, <invitee/>, <channel/> and <token/> child elements.
- The inviter can now send the invitee a message containing the invitation, as shown in the following example.
+ The inviter can now send the invitee a message containing the invitation within the <message/> element, as shown in the following example.
The invitation can now be used by the invitee to join a channel. The invitation is simply added to the standard channel join, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join. The invitation can now be used by the invitee to join a channel. The <invitation/> child element is simply added to the standard channel <join/> element, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join. The invitee MAY send an acknowledgement back to the inviter, noting the status of the invitation. Values are: The invitee MAY send an acknowledgement back to the inviter, noting the status of the invitation.
+ This is encoded as an <invitation-ack/> child element of <message/> element. The <invitation-ack/> element is qualified by the 'urn:xmpp:mix:1' namespace. The <invitation-ack/> has an <invitation/> child element that encodes the invitation being acknowledged and a <value/> child element to encode the acknowledgement value.
+ <value/> has the following values:
- When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages.
+ When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages. The marker is encoded as a <marker/> child element of an <iq/> element. The <marker/> element is qualified by the 'urn:xmpp:mix:1' namespace.
- MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach. A client can determine if it has permission to create a channel on a MIX service, which MAY be used to control options presented to the user. This is achieved by a disco command on the MIX service. If the 'urn:xmpp:mix:0#create-channel' feature is returned, the user is able to create a channel.
+ MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach. A client can determine if it has permission to create a channel on a MIX service, which MAY be used to control options presented to the user. This is achieved by a disco command on the MIX service. If the 'urn:xmpp:mix:1#create-channel' feature is returned, the user is able to create a channel.
- A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). Creating and destroying a channel is done direct from a client.
+ A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a <create/> child element of <iq/> element. The <create/> is qualified by the 'urn:xmpp:mix:1' namespace. The <create/> element MUST have a 'channel' attribute to specify the channel name.
@@ -2024,10 +2073,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
-
+ The destroy operation is encoded as a <destroy/> child element of an <iq/> element. The <destroy/> element is qualified by the 'urn:xmpp:mix:1' namespace. The <destroy/> element MUST have a 'channel' attribute to specify the channel to be destroyed.
A client destroys a channel using a simple set operation, as shown in the following example.
+ The server receiving the message will then deliver the messages to all online clients. Messages are delivered to all available online resources irrespective of
+ status and resource priority.
The following example shows how the participant's server modifies the inbound message to replace the bare JID in the 'to' with a full JID for each of two active MIX clients.
+ Servers supporting the capabilities necessary to enable MIX clients MUST advertise this. A client wishing to use MIX MUST check for this capability in the server before using MIX. The capability is represented by the 'urn:xmpp:mix:account:0' feature.
+
Most interaction between a MIX client and a MIX channel is directly between the client and the channel. The participant's server relays the message but does not modify the messages. In particular configuration management and discovery is direct. Interaction will be direct, unless explicitly stated otherwise.
@@ -2448,7 +2529,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example/UUID-a1j/7533'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
- It will be useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A standard roster item is encoded as follows. It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element <annotate/> to the <query/> element. The <annotate/> element is qualified by the ‘urn:xmpp:mix:roster:0' namespace. A standard roster item is encoded as follows.
- MIX channels in the roster have an attribute 'channel' set to true.
+ MIX channels in the roster information returned in response to a request for this additional MIX information MUST have an element <channel/> qualified by the ‘urn:xmpp:mix:roster:0' namespace included in the roster item, as shown inf the following example.
- When sending roster information to a client that advertises MIX capability, the server MUST return all MIX channels and MUST use this encoding. Presence of MIX roster items MUST be set to offline (unavailable).
-
- Where a client does not advertise MIX capability, the server MAY choose to not return MIX channels as roster items. If this is done care needs to be taken, in particular around support of roster versioning &xep0237;.
- The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. The field with var='muc-mirror' is the value of which is the mirrored MUC domain's JID. The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:1#serviceinfo'. The field with var='muc-mirror' is the value of which is the mirrored MUC domain's JID. Where a client supporting both MIX and MUC is given a reference to a MUC room, it is desirable that the client can determine the MIX channel and join using MIX. This is achieved by an equivalent extension to MUC service discover. The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. The field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID. The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:1#serviceinfo'. The field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID.
Where a client supports MUC and MIX and has determined that for a channel that the server also supports a MUC room, the client has a choice as to which type of invite to send. This SHOULD be done by determining if the client support MIX using the mechanism specified in
@@ -2668,7 +2753,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Timothée Jaussoin, Evgeny Khramtsov, Georg Lukas, Tobias Markmann, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Jonas Wielicki, Matthew Wild and one anonymous reviewer. Thanks to the following who have made contributions: Dave Cridland, Tarun Gupta, Philipp Hancke, Waqas Hussain, Timothée Jaussoin, Evgeny Khramtsov, Georg Lukas, Tobias Markmann, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Jonas Wielicki, Matthew Wild and one anonymous reviewer. Depend on SignalProtocol instead of Olm. Changed to eu.siacs.conversations.axolotl Namespace which is currently used in the wild
- This XEP defines a protocol that leverages &olm; encryption to provide
+ This XEP defines a protocol that leverages the SignalProtocol encryption to provide
multi-end to multi-end encryption, allowing messages to be synchronized
- securely across multiple clients, even if some of them are offline. Olm
+ securely across multiple clients, even if some of them are offline. The SignalProtocol
is a cryptographic double ratched protocol based on work by Trevor Perrin
- and Moxie Marlinspike first published as the Axolotl protocol.
+ and Moxie Marlinspike first published as the Axolotl protocol. While the
+ protocol itself has specifications in the public domain, the
+ protobuf-based wire format of the signal protocol is not fully
+ documented. The signal protocol currently only exists in GPLv3-licensed
+ implementations maintained by OpenWhisperSystems.
The general idea behind this protocol is to maintain separate,
- long-standing Olm-encrypted sessions with each device of each contact
+ long-standing SignalProtocol-encrypted sessions with each device of each contact
(as well as with each of our other devices), which are used as secure key
transport channels. In this scheme, each message is encrypted with a
fresh, randomly generated encryption key. An encrypted header is added to
@@ -87,14 +100,14 @@
As the encrypted payload is common to all recipients, it only has to be
- included once, reducing overhead. Furthermore, Olm's transparent handling
+ included once, reducing overhead. Furthermore, SignalProtocols’s transparent handling
of messages that were lost or received out of order, as well as those sent
while the recipient was offline, is maintained by this protocol. As a
result, in combination with &xep0280; and &xep0313;, the desired property
of inter-client history synchronization is achieved.
- OMEMO currently uses version 1 Olm protocol. Instead of an Axolotl key
+ OMEMO currently uses version 3 SignalProtocol. Instead of a Signal key
server, &xep0163; (PEP) is used to publish key data.
In order to determine whether a given contact has devices that support OMEMO, the devicelist node in PEP is consulted. Devices MUST subscribe to 'urn:xmpp:omemo:0:devicelist' via PEP, so that they are informed whenever their contacts add a new device. They MUST cache the most up-to-date version of the devicelist. In order to determine whether a given contact has devices that support OMEMO, the devicelist node in PEP is consulted. Devices MUST subscribe to 'eu.siacs.conversations.axolotl.devicelist' via PEP, so that they are informed whenever their contacts add a new device. They MUST cache the most up-to-date version of the devicelist. A random preKeyPublic entry is selected, and used to build an Olm session. A random preKeyPublic entry is selected, and used to build a SignalProtocol session.
@@ -230,15 +243,15 @@
128 bit) are concatenated and for each intended recipient device,
i.e. both own devices as well as devices associated with the contact, the
result of this concatenation is encrypted using the corresponding
- long-standing Olm session. Each encrypted payload key/authentication tag
+ long-standing SignalProtocol session. Each encrypted payload key/authentication tag
tuple is tagged with the recipient device's ID. The key element MUST be
- tagged with a prekey attribute set to true if a PreKeyOlmMessage is being
+ tagged with a prekey attribute set to true if a PreKeySignalMessage is being
used. This is all serialized into a MessageElement, which is transmitted
in a <message> as follows:
This KeyTransportElement can then be sent over any applicable transport mechanism. When an OMEMO element is received, the client MUST check whether there is a <key> element with an rid attribute matching its own device ID. If this is not the case, the element MUST be silently discarded. If such an element exists, the client checks whether the element's contents are a PreKeyOlmMessage. When an OMEMO element is received, the client MUST check whether there is a <key> element with an rid attribute matching its own device ID. If this is not the case, the element MUST be silently discarded. If such an element exists, the client checks whether the element's contents are a PreKeySignalMessage. If this is the case, a new session is built from this received element. The client SHOULD then republish their bundle information, replacing the used PreKey, such that it won't be used again by a different client. If the client already has a session with the sender's device, it MUST replace this session with the newly built session. The client MUST delete the private key belonging to the PreKey after use. If the element's contents are a OlmMessage, and the client has a session with the sender's device, it tries to decrypt the OlmMessage using this session. If the decryption fails or if the element's contents are not a OlmMessage either, the OMEMO element MUST be silently discarded. If the element's contents are a SignalMessage, and the client has a session with the sender's device, it tries to decrypt the SignalMessage using this session. If the decryption fails or if the element's contents are not a SignalMessage either, the OMEMO element MUST be silently discarded. If the OMEMO element contains a <payload>, it is an OMEMO message element. The client tries to decrypt the base64 encoded contents using the key and the authentication tag extracted from the <key> element. If the decryption fails, the client MUST silently discard the OMEMO message. If it succeeds, the decrypted contents are treated as the <body> of the received message. If the OMEMO element does not contain a <payload>, the client has received a KeyTransportElement. The key extracted from the <key> element can then be used for other purposes (e.g. encrypted file transfer). Before publishing a freshly generated Device ID for the first time, a device MUST check whether that Device ID already exists, and if so, generate a new one. Clients SHOULD NOT immediately fetch the bundle and build a session as soon as a new device is announced. Before the first message is exchanged, the contact does not know which PreKey has been used (or, in fact, that any PreKey was used at all). As they have not had a chance to remove the used PreKey from their bundle announcement, this could lead to collisions where both Alice and Bob pick the same PreKey to build a session with a specific device. As each PreKey SHOULD only be used once, the party that sends their initial PreKeyOlmMessage later loses this race condition. This means that they think they have a valid session with the contact, when in reality their messages MAY be ignored by the other end. By postponing building sessions, the chance of such issues occurring can be drastically reduced. It is RECOMMENDED to construct sessions only immediately before sending a message. As there are no explicit error messages in this protocol, if a client does receive a PreKeyOlmMessage using an invalid PreKey, they SHOULD respond with a KeyTransportElement, sent in a <message> using a PreKeyOlmMessage. By building a new session with the original sender this way, the invalid session of the original sender will get overwritten with this newly created, valid session. If a PreKeyOlmMessage is received as part of a &xep0313; catch-up and used to establish a new session with the sender, the client SHOULD postpone deletion of the private key corresponding to the used PreKey until after MAM catch-up is completed. If this is done, the client MUST then also send a KeyTransportMessage using a PreKeyOlmMessage before sending any payloads using this session, to trigger re-keying. (as above) This practice can mitigate the previously mentioned race condition by preventing message loss. Clients SHOULD NOT immediately fetch the bundle and build a session as soon as a new device is announced. Before the first message is exchanged, the contact does not know which PreKey has been used (or, in fact, that any PreKey was used at all). As they have not had a chance to remove the used PreKey from their bundle announcement, this could lead to collisions where both Alice and Bob pick the same PreKey to build a session with a specific device. As each PreKey SHOULD only be used once, the party that sends their initial PreKeySignalMessage later loses this race condition. This means that they think they have a valid session with the contact, when in reality their messages MAY be ignored by the other end. By postponing building sessions, the chance of such issues occurring can be drastically reduced. It is RECOMMENDED to construct sessions only immediately before sending a message. As there are no explicit error messages in this protocol, if a client does receive a PreKeySignalMessage using an invalid PreKey, they SHOULD respond with a KeyTransportElement, sent in a <message> using a PreKeySignalMessage. By building a new session with the original sender this way, the invalid session of the original sender will get overwritten with this newly created, valid session. If a PreKeySignalMessage is received as part of a &xep0313; catch-up and used to establish a new session with the sender, the client SHOULD postpone deletion of the private key corresponding to the used PreKey until after MAM catch-up is completed. If this is done, the client MUST then also send a KeyTransportMessage using a PreKeySignalMessage before sending any payloads using this session, to trigger re-keying. (as above) This practice can mitigate the previously mentioned race condition by preventing message loss. As the asynchronous nature of OMEMO allows decryption at a later time to currently offline devices client SHOULD include a &xep0334; <store /> hint in their OMEMO messages. Otherwise, server implementations of &xep0313; will generally not retain OMEMO messages, since they do not contain a <body />
- The Olm library's reference implementation (and presumably its ports to
- various other platforms) uses a trust model that doesn't work very well with
+ The SignalProtocol-library uses a trust model that doesn't work very well with
OMEMO. For this reason it may be desirable to have the library consider all
keys trusted, effectively disabling its trust management. This makes it
necessary to implement trust handling oneself.
@@ -305,7 +317,7 @@
When prompting the user for a trust decision regarding a key, the client SHOULD present the user with a fingerprint in the form of a hex string, QR code, or other unique representation, such that it can be compared by the user. While it is RECOMMENDED that clients postpone private key deletion until after MAM catch-up and this standards mandates that clients MUST NOT use duplicate-PreKey sessions for sending, clients MAY delete such keys immediately for security reasons. For additional information on potential security impacts of this decision, refer to
- In order to be able to handle out-of-order messages, the Olm stack has to
+ In order to be able to handle out-of-order messages, the SignalProtocol stack has to
cache the keys belonging to "skipped" messages that have not been seen yet.
It is up to the implementor to decide how long and how many of such keys to
keep around.
@@ -318,9 +330,8 @@
This specification defines the following XMPP namespaces: The ®ISTRAR; shall include the foregoing namespace in its registry at &NAMESPACES;, as goverened by &xep0053;. Use 'urn:xmpp:hashes:2' and 'urn:xmpp:jingle:apps:file-transfer:5'. Note: that ni URIs use a Base64URL encoding for the hash value and &xep0300; uses a hexencoding. This way the client can aquire the content addressable resource mentioned in the img-tag in the XHTML-IM message, and when finished show in in the rendered XHTML-IM message. Thanks to Kim Alvefur, Emmanuel Gil Peyrot, Kevin Smith, and Nicolas Vérité for their helpful comments. Thanks to Kim Alvefur, Emmanuel Gil Peyrot, Kevin Smith, Nicolas Vérité, and Florian Schmaus for their helpful comments. REQUIRED. Updated according to implementation experience: Servers capable of SASL2 offer a stream feature of <mechanisms/>, qualified by the "urn:xmpp:sasl:0" namespace. This in turn contains one or more <mechanism/> elements in the same namespace, and potentially other elements (for example, the <hostname/> element defined within XEP-0233). Servers capable of SASL2 offer a stream feature of <mechanisms/>, qualified by the "urn:xmpp:sasl:1" namespace. This in turn contains one or more <mechanism/> elements in the same namespace, and potentially other elements (for example, the <hostname/> element defined within XEP-0233). Note that SASL2 is impossible for clients to initiate without at least one mechanism being available, and therefore MUST NOT be offered. The feature so advertised, and its child content, SHOULD be stable for the given stream to and from attributes and encryption state, and therefore MAY be cached by clients for later connections. The Service Name used by XMPP is unchanged from RFC 6120. In all cases, both Clients and Servers encode SASL exchanges using Base 64 encoding. This SHOULD NOT include any line wrapping or other whitespace. As the form <element/> is equivalent to <element></element>, these both indicate an empty string, which is used to indicate no data (ie, the absence of the data). In order to explicitly transmit a zero-length SASL challenge or response, the sending party sends a single equals sign character ("="). In all cases, both Clients and Servers encode SASL exchanges using Base 64 encoding. This SHOULD NOT include any line wrapping or other whitespace. As the form <element/> is equivalent to <element></element>, these both indicate an empty string. Challenges and responses with no data do not occur in SASL, and so require no special handling. To indicate the absence of an initial response, or the absence of success data, the element is simply not included. Clients, upon observing this stream feature, initiate the authentication by the use of the <authenticate/> top-level element, within the same namespace. The nature of this element is to inform the server about properties of the final stream state, as well as initiate authentication itself. To achieve the latter, it has a single mandatory attribute of "mechanism", with a string value of a mechanism name offered by the Server in the stream feature, and an optional child element of <initial-response/>, containing a base64-encoded SASL Initial Response. On subsequent connections, if a Client has previously cache the stream feature, the Client MAY choose to send it before seeing the stream features - sending it "pipelined" with the Stream Open tag for example. In order to provide support for other desired stream states beyond authentication, additional child elements are used. For example, a hypothetical XEP-0198 session resumption element might be included, and/or Resource Binding requests. Server Challenges MAY then be sent. Each Challenge MUST be responded to by a Client in a Client Response. These are not extensible, and contain the corresponding base64 encoded SASL data: Authentication may complete in one of three ways. It may complete successfully, in which case the client is authenticated. It may also fail, in which case the client is not authenticated and the stream and session state remain entirely unchanged. Finally, it may have completed successfully, but further interaction is required - for example, a password change or second-factor authentication. If the Client is now authenticated, the Server sends a <success/> element, which contains an OPTIONAL <additional-data/> element containing SASL additional data. It also contains a <authorization-identity/> element containing the negotiated identity - this is a bare JID, unless resource binding has occurred, in which case it is a full JID. If the Client is now authenticated, the Server sends a <success/> element, which contains contains an <authorization-identity/> element containing the negotiated identity - this is a bare JID, unless resource binding has occurred, in which case it is a full JID. It MAY contain an <additional-data> element, containing additional data from the exchange (task or SASL mechanism) that has just completed. Other extension elements MAY also be contained by the <success/> element. Any security layer negotiated SHALL take effect after the ">" octet of the closing tag (ie, immediately after "</success>"). Any security layer negotiated SHALL take effect after the ">" octet of the closing tag (ie, immediately after "</success>"), if it has not already taken effect at a <continue> - see Continue below. The <success> element is immediately followed by a <features> element containing the applicable stream features of the newly authenticated stream. Note that no stream restart occurs. A <failure/> element is used by the server to terminate the authentication attempt. It MAY contain application-specific error codes, and MAY contain a textual error. It MUST contain one of the SASL error codes from RFC 6120 Section 6.5. A <continue/> element is used to indicate that while the SASL exchange was successful, it is insufficient to allow authentication at this time. This can be used to indicate that the Client needs to perform a Second Factor Authentication ("2FA"), or is required to change password. These are conducted as additional SASL mechanisms. Such SASL mechanisms MUST NOT change the authorization identifier, or introduce any security layer. The authorization identifer transmitted during the subsequent <success/>, and any security layer which comes into effect after the eventual <success/>, therefore MUST be that of the first mechanism. The element contains a <mechanisms/> element, as defined above as a stream feature, containing suitable mechanisms. It MAY contain an <additional-data/> element, as the <success/> element does. This can be used to indicate that the Client needs to perform a Second Factor Authentication ("2FA"), or is required to change password. Such tasks are presented within a <tasks> element, which contains a sequence of <task> elements, each containing a name. These tasks are analogous to a SASL mechanism, but have a number of differences - they may never attempt to negotiate a new authorization identifier, nor a new security layer. A client MAY choose any one of the offered tasks; if multiple are required a sequence of <continue> exchanges will occur until all mandatory tasks are complete. The <continue element therefore always contains a <tasks/> element, as defined above. It MAY contain an <additional-data/> element, as the <success/> element does. Finally, it MAY contain a <text/> element, which can contain human-readable data explaining the nature of the step required. Clients respond with a <next-authenticate/> element, which has a single mandatory attribute of "mechanism", containing the selected mechanism name, and contains an OPTIONAL base64 encoded initial response. After the final octet of the first <continue> element, any SASL security layer negotiated in the preceding exchange SHALL be immediately in effect. Clients respond with a <next/> element, which has a single mandatory attribute of "task", containing the selected task name, and contains an OPTIONAL base64 encoded initial response contained in an <initial-response> element. This provides pointers and/or clarifications to the in the order and manner defined in RFC 4422, section 4. This provides pointers and/or clarifications to the Overview in the order and manner defined in RFC 4422, section 4. The service name SHALL be "xmpp", as defined by RFC 6120. Servers list mechanisms during stream features (See ) and within the <continue/> element (See ). TODO: Neither this specification nor RFC 6120 allow clients access to the mechanism list after SASL negotiation...? Servers list mechanisms during stream features (See Discovering Support). Clients initiate using the <authenticate/> top level element (See , and after any <continue/> with the <next-authenticate/> message (See ). Clients initiate using the <authenticate/> top level element (See Initiation. See . See Challenges and Responses. See . See Completing Authentication. If a Client specifies an authorization string which is non-empty, the identifier is normalized by treating it as a JID, and performing normalization as described in RFC 7622. In general, implementors are advised that a non-empty authorization string MAY be considered an error if the stream's from attribute (if present) does not match. Clients MAY abort unilaterally by sending <abort/> as specified in . Servers MAY abort unliterally by sending <failure/> with the <aborted/> error code as defined in . Clients MAY abort unilaterally by sending <abort/> as specified in Client Aborts. Servers MAY abort unliterally by sending <failure/> with the <aborted/> error code as defined in Failure. See . Security Layers take effect after the SASL mechanism itself (ie, the first negotiation) has completed successfully, after the final octet of the server's <success> or <continue>. See Success and Continue. Option (a) is used - any SASL Security Layer is applied first to data being sent, and TLS applied last. Although the <continue/> concept does use multiple SASL sequences, only the first SASL mechanism used is considered an authentication, and only the first can negotiate a security layer. Although the <continue/> concept does use tasks analogous to multiple SASL sequences, only the first SASL mechanism used is considered an authentication, and only the first can negotiate a security layer. In particular, once <success/> has been sent by the server, any further <authenticate/> element MUST result in a stream error. This section provides a fictional example. It is important to note that many of the extensions used wihtin this section do not, in fact, exist and therefore are to be avoided. Where no additional features that SASL2 makes available are used, the flow of information is identical to the original SASL profile. This example shows the new syntax and draws the reader's attention to the differences. Use of SASL2 in this simple scenario saves one round-trip (due to the lack of stream restart). Again, this is an equivalent flow to a common SASL1 flow, although using the CRAM-MD5 mechanism which is (thankfully) rarely used in practise. Use of SASL2 in this simple scenario again simply saves one round-trip. This moves into the deeply hypothetical. A binding extension is posited, alongside an unrealistic 2FA mechanism which somehow mutually authenticates because why not. Although the unrealistic 2FA here uses 2 round-trips (real ones will probably use one), the embedding of resource binding as shown here means that a second RTT is saved by SASL2, and there's no net change. A more realistic example would see RTTs saved, and additional negotiations could be added to further reduce RTTs. Relative to the SASL profile documented in RFC 6120, this introduces more data unprotected by any security layer negotiated by SASL itself. While no actual exchanges are introduced that are unprotected, the nature of this exchange might allow for (for example) a resource binding extension to be introduced. SASL security layers are sparingly used in the field, however, so this is thought to be a theoretical, rather than practical, concern. None. The author wishes to share any credit with many members of the community, including Lance Stout, Ralph Meijer, and Florian Schmaus. The author wishes to share any credit with many members of the community, including Lance Stout, Ralph Meijer, Phil Roberts and Florian Schmaus. The input to this algorithm is a &xep0030; disco#info <query/> response. The output is an octet string which can be used as input to a hash function or an error. General remarks: The algorithm strongly distinguishes between character data (sequences of Unicode code points) and octet strings (sequences of 8-bit bytes). Whenever character data is encoded to octet strings in the following algorithm, the UTF-8 encoding as specified in &rfc3629; is used. Whenever octet strings are sorted in the following algorithm, the i;octet collation as specified in &rfc4790; is used. General remarks: The algorithm strongly distinguishes between character data (sequences of Unicode code points) and octet strings (sequences of 8-bit bytes). Whenever character data is encoded to octet strings in the following algorithm, the UTF-8 as specified in &rfc3629; encoding is used. Whenever octet strings are sorted in the following algorithm, the i;octet collation as specified in &rfc4790; is used. The algorithm uses the xml:lang attribute. Implementations must take implicit values for the xml:lang attribute into account, for example those inherited from the disco#info or the IQ element. A server MAY support pushing of &hashes; from clients before sending initial presence. This allows servers to discover capabilities of clients before those have sent initial presence, which may be useful or important for some protocols (such as &xep0369;). This feature is called &gratcaps;. To advertise support, the server publishes the urn:xmpp:caps:gratuitous feature: After determining server support, a client can send &hashes; via &gratcaps; before sending initial presence: The server replies with an empty result on success. The server MUST NOT broadcast the &hashes; submitted via &gratcaps; using presence. Clients SHOULD NOT send &gratcaps; after they have sent initial presence; instead, they SHOULD re-send presence to update the &hashes;. Otherwise, entities subscribed to the presence will not receive the updated &hashes;. Instead of issuing a &xep0030; disco#info <query/> with absent 'node' attribute to a target entity, an entity MAY use a &hashcache; to obtain the response. To look up the disco#info response in the &hashcache;, an entity MUST use a hash from the &hashset; which was most recently received from the entity to which the <query/> would have been sent otherwise. If none of the most recently received &hashes; are found in the &hashcache;, the entity MUST fall back to sending the request. An entity MUST NOT use &hashes; which were not included in the most recent &hashset; received from the target entity. An entity MAY use external data sources to fill the &hashcache;. An entity MUST ensure that implicit values for xml:lang attributes is preserved when disco#info data is cached. This can for example happen by making the implicit values explicit in the storage. Servers MAY implement &queryintercept; to further optimise bandwidth consumption. The idea is that servers intercept &xep0030; disco#info queries sent to clients if they already know the answer from &hashes; published by the client. The rules for &queryintercept; are the following (to be applied in this order): This was an issue with &xep0115; and has been addressed with a new algorithm for generating the hash function input which keeps the structural information of the disco#info input. An entity MUST NOT ever use disco#info which has not been verified to belong to a &hash; obtained from a cache using that &hash;. Using cache contents from a trusted source (at the discretion of the entity) counts as verifying. A malicious entity could send a large amount of &hashsets; in short intervals, while making sure that it provides matching disco#info responses. If a &procent; uses caching, this can overflow or thrash the caches. &procents; should be aware of this risk and apply proper rate-limiting for processing &hashsets;. To reduce the attack surface, an entity MAY choose to not cache &hashes; obtained from entities not in its roster. As mentioned earlier, when storing disco#info data in a cache for later retrieval, implementations MUST ensure that implicit values for xml:lang attributes are reconstructed correctly when the disco#info is restored. Entities MAY choose to not send &hashsets; with directed presence (for example to increase privacy). In that case, entities SHOULD also refuse direct &xep0030; queries. The server replies to certain disco#info queries on behalf of the client. This means that the client has no choice on to whom they reply. Otherwise, a client could choose to reply with <service-unavailable/> to mask its existence. We consider two effects of this: A remote entity could attempt to detect that an entity exists behind a resource. For this, they send a disco#info query to the resource since nearly everyone implements disco#info. As the client responds with <service-unavailable/>, it looks as if no client was present at this resource. With &queryintercept;, the server would reply on behalf of the client. However, the consensus in the community is that by measuring the difference between the reply from the server of the resource and the reply from the actual resource, it would generally be possible to detect the existence of a resource. A remote entity can obtain the disco#info information of any resource which supports ∩︀ and of which the entity knows the resource. This cannot be mitigated with &queryintercept;. The risk is deemed acceptable considering that resources should generally be chosen randomly. Thanks to the authors of &xep0115; for coming up with the original idea of using presence broadcast to convey service discovery information, as well as the optimization strategies. The note below the example in Advertisement of Support and Capabilities by Servers has been copied verbatimly from XEP-0115. Thanks to Waqas Hussain for originally (to my knowledge) pointing out the security flaws in XEP-0115 (see &mlwaqas1;). Thanks to Georg Lukas, Link Mauve, Sebastian Riese, Florian Schmaus and Sam Whithed for their input, editorial and otherwise. Thanks to Dave Cridland, Georg Lukas, Link Mauve, Sebastian Riese, Florian Schmaus and Sam Whited for their input, editorial and otherwise. Accepted as Experimental by Council. First draft Jingle Encrypted Transports (JET) strives to provide a modular and easily extensible way to wrap Jingle Transports in an additional end-to-end encryption layer. The focus of this specification lays on being modular. It should be possible to extend existing Jingle use scenarios with end-to-end encryption by simply adding a JET element to the negotiation. JET uses multiple encryption layers, so it is necessary to declare a distinct denomination for the different keys involved. Lets assume Romeo wants to initiate an encrypted Jingle session with Juliet. Prior to the Jingle session initiation, an already existing, established and (ideally) authenticated end-to-end encryption session between Romeo and Juliet MUST exist. This session is needed to transfer the Transport Secret from Romeo to Juliet. When this precondition is met, Romeo initially generates a transport key (TK) and associated initialization vector (IV). These will later be used by the sender to encrypt, and respectively by the recipient to decrypt data that is exchanged. This protocol defines a set of usable ciphers from which Romeo might choose. TK and IV are serialized to create the transport secret (TS). Next Romeo uses her established encryption session with Juliet to encrypt TS. The resulting envelope element (EE) will be part of the Jingle session initiation as child of the JET &secret; element. When Juliet receives Romeos session request, she decrypts EE to retrieve TS, from which she can deserialize TK and IV. Now she and Romeo can go on with the session negotiation. Once the session is established, data can be encrypted and exchanged. Both parties MUST keep a copy of TS in cache until the Jingle session is ended. &xep0234; has the disadvantage, that transmitted files are not encrypted (aside from regular TLS transport encryption), which means that intermediate nodes like XMPP/proxy server(s) have access to the transferred data. Considering that end-to-end encryption becomes more and more important to protect free speech and personal expression, this is a major flaw that needs to be addressed. In order to initiate an encrypted file transfer, the initiator includes a JET &secret; in the Jingle file transfer request. In this scenario Romeo wants to send an encrypted text file over to Juliet. First, he generates a fresh AES-256 transport key and IV. TK and IV are serialized into TS which is then encrypted using Romeos end-to-end-encryption session with Juliet. The resulting envelope element (EE) is sent as part of the security element along with the rest of the jingle stanza over to Juliet. Juliet decrypts the envelope element (EE) using her session with Romeo to retrieve TS from which she deserializes TK and IV. Both Juliet and Romeo then carry on with the session negotiation as described in &xep0234;. Before Romeo starts transmitting the file, he encrypts it using TK and IV. He then transmitts the encrypted file over to Juliet. When Juliet received the file, she uses the TK and IV to decrypt the received file. Juliet might want to request a file transfer from Romeo. This can be the case, when Romeo hosts the file. In order to do so, she sends generates TK and IV, creates TS from those and encrypts TS with an encryption method of her choice to get EE. TK and IV will be used by Romeo to encrypt the requested file before sending it to Juliet. &xep0234; defines a way for parties to request ranged transfers. This can be used to resume interrupted transfers etc. In case of an interrupted transfer, the receiving party might be able to decrypt parts of the received file. When requesting a resumption of the transfer, the recipient therefore can use the index of the last successfully decrypted byte of the file as offset in the ranged transfer. Since a resumed transfer takes place in a new session, the old transport secret might no longer be available to either party. For that reason the receiver creates a new TS for the session-initiation. The sending party then encrypts and sends only the requested parts of the file. In order to encrypt the transported bytestream, the initiator must transmit a cipher key to the responder. There are multiple options available: The column 'serialization' describes, how the key and iv are serialized. "::" means plain concatenation of byte arrays. To advertise its support for the Jingle Encrypted Transports, when replying to service discovery information ("disco#info") requests an entity MUST return URNs for any version, or extension of this protocol that the entity supports -- e.g., "urn:xmpp:jingle:jet:0" for this version, or "urn:xmpp:jingle:jet-stub:0" for a stub encryption method &VNOTE;. In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead. The initiator SHOULD NOT use the generated key TK as IV, but instead generate a seperate random IV. Instead of falling back to unencrypted transfer in case something goes wrong, implementations MUST instead abort the Jingle session, informing the user. IMPORTANT: This approach does not deal with metadata. In case of &xep0234;, an attacker with access to the sent stanzas can for example still see the name of the file and other information included in the <file/> element. The responder MUST check, whether the envelope element belongs to the initiator to prevent MitM attacks This is only a rough draft and there is still a ton of questions left to be answered. Here is a small non-exhaustive list of things I can think of:
+ Move to SHA-1 as mixing function;
+ Properly reference BT.601 and include constants in text;
+ Prefer bare JID over roster name when selecting the hash function input;
+ Editing.
+ Accepted as Experimental by Council. First draft. Colors provide a valuable visual cue to recognize text. Recognition of colors works much faster than recognition of text. Together with the length and overall shape of a piece of text (such as a nickname), a color provides a decent amount of entropy to distinguish a reasonable amount of entities. Clients have been using randomly or deterministically chosen colors for users in multi-user situations for a long time already. However, since there has been no standard for how this is implemented, the experience differs across platforms. The goal of this XEP is to provide a uniform, platform-independent, stateless and easy-to-implement way to map arbitrary bytestrings to colors, as well as give recommendations how this is applied to color names of participants in conversations, roster entries and other pieces of text. To allow cross-client use, it is important that the color scheme can be adapted to different environments. This specification provides means to adapt colors to different background colors as well as &cvds;. In no way is the system presented in this specification a replacement for names. It only serves as an additional visual aid. The color generation mechanism should provide the following features: To generate a color from a string of text, the follownig algorithms are applied in order: Implementations may colorize the participants of a conversation with an individual color to make them easier to distinguish. In such cases, the color SHOULD be generated as described in the Generating a color section. The input used SHOULD be, in descending order of preference, (a) the nickname from the conversation, (b) the bare JID. Implementations may want to show a picture in connection with a contact even if the contact does not have an avatar defined (e.g. via &xep0084;). In such cases, auto-generating an avatar SHOULD happen as follows: Input: An identifier, encoded as octets of UTF-8 (&rfc3269;). Output: Angle in the CbCr plane. Note: The goal of this algorithm is to convert arbitrary text into a scalar value which can then be used to calculate a color. As it happens, the CbCr plane of the YCbCr space determines the color (while Y merely defines the lightness); thus, an angle in the CbCr plane serves as a good scalar value to select a color. Input: Angle in the CbCr plane. Output: Angle in the CbCr plane. Note: This algorithm will re-map the angle to map it away from ranges which can not be distinguished by people with the respective &cvds;. Divide the angle by two. Divide the angle by two and add π/2 (half Pi). Input: Angle in the CbCr plane, from the previous algorithm. Output: Values for Cb and Cr in the YCbCr &BT.601; color space in the range from -0.5 to 0.5. Form a vector from the angle and project it to edges of a quad in 2D space with edge length 1 around (0, 0). The resulting coordinates are Cb and Cr: Input: Values for Cb and Cr in the YCbCr &BT.601; color space in the range from -0.5 to 0.5; Value for Y. Output: Values for Red (R), Green (G) and Blue (B) in the RGB color space in the range from 0 to 1. Note: The recommended value for Y is 0.732. See Gamma Correction for a discussion on the choice of Y. See Constants for YCbCr (BT.601) for the values of KR, KG and KB. Input: RGB values for the color to adapt (Ri, Gi, Bi) and for the background color to adapt to (Rb, Gb, Bb), in the range from 0 to 1 each. Output: Values for Red (Rc), Green (Gc) and Blue (Bc) in the RGB color space in the range from 0 to 1. Input: Values for Red (R), Green (G) and Blue (B) in the RGB color space in the range from 0 to 1. Output: Values for Cb and Cr in the YCbCr &BT.601; color space in the range from -0.5 to 0.5; Value for Y. Calculate Y, Cb and Cr according to BT.601: See Constants for YCbCr (BT.601) for the values of KR, KG and KB. Input: A set of RGB colors (each component from 0 to 1). Output: A mapping from CbCr pairs (each component from -0.5 to 0.5) to RGB colors. Note: when the algorithm finishes, the mapping maps CbCr values (rounded to two decimal places) to the R, G, B triples which come closest to the desired color and lightness. Input: A set of colors (the palette) as tuples of Cbp and Crp and a color to map to the closest palette color as Cb and Cr value. Output: A palette color as Cbr and Crr values. Note: the distance metric is simply the euclidian distance in the CbCr plane. An implementation may choose a different value for Y depending on whether the sink for the R, G and B values expects Gamma Encoded or Gamma Decoded values. The recommended default of 0.732 is 0.5 to the power of 0.45, that is, a Gamma Encoded 0.5. Modifications to Y SHOULD NOT be used to correct for bright/dark backgrounds. Implementations SHOULD instead use the algorithm described in Adapting the Color for specific Background Colors for that. As outlined above, implementations SHOULD offer the &rgblind; and &bblind; corrections as defined in the Corrections for &cvds; section. Users SHOULD be allowed to choose between: The last option is important for users with monochromatic view. Some sources on the internet indicate that people with &cvds; may profit from having larger areas of color to be able to recognize them. This should be taken into consideration when selecting font weights and line widths for colored parts. This specification extracts a bit more information from an entity and shows it alongside the existing information to the user. As the algorithm is likely to produce different colors for look-alikes (see &xep0165; for examples) in JIDs, it may add additional protection against attacks based on those. Due to the limited set of distinguishable colors and only extracting 16 bits of the hash function output, possible &cvds; and/or use of palettes, entities MUST NOT rely on colors being unique in any context. This section provides an overview of design considerations made while writing this specification. It shows alternatives which have been considered, and eventually rejected. The other common YCbCr variants, BT.709 and BT.2020, do not achieve a brightness across the color space as uniform as &BT.601; does. Adapting the Y value for uniform luminosity across the range for CbCr would have complicated the algorithm with little or no gain. The HSV and HSL color spaces fail to provide uniform luminosity with fixed value/lightness and saturation parameters. Adapting those parameters for uniform luminosity across the hue range would have complicated the algorithm with litte to no gain. Given a fixed-size and finite palette of colors, it would be possible to ensure that, until the number of entities to color exceeds the number of colors, no color collisions happen. There are issues with this approach when the set of entities is dynamic. In such cases, it is possible that an entity changes its associated color (for example by re-joining a colored group chat), which defeats the original purpose. In addition, more state needs to be taken into account, increasing the complexity of choosing a color. This specification needs to collapse an arbitrarily long string into just a few bits (the angle in the CbCr plane). To do so, SHA-1 (&rfc3174;) is used. CRC32 and Adler32 have been considered as faster alternatives. Downsides of these functions: SHA-1 is widely available. From a security point of view, the exact choice of hash function does not matter here, since it is truncated to 16 bits. At this length, any cryptographic hash function is weak. This document requires no interaction with &IANA;. This document requires no interaction with the ®ISTRAR;. Thanks to Daniel Gultsch, Georg Lukas, and Tobias Markmann. Throughout the document, the constants KR, KG and KB are used. They are defined in &BT.601; as: This section holds test vectors for the different configurations. The test vectors are provided as Comma Separated Values. Strings are enclosed by single quotes ('). The first line contains a header. Each row contains, in that order, the original text, the text encoded as UTF-8 as hexadecimal octets, the angle in radians, and the Cb, Cr, Red, Green, and Blue values. The used palette can be generated by sampling the RGB cube evenly with six samples on each axis (resulting in 216 colors). The resulting palette is commonly known as the palette of so-called "Web Safe" colors. The format of the test vectors is the same as in the full range case above.
Room Nickname Full JID Affiliation Game Role
@@ -216,7 +216,7 @@
-
Room Type
@@ -275,11 +275,11 @@
+
+
+
+
]]>
-
-
Attribute
@@ -373,11 +372,9 @@ If the meta node is configured to include payloads, the subscribers will receive
A serial number or other unique identifier for the physical device
-
-
Attribute
@@ -507,13 +504,11 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation
The accuracy of the values reported by this transducer
-
-
Type
@@ -610,7 +605,6 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation
Other type that isn't listed above
-The following example shows how to specify a sensor in kilograms.
+
-The following example shows how to specify a sensor in kilowatt-second with a resolution to the nearest 0.1 kWh.
+
-If no unitScaler value is specified, then a unitScaler of 0 (aka 10**0 = 1) is assumed.
+
]]>
-
-
Attribute
@@ -744,7 +737,6 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation
The raw value as seen by the transducer. The rawValue can be used to record a non-unit converted value for record keeping (e.g. a raw ADC value before calibration).
]]>
-
-
Attribute
@@ -922,7 +913,6 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation
If the adapter can verify that the raw value is an allowable value for the transducer, it SHOULD allow the raw value to take precedence over the typedValue if provided.
-
-If an implementaion chooses to put some transducers values into their own nodes
+
@@ -175,14 +175,14 @@
@@ -193,10 +193,10 @@
diff --git a/inbox/spim.xml b/inbox/spim.xml
index 39d1e232..a3279181 100644
--- a/inbox/spim.xml
+++ b/inbox/spim.xml
@@ -43,14 +43,14 @@
- 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.
+
-
-
+
-
- Name
- Type
- Description
-
-
- 'id'
- REQUIRED
- The number of the move. First move is 1.
-
-
- 'row'
- REQUIRED
- The horizontal position of the mark.
-
-
- 'col'
- REQUIRED
- The vertical position of the mark.
-
+
+
+ Name
+ Type
+ Description
+
+
+ 'id'
+ REQUIRED
+ The number of the move. First move is 1.
+
+
+ 'row'
+ REQUIRED
+ The horizontal position of the mark.
+
+
+ 'col'
+ REQUIRED
+ The vertical position of the mark.
+
-
+
-
- Name
- Type
- Description
-
-
- 'id'
- REQUIRED
- The number of the move. First move is 1.
-
-
- 'row'
- REQUIRED
- The horizontal position of the mark.
-
-
- 'col'
- REQUIRED
- The vertical position of the mark.
-
+
+
+ Name
+ Type
+ Description
+
+
+ 'id'
+ REQUIRED
+ The number of the move. First move is 1.
+
+
+ 'row'
+ REQUIRED
+ The horizontal position of the mark.
+
+
+ 'col'
+ REQUIRED
+ The vertical position of the mark.
+
-
+
date
- UTC timestamp specifying the last modified time of the file (which MUST conform to the DateTime profile of &xep0082;).
+ Timestamp specifying the last modified time of the file (which MUST conform to the DateTime profile of &xep0082;).
OPTIONAL
@@ -354,7 +371,12 @@
+ hash
A hash of the file content, using the <hash/> element defined in &xep0300; and qualifed by the 'urn:xmpp:hashes:2' namespace. Multiple hashes MAY be included for hash agility.
- REQUIRED when offering a file, otherwise OPTIONAL
+ See <hash-used/>
+
+
hash-used
+ Alternatively to a <hash/> element, the initiator can also include a <hash-used/> element. This avoids the need to read the file twice to calculate the hash.
+ Either a <hash/> or a <hash-used/> element MUST be included when offering a file.
media-type
@@ -377,7 +399,7 @@
OPTIONAL
@@ -750,7 +772,7 @@ a=file-range:
@@ -323,6 +360,48 @@ All signalling, request, response and publishing is done via XMPP, not requiring
+
+
+
+ Attribute
+ Definition
+ Inclusion
+
+
+ ttl
+ The duration in seconds for which the provided credentials are valid.
+ REQUIRED
+
+
+ uri
+ The TURN Server URI.
+ REQUIRED
+
+
+ username
+ The username to be used on TURN authentication. THe recommended format is a colon-delimited concatenation of expiration timestamp and the requester bare JID.
+ REQUIRED
+
+
+ password
+ The ppassword to be used on TURN authentication. Is the result of 'base64(hmac(secret_key, username))'. Where 'secret_key' is shared between the TURN server and entity providing the credentials.
+ REQUIRED
+
+
+ 2AfMGH8O7UNPTvUVAM9aK13mpCY=
+ ]]>
@@ -399,13 +407,21 @@
+
-
+
+
+
+
+
-
Messages 'urn:xmpp:mix:nodes:messages' For distributing messages to the channel. Each item of this node will contain a message sent to the channel. Message Message Participants 'urn:xmpp:mix:nodes:participants' For storing the list of participants and the associated nick. Channel participants are added when they join the channel and removed when they leave Join/Leave/Set Nick PubSub JID Map 'urn:xmpp:mix:nodes:jidmap' For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs. Automatic PubSub JID Maybe Visible Map 'urn:xmpp:mix:nodes:jidmap2' For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs for participants that choose to share real JIDs in a channel with JID Maybe Visible mode. Automatic PubSub JID Maybe Visible Map 'urn:xmpp:mix:nodes:jidmap-visible' For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs for participants that choose to share real JIDs in a channel with JID Maybe Visible mode. Automatic PubSub Presence 'urn:xmpp:mix:nodes:presence' For storing information about the availability status of online participants, which MAY include multiple clients for a single participant. Presence Presence Information 'urn:xmpp:mix:nodes:info' For storing general channel information, such as description. PubSub PubSub Allowed 'urn:xmpp:mix:nodes:allowed' For storing JIDs that are allowed to be channel participants. PubSub PubSub 'Owner' Bare JIDs with Owner rights as defined in ACL node. When a channel is created, the JID creating the channel is configured as an owner, unless this attribute is explicitly configured to another value. jid-multi - - 'Administrator' Bare JIDs with Administrator rights. jid-multi - - 'End of Life' The date and time at which the channel will be automatically removed by the server. If this is not set, the channel is permanent. text-single - - 'Nodes Present' Specifies which nodes are present. Presence of config nodes is implicit. Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present. list-multi 'participants'; 'presence'; 'information'; 'allowed'; 'banned'; 'jidmap2'; 'avatar' - 'Nodes Present' Specifies which nodes are present. Presence of config nodes is implicit. Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present. list-multi 'participants'; 'presence'; 'information'; 'allowed'; 'banned'; 'jidmap-visible'; 'avatar' - 'Messages Node Subscription' Controls who can subscribe to messages node. list-single 'participants'; 'allowed'; 'anyone' 'participants' 'Presence Node Subscription' Controls who can subscribe to presence node. list-single 'participants'; 'allowed'; 'anyone' 'participants' 'Participants Node Subscription' Controls who can subscribe to participants node. list-single 'participants'; 'allowed'; 'anyone'; 'nobody'; 'admins'; 'owners' 'participants'
-
+
+
@@ -162,9 +175,9 @@
+
-
-
+
+
+
+
+
+
+
+
+
@@ -739,6 +799,7 @@ cDp0aW1lHxw=
+
+
+
+
+
+
+
+ Designation
+ Abbrevation
+ Usage
+
+
+ Transport Key
+ TK
+ (Symmetric) key that is used to encrypt/decrypt the bytestreams sent/received through Jingle transports. This key encrypts the data two entities want to exchange. Examples for TK can be found under "Ciphers".
+
+
+ Initialization Vector
+ IV
+ Initialization vector that is used together with TK.
+
+
+ Transport Secret
+ TS
+ Serialization of TK and TI.
+
+
+ Envelope Element
+ EE
+ Output element of an established end-to-end encryption method when encrypting TS.
+
+
+
+
+ Namespace
+ Type
+ Length (bits)
+ Parameters
+ Serialization
+
+
+ urn:xmpp:ciphers:aes-128-gcm-nopadding:0
+ AES
+ 128
+ GCM/NoPadding
+ 128BitKey::96BitIV
+
+
+ urn:xmpp:ciphers:aes-256-gcm-nopadding:0
+ AES
+ 256
+ GCM/NoPadding
+ 256BitKey::96BitIV
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ abs(cb)) {
+ factor = 0.5 / abs(cr);
+} else {
+ factor = 0.5 / abs(cb);
+}
+cb = cb * factor;
+cr = cr * factor;
+]]>
+
+
+
+
+
+
+
+
+
+
+
+ D = sqrt((Cbp-Cb)*(Cbp-Cb) + (Crp-Cr)*(Crp-Cr)).
+
+
+
+
+
+
+
+
+
+
+