XMPP Council - 2010-07-12

  1. Kev has joined
  2. Tobias has joined
  3. Tobias has left
  4. Tobias has joined
  5. Fritzy has joined
  6. remko has joined
  7. psa has joined
  8. psa greetings and salutations
  9. Kev Evening.
  10. remko hello there-
  11. Kev Quorum early, whatever is the world coming to?
  12. psa reviews http://xmpp.org/internet-drafts/draft-saintandre-tls-server-id-check-08-from-7.diff.html in preparation for submission
  13. remko mattj sent apologies?
  14. Kev Matt'll be here.
  15. psa maybe he sent apologies for being here :)
  16. MattJ has joined
  17. MattJ I'm not that apologetic
  18. Kev Right, no sign of Ralph being online at the moment, so let's start
  19. Kev 1) Roll call.
  20. Kev Fritzy, Kev, Matt, Remko here.
  21. Kev 2) Agenda bashing
  22. MattJ None
  23. Kev Peter sent a bunch, anyone else?
  24. Kev Ok.
  25. Fritzy nope
  26. psa Ralph is probably still in mourning over the World Cup
  27. Fritzy I went over Peter's
  28. Kev 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!
  29. Fritzy +1
  30. MattJ +1
  31. Kev I checked the diff from the last version I reviewed, and this seems fine, I'm +1
  32. remko +1
  33. Kev 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?
  34. Kev I don't have a strong opinion either way.
  35. remko feels like joining as ra1phm and voting on this topic
  36. ralphm has joined
  37. psa 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
  38. ralphm hi
  39. Kev Dave suggested that a XEP as a more fluid spec would be better for this, and I'm fine with that.
  40. Kev Evening Ralph.
  41. Kev Want to vote on pubsub? We're only on the second item.
  42. ralphm I just got home, and first have to put the kid in bed
  43. Kev Ok, we'll see you shortly then.
  44. remko kev: so that is the second alternative?
  45. Kev remko: Dave suggests advancing the XEP to active, and leaving 3920bis with a reference.
  46. MattJ iirc someone mentioned splitting it (I thought Dave?)
  47. MattJ Let me pull that conversation back up to remind myself
  48. Kev MattJ: possibly, I thought tha was Peter's suggestion.
  49. Kev consults archive.
  50. MattJ It could well have been
  51. psa well I stole stuff from 165 and put it in the Internet-Draft
  52. zanchin has joined
  53. remko kev: do we reference XEPs a lot in rfcs?
  54. psa and that stuff can IMHO remain in that I-D because it is more generic
  55. Florob has joined
  56. Kev remko: only a couple.
  57. psa how we solve the problem is another question -- XEP-0165 has some ideas, but they are preliminary and not yet field-tested
  58. Fritzy yeah, the problem is convenience vs. security as always
  59. Kev psa: What's your preference?
  60. Fritzy and it's hard to say where the line is drawn until there are some implementations that follow the recommendation.
  61. psa 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
  62. Kev psa: right.
  63. psa my preference is to remove the reference to 165
  64. Kev Although I hadn't realised it was 'lots'
  65. psa since I've borrowed all the fundamental content
  66. remko psa: same here
  67. MattJ Yes, it was stpeter; http://mail.jabber.org/pipermail/council/2010-July/002919.html
  68. MattJ and I'm +1 to this
  69. psa 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)
  70. Kev I admit that I was swayed by Dave's argument, but I'll go along with the majority if they disagree.
  71. psa 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
  72. psa s/165/the practical solutions in 165/
  73. Fritzy it assumes that clients store the roster as raw xml
  74. psa among other things, perhaps
  75. Fritzy or rather, cache it that way
  76. Kev So, there's nothing for Council to actually do on this, right? Just generally nod about the right way to do it.
  77. MattJ 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)."
  78. psa anyway, those practical recommendations are experimental and if we really cared we'd put more work into it
  79. psa Kev: right
  80. MattJ Kev, but I see much of 165 as not being just "best practices"
  81. psa MattJ: correct
  82. psa anyway as editor of 3921bis I'll remove the reference :)
  83. Fritzy right, there's a real extension buried in there.
  84. psa indeed
  85. psa ok
  86. psa moving on? :)
  87. Kev Ok, good enough then.
  88. Kev 5) 201
  89. psa y'all'll have plenty of chance to review 3291bis soon :)
  90. Kev Another reference.
  91. psa loves it when he gets to use "y'all'll" :)
  92. psa right, another ref
  93. Kev So, I'd have thought just advancing 201 wouldmake sense.
  94. psa but this one is more stable and useful
  95. psa we had some review of it a while back and I/we cleaned it up at that time
  96. 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."
  97. Fritzy in 5.1 of xep201 it suggests that you don't destroy a thread when they go offline.
  98. MattJ Curious whether I'm alone in this
  99. psa Fritzy: that's an Ianism :)
  100. Fritzy psa http://www.urbandictionary.com/define.php?term=ianism?
  101. Kev An ex-member of Council.
  102. Fritzy MattJ I think it could be made more consistent.
  103. Kev Most of the complicated XEPs he had input into.
  104. psa :)
  105. psa Ian's speciality was injecting complexity
  106. Fritzy 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.
  107. psa which we didn't fight strongly enough
  108. psa Fritzy: yep, nothing like a Last Call to get people to review the spec... ;-)
  109. Kev We were young and foolish :)
  110. Kev So: Issue a last call?
  111. psa I agree that there are things that need to be fixed in 201
  112. Kev After which we'll address comments like these?
  113. psa and in 3921bis regarding threads
  114. MattJ oops... did WGLC on xmpp-address end today? Forgot all about it...
  115. psa but we can do those concurrently
  116. Fritzy sounds good to me then.
  117. Fritzy +1 on Last Call
  118. remko +1
  119. MattJ +1 on last call too
  120. psa MattJ: I think the MUST for UUID is unnecessary
  121. Kev +1.
  122. ralphm back
  123. Kev psa: right.
  124. Kev MAY even, seems appropriate
  125. MattJ psa, excellent, thanks :)
  126. psa I think that might have been an Ianism too
  127. MattJ Yay
  128. Fritzy This feels like a public shaming.
  129. Kev 6) 269 (Jingle early media).
  130. MattJ 's heart lightens
  131. psa haha
  132. Kev Authors would like a last call.
  133. Kev I found something interesting out earlier this week.
  134. ralphm I'm with MattJ on the UUID stuff
  135. MattJ Fritzy, he practically disappeared mid-term without a trace, I don't think he'll mind much :)
  136. Kev If authors request a Last Call, and Council then vote not to advance it to draft, it's immediately rejected, rathe than staying Experimental :)
  137. psa I still have time to submit a revised 3921bis before tonight's deadline :)
  138. Kev Anyway, I'm not opposed to a last call if the authors want one.
  139. remko neither am i
  140. ralphm +1
  141. MattJ Kev, is that intentional or a loophole?
  142. Kev It sounds right, actually.
  143. MattJ +1
  144. psa I think it might make sense to ask for feedback on the Jingle list, but that can be done at the same time
  145. Fritzy Last call sounds fine +1
  146. MattJ Kev, does it?
  147. Kev LastCall is used to address feedback to gain consensus.
  148. Fritzy psa: sure, they should be paying attention to last calls. ;)
  149. Kev It should only go to vote once it's got consensus that this is the right thing.
  150. ralphm Kev: according to?
  151. psa I don't care so much about early media but the spec is stable and implemented
  152. Kev ralphm: xep 1
  153. ralphm consensus among whom?
  154. Kev standards-jig.
  155. Kev Anyway
  156. Kev This is strictly irrelevant to the current vote :)
  157. ralphm right
  158. ralphm as this isn't a vote
  159. Kev It is.
  160. Kev Issuing a last call is voted on.
  161. Kev Anyway...
  162. Kev 7) XEP-0266 (codecs).
  163. ralphm right, not a vote on the advancement, we're in agreement
  164. Kev I'm happy for this to have both the codecs in.
  165. Fritzy The spec kind of waxes poetical about patent free and distribution free.
  166. remko dito
  167. Kev 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?
  168. psa Fritzy: heh yeah :)
  169. Kev And after the vot, ask for a vote.
  170. ralphm that's the most basic encoding in RTP, right?
  171. psa 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
  172. ralphm psa: yeah, I noticed the dc stuff, too. Why was that removed?
  173. Kev So if thee's nothing to do for 266 here, onto
  174. Kev 8) Date for next meeting.
  175. psa ralphm: dc?
  176. Kev Next Monday, usual time?
  177. psa Kev: right, 266 needs to be updated
  178. MattJ Kev, +1
  179. remko +1
  180. Fritzy I'm game for Monday.
  181. Fritzy wait
  182. Fritzy that'll be the Summit, right?
  183. psa yes it will
  184. Fritzy I'll be at the Summit in Portland.
  185. ralphm psa: dublin core
  186. Fritzy So, my availability is questionable.
  187. Fritzy anyone else going?
  188. psa and unfortunately some personal/family stuff has come up so I don't think I'll be at the Summit
  189. psa ralphm: it was purely informational and confusing people
  190. Fritzy psa: ah, too bad
  191. ralphm I'll not be at the Summit, unfortunately
  192. ralphm psa: ah
  193. Fritzy I'll go and represent then.
  194. Fritzy ;)
  195. ralphm psa: I also noticed a typo in the edit of example 155
  196. psa I need to ping bear too
  197. psa ralphm: ok great, bug reports are welcome
  198. psa looks
  199. Kev Ok, so - are we skipping a week until summit's over?
  200. Fritzy That's what I suggest, or do it later in the week.
  201. remko i have no problem with that
  202. MattJ We skipped for Brussels iirc, but then 100% of the council was there :)
  203. ralphm psa: you removed a closing quote
  204. ralphm Kev: sure
  205. Kev Ok, week Monday, then.
  206. ralphm Anyone planning on going to Maastricht?
  207. Kev 9) Any other business?
  208. remko no
  209. Fritzy nodda
  210. Kev ralphm: possibly.
  211. psa ralphm: fixed
  212. MattJ I'm undecided on Maastricht, I think it's more than I can afford right now though
  213. ralphm Kev: any ideas on when?
  214. Kev Likely just XMPP day.
  215. Kev That's the Thursday, right?
  216. psa yes
  217. ralphm psa suggested some hacking on sunday?
  218. psa IETF has day passes now
  219. Kev psa: right.
  220. Kev Ok, without AOB I suggest we close.
  221. psa ralphm: only Florian pinged me in reply and he mostly just wants to find a good party I think :)
  222. remko ok, bibi
  223. Kev 2 minutes off my half-hour meeting tolerance.
  224. Kev Thanks all.
  225. Fritzy :)
  226. Kev bangs the gavel.
  227. psa still needs to figure out how to get from BRU to Maastricht
  228. remko psa: train?
  229. Kev psa: train?
  230. psa um yeah
  231. psa but I need to figure out where to change trains etc.
  232. psa well I'll do that tomorrow
  233. psa now I need to submit updated Internet-Drafts :)
  234. Kev Have fun.
  235. psa indeed
  236. Kev I'll sort out minutes tomorrow.
  237. psa ralphm: so you will review XEP-0060 and post to the list?
  238. remko psa: in Leuven and in Luik/Liege :)
  239. remko i'll wave from my window :)
  240. ralphm psa: I think I'm +1
  241. psa remko: :)
  242. psa submits a new 3921bis with no more MUST for UUID
  243. Tobias are UUIDs such a problem?
  244. remko has left
  245. psa Tobias: no, but there is no reason for them to be a MUST
  246. psa Tobias: people could do "interesting" things with ThreadIDs if we remove the UUID requirement
  247. ralphm Kev: did you record my +1 on XEP-0060?
  248. MattJ Indeed, the UUIDs aren't a problem, just the MUST :)
  249. Kev No, was there one?
  250. ralphm Tobias: an opaque identifier suffices
  251. Kev I'll record it in the minutes anyhow :)
  252. MattJ 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 :)
  253. ralphm UUIDs might be a burden to implement
  254. ralphm (even though the mechanics are pretty simple, low-end devices might not want to devote cycles to that for no gain)
  255. psa burden or not, they are unnecessary (as a MUST)
  256. ralphm psa: yeah, that was collateral reasoning
  257. ralphm I'm really sad about not making it to Portland
  258. psa me too
  259. Kev Same.
  260. MattJ Same
  261. MattJ Let's just make the next FOSDEM 10x better to show them that :)
  262. ralphm also, it would be the 10th summit
  263. Kev I'd rather do Portland than Fosdem, TBH.
  264. psa 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
  265. ralphm Kev: agreed
  266. Kev I actually quite liked Portland, Brussels not so much.
  267. MattJ Kev, considering the travel is the least enjoyable part for me, I'd prefer making it as short as possible :)
  268. Kev I dislike the travel, a lot.
  269. ralphm I don't really mind
  270. Kev But I dislike being somewhere I don't like more.
  271. ralphm as long as it is a direct flight, that is
  272. Kev I really dislike being places where English isn't the first language - even Brussels.
  273. Tobias Kev: lol
  274. MattJ Aww, I like that... it makes things more interesting :)
  275. ralphm Kev: how come you like Portland, then?
  276. MattJ anyway, I can manage French a touch
  277. Kev ralphm: point.
  278. Fritzy hey hnow
  279. MattJ Heh
  280. MattJ Fritzy, the sooner y'all'll realise you're not speaking English the better off we'll both be :)
  281. Fritzy y'all is a southern thing
  282. psa indeed
  283. psa I lived in Atlanta for 2 years
  284. Fritzy Pretty small region uses that.
  285. psa and yes some folks really do say "y'all'll" -- gotta love that!
  286. MattJ Heh
  287. psa but I'm not one to talk, since I was born in NY :)
  288. Fritzy There are some spelling differences, but other than that, it's the same language.
  289. psa Fritzy: don't worry, this is a running joke with Kev
  290. Fritzy I'm familiar with it.
  291. psa ok :)
  292. Fritzy Kev and I argue about stuff all the time.
  293. MattJ Talking of running, I'll be off for a bit :)
  294. Fritzy ciao
  295. psa bye!
  296. Fritzy psa: you're syncing up with Bear on the Summit? I'll synch up with him then.
  297. Fritzy psa: I've got to announce that hackfest still.
  298. Fritzy I should do that today after talking to Bear.
  299. psa heats up some lunch
  300. psa do I read the record correctly that we're finally done with XEP-0060?!?!
  301. Fritzy yes
  302. psa ok
  303. psa 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 :)
  304. jkhii has joined
  305. ralphm has left
  306. Florob has left
  307. jkhii has left
  308. jkhii has joined
  309. jkhii has left
  310. Tobias has left
  311. psa has left
  312. Fritzy has left
  313. MattJ has left