On 9/5/19 7:52 PM, Jonas Schäfer (XSF Editor) wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Message Fastening > Abstract: > This specification defines a way for payloads on a message to be > marked as being logically fastened to a previous message. > > URL: https://xmpp.org/extensions/inbox/fasten.html
Thank you, Kev for pushing this forward. I think the kind of attention this ProtoXEP already has received, shows that the XMPP ecosystem needs such a XEP and the community desires one. I want to suggest one small change to how the attached-to message is specified: I always assumed that, if xep359 is used to refer a message, the reference would not just be the id-value, but a tuple of id-value and the id-assigning-entity address. This avoids ambiguity if a <apply-to/> attaches to a stanza which multiple <stanza-id/> elements. Furthermore, xep359 makes it very clear that xep359-IDs are just unique and stable within the scope of the id-assigning-entity (this allows implementations to use simple mechanisms to generate the ID without considering collisions with other id-assigning-entities). So assume we have <message from='r...@muc.example.org/Kev' …> <stanza-id xmlns='urn'xmpp:sid:0' id='1' by='r...@muc.example.org'/> … </message> The according <apply-to/> element should include a 'id-by' (name is subject to bikeshedding) attribute: <apply-to xmlns='urn:xmpp:fasten:0' id='1' id-by='r...@muc.example.org'/> I was not yet able to conclude how it should look like for 1:1 chat and <origin-id/>. However, I assume that the only relevant case where you want to attach to via <origin-id/> is 1:1 chat. All other cases I can think of right now, like MUC and MIX, would have the room/channel as id-assigning-entity and therefore use <stanza-id>. Then the value of 'id-by' attribute could potentially be the full JID of the sender in case of <origin-id/>. That is my main concern with the current ProtoXEP right now. However, I am probably going to think a little bit more about it, which could lead to some more feedback. What follows are some nits and remarks in no particular order: Please remove "that contains content" from the very first sentence, to make it more readable. Explicitly referring to Entity Capabilities (XEP-0115) in § 2. is redundant and prone to becoming outdated. I wish XEPs would instead point to a location, for example in XEP-0030, where the interested reader can read more about the current state of affairs regarding feature discovery caching mechanisms. I would be happy to create such a location if there is a consensus that this is a good idea. The <external/> element should always state the QName of the external element. I suggest we normalize the namespace of <body/>, and the other few elements that carry multiple namespaces, to jabber:client. The semantic of attaching again to a message which we already attached to while using replace=false should be spelled out. Assuming 'false' is the default value for the 'replace' attribute. I probably need to think some more about it, but it feels like replace='true' is like a reset: It doesn't just replace a single "attachment" but all previously attached messages (regarding the child payload in question). Is that correct? - Florian _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________