[Standards] XEP-0115 is harmful and should be deferred
hildjj at gmail.com
Fri Jul 6 15:46:44 UTC 2007
Your solution does not allow the sending clint to disable the
formatting options, keeping the user from wasting time with formatting
that will never be received.
On 7/6/07, Daniel Noll <daniel at noll.id.au> wrote:
> On Friday 06 July 2007 08:31, Rachel Blackman wrote:
> > It's useful to know whether or not another client supports XHTML-IM
> > before you send them a large packet filled with both plaintext and
> > XHTML data. (Especially for the oft-cited case of mobile folks who
> > pay by the megabyte.)
> This particular problem has a more elegant solution that works without
> end needing to know what the other supports.
> 1. Client running on the mobile somehow asks the server to strip XHTML
> bodies out of messages.
> 2. Client running on the mobile simply doesn't send XHTML.
> Problem solved without caps. And interestingly, this solves another case of
> naive client which doesn't even check if the recipient supports XHTML bodies
> before sending XHTML. :-)
> > Further, in order for PEP to work for capabilities, you'd really need
> > to /require/ every client to publish their disco capabilities as a
> > PEP item, and also require everyone to subscribe to that item for all
> > those on their roster. That's a heavy set of requirements just to
> > discover support for file transfer or formatted text! Plus, it
> > generates a lot of text; no matter how many people on your list use
> > 'Pidgin 2.0' you will get the entire disco result for each of them as
> > they log on.
> And ironically due to the size of the XML which wraps around a pubsub
> the flood will probably be even larger than the original disco flood! :-D
> > Which basically brings us back to XEP-0115. :)
> But mobile client users and authors are still going to object to receiving
> data they didn't ask for, especially if it's the same size as what was
> already being sent in the presence. :-)
> The way I see it, they have two options.
> 1. A gateway that strips it out. Not a bad idea as it can strip out loads
> of other things they don't need. Like, oddly enough, XHTML bodies from
> clients which didn't check the caps beforehand. ;-) Or perhaps even
> messages and presence from people they don't want to come to their
> Or, maybe it even reduces the stream to a much more compact binary
> protocol with less extensibility.
> 2. We add some kind of opt-out <iq/> that you send before becoming
> available, which says "no caps, please."
More information about the Standards