XMPP Council - 2012-02-15

I'm having a somewhat distracted day. I'm not intending going anywhere, but in case I fail to notice the time later, could someone please send me a message when the time comes.

sure

Thanks.

Yees.

this is going to bug me all day

On a yoghurt I'm about to eat (although it's a "0% fat" one, which seems to mean "tastes icky"): "suitable for vegetarians".

One assumes this is contrary to the usual bacon yoghurts, which aren't.

well, there's vegetarians and there's Vegerians

or vegans

which wouldn't eat yogurt if any part came from an animal is some form … such as milk

don't forget the fruitarians!

vegitarivores and meatarians

linuxwolf: It doesn't claim to be suitable for vegans (which, given it's made from milk, would probably be difficult).

very true

I wonder if they removed all the bacteria … which wouldn't make it yogurt

They certainly removed all the nice.

I'm sure that when I was (much) younger, fruit yoghurts used to taste of fruit. Sometimes even the one advertised on the packaging.

0% fat is almost never a good idea

I didn't notice any fruit yoghurts that weren't fun-free :/

when we were younger, fruit yogurts actually contained fruit

now they have "natural and artificial flavors"

I *like* cherries.

I'm sure I do.

They taste fruity and nice.

you're best bet is to get plain yogurt, add fruit, and blend

maybe some honey too

and how did we get on this topic? ;-)

Also: Bacon.

stpeter: I'm whining about eating a fun-free yoghurt.

now I'm hugry

hungry within a minute joining the xmpp council muc.

let's get this over with so I can address that hunger thing

Yeah, I was until I tasted this yoghurt, too!

I think I'll have a ham-and-cheese panini

have we pinged Ralph and Matthew?

I have (just)

just pinged Ralph

hehe

oh shoot, gotta join the IETF Tools Team call

pinged matt

Righty.

1) Roll call

I'm here!

AOL

presente

Here!

here

Amazing.

2) Spec length

What to do about -45 and -60?

Too long.

XEP-0312: TL;DR

I doubt anyone will argue too short

Well there are obviously only two things we can do: split or remove

heh

Right, so, I don't argue with splitting MUC into essentially two - Administration and Usage or something.

Makes sense

Although I'm not sure what it buys us, really, other than two shorter specs.

We want servers to implement all of it, regardless.

I suppose clients could just implement the non-admin bits (as Swift did for a while).

I think we'd end up with some duplication, with regards to join/create

Well splitting MUC makes less sense for others, I think

*less sense than for others

I haven't really considered splitting MUC

OTOH I have a growing list of things I'd like to see removed from XEP-0060

For XEP-0060 there are a lot of optional features

that could be moved to their own spec

yeah, XEP-0060 could benefit from breakup

not sure about MUC right now

Ok, so is it fair to say that rough consensus is that -45 should be left alone, wrt. splitting it?

I'm convinced there are a whole bunch of features in XEP-0060 that *nobody* is using

there you have some very basic use cases that you can build upon

Splitting -60 seems fine to me, although I don't know it in enough depth to suggest where.

I think MUC isn't too bad

for MUC, I do think we could fairly easily split the dumb-client parts from the moderator/admin/owner use cases -- and *most* clients don't support any of the latter

We just need to be sure not to add to it

do you think the duplication would be much when splitting basic chat features and complex admin stuff for MUC?

I wouldn't be opposed to an admin/user split of the spec

Tobias: Well, you've got room creation, kicking and things.

stpeter: probably, although some discussion in the "dumb-client" spec would need to talk about create in some referential manner

linuxwolf: for sure

So a dumb client may not be able to kick, but should still know what being kicked looks like.

right

yeah

Kev, but these would only be added by the admin spec, wouldn't they...basic clients would still understand normal errors and such

sure, you need to discuss roles etc in the core spec

ralphm: true

So, my rough stance on this is that I'm not opposed to a sensible split for -45 into dumb client and admin, but that I think getting such a split would be hard work that I'm not looking forward to having to review, and very much want to not have to do.

