From nobody Mon Mar 3 22:55:28 2014 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 21F321A037F for ; Mon, 3 Mar 2014 22:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 TWcOdCAeGUTy for ; Mon, 3 Mar 2014 22:55:24 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D9D941A035F for ; Mon, 3 Mar 2014 22:55:23 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id x12so1942852wgg.6 for ; Mon, 03 Mar 2014 22:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NF6KmlM0O01khRA0sJrobtWC/Mudyv045el2vJvrgXo=; b=Pa68nCKVpkomcMjEXnyMiuSUakz6Mx5Af0YmF4UexUA4nvXwdxZ/eiFAnM+Em7zBnl xnTpMaHvlGO02fZG5gxj64CVO0pVkZ2w5eckmdwnIMGElOskbeU+FlsbwIab7rigGnpw 2EverEcr8ZMAGjsOrvhwnz1JnwhvlZ5K1fBuCYmMRBrgbECTamyXy3QK+ikdZlDPCi0u Qp/+LU+EeW2H/T1bJB/GGA4BoXGEsTBDA7gXAANMKFicLdBedtwAezgJcWozhp4ccXhC U5KXvNyEvbyAlr5zmadV9zmmvWtGyr0dg8RFuz0UdY+h8P+X2et7Q587w/hesRHF90LX y74g== MIME-Version: 1.0 X-Received: by 10.194.143.40 with SMTP id sb8mr24839216wjb.15.1393916120351; Mon, 03 Mar 2014 22:55:20 -0800 (PST) Received: by 10.216.42.196 with HTTP; Mon, 3 Mar 2014 22:55:20 -0800 (PST) In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E44C4D1@SZXEMA510-MBX.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB63E44C4D1@SZXEMA510-MBX.china.huawei.com> Date: Tue, 4 Mar 2014 01:55:20 -0500 Message-ID: From: "B.Khasnabish@ieee.org" To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=089e0115e78c33466604f3c26382 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/6SD3x0wdQAzgLxAGrja3_5O4xJI Cc: "scim@ietf.org" Subject: Re: [scim] Comments on SCIM use cases draft 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: Tue, 04 Mar 2014 06:55:26 -0000 --089e0115e78c33466604f3c26382 Content-Type: text/plain; charset=ISO-8859-1 Thanks a lot Bert. We'll address these in the next version. Best. Bhumip On Fri, Feb 28, 2014 at 2:07 AM, Bert Greevenbosch < Bert.Greevenbosch@huawei.com> wrote: > Hi all, > > I have reviewed the SCIM use cases draft: > > http://tools.ietf.org/html/draft-ietf-scim-use-cases-00 > > I have some comments listed below. I think they are not too difficult to > handle. :-) > > Best regards, > Bert > > --- > > [BG1] Section 2.2.1, 3d line: change "identity" to "identify". > > [BG2] Section 2.2.1, the abbreviation "C.R.U.D." is expanded, whereas > "SSO" is not. I suggest to expand SSO too. > > [BG3] Section 2.2.1, I am not clear on the various triggers. Each item has > the name of a trigger, but in the description there is another name of a > trigger. For example, in the first item there is "Create SCIM Identity > Resource - Service On-boarding Trigger", and in the description "create > SCIM resource trigger". Are these the same? Then use a single name. Also, > for readability I suggest to put the name between quotes, e.g. "create SCIM > resource" trigger. > > [BG4] Section 2.2.1, first item last sentence, add ", and" between > "implementation" and "not to the use cases". > > [BG5] Section 2.2.2, second item: replace "entitle" by "entity". > > [BG6] Section 2.2.2, third item: replace "end-end" by "end". > > [BG7] Section 2.2.3, "real work use cases" -> "real world use cases". > > [BG8] Section 2.3.3: "This use case highlights how different CSPs may > implement different operational semantics behind the same SCIM operation. > Note that CSP-1 suspends the account representation for its service whereas > CPS-2 implements a true delete operation." > Interesting idea. Is it truly desired to have different CSPs treat the > same request differently? Obviously there will always be some difference > between implementations, but this difference seems quite big. > On the other hand, maybe this is also not truly the same SCIM operation, > since CSP-1 receives the trigger from the ECS, whereas CSP-2 receives a > termination request from CSP-1. > > [BG9] Section 2.2.4, last sentence: > "However, rather than pre-provisioning accounts from ECS-1 to CSP-1, CSP-1 > waits for a service access request from the Cloud Service User (CSU-1) > under the control domain of ECS-1, before issuing an account Pull request > to CSP-1." > Something seems wrong in this sentence, as it seems to say that CSP-1 > issues a Pull request to itself. Maybe the account Pull request is sent to > "ECS-1", not to "CSP-1"? > > [BG10] In various use cases, there are requirements for logs. However, > there is no text in the use cases itself. Maybe it would be better to > elaborate a bit on the logs in the use cases? This should also involve the > mentioned auditing. > > [BG11] Section 3.4, the sentence "The local YourCoI offices are > responsible for establishing personal information and (i.e., setting the > user identities and attributes)." needs wordsmithing. > > [BG12] Section 3.4, "Identity management of the personal data must be > secure" is a bit vague. I guess it means protected against unauthorised > access and remaining confidentiality? Then maybe the following wording > would be better: "Identity management of the personal data must be > protected against unauthorised access and remain confidential to only > authorised parties." > > [BG13] Section 3.5: should there be a requirement for expiration of the > cached copy, i.e. a maximum period for which the relying party may cache > the information? > > [BG14] The "security considerations" section is rather short, only > mentioning authorisation and authentication. It would be good to add some > text about confidentiality and privacy protection. > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > --089e0115e78c33466604f3c26382 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
Thanks a lot Bert.
=A0
We'll address these in the next version.
=A0
Best.
<= br>Bhumip

=A0
=A0


On Fri, Feb 28, 2014 at 2:07 AM, B= ert Greevenbosch <Bert.Greevenbosch@huawei.com> w= rote:
Hi all,

I have reviewed the SCIM use cases draft:

http://tools.ietf.org/html/draft-ietf-scim-use-cases-00

I have some comments listed below. I think they are not too difficult to ha= ndle. :-)

Best regards,
Bert

---

[BG1] Section 2.2.1, 3d line: change "identity" to "identify= ".

[BG2] Section 2.2.1, the abbreviation "C.R.U.D." is expanded, whe= reas "SSO" is not. I suggest to expand SSO too.

[BG3] Section 2.2.1, I am not clear on the various triggers. Each item has = the name of a trigger, but in the description there is another name of a tr= igger. For example, in the first item there is "Create SCIM Identity R= esource - Service On-boarding Trigger", and in the description "c= reate SCIM resource trigger". Are these the same? Then use a single na= me. Also, for readability I suggest to put the name between quotes, e.g. &q= uot;create SCIM resource" trigger.

[BG4] Section 2.2.1, first item last sentence, add ", and" betwee= n "implementation" and "not to the use cases".

[BG5] Section 2.2.2, second item: replace "entitle" by "enti= ty".

[BG6] Section 2.2.2, third item: replace "end-end" by "end&q= uot;.

[BG7] Section 2.2.3, "real work use cases" -> "real world= use cases".

[BG8] Section 2.3.3: "This use case highlights how different CSPs may = implement different operational semantics behind the same SCIM operation. N= ote that CSP-1 suspends the account representation for its service whereas = CPS-2 implements a true delete operation."
Interesting idea. Is it truly desired to have different CSPs treat the same= request differently? Obviously there will always be some difference betwee= n implementations, but this difference seems quite big.
On the other hand, maybe this is also not truly the same SCIM operation, si= nce CSP-1 receives the trigger from the ECS, whereas CSP-2 receives a termi= nation request from CSP-1.

[BG9] Section 2.2.4, last sentence:
"However, rather than pre-provisioning accounts from ECS-1 to CSP-1, C= SP-1 waits for a service access request from the Cloud Service User (CSU-1)= under the control domain of ECS-1, before issuing an account Pull request = to CSP-1."
Something seems wrong in this sentence, as it seems to say that CSP-1 issue= s a Pull request to itself. Maybe the account Pull request is sent to "= ;ECS-1", not to "CSP-1"?

[BG10] In various use cases, there are requirements for logs. However, ther= e is no text in the use cases itself. Maybe it would be better to elaborate= a bit on the logs in the use cases? This should also involve the mentioned= auditing.

[BG11] Section 3.4, the sentence "The local YourCoI offices are respon= sible for establishing personal information and (i.e., setting the user ide= ntities and attributes)." needs wordsmithing.

[BG12] Section 3.4, "Identity management of the personal data must be = secure" is a bit vague. I guess it means protected against unauthorise= d access and remaining confidentiality? Then maybe the following wording wo= uld be better: "Identity management of the personal data must be prote= cted against unauthorised access and remain confidential to only authorised= parties."

[BG13] Section 3.5: should there be a requirement for expiration of the cac= hed copy, i.e. a maximum period for which the relying party may cache the i= nformation?

[BG14] The "security considerations" section is rather short, onl= y mentioning authorisation and authentication. It would be good to add some= text about confidentiality and privacy protection.

_______________________________________________
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim

--089e0115e78c33466604f3c26382-- From nobody Tue Mar 4 01:08:55 2014 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 4CB871A0431; Tue, 4 Mar 2014 01:08:49 -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] 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 MwYhmvTKxax5; Tue, 4 Mar 2014 01:08:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0E21A0429; Tue, 4 Mar 2014 01:08:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140304090844.19058.25865.idtracker@ietfa.amsl.com> Date: Tue, 04 Mar 2014 01:08:44 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/lK6lVcAV3GK2lJACloNUVxin9Bg Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-use-cases-01.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 09:08:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : SCIM Use Cases Authors : Phil Hunt Bhumip Khasnabish Anthony Nadalin Kepeng LI Zachary Zeltsan Filename : draft-ietf-scim-use-cases-01.txt Pages : 17 Date : 2014-03-04 Abstract: This document lists the user scenarios and use cases of System for Cross-domain Identity Management (SCIM). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-use-cases-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-use-cases-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 4 05:31:40 2014 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 E6BEE1A01C0 for ; Tue, 4 Mar 2014 05:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 T9YyoVrtmDD3 for ; Tue, 4 Mar 2014 05:31:33 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1B52C1A0080 for ; Tue, 4 Mar 2014 05:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15017; q=dns/txt; s=iport; t=1393939890; x=1395149490; h=from:to:subject:date:message-id:mime-version; bh=sdEqvGL+BuOCHJQH+BslY7xUFOzblRM7NKCe71jcKTo=; b=koSoIDa2hLAMue4YQcwpw0gBxhdjeR3RLg+kcJ8VBFftUW8rUZlnR/QM l70T9OantnLdzzjMQnklF0RXjW7Vf/IP9fqkbo7oPapJ7WmISMYXty1oV OrhdaROS2WH4oibrnAJP4vHfIVUpnMdUybetq5LgoAOcpUKvR0qUjPWVP w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FABbVFVOtJV2b/2dsb2JhbABAFwOCQkQ7V8BugRwWdIIqAmgjAQ8NGAQMPCQDAQOIDA02nFWTRJt1F4xXgSYQMwEMHAeCFoIKBJg8kiuBQIEbUoIq X-IronPort-AV: E=Sophos;i="4.97,585,1389744000"; d="scan'208,217";a="307740306" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 04 Mar 2014 13:31:29 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s24DVTha001417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Mar 2014 13:31:29 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.225]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 07:31:29 -0600 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: Bi-weekly SCIM WG conference calls resuming March 19th Thread-Index: AQHPN64L0Zik0Q1MH0WoFJrdar2Ztw== Date: Tue, 4 Mar 2014 13:31:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.92.187] Content-Type: multipart/alternative; boundary="_000_CF3B862FD0428moransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/f-cnFfhgrAash9dXPq-E-G3H9hY Subject: [scim] Bi-weekly SCIM WG conference calls resuming March 19th 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: Tue, 04 Mar 2014 13:31:36 -0000 --_000_CF3B862FD0428moransarciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, We will not have a WG call on March 12th (too close to London meeting) and = resume the biweekly calls on March 19th. The WebEx meeting info is below, n= ote that this is a new WebEx meeting since we are skipping a week. Please = update your calendar with the new meeting info. Cheers, Morteza ------------------------------------------------------- Meeting information ------------------------------------------------------- Topic: SCIM WG bi-weekly call Date: Every 2 weeks on Wednesday, from Wednesday, March 19, 2014 to no end = date Time: 11:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 385 408 774 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To start or join the online meeting ------------------------------------------------------- Go to https://go.webex.com/go/j.php?ED=3D3985158&UID=3D483472947&RT=3DMiM0 ------------------------------------------------------- Audio conference information ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. US Toll Free: +1-855-749-4751 US Toll: +1-415-655-0000 Global call-in numbers: https://go.webex.com/go/globalcallin.php?serviceTyp= e=3DMC&ED=3D3985158&tollFree=3D1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:385 408 774 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://go.webex.com/go/mc 2. On the left navigation bar, click "Support". To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://go.webex.com/go/j.php?MTID=3Dm92f0520f46fac9644ab9358042b273d0 To check whether you have the appropriate players installed for UCF (Univer= sal Communications Format) rich media files, go to https://go.webex.com/go/= systemdiagnosis.php. http://www.webex.com CCM:+14156550000x385408774# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. You should inform all meeting attendees prior to recording= if you intend to record the meeting. Please note that any such recordings = may be subject to discovery in the event of litigation. --_000_CF3B862FD0428moransarciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9765ACB2A5AA844FAE2E14793D86EEB4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi folks,

We will not have a WG call on March 12th (too close to London meeting)= and resume the biweekly calls on March 19th. The WebEx meeting info is bel= ow, note that this is a new WebEx meeting since we are skipping a week. &nb= sp;Please update your calendar with the new meeting info.


Cheers,
Morteza

---------------------------------------------------= ---- 
Meeting information 
-------------------------------------------------------&= nbsp;
Topic: SCIM WG bi-weekly call 
Date: Every 2 weeks on Wednesday, from Wednesday, March = 19, 2014 to no end date 
Time: 11:00 am, Pacific Daylight Time (San Francisco, GM= T-07:00) 
Meeting Number: 385 408 774 
Meeting Password: (This meeting does not require a passw= ord.) 

-------------------------------------------------------&= nbsp;
To start or join the online meeting 
-------------------------------------------------------&= nbsp;
Go to https://go.webex.com/go/j.php?ED=3D3985158&UID=3D483472947&= RT=3DMiM0 

-------------------------------------------------------&= nbsp;
Audio conference information 
-------------------------------------------------------&= nbsp;
To receive a call back, provide your phone number when y= ou join the meeting, or call the number below and enter the access code.&nb= sp;
US Toll Free: +1-855-749-4751 
US Toll: +1-415-655-0000 
Global call-in numbers: https://go.webex.com/go/globalcalli= n.php?serviceType=3DMC&ED=3D3985158&tollFree=3D1 
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:385 408 774 

-------------------------------------------------------&= nbsp;
For assistance 
-------------------------------------------------------&= nbsp;
1. Go to https://go.webex.com/go/mc 
2. On the left navigation bar, click "Support"= . 
To add this meeting to your calendar program (for exampl= e Microsoft Outlook), click this link: 
https://go.webex.com/go/j.php?MTID= =3Dm92f0520f46fac9644ab9358042b273d0 
To check whether you have the appropriate players instal= led for UCF (Universal Communications Format) rich media files, go to = https://go.webex.com/go/systemdiagnosis.php. <= /span>

http://www= .webex.com 

CCM:+14156550000x385408774# 

