Cancelling this meeting (so that it does not count towards attendance).
Had an informal chat with Karsten before ending the call early.
Karsten asked about our direction with respect to SCIM:
- Gary acknowledged the traction that SCIM is getting.
- Gary hopes to get more clarity on direction with respect to SCIM: is convergence possible?
- The current scope of SCIM addresses few of the traditional use-cases for SPML, e.g.,:
-- No accounts; no relationships to other objects; only User itself.
-- No synchronization (i.e., Updates operation).
- Gary wonders whether participants in SCIM have any interest in addressing such use-cases.
Karsten mentioned several problems/inconsistencies that he encountered in implementing the current SPML specification:
1) Modify operation: Core spec says modificationType is required but DSML spec says to use DSML mod-type.
-- (Gary believes that the errata resolve this by relaxing the Core spec so that DSML spec's override is legal.)
2) Updates operation: search filters don't work well with hard-deletes or with transient attribute-values.
-- can't match an object that has been physically deleted, since you don't know what its attributes were.
-- a search for updates on active authenticators will not match updates for Users who are no longer active authenticators.
-- One would have to keep a complete image of the object to search in combination with the change-log.
-- The SPML spec should acknowledge this difficulty in implementing support for search-criteria with the Updates operation.
-- Karsten found it easier simply to avoid using search-filters with the Updates operation.
3) Updates operation: timestamp may not be sufficiently granular:
-- When updates occur rapidly, the timestamp-value may not be unique. Two updates may have the same timestamp.
-- A client who re-reads from the timestamp of the last update he processed may miss an update.
-- SPML spec for Updates operation should allow an implementation to use a sequence-number (instead or in addition).
|