DDS-SECURITY 1.1 RTF Avatar
  1. OMG Issue

DDSSEC11 — Provide mechanisms to extend Governance and Permissions files without breaking interoperability

  • Key: DDSSEC11-10
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not state what to do when Permissions and Governance files contain "extra elements" that are not valid according to the XSD.

    This is expected to occur both as a result of vendor extensions as well as due to additions in future versions of DDS Security.

    Allowing these extensions/additions without breaking compatibility is important. So the spec should be clear in that they are allowed and also provide rules/guidelines on them.

    Some possibilities:

    • Simply state that elements that are not expected/understood should be ignored
    • Same as above but provide some structure for those elements. E.g. specify that they must have a "vendorId" attribute (used to avoid collisions) and a "mustUnderstand" attribute used to force failure in some cases.
    • Define an "extensions" element that has known structure (e.g. name/value pairs) which is the one used for the extensions.
    • Others to be proposed.

    Common approaches are described here: http://www.ibm.com/developerworks/library/x-xtendschema/

  • Reported: DDS-SECURITY 1.0b1 — Sat, 20 Feb 2016 01:36 GMT
  • Disposition: Deferred — DDS-SECURITY 1.1
  • Disposition Summary:

    Defer to RTF2

    This issue has been deemed of lower priority and some of the proposals to address it depend on standards that are not widely supported. Hence the RTF has determined to defer it to the next RTF in the hope that the situation and requirements will be more clear by then.

  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments: