XMPP Council - 2013-05-29

  1. stpeter

    greetings and salutations

  2. MattJ

    Hey :)

  3. m&m


  4. stpeter

    I seem to recall that Kev sent his regrets?

  5. MattJ

    He said he might be late

  6. MattJ


  7. m&m

    I think so, too

  8. stpeter

    ah ok

  9. m&m

    but I think we can get started, and he can catch up

  10. MattJ

    Now ralphm's here, +1

  11. ralphm


  12. m&m

    0) Roll call

  13. ralphm


  14. MattJ


  15. m&m

    I'm here

  16. m&m


  17. Tobias


  18. Tobias


  19. m&m

    1) XEP-0297: Move to draft?

  20. MattJ


  21. ralphm


  22. Tobias


  23. m&m

    There's a typo in the intro that I'm sure the XEP Editor will fix

  24. m&m

    "There are many situations is which" ...

  25. m&m

    Also, I think I agree with other sentiments that extensions MUST contain <forwarded/>, not merely SHOULD

  26. MattJ

    +1 (after consideration)

  27. m&m

    I'm −1 until the SHOULD is a MUST

  28. stpeter


  29. m&m

    unless a good argument for the SHOULD?

  30. m&m

    "unless there is a good argument for the SHOULD?"

  31. MattJ

    I can't think of oneright now

  32. ralphm


  33. m&m needs last message correct

  34. MattJ

    I can't think of one right now

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

  36. ralphm

    I'm not sure if that's an argument here, though

  37. m&m

    so far the embeddings of <forwarded/> provide important context

  38. ralphm

    arguably, the same holds for pubsub

  39. m&m


  40. ralphm

    but there you could think of some 'see my sibling' semantics

  41. ralphm

    I am just thinking aloud about this, while we can

  42. m&m


  43. Lance

    as a client dev, i strongly prefer the embedded version over sibling

  44. m&m

    me too

  45. ralphm

    in <iq/>s it would not work anyway, as it can only have one child (not counting error)

  46. MattJ

    Well the XEP "strongly prefers" it already

  47. MattJ

    Just there might be exceptions

  48. MattJ

    However none of us can think of one :)

  49. ralphm

    I'm totally ok with embedding

  50. MattJ

    and this SHOULD isn't even for implementations as much as future protocol developers

  51. m&m


  52. ralphm

    allright then

  53. ralphm

    so m&m, do we change it to MUST?

  54. m&m


  55. ralphm


  56. m&m

    any more pressing opinions?

  57. m&m

    ok, moving on

  58. m&m

    ProtoXEP Chat Markers: Accept as Experimental?

  59. m&m


  60. Kanchil

    m&m: http://xmpp.org/extensions/inbox/chat-markers.html: XEP-xxxx: Chat Markers

  61. Kev

    Sorry. I did warn I could be late

  62. m&m

    (that would be 2)

  63. stpeter

    hi Kev!

  64. m&m

    hello Kev

  65. Kev

    I was stuck in a meeting room without wifi to be able to join!

  66. m&m


  67. ralphm


  68. m&m


  69. Kev

    As embedding in 297, I think it should be embedded.

  70. ralphm

    But I like the discussion on how it should be activated.

  71. m&m

    Kev: should be, or must be?

  72. ralphm

    I'm not terribly fond on having another protocol with 'subscribe' as a verb

  73. m&m

    I don't object to the idea, but I'm not sure I like this approach

  74. m&m

    but I don't immediately object to the approach either

  75. MattJ


  76. m&m


  77. MattJ

    There's a lot I don't understand

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

  79. MattJ

    Do I have to subscribe to all the people I have a conversation with?

  80. m&m

    of course!

  81. Tobias

    haven't had time to read chat markers yet...will vote on list

  82. ralphm

    Kev: no. Focus!

  83. m&m

    and noted

  84. m&m

    I think the "subscribe" is global

  85. MattJ

    Global to...?

  86. m&m

    the server?

  87. Zash

    The world!

  88. m&m

    it's not immediately clear

  89. Lance

    MattJ: the way i read it, you basically just subscribe to your archive, which tracks last/read received for each jid

  90. m&m

    which is one of the objections I have

  91. ralphm

    the 'marker providing service'

  92. MattJ

    Then what if I communicate with someone on another server?

  93. ralphm

    in this spec, it is assumed to be your own server

  94. ralphm

    or, more specifically, your account

  95. MattJ

    So chat markers don't work over s2s?

  96. MattJ

    That's... quite a limitation

  97. Lance

    MattJ: the protoxep is very handwavy there. it'd need expanding, but it is doable

  98. MattJ

    Until I see how, I'm not sure I can be +1 to accepting a vague outline

  99. m&m

    I agree

  100. m&m

    with MattJ

  101. MattJ

    I can post to the list

  102. m&m


  103. ralphm

    well, MattJ, you have raised your concern

  104. ralphm

    that counts as a -1 just fine. Just send a message to standards@ to that effect and we'll reiterate

  105. m&m


  106. m&m

    3) ProtoXEP Data Forms - Color Field Type: Accept as Experimental?

  107. m&m


  108. Kanchil

    m&m: http://xmpp.org/extensions/inbox/color-parameter.html: XEP-xxxx: Data Forms - Color Field Type

  109. MattJ

    How widely is XEP-0122 implemented?

  110. m&m

    other than the abuse of prefixed XML that is not inline with XEP-0122, I've no objections

  111. jabberjocke

    we fix that

  112. m&m

    jabberjocke: thanks

  113. ralphm

    ok, in that case !-1

  114. MattJ

    I've no objections either

  115. m&m

    There are a few implementations out there … I had written a couple at one point (-:

  116. Tobias

    only RGB support? not HSV :)

  117. ralphm

    there we go

  118. MattJ


  119. m&m

    nor RGBA (-:

  120. m&m

    but I don't see that as a reason to object

  121. jabberjocke

    iterating is good :)

  122. MattJ


  123. m&m

    I can see that as blocking Draft, but that's a while off

  124. Tobias

    but other than that i'm +1

  125. m&m

    ok, so Peter Waher and/or "jabberjocke" to submit an update removing the prefixes, then we should be good to accept

  126. jabberjocke

    m&m:blocking draft? whats that?

  127. jabberjocke


  128. m&m

    see xep-0001

  129. jabberjocke


  130. ralphm

    I have an AOB

  131. m&m

    4) date of next meeting

  132. m&m

    ralphm: noted, and so do I

  133. m&m


  134. Tobias


  135. ralphm


  136. MattJ


  137. m&m

    5) Any other Business?

  138. ralphm


  139. MattJ

    Yes, but we don't know what it is yet

  140. ralphm

    I remember we talked about coloring XEPs more prominently

  141. ralphm

    according to their status

  142. MattJ


  143. m&m


  144. ralphm

    like with a side ribbon

  145. MattJ


  146. ralphm

    whatever happened with that?

  147. m&m

    no one did the work? (-:

  148. ralphm

    People still think we have a gazillion standards

  149. m&m

    I think it's a fine idea

  150. stpeter


  151. ralphm

    there was a prototype?

  152. stpeter

    I don't recall a prototype

  153. m&m

    I don't remember seeing one, but that doesn't mean it didn't happen

  154. ralphm

    oh, maybe I dreamt of one

  155. stpeter

    we could start an XMPP Area at the IETF and republish all the Draft/Final specs as RFCs...

  156. ralphm

    Do we know of anyone we can volunteer to work on this?

  157. m&m

    well, prototypes and POCs are welcome

  158. ralphm


  159. Kev_

    Please Lord No.

  160. m&m


  161. m&m

    I would rather hold judgement on that until they support Unicode, at a minimum

  162. Tobias

    stpeter, wouldn't that be like trolling the IETF

  163. jabberjocke

    uml diagrams in acsii text is a challenge

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

  165. stpeter

    anyway, enough of that :-)

  166. m&m

    so, my AOB is LC for Carbons

  167. Zash


  168. m&m

    It's dependent on −297, but I don't think that needs to hold up its LC

  169. m&m

    it already complies with the coming changes, AFAICT

  170. stpeter

    yes it would be good to finish that one off

  171. ralphm


  172. MattJ


  173. m&m


  174. Tobias


  175. m&m

    that leaves Kev, which will be on list

  176. m&m

    ok, we're seven minutes over, but we started a couple minutes late

  177. m&m

    unless there's anything else...

  178. MattJ

    Nothing from me

  179. ralphm


  180. m&m bangs gavel

  181. MattJ

    Thanks :)

  182. m&m

    minutes to be sent presently

  183. m&m

    after I get some coffee!

  184. Tobias

    thanks m&m

  185. m&m

    just to clarify, is everyone (but me) +1 to advance −297?

  186. MattJ

    I think so, yes

  187. MattJ

    I'm not fussed about the MUST

  188. m&m

    so it's just me (-: