XMPP Council
Wednesday, 3 December 2008< ^ >
Kev has set the subject to: http://xmpp.org/council/agendas/2008-11-26.html
Room Configuration

[13:01:59] Kev joins the room
[13:04:22] Kev has set the subject to: http://xmpp.org/council/agendas/2008-12-03.html
[13:24:32] jack joins the room
[13:33:32] MattJ joins the room
[13:48:41] ralphm joins the room
[13:51:44] ralphm waves
[13:52:08] <Kev> he
[13:52:08] <Kev> *hey
[13:57:55] psa joins the room
[13:59:03] <psa> howdy
[13:59:14] <psa> just finished my sound check with Randal
[13:59:18] <psa> so I'm all set :)
[14:00:26] dwd joins the room
[14:00:27] ralphm_ joins the room
[14:00:33] <Kev> all here \o/
[14:00:36] <ralphm_> hrm. OpenFire troubles
[14:00:49] <dwd> Not sure for how long, I'm feeling very bad indeed.
[14:00:58] <psa> ralphm: not using python xmpp daemon?
[14:01:00] <psa> dwd: :(
[14:01:07] <Kev> dwd: don't feel you have to stay if you want to catch some shuteye before heckling Peter
[14:01:15] <Kev> any bashing of the agenda?
[14:01:22] <dwd> Kev: It's the only reason I'm awake, of course.
[14:01:46] <psa> Kev: no bashing here
[14:02:08] <psa> Kev: we have http://xmpp.org/extensions/inbox/sasl-external-cert-handling.html and http://xmpp.org/extensions/inbox/security-labels.html but I haven't read them carefully yet
[14:02:28] <psa> (just arrived today, or processed today by our inefficient Editor)
[14:02:29] <Kev> I looked at security labels a few weeks ago, but then forgot all about it
[14:02:35] <Kev> so let's leave those for next week :)
[14:02:48] ralphm leaves the room
[14:02:50] <dwd> Unsurprisingly, I've seen the sec labels one before...
[14:03:04] <Kev> so
[14:03:11] <Kev> what do we need to say about 85? :)
[14:03:31] <ralphm_> psa: heh. That is nowhere near completion.
[14:04:04] <psa> well, there seems to be a bit of confusion about threads, but there always is because we've never defined threads very clearly -- I think the 85 text about threads probably belongs in XEP-0201 and that we need to clean up 201
[14:04:25] <ralphm_> right
[14:04:56] <Kev> I really dislike telling people that a session's over when you close the window
[14:05:12] <Kev> because that's an entirely arbitrary decision made based on how many text editor windows I have open
[14:05:14] <psa> so at some point (preferably before we push rfc3921bis forward) we need to clean up 201
[14:05:18] <Kev> but I think I've said this before :)
[14:06:04] <ralphm_> Kev: agreed. I often close my chat windows, even though I am still hoping to continue conversations when my conversation partner replies
[14:06:15] <psa> agreed here too
[14:06:22] <MattJ> That's why it should be optional
[14:06:24] waqas joins the room
[14:06:30] <dwd> Whereas I'm the opposite - I leave mine open long after I assume the conversation to be over.
[14:06:36] <Kev> dwd: I do that, too
[14:06:42] <psa> it depends
[14:06:46] <Kev> it's non-deterministic :)
[14:07:09] <MattJ> None of us here are average users :)
[14:07:13] <psa> so I don't think it's up to the spec to legislate user behavior, or even necessarily client handling of that user behavior
[14:07:15] <Kev> MattJ: who is?
[14:07:31] <jack> i agree with peter
[14:07:33] <MattJ> Kev, that's why it should be optional :)
[14:07:45] <dwd> But it *is* optional, surely?
[14:07:49] <MattJ> A timeout isn't enough to signal the end of a conversation either
[14:08:01] <dwd> There's all that stuff about the triggers being suggestions. In italics, even.
[14:08:04] <Kev> dwd: 85 suggests that a session is over when a user closes a window
[14:08:07] <psa> dwd: it isn'teven OPTIONAL, the spec just talks about possible suggestions
[14:08:21] <Kev> if we suggest it, people will do it
[14:08:26] <Kev> otherwise why would we suggest it? :)
[14:08:28] <MattJ> People already do it
[14:08:34] <dwd> I suggest people give me loads of money.
[14:09:06] <MattJ> <silence>
[14:09:08] <psa> heh
[14:09:19] <dwd> Kev: See? Doesn't always work.
[14:09:22] <psa> well, we could remove all suggestions and just leave it all up to the implementor
[14:09:26] remko joins the room
[14:09:36] psa never knows whether it is properly implementer or implementor
[14:10:33] <dwd> I think the suggestions stand, but if people are confused, perhaps an additional phrase such as "These suggestions are often not appropriate to implement blindly; implementors SHOULD carefully consider how to generate the state changes."
[14:10:56] <Kev> well
[14:11:03] <Kev> what do we need to discuss and/or decide?
[14:11:29] <psa> not much
[14:11:39] <ralphm_> http://en.wiktionary.org/wiki/-or
[14:11:55] <psa> perhaps just adding something along the lines of what dwd says
[14:12:04] <psa> I can wordsmith and post to the list
[14:12:08] dwd is always right. <-- Reminder.
[14:12:10] <ralphm_> nod
[14:12:15] <psa> hehehe
[14:12:18] <psa> dwd: noted :)
[14:12:19] <ralphm_> dwd: and when not, see above, no?
[14:12:20] <psa> ok
[14:12:26] <psa> so moving along then I suppose
[14:12:59] <Kev> wfm
[14:13:05] <Kev> message mine-ing
[14:13:12] <Kev> I think I'm slowly seeing why this came about
[14:13:14] <dwd> Release Mines!
[14:13:24] <Kev> dwd: yes, I was proud of that :)
[14:13:33] <remko> :)
[14:13:40] <dwd> Yeah, I get the use-case, and it's real.
[14:13:54] <psa> I don't yet completely grok dwd's suggestion
[14:13:57] <Kev> it's only the worst case (leaving a session) that I still don't quite understand
[14:14:16] <psa> Kev: I think that transferring a session is a different problem
[14:14:21] <Kev> psa: I'm not sure it is
[14:14:31] <Kev> because
[14:14:56] <Kev> you only need mine if your sessions aren't in a coherent state to start with (the one you're using being the highest priority).
[14:15:00] <dwd> psa: Put it this way - does your client flash, bounce up and down, or ding when a new message comes in? It's just doing that over the network to your other clients so they can show the pending message, too.
[14:15:08] <Kev> That only happens if you're not transferring priority at the end of sessions
[14:15:26] <Kev> I think the two things are tied
[14:16:00] <dwd> Kev: No, even if your priorities are perfect, then because clients "lock in" to a full jid, new messages still come in on the wrong session.
[14:16:19] <Kev> dwd: yes, existing sessions are still a problem
[14:16:24] <Kev> but /new/ sessions aren't
[14:16:36] <Kev> I'm not proposing that it's a problem solved with priorities
[14:16:39] <dwd> Kev: Now, we could say that the remote client needs upgrading, too, but we're already in forklift territory, and that would leave me out of adjectives.
[14:16:48] <Kev> what I'm still trying to understand is what Mine does that priorities don't atm
[14:17:02] <psa> dwd: right, so you'd need a rule that if you receive any presence updates from your contact then send to the bare JID again (or somesuch)
[14:17:04] <dwd> Kev: They handle the new chat session case.
[14:17:17] <Kev> yes, but priorities manage that much
[14:17:24] <dwd> psa: That being the bigger-than-forklift case I'm worried about.
[14:17:46] <psa> Kev: not really, because people don't manage their priorities and you have the problem of the other client (which you didn't code up and therefore it sucks)
[14:18:00] <dwd> Kev: Well, no, because you need this case where you get up, rely on auto-away, and get a message or two before it kicks in.
[14:18:15] <Kev> dwd: but you have that problem with mine, as it stands, as well, afaics
[14:18:38] <dwd> Kev: Not on new sessions, because all clients get the message, and can claim responsibility for it.
[14:19:05] <psa> right
[14:19:17] <dwd> Kev: On old sessions, where a full jid is used as the to, then Mines don't help.
[14:19:28] <Kev> ok, agreed
[14:19:29] ralphm joins the room
[14:19:32] <dwd> Kev: Because you don't get that all-resource-broadcast.
[14:19:47] <Kev> but I was assuming we don't do the auto-away thing, but rather a 'release mines' type button
[14:19:57] <ralphm_> and it is proper to use full JIDs once you get a reply, right?
[14:20:04] <dwd> Kev: But then you may as well just get priorities right.
[14:20:05] <Kev> ralphm_: right
[14:20:12] <dwd> ralphm: That's our assumption.
[14:20:15] <Kev> dwd: and we're back to question one
[14:20:45] <ralphm_> dwd: but even if you get priorities right in one client, that might not fix your others
[14:21:04] <Kev> ralphm_: right, but Mine requires universal support, too
[14:21:10] <ralphm_> true
[14:21:25] <psa> ralphm: yes, but in the session transfer case you might get back to your desk after chatting on your mobile and now you want to seamlessly start chatting from your laptop -- I think that problem is interesting but out of scope for MINE, unless we want a more general solution
[14:21:31] <dwd> ralphm: Right. So ideally, we need a protocol that solves the case where just some of your clients, *or* just your server, needs to know how to play the game.
[14:21:51] <dwd> psa: I think the session transfer case *is* the general case.
[14:22:17] <dwd> psa: That came out all wrong. :-) It's the case we need to solve, because it'll be the far more common case.
[14:23:04] <psa> maybe
[14:23:11] <psa> I'm really not sure what the general case is
[14:23:17] <ralphm_> worst case, you don't get any presence changes on any client, right?
[14:23:24] <psa> correct
[14:23:29] <dwd> ralphm: Right.
[14:23:34] <ralphm_> so a server doesn't know anything
[14:23:58] <Kev> if the problem we're solving is multiple clients and not knowing where to send something, then I think session transfer is a fairly big part of that.
[14:24:02] <ralphm_> except maybe you started sending messages from another client
[14:24:09] <psa> the only thing the server knows is that you've got multiple resources -- it doesn't know anything about your personal context in relation to those resources
[14:24:15] <dwd> The other thing that occurs to me, sneakily, is that if you mobile client sticks at low priority deliberately, and listens for "I got messages" updates from other clients, then non-essential messages won't take up so much bandwidth. But I think that's probably a red herring in practise.
[14:24:45] <dwd> (In as much as it's more packets for most cases, I suspect)
[14:24:53] <Kev> I wonder if mine should only be used between the same resource
[14:25:04] <dwd> Same resource?
[14:25:08] <Kev> priority
[14:25:15] <Kev> that is, we recommend that everyone uses priority 10
[14:25:19] <psa> I'm not convinced that we have enough knowledge about how clients are used in the real world to solve all these cases
[14:25:29] <Kev> and if you use other priorities, then you get current behaviour
[14:25:42] <ralphm_> I think google only sends to more than one resource if the highest priority occurs more than once
[14:25:42] <psa> why not recommend that everyone use priority = 0 and then we can ignore priorities :)
[14:25:50] <Kev> I'm thinking of a service like identica, that has multiple online resources, and an incoming session is typically one message
[14:26:07] <psa> ralphm: oh I thought that Google sent to all resources, no matter what the priority
[14:26:17] <ralphm_> Kev: I consider identi.ca broken in that respect
[14:26:21] <Kev> psa: that's pretty much what I was suggesting, yes
[14:26:32] <dwd> Kev: Not so, I suspect I'm not alone in letting identi.ca open a window, and simply replying to messages as they fly in, so I'm always locked to the "wrong" resource.
[14:26:45] <psa> I think that perhaps priorities were a first attempt to solve the problem but that they've outlived their usefulness
[14:26:56] <psa> or that they don't really solve the problem
[14:27:12] <Kev> well, asking a silly question
[14:27:14] <dwd> I think priorities are useful, actually, and that broadcast is a hammer of a solution.
[14:27:18] <ralphm_> psa: they at least solve it for new sessions
[14:27:29] <Kev> this is a very simple solution, tell me what's wrong with it, and let's go from there
[14:27:41] <ralphm_> when your priorities are set in a representative way
[14:27:43] <psa> ralphm: no they don't, because people don't know how to manage their priorities
[14:27:48] <psa> when, yes
[14:27:56] <Kev> your client has an "I'm here" button that automatically reduces other resources priorities, raises its own, and gets all outstanding messages
[14:27:59] <psa> but I would argue that rarely are they set correctly
[14:28:02] <Kev> when you move, you click that
[14:28:10] <dwd> I think there's two areas we could improve - firstly, dealing with the situation where priorities go wrong, and secondly, making it much easier to manage priorities.
[14:28:29] <ralphm_> Kev: except who clicks that?
[14:28:36] <Kev> the user once they move to a new client
[14:28:37] <psa> Kev: I think the idea is that the user shouldn't even have to click I'm here -- magic should happen when they pick up their mobile or sit down at their laptop or whatever
[14:28:45] <psa> Kev: it'll never happen
[14:28:48] <Kev> well
[14:28:56] <Kev> you need /a/ trigger, whichever method you use
[14:28:56] <psa> the most natural thing is for me to reply from whatever device I have to hand
[14:28:57] <dwd> psa: Right - but that's actually quite easy, and getting easier.
[14:29:07] <psa> and then you lock onto that device
[14:29:07] <ralphm_> Kev: I consider myself a power user, and I wouldn't click the button
[14:29:08] <dwd> psa: Modern mobiles can tell quite easily when you're moving.
[14:29:10] <Kev> in Mine you need an 'I'm here' trigger too
[14:29:17] <Kev> ralphm: it doesn't need to be a literal button
[14:29:23] <Kev> just an event the client triggers when it discovers you're there
[14:29:30] <ralphm_> ah
[14:29:32] <ralphm_> sure
[14:29:36] <psa> then we need to figure out transfer, but for the new session use case I think mine or something like that works just fine
[14:29:52] <dwd> psa: And mouse-movement detection to stop the auto-away has been about so long we know that bit works. It's the actual going away that's broken.
[14:30:24] <psa> inviting hilddj
[14:30:27] <psa> er
[14:30:27] <psa> hildjj
[14:30:27] <ralphm_> transfer would likely involve server side archiving?
[14:30:31] jhildebrand joins the room
[14:30:38] <Kev> hi Joe
[14:30:44] <dwd> ralphm: No, I think transfer can be done client-client.
[14:30:51] <dwd> Hey Joe.
[14:31:00] <jhildebrand> hey
[14:31:02] <Kev> ralphm_: we already do transfer in RC
[14:31:22] <ralphm> RC?
[14:31:24] <Kev> Joe: trying to attack all the edge cases of Mine atm
[14:31:29] <jhildebrand> nod.
[14:31:29] <dwd> Kev: Fairly coarse, but yes.
[14:31:32] <Kev> ralphm: Remote Controlling Clients
[14:31:36] <jhildebrand> 146.
[14:31:39] <ralphm> Kev: oh, sure
[14:33:12] <Kev> jhildebrand: currently wondering how much we already have that we could reuse
[14:34:03] <jhildebrand> if you use gtalk, you have everything you need but a way to clean up the shards.
[14:34:04] <Kev> I'm not sure how far short we come with an automatic presence/forward shuffle performed when a client discovers the user's there
[14:34:16] <jhildebrand> ew.
[14:34:26] <dwd> Kev: Still short - we need to cope with clients that remain locked in.
[14:34:43] <Kev> dwd: yes, so we need a transfer notice
[14:34:48] psa loves the word "shard"
[14:34:58] <ralphm> Kev: if I understood you correctly, you are saying the 'signal' to say "I'm here" is setting the priority high and then ordering other clients to lower theirs?
[14:35:07] <jhildebrand> Kev: do you mean instead of mine, or in addition to?
[14:35:17] <Kev> ralphm: I'm not proposing anything at the moment, just thinking out loud
[14:35:23] <ralphm> nod
[14:35:28] <Kev> jhildebrand: at the moment I'm wondering about instead of
[14:35:37] <ralphm> jhildebrand: I think we're trying a renewed look at the problem space
[14:36:02] <psa> I don't think priority management is a viable approach because both the clients and the users will get it wrong
[14:36:03] <dwd> jhildebrand: Don't get me wrong, now that I understand the nature of the problem you're addressing, I think it needs addressing. Just trying to figure out how.
[14:36:09] <jhildebrand> k.
[14:36:25] <jhildebrand> i'm against making the clients very complex to deal with this issue.
[14:36:28] <Kev> psa: with the out loud thoughts I'm having, the users don't touch it, and the clients can be XEP-mandated
[14:36:29] <ralphm> psa: that might go for mine-ing, too, no?
[14:36:42] <Kev> jhildebrand: +1 on Dave's sentiment, and on that
[14:37:03] <Kev> psa: if you think clients can get it wrong once we spec it, then they could get mine wrong, too
[14:37:20] <dwd> ralphm: I don't think so, I think it just depends on a forklift of the entire receiving infrastructure - the server plus every client you use.
[14:37:28] <Kev> the presence dance would be much less verbose if you assume that session transfer is less common than session creation
[14:37:43] <Kev> dwd: in the resource dance, do you even need server changes?
[14:38:11] <dwd> In principle, no. Nor in the "broadcast client message pending state to other resources" case, I think.
[14:38:33] <jhildebrand> are you trying to achieve this without server changes?
[14:38:33] linuxwolf joins the room
[14:38:44] <psa> hi linuxwolf
[14:38:54] <linuxwolf> hello
[14:39:01] <dwd> I quite like the automatic prority changing, because in principle, an "activated" client just raises its priority above all other extant resources.
[14:39:01] <psa> linuxwolf: we're chatting about mine
[14:39:13] <linuxwolf> right...catching up
[14:39:16] <jhildebrand> dwd: i hate priorities, in all of their forms but -1.
[14:39:29] psa ponders
[14:39:33] <dwd> jhildebrand: Sure, but if they're hidden from the user, they might be useful.
[14:39:34] <Kev> jhildebrand: what I'm thinking at the moment is quite simple client side, and requires no server change. When a client detects the user is there, it sends a Here stanza that causes it to receive outstanding messages, and go to the head of the priority stack. Clients forwarding messages also send a session forward notif to their contacts in sessions. It also addresses the case that mine doesn't, which is a new client joining the party.
[14:39:41] <Kev> dwd: what was the 'no' to?
[14:40:06] <psa> linuxwolf: http://logs.jabber.org/council@conference.jabber.org/2008-12-03.html
[14:40:10] <dwd> Kev: [20:37:43] Kev> dwd: in the resource dance, do you even need server changes?
[14:40:13] <dwd> I think :-)
[14:40:18] <Kev> dwd: ok, agreed :)
[14:40:38] <jhildebrand> Kev: what form does the Here stanza take?
[14:40:44] <dwd> Kev: But priority waltzing doesn't solve the errant-lock-in case.
[14:41:03] <Kev> jhildebrand: in principle, it could be a pair of 146 requests
[14:41:16] <Kev> dwd: "Clients forwarding messages also send a session forward notif to their contacts in sessions."
[14:41:19] <jhildebrand> how do you notify *all* of your resources? one request to each?
[14:41:27] <jhildebrand> race.
[14:42:01] <Kev> jhildebrand: so we need a 'send to all my online resources' option - like headline.
[14:42:05] <dwd> jhildebrand: Technically, yes. But it's not really a race we care about.
[14:42:06] <jhildebrand> Changing priorities in "real" presence is a non-starter for me. having to re-broadcast all of those presence changes is a huge scale lose.
[14:42:18] <jhildebrand> Kev: or like Mine mandates.
[14:42:26] <Kev> yes
[14:42:46] dwd had forgotten we could use headline.
[14:42:59] <jhildebrand> dwd: we still have to change the definition of headline first.
[14:43:00] <ralphm> also, if you take top priority, and an non-updated client (like Gajim) raises its priority at some point, it might or might not be above the taken priority. Not sure how that'd work
[14:43:09] <Kev> in principle, if we did this, we wouldn't need to send priorityacross the network anymore
[14:43:16] <Kev> but that's maybe not relevant
[14:43:27] <psa> Kev: I think it is relevant
[14:43:31] <dwd> ralphm: You re-raise yours.
[14:43:41] <jhildebrand> Priority Fight!
[14:43:47] <psa> I'll see your 50 and raise you 10!
[14:43:48] <ralphm> what jhildebrand says
[14:43:53] <Kev> The only rule about priority is that there is no priority
[14:43:55] <dwd> jhildebrand: Only if two clients think the user is present.
[14:44:01] <ralphm> and also, you don't know which is currently active
[14:44:28] <Kev> you don't get that fight if both clients implement XEP-Here
[14:44:42] <jhildebrand> dwd: how does my blackberry know that i'm not present? it's still on my hip, as far as it's concerned.
[14:45:02] <Kev> and if you have a client that doesn't support it, but is set to always beat any other priority, you already have problems
[14:45:08] <Kev> jhildebrand: it doesn't need to know you're not there
[14:45:09] <dwd> jhildebrand: As I hinted earlier, mobile devices seem good at spotting their own mocement these days.
[14:45:13] <Kev> it only needs to know you /are/ there
[14:45:31] <ralphm> Kev: I mentioned non-updated client, meaning existing with no new stuff
[14:45:45] <Kev> ralphm: right - that's not a problem
[14:46:21] <Kev> ralphm: as dwd says, you raise your priority above it. An existing client won't have auto-raise-priority-above-all-others-regardless brokenness
[14:46:31] <ralphm> Kev: ah
[14:46:45] <jhildebrand> repeat: changing "real" presence priority is a non-started from a scale perspective.
[14:46:54] <Kev> jhildebrand: see my earlier priority broadcast comment
[14:46:55] <jhildebrand> non-starter, even.
[14:47:11] <jhildebrand> if it's going to be something different, it should be a new protocol.
[14:47:35] <ralphm> but jhildebrand brings up an interesting thing. If I use my current gajim and mobile client, I set the mobile client to a fixed priority between 40 and 50, which makes it top priority when gajim decides to auto-away. I'm not sure how that works in Kev's scheme
[14:47:53] <psa> jhildebrand: yes I think that using directed presence to myself is potentially problematic because then my personal presence will get out of sync with my public presence
[14:48:17] <jhildebrand> psa: as well, unless you direct to all of your resources, i bet most existing servers don't handle that correctly.
[14:48:24] <psa> so just set all priorities to 128 and be done with it :)
[14:48:40] <psa> jhildebrand: probably not
[14:48:40] <Kev> ok
[14:48:42] <ralphm> maybe broadcasting isn't all that bad
[14:48:47] <ralphm> :-/
[14:49:02] <Kev> how about I make a post to standards that I try to make coherent about this alternative approach
[14:49:07] <psa> I think servers will have to change something regardless of what we do, either handling of directed presence to myself or handling of headline messages
[14:49:13] <Kev> and we can see where it falls short when we're not talking across each other :)
[14:49:17] <psa> +1 to coherence :)
[14:49:41] <jack> +1 for move to the list
[14:49:42] <jhildebrand> if the server has to be modified anyway, i assert that Mine is identical to sending a presence to your own bare JID to say "this is the current highest priority".
[14:49:43] <Kev> is anyone opposed to moving on?
[14:50:22] <ralphm> I don't see why the message type is important. You can also send non-body-containing messages with normal type, for example. headline is mostly useless, to me
[14:50:23] <Kev> jhildebrand: it's not, but I can post about that on list :)
[14:50:45] <Kev> so, moving rapidly (?) onto item 4
[14:50:51] <Kev> we wanted to discuss Jingle, I think?
[14:50:56] <Kev> What did we want to say? :)
[14:50:57] <jhildebrand> Kev: i'm ok with the slight difference that it's stickier, but i don't want to always have to re-forward. i'm ok with moving to the list. have a mtg. thanks, all.
[14:51:00] jhildebrand leaves the room
[14:51:25] linuxwolf leaves the room
[14:51:27] <psa> ralphm headline is good because you want the message to be broadcasted to all resources (cf. 3921bis)
[14:51:42] <ralphm> oh, I missed that new meaning
[14:51:43] <dwd> I think psa was going to let us in on the secretve world of Jingle implementor feedback.
[14:51:55] <ralphm> so we now put in pubsub into all servers after the fact?
[14:52:00] <psa> we've got lively discussion on the jingle@ list
[14:52:16] <psa> ralphm: maybe :)
[14:52:33] <psa> so I want to make sure that we gather the Jingle feedback and move it forward
[14:52:42] <ralphm> I'll read the section on that, but for now oppose that semantic
[14:53:24] <Kev> psa: ok - what does that mean for the moment?
[14:54:00] <psa> Kev: I suppose it means poke your favorite jingle developer so that we get the feedback we need :)
[14:54:06] <Kev> ok ;)
[14:54:28] <Kev> straight onto discussing next year, then
[14:54:34] <ralphm> heh
[14:54:38] <Kev> what are our plans and/or priorities for 2009?
[14:54:41] <psa> ralphm: http://xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-07.html#rules-barejid-resource-message
[14:55:34] <dwd> I'm afraid I'm going to have to leave next year until next week. :-) I'll leave the window open and give up for the night. Sorry, folks.
[14:55:36] <psa> Kev: well, I continue to receive pokes about mobile stuff
[14:55:43] <Kev> dwd: nn
[14:55:45] <psa> dwd: thanks, and feel better!
[14:55:55] <psa> mobile optimizations
[14:55:55] <Kev> psa: mobile what?
[14:55:57] <Kev> ok
[14:56:06] <psa> save the batteries
[14:56:13] <ralphm> psa: I'd rather dispose of headline entirely. What's the usecase for this new behaviour exactly? 'headline' has typically been used for news-like services (like Mimír) to make sure messages are delivered to a resource, but not got to offline storage.
[14:56:18] <psa> make it so that Android phones can use XMPP
[14:56:18] <psa> etc.
[14:56:25] <dwd> Save the batteries! Freedom for NiMH!
[14:56:32] <ralphm> heh
[14:56:34] <Kev> dwd: go to bed :p
[14:56:49] <ralphm> I like my batterie
[14:56:50] <dwd> psa: I think we can get Android phones to use XMPP by pretending Google invented it...
[14:56:58] <ralphm> drumming FTW
[14:57:00] <psa> didn't they?
[14:57:11] <psa> ralphm: :)
[14:57:20] <psa> so maybe we have no priorities for 2009 :)
[14:57:40] <Kev> yay
[14:57:43] <psa> personally I think we could take a whole year just to improve existing specs, move some forward to Final, etc.
[14:57:51] <psa> maintenance is becoming a bigger issue
[14:57:55] <Kev> works for me
[14:57:59] <MattJ> dwd, I thought Cisco invented it?
[14:58:04] <ralphm> e2e encryption?
[14:58:10] <psa> ralphm: yeah
[14:58:23] <psa> ralphm: been chatting with Dirk Meyer and others offlist about that
[14:58:44] <remko> psa: sounds smart in economical recession times. Don't invest in new research, just say you are 'perfecting the existing stuff'
[14:58:48] <psa> perhaps returning to something simpler, a la http://xmpp.org/extensions/inbox/xtls.html -- i.e., no Jingle
[14:58:53] <ralphm> I've thought about implementing dwd's suggestion of c2c tls with jingle
[14:59:03] <ralphm> that's several specs combined, no?
[14:59:46] <psa> the idea is that you already have a channel, it's called XMPP -- so why do we need to have negotiable options (IBB, S5B, ICE-TCP, etc.)?
[14:59:48] <ralphm> psa: I don't see why jingle would need to be excluded from that proposal. Can you expand on that?
[15:00:03] <psa> ralphm: just send a special IQ and off you go
[15:00:19] <ralphm> psa: oh, you want in-band, always?
[15:00:19] <psa> no need for negotiation really
[15:00:24] <psa> right
[15:00:28] <Kev> I wouldn't cry about not needing to do Jingle negotiation for c2c
[15:00:30] <psa> in-band always, and probably not even IBB
[15:00:44] dwd stirs
[15:00:55] <psa> because IBB will likely be blocked
[15:00:56] <dwd> psa: There's something to be said for making it optional, I think.
[15:01:02] <ralphm> psa: but a new in-band binary thing?
[15:01:13] <psa> ralphm: basically yes
[15:01:18] <psa> or we could use IBB as in http://xmpp.org/extensions/inbox/xtls.html
[15:01:22] <Kev> it doesn't need to be multipart like ibb, though
[15:01:36] <ralphm> 'cause if you do something new, people will implement ibb over that, and then it'll get blocked, lather, rinse, repeat
[15:01:36] <Kev> because we're sending messages with the same properties as normal messages
[15:01:36] <jack> i hate in-band stuff
[15:01:36] <jack> it kills latency
[15:01:46] <dwd> psa: If you block IBB, better block e2e, because otherwise you'll just use IBB inside e2e.
[15:01:50] <psa> jack: we're using in-band right now for XMPP :P
[15:01:56] <Kev> jack: xmpp /is/ inband
[15:01:57] <psa> dwd: heh
[15:02:13] <ralphm> dwd: beat you, hah!
[15:02:15] <jack> it works for short things. for binary it kills the stream
[15:02:20] <psa> Kev: right, this is just a specially-formatted message
[15:02:25] <Kev> jack: these are short things, though.
[15:02:37] dwd is reading much slower than typing, really must be time to give up.
[15:02:47] <psa> jack: then openpgp is bad too -- those are bigger messages
[15:02:59] <jack> perhaps i should read before i speak :)
[15:02:59] <psa> you can't have encryption without some bloat
[15:03:05] <psa> anyway
[15:03:11] <jack> i thought we were talking about jingle over xmpp in-band, not just session negotiation
[15:03:12] <psa> so let's figure this out in 2009 :)
[15:03:24] <psa> jack: basically talking about http://xmpp.org/extensions/inbox/xtls.html
[15:03:24] <Kev> yay, a priority
[15:03:27] <Kev> *priority
[15:03:46] <psa> and that's it -- for the rest we move stuff to Final, tweak existing specs, and allow coders to catch up :)
[15:04:04] <psa> at least that's one approach
[15:04:11] <dwd> I'd like to get file transfer over Jingle sorted out, too, FWIW.
[15:04:23] <psa> yes yes yes
[15:04:40] <psa> was just chatting about that earlier with Rob McQueen
[15:04:55] <psa> I think e2e and file transfer will be plenty to figure out :)
[15:05:27] <Kev> shall we decide on a next meeting and stop here, then?
[15:05:32] <Kev> after an hour, I'm pretty much done :)
[15:05:36] <psa> we would review http://wiki.xmpp.org/web/Board_and_Council_Elections_2008 and see what we said :)
[15:05:37] <psa> yes
[15:05:40] <psa> fine with me
[15:05:46] <Kev> next week, same time?
[15:05:48] <psa> +1
[15:05:54] <Kev> after that I start having trouble with attending for a few weeks
[15:05:55] <jack> +1
[15:05:58] <psa> I can send out minutes
[15:06:04] <psa> Kev: nod
[15:06:04] <jack> actually hmm
[15:06:05] <ralphm> yay
[15:06:06] <Kev> psa: loverly, thanks
[15:06:11] <psa> jack: ?
[15:06:12] dwd said whatever PSA said so he looked clever.
[15:06:14] <jack> i will be in florida, dont' know if i will be completely available
[15:06:15] <ralphm> going back to my OpenFire issues
[15:06:28] <jack> i will try to make it
[15:06:30] <psa> jack: ok, there's always feedback on the list
[15:06:32] <ralphm> I've been seeing 40 minute latencies for in-server traffic
[15:06:33] <psa> jack: ok thanks
[15:06:41] <ralphm> so much for near real time
[15:06:44] <psa> heh
[15:06:45] <psa> yeah
[15:07:00] <jack> ralphm: wow. that is pretty messed up.
[15:07:14] <psa> brb
[15:07:15] <Kev> ok, assuming there's no AOB, we can go home :)
[15:07:19] <ralphm> jack: indeed. I have no idea how to debug it
[15:07:21] Kev bangs the gavel
[15:07:23] <Kev> thanks guys :)
[15:08:25] <jack> ralphm: i'd start with installing a different server :)
[15:08:35] <jack> later all
[15:08:46] <Kev> bye jack, thanks
[15:08:58] jack leaves the room
[15:24:13] mlundblad joins the room
[15:26:05] ralphm_ leaves the room: offline
[15:26:11] ralphm leaves the room: offline
[15:30:26] psa leaves the room
[15:57:00] seaprior joins the room
[15:59:40] seaprior leaves the room: offline
[17:04:17] waqas leaves the room: Replaced by new connection
[17:19:52] remko leaves the room: Logged out
[19:00:42] MattJ leaves the room
[19:43:25] seaprior joins the room
[19:43:32] seaprior leaves the room: offline
[19:47:15] seaprior joins the room
[19:47:19] seaprior leaves the room
[20:58:42] Nickname joins the room
[20:59:22] Nickname leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!