<br><font size=2 face="sans-serif">Greg,</font>
<br><font size=2 face="sans-serif"> In
Packet Telemetry the term "idle frame" was deprecated because
it is posible that frame is not completely idle (opposite to the idle packet).</font>
<br><font size=2 face="sans-serif">An idle frame can in fact contain a
valid CLCW or a valid secondary header.</font>
<br><font size=2 face="sans-serif">In such a sense:</font>
<br><font size=2 face="sans-serif">1) discarding an idle frame may
imply loosing valid data while</font>
<br><font size=2 face="sans-serif">2) discarding an idle packet has no
drawback.</font>
<br>
<br><font size=2 face="sans-serif">In CCSDS 732.0-B-2 I can read:</font>
<br><font size=2 face="sans-serif">--------------------------------------------</font>
<div>
<br><font size=3 face="Times New Roman"><b>4.1.2.3.2 </b>The Virtual Channel
Identifier shall be used to identify the Virtual Channel. </font>
<br><font size=3 face="Times New Roman">NOTES </font>
<br><font size=3 face="Times New Roman">...........</font>
<br><font size=3 face="Times New Roman">3 A Transfer Frame on the ‘Idle’
Virtual Channel may not contain any valid user data within its Transfer
Frame Data Field, but it must contain the Insert Zone if the Insert Service
is supported. </font>
<br><font size=2 face="sans-serif">--------------------------------------------</font>
<div>
<br><font size=3 face="Times New Roman"><b>4.1.4.1.5 </b>In the case where
at release time </font><font size=2 face="sans-serif">.....................</font>
<br><font size=3 face="Times New Roman">NOTES </font>
<br><font size=3 face="Times New Roman">1 Transfer
Frames containing Idle Data in their Data Fields are sent to maintain synchronization
at the receiver and also to transmit data in the Transfer Frame Insert
Zone when there is no Data Field to send. </font>
<br><font size=2 face="sans-serif">--------------------------------------------</font>
<br><font size=2 face="sans-serif">Looking at </font><font size=3 face="Times New Roman"><b>Figure
4-1: AOS Transfer Frame Structural Components </b></font><font size=2 face="sans-serif">we
see that an AOS frame may contain both an Insert Zone (equivalent to the
Secondary header, I understand) and an Operational Control Field. Therefore
the same reasoning of Packet TM do apply: </font>
<br><font size=2 face="sans-serif"> An
"idle frame" can contain (also) valid data (but not in the Data
Field) while an Idle Packet does not contain any valid data</font>
<br><font size=2 face="sans-serif">--------------------------------------------</font>
<div>
<br>
<br>
<br><font size=2 face="sans-serif">Marjorie is preparing a coordinate ESA
position with respect to all those RIDs.</font>
<br>
<br><font size=2 face="sans-serif">Best regards</font>
<br>
<br><font size=2 face="sans-serif">Gian Paolo</font>
<p><font size=2 face="sans-serif">(*) Clearly for the CLCW - since the
same CLCW is likely to be inserted in several frames - this would not happen
if you have just one OID frame, but it could happen in a situation (that
cannot be excluded a priori) where several OID frames are sent in sequence.
In addition for the Secondary Header even a single frame could contain
important data.</font>
<p>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Kazz, Greg J"
<greg.j.kazz@jpl.nasa.gov></b> </font>
<br><font size=1 face="sans-serif">Sent by: sls-slp-bounces@mailman.ccsds.org</font>
<p><font size=1 face="sans-serif">03-03-2009 01:23</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">"Gian.Paolo.Calzolari@esa.int"
<Gian.Paolo.Calzolari@esa.int></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">"Greenberg, Edward" <edward.greenberg@jpl.nasa.gov>,
"sls-slp@mailman.ccsds.org" <sls-slp@mailman.ccsds.org>,
"Jean-Luc.Gerner@esa.int" <Jean-Luc.Gerner@esa.int>, Takahiro
Yamada <tyamada@pub.isas.jaxa.jp>, "gilles.moury@cnes.fr"
<gilles.moury@cnes.fr></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">[Sls-slp] JAXA RID against OID Frame</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=3 face="Arial">G.P.</font>
<br><font size=3 face="Arial"> </font>
<br><font size=3 face="Arial">I think JAXA has a valid concern in the attached
RID concerning the use of the term, OID, only idle data. I thought the
purpose of using OID frame was to use the same terminology across all CCSDS
space data link documents. But as pointed out in the rid, when we have
an “Idle packet” it isn’t called an OID packet, but rather and idle
packet. So I am not sure that the term OID frame is consistent enough.
Not that I am advocating the use of the term, OID packet at all. What do
you think? </font>
<br><font size=3 face="Arial">JAXA rid below.</font>
<br><font size=3 face="Arial"> </font>
<br><font size=3 face="Arial">thanks,</font>
<br><font size=3 face="Arial"> </font>
<br><font size=3 face="Arial">Greg</font>
<br><font size=3 face="Arial"> </font>
<br><font size=2 face="Courier New">REVIEW ITEM DISPOSITION (RID):</font>
<br><font size=2 face="Courier New">
RED BOOK RID INITIATION FORM</font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New">AGENCY RID NUMBER: JAXA-RPA830-01</font>
<br><font size=2 face="Courier New">SUBMITTING ORGANIZATION (Agency, Center):
JAXA</font>
<br><font size=2 face="Courier New">------------------------------------------------------------------</font>
<br><font size=2 face="Courier New">REVIEWER'S NAME: Shigeyuki Furushima</font>
<br><font size=2 face="Courier New">CODE:
Mitsubishi Electric Corporation</font>
<br><font size=2 face="Courier New">E-MAIL ADDRESS: jaxa.ccsds@jaxa.jp</font>
<br><font size=2 face="Courier New">TELEPHONE:
29-868-2587</font>
<br><font size=2 face="Courier New">------------------------------------------------------------------</font>
<br><font size=2 face="Courier New">DOCUMENT NUMBER: CCSDS 732.0-P-2.1
Pink Sheets, Issue 2.1</font>
<br><font size=2 face="Courier New">DOCUMENT NAME: AOS Space
Data Link Protocol</font>
<br><font size=2 face="Courier New">DATE ISSUED: December
2008</font>
<br><font size=2 face="Courier New">PAGE NUMBER:
PARAGRAPH NUMBER: </font>
<br><font size=2 face="Courier New">RID SHORT TITLE: The cange from
"Idle Frame" to "OID Frame" (1)</font>
<br><font size=2 face="Courier New">------------------------------------------------------------------</font>
<br><font size=2 face="Courier New">DESCRIPTION OF REQUESTED CHANGE: (Use
From: "..." To "..." format)</font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New">It's not necessary to change "Idele
frame" to "OID Frame" .</font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New">The basis of suggestion is given below.</font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New">1. There is no change of definition
in the recomendation.</font>
<br><font size=2 face="Courier New"> Changing word without
changing definition will give rise to the confusion.</font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New">2. The purpose of this pink sheet is
to clearfy the meaning of "idle." </font>
<br><font size=2 face="Courier New"> However, "Idle Packet"
is not changed to "OID Packet."</font>
<br><font size=2 face="Courier New"> (See Page C-3, Table C-1)</font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New">------------------------------------------------------------------</font>
<br><font size=2 face="Courier New">CATEGORY OF REQUESTED CHANGE:</font>
<br><font size=2 face="Courier New"> Technical Fact
___ Recommended _X_ Editorial ___</font>
<br><font size=2 face="Courier New">NOTES:</font>
<br><font size=2 face="Courier New">TECHNICAL FACT: Major technical
change of sufficient magnitude as to</font>
<br><font size=2 face="Courier New"> render the Recommendation inaccurate
and unacceptable if not</font>
<br><font size=2 face="Courier New"> corrected. (Supporting
analysis/rationale is essential.)</font>
<br><font size=2 face="Courier New">RECOMMENDED: Change of a nature
that would, if incorporated, produce</font>
<br><font size=2 face="Courier New"> a marked improvement in document
quality and acceptance.</font>
<br><font size=2 face="Courier New">EDITORIAL: Typographical or other
factual error needing correction.</font>
<br><font size=2 face="Courier New"> (This type of change will be
made without feedback to submitter.)</font>
<br><font size=2 face="Courier New">------------------------------------------------------------------</font>
<br><font size=2 face="Courier New">SUPPORTING ANALYSIS:</font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New">------------------------------------------------------------------</font>
<br><font size=2 face="Courier New">DISPOSITION:</font>
<br><font size=3 face="Arial"> </font><tt><font size=2>_______________________________________________<br>
Sls-slp mailing list<br>
Sls-slp@mailman.ccsds.org<br>
http://mailman.ccsds.org/mailman/listinfo/sls-slp<br>
</font></tt>
<br></div></div></div>