[OTR-dev] OTR version 4 Draft

[Ola Bini]

Hi Ivan,

> I agree with Paul here, using "OTRv4" for protocol name that is not
> actually an OTR one is a bit confusing. If you have plans for "merging"
I'm not sure I understand your point. The specification is aiming to
be the new OTR version - and in fact, if it doesn't end up being that
we have failed, and the specification should not be used.

> this spec upstream it's better to go under some temporal codename for
> it. It will prevent situations like "Do you mean OTRv4 by STRIKE or
> official one?"/"I read official specs and going to use OTRv4
> implementation by STRIKE team in my project"/etc.
As far as I know, there are no other people working on a specification
of OTRv4. The idea from our standpoint is that we hope that we will
get some comments and suggestions on changes and improvements, but
sooner or later will achieve broad consensus on this specification -
and once that happens it will be published on the OTR web page as the
official specification for version 4. If you think it would help
understanding to have a temporary code name we could absolutely do
that - but at the moment I don't exactly see the point.

Cheers
-- 
 Ola Bini (https://olabini.se)

 "Yields falsehood when quined" yields falsehood when quined.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20161217/ece611e8/attachment.sig>