XMPP Council - 2010-08-16

is there a meeting today?

as I understand it, yes

and hi :)

hi :)

Olivier Crête spoke about someone formalising the psuedo-udp ft stuff from google as a "standard" jingle spec. is this in the XSF's inbox?

not in the inbox yet

well

I have somewhat mixed feelings about that...

there is http://xmpp.org/extensions/inbox/jingle-httpft.html

yeah

I was under the impression that this would meerly be a jingle transport spec.

ah

not sure, though...

that one

yeah, there's been talk about documenting that, but no action

maybe I'm slanting towards thinking that might be a good idea, compared to ice-tcp

but maybe not...

the http-over-pseudo-tcp-over-udp stuff is kind of crazy, but that doesn't mean it's bad :)

I think maybe the http stuff is overkill, though

another crazy thing though, psuedo-tcp-over-udp-over-a-tcp-relayed-turn-candidate...

yikes

heehee

hi

Evening Ralph.

hiya

brb

warming up my foods

me too :)

Right, Hello meetingtime

Hooray!

Matt and Remko are both online, just getting them to join.

gosh I love these people who go on vacation for a month -- how is that possible?

Sounds nice doesn't it? :)

stpeter: come live in europe

I did take a two-week vacation back in 1994, that was quite relaxing :P

Right.

So.

Stop. Meeting time.

1) Roll call.

Fritzy, Kev, MattJ, ralphm, remko.

2) Agenda bashing anyone?

Not here

nope

Ok then.

3) ProtoXEP - XMPP on Mobile Devices http://www.xmpp.org/extensions/inbox/mobile.html Accept as Experimental?

yes, interesting matter

indeed

I'm not objecting.

Fritzy / Matt?

Commenting on list's fine if you've not read it.

No objection here, I'm glad someone finally wrote it up :)

yep, that looks helpful

plus I love it when someone other than me writes specs :)

:)

stpeter: Well, Matt and I have a big stack waiting for limelight :)

MattJ: how's that my-client-doesn't-support-SIFT-but-I-still-want-it feature?

ralphm, which was that?

or you mean the intelligent presence buffering?

yeah, but such that I can tell my server to do it for a particular resource. Like 'Maemo'

or a given disco identity? :)

sure!

Ok, I think Fritzy's gone AFK, so moving on.

4) ProtoXEP - Digital Signatures in XMPP http://www.xmpp.org/extensions/inbox/dsig.html Accept as Experimental?

+1, I'm curious about the TBDs

no objection

Heh, you like it more than I do.

Why is it necessary to encode the contents like that?

I'm not convinced about signed messages being illegible to non-signing clients - i.e. you could never send signed messages to a MUC.

Even e2e had some normalization routines, presumably for the same reasons

I wonder if anyone will sign their XMPP stanzas, given that precious few seem to sign their email messages and that technology has been around for a long time

stpeter: Well, in email I can still read your mails.

Even though I don't process and verify the signatures.

MattJ: from what I've been told, normalization like in XMLSig is quite horrible

That's not true here.

kev: indeed

kev: that doesn't really sound very good

it's probably a workaround for the whitespace etc.

but still, there shoudl be a better one

ralphm, e2e did seem to manage, minus one case in the XEP that suggested stripping whitespace in a given instance was enough normalization

Well, I quite like the copy-and-sign approach, where you encode, like this, what you signed so it's there for verifying clients, and other clients get it in plaintext.

But I'm not winning this argument with Kurt, so I'm abstaining on this non-vote.

IMHO it's early days for signing

heck, it's still early days for encryption!

stpeter: true

So, where are we?

Well, I'm ok with it being a XEP, not necessarily thinking this is the best approach.

Remko and Ralph are +1, Matt was ...?

and Fritzy's AFK :)

+1 to publishing

That actually raises an interesting question - if a Council member is in the room, but AFK, for a meeting, does that count as present?

But I 1) think it needs some discussion going forward 2) don't think it's going to see implementations like this

i agree with matt

if a tree falls in the forest...

Kev: does that actually matter?

ralphm: Well, stats are kept on people's voting and attendance history, so people can do sensible things with voting in Sept/Oct.

Whether people use them is another matter, but they're there.

Anyway.

I could easily leave my client idle here 24/7 then :)

MattJ: Right.

5) Winding down Council. Anything we want/need to do before the end of term?

Peter'd like us to get some file transfer headway made.

