Subject: [scim] Proposed PATCH Change: 1 of 2

From: Phil Hunt <[email-masked]>
Date: Fri, 8 Aug 2014 09:44:20 -0700

After some feedback at IETF90 and on this list, I would like to propose to optimization changes to PATCH that should make it more consistent and less verbose.

Please indicate your -1 if you have any objections or questions.  If no objections, I will include this in the next update late Monday afternoon.

Proposal 1:  Move schemas attribute to outer message element.

Currently, the PATCH body consists of an array of objects, each with a single operation and its own “schemas” attribute. Here is some proposed amended text that indicates “schemas” only needs to be provided in the outer most JSON element:

|   The body of each request MUST contain the following "schemas" URI:
|   "urn:ietf:params:scim:api:messages:2.0:PatchOp", followed by an array
|   of one or more operations.  For example:
 
| { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
|   [
|     {
|      "op":"add",
|      "path":"members",
|      "value":[
|       {
|         "display": "Babs Jensen",
|         "$ref": "https://example.com/v2/Users/2819c223...413861904646",
|         "value": "2819c223-7f76-453a-919d-413861904646"
|       }
|      ]
|     },
|     ... + additional operations if needed ...
|   ]
| }
|
|                 Example JSON body for SCIM PATCH Request

Phil

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

---

From: Kelly Grizzle <[email-masked]>
Date: Fri, 8 Aug 2014 17:00:35 +0000

+1.  Although, I would change the URN to be urn:ietf:params:scim:api:messages:2.0:PatchRequest (instead of PatchOp).  This would make it more consistent with SearchRequest and BulkRequest.  IMO a PatchRequest could contain multiple PatchOps, where an operation would be a single add/remove/replace request).

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Friday, August 08, 2014 11:44 AM
To: SCIM WG
Subject: [scim] Proposed PATCH Change: 1 of 2

Currently, the PATCH body consists of an array of objects, each with a single operation and its own "schemas" attribute. Here is some proposed amended text that indicates "schemas" only needs to be provided in the outer most JSON element:

|   [

|     {

|      "op":"add",

|      "path":"members",

|      "value":[

|       {

|       }

|      ]

|     },

|   ]

| }

|

Phil

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

---

From: Phil Hunt <[email-masked]>
Date: Fri, 8 Aug 2014 10:07:35 -0700

Good catch. Agreed.

Phil

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

---

From: Leif Johansson <[email-masked]>
Date: Fri, 08 Aug 2014 22:18:44 +0200

On 2014-08-08 19:00, Kelly Grizzle wrote:
> +1.  Although, I would change the URN to be
> urn:ietf:params:scim:api:messages:2.0:PatchRequest (instead of
> PatchOp).  This would make it more consistent with SearchRequest and
> BulkRequest.  IMO a PatchRequest could contain multiple PatchOps, where
> an operation would be a single add/remove/replace request).
> 

+1 for consistency :-)

>  
> 
> --Kelly
> 
>  
> 
> *From:*scim [mailto:[email-masked]] *On Behalf Of *Phil Hunt
> *Sent:* Friday, August 08, 2014 11:44 AM
> *To:* SCIM WG
> *Subject:* [scim] Proposed PATCH Change: 1 of 2
> 
>  
> 
> After some feedback at IETF90 and on this list, I would like to propose
> to optimization changes to PATCH that should make it more consistent and
> less verbose.
> 
>  
> 
> Please indicate your -1 if you have any objections or questions.  If no
> objections, I will include this in the next update late Monday afternoon.
> 
>  
> 
> Currently, the PATCH body consists of an array of objects, each with a
> single operation and its own “schemas” attribute. Here is some proposed
> amended text that indicates “schemas” only needs to be provided in the
> outer most JSON element:
> 
>  
> 
> www.independentid.com <http://www.independentid.com>
> 
> [email-masked] <mailto:[email-masked]>
> 
>  
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>