-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Inline.
On 01/18/2011 05:21 AM, Eric Rescorla wrote: > > On Dec 6, 2010, at 2:12 PM, Marc Petit-Huguenin wrote: >> bytes, or 2032 bits. >> >> A.14. Section 5.3.2 "uint32 length;" >> >> I can assume that this length covers the Header, MessageContents and >> Signature, >> but I would guess that this was useful when Message was sent without >> FramingHeader over TCP (same than for the relo_token used to >> disambiguate STUN >> packets). Now that this is useless, can't this length been only >> Header and >> MessageContents, so it is possible to find the boundary between >> MessageContents >> and Signature without having to parse MessageContents at all? >> > > I think it's a mistake to assume we'll never want messages to be > self-contained/unframed. > Is there a real advantage to this breaking change? A little easier to parse the message, but you are right that a message can be unframed. [...] >> A.16. Section 5.5.1.1. "IceCandidate candidates<0..2^16-1>;" >> >> Because there must be at least one candidate, should this be: >> >> IceCandidate candidates<1..2^16-1>; > > It's actually quite a but longer than that, because IceCandidate is > fairly long. > However, I think it's harmless to leave it as-is and actually putting > 12..2^16-1 or whatever is just confusing. OK >> A.19. Section 5.6.3.1.1, last paragraph >> >> This paragraph described a lockstep algorithm, but if it is the case >> then there >> is no need for the received field, as we would always know that the >> previous >> messages have been received. >> > > Sorry, I'm not sure I understand the question. The received field is > there to > permit the sender to unilaterally use more sophisticated algorithms. > Here's what the last paragraph says: "Once an ACK has been received for a message, the next message can be sent, but the peer SHOULD ensure that there is at least 10 ms between sending any two messages. The only time a value less than 10 ms can be used is when it is known that all nodes are on a network that can support retransmissions faster than 10 ms with no congestion issues." What I understand from this text is that a message cannot be sent until the previous one has been acknowledged. If other algorithms can be used (e.g. one that use the received field), then the text should say that the algorithm above is the basic algorithm that must at least been implemented. > >> A.20. Section 5.7, "If the message is not fragmented, then both the >> first and >> last fragment are set to 1..." >> >> If the first fragment bit is set to 1 when the message is fragmented >> and is also >> set to one when the message is not fragmented, then it is always set >> to 1, so >> what is the point of having it in the first place? > > > Good point. OTOH, does this do any damage? If not, I'm tempted to write it > down as a misfeature and leave as-is. OK. Perhaps a note somewhere about this would be useful for future developers. >> A.21. Section 10.1. "<kind name='sip-registration'><data-model>..." >> >> Why do we need to repeat the data-model and access-control that were >> already in >> the IANA registry? Or is it a way to override the IANA definitions as the >> example would suggest? (as the registration for SIP-REGISTRATION is using >> DICTIONARY and USER-NODE-MATCH). >> > > No, it's just to preserve uniform syntax for IANA-defined and > user-defined kinds. OK, but what happen if the values in the XML are different from what is in the RFC describing the Kind (like it is currently in the example). My suggestion would be to simply say that the values in the XML files are ignored for IANA-defined kinds. [...] >> A.28. Section 10.1.1 last paragraph "such an XML configuration file >> sent over >> email." >> >> Because the signatures on the XML document are done on exact byte >> string and >> because emails servers are known to mess with end of lines, we will see >> configuration documents that cannot be verified after been sent by >> email (what >> was wrong with using XML-sig anyway?). >> > > It's ridiculously overcomplicated for this application (and arguably for > any application). OK. - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk012lwACgkQ9RoMZyVa61dEfACaAwKwiLT0CpVaxDFjmF24Htfv ZxgAoIbFGmodRm3Q4Q30RiacwmMkjLZO =rh5C -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
