KevI can only come up with contrived examples, at first glance.
m&msuch as end-to-end encryptkon
m&mencryption
m&mwhich I need to add to the draft
KevI'm +1 too.
Kev4) Date of next meeting
MattJI'm starting to feel obligated to anticipate all the horrible ways people might use XEPs I write and include "Please don't do this" requests
KevNext Wednesday, 1600UTC?
m&mKev: +1
MattJwfm
Tobiaswfm
m&mMattJ: the only solution is to not write XEPs (-:
KevMarvellous. Board have timed their meetings to be weekly, immediately subsequent to Council this year, which is convenient if anyone wants to drop in and heckle.
MattJEasier said than done
KevOh, no, it's quite easy.
MattJKev, yes, that's a great idea
KevYou just join the MUC and make irrelevant comments.
MattJThey're still in xsf@?
Kev...oh, you didn't mean that :D
KevYes.
m&m(-:
Kev5) Any other business
KevI'll do my now traditional "Anything anyone wants to change about the way Council is chaired/run this year?" question.
m&m*crickets*
Zash_̎
MattJIt's been pretty ok with me, except when meeting times change, or when I think they have, but they haven't really
KevI've now, I hope, passed the ludicrously busy spell I had the last couple of months. I've not had to go on site for multiple weeks in a row \o/.
m&mheh
KevOK.
KevAny other any other business?
MattJNot here
m&mnay
Tobiasnope
m&mignores that jay-son thingie
KevMarvellous. Despite a delayed start, 4 minutes to spare.
Kevbangs the gavel.
MattJAny informal comments on the jay-son thingie? I fully intend to submit it otherwise :)
KevThanks all :)
MattJThanks Kev
KevMattJ: I think it's a bit nasty, and likely to cause pain, but it's something there's a (perceived) requirement for, so who am I to judge?
MattJWhat pain might it cause? and what (if anything) can be done to prevent it?
m&mMattJ: to be frank, I almost no benefit to it … you still need context
MattJI can't be the only person who thinks JSON in <body/> is evil
m&mI think that's evil also, but I also don't see a point to a single wrapper for all cases of JSON
m&mguidelines for how one mixes in JSON to XMPP, sure
m&ma single container … no
KevMattJ: I don't think that specification for including JSON causes pain, particularly. More that mixing content types like that doesn't seem to buy very much, and JSON isn't all that great for things that need interop and extensibility etc., and ...
Kevm&m: This is true, but at least for the way Swift does parsing/serialising, having all json always in the same wrapper element (which is then within a context element) would be convenient.
Kev*Swiften
KevSo I'm not particularly opposed to saying "If your protocol is shipping JSON, shove it inside <this> element, within your own namespaced element.
KevAs example 2 does in MattJ's spec.
MattJRight
ZashCompare to 297 and xhtml-im
MattJThat's pretty much exactly what it's intended for
m&mfrankly, I'd only be ok if it always had to be wrapped by something else
KevMattJ: So I think maybe example 1 should go.
Kev^5s m&m
MattJI'm ok with that
m&min fact, I'm not sure 297 should be present without somehting wrapping it
m&msomething even
Kevm&m: 297 does have a use case for this, which is that sometimes you really do just want to forward a message as a real forward.
MattJBut many closed "XMPP as middleware" do already do the JSON-in-body hack, I've seen it in multiple places now, and I wince every time
MattJThe "context" there is the sender and recipient
m&mMattJ: I'm not saying it won't happen
MattJI agree that's not pretty, but it's reality
KevMattJ: Where interop isn't required, I don't really much care what people do :)
MattJI do, or they might as well not be using XMPP :)
KevYou can encode stuff in a message body for all I care as long as it doesn't reach anyone else's system :)
MattJand I see this as a step up from what they do now
MattJI've had to interface with such systems :(
KevAs soon as you need to interface with them, interop's required.
KevAnd it starts being clearly wrong :)
MattJSo, happy with a "SHOULD" be inside another element?
MattJI think that sounds good to me
m&mI'm happy with a MUST
MattJHeh
KevTBH, I don't see much of an argument to not say MUST, although hills, etc.
KevIn as much as anyone who's going to ignore it is going to ignore the XEP completely.
MattJRight
m&mplants flag, burns bridge that lets me down
MattJBut they can be coaxed in the right direction
KevThey're not going to say "Oh, well, I'm happy to put it in this wrapper element, but my own namespace? That's just a bridge too far, melad"
MattJThat's mostly the intention
KevThey'll either swallow it and do the right thing, or ignore everything the spec says completely :)
KevSo you may as well say MUST do the right thing.
XMPP Council - 2012-11-21