mathieui at mathieui.net
Fri Dec 19 20:31:08 UTC 2014
On Fri, Dec 19, 2014 at 02:51:02PM -0500, Sam Whited wrote:
> On 12/17/2014 11:46 AM, Winfried Tilanus wrote:
> > In response to my comment that it left a lot of information
> > unencrypted he suggested to start a second OTR protocol in XMPP, one
> > that does proper service discovery and properly encrypts everything
> > of the stanzas that should be encrypted. Optionally embedding the
> > plain version within it when you need to transverse to an other
> > protocol.
> Agreed (that there should be an XMPP flavor of OTR); I'm not so sure
> that embedding the plain version within the XMPP discovered version
> would be helpful, this sounds like an edge case that won't often happen
> in 'real life' to me.
> One of the major problems with XMPP in general as I see it, is that
> extensions try to cover too many little edge cases that aren't ever
> likely to arrise and be a "one size fits all" solution. This leads to
> them being difficult to implement properly, which leads to
> incompatibilities and fragmentation among clients.
> Keeping things simple, and straightforward is the way to go IMO,
> especially in a security sensitive environment.
> That being said, embedding the normal OTR exchange isn't that
> complicatedm it just seems unnecessary to me; sorry, got a little
> sidetracked there.
> > Well... I think the first step should be documenting the most common
> > case, OTR'ing the content of a message in the OTR way....
> Also agreed. Let's pump out a basic informational XEP that describes the
> state of OTR today, and in the mean time we can be discussing how we
> want to expand it in future.
Once the work is started, it might be useful to eventually move (or
share) the discussions to otr-dev  in order to have relevant feedback.
P.S.: I would love to have a standardized OTR where I don't have to
guess if the message is an HTML4 mess or plain text, something
the original OTR spec does not provide.
mathieui (poezio developer)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Standards