NEW Issue: Unrecognized Attributes and Extensibility

[William Cox <wtcox@CoxSoftwareArchitects.com>]

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSION THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.

The issues coordinators will notify the list when that has occurred.

Protocol: bqos rating sla

Artifact: spec

Type: design

Title: Unrecognized Attributes and Extensibility

Description:

This issue applies to

BusinessQualityOfService-v1.0-spec-wd04.pdf
BusinessRating-v1.0-spec-wd05.pdf
BusinessServiceLevelAgreement-v1.0-spec-wd04.pdf

Examples are from BQOS. See lines 130, 137, 143, 146, 149, 190, 284, 342, 352, 355, 447. This addresses overall issues for management and extensibility using the any mechanism.

(1) The attributes are also called parameters; is this correct?

(2) The SHOULD behavior will allow an implementation to silently ignore unrecognized attributes. If this is the intended behavior, MAY might be the right keyword, but it's not at all clear that a fault should be generated for unrecognized attributes. Interoperable applications could instead ignore unrecognized attributes, or maintain "understood attribute profiles."

(3) Similar management issues have registered or otherwise predefined specific characteristics or attributes; some of these are defined, but the interoperability and attribute managements are not addressed in the specifications.


Related issues:

Proposed Resolution:

(a) Make terminology consistent; if the inconsistency is correct, state reason in normative text.

(b) Address interoperability concerns for multiple implementations, particularly ones that do not recognize the same sets of attributes. Explain in normative or non-normative text why the specified behavior is necessary or desirable for interoperation.

(c) Justify choices made in Appendix B or other non-normative text.


bill cox
--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax