Up to version 11, we only had the KindID described in the IANA registry section and it was defined as a 32 bit value. In version 12, we added the typedef for it as well but messed up and put 16 where it should have been 32. The IANA text in version 12 was still 32 bits.
I think the kinds should be a 32 bit space. At first glance 16 bits might seem like enough but the more you think about it, we use these all over the place. A given application could use many kinds. It would be really bad to run out. The doc currently contradicts itself having them partially 32 and partially 16 but I think we should go with 32 bits as we had in version prior to version 12 of the draft. On Jan 18, 2011, at 11:29 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/18/2011 05:32 AM, Eric Rescorla wrote: >> >> On Nov 17, 2010, at 11:28 AM, Marc Petit-Huguenin wrote: >> >> Few more nits: >> >> - Section 5.5.4.1 "typedef uint16 KindId;" >> >> This contradicts section 13.6 that states that KindId are 32-bit integers. >> >> (Reported by Stéphane Bryant) >> >> >>> I'm tempted to change the bits on the wire here--bigger seems better. >>> Obviously >>> this is a breaking change. Comments? > > I am personally all for breaking compatibility between different versions of > an > I-D. You can make it easy for implementers by incrementing the minor version > in > the Forwarding header (i.e. 0x01-->0x02, and it will still be changed to 0x0a > when published as an RFC). > > - -- > Marc Petit-Huguenin > Personal email: [email protected] > Professional email: [email protected] > Blog: http://blog.marc.petit-huguenin.org _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
