standards - 后缀是否符合 UUID 派生的 DICOM UID 标准？

Question

附加 discussion on the comp.protocols.dicom google group .

具体例子:

鉴于实例 UID 是从 UUID 派生的，如 PS3.5 B.2 中所述。 .

例如，给定以下 DICOM 实例 UID:

2.25.329800735698586629295641978511506172918

通过添加附加组件是否标准符合该 UID 的后缀？

2.25.329800735698586629295641978511506172918.1, 
2.25.329800735698586629295641978511506172918.2, 
...

忧虑:

通过阅读标准，我以某种方式得到的印象是，DICOM 标准仅将这种形式的 UID 定义为有效，前提是它仅包含 2.25。有效 UUID 的前缀和十进制表示 - 仅此而已:

ISO/IEC 9834-8 / ITU-T X.667 defines a method by which a UID may be constructed from the root "2.25." followed by a decimal representation of a Universally Unique Identifier (UUID). That decimal representation treats the 128 bit UUID as an integer, and may thus be up to 39 digits long (leading zeros must be suppressed).

它没有明确说明是否可以有后缀。

它的最大长度为 5 + 39 个字符，因此在 UID 的 64 个字符限制之前仍有一些空间。

执行来自 PS3.5 9.1 的所有规则仍然适用于 PS3.5 B.2 的 UID 定义只是有一个固定的根？或者是PS3.5 B.2一个独立的定义？

有关 UUID 派生 UID 的其他信息:

据我了解 DICOM 标准， PS3.5 B.2于 2012 年添加，是 PS3.5 9.1 定义的普通 UID 定义的一个异常(exception)。和 PS3.5 B.1 .
它不需要组织根前缀。相反，它使用通用前缀 2.25对于从 UUID 派生的所有实例 UID。
重要的是要注意，它应该只用于实例 UID。
看:

A UUID derived UID may be appropriate for dynamically created UIDs, such as SOP Instance UIDs, but is usually not appropriate for UIDs determined during application software design, such as private SOP Class or Transfer Syntax UIDs, or Implementation Class UIDs.

作为指向此异常的附加指针 ( source ):

Another approach to generating UIDs that does not require obtaining one's own root prefix can take advantage of a standard prefix established for using a Universally Unique Identifier (UUID) [...] in essence it involves converting the normal hyphenated hexadecimal string form of a UUID into a single large decimal number and appending it to the prefix "2.25."

Answer 1

绝对不。

您不能添加任何内容作为 2.25 + UUID 的后缀。