XMPP Council - 2012-01-18

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

yes, yes it was

I should know, I did the same

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

(-:

well, I'm halfway through now

since my 2.5 hours started yesterday d-:

Taking phone calls can only help my progress :)

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

So at this rate I should finish...

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

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

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

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

this is the first I can recall

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

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

50%!

Tearing through now.

we can always delay consideration again :)

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

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

oh true

(-:

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

Right, it's time.

I've poked Ralph.

1) Roll call

so..i'm here

I'm here.

presente

MattJ: ?

Present

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

+1

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

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

+1

although some bugs

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

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

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

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

.

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

No-one has thoughts on this?

I don't mind it

No client I know of breaks

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

bitlbee displays as "unknown occupant" or something

linuxwolf: typo fixed

a lot appear to just ignore those presences

Tobias: xmlns mismatch fixed

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

it was at one point

I'm not sure if it still is

jabber.com

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.

I'm happy with it

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

i have no problem with it either

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

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

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

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

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

you mean 1.25 (-:

I mean 1.25rc11, yes.

hold on, I need to re-read

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

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

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

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.

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

But anyway.

I'd be happy with that too

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

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@

MattJ: In MUCs?

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

but nothing has ever broken, so I do it anyway

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

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

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

Sure

well, maybe it's moved to a secondary spec

gah

maybe it can be moved to a secondary spec

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.

fair enough

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

So moving ever so swiftly on.

3) Date of next meeting.

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

(and stick to it)

(-:

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

linuxwolf: And sometimes bad for you?

this slot is just fine for me

nope..works fine

it's 1700 that's problematic

wfm

Ok, great.

So Wednesdays at 1600Z as a recurring date?

okay

wfm

Lovely.

4) Any other business?

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

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

Yes please :)

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

Right.

Well, we don't, really.

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

k..so that's it?

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

I don't see other business.

stpeter: Yes, we would :)

Ok, all done then.

nice...see you guys later or so

Thanks all

heh

Thanks :)

adios

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

heh yeah