# SCIM IG Meeting Notes: 4 August, 2021 # Attendees # Agenda * BoF Review * Notes * Padlet * Charter next steps * Review feedback, alter if needed # Notes ## Assets from the BoF Meeting * [https://codimd.ietf.org/notes-ietf-111-sins](https://codimd.ietf.org/notes-ietf-111-sins) * Attendance: 64 people (give or take) ## Review of BoF - from Nancy Cam Winget (BoF Chair) * Personal read * went reasonably well, no strong opposition or challenge * Challenges were on scope of charter * Recommendation: next step is tightening the charter * Need to look at new cutoff dates- if we can get consensus through the mailing list, we can look to be official for Madrid * Mail list chatter is key * IESG frowns on long continuation of a BoF * But based on Roman's feedback, we should be ok * If we can get confirmation through the mailing list, that will help * IETF prefers 2-week notice for meetings to occur * Ok to send cadence, then send reminder ## Review of Feedback (via Padlet, chat, ) * How did Padlet work? * Worked well * but perhaps a bit more context around the fact that people could vote might have been helpful * Reasonable assumption that SCIM is working - lots of representation ## Primary BoF Feedback ### Schema Approach * Comment was that over-indexing on common schema is a problem. In the padlet a suggestion for "discoverable schema" - people could start with base schema but add additional mappings * Question from Paul: does that confuse among common schema? Can we predict interoperability? Consensus call (7/11 within the call) for "investigating discoverable schema as part of our schema milestone" deliverable would be a document containing recommendations delivered to the WG * pagination and synchronization * Interest in understanding use cases - Use cases, understand why clients are asking for large result sets * Is this related to the synchronization problem? * For synchronization - clients want to preserve a state and act on it, * 1) with authorization * Eg users might want to understand the account state before the user ever logs in. When it comes to enforcing authorization, the clients don't want to have to make real-time calls, so they work to get an initial load of users & groups into the application * I've got a big load of users/groups coming down * 2) for detecting deletes * how do I know when to delete * From Danny: * In case of loading up new applications, you are downloading a lot of data * Then for new employees, terminated employees etc, that is the ongoing sync and would happen prior to login * Matt: can we come up with a mechanism that indicates that a change has occurred, but doesn't carry data? * This may not eliminate the need for pagination but it could reduce. * Wes: advanced filtering may also reduce the amount of data returned, and therefore reduce large data set * Matt: we need to investigate whether pagination could be eliminated altogther, if pagination does need to be kept, can we then look at how backends can reliably support pagination more flexibly Conclusion: This widens out the pagination milestone into a core study on how implementers use paginated requests for sync purposes * Parul: is this conflating pagination and sync? There are many patterns for sync * Pam: maybe we need to sequence this instead of combining? * Matt: yes we could define the pagination needs once we understand sync use cases * Wes: we do need to support both universes, one where we sync and one where we filter (this is a both not an either or) * Parul: we do need cursor-based pagination, and that is unlikely to go away but it doesn't harm to first define the synchronization world and then look at whether pagination needs to be enhanced or whether there is smaller work * Janelle: do we need to explore notifications? * Danny strong supports this * Paul: suspect that notification mechanisms become the solution to how we address synchronization and large data set handling * Matt: feels like there is lots of interest here * Paul: seems like pagination and filtering is not going to go away but is part of this inter-related sync/paging/filtering large data set topic. * Useful to know the sync use cases so that everyone refers to the same scenarios * Paul: do we make the headline for the milestone into "Large Data Set Handling"? * Janelle: is batch operation/bulk operation processing also apply to this pagination/synchronization question? * Are there size limitations in the current BATCH recommendations in the spec? * Can we even do pagination on Consensus call (9/11 within the call): We will explore synchronization patterns and deliver a document describing what implementers are doing, with one focus being how large data sets are involved as an early deliverable # Action Items - results of consensus calls - discuss homework: on sync/pagination implementations of BATCH and BULK input to SCIM servers - should the BATCH/BULK input operations also be part of the synchronization (and possibly the pagination) discussion?