<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Georgia",serif;
color:#1F497D;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:22706575;
mso-list-type:hybrid;
mso-list-template-ids:2000169964 93071704 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">John,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">I think the idea, somewhere along the line (and I would have to search the notes more careful than I have time for at the moment) was that we were going to manage
the 927 schema in a similar manner to what has been done for 902 schemas, and that is probably the reason why the schema was removed from the book. Having said that, we of course have never come up with something approximating a definitive plan for 927 schema
management (on the other hand I think we have a good plan for the 902 books series schemas). That’s clearly a problem. I propose that we take this up our telecon on the 26<sup>th</sup>.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">-Erik
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><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> SMWG <smwg-bounces@mailman.ccsds.org> <b>On Behalf Of
</b>John Pietras<br>
<b>Sent:</b> Monday, May 4, 2020 16:52<br>
<b>To:</b> Colin.Haddow@esa.int<br>
<b>Cc:</b> CCSDS SMWG ML (smwg@mailman.ccsds.org) <smwg@mailman.ccsds.org><br>
<b>Subject:</b> [EXTERNAL] [cssm] TGFT RIDs 28 and 41<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Colin,<o:p></o:p></p>
<p class="MsoNormal">Here are my responses to RIDs 28 and 41.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-bottom:12.0pt;margin-left:0in;mso-list:l0 level1 lfo2">
<b>RID 28, short title “in-tray”</b>. The explanation for not changing the diagram is as follows: “As (correctly) illustrated in the diagram, the Agency A Sender transfers the XFDU Package to the URL that identifies Agency B’ in-tray. The same is true in the
reverse direction.”<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo2"><b>RID 41, short title “Metadata to indicate sensitivity”.</b> This was simultaneously easier and harder than I originally thought it might be,
<br>
<br>
Because the TGFT XFDU is a valid subclass of the standard XFDU, we cannot add elements arbitrarily. We must add elements at designated extension points. Specifically, we can add new metadata at only two extension points: (a) TGFT-specific metadata that applies
to the XFDU Package as a whole is added through the the XFDU <b>packageHeader</b>:
<b>environmentInfo</b>: <b>extension</b> element (see 4.3.4.3), and (b) TGFT-specific metadata that applies to individual payload files within the XFDU Package is added through the informationPackageMap: contentUnit: extension element (see 4.3.5.2.3.2.2). Since
the WG decided that the <b>sensitivity</b> metadata element shall apply to the XFDU Package as a whole, it must be added through the
<b>packageHeader</b>: <b>environmentInfo</b>: <b>extension</b> element (option (a), above).
<i><o:p></o:p></i></li></ul>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph">Section 4.3.4.3 (a) currently specifies that the <b>packageHeader</b>:
<b>environmentInfo</b>: <b>extension</b> element “shall contain one <b>tgftXfduExtension</b> element, cast as an instance of the
<b>TgftXfduExtensionType</b> complex schema type, which is registered in the ‘<span style="color:black">urn:ccsds:schema:tgft:xfdu_extensions’ namespace in the file
</span><b>TgftXfduExtensionParameters.xsd</b><span style="color:black">. <br>
</span>NOTE - The <b>TgftXfduExtensionType</b> schema type contains two metadata parameters: originator and recipient.”
<br>
<br>
So the new <b>sensitivity</b> element <u>must</u> be made part of the <b>TgftXfduExtensionType</b>.<b> </b>I have updated the<b> TgftXfduExtensionType</b> schema type to add the sensitivity in the attached
<b><span style="color:black">TgftXfduExtensionParameters</span></b>.<b>xsd</b> file. In the context of section 4.3.4.3 (a), the Note should be changed to read
<br>
“NOTE - The TgftXfduExtensionType complex schema type contains <u>three</u> metadata parameters: originator, recipient,
<u>and sensitivity</u>.” <i><o:p></o:p></i></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph">That was the simple part. Now for the hard part - <i><span style="color:black">where is the actual<b> TgftXfduExtensionParameters.xsd</b> file that implementers will use<b>?</b></span></i><span style="color:black"> As late as version
w0.9</span>, the document had a normative Annex that contained the text of the <b>
<span style="color:black">TgftXfduExtensionParameters.xsd</span></b><span style="color:black"> file, but somewhere along the way that data type specification was deleted from the document, and only the namespace under which it is registered now exists, but
no repository of for the XCD file itself has been created, or if it has it has not been identified on the TGFT book.<i>
</i>Until that schema file is actually available from an identified repository (e.g., a SANA Registry), the TGFT XFDU is unimplementable because the mandatory
</span><b>tgftXfduExtension</b> element has no available type specification. This is a problem whether or not the
<b>sensitivity</b> metadata element is added. Also note that the <b><span style="color:black">TgftXfduExtensionParameters.xsd</span></b><span style="color:black"> file also contains the mandatory
</span><b>TgftContentUnitExtensionType</b> schema type that is required by TGFT ( extension point (b) above, see 4.3.5.2.3.2.2 and 4.3.5.3), so that is another point of unimplementability. [The XFDU Blue Book itself – CCSDS 661.0 – avoids these problems because
the schema is document in the Blue Book and only in the Blue Book.]<br>
<br>
Other sections of the TGFT spec that are problematic as a result of the unavailability of the
<b><span style="color:black">TgftXfduExtensionParameters.xsd</span></b><span style="color:black"> file are
</span>the third paragraph under F6.2.2 and the second paragraph under F6.3.2.4, both of which read: “<u>The mechanism by which the TGFT-specific metadata is added is as a
<b>tgftXfduExtension</b> element of the <b>TgftXfduExtensionType</b> complex schema type, which is registered in the ‘<span style="color:black">urn:ccsds:schema:tgft:xfdu_extensions’ namespace in the file TgftXfduExtensionParameters.xsd</span></u>.”
<i><o:p></o:p></i></p>
<p class="MsoListParagraph"><b><br>
</b>Finally, the NOTE under 4.3.4.3 (a) identifies that the <b>TgftXfduExtensionType
</b>contains originator and recipient parameters (and now sensitivity), but there are no definitions for these terms. I originally included them because you (Colin) sent me an email that listed these as additional parameters that the WG identified at a meeting
that I did not attend, and we never got around to defining. Also, these parameters are each individually optional (including sensitivity), so while the presence of an instance of
<b>TgftXfduExtensionType </b>is mandatory, it can contain all, any or none of the 3 parameters. If no one in the WG has a strong idea about the semantics of these parameters, I suggest that the wording of the NOTE under 4.3.4.3 (a) be extended to read something
like<br>
“NOTE - The TgftXfduExtensionType complex schema type contains three optional metadata parameters: originator, recipient, and sensitivity. The definitions of these parameters are outside the scope of this Recommended Standard, and their use (or non-use) is
left to the application that generates the XFDUs.”<o:p></o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph">Similarly, the NOTE under 4.3.5.3.1 identifies that the
<b>TgftContentUnitExtensionType</b> contains the creationDate element (which is also optional in the schema) with no further definition. Again, if the WG has a definition for this parameter, it should be stated, probably as a requirement and not just a note.
But if the definition is deferred to the application that uses TGFT, then the NOTE could be extended to something like<br>
“NOTE - The <b>TgftContentUnitExtensionType</b> complex schema type contains one optional metadata parameter: creationDate. The definitions of this parameter is outside the scope of this Recommended Standard, and its use (or non-use) is left to the application
that generates the XFDUs.”<o:p></o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph">At this point there is nothing more for me to do. I don’t know or understand why the normative annex that specified this contents of this schema file was deleted from the book itself. I see no reason why it could not have been specified
in the book as well as posted somewhere on line, just like the SLE and CSTS book all contain their ASN.1 module specifications at the same time that those modules are registered within SANA.<o:p></o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal">John<i><o:p></o:p></i></p>
</div>
</body>
</html>