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 50%!
  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 presente
  44. Kev MattJ: ?
  45. MattJ Present
  46. Kev 2) http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc10 Accept 1.25?
  47. MattJ +1
  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 +1
  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 jabber.com
  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 Sure
  99. linuxwolf well, maybe it's moved to a secondary spec
  100. linuxwolf gah
  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 wfm
  118. Kev Ok, great.
  119. Kev So Wednesdays at 1600Z as a recurring date?
  120. Tobias okay
  121. linuxwolf wfm
  122. Kev Lovely.
  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 Right.
  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 heh
  140. MattJ Thanks :)
  141. linuxwolf adios
  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