XMPP Council - 2013-11-20

  1. stpeter has left
  2. tato has left
  3. Lance has joined
  4. tato has joined
  5. Lance has joined
  6. tato has left
  7. stpeter has joined
  8. stpeter has left
  9. stpeter has joined
  10. Tobias has left
  11. stpeter has left
  12. fippo kev: there needs to be a decision about the format first -- linuxwolf made me think (@ http://mail.jabber.org/pipermail/jingle/2013-November/002037.html ) that the hex-with-colons has some advantages over the raw-base64
  13. Lance and those advantages are?
  14. Lance all i can think of is simpler compatibility with sdp, but that's just a single application of this xep
  15. fippo not just sdp. that format is used by sdp because browsers and openssl use it
  16. fippo this might be a display issue, so it's a small decision
  17. bear has joined
  18. bear has left
  19. bear has joined
  20. Tobias has left
  21. Tobias has joined
  22. Lance has left
  23. Lance has joined
  24. bear has left
  25. Lance has joined
  26. Tobias has left
  27. Tobias has joined
  28. stpeter has joined
  29. stpeter has left
  30. stpeter has joined
  31. jabberjocke has joined
  32. Tobias has left
  33. jabberjocke has left
  34. jabberjocke has joined
  35. Tobias has joined
  36. jabberjocke has left
  37. Kev Is there a recommendation anywhere that iqs should return quickly?
  38. MattJ Yes, but it's rather open to interpretation
  39. MattJ It doesn't use the word "quickly"
  40. Kev Do you know where?
  41. MattJ Somewhere, I'm looking to ensure I didn't imagine this sentence
  42. MattJ I remember arguing with someone about it, so it exists somewhere I'm fairly sure
  43. Kev I'm having issues with how much of rayo is presence.
  44. Kev Or the two in the inbox, anyway.
  45. Kev Rayo itself using presence from epemeral JIDs to show them coming into play seems sensible enough.
  46. stpeter (I don't see anything in RFC 6120 about quick responses to IQ requests)
  47. fippo kev: i have too...
  48. fippo mostly because I think that presence shouldn't be used for actual data
  49. MattJ I'm unable to find the text that I'm thinking of :/
  50. fippo but that is for the core rayo spec
  51. MattJ Maybe I'm confusing iq with something else
  52. Kev I'm pondering if saying "send this fax" shouldn't respond once the fax is sent, rather than immediately returning, and then later sending a presence with the result, which seems really wrong.
  53. fippo jingle has some precedence for iq-should-return-quickly -- we don't wait for the user to accept before sending the result
  54. fippo brb
  55. Kev It feels like doing what I was suggesting isn't quite right. I was wondering if we have anything written anywhere to support the feeling.
  56. Kev Regardless, I think the faux-result doesn't belong in presence :)
  57. MattJ After skimming all the RFCs, I can only conclude I was mistake with my "Yes" to your original question
  58. MattJ *mistaken
  59. Kev Ta.
  60. Lance has joined
  61. Dave Cridland has joined
  62. MattJ How will we know when you're nodding if we have no video?
  63. Dave Cridland nods
  64. Zash has joined
  65. fippo kev: i'm thinking that rayo itself uses presence in alot of cases where i don't know if it really fits
  66. Kev That may be fair.
  67. Peter Waher has joined
  68. bear has joined
  69. fippo looking at 0327 i'm also wondering about the rationale of putting urn:xmpp:rayo:client:1 into the node with a caps element
  70. fippo in fact, the whole usage of node there...
  71. Lance yeah, that feels too much like an implementation hack
  72. Tobias just FYI: i might be leaving earlier later, will send any remaining votes before weekend
  73. Dave Cridland Tobias, You might be leaving "earlier later"?
  74. Tobias earlier than the council end, later on this day :)
  75. Kev 'tis time.
  76. Kev 1) Roll call.
  77. Lance here
  78. Tobias here
  79. fippo here
  80. Tobias MattJ, ping
  81. MattJ Here
  82. MattJ Laggy, but here
  83. Kev Excellent.
  84. Kev 2 - http://xmpp.org/extensions/inbox/rayo-cpa.html
  85. Kev Accept as Experimental?
  86. Kev I have a number of reservations about this, not least of which that it seems to be reimplementing pubsub.
  87. fippo kev: i have similar objections, but not against this spec but against rayo
  88. Kev But...I'm not sure that justifies rejecting it.
  89. Tobias don't we already have a DTMF xepß
  90. Lance I have reserverations about most of rayo, but i'm +1 for experimental for this since rayo is too
  91. Lance for cpa itself, the main issue i have is it getting its namespaces consistent
  92. fippo i'm +1 -- there are some nits i posted to standards@, but I'm sure ben langfied will fix them
  93. Kev Tobias: 181?
  94. stpeter right, XEP-0181
  95. Tobias yes
  96. Kev I don't think this is competing with 181.
  97. MattJ Hmm, I'd forgotten about that one
  98. fippo tobias: 0181 is inside a jingle session. rayo is about call control
  99. Tobias fippo, ahh...ok
  100. fippo so you might want notifications without being part of the session
  101. Tobias right
  102. Kev I did spend a while re-reading 327 to remind myself this afternoon. There's lots there that doesn't sit quite right.
  103. fippo FWIW, i've heard a lengthy rant about rayo vs csta-xml from our csta-guy
  104. MattJ I think Ben would be quite open to feedback
  105. Kev I think this is !-1 from Fippo, Lance, Kev.
  106. Kev Matt/Tobias?
  107. MattJ +1 to accpting
  108. Tobias i'm okay with accepting as experimental
  109. Kev Marvellous.
  110. Kev 3 - http://xmpp.org/extensions/inbox/rayo-fax.html Accept as experimental?
  111. Tobias haven't read that yet in detail
  112. Lance same reasoning as above, +1 experimental
  113. fippo found some broken links, ben promised to fix them so i'm +1 as well
  114. Lance my main question for the fax one is why splitting it into two namespaces?
  115. Kev I'm really not comfortable with using <presence/> in place of an <iq =result/>, but I think this falls under the whole 'too much presence in rayo' thing.
  116. Kev So I'm again OK with experimental.
  117. Kev Tobias: Is that a "will vote on list"?
  118. Kev MattJ?
  119. Tobias Kev, yes
  120. MattJ +1 to accepting
  121. Kev 4) Adding tables to 71. Not really a Council action, but I'd like go gauge opinion here.
  122. Tobias k...will read the rest of the log later..sry..g2g
  123. Kev Tobias: Bibi.
  124. Lance I'm ok wth adding tables to 71
  125. Kev I'm vaguely opposed to adding new elements to 71, in something that's Draft.
  126. MattJ and... what next? :)
  127. fippo is 0071 extensible in a way that support for tables can be disco'd?
  128. stpeter fippo: no
  129. Kev Well, sure it is, if we add the text on disco :)
  130. stpeter yeah
  131. Kev But I feel like this doesn't fit into the spirit of non-backwards compatible changes for Draft, and shoving it in a new XEP with discovery would be appropriate.
  132. stpeter but XEP-0071 wasn't designed that that in mind -- we could add it, though
  133. Dave Cridland Adding extensibility with no impact to the deployed base seems like something that could be added in Draft.
  134. stpeter I apologize for being weeks behind on email, but what exactly is the use case? is this really an IM thing?
  135. MattJ stpeter, I asked that on the list - the answer is yes
  136. Kev Dave Cridland: Yes, if we added discovery we could add it. But at that point, why bother?
  137. Kev stpeter: Yes, IM between non-humans.
  138. Dave Cridland Bot to user communications is the use case.
  139. MattJ Peter Waher wants to be able to send tables of information from a bot or automated service
  140. stpeter XHTML-IM was designed for IM use cases, not generalized communication
  141. Kev I'm not opposed to the use case
  142. stpeter by "IM" I meant human to human communication, sorry
  143. Kev I'd just rather it went into another XEP than we bolted stuff onto 71 at this stage, but if I'm the only one I won't bother objecting to it.
  144. MattJ You're not the only one
  145. Kev So could I get a feeling on whether people are OK with adding discovery+tables to 71?
  146. MattJ I think if we start adding to 71 now, it'll be a slippery slope :)
  147. Kev Just a non-vote +-1 would be good.
  148. MattJ a new XEP with discovery would make sense I think
  149. stpeter aside from needing to improve the security considerations (thanks to Waqas), I would like to push XEP-0071 to Final in 2014
  150. fippo -1 -- a new xep with discovery seems like the better way
  151. Lance yeah, +1 for a new xep. i'm sure there are other issues that need fixing once we dive into it
  152. Kev OK, good enough, thanks.
  153. Kev I'll post thoughts to the list, then.
  154. Kev 5) http://xmpp.org/extensions/inbox/eventlogging.html Experimental?
  155. stpeter Lance: "other issues" as in things we need to fix in XHTML-IM?
  156. Kev We've stilll got a couple of items, and we're running out of time, so I'd like to press on.
  157. stpeter (agreed Kev)
  158. Lance +1 experimental for event logging, going by peter's latest version on the list, not the inbox version
  159. Kev So, I'm not intrinsicly opossed to this one. There's a couple of warts that could do with tidying up, to my eye, but that's fine for Experimental.
  160. fippo i'll vote on list. this reminds me of things i've seen in the BEHAVE wg so i want to double-check there
  161. Kev Ah, I've only reviewed the inbox version.
  162. Kev So let's push this out for next meeting once it's in teh inbox.
  163. MattJ Agreed
  164. Kev 6) 134 (Design guidelines)
  165. Kev Fippo raised the issue of these being a little dated a while back.
  166. fippo oh yeah...
  167. fippo let me chech when that was...
  168. Kev stpeter: I'm going to guess you don't have time/energy to update this at the moment?
  169. stpeter heh, "Last Updated: 2004-12-09"
  170. Dave Cridland "SI File Transfer [28] is a good example of respecting the strengths and weaknesses of XMPP" - :-)
  171. Dave Cridland That dates it a little.
  172. MattJ oooooh :)
  173. stpeter it probably does need a bit of updating, yes :-)
  174. fippo http://mail.jabber.org/pipermail/standards/2012-September/026812.html
  175. Kev I'd like either stpeter or someone else with Peter's blessing to volunteer to update this, I think.
  176. Kev Or, if that's not on the table, consider whether it should stay at Active.
  177. Kev stpeter: Thoughts?
  178. fippo this sounds like something for brussels or another f2f meeting
  179. Dave Cridland It actually looks mostly reasonable to me. Dated, and could use a little love, but essentially still solid.
  180. stpeter after today I'll have more time to work on things, so I can add this to my .plan :P
  181. Kev There's certainly a bulk of sensible stuff in there.
  182. fippo dave: it lacks caps and pep
  183. Peter Waher Sorry I was not available when you discussed IM in 0071. I can response in AOB later
  184. Kev stpeter: OK, thanks.
  185. Kev 6) Date of next.
  186. Kev SBTSBC?
  187. MattJ +1
  188. fippo wfm
  189. Lance wfm
  190. stpeter I'll be offline next week, but have fun :-)
  191. Kev 7) AOB?
  192. Peter Waher two things
  193. Kev You have 30 seconds :)
  194. Lance there are the bosh changes that need to be reviewed
  195. Peter Waher First the tables in 0071
  196. stpeter XEP-0156 updates and BOSH patches
  197. MattJ I'm reviewing BOSH
  198. Kev Peter Waher: I'll reply on list for that.
  199. stpeter maybe the Council can consider those next week
  200. Peter Waher (y)
  201. Kev stpeter: Are the BOSH versions published?
  202. stpeter Kev: yes
  203. Kev Ah, I missed, sorry.
  204. Kev So yes, can vote next week.
  205. Peter Waher the original reason for tables in XHTML-IM was to be able to create chat bots for IoT, where tabular output is necessary
  206. stpeter http://xmpp.org/extensions/tmp/xep-0124-1.11.html and http://xmpp.org/extensions/tmp/xep-0206-1.4.html
  207. Kev Peter Waher: I think we can do this on-list.
  208. Peter Waher (y)
  209. Kev Or here, after the meeting, which I want to close now :)
  210. Peter Waher second item:
  211. Peter Waher Dynamic Forms
  212. Peter Waher I've made all updates you requested
  213. Peter Waher even though it took a while
  214. Kev OK, is that in the Inbox again?
  215. Peter Waher yes
  216. Kev Then I just suck. I'll add it to the agenda for next week, sorry.
  217. Peter Waher (y)
  218. Kev Is that everyone/everything?
  219. MattJ Seems so
  220. Peter Waher for my part, yes
  221. Kev Marvellous.
  222. Peter Waher thanks
  223. Kev Thanks all!
  224. Kev bangs the gavel.
  225. MattJ Thanks Kev :)
  226. Peter Waher If you could update the eventlog XEP in the inbox
  227. Peter Waher with the latest version with all corrections
  228. Lance stpeter: i dont know if there are any other issues in 71, but if we're going to make a 71bis, might as well inspect to see if there are any
  229. stpeter Lance: there are security issues of the kind that Waqas raised in Portland
  230. stpeter we need to add some strong wording to the security considerations
  231. Kev Peter Waher: So, the summary is just that I (and others) would rather see tables in a short extra spec with discovery than put into 71 at this late stage in its life. No opposition to the idea, I think.
  232. stpeter Peter Waher: and yes we need to get you up and running with git access, or figure out a better way to get things updated under source control
  233. Kev If the problem is just entry into Git, I don't mind getting mailed a format-patch and pushing it.
  234. fippo stpeter: actually, could you check whether i have git access? sending you patches is silly :-)
  235. Kev Bear's suggestion was that he'd set up a two-way sync with github once Board decide they're comfortable with that submission method.
  236. bear I'm testing that this weekend
  237. Peter Waher ok, excellent
  238. Peter Waher So, if you think a separate XEP is warranted for tabular data, I can write a proposal. Ok with everybody?
  239. Peter Waher Or do we need to discuss this on-list, before a decision is taken?
  240. stpeter I think a bit of discussion on the list would be good
  241. Dave Cridland Peter Waher, For purely tabular data, there is the forms stuff.
  242. Peter Waher But that wouldn't get displayed in the chat window
  243. Peter Waher I'll search for an example...
  244. Peter Waher Example 1: Tabular data using normal text and tab characters:
  245. Peter Waher http://twitpic.com/djmor4
  246. Peter Waher (reading a device)
  247. Peter Waher As tabular data (using Psi client)
  248. Peter Waher http://twitpic.com/djrq2a
  249. Peter Waher (and XHTML-IM containing tables)
  250. Lance has joined
  251. stpeter Peter Waher: ah, that's nice :-)
  252. MattJ Peter Waher, did Psi already allow that? or you added it?
  253. Peter Waher Psi allows it
  254. Peter Waher but only the most basic tables
  255. Peter Waher for instance, I could not use text-align style
  256. Peter Waher to align text within cells left/center/right for instance
  257. Peter Waher (which would be nice)
  258. stpeter heh, XEP-0071 says: Modularization of XHTML defines many additional modules, such as Table Modules, Form Modules, Object Modules, and Frame Modules. None of these modules is part of the XHTML-IM Integration Set. If support for such modules is desired, it MUST be defined in a separate and distinct integration set.
  259. Peter Waher Correct, but the table XHTML module is "very" complex
  260. stpeter yes
  261. stpeter thus my concern
  262. Peter Waher so, a limited subset would suffice
  263. stpeter although many of the XHTML modules are complex
  264. stpeter and we've subsetted most of them anyway
  265. Peter Waher yes, but also, there are many restrictions in XHTML-IM
  266. Peter Waher when it comes to attributes and especially styles
  267. Peter Waher which is OK under the circumstances
  268. Peter Waher exactly
  269. Peter Waher During the discussion on list I proposed a mimimalistic subset
  270. stpeter Peter Waher: great
  271. stpeter Peter Waher: I'm sorry that I haven't posted in that thread, but I shall soon
  272. Peter Waher (y)
  273. Peter Waher has left
  274. stpeter has left
  275. fippo http://xmpp.org/extensions/tmp/xep-0156-1.1.html <-- bosh updates include those, right?
  276. fippo (heh, since there is a link to the log in the minutes i don't even need to send an email)
  277. Lance heh
  278. Kev It's on my list.
  279. Kev Up to 8 items already.
  280. fippo oh, i can add another two :-)
  281. bear question - i'm chatting with one of the moz wg-presence folks and he is asking about a reference doc on presence propagation
  282. bear which XEP is that?
  283. Kev I don't understand the question.
  284. Lance that should be core 6120/1, right?
  285. fippo presence propagation?
  286. Kev If it's core presence handling, that's 6121
  287. bear yes, presence handling thanks
  288. Lance Kev: what items do you have so far?
  289. Kev Bosh, Bosh, 156, dynamic forms, event handling, plus the boilerplate.
  290. bear can presence be subscriptions be done by "group" ?
  291. Kev Presence subs are always 1:1
  292. Kev Most servers support shared roster groups of some sort, but that's an implementation detail.
  293. bear thanks
  294. Tobias has joined
  295. stpeter has joined
  296. stpeter yeah it would be good to standardize roster groups
  297. Lance in what way?
  298. fippo i think that MUC solves much more use cases than roster groups typically
  299. stpeter hmm
  300. stpeter yeah, now that I think about it I can't say that I care too much about shared roster groups :-)
  301. MattJ Users care about shared roster groups - a lot
  302. stpeter they do
  303. MattJ We also have a Prosody plugin to inject MUC bookmarks based on group
  304. MattJ which a number of people use
  305. stpeter we've never succeeded in defining a common solution here, though
  306. fippo mattj: do they care about presence or chatting with a group of people?
  307. MattJ Both
  308. MattJ I know of people with 4K users in a single group :)
  309. stpeter ouch
  310. fippo i recently had a case where a server crashes because 2000 people had subscribed to 1999 other peoples presence...
  311. MattJ Yeah, it found some bottlenecks in our code :)
  312. MattJ We managed to make Pidgin the bottleneck, which was where we drew the line
  313. fippo MUC has interesting scalability implications here ... i.e. you always send updates only to people that are in the muc
  314. MattJ People do use offline messages
  315. fippo which isn't terribly helpful if all people are in the same timezone and working 9-to-5
  316. MattJ The folk with large groups tend to use it as a way for employees to locate other employees
  317. fippo ah, non-anonymous muc then and smart clients
  318. Lance from yesterday's version of the wiki: https://wiki.mozilla.org/index.php?title=CloudServices/Presence&oldid=766337#Why_not_use_XMPP.3F
  319. Lance and wrong room tab, of course
  320. Tobias has left
  321. Tobias has joined
  322. Zash has left
  323. stpeter has left
  324. Tobias has left
  325. Tobias has joined
  326. Dave Cridland has left
  327. jabberjocke has joined