XMPP Council - 2011-02-24

  1. mlundblad has left
  2. Tobias has left
  3. Tobias has joined
  4. Kev has left
  5. Kev has joined
  6. Tobias has left
  7. Tobias has joined
  8. Tobias has left
  9. Kooda has left
  10. Kooda has joined
  11. Tobias has joined
  12. stpeter has joined
  13. linuxwolf has joined
  14. linuxwolf quick caffeine run, brb
  15. Kev You've got 16 minutes. Go go go.
  16. stpeter howdy
  17. stpeter replies to Kev's message
  18. Kev Evening.
  19. Kev What was my message?
  20. Kev I've got another agenda item I'm adding now.
  21. linuxwolf oh noes
  22. stpeter your email message about agenda
  23. stpeter sorry, on a conference call at the moment, but multitasking as best as I can :)
  24. Kev Asking Council to review a version published 12 minutes in advance of the meeting seems excessive :p
  25. Fritzy has joined
  26. stpeter heh
  27. stpeter you mean 0047?
  28. Kev Yeah.
  29. stpeter it was discussed on the list, and I assume that Council members are paying attention to the list :P
  30. stpeter http://xmpp.org/extensions/diff/api/xep/0047/diff/1.3rc2/vs/1.3rc3
  31. stpeter I think Council members can read one sentence in 10 minutes
  32. stpeter but hey XEP-0047 has been sitting around for almost a year, what's another week?
  33. Kev I've reviewed the change :p
  34. linuxwolf ditto
  35. linuxwolf found a typo or two
  36. linuxwolf somewhat patiently waits for gavel
  37. Kev As Florian just posted this: http://florianjensen.com/wp-content/uploads/2009/05/meetings.jpg
  38. Fritzy hurray
  39. stpeter :)
  40. Kev Both Ralph and Matt poked.
  41. stpeter k
  42. MattJ has joined
  43. stpeter yay
  44. MattJ Heh, I was waiting in council@c.j.o :)
  45. stpeter heh
  46. linuxwolf heh…newb (-:
  47. ralphm has joined
  48. MattJ I'm in the habit of "/join council" which uses the current server - I guess I was in the wrong room when I typed it
  49. linuxwolf made that mistake a few weeks ago
  50. Kev 4pm!
  51. Kev And a full Council, the fates are smiling upon us.
  52. ralphm 1700
  53. MattJ :)
  54. linuxwolf or it's the Apocalypse
  55. Kev 1) Roll call.
  56. Kev All here!
  57. linuxwolf either would be fine
  58. ralphm yay
  59. Kev 2) Agenda bashing.
  60. Kev (Beyond the extensive on-list bashing)
  61. ralphm I'm gone in 15 min.
  62. stpeter k
  63. stpeter no bashing here
  64. Fritzy plenty on list. :)
  65. Kev A shame this'll be the longest Council for a while :)
  66. Kev 3) XEP-0047 1.3rc3. http://xmpp.org/extensions/diff/api/xep/0047/diff/1.2/vs/1.3rc3 Accept new version?
  67. MattJ +1
  68. linuxwolf found at least one typo, +1 otherwise
  69. linuxwolf "Upon receiving an error related to delivery of a or stanza, the sender"
  70. ralphm +1
  71. stpeter note that I added a sentence the other day but didn't check in the file -- it was discussed on list, however
  72. stpeter linuxwolf: noted
  73. Kev I had a couple of comments about this. As an aside, SHOULD wait for a reply to the iq seems wrong (unrelated to the diff). Is 'wait' the right error? I didn't check bis. And suggesting we continue sending iqs when we start receiving errors sounds wrong.
  74. Kev +1 though.
  75. Fritzy +1 myself, although maybe an example of a wait error would be nice.
  76. Kev 4) XEP-0184, version 1.2rc: http://xmpp.org/extensions/tmp/xep-0184-1.2.html http://xmpp.org/extensions/diff/api/xep/0184/diff/1.1/vs/1.2rc2 Accept new version? See http://mail.jabber.org/pipermail/standards/2011-February/024133.html http://mail.jabber.org/pipermail/standards/2011-February/024160.html
  77. Kev I'm +1 on this. Now that it's been clarified that these aren't read receipts, I'm happy if the bit about not sending replies is modified to say that a client doesn't need the user's configuration to return a receipt to a contact that has a presence sub. I believe that was added at my behest.
  78. stpeter Kev: it was added at your behest, as I recall
  79. linuxwolf +1 also
  80. Fritzy +1, but what about messages from archives. Are we watching for delay?
  81. ralphm +1
  82. Dave Cridland has joined
  83. stpeter Fritzy: I think we have some text about that now, don't we?
  84. stpeter checks
  85. Kev Fritzy: It explicitly says not to send from archive.
  86. Fritzy No, I see that.
  87. Fritzy I meant, it doesn't specify how you know that (yes, I realize that is in another spec)
  88. stpeter ah
  89. Kev I don't think it needs to.
  90. Kev Does it?
  91. Kev Well, it's a simple tweak to say "As in e.g. ..."
  92. stpeter is off his conference call so can concentrate more fully now
  93. Kev stpeter: Are you happy to make the tweak?
  94. Fritzy right, I think it could be a simple reference
  95. linuxwolf well, it does mention XEP-0136...
  96. Kev linuxwolf: Ah, it does?
  97. Kev I reviewed it earlier, forgotten it all now.
  98. Kev In that case, I think we're set.
  99. linuxwolf "An entity MUST NOT send an ack message when a user views messages that have been archived or stored on the client or the server (e.g., viaMessage Archiving <http://xmpp.org/extensions/xep-0136.html> [8 <http://xmpp.org/extensions/tmp/xep-0184-1.2.html#nt-id36424>]), only when first receiving the message."
  100. stpeter we added: 5.5 Archived Messages An entity MUST NOT send an ack message when a user views messages that have been archived or stored on the client or the server (e.g., via Message Archiving [8]), only when first receiving the message.
  101. Kev I think we're set then.
  102. Kev Fritzy?
  103. Fritzy oh, why didn't I see that?!
  104. Fritzy ok
  105. linuxwolf not sure what more can be said
  106. Fritzy (must have been looking at the wrong version or something)
  107. MattJ OT, but I like "[...] this protocol does not enable the sender to know that the intended recipient has read the message or understood the message (if the intended recipient is a human being)" :)
  108. Kev I don't see a MattJ: note.
  109. MattJ I'm +1
  110. Kev note? vote.
  111. Kev Ta.
  112. Fritzy still +1
  113. Kev 5) http://www.xmpp.org/extensions/inbox/realtimetext.html Accept as XEP?
  114. Fritzy -1
  115. linuxwolf ugh
  116. linuxwolf -0
  117. MattJ It struck me that *this* spec would have more interesting interaction with archiving :)
  118. Kev I'm usually +1 on Experimental stuff, and seeing what happens, but this feels so completely non-XMPPish, I'm -1.
  119. linuxwolf just because there's precedence, doesn't mean it's GOOD precedence
  120. MattJ Instant realtime replay of conversations!
  121. Kev I've actually implemented this before, for someone who needed it, using a far far simpler model.
  122. Hirotaka Sato has joined
  123. MattJ Kev, how exactly?
  124. MattJ (and... should we spec it?)
  125. linuxwolf Kev: ditto
  126. Fritzy probably
  127. MattJ This comes up every so often
  128. Kev MattJ: <fragment>I'm half-way through typ</fragment>
  129. ralphm So even if most of us think it is a bad idea, do we really want to discourage specs being made for the use case?
  130. Kev ralphm: No, I think we want to discourage specs that don't seem right.
  131. Fritzy the use case is fine
  132. Kev I'm not -1 because I don't care about the feature.
  133. MattJ If we reject this then we need some clear feedback for the author on why
  134. Kev This is 11,600 words (excluding boilerplate) if my copy/paste/wc skills are ok.
  135. Kev MattJ: I'd like a thread on this on standards@
  136. Kev I'm happy to revote after seeing some community feedback.
  137. Kev I'll weight in on such a discussion (I'm happy to start it)
  138. stpeter +1 to a discussion thread on standards@
  139. ralphm nod
  140. linuxwolf I'll be sure to provide my $0.02USD
  141. Kev I think this is the requirement we currently have set for Council. You can -1, but must post to standards@ with a justification.
  142. stpeter finds two AOB items
  143. ralphm :-)
  144. Fritzy Sure, I'll -1 and post
  145. MattJ Ok, then I'm +1 to the -1 if we discuss it
  146. Kev MattJ: You mean you're +0?
  147. Dave Cridland I
  148. Kev Or you're -1?
  149. Dave Cridland d
  150. Dave Cridland o
  151. Dave Cridland n
  152. Dave Cridland '
  153. Dave Cridland t
  154. Kev Dave Cridland: Stop.
  155. linuxwolf Kev: I was −0 (-:
  156. Dave Cridland ... much like it either. :-)
  157. Fritzy >_<
  158. Kev linuxwolf: yes, I saw that. It'l ralphm's and MattJ's I missed :)
  159. MattJ Kev, put me as +0
  160. stpeter ralphm: the AOB that applies to you is that we need votes from all Council members on http://xmpp.org/extensions/diff/api/xep/0198/diff/1.1/vs/1.2rc2
  161. coolidge25789 has joined
  162. Kev stpeter: That's not AOB, that's last week's meeting :)
  163. ralphm I don't think it is a required to have everyone's +1,-1,0 for moving to experimental
  164. stpeter Kev: it's other business as far as this meeting is concerned :)
  165. Kev ralphm: do you have a stance on rtt before we move on?
  166. Kev No, you can fail to express an opinion, but I want to know if you have one.
  167. ralphm Kev: I agree with the list action
  168. Kev Ok.
  169. ralphm so that appears to be -1 then
  170. Kev :)
  171. Kev 6) http://dave.cridland.net/xeps/google-queue.html This is documentation of a Google protocol. What track should it be? None seem to fit - author doesn't think it's suitable for standards track (should use stream features), Historical is only for pre-XSF documents, and Informational is for BCP. Should the XEP types be tweaked?
  172. stpeter shouldn't it be up to Google folks to document Google extensions?
  173. linuxwolf that's what I was about to ask....
  174. Kev So, Dave poked me about this pre-Council, and I said it should be standards track.
  175. Fritzy Do they care to?
  176. stpeter (however, note that I wrote the documentation for linklocal...)
  177. stpeter (and that was an Apple protocol)
  178. Fritzy We'll make a new track called "Google"
  179. stpeter haha
  180. linuxwolf grr
  181. MattJ :D
  182. Kev I don't see that we gain sufficient interoperability to make this worth documenting but not ST.
  183. MattJ I think standards track is fine
  184. coolidge25789 has left
  185. ralphm I think this was discussed with some Google people
  186. linuxwolf yeah, but if it's our standard, some things will need to change
  187. stpeter Jonas is on the author list
  188. ralphm stpeter: right
  189. Kev Dave Cridland can express his opinion on it being ST, but I understand he doesn't think this is the right way to do it.
  190. ralphm so it's ours and theirs
  191. stpeter but yeah we'd at least change the namespace to urn:xmpp:*
  192. Kev I think we should ST it, and do whatever the community thinks is the right thing to do.
  193. Dave Cridland stpeter, But that makes it a different protocol.
  194. Kev As it does seem simple and useful.
  195. Fritzy Do we need this simplification when we have other solutions?
  196. stpeter indeed it does
  197. Dave Cridland stpeter, THe point of documenting it is to say "this exists", nothign more.
  198. stpeter I think we need to take this to the standards@ list
  199. Kev Fritzy: from my limited understanding, this is actually simple and useful.
  200. stpeter Dave Cridland: in that case, Informational is right
  201. Fritzy Dave Cridland: then it's informational
  202. Kev stpeter: No, because it's not a BCP.
  203. Dave Cridland stpeter, Informational is described as "typically" for BCP, so there is wiggle-room.
  204. Kev Thus the question about whether we should update the XEP-0001 descriptions.
  205. linuxwolf we've used informational for other "not-quite-standard" protocols in the past
  206. ralphm I would say it is historical, but hey
  207. Kev ralphm: Historical means it was written before the JSF existed :)
  208. linuxwolf I would be good with Informational, FWIW
  209. Dave Cridland I originally thought Historical, hence its designation.
  210. Dave Cridland But Informational suits me fine.
  211. stpeter those categories need to be clarified
  212. stpeter now that the XSF has been around for almost 10 years
  213. linuxwolf or reambiguated (-:
  214. MattJ Good point :)
  215. Kev If we do put this as Informational, I think we should also create an ST version, and obsolete this one.
  216. Fritzy hmm..
  217. MattJ FWIW Telepathy does or is planning to implement this
  218. linuxwolf how about we see what the list discussion is first
  219. MattJ I think
  220. Kev Publishing it as Informational means we think it's important enough to be worth publishing. If we don't believe it's the right solution, we should document the right solution.
  221. Fritzy I think this requires some more thought
  222. Dave Cridland Kev, I'm fine with that (and this was my original plan), but the original is deployed in at least one large implementation.
  223. stpeter I think informational documentation of protocols out there in the wild can be helpful
  224. ralphm so, what is the value of redoing it in a new namespace?
  225. Dave Cridland MattJ, Does implement as specified here.
  226. ralphm I don't think I want more/less features
  227. MattJ ralphm, that we can advance the protocol
  228. Kev ralphm: We wouldn't for Informational.
  229. Kev But for ST we need to.
  230. stpeter ralphm: aside from the fact that "google:" is not a legitimate identifier on any planet I know about?
  231. MattJ Heh
  232. ralphm that seems bureaucratic
  233. Kev Good point, it's an illegal namespace :D
  234. ralphm stpeter's argument is sane
  235. stpeter I mean we dropped "jabber:" 8+ years ago?
  236. Kev Anyway.
  237. MattJ Wait, so is jabber:iq:... :)
  238. stpeter it's an illegal namespace, why encourage those?
  239. Kev Anyway.
  240. linuxwolf has left
  241. stpeter MattJ: legacy
  242. linuxwolf has joined
  243. Kev Who is volunteering to start a list discussion?
  244. stpeter we were idiots back then, why encourage more idiocy?
  245. MattJ Dave
  246. linuxwolf Dave
  247. Kev Or are we not bothering and going ahead as Informational?
  248. ralphm stpeter: must namespaces be uris?
  249. MattJ I vote Informational
  250. MattJ and keep the existing namespace
  251. MattJ and then ST it if we want to make our own
  252. MattJ but that's for the list
  253. Kev I do want a discussion about whether this is the optimal approach.
  254. linuxwolf /agreed w/ MattJ
  255. stpeter [Definition: An XML namespace is identified by a URI reference [RFC3986]; element and attribute names may be placed in an XML namespace using the mechanisms described in this specification. ]
  256. Dave Cridland Oh, if you guys are happy with Informational, I see no need to bother the list with it. I'll just submit to the XEP Editor as Informational.
  257. stpeter http://www.w3.org/TR/xml-names/#concepts
  258. Fritzy I don't think it is /the/ optimal approach, but it is very simple, and that sometimes is all a spec needs to be popular
  259. ralphm stpeter: thanks
  260. stpeter +1 to simplicity
  261. Kev So someone has to agree to start the list discussion to see what the best way of doing it is.
  262. Kev If this is sufficiently different, we should ST it.
  263. MattJ Dave Cridland, the list discussion would be on whether we want to make a standards track version of this
  264. Kev Or, rather, create an ST spec to obsolete the informational.
  265. stpeter MattJ: agreed
  266. Dave Cridland MattJ, I think that'll come naturally from submitting this one.
  267. ralphm I think it would be good to rename the namespace only for this reason
  268. Fritzy yeah, let's see what the community thinks
  269. Kev So who's starting the discussion
  270. linuxwolf Dave
  271. Kev Someone volunteer, I volunteered for rtt :)
  272. stpeter Dave has been volunteered
  273. Fritzy haha
  274. Kev Dave Cridland: Happy?
  275. ralphm i.e. if google would have chosen a valid namespace name, I would excuse them from the namespace changing stuff we regularly do
  276. Fritzy Dave is fine with informational, remember?
  277. MattJ I'd volunteer except I know I'll not get around to it right now
  278. Kev Fritzy: Yes, I'm not happy with Informational without a discussion :)
  279. Dave Cridland There's a political problem with renaming the namespace, of course, which is that given the inertia of Google's implementation, there's little hope of seeing deployment there.
  280. ralphm I'm +1 on accepting this on standards track in that case.
  281. Kev I have no objection to this going on ST.
  282. Fritzy sure, plus a little service discovery and away we go
  283. ralphm Dave Cridland: that's an assumption we should verify
  284. Dave Cridland ralphm, I can ask Jonas, of course.
  285. Kev We're 7 minutes away from meeting-tolerance.
  286. ralphm Dave Cridland: I think it would be good of us to make Google aware that their namespaces are illegally named. You could even suggest they use http://google.com/something
  287. ralphm Dave Cridland: please do
  288. ralphm Kev: next?
  289. Kev What are people's current positions? Mine is that I either want list discussion if we want to Informational it, or to do it ST.
  290. taylor26215 has joined
  291. Hirotaka Sato has left
  292. stpeter Kev: same here
  293. linuxwolf ditto
  294. Fritzy +1
  295. Kev Dave Cridland: Are you willing to start the discussion?
  296. Dave Cridland My opinion is that it shouldn't be done this way, or with this namespace, in ST, and the original needs documenting irregardless of whether we persue this as ST.
  297. Fritzy namespace changes can happen during experimental on standards track
  298. Kev I'm happy to publish this Informational and obsoleted by an ST document.
  299. Fritzy hm
  300. linuxwolf Dave: sounds like you can kick off the list discussion… (-:
  301. Fritzy that way we could at least refer to the old version, I suppose
  302. Dave Cridland Righty, I'll do so - shall I formally submit this before or after?
  303. Kev Dave Cridland: Both at the same time would make me happiest.
  304. Fritzy It's all about you, isn't it?
  305. Fritzy ;)
  306. Kev Fritzy: About me? Yes.
  307. ralphm I'm +1 on 0198
  308. ralphm gotta go
  309. Dave Cridland Kev, K. I shall submit now, then, and then kick off the discussion once it's announced.
  310. Kev Bye Ralph.
  311. stpeter is this extension already documented on google.com somewhere?
  312. Kev Dave Cridland: You have the ST version ready?
  313. stpeter needs to transfer the voting tally pages to WordPress
  314. Kev I was saying I didn't want the Informational submitted before the ST one.
  315. Dave Cridland stpeter, Erm. I can't actually recall - I know that Jonas wrote an email describing it to jdev@ at one point.
  316. MattJ Kev, why not?
  317. Dave Cridland Kev, Ah, you want an ST one? Well, that's another issue entirely... I can easily enough write out a proposal, of course.
  318. Kev MattJ: Because if we're Informationalising it without an ST equivalent, I think there should be a discussion on standards@ to see what the community thinks.
  319. MattJ about what?
  320. Kev The right way of doing it.
  321. linuxwolf I think we should allow this informational one first, start the list discussion, and see where it goes
  322. MattJ Informationalising it isn't about the right way of doing it
  323. MattJ It's about how Google have it implemented *now*
  324. MattJ which can be used as the basis of an ST document if we decide we want one
  325. Kev I basically feel unhappy about us documenting this non-ST, given that it's basically one deployment.
  326. Dave Cridland MattJ, Right - at least three implementations of this exist now.
  327. MattJ Kev, one significant deployment
  328. Dave Cridland Kev, It's not one implementation. If it were...
  329. Kev MattJ: Yes.
  330. Kev Dave Cridland: Yes, and I think we should see if it's the right way before we encourage more implementations.
  331. Kev By claiming that this is a BCP.
  332. MattJ I don't see we should claim it as a BCP
  333. Kev MattJ: That's what Informational means.
  334. MattJ The current definition of "informational" is another matter
  335. linuxwolf fine, then let's redefine informational
  336. linuxwolf then publish
  337. MattJ We've already decided it's too limited
  338. Kev linuxwolf: I'm fine with that.
  339. Kev Although that's Board, rather than Council :)
  340. linuxwolf it used to have a broader definition anyway
  341. MattJ So fix XEP-0001, publish queue as informational, debate forming an ST doc from it
  342. stpeter Kev: right :)
  343. stpeter but documentation is good
  344. Dave Cridland (FWIW, I'd be more comfortable with Historical in the XEP framework - ie, "this is how it's been done, we don't say this is a good idea".)
  345. Kev So'd I.
  346. stpeter fine by me
  347. Kev Assuming we modify historical to mean "Implemented outside the standards track"
  348. linuxwolf I'm fine with Historical too
  349. Kev +wordsmithing.
  350. linuxwolf do we also want to clarify what the definition of "is" is (-:
  351. Dave Cridland But that means redefining Historical to encompass things developed outside the XSF but after it was instigated.
  352. stpeter "Documentation is like sex. When it's good, it's very good. When it's bad, it's better than nothing." -- Jeremie Miller
  353. stpeter ok my other call is starting
  354. Dave Cridland stpeter, Is that Jer's quote? I never knew it was him.
  355. Kev Ok, we've passed tolerance.
  356. linuxwolf oh, +1 on 198
  357. stpeter meeting city this morning!
  358. stpeter linuxwolf: noted
  359. stpeter and ralphm's vote on 198 is noted
  360. Kev I'm happy to vote on this next week as Historical, and someone should ask Board to modify -0001.
  361. Kev 7) Date of next meeting
  362. Kev Next Wednesday?
  363. linuxwolf wfm
  364. MattJ +1
  365. Kev Fritzy: ?
  366. Fritzy that's fine.
  367. Kev 8) AOB?
  368. Fritzy +1
  369. stpeter I'll update the calendar for next Wed
  370. Kev Ta.
  371. Fritzy Nope.
  372. stpeter some folks need to vote on 198
  373. stpeter and the vcard inbox item
  374. Kev stpeter: We know.
  375. Fritzy yup, I'll do that on list today
  376. stpeter just a reminder :)
  377. Fritzy plays catchup.
  378. Kev Anything else?
  379. stpeter nope
  380. linuxwolf nay
  381. Kev Ok.
  382. Fritzy nodda
  383. MattJ Just to confirm... my votes for 198 and vcard4 are in, yes? I got no reply
  384. Kev MattJ: I've not seen them on-list. If they're in the buffer, I'll see them when I do the minutes :)
  385. stpeter MattJ: didn't see those
  386. MattJ Hmph
  387. stpeter MattJ: scrolling up
  388. MattJ I'll try from my other account again
  389. Kev Ok.
  390. stpeter MattJ: probably just my fault
  391. MattJ erm, I sent to the list, sorry
  392. stpeter ah ok
  393. stpeter that works
  394. Kev bangs the gavel
  395. Kev Thanks all.
  396. stpeter thanks
  397. Fritzy ciao
  398. linuxwolf adios
  399. MattJ Thanks
  400. stpeter turns his attention to the IESG telechat
  401. MattJ Enjoy :)
  402. stpeter oh yeah
  403. linuxwolf preps for next meeting
  404. MattJ Just can't get enough telechats
  405. linuxwolf hi ho, hi by
  406. stpeter this is a fun one -- the meeting schedule for IETF 80
  407. MattJ Is that Prague?
  408. stpeter yes
  409. linuxwolf Some say that's Kev's favorite city to visit
  410. stpeter haha
  411. stpeter it's a beautiful city
  412. MattJ Kev, ok... I don't see my email in the archives... +1s anyway
  413. MattJ Kev, I also asked where vcard4 puts User Profile
  414. linuxwolf has left
  415. Steffen Larsen has joined
  416. taylor26215 has left
  417. Steffen Larsen has left
  418. Dave Cridland has left
  419. Tobias has left
  420. ralphm has left
  421. bear has left
  422. bear has joined
  423. ralphm has joined
  424. julm has joined
  425. Tobias has joined
  426. ralphm has left
  427. stpeter has left