XSF Discussion - 2020-02-11

Last thing I remember was a design contest. But was there a decision? Also: Do we have one or two sets (simple badge/bigger one for official websites)?

wurstsalat IIRC, we are in process of reaching out to the designer of the stuff that we picked. I'm afraid that that has fallen off the radar a bit though.

Unless ralphm has had updates?

I don't, tried to get in contact a while ago and didn't succeed. Then fell off the radar

dwd, glad to see you’re still alive. Care to also vote on the advancement of XEP-0363? The vote expires tomorrow.

jonas’, dave voted -- https://mail.jabber.org/pipermail/standards/2020-February/036962.html

theTedd, uuuh thanks

I totally missed that one

and it’s old, too

Daniel, Subject: DRAFT: XEP-0363 (HTTP File Upload) congrats! :)

jonas’: thanks :)

quick question about XEP-0085 (Chat State Notifications): I shouldn't receive notifications from events that happened while I was offline (right?) - is that the client's fault for sending them, or the server's fault for storing them, or both?

Probably the servers fault for storing them

theTedd, it’s not the clients fault for sending them

your presence state may be stale or hidden or ...

And/or the clients fault for not setting proper hints

But I wouldn't blame the sender for sending them

it's all jabber.org's fault - hints are there too

No store?

from memory, but yes I think so

omg a XEP made it to DRAFT

congrats Daniel

i thought i never live to see that day

I hope we’ll see more of that in this and the next quarter

https://sotecware.net/images/dont-puush-me/3-_C0ZrAXnizG1GC2vRyi13AIXJDJcp9WKDEr_JmmMo.png

crazy times

s/crazy/interesting/

What was the last xep before that made it to draft? And the last that went final?

I still think we should merge draft and final into a common "living standard" phase

moparisthebest, XEP-0300 to Draft on 2019-11-13 ✏

right before that, XEP-0423 on 2019-11-07

re Final: my git foo may be tricking me, but it’s possible that was XEP-0047 on 2012-06-22

Ouch

(though we have did start the process for a move to final for '198 today)

(and I expect it to pass without much trouble)

I was planning to try to push 368 to final when the time was up but apparently forgot

moparisthebest, right, we figured that out after the last Council session

good idea

I don't generally set calendar reminders that far out then just forget about it :)

I’m going to fire up a CFE for that right now, those are cheap. And the Editor can simply do that.

done

(I expect the LC I put on the Council agenda not to start before next week, so we won’t have too many things in-flight)

moparisthebest, there you go, lots of feedback to XEP-0368 (and also why I think it can’t move to final as-is)

well the mixing is a SHOULD not a MUST, it's even watered down further with "However, clients MAY choose to prefer one type of connection over the other."

which, reading again, is kind of funky :)

I'll respond officially on-list later, but long story short I'm not married to that at all

moparisthebest, not saying you are, just saying that we need to spell things out clearly before moving on to Final

and if we allow Mixing but not have it a MUST, it the operator considerations still need to be written down

yep absolutely

(also the "dot" cases I mentioned in the email, although I found that you have one of them already covered in section 5)

the document needs a nice table with how to handle the different cases.

a server operator can't count on anything regardless (any addresses/ports could be blocked from any client/server with any SRV records), that maybe should be spelled out anyway though

true

with STARTTLS, you at least can count on the order things are tried, even though you cannot rely on observing that order

and that pretty much makes the mixing thing not matter, you either do standard xmpp, direct tls, either alone or one after the other, or mix them

in which case it should be downgraded from a SHOULD to a MAY

with clearly spelling out why it doesn’t matter in practice

that sounds right

if you look at the commit history it used to be a MUST and it was downgraded to a SHOULD right before going to draft if I remember correctly

sounds about right

How are version numbers of XEPs interpreted? Semantic Versioning?

debacle, don’t ask that

jonas’ hehe

for Standards Track: 0.x.y = Experimental, 1.x.y = Draft, 2.x.y = Final

(though [012].x.y may also be Deprecated/Obsoleted if it went there straight from the other state)

debacle, I try to increase x only on non-Editorial changes

I see. Not *that* bad.

except that it hasn’t always been handled this way, and some XEP versions don’t have a third digit and stuff like that

I’m also quite unhappy with the major digit regime strictly relating to the status

I’d prefer if we could bump the major version number in Draft if we do a namespace bump

also, the move to Final is typically the most insignificant thing (because development towards that happens in Draft) and most certainly does not deserve a major version bump

jonas’ Thanks for the explanation!

debacle, you’re welcome

Guus, ralphm thanks Re Badges!

What's the appropriate error for a server to send when it receives a stanza meant for an external component that isn't connected at the moment?

Prosody says wait, service-unavailable, but this apparently means "MUC occupant limit reached"

Not seeing anything in xep-0114 or 0225 about this

https://xmpp.org/extensions/xep-0045.html#enter-maxusers Why isn't this resource-constraint ?