Recent changes to ieee11073-20702

Add means to identify a consumer in RR & Eventing

Stefan Schlichting — Mon, 09 Mar 2026 09:26:22 -0000

There are recurring discussions that a service provider shall be able to determine the kind of a consumer, an identity and potentially a human-readable friendly name. There should be also the possibility included to explicitely communicate the consumer priority in contrast to the implicit means defined in 11073-20701, chapter "Prioritization of connection establishment".

Proposal is to include either directly the xml constructs of dpws:ThisModel & dpws:ThisDevice and define an xml element or attribute for the priority.

#19 R0010/R0011 wording

Stefan Schlichting — Mon, 05 Jan 2026 11:57:57 -0000

status: open --> accepted

#20 R0017: Contradiction in second sentence

Stefan Schlichting — Mon, 05 Jan 2026 11:55:37 -0000

Proposal: Move second sentence to note. Change sentence to "Acceptable credentials are those credentials that can be processed by the RECEIVER."

#21 WS-Discovery filtering causes an unexpected behavior for action-based filtering

Stefan Schlichting — Mon, 05 Jan 2026 11:49:00 -0000

See https://en.wikipedia.org/wiki/Substring#Prefix

Basic Profile requirement unfulfillable

Benjamin Hohlmann (STX) — Wed, 03 Dec 2025 10:22:08 -0000

MDPWS Section 6 includes all requirements of WS-I Basic Profile 2.0 Section 4, including:

R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in operation signatures that are different from one another.

While MDPWS:R0009 supersedes the requirements for "Notifications" and explicitly allows one-way streaming messages, it does not override the above requirement.
Yet, as one-way streaming operations have no input message, their operation signatures are indistinguishable.

See "4.7.5 Operation Signatures": https://docs.oasis-open.org/ws-brsp/BasicProfile/v2.0/BasicProfile-v2.0.html

Proposals:
a) Add requirement that supersedes and cancels BP:R2710
-or-
b) Clarify in the note of MDPWS:R0009, that streams do not need to have unique signatures.

Limit wse:Expires to be of type xs:duration

Albrecht — Wed, 22 Oct 2025 09:13:44 -0000

Add a note or requirement that thewse:Expires shall be of type xs:duration

WS-Eventing allows wse:Expires to be either of type xs:dateTime orxs:duration. Restricting wse:Expires to xs:duration reduces complexity and eliminates the need for time synchronization between the SDC Consumer and SDC Provider.

