XMPP Council - 2011-08-03

greetings

Greetings stpeter

MattJ: are still in NYC?

How was Quebec?

I am

it was enjoyable

Evening all.

nice place

enjoyable and busy, of course

very French (-:

Heh

Right, it is time.

1) Roll call.

I'm here!

howdy

presente

Presents

dang…a full house?! unpossible!

oh, no ralphm

Don't get your hopes up :)

2) Promote XEP-0260 to Draft? http://mail.jabber.org/pipermail/standards/2011-June/024722.html

+1; I think I found a couple cosmetic grammatical error, but not enough to hold it up

no traffic on the mailing list?

Am I correct in that we had no LC feedback?

not until this morning

Tobias had feedback on both.

(A few minutes ago)

Oh, Tobias

It bothers me somewhat that we're promoting stuff to draft that only a single person says they've implemented or intend to implement.

So, I've implemented most of 260 - but it was some time ago, I'd like to know interop with someone worked

I'd like to test with Tobias in particular

and Gajim implements it I think, if we can track down the code (I'm not sure it's in trunk)

ok, well, sounds like 260 has at least two implementers

3

yeah, that was my sense

IIRC, Gajim's Jingle-FT is in a branch, yes.

Implementers, no real world experience

right

true

Can we put off 260 and 261 until next week, and chase people in the meantime for feedback?

wfm

Should we hold off on draft until we see some interop, at least anecdotally?

there's also a pidgin branch implementing 260 and 261..at least claiming that

dwd, Asterix told me he was merging it "tomorrow" about 6 months ago

cool, let's give it a week

MattJ: :)

the same would be true for 261, yes?

well..IBB to pidgin works for me

I'd like to bring up the last call issues in AOB

It doesn't seem that waiting a week will significantly hurt anything, and it may give us a much better-informed position to comment from.

stpeter: Your thoughts?

I note that proof of interop is not required by XEP-0001 for Draft.

fine with me

dwd: Not required, but if we have known implementors, it makes sense to me to try to get feedback.

dwd: *nod* -- still, seems like we're blind without at least some evidence that it works.

personally I've been having dark thoughts about how everyone will just use http://tools.ietf.org/wg/rtcweb/ before long anyway, but what do I know? ;-)

For the sake of a week.

stpeter: heh

So, assuming that covers 3) Advance 261 to Draft as well...

True. Just noting that you don't *have* to. But specifically pinging implementors seems like a plan.

4) Advance 266 to Draft http://mail.jabber.org/pipermail/standards/2011-June/024625.html

+1 from me, I think

hello

Hey ralphm :)

+1 from me

Hi Ralph.

stpeter, what's the epub symbol there on the WebRTC WG page? IETF publishing in ePub now? :)

damn…we do have a full house

(-:

re codecs, see also http://tools.ietf.org/html/draft-cbran-rtcweb-codec-00

Tobias: some things, yes…sort of (-:

So, I know there was some amount of discussion on list about 266/Opus, but as far as I can tell the XEP does address that (we shouldn't be recommending it/we're not, we should be noting the claim/we are).

exactly

rightio

Same logic from me

+1

there's more consensus on jingle@ mailing list

+!

ehm, +1

Heh

(-:

There was someone offering to list all the reasons it was bad, then not doing so when asked to, so I'm +1 on this in the absence of any clearly unaddressed issues.

I like +!

and agreed about #2 and #3

or +¡

haha

So, noting there's two AOB items (Matt and Matt).

there doesn't seem to be a unicode code point for [approved]

fußy

5) Time of next meeting?

Next week, same time?

WFM

yup

no news from Quebéc?

and that date/time works for me

linuxwolf: That's your AOB item :)

Well, yours/PSA's.

actually Québec :)

haha

6) AOB.

:-)

Québec report from Peter/Matt:

grazíe

(expecting a large paste here)

the main topics were s2s/DNA, i18n, and e2e encryption

so, on the XMPP front...

(wow, why are linuxwolf's /me messages styled in a huge font?)

They seem to be XHTML-IM

ugh

I need to get a better client

or write one /ducks

anyway

Before the last upgrade I patched gajim to disregard certain styles

linuxwolf, join the club

ssshh, we're hearing a report

in particular font-color, family and size

hehe

so

DNA

"the main topics were s2s/DNA, i18n, and e2e encryption"

the biggest concern seemed to be around requiring tedious software upgrades (DNSSEC-based)...

…or sharing cert+keys from the hostee to the hoster (cert-based)

post-session, there was some agreement to a compromise...

…to use a descriptor file served from the hostee's HTTPS server that listed the valid name (or certificate) for the _xmpp-server._tcp service

Joe Hildebrand and Eric Rescola were working on a draft, so I think something should be emerging in the next week or two

Which is really just the age-old trick of shifting-the-problem-without-solving-much.

right

brb, switching to wifi (198 would be so useful right now)

:)

