XMPP Council - 2010-03-15

I might be a few minutes late for the meeting

bbiab

Same here, I've been following a clock that was 5 minutes slow

I'm following a clock that's right, and says we have one minute left :)

$ date -u Mon Mar 15 19:00:10 UTC 2010

Indeed.

So, we have Kev and an afk Matt.

Let's see if this improves.

Remko appears to be online

but I don't see Ralph

Yes, just came on this moment.

ah ok

MUC topics not sticking on jabber.org is quite irritating.

nice http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=50598&tid=1268679729 -- and the mailing list software didn't correctly render ç :)

(I had a redirect note in the topic for council, but of course that was lost, and Remko was sitting there.

Kev: ah, indeed

Kev: I did too :)

thank you dave for using my name as an example :)

stpeter: of course Ralph's been online on his new phone pretty much constantly since he got it, so presumably he's turned it off specifically to avoid Council ;)

remko: :)

So, once Matt returns, I guess we should start.

stpeter: yeah..quite funny the IETF discussion on document format :)

Here

Ok.

If I die from eating undercooked food then I want this council meeting mentioned on my death certificate

1) Roll call.

:)

Kev, Matt, Remko here, Ralph absent.

2) Agenda bashing.

Peter noted onlist that he'd like another discussion of voting periods.

I'll take that as 'none'

3) XEP-0136: Message Archiving version 1.2rc1 http://xmpp.org/extensions/tmp/xep-0136-1.2.html Diff: http://xmpp.org/extensions/diff/api/xep/0136/diff/1.1/vs/1.2rc1 Accept changes?

is there an implementation for these changes?

I have no idea.

it's on the way in ejabberd AFAIK

maybe even checked in

perhaps also in Gajim

sessionremove -> session-remove ?

we can ask on the standards@ list if it's been implemented fully

I have this open here, but haven't gotten to the end of the diff yet, so I need to vote onlist.

it was a joint project between Gajim and ejabberd, in essence

i have the tendency to ask for implementations if we change specs post-draft

I went over the changes, but would be happier to give it another run-through and vote on-list

unless they're clarifying or bugfixing

feedback welcome on the standards@ list

remko: in this case the changes were a result of implementation experience

Ok, votes to follow onlist, then.

4) XEP Notes. Should we have some comments attached to XEPs and proto-XEPs by Council? Cases in point: server ip check, Software information.

yep

This was my question

stpeter: that's what i expected, it's good to have that information explicit

having the comments close to the XEPs doesn't sound like a bad idea. It would take some infrastructure, though, no?

What kind of comments/notes are we talking about?

There've been a few times where I think it would have been helpful to have annotated XEPs or protoXEPs with a summary of Council's thoughts (particularly I think this is useful for protoXEPs when they come back around for votes after being rejected), although attaching notes to e.g. IP check saying "Look, it's not Stun, and it has no purpose, but we'll let it die on the vine rather than blocking it" would be useful.

Heh

like an IESG note in an RFC, I suppose

stpeter: as I understand it.

well

We don't even have to render it in the XEP if we don't want to, but I think having it in the source would be useful.

Thoughts.

is there a reason not to have them in the XEP?

I think that might be appropriate if a XEP is rejected by the Council after being proposed for advancement to Draft

That's what I was about to say

For Server IP Check for example, I think the actual text needs changing

not that i have a problem with making them hidden

for a 0.1 spec? I don't see a good reason for that

remko: not that I can think of, but I was putting it out in case people thought there was.

So is there an example of something that we would attach that wouldn't go in the text of the XEP itself?

stpeter: well, for example, Jingle nodes had lots of comments from Council, but got let through on the understanding that they get fixed before Draft. I think that's useful to record.

for a Rejected spec, I think a Council note would be helpful

Kev: I assume that the spec author could consult the meeting log :)

but then again rejected specs aren't published are they?

Tobias: Rejected XEPs

Tobias: not ProtoXEPs that are never accepted for publication

stpeter: yes, and when Council come to vote to Draft, they can look up the old room logs, and see what was discussed etc., but I think a note is much more convenient.

