XMPP Council - 2013-12-11

Anybody knows when the council meeting will start?

confused about time zones and summer/winter time in different hemispheres

Peter Waher: should be in ~30 minutes

thanks

Trying to review protoXEPs while exhausted is almost more fun than I can describe :)

why did we get rid of pipelining for BOSH?

kev: get over to paris and listen to people talking about RCS and IMS!

AIUI, because no-one did it and it's not legal.

fippo: Revision Control System? :)

rich communication suite

I like mine better.

Kev, pidgin did it at one point, if darkrain didn't remove it....will ask him about that :)

I think I need to review colibri some time that's not now.

quite a big agenda this time ✏

Kev, will there be a LMC update?

Kev, Pipelining POST, you mean? That's a SHOULD NOT in the spec, and we had reasons aplenty - I don't think we were breaking the spec with that.

@Tobias: BOSH makes POST requests and you may not pipeline POST

winfried, ah..okay

Dave Cridland: Ignoring a SHOULD NOT /is/ breaking the spec, IMHO.

wasn't always a should not, at least not in the BOSH spec...but don't know for sure...i implemented it eons ago

No, we used to say in bosh that you should.

'tis time?

hammer time

'tis time.

1) Roll call.

Kev, Well, *ignoring* is not the same as acknowledging but doing it anyway. The rule is there for good reason - start pipelining POSTs at something that's not expecting it and all manner of things can go boom. But between consenting adults it's fine.

here

hereo

fippo was in doubt.

Matt sends apologies.

fippo: You here?

fippo is in Paris for WebRTC stuff right now, no?

stpeter: Yes, he didn't know if he'd be Councilling.

When I spoke to him earlier.

But he doesn't seem to be here.

2) EventLogging http://xmpp.org/extensions/inbox/eventlogging.html

There's been some amount of confusion over there. I'm not opposing objecting.

Uhm.

Not opposing *publishing*.

+1 for going experimental

what's the expected locale if the XEP says one shouldn't localize?

regardless of that i'm +1 for experimental

Tobias: Then I suggest asking on list :)

3) http://xmpp.org/extensions/diff/api/xep/0124/diff/1.11rc1/vs/1.11rc2 http://xmpp.org/extensions/diff/api/xep/0124/diff/1.10/vs/1.11rc2 With changes since last meeting.

kev: here, but not physically. will vote on list :-/

I'm +1 on this.

fippo: Thanks.

+1 on the changes

+1 on XEP-0124

4) http://xmpp.org/extensions/diff/api/xep/0156/diff/1.1rc1/vs/1.1rc2 Changes since last meeting.

I'm +1 here too.

We do still need a legend/explanation from m&m for the chart though in 124

+1 on 156

are some patches still missing / issues not addressed for BOSH specs? Winfried's message suggested so

Tobias: Sorry, all very quick... What do you mean with "what's the expected locale if the XEP says one shouldn't localize"?

wonder why XEP-0156 defaults to unsecure HTTP and unsecure DNS for retrieval of connection methods

Peter Waher, it says you shouldn't localized messages, does that mean that all are supposed to be in english? or in the language of the original software but never translated? or what exactly?

Tobias / Peter Waher: If this isn't blocking publication, I suggest we take it to the list to move things along.

wouldn't it be sensible to expect lookup of those via HTTPS/DNSSEC if possible?

you can localize messages. What you shouldn't do is localize event IDs, for instance

"event IDs should never be localized"

"tag names should never be localized"

+1 on 156, will disuss it with lance later, if he wants

everything else can be localized

Thanks.

Tobias: yes, it would, but the security considerations say: Entities that use these connection methods need to ensure that they conform to the security considerations of each method (e.g., by preferring to use 'https' or 'wss' URLs that are protected using Transport Layer Security).

Tobias: k

5) http://xmpp.org/extensions/inbox/jingle-grouping.html

+1

+1

I'm -1 on this.

Kev, why?

But only because we cannot take RFC content and include it in XEPs.

See the recent discussion on w3c examples in XEPs.

kev: thanks, I was in doubt about that

you mean "a=group:LS voice webcam"?

fippo: XEP submission is copyright assignment. You can't copyright assign an RFC to the XSF, so ...

stpeter: Yes, so it's trivial to fix.

But it says at the bottom that it's doing it, so we should fix it.

kev: will do.

fippo: Ta. You can tell what I'm going to say about a later submission too :)

6) http://xmpp.org/extensions/inbox/peptzo.html

This looked fine to me.

There was discussion on list that this should be a change to XEP-0080 GeoLoc instead

+1 on peptzo

I don't see ""a=group:LS voice webcam" in RFC 5888

Does council think updating 80 is a better approach?

