Kevstpeter: Is it? I thought he was complaining about a bug in Example 7.
KevAh.
KevWhich is, indeed, error handling.
Fritzysounds like I should retract my vote.
FritzyIf things are still up in the air
linuxwolfs/to=sender.tld/to=target.tld/
MattJI think they are
Kevstpeter: Do you have comment on this?
Dave CridlandFWIW, 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.
MattJProsody doesn't implement it, I'm not sure ejabberd does - M-Link and PSYC? :)
ralphmI'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
linuxwolfalso, technically, XEP-0220 is experimental
Dave CridlandMattJ, I thought someone else mentioned doing so, as well.
Dave Cridlandlinuxwolf, That's not an argument *for* changing it.
Kevralphm: No-one has implemented the spec as it stands, because it's just had the namespace changed.
stpeterdo we agree that this is a poor design?
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback'>
<errors/>
</dialback>
</stream:features>
linuxwolfheh
KevThat is - all existing implementations are incompatible with the current revision.
linuxwolfI think it is
MattJstpeter, I think so, yes
linuxwolf(a bad design)
Kevstpeter: Poor design? Yes. What's already in the wild? Probably.
ralphmKev: oh, right
stpeterbecause 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"
linuxwolfdwd: a bad design is a good reason to change it
Dave Cridlandlinuxwolf, Cool. Can we change self-framing XML, too, then?
Fritzyhaha
ralphmgets popcorn
linuxwolfis self-framing XML an experimental XEP?
stpeterand 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/>"
Kevstpeter: That is one of the two options, yes.
Dave Cridlandlinuxwolf, Proposed Standard, so technically still subject to change.
stpeterhow many beers do I need to buy for the M-Links developers to change their minds?
stpeters/Links/Link/
Dave Cridland(I'm not even sure it is bad design - at best it's inconsistent with Disco)
Kevstpeter: I'm not firmly in one camp or the other. I'd just like to see something approaching agreement.
Kev(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)
linuxwolfI 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
Kevlinuxwolf: No, that's not true.
linuxwolfit's a schema change
Dave Cridlandlinuxwolf, I don't see how you arrive at that conclusion.
Kevlinuxwolf: Adding more *the wrong way* later would lead to a schema change.
stpeteralthough bidi is not strictly a dialback thing
linuxwolfKev: that's what I'm saying
KevI'm assuming if we add more features in the future, we'll do it right.
linuxwolfSo #1 is out
KevNo.
KevWe've done it the wrong way once, they question is whether to live with it or not.
KevThere's no cause and effect between letting the (previous version) current way stand and having to do it wrong again in the future.
linuxwolfok, then my vote is to not live with it
Dave CridlandI'd be fine with <errors/> being the last thing added to dialback's stream feature.
linuxwolfbut, IMO, we have time to change this
MattJSo is mine, but only if we can track down existing implementations (I'm not sure there are many in reality)
linuxwolfI'm −1 on keeping it, unless there's a plethora of implementation that will break
KevMy preference is that we should only break namespaces when there's an incompatible change being made, really.
linuxwolfthen I'll re-evaluate (-:
ralphmwe /could/ define a real stream feature and deprecate <errors/> but I'm unsure about the actual impact
Dave Cridlandralphm, Same issue.
ralphmof course
MattJDave Cridland, are you saying you're absolutely against switching to a <dialback-errors> feature?
stpeterit'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)
linuxwolfwe're still advertising support of dialback (sans error-handling) via a namespace declaration, no?
KevI am, in any case, -1 on advancing 220 as it currently stands, so this discussion can take place on list :)
stpeterlinuxwolf: no
MattJstpeter, I agree it seems bad to have backwards-compatibility cruft in such a "recent" feature
stpeterlinuxwolf: advertisment is just via namespace on the stream header
Kev(Which, given that we've not changed 0001 yet means that -0220 has just died. Yay!).
ralphmso discussion ensues and we -1 it for now
ralphmKev: hehehe
Kev4) XEP-0262 (Use of ZRTP in Jingle RTP Sessions), advance to Draft?
ralphm☒
Dave CridlandMattJ, I am generally against changing deployed specs incompatibly for aesthetic reasons, yes.
stpeterI suppose we could say that <dialback xmlns='urn:xmpp:features:dialback'/> means you support dialback with errors and get rid of the child element
stpeterI'd be fine with that
linuxwolfstpeter: I would be ok with that
ralphmstpeter: and if you don't actually do it it doesn't break stuff
stpeterralphm: right
ralphmand the <errors/> is merely informational no-op
Dave Cridlandstpeter, I've a nagging feeling that there exist implementation advertising dialback like that but without supporting errors.
MattJIs it?
ralphmthat'd work for me
KevFolks, this discussion doesn't need to happen now.
ralphmright
KevCan we move onto (4) please.
stpeterDave Cridland: I don't know of any implementations that do it that way
linuxwolfok, let's focus!
linuxwolf#4
stpeterKev: trying to use the high bandwidth connection to reach consensus :)
stpeterbt I'll propose it on the list
KevDiscuss in 10mins once Council's over and I can start ignoring the chat :)
Kev4) XEP-0262 (Use of ZRTP in Jingle RTP Sessions), advance to Draft?
KevI haven't looked up the feedback thread yet. Will vote on-list.
linuxwolfwas there feedback? I don't remember seeing any
MattJThere wasn't feedback iirc
KevI don't remember any, but I need to find the thread to be sure :)
stpeterheh
MattJNo feedback and I'm not aware of any implementations
stpeterit is implemented in Jitsi
MattJAh good
KevOne reply, from Peter, saying that the date was wrong.
stpeterfor voice and video
linuxwolfstpeter: can you ping them to send an "a ok" or something about it, then?
stpeterI've seen it displayed at FOSDEM so it must be true
Fritzywell, that's something!
FritzyShould we ask them for feedback specifically?
KevIf there are known implementations, and no feedback to the LC, I think it's worth poking, yes.
MattJ+1
linuxwolfdefinitely
Dave CridlandIs Jitsi SIP Communicator as-was?
stpeterKev: pokage in progress
ralphm+1
MattJ(to poking)
MattJDave Cridland, yes
KevDave Cridland: Yes.
linuxwolf+1 to POKE, DNV for now
Dave CridlandAnyone else want to say yes?
MattJDave Cridland, no
KevDave Cridland: No.
KevOk, so who's volunteering to poke them for feedback?
MattJI just have
KevTa.
linuxwolfthanks
Kev5) Date of next.
MattJNext week is ok for me as far as I am aware
KevJolly good.
Fritzysame here
linuxwolfworks for me
Kevralphm?
stpeterany further votes on 178?
ralphm+1
KevI think the voting period's expired for that hasn't it? :)
Fritzyvery much so
Kev6) AOB.
linuxwolf+1 on −178
linuxwolfthought I did that on-list
ralphmany news on the summit?
Kevralphm: I think I saw a mail fly by saying it was cancelled.
stpeterlinuxwolf: I missed that
linuxwolfbut I'm getting ~200 emails/day, so it's getting lost (-:
KevAlthough I don't think I was paying much attention at the time.
stpeterlinuxwolf: man up :P
stpeterright, we haven't organized the summer summit so we'll see you all in Brussels again someday
MattJYay
stpeterso meeting next Wed?
KevYep.
stpeteradding to calendar
KevAnd we're done with 3mins to spare.
KevThanks Peter.
KevThanks all.
linuxwolfand now to the flame war
Kevbangs teh gavel.
MattJHeh
stpeterBTW if folks want to look at my i18n stuff it'd be cool