Hello standards@,
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
Yes, definitely. As a user of multiple devices, I very much appreciate
the feature. As an XMPP evangelist, I have had feedback from new users
about "read state not working in public channels". As a developer of
gateways, I am happy that XMPP clients can be on par with a feature that
most other chat apps provide.
2. Does the specification solve the problem stated in the introduction
and requirements?
Yes.
3. Do you plan to implement this specification in your code? If not,
why not?
Yes, I have developed a draft for this feature in gajim. Because of the
way read state works in gajim, it is suboptimal and hasn't been merged
in the master branch. I do, however, use it anyway.
I also have developed the feature in slidge gateways. Because it is
pubsub-based, it requires the gateway to be a XEP-0356 privileged
entity, specifically requiring "IQ privilege" for the pubsub node.
4. Do you have any security concerns related to this specification?
No, but security definitely isn't my area of expertise.
5. Is the specification accurate and clearly written?
Yes. It is always a bit confusing to know what "message ID" one has to
use, but this is not specific to this specification. It all makes sense
once you are used to it, but the complexity of knowing what message
identifier one has to use can be discouraging for new XMPP devs.
Long live MDS! MDS everywhere!
--
nicoco
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
