From nobody Tue Apr 1 09:32: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 EAEC51A09A7 for ; Tue, 1 Apr 2014 09:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 e8mkYqrGLd52 for ; Tue, 1 Apr 2014 09:32:10 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E20E61A0505 for ; Tue, 1 Apr 2014 09:32: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 s31GW5U1031558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Apr 2014 16:32:06 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s31GW4Tt013179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 1 Apr 2014 16:32:05 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s31GW45S008697 for ; Tue, 1 Apr 2014 16:32:04 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Apr 2014 09:32:03 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_1F02688A-8C3A-4802-AE6E-E0E64A624B27" Message-Id: <55143D32-640C-4EB4-B80B-538C518FFD6C@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Date: Tue, 1 Apr 2014 09:32:01 -0700 References: To: "scim@ietf.org WG" In-Reply-To: X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/RF1U41AEc1fkF9-rNOZd2P_fN8k Subject: Re: [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: Tue, 01 Apr 2014 16:32:12 -0000 --Apple-Mail=_1F02688A-8C3A-4802-AE6E-E0E64A624B27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Reminder=85 If you have not already done so, please fill out the survey below. Your = input is requested to guide the editorial effort on SCIM PATCH. Please respond by 8AM tomorrow. Thanks! Phil @independentid www.independentid.com phil.hunt@oracle.com On Mar 28, 2014, at 12:00 PM, Phil Hunt wrote: > 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. >=20 > For each scenario, indicate whether you find the solution preferred, = acceptable, neutral, or unacceptable. You should mark at least one = scenario as "preferred". >=20 > Survey link: https://www.surveymonkey.com/s/ZFY5GKV >=20 > 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. >=20 > 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. >=20 > You may find the following links useful: >=20 > * 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 >=20 > Thanks for your input! >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_1F02688A-8C3A-4802-AE6E-E0E64A624B27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Reminder=85

If you have not = already done so, please fill out the survey below. Your input is = requested to guide the editorial effort on SCIM = PATCH.

Please respond by 8AM = tomorrow.

Thanks!


On Mar 28, 2014, at 12:00 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:

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!

www.independentid.com
phil.hunt@oracle.com
=
=
______________________________________________= _
scim mailing list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_1F02688A-8C3A-4802-AE6E-E0E64A624B27-- From nobody Tue Apr 1 14:58: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 F38221A0A1C for ; Tue, 1 Apr 2014 14:58: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 CAfPcFcnKJkp for ; Tue, 1 Apr 2014 14:58:41 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 426151A0A0E for ; Tue, 1 Apr 2014 14:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15048; q=dns/txt; s=iport; t=1396389517; x=1397599117; h=from:to:subject:date:message-id:mime-version; bh=G4FNAMHOddP9QfVMt6GyP7tZAumUFXY6vZCpg2s0aEU=; b=NH8a9CfOd1fhaglVMQqlRhlfBTWH1wICeILGt0CVLjfZds8aCYAs9mV4 52ISzmFkB/nRyWBkw+WajY3rEZlzb/0hOGC32YbaicP0RbRyZTofcnAOR CWnzsODpCMhTfUtlXC3+OE9EO/8Qj8SfN8UizVQUEBsMLmG4vVDdB5I31 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFALY1O1OtJV2c/2dsb2JhbAA+FwOCQkQ7V7wghzWBHhZ0gioCVRMjAQ8NGAQMPCQDAQOIDA02nguTRZ5GF4xygTozAQwcB4IWggoEmFaSOYJdU4Ir X-IronPort-AV: E=Sophos; i="4.97,775,1389744000"; d="scan'208,217"; a="32107208" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 01 Apr 2014 21:58:37 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s31LwZbr032503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 1 Apr 2014 21:58:36 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.10]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 16:58:35 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: Reminder - SCIM WG call tomorrow @11AM Pacific Thread-Index: AQHPTfWGxfvGFpRSqUK1UX8Low8/CQ== Date: Tue, 1 Apr 2014 21:58:34 +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.124.88] Content-Type: multipart/alternative; boundary="_000_CF608498D4782moransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/2hTNP8ejIhYYtFBvrjYdhUQQ-QI Subject: [scim] Reminder - SCIM WG call tomorrow @11AM Pacific 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, 01 Apr 2014 21:58:44 -0000 --_000_CF608498D4782moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just a reminder that we have the WG biweekly call tomorrow, Wed. April 2nd = at 11AM pacific time. We will discuss the open tracker issues and more spec= ifically issue #18. Cheers, Morteza =97 ------------------------------------------------------- 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_CF608498D4782moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <67A0518530D1F242BB5988E826F18573@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Just a reminder th= at we have the WG biweekly call tomorrow, Wed. April 2nd at 11AM pacific ti= me. We will discuss the open tracker issues and more specifically issue #18= .


Cheers,
Morteza
=97
= ------------------------------------------------------- 
Meeting information 
-------------------------------------------------------&n= bsp;
Topic: SCIM WG bi-weekly call 
Date: Every 2 weeks on Wednesday, from Wednesday, March 1= 9, 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 passwo= rd.) 

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

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

Access code:385 408 774 

-------------------------------------------------------&n= bsp;
For assistance 
-------------------------------------------------------&n= bsp;
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=3D= m92f0520f46fac9644ab9358042b273d0 

To check whether you have the appropriate players install= ed for UCF (Universal Communications Format) rich media files, go to <= /span>h= ttps://go.webex.com/go/systemdiagnosis.php. 

http://www.= webex.com 

CCM:+14156550000x385408774# 

IMPORTANT NOTICE: This WebEx service includes a feature t= hat 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_CF608498D4782moransarciscocom_-- From nobody Wed Apr 2 13:55: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 9846A1A03E4; Wed, 2 Apr 2014 13:55:12 -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 TNE3dlqumUpx; Wed, 2 Apr 2014 13:55:08 -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 560151A039C; Wed, 2 Apr 2014 13:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5111; q=dns/txt; s=iport; t=1396472100; x=1397681700; h=from:to:subject:date:message-id:mime-version; bh=MSVLt/yo1BgAbz7u7hZLxhrGHs7+uL3pCA75etUhH6A=; b=LGDjalMd2BrN6OkntXgUEI0/ySmQ/Vhx4gKpu05fnbUeOz9mJytavRQr zIUVcqWKZZRqfMUkQk6T6kJwVFbedECvB58GRfV75W25q5fQeVqQsfpvf ezIBGIfJvfbfKhv+YSjiPexOdxFmZA6rSQ4AzVXWsrTZkakjYZreAJHRF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFADV4PFOtJV2a/2dsb2JhbAA/GoJCRDtXw2aBIxZ0giwebQGBACcEAS2HXg02znMTBI5shEMEiSCPOJI5gzCCKw X-IronPort-AV: E=Sophos; i="4.97,782,1389744000"; d="scan'208,217"; a="32400273" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 02 Apr 2014 20:55:00 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s32Kt05j028100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 20:55:00 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.10]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Wed, 2 Apr 2014 15:55:00 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" , "proceedings@ietf.org" Thread-Topic: Meeting notes from SCIM WG conical 2014-04-02 Thread-Index: AQHPTrXPIjvDLPUJUUmdRtiiOhE+zQ== Date: Wed, 2 Apr 2014 20:54:59 +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.150.245] Content-Type: multipart/alternative; boundary="_000_CF61C732D4B1Amoransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/BWuXC-EWk5J9Dl6j8YUeIrXfumA Subject: [scim] Meeting notes from SCIM WG conical 2014-04-02 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, 02 Apr 2014 20:55:13 -0000 --_000_CF61C732D4B1Amoransarciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Present: * Kelly Grizzle (note taker) * Erik Wahlstr=F6m * Morteza Ansari * Phil Hunt * Bill Mills * Melvin Laguren Notes: Phil presented results from PATCH poll. -Poll shows most leaning towards a 6902-based solution. Kelly and Morteza (speaking as an implementor) raised concerns about a new = PATCH proposal that primarily increases readibility. This will be a non-ba= ckwards-compatible breaking change for not much benefit. Chairs will present 3 options to list for consensus - 6902-compliant, 6902-= based, or Draft 3. Some discussion around localization, Phil will dig in deeper to see if ther= e are any inconsistencies and bring any issues he finds to the WG. --- Meeting recording: Your recording is now available on the WebEx service site. Click the link b= elow to play it: https://go.webex.com/go/lsr.php?RCID=3D7f2d0f8bdfcd435ebd34aa4c0071130b SCIM WG bi-weekly call-20140402 1806-1 Wednesday, April 2, 2014 11:06 am San Francisco Time 52 Minutes --_000_CF61C732D4B1Amoransarciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <353BD1A112E38540873F4CE9BFBEE0A9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Present:
* Kelly Grizzle (no= te taker)
* Erik Wahlstr=F6m<= /div>
* Morteza Ansari
* Phil Hunt
* Bill Mills
Your recording is now available on the WebEx service= site. Click the link below to play it: 

https://go.webex.com/go/lsr.php?RCID= =3D7f2d0f8bdfcd435ebd34aa4c0071130b 

SCIM WG bi-weekly call-20140402 1806-1 
Wednesday, April 2, 2014 11:06 am San Francisco Time = ;
52 Minutes 
--_000_CF61C732D4B1Amoransarciscocom_-- From nobody Wed Apr 2 15:43:24 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 071D61A03F3; Wed, 2 Apr 2014 15:43:22 -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 i5GEROnzRFMM; Wed, 2 Apr 2014 15:43:17 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id AC3FA1A039C; Wed, 2 Apr 2014 15:43:17 -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 s32MhBhZ003109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Apr 2014 22:43:12 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s32MhAQn016248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2014 22:43:11 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s32MhA3X001396; Wed, 2 Apr 2014 22:43:10 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Apr 2014 15:43:10 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_F742C091-882C-44C9-8B2A-AD1972F0CDB3" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: Date: Wed, 2 Apr 2014 15:43:08 -0700 Message-Id: <9046BF71-3EA7-446C-A8D7-2551BBB9D9CD@oracle.com> References: To: Morteza Ansari X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ycNKPvD2frMLT24qt0NSbXNK_zU Cc: "scim@ietf.org" , "proceedings@ietf.org" Subject: Re: [scim] Meeting notes from SCIM WG conical 2014-04-02 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, 02 Apr 2014 22:43:22 -0000 --Apple-Mail=_F742C091-882C-44C9-8B2A-AD1972F0CDB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I think the discussion was the significant benefit with 6902 Based PATCH = (other than readability) is it allows for specific sub-value updates = that is not possible with the existing patch method. The feeling was the = readability plus this feature outweighed concerns about backwards = compatibility. Or did I hear it wrong? Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 2, 2014, at 1:54 PM, Morteza Ansari (moransar) = wrote: > Present: > * Kelly Grizzle (note taker) > * Erik Wahlstr=F6m > * Morteza Ansari > * Phil Hunt > * Bill Mills > * Melvin Laguren >=20 > Notes: > Phil presented results from PATCH poll. > -Poll shows most leaning towards a 6902-based solution. > Kelly and Morteza (speaking as an implementor) raised concerns about a = new PATCH proposal that primarily increases readibility. This will be a = non-backwards-compatible breaking change for not much benefit. > Chairs will present 3 options to list for consensus - 6902-compliant, = 6902-based, or Draft 3. > Some discussion around localization, Phil will dig in deeper to see if = there are any inconsistencies and bring any issues he finds to the WG. >=20 > --- > Meeting recording: >=20 > Your recording is now available on the WebEx service site. Click the = link below to play it:=20 >=20 > https://go.webex.com/go/lsr.php?RCID=3D7f2d0f8bdfcd435ebd34aa4c0071130b=20= >=20 > SCIM WG bi-weekly call-20140402 1806-1=20 > Wednesday, April 2, 2014 11:06 am San Francisco Time=20 > 52 Minutes=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_F742C091-882C-44C9-8B2A-AD1972F0CDB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = think the discussion was the significant benefit with 6902 Based PATCH = (other than readability) is it allows for specific sub-value updates = that is not possible with the existing patch method. The feeling was the = readability plus this feature outweighed concerns about backwards = compatibility.

Or did I hear it = wrong?


On Apr 2, 2014, at 1:54 PM, Morteza Ansari (moransar) = <moransar@cisco.com> = wrote:

Present:
* Kelly Grizzle = (note taker)
* Erik = Wahlstr=F6m
* Morteza = Ansari
* Phil Hunt
* Bill Mills
* Melvin = Laguren

Notes:
Phil presented results from PATCH poll.
-Poll shows most leaning towards a 6902-based solution.
Kelly and Morteza (speaking as an implementor) raised concerns = about a new PATCH proposal that primarily increases readibility. =  This will be a non-backwards-compatible breaking change for not = much benefit.
Chairs will present 3 options to list for consensus - = 6902-compliant, 6902-based, or Draft 3.
Some discussion around localization, Phil will dig in deeper to see = if there are any inconsistencies and bring any issues he finds to the = WG.

---
Meeting recording:

Your recording is now available on the WebEx = service site. Click the link below to play it: 

https://go.webex.com/go/lsr.php?RCID=3D7f2d0f8bdfcd435ebd34aa4c007= 1130b 

SCIM WG bi-weekly call-20140402 = 1806-1 
Wednesday, April 2, 2014 11:06 am San = Francisco Time 
52 Minutes 
_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_F742C091-882C-44C9-8B2A-AD1972F0CDB3-- From nobody Thu Apr 3 16:34: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 4F1D21A036D for ; Thu, 3 Apr 2014 16:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 9AKH3PPOt9wq for ; Thu, 3 Apr 2014 16:34:50 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD641A0387 for ; Thu, 3 Apr 2014 16:34:47 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so2554919pbb.5 for ; Thu, 03 Apr 2014 16:34:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=PiBEcaZWjTprn4FJUegkjVXBadI26XcY8/uJiQCL9A0=; b=f2LlSOquFGEzN4tL5XoY3D4VVkRminUng/+OicTqQi+wdj/gCzSb5TXKSrQIDRlPoO B4/DUW4qEXqj/aEDG9hS+ozYREpRxV3dysngWT5gQC3dYgdJPibJ2qLmMPrVFElPi9wm XqAtsbmVreRRWb4Fea4cgGzin4ZyfjYW4eVnWNy83tw9sqdi+0QFH+hX7HPeUvMKrlLc lrwgm2pQkdluEqKINaxKivVGAeINVuS+aL97nCOMMVSn0oPR6PxeyzrkRopZhPQYQX3s PH7l7jCY50F0xyHq1TuUCksW71dbTliztOJyfIJ3KX6i5QU73vcmgKFOYcEqk3TXb5oG 5nww== X-Gm-Message-State: ALoCoQk8QTL0FbwwxKJ/WGkg78Gh5Xxd3SSmTDlkSZThNJ62xKC4UBjjyTGmZkvIUl0wga/gaNPl MIME-Version: 1.0 X-Received: by 10.68.178.131 with SMTP id cy3mr10965140pbc.146.1396568083719; Thu, 03 Apr 2014 16:34:43 -0700 (PDT) Received: by 10.68.245.202 with HTTP; Thu, 3 Apr 2014 16:34:43 -0700 (PDT) Date: Thu, 3 Apr 2014 16:34:43 -0700 Message-ID: From: Melvin Laguren To: scim@ietf.org Content-Type: multipart/alternative; boundary=047d7b6735ea88fd8f04f62bd855 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/a59S0rDptMp1ypBezQ0IeG-laUA Subject: [scim] Testing Scim Configuration 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, 03 Apr 2014 23:34:55 -0000 --047d7b6735ea88fd8f04f62bd855 Content-Type: text/plain; charset=ISO-8859-1 Hi, At OneLogin, we are working to make SCIM the standard for provisioning users to apps. It has been working out great for us, as providers are building scim servers and then once the server is added to our catalog, it does exactly what we want it to do. The interesting thing we are seeing now, is that in our case we give the user the option to test the connection. In doing so, we make a call to /Users and if we get a 200, we let them know that the app has been set up. Unfortunately one of our newest apps using scim returns back over 1000 users and took some time before the customer new it was configured properly. My question is, how do other implementors handle this? Not all of the providers create all the other points. So calling another endpoint may not exist. What if we authenticate against the base url? Looking forward to your thoughts and suggestions. Thanks, Melvin Melvin Laguren | Lead QA Automation Engineer | melvin@onelogin.com | --047d7b6735ea88fd8f04f62bd855 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

At OneLogin, we are working to make= SCIM the standard for provisioning users to apps. =A0It has been working o= ut great for us, as providers are building scim servers and then once the s= erver is added to our catalog, it does exactly what we want it to do.

The interesting thing we are seeing now, is that in our= case we give the user the option to test the connection. =A0In doing so, w= e make a call to /Users and if we get a 200, we let them know that the app = has been set up. =A0Unfortunately one of our newest apps using scim returns= back over 1000 users and took some time before the customer new it was con= figured properly.

My question is, how do other implementors handle this? = =A0Not all of the providers create all the other points. =A0So calling anot= her endpoint may not exist. =A0What if we authenticate against the base url= ?

Looking forward to your thoughts and suggestions.
=

Thanks,

Melvin

