From leifj@mnt.se Wed Jan 2 01:51:00 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A582E21F8E49 for ; Wed, 2 Jan 2013 01:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkk4ZxUx4kUo for ; Wed, 2 Jan 2013 01:50:56 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id C967021F8E47 for ; Wed, 2 Jan 2013 01:50:54 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id fj20so5795364lab.38 for ; Wed, 02 Jan 2013 01:50:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=Omyaz8OXd6y1mq9KPieX+9Qqb3gbZWtWWDZLO6FOa50=; b=gqeAPWtvefFkYmoGtAB2LJVmvHpautEyM1r/HpZ/j4t8RDOvB34NUrmobM4GQa9l+Y 0lIvNvqJXyGoXV0Oeh9PXfFv5t9uub2WLgkI3I9AKFdEHeHKMhz9Sw/P6TBKejDW/2ji L0a2GShnwo8xfuoNxSyPXRUpyP9+m8U9WKQLjyX1o34CG8maXWenn7Lh+KqeYXOx/dTr jAqrM5K3Y0Zj/S5y3NNDdIZXzxUxh+HBCV+EkMzebYRSHN6pTWdBss0+Y2k1AUeekU86 nFJcaFmxXbMU1P84QzCHUrujAqxjxsv6XCSwACvnfinL1PVzjH40hUCoXXouoWZz7FQT QEEA== X-Received: by 10.112.17.108 with SMTP id n12mr17382448lbd.21.1357120253391; Wed, 02 Jan 2013 01:50:53 -0800 (PST) Received: from ?IPv6:2001:6b0:7:0:e866:6c05:2c66:5bdc? ([2001:6b0:7:0:e866:6c05:2c66:5bdc]) by mx.google.com with ESMTPS id ml1sm17203243lab.15.2013.01.02.01.50.51 (version=SSLv3 cipher=OTHER); Wed, 02 Jan 2013 01:50:51 -0800 (PST) Message-ID: <50E402FA.80603@mnt.se> Date: Wed, 02 Jan 2013 10:50:50 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: scim@ietf.org References: <50AA9168.2040706@unboundid.com> <50B0E794.5060808@mnt.se> <50B5A4D4.5030507@stpeter.im> <50C98973.9090107@cisco.com> In-Reply-To: <50C98973.9090107@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlIpGinnqF80ihBcZ/7ci2WVj3+R28eUjtnNBoSfBY64G5tDbChxU6aQfdI41zyANDQzppl Cc: Kelly Grizzle Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 09:51:00 -0000 On 12/13/2012 08:53 AM, Eliot Lear wrote: > On 11/28/12 6:44 AM, Peter Saint-Andre wrote: >> However, I reiterate that it's really important for this WG to "get it >> right" with regard to the extensibility model, and secondarily with >> regard to registration of extensions. > +1 on this point, AND there should be some test of that model under the > old "0, 1, many" adage. > > Eliot Sorry for taking so long on this - we clearly have as much consensus as we are likely to get. Lets close this issue and move on. From leifj@mnt.se Wed Jan 2 06:26:26 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5922121F850B for ; Wed, 2 Jan 2013 06:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsTZFS5C-KL5 for ; Wed, 2 Jan 2013 06:26:25 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB6821F84EB for ; Wed, 2 Jan 2013 06:26:25 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id fn20so6172691lab.12 for ; Wed, 02 Jan 2013 06:26:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=jVHvFHJPAgKsM4IQzq8Bb2kMMvJebZd2SWB9cbLrUXQ=; b=FfWyobwSLmAt3z5/SYNeXQw2gAZRSkziuQSEglUJVyZfjvf1yz+Jr6tSSIGqAbJK3h 5vP+mG0EQh/KTv3a/Fl0SEWlEHBzJYyPpLihIdlNKGvuncGApjPFEvUw9oCoS0sjayt7 LOioQO+W042WUwIh2jBUpgjW5t3pa0p6+XPvs1PBXY9049Hjk1K5iJhgZLdaSwR1rRSL ndsfm9Znj9mRAxFlUxhxrAqldM8wY61I7BmD56bJ7RFpI2ZyHDH4f7kB4/IyDKTUpdMO 2e+ZGL2DiQeUL88vRsKi9uHUUTp4VHjhTBt34PBLUuHiLESnKOQKWfIh9fdqumd9d8g+ 7LpA== X-Received: by 10.152.46.161 with SMTP id w1mr43922672lam.27.1357136783971; Wed, 02 Jan 2013 06:26:23 -0800 (PST) Received: from ?IPv6:2001:6b0:7:0:e866:6c05:2c66:5bdc? ([2001:6b0:7:0:e866:6c05:2c66:5bdc]) by mx.google.com with ESMTPS id n7sm16118596lbz.5.2013.01.02.06.26.21 (version=SSLv3 cipher=OTHER); Wed, 02 Jan 2013 06:26:23 -0800 (PST) Message-ID: <50E4438D.8040404@mnt.se> Date: Wed, 02 Jan 2013 15:26:21 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: scim WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmpZ9N5Yab9VeD2nE6f32kLDOz42phMYpcE93wGNUKBPLoXCRSyJRGf6oIn5WCsVUdCwqgW Subject: [scim] Orlando X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 14:26:26 -0000 Folks, Orlando and IETF-86 is slowly approaching. I've requested a 2hr slot for SCIM. Please help me and Morteza fill it by having lots of progress and topics for discussion ready. Suggestions for items for the agenda are welcome. Cheers Leif From phil.hunt@oracle.com Wed Jan 2 13:09:52 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B118121F895F for ; Wed, 2 Jan 2013 13:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.621 X-Spam-Level: X-Spam-Status: No, score=-5.621 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soPBDri9VJU0 for ; Wed, 2 Jan 2013 13:09:52 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id C821F21F8888 for ; Wed, 2 Jan 2013 13:09:51 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r02L9oYq010872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Jan 2013 21:09:51 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r02L9n9c027717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jan 2013 21:09:50 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r02L9nup029098 for ; Wed, 2 Jan 2013 15:09:49 -0600 Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Jan 2013 13:09:48 -0800 References: <97ED83B9-C2D1-4D84-8B9D-9606F0AD7C3A@oracle.com> From: Phil Hunt Content-Type: multipart/alternative; boundary=Apple-Mail-C9361C47-960D-48D8-9E15-CF40ED68272E X-Mailer: iPhone Mail (10A523) In-Reply-To: <97ED83B9-C2D1-4D84-8B9D-9606F0AD7C3A@oracle.com> Message-Id: <764D69BE-E561-4E56-BDF7-DE0E3E9F4481@oracle.com> Date: Wed, 2 Jan 2013 13:09:47 -0800 To: "scim@ietf.org WG" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: Re: [scim] Two draft search proposals: X-Search and Token-Search X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 21:09:52 -0000 --Apple-Mail-C9361C47-960D-48D8-9E15-CF40ED68272E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Just a reminder, any comments appreciated.=20 Phil Sent from my phone. On 2012-12-23, at 15:02, Phil Hunt wrote: > The design team has developed to strawman proposals (draft-hunt-scim-token= search & draft-hunt-scim-xsearch) to solve 3 outstanding ticket items. Both= solutions are equivalent and are expressed as if they were independent spec= ifications. The 3 items covered are: >=20 > 1 Ticket 25 - Ability to search for objects of multiple resource types > 2.Ticket 29 - Ability to search without leaking confidential filter terms i= n the URL (POST search). > 3.Ticket 31 - Ability to page through results without the result set chang= ing between page requests. >=20 > The major difference between these specifications are that one creates a R= ESTful resource representation of the search operation and the other uses to= ken parameters to represent a search result. Depending on your point of vie= w, one may seem simpler than the other. To give you a quick summary of the d= ifferences, a PDF is attached comparing the APIs. > > For now, let's not get into the details right away. Let's keep this simple= . Which draft is closer to what you would like to see? X-/Search or Token-= Search >=20 > With the agreement of the chairs, we can then seek to refine one of the ca= ndidate proposals and then discuss what parts to include (if at all) in the m= ain specification and what parts ot keep separate. >=20 > Links to the draft are: > http://datatracker.ietf.org/doc/draft-hunt-scim-xsearch > http://datatracker.ietf.org/doc/draft-hunt-scim-tokensearch >=20 > Thanks to everyone for your contributions and comments on this. >=20 > Happy holidays! >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-C9361C47-960D-48D8-9E15-CF40ED68272E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Just a reminder, any comments apprecia= ted. 

Phil

Sent from my phone.

On 2012-12-23, at 15:02, Phil Hunt <phil.hunt@oracle.com> wrote:

The design team has developed to strawman proposals (draft-hunt-= scim-tokensearch & draft-hunt-scim-xsearch) to solve 3 outstanding ticke= t items.  Both solutions are equivalent and are expressed as if they we= re independent specifications. The 3 items covered are:

