XMPP Council - 2019-02-06


  1. Kev

    Should be back in time for 4. Today's getting away from me, so sorry if I'm not.

  2. Ge0rG

    dwd: https://github.com/xsf/xeps/pull/739 was merged, so it's technically a pre-advancement thing and not something to vote on. However, it's an indication of what changed in the XEP since it was last read by Council, so it might be good background info

  3. Ge0rG

    https://github.com/xsf/xeps/pull/752 is actually a submarine to make 0045 better.

  4. Ge0rG

    I hope that I'll be available in time for the Meeting, because my client scheduled a meeting at "around" 15:30

  5. Ge0rG

    So please excuse me if I'm late, and feel free to put "my" Agenda items to the end of the list

  6. Ge0rG

    He's not here yet, so I *am* going to be late.

  7. jonas’

    :(

  8. Ge0rG

    Maybe he'll be so late that we can have Meeting before. But somehow I have doubts about that.

  9. Ge0rG

    If you don't read anything from me, it's either xmpp.org connectivity or I'm AFK-busy.

  10. jonas’

    good luck

  11. Kev

    Been for a jog. Dripping. Can't sit like this, might be 2mins late.

  12. ralphm

    TMI

  13. dwd

    1) Wrap Call [healthier]

  14. dwd

    Who's here?

  15. jonas’

    I am

  16. Link Mauve

    o/

  17. dwd

    Kev's in the shower and will be doing the meeting wearing only a towel. Keep a hold of that image.

  18. dwd

    And Ge0rG has been swallowed by a meeting, I think.

  19. jonas’

    thank you very much, dwd.

  20. dwd

    jonas’, I'd say it's my pleasure, but really, it's not.

  21. Kev

    I'm here.

  22. Kev

    Don't worry, I don't have a towel.

  23. jonas’

    that doesn’t improve anything, Ke.

  24. jonas’

    that doesn’t improve anything, Kev.

  25. ralphm

    I'm here for PR 744

  26. zinid here for XOR

  27. dwd fetches the mind-bleach.

  28. jonas’

    oookay, maybe let’s get on with the agenda.

  29. dwd

    2) Agenda bashing

  30. dwd

    Thanks to jonas’ I think we caught everything.

  31. dwd

    Though Ge0rG said #739 wasn't really Council and had been merged (good).

  32. dwd

    So moving on:

  33. dwd

    3) Items for voting:

  34. dwd

    a) #739: XEP-0410: pre-LC and LC feedback https://github.com/xsf/xeps/pull/739

  35. dwd

    (Merged as noted)

  36. Kev

    (To save time, I'm going to be on-list on pretty much everything, sorry)

  37. dwd

    b) #752: XEP-0410: add application-specific <not-an-occupant/> condition https://github.com/xsf/xeps/pull/752

  38. jonas’

    postpone until Ge0rG is maybe there, dwd?

  39. dwd

    I'm fine with doing things a bit out of order in case Ge0rG manages to make it, yes. So parking this.

  40. jonas’

    same for c) then

  41. dwd

    d) #745: XEP-0234: Use <hash-used/> to signify the hash function being used, instead of an (invalid) empty <hash/> https://github.com/xsf/xeps/pull/745

  42. Link Mauve

    So, for this one I have a big set of changes stacked in a branch somewhere.

  43. Link Mauve

    I’d like to avoid bumping the namespace before merging those.

  44. dwd

    Link Mauve, Meaning what?

  45. Link Mauve

    As in, what is the content of these changes?

  46. jonas’

    Link Mauve, to be honest, I’ve been waiting for your changes for over a year now

  47. Link Mauve

    Yeah, and I for more than that.

  48. dwd

    Link Mauve, Meaning you want us to delay this?

  49. Link Mauve

    The addition of <hash-used/> was already a breaking change without a namespace bump, so we can probably do so once more, and then bump once I’m ready for pushing mine.

  50. Link Mauve

    dwd, or that yes.

  51. jonas’

    I don’t have a strong opinion either way.

  52. jonas’

    the :2 version is "broken" anyways due to what Link Mauve said.

  53. Link Mauve

    :5*

  54. dwd

    I think this does need a namespace bump. And I'm not happy about delaying it for PRs we don't have, sorry.

  55. ralphm

    release early, release often?

  56. jonas’

    the ~:2 (that’s hashes, not ft)~ :5 version is "broken" anyways due to what Link Mauve said.

  57. jonas’

    dwd, NS-bumping Jingle-FT is meh though

  58. dwd

    jonas’, What do you mean?

  59. jonas’

    (NS-bumping *anything* is, but file transfer is particularly frustrating when it fails in non-obvious ways)

  60. jonas’

    Link Mauve, how realistic is it that you get your changes in order ’til next meeting?

  61. Link Mauve

    dwd, it’s used in quite a lot of places already, has many implementations, bumping the namespace temporarily sounds indeed meh.

  62. Link Mauve

    jonas’, I’ll put that as a high priority, so somewhat likely.

  63. dwd

    You may have a point, actually - the hash -> hash-used change means that an application expecting hash simply sees no hash at all.

  64. dwd

    Which is allowed by the spec. So I can live without the namespace change on that basis.

  65. dwd

    Anyway votes:

  66. dwd

    Kev, assuming on-list.

  67. jonas’

    I’m +1 on this without namespace change

  68. jonas’

    (-1 with namespace change)

  69. Kev

    Yes, on-list please.

  70. dwd

    I'm +1, I think.

  71. dwd

    Link Mauve, ?

  72. Link Mauve

    I’m +1 without namespace change.

  73. dwd

    OK.

  74. dwd

    e) Adopt Proposed XMPP Extension: XMPP Over RELOAD (XOR) Abstract: This specification defines an XMPP Usage of REsource LOcation And Discovery (RELOAD). The XMPP usage provides an ability for XMPP clients to discover other peers' location through the peer-to-peer overlay. Once a peer location is determined, the RELOAD AppAttach method is used to establish a direct connection between peers through which XMPP streams are exchanged. https://xmpp.org/extensions/inbox/xor.html

  75. jonas’

    I have no knowledge about RELOAD.

  76. Ge0rG .o/

  77. jonas’

    Ge0rG, wb

  78. dwd

    I'm +1 on this. (I don't know more about RELOAD than the abstract of the RFC says, but it seems believable)

  79. jonas’

    I’d also like to mention that the XEP contains stuff which definitely does not belong into standards track

  80. Link Mauve

    I skimmed through it, read what zinid said about this protocol a while ago on conversations@ and am +1 on the basis that it looks good and sounds like an interesting proposal.

  81. dwd

    Ge0rG, To save you skimming back, we've shuffled the order form the agenda to put the '410 stuff at the end.,

  82. jonas’

    specifically, in §8.2: > The root certificate of the overlay MUST be created by the XSF. All intermediate authority's certificates MUST be signed by this root certficate.

  83. jonas’

    I don’t think we can accept this without Board involvement.

  84. Link Mauve

    But I don’t know much about RELOAD itself.

  85. Ge0rG

    jonas’: not even as Experimental?

  86. jonas’

    Ge0rG, not even as experimental

  87. dwd

    jonas’, It's Experimental, in fairness, but yes, it might need splitting for that basis.

  88. zinid

    if only I knew in what I should split it

  89. jonas’

    ralphm, if you happen to be around, a quick suggestion on this?

  90. ralphm

    Yeah, I'm thinking

  91. jonas’

    zinid, anything where it says "the XSF has to" needs to be removed, I think

  92. zinid

    where is the pattern for writing proposals for Board?

  93. Ge0rG

    I think that a wire format for exchanging CSRs and CRTs between XMPP entities, based on the entity JIDs, would be a welcome addition and solve the *technical* issue.

  94. jonas’

    zinid, same format, but different track. it needs to be different documents.

  95. ralphm

    I think it is kind of weird to have the XSF as the only entity to set up something like this.

  96. dwd

    zinid, Could you note that it requires a single CA, and then create a distinct XEP you define an XSF-based CA?

  97. jonas’

    (i.e. you switch "Standards TRack" to "Procedural" or something and describe how the CA should operate)

  98. zinid

    jonas’, I can of course remove that from the protoxep, easily, but that doesn't solve the problem

  99. jonas’

    zinid, what dwd says is correct and sensible.

  100. Ge0rG

    why XSF-based at all? It can be completely external as long as somebody documents it as the trust root for RELOAD-XMPP

  101. dwd

    zinid, The problem is that it requires a single CA? Or simply signed certificates?

  102. zinid

    dwd, only signed

  103. zinid

    by trusted CA

  104. ralphm

    I.e. the greater XMPP network is not a thing that is, or should be, controlled by the XSF?

  105. dwd

    zinid, Right. So the practical problem is that nobody signs end-user EE certs for jids?

  106. zinid

    dwd, yes

  107. zinid

    also, "trusted" in the sense that the CA should not produce massive amount certificates for attackers

  108. zinid

    *of certificates

  109. zinid

    that's the only requirement

  110. dwd

    zinid, OK. On that basis, I think it'd be best to note that requirement, and then remove the XSF-CA part (and if you want, submit that as a different protoXEP for the Board to consider).

  111. zinid

    okay for me

  112. jonas’

    zinid, I understand that certificates are needed here. Could you replace 8.1 and 8.2 with something more generic, leaving the XSF out of that, and make a follow-up document where you describe what’s necessary, on a procedural level, to make this work securely?

  113. jonas’

    ah, yes that

  114. zinid

    jonas’, yes, I will

  115. jonas’

    excellent

  116. zinid

    so reject it, will be ready to the next meeting

  117. jonas’

    zinid, fine by me

  118. dwd

    zinid, Sounds good. In that case I'll -1 this on the expectation that a new submission will pass.

  119. jonas’

    I’m -1 on the basis that the presented ProtoXEP has Procedural content which needs to be acked by Board.

  120. zinid

    (probably you will have some time for RELOAD itself, it's very good RFC :) )

  121. Link Mauve

    Yup, -1 waiting for the next version. :)

  122. jonas’

    so that’s sorted

  123. ralphm

    jonas’: I don't agree this is a requirement for rejecting it as experimental.

  124. ralphm

    I do agree that Board should be involved if we need to setup a CA.

  125. dwd

    I'd rather the Board chose whetheror not to adopt an XSF-CA document.

  126. jonas’

    I agree with dwd.

  127. dwd

    f) #744: XEP-0001: Clarify proposing Deferred XEPs for advancement to Draft https://github.com/xsf/xeps/pull/744

  128. ralphm

    dwd: I agree with that of course

  129. Ge0rG

    I'm pretty sure the XSF doesn't want to participate in the CA ~racket~ business.

  130. Link Mauve

    dwd, +1, but IIRC we already agreed on this change a few weeks ago.

  131. ralphm

    dwd: I'm not sure if adopting it as experimental means we're going to do it, though.

  132. Link Mauve

    I’m fine with the wording of it.

  133. ralphm

    On 744, I understand that Kev had issues with it

  134. jonas’

    +1 on #744

  135. Kev

    Let me remind myself.

  136. ralphm

    Go ahead

  137. Ge0rG

    +1 on #744

  138. Kev

    Oh, yes, so this means that someone can automatically take authorship of a spec by proposing it.

  139. Ge0rG

    Oh. good point.

  140. dwd

    +0 on this. I think in practise it doesn't matter, but the authorship change is curious.

  141. jonas’

    oh, I totally missed that part of the sentence O_O

  142. Kev

    I think that's wrong, and asking for it to be advanced, and changing authorship, should be independent things.

  143. Ge0rG

    But how else do we want to handle it?

  144. jonas’

    I hate reading diffs

  145. jonas’

    I agree with Kev

  146. dwd

    Ge0rG, Anyone can ask for a Deferred doc to be advanced seems fine.

  147. Ge0rG

    Do we want to accept Proposal from anybody?

  148. Ge0rG

    dwd: even without an author?

  149. jonas’

    Ge0rG, no, we still vote on it

  150. jonas’

    Ge0rG, yes, if a XEP is ready for Draft, it doesn’t matter if the author is still around

  151. dwd

    Ge0rG, We do, under this PR. It's just that this PR *also* magics the proposer into a XEP Author.

  152. jonas’

    afterwards, the Council will be the gatekeeper for changes anyways

  153. Ge0rG

    I kind-of-like that you can't Propose without commiting to maintain it.

  154. jonas’

    yeah, I don’t like that authorship change, I think it’s unnecessary

  155. Kev

    dwd: And the way I read it, also bumping off the old Author.

  156. dwd

    I am strictly ambivalent to it.

  157. Kev

    Or, at least, it's not clear that it /doesn't/ mean that.

  158. ralphm

    Kev: my thinking was that accepting changing ownership would be up to the Editor

  159. Ge0rG

    -1 as it is +1 with <del>, thereby taking up the role of XEP author</del>

  160. dwd

    Kev, I don';t think we explicitly have to kill them.

  161. Kev

    ralphm: I don't think that's what this text says.

  162. jonas’

    -1 as it is +1 with <del>, thereby taking up the role of XEP author</del>

  163. ralphm

    I am not saying it changes the Author, it takes up the role for the purpose of moving it in the process as further described.

  164. jonas’

    if the Approving Body (AB) decides that a specification should have an active author to advance, they can still require that and make the proposer author, if needed.

  165. dwd

    ralphm, That's definitely not what it says.

  166. ralphm

    If that's not clear (or you think that's actually not different), that was at least my attempt.

  167. jonas’

    ralphm, oooh, I see the intent now

  168. jonas’

    maybe ", thereby taking up the role of the XEP author for the purpose of proposing"?

  169. Kev

    I think just removing ", thereby taking up the role of XEP author" is easiest.

  170. dwd

    Right, I think the objections are clear.

  171. Ge0rG

    ralphm: what responsibilities does an author have for the purpose of moving a XEP in the process?

  172. ralphm

    The problem is that you need an XEP Author to process LC feedback

  173. dwd

    Note that, as a point of order, we don't get a binding vote on this as Council since the Approving Body is Board.

  174. dwd

    ralphm, Oh, that is actually a good point.

  175. Kev

    ralphm: Sure, but Council can look at getting a new Author where needed.

  176. jonas’

    ralphm, indeed a good point

  177. Kev

    And Deferred and Abandoned are not equivalent.

  178. Ge0rG

    Council can also (theoretically) incorporate LC feedback.

  179. dwd

    Kev, Right, but ralphm's suggestion mean that if you propose a Deferred XEP, you are taking responsibility for it.

  180. jonas’

    ralphm, can you put some wording together which makes this clear? making the proposer responsible for processing (at least by making concrete proposals for) the LC feedback would be good, methinks

  181. Ge0rG

    But I think it makes sense to put that burden on the Proposer.

  182. ralphm

    dwd: but only if there's no active Author to collaborate with.

  183. jonas’

    this is, by default, limited to processing the LC feedback, in my mind.

  184. Kev

    dwd: Yes - but I think automatically making someone Author is the wrong thing.

  185. jonas’

    I think thath makes a lot of sense

  186. jonas’

    I think that line of thinking ("Proposer manages LC feedback if author(s) are unavailable") makes a lot of sense

  187. jonas’

    I think that line of thinking ("Proposer manages LC feedback (and only that if no other agreements with the AB exist about that) if author(s) are unavailable") makes a lot of sense

  188. ralphm

    And indeed, my intent was that in case of abandonment, somebody proposing to move further would be interested in taking up ownership.

  189. dwd

    Or simply that the Proposer may be required to take the role of Author during Last Call.

  190. ralphm

    If proposer is allowed to process LC feedback, why doesn't that make him an author of sorts?

  191. Kev

    I think we're at the stage of some new text being a good idea, and may as well move on.

  192. Ge0rG

    dwd: and after Last Call, until all feedback is incorporated

  193. Ge0rG

    We are also overdue with our time and underdue with our Agenda.

  194. dwd

    ralphm, Do you have enough feedback from us to clarify the text?

  195. peter

    This sounds a bit like the Document Shepherd role at the IETF.

  196. dwd

    Ge0rG, Indeed.

  197. dwd

    peter, That also.

  198. ralphm

    dwd: I don't know yet how to process the feedback into new text

  199. Kev

    ralphm: largely because I forsee that someone is going to go through every deferred XEP, propose it for advancement, and get their name at the top of it automatically because of it.

  200. ralphm

    peter: I'm not familiar with that concept

  201. jonas’

    maybe take the details to the list?

  202. dwd

    ralphm, OK - but I'm going to move on, because I think we're just getting bogged down in detail.

  203. dwd

    g) #746: XEP-0060: Add missing @publisher in pubsub schema https://github.com/xsf/xeps/pull/746

  204. ralphm

    Kev: but if somebody who has abandoned authorship isn't involved, but the document changes anyway, isn't that a problem, too?

  205. Link Mauve

    g) I’m obviously +1, as I am its author.

  206. dwd

    I'm +1 on '746, this looks satrightforward.

  207. peter

    ralphm: https://www.ietf.org/blog/iesg-statement-document-shepherds/

  208. jonas’

    +1

  209. dwd

    ralphm, peter - sorry, we've moved on.

  210. peter

    yep

  211. ralphm

    dwd: I'd still like to somehow discuss details with council

  212. peter

    that's why I prefaced with `ralpphm:` :P

  213. Ge0rG

    +1

  214. peter goes back to $dayjob

  215. ralphm

    peter: thanks!

  216. dwd

    h) #747: XEP-0084: Bump the maximum of @width and @height to 65535 https://github.com/xsf/xeps/pull/747

  217. Link Mauve

    +1 too, for the same reason.

  218. Ge0rG

    This is a schema change, technically it requires a namespace bump.

  219. jonas’

    +1, it doesn’t change any normative part, and is probably an oversight of <revision> <version>0.11</version> <date>2007-07-25</date> <initials>psa</initials> <remark><p>Removed image size requirements.</p></remark> </revision>

  220. Link Mauve

    Ge0rG, uh, why?

  221. dwd

    I'm going to have to be on-list for this one. I'm going to have to dig a little.

  222. dwd

    Mostly on the question of whether Ge0rG is right or not.

  223. Link Mauve

    Do we have any mention that schemas are normative that way?

  224. Ge0rG

    Link Mauve, jonas’: if you followed the old schema and implemented it as u8, you'll end up overflowing your data field

  225. Kev

    Schemas are non-normative in XEPs.

  226. dwd

    We have usually held within the XSF that schemas are non-normative.

  227. jonas’

    Ge0rG, if you parse XML strictly by schema without validating it, you’re doing it wrong

  228. Link Mauve

    Kev, that’s what I remember too.

  229. Link Mauve

    jonas’, and if you do validate it, as it is you will reject way too many otherwise valid images.

  230. Ge0rG

    I'm not saying I'm -1, just interpreting the consequences of the change.

  231. dwd

    Ge0rG, Are you -1 as-is, or not, then?

  232. jonas’

    (please don’t namespace-bump avatars...)

  233. Ge0rG

    dwd: +1 because I want to see the world burn

  234. dwd

    :-)

  235. jonas’

    🔥

  236. dwd

    Looping back to the beginning, then.

  237. Ge0rG

    Also Link Mauve owes me a no-namespace-bump XEP change then :D

  238. dwd

    b) #752: XEP-0410: add application-specific <not-an-occupant/> condition https://github.com/xsf/xeps/pull/752

  239. Ge0rG

    the background of #752 was a list discussion, of which I concluded that it would be great to have an application-specific <not-an-occupant/> or maybe <not-in-room/> condition in MUC

  240. jonas’

    +1 on this, or any other of the commonly-encountered RFC 6120 stanza error condition for accompanying not-an-occupant

  241. dwd

    Is there any reason why this isn't using the `@by` attribute of the error element?

  242. Ge0rG

    But I didn't want to PR MUC yet.

  243. Ge0rG

    But really I want this new condition added to 0045.

  244. jonas’

    dwd, that’s a good addition actually

  245. Ge0rG

    dwd: you mean the example?

  246. Link Mauve

    Is there any reason this isn’t part of 0045 instead?

  247. Ge0rG

    Link Mauve: namespace-bumping-MUC

  248. Zash

    The entire thing?!

  249. jonas’

    dwd, but having a distinct muc-specific <not-an-occupant/> in addition is a good thing

  250. Ge0rG

    Zash: all of it

  251. dwd

    Ge0rG, So do it a MUC extension that adds it under a different namespace?

  252. jonas’

    urn:xmpp:muc:1!

  253. Ge0rG

    dwd: why not have a feature for it on MUC and use the MUC namespace?

  254. dwd

    Ge0rG, <feature var="urn:xmpp:muc:errors:0"/><!-- sends application-specific errors for MUC -->

  255. Ge0rG

    Ah, and use that NS.

  256. dwd

    Ge0rG, Using another XEP's namespace doesn't really sit well with me.

  257. Link Mauve

    A feature sounds like the way forward.

  258. Ge0rG

    dwd, Link Mauve: the specific reason for having this in 0410 was because I wanted to have this discussion, but didn't want to further delay 0410

  259. dwd

    I agree this is useful (though also, @by needs more implementation and use), but it's useful and generic.

  260. Link Mauve

    +1

  261. Ge0rG

    if we add <not-an-occupant xmlns="urn:xmpp:muc:errors:0"/> into 0410, we are now defining MUC errors in a XEP that's actually doing something different.

  262. dwd

    So, I think overall this is a -1 from me, sorry. That said, I don't think this needs to mean '410 needs delaying.

  263. Ge0rG

    What about jonas’ writing a separate Application Specific Errors for MUC XEP?

  264. jonas’

    why me

  265. Ge0rG

    jonas’: you brought that mess upon me.

  266. jonas’

    dammit

  267. Ge0rG

    I add a @by into 0410, and we publish it.

  268. jonas’

    I don’t have a weekend this week, so I can’t promise anything

  269. Ge0rG

    is anybody against having @by in 0410?

  270. jonas’

    @by is a good thing here

  271. dwd

    Ge0rG, jonas’ - votes?

  272. jonas’

    I’m +0

  273. Ge0rG

    and I'm -1 on #752, despite being the author

  274. jonas’

    ha

  275. Ge0rG

    because it needs its own XEP.

  276. Link Mauve

    ^^

  277. dwd

    Awesome.

  278. Ge0rG

    Thank you for the discussion, everyone.

  279. dwd

    Great when people reject their own stuff. :-)

  280. dwd

    c) Advance XEP-0410 to Draft https://xmpp.org/extensions/xep-0410.html

  281. Ge0rG

    The main part of the PR was this: > Please have a Council discussion.

  282. Ge0rG

    +1 to advance 0410 (with a @by added into the error)

  283. dwd

    Same for me - +1 (with @by)

  284. jonas’

    +1 to advance 410, with @by added

  285. Link Mauve

    Same here, +1.

  286. Ge0rG

    jonas’: shall I make a PR or will you do it with your Editor Hat on?

  287. jonas’

    Ge0rG, please make a PR

  288. dwd

    OK. I think we're done with items for voting.

  289. jonas’

    Ge0rG, I like to have more eyes (even if it’s just four) on it before merging stuff

  290. dwd

    4) Outstanding Votes

  291. dwd

    If anyone has anything, please do so on list given the overrun.

  292. dwd

    5) Next Meeting

  293. dwd

    Same time next week?

  294. jonas’

    +1w is ok for me

  295. Link Mauve

    Same.

  296. dwd

    6) AOB

  297. dwd

    (Please no)

  298. jonas’

    Thanks to Tedd Sterr for doing the minutes all the time and the vote summaries.

  299. Ge0rG

    +1 to that

  300. dwd

    Yes, that is amazingly helpful.

  301. jonas’

    tremendously helpful in both of my roles here

  302. Ge0rG

    I have a proto-proto-XEP about Simple Encryption for XMPP in the works, but I don't dare Ask Council.

  303. dwd

    It'd be great if they joined as a member, though that'd involve a real name.

  304. Kev

    Indeed, yay to minutes etc.

  305. dwd

    Assuming no other business...

  306. dwd

    7) Ite, Meeting Est

  307. Kev

    I have a non-AOB AOB.

  308. Kev

    Please let's keep to 30mins.

  309. dwd

    Kev, I generally agree. But we had 7 items to vote on, and I infinitely prefer voting in-meeting to voting on-list where possible.

  310. jonas’

    dwd, we could’ve moved the remaining items to +1w

  311. Kev

    Quite.

  312. jonas’

    I don’t want to cut down on in-meeting discussions, I think those are valuable

  313. dwd

    Sure, but I think the first meeting after Summit is always going to be busy - lots of energy, plus a missed meeting the week before.

  314. Ge0rG

    jonas’: https://github.com/xsf/xeps/pull/754

  315. dwd

    So, you know, sorry-not-sorry. :-)

  316. Kev

    I think the likely outcome is the opposite of the desired one if it becomes a habit.

  317. Kev

    Which is all votes going to onlist.

  318. Ge0rG

    Kev: all votes or just the ones cast after the first 30 minutes? ;-)

  319. Kev

    Once upon a time Council meetings were a mess, usually ran over, stuff was invariably onlist.

  320. Kev

    We eventually sorted that out and got down to sensible 30 minute meetings, with most stuff happening during them.

  321. Kev

    I'm keen not to go back.

  322. Kev

    And I'd rather punt items to the following week than have people sitting appearing to be in the meetings but actually not because they're doing something else once the meeting overruns.

  323. Ge0rG

    I'm really sorry for being late.

  324. Kev

    Stuff happens.

  325. Kev

    I was late too.

  326. Kev

    I don't think either were what caused the running over.

  327. ralphm waves

  328. pep.

    > dwd> It'd be great if they joined as a member, though that'd involve a real name. Would it? There's no reaction on the LC for 345. I am the only one to have replied to it?