<= /div>
Melvi= n Laguren | Lead QA Automation Engineer | melvin@onelogin.com=A0|
--047d7b6735ea88fd8f04f62bd855-- From nobody Thu Apr 3 17:09: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 B63AD1A03F7 for ; Thu, 3 Apr 2014 17:09:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 z9lpybU13TaT for ; Thu, 3 Apr 2014 17:08:56 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF1D1A03F6 for ; Thu, 3 Apr 2014 17:08:56 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j17so2843098oag.28 for ; Thu, 03 Apr 2014 17:08:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=kSrVNUfL6o9xtueKC6uBZ2qkTWa9OKtUoP31uCXZ5Vc=; b=BQfk+8clyNA2ysU2j6Ym7mTpVmNci1Orbtw08Zw2S6r5vTAQH2QZ58+f61z3GIQtrv XhWSAuRMwQBHM64plc07mhkjS06SR++FRE/Uiod7l8qjGqKbwDdL9ypnieS8oVAepNXp 6c+myRgOu/5ir0RS1meDPGd+AhZuy0Zi9nOjXHBZd4WGXR+qMKzi+rtHk5nT9nwYnYet +arxOPZrHWfshmbmD4jSTP9gw4XO4d06e2JB7pDOEes85WdfHyvhwNpAMoVFHwVPbqvn 8JtQjKXqbYGL5SAfbrLyuHSiBNUFnTbcHZkkxH+IZqmMeS5bapW5HvDJ7hmNMCoK57Cz +zKg== X-Gm-Message-State: ALoCoQlkRgL4nvbVflkwf113ZNglARjIUNhsTP86KaQB6cCON7scx/tzN23IZQuI2aiM502AVuHK X-Received: by 10.60.159.137 with SMTP id xc9mr13090322oeb.31.1396570131776; Thu, 03 Apr 2014 17:08:51 -0700 (PDT) Received: from calamity.unboundid.lab (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPSA id ec8sm11656821obb.18.2014.04.03.17.08.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 17:08:50 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F4B941F3-27C8-4AC2-B166-A8E7F78AB1AB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jacob Childress In-Reply-To: Date: Thu, 3 Apr 2014 19:08:50 -0500 Message-Id: <7D2D5061-189C-4C58-A0FF-7D954BA2F846@unboundid.com> References: To: Melvin Laguren X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/scim/kao3RNQjKLsPzes8FFf7YVN9hds Cc: scim@ietf.org Subject: Re: [scim] Testing Scim Configuration 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, 04 Apr 2014 00:09:01 -0000 --Apple-Mail=_F4B941F3-27C8-4AC2-B166-A8E7F78AB1AB Content-Type: multipart/alternative; boundary="Apple-Mail=_B23D3A74-1E3B-4E0C-A591-3436E50D3C06" --Apple-Mail=_B23D3A74-1E3B-4E0C-A591-3436E50D3C06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Melvin, If /Users and only /Users is guaranteed to exist, I=92d suggest = performing a search that you know won=92t be expensive (e.g., one that = uses an attribute that=92s likely to be indexed by the backing data = store). For example: GET /Users?filter=3DuserName%20eq%20%22bjensen%22=20 HTTP/1.1 Accept: application/json Accept-Encoding: gzip, deflate, compress Authorization: Basic aGV5LCBicmlhbiwgaG93J3MgaXQgZ29pbmc=3D Content-Type: application/json; charset=3Dutf-8 Host: example.com:443 User-Agent: HTTPie/0.7.2 HTTP/1.1 200 OK Content-Length: 78 Content-Type: application/json Server: Jetty(8.1.12.v20130726) { "Resources": [],=20 "itemsPerPage": 0,=20 "schemas": [],=20 "startIndex": 1,=20 "totalResults": 0 } Jacob On Apr 3, 2014, at 6:34 PM, Melvin Laguren wrote: > Hi, >=20 > At OneLogin, we are working to make SCIM the standard for provisioning = users to apps. It has been working out great for us, as providers are = building scim servers and then once the server is added to our catalog, = it does exactly what we want it to do. >=20 > The interesting thing we are seeing now, is that in our case we give = the user the option to test the connection. In doing so, we make a call = to /Users and if we get a 200, we let them know that the app has been = set up. Unfortunately one of our newest apps using scim returns back = over 1000 users and took some time before the customer new it was = configured properly. >=20 > My question is, how do other implementors handle this? Not all of the = providers create all the other points. So calling another endpoint may = not exist. What if we authenticate against the base url? >=20 > Looking forward to your thoughts and suggestions. >=20 > Thanks, >=20 > Melvin >=20 > Melvin Laguren | Lead QA Automation Engineer | melvin@onelogin.com | > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_B23D3A74-1E3B-4E0C-A591-3436E50D3C06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Melvin,

If /Users = and only /Users is guaranteed to exist, I=92d suggest performing a = search that you know won=92t be expensive (e.g., one that uses an = attribute that=92s likely to be indexed by the backing data store). For = example:

GET /Users?filter=3DuserName%20eq%2= 0%22bjensen%22 
HTTP/1.1
Accept: application/jsonAccept-Encoding: gzip, deflate, = compress
Authorization: Basic = aGV5LCBicmlhbiwgaG93J3MgaXQgZ29pbmc=3D
Content-Type: application/j= son; charset=3Dutf-8
Host: example.com:443
User-Agent: HTTPie= /0.7.2

HTTP/1.1 200 OK
Content-Length: 78
Cont= ent-Type: application/json
Server: Jetty(8.1.12.v20130726)
{
    "Resources": [], 
  =   "itemsPerPage": 0, 
  =   "schemas": [], 
  =   "startIndex": 1, 
  =   "totalResults": 0
}


Jacob


On Apr 3, 2014, at 6:34 = PM, Melvin Laguren <melvin@onelogin.com> = wrote:

Hi,

At OneLogin, we = are working to make SCIM the standard for provisioning users to apps. =  It has been working out great for us, as providers are building = scim servers and then once the server is added to our catalog, it does = exactly what we want it to do.

The interesting thing we are seeing now, is that in = our case we give the user the option to test the connection.  In = doing so, we make a call to /Users and if we get a 200, we let them know = that the app has been set up.  Unfortunately one of our newest apps = using scim returns back over 1000 users and took some time before the = customer new it was configured properly.

My question is, how do other implementors handle = this?  Not all of the providers create all the other points. =  So calling another endpoint may not exist.  What if we = authenticate against the base url?

Looking forward to your thoughts and = suggestions.

Thanks,

Mel= vin

Melvin Laguren | = Lead QA Automation Engineer | melvin@onelogin.com |
=
_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_B23D3A74-1E3B-4E0C-A591-3436E50D3C06-- --Apple-Mail=_F4B941F3-27C8-4AC2-B166-A8E7F78AB1AB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnDCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGYDCCBUig AwIBAgIDB5a8MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwOTE3MTQwOTM4WhcNMTQwOTE4MDIwMDEyWjBxMRkwFwYDVQQNExBncTUwengyWTZ5TDBJRHpu MSYwJAYDVQQDDB1qYWNvYi5jaGlsZHJlc3NAdW5ib3VuZGlkLmNvbTEsMCoGCSqGSIb3DQEJARYd amFjb2IuY2hpbGRyZXNzQHVuYm91bmRpZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDI01/zavGVzFaP5UAVMj6AXKTs6Ry9Yqk/KJYqDFLO1AL1d2DyU0jTzXvblJ4ZxM7XkDoZ xCExTy5aMXUWNVktM6z7jN054LrjO7/bugAr4PepX4vujn1yyjJDd0Ecl9Im3AWFZdGdKt1rZQPR /9AnWOCtc3XRAvY1AUcQRBAoEUFE3xgXW5HISv8f7LrRp3sC4i7rxeztKXgyq1LKBpQq6/CymCYe vhxI9GGG+RFUU5meb+sZqTGiA0Eb0YfSLdOOBFeJ76fFPRBEY98FzXlKwhOtWrNN7q7/I0tbIy/C 3VSTY+WqYcjcIRHHLbmRA0TmGd7Vd6Q4VXG0JvOcMrbnAgMBAAGjggLjMIIC3zAJBgNVHRMEAjAA MAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMWO o2Uwk2j1rAnGINNzKOBAm+R3MB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMCgGA1Ud EQQhMB+BHWphY29iLmNoaWxkcmVzc0B1bmJvdW5kaWQuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7 BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBD bGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2Yg dGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEF BQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAwt4cOUtSvIgDYCzSfUMfpWyPCidpqjiWLwAS0f8hTSiRhPSeEx5yE3GXhZUi9E/ShbsIFiq1 RZPzynCpzMDg5F3b2uXJqnXGT36PzX05z4bcCD7at5GPxMJMzGTgYhy8xjc1rc37qEOZ/FSLgWOl ZZakZxyW3XaFb9+f+CDvgkGob5GKB3nOANhLhPf5UlzRkfiDhM6OtRixLIwv1Prg+F7g/yPao5yY ExQHVh9sGxNWzqVkNqteqEDDhd5nKCKfmt0XtRVBPAOdzTGw4nAuaflNMb6W5AhvGuNcr2p/NCsS nxsnSbEiTEweiZnnS97ObJ+mHUXT7q7jnymL9TA/1jGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2Vy dGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAweWvDAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA0MDQwMDA4NTBaMCMGCSqGSIb3DQEJBDEWBBRmgCzY 7BtMVsXe1FvZ5HYsOopxvDCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAweWvDCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDB5a8MA0GCSqGSIb3DQEBAQUABIIBAClvWpglS08YuLbfalwJ/E8FhsCup4FdgR7v V99KTSE9bKWC8jGnt/LhTSF7rPADkYUz+9AZ393yVTZ4c6vJWLl8rdNnSrdwdQXdbw07DwCQIwbF UfD1nj335nyW6BCetENaoAfshUYTqGg8M5OjetKDFn9JmEQwk7LDNW7BPu+tVONTPVOIis/sntrq wtq7t0/iqnqetubYDKa5HBMwL3MLyqAdUxZIIblGyXj3q/Tt1/OpJKcMkb+85zxqiFBh+pPYsFF/ IgrS0RL/124iVPCrre+9Lk/AY8YbnOeKsJsiXEj4KyFg39F3I8SOrKvJm3KfIMW3APb1Fw0vvy6R rDgAAAAAAAA= --Apple-Mail=_F4B941F3-27C8-4AC2-B166-A8E7F78AB1AB-- From nobody Thu Apr 3 17:41:51 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 2830A1A03FB for ; Thu, 3 Apr 2014 17:41:47 -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 g0NC7sA3XETe for ; Thu, 3 Apr 2014 17:41:42 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 35B971A0422 for ; Thu, 3 Apr 2014 17:41:40 -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 s340fY7F029538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Apr 2014 00:41:35 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s340fXp1008935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2014 00:41:33 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s340fX6V008930; Fri, 4 Apr 2014 00:41:33 GMT Received: from [192.168.1.186] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Apr 2014 17:41:33 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_E3427EB5-E1DB-4BC6-BEAB-72C2452E9569" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: <7D2D5061-189C-4C58-A0FF-7D954BA2F846@unboundid.com> Date: Thu, 3 Apr 2014 17:41:31 -0700 Message-Id: <3B31012F-EFB3-41CD-948B-5579E28419FF@oracle.com> References: <7D2D5061-189C-4C58-A0FF-7D954BA2F846@unboundid.com> To: Jacob Childress X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/BN3KfwxmFmZZWipAIU-JrCrYxXs Cc: scim@ietf.org, Melvin Laguren Subject: Re: [scim] Testing Scim Configuration 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, 04 Apr 2014 00:41:47 -0000 --Apple-Mail=_E3427EB5-E1DB-4BC6-BEAB-72C2452E9569 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 You could also query /ServiceProviderConfig and even limit the = attributes returned to a single attribute. Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 3, 2014, at 5:08 PM, Jacob Childress = wrote: > Hi Melvin, >=20 > If /Users and only /Users is guaranteed to exist, I=92d suggest = performing a search that you know won=92t be expensive (e.g., one that = uses an attribute that=92s likely to be indexed by the backing data = store). For example: >=20 > GET /Users?filter=3DuserName%20eq%20%22bjensen%22=20 > HTTP/1.1 > Accept: application/json > Accept-Encoding: gzip, deflate, compress > Authorization: Basic aGV5LCBicmlhbiwgaG93J3MgaXQgZ29pbmc=3D > Content-Type: application/json; charset=3Dutf-8 > Host: example.com:443 > User-Agent: HTTPie/0.7.2 >=20 > HTTP/1.1 200 OK > Content-Length: 78 > Content-Type: application/json > Server: Jetty(8.1.12.v20130726) >=20 > { > "Resources": [],=20 > "itemsPerPage": 0,=20 > "schemas": [],=20 > "startIndex": 1,=20 > "totalResults": 0 > } >=20 >=20 > Jacob >=20 >=20 > On Apr 3, 2014, at 6:34 PM, Melvin Laguren = wrote: >=20 >> Hi, >>=20 >> At OneLogin, we are working to make SCIM the standard for = provisioning users to apps. It has been working out great for us, as = providers are building scim servers and then once the server is added to = our catalog, it does exactly what we want it to do. >>=20 >> The interesting thing we are seeing now, is that in our case we give = the user the option to test the connection. In doing so, we make a call = to /Users and if we get a 200, we let them know that the app has been = set up. Unfortunately one of our newest apps using scim returns back = over 1000 users and took some time before the customer new it was = configured properly. >>=20 >> My question is, how do other implementors handle this? Not all of = the providers create all the other points. So calling another endpoint = may not exist. What if we authenticate against the base url? >>=20 >> Looking forward to your thoughts and suggestions. >>=20 >> Thanks, >>=20 >> Melvin >>=20 >> Melvin Laguren | Lead QA Automation Engineer | melvin@onelogin.com | >> _______________________________________________ >> 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 --Apple-Mail=_E3427EB5-E1DB-4BC6-BEAB-72C2452E9569 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 You = could also query /ServiceProviderConfig and even limit the attributes = returned to a single attribute.


On Apr 3, 2014, at 5:08 PM, Jacob Childress <jacob.childress@unboundid.co= m> wrote:

Hi Melvin,

If /Users = and only /Users is guaranteed to exist, I=92d suggest performing a = search that you know won=92t be expensive (e.g., one that uses an = attribute that=92s likely to be indexed by the backing data store). For = example:

GET /Users?filter=3DuserName%20eq%2= 0%22bjensen%22 
HTTP/1.1
Accept: application/jsonAccept-Encoding: gzip, deflate, = compress
Authorization: Basic = aGV5LCBicmlhbiwgaG93J3MgaXQgZ29pbmc=3D
Content-Type: application/j= son; charset=3Dutf-8
Host: example.com:443
User-Agent: HTTPi= e/0.7.2

HTTP/1.1 200 OK
Content-Length: 78
Con= tent-Type: application/json
Server: Jetty(8.1.12.v20130726)
{
    "Resources": [], 
  =   "itemsPerPage": 0, 
  =   "schemas": [], 
  =   "startIndex": 1, 
  =   "totalResults": 0
}


Jacob


On Apr 3, 2014, at 6:34 = PM, Melvin Laguren <melvin@onelogin.com> = wrote:

Hi,

At OneLogin, we = are working to make SCIM the standard for provisioning users to apps. =  It has been working out great for us, as providers are building = scim servers and then once the server is added to our catalog, it does = exactly what we want it to do.

The interesting thing we are seeing now, is that in = our case we give the user the option to test the connection.  In = doing so, we make a call to /Users and if we get a 200, we let them know = that the app has been set up.  Unfortunately one of our newest apps = using scim returns back over 1000 users and took some time before the = customer new it was configured properly.

My question is, how do other implementors handle = this?  Not all of the providers create all the other points. =  So calling another endpoint may not exist.  What if we = authenticate against the base url?

Looking forward to your thoughts and = suggestions.

Thanks,

Mel= vin

Melvin Laguren | = Lead QA Automation Engineer | melvin@onelogin.com |
=
_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/m= ailman/listinfo/scim

_________________= ______________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_E3427EB5-E1DB-4BC6-BEAB-72C2452E9569-- From nobody Fri Apr 4 02:03: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 49BDE1A03A1 for ; Fri, 4 Apr 2014 02:03:03 -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 MePvkzNSx5Qo for ; Fri, 4 Apr 2014 02:02:58 -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 9170A1A00E3 for ; Fri, 4 Apr 2014 02:02:57 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id hr17so2246007lab.19 for ; Fri, 04 Apr 2014 02:02:52 -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=HN8Sr81l7sQS4k29mW6u4vpSeBx3vgfv6T0Pw1fwsDY=; b=MBWnR0LbFcRKv9Ftp4vp2RTxNNwTeELzdg4tFtN0Ik+mx96RBTPWRQy1PEHAGwV6jT JmzGkHzEioHbDEDllmWHMGI4K3Ne+OFFFg4kuHvjmq+UkQdDiM5dBzaRhL3bOUo99Msv 2eHqBoEXDWO1QZ/QmJS7rxqa3nmZ+5j0LBMHMp9nyhyrCYcCcT7nSo3mbzd5wD29JYg4 /KYSx96gxkFhWRduJw31R/x0FsUFMmfbcJhwXSfBravYl9UJL9dpa8K7Y0v1M4Hkib8N MV+UlwzK2O9t3yVTXOt6lUfU8cpSI96hTIgCjLJvGX/fM6/N+5Co0XhnGlM8A4WjvxMi YLOw== X-Gm-Message-State: ALoCoQkd6KCGyzFpXxULhi6tSSBoyaKezu67kJEILr2f+ULH96JRL6x0LLQyXZtzJBwMOpn/BuD5 X-Received: by 10.152.37.99 with SMTP id x3mr7671062laj.7.1396602172251; Fri, 04 Apr 2014 02:02:52 -0700 (PDT) Received: from [109.105.104.170] (dhcp36.se-tug.nordu.net. [109.105.104.170]) by mx.google.com with ESMTPSA id a2sm5261024lbz.25.2014.04.04.02.02.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Apr 2014 02:02:51 -0700 (PDT) Message-ID: <533E7539.8050800@mnt.se> Date: Fri, 04 Apr 2014 11:02:49 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: scim@ietf.org, "Hunt, Phil" References: <5329963F.6070106@sunet.se> In-Reply-To: <5329963F.6070106@sunet.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/_Ri57EWY0jVJW-oc5J83PC4EG3Q Subject: Re: [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: Fri, 04 Apr 2014 09:03:03 -0000 On 2014-03-19 14:06, Leif Johansson wrote: > > 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 > There have been no objections. Phil: feel free to make the required updates in the next version and close the issue. From nobody Fri Apr 4 06:03: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 0E37E1A0176 for ; Fri, 4 Apr 2014 06:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 xevIw74r3IxS for ; Fri, 4 Apr 2014 06:02:58 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id C5C751A0175 for ; Fri, 4 Apr 2014 06:02:57 -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.908.10; Fri, 4 Apr 2014 13:02:51 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.189]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.189]) with mapi id 15.00.0908.008; Fri, 4 Apr 2014 13:02:51 +0000 From: Kelly Grizzle To: Phil Hunt , Jacob Childress Thread-Topic: [scim] Testing Scim Configuration Thread-Index: AQHPT5VTJAOaqTs2Z0uN6DWCpud4V5sAlPEAgAAJIoCAAM8QkA== Date: Fri, 4 Apr 2014 13:02:50 +0000 Message-ID: <761949a2031c4fa98395cf15d68ee8af@BN1PR04MB392.namprd04.prod.outlook.com> References: <7D2D5061-189C-4C58-A0FF-7D954BA2F846@unboundid.com> <3B31012F-EFB3-41CD-948B-5579E28419FF@oracle.com> In-Reply-To: <3B31012F-EFB3-41CD-948B-5579E28419FF@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 2E2E252E006D6E2E2E267B x-originating-ip: [72.182.10.254] x-forefront-prvs: 01713B2841 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(24454002)(377454003)(164054003)(199002)(189002)(99286001)(95416001)(79102001)(15395725003)(77096001)(92566001)(65816001)(83322001)(76786001)(19580405001)(76796001)(93136001)(94316002)(16236675002)(59766001)(47976001)(4396001)(90146001)(46102001)(85306002)(47446002)(56776001)(80022001)(66066001)(47736001)(77982001)(50986001)(81342001)(98676001)(97336001)(56816005)(19580395003)(94946001)(74316001)(93516002)(76482001)(33646001)(54316002)(53806001)(51856001)(63696002)(20776003)(54356001)(74502001)(87936001)(74366001)(15975445006)(74662001)(74876001)(31966008)(80976001)(69226001)(49866001)(86362001)(16601075003)(97186001)(95666003)(81816001)(87266001)(83072002)(2656002)(99396002)(81686001)(74706001)(19609705001)(81542001)(76576001)(85852003)(19300405004)(15202345003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB390; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:B4CCF937.8CF2BFD1.71E1BF03.42DDF841.203F2; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: sailpoint.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_761949a2031c4fa98395cf15d68ee8afBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/IQozlkJbFOb1Zxf2c42MVm2_E20 Cc: "scim@ietf.org" , Melvin Laguren Subject: Re: [scim] Testing Scim Configuration 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, 04 Apr 2014 13:03:02 -0000 --_000_761949a2031c4fa98395cf15d68ee8afBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 This is what we do in our implementation. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, April 03, 2014 7:42 PM To: Jacob Childress Cc: scim@ietf.org; Melvin Laguren Subject: Re: [scim] Testing Scim Configuration You could also query /ServiceProviderConfig and even limit the attributes r= eturned to a single attribute. Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 3, 2014, at 5:08 PM, Jacob Childress > wrote: Hi Melvin, If /Users and only /Users is guaranteed to exist, I'd suggest performing a = search that you know won't be expensive (e.g., one that uses an attribute t= hat's likely to be indexed by the backing data store). For example: GET /Users?filter=3DuserName%20eq%20%22bjensen%22 HTTP/1.1 Accept: application/json Accept-Encoding: gzip, deflate, compress Authorization: Basic aGV5LCBicmlhbiwgaG93J3MgaXQgZ29pbmc=3D Content-Type: application/json; charset=3Dutf-8 Host: example.com:443 User-Agent: HTTPie/0.7.2 HTTP/1.1 200 OK Content-Length: 78 Content-Type: application/json Server: Jetty(8.1.12.v20130726) { "Resources": [], "itemsPerPage": 0, "schemas": [], "startIndex": 1, "totalResults": 0 } Jacob On Apr 3, 2014, at 6:34 PM, Melvin Laguren > wrote: Hi, At OneLogin, we are working to make SCIM the standard for provisioning user= s to apps. It has been working out great for us, as providers are building= scim servers and then once the server is added to our catalog, it does exa= ctly what we want it to do. The interesting thing we are seeing now, is that in our case we give the us= er the option to test the connection. In doing so, we make a call to /User= s and if we get a 200, we let them know that the app has been set up. Unfo= rtunately one of our newest apps using scim returns back over 1000 users an= d took some time before the customer new it was configured properly. My question is, how do other implementors handle this? Not all of the prov= iders create all the other points. So calling another endpoint may not exi= st. What if we authenticate against the base url? Looking forward to your thoughts and suggestions. Thanks, Melvin Melvin Laguren | Lead QA Automation Engineer | melvin@onelogin.com | _______________________________________________ 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 --_000_761949a2031c4fa98395cf15d68ee8afBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

This is what we do in our= implementation.

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, April 03, 2014 7:42 PM
To: Jacob Childress
Cc: scim@ietf.org; Melvin Laguren
Subject: Re: [scim] Testing Scim Configuration

 

You could also query /ServiceProviderConfig and even= limit the attributes returned to a single attribute.

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

On Apr 3, 2014, at 5:08 PM, Jacob Childress <jacob.childress@unboundid.com<= /a>> wrote:



Hi Melvin,

 

If /Users and only /Users is guaranteed to exist, I&= #8217;d suggest performing a search that you know won’t be expensive = (e.g., one that uses an attribute that’s likely to be indexed by the = backing data store). For example:

 

GET /Users?filter=3DuserName%20eq%20%22bjensen%= 22 

HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate, compress
Authorization: Basic aGV5LCBicmlhbiwgaG93J3MgaXQgZ29pbmc=3D
Content-Type: application/json; charset=3Dutf-8
Host: example.com:443
User-Agent: HTTPie/0.7.2

HTTP/1.1 200 OK
Content-Length: 78
Content-Type: application/json
Server: Jetty(8.1.12.v20130726)

{
    "Resources": [], 
    "itemsPerPage": 0, 
    "schemas": [], 
    "startIndex": 1, 
    "totalResults": 0
}

 

 

Jacob

 

 

On Apr 3, 2014, at 6:34 PM, Melvin Laguren <melvin@onelogin.com> wrote:



Hi,

 

At OneLogin, we are working to make SCIM the standar= d for provisioning users to apps.  It has been working out great for u= s, as providers are building scim servers and then once the server is added= to our catalog, it does exactly what we want it to do.

 

The interesting thing we are seeing now, is that in = our case we give the user the option to test the connection.  In doing= so, we make a call to /Users and if we get a 200, we let them know that th= e app has been set up.  Unfortunately one of our newest apps using scim returns back over 1000 users and took some t= ime before the customer new it was configured properly.

 

My question is, how do other implementors handle thi= s?  Not all of the providers create all the other points.  So cal= ling another endpoint may not exist.  What if we authenticate against = the base url?

 

Looking forward to your thoughts and suggestions.

 

Thanks,

 

Melvin

 

Melvin Laguren | Lead QA Automation Engin= eer | melvin@onelogin.com |

_______________________________________________
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

 

--_000_761949a2031c4fa98395cf15d68ee8afBN1PR04MB392namprd04pro_-- From nobody Fri Apr 4 06:50:15 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 A34451A018B for ; Fri, 4 Apr 2014 06:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 DelLAPNNSyq6 for ; Fri, 4 Apr 2014 06:50:10 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 82F8F1A019A for ; Fri, 4 Apr 2014 06:50:10 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id c41so3121468yho.37 for ; Fri, 04 Apr 2014 06:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=okta.com; s=gap; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cZEJt2z71ANKvVt23ff3U5zufp56dAPRpAlNzQldUiE=; b=inRfghSZEW44S6cqXIX/T5/utMGB3IjKk2FLSjg4W/G054CNJxIMpYtwqgA8YpMNx6 hiSnqxBmH0KpGocM1wUgNgRQqEhK+uqc/T8Y7tN7gsSo5ogy2XKZhK7Y6WfwG7RFxyTb FeyXAVPUhp+7xfWtKOpJ2ZsuKSrRhGgz//GNw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cZEJt2z71ANKvVt23ff3U5zufp56dAPRpAlNzQldUiE=; b=bf5UBE4iO3jHaj1iiSsqhWwblnGHajk7Z6rTTu5zTvcy4w6vWp/3cVQwtsOdvu6m1G S5Nd1RmbiCjEZhxVQc51s7/RWb0/aCdnAykjwS2tkkBJjSVfBn2YNIgkYzSsY0ptjgJ7 4F/SB9Pn80Ni4IDVn/qCOze6FmfICbX/tY+cESe9iGYTexX3JUG6EK/zrb7VbiqFQ4yk SvVjoc+kf7lfS9nFcF5L8eQWdCcUtnKCdjPXmFBGrQSFbXs9SjEBbpCfohaxtC426X0+ H0r8wcp44ePiFFTSWGEYEuK0CEqaoNM0hZXOYSETAN2KzIXgz0CMC7vLKGjVcL6asp8s i7PQ== X-Gm-Message-State: ALoCoQkQJ5InBAz6JmrbS+mo0mDL3FrHxK0bxxqlIHIsdHO2OwNHKPyfONixdqKd/pRY2TYicOrj X-Received: by 10.236.94.197 with SMTP id n45mr17070999yhf.46.1396619405714; Fri, 04 Apr 2014 06:50:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.95.70 with HTTP; Fri, 4 Apr 2014 06:49:45 -0700 (PDT) In-Reply-To: <761949a2031c4fa98395cf15d68ee8af@BN1PR04MB392.namprd04.prod.outlook.com> References: <7D2D5061-189C-4C58-A0FF-7D954BA2F846@unboundid.com> <3B31012F-EFB3-41CD-948B-5579E28419FF@oracle.com> <761949a2031c4fa98395cf15d68ee8af@BN1PR04MB392.namprd04.prod.outlook.com> From: Madhu M Date: Fri, 4 Apr 2014 09:49:45 -0400 Message-ID: To: Kelly Grizzle Content-Type: multipart/alternative; boundary=20cf301af897907bd604f637cbde Archived-At: http://mailarchive.ietf.org/arch/msg/scim/AKTTRE8qvIcpUFpMHKwfhxPk74Y Cc: Jacob Childress , "scim@ietf.org" , Melvin Laguren , Phil Hunt Subject: Re: [scim] Testing Scim Configuration 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, 04 Apr 2014 13:50:14 -0000 --20cf301af897907bd604f637cbde Content-Type: text/plain; charset=ISO-8859-1 The Okta implementation also checks the /ServiceProviderConfigs during the connection testing. On Fri, Apr 4, 2014 at 9:02 AM, Kelly Grizzle wrote: > +1 > > > > This is what we do in our implementation. > > > > *From:* scim [mailto:scim-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Thursday, April 03, 2014 7:42 PM > *To:* Jacob Childress > *Cc:* scim@ietf.org; Melvin Laguren > *Subject:* Re: [scim] Testing Scim Configuration > > > > You could also query /ServiceProviderConfig and even limit the attributes > returned to a single attribute. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > On Apr 3, 2014, at 5:08 PM, Jacob Childress > wrote: > > > > Hi Melvin, > > > > If /Users and only /Users is guaranteed to exist, I'd suggest performing a > search that you know won't be expensive (e.g., one that uses an attribute > that's likely to be indexed by the backing data store). For example: > > > > GET /Users?filter=userName%20eq%20%22bjensen%22 > > HTTP/1.1 > Accept: application/json > Accept-Encoding: gzip, deflate, compress > Authorization: Basic aGV5LCBicmlhbiwgaG93J3MgaXQgZ29pbmc= > Content-Type: application/json; charset=utf-8 > Host: example.com:443 > User-Agent: HTTPie/0.7.2 > > HTTP/1.1 200 OK > Content-Length: 78 > Content-Type: application/json > Server: Jetty(8.1.12.v20130726) > > { > "Resources": [], > "itemsPerPage": 0, > "schemas": [], > "startIndex": 1, > "totalResults": 0 > } > > > > > > Jacob > > > > > > On Apr 3, 2014, at 6:34 PM, Melvin Laguren wrote: > > > > Hi, > > > > At OneLogin, we are working to make SCIM the standard for provisioning > users to apps. It has been working out great for us, as providers are > building scim servers and then once the server is added to our catalog, it > does exactly what we want it to do. > > > > The interesting thing we are seeing now, is that in our case we give the > user the option to test the connection. In doing so, we make a call to > /Users and if we get a 200, we let them know that the app has been set up. > Unfortunately one of our newest apps using scim returns back over 1000 > users and took some time before the customer new it was configured properly. > > > > My question is, how do other implementors handle this? Not all of the > providers create all the other points. So calling another endpoint may not > exist. What if we authenticate against the base url? > > > > Looking forward to your thoughts and suggestions. > > > > Thanks, > > > > Melvin > > > > Melvin Laguren | Lead QA Automation Engineer | melvin@onelogin.com | > > _______________________________________________ > 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 > > -- Madhu Mahadevan Sr. Technical Consultant @ okta.com ; t: @mmaha c: +1 (416) 451-4611 ; o: +1 (415) 578-5176 ; b: +1 (877) 273-4202,,1083942 --20cf301af897907bd604f637cbde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The Okta implementation also checks the /Service= ProviderConfigs during the connection testing.


On Fri, Apr 4, 2014 at 9:02 AM, Kelly Gr= izzle <kelly.grizzle@sailpoint.com> wrote:

+1

 

This is what we do in our= implementation.

 

From: scim [ma= ilto:scim-bounce= s@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, April 03, 2014 7:42 PM
To: Jacob Childress
Cc: scim@ietf.org= ; Melvin Laguren
Subject: Re: [scim] Testing Scim Configuration<= /p>

 

You could also query /ServiceProviderConfig and even= limit the attributes returned to a single attribute.

 

 

On Apr 3, 2014, at 5:08 PM, Jacob Childress <jacob.childr= ess@unboundid.com> wrote:



Hi Melvin,

 

If /Users and only /Users is guaranteed to exist, I&= rsquo;d suggest performing a search that you know won’t be expensive = (e.g., one that uses an attribute that’s likely to be indexed by the = backing data store). For example:

 

GET /Users?filter=3DuserName%20eq%20%22bjensen%= 22 

HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate, compress
Authorization: Basic aGV5LCBicmlhbiwgaG93J3MgaXQgZ29pbmc=3D
Content-Type: application/json; charset=3Dutf-8
Host: example.com:443
User-Agent: HTTPie/0.7.2

HTTP/1.1 200 OK
Content-Length: 78
Content-Type: application/json
Server: Jetty(8.1.12.v20130726)

{
    "Resources": [], 
    "itemsPerPage": 0, 
    "schemas": [], 
    "startIndex": 1, 
    "totalResults": 0
}

 

 

Jacob

 

 



Hi,

 

At OneLogin, we are working to make SCIM the standar= d for provisioning users to apps.  It has been working out great for u= s, as providers are building scim servers and then once the server is added= to our catalog, it does exactly what we want it to do.

 

The interesting thing we are seeing now, is that in = our case we give the user the option to test the connection.  In doing= so, we make a call to /Users and if we get a 200, we let them know that th= e app has been set up.  Unfortunately one of our newest apps using scim returns back over 1000 users and took some t= ime before the customer new it was configured properly.

 

My question is, how do other implementors handle thi= s?  Not all of the providers create all the other points.  So cal= ling another endpoint may not exist.  What if we authenticate against = the base url?

 

Looking forward to your thoughts and suggestions.=

 

Thanks,

 

Melvin

 

Melvin Laguren | Lead QA Automation Engin= eer | melvin@onelogin.co= m |

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

 

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

 


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




--
Madhu Mahadevan
Sr. Technical Consultant @ <= a href=3D"http://okta.com" target=3D"_blank">okta.com  ;  t: @mmaha
c: = +1 (416) 451-4611 ;  o: +1 (415) 578-5176 ;  b: +1 (877) 273-4202,,1083942

--20cf301af897907bd604f637cbde-- From nobody Thu Apr 10 22:20:39 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 8AADF1A03BA for ; Thu, 10 Apr 2014 22:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.873 X-Spam-Level: X-Spam-Status: No, score=-12.873 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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.272, 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 qcWpKwV1J2ii for ; Thu, 10 Apr 2014 22:20:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 168231A0280 for ; Thu, 10 Apr 2014 22:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2618; q=dns/txt; s=iport; t=1397193631; x=1398403231; h=from:to:subject:date:message-id:mime-version; bh=Ez7gcMEqJRzwnayBub60ttwzis95mmxrlybJFcJZ31w=; b=f8kgvy+ywHJxZrpMRWdaKXskXGzFLXWyb6tGdMCK3OjMM5JFyZQVGZ6R XYEcRD6OUvCxdELtLGc+aGfmW/C0ahTT8cgygkdHs4RFbVu9TsakU8daz d1L3OxvlsE+gNmH7Wi0Lyu1nJvkJ36Qv2hihC9HQhQMjR4HIbyRupHT5z s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFAFZ7R1OtJA2J/2dsb2JhbABZgkJEgRLFWRZ0giwYVh0BDAFzJwSID5sNsXkXjhgPhQQEmF6SQoMwgis X-IronPort-AV: E=Sophos;i="4.97,839,1389744000"; d="scan'208,217";a="316902963" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP; 11 Apr 2014 05:20:30 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3B5KUPl013524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 11 Apr 2014 05:20:30 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.83]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 00:20:30 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: Consensus call on issue #18 - patch semantics Thread-Index: AQHPVUXBhAu6OCdCR0mywGzic6+K6Q== Date: Fri, 11 Apr 2014 05:20:29 +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.144.162] Content-Type: multipart/alternative; boundary="_000_CF6CC9AFD57F2moransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/4qHtR97hI9qyG2vsj-sR3Y5p4VM Subject: [scim] Consensus call on issue #18 - patch semantics 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, 11 Apr 2014 05:20:36 -0000 --_000_CF6CC9AFD57F2moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In London we had a good discussion on patch operation (ticket #18) and Phil= provided background information and walked the WG through a few options. I= n follow on discussions on the mailing list, survey Phil sent out, and the = WG call we narrowed it down to two options. Stay with the current patch se= mantics or change patch to a RFC6902-based model. Phil has posted to the group the proposed text for 6902 =93based=94 patch (= and also documented in the tracker under issue #18). The WG is making a co= nsensus call as follows: A. Do not change patch semantics and stay with what is currently documented= in the spec B. Adopt the 6902 based changes Phil has put together (as proposed on the l= ist and documented in tracker) C. Don=92t care or need more information Please provide your input before Apr. 18th. Cheers, Leif & Morteza --_000_CF6CC9AFD57F2moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
In London we had a good discussion on patch operation (ticket #18) and= Phil provided background information and walked the WG through a few optio= ns. In follow on discussions on the mailing list, survey Phil sent out, and= the WG call we narrowed it down to two options.  Stay with the current patch semantics or change patc= h to a RFC6902-based model.

Phil has posted to the group the proposed text for 6902 =93based=94 pa= tch (and also documented in the tracker under issue #18).  The WG is m= aking a consensus call as follows:

A. Do not change patch semantics and stay with what is currently docum= ented in the spec
B. Adopt the 6902 based changes Phil has put together (as proposed on = the list and documented in tracker)
C. Don=92t care or need more information

Please provide your input before Apr. 18th.


Cheers,
Leif & Morteza
--_000_CF6CC9AFD57F2moransarciscocom_-- From nobody Mon Apr 14 18:36:01 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 9EA381A02E2 for ; Mon, 14 Apr 2014 18:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.873 X-Spam-Level: X-Spam-Status: No, score=-12.873 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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.272, 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 6hrbadQ1qG2g for ; Mon, 14 Apr 2014 18:35:57 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AC3481A02CA for ; Mon, 14 Apr 2014 18:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4251; q=dns/txt; s=iport; t=1397525755; x=1398735355; h=from:to:subject:date:message-id:mime-version; bh=NTWiZ2ZrEEkQaAR2dOMTjFEsNO++IWVOi/I+kQ5ZRQo=; b=DkjSgHdrsesTJaYc8VYp2RvRVZze7HbpHzuorcV8mMGXtcc7dohUwwul f/cbZy6oogP6OzaKB1Bz/OWdXlasJbRgAwv0nDdR+6Da9JSPHUhEr9ilI Jr+nu2094E9b7VUGIC5oU6pyWvPwMHiWk4GI9+XvQgjfjyRzrst/eXfug M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAN+LTFOtJV2d/2dsb2JhbABYgkJEgRLDLoEfFnSCJQECBBhWHQEIBA0DAQIoORQJCgQTh3sBmXayEheOGg80hFAEmGGSQ4Mxgis X-IronPort-AV: E=Sophos;i="4.97,861,1389744000"; d="scan'208,217";a="317773254" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 15 Apr 2014 01:35:54 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3F1ZsG1031401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 15 Apr 2014 01:35:54 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.83]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 14 Apr 2014 20:35:54 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: [scim] Consensus call on issue #18 - patch semantics Thread-Index: AQHPWEsJ/fXYjTnp/U2m0xskO1TxYQ== Date: Tue, 15 Apr 2014 01:35:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [171.68.20.212] Content-Type: multipart/alternative; boundary="_000_CF71DAA0D5AF0moransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/g7sUwDUrduixuwL9LuK3D47Usd4 Subject: Re: [scim] Consensus call on issue #18 - patch semantics 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, 15 Apr 2014 01:35:59 -0000 --_000_CF71DAA0D5AF0moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Bump=85 Hard to imagine nobody in the WG has any thoughts on this topic :) Cheers, Morteza From: Morteza Ansari > Date: Thursday, April 10, 2014 at 10:20 PM To: "scim@ietf.org" > Subject: [scim] Consensus call on issue #18 - patch semantics In London we had a good discussion on patch operation (ticket #18) and Phil= provided background information and walked the WG through a few options. I= n follow on discussions on the mailing list, survey Phil sent out, and the = WG call we narrowed it down to two options. Stay with the current patch se= mantics or change patch to a RFC6902-based model. Phil has posted to the group the proposed text for 6902 =93based=94 patch (= and also documented in the tracker under issue #18). The WG is making a co= nsensus call as follows: A. Do not change patch semantics and stay with what is currently documented= in the spec B. Adopt the 6902 based changes Phil has put together (as proposed on the l= ist and documented in tracker) C. Don=92t care or need more information Please provide your input before Apr. 18th. Cheers, Leif & Morteza --_000_CF71DAA0D5AF0moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <830B7E903A098E40A0FB6D1AB5025D82@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Bump=85  Hard to imagine nobody in the WG has any thoughts on thi= s topic :)


Cheers,
Morteza

From: Morteza Ansari <moransar@cisco.com>
Date: Thursday, April 10, 2014 at 1= 0:20 PM
To: "scim@ietf.org" <scim@i= etf.org>
Subject: [scim] Consensus call on i= ssue #18 - patch semantics

In London we had a good discussion on patch operation (ticket #18) and= Phil provided background information and walked the WG through a few optio= ns. In follow on discussions on the mailing list, survey Phil sent out, and= the WG call we narrowed it down to two options.  Stay with the current patch semantics or change patc= h to a RFC6902-based model.

Phil has posted to the group the proposed text for 6902 =93based=94 pa= tch (and also documented in the tracker under issue #18).  The WG is m= aking a consensus call as follows:

A. Do not change patch semantics and stay with what is currently docum= ented in the spec
B. Adopt the 6902 based changes Phil has put together (as proposed on = the list and documented in tracker)
C. Don=92t care or need more information

Please provide your input before Apr. 18th.


Cheers,
Leif & Morteza
 --_000_CF71DAA0D5AF0moransarciscocom_-- From nobody Mon Apr 14 18:59:02 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 4646F1A0473 for ; Mon, 14 Apr 2014 18:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 rw7n9hrN96IL for ; Mon, 14 Apr 2014 18:58:57 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A1B861A0259 for ; Mon, 14 Apr 2014 18:58:57 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s3F1wrNG002750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Apr 2014 01:58:54 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 s3F1wr0W022620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Apr 2014 01:58:53 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3F1wrBP024612; Tue, 15 Apr 2014 01:58:53 GMT Received: from [192.168.1.3] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 Apr 2014 18:58:52 -0700 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-A1BF197E-6BE8-48CC-B478-8A2809B3B7CB Content-Transfer-Encoding: 7bit Message-Id: <981377AA-A923-4BD9-AEF1-B1170894942C@oracle.com> X-Mailer: iPhone Mail (11D167) From: Phil Hunt Date: Mon, 14 Apr 2014 18:58:49 -0700 To: "Morteza Ansari (moransar)" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/lUzNnnLDHcxP6Um2-RiFnFofx18 Cc: "scim@ietf.org" Subject: Re: [scim] Consensus call on issue #18 - patch semantics 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, 15 Apr 2014 01:59:00 -0000 --Apple-Mail-A1BF197E-6BE8-48CC-B478-8A2809B3B7CB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable My preference is B.=20 Phil > On Apr 14, 2014, at 18:35, "Morteza Ansari (moransar)" wrote: >=20 > Bump=E2=80=A6 Hard to imagine nobody in the WG has any thoughts on this t= opic :) >=20 >=20 > Cheers, > Morteza >=20 > From: Morteza Ansari > Date: Thursday, April 10, 2014 at 10:20 PM > To: "scim@ietf.org" > Subject: [scim] Consensus call on issue #18 - patch semantics >=20 > In London we had a good discussion on patch operation (ticket #18) and Phi= l provided background information and walked the WG through a few options. I= n follow on discussions on the mailing list, survey Phil sent out, and the W= G call we narrowed it down to two options. Stay with the current patch sema= ntics or change patch to a RFC6902-based model. >=20 > Phil has posted to the group the proposed text for 6902 =E2=80=9Cbased=E2=80= =9D patch (and also documented in the tracker under issue #18). The WG is m= aking a consensus call as follows: >=20 > A. Do not change patch semantics and stay with what is currently documente= d in the spec > B. Adopt the 6902 based changes Phil has put together (as proposed on the l= ist and documented in tracker) > C. Don=E2=80=99t care or need more information >=20 > Please provide your input before Apr. 18th. >=20 >=20 > Cheers, > Leif & Morteza > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-A1BF197E-6BE8-48CC-B478-8A2809B3B7CB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
My preference is B. 

Phil<= /div>

On Apr 14, 2014, at 18:35, "Morteza Ansari (moransar)" <moransar@cisco.com> wrote:

<= /div>
Bump=E2=80=A6  Hard to imagine nobody in the WG has any thoughts o= n this topic :)


Cheers,
Morteza

From: Morteza Ansari <moransar@cisco.com>
Date: Thursday, April 10, 2014 at 10= :20 PM
To: "scim@ietf.org" <scim@ietf.org&= gt;
Subject: [scim] Consensus call on is= sue #18 - patch semantics

In London we had a good discussion on patch operation (ticket #18) and P= hil provided background information and walked the WG through a few options.= In follow on discussions on the mailing list, survey Phil sent out, and the= WG call we narrowed it down to two options.  Stay with the current patch semantics or change patch= to a RFC6902-based model.

Phil has posted to the group the proposed text for 6902 =E2=80=9Cbased=E2= =80=9D patch (and also documented in the tracker under issue #18).  The= WG is making a consensus call as follows:

A. Do not change patch semantics and stay with what is currently docume= nted in the spec
B. Adopt the 6902 based changes Phil has put together (as proposed on t= he list and documented in tracker)
C. Don=E2=80=99t care or need more information

Please provide your input before Apr. 18th.


Cheers,
Leif & Morteza
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-A1BF197E-6BE8-48CC-B478-8A2809B3B7CB-- From nobody Tue Apr 15 02:45:34 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 681D01A03AE for ; Tue, 15 Apr 2014 02:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272, 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 yk66KTbMcIZ0 for ; Tue, 15 Apr 2014 02:45:29 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.120]) by ietfa.amsl.com (Postfix) with ESMTP id 354C91A0745 for ; Tue, 15 Apr 2014 02:45:24 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX01.ad.nexusgroup.com (10.75.28.40) with Microsoft SMTP Server (TLS) id 15.0.775.38; Tue, 15 Apr 2014 11:45:56 +0200 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; Tue, 15 Apr 2014 11:45:56 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] Consensus call on issue #18 - patch semantics Thread-Index: AQHPWEsJ/fXYjTnp/U2m0xskO1TxYZsRyl+AgACkCYA= Date: Tue, 15 Apr 2014 09:45:55 +0000 Message-ID: <32331FA2-C504-45C0-87F1-706F1FFA24E2@nexusgroup.com> References: , <981377AA-A923-4BD9-AEF1-B1170894942C@oracle.com> In-Reply-To: <981377AA-A923-4BD9-AEF1-B1170894942C@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_32331FA2C50445C087F1706F1FFA24E2nexusgroupcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/nDapLJoOUJA4ISyhmOVEcpCaXs0 Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" Subject: Re: [scim] Consensus call on issue #18 - patch semantics 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, 15 Apr 2014 09:45:33 -0000 --_000_32331FA2C50445C087F1706F1FFA24E2nexusgroupcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 on B. / Erik Sent from my iPad On 15 apr 2014, at 03:59, "Phil Hunt" > wrote: My preference is B. Phil On Apr 14, 2014, at 18:35, "Morteza Ansari (moransar)" > wrote: Bump... Hard to imagine nobody in the WG has any thoughts on this topic :) Cheers, Morteza From: Morteza Ansari > Date: Thursday, April 10, 2014 at 10:20 PM To: "scim@ietf.org" > Subject: [scim] Consensus call on issue #18 - patch semantics In London we had a good discussion on patch operation (ticket #18) and Phil= provided background information and walked the WG through a few options. I= n follow on discussions on the mailing list, survey Phil sent out, and the = WG call we narrowed it down to two options. Stay with the current patch se= mantics or change patch to a RFC6902-based model. Phil has posted to the group the proposed text for 6902 "based" patch (and = also documented in the tracker under issue #18). The WG is making a consen= sus call as follows: A. Do not change patch semantics and stay with what is currently documented= in the spec B. Adopt the 6902 based changes Phil has put together (as proposed on the l= ist and documented in tracker) C. Don't care or need more information Please provide your input before Apr. 18th. Cheers, Leif & Morteza _______________________________________________ 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 --_000_32331FA2C50445C087F1706F1FFA24E2nexusgroupcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
+1 on B.
/ Erik

Sent from my iPad

On 15 apr 2014, at 03:59, "Phil Hunt" <phil.hunt@oracle.com> wrote:

My preference is B. 

Phil

On Apr 14, 2014, at 18:35, "Morteza Ansari (moransar)" <moransar@cisco.com> wrote:

Bump…  Hard to imagine nobody in the WG has any thoughts on= this topic :)


Cheers,
Morteza

From: Morteza Ansari <moransar@cisco.com>
Date: Thursday, April 10, 2014 at 1= 0:20 PM
To: "scim@ietf.org" <scim@i= etf.org>
Subject: [scim] Consensus call on i= ssue #18 - patch semantics

In London we had a good discussion on patch operation (ticket #18) and= Phil provided background information and walked the WG through a few optio= ns. In follow on discussions on the mailing list, survey Phil sent out, and= the WG call we narrowed it down to two options.  Stay with the current patch semantics or change patc= h to a RFC6902-based model.

Phil has posted to the group the proposed text for 6902 “based&#= 8221; patch (and also documented in the tracker under issue #18).  The= WG is making a consensus call as follows:

A. Do not change patch semantics and stay with what is currently docum= ented in the spec
B. Adopt the 6902 based changes Phil has put together (as proposed on = the list and documented in tracker)
C. Don’t care or need more information

Please provide your input before Apr. 18th.


Cheers,
Leif & Morteza
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ie= tf.org/mailman/listinfo/scim
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ie= tf.org/mailman/listinfo/scim
--_000_32331FA2C50445C087F1706F1FFA24E2nexusgroupcom_-- From nobody Tue Apr 15 08:07:49 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 AD53C1A0451 for ; Tue, 15 Apr 2014 08:07:46 -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 KFnW9yCQZ8hT for ; Tue, 15 Apr 2014 08:07:44 -0700 (PDT) Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by ietfa.amsl.com (Postfix) with ESMTP id 61D421A02F5 for ; Tue, 15 Apr 2014 08:07:44 -0700 (PDT) Received: by mail-bk0-f43.google.com with SMTP id v15so3243702bkz.30 for ; Tue, 15 Apr 2014 08:07: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=vTz77zXnuVJvx3Z1ZISMR2OdSLCsovI8mmlqiydcE+E=; b=Zz/ANCx4QZKKzCV/L9s2XeD55NbvbYWGBH5DbF214R9X45vbXPUp9BmdwxtLHtbK2y /6lv7Yg2gqMxpJYTGGFOu+v3H7O8MUlpVmwL2CPNMe20meCkkKiZXIYYOlhvSTz6fYUX dY3faevNyumfskb+Nwj+LgtrP+5hc9V0CayRNMknQ35MOFC1kp2d3Atb/dBgfMmhjC3c CDeO6Jk837CT98Xu7UOdKEq0Jvs2Kgmm95r6uRHMs7iK+PpAYdcBYZXI+V2YmuIPY3zg R8myqPru5LUpm2F0uFCXiPThsAvckWiI6DC319CTYsz8xI4jZTm1ZJ/2kEae5NHji0ZS EiYg== X-Gm-Message-State: ALoCoQls/1fCf5uhorr1BvvG91etvQzv08Hg7x6eGzqjs1tNuLFM63RblVPzWaKX6sm7Yk38V6S7 X-Received: by 10.204.77.7 with SMTP id e7mr1766485bkk.7.1397574460736; Tue, 15 Apr 2014 08:07:40 -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 xk2sm20420309bkb.9.2014.04.15.08.07.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 08:07:39 -0700 (PDT) Message-ID: <534D4B3A.5030109@tarent.de> Date: Tue, 15 Apr 2014 17:07:38 +0200 From: =?ISO-8859-15?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 WG" 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/0KmTm4X2zhFdtM9I1MYP6d7Dd-w Subject: [scim] where to save the origin of an user 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, 15 Apr 2014 15:07:46 -0000 Hi, at the moment we want to provide an login with an LDAP server. At the initial login we wan to store the information that the user comes from LDAP. Now is the question if their is any standard scim field where we could store this information. We thought that we could use externalId for this but at the moment we don't think this is the correct field. At the moment we intent to create an extension and store this information in this extension. What do you think about our thoughts and do you have any good idear how to store the origin information. by David From nobody Tue Apr 15 09:19:22 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 27AB71A06C8 for ; Tue, 15 Apr 2014 09:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 dF8mG4Io23Xr for ; Tue, 15 Apr 2014 09:19:16 -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 E96381A067D for ; Tue, 15 Apr 2014 09:19:15 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id hr17so7128549lab.33 for ; Tue, 15 Apr 2014 09:19:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vbA/dGt+O3fyYEJPDlSuBnNKlKOm1lb+cw52Nz/lh9E=; b=Qn4/UYL43jZ2fkoa5aeqWUohdKrhjCMX/3J+HJQHo8Cu8RP/yl1ZZDKPNS6hHCKgZd GsFdnq62q5n+UMuP+7pgzVpBESKqdFHajD1y4o1HyF9L9WapuW4J9AAXUZ7d5eQeOC8X qItbLD9Tl/YdVm55e5lYCk5g4klF9Df3JhsawtXl0pHxkVZUpgp6Fhxag+c/i7zpqLUS Ke0V6Duw1kfKIka2LW8xrqTa79WOf5+dfxaNuBrsCVxw6tqmNiS4/PhCNbkVfeDgoBaV NJLCdDcCXqCKYYIF/fDATykfPf+pM4f4vldLatRjve72eNHaGGcSKBddc9zGGVNJ+dTO yDHQ== X-Gm-Message-State: ALoCoQlALZ7cv1LsX0Wlwf+ct51+HcYqF30g/9HJV263OUTg9rL/QzF61g2lWOaEh/qjTaVDmT2d MIME-Version: 1.0 X-Received: by 10.112.168.170 with SMTP id zx10mr1737192lbb.35.1397578752292; Tue, 15 Apr 2014 09:19:12 -0700 (PDT) Received: by 10.112.150.233 with HTTP; Tue, 15 Apr 2014 09:19:12 -0700 (PDT) In-Reply-To: <32331FA2-C504-45C0-87F1-706F1FFA24E2@nexusgroup.com> References: <981377AA-A923-4BD9-AEF1-B1170894942C@oracle.com> <32331FA2-C504-45C0-87F1-706F1FFA24E2@nexusgroup.com> Date: Tue, 15 Apr 2014 09:19:12 -0700 Message-ID: From: Melvin Laguren To: =?UTF-8?Q?Erik_Wahlstr=C3=B6m?= Content-Type: multipart/alternative; boundary=001a11c23c881388af04f71729cc Archived-At: http://mailarchive.ietf.org/arch/msg/scim/IS1nIooB7b7zptwv6vo_Mn1So2Y Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" , Phil Hunt Subject: Re: [scim] Consensus call on issue #18 - patch semantics 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, 15 Apr 2014 16:19:20 -0000 --001a11c23c881388af04f71729cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My vote is for B. On Tue, Apr 15, 2014 at 2:45 AM, Erik Wahlstr=C3=B6m < erik.wahlstrom@nexusgroup.com> wrote: > +1 on B. > / Erik > > Sent from my iPad > > On 15 apr 2014, at 03:59, "Phil Hunt" wrote: > > My preference is B. > > Phil > > On Apr 14, 2014, at 18:35, "Morteza Ansari (moransar)" > wrote: > > Bump=E2=80=A6 Hard to imagine nobody in the WG has any thoughts on thi= s topic > :) > > > Cheers, > Morteza > > From: Morteza Ansari > Date: Thursday, April 10, 2014 at 10:20 PM > To: "scim@ietf.org" > Subject: [scim] Consensus call on issue #18 - patch semantics > > In London we had a good discussion on patch operation (ticket #18) and > Phil provided background information and walked the WG through a few > options. In follow on discussions on the mailing list, survey Phil sent > out, and the WG call we narrowed it down to two options. Stay with the > current patch semantics or change patch to a RFC6902-based model. > > Phil has posted to the group the proposed text for 6902 =E2=80=9Cbased= =E2=80=9D patch > (and also documented in the tracker under issue #18). The WG is making a > consensus call as follows: > > A. Do not change patch semantics and stay with what is currently > documented in the spec > B. Adopt the 6902 based changes Phil has put together (as proposed on the > list and documented in tracker) > C. Don=E2=80=99t care or need more information > > Please provide your input before Apr. 18th. > > > Cheers, > Leif & Morteza > > _______________________________________________ > 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 > > --001a11c23c881388af04f71729cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My vote is for B.


=
On Tue, Apr 15, 2014 at 2:45 AM, Erik Wahlstr=C3= =B6m <erik.wahlstrom@nexusgroup.com> wrote:
+1 on B.
/ Erik

Sent from my iPad

On 15 apr 2014, at 03:59, "Phil Hunt" <phil.hunt@oracle.com> wrote:

My preference is B.=C2=A0

Phil

On Apr 14, 2014, at 18:35, "Morteza Ansari (moransar)" <moransar@cisco.com>= ; wrote:

Bump=E2=80=A6 =C2=A0Hard to imagine nobody in the WG has any thoughts = on this topic :)


Cheers,
Morteza

From: Morteza Ansari <moransar@cisco.com> Date: Thursday, April 10, 2014 at 1= 0:20 PM
To: "scim@ietf.org" <scim@ietf.org>
Subject: [scim] Consensus call on i= ssue #18 - patch semantics

In London we had a good discussion on patch operation (ticket #18) and= Phil provided background information and walked the WG through a few optio= ns. In follow on discussions on the mailing list, survey Phil sent out, and= the WG call we narrowed it down to two options. =C2=A0Stay with the current patch semantics or change patc= h to a RFC6902-based model.

Phil has posted to the group the proposed text for 6902 =E2=80=9Cbased= =E2=80=9D patch (and also documented in the tracker under issue #18). =C2= =A0The WG is making a consensus call as follows:

A. Do not change patch semantics and stay with what is currently docum= ented in the spec
B. Adopt the 6902 based changes Phil has put together (as proposed on = the list and documented in tracker)
C. Don=E2=80=99t care or need more information

Please provide your input before Apr. 18th.


Cheers,
Leif & Morteza
_______________________________________________
scim mailing list
scim@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/scim
_______________________________________________
scim mailing list
scim@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/scim

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


--001a11c23c881388af04f71729cc-- From nobody Wed Apr 16 05:53:08 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 A0C271A016A for ; Wed, 16 Apr 2014 05:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 JJ8mXfawPW6e for ; Wed, 16 Apr 2014 05:53:02 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id D3CBA1A0173 for ; Wed, 16 Apr 2014 05:52:14 -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.918.8; Wed, 16 Apr 2014 12:52:10 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.175]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.175]) with mapi id 15.00.0918.000; Wed, 16 Apr 2014 12:52:09 +0000 From: Kelly Grizzle To: Melvin Laguren , =?utf-8?B?RXJpayBXYWhsc3Ryw7Zt?= Thread-Topic: [scim] Consensus call on issue #18 - patch semantics Thread-Index: AQHPWEsJ/fXYjTnp/U2m0xskO1TxYZsR6+aAgACCgYCAAG3iAIABWHdg Date: Wed, 16 Apr 2014 12:52:08 +0000 Message-ID: References: <981377AA-A923-4BD9-AEF1-B1170894942C@oracle.com> <32331FA2-C504-45C0-87F1-706F1FFA24E2@nexusgroup.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.182.10.254] x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(377454003)(189002)(199002)(24454002)(5383001)(87936001)(81542001)(2656002)(99286001)(83072002)(85852003)(15202345003)(74316001)(19609705001)(99396002)(19300405004)(76482001)(15975445006)(81342001)(80022001)(76576001)(83322001)(79102001)(66066001)(77982001)(86362001)(33646001)(4396001)(46102001)(50986999)(92566001)(80976001)(74662001)(19580405001)(54356999)(74502001)(76176999)(16236675002)(20776003)(19580395003)(31966008)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:9B8E69B4.AFC79FC1.36E3B3E3.56DEDB00.202C0; 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_f35f1ff5ddde4451b941017f04eaa341BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/-UUWYCJIq3IGp2PdAzkaEWaeeC8 Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" , Phil Hunt Subject: Re: [scim] Consensus call on issue #18 - patch semantics 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, 16 Apr 2014 12:53:06 -0000 --_000_f35f1ff5ddde4451b941017f04eaa341BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIGIuDQoNCkZyb206IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBNZWx2aW4gTGFndXJlbg0KU2VudDogVHVlc2RheSwgQXByaWwgMTUsIDIwMTQg MTE6MTkgQU0NClRvOiBFcmlrIFdhaGxzdHLDtm0NCkNjOiBzY2ltQGlldGYub3JnOyBNb3J0ZXph IEFuc2FyaSAobW9yYW5zYXIpOyBQaGlsIEh1bnQNClN1YmplY3Q6IFJlOiBbc2NpbV0gQ29uc2Vu c3VzIGNhbGwgb24gaXNzdWUgIzE4IC0gcGF0Y2ggc2VtYW50aWNzDQoNCk15IHZvdGUgaXMgZm9y IEIuDQoNCk9uIFR1ZSwgQXByIDE1LCAyMDE0IGF0IDI6NDUgQU0sIEVyaWsgV2FobHN0csO2bSA8 ZXJpay53YWhsc3Ryb21AbmV4dXNncm91cC5jb208bWFpbHRvOmVyaWsud2FobHN0cm9tQG5leHVz Z3JvdXAuY29tPj4gd3JvdGU6DQorMSBvbiBCLg0KLyBFcmlrDQoNClNlbnQgZnJvbSBteSBpUGFk DQoNCk9uIDE1IGFwciAyMDE0LCBhdCAwMzo1OSwgIlBoaWwgSHVudCIgPHBoaWwuaHVudEBvcmFj bGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KTXkgcHJlZmVyZW5j ZSBpcyBCLg0KDQpQaGlsDQoNCk9uIEFwciAxNCwgMjAxNCwgYXQgMTg6MzUsICJNb3J0ZXphIEFu c2FyaSAobW9yYW5zYXIpIiA8bW9yYW5zYXJAY2lzY28uY29tPG1haWx0bzptb3JhbnNhckBjaXNj by5jb20+PiB3cm90ZToNCkJ1bXDigKYgIEhhcmQgdG8gaW1hZ2luZSBub2JvZHkgaW4gdGhlIFdH IGhhcyBhbnkgdGhvdWdodHMgb24gdGhpcyB0b3BpYyA6KQ0KDQoNCkNoZWVycywNCk1vcnRlemEN Cg0KRnJvbTogTW9ydGV6YSBBbnNhcmkgPG1vcmFuc2FyQGNpc2NvLmNvbTxtYWlsdG86bW9yYW5z YXJAY2lzY28uY29tPj4NCkRhdGU6IFRodXJzZGF5LCBBcHJpbCAxMCwgMjAxNCBhdCAxMDoyMCBQ TQ0KVG86ICJzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPiIgPHNjaW1AaWV0Zi5v cmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3NjaW1dIENvbnNlbnN1cyBjYWxs IG9uIGlzc3VlICMxOCAtIHBhdGNoIHNlbWFudGljcw0KDQpJbiBMb25kb24gd2UgaGFkIGEgZ29v ZCBkaXNjdXNzaW9uIG9uIHBhdGNoIG9wZXJhdGlvbiAodGlja2V0ICMxOCkgYW5kIFBoaWwgcHJv dmlkZWQgYmFja2dyb3VuZCBpbmZvcm1hdGlvbiBhbmQgd2Fsa2VkIHRoZSBXRyB0aHJvdWdoIGEg ZmV3IG9wdGlvbnMuIEluIGZvbGxvdyBvbiBkaXNjdXNzaW9ucyBvbiB0aGUgbWFpbGluZyBsaXN0 LCBzdXJ2ZXkgUGhpbCBzZW50IG91dCwgYW5kIHRoZSBXRyBjYWxsIHdlIG5hcnJvd2VkIGl0IGRv d24gdG8gdHdvIG9wdGlvbnMuICBTdGF5IHdpdGggdGhlIGN1cnJlbnQgcGF0Y2ggc2VtYW50aWNz IG9yIGNoYW5nZSBwYXRjaCB0byBhIFJGQzY5MDItYmFzZWQgbW9kZWwuDQoNClBoaWwgaGFzIHBv c3RlZCB0byB0aGUgZ3JvdXAgdGhlIHByb3Bvc2VkIHRleHQgZm9yIDY5MDIg4oCcYmFzZWTigJ0g cGF0Y2ggKGFuZCBhbHNvIGRvY3VtZW50ZWQgaW4gdGhlIHRyYWNrZXIgdW5kZXIgaXNzdWUgIzE4 KS4gIFRoZSBXRyBpcyBtYWtpbmcgYSBjb25zZW5zdXMgY2FsbCBhcyBmb2xsb3dzOg0KDQpBLiBE byBub3QgY2hhbmdlIHBhdGNoIHNlbWFudGljcyBhbmQgc3RheSB3aXRoIHdoYXQgaXMgY3VycmVu dGx5IGRvY3VtZW50ZWQgaW4gdGhlIHNwZWMNCkIuIEFkb3B0IHRoZSA2OTAyIGJhc2VkIGNoYW5n ZXMgUGhpbCBoYXMgcHV0IHRvZ2V0aGVyIChhcyBwcm9wb3NlZCBvbiB0aGUgbGlzdCBhbmQgZG9j dW1lbnRlZCBpbiB0cmFja2VyKQ0KQy4gRG9u4oCZdCBjYXJlIG9yIG5lZWQgbW9yZSBpbmZvcm1h dGlvbg0KDQpQbGVhc2UgcHJvdmlkZSB5b3VyIGlucHV0IGJlZm9yZSBBcHIuIDE4dGguDQoNCg0K Q2hlZXJzLA0KTGVpZiAmIE1vcnRlemENCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpzY2ltIG1haWxpbmcgbGlzdA0Kc2NpbUBpZXRmLm9yZzxtYWlsdG86 c2NpbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Np bQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0g bWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzY2ltIG1haWxpbmcgbGlzdA0Kc2NpbUBp ZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2NpbQ0KDQo= --_000_f35f1ff5ddde4451b941017f04eaa341BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0MzsxIGZvciBiLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2NpbSBbbWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWVsdmluIExhZ3VyZW48YnI+DQo8Yj5TZW50OjwvYj4g VHVlc2RheSwgQXByaWwgMTUsIDIwMTQgMTE6MTkgQU08YnI+DQo8Yj5Ubzo8L2I+IEVyaWsgV2Fo bHN0csO2bTxicj4NCjxiPkNjOjwvYj4gc2NpbUBpZXRmLm9yZzsgTW9ydGV6YSBBbnNhcmkgKG1v cmFuc2FyKTsgUGhpbCBIdW50PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2NpbV0gQ29uc2Vu c3VzIGNhbGwgb24gaXNzdWUgIzE4IC0gcGF0Y2ggc2VtYW50aWNzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgdm90ZSBpcyBmb3IgQi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVHVlLCBBcHIgMTUsIDIwMTQgYXQgMjo0NSBBTSwgRXJpayBXYWhsc3Ryw7ZtICZsdDs8YSBo cmVmPSJtYWlsdG86ZXJpay53YWhsc3Ryb21AbmV4dXNncm91cC5jb20iIHRhcmdldD0iX2JsYW5r Ij5lcmlrLndhaGxzdHJvbUBuZXh1c2dyb3VwLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgb24gQi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi8gRXJpazxi cj4NCjxicj4NClNlbnQgZnJvbSBteSBpUGFkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KT24gMTUgYXByIDIwMTQsIGF0IDAzOjU5LCAmcXVvdDtQaGlsIEh1bnQm cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBwcmVmZXJl bmNlIGlzIEIuJm5ic3A7PGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQpPbiBBcHIgMTQsIDIwMTQsIGF0IDE4OjM1LCAmcXVvdDtNb3J0ZXphIEFuc2FyaSAobW9y YW5zYXIpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW9yYW5zYXJAY2lzY28uY29tIiB0YXJn ZXQ9Il9ibGFuayI+bW9yYW5zYXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdW1w4oCm ICZuYnNwO0hhcmQgdG8gaW1hZ2luZSBub2JvZHkgaW4gdGhlIFdHIGhhcyBhbnkgdGhvdWdodHMg b24gdGhpcyB0b3BpYyA6KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk1vcnRlemE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+TW9ydGV6YSBBbnNhcmkgJmx0OzxhIGhyZWY9Im1haWx0bzptb3JhbnNhckBjaXNj by5jb20iIHRhcmdldD0iX2JsYW5rIj5tb3JhbnNhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxi PkRhdGU6IDwvYj5UaHVyc2RheSwgQXByaWwgMTAsIDIwMTQgYXQgMTA6MjAgUE08YnI+DQo8Yj5U bzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+c2NpbUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPltzY2ltXSBDb25zZW5zdXMgY2FsbCBvbiBpc3N1ZSAjMTggLSBwYXRjaCBzZW1hbnRp Y3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JbiBMb25k b24gd2UgaGFkIGEgZ29vZCBkaXNjdXNzaW9uIG9uIHBhdGNoIG9wZXJhdGlvbiAodGlja2V0ICMx OCkgYW5kIFBoaWwgcHJvdmlkZWQgYmFja2dyb3VuZCBpbmZvcm1hdGlvbiBhbmQgd2Fsa2VkIHRo ZSBXRyB0aHJvdWdoIGEgZmV3IG9wdGlvbnMuIEluIGZvbGxvdyBvbiBkaXNjdXNzaW9ucw0KIG9u IHRoZSBtYWlsaW5nIGxpc3QsIHN1cnZleSBQaGlsIHNlbnQgb3V0LCBhbmQgdGhlIFdHIGNhbGwg d2UgbmFycm93ZWQgaXQgZG93biB0byB0d28gb3B0aW9ucy4gJm5ic3A7U3RheSB3aXRoIHRoZSBj dXJyZW50IHBhdGNoIHNlbWFudGljcyBvciBjaGFuZ2UgcGF0Y2ggdG8gYSBSRkM2OTAyLWJhc2Vk IG1vZGVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5QaGlsIGhhcyBwb3N0ZWQgdG8gdGhlIGdyb3VwIHRoZSBwcm9w b3NlZCB0ZXh0IGZvciA2OTAyIOKAnGJhc2Vk4oCdIHBhdGNoIChhbmQgYWxzbyBkb2N1bWVudGVk IGluIHRoZSB0cmFja2VyIHVuZGVyIGlzc3VlICMxOCkuICZuYnNwO1RoZSBXRyBpcyBtYWtpbmcg YSBjb25zZW5zdXMgY2FsbCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BLiBEbyBub3QgY2hhbmdl IHBhdGNoIHNlbWFudGljcyBhbmQgc3RheSB3aXRoIHdoYXQgaXMgY3VycmVudGx5IGRvY3VtZW50 ZWQgaW4gdGhlIHNwZWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkIuIEFkb3B0IHRo ZSA2OTAyIGJhc2VkIGNoYW5nZXMgUGhpbCBoYXMgcHV0IHRvZ2V0aGVyIChhcyBwcm9wb3NlZCBv biB0aGUgbGlzdCBhbmQgZG9jdW1lbnRlZCBpbiB0cmFja2VyKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Qy4gRG9u4oCZdCBjYXJlIG9yIG5lZWQgbW9yZSBpbmZvcm1hdGlvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5QbGVhc2UgcHJvdmlkZSB5b3VyIGlucHV0IGJlZm9yZSBBcHIuIDE4dGguPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2hlZXJzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TGVpZiAmYW1wOyBNb3J0ZXphPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNjaW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Np bSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2NpbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNjaW0gbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2lt QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2NpbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2NpbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnNjaW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_f35f1ff5ddde4451b941017f04eaa341BN1PR04MB392namprd04pro_-- From nobody Wed Apr 16 07:16:49 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 6C1481A01D9 for ; Wed, 16 Apr 2014 07:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 w2WfRkRIyxRO for ; Wed, 16 Apr 2014 07:16:46 -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 8B88C1A01B2 for ; Wed, 16 Apr 2014 07:16:45 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.0.918.8; Wed, 16 Apr 2014 14:16:33 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.175]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.175]) with mapi id 15.00.0918.000; Wed, 16 Apr 2014 14:16:33 +0000 From: Kelly Grizzle To: =?iso-8859-1?Q?David_M=F6bius?= , "scim@ietf.org WG" Thread-Topic: [scim] where to save the origin of an user Thread-Index: AQHPWLx5hcvByu+R3kSMNiEEOzXBa5sUS1cQ Date: Wed, 16 Apr 2014 14:16:33 +0000 Message-ID: <55cd9517d8e3474189109f5513aad093@BN1PR04MB392.namprd04.prod.outlook.com> References: <534D4B3A.5030109@tarent.de> In-Reply-To: <534D4B3A.5030109@tarent.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.182.10.254] x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51444003)(199002)(189002)(13464003)(377454003)(76104003)(80976001)(19580405001)(19580395003)(99286001)(83322001)(92566001)(99396002)(54356999)(83072002)(76176999)(31966008)(74662001)(74316001)(2656002)(87936001)(86362001)(15975445006)(50986999)(85852003)(74502001)(20776003)(80022001)(76576001)(46102001)(79102001)(77982001)(33646001)(81542001)(66066001)(4396001)(76482001)(81342001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:B4DEC922.97BB5ED2.3DDBBFBF.8C65D2EA.2018D; 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/kOA9yG07ekHrVYkkDCVs2eT2nPs Subject: Re: [scim] where to save the origin of an user 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, 16 Apr 2014 14:16:48 -0000 David ... I think that an extension is probably the correct place to store = this information. --Kelly -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of David M=F6bius Sent: Tuesday, April 15, 2014 10:08 AM To: scim@ietf.org WG Subject: [scim] where to save the origin of an user Hi, at the moment we want to provide an login with an LDAP server. At the initi= al login we wan to store the information that the user comes from LDAP. Now= is the question if their is any standard scim field where we could store t= his information. We thought that we could use externalId for this but at the moment we don't= think this is the correct field. At the moment we intent to create an extension and store this information i= n this extension. What do you think about our thoughts and do you have any good idear how to = store the origin information. by David _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From nobody Wed Apr 16 09:43:50 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 20D9C1A0243 for ; Wed, 16 Apr 2014 09:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 vsBLMgjfOMwg for ; Wed, 16 Apr 2014 09:43:42 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id CFDD41A019B for ; Wed, 16 Apr 2014 09:43:41 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s3GGhbJi028768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 16 Apr 2014 16:43:38 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3GGhbcB004777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Apr 2014 16:43:37 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3GGhbvv004768 for ; Wed, 16 Apr 2014 16:43:37 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Apr 2014 09:43:37 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_8076370E-8889-4E80-941B-35677C18915E" Message-Id: <0C5F84EE-70F2-4F34-A94E-DB16F472F21F@oracle.com> Date: Wed, 16 Apr 2014 09:43:36 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/pDkgb3_od91AxbHCGc5I6EGM6vE Subject: [scim] Ticket 36 - Proper JSON representation of Complex Multi-valued Attrs (Addresses, Groups, eMails) 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, 16 Apr 2014 16:43:47 -0000 --Apple-Mail=_8076370E-8889-4E80-941B-35677C18915E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Erik has raised an interesting issue with regards to how Addresses is = represented in Ticket 36.=20 Please consider the following below and indicate your preference for A = (current) or B (revised). Commentary is welcome. Depending on A or B we = should apply the format to any multi-valued complex attribute = representation. =20 Regardless of the decision, I think some updates to the core schema = documents are required. Thanks=85 Phil Discussion: Address is supposed to be a multi-valued attribute. That means it is = supposed to have 3 sub-attributes: primary, type, and value. However, = Address is also a complex attribute.=20 When this happens there are two JSON representations that appear legit = (well it is debatable at least), we need to pick one: A. Current Compact representation:=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" } ] B. Proposed corrected representation: "addresses": [ { "type": "work", "primary": true, "value":=20 { "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA" } }, { "type": "home", "value":=20 { "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" } } ], Notice that this second representation appears to be more correct = because the =93value=94 is the complex attribute portion. One problem with =93B" is that =93value=94 can=92t be can=92t be = compared. My thought is we should stick with =93A=94 and stipulate the = =93value=94 should represent the default or primary attribute. Other = impacted schema items include: mail, groups, etc. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_8076370E-8889-4E80-941B-35677C18915E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Erik = has raised an interesting issue with regards to how Addresses is = represented in Ticket 36. 

Please consider = the following below and indicate your preference for A (current) or B = (revised).  Commentary is welcome. Depending on A or B we = should apply the format to any multi-valued complex attribute = representation.  

Regardless of the = decision, I think some updates to the core schema documents are = required.

Thanks=85 = Phil

Discussion:

Address = is supposed to be a multi-valued attribute. That means it is supposed to = have 3 sub-attributes:  primary, type, and value.  However, = Address is also a complex attribute. 

When = this happens there are two JSON representations that appear legit (well = it is debatable at least), we need to pick = one:

A. Current Compact = representation: 

"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"

}

]


