ACP 137
ACP 137
ACP 137
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
UNCLASSIFIED<br />
<strong>ACP</strong> <strong>137</strong><br />
email service may still be employed in parallel with the MM transport mechanism. This will<br />
allow the directory information necessary to set up the MM service itself to be replicated<br />
between nations, although the mechanism for initially sharing addresses to be employed<br />
between nations would be subject to bilateral agreement, and may include hand carrying of<br />
data.<br />
DATA INTEGRITY<br />
207. There are two primary concerns to be considered in terms of the data integrity of the<br />
transferred LDIF file:<br />
a. There is a need to ensure the LDIF file received by a nation has not been<br />
inadvertently corrupted. Different transport services provide different levels of<br />
capability for ensuring message integrity. In view of this, the Griffin DS will provide<br />
its own internal mechanisms to allow data integrity to be assured. This will be<br />
accomplished using a Hash value calculated from the data before it is sent and carried<br />
in the message to allow its verification at the receiving nation. Note that the Hash is<br />
not intended to protect against malicious changing of data since it is assumed that this<br />
would not happen on Griffin, and hence no further protection of the Hash is provided.<br />
b. There is also a requirement that sending nations may not include LDIF entries<br />
for which they do not hold the master copy. Receiving nations must ensure they<br />
reject the entire file where the sending nation does not hold the master copy of all<br />
entries received (e.g. any nation receiving a UK entry in the US LDIF file should<br />
reject the file, specify the reason for rejection and request a retransmission).<br />
DATA VOLUMES<br />
208. It is anticipated that the Griffin DS will need to support much larger interchange files<br />
than was required with previous DS solutions. It has been identified that proposed messaging<br />
transport mechanisms may not be capable of transferring these large files unchanged.<br />
Additional features which have been added to the protocol to alleviate this problem include:<br />
a. File compression (where allowed by network and security infrastructure). Use<br />
of file compression provides not only the possibility of transporting data files which<br />
exceed the allowed limit, but is also a more efficient use of the network by reducing<br />
network bandwidth requirements (it appears indicate a compression ratio of 10:1 is<br />
achievable). Initially, use of ZIP compression is assumed, but this specification does<br />
not preclude the use of other methods and products as they become available.<br />
b. File Segmentation. The maximum file size limitation requires that a data file<br />
which is larger than a configurable limit is segmented into multiple data files, each<br />
smaller than the limit. These will be sent in separate messages, each with a separate<br />
file name, allowing the original file to be recreated in the correct order by the<br />
receiving nation.<br />
2-2<br />
UNCLASSIFIED<br />
Original