IMPORTANT NOTICE: This WebEx service includes a feature = that allows audio and any documents and other materials exchanged or viewed= during the session to be recorded. You should inform all meeting attendees prior to recording if you intend t= o record the meeting. Please note that any such recordings may be subject t= o discovery in the event of litigation. 
--_000_CF3B862FD0428moransarciscocom_-- From nobody Thu Mar 6 03:26:35 2014 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 E86241A0272 for ; Thu, 6 Mar 2014 03:26:33 -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 r48UYoKPhkRb for ; Thu, 6 Mar 2014 03:26:32 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 84D6E1A01C9 for ; Thu, 6 Mar 2014 03:26:32 -0800 (PST) Received: from [130.129.154.225] ([130.129.154.225]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MMGWH-1WGH7e48PF-0085bx for ; Thu, 06 Mar 2014 12:26:28 +0100 Message-ID: <53185B61.4000003@gmx.de> Date: Thu, 06 Mar 2014 12:26:25 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "scim@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jv+7u3Lm0ox4JT6Qkm+J1Y9+RJk6LZLGbf0lepKSJ8Ppg4WXPeg vRlwXnsOgh0xnkYO6FdUGKqY5bzjDxgSNwx2gIhH3kyG68k13CGjRV+nGPyrqJLTBYdfr/k qrSQqcyBAU0qRR8yR2QjZvYygdLeRs/n/9+20CyvNAnimv770Dia7l4bFw7/zQxakgF7/vC rjsPs1PZufaKi4yPTY8aw== Archived-At: http://mailarchive.ietf.org/arch/msg/scim/nvV_Ysoy7iPvFZOTvpaj-a8dnQs Subject: [scim] draft-ietf-scim-api-03 vs RFC2616 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: Thu, 06 Mar 2014 11:26:34 -0000 Hi there, the above mentioned draft still has references RFC 2616. However, RFC 2616 has been obsoleted on Feb 12, so you really ought to reference the new specs which are currently in the RFC Editor's Publication Queue. Best regards, Julian From nobody Thu Mar 6 03:33:42 2014 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 DBDB21A02A6 for ; Thu, 6 Mar 2014 03:33:40 -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 wW0fCCbWQItH for ; Thu, 6 Mar 2014 03:33:39 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 675D31A019C for ; Thu, 6 Mar 2014 03:33:39 -0800 (PST) Received: from [130.129.154.225] ([130.129.154.225]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MZwYd-1Wcled1aW7-00Lm7t; Thu, 06 Mar 2014 12:33:32 +0100 Message-ID: <53185D09.301@gmx.de> Date: Thu, 06 Mar 2014 12:33:29 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "scim@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:RQn/OgiMJf7lzTQg68kXfFQkAg88Vb69V2Yibg6tU2QIYuS0Rvq XxvB/aumYPA7KzzSEQ9ng02qICuffCHxs5/S2NdcLfb9XGxBxaveXrtk29s+E+5YSMqOls1 3Xzfoo02LAggaUeRilNF/QgjzV+Ayl/fFVYItxwg7MYHlMS8PTIzqeu1Re37h+SJv5CGoLU 5Rny1Ep0yWZNaeLzrtO7A== Archived-At: http://mailarchive.ietf.org/arch/msg/scim/bG1wLIBql8sJhjpLQYKND0tZlgE Subject: [scim] http://tools.ietf.org/html/draft-ietf-scim-api-03#section-3.9 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: Thu, 06 Mar 2014 11:33:41 -0000 Hi there, I still find it irritating that the spec lists a certain set of HTTP status codes clients "SHOULD" handle. Clients MUST handle status codes as per defined by HTTP. We have status code classes for the cases where a client doesn't know a specific one, so it can fallback to default behavior. It's ok to have *examples* of status codes clients are likely to see, and to give guidance to servers which one to sent. But that's different from just listing a few and pretending that there are no others. Best regards, Julian From nobody Thu Mar 6 04:19:05 2014 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 5BD631A027F for ; Thu, 6 Mar 2014 04:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 5nExpzAT-y18 for ; Thu, 6 Mar 2014 04:18:59 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 57BB11A0289 for ; Thu, 6 Mar 2014 04:18:54 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id mc6so1710060lab.13 for ; Thu, 06 Mar 2014 04:18:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Q7AD5GXvSYxruHe5FExYwd3xhoS5BFx54CkEwImBH1Q=; b=F8gT3+sGUA9ZJDB2k9vmh6MbieOntpPB0ABrzOdOJMqWf1p9dslgErUyKEbDVc8ZPz YeW/ykozXKnF/zNnApnwkbUEuAwyRDrVYUUCNycC/FMHx5l1WgYiQ8RvZN0U0Svnz9+r nDls5twE+s1sTJX3nwde8p9WTrNk8laN4artd9E/Nra2U62ouEhRXjRQkqoQ6AFtgWki tOZEEoBJSrXWbrGH9gYWmJIXRY/w1vaHZsLQ/rJmcO/LYF9MxNl9UpdeRkNNIf9VEb+B GRsNuI5tpUeht+BEp3ns6q6JxdZ66p/4BYvOfhZioJOB9lXAbM81dtmaBl5ZJPQnXnjo vMiQ== X-Gm-Message-State: ALoCoQn0PlDMDfXEdHoHEcEFG3VVGhUagrOtybuiglvKlNXCN9W+DSg5GViUSPWtkU8syjPbWtF/ X-Received: by 10.112.170.234 with SMTP id ap10mr7422342lbc.23.1394108329702; Thu, 06 Mar 2014 04:18:49 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:8d94:b54c:141:6613? ([2001:67c:370:160:8d94:b54c:141:6613]) by mx.google.com with ESMTPSA id r5sm1059587lbb.7.2014.03.06.04.18.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 04:18:48 -0800 (PST) Message-ID: <531867A7.5020509@mnt.se> Date: Thu, 06 Mar 2014 13:18:47 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: scim@ietf.org References: <53185B61.4000003@gmx.de> In-Reply-To: <53185B61.4000003@gmx.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/wNE4hG-aRXGNA2W9gJyBdn_-heY Subject: Re: [scim] draft-ietf-scim-api-03 vs RFC2616 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: Thu, 06 Mar 2014 12:19:01 -0000 On 2014-03-06 12:26, Julian Reschke wrote: > Hi there, > > the above mentioned draft still has references RFC 2616. However, RFC > 2616 has been obsoleted on Feb 12, so you really ought to reference > the new specs which are currently in the RFC Editor's Publication Queue. > > Best regards, Julian > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim Good catch - I've opened issue #66 to track this. From nobody Thu Mar 6 04:21:06 2014 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 31E591A0032 for ; Thu, 6 Mar 2014 04:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ne1PnBqtCmV7 for ; Thu, 6 Mar 2014 04:21:01 -0800 (PST) Received: from mail-bk0-f51.google.com (mail-bk0-f51.google.com [209.85.214.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4A43A1A0105 for ; Thu, 6 Mar 2014 04:21:01 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id 6so644310bkj.24 for ; Thu, 06 Mar 2014 04:20:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FZfyHDmEWkAdl+jUwotOrwOrpNsXqLteEmTGhodY+dw=; b=YImt31eszXsHa/JY+aropgasBwI11k+yzmJY4tHODd89neIDs2HXk8pKTXFo25u7BL OPO4ZYHG7yoVTufFTVmb/AWBexFRIh6l1SXkRi1+MqBmCxQaptJYXKCUM4G/KAJLJPnq +XO+L5h7a7czAzuW/35shY0FVMfWWDgxy9d+vbTUq4igKzAjTRa3FSlkT5K5LEc8+WUs F1QM9tS9QyWTXw8eBc99uTsQnt43EfsZA++KYHhei2yJYaYtT9wIFrLgo8GXpGQ6l91A M55YzPCgLXLE/biM7PXk0XDJ/0gM5tw+Eg37xQaQHbz/d0waYC3lSDp5NR7J03V54F04 jWPQ== X-Gm-Message-State: ALoCoQl4Z7FB5Z+nkDz9vwXIk6WtpEX/IYIu9ZaWwpAywGenzBK6JespNXvUD1oS/drsRabv4sCU X-Received: by 10.205.44.134 with SMTP id ug6mr253450bkb.124.1394108456568; Thu, 06 Mar 2014 04:20:56 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:8d94:b54c:141:6613? ([2001:67c:370:160:8d94:b54c:141:6613]) by mx.google.com with ESMTPSA id p5sm8811325bkh.1.2014.03.06.04.20.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 04:20:55 -0800 (PST) Message-ID: <53186826.5080802@mnt.se> Date: Thu, 06 Mar 2014 13:20:54 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: scim@ietf.org References: <53185D09.301@gmx.de> In-Reply-To: <53185D09.301@gmx.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/zrnoU-ZeojjlpAL27iiaM3s69zM Subject: Re: [scim] http://tools.ietf.org/html/draft-ietf-scim-api-03#section-3.9 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: Thu, 06 Mar 2014 12:21:04 -0000 On 2014-03-06 12:33, Julian Reschke wrote: > Hi there, > > I still find it irritating that the spec lists a certain set of HTTP > status codes clients "SHOULD" handle. > > Clients MUST handle status codes as per defined by HTTP. We have > status code classes for the cases where a client doesn't know a > specific one, so it can fallback to default behavior. > > It's ok to have *examples* of status codes clients are likely to see, > and to give guidance to servers which one to sent. But that's > different from just listing a few and pretending that there are no > others. > > Best regards, Julian > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim I've created issue 67 to track this From nobody Thu Mar 6 04:29:04 2014 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 C4DB61A0046 for ; Thu, 6 Mar 2014 04:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 tXi9bERN9yQq for ; Thu, 6 Mar 2014 04:28:58 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8851F1A0034 for ; Thu, 6 Mar 2014 04:28:58 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s26CSqFI024312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Mar 2014 12:28:52 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s26CSpLY000047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2014 12:28:51 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s26CSpi0023324; Thu, 6 Mar 2014 12:28:51 GMT Received: from [130.129.159.48] (/130.129.159.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Mar 2014 04:28:51 -0800 References: <53185D09.301@gmx.de> Mime-Version: 1.0 (1.0) In-Reply-To: <53185D09.301@gmx.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B651) From: Phil Hunt Date: Thu, 6 Mar 2014 12:28:50 +0000 To: Julian Reschke X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/khLNxJaA3d80By6828_1q5H1uqY Cc: "scim@ietf.org WG" Subject: Re: [scim] http://tools.ietf.org/html/draft-ietf-scim-api-03#section-3.9 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: Thu, 06 Mar 2014 12:29:02 -0000 There are items that are still being cleaned up from the external scim 1 dra= fts to match IETF editorial styles.=20 In this case at least some of table is more of an FYI and maybe should be ex= pressed in non-normative language. Only when we are specifically profiling h= ttpbis should the language be normative IMHO.=20 Also. I plan update references to httpbis in next draft. Though i don't thin= k the intent is to require httpbis. Comments from the group? Phil > On Mar 6, 2014, at 11:33, Julian Reschke wrote: >=20 > Hi there, >=20 > I still find it irritating that the spec lists a certain set of HTTP statu= s codes clients "SHOULD" handle. >=20 > Clients MUST handle status codes as per defined by HTTP. We have status co= de classes for the cases where a client doesn't know a specific one, so it c= an fallback to default behavior. >=20 > It's ok to have *examples* of status codes clients are likely to see, and t= o give guidance to servers which one to sent. But that's different from just= listing a few and pretending that there are no others. >=20 > Best regards, Julian >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Thu Mar 6 04:41:16 2014 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 2B8E11A025D for ; Thu, 6 Mar 2014 04:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ZQMTxDdoFg-M for ; Thu, 6 Mar 2014 04:41:11 -0800 (PST) Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com [209.85.214.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1272C1A022E for ; Thu, 6 Mar 2014 04:41:10 -0800 (PST) Received: by mail-bk0-f45.google.com with SMTP id na10so669880bkb.4 for ; Thu, 06 Mar 2014 04:41:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JDDK1ZDX5i0MwG0QZoFDbWk8uI/vbj+KuFD0H30JqOw=; b=eGT4KpYQFRQRWCr6ZbrQ4f+wFu6FFenfL7ovTt62Auyrf81Ko7uSeZObFxtIKwTE7R 7UAZRWKzLkrUPhe9g98DG54A9XLo5QhE2lSadDMr/D7sVriS/z8eEnNi8vQhM1HqFzhB RpD+gXJGGzIhHItlXMbNyjZHFqQu4oq7vxRyjIjjanuque/UMZXI8ppN+2Lms1idhUp2 UhsItRjiop8x/HL8KsIMUZtxzLaeKS/I+mWmyxhqPNMAPVI1X+Zv1dInaUwlbC8y7ZLM bZsxfXyGsNMA1tXKMm+LFLUWlnx5xFTfLu7jL4266uvDwP6I/HhEceBHZrkaQKWnahG5 lXQw== X-Gm-Message-State: ALoCoQnGgvuiGXrYmjFTVIqaN74MAN2WQz3jw38PtaOhVpACQSj/xyRghUqpGZgnYknqWYO+wlKg X-Received: by 10.204.104.193 with SMTP id q1mr3636402bko.6.1394109666539; Thu, 06 Mar 2014 04:41:06 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:8d94:b54c:141:6613? ([2001:67c:370:160:8d94:b54c:141:6613]) by mx.google.com with ESMTPSA id bh9sm9036479bkb.16.2014.03.06.04.41.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 04:41:05 -0800 (PST) Message-ID: <53186CE0.4080802@mnt.se> Date: Thu, 06 Mar 2014 13:41:04 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: scim@ietf.org References: <53185D09.301@gmx.de> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/1p_oa8ktJYKEuQW957iN89MpRB0 Subject: Re: [scim] http://tools.ietf.org/html/draft-ietf-scim-api-03#section-3.9 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: Thu, 06 Mar 2014 12:41:13 -0000 On 2014-03-06 13:28, Phil Hunt wrote: > There are items that are still being cleaned up from the external scim 1 drafts to match IETF editorial styles. > > In this case at least some of table is more of an FYI and maybe should be expressed in non-normative language. Only when we are specifically profiling httpbis should the language be normative IMHO. > > Also. I plan update references to httpbis in next draft. Though i don't think the intent is to require httpbis. Comments from the group? >From a procedural standpoint I don't think we should hang on httpbis. > > Phil > >> On Mar 6, 2014, at 11:33, Julian Reschke wrote: >> >> Hi there, >> >> I still find it irritating that the spec lists a certain set of HTTP status codes clients "SHOULD" handle. >> >> Clients MUST handle status codes as per defined by HTTP. We have status code classes for the cases where a client doesn't know a specific one, so it can fallback to default behavior. >> >> It's ok to have *examples* of status codes clients are likely to see, and to give guidance to servers which one to sent. But that's different from just listing a few and pretending that there are no others. >> >> Best regards, Julian >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Thu Mar 6 05:02:23 2014 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 6A69A1A004C for ; Thu, 6 Mar 2014 05:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 nPrlVQhf502A for ; Thu, 6 Mar 2014 05:02:18 -0800 (PST) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7AADB1A026A for ; Thu, 6 Mar 2014 05:02:18 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id jz11so2510889veb.39 for ; Thu, 06 Mar 2014 05:02:14 -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=qMwxhgb5MIu62HvHBYndO1E6xh58/idGSyDfs2UeNg0=; b=uJcZZ8CzNRxbDKqpiaUy+Zb6lwqnRNR2Oe4FIm/b77MyB9MZVYfrm98QZRBV2CaBhm JOPvZuAW0fY9mhrKB4TJ8aH1wlCLbTTKKmx8yPv98iljnzHhxYHd+ydzXPFmJ/VLpyNO fPAiMZRK22y8j/AP1Lm4hThas7Z7WkV1SKwcKrXqzobdEpXYcZRbb9FR4WUiWAwFONAt Tya5oQi4LihJljDE2kcqsjWLiYa8l/KZe38HwNzf6r7XjxUXFbhqDeb+OBI1IlHE02PY s95mKNNk3ZqOo6vkdb4ET+xy7I8Ge66HaMHukO3I+QsyFJAjSe7R4A7ytAG94VWth3fp lfPg== MIME-Version: 1.0 X-Received: by 10.221.55.133 with SMTP id vy5mr4974143vcb.17.1394110934376; Thu, 06 Mar 2014 05:02:14 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.19.104 with HTTP; Thu, 6 Mar 2014 05:02:14 -0800 (PST) In-Reply-To: <53186CE0.4080802@mnt.se> References: <53185D09.301@gmx.de> <53186CE0.4080802@mnt.se> Date: Thu, 6 Mar 2014 13:02:14 +0000 X-Google-Sender-Auth: Cuvohf7JHtZvjGS4Y3c7L0KQUIE Message-ID: From: Barry Leiba To: Leif Johansson Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ZrMzwH3hskdvFQUE8hH2mIz-VCc Cc: "scim@ietf.org" Subject: Re: [scim] http://tools.ietf.org/html/draft-ietf-scim-api-03#section-3.9 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: Thu, 06 Mar 2014 13:02:19 -0000 >> Also. I plan update references to httpbis in next draft. Though >> I don't think the intent is to require httpbis. Comments from the group? > > From a procedural standpoint I don't think we should hang on httpbis. No delay issues here any more: the httpbis docs are all in the RFC Editor queue, and should be RFCs by the end of April. Barry From nobody Thu Mar 6 05:18:23 2014 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 BFE731A02E8 for ; Thu, 6 Mar 2014 05:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 DIXv_6JicrLJ for ; Thu, 6 Mar 2014 05:18:13 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A1FEF1A025E for ; Thu, 6 Mar 2014 05:18:05 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s26DHx5e011737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Mar 2014 13:18:00 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s26DHvkO011564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2014 13:17:58 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s26DHvE5000777; Thu, 6 Mar 2014 13:17:57 GMT Received: from [31.133.163.210] (/31.133.163.210) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Mar 2014 05:17:57 -0800 References: <53185D09.301@gmx.de> <53186CE0.4080802@mnt.se> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3CF20A2C-44A3-481B-8E6F-44E430454218@oracle.com> X-Mailer: iPhone Mail (11B651) From: Phil Hunt Date: Thu, 6 Mar 2014 13:17:56 +0000 To: Barry Leiba X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/9wZvcj5qVUJzFcavqtj9FYpFl1A Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] http://tools.ietf.org/html/draft-ietf-scim-api-03#section-3.9 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: Thu, 06 Mar 2014 13:18:18 -0000 What is the best way to say httpbis is not a requirement and scim may be imp= lemented on existing http 1.1 (2616) servers? Ps. I understand that the intent here is to get people to update as was happ= ening with TLS.=20 Phil On Mar 6, 2014, at 13:02, Barry Leiba wrote: >>> Also. I plan update references to httpbis in next draft. Though >>> I don't think the intent is to require httpbis. Comments from the group?= >>=20 >> =46rom a procedural standpoint I don't think we should hang on httpbis. >=20 > No delay issues here any more: the httpbis docs are all in the RFC > Editor queue, and should be RFCs by the end of April. >=20 > Barry >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Thu Mar 6 05:21:13 2014 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 9EAC31A0249 for ; Thu, 6 Mar 2014 05:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 QboavHpFll6U for ; Thu, 6 Mar 2014 05:21:00 -0800 (PST) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 91EFA1A025D for ; Thu, 6 Mar 2014 05:21:00 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id m5so2387485qaj.21 for ; Thu, 06 Mar 2014 05:20:56 -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=ckHHgP94nLIwQGAV8F1x9b4MvX9++Rjl3CgkELf44zg=; b=w6L4HXhkwkGxgac+mEGS5rnL1Aqm2ruvw1uU2FmTyTNFbQBf6oTHPU5MGzW6QugdLn vfsQFPNPMUhjtzvzZo+t2HMzDwgMWD5XeuA7KtIjA3vQoHSgdXp89RVlzLkPv6V3MZu8 ZxV7/XMqwtvPMcsPhs+R3vcV2dQMUAIj2O0Evq9Fkvq/NBhBVrDKF1epCus44leJUT5B 0fUlT+H1kk3peqyFEN85kh9mcwK3sdbXk8w1NN2TQA9q5NDXPrBQPNeNx3orF97vshLL jik4C+c2/t7xc9/uZWRRaHCa9S4/pJNoD86Viy3BquAO9o5Aa70HeKOQdZhdwGx3FxkY RJWw== MIME-Version: 1.0 X-Received: by 10.140.30.230 with SMTP id d93mr12796885qgd.51.1394112056588; Thu, 06 Mar 2014 05:20:56 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.224.26.11 with HTTP; Thu, 6 Mar 2014 05:20:56 -0800 (PST) In-Reply-To: <3CF20A2C-44A3-481B-8E6F-44E430454218@oracle.com> References: <53185D09.301@gmx.de> <53186CE0.4080802@mnt.se> <3CF20A2C-44A3-481B-8E6F-44E430454218@oracle.com> Date: Thu, 6 Mar 2014 05:20:56 -0800 X-Google-Sender-Auth: WNY2K5a1RX1ix0HD1Wsmj49KPko Message-ID: From: Barry Leiba To: Phil Hunt Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/vjhcO0JgQUqx-GTEn4A44NGVAts Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] http://tools.ietf.org/html/draft-ietf-scim-api-03#section-3.9 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: Thu, 06 Mar 2014 13:21:01 -0000 > What is the best way to say httpbis is not a requirement and scim > may be implemented on existing http 1.1 (2616) servers? There's no need to say it at all. You simply say that you use HTTP, and you give the reference to the httpbis p1 doc. Say nothing about versions at all. Barry From nobody Thu Mar 6 05:26:52 2014 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 99E0A1A019C for ; Thu, 6 Mar 2014 05:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Vruc_aO83WtP for ; Thu, 6 Mar 2014 05:26:48 -0800 (PST) Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com [209.85.214.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8B97D1A00A9 for ; Thu, 6 Mar 2014 05:26:48 -0800 (PST) Received: by mail-bk0-f45.google.com with SMTP id na10so685045bkb.4 for ; Thu, 06 Mar 2014 05:26:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DVk5pdN7F6xX4537/6WrINfQcHWQdghFMHAdRuLSQg8=; b=lwZ+kEXmGneiRkeNedzjSQRZrK00r1dDCPhueIiaDkcSTvtOwBqL9oJZLpEOp+XmCq JFSWdrv0MV7nhoxAskINpsmncBZVeWIiCtx1Myk/2EO/5bVDbX1a1jQ4ieJgwuFGbfX3 a5ImzeP9idHyIOzXEIVoKK48++H601euN26Th4k7nvDYWwvJTP1LXxRsRj51qgWtGXTR aF1GQzPqtH/I5P6JZdFKmah9UejK7RBIb295xoj5BQ+59fg9TUbvZRc4LZSocOHmbLhy 3SqfegwmyICBoCYCL9KAoKtjmccGuel7t/V2tb7Sp+S/naqAkWpZuA/mUBq7pzkYBFf3 pr+w== X-Gm-Message-State: ALoCoQmfuc62tNQunjFO0BdZ3jndE0735jgF539vaa0TGqmD/ZWQQNKKZkMz+UhM2BJGuicrA80N X-Received: by 10.204.96.205 with SMTP id i13mr3550708bkn.20.1394112404073; Thu, 06 Mar 2014 05:26:44 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:8d94:b54c:141:6613? ([2001:67c:370:160:8d94:b54c:141:6613]) by mx.google.com with ESMTPSA id xj2sm9250353bkb.15.2014.03.06.05.26.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 05:26:43 -0800 (PST) Message-ID: <53187792.4050807@mnt.se> Date: Thu, 06 Mar 2014 14:26:42 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Barry Leiba References: <53185D09.301@gmx.de> <53186CE0.4080802@mnt.se> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/DXyvLBCy1MsIOshs5V_Jk5XuvZE Cc: "scim@ietf.org" Subject: Re: [scim] http://tools.ietf.org/html/draft-ietf-scim-api-03#section-3.9 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: Thu, 06 Mar 2014 13:26:50 -0000 On 2014-03-06 14:02, Barry Leiba wrote: >>> Also. I plan update references to httpbis in next draft. Though >>> I don't think the intent is to require httpbis. Comments from the group? >> From a procedural standpoint I don't think we should hang on httpbis. > No delay issues here any more: the httpbis docs are all in the RFC > Editor queue, and should be RFCs by the end of April. > > Barry ok fine but there are deployment issues to consider... From nobody Thu Mar 6 05:27:17 2014 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 783241A00A9 for ; Thu, 6 Mar 2014 05:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 jgNs_W47-gHs for ; Thu, 6 Mar 2014 05:27:14 -0800 (PST) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by ietfa.amsl.com (Postfix) with ESMTP id 26CD11A0282 for ; Thu, 6 Mar 2014 05:27:13 -0800 (PST) Received: by mail-bk0-f48.google.com with SMTP id mx12so663715bkb.7 for ; Thu, 06 Mar 2014 05:27:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NfkAs8PKQxrp7YEsnvGJmhbaW22mMjYoKC0UwlgC9h4=; b=L7GTJP5kRAlDBCMz/+KHURSvvXKJ28fqgOD0AKD5BCvj5f6hg+ZCMphq5gHIT8lMj4 A7mTPAlfAtU/oS8VridIalcj498C+51sHkAqIqP0TyfzkClc4Tcg0T2CTrGiRCZG3VJt VTRqBM+4TEcIvw286FD09G+SW94koXTeJMCYPCnWfuM6a+uLlPKBN6PwL0v5Jev5q1hj Y8O0ohRwdDcDAZTLuQHe26rSlWuT16bK6+RxOpn147A318nnaSlo725IjoWYKi/MFcO9 goMI7DgH4cEjsDTAGdLTTz9RiC0ffo/wY0ar1bX4geBoawl9wbqcwoKavbIJU3HgjhJt i2Sg== X-Gm-Message-State: ALoCoQn+34CCi+mYER3hdgCeuEfS8+ipJTfkkKg4IU/l7axEMuLrXJh0x8pbDc+J0uaFi6qN6bXs X-Received: by 10.204.97.68 with SMTP id k4mr334395bkn.56.1394112429636; Thu, 06 Mar 2014 05:27:09 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:8d94:b54c:141:6613? ([2001:67c:370:160:8d94:b54c:141:6613]) by mx.google.com with ESMTPSA id bh9sm9270103bkb.16.2014.03.06.05.27.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 05:27:08 -0800 (PST) Message-ID: <531877AC.8050105@mnt.se> Date: Thu, 06 Mar 2014 14:27:08 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Barry Leiba , Phil Hunt References: <53185D09.301@gmx.de> <53186CE0.4080802@mnt.se> <3CF20A2C-44A3-481B-8E6F-44E430454218@oracle.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/CD2DToGHY5674LMrGhkgO9b3SIk Cc: "scim@ietf.org" Subject: Re: [scim] http://tools.ietf.org/html/draft-ietf-scim-api-03#section-3.9 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: Thu, 06 Mar 2014 13:27:16 -0000 On 2014-03-06 14:20, Barry Leiba wrote: >> What is the best way to say httpbis is not a requirement and scim >> may be implemented on existing http 1.1 (2616) servers? > There's no need to say it at all. You simply say that you use HTTP, > and you give the reference to the httpbis p1 doc. Say nothing about > versions at all. > > Barry ok in that case it makes sense From nobody Thu Mar 6 05:46:17 2014 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 142001A0141 for ; Thu, 6 Mar 2014 05:46:13 -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 hVwMjLkIUGMH for ; Thu, 6 Mar 2014 05:46:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0771A020D for ; Thu, 6 Mar 2014 05:46:10 -0800 (PST) Received: from [31.133.164.112] ([31.133.164.112]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MUoma-1WgK6H05IC-00YAna; Thu, 06 Mar 2014 14:46:01 +0100 Message-ID: <53187C13.5060309@gmx.de> Date: Thu, 06 Mar 2014 14:45:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Leif Johansson , Barry Leiba References: <53185D09.301@gmx.de> <53186CE0.4080802@mnt.se> <53187792.4050807@mnt.se> In-Reply-To: <53187792.4050807@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:EMl85ehNl+a4H7YP8euTBFz4IYHOQ0gEMt799z97bYFP8TdXAWx b0r5JzMh9vnj424bmRhMhk6DeQsT3YWJOFtVFPfgaUg3KMGZyA25XAhX4iao1OnpzADRX6z TkEEu4qbrUgu33SNjjbsAeEa0W/uBpsSwdcEExqvG628Hx9647xLVNpAhEOdz73Q14kv735 2omZuEuaxd01KDrtubr6w== Archived-At: http://mailarchive.ietf.org/arch/msg/scim/catzWRuq3s8y24yTK4iQD4JjX8U Cc: "scim@ietf.org" Subject: Re: [scim] http://tools.ietf.org/html/draft-ietf-scim-api-03#section-3.9 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: Thu, 06 Mar 2014 13:46:13 -0000 On 2014-03-06 14:26, Leif Johansson wrote: > On 2014-03-06 14:02, Barry Leiba wrote: >>>> Also. I plan update references to httpbis in next draft. Though >>>> I don't think the intent is to require httpbis. Comments from the group? >>> From a procedural standpoint I don't think we should hang on httpbis. >> No delay issues here any more: the httpbis docs are all in the RFC >> Editor queue, and should be RFCs by the end of April. >> >> Barry > ok fine but there are deployment issues to consider... There shouldn't be any deployment issues. Care to elaborate? (Note this is still HTTP/1.1) Best regards, Julian From nobody Thu Mar 6 08:42:14 2014 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 394081A0086 for ; Thu, 6 Mar 2014 08:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Y1uJ6N3IQZHa for ; Thu, 6 Mar 2014 08:42:11 -0800 (PST) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id 363631A00EC for ; Thu, 6 Mar 2014 08:42:11 -0800 (PST) Received: by mail-bk0-f42.google.com with SMTP id mx12so751831bkb.29 for ; Thu, 06 Mar 2014 08:42:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4Al7qDuyph+96IK9dQPnD1eIAvWgXgfSjoq17JMbxb8=; b=Mjgq7LuFuZRnw73hLA25rPxU0twgX744W93IUHkQxv38Ll1j2PS80HUHQ/DnelpqyA zEKiUWE7sG+Nt2yNQuT5VhP0HYZ/H4XiP1nb1nzuRbH2nIjGAShmzslmLXeXq0IVWsnt Kfxc/FWmEgLNsbeOABPl1UEt63XM6UozE1xs2EOfPtvjGeY3IMToL74i1v8DXshaoET7 35HhOv8wXyOcc93rLw1ZlpZGU9rU2ffzh1aJFgd5HrNxQqpKX46U0BQlFJu7OTaikn0x JCv6OQud7gpBuudF7mM+b1f1WbREzd/Jbls+OREd1t1vgUCyNi4Ae2EQAWyBeqrhj/bD DJog== X-Gm-Message-State: ALoCoQndcoqkvDMWkT5iXYPFB1Rf0p6eqZio3aQIgKB2XD48M2bRBkufs/av+K9dI42ipH63Kfs2 X-Received: by 10.205.76.199 with SMTP id zf7mr3842804bkb.22.1394124126641; Thu, 06 Mar 2014 08:42:06 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:8d94:b54c:141:6613? ([2001:67c:370:160:8d94:b54c:141:6613]) by mx.google.com with ESMTPSA id rf10sm10009390bkb.3.2014.03.06.08.42.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 08:42:05 -0800 (PST) Message-ID: <5318A55D.1010706@mnt.se> Date: Thu, 06 Mar 2014 17:42:05 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Julian Reschke , Barry Leiba References: <53185D09.301@gmx.de> <53186CE0.4080802@mnt.se> <53187792.4050807@mnt.se> <53187C13.5060309@gmx.de> In-Reply-To: <53187C13.5060309@gmx.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Erq6Wv0yOyQcuWGtShYufO48cew Cc: "scim@ietf.org" Subject: Re: [scim] http://tools.ietf.org/html/draft-ietf-scim-api-03#section-3.9 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: Thu, 06 Mar 2014 16:42:13 -0000 On 2014-03-06 14:45, Julian Reschke wrote: > On 2014-03-06 14:26, Leif Johansson wrote: >> On 2014-03-06 14:02, Barry Leiba wrote: >>>>> Also. I plan update references to httpbis in next draft. Though >>>>> I don't think the intent is to require httpbis. Comments from the >>>>> group? >>>> From a procedural standpoint I don't think we should hang on httpbis. >>> No delay issues here any more: the httpbis docs are all in the RFC >>> Editor queue, and should be RFCs by the end of April. >>> >>> Barry >> ok fine but there are deployment issues to consider... > > There shouldn't be any deployment issues. Care to elaborate? > > (Note this is still HTTP/1.1) > > Best regards, Julian > yep, barry explained that in a separate email, we're good From nobody Thu Mar 6 12:36:57 2014 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 A66371A0160 for ; Thu, 6 Mar 2014 12:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.046 X-Spam-Level: X-Spam-Status: No, score=-4.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, GB_I_INVITATION=-2, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 6CTVRUsDwgtW for ; Thu, 6 Mar 2014 12:36:53 -0800 (PST) Received: from nm36-vm2.bullet.mail.bf1.yahoo.com (nm36-vm2.bullet.mail.bf1.yahoo.com [72.30.238.138]) by ietfa.amsl.com (Postfix) with ESMTP id 77D561A00B4 for ; Thu, 6 Mar 2014 12:36:53 -0800 (PST) Received: from [98.139.212.153] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 06 Mar 2014 20:36:49 -0000 Received: from [98.139.212.233] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 06 Mar 2014 20:36:49 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 06 Mar 2014 20:36:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 394716.32134.bm@omp1042.mail.bf1.yahoo.com Received: (qmail 28403 invoked by uid 60001); 6 Mar 2014 20:36:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394138209; bh=17mv/UYMEGS+yq7qBza79t1PBjzQmzpsT3oIq069czE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6wMz8LRWYloNKi/ndc5y5oFXM0CzN+g+QV7E8HGWxPw0N2dNhaLca72AQI/Tyh36szO6zF77Pef8WKlsHDFExDBZBFstMd7TaQwh9a3dHslIMEtHEp7zBPTbjGwWNtdWba3hvZonAor4LStcT2jZTeFqREFyIQyJmt6cI/SR9Xw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wdseIBsHYqYv7RvLGdXhgXaQfJpkfqZWTSmrlOHPbqbVyNINXwTIe9YUWjnAJzGy0jG7nI1FPWn1Eb3A+gRJyhTKa6t1lNoNYAzgn1gKwWmncqRVXOZ7WSwslaPZZq1hXHaSqSpVsDkOfrCTfQbj43TNDH6BRj2Bs0OWpOoDajg=; X-YMail-OSG: .meURZ0VM1mf4EakeuM8ZQyJNDn.AJQk0X.osHztvvoCyGk gSM4At_1rykylpRR0KfQ4j1Rb2K9ldzHSEXyrhbNono8sElCnFY0Uu.yQuEN tcf.VafRPFNrDI0bCpDbYXzeGry93IM5s.n7ocm9SzxzXtxuD4opECxgIKuO qp9EiOt75VWTtFeaMI0lZh6BIVFG.r7ui3pmkoIgV3dsAFr2ys8HRBKWcVME w.emOiL3BRBJwzJ4J7p_vnKP3SfDWvH_moFZNEXmVsQz7Zmtdp5rVb4yTrQe m3Ixyny6scQ5hokmrcACZ5wazbrgCAEo.QDfmOwIF1vTn5Z99w3hSApgssEj SldZwOyWybx90Nz7uV6PA4QlTEtBRocMIjGxzv9qEV.oIlOXfpSMsaTZTsJf x8gohqkNsWW4H2sq_KySt7qgfrPlbgujZC02vDQBMOZyrU4WLxLQOiua8lG4 bn0PUy8dV8Ge.LO5X8SriWmMu5oPEq1Mcj7bv4GaC8UpUKdKT3JTP.8Jjepe LJ0Fo2geeaqhk8PFjNvcd3MyKkwvbJeJ62XJDbfdZHfkwLu5YJs89FRh1qYV eQP7BFTolW0BfJFKUfeiQWf_8jA-- Received: from [209.131.62.115] by web142805.mail.bf1.yahoo.com via HTTP; Thu, 06 Mar 2014 12:36:49 PST X-Rocket-MIMEInfo: 002.001, VXNlIENhc2VzIGRyYWZ0OiBLLiBMZWUgKG5hbWUgYXBwcm94aW1hdGUpCi1uZXcgZHJhZnRzIHVwLiDCoERlZmluaXRlbHkgbmVlZCByZXZpZXdlcnMuIMKgIk5vbiBhdXRob3IgcmV2aWV3ZXJzIHNwZWNpZmljYWxseSIuIMKgTWlrZSBKb25lcyBhbmQgQmlsbCBNaWxscyByYWlzZWQgaGFuZHMuCi1ubyBzaWduaWZpY2FudCBkaXNjdXNzaW9uIGluIHRoZSByb29tLgoKVkNhcmQgbWFwcGluZzogwqBCZXJ0IEcuCi1EcmFmdCBzZWVtcyB0byBiZSBzdGFiaWxpemluZy4gwqBVcGRhdGVkIHRvIG1hdGNoIGxhdGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: Message-ID: <1394138209.71484.YahooMailNeo@web142805.mail.bf1.yahoo.com> Date: Thu, 6 Mar 2014 12:36:49 -0800 (PST) From: Bill Mills To: "scim@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/scim/QA_rZX5xCMa-GWVyVxMP8QX6g-Q Subject: [scim] Meeting notes for 3/6 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 20:36:55 -0000 Use Cases draft: K. Lee (name approximate)=0A-new drafts up. =A0Definitely = need reviewers. =A0"Non author reviewers specifically". =A0Mike Jones and B= ill Mills raised hands.=0A-no significant discussion in the room.=0A=0AVCar= d mapping: =A0Bert G.=0A-Draft seems to be stabilizing. =A0Updated to match= latest related rafts.=0A-new mandatory foelds for this.=0A-new plurals syn= tax needed.=0A-he's generally following the slides here.=0A-Significant que= stion for SCIM itself, is the character set restricted to numbers?=0A=0A-Mo= rteza asking explicity for additional reviewers, silence in the room.=0A-su= ggestion that the VCard mailing list (WG not active any more) might get som= e interest.=0A=0A"Now we'll spend the rest of the meeting on open issues...= ."=0A=0APhil Hunt at the mike:=0A-A review of recent history. =A0Following = the slides he has.=0A-discussion of 307 & 308 HTTP response codes.=0A-SCIM = Patch=0A-Why not JSON patch? =A0Discussion=0A=0A-because SCIM is not array = indexed.=0A-Possible concurrency or object sync issues.=0A-Proposal: =A0use= 6902 but a subset (perhaps subset of 6901)=0A-JSON Merge Patch is interest= ing=0A-but it doesn't have an add capability...=0A-this is interesting thou= gh.=0A-Still problems with complex attriutes=0A... running through his slid= e/examples pretty much verbatim=0A-Question from Justin Richer: =A0on atomi= city...=0A-clarified by Phil and Morteza=0A-Nat Samimura: This is an import= ant architectural change=0A-Phil: we do this now though, so it's not quite = as different as you think.=0A-Phil: =A0our own developers have been confuse= d as well.=0A-Justin Richer: Are these verbs only in PATCH? =A0Yes. =A0Agre= es with Nat that this is NOT RESTful.=0A-Phil: hasn't seen consistency rega= rding patch.=0A=0A(more general conversation and I don't type fast enough)= =0A=0A-Julian feels this *is* RESTful.=0A=0A(more general conversation and = I don't type fast enough)=0A=0A-Generally not a lot of love in the room for= JSON merge/patch=0A=0ARunning through the issues list now in the IETF issu= e tracker. =A0Phil asking for specific support of issues in the list. =A0It= 's a long wish list and we need to know if there is real support for the th= ings that are enhancements.=0A=0AMany of these may carry over from the SCIM= 1 days on the Google tracker.=0A=0ARoom Hum: generally a YES on taking all= extensions and closing them WONTFIX with the invitation to folks that feel= strongly to propose a new draft to extend/define them.=0A=0ATentative cons= ensus for closing #6.=0A=0AOn #30=0A-Morteza thinks the IANA registry consi= derations must be addressed.=0A-retarget it at the Schema doc=0A-HUM: =A0sh= ould a registry be a separate draft with just stub language in the draft? = =A0Apathy in the room.... we'll take it to the list.=0A=0AOn #43:=0A-Erik p= refers this to simplify things.=0A-from the chair, if we do #43 then #36 is= easy/done=0A-HUM says yes.=0A=0AOn #36:=0A-based on the above will close.= =0A=0AOn #45:=0A-several comments that this probably needs to go.=0A-a part= ial mapping might work, but not a full mapping...=0A-Morteza: if there's no= action on this in 4 months he will ask to drop it from the charter.=0A=0AO= n #37:=0A-=0A=0ABarry at the mic:=0A=0A-Think about the JOSE WG output and = perhaps review it. =A0You're JSON based so it might me useful.=0A-Take a lo= ok at Mark Nottingham's "Get off my lawn" doc. =A0This draft is reserving r= oot URLs which is probably a bad practice.=0A-Morteza+chair: this wasn't in= tended to be absolute URLs. =A0This confusion is improtant, so we shoudl co= rrect the language to make this clearer.=0A=0AJulian R.: =A0The header fiel= d in 4.1.3 implies IANA considerations. =A0It also kills the RESTfulness,= =0A=0A(more conversation and I don't type fast enough)=0A=0A=0AOn #65: Phil= "Do we need overrides?"=0A-Julian: several reasons we might need this.=0A-= If tis is the first IETF draft that uses the override header we really need= to make sure we're right.=0A-Erik W.: on Jabber "I think the fact that it'= s used by existing APIs show that X-HTTP-Method-Override is needed in some = cases."=0A-We'll take this to the list.=0A=0AEND=0A From nobody Sat Mar 8 13:26:46 2014 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 5B2E71A02FB for ; Sat, 8 Mar 2014 13:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 nOhbwQ8IJfyR for ; Sat, 8 Mar 2014 13:26:41 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2B27D1A02EA for ; Sat, 8 Mar 2014 13:26:40 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id mc6so3702225lab.36 for ; Sat, 08 Mar 2014 13:26:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=qGQyPcTidP3Grm2mUhhQf2GKpZq2hAlX2CP+HIsPsQk=; b=aXWuGslVrl4yYeEIKyYWZYOuDHQJtQBaAoqQft9zAhOV1N7+jb4acDLXIpsNT8/04x mMSCaUlrNuUoThlhFMU75j8zpos+o/wSijiy/JmgSZRTw0ksqeZhzeuxZd/ebcoyaPwA DWqX6e4D72Hbic2wD/1pEOoX/CjeHxnVZG/Xo3hBipzOLTo6DYrf8EMaG+ruEDhHUzFy au1hKzvGruAFh9reogMW1Hd8ZdojDLZYWPHqji5oSCQWF5Q50mMrl/RpWOOfq10iwjVT oIy9Gta4TEoBtkcukGrpu5i/XqiWVCMi1V4HzisGvenSvrI1tKfR47ZXv1zJ61Z8oYRO 23cQ== X-Gm-Message-State: ALoCoQkp/QFn+LRSnxhQXC8s+RkjJ8mHjUxvq3eU0lEvsUN3/PGhCd3GTlAlKeESuAzqIBBhETYF X-Received: by 10.112.161.133 with SMTP id xs5mr52069lbb.51.1394313995815; Sat, 08 Mar 2014 13:26:35 -0800 (PST) Received: from [10.0.0.115] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id zf7sm21486168lab.7.2014.03.08.13.26.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Mar 2014 13:26:34 -0800 (PST) Message-ID: <531B8B0F.6000800@mnt.se> Date: Sat, 08 Mar 2014 22:26:39 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "scim@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/IUgebWKnLuHp9vvq0wbpFxS0rRs Subject: [scim] consensus call on moving issues to extension drafts 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: Sat, 08 Mar 2014 21:26:43 -0000 At the London meeting there was strong consensus for identifying the issues that are represent proposed extensions to the core specifications and do the following: 1. Close the issue with "no-fix" 2. Encourage anyone to write a draft describing the extended functionality. Such drafts can either be processed as individual submissions or considered as part of a possible re-charter discussion in the WG when the core documents are done. The following issues have been identified: #11 - Define a very simple language for entitlements #14 - Enhance password and login metadata #15 - Add specification for soft delete and reanimation operation as an extension of core spec #20 - Insert a "person" resource into the model (schema) #32 - Async / Workflow Support In addition the following issues will also be closed as they do not represent issues of the core specifications. Note that these issues remain as milestones in our existing charter until the ADs say otherwise. #4 - Bring the SAML binding up-to-date #45 - LDAP mapping Given the support this had in London we are looking for anyone that disagrees with this plan. Cheers Leif & Morteza From nobody Mon Mar 10 01:53:16 2014 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 D73321A03FB for ; Mon, 10 Mar 2014 01:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, 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 wajQQyivJZD9 for ; Mon, 10 Mar 2014 01:53:12 -0700 (PDT) Received: from mailserver.daasi.de (mailserver.daasi.de [178.63.152.251]) by ietfa.amsl.com (Postfix) with ESMTP id 141E11A03FA for ; Mon, 10 Mar 2014 01:53:12 -0700 (PDT) Received: by mailserver.daasi.de (Postfix, from userid 1001) id 01B0A401810; Mon, 10 Mar 2014 09:53:05 +0100 (CET) Received: from [195.169.109.91] (unknown [195.169.109.91]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: peter.gietz@daasi.de) by mailserver.daasi.de (Postfix) with ESMTPSA id A2722401783 for ; Mon, 10 Mar 2014 09:53:04 +0100 (CET) Message-ID: <531D7D6F.60204@daasi.de> Date: Mon, 10 Mar 2014 09:53:03 +0100 From: Peter Gietz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: scim@ietf.org References: <531B8B0F.6000800@mnt.se> In-Reply-To: <531B8B0F.6000800@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/WZ6uTLNc-KOHDy9HqpKAq8NnrK0 Subject: Re: [scim] consensus call on moving issues to extension drafts 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: Mon, 10 Mar 2014 08:53:15 -0000 Am 08.03.2014 22:26, schrieb Leif Johansson: > At the London meeting there was strong consensus for identifying the > issues that are represent proposed extensions to the core specifications > and do the following: > > 1. Close the issue with "no-fix" > 2. Encourage anyone to write a draft describing the extended functionality. > > Such drafts can either be processed as individual submissions or > considered as part of a possible re-charter discussion in the WG when > the core documents are done. > > The following issues have been identified: > > #11 - Define a very simple language for entitlements > #14 - Enhance password and login metadata > #15 - Add specification for soft delete and reanimation operation as an > extension of core spec > #20 - Insert a "person" resource into the model (schema) > #32 - Async / Workflow Support > > In addition the following issues will also be closed as they do not > represent issues of the core specifications. Note that these issues > remain as milestones in our existing charter until the ADs say otherwise. > > #4 - Bring the SAML binding up-to-date > #45 - LDAP mapping I am very sorry that I did not act on this yet. I may still write a draft, if not as WG submission then as individual. Cheers, Peter > > Given the support this had in London we are looking for anyone that > disagrees with this plan. > > Cheers Leif & Morteza > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim -- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz From nobody Mon Mar 10 04:50:40 2014 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 AA8A71A0420 for ; Mon, 10 Mar 2014 04:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 GSxtMK_n8CrY for ; Mon, 10 Mar 2014 04:50:36 -0700 (PDT) Received: from mail-bk0-f47.google.com (mail-bk0-f47.google.com [209.85.214.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8154B1A041F for ; Mon, 10 Mar 2014 04:50:36 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id w10so1183386bkz.34 for ; Mon, 10 Mar 2014 04:50:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=bJtakfhQleDnxHagwST4Ev+LnY3QlyZYiQNabUX9ntw=; b=HrIh/FeGuoH1O28J86xXYw2CdU5GLG6U/TwIYt1AcjQsEFqBJRdVVOuo6LHaIhskw5 bLwy2YLykg3/Jp0IMo5atfH8uWcxSKaQ1fk6n7IIz8ejEKO2NR2QzN2mTjGBgfjwDMrf CjuUhJFOwIrrlqm37ayPbdwJ1eaetLmc0as/ptAk7KDLrnNnx5ryr4smEfM+9qK/jxNq StGb6qkJE+phJNY8wQ41vBXwZyVI2q2BqpPveKl5e0pVaDZ0E29nZoY5bFEIT32vsqui y7qZ+YQGgC1rShNJ4Y9pbx0CuF7416sKtMAHYBPo23oYEvKcbHJIIS6QwTFcegQ3OCw9 UIpw== X-Gm-Message-State: ALoCoQkYlQWWGXrY+qEX/39Y+GR43GtSPUnOwo6fDNef5fVPIr3QUt+mzO83TCBBBoO9O2pfPiBt X-Received: by 10.204.163.143 with SMTP id a15mr157245bky.44.1394452230395; Mon, 10 Mar 2014 04:50:30 -0700 (PDT) Received: from [172.24.12.173] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id c15sm1740518bky.13.2014.03.10.04.50.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Mar 2014 04:50:29 -0700 (PDT) Message-ID: <531DA704.5040507@tarent.de> Date: Mon, 10 Mar 2014 12:50:28 +0100 From: =?ISO-8859-15?Q?David_M=F6bius?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: scim@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/oNLfeIFgZ6BUjb701BRpsySm36s Subject: [scim] saving photo as data uri 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: Mon, 10 Mar 2014 11:50:38 -0000 Hello, we would like to give the client the possibility to save his photos also as data URI. The scim schema 2.0 tells about the photo: URL of a photo of the User. The value SHOULD be a canonicalized URL, and MUST point to an image file... Like this the client always need to save his images at some other space or in a other db. To make it more easy and more comfortable for the client we would like to save the multi valued image also as data URI (e.g.: data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEUAAAD/ //+l2Z/dAAAAM0lEQVR4nGP4/5/h/1+G/58ZDrAz3D/McH8yw83NDDeNGe4U g9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTkSuQmCC) Since a URL is a part of the URI but the URI is not part from a URL it would not be ok, for the scim 2.0, to save pictures like this. What do you think about this? Does it looks ok to save the picture as URL or as URI or do you think this should not be allowed. byby David From nobody Mon Mar 10 05:04:10 2014 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 9FE021A0423 for ; Mon, 10 Mar 2014 05:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 zDCQTfgVVULh for ; Mon, 10 Mar 2014 05:04:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4F33B1A0420 for ; Mon, 10 Mar 2014 05:04:06 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MWC9x-1WgY9G0tRJ-00XHhO; Mon, 10 Mar 2014 13:03:59 +0100 Message-ID: <531DAA2D.6030009@gmx.de> Date: Mon, 10 Mar 2014 13:03:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?David_M=F6bius?= , scim@ietf.org References: <531DA704.5040507@tarent.de> In-Reply-To: <531DA704.5040507@tarent.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:nyayqUeqngci0j2DwveJ7maElcD7oySJghB8xpWcbamT2THq882 9Rn8Dq7iNMAoz+a4A2B1w1RLRh+W6yRk9z5Odd3DMdRaDrmwIrm9sNPWjG45t3jgcNB9X2F ABnCET6Vvy7Z90LWesGxSOR/YtEyOgVxPj7pazl0uUNYW33amYxcHnXBKf4ZCkhyruIe04e 9+BI0tY8j1Nr39HD4Jxrg== Archived-At: http://mailarchive.ietf.org/arch/msg/scim/z2JqD1mEsXxr5pWmgRQxnncpR6E Subject: Re: [scim] saving photo as data uri 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: Mon, 10 Mar 2014 12:04:08 -0000 On 2014-03-10 12:50, David Möbius wrote: > Hello, > > we would like to give the client the possibility to save his photos > also as data URI. > > The scim schema 2.0 tells about the photo: URL of a photo of the > User. The value SHOULD be a canonicalized URL, and MUST point to an > image file... > > Like this the client always need to save his images at some other > space or in a other db. To make it more easy and more comfortable for > the client we would like to save the multi valued image also as data URI > > (e.g.: data:image/png;base64, > iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEUAAAD/ > //+l2Z/dAAAAM0lEQVR4nGP4/5/h/1+G/58ZDrAz3D/McH8yw83NDDeNGe4U > g9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTkSuQmCC) > > Since a URL is a part of the URI but the URI is not part from a URL it > would not be ok, for the scim 2.0, to save pictures like this. > > What do you think about this? Does it looks ok to save the picture as > URL or as URI or do you think this should not be allowed. > > byby David If the SCIM spec says URL, not URI, that's probably simply a bug. Best regards, Julian From nobody Mon Mar 10 07:24:43 2014 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 79A791A0471 for ; Mon, 10 Mar 2014 07:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, 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 f9OiFjoZysSs for ; Mon, 10 Mar 2014 07:24:38 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4751A047A for ; Mon, 10 Mar 2014 07:24:38 -0700 (PDT) Received: from NG-EX04.ad.nexusgroup.com (10.75.28.9) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.775.38; Mon, 10 Mar 2014 15:24:11 +0100 Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX04.ad.nexusgroup.com (10.75.28.9) with Microsoft SMTP Server (TLS) id 15.0.775.38; Mon, 10 Mar 2014 15:24:10 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0775.031; Mon, 10 Mar 2014 15:24:10 +0100 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Julian Reschke Thread-Topic: [scim] saving photo as data uri Thread-Index: AQHPPFb3rr+BUxjvpUelk6m9qgCwt5raKC+AgAAnLIA= Date: Mon, 10 Mar 2014 14:24:09 +0000 Message-ID: <63EB8F3F-B853-45AA-8F11-2EA4520EA6A1@nexusgroup.com> References: <531DA704.5040507@tarent.de> <531DAA2D.6030009@gmx.de> In-Reply-To: <531DAA2D.6030009@gmx.de> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.12.44] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3F490663CF1B124687C89D36494ADCAF@nexusgroup.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/bNJp5GOq-Ht57vqkpkp9jE1p0pY Cc: =?iso-8859-1?Q?David_M=F6bius?= , "scim@ietf.org WG" Subject: Re: [scim] saving photo as data uri 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: Mon, 10 Mar 2014 14:24:41 -0000 Hi, Lets dig a bit deeper into it. Does that mean that we create the image, gen= erates a URL then return that in the SCIM response? Otherwise, would we alw= ays return the base64 version of the image in the response? Cheers Erik On 10 Mar 2014, at 13:03, Julian Reschke wrote: > On 2014-03-10 12:50, David M=F6bius wrote: >> Hello, >>=20 >> we would like to give the client the possibility to save his photos >> also as data URI. >>=20 >> The scim schema 2.0 tells about the photo: URL of a photo of the >> User. The value SHOULD be a canonicalized URL, and MUST point to an >> image file... >>=20 >> Like this the client always need to save his images at some other >> space or in a other db. To make it more easy and more comfortable for >> the client we would like to save the multi valued image also as data URI >>=20 >> (e.g.: data:image/png;base64, >> iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEUAAAD/ >> //+l2Z/dAAAAM0lEQVR4nGP4/5/h/1+G/58ZDrAz3D/McH8yw83NDDeNGe4U >> g9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTkSuQmCC) >>=20 >> Since a URL is a part of the URI but the URI is not part from a URL it >> would not be ok, for the scim 2.0, to save pictures like this. >>=20 >> What do you think about this? Does it looks ok to save the picture as >> URL or as URI or do you think this should not be allowed. >>=20 >> byby David >=20 > If the SCIM spec says URL, not URI, that's probably simply a bug. >=20 > Best regards, Julian >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon Mar 10 08:47:03 2014 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 7B7961A0495 for ; Mon, 10 Mar 2014 08:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.448 X-Spam-Level: X-Spam-Status: No, score=-4.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 ORGyljiugXXd for ; Mon, 10 Mar 2014 08:46:58 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id CA6701A043E for ; Mon, 10 Mar 2014 08:46:58 -0700 (PDT) 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 s2AFkoLb021520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Mar 2014 15:46:51 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 s2AFkmnG010725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Mar 2014 15:46:48 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2AFkmHh023936; Mon, 10 Mar 2014 15:46:48 GMT Received: from [192.168.1.186] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Mar 2014 08:46:47 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <63EB8F3F-B853-45AA-8F11-2EA4520EA6A1@nexusgroup.com> Date: Mon, 10 Mar 2014 15:46:26 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8AD20945-07E9-49E1-BBA8-413742BD2EC3@oracle.com> References: <531DA704.5040507@tarent.de> <531DAA2D.6030009@gmx.de> <63EB8F3F-B853-45AA-8F11-2EA4520EA6A1@nexusgroup.com> To: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/PXYflsTq3XRLIsXo9ttwVcoo5tQ Cc: Julian Reschke , =?iso-8859-1?Q?David_M=F6bius?= , "scim@ietf.org WG" Subject: Re: [scim] saving photo as data uri 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: Mon, 10 Mar 2014 15:47:01 -0000 AFAIK, this is one of those things we have to update to URI. We should discuss whether clients can send URIs or must send base64 = encoded values. E.g. a client can update base64 encoded value but the = server can return a readOnly URI for a browser accessible file version = of the value. =20 If the client is sending a URI, how would the server domain access it = from a security context perspective? I think this is one of those things the original SCIM 1 folks had some = thoughts on. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2014-03-10, at 2:24 PM, Erik Wahlstr=F6m = wrote: > Hi, >=20 > Lets dig a bit deeper into it. Does that mean that we create the = image, generates a URL then return that in the SCIM response? Otherwise, = would we always return the base64 version of the image in the response? >=20 > Cheers > Erik >=20 >=20 > On 10 Mar 2014, at 13:03, Julian Reschke = wrote: >=20 >> On 2014-03-10 12:50, David M=F6bius wrote: >>> Hello, >>>=20 >>> we would like to give the client the possibility to save his photos >>> also as data URI. >>>=20 >>> The scim schema 2.0 tells about the photo: URL of a photo of the >>> User. The value SHOULD be a canonicalized URL, and MUST point to an >>> image file... >>>=20 >>> Like this the client always need to save his images at some other >>> space or in a other db. To make it more easy and more comfortable = for >>> the client we would like to save the multi valued image also as data = URI >>>=20 >>> (e.g.: data:image/png;base64, >>> iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEUAAAD/ >>> //+l2Z/dAAAAM0lEQVR4nGP4/5/h/1+G/58ZDrAz3D/McH8yw83NDDeNGe4U >>> g9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTkSuQmCC) >>>=20 >>> Since a URL is a part of the URI but the URI is not part from a URL = it >>> would not be ok, for the scim 2.0, to save pictures like this. >>>=20 >>> What do you think about this? Does it looks ok to save the picture = as >>> URL or as URI or do you think this should not be allowed. >>>=20 >>> byby David >>=20 >> If the SCIM spec says URL, not URI, that's probably simply a bug. >>=20 >> Best regards, Julian >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon Mar 10 08:57:25 2014 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 74E371A04A7 for ; Mon, 10 Mar 2014 08:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 qqQql7sgacZt for ; Mon, 10 Mar 2014 08:57:22 -0700 (PDT) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by ietfa.amsl.com (Postfix) with ESMTP id F05AE1A0265 for ; Mon, 10 Mar 2014 08:57:21 -0700 (PDT) Received: by mail-bk0-f48.google.com with SMTP id mx12so1200809bkb.21 for ; Mon, 10 Mar 2014 08:57:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0S8nCIiPLhaSj4RFPDYQxoCXJPmuEnzn8ZcGMcN5pCg=; b=bTXJTP2v4tsW7xtXRFsXbrteZveqKIEbLdENiOF8ZyHyYES0F+OKoEUMU1iBstQkJv FD2C4qhIiKFlyAbRkIcRWxo7e+8OTmasyl5/4M/WIwLz25pn4/qxcNNDElJad0imQTNs l8KUI7Z/dOFw6iAtIn514CmKFr+BY0RQuO+U6D9zskOES3fkf9sq1pcimfH8V8Cxqkln rBDRWn5Dyv8pkBJbrRdr2crjgz3Bj2ePRTxHYAfXEaZOMcku9OLHZQKpxf29OKZ3SyOV c5tG5+DTGb+p6C8mL36XRPApxczeF4sGvBJPFvdnCgYoWTI6vIhdvVvTeClO0ARtiwTV sNVA== X-Gm-Message-State: ALoCoQkhpZtvXy0wUI+//Y2SaCeZRlmYE97E6XHHFXKIYWIB6CfJGusZoQj9lDTWaaubpCEOhTVk X-Received: by 10.204.103.9 with SMTP id i9mr12462044bko.14.1394467035993; Mon, 10 Mar 2014 08:57:15 -0700 (PDT) Received: from [172.24.12.173] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id v12sm12110455bko.17.2014.03.10.08.57.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Mar 2014 08:57:15 -0700 (PDT) Message-ID: <531DE0D9.2030909@tarent.de> Date: Mon, 10 Mar 2014 16:57:13 +0100 From: =?ISO-8859-1?Q?David_M=F6bius?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Erik_Wahlstr=F6m?= , "scim@ietf.org WG" References: <531DA704.5040507@tarent.de> <531DAA2D.6030009@gmx.de> <63EB8F3F-B853-45AA-8F11-2EA4520EA6A1@nexusgroup.com> In-Reply-To: <63EB8F3F-B853-45AA-8F11-2EA4520EA6A1@nexusgroup.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/SrGdO18DzntF5zofyDZ47BB4ZRQ Subject: Re: [scim] saving photo as data uri 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: Mon, 10 Mar 2014 15:57:24 -0000 Hello Erik, actually it's not important how we create the image, but how we store the image. As you can read in the SCIM schema, the standard tells us (http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-6.2) to store images as URLs, but we like to store also URIs, to provide this data URI scheme; http://en.wikipedia.org/wiki/Data_URI_scheme It's just an image as string in this scheme: data:[][;charset=][;base64], But this is not an URL. Am 10.03.2014 15:24, schrieb Erik Wahlström: > Hi, > > Lets dig a bit deeper into it. Does that mean that we create the image, generates a URL then return that in the SCIM response? Otherwise, would we always return the base64 version of the image in the response? No, just put in the response what actually is stored. Both are okay, but just one of the following in the value attribute of the photo: http://www.example.org/image.jpg data:[][;charset=][;base64], Greetz, David > > Cheers > Erik > > > On 10 Mar 2014, at 13:03, Julian Reschke wrote: > >> On 2014-03-10 12:50, David Möbius wrote: >>> Hello, >>> >>> we would like to give the client the possibility to save his photos >>> also as data URI. >>> >>> The scim schema 2.0 tells about the photo: URL of a photo of the >>> User. The value SHOULD be a canonicalized URL, and MUST point to an >>> image file... >>> >>> Like this the client always need to save his images at some other >>> space or in a other db. To make it more easy and more comfortable for >>> the client we would like to save the multi valued image also as data URI >>> >>> (e.g.: data:image/png;base64, >>> iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEUAAAD/ >>> //+l2Z/dAAAAM0lEQVR4nGP4/5/h/1+G/58ZDrAz3D/McH8yw83NDDeNGe4U >>> g9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTkSuQmCC) >>> >>> Since a URL is a part of the URI but the URI is not part from a URL it >>> would not be ok, for the scim 2.0, to save pictures like this. >>> >>> What do you think about this? Does it looks ok to save the picture as >>> URL or as URI or do you think this should not be allowed. >>> >>> byby David >> >> If the SCIM spec says URL, not URI, that's probably simply a bug. >> >> Best regards, Julian >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > From nobody Thu Mar 13 01:16:44 2014 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 77B2E1A0952 for ; Thu, 13 Mar 2014 01:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 wQoiA7JXOmZr for ; Thu, 13 Mar 2014 01:16:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3E91A0703 for ; Thu, 13 Mar 2014 01:16:41 -0700 (PDT) Received: from [192.168.2.117] ([84.187.42.175]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M0yaB-1XIRus3v4B-00v7jA; Thu, 13 Mar 2014 09:16:30 +0100 Message-ID: <5321695C.4030109@gmx.de> Date: Thu, 13 Mar 2014 09:16:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?David_M=F6bius?= , =?ISO-8859-1?Q?Erik_Wahlstr=F6m?= , "scim@ietf.org WG" References: <531DA704.5040507@tarent.de> <531DAA2D.6030009@gmx.de> <63EB8F3F-B853-45AA-8F11-2EA4520EA6A1@nexusgroup.com> <531DE0D9.2030909@tarent.de> In-Reply-To: <531DE0D9.2030909@tarent.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:t2xE4Vm4NcALDCgWGoNjoviKQ525GV59j4t5yq59J4QKIVVN6FY CTwRS45+4hWS8JE12y9KiugJRl+5qWKtYfOTbA5U0QAu+btZAd5g+9D3+F+jOLZsmj1gazm eP9IixnxcaehphifkaXu4LcePjWLqXLzxMhSP5Uhzk+hLMog8zQg/E2ME13jFcKFXcsAT1r Lr8iW7oyLsL+AADPgZg9A== Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Qn549KCA0whYpdgCWp93kxBHrZE Subject: Re: [scim] saving photo as data uri 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: Thu, 13 Mar 2014 08:16:42 -0000 On 2014-03-10 16:57, David Möbius wrote: > Hello Erik, > > actually it's not important how we create the image, but how we store > the image. As you can read in the SCIM schema, the standard tells us > (http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-6.2) > to store images as URLs, but we like to store also URIs, to provide this > data URI scheme; http://en.wikipedia.org/wiki/Data_URI_scheme > It's just an image as string in this scheme: > data:[][;charset=][;base64], > But this is not an URL. Do not spend too much time with terminology. Any URL can be a name (such as in XML namespaces). And any URN can become resolvable at a later point of time. Just say "URI". Best regards, Julian From nobody Thu Mar 13 01:41:25 2014 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 420421A0989 for ; Thu, 13 Mar 2014 01:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 mEhOHwx1C172 for ; Thu, 13 Mar 2014 01:41:15 -0700 (PDT) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by ietfa.amsl.com (Postfix) with ESMTP id E72D51A097E for ; Thu, 13 Mar 2014 01:41:14 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id my13so45258bkb.22 for ; Thu, 13 Mar 2014 01:41:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QzuQ5BXxr5ndhipJkH3peLAV6bhvCGE1ttLbZuLVG9E=; b=cGANrL+85k7pjeSxH+aCeE4f7o4BoLg6xB68FBu3NX8BlzDXe7k6oL6iqgTMVyzp1f EoU0Ig2cxvMtO8FI0v2pcJglAW1rlVfit/x1Gs9lxBdpgC9sPLQZqOaCNaxGTh3rNtZe rUOjrrKyddWHC+RCy7zPKnGiei7IGa/MfrcAyfW/k7jI32J9xXk7i8gPdPr8/a8CsSGo rogVN8QeZb9VjRT17FWPQ2uEsYVHvXD/1TY59JFHPe4yRSajjvvVfYTlloapvVi8UAai IwBb+EMFszOhUhf9572zi06A/kT1ClkdL48WtIPmYwGFtB/JAmIFzOZSNV1LUWaOQfvV XosQ== X-Gm-Message-State: ALoCoQkhDs/ZmlaVsPHg07kBCovmWPLuCc4cUBlLdj0WmeUWzX3/53uBwg+6LXtFIy1BLfWpV5jP X-Received: by 10.204.78.9 with SMTP id i9mr182407bkk.40.1394700067765; Thu, 13 Mar 2014 01:41:07 -0700 (PDT) Received: from [172.24.12.173] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id oa10sm1747157bkb.14.2014.03.13.01.41.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 01:41:06 -0700 (PDT) Message-ID: <53216F21.4070803@tarent.de> Date: Thu, 13 Mar 2014 09:41:05 +0100 From: =?ISO-8859-1?Q?David_M=F6bius?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Julian Reschke , =?ISO-8859-1?Q?Erik_Wahlstr?= =?ISO-8859-1?Q?=F6m?= , "scim@ietf.org WG" References: <531DA704.5040507@tarent.de> <531DAA2D.6030009@gmx.de> <63EB8F3F-B853-45AA-8F11-2EA4520EA6A1@nexusgroup.com> <531DE0D9.2030909@tarent.de> <5321695C.4030109@gmx.de> In-Reply-To: <5321695C.4030109@gmx.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/S9AgYRZOYi8EjJ4Bf0m3D4eyWAc Subject: Re: [scim] saving photo as data uri 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: Thu, 13 Mar 2014 08:41:22 -0000 Hi, ok, thanks for your answers and ideas :) Thank we will take a URI for a photo. It would be nice if this could be changed in the scim spec. thanks and by David Am 13.03.2014 09:16, schrieb Julian Reschke: > On 2014-03-10 16:57, David Möbius wrote: >> Hello Erik, >> >> actually it's not important how we create the image, but how we store >> the image. As you can read in the SCIM schema, the standard tells us >> (http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-6.2) >> to store images as URLs, but we like to store also URIs, to provide this >> data URI scheme; http://en.wikipedia.org/wiki/Data_URI_scheme >> It's just an image as string in this scheme: >> data:[][;charset=][;base64], >> But this is not an URL. > > Do not spend too much time with terminology. Any URL can be a name (such > as in XML namespaces). And any URN can become resolvable at a later > point of time. > > Just say "URI". > > Best regards, Julian From nobody Fri Mar 14 17:09:25 2014 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 1DF8D1A012B for ; Fri, 14 Mar 2014 17:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 WkMyR3WJH1UY for ; Fri, 14 Mar 2014 17:09:20 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA7E1A00C9 for ; Fri, 14 Mar 2014 17:09:20 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2F09C7E001828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 15 Mar 2014 00:09:13 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2F09BV6017385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 15 Mar 2014 00:09:12 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s2F09BMF019508 for ; Sat, 15 Mar 2014 00:09:11 GMT Received: from [192.168.1.186] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Mar 2014 17:09:11 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_788BF95E-E50D-4D8A-A2B8-A3B02F7CCC5F" Message-Id: <42B672C1-5A3C-47C5-B1A1-3625BCF4992B@oracle.com> Date: Fri, 14 Mar 2014 17:09:09 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/RsxwGIKtxEte6iaAgApUJQkxeSg Subject: [scim] Ticket #18 - New PATCH - What is your preference for PATCH? 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: Sat, 15 Mar 2014 00:09:23 -0000 --Apple-Mail=_788BF95E-E50D-4D8A-A2B8-A3B02F7CCC5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks everyone for your feedback at IETF89. =20 =46rom the discussion, I took away that most people like RFC6902 but = because I proposed not using JSON Pointer there were some concerns about = not being compliant with 6902 in a normative sense (I am not sure if = this is in fact an issue). I see a few options that we can go with: A. Profiled/ JSON Patch + SCIM style paths - As proposed with SCIM-API = profiling 6902 but using SCIM attribute paths. = attribute[subfilter].subattr "path" =3D "members" "path" =3D "name.familyName" "path" =3D "addresses[type eq \"work\"]" "path"=3D"members[value eq \ "2819c223-7f76-453a-919d-413861904646\"]" "path"=3D"members[value eq = \"2819c223-7f76-453a-919d-413861904646\"].displayName" B. JSON Patch Based - SCIM Similar to A, except that we say it is = based/inspired by 6902 and completely define the operations supported. C1. 6901/6902 Profiled - Use 6901 Pointers (6902 pathes) as per = following examples: "path" =3D "members" "path" =3D "name/familyName" "path" =3D "addresses/[type eq \"work\"]" "path" =3D "members/[value eq \ "2819c223-7f76-453a-919d-413861904646\"]" "path" =3D "members/[value eq = \"2819c223-7f76-453a-919d-413861904646\"]/displayName" C2. 6901/6902 Based - Same as C1 except that we redefine all operations = since we do not support arrays. D. Fully 6901/6902 Compliant - We allow both array indexing and filters = per C. "path" =3D "members/[value eq = \"2819c223-7f76-453a-919d-413861904646\"]/displayName" "path" =3D "members/1011234/displayName" Note that "based" means that we fully redefine 6902 within the PATCH = command. "Profiled" means that we are depending on 6902 and optionally = 6901 in a normative sense. My preference is B as this seems to address the normative concerns = around using 6902 while retaining a consistent path format that we use = throughout the rest of scim (attribute.subattribute dotted notation). = It also seems more obvious that SCIM does not support indexed access or = ordered arrays. Which method do you prefer? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_788BF95E-E50D-4D8A-A2B8-A3B02F7CCC5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

"path" =3D "members

"path" =3D "

"path" =3D "addresses[type eq \"work\"]

"path"=3D"members[value eq "

"path"=3D"members[value eq \"2819c223-7f76-453a-919d-413861904646\"].displayName


B. JSON Patch = Based - SCIM  Similar to A, except that we say it is = based/inspired by 6902 and completely define the operations = supported.

C1. 6901/6902 Profiled - Use = 6901 Pointers (6902 pathes) as per following examples:

"path" =3D= "members

"path" =3D "name/familyName"

"path" =3D= "addresses/[eq \"work\"]"

"path" =3D= "members/[value  \

"

"eq displayName

 Fully 6901/6902 = Compliant - We allow both array indexing and filters per = C.

"path" =3D "members/[value eq \"2819c223-7f76-453a-919d-413861904646\"]/displayName"
"path" =3D "members/1011234/

My preference is B as this seems to address the = normative concerns around using 6902 while retaining a consistent path = format that we use throughout the rest of scim (attribute.subattribute = dotted notation).  It also seems more obvious that SCIM does not = support indexed access or ordered arrays.


phil.hunt@oracle.com
=

= --Apple-Mail=_788BF95E-E50D-4D8A-A2B8-A3B02F7CCC5F-- From nobody Sat Mar 15 11:02:18 2014 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 903AA1A018E for ; Sat, 15 Mar 2014 11:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 P9kKUUQftv2u for ; Sat, 15 Mar 2014 11:02:09 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8C61A0180 for ; Sat, 15 Mar 2014 11:02:09 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2FI1wQF026749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Mar 2014 18:01:59 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2FI1vnl027021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Mar 2014 18:01:57 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2FI1vPD027016; Sat, 15 Mar 2014 18:01:57 GMT Received: from [192.168.1.186] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 15 Mar 2014 11:01:57 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <531D7D6F.60204@daasi.de> Date: Sat, 15 Mar 2014 11:01:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <531B8B0F.6000800@mnt.se> <531D7D6F.60204@daasi.de> To: Peter Gietz X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/QjigOyK2nTnVH6rCPPWp-_NFvqg Cc: scim@ietf.org Subject: Re: [scim] consensus call on moving issues to extension drafts 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: Sat, 15 Mar 2014 18:02:13 -0000 Peter, I closed the issue per the message from Leif on Mar 8 and the general = discussion at IETF89. I'm still assuming you will proceed to submit a = separate draft rather than tracking this item against the existing = drafts. I seem to recall in the IETF89 meeting, someone mentioned they are = finding it easier to extend LDAP implementations internally to support = complex attributes for SCIM rather than use a mapping. FWIW. I think one-way mappings where LDAP is a provisioning end-point = is a very useful draft to have. In this case I would expect that = read-after-write dual-mapping is not expected. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2014-03-10, at 1:53 AM, Peter Gietz wrote: > Am 08.03.2014 22:26, schrieb Leif Johansson: >> At the London meeting there was strong consensus for identifying the >> issues that are represent proposed extensions to the core = specifications >> and do the following: >>=20 >> 1. Close the issue with "no-fix" >> 2. Encourage anyone to write a draft describing the extended = functionality. >>=20 >> Such drafts can either be processed as individual submissions or >> considered as part of a possible re-charter discussion in the WG when >> the core documents are done. >>=20 >> The following issues have been identified: >>=20 >> #11 - Define a very simple language for entitlements >> #14 - Enhance password and login metadata >> #15 - Add specification for soft delete and reanimation operation as = an >> extension of core spec >> #20 - Insert a "person" resource into the model (schema) >> #32 - Async / Workflow Support >>=20 >> In addition the following issues will also be closed as they do not >> represent issues of the core specifications. Note that these issues >> remain as milestones in our existing charter until the ADs say = otherwise. >>=20 >> #4 - Bring the SAML binding up-to-date >> #45 - LDAP mapping >=20 > I am very sorry that I did not act on this yet. I may still write a = draft, if not as WG submission then as individual. >=20 > Cheers, >=20 > Peter >=20 >>=20 >> Given the support this had in London we are looking for anyone that >> disagrees with this plan. >>=20 >> Cheers Leif & Morteza >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > --=20 >=20 > Peter Gietz, CEO >=20 > DAASI International GmbH > Europaplatz 3 > D-72072 T=FCbingen > Germany >=20 > phone: +49 7071 407109-0 > fax: +49 7071 407109-9 > email: peter.gietz@daasi.de > web: www.daasi.de >=20 > Sitz der Gesellschaft: T=FCbingen > Registergericht: Amtsgericht Stuttgart, HRB 382175 > Gesch=E4ftsleitung: Peter Gietz >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Sun Mar 16 03:01:12 2014 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 AFF2C1A00AE for ; Sun, 16 Mar 2014 03:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 rQjLltgOB6Ji for ; Sun, 16 Mar 2014 03:01:08 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id 69B331A01C5 for ; Sun, 16 Mar 2014 03:01:08 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id e16so2978960lan.30 for ; Sun, 16 Mar 2014 03:01:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hS0pKrPYsnQhb/1+eaWXK6KNYOLlC3QpiUwhij6YJdo=; b=MNlATYHPAV98sV9L8NVxzD7FM5IhYveI1LOwW0CGy0ZapjDE14tLP8XXEtXx0LqYQq mbk+z8nojNAKitay+2iP1yVUz2ZZ0hnnRGzyqh5UuIDdeQI4ueuPNH99I78RCuJLOpFo J2x2IyThOF3w57TlERo6yW7KDGtgzxcO4UsORaxgonLGoWvns++uVlnnux+lEyyHDTFD UCNKyb8I6H9mL22EoASTIi5QZwWpJgR6i6Bk1rBo+VnJe4vWIG6tkSgr51p6JMFmGViA kxiPrH+TP3C+Pcfsv2cVmG3+blEbCVCAzo5r4s9kEnDZsHCChVmdbVyNISIhfqGYqaf6 lmig== X-Gm-Message-State: ALoCoQlYWmBl7T1IZ/lSBOjPEQ+mvhcp08PBoCVS3O9ju2TuRnREsW2mWdWMtf1SICDTm46fsxUD X-Received: by 10.153.8.135 with SMTP id dk7mr12653984lad.18.1394964060137; Sun, 16 Mar 2014 03:01:00 -0700 (PDT) Received: from [172.20.10.3] (2.64.138.64.mobile.tre.se. [2.64.138.64]) by mx.google.com with ESMTPSA id mk5sm10596832lac.6.2014.03.16.03.00.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 03:00:59 -0700 (PDT) Message-ID: <53257658.90807@mnt.se> Date: Sun, 16 Mar 2014 11:00:56 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: scim@ietf.org References: <531B8B0F.6000800@mnt.se> <531D7D6F.60204@daasi.de> In-Reply-To: <531D7D6F.60204@daasi.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/0ETNN6mIUUkzrkXX2kduDCEG74o Subject: Re: [scim] consensus call on moving issues to extension drafts 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: Sun, 16 Mar 2014 10:01:10 -0000 On 2014-03-10 09:53, Peter Gietz wrote: > Am 08.03.2014 22:26, schrieb Leif Johansson: >> At the London meeting there was strong consensus for identifying the >> issues that are represent proposed extensions to the core specifications >> and do the following: >> >> 1. Close the issue with "no-fix" >> 2. Encourage anyone to write a draft describing the extended >> functionality. >> >> Such drafts can either be processed as individual submissions or >> considered as part of a possible re-charter discussion in the WG when >> the core documents are done. >> >> The following issues have been identified: >> >> #11 - Define a very simple language for entitlements >> #14 - Enhance password and login metadata >> #15 - Add specification for soft delete and reanimation operation as an >> extension of core spec >> #20 - Insert a "person" resource into the model (schema) >> #32 - Async / Workflow Support >> >> In addition the following issues will also be closed as they do not >> represent issues of the core specifications. Note that these issues >> remain as milestones in our existing charter until the ADs say otherwise. >> >> #4 - Bring the SAML binding up-to-date >> #45 - LDAP mapping I declare consensus on this issue and will close the tickets accordingly. Cheers Leif From nobody Sun Mar 16 10:20:06 2014 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 C420A1A02F4 for ; Sun, 16 Mar 2014 10:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 GL1bhNDn6zzP for ; Sun, 16 Mar 2014 10:20:04 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 01A8E1A02F2 for ; Sun, 16 Mar 2014 10:20:03 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id z11so2985009lbi.22 for ; Sun, 16 Mar 2014 10:19:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=AoM5eRyUKPoREiuV3QcbTs9nc2BIOiIgDGTYj1J1ec8=; b=F+xwmJN7moQt+qKnrrCvlpNPSqxMgTiF88zm0Im/pAHX2EkcduE+cKrmoJDJ2+qhHF p5DyOtaQqR65gBA2qwOqETlVbyNS+sY/sDSRineoEUOYE9SpOE40679XPIFsOcCjVhnB VbOkEoN0rSs9Wtjj8syhByKQjhVO/p9zQhIUcbPtdTsvaaIIs/iV4N5Wt8YOj4jEbNDp lB5gbAirpxPaWCIpnzHB5Tn+TFryEiERjK1kmcbeXL/kc21seeSTmrKaJDmNixv4L34a NlCxdnxAEi4WVkZZy4hhfDrFbX8XyZ9f32aezN9g5ztXent/XXAClBwT/RobCDdLOtc/ DcbQ== X-Gm-Message-State: ALoCoQkH8Lhf18S/HjPRcUgK9brzP0hWRg/IXuiOwcMClsdDLhOAg11H5S38DSt/bCy1WM/k58CN X-Received: by 10.112.143.99 with SMTP id sd3mr13009400lbb.11.1394990395492; Sun, 16 Mar 2014 10:19:55 -0700 (PDT) Received: from [10.0.0.115] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id v20sm3276088lbi.24.2014.03.16.10.19.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 10:19:54 -0700 (PDT) Message-ID: <5325DD3B.6090009@mnt.se> Date: Sun, 16 Mar 2014 18:19:55 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "scim@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/C-PFGEtG3HXiCch695_BR4eGQEg Subject: [scim] consensus-call: close #6 as won't fix 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: Sun, 16 Mar 2014 17:20:06 -0000 There was support in London for rejecting the proposal to move nicname to a sub-attribute of name. Please respond here if you *object* to closing #6 with won't fix. Cheers Leif & Morteza From nobody Sun Mar 16 10:52:35 2014 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 D057A1A0165 for ; Sun, 16 Mar 2014 10:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.316 X-Spam-Level: X-Spam-Status: No, score=-4.316 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_FOLLOW2=0.422, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_FRT_FOLLOW2=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 1FQLH6QEmoxN for ; Sun, 16 Mar 2014 10:52:27 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 296291A02FA for ; Sun, 16 Mar 2014 10:52:26 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2GHqHNT011491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 16 Mar 2014 17:52:19 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2GHqGo8019042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 16 Mar 2014 17:52:17 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2GHqGKe012721 for ; Sun, 16 Mar 2014 17:52:16 GMT Received: from [192.168.1.186] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 16 Mar 2014 10:52:16 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <077.3867a9173da069c780355d16afd743ae@tools.ietf.org> Date: Sun, 16 Mar 2014 10:52:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5955383B-7AFE-4E41-A8BC-15E4A53413B6@oracle.com> References: <062.6cf0f5905872266bf11150e6c9a3e265@tools.ietf.org> <077.3867a9173da069c780355d16afd743ae@tools.ietf.org> To: "scim@ietf.org WG" X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/imdMy_2bny_H3LyANYvpDbU3SYg Subject: Re: [scim] #18 (api): Review patch function 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: Sun, 16 Mar 2014 17:52:33 -0000 Oops=85 the text I posted to the ticket was old text. I have updated = the ticket. This is the correct "proposed" text. Do we want full conformance including all operations and json pointer? Here is just the new PATCH section alone: ---------------------------------- 3.3.2. Modifying with PATCH =20 PATCH is OPTIONAL. PATCH enables clients to send only those attributes requiring modification, reducing network and processing overhead. Attributes may be deleted, replaced, merged, or added in = a single request. =20 | The body of a PATCH request MUST contain ONE or more JSON Patch | operations [RFC6902]. The server MUST return either a 200 OK response code and the entire resource (subject to the "attributes" query parameter - see Additional Retrieval Query Parameters (Section 3.7)) within the response body, or a 204 No Content = response code and the appropriate response headers for a successful PATCH request. The server MUST return a 200 OK if the "attributes" parameter is specified on the request. =20 | The "path" and "from" attributes are strings containing a SCIM | attribute path or a json pointer and optional SCIM multi-value array | filter. =20 | The ABNF syntax for "path" and "from" is specified by "PATH": =20 | PATH =3D ATPATH / json6901path =20 | json6901path =3D json-pointer ["/[" FILTER "]" [json-pointer] ] =20 | ABNF for PATCH "path" and "from" Attributes =20 | "ATPATH" and "FILTER" are as per Figure 1, and "json-pointer" is as | per [RFC6901]. =20 | As SCIM servers do not guarantee order of multi-value arrays, a SCIM | client should use caution when using JSON Pointer array addressing. | SCIM sub-attribute filtes MUST be specified within square brackets = ([ | ]) to distinguish from array indexing. Clients should consider that | entries with high-update rates may change array indexes frequently. | Clients SHOULD use "Etags" when accessing multi-valued attributes by | array index. | | Valid example "path" and "from" values are as follows: | | "path" =3D "members" | | "path" =3D "name.familyName" | | "path" =3D "/name/familyName" | | "path" =3D "addresses[type eq \"work\"]" | | "path" =3D "members[value eq | \"2819c223-7f76-453a-919d-413861904646\"]" | | "path" =3D "/members/1/displayName" | | "path" =3D "members[value eq | \"2819c223-7f76-453a-919d-413861904646\"].displayName" | | "path" =3D "/members/[value eq | \"2819c223-7f76-453a-919d-413861904646\"]/displayName | |3.3.2.1. Supported JSON Patch Operations | | SCIM supports the JSON Patch operations: "add", "remove", "replace", | "copy","move", and "test". | | As specified in [RFC6902], a PATCH MAY contain one or more JSON = patch | operation in a JSON array. The PATCH request comprising the entire | array of operations SHALL be treated as atomic. If a single | operation encounters an error condition, the original SCIM resource | MUST be restored. | | Each operation represents a single action to be applied to the same | SCIM resource specified by the request URI. Operations are applied | sequentially in the order they appear in the array. Each operation | in the sequence is applied to the target resource; the resulting | resource becomes the target of the next operation. Evaluation | continues until all operations are successfully applied or until an | error condition is encountered. | |3.3.2.2. Add Operation | | The "add" operation performs one of the following functions, | depending upon what the target location indicated by "path" | references: | | o If the target location does not exist, the attribute and value is | added. | | o If the target location specifies a multi-valued attribute, a new | value is added to the attribute. | | o if the target location specifies a single-valued attribute, the | existing value is replaced. | | o If the target location specifies an attribute that does not exist | (has no value), the attribute is added with the new value. | | o If the target location already contains the value specified, no | changes SHOULD be made to the resource and a success response | SHOULD be returned. | | o If the target location already exists the value is replaced. | | The operation MUST contain a "value" member whose content specifies | the value to be added. The value MAY be a quoted value OR it may be | a JSON object containing the sub-attributes of the complex attribute | specified in the operation's "path". | | The following example shows how to add a member to a group. Some | text removed for readability ("..."): =20 PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" =20 { | "op":"add", | "path":"members", | "value":[ { "display": "Babs Jensen", | "$ref": = "https://example.com/v2/Users/2819c223-...919d-413861904646", "value": "2819c223-7f76-453a-919d-413861904646" } ] } =20 The "display" Sub-Attribute in this request is optional since the value attribute uniquely identifies the user to be added. If the user was already a member of this group, no changes should be made = to the resource and a success response should be returned. The server responds with either the entire updated Group or no response body: =20 HTTP/1.1 204 No Content Authorization: Bearer h480djs93hd8 ETag: W/"b431af54f0671a2" Location: = "https://example.com/v2/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce" =20 |3.3.2.3. Remove Operation | | The "remove" operation removes the value at the target location | specified by the "path". The operation performs the following | functions depending on the target location specified by "path": | | o If the target location is a single-value attribute, the attribute | and its associated value is removed. | | o If the target location is a multi-valued attribute and no filter | is specified, the attribute and all values are removed. | | o If the target location is a multi-valued attribute and a complex | filter is specified comparing a "value", the values matched by = the | filter are removed. | | o If the target location is a complex-multi-valued attribute and a | complex filter is specified based on the attribute's sub- | attributes, the matching records are removed. | The following example shows how to remove a member from a group. As with the previous example, the "display" Sub-Attribute is optional. If the user was not a member of this group, no changes should be = made to the resource and a success response should be returned. =20 Note that server responses have been omitted for the rest of the PATCH examples. =20 | Remove a single member from a group. Some text removed for | readability ("..."): | PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" =20 { | "op":"remove", | "path":"members[value eq \"2819c223-7f76-...413861904646\"]" } =20 | Remove all members of a group: =20 PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" =20 | { "op":"remove","path":"members"} | | Removal of a value from a complex-multi-valued attribute (request | headers removed for brevity): | { | "op":"remove", | "path":"address[type eq \"work\" and value ew \"example.com\"]" } | Example request to remove and add a member. Some text removed for | readability ("..."): =20 PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" =20 |[ { | "op":"remove", | "path":"members[value eq\"2819c223-...919d-413861904646\"]" }, | { | "op":"add", | "path":"members", | "value": [ | { | "display": "James Smith", | "$ref": = "https://example.com/v2/Users/08e1d05d-...8b96-473d93df9210", | "value": "08e1d05d-121c-4561-8b96-473d93df9210" | } | ] | } |] | The following example shows how to replace all the members of a = group | with a different members list. Some text removed for readabilty | ("..."): | |PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce |Host: example.com |Accept: application/json |Content-Type: application/json |Authorization: Bearer h480djs93hd8 |If-Match: W/"a330bc54f0671c9" | |[ | { "op":"remove","path":"members"}, | { | "op":"add", | "path":"members", | "value":[ { "display": "Babs Jensen", | "$ref": = "https://example.com/v2/Users/2819c223-...919d-413861904646", "value": "2819c223-7f76-453a-919d-413861904646" }, { "display": "James Smith", | "$ref": = "https://example.com/v2/Users/08e1d05d-121c-...473d93df9210", "value": "08e1d05d-121c-4561-8b96-473d93df9210" | }] } ] =20 |3.3.2.4. Replace Operation | | The "replace" operation replaces the value at the target location | specified by the "path". The operation performs the following | functions depending on the target location specified by "path": | | o If the target location is a single-value attribute, the = attributes | value is replaced. | | o If the target location is a multi-valued attribute and no filter | is specified, the attribute and all values are replaced. | | o If the target location is a multi-valued attribute and a complex | filter is specified comparing a "value", the values matched by = the | filter are replaced. | | o If the target location is a complex-multi-valued attribute and a | complex filter is specified based on the attribute's sub- | attributes, the matching records are replaced. | | o If the target location is a complex-multi-valued attribute with a | complex filter and a specific sub-attribute (e.g. = "addresses[type | eq "work"].streetAddress"), the matching sub-attribute of the | matching record is replaced. | | The following example shows how to replace all the members of a = group | with a different members list in a single replace operation. Some | text removed for readability ("..."): =20 PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" =20 { | "op":"replace", | "path":"members", | "value":[ { "display": "Babs Jensen", | "$ref": = "https://example.com/v2/Users/2819c223-...919d-413861904646", | "value": "2819c223-7f76-453a-919d-413861904646" }, { "display": "James Smith", | "$ref": = "https://example.com/v2/Users/08e1d05d-121c-...473d93df9210", "value": "08e1d05d-121c-4561-8b96-473d93df9210" } ] } | The following example shows how to change a User's entire "work" | address. =20 PATCH /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" =20 { | "op":"replace", | "path":"addresses[type eq \"work\"]", | "value": { | "type": "work", | "streetAddress": "911 Universal City Plaza", | "locality": "Hollywood", | "region": "CA", | "postalCode": "91608", | "country": "US", | "formatted": "911 Universal City Plaza\nHollywood, CA 91608 US", "primary": true } } | The following example shows how to change a User's address. Since address does not have a value Sub-Attribute, the existing address must be removed and the modified address added. =20 PATCH /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" =20 { | "op":"replace", | "path":"addresses[type eq \"work\"].streetAddress", | "value":"911 Universal City Plaza" | } | |3.3.2.5. Move Operation | | The "move" operation moves the value at a specified location = ("from") | and adds it at a target location ("path"). The operation is | functionally identical to a "remove" operation on the "from" | location, frollowed immediately by an "add" operation at the target | location with the value that was just removed. If a filter was used | to select the path location, any filter term with an attribute | equality condition (e.g. "[type eq \"home\"]") SHALL retain the = value | of the filtered attribute and SHALL NOT be overwritten by a | corresponding attribute value from the "from" location. | | The following shows two existing "addresses" that are part of a | resource in the SCIM server before patching: | "addresses": [ { "type": "work", "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", | "country": "USA", | "formatted": "100 Universal City Plaza\nHollywood, CA 91608 = USA", | "primary": true }, { | "type": "home", | "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", | "country": "USA", | "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" } ] =20 | The following example shows how to move an address from type "work" | to type "home": =20 PATCH /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" =20 { | "op":"move", | "from":"/addresses/[type eq \"work\"]" | "path":"/addresses/[type eq \"home\"]" | } | The following shows the attribute "addresses" after the preceding | PATCH "move" operation. =20 | "addresses": [ | { | "type": "home", | "streetAddress": "100 Universal City Plaza", | "locality": "Hollywood", | "region": "CA", | "postalCode": "91608", | "country": "USA", | "formatted": "100 Universal City Plaza\nHollywood, CA 91608 = USA", | "primary": true | } | ] =20 |3.3.2.6. Copy Operation | | The "copy" operation copies the value at a specified location | ("from") and adds it the target location ("path"). This operation = is | functionalty the similar to an "add" operation at the target = location | with the value that specified by the "from" attribute. If a filter | was used to select the path location, any filter term with an | attribute equality condition (e.g. "[type eq \"home\"]") SHALL = retain | the value of the filtered attribute and SHALL NOT be overwritten by = a | corresponding attribute value from the "from" location. | | The following shows two existing "addresses" that are part of a | resource in the SCIM server before patching: =20 | "addresses": [ { | "type": "work", | "streetAddress": "100 Universal City Plaza", | "locality": "Hollywood", | "region": "CA", | "postalCode": "91608", | "country": "USA", | "formatted": "100 Universal City Plaza\nHollywood, CA 91608 = USA", | "primary": true | }, | { | "type": "home", | "streetAddress": "456 Hollywood Blvd", | "locality": "Hollywood", | "region": "CA", | "postalCode": "91608", | "country": "USA", | "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" } | ] =20 | The following example shows how to copy an address from type "work" | to type "home": =20 PATCH /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" =20 { | "op":"copy", | "from":"/addresses/[type eq \"work\"]" | "path":"/addresses/[type eq \"home\"]" | } | The following shows the attribute "addresses" after the preceding | PATCH "copy" operation. | | "addresses": [ | { | "type": "work", | "streetAddress": "100 Universal City Plaza", | "locality": "Hollywood", | "region": "CA", | "postalCode": "91608", | "country": "USA", | "formatted": "100 Universal City Plaza\nHollywood, CA 91608 = USA", | "primary": true | }, | { | "type": "home", | "streetAddress": "100 Universal City Plaza", | "locality": "Hollywood", | "region": "CA", | "postalCode": "91608", | "country": "USA", | "formatted": "100 Universal City Plaza\nHollywood, CA 91608 = USA", | "primary": true } | ] =20 |3.3.2.7. Test Operation | | The "test" operation tests the value at the target location = specified | by the "path"is equal to the specified value. The operation = performs | the following functions depending on the target location specified = by | "path": | | o If the target location is a single-value attribute, the = attributes | value is compared for equality to the value specified. | | o If the target location is a multi-valued attribute and no filter | is specified, all values are compared as if the "eq" filter were | applied to the attribute. | | o If the target location is a multi-valued attribute and a complex | filter is specified comparing a "value", the values matched by = the | filter are compared for equality to the value specified. | | o If the target location is a complex-multi-valued attribute and a | complex filter is specified based on the attribute's sub- | attributes, the matching record is compared for equality to the | value specified. | | o If the target location is a complex-multi-valued attribute with a | complex filter and a specific sub-attribute (e.g. = "addresses[type | eq "work"].streetAddress"), the matching sub-attribute of the | matching record is compared to the value specified. | | The following is an example of a test operation performing | conditional replace if a record has a specific value. =20 PATCH /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" =20 | [ { | "op":"test", | "path":"addresses[type eq \"work\"].streetAddress", | "value":"100 Universal City Plaza" | }, | { | "op":"replace", | "path":"addresses[type eq \"work\"].streetAddress", | "value":"911 Universal City Plaza" } | ] =20 ---------------------------------- Phil @independentid www.independentid.com phil.hunt@oracle.com On 2014-03-16, at 10:40 AM, "scim issue tracker" = wrote: > #18: Review patch function >=20 >=20 > Comment (by phil.hunt@oracle.com): >=20 > Here is a proposal with full 6902/6901 compliance: >=20 > {{{ >=20 > 3.3.2. Modifying with PATCH >=20 > PATCH is OPTIONAL. PATCH enables clients to send only those > attributes requiring modification, reducing network and processing > overhead. Attributes may be deleted, replaced, merged, or added = in a > single request. >=20 > The body of a PATCH request MUST contain a partial resource with = the > desired modifications. The server MUST return either a 200 OK > response code and the entire resource (subject to the "attributes" > query parameter - see Additional Retrieval Query Parameters > (Section 3.7)) within the response body, or a 204 No Content = response > code and the appropriate response headers for a successful PATCH > request. The server MUST return a 200 OK if the "attributes" > parameter is specified on the request. >=20 > | The format of the SCIM PATCH operation is based upon JavaScript > | Object Notation (JSON) Patch [RFC6902]. However instead of using > | JSON-Pointer values [RFC6901], SCIM PATCH operation objects have > | a"path" member whose value is a string containing a SCIM attribute > | path value whose ABNF syntax is PATH as per Figure 1). >=20 > | The attribute-path is a SCIM attribute or attribute and = sub-attribute > | combined with an optional complex filter to select the correct = value > | of a multi-valued complex attribute. Valid examples are as = follows: >=20 > | "path" =3D "members" >=20 > | "path" =3D "name.familyName" >=20 > | "path" =3D "addresses[ty[e eq \"work\"]" >=20 > | "path" =3D "members[value eq > | \"2819c223-7f76-453a-919d-413861904646\"]" >=20 > | "path" =3D "members[value eq > | \"2819c223-7f76-453a-919d-413861904646\"].displayName" > | > |3.3.2.1. Supported JSON Patch Operations > | > | SCIM supports the JSON Patch operations: "add", "remove", = "replace", > | and "test". The JSON patch operations "move" and "copy" SHALL NOT = be > | supported as SCIM does not support array based addressing. > | > | As specified in [RFC6902], a PATCH MAY contain one or more JSON = patch > | operation in a JSON array. The PATCH request comprising the = entire > | array of operations SHALL be treated as atomic. If a single > | operation encounters an error condition, the original SCIM = resource > | MUST be restored. > | > | Each operation represents a single action to be applied to a = single > | SCIM resource. Operations are applied sequentially in the order = they > | appear in the array. Each operation in the sequence is applied to > | the target document; the resulting document becomes the target of = the > | next operation. Evaluation continues until all operations are > | successfully applied or until an error condition is encountered. > | > |3.3.2.2. Add Operation > | > | The "add" operation performs one of the following functions, > | depending upon what the target location inidicated by "path" > | references: > | > | o If the target location specifies a multi-valued attribute, a = new > | value is added to the attribute. > | > | o if the target location specifies a single-valued attribute, the > | existing value is replaced. > | > | o If the target location specifies an attribute that does not = exist > | (has no value), the attribute is added with the new value. > | > | o If the target location already contains the value specified, no > | changes SHOULD be made to the resource and a success response > | SHOULD be returned. The server MAY respond with either the = entire > | updated resource or no response body (e.g. in the case of a > | "Group"). > | > | The operation MUST contain a "value" member whose content = specifies > | the value to be added. The value MAY be a quoted value OR it may = be > | a JSON object containing the sub-attributes of the complex = attribute > | specified in the operation's "path". > | > | The following example shows how to add a member to a group. Some > | text removed for readability ("..."): >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Content-Type: application/json > Authorization: Bearer h480djs93hd8 > If-Match: W/"a330bc54f0671c9" >=20 > { > | "op":"add", > | "path":"members", > | "value":[ > { > "display": "Babs Jensen", > | "$ref": > "https://example.com/v2/Users/2819c223-...919d-413861904646", > "value": "2819c223-7f76-453a-919d-413861904646" > } > ] > } >=20 > The "display" Sub-Attribute in this request is optional since the > value attribute uniquely identifies the user to be added. If the > user was already a member of this group, no changes should be made = to > the resource and a success response should be returned. The = server > responds with either the entire updated Group or no response body: >=20 > HTTP/1.1 204 No Content > Authorization: Bearer h480djs93hd8 > ETag: W/"b431af54f0671a2" > Location: "https://example.com/v2/Groups/acbf3ae7-8463-4692-b4fd- > 9b4da3f908ce" >=20 > |3.3.2.3. Remove Operation > | > | The "remove" operation removes the value at the target location > | specified by the "path". The operation performs the following > | functions depending on the target location specified by "path": > | > | o If the target location is a single-value attribute, the = attribute > | and its associated value is removed. > | > | o If the target location is a multi-valued attribute and no = filter > | is specified, the attribute and all values are removed. > | > | o If the target location is a multi-valued attribute and a = complex > | filter is specified comparing a "value", the values matched by = the > | filter are removed. > | > | o If the target location is a complex-multi-valued attribute and = a > | complex filter is specified based on the attribute's sub- > | attributes, the matching records are removed. > | > The following example shows how to remove a member from a group. = As > with the previous example, the "display" Sub-Attribute is = optional. > If the user was not a member of this group, no changes should be = made > to the resource and a success response should be returned. >=20 > Note that server responses have been omitted for the rest of the > PATCH examples. >=20 > | Remove a single member from a group. Some text removed for > | readability ("..."): > | > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Content-Type: application/json > Authorization: Bearer h480djs93hd8 > If-Match: W/"a330bc54f0671c9" >=20 > { > | "op":"remove", > | "path":"members[value eq \"2819c223-7f76-...413861904646\"]" > } > | Remove all members of a group: >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Content-Type: application/json > Authorization: Bearer h480djs93hd8 > If-Match: W/"a330bc54f0671c9" >=20 > | { "op":"remove","path":"members"} > | > | Removal of a value from a complex-mulit-valued attribute (request > | headers removed for brevity): > | > { > | "op":"remove", > | "path":"address[type eq \"work\" and value ew \"example.com\"]" > } >=20 > | Example request to remove and add a member. Some text removed for > | readability ("..."): >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Content-Type: application/json > Authorization: Bearer h480djs93hd8 > If-Match: W/"a330bc54f0671c9" >=20 > |[ > { > | "op":"remove", > | "path":"members[value eq\"2819c223-...919d-413861904646\"]" > }, > { > | "op":"add", > | "path":"members", > | "value": [ > { > "display": "James Smith", > | "$ref": > "https://example.com/v2/Users/08e1d05d-...8b96-473d93df9210", > "value": "08e1d05d-121c-4561-8b96-473d93df9210" > } > ] > } > |] > | The following example shows how to replace all the members of a = group > | with a different members list. Some text removed for readabilty > | ("..."): >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Content-Type: application/json > Authorization: Bearer h480djs93hd8 > If-Match: W/"a330bc54f0671c9" >=20 > |[ > | { "op":"remove","path":"members"}, > { > | "op":"add", > | "path":"members", > | "value":[ > { > "display": "Babs Jensen", > | "$ref": > "https://example.com/v2/Users/2819c223-...919d-413861904646", > | "value": "2819c223-7f76-453a-919d-413861904646" > }, > { > "display": "James Smith", > | "$ref": "https://example.com/v2/Users/08e1d05d- > 121c-...473d93df9210", > "value": "08e1d05d-121c-4561-8b96-473d93df9210" > | }] > } > ] >=20 > |3.3.2.4. Replace Operation >=20 > | The "replace" operation replaces the value at the target location > | specified by the "path". The operation performs the following > | functions depending on the target location specified by "path": > | > | o If the target location is a single-value attribute, the = attributes > | value is replaced. > | > | o If the target location is a multi-valued attribute and no = filter > | is specified, the attribute and all values are replaced. > | > | o If the target location is a multi-valued attribute and a = complex > | filter is specified comparing a "value", the values matched by = the > | filter are replaced. > | > | o If the target location is a complex-multi-valued attribute and = a > | complex filter is specified based on the attribute's sub- > | attributes, the matching records are replaced. > | > | o If the target location is a complex-multi-valued attribute with = a > | complex filter and a specific sub-attribute (e.g. = "addresses[type > | eq "work"].streetAddress"), the matching sub-attribute of the > | matching record is replaced. > | > | The following example shows how to replace all the members of a = group > | with a different members list in a single replace operation. Some > | text removed for readability ("..."): > | > |PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Content-Type: application/json > Authorization: Bearer h480djs93hd8 > If-Match: W/"a330bc54f0671c9" >=20 > { > | "op":"replace", > | "path":"members", > | "value":[ > { > | "display": "Babs Jensen", > | "$ref": > "https://example.com/v2/Users/2819c223-...919d-413861904646", > | "value": "2819c223-7f76-453a-919d-413861904646" > | }, > | { > | "display": "James Smith", > | "$ref": "https://example.com/v2/Users/08e1d05d- > 121c-...473d93df9210", > | "value": "08e1d05d-121c-4561-8b96-473d93df9210" > } > ] > } > | The following example shows how to change a User's entire "work" > | address. >=20 > PATCH /Users/2819c223-7f76-453a-919d-413861904646 > Host: example.com > Accept: application/json > Content-Type: application/json > Authorization: Bearer h480djs93hd8 > If-Match: W/"a330bc54f0671c9" >=20 > { > | "op":"replace", > | "path":"addresses[type eq \"work\"]", > | "value": > { > "type": "work", > "streetAddress": "911 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "US", > "formatted": "911 Universal City Plaza\nHollywood, CA 91608 = US", > "primary": true > } > } >=20 > | The following example shows how to change a User's address. Since > | address does not have a value Sub-Attribute, the existing address > | must be removed and the modified address added. >=20 > PATCH /Users/2819c223-7f76-453a-919d-413861904646 > Host: example.com > Accept: application/json > Content-Type: application/json > Authorization: Bearer h480djs93hd8 > If-Match: W/"a330bc54f0671c9" >=20 > { > | "op":"replace", > | "path":"addresses[type eq \"work\"].streetAddress", > | "value":"911 Universal City Plaza" > } >=20 > |3.3.2.5. Test Operation >=20 > | The "test" operation tests the value at the target location = specified > | by the "path"is equal to the specified value. The operation = performs > | the following functions depending on the target location specified = by > | "path": >=20 > | o If the target location is a single-value attribute, the = attributes > | value is compared for equality to the value specified. >=20 > | o If the target location is a multi-valued attribute and no = filter > | is specified, all values are compared as if the "eq" filter = were > | applied to the attribute. >=20 > | o If the target location is a multi-valued attribute and a = complex > | filter is specified comparing a "value", the values matched by = the > | filter are compared for equality to the value specified. >=20 > | o If the target location is a complex-multi-valued attribute and = a > | complex filter is specified based on the attribute's sub- > | attributes, the matching record is compared for equality to the > | value specified. >=20 > | o If the target location is a complex-multi-valued attribute with = a > | complex filter and a specific sub-attribute (e.g. = "addresses[type > | eq "work"].streetAddress"), the matching sub-attribute of the > | matching record is compared to the value specified. > | > | The following is an example of a test operation performing > | conditional replace if a record has a specific value. >=20 > PATCH /Users/2819c223-7f76-453a-919d-413861904646 > Host: example.com > Accept: application/json > Content-Type: application/json > Authorization: Bearer h480djs93hd8 > If-Match: W/"a330bc54f0671c9" >=20 > | [ > { > | "op":"test", > | "path":"addresses[type eq \"work\"].streetAddress", > | "value":"100 Universal City Plaza" > | }, > | { > | "op":"replace", > | "path":"addresses[type eq \"work\"].streetAddress", > | "value":"911 Universal City Plaza" > } > | ] >=20 >=20 > }}} >=20 > --=20 > = -------------------------+------------------------------------------------= - > Reporter: | Owner: = draft-ietf-scim-api@tools.ietf.org > melinda.shore@gmail.com| Status: new > Type: task | Milestone: > Priority: major | Version: > Component: api | Resolution: > Severity: - | > Keywords: | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: = > scim >=20 From nobody Mon Mar 17 06:21:58 2014 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 A148C1A0408 for ; Mon, 17 Mar 2014 06:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, 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 79ItKWryBBX3 for ; Mon, 17 Mar 2014 06:21:53 -0700 (PDT) Received: from mailserver.daasi.de (mailserver.daasi.de [178.63.152.251]) by ietfa.amsl.com (Postfix) with ESMTP id 20F1F1A0407 for ; Mon, 17 Mar 2014 06:21:52 -0700 (PDT) Received: by mailserver.daasi.de (Postfix, from userid 1001) id AB0BE401AD8; Mon, 17 Mar 2014 14:21:42 +0100 (CET) Received: from [192.168.100.126] (fw.daasi.de [85.220.140.34]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailserver.daasi.de (Postfix) with ESMTPS id 4894E401AD9; Mon, 17 Mar 2014 14:21:39 +0100 (CET) Message-ID: <5326F6E4.1050804@daasi.de> Date: Mon, 17 Mar 2014 14:21:40 +0100 From: Peter Gietz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Phil Hunt References: <531B8B0F.6000800@mnt.se> <531D7D6F.60204@daasi.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Z5aYcfI9t77faMLsdnTgq0Yb-P4 Cc: scim@ietf.org Subject: Re: [scim] consensus call on moving issues to extension drafts 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: Mon, 17 Mar 2014 13:21:56 -0000 Phil, Thanks for this input and the implicit encouragement. Peter Am 15.03.2014 19:01, schrieb Phil Hunt: > Peter, > > I closed the issue per the message from Leif on Mar 8 and the general discussion at IETF89. I'm still assuming you will proceed to submit a separate draft rather than tracking this item against the existing drafts. > > I seem to recall in the IETF89 meeting, someone mentioned they are finding it easier to extend LDAP implementations internally to support complex attributes for SCIM rather than use a mapping. > > FWIW. I think one-way mappings where LDAP is a provisioning end-point is a very useful draft to have. In this case I would expect that read-after-write dual-mapping is not expected. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On 2014-03-10, at 1:53 AM, Peter Gietz wrote: > >> Am 08.03.2014 22:26, schrieb Leif Johansson: >>> At the London meeting there was strong consensus for identifying the >>> issues that are represent proposed extensions to the core specifications >>> and do the following: >>> >>> 1. Close the issue with "no-fix" >>> 2. Encourage anyone to write a draft describing the extended functionality. >>> >>> Such drafts can either be processed as individual submissions or >>> considered as part of a possible re-charter discussion in the WG when >>> the core documents are done. >>> >>> The following issues have been identified: >>> >>> #11 - Define a very simple language for entitlements >>> #14 - Enhance password and login metadata >>> #15 - Add specification for soft delete and reanimation operation as an >>> extension of core spec >>> #20 - Insert a "person" resource into the model (schema) >>> #32 - Async / Workflow Support >>> >>> In addition the following issues will also be closed as they do not >>> represent issues of the core specifications. Note that these issues >>> remain as milestones in our existing charter until the ADs say otherwise. >>> >>> #4 - Bring the SAML binding up-to-date >>> #45 - LDAP mapping >> I am very sorry that I did not act on this yet. I may still write a draft, if not as WG submission then as individual. >> >> Cheers, >> >> Peter >> >>> Given the support this had in London we are looking for anyone that >>> disagrees with this plan. >>> >>> Cheers Leif & Morteza >>> >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> >> -- >> >> Peter Gietz, CEO >> >> DAASI International GmbH >> Europaplatz 3 >> D-72072 Tübingen >> Germany >> >> phone: +49 7071 407109-0 >> fax: +49 7071 407109-9 >> email: peter.gietz@daasi.de >> web: www.daasi.de >> >> Sitz der Gesellschaft: Tübingen >> Registergericht: Amtsgericht Stuttgart, HRB 382175 >> Geschäftsleitung: Peter Gietz >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim -- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz From nobody Mon Mar 17 06:22:18 2014 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 1609B1A0404 for ; Mon, 17 Mar 2014 06:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, 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 XzjD_JvOr1qt for ; Mon, 17 Mar 2014 06:22:15 -0700 (PDT) Received: from mailserver.daasi.de (mailserver.daasi.de [178.63.152.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA301A011C for ; Mon, 17 Mar 2014 06:22:15 -0700 (PDT) Received: by mailserver.daasi.de (Postfix, from userid 1001) id 86F3E401ADB; Mon, 17 Mar 2014 14:22:07 +0100 (CET) Received: from [192.168.100.126] (fw.daasi.de [85.220.140.34]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailserver.daasi.de (Postfix) with ESMTPS id 50C5D4002B5 for ; Mon, 17 Mar 2014 14:22:06 +0100 (CET) Message-ID: <5326F6FE.5020608@daasi.de> Date: Mon, 17 Mar 2014 14:22:06 +0100 From: Peter Gietz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: scim@ietf.org References: <531B8B0F.6000800@mnt.se> <531D7D6F.60204@daasi.de> <53257658.90807@mnt.se> In-Reply-To: <53257658.90807@mnt.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Hj6IYv8HIcyWuEApO2eGpaizoDg Subject: Re: [scim] consensus call on moving issues to extension drafts 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: Mon, 17 Mar 2014 13:22:17 -0000 Am 16.03.2014 11:00, schrieb Leif Johansson: > On 2014-03-10 09:53, Peter Gietz wrote: >> Am 08.03.2014 22:26, schrieb Leif Johansson: >>> At the London meeting there was strong consensus for identifying the >>> issues that are represent proposed extensions to the core specifications >>> and do the following: >>> >>> 1. Close the issue with "no-fix" >>> 2. Encourage anyone to write a draft describing the extended >>> functionality. >>> >>> Such drafts can either be processed as individual submissions or >>> considered as part of a possible re-charter discussion in the WG when >>> the core documents are done. >>> >>> The following issues have been identified: >>> >>> #11 - Define a very simple language for entitlements >>> #14 - Enhance password and login metadata >>> #15 - Add specification for soft delete and reanimation operation as an >>> extension of core spec >>> #20 - Insert a "person" resource into the model (schema) >>> #32 - Async / Workflow Support >>> >>> In addition the following issues will also be closed as they do not >>> represent issues of the core specifications. Note that these issues >>> remain as milestones in our existing charter until the ADs say otherwise. >>> >>> #4 - Bring the SAML binding up-to-date >>> #45 - LDAP mapping > I declare consensus on this issue and will close the tickets accordingly. A wise decision anyway. Cheers, Peter > > Cheers Leif > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim -- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz From nobody Wed Mar 19 05:59:42 2014 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 E3DDC1A0750 for ; Wed, 19 Mar 2014 05:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ptAW4uLYjupk for ; Wed, 19 Mar 2014 05:59:39 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7E01A0048 for ; Wed, 19 Mar 2014 05:59:38 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id y1so5992531lam.9 for ; Wed, 19 Mar 2014 05:59:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SMpI5Jg1JHDOGXo7QNkTETMQhstecSm4A8k2IQMRJ34=; b=iIJ+wmiN+XfyCcSPOD0NtsNNS/Qtf7ZA+4Yi18QLVnST4UUAr0BGa9E5iC7Gi7ffOV yzwl8UNLksQBmreie4uGv5VlJu3Q0K+xxnhMhwgg+RTaa5pTn1jh3LYcMkW6Q46sTd5h xmrynJQB81BYx+msouFRL4Xg+Bcj3+DFcTCfJIrRi34iFTi+KS2TyvSj5HTFXF9tCehB erXz04QZr/o4cE3xyo1MkzUxM1pYwbOFpdMXg+4blPuwYuI7rl0Nl8OH0Jfg1TdyKj7G XPsSCD3mymtfzgDeIoTpUeTAnLwsgguyORgmVM9HPtCOZiBA6U/BuofiTJkyI0LMQxqa xVdA== X-Gm-Message-State: ALoCoQlSNy6y9ObWZsSBIknvBZ5YrBl51DrVx3k63szgNeyxkSBF0ChXSTYHNaYNYS1qHwPy8CbP X-Received: by 10.152.1.8 with SMTP id 8mr25519486lai.1.1395233969673; Wed, 19 Mar 2014 05:59:29 -0700 (PDT) Received: from [172.20.10.3] (2.70.54.138.mobile.tre.se. [2.70.54.138]) by mx.google.com with ESMTPSA id f9sm19872871laa.8.2014.03.19.05.59.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 05:59:28 -0700 (PDT) Message-ID: <532994AB.4080707@mnt.se> Date: Wed, 19 Mar 2014 13:59:23 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "scim@ietf.org" References: <5325DD3B.6090009@mnt.se> In-Reply-To: <5325DD3B.6090009@mnt.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/6s5fkGdP2xMJi_o5vvL_ETlZQ7w Subject: Re: [scim] consensus-call: close #6 as won't fix 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, 19 Mar 2014 12:59:41 -0000 On 2014-03-16 18:19, Leif Johansson wrote: > There was support in London for rejecting the proposal to move nicname > to a sub-attribute of name. > > Please respond here if you *object* to closing #6 with won't fix. > > Cheers Leif & Morteza > I'm calling this. Closing the issue. From nobody Wed Mar 19 06:06:25 2014 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 A217E1A0750 for ; Wed, 19 Mar 2014 06:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.547, SPF_NEUTRAL=0.779] 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 MY7puFEXdo8v for ; Wed, 19 Mar 2014 06:06:21 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 27D451A0731 for ; Wed, 19 Mar 2014 06:06:20 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s2JD6BLw002759 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 19 Mar 2014 14:06:11 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s2JD68Fe015194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Mar 2014 14:06:11 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [172.20.10.3] ([2.70.54.138]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.2) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128 bits)) for scim@ietf.org; Wed, 19 Mar 2014 14:06:08 +0100 Message-ID: <5329963F.6070106@sunet.se> Date: Wed, 19 Mar 2014 14:06:07 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "scim@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09LDp6bW9 - ab4bc8048fad - 20140319 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/scim/12fKXbHEHHvbk53F1OQc-FZHOvk Subject: [scim] confirming consensus calls: #43 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, 19 Mar 2014 13:06:23 -0000 In London there was consensus in the room for dropping short-hand notation for complex multi-valued attributes. Please respond if you *object* to this way of handing #43 BestR Leif & Morteza From nobody Wed Mar 19 06:12:05 2014 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 845F61A0751 for ; Wed, 19 Mar 2014 06:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 UZTNBHh0KCh4 for ; Wed, 19 Mar 2014 06:12:01 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by ietfa.amsl.com (Postfix) with ESMTP id 542C21A03CA for ; Wed, 19 Mar 2014 06:11:59 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id hr17so5888547lab.33 for ; Wed, 19 Mar 2014 06:11:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wSLhah7FLC1isc+Wh+pBPReOzlUB+EIJjSqOAVUNOXU=; b=GE6ZU6IE+nN5gOOFzI1JXE78QLgf/K7QZVPOI1+d7sWmMdLm5DFmj/MJIOkWCQ8iKh LluxtnZ57+UpWEGEyW5CwOE0Dq6HgJ5EDNtgSfZ01lqpGcRQy+pCD0ikqgJOomo2R8NB L9Ski2z+ja9GJryOFKpzGtWqJIVoi7YRl9h9ukx2Rbi3Cyt4TF+gNdwPWsW8MUC1BeTQ Od9cSBSFx7DR+c9ozgsmkVppWodEfPRyPYVd6MZ5+XJmxhdsRyGCnhw2tFAoaKPt7cBA nVyVM8Y/juQkBvFzn/MWKWddvxQpm9NjE6Smnw9zVTRdgddhCXvtotfYE+m52IJBmVus ejXg== X-Gm-Message-State: ALoCoQm0wNS8629HkHfoQ8Zq6i9WKJuRDJNJibVTxVNrccV6jyWT5TniGa29IB51YhMUSlTYkMMR X-Received: by 10.152.120.195 with SMTP id le3mr25925331lab.6.1395234709831; Wed, 19 Mar 2014 06:11:49 -0700 (PDT) Received: from [172.20.10.3] (2.70.54.138.mobile.tre.se. [2.70.54.138]) by mx.google.com with ESMTPSA id a2sm9175607lbz.25.2014.03.19.06.11.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 06:11:48 -0700 (PDT) Message-ID: <53299792.80703@mnt.se> Date: Wed, 19 Mar 2014 14:11:46 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: scim@ietf.org References: <52DFA17F.8070305@gmx.de> <59379804-1702-460F-9253-B738CFE63CAF@oracle.com> <5303D269.5030100@gmx.de> <5303D7B6.5070506@gmx.de> <5303E558.1000002@gmx.de> <8269C6F4-9A25-4E49-8D4E-9A7914F1651A@oracle.com> In-Reply-To: <8269C6F4-9A25-4E49-8D4E-9A7914F1651A@oracle.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/widwIB5vwuvqOL03lQhCdSybgFA Subject: [scim] Drop X-HTTP-Method-Override [was: Re: http://tools.ietf.org/html/draft-ietf-scim-api-02#section-3.12: "X-HTTP-Method-Override"] 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, 19 Mar 2014 13:12:02 -0000 On 2014-02-19 01:07, Phil Hunt wrote: > I have added a ticket: > http://trac.tools.ietf.org/wg/scim/trac/ticket/65 > > Comments appreciated (either here on this thread), or directly on the ticket. Especially from anyone who thinks we need to keep it. > Based on the discussion in London and feedback from the HTTP community I believe the appropriate solution is to drop X-HTTP-Method-Override from the API spec. In practice server implementations may choose to support such a feature but it seems clear that it is orthogonal to the SCIM API and therefore it will only add overhead to our specs. Please respond with +1/-1 for this proposal! Cheers Leif From nobody Wed Mar 19 06:14:53 2014 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 D63281A068F for ; Wed, 19 Mar 2014 06:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 1L_cx4SP5M26 for ; Wed, 19 Mar 2014 06:14:50 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id BFEE71A0731 for ; Wed, 19 Mar 2014 06:14:49 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id y1so5882382lam.37 for ; Wed, 19 Mar 2014 06:14:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=w3s/gUmSDB8oWXrt8qPibMncmraPR5FAwipgWKJqROs=; b=mCQen8g7Z6hI2L7cHaigaU8HGtoNLBZnuEEkvR3Wtt6W1Yf0vrGWZOj9R+b+xouiO7 ed9VuEGfyzbnd7F5paBvOnAKPPLPPtF8QVklvbbTMlSGxTqD5wwC2/lN1Gi9eeFz5/+b fPRRDiJH7YSQBpC4VzpfP4w8jX2vSc0e7nS/FNzfjdMt1e5ub1fbSJK2Nt5U25cph4tr 871ubwKFDd6Pnz0AvxwrXtesQruP62fBD0ageDiyieHXzxtroiPOLfKl1YosAG1enRQL FDHk2tY6pphVpY9qYBQVPnFKcBOcd+u5wrEjWIQsU1U/E7b4Xt6ciPr5Qhfn2tzMJAp2 O3fQ== X-Gm-Message-State: ALoCoQlO8nJ7t/2CJRohDIdXlvH1MrJ5FU71QrIPlb3/Z4gVpEi/MV/M5i4VwAMGr0DXqk+MgS/G X-Received: by 10.112.198.69 with SMTP id ja5mr1199273lbc.50.1395234880627; Wed, 19 Mar 2014 06:14:40 -0700 (PDT) Received: from [172.20.10.3] (2.70.54.138.mobile.tre.se. [2.70.54.138]) by mx.google.com with ESMTPSA id u4sm19917009laj.2.2014.03.19.06.14.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 06:14:39 -0700 (PDT) Message-ID: <5329983E.9040507@mnt.se> Date: Wed, 19 Mar 2014 14:14:38 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "scim@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Q6utgH8JfY6GGnsrRRUDzMlPldo Subject: [scim] Drop SCIM_TENANT_ID (issue #70) 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, 19 Mar 2014 13:14:52 -0000 This is (not entirely un)related to X-HTTP-Method-Override. Based on the discussion in London I believe it is appropriate to drop the reference to SCIM_TENANT_ID in the api draft. Anyone who wants to come up with a specification for the header is free to do so as an extension. Cheers Leif From nobody Wed Mar 19 06:25:07 2014 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 874A91A076C for ; Wed, 19 Mar 2014 06:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 g40PwpJeAMh2 for ; Wed, 19 Mar 2014 06:25:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id A52481A0771 for ; Wed, 19 Mar 2014 06:25:01 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.0.898.11; Wed, 19 Mar 2014 13:24:52 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.13]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.19]) with mapi id 15.00.0898.005; Wed, 19 Mar 2014 13:24:51 +0000 From: Kelly Grizzle To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] Drop X-HTTP-Method-Override [was: Re: http://tools.ietf.org/html/draft-ietf-scim-api-02#section-3.12: "X-HTTP-Method-Override"] Thread-Index: AQHPQ3TPleaclPEm+EOge2jrYJm46ZroZj7Q Date: Wed, 19 Mar 2014 13:24:51 +0000 Message-ID: <6b25e122c52d49ecac9e9ca38b0b6699@BN1PR04MB392.namprd04.prod.outlook.com> References: <52DFA17F.8070305@gmx.de> <59379804-1702-460F-9253-B738CFE63CAF@oracle.com> <5303D269.5030100@gmx.de> <5303D7B6.5070506@gmx.de> <5303E558.1000002@gmx.de> <8269C6F4-9A25-4E49-8D4E-9A7914F1651A@oracle.com> <53299792.80703@mnt.se> In-Reply-To: <53299792.80703@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 19E1F03F006B8E19E1F18C x-originating-ip: [97.79.140.10] x-forefront-prvs: 01559F388D x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(199002)(189002)(24454002)(377424004)(377454003)(51704005)(74876001)(15202345003)(74366001)(561944002)(47976001)(50986001)(4396001)(49866001)(74706001)(46102001)(77982001)(69226001)(20776003)(63696002)(81342001)(33646001)(81542001)(66066001)(59766001)(79102001)(74316001)(76482001)(65816001)(80022001)(77096001)(76796001)(47736001)(76786001)(76576001)(220493001)(54356001)(56776001)(53806001)(2656002)(51856001)(81816001)(87936001)(87266001)(19580405001)(56816005)(90146001)(83072002)(93516002)(85852003)(15975445006)(95666003)(19580395003)(80976001)(74662001)(81686001)(47446002)(97336001)(54316002)(85306002)(83322001)(74502001)(97186001)(94946001)(31966008)(93136001)(92566001)(94316002)(86362001)(95416001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:3B7E4176.AF319FE8.7D51BCB8.C8ED5E30.201E1; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: sailpoint.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/38p8-mBEvkgLlYf5ryF8K--uVyw Subject: Re: [scim] Drop X-HTTP-Method-Override [was: Re: http://tools.ietf.org/html/draft-ietf-scim-api-02#section-3.12: "X-HTTP-Method-Override"] 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, 19 Mar 2014 13:25:04 -0000 +1 to drop -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson Sent: Wednesday, March 19, 2014 8:12 AM To: scim@ietf.org Subject: [scim] Drop X-HTTP-Method-Override [was: Re: http://tools.ietf.org= /html/draft-ietf-scim-api-02#section-3.12: "X-HTTP-Method-Override"] On 2014-02-19 01:07, Phil Hunt wrote: > I have added a ticket: > http://trac.tools.ietf.org/wg/scim/trac/ticket/65 >=20 > Comments appreciated (either here on this thread), or directly on the tic= ket. Especially from anyone who thinks we need to keep it. >=20 Based on the discussion in London and feedback from the HTTP community I be= lieve the appropriate solution is to drop X-HTTP-Method-Override from the A= PI spec. In practice server implementations may choose to support such a feature but= it seems clear that it is orthogonal to the SCIM API and therefore it will= only add overhead to our specs. Please respond with +1/-1 for this proposal! Cheers Leif _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From nobody Mon Mar 24 15:19:36 2014 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 0D7981A02AE for ; Mon, 24 Mar 2014 15:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.192 X-Spam-Level: * X-Spam-Status: No, score=1.192 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 DDY8gTLJfRbr for ; Mon, 24 Mar 2014 15:19:33 -0700 (PDT) Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3F91A02A2 for ; Mon, 24 Mar 2014 15:19:33 -0700 (PDT) Received: from [98.139.215.143] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 24 Mar 2014 22:19:32 -0000 Received: from [98.139.212.200] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 24 Mar 2014 22:19:32 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 24 Mar 2014 22:19:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 558858.81588.bm@omp1009.mail.bf1.yahoo.com Received: (qmail 97031 invoked by uid 60001); 24 Mar 2014 22:19:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395699572; bh=HlyvfAP0y/cJwz+d7TfXUhd+KcEu4cBb+0TyctJWViU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=FwRUI/x+TewPxIoz1cjH4Y/7wOlpPhMHgzGxQXv9JiE5nvYwlMJnRAYyaWdT/wKc2mlj6z9qAiHO3ueLUqxr+TUCgc8PV1KAkA0T8Lrx21hfAqBisKdntd80YSjGYrlBk7MQghkISKvUcpUXT2h0XqFrAG3ooRv98EKaZZUbabM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=qeuQPfnaDcOgRS/Atd+jN+uFaR4npE4xtBlRPvzw9L4aSwOV6iu5dYus6knfJLMfRg/uliov6t5LdmPAz9nVlBjLnFNKlHCjo3zpuGoeiqZztcc4UWTDzRL+HeLpIdlBkkMshxHbfFmWx4nc/Yawfods6liiZUO1piFzeTAs1IE=; X-YMail-OSG: MO1HS54VM1ll5eJVzlKzZ5DcYEOnWaaiPkkqxW4d47o487J RkmLClXfmWJrBjdp708fRbUFdQgs4gpSkQABxRXicWgLUSKVVqtSy6Sq2tPO SbqUp9Uo6zjtWDFQ53EpRa8NDe_vdjyJNLmmCuxHW3qzyJqswZJyLT7cb8VB e__A8P6YCDuikf9nqFn.3ub2X2OYBspdQnQIi7Ez5xaVUYYqO9y5LxS7c_Ms aQa80i3MumxdDWhy.q3apcGxGLWgaEQR.4k8xMw1aVf9rjAE54ciu7lGuU6y pMmyxkOuCUemACewlfZQDAkCscSvWmyhTJryKtQ8oTBgYSNwrWPrJtvKSL1S M4b0QED3GTeO0PMWh5jvB3MkiNtavWMkJYw7TNZRx2T2RUO1Hos5j4g2U6vF CgfieRGjfsejDA.en0PsQBejSuFQGqFGyjZ64j21_pGtRtASxu3mejfNEmY2 wan3JNmcHmqVXVi5u9COPJXlcmZEpY5XEQBiOD2ouf0tyc48gvOJOB5.Y1K2 zkt5oY43xsLxz3GLf8DWR54B5t.zz14hRQsvcTwsc9hxZ4._mD6_2pVLIbn4 hjQ-- Received: from [66.228.162.52] by web142803.mail.bf1.yahoo.com via HTTP; Mon, 24 Mar 2014 15:19:32 PDT X-Rocket-MIMEInfo: 002.001, Im1ldGEiIGlzIHVzZWQgdG8gcmV0dXJuIG1ldGFkYXRhIGFib3V0IGVudHJpZXMgYW5kIGluIHRoZSBjYXNlIG9mIFBBVENIIGl0J3MgdXNlZCB0byBzcGVjaWZ5IGVsZW1lbnRzIHRvIGRlbGV0ZS4gwqAgSSdkIGxpa2UgdG8gcHJvcG9zZSBhIG5ldyAibWV0YSIgZWxlbWVudCBmb3IgYWN0aW9uIHRvIGJlIHRha2VuLiDCoEkgdGhpbmsgdGhpcyB3b3VsZCBzb2x2ZSBzb21lIG9mIHRoZSBxdWVzdGlvbiBvZiB0cmlnZ2VyaW5nIGFjdGlvbnMgYmFzZWQgb24gYSBQQVRDSC4gwqBTbyBmb3IgZXhhbXBsZToKCiIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.181.645 Message-ID: <1395699572.32920.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Mon, 24 Mar 2014 15:19:32 -0700 (PDT) From: Bill Mills To: "scim@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="905790552-383217884-1395699572=:32920" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ueiLXY8DXtWeVxeXDKnh6pvn6WA Subject: [scim] metadata and actions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 22:19:35 -0000 --905790552-383217884-1395699572=:32920 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable "meta" is used to return metadata about entries and in the case of PATCH it= 's used to specify elements to delete. =A0 I'd like to propose a new "meta"= element for action to be taken. =A0I think this would solve some of the qu= estion of triggering actions based on a PATCH. =A0So for example:=0A=0A"met= a": { "action": ["SuspendUser", "DeleteMailbox"]=0A}=0A=0ASpecifies 2 actio= ns to be taken along with whatever data changes are applied.=0A=0ADoes this= sound workable?=0A=0A-bill --905790552-383217884-1395699572=:32920 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
"meta" is used to return metadata about entries and in t= he case of PATCH it's used to specify elements to delete.   I'd like t= o propose a new "meta" element for action to be taken.  I think this w= ould solve some of the question of triggering actions based on a PATCH. &nb= sp;So for example:

}