B. Proposed corrected = representation:

"addresses": [

{

"type": "work",
"primary": = true,
"value": 

{

"str= eetAddress": "100 Universal City Plaza",
"locality": = "Hollywood",
"region": "CA",
"postalCode": "91608",
"country": = "USA",
"formatted": "100 Universal City Plaza\nHollywood, CA 91608 = USA"

}

},
{<= br>

"type": = "home",
"value": 

{

"s= treetAddress": "456 Hollywood Blvd",
"locality": = "Hollywood",
"region": "CA",
"postalCode": "91608",
"country": = "USA",
"formatted": "456 Hollywood Blvd\nHollywood, CA 91608 = USA"

}

}

],

Notice that this second representation = appears to be more correct because the =93value=94 is the complex = attribute portion.

One problem with = =93B" is that =93value=94 can=92t be can=92t be compared. My thought is = we should stick with =93A=94 and stipulate the =93value=94 should = represent the default or primary attribute. Other impacted schema items = include:  mail, groups, etc.

Phil

@independentid
phil.hunt@oracle.com



= --Apple-Mail=_8076370E-8889-4E80-941B-35677C18915E-- From nobody Wed Apr 16 09:55:24 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 4D8741A0250 for ; Wed, 16 Apr 2014 09:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 FeZX2seT6lBn for ; Wed, 16 Apr 2014 09:55:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 74F1B1A023D for ; Wed, 16 Apr 2014 09:55:21 -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.918.8; Wed, 16 Apr 2014 16:55:10 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.175]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.175]) with mapi id 15.00.0918.000; Wed, 16 Apr 2014 16:55:10 +0000 From: Kelly Grizzle To: Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Ticket 36 - Proper JSON representation of Complex Multi-valued Attrs (Addresses, Groups, eMails) Thread-Index: AQHPWZMK8z0JItI5iUKiD/c/cyUyJ5sUdb7A Date: Wed, 16 Apr 2014 16:55:09 +0000 Message-ID: References: <0C5F84EE-70F2-4F34-A94E-DB16F472F21F@oracle.com> In-Reply-To: <0C5F84EE-70F2-4F34-A94E-DB16F472F21F@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [208.54.70.236] x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(189002)(199002)(377454003)(74316001)(85852003)(20776003)(79102001)(31966008)(33646001)(76576001)(99396002)(74662001)(50986999)(99286001)(83072002)(81542001)(16236675002)(87936001)(80022001)(76482001)(15975445006)(77982001)(16601075003)(81342001)(80976001)(19609705001)(74502001)(54356999)(19300405004)(76176999)(92566001)(2656002)(4396001)(19580395003)(46102001)(15202345003)(86362001)(19580405001)(83322001)(66066001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB390; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:ACCED9DD.8EF277EA.31DDBFB3.44EDA94D.20326; 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_e87d528a99714001bbda9a119f09000bBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/nC_d8prjellXTD40le_tXD6uXHU Subject: Re: [scim] Ticket 36 - Proper JSON representation of Complex Multi-valued Attrs (Addresses, Groups, eMails) 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, 16 Apr 2014 16:55:24 -0000 --_000_e87d528a99714001bbda9a119f09000bBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for A. The spec makes it clear that value is an optional sub-attribute for complex= multi-valued attributes. I agree that this should be removed from the "addresses" description: "The = value attribute is a complex type with the following sub-attributes." --Kelly From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, April 16, 2014 11:44 AM To: scim@ietf.org WG Subject: [scim] Ticket 36 - Proper JSON representation of Complex Multi-val= ued Attrs (Addresses, Groups, eMails) Erik has raised an interesting issue with regards to how Addresses is repre= sented in Ticket 36. Please consider the following below and indicate your preference for A (cur= rent) or B (revised). Commentary is welcome. Depending on A or B we should= apply the format to any multi-valued complex attribute representation. Regardless of the decision, I think some updates to the core schema documen= ts are required. Thanks... Phil Discussion: Address is supposed to be a multi-valued attribute. That means it is suppos= ed to have 3 sub-attributes: primary, type, and value. However, Address i= s also a complex attribute. When this happens there are two JSON representations that appear legit (wel= l it is debatable at least), we need to pick one: A. Current Compact representation: "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" } ] B. Proposed corrected representation: "addresses": [ { "type": "work", "primary": true, "value": { "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA" } }, { "type": "home", "value": { "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" } } ], Notice that this second representation appears to be more correct because t= he "value" is the complex attribute portion. One problem with "B" is that "value" can't be can't be compared. My thought= is we should stick with "A" and stipulate the "value" should represent the= default or primary attribute. Other impacted schema items include: mail, = groups, etc. Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_e87d528a99714001bbda9a119f09000bBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 for A.<= /span>

 <= /p>

