XMPP Council - 2011-05-18

Kev: I have given my feedback and reasons for vetoing Sensors over XMPP

Evening.

Thanks.

thanks, Fritzy!

*nod* -- sorry it's so late.

/sigh … one of my network drops is dead

that's going to make today interesting

heh

if only I worked for a company that knew something about networking...

:)

on the plus side, I have no phone, since it's the one plugged into the dead drop (-:

You find good in bad. I like!

every silver lining has a cloud!

and a nice movie reference, fritzy!

hi

Right.

Dingding etc.

!agendaup

1) Roll Call

MattJ has been poked.

here

presente

Ralph here?

yes

Oh, sorry, didn't recognise the new nick.

stpeter: Hi Ralph.

:)

2) Agenda bashing.

None

nay

new nick?

ralphm: stpeter replied on your behalf.

3) XEP-0220 (Server Dialback), advance to Draft?

+1

☑

ooh nice

there's still some discussion on how to advertise db+errors, correct?

linuxwolf: yes

I'd rather hold off on Drafting this until there's at least some agreement amongst the authors :)

ah, ok

Kev: I don't think that will happen

The namespace versioning issue needs resolution, too.

Kev: I think that's the same issue, no?

stpeter: Is it? I thought he was complaining about a bug in Example 7.

Ah.

Which is, indeed, error handling.

sounds like I should retract my vote.

If things are still up in the air

s/to=sender.tld/to=target.tld/

I think they are

stpeter: Do you have comment on this?

FWIW, i think the existing errors feature advertising has been about long enough that even if the implementations *could* be changed, I suspect there'll be confusion if it were changed in the spec.

Prosody doesn't implement it, I'm not sure ejabberd does - M-Link and PSYC? :)

I'm not sure why this would impede advancement, as this was already in the spec and people apparently have implemented and it is seems backwards compatible

also, technically, XEP-0220 is experimental

MattJ, I thought someone else mentioned doing so, as well.

linuxwolf, That's not an argument *for* changing it.

ralphm: No-one has implemented the spec as it stands, because it's just had the namespace changed.

do we agree that this is a poor design? <stream:features> <dialback xmlns='urn:xmpp:features:dialback'> <errors/> </dialback> </stream:features>

heh

That is - all existing implementations are incompatible with the current revision.

I think it is

stpeter, I think so, yes

(a bad design)

stpeter: Poor design? Yes. What's already in the wild? Probably.

Kev: oh, right

because if we keep that, then we need to add a note to the spec saying "this is a bad design, if you design your own stream features in the future then don't do it this way"

dwd: a bad design is a good reason to change it

linuxwolf, Cool. Can we change self-framing XML, too, then?

haha

is self-framing XML an experimental XEP?

and we need to say "if we add new dialback-related features in the future, then they MUST NOT be added as new child elements like <errors/>"

stpeter: That is one of the two options, yes.

linuxwolf, Proposed Standard, so technically still subject to change.

how many beers do I need to buy for the M-Links developers to change their minds?

s/Links/Link/

(I'm not even sure it is bad design - at best it's inconsistent with Disco)

stpeter: I'm not firmly in one camp or the other. I'd just like to see something approaching agreement.

(Well, I'm firmly in the 'we should not go with the current XEP approach' camp, but not firmly in either of the other two)

I think it's a bad design…and would require the spec to be updated (and the namespace to be changed) if we added more later

linuxwolf: No, that's not true.

it's a schema change

linuxwolf, I don't see how you arrive at that conclusion.

I note that http://xmpp.org/extensions/xep-0288.html has: <stream:features> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> <bidi xmlns='urn:xmpp:features:bidi'/> </stream:features>

not: <stream:features> <dialback xmlns='urn:xmpp:features:dialback'> <bidi/> </dialback> </stream:features>

linuxwolf: Adding more *the wrong way* later would lead to a schema change.

although bidi is not strictly a dialback thing

Kev: that's what I'm saying

I'm assuming if we add more features in the future, we'll do it right.

So #1 is out

No.

We've done it the wrong way once, they question is whether to live with it or not.

There's no cause and effect between letting the (previous version) current way stand and having to do it wrong again in the future.

ok, then my vote is to not live with it

I'd be fine with <errors/> being the last thing added to dialback's stream feature.

but, IMO, we have time to change this

So is mine, but only if we can track down existing implementations (I'm not sure there are many in reality)

I'm −1 on keeping it, unless there's a plethora of implementation that will break

My preference is that we should only break namespaces when there's an incompatible change being made, really.

then I'll re-evaluate (-:

we /could/ define a real stream feature and deprecate <errors/> but I'm unsure about the actual impact

ralphm, Same issue.

of course

Dave Cridland, are you saying you're absolutely against switching to a <dialback-errors> feature?

it's not a hill for me to die on, but it's ugly and the wrong way to do it and sets a bad precedent -- people look at the XEPs for examples of what to do in their own extensions and someone will say "oh they did it in XEP-0220 so it's fine in this extension" (and realize that people might never even look at the spec, they'll just see the XML go across the wire)

we're still advertising support of dialback (sans error-handling) via a namespace declaration, no?

I am, in any case, -1 on advancing 220 as it currently stands, so this discussion can take place on list :)

linuxwolf: no

stpeter, I agree it seems bad to have backwards-compatibility cruft in such a "recent" feature

linuxwolf: advertisment is just via namespace on the stream header

(Which, given that we've not changed 0001 yet means that -0220 has just died. Yay!).

so discussion ensues and we -1 it for now

Kev: hehehe

4) XEP-0262 (Use of ZRTP in Jingle RTP Sessions), advance to Draft?

☒

MattJ, I am generally against changing deployed specs incompatibly for aesthetic reasons, yes.

I suppose we could say that <dialback xmlns='urn:xmpp:features:dialback'/> means you support dialback with errors and get rid of the child element

I'd be fine with that

stpeter: I would be ok with that

stpeter: and if you don't actually do it it doesn't break stuff

ralphm: right

and the <errors/> is merely informational no-op

stpeter, I've a nagging feeling that there exist implementation advertising dialback like that but without supporting errors.

Is it?

that'd work for me

Folks, this discussion doesn't need to happen now.

right

Can we move onto (4) please.

Dave Cridland: I don't know of any implementations that do it that way

ok, let's focus!

#4

Kev: trying to use the high bandwidth connection to reach consensus :)

bt I'll propose it on the list

Discuss in 10mins once Council's over and I can start ignoring the chat :)

4) XEP-0262 (Use of ZRTP in Jingle RTP Sessions), advance to Draft?

