XMPP Council - 2013-09-18

I really want someone to comment on 152 so we can sensibly advance it.

just reading through it

Right. 'tis time, 'tis time.

yay!

Thanks for sorting out the meeting in my absense.

we try

I don't think we have anything to discuss today.

1) Roll call.

here

presente

and, actually, most of the votes are due today

Yes.

only left thing to read for me is dialback

will do so later today

We can cover those in the meeting if anyone wants to vote here.

MattJ looks here, but isn't, if mail is to be believed.

well … I have comments

Ralph is marked AFK.

Let's go through them.

2) 301?

yeah

yeah == +1?

so, I' am +1 on the intent … but there's a lot of formatting and consistency nits

+1 on that if they add the MUC allowable traffic discovery stuff, which they said they'll do

it was really annoying to me … and it very well could just be me

Tobias: That sounds like -1 pending changes to me. Isn't it?

me too

(sounds like it to mee, too)

m&m: I don't enjoy reading that one. It is much *much* better than it used to be. Really is.

Oh, I know

So I think the motivation to sort things out was there.

I had a slew of comments early on myself

/nod

like I said, it's nits

Kev, right..it's probably *that* version to draft or not and not *a fixed version* to draft, right?

things the XEP Editor would be in his/her pervue to fix

Tobias: Correct. It's "Is the XEP ready for Draft?".

Not "Might it be ready for Draft later".

if it's about *that* particular unfixed version, than i'm -1

It does raise the question of how good we want things to be before Draft. I think the MUC discovery needs to be addressed, at least.

/nod

But in general, there are other things that I'm not entirely satisfied with, but probably aren't fatal.

I'm torn on whether we should block on it until it's "Right" or not.

for /me it's mostly MUC discovery and my editorial point i raised...after that it can go to draft

the enemy of Good is Perfect

Given slippage of Draft being essentially Final these days.

m&m: Did you have any blocking comments on it, or are you +1?

before the Draft version is published, I would really like this XEP to be consistent with other XEPs

Kev: actually, we made good progress on advancing some specs to Final for a while there, and I'm happy to come up with more candidates for that progression

consistency in references

stpeter: It wasn't "Nothing goes to Final", but "People think of Draft as Final".

ah

sounds like the IETF :P

heh

m&m: Could you produce a list of these?

yes

Ta.

I kind of stopped after 4.1

So this is a -1 at teh moment from both of you anyway.

but I can pick it back up

288

+1

3) 288

+1 on 288

Much as I wanted to implement this first, because I think it's the sort of XEP that bears implementing before judging, I think I'll just have to +1 it. Time time time.

4) 220

I think we should leave this Experimental a bit longer until it's been proven in the field.

I believe Dave Cridland had implemented −288 in a previous life

Also, +1

+1 on 220

i'll send my vote for 220 later today

m&m, prosody also has an implementation...but occasional interop problems with dave's implementation

OK.

5) 152

/-:

so, I can see the utility of −152

those cusax environenments?

but it would be nice if someone that plans to implement it would comment

Tobias: possibly, yes

well...send a mail some minutes ago..but i don't plan to implemente it so... :)

I poked Emil but got no response. I really don't think we can push this through to Draft while the people who most need it aren't supporting it.

right

agreed

I think Emil was on vacation or moving or both

stpeter: Ah, OK. He's been showing up as Online to me all day.

so I'll ping him again

Thanks.

yeah, probably way behind on things :)

once I get my Linux machine I might start hacking up some features in Gajim :P

Traitor :p

heh

Long Live OS/2

Psi was supported on OS/2, incidentally.

I meant traitor for Gajim/Swift, not Linux/Mac, though.

Anyway...

Kev: I'm not getting near C++ :P

Kev: stpeter work in Python d-:

moving on …

I think both Matt and I are -1 on 152 pending someone else actually wanting to implement it.

OK

so

Is that right?

yes

do we have a requirement in XEP-0001 for implementations or expressions of desire to implement before advancing to Draft?

Kev, were implementations a requirement for draft?

I sense that we're changing XEP-0001 here

and I have a problem with that

Implementations? No.

if we want to change the criteria, we need to change XEP-0001

But if no-one comes forward saying they want it, it fails the test for being useful.

I think it is very useful for CUSAX implementations, but I'm biased

lance wants it, not?

we poked a *lot* of people off list to get feedback on the CUSAX I-D

i've used it, yes

they never posted to the lists

/-:

I can poke them all again individually off list

but it was a PITA

and I do NOT see that this is required by XEP-0001

stpeter: heh, even you noting names of people who wanted to send feedback in STOX didn't help :-)

Incidentally:

In order for a Standards Track XEP to advance from Proposed to Draft, it must: fill known gaps in XMPP technologies or deficiencies with existing protocols be clearly described and accurately documented so that it can be understood and implemented by interested and knowledgeable members of the XMPP developer community document any known security considerations with the proposed technology be generally stable and appropriate for further field experience have achieved rough consensus (though not necessarily unanimity) within the Standards SIG be formally defined by an XML schema receive the requisite votes from the XMPP Council

BUT, that said, I will poke some folks again

IMHO this might be a case of people needing it and not realizing that

I think it is fine for us to actually be ahead of implementers sometimes

I don't think it has achieved rough consensus if no-one wants to implement it (or only one person).

so that we have something ready to go

I'm happy for people to say "We need this and are going to use it for CUSAX", but only having one person saying they want it seems to fall shy of these criteria to me.

I would be happy with some people coming forward saying "I really need this"

half the specs that are Draft should never have been advanced from Experimental, then

stpeter: very likely

so we can deprecate those

in any case

and the schema contradicts the text

I will poke some more folks and see what they have to say

well, there's a technical reason to not advance it

time for the XSF board meeting in xmpp:xsf@muc.xmpp.org

see you

pedantically technical

Yeah, we're running over for a change.

6) Date of next.

oh 297?

Isn't 297 pending more changes from Matt?

That's what I'd noted in the minutes.

I thought he already made them, and that is what was published two (three?) weeks ago

I thought he had made the changes, but they had not been published

A disembodied voice says yes

Ah, OK.

Voting on that next week, then?

wfm

wfm

6) Date of next. next weke?

sure

okay

wfm (both 5 and 6)

7) AOB?

none here

I'll take that as a No.

Thanks all.

thank you

gracias

Upon reflection (and checking xep1), I don't think the whole 'we treat Draft quite like Final' is something we've tacitly accepted, I think it's what is implied by:

Note: Once an XMPP Extension Protocol has been advanced to a status of Draft, it is expected that the specification will be the basis for widespread implementation and for deployment in production environments. As a result of such implementation and deployment experience, the protocol may be subject to modification, including changes that are backwards-incompatible. Although such backwards-incompatible modifications shall be avoided if at all possible, deployment of a Draft protocol in mission-critical application may not be advisable.

That is, we're doing the Right Thing by making the move to Draft a Big Deal.

I clearly need to read the meeting logs now

I think it would be better to do that than rely on the minutes' summary.

.

.

•