The spec makes it clear t= hat value is an optional sub-attribute for complex multi-valued attributes.=

 <= /p> 

I agree =
that this should be removed from the “addresses” description: &=
#8220;The value attribu=
te is a complex type with the following =
sub-attributes.”

 <= /p>

--Kelly=

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, April 16, 2014 11:44 AM
To: scim@ietf.org WG
Subject: [scim] Ticket 36 - Proper JSON representation of Complex Mu= lti-valued Attrs (Addresses, Groups, eMails)

 

Erik has raised an interesting issue with regards to= how Addresses is represented in Ticket 36. 

 

Please consider the following below and indica= te your preference for A (current) or B (revised).  Commentary is welcome. Depending on A or B we should apply th= e format to any multi-valued complex attribute representation.  <= /o:p>

 

Regardless of the decision, I think some updates to = the core schema documents are required.

 

Thanks… Phil

 

Discussion:

 

Address is supposed to be a multi-valued attribute. = That means it is supposed to have 3 sub-attributes:  primary, type, an= d value.  However, Address is also a complex attribute. 

 

When this happens there are two JSON representations= that appear legit (well it is debatable at least), we need to pick one:

 

A. Current Compact representation: =

"addr= esses": [

{

"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&qu= ot;

}

]

 

B. Proposed corrected r= epresentation:

"addresses": [

{

"type": "work",
"primary": true,
"value": 

{

"streetAddress": "100 Universal City Plaza",
"locality": "Hollywood",
"region": "CA",
"postalCode": "91608",
"country": "USA",
"formatted": "100 Universal City Plaza\nHollywood, CA 91608 = USA"

}

},
{

"type": "home",
"value": 

{

"streetAddress": "456 Hollywood Blvd",
"locality": "Hollywood",
"region": "CA",
"postalCode": "91608",
"country": "USA",
"formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA&qu= ot;

}

}

],

Notice that this second re= presentation appears to be more correct because the “value” is = the complex attribute portion.

 

One problem with “B&= quot; is that “value” can’t be can’t be compared. M= y thought is we should stick with “A” and stipulate the “= value” should represent the default or primary attribute. Other impacted schema items include:  mail, gro= ups, etc.

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

--_000_e87d528a99714001bbda9a119f09000bBN1PR04MB392namprd04pro_-- From nobody Wed Apr 16 10:51:37 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 A813E1A01AC for ; Wed, 16 Apr 2014 10:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.47 X-Spam-Level: X-Spam-Status: No, score=-4.47 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 yTT2RvRl5a0A for ; Wed, 16 Apr 2014 10:51:29 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E951C1A0299 for ; Wed, 16 Apr 2014 10:51:28 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 42CF01F0726 for ; Wed, 16 Apr 2014 13:51:25 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 25E821F06C6 for ; Wed, 16 Apr 2014 13:51:25 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Wed, 16 Apr 2014 13:51:24 -0400 From: "Natale, Bob" To: "scim@ietf.org WG" Thread-Topic: [scim] Ticket 36 - Proper JSON representation of Complex Multi-valued Attrs (Addresses, Groups, eMails) Thread-Index: AQHPWZMJISBJGndJek6bdviOIEiXZpsUuSeA///MibA= Date: Wed, 16 Apr 2014 17:51:24 +0000 Message-ID: References: <0C5F84EE-70F2-4F34-A94E-DB16F472F21F@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.54] Content-Type: multipart/alternative; boundary="_000_A65E21691881E64DBF058A66E53068ED4C66F0EBIMCMBX01MITREOR_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/bVlirBS_-U_bLoHs05KxzcBMOXk Subject: Re: [scim] Ticket 36 - Proper JSON representation of Complex Multi-valued Attrs (Addresses, Groups, eMails) 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, 16 Apr 2014 17:51:33 -0000 --_000_A65E21691881E64DBF058A66E53068ED4C66F0EBIMCMBX01MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for A. Avanti, BobN From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Kelly Grizzle Sent: Wednesday, April 16, 2014 12:55 PM To: Phil Hunt; scim@ietf.org WG Subject: Re: [scim] Ticket 36 - Proper JSON representation of Complex Multi= -valued Attrs (Addresses, Groups, eMails) +1 for A. The spec makes it clear that value is an optional sub-attribute for complex= multi-valued attributes. I agree that this should be removed from the "addresses" description: "The = value attribute is a complex type with the following sub-attributes." --Kelly From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, April 16, 2014 11:44 AM To: scim@ietf.org WG Subject: [scim] Ticket 36 - Proper JSON representation of Complex Multi-val= ued Attrs (Addresses, Groups, eMails) Erik has raised an interesting issue with regards to how Addresses is repre= sented in Ticket 36. Please consider the following below and indicate your preference for A (cur= rent) or B (revised). Commentary is welcome. Depending on A or B we should= apply the format to any multi-valued complex attribute representation. Regardless of the decision, I think some updates to the core schema documen= ts are required. Thanks... Phil Discussion: Address is supposed to be a multi-valued attribute. That means it is suppos= ed to have 3 sub-attributes: primary, type, and value. However, Address i= s also a complex attribute. When this happens there are two JSON representations that appear legit (wel= l it is debatable at least), we need to pick one: A. Current Compact representation: "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" } ] B. Proposed corrected representation: "addresses": [ { "type": "work", "primary": true, "value": { "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA" } }, { "type": "home", "value": { "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" } } ], Notice that this second representation appears to be more correct because t= he "value" is the complex attribute portion. One problem with "B" is that "value" can't be can't be compared. My thought= is we should stick with "A" and stipulate the "value" should represent the= default or primary attribute. Other impacted schema items include: mail, = groups, etc. Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_A65E21691881E64DBF058A66E53068ED4C66F0EBIMCMBX01MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 for A.<= /span>

 <= /p>

Avanti,=

BobN

 <= /p>

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Kelly Grizzle
Sent: Wednesday, April 16, 2014 12:55 PM
To: Phil Hunt; scim@ietf.org WG
Subject: Re: [scim] Ticket 36 - Proper JSON representation of Comple= x Multi-valued Attrs (Addresses, Groups, eMails)

 

I agree that this should be removed from the “addresses̶= 1; description: “= The value attribute is a complex type wi= th the following sub-attributes.”

From: scim [mailto:sc= im-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, April 16, 2014 11:44 AM
To: scim@ietf.org WG
Subject: [scim] Ticket 36 - Proper JSON representation of Complex Mu= lti-valued Attrs (Addresses, Groups, eMails)

 

Erik has raised an intere= sting issue with regards to how Addresses is represented in Ticket 36. = ;

 

Please consider the= following below and indicate your preference for A (current) or B (revised= ).  Commentary is welcome. Depending on A or B we should apply th= e format to any multi-valued complex attribute representation.  <= /o:p>

 

Regardless of the decisio= n, I think some updates to the core schema documents are required.

 

Thanks… Phil

 

Discussion:

 

Address is supposed to be= a multi-valued attribute. That means it is supposed to have 3 sub-attribut= es:  primary, type, and value.  However, Address is also a comple= x attribute. 

 

When this happens there a= re two JSON representations that appear legit (well it is debatable at leas= t), we need to pick one:

 

A. Current Compact rep= resentation: 

"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&qu= ot;

}

]

 

B. Proposed corrected representation:

"addresses": [=

{

"type": "work",
"primary": true,
"value": 

{

"streetAddress": "100 Universal City Plaz= a",
"locality": "Hollywood",
"region": "CA",
"postalCode": "91608",
"country": "USA",
"formatted": "100 Universal City Plaza\nHollywood, CA 91608 = USA"

}

},
{

"type": "home",
"value": 

{

"streetAddress": "456 Hollywood Blvd"= ;,
"locality": "Hollywood",
"region": "CA",
"postalCode": "91608",
"country": "USA",
"formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA&qu= ot;

}

}

],

Notice that this second representation appears to be more correct because = the “value” is the complex attribute portion.=

 

One problem with “B" is that “value” can’t be= can’t be compared. My thought is we should stick with “A”= ; and stipulate the “value” should represent the default or primary attribute. Other impacted schema items in= clude:  mail, groups, etc.

 

Phil

 

@independentid

phil.hunt@oracle.com

 

 

 

--_000_A65E21691881E64DBF058A66E53068ED4C66F0EBIMCMBX01MITREOR_-- From nobody Wed Apr 16 11:02:54 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 11E141A0173 for ; Wed, 16 Apr 2014 11:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 24CQxvgdZrkL for ; Wed, 16 Apr 2014 11:02:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) by ietfa.amsl.com (Postfix) with ESMTP id 5053E1A0160 for ; Wed, 16 Apr 2014 11:02:43 -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.918.8; Wed, 16 Apr 2014 18:02:38 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.175]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.175]) with mapi id 15.00.0918.000; Wed, 16 Apr 2014 18:02:38 +0000 From: Kelly Grizzle To: "scim@ietf.org" Thread-Topic: Webex for today's meeting? Thread-Index: Ac9ZngDtodjJsDCnTx2IM2a9aLhhCA== Date: Wed, 16 Apr 2014 18:02:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [208.54.70.236] x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(74316001)(85852003)(20776003)(79102001)(558084003)(31966008)(33646001)(76576001)(99396002)(74662001)(50986999)(99286001)(83072002)(81542001)(16236675002)(87936001)(80022001)(76482001)(15975445006)(77982001)(81342001)(80976001)(19609705001)(74502001)(54356999)(19300405004)(92566001)(2656002)(4396001)(19580395003)(46102001)(15202345003)(86362001)(83322001)(66066001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB390; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:BD14D439.A071879E.46E30C7C.10CDF720.2003A; 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_dc5034e92129473085627f32cf89035aBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/UhaT7eZ-p-L_2UUdLl0nOL3FLxw Subject: [scim] Webex for today's meeting? 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, 16 Apr 2014 18:02:46 -0000 --_000_dc5034e92129473085627f32cf89035aBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm having trouble getting on the webex. Could someone send out the info? --Kelly --_000_dc5034e92129473085627f32cf89035aBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m having trouble getting on the webex. = Could someone send out the info?

 

--Kelly

--_000_dc5034e92129473085627f32cf89035aBN1PR04MB392namprd04pro_-- From nobody Wed Apr 16 12:20:08 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 E1C501A02E8 for ; Wed, 16 Apr 2014 12:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 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.272, 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 PMZchq0dj9n2 for ; Wed, 16 Apr 2014 12:20:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6978B1A02CF for ; Wed, 16 Apr 2014 12:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17474; q=dns/txt; s=iport; t=1397675998; x=1398885598; h=from:to:subject:date:message-id:mime-version; bh=NehQSL00vztQMwUvXwLFQeDN1LYohZe+Cfaq+I3X00o=; b=UGh0qVm0KoosWF3i2zi2o99PPJ4jRsLKZUpBOi7xN2Ux0Tw3BxpuEQSB xV8dTTksgQTLd1IxP7nDm8XDKGNiUKjuQsauzhaoMk/I8hZ3V6P5pxbSj 9dKqQsyJCRlh13DeFjGp7vc7sASJQiqAPurhdTEQHVIl01ImRmPc4BMET 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAL7WTlOtJA2I/2dsb2JhbAA/FwOCQkQ7V8M1gSMWdIIlAQICAi0oEyMBCAcKAwECFQQMAzkUCQcDAQMBEod8DTaqO55jF44eMwEMHAeEIASFNpMwkkmCXlOCKw X-IronPort-AV: E=Sophos;i="4.97,873,1389744000"; d="scan'208,217";a="318260141" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP; 16 Apr 2014 19:19:58 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3GJJvPR015537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 19:19:57 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.226]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 14:19:57 -0500 From: "Morteza Ansari (moransar)" To: Kelly Grizzle , "scim@ietf.org" Thread-Topic: [scim] Webex for today's meeting? Thread-Index: AQHPWajaJbtB1QasXEioEo0D99XVKw== Date: Wed, 16 Apr 2014 19:19:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.80.87] Content-Type: multipart/alternative; boundary="_000_CF7425A6D5F6Bmoransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ctyBHc_jOEJZ1P_A1qNojZWT0TE Subject: Re: [scim] Webex for today's meeting? 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, 16 Apr 2014 19:20:06 -0000 --_000_CF7425A6D5F6Bmoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry, just saw this, the meeting info is the same every week. Here is the= WebEx info for the recurring meeting: ------------------------------------------------------- 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. From: Kelly Grizzle > Date: Wednesday, April 16, 2014 at 11:02 AM To: "scim@ietf.org" > Subject: [scim] Webex for today's meeting? I=92m having trouble getting on the webex. Could someone send out the info= ? --Kelly --_000_CF7425A6D5F6Bmoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <36F16D68723CBD4F91FD29C98C6342A4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Sorry, just saw this, the meeting info is the same every week.  H= ere is the WebEx info for the recurring meeting:

----------------------------------------------------= --- 
Meeting information 
-------------------------------------------------------&n= bsp;
Topic: SCIM WG bi-weekly call 
Date: Every 2 weeks on Wednesday, from Wednesday, March 1= 9, 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 passwo= rd.) 

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

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

Access code:385 408 774 

-------------------------------------------------------&n= bsp;
For assistance 
-------------------------------------------------------&n= bsp;
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=3D= m92f0520f46fac9644ab9358042b273d0 

To check whether you have the appropriate players install= ed for UCF (Universal Communications Format) rich media files, go to <= /span>h= ttps://go.webex.com/go/systemdiagnosis.php. 

http://www.= webex.com 

CCM:+14156550000x385408774# 

IMPORTANT NOTICE: This WebEx service includes a feature t= hat 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. 

From: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Date: Wednesday, April 16, 2014 at = 11:02 AM
To: "scim@ietf.org" <scim@i= etf.org>
Subject: [scim] Webex for today's m= eeting?

I=92m having trouble getting on the webex.  Cou= ld someone send out the info?

 

--Kelly

 --_000_CF7425A6D5F6Bmoransarciscocom_-- From nobody Thu Apr 17 00:02: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 8D9F71A0070 for ; Thu, 17 Apr 2014 00:02:53 -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 G_0U20gUUFlu for ; Thu, 17 Apr 2014 00:02:47 -0700 (PDT) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6711A042E for ; Thu, 17 Apr 2014 00:02:47 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id b57so243445eek.40 for ; Thu, 17 Apr 2014 00:02:43 -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=OLqbSdfYEsjpPmQ7d7qVRJm4yWpd+V/tgRgGoRmomR0=; b=PnJrCUX2+xRNtagPNdo291EeNvpo+LBk6EL3NF1+m3OPWIfYNx9OgUtIudhK9tgezF C2enfXFCjR7oKvVlqK+mN3D8Ss8wQRf5MsoPxKNzk4Z19SAq2ceBjEvQvcNYH19MWBFN LE/Qw+E5lGAL+fzA4idJGD8JfFwPpziOG2cxl989gz42m9kOrQ2Au90aw41C+ED3jIhn BzJQ/jF9rgwpYyG9/ry3j/JVj9paGbFdJAcZqnwxZapr1Zloh3AMUNzMdTwxbcFiDBmE VEq5PSbyjIUS+GPUohCdpkvNBXIGZrOMzXZvoKnM4JGOWlDXAfbdmKXDJgJp7C3fFBM7 XkHQ== X-Gm-Message-State: ALoCoQnZlZCvKDJsm2jExwMDYIcZy/uAroGvp+tvK1tY9cERwvTnCqt8gaPORsjsfeK+zf2OFBe8 X-Received: by 10.14.94.5 with SMTP id m5mr11585595eef.23.1397718163086; Thu, 17 Apr 2014 00:02:43 -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 z48sm64604937eel.27.2014.04.17.00.02.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 00:02:41 -0700 (PDT) Message-ID: <534F7C90.5050605@tarent.de> Date: Thu, 17 Apr 2014 09:02:40 +0200 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: <0C5F84EE-70F2-4F34-A94E-DB16F472F21F@oracle.com> In-Reply-To: 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/hPfbKGndFU22RG9XUS9ibMClQ-A Subject: Re: [scim] Ticket 36 - Proper JSON representation of Complex Multi-valued Attrs (Addresses, Groups, eMails) 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, 17 Apr 2014 07:02:53 -0000 +1 for A by David Am 16.04.2014 19:51, schrieb Natale, Bob: > +1 for A. > > > > Avanti, > > BobN > > > > *From:*scim [mailto:scim-bounces@ietf.org] *On Behalf Of *Kelly Grizzle > *Sent:* Wednesday, April 16, 2014 12:55 PM > *To:* Phil Hunt; scim@ietf.org WG > *Subject:* Re: [scim] Ticket 36 - Proper JSON representation of Complex > Multi-valued Attrs (Addresses, Groups, eMails) > > > > +1 for A. > > > > The spec makes it clear that value is an optional sub-attribute for > complex multi-valued attributes. > > > > I agree that this should be removed from the “addresses” description: “The value attribute is a complex type with the following sub-attributes.” > > > > --Kelly > > > > *From:*scim [mailto:scim-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Wednesday, April 16, 2014 11:44 AM > *To:* scim@ietf.org WG > *Subject:* [scim] Ticket 36 - Proper JSON representation of Complex > Multi-valued Attrs (Addresses, Groups, eMails) > > > > Erik has raised an interesting issue with regards to how Addresses is > represented in Ticket 36. > > > > *_Please consider the following below and indicate your preference for A > (current) or B (revised). _* Commentary is welcome. Depending on A or B > we should apply the format to any multi-valued complex attribute > representation. > > > > Regardless of the decision, I think some updates to the core schema > documents are required. > > > > Thanks… Phil > > > > Discussion: > > > > Address is supposed to be a multi-valued attribute. That means it is > supposed to have 3 sub-attributes: primary, type, and value. However, > Address is also a complex attribute. > > > > When this happens there are two JSON representations that appear legit > (well it is debatable at least), we need to pick one: > > > > *A. Current Compact representation: * > > "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" > > } > > ] > > > > *B. Proposed corrected representation:* > > "addresses": [ > > { > > "type": "work", > "primary": true, > "value": > > { > > "streetAddress": "100 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "100 Universal City Plaza\nHollywood, CA > 91608 USA" > > } > > }, > { > > "type": "home", > "value": > > { > > "streetAddress": "456 Hollywood Blvd", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" > > } > > } > > ], > > Notice that this second representation appears to be more correct > because the “value” is the complex attribute portion. > > > > One problem with “B" is that “value” can’t be can’t be compared. My > thought is we should stick with “A” and stipulate the “value” should > represent the default or primary attribute. Other impacted schema items > include: mail, groups, etc. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From nobody Thu Apr 17 06:47:51 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 B821D1A0180 for ; Thu, 17 Apr 2014 06:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 oBQ6lbyx9_5n for ; Thu, 17 Apr 2014 06:47:46 -0700 (PDT) Received: from canmail.canarie.ca (canmail.canarie.ca [205.189.33.17]) by ietfa.amsl.com (Postfix) with ESMTP id EBBDF1A015F for ; Thu, 17 Apr 2014 06:47:45 -0700 (PDT) Received: from THUNDERCHIEF.canarie.local (192.168.1.17) by Thunderchief.canarie.local (192.168.1.17) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 17 Apr 2014 09:47:35 -0400 Received: from THUNDERCHIEF.canarie.local ([::1]) by Thunderchief.canarie.local ([::1]) with mapi id 15.00.0775.031; Thu, 17 Apr 2014 09:47:35 -0400 From: Chris Phillips To: "scim@ietf.org" Thread-Topic: [scim] Consensus call on issue #18 - patch semantics Thread-Index: AQHPWEsJ/fXYjTnp/U2m0xskO1TxYZsV1pKA Date: Thu, 17 Apr 2014 13:47:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [192.168.1.81] Content-Type: multipart/alternative; boundary="_000_CF75538318E51Echrisphillipscanarieca_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/xk-_sLJ_KoHx9Pe2gtNj16m_cxE Subject: Re: [scim] Consensus call on issue #18 - patch semantics 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, 17 Apr 2014 13:47:48 -0000 --_000_CF75538318E51Echrisphillipscanarieca_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 for B Chris. From: "Morteza Ansari (moransar)" > Date: Monday, 14 April, 2014 9:35 PM To: "scim@ietf.org" > Subject: Re: [scim] Consensus call on issue #18 - patch semantics Bump... Hard to imagine nobody in the WG has any thoughts on this topic :) Cheers, Morteza From: Morteza Ansari > Date: Thursday, April 10, 2014 at 10:20 PM To: "scim@ietf.org" > Subject: [scim] Consensus call on issue #18 - patch semantics In London we had a good discussion on patch operation (ticket #18) and Phil= provided background information and walked the WG through a few options. I= n follow on discussions on the mailing list, survey Phil sent out, and the = WG call we narrowed it down to two options. Stay with the current patch se= mantics or change patch to a RFC6902-based model. Phil has posted to the group the proposed text for 6902 "based" patch (and = also documented in the tracker under issue #18). The WG is making a consen= sus call as follows: A. Do not change patch semantics and stay with what is currently documented= in the spec B. Adopt the 6902 based changes Phil has put together (as proposed on the l= ist and documented in tracker) C. Don't care or need more information Please provide your input before Apr. 18th. Cheers, Leif & Morteza --_000_CF75538318E51Echrisphillipscanarieca_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5DF53878B641FF4F83EBD03F562CAA57@canarie.local> Content-Transfer-Encoding: quoted-printable
+1 for B

Chris.


From: "Morteza Ansari (moransa= r)" <moransar@cisco.com&g= t;
Date: Monday, 14 April, 2014 9:35 P= M
To: "scim@ietf.org" <scim@i= etf.org>
Subject: Re: [scim] Consensus call = on issue #18 - patch semantics

Bump…  Hard to imagine nobody in the WG has any thoughts on= this topic :)


Cheers,
Morteza

From: Morteza Ansari <moransar@cisco.com>
Date: Thursday, April 10, 2014 at 1= 0:20 PM
To: "scim@ietf.org" <scim@i= etf.org>
Subject: [scim] Consensus call on i= ssue #18 - patch semantics

