XMPP Council - 2011-04-20


  1. Kanchil+

    Kev: Done.

  2. Kev

    !agenda

  3. 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

  4. Kev

    Close enough.

  5. Kev wonders how many of the specs he'll have a chance to review before the meeting.

  6. stpeter

    hi MattJ

  7. MattJ

    Hi

  8. stpeter

    I'm going to check 198 into git

  9. stpeter

    so that you can see the diff

  10. MattJ

    k

  11. MattJ

    thanks

  12. MattJ

    I'm confused about what is version 1.2 :)

  13. stpeter

    well

  14. stpeter

    1.2 was confused in several respects

  15. stpeter

    but 1.2 is what's published on the website

  16. stpeter

    I cleaned up all the XEPs to refer to 6120/6121

  17. MattJ

    Ok, so 1.2rc2 is something else?

  18. stpeter

    I don't think we want council votes on all those reference updates

  19. MattJ

    No, we don't :)

  20. Kev

    I think we should probably have a Council item to say "Switch to 6120/6121 throughout".

  21. Kev

    No-one's going to object, but they are technically non-trivial changes to the dependencies of the XEPs.

  22. stpeter

    Kev: well, there *are* exceptions because in some of the specs we legitimately refer to 3920 or 3921

  23. stpeter

    e.g., to reference Nodeprep or whatever

  24. Kev

    Righty.

  25. stpeter

    those references have been retained

  26. stpeter

    but sure, a vote on that switch seems good

  27. stpeter

    maybe we should make suite definitions while we're at it, although it's unclear to me if anyone ever used those

  28. stpeter

    early 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

  29. Kev

    Right, I was going to suggest that.

  30. MattJ

    Ok, I'll stop reviewing it now then :)

  31. stpeter replies to fippo's latest email before the meeting begins

  32. stpeter

    I 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

  33. linuxwolf

    sounds like fun

  34. stpeter

    indeed

  35. Kev

    linuxwolf: it does? :)

  36. linuxwolf

    no, it does not (-:

  37. linuxwolf

    that was sarcasm

  38. stpeter

    linuxwolf: you'll be happy to hear that I also had a HYBI WG coordination call at 11 last night :)

  39. linuxwolf

    did it involve AES-CTR?

  40. linuxwolf

    (-:<

  41. stpeter

    no!

  42. linuxwolf

    good

  43. linuxwolf

    I noticed you actually posted something to the hybi list, too

  44. stpeter

    just using one of the reserved opcodes to signal if masking is enabled

  45. stpeter

    hi ralph!

  46. linuxwolf

    /nod … but the oddest things become a hill to die on over there

  47. ralphm

    hi

  48. MattJ

    Gah, phone... brb 2 minutes

  49. stpeter

    fippo: I've replied to you on the list

  50. Kev

    May as well get started, and let Matt catch up?

  51. Kev

    Or wait for him?

  52. linuxwolf

    I can catch up (-:

  53. linuxwolf trolls the vagueness

  54. stpeter

    :P

  55. Kev

    So

  56. Kev

    !agendaup

  57. Kanchil+

    Kev: 1) Roll call

  58. linuxwolf

    presente

  59. ralphm

    here

  60. Kev

    MattJ's largely here.

  61. Kev

    I'm certainly here.

  62. Kev

    We're missing a Fritzy - I don't remember him saying he'd miss it, I should check I guess.

  63. Kev

    Will do so before the minutes.

  64. Kev

    !agendaup

  65. Kanchil+

    Kev: 2) Agenda bashing

  66. Kev

    Anyone?

  67. stpeter

    I bashed about 178

  68. Kev

    You did.

  69. stpeter

    before the meeting started

  70. Kev

    Onward, then.

  71. Kev

    !agendaup

  72. Kanchil+

    Kev: 3) Retract XEP-0192

  73. MattJ

    Sorry, back

  74. stpeter

    we also talked about the 6120/6121 updates

  75. Kev

    Point.

  76. Kev

    !agendaappend 6120/6121 updates.

  77. Kanchil+

    Kev: Done.

  78. stpeter

    thanks

  79. Kev

    So.

  80. stpeter

    nothing else here

  81. Kev

    !agendaup 0

  82. stpeter

    I might have an AOB or two

  83. Kanchil+

    Kev: 3) Retract XEP-0192

  84. Kev

    +1

  85. MattJ

    +1

  86. linuxwolf

    +1

  87. ralphm

    this is kinda odd

  88. ralphm

    don't authors retract xeps?

  89. Kev

    Well, a Draft XEP can't actually be Retracted.

  90. Kev

    So we're really voting to Deprecate, I think.

  91. ralphm

    also, I don't think you can go from Draft to Retracted

  92. ralphm

    in that case +1

  93. Kev

    So, yes, let's make this a vote to deprecate and revote.

  94. Kev

    +1

  95. linuxwolf

    +1

  96. stpeter

    right, deprecate is correct

  97. stpeter

    http://xmpp.org/extensions/xep-0001.html#approval-std

  98. linuxwolf

    you beat me to the link

  99. Kev

    MattJ: Still +1?

  100. MattJ

    Still +1

  101. Kev

    !agendaup

  102. Kanchil+

    Kev: 4) Retract XEP-0193

  103. Kev

    This is Deprecate too.

  104. Kev

    +1

  105. ralphm

    +1

  106. linuxwolf

    +1

  107. MattJ

    +1

  108. Kev

    !agendaup

  109. Kanchil+

    Kev: 5) Last Call on XEP-0262: Use of ZRTP in Jingle RTP Sessions

  110. Kev

    I'm largely happy to Last Call anything :)

  111. linuxwolf

    (-:

  112. ralphm

    +1

  113. Kev

    +1

  114. linuxwolf

    +1

  115. stpeter

    it will make Phil Zimmerman happy, if nothing else

  116. MattJ

    +1

  117. Kev

    !agendaup

  118. Kanchil+

    Kev: 6) Vote on accepting version 1.1rc3 of XEP-0178: Best Practices for Use

  119. Kev

    Skipping this one.

  120. stpeter

    nod

  121. Kev

    (Ongoing list discussion)

  122. Kev

    !agendaup

  123. Kanchil+

    Kev: 7) Vote on accepting version 1.1rc1 of XEP-0171: Language Translation

  124. linuxwolf

    heh

  125. linuxwolf

    +1

  126. linuxwolf

    that was such a hard read (-:

  127. stpeter

    somehow that slipped through the cracks last year

  128. Kev

    This seems a bit of a strange thing to update. Given it'll break any existing implementations.

  129. stpeter

    right

  130. stpeter

    but as discussed on the list, there was agreement to fix it

  131. Kev

    Oh, I somehow missed that.

  132. linuxwolf

    right

  133. ralphm

    doesn't this require a numeral now?

  134. MattJ

    I guess I missed it too, but +1

  135. stpeter

    the '#' is now allowed in URNs

  136. stpeter

    s/now/not/

  137. ralphm

    I understand

  138. stpeter

    ralphm: this document was published before we had versioning

  139. ralphm

    but if it is being changed...

  140. linuxwolf

    hrm

  141. Kev

    The 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.

  142. stpeter

    Kev: because I poked them offlist

  143. stpeter

    AFAIK there was only ever the one implementation, but I'm happy to bring this back to the list

  144. stpeter

    with a versioning update to the namespace

  145. Kev

    I think "discussed on the list" is pushing it when there was only one person posting :p

  146. stpeter

    discussed among the authors

  147. Kev

    But if we believe there's only one implementation, I'm happy to change it.

  148. stpeter

    I can't promise that there's only one impl

  149. ralphm

    I really just asking whether it should be changed, not requiring it, per se.

  150. stpeter

    so let's take it to the list

  151. stpeter

    I'll start a thread about it right now

  152. linuxwolf

    /nod

  153. Kev

    I think just asking the list if anyone has implemented, and then voting in a fortnight or so seems safest.

  154. ralphm

    k

  155. Kev

    Even if there was only one implementation a year ago when you last posted, there *could* be more by now.

  156. Kev

    Everyone ok with that?

  157. MattJ

    Fine

  158. Kev

    !agendaup

  159. Kanchil+

    Kev: 8) Council concensus on removing Proposed from XEP-0001

  160. linuxwolf

    wfm

  161. ralphm

    +1

  162. MattJ

    +1

  163. linuxwolf

    +1

  164. Kev

    Council isn't the approving body for XEP-0001, but it's good to be asked anyway :)

  165. ralphm

    Kev: you +1?

  166. Kev

    I'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.

  167. Kev

    Specifically, if we remove Proposed, we no longer have a way to Reject a XEP.

  168. ralphm

    well, it just that we make XEP-0001 more in line with current practice

  169. MattJ

    This /was/ discussed on the list though :)

  170. Kev

    MattJ: Was there suggested text, though?

  171. MattJ

    Not that I recall without looking

  172. Kev

    I thought it only went as far as vaguely agreeing to get rid of Proposed.

  173. stpeter

    Kev: sure we do, it comes up for a vote while still in the Experimental state and the Council votes to Reject it

  174. Kev

    Which I'm fine with.

  175. ralphm

    I don't see a problem with moving the arrow from experimental to rejected

  176. Kev

    stpeter: I mean that the only valid state change to Rejected is from Proposed.

  177. Kev

    I'm entirely happy with allowing Council to Reject at any point in Experimental.

  178. Kev

    I think this would be preferable, in fact.

  179. ralphm

    I agree

  180. linuxwolf

    or we do what happens now, and never vote on the item (-:

  181. stpeter

    in 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

  182. Kev

    Right, the current problem is, as I understand it:

  183. stpeter

    seems cleaner to just get rid of Proposed

  184. Kev

    Author 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.

  185. ralphm

    I don't think that the 'proposed' state adds much value

  186. Kev

    This is a fine problem to solve.

  187. linuxwolf

    let's dump it!

  188. Kev

    So 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.

  189. linuxwolf

    that's what it sounds like to me

  190. ralphm

    I also note that there is no arrow from deferred back to experimental

  191. Kev

    Does anyone disagree with that assessment and/or have a different understanding?

  192. stpeter

    yes, that's the concrete proposal

  193. stpeter

    ralphm: also something to be fixed, then

  194. MattJ

    Kev, I don't

  195. Kev

    ralphm: Not in the diagram, but the text itself documents that this is permitted.

  196. Kev

    Ok, so we're good to move on then with Council support, excellent.

  197. Kev

    !agendaup

  198. Kanchil+

    Kev: 9) Accept XEP-0220 version 0.6?

  199. ralphm

    in principle our 'experimental' is really 'proposed'

  200. Kev

    ralphm: Right.

  201. Kev

    I'm +1 on this.

  202. linuxwolf

    +1

  203. ralphm

    +1

  204. MattJ

    I'm going to vote on the lis

  205. MattJ

    t

  206. Kev

    MattJ: OK.

  207. MattJ

    I've been following the discussions, but haven't reviewed the latest diff (if it's changed)

  208. ralphm

    I can't think of any other XEP with so many implementations that is experimental

  209. stpeter

    posted to the list about 171

  210. MattJ

    ralphm, heh

  211. ralphm

    stpeter: thanks!

  212. stpeter

    always best to be careful :)

  213. linuxwolf

    hehe

  214. Kev

    !agendaup

  215. Kanchil+

    Kev: 10) Accept XEP-0220 version 0.6?

  216. Kev

    !agendaup

  217. stpeter

    ralphm: it really should not have been Experimental when we copied it over from RFC 3920 to XEP-0220

  218. Kanchil+

    Kev: 11) 6120/6121 updates.

  219. ralphm

    stpeter: right

  220. ralphm

    so, where are we wanting to move it to, really?

  221. Kev

    So, are we happy with Peter going through all the XEPs and replacing 3920 with 6120 and 3921 with 6121 where he deems appropriate?

  222. Kev

    +1

  223. ralphm

    +1

  224. stpeter

    ralphm: I think we need to move it to Draft before we can do anything else with it

  225. ralphm

    stpeter: agreed

  226. ralphm

    stpeter: and then last call it next week?

  227. ralphm

    :-)

  228. MattJ

    Kev, +1

  229. linuxwolf

    heh

  230. linuxwolf

    +1

  231. Kev

    !agendaup

  232. Kanchil+

    Kev: 12) Date of next meeting

  233. Kev

    Next Wednesday, usual time? (1500GMT)

  234. linuxwolf

    wfm

  235. stpeter

    WFM

  236. ralphm

    I might not be available

  237. ralphm

    taking some time off

  238. MattJ

    +1

  239. stpeter

    I'll miss any meeting the following week (May 4) if we have one

  240. MattJ

    (to next week)

  241. ralphm

    (easter holidays)

  242. Kev

    ralphm: Happy to vote on-list?

  243. stpeter

    I'll be flying back from Amsterdam that day

  244. ralphm

    stpeter: you'll be here?

  245. stpeter

    ralphm: yes, on May 2-3 for the IESG retreat

  246. ralphm

    stpeter: oh, nice. Are you only here on those days, or do you have more time?

  247. stpeter

    oh AOB?

  248. linuxwolf

    focus people!

  249. ralphm

    bang already

  250. stpeter

    hmph

  251. Kev

    stpeter: I'm waiting for Ralph to confirm he's happy to vote onlist.

  252. stpeter

    my other meeting was ending

  253. ralphm

    Kev: oh, I'm probably offline quite a bit

  254. Kev

    Ideally soon so we can get on with AOB before 30minute tolerance.

  255. stpeter

    I received a submission that sounds just like the April 1 XEP :) http://xmpp.org/extensions/inbox/json.html

  256. Kev

    ralphm: I'll take that as a "Yes" :)

  257. ralphm

    Kev: but I have 2 weeks, so sure

  258. stpeter

    however, it is legitimate

  259. Kev

    !agendaup

  260. Kanchil+

    Kev: 13) Any other business

  261. stpeter

    I'll send a notice to the list after I clean it up a bit

  262. stpeter

    didn't want to announce it right before this meeting

  263. emcho

    are outsiders allowed to speak?

  264. stpeter

    it's nostly BOSH-ish

  265. stpeter

    s/n/m/

  266. Kev

    emcho: I don't see why not.

  267. emcho

    concerning the any other business item

  268. emcho

    last 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?

  269. Kev

    emcho: It wasn't added to the agenda.

  270. Kev

    emcho: I'll make sure it's on next week's.

  271. emcho

    Kev: k thanks!

  272. ralphm

    stpeter: oh wow, that's classic. I'm not quite sure what to think about this JSON-encoded-XMPP-for-the-sake-of-BOSH

  273. linuxwolf

    /sigh

  274. Kev

    So, I think there's nothing to do with this protoXEP, it's just a proposal and soon we'll be voting on it, right?

  275. ralphm

    let's publish it

  276. ralphm

    +1

  277. ralphm

    if it comes up for vote

  278. Kev

    I'm impressed that it seems to take my ugly proposal from the April 1st XEP and make it less legible :D

  279. MattJ

    Kev, +1 :(

  280. ralphm

    they can battle!

  281. Kev

    Anyway.

  282. Kev

    AOAOB?

  283. linuxwolf

    ugh

  284. linuxwolf

    none from me

  285. MattJ

    None

  286. ralphm

    nope

  287. Kev

    Excellent.

  288. Kev

    Thanks all!

  289. ralphm

    hooray!

  290. Kev bangs the gavel.

  291. linuxwolf waves

  292. Kev

    32 minutes :(

  293. stpeter

    Kev: check the date on that submission, though

  294. stpeter

    it predates yours, but there was some IPR wrangling at Nokia

  295. ralphm

    woah

  296. Kev

    stpeter: Oh. I wonder why I didn't remember this, then.

  297. stpeter

    Kev: because I never announced it until now

  298. Kev

    Excellent.

  299. stpeter

    this got lost in my inbox

  300. stpeter

    along with many other old topics

  301. stpeter works to get his inbox back down from 5 to 0 :)

  302. stpeter

    emcho: sorry about the snafu, we'll get it on next week's agenda

  303. fippo

    stpeter: +1 @ 0178

  304. stpeter

    fippo: excellent, thanks

  305. emcho

    stpeter: no problem at all

  306. MattJ

    emcho, since discussions are currently happening on the list about Coin, it's probably wise to wait a week anyway

  307. ralphm

    I am not quite sure about JSON and extensibility in general

  308. emcho

    MattJ: yes that makes sense

  309. stpeter

    ralphm: me neither

  310. MattJ

    ralphm, I'm not sure I'm happy with this XEP :/

  311. ralphm

    What I am seeing happening at, for example, the activity streams stuff saddens me

  312. stpeter

    MattJ: true

  313. Kev

    ralphm: JSON isn't any less extensible than XML, you just need to make it horribly ugly to achieve the same things.

  314. stpeter

    :)

  315. MattJ

    It's a non-standard translation from XML to JSON

  316. MattJ

    Prosody could easily support JSON in BOSH (wait, it does since 1st April...)

  317. Kev

    :)

  318. ralphm

    Kev: that's my point. This is how it goes: 1) XML SUCKS! Let's use JSON, because it is *easier*

  319. MattJ

    But if we were to do it in the style of this XEP, we would use JSON that matches our internal stanza structures

  320. ralphm

    2) hmm, we need to change how many values this attribute can have, let's up the version

  321. ralphm

    3) hmm, we really need extensibility. Let's add namespaces.

  322. MattJ

    Otherwise we'd end up doing all kinds of transformations on the server that I'm sure would negate any performance advantages on the client

  323. ralphm

    4) WOW. This is HORRIBLE!

  324. ralphm

    5) Let's use XML?

  325. Kev

    Supporting this protoXEP seems to make the server work much harder.

  326. Kev

    ralphm: I think there are plenty of cases where JSON is a reasonable format, to be fair.

  327. stpeter

    ralphm: :)

  328. ralphm

    Kev: yes, but I don't think it quite works for an exchange standard between services

  329. Kev

    Right.

  330. Kev

    It works well when it's an internal transfer format.

  331. Kev

    e.g. Ajaxy things.

  332. stpeter

    right

  333. stpeter

    Kev: but internal is the new external

  334. Kev

    Please let's not get started with that silliness here.

  335. ralphm

    Well, it is used for APIs quite a bit too

  336. stpeter

    looks like I need to update http://xmpp.org/about-xmpp/xsf/xmpp-council/tenth-council/

  337. stpeter

    ralphm: it seems you were DNV on XEP 65

  338. ralphm

    and as long as those namespaces are controlled by one entity for a particular service, that's probably ok

  339. ralphm

    stpeter: noo?

  340. ralphm

    stpeter: that's sad. I am +1 on the changes. Didn't I pass this on?

  341. Kev

    NAFAIK.

  342. ralphm

    Let me get my time machine then.

  343. ralphm

    cya

  344. stpeter

    I might have missed it

  345. stpeter

    (sorry, was replying to email and processing XEPs so I missed ralphm)

  346. stpeter updates the voting table and takes appropriate XEP Editor actions

  347. stpeter scrolls up to determine action items

  348. stpeter

    another action item for next week is http://xmpp.org/extensions/inbox/sensors.html (it's been updated to reflect earlier feedback)

  349. Kev

    Have they asked for another vote, then?

  350. stpeter

    they asked me if it could be reconsidered given that they'd updated it, yes

  351. Kev

    Ok.

  352. stpeter

    Kev: how are we handling new XEP authors now w.r.t. git check-ins?

  353. fippo

    stpeter: no action about 220 yet please - it seems some examples (13) are buggy and I still need to read the latest version

  354. stpeter

    fippo: right -- we're waiting for a vote from Nathan Fritz as well

  355. stpeter

    ack

  356. stpeter reads http://xmpp.org:5290/muc_log/muc.xmpp.org/council/110420/ instead of continually scrolling up

  357. Kev

    stpeter: We use the Gitosis stuff to give them access, I guess.

  358. Kev

    Or just ask them to fork us on Gitorious and you can do stuff that way.

  359. stpeter

    the latter seems easier :)

  360. stpeter

    http://xmpp.org/about-xmpp/xsf/xmpp-council/tenth-council/ updated

  361. Kev

    Thanks.

  362. MattJ

    > "My apologies for the error, naturally that is 2011-05-10."

  363. MattJ

    stpeter, I signed the date on a bank form the other day as "2009", you're forgiven :)

  364. stpeter

    haha

  365. stpeter

    at least I have the decade correct

  366. stpeter corrects an error in http://xmpp.org/about-xmpp/xsf/xmpp-council/tenth-council/ (MW to vote on list about the dialback spec)