XMPP Council - 2013-07-03

Ralph: Thanks.

Reminding everyone that we're starting 10mins later today (and limiting ourselves to 20mins).

T - 6 minutes?

affirmative

hmm … the XSF calendar doesn't reflect it

no, I didn't update the calendar

yet

T - 4 minutes.

It is time.

1) Roll call

I'm here!

Harpier cries, 'tis time, 'tis time!

presente

aye

I'm here

I can't see a Tobias to poke.

we still have quorum

We have.

2) HTTP over XMPP.

I didn't catch up on this (RTT took me a while!) will vote on list.

No objections.

No objection here either

But I'm waiting for UPnP over XMPP

I've no objections to Experimental

OK.

3) Chat Markers Discuss Kev's concerns

MattJ: I'm pretty sure I remember people doing exactly that.

So, I wanted to discuss this because I'm surprised that everyone else is OK with it :)

I'm not, I'm rather behind on the new stuff

MattJ: You've 'no objectioned it', I thought?

Markers?

Yes.

It seems to me that the current proposal is kinda broken, and that just doing what 184 does but s/delivered/read/, combined with MAM/carbons would solve the discussed issues.

Ok, yes

I did, and I did read the new version, I somehow forgot that

I'd like to block it on this basis, so would like everyone else who wants to publish it to tell me I'm wrong :)

On the basis that it's in the style of XEP-0184, but doing things that 184 cannot?

MattJ: On the basis that it's doing stuff similar to 184, in a different way to 184, such that the proposed way is broken and just copy/paste of 184 wouldn't be.

Kev: I'm not sure what you mean with 'OK with it'. I make a pretty big distinction between allowing a proposal become experimental and moving it to Draft. We have had multiple (slightly overlapping) proposals on several topics before, and I am entirely fine with that.

Kev: as in, define 184+ which covers "read" instead of "delivered"? or augment existing 184 to add "read">

It's not the overlappingness that bothers me with this one, it's that it's broken.

Oh, right - you have a point... in that if we mandate Carbons+MAM as part of the solution, XEP-0184 can work?

stpeter: Either way. But exactly 184 syntax other than s/delivered/read/.

I think there was some justification of this on the list

MattJ: 184 can work, as can s184/delivered/read/

And that these /would/ work, while the proposal doesn't.

Chat Markers is also tied to UI interaction, which is extremely rare for a XEP

Then I guess the next step is for some more concrete proposals (even just to the list) on how XEP-0184 could be used/adapted for this purpose

MattJ: right

Please don't say I've volunteered myself :/

Too late :)

you're the one objecting the strongest

So yeah, maybe this spec currently doesn't do the most desirable thing (if at all). I awarded it no objections, because of the attempt to solve a problem people are experiencing. It might very well be that indeed using XEP-0184 is better a approach combined with Carbons+MAM. This could be done either in an updated version of this spec or as modifications to XEP-0184.

True. I'm not entirely sure why everyone else isn't, which is what bothers me.

i.e. am I wrong about it being broken?

I am in the same position as Ralph

I admit that I haven't paid close attention to the Chat Markers discussion

And I don't see this being fundamentally broken

m&m: right

particularly the assumption that: you're always going to be sending them to a contact you're already in a chat with, and therefore will be bound to the full JID.

I think is false

I'm in the same position as m&m and Ralph, but I do think Kev's proposal has merit, it just needs a bit more elaboration

OK, but that wasn't the fundamental brokenness. The fundamental brokenness was saying "I have seen everything up to X" - when you have no idea what was up to X.

You either need to enumerate what you've seen, or ack individually (like 184).

Otherwise you have the situation of something like

Kev: so wouldn't it be great to have this proposal as a starting point and then has it out with the authors on the standards list?

hash it out

<A> Man down, need evac. [gets lost] <A> And I fancy a cup of tea <B> I have seen every message up to 'cup of tea'

Kev, but it's not designed for ensuring reliability...

I think that's better left to other parts of the stack

MattJ: You're confirming that you have read a message.

MattJ: That's the strongest form of assertion that a stanza has been delivered.

hmmmm

Sorry I'm late. If there are any questions/comments on the HTTP over XMPP XEP proposal, I'm happy to answer

clearly I need to look at Chat Markers more carefully

not that I have a vote :-)

Kev, then it's enough to satisfy your concerns with a note in the XEP that it depends on reliable delivery?

Most people don't need that sort of assertion, and those that do would presumably be unhappy if it was unreliable.

MattJ: That it can only be used if 184 is also used for every message? That would work, but boy is it ugly.

Anyway. 3 minutes to go. I'll send objections to the list

Peter Waher: Thanks. I need to vote onlist on that.

Great :)

4) RTT - move to Draft

While I welcome discussion on this spec, I'd rather have this done on the standards list, with a published first spec as basis.

exactly what ralphm says

I'd like to see the current discussion resolved before we move to Draft, as normative language is involved.

Kev: fine with me

Kev: above comments were still on Chat Markers

I'm in favour of publishing most stuff to Experimental, unless it's obviously broken, which I think this is.

Yes, I gathered :)

Anyone else want to express an opinion on RTT?

so hopefully the RTT discussion can be completed soon and then the Council can have a vote

As for RTT, I think the recent comments on the list should result in an extension of the LC phase.

WFM.

agreed

nod

Fab.

5) Date of next

Same 15:10 time, next wek?

+e

fine here

Should we set a new date for LC?

let's just assume that's the case

+1

ralphm: not needed, I think

OK.

stpeter: ok

6) AOB?

I'm ok with this time

as long as it gets into the calendar!

(-:

I'll just show up around 15:00UTC as before

And then wait until a chair shows up

I need my 10-minute warning bell

What was the conclusion about the HTTP over XMPP proposal?

ralphm: LC often gets "extended" -- in fact I think we have a few specs that the Council hasn't voted on yet and for which the last calls started months ago, right?

Peter Waher: Kevin still needs to weigh in

Peter Waher, all accepted but Kev, who will vote on the list

which he will do on list

oh, time for a conference call here, will check later

ok

Have fun

As a minor side project I worked on some CSS thingies for a nice side ribbon for XEPs

ralphm: Lovely.

stpeter: Ta, bibi.

back to the official meeting — I've got no AOB

Excellent.

nothing else from me

Ta.

I think we're done then.

Thanks all.

Thanks Kev

grazie

Thanks!

Kev: if you decide to -1 chat markers on list, could you just send your objections to the standards list to go with it?

ralphm: Yes.

awesome

Looks like next FOSDEM will be under a new King.

http://www.bbc.co.uk/news/world-europe-23167525