Thanks to Sal for volunteering to take notes. Attendees: Morteza Ansari, Phil Hunt, Kelly Grizzle, Bjorn Aannestad, Barry Leiba, Leif Johansson, Sal D'Agostino, Peter Gietz Assign responsible persons for issues based on issue tracker: #2 Kelly to provide text #9 Postponed #10 Phil to create separate item related to the thread on list #13 Eric to provide update on etags #24 Bjorn to provide language Morteza related to last IETF there are issued related to filter semantic for plural queries of complex attribute, "resource object not the value" #34 Hold for Kelly response #35 Hold for Kelly, comments on thread Text is incorrect, comments are valid, remove sentence vs. fixing piece, look at group member addressed in updated schema, added to ticket, Bjorn to take ticket #37 Extended discussion, OK to return http error How does a remote client find this out (other examples) akin to index errors or bad filters, discovery upfront is different than detailed error message. Return "Error" only, vulnerabilities on the public internet a consideration If there is a desire for human understandable errors refer to security considerations and do what is appropriate. How does client figure it out, cannot guarantee interoperability if limited to rest error or http error codes All the protocol needs is unwilling to perform List query restriction Discovery holds no security risk LDAP versus X500 gives examples of good versus bad ways to do this, http restful codes sufficient, Concern comes from the need to have some clues, "Equal" # publisher and clients, need to be much more concerned given peer to peer nature of scim Discovery vs. detailed error message, later is a security consideration Attribute at server level vs. details are aspect of attribute. Remove searching entirely from the spec, make a provisioning only, otherwise it is a cloud directory, scim 1 with filters requires that Working group should look at issue of cloud directory and search extension Two issues: Error code More with discovery some related to error and some related to other things and what are the things that have a big impact on use case, complete set is slippery slope, start with making sure what is already in the spec #47 discovery of attribute indexing Being specific about discovery for clients, manageable if not about error messages Phil to look at 37 and 47 Phil to propose text Bad request mentioned on the list, LDAP laissez faire, sit on top of multiple datasets if one dataset throws an error, how do you handle it, it can be an ok result, admins can (want to) determine why, x500 to throw errors at first sign May still want to define bad request even to know what it isn't Don't use or seldom used codes, don't expect fully parsed error Filter needs to conform to scim syntax, filter comparison is valid due to server configuration, clients build in a lot of OR blocks for deployments, and this is breaking for some Show some error codes in context. Consider things like 501 and semantics Combine into a general error code ticket and merge into 47, defer to new issue, general error review, general review, or appendix with scim error codes table Meeting recording link: https://go.webex.com/go/lsr.php?AT=pb&SP=MC&rID=6141242&rKey=6ee5ab19 b38d45c3 SCIM WG bi-weekly call-20130918 1808-1 Wednesday, September 18, 2013 11:08 am San Francisco Time 52 Minutes