Specifies 2 actions=
 to be taken along with whatever data changes are applied.

Does this sound workable?

-bil=
l
--905790552-383217884-1395699572=:32920-- From nobody Mon Mar 24 20:20:45 2014 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 3840C1A0330 for ; Mon, 24 Mar 2014 20:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 gvkTCNZP4ut1 for ; Mon, 24 Mar 2014 20:20:41 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 957DC1A0325 for ; Mon, 24 Mar 2014 20:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4961; q=dns/txt; s=iport; t=1395717641; x=1396927241; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=DU9P4W7fqyWhlDChpPKrVH73wZ/koNzezEBk+pZwAss=; b=LDg85Xvlpqmtq/0vTjM6CnpnYzb6cyNu3MbfYf3c1W0ml9GSVIR5oKZe pHTnIEzpg2yO5QFB3kFFonQ/74iozV97tAYNQt25d87q6oeTtTAX4EaOT niczWccWjlcxDgVhHP4cGMYp0/iEXL9vgOdsaXFvkY8V3/OUAMm1pv+O2 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFALv1MFOtJV2Z/2dsb2JhbABZgkJEgRKsAZZmgSIWdIIlAQEBBG4bAgEIDgMDAQIoBzITAQkIAgQBEodlAxHPHheMXYIMGIQ4AQOHYo8BgWeHWYUPhUmDLYFpIx8 X-IronPort-AV: E=Sophos; i="4.97,725,1389744000"; d="scan'208,217"; a="30070303" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 25 Mar 2014 03:20:40 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2P3KeEa028280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 03:20:40 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.10]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 22:20:39 -0500 From: "Morteza Ansari (moransar)" To: Bill Mills , "scim@ietf.org" Thread-Topic: [scim] metadata and actions Thread-Index: AQHPR68mXFUJU0t7d0y+oZLHpfClpprxAXyA Date: Tue, 25 Mar 2014 03:20:39 +0000 Message-ID: References: <1395699572.32920.YahooMailNeo@web142803.mail.bf1.yahoo.com> In-Reply-To: <1395699572.32920.YahooMailNeo@web142803.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.89.50] Content-Type: multipart/alternative; boundary="_000_CF5642FCD2D7Bmoransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/43lQvBidRXpLLbJnK1N7jJOcbpk Subject: Re: [scim] metadata and actions 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: Tue, 25 Mar 2014 03:20:44 -0000 --_000_CF5642FCD2D7Bmoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Bill, Can you expand on the problem this would solve? I know this came up on one= of the calls a while ago but I don=92t think the problem is clearly captur= ed on the mailing list before. Cheers, Morteza From: Bill Mills > Reply-To: Bill Mills = > Date: Monday, March 24, 2014 at 3:19 PM To: "scim@ietf.org" > Subject: [scim] metadata and actions "meta" is used to return metadata about entries and in the case of PATCH it= 's used to specify elements to delete. I'd like to propose a new "meta" e= lement for action to be taken. I think this would solve some of the questi= on of triggering actions based on a PATCH. So for example: "meta": { "action": ["SuspendUser", "DeleteMailbox"] } Specifies 2 actions to be taken along with whatever data changes are applie= d. Does this sound workable? -bill --_000_CF5642FCD2D7Bmoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6036ED102E2F6F48A0A51B1BAC55F52C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Bill,

