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

Uli M a.sporto+bee at gmail.com
Mon Jun 23 15:05:16 EDT 2008


On Fri 20.06.08 13:44, Ian Goldberg wrote:
> On Fri, Jun 20, 2008 at 05:14:52PM +0200, Jonathan Schleifer wrote:
> > Uli M <a.sporto+bee at gmail.com> wrote:
> > 
> > > And should there be a default it should be text/plain and only *one*
> > > line.  
> > 
> > I hope you mean the encrypted data and not the actual message? I
> > understand that the encrypted data should be one line, but why the
> > plaintext?
> 
> We're talking about the OTR Query message, which is not encrypted.
> It's the message that's sent to trigger the other side to start OTR (if
> it supports it).  Right now, it looks like this:
> 
>     const char *format = "?OTR%s\n<b>%s</b> has requested an "
>             "<a href=\"http://otr.cypherpunks.ca/\">Off-the-Record "
>             "private conversation</a>.  However, you do not have a plugin "
>             "to support that.\nSee <a href=\"http://otr.cypherpunks.ca/\">"
>             "http://otr.cypherpunks.ca/</a> for more information.";
> 
> But, as has been pointed out, it's (1) in English, which is bad for many
> people, and (2) it's multiple lines, which is bad for IRC (at least).

(3) it's HTML which is bad for a whole lot of people and clients.

> So I think the above will stay the default, 

Hmmmm...shouldn't a default be as compatible as possible? I agree that
English is the right choice concerning the language but wouldn't that
also imply one line and no HTML as in:

     const char *format = "?OTR%s. %s has requested an "
             "Off-the-Record private conversation. "
	     "However, you do not have a plugin "
             "to support that. See http://otr.cypherpunks.ca/ "
             "for more information.";

I think if a client detects HTML capabilities on the other end it can
easily choose the fancier message and everyone's happy. If HTML stays
the default I bet implementations capable of HTML won't change a thing
and OTR will keep its reputation for causing HTML garbage which actually
keeps people from using it. (also this is not always OTRs fault as in
that adium or libpurple bug where HTML stripping couldn't be done with
OTR on).

Uli




More information about the OTR-dev mailing list