stpeter: you mean a XEP being rejected?

stpeter: I was proposing this for protoXEPs that aren't accepted, too.

Just some repository of comments, however that's done, so people don't have to trawl Council logs.

Ok, yes, I think this would be useful

i see...quite some time since something has been rejected, that councils just have been too kind :D

Tobias: or bad stuff simply gets deferred

but if the Council wishes to take on more work by publishing official Council notes, go for it :)

stpeter: or that, so it would only be rejected if the author of the bad XEP keeps sending in bad updates on it

stpeter: I think it's a net reduction in effort, when faced with agenda items like:

5) XEP-0232 / software information: this was recently deferred for inactivity but there is still interest in moving this forward. Can the Council review it again and more clearly specify its objections?

Kev: sure

How about we just: 1) Make sure to clearly document thoughts, comments and objection reasons in the council minutes

and composing a note would force the Council to be more explicit about its reasons

Have some metadata in XEPs to link up to minutes where the XEP was on the agenda

MattJ: that's still referenced by the wrong thing (date instead of xep)

2) ^

naturally the old Council might have no members in common with the new Council :)

MattJ: but if you'd like to come up with some cross-referencing system, go for it.

heh

I don't care how it's done as long as it's easy for the chair to update.

probably easier to copy the notes from the minutes to the XEP and be done with it

I would have thought so.

So,

5) XEP-0232 / software information: this was recently deferred for inactivity but there is still interest in moving this forward. Can the Council review it again and more clearly specify its objections?

I have no memory of this at all.

Me neither, so I reviewed it - and it looks fine

Though I'm still partial to jabber:iq:version :)

(BTW this also ties in with my point about objection periods and clear objections to XEPs when a Council member votes -1....)

I'll have a read through and post to list if I remember anything I may have once complained about.

i have some vague memory

stpeter: Right, I'm all in favour of a -1 report.

I might be mistaken, but wasn't some of the concern that it has an adverse impact on the number of entires in an entity caps cache?

Albeit where 'report' is pretty much a one-sentence in some cases.

darkrain: that's negligible though, I rather imagen.

*imagine.

That could well have been the complaint, though :)

there's a longish thread starting here: http://mail.jabber.org/pipermail/standards/2009-January/020909.html

Remko wanted to know why we were not using data forms

http://logs.jabber.org/council@conference.jabber.org/2009-04-22.html, too

s/not//

right, that sounds more like me :)

that was a void statement though

'because it's disco' was the answer

In any case, can people do this and get back to the XEP Editor, please? :)

nice summary at http://mail.jabber.org/pipermail/standards/2009-February/020972.html

This was my understanding of the opinions on this XEP: - Showing the different type of icons per-status is not something people want to implement in clients. The only use I see is for this might be transports, although I still think most clients even want this to be implemented on their side, for better consistency with the rest of the UI look. - Some clients implement the per-client logo avatar, so the logo sounds useful to at least these clients. - There's a security issue with OOB images that at least needs to be documented. Documenting is probably not enough, because I don't see a client displaying client icons asking the user for every type of client whether he wants to fetch the icon (which is different than with 'occasional' OOB requests that need to be acknowledged). There was a suggestion of mediated BoB solutions, which IMO makes sense because it removes the burden of security checks off the clients, and most clients will request the same images anyway.

as a result we removed these: icon_available icon_away icon_chat icon_dnd icon_xa

etc.

anyway

I can post to the standards@ list :)

2 minutes left on my meeting tolerance gauge :)

6) XEP-0193 / multiple resources per stream: several people have expressed an interest in bring back this feature (which was removed from rfc3920bis). Is the Council receptive to taking this on?

Council meeting 2009-01-21: 5) XEP-0232: Software Information Last call for moving to Draft? No objections.

MattJ: sure but then we had a second last call

etc.

I wasn't at all clear what you were asking here.

Ok

Kev: we'd have a new XEP with a new namespace, or 193 with a changed namespace

does the Council have a preference?

I slightly favor a new XEP

Why so?

because 193 was input to the rfc3920bis process

