XMPP Council - 2011-06-22

and while eating my second breakfast I pushed out a slightly revised version of XEP-0233 :)

I've almost finished realtimetext.

I'm going to ping Alexey about reviewing it

The gift that keeps on giving :)

;-)

Aaand done. With plenty of time until Council :)

yay!

now to start rounding up Council members :P

bbiaf

heh, my dent/tweet seems to have worked, although it remains to be seen how many Council members are online...

Hey :)

:(

sorry to hear it

I'm sure I'll survive

well that's good news :)

I pinged Ralph but he seems to be AFK

Fritzy is offline as far as I can see

it appears that our Council has been reduced to a Triumvirate...

Is it contagious?

:)

So. No sign of a quorum at the moment.

linuxwolf is somewhat here but no doubt distracted in an IRL meeting

Right, linuxwolf sent apologies.

yes

Is Realtime Text the first XEP with an external homepage?

Probably.

I'm half expecting to find it on Twitter and Facebook :)

gosh, maybe I need to get on this Facebook thing I've been hearing so much about

Your face, in their book

This RTT animation makes me dizzy, I never liked it in Wave either

So. I wonder what we should do about our wayward Council cousins.

Why don't we always just type half a sentence, if that's enough for the other person to start responding?

MattJ: I don't enjoy using it at all, but I'm not opposed to others doing so.

Kev: well, one of them might not even be an XSF member any longer...

Me neither (on both counts)

agreed, on RTT

I thought RTT was vastly improved over v1, btw.

ditto, though I haven't read it all yet

I need to read it, too

Ok, shall we have a non-quorumed meeting?

or a non-meeting?

So at least we can discuss stuff usefully, even if not pass votes.

Fine by me :)

sure

we'll just have a friendly chat

I'll send out minutes afterwards :)

heh

Of of the friendly chat :)

We actually wait for votes from people not at the meeting anyway

Doesn't Jingle Nodes have a "external homepage"?

Florob: yes

MattJ: Yes, but we can't start the vote period until a meeting happens.

Florob, gah, you're right :)

Maybe this is a trend

Right, so we can skip the Roll Call, and probably the Agenda bashing.

http://www.xmpp.org/extensions/inbox/hashes.html

I'm fine with the idea of this, and the implementation, except that section 4 (update namespaces) is wrong.

Kev: how do you think we should handle the namespace versioning?

The namespace should only be updated if there's an incompatible schema change (or usage change).

Else we have the situation like:

md5 is MAY, SHA1 SHA2 are MUST. SHA3 comes out and the XEP then becomes the same but with SHA3 as MUST (for example).

Now someone who implemented it yesterday is unable to interop with someone implementing it tomorrow, even though they support several MTI hashes in common.

(Because the namespace has changed)

right

one question is: do we need a way to discover which hashes the other party supports?

So I think you use the hashes you support, and if the other side supports them great, otherwise you can't interop.

I might agree that changing the namespace might not be the best way to perform that discovery

stpeter: Is the assumption that you only send one negotiated hash, or that you send those you support?

Kev: it might depend on the protocol

I was assuming you'd send those hashes you support.

Maximum interop, for not a huge amount of overhead (unless we start talking about supporting hundreds of hashes).

Yeah, discovery brings just a small optimisation (which may not actually be worth it in some cases)

sure, but why eat of processor time to generate hashes that the other party doesn't support? (e.g., in file transfer)

s/of/up/

(This is notable not suitable if you're doing something like password hashing, where having multiple is a vulnerability, of course).

stpeter: Right, in that case we probably want negotiation.

Well, I say negotiation.

I mean caps.

so if I want to send you a bunch of large-ish files, I don't want to figure a checksum for SHA1, SHA2, and SHA3

Right.

so discovery might be good

but

we don't need a namespace change to do that

So I have sha1, sha2 in my caps. You know what I support, pick the one that suits you best, use it.

Right.

we could have separate disco features

So I think we add discovery, and remove namespace changes.

that would work for me

+1

Great.

I have a small proposal, but I haven't thought it out yet

MattJ: proposal for...?

This XEP

Just typing :)

heh ok

(if only we had a way of transmitting my text as I typed...)

Yes, that could get hilarious in MUCs :)

Instead of a <hash> element for each algorithm, what if that element contained all the algorithms?

85 in MUCs would be sensible, though.

Maybe Swift should start doing that.

Kev, it should - I'm pestering for Gajim support

A number of clients are doing it now

(finally)

Maybe an example of my hash idea would be clearer

MattJ: that might be fine, yes

<hash xmlns='urn:xmpp:hashes:0'> <algo type='sha-256'>2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU=</algo> </hash>

or something like that

nod

Isn't that what we have now?

'now'

:)

It's not so different really, except in the implementation you just have to iterate over the child elements of a single tag

Oh, I see.

rather than cherry-pick all elements with the hashes namespace from amidst the rest

Right, that's neater if you have multiple hashes, yes.

Right, although your library's going to be doing that for you.

Yeah, sorry, I'm lazy :)

you say potayto, I say potahto

Kev, depends how high-level it is, also - I write the library, so no it isn't :)

I like that a bit better

so I'll make version 0.0.2

Thanks

Thanks Peter.

So, has anyone read any of http://xmpp.org/extensions/inbox/realtimetext.html ?

I have a longish list of issues with it, but I don't think they're sufficiently fundamental to block publication - and it's written like a XEP now, mostly, which makes life much better.

Not the new version in detail, and I'm not sure I'm capable right now

I haven't done so

It didn't make me go "aargh" like the first one did though

:)

heh

If you're happy with publication then I probably am too, but I'll take time this week to review it and put my thoughts on-list (assuming we won't vote until next meeting?)

I'll do the same

We can't vote until next meeting, indeed.

I'll post my thoughts to the list in advance.

excellent

any other non-business for discussion in this non-meeting? ;-)

I just updated XEP-0233

and I poke some SASL people about reviewing it

poked, that is

Not according to the agenda.

Unless someone else has something.

so I might request a Last Call about that one before long

iirc I read an email where stpeter said we could discuss something at the meeting

yes

file transfer

if we plug this hashes stuff into XEP-0234, then 260 and 261 are left waiting

Ah, ok

so I wonder if it makes sense to take care of those first

we said we'd bundle them with 234

but they're basically done, I think

something to discuss next time, I suppose

shall we schedule the next meeting?

Next Wednesday, presumably.

Fine with me

WFM

Righty.

Aww shucks.

(And thanks)

:)

Righty, I guess we're done with the non-meeting, then.

yep

Thanks.

And thanks both for turning up!

we're here for you!

Heh, thanks :)

hmm

it would be handy to reference hash algorithms like this... urn:iana:hash-function-text-names:sha-256

but there is no urn:iana:* namespace

Faux-minutes sent!

:)

And that's RTT notes sent out.

Thanks

and hashes 0.0.2 checked into git :)

Thanks.

http://xmpp.org/extensions/inbox/hashes.html

Brief scan looks good to me.

I've poked IANA about setting up a urn:iana namespace so that we don't have to manage a separate set of disco features in the urn:xmpp tree for cryptographic hashes (although I don't see any great harm in doing so)

bbiab