<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:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" 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: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:12.0pt;
font-family:"Times New Roman",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:1177158321;
mso-list-type:hybrid;
mso-list-template-ids:1603455546 -432734470 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:1.75in;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:3.25in;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:4.75in;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1292516882;
mso-list-type:hybrid;
mso-list-template-ids:-1476986694 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:1841771204;
mso-list-type:hybrid;
mso-list-template-ids:-605101580 982812724 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
{mso-level-number-format:alpha-lower;
mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:1.75in;
text-indent:-9.0pt;}
@list l2:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:3.25in;
text-indent:-9.0pt;}
@list l2:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:4.75in;
text-indent:-9.0pt;}
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:12.0pt;font-family:"Georgia",serif;color:#1F497D">John,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">I know we discussed this a bit at the teleconference yesterday but I have also provided some comments which are listed below.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">-Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.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> Tuesday, May 1, 2018 11:41 AM<br>
<b>To:</b> CCSDS SMWG ML (smwg@mailman.ccsds.org) <smwg@mailman.ccsds.org><br>
<b>Subject:</b> [Smwg] updated draft TGFT on CWE<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">CSSMWG colleagues ---<o:p></o:p></p>
<p class="MsoNormal">At the Gaithersburg meeting, we discussed several items raised by Claudia that she and her team discovered during TGFT prototyping. I took that action to update the TGFT White Book. I have performed the update (to v0.4) and posted it to
the CWE at URL <o:p></o:p></p>
<p class="MsoNormal"><a href="https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Terrestrial%20Generic%20File%20Transfer/White%20Book/Drafts/927x01w0.4%20-%20Terrestrial%20Generic%20File%20Transfer-180501.doc">https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Terrestrial%20Generic%20File%20Transfer/White%20Book/Drafts/927x01w0.4%20-%20Terrestrial%20Generic%20File%20Transfer-180501.doc</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">What follows is my reconstruction of the major discussion points and how they have led to the changes in the updated White Book. Please review these point to see if they accurately reflect your recollection of the decisions made at the
meeting.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">However, before going into the recap of the meeting, I’d like to raise a concern that occurred to me while I was making the updates. According to the White Book, each Agency has a single “in-tray” for all files received from another Agency.
Since TGFT is expected to be used for multiple applications/services concurrently, this means that there may be files for different applications residing in the in-tray. How does the Receiver distinguish, for example a Return File Service file (contain spacecraft
telemetry) from a validated Radiometric Data file? Because there are no file naming conventions that could be used to differentiate between the applications that created the files (theoretically, TGFT would be perfectly happy if all files were simply named
“myData-<timestamp>.zip”) I had put into the TGFT XFDU definition that the packageType attribute of the informationPackageMapType (see F6.3.1 of the White Book) is required to be present and used to distinguish the applications. This requires that any “sorting”
application of the receiving end burrow down into the XFDU Manifest to read this attribute to determine how to process the XFDU Package. To my knowledge we’ve never discussed this. Is it acceptable, and is this the method for file differentiation that is being
used in the prototypes? If it is acceptable, then I still think that we need some sort of SANA Registry to register the different standard (string) values of packageType. If it’s not a good way to do this (e.g., because it requires looking into the Manifest
file within the compressed XFDU Package file) then how should we handle it?<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">eb> Certainly the idea of registering the different file types has always been part of the TGFT concept as best as I can recall. I realize that you are also looking
at the identification within the XFDU package. I believe that as a result of the teleconference yesterday Colin as a subsequent action item for further consideration in this regard.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal">John <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraph" style="margin-bottom:12.0pt;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>The <span style="font-family:"Courier New"">dataObjectPointer</span> type was erroneously called “dataPointerObject” in multiple instances in the text of the TGFT book. This has been fixed in the latest update.<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>The standard CCSDS XFDU provides two schema extension mechanisms as part of the<span style="font-family:"Courier New""> environmentInfo</span> element of the
<span style="font-family:"Courier New"">packageHeaderType</span>: the<span style="font-family:"Courier New""> xmlData</span> element containing unstructured XML, and the
<span style="font-family:"Courier New"">extension</span> element by which the XFDU schema can be extended through the use of an XML type. The TGFT XFDU formally specifies that the
<span style="font-family:"Courier New"">extension</span> element is the specified mechanism for extensions to the schema for the base TGFT service, and that such extensions must be done through the
<span style="font-family:"Courier New"">TgftXfduExtensionType</span> complex schema type. However, the TGFT XFDU specification does not forbid any user-application-specific use of the (unstructured)
<span style="font-family:"Courier New"">xmlData</span> elements. Claudia suggested that the
<span style="font-family:"Courier New"">xmlData</span> element be explicitly forbidden to be used in TGFT XFDUs.<br>
<br>
In Gaithersburg, we discussed the difference between what additional metadata might be standard for *<b>all</b>* TGFT XFDUs and metadata that a TGFT-using application might need to add to the XFDU for its own application-specific purposes. Examples of extension
metadata that is common to all TGFT XFDUs are<span style="font-family:"Courier New""> originator</span>,
<span style="font-family:"Courier New"">recipient</span>, and <span style="font-family:"Courier New"">
creationDate</span>, where <span style="font-family:"Courier New"">originator</span> and
<span style="font-family:"Courier New"">recipient</span> are included in the <span style="font-family:"Courier New"">
TgftXfduExtensionType</span> complex schema type because they apply to the whole XFDU Package, and
<span style="font-family:"Courier New"">creationDate</span> is in the <span style="font-family:"Courier New"">
TgftContentUnitExtensionType</span> because it applies to each individual Content Unit (i.e., payload data file) within the XFDU Package.<br>
<br>
We agreed that (a) extension metadata that is common to all TGFT XFDUs (and thus part of the TGFT standard itself) must be contained in the
<span style="font-family:"Courier New"">TgftXfduExtensionType</span> or <span style="font-family:"Courier New"">
TgftContentUnitExtensionType</span> complex schema types, and (b) TGFT-using applications *<b>may</b>* use
<span style="font-family:"Courier New"">xmlData</span> elements for adding application-specific metadata that applies to the XFDU Package as a whole. I agreed to review the description of this distinction in the TGFT book and clarify it if necessary. I have
since looked at the relevant sections of the TGFT book and have concluded that it is indeed ambiguous and in need of clarification. As the result:<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l2 level1 lfo4">
<![if !supportLists]><span style="mso-list:Ignore">a)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>I’ve reworded the text to state that the recommended extension mechanism for adding TGFT-using application-specific metadata that applies to the XFDU Package as a whole is through the addition of another
<span style="font-family:"Courier New"">environmentInfo</span> element containing an
<span style="font-family:"Courier New"">extension</span> element. <o:p></o:p></p>
<p class="MsoListParagraph" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.75in;text-indent:-.25in;mso-list:l2 level1 lfo4">
<![if !supportLists]><span style="mso-list:Ignore">b)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>I’ve added a NOTE that says that TGFT-using applications may also use
<span style="font-family:"Courier New"">xmlData</span> elements, but any such usage is outside the scope of TGFT and must be documented as part of the specification of the TGFT-using application.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">eb> That sounds reasonable to me. I'd like to get Claudia's take on your note as obviously this does not explicitly forbid the use of
xmlData element. <o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>We also discussed the inconsistencies in the construction of the XFDU Package file names and the href elements in the XFDU Manifest that point to the files contained in the XFDU Package. As we discussed, I have attempted to fix these
inconsistencies by reformulating the XFDU Package file name (as transferred by the TGFT Sender tot the TGFT Receiver) as having three components:<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo6">
<![if !supportLists]><span style="mso-list:Ignore">a.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>the <i>package folder name part</i>;<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo6">
<![if !supportLists]><span style="mso-list:Ignore">b.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>the <i>compressed folder file extension type</i>; and<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo6">
<![if !supportLists]><span style="mso-list:Ignore">c.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>the <i>timestamp part</i>.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">The <i>package folder name part</i> is the name of the folder (subdirectory) that contains all of the files contained within the XFDU Package: the manifest file, any payload data files, and any contained metadata
files. The <i>compressed folder file extension type</i> is the extension that specifies which compression method (“.zip” or “.tar”) has been used to compress the folder into a single file for transmission.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">We also agreed that the compressed folder file extension type would be at the end of the XFDU Package file name (in the “normal” position for a file name). This, when an XFDU Package “folder” that has the folder
name “XXX” is compressed using ZIP, it has an original compressed package file name “XXX.zip”. When that file is subsequently transmitted from the TGFT Sender to the TGFT Receiver, the TGFT Sender inserts a timestamp part to form the as-transmitted file named
“XXX-<timestamp part>.zip”. As we agreed, when the file XXX-<timestamp part>.zip is subsequently unzipped on the TGFT Receiver side, the uncompressed folder is simply name “XXX” – that is, timestamp part is lost. I have reworked the daft White Book in accordance
with these understandings.<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">(eb> well it might be a rather daft undertaking but I will take this as the draft white book :-) )<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><br>
<br>
<u>NOTE – Section 3.3 (Security) of the White Book identifies a security mechanism that includes post-pending a SHA-2 hash value to the file name. However, to my knowledge a final decision on this approach has not been reached, and the following discussion
does not address this aspect of the file name. If such a post-pended hash value is added to the standard, the exact syntax should be addressed in section 3.2.1.1 (XFDU Package File Names).</u><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">eb> yes, here again, for the benefit of those not in the teleconference, Colin will be taking a look at this.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoListParagraph" style="margin-bottom:12.0pt;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="mso-list:Ignore">4.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>The next issue raised by Claudia was in regard to inconsistent naming in the example in Annex E. These errors were the result of my changing the timestamp for the TDM file from CSDS time code B to xsd:datetime format but not propagating
the change throughout the example (2017-058 and 2017-02-27 are both 27 Feb 2017). These have been corrected.<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">5.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>This next item is not one that was explicitly initiated by Claudia, but is a result of my looking into the issues that Claudia raised. The
<span style="font-family:"Courier New"">TgftXfduExtensionType</span> complex schema type has three elements, two (<span style="font-family:"Courier New"">originator</span> and
<span style="font-family:"Courier New"">recipient</span>) of which represent TGFT metadata that the CSSMWG put forward in the TGFT brainstorming session in Rome (which of course I did not attend) as candidate metadata elements that do not otherwise appear in
the CCSDS-standard XFDU, and the third (<span style="font-family:"Courier New"">crossSupportServiceType</span>) is something that I added because it seemed like something useful (note that not all TGFT XFDUs will necessarily be generated by cross support services:
there may be Provider CSSS-unique or Mission-unique uses of TGFT. In such XFDUs, the optional
<span style="font-family:"Courier New"">crossSupportServiceType</span> would not appear).
<br>
<br>
All three elements (<span style="font-family:"Courier New"">originator</span>, <span style="font-family:"Courier New"">
recipient</span>, and <span style="font-family:"Courier New"">tgftUsingApplicationType</span>) are currently of type String, and otherwise undefined. At what level are originator and recipient defined – Provider CSSS/Mission, individual ground station/Mission
facility, etc.? Where are the valid values of <span style="font-family:"Courier New"">
originator</span> and <span style="font-family:"Courier New"">recipient</span> defined and/or registered? Do we need to register the values of
<span style="font-family:"Courier New"">crossSupportServiceType</span>, in order to ensure that different user applications don’t use the same value? I’ve flagged these issues as comments in the TGFT White Book.<o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">eb> I am not sure that I follow. In the first paragraph of item 5 the three elements are called out as originator, recipient, and crossSupportServiceType and the second
paragraph says that the three elements are </span><span style="font-family:"Courier New"">originator</span>,
<span style="font-family:"Courier New"">recipient</span>, and <span style="font-family:"Courier New"">
tgftUsingApplicationType. </span><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">In any case, it does not seem to me that the cross support service type adds anything? -- especially if the various types of files are already registered
in SANA. <o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>