ACP 137

More documents

Recommendations

Info

UNCLASSIFIED ACP 137 SEQUENCING OF GRIFFIN EXCHANGES 446. Since a receiving nation cannot fully verify the correct sequencing of received Griffin exchanges based on creation date alone, Datafile Sequence Numbering is used to ensure continuity of import operations and to mitigate problems that could cause potential import errors or corrupt data because a receiving nation unknowingly missed a Griffin exchange (e.g. system error causing one or more messages containing data file attachments not to be sent or received, or even duplicated). Each sending nation will maintain separate Datafile Sequence Numbers (DSNs) starting at zero for each receiving nation (or Replication Area per Nation), and will increment the corresponding DSN by one each time a Griffin exchange is sent to a receiving nation. Once a DSN reaches 9999, it should be reset to start at zero again. 447. It is the responsibility of a receiving nation to keep track of DSNs from sending nations such that it can be determined that a data file was not received (e.g. nation last received a file with DSN 74 and now has received a file with DSN 76) or was duplicated. If an exchange is missing, the receiving nation should email or send a military message to the sending nation requesting the missing exchange, specifying the particular DSN or requesting a new initial or verify data file (as defined in paragraph 208). If an initial exchange is sent, it will contain a new DSN of zero. Hence, it is the responsibility of the sending nation to archive Griffin data files and have the capability to process such special updates. 448. It should be noted that where segmentation is in place (see paragraph 415), the same DSN will be used for all segments within the exchange. DATA FILE SEGMENTATION 449. In the case of large data sets, which exceed the maximum message transfer file limits, and where compression or other mechanisms are not suitable for reducing the size of the data, the use of Data File Segmentation may be considered. It is strongly advised that the Maximum Data File size which may be transferred is configurable, as should be the Maximum Segment Size which may be sent. Where segmentation is required, the data set is segmented into multiple files (each smaller than the configurable Maximum Segment Size), each of which is sent in order in a separate message. 450. Management of the receipt of the segment and the re-composition of the original data set is the responsibility of the receiving nation, which may need to request retransmissions from the sender nation if required (see paragraph 465). In order to assist with this process, the message header is modified in a number of areas, maintaining backwards compatibility as much as possible. 451. The file naming policy is modified to support segmentation by placing a file segment number following the Universal Time (UTC), with zero being used to indicate a nonsegmented file. The Sequence Number line is modified to add additional (colon separated) fields where sequencing is being performed. Following the Datafile Sequence Number, which is the same for all messages in the sequence, is a Segment Sequence Number (starting at 1 for 4-10 UNCLASSIFIED Original
UNCLASSIFIED ACP 137 the first segment), a Highest Segment Sequence Number and a Hash Value for the complete Data set (the latter two being mandatory for the first segment, optional for others). 452. Segmented data files (other than the first) will not contain a heading since this would make it impossible to reconstitute the file exactly on receipt, and thus would invalidate the complete file checksum. 453. Experience with certain Griffin gateways has indicated that additional End of Line (i.e. CR/LF combinations) may be added unless a text attachment terminates in an End of Line sequence, which causes checksum checking to fail. In light of these discoveries, it is required that segmenting only occurs at the end of a line when sending text files. Implementations should preferably truncate files on the line before the segment size if reached, although receiving nations should cope with slightly more. Implementations should also ensure that segment sizes slightly larger than the agreed and configured limit should be supported on receipt to cater for the case where segmentation occurs at the line immediately following the maximum segmentation size (since LDIF lines are typically 80 characters or less, an increased allowance up to say 100 characters should be adequate). 454. It should be noted that while segmented messages should be sent in ascending sequence, they may not be received in the same order, since the underlying messaging systems cannot guarantee order of delivery. The precedence of messages is for bilateral agreement between nations, but may be dependent upon message size, urgency etc. DATA FILE FORMATS 455. Replicated data will initially be sent using the LDIF data file format [Ref. 3]. However, it is envisaged that in the future, other data file formats may be allowed, although these have not yet been defined. It is appropriate therefore to incorporate a mechanism to allow the format of a data file to be specified by the sending nation for use by the receiving nation. It is the responsibility of the receiving nation to accept all supported formats. 456. The format of data file transmitted may be specified by the optional keyword format within the Control Information in the message body text, followed by a keyword specifying the format of the data file. The only value currently allowable is LDIF (which may be specified). If the keyword is not present, the default of LDIF is assumed. COMPRESSION FORMATS 457. The use of compressed data, is allowed by some nations, dependent upon security and networking constraints. Compressed data would greatly reduce the amount of network traffic in transferring large data files. An optional keyword compression is allowed in the Control Information to specify that compression is being used. Allowable values are currently restricted to NONE indicating no compression is present or ZIP indicating use of Zip file compression. If the keyword is not present, the default of NONE is assumed. 458. Where data is compressed, the compression should be performed on the complete set of data before segmentation. Where segmentation is also required, each segment comprises a 4-11 Original UNCLASSIFIED
Page 1 and 2: UNCLASSIFIED ACP 137 GRIFFIN DIRECT
Page 3 and 4: UNCLASSIFIED ACP 137 THE COMBINED C
Page 5 and 6: UNCLASSIFIED ACP 137 TABLE OF CONTE
Page 7 and 8: UNCLASSIFIED ACP 137 IMPLEMENTATION
Page 9 and 10: UNCLASSIFIED ACP 137 104. Figure 1
Page 11 and 12: UNCLASSIFIED ACP 137 email service
Page 13 and 14: UNCLASSIFIED ACP 137 CHAPTER 3 GRIF
Page 15 and 16: UNCLASSIFIED ACP 137 c. user@js.pen
Page 17 and 18: UNCLASSIFIED ACP 137 INFORMAL EMAIL
Page 19 and 20: UNCLASSIFIED ACP 137 330. A number
Page 21 and 22: UNCLASSIFIED ACP 137 CHAPTER 4 GENE
Page 23 and 24: UNCLASSIFIED ACP 137 SCHEMA c. Nati
Page 25 and 26: UNCLASSIFIED ACP 137 417. Nations w
Page 27 and 28: UNCLASSIFIED ACP 137 428. This shou
Page 29: UNCLASSIFIED ACP 137 INDICATION OF
Page 33 and 34: UNCLASSIFIED ACP 137 d. Precedence
Page 35 and 36: UNCLASSIFIED ACP 137 i. Nations wil
Page 37 and 38: UNCLASSIFIED ACP 137 f. Underscore
Page 39 and 40: UNCLASSIFIED ACP 137 automatically
Page 41 and 42: UNCLASSIFIED ACP 137 c. The replica
Page 43 and 44: UNCLASSIFIED ACP 137 BACKWARDS COMP
Page 45 and 46: UNCLASSIFIED ACP 137 g. Multivalued
Page 47 and 48: Schema Type UNCLASSIFIED Source: Id
Page 49 and 50: UNCLASSIFIED ACP 137 Schema Type So
Page 55 and 56: UNCLASSIFIED REFERENCES ACP 137 1.
Page 57 and 58: UNCLASSIFIED DEFINITIONS ACP 137 Ab

ACP 137

Create successful ePaper yourself

Delete template?

Save as template?