<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 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Calibri Light";
panose-1:2 15 3 2 2 2 4 3 2 4;}
@font-face
{font-family:Georgia;
panose-1:2 4 5 2 5 4 5 2 3 3;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Webdings;
panose-1:5 3 1 2 1 5 9 6 7 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
h1
{mso-style-priority:9;
mso-style-link:"Heading 1 Char";
margin-top:12.0pt;
margin-right:0in;
margin-bottom:0in;
margin-left:0in;
margin-bottom:.0001pt;
page-break-after:avoid;
font-size:16.0pt;
font-family:"Calibri Light","sans-serif";
color:#2E74B5;
font-weight:normal;}
h2
{mso-style-priority:9;
mso-style-link:"Heading 2 Char";
margin-top:2.0pt;
margin-right:0in;
margin-bottom:0in;
margin-left:0in;
margin-bottom:.0001pt;
page-break-after:avoid;
font-size:13.0pt;
font-family:"Calibri Light","sans-serif";
color:#2E74B5;
font-weight:normal;}
span.MsoCommentReference
{mso-style-priority:99;}
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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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:12.0pt;
font-family:"Times New Roman","serif";}
span.Heading1Char
{mso-style-name:"Heading 1 Char";
mso-style-priority:9;
mso-style-link:"Heading 1";
font-family:"Cambria","serif";
color:#365F91;
font-weight:bold;}
span.Heading2Char
{mso-style-name:"Heading 2 Char";
mso-style-priority:9;
mso-style-link:"Heading 2";
font-family:"Cambria","serif";
color:#4F81BD;
font-weight:bold;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
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:12.0pt;
font-family:"Times New Roman","serif";}
span.PrformatHTMLCar
{mso-style-name:"Pr\00E9format\00E9 HTML Car";
mso-style-priority:99;
mso-style-link:"Pr\00E9format\00E9 HTML";
font-family:Consolas;}
p.PrformatHTML, li.PrformatHTML, div.PrformatHTML
{mso-style-name:"Pr\00E9format\00E9 HTML";
mso-style-link:"Pr\00E9format\00E9 HTML Car";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.Titre1Car
{mso-style-name:"Titre 1 Car";
mso-style-priority:9;
mso-style-link:"Titre 1";
font-family:"Calibri Light","sans-serif";
color:#2E74B5;}
p.Titre1, li.Titre1, div.Titre1
{mso-style-name:"Titre 1";
mso-style-link:"Titre 1 Car";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.Titre2Car
{mso-style-name:"Titre 2 Car";
mso-style-priority:9;
mso-style-link:"Titre 2";
font-family:"Calibri Light","sans-serif";
color:#2E74B5;}
p.Titre2, li.Titre2, div.Titre2
{mso-style-name:"Titre 2";
mso-style-link:"Titre 2 Car";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle29
{mso-style-type:personal;
font-family:"Georgia","serif";
color:#1F497D;}
span.EmailStyle30
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle31
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.begin-antispam-voting-links
{mso-style-name:begin-antispam-voting-links;}
span.end-antispam-voting-links
{mso-style-name:end-antispam-voting-links;}
span.EmailStyle34
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle35
{mso-style-type:personal;
font-family:"Calibri","sans-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:185483520;
mso-list-template-ids:-1156288358;}
@list l1
{mso-list-id:302196396;
mso-list-template-ids:-2006651072;}
@list l1:level1
{mso-level-start-at:7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2
{mso-list-id:440224650;
mso-list-template-ids:-2050209246;}
@list l2:level1
{mso-level-start-at:5;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3
{mso-list-id:767888906;
mso-list-template-ids:-2019901834;}
@list l3:level1
{mso-level-start-at:2;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4
{mso-list-id:769817644;
mso-list-template-ids:139394098;}
@list l4:level1
{mso-level-start-at:3;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5
{mso-list-id:1099332262;
mso-list-template-ids:-316491604;}
@list l5:level1
{mso-level-start-at:6;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6
{mso-list-id:1551109973;
mso-list-template-ids:-555304108;}
@list l6:level1
{mso-level-start-at:4;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7
{mso-list-id:1661542787;
mso-list-template-ids:-1154970086;}
@list l7:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l7:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l8
{mso-list-id:2016609146;
mso-list-type:hybrid;
mso-list-template-ids:-818240580 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l8:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l8:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l8:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l9
{mso-list-id:2095125093;
mso-list-template-ids:-599477352;}
@list l9:level1
{mso-level-start-at:8;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
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:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Dear all,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I have reviewed the comments that Claudia submitted on 22 December and the comments that Wes submitted on 3 January, and I have updated the TGFT XFDU Package
in response to those comments that applied to the TGFT XFDU schema, the user/provider vs. sender/receiver terminology, and typo cleanup.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The XFDU Package - xfdu_for_tgft-package.zip-2018-004T22-13-00Z - is a zipped file that conforms to the TGFT XFDU requirements (or at least it is intended to
do so) that has been posted to the CWE at URL<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><a href="https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private%20-%20Beta/Book%20Production/Blue/Terrestrial%20Generic%20File%20Transfer/White%20Book/Drafts/xfdu_for_tgft-package.zip-2018-004T22-13-00Z">https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private%20-%20Beta/Book%20Production/Blue/Terrestrial%20Generic%20File%20Transfer/White%20Book/Drafts/xfdu_for_tgft-package.zip-2018-004T22-13-00Z</a>.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The XFDU Package contain the following files:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l8 level1 lfo2"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">xfdu_for_tgft-package-manifest.xfdu. The manifest XFDU document for the package. Compared to the manifest file in the previous version of the Package,
the file name now conforms to the character set constraints for TGFT files. Other changes are identified in the detailed comments in the remainder of this email.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l8 level1 lfo2"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">XFDUschema.xsd. The original CCSDS XFDU schema file. This is unchanged from the previous version of the Package.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l8 level1 lfo2"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">TGFTXFDUschema.xsd. The schema has been updated as described in the detailed comments bellow.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l8 level1 lfo2"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">4.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Terrestrial Generic File Transfer 927x1w0.02-JVP-rev1-180103.doc. This is the most recent draft of the TGFT White Book that I have. It consists of
Colin’s version 0.02 white book with my comments and suggested re-organization of the XFDU material, PLUS changes that resulted from Claudia’s and Wes’ comments. Because the most important parts of the XFDU in TGFT Tech Note have been transferred to the TGFT
White Book, the TGFT White Book is now the authoritative document on the TGFT XFDU schema, and the Tech Note will no longer be updated.
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l8 level1 lfo2"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">5.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">tgft_xfdu_manifest_tdm_example-180103.xml. This is an update of the TDM manifest example file that appeared in previous versions of the Package. Compared
to the manifest file in the previous version of the Package, the file name now conforms to the character set constraints for TGFT files. Other changes are identified in the detailed comments in the remainder of this email. Note that this file has the .xml
extension because it is not the manifest file for <u>this</u> XFDU Package (i.e., it is simply a payload data file here). If it were the manifest file for its own XFDU Package, it would have the .xfdu extension.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Below are copies of Claudia’s and Wes’ emails. Point-by-point responses are interleaved into those email copies in
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">red</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Unfortunately, it looks like Colin won’t be back at work until the day of our next WebEx, so he will not have had the chance to look at and respond to these
inputs at that meeting.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> SMWG [mailto:smwg-bounces@mailman.ccsds.org]
<b>On Behalf Of </b>Ciocirlan Claudia<br>
<b>Sent:</b> Friday, December 22, 2017 9:39 AM<br>
<b>To:</b> Barkley, Erik J (3970); Colin.Haddow@esa.int; CCSDS SMWG ML (smwg@mailman.ccsds.org)<br>
<b>Subject:</b> [Smwg] TGFT yellow book<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="FR" style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Dear all,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR" style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">I know I am early on planning but I would like to propose you a first draft of the TGFT yellow book. It will be simpler to discuss over it in January.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in"><span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:7.0pt">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">I know it is not what we agreed on, but it is only a proposal for the cross validation. Maybe by seeing it on paper it makes more sense than explaining. This can easily be changed.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">I have a couple of questions that my contractor mentioned and as I do not have the answer I am addressing his questions and remarks to you. As the comments address to various
books and John example I rather prefer laying them in an email, but I can integrate them in the documents is needed.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Could it be possible to add this on the agenda of the 16<sup>th</sup> of January?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<h2>TGFTXFDUschema.xsd<o:p></o:p></h2>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">This schema is defined but it is not used in the example manifest sent by John. The standard XFDUschema is used instead. Is there any reason for this?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">The reason is that I wanted to make sure that the TGFT XFDU manifests were indeed still conformant to the original XFDU schema (which they were and are) and I forgot
to reset the referenced schema fil to “TGFTXFDUschema.xsd”. This change has now been made in the two manifest files and in Annex E of the TGFT White Book in the xfdu_for_tgft-package file.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">However, the TGFTXFDU schema still resides in the
</span><span style="color:red;background:white;mso-highlight:white">urn:ccsds:schema:xfdu:1</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red"> namespace. I think that my original motivation for leaving it in that namespace was
that since the TGFT XFDU schema is a subset of the XFDU schema, it could reside in the same namespace, but that may have been an incorrect assumption. Also, to truly be a “proper” subset of the XFDU schema, the TGFT XFDU schema should be formally derived from
the XFDU schema with restrictions (which we can do). We should discuss the namespace of the TGFT XFDU schema.
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">The value of this attribute of the volumeInfo element is declared fixed in the specification (section 4.2.5.4.1) but not in the schema. It could be. The specificationVersion
element shall have the value “1.0”.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">The value of the
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">specificationVersion element has been fixed to “1.0” in the TGFTXFDUschema.xsd file.</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">The specification (section 4.2.7.2.2) requires a metadataReference element in a metadataObject, however this is declared in the schema with minOccurs="0".The metadataObject
element shall contain a metadataReference element that identifies the location of the corresponding metadata file.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">The TGFTXFDUschema has been changed to have minOccurs = 1 for the
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">metadataReference element, and in figure F-12 of the draft White Book that is contained within the Package.</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">Also, because the metadataSection is present only if there is at least one metadataObject, the minOccurs for the metadataObject must be 1 instead of 0 (zero). This
has been changed in the TGFTXFDUschema and in figure F-12 of the draft White Book that is contained within the Package. It has also been clarified in 4.2.4 (c) of the draft White Book.</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">The specification (section 4.2.8.2.2) requires a single byteStream element in a dataObject, however the schema specifies an unbounded number. The dataObject element shall
contain one byteStream element. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">The TGFTXFDUschema has been changed to have maxOccurs = 1 for the
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">byteStream element. (Curiously, the XMLSpy diagram for the dataObjectSectionType was already corrected in the draft White Book – I must have made the change in the copy of the
schema file that I used to generate the diagrams but failed to include it in the schema file that I distributed.)</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<h2>Standard white book 927x1w0.02<o:p></o:p></h2>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">PackageHeader ID (section 4.2.5.1.a)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">The remark below relates to the use of “shall” in the specification. Shall has a strong meaning as a conformance requirement. However in the cases below, this requirement
may be changed by the TGFT-using services, and thus not respected. A different wording without shall would be preferable.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">The ID attribute of the packageHeader element shall have the default value of “pkgHdr”. However, TGFT-using service may define their own values for the ID attribute.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">The intent of this statement was that if the creator of the Package does not have their own value for the ID attribute, then the value should be set to “pkgHdr”.
In general terms, I believe that is what is meant by “default value” – it is the value unless specifically overridden.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">However, the XML Schema definition of “default” has particular semantics that prohibit assigning a default value to a required attribute such as ID. So instead
of using “default” and risking confusion, the requirement in 4.2.5.1 (a) has been rephrased in the draft White Book to read “The ID attribute of the packageHeader element shall have either (1) a value that is relevant to the TGFT-using application or (2)
the value “pkgHdr”.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">SequenceInformation (section 4.2.5.5.2)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">This is similar to the previous remark, with the use of a shall. The sequencePosition attribute shall contain the numerical position of the XFDU in the XFDU sequence. The
semantics of this attribute are deferred to the specification of the service.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">The sequenceSize attribute shall contain size of the XFDU sequence to which this SFDU belongs. The semantics of this attribute are deferred to the specification of the service.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">In both cases, “shall” has been changed to “is intended to be used to”.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">MetadataObject<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">A requirement in section 4.5.3 looks inconsistent with the rest of the document. The TGFT XFDU package shall contain one enclosed metadata files for every metadataObject
element in the metadataSection of the XFDU manifest. A metadata file may not be included in the XFDU package (cf for example section 4.2.7.3.1.c.2).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">Good catch! 4.5.3 has been changed to read “</span><span style="color:red">The TGFT XFDU package shall contain one enclosed metadata file for every
<b>metadataObject</b> element in the <b>metadataSection</b> of the XFDU manifest for which the
<b>metadataReference</b> element has an <b>href</b> value that begins “file:”.”</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Naming rules<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Inconsistencies exist in the naming rules (section 4.5.4.*) and their example usages (Annex E). In the annex the XFDU zip file is named dss_25_validated_tdm_xfdu_package-2017-
058T23-15-46Z.zip. When the timestamp part defined in 4.5.4.2 is removed, the servicespecific part should remain as defined in 4.5.4. The service-specific part should then be dss_25_validated_tdm_xfdu_package- and not dss_25_validated_tdm_xfdu_package as shown
in the example. Nothing is said in 4.5.4 about adding a dash in between.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">Thanks for pointing out these inconsistencies. The timestamped name of the XFDU package should be “</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">dss_25_validated_tdm_xfdu_package.zip-2017-058T23-15-46Z”
so that when the timestamp part is discarded the original file name remains. I agree that Colin’s rules for combining the service-specific part and the timestamp part did not explicitly include the dash between them in 4.5.4, but his example in 3.2.1
<u>did</u> include the dash (<i>file_name.file_type-YYYY-DDDThh:mm:ssZ</i>). <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">In the consistency and consolidation changes that I proposed to Colin in November, I proposed to explicitly add the dash as part of the syntax of the transferred
XFDU Package name. The new name syntax is specified in section 3.2.1.1 of the updated draft TGFT White Book that is contained in the zipped package that I just uploaded to the CWE.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">Also, the name of the example transferred XFDU Package Annex F has been changed in the draft TGFT White Book.</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Manifest file<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Few rules apply to the naming of the XFDU manifest file. However, looking at the examples, I wonder if one rule could be added concerning the location of this file. I expected
it to be found at the top level in the archive, however it has been set in the first level directory.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">I don’t understand this question. Let’s talk about it at the January WebEx.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Annex E<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">The name of the file (dss_25_validated_tdm-2017-058T19-35-24Z.xml) does not conform to the naming rule in section 3.2.1. The upper case letters are forbidden. The Zulu time
exception described in the specification only concerns the name of the archive itself, not the files inside it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">The reference to the file (href attribute) does not conform either to the specification as defined in section 4.2.8.4.1.c. The Zulu time part of the archive name should be
removed from the directory part of the href. The href attribute shall contain the URL of the file, which shall be of the form “file:”+<XFDU Package file name service-specific part> + ”/” + <payload file name (with extension><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">Colin and I discussed (in October or November 2016, I believe) the applicability (or lack thereof) of the file-naming constraints and agreed that they should NOT
apply to the payload and metadata file names because (a) TGFT sees only the name of the XFDU Package file and (b) the applications/domains that generate the payload data and metadata files that are contained within the XFDU Package may have their own file-naming
conventions. The exemption of the payloads data file and metadata file names from the file-naming constraints was documented in sections 4.3.2 and 4.4.2 of the version 0.02 TGFT White Book but unfortunately this was not correctly reflected in section 3.2.1.
It is one of the items that I cleaned up in the set of suggested changes that I made to Colin in November – see the revised section 3.2.1 of the draft TGFT White Book that is included in the XFDU Package described above.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">The file with the name “dss_25_validated_tdm-2017-058T19-35-24Z.xml” is a payload data (and thus exempt from the TGFT Manifest/Package naming conventions) and the
“2017-058T19-35-24Z” portion of the filename refers to the time at which the tracking data stopped being acquired. The use of the timestamp in this case is presumed to be part of the (hypothetical) Validated Radiometric Data cross support service file naming
convention. However, I can now see that the use of the same timestamp format as that of the transferred TGFT XFDU Package name can be confusing. Therefore I have changed the name in the example to use a time/data stamp that follows the
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">XSD datetime format (<a name="INDEX-198">CCYY-MM-DDThh:mm:ss</a>Z). Thus the filename in the example has been changed to
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">“dss_25_validated_tdm-2017-02-07T19-35-24Z.xml” to emphasize that this filename data/timestamp is not related to the TGFT XFDU Package file name conventions.</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<h2>TGFT/XFDU manifest<o:p></o:p></h2>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">XFDU version<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">The version attribute is declared while it should not be (cf section 4.2.3.b). The optional version attribute shall be absent when the XFDU schema defined in Issue 1 (September
2008) of reference [9] is used as the schema for TGFT XFDUs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">Thanks for catching that. The version attributes have been deleted from both the manifest for the TGFT documentation package and the example TDM manifest.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">PackageHeader ID<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">This attribute is set to “PkgHdr” instead of “pckHdr” (cf section 4.2.5.1.a). The ID attribute of the packageHeader element shall have the default value of “pkgHdr”. However,
TGFT-using service may define their own values for the ID attribute. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">As described above under the Package Header ID section, the intention was that an application could set its own value for the ID, or it could “default” to “pkgHdr”.
The real driver here is that since the ID field is mandatory in this CCSDS-standard ID attribute, “something” must be supplied and the value “pkgHdr” could be used if the application had no specific use for this attributeTechnically, “PkgHdr” can be viewed
as an application-specific use for this attribute and is valid. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">File naming
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">The file names include upper case letters which are forbidden by the specification (cf section 3.2.1). This remark may lead to reconsider this rule. One of the files in
the example package is the XSD schema. Its name is TGFTXFDUschema.xsd, and this name could/should be included in the xml files that conform to the schema. If we rename the file to tgft_xfdu_schema.xsd for example, to conform to the specification, then the
XML file will loose its reference to its model.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">As noted above, the file naming conventions apply to
<u>only</u> the manifest and package files names, TGFTXFDUschema.xsd is a payload data file and is therefore not required to follow the convention. Similarly, the XFDUschema.xsd file is also a payload data file, and it is a good example of why payload data
and metadata file names are exempt from the convention, since the name of the file was assigned by the CCSDS Navigation WG.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Similar issues are very likely to occur in the TGFT use cases, as the example in Annex E shows. Are these issues been identified? Has a proper handling procedure been suggested?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">I think that we will avoid similar issues now that we have made the file-naming convention apply to only the manifest and package file names.</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Size<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">The size attributes provided in the example do not match the actual size of the files as I see them on my PC (Windows). Is this just an update issue of the values, or is
there something more?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">I forgot to update the sizes when I modified the contents of the files within the zipped folder. That has been corrected in the latest manifest.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Wish you all Merry Christmas and a veyyrryyyy happpyyyy new year!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Claudia<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><b><span lang="IT" style="font-size:9.0pt;font-family:"Arial","sans-serif"">Claudia Ciocirlan
</span></b><span lang="IT" style="font-size:9.0pt;font-family:"Arial","sans-serif"">CNES/DNO/OP/SSO<b><o:p></o:p></b></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial","sans-serif"">Mission Operations Ground Segment<br>
phone : +33 (0)5 61 28 17 11<br>
email : </span><a href="mailto:claudia.ciocirlan@cnes.fr"><span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:blue">claudia.ciocirlan@cnes.fr</span></a><span style="font-size:9.0pt;font-family:"Arial","sans-serif""><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="FR" style="font-size:14.0pt;font-family:Webdings;color:green">P</span><span lang="FR" style="color:black">
</span><i><span style="font-size:8.0pt;font-family:"Arial","sans-serif";color:green">Save a tree ! Think before printing
</span></i><b><span style="font-size:9.0pt;font-family:"Arial","sans-serif""><o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<pre><span style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></pre>
<pre><span style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></pre>
<div>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span lang="FR" style="font-size:13.5pt;color:black;background:white">
<hr size="2" width="100%" align="center">
</span></div>
<p class="MsoNormal" align="center" style="text-align:center"><span lang="FR" style="font-size:13.5pt;color:black;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.] [mailto:wesley.m.eddy@nasa.gov]
<br>
<b>Sent:</b> Wednesday, January 03, 2018 3:52 PM<br>
<b>To:</b> John Pietras<br>
<b>Cc:</b> Barkley, Erik J (JPL-3970)[Jet Propulsion Laboratory]; Colin.Haddow@esa.int<br>
<b>Subject:</b> RE: Updated TGFT White Book on CWE<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi John, I took a look at your draft, and here are a few comments, questions, and typo catches on the TGFT book you posted. I copied Erik and Colin, but don’t know if this is something the rest of the working group would normally be interested
in, or if comments are typically just unicast to the book editors.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">First just a few easy typos:<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="mso-list:l7 level1 lfo3">page 14 (or 1-2), in list item b) bullet q. should "vent" be "event"?
<o:p></o:p></li></ul>
<ul style="margin-top:0in" type="disc">
<ul style="margin-top:0in" type="circle">
<li class="MsoNormal" style="mso-list:l7 level2 lfo3">in list item c) should "Post Mission" be "Post-mission"?<o:p></o:p></li></ul>
</ul>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="mso-list:l7 level1 lfo3">page 16 (or 1-4), in section 1.3.2, first paragraph, last sentence, "seem" should be "seen"<o:p></o:p></li><li class="MsoNormal" style="mso-list:l7 level1 lfo3">page 17 (or 1-5), in 2nd paragraph, "underlying TFGT" should be "underlying "TGFT"?<o:p></o:p></li><li class="MsoNormal" style="mso-list:l7 level1 lfo3">page 19 (or 1-7), in item h) "containg" should be "containing"<o:p></o:p></li><li class="MsoNormal" style="mso-list:l7 level1 lfo3">page 25 (or 3-1) in the first paragraph of 3.1 "Senderto" should be "Sender to"<o:p></o:p></li><li class="MsoNormal" style="mso-list:l7 level1 lfo3">page 28, the section title for 3.2 is jumbled somehow<o:p></o:p></li><li class="MsoNormal" style="mso-list:l7 level1 lfo3">bad reference in 3.2.1.1 part a)<o:p></o:p></li><li class="MsoNormal" style="mso-list:l7 level1 lfo3">page 31 (or 3-7), "deliveredwith" is missing a space and "paload" should be "payload"<o:p></o:p></li><li class="MsoNormal" style="mso-list:l7 level1 lfo3">page 34, in 4.2.5.2 "volumenInfo" looks like it has an extra n?<o:p></o:p></li></ul>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:red">All of the typos have been corrected<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">More substantial thoughts/comments/questions:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="mso-list:l0 level1 lfo4">On page 27 (or 3-3) in the 2nd paragraph, I think the service provider/user terminology should more correctly be file sender/receiver (as the terminology is discussed earlier in the document).<o:p></o:p></li></ol>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">There were several user/provider, source/recipient, etc., roles described in the White Book, and they were not used consistently. I took
a stab at reworking the relationships and proposed them to Colin in November. The resulting “homogenization” of those terms is present in the draft TGFT White Book that is contained in the latest Package on the CWE. Without repeating all of the new proposed
definitions, in light of those (proposed) new definitions, the sentence to which you are referring has changed from<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:red">“</span><span style="color:red">The PROPFIND method thus enables the service provider to retrieve the properties of the directory hierarchy of the service user system and can thus check that
the file has successfully been transferred.</span><span style="color:red">”</span><span style="font-family:"Calibri","sans-serif";color:red">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">to</span><span style="color:red"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:red">“The PROPFIND method thus enables the
<u>file source</u> to retrieve the properties of the directory hierarchy of the <u>
TGFT Receiver</u> and can thus check that the file has successfully been transferred.</span><span style="color:red">”</span><span style="color:red">
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red"> where “file source” refers to the entity (e.g., application, operator) that uses TGFT to send the file, and “TGFT Receiver” is the host
computer that receives the file.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">Note that in this particular case, however, the use of PROPFIND is under question and this whole subsection may disappear.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">This is the extent to which I can respond to your comments. Colin and/or the rest of the working group will have to address your remaining comments.<o:p></o:p></span></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<ol style="margin-top:0in" start="2" type="1">
<li class="MsoNormal" style="mso-list:l3 level1 lfo5">In section 1.8, why are TLS 1.0 and 1.1 references provided in addition to TLS 1.2? It wasn’t clear if there is some technical or practical reason. Both are obsoleted, and TLS 1.3 is going to be standardized
soon, so it's not clear why anything more than just 1.2 would make sense.<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="3" type="1">
<li class="MsoNormal" style="mso-list:l4 level1 lfo6">Is TGFT only intended to work with HTTP 1.1 and not HTTP/2? maybe this is related to relying on WebDAV, since it's unclear if people are using these together yet in industry? Maybe this is something to
bookmark for future work, but not worry about now, since the software tooling available predominately supports 1.1 and it isn’t really obsolete yet?<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="4" type="1">
<li class="MsoNormal" style="mso-list:l6 level1 lfo7">It probably doesn't matter much in practice as TGFT is envisioned to be used, but there may be some friction between use of "file" concepts in TGFT versus more generic concept of "resources" in HTTP. In
the HTTP server, the resources are often stored and managed as files, but definitely not always (e.g. in the case of REST applications, etc). I doubt this is a real issue for us at the moment, but maybe just a terminology question to think about, if perhaps
there is some use case where the XFDUs and contents are processed straight to/from database entries or something. That would be more like a typical REST application, and I guess TGFT is using HTTP and WebDAV for transport of XFDUs as files *<b>only</b>*,
and not really intended to fit into a REST-like architecture?<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="5" type="1">
<li class="MsoNormal" style="mso-list:l2 level1 lfo8">For cross-system compatibility, TGFT limits the valid characters that can be used in the filename, but I didn't notice a limit on the length of a filename? It seems like there should be a limit on the number
of characters for similar compatibility reasons.<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="6" type="1">
<li class="MsoNormal" style="mso-list:l5 level1 lfo9">Should there be a limit to the size of files and/or XFDUs? Maybe this is something for appendix A, in addition to the data volume already there?<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="7" type="1">
<li class="MsoNormal" style="mso-list:l1 level1 lfo10">In 3.3, there is a suggestion to append a hash value within the filename with a colon separator, but the colon is illegal in filenames in some systems, and adding it could make the filename too long?<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="8" type="1">
<li class="MsoNormal" style="mso-list:l9 level1 lfo11">Hash values or signatures can just be provided separately in files on the side, if needed. This is how it's done normally for large downloads on the Internet like Linux installation images, signed RPM
files, etc. I don’t think doing anything fancier (like embedding in the filename) adds value, and probably creates complexity.<o:p></o:p></li></ol>
<p class="MsoNormal" align="center" style="text-align:center"><span lang="FR" style="font-size:13.5pt;color:black;background:white"><o:p> </o:p></span></p>
</div>
</div>
</div>
</body>
</html>