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.
signature.asc
Description: PGP signature
_______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
