[cssm] TGFT RIDs 28 and 41

Thu May 14 00:09:51 UTC 2020

John,

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 26th.

Best regards,
-Erik

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of John Pietras
Sent: Monday, May 4, 2020 16:52
To: Colin.Haddow at esa.int
Cc: CCSDS SMWG ML (smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>
Subject: [EXTERNAL] [cssm] TGFT RIDs 28 and 41

Colin,
Here are my responses to RIDs 28 and 41.

  *   RID 28, short title "in-tray". 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."
  *   RID 41, short title "Metadata to indicate sensitivity". This was simultaneously easier and harder than I originally thought it might be,

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 packageHeader: environmentInfo: extension 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 sensitivity metadata element shall apply to the XFDU Package as a whole, it must be added through the packageHeader: environmentInfo: extension element (option (a), above).

Section 4.3.4.3 (a) currently specifies that the packageHeader: environmentInfo: extension element "shall contain one tgftXfduExtension element, cast as an instance of the TgftXfduExtensionType complex schema type, which is registered in the 'urn:ccsds:schema:tgft:xfdu_extensions' namespace in the file TgftXfduExtensionParameters.xsd.
NOTE - The TgftXfduExtensionType schema type contains two metadata parameters: originator and recipient."

So the new  sensitivity element must be made part of the TgftXfduExtensionType.  I have updated the TgftXfduExtensionType schema type to add the sensitivity in the attached TgftXfduExtensionParameters.xsd file. In the context of section 4.3.4.3 (a), the Note should be changed to read
"NOTE - The TgftXfduExtensionType complex schema type contains three metadata parameters: originator, recipient, and sensitivity."

That was the simple part. Now for the hard part -  where is the actual TgftXfduExtensionParameters.xsd file that implementers will use? As late as version w0.9, the document had a normative Annex that contained the text of the TgftXfduExtensionParameters.xsd 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. Until that schema file is actually available from an identified repository (e.g., a SANA Registry), the TGFT XFDU is unimplementable because the mandatory tgftXfduExtension element has no available type specification. This is a problem whether or not the sensitivity metadata element is added. Also note that the TgftXfduExtensionParameters.xsd file also contains the mandatory TgftContentUnitExtensionType 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.]

Other sections of the TGFT spec that are problematic as a result of the unavailability of the TgftXfduExtensionParameters.xsd file are the third paragraph under F6.2.2 and the second paragraph under F6.3.2.4, both of which read: "The mechanism by which the TGFT-specific metadata is added is as a tgftXfduExtension element of the TgftXfduExtensionType complex schema type, which is registered in the 'urn:ccsds:schema:tgft:xfdu_extensions' namespace in the file TgftXfduExtensionParameters.xsd."

Finally, the NOTE under 4.3.4.3 (a) identifies that the TgftXfduExtensionType 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 TgftXfduExtensionType 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
"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."

Similarly, the NOTE under 4.3.5.3.1 identifies that the TgftContentUnitExtensionType 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
"NOTE - The TgftContentUnitExtensionType 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."

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.

Best regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200514/4349d1f2/attachment.htm>