[OTR-dev] Re: Requirements for libotr4

[Uli M]

On 2008-06-19, Kjell Braden <fnord at pentabarf.de> wrote:
-snip-
>> 5. "?OTR?" restarts OTR. Again a hardcoded string I would like to see
>> disappear. Because of it, it is impossible to transfer OTR
>> conversations over OTR...and also complicated to talk about OTR in an
>> OTR session...I always find myself writing "if you wanna restart OTR
>> write <question mark>OTR....". A function otr_restart would be the
>> right thing here I believe.
>
> This will probably complicated: we need something that the lib can use
> to identify it's messages, and since we don't know what kind of protocol
> will be used, it's hard to find some sort of tag that
>   a.) is protocol independent (an additional stanza in XMPP will not
> work on OSCAR/IRC/whatever)
>   b.) will never interfere with messages manually written by the user

As far as I can tell ?OTR? is used for two different things:

1. OTR initiation. I agree that you need something like ?OTR? here.
2. OTR restart. Here ?OTR? is interpreted within an ongoing OTR conversation
which I think is totally unneccessary. Here you could easily use a
protocol internal message to restart OTR. That way anything can be
transmitted over OTR, including OTR. One would only have to add a
function otr_restart() to the library.

>> 6. SMP handling. Ian said this would be reworked but it's missing in
>> the 4 points below. E.g. applications really shouldnt mess around with
>> variables that libotr touches as well (smstate->nextExpected).
>
> IMO SMP should just call a callback (or return a TLV or similar which
> can be identified by the client) from otlr_message_receiving for a SMP
> request (on TLV_SMP1*), abort (something went wrong, like
> SMP_PROG_CHEATED, or wrong TLV order) and finish (TLV_SMP[34]). The
> implementation can then check the SMProgState and display the results.

Sounds good to me.

>> 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.
>
> Sounds like a good thing to me. If I read that correctly it wouldn't
> even need work from the clients, the lib can do this on it's own.

yes, that's what I thought.

>> > *** 2. Custom message stripping function ***
- snip -

About that whole HTML discussion and also concerning previous
discussions about character encodings: I simply think it is not OTRs
business, hence functions such as HTML stripping should - if at all -
only be there for convenience.

I hope you don't mind if I refer to the OSI reference model, but in
that sense OTR is on the transport or maybe the session layer. The
presentation layer (which is above the session layer) or if absent the
application layer takes care of stuff like character encodings
and...well...presentation as in text/plain or text/html. To provide an
analogy, you wouldn't want TCP to do character set conversion or html
stripping for you either because TCP doesnt care and I believe OTR
shouldn't care either what people are transferring.  For OTR it should
be the same as for TCP: Deliver some octets from A to B, no matter
what it is. If you try to do anything else you'll run into the
problems such as those Kjell describes below.

Thanks,

Uli

>> > otrl_message_sending and otrl_message_receiving will be having an
>> extra
>> > optional argument (a callback function) to give the IMs the
>> flexibility to
>> > strip/convert the messages that are sent/received. For example, the
>> > conversion function could strip the HTML tags out of the original
>> message in
>> > order to be guaranteed an HTML-free message.
>
> I don't think the receiver should remove HTML from the message. What if
> I want to send a HTML-snippet to my friend using jabber? Currently,
> pidgin would escape the HTML tags to < and >, and proper clients
> would display those entities in plaintext, which is very bad. If we
> would implement a stripping method on the receiving side, they would
> change that back to < and >, but they would also strip anything which
> was initially in < and >. So if a proper client sends HTML tags (in
> plaintext, not intended to be formatted!) to another proper client, they
> would strip the HTML tags, which is even worse.
> 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.
>
> So that means:
>   purple-client sends text/html to gajim: gajim would convert this to
> text/plain
>   gajim sends text/plain to another gajim: no conversion necessary.
>
>
> Thanks,
> Kjell
>
> --=-GuuE5ToIrJg/sxRzeHhq
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: This is a digitally signed message part
>
>
> --=-GuuE5ToIrJg/sxRzeHhq--