stpeterI seem to recall that Kev sent his regrets?
MattJHe said he might be late
MattJiirc
m&mI think so, too
stpeterah ok
m&mbut I think we can get started, and he can catch up
ralphmhas joined
MattJNow ralphm's here, +1
ralphmaloha
m&m0) Roll call
ralphmhere
MattJHere
m&mI'm here
m&mTobias?
Tobiasyup
Tobiashere
m&m1) XEP-0297: Move to draft?
MattJ+1
ralphm+1
Tobias+1
m&mThere's a typo in the intro that I'm sure the XEP Editor will fix
m&m"There are many situations is which" ...
m&mAlso, I think I agree with other sentiments that extensions MUST contain <forwarded/>, not merely SHOULD
Florobhas joined
MattJ+1 (after consideration)
m&mI'm −1 until the SHOULD is a MUST
stpeterheh
m&munless a good argument for the SHOULD?
m&m"unless there is a good argument for the SHOULD?"
MattJI can't think of oneright now
ralphmwell
m&mneeds last message correct
MattJI can't think of one right now
ralphmI had suggestions about PubSub some time, where people asked why the payload of events were embedded. If they were not, the original message might be interpretable, (like with Atom), even if PubSub wasn't.
ralphmI'm not sure if that's an argument here, though
m&mso far the embeddings of <forwarded/> provide important context
ralphmarguably, the same holds for pubsub
m&m/nod
ralphmbut there you could think of some 'see my sibling' semantics
ralphmI am just thinking aloud about this, while we can
m&mheh
Lanceas a client dev, i strongly prefer the embedded version over sibling
m&mme too
ralphmin <iq/>s it would not work anyway, as it can only have one child (not counting error)
MattJWell the XEP "strongly prefers" it already
MattJJust there might be exceptions
MattJHowever none of us can think of one :)
ralphmI'm totally ok with embedding
MattJand this SHOULD isn't even for implementations as much as future protocol developers
Kanchilm&m: http://xmpp.org/extensions/inbox/color-parameter.html:
XEP-xxxx: Data Forms - Color Field Type
MattJHow widely is XEP-0122 implemented?
m&mother than the abuse of prefixed XML that is not inline with XEP-0122, I've no objections
jabberjockewe fix that
m&mjabberjocke: thanks
ralphmok, in that case !-1
MattJI've no objections either
m&mThere are a few implementations out there … I had written a couple at one point (-:
Tobiasonly RGB support? not HSV :)
ralphmthere we go
MattJ:D
m&mnor RGBA (-:
m&mbut I don't see that as a reason to object
jabberjockeiterating is good :)
MattJ+1
m&mI can see that as blocking Draft, but that's a while off
Tobiasbut other than that i'm +1
m&mok, so Peter Waher and/or "jabberjocke" to submit an update removing the prefixes, then we should be good to accept
jabberjockem&m:blocking draft? whats that?
jabberjockeperfect
m&msee xep-0001
jabberjockeok
ralphmI have an AOB
m&m4) date of next meeting
m&mralphm: noted, and so do I
m&mSBTSBC WFM
Tobiaswfm
ralphm+1
MattJ+1
m&m5) Any other Business?
ralphmyes
MattJYes, but we don't know what it is yet
ralphmI remember we talked about coloring XEPs more prominently
ralphmaccording to their status
MattJMmm
m&mhm
ralphmlike with a side ribbon
MattJYes
ralphmwhatever happened with that?
m&mno one did the work? (-:
ralphmPeople still think we have a gazillion standards
Kev_has joined
m&mI think it's a fine idea
stpeterexactly
ralphmthere was a prototype?
stpeterI don't recall a prototype
m&mI don't remember seeing one, but that doesn't mean it didn't happen
ralphmoh, maybe I dreamt of one
stpeterwe could start an XMPP Area at the IETF and republish all the Draft/Final specs as RFCs...
ralphmDo we know of anyone we can volunteer to work on this?
m&mwell, prototypes and POCs are welcome
ralphmehm
Kev_Please Lord No.
m&mheh
m&mI would rather hold judgement on that until they support Unicode, at a minimum
Tobiasstpeter, wouldn't that be like trolling the IETF
jabberjockeuml diagrams in acsii text is a challenge
m&mI don't think the RFC XML format is any worse or better than the XEP XML format, but I think the lack of Unicode, image handling, and some other pieces is too much of a dealbreaker
stpeteranyway, enough of that :-)
m&mso, my AOB is LC for Carbons
ZashYay
m&mIt's dependent on −297, but I don't think that needs to hold up its LC
m&mit already complies with the coming changes, AFAICT
stpeteryes it would be good to finish that one off
ralphm+1
MattJ+1
m&mTobias?
Tobias+1
m&mthat leaves Kev, which will be on list
m&mok, we're seven minutes over, but we started a couple minutes late
m&munless there's anything else...
MattJNothing from me
ralphmthanks!
m&mbangs gavel
MattJThanks :)
m&mminutes to be sent presently
m&mafter I get some coffee!
waqashas joined
Tobiasthanks m&m
waqashas left
Kev_has left
Kevhas left
Florobhas left
m&mjust to clarify, is everyone (but me) +1 to advance −297?
XMPP Council - 2013-05-29