XMPP Council - 2013-09-25

are there any outstanding votes from me?

Not for another 2 minutes :)

great

ding

dong

the witch is dead

the witch is dead

dammit

Which old witch?

1) Roll call!

Present

presente

here

Le Ralph?

here

Marvellous.

yay!

2) http://xmpp.org/extensions/xep-0297.html Advance to Draft?

Kev: http://xmpp.org/extensions/xep-0297.html: XEP-0297: Stanza Forwarding

+1 from me

+1

+1

+1

I'll double check before sending +1 to list.

I think that was the only voting action this week.

So unless I missed one...

3) Date of next meeting

SBTSBC WFM

wfm

Excellent.

ditto

yay

ralphm?

OK.

4) AOB.

Yes, my outstanding votes need recording :)

I notice the Board and Council nominees are thin

do we already have a new version of RTT to read/vote on or will a last call be reissued?

I'm +1 on 220 and 288

The 301 authors have submitted another version to Peter to address m&m's comments, although not my last remaining comment (which I first raised ages ago).

Tobias: Was already typing :)

FWIW, my remaining comment (which didn't go to list because I was replying to a mail they didn't send to list, accidentally) was:

I'm sorry for being a nuisance yet again, but I have one remaining nit. At the end of 6.1 you have the ...MAY implicitly request... e.g. when...invisible/offline. Can you tighten this up just slightly to be clear that implicit discovery is only allowed when normal discovery isn't possible? I suggest this tweak: "While explicit discovery is strongly RECOMMENDED (see Determining Support), the sender client MAY implicitly request and discover the use of real-time text, by sending <rtt event='init'/> upon activation" -> "While explicit discovery is REQUIRED (see Determining Support) where possible, it is not possible to use explicit discovery when the sender does not share a presence subscription with the the contact and knows only their bare JID (e.g. they have yet to receive stanzas from the contact). In this case, the sender client MAY implicitly request and discover the use of real-time text, by sending <rtt event='init'/> upon activation" I think this keeps your ability to discover implicitly when explicit discovery isn't possible, but maintains that in all other cases you need to do explicit discovery.

I'm +1 on 220 and 228 as well

I feel fairly strongly that we shouldn't be introducing another pseudo-discovery mess like 85 here. (85 became a mess because 115 didn't exist when it was published, and we needed to maintain backwards compatibility).

115 and decloaking

Kev: this came up before, and I agree

Having worked on a couple of 85 implementations I don't think that confusion is helpful.

i think discovery should be used where possible...if they don't want expensive discos they can ship their clients with precalculated caps databases

Makes sense to me

ralphm: It did, but the authors didn't really address it last time (and haven't this time), claiming they need to be compatible with -85.

m&m: I thought about saying they should be using decloaking, but I can also see the argument that decloaking hasn't actually gone anywhere.

How is that even an issue? Clients that implement XEP-0085 will, eh, implement XEP-0085.

ralphm: Right, I don't think my proposed text means there's ever a case where you could do -85 but couldn't do -301.

I'd like to keep blocking until this is addressed, so I'm presenting it here so the rest of Council can talk me down if they disagree with me.

But it doesn't seem like they do :)

So, 280 (and 313) could move forward now? (If Kev +1es)

Kev: I support your -1.

Zash: in theory

Kev: hold the line

Zash: I think they can go to LC, if the authors request it, yes.

ralphm / m&m: Ta.

313 isn't quite ready yet, I have a new version I need to push

OK. I note Ralph and Matt's votes from earlier, will minute.

But then it'll be ready

Kev: that kind of moves this to 'Rejected', right?

Anything else for AOB?

could we have the votes on our votes page?

I notice the Board and Council nominee list is thin

ralphm: If we're following the letter of XEP-0001 (which we never do), it would, yes. But I'm happy with the usual "We'll just keep it in Proposed until all feedback is addressed".

ralphm: What are your thoughts?

Does XEP-0001 need updating to reflect this process then?

Kev: practically, how could a spec ever move to rejected?

m&m: Yes, seems so. I'll apply to Council again. I'm aware of people being poked for Board behind the scenes.

referring to this page http://xmpp.org/about-xmpp/xsf/xmpp-council/twelfth-council/

Tobias: http://xmpp.org/about-xmpp/xsf/xmpp-council/twelfth-council/: Twelfth Council &#8211; The XMPP Standards Foundation

ralphm: Only if we decided during LC that it wasn't ever going to be appropriate to move to Draft, I think.

hm

Tobias: I think Peter usually maintains that page. I'm sure he'd appreciate a volunteer, if you are :)

sure...but i have no clue who voted what :)

MattJ: I think probably updating XEP-0001 to match reality is desirable. Although given the imminent departure of Board, it might be best to wait for next term.

Tobias: The minutes :)

m&m: Know of any issues with 280?

Tobias: If you want to take this on, I'd suggest poking Peter.

I was planning on running for Council

Zash, m&m: might hate me for this, but it doesn't use hints

(sorry, I got delayed and I'm also on a conference call)

hey stpeter

Hi Peter.

Zash: I think fippo and cridland (in a previous life) worked out most of the technical hurdles, and the latest draft reflects this

I can live without hints (-:

I'm not sure where we are meeting-wise, now. I think we've dealt with all official business and can close?

we're at AOB

AOB was the last item, yes.

It's not clear that we're actually still in it :)

so, if you're going to run, get your page up!

m&m: Done.

Although I should update it to not be a copy of the last eight years :)

OK, I think we're done with AOB and are just chatting here?

Kev: you could go the bot route (-:

/nod

So, last call for AOB :)

m&m, I heard you may not be in Portland... say it ain't so

I will not be in Portland )-:

not physically

I'd like to chat a bit about Porland, outside this meeting

if there's a remote option, I'll join that

OK, let's close up then.

Thanks all!

Thanks!

So, Summit #14

thanks

There's been some talk, the number of people signing up is rather low.

Still, I do think it is worth it to meet up.

Yeah, I'm afraid we don't really have the cycles to lose anyone for a week at the moment, else I'd be inclined to attend.

Not all talk with a large group like usual, but at least partially do some actual work.

m&m: Didn't someone mention that 280 + MUC was an issue? And using hints instead of the 280-only <private> would be nice.

Zash: I'm a moron … I see 280 and thought 288

I need to go back over 280

MUC private messages can be an issue

For MAM too

Why is the server applying carbons to things that don't come immediately from an active endpoint?

(Summit) For example, our web site needs love, spec pages, splitting up XEP-0060. Maybe something like tutorials for publish-subscribe and other topics.

ralphm: On the pubsub topic, did you see Remko's blog post? I thought that was pretty neat.

Oh, damn, there was something I wanted to discuss in AOB. Nevermind, can do it out of band.

(-:

Kev: yeah, stuff like that is great.

stpeter: Feel free to report back once you know about it :D

Kev: I was looking at http://www.rabbitmq.com/getstarted.html

ralphm: http://www.rabbitmq.com/getstarted.html: RabbitMQ - Getting started with RabbitMQ

Kev: and also, I am sensing that we should have an offering for people using XMPP as part of their application, without starting out with a full-fledged XMPP server.

m&m: Hm? A PM from a remote MUC looks exactly like a chat message from a s2s connection.

Kev: of course the existing software to support this use case is lacking, so maybe we should try come up with what's needed for something like that

ralphm: Hmm. I'm not sure what the value of only having part of a server is. Or did I misunderstand?

Kev: use case is something like Facebook. They started out with ejabberd, needed to replace most of the guts of the thing (like the session manager) and finally started rebuilding it from scratch.

Kev: I did this for just publish-subscribe at Mediamatic

Kev: and I am sure that many people trying to use XMPP as part of their application get stuck on this

Zash: I'm not understanding your terseness then

Facebook is a somewhat special case, because they were mapping an existing IM implementation onto XMPP at the boundary, most people don't have large internal IM systems. So the Mediamatic case is probably more interesting.

So, in what way was what you did there different to e.g. running up M-Link* and only using the pubsub bits.

[* Replace with server of choice]

heh, the topic of XMPP compliance testing has arisen on this conference call :-)

Kev: actually, I have exposed a model of a publish-subscribe node as an internal API, not unlike what web frameworks do for building web sites

Kev: and then used that to glue it on top of the (HTTP API) of the website

I don't think this is the ideal medium for discussing this, sadly. What you describe sounds naively like putting a relevant API over the top of XMPP, rather than needing to cut bits out of servers.

Kev: it also uses the s2s implementation in Wokkel, but you could also run it as a server-side component and have a (bare) server do that part.

Kev: that might be true.

I guess one option would be to register xmppformiddleware.com, and do much like the RabbitMQ thing, with how to do basic stuff in different languages. I would suggest that doing this through the XSF would result in too much need for fairness. e.g. if I was working on it, I'd pick Swiften for C++, and ignore Gloox, Stroke for Java and ignore Smack, etc.

I think it would be very unhelpful to have 37 different 'how to do it in Python' examples, for each of the libraries.

Kev: oh, it doesn't really need to be an XSF thing at all

But I think it'd be a really interesting project to do outside the XSF.

Kev: but a nice topic for the Summit

