KevThe example for a new field name seems to be sane.
Kev <field var="x-{http://example.com/pubsub}time_restrictions" type="text-multi"
label="Limit to these time ranges">
KevThat seems reasonable.
stpeterlooks
KevBut 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.
KevOf course, my paste has the strikout x- as well as the added namespaceish stuff, which doesn't paste into here.
ralphmhehe
stpeteryou're talking about http://xmpp.org/extensions/tmp/xep-0068-1.2.html#example-2
KevI am.
KevThe example seems entirely sane - I'm suggesting we include text to match.
linuxwolfKev: There's also section 3.3, with SHOULDs (not MUSTs) around what the naming conventions
Kev(Or you tell me there is text to match and I can't see it)
Kevlinuxwolf: 3.4, don't you mean?
linuxwolfd'oh
linuxwolfyeah
linuxwolfand it's not enough
linuxwolfmaybe
stpeterI'd be fine with recommending Clark notation
stpeterall that 3.4 says is "If the FORM_TYPE is not registered, the field MAY have any name (managed by the namespace owner)."
KevRight.
stpeterwhich admittedly is rather weak :)
KevI think we should namespace it somehow.
linuxwolfI'm still +1 to the current, but would not object to further specificity
KevClark notation, as in the example, seems right to me.
KevOr sensible, at least, I'm not opposed to other sensible options.
linuxwolfWe're XML, so Clark notation seems the best fit, IMO
ralphmagreed
ralphmI'm not sure if that need to be a MUST
ralphmbut clearly we should at least strongly recommend that custom fields do this
linuxwolfhowever, I don't want everyone that followed XEP-68 < 1.2 to feel obligated to change their code
KevI'm happy with MUST be clearly namespaced, SHOULD use Clark notation, legacy implementations MAY use the obsolete x- notation.
KevWould that suit everyone else?
ralphmI'd be in favor of MUSTing the notation
Tobiasfine with me
linuxwolfI think so
stpeterKev: this is for forms where the FORM_TYPE is registered with the XSF, or also for forms where the FORM_TYPE is unregistered?
Kevralphm: I'm not opposed to MUST use Clark *except* existing x- implementations.
linuxwolfstpeter: both, no?
Kevstpeter: I think for all forms, because I can non-XSF a form and you can extend it non-XSF.
stpeterSection 3.4 is a bit ambiguous about naming in the context of forms where the FORM_TYPE is registered
stpeterI think we kind of assume that the field "namespace" is inherited from the FORM_TYPE
ralphmstpeter: that
KevI'm happy with text along the lines of 'extending forms outside your namespace requires...'.
linuxwolfthat
KevI think that's the critical thing. If it's not your form, you have to namespace your changes.
stpeterso why have a FORM_TYPE of "http://example.com/foo" and then field names of {http://example.com/foo}bar" ?
ralphmit is rather unfortunate that we also have these pubsub# and muc# prefixes, but yeah, leaving off {...} assumes the form namespace
Kevstpeter: See above :)
stpeterralphm: indeed -- I have no idea why we thought that was a good idea :)
stpeterKev: ok, yes
ralphmso must use clark except for legacy apps using x-
stpeterright
ralphm+1 then
stpeterI will formulate some text and then run it by the list
KevI suggest that instead of pre-approving rc3, we discuss again next week/week after.
KevJust because we've discussed a number of approaches and the possibility for miscommunication is high.
stpeternot quite up for wordsmithing the text here :)
stpeterWFM
stpeterright
stpeteragreed
KevSo I think we're done with this.
Kev3) Date of next meeting.
Tobiasyup
KevI don't believe I can make next week at the normal time.
ralphm+1W
KevYou folks could go on without me, or we can reschedule, or miss a week.
ralphmgiven the amount of work, skipping a week seems fine
KevAnyone else?
MattJwfm
Tobiaswfm
MattJis ~50% here
linuxwolfI'm ambivalent (-:
Kevlinuxwolf: ambivalent, or disinterested?
ralphmlinuxwolf: we can still hang out here next week
stpeterI'll post to standards@ about the x- changes
KevThanks.
ralphmstpeter: I think we should mention that {http://jabber.org/protocol/pubsub#subscribe_authorization}pubsub#subscriber_jid is equivalent to pubsub#subscriber_jid
ralphmalso, example 168 of XEP-0060 has a typo for that field name
ralphmand example 2 in your draft of 0068 has an incorrect FORM_TYPE
ralphm(i.e. it lacks the #subscribe_authorization part)
stpeterok, will check those when I get to the office, gotta run!
XMPP Council - 2012-05-09