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

[Daniel Noll]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20070706/4c5a8729/attachment.pgp