In general, the ranges of command codes byte values that are defined for Vendor or Standards use in specification Table 16 in Section 5.1.9.3 (i.e., the main table that defines the I3C Common Command Codes) can be used by any implementer or any standards developing organization to define custom CCCs that extend I3C to accommodate new use cases. However, the definition of custom CCCs should be considered carefully because the practical issues of implementation might lead to situations where interoperability could be affected across multiple I3C Target Devices that interpret the same command code differently.
For example, different implementers or standards groups might define a custom CCC using the same command code value (i.e., CCC byte value) with (for a Direct GET CCC) different interpretations of the message format that their custom Target Device should return, or (for a Direct SET CCC) different expectations about how their custom Target Device should act; or different expectations about which Defining Bytes might be supported for this CCC, for their custom Target Device. For these conflicting definitions, interoperability issues would certainly arise if the Controller used this custom CCC on an I3C Bus that used custom Target Devices from multiple implementers, or custom Target Devices that conformed to different standards published by several such standards groups. The Controller would not necessarily have knowledge of this situation until it detected protocol issues or encountered other errors.
To help alleviate this situation, I3C v1.1 and I3C Basic v1.1.1 add a new SETBUSCON CCC (see specification Section 5.1.9.3.31) that allows the Controller to set the Bus context. This CCC informs Targets about which version of I3C is used on the Bus, and whether it is a standards-based Bus and/or a vendor-private Bus. This information allows the Target to coordinate its interpretation of extended CCCs, as well as other uses of the Bus, to match the actual current Bus context. Although the SETBUSCON feature is fully optional, it provides a powerful way to align standards-group-based uses of I3C with coordinated private uses. To foster proper coordination, SETBUSCON Context Byte values are published on the MIPI Alliance public website [MIPI11], and may be assigned by request.
MIPI Alliance strongly recommends that standards groups utilize the SETBUSCON CCC to prevent such interoperability issues, by requesting an assigned Context Byte for their particular usage, which might include a specific interpretation of any command codes that are defined for vendor or Standards use. Additionally, such custom Target Device implementations should not enable this custom interpretation by default, until they receive the SETBUSCON CCC with an assigned Context Byte from the I3C Controller.
MIPI Alliance offers a similar recommendation to implementers seeking to define custom CCCs for private use in a custom Target Device, by using similar logic in such a Target implementation to not enable this custom interpretation by default, until receiving the SETBUSCON CCC with a suitable Context Byte from the I3C Controller to explicitly enable a private interpretation.