1= Ticket 25 - Ability to search for objects of multiple resource types
<= div>2.Ticket 29 - Ability to search without leaking confidential filter term= s in the URL (POST search).
3.Ticket 31 - Ability to page through r= esults without the result set changing between page requests.

The major difference between these specifications are that one crea= tes a RESTful resource representation of the search operation and the other u= ses token parameters to represent a search result.  Depending on your p= oint of view, one may seem simpler than the other. To give you a quick summa= ry of the differences, a PDF is attached comparing the APIs.
=
<compari= son-token-rest.pdf>
= For now, let's not get into the details right away. Let's keep this simple. W= hich draft is closer to what you would like to see?   X-/Search or Toke= n-Search

With the agreement of the chai= rs, we can then seek to refine one of the candidate proposals and then discu= ss what parts to include (if at all) in the main specification and what part= s ot keep separate.

Links to the draft are:
http://datatracker.ietf.org/doc/draft-hunt-scim-xsearch
http://datatracker.ietf.org/doc/draft-hunt-scim-tokensearch

T= hanks to everyone for your contributions and comments on this.
Happy holidays!

Phil



_______________________________________________
scim= mailing list
scim@ietf.org=
= https://www.ietf.org/mailman/listinfo/scim
= = --Apple-Mail-C9361C47-960D-48D8-9E15-CF40ED68272E-- From kelly.grizzle@sailpoint.com Wed Jan 2 13:17:45 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF87821F8878 for ; Wed, 2 Jan 2013 13:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wH6HZj4lX6zi for ; Wed, 2 Jan 2013 13:17:45 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id D423E21F8877 for ; Wed, 2 Jan 2013 13:17:44 -0800 (PST) Received: from mail15-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE003.bigfish.com (10.236.130.66) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 Jan 2013 21:17:44 +0000 Received: from mail15-co9 (localhost [127.0.0.1]) by mail15-co9-R.bigfish.com (Postfix) with ESMTP id 2C5B82A0213; Wed, 2 Jan 2013 21:17:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.133; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0412HT004.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371Ic85fh1432I1528Izz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh1033IL18c673h1954cbh17326ah18602ehz31h2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received-SPF: softfail (mail15-co9: transitioning domain of sailpoint.com does not designate 132.245.1.133 as permitted sender) client-ip=132.245.1.133; envelope-from=kelly.grizzle@sailpoint.com; helo=BLUPRD0412HT004.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail15-co9 (localhost.localdomain [127.0.0.1]) by mail15-co9 (MessageSwitch) id 1357161418824171_9895; Wed, 2 Jan 2013 21:16:58 +0000 (UTC) Received: from CO9EHSMHS025.bigfish.com (unknown [10.236.132.244]) by mail15-co9.bigfish.com (Postfix) with ESMTP id 0491A2013A; Wed, 2 Jan 2013 21:16:51 +0000 (UTC) Received: from BLUPRD0412HT004.namprd04.prod.outlook.com (132.245.1.133) by CO9EHSMHS025.bigfish.com (10.236.130.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 2 Jan 2013 21:16:50 +0000 Received: from BLUPRD0412MB643.namprd04.prod.outlook.com ([169.254.4.120]) by BLUPRD0412HT004.namprd04.prod.outlook.com ([10.255.214.165]) with mapi id 14.16.0245.002; Wed, 2 Jan 2013 21:18:09 +0000 From: Kelly Grizzle To: Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Two draft search proposals: X-Search and Token-Search Thread-Index: AQHN4WFuboDkNmuID0C7E5hmFNODYJg2mb7A Date: Wed, 2 Jan 2013 21:16:45 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437472D961E@BLUPRD0412MB643.namprd04.prod.outlook.com> References: <97ED83B9-C2D1-4D84-8B9D-9606F0AD7C3A@oracle.com> In-Reply-To: <97ED83B9-C2D1-4D84-8B9D-9606F0AD7C3A@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 76C6F92D0039D476C6FA7A x-originating-ip: [173.226.147.242] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C3437472D961EBLUPRD0412MB643_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Two draft search proposals: X-Search and Token-Search X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 21:17:46 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C3437472D961EBLUPRD0412MB643_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > For now, let's not get into the details right away. Let's keep this simpl= e. Which draft is closer to what you would like to see? +1 for token search. From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Sunday, December 23, 2012 5:03 PM To: scim@ietf.org WG Subject: [scim] Two draft search proposals: X-Search and Token-Search The design team has developed to strawman proposals (draft-hunt-scim-tokens= earch & draft-hunt-scim-xsearch) to solve 3 outstanding ticket items. Both= solutions are equivalent and are expressed as if they were independent spe= cifications. The 3 items covered are: 1 Ticket 25 - Ability to search for objects of multiple resource types 2.Ticket 29 - Ability to search without leaking confidential filter terms i= n the URL (POST search). 3.Ticket 31 - Ability to page through results without the result set changi= ng between page requests. The major difference between these specifications are that one creates a RE= STful resource representation of the search operation and the other uses to= ken parameters to represent a search result. Depending on your point of vi= ew, one may seem simpler than the other. To give you a quick summary of the= differences, a PDF is attached comparing the APIs. For now, let's not get into the details right away. Let's keep this simple.= Which draft is closer to what you would like to see? X-/Search or Token-= Search With the agreement of the chairs, we can then seek to refine one of the can= didate proposals and then discuss what parts to include (if at all) in the = main specification and what parts ot keep separate. Links to the draft are: http://datatracker.ietf.org/doc/draft-hunt-scim-xsearch http://datatracker.ietf.org/doc/draft-hunt-scim-tokensearch Thanks to everyone for your contributions and comments on this. Happy holidays! Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_56C3C758F9D6534CA3778EAA1E0C3437472D961EBLUPRD0412MB643_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> For now, let's not get into the details ri= ght away. Let's keep this simple. Which draft is closer to what you would l= ike to see?

 <= /p>

+1 for token search.<= o:p>

 <= /p>

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Sunday, December 23, 2012 5:03 PM
To: scim@ietf.org WG
Subject: [scim] Two draft search proposals: X-Search and Token-Searc= h

 

The design team has developed to strawman proposals = (draft-hunt-scim-tokensearch & draft-hunt-scim-xsearch) to solve 3 outs= tanding ticket items.  Both solutions are equivalent and are expressed= as if they were independent specifications. The 3 items covered are:

 

1 Ticket 25 - Ability to search for objects of multi= ple resource types

2.Ticket 29 - Ability to search without leaking conf= idential filter terms in the URL (POST search).

3.Ticket 31 - Ability to page through results withou= t the result set changing between page requests.

 

The major difference between these specifications ar= e that one creates a RESTful resource representation of the search operatio= n and the other uses token parameters to represent a search result.  D= epending on your point of view, one may seem simpler than the other. To give you a quick summary of the difference= s, a PDF is attached comparing the APIs.

For now, let's not get int= o the details right away. Let's keep this simple. Which draft is closer to = what you would like to see?   X-/Search or Token-Search

 

With the agreement of the = chairs, we can then seek to refine one of the candidate proposals and then = discuss what parts to include (if at all) in the main specification and what parts ot keep separate.

 

Links to the draft are:

http://datatracker.ietf.org/doc/draft-hunt-scim-xsearch

http://datatracker.ietf.org/doc/draft-hunt-scim-tokensearch<= /span> =

 

Thanks to everyone for you= r contributions and comments on this.

 

Happy holidays!=

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com=

 

 

 

--_000_56C3C758F9D6534CA3778EAA1E0C3437472D961EBLUPRD0412MB643_-- From moransar@cisco.com Wed Jan 9 11:32:02 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6201C21F84FD for ; Wed, 9 Jan 2013 11:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXjxG6m8InEw for ; Wed, 9 Jan 2013 11:32:01 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C666721F84E9 for ; Wed, 9 Jan 2013 11:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14177; q=dns/txt; s=iport; t=1357759920; x=1358969520; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=gvTubujpDby6PfZuMnd3tb7ReWPTehVvF9ptmEk/X7A=; b=iKI/T+c7n1EjrVXmhWTzaUFe1DGHx4zML7P8j3i9tjN12Wx/Fy8jasS1 TSjO88Iv03ed3fiiswwC+EgZt7Ds/sgiI3FdIikYo0Pyq49a5tG0edS9D +zb2lIbq/4Y8dH3TRvtUj+QOVL/dUc1WXHNFjPZAZPzLuHus+QdH8zut7 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAB/F7VCtJV2c/2dsb2JhbABEgkioaIkMAYkdFnOCHgEBAQMBLRw1DQEIEQMBAQELHTkUCQgCBAESCBOHeAYMtjKMVyWDPWEDlyiPLYJ0giQ X-IronPort-AV: E=Sophos;i="4.84,439,1355097600"; d="scan'208,217";a="160630990" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 09 Jan 2013 19:32:00 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r09JW0mH018396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jan 2013 19:32:00 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.232]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 13:31:59 -0600 From: "Morteza Ansari (moransar)" To: Kelly Grizzle , Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Two draft search proposals: X-Search and Token-Search Thread-Index: AQHN4WFrY4dCFR7c2UiCAfSAJcs4FZg2/sGAgApc7oA= Date: Wed, 9 Jan 2013 19:31:58 +0000 Message-ID: In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437472D961E@BLUPRD0412MB643.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.2.5.121010 x-originating-ip: [10.21.72.13] Content-Type: multipart/alternative; boundary="_000_CA3B67220D628A4780D6FEB31F18A3E3285FD5E0xmbrcdx08ciscoc_" MIME-Version: 1.0 Subject: Re: [scim] Two draft search proposals: X-Search and Token-Search X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 19:32:02 -0000 --_000_CA3B67220D628A4780D6FEB31F18A3E3285FD5E0xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Any other comments, thoughts on this? We do need to decide what search ext= ensions (if any) we make in the core spec for search as there are a number = of tickets pending on that. The key question is what part(s) of these extensions should be included in = the core spec (if any). Please review and provide feedback. Cheers, Morteza From: Kelly Grizzle > Date: Wednesday, January 2, 2013 1:16 PM To: Phil Hunt >, "scim@ie= tf.org" > Subject: Re: [scim] Two draft search proposals: X-Search and Token-Search > For now, let's not get into the details right away. Let's keep this simpl= e. Which draft is closer to what you would like to see? +1 for token search. From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Phil Hunt Sent: Sunday, December 23, 2012 5:03 PM To: scim@ietf.org WG Subject: [scim] Two draft search proposals: X-Search and Token-Search The design team has developed to strawman proposals (draft-hunt-scim-tokens= earch & draft-hunt-scim-xsearch) to solve 3 outstanding ticket items. Both= solutions are equivalent and are expressed as if they were independent spe= cifications. The 3 items covered are: 1 Ticket 25 - Ability to search for objects of multiple resource types 2.Ticket 29 - Ability to search without leaking confidential filter terms i= n the URL (POST search). 3.Ticket 31 - Ability to page through results without the result set changi= ng between page requests. The major difference between these specifications are that one creates a RE= STful resource representation of the search operation and the other uses to= ken parameters to represent a search result. Depending on your point of vi= ew, one may seem simpler than the other. To give you a quick summary of the= differences, a PDF is attached comparing the APIs. For now, let's not get into the details right away. Let's keep this simple.= Which draft is closer to what you would like to see? X-/Search or Token-= Search With the agreement of the chairs, we can then seek to refine one of the can= didate proposals and then discuss what parts to include (if at all) in the = main specification and what parts ot keep separate. Links to the draft are: http://datatracker.ietf.org/doc/draft-hunt-scim-xsearch http://datatracker.ietf.org/doc/draft-hunt-scim-tokensearch Thanks to everyone for your contributions and comments on this. Happy holidays! Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_CA3B67220D628A4780D6FEB31F18A3E3285FD5E0xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <2BEAC92047CAD0449B58384D26926BD2@cisco.com> Content-Transfer-Encoding: quoted-printable
Any other comments, thoughts on this?  We do need to decide what = search extensions (if any) we make in the core spec for search as there are= a number of tickets pending on that.

