<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3354" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV dir=ltr align=left>
<DIV dir=ltr align=left><SPAN class=302351916-25062008><FONT face=Arial
color=#0000ff size=2>It sounds good to me. Explicit length definitions
always look cleaner to me than a series of null-terminated strings. Then again,
in my <SPAN class=012572216-25062008>initial </SPAN>single-processor
focused message queue implementation, I haven't actually had <SPAN
class=012572216-25062008>a need to </SPAN>process many of the null-terminated
string fields. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=302351916-25062008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=302351916-25062008><FONT face=Arial
color=#0000ff size=2><SPAN class=012572216-25062008>For error checking though,
don't we already have a total "Length of supplementary data" field in the
header, which should be used for failsafe validation. Also, from a
standards point of view, I believe NULL-terminated strings are generally more
commonly used for variable sized strings, with or without accompanying length
fields.</SPAN></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=302351916-25062008><FONT face=Arial
color=#0000ff size=2><SPAN class=012572216-25062008></SPAN></FONT></SPAN><SPAN
class=302351916-25062008><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=302351916-25062008><SPAN
class=012572216-25062008><FONT face=Arial color=#0000ff size=2>-
David</FONT></SPAN></SPAN></DIV></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> sis-ams-bounces@mailman.ccsds.org
[mailto:sis-ams-bounces@mailman.ccsds.org] <B>On Behalf Of </B>Scott
Burleigh<BR><B>Sent:</B> Wednesday, June 25, 2008 11:32 AM<BR><B>To:</B> Ray,
Timothy J. (GSFC-583.0)<BR><B>Cc:</B>
sis-ams@mailman.ccsds.org<BR><B>Subject:</B> Re: [Sis-ams] validation of
Meta-AMS PDUs<BR></FONT><BR></DIV>
<DIV></DIV>Ray, Timothy J. (GSFC-583.0) wrote:
<BLOCKQUOTE
cite=mid:C3B9C435D7725E4EABE2B62200A42C127CD508@NDMSEVS36A.ndc.nasa.gov
type="cite">
<META content="Microsoft Word 11 (filtered)" name=Generator>
<STYLE>@font-face {
font-family: MS Mincho;
}
@font-face {
font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
P.StyleParagraph4Kernat14pt {
FONT-SIZE: 12pt; MARGIN: 12pt 0in 0pt; LINE-HEIGHT: 14pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
LI.StyleParagraph4Kernat14pt {
FONT-SIZE: 12pt; MARGIN: 12pt 0in 0pt; LINE-HEIGHT: 14pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
DIV.StyleParagraph4Kernat14pt {
FONT-SIZE: 12pt; MARGIN: 12pt 0in 0pt; LINE-HEIGHT: 14pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
SPAN.EmailStyle18 {
COLOR: windowtext; FONT-FAMILY: Arial
}
DIV.Section1 {
page: Section1
}
OL {
MARGIN-BOTTOM: 0in
}
UL {
MARGIN-BOTTOM: 0in
}
</STYLE>
<DIV class=Section1>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Dear WG Members,</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT> </P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">In my implementation, I am trying
to thoroughly validate each incoming Meta-AMS protocol message (MPDU).
The primary goal is to avoid program crashes that can occur when an attempt is
made to access an array element beyond the end of the array’s allocated
memory. For example, if the supplementary data includes a field that is
supposed to be a null-terminated character string, but the null-terminator is
missing, avoid any attempts to access past the end of the entire array
allocated to hold the raw MPDU bytes.</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT> </P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">I’m finding it quite complex to
validate MPDUs whose supplementary data includes null-terminated strings
(especially if the strings are buried within arrays of structures containing
sub-structures). Validation would be much simpler if, instead of adding
a one-byte null terminator at the end of each string, we added a one-byte
length field at the beginning of each string. (It would also be possible
to add the one-byte length field and keep the null terminator, although that
seems redundant).</SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT> </P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Any
thoughts/comments?</SPAN></FONT></P></DIV></BLOCKQUOTE>I kind of like this idea,
though I know it would have an impact on everybody's implementation work.
It would be not much harder to write up in the spec, it would consume no
additional bandwidth (assuming the string length byte was instead of, rather
than in addition to, the NULL string terminator), and it could very well make
validation simpler and therefore make implementations safer.<BR><BR>But that's
easy for me to say, as I'm way behind in retrofitting my implementation to the
Red-2 spec anyway and it would be fairly easy for me to include this change when
I finally get to work. Stuart, Pat, David, what do you guys
think?<BR><BR>Scott<BR></BODY></HTML>