XMPP Council - 2013-05-29

  1. Neustradamus has left
  2. Neustradamus has joined
  3. m&m has joined
  4. m&m has left
  5. Tobias has left
  6. bear has joined
  7. Kev has joined
  8. Tobias has joined
  9. bear has left
  10. Kev has left
  11. Kev has joined
  12. Tobias has joined
  13. Tobias has left
  14. Kev has left
  15. Tobias has left
  16. Tobias has joined
  17. bear has left
  18. m&m has joined
  19. Tobias has left
  20. Tobias has joined
  21. Lance has joined
  22. stpeter has joined
  23. stpeter greetings and salutations
  24. Zash has joined
  25. MattJ Hey :)
  26. m&m hola
  27. stpeter I seem to recall that Kev sent his regrets?
  28. MattJ He said he might be late
  29. MattJ iirc
  30. m&m I think so, too
  31. stpeter ah ok
  32. m&m but I think we can get started, and he can catch up
  33. ralphm has joined
  34. MattJ Now ralphm's here, +1
  35. ralphm aloha
  36. m&m 0) Roll call
  37. ralphm here
  38. MattJ Here
  39. m&m I'm here
  40. m&m Tobias?
  41. Tobias yup
  42. Tobias here
  43. m&m 1) XEP-0297: Move to draft?
  44. MattJ +1
  45. ralphm +1
  46. Tobias +1
  47. m&m There's a typo in the intro that I'm sure the XEP Editor will fix
  48. m&m "There are many situations is which" ...
  49. m&m Also, I think I agree with other sentiments that extensions MUST contain <forwarded/>, not merely SHOULD
  50. Florob has joined
  51. MattJ +1 (after consideration)
  52. m&m I'm −1 until the SHOULD is a MUST
  53. stpeter heh
  54. m&m unless a good argument for the SHOULD?
  55. m&m "unless there is a good argument for the SHOULD?"
  56. MattJ I can't think of oneright now
  57. ralphm well
  58. m&m needs last message correct
  59. MattJ I can't think of one right now
  60. ralphm I had suggestions about PubSub some time, where people asked why the payload of events were embedded. If they were not, the original message might be interpretable, (like with Atom), even if PubSub wasn't.
  61. ralphm I'm not sure if that's an argument here, though
  62. m&m so far the embeddings of <forwarded/> provide important context
  63. ralphm arguably, the same holds for pubsub
  64. m&m /nod
  65. ralphm but there you could think of some 'see my sibling' semantics
  66. ralphm I am just thinking aloud about this, while we can
  67. m&m heh
  68. Lance as a client dev, i strongly prefer the embedded version over sibling
  69. m&m me too
  70. ralphm in <iq/>s it would not work anyway, as it can only have one child (not counting error)
  71. MattJ Well the XEP "strongly prefers" it already
  72. MattJ Just there might be exceptions
  73. MattJ However none of us can think of one :)
  74. ralphm I'm totally ok with embedding
  75. MattJ and this SHOULD isn't even for implementations as much as future protocol developers
  76. m&m right
  77. ralphm allright then
  78. ralphm so m&m, do we change it to MUST?
  79. m&m yes
  80. ralphm wfm
  81. m&m any more pressing opinions?
  82. m&m ok, moving on
  83. m&m ProtoXEP Chat Markers: Accept as Experimental?
  84. m&m http://xmpp.org/extensions/inbox/chat-markers.html
  85. Kanchil m&m: http://xmpp.org/extensions/inbox/chat-markers.html: XEP-xxxx: Chat Markers
  86. Kev has joined
  87. Kev Sorry. I did warn I could be late
  88. m&m (that would be 2)
  89. stpeter hi Kev!
  90. m&m hello Kev
  91. Kev I was stuck in a meeting room without wifi to be able to join!
  92. m&m ugh
  93. ralphm !-1
  94. m&m heh
  95. Kev As embedding in 297, I think it should be embedded.
  96. ralphm But I like the discussion on how it should be activated.
  97. m&m Kev: should be, or must be?
  98. ralphm I'm not terribly fond on having another protocol with 'subscribe' as a verb
  99. m&m I don't object to the idea, but I'm not sure I like this approach
  100. m&m but I don't immediately object to the approach either
  101. MattJ Markers?
  102. m&m correct
  103. MattJ There's a lot I don't understand
  104. Kev I think I'm too on the run at the moment to contribute sensibly, so I'll vote on everything when I get the minutes, if I could, please.
  105. MattJ Do I have to subscribe to all the people I have a conversation with?
  106. m&m of course!
  107. Tobias haven't had time to read chat markers yet...will vote on list
  108. ralphm Kev: no. Focus!
  109. m&m and noted
  110. m&m I think the "subscribe" is global
  111. MattJ Global to...?
  112. m&m the server?
  113. Zash The world!
  114. m&m it's not immediately clear
  115. Lance MattJ: the way i read it, you basically just subscribe to your archive, which tracks last/read received for each jid
  116. m&m which is one of the objections I have
  117. ralphm the 'marker providing service'
  118. MattJ Then what if I communicate with someone on another server?
  119. xnyhps has joined
  120. ralphm in this spec, it is assumed to be your own server
  121. ralphm or, more specifically, your account
  122. MattJ So chat markers don't work over s2s?
  123. MattJ That's... quite a limitation
  124. Lance MattJ: the protoxep is very handwavy there. it'd need expanding, but it is doable
  125. MattJ Until I see how, I'm not sure I can be +1 to accepting a vague outline
  126. m&m I agree
  127. m&m with MattJ
  128. MattJ I can post to the list
  129. m&m noted
  130. ralphm well, MattJ, you have raised your concern
  131. ralphm that counts as a -1 just fine. Just send a message to standards@ to that effect and we'll reiterate
  132. m&m right
  133. m&m 3) ProtoXEP Data Forms - Color Field Type: Accept as Experimental?
  134. m&m http://xmpp.org/extensions/inbox/color-parameter.html
  135. Kanchil m&m: http://xmpp.org/extensions/inbox/color-parameter.html: XEP-xxxx: Data Forms - Color Field Type
  136. MattJ How widely is XEP-0122 implemented?
  137. m&m other than the abuse of prefixed XML that is not inline with XEP-0122, I've no objections
  138. jabberjocke we fix that
  139. m&m jabberjocke: thanks
  140. ralphm ok, in that case !-1
  141. MattJ I've no objections either
  142. m&m There are a few implementations out there … I had written a couple at one point (-:
  143. Tobias only RGB support? not HSV :)
  144. ralphm there we go
  145. MattJ :D
  146. m&m nor RGBA (-:
  147. m&m but I don't see that as a reason to object
  148. jabberjocke iterating is good :)
  149. MattJ +1
  150. m&m I can see that as blocking Draft, but that's a while off
  151. Tobias but other than that i'm +1
  152. m&m ok, so Peter Waher and/or "jabberjocke" to submit an update removing the prefixes, then we should be good to accept
  153. jabberjocke m&m:blocking draft? whats that?
  154. jabberjocke perfect
  155. m&m see xep-0001
  156. jabberjocke ok
  157. ralphm I have an AOB
  158. m&m 4) date of next meeting
  159. m&m ralphm: noted, and so do I
  160. m&m SBTSBC WFM
  161. Tobias wfm
  162. ralphm +1
  163. MattJ +1
  164. m&m 5) Any other Business?
  165. ralphm yes
  166. MattJ Yes, but we don't know what it is yet
  167. ralphm I remember we talked about coloring XEPs more prominently
  168. ralphm according to their status
  169. MattJ Mmm
  170. m&m hm
  171. ralphm like with a side ribbon
  172. MattJ Yes
  173. ralphm whatever happened with that?
  174. m&m no one did the work? (-:
  175. ralphm People still think we have a gazillion standards
  176. Kev_ has joined
  177. m&m I think it's a fine idea
  178. stpeter exactly
  179. ralphm there was a prototype?
  180. stpeter I don't recall a prototype
  181. m&m I don't remember seeing one, but that doesn't mean it didn't happen
  182. ralphm oh, maybe I dreamt of one
  183. stpeter we could start an XMPP Area at the IETF and republish all the Draft/Final specs as RFCs...
  184. ralphm Do we know of anyone we can volunteer to work on this?
  185. m&m well, prototypes and POCs are welcome
  186. ralphm ehm
  187. Kev_ Please Lord No.
  188. m&m heh
  189. m&m I would rather hold judgement on that until they support Unicode, at a minimum
  190. Tobias stpeter, wouldn't that be like trolling the IETF
  191. jabberjocke uml diagrams in acsii text is a challenge
  192. m&m I don't think the RFC XML format is any worse or better than the XEP XML format, but I think the lack of Unicode, image handling, and some other pieces is too much of a dealbreaker
  193. stpeter anyway, enough of that :-)
  194. m&m so, my AOB is LC for Carbons
  195. Zash Yay
  196. m&m It's dependent on −297, but I don't think that needs to hold up its LC
  197. m&m it already complies with the coming changes, AFAICT
  198. stpeter yes it would be good to finish that one off
  199. ralphm +1
  200. MattJ +1
  201. m&m Tobias?
  202. Tobias +1
  203. m&m that leaves Kev, which will be on list
  204. m&m ok, we're seven minutes over, but we started a couple minutes late
  205. m&m unless there's anything else...
  206. MattJ Nothing from me
  207. ralphm thanks!
  208. m&m bangs gavel
  209. MattJ Thanks :)
  210. m&m minutes to be sent presently
  211. m&m after I get some coffee!
  212. waqas has joined
  213. Tobias thanks m&m
  214. waqas has left
  215. Kev_ has left
  216. Kev has left
  217. Florob has left
  218. m&m just to clarify, is everyone (but me) +1 to advance −297?
  219. MattJ I think so, yes
  220. MattJ I'm not fussed about the MUST
  221. m&m so it's just me (-:
  222. Tobias has left
  223. xnyhps has left
  224. Tobias has joined
  225. Lance has joined
  226. Zash has joined
  227. Lance has joined
  228. Neustradamus has joined
  229. Lance has joined
  230. Lance has joined
  231. Lance has joined
  232. ralphm has left
  233. ralphm has joined
  234. ralphm has left
  235. ralphm has joined
  236. ralphm has left
  237. ralphm has joined
  238. Tobias has left
  239. Zash has left
  240. m&m has left
  241. stpeter has left