On Jan 18, 2011, at 8:22 PM, Marc Petit-Huguenin wrote: > > 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. >
Sounds good. Willdo. >> >> Good point. OTOH, does this do any damage? If not, I'm tempted to write it >> down as a misfeature and leave as-is. Done. > 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. > I've made this change, but I'd like to have other people weigh in if they don't like it. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
