stpeterI might be a few minutes late for the meeting
stpeterbbiab
stpeterhas left
MattJhas joined
MattJSame here, I've been following a clock that was 5 minutes slow
MattJbrbs
stpeterhas joined
stpeterwanders back in
KevI'm following a clock that's right, and says we have one minute left :)
stpeter$ date -u
Mon Mar 15 19:00:10 UTC 2010
KevIndeed.
KevSo, we have Kev and an afk Matt.
KevLet's see if this improves.
stpeterRemko appears to be online
stpeterbut I don't see Ralph
KevYes, just came on this moment.
stpeterah ok
KevMUC topics not sticking on jabber.org is quite irritating.
stpeternice 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 ç :)
Kev(I had a redirect note in the topic for council, but of course that was lost, and Remko was sitting there.
stpeterKev: ah, indeed
stpeterKev: I did too :)
remkohas joined
remkothank you dave for using my name as an example :)
Kevstpeter: 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 ;)
stpeterremko: :)
KevSo, once Matt returns, I guess we should start.
Tobiashas joined
stpeterwonders if he has time to put some lunch together while waiting for Mr. Wild
Tobiasstpeter: yeah..quite funny the IETF discussion on document format :)
MattJHere
KevOk.
MattJIf I die from eating undercooked food then I want this council meeting mentioned on my death certificate
Kev1) Roll call.
remko:)
KevKev, Matt, Remko here, Ralph absent.
Kev2) Agenda bashing.
KevPeter noted onlist that he'd like another discussion of voting periods.
remkois there an implementation for these changes?
KevI have no idea.
stpeterit's on the way in ejabberd AFAIK
stpetermaybe even checked in
stpeterperhaps also in Gajim
remkosessionremove -> session-remove ?
stpeterwe can ask on the standards@ list if it's been implemented fully
KevI have this open here, but haven't gotten to the end of the diff yet, so I need to vote onlist.
stpeterit was a joint project between Gajim and ejabberd, in essence
remkoi have the tendency to ask for implementations if we change specs post-draft
MattJI went over the changes, but would be happier to give it another run-through and vote on-list
remkounless they're clarifying or bugfixing
stpeterfeedback welcome on the standards@ list
stpeterremko: in this case the changes were a result of implementation experience
KevOk, votes to follow onlist, then.
Kev4) XEP Notes.
Should we have some comments attached to XEPs and proto-XEPs by Council?
Cases in point: server ip check, Software information.
stpeteryep
KevThis was my question
remkostpeter: that's what i expected, it's good to have that information explicit
remkohaving the comments close to the XEPs doesn't sound like a bad idea. It would take some infrastructure, though, no?
MattJWhat kind of comments/notes are we talking about?
KevThere'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.
MattJHeh
stpeterlike an IESG note in an RFC, I suppose
Kevstpeter: as I understand it.
stpeterwell
KevWe 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.
KevThoughts.
remkois there a reason not to have them in the XEP?
stpeterI think that might be appropriate if a XEP is rejected by the Council after being proposed for advancement to Draft
MattJThat's what I was about to say
MattJFor Server IP Check for example, I think the actual text needs changing
remkonot that i have a problem with making them hidden
stpeterfor a 0.1 spec? I don't see a good reason for that
Kevremko: not that I can think of, but I was putting it out in case people thought there was.
MattJSo is there an example of something that we would attach that wouldn't go in the text of the XEP itself?
Kevstpeter: 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.
stpeterfor a Rejected spec, I think a Council note would be helpful
stpeterKev: I assume that the spec author could consult the meeting log :)
Tobiasbut then again rejected specs aren't published are they?
stpeterTobias: Rejected XEPs
stpeterTobias: not ProtoXEPs that are never accepted for publication
Kevstpeter: 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.
Tobiasstpeter: you mean a XEP being rejected?
Kevstpeter: I was proposing this for protoXEPs that aren't accepted, too.
KevJust some repository of comments, however that's done, so people don't have to trawl Council logs.
stpeterstill favors being liberal in publication and conservative in advancement
MattJOk, yes, I think this would be useful
Tobiasi see...quite some time since something has been rejected, that councils just have been too kind :D
stpeterTobias: or bad stuff simply gets deferred
stpeterbut if the Council wishes to take on more work by publishing official Council notes, go for it :)
Tobiasstpeter: or that, so it would only be rejected if the author of the bad XEP keeps sending in bad updates on it
Kevstpeter: I think it's a net reduction in effort, when faced with agenda items like:
Kev5) 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?
stpeterKev: sure
MattJHow about we just: 1) Make sure to clearly document thoughts, comments and objection reasons in the council minutes
stpeterand composing a note would force the Council to be more explicit about its reasons
MattJHave some metadata in XEPs to link up to minutes where the XEP was on the agenda
KevMattJ: that's still referenced by the wrong thing (date instead of xep)
MattJ2) ^
stpeternaturally the old Council might have no members in common with the new Council :)
KevMattJ: but if you'd like to come up with some cross-referencing system, go for it.
stpeterheh
KevI don't care how it's done as long as it's easy for the chair to update.
stpeterprobably easier to copy the notes from the minutes to the XEP and be done with it
KevI would have thought so.
KevSo,
Kev5) 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?
KevI have no memory of this at all.
MattJMe neither, so I reviewed it - and it looks fine
MattJThough I'm still partial to jabber:iq:version :)
niekiehas joined
stpeter(BTW this also ties in with my point about objection periods and clear objections to XEPs when a Council member votes -1....)
KevI'll have a read through and post to list if I remember anything I may have once complained about.
remkoi have some vague memory
Kevstpeter: Right, I'm all in favour of a -1 report.
darkrainI 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?
KevAlbeit where 'report' is pretty much a one-sentence in some cases.
Kevdarkrain: that's negligible though, I rather imagen.
Kev*imagine.
KevThat could well have been the complaint, though :)
stpeterthere's a longish thread starting here: http://mail.jabber.org/pipermail/standards/2009-January/020909.html
stpeterRemko wanted to know why we were not using data forms
darkrainhttp://logs.jabber.org/council@conference.jabber.org/2009-04-22.html, too
stpeters/not//
remkoright, that sounds more like me :)
remkothat was a void statement though
remko'because it's disco' was the answer
KevIn any case, can people do this and get back to the XEP Editor, please? :)
stpeternice summary at http://mail.jabber.org/pipermail/standards/2009-February/020972.html
stpeterThis 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.
stpeteras a result we removed these:
icon_available
icon_away
icon_chat
icon_dnd
icon_xa
stpeteretc.
stpeteranyway
stpeterI can post to the standards@ list :)
Kev2 minutes left on my meeting tolerance gauge :)
Kev6) 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?
MattJCouncil meeting 2009-01-21: 5) XEP-0232: Software Information
Last call for moving to Draft?
No objections.
stpeterMattJ: sure but then we had a second last call
stpeteretc.
KevI wasn't at all clear what you were asking here.
MattJOk
stpeterKev: we'd have a new XEP with a new namespace, or 193 with a changed namespace
stpeterdoes the Council have a preference?
stpeterI slightly favor a new XEP
MattJWhy so?
stpeterbecause 193 was input to the rfc3920bis process
stpeterand we might want to document that for the ages
stpetershrugs
stpetereither way is fine, really
MattJSame here :)
MattJSo I was curious why you wanted a new XEP
MattJIf we need to keep 193 around, new XEP is fine with me
KevI'm happy with a new XEP if that's what you'd like, *shrug*
MattJBack when I was starting Prosody I asked around as to whether people actually wanted multiple resource binding
MattJI ended up not implementing it, because I couldn't find anyone with valid use-cases that couldn't be solved otherwise
MattJImplementing it now would be tricky, and probably not worth the effort
MattJBut since it seems quite a few people do want this, I'm happy to not block it
stpeterMattJ: 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)
MattJ:)
MattJCunning
stpeterok moving on
stpeterI'll work with those who want to do this, if they really do
stpeterI think I referenced the wrong mailing list post :)
KevOr I misclicked
KevAnyway.
stpeterat 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.
KevHaving the review periods at a fortnight seems fine.
KevI disagree that -1 being a permanent block is wrong.
stpeterKev: yes, I already updated XEP-0001 with 14 days
MattJAh, hmm
KevI do agree with having to justify a -1
stpeterKev: I agree that -1 being a permanent block if fine, but not if you never say why you voted -1
stpeterright
MattJI've voted too many +1s this year, time for a change
stpeterto 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
KevSo 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.
stpeterright
stpeterthat's my proposal
stpeternow, perhaps it can't be fixed
stpeteror the authors never address the clearly stated concern
MattJstpeter, how does it work at the IETF?
stpeterso it goes to Experimental while the token lives with the authors -- if they never update the spec then it goes to Deferred eventually
stpeterMattJ: the IETF has an elaborate state chart :)
stpetere.g., "revised I-D needed"
MattJOk, forget I asked :)
stpeterif the revised I-D is never submitted, it expires after six months and *poof*
stpeterI just want clear reasons for -1 so that the authors know what they need to change
stpetere.g., I don't know what to change in XEP-0060 right now
stpeterso good fixes are being held up
MattJThis ties in nicely with the XEP notes :)
KevMattJ: indeed.
KevOk, so, enough on this?
stpeterbut I'll poke Ralph again :)
stpeterKev: yep, enough
Kev8 ) Peter would like feedback on filetransfer things.
KevPlease do on-list or on-XMPP :)
Kev9) Date of next meeting.
KevSame bat time, same bat channel?
MattJ+1
Kev10) AOB.
MattJNot from me
stpeterI won't be available next week, but the Council is free to meet without me :)
MattJThough I'm working on some notes about 198 which I'll post to standards@ soon
remkook
KevMattJ: excellent.
remkonone from me
stpeterKev: any progress on #5?
KevNo-one's shown any interest to me in filling the space.
waqashas joined
KevSo we may end up limping along with four.
stpetercould be
MattJThey've got another week :)
stpeterwe rarely need the tie-break anyway
stpeterperhaps I'll poke some folks in private :)
MattJThey'll all contact you on the last day, mark my words
stpeter:)
KevThere's only ever a tie-break involved with voting off Council members, in Council, of course.
KevAs everything we do is veto-based.
stpeternod
KevIn any case, I think we're done.
stpeterwho's writing the minutes this time?
MattJKev, you manage to slip that factoid into every meeting :)
stpeterMattJ: :)
Kevstpeter: I can do it, probably tomorrow morning.
KevMattJ: not every meeting, and it's not always me.
stpeterKev: ok thanks
KevThanks all
Kevbangs the gavel.
stpeterthis week is crazy for me
MattJKev, true, it used to be the other one
stpeteryay
stpeterupdates /council/events.xml
MattJstpeter, that's my job :)
MattJBut you keep doing it for me
stpeteroh is it?
MattJWhich is just as well, because I often forget
MattJe.g. I went to update it this morning
MattJSince you actually have a calendar tied into it, if you think you'll notice more when it needs updating, feel free
stpeterit's a task of less than one minute, so easy enough to do :)
stpeterneeds to get back to GTD
stpeteranyway
stpetergotta run
stpeterbbiab
MattJMy calendar is still telling me about 20 board meetings on the same date in January