XSF Discussion - 2021-01-27

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?

depends on whether you control the client

Not quite worded in an obvious compliance level way tho

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

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

:)

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

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

I think so

Let's do it

I don't find that very ambiguous tbh ✏

But I wrote the thing so I'm obviously biased

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.

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

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)

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.

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

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.

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

dwd, oh!

Zash, Oh?

re > MAY implies MUST

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.

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

dwd, TIL

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.

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.

dwd, hah

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.