Yeah. I didn't really think that was conclusive, but I'm happy for you to retract this instead if you like :)

Lance: I've not formed an opinion yet.

Shall we put this onto the next meeting agenda?

Yeah, so a -1 from me today

stpeter: I think i adapted to 0167 already... but need to check again

OK.

7) http://xmpp.org/extensions/inbox/colibri.html

I have to vote on this one on-list, I don't have the cycles to review it today.

will vote on list for this one

s/don't/didn't/

i'm +1 for exerimental

Ta.

8) http://xmpp.org/extensions/inbox/jingle-sources.html

I'm -1 just for the RFC examples reason, again.

here i was surprised by the urn:ietf:rfc:5576 ✏

does that have to be registered somwhere?

Tobias: we already do urn:ietf:rfc:3264

stpeter, ahh..ok. didn't know about that

+1 once the rfc legal stuff is resolved

same as lance...+1 then

Tobias: http://tools.ietf.org/html/rfc2648

9) Board requests for liaisons.

tobias: rfc 2648 defines that

yes

bear / stpeter: This one's for one of you.

I have been in communication with the UPnP Forum about a liaison relationship

their spec-in-progress references the core XMPP stuff as well as various pubsub-related specifications

they *might* also hope for some input regarding Jingle

that's less clear right now

I can work with the Council regarding a call for volunteers

stpeter: How many people in this liason? One or more?

can be more than one

And does this happen in public or private?

in this case, I might say "should be more than one"

this work happens within the UPnP Forum, and their work is not public -- they have a working group made up up UPnP members and invited "observers" (which would include the people we name)

I think it would be best for now if we name only XSF members, too

not just general people we find on the street :-)

heh

i.e., we are treating this liaison group as a "Work Team" per http://xmpp.org/about-xmpp/xsf/xsf-bylaws/

I think that I can send a PDF of the proposed liaison agreement to the membership

I'd be inclined to say that it'd be sensible to try to have someone from Council, and someone not.

I will check on that

But let's ask for volunteers and see what happens.

Kev: sure

So, date of next?

and dynamic forms?

Kev: IMHO the process is, Council asks for volunteers, chooses the liaison team, and proposes it to the Board for approval

stpeter: Right.

(keeping in mind that we're going to have liaison relationships with UPnP Forum, ISO, and IEC by the looks of it, so we can't burden the same people with all the work IMHO)

Peter Waher: Has been covered in previous meetings, no objections.

stpeter: Yes.

So, date of next?

(y)

next week, usual time is good for me

I'm inclined at this point to suggest we go for the new year, but we can do next week if people like.

Yeah, ok, let's do that.

Any other business?

WFM

Kev, next week wfm

no AOB here

so both can have numbers and be published as experimental?

Excellent.

Peter Waher: I think so

excellent :)

thanks

Peter Waher: Need the two people not present to express an opinion for logging.

my other conf call just finished (went 30 minutes over), sorry about the divided attention

Right, we're done.

Thanks all!

thank you

thanks, Kev!

Tobias: what was the issue you had with 156?

Lance: that it should be done over HTTPS or DNSSEC if possible

I think the security considerations talk about that, but perhaps not strongly enough for his taste

stpeter, i think they basically say that if you originally intended to do a secure connection you should also only choose secure alternative methods

but i doesn't say, at least i haven't read it that way, that you should use secure methods to discover the alternative methods

Tobias: that does make some sense

i mean sure, DNSSEC isn't here....but HTTPS has some availability ^^

"Entities that use these connection methods need to ensure that they conform to the security considerations of each method (e.g., by preferring to use 'https' or 'wss' URLs that are protected using Transport Layer Security)."

that could be worded more strongly

stpeter, that still only talks about the choice among the provided methods, right?

Tobias, You're talking about using https to do the XEP-0156 discovery, right?

right

Tobias, Not merely using https for BOSH.

requesting the json file via HTTPS

or requesting that TXT record via DNSSEC

Tobias: yes, agreed

ah, right. yeah, adding a sentence for that should be done

technically that should bubble up from RFC 6415 for the host-meta stuff

Lance: right, let's check what the RFCs say for sure

stpeter: 6415 says if authentication is necessary for what's in the host-meta file, HTTPS only MUST be used

"Applications utilizing the host-meta document where the authenticity of the information is necessary MUST require the use of the HTTPS protocol and MUST NOT produce a host-meta document using other means. In addition, such applications MUST require that any redirection leading to the retrieval of a host-meta document also utilize the HTTPS protocol." they have this in their sec. considerations

but it wouldn't hurt to also mention it in the XEP, and that way we can add DNSSEC to it too

Tobias +1

Tobias: agreed, thanks for pressing the issue

stpeter: "no burden the same people" means you cant be on it :-)