In fact the main advantage I see of splitting 45 as it stands is that we can experiment with e.g. defining other protocols for admin of a room/service

so I think it might be useful to take a look at 45 and see what it would look like with the moderator/admin/owner stuff moved to a separate spec

nod

sure

MattJ: yes, ad-hoc commands in MUC is on my list :)

Mine too

Below MAM :)

heh

my workflow is slowing down with the impending end of my IESG term, so I'll have more time soon

Ok, so, pubsub everyone's happy with being split.

s/changes/charges

Kev: definitely

I don't think we need to discuss this further then, do we?

not presently

Kev: I can take a quick/rough pass at 45

I'll take -45 changes as they come, but I have assorted reservations that I'm happy to have removed by seeing something that works.

Kev: I think it would be worth discussing 60

clearly there's a lot in 60

stpeter: Now, or when we have some sort of split pencilled up so we can discuss it?

well, have people looked at 60 and thought about how we might split it up?

same kind of thing?

how about we start with everyone's list of "please remove"

a bit

most of the configuration bits could be moved out

I'm still in the process of XEP-0060 review

i.e., admin/owner/etc. vs mere publish and subscribe?

I've thought about it, but haven't gone into much detail

I haven't, I think everyone else here has a better grasp of pubsub than I do.

for nodes, subscriptions and pre-conditions

I think that pub and sub are pretty simple, really

so I'll probably have a better list when I submit my feedback to the list

stpeter: yeah

ok

so it sounds like we can circle back on this topic in a few weeks

/nod

and perhaps start a thread on the pubsub@ list?

+1

I can start a thread on muc@ when I take a rough pass at the split

3) Last call on XEP-0267

even for subscriptions... I think things like "multiple subscriptions" should be (re)moved (or at least fixed)

I'd very much like to see XEP-0060 be a very stripped down spec that explains the core use case, with references to other specs for enhanced behaviour

+100

+1

I'll have a pass at XEP-0060 and make a list

ralphm: super

Do we have implementations of 267 deployed/used now?

garzie

grazie even

gah

Kev: I don't know

Kev: there's an implementation in Prosody (experimental) but I've not yet had time to deploy it at xmpp.net

I'd be happy to wait

I'm not opposed to Last Calling it I guess, but I'm unlikely to want to push it to Draft.

and I haven't looked at it or tested it yet

right

two would be nice

how about I test it out at xmpp.net first

wfm

+1

sounds like a plan

Ok. I may even have comments about it, I think.

stpeter: I think multiple implementations is still a great thing to have

I treat Experimental as "Not obivously broken" and Draft as "The way we have consensus on solving this", mostly (and Final as "done deal").

ralphm: always, the question is: is that a requirement for advancement? XEP-0001 doesn't say that

I think the current state of 267 is that we don't know that this is the right way to do this as we've not tried it.

but that's a topic for a future meeting

Kev: probably

Or, to phrase it slightly better, it can't stop being Experimental until there's been an experiment.

thought experiments can go far, but maybe not far enough

right, so the non-requirement kinda makes it easier to assert if it is the right way to do a thing

anyway

I think we have a path for 267

We've explicitly made the bar to Experimental very low in recentish meetings.

more experimentation on the way :)

the bar as been lower (-:

Kev, *ahem* :)

Kev: I've never lowered the bar, I don't think it should be very high at all

but draft should be

I'm with ralphm

Right, that's what I said, isn't it?

We've discussed this recently and agreed that the bar to Experimental should be very low.

right

It doesn't imply that Draft should be that low.

