XMPP Council - 2011-02-24

  1. linuxwolf

    quick caffeine run, brb

  2. Kev

    You've got 16 minutes. Go go go.

  3. stpeter


  4. stpeter replies to Kev's message

  5. Kev


  6. Kev

    What was my message?

  7. Kev

    I've got another agenda item I'm adding now.

  8. linuxwolf

    oh noes

  9. stpeter

    your email message about agenda

  10. stpeter

    sorry, on a conference call at the moment, but multitasking as best as I can :)

  11. Kev

    Asking Council to review a version published 12 minutes in advance of the meeting seems excessive :p

  12. stpeter


  13. stpeter

    you mean 0047?

  14. Kev


  15. stpeter

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

  16. stpeter


  17. stpeter

    I think Council members can read one sentence in 10 minutes

  18. stpeter

    but hey XEP-0047 has been sitting around for almost a year, what's another week?

  19. Kev

    I've reviewed the change :p

  20. linuxwolf


  21. linuxwolf

    found a typo or two

  22. linuxwolf somewhat patiently waits for gavel

  23. Kev

    As Florian just posted this: http://florianjensen.com/wp-content/uploads/2009/05/meetings.jpg

  24. Fritzy


  25. stpeter


  26. Kev

    Both Ralph and Matt poked.

  27. stpeter


  28. stpeter


  29. MattJ

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

  30. stpeter


  31. linuxwolf

    heh…newb (-:

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

  33. linuxwolf made that mistake a few weeks ago

  34. Kev


  35. Kev

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

  36. ralphm


  37. MattJ


  38. linuxwolf

    or it's the Apocalypse

  39. Kev

    1) Roll call.

  40. Kev

    All here!

  41. linuxwolf

    either would be fine

  42. ralphm


  43. Kev

    2) Agenda bashing.

  44. Kev

    (Beyond the extensive on-list bashing)

  45. ralphm

    I'm gone in 15 min.

  46. stpeter


  47. stpeter

    no bashing here

  48. Fritzy

    plenty on list. :)

  49. Kev

    A shame this'll be the longest Council for a while :)

  50. Kev

    3) XEP-0047 1.3rc3. http://xmpp.org/extensions/diff/api/xep/0047/diff/1.2/vs/1.3rc3 Accept new version?

  51. MattJ


  52. linuxwolf

    found at least one typo, +1 otherwise

  53. linuxwolf

    "Upon receiving an error related to delivery of a or stanza, the sender"

  54. ralphm


  55. stpeter

    note that I added a sentence the other day but didn't check in the file -- it was discussed on list, however

  56. stpeter

    linuxwolf: noted

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

  58. Kev

    +1 though.

  59. Fritzy

    +1 myself, although maybe an example of a wait error would be nice.

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

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

  62. stpeter

    Kev: it was added at your behest, as I recall

  63. linuxwolf

    +1 also

  64. Fritzy

    +1, but what about messages from archives. Are we watching for delay?

  65. ralphm


  66. stpeter

    Fritzy: I think we have some text about that now, don't we?

  67. stpeter checks

  68. Kev

    Fritzy: It explicitly says not to send from archive.

  69. Fritzy

    No, I see that.

  70. Fritzy

    I meant, it doesn't specify how you know that (yes, I realize that is in another spec)

  71. stpeter


  72. Kev

    I don't think it needs to.

  73. Kev

    Does it?

  74. Kev

    Well, it's a simple tweak to say "As in e.g. ..."

  75. stpeter is off his conference call so can concentrate more fully now

  76. Kev

    stpeter: Are you happy to make the tweak?

  77. Fritzy

    right, I think it could be a simple reference

  78. linuxwolf

    well, it does mention XEP-0136...

  79. Kev

    linuxwolf: Ah, it does?

  80. Kev

    I reviewed it earlier, forgotten it all now.

  81. Kev

    In that case, I think we're set.

  82. 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."

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

  84. Kev

    I think we're set then.

  85. Kev


  86. Fritzy

    oh, why didn't I see that?!

  87. Fritzy


  88. linuxwolf

    not sure what more can be said

  89. Fritzy

    (must have been looking at the wrong version or something)

  90. 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)" :)

  91. Kev

    I don't see a MattJ: note.

  92. MattJ

    I'm +1

  93. Kev

    note? vote.

  94. Kev


  95. Fritzy

    still +1

  96. Kev

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

  97. Fritzy


  98. linuxwolf


  99. linuxwolf


  100. MattJ

    It struck me that *this* spec would have more interesting interaction with archiving :)

  101. Kev

    I'm usually +1 on Experimental stuff, and seeing what happens, but this feels so completely non-XMPPish, I'm -1.

  102. linuxwolf

    just because there's precedence, doesn't mean it's GOOD precedence

  103. MattJ

    Instant realtime replay of conversations!

  104. Kev

    I've actually implemented this before, for someone who needed it, using a far far simpler model.

  105. MattJ

    Kev, how exactly?

  106. MattJ

    (and... should we spec it?)

  107. linuxwolf

    Kev: ditto

  108. Fritzy


  109. MattJ

    This comes up every so often

  110. Kev

    MattJ: <fragment>I'm half-way through typ</fragment>

  111. 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?

  112. Kev

    ralphm: No, I think we want to discourage specs that don't seem right.

  113. Fritzy

    the use case is fine

  114. Kev

    I'm not -1 because I don't care about the feature.

  115. MattJ

    If we reject this then we need some clear feedback for the author on why

  116. Kev

    This is 11,600 words (excluding boilerplate) if my copy/paste/wc skills are ok.

  117. Kev

    MattJ: I'd like a thread on this on standards@

  118. Kev

    I'm happy to revote after seeing some community feedback.

  119. Kev

    I'll weight in on such a discussion (I'm happy to start it)

  120. stpeter

    +1 to a discussion thread on standards@

  121. ralphm


  122. linuxwolf

    I'll be sure to provide my $0.02USD

  123. Kev

    I think this is the requirement we currently have set for Council. You can -1, but must post to standards@ with a justification.

  124. stpeter finds two AOB items

  125. ralphm


  126. Fritzy

    Sure, I'll -1 and post

  127. MattJ

    Ok, then I'm +1 to the -1 if we discuss it

  128. Kev

    MattJ: You mean you're +0?

  129. Dave Cridland


  130. Kev

    Or you're -1?

  131. Dave Cridland


  132. Dave Cridland


  133. Dave Cridland


  134. Dave Cridland


  135. Dave Cridland


  136. Kev

    Dave Cridland: Stop.

  137. linuxwolf

    Kev: I was −0 (-:

  138. Dave Cridland

    ... much like it either. :-)

  139. Fritzy


  140. Kev

    linuxwolf: yes, I saw that. It'l ralphm's and MattJ's I missed :)

  141. MattJ

    Kev, put me as +0

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

  143. Kev

    stpeter: That's not AOB, that's last week's meeting :)

  144. ralphm

    I don't think it is a required to have everyone's +1,-1,0 for moving to experimental

  145. stpeter

    Kev: it's other business as far as this meeting is concerned :)

  146. Kev

    ralphm: do you have a stance on rtt before we move on?

  147. Kev

    No, you can fail to express an opinion, but I want to know if you have one.

  148. ralphm

    Kev: I agree with the list action

  149. Kev


  150. ralphm

    so that appears to be -1 then

  151. Kev


  152. 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?

  153. stpeter

    shouldn't it be up to Google folks to document Google extensions?

  154. linuxwolf

    that's what I was about to ask....

  155. Kev

    So, Dave poked me about this pre-Council, and I said it should be standards track.

  156. Fritzy

    Do they care to?

  157. stpeter

    (however, note that I wrote the documentation for linklocal...)

  158. stpeter

    (and that was an Apple protocol)

  159. Fritzy

    We'll make a new track called "Google"

  160. stpeter


  161. linuxwolf


  162. MattJ


  163. Kev

    I don't see that we gain sufficient interoperability to make this worth documenting but not ST.

  164. MattJ

    I think standards track is fine

  165. ralphm

    I think this was discussed with some Google people

  166. linuxwolf

    yeah, but if it's our standard, some things will need to change

  167. stpeter

    Jonas is on the author list

  168. ralphm

    stpeter: right

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

  170. ralphm

    so it's ours and theirs

  171. stpeter

    but yeah we'd at least change the namespace to urn:xmpp:*

  172. Kev

    I think we should ST it, and do whatever the community thinks is the right thing to do.

  173. Dave Cridland

    stpeter, But that makes it a different protocol.

  174. Kev

    As it does seem simple and useful.

  175. Fritzy

    Do we need this simplification when we have other solutions?

  176. stpeter

    indeed it does

  177. Dave Cridland

    stpeter, THe point of documenting it is to say "this exists", nothign more.

  178. stpeter

    I think we need to take this to the standards@ list

  179. Kev

    Fritzy: from my limited understanding, this is actually simple and useful.

  180. stpeter

    Dave Cridland: in that case, Informational is right

  181. Fritzy

    Dave Cridland: then it's informational

  182. Kev

    stpeter: No, because it's not a BCP.

  183. Dave Cridland

    stpeter, Informational is described as "typically" for BCP, so there is wiggle-room.

  184. Kev

    Thus the question about whether we should update the XEP-0001 descriptions.

  185. linuxwolf

    we've used informational for other "not-quite-standard" protocols in the past

  186. ralphm

    I would say it is historical, but hey

  187. Kev

    ralphm: Historical means it was written before the JSF existed :)

  188. linuxwolf

    I would be good with Informational, FWIW

  189. Dave Cridland

    I originally thought Historical, hence its designation.

  190. Dave Cridland

    But Informational suits me fine.

  191. stpeter

    those categories need to be clarified

  192. stpeter

    now that the XSF has been around for almost 10 years

  193. linuxwolf

    or reambiguated (-:

  194. MattJ

    Good point :)

  195. Kev

    If we do put this as Informational, I think we should also create an ST version, and obsolete this one.

  196. Fritzy


  197. MattJ

    FWIW Telepathy does or is planning to implement this

  198. linuxwolf

    how about we see what the list discussion is first

  199. MattJ

    I think

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

  201. Fritzy

    I think this requires some more thought

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

  203. stpeter

    I think informational documentation of protocols out there in the wild can be helpful

  204. ralphm

    so, what is the value of redoing it in a new namespace?

  205. Dave Cridland

    MattJ, Does implement as specified here.

  206. ralphm

    I don't think I want more/less features

  207. MattJ

    ralphm, that we can advance the protocol

  208. Kev

    ralphm: We wouldn't for Informational.

  209. Kev

    But for ST we need to.

  210. stpeter

    ralphm: aside from the fact that "google:" is not a legitimate identifier on any planet I know about?

  211. MattJ


  212. ralphm

    that seems bureaucratic

  213. Kev

    Good point, it's an illegal namespace :D

  214. ralphm

    stpeter's argument is sane

  215. stpeter

    I mean we dropped "jabber:" 8+ years ago?

  216. Kev


  217. MattJ

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

  218. stpeter

    it's an illegal namespace, why encourage those?

  219. Kev


  220. stpeter

    MattJ: legacy

  221. Kev

    Who is volunteering to start a list discussion?

  222. stpeter

    we were idiots back then, why encourage more idiocy?

  223. MattJ


  224. linuxwolf


  225. Kev

    Or are we not bothering and going ahead as Informational?

  226. ralphm

    stpeter: must namespaces be uris?

  227. MattJ

    I vote Informational

  228. MattJ

    and keep the existing namespace

  229. MattJ

    and then ST it if we want to make our own

  230. MattJ

    but that's for the list

  231. Kev

    I do want a discussion about whether this is the optimal approach.

  232. linuxwolf

    /agreed w/ MattJ

  233. 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. ]

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

  235. stpeter


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

  237. ralphm

    stpeter: thanks

  238. stpeter

    +1 to simplicity

  239. Kev

    So someone has to agree to start the list discussion to see what the best way of doing it is.

  240. Kev

    If this is sufficiently different, we should ST it.

  241. MattJ

    Dave Cridland, the list discussion would be on whether we want to make a standards track version of this

  242. Kev

    Or, rather, create an ST spec to obsolete the informational.

  243. stpeter

    MattJ: agreed

  244. Dave Cridland

    MattJ, I think that'll come naturally from submitting this one.

  245. ralphm

    I think it would be good to rename the namespace only for this reason

  246. Fritzy

    yeah, let's see what the community thinks

  247. Kev

    So who's starting the discussion

  248. linuxwolf


  249. Kev

    Someone volunteer, I volunteered for rtt :)

  250. stpeter

    Dave has been volunteered

  251. Fritzy


  252. Kev

    Dave Cridland: Happy?

  253. ralphm

    i.e. if google would have chosen a valid namespace name, I would excuse them from the namespace changing stuff we regularly do

  254. Fritzy

    Dave is fine with informational, remember?

  255. MattJ

    I'd volunteer except I know I'll not get around to it right now

  256. Kev

    Fritzy: Yes, I'm not happy with Informational without a discussion :)

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

  258. ralphm

    I'm +1 on accepting this on standards track in that case.

  259. Kev

    I have no objection to this going on ST.

  260. Fritzy

    sure, plus a little service discovery and away we go

  261. ralphm

    Dave Cridland: that's an assumption we should verify

  262. Dave Cridland

    ralphm, I can ask Jonas, of course.

  263. Kev

    We're 7 minutes away from meeting-tolerance.

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

  265. ralphm

    Dave Cridland: please do

  266. ralphm

    Kev: next?

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

  268. stpeter

    Kev: same here

  269. linuxwolf


  270. Fritzy


  271. Kev

    Dave Cridland: Are you willing to start the discussion?

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

  273. Fritzy

    namespace changes can happen during experimental on standards track

  274. Kev

    I'm happy to publish this Informational and obsoleted by an ST document.

  275. Fritzy


  276. linuxwolf

    Dave: sounds like you can kick off the list discussion… (-:

  277. Fritzy

    that way we could at least refer to the old version, I suppose

  278. Dave Cridland

    Righty, I'll do so - shall I formally submit this before or after?

  279. Kev

    Dave Cridland: Both at the same time would make me happiest.

  280. Fritzy

    It's all about you, isn't it?

  281. Fritzy


  282. Kev

    Fritzy: About me? Yes.

  283. ralphm

    I'm +1 on 0198

  284. ralphm

    gotta go

  285. Dave Cridland

    Kev, K. I shall submit now, then, and then kick off the discussion once it's announced.

  286. Kev

    Bye Ralph.

  287. stpeter

    is this extension already documented on google.com somewhere?

  288. Kev

    Dave Cridland: You have the ST version ready?

  289. stpeter needs to transfer the voting tally pages to WordPress

  290. Kev

    I was saying I didn't want the Informational submitted before the ST one.

  291. Dave Cridland

    stpeter, Erm. I can't actually recall - I know that Jonas wrote an email describing it to jdev@ at one point.

  292. MattJ

    Kev, why not?

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

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

  295. MattJ

    about what?

  296. Kev

    The right way of doing it.

  297. linuxwolf

    I think we should allow this informational one first, start the list discussion, and see where it goes

  298. MattJ

    Informationalising it isn't about the right way of doing it

  299. MattJ

    It's about how Google have it implemented *now*

  300. MattJ

    which can be used as the basis of an ST document if we decide we want one

  301. Kev

    I basically feel unhappy about us documenting this non-ST, given that it's basically one deployment.

  302. Dave Cridland

    MattJ, Right - at least three implementations of this exist now.

  303. MattJ

    Kev, one significant deployment

  304. Dave Cridland

    Kev, It's not one implementation. If it were...

  305. Kev

    MattJ: Yes.

  306. Kev

    Dave Cridland: Yes, and I think we should see if it's the right way before we encourage more implementations.

  307. Kev

    By claiming that this is a BCP.

  308. MattJ

    I don't see we should claim it as a BCP

  309. Kev

    MattJ: That's what Informational means.

  310. MattJ

    The current definition of "informational" is another matter

  311. linuxwolf

    fine, then let's redefine informational

  312. linuxwolf

    then publish

  313. MattJ

    We've already decided it's too limited

  314. Kev

    linuxwolf: I'm fine with that.

  315. Kev

    Although that's Board, rather than Council :)

  316. linuxwolf

    it used to have a broader definition anyway

  317. MattJ

    So fix XEP-0001, publish queue as informational, debate forming an ST doc from it

  318. stpeter

    Kev: right :)

  319. stpeter

    but documentation is good

  320. 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".)

  321. Kev

    So'd I.

  322. stpeter

    fine by me

  323. Kev

    Assuming we modify historical to mean "Implemented outside the standards track"

  324. linuxwolf

    I'm fine with Historical too

  325. Kev


  326. linuxwolf

    do we also want to clarify what the definition of "is" is (-:

  327. Dave Cridland

    But that means redefining Historical to encompass things developed outside the XSF but after it was instigated.

  328. stpeter

    "Documentation is like sex. When it's good, it's very good. When it's bad, it's better than nothing." -- Jeremie Miller

  329. stpeter

    ok my other call is starting

  330. Dave Cridland

    stpeter, Is that Jer's quote? I never knew it was him.

  331. Kev

    Ok, we've passed tolerance.

  332. linuxwolf

    oh, +1 on 198

  333. stpeter

    meeting city this morning!

  334. stpeter

    linuxwolf: noted

  335. stpeter

    and ralphm's vote on 198 is noted

  336. Kev

    I'm happy to vote on this next week as Historical, and someone should ask Board to modify -0001.

  337. Kev

    7) Date of next meeting

  338. Kev

    Next Wednesday?

  339. linuxwolf


  340. MattJ


  341. Kev

    Fritzy: ?

  342. Fritzy

    that's fine.

  343. Kev

    8) AOB?

  344. Fritzy


  345. stpeter

    I'll update the calendar for next Wed

  346. Kev


  347. Fritzy


  348. stpeter

    some folks need to vote on 198

  349. stpeter

    and the vcard inbox item

  350. Kev

    stpeter: We know.

  351. Fritzy

    yup, I'll do that on list today

  352. stpeter

    just a reminder :)

  353. Fritzy plays catchup.

  354. Kev

    Anything else?

  355. stpeter


  356. linuxwolf


  357. Kev


  358. Fritzy


  359. MattJ

    Just to confirm... my votes for 198 and vcard4 are in, yes? I got no reply

  360. Kev

    MattJ: I've not seen them on-list. If they're in the buffer, I'll see them when I do the minutes :)

  361. stpeter

    MattJ: didn't see those

  362. MattJ


  363. stpeter

    MattJ: scrolling up

  364. MattJ

    I'll try from my other account again

  365. Kev


  366. stpeter

    MattJ: probably just my fault

  367. MattJ

    erm, I sent to the list, sorry

  368. stpeter

    ah ok

  369. stpeter

    that works

  370. Kev bangs the gavel

  371. Kev

    Thanks all.

  372. stpeter


  373. Fritzy


  374. linuxwolf


  375. MattJ


  376. stpeter turns his attention to the IESG telechat

  377. MattJ

    Enjoy :)

  378. stpeter

    oh yeah

  379. linuxwolf preps for next meeting

  380. MattJ

    Just can't get enough telechats

  381. linuxwolf

    hi ho, hi by

  382. stpeter

    this is a fun one -- the meeting schedule for IETF 80

  383. MattJ

    Is that Prague?

  384. stpeter


  385. linuxwolf

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

  386. stpeter


  387. stpeter

    it's a beautiful city

  388. MattJ

    Kev, ok... I don't see my email in the archives... +1s anyway

  389. MattJ

    Kev, I also asked where vcard4 puts User Profile