<br>
<br><tt><font size=2>"Kazz, Greg J" <greg.j.kazz@jpl.nasa.gov>
wrote on 03-03-2009 18:21:35:<br>
<br>
> G.P.,</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> But a Space Packet can contain a Secondary Header,
which could <br>
> contain useful data as well. So in that sense, OID Packet also makes<br>
> sense. In other words, discarding an “Idle Packet” can have a <br>
> drawback or unintended consequence. CCSDS needs to use consistent
<br>
> terminology across the board and I think that is what this JAXA rid
<br>
> is pointing out. I am looking forward to Marjorie’s responses to
<br>
> those rids as well.</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> thanks,</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> Greg</font></tt>
<br><tt><font size=2>>  </font></tt>
<br>
<br><tt><font size=2>Greg,</font></tt>
<br><tt><font size=2>        The Frame has
a structure linked to the Virtual Channel and all frames on a VC have the
secondary header (if this is used) independently they are OID or not.</font></tt>
<br><tt><font size=2>Conversely the Space Packet has a structure linked
to the APID and a mission implementing a Packet Secondary Header on Idle
Packets would just be crazy. :-) In addition, I think that, being the idle
APID fixed, there is no chance for having a Secondary header in an Idle
Packet [this is TBC].</font></tt>
<br>
<br><tt><font size=2>Comments/confirmations are welcome.</font></tt>
<br>
<br><tt><font size=2>Ciao</font></tt>
<br>
<br><tt><font size=2>Gian Paolo</font></tt>