XSF logo XMPP Council - 2012-06-20


  1. m&m has joined
  2. m&m has left
  3. Neustradamus has left
  4. Tobias has joined
  5. Tobias has left
  6. Tobias has joined
  7. Tobias has left
  8. Tobias has joined
  9. Neustradamus has left
  10. m&m has joined
  11. Tobias has left
  12. stpeter has joined
  13. m&m T - 15
  14. stpeter indeed
  15. stpeter I see Ralph and Matthew online
  16. m&m T - 10
  17. MattJ has joined
  18. stpeter sends invitations to Ralph and Matthew
  19. stpeter heh
  20. MattJ Merci stpeter
  21. Tobias has joined
  22. stpeter hi Tobi!
  23. ashward has joined
  24. Tobias hello
  25. m&m very good … we at least have quorum, assuming no one disappears in the next 7 minutes (-:
  26. stpeter ashward: howdy
  27. ashward Hello
  28. stpeter Ralph just went idle, but perhaps he'll return to whatever device he's using at the moment
  29. stpeter notes that ashward is a co-author of the pubsub-labels proposal
  30. m&m has left
  31. ashward It's my first XEP I've written, so be nice :)
  32. stpeter heh
  33. m&m has joined
  34. stpeter m&m: hardware problems? ;-)
  35. m&m no … pebkac
  36. Tobias PbuSb :D
  37. m&m (-:
  38. Tobias that'd be hard to pronounce
  39. m&m Tuesday nights to Wednesday mornings are tough for me (-:
  40. ralphm_ has joined
  41. MattJ is nearly here
  42. ralphm has joined
  43. m&m we have a Ralph, and just in time!
  44. ralphm hi!
  45. m&m bangs gavel
  46. m&m 0) Roll Call
  47. m&m yo es presente
  48. Tobias here
  49. m&m MattJ and ralphm?
  50. m&m gets minutes prepped
  51. ralphm yes, I'm still here
  52. m&m thank you, and we'll assume the same from MattJ
  53. m&m 1) XEP-0047 - Advance to Final?
  54. Tobias +1
  55. ralphm +1
  56. MattJ I'm here
  57. MattJ Is this +1 for a last call, or did we have that?
  58. MattJ (or do we need another?)
  59. m&m we already had LC, with one minor correction
  60. MattJ The data length? I'm not convinced (either way) of how minor that is
  61. ralphm the LC was in May and earlier this month
  62. m&m there was a correction
  63. stpeter actually the LC was in February or so but it took a while for me to reply to the feedback :)
  64. m&m (-:
  65. ralphm eh, right
  66. MattJ That's fine
  67. m&m anyway, if we'd rather re-issue LC, that's fine with me
  68. MattJ Well I agree with the new text
  69. ralphm MattJ: do you have any instructions for such an LC?
  70. MattJ The old text was unclear, so... let's just go +1
  71. m&m and I'm +1
  72. stpeter IMHO it's not a significant enough change (more of a clarification) to justify another Last Call, but it's not a hill for me to die on
  73. ralphm Kev to vote on list
  74. m&m yup
  75. m&m 2) XEP-0191 - Accept rev 1.2?
  76. MattJ stpeter, the old text definitely leant towards post-encoded data (even if that wasn't intentional)
  77. MattJ I suspect (but have no data to go on) that most implementations don't enforce it, so it doesn't matter
  78. ralphm +1 on XEP-0191
  79. stpeter MattJ: yes it did, but The Implementers Have Spoken™
  80. m&m that was my take … at least a couple of implementors spoke up
  81. MattJ Not all, but I guess as many as shall
  82. m&m if we wait for all, no draft would go final
  83. Tobias +1 for 191
  84. ralphm 100% is unattainable, of course
  85. MattJ I'll vote on-list for 191
  86. MattJ I haven't read all the new text
  87. ralphm MattJ: there isn't much, just a reshuffle and rename
  88. m&m anyway, +1 on −191 … the only "significant" change is a reorganization
  89. stpeter right
  90. ralphm you can do it in parallel while we move on
  91. m&m 3) inbox: Data Forms XML Element
  92. ralphm I don't like this
  93. Tobias ralphm, what don't you like about it?
  94. MattJ ralphm, I have another meeting overrunning in parallel :)
  95. m&m ouch
  96. stpeter heh
  97. m&m well, there are obvious problems with the draft, IMO
  98. m&m such as <xml/> is not a well-formed element
  99. ralphm Well, I'd rather have the XML outside of the form
  100. MattJ Outside?
  101. stpeter m&m: yes, noted on the standards@ list
  102. ralphm the reasoning comes back to a discussion I had with Blaine Cook years ago
  103. ralphm on pubsub+atom
  104. Tobias outside and then referencing it from withing the form?
  105. m&m ralphm: are you −1 on this?
  106. m&m I'm −1 until the obvious flaws are fixed
  107. stpeter looks forward to hearing the story about Blaine :)
  108. MattJ too
  109. m&m heh
  110. Tobias well... m&m's argument of xml being not well-formed is enough for a -1 from me
  111. ralphm when he was sending out Tweets over XMPP, he really disliked that an additional wrapper was required, even though existing clients might be able to consume the Atom payload as a direct child of <message/>
  112. ralphm Tobias: if referencing is not too hard, I'd prefer that, yes
  113. m&m it's all about context
  114. m&m ralphm: will you post a rejection reply on the list?
  115. ralphm m&m: In most cases, parsing messages requires looking at the whole stanza anyway
  116. Tobias ralphm, if we define clear and specific rules for referencing sure, that'd be fine
  117. stpeter m&m: IMHO it's more about having a discussion than sending a rejection :)
  118. m&m fair enough (-:
  119. m&m s/rejection/obections/
  120. ralphm stpeter: indeed. sorry I didn't make that clear
  121. m&m I realized it was the wrong word the moment I hit <ENTER>
  122. ralphm I'm +1 on publishing
  123. stpeter ralphm: it was clear to me
  124. m&m ok, then I'll send the objections email
  125. ralphm (to stay consistent with all the XEPs I've not objected to during my terms, haha)
  126. m&m there's a couple of other things that bother me, but I'm not sure they're worth holding up the proposal
  127. ashward has left
  128. stpeter Sergey and I had a long discussion about it on the standards@ list but no one else participated IIRC
  129. m&m 4) inbox: Security Labels in PubSub (or PbuSb)
  130. ralphm stpeter: I'll look that up
  131. ralphm I'd like to postpone my vote on this
  132. ralphm wait
  133. ralphm +1 on publishing
  134. ralphm but I want to read it still
  135. m&m so, I'm +1 on publishing
  136. MattJ I'll vote on-list
  137. m&m but I implore the authors to rethink some of their normative language (-:
  138. Tobias haven't read it yet...will vote on list for this one
  139. stpeter ralphm: http://mail.jabber.org/pipermail/standards/2012-June/026112.html is the most recent discussion (there were earlier messages, but I changed the subject)
  140. m&m there's an awful lot of SHOULD, and I think they ought to be MUSTs
  141. ralphm stpeter: yeah, they are all still marked as unread
  142. stpeter :)
  143. m&m heh
  144. stpeter truth be told I haven't looked at the labels spec yet either, all I did was publish it to the inbox :(
  145. m&m remember you have one fortnight to raise objections before auto publish!
  146. stpeter loads http://xmpp.org/extensions/inbox/pubsub-labels.html in a tab
  147. m&m I've glanced at it, but I have the same general policy as ralphm (-:
  148. m&m as long as there's no obvious faults, I'm fine publishing a 0.1
  149. m&m ok
  150. m&m 5) date of next meeting
  151. m&m SBTSBC?
  152. ralphm +1
  153. Tobias +1
  154. stpeter yes, that's already in the calendar
  155. m&m I'll note that 7/4 is a US holiday, and I will not be able to make that meeting
  156. m&m but I'm good with next week
  157. ralphm although I might not make it
  158. m&m noted
  159. ralphm I'll be in SF on 7/4 and 7/11
  160. MattJ +1 to next week
  161. m&m very nice
  162. m&m 6) AOB?
  163. Tobias not from me
  164. MattJ This might be more applicable for when Kev is here
  165. MattJ But I wanted to check we are all in agreement about the change I'm making to stanza forwarding
  166. stpeter someone from the "U.S. Access Board" sent me an email message late yesterday asking when XEP-0301 will be done :)
  167. m&m haha
  168. m&m MattJ: ??
  169. MattJ Specifically making the <forward/> a child of the using protocol
  170. m&m oh, I'm ok with that
  171. MattJ this means backwards-incompatible changes to MAM and Carbons
  172. MattJ Ok, fine
  173. MattJ I'm planning to push those in the next couple of days
  174. m&m well, they are EXPERIMENTAL
  175. Tobias stpeter, what's the US Acess Board?
  176. m&m very good
  177. stpeter "The U.S. Access Board is an independent Federal agency devoted to accessibility for people with disabilities. As part of our agency mission, the Board develops and maintains design criteria for the built environment, transit vehicles, telecommunications equipment, and for electronic and information technology. http://www.access-board.gov/"
  178. m&m MattJ: the only thing I might ask is that I can use <forwarded/> "stand-alone" … ish, or at least not put too heavy a restriction on where it's placed
  179. m&m it would help with e2e
  180. Tobias ahh
  181. m&m in e2e, I build up a <forwarded/>, then encode UTF-8 to encrypt
  182. m&m that all gets wrapped in a <e2e/> element
  183. m&m anyway, I look forward to forwarded (-:
  184. m&m anybody else?
  185. m&m going once
  186. m&m going twice
  187. m&m done!
  188. m&m bangs gavel
  189. m&m thanks everyone!
  190. ashward Thanks all!
  191. m&m I'll get minutes out before the end of the day MDT
  192. stpeter thanks to m&m for chairing
  193. MattJ +1
  194. stpeter ashward: so we'll all review the spec again and discuss next Wednesday
  195. ashward Excellent :)
  196. m&m at this point, if no one objects by 7/4, it gets published
  197. stpeter yep
  198. m&m I'll send my objections to XML data element later today, too
  199. m&m goes off to next meeting
  200. stpeter m&m: no need, I think
  201. stpeter m&m: that might be piling on at this point :)
  202. stpeter oh
  203. stpeter I meant <xml/> itself
  204. m&m yes
  205. stpeter not the general concept
  206. stpeter sorry
  207. m&m (-:
  208. ashward has left
  209. m&m could someone remind me the URL for council logs
  210. Tobias see topic
  211. m&m yeah, this client sucks and I can't /-:
  212. Tobias http://www.mauldineconomics.com/
  213. Tobias wrong link
  214. MattJ XMPP Council Room | http://xmpp.org/about-xmpp/xsf/xmpp-council/ | Room logs: http://logs.xmpp.org/council/
  215. m&m (-:
  216. Tobias Room logs: http://logs.xmpp.org/council/
  217. m&m grazé
  218. Tobias my client doesn't allow copying directly from subject line
  219. Tobias *topic
  220. m&m my client displayed it in the chat view, but I cleared it since then
  221. stpeter it's a shame that so few clients show the room subject
  222. m&m Yes. Yes it is
  223. MattJ has left
  224. Kev has joined
  225. Kev We show it, at least. Just copying it doesn't work. Someone should probably fix that.
  226. ralphm Gajim shows it
  227. ralphm allows copying, too
  228. ralphm Let's make it mandatory in our next client certification
  229. Kev has left
  230. Tobias but only for the advanced client profile
  231. stpeter I'm not convinced about the necessity for software certifications -- do people actually use them?
  232. ralphm Oh, did I forgot to add the sarcasmicon *again*?
  233. stpeter ;-)
  234. Tobias it's a nice starting place for client and server devs starting new implementations...but aside of that i don't know
  235. m&m fscking rfc format
  236. ralphm heh
  237. stpeter m&m: problems?
  238. m&m running into line length problems
  239. stpeter in examples?
  240. m&m yeah
  241. m&m goes to fixing
  242. stpeter nods
  243. ralphm does the RFC format also still require pure ASCII?
  244. m&m I wouldn't be so bad if it weren't huge blobs of Base64-encoded data
  245. m&m ralphm: yes
  246. stpeter as the canonical output format, yes
  247. stpeter there's work happening to change that
  248. stpeter but it's slow :)
  249. ralphm you don't say
  250. ralphm so one day, your name can be on them properly
  251. m&m there's an XML format for input, but the RFC editor requires ASCII when submitting
  252. m&m and with much trolling
  253. stpeter happens to be on the RFC Series Advisory Group ... http://www.rfc-editor.org/RSAG.html
  254. ralphm stpeter: a good start would be to have your name listed properly on that page
  255. ralphm haha
  256. stpeter yeah, I just noticed that
  257. stpeter it could be worse
  258. stpeter and hey, I work on Wyknoop Street, too ;-)
  259. m&m that error just won't go away 9-:
  260. stpeter I'm stamping it out everywhere I can
  261. stpeter clearly I fat-fingered it once and I'm still paying the price
  262. m&m makes sure his I-Ds reference it correctly
  263. m&m we need to have a PbuSb service for that (-:
  264. stpeter ;-)
  265. m&m hrm
  266. m&m I wrote a spec on encrypting, but did not talk really about decrypting
  267. stpeter heh
  268. stpeter there's a long thread about that on the cryptography list
  269. stpeter but I've just been deleting all the messages
  270. stpeter "Encryption Without Decryption" :)
  271. m&m well, there are several modes of operation that use the encryption algorithm, but not the decryption algorithm (-:
  272. m&m OFB, CFB, CTR
  273. stpeter having finished one deliverable, decides to dive into some spec about XMPP federation
  274. m&m continues reformatting spec on XMPP e2e
  275. ralphm m&m: I was glad to find that error, only people aware of the street and Dutchmen would notice.
  276. m&m (-:
  277. m&m ralphm: but since it contains the same number of characters, and starts and ends with the correct characters, many people would miss it!
  278. ralphm yeah
  279. stpeter wanders off for tea
  280. m&m mmmm …. that's a good idea
  281. ralphm I once read that most people can read text where the inner chars of words are hussled
  282. stpeter yes, I have heard simliar reprots
  283. m&m dammit
  284. stpeter m&m: http://datatracker.ietf.org/doc/rfc5785/
  285. m&m I didn't notice the misspelling until the third time looking at that chat (-:
  286. ralphm m&m: we're That Good™
  287. m&m is it bad that I type and say "ought" instead of "SHOULD" (or that I always want to capitalize SHOULD, MUST, MAY)? (-:
  288. stpeter m&m: nowadays, I never use those keywords unless they are all caps -- instead I use "needs to", "ought to", "might", etc.
  289. m&m ok, I'm glad I'm not the only one
  290. stpeter I'm not saying you MUST do it that way, mind you ;-)
  291. m&m but I MAY if I so wish (-:
  292. stpeter indeed!
  293. ralphm at least that's what I RECOMMEND
  294. m&m ralphm: we SHOULD get together for drinks again
  295. ralphm m&w: when we get together, we SHALL do that. I'm going to mention to my coworkers that it is RECOMMENDED I go to Portland in October.
  296. m&m (-:
  297. stpeter m&m: checked in the problem statement, at least it's a start
  298. m&m grazé
  299. stpeter has left
  300. m&m has left
  301. m&m has joined
  302. m&m has left
  303. Tobias has left