XMPP Council - 2010-07-12

greetings and salutations

Evening.

hello there-

Quorum early, whatever is the world coming to?

mattj sent apologies?

Matt'll be here.

maybe he sent apologies for being here :)

I'm not that apologetic

Right, no sign of Ralph being online at the moment, so let's start

1) Roll call.

Fritzy, Kev, Matt, Remko here.

2) Agenda bashing

None

Peter sent a bunch, anyone else?

Ok.

nope

Ralph is probably still in mourning over the World Cup

I went over Peter's

3) XEP-0060: Publish-Subscribe http://xmpp.org/extensions/tmp/xep-0060-1.13.html http://xmpp.org/extensions/diff/api/xep/0060/diff/1.12/vs/1.13rc18 Accept version 1.13? At last vote, Ralph had comments on the spec - last week Ralph confirmed these have been addressed, so I'm hoping we can get this chapter of pubsub closed now!

+1

+1

I checked the diff from the last version I reviewed, and this seems fine, I'm +1

+1

4) JID Mimicking. We can either leave this in 165 and move that along to active, or split what we need into 3920bis so we can remove the reference. Thoughts?

I don't have a strong opinion either way.

as I noted to Kev, Ralph's feedback came in over time, so there were several revisions to address it all, thus http://xmpp.org/extensions/diff/api/xep/0060/diff/1.13rc13/vs/1.13rc18 is the diff that Ralph cares about, I think

hi

Dave suggested that a XEP as a more fluid spec would be better for this, and I'm fine with that.

Evening Ralph.

Want to vote on pubsub? We're only on the second item.

I just got home, and first have to put the kid in bed

Ok, we'll see you shortly then.

kev: so that is the second alternative?

remko: Dave suggests advancing the XEP to active, and leaving 3920bis with a reference.

iirc someone mentioned splitting it (I thought Dave?)

Let me pull that conversation back up to remind myself

MattJ: possibly, I thought tha was Peter's suggestion.

It could well have been

well I stole stuff from 165 and put it in the Internet-Draft

kev: do we reference XEPs a lot in rfcs?

and that stuff can IMHO remain in that I-D because it is more generic

remko: only a couple.

how we solve the problem is another question -- XEP-0165 has some ideas, but they are preliminary and not yet field-tested

yeah, the problem is convenience vs. security as always

psa: What's your preference?

and it's hard to say where the line is drawn until there are some implementations that follow the recommendation.

Kev: in fact there are lots of informational references to XEPs now, however all but two of them are Draft/Final/Active -- the two exceptions being 165 (not sure if that's needed) and 201

psa: right.

my preference is to remove the reference to 165

Although I hadn't realised it was 'lots'

since I've borrowed all the fundamental content

psa: same here

Yes, it was stpeter; http://mail.jabber.org/pipermail/council/2010-July/002919.html

and I'm +1 to this

see for instance http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-07#section-14 and http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-10#section-16 (but you'll need to scroll down a bit)

I admit that I was swayed by Dave's argument, but I'll go along with the majority if they disagree.

so I think 165 is awfully preliminary, but that 201 is more stable and deserves to move forward or at least have a Last Call

s/165/the practical solutions in 165/

it assumes that clients store the roster as raw xml

among other things, perhaps

or rather, cache it that way

So, there's nothing for Council to actually do on this, right? Just generally nod about the right way to do it.

Kev, I agree with what Dave says as far as "Best practices change over time (and thus a XEP number is a more stable reference), and are defined with and by the community (hence better done within the auspices of the XSF)."

anyway, those practical recommendations are experimental and if we really cared we'd put more work into it

Kev: right

Kev, but I see much of 165 as not being just "best practices"

MattJ: correct

anyway as editor of 3921bis I'll remove the reference :)

right, there's a real extension buried in there.

indeed

ok

moving on? :)

Ok, good enough then.

5) 201

y'all'll have plenty of chance to review 3291bis soon :)

Another reference.

right, another ref

