In this case, definitely that's fine. Can you point out where in the spec it mentions opaque data encoding a length? I even looked for that in the TLS style syntax description again, since everything I was worried about in the draft made since if that was the case, but couldn't find it.
I think we may have the very minor bug of needing to make the fact the length is encoded a bit more clear in the draft (or I'm just blind), but given this, my bigger concern is a non-issue. Thanks, that clears it up. David (as individual) On Jul 8, 2010 4:11 PM, "Cullen Jennings" <[email protected]> wrote: Agree with what you are getting at here but I think the draft is already pretty much what you want and this is just a syntax confusion. When the spec has a typedef like typedef opaque ResourceId<0..2^8-1>; This results in bits on the wire that look like an 8 bit integer as the length followed by that many byes of data. So any time we have a variably length element generated by the < > operators, it includes the length as well as the data. So with that in mind, looking at section 5.3.3, the MessageExtensions extensions<0..2^32-1>; will contain the length all *all* the extensions if a parser just wanted to skip over them all. If it did not skip them all, the opaque extension_contents<0..2^32-1>; will start with the length of the extension data so the parser can skip over an extenuation it does not understand. So given all that, does draft look reasonable. I completely agree an peer needs to be able to know the length of an unknown extortion to be able to step over it in parsing so if we can't do that, we need to fix it. On Jul 8, 2010, at 8:58 AM, David A. Bryan wrote: > So looking at the extension mechanism in 5.3... > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
