Subject: [scim] Clarification on body request for DELETE

From: Alexandre Santos <[email-masked]>
Date: Wed, 27 Mar 2013 09:03:49 -0700

The spec for PUT says "3.3.1...  Unless otherwise specified a successful
PUT operation returns a 200 OK response code and the entire Resource within
the response body"
For POST: "3.1...  the response body MUST contain the newly created
Resource."
For DELETES it says " 3.4.  Deleting Resources

Consumers request Resource removal via DELETE. Service Providers MAY choose
not to permanently delete the Resource, but MUST return a 404 error code
for all operations associated with the previously deleted Id. Service
Providers MUST also omit the Resource from future query results. In
addition the Service Provider MUST not consider the deleted resource in
conflict calculation. For example if a User resource is deleted, a CREATE
request for a User resource with the same userName as the previously
deleted resource should not fail with a 409 error due to userName conflict.
"

My question is, what (if anything at all) should be returned in the
response body as a result of a successful DELETE operation.

Thanks,
Alex Santos
*
*

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 27 Mar 2013 18:10:28 +0000

The SCIM API spec is not entirely clear here.  According to RFC 2616, the DELETE operation should work like this:

   A successful response SHOULD be 200 (OK) if the response includes an
   entity describing the status, 202 (Accepted) if the action has not
   yet been enacted, or 204 (No Content) if the action has been enacted
   but the response does not include an entity.

I can't think of anything interesting for SCIM to return in a response body, so my vote would either be a 200 with an empty response (or just a message) or a 204 with no response body.  Perhaps we should open an issue to clarify this.  Thoughts?

--Kelly

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandre Santos
Sent: Wednesday, March 27, 2013 11:04 AM
To: [email-masked]
Subject: [scim] Clarification on body request for DELETE

The spec for PUT says "3.3.1...  Unless otherwise specified a successful PUT operation returns a 200 OK response code and the entire Resource within the response body"
For POST: "3.1...  the response body MUST contain the newly created Resource."
For DELETES it says "
3.4.  Deleting Resources

Consumers request Resource removal via DELETE. Service Providers MAY choose not to permanently delete the Resource, but MUST return a 404 error code for all operations associated with the previously deleted Id. Service Providers MUST also omit the Resource from future query results. In addition the Service Provider MUST not consider the deleted resource in conflict calculation. For example if a User resource is deleted, a CREATE request for a User resource with the same userName as the previously deleted resource should not fail with a 409 error due to userName conflict.
"

My question is, what (if anything at all) should be returned in the response body as a result of a successful DELETE operation.

Thanks,
Alex Santos

---

From: Phil Hunt <[email-masked]>
Date: Wed, 27 Mar 2013 14:48:51 -0700

We've been discussing that 202 should generally be interpreted as, transaction is syntactically valid but pending completion (e.g. an approval workflow). It seems there is a need to do this with all SCIM operations.

Successful immediate completion would be status 200 or potentially 204.  Is there any reason for a SP to indicate for example that an entity wasn't actually deleted, but rather suspended (e.g. because the SP has a tombstone feature to preserve UUIDs)?

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-03-27, at 11:10 AM, Kelly Grizzle wrote:

> I can’t think of anything interesting for SCIM to return in a response body, so my vote would either be a 200 with an empty response (or just a message) or a 204 with no response body.  Perhaps we should open an issue to clarify this.  Thoughts?
>  
> --Kelly
>  
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Phil Hunt <[email-masked]>
Date: Wed, 27 Mar 2013 16:50:31 -0700

Sorry, by "we" I meant I was discussing with my colleagues at Oracle. I don't want to imply that other members of the WG are in agreement or disagreement. I simply want to concur Oracle identified as an issue needing more discussion.  :-)

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 28 Mar 2013 12:59:54 +0000

Phil ... I think the two thoughts you bring up are valid.  The 202 status code should probably be addressed as a part of issue #32, and the suspension vs. deletion could be addressed in issue #15.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, March 27, 2013 6:51 PM
To: Kelly Grizzle
Cc: [email-masked]; Alexandre Santos
Subject: Re: [scim] Clarification on body request for DELETE

Phil

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

Phil

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

--Kelly

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Alexandre Santos
Sent: Wednesday, March 27, 2013 11:04 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [scim] Clarification on body request for DELETE

Thanks,
Alex Santos

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

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