In general, the XMPP Standards Foundation may choose to define at most one FORM_TYPE for each service discovery identity (category+type) registered with the XMPP Registrar. In addition, particular applications may define application-specific FORM_TYPEs as well, and one entity may have multiple service discovery identities (e.g., an XMPP server might also function as a publish-subscribe service). Therefore, it is possible (and allowed) for a single service discovery result to contain multiple service discovery extension elements (potentially up to two elements for each identity). However, in practice it is unlikely that any given service discovery result will contain more than one service discovery extension element.
+In general, the XMPP Standards Foundation may choose to define at most one FORM_TYPE for each service discovery identity (category+type) registered with the XMPP Registrar. In addition, particular applications may define application-specific FORM_TYPEs as well, and one entity may have multiple service discovery identities (e.g., an XMPP server might also function as a publish-subscribe service). Therefore, it is possible (and allowed) for a single service discovery result to contain multiple service discovery extension elements (potentially up to two elements for each identity).
Applications SHOULD ensure that information disclosed in a disco extension is appropriate for discovery by any entity on the network.
diff --git a/xep-0184.xml b/xep-0184.xml index c7ceb52c..dcd136cb 100644 --- a/xep-0184.xml +++ b/xep-0184.xml @@ -27,6 +27,12 @@ &stpeter; &hildjj; +Make the 'id' attribute required, this extension makes no sense otherwise.
When the recipient sends an ack message, it SHOULD ensure that the message stanza contains only one child element, namely the <received/> element qualified by the 'urn:xmpp:receipts' namespace. In addition, it SHOULD include an 'id' attribute that echoes the 'id' attribute of the content message. Naturally, intermediate entities might add other extension elements to the message when routing or delivering the receipt message, e.g., a <delay/> element as specified in &xep0203;.
+When the recipient sends an ack message, it SHOULD ensure that the message stanza contains only one child element, namely the <received/> element qualified by the 'urn:xmpp:receipts' namespace, which MUST include an 'id' attribute that echoes the 'id' attribute of the content message. Naturally, intermediate entities might add other extension elements to the message when routing or delivering the receipt message, e.g., a <delay/> element as specified in &xep0203;.
Note: It is a good practice to use the same message type as the message that requested the receipt, however a client SHOULD also accept receipts with a different message type. When sending a Receipt for a type='groupchat' message (which is NOT RECOMMENDED), the Receipt must be sent to the bare JID of the room and not to the full JID of the sender.
Informational messages can be sent by either party within the context of Jingle to communicate the status of a Jingle ICE "session". The informational message MUST be an IQ-set containing a &JINGLE; element of type "transport-info", where the informational message is a payload element qualified by the 'urn:xmpp:jingle:transports:ice:info:0' namespace.
-The only payload element defined so far is the <ice-gathering-complete/> element. This element is used only to signal that gathering of ICE candidates has been completed (i.e., to send an "end-of-candidates indication"), as in the following example.
+The only payload element defined so far is the <gathering-complete/> element. This element is used only to signal that gathering of ICE candidates has been completed (i.e., to send an "end-of-candidates indication"), as in the following example.
Added OMEMO encryption namespace.
+Made XEP experimental again.
+