XMPP Council - 2012-05-09

~1 hour.

~5 min

hi

It is time.

1) Roll call

I be here.

presente

tadaaah

/me2

MattJ: Ping.

Pong

Present

http://xmpp.org/extensions/diff/api/xep/0068/diff/1.1/vs/1.2rc2

2) http://xmpp.org/extensions/diff/api/xep/0068/diff/1.1/vs/1.2rc2 Accept 1.2

Rather.

+1

+1

+1

I'm almost +1.

The example for a new field name seems to be sane.

<field var="x-{http://example.com/pubsub}time_restrictions" type="text-multi" label="Limit to these time ranges">

That seems reasonable.

But AFAICS from the diff, we're just removing an obligation on people making new values to put x- on them, and I think we should encourage them to namespace themsomehow as bove, instead.

Of course, my paste has the strikout x- as well as the added namespaceish stuff, which doesn't paste into here.

hehe

you're talking about http://xmpp.org/extensions/tmp/xep-0068-1.2.html#example-2

I am.

The example seems entirely sane - I'm suggesting we include text to match.

Kev: There's also section 3.3, with SHOULDs (not MUSTs) around what the naming conventions

(Or you tell me there is text to match and I can't see it)

linuxwolf: 3.4, don't you mean?

d'oh

yeah

and it's not enough

maybe

I'd be fine with recommending Clark notation

all that 3.4 says is "If the FORM_TYPE is not registered, the field MAY have any name (managed by the namespace owner)."

Right.

which admittedly is rather weak :)

I think we should namespace it somehow.

I'm still +1 to the current, but would not object to further specificity

Clark notation, as in the example, seems right to me.

Or sensible, at least, I'm not opposed to other sensible options.

We're XML, so Clark notation seems the best fit, IMO

agreed

I'm not sure if that need to be a MUST

but clearly we should at least strongly recommend that custom fields do this

however, I don't want everyone that followed XEP-68 < 1.2 to feel obligated to change their code

I'm happy with MUST be clearly namespaced, SHOULD use Clark notation, legacy implementations MAY use the obsolete x- notation.

Would that suit everyone else?

I'd be in favor of MUSTing the notation

fine with me

I think so

Kev: this is for forms where the FORM_TYPE is registered with the XSF, or also for forms where the FORM_TYPE is unregistered?

ralphm: I'm not opposed to MUST use Clark *except* existing x- implementations.

stpeter: both, no?

stpeter: I think for all forms, because I can non-XSF a form and you can extend it non-XSF.

Section 3.4 is a bit ambiguous about naming in the context of forms where the FORM_TYPE is registered

I think we kind of assume that the field "namespace" is inherited from the FORM_TYPE

stpeter: that

I'm happy with text along the lines of 'extending forms outside your namespace requires...'.

that

I think that's the critical thing. If it's not your form, you have to namespace your changes.

so why have a FORM_TYPE of "http://example.com/foo" and then field names of {http://example.com/foo}bar" ?

it is rather unfortunate that we also have these pubsub# and muc# prefixes, but yeah, leaving off {...} assumes the form namespace

stpeter: See above :)

ralphm: indeed -- I have no idea why we thought that was a good idea :)

Kev: ok, yes

so must use clark except for legacy apps using x-

right

+1 then

I will formulate some text and then run it by the list

I suggest that instead of pre-approving rc3, we discuss again next week/week after.

Just because we've discussed a number of approaches and the possibility for miscommunication is high.

not quite up for wordsmithing the text here :)

WFM

right

agreed

So I think we're done with this.

3) Date of next meeting.

yup

I don't believe I can make next week at the normal time.

+1W

You folks could go on without me, or we can reschedule, or miss a week.

given the amount of work, skipping a week seems fine

Anyone else?

wfm

wfm

I'm ambivalent (-:

linuxwolf: ambivalent, or disinterested?

linuxwolf: we can still hang out here next week

Anyway, a fortnight now seems vaguely agreed.

4) Any other business?

ralphm: (-:

no other business

Right, I think we're done.

Thanks all.

thanks

ok

I've provisionally updated 68

http://xmpp.org/extensions/tmp/xep-0068-1.2.html#approach-fieldnames

I need to heaad into the office, bbiab

I'll post to standards@ about the x- changes

Thanks.

stpeter: I think we should mention that {http://jabber.org/protocol/pubsub#subscribe_authorization}pubsub#subscriber_jid is equivalent to pubsub#subscriber_jid

also, example 168 of XEP-0060 has a typo for that field name

and example 2 in your draft of 0068 has an incorrect FORM_TYPE

(i.e. it lacks the #subscribe_authorization part)

ok, will check those when I get to the office, gotta run!