Subject: Re: [scim] PATCH Response Status

From: Shelley <[email-masked]>
Date: Tue, 2 Aug 2016 15:48:15 -0500

>  The client can force the full response by including the attributes
> parameter

In order to get the full resource representation in the response, this
would require consumers to explicitly list every single attribute in the
"attributes" parameter. This may still be acceptable, but is certainly not
very usable for consumers wishing to get the full response (issuing a
subsequent GET would perhaps even be a better option).

Note: of course a service provider might still refuse under its own access
> rules.

Can you please clarify this point? The spec seems to indicate that SPs MUST
return a 200 when a PATCH is requested with the "attributes" parameter
specified.

On Mon, Jul 18, 2016 at 12:23 PM, Phil Hunt <[email-masked]> wrote:

> Because of the issue you mention I would expect a lot are returning code
> 204.  The client can force the full response by including the attributes
> parameter. Note: of course a service provider might still refuse under its
> own access rules.
>
> Just as servers are required to be robust, we can expect that clients
> should expect some variation from the servers on the response code and the
> content of the response (the server isn’t obliged to accept data as stated
> 100%).
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
>
>
> On Jul 18, 2016, at 8:45 AM, Shelley <[email-masked]> wrote:
>
> The SCIM specification indicates that a server may return *either *a 200
> or 204 for successful PATCH requests, but *must *return 200 for PATCH
> requests with the "attributes" parameter [1,2].
>
> Our team's SCIM service provider implementation is currently deciding
> which status code is the most appropriate to return. A 200 would provide
> the most complete representation available and would provide consistency
> regardless of the absence/presence of the "attributes" parameter. However,
> one of the most significant benefits of PATCH is the performance
> improvements. For example, PATCH can prevent consumers from dealing with
> extremely large group resources (in many cases, groups have thousands or
> even tens-of-thousands of members); and likewise, the resources required on
> the server to process and/or return such large requests is significant. A
> 204 response could therefore have significant performance benefits.
>
> What do other SCIM service providers return for successful PATCH requests?
> Also, do SCIM consumers/clients properly handle the possibility for either
> a 200 or 204 to be returned per the spec?
>
> [1]
> http://www.simplecloud.info/specs/draft-scim-api-01.html#edit-resource-with-patch
> [2] https://tools.ietf.org/html/rfc7644#section-3.5.2
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 2 Aug 2016 14:03:35 -0700

Yes. That is my interpretation as well. I agree, it is not an ideal situation. It does same bandwidth and the results are given if the client really really wants it.

The problem with larger groups is that the bigger the get, we not only have performance problems but we also have privacy and disclosure problems.  I think this will mean an eventual move towards entitlement/role based access as user populations or group sizes grow.  I think also the mapping back and forth between user entry and groups is also going to prove challenging.

I think it is something we need to discuss.  
 
Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Aug 2, 2016, at 1:48 PM, Shelley <[email-masked]> wrote:
> 
>  The client can force the full response by including the attributes parameter
> 
> In order to get the full resource representation in the response, this would require consumers to explicitly list every single attribute in the "attributes" parameter. This may still be acceptable, but is certainly not very usable for consumers wishing to get the full response (issuing a subsequent GET would perhaps even be a better option).
> 
> Note: of course a service provider might still refuse under its own access rules.
> 
> Can you please clarify this point? The spec seems to indicate that SPs MUST return a 200 when a PATCH is requested with the "attributes" parameter specified.
> 
> 
> On Mon, Jul 18, 2016 at 12:23 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> Because of the issue you mention I would expect a lot are returning code 204.  The client can force the full response by including the attributes parameter. Note: of course a service provider might still refuse under its own access rules.
> 
> Just as servers are required to be robust, we can expect that clients should expect some variation from the servers on the response code and the content of the response (the server isn’t obliged to accept data as stated 100%).
> 
> Phil
> 
> @independentid
> www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> 
> 
> 
> 
> 
>> On Jul 18, 2016, at 8:45 AM, Shelley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> The SCIM specification indicates that a server may return either a 200 or 204 for successful PATCH requests, but must return 200 for PATCH requests with the "attributes" parameter [1,2].
>> 
>> Our team's SCIM service provider implementation is currently deciding which status code is the most appropriate to return. A 200 would provide the most complete representation available and would provide consistency regardless of the absence/presence of the "attributes" parameter. However, one of the most significant benefits of PATCH is the performance improvements. For example, PATCH can prevent consumers from dealing with extremely large group resources (in many cases, groups have thousands or even tens-of-thousands of members); and likewise, the resources required on the server to process and/or return such large requests is significant. A 204 response could therefore have significant performance benefits.
>> 
>> What do other SCIM service providers return for successful PATCH requests? Also, do SCIM consumers/clients properly handle the possibility for either a 200 or 204 to be returned per the spec?
>> 
>> [1] http://www.simplecloud.info/specs/draft-scim-api-01.html#edit-resource-with-patch <http://www.simplecloud.info/specs/draft-scim-api-01.html#edit-resource-with-patch>
>> [2] https://tools.ietf.org/html/rfc7644#section-3.5.2 <https://tools.ietf.org/html/rfc7644#section-3.5.2>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>
> 
>