> On 9 Sep 2019, at 20:37, Florian Schmaus <f...@geekplace.eu> wrote: > > 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).
Good point, thanks Flo. Although I’m not sure that 359 does make it clear that it’s not globally unique, actually the opposite - I believe it’s a SHOULD on using UUID, and my understanding has always been that these are intended to be globally unique (I realise you have authority on claims of the original intention) from reading it. This isn’t the only XEP that’s written on the basis of the unique IDs being unique :) We probably need to clear this up - was I the only one with this misconception? (i.e. do we update 422 (and others) or 359?) > 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. Will do. > 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. This is fair, but also consistent with other XEPs, so I’m inclined to leave for the moment. > 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. I’ll go along with the majority here if more people provide feedback. > 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? I’ll try to find some words that are clearer. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