The key question is what part(s) of these extensions should be include= d in the core spec (if any). Please review and provide feedback.


Cheers,
Morteza

From: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Date: Wednesday, January 2, 2013 1:= 16 PM
To: Phil Hunt <phil.hunt@oracle.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] Two draft searc= h proposals: X-Search and Token-Search

> For now, let's not get into the details right away. Let's ke= ep this simple. Which draft is closer to what you would like to see?=

 

+1 for token search.

 

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Sunday, December 23, 2012 5:03 PM
To: scim@ietf.org WG
Subject: [scim] Two draft search proposals: X-Search and Token-Searc= h

 

The design team has developed to strawman proposals = (draft-hunt-scim-tokensearch & draft-hunt-scim-xsearch) to solve 3 outs= tanding ticket items.  Both solutions are equivalent and are expressed= as if they were independent specifications. The 3 items covered are:

 

1 Ticket 25 - Ability to search for objects of multi= ple resource types

2.Ticket 29 - Ability to search without leaking conf= idential filter terms in the URL (POST search).

3.Ticket 31 - Ability to page through results withou= t the result set changing between page requests.

 

The major difference between these specifications ar= e that one creates a RESTful resource representation of the search operatio= n and the other uses token parameters to represent a search result.  D= epending on your point of view, one may seem simpler than the other. To give you a quick summary of the difference= s, a PDF is attached comparing the APIs.

For now, let's not get into the details righ= t away. Let's keep this simple. Which draft is closer to what you would lik= e to see?   X-/Search or Token-Search

 

With the agreement of the chairs, we can the= n seek to refine one of the candidate proposals and then discuss what parts= to include (if at all) in the main specification and what parts ot keep separate.

 

Links to the draft are:

http://datatracker.ietf.org/doc/draft-hunt-scim-xsearch

http://datatracker.ietf.org/doc/draft-hunt-scim-tokensearch<= /span>

 

Thanks to everyone for your contributions an= d comments on this.

 

Happy holidays!

 

