Cullen, By comparing to reload-03, I realize that the notation "opaque name<0..2^8-1>" simply means a variable length of bytes with NO leading length byte, contrary to what I suggested in my last post. Then in Reload-04,
4. Either the "name<0..2^8-1>" notation is ambiguous about whether such leading length exist; or 5. If no such length byte is implied, then there are a number of places where the length of variable bytes/characters are missing (search all occurrences of "<0.."): RouteLogEntry.version RouteLogEntry.certificate ErrorResponse.reason_phrase ErrorResponse.error_info ConnectReqAns.ufrag ConnectReqAns.password ConnectReqAns.role ConnectReqAns.candidate TunnelReq.dialog_id TunnelReq.application_pdu ... a lot more of these ... The first two items above also make parsing these two difficult: RouteLogEntry.extensions RouteLog (unless take my suggestion of adding "Route Log Length" to fix header) Also, the size of "Signature.signature_value" must be determined using the size of the entire PDU, which is an awkward way to do it. Thank you --Michael Cullen Jennings wrote: > We've just uploaded an update to the reload draft. Until it shows up > in the drafts directory, you can find it at > > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-bryan-p2psip-reload-04.txt > or > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-bryan-p2psip-reload-04.html > > reload-04 represents a total rewrite of the presentation of the > protocol. There were a number of goals: > > - add several descriptive sections at the beginning that detail how > the protocol works and the design choices we made (and some of the > options we chose not to incorporate at this point) > - Simplify the presentation (and protocol) wherever possible by > removing extraneous features from this draft. Some of these may come > back in future drafts, but we felt simplifying wherever possible was > good. > - remove the bit-field diagrams from the protocol descriptions in > favor of c-like message structure presentations. > > We are very interested in comments on this draft. We expect to have > time for another revision in about 2 weeks. We have tried to address > as many of the comments and questions that have been raised as we > can. In some areas we have made deliberate choices to avoid adding > features that have been requested. Where possible we discuss the > tradeoffs that adding additional features will require. We think it's > important for the working group to decide as a whole where additional > features are worth the added complexity. > > Please send your comments to the working group list - it would make it > easier for us if people tried to keep separate issues in separate > threads and start new threads where it appropriate. I think we would > all like to hash out as many protocol issues as possible before we get > to Dublin. > > Cullen > Bruce > Eric > Salman > Henning > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
