FYI
---------- Forwarded message ---------- From: Peter Saint-Andre <[email protected]> Date: Mon, Feb 15, 2010 at 8:06 PM Subject: [Council] chat log from 2010-02-15 meeting To: XMPP Council <[email protected]> *** 1969-12-31 [17:00:00] *** The topic has been set to: XMPP Council | Next meeting 2010-01-25 @ 19:00 UTC | Calendar: http://xmpp.org/calendar/xsf-council.ics | Previous agenda: http://mail.jabber.org/pipermail/council/2009-December/002705.html *** 2010-02-15 [11:45:49] <stpeter> Kev: have we settled on this room until logging is enabled at muc.xmpp.org? [11:47:10] <Kev> I think so - although we need to re-enable logging on jabber.org, too. [11:47:20] <stpeter> indeed [11:50:36] <stpeter> brb, heating up some lunch [11:51:06] *** [email protected] ([email protected]/McBukF33C0959) has joined the room as a participant [11:52:05] *** fritzy ([email protected]/work/laptop) has joined the room as a participant [11:52:18] *** ralphm ([email protected]/mcabber) has joined the room as a moderator and an administrator [11:52:32] <ralphm> hi [11:52:52] <fritzy> ahoy ralph [11:53:03] *** [email protected] is now known as zool [11:53:04] *** zool is now known as [email protected] [11:53:04] *** [email protected] is now known as zool [11:53:15] *** MattJ ([email protected]/Gajim) has joined the room as a moderator and an administrator [11:53:30] *** bear ([email protected]/mbp) has joined the room as a participant [11:53:58] <bear> did the MUC room just give me a date/time of 1969-12-31 ?? [11:54:46] <Kev> No. [11:54:51] <MattJ> I think it probably gave you 1970 in UTC [11:54:54] <Kev> It gave you a date/time of 1970-01-01 :) [11:55:07] <bear> *** 1969-12-31 [19:00:00] *** The topic has been set to: XMPP Council | Next meeting 2010-01-25 @ 19:00 UTC | Calendar: http://xmpp.org/calendar/xsf-council.ics | Previous agenda: http://mail.jabber.org/pipermail/council/2009-December/002705.html *** 2010-02-15 [13:53:58] <bear> did the MUC room just give me a date/time of 1969-12-31 ?? [11:55:52] *bear goes back to lurking [11:56:01] *** zool is now known as [email protected] [11:56:02] *** [email protected] is now known as zool [11:56:15] *** darkrain ([email protected]/λ) has joined the room as a participant [11:56:15] <stpeter> yeah, what is it with that datetime? [11:56:29] <Kev> I think, although I don't know, that it's caused when the topic was set before the last server restart. [11:56:36] <stpeter> ah [11:56:43] <stpeter> that makes a twisted kind of sense :) [11:56:43] *** deryni ([email protected]/work) has joined the room as a participant [11:57:02] <MattJ> In which case it should probably not send a delay at all [11:57:10] <MattJ> !uptime xmpp.org [11:57:13] <HAL> xmpp.org has been running for 82 days, 15 hours and 6 minutes [11:57:17] <stpeter> nice :) [11:57:21] <MattJ> Sad, but what's going on there at the moment? [11:57:26] <MattJ> I think a restart should get logging working [11:57:31] <stpeter> MattJ: super [11:57:41] <bear> is xmpp.org == jabber.org now? [11:57:44] <MattJ> Oh, except you wanted the port changed [11:57:50] <stpeter> MattJ: and we need to lean on some people to write some bots [11:57:52] <MattJ> bear, no, separate machine, running Prosody [11:58:10] <stpeter> MattJ: we might as well -- although I like the high ports, they force people to implement SRV support ;-) [11:58:14] <MattJ> :) [11:58:42] <stpeter> I mean, c'mon folks, we defined that stuff back in 2003! [11:58:54] <MattJ> Tell me about it [11:59:05] <bear> come march 1st my whole concept of freetime becomes more normal and I get to do non-work things again [11:59:28] <MattJ> Yay [11:59:47] <bear> and I get to try and influence the Weave team with their xmpp stuff :) [12:00:20] <stpeter> :) [12:00:22] <MattJ> My Thunderbird is mad [12:00:33] <Kev> I'm not convinced there's a compelling reason to switch xmpp.org to 5269 [12:00:41] <stpeter> Kev: I'm not, either [12:00:45] <bear> stpeter - has anyone from facebook contacted you about their xmpp setup? I tried to make contact with the folks I know but they are buried deep and I don't think they have time to respond [12:00:47] <Tobias> but still I think 90% of the java XMPP libs don't support SRV records :) [12:00:48] <MattJ> Kev, apart from that Tigase users can't join rooms there? [12:01:02] *** zool is now known as [email protected] [12:01:02] *** [email protected] is now known as zool [12:01:06] <Kev> MattJ: Artur'll fix that imminently though, presumably. [12:01:17] <MattJ> It may already be done [12:01:43] <Tobias> SRV record lookup isn't native in java, right? you need additional libs for that, right? [12:01:55] <Kev> Ok, so, Remko may or may not be here because of power problems across town. [12:02:01] <Kev> I don't know about Dave. [12:02:20] <stpeter> Remko seems to be online [12:02:42] <Kev> Yeah, but he just sent me a message to say he may vanish, due to the power problems. [12:02:48] <stpeter> ah [12:02:49] <stpeter> ok [12:02:54] <Kev> We'll give them both a few minutes anyway. [12:02:59] <stpeter> ok [12:03:08] <Kev> Another 2, in any case. [12:03:10] *** jprieur ([email protected]/Gajim) has joined the room as a participant [12:03:30] <stpeter> hi jprieur [12:03:42] <jprieur> hi stpeter and others :) [12:04:05] <Kev> Hi. [12:04:18] <MattJ> Hi jprieur [12:05:09] *** Ali Sabil ([email protected]/Gajim5A495FBB) has joined the room as a participant [12:05:17] <stpeter> Kev: I wonder if we could build the agendas into http://wiki.xmpp.org/web/Radar or dispense with agendas entirely.... [12:05:17] *** Ali Sabil ([email protected]/Gajim5A495FBB) has left the room [12:05:25] <Kev> stpeter: Iono. [12:05:27] *** remko ([email protected]/Swift) has joined the room as a moderator and an administrator [12:05:33] <Kev> The agendas at least remind people to turn up :) [12:05:36] <Kev> Hey remko [12:05:37] <stpeter> true [12:05:39] <Kev> So, let's start. [12:05:48] <stpeter> the more reminders, the better, with this crew ;-) [12:05:58] <Kev> 1) Roll call. [12:06:02] *** zool is now known as [email protected] [12:06:02] *** [email protected] is now known as zool [12:06:06] <Kev> Kev, Matt, Ralph, Remko. [12:06:08] <remko> note that i am both power and internet challenged [12:06:20] <stpeter> noted :) [12:06:25] <ralphm> hehe [12:06:27] *** jkhii ([email protected]/lubit-T078118) has joined the room as a participant [12:06:28] <Kev> 2) Pubsub. Votes needed from Dave, Matt, Ralph and Remko. [12:06:44] <stpeter> in Brussels, Ralph mentioned that he might have some concerns [12:06:52] <remko> asking for one last postponition on my vote [12:06:54] <stpeter> e.g., about IQ notifications [12:07:08] <remko> same goes for the next one [12:07:14] <Kev> I have no idea why people want these IQ notifications, and I'm certain they're an abomination, but... [12:07:44] <ralphm> I have concerns [12:07:58] <MattJ> I'm not sure either, but what's the concern? [12:08:04] <stpeter> Kev: perhaps an "IQ Notifications: Pro and Con" thread on the [email protected] list? [12:08:09] <ralphm> IQ notifications don't appear to solve real things [12:08:13] <stpeter> or "IQ Notifications Considered Harmful" [12:08:37] *** Ali Sabil ([email protected]/Gajim5A495FBB) has joined the room as a participant [12:08:45] <ralphm> as in, you still have no guaranteed deleviry [12:08:45] *** Ali Sabil ([email protected]/Gajim5A495FBB) has left the room [12:08:57] <ralphm> delivery even [12:09:02] <Kev> Right. [12:09:03] <stpeter> I'd almost rather have IQ notifications than message notifications + message receipts [12:09:08] <stpeter> there are no guarantees [12:09:23] <Kev> Well, ... 198 :) [12:09:27] <stpeter> I mean, message receipts are basically IQs but uglier :) [12:09:28] <MattJ> 198, 198, 198... [12:09:40] <Kev> certainly message receipts we don't want for this, but 198 solves the issue. [12:09:43] <ralphm> you'd need 2 phase commit [12:09:46] <stpeter> sure, 198 will solve many things, we hope [12:09:56] <Kev> Well, servers support that now, right? [12:09:56] <MattJ> But 198 won't solve it soon [12:10:01] <stpeter> correct [12:10:13] <Kev> MattJ: right, but we're talking about closed deployments anyway, if people are doing iq-based stuff, I suspect. [12:10:21] <Kev> So in those scenarios, 198 /can/ solve it soon. [12:10:22] <stpeter> Kev: I think so, yes [12:10:24] <MattJ> People are still going to want to publish to users on archaic servers [12:10:42] <ralphm> I hate to put this in XEP 0060 this late in the game if it not a solution or a bad one [12:10:56] <Kev> ralphm: are you -1ing? [12:10:57] <ralphm> it is crap for interop [12:11:03] *** zool is now known as [email protected] [12:11:03] *** [email protected] is now known as zool [12:11:08] <ralphm> yeah [12:11:16] <Kev> Ok. You can start the thread then :) [12:11:24] <stpeter> yes let's have a thread about it [12:11:25] <Kev> Other people can continue to vote on-list. [12:11:28] <bear> xep 0060 interop is already a pain - adding more deviation smells [12:11:29] <stpeter> Remko is running out of power :) [12:11:35] <ralphm> also, the delete node plus redirect is incomplete [12:11:46] <remko> too bad i don't have a lever like i have on my flashlight [12:11:51] <Kev> So, 163... [12:12:09] <Kev> It's not clear to me what the repercussions of no longer subscribing to the namespace is. [12:12:13] <Kev> s/is/are/ [12:12:26] <stpeter> ralphm: let me know if you need to check-in privileges to fix up the delete plus redirect stuff [12:12:39] <ralphm> afaics there is no support in delete notifications and I implemented it using XMPP URIs instead of jid/node [12:12:42] <Kev> Which isn't to say I'll block this, I'm just not sure we're not being premature about the node/namespace bit. [12:12:55] <ralphm> not sure which is better [12:13:19] <stpeter> Kev: we has consensus that everyone (well, maybe except Ralph) had implemented it one way [12:13:33] <ralphm> actually, you don't subscribe to namespaces at all [12:13:37] *** Ali Sabil ([email protected]/Gajim5A495FBB) has joined the room as a participant [12:13:45] <Kev> ralphm: well, you do atm, because namespace = node. [12:13:45] *** Ali Sabil ([email protected]/Gajim5A495FBB) has left the room [12:13:46] <ralphm> you are autosubd to the root node [12:13:57] <ralphm> and then filtering takes place [12:14:01] <ralphm> based on caps [12:14:09] <ralphm> in either scenario [12:14:13] *** tofu ([email protected]/Wickfield) has joined the room as a participant [12:14:24] <Kev> Yes. But changing this means your caps are no longer feature namespaces, but nodes. [12:14:38] <Kev> Which smells wrong to me. [12:15:02] <ralphm> yeah [12:15:21] <stpeter> I'm surprised that we're re-hashing this [12:15:29] <Kev> I probably have a very short memory. [12:15:53] <Kev> Or, this hasn't occurred to me before [12:15:59] <stpeter> it's been over a year since we had consensus on this (or so I thought), I was just slow about updating the specs [12:16:03] *** zool is now known as [email protected] [12:16:03] *** [email protected] is now known as zool [12:16:08] <stpeter> (which is a topic for another day) [12:16:29] <MattJ> The consensus is good enough for me :) [12:16:45] <ralphm> afaik we need both 'subscribe on payload namespace' which is what +notify does [12:16:52] <ralphm> and the other thing [12:17:26] <Kev> Well, the thing is...these things are going in your disco, so are therefore 'protocol namespace or other feature offered by the entity' [12:17:30] <ralphm> where you 'subscribe' on particular classes of nodes [12:17:37] <ralphm> like 'blogs? [12:17:41] <ralphm> 'blogs' [12:17:44] <Kev> Is a pubsub node a reasonable thing to have in your disco info? [12:18:09] <ralphm> it would not be a node [12:18:09] <stpeter> hmm [12:18:12] <Kev> ralphm: it would. [12:18:15] <ralphm> no [12:18:16] <Kev> ralphm: so says XEP-0060 [12:18:24] <Kev> You put #notify on the end of the node name. [12:18:32] <ralphm> if that's what it says now, that's not what we meant [12:18:38] *** Ali Sabil ([email protected]/Gajim5A495FBB) has joined the room as a participant [12:18:47] <MattJ> Hmm [12:18:47] *** Ali Sabil ([email protected]/Gajim5A495FBB) has left the room [12:18:54] <Kev> "In order to make this possible, all possible NodeIDs can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the specified NodeID. " [12:19:19] <stpeter> we decided to go down this path (which is what everyone does now) because there *might* be a one-to-one correspondence between a namespace and a node (that's what is true now for all the PEP stuff), but there *might* not be (e.g., a lot of different kinds of nodes might use Atom as the base format) [12:19:20] <Kev> I thought that was supposed to be a namespace, not a node. [12:19:20] <ralphm> the fact that the node id is identical to the payload namespace is coincidental [12:20:02] <Kev> stpeter: That need is compelling. [12:20:08] <ralphm> it seems this text tries to capture reality [12:20:08] <Kev> ralphm: s/coincidental/by design/ [12:20:14] <stpeter> well [12:20:30] <ralphm> Kev: read earlier versions [12:20:56] <Kev> Ok, so, it looks like we'll be having pubsub nodes inside disco#info. [12:21:02] <Kev> That's probably not the end of the world. [12:21:04] *** zool is now known as [email protected] [12:21:04] *** [email protected] is now known as zool [12:21:20] *** l-fy ([email protected]/c4508ff5048c1e1de830814b02324e2e) has joined the room as a participant [12:21:21] <MattJ> I gave up on caps already :) [12:21:23] <stpeter> we might need to revisit this on the list, but given that everyone (except perhaps idavoll) already implements +notify in the way now described by the modified specs, IMHO if we want payload matching then we'll need +somethingelse [12:21:46] <Kev> stpeter: Yeah. [12:21:50] <ralphm> Sure [12:21:52] <MattJ> I think we're debating semantics here [12:21:53] <l-fy> morning counsil [12:21:55] <Kev> Ok, so, I'm +1 on this. [12:21:56] <stpeter> like, send me Atom-everything, I don't care about the semantics I just love the Atom format [12:22:01] <MattJ> The end result is always the same [12:22:14] *** tofu ([email protected]/Wickfield) has left the room [12:22:15] <stpeter> I'm an Atom fanboy, just send me the Atom love! [12:22:21] <stpeter> hi l-fy [12:22:25] *MattJ sends stpeter some Atom love [12:22:42] <Kev> zool: you can't change your nick in a muc if you're a gtalk user. Can you log out and back in, and not change nicks once you've joined please - else you'll spam nick changes every 5 minutes from now until evermore :) [12:22:53] <stpeter> personally I see the true payload matching as less compelling [12:23:04] <Kev> I'll assume no-one else wants to vote on this, and move on. [12:23:11] <Kev> 4) Roster versioning. [12:23:13] <stpeter> and if we change XEP-0163 on this point then we need to update all the PEP payload XEPs [12:23:13] <bear> this is where, as a consumer of server based pubsub, I just wish it to be the same across servers [12:23:16] <Kev> This was just a spec bug. +1 [12:23:21] <ralphm> I just thought we earlier said +notify would be for denoting classes rather than specific nodes [12:23:38] *** Ali Sabil ([email protected]/Gajim5A495FBB) has joined the room as a participant [12:23:47] <ralphm> I can't type very fast on my phone [12:23:47] *** Ali Sabil ([email protected]/Gajim5A495FBB) has left the room [12:23:49] <MattJ> +1 to roster versioning [12:24:02] <ralphm> don't speed up [12:24:06] <stpeter> :) [12:24:09] <l-fy> ok, when is the ip part? [12:24:17] <Kev> l-fy: when we come to it. [12:24:26] <Kev> Two item's time. [12:24:38] <l-fy> ok, thank you kev [12:24:40] <stpeter> ralphm: feel free to post to the pubsub@ list again, but I think we're beating a dead horse at this point [12:24:43] <stpeter> l-fy: http://mail.jabber.org/pipermail/council/2010-February/002756.html [12:24:46] <stpeter> that's the agenda [12:24:52] *MattJ thinks that should be "two items' time", but may be wrong [12:24:59] <Kev> MattJ: it should. [12:25:03] <stpeter> sorry about the spec bug in XEP-0237 [12:25:07] *MattJ needs to know these things :) [12:25:13] <Kev> Anyone else voting on 237? [12:25:21] <MattJ> stpeter, I don't think anyone expected Facebook to do what they did :) [12:25:24] <Kev> We're approaching my 30minute tolerance for meetings :) [12:25:26] <MattJ> Quite glad of it though [12:25:28] <stpeter> MattJ: agreed [12:25:45] <ralphm> stpeter: ok, I just had a different recollection of history, one that my chat with hildjj appeared to support [12:25:46] *stpeter will need to update draft-ietf-xmpp-3921bis, too [12:26:04] *** zool is now known as [email protected] [12:26:04] *** [email protected] is now known as zool [12:26:09] <ralphm> Kev: we started late [12:26:20] <Kev> That doesn't stop us approaching 30minutes. [12:26:25] <MattJ> Heh [12:26:40] <Kev> Ok: XEP-1 [12:26:45] <Kev> Not that this needs a council vote. [12:26:47] <stpeter> hmm, I see dwd bantering on identi.ca but he's too busy to join us here, it seems :) [12:26:54] <ralphm> I want to review roster versioning again [12:27:06] <Kev> ralphm: it's a trivial change: http://xmpp.org/extensions/diff/api/xep/0237/diff/1.0/vs/1.1rc1 [12:27:31] <ralphm> damn long uri [12:27:53] <Kev> If you'd like to review, take your time and vote on list :) [12:27:54] <ralphm> still on phone (holiday) [12:27:56] <stpeter> the change is: If a client supports roster versioning and the server to which it has connected advertises support for roster versioning as described under Stream Feature, then the client MUST include the 'ver' element in its request for the roster. If the server does not advertise support for roster versioning, the client MUST NOT include the 'ver' attribute. If included, the 'ver' attribute is set to the version ID associated with its last cache of the roster. [12:28:20] <Kev> stpeter: ah, that's interesting. The diff tool shows much more changed than that. [12:28:21] <ralphm> oh [12:28:24] <stpeter> basically requiring discovery via stream features before the client engages in roster versioning [12:28:27] <ralphm> +1 then [12:28:33] <stpeter> Kev: because I moved the stream feature earlier in the spec [12:28:34] <Kev> Tobias is looking at that tonight, though, replacing the diff with something better. [12:28:38] <Kev> stpeter: ah. [12:28:39] *** Ali Sabil ([email protected]/Gajim5A495FBB) has joined the room as a participant [12:28:53] <ralphm> if that's the only change [12:28:54] <stpeter> that probably changed the numbering of all sections [12:29:09] <stpeter> that is the change [12:29:15] <ralphm> yay [12:29:21] <Kev> ralphm: right, it was just a reaction to a bug in the spec revealed by Facebook. [12:29:37] <ralphm> that's more of a clarification than anything else [12:29:39] <Kev> I don't have much comment on the xep-1 stuff. Although I do find it odd that our standards process is blocking on OSS implementations. [12:29:49] <stpeter> ralphm: correct [12:29:52] <Kev> That was there before, though, nothing to do with this change. [12:30:12] <stpeter> Kev: you would, now that you work for an evil proprietary software company :P [12:30:17] <MattJ> Heh [12:30:17] <Kev> stpeter: that may be true. [12:30:29] <stpeter> in fact, we should be blocking on real interop testing, but that's another story [12:30:48] <ralphm> Kev: I think open 'reference' implementations are crucial to any open protocol [12:31:01] <Kev> Real interop testing seems more valuable than requiring that the implementations are RMS-compliant :) [12:31:04] *** zool is now known as [email protected] [12:31:04] *** [email protected] is now known as zool [12:31:15] <stpeter> and who will develop the reference implementations? that is a truly thankless job [12:31:20] <Kev> ralphm: ah, well, in that case shouldn't the XSF be producing them? :) [12:31:30] <stpeter> Kev: right [12:31:43] *** remko ([email protected]/Swift) has left the room [12:31:44] <MattJ> *cough* [12:31:46] <Kev> But in any case, does anyone have any comments on the xep-1 changes? [12:31:46] <ralphm> Kev: you know I'm far from an rms fanboy [12:31:57] <stpeter> Kev: and then the XSF gets into the business of writing software, which various vendors might construe as favoring competing implementations [12:32:04] <stpeter> and we've always avoided that path [12:32:05] <Kev> stpeter: indeed. [12:32:10] <ralphm> Kev: I would love the XSF to sponsor such work, yes [12:32:29] <ralphm> not do it themselves [12:32:32] <stpeter> ok, that's a broader discussion :) [12:32:36] <Kev> I seem to have derailed this quite nicely. [12:32:42] <stpeter> please take a look at the XEP-0001 fixes [12:32:45] <Kev> Back on-track - anyone have comments on the current changes? [12:32:55] <ralphm> no [12:33:02] <Kev> I didn't have any comments, it looked minor, at least as the diff-tool presented it. [12:33:14] <MattJ> Anywhere I can see the XEP-0001 fixes? [12:33:17] <stpeter> Kev: mostly minor, yes [12:33:23] <stpeter> http://xmpp.org/extensions/diff/ [12:33:27] <Kev> MattJ: http://xmpp.org/extensions/diff/ [12:33:33] <MattJ> Not working for me [12:33:46] <Kev> Oh, it is for me, given the right diff versions. [12:33:49] <MattJ> Like Gajim, which is throwing error dialogs in my face as I try to type [12:33:52] <stpeter> gotta have the right javascript [12:34:00] <MattJ> Hmph [12:34:02] <Kev> Well, people can comment on-list anyway :) [12:34:08] <stpeter> right [12:34:09] <Kev> 6) Proto-XEP: Server IP Check http://xmpp.org/extensions/inbox/sic.html Accept as XEP? [12:34:09] <MattJ> Kev, what are the right diff versions? [12:34:13] <bear> mattj - you have to pick another xep and then go back to 001 [12:34:18] <stpeter> 1.19 to 1.20rc2 [12:34:22] <MattJ> Ah [12:34:23] <stpeter> bear: oh yes [12:34:30] <stpeter> I discovered that recently :) [12:34:37] <ralphm> Kev: what's the gist of that spec? [12:34:37] <MattJ> No, still failed :) [12:34:41] *** Bloody Rose ([email protected]/Home) has joined the room as a participant [12:34:47] <stpeter> ok, IP check [12:34:53] <Kev> ralphm: client asks server what the IP it thinks the client has is, server replies. [12:35:03] <ralphm> that again [12:35:04] <Bloody Rose> hi. is it okay for me to be here? [12:35:05] <bear> mattj - you have to change each dropdown in order to trigger the next one to reload it's values [12:35:13] <Kev> Bloody Rose: yes, spectating is allowed. [12:35:14] <stpeter> the idea (from Summit #6?) is that the server tells you what your IP address, which gives you a hint as to whether you're behind a firewall [12:35:28] <Bloody Rose> thanks. [12:35:29] <stpeter> +is in there somewhere [12:36:00] <ralphm> I am sure we struck this down umpteen times [12:36:02] <Kev> So, this has been rejected by council several times already, right? [12:36:05] *** zool is now known as [email protected] [12:36:05] *** [email protected] is now known as zool [12:36:06] <stpeter> that external IP address might even be useful in candidates for ICE-TCP (less likely for ICE-UDP) [12:36:12] <stpeter> Kev: once [12:36:20] <MattJ> I believe it was deemed "not useful" [12:36:23] <Tobias> MattJ: the usual error: DESC: java.io.IOException: Server returned HTTP response code: 503 for URL: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd :) [12:36:31] <MattJ> But now I'm on the council I can argue it is :) [12:36:36] <Tobias> i hope the other diff tool doesn't give a damn on DTDs [12:36:39] <Kev> It certainly doesn't solve the general case, but if people are that keen on it, ... [12:36:41] <stpeter> I do not see any active harm in this feature [12:36:45] <MattJ> Me neither [12:36:54] <stpeter> people can make use of it and perhaps it will be helpful [12:37:06] <stpeter> at least, people think it might be helpful [12:37:11] <MattJ> Discovering your external IP is useful in many cases [12:37:13] <ralphm> If it makes people happy +1 [12:37:17] <MattJ> Yay [12:37:25] <Kev> MattJ: ah, but this doesn't tell you your external IP. [12:37:32] <stpeter> e.g., your server tells you an IP address and then you decide that immediately you need to get more creative about gathering candidates for Jingle use cases [12:37:43] <Kev> This tells you the IP you connected to the server from, which is completely different, potentially. [12:37:47] <Kev> But in any case, I'm not -1. [12:38:00] <ralphm> Kev: exactly [12:38:02] <stpeter> Kev: potentially, yes [12:38:08] <ralphm> routing is so cool [12:38:10] <MattJ> Kev, "potentially" [12:38:13] <MattJ> == "rarely" [12:38:18] <Kev> It would be for me :) [12:38:31] <ralphm> MattJ: you must be new around here [12:38:43] <Kev> In any case. No-one's objecting. [12:38:51] <MattJ> I don't see "this isn't useful for some people" as "no-one should be allowed to use this" [12:38:51] <Kev> Remko and Dave need to not object too. [12:38:58] <MattJ> ok :) [12:39:05] <stpeter> however, I think the proposal needs to explain itself a bit better :) [12:39:07] <Kev> Let's argue about just how much we're not objecting some other time. [12:39:15] <Kev> 7) Jingle Relay Nodes http://xmpp.org/extensions/inbox/jingle-nodes.html Accept as XEP? [12:39:30] <ralphm> +1 [12:39:36] <Kev> Lots of stuff needs to be cleaned up in this, like inventing a new disco protocol for one, but it doesn't seem inherently broken. [12:39:36] <MattJ> +1 [12:39:41] <stpeter> heh [12:39:48] <ralphm> Kev: haha [12:39:52] <MattJ> Yes, I need to re-read it, but not sure why PEP couldn't be used [12:39:59] <Kev> MattJ: PEP, or Disco. [12:40:05] <ralphm> or both! [12:40:09] <MattJ> :) [12:40:18] <Kev> "Use case: I need to discover what items this service has" [12:40:24] <Kev> Yes, clearly a new spec is needed for this :) [12:40:40] <stpeter> MattJ: I think that Thiago did not want to introduce a *hard* dependency on PEP given that services like Google Talk don't support it yet, however I do think that adding a PEP flow would be good [12:40:48] <Kev> Anyway, no-one's objecting, and I'm happy to clean it up if Thiago doesn't want to, it's mostly straightforward stuff to fix. [12:40:57] <MattJ> Agreed [12:41:05] <Kev> http://xmpp.org/extensions/inbox/distributedmuc.html [12:41:06] *** zool is now known as [email protected] [12:41:06] *** [email protected] is now known as zool [12:41:13] <ralphm> +1 [12:41:16] <Kev> Peter: were you asking for this to be voted on, or just discussed? [12:41:30] <ralphm> we can't vote on it yet [12:41:45] <Kev> ralphm: sure we can, we can vote to veto it ;) [12:41:46] <ralphm> we just can comment or not-object to be a xep [12:42:03] <ralphm> I did the latter [12:42:04] <stpeter> :) [12:42:24] <Kev> I was thinking we'd take quite a different approach to this. [12:42:33] <stpeter> Kev: I'd like to make it a XEP at some point but I never heard details about the approach that you and Dave were talking about [12:42:40] <ralphm> cool: counter-spec: [12:42:45] <ralphm> ! [12:42:53] <stpeter> Kev: so mostly I'd like to hear about that and merge or whatever we need [12:43:06] <Kev> Which is that the current proposal essentially requires a peering agreement between the muc services, and I was going to suggest that it could be done transparently for local services. [12:43:09] <stpeter> I don't care deeply about the proposed approach [12:43:16] <Kev> I'm happy to write up a summary of what Dave and I discussed. [12:43:22] <stpeter> Kev: that would be most helpful [12:43:29] <ralphm> local services? [12:43:29] <MattJ> Kev, sounds like what I have half-implemented [12:43:31] <Kev> stpeter: would you like us to decide whether to accept this version in the meantime, or wait? [12:43:32] <stpeter> doesn't need to be in XEP form [12:43:36] <stpeter> Kev: no [12:43:44] <MattJ> so I'm keen to see a spec [12:44:02] <Kev> ralphm: sure, so jabber.ru could proxy co.jabber.org without a peering agreement, but only for local users. [12:44:03] <ralphm> local as in 'within logical server'? [12:44:08] <stpeter> Kev: as I say, I'm not wedded to this approach [12:44:26] <Kev> And if c.j.o wanted jabber.ru to officially mirror, it could be added to the SRV records. [12:44:32] <Kev> stpeter: ok, let's discuss out of meeting then :) [12:44:46] <stpeter> WFM [12:44:51] <Kev> Date of next meeting? [12:45:01] <MattJ> +7? [12:45:03] <stpeter> I'm just trying to get some discussion going [12:45:04] <Kev> Next Monday night /should/ be ok for me. [12:45:13] <Kev> Although I'm in the middle of move, I think I'll have DSL. [12:45:23] <ralphm> I'm probably not online next week [12:45:36] *** Ali Sabil ([email protected]/Gajim5A495FBB) has left the room [12:45:38] *** Ali Sabil ([email protected]/GajimDFA76505) has joined the room as a participant [12:45:50] <Kev> Well, MattJ: would you rather skip a week, or plough ahead regardless? [12:45:50] <stpeter> ralphm: ok [12:46:01] <Kev> As Dave and Remko aren't here to express a preference :) [12:46:03] *stpeter is favor of ploughing or plowing [12:46:06] *** zool is now known as [email protected] [12:46:06] *** [email protected] is now known as zool [12:46:15] <ralphm> favour? [12:46:16] <MattJ> ploughing :) [12:46:20] <MattJ> favour [12:46:28] <stpeter> :P [12:46:41] <Kev> Ok, next week it is then. [12:46:42] <MattJ> New words stpeter has /learnt/ [12:46:48] <Kev> Any other business? [12:46:48] *** dthompson ([email protected]/AdiumD8B9E52D) has joined the room as a participant [12:46:49] <MattJ> Kev, thanks, I'll update the calendar [12:46:49] <stpeter> I'm in favor of plowing, so if you guys are in favour of ploughing then let's make progress [12:46:49] *** dthompson ([email protected]/AdiumD8B9E52D) has left the room [12:46:53] <Bloody Rose> will this conversation be saved and published? I missed the beginning. [12:46:56] <ralphm> I spelt it right anyway [12:47:00] <Kev> Bloody Rose: yes, there'll be minutes. [12:47:29] <stpeter> hmm [12:47:33] <stpeter> well [12:47:45] <stpeter> I wanted to make a more general point about spec updates [12:47:49] <stpeter> and maintenance of existing specs [12:48:00] <stpeter> which is a lot of what I do [12:48:02] <ralphm> 'spelt' is a personal favourite [12:48:06] <stpeter> I'm about to have less time [12:48:10] <Bloody Rose> where should I look for logs? [12:48:17] <Kev> Bloody Rose: standards@ [12:48:25] <stpeter> so I think we might need to ask the technical review team to step up [12:48:25] <Kev> Or council@ [12:48:31] <stpeter> or something [12:48:36] <stpeter> I'm not sure yet [12:48:48] <stpeter> but I think we need a better process for XEP maintenance [12:48:53] <stpeter> one that is less dependent on me [12:48:58] <ralphm> stpeter: I could take on maintainership of specs with my name on it [12:48:58] <Kev> stpeter: Want to come up with a proposal and we can discuss on list or such? [12:49:06] <Kev> I'm happy to do some spec maintenance. [12:49:12] <stpeter> Kev: yes, I'm just raising the issue at this point [12:49:30] <ralphm> and here we are solving things as we go [12:49:33] <ralphm> yay [12:49:38] <stpeter> :) [12:50:01] <Kev> Ok. [12:50:03] <stpeter> I'll post to some list about it (members or council or something) and we can discuss further at the next meeting [12:50:24] <stpeter> that's it for me [12:50:48] <Kev> I'm inclined to suggest that we move XEP maintenance into some more modern VCS than Subversion. [12:50:55] <Kev> but that's not really a council matter. [12:50:59] <Kev> So, thanks all [12:51:02] *Kev bangs the gavel. [12:51:03] <stpeter> :) [12:51:03] <ralphm> just pass on maintainership to the other authors and the rest we assign to the first person asking for modifications [12:51:07] *** zool is now known as [email protected] [12:51:19] <ralphm> Kev: sure it is [12:51:19] <bear> anything distributed and you will increase the load/need for a single master editor [12:51:25] <stpeter> I'm more concerned about the review and maintenance process than the tool [12:52:16] <stpeter> but we can discuss next week :) [12:52:31] <ralphm> bear: even in a dvcs setting you'd need people managing the 'true master' [12:52:42] <Tobias> ralphm: right [12:52:47] <bear> ralphm - that's the point I was trying to make [12:53:15] <Kev> Actually, I think that's completely untrue :) [12:53:21] <ralphm> oh, hah [12:53:33] <bear> with subversion you have a single repo that everyone can see where the change came from [12:53:41] <Kev> People with commit access to svn = people with commit access to origin/master [12:53:53] <ralphm> Kev: agreed [12:53:59] <Kev> People without commit access to svn need to go through the above. People without commit access to origin/master need to go through the above. [12:54:09] <Kev> It's the same deal. [12:54:38] *** [email protected] ([email protected]/McBukF33C0959) has left the room [12:54:39] <bear> you don't commit to a dvcs if your not local to it - you have to pull in the changes [12:54:52] <bear> so someone who is local to the master has to pull in outside changesets [12:55:08] <Kev> You certainly can do it that way, if you like pain. [12:55:17] <ralphm> the advantage of dvcs is just that tooling is easier [12:55:22] <Kev> Or you can just have a bundle of people capable of pushing to master. [12:55:33] <stpeter> brb [12:55:36] <Kev> Just like we have with svn. [12:55:49] <Kev> Except where it's easier to work offline etc. [12:55:51] <ralphm> as in, you could offer a pull request rather than send a patch by mail [12:55:55] <ralphm> or something [12:56:13] <Kev> ralphm: or send a patch by mail, still, whichever. [12:56:19] <bear> that just shifts the pain - others will then have to routinely sync their local master copy [12:56:34] <Kev> bear: right, just like they have to with svn. [12:56:36] <darkrain> How is that different from "svn up"? [12:56:37] <bear> so yea, you can do it - the perception of pain just changes [12:56:49] <ralphm> bear: as we said, tooling [12:56:51] <bear> with svn up it's part of the normal flow - so the pain is shared globally ;) [12:57:38] <ralphm> given the amount of people currently trying to amend specs other than having peter do it, I don't think this is a real issue right now [12:57:44] <bear> just trying to point out that in the realm of documents, where there isn't a build/qa process to show failures - dvcs requires more admin overview than most folks think [13:04:50] <stpeter> so who will write the minutes for this meeting, and do we need to send the chatlog to the [email protected] list for completeness? [13:05:02] <Kev> stpeter: I can, and probably. [13:05:09] <Kev> I'll do so tomorrow morning though, rather than Right Now. [13:05:09] <stpeter> ok [13:05:14] <stpeter> no worries [13:05:18] <stpeter> I'll send the chatlog now
smime.p7s
Description: S/MIME cryptographic signature