Can you expand on the problem this would solve?  I know this came= up on one of the calls a while ago but I don=92t think the problem is clea= rly captured on the mailing list before.


Cheers,
Morteza

From: Bill Mills <wmills_92105@yahoo.com>
Reply-To: Bill Mills <wmills_92105@yahoo.com>
Date: Monday, March 24, 2014 at 3:1= 9 PM
To: "scim@ietf.org" <scim@i= etf.org>
Subject: [scim] metadata and action= s

"meta": { "action": ["SuspendUser", "DeleteMailbox"= ] 
}

Specifies 2 actions to be taken along with whatever data changes are a= pplied.

Does this sound workable?

-bill
 --_000_CF5642FCD2D7Bmoransarciscocom_-- From nobody Mon Mar 24 21:17:11 2014 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 602381A0353 for ; Mon, 24 Mar 2014 21:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.003 X-Spam-Level: * X-Spam-Status: No, score=1.003 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 kredvygtO8J0 for ; Mon, 24 Mar 2014 21:17:08 -0700 (PDT) Received: from nm35.bullet.mail.bf1.yahoo.com (nm35.bullet.mail.bf1.yahoo.com [72.30.238.197]) by ietfa.amsl.com (Postfix) with ESMTP id 3A97B1A034C for ; Mon, 24 Mar 2014 21:17:08 -0700 (PDT) Received: from [98.139.215.142] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 25 Mar 2014 04:17:07 -0000 Received: from [98.139.212.227] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 25 Mar 2014 04:17:06 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 25 Mar 2014 04:17:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 887606.75419.bm@omp1036.mail.bf1.yahoo.com Received: (qmail 53226 invoked by uid 60001); 25 Mar 2014 04:17:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395721026; bh=QqB/PLJvs2BZsDUa73Y1LHm8Cb07ZIh5mwwpXUQkYcI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fJjLcdaZQTNk9K2gmr/tB2XsypjfGRCXCPNK1Po1YDb1us06wfbLBiPrn6mO6xxD0ZY6MCedAfD9xHMgL5QyKlwx4ugr5O0QxmssWYb1qZZgGLHXSOKxc9LNvKzqCg8IWwsud5O25PyKlLb0Mf5PDQmA7qyDXzSpgpB+K+HmieE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=4sY1fgzsvazlxL2PgwosQQTxUESlC+gB7iykXvWWtcNlqCeVfkAf5E+DNTMOTGV6OW0EGIhI2LKKZvw5WPbJCs74c+o1EZAHZ87TWeN056HYgiFaKje2O/PhYpH+Hg0GDuMyacnK/GPFJhpHlNOCkGO6aZAd8bKVFTWvWucNuDI=; X-YMail-OSG: VJbUUY8VM1mMAH.3kl606p9zRplsBVZOd31nraCLrbGcYN3 SVralCNi2U8x63CzGDf6f0wJQFvxoiovLaOnDJEKgRpX6CGT_I6wxldmMP6x hBR6L7x_3wm6FjGCnh76cvDfwFcdzteyfHHj6AV9CIryw3DlHE8ZzvzRTyi. bZkCzhoEChYOcupjZ1ncarWddzN3rPQCufF_S6F.okmfQMm.ur2JxCGaVgtw 5W03BE2IP_XJrL4xBz52xKsIsN2MBNJdbSk5nSPISl3cvDk0tOnqq58_qPc4 WV.p9ez537ZB350HjIbCW1DOD139Xgvrki90ZPMhxHL_QSOYEnSk28Z91fyC k7Vwsowaz2uO1tdzCdmkF35HLbkk4ySOfm52zmjW.pnBdB01CKZ.xGZeU8Jl N9r4BqVgaa.abKgwnXqdA4UkdpjlHH_UGe2BJddXa24uCosa0pl1z1xW9lIK 2uf4tUFLptso3jLRf_TIFlriYFLey86nCy9t2pQS7yxUxbfXvFLWkmuHIwxd WSI5C8A4Wn9yccYNOhaexWsVkGnu_bSkNnO_nBwJ.pseARQ36 Received: from [99.31.212.42] by web142806.mail.bf1.yahoo.com via HTTP; Mon, 24 Mar 2014 21:17:06 PDT X-Rocket-MIMEInfo: 002.001, VGhlIHByb2JsZW0gaXMgdGhhdCBpbiBhIFBBVENIIG9yIFBVVCBhbnkgYWN0aW9uIHRvIGJlIHRha2VuIG9uIHRoZSBhY2NvdW50IGhhcyB0byBiZSBpbmZlcnJlZCBmcm9tIHRoZSBkYXRhIGNoYW5nZXMuIMKgVGhpcyBhbHNvIG1lYW5zIHRoYXQgZXZlcnlvbmUgaGFzIHRvIHNoYXJlIHRoZSBlbnRpcmUgc2NoZW1hIGZvciBob3cgYW4gYWNvdW50IGlzIG1hbmFnZWQuCgpXZSBoYXZlIGEgc3lzdGVtIHRoYXQgbG9va3MgdmVyeSBtdWNoIGxpa2UgU0NJTSAobm90IGEgc3VwcmlzZSBzaW5jZSBTQ0lNIGlzIHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.181.645 References: <1395699572.32920.YahooMailNeo@web142803.mail.bf1.yahoo.com> Message-ID: <1395721026.16897.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Mon, 24 Mar 2014 21:17:06 -0700 (PDT) From: Bill Mills To: "Morteza Ansari \(moransar\)" , "scim@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="515012262-2036511253-1395721026=:16897" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ahQukTFwhl3XTpH177wigO9q1fs Subject: Re: [scim] metadata and actions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 04:17:10 -0000 --515012262-2036511253-1395721026=:16897 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The problem is that in a PATCH or PUT any action to be taken on the account= has to be inferred from the data changes. =C2=A0This also means that every= one has to share the entire schema for how an acount is managed.=0A=0AWe ha= ve a system that looks very much like SCIM (not a suprise since SCIM is sta= ndardizing a common task) but we have action verbs with data. =C2=A0Compari= ng the two I much prefer the action verb with supporting data model. =C2=A0= In the current SCIM model actions have to be inferred from data changes.=0A= =0AFor example we might have a "create_mailbox" verb, where in SCIM I need = to compare the current state to the new state and dtermine that "mailbox_ac= tive" changed from "0" to "1". =C2=A0=C2=A0=0A=0A-bill=0A=0A=0A=0AOn Monday= , March 24, 2014 8:20 PM, Morteza Ansari (moransar) wr= ote:=0A =0ABill,=0A=0ACan you expand on the problem this would solve? =C2= =A0I know this came up on one of the calls a while ago but I don=E2=80=99t = think the problem is clearly captured on the mailing list before.=0A=0A=0AC= heers,=0AMorteza=0A=0AFrom: Bill Mills =0AReply-To:= Bill Mills =0ADate: Monday, March 24, 2014 at 3:19= PM=0ATo: "scim@ietf.org" =0ASubject: [scim] metadata and ac= tions=0A=0A=0A"meta" is used to return metadata about entries and in the ca= se of PATCH it's used to specify elements to delete. =C2=A0 I'd like to pro= pose a new "meta" element for action to be taken. =C2=A0I think this would = solve some of the question of triggering actions based on a PATCH. =C2=A0So= for example:=0A=0A"meta": { "action": ["SuspendUser", "DeleteMailbox"]=0A}= =0A=0ASpecifies 2 actions to be taken along with whatever data changes are = applied.=0A=0ADoes this sound workable?=0A=0A-bill=0A=0A___________________= ____________________________=0Ascim mailing list=0Ascim@ietf.org=0Ahttps://= www.ietf.org/mailman/listinfo/scim --515012262-2036511253-1395721026=:16897 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The problem is that in a PATCH or PUT any action t= o be taken on the account has to be inferred from the data changes.  T= his also means that everyone has to share the entire schema for how an acou= nt is managed.