Phil

 

 

 

 --_000_CA3B67220D628A4780D6FEB31F18A3E3285FD5E0xmbrcdx08ciscoc_-- From likepeng@huawei.com Tue Jan 15 00:45:35 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C6721F87D5 for ; Tue, 15 Jan 2013 00:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCMVxUc-UcWI for ; Tue, 15 Jan 2013 00:45:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D149F21F87C8 for ; Tue, 15 Jan 2013 00:45:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANO05135; Tue, 15 Jan 2013 08:45:32 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Jan 2013 08:45:22 +0000 Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Jan 2013 08:45:29 +0000 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.166]) by SZXEML454-HUB.china.huawei.com ([10.82.67.197]) with mapi id 14.01.0323.003; Tue, 15 Jan 2013 16:45:22 +0800 From: Likepeng To: scim WG Thread-Topic: New Version Notification for draft-li-scim-user-scenarios-00.txt Thread-Index: AQHN8vsk4SPeNNhq20GWkTGcD6f6OphKEIaQ Date: Tue, 15 Jan 2013 08:45:22 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F21EDAEC33@szxeml525-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [scim] Fw: New Version Notification for draft-li-scim-user-scenarios-00.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 08:45:35 -0000 SSB1cGxvYWRlZCBvbmUgZHJhZnQgdG8gZGVzY3JpYmUgdGhlIHVzZXIgc2NlbmFyaW9zLg0KDQpB cyBkaXNjdXNzZWQgaW4gQXRsYW50YSBGMkYgbWVldGluZywgSSB0aGluayBpdCB3b3VsZCBiZSB1 c2VmdWwgdG8gYWRkIHVzZXIgc2NlbmFyaW8gaW4gdGhlIHVzZSBjYXNlIGRvY3VtZW50LCB0byBo ZWxwIHBlb3BsZSB0byB1bmRlcnN0YW5kIHRoZSB1c2VyIHNjZW5hcmlvcy4NCg0KSWYgeW91IGNo ZWNrIHRoZSBkcmFmdCwgeW91IGNhbiBmaW5kIG91dCB0aGF0IHRoZSB0ZXh0cyBhcmUgcXVpdGUg c2ltaWxhciB0byB0aGlzIG9uZToNCmh0dHA6Ly93d3cuc2ltcGxlY2xvdWQuaW5mby9zcGVjcy9k cmFmdC1zY2ltLXNjZW5hcmlvcy0wNC5odG1sDQoNClRoZSBkcmFmdCBhYm92ZSBpcyBub3QgdXBs b2FkZWQgdG8gSUVURiwgYmVjYXVzZSB0aGUgb3JpZ2luYWwgYXV0aG9ycyBlaXRoZXIgbGVmdCB0 aGUgY29tcGFueSBvciBoYXZlIG90aGVyIHRhc2tzLg0KDQpJIHRoaW5rIGl0IHdvdWxkIGJlIGdv b2QgdG8gY29udGludWUgdGhlIHdvcmsgaW4gSUVURiwgYW5kIHRoYXQgaXMgd2h5IEkgcGljayB1 cCB0aGUgd29yay4NCg0KUGxlYXNlIHJldmlldyBpdCBhbmQgcHJvdmlkZSB5b3VyIGZlZWRiYWNr Lg0KDQpUaGFua3MsDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQotLS0tLemCruS7tuWOn+S7ti0t LS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTPlubQx5pyIMTXml6UgMTY6MzQN CuaUtuS7tuS6ujogTGlrZXBlbmcNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1saS1zY2ltLXVzZXItc2NlbmFyaW9zLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1saS1zY2ltLXVzZXItc2NlbmFyaW9zLTAwLnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZXBlbmcgTEkgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYg cmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1saS1zY2ltLXVzZXItc2NlbmFyaW9zDQpS ZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBTQ0lNIFVzZXIgU2NlbmFyaW9zDQpDcmVhdGlvbiBkYXRl OgkgMjAxMy0wMS0xNQ0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2Yg cGFnZXM6IDEwDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWxpLXNjaW0tdXNlci1zY2VuYXJpb3MtMDAudHh0DQpTdGF0dXM6ICAgICAg ICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGktc2NpbS11c2VyLXNj ZW5hcmlvcw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1saS1zY2ltLXVzZXItc2NlbmFyaW9zLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3Vt ZW50IGxpc3RzIHRoZSB1c2VyIHNjZW5hcmlvcyBvZiBTeXN0ZW0gZm9yIENyb3NzLWRvbWFpbg0K ICAgSWRlbnRpdHkgTWFuYWdlbWVudCAoU0NJTSkuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From tatsuo.kudo@gmail.com Wed Jan 16 02:28:53 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D6421F87AD for ; Wed, 16 Jan 2013 02:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSS8VE41vG9q for ; Wed, 16 Jan 2013 02:28:52 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id 4463521F8633 for ; Wed, 16 Jan 2013 02:28:51 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id eg20so1200878lab.30 for ; Wed, 16 Jan 2013 02:28:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=DHMEznnxWkYaX3OEIyGUdta8DsVe4uXD542fHb/UG1A=; b=tpGjNi1kzm8BZlG0nj0KuWENXEIQFhJnyjwPSvycHXGFmu3xwudjChA+9z274dUZhn iejJSu6Gcct+1nadIkANcKo32U3inSPBjZx0tzFa+lUyjB/10zpFymDQK17PusSFY5+8 dIEauxUbWeBfp6mqEPR2Z9a8ludiNKJsVfHzhsEuFhDzmIx8/0Lr9hy0hnO5fKqs8GGw /37naq/4lhW5IsBmf3mFi70ZljZUdM1Ng8EV0JETrC6s9IzjN+FgMWkqUBmaOnzkL/iT FRPzSZc72uOATaA1/c9Zvd1ZbwyjPSKKa5N8eVjWTu/FbeTx9RpyKXVFtquBlC9pAQQz 5iow== MIME-Version: 1.0 X-Received: by 10.112.10.200 with SMTP id k8mr416921lbb.73.1358332130870; Wed, 16 Jan 2013 02:28:50 -0800 (PST) Received: by 10.112.113.99 with HTTP; Wed, 16 Jan 2013 02:28:50 -0800 (PST) Date: Wed, 16 Jan 2013 19:28:50 +0900 Message-ID: From: Tatsuo Kudo To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=bcaec54ee29025c47504d3655887 Subject: [scim] Concurrent responsibilities X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 10:28:53 -0000 --bcaec54ee29025c47504d3655887 Content-Type: text/plain; charset=ISO-8859-1 Today I had a discussion with a SaaS vendor on adding SCIM API to their collaboration services, and we have concluded that we may have to develop another new schema to represent "concurrent responsibilities" e.g. a person holding two titles, officer at HQ and president at a subsidiary company as follows (group may be unique identifier): ... "titles": [ { "title": "Officer", "group": "HQ" }, { "title": "US Employees", "group": "Subsidiary A" } ], ... Any comments would be appreciated. Thanks, Tatsuo. --bcaec54ee29025c47504d3655887 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Today I had a discussion with a SaaS vendor on adding S= CIM API to=A0their collaboration services, and we have concluded that we ma= y have=A0to=A0develop another new schema to represent=A0"= concurrent=A0responsibilities" e.g. a person holding two titles, offic= er at HQ and=A0president at a subsidiary company as follows (group may be u= nique=A0identifier):

...
=A0 "titles": [
=A0 =A0 {
=A0 =A0 =A0 "titl= e": "Officer",
=A0 =A0 =A0 "group": "HQ&qu= ot;
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0 "title": "US E= mployees",
=A0 =A0 =A0 "group": "Subsidiary A"<= br> =A0 =A0 }
=A0 ],
...

Any comments would be appreciated.
Thanks,
Tatsuo. --bcaec54ee29025c47504d3655887-- From pradtke@stanford.edu Wed Jan 16 10:19:18 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04D021F8B8B for ; Wed, 16 Jan 2013 10:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA0vRrPZVyBd for ; Wed, 16 Jan 2013 10:19:18 -0800 (PST) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7E921F8859 for ; Wed, 16 Jan 2013 10:19:17 -0800 (PST) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CE4D3645EB2; Wed, 16 Jan 2013 10:19:16 -0800 (PST) Received: from radtke.local (c-50-131-40-145.hsd1.ca.comcast.net [50.131.40.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pradtke) by smtp.stanford.edu (Postfix) with ESMTPSA id F026F645ED2; Wed, 16 Jan 2013 10:19:13 -0800 (PST) Message-ID: <50F6EF1D.4000009@stanford.edu> Date: Wed, 16 Jan 2013 10:19:09 -0800 From: Patrick Radtke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tatsuo Kudo References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" Subject: Re: [scim] Concurrent responsibilities X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 18:19:18 -0000 At Universities, "concurrent responsibilities" can also mean multiple offices, phone numbers, email addresses, etc for each role. The challenge with using existing multivalued attributes for these is correlating the phone, email address, office addresses together to know which ones belong to a given role. What is the SaaS vendor using the "concurrent responsibilities" for? If it is for access control, can 'entitlement' or 'group' suffice? Is it for information purposes in the UI? -Patrick On 1/16/13 2:28 AM, Tatsuo Kudo wrote: > Today I had a discussion with a SaaS vendor on adding SCIM API to their > collaboration services, and we have concluded that we may have to > develop another new schema to represent "concurrent responsibilities" > e.g. a person holding two titles, officer at HQ and president at a > subsidiary company as follows (group may be unique identifier): > > ... > "titles": [ > { > "title": "Officer", > "group": "HQ" > }, > { > "title": "US Employees", > "group": "Subsidiary A" > } > ], > ... > > Any comments would be appreciated. > > Thanks, > Tatsuo. > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From prateek.mishra@oracle.com Thu Jan 17 08:08:19 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9445321F85BF for ; Thu, 17 Jan 2013 08:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWRltKZ-5WH5 for ; Thu, 17 Jan 2013 08:08:13 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0425E21F85C2 for ; Thu, 17 Jan 2013 08:08:12 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0HG8BHR006311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 17 Jan 2013 16:08:12 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0HG8BCx026291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Jan 2013 16:08:11 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0HG8BSp002789 for ; Thu, 17 Jan 2013 10:08:11 -0600 Received: from [184.48.102.215] (/184.48.102.215) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Jan 2013 08:08:10 -0800 Message-ID: <50F821FA.3080103@oracle.com> Date: Thu, 17 Jan 2013 11:08:26 -0500 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: scim@ietf.org Content-Type: multipart/alternative; boundary="------------010801030300050802000400" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [scim] Comments on draft-ietf-scim-core-schema-00 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 16:08:19 -0000 This is a multi-part message in MIME format. --------------010801030300050802000400 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Section 5.1 - Common Schema Attributes A) [quote] id Unique identifier for the SCIM Resource as defined by the Service Provider. Each representation of the Resource MUST include a non-empty id value. This identifier MUST be unique across the Service Provider's entire set of Resources. It MUST be a stable, non-reassignable identifier that does not change when the same Resource is returned in subsequent requests. The value of the id attribute is always issued by the Service Provider and MUST never be specified by the Service Consumer. bulkId: is a reserved keyword and MUST NOT be used in the unique identifier. REQUIRED and READ-ONLY. [\quote] This is an odd way to state a requirement that the service provider choose an identifier that is unique over all service providers and time.The reference to bulkId is confusing and should be removed. Many protocols have a similar uniqueness requirement, for example, in SAML 2.0 there is the language - [saml2.0] The mechanism by which a SAML system entity ensures that the identifier is unique is left to the implementation. In the case that a random or pseudorandom technique is employed, the probability of two randomly chosen identifiers being identical MUST be less than or equal to 2-128 and SHOULD be less than or equal to 2-160. This requirement MAY be met by encoding a randomly chosen value between 128 and 160 bits in length. A pseudorandom generator MUST be seeded with unique material in order to ensure the desired uniqueness properties between different systems. [\saml2.0] or in the JWT draft specification (v05) [JWT-05] The jti (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object. The jti claim can be used to prevent the JWT from being replayed. [\JWT-05] B) [quote] externalId Unique identifier for the Resource as defined by the Service Consumer. The externalId may simplify identification of the Resource between Service Consumer and Service provider by allowing the Consumer to refer to the Resource with its own identifier, obviating the need to store a local mapping between the local identifier of the Resource and the identifier used by the Service Provider. Each Resource MAY include a non-empty externalId value. The value of the externalId attribute is always issued be the Service Consumer and can never be specified by the Service Provider. This identifier MUST be unique across the Service Consumer's entire set of Resources. It MUST be a stable, non-reassignable identifier that does not change when the same Resource is returned in subsequent requests. The Service Provider MUST always interpret the externalId as scoped to the Service Consumer's tenant. [\quote] I found this very confusing. I understand that the Service Consumer is allowed to set an identifier for a resource - though its optional, so thats well and good. Further, this identifier MUST always be returned with the resource. But how are these other requirements regarding tenancy and uniqueness "across the Service Consumer's entire set of Resources" going to be enforced? Will the service provider be required to search through its entire repository to ensure these constraints are met? --------------010801030300050802000400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Section 5.1 - Common Schema Attributes

A)

