XMPP Council - 2011-07-13

T-12 minutes?

Yep.

then who have I been talking to all this time?!?!!!111!!!eleventy11!! (-:

I sign my mail either Best, /K or /K

hehe

Does that count?

heh

hi

hi Ralph!

Hi Ralph.

Hi Matt.

This meeting can't go past 11:30, or I have to run :)

Damn, it's alread 15:54 now.

Mr. EDT!

Oh well

stpeter, my watch is still in GMT :)

heh

But my schedule isn't

(-:

Dingding.

So, onwards.

1) Roll call.

I'm free!

presente

Present

:-)

2) Agenda Ba^w^whttp://www.xmpp.org/extensions/inbox/compliance2012.html Accept as XEP?

+1

+1

needs some work, clearly

stpeter: Yes, but that can be done in place.

righ

right even

+1

I think the 198 discussion is interesting. I'm actually in favour of that, despite it making neither M-Link nor Swift compliant (neither do Resume).

(I'm +1, to be clear)

3) http://www.xmpp.org/extensions/inbox/commenting.html Accept as XEP?

Kev: agreed on 198

I've asked the BuddyCloud guys to comment on this on list, because it seems like their area of expertise; I have no objection to publication at the moment.

I haven't read it in detail, but it seems sane, I'm +1

+1 also

+1 on commenting. Very interesting, although I want to go through it a with a fine comb

(we did have discussion about splitting 198 into two pieces, but Matthew convinced me that acking and resuming belong together)

stpeter: nod

I think they do.

stpeter, +1

You really want both features.

I started the discussion :)

yes

MattJ: faulty memory

4) LC on XEP-0296?

I think I'll have comments on this on-list, but I'm happy to LC it.

+1 for LC

obvious +1 from me (-:

+1

5) Date of next meeting.

should it also be in compliance?

SBTSBC?

SBTSBC++

ralphm: that's my thought…and why I'd like LC to be sooner rather than later

Kev: WFM

ralphm: Well, there's a discussion. I think it'd be worth seeing how the LC goes.

Astro: Thanks.

Kev: agreed

I think that's everyone agreed on date.

6) Any other business.

I like "Users leave comments on just about anything" :)

I liked the opening sentence.

hmm, AOB

are we closer to done on dialback?

I can incorporate the one fix from fippo and push out a new version

seems like we'd want a second LC

It's not clear to me whether fippo is now happy with it (with his fix pushed).

stpeter: /nod … unless you want to act unilaterally (-: /ducks

He's happy with little at the moment :)

it's not clear to me if fippo is ever happy ;-)

Not that this is necessarily a requirement, but I think knowing is a requirement :)

I have a broader question about dialback, though

if we have a few minutes

I don't think we've had the situation before where authors have been is such disagreement.

So how to resolve it is a little new to me.

there was one time in the distant past...

Kev: new for me, too

happiness is overrated?

hah

hehe

so

linuxwolf: Oh. A memory stirs. XHTML-IM?

the broader issue is: does this belong in the XMPP WG?

I think it might

because of the DNA/DNSSEC work

stpeter: I think that's a credible argument, at least.

good point

yes

kinda funny that we pulled it out of an RFC

so I think it might make sense to fold DNA/DNSSEC in with the dialback spec and the bidi extension

and publish it all as an RFC on XMPP S2S

ralphm: right :)

That would actually be nice

stpeter: I can see drawbacks to this.

the IETF security mafia objected to dialback years ago because "it's not secure" -- but if we use DNSSEC then in fact dialback has useful security properties

Largely that you're pushing the experimental in with the established, and it risks how you judge that implementations are compliant.

Kev: right

hmm

I would be a little reluctant to make a move that would mean we have a sum total of zero servers that implement S2S.

Nothing on the internet is "secure" :)

Kev: nod

Yeah, I don't care for the non-secure argument, we all know the trade-offs

Kev: another approach would be to do all this work at the XSF, and then eventually publish an RFC when we publish 6120 bis a few years from now

So, if the RFC route is taken, I think it's probably better to publish two - one with what we have, and one with what we want.

but splitting things across IETF and XSF feels a bit odd here

anyway

I just wanted to raise the issue

ralphm: Well, the IETF security guys *have* to complain that it's not secure, that's their purpose. What then happens is a matter for pragmatism.

there will be discussions in Quebec City about DNA/DNSSEC

it also matters what your definition of "secure" is

stpeter: I'm not opposed to the idea, at least at first glance, - just the implementation of rolling everything into one RFC.