(SDPi already defines such a constrain, also limiting the regex - see https://profiles.ihe.net/DEV/SDPi/index.html#_subscribe_message)

#27 Enforce UUIDs for device EPR addresses

Winfried — Wed, 23 Jul 2025 08:49:48 -0000

Description has changed:

Diff:

--- old
+++ new
@@ -1,4 +1,7 @@
-DPWS R0004 states that &#34;A DEVICE SHOULD use a `urn:uuid` scheme IRI as the `[address]` property of its Endpoint Reference.&#34; (see attachment)
+DPWS R0004 states that &#34;A DEVICE SHOULD use a `urn:uuid` scheme IRI as the `[address]` property of its Endpoint Reference.&#34; (see attachment):
+
+![DPWS R0004](https://sourceforge.net/p/opensdc/ieee11073-20702/27/attachment/image-2025-3-17_9-33-43.png)
+

 As far as we know, everybody in the SDC world follows this suggestion. To reduce edge cases/implementation effort, we suggest to enforce the use of UUIDs for device EPR addresses in MDPWS: &#34;A DEVICE **SHALL** use a `urn:uuid` scheme IRI as the `[address]` property of its Endpoint Reference.&#34;

#27 Enforce UUIDs for device EPR addresses

Winfried — Wed, 23 Jul 2025 08:46:10 -0000

Description has changed:

Diff:

--- old
+++ new
@@ -3,6 +3,7 @@
 As far as we know, everybody in the SDC world follows this suggestion. To reduce edge cases/implementation effort, we suggest to enforce the use of UUIDs for device EPR addresses in MDPWS: &#34;A DEVICE **SHALL** use a `urn:uuid` scheme IRI as the `[address]` property of its Endpoint Reference.&#34;

 Rationale:
+
 * It&#39;s SHOULD already ;-). R0005 requires a &#34;stable, globally unique identifier&#34;, and UUIDs are clearly a perfect fit.
 * Reducing flexibility generally increases interoperability
 * **Writing device data to a file**: it would be natural to use the device&#39;s EPR address (=&#34;stable, globally unique identifier&#34;) as file name (or part of the file name). Which is not possible today without taking extra care, because arbitrary IRIs could contain characters that are illegal or at least problematic in a filename like `/`, `:`, `#`, `&amp;`,... UUIDs in hexadecimal string representation on the other hand do not contain any &#34;file name unfriendly&#34; characters.

#27 Enforce UUIDs for device EPR addresses

Winfried — Wed, 23 Jul 2025 08:45:55 -0000

Description has changed:

Diff:

--- old
+++ new
@@ -1,3 +1,10 @@
-DPWS R0004 states that &#34;A DEVICE SHOULD use a urn:uuid scheme IRI as the [address] property of its Endpoint Reference.&#34; (see attachment)
+DPWS R0004 states that &#34;A DEVICE SHOULD use a `urn:uuid` scheme IRI as the `[address]` property of its Endpoint Reference.&#34; (see attachment)

-As far as we know, everybody in the SDC world follows this suggestion. To reduce edge cases/implementation effort, we suggest to enforce the use of UUIDs for device EPR addresses in MDPWS: &#34;A DEVICE **SHALL** use a urn:uuid scheme IRI as the [address] property of its Endpoint Reference.&#34;
+As far as we know, everybody in the SDC world follows this suggestion. To reduce edge cases/implementation effort, we suggest to enforce the use of UUIDs for device EPR addresses in MDPWS: &#34;A DEVICE **SHALL** use a `urn:uuid` scheme IRI as the `[address]` property of its Endpoint Reference.&#34;
+
+Rationale:
+* It&#39;s SHOULD already ;-). R0005 requires a &#34;stable, globally unique identifier&#34;, and UUIDs are clearly a perfect fit.
+* Reducing flexibility generally increases interoperability
+* **Writing device data to a file**: it would be natural to use the device&#39;s EPR address (=&#34;stable, globally unique identifier&#34;) as file name (or part of the file name). Which is not possible today without taking extra care, because arbitrary IRIs could contain characters that are illegal or at least problematic in a filename like `/`, `:`, `#`, `&amp;`,... UUIDs in hexadecimal string representation on the other hand do not contain any &#34;file name unfriendly&#34; characters.
+* **Sending device data via message-oriented middleware (MOM)**: it would be natural to use the device&#39;s EPR address (=&#34;stable, globally unique identifier&#34;) as name for the &#34;topic&#34;/&#34;channel&#34;/&#34;queue&#34;/whatever concept your MOM offers for data separation. For arbitrary IRIs you would need to take extra care that the IRI does not contain characters that are illegal for this purpose. E.g., in MQTT topic names, `/`, `+`, `#`, `*`, `$` have a special meaning, while Kafka topic names only allow `[a-zA-Z0-9._-]`. Also, length limits apply, that could be violated by an arbitrary IRI. Using only UUIDs in hex representation would guarantee only unproblematic characters and a fixed length, so it could directly be used as MOM target name.
+* **Writing device data to a database**: it would be natural to use the device&#39;s EPR address (=&#34;stable, globally unique identifier&#34;) as key. For arbitrary IRIs you would need to take extra care to choose a Unicode-friendly key data type with variable length, like NVARCHAR in SQL, with all the complexity like char-length != byte-length and performance disadvantages. For UUIDs on the other hand you could use a fixed-length BINARY or CHAR data type with excellent storage efficiency and performance.

#27 Enforce UUIDs for device EPR addresses

Winfried — Wed, 09 Jul 2025 14:03:44 -0000

Description has changed:

Diff:

--- old
+++ new
@@ -1,3 +1,3 @@
 DPWS R0004 states that &#34;A DEVICE SHOULD use a urn:uuid scheme IRI as the [address] property of its Endpoint Reference.&#34; (see attachment)

-As far as we know, everybody in the SDC world follows this suggestion. To reduce edge cases/implementation effort, we suggest to enforce the use of UUIDs for EPR addresses in MDPWS: &#34;A DEVICE **SHALL** use a urn:uuid scheme IRI as the [address] property of its Endpoint Reference.&#34;
+As far as we know, everybody in the SDC world follows this suggestion. To reduce edge cases/implementation effort, we suggest to enforce the use of UUIDs for device EPR addresses in MDPWS: &#34;A DEVICE **SHALL** use a urn:uuid scheme IRI as the [address] property of its Endpoint Reference.&#34;