Wednesday, April 04, 2012
council@muc.xmpp.org
April
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
           
XMPP Council Room | https://xmpp.org/about/xmpp-standards-foundation#council | Room logs: http://logs.xmpp.org/council/ | https://trello.com/b/ww7zWMlI/xmpp-council-agenda

[00:29:40] *** linuxwolf shows as "away" and his status message is "stuffage"
[00:29:40] *** linuxwolf has left the room
[01:44:03] *** Neustradamus shows as "away"
[07:21:44] *** Tobias has joined the room
[07:21:47] *** Tobias shows as "online" and his status message is "Available"
[07:45:09] *** Kev shows as "online"
[07:58:53] *** Tobias has left the room
[08:20:05] *** fippo has joined the room
[08:27:52] *** Tobias has joined the room
[08:27:52] *** Tobias shows as "online" and his status message is "Available"
[08:46:50] *** Kooda shows as "online"
[09:38:00] *** Tobias has left the room
[10:00:58] *** Kooda shows as "away"
[10:16:52] *** Kooda shows as "online"
[10:47:21] *** Tobias has joined the room
[10:47:24] *** Tobias shows as "online" and his status message is "Available"
[13:24:33] *** linuxwolf has joined the room
[13:30:08] *** linuxwolf has left the room
[13:34:37] *** linuxwolf has joined the room
[14:08:23] *** linuxwolf shows as "away" and his status message is "stuffage"
[14:11:24] *** linuxwolf shows as "online"
[14:39:21] *** linuxwolf shows as "away" and his status message is "stuffage"
[14:41:48] *** Tobias has joined the room
[14:41:50] *** Tobias shows as "online" and his status message is "Available"
[14:49:22] *** linuxwolf shows as "away" and his status message is "stuffage"
[14:53:40] *** MattJ has joined the room
[14:57:06] *** linuxwolf shows as "away" and his status message is "stuffage"
[14:57:09] *** linuxwolf shows as "online"
[15:04:21] <linuxwolf> meeting in one more hour (ish)?
[15:06:29] <Kev> Nope, now.
[15:06:30] <Kev> I suck.
[15:06:33] <Kev> Thanks for the poke
[15:06:34] <linuxwolf> heh
[15:06:37] <linuxwolf> no worries
[15:06:44] *linuxwolf is still not sure which timezone he's hin
[15:06:52] <Kev> I'm in GSoC time.
[15:07:02] <linuxwolf> (-:
[15:07:13] <Kev> But anyway.
[15:07:17] <Kev> 1) Roll call.
[15:07:24] <linuxwolf> presente
[15:07:32] *** linuxwolf shows as "dnd" and his status message is "XSF Council"
[15:07:53] <Kev> MattJ / Tobias: Highlight.
[15:07:58] <Tobias> present
[15:08:05] <MattJ> Boo
[15:08:11] <MattJ> gift
[15:08:28] <linuxwolf> offering?
[15:08:37] <Kev> Righty
[15:08:45] <Kev> 2) XMPP WG report.
[15:08:49] <Kev> linuxwolf: You fancy giving one? :)
[15:08:54] <linuxwolf> sure
[15:09:23] <linuxwolf> The WG meeting in Paris, one week back
[15:09:41] <linuxwolf> major topics are end-to-end encryption, domain-name-assertions, and i18n
[15:10:22] <Tobias> roughly the same topics as 5 years ago it seems :)
[15:10:27] <linuxwolf> there is a draft for a new proposal to e2e, which puts key management into a protocol, and is trying to re-use the work from JOSE (JSON Object Signing and Encrypting)
[15:10:32] <linuxwolf> Tobias: basically (-:
[15:10:44] <MattJ> I finally know what JOSE is
[15:10:53] <linuxwolf> (-:
[15:11:05] <Kev> linuxwolf: So long as it doesn't need us to rewrite XMPP in JSON.
[15:11:11] <linuxwolf> no!
[15:11:12] <linuxwolf> the proposal has been received favorable reviews to date
[15:11:30] <linuxwolf> the crypto bits are encoded with some sprinkling of JSON, but the XMPP stuff is still XML
[15:11:49] <Kev> OK.
[15:11:49] <linuxwolf> it was either that or ASN.1
[15:12:04] <linuxwolf> no one born after 1970 wants to use ASN.1
[15:12:04] <Tobias> wheeee..ASN.1 :D
[15:12:15] <MattJ> :)
[15:12:16] <Kev> Right.
[15:12:53] <linuxwolf> if you're interested: http://tools.ietf.org/html/draft-miller-xmpp-e2e
[15:13:16] <linuxwolf> there'll be an update to that sometime this month (-:
[15:13:16] <Kev> Ta. I'll have a read at some point (not right now).
[15:13:27] <linuxwolf> DNA ...
[15:13:48] <linuxwolf> so, after floundering about with non-discussion ...
[15:14:21] <linuxwolf> … an approach is starting to form around a layered approach
[15:14:42] <linuxwolf> 1) determine alternate trust algorithms for certificates
[15:15:13] <linuxwolf> 2) use stream:stream headers and/or dialback for asserting names (then use the afore mentioned prooftypes)
[15:15:38] <linuxwolf> there's been discussion for two alternatives over PKIX: https/.well-known and DANE
[15:16:19] <linuxwolf> DANE is a DNS-based protocol, essentially you get the target cert, signed indirectly with DNSSEC
[15:16:46] <linuxwolf> the TLSA RR is signed, but the cert can be almost anything: self-signed, ca-signed, trust-anchor, etc
[15:17:11] <Tobias> linuxwolf, alternatives? can't PKIX, https/.well-known and DANE co-exist?
[15:17:16] <linuxwolf> they can
[15:17:29] <Tobias> and HTTPS's S is based on what, PKIX?
[15:17:37] <linuxwolf> and a server (or client) will likely need to implement all three
[15:18:11] <linuxwolf> the HTTPS/.well-known is simply the target certificate (or maybe also a trust-anchor) at a specific path through HTTPS
[15:18:40] <linuxwolf> the trust established if you can trust the HTTPS connection
[15:19:17] <Tobias> PKIX and DANE are likely to be implemented in TLS libraries in future, right?
[15:19:18] <Kev> Tobias: HTTPS:/.well-known is basically "Yes, we're not solving any problems, but we're saying they're not *our* problems, so that's fine".
[15:19:29] <linuxwolf> in all cases, the target cert would be the hosting services cert (e.g. talk.goole.com or webexconnect.com) but obtained from the target domain (e.g. example.com)
[15:19:45] <linuxwolf> PKIX is already implemented in OpenSSL
[15:19:53] <Tobias> linuxwolf, right...wrongly phrased
[15:19:56] <linuxwolf> DANE is likely to be implemented in some DNS libraries
[15:20:03] <linuxwolf> but just to get the cert
[15:20:13] <Kev> linuxwolf: *Some* of PKIX is in OpenSSL, right?
[15:20:14] <linuxwolf> you'll then feed that into, say, OpenSSL to complete validation
[15:20:25] <Kev> PKIX also includes revocation, doesn't it?
[15:20:26] <linuxwolf> Kev: it depends on what version of OpenSSL we're talking about
[15:20:30] <linuxwolf> it does
[15:20:38] <Kev> And OpenSSL doesn't do revocation checks for you.
[15:20:44] <linuxwolf> it can do some
[15:20:45] <Kev> Does it?
[15:20:47] <Tobias> k...and the HTTPS way will probably always need to implemented directly by XMPP client/server devs
[15:21:07] <linuxwolf> 1.0 can process a CRL chain, if it's local
[15:21:16] <linuxwolf> Tobias: most likely
[15:21:31] <linuxwolf> as I see it: HTTPS would be implemented "now", and DANE would come later
[15:21:49] <Tobias> linuxwolf, is DANE so far away *now*?
[15:21:53] <linuxwolf> long-term, DANE is probably the better technical approach, but it's not exactly deployable yet
[15:22:03] <linuxwolf> it depends on who you ask
[15:22:20] <Tobias> yeah...i've asked my ISP and he said ask again in a month ^^
[15:22:34] <linuxwolf> there are more and more DNS resolvers and nameservers supporting DNSSEC, but only for the common TLDs
[15:22:47] <Tobias> right
[15:22:54] <linuxwolf> outside of .com/org/net, it's not available
[15:23:14] <linuxwolf> DANE has not finished IESG Last Call, so there's a lot of people holding off on implementations
[15:23:14] <Tobias> but requireing HTTPS support for XMPP clients/servers
[15:23:25] <linuxwolf> /shrug
[15:23:45] <linuxwolf> HTTPS implementations are everywhere, and if a server supports BOSH, it already supports HTTP
[15:23:57] <linuxwolf> adding HTTPS is not *that* much more work, unless you did everything by hand
[15:23:58] <Tobias> but then again there are a lot (maybe even well tested) ready to use implementations for it
[15:24:04] <linuxwolf> exactly
[15:24:23] <MattJ> If a server supports BOSH it supports being a server, not a client
[15:24:25] <linuxwolf> plus, a lot of clients end up with HTTP libraries for things like updating and grabbing images and whatnot
[15:24:33] <Kev> I think it's a much more nefarious problem than that.
[15:24:34] <MattJ> but *shrug*, Prosody does both already
[15:24:57] <linuxwolf> MattJ: true, but like I said there are lots and lots of HTTP libraries around
[15:24:59] <Kev> It's one thing "supporting HTTP", it's quite another getting this into the trust checking for the XMPP session.
[15:25:09] <Kev> But anyway.
[15:25:12] <MattJ> Is it really?
[15:25:14] <linuxwolf> Kev: well, gotta get there somehow
[15:25:16] <MattJ> Harder than anything else?
[15:25:25] <MattJ> The trust checking is going to change anyway
[15:25:30] <linuxwolf> right
[15:25:41] <Kev> MattJ: Harder than PKIX, which is already required, yeah :)
[15:25:42] <linuxwolf> PKIX isn't good enough already, so *something* needs to be done
[15:25:50] <MattJ> Right
[15:25:54] <Tobias> exactly
[15:26:25] <Kev> So, do you connect to the XMPP server, ask for the cert, then see it's not right, so go on to check over HTTPS?
[15:26:33] <linuxwolf> both DANE and HTTPS are essentially "does this cert match", without the need to go through the nitty-gritty subject
[15:27:00] <Kev> If both certs are 'bad', but behind the HTTPS cert is the .well-known for the XMPP server, do you present the HTTP stuff to the user and ask them to trust the HTTPS? etc.
[15:27:00] <linuxwolf> Kev: that's roughly what I was thinking
[15:27:14] <Kev> I'm not saying these aren't resolvable problems.
[15:27:35] <Kev> I *am* saying this is a lot more unpleasant at the edges than "Well, there are plenty of HTTPS libraries, so we just use those" makes it sound.
[15:27:41] <MattJ> Sure
[15:27:49] <linuxwolf> Kev: it's a detail that does need to get worked out, but frankly the HTTP people have done a lot more with it than anyone else
[15:28:07] <Kev> Right, probably.
[15:28:11] <Kev> So, moving on :)
[15:28:28] <linuxwolf> anyway, comments on the xmpp@ietf.org mailing list are most welcome
[15:28:30] *** Kev shows as "dnd" and his status message is "Council"
[15:28:44] <linuxwolf> the last one is i18n
[15:29:16] <linuxwolf> Precis is finishing up its definition of the framework, and stpeter has a draft for 6122bis based on that
[15:30:00] <linuxwolf> but, there are a lot of dragons to work out, and we're suggesting some sub-profiles for specific things, like MUC nicknames
[15:30:19] <linuxwolf> so a resourcepart would accept just about anything, but usage with MUC would be more restrictive
[15:31:05] <linuxwolf> some discussion on how one might go about enforcing and discovering such rules (which are seen as locale-specific) was thought about
[15:31:27] <linuxwolf> a lot of 6122bis is waiting on precis, which is progressing … albeit slower than others would like
[15:31:42] <linuxwolf> and I think that about sums up the actual meeting
[15:32:05] <MattJ> The "others" who don't like the speed aren't very vocal in helping resolve issues (afaics)
[15:32:06] <linuxwolf> there is a proposal from a group in Japan for alternatives to DNS SRV, and they'd like feedback on it
[15:32:13] <MattJ> Not that the issues are easy, but that's why it's slow
[15:32:15] <linuxwolf> MattJ: essentially
[15:32:39] <linuxwolf> well, that, and it's really a cultural problem we're attempting to solve with technology
[15:33:04] <linuxwolf> so there may not actually be a right way to do this anyway
[15:33:07] <MattJ> Indeed
[15:33:23] <linuxwolf> the precis meeting ended with "maybe we need a new area directorate for internationalization"
[15:33:32] <Tobias> heh
[15:33:36] <linuxwolf> yeah
[15:34:30] <linuxwolf> oh, one last point on DNA: there is no current draft yet, but there's three of us working on one, once we get back to work from IETF (-:
[15:34:40] <linuxwolf> so be on the lookout for that, if you care about it
[15:34:40] <Kev> Lovely.
[15:34:51] <Kev> So that's Paris covered?
[15:34:55] <linuxwolf> most people, smarter people, take time off after these
[15:34:58] <linuxwolf> yes
[15:35:11] <Kev> 3) Date of next meeting - same time next week?
[15:35:17] <Tobias> wfm
[15:35:21] <linuxwolf> wfm
[15:35:22] <MattJ> wfm
[15:35:31] <Kev> 4) Request from chair
[15:35:36] <Kev> Can someone else minute this please?
[15:35:42] <linuxwolf> will do
[15:35:44] <Kev> Thanks verym uch.
[15:35:53] <Kev> 5) AOB?
[15:35:59] <MattJ> None here
[15:36:01] <linuxwolf> I'll have them out by tomorrow
[15:36:08] <linuxwolf> nothing more from me
[15:36:19] <Tobias> neither here
[15:36:27] <Kev> Marvellous.
[15:36:29] <Kev> Thanks all.
[15:36:35] *Kev meeting over gavel bangs.
[15:36:37] <linuxwolf> five minutes over (-:
[15:36:47] <MattJ> :)
[15:36:50] *linuxwolf goes off to next meeting … which is probably already over
[15:37:01] <Kev> Yeah, sorry.
[15:37:09] <linuxwolf> no, it's perfectly fine
[15:37:09] <Kev> Exactly 30 minutes, but I needed to be poked to start.
[15:37:29] <linuxwolf> fine with me anyway, I've already told the others I'm likely to miss on Wednesdays (-:
[15:37:49] <Kev> MattJ: MAM. We're almost certain to have someone working on it in Swift for GSoC - so a) Where's the spec and b) How's Prosody's support?
[15:38:33] *** Kev shows as "online"
[15:38:46] <MattJ> a) the spec is either the one currently on matthewwild.co.uk, or the one I haven't finished yet to submit
[15:39:24] <MattJ> b) Prosody's support is for the one on matthewwild.co.uk, and I believe it is mostly complete, just inefficient (fine for developing with, not for production)
[15:39:34] <MattJ> Zash would know more, since he wrote it
[15:41:27] <Kev> How different is what you're submitting for XEPpification from what's on mw.co.uk?
[15:42:56] <MattJ> Not very
[15:43:03] *MattJ pulls up matthewwild.co.uk's version
[15:43:17] <Kev> OK, cool.
[15:43:25] <Kev> We have to expect some change from Experimental->Draft anyway.
[15:43:29] <MattJ> Right, so everything there will work
[15:43:36] <MattJ> But I'm adding querying by id too
[15:43:39] <Kev> But if you'd rewritten it, targetting that doc wouldn't be much use.
[15:43:47] <MattJ> No, the basics there won't change
[15:43:54] <Kev> "Querying by id" -> "Get me everything since ID X"?
[15:44:21] <MattJ> Yes
[15:44:30] <Kev> Cool.
[15:44:35] <MattJ> I think I talked to you about this once upon a time
[15:44:41] <Kev> Yes, I said we needed it.
[15:44:44] <MattJ> I was trying to avoid giving messages unique ids
[15:44:49] <MattJ> But I agree it's a necessary evil
[15:45:12] <MattJ> One interesting open question...
[15:45:22] <MattJ> Is how the client knows the id of messages it sends
[15:45:37] <MattJ> We either solve it so that it does, or it downloads duplicates
[15:45:44] <MattJ> at some point
[15:46:02] <MattJ> I think this is most important for clients that have dual local-remote history implementations
[15:46:27] <MattJ> and since all clients with history do local at the moment... it's important to them
[15:47:02] <MattJ> Everything else is simple, but I can't dream up a clean solution to this
[15:47:15] <MattJ> I was going to leave it open when I submit the spec, and see if anyone on the list has bright ideas
[15:47:45] <Kev> MattJ: Well, there are beautiful solutions for it that you don't want to consider :)
[15:47:53] <MattJ> Such as?
[15:48:07] <Kev> Like just redownloading all messages and ignoring your 'natural' history in favour of what's in MAM.
[15:48:47] <MattJ> Sure, that's one solution (no solution at all)
[15:49:05] <MattJ> It just feels like a waste of time to me to re-download messages it already has
[15:50:40] <Kev> Of course it is :)
[15:51:25] <Kev> But, I think we can solve this.
[15:51:34] <Kev> Or, rather, not knowing the id of your sent messages isn't the biggest problem here.
[15:52:01] <MattJ> What do you think is?
[15:52:02] <Kev> I'm assuming that the case we're trying to solve here is "I want to use MAM to get a full local history cache, given that I have already received all my this-resource messages"
[15:52:15] <MattJ> Indeed
[15:52:39] <Kev> And in this case, the big problem is 'filling in' the same history period for which you have a partial history.
[15:53:40] <MattJ> Mmm
[15:54:14] <Kev> Now, possibly the thing to do here is to always use carbons.
[15:54:33] <Kev> That is "If you are going to want a complete local history cache, always use carbons.".
[15:55:27] <Kev> That way you can sync from $LAST_ID -> $NOW when you log in, get carbons of everything from then on, and record the last received message id when you log out. Or even have the server send you the last MAM id for a message you've received when you close the stream.
[15:56:29] *** linuxwolf shows as "dnd" and his status message is "XSF Council"
[15:58:17] *** Neustradamus shows as "away"
[16:08:58] <MattJ> Indeed
[16:09:12] <MattJ> What about messages you send? Which carbons doesn't provide atm afaik
[16:09:59] <Kev> It should.
[16:10:06] <Kev> linuxwolf: Ping.
[16:10:31] <Kev> There's not so much point using carbons to get half of every conversation other than the one for the current session :)
[16:16:40] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[16:16:46] *** linuxwolf shows as "dnd" and his status message is "XSF Council"
[16:19:44] *** MattJ shows as "online"
[16:21:13] <linuxwolf> ??
[16:22:54] <linuxwolf> IIRC, the original thinking was if a specific resource is sending the message, it doesn't need a carbon of it
[16:24:31] <linuxwolf> how about I change § 3.6 to:
Carbons clients want to have copies of messages going in /both/ directions for all resources associated with the same user. To that end, messages of type "chat" that are sent from any resource MUST be copied by the sending server to each of the resources that have enabled Carbons.
[16:26:05] <Kev> Do you currently get a copy of every message sent from another resource?
[16:26:19] <Kev> I thought $OTHER_MATT was implying that you didn't (I thought you did).
[16:26:30] <Kev> This is what you need. I don't think you need a duplication of your own outgoings.
[16:27:56] <MattJ> No, sorry, I wasn't implying that
[16:28:09] <MattJ> When I said "you" I meant the current resource
[16:28:58] <Kev> I don't think you need that, do you?
[16:29:10] <linuxwolf> the current text forwards a <sent/> carbon to every resource OTHER THAN the sending resource
[16:29:20] <linuxwolf> I can see going either way
[16:29:36] <Kev> linuxwolf: Thanks - that's all I think is needed, but Matt might know otherwise.
[16:29:46] <linuxwolf> forwarding to all sending resources makes it more MUC-like
[16:30:32] <Kev> It does. It also potentially makes it *slightly* nicer for local history caching.
[16:30:46] <linuxwolf> that's what I was thinking
[16:30:46] <Kev> But it's pretty slight, I think, and the bandwidth cost isn't insignificant.
[16:30:54] <linuxwolf> true
[16:31:49] <linuxwolf> then again, if you're mobile, you're radio is already at full because you just sent something (-:
[16:32:30] <linuxwolf> and if compression is enabled, how much is that cost really?
[16:33:40] <linuxwolf> just playing devil's advocate here … I'm fine with it as-is, or changing it to every … I don't really care
[16:35:27] <Kev> Right.
[16:35:41] <Kev> I'm happy with as-is, at the moment. I don't think it hurts MAM.
[16:36:14] <Kev> I think having a MAM server send you a "Your last received id is" when you log out would probably be a better solution, if a solution is needed (I'm not convinced it is).
[16:37:00] <MattJ> So you think clients should drop local history?
[16:38:32] <Kev> I don't think I'm saying that.
[16:38:49] <Kev> Although I could be wrong :)
[16:39:07] <Kev> I think I'm saying that MAM+Carbons is sufficient already to get a complete local cache.
[16:39:25] <Kev> Or even a local cache where it is incomplete, but the gaps are known.
[16:39:33] <Kev> (And thus could be filled when the user wants history)
[17:01:22] *** linuxwolf shows as "online"
[17:08:33] *** linuxwolf shows as "away" and his status message is "stuffage"
[17:18:34] *** linuxwolf shows as "away" and his status message is "stuffage"
[17:38:29] *** linuxwolf shows as "away" and his status message is "stuffage"
[17:38:33] *** linuxwolf shows as "online"
[17:42:40] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[17:52:40] *** MattJ shows as "xa" and his status message is " (Not available as a result of being idle more than 15 min)"
[18:02:11] *** fippo has left the room
[18:38:55] *** linuxwolf shows as "away" and his status message is "stuffage"
[18:43:15] *** linuxwolf shows as "online"
[18:46:59] *** Kooda shows as "away"
[19:22:13] *** linuxwolf shows as "away" and his status message is "stuffage"
[19:25:53] *** linuxwolf shows as "online"
[20:27:26] *** linuxwolf shows as "away" and his status message is "stuffage"
[20:37:26] *** linuxwolf shows as "away" and his status message is "stuffage"
[20:48:43] *** linuxwolf shows as "away" and his status message is "stuffage"
[20:48:53] *** linuxwolf shows as "online"
[20:57:09] *** Kev shows as "away"
[21:03:03] *** MattJ shows as "online"
[21:24:02] *** linuxwolf shows as "away" and his status message is "stuffage"
[21:34:02] *** linuxwolf shows as "away" and his status message is "stuffage"
[21:42:49] *** linuxwolf shows as "away" and his status message is "stuffage"
[21:42:52] *** linuxwolf shows as "online"
[21:43:48] *** Kooda shows as "online"
[21:56:35] *** linuxwolf has left the room
[22:29:24] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[22:30:30] *** MattJ shows as "online"
[22:52:34] *** Kooda shows as "away"
[23:19:47] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[23:22:05] *** MattJ shows as "online"
[23:24:17] *** Tobias has left the room