XMPP Council - 2024-03-25

  1. daniel

    > On 333, should Sending be explicitly dependent on the markable/request? Currently it's sort-of implied. Vote: +0 (but 1 outside of this question). dan.caseley: have you had time to look into your pending votes?

  2. dan.caseley

    Sorry, work life was hilarious today. GitHub Actions can get in the sea. Looking now.

  3. dan.caseley

    On Message Display Synchronization, I'd prefer that the first requirement referenced a Compatibility Suite rather than "what is commonly implemented at the time of writing". This statement becomes meaningless for future readers. Not a blocking complaint for experimental, I suppose. I'd also have preferred an extra example in §4.5.3 to show the outbound message after stripping. But I could add that myself. It's a preference thing. The first business rule in s5 talks about IDs only moving forward. Is this practical? It's not required by XEP-0359. The second business rule requires that server knows all prior stanza IDs. As before, is this already always available, given the point in s2 about not requiring MAM?

  4. dan.caseley

    On the 5th rule... if you've already got the server doing assisting, can't it strip the full jid to a bare jid? I'm sure there's a good reason, but it isn't given.

  5. dan.caseley

    Does the first security consideration regarding publish-options (or the reference in §4.2) also imply that the server MUST support publish-options to support this XEP?

  6. dan.caseley

    (If there are going to be changes, "server-assisted" has a typo in the 3rd item in Security Considerations)

  7. dan.caseley

    There's some stuff here that I'd like to see changed. I'm not against publishing with an assurance that the changes will be made. The author appears trustworthy :)

  8. dan.caseley

    daniel: Let me know if it makes more sense to put all of this through the Standards mailing list for visibility.

  9. dan.caseley

    On the Final Call for XEP-0398, +1