XMPP Council - 2011-03-23

T-15 minutes?

Aye

Yes please.

posted to identi.ca

I just processed the forwarding proposal, too

!agendaappend http://www.xmpp.org/extensions/inbox/forwarding.html Accept as XEP?

Kev: Done.

stpeter: So I saw :)

Thanks :)

Indeed, murky.

also, I received a bug report on the XEP-0198 schema so I processed that just now

cutting the submission awfully close (-:

heh

could be considered next week or week after

It's a small XEP!

But really, I don't mind :)

"I don't know if I can consider it at this late stage…"

It is a small XEP, and Peter announced that Council would vote today, so I have to put it on the agenda :)

j/k… (-:

I haven't looked at how the new http://xmpp.org/extensions/inbox/forwarding.html differs from the old http://xmpp.org/extensions/inbox/forwarding-delivery.html and http://xmpp.org/extensions/inbox/forwarding-request.html

brb

stpeter: It's just an encapsulation format (unlike forwarding-request) to be used in other XEPs (like the upcoming Message Archive Management), and it's a straightforward complete encapsulation, unlike forwarding-deliver.

mmmm….competing specs!

Kev: and I have yet another BCP I'd like to propose

I have people working on the 'back yard' at the moment, so I'm sorry if I have to vanish at an inopportune moment for a couple of minutes.

linuxwolf: Good. You have 9 minutes.

Hey, that's not fair

(optional) version info via caps URL

MattJ: do you see me presenting an actual spec? (-:

linuxwolf, thankfully no, I want to hold the record for shortest submission->vote->acceptance for at least a short time :)

in that case, I might just have to defer acceptance… (-:<

You wouldn't :(

I hope snarky is over-age, then.

MattJ: use of reverse smileys may dissuade me from delay

☺

(-:<

aha, I see what you're after in http://xmpp.org/extensions/inbox/forwarding.html -- that's quite straightforward

😸

the old specs were about stanza forwarding a la .forward

Right.

So e.g. carbons should use this format.

As ideal, should the ad-hoc for forwarding unread messages.

As should 136bis

+1 to 136bis

well, carbons could use the older forwarding specs, too

136bis is on the way... I know because one of the few remaining todo items is "choose a title" :)

I was mentioning just yesterday how we need to de-ian-ize certain specs like 136

but I prefer the form from Messers WIld and Smith

(mentioning to linuxwolf that is)

Matt's approach is to deny 136 ever existing. :)

lol

Which suits me fine.

It's not like it's seen wide adoption (and it's not hard to see why)

I'm mostly excited about the new protocol simply because finally people might implement archiving

maybe

(-:

I just invited Fritzy

I'd love it to become a more mainstream feature - it's a really common request from users

:)

hi Nathan!

it definitely is

MattJ: Well, I want it in Swift, at least. Especially when used with the rest of the multi-resource stuff.

That, and "I want my conversations to appear in all my clients"

no sign of Mr. Meijer

Howdy

I have to AFK for a moment, I'll be back within 2mins or so.

MattJ: forwarding is a really common request, or history?

history

(logging, auditing, caching, ....)

stpeter, history

nod

just checking

Forwarding would be a nice addition to clients in itself, but I suspect users are just going to continue with their copying and their pasting :)

Right.

Let's start :)

!agendaup

Kev: -9) Fini.

!agendaup 10

Kev: 1) Roll call

here

Here

howdy

I mean here

!agendaup

Kev: 2) Agenda bashing

request to talk about caps

)(see above)

Is that a real item or AOB? :)

it can be an AOB

Ok.

Anyone else?

nossir

it's hard to bash an agenda that we can't see :)

Nope

Gah, brb 60 sec

we're blind?

stpeter: Well, I sent it out earlier in the week.

Plus the item you added today :)

But sure

!agenda

Kev: 1) Roll call 2) Agenda bashing 3) XEP-0065: Accept version 1.8? 4) http://www.xmpp.org/extensions/inbox/resource-locking.html Accept as XEP? 5) http://www.xmpp.org/extensions/inbox/forwarding.html Accept as XEP? 6) Date of next meeting 7) Any other business Fini

one could !agenda

heh

many thanks

seems fine to me

!agendaup

Kev: 3) XEP-0065: Accept version 1.8?

I haven't reviewed the diff. I'll do so and on-list it up.

me neither

I'll also wait for MattJ for a moment before moving on.

and neither have I

the diff is hard to read, I find

Does anyone object to waiting for a moment for Matt to catch up?

fine by me

(defeaning silience)

/sigh

I'm easy

I've got too many docs to write today to be typoing

Sorry, back

!agendaup 0

Kev: 3) XEP-0065: Accept version 1.8?

MattJ: ^

I have it open, I haven't finished reviewing it, so I'll post on-list too

!agendaup

Kev: 4) http://www.xmpp.org/extensions/inbox/resource-locking.html Accept as XEP?

I don't object.

I'm not entirely convinced by each of the details, but I don't object :)

+1

