Foreword

The Redfish Interoperability Profile specification was prepared by DMTF's Redfish Forum.

DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems management and interoperability. For information about DMTF, see https://www.dmtf.org.

Acknowledgments

DMTF acknowledges the following individuals for their contributions to this document:

• Richelle Ahlvers — Broadcom Inc.
• Jeff Autor — Vertiv, Hewlett Packard Enterprise
• George Ericson — Dell Technologies
• Tomas Gonzalez — Majec Systems, Inc.
• Jon Hass — Dell Technologies
• Jeff Hilland — Hewlett Packard Enterprise
• François Homps — Atos
• John Leung — Intel Corporation
• Michael Raineri — Dell Technologies
• Paul Vancil — Dell Technologies

1 Abstract

As schema definitions for the Redfish Specification ("Redfish") are designed to provide significant flexibility, and allow conforming implementations on a wide variety of products, very few properties within the schemas are required by the Redfish Specification. But consumers and software developers need a more rigidly defined set of required properties (features) in order to accomplish management tasks. This set allows users to compare implementations, specify needs to vendors, and allows software to rely on the availability of data. To provide that "common ground", a Redfish interoperability profile allows the definition of a set of schemas and property requirements, which meet the needs of a particular class of product or service.

A Redfish interoperability profile is a JSON document that contains schema-level, property-level, and registry-level requirements. At the property level, these requirements can include a variety of conditions under which the requirement applies.

2 Overview

The Redfish Specification separates the definition of the protocol from the data model (schema), and in addition, allows each resource defined in the data model to be revised independently. While this creates significant flexibility and extensibility, it can cause confusion when developers and end users attempt to answer the question "What version of Redfish does your product support?" The answer is not a simple one, because fully describing a Redfish implementation would require listing each property supported in each schema implemented, as well as the protocol version and supported features. That level of detail and version reporting would be extremely cumbersome to create or maintain, and difficult to use to compare implementations across products or vendors.

The Redfish interoperability profile concept was created to simplify that process, by providing a means to communicate the functionality provided with a single statement - that an implementation meets the requirements set forth in a Redfish interoperability profile.

A profile is constructed in a machine-readable (JSON) document that serves two purposes. First, it enables the creation of a human-readable document that merges the profile requirements with the Redfish schema into a single document for developers or users. Second, it allow a conformance test utility to test a Redfish service implementation for conformance with the profile.

3 Normative references

The following referenced documents are indispensable for the application of this document. For dated or versioned references, only the edition cited (including any corrigenda or DMTF update versions) applies. For references without a date or version, the latest published edition of the referenced document (including any corrigenda or DMTF update versions) applies.

• IETF RFC 3986 T. Berners-Lee et al., Uniform Resource Identifier (URI): Generic Syntax, https://www.ietf.org/rfc/rfc3986.txt
• ISO/IEC Directives, Part 2, Principles and rules for the structure and drafting of ISO and IEC documents, https://www.iso.org/sites/directives/current/part2/index.xhtml
• IETF RFC 6901, P. Bryan, Ed. et al., JavaScript Object Notation (JSON) Pointer, https://www.ietf.org/rfc/rfc6901.txt
• JSON Schema: A Media Type for Describing JSON Documents, Draft 7 https://tools.ietf.org/html/draft-handrews-json-schema-01
• JSON Schema Validation: A Vocabulary for Structural Validation of JSON, Draft 7 https://tools.ietf.org/html/draft-handrews-json-schema-validation-01
• DMTF Redfish Specification, DSP0266 https://www.dmtf.org/dsp/DSP0266
• OpenAPI Specification https://github.com/OAI/OpenAPI-Specification
• ECMA-262, ECMAScript® 2025 language specification, https://https://ecma-international.org/publications-and-standards/standards/ecma-262/

4 Terms and definitions

Some terms and phrases in this document have specific meanings beyond their typical English meanings. This clause defines those terms and phrases.

The terms "shall" ("required"), "shall not", "should" ("recommended"), "should not" ("not recommended"), "may", "need not" ("not required"), "can" and "cannot" in this document are to be interpreted as described in ISO/IEC Directives, Part 2, Clause 7. The terms in parenthesis are alternatives for the preceding term, for use in exceptional cases when the preceding term cannot be used for linguistic reasons. Note that ISO/IEC Directives, Part 2, Clause 7 specifies additional alternatives. Occurrences of such additional alternatives shall be interpreted in their normal English meaning.

