XMPP Council - 2012-02-15

00:01:49 Tobias has left
07:55:46 Tobias has joined
12:36:31 Kev has left
13:44:47 bear has joined
13:45:01 bear has left
14:17:58 Kev I'm having a somewhat distracted day. I'm not intending going anywhere, but in case I fail to notice the time later, could someone please send me a message when the time comes.
14:20:37 Tobias sure
14:24:06 Kev Thanks.
15:39:46 stpeter has joined
15:40:40 stpeter has left
15:41:11 stpeter has joined
15:42:15 linuxwolf goes looking for his graphite-powered legacy input device
15:44:58 Kev Yees.
15:45:24 stpeter dents and tweets
15:48:49 Michael has joined
15:50:41 linuxwolf this is going to bug me all day
15:51:52 Kev On a yoghurt I'm about to eat (although it's a "0% fat" one, which seems to mean "tastes icky"): "suitable for vegetarians".
15:52:03 Hirotaka Sato has joined
15:52:12 Kev One assumes this is contrary to the usual bacon yoghurts, which aren't.
15:52:23 linuxwolf well, there's vegetarians and there's Vegerians
15:52:36 linuxwolf or vegans
15:53:07 linuxwolf which wouldn't eat yogurt if any part came from an animal is some form … such as milk
15:53:26 stpeter don't forget the fruitarians!
15:53:52 linuxwolf vegitarivores and meatarians
15:53:57 Kev linuxwolf: It doesn't claim to be suitable for vegans (which, given it's made from milk, would probably be difficult).
15:54:06 linuxwolf very true
15:54:33 linuxwolf I wonder if they removed all the bacteria … which wouldn't make it yogurt
15:54:48 Kev They certainly removed all the nice.
15:55:19 Kev I'm sure that when I was (much) younger, fruit yoghurts used to taste of fruit. Sometimes even the one advertised on the packaging.
15:55:24 linuxwolf 0% fat is almost never a good idea
15:55:47 Kev I didn't notice any fruit yoghurts that weren't fun-free :/
15:55:57 linuxwolf when we were younger, fruit yogurts actually contained fruit
15:56:15 linuxwolf now they have "natural and artificial flavors"
15:58:27 Kev I *like* cherries.
15:58:31 Kev I'm sure I do.
15:58:40 Kev They taste fruity and nice.
15:58:49 linuxwolf you're best bet is to get plain yogurt, add fruit, and blend
15:58:59 guusdk has joined
15:59:05 stpeter prefers plain, high-fat yoghurt
15:59:05 linuxwolf maybe some honey too
15:59:44 stpeter and how did we get on this topic? ;-)
15:59:49 Kev Also: Bacon.
15:59:56 Kev stpeter: I'm whining about eating a fun-free yoghurt.
16:00:13 linuxwolf now I'm hugry
16:00:20 guusdk hungry within a minute joining the xmpp council muc.
16:00:25 linuxwolf let's get this over with so I can address that hunger thing
16:00:25 Kev Yeah, I was until I tasted this yoghurt, too!
16:00:45 linuxwolf I think I'll have a ham-and-cheese panini
16:00:46 stpeter have we pinged Ralph and Matthew?
16:01:02 Kev I have (just)
16:01:02 ralphm has joined
16:01:05 linuxwolf just pinged Ralph
16:01:06 linuxwolf hehe
16:01:07 stpeter oh shoot, gotta join the IETF Tools Team call
16:01:18 Tobias pinged matt
16:01:40 Kev Righty.
16:01:41 MattJ has joined
16:01:43 Kev 1) Roll call
16:01:47 Kev I'm here!
16:01:54 ralphm AOL
16:01:58 linuxwolf presente
16:02:05 MattJ Here!
16:02:06 Tobias here
16:02:14 Kev Amazing.
16:02:18 Kev 2) Spec length
16:02:22 Kev What to do about -45 and -60?
16:02:22 MattJ Too long.
16:02:39 Kev XEP-0312: TL;DR
16:02:45 linuxwolf I doubt anyone will argue too short
16:02:57 MattJ Well there are obviously only two things we can do: split or remove
16:03:10 ralphm heh
16:03:12 Kev Right, so, I don't argue with splitting MUC into essentially two - Administration and Usage or something.
16:03:44 MattJ Makes sense
16:03:47 Kev Although I'm not sure what it buys us, really, other than two shorter specs.
16:04:00 Kev We want servers to implement all of it, regardless.
16:04:15 Kev I suppose clients could just implement the non-admin bits (as Swift did for a while).
16:04:18 linuxwolf I think we'd end up with some duplication, with regards to join/create
16:04:20 MattJ Well splitting MUC makes less sense for others, I think
16:04:30 MattJ *less sense than for others
16:04:49 ralphm I haven't really considered splitting MUC
16:04:51 MattJ OTOH I have a growing list of things I'd like to see removed from XEP-0060
16:05:00 ralphm For XEP-0060 there are a lot of optional features
16:05:06 ralphm that could be moved to their own spec
16:05:11 linuxwolf yeah, XEP-0060 could benefit from breakup
16:05:18 linuxwolf not sure about MUC right now
16:05:26 Kev Ok, so is it fair to say that rough consensus is that -45 should be left alone, wrt. splitting it?
16:05:27 MattJ I'm convinced there are a whole bunch of features in XEP-0060 that *nobody* is using
16:05:39 ralphm there you have some very basic use cases that you can build upon
16:06:08 Kev Splitting -60 seems fine to me, although I don't know it in enough depth to suggest where.
16:06:14 MattJ I think MUC isn't too bad
16:06:36 stpeter for MUC, I do think we could fairly easily split the dumb-client parts from the moderator/admin/owner use cases -- and *most* clients don't support any of the latter
16:06:36 MattJ We just need to be sure not to add to it
16:06:57 Tobias do you think the duplication would be much when splitting basic chat features and complex admin stuff for MUC?
16:07:07 MattJ I wouldn't be opposed to an admin/user split of the spec
16:07:17 Kev Tobias: Well, you've got room creation, kicking and things.
16:07:23 linuxwolf stpeter: probably, although some discussion in the "dumb-client" spec would need to talk about create in some referential manner
16:07:30 stpeter linuxwolf: for sure
16:07:32 Kev So a dumb client may not be able to kick, but should still know what being kicked looks like.
16:07:40 stpeter right
16:07:40 linuxwolf yeah
16:07:48 Tobias Kev, but these would only be added by the admin spec, wouldn't they...basic clients would still understand normal errors and such
16:07:49 ralphm sure, you need to discuss roles etc in the core spec
16:08:18 stpeter ralphm: true
16:08:29 Kev So, my rough stance on this is that I'm not opposed to a sensible split for -45 into dumb client and admin, but that I think getting such a split would be hard work that I'm not looking forward to having to review, and very much want to not have to do.
16:08:44 MattJ In fact the main advantage I see of splitting 45 as it stands is that we can experiment with e.g. defining other protocols for admin of a room/service
16:09:00 stpeter so I think it might be useful to take a look at 45 and see what it would look like with the moderator/admin/owner stuff moved to a separate spec
16:09:11 ralphm nod
16:09:15 linuxwolf sure
16:09:19 stpeter MattJ: yes, ad-hoc commands in MUC is on my list :)
16:09:24 MattJ Mine too
16:09:27 MattJ Below MAM :)
16:09:29 stpeter heh
16:09:47 linuxwolf changes 0.25USD to hildjj
16:09:51 stpeter my workflow is slowing down with the impending end of my IESG term, so I'll have more time soon
16:09:52 Kev Ok, so, pubsub everyone's happy with being split.
16:09:53 linuxwolf s/changes/charges
16:10:01 linuxwolf Kev: definitely
16:10:10 Kev I don't think we need to discuss this further then, do we?
16:10:30 linuxwolf not presently
16:10:30 stpeter Kev: I can take a quick/rough pass at 45
16:10:36 Kev I'll take -45 changes as they come, but I have assorted reservations that I'm happy to have removed by seeing something that works.
16:10:37 stpeter Kev: I think it would be worth discussing 60
16:10:50 stpeter clearly there's a lot in 60
16:10:53 Kev stpeter: Now, or when we have some sort of split pencilled up so we can discuss it?
16:11:13 stpeter well, have people looked at 60 and thought about how we might split it up?
16:11:16 stpeter same kind of thing?
16:11:20 linuxwolf how about we start with everyone's list of "please remove"
16:11:22 ralphm a bit
16:11:33 ralphm most of the configuration bits could be moved out
16:11:34 MattJ I'm still in the process of XEP-0060 review
16:11:36 stpeter i.e., admin/owner/etc. vs mere publish and subscribe?
16:11:37 linuxwolf I've thought about it, but haven't gone into much detail
16:11:37 Kev I haven't, I think everyone else here has a better grasp of pubsub than I do.
16:11:47 ralphm for nodes, subscriptions and pre-conditions
16:11:53 stpeter I think that pub and sub are pretty simple, really
16:11:56 MattJ so I'll probably have a better list when I submit my feedback to the list
16:11:57 ralphm stpeter: yeah
16:12:01 stpeter ok
16:12:11 stpeter so it sounds like we can circle back on this topic in a few weeks
16:12:17 linuxwolf /nod
16:12:18 stpeter and perhaps start a thread on the pubsub@ list?
16:12:23 linuxwolf +1
16:12:31 stpeter I can start a thread on muc@ when I take a rough pass at the split
16:12:34 Kev 3) Last call on XEP-0267
16:12:37 MattJ even for subscriptions... I think things like "multiple subscriptions" should be (re)moved (or at least fixed)
16:12:39 ralphm I'd very much like to see XEP-0060 be a very stripped down spec that explains the core use case, with references to other specs for enhanced behaviour
16:12:57 MattJ +100
16:13:02 Tobias +1
16:13:04 ralphm I'll have a pass at XEP-0060 and make a list
16:13:27 stpeter ralphm: super
16:13:30 Kev Do we have implementations of 267 deployed/used now?
16:13:31 linuxwolf garzie
16:13:37 linuxwolf grazie even
16:13:38 linuxwolf gah
16:13:58 linuxwolf Kev: I don't know
16:14:10 stpeter Kev: there's an implementation in Prosody (experimental) but I've not yet had time to deploy it at xmpp.net
16:14:22 stpeter I'd be happy to wait
16:14:25 Kev I'm not opposed to Last Calling it I guess, but I'm unlikely to want to push it to Draft.
16:14:28 MattJ and I haven't looked at it or tested it yet
16:14:39 stpeter right
16:14:54 ralphm two would be nice
16:14:54 stpeter how about I test it out at xmpp.net first
16:15:03 MattJ wfm
16:15:08 linuxwolf +1
16:15:22 Tobias sounds like a plan
16:15:24 stpeter notes that we might need to think about this non-requirement requirement for multiple implementations and deployment experience before pushing something to Draft
16:15:37 Kev Ok. I may even have comments about it, I think.
16:16:23 ralphm stpeter: I think multiple implementations is still a great thing to have
16:16:45 Kev I treat Experimental as "Not obivously broken" and Draft as "The way we have consensus on solving this", mostly (and Final as "done deal").
16:16:59 stpeter ralphm: always, the question is: is that a requirement for advancement? XEP-0001 doesn't say that
16:17:12 Kev I think the current state of 267 is that we don't know that this is the right way to do this as we've not tried it.
16:17:14 stpeter but that's a topic for a future meeting
16:17:19 stpeter Kev: probably
16:17:29 Kev Or, to phrase it slightly better, it can't stop being Experimental until there's been an experiment.
16:17:37 linuxwolf thought experiments can go far, but maybe not far enough
16:17:45 ralphm right, so the non-requirement kinda makes it easier to assert if it is the right way to do a thing
16:18:20 stpeter anyway
16:18:26 stpeter I think we have a path for 267
16:18:29 Kev We've explicitly made the bar to Experimental very low in recentish meetings.
16:18:35 stpeter more experimentation on the way :)
16:18:49 linuxwolf the bar as been lower (-:
16:18:50 MattJ Kev, *ahem* :)
16:18:58 ralphm Kev: I've never lowered the bar, I don't think it should be very high at all
16:19:04 ralphm but draft should be
16:19:10 linuxwolf I'm with ralphm
16:19:31 Kev Right, that's what I said, isn't it?
16:19:41 Kev We've discussed this recently and agreed that the bar to Experimental should be very low.
16:19:49 ralphm right
16:19:55 Kev It doesn't imply that Draft should be that low.
16:19:58 linuxwolf yes, but some of us started very low, and others needed to move (-:
16:20:01 Astro has joined
16:20:04 ralphm so I am again arguing for actual implementations (plural) to move forward
16:20:13 linuxwolf anyway, we're in general agreement, so let's move on (-:
16:20:25 Kev I don't need multiple implementations to persuade me it's Draft ready - but it's the easiest way to persuade me.
16:20:27 Kev linuxwolf: right.
16:20:39 Kev 4) Last call on XEP-0297
16:20:57 MattJ +1
16:21:07 linuxwolf are there multiple implementations?
16:21:13 stpeter (BTW, a quick visual comparison of http://xmpp.org/extensions/xep-0045.html#moderator and http://xmpp.org/extensions/xep-0045.html#statuscodes indicates that we'd cut about 40% of XEP-0045 by moving the moderator/admin/owner use cases)
16:21:34 Tobias i don't know of a single implementation
16:21:41 Kev linuxwolf: I think there are, actually, aren't there?
16:21:41 stpeter (but I'll post to muc@ about that....)
16:21:42 linuxwolf MattJ has one for Prosody
16:21:46 linuxwolf right?
16:21:49 MattJ and a client one in Verse
16:21:50 Tobias ah...ok
16:21:53 Kev As the BC guys are using MAM, which uses it.
16:21:54 MattJ Zash wrote both
16:21:59 linuxwolf /-:
16:22:02 Tobias nice
16:22:08 MattJ and yes, BuddyCloud
16:22:14 linuxwolf ok then
16:22:21 linuxwolf +1 for last call
16:22:47 stpeter notes that we'll need 297 for Carbons
16:22:51 Kev Right.
16:22:53 linuxwolf I'll make my comments during LC
16:22:55 Kev I'm ok with Last Calling this.
16:22:57 stpeter that's why I'm interested in seeing this done
16:22:59 linuxwolf which are related to Carbons
16:23:01 ralphm http://archive.jabber.org/docs/proto-draft/envelope.html
16:23:02 Tobias i gave it a read earlier and it made sense and sounds logical...so +1 for this
16:23:16 ralphm was wat it reminds me off, and XEP-0033's claim that it supersedes that
16:23:46 MattJ gives ralphm bonus points for citing archive.jabber.org
16:24:02 ralphm Heh
16:24:17 ralphm I've been around for a bit I suppose
16:24:21 linuxwolf (-:
16:24:32 linuxwolf I think I actually tried to implement that, too
16:24:41 Kev I think we need -297 LC votes from Ralph and Tobias?
16:24:58 ralphm I think, contrairy to its claim, that jabber:x:envelope might actually have implementation
16:25:06 ralphm that said, I'm +1 on LC
16:25:09 Tobias i'Ve only implemented / used XEP-0033 some years ago
16:25:20 Tobias Kev, see 16:22
16:25:23 Tobias +1
16:25:29 ralphm this spec is richer and more well defined
16:25:35 Kev Tobias: Ta.
16:25:45 Kev Ok, moving ever onwarsd.
16:25:47 ralphm especially the security considerations
16:25:49 Kev Also, onwards.
16:25:58 Kev 5) http://gitorious.org/xmpp/xmpp/blobs/master/extensions/xep-0166.xml#line1399
16:26:04 linuxwolf ralphm: envelope was only meant to be the addressing bits, −297 really does wrap another (message) stanza
16:26:08 Kev Is that line redundant?
16:26:19 Kev It looks it to me.
16:26:58 ralphm linuxwolf: yeah, I suppose. It's just juggling elements :-)
16:27:19 Tobias Kev, where is the same already said? or is the behavior described common sense?
16:27:24 ralphm linuxwolf: one might argue that embedding a message in another element makes backwards compatibility harder
16:27:30 Kev Tobias: There was a thread about this on the mailing list.
16:27:44 MattJ I missed the thread
16:27:45 Kev I wonder if I can find it.
16:27:56 Kev But the summary was that the error it refers to doesn't exist.
16:27:58 linuxwolf ralphm: that's what explicit namespace declarations are for (-:
16:28:01 MattJ so am lacking any context or opinion (it seems sensible)
16:28:10 linuxwolf I don't recall that jingle thread
16:28:13 stpeter MattJ: we discussed this on the jingle@ list
16:28:13 ralphm linuxwolf: as an aside, Blain Cook asserted the same thing about Atom payloads and pubsub events.
16:28:14 Kev Nor is there anything in 166 that talks about encrypted streams to use this on.
16:28:17 stpeter and on standards@
16:28:34 linuxwolf checks his subscriptions
16:28:38 stpeter wel
16:28:40 ralphm linuxwolf: in that he'd like it better if the payload was outside the pubsub element
16:28:40 stpeter actually
16:28:41 stpeter http://mail.jabber.org/pipermail/standards/2012-January/025717.html
16:28:44 stpeter that's the start of the thread
16:28:55 stpeter so I only forwarded my conclusions to the jingle@ list
16:28:56 Kev That's the one, thanks Peter.
16:29:03 stpeter anyway, no hurry
16:29:07 stpeter we can discuss next week
16:29:09 stpeter or on the list
16:29:11 linuxwolf yeah
16:29:17 linuxwolf I need to rebuild my context
16:29:25 Kev Ok.
16:29:30 Kev 6) Date of next meeting.
16:29:30 linuxwolf it was sent on my b-day … I ignored a lot of email that day (-:
16:29:34 Kev SBTSBC?
16:29:38 linuxwolf +1
16:29:45 MattJ +1
16:29:54 stpeter heh
16:30:03 Tobias looks up what it means
16:30:05 stpeter wfm
16:30:13 linuxwolf Same Bat Time Same Bat Channel
16:30:13 stpeter I assume it's same bat time, same bat channel
16:30:16 Kev Tobias: I don't *think* it's an established acronym, just one I use.
16:30:22 Kev linuxwolf: Right.
16:30:25 ralphm I should be
16:30:27 ralphm it
16:30:28 linuxwolf Kev likes to channel Adam West
16:30:31 Tobias ah...k
16:30:37 Tobias +1 then
16:30:46 Kev Tobias: We went through a period where I'd say "same bat time same bat channel" for this agenda item. So I started abbreviating.
16:31:06 Kev 7) AOB?
16:31:06 linuxwolf s/Adam West/William Dozier/
16:31:44 linuxwolf no AOB from me
16:32:07 MattJ nack
16:32:13 Kev Nor anyone else, it seems.
16:32:17 Kev Ok then.
16:32:20 ralphm yay
16:32:21 Kev Thanks all :)
16:32:26 MattJ Thanks
16:32:32 Kev gavels the hammer. Or something.
16:33:19 linuxwolf goes back to lamenting the loss of his pencil
16:33:46 linuxwolf now I don't know what to do when I'm pondering
16:34:17 Kev I have some almost-yoghurt you could eat!
16:34:22 stpeter heh
16:34:29 linuxwolf I think I might have a fancy wood pencil
16:34:56 linuxwolf aha!
16:35:00 linuxwolf found my pencil bag
16:35:02 stpeter linuxwolf: now that I'm using PGP more often, you and I might want to do a keysigning sometime ;-)
16:35:15 linuxwolf that would require me to use PGP d-:
16:35:30 stpeter linuxwolf: you usually sign your @cisco mail, don't you?
16:35:36 linuxwolf I do
16:35:42 linuxwolf CMS
16:36:02 stpeter oh
16:36:27 stpeter sees his inbox bump up over 30 messages and starts to scrub it
16:36:41 linuxwolf (-:
16:37:02 Astro did I read channels? buddycloud channels?
16:38:11 ralphm Astro: bat channels
16:38:40 stpeter :)
16:43:16 linuxwolf looks at using PGP
16:44:38 linuxwolf I can get my PGP key printed on my business cards, but not my cert
16:44:40 stpeter linuxwolf: I go back and forth between PGP, S/MIME, and nothing
16:45:25 stpeter linuxwolf: however, in my experience very very few people us S/MIME, whereas PGP is mildly useful for sending messages encrypted
16:45:55 stpeter I even use openpgp for IM messages at times (at least with migri, who helps out with xmpp.org list administration)
16:46:36 stpeter tests out the beta version of the IETF datatracker
16:53:28 linuxwolf has left
16:53:36 linuxwolf has joined
17:01:06 Michael has left
17:17:12 Astro has left
17:21:17 guusdk has left
17:23:48 Hirotaka Sato has left
17:51:04 stpeter has left
18:12:41 stpeter has joined
19:37:24 Astro has joined
19:50:47 linuxwolf has left
19:51:04 Astro has joined
19:56:13 ralphm has left
19:57:54 linuxwolf has joined
20:51:29 Astro has joined
22:31:05 linuxwolf has left
22:54:38 linuxwolf has joined
23:12:36 linuxwolf has left
23:43:06 Astro has left