Description
At the March 6th, 2012 meeting of the Infrastructure Framework subcommittee, the members continued to review and resolve comments from the public review of the draft DE 2.0. The members discussed the following topics:
1. TOPIC: Is “classified/unclassified” sufficient for default terms for confidentiality? (Answer: Yes. A concern was raised that these terms may suggest that confidentiality is slanted toward government or Department of Defense use, but that is not the case. Picking other terms raises its own set of issues. The consensus opinion is that “classified/unclassified” is generic and will encourage users to think about and select a more appropriate list from the appropriate domain, without this standard picking one over another.)
2. TOPIC EMFW-17: Should we add a section up front in the specification to better explain how to link Distribution Element 2.0 (DE 2.0) objects? (Answer: Yes. A motion was approved to “Add Section 1.3.5 'Linking Content Objects and Other DE Components' and provide a better explanation of this topic in one spot and reference it in those elements that enable linking”.)
3. TOPIC EMFW-16: Should we move the current section 3.2.10, explaining the common elements, up front in the specification since prefixes like “ct:” are used in the specification prior to the explanation? (Answer: Yes. A motion was approved to “Add to the specification a section 1.3.6 'Common Elements' and move the content of Section 3.2.10 to this new section 1.3.6 and fix the reference to 'edxl-cig' to 'edxl-ct' for the geopolitical location type. ”)
4. TOPIC EMFW-15: Can users adequately distinguish a DE 2.0 message from a DE 1.0 message? (Answer: Yes. A DE 2.0 message can be distinguished by it's namespace, and by validating the message against the DE 2.0 schema. A motion was approved that “No change needed. The namespace and validation according to the schema is the way to tell what version you are using.”)
5. TOPIC EMFW-14 and 13: What type of signing is appropriate for the DE 2.0 and is the location of ##other sufficient to enable this? (Answer: The consensus was that the signing component of the DE should allow for signing the entire message when the EDXLDistribution wrapper element is used. Signing ensures receivers can verify the integrity of an entire DE message; however, signing of content objects themselves should be left to the creators of those content objects and enabled by the corresponding content object schema, not the DE 2.0. The location of ##other needs further review to determine whether it is in the correct spot in the schema. Motion: “Our intent is to allow signing of the entire DE 2.0 when the EDXLDistribution wrapper is used, but otherwise content providers are responsible for their own signing and encryption of their content objects and if DE 2.0 components, like Content, are used with other wrappers then the user is responsible for signing using whatever mechanisms are provided by the other wrapper.”)
References:
(1) JIRA DE 2.0 Issues List: http://tools.oasis-open.org/issues/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10084