[quote]
id
Unique identifier for the SCIM Resource as defined by the Service Provider. Each representation of the Resource MUST include a non-empty id value. This identifier MUST be unique across the Service Provider's entire set of Resources. It MUST be a stable, non-reassignable identifier that does not change when the same Resource is returned in subsequent requests. The value of the id attribute is always issued by the Service Provider and MUST never be specified by the Service Consumer. bulkId: is a reserved keyword and MUST NOT be used in the unique identifier. REQUIRED and READ-ONLY.
[\quote]

This is an odd way to state a requirement that the service provider choose an identifier that is unique over all service providers and time.The reference to bulkId is confusing and should be removed.

Many protocols have a similar uniqueness requirement, for example, in SAML 2.0 there is the language -

[saml2.0]
The mechanism by which a SAML system entity ensures that the identifier is unique is left to the
implementation. In the case that a random or pseudorandom technique is employed, the probability of two
randomly chosen identifiers being identical MUST be less than or equal to 2-128 and SHOULD be less than
or equal to 2-160. This requirement MAY be met by encoding a randomly chosen value between 128 and
160 bits in length. A pseudorandom
generator MUST be seeded with unique material in order to ensure the desired uniqueness properties
between different systems.
[\saml2.0]

or in the JWT draft specification (v05)

[JWT-05]
The jti (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be
assigned in a manner that ensures that there is a negligible probability that the same value
will be accidentally assigned to a different data object. The jti claim can be used to prevent
the JWT from being replayed.
[\JWT-05]


B)

[quote]
externalId
Unique identifier for the Resource as defined by the Service Consumer. The externalId may simplify identification of the Resource between Service Consumer and Service provider by allowing the Consumer to refer to the Resource with its own identifier, obviating the need to store a local mapping between the local identifier of the Resource and the identifier used by the Service Provider. Each Resource MAY include a non-empty externalId value. The value of the externalId attribute is always issued be the Service Consumer and can never be specified by the Service Provider. This identifier MUST be unique across the Service Consumer's entire set of Resources. It MUST be a stable, non-reassignable identifier that does not change when the same Resource is returned in subsequent requests. The Service Provider MUST always interpret the externalId as scoped to the Service Consumer's tenant.

[\quote]

I found this very confusing. I understand that the Service Consumer is allowed to set an identifier for a resource - though its optional, so thats well and good. Further, this identifier MUST always be returned with the resource.

But how are these other requirements regarding tenancy and uniqueness "across the Service Consumer's entire set of Resources" going to be enforced?
Will the service provider  be required to search through its entire repository to ensure these constraints are met? 
--------------010801030300050802000400-- From tatsuo.kudo@gmail.com Wed Jan 30 02:35:56 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CC021F878F for ; Wed, 30 Jan 2013 02:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFWRbjEfn+sz for ; Wed, 30 Jan 2013 02:35:55 -0800 (PST) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id BD4CB21F8795 for ; Wed, 30 Jan 2013 02:35:55 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id rq13so892748pbb.32 for ; Wed, 30 Jan 2013 02:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/S+b59QE/6jpmVAbS9AceQ9KoCpsdO8bi4X4ZmG0M7M=; b=de8CAkTBkJmqcOrLSfSLd/oR+vd/ok5wweWUnk4ObURdw0UiPO1zXuPy90eggwfrvw dq0P7ITJFylBxQfOUCan1ESh3bXDNEcaOCfS8Lg9JmEOQWy0wGjrdObiotmP9ov8QxX/ X2EnrvO+yyesvaherdbSJbX+Q1dvhKgMpGOKrKqw9SRTtGQP8UrEbxVQX+VxOyX4Fb9d hWrgNtc4/gp5C+twVuc/GKmAJWRwy1A5S2Bpyqwkrhg6jSGgYV5CV3fyyfgkeyfHhGw0 QjeZJB7eqvhrAR+0hFpnJJmS4yDBLYlIhVbTE1CkUvJXqoWdBIexEFWHNi8h4MWOI84e qm0Q== X-Received: by 10.68.237.42 with SMTP id uz10mr11270478pbc.118.1359542155553; Wed, 30 Jan 2013 02:35:55 -0800 (PST) Received: from [111.188.38.11] (EM111-188-38-11.pool.e-mobile.ne.jp. [111.188.38.11]) by mx.google.com with ESMTPS id t6sm1672023paz.11.2013.01.30.02.35.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 02:35:54 -0800 (PST) Message-ID: <5108F783.7000208@gmail.com> Date: Wed, 30 Jan 2013 19:35:47 +0900 From: Tatsuo Kudo User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Patrick Radtke References: <50F6EF1D.4000009@stanford.edu> In-Reply-To: <50F6EF1D.4000009@stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" Subject: Re: [scim] Concurrent responsibilities X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 10:35:56 -0000 Hi Patrick, (2013/01/17 3:19), Patrick Radtke wrote: > At Universities, "concurrent responsibilities" can also mean multiple offices, phone numbers, email addresses, etc for each role. > The challenge with using existing multivalued attributes for these is correlating the phone, email address, office addresses together to know which ones belong to a given role. They are doing access control with the correlated attributes. An employee would have full access within one of subsidiaries as a president, while a bit resricted within its headquarter. > > What is the SaaS vendor using the "concurrent responsibilities" for? > If it is for access control, can 'entitlement' or 'group' suffice? It may be applicable if the vendor agrees the following for example. I will be discussing later. "roles": [ { "value": "" }, { "value": "" }, ], > Is it for information purposes in the UI? It would be used for UI as well as access control. Tatsuo. > > -Patrick > > > > > On 1/16/13 2:28 AM, Tatsuo Kudo wrote: >> Today I had a discussion with a SaaS vendor on adding SCIM API to their >> collaboration services, and we have concluded that we may have to >> develop another new schema to represent "concurrent responsibilities" >> e.g. a person holding two titles, officer at HQ and president at a >> subsidiary company as follows (group may be unique identifier): >> >> ... >> "titles": [ >> { >> "title": "Officer", >> "group": "HQ" >> }, >> { >> "title": "US Employees", >> "group": "Subsidiary A" >> } >> ], >> ... >> >> Any comments would be appreciated. >> >> Thanks, >> Tatsuo. >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> > From tatsuo.kudo@gmail.com Wed Jan 30 02:51:24 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3222321F87CC for ; Wed, 30 Jan 2013 02:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUMUXOAs-ZKl for ; Wed, 30 Jan 2013 02:51:23 -0800 (PST) Received: from mail-da0-f41.google.com (mail-da0-f41.google.com [209.85.210.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6C99F21F876E for ; Wed, 30 Jan 2013 02:51:23 -0800 (PST) Received: by mail-da0-f41.google.com with SMTP id e20so721517dak.0 for ; Wed, 30 Jan 2013 02:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ueslK6t3dOASND1a7K6ZOw8jd9bvmB/hJ1GSbf7eW0o=; b=0U94Ck+KpWtcRDUZ16whQRgaPJyV+bpiwsngmOWbIJN1AQ5NnLa24dqHtZoiu+ZyFH cnNCM4ffMjQinoY97HhgAzLTV0F8KTAZmLolrHHFR0NFMvXolkTyHTGOZ9jIZaThVVLC cgyLPXn44Wi/ksod/q4pibkYfneXO8VjBBllUz6g+1r9DsbS4oyuIZOXDtKD4kMD3jL6 5u0BvPuCa14XOvztY0F39VvlCVV1wBj0gAVtaHcMjSFSvRt3n+qRrga497LhYYGNJFsP hStHFWTzI16dH9iKJpazIOuaME+DNPOlcVafwv/z8qsP2cruKC62bDmzK0jfTfJKKlxD euVw== X-Received: by 10.68.209.170 with SMTP id mn10mr11587492pbc.11.1359543083072; Wed, 30 Jan 2013 02:51:23 -0800 (PST) Received: from [111.188.38.11] (EM111-188-38-11.pool.e-mobile.ne.jp. [111.188.38.11]) by mx.google.com with ESMTPS id kl3sm1272234pbc.15.2013.01.30.02.51.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 02:51:21 -0800 (PST) Message-ID: <5108FB25.7000700@gmail.com> Date: Wed, 30 Jan 2013 19:51:17 +0900 From: Tatsuo Kudo User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [scim] Phonetic representation of values X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2013 10:51:24 -0000 A couple of SaaS providers / ASPs in Japan are asking how to specify phonetic representation in SCIM. Has anyone done that? I suppose the following example but don't know which is better in practice. - "value;lang-ja;phonetic":"" - "value#ja-kana-JP":"..." - "value#ja_kana_JP":"..." - { "value":"...","locale":"ja-kana-JP" } Any comments appreciated. Tatsuo. From phil.hunt@oracle.com Thu Jan 31 10:20:35 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF1721F8807 for ; Thu, 31 Jan 2013 10:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnEtwc6kN4V8 for ; Thu, 31 Jan 2013 10:20:34 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D28BF21F87AA for ; Thu, 31 Jan 2013 10:20:34 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0VIKX7M031799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 31 Jan 2013 18:20:34 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0VIKXoC002650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2013 18:20:33 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0VIKXVQ026485 for ; Thu, 31 Jan 2013 12:20:33 -0600 Received: from [192.168.1.14] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 31 Jan 2013 10:20:32 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_13956003-8ED7-43AE-95F9-F938C3AD2FBD" Date: Thu, 31 Jan 2013 10:20:31 -0800 Message-Id: <9497C84B-61CB-4B7C-AB21-79CB6390597A@oracle.com> To: "scim@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [scim] BulkId - how transient is it? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 18:20:35 -0000 --Apple-Mail=_13956003-8ED7-43AE-95F9-F938C3AD2FBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Is bulkId intended to span multiple request/responses or is it intended = only to be valid within a single bulk request? In other words, if a = bulk sequence of operations were split across 2 or more requests, could = bulkId be valid? =46rom the spec... bulkId The transient identifier of a newly created Resource, unique within a bulk request and created by the Consumer. The bulkId serves as a surrogate Resource id enabling Consumers to uniquely identify newly created Resources in the Response and cross reference new Resources in and across operations within a bulk request. REQUIRED when method is POST. Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_13956003-8ED7-43AE-95F9-F938C3AD2FBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Is = bulkId intended to span multiple request/responses or is it intended = only to be valid within a single bulk request?  In other words, if = a bulk sequence of operations were split across 2 or more requests, = could bulkId be valid?

