XSF Discussion - 2023-05-17


  1. goffi

    Why was XEP-0353 (Jingle Message Initiation) namespace version downgraded in v0.6.0? There are new things (like <ringing>, use or the "store" hint) that were not presend in 0.3.1. I have to update my implementation, and normally namespace version is an indicator of that.

  2. goffi

    also the XEP talks about "media type" which comes from XEP-0167, but it's really useful with other non A/V calls use cases (like file transfer). Would be nice to make it more explicit.

  3. MattJ

    goffi, as the extension is already deployed, it was decided that backwards-incompatible changes were not desirable

  4. MattJ

    So the latest version should be compatible with the deployed version

  5. goffi

    I think it's not, the store hint and <ringing> element where not present.

  6. goffi

    Anyway I'm updating now

  7. goffi

    were not present*

  8. goffi

    that's right that this extension it's delicate at there is not discovery, so that would mean sending one <message> for each supported namespace.

  9. goffi

    So I kind of get why this has been done this way.

  10. MattJ

    Store hint is in another namespace anyway. The addition of <ringing/> is indeed "technically" wrong, but it's optional and hopefully a lesser evil than entirely breaking compatibility with existing clients.

  11. flow

    a store hint can be added without a namespace version bump, as its just a hint

  12. pep.

    Mandating a store hint though isn't the same thing is "just adding a store hint", right

  13. flow

    I think it is for the question whether or not a namespace bump is required

  14. MattJ

    Sure. New (non-editorial) XEP versions can change requirements without changing the protocol syntax, and only syntax changes require namespace changes.

  15. flow

    I am sorry, "synatx" appears to be quite abstract in this discussion

  16. pep.

    Mandating a store hint though isn't the same thing as "just adding a store hint", right

  17. flow

    The question of bumping the namespace is always "does something break if we do not bump it"?

  18. flow

    which is also quite abstract

  19. flow

    <ringing/> seems to be mandated, but not by RFC keywords. I wonder if something would break if older impls under the same namespace wouldn't send it

  20. flow

    I would hope not, but this seems to be borderline

  21. flow

    but I am happy to see urn:xmpp:hints back in buisness \o/

  22. Zash

    What happens if thing on the new version talks to thing on the old version?

  23. flow

    goffi, maybe you could help to answer this question: do you need to upgrade your implemention so that it follows the current spec or does something break if your implementation speaks to a newer-spec implementation?

  24. goffi

    flow: I have other issues in my implementation (the media type was missing notably), resulting in issues, so it was broken anyway in my case.

  25. flow

    goffi, I see, thanks for sharing :)

  26. singpolyma

    Adding elements shouldn't require a namespace change, surely? Rather removing, renaming, or changing the semantics of existing ones should

  27. Zash

    As a general rule, I would think so, yeah.

  28. Zash

    Unless something really bad happens if the receiving entity ignores a new element.

  29. MattJ

    > Adding elements shouldn't require a namespace change, surely? This is not clear. There is an argument for immutable namespaces, and some implementations may validate or otherwise depend on adherence to a known schema. That most implementations just look for and pluck out elements they are expecting is not necessarily a fundamental design choice of XMPP (ignoring unknown namespaces is, explicitly).

  30. Zash

    Historically, we haven't taken schemas _that_ seriously.

  31. Zash

    And practically, it'd be pretty painful for minor changes.

  32. MattJ

    Yeah, but let's admit that this is mostly laziness and lack of nice tooling, rather than an explicit choice :)

  33. Zash

    Agree

  34. MattJ

    and there have always been some projects doing stuff with schemas

  35. MattJ

    I'm not against the addition of <ringing/>, to be clear. I think extending existing namespaces is something we shouldn't make a habit of, but sometimes the alternative options are simply worse.

  36. Zash

    Part of the problem is mismatch between XEP status and deployment status, I think. I.e. Experimental things getting implemented and deployed everywhere without advancing to Draft.

  37. singpolyma

    I think changing namespace is basically always bad, but sometimes necessary, since it destroys forward compatibility and makes back-compat take a bunch more code. Ref all my code that looks for one of three jingle namespaces and then treats the elements exactly the same no matter which of the three it finds...

  38. pep.

    "some implementations may validate or otherwise depend on adherence to a known schema" < This, yes.

  39. pep.

    xmpp-parsers checks strictly, unless specified like bookmark2's <extensions/>

  40. pep.

    fwiw this has helped uncover some bugs already

  41. pep.

    fwiw this has helped uncover some bugs already in other implementations

  42. singpolyma

    You should be able to check <extensions/> strictly, since it can contain no children in it's own namespace

  43. pep.

    True

  44. singpolyma

    IMO schemas are descriptive, especially pre-Final status for XEP. Doesn't mean not useful, but if a client barfs on an unknown tag being present instead of ignoring it, especially on non-Final namespace, that's asking for trouble

  45. pep.

    Relatedly, recently I was looking at mentions (372), and a proposed change for referencing something else than <body/> completly breaks this. That is, the possibility to add an "id" attribute on any other element to refer to it via the <reference/> tag

  46. singpolyma

    And I already live with the pain if namespaces that were changed too often (like the three identical jingle ones)

  47. singpolyma

    pep.: Sounds like an actual use case for namespaced attribute?

  48. pep.

    Well stuff like this is generally negociated.

  49. pep.

    For example in 463, I have introduced a namespace attribute on <{muc}x/> in the reply from the server, but that's only if the client signals it knows the protocol

  50. pep.

    For example in 463, I have introduced a namespaced attribute on <{muc}x/> in the reply from the server, but that's only if the client signals it knows the protocol

  51. pep.

    But maybe that's a use-case for these yeah.. even not negociated

  52. pep.

    But then all hail breaks loose.. if anything can be added anywhere. Isn't it that extensible pieces are generally defined extensible preventively? Or negociated.

  53. singpolyma

    Well new namespace things can surely be added anywhere. And if implementing a pre-Final protocol one thing expect it is perhaps not... final. IMO

  54. singpolyma

    Well new namespace things can surely be added anywhere. And if implementing a pre-Final protocol one should expect it is perhaps not... final. IMO

  55. singpolyma

    Except in some cases where the spec really says do not I guess, like if must have only one child no matter the namespace and data form value must have no element children of any kind

  56. pep.

    Unless negociated*

  57. pep.

    Anything is possible anyway when negociated

  58. flow

    singpolyma, do you see a better alternative than bumping the jingle jingle namespace (three times)?

  59. singpolyma

    Hello all, FOSSY conference has put out their Call for Booths now as well: https://2023.fossy.us/call-for-booths/ While I can apply for an XMPP booth as a community project, I think it might be a more impactful application if it were an "XSF booth" such that it is both a community project and a non-profit org. So I'm wondering if it would be possible to do this? All I really need is someone on board to say "yes" I guess since I'm not asking anyone to do anything really, happy to provide materials and organize volunteers for the booth etc myself

  60. singpolyma

    flow: I would have to dive into why the namespace was bumped to be sure

  61. flow

    I am also not sure why we should not be able to add unnamespaced attributes (and namespaced) elements later on without a namespace bump

  62. flow

    under the assumption that those additional attributes/elements can be ignored

  63. Kev

    > Historically, we haven't taken schemas _that_ seriously. Just because the XEP schemas aren't great, doesn't mean that someone can't produce a schema from the normative text and validate on that. Because that sounds like the sort of thing people might be hypothetically doing.

  64. flow

    fwiw, I take schemas seriously :)

  65. flow

    I think people mix two aspects of schema validation: validating things the schema describes and validating things the schema does not describe

  66. Zash

    Hm, doesn't affect the holy commandment of "Ignore what thou doth not understandeth" ?

  67. Kev

    It does, because you understand the namespace, and what you received should not be in it.

  68. Zash

    (Whether you're doing schema validation or fuzzy `e.get(name, namespace)`

  69. flow

    while IIRC XML schema's usually forbid extending the XML with attributes and elements not described by the schema, this is some limitation that we in XMPP should not follow, as it makes it impossible to extend an existing protocol without unnecessarily (from the protocols pov) namespace

  70. singpolyma

    I suppose there's also no reason a XEP can't define a new element in a new namepace and not change the namespace for existing elements

  71. Kev

    > I suppose there's also no reason a XEP can't define a new element in a new namepace and not change the namespace for existing elements Yes.

  72. MattJ

    This is what we did in XEP-0313 not too long ago

  73. Kev

    Other places too.

  74. singpolyma

    that would be fine. I just dislike changing for existing elements when there is no breaking change to how they are used. new elements in new namespaces vs existing namespaces is the same either way to me