Wednesday, March 08, 2017
council@muc.xmpp.org
March
Mon Tue Wed Thu Fri Sat Sun
    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27 28 29 30 31    
             
XMPP Council Room | http://xmpp.org/about-xmpp/xsf/xmpp-council/ | Room logs: http://logs.xmpp.org/council/ | https://trello.com/b/ww7zWMlI/xmpp-council-agenda

[00:12:25] *** moparisthebest has left the room
[00:12:40] *** moparisthebest has joined the room
[00:28:36] *** Lance has joined the room
[00:28:36] *** Lance shows as "online"
[00:45:07] *** Lance has left the room
[01:03:05] *** Tobias shows as "away"
[01:03:07] *** Tobias shows as "away"
[01:04:16] *** Tobias shows as "away"
[01:04:17] *** Tobias shows as "away"
[01:05:32] *** Tobias has left the room
[01:06:41] *** Tobias shows as "online"
[01:09:05] *** Tobias has left the room
[01:17:53] *** Tobias shows as "away"
[01:19:19] *** daniel has left the room
[01:26:09] *** daniel has joined the room
[01:31:44] *** daniel has left the room
[01:32:44] *** SamWhited shows as "online"
[01:45:56] *** daniel has joined the room
[02:31:01] *** jere has joined the room
[03:00:45] *** Zash shows as "away"
[03:03:08] *** Zash has left the room
[03:03:33] *** Zash shows as "online"
[04:16:34] *** jere has left the room
[04:39:50] *** moparisthebest shows as "online"
[04:40:18] *** Zash shows as "away"
[04:40:29] *** Zash shows as "online"
[04:55:12] *** Zash shows as "away"
[05:14:13] *** Zash shows as "online"
[05:14:29] *** Zash has left the room
[05:14:43] *** Zash shows as "online"
[05:16:07] *** Zash shows as "online"
[05:58:15] *** SamWhited has left the room
[06:08:20] *** Zash shows as "away"
[06:17:23] *** Tobias shows as "online"
[06:17:51] *** Tobias shows as "online"
[06:20:30] *** ralphm shows as "online"
[06:20:35] *** ralphm has left the room
[06:28:29] *** Tobias shows as "away"
[07:21:18] *** ralphm shows as "online"
[07:27:40] *** Tobias shows as "away"
[07:29:18] *** daniel has left the room
[07:29:25] *** daniel has joined the room
[07:32:19] *** daniel has left the room
[07:32:29] *** daniel has joined the room
[07:37:28] *** Tobias shows as "online"
[08:24:40] *** daniel has left the room
[08:24:50] *** daniel has joined the room
[08:27:45] *** Flow has joined the room
[08:31:15] *** ralphm has left the room
[08:36:52] *** daniel has left the room
[08:37:01] *** daniel has joined the room
[08:40:46] *** Kev has joined the room
[08:40:47] *** Kev shows as "online"
[08:41:20] *** Tobias shows as "online"
[08:41:49] *** Tobias shows as "online"
[08:41:49] *** ralphm shows as "online"
[08:46:44] *** ralphm shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[08:50:31] *** Tobias has left the room
[08:50:44] *** Tobias shows as "online"
[08:51:07] *** Tobias shows as "online"
[08:51:38] *** Tobias has left the room
[08:56:44] *** ralphm shows as "xa" and his status message is " (Not available as a result of being idle more than 15 min)"
[09:00:28] *** ralphm shows as "online"
[09:06:26] *** ralphm shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[09:09:19] *** Flow shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[09:11:51] *** Flow shows as "online"
[09:16:26] *** ralphm shows as "xa" and his status message is " (Not available as a result of being idle more than 15 min)"
[09:17:02] *** ralphm shows as "online"
[09:23:24] *** Flow shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[09:23:34] *** ralphm shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[09:24:28] *** Flow shows as "online"
[09:29:33] *** Flow shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[09:31:06] *** Flow shows as "online"
[09:33:34] *** ralphm shows as "xa" and his status message is " (Not available as a result of being idle more than 15 min)"
[09:36:04] *** Flow shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[09:38:52] *** daniel has left the room
[09:39:03] *** daniel has joined the room
[09:46:06] *** Flow shows as "xa" and his status message is " (Not available as a result of being idle more than 15 min)"
[09:49:06] *** ralphm shows as "online"
[09:54:08] *** ralphm shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[09:58:52] *** Kev shows as "away"
[10:04:08] *** ralphm shows as "xa" and his status message is " (Not available as a result of being idle more than 15 min)"
[10:11:59] *** Kev shows as "online"
[10:15:30] *** Flow shows as "online"
[10:18:30] *** ralphm shows as "online"
[10:20:31] *** Flow shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[10:28:03] *** daniel has left the room
[10:29:39] *** Holger shows as "online" and his status message is "I'm available"
[10:29:39] *** Holger shows as "online" and his status message is "I'm available"
[10:30:01] *** Kev shows as "away"
[10:30:07] *** daniel has joined the room
[10:30:30] *** Flow shows as "xa" and his status message is " (Not available as a result of being idle more than 15 min)"
[10:35:37] *** daniel has left the room
[10:37:50] *** Kev shows as "online"
[10:39:15] *** daniel has joined the room
[10:46:05] *** daniel has left the room
[10:46:14] *** daniel has joined the room
[10:48:44] *** Kev shows as "away"
[10:55:47] *** daniel has left the room
[10:55:56] *** daniel has joined the room
[11:13:53] *** jere has joined the room
[11:14:20] *** Kev shows as "online"
[11:14:51] *** Holger shows as "away" and his status message is "Auto-away (idle)"
[11:16:08] *** jere has left the room
[11:16:16] *** jere has joined the room
[11:21:51] *** Tobias shows as "away"
[11:22:04] *** Tobias shows as "online"
[11:29:20] *** daniel has left the room
[11:29:28] *** daniel has joined the room
[11:31:52] *** daniel has left the room
[11:32:02] *** daniel has joined the room
[11:32:10] *** Tobias shows as "away"
[11:35:53] *** ralphm shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[11:42:54] *** daniel has left the room
[11:43:01] *** daniel has joined the room
[11:45:53] *** ralphm shows as "xa" and his status message is " (Not available as a result of being idle more than 15 min)"
[11:56:42] *** Tobias shows as "online"
[12:12:00] *** Kev shows as "away"
[12:14:18] *** Flow shows as "online"
[12:16:41] *** Tobias shows as "online"
[12:16:50] *** Tobias shows as "online"
[12:17:55] *** Tobias has left the room
[12:23:41] <Tobias> I won't be able to make it to todays council meeting. Would be great if someone else could chair the meeting this time.
[12:45:34] *** Flow shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[12:46:03] *** Flow shows as "online"
[12:49:55] *** ralphm shows as "online"
[12:52:21] *** jere has left the room
[12:52:30] *** jere has joined the room
[12:59:46] *** Kev shows as "online"
[13:13:29] *** ralphm shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[13:13:51] *** moparisthebest shows as "online"
[13:16:57] *** ralphm shows as "online"
[13:21:54] *** daniel shows as "online"
[13:22:53] *** Kev shows as "away"
[13:23:07] *** daniel has left the room
[13:23:28] *** Kev shows as "online"
[13:24:06] *** daniel shows as "online"
[14:13:57] <Tobias> or we postpone it to next week if there's nobody else to chair
[14:14:32] <SamWhited> I'll do it
[14:14:50] <SamWhited> Unless someone else wants too; but happy to so that we can have a meeting
[14:14:58] <Tobias> great, ta. Will read the logs tomorrow then.
[14:17:14] *** Kev shows as "away"
[14:27:00] *** Tobias shows as "away"
[14:27:33] *** Tobias shows as "online"
[14:28:38] *** Flow shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[14:29:51] *** Flow shows as "online"
[14:37:41] *** Holger shows as "online" and his status message is "I'm available"
[14:38:06] *** ralphm has left the room
[14:38:24] *** ralphm shows as "online"
[14:45:04] *** Zash shows as "online"
[14:46:28] *** jere has left the room
[14:46:42] *** jere has joined the room
[14:55:16] *** SamWhited shows as "online"
[14:58:03] *** Holger shows as "away" and his status message is "I'm away"
[14:58:07] *** Holger shows as "online" and his status message is "I'm available"
[15:00:27] *** Tobias shows as "online"
[15:06:19] *** daniel has left the room
[15:09:48] *** peter has joined the room
[15:12:46] *** Kev shows as "online"
[15:12:53] *** Tobias shows as "away"
[15:17:45] *** Zash shows as "online"
[15:19:35] *** Tobias shows as "online"
[15:20:20] *** Zash has left the room
[15:20:31] *** Zash shows as "online"
[15:30:15] *** narcode shows as "online"
[15:37:22] *** ralphm shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[15:40:04] *** Tobias shows as "away" and his status message is "Away"
[15:40:46] *** ralphm shows as "online"
[15:41:54] *** Flow has joined the room
[15:45:20] *** peter has left the room
[15:58:10] *** ralphm shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[16:00:20] <SamWhited> The time is come.
[16:00:35] <SamWhited> Who's here?
[16:00:49] <daniel> Me
[16:01:00] <Link Mauve> Me too.
[16:01:08] *** daniel shows as "online"
[16:01:45] <SamWhited> I see no Dave
[16:01:52] <SamWhited> But we can muddle through
[16:02:14] <SamWhited> 1. Minutes Taker?
[16:02:48] <daniel> since JC isn't here I can do it
[16:02:56] <SamWhited> perfect
[16:03:15] <SamWhited> 2. Entity Caps 2 ProtoXEP https://xmpp.org/extensions/inbox/ecaps2.html
[16:03:45] <SamWhited> Any discussion before we vote?
[16:03:45] <daniel> +1
[16:03:51] <SamWhited> I'll be on list
[16:04:18] <daniel> SamWhited, do you think there is something that should be discussed?
[16:04:30] <daniel> regarding just updating entity caps 1?
[16:04:33] <SamWhited> daniel: Not in particular; I still need to read it again, I only briefly scanned it
[16:04:35] <Link Mauve> daniel, whether we accept it as a new XEP or as an update to 0115, mostly.
[16:05:43] <SamWhited> Since 0115 is already in draft and this is radically different in some ways (I think?) I'm inclined to think this needs to be a new XEP personally.
[16:06:20] <SamWhited> But since it's only the three of us, maybe we should save that for list discussion along with the outstanding votes?
[16:07:11] <daniel> ok
[16:07:31] <Link Mauve> I am of the same opinion, other XEPs currently “depending” on 0115 should be updated to say something like “use 0030, or any caching mechanism like ecaps2.”
[16:07:32] <Kev> I maintain that I think a new XEP here is more trouble than it's worth :)
[16:07:53] <Kev> I don't think it's conceptually any different to 115, is it?
[16:08:10] *** ralphm shows as "xa" and his status message is " (Not available as a result of being idle more than 15 min)"
[16:08:13] <Link Mauve> It’s not.
[16:08:53] <SamWhited> Let's discuss on list since so many people aren't here. Link Mauve: will you create a thread for this in response to the minutes being sent out?
[16:09:00] <Link Mauve> Ok.
[16:09:03] <SamWhited> Thanks
[16:09:23] <SamWhited> 3. LC for XEP-0333
[16:09:32] <SamWhited> The LC has ended, but I think Daniel wants to submit changes before we vote?
[16:10:11] <daniel> SamWhited, just let it fall out of LC back to experimental again. i need more time than a week or so
[16:10:23] <SamWhited> Will do; moving to the editors column.
[16:10:29] <daniel> i guess we can formally vote -1 if necessary
[16:10:41] <Link Mauve> WFM.
[16:10:53] <SamWhited> If the author (or steward) says it's not ready that sounds like enough to me personally :)
[16:11:23] *** Holger shows as "online" and his status message is "Available"
[16:11:28] <SamWhited> 4. Vote on advancing XEP-0233 version 0.5.1 to Draft
[16:11:29] *** Holger has left the room
[16:11:46] <SamWhited> I'm +1
[16:12:08] <daniel> +1
[16:13:10] <Link Mauve> I’m +1 too.
[16:13:29] <SamWhited> Others to vote on list; excellent.
[16:13:52] <SamWhited> 5. Several PRs relating to CSI/Carbons state after SM resumption
[16:13:54] <SamWhited> https://trello.com/c/IR0c5nfq
[16:14:01] <SamWhited> I think the PRs listed on this card need our attention
[16:14:20] <SamWhited> I'm not sure that there's anything to do but mention that they exist
[16:14:40] <SamWhited> Only the 0198 one needs council, if I understand this correctly
[16:14:46] *** ralphm shows as "online"
[16:15:52] *** ralphm has left the room
[16:15:57] <daniel> i'm not sure that's a good idea
[16:16:12] <SamWhited> Which one? Maybe I should have broken this up
[16:16:13] <daniel> by adding that you are basically forcing the carbons ns bump
[16:16:22] <daniel> the one about 0198
[16:16:48] <daniel> by delegating the responsibilty to the individual XEPs you requrie namespace bumps on those xeps
[16:17:17] <SamWhited> I'm unsure if I think it helps or hurts, but I sort of think the 0198 change is unnecessary either way.
[16:18:06] <daniel> i'm not even sure where the idea that a carbon state or a csi state is undefined after a resumption comes from. is it really?
[16:18:23] <daniel> did this ever cause unexpected behaviour in real life?
[16:18:38] <daniel> or a dissagreement between server developers?
[16:18:38] <Link Mauve> This sounds more of a design problem of nonza than something that needs to be specified that way, actually.
[16:18:54] <SamWhited> I'm not sure if it's ever actually caused problems, but I do think it's undefined (and we should probably not leave behavior undefined)
[16:19:19] <Kev> I'm not entirely sure I understand why this is an issue at all.
[16:19:26] <Kev> Sure you're resuming everything in the same state it was in before?
[16:19:34] <Kev> The point of 198 resumption is to pick up where you left off.
[16:19:40] <Kev> *Surely
[16:19:46] <SamWhited> That was always my assumption
[16:19:49] <daniel> but you enable feature X (csi, carbons what ever) for a *stream*. and then you resume a s*stream*
[16:19:58] <daniel> why would that be gone after a resume?
[16:20:26] <Kev> Surely this is a one-line editorial fix in 198 to make this clearer, if it's possible to misread it if you squint hard?
[16:20:27] <daniel> so i don't agree with the notion that this is undefined behaviour
[16:20:59] <daniel> or what Kev that
[16:21:12] <SamWhited> I think I agree with Kev; do we want to vote on the 198 changes in their current form today (even if we're all on list) and then consider an alternative if necessary later?
[16:21:15] <daniel> but it should be up to the carbons or csi xeps
[16:21:52] <daniel> SamWhited, we are talking about #429 right?
[16:21:55] <daniel> just to be sure
[16:22:00] <SamWhited> Yes, sorry
[16:22:17] <Holger> The CSI state has to be reset because the CSI nonzas cannot be acknowledged.
[16:22:42] <daniel> *but it should NOT be up to the (in case that wasn't clear from the context)
[16:22:45] <Holger> So if a CSI nonza was sent before resumption, the client wouldn't know whether the server processed it.
[16:23:01] <SamWhited> ah right, that makes sense
[16:23:10] <Holger> This was the reasoning for resetting the CSI state on resumption.
[16:23:11] <Zash> Is the CSI state attached to the TCP-bound stream or the resource/long lived session?
[16:23:14] <daniel> Holger, but that's an orthogonal problem
[16:24:18] <moparisthebest> how can you *ever* be sure the server got the nonza and enabled CSI though? if you go down that rabbit hole do you just have to continually send it every minute or something?
[16:24:18] <SamWhited> That still sounds like a 1 line change to CSI saying "after resumption, update the state since we're not sure if it stuck"
[16:24:57] <Link Mauve> moparisthebest, the next stanza you send will be acked, and then you know the csi one got sent.
[16:25:08] <daniel> Zash, i think in general CSI applies to the stream. the fact that you can't be sure if the server got the active/inactive is a different problem
[16:25:18] <daniel> that will basically force you to resent it every time
[16:25:40] <moparisthebest> Link Mauve, so then only re-set it after stream resumption if you didn't get an ack for your next message?
[16:25:45] <SamWhited> I thihnk that makes #427 wrong, even though the behavior is correct. It explicitly says that the CSI state is *not* restored: https://github.com/xsf/xeps/pull/427/files
[16:25:57] <SamWhited> If there was a next message at all
[16:26:07] <Holger> moparisthebest: That's completely weirdo.
[16:26:13] <Holger> It must be reset.
[16:26:16] <daniel> SamWhited, yes i think it is wrong
[16:26:18] <daniel> imho
[16:26:21] <Holger> If you don't want that use stanzas instead.
[16:26:27] <moparisthebest> sounds like nonza's in general are completely wierdo Holger :)
[16:26:53] <SamWhited> So, action items thus far:
[16:27:12] <moparisthebest> kinda like using UDP when you want TCP guarantees... anyway
[16:27:13] <SamWhited> 1. Comment on the CSI PR (#427) and say we think it needs work (although it's actually between the author and whomever made the PR)
[16:27:16] <Holger> moparisthebest: They might be the wrong choice for CSI (some argue this way), yes. But as long as we stick to them the CSI state must be reset.
[16:27:29] <SamWhited> Daniel: Can you comment there and mention this, or maybe bring it up for discussion if there's disagreement?
[16:27:54] <daniel> SamWhited, on the #427 one?
[16:28:00] <SamWhited> daniel: yes
[16:28:03] <daniel> yes i can do that
[16:28:05] <Link Mauve> SamWhited, 2. review the CSI discussion for nonza vs. stanza, and potentially switch to stanza?
[16:28:38] <SamWhited> Link Mauve: Yah, that might be where that discussion goes, but for now we can get the quick fix of just tweaking that PR and merging it
[16:28:51] <Link Mauve> Yeah.
[16:29:01] <SamWhited> 2.1: Vote on #429 (even if we're all just on-list)
[16:29:59] <daniel> i'm fine with voting right now. i'm going -1 on that
[16:30:12] <SamWhited> I'm also -1
[16:30:25] <Link Mauve> -1 too.
[16:31:09] <SamWhited> cool, that only leaves #428 from that discussion. Do we actually want (or need) to discuss it?
[16:31:44] <daniel> i think we already did discuss this?
[16:31:51] <SamWhited> Did we? Oops, in that case, we can probably move on.
[16:32:25] <Link Mauve> 428 is basically “this is a stanza, no problem here”.
[16:32:52] <SamWhited> 5 (I think). Add <x/> tag to MUC-PMs: https://github.com/xsf/xeps/pull/436
[16:33:58] <SamWhited> I do not fully understand this yet, but it appears to bump the carbons version in expectation of that carbons PR being merged
[16:34:03] <Link Mauve> Didn’t we already vote on that last week?
[16:34:04] <daniel> i honestly have no hard feelings either way. I've personally given up on MUC
[16:34:20] <SamWhited> Link Mauve: Did we? I really can't keep track of this stuff, it was just listed in the Trello…
[16:34:31] <Link Mauve> Let me check.
[16:34:51] <SamWhited> oh no, I'm sorry, this does not change the carbons namespace, ignore me.
[16:35:03] <SamWhited> I wasn't even looking at the right PR.
[16:35:14] <Link Mauve> SamWhited, section 2) of the previous minutes.
[16:35:32] <daniel> the thing is that #436 removes one side effect and introduces another
[16:35:43] <daniel> (arguably minor one?)
[16:35:59] <daniel> i actually don't think MUC can be fixed
[16:36:11] <SamWhited> cool, so it's apparently still just missing a few votes. I'll vote on list, apologies for the confusion.
[16:36:29] <SamWhited> Does anyone else want to vote (looks like we didn't vote, just said we'd vote next week)
[16:36:46] <SamWhited> Except for Link Mauve, he's ahead of the game :)
[16:37:04] <Link Mauve> (I just fixed that on trello.)
[16:37:22] <SamWhited> Perfect; official vote. I'm on list. daniel?
[16:37:56] <daniel> i don't know. i'm really torn. i think i should maybe block this... i'll vote on list
[16:38:05] <SamWhited> Alrighty
[16:38:11] *** Zash has left the room
[16:38:20] <SamWhited> This was put on the agenda, but I'm not sure why: https://mail.jabber.org/pipermail/standards/2017-February/032328.html
[16:38:28] *** Zash has joined the room
[16:38:28] <SamWhited> Since we just voted on ecaps2, I guess moving on?
[16:38:30] *** Zash shows as "online"
[16:39:01] <SamWhited> Or maybe we are supposed to come up with a migration plan for SHA-1 in general (although it's worth noting that it doesn't really affect anything yet, or XMPP possibly at all)
[16:39:35] <SamWhited> (that's 6. I guess)
[16:39:53] <SamWhited> Let's call it mentioned and move on unless anyone objects
[16:40:49] <SamWhited> I'm hearing crickets.
[16:40:56] <SamWhited> 7. IEEE IoT email
[16:40:56] <daniel> no objections
[16:41:09] <Link Mauve> I have on my TODO list to start reviewing every usage of SHA-1 we have, but haven’t done anything yet.
[16:41:22] <Link Mauve> (Sorry, re 6.)
[16:41:32] <SamWhited> Link Mauve: Perfect, let's call that an action item for you then: SHA-1 review and migration plan. Thanks!
[16:41:35] <Zash> Link Mauve: Like https://xmpp.org/extensions/xep-0300.html#existing ?
[16:41:39] <Link Mauve> SamWhited, what is this email about?
[16:42:01] <Link Mauve> Zash, right.
[16:42:28] <SamWhited> RE 7: A motly crew of random people got CCed on an email from the IEEE IoT working group (or something) asking us to fast track the IoT XEPs which are currently deferred. Arc apparently had coffee with the person who sent the email, and it was decided that we should probably interact with their WG
[16:42:38] <SamWhited> since they're using XMPP for all IoT things, but don't actually have any XSF members
[16:42:42] *** Kev shows as "away"
[16:42:49] <SamWhited> Dave suggested we assign a council liason to the IEEE
[16:43:17] <Link Mauve> Wasn’t that the purpose of the IoT SIG already?
[16:43:17] *** ralphm shows as "online"
[16:43:19] <SamWhited> and the board requested that we work with Rikard and the IoT SIG to come up with a strategy for the current IoT work
[16:43:31] <SamWhited> yes, I think the idea was just to get council involved.
[16:43:55] <SamWhited> I think since no one's here, we should just send out an email about this and discuss on list, unless anyone wants to suggest a specific plan or volunteer to work with the IoT SIG?
[16:44:16] <SamWhited> Either way I'm happy to write that email
[16:44:57] <SamWhited> Any volunteers?
[16:45:15] <SamWhited> (I'm happy to write the email, I am not volunteering to be the IoT liason)
[16:45:53] <Link Mauve> Didn’t we already elect stpeter as the representative of the council to the SIG?
[16:46:42] <SamWhited> I think we did, but since then Peter has gotten busy and not really involved right now, I don't think we can actually burden him with more work (and he's not on the council)
[16:47:18] <SamWhited> I'll send out an email to council@ and we can discuss specific plans (or we can discuss again next time we're all here). I'm not 100% sure what Dave et al. had in mind, so we can wait for their feedback before addressing this.
[16:47:44] <SamWhited> 8 (maybe). Date of Next
[16:48:01] <Link Mauve> I won’t be here at all next week, fyi.
[16:48:20] <SamWhited> Same time next week?
[16:48:38] <daniel> wfm
[16:48:43] <SamWhited> 2017-03-15 1600Z it is
[16:48:48] <SamWhited> 9. AOB
[16:48:59] <SamWhited> I have some, but it's brief and can be last
[16:49:09] <daniel> i don't have any
[16:49:14] <Link Mauve> Me neither.
[16:49:18] <SamWhited> Cool, mine is just pending vote reminders:
[16:49:41] <SamWhited> XEP-0368 to draft: Link Mauve, SASL2: Link Mauve, IBR2: Link Mauve, Daniel. Please vote; thanks!
[16:50:00] <SamWhited> *gavel*
[16:50:06] <Link Mauve> Thank you.
[16:50:08] <SamWhited> Thanks everybody
[16:50:13] <daniel> thank you
[16:50:39] <moparisthebest> I think XEP-0368 to draft times out to day anyway
[16:50:49] <moparisthebest> I think XEP-0368 to draft times out today anyway
[16:51:03] <SamWhited> yah, I thihnk you're right
[16:51:30] <SamWhited> Link Mauve: You have until EOB central time when I'm going to put my editor hat on and call it :)
[16:51:33] <moparisthebest> or times in, but that sounds odd
[16:52:09] <Link Mauve> Alright, I’ll take a few more minutes off work to handle that then!
[16:53:54] <moparisthebest> now that meeting is over, so Holger what I'm asking is with a nonza how can I be sure the server *ever* got it, even not counting stream resumption now?
[16:53:56] *** Kev shows as "online"
[16:55:14] <Holger> moparisthebest: You have this guarantee (as Link Mauve or someone mentioned): https://xmpp.org/extensions/xep-0352.html#in-order-processing
[16:56:07] <Holger> moparisthebest: You no longer have that if the stream is resumed after sending a CSI element and before a following stanza was acknowledged by the server.
[16:56:08] <moparisthebest> so then as horrible as it sounds, why not mark csi as 'acked' in the client when you recieve the next 'ack' for your next stanza?
[16:56:16] <SamWhited> Link Mauve: Thanks! Don't forget the 0115/ecaps2 email too (not that that has to happen right away). Also reminder to me: I'm going to go draft one about the IEEE IoT stuff.
[16:56:16] <moparisthebest> right
[16:56:45] <Holger> moparisthebest: The server would have to know whether the client has marked this as 'acked' in order to decide whether to reset the CSI state :-)
[16:56:51] <Link Mauve> SamWhited, ok.
[16:57:45] <moparisthebest> but yea in general, nonzas sound like they are useful for here is this but I don't care whether you get it or not, and not in any way appropriate for modifying state on either side, or keeping state in sync
[16:58:22] <Holger> moparisthebest: Just reset it or use stanzas. I agree that resetting the state doesn't feel elegant, but I think that's a purely academic issue, I don't see the problem in practice. If protocol elegance is what you're after, you should not be doing XMPP :-)
[16:59:00] <moparisthebest> so what your saying is we should all re-invent the wheel with our own json over http protocols?
[16:59:11] <moparisthebest> so what you're saying is we should all re-invent the wheel with our own json over http protocols?
[16:59:44] <Holger> If you want elegance, yes. I find compatibility way more important, which is why I'm doing XMPP rather than Matrix.
[16:59:54] <moparisthebest> what is the history for using a nonza there in the first place?
[17:00:07] <moparisthebest> I feel like I'm missing some context
[17:00:26] <SamWhited> I think it just makes sense; it's a thing you only ever need to send to the server, so it doesn't need to be routable, and it's not mission critical, so fire-and-forget is fine.
[17:00:44] <SamWhited> It matches the nonza use case perfectly, I think.
[17:00:58] <moparisthebest> it modifies state though? and is mission critical if your mission is please don't murder my phone battery
[17:01:18] <Holger> moparisthebest: Find a room where both Ge0rg and Flow are joined, prepare yourself with some popcorn, mention the topic, and you'll have the context.
[17:02:02] <Zash> Holger: What have you done!
[17:02:25] <moparisthebest> I'll wait for flow to join prosody and have at it haha
[17:04:59] <Kev> SamWhited: Actually, I think it's telling the server to do something on your behalf, so an iq to your bare JID (no to=) is probably pretty sensible too.
[17:05:44] <Kev> Stanzas are the building blocks of XMPP. Investing new top level elements is possible, of course, but there are implications (see the current discussion on interactions with 198).
[17:05:57] <SamWhited> Kev: Yah, that makes sense too, I just don't see the need for an ack, and I like it when things aren't routable.
[17:06:00] <Kev> I don't know what my opinion was in the past, but right now I think my opinion is largely that this should have been an iq.
[17:07:18] <Holger> I agree, but I'm not sure switching to stanzas now is worth the trouble.
[17:07:51] <Kev> I think 'not routable' isn't really much of an argument. If it's an iq to your bare JID, your server already understands how to deal with it. If it's a new element type, that means new code paths (probably, maybe, potentially, depending on server design).
[17:10:57] <SamWhited> If it is routable, but not intended for anyone else but the server, that's a chance for an XMPP library to break in unexpected ways
[17:11:21] <SamWhited> (to break in unexpected ways when I try to send them a CSI IQ even though technically they shouldn't ever get one as a client, for instance)
[17:11:35] <SamWhited> I generally just like keeping the scope of things as limited as possible
[17:11:44] <SamWhited> But I agree, it's not likely to be an issue in this case
[17:12:05] <Holger> CSI elements don't need to be routed but I do see need for an ACK, so we don't have a perfect fit for this.
[17:12:32] <Kev> SamWhited: I don't buy that, really. Receiving stuff you don't expect is kinda a core part of extensibility.
[17:13:58] <SamWhited> Yah, but that doesn't mean we can't limit that possibility on the server as much as possible if it doesn't cause any other problems
[17:14:08] <SamWhited> Which I think it doesn't in this case, but obviously others disagree
[17:14:27] *** Holger shows as "online"
[17:15:31] *** Holger shows as "away" and his status message is "I'm away"
[17:15:42] <moparisthebest> good call Holger , that's a perfect fit for a nostanza
[17:15:52] <moparisthebest> which doesn't get routed, but does get ACKd
[17:17:13] <Holger> Given limited manpower, I think we should try to distinguish between real problems and cosmetic issues and concentrate on the former as long as we have those :-)
[17:17:17] <moparisthebest> nonstanza maybe, I'm not married to the name, everyone wants a new top level element right? :P
[17:18:19] <moparisthebest> but yea about the issue at hand it seems fairly clear CSI needs to be a stanza, or re-sent on session resumption if something didn't get acked after it was sent before, or something, yuck
[17:18:37] <moparisthebest> or you just re-send it on every session resumption and call it a day
[17:24:03] *** Kev shows as "away"
[17:27:20] *** Kev shows as "online"
[17:28:16] <Kev> FWIW, I don't think there'd be significant pain in migrating to iqs instead of non-stanza elements.
[17:31:28] <Holger> I'd rather avoid spamming the code of implementations with both solutions for no good reason.
[17:32:00] *** Lance has joined the room
[17:32:01] *** Lance shows as "online"
[17:34:00] <Kev> I think that's fair.
[17:34:23] <Kev> It's Experimental though, right? :)
[17:36:29] <Holger> I'm in the Council room so I was expecting this response :-)
[17:36:34] <SamWhited> Yah, but it's one of those experimental XEPs that we left until everyone was using it; at that point it's practically defacto draft and we should be careful with changes, I think (I'm not saying we should treat it exactly like draft, but we should be careful not to leave stuff in experimental this long until it's so widely used)
[17:41:15] <Holger> Yes looking at such issues from a practical perspective rather than blindly applying formal rules sounds like a great idea to me :-)
[17:42:12] *Holger goes AFK and therefore stops trolling, have a nice evening everyone.
[17:46:16] *** Holger has left the room
[17:46:24] *** Holger shows as "online"
[17:48:43] <Kev> I think a line saying "Look, this should have been a stanza (take note future authors), but it's not, so we need to reset it on a new stream just in case" is probably not daft.
[17:49:39] <SamWhited> Yah, I don't think that would be a problem
[17:50:16] <SamWhited> Although I also disagree that it should have been a stanza; but mentioning that you may need to send it again on stream restart seems fine.
[17:53:59] <Kev> I think that this discussion shows that in practical terms pretty much everything needs to be a stanza, so that 198 works.
[17:55:02] <SamWhited> 198 does work; if the server got the CSI thing, then the stream state will remain the same and no reset is necessary. If it didn't, then it's exactly the same as if it didn't get it and the stream wasn't resumed: the state just never got changed (which I think is fine in this case)
[17:55:51] <daniel> SamWhited, +1
[17:56:12] <Kev> Yes, it works in the sense of it will not be broken.
[17:56:39] <Kev> But in terms of you needing to resend it after a restart because you don't know whether it was received isn't exactly 'working'.
[17:57:55] *** jere has left the room
[17:58:03] *** jere has joined the room
[17:58:22] <SamWhited> I just don't think that's a problem; however, if it is, the fix is easy: just always send it after a restart. I don't think it's necessary, but I also don't think it's a problem. It's an easy fix.
[17:58:32] <Kev> Changing to something much less bikesheddish:
[17:58:36] <Kev> https://github.com/xsf/xeps/pull/436/commits/cde2abe151ac8ecaacf46ad5d0cc43caae5b9a62
[17:58:41] <Kev> Surely we can't merge that?
[17:59:10] <Kev> It renders existing implementations non-compliant, and poses a potential interop problem.
[17:59:34] <daniel> you said *less* bikesheddish?
[17:59:44] <SamWhited> It is a SHOULD, not a MUST (but I'm leaning that way too)
[17:59:44] <Kev> Yes, this is a real issue, rather than cosmetic.
[18:00:01] <Kev> SamWhited: A SHOULD means you can rely on it, pretty much, because anyone not doing it made a deliberate decision.
[18:00:17] <SamWhited> Kev: What I heard there is "you can't rely on it" :)
[18:00:28] <Kev> SamWhited: Then it should be MAY.
[18:00:29] <daniel> we could just bump the muc namespace :-)
[18:00:31] <Kev> SHOULD means you can rely on it.
[18:00:51] <Kev> At the least it needs text saying that while a service/client SHOULD attach it, receiving entities can't assume that it'll be present, because $REASONS.
[18:01:12] <Kev> If we really do want to make it either SHOULD or MUST without further explanation, then yes, you're needing a namespace bump.
[18:01:32] <Kev> I suggest a namespace bump would be ludicrously stupid, and instead we need wording that doesn't introduce interop concerns.
[18:01:46] <SamWhited> yah, I agree; if it requires a namespace bump I'm absolutely -1
[18:02:25] <SamWhited> But I'm also fairly convinced that we should take MUC out behind the chemical shed and shoot it (and by that I meant that MUC is always going to be a bad experience, and there is nothing we can do about it, so we shouldn't bother)
[18:02:50] <SamWhited> But we definitely shouldn't make it *worse* (which a namespace bump would do)
[18:03:05] <Kev> I think that an additional sentence saying something approximately "Note that this requirement was added late in MUC's life, when implementations were already stable, and thus clients MUST NOT rely on receiving this element".
[18:03:19] <Kev> would probably be sufficient to get this text in there, while not breaking anything.
[18:03:21] <SamWhited> yah, that seems sane
[18:03:28] <daniel> i think everyone (including the author of the PR) will probably be fine with MAY
[18:03:34] <SamWhited> or that
[18:03:55] <Kev> MAY would not introduce an interop concern, so I'm far less opposed to it.
[18:04:04] <Kev> But I think better would be to make it clear that it's a good idea to do it.
[18:04:21] <daniel> can someone create a comment on the PR basically pasting the last couple of lines
[18:04:53] <daniel> because i really agree with SamWhited that MUC needs to die already and we shouldn't spend hours discussing these things
[18:05:09] <SamWhited> (I can't copy/paste easily from mcabber or I would)
[18:05:17] <daniel> :-)
[18:05:21] <Kev> I suggest someone Council does it, but I'll do it if not.
[18:05:22] <daniel> ok i'll do it
[18:05:26] <Kev> Thanks.
[18:05:49] <Kev> I think my suggested text is the best option, but I'm far fewer Fs about that than about not merging the PR as-is.
[18:14:44] *** daniel has left the room
[18:14:52] *** daniel shows as "online"
[18:19:25] *** daniel has left the room
[18:19:35] *** daniel shows as "online"
[18:20:04] *** Holger has left the room
[18:20:13] *** Holger shows as "online"
[18:20:25] *** daniel has left the room
[18:20:34] *** daniel shows as "online"
[18:24:10] *** Kev has left the room
[18:30:46] *** daniel has left the room
[18:30:54] *** daniel shows as "online"
[18:46:17] *** Lance has left the room
[18:47:06] *** daniel has left the room
[18:47:14] *** daniel shows as "online"
[18:47:31] *** narcode shows as "away"
[18:48:32] *** Lance has joined the room
[18:48:33] *** Lance shows as "online"
[18:48:53] *** daniel has left the room
[18:49:04] *** daniel shows as "online"
[18:51:47] *** daniel has left the room
[18:51:57] *** daniel shows as "online"
[18:53:21] *** daniel has left the room
[18:53:32] *** daniel shows as "online"
[18:58:36] *** Tobias has left the room
[18:58:39] *** Tobias shows as "away" and his status message is "Away"
[18:58:40] *** Tobias shows as "away" and his status message is "Away"
[19:31:08] *** daniel has left the room
[19:31:18] *** daniel shows as "online"
[19:33:35] *** daniel shows as "online"
[19:34:45] *** daniel has left the room
[19:48:24] *** daniel has left the room
[19:48:35] *** daniel shows as "online"
[19:59:14] *** daniel has left the room
[19:59:23] *** daniel shows as "online"
[20:12:13] *** daniel has left the room
[20:12:45] *** daniel shows as "online"
[20:13:37] *** daniel has left the room
[20:13:59] *** daniel shows as "online"
[20:17:23] *** Lance has left the room
[20:20:44] *** daniel has left the room
[20:21:35] *** daniel shows as "online"
[20:23:25] *** daniel has left the room
[20:23:35] *** daniel shows as "online"
[20:24:25] *** daniel has left the room
[20:24:48] *** daniel shows as "online"
[20:26:44] *** daniel has left the room
[20:26:56] *** daniel shows as "online"
[20:27:30] *** daniel has left the room
[20:28:47] *** daniel shows as "online"
[20:38:32] *** daniel has left the room
[20:38:39] *** daniel shows as "online"
[20:49:18] *** Lance has joined the room
[20:49:20] *** Lance shows as "online"
[20:51:46] *** daniel has left the room
[20:51:58] *** daniel shows as "online"
[21:04:50] *** daniel has left the room
[21:04:53] *** daniel shows as "online"
[21:08:34] *** daniel has left the room
[21:08:43] *** daniel shows as "online"
[21:15:48] *** Zash shows as "online"
[21:22:12] *** Holger shows as "online" and his status message is "I'm available"
[21:40:39] *** Tobias has left the room
[21:40:46] *** Tobias shows as "online"
[22:06:01] *** moparisthebest has left the room
[22:06:22] *** moparisthebest has joined the room
[22:16:59] *** Zash shows as "away"
[22:27:09] *** Zash shows as "online"
[23:15:01] *** moparisthebest has joined the room
[23:29:46] *** Zash shows as "away"
[23:30:50] *** Zash shows as "online"
[23:41:03] *** SamWhited has left the room
[23:44:27] *** daniel has left the room
[23:48:06] *** Holger shows as "away" and his status message is "Auto-away (idle)"
[23:52:35] *** Tobias shows as "online"
[23:52:37] *** Tobias shows as "online"