I haven't looked up the feedback thread yet. Will vote on-list.

was there feedback? I don't remember seeing any

There wasn't feedback iirc

I don't remember any, but I need to find the thread to be sure :)

heh

No feedback and I'm not aware of any implementations

it is implemented in Jitsi

Ah good

One reply, from Peter, saying that the date was wrong.

for voice and video

stpeter: can you ping them to send an "a ok" or something about it, then?

I've seen it displayed at FOSDEM so it must be true

well, that's something!

Should we ask them for feedback specifically?

If there are known implementations, and no feedback to the LC, I think it's worth poking, yes.

+1

definitely

Is Jitsi SIP Communicator as-was?

Kev: pokage in progress

+1

(to poking)

Dave Cridland, yes

Dave Cridland: Yes.

+1 to POKE, DNV for now

Anyone else want to say yes?

Dave Cridland, no

Dave Cridland: No.

Ok, so who's volunteering to poke them for feedback?

I just have

Ta.

thanks

5) Date of next.

Next week is ok for me as far as I am aware

Jolly good.

same here

works for me

ralphm?

any further votes on 178?

+1

I think the voting period's expired for that hasn't it? :)

very much so

6) AOB.

+1 on −178

thought I did that on-list

any news on the summit?

ralphm: I think I saw a mail fly by saying it was cancelled.

linuxwolf: I missed that

but I'm getting ~200 emails/day, so it's getting lost (-:

Although I don't think I was paying much attention at the time.

linuxwolf: man up :P

right, we haven't organized the summer summit so we'll see you all in Brussels again someday

Yay

so meeting next Wed?

Yep.

adding to calendar

And we're done with 3mins to spare.

Thanks Peter.

Thanks all.

and now to the flame war

Heh

BTW if folks want to look at my i18n stuff it'd be cool

stpeter, where is that?

xmpp@ietf.org

the precis draft

or http://xmpp.org/2011/05/progress-on-internationalization/

Ah yes, thanks

stpeter: on my /todo

On mine too

thank

thanks even

ciao

we can see that Ralph likes Unicode ;-)

Unicode Rocks™ and all that

Ralphm: what happened to "if you don't like ASCII…f**k you"? (-:

heh

linuxwolf: did I ever say that?

linuxwolf: also, I don't see how that's conflicting with liking unicode

ralphm is a man of contradictions :)

haha

stpeter: pft! Al

ralphm: well, I said the first part…and beers were involved (-:

linuxwolf: agreed

stpeter, hmm, my vote isn't there... I'm +1

ok

But I'm working more on Prosody's implementation soon so I may have some feedback

as ASCII is a strict subset of unicode, I don't see how this is a contradication

not sure if Fritzy voted

ralphm, you win :)

ASCII is a strict subset of UTF8, actually

(-:

I think I missed a meeting while travelling of late

linuxwolf: hehe

and UTF8 is a particular encoding of Unicode, afterall (-:

nevertheless a thing to like

I've got a slidedeck I can show you about it (-:

stpeter: I don't think my vote on 0220 is accurate

given the revote and updates and whatnot

Indeed. I'm currently -1.

Kev: noted

heh, now I'm receiving password requests for chat.facebook.com at jabber.org

stpeter: I'm "" on XEP-0220 right now, pending further discussion about advertisement

ugh

and I'm 10 minutes late to a 15-minute meeting (-:

adios

linuxwolf: noted

I changed ralphm to "" as well

so the only vote is Kev's -1 :)

Which I'll no doubt be changing shortly.

stpeter, ralphm may well be “”, in fact.

heh

☐

:)

☺

I tried a bottom bracket with combining umlaut once, and it actually worked. I was particularly happy.

̈̈̈̈‿̈

ooh

Unicode Art is so much more experssive than the ASCII kind.

‿̈

I had another combining one in there

There's actually a smile codepoint that might be better.

⁀̤

̤⁀⃘̤

◡̈

Many options.

I just tried a combination that kicked out my connection

with combining musical symbols

probably because they are in another plane

Could be anti-codepoints.

You can't put those in contact with ordinary codepoints, they'll explode.

I had a cross-note-head with a combining 1/64 stem

Yeah, you need to have a special screwdriver for those, though.