[OTR-dev] Re: Requirements for libotr4

[Ian Goldberg]

On Thu, Jun 19, 2008 at 05:26:18PM +0200, Kjell Braden wrote:
> On Do, 2008-06-19 at 17:09 +0200, Jonathan Schleifer wrote:
> > This has one problem: What if two users chat via ICQ for example and
> > both use a Jabber transport? Both would announce that they don't need
> > fragmentation, but they do. 
> 
> This does not in any way conflict with what Uli suggested before.
> 
> Alice (using XMPP) tells Bob (which is a ICQ-transport contact of Alice)
> that she needs a MMS of 1024 because of the gateway, Bob (who uses XMPP,
> but chats with Alice using the transport) answers with the same value
> and the lib saves that value in the context on both sides. The only
> necessary change would be that the max_message_size Op would need the
> context or the accountname, username and protocol for that contact.

I'm not too familiar with this concept of transporting ICQ within XMPP.

Right now, clients can tell libotr what their MMS is for any given
conversation.  You're saying that the client might not know, because
he's speaking XMPP to a gateway which converts it to ICQ?  What happens
if the gateway gets a message that's too big?

In general, determining the MSS is highly non-trivial.

> > The client would still need to handle HTML stripping then - with Ian's
> > proposal, the client would just specify it it supports HTML or not and
> > libotr will do all the rest.
> > 
> Let me clarify my proposal:
> The sending *client* (ie. user of libotr) passes the type to
> otrl_message_sending, the message and the type gets sent to the
> receiver, the receiving client passes it's requested type to
> otrl_message_receiving and otrl_message_receiving calls *something*
> (libotr internal would mean that it's not very flexible, a callback
> would mean that the implementing client would have to be *very*
> flexible) that converts the message to the requested type.

My proposal was made exactly to solve that (very inflexible) vs (forcing
clients to be too flexible) problem.  What I proposed is that clients
tell libotr what the content-type of the message is (for sending) and
what they would like out (for receiving).  If it's not a standard type,
the client needs to provide converter functions (as Willy wrote), but
only to and from one fixed, common type: UTF-8 text/xhtml.

That way, anyone can talk to anyone, and if client X supports some weird
markup method or character encoding, only it has to know about it, and
only it needs to write the converters to/from UTF-8 text/xhtml.

I think this gives exactly the right amount of flexibility: the library
is flexible, because it can support anything, and the application
doesn't have to be ridiculously flexible and accept every possible
format.

I explained my reasoning in this message:

http://www.cypherpunks.ca/pipermail/otr-dev/2008-May/000772.html


Does this clarify my thinking?  Your proposal is #2 in the
above-referenced message, and I explain there why I think #1 is better.
But API-wise, it's indeed just what you suggest: pass the type you
have/want into otrl_message_sending/receiving, and libotr will do the
conversion for you.

   - Ian