XSF Discussion - 2021-01-27

  1. Zash

    I just realized that XEP-0363 talks about the <header>s as MAY. Does this mean as a server-side implementer I can't actually use that?

  2. jonas’

    depends on whether you control the client

  3. Zash

    Not quite worded in an obvious compliance level way tho

  4. Zash

    Oh > the client MUST include all allowed headers that came with the slot assignment.

  5. Zash

    So, server MAY include <header>s, client MUST support.

  6. jonas’


  7. flow

    I wonder if this is a case where the 'may' should be lowercased

  8. Zash

    So I need to file a bug report instead instead of redesigning my thing.

  9. jonas’

    I think so

  10. Zash

    Let's do it

  11. Daniel

    I don't find that very ambiguous tbg

  12. Daniel

    I don't find that very ambiguous tbh

  13. Daniel

    But I wrote the thing so I'm obviously biased

  14. dwd

    I don't understand the problem - servers might or might not include headers, entirely at their discretion, but if they do then client have to handle them if they expect things to actually work.

  15. jonas’

    dwd, then the MAY is not RFC 2119 language in that context, but just plain english IMO

  16. jonas’

    the action of a server including or not including headers is irrelevant for interop, what is relevant for interop is that clients can deal with the case (where the MUST is also placed)

  17. Zash

    Daniel, mostly because I didn't see the part about clients when I searched, which is isn't in the same spot in the document.

  18. Daniel

    Zash: I'd be curious on where and how you use the headers though. Because I started to suspect nobody uses them

  19. dwd

    jonas’, One implies the other, indeed, but actually the way RFC 2119 is written, MAY implies MUST on the recipient, and not the other way around.

  20. Zash

    Daniel: I recently started on a new implementation and went with passing magic via a Authorization header.

  21. Zash

    dwd, oh!

  22. dwd

    Zash, Oh?

  23. Zash

    re > MAY implies MUST

  24. dwd

    Zash, Well, what it says is more nuanced, but: An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality.

  25. Zash

    So, never mind, just me not having read the whole thing into my head yet 🙂

  26. jonas’

    dwd, TIL

  27. jonas’ goes back to updating countless instances of sudo(1)

  28. dwd

    Zash, So there's an implication here that a client could conform to the server's MAY by ignoring the headers, which we don't want.

  29. dwd

    jonas’, I did my bastion hosts last night, indeed. Got the rest of the estate to do today and our head of infra is off sick so I suppose it's my job now.

  30. jonas’

    dwd, hah

  31. dwd

    Zash, But anyway MAY send, MUST handle is fine by me. I've generally preferred specifying sender/receiver behaviour separately, and it's especially useful in fun cases like MUST NOT send, SHOULD ignore, where you have legacy behaviour to deal with.