In London we had a good discussion on patch operation (ticket #18) and= Phil provided background information and walked the WG through a few optio= ns. In follow on discussions on the mailing list, survey Phil sent out, and= the WG call we narrowed it down to two options.  Stay with the current patch semantics or change patc= h to a RFC6902-based model.

Phil has posted to the group the proposed text for 6902 “based&#= 8221; patch (and also documented in the tracker under issue #18).  The= WG is making a consensus call as follows:

A. Do not change patch semantics and stay with what is currently docum= ented in the spec
B. Adopt the 6902 based changes Phil has put together (as proposed on = the list and documented in tracker)
C. Don’t care or need more information

Please provide your input before Apr. 18th.


Cheers,
Leif & Morteza
 --_000_CF75538318E51Echrisphillipscanarieca_-- From nobody Thu Apr 17 07:07: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 EAD3A1A02E7 for ; Thu, 17 Apr 2014 07:07:14 -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 vPFY4qL0EP4u for ; Thu, 17 Apr 2014 07:07:10 -0700 (PDT) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id C9A781A01A8 for ; Thu, 17 Apr 2014 07:07:09 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id t10so707743eei.5 for ; Thu, 17 Apr 2014 07:07:05 -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=XAk6hTkioEff1e9aGoiyGkdZDFDupZZmnTaG5p9OelY=; b=GXaGx97yX/RIGrmB1Gcl2SJpzzH2J257KRL4UPKix20IZe23azosQzo6mEfjWM4vnR IJiMLYHPqDZannQvRYtYdODWzpNlWOdVeQC5IrGX5hYrsoVvi+LqNZyerB30pPHTzIsP SpCnVgI3vxnjCUIIdv/z9C29jPJRJ/LgpALIKIwSXHpU+XQs1OW07Wc/+2BA/+b8atoH e5yM4Qw57LLEyk7UikL6QUoxXTnlrHnF2uy/+/75MTom1DYt/WLoloHqrQhmNsrTUh5Z tQ6EHRcrKoAoydf7r0vdTDfl/YSduWuq9k5wrxlmCNIWf9uGJiSIe/w/g8wLcJjRBAmk ePzA== X-Gm-Message-State: ALoCoQnfKrmyswKRKFxIfipOkgQ35J0JpWGFweXKWkQ9w2kjJ42RPEfoQYIeXMg42hEv3ZvSv8b2 X-Received: by 10.14.225.73 with SMTP id y49mr14320518eep.43.1397743625740; Thu, 17 Apr 2014 07:07:05 -0700 (PDT) Received: from dhcp-172-24-13-92.dynamic.tarent.de (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id t44sm67686531eeo.6.2014.04.17.07.07.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 07:07:05 -0700 (PDT) Message-ID: <534FE008.8010000@tarent.de> Date: Thu, 17 Apr 2014 16:07:04 +0200 From: David Crome User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: scim@ietf.org References: <0C5F84EE-70F2-4F34-A94E-DB16F472F21F@oracle.com> <534F7C90.5050605@tarent.de> In-Reply-To: <534F7C90.5050605@tarent.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/GTMstHc2arRElAxIF9KjTIKcgMI Subject: Re: [scim] Ticket 36 - Proper JSON representation of Complex Multi-valued Attrs (Addresses, Groups, eMails) 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, 17 Apr 2014 14:07:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 +1 for A Greetz, David Crome Am 17.04.14 09:02, schrieb David Möbius: > +1 for A > > by David > > Am 16.04.2014 19:51, schrieb Natale, Bob: >> +1 for A. >> >> >> >> Avanti, >> >> BobN >> >> >> >> *From:*scim [mailto:scim-bounces@ietf.org] *On Behalf Of *Kelly >> Grizzle *Sent:* Wednesday, April 16, 2014 12:55 PM *To:* Phil >> Hunt; scim@ietf.org WG *Subject:* Re: [scim] Ticket 36 - Proper >> JSON representation of Complex Multi-valued Attrs (Addresses, >> Groups, eMails) >> >> >> >> +1 for A. >> >> >> >> The spec makes it clear that value is an optional sub-attribute >> for complex multi-valued attributes. >> >> >> >> I agree that this should be removed from the “addresses” >> description: “The value attribute is a complex type with the >> following sub-attributes.” >> >> >> >> --Kelly >> >> >> >> *From:*scim [mailto:scim-bounces@ietf.org] *On Behalf Of *Phil >> Hunt *Sent:* Wednesday, April 16, 2014 11:44 AM *To:* >> scim@ietf.org WG *Subject:* [scim] Ticket >> 36 - Proper JSON representation of Complex Multi-valued Attrs >> (Addresses, Groups, eMails) >> >> >> >> Erik has raised an interesting issue with regards to how >> Addresses is represented in Ticket 36. >> >> >> >> *_Please consider the following below and indicate your >> preference for A (current) or B (revised). _* Commentary is >> welcome. Depending on A or B we should apply the format to any >> multi-valued complex attribute representation. >> >> >> >> Regardless of the decision, I think some updates to the core >> schema documents are required. >> >> >> >> Thanks… Phil >> >> >> >> Discussion: >> >> >> >> Address is supposed to be a multi-valued attribute. That means it >> is supposed to have 3 sub-attributes: primary, type, and value. >> However, Address is also a complex attribute. >> >> >> >> When this happens there are two JSON representations that appear >> legit (well it is debatable at least), we need to pick one: >> >> >> >> *A. Current Compact representation: * >> >> "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" >> >> } >> >> ] >> >> >> >> *B. Proposed corrected representation:* >> >> "addresses": [ >> >> { >> >> "type": "work", "primary": true, "value": >> >> { >> >> "streetAddress": "100 Universal City Plaza", "locality": >> "Hollywood", "region": "CA", "postalCode": "91608", "country": >> "USA", "formatted": "100 Universal City Plaza\nHollywood, CA >> 91608 USA" >> >> } >> >> }, { >> >> "type": "home", "value": >> >> { >> >> "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", >> "region": "CA", "postalCode": "91608", "country": "USA", >> "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" >> >> } >> >> } >> >> ], >> >> Notice that this second representation appears to be more >> correct because the “value” is the complex attribute portion. >> >> >> >> One problem with “B" is that “value” can’t be can’t be compared. >> My thought is we should stick with “A” and stipulate the “value” >> should represent the default or primary attribute. Other impacted >> schema items include: mail, groups, etc. >> >> >> >> Phil >> >> >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> >> >> _______________________________________________ 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 > - -- David Crome Softwareentwicklung tarent solutions GmbH Telefon +49 (0) 30 138803-132 Telefax +49 (0) 30 56829495 d.crome@tarent.de tarent solutions GmbH Niederlassung Berlin Voltastraße 5, D-13355 Berlin • http://www.tarent.de/ Tel: +49 30 138803-0 • Fax: +49 30 56829495 Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-0 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQGcBAEBCgAGBQJTT+AIAAoJEGggHv7AIBKqDTgL/0YviKd1Jv7Q1ZONAurXevUx bOsBaqpn7YKE/CbbL4f20fUcgV/4H4t+mFuC02Z0VjQgJV1O1f8dv12uXEvWL2H8 RRIzdjxf6/7INxVGocZ3pcxZLqgF28WiQv2w92HPlnNKjscvCEkcy3jSY71EzbOc htT/plFQWpJSU1ZzzoUKoqPyc3+Kf0Q5jFDr4mY3JOTluS6j5q0DUO+mtJSHIZrP uqu8N5v7kbTqjb1txK+0JeesDn+3/AmnTMJoBsHcRF6Gq6w3OVMcixzQpjVu07WU g9NGKij/slikazvnUGy9Uu47eUoCrxinslcz076QCgdbYbf5L6xbYvnOUnMOA/CL /Mqz1Pmg+2m4HGyUw/h6vZleL3JNa2ngZdr7AVN1Ar4l/zAbbvz9EFMggaWSSoqv ZpB3+GL+Xgd+be5yUsfZ4cnUBJs8tUbEjW3XTw4UFAcVKaZc6Hk0817nrm79m5Vw USqUwvFZxt5DQPJhhEkam3Ew8p+WfvZGNU9siCbi1w== =2oMz -----END PGP SIGNATURE----- From nobody Thu Apr 17 09:15:30 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 BD0871A00FB for ; Thu, 17 Apr 2014 09:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 nCfSTOjzwZ3z for ; Thu, 17 Apr 2014 09:15:24 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id EE1971A00DD for ; Thu, 17 Apr 2014 09:15:23 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rd18so578374iec.15 for ; Thu, 17 Apr 2014 09:15:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=6Sg5rWH4kORuvJgV64lLGKksFx9kGF0z6NZagMyUrUA=; b=F7yMStVk5be5f1MoSybIy2t5gRstcwAqDVwRv0F3KPeViXGP+Ukyt3rlKxTDP1umT9 qBkdSzqYeUqVVXcZvg3NUWsbytT+G9A4418QItH+wfr6Au89Z5n2KxZQWA6NCYvM8IA+ HJFrAnnlQKMftiinxt75LThr3uCbQmo/UnYLVoobEl4GBKq6R5L/oJ4GtwcsR9kocPNY 3rn4eR1YdwyYPLFGZOE2q070Zzs53U5GZRz2Y0fY7qmQFYDhocnCFkQpUjWp35id0lYT YBCWHPRIGyJUT6t34uGo43YmdCOEbYqN/EhBuFPohKfNMqQPNxhNfN+iv25eDqBtA92p oYKg== X-Gm-Message-State: ALoCoQkyW9f6U58rj4VYccf9WWnJ+yIXx8ohoPIWomTRM5UXF8fPhhJ1lbAhRXImLThlUt34vjEk MIME-Version: 1.0 X-Received: by 10.50.66.143 with SMTP id f15mr12199185igt.18.1397751320184; Thu, 17 Apr 2014 09:15:20 -0700 (PDT) Received: by 10.64.15.68 with HTTP; Thu, 17 Apr 2014 09:15:20 -0700 (PDT) In-Reply-To: <534FE008.8010000@tarent.de> References: <0C5F84EE-70F2-4F34-A94E-DB16F472F21F@oracle.com> <534F7C90.5050605@tarent.de> <534FE008.8010000@tarent.de> Date: Thu, 17 Apr 2014 09:15:20 -0700 Message-ID: From: Melvin Laguren To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd6c744eca1a204f73f56fa Archived-At: http://mailarchive.ietf.org/arch/msg/scim/6X8-eFbAlkE_mS1pBNvHjQTTl7Q Subject: Re: [scim] Ticket 36 - Proper JSON representation of Complex Multi-valued Attrs (Addresses, Groups, eMails) 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, 17 Apr 2014 16:15:28 -0000 --047d7bd6c744eca1a204f73f56fa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Vote for A On Thu, Apr 17, 2014 at 7:07 AM, David Crome wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > +1 for A > > Greetz, > David Crome > > Am 17.04.14 09:02, schrieb David M=C3=B6bius: > > +1 for A > > > > by David > > > > Am 16.04.2014 19:51, schrieb Natale, Bob: > >> +1 for A. > >> > >> > >> > >> Avanti, > >> > >> BobN > >> > >> > >> > >> *From:*scim [mailto:scim-bounces@ietf.org] *On Behalf Of *Kelly > >> Grizzle *Sent:* Wednesday, April 16, 2014 12:55 PM *To:* Phil > >> Hunt; scim@ietf.org WG *Subject:* Re: [scim] Ticket 36 - Proper > >> JSON representation of Complex Multi-valued Attrs (Addresses, > >> Groups, eMails) > >> > >> > >> > >> +1 for A. > >> > >> > >> > >> The spec makes it clear that value is an optional sub-attribute > >> for complex multi-valued attributes. > >> > >> > >> > >> I agree that this should be removed from the =E2=80=9Caddresses=E2=80= =9D > >> description: =E2=80=9CThe value attribute is a complex type with the > >> following sub-attributes.=E2=80=9D > >> > >> > >> > >> --Kelly > >> > >> > >> > >> *From:*scim [mailto:scim-bounces@ietf.org] *On Behalf Of *Phil > >> Hunt *Sent:* Wednesday, April 16, 2014 11:44 AM *To:* > >> scim@ietf.org WG *Subject:* [scim] Ticket > >> 36 - Proper JSON representation of Complex Multi-valued Attrs > >> (Addresses, Groups, eMails) > >> > >> > >> > >> Erik has raised an interesting issue with regards to how > >> Addresses is represented in Ticket 36. > >> > >> > >> > >> *_Please consider the following below and indicate your > >> preference for A (current) or B (revised). _* Commentary is > >> welcome. Depending on A or B we should apply the format to any > >> multi-valued complex attribute representation. > >> > >> > >> > >> Regardless of the decision, I think some updates to the core > >> schema documents are required. > >> > >> > >> > >> Thanks=E2=80=A6 Phil > >> > >> > >> > >> Discussion: > >> > >> > >> > >> Address is supposed to be a multi-valued attribute. That means it > >> is supposed to have 3 sub-attributes: primary, type, and value. > >> However, Address is also a complex attribute. > >> > >> > >> > >> When this happens there are two JSON representations that appear > >> legit (well it is debatable at least), we need to pick one: > >> > >> > >> > >> *A. Current Compact representation: * > >> > >> "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" > >> > >> } > >> > >> ] > >> > >> > >> > >> *B. Proposed corrected representation:* > >> > >> "addresses": [ > >> > >> { > >> > >> "type": "work", "primary": true, "value": > >> > >> { > >> > >> "streetAddress": "100 Universal City Plaza", "locality": > >> "Hollywood", "region": "CA", "postalCode": "91608", "country": > >> "USA", "formatted": "100 Universal City Plaza\nHollywood, CA > >> 91608 USA" > >> > >> } > >> > >> }, { > >> > >> "type": "home", "value": > >> > >> { > >> > >> "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", > >> "region": "CA", "postalCode": "91608", "country": "USA", > >> "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" > >> > >> } > >> > >> } > >> > >> ], > >> > >> Notice that this second representation appears to be more > >> correct because the =E2=80=9Cvalue=E2=80=9D is the complex attribute p= ortion. > >> > >> > >> > >> One problem with =E2=80=9CB" is that =E2=80=9Cvalue=E2=80=9D can=E2=80= =99t be can=E2=80=99t be compared. > >> My thought is we should stick with =E2=80=9CA=E2=80=9D and stipulate t= he =E2=80=9Cvalue=E2=80=9D > >> should represent the default or primary attribute. Other impacted > >> schema items include: mail, groups, etc. > >> > >> > >> > >> Phil > >> > >> > >> > >> @independentid > >> > >> www.independentid.com > >> > >> phil.hunt@oracle.com > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ 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 > > > > - -- > David Crome > Softwareentwicklung > tarent solutions GmbH > > Telefon +49 (0) 30 138803-132 > Telefax +49 (0) 30 56829495 > d.crome@tarent.de > > tarent solutions GmbH Niederlassung Berlin > Voltastra=C3=9Fe 5, D-13355 Berlin =E2=80=A2 http://www.tarent.de/ > Tel: +49 30 138803-0 =E2=80=A2 Fax: +49 30 56829495 > > Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/ > Tel: +49 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235 > HRB AG Bonn 5168 =E2=80=A2 USt-ID (VAT): DE122264941 > Gesch=C3=A4ftsf=C3=BChrer: Boris Esser, Sebastian Mancke > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQGcBAEBCgAGBQJTT+AIAAoJEGggHv7AIBKqDTgL/0YviKd1Jv7Q1ZONAurXevUx > bOsBaqpn7YKE/CbbL4f20fUcgV/4H4t+mFuC02Z0VjQgJV1O1f8dv12uXEvWL2H8 > RRIzdjxf6/7INxVGocZ3pcxZLqgF28WiQv2w92HPlnNKjscvCEkcy3jSY71EzbOc > htT/plFQWpJSU1ZzzoUKoqPyc3+Kf0Q5jFDr4mY3JOTluS6j5q0DUO+mtJSHIZrP > uqu8N5v7kbTqjb1txK+0JeesDn+3/AmnTMJoBsHcRF6Gq6w3OVMcixzQpjVu07WU > g9NGKij/slikazvnUGy9Uu47eUoCrxinslcz076QCgdbYbf5L6xbYvnOUnMOA/CL > /Mqz1Pmg+2m4HGyUw/h6vZleL3JNa2ngZdr7AVN1Ar4l/zAbbvz9EFMggaWSSoqv > ZpB3+GL+Xgd+be5yUsfZ4cnUBJs8tUbEjW3XTw4UFAcVKaZc6Hk0817nrm79m5Vw > USqUwvFZxt5DQPJhhEkam3Ew8p+WfvZGNU9siCbi1w=3D=3D > =3D2oMz > -----END PGP SIGNATURE----- > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > --047d7bd6c744eca1a204f73f56fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Vote for A


On Thu, Apr 17, 2014 at 7:07 AM, David Crome <d.crome= @tarent.de> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

+1 for A

Greetz,
David Crome

Am 17.04.14 09:02, schrieb David M=C3=B6bius:
> +1 for A
>
> by David
>
> Am 16.04.2014 19:51, schrieb Natale, Bob:
>> +1 for A.
>>
>>
>>
>> Avanti,
>>
>> BobN
>>
>>
>>
>> *From:*scim [mailto:scim-= bounces@ietf.org] *On Behalf Of *Kelly
>> Grizzle *Sent:* Wednesday, April 16, 2014 12:55 PM *To:* Phil
>> Hunt; scim@ietf.org WG *Subje= ct:* Re: [scim] Ticket 36 - Proper
>> JSON representation of Complex Multi-valued Attrs (Addresses,
>> Groups, eMails)
>>
>>
>>
>> +1 for A.
>>
>>
>>
>> The spec makes it clear that value is an optional sub-attribute >> for complex multi-valued attributes.
>>
>>
>>
>> I agree that this should be removed from the =E2=80=9Caddresses=E2= =80=9D
>> description: =E2=80=9CThe value attribute is a complex type with t= he
>> following sub-attributes.=E2=80=9D
>>
>>
>>
>> --Kelly
>>
>>
>>
>> *From:*scim [mailto:scim-= bounces@ietf.org] *On Behalf Of *Phil
>> Hunt *Sent:* Wednesday, April 16, 2014 11:44 AM *To:*
>> scim@ietf.org <mailto:scim@ietf.org> WG *Subject:* [scim] Tic= ket
>> 36 - Proper JSON representation of Complex Multi-valued Attrs
>> (Addresses, Groups, eMails)
>>
>>
>>
>> Erik has raised an interesting issue with regards to how
>> Addresses is represented in Ticket 36.
>>
>>
>>
>> *_Please consider the following below and indicate your
>> preference for A (current) or B (revised). _* Commentary is
>> welcome. Depending on A or B we should apply the format to any
>> multi-valued complex attribute representation.
>>
>>
>>
>> Regardless of the decision, I think some updates to the core
>> schema documents are required.
>>
>>
>>
>> Thanks=E2=80=A6 Phil
>>
>>
>>
>> Discussion:
>>
>>
>>
>> Address is supposed to be a multi-valued attribute. That means it<= br> >> is supposed to have 3 sub-attributes: =C2=A0primary, type, and val= ue.
>> However, Address is also a complex attribute.
>>
>>
>>
>> When this happens there are two JSON representations that appear >> legit (well it is debatable at least), we need to pick one:
>>
>>
>>
>> *A. Current Compact representation: *
>>
>> "addresses": [
>>
>> {
>>
>> "type": "work", "streetAddress": &qu= ot;100 Universal City Plaza",
>> "locality": "Hollywood", "region": &= quot;CA", "postalCode": "91608",
>> "country": "USA", "formatted": "= ;100 Universal City
>> Plaza\nHollywood, CA 91608 USA", "primary": true >>
>> }, {
>>
>> "type": "home", "streetAddress": &qu= ot;456 Hollywood Blvd",
>> "locality": "Hollywood", "region": &= quot;CA", "postalCode": "91608",
>> "country": "USA", "formatted": "= ;456 Hollywood Blvd\nHollywood, CA
>> 91608 USA"
>>
>> }
>>
>> ]
>>
>>
>>
>> *B. Proposed corrected representation:*
>>
>> "addresses": [
>>
>> {
>>
>> "type": "work", "primary": true, &qu= ot;value":
>>
>> {
>>
>> "streetAddress": "100 Universal City Plaza", &= quot;locality":
>> "Hollywood", "region": "CA", "p= ostalCode": "91608", "country":
>> "USA", "formatted": "100 Universal City P= laza\nHollywood, CA
>> 91608 USA"
>>
>> }
>>
>> }, {
>>
>> "type": "home", "value":
>>
>> {
>>
>> "streetAddress": "456 Hollywood Blvd", "l= ocality": "Hollywood",
>> "region": "CA", "postalCode": "= 91608", "country": "USA",
>> "formatted": "456 Hollywood Blvd\nHollywood, CA 916= 08 USA"
>>
>> }
>>
>> }
>>
>> ],
>>
>> Notice that this second representation appears to be more
>> correct because the =E2=80=9Cvalue=E2=80=9D is the complex attribu= te portion.
>>
>>
>>
>> One problem with =E2=80=9CB" is that =E2=80=9Cvalue=E2=80=9D = can=E2=80=99t be can=E2=80=99t be compared.
>> My thought is we should stick with =E2=80=9CA=E2=80=9D and stipula= te the =E2=80=9Cvalue=E2=80=9D
>> should represent the default or primary attribute. Other impacted<= br> >> schema items include: =C2=A0mail, groups, etc.
>>
>>
>>
>> Phil
>>
>>
>>
>> @independentid
>>
>> www.ind= ependentid.com <http://www.independentid.com>
>>
>> phil.hunt@oracle.com &= lt;mailto:phil.hunt@oracle.com&= gt;
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________ 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
>

- --
David Crome
Softwareentwicklung
tarent solutions GmbH

Telefon +49 (0) 30 138803-132
Telefax +49 (0) 30 56829495
d.crome@tarent.de

tarent solutions GmbH =C2=A0Niederlassung Berlin
Voltastra=C3=9Fe 5, D-13355 Berlin =E2=80=A2 http://www.tarent.de/
Tel: +49 30 13= 8803-0 =E2=80=A2 Fax: +49 30 56829495

Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 5= 4881-0 =E2=80=A2 Fax: +49 228 54881-235
HRB AG Bonn 5168 =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Boris Esser, Sebastian Mancke
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQGcBAEBCgAGBQJTT+AIAAoJEGggHv7AIBKqDTgL/0YviKd1Jv7Q1ZONAurXevUx
bOsBaqpn7YKE/CbbL4f20fUcgV/4H4t+mFuC02Z0VjQgJV1O1f8dv12uXEvWL2H8
RRIzdjxf6/7INxVGocZ3pcxZLqgF28WiQv2w92HPlnNKjscvCEkcy3jSY71EzbOc
htT/plFQWpJSU1ZzzoUKoqPyc3+Kf0Q5jFDr4mY3JOTluS6j5q0DUO+mtJSHIZrP
uqu8N5v7kbTqjb1txK+0JeesDn+3/AmnTMJoBsHcRF6Gq6w3OVMcixzQpjVu07WU
g9NGKij/slikazvnUGy9Uu47eUoCrxinslcz076QCgdbYbf5L6xbYvnOUnMOA/CL
/Mqz1Pmg+2m4HGyUw/h6vZleL3JNa2ngZdr7AVN1Ar4l/zAbbvz9EFMggaWSSoqv
ZpB3+GL+Xgd+be5yUsfZ4cnUBJs8tUbEjW3XTw4UFAcVKaZc6Hk0817nrm79m5Vw
USqUwvFZxt5DQPJhhEkam3Ew8p+WfvZGNU9siCbi1w=3D=3D
=3D2oMz
-----END PGP SIGNATURE-----

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

--047d7bd6c744eca1a204f73f56fa-- From nobody Thu Apr 17 12:14: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 D0F341A0171; Thu, 17 Apr 2014 12:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 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, RP_MATCHES_RCVD=-0.272, 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 pZgB6xeDPTpX; Thu, 17 Apr 2014 12:14:51 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF811A0137; Thu, 17 Apr 2014 12:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10581; q=dns/txt; s=iport; t=1397762088; x=1398971688; h=from:to:subject:date:message-id:mime-version; bh=N03mKN838w6jF3wE0bIBnrvQsxNJrF0ivrGe2k0emlQ=; b=GI9ADjWYPeDAvCfAgWQUsy7umYlDhS+cGjJAF3V9bGYbZApGldbUj2oy PLZgKlDVPyPJ6SmkuV8kQHaWdkrL9PLo6WN4jRPaQkDyxMhmEqvhUtTAG 5tjzNaybXOTfNG3Q1hqSRPyFsN1AfTTsDvbyQmOOxsMf39AwE7BnMTzof 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFABAnUFOtJA2M/2dsb2JhbAA/GoJCRDtXw2GBJhZ0giwdAVAdAYEAJwQBiA4NNsspEwSOHUGEQwSYbpJNgzGCKw X-IronPort-AV: E=Sophos; i="4.97,880,1389744000"; d="scan'208,217"; a="36708895" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP; 17 Apr 2014 19:14:47 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s3HJEl0G025949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 19:14:47 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.226]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 14:14:46 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" , "proceedings@ietf.org" Thread-Topic: Meeting notes from SCIM WG conf call 2014-04-16 Thread-Index: AQHPWnFLPzvioMcZ/E+7WAqiOmk/LA== Date: Thu, 17 Apr 2014 19:14:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.70.123] Content-Type: multipart/alternative; boundary="_000_CF757637D64EDmoransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/t1L7mR0yUVui2FcBCr8f0pArx-o Subject: [scim] Meeting notes from SCIM WG conf call 2014-04-16 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, 17 Apr 2014 19:14:55 -0000 --_000_CF757637D64EDmoransarciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Present: * Bjorn Aannestad (note taker) * Kelly Grizzle * Ian Glazer * Morteza Ansari * Phil Hunt * Melvin Laguren Notes: Ticket #18: Still waiting on comments by end of this week. Once that happe= ns, then Morteza/Leif will close the thread. All comments so far been in f= avor adopting the JSON patch. Ticket #61 was handled as part of Phil's updates for 18, limiting character= s that can be used in attribute names. #71 and #72 are related to #61, bo= th about localization issues. Decision to make a consensus call for #61, so that #18 can also be closed. = (Noted that JSON allows any string, but SCIM attribute names appear in URLs= ) Tickets #43, #36: Dropping short-hand notation... consensus was confirmed a= lready for #43. Phil will change language to follow the RFC5646 as the HTT= Pbis WG does in section 3.1.3 of their draft. And, add language to recommen= d support both underscores and (the new) dashes for backwards compatibility= . Phil will fix #62, #63, #65 in a draft subsequent to the draft that contain= s changes related to #18. Ticket #65 (Removing method overload header) Kelly reports finding a need= for the header when using a new Blackberry browser. It can't do a SCIM PAT= CH unless the overload header is supported. Kelly will add more explanation= to the ticket. However, based on earlier discussion we either have to us= e a registered method override, or remove it from the spec. Referred to J= ulian and Leif for their opinions. Ticket #73 - (Async support for long bulk operations) Discussion around nee= d to address this now, or wait till its a problem. Phil may request comments from the mailing list. Also, consideration must be made f= or what happens after a timed out HTTP operation. Discussion led to conclus= ion that bulk operations are valuable, and async operations should be a sep= arate extension draft. Ian Glazer is "taking the baton" from Chuck Mortimer, representing SalesFor= ce. --- Meeting recording: Your recording is now available on the WebEx service site. Click the link b= elow to play it: https://go.webex.com/go/lsr.php?RCID=3D714d5648b0204e7ea05f6f43f9107b47 SCIM WG bi-weekly call-20140416 1810-1 Wednesday, April 16, 2014 11:10 am San Francisco Time 48 Minutes --_000_CF757637D64EDmoransarciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <42616592AE4BAE46BCFDDB861D450C48@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Present:
* Bjorn Aanne= stad <= /span>(note taker)=
* Kelly Grizzle
* Ian Glazer
* Morteza Ansari
* Phil Hunt
* Melvin Laguren

Notes:
Ticket #18: Still waiting on comment= s by end of this week.  Once that happens, then Morteza/Leif will close the thread.=  All comments so far been in favor adopting the JSON patch.

Ticket #61 was handled as part of Ph= il's updates for 18, limiting characters that can be used in attribute names.   #71= and #72 are = related to #61, both about localization issues.

Decision to make a consensus call fo= r #61, so that #18 can also be closed. (Noted that JSON allows any string, but SCIM attr= ibute names appear in URLs)

Tickets #43, #36: Dropping short-han= d notation... consensus was confirmed already for #43.  Phil will change language t= o follow the RFC5646 as the HTTPbis WG does in section 3.1.3 of their draft. And, add language to recommend = support both underscores and (the new) dashes for backwards compatibility.

Phil will fix #62, #63, #65 in a dra= ft subsequent to the draft that contains changes related to #18.

Ticket #65 (Removing method overload= header)   Kelly reports finding a need for the header when using a new Blackberry = browser. It can't do a SCIM PATCH unless the overload header is supported. Kelly will add more explanation to the t= icket.   However, based on earlier discussion we either have to use a registered method override, or remove it from the spec.   Referred to Jul= ian and Leif for their opinions.

Ticket #73 - (Async support for long= bulk operations) Discussion around need to address this now, or wait till its a problem= .  Phil may
request comments from the mailing li= st.  Also, consideration must be made for what happens after a timed out HTTP opera= tion. Discussion led to conclusion that bulk operations are valuable, and async operations should be a separate= extension draft.

Ian Glazer is "taking the baton= " from Chuck Mortimer, representing SalesForce.

---
Meeting recording:<= /div>

Y= our recording is now available on the WebEx service site. Click the link be= low to play it: 

https://go.webex.com/go/lsr.php?RCID= =3D714d5648b0204e7ea05f6f43f9107b47 

