Use a custom item value (CAP-V).
Use PubSub publish-options preconditions.
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.
+PubSub services supporting the Compare-And-Publish PubSub extension MUST include a Comapre-and-Publish value + (CAP-V) for every item in every response. The CAP-V value MUST change if the content of the item changed and + different item content under the same node MUST NOT yield the same CAP-V. A simple computation of the CAP-ID would + be to hash the String representation of the item's content.
-In order to atomically compare-and-publish an item, a client sends a XEP-0060 <publish/> IQ + with a 'pubsub#prev_item_cap_value' precondition publishing option, set to the value of the currently assumed CAP-V + of the latest item of the node.
+ +The PubSub service MUST only publish the item if the node's latest item CAP-V is equal to the + CAP-V found in the 'pubsub#prev_item_cap_value' field.
+ +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.
+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 <conflict/> error + of type 'modify' which a pubsub-specific condition of <precondition-not-met/> and a + <compare-and-publish-failed/> element qualifed by the 'urn:xmpp:pubsub:cap:0' + namespace. The element MUST have a 'cap-id' attribute with the CAP-V of the lastest item.
-All other error cases are handled as specified in - XEP-0060 § 7.1.3
+Unfortunately it was not possible to re-use the PubSub item ID for the "Atomically + Compare-And-Publish" purpose. This is mostly due XEP-0060 § 12.8 stating that:
++ "If a publisher publishes an item and the ItemID + matches that of an existing item, the pubsub service MUST overwrite the existing item and generate a new event + notification." +
+Which means that the content of an item could change without its ID, rendering the item ID + unusable for CAP.
+ +Injecting a "cap"-namespaced attribute carrying the item's CAP-V into PubSub's <item/> + would be a very elegant approach to assign CAP-Vs to PubSub items (and the favored one of the + XEP's author). But the usage of namespaces attributes within XMPP is controversial. Therefore this + XEP resorts to using the <cap-v-map/> approach for now.
This extension protocol does not add any further security - considerations to the ones mentioned in XEP-0060 § - 14..
+This extension protocol does not add any further security considerations to the ones mentioned + in XEP-0060 § 14..
- urn:xmpp:pubsub:cap:0
- Indicates support for Compare-And-Publish
- XEP-XXXX
+ urn:xmpp:pubsub:cap:0
+ Indicates support for Compare-And-Publish
+ XEP-XXXX
]]>
+ This specification defines the following <publish-options/> fields:
+]]>
+
+
TODO: Add after the XEP leaves the 'experimental' state.
Thanks to Kim Alvefur and Dave Cridland for their feedback.
+ +First draft
&xep0391; can be used to utilize different end-to-end encryption methods to secure Jingle Transports, eg. in the context of &xep0234;. This document aims to extend &xep0391; to allow the use of OMEMO encryption with Jingle transports. To achieve this goal, this protocol extension makes use of OMEMOs KeyTransportElements.
+Conveniently the OMEMO protocol already provides a way to transport key material to another entity. So called KeyTransportElements are basically normal OMEMO MessageElements, but without a payload, so the contained key can be used for something else (See Section 4.6 of XEP-0384). This extension uses the key encrypted in the KeyTransportMessages <key> attribute and initialization vector from the <iv> attribute to secure Jingle Transports. The key corresponds to the Transport Key of XEP-0391, while the iv corresponds to the Initialization Vector. The KeyTransportMessage is the equivalent to the Envelope Element. Note that within the Envelope Element, the Transport Key is encrypted with the OMEMO ratchet.
+Unfortunately &xep0384; determines the type of the transported key to be AES-128-GCM-NoPadding, so no other configuration can be used in the context of this extension.
+Since OMEMO deviceIds are not bound to XMPP resources, the initiator MUST encrypt the Transport Key for every device of the recipient.
+In order to transport a key to the responder, the initiator creates a fresh AES-128-GCM-NoPadding Transport Key and Initialization Vector and generates an OMEMO KeyTransportElement from it as described in XEP-0384. This is then added as a child of the JET <security> element. The 'cipher' attribute MUST be set to 'aes-128-gcm-nopadding:0' (see the ciphers section of XEP-0391). The value of the 'type' attribute must be set to the namespace of the used version of XEP-0384 &VNOTE;.
+ +The recipient decrypts the OMEMO KeyTransportElement to retrieve the Transport Secret. Transport Key and Initialization Vector are later used to encrypt/decrypt data as described in &xep0391;.
+To advertise its support for JET-OMEMO, when replying to service discovery information ("disco#info") requests an entity MUST return URNs for any version of this extension, as well as of the JET extension that the entity supports -- e.g., "urn:xmpp:jingle:jet-omemo:0" for this version, or "urn:xmpp:jingle:jet:0" for &xep0391; &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.
+Add missing dependency on XEP-0059.