which is hard to get them to nail down sometimes (-:

Haven't we earlier taken initial work as XEPs to then incorporate them into an RFC?

ralphm: yes indeed

ralphm: yes, privacy

I don't see how it hurts to first have a few XEPs, worked on by the same people as in the WG

the DNSSEC/DNA stuff will happen the IETF with or without us

unless there are legal issues around this

and roster versioning and so on

well, the XMPP WG is just the folks who participate

my point

the IETF is not some monolithic entity

true

well, it's not a 1:1 mapping of standard@ and xmppwg@ commenters

Kev: your point about two documents is well taken

So, what do we need to discuss about this here? Anything, or was it an airing?

Kev: as in, publish dialback-core and dna-using-dialback with a reference to dialback-core

two documents actually sounds like a good way to go…whether they're XEPs or RFCs

Can't we just have the discussion on the xmppwg mailinglist and defere standards@ to that? We have multiple different lists for specific interest areas

stpeter: Yes, with bibi probably belonging in the latter, because that's also new and exciting.

so for now I think it's fine to proceed with XEP-0220, but it would be nice to get it done

Kev: yes

and you want some level of assurance above "(non SEC) DNS lookups worked"

(for bidi)

and eventually I think we might republish 220 back at the IETF, but there's no hurry about it (could be done when we do the great republish of 6120bis, 6121bis, 6122bis, etc.)

(if we do :)

I have to cut out the meeting now to catch my train. Thanks all.

/nod

yep

ok

that's all from me

no action required

Thanks Ralph.

just an airing

I think we're done anyway :)

nice and short

So, any other any other business?

any other AOB? ;-)

No AOB

none here

not directly council related, per se (-:

Fab.

In that case, thanks all!

need to add my comments to the "Great XSF Reset" discussion

(-:

linuxwolf: I think there we may have a gift that keeps on giving.

I haven't yet read any of the messages that came in on that thread overnight

Most were me.

Kev: as long as it's not "We need a better name than XSF" again…and again…and again...

linuxwolf: Those Jabber guys are evil.

exactly

I was there, I remember :)

they should be hoisted by their own petards

(-:

Those Jabber guys *were* evil.

not sure if they've reformed since then

at least one hasn't...apparently

I think at least one raised issue is important.

There is a perception, at least from some, that Council and Board aren't doing their jobs, and we clearly need to address this.

Or, well, I assert that we need to address this.

agreed

Kev: I'll wait for your minutes before issuing a LC on 296, and I think we might need to clarify the basis for such actions, but in general I think it is acceptable for a simple majority of Council members present to make a decision to issue a Last Call (i.e., no need to wait for Fritzy to weigh in)

actually I think the Council is doing a fine job

Given that LC isn't an advancement action, per se, I think I'd buy that.

right

I think http://xmpp.org/about-xmpp/xsf/xmpp-council/policies-and-procedures/ is not quite clear on the matter

I think Council is, in some ways, doing better than it did at one point.

agreed!

I feel it's taken how ever many years it is to start to work out what the Chair should be doing, and try to start doing it.

I think if the outcome of this debate is that Board and Council become more accountable, this is a good thing.

well the Board's mandate is not as clear as the Council's, which is part of the challenge

and, for the record, I think Kev does an excellent job as Council Chair

stpeter: It's true, but it also makes it hard to not wonder if they're pulling their weight. Their mandate to be doing stuff may not be clear, but the perception that unless stuff is being done they're not meeting their mandate seems hard to counter.

Aww, thanks.

Council is almost as simple as "Are there being votes on XEPs? Please tick as appropriate".

(To judge whether the job is being done)

:)

I do think it would help to clarify what a council "vote" is

and when the two-week period applies

Yes.

e.g., perhaps that applies only to advancement, not to acceptance (0.1) or last calls

that's how I'd think of it

I would be happy with something like: Acceptance you have until the meeting to complain. Advancement you have a fortnight after the meeting.

Or something.

Although as I noted on list, if we were to do the former we'd need to not count submissions made 30seconds before the meeting.

right

we'd need all submissions to happen a week before

I do like the idea of people being able to autosubmit their stuff, and authors being able to autoupdate their Experimentals, and things.

I realise I have commit access to the repository, but I don't have access (or have access but not authority) to publish a new version.

not sure we have enough publication activity to warrant work on automated tools, although I have no objection to doing so

Setting up an email address to which you can send new versions, or a web form through which you can upload, or whatever, and have everything happen automagically sounds terribly swish.

I accept there may well be an issue of perception rather than efficacy here.

heh

the IETF has tools for that

http://datatracker.ietf.org/submit/

Right, I'm aware of it, although haven't used it.

Kev: I'd be happy to work with you, via the list or not, on revisions to http://xmpp.org/about-xmpp/xsf/xmpp-council/policies-and-procedures/

proposed revisions for review and approval by the rest of the Council, that is

Thanks. I think the best thing is probably to wait a short while for the list discussion to die down (maybe it already has, or maybe it'll errupt now those Merkin types have worken up) and see what seems prudent from that.

sure

speaking of which, I need to catch up :)

but first I need to wash my breakfast dishes, brb

Enjoy!

I'm looking forward to dinner right now ;)

OT: it's starnge that there's no equivalent for "bon appetit" in English... http://www.omniglot.com/language/phrases/bonappetit.htm

strange, even

Oh, there is, isn't there?

"Enjoy"

right

there must be some old English phrase to bring back

Right, let's see if I can get those minutes out quickly.

stpeter: Sorry, I realise I wasn't clear earlier in AOB. I'm happy with the namespacing for 220, as I said on list at the time, I'm not blocking on that.

right, I understood

I think there were no actions arising from that AOB. Is that your understanding?

yes

agreed