To keep the list up to date, I briefly chatted with Ian about this. He said he doesn't have any up front objections to the idea, but won't have time to review it for a while. I proposed just assigning the TLV numbers for now, so we don't have to work about conflicts and compatibility issues. So I posted this bug report:
https://bugs.otr.im/issues/87 On a similar topic, I also am requesting an "experimental range" for byte values in TLV8 to help deal with future compatibility issues. https://bugs.otr.im/issues/86 .hc Hans-Christoph Steiner: > > So far, resounding silence on this, so I'll try again! > > We (Guardian Project/ChatSecure) are currently working on nailing down the > final API of our DATA_RESPONSE and DATA_REQUEST TLVs for in-band data > transfer. We have it implemented now in otr4j and OTRKit, its been integrated > in ChatSecure-android for 6+ months, and now we are pushing forward getting > this integrated into more apps. > > We have been using the TLV numbers 100 and 101 to make sure that we don't > conflict with anything that might be in the works. I think now is the time to > make an official number so that new apps do not need to handle a migration > from the temp numbers. > > What do we need to officially claim TLV numbers in the OTR protocol? How about > 9 and 10? Should I submit a patch to libotr? Once we get it nailed down, the > OTRKit code can be ported to libotr, since OTRKit is really a wrapper of > libotr. > > Here is some more discussion, for those who want to know more details: > https://github.com/jitsi/otr4j/issues/16 > > And OTRKit's implementation: > https://github.com/ChatSecure/OTRKit/blob/otrdata/OTRKit/OTRData > > .hc > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
