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

Hello,

1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?

Yes.

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.

4. Do you have any security concerns related to this specification?

No.

5. Is the specification accurate and clearly written?

Yes Regards Philipp