Kanchil+Kev: 1) Roll call
2) Agenda bashing
3) Retract XEP-0192
4) Retract XEP-0193
5) Last Call on XEP-0262: Use of ZRTP in Jingle RTP Sessions
6) Vote on accepting version 1.1rc3 of XEP-0178: Best Practices for Use
7) Vote on accepting version 1.1rc1 of XEP-0171: Language Translation
8) Council concensus on removing Proposed from XEP-0001
9) Accept XEP-0220 version 0.6?
10) Accept XEP-0220 version 0.6?
11) Date of next meeting
12) Any other business
Fini
KevClose enough.
Vanaryonhas joined
Vanaryonhas left
stpeterhas joined
Kevwonders how many of the specs he'll have a chance to review before the meeting.
fippohas joined
MattJhas joined
stpeterhi MattJ
MattJHi
stpeterI'm going to check 198 into git
stpeterso that you can see the diff
MattJk
MattJthanks
MattJI'm confused about what is version 1.2 :)
stpeterwell
stpeter1.2 was confused in several respects
stpeterbut 1.2 is what's published on the website
stpeterI cleaned up all the XEPs to refer to 6120/6121
MattJOk, so 1.2rc2 is something else?
stpeterI don't think we want council votes on all those reference updates
MattJNo, we don't :)
KevI think we should probably have a Council item to say "Switch to 6120/6121 throughout".
KevNo-one's going to object, but they are technically non-trivial changes to the dependencies of the XEPs.
stpeterKev: well, there *are* exceptions because in some of the specs we legitimately refer to 3920 or 3921
stpetere.g., to reference Nodeprep or whatever
KevRighty.
stpeterthose references have been retained
stpeterbut sure, a vote on that switch seems good
linuxwolfhas joined
stpetermaybe we should make suite definitions while we're at it, although it's unclear to me if anyone ever used those
Florobhas joined
benehas joined
stpeterearly agenda bashing ... I think that XEP-0178 is not quite ready for approval because fippo and I are still working out some fine points in the document on the standards@xmpp.org list
KevRight, I was going to suggest that.
MattJOk, I'll stop reviewing it now then :)
stpeterreplies to fippo's latest email before the meeting begins
stpeterI also have a conference call starting in 12 minutes (I'm now the IESG liaison to the IETF Tools Team, yay!), but I don't know how much attention that will take
linuxwolfsounds like fun
stpeterindeed
Kevlinuxwolf: it does? :)
linuxwolfno, it does not (-:
linuxwolfthat was sarcasm
stpeterlinuxwolf: you'll be happy to hear that I also had a HYBI WG coordination call at 11 last night :)
linuxwolfdid it involve AES-CTR?
linuxwolf(-:<
stpeterno!
linuxwolfgood
linuxwolfI noticed you actually posted something to the hybi list, too
stpeterjust using one of the reserved opcodes to signal if masking is enabled
ralphmhas joined
stpeterhi ralph!
linuxwolf/nod … but the oddest things become a hill to die on over there
ralphmhas left
ralphmhas joined
ralphmhi
MattJGah, phone... brb 2 minutes
stpeterfippo: I've replied to you on the list
KevMay as well get started, and let Matt catch up?
KevOr wait for him?
linuxwolfI can catch up (-:
linuxwolftrolls the vagueness
stpeter:P
KevSo
Kev!agendaup
Kanchil+Kev: 1) Roll call
linuxwolfpresente
ralphmhere
KevMattJ's largely here.
KevI'm certainly here.
KevWe're missing a Fritzy - I don't remember him saying he'd miss it, I should check I guess.
KevWill do so before the minutes.
Kev!agendaup
Kanchil+Kev: 2) Agenda bashing
KevAnyone?
linuxwolfhas left
linuxwolfhas joined
stpeterI bashed about 178
KevYou did.
stpeterbefore the meeting started
KevOnward, then.
Kev!agendaup
Kanchil+Kev: 3) Retract XEP-0192
MattJSorry, back
stpeterwe also talked about the 6120/6121 updates
KevPoint.
Kev!agendaappend 6120/6121 updates.
Kanchil+Kev: Done.
stpeterthanks
KevSo.
stpeternothing else here
Kev!agendaup 0
stpeterI might have an AOB or two
Kanchil+Kev: 3) Retract XEP-0192
Kev+1
MattJ+1
linuxwolf+1
ralphmthis is kinda odd
ralphmdon't authors retract xeps?
KevWell, a Draft XEP can't actually be Retracted.
KevSo we're really voting to Deprecate, I think.
ralphmalso, I don't think you can go from Draft to Retracted
ralphmin that case +1
KevSo, yes, let's make this a vote to deprecate and revote.
Kanchil+Kev: 5) Last Call on XEP-0262: Use of ZRTP in Jingle RTP Sessions
KevI'm largely happy to Last Call anything :)
linuxwolf(-:
ralphm+1
Kev+1
linuxwolf+1
stpeterit will make Phil Zimmerman happy, if nothing else
MattJ+1
Kev!agendaup
Kanchil+Kev: 6) Vote on accepting version 1.1rc3 of XEP-0178: Best Practices for Use
KevSkipping this one.
stpeternod
Kev(Ongoing list discussion)
Kev!agendaup
Kanchil+Kev: 7) Vote on accepting version 1.1rc1 of XEP-0171: Language Translation
linuxwolfheh
linuxwolf+1
linuxwolfthat was such a hard read (-:
stpetersomehow that slipped through the cracks last year
KevThis seems a bit of a strange thing to update. Given it'll break any existing implementations.
stpeterright
stpeterbut as discussed on the list, there was agreement to fix it
KevOh, I somehow missed that.
linuxwolfright
ralphmdoesn't this require a numeral now?
MattJI guess I missed it too, but +1
stpeterthe '#' is now allowed in URNs
stpeters/now/not/
ralphmI understand
stpeterralphm: this document was published before we had versioning
ralphmbut if it is being changed...
linuxwolfhrm
KevThe thread I can find on the lists is from last June, where Peter says "The authors ...approve of this change" but there was no discussion.
stpeterKev: because I poked them offlist
stpeterAFAIK there was only ever the one implementation, but I'm happy to bring this back to the list
stpeterwith a versioning update to the namespace
KevI think "discussed on the list" is pushing it when there was only one person posting :p
stpeterdiscussed among the authors
KevBut if we believe there's only one implementation, I'm happy to change it.
stpeterI can't promise that there's only one impl
ralphmI really just asking whether it should be changed, not requiring it, per se.
stpeterso let's take it to the list
stpeterI'll start a thread about it right now
linuxwolf/nod
KevI think just asking the list if anyone has implemented, and then voting in a fortnight or so seems safest.
ralphmk
KevEven if there was only one implementation a year ago when you last posted, there *could* be more by now.
KevEveryone ok with that?
MattJFine
Kev!agendaup
Kanchil+Kev: 8) Council concensus on removing Proposed from XEP-0001
linuxwolfwfm
ralphm+1
MattJ+1
linuxwolf+1
KevCouncil isn't the approving body for XEP-0001, but it's good to be asked anyway :)
ralphmKev: you +1?
KevI'm not opposed to removing Proposed, but I note that this needs more thought than scrubbing it, so I'd quite like to know to what we're agreeing.
KevSpecifically, if we remove Proposed, we no longer have a way to Reject a XEP.
ralphmwell, it just that we make XEP-0001 more in line with current practice
MattJThis /was/ discussed on the list though :)
KevMattJ: Was there suggested text, though?
MattJNot that I recall without looking
KevI thought it only went as far as vaguely agreeing to get rid of Proposed.
stpeterKev: sure we do, it comes up for a vote while still in the Experimental state and the Council votes to Reject it
KevWhich I'm fine with.
ralphmI don't see a problem with moving the arrow from experimental to rejected
Kevstpeter: I mean that the only valid state change to Rejected is from Proposed.
KevI'm entirely happy with allowing Council to Reject at any point in Experimental.
KevI think this would be preferable, in fact.
ralphmI agree
linuxwolfor we do what happens now, and never vote on the item (-:
stpeterin general, a number of specs have ended up going from Proposed back to Experimental (Council feedback requires an updated version but the authors don't get around to that), and it's unclear when the XEP Editor is supposed to change it back from Proposed to Experimental
KevRight, the current problem is, as I understand it:
stpeterseems cleaner to just get rid of Proposed
KevAuthor asks for vote to Draft on Experimental XEP. Council deem it not ready. As XEP-0001 stands, the XEP is then Rejected with no way to get it back.
ralphmI don't think that the 'proposed' state adds much value
KevThis is a fine problem to solve.
linuxwolflet's dump it!
KevSo if what we're discussing is removing Proposed from the state chart, and making the arrow go from Experimental to Rejected instead, and letting Council do this at any time (with appropriate majority vote), I'm happy with the proposal.
linuxwolfthat's what it sounds like to me
ralphmI also note that there is no arrow from deferred back to experimental
KevDoes anyone disagree with that assessment and/or have a different understanding?
stpeteryes, that's the concrete proposal
stpeterralphm: also something to be fixed, then
MattJKev, I don't
Kevralphm: Not in the diagram, but the text itself documents that this is permitted.
KevOk, so we're good to move on then with Council support, excellent.
Kev!agendaup
Kanchil+Kev: 9) Accept XEP-0220 version 0.6?
ralphmin principle our 'experimental' is really 'proposed'
Kevralphm: Right.
KevI'm +1 on this.
linuxwolf+1
ralphm+1
MattJI'm going to vote on the lis
MattJt
KevMattJ: OK.
MattJI've been following the discussions, but haven't reviewed the latest diff (if it's changed)
ralphmI can't think of any other XEP with so many implementations that is experimental
stpeterposted to the list about 171
MattJralphm, heh
ralphmstpeter: thanks!
stpeteralways best to be careful :)
linuxwolfhehe
Kev!agendaup
Kanchil+Kev: 10) Accept XEP-0220 version 0.6?
Kev!agendaup
stpeterralphm: it really should not have been Experimental when we copied it over from RFC 3920 to XEP-0220
Kanchil+Kev: 11) 6120/6121 updates.
ralphmstpeter: right
ralphmso, where are we wanting to move it to, really?
KevSo, are we happy with Peter going through all the XEPs and replacing 3920 with 6120 and 3921 with 6121 where he deems appropriate?
Kev+1
ralphm+1
stpeterralphm: I think we need to move it to Draft before we can do anything else with it
ralphmstpeter: agreed
ralphmstpeter: and then last call it next week?
ralphm:-)
MattJKev, +1
linuxwolfheh
linuxwolf+1
Kev!agendaup
Kanchil+Kev: 12) Date of next meeting
KevNext Wednesday, usual time? (1500GMT)
linuxwolfwfm
stpeterWFM
ralphmI might not be available
ralphmtaking some time off
MattJ+1
stpeterI'll miss any meeting the following week (May 4) if we have one
MattJ(to next week)
ralphm(easter holidays)
Kevralphm: Happy to vote on-list?
stpeterI'll be flying back from Amsterdam that day
ralphmstpeter: you'll be here?
stpeterralphm: yes, on May 2-3 for the IESG retreat
Florobhas left
ralphmstpeter: oh, nice. Are you only here on those days, or do you have more time?
stpeteroh AOB?
linuxwolffocus people!
ralphmbang already
stpeterhmph
Kevstpeter: I'm waiting for Ralph to confirm he's happy to vote onlist.
stpetermy other meeting was ending
ralphmKev: oh, I'm probably offline quite a bit
KevIdeally soon so we can get on with AOB before 30minute tolerance.
stpeterI received a submission that sounds just like the April 1 XEP :) http://xmpp.org/extensions/inbox/json.html
Kevralphm: I'll take that as a "Yes" :)
ralphmKev: but I have 2 weeks, so sure
stpeterhowever, it is legitimate
Kev!agendaup
Kanchil+Kev: 13) Any other business
stpeterI'll send a notice to the list after I clean it up a bit
stpeterdidn't want to announce it right before this meeting
emchoare outsiders allowed to speak?
stpeterit's nostly BOSH-ish
stpeters/n/m/
Kevemcho: I don't see why not.
emchoconcerning the any other business item
emcholast thursday stpeter mentioned on the jingle list that "The XMPP Council will decide at its next meeting whether to accept [Coin] as an official XEP". Peter, is this the meeting you were referring to?
Kevemcho: It wasn't added to the agenda.
Kevemcho: I'll make sure it's on next week's.
emchoKev: k thanks!
ralphmstpeter: oh wow, that's classic. I'm not quite sure what to think about this JSON-encoded-XMPP-for-the-sake-of-BOSH
linuxwolf/sigh
KevSo, I think there's nothing to do with this protoXEP, it's just a proposal and soon we'll be voting on it, right?
ralphmlet's publish it
ralphm+1
ralphmif it comes up for vote
KevI'm impressed that it seems to take my ugly proposal from the April 1st XEP and make it less legible :D
MattJKev, +1 :(
ralphmthey can battle!
KevAnyway.
KevAOAOB?
linuxwolfugh
linuxwolfnone from me
MattJNone
ralphmnope
KevExcellent.
KevThanks all!
ralphmhooray!
Kevbangs the gavel.
linuxwolfwaves
Kev32 minutes :(
linuxwolfhas left
stpeterKev: check the date on that submission, though
stpeterit predates yours, but there was some IPR wrangling at Nokia
ralphmwoah
Kevstpeter: Oh. I wonder why I didn't remember this, then.
stpeterKev: because I never announced it until now
KevExcellent.
stpeterthis got lost in my inbox
stpeteralong with many other old topics
stpeterworks to get his inbox back down from 5 to 0 :)
stpeteremcho: sorry about the snafu, we'll get it on next week's agenda
fippostpeter: +1 @ 0178
stpeterfippo: excellent, thanks
emchostpeter: no problem at all
MattJemcho, since discussions are currently happening on the list about Coin, it's probably wise to wait a week anyway
ralphmI am not quite sure about JSON and extensibility in general
emchoMattJ: yes that makes sense
stpeterralphm: me neither
MattJralphm, I'm not sure I'm happy with this XEP :/
ralphmWhat I am seeing happening at, for example, the activity streams stuff saddens me
stpeterMattJ: true
Kevralphm: JSON isn't any less extensible than XML, you just need to make it horribly ugly to achieve the same things.
stpeter:)
MattJIt's a non-standard translation from XML to JSON
MattJProsody could easily support JSON in BOSH (wait, it does since 1st April...)
Kev:)
ralphmKev: that's my point. This is how it goes: 1) XML SUCKS! Let's use JSON, because it is *easier*
MattJBut if we were to do it in the style of this XEP, we would use JSON that matches our internal stanza structures
ralphm2) hmm, we need to change how many values this attribute can have, let's up the version
ralphm3) hmm, we really need extensibility. Let's add namespaces.
MattJOtherwise we'd end up doing all kinds of transformations on the server that I'm sure would negate any performance advantages on the client
ralphm4) WOW. This is HORRIBLE!
ralphm5) Let's use XML?
KevSupporting this protoXEP seems to make the server work much harder.
Kevralphm: I think there are plenty of cases where JSON is a reasonable format, to be fair.
stpeterralphm: :)
ralphmKev: yes, but I don't think it quite works for an exchange standard between services
KevRight.
KevIt works well when it's an internal transfer format.
Keve.g. Ajaxy things.
stpeterright
stpeterKev: but internal is the new external
KevPlease let's not get started with that silliness here.
ralphmWell, it is used for APIs quite a bit too
stpeterlooks like I need to update http://xmpp.org/about-xmpp/xsf/xmpp-council/tenth-council/
stpeterralphm: it seems you were DNV on XEP 65
ralphmand as long as those namespaces are controlled by one entity for a particular service, that's probably ok
ralphmstpeter: noo?
benehas left
ralphmstpeter: that's sad. I am +1 on the changes. Didn't I pass this on?
KevNAFAIK.
ralphmLet me get my time machine then.
ralphmcya
ralphmhas left
stpeterI might have missed it
stpeter(sorry, was replying to email and processing XEPs so I missed ralphm)
stpeterupdates the voting table and takes appropriate XEP Editor actions
stpeterscrolls up to determine action items
emchohas left
stpeteranother action item for next week is http://xmpp.org/extensions/inbox/sensors.html (it's been updated to reflect earlier feedback)
KevHave they asked for another vote, then?
stpeterthey asked me if it could be reconsidered given that they'd updated it, yes
KevOk.
stpeterKev: how are we handling new XEP authors now w.r.t. git check-ins?
fippostpeter: no action about 220 yet please - it seems some examples (13) are buggy and I still need to read the latest version
stpeterfippo: right -- we're waiting for a vote from Nathan Fritz as well
stpeterack
stpeterreads http://xmpp.org:5290/muc_log/muc.xmpp.org/council/110420/ instead of continually scrolling up
Kevstpeter: We use the Gitosis stuff to give them access, I guess.
KevOr just ask them to fork us on Gitorious and you can do stuff that way.