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


  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


  59. Kev


  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


  78. Tobias


  79. fippo


  80. Tobias

    MattJ, ping

  81. MattJ


  82. MattJ

    Laggy, but here

  83. Kev


  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


  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


  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


  107. MattJ

    +1 to accpting

  108. Tobias

    i'm okay with accepting as experimental

  109. Kev


  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


  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


  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


  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


  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


  187. MattJ


  188. fippo


  189. Lance


  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


  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


  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


  216. Kev

    Then I just suck. I'll add it to the agenda for next week, sorry.

  217. Peter Waher


  218. Kev

    Is that everyone/everything?

  219. MattJ

    Seems so

  220. Peter Waher

    for my part, yes

  221. Kev


  222. Peter Waher


  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


  246. Peter Waher

    (reading a device)

  247. Peter Waher

    As tabular data (using Psi client)

  248. Peter Waher


  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


  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


  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


  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


  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


  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


  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


  308. MattJ

    I know of people with 4K users in a single group :)

  309. stpeter


  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