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
_______________________________________________