So, I'd have thought just advancing 201 wouldmake sense.

but this one is more stable and useful

we had some review of it a while back and I/we cleaned it up at that time

"I think my only complaint on this one (and 3921bis) is that it requires (quite strongly) the contents of <thread> be a UUID. Elsewhere it says that the ThreadID is an opaque string, and I can imagine there would indeed be cases when it would be useful to have some other kind of identifier there instead."

in 5.1 of xep201 it suggests that you don't destroy a thread when they go offline.

Curious whether I'm alone in this

Fritzy: that's an Ianism :)

psa http://www.urbandictionary.com/define.php?term=ianism?

An ex-member of Council.

MattJ I think it could be made more consistent.

Most of the complicated XEPs he had input into.

:)

Ian's speciality was injecting complexity

In any case, it suggest that you don't destroy it then, which you can infer you're never supposed to destroy a thread-id.

which we didn't fight strongly enough

Fritzy: yep, nothing like a Last Call to get people to review the spec... ;-)

We were young and foolish :)

So: Issue a last call?

I agree that there are things that need to be fixed in 201

After which we'll address comments like these?

and in 3921bis regarding threads

oops... did WGLC on xmpp-address end today? Forgot all about it...

but we can do those concurrently

sounds good to me then.

+1 on Last Call

+1

+1 on last call too

MattJ: I think the MUST for UUID is unnecessary

+1.

back

psa: right.

MAY even, seems appropriate

psa, excellent, thanks :)

I think that might have been an Ianism too

Yay

This feels like a public shaming.

6) 269 (Jingle early media).

haha

Authors would like a last call.

I found something interesting out earlier this week.

I'm with MattJ on the UUID stuff

Fritzy, he practically disappeared mid-term without a trace, I don't think he'll mind much :)

If authors request a Last Call, and Council then vote not to advance it to draft, it's immediately rejected, rathe than staying Experimental :)

I still have time to submit a revised 3921bis before tonight's deadline :)

Anyway, I'm not opposed to a last call if the authors want one.

neither am i

+1

Kev, is that intentional or a loophole?

It sounds right, actually.

+1

I think it might make sense to ask for feedback on the Jingle list, but that can be done at the same time

Last call sounds fine +1

Kev, does it?

LastCall is used to address feedback to gain consensus.

psa: sure, they should be paying attention to last calls. ;)

It should only go to vote once it's got consensus that this is the right thing.

Kev: according to?

I don't care so much about early media but the spec is stable and implemented

ralphm: xep 1

consensus among whom?

standards-jig.

Anyway

This is strictly irrelevant to the current vote :)

right

as this isn't a vote

It is.

Issuing a last call is voted on.

Anyway...

7) XEP-0266 (codecs).

right, not a vote on the advancement, we're in agreement

I'm happy for this to have both the codecs in.

The spec kind of waxes poetical about patent free and distribution free.

dito

If we want interop, it seems the right thing to do - I'm not sure what Council needs to say on this, isn't it waiting for the XEP author to update to meet the consensus, and then ask for a vot?

Fritzy: heh yeah :)

And after the vot, ask for a vote.

that's the most basic encoding in RTP, right?

ralphm: http://xmpp.org/extensions/diff/api/xep/0060/diff/1.13rc13/vs/1.13rc18 is the diff that addresses all of your pubsub feedback, for your reading pleasure when you have the time

psa: yeah, I noticed the dc stuff, too. Why was that removed?

So if thee's nothing to do for 266 here, onto

8) Date for next meeting.

ralphm: dc?

Next Monday, usual time?

Kev: right, 266 needs to be updated

Kev, +1

+1

I'm game for Monday.

wait

that'll be the Summit, right?

yes it will

I'll be at the Summit in Portland.

psa: dublin core

So, my availability is questionable.

anyone else going?

and unfortunately some personal/family stuff has come up so I don't think I'll be at the Summit

ralphm: it was purely informational and confusing people

psa: ah, too bad

