psareviews http://xmpp.org/internet-drafts/draft-saintandre-tls-server-id-check-08-from-7.diff.html in preparation for submission
remkomattj sent apologies?
KevMatt'll be here.
psamaybe he sent apologies for being here :)
MattJhas joined
MattJI'm not that apologetic
KevRight, no sign of Ralph being online at the moment, so let's start
Kev1) Roll call.
KevFritzy, Kev, Matt, Remko here.
Kev2) Agenda bashing
MattJNone
KevPeter sent a bunch, anyone else?
KevOk.
Fritzynope
psaRalph is probably still in mourning over the World Cup
FritzyI went over Peter's
Kev3) 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!
Fritzy+1
MattJ+1
KevI checked the diff from the last version I reviewed, and this seems fine, I'm +1
remko+1
Kev4) 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?
KevI don't have a strong opinion either way.
remkofeels like joining as ra1phm and voting on this topic
ralphmhas joined
psaas 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
ralphmhi
KevDave suggested that a XEP as a more fluid spec would be better for this, and I'm fine with that.
KevEvening Ralph.
KevWant to vote on pubsub? We're only on the second item.
ralphmI just got home, and first have to put the kid in bed
KevOk, we'll see you shortly then.
remkokev: so that is the second alternative?
Kevremko: Dave suggests advancing the XEP to active, and leaving 3920bis with a reference.
MattJiirc someone mentioned splitting it (I thought Dave?)
MattJLet me pull that conversation back up to remind myself
KevMattJ: possibly, I thought tha was Peter's suggestion.
Kevconsults archive.
MattJIt could well have been
psawell I stole stuff from 165 and put it in the Internet-Draft
zanchinhas joined
remkokev: do we reference XEPs a lot in rfcs?
psaand that stuff can IMHO remain in that I-D because it is more generic
Florobhas joined
Kevremko: only a couple.
psahow we solve the problem is another question -- XEP-0165 has some ideas, but they are preliminary and not yet field-tested
Fritzyyeah, the problem is convenience vs. security as always
Kevpsa: What's your preference?
Fritzyand it's hard to say where the line is drawn until there are some implementations that follow the recommendation.
psaKev: 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
Kevpsa: right.
psamy preference is to remove the reference to 165
KevAlthough I hadn't realised it was 'lots'
psasince I've borrowed all the fundamental content
remkopsa: same here
MattJYes, it was stpeter; http://mail.jabber.org/pipermail/council/2010-July/002919.html
MattJand I'm +1 to this
psasee 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)
KevI admit that I was swayed by Dave's argument, but I'll go along with the majority if they disagree.
psaso I think 165 is awfully preliminary, but that 201 is more stable and deserves to move forward or at least have a Last Call
psas/165/the practical solutions in 165/
Fritzyit assumes that clients store the roster as raw xml
psaamong other things, perhaps
Fritzyor rather, cache it that way
KevSo, there's nothing for Council to actually do on this, right? Just generally nod about the right way to do it.
MattJKev, 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)."
psaanyway, those practical recommendations are experimental and if we really cared we'd put more work into it
psaKev: right
MattJKev, but I see much of 165 as not being just "best practices"
psaMattJ: correct
psaanyway as editor of 3921bis I'll remove the reference :)
Fritzyright, there's a real extension buried in there.
psaindeed
psaok
psamoving on? :)
KevOk, good enough then.
Kev5) 201
psay'all'll have plenty of chance to review 3291bis soon :)
KevAnother reference.
psaloves it when he gets to use "y'all'll" :)
psaright, another ref
KevSo, I'd have thought just advancing 201 wouldmake sense.
psabut this one is more stable and useful
psawe had some review of it a while back and I/we cleaned it up at that time
MattJ"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."
Fritzyin 5.1 of xep201 it suggests that you don't destroy a thread when they go offline.
FritzyMattJ I think it could be made more consistent.
KevMost of the complicated XEPs he had input into.
psa:)
psaIan's speciality was injecting complexity
FritzyIn any case, it suggest that you don't destroy it then, which you can infer you're never supposed to destroy a thread-id.
psawhich we didn't fight strongly enough
psaFritzy: yep, nothing like a Last Call to get people to review the spec... ;-)
KevWe were young and foolish :)
KevSo: Issue a last call?
psaI agree that there are things that need to be fixed in 201
KevAfter which we'll address comments like these?
psaand in 3921bis regarding threads
MattJoops... did WGLC on xmpp-address end today? Forgot all about it...
psabut we can do those concurrently
Fritzysounds good to me then.
Fritzy+1 on Last Call
remko+1
MattJ+1 on last call too
psaMattJ: I think the MUST for UUID is unnecessary
Kev+1.
ralphmback
Kevpsa: right.
KevMAY even, seems appropriate
MattJpsa, excellent, thanks :)
psaI think that might have been an Ianism too
MattJYay
FritzyThis feels like a public shaming.
Kev6) 269 (Jingle early media).
MattJ's heart lightens
psahaha
KevAuthors would like a last call.
KevI found something interesting out earlier this week.
ralphmI'm with MattJ on the UUID stuff
MattJFritzy, he practically disappeared mid-term without a trace, I don't think he'll mind much :)
KevIf authors request a Last Call, and Council then vote not to advance it to draft, it's immediately rejected, rathe than staying Experimental :)
psaI still have time to submit a revised 3921bis before tonight's deadline :)
KevAnyway, I'm not opposed to a last call if the authors want one.
remkoneither am i
ralphm+1
MattJKev, is that intentional or a loophole?
KevIt sounds right, actually.
MattJ+1
psaI think it might make sense to ask for feedback on the Jingle list, but that can be done at the same time
FritzyLast call sounds fine +1
MattJKev, does it?
KevLastCall is used to address feedback to gain consensus.
Fritzypsa: sure, they should be paying attention to last calls. ;)
KevIt should only go to vote once it's got consensus that this is the right thing.
ralphmKev: according to?
psaI don't care so much about early media but the spec is stable and implemented
Kevralphm: xep 1
ralphmconsensus among whom?
Kevstandards-jig.
KevAnyway
KevThis is strictly irrelevant to the current vote :)
ralphmright
ralphmas this isn't a vote
KevIt is.
KevIssuing a last call is voted on.
KevAnyway...
Kev7) XEP-0266 (codecs).
ralphmright, not a vote on the advancement, we're in agreement
KevI'm happy for this to have both the codecs in.
FritzyThe spec kind of waxes poetical about patent free and distribution free.
remkodito
KevIf 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?
psaFritzy: heh yeah :)
KevAnd after the vot, ask for a vote.
ralphmthat's the most basic encoding in RTP, right?
psaralphm: 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
ralphmpsa: yeah, I noticed the dc stuff, too. Why was that removed?
KevSo if thee's nothing to do for 266 here, onto
Kev8) Date for next meeting.
psaralphm: dc?
KevNext Monday, usual time?
psaKev: right, 266 needs to be updated
MattJKev, +1
remko+1
FritzyI'm game for Monday.
Fritzywait
Fritzythat'll be the Summit, right?
psayes it will
FritzyI'll be at the Summit in Portland.
ralphmpsa: dublin core
FritzySo, my availability is questionable.
Fritzyanyone else going?
psaand unfortunately some personal/family stuff has come up so I don't think I'll be at the Summit
psaralphm: it was purely informational and confusing people
Fritzypsa: ah, too bad
ralphmI'll not be at the Summit, unfortunately
ralphmpsa: ah
FritzyI'll go and represent then.
Fritzy;)
ralphmpsa: I also noticed a typo in the edit of example 155
psaI need to ping bear too
psaralphm: ok great, bug reports are welcome
psalooks
KevOk, so - are we skipping a week until summit's over?
FritzyThat's what I suggest, or do it later in the week.
remkoi have no problem with that
MattJWe skipped for Brussels iirc, but then 100% of the council was there :)
ralphmpsa: you removed a closing quote
ralphmKev: sure
KevOk, week Monday, then.
ralphmAnyone planning on going to Maastricht?
Kev9) Any other business?
remkono
Fritzynodda
Kevralphm: possibly.
psaralphm: fixed
MattJI'm undecided on Maastricht, I think it's more than I can afford right now though
ralphmKev: any ideas on when?
KevLikely just XMPP day.
KevThat's the Thursday, right?
psayes
ralphmpsa suggested some hacking on sunday?
psaIETF has day passes now
Kevpsa: right.
KevOk, without AOB I suggest we close.
psaralphm: only Florian pinged me in reply and he mostly just wants to find a good party I think :)
remkook, bibi
Kev2 minutes off my half-hour meeting tolerance.
KevThanks all.
Fritzy:)
Kevbangs the gavel.
psastill needs to figure out how to get from BRU to Maastricht
remkopsa: train?
Kevpsa: train?
psaum yeah
psabut I need to figure out where to change trains etc.
psawell I'll do that tomorrow
psanow I need to submit updated Internet-Drafts :)
KevHave fun.
psaindeed
KevI'll sort out minutes tomorrow.
psaralphm: so you will review XEP-0060 and post to the list?
remkopsa: in Leuven and in Luik/Liege :)
remkoi'll wave from my window :)
ralphmpsa: I think I'm +1
psaremko: :)
psasubmits a new 3921bis with no more MUST for UUID
Tobiasare UUIDs such a problem?
remkohas left
psaTobias: no, but there is no reason for them to be a MUST
psaTobias: people could do "interesting" things with ThreadIDs if we remove the UUID requirement
ralphmKev: did you record my +1 on XEP-0060?
MattJIndeed, the UUIDs aren't a problem, just the MUST :)
KevNo, was there one?
ralphmTobias: an opaque identifier suffices
KevI'll record it in the minutes anyhow :)
MattJI 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 :)
ralphmUUIDs might be a burden to implement
ralphm(even though the mechanics are pretty simple, low-end devices might not want to devote cycles to that for no gain)
psaburden or not, they are unnecessary (as a MUST)
ralphmpsa: yeah, that was collateral reasoning
ralphmI'm really sad about not making it to Portland
psame too
KevSame.
MattJSame
MattJLet's just make the next FOSDEM 10x better to show them that :)
ralphmalso, it would be the 10th summit
KevI'd rather do Portland than Fosdem, TBH.
psaunfortunately 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
ralphmKev: agreed
KevI actually quite liked Portland, Brussels not so much.
MattJKev, considering the travel is the least enjoyable part for me, I'd prefer making it as short as possible :)
KevI dislike the travel, a lot.
ralphmI don't really mind
KevBut I dislike being somewhere I don't like more.
ralphmas long as it is a direct flight, that is
KevI really dislike being places where English isn't the first language - even Brussels.
TobiasKev: lol
MattJAww, I like that... it makes things more interesting :)
ralphmKev: how come you like Portland, then?
MattJanyway, I can manage French a touch
Kevralphm: point.
Fritzyhey hnow
MattJHeh
MattJFritzy, the sooner y'all'll realise you're not speaking English the better off we'll both be :)
Fritzyy'all is a southern thing
psaindeed
psaI lived in Atlanta for 2 years
FritzyPretty small region uses that.
psaand yes some folks really do say "y'all'll" -- gotta love that!
MattJHeh
psabut I'm not one to talk, since I was born in NY :)
FritzyThere are some spelling differences, but other than that, it's the same language.
psaFritzy: don't worry, this is a running joke with Kev
FritzyI'm familiar with it.
psaok :)
FritzyKev and I argue about stuff all the time.
MattJTalking of running, I'll be off for a bit :)
Fritzyciao
psabye!
Fritzypsa: you're syncing up with Bear on the Summit? I'll synch up with him then.
Fritzypsa: I've got to announce that hackfest still.
FritzyI should do that today after talking to Bear.
psaheats up some lunch
psado I read the record correctly that we're finally done with XEP-0060?!?!
Fritzyyes
psaok
psaI'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 :)
XMPP Council - 2010-07-12