<= span>
We hav= e a system that looks very much like SCIM (not a suprise since SCIM is stan= dardizing a common task) but we have action verbs with data.  Comparing the two I much prefer the action verb with supporting data= model.  In the current SCIM model actions have to be inferred from da= ta changes.

<= div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNe= ue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; backgr= ound-color: transparent; font-style: normal;">For example we might have a "= create_mailbox" verb, where in SCIM I need to compare the current state to = the new state and dtermine that "mailbox_active" changed from "0" to "1". &= nbsp; 

On M= onday, March 24, 2014 8:20 PM, Morteza Ansari (moransar) <moransar@cisco= .com> wrote:
=0A
Bill,
=0A

=0A=0A
Can you expand on the problem this would solve?  I know th= is came up on one of the calls a while ago but I don=E2=80=99t think the pr= oblem is clearly captured on the mailing list before.
=0A

=0A
=0A

=0A
=0A
Cheers,=0A
Morteza
=0A

=0A
=0A=0A
=0AFrom: Bill Mills <wmills_92105@yahoo.com>
=0AReply-To: Bill Mills <wmills_92105@yahoo.com>
=0ADate: Monday, March 24, 2014 = at 3:19 PM
=0ATo: "scim@ietf.org" <scim@ietf.org>
= =0ASubject: [scim] metadata and ac= tions
=0A
=0A

=0A
=0A=0A
=0A
=0A
"meta" is used to re= turn metadata about entries and in the case of PATCH it's used to specify e= lements to delete.   I'd like to propose a new "meta" element for acti= on to be taken.  I think this would solve some of the question of trig= gering actions based=0A on a PATCH.  So for example:
=0A

=0A
=0A
"meta": {=0A    "action": ["S=
uspendUser", "DeleteMailbox"]
=0A
}
=0A
=0A
=0A
Specifies 2 actions to be taken along with= whatever data changes are applied.
=0A
=0A
=0A
=0A
=0ADoes this sound workable?
=0A
=0A
=0A
=0A
=0A-bill
=0A
=0A
=0A=0A=0A

_______________________________________________
scim m= ailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim


--515012262-2036511253-1395721026=:16897-- From nobody Mon Mar 24 23:05:56 2014 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 E8A9B1A00F2 for ; Mon, 24 Mar 2014 23:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 zRewnAjRTcun for ; Mon, 24 Mar 2014 23:05:48 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 261621A0367 for ; Mon, 24 Mar 2014 23:05:47 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id d49so5259665eek.27 for ; Mon, 24 Mar 2014 23:05:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6tEdDz0LaEXhP9epH3n6XFvgeUcTWV3VvNxPvonRzAk=; b=jr3hJKOX9PGgYWE8YZcPpvfFffVOu0TxyzXKlocyQJ7d+ttIcAi4B00T9P1AARqKk4 brG8XgUoWwwmmHGQzE9UXHCTIieS3F0ss4M9AtYEjhpXfSXHBdJnObv0Qf4DXnq3utB0 3Jz+UFU+PruXoIs6qhN67brIpzQxeXuhGTfHhgnfY8nfQx1z2fE6wwrSgu+lYDqUjTrM ZHLOeeivayDXx2CzAhS/koaLarEovF+4WvkOg/AjGFnjdpWyt90AUBu7I5Y30OGVz6fQ Irt7WZK7EZ2ALO4Ux+1YCmSDDoO6Tetlqly4UjsY+zVDwZJOPRz1kHHZhUuiBJC74JtE dKAg== X-Gm-Message-State: ALoCoQl+Ptw9aZ0tFO/l29TuH/bdv2r8mkBTd1QXk+CD2o7HXTJXtNqck5+UTZcTueGNb0p4oRxc X-Received: by 10.15.43.132 with SMTP id x4mr1364646eev.59.1395727546655; Mon, 24 Mar 2014 23:05:46 -0700 (PDT) Received: from [172.24.12.173] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id z48sm38011513eel.27.2014.03.24.23.05.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Mar 2014 23:05:45 -0700 (PDT) Message-ID: <53311CB8.40007@tarent.de> Date: Tue, 25 Mar 2014 07:05:44 +0100 From: =?windows-1252?Q?David_M=F6bius?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: scim@ietf.org References: <1395699572.32920.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1395721026.16897.YahooMailNeo@web142806.mail.bf1.yahoo.com> In-Reply-To: <1395721026.16897.YahooMailNeo@web142806.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/krdy3rfvJh5HEktZijB4z6a6jm8 Subject: Re: [scim] metadata and actions 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: Tue, 25 Mar 2014 06:05:51 -0000 Hello Bill, I also don't realy understand why you need this action. For you two examples: SuspendUser: would be like active = false DeleteMailbox: The scim user has no mailbox so what should the system do? For my understanding a mailbox like something could only be a part of an extension but not of the standard user. So it looks like that the meta.action would be very client specific. by David Am 25.03.2014 05:17, schrieb Bill Mills: > The problem is that in a PATCH or PUT any action to be taken on the > account has to be inferred from the data changes. This also means that > everyone has to share the entire schema for how an acount is managed. > > We have a system that looks very much like SCIM (not a suprise since > SCIM is standardizing a common task) but we have action verbs with data. > Comparing the two I much prefer the action verb with supporting data > model. In the current SCIM model actions have to be inferred from data > changes. > > For example we might have a "create_mailbox" verb, where in SCIM I need > to compare the current state to the new state and dtermine that > "mailbox_active" changed from "0" to "1". > > -bill > > > On Monday, March 24, 2014 8:20 PM, Morteza Ansari (moransar) > wrote: > Bill, > > Can you expand on the problem this would solve? I know this came up on > one of the calls a while ago but I don’t think the problem is clearly > captured on the mailing list before. > > > Cheers, > Morteza > > From: Bill Mills > > Reply-To: Bill Mills > > Date: Monday, March 24, 2014 at 3:19 PM > To: "scim@ietf.org " > > Subject: [scim] metadata and actions > > "meta" is used to return metadata about entries and in the case of PATCH > it's used to specify elements to delete. I'd like to propose a new > "meta" element for action to be taken. I think this would solve some of > the question of triggering actions based on a PATCH. So for example: > > "meta": { > "action": ["SuspendUser", "DeleteMailbox"] > > } > > > Specifies 2 actions to be taken along with whatever data changes are > applied. > > Does this sound workable? > > -bill > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From nobody Tue Mar 25 07:42:46 2014 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 53E8D1A014B for ; Tue, 25 Mar 2014 07:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.792 X-Spam-Level: X-Spam-Status: No, score=0.792 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 CntY2idMSBF1 for ; Tue, 25 Mar 2014 07:42:41 -0700 (PDT) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) by ietfa.amsl.com (Postfix) with ESMTP id D4FB31A0133 for ; Tue, 25 Mar 2014 07:42:40 -0700 (PDT) Received: from [66.196.81.170] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 25 Mar 2014 14:42:39 -0000 Received: from [98.139.212.212] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 25 Mar 2014 14:42:39 -0000 Received: from [127.0.0.1] by omp1021.mail.bf1.yahoo.com with NNFMP; 25 Mar 2014 14:42:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 565614.69409.bm@omp1021.mail.bf1.yahoo.com Received: (qmail 31227 invoked by uid 60001); 25 Mar 2014 14:42:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395758559; bh=eWBQNygCi4IEaiU8Vfxt4s63hq/LhPA2T7OzqgEM0XE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=YRm4tBuacCASu5IbSlk9alGyrJ6mmfj5EQAZMOx7NW3lmCIkAGuhD0L4FhYNRu8KwQPh7uHWR/22O+xFPZTYDD45+kzGOnRTLvpSnVKIlV4bqDCvgEoxK/olxCLnDn5/VrUztqPW4wmaq5KGgFAdbT/x60Ce5zNi3km5fTP9E9E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=TeRjT3P45vRB7kbAHP2ucEZt8eOuPP4VuBAS2da9P+8RX1DJSGGXyhyaPtcVYf6wWrJ8oEumCpxfcl/pRnEgJkd80F2ZFPkTKdbbfEo32Wac1srgKT4BlNCc8H+JQLGxmf83Vns50YSAFS/NDSPHOnAREz4JTxL13eLeXWj6eC4=; X-YMail-OSG: eepdVXIVM1n7c.nnCKnoAvITeOQiznOWYq69OjV5wsOIng6 TUl0nPrsF7avvIw96lfyv4Ifj1YDmd0Fn255RWV_Z3TDlkNgMYK7jHSssX_0 2ayNoMclRDNfsVvMHvoT8c_8010Z3Z_mweE20e0JFz0SFotPjFhGqB.bY0uD x2BzegZcq0B7YaSXq94DQIAUiaxauMq0STMAkkwTvJ6OALodEUUCR1odwEBR Wyg9UFdIS68wc4k4gBykIqPkFME8Wn8EgAT0aumIKFylor3baqoLyJ7VWaXV LeWghCK17xUUtF7EamAisCfaeDj_SpEKoYcrzVLAzFKe6RV6purY4khKRCGq Clay8jipYjnpUq9k251v4DstvafdyVt3PL3rEG8F6MSec2TmOpLhB2af_.0U AjgXBdrXE.FUuFq1KNHnzG5BMbY0rrVtciUkYBpeZNseUMD57jCat6MiVyA2 c4p9FF4EYh67Ela6Hf2Q_XedK8uK_B5mR_b8_TxZ5KoGxt_I4NJrJ0yCu7XS TvdILOjkdIlMjYchnJCiax7TMdilKv0vC036KQtHCqSdSdBFi0SaWW.YFgbU - Received: from [209.131.62.115] by web142802.mail.bf1.yahoo.com via HTTP; Tue, 25 Mar 2014 07:42:39 PDT X-Rocket-MIMEInfo: 002.001, V2hhdCBJJ20gYXNraW5nIGZvciBpcyBhIGRlZmluZWQgZXh0ZW5zaW9uIHRvIHRoZSAibWV0YSIgZWxlbWVudCwgbm90IMKgIm1haWxib3giIGVsZW1lbnQuIMKgV2UnbGwgZGVmaW5lIG91ciBvd24gc2NoZW1hIGFzIG5lZWRlZCBmb3IgdGhlIHRoaW5ncyBzcGVmaWNpIHRvIG91ciBwcm92aXNpb25pbmcgZW52aXJvbm1lbnQuIMKgU0NJTSBpcyBhYm91dCBtYW5hZ2luZyB1c2VycyBBTkQgdGhpbmdzIGFzb2NpYXRlZCB3aXRoIHRoZW0sIHNvIGEgbWFpbGJveCBpcyBhIHJlYXNvbmFibGUgcmVzb3VyY2UgdG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.181.645 References: <1395699572.32920.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1395721026.16897.YahooMailNeo@web142806.mail.bf1.yahoo.com> <53311CB8.40007@tarent.de> Message-ID: <1395758559.2114.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Tue, 25 Mar 2014 07:42:39 -0700 (PDT) From: Bill Mills To: =?utf-8?B?RGF2aWQgTcO2Yml1cw==?= , "scim@ietf.org" In-Reply-To: <53311CB8.40007@tarent.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-452254131-1395758559=:2114" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/C9fr9QgHGK4lqy3CeeDVhSgkAK0 Subject: Re: [scim] metadata and actions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 14:42:43 -0000 --1397251415-452254131-1395758559=:2114 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable What I'm asking for is a defined extension to the "meta" element, not =C2= =A0"mailbox" element. =C2=A0We'll define our own schema as needed for the t= hings spefici to our provisioning environment. =C2=A0SCIM is about managing= users AND things asociated with them, so a mailbox is a reasonable resourc= e to be managing which is why I chose it as an example.=0A=0A=0A=0AOn Monda= y, March 24, 2014 11:05 PM, David M=C3=B6bius wrote:= =0A =0AHello Bill,=0A=0AI also don't realy understand why you need this act= ion.=0AFor you two examples:=0A=0ASuspendUser: would be like active =3D fal= se=0ADeleteMailbox: The scim user has no mailbox so what should the system= =0Ado? For my understanding a mailbox like something could only be a part= =0Aof an extension but not of the standard user. So it looks like that the= =0Ameta.action would be very client specific.=0A=0A=0Aby David=0A=0AAm 25.0= 3.2014 05:17, schrieb Bill Mills:=0A> The problem is that in a PATCH or PUT= any action to be taken on the=0A> account has to be inferred from the data= changes.=C2=A0 This also means that=0A> everyone has to share the entire s= chema for how an acount is managed.=0A> =0A> We have a system that looks ve= ry much like SCIM (not a suprise since=0A> SCIM is standardizing a common t= ask) but we have action verbs with data.=0A>=C2=A0 Comparing the two I much= prefer the action verb with supporting data=0A> model.=C2=A0 In the curren= t SCIM model actions have to be inferred from data=0A> changes.=0A> =0A> Fo= r example we might have a "create_mailbox" verb, where in SCIM I need=0A> t= o compare the current state to the new state and dtermine that=0A> "mailbox= _active" changed from "0" to "1".=C2=A0 =0A> =0A> -bill=0A> =0A> =0A> On Mo= nday, March 24, 2014 8:20 PM, Morteza Ansari (moransar)=0A> wrote:=0A> Bill,=0A> =0A> Can you expand on the problem this would so= lve?=C2=A0 I know this came up on=0A> one of the calls a while ago but I do= n=E2=80=99t think the problem is clearly=0A> captured on the mailing list b= efore.=0A> =0A> =0A> Cheers,=0A> Morteza=0A> =0A> From: Bill Mills >=0A> Reply-To: Bill Mills <= wmills_92105@yahoo.com=0A> >=0A> Date: Monda= y, March 24, 2014 at 3:19 PM=0A> To: "scim@ietf.org "= >=0A> Subject: [scim] metadata an= d actions=0A> =0A> "meta" is used to return metadata about entries and in t= he case of PATCH=0A> it's used to specify elements to delete.=C2=A0 I'd li= ke to propose a new=0A> "meta" element for action to be taken.=C2=A0 I thin= k this would solve some of=0A> the question of triggering actions based on = a PATCH.=C2=A0 So for example:=0A> =0A> "meta": {=0A>=C2=A0 =C2=A0 "action= ": ["SuspendUser", "DeleteMailbox"]=0A> =0A> }=0A> =0A> =0A> Specifies 2 ac= tions to be taken along with whatever data changes are=0A> applied.=0A> =0A= > Does this sound workable?=0A> =0A> -bill=0A> =0A> _______________________= ________________________=0A> scim mailing list=0A> scim@ietf.org =0A> https://www.ietf.org/mailman/listinfo/scim=0A> =0A> =0A> = =0A> =0A> _______________________________________________=0A> scim mailing = list=0A> scim@ietf.org=0A> https://www.ietf.org/mailman/listinfo/scim=0A=0A= > =0A=0A_______________________________________________=0Ascim mailing list= =0Ascim@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/scim --1397251415-452254131-1395758559=:2114 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
What I'm asking for is a defined extension to the = "meta" element, not  "mailbox" element.  We'll define our own sch= ema as needed for the things spefici to our provisioning environment.  = ;SCIM is about managing users AND things asociated with them, so a mailbox = is a reasonable resource to be managing which is why I chose it as an examp= le.

=
On Monday, March 24, 2014 11:05 PM, David M=C3=B6bius <d.moebius@tarent.de> wrote:
Hello Bill,

I also don't r= ealy understand why you need this action.
For you two exa= mples:

SuspendUser: would be like acti= ve =3D false
DeleteMailbox: The scim user has no mailbox = so what should the system
do? For my understanding a mail= box like something could only be a part
of an extension b= ut not of the standard user. So it looks like that the
me= ta.action would be very client specific.


by David

Am 25.0= 3.2014 05:17, schrieb Bill Mills:
> The problem is tha= t in a PATCH or PUT any action to be taken on the
> ac= count has to be inferred from the data changes.  This also means that<= br clear=3D"none">> everyone has to share the entire schema for how an acount is managed.
>
> We have a system that looks very much lik= e SCIM (not a suprise since
> SCIM is standardizing a = common task) but we have action verbs with data.
>&nbs= p; Comparing the two I much prefer the action verb with supporting data
> model.  In the current SCIM model actions have to = be inferred from data
> changes.
>= ;
> For example we might have a "create_mailbox" verb= , where in SCIM I need
> to compare the current state = to the new state and dtermine that
> "mailbox_active" = changed from "0" to "1". 
>
= > -bill
>
>
> On Monday, March 24, 2014 8:20 PM, Morteza Ansari (moransar)
> <moransar@cisco.com> wrote:
> Bill= ,
>
> Can you expand on the prob= lem this would solve?  I know this came up on
> o= ne of the calls a while ago but I don=E2=80=99t think the problem is clearl= y
> captured on the mailing list before.
>
>
> Cheers,
> Morteza
>
> From:= Bill Mills <wmills_92105@yahoo.com <mail= to:wmills_92105@yahoo.com>>
> Reply-To: Bill Mills <wmills_92105@yahoo.com
> <mailto:wmills_92105@yahoo.com>>
> Date: Monday, March 24, 2014 at 3:19 PM> To: "scim@ietf.org <mailto:scim@iet= f.org>" <scim@ietf.org
> <mail= to:scim@ietf.org>>
> Subject: [scim] m= etadata and actions
>
> "meta" i= s used to return metadata about entries and in the case of PATCH
> it's used to specify elements to delete.  I'd like to propose a new
> "meta" = element for action to be taken.  I think this would solve some of
> the question of triggering actions based on a PATCH.&nbs= p; So for example:
>
> "meta": {=
>    "action": ["SuspendUser", "DeleteMail= box"]
>
> }
&g= t;
>
> Specifies 2 actions to b= e taken along with whatever data changes are
> applied= .
>
> Does this sound workable?<= br clear=3D"none">>
> -bill
>=
> _______________________________________________> scim mailing list
> scim@ie= tf.org <mailto:scim@ietf.o= rg>
> https://www.ietf.org/mailman= /listinfo/scim
>
>
>
>
> ____________= ___________________________________
> scim mailing lis= t
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim

>
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim


--1397251415-452254131-1395758559=:2114-- From nobody Tue Mar 25 07:49:52 2014 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 A93701A014B for ; Tue, 25 Mar 2014 07:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 ixFfMppeWVh0 for ; Tue, 25 Mar 2014 07:49:47 -0700 (PDT) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3B64D1A0133 for ; Tue, 25 Mar 2014 07:49:47 -0700 (PDT) Received: by mail-bk0-f53.google.com with SMTP id r7so227152bkg.26 for ; Tue, 25 Mar 2014 07:49:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iPYOIyMKFP46vCTK53RzUy2pXliJEuxu8/KSchG5eLc=; b=REgrIh1/4uYEa2vCrMHILoRWkjye9l8myzoiubkj3bLh1nW0DyRxYGQl6nFE3oUzui wjJeA8HepdqXbc8P0wilcetafYfA/sRXEE+p7OSvz+DV8MPozhx/a3YQ3SVIYruD8hem H9B9TZNTNqN97GDjArOOYNJ2VFiG1FVittZ/b5Hx8Vx6pHdgjB3KuYkwp6demmLHRY2n G5X7/Z6uNLyixdZhmlNwFiDRo8v+8/jPT+nrP+5IFZIc+VTAwK+B7THmogXl/laUS7Z7 vEZVsRt9OQ+3b7ZOLwFzqhsjCDrjHkJRQVoyhlnzFNoNfrDRGauikhQvojUKi1tUwit2 9D5g== X-Gm-Message-State: ALoCoQlfwl6+hB5Knq/lhmU0WiLJNURCgqVqgbMFHgK9sPswbR5uzjaNY86v6rihv3G/5A3ZhkMN X-Received: by 10.205.20.202 with SMTP id qp10mr253698bkb.100.1395758985480; Tue, 25 Mar 2014 07:49:45 -0700 (PDT) Received: from [172.24.12.173] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id oa10sm19132035bkb.14.2014.03.25.07.49.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Mar 2014 07:49:44 -0700 (PDT) Message-ID: <53319786.30506@tarent.de> Date: Tue, 25 Mar 2014 15:49:42 +0100 From: =?UTF-8?B?RGF2aWQgTcO2Yml1cw==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Bill Mills , "scim@ietf.org" References: <1395699572.32920.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1395721026.16897.YahooMailNeo@web142806.mail.bf1.yahoo.com> <53311CB8.40007@tarent.de> <1395758559.2114.YahooMailNeo@web142802.mail.bf1.yahoo.com> In-Reply-To: <1395758559.2114.YahooMailNeo@web142802.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/OZ05Gyn1PgcVW0eqv9jZnRCX9i0 Subject: Re: [scim] metadata and actions 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: Tue, 25 Mar 2014 14:49:49 -0000 Yea that is sure but I think the meta attribute should only be for scim attributes. I don't know how you implement your code but I think you have your "mailbox" or what else in some kind of extension. In this case you just could definde an additional field in your extension where you store the actions. David Am 25.03.2014 15:42, schrieb Bill Mills: > What I'm asking for is a defined extension to the "meta" element, not > "mailbox" element. We'll define our own schema as needed for the > things spefici to our provisioning environment. SCIM is about managing > users AND things asociated with them, so a mailbox is a reasonable > resource to be managing which is why I chose it as an example. > > > On Monday, March 24, 2014 11:05 PM, David Möbius > wrote: > Hello Bill, > > I also don't realy understand why you need this action. > For you two examples: > > SuspendUser: would be like active = false > DeleteMailbox: The scim user has no mailbox so what should the system > do? For my understanding a mailbox like something could only be a part > of an extension but not of the standard user. So it looks like that the > meta.action would be very client specific. > > > by David > > Am 25.03.2014 05:17, schrieb Bill Mills: >> The problem is that in a PATCH or PUT any action to be taken on the >> account has to be inferred from the data changes. This also means that >> everyone has to share the entire schema for how an acount is managed. >> >> We have a system that looks very much like SCIM (not a suprise since >> SCIM is standardizing a common task) but we have action verbs with data. >> Comparing the two I much prefer the action verb with supporting data >> model. In the current SCIM model actions have to be inferred from data >> changes. >> >> For example we might have a "create_mailbox" verb, where in SCIM I need >> to compare the current state to the new state and dtermine that >> "mailbox_active" changed from "0" to "1". >> >> -bill >> >> >> On Monday, March 24, 2014 8:20 PM, Morteza Ansari (moransar) >> > wrote: >> Bill, >> >> Can you expand on the problem this would solve? I know this came up on >> one of the calls a while ago but I don’t think the problem is clearly >> captured on the mailing list before. >> >> >> Cheers, >> Morteza >> >> From: Bill Mills >> >> Reply-To: Bill Mills >> >> >> Date: Monday, March 24, 2014 at 3:19 PM >> To: "scim@ietf.org >" >> >> >> Subject: [scim] metadata and actions >> >> "meta" is used to return metadata about entries and in the case of PATCH >> it's used to specify elements to delete. I'd like to propose a new >> "meta" element for action to be taken. I think this would solve some of >> the question of triggering actions based on a PATCH. So for example: >> >> "meta": { >> "action": ["SuspendUser", "DeleteMailbox"] >> >> } >> >> >> Specifies 2 actions to be taken along with whatever data changes are >> applied. >> >> Does this sound workable? >> >> -bill >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org > >> https://www.ietf.org/mailman/listinfo/scim >> >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > >> > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > From nobody Tue Mar 25 08:54:48 2014 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 E5D171A016D for ; Tue, 25 Mar 2014 08:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.608 X-Spam-Level: X-Spam-Status: No, score=-0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 ZuHbI86ACZ4a for ; Tue, 25 Mar 2014 08:54:31 -0700 (PDT) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 787511A0197 for ; Tue, 25 Mar 2014 08:54:30 -0700 (PDT) Received: from [66.196.81.172] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 25 Mar 2014 15:54:29 -0000 Received: from [98.139.212.231] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 25 Mar 2014 15:54:29 -0000 Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 25 Mar 2014 15:54:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 30844.48061.bm@omp1040.mail.bf1.yahoo.com Received: (qmail 74454 invoked by uid 60001); 25 Mar 2014 15:54:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395762868; bh=qYX8jGJ6mysbrIH7+RqSe53a5k5aDJdEzfiNayv/NBI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=MHHYvcr+6U99UIvvdfpc/1iIuyLSBsrbyFeO1wltJ3flSQQkX2KYPqx4rMrRIzxSAyligmvNhOpeyR4CDHD6BgoMGOBOO6d6EJ3E6DOC5GUjW5gULIpVgCH0Nwm5yFHe7UPz8a21C6DDylKCgv5qHpNvGFTeApt1QAI+p85R8s4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=j+1cbaYcPYNxZl4DDCs7qpLK0D2PooAl10A0cevZiuG+lsWLqO3kq5E2Yx7C04movr9so0gPuE7gZ55mY2N3K9EAdmf9X/K8BAB+OxyhsKB/Si4UdCKwN0YJDliQGSB0rUhUZs4XKxMQkzRCsmp7/AfanrwGVtrfbmirIE9pKUE=; X-YMail-OSG: 1PmRWbkVM1nKz6ZXt88jp5viHh14HgZFK2CJvgKnfKUhLyd d9HTiDVIFJVx_zWEzCJABI9hZ70xv6r5Nal2zqgVOr6EVEKx7kHIUtIh09Ub 7ae3DresoDcyTutxr1Oas7d8ewjR.MUe88SONI4JYVD.G7wIm_D2Epx01SPq Z3xlClelKN_5jBM3b54MsO5MTfgZH6oKi_jCOvck9z.SetNjhR9U5ckQo6YY NjxCVW.vG7qtvol9XAacT9tIHyExUxEamGbtYuxympEHMfagu2c8KwXZnLZC tiuZxhuWQYJ65b7qYuQ351jLH2ZMSCRtDeGXeEgG2MmdMNekPJ19M_9EML6r 1.H5Wfxa_JUcISSh.AvPCBh1fE2r2_H1oc4RniQuWYK6g9dr6sKmHVkxn.QK YW3iSuU5mtbRKwLxjbmD9pssD2j2h7vs2IWmdm.INS_nvfX5TbBl1jNnub.G S9dhIwqYhyxRh3E3a6ZSc2vyg.1MAjz_Ak5jG9KEU7dd1Vcf5d2IWasW3Ntj t6ZaKTWU.3HrcfHlM_.3qFrxe5oueQf.VVtEgoHWCE6ogG8_YpOasco5VsO4 - Received: from [209.131.62.115] by web142806.mail.bf1.yahoo.com via HTTP; Tue, 25 Mar 2014 08:54:28 PDT X-Rocket-MIMEInfo: 002.001, MSkgSSBkbyBub3Qgd2FudCB0byBleHBsaWNpdGx5IHN0b3JlIHRoZSB0cmFuc2FjdGlvbnMsIGJ1dCBJIG1heSBsb2cgdGhlbSBpbiBhIGRpZmZlcmVudCBmaWVsZC4gwqBBICJuby1zdG9yZSIgbXV0YWJpbGl0eSB2YWx1ZSBjb3VsZCBzb2x2ZSB0aGlzIHRvby4KCjIpIFNDSU0gcmVhbGx5IG5lZWRzIHRoaXMgY29uY2VwdC4gwqBEaWZmcyBvZiBkYXRhIHRvIGRldGVybWluZSB3aGF0IGFjdGlvbnMgdG8gdGFrZSBpcyBub3QgYSBncmVhdCB0aGluZy4KCgoKT24gVHVlc2RheSwgTWFyY2ggMjUsIDIwMTQgNzoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.181.645 References: <1395699572.32920.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1395721026.16897.YahooMailNeo@web142806.mail.bf1.yahoo.com> <53311CB8.40007@tarent.de> <1395758559.2114.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53319786.30506@tarent.de> Message-ID: <1395762868.98394.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Tue, 25 Mar 2014 08:54:28 -0700 (PDT) From: Bill Mills To: =?utf-8?B?RGF2aWQgTcO2Yml1cw==?= , "scim@ietf.org" In-Reply-To: <53319786.30506@tarent.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="515012262-1240567632-1395762868=:98394" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/9XGcDMrfzLx2ddSTFwpAIFyDKpc Subject: Re: [scim] metadata and actions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 15:54:33 -0000 --515012262-1240567632-1395762868=:98394 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 1) I do not want to explicitly store the transactions, but I may log them i= n a different field. =C2=A0A "no-store" mutability value could solve this t= oo.=0A=0A2) SCIM really needs this concept. =C2=A0Diffs of data to determin= e what actions to take is not a great thing.=0A=0A=0A=0AOn Tuesday, March 2= 5, 2014 7:49 AM, David M=C3=B6bius wrote:=0A =0AYea t= hat is sure but I think the meta attribute should only be for scim=0Aattrib= utes.=0A=0AI don't know how you implement your code but I think you have yo= ur=0A"mailbox" or what else in some kind of extension. In this case you jus= t=0Acould definde an additional field in your extension where you store the= =0Aactions.=0A=0ADavid=0A=0AAm 25.03.2014 15:42, schrieb Bill Mills:=0A> Wh= at I'm asking for is a defined extension to the "meta" element, not=0A>=C2= =A0 "mailbox" element.=C2=A0 We'll define our own schema as needed for the= =0A> things spefici to our provisioning environment.=C2=A0 SCIM is about ma= naging=0A> users AND things asociated with them, so a mailbox is a reasonab= le=0A> resource to be managing which is why I chose it as an example.=0A> = =0A> =0A> On Monday, March 24, 2014 11:05 PM, David M=C3=B6bius =0A> wrote:=0A> Hello Bill,=0A> =0A> I also don't realy understan= d why you need this action.=0A> For you two examples:=0A> =0A> SuspendUser:= would be like active =3D false=0A> DeleteMailbox: The scim user has no mai= lbox so what should the system=0A> do? For my understanding a mailbox like = something could only be a part=0A> of an extension but not of the standard = user. So it looks like that the=0A> meta.action would be very client specif= ic.=0A> =0A> =0A> by David=0A> =0A> Am 25.03.2014 05:17, schrieb Bill Mills= :=0A>> The problem is that in a PATCH or PUT any action to be taken on the= =0A>> account has to be inferred from the data changes.=C2=A0 This also mea= ns that=0A>> everyone has to share the entire schema for how an acount is m= anaged.=0A>>=0A>> We have a system that looks very much like SCIM (not a su= prise since=0A>> SCIM is standardizing a common task) but we have action ve= rbs with data.=0A>>=C2=A0 Comparing the two I much prefer the action verb w= ith supporting data=0A>> model.=C2=A0 In the current SCIM model actions hav= e to be inferred from data=0A>> changes.=0A>>=0A>> For example we might hav= e a "create_mailbox" verb, where in SCIM I need=0A>> to compare the current= state to the new state and dtermine that=0A>> "mailbox_active" changed fro= m "0" to "1". =0A>>=0A>> -bill=0A>>=0A>>=0A>> On Monday, March 24, 2014 8:2= 0 PM, Morteza Ansari (moransar)=0A>> > wrote:=0A>> Bill,=0A>>=0A>> Can you expand on the problem this w= ould solve?=C2=A0 I know this came up on=0A>> one of the calls a while ago = but I don=E2=80=99t think the problem is clearly=0A>> captured on the maili= ng list before.=0A>>=0A>>=0A>> Cheers,=0A>> Morteza=0A>>=0A>> From: Bill Mi= lls >>=0A>> Reply-To: Bi= ll Mills =0A>> <= mailto:wmills_92105@yahoo.com >>=0A>> Date: = Monday, March 24, 2014 at 3:19 PM=0A>> To: "scim@ietf.org >" =0A>> >>=0A>= > Subject: [scim] metadata and actions=0A>>=0A>> "meta" is used to return m= etadata about entries and in the case of PATCH=0A>> it's used to specify el= ements to delete.=C2=A0 I'd like to propose a new=0A>> "meta" element for a= ction to be taken.=C2=A0 I think this would solve some of=0A>> the question= of triggering actions based on a PATCH.=C2=A0 So for example:=0A>>=0A>> "m= eta": {=0A>>=C2=A0 =C2=A0 "action": ["SuspendUser", "DeleteMailbox"]=0A>>= =0A>> }=0A>>=0A>>=0A>> Specifies 2 actions to be taken along with whatever = data changes are=0A>> applied.=0A>>=0A>> Does this sound workable?=0A>>=0A>= > -bill=0A>>=0A>> _______________________________________________=0A>> scim= mailing list=0A>> scim@ietf.org >=0A>> https://www.ietf.org/mailman/listinfo/s= cim=0A>>=0A>>=0A>>=0A>>=0A>> ______________________________________________= _=0A>> scim mailing list=0A>> scim@ietf.org =0A>> htt= ps://www.ietf.org/mailman/listinfo/scim=0A=0A> =0A>>=0A> =0A> _____________= __________________________________=0A> scim mailing list=0A> scim@ietf.org = =0A> https://www.ietf.org/mailman/listinfo/scim=0A> = =0A> =0A=0A_______________________________________________=0Ascim mailing l= ist=0Ascim@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/scim --515012262-1240567632-1395762868=:98394 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
1) I do not want to explicitly store the transactions, b= ut I may log them in a different field.  A "no-store" mutability value= could solve this too.

