Modular+Specs+Direct+Exchange+Feedback

include component="page" wikiName="siframework" page="ModularSpecTabs" This page is where ONC and Project Team members will respond to comments on the final artifacts posted from Modular Specification Pilot Phase 2.

We clarified how we use identifiers for test cases and checklist rows in the Direct Test Guide, version v1.0c. || Complete || How can the MIME test implementation process an XDM message? If anything shouldn’t an error be sent from the test tool to the implementation. the test steps did not indicate that a conversion should have been applied This goes for any other test step where there are conflicting implementation types (aside from the processing of the standard SMIME message which all types have to process) In relation to the above bullet, Rows 31 and 32 have the same test steps, the only difference is the testing tool type 31 MIME and XDM -> MIME or XDM 32 MIME and XDM -> XDR In both instances there is no conversion performed by the implementation as both test steps state a MIME + 5322 Message is being sent, it appears the only thing being tested is the processing ability of the test tool. || A MIME test implementation can process an XDM because there is no conversion necessary on the MIME test implementation's side. For Row 32, we have added a conversion actor to our test cases. So what was row 32 in Test Package v.0.7 is now modified in Version 1.0 of the Test Package. See DTS 5 in this package to see how we've added a step for the System to convert the MIME message into XDR. || Complete || Please further qualify "Receiver returns failure MDN in case of invalid incoming message" The receiver should not be sending failure MDN message for untrusted incoming messages. A negative MDN message should only be sent if the message first passes security and trust validation. || As part of our feedback to the Direct community we have requested that this requirement be clarified that the MDN should NOT be sent. That being said, we have modified our test cases to replace the step where the System returns an MDN with a step stating where the System recognizes that an error has occurred. || Complete || If the intention of including the Disposition-Notification-To header is to test the "MDN processed disposition" message, then this header is not necessary. The SAT implementation automatically sends the MDN message regardless if this header is present or not. If it is not present, the "From:" header is used as the target address of the MDN message. || Our tests intend to test that a System can successfully respond to a message that includes a "disposition-notification-to" header (see DTS 87). We also include a test that does not include this header (see DTS 88). Per RTM requirement 52, the MAIL FROM SMTP command is the first field where the System should look for the MDN response. || Complete || The test case states the rfc822Name extension is required. According to section 4.1.1 of the Applicability Statement for Secure Health Transport, the extension is not required if the email address supplied in the certificate's subject distinguished name. || We agree that it isn't required for Systems to choose one way or the other for their own certificates, but it is required for Systems to be able to send direct messages to an implementation that binds to the rfc822 Name as well as to implementations that bind the email address using the Subject Distinguished name. Test Case CERT 1013 tests that the System under test can also send a message to an implementation that binds using the subject distinguished name. || Complete || Definition of "unsecure email address" is not clear. || We have removed this test from Direct_Transport_and_Security_Test_Package_v1.2 || Complete || DTS 78, DTS 79, DTS 80, This system will not be able to successfully process the message in the STA in these use cases. MDN failure messages are not sent if the STA cannot process the message. || After discussion with Greg Meyer of CERN and Dragon, they both stated that while these requirements are not currently written, there have been "conversations" with regard to Direct specifications that mandate that MDNs should not be sent when a Direct STA receives an unencrypted message because this could lead to phishing. Because of this, we have removed the step where the System returns and MDN with a step where the system recognizes that an error has occurred and refrains from sending an MDN. || Complete || We believe you indicated that the intent was to provide this functionality, and that unit testing would focus on source client/destination client man/machine interface constructs. || All of the Test Team's Tests and checklist items include references to particular RTM requirements, which reference the underlying specifications. If the RTM does not fully constrain, our tests and checklist items include references to the underlying specifications where those requirements are stipulated. || Complete ||
 * ID || From || Issue || Response || Status ||
 * 1 || SME || The notes in the "Test Data" tabs have a significant number of open questions (content related). It seems that these questions needs to be clarified for the sake of completeness. || Agree. We have removed all of the open questions from Direct_Transport_and_Security_Test_Package_v1.2. || Complete ||
 * 2 || SME || Test cases DTS-86, DTS-87, DTS-88 are all sub test of DTS-29, ideally the structure of the document should reflect this (the same goes for DTS-89, DTS-90, DTS-91 as sub tests of DTS-8). || Test Cases, 86, 87, and 88, are now sub tests of DTS 29. Upon closer look, DTS 89 and 90 were error cases so we moved them to the Error Section of the package. DTS 91 has a different second step from DTS-8 so we had to leave it as is. Further, we have added a subsection to section 6 in our Test Guide that explains how sub flow test cases work. || Complete ||
 * 3 || SME || In the "Test Cases" tab I'd question columns "Source" and "Destination". Both of them seems to be redundant after separation of XD test cases. || At the time we separated we were maintaining parallel combined and separated versions, and these columns were significant for the combined version. At this time it appears we will be maintaining only the separated versions. We have removed the columns from the Transport and Security Test Package. || Complete ||
 * 4 || SME || A lot of test cases (#5,31,93,206-211, etc...) refer to SOAP Checklist tab, however this tab has information for only test cases #400 - 432 || DTS 400-432 are not referencing or tracing to test cases, they are identifiers for checklist rows. They are present so that we can trace from the RTM into individual test items.
 * 5 || SME || In the Test Cases tab there is a "Test Data" column that seems to be redundant as it has a column "Test Data ID" which refers to the "Test Data" tab. However in few rows this column ("Test Data") refers to "Message A/B/C/D.." which are in the separate tabs ("XDR Test Messages" for messages A and B, "Converted Messages" for all other messages). In sort the column "Test Data" is mostly copy/paste from the tab "Test Data" - which is not a good practice and partially refers to two other tabs - which is confusing... || Agree. We removed the Test Data Column from the Test Cases tab. We put the test data requirements into the test steps so as to remove a layer of indirection. However, we kept the Test Data index tab to include examples of the Test Data requirements. || Complete ||
 * 6 || SME || Test Cases tab has a number of references to "XDR Test Message Tab" without clarification to what row it refers. It literally just says "See XDR Test Message Tab" || Agree. Because we removed the Test Data Column this reference is fixed. || Complete ||
 * 7 || Spec Team || Several test cases include the constraint “Conditional for systems that can receive RFC 5322 +MIME Messages.” However, this is the base transport mechanism and should be supported by everyone. This was fixed in version 1.0 of the Test Package. || These were modified to be required in version 0.9 of the Test Package. || Complete ||
 * 8 || Spec Team || There are about 30 test cases with no ID. || These were added in version 0.9 of the Test Package. || Complete ||
 * 9 || Spec Team || Rows 95-96-104-105 - DSA with SHA-256 and RSASSA-PSS with SHA-256 are not required as tagged in the test document, they are both optional. || These were added in version 0.9 of the Test Package. || Complete ||
 * 10 || Spec Team || Error processing is governed by local policy and may not conform to the expected actions in the test steps (i.e. content contained in the MDN sent by the implementation) || We have modified our test cases to replace the step where the System returns an MDN with a step stating where the System recognizes that an error has occurred. || Complete ||
 * 11 || Spec Team || Row 65 (and several others): System Implementation Type = XDM -sending to-> Testing Tool Implementation Type = MIME or XDM
 * 12 || ModularSpecs Wikipages feedback || - Negative Testing
 * 13 || ModularSpecs Wikipages feedback || Test Data Index 201
 * 14 || ModularSpecs Wikipages feedback || Test Case CERT 1012
 * 15 || ModularSpecs Wikipages feedback || Test Case CERT 1015
 * 16 || ModularSpecs Wikipages feedback || Test Cases DTS 89, DTS 90, DTS 91, DTS 76, DTS 77, DTS 81, DTS 82, DTS 83, DTS 84, DTS 85,
 * 17 || ModularSpecs Wikipages feedback || We Wish We Knew if the test driver would be designed to test all software paths and force saturation? || The Test Team's Test Package tests conformance to the specifications. These do not include performance requirements, and therefore we do not test saturation of a system's resources. || Complete ||
 * 18 || ModularSpecs Wikipages feedback || On error, during test, will the test driver return an index to the spec and to the description in the documentation where information regarding test condition could be found?
 * 19 || Test Team || Direct XD package: Some of the conversion tests have XDR endpoints returning an MDN. || Fixed. || Complete ||
 * 20 || Test Team || Direct XD package: Based on answers from SMEs, in conversion cases the two hops (on either side of the converter) are asynchronous, i.e. the first hop should return without waiting for the second hop. Reflect this in the test case steps. || Fixed. || Complete ||
 * 21 || Test Team || Direct XD package: DTS 207, 208, 211, 292, 293, 296 all cover referencing existing objects (e.g. documents, submission sets) previously submitted to the destination. Because this is such an edge case, make the assumptions a lot clearer, and adjust the optionality. || Done. || Complete ||
 * 22 || Test Team || Rename SOAP Header Checklist to Direct XDR Request Checklist, because it needs to check more than just the SOAP header. || Done. || Complete ||
 * 24 || SME || There are references to "XDR testing tool". The test guide defines it as "implementation capable of receiving XDR messages". I think that this is very vague definition. The spec is talking about "minimal XDR" set. I think we need a better definition/requirement. Direct XDR requirement is quite different from (for example) XDR subset used in CONNECT, etc... || Clarified terms, definitions and examples in the Test Guide to specify that the XDR Testing Tool is capable of receiving converted (i.e. full or minimal metadata) XDR messages. || Complete ||
 * 26 || SME || Transport & Security test cases - DTS-192 test case calls for "large attachment". Could we be more specific and define it? || After discussion within the team, we decided to pull these tests out of the Test Package because there are no requirements for sending large attachments. || Complete ||
 * 27 || SME || In "RFC 5322" tabs the indexing schema is based on "DTS" prefix and numbers from 100 to 181. This is same indexing as in "Test Cases" tab. This is confusing. I'd suggest a different indexing approach when there is no reference to the other tab. || Agree. We updated the ID numbering of some test cases so that the functional areas such as RFC5322 Checklist and the XD Test Cases have numbers that are all from the same range (e.g. 1-99 for Direct Transport and Security Test Cases, 200-299 for XD Conversion Test Cases, etc.). We updated the Test Guide to indicate the ID Prefix and ranges and their respective areas of the test package. || Complete ||
 * 28 || SME || Transport & Security test cases -"XDR message checklist" tab - the cell in line 6/column I has a problem ( probably misspelling) that messed up the cell formatting. || Fixed in Version 1.0c of the Test Packages. || Complete ||
 * 29 || SME || XDR test cases - "test data index" tab has the same problem ( see #4) in column C, lines 23 and 23 (two cells over all). || Fixed in Version 1.0c of the Test Packages. || Complete ||
 * 30 || Test Team || Reflect new test case optionality in the Questionnaire. || Fixed in Version 1.0c of the Test Packages. || Complete ||
 * 31 || Mod Spec Development Team || When converting to XDR from S/MIME or S/MIME with XDM, are all features of XDR supported? || All the features of XDR would not be supported via the conversion from S/MIME to XDR. The critical part of the specification is to follow the conversion rules and then not make any assumptions of the receiver or the state of the registry at the receivers end. As for the resolution, no changes were made to the specifications. || Complete ||
 * 33 || Mod Spec Development Team || How could XDS Folders that exist in an XDM package be inferred from an S/MIME message? || The content should not be inferred. It should just follow the conversion rules for S/MIME to XDM/XDR.As for the resolution, no changes were made to the specifications. || Complete ||
 * 34 || Mod Spec Development Team || There are features in XDR which take advantage of the state of an XDS registry: associating existing documents with a new submission set or folder, replacing an existing document, etc. With this, S/MIME has no way to express an existing XDS object and S/MIME + XDM use cases don't seem to lend themselves to prior knowledge of the state of the Document Receiver. I suppose it could be possible for someone to create an XDM file that replaces an existing document by obtaining the document’s UUID out-of-band. With this being said, should this be allowed? || Prior knowledge of the document receiver is not required for DIRECT interaction and the state is not assumed to be known. Hence, replacing a document is not within the scope of the DIRECT specs unless the receiver is smart enough and is determining the stuff out of band like you say, in which case the interaction falls outside of the DIRECT spec. The DIRECT spec only deals with the conversion from S/MIME to XDR/XDM as appropriate and does not go beyond that. || Complete ||
 * 35 || Mod Spec Development Team || For the XDR/XDM conversion, the table shows all combinations between S/MIME, XDM, and XDR. Is XDR-XDR in scope? This would include all features of XDR (i.e. XDSFolders, referencing existing objects). || XDR-XDR is not in scope, because that is performed by the existing Exchange Specifications and also the IHE CONNECTATHON validates that stuff. DIRECT Specifications does not deal with that aspect except in cases where you can use XDR without conversions when both sender / receiver are XDR capable. As for the resolution, no change was made; not able to address the scope of Direct specifications. || Complete ||
 * 36 || Mod Spec Development Team || For the mod spec issue, XDR, how do S/MIME/XDR converters fit into the system under test? Another way to put it is: a converter is a standalone system under test, as shown in deployment models E.1 and E.2. Testing tools (i.e. control systems) would be used for both the S/MIME endpoint and the SOAP/XDR endpoint. A converter would be considered an internal part of the system under test on the sending side. For example, a particular S/MIME sender would have the optional feature of also being able to send SOAP/XDR messages. In this case, use an S/MIME Testing Tool to test its native messages, and a SOAP/XDR Testing Tool to test its converted messages Please note that this is what the RTM seems to imply: it assigns all conversion requirements to the initiator. A converter would be considered an internal part of the system under test on the receiving side. For example, a particular S/MIME receiver would have the optional feature of also being able to receive SOAP/XDR messages. In this case, use an S/MIME Testing Tool to send it native messages, and a SOAP/XDR Testing Tool to send it messages to convert. Inspect the SOAP/XDR messages after conversion. || In case of E1, the sending system should be a testing tool that sends S/MIME a message. The receiving system is a DIRECT HISP capable of receiving S/MIME and converting to XDM/XDR. The converted content is delivered to an XDR endpoint. The End point itself can be a testing tool to verify that it can process the converted message. So the system under test is DIRECT HISP that is the receiver of S/MIME messages and converts it to XDM/XDR. In the case of E2, the reverse, known as the end point (can be simulated via Testing tool), delivers an XDR/XDM Message which the HISP then converts to S/MIME and then sends that to a receiving system which can be simulated by a testing tool capable of processing S/MIME messages. So the System under test is the Sending HISP which takes XDM/XDR messages and converts it to S/MIME. The resolution was there were no changes to the specifications. || Complete ||
 * 37 || Mod Spec Development Team || For the mod spec requirement 175, does Direct mandate a particular format for this( given that the new requirement that all messages MUST be signed and encrypted)? For example, per RFC 5751, Section 3.6, Encryption can take place prior to signing or after signing. The following text is from that section: There are security ramifications to choosing whether to sign first or encrypt first. A recipient of a message that is encrypted and then signed can validate that the encrypted block was unaltered, but cannot determine any relationship between the signer and the unencrypted contents of the message. A recipient of a message that is signed then encrypted can assume that the signed message itself has not been altered, but that a careful attacker could have changed the unauthenticated || DIRECT uses End to End message security, so for that reason the content should be signed first and then encrypted, the source of the message should always be protected along with the signature so that the origin of the message can be verified from a security standpoint. Also the body of the message should be encrypted so that you are protecting the entire message. For the resolution, IG was added. || Complete ||
 * 38 || Mod Spec Development Team || In the mod spec requirement 36, STAs MUST be capable of also recognizing Enveloped Data with media type application/x-pkcs-mime. Is there just one flavor of encryption (as noted in RFC 5751 Section 3.3) that needs to be verified with each outgoing message? It is known that STAs need to be prepared to accept “application/x-pkcs-mime” per requirement 36. But should originators of messages be allowed to encrypt their messages using this protocol? || The requirement is for receivers for compatibility purposes. The encryption algorithms allowed and preferred by DIRECT are already part of other requirements. As for the resolution, no change was made to specifications. || Complete ||
 * 39 || Mod Spec Development Team || In the mod spec requirement 40, should the signing format to multipart/signed as described in RFC 5751 Section 3.4.3 be restricted? Or does it also allow the application/pkcs7-mime with Signed Data format as described in RFC 5751 Section 3.4.2? || It is restricted to multipart/signed for main body part within the DIRECT specifications. || Complete ||
 * 40 || Mod Spec Development Team || In the mod spec requirement 38, the sender may need to encrypt the header fields. With this being said, should every message have the header fields encrypted? Also, which header fields should be encrypted? || It is not a requirement to encrypt header fields; however a STA might choose to do that recognizing the fact that there might be sensitive data like PII in the Subject Field. The Key is to ensure that all sensitive data is protected. So for example if an organization has a policy to not use sensitive data in the subject field, they might use a STA which does not encrypt the subject field, and on other occasions organizations might be extra cautious and use STA's that encrypt the subject lines. In conclusion, IG was added to the specifications. || Complete ||
 * 41 || Mod Spec Development Team || In the mod spec requirement 49, STAs MUST send Message Disposition Notification messages conforming to RFC 3798 and implementing the message security requirements in this document I [NA] R [R] on successful receipt and trust verification of a message. ForRequisition 93, the transport conversions REQUIRED are between SOAP and SMTP. There are two cases of this conversion, converting from SMTP to SOAP and vice versa. I [R] R [NA] When converting from SMTP to SOAP, which of the following is the correct sequence? Assume the “SOAP response receiver to converter” is returned synchronously; does it have to have the actual XDR response if the converter used immediate messaging or should it be acknowledged if the converter used is deferred? Based on RTM 49 IG, I would assume the second sequence. || The MDN response is at the SMTP stack level and is not dependent on the SOAP processing during the conversion. So the MDN just notifies that the message was received and trust was verified. It does not provide information on if the user actually read it or if a SOAP end point actually consumed it without errors. For the resolution IG was added to mod spec requirement 49. || Complete ||
 * 42 || Mod Spec Development Team || In mod spec requirement 173, (Document Entry Metadata)the XDS metadata attribute 'limitedMedata' is REQUIRED if sending minimum metadata. Also the Document Entry MUST be flagged using an ebRIM Classification with a classification Scheme of urn:uuid:ab9b591b-83ab-4d03-8f5d-f93b1fb92e85. I [C] R [NA] mod spec issue # 174 (Submission Set Metadata): The XDS metadata attribute 'limitedMedata' is REQUIRED if sending minimum metadata and the submission set MUST be flagged using an ebRIM Classification with a classification scheme of urn:uuid:5003a9db-8d8d-49e6-bf0c-990e34ac7707. I [C] R [NA] Why does the table in Table 3.32.4.1-2 ITI-32 Metadata Requirements in [] have “n/a” for the limitedMetadata attribute? If an XDM source has the ability to use limited metadata just like an S/MIME source, why shouldn’t they use the limitedMetadata attribute? || The intent is to allow limited metadata sources like SMTP senders to specify the level of metadata. If one is XDM/XDR sender already, the assumption is that they would know how to generate all the required metadata and would not have to use the limited metadata attribute. The question can be asked to the IHE folks to see if they think of any other reason why it would not be applicable.In conclusion no change was made to the specifications. || Complete ||
 * 43 || Mod Spec Development Team || In mod spec issue, IHE, why is Home Community Id “N/a” in ITI-32 Metadata Requirements in [] ? || Home Community Id is not a required metadata item for document entry or submission set and hence it is not being considered in the DIRECTED exchange. There might be a few others that fall into this bucket of metadata. || Complete ||