XMPP Council - 2012-06-20


  1. m&m

    T - 15

  2. stpeter

    indeed

  3. stpeter

    I see Ralph and Matthew online

  4. m&m

    T - 10

  5. stpeter sends invitations to Ralph and Matthew

  6. stpeter

    heh

  7. MattJ

    Merci stpeter

  8. stpeter

    hi Tobi!

  9. Tobias

    hello

  10. m&m

    very good … we at least have quorum, assuming no one disappears in the next 7 minutes (-:

  11. stpeter

    ashward: howdy

  12. ashward

    Hello

  13. stpeter

    Ralph just went idle, but perhaps he'll return to whatever device he's using at the moment

  14. stpeter notes that ashward is a co-author of the pubsub-labels proposal

  15. ashward

    It's my first XEP I've written, so be nice :)

  16. stpeter

    heh

  17. stpeter

    m&m: hardware problems? ;-)

  18. m&m

    no … pebkac

  19. Tobias

    PbuSb :D

  20. m&m

    (-:

  21. Tobias

    that'd be hard to pronounce

  22. m&m

    Tuesday nights to Wednesday mornings are tough for me (-:

  23. MattJ is nearly here

  24. m&m

    we have a Ralph, and just in time!

  25. ralphm

    hi!

  26. m&m bangs gavel

  27. m&m

    0) Roll Call

  28. m&m

    yo es presente

  29. Tobias

    here

  30. m&m

    MattJ and ralphm?

  31. m&m gets minutes prepped

  32. ralphm

    yes, I'm still here

  33. m&m

    thank you, and we'll assume the same from MattJ

  34. m&m

    1) XEP-0047 - Advance to Final?

  35. Tobias

    +1

  36. ralphm

    +1

  37. MattJ

    I'm here

  38. MattJ

    Is this +1 for a last call, or did we have that?

  39. MattJ

    (or do we need another?)

  40. m&m

    we already had LC, with one minor correction

  41. MattJ

    The data length? I'm not convinced (either way) of how minor that is

  42. ralphm

    the LC was in May and earlier this month

  43. m&m

    there was a correction

  44. stpeter

    actually the LC was in February or so but it took a while for me to reply to the feedback :)

  45. m&m

    (-:

  46. ralphm

    eh, right

  47. MattJ

    That's fine

  48. m&m

    anyway, if we'd rather re-issue LC, that's fine with me

  49. MattJ

    Well I agree with the new text

  50. ralphm

    MattJ: do you have any instructions for such an LC?

  51. MattJ

    The old text was unclear, so... let's just go +1

  52. m&m

    and I'm +1

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

  54. ralphm

    Kev to vote on list

  55. m&m

    yup

  56. m&m

    2) XEP-0191 - Accept rev 1.2?

  57. MattJ

    stpeter, the old text definitely leant towards post-encoded data (even if that wasn't intentional)

  58. MattJ

    I suspect (but have no data to go on) that most implementations don't enforce it, so it doesn't matter

  59. ralphm

    +1 on XEP-0191

  60. stpeter

    MattJ: yes it did, but The Implementers Have Spoken™

  61. m&m

    that was my take … at least a couple of implementors spoke up

  62. MattJ

    Not all, but I guess as many as shall

  63. m&m

    if we wait for all, no draft would go final

  64. Tobias

    +1 for 191

  65. ralphm

    100% is unattainable, of course

  66. MattJ

    I'll vote on-list for 191

  67. MattJ

    I haven't read all the new text

  68. ralphm

    MattJ: there isn't much, just a reshuffle and rename

  69. m&m

    anyway, +1 on −191 … the only "significant" change is a reorganization

  70. stpeter

    right

  71. ralphm

    you can do it in parallel while we move on

  72. m&m

    3) inbox: Data Forms XML Element

  73. ralphm

    I don't like this

  74. Tobias

    ralphm, what don't you like about it?

  75. MattJ

    ralphm, I have another meeting overrunning in parallel :)

  76. m&m

    ouch

  77. stpeter

    heh

  78. m&m

    well, there are obvious problems with the draft, IMO

  79. m&m

    such as <xml/> is not a well-formed element

  80. ralphm

    Well, I'd rather have the XML outside of the form

  81. MattJ

    Outside?

  82. stpeter

    m&m: yes, noted on the standards@ list

  83. ralphm

    the reasoning comes back to a discussion I had with Blaine Cook years ago

  84. ralphm

    on pubsub+atom

  85. Tobias

    outside and then referencing it from withing the form?

  86. m&m

    ralphm: are you −1 on this?

  87. m&m

    I'm −1 until the obvious flaws are fixed

  88. stpeter looks forward to hearing the story about Blaine :)

  89. MattJ too

  90. m&m

    heh

  91. Tobias

    well... m&m's argument of xml being not well-formed is enough for a -1 from me

  92. 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/>

  93. ralphm

    Tobias: if referencing is not too hard, I'd prefer that, yes

  94. m&m

    it's all about context

  95. m&m

    ralphm: will you post a rejection reply on the list?

  96. ralphm

    m&m: In most cases, parsing messages requires looking at the whole stanza anyway

  97. Tobias

    ralphm, if we define clear and specific rules for referencing sure, that'd be fine

  98. stpeter

    m&m: IMHO it's more about having a discussion than sending a rejection :)

  99. m&m

    fair enough (-:

  100. m&m

    s/rejection/obections/

  101. ralphm

    stpeter: indeed. sorry I didn't make that clear

  102. m&m

    I realized it was the wrong word the moment I hit <ENTER>

  103. ralphm

    I'm +1 on publishing

  104. stpeter

    ralphm: it was clear to me

  105. m&m

    ok, then I'll send the objections email

  106. ralphm

    (to stay consistent with all the XEPs I've not objected to during my terms, haha)

  107. m&m

    there's a couple of other things that bother me, but I'm not sure they're worth holding up the proposal

  108. stpeter

    Sergey and I had a long discussion about it on the standards@ list but no one else participated IIRC

  109. m&m

    4) inbox: Security Labels in PubSub (or PbuSb)

  110. ralphm

    stpeter: I'll look that up

  111. ralphm

    I'd like to postpone my vote on this

  112. ralphm

    wait

  113. ralphm

    +1 on publishing

  114. ralphm

    but I want to read it still

  115. m&m

    so, I'm +1 on publishing

  116. MattJ

    I'll vote on-list

  117. m&m

    but I implore the authors to rethink some of their normative language (-:

  118. Tobias

    haven't read it yet...will vote on list for this one

  119. 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)

  120. m&m

    there's an awful lot of SHOULD, and I think they ought to be MUSTs

  121. ralphm

    stpeter: yeah, they are all still marked as unread

  122. stpeter

    :)

  123. m&m

    heh

  124. stpeter

    truth be told I haven't looked at the labels spec yet either, all I did was publish it to the inbox :(

  125. m&m

    remember you have one fortnight to raise objections before auto publish!

  126. stpeter loads http://xmpp.org/extensions/inbox/pubsub-labels.html in a tab

  127. m&m

    I've glanced at it, but I have the same general policy as ralphm (-:

  128. m&m

    as long as there's no obvious faults, I'm fine publishing a 0.1

  129. m&m

    ok

  130. m&m

    5) date of next meeting

  131. m&m

    SBTSBC?

  132. ralphm

    +1

  133. Tobias

    +1

  134. stpeter

    yes, that's already in the calendar

  135. m&m

    I'll note that 7/4 is a US holiday, and I will not be able to make that meeting

  136. m&m

    but I'm good with next week

  137. ralphm

    although I might not make it

  138. m&m

    noted

  139. ralphm

    I'll be in SF on 7/4 and 7/11

  140. MattJ

    +1 to next week

  141. m&m

    very nice

  142. m&m

    6) AOB?

  143. Tobias

    not from me

  144. MattJ

    This might be more applicable for when Kev is here

  145. MattJ

    But I wanted to check we are all in agreement about the change I'm making to stanza forwarding

  146. stpeter

    someone from the "U.S. Access Board" sent me an email message late yesterday asking when XEP-0301 will be done :)

  147. m&m

    haha

  148. m&m

    MattJ: ??

  149. MattJ

    Specifically making the <forward/> a child of the using protocol

  150. m&m

    oh, I'm ok with that

  151. MattJ

    this means backwards-incompatible changes to MAM and Carbons

  152. MattJ

    Ok, fine

  153. MattJ

    I'm planning to push those in the next couple of days

  154. m&m

    well, they are EXPERIMENTAL

  155. Tobias

    stpeter, what's the US Acess Board?

  156. m&m

    very good

  157. 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/"

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

  159. m&m

    it would help with e2e

  160. Tobias

    ahh

  161. m&m

    in e2e, I build up a <forwarded/>, then encode UTF-8 to encrypt

  162. m&m

    that all gets wrapped in a <e2e/> element

  163. m&m

    anyway, I look forward to forwarded (-:

  164. m&m

    anybody else?

  165. m&m

    going once

  166. m&m

    going twice

  167. m&m

    done!

  168. m&m bangs gavel

  169. m&m

    thanks everyone!

  170. ashward

    Thanks all!

  171. m&m

    I'll get minutes out before the end of the day MDT

  172. stpeter

    thanks to m&m for chairing

  173. MattJ

    +1

  174. stpeter

    ashward: so we'll all review the spec again and discuss next Wednesday

  175. ashward

    Excellent :)

  176. m&m

    at this point, if no one objects by 7/4, it gets published

  177. stpeter

    yep

  178. m&m

    I'll send my objections to XML data element later today, too

  179. m&m goes off to next meeting

  180. stpeter

    m&m: no need, I think

  181. stpeter

    m&m: that might be piling on at this point :)

  182. stpeter

    oh

  183. stpeter

    I meant <xml/> itself

  184. m&m

    yes

  185. stpeter

    not the general concept

  186. stpeter

    sorry

  187. m&m

    (-:

  188. m&m

    could someone remind me the URL for council logs

  189. Tobias

    see topic

  190. m&m

    yeah, this client sucks and I can't /-:

  191. Tobias

    http://www.mauldineconomics.com/

  192. Tobias

    wrong link

  193. MattJ

    XMPP Council Room | http://xmpp.org/about-xmpp/xsf/xmpp-council/ | Room logs: http://logs.xmpp.org/council/

  194. m&m

    (-:

  195. Tobias

    Room logs: http://logs.xmpp.org/council/

  196. m&m

    grazé

  197. Tobias

    my client doesn't allow copying directly from subject line

  198. Tobias

    *topic

  199. m&m

    my client displayed it in the chat view, but I cleared it since then

  200. stpeter

    it's a shame that so few clients show the room subject

  201. m&m

    Yes. Yes it is

  202. Kev

    We show it, at least. Just copying it doesn't work. Someone should probably fix that.

  203. ralphm

    Gajim shows it

  204. ralphm

    allows copying, too

  205. ralphm

    Let's make it mandatory in our next client certification

  206. Tobias

    but only for the advanced client profile

  207. stpeter

    I'm not convinced about the necessity for software certifications -- do people actually use them?

  208. ralphm

    Oh, did I forgot to add the sarcasmicon *again*?

  209. stpeter

    ;-)

  210. Tobias

    it's a nice starting place for client and server devs starting new implementations...but aside of that i don't know

  211. m&m

    fscking rfc format

  212. ralphm

    heh

  213. stpeter

    m&m: problems?

  214. m&m

    running into line length problems

  215. stpeter

    in examples?

  216. m&m

    yeah

  217. m&m goes to fixing

  218. stpeter nods

  219. ralphm

    does the RFC format also still require pure ASCII?

  220. m&m

    I wouldn't be so bad if it weren't huge blobs of Base64-encoded data

  221. m&m

    ralphm: yes

  222. stpeter

    as the canonical output format, yes

  223. stpeter

    there's work happening to change that

  224. stpeter

    but it's slow :)

  225. ralphm

    you don't say

  226. ralphm

    so one day, your name can be on them properly

  227. m&m

    there's an XML format for input, but the RFC editor requires ASCII when submitting

  228. m&m

    and with much trolling

  229. stpeter happens to be on the RFC Series Advisory Group ... http://www.rfc-editor.org/RSAG.html

  230. ralphm

    stpeter: a good start would be to have your name listed properly on that page

  231. ralphm

    haha

  232. stpeter

    yeah, I just noticed that

  233. stpeter

    it could be worse

  234. stpeter

    and hey, I work on Wyknoop Street, too ;-)

  235. m&m

    that error just won't go away 9-:

  236. stpeter

    I'm stamping it out everywhere I can

  237. stpeter

    clearly I fat-fingered it once and I'm still paying the price

  238. m&m makes sure his I-Ds reference it correctly

  239. m&m

    we need to have a PbuSb service for that (-:

  240. stpeter

    ;-)

  241. m&m

    hrm

  242. m&m

    I wrote a spec on encrypting, but did not talk really about decrypting

  243. stpeter

    heh

  244. stpeter

    there's a long thread about that on the cryptography list

  245. stpeter

    but I've just been deleting all the messages

  246. stpeter

    "Encryption Without Decryption" :)

  247. m&m

    well, there are several modes of operation that use the encryption algorithm, but not the decryption algorithm (-:

  248. m&m

    OFB, CFB, CTR

  249. stpeter having finished one deliverable, decides to dive into some spec about XMPP federation

  250. m&m continues reformatting spec on XMPP e2e

  251. ralphm

    m&m: I was glad to find that error, only people aware of the street and Dutchmen would notice.

  252. m&m

    (-:

  253. 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!

  254. ralphm

    yeah

  255. stpeter wanders off for tea

  256. m&m

    mmmm …. that's a good idea

  257. ralphm

    I once read that most people can read text where the inner chars of words are hussled

  258. stpeter

    yes, I have heard simliar reprots

  259. m&m

    dammit

  260. stpeter

    m&m: http://datatracker.ietf.org/doc/rfc5785/

  261. m&m

    I didn't notice the misspelling until the third time looking at that chat (-:

  262. ralphm

    m&m: we're That Good™

  263. m&m

    is it bad that I type and say "ought" instead of "SHOULD" (or that I always want to capitalize SHOULD, MUST, MAY)? (-:

  264. stpeter

    m&m: nowadays, I never use those keywords unless they are all caps -- instead I use "needs to", "ought to", "might", etc.

  265. m&m

    ok, I'm glad I'm not the only one

  266. stpeter

    I'm not saying you MUST do it that way, mind you ;-)

  267. m&m

    but I MAY if I so wish (-:

  268. stpeter

    indeed!

  269. ralphm

    at least that's what I RECOMMEND

  270. m&m

    ralphm: we SHOULD get together for drinks again

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

  272. m&m

    (-:

  273. stpeter

    m&m: checked in the problem statement, at least it's a start

  274. m&m

    grazé