PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.
The issues coordinators will notify the list when that has occurred.
Title: Add conformance statements to new versions of Trust/SC/SP
Protocol: ws-sp
Artifact: Examples
Description:
The OASIS process requires all specs to now have a
conformance section. Using the RX TC specs as a guideline I suggest the following.
Proposal:
WS-SecurityPolicy
Add new section 1.7 Conformance as follows:
An implementation conforms to this specification if it satisfies all of the
MUST or REQUIRED level requirements defined within this specification. A SOAP
Node MUST NOT use the XML namespace identifier for this specification (listed
in Section 1.2) within SOAP Envelopes unless it is compliant with this
specification.
This specification references a number of other specifications (see the table above).
In order to comply with this specification, an implementation MUST implement
the portions of referenced specifications necessary to comply with the required
provisions of this specification. Additionally, the implementation of the
portions of the referenced specifications that are specifically cited in this
specification MUST comply with the rules for those portions as established in
the referenced specification.
Additionally normative text within this specification takes precedence over
normative outlines (as described in section 1.4.1), which in turn take
precedence over the XML Schema [XML Schema Part 1, Part 2] and WSDL [WSDL 1.1]
descriptions. That is, the normative text in this specification further
constrains the schemas and/or WSDL that are part of this specification; and
this specification contains further constraints on the elements defined in
referenced schemas.
This specification defines a
number of extensions; compliant services are NOT REQUIRED to implement
everything defined in this specification. However, if a service
implements an aspect of the specification, it MUST comply with the requirements
specified (e.g. related "MUST" statements). If an OPTIONAL message is
not supported, then the implementation SHOULD Fault just as it would for any
other unrecognized/unsupported message. If an OPTIONAL message is supported,
then the implementation MUST satisfy all of the MUST and REQUIRED sections of
the message.
WS-Trust
Move lines 21 – 23 to new conformance section as below.
Add new section 1.8 Conformance as follows:
An implementation conforms to this specification if it satisfies all of the
MUST or REQUIRED level requirements defined within this specification. A SOAP
Node MUST NOT use the XML namespace identifier for this specification (listed
in Section 1.3) within SOAP Envelopes unless it is compliant with this
specification.
This specification references a number of other specifications (see the table
above). In order to comply with this specification, an implementation MUST
implement the portions of referenced specifications necessary to comply with
the required provisions of this specification. Additionally, the implementation
of the portions of the referenced specifications that are specifically cited in
this specification MUST comply with the rules for those portions as established
in the referenced specification.
Additionally normative text within this specification takes precedence over
normative outlines (as described in section 1.5.1), which in turn take
precedence over the XML Schema [XML Schema Part 1, Part 2] and WSDL [WSDL 1.1]
descriptions. That is, the normative text in this specification further
constrains the schemas and/or WSDL that are part of this specification; and
this specification contains further constraints on the elements defined in
referenced schemas.
This specification defines a number of extensions; compliant services are
NOT REQUIRED to implement everything defined in this specification. However, if
a service implements an aspect of the specification, it MUST comply with the
requirements specified (e.g. related "MUST" statements). [Preceding
italic text is lines 21 -23] If an OPTIONAL message is not supported, then
the implementation SHOULD Fault just as it would for any other
unrecognized/unsupported message. If an OPTIONAL message is supported, then the
implementation MUST satisfy all of the MUST and REQUIRED sections of the
message.
WS-SecureConversation
Move lines 17 – 19 to new conformance section as below.
Add new section 1.8 Conformance as follows:
An implementation conforms to this specification if it satisfies all of the
MUST or REQUIRED level requirements defined within this specification. A SOAP
Node MUST NOT use the XML namespace identifier for this specification (listed
in Section 1.3) within SOAP Envelopes unless it is compliant with this specification.
This specification references a number of other specifications (see the table
above). In order to comply with this specification, an implementation MUST
implement the portions of referenced specifications necessary to comply with
the required provisions of this specification. Additionally, the implementation
of the portions of the referenced specifications that are specifically cited in
this specification MUST comply with the rules for those portions as established
in the referenced specification.
Additionally normative text within this specification takes precedence over
normative outlines (as described in section 1.5.1), which in turn take
precedence over the XML Schema [XML Schema Part 1, Part 2] and WSDL [WSDL 1.1]
descriptions. That is, the normative text in this specification further
constrains the schemas and/or WSDL that are part of this specification; and
this specification contains further constraints on the elements defined in
referenced schemas.
Compliant services are NOT REQUIRED to implement everything defined in this
specification. However, if a service implements an aspect of the specification,
it MUST comply with the requirements specified (e.g. related "MUST"
statements). [Preceding italic text is lines 17 -19] If an OPTIONAL message
is not supported, then the implementation SHOULD Fault just as it would for any
other unrecognized/unsupported message. If an OPTIONAL message is supported,
then the implementation MUST satisfy all of the MUST and REQUIRED sections of
the message.