=46rom the = spec...

bulkId =
 The transient identifier of a newly created Resource,
         unique within a bulk request and created by the Consumer.  The
         bulkId serves as a surrogate Resource id enabling Consumers to
         uniquely identify newly created Resources in the Response and
         cross reference new Resources in and across operations within a
         bulk request.  REQUIRED when method is =
POST.

Thanks,
Phil
= --Apple-Mail=_13956003-8ED7-43AE-95F9-F938C3AD2FBD-- From kelly.grizzle@sailpoint.com Thu Jan 31 11:05:51 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A78121F87D3 for ; Thu, 31 Jan 2013 11:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFlNYOHxV2kM for ; Thu, 31 Jan 2013 11:05:50 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 42BCA21F87CD for ; Thu, 31 Jan 2013 11:05:50 -0800 (PST) Received: from mail271-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Thu, 31 Jan 2013 19:05:49 +0000 Received: from mail271-va3 (localhost [127.0.0.1]) by mail271-va3-R.bigfish.com (Postfix) with ESMTP id 38EF38003FB; Thu, 31 Jan 2013 19:05:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.133; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0412HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic85dh4015Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh18c673h1954cbh18602eh8275bhz31h2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h1155h) Received-SPF: softfail (mail271-va3: transitioning domain of sailpoint.com does not designate 132.245.1.133 as permitted sender) client-ip=132.245.1.133; envelope-from=kelly.grizzle@sailpoint.com; helo=BLUPRD0412HT002.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail271-va3 (localhost.localdomain [127.0.0.1]) by mail271-va3 (MessageSwitch) id 13596591272824_18910; Thu, 31 Jan 2013 19:05:27 +0000 (UTC) Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.250]) by mail271-va3.bigfish.com (Postfix) with ESMTP id EB04EA80052; Thu, 31 Jan 2013 19:05:26 +0000 (UTC) Received: from BLUPRD0412HT002.namprd04.prod.outlook.com (132.245.1.133) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 31 Jan 2013 19:05:18 +0000 Received: from BLUPRD0412MB643.namprd04.prod.outlook.com ([169.254.4.169]) by BLUPRD0412HT002.namprd04.prod.outlook.com ([10.255.214.163]) with mapi id 14.16.0263.000; Thu, 31 Jan 2013 19:05:18 +0000 From: Kelly Grizzle To: Phil Hunt , "scim@ietf.org WG" , =?iso-8859-1?Q?Erik_Wahlstr=F6m_=28erik=2Ewahlstrom=40nexussafe=2Ecom=29?= Thread-Topic: [scim] BulkId - how transient is it? Thread-Index: AQHN/9+zvrcUxJt0U0Ok4hzGID3fXJhjy83w Date: Thu, 31 Jan 2013 19:05:17 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C343753AA4AA5@BLUPRD0412MB643.namprd04.prod.outlook.com> References: <9497C84B-61CB-4B7C-AB21-79CB6390597A@oracle.com> In-Reply-To: <9497C84B-61CB-4B7C-AB21-79CB6390597A@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 660E80FA003BD0660E8247 x-originating-ip: [173.226.147.242] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C343753AA4AA5BLUPRD0412MB643_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] BulkId - how transient is it? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:05:51 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C343753AA4AA5BLUPRD0412MB643_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe that bulkId was intended to be scoped to a single request. Erik,= do you have any thoughts? --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Thursday, January 31, 2013 12:21 PM To: scim@ietf.org WG Subject: [scim] BulkId - how transient is it? Is bulkId intended to span multiple request/responses or is it intended onl= y to be valid within a single bulk request? In other words, if a bulk sequ= ence of operations were split across 2 or more requests, could bulkId be va= lid? >From the spec... bulkId The transient identifier of a newly created Resource, unique within a bulk request and created by the Consumer. The bulkId serves as a surrogate Resource id enabling Consumers to uniquely identify newly created Resources in the Response and cross reference new Resources in and across operations within a bulk request. REQUIRED when method is POST. Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_56C3C758F9D6534CA3778EAA1E0C343753AA4AA5BLUPRD0412MB643_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I believe that bulkId was= intended to be scoped to a single request.  Erik, do you have any tho= ughts?

 <= /p>

--Kelly=

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, January 31, 2013 12:21 PM
To: scim@ietf.org WG
Subject: [scim] BulkId - how transient is it?

 

Is bulkId intended to span multiple request/response= s or is it intended only to be valid within a single bulk request?  In= other words, if a bulk sequence of operations were split across 2 or more = requests, could bulkId be valid?

 

From the spec...

 

bulkId  The=
 transient identifier of a newly created Resource,
         unique within a =
bulk request and created by the Consumer.  The
         bulkId serves as=
 a surrogate Resource id enabling Consumers to
         uniquely identif=
y newly created Resources in the Response and
         cross reference =
new Resources in and across operations within a
         bulk request.&nb=
sp; REQUIRED when method is POST.

 

Thanks,

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com=

 

 

 

