Re: [scim] Ticket 13, required flag for etags

[Phil Hunt <[e-mail]>]

I missed that. I agree, MUST should be MAY.

In many cases, such as adding a user to a large group via PATCH, the fact that the underlying resource MAY have changed a 1000 times will have no impact — unless multiple clients start trying to add the same user.

I also think there is a consideration that ETags could cause accidental performance problems.  E.g. a client keeps trying to do read-before-write (to get the version) and fails continually because of a high rate of change of the target resource. In many of these cases, an approach of discrete PATCH operations may solve the problem at scale.

I’m going to review what http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-26 spec is saying on this and see how we should apply to SCIM.

Phil

@independentid
www.independentid.com
[e-mail]



On May 1, 2014, at 3:23 PM, Erik Wahlström <[e-mail]> wrote:

> But the following texts makes it all rather unclear.
> 
> If the Service Providers supports versioning of resources the
>    Consumer MUST supply an If-Match [15] header for PUT and PATCH
>    operations to ensure that the requested operation succeeds only if
>    the supplied ETag matches the latest Service Provider Resource; e.g.,
>    If-Match: W/"e180ee84f0671b1"
> 
> 
> How about changing MUST to MAY?
> 
> / Erik
> 
> 
> 
> 
> 
> 
> On 01 May 2014, at 22:37, Kelly Grizzle <[e-mail]> wrote:
> 
>> Good info.  And I believe that the spec already suggests that these should be optional for the client (section 3.11 of the API):
>>  
>>    With the returned ETag, clients MAY choose to retrieve the resource
>>    only if the resource has been modified.
>>  
>> Given the “MAY” in this statement, I think we should close this ticket as WONTFIX.
>>  
>>  
>> From: Phil Hunt [mailto:[e-mail]] 
>> Sent: Thursday, May 01, 2014 2:47 PM
>> To: Kelly Grizzle
>> Cc: [e-mail] WG
>> Subject: Re: [scim] Ticket 13, required flag for etags
>>  
>> My understanding of etags is that they are always optional.  From an interop perspective a server can’t require them.
>>  
>> Phil
>>  
>> @independentid
>> www.independentid.com
>> [e-mail]
>>  
>>  
>>  
>> On May 1, 2014, at 12:45 PM, Kelly Grizzle <[e-mail]> wrote:
>> 
>> 
>> IIRC this came up at a SCIM interop event.  The SCIM Proxy server supported ETags and failed if they were not supplied by the client.  However, it seemed like the correct behavior was to accept client requests with or without an ETag.  My understanding of the “supported” attribute was that the server accepted ETags but they were not mandatory for the client to send.
>>  
>>  
>> From: scim [mailto:[e-mail]] On Behalf Of Phil Hunt
>> Sent: Thursday, May 01, 2014 2:42 PM
>> To: [e-mail] WG
>> Subject: [scim] Ticket 13, required flag for etags
>>  
>> Does anybody have any explanation of this ticket?  
>> http://trac.tools.ietf.org/wg/scim/trac/ticket/13
>>  
>> This is one of the old tickets from SCIM 1.  The explanation here https://code.google.com/p/scim/issues/detail?id=92 didn’t provide any more detail.
>>  
>> I’m wondering if what is meant is whether the server configuration should indicate whether etags are “supported” rather than “required”.
>>  
>> Section 12.5 of core-schema already indicates that the service provider config includes an attribute etags whose sub attribute “supported’ indicated that the server supports etags.
>>  
>> Was there something else?
>>  
>> Or, is this just a ticket that should have been closed a long time ago?
>>  
>> Phil
>>  
>> @independentid
>> www.independentid.com
>> [e-mail]
>>  
>>  
>>  
>> _______________________________________________
>> scim mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/scim
>>  
>> _______________________________________________
>> scim mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/scim
> 
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim