[OTR-dev] Re: Requirements for libotr4

Peter Saint-Andre stpeter at stpeter.im
Thu Jun 19 15:41:32 EDT 2008


On 06/19/2008 1:32 PM, Ian Goldberg wrote:
> 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.

Strictly speaking, it's not ICQ-in-XMPP, it's ICQ on one side of the
wormhole ^H^H^H gateway and XMPP on the other side.

> 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?

It probably returns an error. If you're lucky.

> 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

+1 to UTF-8 -- we've been using it in Jabber since 1999.

Will you support a subset of XHTML, or the whole thing? For XMPP we
defined a subset:

http://www.xmpp.org/extensions/xep-0071.html

(Basically, no <head/>, scripts, etc.)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20080619/401c7a10/attachment.bin>


More information about the OTR-dev mailing list