XMPP Council - 2012-07-11

T-12 or so.

yup..anything on the agenda?

didn't sound like it in your recent mail

Not formally, but it might be worth discussing XEP-specific discovery and negotiation methods.

ah...the 301 disco fallback discussion? ✏

yes

yes

k

heh

not posh enough

heehee

It is time.

1) Roll call.

I'm here.

presente

here

MattJ?

Present

Ralph responded, but I don't know that he has a machine capable of joining (I think he's on his phone).

stpeter: sometime after Hades actually freezes solid?

he's enjoying too much sourdough

Anyway.

Assuming no-one has anything formal to discuss.

2) Date of next meeting.

As usual?

uhm

wfm

I will be busy

OK. Week after?

that should work

OK then.

I know, because I'll be busy too in the same meeting as m&m

(-:

3) Any other business.

that'd work too

ralphm: Welcome.

present

ralphm: :)

+1 on LC 186

I have two things here - one is LC and Council, the other is designing spec-unique discovery.

Thanks.

So, for whether it matters particularly that Council don't block an LC I have mixed feelings.

On the one hand, having it held up for a fortnight while Council vote on it may be a fortnight it doesn't need to be held up, and largely for the sake of it.

I'd rather have the XEP Editor issue LC at authors' or coucil's request

On the other hand, it's difficult getting LC feedback at the best of times - if we end up calling them multiple times on specs that aren't ready but the author thinks they are I'm worried it will reduce the quality or quantity of LC feedback we get.

then we can put our objections on the list

Whereas Council are pretty much guaranteed to at least check it's in a sensible state to LC.

Kev, +1 on that

well, does it need to be the entire council that has to approve LC?

Last Call is for getting wider attention for a broader review

could it be a single council member

bah crappy connection

> [16:07:40] m&m: I'd rather have the XEP Editor issue LC at authors' or coucil's request

m&m: That probably works for me.

I'm with this I think

I don't have a strong preference, although holding it up for 2 weeks seems a bit silly -- I'd prefer if the majority of the Council can say yes or no in its meeting

and not wait for two weeks

MattJ, so each time an author request a LC the XEP Editor issues one?

I'd have thought just going with majority of Council present with no-one objecting would be fine.

poor Ralph :(

either would work for me … as long as it's not a fortnight hold on

up rather

The interesting side effect is that if the author requests an LC too early, and Council then doesn't advance it to Draft, it doesn't go back to Experimental, it gets Rejected, yay!

We should probably change that at some point.

heh

I'd be happy with just 'no objections at the next Council meeting'.

+1 on lc by editor

Kev: although I think the Council could say "you're too early, keep working on this and it will stay at Experimental for a while longer"

I don't feel /hugely/ opposed to it just being as soon as the author wants it, but I do have this concern on what it'll do to LC feedback.

Mmm

stpeter: Well, that's what the pre-LC check does at the moment, but if we follow the rules to the letter once it's in LC it has to either go to Draft or Rejected. If I remember correctly.

Anyway, this is largely pointless and we wouldn't actually do this. Probably.

I think the XEP Editor can function as a reasonable wall against obvious flaws

naturally, the XEP Editor might tell the author that they're too early and to keep polishing it further, gathering implementation feedback, etc. -- which I already do :)

m&m: Ah, so it's not "XEP Editor does it at author's request" but "XEP Editor decides when".

Which is somewhat different, and probably fine.

yes … prompted by author or council, but yes

stpeter, that'd work :)

realistically I do interact with authors a bit on that point sometimes

/nod

in any case, I think the sanity check by the Council is fine, it puts the Council on notice too etc., I just think holding it up for another 2 weeks is a bit silly :)

OK, if we're saying that Peter will issue LCs and it's his responsibility to not issue them until the XEP's ready, that's OK with me, I think.

not St. Peter … the XEP Editor (-:

Although it's not clear to me if the XEP Editor should have a stronger veto position than Council, which this effectively gives him.

Kev: I think it's better for this to be the Council's responsibility, my only complaint was the two-week holdup

OK.

I'm fine with that too

So, anyone got objections to a policy of "no objections at next meeting of Council", then?

make it majority rules without veto in the meeting and off we go

It can't be a meeting without a majority anyway, so that seems OK to me.

right

it's a quick sanity check, not a formal vote

as long as there's quorum, and the quorum does not object, it goes LC

Tobias / ralphm / MattJ?

works for me

y'all have an opportunity for a formal vote anyway :)

exactly

Yeah, it's fine

wfm

stpeter: Yes, but the formal vote comes after we've asked the community to review stuff. I'd rather keep asking that until we're prepared to accept it. If we already know we're going to reject it, LC just wastes everyone's time :)

There, now via t-mobile

OK. Given that Ralph's wet string seems to be broken, I'll assume he's happy too.

ralphm: Oooh, stable? :)

