Subject: [scim] PATCH method in Bulk

From: [email-masked]
Date: Tue, 21 Oct 2014 11:53:07 +0900

Hello

In section 3.5.3(page 52) of api document,
PATCH method is written as follows.

   "method": "PATCH",
   "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
   "version": "W/\"edac3253e2c0ef2\"",
   "data": {[
     {
         "op": "remove",
         "path": "nickName"
     },

Questions.

1."schemas" attrribute is not need in "data"?
2."Operations" attribute is not need in "data"?

as follows.

   "method": "PATCH",
   "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
   "version": "W/\"edac3253e2c0ef2\"",
   "data": {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
     "Operations": [
       {
           "op": "remove",
           "path": "nickName"
       },

-
Takanori Ueda.

---

From: Erik Wahlström, neXus <[email-masked]>
Date: Tue, 21 Oct 2014 13:11:19 +0000

Yes. Looks like it’s a typo in the spec. Should be a standard PATCH call within the data attribute.
/ Erik

On 21 Oct 2014, at 04:53, [email-masked] wrote:

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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 21 Oct 2014 08:43:40 -0700

I agree, the PATCH operation is not consistent.

We shall need to put some clarifying text that the outer path applies to selection of the resource (in place of URL) and the inner path for the operation applies to attribute/value selection.

The rule of thumb should be that the JSON blob within the “data” attribute should match the body payload of any other SCIM HTTP request?  Correct?

Phil

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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 21 Oct 2014 11:17:35 -0700

Looking this over, it looks like the example is erroneous:
       … 
       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {[
           {
               "op": "remove",
               "path": "nickName"
           },
           {
               "op": "add",
               "path": "userName",
               "value": "Dave"
           }
         ]}
       …

It should be changed to (full example included):

   POST /v2/Bulk
   Host: example.com
   Accept: application/scim+json
   Content-Type: application/scim+json
   Authorization: Bearer h480djs93hd8
   Content-Length: ...

   {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
     "failOnErrors":1,
     "Operations":[
       {
         "method":"POST",
         "path":"/Users",
         "bulkId":"qwerty",
         "data":{
           "schemas": ["urn:ietf:params:scim:api:messages:2.0:User"],
           "userName":"Alice"
         }
       },
       {
         "method":"PUT",
         "path":"/Users/b7c14771-226c-4d05-8860-134711653041",
         "version":"W\/\"3694e05e9dff591\"",
         "data":{
           "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
           "id":"b7c14771-226c-4d05-8860-134711653041",
           "userName":"Bob"
         }
       },
       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {
           "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
           "Operations": [
               {
                  “schemas”:["
                  "op": "remove",
                  "path": "nickName"
               },
               {
                  "op": "add",
                  "path": "userName",
                  "value": "Dave"
               }
           ]
         }
       },
       {
         "method":"DELETE",
         "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
         "version":"W\/\"0ee8add0a938e1a\""
       }
     ]
   }

If any have implemented according to the erroneous example and object to the change, please let the list know.

Regards,

Phil

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

---

From: Ian Glazer <[email-masked]>
Date: Tue, 21 Oct 2014 14:22:31 -0400

Do we need the schemas element in the Operations section?

On Tue, Oct 21, 2014 at 2:17 PM, Phil Hunt <[email-masked]> wrote:

> *       {
> *       …
>        },*       {
>          "data": {*
> *           "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
>            "Operations": [
>                {*
>
> *                  “schemas”:["
>                   "op": "remove",
>                   "path": "nickName"
>                },
>                {
>                   "op": "add",
>                   "path": "userName",
>                   "value": "Dave"
>                }
>            ]*
>
> *         }
>        },*
>        {
>          "method":"DELETE",
> We shall need to put some clarifying text that the outer path applies to
> selection of the resource (in place of URL) and the inner path for the
> operation applies to attribute/value selection.
>
> The rule of thumb should be that the JSON blob within the “data” attribute
> should match the body payload of any other SCIM HTTP request?  Correct?
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>

-- 
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer <https://twitter.com/iglazer>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 21 Oct 2014 11:32:10 -0700

Yes.  That would be consistent with the normal patch operation.

Phil

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

On Oct 21, 2014, at 11:22 AM, Ian Glazer <[email-masked]> wrote:

> @iglazer

---

From: Alex Redston <[email-masked]>
Date: Tue, 21 Oct 2014 20:39:15 +0100

Contributors

I've been away from the list for a few months so the changes seem to be 
fairly dramatic, a bit like seeing a child for the first time in 6 months.

Please don't be offended as this is a casual observation and is not 
meant in any derogatory way.

I understand the reason for adding schema fields, it seems that the spec 
is becoming more verbose and I will be interested to see how many of the 
larger vendors who are not part of the core SCIM contributors go on to 
implement the v2 spec.

I know the S in SCIM no longer stands for simple and the spec is more 
complete, robust, deterministic and flexible now but the syntax is 
becoming more verbose, as it does I can't help but think it would be 
cleaner if XML were restored to the spec.

The trouble with specifications is that adoption rate often trumps quality.

For me - I'm looking forward to implementing the new specification, in 
its current form which we will start work on shortly.

Alex

On 21/10/2014 19:22, Ian Glazer wrote:
> On Tue, Oct 21, 2014 at 2:17 PM, Phil Hunt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>             ...
>     *        ...
>         Host:example.com  <http://example.com>
>     *                   "schemas":["
>     If any have implemented according to the erroneous example and
>     object to the change, please let the list know.
>
>     Regards,
>
>     Phil
>
>     @independentid
>     www.independentid.com <http://www.independentid.com>
>     [email-masked] <mailto:[email-masked]>
>
>
>
>     On Oct 21, 2014, at 8:43 AM, Phil Hunt <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>>     We shall need to put some clarifying text that the outer path
>>     applies to selection of the resource (in place of URL) and the
>>     inner path for the operation applies to attribute/value selection.
>>
>>     The rule of thumb should be that the JSON blob within the "data"
>>     attribute should match the body payload of any other SCIM HTTP
>>     request?  Correct?
>>
>>     Phil
>>
>>     @independentid
>>     www.independentid.com <http://www.independentid.com>
>>     [email-masked] <mailto:[email-masked]>
>>
>>
>>
>>     On Oct 21, 2014, at 6:11 AM, Erik Wahlström, neXus
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>>     Yes. Looks like it's a typo in the spec. Should be a standard
>>>     PATCH call within the data attribute.
>>>     / Erik
>>>
>>>     On 21 Oct 2014, at 04:53, [email-masked]
>>>     <mailto:[email-masked]> wrote:
>>>
>>>>     Hello
>>>>
>>>>     [email-masked] <mailto:[email-masked]>
>>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

---

From: Phil Hunt <[email-masked]>
Date: Tue, 21 Oct 2014 15:49:56 -0700

Alex,

Thanks for your comments. 

Yes, our baby has been going through a healthy maturation indeed!

Was there anything specific to this issue that you are recommending?  

Phil

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

On Oct 21, 2014, at 12:39 PM, Alex Redston <[email-masked]> wrote:

> Contributors
> 
> I've been away from the list for a few months so the changes seem to be fairly dramatic, a bit like seeing a child for the first time in 6 months.
> 
> Please don't be offended as this is a casual observation and is not meant in any derogatory way.
> 
> I understand the reason for adding schema fields, it seems that the spec is becoming more verbose and I will be interested to see how many of the larger vendors who are not part of the core SCIM contributors go on to implement the v2 spec.
> 
> I know the S in SCIM no longer stands for simple and the spec is more complete, robust, deterministic and flexible now but the syntax is becoming more verbose, as it does I can't help but think it would be cleaner if XML were restored to the spec.
> 
> For me - I'm looking forward to implementing the new specification, in its current form which we will start work on shortly.
> Alex

---

From: Alex Redston <[email-masked]>
Date: Wed, 22 Oct 2014 08:55:01 +0100

Hi Phil

Sorry if this is a naive question but I'm just wondering about how bulk 
patch operations will look and whether with the JSON syntax for such an 
operation would containing repeated references to the schema in each 
subsequent patch.

*"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"]*

Alex

Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

On 21/10/2014 23:49, Phil Hunt wrote:
> On Oct 21, 2014, at 12:39 PM, Alex Redston 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> Contributors
>>
>> I've been away from the list for a few months so the changes seem to 
>> be fairly dramatic, a bit like seeing a child for the first time in 6 
>> months.
>>
>> I understand the reason for adding schema fields, it seems that the 
>> spec is becoming more verbose and I will be interested to see how 
>> many of the larger vendors who are not part of the core SCIM 
>> contributors go on to implement the v2 spec.
>>
>> For me - I'm looking forward to implementing the new specification, 
>> in its current form which we will start work on shortly.
>> Alex
>>>         Host:example.com  <http://example.com/>
>>>     www.independentid.com <http://www.independentid.com/>
>>>>     The rule of thumb should be that the JSON blob within the
>>>>     “data” attribute should match the body payload of any other
>>>>     SCIM HTTP request?  Correct?
>>>>
>>>>     Phil
>>>>
>>>>     @independentid
>>>>     www.independentid.com <http://www.independentid.com/>
>> ------------------------------------------------------------------------
>> <http://www.avast.com/> 	
>>
>> This email is free from viruses and malware because avast! Antivirus 
>> <http://www.avast.com/> protection is active.
>>
>>

---

---

From: Phil Hunt <[email-masked]>
Date: Wed, 22 Oct 2014 08:55:38 -0700

Alex,

What goes in the “data" attribute should match what you would put in the body of a single HTTP PATCH request.

IOW, if you were to take the value of “data” and put it as input into your PATCH operation parser it should work the same. 

Sooo…

In the case of PATCH, each sub-operation does not have a repeated schemas attribute. There is only one at the top of the array — following the same pattern as the normal PATCH request.

As a full example, the following bulk request has a patch and a delete operation. The patch operation also has 2 operations to the same User which removes the attribute “members” and then adds 2 values back to members (note: this could be more concise using replace, but I’m showing multiple repeated operations). Note that the bolded section should exactly match the body of the normal HTTP PATCH request:
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
  "failOnErrors":1,
  "Operations":[       
    {
      "method": "PATCH",
      "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
      "version": "W/\"edac3253e2c0ef2\"",
      "data":
        {
          "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
          "Operations": [
            {
              "op":"remove","path":"members"
            },
            {
              "op":"add",
              "path":"members",
              "value":[
                {
                  "display": "Babs Jensen",
                  "$ref": "https://example.com/v2/Users/2819c223...413861904646",
                  "value": "2819c223-7f76-453a-919d-413861904646"
                },
                {
                  "display": "James Smith",
                  "$ref": "https://example.com/v2/Users/08e1d05d...473d93df9210",
                  "value": "08e1d05d-121c-4561-8b96-473d93df9210"
                }]
            }
          ]
        } 
    },
    {
      "method":"DELETE",
      "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
      "version":"W\/\"0ee8add0a938e1a\""
    }
  ]
}

I agree, in this compound case, it looks a bit complicated (“operations”, “path" and “schemas” are repeated). However, within each structure the JSON is consistent.  Meaning, you could cut and paste the body from HTTP PATCH and place it in the “data” attribute.
 
Phil

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

On Oct 22, 2014, at 12:55 AM, Alex Redston <[email-masked]> wrote:

> Hi Phil
> 
> Sorry if this is a naive question but I'm just wondering about how bulk patch operations will look and whether with the JSON syntax for such an operation would containing repeated references to the schema in each subsequent patch. 
> 
>  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"]
> 
> Alex
> Alex Redston
> 
> CEO

---

From: Leif Johansson <[email-masked]>
Date: Wed, 22 Oct 2014 21:39:31 +0200

> cleaner if XML were restored to the spec.

Hi Alex,

The XML issue has been settled by consensus in the WG already and based
on the (lack of response) to your comment above, we're not re-opening
that issue.

The documents are currently in WGLC (closing tomorrow) so if you have
specific concerns you should write them up right now and send them to
the list.

	Cheers Leif (with my chair hat on)