20 Mar
2024
20 Mar
'24
9:19 a.m.
Hi Matthew,
On Thu, Feb 23, 2017 at 1:53 PM Matthew Wild <mwild1(a)gmail.com> wrote:
On 8 February 2017 at 23:47, Christian Schudt <christian.schudt(a)gmx.de> wrote:
Maybe the document should go into more detail regarding differences
with AMP. Some notes:
- You can implement both specifications if desired
- Over 10 years after publication, XEP-0079 is not widely
implemented, I believe this is largely due to its complexity
- XEP-0079 requires multiple discovery steps before you can actually
send a message
- XEP-0079 is relatively difficult to re-use in other XEPs
- Lots of edge cases, e.g. interaction with MUC rooms. With hints the
server is still free to choose the most sensible option given the info
it has.
Council has Issued another Last Call on 0334¹ and I've been going over
the feedback from the last Last Call.
The Editor will start the Last Call next Monday.
I think it received mostly positive feedback back then and I have no
reason to believe it won’t pass Last Call this time.
However I think you were right that the document should go into more
detail regarding differences with AMP.
Furthermore a little down the thread Dave had feedback wrt hints in
Error messages:
"I noted that messages of type error are explicitly called out in §4.4,
however I think there needs to be a general rule that hints SHOULD be
ignored in messages of type='error'. Possibly MUST. Errors are
sometimes generated by bouncing the entire stanza, including original
contents, back to the sender, and these original contents might
include a hint; it seems sensible to always ignore these."
that also sounds like a sensible addition to me.
Maybe you have the time to make those changes before Last Call even
starts (next Monday)
Thank You
cheers
Daniel
¹: On February 8th 2023
1. Is this specification needed to fill gaps in
the XMPP protocol stack or to clarify an existing protocol?
Partly.
XEP-0079: Advanced Message Processing already solves the same problem.
drop forward => no-copy
drop stored => no-store