XSF Discussion - 2024-03-10

  1. ogkiwi

    python certs am i right

  2. ogkiwi

    pcep test soon

  3. Daniel

    Oh I was mentally preparing myself to give feedback that we should remove color correction from 0392 and then I saw it's already gone

  4. jonas’

    someone pointed out that that's more of an OS-level thing and so I dropped it

  5. Daniel

    Yes I was going to say that. Plus we don't know if there might even be some bad interaction if you have OS level correction and xep-level / application level correction

  6. jonas’


  7. pep.

    Recently there were changes to add Privacy considerations to the XEP template right? Could LC also include this? I'm only seeing questions re security considerations

  8. Daniel

    I don't understand the question as being explicit about the security considerations. I'm reading this as a broader question

  9. Daniel

    We don't have explicit questions for 'are the business rules correct' either

  10. jonas’

    adding a question regarding privacy considerations might be sensible nontheless to raise awareness

  11. jonas’

    especially in older XEPs, where it hasn't been part of the template, the LC is a good point to review whether it should maybe be added.

  12. pep.

    https://xmpp.org/extensions/xep-0360.html > Informal definition: A XMPP stream element is a Nonza, if its element name is not 'message', 'iq' or 'presence'. Isn't this missing a mention of the namespace?

  13. jonas’

    probably deliberately omitted because jabber:{client,server,whatever-the-heck-component-uses}

  14. Zash

    but, but, explicit > implicit

  15. jonas’

    yes, it should be mentioned

  16. pep.

    Also.. wasn't there something "after <bind/>" too? Like the IBR iq not being a stanza or something?

  17. jonas’

    otherwise in a few years someone comes along and defines a <presence xmlns="foo"/> nonza and all stream management impls go haywire

  18. Zash

    and one day it'd be nice to merge those

  19. Zash

    pep., hush, special case, lalalalala let's not talk about it

  20. pep.


  21. jonas’

    '198 should probably refer to '360 once it's stable

  22. Zash

    but yeah, that is considered a nonza by Prosody now, for authz reasons

  23. Zash

    but then bind2 & friends makes that go away :D

  24. pep.

    jonas’, re the many namespaces, maybe it could be.. "the default stream NS"? :x Even though that's just an artifact of how examples are written / xml is made. I guess one doesn't need to declare a default namespace on the stream

  25. jonas’

    RFC 6120 has words on that I'm not gonna look up now

  26. pep.


  27. pep.

    I guess that's called "content namespace" https://www.rfc-editor.org/rfc/rfc6120#section-4.8.2

  28. jonas’

    oh look, jabber:{client,server} actually have different schema requirements (@to/@from optional in jabber:client, required in jabber:server)

  29. Holger

    XEP-0045 says: > An admin can grant membership to a user; this is done by changing the affiliation for the user's bare JID to "member" (if a nick is provided, that nick becomes the user's default nick in the room if that functionality is supported by the implementation) https://xmpp.org/extensions/xep-0045.html#grantmember What does "default nick" mean, here?

  30. MattJ

    Just pretend you didn't read it

  31. MattJ

    But Prosody does s/default/registered/

  32. Holger

    Heh, thx.

  33. Daniel

    > But Prosody does s/default/registered/ Meaning nobody else can take that?

  34. Zash


  35. cal0pteryx

    Since WhatsApp links directly to https://xmpp.org/about/technology-overview/ in their "WhatsApp Developer Documentation Overview" at https://developers.facebook.com/m/messaging-interoperability we could use that opportunity to update that page. I'm going to help implement if there are ideas

  36. MattJ


  37. cal0pteryx

    Apart from the usual text and images, data from XEPs and implementations would be available for all kinds of data aggregations. Diagrams using Mermaid would also be available.