SCIM WG bi-weekly call-20140416 1810-1 
Wednesday, April 16, 2014 11:10 am San Francisco Time&nbs= p;
48 Minutes 
--_000_CF757637D64EDmoransarciscocom_-- From nobody Fri Apr 18 10:45:19 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 208011A03CF for ; Fri, 18 Apr 2014 10:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 nsJeWevNArKf for ; Fri, 18 Apr 2014 10:45:12 -0700 (PDT) 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 04AEB1A0425 for ; Fri, 18 Apr 2014 10:45:08 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so3446669veb.11 for ; Fri, 18 Apr 2014 10:45:04 -0700 (PDT) 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=fRPqWErhi5Q6YZbSRLPN7HtW95KCnA1ZMuEJIRNSINs=; b=EtzeRgJVdi2d4aaby2Lklmod0GUUTVVwjTVt51F+48k19p233PsvJ53Wk1+M6ho0gb Bqk9mh/XBjACDBes82C7rrhsQ26RYIS9Q4G+37iY0D93GUDIxnFXQTwQBIj7mYE8MNjx 6dG9f8KdzizhSSXcOthG6uUnLLfmkF1d6skshZI3S/B61/93hfuHooeltJDBn72cg/Lw KzPbKkNx6zsxx1VVYPYaWfmg26N8ciiefUYi6BqfEuY0NXGLFM/itRprUF+9C7jtbRQJ hyp2f+MMga/OJdbpDDpvRHOD3cH4bdeHR4EsaWHzUbIweAslGOpNjNgCrDH2/+yjmgPF xr1A== MIME-Version: 1.0 X-Received: by 10.52.251.199 with SMTP id zm7mr12451290vdc.21.1397843104799; Fri, 18 Apr 2014 10:45:04 -0700 (PDT) Received: by 10.58.196.135 with HTTP; Fri, 18 Apr 2014 10:45:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Apr 2014 10:45:04 -0700 Message-ID: From: Chuck Mortimore To: Chris Phillips Content-Type: multipart/alternative; boundary=001a1135f378b6a5ce04f754b55b Archived-At: http://mailarchive.ietf.org/arch/msg/scim/obRbllVq-TvJFZkjJ1mjjiNx0j8 Cc: "scim@ietf.org" Subject: Re: [scim] Consensus call on issue #18 - patch semantics 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, 18 Apr 2014 17:45:17 -0000 --001a1135f378b6a5ce04f754b55b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for B. No point re-inventing the wheel. On Thu, Apr 17, 2014 at 6:47 AM, Chris Phillips wrote: > +1 for B > > Chris. > > > From: "Morteza Ansari (moransar)" > Date: Monday, 14 April, 2014 9:35 PM > To: "scim@ietf.org" > Subject: Re: [scim] Consensus call on issue #18 - patch semantics > > Bump=E2=80=A6 Hard to imagine nobody in the WG has any thoughts on thi= s topic > :) > > > Cheers, > Morteza > > From: Morteza Ansari > Date: Thursday, April 10, 2014 at 10:20 PM > To: "scim@ietf.org" > Subject: [scim] Consensus call on issue #18 - patch semantics > > In London we had a good discussion on patch operation (ticket #18) and > Phil provided background information and walked the WG through a few > options. In follow on discussions on the mailing list, survey Phil sent > out, and the WG call we narrowed it down to two options. Stay with the > current patch semantics or change patch to a RFC6902-based model. > > Phil has posted to the group the proposed text for 6902 =E2=80=9Cbased= =E2=80=9D patch > (and also documented in the tracker under issue #18). The WG is making a > consensus call as follows: > > A. Do not change patch semantics and stay with what is currently > documented in the spec > B. Adopt the 6902 based changes Phil has put together (as proposed on the > list and documented in tracker) > C. Don=E2=80=99t care or need more information > > Please provide your input before Apr. 18th. > > > Cheers, > Leif & Morteza > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --001a1135f378b6a5ce04f754b55b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for B. =C2=A0 No point re-inventing the wheel.


On Thu, Apr 17, = 2014 at 6:47 AM, Chris Phillips <Chris.Phillips@canarie.ca>= wrote:
+1 for B

Chris.


From: "Morteza Ansari (moransa= r)" <morans= ar@cisco.com>
Date: Monday, 14 April, 2014 9:35 P= M
To: "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] Consensus call = on issue #18 - patch semantics

Bump=E2=80=A6 =C2=A0Hard to imagine nobody in the WG has any thoughts = on this topic :)


Cheers,
Morteza

From: Morteza Ansari <moransar@cisco.com> Date: Thursday, April 10, 2014 at 1= 0:20 PM
To: "scim@ietf.org" <scim@ietf.org>
Subject: [scim] Consensus call on i= ssue #18 - patch semantics

In London we had a good discussion on patch operation (ticket #18) and= Phil provided background information and walked the WG through a few optio= ns. In follow on discussions on the mailing list, survey Phil sent out, and= the WG call we narrowed it down to two options. =C2=A0Stay with the current patch semantics or change patc= h to a RFC6902-based model.

Phil has posted to the group the proposed text for 6902 =E2=80=9Cbased= =E2=80=9D patch (and also documented in the tracker under issue #18). =C2= =A0The WG is making a consensus call as follows:

A. Do not change patch semantics and stay with what is currently docum= ented in the spec
B. Adopt the 6902 based changes Phil has put together (as proposed on = the list and documented in tracker)
C. Don=E2=80=99t care or need more information

Please provide your input before Apr. 18th.


Cheers,
Leif & Morteza

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


--001a1135f378b6a5ce04f754b55b-- From nobody Mon Apr 21 16:52: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 45A0E1A031F for ; Mon, 21 Apr 2014 16:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 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, RP_MATCHES_RCVD=-0.272, 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 qN04sMj4rD5D for ; Mon, 21 Apr 2014 16:52:08 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5871A031A for ; Mon, 21 Apr 2014 16:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8637; q=dns/txt; s=iport; t=1398124323; x=1399333923; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=f0VY0E/1D3eJZa5Gn+hCWmWsqMEMu8DPXRBRLWgYYA0=; b=ENQbU2Cvw2p8Z6Cq4mtbmxd26diXF6IPi3GVRJ+nW+W3h6xcIeEvmL/N +KAS2SMFySQwXROq1s1knJxGAqgcLmTejqaOEszXrKyskNCedBAlrzMpX 6UtK3M5IVd7qiaUfLyuRgcp8Bp1Qvdvur3POxmsH+vGouW3NDgcSauxuU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FAD2uVVOtJA2F/2dsb2JhbABZgkJET1e8Voc8gSAWdIIlAQEBBAEBARVWGwIBCBEDAQIoByEGCxQJCAIEE4gtAxENxiYNhmsTBIxJgUUPNA0LAoQ2BJcAgW6MfoVRgzGCKw X-IronPort-AV: E=Sophos; i="4.97,899,1389744000"; d="scan'208,217"; a="37589688" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP; 21 Apr 2014 23:52:02 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s3LNq2oE018928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 23:52:02 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.226]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 18:52:02 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: [scim] Consensus call on issue #18 - patch semantics Thread-Index: AQHPWEsJ/fXYjTnp/U2m0xskO1TxYZsV1pKAgAIohQCABKg1gA== Date: Mon, 21 Apr 2014 23:52:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.126.63] Content-Type: multipart/alternative; boundary="_000_CF7AFCD3D847Amoransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/lBrbqRtG4xG46cpf1XNZL9u_Jjs Subject: Re: [scim] Consensus call on issue #18 - patch semantics 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, 21 Apr 2014 23:52:12 -0000 --_000_CF7AFCD3D847Amoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks everyone for your input, we have consensus on option B. Phil, pleas= e publish the changes for option B and close this ticket. Cheers, Morteza From: Chuck Mortimore > Date: Friday, April 18, 2014 at 10:45 AM To: Chris Phillips > Cc: "scim@ietf.org" > Subject: Re: [scim] Consensus call on issue #18 - patch semantics +1 for B. No point re-inventing the wheel. On Thu, Apr 17, 2014 at 6:47 AM, Chris Phillips > wrote: +1 for B Chris. From: "Morteza Ansari (moransar)" > Date: Monday, 14 April, 2014 9:35 PM To: "scim@ietf.org" > Subject: Re: [scim] Consensus call on issue #18 - patch semantics Bump=85 Hard to imagine nobody in the WG has any thoughts on this topic :) Cheers, Morteza From: Morteza Ansari > Date: Thursday, April 10, 2014 at 10:20 PM To: "scim@ietf.org" > Subject: [scim] Consensus call on issue #18 - patch semantics In London we had a good discussion on patch operation (ticket #18) and Phil= provided background information and walked the WG through a few options. I= n follow on discussions on the mailing list, survey Phil sent out, and the = WG call we narrowed it down to two options. Stay with the current patch se= mantics or change patch to a RFC6902-based model. Phil has posted to the group the proposed text for 6902 =93based=94 patch (= and also documented in the tracker under issue #18). The WG is making a co= nsensus call as follows: A. Do not change patch semantics and stay with what is currently documented= in the spec B. Adopt the 6902 based changes Phil has put together (as proposed on the l= ist and documented in tracker) C. Don=92t care or need more information Please provide your input before Apr. 18th. Cheers, Leif & Morteza _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_CF7AFCD3D847Amoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks everyone for your input, we have consensus on option B.  P= hil, please publish the changes for option B and close this ticket. 


Cheers,
Morteza

From: Chuck Mortimore <charliemortimore@gmail.com> Date: Friday, April 18, 2014 at 10:= 45 AM
To: Chris Phillips <Chris.Phillips@canarie.ca>
Cc: "scim@ietf.org" <scim@i= etf.org>
Subject: Re: [scim] Consensus call = on issue #18 - patch semantics

+1 for B.   No point re-inventing the wheel.


On Thu, Apr 17, 2014 at 6:47 AM, Chris Phillips = <Chris.Ph= illips@canarie.ca> wrote:
+1 for B

Chris.


From: "Morteza Ansari (moransa= r)" <morans= ar@cisco.com>
Date: Monday, 14 April, 2014 9:35 P= M
To: "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] Consensus call = on issue #18 - patch semantics

Bump=85  Hard to imagine nobody in the WG has any thoughts on thi= s topic :)


Cheers,
Morteza

From: Morteza Ansari <moransar@cisco.com> Date: Thursday, April 10, 2014 at 1= 0:20 PM
To: "scim@ietf.org" <scim@ietf.org>
Subject: [scim] Consensus call on i= ssue #18 - patch semantics

