Quoting from the current spec (section 3.3.1):

   Unless otherwise specified a successful PUT opera=
tion returns a 200
   OK response code and the entire resource within the response body,
   enabling the client to correlate the client's and the service
   provider's views of the updated resource


2 questions:
- why return the resource? under what circu=
mstances can the 'views' be different, and what would a client do a=
bout that? Why not just let the client 'get' the resource if it wan=
ts to see the outcome, instead of clogging up bandwidth with the reponse?=
=C2=A0
- "unless otherwise specified" - I did not see a=
ny information about how that might be specified?=C2=A0

thanks
Grahame

-- 
-----
http://www.healthintersections.com.au / grahame@healthinte=
rsections.com.au / +61 411 867 065

--e89a8f3ba7ed144137050db5b616-- From nobody Wed Jan 28 05:30:12 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB781A007C for ; Wed, 28 Jan 2015 05:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2l2NQQs5QtSt for ; Wed, 28 Jan 2015 05:29:49 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4DDB1A0081 for ; Wed, 28 Jan 2015 05:29:44 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LsD9n-1XXxO62pLT-013sI5; Wed, 28 Jan 2015 14:29:41 +0100 Message-ID: <54C8E43F.9080204@gmx.de> Date: Wed, 28 Jan 2015 14:29:35 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Grahame Grieve , "scim@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:W2y56QNFN7DWEKH1+ok4IqambJTTbEzR9ihLxS774sl5P5nBnWf aWeTqr1CwErbacuhzbnm2hfjn0aTRjEoMJXBLkkaiMBffxutznky7xXOhkarG2ZEinR0FaL ltn/G1mbmY5gz/xL2GArVuadYei1Ey4jxPa0rT04u4vezJNbQayk9D1+ok62aXJOQ136Gp+ 0cGTfX0GS3TsKboZ3DM+Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [scim] Return of POST/PUT operations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 13:29:58 -0000 On 2015-01-28 13:42, Grahame Grieve wrote: > Quoting from the current spec (section 3.3.1): > > Unless otherwise specified a successful PUT operation returns a 200 > OK response code and the entire resource within the response body, > enabling the client to correlate the client's and the service > provider's views of the updated resource > > > 2 questions: > - why return the resource? under what circumstances can the 'views' be > different, and what would a client do about that? Why not just let the > client 'get' the resource if it wants to see the outcome, instead of > clogging up bandwidth with the reponse? > - "unless otherwise specified" - I did not see any information about how > that might be specified? > > thanks > Grahame might be of interest. Best regards, Julian From nobody Wed Jan 28 08:35:35 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A211A87A2 for ; Wed, 28 Jan 2015 08:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxGGLiCeZqob for ; Wed, 28 Jan 2015 08:35:28 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3331A8792 for ; Wed, 28 Jan 2015 08:35:28 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0SGZO3s018757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Jan 2015 16:35:24 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0SGZNa6023722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Jan 2015 16:35:23 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0SGZMq8023673; Wed, 28 Jan 2015 16:35:22 GMT Received: from [10.0.1.6] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Jan 2015 08:35:22 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12B440) In-Reply-To: <54C8E43F.9080204@gmx.de> Date: Wed, 28 Jan 2015 08:35:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2A4F5D90-8D43-4EEC-BB20-72030EB92A0B@oracle.com> References: <54C8E43F.9080204@gmx.de> To: Julian Reschke X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Cc: "scim@ietf.org" , Grahame Grieve Subject: Re: [scim] Return of POST/PUT operations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 16:35:33 -0000 The general design principle has been to return the final representation. SC= IM's primary objective is provisioning so letting the client know the final s= tate has been the historical choice. Not saying whether this is good or bad,= but it has been my impression from the original drafts. Maybe others have m= ore historical context? I am concerned about use of the returned header per sec 4.2 of 7340 as this a= dds more permutations besides http status 200 vs 204.=20 Note: we are currently past last call but this may re-open due other bugs I w= ill post today.=20 Phil > On Jan 28, 2015, at 05:29, Julian Reschke wrote: >=20 >> On 2015-01-28 13:42, Grahame Grieve wrote: >> Quoting from the current spec (section 3.3.1): >>=20 >> Unless otherwise specified a successful PUT operation returns a 200 >> OK response code and the entire resource within the response body, >> enabling the client to correlate the client's and the service >> provider's views of the updated resource >>=20 >>=20 >> 2 questions: >> - why return the resource? under what circumstances can the 'views' be >> different, and what would a client do about that? Why not just let the >> client 'get' the resource if it wants to see the outcome, instead of >> clogging up bandwidth with the reponse? >> - "unless otherwise specified" - I did not see any information about how >> that might be specified? >>=20 >> thanks >> Grahame >=20 > might be of interest. >=20 > Best regards, Julian >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed Jan 28 08:42:20 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725FD1A8747 for ; Wed, 28 Jan 2015 08:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDLXMM9GwMWK for ; Wed, 28 Jan 2015 08:42:13 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39EC1A878A for ; Wed, 28 Jan 2015 08:42:12 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M5dMm-1XS6yA0SMK-00xcEL; Wed, 28 Jan 2015 17:42:10 +0100 Message-ID: <54C9115C.6000104@gmx.de> Date: Wed, 28 Jan 2015 17:42:04 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Phil Hunt References: <54C8E43F.9080204@gmx.de> <2A4F5D90-8D43-4EEC-BB20-72030EB92A0B@oracle.com> In-Reply-To: <2A4F5D90-8D43-4EEC-BB20-72030EB92A0B@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Hp0ejeUNaMiv5TSG+m/cFtcFoKNWCQK2f7JRltu3akAIm65VUMn +J9GV0baCtXkqx8QtfIp7RyTP8YXrBRW+rAqhaKV1iIgvh3g68pqeNcLSRmP35+oydQw2bR Njz9zUs+75OVIe4Em22XO3REXOHqUg/BdvSiUnLt5p5nQzG5Hz3TBmfDwkLgBlrPDktbzag XKrGZXEpr3BSP4uu3Qg7w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "scim@ietf.org" , Grahame Grieve Subject: Re: [scim] Return of POST/PUT operations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 16:42:19 -0000 On 2015-01-28 17:35, Phil Hunt wrote: > The general design principle has been to return the final representation. SCIM's primary objective is provisioning so letting the client know the final state has been the historical choice. Not saying whether this is good or bad, but it has been my impression from the original drafts. Maybe others have more historical context? > > I am concerned about use of the returned header per sec 4.2 of 7340 as this adds more permutations besides http status 200 vs 204. > > Note: we are currently past last call but this may re-open due other bugs I will post today. > > Phil > ... If you require 200 with the full resource state then you are profiling HTTP. It's better to avoid that, because if you have two conflicting profiles, you can't implement them on the same URI unless you do UA sniffing. The Prefer header field gives you the hook that you need to specify a preference. Best regards, Julian From nobody Wed Jan 28 09:40:35 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFFA1A0E10 for ; Wed, 28 Jan 2015 09:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjMevkcnDS53 for ; Wed, 28 Jan 2015 09:40:31 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9797B1A1F00 for ; Wed, 28 Jan 2015 09:40:31 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0SHeTf0023550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 28 Jan 2015 17:40:30 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0SHeSRH020378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 28 Jan 2015 17:40:29 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0SHeSX7020307 for ; Wed, 28 Jan 2015 17:40:28 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Jan 2015 09:40:27 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_15143AEB-FB84-4B25-9380-38AB760847B4" Message-Id: <6D2639A2-6B34-4861-99CB-C3AAAAF0BAD7@oracle.com> Date: Wed, 28 Jan 2015 09:40:26 -0800 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Subject: [scim] Core Schema Attribute Type Inconsistencies X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 17:40:33 -0000 --Apple-Mail=_15143AEB-FB84-4B25-9380-38AB760847B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In the SCIM core schema document, it has been brought to my attention = from some reviewers that there are some inconsistencies regarding the = use of attribute types within SCIM.=20 The concern is an apparent conflict between Section 2.1 (which defines = attribute types) and Section 7 (which is the Schema definition). In = particular, we define Decimal, Integer, DateTime, Binary, and Reference = as well as =E2=80=9CString=E2=80=9D, =E2=80=9CBoolean=E2=80=9D, and = =E2=80=9CComplex". Yet in practice, Section 7 uses only =E2=80=9CString=E2= =80=9D, =E2=80=9CComplex=E2=80=9D and =E2=80=9Cboolean=E2=80=9D are used = in Section 7. After some review, I note that Section 2.1 is very clear about how each = type is represented in JSON (per RFC7159). =20 It appears that Section 7 is reflecting the JSON type rather than the = SCIM type and should be changed to reflect the SCIM data type, not the = JSON data type. Please let me know if there are any objections or concerns to this = clarification. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_15143AEB-FB84-4B25-9380-38AB760847B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In the SCIM core schema document, it has been brought to my = attention from some reviewers that there are some inconsistencies = regarding the use of attribute types within SCIM.

