Peter WaherI wonder what is missing for eventlogging to be approved as experimental and get a number?
MattJwfm
KevPeter Waher: That's done, isn't it?
MattJsorry, my ethernet cable fell out
KevAh, no.
Peter Waherwell, it hasn't been published
KevNeeds Fippo and Matt to not object.
stpeterKev: I think we were waiting for Council members to vote
KevThere's another week for them to do so.
fippokev: no objections
fippo(didn't I say that before?)
Kevfippo: Not in response to the minutes, at least.
KevJust MattJ, then.
Kev5) AOB?
Zashhas joined
stpeterI mentioned another vote on XEP-0152
fippoany new votes on colibri?
MattJSorry, didn't know that was waiting on me - though I know BOSH is
MattJI'll get to it
stpeterthe previous Council did not complete its voting, and I made changes to address Council feedback
Kevstpeter: I think the procedure, given xep1, is for another if Council doesn't finish voting by the end of term.
fippostpeter: is 0152 referenced by cusax?
KevAlthough I'm happy to skip that if everyone else is.
stpeterfippo: yes
stpeterKev: yes, another vote for sure
MattJI'm happy with 152
Kevfippo: No, that's still pending me to review it (colibri), I have a TODO.
Lance+1 on 152
stpeterbut that can wait until the next meeting, I think (for 152)
Kevstpeter: There was an "LC" missing from that sentence.
fippoi'll review 0152 tomorrow, but it looked good
stpeterKev: ah, that I'm not completely sure of, but either way is fine with me
stpeterand yes, it is referenced by RFC 7081
KevThat is - I think xep1 says to LC again if Council doesn't finish voting by the end of term, but I'm not opposed to skipping it if everyone's happy to.
stpeter(informationally, anyway)
KevShall we schedule to vote on it on the 8th?
stpeterKev: you are right...
If the XMPP Council does not complete voting on a XEP before the end of its term, the XMPP Extensions Editor shall issue a new Last Call on the Standards list and the newly-elected Council shall vote anew on the XEP after completion of the Last Call. This provides an opportunity for any member of the previous Council who had voted -1 to voice his or her concerns in a public forum before the new Council votes on the XEP.
ralphmDid we even start voting?
stpeterso let's follow our process :-)
Kevstpeter: WFM.
KevAny other AOB?
stpeter(BTW I also plan to ask the Council for a LC on XEP-0279)
stpeterone AOB
stpeteror 2 perhaps
ralphm(i.e. 0152 is not listed in the tally for the 12th council)
stpeter(1) are we OK with accepting proposals (like Philipp's) that have not gone through the inbox?
Kevstpeter: Not in general, no.
fippostpeter: the xml is in the inbox actually
Peter WaherSo, am I waiting for input on eventlogging to continue?
MattJWhat practical difference does it make?
MattJPeter Waher, yes
MattJ(from me, it seems)
Peter Waherwhen can I expect this input?
KevPeter Waher: Within a week.
ralphmSection 5 of XEP-0001 clearly shows that it is not ok.
stpeter(2) see discussion about the liaison relationship with UPnP Forum, but that's before the XSF membership right now so no action required for the Council
Peter Waherthanks
Kev(People who don't vote in a meeting get a fortnight to do so on-list before they're DNV)
stpeterMattJ: it doesn't make a practical difference, so I think it's fine to have people request publication in a less formal way, I just want to make sure we're all clear that this is fine :-)
ralphmAlthough I am no longer on the council, I prefer we stick to the procedure
MattJIf I can see rendered versions easily before voting, I'm not too concerned about what the URL is :)
ralphmbecause it is a single location and notification to the standards@ list is part of it
KevI think this was a special case, as it was put in inbox, and there was a non-technical change needed when Council voted on it.
KevBut in just about all cases, I think it should go through the inbox+Peter.
ralphmI thought this was about the generic case, not this one.
Peter Waherthe tables in IM discussion, I would also appreciate some feedback on this issue
Kev(I note we sometimes pre-approve stuff, too, which is ~= the same as this case)
stpeter(as to inbox+Peter, I was thinking last night that we might want to turn the editor's role into a standing XSF Work Team, but I'll ponder that a bit more before suggesting it to the membership... :-)
Peter Waherespecially from Peter, since he's the author of XHTML-IM, and recommended a separate XEP in favor of using XHTML-IM
Kevstpeter: That seems like a sensible thing to do.
stpeterPeter Waher: yes, I will review your proposal and the email thread after the Board meeting
KevPeter Waher: I'll try to get to it when I'm trying to clear out my XSF stuff when I get back from holiday in the new year.
Peter Waherexcellent, thanks :)
ralphmLance mentioned some confusement on his part regarding tables, and I have the same.
KevI think we're done for the Council meeting, then?
ralphmWas it really suggested it would not be another profile of XHTML in a different XEP?
stpeterKev: yes
KevMarvellous, thanks all.
Kevbangs the gavel.
MattJThanks Kev
Kevralphm: I thought the suggestion (I've not looked at that thread in a while) was to have a discoverable feature that meant "And I also accept xhtml-im tables", and that was about it.
ralphmKev: right
LanceKev: ok, that was my take away too
stpeternods
ralphmKev: so I don't really understand why Peter Waher went for a separate thing.
KevI've not looked at it in a while, I need to catch up.
Peter WaherI understood it that way
Peter Waherbecause so many did not want to change the XHTML-IM implementation
Peter Waherthinking it was too complex
Peter Waherwith rendering
KevI don't think it was a case of complexity, it was a case of not shoving new stuff into a Draft XEP.
KevOr, at least, that would be my complaint.
ralphmIMO we could amend XHTML-IM to allow for (discoverable) extensions and then have the XHTML Basic Tables Module.
Dave Cridlandhas joined
stpeterralphm: quite possibly, yes
Kevralphm: Although XHTML-IM itself doesn't need to allow for discoverable extensions, I think, if another XEP just says "If you advertise feature X, also accept tables".
ralphmKev: the XEP forbids it currently
ralphmso at least some word smithing is in order
KevNothing is forbidden by negotiation :)
Peter Waherthe problem with the XHTML table module is that it is rather complex, and there was a desire to have a reduced set also
Peter Waherand then there was the discussion about blacklisting vs. whitelisting which made me feel the XHTML-IM was a topic some didn't want to touch
Lancethe black/whitelisting issue is mainly just client implementation details we've found to occur in practice (where using only a blacklist is insecure against creative attackers). we just have to ensure that things work when only a whitelist is in use, since that's the safer route
ralphmPeople will otherwise simply map the new stuff to HTML. Badly.
stpeterPeter Waher: well, we have "profiled" the other modules (some of which are also complex), so I don't see that as a showstopper
Peter Waherok
Peter Waherso, if you could revise the previous communication and then let me know in detail how you would like to see this extended, I can write an extension accordingly
Peter Waherif you feel the proposal is not in accordance to what you prefer
stpeterPeter Waher: yes, I will look at it in more detail here very soon
XMPP Council - 2013-12-18