Alternative Proposals on the Relationship Between TIER and SCIM APIs and Schema

Proposal 1) TIER APIs and Schema have some overlap with SCIM APIs and Schema. The development of TIER-defined API and Schema is not bound by SCIM specifications

Pros: 

1. Maximum freedom in defining TIER-specific APIs and schema
2. SCIM compliance for simple API calls can be achieved by proper configuration of the parties.
3. Minimal development effort is required to provide simple SCIM responses. Simple SCIM responses will be enough to meet the majority of real-world SCIM use cases.

Cons:

1. Less SCIM compliance overall than other proposals on the table
2. Ongoing challenge to explain to developers and others where and how TIER diverges from SCIM

Proposal 2) 

SCIM APIs are a strict subset of TIER APIs. Rather than relying solely on SCIM User and Group Resource Types, TIER defines and uses new Resource Types: TierGroup and TierUser using SCIM-defined procedures. 

Pros:

1. Full SCIM compliance: Can be accomplished in conformance with SCIM RFCs using SCIM-defined procedures for defining new Resource Types and their core schema.
2. Freedom to define our own resource types and schema without having to prefix each attribute name with 'tier'
3. Avoids use of the choppy SCIM schema extension mechanism for Users and Groups (SCIM mandates all core attributes together followed by sections of SCIM extensions and TIER extensions).

Cons:

1. TIER User and Group Resource Types would have "Tier" in their names while other resource type names would not (or would they?)
2. To support SCIM User and Group objects, TIER would need to provide bi-directional, automated mapping between the TierUser and TierGroup schema and the corresponding SCIM schema. (Does that mean we still do prefixing for these objects)
3. Can we fix issues with SCIM e.g. that we want to offer a better way to page through large resultsets?
4. Does this mean we cant add things to the Meta object?  We are back to having a Meta and a TierMeta for Tier resource types?