based on .well-known?

and with the CA trust anchors in x.509 being less-than-stellar...

ralphm: yes

I basically agree, but I think it's an achievable goal and workable if one assumes that it's a fallback from DNSSEC.

/nod

yeah I can imagine the approach

dwd: agreed

'assumes' or 'requires'

on the i18n front…it's basically see what happens in PRECÍS, although stpeter can comment more there

yes, I've been pushing for progress on internationalization

we'll need to do something

I need to update the precis-framework document based on feedback received in Québec City

/nod

I worry a bit about Kev's point that changing the address format might require a version change to XMPP itself, but we'll see if that's needed...

linuxwolf: as in 'nobody is picking up the work'?

ralphm: it's more that "this is hard, and we don't know what to do"

ralphm: unfortunately, few people care about internationalization, and even fewer know how to help

or can take time to work on it

however, I think we can see a realistic path forward

/nod

stpeter: I realise I'm speaking as someone who does't understand this stuff, but I only see two options - either updating away from 'prep gives us something new and therefore isn't compatible, or it's not giving us anything that stringprep/fixed unicode versioning doesn't.

I mean, what we're working on is based on / similar to what people are already using for domain names

I think it's more that it's hard and daunting, so the motivation to work on it is less

FWIW, Isode folk have picked up some knowledge; I'll see if I can get some time from Alexey and Kurt on this.

I've been getting a crash course from stpeter and hildjj

it is daunting

Kev: I see. And your point is that since the JIDs already appear in the stream header, you can't discover it?

Kev: right -- we need to dig into those issues, which I plan to do Real Soon Now™

ralphm: right

Kev: it's not clear if it will really break in the practical sense, or just the theoretical sense

or at least not clear to me

yeah

well, further updates on the way :)

next item?

the fixed unicode is, or will be very soon, breaking in the practical sense

I don't think it needs a version bump

Kev, I think we may need to signal in the <stream:stream>, but it's not clear this is a full version-break.

MattJ: I don't think it's clear yet

linuxwolf: so we need to assert the risk of breakage and decide if we think that is generally acceptable

So, how was the weather?

ralphm: basically…there's more to it, but that's one of the big things

if the JID is valid, who cares about the version? if it's invalid (and should be valid) then there's a broken interop whether we bump the version or no

So, was that the total for the WG meet?

Fritzy: warm, but not unpleasant (-:

there was an E2E presentation of sorts (-:

Well, if we ever change the version number, I have a wish list

:-D

that is basically waiting on output from WOES cum JOSE

linuxwolf, That's just a tradition, now, right?

MattJ: Unless it's valid, or different, under different profiles and you need to signal the profile. If you have a profile in common you can interop, otherwise not. This can be a version number, or just another top level attribute on the stream header.

dwd: essentially (-:

ralphm, you and how many other people? :)

MattJ: how is that relevant :-P

Kev, true, valid but "different" would be awkward

forget about XMPP 1.0+, just use WebSocket

linuxwolf: Is there more to say on e2e?

Or shall we move onto MattJ's AOB for the last 2 minutes?

stpeter, because those guys really have their act together

stpeter: hehe

stpeter, Can't on S2S, neither end would know which one should be encrypting their output.

MattJ: You wanted to AOB about the LC feedback?

Right

Kev: there's a WG forming for "better" crypto options, which is now called JOSE…otherwise nothing concrete yet

Kev, it was just a thought that I had before the meeting

that it's not uncommon for us to have no LC feedback, despite implementations existing

and I'm wondering if that's something we can improve on

MattJ: which could either mean our specs are awesome, or nobody cares to write up issues?

ralphm, nobody cares, most certainly :)

heh

the latter

yeah

I'm just wondering if we should make it someone's responsibility to research implementations and reach out to these people

ralphm: If they were awesome, but people cared, they'd still reply to the "Is this spec alright?" mail.

I know that's what we're doing already, typically

but only after the first LC period fails

Right.

So would it help to approach the (known) implementers more directly?

A question to send out to list, probably.

/hnod

ralphm, that's the idea

/nod even

As we've just hit half past so we're out of time.

it seems to me that dedicated protocols like SIP and XMPP and IMAP are going away for client-to-server interactions, and we'll just be left with WebSocket and JavaScript APIs -- however, we'll still need s2s protocols for federation purposes (if anyone ever wants to federate in the brave new world of web silos

stpeter, you can be cynical sometimes :)

stpeter: I don't think that's true at all

MattJ: just reading the writing on the wall

or maybe I just need a vacation

Well, stpeter is right that there is that trend

Looking at a different wall to me

There's hype

but I don't think it'll be ultimately to that side

I don't know if that constitutes trend just yet

stpeter: except those WS + JS end up using something that looks an awful lot like XMPP or SIP or IMAP d-:

linuxwolf: perhaps, yeah

In any case, I think we're done.

Any other any other?

None from me

meeting is done, I think

nay

just like Ruby is taking over the world

Righty.

Thanks all

:)

