XMPP Council - 2012-01-18

  1. Neustradamus has left

  2. Neustradamus has joined

  3. Tobias has left

  4. linuxwolf has joined

  5. Kev has joined

  6. Tobias has joined

  7. MattJ has joined

  8. Kev

    I only set aside 2 1/2 hours for reviewing MUC changes. At my current rate of progress, this was a bad move.

  9. linuxwolf

    yes, yes it was

  10. linuxwolf

    I should know, I did the same

  11. linuxwolf

    at least I don't have wikipedia and cheezburgers to distract me today

  12. linuxwolf


  13. MattJ laughs at you all

  14. linuxwolf

    well, I'm halfway through now

  15. linuxwolf

    since my 2.5 hours started yesterday d-:

  16. Kev

    Taking phone calls can only help my progress :)

  17. Kev

    I reckon I'm at least 15% through now.

  18. Kev

    So at this rate I should finish...

  19. Kev

    no, that's wrong. I shouldn't.

  20. Tobias

    yeah..we should set a limit on the size of a diff between two versions ^^

  21. Kev

    I've already decided there's bits in here I don't think should be, so maybe I should just -1 and forget about reading the rest :D

  22. Tobias has joined

  23. Kev

    Oooh, extending our use of 2119 in XEPs? I don't think I've noticed us use SHALL instead of MUST before.

  24. linuxwolf

    this is the first I can recall

  25. MattJ

    I'm not sure it's the first, unless I'm thinking of the RFCs

  26. Kev

    22 minutes to go, and I'm about 40% through. I'm sure it's about to get easier...

  27. stpeter has joined

  28. Kev


  29. Kev

    Tearing through now.

  30. stpeter

    we can always delay consideration again :)

  31. Kev

    Well, we've got a fortnight to vote on list anyway.

  32. Kev

    Just looks like I'll need to take advantage of it.

  33. stpeter

    oh true

  34. linuxwolf


  35. Kev

    (I'd forgotten it was 1600 and not 1700 today, in truth, which knocked my plan out a little)

  36. stpeter joins the IETF Tools Team call

  37. Kev

    Right, it's time.

  38. Tobias has joined

  39. Kev

    I've poked Ralph.

  40. Kev

    1) Roll call

  41. Tobias

    so..i'm here

  42. Kev

    I'm here.

  43. linuxwolf


  44. Kev

    MattJ: ?

  45. MattJ


  46. Kev

    2) http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc10 Accept 1.25?

  47. MattJ


  48. linuxwolf

    I found a typo in one of the examples, and I'm not sure *admin* is used consistently

  49. linuxwolf

    typo: <item affiliation='outcast'>           jid='lordscroop@shakespeare.lit'>

  50. Tobias


  51. Tobias

    although some bugs

  52. linuxwolf

    should be: <item affiliation='outcast'           jid='lordscroop@shakespeare.lit'>

  53. Kev

    I have a significant gripe with 1.25, so far, in the use of occupants that don't send presence.

  54. Tobias

    Reply XML NS doesn't match the one of the request. http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc10#added-diff-155 Limit history by characters. Why not by number of messages? http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc10#added-diff-422

  55. Kev

    I know this is a feature that we want, but I'm not sure the problem is well-understood enough to put it in right now. Particularly, it seems to suggest you could have members that are sending messages but not being shown as occupants through presence, and this seems like something that could break clients (and *possibly* servers, although that's less clear).

  56. Tobias


  57. Kev

    (I'm seeing if anyone responds to my comment)

  58. Kev

    No-one has thoughts on this?

  59. MattJ

    I don't mind it

  60. Hirotaka Sato has joined

  61. MattJ

    No client I know of breaks

  62. linuxwolf

    I know of at least one MUC implementation that is doing that today, and have not seen catastrophic consequences

  63. MattJ

    bitlbee displays as "unknown occupant" or something

  64. stpeter

    linuxwolf: typo fixed

  65. linuxwolf

    a lot appear to just ignore those presences

  66. stpeter

    Tobias: xmlns mismatch fixed

  67. Kev

    linuxwolf: Is this in an Internetish environment? (i.e. is this being exposed to a large selection of clients)

  68. linuxwolf

    it was at one point

  69. linuxwolf

    I'm not sure if it still is

  70. linuxwolf


  71. Kev

    If we have sufficient confidence that nothing's going to break with such a (seemingly, to me anyway) major change, I won't grumble too much.

  72. MattJ

    I'm happy with it

  73. linuxwolf

    I vaguely remember a version of OpenFire doing this, too … not sure it still does

  74. Tobias

    i have no problem with it either

  75. Kev

    I have another gripe about redefining 'room JID', especially given that we then continue to use the old definition.

  76. Kev

    But I think the no-presence thing was my only material complaint about the first half of the document. I'll finish reviewing the second half and post my comments to standards@.

  77. linuxwolf

    to be fair, I'm not sure I like the unavailable presence thing, either … but I'm not sure I don't like it (-:

  78. Kev

    I'd like to -1 this right now, but I anticipate the required changes to be relatively minor before pushing 1.26.

  79. Kev

    linuxwolf: By the 'unavailable presence thing', do you mean what I mentioned above, or something else?

  80. linuxwolf

    you mean 1.25 (-:

  81. Kev

    I mean 1.25rc11, yes.

  82. linuxwolf

    hold on, I need to re-read

  83. linuxwolf

    you might need to ignore that bit from me (-:

  84. linuxwolf

    no, I meant the message without available presence … sometimes I intermingle unavailable with no avaiable (-:

  85. Kev

    Ok, so that's the same thing I mentioned, then.

  86. Kev

    I'd be much much happier if we said something like "You can have rooms where visitors don't broadcast presence", because that avoids ever receiving a message from someone that you don't receive presence from.

  87. Kev

    (And I think this resolves all the use cases I've heard for this, but I could be wrong)

  88. Kev

    But anyway.

  89. MattJ

    I'd be happy with that too

  90. MattJ

    I've used the <message>-with-no-<presence> thing a lot

  91. Kev

    Do we need to discuss -45 any further here? I think everyone's +1 except me, who's -1 and will post a more complete review to standards@

  92. Kev

    MattJ: In MUCs?

  93. MattJ

    but I've always been aware it's somewhat abusing the spec

  94. MattJ

    but nothing has ever broken, so I do it anyway

  95. Kev

    Although I note that it's ok to send in messages from someone who's not an occupant, so maybe it's irrelevant.

  96. MattJ

    so I'm not against it entering the XEP, but I'm happy either way - I can see some valid use-cases for it in general

  97. Kev

    Ok, I withdraw that particular objection. But I'm still -1 pending some minor points, or being told they're wrong.

  98. MattJ


  99. linuxwolf

    well, maybe it's moved to a secondary spec

  100. linuxwolf


  101. linuxwolf

    maybe it can be moved to a secondary spec

  102. Kev

    linuxwolf: The problem is that moving to a secondary spec doesn't work, because it's the clients that *don't* support it that receive the unexpected messages.

  103. linuxwolf is distracted by a DANE flamewar

  104. linuxwolf

    fair enough

  105. Kev

    But it's true that the spec hasn't prohibited messages from people who truly aren't occupants, so it's immaterial - clients that don't cope were already buggy :)

  106. Kev

    So moving ever so swiftly on.

  107. Kev

    3) Date of next meeting.

  108. Kev

    We should try and find a time that works for everyone.

  109. Kev

    (and stick to it)

  110. linuxwolf


  111. linuxwolf checks calendar

  112. Kev

    Tobias: This slot is bad for you, usually, isn't it?

  113. Kev

    linuxwolf: And sometimes bad for you?

  114. linuxwolf

    this slot is just fine for me

  115. Tobias

    nope..works fine

  116. linuxwolf

    it's 1700 that's problematic

  117. MattJ


  118. Kev

    Ok, great.

  119. Kev

    So Wednesdays at 1600Z as a recurring date?

  120. Tobias


  121. linuxwolf


  122. Kev


  123. Kev

    4) Any other business?

  124. stpeter

    Kev: I look forward to your more extensive comments on 45

  125. stpeter

    shall I create a calendar entry for a meeting next week?

  126. Kev

    Yes please :)

  127. stpeter

    (and naturally we also need input from Ralph on 45)

  128. Kev


  129. Kev

    Well, we don't, really.

  130. Kev

    I mean - we do next time it comes to vote, but if anyone -1s, everyone else is irrelevant :)

  131. Tobias

    k..so that's it?

  132. stpeter

    Kev: (and naturally we would also love input from Ralph on 45)

  133. Kev

    I don't see other business.

  134. Kev

    stpeter: Yes, we would :)

  135. Kev

    Ok, all done then.

  136. Tobias

    nice...see you guys later or so

  137. Kev

    Thanks all

  138. Kev bangs the gavel.

  139. linuxwolf


  140. MattJ

    Thanks :)

  141. linuxwolf


  142. stpeter continues monitoring the IETF Tools Team call

  143. linuxwolf contemplates grumbling at DNS 'experts'

  144. linuxwolf

    sometimes I wonder if these people realize that DNS is not pure theory (-:

  145. stpeter

    heh yeah

  146. Zash has joined

  147. Zash has left

  148. Zash has joined

  149. Kev has left

  150. Kev has joined

  151. Kev has left

  152. Kev has joined

  153. MattJ has left

  154. Zash has left

  155. Tobias has joined

  156. Neustradamus has joined

  157. Tobias has left

  158. Tobias has joined

  159. Neustradamus has joined

  160. Kev has left

  161. stpeter has left

  162. stpeter has joined

  163. Tobias has left

  164. linuxwolf has left