+1, obviously (-:

I don't object either, but I have some small feedback I'll post to standards@ when it's published

Specifically, I think it should always lock when receiving a new message, rather than maybe locking and maybe unlocking.

BTW the most up-to-date diff for 65 is http://xmpp.org/extensions/diff/api/xep/0065/diff/1.7/vs/1.8rc4

I'm also not sure that <gone/> justifies an unlock, but I'm less worried about that.

(but it's close to unreadable)

Kev: to be fair, this is based on 10+ experience (-:

I'm happy to not really worry about this, as I think the later multi-client XEP solves all problems ;)

(well, not specifically with <gone/> itself, but the entire concept)

we shall see (-:

This is *almost* what we're doing in Swift.

Apart from not bothering with gone yet, and rebinding instead of unbinding on a new message.

Anyway.

!agendaup

Kev: 5) http://www.xmpp.org/extensions/inbox/forwarding.html Accept as XEP?

+1 :)

hmmm

The background for this:

Matt's got a new archiving spec, there's carbons, there's an ad-hoc for forwarding messages.

It'd be good to have a common format for the forwarded messages in each of these cases.

Thus this spec

+1 actually

+1

I think I still have some security concerns, but I haven't exactly had a lot of time to read it (-:

linuxwolf: It's a format rather than a protocol.

linuxwolf: sure, the interaction with signing and encryption might be "interesting"

So I think the security concerns belong to the protocol using the format, but I could be persuaded otherwise.

MattJ: Your vote? :)

Kev: technically, it's a protocol extension format

(-:

does this technically change the jabber:client ns?

fritzy: Of course not.

allowing another <message /> child?

fritzy, it does not, why?

jabber:client says nothing about the number of message children.

plus it's a child of a child

right, that's not what I meant

of another namespace

so another schema (forwarding) applies

http://tools.ietf.org/html/rfc3922 already had <presence/> within <presence/> (but a different namespace)

AIUI

Kev, +1 surprise, surprise! :)

Oh, you're right MattJ.

Excellent.

!agendaup

Kev: 6) Date of next meeting

Ok, so, daylight savings change.

Next week suits me

heh

So I propose next Wednesday at 1500GMT.

Wed 1600 Kevin Time. If he's in an unusual timezone for him, so help us all.

linuxwolf: Indeed. That's why I noted just before the US started changing that we weren't shifting Council yet :)

1500GMT? Why the change?

MattJ: So it remains 4PM UK time.

I never change my clocks for DST :)

heehee

good for you

MattJ: that explains a lot (-:

Heh

I just use the sundial in my back yard

Ok, I'm happy with 1500GMT next week

Is everyone happy with this?

so 15:00 GMT?

sure

or to use the sundial in stpeter's back yard

heh

fine either way

stpeter: Thanks.

!agendaup

Kev: 7) Any other business

ok

linuxwolf !

it's doubtful that I'll attend next week's meeting

ok

so, I'd like to propose a caps URL format recommendation, if clients are interested in reporting version/platform info

let's see, I'll be in the CORE WG session at that time

stpeter: Enjoy Prague :)

I shall, thanks :)

anyway

linuxwolf?

oh yes, so

we need CSN in these meetings :)

stpeter: I said that last week.

RT: linuxwolf: so, I'd like to propose a caps URL format recommendation, if clients are interested in reporting version/platform info

linuxwolf: Right, I'm waiting for your next line after that :)

linuxwolf, I don't understand, please continue

(calendar updated)

hold on…shooing away IRL trolls

heehee

Grab a piece of chalk and draw a circle around your desk

ok, so the idea is to inconspicuously indicate the version/platform via "query parameters" to the caps node URL, assuming a client sends a URL (per recommendations)

haha

e.g. http://outer-planes.net/matts-magical-client?v=2011.03.12314&p=linux

and doesn't impact the actual caps hash

:)

yeah, I'd like to see iq:version DIAF

linuxwolf, ok, why this?

I would like to fix caps hashes :)

MattJ: because large organizations like to know what clients their users are logging in with, without laying down the lockout hammer

yes, we do need to fix the security hole that waqas found

definitely

So, I have no particular opinion on this until I've seen some examples.

RT: linuxwolf: e.g. http://outer-planes.net/matts-magical-client?v=2011.03.12314&p=linux

Yeees.

I meant slightly more of an exposition than that :)

heh

or, say, http://ww.cisco.com/go/jabber?v=8.0.3&p=mac

linuxwolf, why not just file a bug with the relevant clients?

Say "it would be really nice if you included the version and platform in your caps url"

well, it's hard to file a bug if there's not defined (recommended) format

I don't think I have any particular objections to this, I'd have to sit down with 115 and the new spec and be sure there's no unfortunate interactions.

and I likely would…it would be nice for us to agree to a general format

So...bring on the spec :)

well…so with the 115 problems

I don't see why we need to define such a format, it's not for interop and I don't think anyone is going to enforce it

do we want a separate spec, or an implementation detail within 115 (as we fix 115)

MattJ: You can say the same about iq:version :)

MattJ: It actually is for interop

Kev, I bet someone, somewhere, has used iq:version for interop

linuxwolf: I *think* a sidenote in 115, but I don't feel strongly.

iq:version needs to DIAG (-:

I can go either way

fixing 115 is not a small task

I don't think I know DIAG. What's 'G'?

gah

Ah.

DIAF

Gulag?

No, I like DIA Gah

lol...literally

ok

Anyway, I think we're vaguely done with this are we?

there you go

so, I (or some minion) can writeup a tiny XEP about it

linuxwolf: Sure.

I don't know if I want to tackle fixing hashes at the same time we add this note

Sounds like a plan

ah, to have minions

that'd be nice

So

technically, my minions are loaned to me

!agendaup 0

Kev: 7) Any other business

/fini

!done

or wait, is that not-done?

!agendaup

Kev: 8) Fini.

Thanks all :)

adios

!agendaup -8

Kev: 0) Fini.

Wow, on the dot

!agendaclear

Kev: Done.

specs even

:P

cio

who is the cio?

that's an italian typo - he meant ciao

I figured :)

although my Czech friends spell it "čau" :)