lol

ciao!

haha

ralphm: Ruby forever!

I'll email standards@ about LC

MattJ: thanks

grazíe

MattJ: I'll bet you get loads of responses

clearly Lua is taking over the world ;-)

ralphm, :)

¡chao!

stpeter, http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html :)

I do think lua is kinda cool

stpeter: it's really hildjj's (-:

MattJ, right there trending with Transact-SQL

although JavaScript is the new Ruby…with Lua maybe the new Python d-:

I /was/ kind of surprised finding out that prosody doesn't respond well to a 4G lua file with offline storage

ok, off to my next meeting

ralphm, lovely

ralphm, FWIW we're working on that :)

MattJ: well, it was also something I needed to fix on my end

they were piling up pubsub notifications for resources that were no longer listening

Sure, but if you want 4GB of offline messages...

how long is a Last Call period?

a fortnight, IIRC

"The Last Call shall expire not less than fourteen (14) days after the date of issue."

so, a fortnight is a minimum (-:

sometimes we declare longer review periods

e.g., for large or controversial specs

15 is right out, so is 13, unless followed by 14

or if there are some holidays in the middble

or extend them

that too

:-D

Tobias, Extending Last Calls is specifically allowed: If necessary, the XMPP Extensions Editor may, at his discretion and in consultation with the XMPP Council, extend the Last Call or issue a new Last Call if the XEP requires further discussion.

and we've done that in the past

Right, I recall a few times, actually.

interesting

http://jabber.markmail.org/ <-- watching that activity graph we soon are at about 0 :)

Tobias: interesting

not that different from, say, http://spamassassin.markmail.org/

stpeter, but spam is decreasing year over year..so that's no surprise ;)

heh maybe

but it's not just that graph..i've been noticing quite a decline in xmpp related mailing list activity...don't know if that's due to work on new standard or whatever

Tobias: agreed

I think XMPP has become a stable, boring technology

or most of the energy is moving to things like node.js and websockets

not quite sure yet

Tobias, It's a sign that we're not working on anything interesting right now.

it's not the new hotness (-:

heh

it's the old hotness?

dwd, file transfer is interesting...since it's the thing that never works :P

Tobias, But I wouldn't read too much into that - IMAP went dead for several years then popped back up for all the mobile mail stuff.

it could heat up again when people realize that WebSockets turned out to be warmed over cometd/BOSH (-: /ducks

linuxwolf, WS is, in principle, faster, except that the repeated buffering and XORs are, I think, going to wear away some of that benefit.

linuxwolf, The interesting question is whether it'll fly on mobile. Very little mobile experience in that group, and there's the usual crop of "Well, I heard that on mobile [...]".

dwd: yeah, we'll see

isn't WebSocket still going over TCP?

I've still got my doubts

Tobias: it's worse than that

Tobias, Yes, but TCP is fine on mobile.

Tobias, You've got to get much worse networks for TCP to be a problem.

dwd, Apple seems to think different, watched a couple of sessions from their last WWDC, they discourage any long living connection. I guess other mobile vendors think different. Opening TCP connections over and over again can't be that good for speed/latency/battery/etc.

or not?

I guess watching that train wreak…er, mailing list…made me a bit jaded

Tobias, On the vast majority of mobile networks, you can leave a TCP session open and happy for 15 minutes or more, these days.

Tobias, That is, without sending any traffic at all.

/nod

dwd, while traveling through half the country?

I've certainly held TCP sessions whilst on a train. I even held them through the Severn Tunnel a couple of times during Council meetings. :-)

Tobias: from my limited experience, as long as I don't drop below a certain signal threshold, I've been fine

but I'm in the US (-:

OT: does anyone care about jabberpowered.org anymore? I need to decide whether to renew the domain registration :)

we still had that?

yep

every year I try to decide whether I still need to renew it :)

heh

thefutureiswebsocketsnotxmpp.com?

heh

:)