m&mMattJ: your JSON specification reference is incorrect (-:
MattJOh?
MattJOh.
m&mdepending on which standards body you talk to, its either RFC 4627 or ECMA-404
MattJYeah, I can fix it to point to the RFC
ralphmNot objecting to publish as a XEP.
m&m4627bis is in progress
stpeterheh
Tobiasor define a new standard...not only Base64 can have tons of standards
m&mno objections to publishing, but not terribly excited about it either
m&mMattJ: Oh, and specication
KevSo, I don't really understand half of this.
ralphmm&m: I've been promoting this idea before, wasn't aware that MattJ had written this spec (or I forgot) and Justin Karneges has just published an article about doing the same.
stpeterI could definitely see people using JSON containers
KevShoving it in other protocol namespaces: Understood. Shoving it directly into messages: not understood.
MattJI have had to deal with such "APIs" in the past
stpeterheh
stpeteryeah
m&mI agree with Kev
stpeterlet's at least make it clean
KevIf we're telling people how do Do This Right, why not say "And always namespace it according to use"?
waqashas joined
MattJSHOULD?
m&mwhy not MUST?
stpeternod, the pure message stuff seems strange, IMHO it usually needs some context
ralphmKev: my motivation to accept this is along the same lines as the other payload format XEPs (User Mood, etc)
MattJm&m, the context may be provided elsewhere
ralphmI'm not to keen on direct embedding in messages like this
ralphmMore interested in the pubsub use
MattJOk, happy to amend it then
m&mMattJ: I don't think it will kill them to re-iterate the context
KevI'm happy to accept 0.0.2 as experimental, which says to use contexts.
m&mthis isn't alg:none bad, but I'm not keen on it
ralphmthat said, I know some developers have embedded Atom entries in messages as well
MattJIf people continue to use JSON in <body/>, I'll mark the date this was decided :)
ralphmarguably without context
KevMattJ: If people continue to use <body/>, then demanding context isn't going to be what stops them.
m&mMattJ: people put all sorts of things into <body/> — that doesn't make them correct
ralphmand I have gotten suggested if we could do something where you'd have the pubsub notification meta data *next to* the payload
KevThe spec already says 'shove it in the json namespace'. I don't see "shove the json namespace somewhere relevant" as any harder.
stpeterhmm
MattJIt's also more about defining the json element, than dictating what you do with it
ralphmKev: I suppose you can supply context with a sibling element
ralphmit doesn't have to be wrapping it
Kevralphm: Using siblings for context is pretty ugly, though.
MattJI don't see why we need rules about where it MUST NOT be embedded
stpeterwell, I could see that people would know the context from the application they've developed (closed network kind of thing), and entities just pass around json blobs to their heart's content
KevI have a preference for MUST put it in a context, I'll settle for SHOULD and form a concrete opinion before Draft.
KevOr new Council can, rather.
stpeternods to Kev
m&mwfm
MattJI'm ok for compromising to SHOULD
stpeterrough consensus! ;-)
MattJ:)
ralphmyay
KevOK.
ralphmand we have another XEP
ralphm:-D
MattJI'll update it ASAP
Kevralphm: I don't think we have a Tobias opinion yet.
KevAt least, I can't find it.
m&mMattJ: don't forget to change the namespace to end with ":0" instead of ":tmp"
Zash... Mam
TobiasKev, i'm fine with SHOULD for now too
m&mKev: we're still pending MattJ's update, though
Kevm&m: I'm happy to pre-approve this one.
KevBut I'm not pushing anyone else to do so.
ralphmm&m: I strongly believe in publish, then discuss details
m&mI've already stated non-objection
KevI think this is our last meeting, so I think we're punting for next Council if we don't decide today.
Kev(Not that this is a problem)
ralphmm&m: right
KevOk, so everyone is non-objecting the pending 0.0.2?
m&mas long as something doesn't smell like duplication (without justification) or have very obvious flaws, I don't object
MattJYay
ralphmKev: I think I've seen no objections from everyone(!)
KevOK.
Kev3) Date of next.
KevI think we're saying that this was our last meeting.
m&mit sounds like "none"
m&m/agreed
Tobiaswfm
KevIn which case
Kev4) Ta.
MattJok, me too
ralphmThanks all!
KevI'd like to thank everyone for their work this year.
MattJ++
Tobiasthank you
ralphmYou've been a pleasure to work with.
Kev5) Any other business
TobiasKev, thanks for chairing
m&mgracias
ralphm+1
ZashThanks yall
m&mI've decided not to run again
Kevm&m: You can always come back later, you've done it before :)
ralphm:-D
m&mI've struggled to keep up as it is (-:
Tobiasand for those reappliers, there are a couple days left to put yourself on the wiki page
m&mbut I also think it would be best for there to be new blood
MattJAfter swinging to and fro for a while, I finally decided to run again
KevI think we're guaranteed at least some new blood next year then, and yes, I agree this is healthy.
XMPP Council - 2013-10-09