yes, but some of us started very low, and others needed to move (-:

so I am again arguing for actual implementations (plural) to move forward

anyway, we're in general agreement, so let's move on (-:

I don't need multiple implementations to persuade me it's Draft ready - but it's the easiest way to persuade me.

linuxwolf: right.

4) Last call on XEP-0297

+1

are there multiple implementations?

(BTW, a quick visual comparison of http://xmpp.org/extensions/xep-0045.html#moderator and http://xmpp.org/extensions/xep-0045.html#statuscodes indicates that we'd cut about 40% of XEP-0045 by moving the moderator/admin/owner use cases)

i don't know of a single implementation

linuxwolf: I think there are, actually, aren't there?

(but I'll post to muc@ about that....)

MattJ has one for Prosody

right?

and a client one in Verse

ah...ok

As the BC guys are using MAM, which uses it.

Zash wrote both

/-:

nice

and yes, BuddyCloud

ok then

+1 for last call

Right.

I'll make my comments during LC

I'm ok with Last Calling this.

that's why I'm interested in seeing this done

which are related to Carbons

http://archive.jabber.org/docs/proto-draft/envelope.html

i gave it a read earlier and it made sense and sounds logical...so +1 for this

was wat it reminds me off, and XEP-0033's claim that it supersedes that

Heh

I've been around for a bit I suppose

(-:

I think I actually tried to implement that, too

I think we need -297 LC votes from Ralph and Tobias?

I think, contrairy to its claim, that jabber:x:envelope might actually have implementation

that said, I'm +1 on LC

i'Ve only implemented / used XEP-0033 some years ago

Kev, see 16:22

+1

this spec is richer and more well defined

Tobias: Ta.

Ok, moving ever onwarsd.

especially the security considerations

Also, onwards.

5) http://gitorious.org/xmpp/xmpp/blobs/master/extensions/xep-0166.xml#line1399

ralphm: envelope was only meant to be the addressing bits, −297 really does wrap another (message) stanza

Is that line redundant?

It looks it to me.

linuxwolf: yeah, I suppose. It's just juggling elements :-)

Kev, where is the same already said? or is the behavior described common sense?

linuxwolf: one might argue that embedding a message in another element makes backwards compatibility harder

Tobias: There was a thread about this on the mailing list.

I missed the thread

I wonder if I can find it.

But the summary was that the error it refers to doesn't exist.

ralphm: that's what explicit namespace declarations are for (-:

so am lacking any context or opinion (it seems sensible)

I don't recall that jingle thread

MattJ: we discussed this on the jingle@ list

linuxwolf: as an aside, Blain Cook asserted the same thing about Atom payloads and pubsub events.

Nor is there anything in 166 that talks about encrypted streams to use this on.

and on standards@

wel

linuxwolf: in that he'd like it better if the payload was outside the pubsub element

actually

http://mail.jabber.org/pipermail/standards/2012-January/025717.html

that's the start of the thread

so I only forwarded my conclusions to the jingle@ list

That's the one, thanks Peter.

anyway, no hurry

we can discuss next week

or on the list

yeah

I need to rebuild my context

Ok.

6) Date of next meeting.

it was sent on my b-day … I ignored a lot of email that day (-:

SBTSBC?

+1

+1

heh

looks up what it means

wfm

Same Bat Time Same Bat Channel

I assume it's same bat time, same bat channel

Tobias: I don't *think* it's an established acronym, just one I use.

linuxwolf: Right.

I should be

it

Kev likes to channel Adam West

ah...k

+1 then

Tobias: We went through a period where I'd say "same bat time same bat channel" for this agenda item. So I started abbreviating.

7) AOB?

s/Adam West/William Dozier/

no AOB from me

nack

Nor anyone else, it seems.

Ok then.

yay

Thanks all :)

Thanks

now I don't know what to do when I'm pondering

I have some almost-yoghurt you could eat!

heh

I think I might have a fancy wood pencil

aha!

found my pencil bag

linuxwolf: now that I'm using PGP more often, you and I might want to do a keysigning sometime ;-)

that would require me to use PGP d-:

linuxwolf: you usually sign your @cisco mail, don't you?

I do

CMS

oh

(-:

did I read channels? buddycloud channels?

Astro: bat channels

:)

I can get my PGP key printed on my business cards, but not my cert

linuxwolf: I go back and forth between PGP, S/MIME, and nothing

linuxwolf: however, in my experience very very few people us S/MIME, whereas PGP is mildly useful for sending messages encrypted

I even use openpgp for IM messages at times (at least with migri, who helps out with xmpp.org list administration)