+1

Great. I don't think this needs any formal procedural changes, we'll just Do It.

ralphm: it's the 4th carrier, so no one's on it (-:

So, second point. Ad-Hoc discovery mechanisms in XEPs.

m&m: I was on the hotel network before

Triggered by the 301 discussions, of course.

m&m: and it appears particularly bad

ralphm: 4th carrier

so, ad-hoc discovery

So. My thought on this is that we should not, every time we have a new XEP that needs discovery, invent a new way of dealing with the 'we haven't got presence so can't use caps' case.

And when we have presence we just listen to caps to signal availability, and when we don't we do presence uncloaking and then use caps.

ok

(This isn't the same as negotiation, I realise - for which we have Jingle)

Oh, I thought this was implied

so yeah, maybe we need to spell this out

I still see some value in "I don't know if you can actually do this, so I'm going to just try"

just because I send presence to you does not mean you'll automatically send presence to me

301, though, I don't think needs negotiation in that way. If Peter's client does 301 I think it's fine for me to send him 301 until he says "Wait, stop!", and when he receives it his client may prompt him to ask if he wants to start sending, but there isn't a need for explicit negotiation.

m&m: Well, that's what the presence uncloaking does.

m&m: that kinda depends on the application, of course

uncloaking = http://xmpp.org/extensions/xep-0276.html

m&m: It's saying "Yes, I'm prepared to share capabilities so we can do stuff". It's not like /really/ sending presence (i.e. no roster sub).

doesn't using direct-presence in those cases fixes the problem?

although I'd like to change the name and namespace of 276 :)

Tobias: Yes, that's what presence uncloaking is.

Kev, ah..k

well, as soon as everyone (clients and servers) implement it

heh

m&m: Servers don't need to.

It's end to end.

m&m: well, almost all clients support direct presence, I'd imagine -- the uncloak stuff is just some niceties on top of directed presence

1) yes, I need to re-read -276

yes, I understand how directed presence works d-:

stpeter: I mean explicit in our specs, just changing the boilerplate

Note that I'm not suggesting we retrofit FINAL XEPs with this - but I think we need a coherent story going forwards, and neither "Send stuff without bothering to do discovery" nor "Make something up for each XEP" seems to be a good policy.

ralphm: yes

(to include a reference to 276)

note that 276 is deferred

m&m: Yes. That's not much of a barrier though :)

Kev: Even without explicit support of the namespace in 276, I don't think you actually change the workings of current FINAL XEPs with sending directed presence.

right

Kev: do we have such custom discoveries in those XEPS?

stpeter: decloaking on port bow!

yeah, I like the Trek overtones of decloak :)

ralphm: Well, -85 has custom discovery (albeit this is a legacy mostly superceded by caps) and -301 is now proposing custom discovery (and even at times advocating dropping disco altogether in favour of blindly sending), and I don't think we have a coherent story for what the Right Thing is - although lots of things are obviously wrong when we see them.

I still don't see how −276 fixes everything

301 isn't final

ralphm: Oh, I see what you meant.

No, I don't think we have Final XEPs doing custom discovery.

Kev, does doing the protocol anyway so the other side can dectect it count as custom discovery too?

m&m: It means you always know the caps of the person you're trying to talk to, and therefore know what they support.

Tobias: No, that counts as horrible :)

m&m: so maybe you can find a good counter example to discuss next meeting?

I will not have time to find such a counter example

what!

IETF

I don't think we're going to solve anything right now by the sound of it anyway, so let's call it a day.

Any other any other business for this non-meeting?

I call this a day.

I don't at this time

:)

OK, I'll take that as done.

Thanks all.

thanks

yep, good discussion

Now breakfast!

Does anyone feel that I should write minutes for the non-meeting?

(-:

It was a meeting

with good stuff to note

I think any discussion should result in minutes

OK.

just because it was all AOB doesn't mean it was not a meeting (-:

m&m: I think when there's no agenda, it pretty much does mean it's not a formal meeting, but I'm OK with producing minutes if people think it's worthwhile.

(And they do, so OK)

I move we retroactively call it a formal meeting.

there

see what I did!

seconded

(=

Kev: I think it would indeed be helpful to summarize the discovery discussion, and perhaps the process discussion as well