Discourage arbitrary extensions

Section Number

Appendix 2:A ISO/IEEE 11073 SDC / MDPWS Message Specifications (Normative)

Priority

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

I think this one won't be controversial; just making explicit what a couple of people said when I asked about it.

Issue

The many extension points in BICPES allow, at least theoretically, a consumer to include large amounts of data in messages (up to the 4 MB message limit; MAX_LARGE_ENVELOPE_SIZE, 20702). Including a patient or location thumbnail photo, for example, could be a useful extension but may overwhelm some participants. There may also be safety and / or security implications with storing and passing on unknown content.

10700, §6.7 TR1342 allows consumers to ignore extensions they don't understand as long as they don't use them, But this section seems to ignore the plight of providers.

Proposed Change

Two new requirements, the first mirroring TR1342 , the second allowing the provider to ignore extensions it doesn't understand.

Rxxx1
If a BICEPS service provider is unable to interpret an extension in a message from a SDC base consumer with @ext:MustUnderstand = true then it shall not use the BICEPS containment subtree the @ext:MustUnderstand = true is attached to.

Note: this means the service provider won't include the content of the subtree in any AbstractState.

Rxxx2
If a BICEPS service provider is unable to interpret an extension in a message from a SDC base consumer with @ext:MustUnderstand = false then it may include content from the BICEPS containment subtree in relevant AbstractStates.

Note: this means the service provider is not required to store or serve content it doesn't understand.

This might ultimately be a better fit for ec-pkp, though it may be relevant for remote operations with extension data from the Alert Pkp as well. Perhaps SDPi is a good home for now?