2) SCIM really needs this concept.  Diffs of data to de= termine what actions to take is not a great thing.


On Tuesday, March 25, 2014 7= :49 AM, David M=C3=B6bius <d.moebius@tarent.de> wrote:
Yea that is sure but I think the meta = attribute should only be for scim
attributes.

I don't know how you implement your code but I th= ink you have your
"mailbox" or what else in some kind of = extension. In this case you just
could definde an additio= nal field in your extension where you store the
actions.<= br clear=3D"none">
David

Am 25.03.2014 15:42, schrieb Bill Mills:
> What I= 'm asking for is a defined extension to the "meta" element, not
>  "mailbox" element.  We'll define our own schema as n= eeded for the
> things spefici to our provisioning env= ironment.  SCIM is about managing
> users AND things asociated with them, so a= mailbox is a reasonable
> resource to be managing whi= ch is why I chose it as an example.
>
>
> On Monday, March 24, 2014 11:05 PM, David M= =C3=B6bius <d.moebius@tarent.de>
> wrote:
> Hello Bill,
> <= br clear=3D"none">> I also don't realy understand why you need this acti= on.
> For you two examples:
> > SuspendUser: would be like active =3D false
> DeleteMailbox: The scim user has no mailbox so what should t= he system
> do? For my understanding a mailbox like so= mething could only be a part
> of an extension but not= of the standard user. So it looks like that the
> meta.action would be very client spec= ific.
>
>
>= ; by David
>
> Am 25.03.2014 05:= 17, schrieb Bill Mills:
>> The problem is that in a= PATCH or PUT any action to be taken on the
>> acco= unt has to be inferred from the data changes.  This also means that>> everyone has to share the entire schema for how an= acount is managed.
>>
>> W= e have a system that looks very much like SCIM (not a suprise since
>> SCIM is standardizing a common task) but we have action= verbs with data.
>>  Comparing the two I much= prefer the action verb with supporting data
>> mod= el.  In the current SCIM model actions have to be inferred from data>> changes.
>>
>> For example we might have a "create_mailbox" verb, where in SC= IM I need
>> to compare the current state to the ne= w state and dtermine that
>> "mailbox_active" chang= ed from "0" to "1".
>>
>> = -bill
>>
>>
>> On Monday, March 24, 2014 8:20 PM, Morteza Ansari (moransar)>> <moransar@cisco.com <mai= lto:moransar@cisco.com>> wrote:
>> Bill,
>>
>> Can y= ou expand on the problem this would solve?  I know this came up on
>> one of the calls a while ago but I don=E2=80=99t think the problem is clearly
>> captured on the mailing list before.
= >>
>>
>> Cheers,
>> Morteza
>>
>> From: Bill Mills <wmills_92105@yahoo.c= om
> <mailto:wmills_921= 05@yahoo.com> <mailto:wmills_92105@yahoo.= com
> <mailto:wmills_92= 105@yahoo.com>>>
>> Reply-To: Bill Mil= ls <wmills_92105@yahoo.com
> <mailto:wmills_92105@yahoo.com>
>> = <mailto:wmills_92105@yahoo.com <mailto:wmills_92105@yahoo.com>>>
>> Date: Monday, March 24, 2014 at 3:19 PM
>= > To: "scim@ietf.org <mailto:scim@ietf.org> &l= t;mailto:scim@ietf.org
> <mailto:scim@ietf.org>>" <= scim@ietf.org <mailto:scim@ietf.org>
= >> <mailto:scim@ietf.org <mailto:scim@ietf.org<= /a>>>>
>> Subject: [scim] metadata and act= ions
>>
>> "meta" is used t= o return metadata about entries and in the case of PATCH
= >> it's used to specify elements to delete.  I'd like to propose= a new
>> "meta" element for action to be taken.&nb= sp; I think this would solve some of
>> the question of triggering actions based on = a PATCH.  So for example:
>>
>> "meta": {
>>    "action": ["Sus= pendUser", "DeleteMailbox"]
>>
&g= t;> }
>>
>>
>> Specifies 2 actions to be taken along with whatever data cha= nges are
>> applied.
>>
>> Does this sound workable?
>>= ;
>> -bill
>>
>> _______________________________________________
>> scim mailing list
>> scim@ietf.= org <mailto:scim@ietf.org> <mailto:scim@= ietf.org
> <mailto:scim@ietf.org>&= gt;
>> https://www.ietf.org/mailman/li= stinfo/scim
>>
>>
>>
>>
>>= _______________________________________________
>>= scim mailing list
>> scim@ietf.org <m= ailto:scim@ietf.org>
>> http= s://www.ietf.org/mailman/listinfo/scim

>
>>
>
> ___________________________________= ____________
> scim mailing list
>= ; scim@ietf.org <mailto:scim@ietf.org>
> https://www.ietf.org/mailman/listinfo/scim<= br clear=3D"none">>
>

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim


--515012262-1240567632-1395762868=:98394-- From nobody Tue Mar 25 20:31:57 2014 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 3BA651A00B1 for ; Tue, 25 Mar 2014 20:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.609 X-Spam-Level: X-Spam-Status: No, score=-3.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, MIME_QP_LONG_LINE=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 VjNUgbTIUkqO for ; Tue, 25 Mar 2014 20:31:52 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 27EF51A0005 for ; Tue, 25 Mar 2014 20:31:52 -0700 (PDT) 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 s2Q3VnsV020914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Mar 2014 03:31:50 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2Q3VlvY016568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2014 03:31:47 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s2Q3Vlvt022373; Wed, 26 Mar 2014 03:31:47 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Mar 2014 20:31:46 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-A7EA80D0-3A2B-42FE-B74C-A784D935DD14 Content-Transfer-Encoding: 7bit References: <1395699572.32920.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1395721026.16897.YahooMailNeo@web142806.mail.bf1.yahoo.com> <53311CB8.40007@tarent.de> <1395758559.2114.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53319786.30506@tarent.de> <1395762868.98394.YahooMailNeo@web142806.mail.bf1.yahoo.com> From: Phil Hunt Mime-Version: 1.0 (1.0) In-Reply-To: <1395762868.98394.YahooMailNeo@web142806.mail.bf1.yahoo.com> Message-Id: <1F458548-58CD-4BC3-8024-1752DED636A8@oracle.com> Date: Tue, 25 Mar 2014 20:31:31 -0700 To: Bill Mills X-Mailer: iPhone Mail (11D167) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/J3IOGodzF3TEs63psZBzNrsHSf4 Cc: =?utf-8?Q?David_M=C3=B6bius?= , "scim@ietf.org" Subject: Re: [scim] metadata and actions 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, 26 Mar 2014 03:31:55 -0000 --Apple-Mail-A7EA80D0-3A2B-42FE-B74C-A784D935DD14 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It seems like you are defining high-level "functions" rather than simple sta= teful changes.=20 I agree on the need, but i think many will say this is not RESTful. =20 Phil > On Mar 25, 2014, at 8:54, Bill Mills wrote: >=20 > 1) I do not want to explicitly store the transactions, but I may log them i= n a different field. A "no-store" mutability value could solve this too. >=20 > 2) SCIM really needs this concept. Diffs of data to determine what action= s to take is not a great thing. >=20 >=20 > On Tuesday, March 25, 2014 7:49 AM, David M=C3=B6bius wrote: > Yea that is sure but I think the meta attribute should only be for scim > attributes. >=20 > I don't know how you implement your code but I think you have your > "mailbox" or what else in some kind of extension. In this case you just > could definde an additional field in your extension where you store the > actions. >=20 > David >=20 > Am 25.03.2014 15:42, schrieb Bill Mills: > > What I'm asking for is a defined extension to the "meta" element, not > > "mailbox" element. We'll define our own schema as needed for the > > things spefici to our provisioning environment. SCIM is about managing > > users AND things asociated with them, so a mailbox is a reasonable > > resource to be managing which is why I chose it as an example. > >=20 > >=20 > > On Monday, March 24, 2014 11:05 PM, David M=C3=B6bius > > wrote: > > Hello Bill, > >=20 > > I also don't realy understand why you need this action. > > For you two examples: > >=20 > > SuspendUser: would be like active =3D false > > DeleteMailbox: The scim user has no mailbox so what should the system > > do? For my understanding a mailbox like something could only be a part > > of an extension but not of the standard user. So it looks like that the > > meta.action would be very client specific. > >=20 > >=20 > > by David > >=20 > > Am 25.03.2014 05:17, schrieb Bill Mills: > >> The problem is that in a PATCH or PUT any action to be taken on the > >> account has to be inferred from the data changes. This also means that= > >> everyone has to share the entire schema for how an acount is managed. > >> > >> We have a system that looks very much like SCIM (not a suprise since > >> SCIM is standardizing a common task) but we have action verbs with data= . > >> Comparing the two I much prefer the action verb with supporting data > >> model. In the current SCIM model actions have to be inferred from data= > >> changes. > >> > >> For example we might have a "create_mailbox" verb, where in SCIM I need= > >> to compare the current state to the new state and dtermine that > >> "mailbox_active" changed from "0" to "1".=20 > >> > >> -bill > >> > >> > >> On Monday, March 24, 2014 8:20 PM, Morteza Ansari (moransar) > >> > wrote: > >> Bill, > >> > >> Can you expand on the problem this would solve? I know this came up on= > >> one of the calls a while ago but I don=E2=80=99t think the problem is c= learly > >> captured on the mailing list before. > >> > >> > >> Cheers, > >> Morteza > >> > >> From: Bill Mills > > >> > >> Reply-To: Bill Mills > > >> >> > >> Date: Monday, March 24, 2014 at 3:19 PM > >> To: "scim@ietf.org > >" > >> >> > >> Subject: [scim] metadata and actions > >> > >> "meta" is used to return metadata about entries and in the case of PATC= H > >> it's used to specify elements to delete. I'd like to propose a new > >> "meta" element for action to be taken. I think this would solve some o= f > >> the question of triggering actions based on a PATCH. So for example: > >> > >> "meta": { > >> "action": ["SuspendUser", "DeleteMailbox"] > >> > >> } > >> > >> > >> Specifies 2 actions to be taken along with whatever data changes are > >> applied. > >> > >> Does this sound workable? > >> > >> -bill > >> > >> _______________________________________________ > >> scim mailing list > >> scim@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/scim > >> > >> > >> > >> > >> _______________________________________________ > >> scim mailing list > >> scim@ietf.org > >> https://www.ietf.org/mailman/listinfo/scim >=20 > >=20 > >> > >=20 > > _______________________________________________ > > scim mailing list > > scim@ietf.org > > https://www.ietf.org/mailman/listinfo/scim > >=20 > >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-A7EA80D0-3A2B-42FE-B74C-A784D935DD14 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It seems like you are defining high-le= vel "functions" rather than simple stateful changes. 

I agree on the need, but i think many will say this is not RESTful. &= nbsp;

Phil

On Mar 25, 2014, at 8:54, Bill Mills &= lt;wmills_92105@yahoo.com> w= rote:

1) I do not want to exp= licitly store the transactions, but I may log them in a different field. &nb= sp;A "no-store" mutability value could solve this too.

<= div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeu= e, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; backgrou= nd-color: transparent; font-style: normal;">2) SCIM really needs this concep= t.  Diffs of data to determine what actions to take is not a great thin= g.


On T= uesday, March 25, 2014 7:49 AM, David M=C3=B6bius <d.moebius@tarent.de> wrote:
Yea that is sure but I think the meta attribute s= hould only be for scim
attributes.

I don't know how you implement your code but I think you have y= our
"mailbox" or what else in some kind of extension. In t= his case you just
could definde an additional field in you= r extension where you store the
actions.

David

Am 25.03.2014= 15:42, schrieb Bill Mills:
> What I'm asking for is a d= efined extension to the "meta" element, not
>  "ma= ilbox" element.  We'll define our own schema as needed for the
> things spefici to our provisioning environment.  SCIM is= about managing
> users AND things asociated with them, so a m= ailbox is a reasonable
> resource to be managing which i= s why I chose it as an example.
>
&g= t;
> On Monday, March 24, 2014 11:05 PM, David M=C3=B6= bius <d.moebius@tarent.de>
>= wrote:
> Hello Bill,
>
> I also don't realy understand why you need this action.
> For you two examples:
>
> SuspendUser: would be like active =3D false
> D= eleteMailbox: The scim user has no mailbox so what should the system
> do? For my understanding a mailbox like something could only= be a part
> of an extension but not of the standard us= er. So it looks like that the
> meta.action would be very client speci= fic.
>
>
> b= y David
>
> Am 25.03.2014 05:17, s= chrieb Bill Mills:
>> The problem is that in a PATCH= or PUT any action to be taken on the
>> account has= to be inferred from the data changes.  This also means that
>> everyone has to share the entire schema for how an acount is= managed.
>>
>> We have a sy= stem that looks very much like SCIM (not a suprise since
&= gt;> SCIM is standardizing a common task) but we have action verbs with d= ata.
>>  Comparing the two I much prefer the ac= tion verb with supporting data
>> model.  In th= e current SCIM model actions have to be inferred from data
>> changes.
>>
>> For= example we might have a "create_mailbox" verb, where in SCIM I need
>> to compare the current state to the new state and dtermi= ne that
>> "mailbox_active" changed from "0" to "1".=
>>
>> -bill
>>
>>
>> On Monday= , March 24, 2014 8:20 PM, Morteza Ansari (moransar)
>&g= t; <moransar@cisco.com <mailto:moran= sar@cisco.com>> wrote:
>> Bill,
>>
>> Can you expand on the problem thi= s would solve?  I know this came up on
>> one o= f the calls a while ago but I don=E2=80=99t think the problem is clearly
>> captured on the mailing list before.
&g= t;>
>>
>> Cheers,
>> Morteza
>>
>= ;> From: Bill Mills <wmills_92105@yahoo.com=
> <mailto:wmills_92105@yahoo= .com> <mailto:wmills_92105@yahoo.com> <mailto:wmills_92105@yahoo.co= m>>>
>> Reply-To: Bill Mills <wmills_92105@yahoo.com
> <mailt= o:wmills_92105@yahoo.com>
&g= t;> <mailto:wmills_92105@yahoo.com <mail= to:wmills_92105@yahoo.com>>>
>> Date: Monday, March 24, 2014 at 3:19 PM
&g= t;> To: "scim@ietf.org <mailto:scim@ietf.org> <= ;mailto:scim@ietf.org
> <mailto:scim@i= etf.org>>" <scim@ietf.org <mailto:scim@ietf.org<= /a>>
>> <mailto:scim@ietf.org <mai= lto:scim@ietf.org>>>
>> Subject: [= scim] metadata and actions
>>
>= > "meta" is used to return metadata about entries and in the case of PATC= H
>> it's used to specify elements to delete.  I= 'd like to propose a new
>> "meta" element for actio= n to be taken.  I think this would solve some of
>> the question of triggering actions based on a= PATCH.  So for example:
>>
&= gt;> "meta": {
>>    "action": ["Suspen= dUser", "DeleteMailbox"]
>>
>&g= t; }
>>
>>
>> Specifies 2 actions to be taken along with whatever data changes a= re
>> applied.
>>
>> Does this sound workable?
>>
>> -bill
>>
>&= gt; _______________________________________________
>&g= t; scim mailing list
>> scim@ietf.org <m= ailto:scim@ietf.org> <mailto:scim@ietf.org
> <mailto:scim@ietf.org>>
>= > https://www.ietf.org/mailman/listinfo/scim
>>
>>
>>
>>
>> _____________________________= __________________
>> scim mailing list
>> scim@ietf.org <mailto:scim@ietf.org>>> https://www.ietf.org/mailman/listinfo/= scim

&g= t;
>>
>
>= ; _______________________________________________
> sci= m mailing list
> scim@ietf.org <mailto:scim@ietf.org>
> https://www.ietf.o= rg/mailman/listinfo/scim
>
> <= br clear=3D"none">
_______________________________________= ________
scim mailing list
scim@iet= f.org
https://www.ietf.org/mailman/listinf= o/scim


_________________= ______________________________
scim mailing list
<= span>scim@ietf.org
https://www.ietf.org/mail= man/listinfo/scim
= --Apple-Mail-A7EA80D0-3A2B-42FE-B74C-A784D935DD14-- From nobody Tue Mar 25 22:16:56 2014 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 25B3F1A00C2 for ; Tue, 25 Mar 2014 22:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 zDrB2k749O0A for ; Tue, 25 Mar 2014 22:16:51 -0700 (PDT) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) by ietfa.amsl.com (Postfix) with ESMTP id B3A521A00C0 for ; Tue, 25 Mar 2014 22:16:50 -0700 (PDT) Received: from [66.196.81.171] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2014 05:16:49 -0000 Received: from [98.139.212.204] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2014 05:16:49 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 26 Mar 2014 05:16:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 138738.54985.bm@omp1013.mail.bf1.yahoo.com Received: (qmail 48935 invoked by uid 60001); 26 Mar 2014 05:16:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395811008; bh=UFim4RByD9jXx0GmWAvHeNCd0tqIfURpY14frouuonE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Rn1cTP3DMkyrvdbUHh8WnnP+QhdrcetjMm/+eTzZ2wzehrQzvCHfS2ukgl75cKotR6MzURUjYi8h+vRyWDWNGx/0DMTD4XkE0XnKrTjYq/jqj1pcTT2UySNcO2QPl6ibJpA5QhbxIrpDMz4q5ze5NgSAtOOZpPO/FsD33QtQtnY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Hbv1x3fqI/OU0YM7mFAvrTyuF3u3C5bxYnWAfc3Ir9LqznKdjE3kTh+SoOCmg+ZC6uncqnFoO3W1DV8K//cIBmhbQZ+WMn1ZVQALtX3/B/D9Esn4SKLwPAP3V+2myx0mRmBXlasMyrJFrvqCUGGboD3KFVpZdObWapCiz0fPslo=; X-YMail-OSG: EU2b1fwVM1k4X62Tpo98RtS204IIiD5czs959a0j659dC5q ElJIZTZiuEb2oh1jow6KYdsL_rSUw8VYlK2kGP34kbZS1VO86yWSOocY0CsJ 6HOsl3rOioVnSga4CPcwOOKYOCdn49KcgCGKG2s8pJhizJbymFWg5Z7W2dJt id54rZtDTpQdpBY5_SzkNfVyRc4JSthjWg6Vq_jAALYlKnYR5EM4dL9pRI1o 3woXBj0VhzUS.i3UvVA2WCtOaYPh4VoFkVPCdpb4p1XqxjGRgfdcZ3Efqu3i nISEQHGranBSAgmr7wqRWd9mnZFOSdTiU5JBX6YAeVCQI7t8zk47XZBPZ2Dr GmhmJHz1w85VdgNG.3.q_L.SDVr78W2r2dLElipj9GixEbKOJ0pFwISZuLmb VA8iIhPCHqIH7UAjlV286J0riQf5jpkjgiopkN34J7PLzdVJlRig9drFdXJE uXA7n2ABWjb_urjVAqQsiVQblFMy_VlnWqjBLDyyD76826iPNF_CBMjl3DE6 wav9sB_xKmkkchZRiWxCapu2Eqq0w.pX8131Zc1aQEj_wXX_bAW8ErA-- Received: from [99.31.212.42] by web142803.mail.bf1.yahoo.com via HTTP; Tue, 25 Mar 2014 22:16:48 PDT X-Rocket-MIMEInfo: 002.001, SSBhZ3JlZSwgaXQncyBub3QgUkVTVC1mdWwgcGVyaGFwcywgYnV0IEkgYWxzbyB0aGluayBSRVNUIGlzIGFuIDgwJSBzb2x1dGlvbi4KCkRvZXMgYWRkaW5nIGEgIm5vLXN0b3JlIiBtdXRhYmlsaXR5IHZhcmlhbnQgbWFrZSBhIGJldHRlciBzb2x1dGlvbj8KCgoKT24gVHVlc2RheSwgTWFyY2ggMjUsIDIwMTQgODozMiBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4gd3JvdGU6CiAKSXQgc2VlbXMgbGlrZSB5b3UgYXJlIGRlZmluaW5nIGhpZ2gtbGV2ZWwgImZ1bmN0aW9ucyIgcmF0aGVyIHQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.181.645 References: <1395699572.32920.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1395721026.16897.YahooMailNeo@web142806.mail.bf1.yahoo.com> <53311CB8.40007@tarent.de> <1395758559.2114.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53319786.30506@tarent.de> <1395762868.98394.YahooMailNeo@web142806.mail.bf1.yahoo.com> <1F458548-58CD-4BC3-8024-1752DED636A8@oracle.com> Message-ID: <1395811008.57103.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Tue, 25 Mar 2014 22:16:48 -0700 (PDT) From: Bill Mills To: Phil Hunt In-Reply-To: <1F458548-58CD-4BC3-8024-1752DED636A8@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="905790552-1472540229-1395811008=:57103" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/LijxOr2mdrvkBLVl9PTAhVovbOQ Cc: =?utf-8?B?RGF2aWQgTcO2Yml1cw==?= , "scim@ietf.org" Subject: Re: [scim] metadata and actions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 05:16:53 -0000 --905790552-1472540229-1395811008=:57103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree, it's not REST-ful perhaps, but I also think REST is an 80% solutio= n.=0A=0ADoes adding a "no-store" mutability variant make a better solution?= =0A=0A=0A=0AOn Tuesday, March 25, 2014 8:32 PM, Phil Hunt wrote:=0A =0AIt seems like you are defining high-level "functions" ra= ther than simple stateful changes.=C2=A0=0A=0AI agree on the need, but i th= ink many will say this is not RESTful. =C2=A0=0A=0APhil=0A=0AOn Mar 25, 201= 4, at 8:54, Bill Mills wrote:=0A=0A=0A1) I do not = want to explicitly store the transactions, but I may log them in a differen= t field. =C2=A0A "no-store" mutability value could solve this too.=0A>=0A>= =0A>2) SCIM really needs this concept. =C2=A0Diffs of data to determine wha= t actions to take is not a great thing.=0A>=0A>=0A>=0A>On Tuesday, March 25= , 2014 7:49 AM, David M=C3=B6bius wrote:=0A> =0A>Yea = that is sure but I think the meta attribute should only be for scim=0A>attr= ibutes.=0A>=0A>I don't know how you implement your code but I think you hav= e your=0A>"mailbox" or what else in some kind of extension. In this case yo= u just=0A>could definde an additional field in your extension where you sto= re the=0A>actions.=0A>=0A>David=0A>=0A>Am 25.03.2014 15:42, schrieb Bill Mi= lls:=0A>> What I'm asking for is a defined extension to the "meta" element,= not=0A>>=C2=A0 "mailbox" element.=C2=A0 We'll define our own schema as nee= ded for the=0A>> things spefici to our provisioning environment.=C2=A0 SCIM= is about=0A managing=0A>> users AND things asociated with them, so a mailb= ox is a reasonable=0A>> resource to be managing which is why I chose it as = an example.=0A>> =0A>> =0A>> On Monday, March 24, 2014 11:05 PM, David M=C3= =B6bius =0A>> wrote:=0A>> Hello Bill,=0A>> =0A>> I als= o don't realy understand why you need this action.=0A>> For you two example= s:=0A>> =0A>> SuspendUser: would be like active =3D false=0A>> DeleteMailbo= x: The scim user has no mailbox so what should the system=0A>> do? For my u= nderstanding a mailbox like something could only be a part=0A>> of an exten= sion but not of the standard user. So it looks=0A like that the=0A>> meta.a= ction would be very client specific.=0A>> =0A>> =0A>> by David=0A>> =0A>> A= m 25.03.2014 05:17, schrieb Bill Mills:=0A>>> The problem is that in a PATC= H or PUT any action to be taken on the=0A>>> account has to be inferred fro= m the data changes.=C2=A0 This also means that=0A>>> everyone has to share = the entire schema for how an acount is managed.=0A>>>=0A>>> We have a syste= m that looks very much like SCIM (not a suprise since=0A>>> SCIM is standar= dizing a common task) but we have action verbs with data.=0A>>>=C2=A0 Compa= ring the two I much prefer the action verb with supporting data=0A>>> model= .=C2=A0 In the current SCIM model actions have to be inferred from data=0A>= >> changes.=0A>>>=0A>>> For example we might have a "create_mailbox" verb, = where in SCIM I need=0A>>> to compare the current state to the new state an= d dtermine that=0A>>> "mailbox_active" changed from "0" to "1". =0A>>>=0A>>= > -bill=0A>>>=0A>>>=0A>>> On Monday, March 24, 2014 8:20 PM, Morteza Ansari= (moransar)=0A>>> > wrote:= =0A>>> Bill,=0A>>>=0A>>> Can you expand on the problem this would solve?=C2= =A0 I know this came up on=0A>>> one of the=0A calls a while ago but I don= =E2=80=99t think the problem is clearly=0A>>> captured on the mailing list = before.=0A>>>=0A>>>=0A>>> Cheers,=0A>>> Morteza=0A>>>=0A>>> From: Bill Mill= s > > >>=0A>>> Reply-To: B= ill Mills > =0A>>= > >>=0A>>> Da= te: Monday, March 24, 2014 at 3:19 PM=0A>>> To: "scim@ietf.org > >" =0A>>> >>=0A>>> Subject: [scim] metadata and actions=0A>>>=0A>>> "meta" is used t= o return metadata about entries and in the case of PATCH=0A>>> it's used to= specify elements to delete.=C2=A0 I'd like to propose a new=0A>>> "meta" e= lement for action to be taken.=C2=A0 I think this would solve some=0A of=0A= >>> the question of triggering actions based on a PATCH.=C2=A0 So for examp= le:=0A>>>=0A>>> "meta": {=0A>>>=C2=A0 =C2=A0 "action": ["SuspendUser", "Del= eteMailbox"]=0A>>>=0A>>> }=0A>>>=0A>>>=0A>>> Specifies 2 actions to be take= n along with whatever data changes are=0A>>> applied.=0A>>>=0A>>> Does this= sound workable?=0A>>>=0A>>> -bill=0A>>>=0A>>> ____________________________= ___________________=0A>>> scim mailing list=0A>>> scim@ietf.org > >=0A>>> https:= //www.ietf.org/mailman/listinfo/scim=0A>>>=0A>>>=0A>>>=0A>>>=0A>>> ________= _______________________________________=0A>>> scim mailing list=0A>>> scim@= ietf.org =0A>>> https://www.ietf.org/mailman/listinfo= /scim=0A>=0A>> =0A>>>=0A>> =0A>> __________________________________________= _____=0A>> scim mailing list=0A>> scim@ietf.org =0A>>= https://www.ietf.org/mailman/listinfo/scim=0A>> =0A>> =0A>=0A>____________= ___________________________________=0A>scim mailing list=0A>scim@ietf.org= =0A>https://www.ietf.org/mailman/listinfo/scim=0A>=0A>=0A>=0A______________= _________________________________=0A>scim mailing list=0A>scim@ietf.org=0A>= https://www.ietf.org/mailman/listinfo/scim=0A>=0A=0A_______________________= ________________________=0Ascim mailing list=0Ascim@ietf.org=0Ahttps://www.= ietf.org/mailman/listinfo/scim --905790552-1472540229-1395811008=:57103 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I agree, it's not REST-ful perhaps, but I also thi= nk REST is an 80% solution.

Does adding a "no-store" mutability variant make a better solu= tion?

On Tuesday, March 25, 2014 8:32 PM, Phil Hunt <ph= il.hunt@oracle.com> wrote:
It seems like you are defining hi= gh-level "functions" rather than simple stateful changes. 
<= br clear=3D"none">
I agree on the need, but i think many will say= this is not RESTful.  

Phil

On Mar 25, 2014, at 8:54, Bill Mills <wmills_92105@yahoo.com> wrote:=

=
1) I do not want to explicitly store the transactions, but I may l= og them in a different field.  A "no-store" mutability value could sol= ve this too.

2) SCIM really needs this concept.  Diffs of data = to determine what actions to take is not a great thing.

<= br clear=3D"none">
On Tuesday, March 25, 2014 7:49 AM, David M=C3=B6bius <= d.moebius@tarent.de> wrote:
Yea that is sure but I think the meta attribute should onl= y be for scim
attributes.

I don't know how you implement your code but I think you have your"mailbox" or what else in some kind of extension. In this c= ase you just
could definde an additional field in your ex= tension where you store the
actions.
David

Am 25.03.2014 1= 5:42, schrieb Bill Mills:
> What I'm asking for is a d= efined extension to the "meta" element, not
>  "mailbox" element.  We'll define our= own schema as needed for the
> things spefici to our = provisioning environment.  SCIM is about=0A managing
> users AND things asociated with them, so a mailbox is a reasonable> resource to be managing which is why I chose it as an = example.
>
>
= > On Monday, March 24, 2014 11:05 PM, David M=C3=B6bius <d.moebius@tarent.de>
> wrote:
> Hello Bill,
>
> I also don't realy understand why you need t= his action.
> For you two examples:
= >
> SuspendUser: would be like active =3D false> DeleteMailbox: The scim user has no mailbox so what sh= ould the system
> do? For my understanding a mailbox l= ike something could only be a part
> of an extension b= ut not of the standard user. So it looks=0A like that the
> met= a.action would be very client specific.
>
>
> by David
>
> Am 25.03.2014 05:17, schrieb Bill Mills:
>> The problem is that in a PATCH or PUT any action to be taken on t= he
>> account has to be inferred from the data chan= ges.  This also means that
>> everyone has to = share the entire schema for how an acount is managed.
>= ;>
>> We have a system that looks very much like= SCIM (not a suprise since
>> SCIM is standardizing= a common task) but we have action verbs with data.
>&= gt;  Comparing the two I much prefer the action verb with supporting d= ata
>> model.  In the current SCIM model actio= ns have to be inferred from data
>> changes.
>>
>> For example we might have a "create_mailbox" verb, where in SC= IM I need
>> to compare the current state to the ne= w state and dtermine that
>> "mailbox_active" chang= ed from "0" to "1".
>>
>> = -bill
>>
>>
>> On Monday, March 24, 2014 8:20 PM, Morteza Ansari (moransar)>> <moransar@cisco.com <mailto:moransar@cisco.com>> wrote:
>= > Bill,
>>
>> Can you ex= pand on the problem this would solve?  I know this came up on
>> one of the= =0A calls a while ago but I don=E2=80=99t think the problem is clearly
>> captured on the mailing list before.
>>
>>
>> Cheers,>> Morteza
>>
>> From: Bill Mills <wmills_92105@yahoo.com
> <mai= lto:wmills_92105= @yahoo.com> <mailto:wmills_92105@yahoo.com
> <mailto:= wmills_92105@yahoo.com>>&= gt;
>> Reply-To: Bill Mills <wmills_92105@yahoo.com
> <mailto:wmills_92105@yahoo.com>
>> <mai= lto:wmills_92105= @yahoo.com <mailto:wmills_92105@yahoo.com>>>
>>= Date: Monday, March 24, 2014 at 3:19 PM
>> To: "scim@ietf.org <mailto:scim@ietf.org> <mailto:scim@ietf.org
> <mailto:scim@ietf.org>>" <scim@ietf.org <mailto:scim@ietf.org>
>> <mailto:scim@ietf.org <mailto:scim@ietf.org>&= gt;>
>> Subject: [scim] metadata and actions
>>
>> "meta" is used to return= metadata about entries and in the case of PATCH
>>= it's used to specify elements to delete.  I'd like to propose a new>> "meta" element for action to be taken.  I th= ink this would solve some=0A of
>> the question of = triggering actions based on a PATCH.  So for example:
>>
>> "meta": {
>>&= nbsp;   "action": ["SuspendUser", "DeleteMailbox"]
&= gt;>
>> }
>>
>>
>> Specifies 2 actions to be taken = along with whatever data changes are
>> applied.>>
>> Does this sound workabl= e?
>>
>> -bill
>>
>> _________________________________= ______________
>> scim mailing list
>> scim@ietf.org <= mailto:scim@ietf.org> <mailto:scim@ietf.org
> <mailto:scim@ietf.org>>
>&= gt; https://www.ietf.org/mailman/listinfo/sci= m
>>
>>
>>
>>
>> _________= ______________________________________
>> scim mail= ing list
>> scim@ietf.org <mailto:scim@ietf.org>
>> https://www.ietf.org/mailman/listinfo/scim
>
>>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org <mailto:scim@ietf.org>
> https://www.ietf.org/m= ailman/listinfo/scim
>
>
________________________________________= _______
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim


=
_______________________________________________
= scim mailing list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim
<= /div>
_____________________= __________________________
scim mailing list
scim@ietf.org
https://www.ie= tf.org/mailman/listinfo/scim


--905790552-1472540229-1395811008=:57103-- From nobody Thu Mar 27 06:38:29 2014 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 859F91A0055 for ; Thu, 27 Mar 2014 06:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 am1du9EHatD0 for ; Thu, 27 Mar 2014 06:38:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0331A00B4 for ; Thu, 27 Mar 2014 06:38:20 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB390.namprd04.prod.outlook.com (10.141.60.147) with Microsoft SMTP Server (TLS) id 15.0.898.11; Thu, 27 Mar 2014 13:38:10 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.13]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.19]) with mapi id 15.00.0898.005; Thu, 27 Mar 2014 13:38:09 +0000 From: Kelly Grizzle To: Bill Mills , Phil Hunt Thread-Topic: [scim] metadata and actions Thread-Index: AQHPR68ls9sWKjeMfUq8eldJE5cdCJrxIwWAgAAPxgCAAB5aAIAAkG2AgAAB+ACAABIYAIAAwsGAgAAdawCAAhVRIA== Date: Thu, 27 Mar 2014 13:38:08 +0000 Message-ID: References: <1395699572.32920.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1395721026.16897.YahooMailNeo@web142806.mail.bf1.yahoo.com> <53311CB8.40007@tarent.de> <1395758559.2114.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53319786.30506@tarent.de> <1395762868.98394.YahooMailNeo@web142806.mail.bf1.yahoo.com> <1F458548-58CD-4BC3-8024-1752DED636A8@oracle.com> <1395811008.57103.YahooMailNeo@web142803.mail.bf1.yahoo.com> In-Reply-To: <1395811008.57103.YahooMailNeo@web142803.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 051B7F18006C78051B8065 x-originating-ip: [97.79.140.10] x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(24454002)(51704005)(189002)(199002)(377454003)(15594002)(33646001)(76576001)(97186001)(76796001)(76786001)(81816001)(81342001)(98676001)(49866001)(81686001)(50986001)(47736001)(47976001)(15975445006)(4396001)(551934002)(97336001)(77096001)(95416001)(2656002)(551544002)(87266001)(46102001)(74876001)(15202345003)(83072002)(47446002)(95666003)(74316001)(19300405004)(74706001)(69226001)(53806001)(85852003)(94316002)(16236675002)(56816005)(66066001)(87936001)(56776001)(74502001)(20776003)(63696002)(54316002)(31966008)(19580405001)(51856001)(19580395003)(74662001)(85306002)(83322001)(561944002)(74366001)(81542001)(19609705001)(93136001)(80976001)(65816001)(76482001)(92566001)(77982001)(59766001)(54356001)(80022001)(90146001)(86362001)(94946001)(79102001)(93516002)(24704002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB390; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:E6FFF1E4.A7FA93D0.B3F775BF.82E5E241.2069D; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: sailpoint.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_f69735c44a0842f2ab982deee3ac10d3BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/JAoS5SduQqqvNZHLKLOwCd3Pm0w Cc: =?utf-8?B?RGF2aWQgTcO2Yml1cw==?= , "scim@ietf.org" Subject: Re: [scim] metadata and actions 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: Thu, 27 Mar 2014 13:38:26 -0000 --_000_f69735c44a0842f2ab982deee3ac10d3BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHNlZW4gUkVTVCBBUElzIGFkZCBmdW5jdGlvbnMgaW4gYSBudW1iZXIgb2Ygd2F5cyAo YWx0aG91Z2gg4oCmIHRlY2huaWNhbGx5IG5vdCBhbGwgUkVTVC1mdWxseSkuICBIZXJlIGFyZSB0 aGUgZmV3IHRoYXQgSSBoYXZlIHNlZW4gbGlzdGVkIGZyb20gbW9zdCB0byBsZWFzdCBjb21tb24u DQoNCg0KMSkgICAgICBQT1NUIHRvIGEgc3ViLXJlc291cmNlIHRvIGNhdXNlIGFuIGFjdGlvbiB0 byBvY2N1ci4gIEV4YW1wbGU6DQpQT1NUIC9Vc2Vycy8xMjM0L2RlbGV0ZU1haWxib3gNCg0KDQoy KSAgICAgIEluY2x1ZGUgYW4gYWN0aW9uIGluIHRoZSBQT1NUIHRvIHRoZSBlbmRwb2ludCAodGhp cyBpcyB5b3VyIHN1Z2dlc3Rpb24pLiAgRXhhbXBsZToNCg0KUE9TVCAvVXNlcnMvMTIzNA0KDQp7 DQoNCiAg4oCcbWV0YeKAnTogeyDigJxhY3Rpb27igJ06IOKAnGRlbGV0ZU1haWxib3jigJ0gfQ0K DQp9DQoNCiAgICAgICAgICAgICAgICBTaW1pbGFybHksIHRoaXMgY291bGQgYmUgYWNoaWV2ZWQg YnkgZXh0ZW5kaW5nIHRoZSBzY2hlbWEgYW5kIGFkZGluZyBhbiBhY3Rpb24gYXR0cmlidXRlLiAg RXhhbXBsZToNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQT1NUIC9Vc2Vycy8x MjM0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCiDigJx1cm46eWFob2/igJ06 IHsNCiAgICDigJxhY3Rpb27igJ06IOKAnGRlbGV0ZU1haWxib3jigJ0sDQoNCiAgICDigKYgc29t ZSBkYXRhIHRoYXQgcHJvdmlkZXMgcGFyYW1ldGVycyBmb3IgdGhlIGRlbGV0ZU1haWxib3ggY29t bWFuZCDigKYNCiAgfQ0KfQ0KDQoNCjMpICAgICAgSW5jbHVkZSBhIOKAnGNvbW1hbmQgb2JqZWN0 4oCdIGluIHRoZSBQT1NUIGJvZHkgdG8gdGhlIGVuZHBvaW50IHJhdGhlciB0aGFuIGEgcmVwcmVz ZW50YXRpb24gb2YgdGhlIGVuZHBvaW50LiAgVGhpcyBpcyBzaW1pbGFyIHRvIHdoYXQgdGhlIG5l dyBQQVRDSCBwcm9wb3NhbCBkb2VzLCBidXQgaXMga2V5ZWQgb2ZmIG9mIGEgc3BlY2lhbCBIVFRQ IGhlYWRlciBvciB0aGUgQ29udGVudC1UeXBlIGhlYWRlci4gIEV4YW1wbGU6DQoNClBPU1QgL1Vz ZXJzLzEyMzQNCg0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi95YWhvby5kZWxldGVNYWlsYm94 K2pzb24NCg0Kew0KDQogIOKApiBzb21lIGRhdGEgdGhhdCBwcm92aWRlcyBwYXJhbWV0ZXJzIGZv ciB0aGUgZGVsZXRlTWFpbGJveCBjb21tYW5kIOKApg0KDQp9DQoNCg0KDQoNCg0KVGhlcmUgYXJl IHByb3MgYW5kIGNvbnMgdG8gZWFjaCBhcHByb2FjaC4NCg0KDQoNClRoZSBmaXJzdCBhcHByb2Fj aCBkb2VzIG5vdCBhbGxvdyBmb3IgZGVsZXRpbmcgYSBtYWlsYm94IHdoaWxlIHVwZGF0aW5nIG90 aGVyIGF0dHJpYnV0ZXMgb24gdGhlIHVzZXIuICBBbHNvLCBTQ0lNIGRvZXNu4oCZdCBjdXJyZW50 bHkgaGF2ZSBhIGdvb2QgZXh0ZW5zaW9uIG1lY2hhbmlzbSB0byBkZWZpbmUgdGhpcyDigKYgbWF5 YmUgdGhyb3VnaCBhIFJlc291cmNlVHlwZSBidXQgdGhpcyB3b3VsZCBiZSBhIHN0cmV0Y2guDQoN Cg0KDQpVc2luZyBtZXRhIGluIHRoZSBzZWNvbmQgYXBwcm9hY2ggaXMgZWFzaWVyIHRvIHNvbHZl IGZyb20gYW4gZXh0ZW5zaWJpbGl0eSBwZXJzcGVjdGl2ZSwgYnV0IHdlIHdvdWxkIHByb2JhYmx5 IHdhbnQgYSB3YXkgZm9yIHNlcnZpY2UgcHJvdmlkZXJzIHRvIHJldHVybiB3aGljaCBhY3Rpb25z IHRoZXkgc3VwcG9ydCAoZWcg4oCTIHRocm91Z2ggdGhlIFJlc291cmNlVHlwZSBlbmRwb2ludCku DQoNCg0KDQpVc2luZyBhIG5vcm1hbCBzY2hlbWEgZXh0ZW5zaW9uIGluIHRoZSBzZWNvbmQgYXBw cm9hY2ggd291bGRu4oCZdCByZXF1aXJlIGFueSBjaGFuZ2VzIHRvIHRoZSBzcGVjLiAgWW91IHdv dWxkIGp1c3QgYWRkIGFuIOKAnGFjdGlvbuKAnSBhdHRyaWJ1dGUgdG8gdGhlIGV4dGVuc2lvbiBh bmQgc2V0IHRoZSBtdXRhYmlsaXR5IHRvIHdyaXRlT25seS4gIFRoaXMgaGFzIHRoZSBhZGRlZCBi ZW5lZml0IHRoYXQgYW55IGRhdGEgcmVxdWlyZWQgYnkgdGhlIGFjdGlvbiAoZWcg4oCTIGFjdGlv biA9IOKAnHNldE1haWxib3hTaXpl4oCdLCBuZXdNYWlsYm94U2l6ZSA9IDEwMDAwMDApIGlzIGRl ZmluZWQgaW4gdGhlIHNhbWUgcGxhY2UuDQoNCg0KDQpUaGUgbGFzdCBhcHByb2FjaCBpcyB2ZXJ5 IHVuY29tbW9uIGFuZCB3b3VsZCBiZSB0aGUgbGFyZ2VzdCBjaGFuZ2UgdG8gdGhlIHNwZWMsIHNv IEnigJlsbCBsZWF2ZSBpdCBvdXQuICBGdW5jdGlvbmFsbHksIGl0IGlzIHZlcnkgc2ltaWxhciB0 byBvcHRpb24gMS4NCg0KDQoNCg0KDQpTQ0lNIGRvZXMgaGF2ZSBhIGNvdXBsZSBvZiBwbGFjZXMg d2hlcmUgaXQgd291bGQgYmUgbmljZSB0byBoYXZlIGFjdGlvbnMuICBBcyB5b3UgbWVudGlvbmVk LCBjaGFuZ2luZyB0aGUgaW5hY3RpdmUgZmxhZyBpcyBub3QgYWx3YXlzIGlkZWFsIChhbHRob3Vn aCB0aGlzIGlzIHByb2JhYmx5IHRoZSBjb3JyZWN0IGxvd2VzdCBjb21tb24gZGVub21pbmF0b3Ig YWNyb3NzIHNlcnZpY2UgcHJvdmlkZXJzKS4gIEFsc28sIGNoYW5naW5nIGEgcGFzc3dvcmQgaXMg YW5vdGhlciB0aGluZyB0aGF0IHdlIGhhdmUgc2hvZS1ob3JuZWQgaW50byBhbiBhdHRyaWJ1dGUg KHNlZSB0aWNrZXQgMTQgZm9yIHdoZXJlIHRoaXMgaGFzIGZhbGxlbiBzaG9ydCAtIGh0dHA6Ly90 b29scy5pZXRmLm9yZy93Zy9zY2ltL3RyYWMvdGlja2V0LzE0KS4gIFRoZSBkaWZmaWN1bHQgdGhp bmcgd2l0aCB0aGVzZSBpcyB0aGF0IHlvdSBvZnRlbiBuZWVkIHRvIGRvIHRoZW0gaW4gY29uanVu Y3Rpb24gd2l0aCBhbm90aGVyIGFjdGlvbiDigJMgc3VjaCBhcyBzZXR0aW5nIHRoZSBwYXNzd29y ZCB3aGVuIHlvdSBjcmVhdGUgYSB1c2VyLg0KDQoNCg0KTXkgb3BpbmlvbiBpcyB0aGF0IHdlIHNo b3VsZCBqdXN0IHVzZSBleHRlbnNpb25zIHRvIGRlZmluZSBhY3Rpb25zIChvcHRpb24gMmIpLiAg VGhpcyBwcm92aWRlcyBhIGdvb2QgYW1vdW50IG9mIGZsZXhpYmlsaXR5IGZvciBtaXhpbmcgaW4g YWN0aW9ucyB3aXRoIG90aGVyIG9wZXJhdGlvbiAoY3JlYXRlIGFuZCB1cGRhdGUpLCBhbmQgd2Ug YWxyZWFkeSBoYXZlIGEgZmFjaWxpdHkgZm9yIHRoaXMgdGhyb3VnaCBzY2hlbWEgZXh0ZW5zaW9u LiAgRXNzZW50aWFsbHksIHRoaXMgaXMganVzdCBtb3ZpbmcgdGhlIGFjdGlvbiBmcm9tIHRoZSBt ZXRhIGF0dHJpYnV0ZSB0byBhbiBleHRlbnNpb24uDQoNCg0KDQotLUtlbGx5DQoNCkZyb206IHNj aW0gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCaWxsIE1pbGxz DQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDI2LCAyMDE0IDEyOjE3IEFNDQpUbzogUGhpbCBIdW50 DQpDYzogRGF2aWQgTcO2Yml1czsgc2NpbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzY2ltXSBt ZXRhZGF0YSBhbmQgYWN0aW9ucw0KDQpJIGFncmVlLCBpdCdzIG5vdCBSRVNULWZ1bCBwZXJoYXBz LCBidXQgSSBhbHNvIHRoaW5rIFJFU1QgaXMgYW4gODAlIHNvbHV0aW9uLg0KDQpEb2VzIGFkZGlu ZyBhICJuby1zdG9yZSIgbXV0YWJpbGl0eSB2YXJpYW50IG1ha2UgYSBiZXR0ZXIgc29sdXRpb24/ DQoNCk9uIFR1ZXNkYXksIE1hcmNoIDI1LCAyMDE0IDg6MzIgUE0sIFBoaWwgSHVudCA8cGhpbC5o dW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQpJdCBz ZWVtcyBsaWtlIHlvdSBhcmUgZGVmaW5pbmcgaGlnaC1sZXZlbCAiZnVuY3Rpb25zIiByYXRoZXIg dGhhbiBzaW1wbGUgc3RhdGVmdWwgY2hhbmdlcy4NCg0KSSBhZ3JlZSBvbiB0aGUgbmVlZCwgYnV0 IGkgdGhpbmsgbWFueSB3aWxsIHNheSB0aGlzIGlzIG5vdCBSRVNUZnVsLg0KDQpQaGlsDQoNCk9u IE1hciAyNSwgMjAxNCwgYXQgODo1NCwgQmlsbCBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNv bTxtYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4+IHdyb3RlOg0KMSkgSSBkbyBub3Qgd2Fu dCB0byBleHBsaWNpdGx5IHN0b3JlIHRoZSB0cmFuc2FjdGlvbnMsIGJ1dCBJIG1heSBsb2cgdGhl bSBpbiBhIGRpZmZlcmVudCBmaWVsZC4gIEEgIm5vLXN0b3JlIiBtdXRhYmlsaXR5IHZhbHVlIGNv dWxkIHNvbHZlIHRoaXMgdG9vLg0KDQoyKSBTQ0lNIHJlYWxseSBuZWVkcyB0aGlzIGNvbmNlcHQu ICBEaWZmcyBvZiBkYXRhIHRvIGRldGVybWluZSB3aGF0IGFjdGlvbnMgdG8gdGFrZSBpcyBub3Qg YSBncmVhdCB0aGluZy4NCg0KT24gVHVlc2RheSwgTWFyY2ggMjUsIDIwMTQgNzo0OSBBTSwgRGF2 aWQgTcO2Yml1cyA8ZC5tb2ViaXVzQHRhcmVudC5kZTxtYWlsdG86ZC5tb2ViaXVzQHRhcmVudC5k ZT4+IHdyb3RlOg0KWWVhIHRoYXQgaXMgc3VyZSBidXQgSSB0aGluayB0aGUgbWV0YSBhdHRyaWJ1 dGUgc2hvdWxkIG9ubHkgYmUgZm9yIHNjaW0NCmF0dHJpYnV0ZXMuDQoNCkkgZG9uJ3Qga25vdyBo b3cgeW91IGltcGxlbWVudCB5b3VyIGNvZGUgYnV0IEkgdGhpbmsgeW91IGhhdmUgeW91cg0KIm1h aWxib3giIG9yIHdoYXQgZWxzZSBpbiBzb21lIGtpbmQgb2YgZXh0ZW5zaW9uLiBJbiB0aGlzIGNh c2UgeW91IGp1c3QNCmNvdWxkIGRlZmluZGUgYW4gYWRkaXRpb25hbCBmaWVsZCBpbiB5b3VyIGV4 dGVuc2lvbiB3aGVyZSB5b3Ugc3RvcmUgdGhlDQphY3Rpb25zLg0KDQpEYXZpZA0KDQpBbSAyNS4w My4yMDE0IDE1OjQyLCBzY2hyaWViIEJpbGwgTWlsbHM6DQo+IFdoYXQgSSdtIGFza2luZyBmb3Ig aXMgYSBkZWZpbmVkIGV4dGVuc2lvbiB0byB0aGUgIm1ldGEiIGVsZW1lbnQsIG5vdA0KPiAgIm1h aWxib3giIGVsZW1lbnQuICBXZSdsbCBkZWZpbmUgb3VyIG93biBzY2hlbWEgYXMgbmVlZGVkIGZv ciB0aGUNCj4gdGhpbmdzIHNwZWZpY2kgdG8gb3VyIHByb3Zpc2lvbmluZyBlbnZpcm9ubWVudC4g IFNDSU0gaXMgYWJvdXQgbWFuYWdpbmcNCj4gdXNlcnMgQU5EIHRoaW5ncyBhc29jaWF0ZWQgd2l0 aCB0aGVtLCBzbyBhIG1haWxib3ggaXMgYSByZWFzb25hYmxlDQo+IHJlc291cmNlIHRvIGJlIG1h bmFnaW5nIHdoaWNoIGlzIHdoeSBJIGNob3NlIGl0IGFzIGFuIGV4YW1wbGUuDQo+DQo+DQo+IE9u IE1vbmRheSwgTWFyY2ggMjQsIDIwMTQgMTE6MDUgUE0sIERhdmlkIE3DtmJpdXMgPGQubW9lYml1 c0B0YXJlbnQuZGU8bWFpbHRvOmQubW9lYml1c0B0YXJlbnQuZGU+Pg0KPiB3cm90ZToNCj4gSGVs bG8gQmlsbCwNCj4NCj4gSSBhbHNvIGRvbid0IHJlYWx5IHVuZGVyc3RhbmQgd2h5IHlvdSBuZWVk IHRoaXMgYWN0aW9uLg0KPiBGb3IgeW91IHR3byBleGFtcGxlczoNCj4NCj4gU3VzcGVuZFVzZXI6 IHdvdWxkIGJlIGxpa2UgYWN0aXZlID0gZmFsc2UNCj4gRGVsZXRlTWFpbGJveDogVGhlIHNjaW0g dXNlciBoYXMgbm8gbWFpbGJveCBzbyB3aGF0IHNob3VsZCB0aGUgc3lzdGVtDQo+IGRvPyBGb3Ig bXkgdW5kZXJzdGFuZGluZyBhIG1haWxib3ggbGlrZSBzb21ldGhpbmcgY291bGQgb25seSBiZSBh IHBhcnQNCj4gb2YgYW4gZXh0ZW5zaW9uIGJ1dCBub3Qgb2YgdGhlIHN0YW5kYXJkIHVzZXIuIFNv IGl0IGxvb2tzIGxpa2UgdGhhdCB0aGUNCj4gbWV0YS5hY3Rpb24gd291bGQgYmUgdmVyeSBjbGll bnQgc3BlY2lmaWMuDQo+DQo+DQo+IGJ5IERhdmlkDQo+DQo+IEFtIDI1LjAzLjIwMTQgMDU6MTcs IHNjaHJpZWIgQmlsbCBNaWxsczoNCj4+IFRoZSBwcm9ibGVtIGlzIHRoYXQgaW4gYSBQQVRDSCBv ciBQVVQgYW55IGFjdGlvbiB0byBiZSB0YWtlbiBvbiB0aGUNCj4+IGFjY291bnQgaGFzIHRvIGJl IGluZmVycmVkIGZyb20gdGhlIGRhdGEgY2hhbmdlcy4gIFRoaXMgYWxzbyBtZWFucyB0aGF0DQo+ PiBldmVyeW9uZSBoYXMgdG8gc2hhcmUgdGhlIGVudGlyZSBzY2hlbWEgZm9yIGhvdyBhbiBhY291 bnQgaXMgbWFuYWdlZC4NCj4+DQo+PiBXZSBoYXZlIGEgc3lzdGVtIHRoYXQgbG9va3MgdmVyeSBt dWNoIGxpa2UgU0NJTSAobm90IGEgc3VwcmlzZSBzaW5jZQ0KPj4gU0NJTSBpcyBzdGFuZGFyZGl6 aW5nIGEgY29tbW9uIHRhc2spIGJ1dCB3ZSBoYXZlIGFjdGlvbiB2ZXJicyB3aXRoIGRhdGEuDQo+ PiAgQ29tcGFyaW5nIHRoZSB0d28gSSBtdWNoIHByZWZlciB0aGUgYWN0aW9uIHZlcmIgd2l0aCBz dXBwb3J0aW5nIGRhdGENCj4+IG1vZGVsLiAgSW4gdGhlIGN1cnJlbnQgU0NJTSBtb2RlbCBhY3Rp b25zIGhhdmUgdG8gYmUgaW5mZXJyZWQgZnJvbSBkYXRhDQo+PiBjaGFuZ2VzLg0KPj4NCj4+IEZv ciBleGFtcGxlIHdlIG1pZ2h0IGhhdmUgYSAiY3JlYXRlX21haWxib3giIHZlcmIsIHdoZXJlIGlu IFNDSU0gSSBuZWVkDQo+PiB0byBjb21wYXJlIHRoZSBjdXJyZW50IHN0YXRlIHRvIHRoZSBuZXcg c3RhdGUgYW5kIGR0ZXJtaW5lIHRoYXQNCj4+ICJtYWlsYm94X2FjdGl2ZSIgY2hhbmdlZCBmcm9t ICIwIiB0byAiMSIuDQo+Pg0KPj4gLWJpbGwNCj4+DQo+Pg0KPj4gT24gTW9uZGF5LCBNYXJjaCAy NCwgMjAxNCA4OjIwIFBNLCBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpDQo+PiA8bW9yYW5zYXJA Y2lzY28uY29tPG1haWx0bzptb3JhbnNhckBjaXNjby5jb20+IDxtYWlsdG86bW9yYW5zYXJAY2lz Y28uY29tPG1haWx0bzptb3JhbnNhckBjaXNjby5jb20+Pj4gd3JvdGU6DQo+PiBCaWxsLA0KPj4N Cj4+IENhbiB5b3UgZXhwYW5kIG9uIHRoZSBwcm9ibGVtIHRoaXMgd291bGQgc29sdmU/ICBJIGtu b3cgdGhpcyBjYW1lIHVwIG9uDQo+PiBvbmUgb2YgdGhlIGNhbGxzIGEgd2hpbGUgYWdvIGJ1dCBJ IGRvbuKAmXQgdGhpbmsgdGhlIHByb2JsZW0gaXMgY2xlYXJseQ0KPj4gY2FwdHVyZWQgb24gdGhl IG1haWxpbmcgbGlzdCBiZWZvcmUuDQo+Pg0KPj4NCj4+IENoZWVycywNCj4+IE1vcnRlemENCj4+ DQo+PiBGcm9tOiBCaWxsIE1pbGxzIDx3bWlsbHNfOTIxMDVAeWFob28uY29tPG1haWx0bzp3bWls bHNfOTIxMDVAeWFob28uY29tPg0KPiA8bWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb208bWFp bHRvOndtaWxsc185MjEwNUB5YWhvby5jb20+PiA8bWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5j b208bWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb20+DQo+IDxtYWlsdG86d21pbGxzXzkyMTA1 QHlhaG9vLmNvbTxtYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4+Pj4NCj4+IFJlcGx5LVRv OiBCaWxsIE1pbGxzIDx3bWlsbHNfOTIxMDVAeWFob28uY29tPG1haWx0bzp3bWlsbHNfOTIxMDVA eWFob28uY29tPg0KPiA8bWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb208bWFpbHRvOndtaWxs c185MjEwNUB5YWhvby5jb20+Pg0KPj4gPG1haWx0bzp3bWlsbHNfOTIxMDVAeWFob28uY29tPG1h aWx0bzp3bWlsbHNfOTIxMDVAeWFob28uY29tPiA8bWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5j b208bWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb20+Pj4+DQo+PiBEYXRlOiBNb25kYXksIE1h cmNoIDI0LCAyMDE0IGF0IDM6MTkgUE0NCj4+IFRvOiAic2NpbUBpZXRmLm9yZzxtYWlsdG86c2Np bUBpZXRmLm9yZz4gPG1haWx0bzpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPj4g PG1haWx0bzpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KPiA8bWFpbHRvOnNj aW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+Pj4iIDxzY2ltQGlldGYub3JnPG1haWx0 bzpzY2ltQGlldGYub3JnPiA8bWFpbHRvOnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5v cmc+Pg0KPj4gPG1haWx0bzpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPiA8bWFp bHRvOnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+Pj4+DQo+PiBTdWJqZWN0OiBb c2NpbV0gbWV0YWRhdGEgYW5kIGFjdGlvbnMNCj4+DQo+PiAibWV0YSIgaXMgdXNlZCB0byByZXR1 cm4gbWV0YWRhdGEgYWJvdXQgZW50cmllcyBhbmQgaW4gdGhlIGNhc2Ugb2YgUEFUQ0gNCj4+IGl0 J3MgdXNlZCB0byBzcGVjaWZ5IGVsZW1lbnRzIHRvIGRlbGV0ZS4gIEknZCBsaWtlIHRvIHByb3Bv c2UgYSBuZXcNCj4+ICJtZXRhIiBlbGVtZW50IGZvciBhY3Rpb24gdG8gYmUgdGFrZW4uICBJIHRo aW5rIHRoaXMgd291bGQgc29sdmUgc29tZSBvZg0KPj4gdGhlIHF1ZXN0aW9uIG9mIHRyaWdnZXJp bmcgYWN0aW9ucyBiYXNlZCBvbiBhIFBBVENILiAgU28gZm9yIGV4YW1wbGU6DQo+Pg0KPj4gIm1l dGEiOiB7DQo+PiAgICAiYWN0aW9uIjogWyJTdXNwZW5kVXNlciIsICJEZWxldGVNYWlsYm94Il0N Cj4+DQo+PiB9DQo+Pg0KPj4NCj4+IFNwZWNpZmllcyAyIGFjdGlvbnMgdG8gYmUgdGFrZW4gYWxv bmcgd2l0aCB3aGF0ZXZlciBkYXRhIGNoYW5nZXMgYXJlDQo+PiBhcHBsaWVkLg0KPj4NCj4+IERv ZXMgdGhpcyBzb3VuZCB3b3JrYWJsZT8NCj4+DQo+PiAtYmlsbA0KPj4NCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzY2ltIG1haWxpbmcgbGlz dA0KPj4gc2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4gPG1haWx0bzpzY2ltQGll dGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPj4gPG1haWx0bzpzY2ltQGlldGYub3JnPG1haWx0 bzpzY2ltQGlldGYub3JnPg0KPiA8bWFpbHRvOnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0 Zi5vcmc+Pj4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbQ0K Pj4NCj4+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiBzY2ltIG1haWxpbmcgbGlzdA0KPj4gc2NpbUBpZXRmLm9yZzxtYWlsdG86 c2NpbUBpZXRmLm9yZz4gPG1haWx0bzpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3Jn Pj4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbQ0KDQo+DQo+ Pg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzY2ltIG1haWxpbmcgbGlzdA0KPiBzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3Jn PiA8bWFpbHRvOnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+Pg0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCj4NCj4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpz Y2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpzY2ltIG1haWxpbmcgbGlzdA0Kc2NpbUBpZXRmLm9yZzxtYWlsdG86 c2NpbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Np bQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2Np bSBtYWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg0K --_000_f69735c44a0842f2ab982deee3ac10d3BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1ODEyNTg1MTM7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMjU0NDI4OTQ4IDY3Njk4 NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoi JTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSBzZWVuIFJFU1Qg QVBJcyBhZGQgZnVuY3Rpb25zIGluIGEgbnVtYmVyIG9mIHdheXMgKGFsdGhvdWdoIOKApiB0ZWNo bmljYWxseSBub3QgYWxsIFJFU1QtZnVsbHkpLiZuYnNwOyBIZXJlIGFyZSB0aGUgZmV3IHRoYXQg SSBoYXZlIHNlZW4gbGlzdGVkIGZyb20gbW9zdCB0bw0KIGxlYXN0IGNvbW1vbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xKTxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBPU1QgdG8gYSBzdWIt cmVzb3VyY2UgdG8gY2F1c2UgYW4gYWN0aW9uIHRvIG9jY3VyLiZuYnNwOyBFeGFtcGxlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBPU1Qg L1VzZXJzLzEyMzQvZGVsZXRlTWFpbGJveDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ Mik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbmNsdWRlIGFu IGFjdGlvbiBpbiB0aGUgUE9TVCB0byB0aGUgZW5kcG9pbnQgKHRoaXMgaXMgeW91ciBzdWdnZXN0 aW9uKS4mbmJzcDsgRXhhbXBsZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QT1NUIC9Vc2Vycy8xMjM0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ezxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyDigJxtZXRh4oCdOiB7IOKAnGFjdGlvbuKAnTog4oCcZGVsZXRlTWFpbGJveOKAnSB9PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgU2ltaWxhcmx5LCB0aGlzIGNvdWxkIGJlIGFjaGlldmVkIGJ5 IGV4dGVuZGluZyB0aGUgc2NoZW1hIGFuZCBhZGRpbmcgYW4gYWN0aW9uIGF0dHJpYnV0ZS4mbmJz cDsgRXhhbXBsZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQT1NUIC9Vc2Vycy8xMjM0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A74oCcdXJu OnlhaG9v4oCdOiB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGFjdGlvbuKAnTog4oCcZGVsZXRlTWFp bGJveOKAnSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7ICZuYnNwOyZuYnNwO+KApiBzb21lIGRhdGEgdGhhdCBwcm92 aWRlcyBwYXJhbWV0ZXJzIGZvciB0aGUgZGVsZXRlTWFpbGJveCBjb21tYW5kIOKApjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDox LjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyB9 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjEuMGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Myk8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbmNsdWRlIGEg4oCcY29tbWFuZCBvYmplY3TigJ0gaW4g dGhlIFBPU1QgYm9keSB0byB0aGUgZW5kcG9pbnQgcmF0aGVyIHRoYW4gYSByZXByZXNlbnRhdGlv biBvZiB0aGUgZW5kcG9pbnQuJm5ic3A7IFRoaXMgaXMgc2ltaWxhciB0byB3aGF0IHRoZSBuZXcg UEFUQ0ggcHJvcG9zYWwNCiBkb2VzLCBidXQgaXMga2V5ZWQgb2ZmIG9mIGEgc3BlY2lhbCBIVFRQ IGhlYWRlciBvciB0aGUgQ29udGVudC1UeXBlIGhlYWRlci4mbmJzcDsgRXhhbXBsZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjEuMGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UE9TVCAvVXNlcnMvMTIzNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Db250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3lhaG9vLmRl bGV0ZU1haWxib3gmIzQzO2pzb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsg4oCmIHNvbWUgZGF0YSB0 aGF0IHByb3ZpZGVzIHBhcmFtZXRlcnMgZm9yIHRoZSBkZWxldGVNYWlsYm94IGNvbW1hbmQg4oCm PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPn08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGFyZSBwcm9zIGFuZCBj b25zIHRvIGVhY2ggYXBwcm9hY2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBmaXJzdCBhcHByb2FjaCBk b2VzIG5vdCBhbGxvdyBmb3IgZGVsZXRpbmcgYSBtYWlsYm94IHdoaWxlIHVwZGF0aW5nIG90aGVy IGF0dHJpYnV0ZXMgb24gdGhlIHVzZXIuJm5ic3A7IEFsc28sIFNDSU0gZG9lc27igJl0IGN1cnJl bnRseQ0KIGhhdmUgYSBnb29kIGV4dGVuc2lvbiBtZWNoYW5pc20gdG8gZGVmaW5lIHRoaXMg4oCm IG1heWJlIHRocm91Z2ggYSBSZXNvdXJjZVR5cGUgYnV0IHRoaXMgd291bGQgYmUgYSBzdHJldGNo LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5Vc2luZyBtZXRhIGluIHRoZSBzZWNvbmQgYXBwcm9hY2ggaXMgZWFz aWVyIHRvIHNvbHZlIGZyb20gYW4gZXh0ZW5zaWJpbGl0eSBwZXJzcGVjdGl2ZSwgYnV0IHdlIHdv dWxkIHByb2JhYmx5IHdhbnQgYSB3YXkgZm9yDQogc2VydmljZSBwcm92aWRlcnMgdG8gcmV0dXJu IHdoaWNoIGFjdGlvbnMgdGhleSBzdXBwb3J0IChlZyDigJMgdGhyb3VnaCB0aGUgUmVzb3VyY2VU eXBlIGVuZHBvaW50KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VXNpbmcgYSBub3JtYWwgc2NoZW1hIGV4dGVu c2lvbiBpbiB0aGUgc2Vjb25kIGFwcHJvYWNoIHdvdWxkbuKAmXQgcmVxdWlyZSBhbnkgY2hhbmdl cyB0byB0aGUgc3BlYy4mbmJzcDsgWW91IHdvdWxkIGp1c3QgYWRkIGFuIOKAnGFjdGlvbuKAnQ0K IGF0dHJpYnV0ZSB0byB0aGUgZXh0ZW5zaW9uIGFuZCBzZXQgdGhlIG11dGFiaWxpdHkgdG8gd3Jp dGVPbmx5LiZuYnNwOyBUaGlzIGhhcyB0aGUgYWRkZWQgYmVuZWZpdCB0aGF0IGFueSBkYXRhIHJl cXVpcmVkIGJ5IHRoZSBhY3Rpb24gKGVnIOKAkyBhY3Rpb24gPSDigJxzZXRNYWlsYm94U2l6ZeKA nSwgbmV3TWFpbGJveFNpemUgPSAxMDAwMDAwKSBpcyBkZWZpbmVkIGluIHRoZSBzYW1lIHBsYWNl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGUgbGFzdCBhcHByb2FjaCBpcyB2ZXJ5IHVuY29tbW9uIGFuZCB3 b3VsZCBiZSB0aGUgbGFyZ2VzdCBjaGFuZ2UgdG8gdGhlIHNwZWMsIHNvIEnigJlsbCBsZWF2ZSBp dCBvdXQuJm5ic3A7IEZ1bmN0aW9uYWxseSwgaXQgaXMgdmVyeQ0KIHNpbWlsYXIgdG8gb3B0aW9u IDEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U0NJTSBkb2VzIGhhdmUgYSBjb3VwbGUgb2Yg cGxhY2VzIHdoZXJlIGl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSBhY3Rpb25zLiZuYnNwOyBBcyB5 b3UgbWVudGlvbmVkLCBjaGFuZ2luZyB0aGUgaW5hY3RpdmUgZmxhZyBpcyBub3QNCiBhbHdheXMg aWRlYWwgKGFsdGhvdWdoIHRoaXMgaXMgcHJvYmFibHkgdGhlIGNvcnJlY3QgbG93ZXN0IGNvbW1v biBkZW5vbWluYXRvciBhY3Jvc3Mgc2VydmljZSBwcm92aWRlcnMpLiZuYnNwOyBBbHNvLCBjaGFu Z2luZyBhIHBhc3N3b3JkIGlzIGFub3RoZXIgdGhpbmcgdGhhdCB3ZSBoYXZlIHNob2UtaG9ybmVk IGludG8gYW4gYXR0cmlidXRlIChzZWUgdGlja2V0IDE0IGZvciB3aGVyZSB0aGlzIGhhcyBmYWxs ZW4gc2hvcnQgLQ0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3NjaW0vdHJhYy90 aWNrZXQvMTQiPmh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9zY2ltL3RyYWMvdGlja2V0LzE0PC9h PikuJm5ic3A7IFRoZSBkaWZmaWN1bHQgdGhpbmcgd2l0aCB0aGVzZSBpcyB0aGF0IHlvdSBvZnRl biBuZWVkIHRvIGRvIHRoZW0gaW4gY29uanVuY3Rpb24gd2l0aCBhbm90aGVyIGFjdGlvbiDigJMg c3VjaCBhcyBzZXR0aW5nIHRoZSBwYXNzd29yZCB3aGVuIHlvdSBjcmVhdGUgYSB1c2VyLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5NeSBvcGluaW9uIGlzIHRoYXQgd2Ugc2hvdWxkIGp1c3QgdXNlIGV4dGVuc2lv bnMgdG8gZGVmaW5lIGFjdGlvbnMgKG9wdGlvbiAyYikuJm5ic3A7IFRoaXMgcHJvdmlkZXMgYSBn b29kIGFtb3VudCBvZiBmbGV4aWJpbGl0eSBmb3INCiBtaXhpbmcgaW4gYWN0aW9ucyB3aXRoIG90 aGVyIG9wZXJhdGlvbiAoY3JlYXRlIGFuZCB1cGRhdGUpLCBhbmQgd2UgYWxyZWFkeSBoYXZlIGEg ZmFjaWxpdHkgZm9yIHRoaXMgdGhyb3VnaCBzY2hlbWEgZXh0ZW5zaW9uLiZuYnNwOyBFc3NlbnRp YWxseSwgdGhpcyBpcyBqdXN0IG1vdmluZyB0aGUgYWN0aW9uIGZyb20gdGhlIG1ldGEgYXR0cmli dXRlIHRvIGFuIGV4dGVuc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS1LZWxseTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkJpbGwgTWlsbHM8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXJjaCAyNiwg MjAxNCAxMjoxNyBBTTxicj4NCjxiPlRvOjwvYj4gUGhpbCBIdW50PGJyPg0KPGI+Q2M6PC9iPiBE YXZpZCBNw7ZiaXVzOyBzY2ltQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2Np bV0gbWV0YWRhdGEgYW5kIGFjdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgYWdyZWUsIGl0J3Mgbm90IFJFU1QtZnVsIHBlcmhhcHMs IGJ1dCBJIGFsc28gdGhpbmsgUkVTVCBpcyBhbiA4MCUgc29sdXRpb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRvZXMgYWRk aW5nIGEgJnF1b3Q7bm8tc3RvcmUmcXVvdDsgbXV0YWJpbGl0eSB2YXJpYW50IG1ha2UgYSBiZXR0 ZXIgc29sdXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk9uIFR1 ZXNkYXksIE1hcmNoIDI1LCAyMDE0IDg6MzIgUE0sIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdy b3RlOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9InlpdjA0ODc4MzI0NDciPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5JdCBzZWVtcyBsaWtlIHlvdSBhcmUgZGVmaW5pbmcgaGlnaC1sZXZl bCAmcXVvdDtmdW5jdGlvbnMmcXVvdDsgcmF0aGVyIHRoYW4gc2ltcGxlIHN0YXRlZnVsIGNoYW5n ZXMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+SSBhZ3JlZSBvbiB0aGUgbmVlZCwgYnV0IGkgdGhpbmsgbWFueSB3aWxsIHNheSB0 aGlzIGlzIG5vdCBSRVNUZnVsLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQpQaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJ5aXYwNDg3ODMyNDQ3eXF0OTM4OTgiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCk9uIE1hciAyNSwgMjAxNCwgYXQgODo1 NCwgQmlsbCBNaWxscyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb20i IHRhcmdldD0iX2JsYW5rIj53bWlsbHNfOTIxMDVAeWFob28uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjEpIEkgZG8gbm90IHdhbnQgdG8gZXhwbGljaXRseSBzdG9yZSB0aGUgdHJhbnNh Y3Rpb25zLCBidXQgSSBtYXkgbG9nIHRoZW0gaW4gYSBkaWZmZXJlbnQgZmllbGQuICZuYnNwO0Eg JnF1b3Q7bm8tc3RvcmUmcXVvdDsgbXV0YWJpbGl0eSB2YWx1ZSBjb3VsZCBzb2x2ZSB0aGlzIHRv by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjIpIFNDSU0gcmVhbGx5IG5lZWRzIHRo aXMgY29uY2VwdC4gJm5ic3A7RGlmZnMgb2YgZGF0YSB0byBkZXRlcm1pbmUgd2hhdCBhY3Rpb25z IHRvIHRha2UgaXMgbm90IGEgZ3JlYXQgdGhpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPk9uIFR1ZXNkYXksIE1hcmNoIDI1LCAyMDE0IDc6NDkgQU0sIERhdmlkIE3D tmJpdXMgJmx0OzxhIGhyZWY9Im1haWx0bzpkLm1vZWJpdXNAdGFyZW50LmRlIiB0YXJnZXQ9Il9i bGFuayI+ZC5tb2ViaXVzQHRhcmVudC5kZTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPlllYSB0aGF0IGlzIHN1cmUgYnV0IEkgdGhpbmsgdGhlIG1ldGEgYXR0cmli dXRlIHNob3VsZCBvbmx5IGJlIGZvciBzY2ltPGJyPg0KYXR0cmlidXRlcy48YnI+DQo8YnI+DQpJ IGRvbid0IGtub3cgaG93IHlvdSBpbXBsZW1lbnQgeW91ciBjb2RlIGJ1dCBJIHRoaW5rIHlvdSBo YXZlIHlvdXI8YnI+DQomcXVvdDttYWlsYm94JnF1b3Q7IG9yIHdoYXQgZWxzZSBpbiBzb21lIGtp bmQgb2YgZXh0ZW5zaW9uLiBJbiB0aGlzIGNhc2UgeW91IGp1c3Q8YnI+DQpjb3VsZCBkZWZpbmRl IGFuIGFkZGl0aW9uYWwgZmllbGQgaW4geW91ciBleHRlbnNpb24gd2hlcmUgeW91IHN0b3JlIHRo ZTxicj4NCmFjdGlvbnMuPGJyPg0KPGJyPg0KRGF2aWQ8YnI+DQo8YnI+DQpBbSAyNS4wMy4yMDE0 IDE1OjQyLCBzY2hyaWViIEJpbGwgTWlsbHM6PGJyPg0KJmd0OyBXaGF0IEknbSBhc2tpbmcgZm9y IGlzIGEgZGVmaW5lZCBleHRlbnNpb24gdG8gdGhlICZxdW90O21ldGEmcXVvdDsgZWxlbWVudCwg bm90PGJyPg0KJmd0OyZuYnNwOyAmcXVvdDttYWlsYm94JnF1b3Q7IGVsZW1lbnQuJm5ic3A7IFdl J2xsIGRlZmluZSBvdXIgb3duIHNjaGVtYSBhcyBuZWVkZWQgZm9yIHRoZTxicj4NCiZndDsgdGhp bmdzIHNwZWZpY2kgdG8gb3VyIHByb3Zpc2lvbmluZyBlbnZpcm9ubWVudC4mbmJzcDsgU0NJTSBp cyBhYm91dCBtYW5hZ2luZzxicj4NCiZndDsgdXNlcnMgQU5EIHRoaW5ncyBhc29jaWF0ZWQgd2l0 aCB0aGVtLCBzbyBhIG1haWxib3ggaXMgYSByZWFzb25hYmxlPGJyPg0KJmd0OyByZXNvdXJjZSB0 byBiZSBtYW5hZ2luZyB3aGljaCBpcyB3aHkgSSBjaG9zZSBpdCBhcyBhbiBleGFtcGxlLjxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIE1vbmRheSwgTWFyY2ggMjQsIDIwMTQgMTE6 MDUgUE0sIERhdmlkIE3DtmJpdXMgJmx0OzxhIGhyZWY9Im1haWx0bzpkLm1vZWJpdXNAdGFyZW50 LmRlIiB0YXJnZXQ9Il9ibGFuayI+ZC5tb2ViaXVzQHRhcmVudC5kZTwvYT4mZ3Q7PGJyPg0KJmd0 OyB3cm90ZTo8YnI+DQomZ3Q7IEhlbGxvIEJpbGwsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgYWxz byBkb24ndCByZWFseSB1bmRlcnN0YW5kIHdoeSB5b3UgbmVlZCB0aGlzIGFjdGlvbi48YnI+DQom Z3Q7IEZvciB5b3UgdHdvIGV4YW1wbGVzOjxicj4NCiZndDsgPGJyPg0KJmd0OyBTdXNwZW5kVXNl cjogd291bGQgYmUgbGlrZSBhY3RpdmUgPSBmYWxzZTxicj4NCiZndDsgRGVsZXRlTWFpbGJveDog VGhlIHNjaW0gdXNlciBoYXMgbm8gbWFpbGJveCBzbyB3aGF0IHNob3VsZCB0aGUgc3lzdGVtPGJy Pg0KJmd0OyBkbz8gRm9yIG15IHVuZGVyc3RhbmRpbmcgYSBtYWlsYm94IGxpa2Ugc29tZXRoaW5n IGNvdWxkIG9ubHkgYmUgYSBwYXJ0PGJyPg0KJmd0OyBvZiBhbiBleHRlbnNpb24gYnV0IG5vdCBv ZiB0aGUgc3RhbmRhcmQgdXNlci4gU28gaXQgbG9va3MgbGlrZSB0aGF0IHRoZTxicj4NCiZndDsg bWV0YS5hY3Rpb24gd291bGQgYmUgdmVyeSBjbGllbnQgc3BlY2lmaWMuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgYnkgRGF2aWQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgQW0gMjUuMDMu MjAxNCAwNToxNywgc2NocmllYiBCaWxsIE1pbGxzOjxicj4NCiZndDsmZ3Q7IFRoZSBwcm9ibGVt IGlzIHRoYXQgaW4gYSBQQVRDSCBvciBQVVQgYW55IGFjdGlvbiB0byBiZSB0YWtlbiBvbiB0aGU8 YnI+DQomZ3Q7Jmd0OyBhY2NvdW50IGhhcyB0byBiZSBpbmZlcnJlZCBmcm9tIHRoZSBkYXRhIGNo YW5nZXMuJm5ic3A7IFRoaXMgYWxzbyBtZWFucyB0aGF0PGJyPg0KJmd0OyZndDsgZXZlcnlvbmUg aGFzIHRvIHNoYXJlIHRoZSBlbnRpcmUgc2NoZW1hIGZvciBob3cgYW4gYWNvdW50IGlzIG1hbmFn ZWQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBXZSBoYXZlIGEgc3lzdGVtIHRoYXQgbG9v a3MgdmVyeSBtdWNoIGxpa2UgU0NJTSAobm90IGEgc3VwcmlzZSBzaW5jZTxicj4NCiZndDsmZ3Q7 IFNDSU0gaXMgc3RhbmRhcmRpemluZyBhIGNvbW1vbiB0YXNrKSBidXQgd2UgaGF2ZSBhY3Rpb24g dmVyYnMgd2l0aCBkYXRhLjxicj4NCiZndDsmZ3Q7Jm5ic3A7IENvbXBhcmluZyB0aGUgdHdvIEkg bXVjaCBwcmVmZXIgdGhlIGFjdGlvbiB2ZXJiIHdpdGggc3VwcG9ydGluZyBkYXRhPGJyPg0KJmd0 OyZndDsgbW9kZWwuJm5ic3A7IEluIHRoZSBjdXJyZW50IFNDSU0gbW9kZWwgYWN0aW9ucyBoYXZl IHRvIGJlIGluZmVycmVkIGZyb20gZGF0YTxicj4NCiZndDsmZ3Q7IGNoYW5nZXMuPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBGb3IgZXhhbXBsZSB3ZSBtaWdodCBoYXZlIGEgJnF1b3Q7Y3Jl YXRlX21haWxib3gmcXVvdDsgdmVyYiwgd2hlcmUgaW4gU0NJTSBJIG5lZWQ8YnI+DQomZ3Q7Jmd0 OyB0byBjb21wYXJlIHRoZSBjdXJyZW50IHN0YXRlIHRvIHRoZSBuZXcgc3RhdGUgYW5kIGR0ZXJt aW5lIHRoYXQ8YnI+DQomZ3Q7Jmd0OyAmcXVvdDttYWlsYm94X2FjdGl2ZSZxdW90OyBjaGFuZ2Vk IGZyb20gJnF1b3Q7MCZxdW90OyB0byAmcXVvdDsxJnF1b3Q7LiA8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IC1iaWxsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IE9uIE1vbmRheSwgTWFyY2ggMjQsIDIwMTQgODoyMCBQTSwgTW9ydGV6YSBBbnNhcmkgKG1vcmFu c2FyKTxicj4NCiZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW9yYW5zYXJAY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+bW9yYW5zYXJAY2lzY28uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzptb3JhbnNhckBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tb3JhbnNhckBj aXNjby5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgQmlsbCw8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IENhbiB5b3UgZXhwYW5kIG9uIHRoZSBwcm9ibGVtIHRoaXMgd291 bGQgc29sdmU/Jm5ic3A7IEkga25vdyB0aGlzIGNhbWUgdXAgb248YnI+DQomZ3Q7Jmd0OyBvbmUg b2YgdGhlIGNhbGxzIGEgd2hpbGUgYWdvIGJ1dCBJIGRvbuKAmXQgdGhpbmsgdGhlIHByb2JsZW0g aXMgY2xlYXJseTxicj4NCiZndDsmZ3Q7IGNhcHR1cmVkIG9uIHRoZSBtYWlsaW5nIGxpc3QgYmVm b3JlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBDaGVlcnMsPGJy Pg0KJmd0OyZndDsgTW9ydGV6YTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRnJvbTogQmls bCBNaWxscyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb20iIHRhcmdl dD0iX2JsYW5rIj53bWlsbHNfOTIxMDVAeWFob28uY29tPC9hPjxicj4NCiZndDsgJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PndtaWxsc185MjEwNUB5YWhvby5jb208L2E+Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzp3bWlsbHNfOTIxMDVAeWFob28uY29tIiB0YXJnZXQ9Il9ibGFuayI+d21pbGxzXzkyMTA1QHlh aG9vLmNvbTwvYT48YnI+DQomZ3Q7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOndtaWxsc185 MjEwNUB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj53bWlsbHNfOTIxMDVAeWFob28uY29tPC9h PiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFJlcGx5LVRvOiBCaWxsIE1pbGxzICZsdDs8YSBo cmVmPSJtYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndtaWxs c185MjEwNUB5YWhvby5jb208L2E+PGJyPg0KJmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzp3bWlsbHNfOTIxMDVAeWFob28uY29tIiB0YXJnZXQ9Il9ibGFuayI+d21pbGxzXzkyMTA1QHlh aG9vLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 d21pbGxzXzkyMTA1QHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndtaWxsc185MjEwNUB5YWhv by5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5j b20iIHRhcmdldD0iX2JsYW5rIj53bWlsbHNfOTIxMDVAeWFob28uY29tPC9hPiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IERhdGU6IE1vbmRheSwgTWFyY2ggMjQsIDIwMTQgYXQgMzoxOSBQTTxi cj4NCiZndDsmZ3Q7IFRvOiAmcXVvdDs8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv OnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltQGlldGYub3JnPC9hPiZndDsgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNj aW1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzY2lt QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2lt QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1A aWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5zY2ltQGlldGYub3JnPC9hPiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IFN1YmplY3Q6IFtzY2ltXSBtZXRhZGF0YSBhbmQgYWN0aW9uczxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJnF1b3Q7bWV0YSZxdW90OyBpcyB1c2VkIHRvIHJldHVybiBtZXRhZGF0YSBhYm91 dCBlbnRyaWVzIGFuZCBpbiB0aGUgY2FzZSBvZiBQQVRDSDxicj4NCiZndDsmZ3Q7IGl0J3MgdXNl ZCB0byBzcGVjaWZ5IGVsZW1lbnRzIHRvIGRlbGV0ZS4mbmJzcDsgSSdkIGxpa2UgdG8gcHJvcG9z ZSBhIG5ldzxicj4NCiZndDsmZ3Q7ICZxdW90O21ldGEmcXVvdDsgZWxlbWVudCBmb3IgYWN0aW9u IHRvIGJlIHRha2VuLiZuYnNwOyBJIHRoaW5rIHRoaXMgd291bGQgc29sdmUgc29tZSBvZjxicj4N CiZndDsmZ3Q7IHRoZSBxdWVzdGlvbiBvZiB0cmlnZ2VyaW5nIGFjdGlvbnMgYmFzZWQgb24gYSBQ QVRDSC4mbmJzcDsgU28gZm9yIGV4YW1wbGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm cXVvdDttZXRhJnF1b3Q7OiB7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZxdW90O2FjdGlv biZxdW90OzogWyZxdW90O1N1c3BlbmRVc2VyJnF1b3Q7LCAmcXVvdDtEZWxldGVNYWlsYm94JnF1 b3Q7XTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgfTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBTcGVjaWZpZXMgMiBhY3Rpb25zIHRvIGJlIHRha2VuIGFsb25n IHdpdGggd2hhdGV2ZXIgZGF0YSBjaGFuZ2VzIGFyZTxicj4NCiZndDsmZ3Q7IGFwcGxpZWQuPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBEb2VzIHRoaXMgc291bmQgd29ya2FibGU/PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtYmlsbDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 Jmd0OyBzY2ltIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzY2lt QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5v cmc8L2E+Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZsdDttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltQGlldGYub3JnPC9h PiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zY2ltIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBzY2ltIG1haWxpbmcg bGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2Np bUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZn dDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Np bSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2NpbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJ5aXYwNDg3ODMyNDQ3eXF0 ZmQ5MzU1MCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyBzY2ltIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFp bHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltQGlldGYub3JnPC9hPiAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2Np bUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0Kc2NpbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CnNjaW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5zY2ltQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJ5cXQ4MjU4NiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnNjaW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5v cmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zY2ltIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_f69735c44a0842f2ab982deee3ac10d3BN1PR04MB392namprd04pro_-- From nobody Thu Mar 27 07:33:09 2014 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 8C8B51A06C1 for ; Thu, 27 Mar 2014 07:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 62oCStUa2Jje for ; Thu, 27 Mar 2014 07:33:04 -0700 (PDT) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id BE1831A06E8 for ; Thu, 27 Mar 2014 07:33:03 -0700 (PDT) Received: from [98.139.212.152] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2014 14:33:01 -0000 Received: from [98.139.212.219] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2014 14:33:01 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 27 Mar 2014 14:33:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 706137.64809.bm@omp1028.mail.bf1.yahoo.com Received: (qmail 78846 invoked by uid 60001); 27 Mar 2014 14:33:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395930781; bh=pattOouTxX4fFthQDm3xpQyEp0jAuy2BHdd6GrUqQhA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=05KDuCoaZpT27d/ZXvvLsv556K47bcnwo+eTmzZh/cVUsa+ahcI19fjeZBV8wi8zZr1uCx6cgMkq0IQoRyXRuPEIiEODJGImklvWF2JBvFbIKwHEsirgGf+LwZmFOFUodT799lcXkESZ860dU5H6t7i14bD1IyRsXJGx8Uj5eH8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BNN39wkltbWV2/rB5bkYUEK/cKiWNJxMnIgbj/4sgg8v8FYZbUpwRKwWYDOws3UXTyxF1maYMKu6KJsvk0HEp2N+dU1lxQz90cS0EvUJjmAollRsKCuL02KidjOGVt6hfSDRLiIGvg1kgbewf6mdNDfHMZ21Nfx0VJmoPhQ8OZs=; X-YMail-OSG: vDFxa.8VM1kJ76gr346xa6VVkUvy.hmKIa6VmouLDyQicpw g74YBUikBodWqJnykIfvaaPLsZvCrmTkVvcWn9V2aH2pfET3cDF8DXyR6rUj UGcU1HRQxFFPu_KCw8BXxXDfXGUiqxroQG_ieCPbjq2xkflWSWPS6D1EC78m ZlhE0dSzuCf1wBYRkPYrVgGr0gfy6CPCRs9c3RVo23I2Je4f20iB1_Ow83hs mrItZg1fI2k3pF3wTS6JLVRlt2H27VjLwI.1Mo6HcBaDx5ts.We8y0WASHg6 UL2jysIgiDEwLxh4KYQgS1rYELT_kwPNWAKoHBGYbaUQmcTl1sN5hvnFblbe ET5fmKbbmWCw9S2hy55Xxw6Pr64i0WSqP4qLHWPC.O9OakvzkFETdtEkq0fL P_ctaxn6bw_cWcjkk_KHdqB6q6S7r22DLbhVLtr.h2VsjnCxkA4mIaGFl1pl N_VqzsZ2k2vC1WlKk8N4HaG8EwyE4s.GS8bKyIA6CipgYqmk4r1QtzHZwyIc blLPY4aOdyTZ4HrBYeYkaDDkNuSL8mRcMvLrkaai7mQ9RB8ve7RXbBA-- Received: from [99.31.212.42] by web142801.mail.bf1.yahoo.com via HTTP; Thu, 27 Mar 2014 07:33:01 PDT X-Rocket-MIMEInfo: 002.001, SSBoYWRuJ3QgdGhvdWdodCBhYm91dCBXcml0ZU9ubHkgdGhhdCB3YXksIGl0IHdvdWxkIHdvcmsgZmluZS4KCgoKT24gVGh1cnNkYXksIE1hcmNoIDI3LCAyMDE0IDY6MzggQU0sIEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbT4gd3JvdGU6CiAKSSBoYXZlIHNlZW4gUkVTVCBBUElzIGFkZCBmdW5jdGlvbnMgaW4gYSBudW1iZXIgb2Ygd2F5cyAoYWx0aG91Z2gg4oCmIHRlY2huaWNhbGx5IG5vdCBhbGwgUkVTVC1mdWxseSkuwqAgSGVyZSBhcmUgdGhlIGZldyB0aGF0IEkgaGF2ZSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.182.648 References: <1395699572.32920.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1395721026.16897.YahooMailNeo@web142806.mail.bf1.yahoo.com> <53311CB8.40007@tarent.de> <1395758559.2114.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53319786.30506@tarent.de> <1395762868.98394.YahooMailNeo@web142806.mail.bf1.yahoo.com> <1F458548-58CD-4BC3-8024-1752DED636A8@oracle.com> <1395811008.57103.YahooMailNeo@web142803.mail.bf1.yahoo.com> Message-ID: <1395930781.41732.YahooMailNeo@web142801.mail.bf1.yahoo.com> Date: Thu, 27 Mar 2014 07:33:01 -0700 (PDT) From: Bill Mills To: Kelly Grizzle , Phil Hunt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="469468616-859918099-1395930781=:41732" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/_WNSWKR_I76x1tEAuJgQv7TnLk8 Cc: =?utf-8?B?RGF2aWQgTcO2Yml1cw==?= , "scim@ietf.org" Subject: Re: [scim] metadata and actions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:33:07 -0000 --469468616-859918099-1395930781=:41732 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I hadn't thought about WriteOnly that way, it would work fine.=0A=0A=0A=0AO= n Thursday, March 27, 2014 6:38 AM, Kelly Grizzle wrote:=0A =0AI have seen REST APIs add functions in a number of ways (= although =E2=80=A6 technically not all REST-fully).=C2=A0 Here are the few = that I have seen listed from most to least common.=0A=C2=A0=0A1)=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 POST to a sub-resource to cause an action to occur.= =C2=A0 Example:=0APOST /Users/1234/deleteMailbox=0A=C2=A0=0A2)=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Include an action in the POST to the endpoint (this is y= our suggestion).=C2=A0 Example:=0APOST /Users/1234=0A{=0A=C2=A0 =E2=80=9Cme= ta=E2=80=9D: { =E2=80=9Caction=E2=80=9D: =E2=80=9CdeleteMailbox=E2=80=9D }= =0A}=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Similarly, this could be achi= eved by extending the schema and adding an action attribute.=C2=A0 Example:= =0A=C2=A0=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 POST /Users/1234=0A=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=0A=C2=A0=E2=80=9Curn:yahoo=E2=80=9D: {=0A= =C2=A0=C2=A0=C2=A0 =E2=80=9Caction=E2=80=9D: =E2=80=9CdeleteMailbox=E2=80= =9D,=0A=C2=A0 =C2=A0=C2=A0=E2=80=A6 some data that provides parameters for = the deleteMailbox command =E2=80=A6=0A=C2=A0 }=0A}=0A=C2=A0=0A3)=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Include a =E2=80=9Ccommand object=E2=80=9D in the POS= T body to the endpoint rather than a representation of the endpoint.=C2=A0 = This is similar to what the new PATCH proposal does, but is keyed off of a = special HTTP header or the Content-Type header.=C2=A0 Example:=0APOST /User= s/1234=0AContent-Type: application/yahoo.deleteMailbox+json=0A{=0A=C2=A0 = =E2=80=A6 some data that provides parameters for the deleteMailbox command = =E2=80=A6=0A}=0A=C2=A0=0A=C2=A0=0AThere are pros and cons to each approach.= =0A=C2=A0=0AThe first approach does not allow for deleting a mailbox while = updating other attributes on the user.=C2=A0 Also, SCIM doesn=E2=80=99t cur= rently have a good extension mechanism to define this =E2=80=A6 maybe throu= gh a ResourceType but this would be a stretch.=0A=C2=A0=0AUsing meta in the= second approach is easier to solve from an extensibility perspective, but = we would probably want a way for service providers to return which actions = they support (eg =E2=80=93 through the ResourceType endpoint).=0A=C2=A0=0AU= sing a normal schema extension in the second approach wouldn=E2=80=99t requ= ire any changes to the spec.=C2=A0 You would just add an =E2=80=9Caction=E2= =80=9D attribute to the extension and set the mutability to writeOnly.=C2= =A0 This has the added benefit that any data required by the action (eg =E2= =80=93 action =3D =E2=80=9CsetMailboxSize=E2=80=9D, newMailboxSize =3D 1000= 000) is defined in the same place.=0A=C2=A0=0AThe last approach is very unc= ommon and would be the largest change to the spec, so I=E2=80=99ll leave it= out.=C2=A0 Functionally, it is very similar to option 1.=0A=C2=A0=0A=C2=A0= =0ASCIM does have a couple of places where it would be nice to have actions= .=C2=A0 As you mentioned, changing the inactive flag is not always ideal (a= lthough this is probably the correct lowest common denominator across servi= ce providers).=C2=A0 Also, changing a password is another thing that we hav= e shoe-horned into an attribute (see ticket 14 for where this has fallen sh= ort - http://tools.ietf.org/wg/scim/trac/ticket/14).=C2=A0 The difficult th= ing with these is that you often need to do them in conjunction with anothe= r action =E2=80=93 such as setting the password when you create a user.=0A= =C2=A0=0AMy opinion is that we should just use extensions to define actions= (option 2b).=C2=A0 This provides a good amount of flexibility for mixing i= n actions with other operation (create and update), and we already have a f= acility for this through schema extension.=C2=A0 Essentially, this is just = moving the action from the meta attribute to an extension.=0A=C2=A0=0A--Kel= ly=0A=C2=A0=0AFrom:scim [mailto:scim-bounces@ietf.org] On Behalf Of Bill Mi= lls=0ASent: Wednesday, March 26, 2014 12:17 AM=0ATo: Phil Hunt=0ACc: David = M=C3=B6bius; scim@ietf.org=0ASubject: Re: [scim] metadata and actions=0A=C2= =A0=0AI agree, it's not REST-ful perhaps, but I also think REST is an 80% s= olution.=0A=C2=A0=0ADoes adding a "no-store" mutability variant make a bett= er solution?=0A=C2=A0=0AOn Tuesday, March 25, 2014 8:32 PM, Phil Hunt wrote:=0AIt seems like you are defining high-level "funct= ions" rather than simple stateful changes.=C2=A0=0A=C2=A0=0AI agree on the = need, but i think many will say this is not RESTful. =C2=A0=0A=0APhil=0A=0A= On Mar 25, 2014, at 8:54, Bill Mills wrote:=0A1) I= do not want to explicitly store the transactions, but I may log them in a = different field. =C2=A0A "no-store" mutability value could solve this too.= =0A>=C2=A0=0A>2) SCIM really needs this concept. =C2=A0Diffs of data to det= ermine what actions to take is not a great thing.=0A>=C2=A0=0A>On Tuesday, = March 25, 2014 7:49 AM, David M=C3=B6bius wrote:=0A>Y= ea that is sure but I think the meta attribute should only be for scim=0A>a= ttributes.=0A>=0A>I don't know how you implement your code but I think you = have your=0A>"mailbox" or what else in some kind of extension. In this case= you just=0A>could definde an additional field in your extension where you = store the=0A>actions.=0A>=0A>David=0A>=0A>Am 25.03.2014 15:42, schrieb Bill= Mills:=0A>> What I'm asking for is a defined extension to the "meta" eleme= nt, not=0A>>=C2=A0 "mailbox" element.=C2=A0 We'll define our own schema as = needed for the=0A>> things spefici to our provisioning environment.=C2=A0 S= CIM is about managing=0A>> users AND things asociated with them, so a mailb= ox is a reasonable=0A>> resource to be managing which is why I chose it as = an example.=0A>> =0A>> =0A>> On Monday, March 24, 2014 11:05 PM, David M=C3= =B6bius =0A>> wrote:=0A>> Hello Bill,=0A>> =0A>> I als= o don't realy understand why you need this action.=0A>> For you two example= s:=0A>> =0A>> SuspendUser: would be like active =3D false=0A>> DeleteMailbo= x: The scim user has no mailbox so what should the system=0A>> do? For my u= nderstanding a mailbox like something could only be a part=0A>> of an exten= sion but not of the standard user. So it looks like that the=0A>> meta.acti= on would be very client specific.=0A>> =0A>> =0A>> by David=0A>> =0A>> Am 2= 5.03.2014 05:17, schrieb Bill Mills:=0A>>> The problem is that in a PATCH o= r PUT any action to be taken on the=0A>>> account has to be inferred from t= he data changes.=C2=A0 This also means that=0A>>> everyone has to share the= entire schema for how an acount is managed.=0A>>>=0A>>> We have a system t= hat looks very much like SCIM (not a suprise since=0A>>> SCIM is standardiz= ing a common task) but we have action verbs with data.=0A>>>=C2=A0 Comparin= g the two I much prefer the action verb with supporting data=0A>>> model.= =C2=A0 In the current SCIM model actions have to be inferred from data=0A>>= > changes.=0A>>>=0A>>> For example we might have a "create_mailbox" verb, w= here in SCIM I need=0A>>> to compare the current state to the new state and= dtermine that=0A>>> "mailbox_active" changed from "0" to "1". =0A>>>=0A>>>= -bill=0A>>>=0A>>>=0A>>> On Monday, March 24, 2014 8:20 PM, Morteza Ansari = (moransar)=0A>>> > wrote:=0A= >>> Bill,=0A>>>=0A>>> Can you expand on the problem this would solve?=C2=A0= I know this came up on=0A>>> one of the calls a while ago but I don=E2=80= =99t think the problem is clearly=0A>>> captured on the mailing list before= .=0A>>>=0A>>>=0A>>> Cheers,=0A>>> Morteza=0A>>>=0A>>> From: Bill Mills > > >>=0A>>> Reply-To: Bill Mi= lls > =0A>>> >>=0A>>> Date: Mo= nday, March 24, 2014 at 3:19 PM=0A>>> To: "scim@ietf.org > >" =0A>>> >>=0A= >>> Subject: [scim] metadata and actions=0A>>>=0A>>> "meta" is used to retu= rn metadata about entries and in the case of PATCH=0A>>> it's used to speci= fy elements to delete.=C2=A0 I'd like to propose a new=0A>>> "meta" element= for action to be taken.=C2=A0 I think this would solve some of=0A>>> the q= uestion of triggering actions based on a PATCH.=C2=A0 So for example:=0A>>>= =0A>>> "meta": {=0A>>>=C2=A0 =C2=A0 "action": ["SuspendUser", "DeleteMailbo= x"]=0A>>>=0A>>> }=0A>>>=0A>>>=0A>>> Specifies 2 actions to be taken along w= ith whatever data changes are=0A>>> applied.=0A>>>=0A>>> Does this sound wo= rkable?=0A>>>=0A>>> -bill=0A>>>=0A>>> _____________________________________= __________=0A>>> scim mailing list=0A>>> scim@ietf.org > >=0A>>> https://www.iet= f.org/mailman/listinfo/scim=0A>>>=0A>>>=0A>>>=0A>>>=0A>>> _________________= ______________________________=0A>>> scim mailing list=0A>>> scim@ietf.org = =0A>>> https://www.ietf.org/mailman/listinfo/scim=0A>= =0A>> =0A>>>=0A>> =0A>> _______________________________________________=0A>= > scim mailing list=0A>> scim@ietf.org =0A>> https://= www.ietf.org/mailman/listinfo/scim=0A>> =0A>> =0A>=0A>_____________________= __________________________=0A>scim mailing list=0A>scim@ietf.org=0A>https:/= /www.ietf.org/mailman/listinfo/scim=0A>=C2=A0=0A___________________________= ____________________=0A>scim mailing list=0A>scim@ietf.org=0A>https://www.i= etf.org/mailman/listinfo/scim=0A=C2=A0=0A__________________________________= _____________=0Ascim mailing list=0Ascim@ietf.org=0Ahttps://www.ietf.org/ma= ilman/listinfo/scim=0A=C2=A0=0A=0A_________________________________________= ______=0Ascim mailing list=0Ascim@ietf.org=0Ahttps://www.ietf.org/mailman/l= istinfo/scim --469468616-859918099-1395930781=:41732 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I hadn't thought about WriteOnly that way, it woul= d work fine.


