Format Specifications Needed

[dlemire60]

The following items could benefit from more refined format specifications in order to reduce the potential for interoperability problems:

1. mime_type (3.4.1.1) -- could apply a regex to match the IANA type/subtype format
   (EDIT: this item was addressed in PR #405 )

2. device_id (3.4.1.2) -- the "string" format should be refined to something more specific

3. Command-ID (3.2.4.16) -- currently specified as a string of 0-36 characters; should be refined to something more specific

4. Version (3.2.4.17) -- consider defining a more specific format, such Major.Minor.Patch semantic numbering or similar
   (EDIT: this item was addressed by PR #403 )

(source: HII software team)

[dlemire60]

Discussed at the 8/10 working meeting, with @davaya providing the following perspective:

1) mime_type (3.4.1.1) -- agrees could specify a suitable regex to limit this string 1) device_id (3.4.1.2) -- as with issue #385 , @davaya's view is that we don't yet know enough to be more definitive about this type 1) Command-ID (3.2.4.16) -- the specified string of 0-36 characters is sized to hold a UUID in string format with delimiting dashes; since this field is for producers and consumers to correlate requests and responses, OpenC2 "doesn't care" exactly what's in the field, as the participants in a command / response exchange will only need to match a string value 1) Version (3.2.4.17) -- need to examine how this is used; if only for OpenC2 version then a major.minor format would fine and @davaya is supportive. If applied to the versions of other things then a more flexible approach is needed.

@dlemire60 will review these types and prepare a suitable PR.

[dlemire60]

Regarding versions:

• type is used in the specification of response results (3.3.2.2), cited as "List of OpenC2 language versions supported by this Consumer"
• type is used in the specification of feature (3.4.2.4), same language
• type is defined in 3.4.2.17 as "String", with description of "Major.Minor version number"
• query features command description (4.1) includes "With the "versions" Target Specifier MUST respond with status 200 and populate the versions field with a list of the OpenC2 Language Versions supported by the consumer." That's illustrated in Example 2 (4.2.2).

So it appears that data type is limited to describing OpenC2 versions, as of v1.1, WD02 of the LS.

[dlemire60]

regarding mime_type, several observations apply:

1. Per RFC 6838, this should probably be renamed media_type to be consistent with IETF usage. The RFC says "The media type specification and registration procedure is now a separate document, to make it clear that it is independent of MIME."
2. The cited RFC describes the registration process for creating media_type values, but isn't the list of values themselves. The appropriate reference for that is the media type index cited in the RFC: http://www.iana.org/assignments/media-types/
3. This registry reference should be handled similarly to the Layer 4 Protocol registry issues discussed in issue #390, as both the media_type and the L4-Protocol values are enumerated in dynamic registries external to OpenC2.
4. A regex to limit the media_type may be unnecessary, given the existence of the registry; certainly it's not a straightfoward regex to create (or maintain).

[dlemire60]

Propose closing this issue. Items 1 and 4 have been addressed by PRs (as now annotated in the original comments) and items 2 and 3 remain in the "we aren't smart enough to define" category (per this comment above.)

Open question whether to create new issue(s) for items 2 and 3 or wait until they actually are an issue for OpenC2 implementers (e.g., we hear an outcry).

[dlemire60]

PR #431 updates the definition of Command-ID with a description and a usage requirement: SHOULD be a UUIDv4.

Open question: the Message structure defined in LS section 3.2 and the Headers map include a request_id of type String which is used in the same way / purpose as the command_id in a Command message (section 3.3.1); should the request_id type be changed to Command-ID?

[dlemire60]

PRs have addressed items 1, 3, and 4 of the original issue submission. Item 2 is deferred.

This issue is now closed, per consensus at the 10 January 2024 working meeting.