The terms "clause", "subclause", "paragraph", and "annex" in this document are to be interpreted as described in ISO/IEC Directives, Part 2, Clause 6.

The terms "normative" and "informative" in this document are to be interpreted as described in ISO/IEC Directives, Part 2, Clause 3. In this document, clauses, subclauses, or annexes labeled "(informative)" do not contain normative content. Notes and examples are always informative elements.

The term "deprecated" in this document is to be interpreted as material that is not recommended for use in new development efforts. Existing and new implementations may use this material, but they should move to the favored approach. Deprecated material may be implemented in order to achieve backwards compatibility. Deprecated material should contain references to the last published version that included the deprecated material as normative material and to a description of the favored approach. Deprecated material may be removed from the next major version of the specification.

5 Design tenets

All profile entries, at the profile, resource, or property level, are "additive". That is, each requirement can only apply more rigid requirements that override less rigid requirements.

Profile requirements do not allow for exclusions of data. Implementations are able to provide more data in their resources than required by a profile, as an implementation likely addresses multiple use cases or profiles. This includes both standard properties and OEM extensions.

6 Profile tools

A free, open source utility has been created by the Redfish Forum to verify that a Redfish service implementation conforms to the requirements included in a Redfish interoperability profile. The Redfish Interop Validator is available for download from DMTF's organization on GitHub at: https://github.com/DMTF/Redfish-Interop-Validator

A documentation generator has also been created by the Redfish Forum that will create a "guide" using the Redfish schema and the profile document. The output is intended for use by both developers and end users to understand the implementation requirements of a profile. The Redfish Documentation Generator is available for download from DMTF's organization on GitHub at: https://github.com/DMTF/Redfish-Tools

7 Profile repository

Redfish interoperability profiles published or re-distributed by DMTF are available for download from the Redfish profile repository located at: http://redfish.dmtf.org/profiles

8 Profile document definition

A Redfish interoperability profile is specified in a JSON document. The JSON objects and properties contained in the document are described in this specification, and are also available in a JSON-schema form (RedfishInteroperabilityProfile.v1_x_x.json) from DMTF's Redfish schema repository at http://redfish.dmtf.org/profiles for download. The json-schema can be used to validate a profile document to ensure compatibility with automated conformance tools or utilities.

The JSON document structure is intended to align easily with JSON payloads retrieved from Redfish service implementations, to allow for easy comparisons and conformance testing. Many of the properties defined within this structure have assumed default values that correspond with the most common use case, so that those properties can be omitted from the document for brevity.

8.1 File name conventions

The document that describes a profile follows the Redfish schema file naming conventions from the Redfish Specification. The file name format for profiles shall be:

<ProfileName>.v<MajorVersion>_<MinorVersion>_<Errata>.json

For example, the file name of the BasicServer profile v1.2.0 is BasicServer.v1_2_0.json. The file name shall include the profile name and version, which matches those property values within the document.

8.2 Basic functions

At the top level of the JSON document are the basic properties, which describe the profile, including authorship and contact information, versioning, and other profiles to include in order to build upon previous work.

