XSF Discussion - 2021-06-02

  1. MattJ

    `<xs:choice minOccurs='0'><xs:element ref='a'/><xs:element ref='b'/></xs:choice>`

  2. MattJ

    Does this only allow <a/><a/> or also <a/><b/>?

  3. MattJ

    I believe it's the latter, but would like a second opinion :)

  4. jonas’

    I also think its the latter

  5. MattJ


  6. şişio

    XMPP <3

  7. MattJ

    I just opened this draft PR for XEP-0227: https://github.com/xsf/xeps/pull/1064

  8. MattJ

    I'll post to the list, some reviewers would be nice

  9. Zash

    MattJ: for SCRAM storage, I'd recommend looking at https://datatracker.ietf.org/doc/html/rfc5803

  10. MattJ

    I did

  11. MattJ

    I used it as a reference, but I defined an XML mapping which I think simplifies it somewhat

  12. DebXWoody

    How should we implement message reflection? #1: In XEP-0045: The service SHOULD reflect the message with the same 'id' that was generated by the client, to allow clients to track their outbound messages. If the client did not provide an 'id', the server MAY generate an 'id' and use it for all reflections of the same message. #2: On the Wiki page: 1) you recently sent a message to the MUC, AND 2) the received message is from your participant JID, AND I) the XEP-0359 origin ID matches (probably not a transport) OR II )the message ID matches (a nice MUC, but not required by the XEP) OR #3: In XEP-0359 They are also useful in the context of Multi-User Chat (XEP-0045) [2] conferences, as they allow to identify a message reflected by a MUC service back to the originating entity. When I understood well, we should use message-id (muc#stable_id) instead of XEP-0359. If we assume that the implementation follows #1, it will be possible to build message reflection based on message-id, only. The text in the wiki #2 should change the order of I) and II) or drop I) at all. ( I just talk about basic XMPP via MUC - without the idea to have stanzas forwarded my different servers etc. - where XEP-0359 may helpful.) Is this correct or did I misunderstood something?

  13. MattJ

    You're right, practically all services take the muc#stable_id approach (jabber.org/M-Link used to be, and may currently still be, an exception)

  14. MattJ

    This happened because originally XEP-0045 did not specify the behaviour, so that text about reflecting with the same id was added later on

  15. DebXWoody

    Yes, I saw. But we should fix XEP-0359 and wiki as well?

  16. MattJ

    In my opinion yes, and origin-id should be removed from the XEP

  17. MattJ

    But last I knew the author disagreed :)

  18. DebXWoody

    Maybe there are other use cases where it can be helpful.

  19. DebXWoody

    But at least for MUC it will not

  20. DebXWoody

    Maybe in IoT where messages get routed by lot of "things", each can att a origin-id ID.

  21. DebXWoody


  22. flow

    I think having a mechanism allowing an originating entity to signal that it has assigned the given unique and stable ID to one an outgoing stanza could become handy. That said, the use origin-id use case for MUC is now gone and the XEP should reflect that.

  23. flow

    DebXWoody, in that case you would use probably <stanza-id/>

  24. Geno


  25. eta

    MattJ, there are decent arguments against using the client ID

  26. eta

    the client-supplied ID is not always unique

  27. eta

    oh wait, but I guess that's what XEP-0359 is for

  28. DebXWoody

    To be unique is an agreement which can be defined in origin-id and also in message-id. At the end of the day the client has to generated the id and as to make sure it's unique. Should be a problem - for both concepts.

  29. DebXWoody

    Shouldn't be a problem

  30. Kev

    Until you have to trust hostile clients :)

  31. flow

    DebXWoody, sure, you *could* have also a marker extension telling that the rfc id is globally unique (as opposed to unique within the scope of a single stream)