MattJ: your JSON specification reference is incorrect (-:
MattJ
Oh?
MattJ
Oh.
m&m
depending on which standards body you talk to, its either RFC 4627 or ECMA-404
MattJ
Yeah, I can fix it to point to the RFC
ralphm
Not objecting to publish as a XEP.
m&m
4627bis is in progress
stpeter
heh
Tobias
or define a new standard...not only Base64 can have tons of standards
m&m
no objections to publishing, but not terribly excited about it either
m&m
MattJ: Oh, and specication
Kev
So, I don't really understand half of this.
ralphm
m&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.
stpeter
I could definitely see people using JSON containers
Kev
Shoving it in other protocol namespaces: Understood. Shoving it directly into messages: not understood.
ralphm
https://news.ycombinator.com/item?id=6520524
MattJ
People *already* shove JSON into <body/>
Kev
MattJ: Not in standards, though.
ralphm
*that* is horrible
MattJ
I have had to deal with such "APIs" in the past
stpeter
heh
stpeter
yeah
m&m
I agree with Kev
stpeter
let's at least make it clean
Kev
If we're telling people how do Do This Right, why not say "And always namespace it according to use"?
waqashas joined
MattJ
SHOULD?
m&m
why not MUST?
stpeter
nod, the pure message stuff seems strange, IMHO it usually needs some context
ralphm
Kev: my motivation to accept this is along the same lines as the other payload format XEPs (User Mood, etc)
MattJ
m&m, the context may be provided elsewhere
ralphm
I'm not to keen on direct embedding in messages like this
ralphm
More interested in the pubsub use
MattJ
Ok, happy to amend it then
m&m
MattJ: I don't think it will kill them to re-iterate the context
Kev
I'm happy to accept 0.0.2 as experimental, which says to use contexts.
m&m
this isn't alg:none bad, but I'm not keen on it
ralphm
that said, I know some developers have embedded Atom entries in messages as well
MattJ
If people continue to use JSON in <body/>, I'll mark the date this was decided :)
ralphm
arguably without context
Kev
MattJ: If people continue to use <body/>, then demanding context isn't going to be what stops them.
m&m
MattJ: people put all sorts of things into <body/> — that doesn't make them correct
ralphm
and I have gotten suggested if we could do something where you'd have the pubsub notification meta data *next to* the payload
Kev
The spec already says 'shove it in the json namespace'. I don't see "shove the json namespace somewhere relevant" as any harder.
stpeter
hmm
MattJ
It's also more about defining the json element, than dictating what you do with it
ralphm
Kev: I suppose you can supply context with a sibling element
ralphm
it doesn't have to be wrapping it
Kev
ralphm: Using siblings for context is pretty ugly, though.
MattJ
I don't see why we need rules about where it MUST NOT be embedded
stpeter
well, 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
Kev
I have a preference for MUST put it in a context, I'll settle for SHOULD and form a concrete opinion before Draft.
Kev
Or new Council can, rather.
stpeternods to Kev
m&m
wfm
MattJ
I'm ok for compromising to SHOULD
stpeter
rough consensus! ;-)
MattJ
:)
ralphm
yay
Kev
OK.
ralphm
and we have another XEP
ralphm
:-D
MattJ
I'll update it ASAP
Kev
ralphm: I don't think we have a Tobias opinion yet.
Kev
At least, I can't find it.
m&m
MattJ: don't forget to change the namespace to end with ":0" instead of ":tmp"
Zash
... Mam
Tobias
Kev, i'm fine with SHOULD for now too
m&m
Kev: we're still pending MattJ's update, though
Kev
m&m: I'm happy to pre-approve this one.
Kev
But I'm not pushing anyone else to do so.
ralphm
m&m: I strongly believe in publish, then discuss details
m&m
I've already stated non-objection
Kev
I 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)
ralphm
m&m: right
Kev
Ok, so everyone is non-objecting the pending 0.0.2?
m&m
as long as something doesn't smell like duplication (without justification) or have very obvious flaws, I don't object
MattJ
Yay
ralphm
Kev: I think I've seen no objections from everyone(!)
Kev
OK.
Kev
3) Date of next.
Kev
I think we're saying that this was our last meeting.
m&m
it sounds like "none"
m&m
/agreed
Tobias
wfm
Kev
In which case
Kev
4) Ta.
MattJ
ok, me too
ralphm
Thanks all!
Kev
I'd like to thank everyone for their work this year.
MattJ
++
Tobias
thank you
ralphm
You've been a pleasure to work with.
Kev
5) Any other business
Tobias
Kev, thanks for chairing
m&m
gracias
ralphm
+1
Zash
Thanks yall
m&m
I've decided not to run again
Kev
m&m: You can always come back later, you've done it before :)
ralphm
:-D
m&m
I've struggled to keep up as it is (-:
Tobias
and for those reappliers, there are a couple days left to put yourself on the wiki page
m&m
but I also think it would be best for there to be new blood
MattJ
After swinging to and fro for a while, I finally decided to run again
Kev
I think we're guaranteed at least some new blood next year then, and yes, I agree this is healthy.