XMPP Council - 2018-09-05

XMPP Council Room | https://xmpp.org/about/xmpp-standards-foundation#council | Room logs: http://logs.xmpp.org/council/ | https://trello.com/b/ww7zWMlI/xmpp-council-agenda

Afternoon. I'm less rubbish than last week (in as much as I'm here), but more rubbish than I should be because I havem't had a chance to do the agenda.

This is definitely on it though: https://xmpp.org/extensions/inbox/muc-avatars.html

So this would be the agenda, if I read correctly: https://docs.google.com/spreadsheets/d/1AZ-Sna6OiRG--b-mJMKv3XXfrn3Nehm0kAtlyJvImL0/edit#gid=0&range=B93

No, some (many) of these have been voted on.

Right, corrected, though I'll fill the votes in later for the ones that have been done.

Righty, 'tis time.

1) Roll Call

Who be here?

Here. Entirely unprepared, but here.

I'm pretty unprepared as well.

I am here, and have read at least one of the protoxeps

But also pretty unprepared

SamWhited, There's only one protoXEP, plus one PR.

Oh, I thought a second one came in. I have read the protoxep!

No Daniel or Georg?

2) Voting On Stuff

a) MUC Avatars https://xmpp.org/extensions/inbox/muc-avatars.html

Here

+1

I'll try to get this one on-list, but realistically I'm flat out until holiday and it might expire.

I heard Georg is on vacation

I'm +1 on this, though i would like to understand how it differs from the de-facto that it suggests exists.

I'd be curious to hear what others (especially client authors) think about this one. I tend to think it's unnecessary, because you can just do it all already as far as I can see and having a second XEP that says more or less the same as vcard-temp feels awkward to me.

Minus presence plus in Disco info

Dave, I tried to explain that in both the introduction and section 5.2.

I'm +1, have just scanned it.

But I'm not entirely sure about the motivation

SamWhited, I hesitated about making it just informational, still not too sure.

Link Mauve, Ah, I thought that was just about presence.

SamWhited, It's mostly usage and semantics rather than protocol, but it seems useful to document.

That might make a bit more sense, having a standards track XEP that rehashes a historical one and adds discovery just feels odd

Dave, presence vs. disco#info is the only part where my proposal differs from the status quo.

Link Mauve, Gotcha.

"That" == "Informational"

But since servers will do that anyway now I don't think that this xep will retroactively fix that

I mean sorry that clients broke and all

Documenting things sounds find, but it feels poor to have multiple XEPs in various states documenting the same thing. Couldn't we equally just add a note to vcard-temp saying "remember, MUCs are JIDs too"

At least Prosody will probably skip on the presence way.

But the demage is done

But we don't have to discuss this on council

Or a nod to vcard temp in 0045 even

SamWhited, Are you voting on this or thinking? (Georg is presumed to be on list anyway)

I'm +1 and then we can discuss on list once the xep is out

I'm thinking out loud, just curious to get others opinions. I guess I'm on list. I'm hesitant to publish this, but it seems fine protocol-wise.

Cool.

b) XEP-0060: Add an example on returning fewer items than requested https://github.com/xsf/xeps/pull/695

Also really if your client breaks if you get a presence from a bare jid. Wtf. Just fix your client

The neat thing about doing the presence hash thing is that it worked instantly w/o any changes

daniel, Feel free to argue this position on list. :-)

Anyone any votes for this PR?

I personally think it's straightforward, so +1.

+1 on the PR, though I'll leave an editorial note for the author, but it won't change the substance of it

I'm not sure why this is a thing. What's the backstory here?

Link Mauve, ?

Kev, FWIW, the XEP doesn't say what happens if a clientrequests N most recent when there are only M (M < N) items present. This is the obvious thing to do.

It being the obvious thing made me wonder why it needed to be a thing.

Hmm, it was during the XMPP Sprint with MattJ, we IIRC encountered a case where Prosody was sending back an error instead of zero items.

This makes sure servers behave correctly in this case.

Fair enough. No objections here.

Kev, Is that a 0 or a +1?

+1

Added some minor nits on wording; only the first one really needs to be fixed. The other is just me being picky and I don't think it actually matters, feel free to disregard.

(I'm +1 either way with my council hat on, nits are with my editor hat on)

0 because I don't have time to do the full review involved in +1ing it. The patch looks fine, but I don't think it's sufficiently diligent to approve just based on the diff - we know how that has worked in the past with complex XEPs like 50.

OK

3) AOB

Nowt.

4) Next Meeting

I saw you were saying you'll be away for a bit, Kev?

I'm out of action until October.

Anyone else going to be MIA?

(That'll be fully out of action, not on-list, unfortunately)

I have no idea how you'll survive.

I'll assume the rest of us will meet same time, same channel.

WFM

So absent anything else, thanks all, see you next week.

5) Ite, Meeting Est.

Btw, there are still quite a few outstanding PRs at https://github.com/xsf/xeps/pulls which are tagged as Needs Council, could you add them all to next week’s agenda?

Link Mauve, I believe that those have had votes and expired. I'll see about tidying these up and ensuring they're documented etc.

Ta.

Dave: #579 was voted on?

The h thingy on SM

It was in February, but was modified since.

guus.der.kinderen, #579 appears to be conflicting with master (at least gh tells me so)

guus.der.kinderen, I would suggest squashing into a single commit and rebaseing on the current master