8.2.1 ProfileType`

The ProfileType property enables or disables various features of the profile definition to align with the intended usage of the profile document. As the scope and usage of the profile concept has expanded, the use of a top-level type selector provides a simple means to accommodate additional functionality that would either not apply or directly conflict with the intended purpose of the profile definition.

8.2.1.1 ProfileType values

8.2.2 Required profiles

The RequiredProfiles object contains object properties that are named to match the name of the profile to be included. Each of these sub-objects contains the properties listed below.

8.2.3 Example

The following is an example of the top-level properties in a profile, with two required profiles included.

{
    "SchemaDefinition": "RedfishInteroperabilityProfile.v1_9_0",
    "ProfileName": "Anchovy",
    "ProfileVersion": "1.0.2",
    "OwningEntity": "Pizza Box Consortium",
    "ContributedBy": "Contoso Anchovy Committee",
    "License": "BSD 3-clause.",
    "Purpose": "This is a sample Redfish Interoperability profile.",
    "ContactInfo": "pizza@contoso.com",
    "RequiredProfiles": {
        "DMTFBasic": {
            "MinVersion": "1.0.0"
        },
        "ContosoPizza": {
            "Repository": "http://contoso.com/profiles",
            "MinVersion": "1.0.0"
        }
    }
}

8.3 Protocol requirements

An object named Protocol contains properties which describe Redfish protocol functionality that is not related to the supported schemas or properties. Therefore, these functions cannot be validated by comparing retrieved JSON payloads.

8.3.1 Example

{
    "Protocol": {
        "MinVersion": "1.24",
        "Discovery": "Mandatory",
        "HostInterface": "Recommended",
        "ExpandQuery": "Mandatory",
        "SelectQuery": "None",
        "FilterQuery": "Recommended",
        "OnlyQuery": "Mandatory",
        "ExcerptQuery": "Recommended",
        "DeepPOST": "Recommended",
        "DeepPATCH": "Recommended"
    }
}

8.3.2 Requirement values

8.4 Resource (schema) requirements

The primary content in a Redfish profile is the set of supported property requirements. As Redfish is organized and defined by schema-backed JSON resources, these requirements are also organized by schema.

For each schema, an object is created in the JSON document, named to match the schema name. Within this object, properties describe the location of the schema file, and schema-level requirements. Within each schema-level object is a PropertyRequirements object that describes the property-level requirements for that schema. The definition of both the schema/resource-level and property-level requirements are accomplished using the same mechanisms, which are described in the next clause.

The structure of the resource and property requirements is:

{
    "<schema-name>": {
        "MinVersion": "<version>",
        "CreateResource": "<boolean>",
        "DeleteResource": "<boolean>",
        "UpdateResource": "<boolean>",
        "URIs": [
            "<uri-pattern>",
            "<uri-pattern>"
        ],
        "PropertyRequirements": {
            "<property-name>": {
                "<property-requirements>": "<property-requirements-value>"
            },
            "<property-name>": {
                "<property-requirements>": "<property-requirements-value>"
            }
        },
        "ActionRequirements": {
            "<action-name>": {
                "<action-requirements>": "<action-requirements-value>"
            }
        },
        "ConditionalRequirements": [
            {
                "<conditional-requirement>": "<conditional-requirements-value>"
            },
            {
                "<conditional-requirement>": "<conditional-requirements-value>"
            }
        ]
    },
    "<additional-schemas>": {}
}

8.4.1 Schema-level functions

The following options are available at the schema level:

8.4.1.0.1 URI patterns

The URIs property provides a means to easily create requirements or conditional requirements for resource types that occur at multiple locations in the resource tree. Profiles that specify one or more URI patterns with no PropertyRequirements for the schema indicates a requirement for the presence of at least one resource that matches each URI pattern.

While Interop profiles may only specify URI patterns defined in Redfish schema, a Product type profile may also define URI patterns using regular expressions that place more restrictive naming requirements based on the pattern of value for resources' Id properties.

Note that early versions of the Redfish Specification prior to version 1.6 (released in 2018) did not require specific URI patterns. Profiles containing URI pattern requirements shall require a Redfish Specification version 1.6 or higher in the profile's Protocol object MinVersion property.

8.4.1.1 Example

This example shows a simple required schema:

{
    "ComputerSystem": {
        "MinVersion": "1.22.0",
        "Purpose": "Every instance must have a logical-view ComputerSystem resource.",
        "PropertyRequirements": {
            "SerialNumber": {},
            "Manufacturer": {},
            "Model": {
                "ReadRequirement": "Recommended"
            }
        }
    }
}

8.4.2 Resource use cases

Some Redfish schemas are re-used for many types of equipment, and also in different parts of the resource tree. The requirements specified in a profile can differ significantly based on a particular resource's usage in the hierarchy. While slight variations in requirements can be handled using conditional requirements, larger variations can instead be expressed with use cases.

The use case resource requirement structure is employed when a particular resource (schema) has two or more significantly different sets of requirements that are dependent on a "type" of that resource, which can be specified using a single property-level comparison, by the URI pattern for those resources, or both.

For example, the Memory schema supports both DRAM (DIMM) and non-volatile (NV-DIMM) memory devices. The management requirements for a NV-DIMM device are considerably different than those for DRAM. By setting up two use cases for the Memory schema, one for "DIMM" and the other for "NV-DIMM" memory, the resulting profile is both easier to construct and easier to comprehend.

The structure for a set of resource use cases follows the resource-level structure, with a single UseCases property in place of the resource-level requirements. Those requirements are specified within each use case:

{
    "<schema-name>": {
        "UseCases": [
            {
                "UseCaseTitle": "<title>",
                "UseCaseKeyProperty": "<property name>",
                "UseCaseKeyValues": [
                    "<values of key property for comparison>"
                ],
                "UseCaseComparison": "<type of comparison>",
                "URIs": [
                    "<uri-pattern>",
                    "<uri-pattern>"
                ],
                "PropertyRequirements": {
                    "<Property Requirements>": "<property requirements values>"
                },
                "ActionRequirements": {
                    "<Action Requirements>": "<action requirements values>"
                }
            },
            {
                "<Second Use Case>": {}
            },
            {
                "<Additional Use Cases>": {}
            }
        ]
    }
}

8.4.2.1 Use case-level functions

Each use case may include any of the options available as a schema-level function. A use case that includes the URIs property, with or without PropertyRequirements or ActionRequirements, creates a requirement for resources of this type to exist at the URI patterns specified. In addition, the following options are also available at the use case level:

8.4.2.2 Use case types

8.4.2.3 Use case example

This example shows a use case selecting requirements by MemoryType for DRAM-based Memory resources under the systems collection, and non-volatile (NV-DIMM) Memory resources anywhere in the resource tree. It then shows the selection of the MemoryMetrics resources using UseCaseType to limit the requirements to those resources subordinate to non-volatile (NV-DIMM) Memory resources.

{
    "Memory": {
        "UseCases": [
            {
                "UseCaseTitle": "DIMM",
                "UseCaseKeyProperty": "MemoryType",
                "UseCaseComparison": "Equal",
                "UseCaseKeyValues": [
                    "DRAM"
                ],
                "URIs": [
                    "/redfish/v1/Systems/{ComputerSystemsId}/Memory/{MemoryId}"
                ],
                "MinVersion": "1.13.0",
                "PropertyRequirements": {
                    "CapacityMiB": {},
                    "Location": {},
                    "Manufacturer": {},
                    "ModuleProductID": {},
                    "OperatingSpeedMhz": {},
                    "PartNumber": {}
                }
            },
            {
                "UseCaseTitle": "NV-DIMM",
                "UseCaseKeyProperty": "MemoryType",
                "UseCaseComparison": "NotEqual",
                "UseCaseKeyValues": [
                    "DRAM"
                ],
                "MinVersion": "1.13.0",
                "PropertyRequirements": {
                    "CapacityMiB": {},
                    "ConfigurationLocked": {},
                    "EnvironmentMetrics": {},
                    "Location": {},
                    "Manufacturer": {},
                    "MemoryDeviceType": {},
                    "MemoryMediaType": {},
                    "Metrics": {},
                    "ModuleProductID": {},
                    "NonVolatileSizeMiB": {},
                    "OperatingSpeedMhz": {},
                    "PartNumber": {},
                    "SerialNumber": {},
                    "Status": {},
                    "VolatileSizeMiB": {}
                }
            }
        ]
    },
    "MemoryMetrics": {
        "UseCases": [
            {
                "UseCaseTitle": "NV-DIMM Metrics",
                "UseCaseType": "MemoryType",
                "UseCaseComparison": "NotEqual",
                "UseCaseKeyValues": [
                    "DRAM"
                ],
                "URIs": [
                    "/redfish/v1/Systems/{ComputerSystemsId}/Memory/{MemoryId}/MemoryMetrics"
                ],
                "MinVersion": "1.7.0",
                "PropertyRequirements": {
                    "BandwidthPercent": {},
                    "CapacityUtilizationPercent": {},
                    "CurrentPeriod": {
                        "PropertyRequirements": {
                            "BlocksRead": {},
                            "BlocksWritten": {}
                        }
                    },
                    "LifeTime": {
                        "PropertyRequirements": {
                            "BlocksRead": {},
                            "BlocksWritten": {}
                        }
                    }
                }
            }
        ]
    }
}

8.4.3 Property-level functions

Within the PropertyRequirements object are additional objects that are named to match the property name in the parent object's schema definition. This object then contains the property-level requirements, which account for the bulk of a profile's definition. One additional level of JSON objects may be embedded, essentially nesting a PropertyRequirements object.

The following options are available at the property level:

8.4.3.1 Example

This example shows property-level requirements. For each Sensor resource, the ReadingType, Reading, Status, and Implementation properties are all mandatory. PhysicalContext is specified as a recommended property. ReadingType specifies further requirements with the AllOf comparison, which indicates the service is required to provide at least one Sensor resource with Temperature as ReadingType and at least one Sensor resource with Voltage as ReadingType. Implementation also specifies further requirements with the Equal comparison, which indicates the required value for the property is PhysicalSensor.

{
    "Sensor": {
        "PropertyRequirements": {
            "ReadingType": {
                "ReadRequirement": "Mandatory",
                "Comparison": "AllOf",
                "Values": [
                    "Temperature",
                    "Voltage"
                ]
            },
            "Reading": {},
            "Status": {},
            "Implementation": {
                "ReadRequirement": "Mandatory",
                "Comparison": "Equal",
                "Values": [
                    "PhysicalSensor"
                ]
            },
            "PhysicalContext": {
                "ReadRequirement": "Recommended"
            }
        }
    }
}

8.4.3.2 Comparison

The Comparison function uses the following enumerations to represent the various comparisons available:

Many of these comparison types are simple arithmetic, boolean, or string value comparisons. In addition, Absent and Present allow for comparisons concerning the existence or absence of a property. The LinkToResource comparison specifies that the object property contains an @odata.id property to a resource whose schema name (type) is listed in the Values array.

The AnyOf and AllOf comparison types can be met using any resource instance within the scope of the schema-level requirement. Comparisons of these types within resource use cases or conditional requirements can only be met by resources that meet the resource use case or conditional requirements.

8.4.3.3 Read requirement

The ReadRequirement function specifies the level of basic read (HTTP GET) requirement applied to the resource or property. The default value, or if no ReadRequirement is present, is Mandatory. For object properties, requirements of the embedded properties will apply only if the object is present.

8.4.3.4 Write requirement

The WriteRequirement function specifies the level of write support (HTTP PATCH or PUT) applied to a property. The default value, or if no WriteRequirement is present, is None. The WriteRequirement applies to a property once the ReadRequirement is met.

8.4.3.5 Conditional requirements

The most flexible aspect of the Redfish profile definition is the ability to make resource or property-level requirements that are dependent on one or more conditional requirements within the resource and the parent resources in the resource tree.

The ConditionalRequirements array function specifies these conditional requirements, which add to any requirements also defined for the resource or property. Note that a condition cannot override or weaken a requirement already specified. For example, if a property requirement is marked as Mandatory, no conditional requirement could mark the property as None. Instead, the property would be specified with a None requirement, and with one or more ConditionalRequirements that would specify when the property requirement becomes Mandatory.

The following options are available for each conditional requirement:

8.4.3.5.1 Parent and subordinate resources

Because there can be several instances of a particular Redfish schema in the resource tree, the requirements placed on those resources may vary depending on their usage. Since the profile is schema-centric, the SubordinateToResource function allows a profile to specify requirements based a resource instance's placement in the resource tree.

SubordinateToResource allows specifying the schema (resource) path from parent resources to the resource to which the requirements apply. This property contains an array of schema names, in the top-down order that they appear in the path to the required resource.

Note that this functionality may also be accomplished using the URIs function for the resource, which is the preferred method.

8.4.3.5.2 Example

For the property HostName in the EthernetInterface schema, the example shows it as Recommended property. But if an instance of EthernetInterface is linked from a ComputerSystem resource, through the EthernetInterfaceCollection resource, the Condition is met, which changes the HostName property requirement to Mandatory.

In the second part of the example, the IPv6Addresses array property is required to have at least one item (MinCount) in the array. But if, as in the previous example, the instance is subordinate to a ComputerSystem (and EthernetInterfaceCollection) resource, at least two items are required in the array.

{
    "EthernetInterface": {
        "PropertyRequirements": {
            "HostName": {
                "ReadRequirement": "Recommended",
                "WriteRequirement": "Recommended",
                "ConditionalRequirements": [
                    {
                        "SubordinateToResource": [
                            "ComputerSystem",
                            "EthernetInterfaceCollection"
                        ],
                        "ReadRequirement": "Mandatory",
                        "Purpose": "Used to match this instance to other data sources."
                    }
                ]
            },
            "IPv6Addresses": {
                "ReadRequirement": "Mandatory",
                "MinCount": 1,
                "ConditionalRequirements": [
                    {
                        "SubordinateToResource": [
                            "ComputerSystem",
                            "EthernetInterfaceCollection"
                        ],
                        "MinCount": 2
                    }
                ]
            }
        }
    }
}

8.4.3.5.3 Compare property

A typical need for a conditional requirement is a dependency on the value of another property within the resource. This type of dependency can be used when several different product variations share a common schema definition. In that case, Redfish schemas normally define a type-specifying property with enumerations, for a variety of product categories, that can be used to differentiate profile requirements by product category.

To accomplish this, there are three Profile properties related to this function:

8.4.3.5.4 Examples

Simple dependencies can be expressed using the conditional requirement and a comparison. This example shows a CompareProperty condition applied to the Pepperoni property. If the PizzaType property is not equal to Cheese, then the Pepperoni property becomes both mandatory and must have a value of true.

{
    "Pepperoni": {
        "ReadRequirement": "Recommended",
        "ConditionalRequirements": [
            {
                "Purpose": "Pepperoni is required on all pizza types except Cheese.",
                "CompareProperty": "PizzaType",
                "CompareType": "NotEqual",
                "CompareValues": [
                    "Cheese"
                ],
                "ReadRequirement": "Mandatory",
                "Comparison": "Equal",
                "Values": [
                    true
                ]
            }
        ]
    }
}

This example shows a CompareProperty condition applied to the IndicatorLED property, which has a base Recommended requirement, but becomes Mandatory if the SystemType property has a value of Physical or Composed.

{
    "IndicatorLED": {
        "ReadRequirement": "Recommended",
        "ConditionalRequirements": [
            {
                "Purpose": "Physical and composed systems must have a writable LED",
                "CompareProperty": "SystemType",
                "CompareType": "AnyOf",
                "CompareValues": [
                    "Physical",
                    "Composed"
                ],
                "ReadRequirement": "Mandatory",
                "WriteRequirement": "Mandatory"
            }
        ]
    }
}

This example shows a CompareProperty condition applied to the SerialNumber property, which has a Conditional requirement, becoming Mandatory only in cases where the /Location/PartLocation/LocationType property (specified as a JSON Pointer per RFC6901) has a value that is not Embedded.

{
    "SerialNumber": {
        "ReadRequirement": "Conditional",
        "ConditionalRequirements": [
            {
                "Purpose": "SerialNumber is required on Memory resources whose LocationType is not Embedded.",
                "CompareProperty": "/Location/PartLocation/LocationType",
                "CompareType": "NotEqual",
                "CompareValues": [
                    "Embedded"
                ],
                "ReadRequirement": "Mandatory"
            }
        ]
    }
}

8.4.3.6 Handling deprecated properties

As the Redfish data model evolves, there are many cases of properties being deprecated in favor of an improved property that replaces it. While it would be preferred for a profile to specify the new property, existing service implementations could not meet these requirements. Furthermore, it may take substantial time for broad adoption of the replacement property.

Rather than creating property-level requirements for both the original and the replacement property, the ReplacesProperty and ReplacedByProperty functions allow a profile to specify requirements where either the original or replacement property can fulfill those requirement, without requiring "legacy" support of deprecated properties.

For example, the widely-implemented IndicatorLED property, which suffered from interoperability issues due to the different LED states implemented by vendors, was replaced by the LocationIndicatorActive property throughout the Redfish data model. To encourage vendors to implement the replacement property, an entry for LocationIndicatorActive is added to the profile. But as existing implementations will only support the deprecated IndicatorLED, it is referenced using the ReplacesProperty function. That allows an implementation to meet the requirements by supporting either property, but not placing any requirement that it supports both the deprecated property and its replacement.

8.4.3.6.1 Examples

This example shows the LocationIndicatorActive property requirements, which can be met if the service implements the deprecated IndicatorLED property. But if the service implements the replacement property, it has no profile requirement to carry the deprecated, "legacy" property.

{
    "PropertyRequirements": {
        "LocationIndicatorActive": {
            "ReadRequirement": "Mandatory",
            "WriteRequirement": "Mandatory",
            "ReplacesProperty": "IndicatorLED"
        }
    }
}

This example follows the previous one but retains specific requirements on the deprecated IndicatorLED property. If the service implements only the deprecated IndicatorLED property, it will meet both of these property requirements, as long as it supports setting the IndicatorLED property to the Off, Lit, and Blinking values. If the service implements the LocationIndicatorActive property, the requirements on IndicatorLED are ignored.

{
    "PropertyRequirements": {
        "LocationIndicatorActive": {
            "ReadRequirement": "Mandatory",
            "WriteRequirement": "Mandatory",
            "ReplacesProperty": "IndicatorLED"
        },
        "IndicatorLED": {
            "ReadRequirement": "Mandatory",
            "WriteRequirement": "Mandatory",
            "ReplacedByProperty": "LocationIndicatorActive",
            "MinSupportValues": [
                "Off",
                "Lit",
                "Blinking"
            ]
        }
    }
}

8.4.4 Action requirements

Because several critical functions of a Redfish service are implemented as Actions, the profile may place requirements for support of these Actions. The requirements can specify which parameters must be supported, and may specify allowable values for those parameters.

The following functions are available to specify requirements for an action within a resource requirement:

The following values are allowed for the ActionInfo requirement:

8.4.4.1 Parameters

The following functions are available to specify requirements for a parameter on a particular action:

8.4.4.2 Example

This example shows the Reset action as required for this resource, along with the required parameter ResetType, which must support the values of ForceOff and PowerCycle.

{
    "ActionRequirements": {
        "Reset": {
            "ReadRequirement": "Mandatory",
            "Purpose": "Ability to reset the unit is a core requirement of most users.",
            "Parameters": {
                "ResetType": {
                    "ParameterValues": [
                        "ForceOff",
                        "PowerCycle",
                        "On"
                    ],
                    "RecommendedValues": [
                        "GracefulShutdown",
                        "GracefulRestart",
                        "ForceRestart",
                        "PushPowerButton"
                    ],
                    "ReadRequirement": "Mandatory"
                }
            }
        }
    }
}

8.5 Registry-level requirements

While not normally part of the JSON resources, the Redfish-defined message registries are important for interoperability, as they indicate what functionality has been implemented for events, and are also a useful method for setting expectations on the use of extended info error messages when interacting with a Redfish service.

The following functions are available to specify registry-level requirements:

8.5.1 Messages

Within the registry object are additional objects that are named to match the message name in the registry definition. This object then contains the message-level requirements.

The following options are available at the message-level:

8.5.2 Example

This example shows requirements for two message registries, including one OEM-defined registry. The Base registry is a DMTF standard registry. By default since no OwningEntity is listed, and therefore can be retrieved by default from DMTF's repository. The Base registry lists only four messages that are required.

In the case of the OEM-defined registry ContosoPizzaMessages, the Mandatory requirement set at the registry level specifies that all messages defined in that registry are required.

{
    "Registries": {
        "Base": {
            "MinVersion": "1.18.0",
            "Messages": {
                "Success": {},
                "GeneralError": {},
                "Created": {},
                "PropertyDuplicate": {}
            }
        },
        "ContosoPizzaMessages": {
            "OwningEntity": "Other",
            "OwningEntityName": "Contoso",
            "Repository": "http://contoso.com/registries",
            "ReadRequirement": "Mandatory"
        }
    }
}

8.5.3 Supported features

Within the registry object are additional objects that are named to match the SupportedFeatures name in the registry definition. This object then contains the features-level requirements.

The following options are available at the feature-level:

8.5.4 Example

This example shows requirements for a feature registry. The SwordfishFeatures registry is a DMTF-partner defined standard registry, specified as such where the OwningEntity is SNIA. SNIA re-publishes their registries through DMTF and therefore this registry can be retrieved from DMTF's repository. In this example, the SwordfishFeatures registry lists two features that are supported by the service.

{
    "Registries": {
        "SwordfishFeatures": {
            "MinVersion": "1.0.2",
            "SupportedFeatures": {
                "SNIA.Swordfish.Discovery": {},
                "SNIA.Swordfish.EventNotification": {}
            }
        }
    }
}

9 ANNEX A (informative) Change log