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


  17. stpeter replies to Kev's message

  18. Kev


  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


  27. stpeter

    you mean 0047?

  28. Kev


  29. stpeter

    it was discussed on the list, and I assume that Council members are paying attention to the list :P

  30. stpeter


  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


  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


  39. stpeter


  40. Kev

    Both Ralph and Matt poked.

  41. stpeter


  42. MattJ has joined

  43. stpeter


  44. MattJ

    Heh, I was waiting in council@c.j.o :)

  45. stpeter


  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


  51. Kev

    And a full Council, the fates are smiling upon us.

  52. ralphm


  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


  59. Kev

    2) Agenda bashing.

  60. Kev

    (Beyond the extensive on-list bashing)

  61. ralphm

    I'm gone in 15 min.

  62. stpeter


  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


  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


  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


  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


  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


  103. Fritzy

    oh, why didn't I see that?!

  104. Fritzy


  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


  112. Fritzy

    still +1

  113. Kev

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

  114. Fritzy


  115. linuxwolf


  116. linuxwolf


  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


  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


  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


  148. Kev

    Or you're -1?

  149. Dave Cridland


  150. Dave Cridland


  151. Dave Cridland


  152. Dave Cridland


  153. Dave Cridland


  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


  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


  180. linuxwolf


  181. MattJ


  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


  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


  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


  237. MattJ

    Wait, so is jabber:iq:... :)

  238. stpeter

    it's an illegal namespace, why encourage those?

  239. Kev


  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


  246. linuxwolf


  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


  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


  271. Kev

    Someone volunteer, I volunteered for rtt :)

  272. stpeter

    Dave has been volunteered

  273. Fritzy


  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


  294. Fritzy


  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


  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


  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


  364. MattJ


  365. Kev

    Fritzy: ?

  366. Fritzy

    that's fine.

  367. Kev

    8) AOB?

  368. Fritzy


  369. stpeter

    I'll update the calendar for next Wed

  370. Kev


  371. Fritzy


  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


  380. linuxwolf


  381. Kev


  382. Fritzy


  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


  387. stpeter

    MattJ: scrolling up

  388. MattJ

    I'll try from my other account again

  389. Kev


  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


  397. Fritzy


  398. linuxwolf


  399. MattJ


  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


  409. linuxwolf

    Some say that's Kev's favorite city to visit

  410. stpeter


  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