From eb87a3b0bc4aed4d1a80aa23354902a2c0001ee2 Mon Sep 17 00:00:00 2001 From: Matthew Wild Date: Sat, 18 Aug 2018 18:08:11 +0100 Subject: [PATCH] XEP-0367: Update to specify the correct ID to use within MUCs --- xep-0367.xml | 123 ++++++++++++++++++++++++++++++++------------------- 1 file changed, 78 insertions(+), 45 deletions(-) diff --git a/xep-0367.xml b/xep-0367.xml index 21d8256f..355c0264 100644 --- a/xep-0367.xml +++ b/xep-0367.xml @@ -14,7 +14,7 @@ &LEGALNOTICE; 0367 - Deferred + Experimental Standards Track Standards Council @@ -30,6 +30,13 @@ Petchell cpetchell@atlassian.com + &mwild; + + 0.3 + 2018-08-18 + mw + Update to use unique stanza ids. + 0.2 2017-09-11 @@ -66,7 +73,7 @@

If a client implements message attaching, it MUST specify the - 'urn:xmpp:message-attaching:0' feature in its service discovery information + 'urn:xmpp:message-attaching:1' feature in its service discovery information features as specified in &xep0030; and the Entity Capabilities profile specified in &xep0115;.

@@ -83,7 +90,7 @@ id='miuARo9V'> … - + … ]]> @@ -91,16 +98,17 @@

Messages that are attached to other messages MUST contain an - <attach-to/> element qualified by the 'urn:xmpp:message-attaching:0' + <attach-to/> element qualified by the 'urn:xmpp:message-attaching:1' namespace and with an 'id' attribute set to the ID of the message that we - want to attach to. Messages MAY be attached to any other message, including - those sent by other clients, but clients MAY choose to ignore the attach-to - directive and display the message normally. + want to attach to (important note: the correct ID to use depends on the context, + see the business rules below). Messages MAY be attached to any + other message, including those sent by other clients, but clients MAY choose + to ignore the attach-to directive and display the message normally.

storm.png - + ]]>

Note that indicating that a message should be "attached" to an earlier @@ -109,42 +117,67 @@

-

- A receiving client MAY choose to show the attached message next to or below - the indicated message in whatever display is used for messages or can - choose to display the attachment in another way (including as a normal - message, completely ignoring the attach-to element). -

-

- A receiving client SHOULD indicate that the message is an attachment, and - not a part of the original message to prevent confusion. -

-

- <attach-to/> elements MUST NOT be put on any stanza type other than - messages. -

-

- A server may choose to strip some <attach-to/> messages based on - local policy (eg. a server might have a policy that only it can create - message attachments). -

-

Clients MUST send ids on messages if they support attachments.

-

- Messages MUST NOT contain more than one <attach-to/> element. -

-

- Clients and servers MUST NOT include an <attach-to/> element on - messages with a non-messaging payload unless they are including it on an - error which may be attached to the message that caused the error to be - generated. -

+ +

+ For messages of type 'groupchat', the stanza's 'id' attribute MUST NOT be + used for attachments. Instead, in group chat situations, the ID assigned to + the stanza by the group chat itself must be used. This is discovered in a + <stanza-id> element with a 'by' attribute that matches the bare JID of + the group chat, as defined in &xep0359;. +

+

+ For other message types the attacher should use the 'id' from a XEP-0359 + <origin-id> if present, or the value of the 'id' attribute on the + <message> otherwise. +

+ + +

+ A receiving client MAY choose to show the attached message next to or below + the indicated message in whatever display is used for messages or can + choose to display the attachment in another way (including as a normal + message, completely ignoring the attach-to element). +

+

+ A receiving client SHOULD indicate that the message is an attachment, and + not a part of the original message to prevent confusion. +

+ + +

+ <attach-to/> elements MUST NOT be put on any stanza type other than + messages. +

+

+ A server may choose to strip some <attach-to/> messages based on + local policy (eg. a server might have a policy that only it can create + message attachments). +

+

Clients MUST send ids on messages if they support attachments.

+

+ Messages MUST NOT contain more than one <attach-to/> element. +

+

+ Clients and servers MUST NOT include an <attach-to/> element on + messages with a non-messaging payload unless they are including it on an + error which may be attached to the message that caused the error to be + generated. +

+

- Clients that implement message attachments MUST be careful not to display - the attachments in such a way that they could be confused with the original - message and cause someone viewing the conversation to assume they were sent - by the sender of the message being attached to. + Clients that implement message attachments MUST display the attachments + in such a way that they could be confused with the original message and + cause someone viewing the conversation to assume they were sent by the + sender of the message being attached to. +

+

+ When matching a received attachment to the original message, clients must + ensure they match using the correct ID, as described in the business rules + section, e.g. within a group chat only the XEP-0359 stanza-id should be + matched against. If this is not available, the message SHOULD be displayed + as a normal unattached message.

@@ -153,7 +186,7 @@

This specification defines the following XML namespaces:

    -
  • urn:xmpp:message-attaching:0
    • +
  • urn:xmpp:message-attaching:1

The ®ISTRAR; shall include the foregoing namespaces in its disco @@ -161,7 +194,7 @@

- urn:xmpp:message-attaching:0 + urn:xmpp:message-attaching:1 Indicates support for attaching one message to another. XEP-xxxx @@ -173,8 +206,8 @@