<HTML>
<HEAD>
<TITLE>Re: [Sls-slp] JAXA RID against OID Frame</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>So if you can read the spec and think that a project can do that then write it into the spec that you can’t do that. <BR>
<BR>
<BR>
On 3/4/09 4:34 PM, "Kazz, Greg J" <greg.j.kazz@jpl.nasa.gov> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT COLOR="#000080"><FONT SIZE="4"><FONT FACE="Arial"><SPAN STYLE='font-size:13.0px'>Ed,<BR>
<BR>
You are saying the service provider (DSN, SN, GN, ESA, etc) would not provide OID packets to the user. I agree. I was only saying that the way the standard is written today, it is possible for a project to think that they could put data into a packet secondary header of an OID packet and think it is a valid thing to do.<BR>
<BR>
Greg<BR>
<BR>
</SPAN></FONT></FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>
</SPAN></FONT>
<P ALIGN=CENTER>
<FONT SIZE="5"><FONT FACE="Times New Roman"><SPAN STYLE='font-size:16.0px'><HR ALIGN=CENTER SIZE="2" WIDTH="100%"></SPAN></FONT></FONT>
<P>
<FONT SIZE="4"><FONT FACE="Tahoma"><SPAN STYLE='font-size:13.0px'><B>From:</B> Greenberg, Edward <BR>
<B>Sent:</B> Wednesday, March 04, 2009 4:18 PM<BR>
<B>To:</B> Kazz, Greg J; Matt Cosby; Gian.Paolo.Calzolari@esa.int<BR>
<B>Cc:</B> sls-slp@mailman.ccsds.org; Takahiro Yamada; Tim RAY; Jean-Luc.Gerner@esa.int; sls-slp-bounces@mailman.ccsds.org; gilles.moury@cnes.fr<BR>
<B>Subject:</B> Re: [Sls-slp] JAXA RID against OID Frame<BR>
</SPAN></FONT></FONT><FONT SIZE="5"><FONT FACE="Times New Roman"><SPAN STYLE='font-size:16.0px'> <BR>
</SPAN></FONT></FONT><FONT SIZE="1"><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:5.0px'>NO, Projects should not be allowed to get fill/idle/OID packets. OID frames on the other hand can contain insert data if managed for the physical channel (TM or AOS)<BR>
<BR>
<BR>
On 3/4/09 8:26 AM, "Kazz, Greg J" <greg.j.kazz@jpl.nasa.gov> wrote:<BR>
</SPAN></FONT><FONT COLOR="#000080"><FONT FACE="Arial"><SPAN STYLE='font-size:6.0px'>You are all thinking very logically. But flight projects often cut corners and find all sorts of unusual and esoteric ways of utilizing the standards. Consensus on this matter seems to be, yes it is possible, but the limit of the probability of doing so approaches zero.<BR>
<BR>
Greg<BR>
</SPAN></FONT></FONT></FONT>
<P ALIGN=CENTER>
<FONT SIZE="1"><FONT FACE="Times New Roman"><SPAN STYLE='font-size:8.0px'><HR ALIGN=CENTER SIZE="2" WIDTH="100%"></SPAN></FONT></FONT>
<P>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
</SPAN></FONT><FONT SIZE="1"><FONT FACE="Tahoma"><SPAN STYLE='font-size:6.0px'><B>From:</B> Greenberg, Edward <BR>
<B>Sent:</B> Wednesday, March 04, 2009 3:03 AM<BR>
<B>To:</B> Matt Cosby; Gian.Paolo.Calzolari@esa.int; Kazz, Greg J<BR>
<B>Cc:</B> sls-slp@mailman.ccsds.org; Takahiro Yamada; Tim RAY; Jean-Luc.Gerner@esa.int; sls-slp-bounces@mailman.ccsds.org; gilles.moury@cnes.fr<BR>
<B>Subject:</B> Re: [Sls-slp] JAXA RID against OID Frame<BR>
</SPAN></FONT><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:8.0px'><BR>
</SPAN></FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"><FONT SIZE="2"><SPAN STYLE='font-size:10.0px'>I agree with Matt and Gian Paolo. If you want to send a packet with a meaningful secondary header and no useful information thengive it an APID with that interpretation, not one that says it only contains idle data. Have a wonderful time discussing this trivia. <BR>
<BR>
<BR>
On 3/4/09 1:59 AM, "Cosby Matthew" <MCOSBY@qinetiq.com> wrote:<BR>
</SPAN></FONT></FONT><FONT SIZE="2"><SPAN STYLE='font-size:10.0px'><FONT COLOR="#000080"><FONT FACE="Arial">Greg,<BR>
<BR>
I agree with Gian Paolo. <BR>
<BR>
When our TM systems detect an Idle Packet (APID set to 0x7FF) it discards it. <BR>
<BR>
>From the TM Spec.<BR>
</FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"><B>4.3.2.5 </B>Extracted Packets shall be delivered to the users on the basis of the PVN in their header. Incomplete Packets are not required to be delivered in cross support situations. <BR>
<BR>
NOTE . Idle Packets are discarded. Data Fields that contain only Idle Data are also discarded.<BR>
</FONT><FONT COLOR="#000080"><FONT FACE="Arial"><BR>
This states that the Idle Packet is discarded and implies that there is no user data within the packet. There probability isn’t any where in the standard stating that you can’t put a secondary header in the Idle Packet, but this is implied as this packet is thrown out. So quoting Gian Paolo it would be crazy to put any useful data into the idle packet.<BR>
<BR>
Regards,<BR>
<BR>
Matt.<BR>
</FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"><BR>
</FONT><FONT COLOR="#000080"><FONT FACE="Arial">Matthew Cosby<BR>
<BR>
QinetiQ<BR>
Bldg X107 Rm G003<BR>
Cody Technology Park<BR>
Ively Road, Farnborough<BR>
Hants, GU14 0LX<BR>
</FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"><BR>
</FONT><FONT COLOR="#000080"><FONT FACE="Arial">Tel: </FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> </FONT><FONT COLOR="#000080"><FONT FACE="Arial">01252 396313 </FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#000080"><FONT FACE="Arial">Email: </FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> </FONT><FONT COLOR="#000080"><FONT FACE="Arial">mcosby@QinetiQ.com </FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#000080"><FONT FACE="Arial">Fax: </FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> </FONT><FONT COLOR="#000080"><FONT FACE="Arial">01252 392969 </FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#000080"><FONT FACE="Arial">Web: </FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> </FONT><FONT COLOR="#000080"><FONT FACE="Arial">www.QinetiQ.com <a href="http://www.qinetiq.com"><http://www.qinetiq.com></a> </FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#000080"><FONT FACE="Arial">QinetiQ - The Global Defence and Security Experts <BR>
</FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"><BR>
</FONT></SPAN></FONT><FONT COLOR="#339966"><FONT SIZE="1"><FONT FACE="Webdings"><SPAN STYLE='font-size:5.0px'>P </SPAN></FONT></FONT><FONT SIZE="2"><FONT FACE="Arial"><SPAN STYLE='font-size:10.0px'><I>Please consider the environment before printing this email.</I> <BR>
</SPAN></FONT></FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>
</SPAN></FONT>
<P ALIGN=CENTER>
<FONT SIZE="2"><FONT FACE="Times New Roman"><SPAN STYLE='font-size:10.0px'><HR ALIGN=CENTER SIZE="2" WIDTH="100%"></SPAN></FONT></FONT>
<P>
<FONT SIZE="2"><SPAN STYLE='font-size:10.0px'><FONT FACE="Tahoma"><B>From:</B> sls-slp-bounces@mailman.ccsds.org [<a href="mailto:sls-slp-bounces@mailman.ccsds.org]">mailto:sls-slp-bounces@mailman.ccsds.org]</a> <a href="mailto:sls-slp-bounces@mailman.ccsds.org%5d"><mailto:sls-slp-bounces@mailman.ccsds.org%5d></a> <a href="mailto:sls-slp-bounces@mailman.ccsds.org%5d"><mailto:sls-slp-bounces@mailman.ccsds.org%5d></a> <B>On Behalf Of </B></FONT></SPAN></FONT><FONT FACE="Tahoma"><SPAN STYLE='font-size:12.0px'>Gian.Paolo.Calzolari@esa.int<BR>
<B>Sent:</B> 03 March 2009 18:21<BR>
<B>To:</B> Kazz, Greg J<BR>
<B>Cc:</B> sls-slp@mailman.ccsds.org; Takahiro Yamada; Ray,Timothy J. (GSFC-583.0); Jean-Luc.Gerner@esa.int; sls-slp-bounces@mailman.ccsds.org; gilles.moury@cnes.fr; Greenberg,Edward<BR>
<B>Subject:</B> RE: [Sls-slp] JAXA RID against OID Frame<BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10.0px'><BR>
<BR>
<BR>
</SPAN></FONT><SPAN STYLE='font-size:10.0px'><FONT FACE="Courier New">"Kazz, Greg J" <greg.j.kazz@jpl.nasa.gov> wrote on 03-03-2009 18:21:35:<BR>
</FONT><FONT FACE="Verdana, Helvetica, Arial"><BR>
</FONT><FONT FACE="Courier New">> G.P.,</FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT FACE="Courier New">> <BR>
> 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><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT FACE="Courier New">> <BR>
> thanks,</FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT FACE="Courier New">> <BR>
> Greg</FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT FACE="Courier New">> <BR>
</FONT><FONT FACE="Verdana, Helvetica, Arial"><BR>
</FONT><FONT FACE="Courier New">Greg,</FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT FACE="Courier New"> 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><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT FACE="Courier New">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><FONT FACE="Verdana, Helvetica, Arial"> <BR>
<BR>
</FONT><FONT FACE="Courier New">Comments/confirmations are welcome.</FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
<BR>
</FONT><FONT FACE="Courier New">Ciao</FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
<BR>
</FONT><FONT FACE="Courier New">Gian Paolo<BR>
</FONT><FONT FACE="Verdana, Helvetica, Arial">The information contained in this E-Mail and any subsequent <BR>
correspondence is private and is intended solely for the intended <BR>
recipient(s). The information in this communication may be <BR>
confidential and/or legally privileged. Nothing in this e-mail is <BR>
intended to conclude a contract on behalf of QinetiQ or make QinetiQ <BR>
subject to any other legally binding commitments, unless the e-mail <BR>
contains an express statement to the contrary or incorporates a formal Purchase Order.<BR>
<BR>
For those other than the recipient any disclosure, copying, <BR>
distribution, or any action taken or omitted to be taken in reliance <BR>
on such information is prohibited and may be unlawful.<BR>
<BR>
Emails and other electronic communication with QinetiQ may be <BR>
monitored and recorded for business purposes including security, audit <BR>
and archival purposes. Any response to this email indicates consent <BR>
to this.<BR>
<BR>
Telephone calls to QinetiQ may be monitored or recorded for quality <BR>
control, security and other business purposes.<BR>
<BR>
QinetiQ Limited<BR>
Registered in England & Wales: Company Number:3796233<BR>
Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom<BR>
Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom <BR>
<a href="http://www.qinetiq.com/home/notices/legal.html">http://www.qinetiq.com/home/notices/legal.html</a> <a href="http://www.QinetiQ.com/home/legal.html"><http://www.QinetiQ.com/home/legal.html></a> <BR>
</FONT></SPAN></FONT><FONT FACE="Verdana, Helvetica, Arial"><FONT SIZE="1"><SPAN STYLE='font-size:5.0px'><BR>
<BR>
</SPAN></FONT><SPAN STYLE='font-size:12.0px'><BR>
</SPAN></FONT><FONT SIZE="5"><FONT FACE="Times New Roman"><SPAN STYLE='font-size:16.0px'> <BR>
</SPAN></FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
</SPAN></FONT>
</BODY>
</HTML>