Wireshark-dev: Re: [Wireshark-dev] Terminating NULL chraracter in RTCP Byereason string
> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx
> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
>
> On Aug 5, 2008, at 7:23 AM, Vinod M wrote:
>
> > "Optionally, the BYE packet MAY include an 8-bit octet
> count followed
> > by that many octets of text indicating the reason for
> leaving, e.g.,
> > "camera malfunction" or "RTP loop detected".
> > The string has the same encoding as that described for SDES.
> > If the string fills the packet to the next 32-bit boundary, the
> > string is not null terminated.
The real problem in the spec is here - the leap from "octets of text" to
"string".
> 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.
Neil
