XDS Main Page
From IHEWiki
IHE XDS
The is the home page for XDS profile Testing. If you are new, I suggest examining the XDS Testing Introduction page and the IHE Links section below first. This page is intended to be a collection of reference material for testing and not tutorial in nature. XDS Testing Introduction is the best current introduction or tutorial on the subject.
IHE Links
IT Infrastructure Committee (home of XDS)
Download IT Infrastructure Profiles and Whitepapers
Implementation Notes
XDS Notes from 2008 NA Connectathon
Updates for the 2008-2009 Testing Season
Plans for the season
- Updates to track CPs approved this season
- New MTOM/XOP tests to reflect corrections to XDS.b/XCA profile
- Upgrade to xdstest tool
- XCA tests
- Tests for Async - because of the nature of corporate Internet filewalls, this will require downloading and installing a local copy of the Public Registry
- Tests and Public Registry upgrades to follow Metadata White Paper
- Make Repository implementation handle UTF-8 correctly and add tests for same
- Tests for PubSub White Paper (time permitting)
- Things I have forgotten to put on this list
Changes to tests and tools
- Significant upgrade to the xdstest tool (yes, I renamed it back to xdstest, xdtest2 is just too hard to say in a sentence)
- New command line front end
- Manages patient ID allocation automatically
- Manages WS Endpoints from a common configuration table
- No longer any need to edit testplan.xml files
- log.xml files placed into separate directory tree
- Configuration controlled by a small collection of environment variables
Release dates for new tools and updates
I planning for a major release around October 15. I will release pieces earlier if I can.
Where to ask questions
We have a mailing list dedicated to XDS (and related profile) testing. It is ihe-xds-implementors@googlegroups.com. Discussion of ITI Profiles belongs on the ITI committee mailing list ititech@googlegroups.com. If you need to contact me directly, I have a new email address for IHE work bmajur AT gmail dot com.
Updates for the 2007-2008 Testing Season
- This wiki material has been moved to a new host. The new main support page for XDS Profile testing is http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page. If broken links are found please let me know. Also, if a wiki page that you depend on is not present, let me know. I have moved all of what I think folks are using but I might have missed a page. The old wiki on hcxw2k1.nist.gov is no longer being updated and will be turned off December 1.
- The Registry Adaptor, metadata validator, and the new test tool xdstest2 are new implementations based on the Apache Axis2 project.
- Error reporting software has been rewritten. This means no more cryptic JSP errors!
- Last year's implementation is still available for testing but is not being maintained.
- New server hardware is now installed. The old server is still running to support the RSNA demonstration at the end of November. Around December 1, it will be turned off. During this period of having two servers running, the old server will retain the hcxw2k1.nist.gov name and the new server will be addressed by its IP address 129.6.24.109. After the old server is turned off, the hcxw2k1 name (DNS) will be moved to the new server.
- The xdstest tool has been replaced by a new tool xdstest2. The old tool will not be used this season.
- XDS.a and XDS.b are both supported by this server. Documents and metadata submitted via one interface can be queried/retrieved via the other. There is one database behind the two interfaces.
- A syslog service will be available on the server. To support this service, a syslog browser will be available to inspect the syslog records you generate. There are new XDS tests that require you to submit syslog entries to this server.
- A new test log browser will be used this season. Unlike last season where the SOAP Header returned from a transaction included a link to a test log entry, this tool allows browsing of all test log entries submitted from your current IP adddress. See the tools section below for details.
- Test result reporting has changed. Tests run using the new test tool xdstest2 generate a log file named log.xml that is to be logged to Kudu. Tests run against the Public Registry now require logging in Kudu of the XDSSubmissionSet.uniqueId attribute. There is no longer any restrictions placed on the use of Patient IDs. For both style tests, old style of logging will not be accepted this season.
Testing
Rules for submitting results to Kudu
Do not submit zip files. Instead, submit multiple .txt or .xml files. If a test has two parts, submit and eval the submit to Kudu a submit.xml and eval.xml log files instead of a zip file containing both.
2007-2008 Test Documentation
- a table of all the XDS tests indexed by the XDS transaction they support. Includes links to the documentation for each test
Test Descriptions/Instructions
- detailed description of all the tests with instructions for executing. At the top of the page is documented the rules of testing (what to submit as evidence, how to allocate Patient IDs etc). You can look directly here if you know a test number.
2006-2007 Test Documentation
Testing XD* (2006-2007 season)
XD* Detailed test requirements (2006-2007 season)
General
- Notes on metadata and Soap with Attachments as used in the XDS.a profile.
- (Frequently Asked Questions regarding the XDS profile)
- table documenting all the UUIDs created by the XDS Profile.
Discussion of XDS Transactions
- this page offers discussion on selected topics on XDS Transactions.
- this page offers discussion on common metadata patterns
- All XML Schema files used to validate Registry/Repository related transactions.
Testing Tools
- xdstest2 is a new test tool for testing Registry and Repository implementations. It replaces the old xdstest tool. Output from the old xdstest tool will not be accepted this season. If you are testing Document Source or Document Consumer actors you do not need this.
- a web page with a collection of tools. It includes the Patient ID allocator for the Public Registry.
Test Log Browser (documentation)
- a web based tool for browsing the test logs maintained on the Public Server. It detects the IP address from your browser connection and only shows log entries for transactions sent from that IP address.
- a web based tool for browsing audit log entries sent to the audit repository on the Public Server. It detects the IP address from your browser connection and only shows log entries for transactions sent from that IP address.
- each new version of the test kit is published here. Always download the most recent version. This contains material for testing Document Repository and Document Registry actors. If you are testing Document Source or Document Consumer actors you do not need this.
- text file documenting changes and updates to the test kit.
Public Registry
The Public Registry is a server maintained on the Internet which implements the following actors:
- Document Registry (XDS.a and XDS.b)
- Document Repository (XDS.a and XDS.b)
- Receiving Gateway (XCA)
- Audit Record Repository
The new Public Registry implementation resides at hcxw2k1.nist.gov (also known as ihexds.nist.gov and 129.6.24.109).
Configuration and Change Log
- that defines the Public Registry Affinity Domain configuration. This includes definitions of acceptable codes, mime types etc. The Metadata Validator function of the Public Registry validates all ProvideAndRegisterDocumentSet and RegisterDocumentSet transactions (XDS.a and XDS.b) against this configuration. Specifically, it passes the submitted metadata through Schema validation and then metadata validation. Metadata validation has two parts: validate that the metadata is structured according to the rules of XDS (which are more strict than ebXML Registry standard) and that the codes used in the metadata are consistent with the configuration of the Affinity Domain. Updates to this table are made on request to support community activities.
- Text file documenting changes and updates to the Public Registry server.
Important URLs / WS Endpoints
| Transaction | non-TLS | TLS |
| XDS.a | ||
| Provide and Register | http://129.6.24.109:9080/axis2/services/xdsrepositorya | https://129.6.24.109:9443/axis2/services/xdsrepositorya |
| Register | http://129.6.24.109:9080/axis2/services/xdsregistrya | https://129.6.24.109:9443/axis2/services/xdsregistrya |
| SQL Query | http://129.6.24.109:9080/axis2/services/xdsregistrya | https://129.6.24.109:9443/axis2/services/xdsregistrya |
| Non-TLS SQL Query will return a non-TLS URI. TLS SQL Query will return a TLS URI. | ||
| XDS.b | ||
| Provide and Register - b | http://129.6.24.109:9080/axis2/services/xdsrepositoryb | https://129.6.24.109:9443/axis2/services/xdsrepositoryb |
| Register - b | http://129.6.24.109:9080/axis2/services/xdsregistryb | https://129.6.24.109:9443/axis2/services/xdsregistryb |
| Retrieve Document Set (returns MTOM) | http://129.6.24.109:9080/axis2/services/xdsrepositoryb | https://129.6.24.109:9443/axis2/services/xdsrepositoryb |
| Retrieve Document Set (returns MTOM/XOP) | http://129.6.24.109:9080/axis2xop/services/xdsrepositoryb | https://129.6.24.109:9443/axis2xop/services/xdsrepositoryb |
| Both XDS.a and XDS.b | ||
| Stored Query | http://129.6.24.109:9080/axis2/services/xdsregistryb | https://129.6.24.109:9443/axis2/services/xdsregistryb |
| Non-TLS Stored Query will return a non-TLS URI. TLS Stored Query will return a TLS URI. | ||
| XCA Receiving Gateway | ||
| Cross Gateway Query | http://129.6.24.109:9080/axis2/services/rg | https://129.6.24.109:9443/axis2/services/rg |
| Cross Gateway Retrieve (return is MTOM/XOP coded) | http://129.6.24.109:9080/axis2xop/services/rg | https://129.6.24.109:9443/axis2xop/services/rg |
| Cross Gateway Retrieve (return is MTOM coded) | http://129.6.24.109:9080/axis2/services/rg | https://129.6.24.109:9443/axis2/services/rg |
Many tests use specialty URLs representing special testing services. These are documented in the individual tests.
repositoryUniqueId is 1.19.6.24.109.42.1
homeCommunityId is urn:oid:1.19.6.24.109.42.1.3
North American TLS
The configuration created to support the North American Connectathon January 2008 has been removed to allow for Europe 2008 testing. The two configurations are not compatible.
This season certificates are being handled differently, as an experiment. The certs that Steve has issued are valid for a full year and contain the hostname that you will be using at Connectathon. They are being used Pre-Connectathon and at the Connectathon. Hopefully this will avoid the last minute rush to install new certs. But, it is coming with some headaches. First, do not depend on the hostnames embedded in the certs for pre-Connectathon testing. Second, some folks have found it necessary to put the hostnames/IP addresses into their local host table for them to work. If you have other issues/solutions please let me know and I will post them here.
TLS (port 9443) accepts the following Cyphers:
- TLS_RSA_WITH_AES_128_CBC_SHA
- SSL_RSA_WITH_3DES_EDE_CBC_SHA
The public certificate for the Public Registry is located at NIST/XDSb_REG_NIST/nist1.ihe.net.cert.pem in the distribution from Steve.
If you cannot connect to the Public Registry over TLS here are some common reasons:
- http requests non-secure transaction and https requests a secured transaction. The port number is just part of the address to were software exists that might accept your secured/non-secured request.
- The Public Registry is known in the certification collection as nist1.ihe.net. You may have to add this name to your host file with the IP address 129.6.24.109 before your secure software will accept it as valid.
- Specify the endpoint as https://nist1.ihe.net:9443/
If you have to do more than this please let me know so I can update the list.
European TLS
There are updates to both the Public Registry server and the xdstest2 tool.
For xdstest2 tool users, there is now available version 1.15 that is pre-configured with the cert/key for nist2.ihe.net. This will allow testing with your servers. Internal to the scripts delivered with xdstest2, there are changes. In place of the old keystore file which acted as both keystore and truststore, there are now separate keystore.jks and truststore.jks files. The supplied scripts have been updated. The keystore and truststore are shown below.
The keystore looks like:
~/dev/xdstest2tool bill$ keytool -list -v -keystore keystore.jks -storepass changeit
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: xds_server
Creation date: Mar 19, 2008
Entry type: keyEntry
Certificate chain length: 3
Certificate[1]:
Owner: CN=nist2.ihe.net, OU=318003000900013, L=Paris (75), O=TEST, C=FR
Issuer: OU=AC-CLASSE-4, O=GIP-CPS, C=FR
Serial number: 30303031323035323230373332303030
Valid from: Tue Mar 11 04:32:12 EDT 2008 until: Tue Dec 30 19:00:00 EST 2008
Certificate fingerprints:
MD5: D5:21:D7:2F:0C:80:CD:83:1B:50:BD:5B:50:63:F5:7A
SHA1: 2D:85:43:41:03:D8:86:CF:3E:FF:F8:C4:06:F1:7F:C3:52:04:39:09
Certificate[2]:
Owner: OU=AC-CLASSE-4, O=GIP-CPS, C=FR
Issuer: O=GIP-CPS, C=FR
Serial number: 3030303130303538393739393230303000
Valid from: Mon Nov 12 19:00:00 EST 2001 until: Tue Dec 30 19:00:00 EST 2008
Certificate fingerprints:
MD5: 96:F6:D0:D6:1F:9D:BE:10:49:87:60:9D:E9:95:41:6D
SHA1: 04:EA:FC:58:D5:09:A9:4C:52:10:B2:A0:D1:20:97:D4:DB:BE:33:65
Certificate[3]:
Owner: O=GIP-CPS, C=FR
Issuer: O=GIP-CPS, C=FR
Serial number: 30303031303030343438373333303030
Valid from: Mon Jun 25 20:00:00 EDT 2001 until: Thu Dec 30 19:00:00 EST 2010
Certificate fingerprints:
MD5: 91:B9:A4:5E:EC:FD:95:01:31:34:DB:DE:15:80:82:18
SHA1: F7:35:53:22:EA:4B:80:C7:FF:E2:B4:CB:D4:92:B0:45:45:B9:18:D4
*******************************************
*******************************************
Note that the truststore contains the trustCertEntry for all certificates leading up to the root CA certificate.
For users of the Public Registry, no large changes are necessary. The certs installed there have the same structure as the ones shown in detail above. The cert/key pair prepared for the Public Registry is named incorrectly. Instead of having the name hcxw2k1.nist.gov it has the name hcxw2k1.nist.org. Because of this, you may need to add the following line to your hosts file (/etc/hosts on Unix-like systems):
129.6.24.109 hcxw2k1.nist.org
Syslog Facility
The Public Registry server has a syslog facility to be used with joint XDS/ATNA testing.
- It accepts messages at 129.6.24.109 port 8087
- A browser is available to view your messages here. This browser will only display audit messages sent from the IP address that generated the audit messages.
Syslog testing requirements for XDS at the 2008 Connectathon are documented here.
Test Data
Test data available in the Public Registry is documented here.
Status of Public Registry Services
Operational
These services are available:
XDS.a Profile
- Accepts Provide and Register -a transaction
- Accepts Register -a transaction
- Accepts Query transaction (SQL)
- Accepts Retrieve Document transaction
XDS.b Profile
- Accepts Provide and Register -b transaction
- Accepts Register -b transaction
- Accepts Retrieve Document Set transaction
Not XDS.a / XDS.b specific
- Accepts Stored Query transaction. The following Stored Queries are not yet implemented:
- FindFolders
- GetAll
Not Operational yet
These services are not yet available:
- The rest of the Stored Query catalog
- Many many tests. New tests will be released weekly.
Known bugs in the Public Registry Implementation
The following bugs exist in the Public Registry implementation. When fixed they will be reflected in the change log.
ws:Action element in SOAP Fault in XDS.a
When this implementation of XDS.a detects a low level error (HTTP/SOAP etc) it generates a SOAP fault in return. The SOAP fault message includes a ws:Action element. Since XDS.a does not use WS-Addressing this seems wrong. I have not yet examined the standard to know if this is a feature or a bug.
Overly sensitive to Content-Type header
Axis2, which I use as the WS implementation, is extremely sensitive to the formatting of the Content-Type header. The following header:
Content-Type: Multipart/Related ;type="text/xml"; boundary=7d4285f14803b8
causes errors for two reasons:
- There is a space after 'Related' and before the semicolon
- Multipart/Related needs to be multipart/related
Both of these are in violation of the relevant standards. I will find a way to correct this input before feeding axis2 so testers do not need to see this bug.
Content-ID mismatch
A mismatch in Content-IDs for attachments (XDS.b using MTOM/XOP) returns an error
<soapenv:Fault>
<soapenv:Code>
<soapenv:Value>soapenv:Receiver</soapenv:Value>
</soapenv:Code>
<soapenv:Reason>
<soapenv:Text xml:lang="en-US">java.lang.NullPointerException</soapenv:Text>
</soapenv:Reason>
<soapenv:Detail />
</soapenv:Fault>
which is totally unreasonable. The real error is shown by looking at a piece of XDS.b metadata:
<xdsb:Document id="Document01">
<xop:Include
href="cid:1.urn:uuid:B8FFE3B858E1AE7B4E1196170432225@apache.org"
xmlns:xop="http://www.w3.org/2004/08/xop/include" />
</xdsb:Document>
and the corresponding Part header:
Content-ID: <1.urn:uuid:B8FFE3B858E1AE7B4E1196170432225@apache.org>
which is correct. The error occurs when the content id is formatted as
Content-ID: <cid:1.urn:uuid:B8FFE3B858E1AE7B4E1196170432225@apache.org>
with the leading cid: which violates RFC 2387 which covers multipart/related.
Known Defects and Changes to the XDS Profile (2007-2008 season)
The following defects in the published text have been found. They will be fixed through the formal Change Proposal process. They affect:
- Revision 4.0 of Volume 2 of the ITI Technical Framework (IHE_ITI_TF_4.0_Vol2_FT_2007-08-22.pdf) and
- XDS.b Supplement (IHE_ITI_TF_Supplement_XDS-2.pdf)
- A CP will be submitted to clarify the responsibilities of the Document Repository regarding the handling of the repositoryUniqueId attribute. It is proposed that it be handled like the size, hash, URI attributes. If it is present in the Provide and Register transaction then the Document Repository shall overwrite the attribute.
- A clarification of the semantics behind the GetSubmissionSetAndContents Stored Query has been submitted as a Change Proposal. This clarification points out that the Association objects that link Folders and Documents ARE to be returned by the query. The proposed change to the text can be found here
- Section 4.1.11 - Registry Adaptor - Support Document Replacement section: Document to be replaced must have status = Approved
- XDSDocumentEntry.sourcePatientInfo attribute: Source/Query column shows R8/P (should be R/P) with a footnote saying that certain segments are required, see text for details. Text says single value required but example shows multiple values. Example is correct.
- XDSDocumentEntry.patientId attribute: name should be XDSDocumentEntry.patientId
- XDSSubmissionSet.patientId attribute: uuid should be urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446
- XDSFolder.patientId attribute: uuid should be urn:uuid:f64ffdf0-4b97-4e06-b79f-a52b38ec2f8a
- XDSFolder.codeList attribute: shows single quotes around attribute values - XML specifies they are to be double quotes.
- Change Proposal 241 describes a new configuration of options for the Document Source actor in XDS.a. Its contents were supposed to be reflected in the XDS.b supplement. The new Document Source option configuration applies to both XDS.a and XDS.b. The major change is that now Document Replace operation is optional instead of mandatory for Document Source Actors.
- Section 4.1.13 Error Reporting introduces the new RegistryResponse status code of PartialSuccess without discussing which profiles it may be used in. It is used in the Cross-Community Access (XCA) profile and not in the XDS profile.
- The use of base64 encoding in XDS.a has been poorly understood for a long time. After a review of relevant standards we have found that the relevant standards clearly specify what is acceptable.
- Base 64 encoding IS appropriate (may be generated by the Document Source, must be accepted by the Document Repository) for the Provide and Register transaction
- Base 64 encoding IS NOT allowed in the Retrieve Document (HTTP GET) transaction.
The Provide and Register Document Set and Retrieve Document transactions will be updated with this clarification.
- Change Proposal 267 (word) (new) describes a change to the use of MTOM and MTOM/XOP to align better with common industry practices. Tutorial information and the new specific requirements are documented here. This wiki document has more detail than the formal Change Proposal document for now.
- Change Proposal 28 (word) (integrated into TF) describes how XDS (.a and .b) now uses formal error codes in response messages.
- Change Proposal 117 (word) (integrated into TF) describes how Replace, Append, and Transform (relationships between documents) interact.
- Change Proposal 130 (word) (integrated into TF) allows XDSDocumentEntry.legalAuthenticator and XDSDocumentEntryConfidentialityCode to be multi-valued.
- Change Proposal 145 (word) (integrated into TF) clarifies the Date/Time formatting to be used.
- Change Proposal 164 (word) (integrated into TF) documents how to code Syslog events (ATNA Profile) for XDS.
- Change Proposal 187 (word) (integrated into TF) documents how to insert extra (not specified by XDS) metadata into the Registry.
- Change Proposal 208 (word) (integrated into TF) adds specific labels to metadata elements controlling whether they can/must be single/multi valued.
- Change Proposal 225 (word) (integrated into TF) more clearly states the enforcement rules for unique IDs.
- Change Proposal 226 (word) (integrated into TF) clarifies how OIDs used in unique IDs must be formatted.
- Change Proposal 246 (word) (integrated into TF) documents the move of the metadata tables into their own section.
- Change Proposal 266 (word) (new) documents new error codes beyond what is currently described in the Technical Framework. This list will be added to during the testing season as new needs are identified. These error codes are required at the January 2008 Connectathon.
- Change Proposal 268 (word) (new) clarifies the use of XML namespaces on Association Types in XDS.b. They are required on ALL Association Types.
- Change Proposal 269 (word) (new) clarifies the use of the status value PartialSuccess. It is only to be used in the context of the XCA profile.
- Change Proposal 237 (word) (Approved) defines how Associations may be added to the Registry. One use is for adding an existing Document to an existing Folder.
- (This is either a defect in the Public Registry implementation or a new interpretation of the underlying standard. I am not sure which...yet.)
Some implementers have had problems with the HTTP header SOAPAction. The Public Registry, based on Axis2 libraries, is requiring that the SOAPAction header match the top level request element in order to be valid. This applies only to XDS.a since XDS.b uses WS-Addressing which leads to SOAPAction holding the same value as th Action element of the SOAP Header.
An XDS.a example is
... SOAPAction: "SubmitObjectsRequest" ... ... <soapenv:Body> <rs:SubmitObjectsRequest xmlns:rs="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1"> ...
Looking to the relevant standards for guidance produces...
SOAP 1.1 (section 6.1.1) specifies
- The SOAPAction HTTP request header field can be used to indicate the intent of the SOAP HTTP request. The value is a URI identifying the intent. SOAP places no restrictions on the format or specificity of the URI or that it is resolvable. An HTTP client MUST use this header field when issuing a SOAP HTTP Request.
This would seem to justify the Axis2 interpretation that the SOAPAction match the top level request element. The value "urn:SubmitObjectsRequest" is also valid.
I cannot find other supporting references. If we get through the testing season with this assumption then XDS will updated to reflect this more modern interpretation of SOAPAction. What makes this troubling is that older libraries and tool kits (such as the one use in the old Public Registry implementation) did not implement this restriction.
Open Change Proposals against XDS (2008-2009 season)
Actual text of these proposals can be found at here.
| CP # | Description |
|---|---|
| Changes affecting Interoperability | |
| 147 | Patient ID string encoding of non-ASCII characters |
| 201 | Instructions needed for computing size and hash for multiparts in XDM |
| 228 | eventCode parameter to FindDocument Stored Query needs AND semantics instead of OR semantics |
| 262 | Add new Error Codes |
| 266 | Duplicate of 262 |
| 267 | XDS.b should specify XOP coding instead of MTOM for document attachments |
| 268 | Association Types must have XML namespaces in XDS.b |
| 269 | Add discussion on when PartialSuccess status may be used, see also 287 |
| 271 | Clarification on when base64 encoding is acceptable |
| 278 | Submission of Association Objects |
| 279 | Clarification of Document Retrieve Import/Export Audit Message |
| 280 | Duplicate of 279 |
| 281 | Update of XDS Audit requirements to be more specific |
| 286 | Repository must overwrite repositoryUniqueId if submitted in metadata |
| 287 | Another set of requirements for the use of PartialSuccess status, see also 269 |
| 288 | Fixes to XDS.b WSDL |
| 295 | Stored Query parameters with length greater than 256 characters |
| 301 | Duplicate of 268 |
| 303 | Specify handling of XDSFolder.lastUpdateTime when received in Register transaction |
| Wording Improvements | |
| 255 | Rename two sections on XDS security |
| 259 | Improve documentation on parentDocumentRelationship/parentDocumentId attribute |
| 260 | Improve wording on intendedRecipient attribute |
| 261 | XDS Errata - correct typos on UUIDs etc. |
| 265 | Clarify required/optional version of SOAP on Stored Query |
| 283 | Clarify use of SHA1 as hash algorithm |
| 284 | Incorrect section reference for off-line transaction option in XDS.a |
| 292 | Correct example - Patient ID not properly quoted |
| 293 | URI Attribute Formatting - warn developers that ^ is a special char in a URI and must be escaped |
| 294 | XDSFolder.patientID UUID wrong |
| 296 | Clarification on the use of Submission Set |
| 297 | Clarification of GetSubmissionSetAndContents Stored Query |
| 289 | Clarification of GetRelated Stored Query |
| 299 | Duplicate of 289 |
| 300 | Clarify when and why ObjectRefs should be generated in metadata |
| 302 | Improve description of XCN datatype |
Open Source
XDS Server, Registry and Repository, can be downloaded in either binary or source versions. Installation instructions and the download elements can be found at http://ihexds.nist.gov:9080/XdsDocs/opensource/. Start by reading the file readme.txt.
