XMPP Council - 2012-01-18

  1. Kev

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

  2. linuxwolf

    yes, yes it was

  3. linuxwolf

    I should know, I did the same

  4. linuxwolf

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

  5. linuxwolf


  6. MattJ laughs at you all

  7. linuxwolf

    well, I'm halfway through now

  8. linuxwolf

    since my 2.5 hours started yesterday d-:

  9. Kev

    Taking phone calls can only help my progress :)

  10. Kev

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

  11. Kev

    So at this rate I should finish...

  12. Kev

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

  13. Tobias

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

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

  15. Kev

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

  16. linuxwolf

    this is the first I can recall

  17. MattJ

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

  18. Kev

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

  19. Kev


  20. Kev

    Tearing through now.

  21. stpeter

    we can always delay consideration again :)

  22. Kev

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

  23. Kev

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

  24. stpeter

    oh true

  25. linuxwolf


  26. Kev

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

  27. stpeter joins the IETF Tools Team call

  28. Kev

    Right, it's time.

  29. Kev

    I've poked Ralph.

  30. Kev

    1) Roll call

  31. Tobias

    so..i'm here

  32. Kev

    I'm here.

  33. linuxwolf


  34. Kev

    MattJ: ?

  35. MattJ


  36. Kev

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

  37. MattJ


  38. linuxwolf

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

  39. linuxwolf

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

  40. Tobias


  41. Tobias

    although some bugs

  42. linuxwolf

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

  43. Kev

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

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

  45. 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).

  46. Tobias


  47. Kev

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

  48. Kev

    No-one has thoughts on this?

  49. MattJ

    I don't mind it

  50. MattJ

    No client I know of breaks

  51. linuxwolf

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

  52. MattJ

    bitlbee displays as "unknown occupant" or something

  53. stpeter

    linuxwolf: typo fixed

  54. linuxwolf

    a lot appear to just ignore those presences

  55. stpeter

    Tobias: xmlns mismatch fixed

  56. Kev

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

  57. linuxwolf

    it was at one point

  58. linuxwolf

    I'm not sure if it still is

  59. linuxwolf


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

  61. MattJ

    I'm happy with it

  62. linuxwolf

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

  63. Tobias

    i have no problem with it either

  64. Kev

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

  65. 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@.

  66. 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 (-:

  67. Kev

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

  68. Kev

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

  69. linuxwolf

    you mean 1.25 (-:

  70. Kev

    I mean 1.25rc11, yes.

  71. linuxwolf

    hold on, I need to re-read

  72. linuxwolf

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

  73. linuxwolf

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

  74. Kev

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

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

  76. Kev

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

  77. Kev

    But anyway.

  78. MattJ

    I'd be happy with that too

  79. MattJ

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

  80. 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@

  81. Kev

    MattJ: In MUCs?

  82. MattJ

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

  83. MattJ

    but nothing has ever broken, so I do it anyway

  84. Kev

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

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

  86. Kev

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

  87. MattJ


  88. linuxwolf

    well, maybe it's moved to a secondary spec

  89. linuxwolf


  90. linuxwolf

    maybe it can be moved to a secondary spec

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

  92. linuxwolf is distracted by a DANE flamewar

  93. linuxwolf

    fair enough

  94. 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 :)

  95. Kev

    So moving ever so swiftly on.

  96. Kev

    3) Date of next meeting.

  97. Kev

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

  98. Kev

    (and stick to it)

  99. linuxwolf


  100. linuxwolf checks calendar

  101. Kev

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

  102. Kev

    linuxwolf: And sometimes bad for you?

  103. linuxwolf

    this slot is just fine for me

  104. Tobias

    nope..works fine

  105. linuxwolf

    it's 1700 that's problematic

  106. MattJ


  107. Kev

    Ok, great.

  108. Kev

    So Wednesdays at 1600Z as a recurring date?

  109. Tobias


  110. linuxwolf


  111. Kev


  112. Kev

    4) Any other business?

  113. stpeter

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

  114. stpeter

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

  115. Kev

    Yes please :)

  116. stpeter

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

  117. Kev


  118. Kev

    Well, we don't, really.

  119. Kev

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

  120. Tobias

    k..so that's it?

  121. stpeter

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

  122. Kev

    I don't see other business.

  123. Kev

    stpeter: Yes, we would :)

  124. Kev

    Ok, all done then.

  125. Tobias

    nice...see you guys later or so

  126. Kev

    Thanks all

  127. Kev bangs the gavel.

  128. linuxwolf


  129. MattJ

    Thanks :)

  130. linuxwolf


  131. stpeter continues monitoring the IETF Tools Team call

  132. linuxwolf contemplates grumbling at DNS 'experts'

  133. linuxwolf

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

  134. stpeter

    heh yeah