XMPP Council - 2011-03-23


  1. stpeter

    T-15 minutes?

  2. MattJ

    Aye

  3. Kev

    Yes please.

  4. stpeter

    posted to identi.ca

  5. stpeter

    I just processed the forwarding proposal, too

  6. Kev

    !agendaappend http://www.xmpp.org/extensions/inbox/forwarding.html Accept as XEP?

  7. Kanchil+

    Kev: Done.

  8. Kev

    stpeter: So I saw :)

  9. MattJ

    Thanks :)

  10. Kev

    Indeed, murky.

  11. stpeter

    also, I received a bug report on the XEP-0198 schema so I processed that just now

  12. linuxwolf

    cutting the submission awfully close (-:

  13. stpeter

    heh

  14. stpeter

    could be considered next week or week after

  15. MattJ

    It's a small XEP!

  16. MattJ

    But really, I don't mind :)

  17. linuxwolf

    "I don't know if I can consider it at this late stage…"

  18. Kev

    It is a small XEP, and Peter announced that Council would vote today, so I have to put it on the agenda :)

  19. linuxwolf

    j/k… (-:

  20. stpeter

    I haven't looked at how the new http://xmpp.org/extensions/inbox/forwarding.html differs from the old http://xmpp.org/extensions/inbox/forwarding-delivery.html and http://xmpp.org/extensions/inbox/forwarding-request.html

  21. stpeter

    brb

  22. Kev

    stpeter: It's just an encapsulation format (unlike forwarding-request) to be used in other XEPs (like the upcoming Message Archive Management), and it's a straightforward complete encapsulation, unlike forwarding-deliver.

  23. linuxwolf

    mmmm….competing specs!

  24. linuxwolf

    Kev: and I have yet another BCP I'd like to propose

  25. Kev

    I have people working on the 'back yard' at the moment, so I'm sorry if I have to vanish at an inopportune moment for a couple of minutes.

  26. Kev

    linuxwolf: Good. You have 9 minutes.

  27. MattJ

    Hey, that's not fair

  28. linuxwolf

    (optional) version info via caps URL

  29. linuxwolf

    MattJ: do you see me presenting an actual spec? (-:

  30. MattJ

    linuxwolf, thankfully no, I want to hold the record for shortest submission->vote->acceptance for at least a short time :)

  31. linuxwolf

    in that case, I might just have to defer acceptance… (-:<

  32. MattJ

    You wouldn't :(

  33. linuxwolf is feeling snarky

  34. Kev

    I hope snarky is over-age, then.

  35. linuxwolf

    MattJ: use of reverse smileys may dissuade me from delay

  36. MattJ

  37. Kev

    (-:<

  38. stpeter

    aha, I see what you're after in http://xmpp.org/extensions/inbox/forwarding.html -- that's quite straightforward

  39. Florob

    😸

  40. stpeter

    the old specs were about stanza forwarding a la .forward

  41. Kev

    Right.

  42. Kev

    So e.g. carbons should use this format.

  43. Kev

    As ideal, should the ad-hoc for forwarding unread messages.

  44. Kev

    As should 136bis

  45. stpeter

    +1 to 136bis

  46. linuxwolf

    well, carbons could use the older forwarding specs, too

  47. MattJ

    136bis is on the way... I know because one of the few remaining todo items is "choose a title" :)

  48. stpeter

    I was mentioning just yesterday how we need to de-ian-ize certain specs like 136

  49. linuxwolf

    but I prefer the form from Messers WIld and Smith

  50. stpeter

    (mentioning to linuxwolf that is)

  51. Kev

    Matt's approach is to deny 136 ever existing. :)

  52. linuxwolf

    lol

  53. Kev

    Which suits me fine.

  54. MattJ

    It's not like it's seen wide adoption (and it's not hard to see why)

  55. MattJ

    I'm mostly excited about the new protocol simply because finally people might implement archiving

  56. linuxwolf

    maybe

  57. linuxwolf

    (-:

  58. stpeter

    I just invited Fritzy

  59. MattJ

    I'd love it to become a more mainstream feature - it's a really common request from users

  60. stpeter

    :)

  61. stpeter

    hi Nathan!

  62. linuxwolf

    it definitely is

  63. Kev

    MattJ: Well, I want it in Swift, at least. Especially when used with the rest of the multi-resource stuff.

  64. MattJ

    That, and "I want my conversations to appear in all my clients"

  65. stpeter

    no sign of Mr. Meijer

  66. fritzy

    Howdy

  67. Kev

    I have to AFK for a moment, I'll be back within 2mins or so.

  68. stpeter

    MattJ: forwarding is a really common request, or history?

  69. linuxwolf

    history

  70. linuxwolf

    (logging, auditing, caching, ....)

  71. MattJ

    stpeter, history

  72. stpeter

    nod

  73. stpeter

    just checking

  74. MattJ

    Forwarding would be a nice addition to clients in itself, but I suspect users are just going to continue with their copying and their pasting :)

  75. Kev

    Right.

  76. Kev

    Let's start :)

  77. Kev

    !agendaup

  78. Kanchil+

    Kev: -9) Fini.

  79. Kev

    !agendaup 10

  80. Kanchil+

    Kev: 1) Roll call

  81. linuxwolf

    here

  82. MattJ

    Here

  83. fritzy

    howdy

  84. fritzy

    I mean here

  85. Kev

    !agendaup

  86. Kanchil+

    Kev: 2) Agenda bashing

  87. linuxwolf

    request to talk about caps

  88. linuxwolf

    )(see above)

  89. Kev

    Is that a real item or AOB? :)

  90. linuxwolf

    it can be an AOB

  91. Kev

    Ok.

  92. Kev

    Anyone else?

  93. fritzy

    nossir

  94. stpeter

    it's hard to bash an agenda that we can't see :)

  95. MattJ

    Nope

  96. MattJ

    Gah, brb 60 sec

  97. fritzy

    we're blind?

  98. Kev

    stpeter: Well, I sent it out earlier in the week.

  99. Kev

    Plus the item you added today :)

  100. Kev

    But sure

  101. Kev

    !agenda

  102. Kanchil+

    Kev: 1) Roll call 2) Agenda bashing 3) XEP-0065: Accept version 1.8? 4) http://www.xmpp.org/extensions/inbox/resource-locking.html Accept as XEP? 5) http://www.xmpp.org/extensions/inbox/forwarding.html Accept as XEP? 6) Date of next meeting 7) Any other business Fini

  103. linuxwolf

    one could !agenda

  104. linuxwolf

    heh

  105. stpeter

    many thanks

  106. stpeter

    seems fine to me

  107. Kev

    !agendaup

  108. Kanchil+

    Kev: 3) XEP-0065: Accept version 1.8?

  109. Kev

    I haven't reviewed the diff. I'll do so and on-list it up.

  110. fritzy

    me neither

  111. Kev

    I'll also wait for MattJ for a moment before moving on.

  112. linuxwolf

    and neither have I

  113. stpeter

    the diff is hard to read, I find

  114. Kev

    Does anyone object to waiting for a moment for Matt to catch up?

  115. stpeter

    fine by me

  116. linuxwolf

    (defeaning silience)

  117. linuxwolf

    /sigh

  118. waqas chooses not to object

  119. fritzy

    I'm easy

  120. linuxwolf

    I've got too many docs to write today to be typoing

  121. MattJ

    Sorry, back

  122. Kev

    !agendaup 0

  123. Kanchil+

    Kev: 3) XEP-0065: Accept version 1.8?

  124. Kev

    MattJ: ^

  125. MattJ

    I have it open, I haven't finished reviewing it, so I'll post on-list too

  126. Kev

    !agendaup

  127. Kanchil+

    Kev: 4) http://www.xmpp.org/extensions/inbox/resource-locking.html Accept as XEP?

  128. Kev

    I don't object.

  129. Kev

    I'm not entirely convinced by each of the details, but I don't object :)

  130. fritzy

    +1

  131. linuxwolf

    +1, obviously (-:

  132. MattJ

    I don't object either, but I have some small feedback I'll post to standards@ when it's published

  133. Kev

    Specifically, I think it should always lock when receiving a new message, rather than maybe locking and maybe unlocking.

  134. stpeter

    BTW the most up-to-date diff for 65 is http://xmpp.org/extensions/diff/api/xep/0065/diff/1.7/vs/1.8rc4

  135. Kev

    I'm also not sure that <gone/> justifies an unlock, but I'm less worried about that.

  136. stpeter

    (but it's close to unreadable)

  137. linuxwolf

    Kev: to be fair, this is based on 10+ experience (-:

  138. Kev

    I'm happy to not really worry about this, as I think the later multi-client XEP solves all problems ;)

  139. linuxwolf

    (well, not specifically with <gone/> itself, but the entire concept)

  140. linuxwolf

    we shall see (-:

  141. Kev

    This is *almost* what we're doing in Swift.

  142. Kev

    Apart from not bothering with gone yet, and rebinding instead of unbinding on a new message.

  143. Kev

    Anyway.

  144. Kev

    !agendaup

  145. Kanchil+

    Kev: 5) http://www.xmpp.org/extensions/inbox/forwarding.html Accept as XEP?

  146. Kev

    +1 :)

  147. linuxwolf

    hmmm

  148. Kev

    The background for this:

  149. Kev

    Matt's got a new archiving spec, there's carbons, there's an ad-hoc for forwarding messages.

  150. Kev

    It'd be good to have a common format for the forwarded messages in each of these cases.

  151. Kev

    Thus this spec

  152. linuxwolf

    +1 actually

  153. fritzy

    +1

  154. linuxwolf

    I think I still have some security concerns, but I haven't exactly had a lot of time to read it (-:

  155. Kev

    linuxwolf: It's a format rather than a protocol.

  156. stpeter

    linuxwolf: sure, the interaction with signing and encryption might be "interesting"

  157. Kev

    So I think the security concerns belong to the protocol using the format, but I could be persuaded otherwise.

  158. Kev

    MattJ: Your vote? :)

  159. linuxwolf

    Kev: technically, it's a protocol extension format

  160. linuxwolf

    (-:

  161. fritzy

    does this technically change the jabber:client ns?

  162. Kev

    fritzy: Of course not.

  163. fritzy

    allowing another <message /> child?

  164. MattJ

    fritzy, it does not, why?

  165. Kev

    jabber:client says nothing about the number of message children.

  166. MattJ

    plus it's a child of a child

  167. fritzy

    right, that's not what I meant

  168. MattJ

    of another namespace

  169. MattJ

    so another schema (forwarding) applies

  170. stpeter

    http://tools.ietf.org/html/rfc3922 already had <presence/> within <presence/> (but a different namespace)

  171. MattJ

    AIUI

  172. MattJ

    Kev, +1 surprise, surprise! :)

  173. fritzy

    Oh, you're right MattJ.

  174. Kev

    Excellent.

  175. Kev

    !agendaup

  176. Kanchil+

    Kev: 6) Date of next meeting

  177. Kev

    Ok, so, daylight savings change.

  178. MattJ

    Next week suits me

  179. linuxwolf

    heh

  180. Kev

    So I propose next Wednesday at 1500GMT.

  181. fritzy

    Wed 1600 Kevin Time. If he's in an unusual timezone for him, so help us all.

  182. linuxwolf notes that some of us already went through a TZ change

  183. stpeter notes that he'll go through the time change again in Prague on Sunday morning

  184. Kev

    linuxwolf: Indeed. That's why I noted just before the US started changing that we weren't shifting Council yet :)

  185. MattJ

    1500GMT? Why the change?

  186. Kev

    MattJ: So it remains 4PM UK time.

  187. MattJ

    I never change my clocks for DST :)

  188. stpeter

    heehee

  189. stpeter

    good for you

  190. linuxwolf

    MattJ: that explains a lot (-:

  191. MattJ

    Heh

  192. stpeter

    I just use the sundial in my back yard

  193. MattJ

    Ok, I'm happy with 1500GMT next week

  194. Kev

    Is everyone happy with this?

  195. stpeter

    so 15:00 GMT?

  196. fritzy

    sure

  197. MattJ

    or to use the sundial in stpeter's back yard

  198. stpeter

    heh

  199. stpeter edits ./council/events.xml

  200. linuxwolf

    fine either way

  201. Kev

    stpeter: Thanks.

  202. Kev

    !agendaup

  203. Kanchil+

    Kev: 7) Any other business

  204. linuxwolf

    ok

  205. Kev

    linuxwolf !

  206. stpeter

    it's doubtful that I'll attend next week's meeting

  207. fritzy

    ok

  208. linuxwolf

    so, I'd like to propose a caps URL format recommendation, if clients are interested in reporting version/platform info

  209. stpeter

    let's see, I'll be in the CORE WG session at that time

  210. Kev

    stpeter: Enjoy Prague :)

  211. stpeter

    I shall, thanks :)

  212. stpeter

    anyway

  213. stpeter

    linuxwolf?

  214. linuxwolf is slightly jealous

  215. linuxwolf

    oh yes, so

  216. stpeter

    we need CSN in these meetings :)

  217. Kev

    stpeter: I said that last week.

  218. linuxwolf

    RT: linuxwolf: so, I'd like to propose a caps URL format recommendation, if clients are interested in reporting version/platform info

  219. Kev

    linuxwolf: Right, I'm waiting for your next line after that :)

  220. MattJ

    linuxwolf, I don't understand, please continue

  221. stpeter

    (calendar updated)

  222. linuxwolf

    hold on…shooing away IRL trolls

  223. stpeter

    heehee

  224. stpeter isn't in the office today, so it's not my fault

  225. MattJ

    Grab a piece of chalk and draw a circle around your desk

  226. linuxwolf

    ok, so the idea is to inconspicuously indicate the version/platform via "query parameters" to the caps node URL, assuming a client sends a URL (per recommendations)

  227. stpeter is favor of just about anything that kills off iq:version

  228. fritzy

    haha

  229. linuxwolf

    e.g. http://outer-planes.net/matts-magical-client?v=2011.03.12314&p=linux

  230. MattJ loves iq:version, long live iq:version!

  231. linuxwolf

    and doesn't impact the actual caps hash

  232. stpeter

    :)

  233. linuxwolf

    yeah, I'd like to see iq:version DIAF

  234. MattJ

    linuxwolf, ok, why this?

  235. waqas

    I would like to fix caps hashes :)

  236. linuxwolf

    MattJ: because large organizations like to know what clients their users are logging in with, without laying down the lockout hammer

  237. stpeter

    yes, we do need to fix the security hole that waqas found

  238. linuxwolf

    definitely

  239. Kev

    So, I have no particular opinion on this until I've seen some examples.

  240. linuxwolf

    RT: linuxwolf: e.g. http://outer-planes.net/matts-magical-client?v=2011.03.12314&p=linux

  241. Kev

    Yeees.

  242. Kev

    I meant slightly more of an exposition than that :)

  243. stpeter

    heh

  244. stpeter looks forward to a mini-spec on the topic or a patch to 115

  245. linuxwolf

    or, say, http://ww.cisco.com/go/jabber?v=8.0.3&p=mac

  246. MattJ

    linuxwolf, why not just file a bug with the relevant clients?

  247. MattJ

    Say "it would be really nice if you included the version and platform in your caps url"

  248. linuxwolf

    well, it's hard to file a bug if there's not defined (recommended) format

  249. Kev

    I don't think I have any particular objections to this, I'd have to sit down with 115 and the new spec and be sure there's no unfortunate interactions.

  250. linuxwolf

    and I likely would…it would be nice for us to agree to a general format

  251. Kev

    So...bring on the spec :)

  252. linuxwolf

    well…so with the 115 problems

  253. MattJ

    I don't see why we need to define such a format, it's not for interop and I don't think anyone is going to enforce it

  254. linuxwolf

    do we want a separate spec, or an implementation detail within 115 (as we fix 115)

  255. Kev

    MattJ: You can say the same about iq:version :)

  256. linuxwolf

    MattJ: It actually is for interop

  257. MattJ

    Kev, I bet someone, somewhere, has used iq:version for interop

  258. Kev

    linuxwolf: I *think* a sidenote in 115, but I don't feel strongly.

  259. linuxwolf

    iq:version needs to DIAG (-:

  260. linuxwolf

    I can go either way

  261. linuxwolf

    fixing 115 is not a small task

  262. Kev

    I don't think I know DIAG. What's 'G'?

  263. linuxwolf

    gah

  264. Kev

    Ah.

  265. linuxwolf

    DIAF

  266. linuxwolf

    Gulag?

  267. Kev

    No, I like DIA Gah

  268. linuxwolf

    lol...literally

  269. linuxwolf

    ok

  270. Kev

    Anyway, I think we're vaguely done with this are we?

  271. fritzy

    there you go

  272. linuxwolf

    so, I (or some minion) can writeup a tiny XEP about it

  273. Kev

    linuxwolf: Sure.

  274. linuxwolf

    I don't know if I want to tackle fixing hashes at the same time we add this note

  275. MattJ

    Sounds like a plan

  276. stpeter

    ah, to have minions

  277. fritzy

    that'd be nice

  278. Kev

    So

  279. linuxwolf

    technically, my minions are loaned to me

  280. Kev

    !agendaup 0

  281. Kanchil+

    Kev: 7) Any other business

  282. linuxwolf

    /fini

  283. fritzy

    !done

  284. fritzy

    or wait, is that not-done?

  285. Kev

    !agendaup

  286. Kanchil+

    Kev: 8) Fini.

  287. Kev

    Thanks all :)

  288. Kev bangs the gavel

  289. linuxwolf

    adios

  290. Kev

    !agendaup -8

  291. Kanchil+

    Kev: 0) Fini.

  292. MattJ

    Wow, on the dot

  293. Kev

    !agendaclear

  294. Kanchil+

    Kev: Done.

  295. linuxwolf goes off to read a dictionary, hopefully soaking in better spelling mojo

  296. stpeter returns to his review of OAuth spe s

  297. stpeter

    specs even

  298. linuxwolf feels less horrible now…thanks stpeter (-:

  299. stpeter

    :P

  300. fritzy

    cio

  301. stpeter

    who is the cio?

  302. bear

    that's an italian typo - he meant ciao

  303. stpeter

    I figured :)

  304. stpeter

    although my Czech friends spell it "čau" :)