[Standards] XEP-0115 is harmful and should be deferred

Joe Hildebrand 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
> either
> 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
> a
> 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
> message,
> the flood will probably be even larger than the original disco flood! :-D
>
> ...
> > Which basically brings us back to XEP-0115. :)
>
> Indeed.
>
> 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
> phone.
>      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."
>
> Daniel
>


-- 
Joe Hildebrand



More information about the Standards mailing list