[OTR-dev] making DATA_REQUEST and DATA_RESPONSE official TLVs (aka OTRDATA)

[Hans-Christoph Steiner]

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