[Standards] Fwd: [Council] chat log from 2010-02-15 meeting

Kevin Smith kevin at kismith.co.uk
Thu Feb 18 16:30:54 UTC 2010


FYI


---------- Forwarded message ----------
From: Peter Saint-Andre <stpeter at stpeter.im>
Date: Mon, Feb 15, 2010 at 8:06 PM
Subject: [Council] chat log from 2010-02-15 meeting
To: XMPP Council <council at xmpp.org>


*** 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] *** zooldk at gmail.com (zooldk at gmail.com/McBukF33C0959) has
joined the room as a participant
[11:52:05] *** fritzy (fritzy at netflint.net/work/laptop) has joined the
room as a participant
[11:52:18] *** ralphm (ralphm at ik.nu/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] *** zooldk at gmail.com is now known as zool
[11:53:04] *** zool is now known as zooldk at gmail.com
[11:53:04] *** zooldk at gmail.com is now known as zool
[11:53:15] *** MattJ (matthew at prosody.im/Gajim) has joined the room as a
moderator and an administrator
[11:53:30] *** bear (bear at code-bear.com/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 zooldk at gmail.com
[11:56:02] *** zooldk at gmail.com is now known as zool
[11:56:15] *** darkrain (paul at darkrain42.org/λ) 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 (deryni at pidgin.im/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 zooldk at gmail.com
[12:01:02] *** zooldk at gmail.com 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 (johann.prieur at talkr.im/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 (ali.sabil at gmail.com/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 (ali.sabil at gmail.com/Gajim5A495FBB) has left
the room
[12:05:25] <Kev> stpeter: Iono.
[12:05:27] *** remko (remko at el-tramo.be/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 zooldk at gmail.com
[12:06:02] *** zooldk at gmail.com 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 (kelly.hays at jkhfamily.org/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 pubsub at xmpp.org 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 (ali.sabil at gmail.com/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 (ali.sabil at gmail.com/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 zooldk at gmail.com
[12:11:03] *** zooldk at gmail.com 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 (ali.sabil at gmail.com/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 (ali.sabil at gmail.com/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 (tofu at thetofu.com/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 zooldk at gmail.com
[12:16:03] *** zooldk at gmail.com 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 (ali.sabil at gmail.com/Gajim5A495FBB) has joined
the room as a participant
[12:18:47] <MattJ> Hmm
[12:18:47] *** Ali Sabil (ali.sabil at gmail.com/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 zooldk at gmail.com
[12:21:04] *** zooldk at gmail.com is now known as zool
[12:21:20] *** l-fy
(l-fy at jabber.null.ro/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 (tofu at thetofu.com/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 (ali.sabil at gmail.com/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 (ali.sabil at gmail.com/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 zooldk at gmail.com
[12:26:04] *** zooldk at gmail.com 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 (ali.sabil at gmail.com/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 zooldk at gmail.com
[12:31:04] *** zooldk at gmail.com 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 (remko at el-tramo.be/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 (bloodyrose at jabber.org/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 zooldk at gmail.com
[12:36:05] *** zooldk at gmail.com 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 zooldk at gmail.com
[12:41:06] *** zooldk at gmail.com 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 (ali.sabil at gmail.com/Gajim5A495FBB) has left
the room
[12:45:38] *** Ali Sabil (ali.sabil at gmail.com/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 zooldk at gmail.com
[12:46:06] *** zooldk at gmail.com 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 (dthompson at gmail.com/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 (dthompson at gmail.com/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 zooldk at gmail.com
[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] *** zooldk at gmail.com (zooldk at gmail.com/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 council at xmpp.org 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100218/f9044eb3/attachment.bin>


More information about the Standards mailing list