Comments on Conformance Language

["Considine, Toby" <Toby.Considine@unc.edu>]

Two weeks ago, there were questions about writing conformance.

 

I promised some of my favorite examples, but was not in the SCs properly. Now I am.

 

None of these are exactly correct, but I hope they will be useful to the editor in crafting this spec. Note the bias toward incorporation rather than re-statements…

 

I also note that normative uses of MAY and SHALL etc, should be capitalized to distinguish them from loose talk.

 

 

 

 

1.1 Version Conformance

 

Implementations that use the Schema Version attribute, and that claim full conformance to this specification, MAY use the use the value “1.0.2011.11” for that attribute.

 

 

 

 

 

15.1.6.3 Full Conformance or Conformance with Alternate Interoperation to a Named Profile

 

An implementation claiming Conformance with Alternate Interoperation or Full Conformance with Alternate Interoperation to a Named Profile of Energy Interoperation MUST be able to claim the respective Full Conformance with Alternate Interoperation or Conformance with Alternate Interoperation to Energy Interoperation excepting only the following:

 

•            Services and Operations in sections not included in the Named Profile

 

In addition, interoperation payloads MUST be used as defined or extended; in the event that payloads are extended a description of the extension(s) SHALL be included in the Implementation’s conformance statement.

 

 

 

 

 

It is RECOMMENDED that Web services interoperation be achieved using the WSI Basic Profile [WSI-Basic]

 

 

 

 

 

In order to be conformant, an implementation MUST be able to interoperate with any implementation that satisfies all MUST and REQUIRED level requirements.  Where the implementation has implemented optional behaviors, the implementation MUST be able to fall back to mandated behaviors if the implementation it is interacting with has not implemented those same behaviors.  Where the other implementation has implemented optional behaviors not implemented by this implementation, the conformant implementation MUST be able to provide the mandated level behaviors that allow the other implementation to fall back to using only mandated behaviors.

 

 

 

 

 

A conformant OBIX Client implementation SHOULD support one of the encodings defined in this specification.  An implementation MUST support negotiation of which encoding to use in communicating with an OBIX Server using the mechanism defined for the binding being used.

 

 

 

 

 

An implementation MUST support negotiation of the encoding to be used with a Client according to the mechanism defined for the specific binding used. A conforming binding specification MUST specify how negotiation of the encoding to be used is performed.  A conforming implementation MUST conform to the negotiation rules defined in the specification for each binding that it uses.

 

An implementation MUST return values according to the type representations defined in Section 4.2.

 

 

 

 

 

It is expected that an OBIX Server will perform authentication and utilize those user credentials for checking permissions before processing read, write, and invoke requests. As a general rule, Servers SHOULD return err with the obix:PermissionErr Contract to indicate a Client lacks the permission to perform a request. In particularly sensitive applications, a Server may instead choose to return BadUriErr so that an untrustworthy Client is unaware that a specific object even exists.

 

 

 

 

 

OBIX does not define security protocols or security methods. Security is dependent upon the business process, the value of the data, the encoding used, and other issues that are out of scope for this specification. OBIX supports composition with any number of security approaches and technologies. User authentication and authorization are left to the implementer. The type and depth of encryption are dependent upon the bindings and transport protocols used. Although it is possible to define contracts for user management through OBIX, this committee does not define any standard Contracts for user management.

 

OBIX does define the messages used to report errors in security or in authentication. OBIX further defines how security is inherited within the hierarchy of a system. OBIX further makes a number of statements throughout this specification of areas or conditions wherein practitioners should consider carefully the security effects of their decisions.