Page History

...

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. 
   1. Q: Does that mean we still do prefixing for these objects?
   2. A: No, I'd say when converting objects to SCIM, we'd ditch all the TIER ResourceType attributes that don't have a direct counterpart in SCIM. That way SCIM endpoints would see pure SCIM.
   3. Q: Can we fix issues with SCIM e.g. that we want to offer a better way to page through large resultsets?
   4. A: Since we declare TIER a superset of SCIM, we could define points on which TIER APIs diverge from SCIM APIs, but I think we should set a pretty high bar for deciding it's necessary to do that. If there's something wrong with SCIM, we should first really try to get it fixed in the next release of SCIM.  In general, better lines of communication with the SCIM community is a good thing.
   5. Q: 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?
   6. A: If we just make sure all the SCIM meta attributes are included have a direct counterpart in the meta element we define for each TIER Resource Type, then nowe just need one meta object. Mapping from a TIER Resource Type to a SCIM Resource Type is then a straight mapping of corresponding attributes, plus filtering out all the TIER-specific meta elements.
3. This solves the problem of TIER wanted to pepper the object model with new attributes, but what about when institutions want to add new attributes, they will have to either define institution specific resource types which is a lot of work or follow the scim extension model which is clunky