In London we had a good discussion on patch operation (ticket #18) and= Phil provided background information and walked the WG through a few optio= ns. In follow on discussions on the mailing list, survey Phil sent out, and= the WG call we narrowed it down to two options.  Stay with the current patch semantics or change patc= h to a RFC6902-based model.

Phil has posted to the group the proposed text for 6902 =93based=94 pa= tch (and also documented in the tracker under issue #18).  The WG is m= aking a consensus call as follows:

A. Do not change patch semantics and stay with what is currently docum= ented in the spec
B. Adopt the 6902 based changes Phil has put together (as proposed on = the list and documented in tracker)
C. Don=92t care or need more information

Please provide your input before Apr. 18th.


Cheers,
Leif & Morteza

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


--_000_CF7AFCD3D847Amoransarciscocom_-- From nobody Wed Apr 23 08:58:24 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 95DB21A0365; Wed, 23 Apr 2014 08:58:15 -0700 (PDT) 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 XR4fuO-zuP93; Wed, 23 Apr 2014 08:58:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDF31A02B7; Wed, 23 Apr 2014 08:58:13 -0700 (PDT) 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.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140423155813.27847.59987.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 08:58:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/xdD5mN9kqId8HvZm_6nt-xCk2BY Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-04.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: Wed, 23 Apr 2014 15:58:15 -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 : System for Cross-Domain Identity Management:Protocol Authors : Kelly Grizzle Phil Hunt Morteza Ansari Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-api-04.txt Pages : 61 Date : 2014-04-23 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. It's intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-api-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-04 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 Wed Apr 23 09:05:01 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 20EA21A0348 for ; Wed, 23 Apr 2014 09:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 OiUFxyS1LmxK for ; Wed, 23 Apr 2014 09:04:58 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 822861A0291 for ; Wed, 23 Apr 2014 09:04:58 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s3NG4qgF011166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Apr 2014 16:04:52 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3NG4phn027236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Apr 2014 16:04:51 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s3NG4o4B022776 for ; Wed, 23 Apr 2014 16:04:50 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Apr 2014 09:04:50 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: <20140423155813.27847.59987.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 09:04:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A792AE0-20A3-4EE3-96AA-B1FCE57BD594@oracle.com> References: <20140423155813.27847.59987.idtracker@ietfa.amsl.com> To: "scim@ietf.org WG" X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/nPrkzaZSZEKnJDqO1N1JO0jFUUw Subject: Re: [scim] I-D Action: draft-ietf-scim-api-04.txt 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, 23 Apr 2014 16:05:00 -0000 Hi all, This new API draft has the new patch command based on JSON Patch for = which consensus was called on Monday (Ticket 18). Comments appreciated. Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 23, 2014, at 8:58 AM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : System for Cross-Domain Identity = Management:Protocol > Authors : Kelly Grizzle > Phil Hunt > Morteza Ansari > Erik Wahlstroem > Chuck Mortimore > Filename : draft-ietf-scim-api-04.txt > Pages : 61 > Date : 2014-04-23 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) specification > is designed to make managing user identity in cloud based > applications and services easier. The specification suite seeks to > build upon experience with existing schemas and deployments, placing > specific emphasis on simplicity of development and integration, = while > applying existing authentication, authorization, and privacy models. > It's intent is to reduce the cost and complexity of user management > operations by providing a common user schema and extension model, as > well as binding documents to provide patterns for exchanging this > schema using standard protocols. In essence, make it fast, cheap, > and easy to move users in to, out of, and around the cloud. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-scim-api-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-api-04 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed Apr 23 12:31:30 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 242061A0573 for ; Wed, 23 Apr 2014 12:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 E1G_iaqeDWfq for ; Wed, 23 Apr 2014 12:31:27 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 85EE61A049A for ; Wed, 23 Apr 2014 12:31:27 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s3NJVKL2003209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Apr 2014 19:31:21 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3NJVJmg013987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Apr 2014 19:31:20 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3NJVJYS008172 for ; Wed, 23 Apr 2014 19:31:19 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Apr 2014 12:31:19 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_76075065-D9BC-4E27-9348-28066EA9E8C3" Message-Id: Date: Wed, 23 Apr 2014 12:31:17 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/AyH-uwMXUZpiN4s0sFMOiZFdUUo Subject: [scim] PreferredLanguage - should it be more like accept-language header 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, 23 Apr 2014 19:31:29 -0000 --Apple-Mail=_76075065-D9BC-4E27-9348-28066EA9E8C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have been talking with some of our internationalization folks and we = ran into some concerns with the preferredLanguage attribute which = specifies a users preferred language. The issue is that current SCIM core schema spec allows only one = preferred language to be specified while in other systems such as LDAP = the =93preferredLanguage=94 attribute uses a value compatible with = accept-language headers (http://tools.ietf.org/html/rfc2798#section-2.7 = ). For example: "da, en-gb;q=3D0.8, en;q=3D0.7=94 means I prefer Danish but will = accept British English and other types of English. On a positive note, the LDAP form which uses =93language-range=94 = defined [RFC4647], Section 2.1 appears to be backwards compatible with = the single language definition we currently have. One worry that was expressed was that in the cloud we have less = dependency on a user-agents being able to correctly negotiate languages = for users. While some browsers are dedicated to users (eg smartphones), = others are becoming increasingly shared such as kiosks. Being able to = pull accept-language information from a User=92s profile is very = important. Any concerns with expanding preferredLanguage to allow for = language-range per RFC4647? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_76075065-D9BC-4E27-9348-28066EA9E8C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I have = been talking with some of our internationalization folks and we ran into = some concerns with the preferredLanguage attribute which specifies a = users preferred language.

The issue is that current = SCIM core schema spec allows only one preferred language to be specified = while in other systems such as LDAP the =93preferredLanguage=94 = attribute uses a value compatible with accept-language headers (http://tools.ietf.= org/html/rfc2798#section-2.7 ).  For example:
  = "da, en-gb;q=3D0.8, = en;q=3D0.7=94 means I prefer = Danish but will accept British English and other types of = English.

On a positive note, the LDAP = form which uses =93language-range=94 defined [RFC4647], = Section 2.1 appears to be backwards compatible with the = single language definition we currently = have.

One worry that was expressed was that in = the cloud we have less dependency on a user-agents being able to = correctly negotiate languages for users. While some browsers are = dedicated to users (eg smartphones), others are becoming increasingly = shared such as kiosks.  Being able to pull accept-language = information from a User=92s profile is very = important.

Any concerns with expanding = preferredLanguage to allow for language-range per = RFC4647?

= --Apple-Mail=_76075065-D9BC-4E27-9348-28066EA9E8C3-- From nobody Thu Apr 24 10:18: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 0B5F71A02AD for ; Thu, 24 Apr 2014 10:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 Q5pgFBM5OBJo for ; Thu, 24 Apr 2014 10:18:34 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5E32E1A02B5 for ; Thu, 24 Apr 2014 10:18:34 -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 s3OHIQRV002898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Apr 2014 17:18:27 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 s3OHIPMD021924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Apr 2014 17:18:26 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 s3OHIPd3021917 for ; Thu, 24 Apr 2014 17:18:25 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 Apr 2014 10:18:25 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_9711C24D-3075-4C43-B8BD-2B705B94485D" Message-Id: <7237F52E-BD1D-42EA-A59E-9070E234AF3D@oracle.com> Date: Thu, 24 Apr 2014 10:18:16 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/xo518wd7BJJ9Hh17wTIDuPXSUtE Subject: [scim] Ticket 71 - Language tags - proposed text 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, 24 Apr 2014 17:18:37 -0000 --Apple-Mail=_9711C24D-3075-4C43-B8BD-2B705B94485D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ticket 71 is about updates to the spec to conform with IETF best = practices regarding language tags. The good news here is I believe these should have no breaking changes = and essentially changes some of the references (e.g. from Olson timezone = database to IANA Timezone Database format). preferredLanguage has been extended to allow for a user to indicate = multiple language preferences using the Accept-Language HTTP header = format. For those of use using LDAP, it is also compatible with LDAP=92s = definition. I am led to believe that while some may be already using the = single preferred language definition from previous drafts, that this = change should be compatible. Proposed text: > preferredLanguage Indicates the user's preferred written or spoken > languages and is generally used for selecting a localized User > interface. The value indicates the set of natural languages = that > are preferred. The format of the value is same as the Accept- > Language header field (not including "Accept-Language:") of HTTP > and is specified in Section 5.3.5 of > [I-D.ietf-httpbis-p2-semantics]. The intent of this value is to > enable cloud applications to perform matching of language tags > [RFC4647] to the user's language preferences regardless of what > may be indicated by a user agent (which might be shared), or in = an > interaction not involving a browser or direct interaction with = the > User (such as in a delegated OAuth2 [RFC6749] style interaction) > and normal Accept-Language header negotiation cannot take place. >=20 > locale Used to indicate the User's default location for purposes = of > localizing items such as currency, date time format, numerical > representations, etc. A valid value is a language tag as = defined > in [RFC5646]. Computer languages are explicitly excluded. >=20 > A language tag is a sequence of one or more case-insensitive > subtags, each separated by a hyphen character ("-", %x2D). For > backwards compatibility reasons, servers MAY accept tags = separated > by an underscore character ("_", %5F). In most cases, a = language > tag consists of a primary language subtag that identifies a = broad > family of related languages (e.g., "en" =3D English) which is > optionally followed by a series of subtags that refine or narrow > that language's range (e.g., "en-CA" =3D the variety of English = as > communicated in Canada). Whitespace is not allowed within a > language tag. Example tags include: >=20 > fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN >=20 > See [RFC5646] for further information. >=20 > timezone The User's time zone in IANA Time Zone database format > [RFC6557], also known as "Olson" timezone database > format[Olson-TZ]; For example: "America/Los_Angeles". Please let me know if there are any objections to the above text. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_9711C24D-3075-4C43-B8BD-2B705B94485D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Ticket 71 is about updates to the spec to = conform with IETF best practices regarding language = tags.

The good news here is I believe these = should have no breaking changes and essentially changes some of the = references (e.g. from Olson timezone database to IANA Timezone Database = format).

preferredLanguage has been extended to = allow for a user to indicate multiple language preferences using the = Accept-Language HTTP header format. For those of use using LDAP, it is = also compatible with LDAP=92s definition. I am led to believe that while = some may be already using the single preferred language definition from = previous drafts, that this change should be = compatible.

Proposed text:
   preferredLanguage  Indicates the user's preferred =
written or spoken
      languages and is generally used for selecting a localized User
      interface.  The value indicates the set of natural languages that
      are preferred.  The format of the value is same as the Accept-
      Language header field (not including "Accept-Language:") of HTTP
      and is specified in Section 5.3.5 of
      [I-D.ietf-httpbis-p2-semantics].  The intent of this value is to
      enable cloud applications to perform matching of language tags
      [RFC4647] to the user's language preferences regardless of what
      may be indicated by a user agent (which might be shared), or in an
      interaction not involving a browser or direct interaction with the
      User (such as in a delegated OAuth2 [RFC6749] style interaction)
      and normal Accept-Language header negotiation cannot take place.

   locale  Used to indicate the User's default location for purposes of
      localizing items such as currency, date time format, numerical
      representations, etc.  A valid value is a language tag as defined
      in [RFC5646].  Computer languages are explicitly excluded.

      A language tag is a sequence of one or more case-insensitive
      subtags, each separated by a hyphen character ("-", %x2D).  For
      backwards compatibility reasons, servers MAY accept tags separated
      by an underscore character ("_", %5F).  In most cases, a language
      tag consists of a primary language subtag that identifies a broad
      family of related languages (e.g., "en" =3D English) which is
      optionally followed by a series of subtags that refine or narrow
      that language's range (e.g., "en-CA" =3D the variety of English as
      communicated in Canada).  Whitespace is not allowed within a
      language tag.  Example tags include:

           fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN

      See [RFC5646] for further information.

   timezone  The User's time zone in IANA Time Zone database format
      [RFC6557], also known as "Olson" timezone database
      format[Olson-TZ]; For example: =
"America/Los_Angeles".
Please let me know = if there are any objections to the above text.


= --Apple-Mail=_9711C24D-3075-4C43-B8BD-2B705B94485D-- From nobody Thu Apr 24 11:32:19 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 613F61A039B for ; Thu, 24 Apr 2014 11:32:12 -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 0h6l6TKUBrqV for ; Thu, 24 Apr 2014 11:32:10 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 99A5D1A02BA for ; Thu, 24 Apr 2014 11:32:09 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id n15so2374367lbi.28 for ; Thu, 24 Apr 2014 11:32:02 -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=PwYCH6wgex1M//H2fQBe5mSu5UeIBsfhlzKMHascVEM=; b=KqeQG9CgvM///Uvj5vD75KRJUnPRveQJ9TdRuhHl4V1ghHFHr6Pq/ofdoPZvy/Q0ZS x4PbUdHpZpkE+78RTPl+CY/I84EZpZK7qfKcWrDnmbMc6CIu2fDMzVMXHB2rfhrflQEQ y7ejOl/QkcF95vA+rfo0JvdukpCWuCE9RiSyAfKyxXsIdvYcmYXobglzmBZFd9qCzlWn gzJ4VIxas0qkCsUofeF8fVSXoOCPpbV9icJwNJ4AwR4AWnm7k6v+ltuoQso5QfGmwNSa GksExU5zdvwhMOWTTk74saMOSYoLEMU36ApnEU9oC1IIzQkNJwu9ce7dXFol6l9goad8 vzYA== X-Gm-Message-State: ALoCoQmkorUKp7VOk73Pd45dl52MxlVoGeahJnyeA18UdIP/VAjFR9zRyjVgatWGHHjSoaU5/WCm X-Received: by 10.152.37.99 with SMTP id x3mr2190931laj.7.1398364322579; Thu, 24 Apr 2014 11:32:02 -0700 (PDT) Received: from [10.0.0.113] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id r2sm4294435laa.5.2014.04.24.11.32.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Apr 2014 11:32:01 -0700 (PDT) Message-ID: <5359589F.7060309@mnt.se> Date: Thu, 24 Apr 2014 20:31:59 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: scim@ietf.org References: <7237F52E-BD1D-42EA-A59E-9070E234AF3D@oracle.com> In-Reply-To: <7237F52E-BD1D-42EA-A59E-9070E234AF3D@oracle.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/giqiL7lorLEIpnfZGV-FpS8HYQM Subject: Re: [scim] Ticket 71 - Language tags - proposed text 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, 24 Apr 2014 18:32:12 -0000 On 2014-04-24 19:18, Phil Hunt wrote: > Ticket 71 is about updates to the spec to conform with IETF best practices regarding language tags. > > The good news here is I believe these should have no breaking changes and essentially changes some of the references (e.g. from Olson timezone database to IANA Timezone Database format). > > preferredLanguage has been extended to allow for a user to indicate multiple language preferences using the Accept-Language HTTP header format. For those of use using LDAP, it is also compatible with LDAP’s definition. I am led to believe that while some may be already using the single preferred language definition from previous drafts, that this change should be compatible. > Speaking as an old LDAP hand I say "+1" > Proposed text: >> preferredLanguage Indicates the user's preferred written or spoken >> languages and is generally used for selecting a localized User >> interface. The value indicates the set of natural languages that >> are preferred. The format of the value is same as the Accept- >> Language header field (not including "Accept-Language:") of HTTP >> and is specified in Section 5.3.5 of >> [I-D.ietf-httpbis-p2-semantics]. The intent of this value is to >> enable cloud applications to perform matching of language tags >> [RFC4647] to the user's language preferences regardless of what >> may be indicated by a user agent (which might be shared), or in an >> interaction not involving a browser or direct interaction with the >> User (such as in a delegated OAuth2 [RFC6749] style interaction) >> and normal Accept-Language header negotiation cannot take place. >> >> locale Used to indicate the User's default location for purposes of >> localizing items such as currency, date time format, numerical >> representations, etc. A valid value is a language tag as defined >> in [RFC5646]. Computer languages are explicitly excluded. >> >> A language tag is a sequence of one or more case-insensitive >> subtags, each separated by a hyphen character ("-", %x2D). For >> backwards compatibility reasons, servers MAY accept tags separated >> by an underscore character ("_", %5F). In most cases, a language >> tag consists of a primary language subtag that identifies a broad >> family of related languages (e.g., "en" = English) which is >> optionally followed by a series of subtags that refine or narrow >> that language's range (e.g., "en-CA" = the variety of English as >> communicated in Canada). Whitespace is not allowed within a >> language tag. Example tags include: >> >> fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN >> >> See [RFC5646] for further information. >> >> timezone The User's time zone in IANA Time Zone database format >> [RFC6557], also known as "Olson" timezone database >> format[Olson-TZ]; For example: "America/Los_Angeles". > > Please let me know if there are any objections to the above text. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From nobody Fri Apr 25 16:33:49 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 883891A06D4 for ; Fri, 25 Apr 2014 16:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.473 X-Spam-Level: X-Spam-Status: No, score=-14.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 7PR_5q93Kvu8 for ; Fri, 25 Apr 2014 16:33:44 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7040E1A06D3 for ; Fri, 25 Apr 2014 16:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2203; q=dns/txt; s=iport; t=1398468818; x=1399678418; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7tR+mYNHv0bP1dwJ1d5zwEFU7duBDqAZBw1jUBB/IKk=; b=kJDqGUNU94dIfl83TvrXfoZmrdDM9dW2oS3VJSzZByO49QafLrOJH6qg oop0Vu4PMI6ZDwYxaFprg/hOUoJAZah5dRQG/5ea5PHb1ak0BfmQkAktX fAHl7riLrLvwRn363vs8OHwdqSjhXNuFB7DBsM5adT6FILEpnQ32+woUF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAI7vWlOtJA2I/2dsb2JhbABYgwZPV7xqhziBExZ0giUBAQEEAQEBawsMBAIBCBEEAQEBJwcnCxQJCAIEAQ0FiEENykEXjXcRAQsSMwcGhDMEiTOPUpJcgzGBawcXBhw X-IronPort-AV: E=Sophos;i="4.97,930,1389744000"; d="scan'208";a="320458221" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP; 25 Apr 2014 23:33:38 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3PNXb2k016653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 23:33:37 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.226]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 18:33:37 -0500 From: "Morteza Ansari (moransar)" To: Kelly Grizzle , Phil Hunt , =?iso-8859-1?Q?Thorsten_Ro=DFner?= Thread-Topic: [scim] Ticket #3 - Exclude Attributes explicitly Thread-Index: AQHOyyfTDdEmUHtZ20Skr0RfOMzxEJn5b/GAgAAEP4CBKpGHAA== Date: Fri, 25 Apr 2014 23:33:37 +0000 Message-ID: References: <525FC2AF.5060002@tarent.de> <114ba48e23474f57a433facb4790c80a@BN1PR04MB392.namprd04.prod.outlook.com> In-Reply-To: <114ba48e23474f57a433facb4790c80a@BN1PR04MB392.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.121.64] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9B0E4CA010F6084BBF7F6411B56DE44D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/5vRUVDt-pckBAX2KcVg2BJRP9jY Cc: "scim@ietf.org" Subject: Re: [scim] Ticket #3 - Exclude Attributes explicitly 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, 25 Apr 2014 23:33:46 -0000 Continuing conversation on an old thread. Without full text for the suggested change it is not clear to me what SHOULD means in this context. What=B9s the behavior if the client ask for it, but the server has not implemented it? Does it mean server SHOULD support exclude attribute and return error if a query includes excluded attribute parameter if it doesn=B9t OR does it mean server SHOULD support i= t and if it doesn=B9t it can ignore it and return the full set of attributes back to the client? I do worry about interoperability with adding another SHOULD which means clients need to deal with it one way or another. Looking at the ticket and email it is not clear to me which SHOULD we are recommending. Cheers, Morteza On 10/17/13, 11:07 AM, "Kelly Grizzle" wrote: >+1 > >-----Original Message----- >From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >Phil Hunt >Sent: Thursday, October 17, 2013 11:52 AM >To: Thorsten Ro=DFner >Cc: scim@ietf.org >Subject: Re: [scim] Ticket #3 - Exclude Attributes explicitly > >+1 > >Phil > >@independentid >www.independentid.com >phil.hunt@oracle.com > >On 2013-10-17, at 3:57 AM, Thorsten Ro=DFner wrote: > >> Hi all >>=20 >> from my perspective the ticket covers a very reasonable enhancement, >> as long as it is a "SHOULD" in the standard. >>=20 >> It would not add complexity to simple SCIM implementations, while >> clients that send a requests to a server that does not support the >> attribute exclusion still should retrieve data they can work with... >> if they do not perform some sort of strict schema validation against a >> stripped-down schema. >>=20 >> What do you think? >>=20 >> Thanks >> Thorsten >> _______________________________________________ >> 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 Fri Apr 25 17:12:02 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 D6CE61A06B9 for ; Fri, 25 Apr 2014 17:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 Yrw36Q85eYSK for ; Fri, 25 Apr 2014 17:11:54 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9021A06D4 for ; Fri, 25 Apr 2014 17:11:36 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s3Q0BRW7027636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 26 Apr 2014 00:11:28 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3Q0BPIs015530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Apr 2014 00:11:27 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 s3Q0BPsk015527; Sat, 26 Apr 2014 00:11:25 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 Apr 2014 17:11:25 -0700 References: <525FC2AF.5060002@tarent.de> <114ba48e23474f57a433facb4790c80a@BN1PR04MB392.namprd04.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <8AED36EE-7F10-4A75-BF48-9B3FCD2BA38B@oracle.com> X-Mailer: iPhone Mail (11D167) From: Phil Hunt Date: Fri, 25 Apr 2014 17:11:23 -0700 To: "Morteza Ansari (moransar)" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/nb5F_5gcwUKs9rw89XVbn60XYTU Cc: =?utf-8?Q?Thorsten_Ro=C3=9Fner?= , "scim@ietf.org" , Kelly Grizzle Subject: Re: [scim] Ticket #3 - Exclude Attributes explicitly 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, 26 Apr 2014 00:12:01 -0000 I think if we support it has to be mandatory for those that implement search= . Too complex to have options within options.=20 FWIW. While I think must is important, am neutral on the feature. =20 Phil > On Apr 25, 2014, at 16:33, "Morteza Ansari (moransar)" wrote: >=20 > Continuing conversation on an old thread. >=20 > Without full text for the suggested change it is not clear to me what > SHOULD means in this context. What=C2=B9s the behavior if the client ask f= or > it, but the server has not implemented it? Does it mean server SHOULD > support exclude attribute and return error if a query includes excluded > attribute parameter if it doesn=C2=B9t OR does it mean server SHOULD suppo= rt it > and if it doesn=C2=B9t it can ignore it and return the full set of attribu= tes > back to the client? >=20 > I do worry about interoperability with adding another SHOULD which means > clients need to deal with it one way or another. Looking at the ticket > and email it is not clear to me which SHOULD we are recommending. >=20 >=20 > Cheers, > Morteza >=20 >> On 10/17/13, 11:07 AM, "Kelly Grizzle" wrot= e: >>=20 >> +1 >>=20 >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >> Phil Hunt >> Sent: Thursday, October 17, 2013 11:52 AM >> To: Thorsten Ro=C3=9Fner >> Cc: scim@ietf.org >> Subject: Re: [scim] Ticket #3 - Exclude Attributes explicitly >>=20 >> +1 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On 2013-10-17, at 3:57 AM, Thorsten Ro=C3=9Fner wr= ote: >>>=20 >>> Hi all >>>=20 >>> from my perspective the ticket covers a very reasonable enhancement, >>> as long as it is a "SHOULD" in the standard. >>>=20 >>> It would not add complexity to simple SCIM implementations, while >>> clients that send a requests to a server that does not support the >>> attribute exclusion still should retrieve data they can work with... >>> if they do not perform some sort of strict schema validation against a >>> stripped-down schema. >>>=20 >>> What do you think? >>>=20 >>> Thanks >>> Thorsten >>> _______________________________________________ >>> 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 >> _______________________________________________ >> 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 Apr 28 05:35:22 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 77B151A09EF for ; Mon, 28 Apr 2014 05:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, 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 JIqKekAHPLGD for ; Mon, 28 Apr 2014 05:35:18 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3931A0710 for ; Mon, 28 Apr 2014 05:35:18 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id pv20so501515lab.19 for ; Mon, 28 Apr 2014 05:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:message-id:subject:mime-version:content-type; bh=eGx3ZtwHUqPSs1Mj+VfAAoGvee4VJfjPeBRI/WyFvus=; b=pE3y6CPC3DRtvSUqunQ4HxjlY+LDoS3Xxsq8Hnss/vhVUNxYKrHE96d3j9cXTkDfk4 A/wxsoQZuu9AuMqmZZpSRT1Q/EX0NCYwQO1TMCNNLvSqB8qVuiiAsfJd9e/Rpqonuq31 6xefSCZ7LnK1MouKT6Mrafs37uFqByMvBsq25Y7o2z4bb6IgW7Z+K3GVx3Q/FS3xfZBU TrEtj3o5dLQvfO4pWKtw1zZPctPkUCnvjCc9wUPj2QiHpLhQuMYvLrLqsWKvq5SO422m 9NoVZdiItidBxzUH2EloHp9W/sMEAwBFcH5IZaFTSz8x08aQsfNxSJmQqoT8uDKaoFs9 VU7g== X-Received: by 10.152.234.130 with SMTP id ue2mr19200463lac.0.1398688516974; Mon, 28 Apr 2014 05:35:16 -0700 (PDT) Received: from andreas-home.local ([94.246.37.42]) by mx.google.com with ESMTPSA id lc3sm18808021lbb.21.2014.04.28.05.35.15 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 05:35:16 -0700 (PDT) Sender: =?UTF-8?Q?Andreas_=C3=85kre_Solberg?= Date: Mon, 28 Apr 2014 14:35:14 +0200 From: =?utf-8?Q?Andreas_=C3=85kre_Solberg?= To: scim@ietf.org Message-ID: X-Mailer: Airmail (237) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="535e4b02_1befd79f_67de" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/k3ri29VqfbVT7Ub0Sq6wbgPsF1Y Subject: [scim] Multi-lingual support for some textual attributes 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, 28 Apr 2014 12:35:20 -0000 --535e4b02_1befd79f_67de Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi folks, this is my first post, let me give a brief introduction: I=E2=80=99m working with APIs for exchanging group information in federat= ed environments, and work with a specification with the nickname =E2=80=9C= VOOT=E2=80=9D. We are currently exploring the possibility to define this = as a layer on top of SCIM. Although it looks very promosing, there is a n= umber of minor issues that we need to resort in order to be fully complia= nt. =46irst out, given our European target community, the need for multi-ling= ual support is rather fundamental. My assumption is that there is currently no multi-lingual support in SCIM= =3F Has this question been raised before, and if so any references=3F If we would like to add attributes in multiple languages, it seems that c= omplex attributes is the closest fit, but it does not feel compleley righ= t either. What do you think about introducing a new attribute type, translatableStr= ing which allows both plain backward-compatible representation of unspeci= fied language: =7B =22displayName=22: =22University X=22 =7D as well as one specific translation: =7B =22displayName=22: =7B =22en=22: =22University X=22 =7D =7D as well as multiple translations: =7B =22displayName=22: =7B =22en=22: =22University X=22, =22no=22: =22Universitet X=22 =7D =7D where the object properties used is defined by xml:lang. It would also be nice to add support in the protocol for optionally flatt= ening the translatableStrings in the response based upon HTTP content neg= otiation with Accept-Language. In example like this: GET /Resource/X=3Ftranslate=3D1 HTTP/1.0 Accept-Language: no =7B =22displayName=22: =22Universitet X=22 =7D --=C2=A0 Andreas =C3=85kre Solberg UNINET AS - http://uninett.no --535e4b02_1befd79f_67de Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi folks, this i= s my first post, let me give a brief introduction:

I=E2=80=99m working with APIs for exchanging group information in fede= rated environments, and work with a specification with the nickname =E2=80= =9CVOOT=E2=80=9D. We are currently exploring the possibility to define th= is as a layer on top of SCIM. Although it looks very promosing, there is = a number of minor issues that we need to resort in order to be fully = compliant.

=46irst out, given our European target community, the need for multi-l= ingual support is rather fundamental.

My assumption is that there is currently no multi-lingual supp= ort in SCIM=3F

Has this question been raised before, and if so any references=3F

If we would like to add attributes in multiple languages, it seems tha= t complex attributes is the closest fit, but it does not feel co= mpleley right either.

What do you think about introducing a new attribute type, transl= atableString which allows both plain backward-compatible represent= ation of unspecified language:

=7B
    =22displayName=22: =22University X=22
=7D

as well as one specific translation:

=7B
    =22displayName=22: =7B
        =22en=22: =22University X=22
    =7D
=7D

as well as multiple translations:

=7B
    =22displayName=22: =7B
        =22en=22: =22University X=22,
        =22no=22: =22Universitet X=22
    =7D
=7D

where the object properties used is defined by xml:lang.<= /p>

It would also be nice to add support in the protocol for optionally flattening the translatableStrings in the response ba= sed upon HTTP content negotiation with Accept-Language.

In example like this:

GET /Resource/X=3Ftranslate=3D1 HTTP/1.0
Accept-Language: no

=7B
    =22displayName=22: =22Universitet X=22
=7D

body =7B font-family: =22Helvetica Neue=22, Helvetica, Arial, sans-serif; padding:1em; margin:auto; background:=23fefefe; =7D h1, h2, h3, h4, h5, h6 =7B font-weight: bold; =7D h1 =7B color: =23000000; font-size: 28pt; =7D h2 =7B border-bottom: 1px solid =23CCCCCC; color: =23000000; font-size: 24px; =7D h3 =7B font-size: 18px; =7D h4 =7B font-size: 16px; =7D h5 =7B font-size: 14px; =7D h6 =7B color: =23777777; background-color: inherit; font-size: 14px; =7D hr =7B height: 0.2em; border: 0; color: =23CCCCCC; background-color: =23CCCCCC; =7D p, blockquote, ul, ol, dl, li, table, pre =7B margin: 15px 0; =7D a, a:visited =7B color: =234183C4; background-color: inherit; text-decoration: none; =7D =23message =7B border-radius: 6px; border: 1px solid =23ccc; display:block; width:100%; height:60px; margin:6px 0px; =7D button, =23ws =7B font-size: 12 pt; padding: 4px 6px; border-radius: 5px; border: 1px solid =23bbb; background-color: =23eee; =7D code, pre, =23ws, =23message =7B font-family: Monaco; font-size: 10pt; border-radius: 3px; background-color: =23=468=468=468; color: inherit; =7D code =7B border: 1px solid =23EAEAEA; margin: 0 2px; padding: 0 5px; =7D pre =7B border: 1px solid =23CCCCCC; overflow: auto; padding: 4px 8px; =7D pre > code =7B border: 0; margin: 0; padding: 0; =7D =23ws =7B background-color: =23f8f8f8; =7D table =7B border-collapse: collapse; =20 font-family: Helvetica, arial, freesans, clean, sans-serif; =20 color: rgb(51, 51, 51); =20 font-size: 15px; line-height: 25px; padding: 0; =7D table tr =7B border-top: 1px solid =23cccccc; background-color: white; margin: 0; padding: 0; =7D =20 table tr:nth-child(2n) =7B background-color: =23f8f8f8; =7D table tr th =7B font-weight: bold; border: 1px solid =23cccccc; margin: 0; padding: 6px 13px; =7D table tr td =7B border: 1px solid =23cccccc; margin: 0; padding: 6px 13px; =7D table tr th :first-child, table tr td :first-child =7B margin-top: 0; =7D table tr th :last-child, table tr td :last-child =7B margin-bottom: 0; =7D .send =7B color:=2377bb77; =7D .server =7B color:=237799bb; =7D .error =7B color:=23AA0000; =7D



-- 
An= dreas =C3=85kre Solberg
UNINET AS - http://uninett.no

--535e4b02_1befd79f_67de-- From nobody Mon Apr 28 09:10:37 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 24C001A066A for ; Mon, 28 Apr 2014 09:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 H8cbs2mBSwev for ; Mon, 28 Apr 2014 09:10:33 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 720E11A048C for ; Mon, 28 Apr 2014 09:10:33 -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 s3SGAVdV021206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Apr 2014 16:10:32 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3SGATXh020242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Apr 2014 16:10:30 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 s3SGATUC012859; Mon, 28 Apr 2014 16:10:29 GMT Received: from [192.168.1.186] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Apr 2014 09:10:29 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_63FDC5CB-F06A-4F35-BD3C-28E3C0E14525" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: Date: Mon, 28 Apr 2014 09:10:27 -0700 Message-Id: <394D5690-3650-4EBB-91A8-92D4B6764834@oracle.com> References: To: =?iso-8859-1?Q?Andreas_=C5kre_Solberg?= X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/M-lFUE-m82UrHmA89WOZ0sTO3NY Cc: scim@ietf.org Subject: Re: [scim] Multi-lingual support for some textual attributes 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, 28 Apr 2014 16:10:36 -0000 --Apple-Mail=_63FDC5CB-F06A-4F35-BD3C-28E3C0E14525 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Andreas, Your question is timely as I am just going through some of the = internationalization support details for the next draft of core-schema. I believe your question goes to the ability to have multiple = translations (at the same time) for an attribute of a resource. This was actually discussed (in Berlin?) at length and at the time there = was no interest in this aspect of international support. This view may be coming from LDAP hands where there was support but the = feature was rarely used. Is this view still valid in the cloud? The = collective view at the time was it wasn=92t needed.=20 My major concern is that the solution would most likely require turning = multi-lingual attributes into complex attributes (as you describe). = This makes the protocol significantly more complex. Though that said, = recent changes with the API draft now make this much easier to support = since you can now update specific sub-attributes of complex attributes. Could your case be handled using attribute extensions? In this case the = core schema value would be the default or preferred language of the user = or the owner of the resource (e.g. group). The extension would then = contain the complex attribute structure you require.=20 Do we need a multi-lingual attribute definition? =97> so that at least = multi-language attributes are handled consistently? Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 28, 2014, at 5:35 AM, Andreas =C5kre Solberg = wrote: > Hi folks, this is my first post, let me give a brief introduction: >=20 > I=92m working with APIs for exchanging group information in federated = environments, and work with a specification with the nickname =93VOOT=94. = We are currently exploring the possibility to define this as a layer on = top of SCIM. Although it looks very promosing, there is a number of = minor issues that we need to resort in order to be fully compliant. >=20 > First out, given our European target community, the need for = multi-lingual support is rather fundamental. >=20 > My assumption is that there is currently no multi-lingual support in = SCIM? >=20 > Has this question been raised before, and if so any references? >=20 > If we would like to add attributes in multiple languages, it seems = that complex attributes is the closest fit, but it does not feel = compleley right either. >=20 > What do you think about introducing a new attribute type, = translatableString which allows both plain backward-compatible = representation of unspecified language: >=20 > { > "displayName": "University X" > } > as well as one specific translation: >=20 > { > "displayName": { > "en": "University X" > } > } > as well as multiple translations: >=20 > { > "displayName": { > "en": "University X", > "no": "Universitet X" > } > } > where the object properties used is defined by xml:lang. >=20 > It would also be nice to add support in the protocol for optionally = flattening the translatableStrings in the response based upon HTTP = content negotiation with Accept-Language. >=20 > In example like this: >=20 > GET /Resource/X?translate=3D1 HTTP/1.0 > Accept-Language: no >=20 > { > "displayName": "Universitet X" > } >=20 >=20 > --=20 > Andreas =C5kre Solberg > UNINET AS - http://uninett.no >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_63FDC5CB-F06A-4F35-BD3C-28E3C0E14525 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Andreas,

Your question is timely = as I am just going through some of the internationalization support = details for the next draft of core-schema.

I = believe your question goes to the ability to have multiple translations = (at the same time) for an attribute of a = resource.

This was actually discussed (in = Berlin?) at length and at the time there was no interest in this aspect = of international support.

This view may be = coming from LDAP hands where there was support but the feature was = rarely used. Is this view still valid in the cloud?  The collective = view at the time was it wasn=92t = needed. 

My major concern is that the = solution would most likely require turning multi-lingual attributes into = complex attributes (as you describe).  This makes the protocol = significantly more complex.  Though that said, recent changes with = the API draft now make this much easier to support since you can now = update specific sub-attributes of complex = attributes.

Could your case be handled using attribute extensions? =  In this case the core schema value would be the default or = preferred language of the user or the owner of the resource (e.g. = group).  The extension would then contain the complex attribute = structure you require. 

Do we = need a multi-lingual attribute definition? =97> so that at least = multi-language attributes are handled = consistently?

Phil

On Apr 28, 2014, at 5:35 AM, Andreas =C5kre Solberg <andreas.solberg@uninett.no&= gt; wrote:

Hi folks, this is my = first post, let me give a brief introduction:

I=92m working with = APIs for exchanging group information in federated environments, and = work with a specification with the nickname =93VOOT=94. We are currently = exploring the possibility to define this as a layer on top of SCIM. = Although it looks very promosing, there is a number of minor issues that = we need to resort in order to be fully compliant.

First = out, given our European target community, the need for multi-lingual = support is rather fundamental.

My assumption is that = there is currently no multi-lingual support in SCIM?

Has = this question been raised before, and if so any references?

If we = would like to add attributes in multiple languages, it seems that = complex attributes is the closest fit, but it does not feel = compleley right either.

What do you think about introducing a new = attribute type, translatableString which allows both plain = backward-compatible representation of unspecified language:

{
    "displayName": "University X"
}

as well as one specific translation:

{
    "displayName": {
        "en": "University X"
    }
}

as well as multiple translations:

{
    "displayName": {
        "en": "University X",
        "no": "Universitet X"
    }
}

where the object properties used is defined by = xml:lang.

It would also be nice to add support in the = protocol for optionally flattening the = translatableStrings in the response based upon HTTP content = negotiation with Accept-Language.

In example like = this:

GET /Resource/X?translate=3D1 HTTP/1.0
Accept-Language: no

{
    "displayName": "Universitet X"
}
=



-- 
Andr= eas =C5kre Solberg
UNINET AS - http://uninett.no


___________________________= ____________________
scim mailing list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_63FDC5CB-F06A-4F35-BD3C-28E3C0E14525-- From nobody Mon Apr 28 20:53: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 8C1711A08AD; Mon, 28 Apr 2014 20:53:00 -0700 (PDT) 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 em2mOCh1dj3e; Mon, 28 Apr 2014 20:52:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AA91A084F; Mon, 28 Apr 2014 20:52:58 -0700 (PDT) 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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140429035258.26828.93016.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 20:52:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/f6SakH6wA2r_8vEVSc4Zn4XcIfM Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-04.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, 29 Apr 2014 03:53:01 -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 : System for Cross-Domain Identity Management: Core Schema Authors : Kelly Grizzle Phil Hunt Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-core-schema-04.txt Pages : 57 Date : 2014-04-28 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move identity in to, out of, and around the cloud. This document provides a platform neutral schema and extension model for representing users and groups in JSON format. This schema is intended for exchange and use with cloud service providers. Additional binding documents provide a standard REST API, SAML binding, and use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-core-schema-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-04 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 Mon Apr 28 20:57: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 F330F1A085A for ; Mon, 28 Apr 2014 20:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 k7MPKuVn5RGK for ; Mon, 28 Apr 2014 20:57:33 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 24E9D1A8835 for ; Mon, 28 Apr 2014 20:57:21 -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 s3T3vJ2x020768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 Apr 2014 03:57:20 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3T3vIP3009347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Apr 2014 03:57:19 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3T3vHLA017015 for ; Tue, 29 Apr 2014 03:57:18 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Apr 2014 20:57:17 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: <20140429035258.26828.93016.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 20:57:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140429035258.26828.93016.idtracker@ietfa.amsl.com> To: "scim@ietf.org WG" X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/sE9JZHfuratm6Z8UOmbK3nMM0b8 Subject: Re: [scim] I-D Action: draft-ietf-scim-core-schema-04.txt 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, 29 Apr 2014 03:57:36 -0000 Draft 04 addresses the following tickets: 43 - Drop short-hand notation for complex multi-valued attributes 61 - Specify attribute name limitations 62 - Fix 'mutability' normative language 63 - Fix incorrect EnterpriseUser schema reference 68 - Update JSON references from RFC4627 to RFC7159 71 - Made corrections to language tags in compliance with BCP47 / RFC5646 These items should are for the most part clarifications and should not = represent breaking changes.=20 Note that preferredLanguage now allows for multiple preferredLanguages = to be specified per the Accept-Language HTTP header format. This is also = consistent with LDAP=92s definition of preferredLanguage as well. Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 28, 2014, at 8:52 PM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : System for Cross-Domain Identity Management: = Core Schema > Authors : Kelly Grizzle > Phil Hunt > Erik Wahlstroem > Chuck Mortimore > Filename : draft-ietf-scim-core-schema-04.txt > Pages : 57 > Date : 2014-04-28 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) specification > is designed to make managing user identity in cloud based > applications and services easier. The specification suite builds > upon experience with existing schemas and deployments, placing > specific emphasis on simplicity of development and integration, = while > applying existing authentication, authorization, and privacy models. > Its intent is to reduce the cost and complexity of user management > operations by providing a common user schema and extension model, as > well as binding documents to provide patterns for exchanging this > schema using standard protocols. In essence, make it fast, cheap, > and easy to move identity in to, out of, and around the cloud. >=20 > This document provides a platform neutral schema and extension model > for representing users and groups in JSON format. This schema is > intended for exchange and use with cloud service providers. > Additional binding documents provide a standard REST API, SAML > binding, and use cases. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-scim-core-schema-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-core-schema-04 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue Apr 29 02:42: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 549AB1A0707 for ; Tue, 29 Apr 2014 02:42:55 -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 rbyoHlb7toBr for ; Tue, 29 Apr 2014 02:42:52 -0700 (PDT) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id A92D91A0118 for ; Tue, 29 Apr 2014 02:42:50 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id e53so80034eek.11 for ; Tue, 29 Apr 2014 02:42:49 -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=WY0t/RJi2d9I2zScvxLK5rjF7Kb37eMRasTN8bUxAuU=; b=OJu2XiuBYJ8dFGoB3BGzRzwWdBBixCGUlRUlWa3us+qAAPHhvJunhhXjbSl5uh2cKv 1IT2V0eFABvcnTklpDvzun6AUh7KQG4LCcd7QpBzfcsf9uCfWUxObdQ8c921QMe7XW5m qyBgRnXiW+D+VTQpRZU7Bozd8Uxep1U77xKr4pQHJhX8Beau7klPR/YiOrAJrt6LhOlL 5Mb7VsPrUkqyRhtdWTQSemQgZ2ags7aEJDB29x/UnIaLLKmhmwWIFnk5Yc4AkCLKjwrc E+9I8t0a1DJiROt6Z3Fv9BkHCjd7LvhPxCINxOQ/2X9OVSHgApVT7o/W7oEsaFOYQIsv 3NUA== X-Gm-Message-State: ALoCoQk+thkwptSZZWihlIIjsroQmQMHNAZ9ikkBonQKpJeG+75bcL4NNQtHEwGjM88T0stiCJUW X-Received: by 10.15.50.136 with SMTP id l8mr1622570eew.73.1398764569212; Tue, 29 Apr 2014 02:42:49 -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 x43sm46063533eeo.26.2014.04.29.02.42.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Apr 2014 02:42:48 -0700 (PDT) Message-ID: <535F7417.3000806@tarent.de> Date: Tue, 29 Apr 2014 11:42:47 +0200 From: =?windows-1252?Q?David_M=F6bius?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: scim@ietf.org References: <394D5690-3650-4EBB-91A8-92D4B6764834@oracle.com> In-Reply-To: <394D5690-3650-4EBB-91A8-92D4B6764834@oracle.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/It9TW_zb2351Z6Y-aLD_m9TjqKA Subject: Re: [scim] Multi-lingual support for some textual attributes 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, 29 Apr 2014 09:42:55 -0000 Hi Andreas, I also think this looks very much like an case for extension. I think you have to look which fields need to be multi language and store the translation in the extensions. If you are exploring the possibility of scim at the moment and working with Java maybe our schim schema could help for you to have minimal effort. With the scim schema we already have an easy possibility to store and to retrieve scim extensions. With the scim schema we are implementing a OpenSource scim 2.0 project. Together with the other OSIAM projects (Server, connector4Java and selfadministration) we have a framework that could help you to have an quick start. In about 2 weeks we will also go to version 1.0 scim schema: https://github.com/osiam/scim-schema osiam main: https://github.com/osiam If you have more question about this please contact me. by David Am 28.04.2014 18:10, schrieb Phil Hunt: > Andreas, > > Your question is timely as I am just going through some of the > internationalization support details for the next draft of core-schema. > > I believe your question goes to the ability to have multiple > translations (at the same time) for an attribute of a resource. > > This was actually discussed (in Berlin?) at length and at the time there > was no interest in this aspect of international support. > > This view may be coming from LDAP hands where there was support but the > feature was rarely used. Is this view still valid in the cloud? The > collective view at the time was it wasn’t needed. > > My major concern is that the solution would most likely require turning > multi-lingual attributes into complex attributes (as you describe). > This makes the protocol significantly more complex. Though that said, > recent changes with the API draft now make this much easier to support > since you can now update specific sub-attributes of complex attributes. > > Could your case be handled using attribute extensions? In this case the > core schema value would be the default or preferred language of the user > or the owner of the resource (e.g. group). The extension would then > contain the complex attribute structure you require. > > Do we need a multi-lingual attribute definition? —> so that at least > multi-language attributes are handled consistently? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Apr 28, 2014, at 5:35 AM, Andreas Åkre Solberg > > wrote: > >> Hi folks, this is my first post, let me give a brief introduction: >> >> I’m working with APIs for exchanging group information in federated >> environments, and work with a specification with the nickname “VOOT”. >> We are currently exploring the possibility to define this as a layer >> on top of SCIM. Although it looks very promosing, there is a number of >> minor issues that we need to resort in order to be fully /compliant/. >> >> First out, given our European target community, the need for >> multi-lingual support is rather fundamental. >> >> *My assumption is that there is currently no multi-lingual support in >> SCIM?* >> >> Has this question been raised before, and if so any references? >> >> If we would like to add attributes in multiple languages, it seems >> that /complex/ attributes is the closest fit, but it does not feel >> compleley right either. >> >> What do you think about introducing a new attribute type, >> |translatableString| which allows both plain backward-compatible >> representation of unspecified language: >> >> |{ >> "displayName": "University X" >> } >> | >> >> as well as one specific translation: >> >> |{ >> "displayName": { >> "en": "University X" >> } >> } >> | >> >> as well as multiple translations: >> >> |{ >> "displayName": { >> "en": "University X", >> "no": "Universitet X" >> } >> } >> | >> >> where the object properties used is defined by |xml:lang|. >> >> It would also be nice to add support in the protocol for optionally >> /flattening/ the |translatableString|s in the response based upon HTTP >> content negotiation with |Accept-Language|. >> >> In example like this: >> >> |GET /Resource/X?translate=1 HTTP/1.0 >> Accept-Language: no >> >> { >> "displayName": "Universitet X" >> } >> | >> >> >> >> -- >> Andreas Åkre Solberg >> UNINET AS - http://uninett.no >> >> >> _______________________________________________ >> 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 Apr 29 10:56: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 4697D1A08DB for ; Tue, 29 Apr 2014 10:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 dgFqQI5zf5x3 for ; Tue, 29 Apr 2014 10:56:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6081A095B for ; Tue, 29 Apr 2014 10:56:46 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s3THuhvg005650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 Apr 2014 17:56:43 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3THughE027740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Apr 2014 17:56:43 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3THugY3017828 for ; Tue, 29 Apr 2014 17:56:42 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Apr 2014 10:56:41 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_9AEDF343-A3E4-46ED-82CD-089C143588BA" Message-Id: <7B8713D9-F682-42BA-AD38-98B285DE3F74@oracle.com> Date: Tue, 29 Apr 2014 10:56:40 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/kBQ2RVZ4AnY4XyBQZW5Uv50OEmw Subject: [scim] How to signal when a query is not eligible for use with HTTP GET (due to PII/security) 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, 29 Apr 2014 17:56:50 -0000 --Apple-Mail=_9AEDF343-A3E4-46ED-82CD-089C143588BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 In the current spec, we have created the POST profile so that searches = with confidential data can be made without exposing confidential data in = the URL (via GET). I had a question from one of our developers about how does the client = know when to use GET vs. POST? a. For all queries? b. Should an attribute have some metadata flagging it as not usable on = GET? c. Should GET return a specific error when a query is to be repeated as = a POST? The concern with c. is that once done the data is exposed. In our = internal group we discussed that this would likely happen the first time = a client starts talking to a new endpoint =97 so either the deployer or = a developer would see the error. IOW, once a client knows an attribute = is =93confidential=94 it wouldn=92t normally keep doing the same thing. I=92m not sure there is a good answer here. Any other ideas? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_9AEDF343-A3E4-46ED-82CD-089C143588BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 In the = current spec, we have created the POST profile so that searches with = confidential data can be made without exposing confidential data in the = URL (via GET).

I had a question from one of our = developers about how does the client know when to use GET vs. = POST?

a.  For all queries?
b. =  Should an attribute have some metadata flagging it as not usable = on GET?
c.  Should GET return a specific error when a = query is to be repeated as a POST?

The concern = with c. is that once done the data is exposed. In our internal group we = discussed that this would likely happen the first time a client starts = talking to a new endpoint =97 so either the deployer or a developer = would see the error.  IOW, once a client knows an attribute is = =93confidential=94 it wouldn=92t normally keep doing the same = thing.

I=92m not sure there is a good answer = here.  Any other ideas?

= --Apple-Mail=_9AEDF343-A3E4-46ED-82CD-089C143588BA-- From nobody Tue Apr 29 12:55:32 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 3B1D31A09A2 for ; Tue, 29 Apr 2014 12:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 oq2bBEyC_Ejf for ; Tue, 29 Apr 2014 12:55:15 -0700 (PDT) Received: from nm32-vm1.bullet.mail.bf1.yahoo.com (nm32-vm1.bullet.mail.bf1.yahoo.com [72.30.239.137]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEA51A097D for ; Tue, 29 Apr 2014 12:55:15 -0700 (PDT) Received: from [66.196.81.172] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 19:55:13 -0000 Received: from [98.139.212.246] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 19:55:13 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 19:55:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 744365.23510.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 46532 invoked by uid 60001); 29 Apr 2014 19:55:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398801313; bh=U9c/ljeGCSHNmR3YrVAFkgLE+shEw0J+wNseWsv4lI4=; 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=fc9fAaAnSQ2cbxT5/l5/RTYv2uLftObPjqvFPScN7V4e2cT5s1MW4ygf0999CyTEF5Fgxq8Tj0B8SFoAtagJO1q2TTUfUGGA0WMdni+EiaBW4I88PG5netxUn4XZJCNS0K/o5xDG983eBZlms4QE/0XEuDgoquxUY/qOcKjp4Bw= X-YMail-OSG: ho1NFwYVM1ngvMdYsA4Gid3AyuHkdrUfORNnc0DgsxaquI7 bSBJEyFglPiTpfCXZrJa.VzDp8BCQk8SLL7fAIm9IHRZPrdvJ.AVYuRNgscM QsjlP7mALBeNMRGYuTRBsZfI27CQ0ws9CUAI6uvBOfE5MmXmgBHAqL2FC1jy EHjsy66qhSGcED3NOLS.mH1qaU7AfMVQzSpvidcXBA0ENrLdydFxsZJlGWcf px.QytIRxcn77EX0UAWm6eEs489GQYZdEfu1RFRAGR9TmxvCPrLt3O6HCAO0 H4uasIuIH7e2jnL5mA.pQTMDnt6Je6j.BLKbGXpl7TQPtuD_nwNzuL9Z813C 7lca9dum5_IO_YA0hotGYbX7M6tNO8Yx.CvRav2NBRKKSiu4hymSoO2cPQhX fmthud_p3w8h4XgcahvRcBP5rPzuNlrzlxNA6oorP0aeCUn0OP1mzezodB.E XUVJyKqHD.GkqEuA5Us9w9IdUa.DFkrssZBfBv1eUORpqbFS2__MiXTSK_GT C1vFbhKTJPtGXK7POfsXzTHxDVYWEteektbwmF2SsvRfHrN0NwMbOaWbbAtO D5_21tH0yjfChr3gnCGpzwDINsLhdl4OCojocynmVThB8Nbok3Vlkw8VG7T_ MaskRv4AxwTD7Ow3e0HiV2V0gE8Fv5ckDH087XuqSH8QzU8toqZqsrpE7 Received: from [66.228.162.36] by web142802.mail.bf1.yahoo.com via HTTP; Tue, 29 Apr 2014 12:55:13 PDT X-Rocket-MIMEInfo: 002.001, SSB0aGluayBpZiB0aGUgc2l0ZSBoYXMgY29uY2VybnMgYWJvdXQgdGhpcyB0aGVuIHRoZXkgb25seSBzdXBwb3J0IFBPU1QgZm9yIHF1ZXJpZXMgYW5kIHJldHVybiBhIDQwNSBmb3IgYWxsIEdFVCB0byB0aGUgcXVlcnkgZW5kcG9pbnQuIMKgVHJ5aW5nIHRvIHBhcnNlIHRoZSBkYXRhIHNlbnQgdG8gZGV0ZXJtaW5lIGd1YXJhbnRlZXMgeW91J2xsIGZhaWwgdG8gcHJvdGVjdCB0aGUgZGF0YSBwcm9wZXJseS4KT24gVHVlc2RheSwgQXByaWwgMjksIDIwMTQgMTA6NTcgQU0sIFBoaWwgSHVudCA8cGhpbC5odW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.185.657 References: <7B8713D9-F682-42BA-AD38-98B285DE3F74@oracle.com> Message-ID: <1398801313.28138.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Tue, 29 Apr 2014 12:55:13 -0700 (PDT) From: Bill Mills To: Phil Hunt , "scim@ietf.org WG" In-Reply-To: <7B8713D9-F682-42BA-AD38-98B285DE3F74@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-1043664930-1398801313=:28138" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/LMXzo4pCEH4oEPS4jh4HrC85rAU Subject: Re: [scim] How to signal when a query is not eligible for use with HTTP GET (due to PII/security) 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, 29 Apr 2014 19:55:18 -0000 --1397251415-1043664930-1398801313=:28138 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think if the site has concerns about this then they only support POST for= queries and return a 405 for all GET to the query endpoint. =C2=A0Trying t= o parse the data sent to determine guarantees you'll fail to protect the da= ta properly.=0AOn Tuesday, April 29, 2014 10:57 AM, Phil Hunt wrote:=0A =0AIn the current spec, we have created the POST profil= e so that searches with confidential data can be made without exposing conf= idential data in the URL (via GET).=0A=0AI had a question from one of our d= evelopers about how does the client know when to use GET vs. POST?=0A=0Aa. = =C2=A0For all queries?=0Ab. =C2=A0Should an attribute have some metadata fl= agging it as not usable on GET?=0Ac. =C2=A0Should GET return a specific err= or when a query is to be repeated as a POST?=0A=0AThe concern with c. is th= at once done the data is exposed. In our internal group we discussed that t= his would likely happen the first time a client starts talking to a new end= point =E2=80=94 so either the deployer or a developer would see the error. = =C2=A0IOW, once a client knows an attribute is =E2=80=9Cconfidential=E2=80= =9D it wouldn=E2=80=99t normally keep doing the same thing.=0A=0AI=E2=80=99= m not sure there is a good answer here. =C2=A0Any other ideas?=0A=0A=0APhil= =0A=0A@independentid=0Awww.independentid.comphil.hunt@oracle.com=0A=0A=0A= =0A_______________________________________________=0Ascim mailing list=0Asc= im@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/scim --1397251415-1043664930-1398801313=:28138 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think if the site has concerns about this then t= hey only support POST for queries and return a 405 for all GET to the query= endpoint.  Trying to parse the data sent to determine guarantees you'= ll fail to protect the data properly.
= On Tuesday, April 29, 2014 10:57 AM, Phil = Hunt <phil.hunt@oracle.com> wrote:
In the current spec, we hav= e created the POST profile so that searches with confidential data can be made without e= xposing confidential data in the URL (via GET).

I had a = question from one of our developers about how does the client know when to = use GET vs. POST?

a.  For all queries?
<= div>b.  Should an attribute have some metadata flagging it as not usab= le on GET?
c.  Should GET return a specific error when a que= ry is to be repeated as a POST?

The concern with c= . is that once done the data is exposed. In our internal group we discussed= that this would likely happen the first time a client starts talking to a = new endpoint =E2=80=94 so either the deployer or a developer would see the = error.  IOW, once a client knows an attribute is =E2=80=9Cconfidential= =E2=80=9D it wouldn=E2=80=99t normally keep doing the same thing.

I=E2=80=99m not sure there is a good answer here.  Any= other ideas?

=0A

_____________________________________= __________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/l= istinfo/scim


--1397251415-1043664930-1398801313=:28138-- From nobody Tue Apr 29 13:15: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 7C46C1A096B for ; Tue, 29 Apr 2014 13:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 desQd9M4FnX4 for ; Tue, 29 Apr 2014 13:15:08 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1102F1A08D8 for ; Tue, 29 Apr 2014 13:15:08 -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 s3TKF6kD031304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Apr 2014 20:15:06 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 s3TKF5wR001646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 20:15:05 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s3TKF4J1007266; Tue, 29 Apr 2014 20:15:04 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Apr 2014 13:15:04 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_BFAA7571-D7CD-401F-8F23-46842C19AC78" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Phil Hunt In-Reply-To: <1398801313.28138.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Tue, 29 Apr 2014 13:15:02 -0700 Message-Id: <07DF1DFA-F17B-4902-93A4-C4BFDFF85FF3@oracle.com> References: <7B8713D9-F682-42BA-AD38-98B285DE3F74@oracle.com> <1398801313.28138.YahooMailNeo@web142802.mail.bf1.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/AIv6JQtIDnOc--9z4k7_gUhdrEs Cc: "scim@ietf.org WG" Subject: Re: [scim] How to signal when a query is not eligible for use with HTTP GET (due to PII/security) 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, 29 Apr 2014 20:15:12 -0000 --Apple-Mail=_BFAA7571-D7CD-401F-8F23-46842C19AC78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Bill, Interesting simplification. However, the URL is still exposed even when = the server returns a 405. But as with the more complex approach, you=92d think clients would = switch to POST for future requests.=20 I think this is mainly a security considerations issue. Other than the obvious =93it is restful to do GET=94, why might a client = *want* or *need* to do a GET? Is it reasonable as Bill suggests that = servers could drop GET in favour of POST search only? Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 29, 2014, at 12:55 PM, Bill Mills wrote: > I think if the site has concerns about this then they only support = POST for queries and return a 405 for all GET to the query endpoint. = Trying to parse the data sent to determine guarantees you'll fail to = protect the data properly. > On Tuesday, April 29, 2014 10:57 AM, Phil Hunt = wrote: > In the current spec, we have created the POST profile so that searches = with confidential data can be made without exposing confidential data in = the URL (via GET). >=20 > I had a question from one of our developers about how does the client = know when to use GET vs. POST? >=20 > a. For all queries? > b. Should an attribute have some metadata flagging it as not usable = on GET? > c. Should GET return a specific error when a query is to be repeated = as a POST? >=20 > The concern with c. is that once done the data is exposed. In our = internal group we discussed that this would likely happen the first time = a client starts talking to a new endpoint =97 so either the deployer or = a developer would see the error. IOW, once a client knows an attribute = is =93confidential=94 it wouldn=92t normally keep doing the same thing. >=20 > I=92m not sure there is a good answer here. Any other ideas? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 --Apple-Mail=_BFAA7571-D7CD-401F-8F23-46842C19AC78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Bill,

Interesting = simplification. However, the URL is still exposed even when the server = returns a 405.

But as with the more complex approach, = you=92d think clients would switch to POST for future = requests. 

I think this is mainly a = security considerations issue.

Other than the = obvious =93it is restful to do GET=94, why might a client *want* or = *need* to do a GET?  Is it reasonable as Bill suggests that servers = could drop GET in favour of POST search = only?


On Apr 29, 2014, at 12:55 PM, Bill Mills <wmills_92105@yahoo.com> = wrote:

I think if the site = has concerns about this then they only support POST for queries and = return a 405 for all GET to the query endpoint.  Trying to parse = the data sent to determine guarantees you'll fail to protect the data = properly.
On Tuesday, April 29, 2014 10:57 AM, Phil = Hunt <phil.hunt@oracle.com> = wrote:
In the current spec, we have created the POST profile so that searches with confidential data can be made = without exposing confidential data in the URL (via = GET).

I had a question from one of our developers = about how does the client know when to use GET vs. = POST?

a.  For all queries?
b. =  Should an attribute have some metadata flagging it as not usable = on GET?
c.  Should GET return a specific error when a = query is to be repeated as a POST?

The concern = with c. is that once done the data is exposed. In our internal group we = discussed that this would likely happen the first time a client starts = talking to a new endpoint =97 so either the deployer or a developer = would see the error.  IOW, once a client knows an attribute is = =93confidential=94 it wouldn=92t normally keep doing the same = thing.

I=92m not sure there is a good answer = here.  Any other ideas?

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

=

= --Apple-Mail=_BFAA7571-D7CD-401F-8F23-46842C19AC78-- From nobody Tue Apr 29 14:28: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 A22041A0792 for ; Tue, 29 Apr 2014 14:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 VV37UOeQ8ylY for ; Tue, 29 Apr 2014 14:27:35 -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 605F51A02AC for ; Tue, 29 Apr 2014 14:27:35 -0700 (PDT) Received: from [98.139.215.140] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 21:27:34 -0000 Received: from [98.139.212.203] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 21:27:34 -0000 Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 21:27:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 990775.30329.bm@omp1012.mail.bf1.yahoo.com Received: (qmail 53811 invoked by uid 60001); 29 Apr 2014 21:27:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398806853; bh=x0Lj+40hkWLSK9iBX+v8TcfqLUaF4KLHFtPdiVq/vvI=; 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=0PxYNYfqkq+G25gPsaOGzHAc1Fyt2Y6mOUj3vDhLIbkP8eTjCn2gOk9YFOcRVRnq9Rar2/6k7MVSPG98s66vRTlic/s+dSopZS80Tc7XyJKU3Y6DwlrtxMB+q0HvxgxUs8/Zw7lyFvkjqxvuLziHNu24+ZfurDuinjHnmhFqggg= X-YMail-OSG: M_IQlpIVM1k1y8GPLQWbRgJorz1mixMp8ybTLPNvXkGL.qK GVsK7vkOBon9yZ_wois0WIbyx4MjM2vyEY9OcO0VBj8YvGk1Ua.90i2d9Q36 MwMxe8xRyOGv9OKxPTQR5nVJbfdSRbgr1pKM1lCj7YTIhHDXr37jUk0cmaqG LU.BD9sFHJrGbb3032Wsh0QBSTe4e2MC0SLJhr1qBMe74bZwMrqi4Azgr2A1 hJ9O8uTLE2sLW8iwu98qpIF8Z_bB7B3KWmYbxsE4e8JlT2YEp2i7uZXgStJ5 TvMr2jtjTk4slJZgBezzs_ZQtXynpE.mvOWX00tJDiJBYa4PXaBpN5MzND6Q b6tB1nkHFyveMjFYWLfyKJF09NhbVgiwY.vhULwfVFQKuMvjqi9bzo6OSJX1 EZGzLT4GHo3qlxhZCUP4ejdd6bp01gL0XZK.aMn_QzkS.JV9aWDfq1Fvi3Fr 1p1idCzTUVQqnkgJc4VSxmmoLpDteGt3C4DwY0Kv.ZaXDz__CdDK_YYiuyyC fWKLlwqfA.6a.LOc2rwWbC39C7L2RC9pYFhZCVhAp0pS7ZBj3dtnw5PHuBoB gqFWLoi3qUfujKAWPy2LVdMPQ.XD1f.AQvq9H4_gcW1XqzJpFLFa2nZexBEm jx8ee8yQmWHoYFdFT50tlJIPRgMX.Gjng9j3_ETFeyeS_f0pEeNVy Received: from [209.131.62.113] by web142806.mail.bf1.yahoo.com via HTTP; Tue, 29 Apr 2014 14:27:33 PDT X-Rocket-MIMEInfo: 002.001, WWVhaCwgdGhlcmUncyBzdGlsbCB0aGUgcG9zc2liaWxpdHkgb2YgbGVha2luZyB3aXRoIHRoaXMsIGJ1dCBpdCdzIGxlc3MgdGhhbiB3aGVuIHRoZSBjbGllbnQgaGFzIHRvIHByb2JlIGZvciB3aGljaCBkYXRhIGVsZW1lbnRzIG1pZ2h0IGJlIGJhZC4KT24gVHVlc2RheSwgQXByaWwgMjksIDIwMTQgMjoxNSBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4gd3JvdGU6CiAKQmlsbCwKSW50ZXJlc3Rpbmcgc2ltcGxpZmljYXRpb24uIEhvd2V2ZXIsIHRoZSBVUkwgaXMgc3RpbGwgZXhwb3NlZCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.185.657 References: <7B8713D9-F682-42BA-AD38-98B285DE3F74@oracle.com> <1398801313.28138.YahooMailNeo@web142802.mail.bf1.yahoo.com> <07DF1DFA-F17B-4902-93A4-C4BFDFF85FF3@oracle.com> Message-ID: <1398806853.53222.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Tue, 29 Apr 2014 14:27:33 -0700 (PDT) From: Bill Mills To: Phil Hunt In-Reply-To: <07DF1DFA-F17B-4902-93A4-C4BFDFF85FF3@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="515012262-211570754-1398806853=:53222" Archived-At: http://mailarchive.ietf.org/arch/msg/scim/dk5Hcy64LyCJG4jFJrXt7_--nZs Cc: "scim@ietf.org WG" Subject: Re: [scim] How to signal when a query is not eligible for use with HTTP GET (due to PII/security) 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, 29 Apr 2014 21:28:05 -0000 --515012262-211570754-1398806853=:53222 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yeah, there's still the possibility of leaking with this, but it's less tha= n when the client has to probe for which data elements might be bad.=0AOn T= uesday, April 29, 2014 2:15 PM, Phil Hunt wrote:=0A = =0ABill,=0AInteresting simplification. However, the URL is still exposed ev= en when the server returns a 405.=0A=0ABut as with the more complex approac= h, you=E2=80=99d think clients would switch to POST for future requests.=C2= =A0=0A=0AI think this is mainly a security considerations issue.=0A=0AOther= than the obvious =E2=80=9Cit is restful to do GET=E2=80=9D, why might a cl= ient *want* or *need* to do a GET? =C2=A0Is it reasonable as Bill suggests = that servers could drop GET in favour of POST search only?=0A=0A=0APhil=0A= =0A@independentid=0Awww.independentid.comphil.hunt@oracle.com=0A=0A=0A=0AOn= Apr 29, 2014, at 12:55 PM, Bill Mills wrote:=0A= =0AI think if the site has concerns about this then they only support POST = for queries and return a 405 for all GET to the query endpoint. =C2=A0Tryin= g to parse the data sent to determine guarantees you'll fail to protect the= data properly.=0A>On Tuesday, April 29, 2014 10:57 AM, Phil Hunt wrote:=0A> =0A>In the current spec, we have created the POST = profile so that searches with confidential data can be made without exposin= g confidential data in the URL (via GET).=0A>=0A>=0A>I had a question from = one of our developers about how does the client know when to use GET vs. PO= ST?=0A>=0A>=0A>a. =C2=A0For all queries?=0A>b. =C2=A0Should an attribute ha= ve some metadata flagging it as not usable on GET?=0A>c. =C2=A0Should GET r= eturn a specific error when a query is to be repeated as a POST?=0A>=0A>=0A= >The concern with c. is that once done the data is exposed. In our internal= group we discussed that this would likely happen the first time a client s= tarts talking to a new endpoint =E2=80=94 so either the deployer or a devel= oper would see the error. =C2=A0IOW, once a client knows an attribute is = =E2=80=9Cconfidential=E2=80=9D it wouldn=E2=80=99t normally keep doing the = same thing.=0A>=0A>=0A>I=E2=80=99m not sure there is a good answer here. = =C2=A0Any other ideas?=0A>=0A>=0A>Phil=0A>=0A>=0A>@independentid=0A>www.ind= ependentid.comphil.hunt@oracle.com=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___________________= ____________________________=0Ascim mailing list=0Ascim@ietf.org=0Ahttps://= www.ietf.org/mailman/listinfo/scim --515012262-211570754-1398806853=:53222 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yeah, there's still the possibility of leaking wit= h this, but it's less than when the client has to probe for which data elem= ents might be bad.
On Tuesday, April 29, 2014 2:15 PM, Phil Hunt <phil.hunt@o= racle.com> wrote:
Bill,

I= nteresting simplification. However, the URL is still exposed even when the = server returns a 405.

But as with the more complex appr= oach, you=E2=80=99d think clients would switch to POST for future requests.=  

I think this is mainly a sec= urity considerations issue.

Other t= han the obvious =E2=80=9Cit is restful to do GET=E2=80=9D, why might a clie= nt *want* or *need* to do a GET?  Is it reasonable as Bill suggests th= at servers could drop GET in favour of POST search only?
=

=0A<= br clear=3D"none" class=3D"yiv5440632011Apple-interchange-newline">=0A=0A
On Apr 29, 2014, at 12:55 PM, Bill Mills <<= a rel=3D"nofollow" shape=3D"rect" ymailto=3D"mailto:wmills_92105@yahoo.com"= target=3D"_blank" href=3D"mailto:wmills_92105@yahoo.com">wmills_92105@yaho= o.com> wrote:

I thin= k if the site has concerns about this then they only support POST for queri= es and return a 405 for all GET to the query endpoint.  Trying to pars= e the data sent to determine guarantees you'll fail to protect the data pro= perly.
On Tues= day, April 29, 2014 10:57 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
In the current spec, we have created the=0A POST profile so = that searches with confidential data can be made without exposing confident= ial data in the URL (via GET).

I had a qu= estion from one of our developers about how does the client know when to us= e GET vs. POST?

a.  For all qu= eries?
b.  Should an attribute have some metadata flagging i= t as not usable on GET?
c.  Should GET return a specific err= or when a query is to be repeated as a POST?

<= /div>
The concern with c. is that once done the data is exposed. In our= internal group we discussed that this would likely happen the first time a= client starts talking to a new endpoint =E2=80=94 so either the deployer o= r a developer would see the error.  IOW, once a client knows an attrib= ute is =E2=80=9Cconfidential=E2=80=9D it wouldn=E2=80=99t normally keep doi= ng the same thing.

I=E2=80=99m not = sure there is a good answer here.  Any other=0A ideas?

=0A
<= div style=3D"word-wrap:break-word;">
Phil

=
@independentid
phil.= hunt@oracle.com


=0A
=0A

_____________________________________= __________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim


=

=

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


--515012262-211570754-1398806853=:53222-- From nobody Wed Apr 30 12:21: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 469BD1A886D for ; Wed, 30 Apr 2014 12:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 ZbL3RJGTSzwJ for ; Wed, 30 Apr 2014 12:21:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 872741A8879 for ; Wed, 30 Apr 2014 12:21:52 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s3UJLo6k020807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Apr 2014 19:21:50 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 s3UJLnF9007260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 Apr 2014 19:21:50 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 s3UJLngZ007246 for ; Wed, 30 Apr 2014 19:21:49 GMT Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 Apr 2014 12:21:49 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_42A242E4-9B46-4936-86B4-C3A584743FA8" Message-Id: Date: Wed, 30 Apr 2014 12:21:48 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/pyXe0GwUkRUSjZa913H23yY4iWw Subject: [scim] Ticket 65 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, 30 Apr 2014 19:21:54 -0000 --Apple-Mail=_42A242E4-9B46-4936-86B4-C3A584743FA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Kelly, You reported on the ticket that blackberry clients seem to need this = feature. Do we feel strongly enough that we need to support this? Or are we = better not to support it in hopes that Blackberry upgrades their = browser. :-) If we do support it, someone needs to take on the deliverable to do an = IANA registry draft for X-HTTP-Method-Override for which Julian informs = us is not officially registered (despite being a defacto standard). Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_42A242E4-9B46-4936-86B4-C3A584743FA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Kelly,

You reported on the ticket = that blackberry clients seem to need this = feature.

Do we feel strongly enough that we = need to support this?  Or are we better not to support it in hopes = that Blackberry upgrades their browser. =  :-)

