Subject: [scim] Clarification on DELETE handling of unique attributes

From: Phil Hunt <[email-masked]>
Date: Wed, 11 Jun 2014 11:00:49 -0700

In the current draft, DELETE indicates that when a resource is actually deleted, attributes like userName must not be considered in conflict calculations.  I am thinking that this requirement is not necessary for inter-operability. As well, there may be valid reasons why an attribute value might be held for a period of time after a resource is deleted that might have much more than simple resource resurrection.  For example, many telcos often hold telephone numbers for a period of time before re-use.  I agree however that once deleted, a search based on that attribute value should not return a match since the resource is deleted.

I would like to propose we remove the last two sentences:
   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.

Original text from section 3.4 on HTTP DELETE: 

   Clients 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.

Phil

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