The concern is an apparent conflict = between Section 2.1 (which defines attribute types) and Section 7 (which = is the Schema definition). In particular, we define Decimal, = Integer, DateTime, Binary, and Reference as well as =E2=80=9CString=E2=80=9D= , =E2=80=9CBoolean=E2=80=9D, and =E2=80=9CComplex". Yet in = practice, Section 7 uses only =E2=80=9CString=E2=80=9D, =E2=80=9CComplex=E2= =80=9D and =E2=80=9Cboolean=E2=80=9D are used in Section 7.

After some review, I = note that Section 2.1 is very clear about how each type is represented = in JSON (per RFC7159).

It appears that Section 7 is reflecting = the JSON type rather than the SCIM type and should be changed to reflect the SCIM data type, not = the JSON data type.

Please let me know if there are any objections or concerns to = this clarification.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

= --Apple-Mail=_15143AEB-FB84-4B25-9380-38AB760847B4-- From nobody Wed Jan 28 10:12:36 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108001A887D for ; Wed, 28 Jan 2015 10:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzIlBtkZx_sz for ; Wed, 28 Jan 2015 10:12:29 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C611A884D for ; Wed, 28 Jan 2015 10:12:29 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0SICSi6002490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 28 Jan 2015 18:12:29 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id t0SICRrn009551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 28 Jan 2015 18:12:28 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0SICRZu006867 for ; Wed, 28 Jan 2015 18:12:27 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Jan 2015 10:12:26 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_6DE8F676-1D96-4AEA-AC68-0C724CDB0DEB" Message-Id: <59F54E0C-DBF1-47F9-9AF5-0E3BBA049BAE@oracle.com> Date: Wed, 28 Jan 2015 10:12:25 -0800 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: Subject: [scim] Clarification on PATCH regarding "replace" operations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 18:12:32 -0000 --Apple-Mail=_6DE8F676-1D96-4AEA-AC68-0C724CDB0DEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A reviewer has indicated that the SCIM API document is not clear on what = should happen during a PATCH =E2=80=9Creplace=E2=80=9D operation if the = target attribute does not exist. I note that in the SCIM API error response we do have the SCIM error = =E2=80=9CnoTarget=E2=80=9D. This error is intended to be returned if the = =E2=80=9Cpath=E2=80=9D value contains a valuePath filter which specifies = which specific value of a multi-valued attribute is being patched and no = value match occurs. Should we broaden use of =E2=80=9CnoTarget" to include a replace = operation where no-existing value occurs? Some have argued that it is more useful to allow a replace to = automatically add. I note that the PATCH =E2=80=9Cadd=E2=80=9D = operation already does this by its rule that =E2=80=9Cif the target = location exists, the value is replaced.=E2=80=9D Making replace do = auto-add seems to be consistent with the =E2=80=9Cadd=E2=80=9D = operation. My proposal is to add clarification text to PATCH =E2=80=9Creplace" that = says it is permissible to add a new attribute if there is none to = replace. This follows the be flexible in what you accept principle. I = will also add clarification in replace that a =E2=80=9CnoTarget=E2=80=9D = error is only returned if there is no match on a =E2=80=9CvaluePath=E2=80=9D= type of path (one which specifies a specific target record of a = multi-valued attribute). * Please let me know if this clarification represents a normative change = to anyone, OR, if you object to the clarification. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_6DE8F676-1D96-4AEA-AC68-0C724CDB0DEB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A reviewer has indicated that the SCIM API document is not = clear on what should happen during a PATCH =E2=80=9Creplace=E2=80=9D = operation if the target attribute does not exist.

