On Aug 5, 2008, at 10:20 AM, Neil Piercy wrote: > The real problem in the spec is here - the leap from "octets of > text" to > "string".
A sequence of octets of text *is* a (text) string. A string is not necessarily null-terminated (the C programming language, and its derivatives, nonwithstanding). >> It sounds as if whoever wrote RFC 3550 needs to learn the >> difference between the words "padded" and "terminated" - they >> probably meant to say that the string is null-*padded* to a >> 4-byte boundary. > > Maybe they did know the diference, and maybe they didn't, but what > they > actually said was: > >>> If the string fills the packet to the next 32-bit boundary, the >>> string is not null terminated. > > i.e. they have defined a case in which a "string" is not null > terminated > (i.e. is a sequence of non-null characters only), so Wireshark should > not object to the string not being null terminated in this case. They also said > The string has the same encoding as that described for SDES. and what they say for SDES is > Each chunk consists of an SSRC/CSRC identifier followed by a list > of > zero or more items, which carry information about the SSRC/CSRC. > Each chunk starts on a 32-bit boundary. Each item consists of an > 8- > bit type field, an 8-bit octet count describing the length of the > text (thus, not including this two-octet header), and the text > itself. Note that the text can be no longer than 255 octets, but > this is consistent with the need to limit RTCP bandwidth > consumption. > > The text is encoded according to the UTF-8 encoding specified in > RFC > 2279 [5]. US-ASCII is a subset of this encoding and requires no > additional encoding. The presence of multi-octet encodings is > indicated by setting the most significant bit of a character to a > value of one. > > Items are contiguous, i.e., items are not individually padded to a > 32-bit boundary. Text is not null terminated because some multi- > octet encodings include null octets. The list of items in each > chunk > MUST be terminated by one or more null octets, the first of which > is > interpreted as an item type of zero to denote the end of the list. > No length octet follows the null item type octet, but additional > null > octets MUST be included if needed to pad until the next 32-bit > boundary. Note that this padding is separate from that indicated > by > the P bit in the RTCP header. A chunk with zero items (four null > octets) is valid but useless. which describes null-padded strings, not null-terminated strings (in fact, they explicitly say "Text is not null terminated because some multi-octet encodings include null octets" - although they earlier say the encoding is UTF-8, which *doesn't* include null octets in multi- octet encodings). I.e., RFC 3550 needs a little attention from an editor. In any case, what Wireshark should do is treat the BYE Reason string as null-padded, not as "null-terminated except when it isn't". _______________________________________________ Wireshark-dev mailing list [email protected] https://wireshark.org/mailman/listinfo/wireshark-dev
