KevI'll try to get this one on-list, but realistically I'm flat out until holiday and it might expire.
ZashI heard Georg is on vacation
DaveI'm +1 on this, though i would like to understand how it differs from the de-facto that it suggests exists.
SamWhitedI'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.
danielMinus presence plus in Disco info
Link MauveDave, I tried to explain that in both the introduction and section 5.2.
KevI'm +1, have just scanned it.
danielBut I'm not entirely sure about the motivation
Link MauveSamWhited, I hesitated about making it just informational, still not too sure.
DaveLink Mauve, Ah, I thought that was just about presence.
DaveSamWhited, It's mostly usage and semantics rather than protocol, but it seems useful to document.
SamWhitedThat might make a bit more sense, having a standards track XEP that rehashes a historical one and adds discovery just feels odd
Link MauveDave, presence vs. disco#info is the only part where my proposal differs from the status quo.
DaveLink Mauve, Gotcha.
SamWhited"That" == "Informational"
danielBut since servers will do that anyway now I don't think that this xep will retroactively fix that
danielI mean sorry that clients broke and all
SamWhitedDocumenting 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"
Link MauveAt least Prosody will probably skip on the presence way.
danielBut the demage is done
danielBut we don't have to discuss this on council
SamWhitedOr a nod to vcard temp in 0045 even
DaveSamWhited, Are you voting on this or thinking? (Georg is presumed to be on list anyway)
danielI'm +1 and then we can discuss on list once the xep is out
SamWhitedI'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.
Daveb) XEP-0060: Add an example on returning fewer items than requested https://github.com/xsf/xeps/pull/695
danielAlso really if your client breaks if you get a presence from a bare jid. Wtf. Just fix your client
danielThe neat thing about doing the presence hash thing is that it worked instantly w/o any changes
Davedaniel, Feel free to argue this position on list. :-)
DaveAnyone any votes for this PR?
DaveI personally think it's straightforward, so +1.
SamWhited+1 on the PR, though I'll leave an editorial note for the author, but it won't change the substance of it
KevI'm not sure why this is a thing. What's the backstory here?
DaveLink Mauve, ?
DaveKev, 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.
KevIt being the obvious thing made me wonder why it needed to be a thing.
Link MauveHmm, it was during the XMPP Sprint with MattJ, we IIRC encountered a case where Prosody was sending back an error instead of zero items.
Link MauveThis makes sure servers behave correctly in this case.
KevFair enough. No objections here.
DaveKev, Is that a 0 or a +1?
SamWhitedAdded 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.
SamWhited(I'm +1 either way with my council hat on, nits are with my editor hat on)
Kev0 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.
Dave4) Next Meeting
DaveI saw you were saying you'll be away for a bit, Kev?
KevI'm out of action until October.
DaveAnyone else going to be MIA?
Kev(That'll be fully out of action, not on-list, unfortunately)
DaveI have no idea how you'll survive.
DaveI'll assume the rest of us will meet same time, same channel.
DaveSo absent anything else, thanks all, see you next week.
Dave5) Ite, Meeting Est.
Link MauveBtw, 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?
DaveLink Mauve, I believe that those have had votes and expired. I'll see about tidying these up and ensuring they're documented etc.
guus.der.kinderenDave: #579 was voted on?
guus.der.kinderenThe h thingy on SM
guus.der.kinderenIt was in February, but was modified since.
Link Mauvehas left
flowguus.der.kinderen, #579 appears to be conflicting with master (at least gh tells me so)
flowguus.der.kinderen, I would suggest squashing into a single commit and rebaseing on the current master