I've nothing to say that we didn't discuss on list

Archiving, etc.

Yes, well, I'm happy to push my specs out if you are yours :)

file transfer would be nice indeed

FWIW I have some comments on Jingle (it's a pain to implement)

MattJ: in general?

Kev: well, given that I promised to review the reviews of file transfer, I have action items I can take

stpeter: Jolly good, nothing for me to do yet, then.

7) Date of next meeting.

Next Monday, assuming we have things to discuss?

yes

:)

ralphm, well I'm implementing Jingle File Transfer, the main Jingle spec defines a lot of things vaguely that aren't followed up on in JFT

+1

8) Any other business?

The spec was clearly split into signalling/RTP at some point, the split wasn't quite right IMHO

MattJ: "the spec" = 166?

MattJ: ah, so the specs are unclear? Not necessarily bad?

stpeter, yes

ralphm, I think (hope) mostly just unclear

Kev: Council members need to decide if they are going to stand for consideration again, I suppose

For example...

http://xmpp.org/extensions/xep-0166.html#session-negotiation

This section has no protocol description at all

stpeter: I'll be seeing if there are enough sensible candidates other than me, and deciding then.

Yet negotiation is surely the most significant part of Jingle :)

MattJ: heh

I do think I've been on Council a while, and people should step down after that long if there are sensible replacements.

MattJ: in general, I think we've been defining Jingle via examples such as XEP-0167

Ok, I'm taking this as no more other more business.

Kev, turning that around... isn't that up to the members to decide?

MattJ: I "discovered" some things about Jingle by writing the file transfer specs

i'm steppnig down, because of lack of time to focus appropriately

stpeter, as one of the few developers that doesn't develop implementations purely by reading examples, that's awkward :)

MattJ: possibly.

Right, I'll write up some minutes, probably tomorrow.

Thanks all.

Thanks Kev

MattJ: hehe. Maybe you can provide some examples to be added to the spec?

MattJ: by examples I meant "RTP is one example of how we'd use Jingle, but file transfer is another example / use case"

ralphm, I wish I could, but I literally have no idea what that part of the protocol is meant to be like

MattJ: the same is true on the transport side (UDP, TCP, etc.)

MattJ: I actually think this part is intentionally vague

166 describes all these commands, content-add, content-replace, etc... without saying how to use them or what they mean

Ok, if it's intentionally vague then it should say so

it is intentionally vague, but as we have more applications we could strengthen the core spec

and the file transfer XEP should explicitly say what each command means

But it doesn't

Meaning at the moment I am basically implementing by 1) example 2) interop with Gajim's new code

two-week vacation?

I had a short vacation this year, only four weeks :D

stpeter: for most of these things, doesn't the actual profile decide the protocol bits going in these actions?

ralphm: yes

ralphm: although I agree with Matthew that we could be clearer in 166

mlundblad: :P

stpeter: I'm unsure how to then make it more clear except by writing a fictional profil

e

right

that's how I learned :)

didn't we try that?

it's like writing a novel, the characters take on a life of their own :)

http://xmpp.org/extensions/xep-0234.html doesn't mention any of the Jingle commands

XEP-0208, I think

I take it back... it mentions transport-info

and then links to an example that uses session-info

ok those are all good points

The box under example 1

in part file transfer is much simpler than voice and video, so it has no need for many of the Jingle commands

however

transport-replace

I think it would be good to say that

but that is in s5b, I think

Kev: do we have definitive feedback on the message threads XEP?

stpeter, I agree... which is why I suggested the split in the XEPs was in the wrong place

Kev: perhaps we need to chat about that and figure out what changes are needed

We've got feedback from Matt, does that count?

sure it does

MattJ: You're the definitive voice of XMPP. Congratulations :)

\o/

heehee

the other point about file transfer was that we want to get feedback from the GSoC implementers

Now if only I could finish this overdue work so I can catch up with other spec reviews

MattJ: yeah, understood

oh and I have more XMPP WG feedback to address, too

fun

stpeter: I'm happy to have a work through threads with you if you like, but not tonight.

at least I'm adding acknowledgements so that all you helpful reviewers receive some credit

Ta muchly.

My name in lights :)

Kev: sure, perhaps tomorrow or Wednesday or whatever

Right, AFK.

Mondays can be crazy, I know :)

Mondays suck.

heh

MattJ: thanks for your helpful feedback -- I sense some revisions on the way

You're welcome :)