No subject

"Hm .. ok .. the friend made a statement and asked me to post it for him (as
he isn't registered here and to lazy to do so):

"Quote:
I had a lengthy email conversation with Ian Goldberg, one of the authors of
OTR, libotr and the gaim-otr plugin. If you read the OTR spec carefully, you
will see that it specifies optional HTML-formating in the plaintext. As
OTR-messages are merely encapsulated using Jabber (or other) protocols, Ian
thinks (as do I after thinking about it) that the OTR specs supersede the
standards of "lower level" protocols such as XMPP. It is the job of an OTR
plugin to process the HTML tags in the plaintext, if they are not used by
the client it's the plugins job to strip them.
If you don't see it that way, I suggest you contact the otr-dev
mailinglist."

I think of it quite the opposite way - OTR simply encapsulates protocol
messages

OTR would have quite a job to do trying to detect whether the client
supports HTML in Miranda - there are so many messaging modules etc. And
they're likely to change at any time - it would make maintainence difficult.
I don't think tracking the client's capabilities is the plugin's job.

And I think the client should output the same *intended message* whether or
not OTR is installed - after decription, OTR messages from gaim OTR contain
formatting html, whereas without OTR gaim outputs no formatting html.  This
means transmitting more information than usual - which, although very
unlikely, may not be something that the user wants.

Removing the tags means I would have to reimlement something already
implemented by at least the AIM protocol plugin. Processing the codes
'properly' for the client could involve conversion from e.g. html to
bbcodes, if the client supports those - which would mean differences in the
nature of OTR plugins for different clients. Or further, if the OTR spec
specifies handling of HTML, then the otr library should be able to handle it
- but again that's a reimplementation of stuff that the protocol can already
do.

Also - and I really don't mean to criticize - but the protocol specs for
things like jabber and other open protocols, with their RFC's and comittees
etc etc, tend to be thought out pretty well. The reasons for disallowing
things like 'mixed contect' (from the jabber RFC) are usually pretty good.
For example, if I want to send the text <font>blue</font> to a friend, I can
do so over jabber (because it is encoded and decoded by the protocol so as
to not create 'mixed content') and expect him to get the message as I typed
it, if the client performs to the spec. With OTR, if it's removing tags on
clients that do not support markup, how does it tell the difference between
formatting tags and what the user has typed? At a minimum it would somehow
have to encode tags in message text and formatting tags differently - or you
have restricted what messages users can and can't send.

------=_Part_201152_33376833.1174578923153
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline