<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Georgia;
        panose-1:2 4 5 2 5 4 5 2 3 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle18
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Georgia",serif;
        color:windowtext;}
span.EmailStyle20
        {mso-style-type:personal-compose;
        font-family:"Georgia",serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Georgia",serif">Wes,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif">Thanks for the input. 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif">For telemetry I tend to have the presumption that we are dealing with CCSDS telemetry frame formats and presumably processing for this is already well understood by missions in general.  Taking
 a look at the Roman draft ICD that Holger forwarded, as an example use case, it appears that what is being delivered  are AOS TLM frames with 32 bytes worth of annotation data added just prior to the start of each frame. This seems a lot like the SLE PDU just
 perhaps organized differently.  From the DLR example that Marcin sent, it looks like 38 bytes (if I interpret correctly) of “fixed” header and then an optional variable header and then the frame.  So perhaps it is just the ancillary annotation data that we
 are thinking about having in potentially different encoding schemes?  <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif">I think this tends to confirm that we should dedicate some time at the next telecon to discuss ASN.1 vs. other encoding schemes.  Of course, if anyone has any comments prior to the next teleconference
 that course would also be welcome.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif">-Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Eddy, Wesley M. (GSFC-580.0)[MTI SYSTEMS, INC.] <wesley.m.eddy@nasa.gov>
<br>
<b>Sent:</b> Saturday, November 26, 2022 9:02<br>
<b>To:</b> Barkley, Erik J (US 3970) <erik.j.barkley@jpl.nasa.gov>; css-cloud@mailman.ccsds.org<br>
<b>Subject:</b> RE: [EXTERNAL] [CSS-CLOUD] Offer different encodings?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Since the bodies can essentially be binary data, this may make require some deal of gymnastics for certain encodings that are less suited for carrying binary data (e.g. JSON).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> CSS-CLOUD <<a href="mailto:css-cloud-bounces@mailman.ccsds.org">css-cloud-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>Barkley, Erik J (US 3970) via CSS-CLOUD<br>
<b>Sent:</b> Tuesday, November 22, 2022 7:25 PM<br>
<b>To:</b> <a href="mailto:css-cloud@mailman.ccsds.org">css-cloud@mailman.ccsds.org</a><br>
<b>Subject:</b> [EXTERNAL] [CSS-CLOUD] Offer different encodings?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif">Dear Cloud BOF Colleagues,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif">Part of the standards shaping we discussed at the Toulouse meetings was involved with not necessarily using ASN.1 encoding for producing files of SLE PDUs or streaming data or streaming the SLE
 PDUs. Part of our discussion about that was deliberating a little bit as to possible alternative encodings such as JSON, XML, or perhaps something else. It occurs to me, and this may be just a brain fart, that maybe we don't have to really indicate any one
 particular encoding.  Given that the telemetry frames are going into the cloud, it seems that whatever gymnastic/processing is needed can be applied in the cloud for producing whatever encoding is desired. So maybe it's not so much that we would have to choose
 one encoding but we could indicate some possible alternatives as part of the standardization effort. Taking telemetry as an example, I think this would mean that we would have standard CCSDS telemetry frames going into the cloud computing infrastructure and
 then it would perhaps be a matter of choice among some different precooked encoding schemes for delivery to the mission operations center. I do know, as an analogy, that for some of the APIs in the DSN there is an option of essentially throwing a switch in
 the  ReST API to have data returned as XML or have it returned as JSON -- it is something like this that I'm thinking about. I would like to ask for a sanity check – do you think something like this makes sense? I would be interested in hearing any comments
 you may have. I realize that on the one hand this might be seen as "diluting" a potential standard by setting it scope a little too broadly, but then at the same time it may help with increasing infusion albeit at the cost of a few options. Perhaps we can
 discuss this at our next teleconference. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif">-Erik<o:p></o:p></span></p>
</div>
</body>
</html>