[Smwg] FW: Updated TGFT White Book on CWE

Tue Jan 16 16:29:42 UTC 2018

From: Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.]
Sent: Wednesday, January 3, 2018 3:52 PM
To: 'John Pietras' <john.pietras at gst.com>
Cc: Barkley, Erik J (JPL-3970)[Jet Propulsion Laboratory] <erik.j.barkley at jpl.nasa.gov>; Colin.Haddow at esa.int
Subject: RE: Updated TGFT White Book on CWE

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.

First just a few easy typos:

  *   page 14 (or 1-2), in list item b) bullet q. should "vent" be "event"?
     *   in list item c) should "Post Mission" be "Post-mission"?
  *   page 16 (or 1-4), in section 1.3.2, first paragraph, last sentence, "seem" should be "seen"
  *   page 17 (or 1-5), in 2nd paragraph, "underlying TFGT" should be "underlying "TGFT"?
  *   page 19 (or 1-7), in item h) "containg" should be "containing"
  *   page 25 (or 3-1) in the first paragraph of 3.1 "Senderto" should be "Sender to"
  *   page 28, the section title for 3.2 is jumbled somehow
  *   bad reference in 3.2.1.1 part a)
  *   page 31 (or 3-7), "deliveredwith" is missing a space and "paload" should be "payload"
  *   page 34, in 4.2.5.2 "volumenInfo" looks like it has an extra n?

More substantial thoughts/comments/questions:

  1.  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).

  1.  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.

  1.  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?

  1.  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 *only*, and not really intended to fit into a REST-like architecture?

  1.  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.

  1.  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?

  1.  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?

  1.  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.

From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Sunday, November 26, 2017 5:53 PM
To: Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>
Cc: CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>) <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: [Smwg] Updated TGFT White Book on CWE

Colin,
During the Fall 2017 CCSDS Workshop, I took the action to update the TGFT White Book in two specific areas:

  1.  To add my comments on the November 2016 version of the White Book to the latest (v0.2) version (taking into account intermediate revisions and changes in concepts)
  2.  To make the user/provider, sender/recipient, etc., terminology consistent throughout the book.

I have updated the white book, which I have posted at URL
https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private%20-%20Beta/Book%20Production/Blue/Terrestrial%20Generic%20File%20Transfer/White%20Book/Drafts/Terrestrial%20Generic%20File%20Transfer%20927x1w0.02-JVP-171126.doc

Besides the two categories of changes listed above, I also:

  1.  Consolidated all file naming requirements into section 3.2.1 (these had been spread out over several sections), and
  2.  Replaced "cross support service" as the user of TGFT with the more-general "application" so as to encompass not only CCSDS cross support services but Agency-unique or situation-specific uses of TGFT.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20180116/8e1986bc/attachment.html>