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

From: Phil Hunt <[email-masked]>
Date: Thu, 1 May 2014 12:42:07 -0700

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
[email-masked]

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 1 May 2014 19:45:17 +0000

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:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, May 01, 2014 2:42 PM
To: [email-masked] WG
Subject: [scim] Ticket 13, required flag for etags

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.

Phil

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

---

From: Phil Hunt <[email-masked]>
Date: Thu, 1 May 2014 12:46:45 -0700

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
[email-masked]

On May 1, 2014, at 12:45 PM, Kelly Grizzle <[email-masked]> 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.
>  
>  
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 1 May 2014 20:37:38 +0000

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:[email-masked]]
Sent: Thursday, May 01, 2014 2:47 PM
To: Kelly Grizzle
Cc: [email-masked] 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

On May 1, 2014, at 12:45 PM, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, May 01, 2014 2:42 PM
To: [email-masked]<mailto:[email-masked]> WG
Subject: [scim] Ticket 13, required flag for etags

Phil

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

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: Erik Wahlström <[email-masked]>
Date: Thu, 1 May 2014 22:23:02 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Given the “MAY” in this statement, I think we should close this ticket as WONTFIX.

From: Phil Hunt [mailto:[email-masked]]
Sent: Thursday, May 01, 2014 2:47 PM
To: Kelly Grizzle
Cc: [email-masked]<mailto:[email-masked]> WG
Subject: Re: [scim] Ticket 13, required flag for etags

Phil

@independentid

Phil

@independentid

---

From: Phil Hunt <[email-masked]>
Date: Thu, 1 May 2014 15:39:13 -0700

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
[email-masked]

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

> On 01 May 2014, at 22:37, Kelly Grizzle <[email-masked]> wrote:
>