XMPP Council - 2013-11-20


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

  2. Lance

    and those advantages are?

  3. Lance

    all i can think of is simpler compatibility with sdp, but that's just a single application of this xep

  4. fippo

    not just sdp. that format is used by sdp because browsers and openssl use it

  5. fippo

    this might be a display issue, so it's a small decision

  6. Kev

    Is there a recommendation anywhere that iqs should return quickly?

  7. MattJ

    Yes, but it's rather open to interpretation

  8. MattJ

    It doesn't use the word "quickly"

  9. Kev

    Do you know where?

  10. MattJ

    Somewhere, I'm looking to ensure I didn't imagine this sentence

  11. MattJ

    I remember arguing with someone about it, so it exists somewhere I'm fairly sure

  12. Kev

    I'm having issues with how much of rayo is presence.

  13. Kev

    Or the two in the inbox, anyway.

  14. Kev

    Rayo itself using presence from epemeral JIDs to show them coming into play seems sensible enough.

  15. stpeter

    (I don't see anything in RFC 6120 about quick responses to IQ requests)

  16. fippo

    kev: i have too...

  17. fippo

    mostly because I think that presence shouldn't be used for actual data

  18. MattJ

    I'm unable to find the text that I'm thinking of :/

  19. fippo

    but that is for the core rayo spec

  20. MattJ

    Maybe I'm confusing iq with something else

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

  22. fippo

    jingle has some precedence for iq-should-return-quickly -- we don't wait for the user to accept before sending the result

  23. fippo

    brb

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

  25. Kev

    Regardless, I think the faux-result doesn't belong in presence :)

  26. MattJ

    After skimming all the RFCs, I can only conclude I was mistake with my "Yes" to your original question

  27. MattJ

    *mistaken

  28. Kev

    Ta.

  29. MattJ

    How will we know when you're nodding if we have no video?

  30. Dave Cridland nods

  31. fippo

    kev: i'm thinking that rayo itself uses presence in alot of cases where i don't know if it really fits

  32. Kev

    That may be fair.

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

  34. fippo

    in fact, the whole usage of node there...

  35. Lance

    yeah, that feels too much like an implementation hack

  36. Tobias

    just FYI: i might be leaving earlier later, will send any remaining votes before weekend

  37. Dave Cridland

    Tobias, You might be leaving "earlier later"?

  38. Tobias

    earlier than the council end, later on this day :)

  39. Kev

    'tis time.

  40. Kev

    1) Roll call.

  41. Lance

    here

  42. Tobias

    here

  43. fippo

    here

  44. Tobias

    MattJ, ping

  45. MattJ

    Here

  46. MattJ

    Laggy, but here

  47. Kev

    Excellent.

  48. Kev

    2 - http://xmpp.org/extensions/inbox/rayo-cpa.html

  49. Kev

    Accept as Experimental?

  50. Kev

    I have a number of reservations about this, not least of which that it seems to be reimplementing pubsub.

  51. fippo

    kev: i have similar objections, but not against this spec but against rayo

  52. Kev

    But...I'm not sure that justifies rejecting it.

  53. Tobias

    don't we already have a DTMF xepß

  54. Lance

    I have reserverations about most of rayo, but i'm +1 for experimental for this since rayo is too

  55. Lance

    for cpa itself, the main issue i have is it getting its namespaces consistent

  56. fippo

    i'm +1 -- there are some nits i posted to standards@, but I'm sure ben langfied will fix them

  57. Kev

    Tobias: 181?

  58. stpeter

    right, XEP-0181

  59. Tobias

    yes

  60. Kev

    I don't think this is competing with 181.

  61. MattJ

    Hmm, I'd forgotten about that one

  62. fippo

    tobias: 0181 is inside a jingle session. rayo is about call control

  63. Tobias

    fippo, ahh...ok

  64. fippo

    so you might want notifications without being part of the session

  65. Tobias

    right

  66. Kev

    I did spend a while re-reading 327 to remind myself this afternoon. There's lots there that doesn't sit quite right.

  67. fippo

    FWIW, i've heard a lengthy rant about rayo vs csta-xml from our csta-guy

  68. MattJ

    I think Ben would be quite open to feedback

  69. Kev

    I think this is !-1 from Fippo, Lance, Kev.

  70. Kev

    Matt/Tobias?

  71. MattJ

    +1 to accpting

  72. Tobias

    i'm okay with accepting as experimental

  73. Kev

    Marvellous.

  74. Kev

    3 - http://xmpp.org/extensions/inbox/rayo-fax.html Accept as experimental?

  75. Tobias

    haven't read that yet in detail

  76. Lance

    same reasoning as above, +1 experimental

  77. fippo

    found some broken links, ben promised to fix them so i'm +1 as well

  78. Lance

    my main question for the fax one is why splitting it into two namespaces?

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

  80. Kev

    So I'm again OK with experimental.

  81. Kev

    Tobias: Is that a "will vote on list"?

  82. Kev

    MattJ?

  83. Tobias

    Kev, yes

  84. MattJ

    +1 to accepting

  85. Kev

    4) Adding tables to 71. Not really a Council action, but I'd like go gauge opinion here.

  86. Tobias

    k...will read the rest of the log later..sry..g2g

  87. Kev

    Tobias: Bibi.

  88. Lance

    I'm ok wth adding tables to 71

  89. Kev

    I'm vaguely opposed to adding new elements to 71, in something that's Draft.

  90. MattJ

    and... what next? :)

  91. fippo

    is 0071 extensible in a way that support for tables can be disco'd?

  92. stpeter

    fippo: no

  93. Kev

    Well, sure it is, if we add the text on disco :)

  94. stpeter

    yeah

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

  96. stpeter

    but XEP-0071 wasn't designed that that in mind -- we could add it, though

  97. Dave Cridland

    Adding extensibility with no impact to the deployed base seems like something that could be added in Draft.

  98. stpeter

    I apologize for being weeks behind on email, but what exactly is the use case? is this really an IM thing?

  99. MattJ

    stpeter, I asked that on the list - the answer is yes

  100. Kev

    Dave Cridland: Yes, if we added discovery we could add it. But at that point, why bother?

  101. Kev

    stpeter: Yes, IM between non-humans.

  102. Dave Cridland

    Bot to user communications is the use case.

  103. MattJ

    Peter Waher wants to be able to send tables of information from a bot or automated service

  104. stpeter

    XHTML-IM was designed for IM use cases, not generalized communication

  105. Kev

    I'm not opposed to the use case

  106. stpeter

    by "IM" I meant human to human communication, sorry

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

  108. MattJ

    You're not the only one

  109. Kev

    So could I get a feeling on whether people are OK with adding discovery+tables to 71?

  110. MattJ

    I think if we start adding to 71 now, it'll be a slippery slope :)

  111. Kev

    Just a non-vote +-1 would be good.

  112. MattJ

    a new XEP with discovery would make sense I think

  113. stpeter

    aside from needing to improve the security considerations (thanks to Waqas), I would like to push XEP-0071 to Final in 2014

  114. fippo

    -1 -- a new xep with discovery seems like the better way

  115. Lance

    yeah, +1 for a new xep. i'm sure there are other issues that need fixing once we dive into it

  116. Kev

    OK, good enough, thanks.

  117. Kev

    I'll post thoughts to the list, then.

  118. Kev

    5) http://xmpp.org/extensions/inbox/eventlogging.html Experimental?

  119. stpeter

    Lance: "other issues" as in things we need to fix in XHTML-IM?

  120. Kev

    We've stilll got a couple of items, and we're running out of time, so I'd like to press on.

  121. stpeter

    (agreed Kev)

  122. Lance

    +1 experimental for event logging, going by peter's latest version on the list, not the inbox version

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

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

  125. Kev

    Ah, I've only reviewed the inbox version.

  126. Kev

    So let's push this out for next meeting once it's in teh inbox.

  127. MattJ

    Agreed

  128. Kev

    6) 134 (Design guidelines)

  129. Kev

    Fippo raised the issue of these being a little dated a while back.

  130. fippo

    oh yeah...

  131. fippo

    let me chech when that was...

  132. Kev

    stpeter: I'm going to guess you don't have time/energy to update this at the moment?

  133. stpeter

    heh, "Last Updated: 2004-12-09"

  134. Dave Cridland

    "SI File Transfer [28] is a good example of respecting the strengths and weaknesses of XMPP" - :-)

  135. Dave Cridland

    That dates it a little.

  136. MattJ

    oooooh :)

  137. stpeter

    it probably does need a bit of updating, yes :-)

  138. fippo

    http://mail.jabber.org/pipermail/standards/2012-September/026812.html

  139. Kev

    I'd like either stpeter or someone else with Peter's blessing to volunteer to update this, I think.

  140. Kev

    Or, if that's not on the table, consider whether it should stay at Active.

  141. Kev

    stpeter: Thoughts?

  142. fippo

    this sounds like something for brussels or another f2f meeting

  143. Dave Cridland

    It actually looks mostly reasonable to me. Dated, and could use a little love, but essentially still solid.

  144. stpeter

    after today I'll have more time to work on things, so I can add this to my .plan :P

  145. Kev

    There's certainly a bulk of sensible stuff in there.

  146. fippo

    dave: it lacks caps and pep

  147. Peter Waher

    Sorry I was not available when you discussed IM in 0071. I can response in AOB later

  148. Kev

    stpeter: OK, thanks.

  149. Kev

    6) Date of next.

  150. Kev

    SBTSBC?

  151. MattJ

    +1

  152. fippo

    wfm

  153. Lance

    wfm

  154. stpeter

    I'll be offline next week, but have fun :-)

  155. Kev

    7) AOB?

  156. Peter Waher

    two things

  157. Kev

    You have 30 seconds :)

  158. Lance

    there are the bosh changes that need to be reviewed

  159. Peter Waher

    First the tables in 0071

  160. stpeter

    XEP-0156 updates and BOSH patches

  161. MattJ

    I'm reviewing BOSH

  162. Kev

    Peter Waher: I'll reply on list for that.

  163. stpeter

    maybe the Council can consider those next week

  164. Peter Waher

    (y)

  165. Kev

    stpeter: Are the BOSH versions published?

  166. stpeter

    Kev: yes

  167. Kev

    Ah, I missed, sorry.

  168. Kev

    So yes, can vote next week.

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

  170. stpeter

    http://xmpp.org/extensions/tmp/xep-0124-1.11.html and http://xmpp.org/extensions/tmp/xep-0206-1.4.html

  171. Kev

    Peter Waher: I think we can do this on-list.

  172. Peter Waher

    (y)

  173. Kev

    Or here, after the meeting, which I want to close now :)

  174. Peter Waher

    second item:

  175. Peter Waher

    Dynamic Forms

  176. Peter Waher

    I've made all updates you requested

  177. Peter Waher

    even though it took a while

  178. Kev

    OK, is that in the Inbox again?

  179. Peter Waher

    yes

  180. Kev

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

  181. Peter Waher

    (y)

  182. Kev

    Is that everyone/everything?

  183. MattJ

    Seems so

  184. Peter Waher

    for my part, yes

  185. Kev

    Marvellous.

  186. Peter Waher

    thanks

  187. Kev

    Thanks all!

  188. Kev bangs the gavel.

  189. MattJ

    Thanks Kev :)

  190. Peter Waher

    If you could update the eventlog XEP in the inbox

  191. Peter Waher

    with the latest version with all corrections

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

  193. stpeter

    Lance: there are security issues of the kind that Waqas raised in Portland

  194. stpeter

    we need to add some strong wording to the security considerations

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

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

  197. Kev

    If the problem is just entry into Git, I don't mind getting mailed a format-patch and pushing it.

  198. fippo

    stpeter: actually, could you check whether i have git access? sending you patches is silly :-)

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

  200. bear

    I'm testing that this weekend

  201. Peter Waher

    ok, excellent

  202. Peter Waher

    So, if you think a separate XEP is warranted for tabular data, I can write a proposal. Ok with everybody?

  203. Peter Waher

    Or do we need to discuss this on-list, before a decision is taken?

  204. stpeter

    I think a bit of discussion on the list would be good

  205. Dave Cridland

    Peter Waher, For purely tabular data, there is the forms stuff.

  206. Peter Waher

    But that wouldn't get displayed in the chat window

  207. Peter Waher

    I'll search for an example...

  208. Peter Waher

    Example 1: Tabular data using normal text and tab characters:

  209. Peter Waher

    http://twitpic.com/djmor4

  210. Peter Waher

    (reading a device)

  211. Peter Waher

    As tabular data (using Psi client)

  212. Peter Waher

    http://twitpic.com/djrq2a

  213. Peter Waher

    (and XHTML-IM containing tables)

  214. stpeter

    Peter Waher: ah, that's nice :-)

  215. MattJ

    Peter Waher, did Psi already allow that? or you added it?

  216. Peter Waher

    Psi allows it

  217. Peter Waher

    but only the most basic tables

  218. Peter Waher

    for instance, I could not use text-align style

  219. Peter Waher

    to align text within cells left/center/right for instance

  220. Peter Waher

    (which would be nice)

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

  222. Peter Waher

    Correct, but the table XHTML module is "very" complex

  223. stpeter

    yes

  224. stpeter

    thus my concern

  225. Peter Waher

    so, a limited subset would suffice

  226. stpeter

    although many of the XHTML modules are complex

  227. stpeter

    and we've subsetted most of them anyway

  228. Peter Waher

    yes, but also, there are many restrictions in XHTML-IM

  229. Peter Waher

    when it comes to attributes and especially styles

  230. Peter Waher

    which is OK under the circumstances

  231. Peter Waher

    exactly

  232. Peter Waher

    During the discussion on list I proposed a mimimalistic subset

  233. stpeter

    Peter Waher: great

  234. stpeter

    Peter Waher: I'm sorry that I haven't posted in that thread, but I shall soon

  235. Peter Waher

    (y)

  236. fippo

    http://xmpp.org/extensions/tmp/xep-0156-1.1.html <-- bosh updates include those, right?

  237. fippo

    (heh, since there is a link to the log in the minutes i don't even need to send an email)

  238. Lance

    heh

  239. Kev

    It's on my list.

  240. Kev

    Up to 8 items already.

  241. fippo

    oh, i can add another two :-)

  242. bear

    question - i'm chatting with one of the moz wg-presence folks and he is asking about a reference doc on presence propagation

  243. bear

    which XEP is that?

  244. Kev

    I don't understand the question.

  245. Lance

    that should be core 6120/1, right?

  246. fippo

    presence propagation?

  247. Kev

    If it's core presence handling, that's 6121

  248. bear

    yes, presence handling thanks

  249. Lance

    Kev: what items do you have so far?

  250. Kev

    Bosh, Bosh, 156, dynamic forms, event handling, plus the boilerplate.

  251. bear

    can presence be subscriptions be done by "group" ?

  252. Kev

    Presence subs are always 1:1

  253. Kev

    Most servers support shared roster groups of some sort, but that's an implementation detail.

  254. bear

    thanks

  255. stpeter

    yeah it would be good to standardize roster groups

  256. Lance

    in what way?

  257. fippo

    i think that MUC solves much more use cases than roster groups typically

  258. stpeter

    hmm

  259. stpeter

    yeah, now that I think about it I can't say that I care too much about shared roster groups :-)

  260. MattJ

    Users care about shared roster groups - a lot

  261. stpeter

    they do

  262. MattJ

    We also have a Prosody plugin to inject MUC bookmarks based on group

  263. MattJ

    which a number of people use

  264. stpeter

    we've never succeeded in defining a common solution here, though

  265. fippo

    mattj: do they care about presence or chatting with a group of people?

  266. MattJ

    Both

  267. MattJ

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

  268. stpeter

    ouch

  269. fippo

    i recently had a case where a server crashes because 2000 people had subscribed to 1999 other peoples presence...

  270. MattJ

    Yeah, it found some bottlenecks in our code :)

  271. MattJ

    We managed to make Pidgin the bottleneck, which was where we drew the line

  272. fippo

    MUC has interesting scalability implications here ... i.e. you always send updates only to people that are in the muc

  273. MattJ

    People do use offline messages

  274. fippo

    which isn't terribly helpful if all people are in the same timezone and working 9-to-5

  275. MattJ

    The folk with large groups tend to use it as a way for employees to locate other employees

  276. fippo

    ah, non-anonymous muc then and smart clients

  277. Lance

    from yesterday's version of the wiki: https://wiki.mozilla.org/index.php?title=CloudServices/Presence&oldid=766337#Why_not_use_XMPP.3F

  278. Lance

    and wrong room tab, of course