I note that in the SCIM API error = response we do have the SCIM error =E2=80=9CnoTarget=E2=80=9D. This = error is intended to be returned if the =E2=80=9Cpath=E2=80=9D value = contains a valuePath filter which specifies which specific value of a = multi-valued attribute is being patched and no value match = occurs.

Should = we broaden use of =E2=80=9CnoTarget" to include a replace operation = where no-existing value occurs?

Some have argued that it is more useful = to allow a replace to automatically add. I note that the PATCH = =E2=80=9Cadd=E2=80=9D operation already does this by its rule that =E2=80=9C= if the target location exists, the value is replaced.=E2=80=9D = Making replace do auto-add seems to be consistent with the = =E2=80=9Cadd=E2=80=9D operation.

My proposal is to add clarification = text to PATCH =E2=80=9Creplace" that says it is permissible to add a new = attribute if there is none to replace. This follows the be = flexible in what you accept principle. I will also add = clarification in replace that a =E2=80=9CnoTarget=E2=80=9D error is only = returned if there is no match on a =E2=80=9CvaluePath=E2=80=9D type of = path (one which specifies a specific target record of a multi-valued = attribute).

* = Please let me know if this clarification represents a normative change = to anyone, OR, if you object to the clarification.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

= --Apple-Mail=_6DE8F676-1D96-4AEA-AC68-0C724CDB0DEB-- From nobody Wed Jan 28 14:03:20 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92F31A037C for ; Wed, 28 Jan 2015 14:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqpPlVVsy5HH for ; Wed, 28 Jan 2015 14:03:12 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC771A00F6 for ; Wed, 28 Jan 2015 14:03:11 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id h11so16001994wiw.5 for ; Wed, 28 Jan 2015 14:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Mn87wnBdGTntCzXEvCRxRL5cUlXrCBPgd2X4ULqM1LA=; b=AjbQPKv2034rMq9cOrBPDODq+t5SPjAv9qK9nCStkPabDZV1ssykupCL96YC8+plLk 8Zy/UKGJESSOAdt6yDy+5O6Zblqy3EY8pxpEJOV9Pjg6wAwygg1Z7/Pv9tf4eYtB4aMC RsXZ5kxfTffDV8CjNhp8WSlELDi7TZcPqprX52Y9/ItRd29dFR5GCF9OUXjejn8GmPCG ipPK8TydyKv8K0mzhUkO9trDI1s605HuWUR3Jv/7d7Q7XMvkh2cr83TdGedrZtDIk5Lj 8SDO0ED9u25Octqp8Nmeq5M3cF8ioE1hokYZiZz246mabuYSfZedeRWCUGl8esIAuVV5 YECA== MIME-Version: 1.0 X-Received: by 10.180.74.205 with SMTP id w13mr22167637wiv.1.1422482590163; Wed, 28 Jan 2015 14:03:10 -0800 (PST) Sender: grahameg@gmail.com Received: by 10.27.77.68 with HTTP; Wed, 28 Jan 2015 14:03:10 -0800 (PST) In-Reply-To: <54C8E43F.9080204@gmx.de> References: <54C8E43F.9080204@gmx.de> Date: Thu, 29 Jan 2015 09:03:10 +1100 X-Google-Sender-Auth: 63eHVXId31eEl8Aj-TDIYmfEkL8 Message-ID: From: Grahame Grieve To: Julian Reschke Content-Type: multipart/alternative; boundary=f46d043c07407caa06050dbd896e Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Return of POST/PUT operations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 22:03:18 -0000 --f46d043c07407caa06050dbd896e Content-Type: text/plain; charset=UTF-8 that's very interesting, thanks Grahame On Thu, Jan 29, 2015 at 12:29 AM, Julian Reschke wrote: > On 2015-01-28 13:42, Grahame Grieve wrote: > >> Quoting from the current spec (section 3.3.1): >> >> Unless otherwise specified a successful PUT operation returns a 200 >> OK response code and the entire resource within the response body, >> enabling the client to correlate the client's and the service >> provider's views of the updated resource >> >> >> 2 questions: >> - why return the resource? under what circumstances can the 'views' be >> different, and what would a client do about that? Why not just let the >> client 'get' the resource if it wants to see the outcome, instead of >> clogging up bandwidth with the reponse? >> - "unless otherwise specified" - I did not see any information about how >> that might be specified? >> >> thanks >> Grahame >> > > might be of interest. > > Best regards, Julian > > -- ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 --f46d043c07407caa06050dbd896e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

that's very interesting, thanks

Gra= hame

On Thu, Jan 29, 2015 at 12:29 AM, Julian Reschke <julian= .reschke@gmx.de> wrote:

On 2015-01-28 13:42, Grahame Grieve wrote:

Quoting from the current spec (section 3.3.1):

=C2=A0 =C2=A0 Unless otherwise specified a successful PUT operation returns= a 200
=C2=A0 =C2=A0 OK response code and the entire resource within the response = body,
=C2=A0 =C2=A0 enabling the client to correlate the client's and the ser= vice
=C2=A0 =C2=A0 provider's views of the updated resource

2 questions:
- why return the resource? under what circumstances can the 'views'= be
different, and what would a client do about that? Why not just let the
client 'get' the resource if it wants to see the outcome, instead o= f
clogging up bandwidth with the reponse?
- "unless otherwise specified" - I did not see any information ab= out how
that might be specified?

thanks
Grahame

<https://tools.ietf.org/html/rfc7240#section-4.2> might= be of interest.

Best regards, Julian

-----
http://www.healthintersections.com.au / grahame@he= althintersections.com.au / +61 411 867 065

--f46d043c07407caa06050dbd896e--