and we might want to document that for the ages

either way is fine, really

Same here :)

So I was curious why you wanted a new XEP

If we need to keep 193 around, new XEP is fine with me

I'm happy with a new XEP if that's what you'd like, *shrug*

Back when I was starting Prosody I asked around as to whether people actually wanted multiple resource binding

I ended up not implementing it, because I couldn't find anyone with valid use-cases that couldn't be solved otherwise

Implementing it now would be tricky, and probably not worth the effort

But since it seems quite a few people do want this, I'm happy to not block it

MattJ: it remains to be seen whether those who say they want it really do (to the extent of the small amount of work needed to write a new XEP)

:)

Cunning

ok moving on

I'll work with those who want to do this, if they really do

7) http://mail.jabber.org/pipermail/council/2010-March/002783.html

Review periods.

ah

hmm

I think I referenced the wrong mailing list post :)

Or I misclicked

Anyway.

at http://mail.jabber.org/pipermail/council/2010-March/002798.html I said: I think we might also need to specify objection periods. For example: you have two weeks to vote on a XEP and if you vote -1 you have two weeks after the end of the voting period to clearly specify your objections, preferably with suggested fixes. If you don't do that within two weeks, your vote is automatically changed to 0. Currently, a -1 vote can be used as a permanent block, and that's just wrong.

Having the review periods at a fortnight seems fine.

I disagree that -1 being a permanent block is wrong.

Kev: yes, I already updated XEP-0001 with 14 days

Ah, hmm

I do agree with having to justify a -1

Kev: I agree that -1 being a permanent block if fine, but not if you never say why you voted -1

right

I've voted too many +1s this year, time for a change

to vote -1 and say "I'll post to the list about it" and then never post to the list -- I have a problem with that

So you say -1, you've got a fortnight after the fortnight you've got for voting in which to summarise the -1, and hopefully give suggestions for how it can be fixed, if it can.

right

that's my proposal

now, perhaps it can't be fixed

or the authors never address the clearly stated concern

stpeter, how does it work at the IETF?

so it goes to Experimental while the token lives with the authors -- if they never update the spec then it goes to Deferred eventually

MattJ: the IETF has an elaborate state chart :)

e.g., "revised I-D needed"

Ok, forget I asked :)

if the revised I-D is never submitted, it expires after six months and *poof*

I just want clear reasons for -1 so that the authors know what they need to change

e.g., I don't know what to change in XEP-0060 right now

so good fixes are being held up

This ties in nicely with the XEP notes :)

MattJ: indeed.

Ok, so, enough on this?

but I'll poke Ralph again :)

Kev: yep, enough

8 ) Peter would like feedback on filetransfer things.

Please do on-list or on-XMPP :)

9) Date of next meeting.

Same bat time, same bat channel?

+1

10) AOB.

Not from me

I won't be available next week, but the Council is free to meet without me :)

Though I'm working on some notes about 198 which I'll post to standards@ soon

ok

MattJ: excellent.

none from me

Kev: any progress on #5?

No-one's shown any interest to me in filling the space.

So we may end up limping along with four.

could be

They've got another week :)

we rarely need the tie-break anyway

perhaps I'll poke some folks in private :)

They'll all contact you on the last day, mark my words

:)

There's only ever a tie-break involved with voting off Council members, in Council, of course.

As everything we do is veto-based.

nod

In any case, I think we're done.

who's writing the minutes this time?

Kev, you manage to slip that factoid into every meeting :)

MattJ: :)

stpeter: I can do it, probably tomorrow morning.

MattJ: not every meeting, and it's not always me.

Kev: ok thanks

Thanks all

this week is crazy for me

Kev, true, it used to be the other one

yay

stpeter, that's my job :)

But you keep doing it for me

oh is it?

Which is just as well, because I often forget

e.g. I went to update it this morning

Since you actually have a calendar tied into it, if you think you'll notice more when it needs updating, feel free

it's a task of less than one minute, so easy enough to do :)

anyway

gotta run

bbiab

My calendar is still telling me about 20 board meetings on the same date in January