And I'd be willing and/or keen to work on such things with people (but not alone).

Kev: also, make sure that you block out Summit #15 (Brussels) in your agenda. :-D

Point.

(and those of your minions)

Haha. I have no minions, sadly. We're all Kurt's minions.

Kev: all Kurt's minions then. Whatever makes you guys show up.

Do we have days for the summit yet?

Kev: not yet

OK.

I do know there is http://cfgmgmtcamp.eu on Monday and Tuesday. Not sure if that's a problem.

ralphm: http://cfgmgmtcamp.eu: Config Management Camp 2014, Gent

I thought the rough consensus was to do the summit before, not after?

because people are worn out after FOSDEM (-:

yeah

30/31 seems fine to me

m&m: And because they can head home on the Sunday of FOSDEM, cutting a day off the trip :)

Kev: well yeah, *those* people

I see the Sunday of FOSDEM as being by far the least productive of the four days, personally.

You mean the LOSERS! (-:

and miss out on a prime opportunity for more beer

yay, finished with my conf call

m&m: I'm aware my desire to be at home is much stronger than most people's (and my desire for beer much less strong), yes.

Kev: it is what you make of it. I've done some productive stuff by grabbing one or two other people into a hacker room and then do some speccing, in previous years

I don't claim it can't be productive, but I find it all exhausting, and I'd rather concentrate my energy on the other days :)

Kev: I say you need more training.

Possibly.

stpeter: The remaining item that I forgot to put into AOB is how we're going to move Reachability forwards.

Or upwards, or whatever direction the process goes in.

yes

is the meeting still going here or is this post-meeting chat?

Post-meeting chat.

it's the after-meeting

ok

Good grief, do you think we've been going for 50 minutes? :)

I doubted it!

Who are the people who're building things with the XEP, and how do we get them to confirm/deny that it's doing its job?

I think I'll ping all the folks who provided feedback on the CUSAX spec

Thanks.

I might have a non-CUSAX use case, too

This feels like it should be part of a vcard spec, rather than independent, but I'm not going to be Mr. Unpopular and do anything because of that. The world is what it is.

sometimes you have more dynamic information that would not go into your vCard

e.g., you walk into a conference room and based on near-field communication or simple old reading you discover the 'tel:' or 'sip:' URI for a video endpoint

Marvellous, I feel better about it now, thanks.

once you walk out of the room, you don't want to update your vCard

I hadn't quite clicked it was an as-you-walk thing, when it talked about moving buildings.

Yeah, that makes sense.

but I am not sure that people are building this into products yet, although I wish they would!

ideally that stuff would be automated

so I walk into a conference room and my XMPP client can push my temporary contact location to you

All makes sense, ta.

if I have a more stable contact address (e.g., my configured SIP URI) then yes, that makes sense to put in my vCard for sure

if that's not clear then it needs to be

Multiple vCards or vCard items in their own PEP nodes?

Zash: why would I want to have multiple vCards? sounds confusing...

stpeter: I'd suggest putting (e.g. changing their addresses as they walk from one room to another) to the bit in section 2 about dynamicness.

Kev: yes

stpeter: Persona. E.g. I have multiple google plus accounts (personal and company)

stpeter: Simplified access control, namespace/spec reuse, separation based on TTL

Spell it out for stupid people like me :)

Zash: you arguably don't need multiple items for restricted access

(you can serve up different content)

ralphm: Do we have anything for only sharing parts of vCards based on who's receiving it?

The OneSocialWeb people were working on something to address that, but I don't think it ever got submitted

ralphm: BTW the folks I was chatting with earlier are going to use pubsub for most of their use cases

Zash: you don't need additional protocol for the subscribing/retrieval part

stpeter: cool

ralphm, but things like not giving out my private phone numbers to people not in my contact list or limiting it to a specific roster group

Zash: you could do this as part of the implementation. Depending who asks, subscribes, you give a different view on the same data.

ralphm: We have no way of defining that though, I think.

Zash: you might want to specify how to make a service do that.

So you could patch your server to do these things, but it's specific to your deployment.

Zash: like with node configs

ralphm: Yeah

my point was that you don't need additional protocol, per se

My steak is calling. Back in a bit.

Mmmm. Steak.

heh

at some point I'll need to scroll up and see what all the discussion was about, but first I'm trying to finalize some summit details

hmm, last year we spent quite a bit on room / catering at the Summit, I'm sure I can get that down a bit this time

at both meetings?

no, just in Portland

ahh..k

the meeting rooms are free for me at the Cisco office in Diegem ;-)

stpeter, maybe cisco also runs a catering business which needs to produce profits :D

heh

pizza boxes? ;-)

Mmmmm, pizza.