I'll not be at the Summit, unfortunately

psa: ah

I'll go and represent then.

;)

psa: I also noticed a typo in the edit of example 155

I need to ping bear too

ralphm: ok great, bug reports are welcome

Ok, so - are we skipping a week until summit's over?

That's what I suggest, or do it later in the week.

i have no problem with that

We skipped for Brussels iirc, but then 100% of the council was there :)

psa: you removed a closing quote

Kev: sure

Ok, week Monday, then.

Anyone planning on going to Maastricht?

9) Any other business?

no

nodda

ralphm: possibly.

ralphm: fixed

I'm undecided on Maastricht, I think it's more than I can afford right now though

Kev: any ideas on when?

Likely just XMPP day.

That's the Thursday, right?

yes

psa suggested some hacking on sunday?

IETF has day passes now

psa: right.

Ok, without AOB I suggest we close.

ralphm: only Florian pinged me in reply and he mostly just wants to find a good party I think :)

ok, bibi

2 minutes off my half-hour meeting tolerance.

Thanks all.

:)

psa: train?

psa: train?

um yeah

but I need to figure out where to change trains etc.

well I'll do that tomorrow

now I need to submit updated Internet-Drafts :)

Have fun.

indeed

I'll sort out minutes tomorrow.

ralphm: so you will review XEP-0060 and post to the list?

psa: in Leuven and in Luik/Liege :)

i'll wave from my window :)

psa: I think I'm +1

remko: :)

are UUIDs such a problem?

Tobias: no, but there is no reason for them to be a MUST

Tobias: people could do "interesting" things with ThreadIDs if we remove the UUID requirement

Kev: did you record my +1 on XEP-0060?

Indeed, the UUIDs aren't a problem, just the MUST :)

No, was there one?

Tobias: an opaque identifier suffices

I'll record it in the minutes anyhow :)

I think it is obvious that ThreadIDs should be different for different threads... what a ThreadID is and which messages get what ThreadID is up to the implementation :)

UUIDs might be a burden to implement

(even though the mechanics are pretty simple, low-end devices might not want to devote cycles to that for no gain)

burden or not, they are unnecessary (as a MUST)

psa: yeah, that was collateral reasoning

I'm really sad about not making it to Portland

me too

Same.

Same

Let's just make the next FOSDEM 10x better to show them that :)

also, it would be the 10th summit

I'd rather do Portland than Fosdem, TBH.

unfortunately I need to be away for 12 days all told for IETF meeting + ITU-T meeting on the Monday after, and that's all I can afford right now

Kev: agreed

I actually quite liked Portland, Brussels not so much.

Kev, considering the travel is the least enjoyable part for me, I'd prefer making it as short as possible :)

I dislike the travel, a lot.

I don't really mind

But I dislike being somewhere I don't like more.

as long as it is a direct flight, that is

I really dislike being places where English isn't the first language - even Brussels.

Kev: lol

Aww, I like that... it makes things more interesting :)

Kev: how come you like Portland, then?

anyway, I can manage French a touch

ralphm: point.

hey hnow

Heh

Fritzy, the sooner y'all'll realise you're not speaking English the better off we'll both be :)

y'all is a southern thing

indeed

I lived in Atlanta for 2 years

Pretty small region uses that.

and yes some folks really do say "y'all'll" -- gotta love that!

Heh

but I'm not one to talk, since I was born in NY :)

There are some spelling differences, but other than that, it's the same language.

Fritzy: don't worry, this is a running joke with Kev

I'm familiar with it.

ok :)

Kev and I argue about stuff all the time.

Talking of running, I'll be off for a bit :)

ciao

bye!

psa: you're syncing up with Bear on the Summit? I'll synch up with him then.

psa: I've got to announce that hackfest still.

I should do that today after talking to Bear.

do I read the record correctly that we're finally done with XEP-0060?!?!

yes

ok

I'm going to remove all the definitional stuff from XEP-0201 because it's in 3921bis now -- no good reason to define it in two places :)