KevI really want someone to comment on 152 so we can sensibly advance it.
Peter Waherhas joined
Tobiasjust reading through it
KevRight. 'tis time, 'tis time.
KevThanks for sorting out the meeting in my absense.
KevI don't think we have anything to discuss today.
Kev1) Roll call.
m&mand, actually, most of the votes are due today
Tobiasonly left thing to read for me is dialback
Tobiaswill do so later today
KevWe can cover those in the meeting if anyone wants to vote here.
KevMattJ looks here, but isn't, if mail is to be believed.
m&mwell … I have comments
KevRalph is marked AFK.
KevLet's go through them.
Kevyeah == +1?
m&mso, I' am +1 on the intent … but there's a lot of formatting and consistency nits
Tobias+1 on that if they add the MUC allowable traffic discovery stuff, which they said they'll do
m&mit was really annoying to me … and it very well could just be me
KevTobias: That sounds like -1 pending changes to me. Isn't it?
m&m(sounds like it to mee, too)
Kevm&m: I don't enjoy reading that one. It is much *much* better than it used to be. Really is.
m&mOh, I know
KevSo I think the motivation to sort things out was there.
m&mI had a slew of comments early on myself
m&mlike I said, it's nits
TobiasKev, right..it's probably *that* version to draft or not and not *a fixed version* to draft, right?
m&mthings the XEP Editor would be in his/her pervue to fix
KevTobias: Correct. It's "Is the XEP ready for Draft?".
KevNot "Might it be ready for Draft later".
Tobiasif it's about *that* particular unfixed version, than i'm -1
KevIt does raise the question of how good we want things to be before Draft. I think the MUC discovery needs to be addressed, at least.
KevBut in general, there are other things that I'm not entirely satisfied with, but probably aren't fatal.
KevI'm torn on whether we should block on it until it's "Right" or not.
Tobiasfor /me it's mostly MUC discovery and my editorial point i raised...after that it can go to draft
m&mthe enemy of Good is Perfect
KevGiven slippage of Draft being essentially Final these days.
Kevm&m: Did you have any blocking comments on it, or are you +1?
m&mbefore the Draft version is published, I would really like this XEP to be consistent with other XEPs
stpeterKev: actually, we made good progress on advancing some specs to Final for a while there, and I'm happy to come up with more candidates for that progression
m&mconsistency in references
Kevstpeter: It wasn't "Nothing goes to Final", but "People think of Draft as Final".
stpetersounds like the IETF :P
Kevm&m: Could you produce a list of these?
m&mI kind of stopped after 4.1
KevSo this is a -1 at teh moment from both of you anyway.
m&mbut I can pick it back up
Tobias+1 on 288
KevMuch as I wanted to implement this first, because I think it's the sort of XEP that bears implementing before judging, I think I'll just have to +1 it. Time time time.
KevI think we should leave this Experimental a bit longer until it's been proven in the field.
m&mI believe Dave Cridland had implemented −288 in a previous life
m&m+1 on 220
Tobiasi'll send my vote for 220 later today
Tobiasm&m, prosody also has an implementation...but occasional interop problems with dave's implementation
m&mso, I can see the utility of −152
Tobiasthose cusax environenments?
m&mbut it would be nice if someone that plans to implement it would comment
m&mTobias: possibly, yes
Tobiaswell...send a mail some minutes ago..but i don't plan to implemente it so... :)
KevI poked Emil but got no response. I really don't think we can push this through to Draft while the people who most need it aren't supporting it.
stpeterI think Emil was on vacation or moving or both
Kevstpeter: Ah, OK. He's been showing up as Online to me all day.
stpeterso I'll ping him again
stpeteryeah, probably way behind on things :)
stpeteronce I get my Linux machine I might start hacking up some features in Gajim :P
m&mLong Live OS/2
KevPsi was supported on OS/2, incidentally.
KevI meant traitor for Gajim/Swift, not Linux/Mac, though.
stpeterKev: I'm not getting near C++ :P
m&mKev: stpeter work in Python d-:
m&mmoving on …
KevI think both Matt and I are -1 on 152 pending someone else actually wanting to implement it.
KevIs that right?
stpeterdo we have a requirement in XEP-0001 for implementations or expressions of desire to implement before advancing to Draft?
TobiasKev, were implementations a requirement for draft?
stpeterI sense that we're changing XEP-0001 here
stpeterand I have a problem with that
stpeterif we want to change the criteria, we need to change XEP-0001
KevBut if no-one comes forward saying they want it, it fails the test for being useful.
stpeterI think it is very useful for CUSAX implementations, but I'm biased
Tobiaslance wants it, not?
stpeterwe poked a *lot* of people off list to get feedback on the CUSAX I-D
Lancei've used it, yes
stpeterthey never posted to the lists
stpeterI can poke them all again individually off list
stpeterbut it was a PITA
stpeterand I do NOT see that this is required by XEP-0001
fippostpeter: heh, even you noting names of people who wanted to send feedback in STOX didn't help :-)
KevIn order for a Standards Track XEP to advance from Proposed to Draft, it must:
fill known gaps in XMPP technologies or deficiencies with existing protocols
be clearly described and accurately documented so that it can be understood and implemented by interested and knowledgeable members of the XMPP developer community
document any known security considerations with the proposed technology
be generally stable and appropriate for further field experience
have achieved rough consensus (though not necessarily unanimity) within the Standards SIG
be formally defined by an XML schema
receive the requisite votes from the XMPP Council
stpeterBUT, that said, I will poke some folks again
stpeterIMHO this might be a case of people needing it and not realizing that
stpeterI think it is fine for us to actually be ahead of implementers sometimes
KevI don't think it has achieved rough consensus if no-one wants to implement it (or only one person).
stpeterso that we have something ready to go
KevI'm happy for people to say "We need this and are going to use it for CUSAX", but only having one person saying they want it seems to fall shy of these criteria to me.
m&mI would be happy with some people coming forward saying "I really need this"
stpeterhalf the specs that are Draft should never have been advanced from Experimental, then
m&mstpeter: very likely
stpeterso we can deprecate those
stpeterin any case
Tobiasand the schema contradicts the text
stpeterI will poke some more folks and see what they have to say
m&mwell, there's a technical reason to not advance it
stpetertime for the XSF board meeting in xmpp:email@example.com
KevYeah, we're running over for a change.
Kev6) Date of next.
KevIsn't 297 pending more changes from Matt?
KevThat's what I'd noted in the minutes.
m&mI thought he already made them, and that is what was published two (three?) weeks ago
Tobiasthought that too
m&mI thought he had made the changes, but they had not been published
MattJA disembodied voice says yes
KevVoting on that next week, then?
Kev6) Date of next.
m&mwfm (both 5 and 6)
KevI'll take that as a No.
Kevbangs the gavel.
Peter Waherhas left
KevUpon reflection (and checking xep1), I don't think the whole 'we treat Draft quite like Final' is something we've tacitly accepted, I think it's what is implied by:
KevNote: Once an XMPP Extension Protocol has been advanced to a status of Draft, it is expected that the specification will be the basis for widespread implementation and for deployment in production environments. As a result of such implementation and deployment experience, the protocol may be subject to modification, including changes that are backwards-incompatible. Although such backwards-incompatible modifications shall be avoided if at all possible, deployment of a Draft protocol in mission-critical application may not be advisable.
KevThat is, we're doing the Right Thing by making the move to Draft a Big Deal.
MattJI clearly need to read the meeting logs now
KevI think it would be better to do that than rely on the minutes' summary.