[OTR-dev] Re: Re: Requirements for libotr4

[Uli M]

On Thu 19.06.08 17:09, Jonathan Schleifer wrote:
> Uli M <a.sporto+bee at gmail.com> wrote:
> 
> > 7. Maximum message size handshake. Currently, each end uses its own
> > MMS. This is a bad thing if you use something like jabber transports
> > because the jabber end will likely have a too large MMS for the other
> > end (ICQ,...). For irssi-otr it's always a problem in conjunction with
> > bitlbee since IRC has a limit of about 500 and the other end might be
> > playing with 2k. The only reason why this currently works at all is
> > because OTR messages (except the 'better' msg under 4.) start with
> > "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr.
> > The solution is simple: Each end advertises its own MSS during the
> > initial handshake and both use the minimum of the two.
> 
> 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.

The jabber clients are probably aware that their contact uses an ICQ
transport, so they know better and should announce that they need
fragmentation.

If you assume that the clients themselves don't know the appropriate MMS
you need more elaborate schemes to determine it (e.g. measuring
it). But I think that's not the case with jabber transports and I can't
think of any other setting where this applies. Therefore, using the
smaller of the two maximum message sizes should cover all cases.

> We would need some way to define what we support *PER CONTACT*. So the
> client could for example limit it's own capability if it knows it's a
> gateway contact and announce that it needs fragmentation.

That is already the case. MMS is checked per context in
otrl_message_fragment_and_send:

int (*max_message_size)(void *opdata, ConnContext *context);

I didn't see any caching for this in libotr so applications can freely
choose the MMS for each context.

Uli