--_000_56C3C758F9D6534CA3778EAA1E0C343753AA4AA5BLUPRD0412MB643_-- From phil.hunt@oracle.com Thu Jan 31 11:25:23 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DC221F8574 for ; Thu, 31 Jan 2013 11:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8KwX-vgah1B for ; Thu, 31 Jan 2013 11:25:12 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E1B1D21F8536 for ; Thu, 31 Jan 2013 11:25:11 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0VJPA8s017621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Jan 2013 19:25:11 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0VJP9TR004448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2013 19:25:09 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0VJP8Jo020807; Thu, 31 Jan 2013 13:25:08 -0600 Received: from [192.168.1.14] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 31 Jan 2013 11:25:08 -0800 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E0D74199-7CD0-4A5C-96B7-5C47D97651C8" From: Phil Hunt In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C343753AA4AA5@BLUPRD0412MB643.namprd04.prod.outlook.com> Date: Thu, 31 Jan 2013 11:25:06 -0800 Message-Id: References: <9497C84B-61CB-4B7C-AB21-79CB6390597A@oracle.com> <56C3C758F9D6534CA3778EAA1E0C343753AA4AA5@BLUPRD0412MB643.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "scim@ietf.org WG" , =?iso-8859-1?Q?Erik_Wahlstr=F6m_=28erik=2Ewahlstrom=40nexussafe?= =?iso-8859-1?Q?=2Ecom=29?= Subject: Re: [scim] BulkId - how transient is it? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:25:23 -0000 --Apple-Mail=_E0D74199-7CD0-4A5C-96B7-5C47D97651C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 To give some more background to the reason I'm asking. I'm considering = what are the issues with ASYNC processing (where an operation does not = complete immediately, eg. because of a workflow requirement). If we had = asynchronous support, then it would create requirements (and conflicts) = similar to bulk requests in that you have a series of transactions that = may have to reference each other. For example, if someone POSTs a new = User object and then wants to subsequently modify or reference that = object prior to completion, than the same transient id issue comes up. I'm looking for a way we could have a generalized simple solution. If = the server returned status 202 (accepted) on the original POST, the URL = returned could have qualities similar to bulkId. This allows follow-on = transactions/references to occur. Naturally, if the original POST fails, = than as in Bulk, the dependent operations also fail. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-01-31, at 11:05 AM, Kelly Grizzle wrote: > I believe that bulkId was intended to be scoped to a single request. = Erik, do you have any thoughts? > =20 > --Kelly > =20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Thursday, January 31, 2013 12:21 PM > To: scim@ietf.org WG > Subject: [scim] BulkId - how transient is it? > =20 > Is bulkId intended to span multiple request/responses or is it = intended only to be valid within a single bulk request? In other words, = if a bulk sequence of operations were split across 2 or more requests, = could bulkId be valid? > =20 > =46rom the spec... > =20 > bulkId The transient identifier of a newly created Resource, > unique within a bulk request and created by the Consumer. = The > bulkId serves as a surrogate Resource id enabling Consumers = to > uniquely identify newly created Resources in the Response and > cross reference new Resources in and across operations within = a > bulk request. REQUIRED when method is POST. > =20 > Thanks, > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > =20 > =20 >=20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_E0D74199-7CD0-4A5C-96B7-5C47D97651C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 To = give some more background to the reason I'm asking. I'm considering what = are the issues with ASYNC processing (where an operation does not = complete immediately, eg. because of a workflow requirement). If we had = asynchronous support, then it would create requirements (and conflicts) = similar to bulk requests in that you have a series of transactions that = may have to reference each other. For example, if someone POSTs a new = User object and then wants to subsequently modify or reference that = object prior to completion, than the same transient id issue comes = up.

I'm looking for a way we could have a generalized = simple solution. If the server returned status 202 (accepted) on the = original POST, the URL returned could have qualities similar to bulkId. =  This allows follow-on transactions/references to occur. Naturally, = if the original POST fails, than as in Bulk, the dependent operations = also fail.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2013-01-31, at 11:05 AM, Kelly Grizzle wrote:

I = believe that bulkId was intended to be scoped to a single request.  = Erik, do you have any thoughts?
From: scim-bounces@ietf.org = [mailto:scim-bounces@ietf.org] On Behalf Of Phil = Hunt
Sent: Thursday, January 31, 2013 = 12:21 PM
To: scim@ietf.org = WG
Subject: [scim] BulkId - how = transient is it?
 
Is bulkId intended to = span multiple request/responses or is it intended only to be valid = within a single bulk request?  In other words, if a bulk sequence = of operations were split across 2 or more requests, could bulkId be = valid?
=46rom the = spec...
bulkId  The transient = identifier of a newly created Resource,
         unique within =
a bulk request and created by the Consumer.  =
The
         uniquely =
identify newly created Resources in the Response =
and
         bulk =
request.  REQUIRED when method is =
POST.
 
@independentid

 

scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_E0D74199-7CD0-4A5C-96B7-5C47D97651C8-- From prvs=5743E7014E=erik.wahlstrom@nexussafe.com Thu Jan 31 12:44:21 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6C921F8505 for ; Thu, 31 Jan 2013 12:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pnq3Txit99sW for ; Thu, 31 Jan 2013 12:44:20 -0800 (PST) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4C521F8546 for ; Thu, 31 Jan 2013 12:44:19 -0800 (PST) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.1.438.0; Thu, 31 Jan 2013 21:44:09 +0100 Received: from MARVMAILDB.technxs.com ([fe80::95d1:b13:6f90:bdad]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0438.000; Thu, 31 Jan 2013 21:44:13 +0100 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] BulkId - how transient is it? Thread-Index: AQHN/9+1Iku4MBWbAE+Ya7l1cowZS5hju02AgAAFiQCAABYbgA== Date: Thu, 31 Jan 2013 20:44:13 +0000 Message-ID: <9D0D3B21-41FA-4418-92D2-9A297B30F369@nexussafe.com> References: <9497C84B-61CB-4B7C-AB21-79CB6390597A@oracle.com> <56C3C758F9D6534CA3778EAA1E0C343753AA4AA5@BLUPRD0412MB643.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.12] Content-Type: multipart/alternative; boundary="_000_9D0D3B2141FA441892D29A297B30F369nexussafecom_" MIME-Version: 1.0 Cc: "scim@ietf.org WG" , Kelly Grizzle Subject: Re: [scim] BulkId - how transient is it? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 20:44:21 -0000 --_000_9D0D3B2141FA441892D29A297B30F369nexussafecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yeah. It's, in it's current form, only valid in one request. This where my 5 cents when we tried to get async into bulk. We opted out fr= om it and settled for the limitations instead. They include some pros and cons. Nothing fancy though. The three alternatives we looked at: https://code.google.com/p/scim/issues/attachmentText?id=3D11&aid=3D11000500= 0&name=3Dbatch_0.1.txt&token=3DP_jxo114_stZ91x1fRZ39IQ93F8%3A1359663928990#= 287 The final version before we removed it: https://code.google.com/p/scim/issues/attachmentText?id=3D11&aid=3D11001000= 0&name=3Dbulk_0.6.txt&token=3DDZPyExCX4vkWBBmg_4pDigSS3TA%3A1359663928991#5= 47 / Erik On Jan 31, 2013, at 8:25 PM, Phil Hunt wrote: To give some more background to the reason I'm asking. I'm considering what= are the issues with ASYNC processing (where an operation does not complete= immediately, eg. because of a workflow requirement). If we had asynchronou= s support, then it would create requirements (and conflicts) similar to bul= k requests in that you have a series of transactions that may have to refer= ence each other. For example, if someone POSTs a new User object and then w= ants to subsequently modify or reference that object prior to completion, t= han the same transient id issue comes up. I'm looking for a way we could have a generalized simple solution. If the s= erver returned status 202 (accepted) on the original POST, the URL returned= could have qualities similar to bulkId. This allows follow-on transaction= s/references to occur. Naturally, if the original POST fails, than as in Bu= lk, the dependent operations also fail. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-01-31, at 11:05 AM, Kelly Grizzle wrote: I believe that bulkId was intended to be scoped to a single request. Erik,= do you have any thoughts? --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, January 31, 2013 12:21 PM To: scim@ietf.org WG Subject: [scim] BulkId - how transient is it? Is bulkId intended to span multiple request/responses or is it intended onl= y to be valid within a single bulk request? In other words, if a bulk sequ= ence of operations were split across 2 or more requests, could bulkId be va= lid? >From the spec... bulkId The transient identifier of a newly created Resource, unique within a bulk request and created by the Consumer. The bulkId serves as a surrogate Resource id enabling Consumers to uniquely identify newly created Resources in the Response and cross reference new Resources in and across operations within a bulk request. REQUIRED when method is POST. Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_9D0D3B2141FA441892D29A297B30F369nexussafecom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Yeah. It's, in it's current form, only valid in one request. 
This where my 5 cents when we tried to get async into bulk. We opted o= ut from it and settled for the limitations instead.

They include some pros and cons. Nothing fancy though.

The three alternatives we looked at:
 
The final version before we removed it:

/ Erik


On Jan 31, 2013, at 8:25 PM, Phil Hunt wrote:

To give some more background to the reason I'm asking. I'm considering what= are the issues with ASYNC processing (where an operation does not complete= immediately, eg. because of a workflow requirement). If we had asynchronou= s support, then it would create requirements (and conflicts) similar to bulk requests in that you have a s= eries of transactions that may have to reference each other. For example, i= f someone POSTs a new User object and then wants to subsequently modify or = reference that object prior to completion, than the same transient id issue comes up.

