[Smwg] TGFT comments and Actions

Ciocirlan Claudia Claudia.Ciocirlan at cnes.fr
Wed Jul 19 15:32:07 UTC 2017


Hello,

You may find in the document attached a set of questions directly linked to the white note. Maybe some of those questions were already addressed but I do not have all the context and the history.

AI 2017-0512-45 XSD verification

When "exploring" the zip file provided by John : XFDU_in_TGFT_TechNote-v0x5_Package-2017-137T16-46-00Z (3).ZIP

The file XFDU_in_TGFT_TechNote-v0x5.xml does not respect the schema provided.

It seems that the declaration of the attribute maxOccurs (.  "maxOccurs="unbounded"" ) is missing in TGFTXFDUschema.xsd, line 419. This is useful in order to allow the declaration of multiple dataObject in the dataObjectSection (the default value is 1).





White book remarks/questions

In the chapter 1.3.1.2 the CFDP metadata is addressed. Do we have any inputs for this kind of metadata and imagine how we are going to encapsulate it in TGFT?



Which is the final status of using or not using PROPFIND?  And which are the errors and the states that we should manage by TGFT?



File naming:

Using the naming convention containing the date of the beginning of the upload raises several questions:

·         it might be a risk if the suffix is not synced or if is added by hand. This means that we have to manage the possibility that the same file name is used twice.

·         Is there a special meaning if a file is already present but with a different date? If I understand it well the previous file is kept and there is no meaning or link between 2 files with the same name and a different date.



TGFT tech note

The usage of provider and user is ambiguous. In the white book the provider is the one that holds the file to be transferred and the user is the receiver. In the tech note the provider and the user are employed while talking about services or physical ground elements. The white book provider and user are replaced by provider/sender, provider/receiver, user/sender, and user/receiver This makes the comprehension pretty hard.

In the 3.2.6.6.1
"If the TGFT-using service has service-specific metadata that is applicable to individual Content Units, the serviceSpecficContentUnitExtextension element of the tgftContentUnitExtension element shall contain an instanceof a data type that contains that metadata »
The service we are talking about is the service provided by tgft or the service as is defined by the tech note ?


Global questions and remarks

·         The user side usage
we say that the provider needs a standard webdav client, but nothing is said for the user side.

·         Error cases
The simple errors seem well described in the 3.1.2 chapter but nothing is said if problems like hardware crash or network crashes occur?
Is it possible to clean the possible temporary webdav files without an impact on the others transfers to be made?
May we have a risk of incoherence between the webdav view (operation completed) and the provider point of view (operation cancelled)?

·         Date suffix

The arguments and the semantic may be better argued
For example what happens if a service user defines 2 servers (a master and a slave one) with the policy to transfer on both servers. The send files must have the same date suffix on both servers, or do we need to  use the real transfer starting date on each server?
Is the date only used for avoiding overwrite, of is the date also used to version a file? Normally this is only to avoid collisions, but in that case we can use any sort of discriminant, like an index and ask to the service provider to guaranty the unicity of this index.

·         Cleaning policy
Nothing is said on the cleaning matter.
for example how is this scenario managed?

1.       SPA send a a file fichier.ext-2017-200T12:00:00Z

2.       WebDAV makes the transfer but the connection is lost before sending the ack

3.       SUB sees the file and uses it but still lets it on the server

4.       SPA tries to resend the file and uses the same date

5.       SUB decides to delete the file (while SPA sill transfers it for the second time)...

Thanks,
Claudia


De : Barkley, Erik J (3970) [mailto:erik.j.barkley at jpl.nasa.gov]
Envoyé : mercredi 19 juillet 2017 01:51
À : Ciocirlan Claudia
Cc : CCSDS Service Mgmt WG
Objet : Response to AI re TGFT file types

Hello Claudia,

I was able to locate the attached file on my computer from the October 2013 San Antonio meeting. This was input to what was then the file transfer BOF.  The list of file types is in the first table that starts on page 1 of the attached document.

Best regards,
-Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20170719/a2687493/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 927x1w0.00_comments19072017.doc
Type: application/msword
Size: 542208 bytes
Desc: 927x1w0.00_comments19072017.doc
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20170719/a2687493/attachment.doc>


More information about the SMWG mailing list