I 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.
ralphm
I'm not sure if that's an argument here, though
m&m
so far the embeddings of <forwarded/> provide important context
ralphm
arguably, the same holds for pubsub
m&m
/nod
ralphm
but there you could think of some 'see my sibling' semantics
ralphm
I am just thinking aloud about this, while we can
m&m
heh
Lance
as a client dev, i strongly prefer the embedded version over sibling
m&m
me too
ralphm
in <iq/>s it would not work anyway, as it can only have one child (not counting error)
MattJ
Well the XEP "strongly prefers" it already
MattJ
Just there might be exceptions
MattJ
However none of us can think of one :)
ralphm
I'm totally ok with embedding
MattJ
and this SHOULD isn't even for implementations as much as future protocol developers
m&m: http://xmpp.org/extensions/inbox/color-parameter.html:
XEP-xxxx: Data Forms - Color Field Type
MattJ
How widely is XEP-0122 implemented?
m&m
other than the abuse of prefixed XML that is not inline with XEP-0122, I've no objections
jabberjocke
we fix that
m&m
jabberjocke: thanks
ralphm
ok, in that case !-1
MattJ
I've no objections either
m&m
There are a few implementations out there … I had written a couple at one point (-:
Tobias
only RGB support? not HSV :)
ralphm
there we go
MattJ
:D
m&m
nor RGBA (-:
m&m
but I don't see that as a reason to object
jabberjocke
iterating is good :)
MattJ
+1
m&m
I can see that as blocking Draft, but that's a while off
Tobias
but other than that i'm +1
m&m
ok, so Peter Waher and/or "jabberjocke" to submit an update removing the prefixes, then we should be good to accept
jabberjocke
m&m:blocking draft? whats that?
jabberjocke
perfect
m&m
see xep-0001
jabberjocke
ok
ralphm
I have an AOB
m&m
4) date of next meeting
m&m
ralphm: noted, and so do I
m&m
SBTSBC WFM
Tobias
wfm
ralphm
+1
MattJ
+1
m&m
5) Any other Business?
ralphm
yes
MattJ
Yes, but we don't know what it is yet
ralphm
I remember we talked about coloring XEPs more prominently
ralphm
according to their status
MattJ
Mmm
m&m
hm
ralphm
like with a side ribbon
MattJ
Yes
ralphm
whatever happened with that?
m&m
no one did the work? (-:
ralphm
People still think we have a gazillion standards
Kev_has joined
m&m
I think it's a fine idea
stpeter
exactly
ralphm
there was a prototype?
stpeter
I don't recall a prototype
m&m
I don't remember seeing one, but that doesn't mean it didn't happen
ralphm
oh, maybe I dreamt of one
stpeter
we could start an XMPP Area at the IETF and republish all the Draft/Final specs as RFCs...
ralphm
Do we know of anyone we can volunteer to work on this?
m&m
well, prototypes and POCs are welcome
ralphm
ehm
Kev_
Please Lord No.
m&m
heh
m&m
I would rather hold judgement on that until they support Unicode, at a minimum
Tobias
stpeter, wouldn't that be like trolling the IETF
jabberjocke
uml diagrams in acsii text is a challenge
m&m
I 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
stpeter
anyway, enough of that :-)
m&m
so, my AOB is LC for Carbons
Zash
Yay
m&m
It's dependent on −297, but I don't think that needs to hold up its LC
m&m
it already complies with the coming changes, AFAICT
stpeter
yes it would be good to finish that one off
ralphm
+1
MattJ
+1
m&m
Tobias?
Tobias
+1
m&m
that leaves Kev, which will be on list
m&m
ok, we're seven minutes over, but we started a couple minutes late
m&m
unless there's anything else...
MattJ
Nothing from me
ralphm
thanks!
m&mbangs gavel
MattJ
Thanks :)
m&m
minutes to be sent presently
m&m
after I get some coffee!
waqashas joined
Tobias
thanks m&m
waqashas left
Kev_has left
Kevhas left
Florobhas left
m&m
just to clarify, is everyone (but me) +1 to advance −297?