[OTR-dev] Re: Requirements for libotr4

Kjell Braden fnord at pentabarf.de
Thu Jun 19 11:26:18 EDT 2008


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.



On Do, 2008-06-19 at 17:12 +0200, Jonathan Schleifer wrote:
> Ian already said that the client can specify if it's want HTML or not
> on sending and receiving. So if a non-HTML client gives a message to
> libotr, libotr will escape it and on receiving, a non-HTML client will
> get an unescaped message from libotr.

That doesn't seem to be what the initial post on this thread says: a
conversion callback passed to the message_{sending,receiving} functions.

> > The right thing to do here would be to make the sender send
> > information about what kind of message it is (maybe using MIME-Types
> > or whatever, so they would send text/html or text/plain or
> > text/x-aolrtf) and to make the receiver convert them to the right
> > format.
> 
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20080619/236d8e58/attachment.pgp>


More information about the OTR-dev mailing list