On Thursday, March 27, 2014 6:38 AM, Kelly Grizzle <ke= lly.grizzle@sailpoint.com> wrote:
I ha= ve seen REST APIs add functions in a number of ways (although =E2=80=A6 tech= nically not all REST-fully).  Here are the few that I have seen listed f= rom most to least common.
=20
&nb= sp;
=20
1)  &nb= sp;   POST to a sub-resourc= e to cause an action to occur.  Example:
=20
POST /Users/1234/deleteMailbox
=20
 
=20
2)  &nb= sp;   Include an action in t= he POST to the endpoint (this is your suggestion).  Example:=20
POST /Users/1234
=20
{
=20
  =E2=80=9Cmeta=E2=80=9D: { =E2=80=9Cact= ion=E2=80=9D: =E2=80=9CdeleteMailbox=E2=80=9D }
=20
}
=20
&nbs= p;            &n= bsp; 
=20
&nbs= p;            &n= bsp;  Similarly, this could be achieved by extending the schema and add= ing an action attribute.  Example:
=20
&nb= sp;
=20
&nbs= p;            &n= bsp;            =       POST /Users/1234
=20
&nbs= p;            &n= bsp;            =       {
=20
 =E2=80=9Curn:yahoo=E2=80=9D: {
=20=
    =E2=80=9Caction=E2=80=9D: =E2=80= =9CdeleteMailbox=E2=80=9D,
=20
    =E2=80=A6 some data that p= rovides parameters for the deleteMailbox command =E2=80=A6
=20
  }
=20
}
=20
 
=20
3)  &nb= sp;   Include a =E2=80=9Cco= mmand object=E2=80=9D in the POST body to the endpoint rather than a represe= ntation of the endpoint.  This is similar to what the new PATCH proposa= l does, but is keyed off of a special HTTP header or the Content-Type header.=   Example:
=20
POST /Users/1234
=20
Content-Type: application/yahoo.deleteMailbo= x+json
=20
{
=20
  =E2=80=A6 some data that provides par= ameters for the deleteMailbox command =E2=80=A6
=20
}
=20
 
=20
 
=20
There are pros and cons to each approach.
=20
 
=20
The first approach does not allow for deleting= a mailbox while updating other attributes on the user.  Also, SCIM doe= sn=E2=80=99t currently have a good extension mechanism to define this =E2=80=A6 maybe through a Re= sourceType but this would be a stretch.
=20
 
=20
Using meta in the second approach is easier to= solve from an extensibility perspective, but we would probably want a way f= or service providers to return which actions they support (eg =E2=80=93 throug= h the ResourceType endpoint).
=20
 
=20
Using a normal schema extension in the second a= pproach wouldn=E2=80=99t require any changes to the spec.  You would ju= st add an =E2=80=9Caction=E2=80=9D attribute to the extension and set the mutability to writeOnly.  This h= as the added benefit that any data required by the action (eg =E2=80=93 acti= on =3D =E2=80=9CsetMailboxSize=E2=80=9D, newMailboxSize =3D 1000000) is defi= ned in the same place.
=20
 
=20
The last approach is very uncommon and would b= e the largest change to the spec, so I=E2=80=99ll leave it out.  Functi= onally, it is very similar to option 1.
=20
 
=20
 
=20
SCIM does have a couple of places where it wou= ld be nice to have actions.  As you mentioned, changing the inactive fl= ag is not always ideal (although this is probably the correct lowest common denominat= or across service providers).  Also, changing a password is another thi= ng that we have shoe-horned into an attribute (see ticket 14 for where this h= as fallen short - http://tools.ietf.org/wg/scim/trac/ticket/14<= /a>).  The difficult thing with these is that you often need to do them= in conjunction with another action =E2=80=93 such as setting the password w= hen you create a user.
=20
 
=20
My opinion is that we should just use extensio= ns to define actions (option 2b).  This provides a good amount of flexi= bility for mixing in actions with other operation (create and update), and we already h= ave a facility for this through schema extension.  Essentially, this is= just moving the action from the meta attribute to an extension.=20
 
=20
--Kelly
=20
&nb= sp;
=20
=
From:= scim [mailto:scim-bounces@ietf.org] On Behalf Of Bill Mills
Sent: Wednesday, March 26, 2014 12:17 AM
To: Phil Hunt
Cc: David M=C3=B6bius; scim@ietf.org=
Subject: Re: [scim] metadata and actions
=20
 
=20
I agree, it's not REST-ful perhaps, but I also think REST is an 80% s= olution.
=20
 
=20=
Does adding a "no-sto= re" mutability variant make a better solution?
=20
 
=20
On Tuesday, March 25, 2014 8:32 PM, Phil Hunt <phil.hunt@oracle.com= > wrote:
=20
It seems like you are defining high-level "functions" rather than sim= ple stateful changes. 
=20
 
=20
I agree on the need, but i think many will say this is not RESTful. &= nbsp;
=20

Phil
=20

On Mar 25, 2014, at 8:54, Bill Mills <wmills_92105@yahoo.com> wrote:
=20
1) I do not want to explicitly store the transactions, but I may log t= hem in a different field.  A "no-store" mutability value could solve th= is too.
=20
 
=20
2) SCIM really needs t= his concept.  Diffs of data to determine what actions to take is not a g= reat thing.
=20
 
=20
On Tuesday, March 25, 2014 7:49 AM, David M=C3=B6biu= s <d.moebius@tarent.d= e> wrote:
=20
Yea that is sure but I think the meta attribute should only be for sc= im
attributes.

I don't know how you implement your code but I think you have your
"mailbox" or what else in some kind of extension. In this case you just
could definde an additional field in your extension where you store the
actions.

David

Am 25.03.2014 15:42, schrieb Bill Mills:
> What I'm asking for is a defined extension to the "meta" element, not >  "mailbox" element.  We'll define our own schema as needed fo= r the
> things spefici to our provisioning environment.  SCIM is about man= aging
> users AND things asociated with them, so a mailbox is a reasonable
> resource to be managing which is why I chose it as an example.
>
>
> On Monday, March 24, 2014 11:05 PM, David M=C3=B6bius <d.moebius@tarent.de>
> wrote:
> Hello Bill,
>
> I also don't realy understand why you need this action.
> For you two examples:
>
> SuspendUser: would be like active =3D false
> DeleteMailbox: The scim user has no mailbox so what should the system > do? For my understanding a mailbox like something could only be a part<= br clear=3D"none"> > of an extension but not of the standard user. So it looks like that the=
> meta.action would be very client specific.
>
>
> by David
>
> Am 25.03.2014 05:17, schrieb Bill Mills:
>> The problem is that in a PATCH or PUT any action to be taken on the=
>> account has to be inferred from the data changes.  This also m= eans that
>> everyone has to share the entire schema for how an acount is manage= d.
>>
>> We have a system that looks very much like SCIM (not a suprise sinc= e
>> SCIM is standardizing a common task) but we have action verbs with d= ata.
>>  Comparing the two I much prefer the action verb with supporti= ng data
>> model.  In the current SCIM model actions have to be inferred f= rom data
>> changes.
>>
>> For example we might have a "create_mailbox" verb, where in SCIM I n= eed
>> to compare the current state to the new state and dtermine that
>> "mailbox_active" changed from "0" to "1".
>>
>> -bill
>>
>>
>> On Monday, March 24, 2014 8:20 PM, Morteza Ansari (moransar)
>> <moransar@cisc= o.com <mailto:moran= sar@cisco.com>> wrote:
>> Bill,
>>
>> Can you expand on the problem this would solve?  I know this c= ame up on
>> one of the calls a while ago but I don=E2=80=99t think the problem i= s clearly
>> captured on the mailing list before.
>>
>>
>> Cheers,
>> Morteza
>>
>> From: Bill Mills <wmills_92105@yahoo.com
> <mailto:wm= ills_92105@yahoo.com> <mailto:wmills_92105@yahoo.com
> <mailto:wm= ills_92105@yahoo.com>>>
>> Reply-To: Bill Mills <wmills_92105@yahoo.com
> <mailto:wm= ills_92105@yahoo.com>
>> <mailto:wmills_92105@yahoo.com <mailto:wmills_92105@yahoo.com>>>
>> Date: Monday, March 24, 2014 at 3:19 PM
>> To: "scim@ietf.org <= mailto:scim@ietf.org> <mai= lto:scim@ietf.org
> <mailto:scim@ietf.org>= ;>" <scim@ietf.org <mai= lto:scim@ietf.org>
>> <mailto:scim@ietf.org <mailto:scim@ietf.org>&g= t;>
>> Subject: [scim] metadata and actions
>>
>> "meta" is used to return metadata about entries and in the case of P= ATCH
>> it's used to specify elements to delete.  I'd like to propose a= new
>> "meta" element for action to be taken.  I think this would sol= ve some of
>> the question of triggering actions based on a PATCH.  So for e= xample:
>>
>> "meta": {
>>    "action": ["SuspendUser", "DeleteMailbox"]
>>
>> }
>>
>>
>> Specifies 2 actions to be taken along with whatever data changes ar= e
>> applied.
>>
>> Does this sound workable?
>>
>> -bill
>>
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org <mailt= o:scim@ietf.org> <mailto:<= a rel=3D"nofollow" shape=3D"rect" ymailto=3D"mailto:scim@ietf.org" target=3D= "_blank" href=3D"mailto:scim@ietf.org">scim@ietf.org
> <mailto:scim@ietf.org>= ;>
>> https://www.ietf.org/mailman/listinfo/= scim
>>
>>
>>
>>
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org <mailt= o:scim@ietf.org>
>> https://www.ietf.org/mailman/listinfo/= scim
=20

>
>>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org <mailto:scim@ietf.org>
> https://www.ietf.org/mailman/listinfo/scim=
>
>

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim<= /span>
=20
 
=20
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim<= /span>
=20
 
=20
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim<= /span>
=20
 
=20

_______________= ________________________________
scim mailing list
scim@ietf.org
https://www.i= etf.org/mailman/listinfo/scim


= _______________________________________________
scim m= ailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim
= --Apple-Mail-773CA959-E80C-43BD-AE0E-CFC024F1AFE8-- From nobody Fri Mar 28 12:01:12 2014 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 AAE581A0966 for ; Fri, 28 Mar 2014 12:01:10 -0700 (PDT) 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 RihHzOrqCn7t for ; Fri, 28 Mar 2014 12:01:08 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 435371A094E for ; Fri, 28 Mar 2014 12:00:59 -0700 (PDT) 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 s2SJ0uZt019372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Mar 2014 19:00:56 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s2SJ0tVJ027715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Mar 2014 19:00:56 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2SJ0tr5026118 for ; Fri, 28 Mar 2014 19:00:55 GMT Received: from [192.168.1.186] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Mar 2014 12:00:55 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_88E9B40D-6994-42F9-9777-15650061E759" Message-Id: Date: Fri, 28 Mar 2014 12:00:53 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/CELeHbuW1M9ZljLxdHegsgAxwds Subject: [scim] SCIM PATCH Survey 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: Fri, 28 Mar 2014 19:01:10 -0000 --Apple-Mail=_88E9B40D-6994-42F9-9777-15650061E759 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm looking for feedback on where to focus efforts on the next SCIM = PATCH (Ticket 18). Since there was a lot of discussion and a bunch of = different possibilities put forward, I have put together a Survey Monkey = questionnaire to get your rankings on each of the proposals so far and = to allow for new proposals. For each scenario, indicate whether you find the solution preferred, = acceptable, neutral, or unacceptable. You should mark at least one = scenario as "preferred". Survey link: https://www.surveymonkey.com/s/ZFY5GKV If possible, please complete the survey by 8AM Pacific on April 2. I = will present a quick summary at the SCIM WG call that same day. Notes:=20 A. I am asking for contact emails so I can follow up to clarify any = responses. I will not use your name when the results are published. B. Bill Mills recently raised the issue of "action" patches. I would = prefer to deal with this as a separate issue for now. C. If you have any questions about the survey, just reply to this email. You may find the following links useful: * Current SCIM Patch - = http://tools.ietf.org/html/draft-ietf-scim-api-03#section-3.3.2 * IETF89 patch proposal - = https://tools.ietf.org/agenda/89/slides/slides-89-scim-2.pdf * JSON Merge Patch - = https://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch * JSON Patch RFC 6902 - https://tools.ietf.org/html/rfc6902 Thanks for your input! Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_88E9B40D-6994-42F9-9777-15650061E759 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I'm = looking for feedback on where to focus efforts on the next SCIM PATCH = (Ticket 18).  Since there was a lot of discussion and a bunch of = different possibilities put forward, I have put together a Survey = Monkey questionnaire to get your rankings on each of the proposals so = far and to allow for new proposals.

For each = scenario, indicate whether you find the solution preferred, acceptable, = neutral, or unacceptable. You should mark at least one scenario as = "preferred".


If possible, please complete = the survey by 8AM Pacific on April 2. I will present a quick summary at = the SCIM WG call that same = day.

Notes: 
A. I am asking for = contact emails so I can follow up to clarify any responses. I will not = use your name when the results are published.
B. Bill Mills = recently raised the issue of "action" patches. I would prefer to deal = with this as a separate issue for now.
C. If you have any = questions about the survey, just reply to this = email.

You may find the following links = useful:

* IETF89 patch proposal - http= s://tools.ietf.org/agenda/89/slides/slides-89-scim-2.pdf
* JSON Patch RFC 6902 - https://tools.ietf.org/html/r= fc6902

Thanks for your = input!
= --Apple-Mail=_88E9B40D-6994-42F9-9777-15650061E759--