I'm looking for a way we could have a generalized simple solution. If = the server returned status 202 (accepted) on the original POST, the URL ret= urned could have qualities similar to bulkId.  This allows follow-on t= ransactions/references to occur. Naturally, if the original POST fails, than as in Bulk, the dependent operations also= fail.


On 2013-01-31, at 11:05 AM, Kelly Grizzle wrote:

I believe that bulkId was intended to be scoped to a sing= le request.  Erik, do you have any thoughts?
 
--Kelly
 
From:=  scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] = On Behalf Of Phil Hunt
Sent: Thursday, Ja= nuary 31, 2013 12:21 PM
To: scim@ietf.org WG
Subject: [scim] Bu= lkId - how transient is it?
 
Is bulkId intended to span multiple request/responses or is it intended onl= y to be valid within a single bulk request?  In other words, if a bulk= sequence of operations were split across 2 or more requests, could bulkId = be valid?
 
>From the spec...
 
<=
span style=3D"font-size: 12pt; color: black; ">bulkId  The transient i=
dentifier of a newly created Resource,
 &nbs=
p;       unique within a bulk request and cre=
ated by the Consumer.  The
 &nbs=
p;       bulkId serves as a surrogate Resourc=
e id enabling Consumers to
 &nbs=
p;       uniquely identify newly created Reso=
urces in the Response and
 &nbs=
p;       cross reference new Resources in and=
 across operations within a
 &nbs=
p;       bulk request.  REQUIRED when me=
thod is POST.
 
Thanks,
 
Phil
 
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org= /mailman/listinfo/scim


--_000_9D0D3B2141FA441892D29A297B30F369nexussafecom_-- From phil.hunt@oracle.com Thu Jan 31 15:27:00 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8124321F88CA for ; Thu, 31 Jan 2013 15:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQRZsxF7p0Ec for ; Thu, 31 Jan 2013 15:26:59 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85421F889C for ; Thu, 31 Jan 2013 15:26:59 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r0VNQvic002395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Jan 2013 23:26:58 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0VNQuEY022205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2013 23:26:56 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0VNQtFx000765; Thu, 31 Jan 2013 17:26:55 -0600 Received: from [192.168.1.14] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 31 Jan 2013 15:26:55 -0800 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_A1430BE2-29F9-45E3-B67A-7E571E71C415" From: Phil Hunt In-Reply-To: <9D0D3B21-41FA-4418-92D2-9A297B30F369@nexussafe.com> Date: Thu, 31 Jan 2013 15:26:52 -0800 Message-Id: <286EABE0-52AB-4957-9ABD-38C9CCB594A4@oracle.com> References: <9497C84B-61CB-4B7C-AB21-79CB6390597A@oracle.com> <56C3C758F9D6534CA3778EAA1E0C343753AA4AA5@BLUPRD0412MB643.namprd04.prod.outlook.com> <9D0D3B21-41FA-4418-92D2-9A297B30F369@nexussafe.com> To: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "scim@ietf.org WG" , Kelly Grizzle Subject: Re: [scim] BulkId - how transient is it? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 23:27:00 -0000 --Apple-Mail=_A1430BE2-29F9-45E3-B67A-7E571E71C415 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Erik, Thanks for the links. The links you provided seem to cover a very = different case than mine. In all the previous proposals, async = processing seems to be about bulk requests with large numbers of = operations that therefore might take a very long time to process. In my case, a single transaction can spontaneously (e.g. by policy) turn = into an async transaction. For example, for a particular client, it may = be policy that all new add requests go through an online approval = workflow before being completed. Or, a UI component modifies a user's email. But before that attribute = can be set, policy requires the new value be confirmed. It's conceivable = we could force the client to be "authoritative" and check the value = itself. But it is really an example of the service provider's workflow = taking final precedence (over the client's for example). Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-01-31, at 12:44 PM, Erik Wahlstr=F6m wrote: > Yeah. It's, in it's current form, only valid in one request.=20 > This where my 5 cents when we tried to get async into bulk. We opted = out from it and settled for the limitations instead. >=20 > They include some pros and cons. Nothing fancy though. >=20 > The three alternatives we looked at: > = https://code.google.com/p/scim/issues/attachmentText?id=3D11&aid=3D1100050= 00&name=3Dbatch_0.1.txt&token=3DP_jxo114_stZ91x1fRZ39IQ93F8%3A135966392899= 0#287 > =20 > The final version before we removed it: > = https://code.google.com/p/scim/issues/attachmentText?id=3D11&aid=3D1100100= 00&name=3Dbulk_0.6.txt&token=3DDZPyExCX4vkWBBmg_4pDigSS3TA%3A1359663928991= #547 >=20 > / Erik >=20 >=20 > On Jan 31, 2013, at 8:25 PM, Phil Hunt wrote: >=20 >> To give some more background to the reason I'm asking. I'm = considering what are the issues with ASYNC processing (where an = operation does not complete immediately, eg. because of a workflow = requirement). If we had asynchronous support, then it would create = requirements (and conflicts) similar to bulk requests in that you have a = series of transactions that may have to reference each other. For = example, if someone POSTs a new User object and then wants to = subsequently modify or reference that object prior to completion, than = the same transient id issue comes up. >>=20 >> I'm looking for a way we could have a generalized simple solution. If = the server returned status 202 (accepted) on the original POST, the URL = returned could have qualities similar to bulkId. This allows follow-on = transactions/references to occur. Naturally, if the original POST fails, = than as in Bulk, the dependent operations also fail. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-01-31, at 11:05 AM, Kelly Grizzle wrote: >>=20 >>> I believe that bulkId was intended to be scoped to a single request. = Erik, do you have any thoughts? >>> =20 >>> --Kelly >>> =20 >>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Phil Hunt >>> Sent: Thursday, January 31, 2013 12:21 PM >>> To: scim@ietf.org WG >>> Subject: [scim] BulkId - how transient is it? >>> =20 >>> Is bulkId intended to span multiple request/responses or is it = intended only to be valid within a single bulk request? In other words, = if a bulk sequence of operations were split across 2 or more requests, = could bulkId be valid? >>> =20 >>> =46rom the spec... >>> =20 >>> bulkId The transient identifier of a newly created Resource, >>> unique within a bulk request and created by the Consumer. = The >>> bulkId serves as a surrogate Resource id enabling Consumers = to >>> uniquely identify newly created Resources in the Response = and >>> cross reference new Resources in and across operations = within a >>> bulk request. REQUIRED when method is POST. >>> =20 >>> Thanks, >>> =20 >>> Phil >>> =20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>> =20 >>> =20 >>>=20 >>> =20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_A1430BE2-29F9-45E3-B67A-7E571E71C415 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2013-01-31, at 12:44 PM, Erik Wahlstr=F6m = wrote:

Yeah. It's, in it's current form, only valid in one = request. 
This where my 5 cents when we tried to get async into bulk. We = opted out from it and settled for the limitations instead.

They include some pros and cons. Nothing fancy though.

The three alternatives we looked at:
 
The final version before we removed it:

/ Erik


On Jan 31, 2013, at 8:25 PM, Phil Hunt wrote:

To give some more background to the reason I'm asking. I'm considering = what are the issues with ASYNC processing (where an operation does not = complete immediately, eg. because of a workflow requirement). If we had = asynchronous support, then it would create requirements (and conflicts) similar to bulk requests in that you have = a series of transactions that may have to reference each other. For = example, if someone POSTs a new User object and then wants to = subsequently modify or reference that object prior to completion, than the same transient id issue comes up.

I'm looking for a way we could have a generalized simple solution. = If the server returned status 202 (accepted) on the original POST, the = URL returned could have qualities similar to bulkId.  This allows = follow-on transactions/references to occur. Naturally, if the original POST fails, than as in Bulk, the dependent operations = also fail.


On 2013-01-31, at 11:05 AM, Kelly Grizzle wrote:

I believe that bulkId was intended to be scoped to a = single request.  Erik, do you have any = thoughts?
 
--Kelly
 
 scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, = January 31, 2013 12:21 PM
To: scim@ietf.org WG
Subject: [scim] = BulkId - how transient is it?
 
Is bulkId intended to span multiple request/responses or is it intended = only to be valid within a single bulk request?  In other words, if = a bulk sequence of operations were split across 2 or more requests, = could bulkId be valid?
 
=46rom the spec...
 
         unique within =
a bulk request and created by the Consumer.  =
The
         bulkId serves =
as a surrogate Resource id enabling Consumers to
         uniquely =
identify newly created Resources in the Response =
and
         cross =
reference new Resources in and across operations within =
a
         bulk =
request.  REQUIRED when method is POST.
 
 
 
@independentid

 

 
_______________________________________________
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=_A1430BE2-29F9-45E3-B67A-7E571E71C415--