If we do support it, someone needs to = take on the deliverable to do an IANA registry draft for = X-HTTP-Method-Override for which Julian informs us is not officially = registered (despite being a defacto = standard).

= --Apple-Mail=_42A242E4-9B46-4936-86B4-C3A584743FA8-- From nobody Wed Apr 30 15:01:19 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 812201A0953 for ; Wed, 30 Apr 2014 15:01:05 -0700 (PDT) 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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 C6-GExVJ-Ehj for ; Wed, 30 Apr 2014 15:01:00 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) by ietfa.amsl.com (Postfix) with ESMTP id DFB541A094C for ; Wed, 30 Apr 2014 15:00:59 -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.929.12; Wed, 30 Apr 2014 22:00:56 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.174]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.174]) with mapi id 15.00.0929.001; Wed, 30 Apr 2014 22:00:56 +0000 From: Kelly Grizzle To: Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Ticket 65 HTTP Method Override Thread-Index: AQHPZKl0T8YeZCVnq0i9mHXAtzj1XZsqtT8A Date: Wed, 30 Apr 2014 22:00:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 009464FC00703800946649 x-originating-ip: [97.79.140.10] x-forefront-prvs: 0197AFBD92 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(189002)(199002)(377454003)(50986999)(74316001)(66066001)(46102001)(33646001)(80022001)(15975445006)(4396001)(81342001)(76176999)(20776003)(99396002)(19609705001)(54356999)(77982001)(76482001)(99286001)(19300405004)(74662001)(76576001)(80976001)(15202345003)(81542001)(16236675002)(83072002)(85852003)(92566001)(19580405001)(19580395003)(2656002)(87936001)(74502001)(16601075003)(31966008)(101416001)(83322001)(79102001)(86362001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR04MB390; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:BCCDC195.8F3275C0.4161BF70.44E5B9D9.20233; 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_f9ac8aa9ad354867861e1bc35b5cad43BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/sLTc_2E_OiVCFUqDZ1nLueyaW_o Subject: Re: [scim] Ticket 65 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, 30 Apr 2014 22:01:05 -0000 --_000_f9ac8aa9ad354867861e1bc35b5cad43BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm fine whether it is in the spec or not. It is a common enough practice = that service providers that wish to support it can do so. The main issue w= ould be client-side. If the client can't send a PATCH and the server doesn= 't support the X-HTTP-Method-Override header, then there will be problems. = Blackberry is the only instance of a limited modern client that I have run= into out in the wild, so I don't have a strong opinion either way. --Kelly From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, April 30, 2014 2:22 PM To: scim@ietf.org WG Subject: [scim] Ticket 65 HTTP Method Override Kelly, You reported on the ticket that blackberry clients seem to need this featur= e. Do we feel strongly enough that we need to support this? Or are we better = not to support it in hopes that Blackberry upgrades their browser. :-) If we do support it, someone needs to take on the deliverable to do an IANA= registry draft for X-HTTP-Method-Override for which Julian informs us is n= ot officially registered (despite being a defacto standard). Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_f9ac8aa9ad354867861e1bc35b5cad43BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m fine whether it= is in the spec or not.  It is a common enough practice that service p= roviders that wish to support it can do so.  The main issue would be client-side.  If the client can’t send a PATCH and the server d= oesn’t support the X-HTTP-Method-Override header, then there will be = problems.  Blackberry is the only instance of a limited modern client = that I have run into out in the wild, so I don’t have a strong opinion either way.

 <= /p>

--Kelly

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, April 30, 2014 2:22 PM
To: scim@ietf.org WG
Subject: [scim] Ticket 65 HTTP Method Override

 

Kelly,

 

You reported on the ticket that blackberry clients s= eem to need this feature.

 

Do we feel strongly enough that we need to support t= his?  Or are we better not to support it in hopes that Blackberry upgr= ades their browser.  :-)

 

If we do support it, someone needs to take on the de= liverable to do an IANA registry draft for X-HTTP-Method-Override for which= Julian informs us is not officially registered (despite being a defacto st= andard).

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

--_000_f9ac8aa9ad354867861e1bc35b5cad43BN1PR04MB392namprd04pro_-- From nobody Wed Apr 30 16:29:21 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 B95301A6F28 for ; Wed, 30 Apr 2014 16:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 NQ_dGRCLjDVD for ; Wed, 30 Apr 2014 16:29:07 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 76B4E1A09CD for ; Wed, 30 Apr 2014 16:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1169; q=dns/txt; s=iport; t=1398900546; x=1400110146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PhefjQ4osWlJNKs6cZUWhEKEeJ0+RHvVyKp8kuGmM+0=; b=RBeCrQTrPT715Q+LvC+Vk8MAs3seastMhpNgYExlVy/b4WjiPqF+7qA6 TWBhd4rz7VG4y+pL0HgjAPHo/hDuZuasGLVvUDH4/8DrAyj3o+lA94fFN S3SPRn+5FjS1auCBYF+BMqb20boupHQXKfGLqUgoH1KfH93Jq/5WPKRqK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFACCGYVOtJA2I/2dsb2JhbABZgwZPV8RMgSAWdIImAQEEOjQLEAIBCDYQMiUCBA4FiEENyX4XjgxFB4Q5BJkngTyLWIVXgzGCKw X-IronPort-AV: E=Sophos;i="4.97,961,1389744000"; d="scan'208";a="40129291" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP; 30 Apr 2014 23:29:05 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3UNT5iO006081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 23:29:05 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.226]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 18:29:05 -0500 From: "Morteza Ansari (moransar)" To: "kelly.grizzle@sailpoint.com" Thread-Topic: [scim] #21 (api): Add an "application" or "system" resource (schema) Thread-Index: AQHPZKTlg3cZI+IXyUmSie69Hj8KhJsqrSQA Date: Wed, 30 Apr 2014 23:29:04 +0000 Message-ID: References: <068.1a7857d58f377ce93cc78c9cb9ebddb7@tools.ietf.org> <083.52455c68ca447a00d938bceccdf255cc@tools.ietf.org> In-Reply-To: <083.52455c68ca447a00d938bceccdf255cc@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.144.101] Content-Type: text/plain; charset="us-ascii" Content-ID: <9A44FF94C668104F9D76F5B1E40E0325@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/CNV-QXFViSKiUphkyzScvQ6-jDU Cc: "scim@ietf.org" Subject: Re: [scim] #21 (api): Add an "application" or "system" resource (schema) 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, 30 Apr 2014 23:29:15 -0000 If anyone has concerns with closing this as WONTFIX, please bring it up to the mailing list or update the ticket in the issue tracker. Cheers, Morteza On 4/30/14, 11:49 AM, "scim issue tracker" wrote: >#21: Add an "application" or "system" resource (schema) > > >Comment (by kelly.grizzle@sailpoint.com): > > This seems like it would be better handled as an extension rather than in > the core schema. I suggest we close as WONTFIX. > >--=20 >-------------------------------------+------------------------------------ >- > Reporter: | Owner: draft-ietf-scim- > bjorn.aannestad@unboundid.com | api@tools.ietf.org > Type: enhancement | Status: new > Priority: major | Milestone: >Component: api | Version: > Severity: - | Resolution: > Keywords: | >-------------------------------------+------------------------------------ >- > >Ticket URL: >scim > From nobody Wed Apr 30 16:29: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 1F08F1A6F3E for ; Wed, 30 Apr 2014 16:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 SyKACE9ghgSP for ; Wed, 30 Apr 2014 16:29:40 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EAF1F1A6F2B for ; Wed, 30 Apr 2014 16:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1093; q=dns/txt; s=iport; t=1398900578; x=1400110178; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZZSYUUeZS9dkr7ArorlcoCe/DeJ4X5pFXXsV6eM2nkA=; b=XznMlDGjd08ttl4fZ/vMu3FrW3F48dqUVzPSXyzEv5QkyCKoKLhtbrp4 cM7LtBq9gZiiZfY4NtlOgPcBOHkYx2K/U/CVLMWE8l2Be5iTxrOtLzBfK ThRRdiaOmNTWAuq9rLZrEPBL6zaIWRkNiLbIRpmuEYzBl2J9+h+pG8rr5 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAJeGYVOtJA2G/2dsb2JhbABZgwZPV8RMgSAWdIImAQEEOjQLEAIBCDYQMiUCBAENBYhBDcl6F44MRQeEOQEDmSeBPItYhVeDMYIr X-IronPort-AV: E=Sophos;i="4.97,961,1389744000"; d="scan'208";a="321614453" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP; 30 Apr 2014 23:29:38 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s3UNTc7N001033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 23:29:38 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.226]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 18:29:37 -0500 From: "Morteza Ansari (moransar)" To: "kelly.grizzle@sailpoint.com" , "bjorn.aannestad@unboundid.com" , "phil.hunt@oracle.com" Thread-Topic: [scim] #22 (api): Add metadata to attributes (schema) Thread-Index: AQHPZKUg8Q90wFABIUWauTCyV1RKvZsqrUqA Date: Wed, 30 Apr 2014 23:29:36 +0000 Message-ID: References: <068.3d75d98582409d10c298eae3d37f1cca@tools.ietf.org> <083.b2f80f2311eaa21a4dd39b14d49fd31b@tools.ietf.org> In-Reply-To: <083.b2f80f2311eaa21a4dd39b14d49fd31b@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.144.101] Content-Type: text/plain; charset="us-ascii" Content-ID: <405C288F3A257A4E8DF1427E271A8564@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ODblxopgsLoD4zfe44uFFxsxIVM Cc: "scim@ietf.org" Subject: Re: [scim] #22 (api): Add metadata to attributes (schema) 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, 30 Apr 2014 23:29:41 -0000 If anyone has concerns with closing this as WONTFIX, please bring it up to the mailing list or update the ticket in the issue tracker. Cheers, Morteza On 4/30/14, 11:50 AM, "scim issue tracker" wrote: >#22: Add metadata to attributes (schema) > > >Comment (by kelly.grizzle@sailpoint.com): > > +1 for handling as an extension and closing this as WONTFIX. > >--=20 >-------------------------------------+------------------------------------ >- > Reporter: | Owner: draft-ietf-scim- > bjorn.aannestad@unboundid.com | api@tools.ietf.org > Type: enhancement | Status: new > Priority: major | Milestone: >Component: api | Version: > Severity: - | Resolution: > Keywords: | >-------------------------------------+------------------------------------ >- > >Ticket URL: >scim >