XMPP Council - 2013-12-18

Kev, why was the agenda titled 17-12-2013?

Because it was the 17th when I wrote it, and I'm not very smart.

ahh..ok

i'll probably have to leave shortly after begin of the meeting. i'll post my votes on the list

Ta.

howdy

bbiaf, need tea

fippo, what's latching?

tobias: similar to TURN, i.e. a relay in the media path

ahh..ok

hi Ralph!

hi!

and bear! :-)

morning

bear: better train your cat

ralph, he's about as trained as you can make a cat - he no longer orders from Amazon via 1-click

heehee

:-)

Nearly time, it is.

'tis time, 'tis time.

are we almost there yet? ;-)

Jingle on!

1) Bread products()

I'm here.

here

Croissant.

semmel

Tobias / MattJ.

I'm not

Here

2) http://fippo.github.io/customxeps/extensions/jingle-sources.html Accept?

+1

+1

+1

oh, this still says the example was taken from 5576

I can fix that before publication

I thought I checked the diff and it didn't any more.

Oops.

I trusted you, fippo!

trust, but verify!

Anyway, yes, please remove before publication.

3) http://fippo.github.io/customxeps/extensions/jingle-grouping.html Accept?

+1

+1

+1

I'm casually assuming fippo is +1

kev: thanks (-:

4) Date of next.

8

8th Jan?

lgtm

WFM

I wonder what is missing for eventlogging to be approved as experimental and get a number?

wfm

Peter Waher: That's done, isn't it?

sorry, my ethernet cable fell out

Ah, no.

well, it hasn't been published

Needs Fippo and Matt to not object.

Kev: I think we were waiting for Council members to vote

There's another week for them to do so.

kev: no objections

(didn't I say that before?)

fippo: Not in response to the minutes, at least.

Just MattJ, then.

5) AOB?

I mentioned another vote on XEP-0152

any new votes on colibri?

Sorry, didn't know that was waiting on me - though I know BOSH is

I'll get to it

the previous Council did not complete its voting, and I made changes to address Council feedback

stpeter: I think the procedure, given xep1, is for another if Council doesn't finish voting by the end of term.

stpeter: is 0152 referenced by cusax?

Although I'm happy to skip that if everyone else is.

fippo: yes

Kev: yes, another vote for sure

I'm happy with 152

fippo: No, that's still pending me to review it (colibri), I have a TODO.

+1 on 152

but that can wait until the next meeting, I think (for 152)

stpeter: There was an "LC" missing from that sentence.

i'll review 0152 tomorrow, but it looked good

Kev: ah, that I'm not completely sure of, but either way is fine with me

and yes, it is referenced by RFC 7081

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

(informationally, anyway)

Shall we schedule to vote on it on the 8th?

Kev: 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.

Did we even start voting?

so let's follow our process :-)

stpeter: WFM.

Any other AOB?

(BTW I also plan to ask the Council for a LC on XEP-0279)

one AOB

or 2 perhaps

(i.e. 0152 is not listed in the tally for the 12th council)

(1) are we OK with accepting proposals (like Philipp's) that have not gone through the inbox?

stpeter: Not in general, no.

stpeter: the xml is in the inbox actually

So, am I waiting for input on eventlogging to continue?

What practical difference does it make?

Peter Waher, yes

(from me, it seems)

when can I expect this input?

Peter Waher: Within a week.

Section 5 of XEP-0001 clearly shows that it is not ok.

(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

thanks

(People who don't vote in a meeting get a fortnight to do so on-list before they're DNV)

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

Although I am no longer on the council, I prefer we stick to the procedure

If I can see rendered versions easily before voting, I'm not too concerned about what the URL is :)

because it is a single location and notification to the standards@ list is part of it

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

But in just about all cases, I think it should go through the inbox+Peter.

I thought this was about the generic case, not this one.

the tables in IM discussion, I would also appreciate some feedback on this issue

(I note we sometimes pre-approve stuff, too, which is ~= the same as this case)

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

especially from Peter, since he's the author of XHTML-IM, and recommended a separate XEP in favor of using XHTML-IM

stpeter: That seems like a sensible thing to do.

Peter Waher: yes, I will review your proposal and the email thread after the Board meeting

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

excellent, thanks :)

Lance mentioned some confusement on his part regarding tables, and I have the same.

I think we're done for the Council meeting, then?

Was it really suggested it would not be another profile of XHTML in a different XEP?

Kev: yes

Marvellous, thanks all.

Thanks Kev

ralphm: 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.

Kev: right

Kev: ok, that was my take away too

Kev: so I don't really understand why Peter Waher went for a separate thing.

I've not looked at it in a while, I need to catch up.

I understood it that way

because so many did not want to change the XHTML-IM implementation

thinking it was too complex

with rendering

I don't think it was a case of complexity, it was a case of not shoving new stuff into a Draft XEP.

Or, at least, that would be my complaint.

IMO we could amend XHTML-IM to allow for (discoverable) extensions and then have the XHTML Basic Tables Module.

ralphm: quite possibly, yes

ralphm: 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".

Kev: the XEP forbids it currently

so at least some word smithing is in order

Nothing is forbidden by negotiation :)

the problem with the XHTML table module is that it is rather complex, and there was a desire to have a reduced set also

and 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

the 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

People will otherwise simply map the new stuff to HTML. Badly.

Peter Waher: well, we have "profiled" the other modules (some of which are also complex), so I don't see that as a showstopper

ok

so, 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

if you feel the proposal is not in accordance to what you prefer

Peter Waher: yes, I will look at it in more detail here very soon

(y)