From svella@idauto.net Wed Nov 2 14:28:46 2016 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 8F18A12996D for ; Wed, 2 Nov 2016 14:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=idauto-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5-u3rug68Bt for ; Wed, 2 Nov 2016 14:28:45 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272621294D7 for ; Wed, 2 Nov 2016 14:28:45 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 20so23973154uak.0 for ; Wed, 02 Nov 2016 14:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=idauto-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=SfaV2kcOaSSFWlRGI3xwe3VIrbhqPORMaOOA6bjR02E=; b=xKWLQJr/LUbA45XR/Ya1t2X+Bg8gEVQqiIx3sPWfLpS5puBeLT68OLKrkCbQr4oNKS 6lnZ7xt0bbJxQnoUJN97J4jeGh0T0JmyyFZDpMjsBCBhsHEGlMRq5Qn9Ec3UIZDlzI+b kkXebU5Ac+vJNgZCIaBrNbs8p9ZN6DqAcTKtXuhYOnIM1QMsqxhX4YLnOwublHiTzi84 752VLraMYXQl7tlkYwxCab0lnKWvKz8/TmidVRkR7D3VmRnYiM2QD0JbSiuyN/JmBhHr 8hQ/SKLsQ3v18l7TXT3l7A6QpKY/zlZYxfiPmcpPxr/1L5+fHyiNDfLvoboqkELMUz2w Icqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SfaV2kcOaSSFWlRGI3xwe3VIrbhqPORMaOOA6bjR02E=; b=W83x4vkeCvIJeUXHY2TIPg6zvd46aFrqdwARSaJzPbm63hvUjzT5pP9/Msp1fvra4s Re/w0xWFWy5w8/aFmDXUgtDx0XUj8mVMC32GOqbhCHllEBRQArIuzzh/nThtb7wVlke/ f+nb3i22caepDPB+5akQp0lxtbJvvPFftJFfWVedVSKUTwDsld0MWMPEq24B5arhPyNa 30WDpNc+J7IW0GRmcdQl9xowmAd8UFFHSdowA2F/acvgqlKKiyDU2nW25JsqKhW0Pmme Lj7d3L2Z+/JhoemCmmTTyKNhM2lF7yqj3f7zBLlTMZ6JXTOu6Vu5BQZhs5iOwKWO+C7s rvlg== X-Gm-Message-State: ABUngvdl3osM2q6xzzbjsyVFbpOGKw/eXUgn4ZYdqvOgqY60z39yfaBJQPk5RWA1ArBpm4+X8kcGRjoj9OCZgwi+ X-Received: by 10.176.86.140 with SMTP id a12mr4614713uab.105.1478122124080; Wed, 02 Nov 2016 14:28:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.150 with HTTP; Wed, 2 Nov 2016 14:28:43 -0700 (PDT) From: "Vella, Shon" Date: Wed, 2 Nov 2016 15:28:43 -0600 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1b30c224143105405820d6 Archived-At: Subject: [scim] Clarification on expected response to single resource request with query parameters X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 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 Nov 2016 21:29:24 -0000 --94eb2c1b30c224143105405820d6 Content-Type: text/plain; charset=UTF-8 I just starting an implementation of the SCIM 2.0 specification and I found something that seems a little ambiguous in the RFC 7644. In section 3.4.1 if I GET /Users/{id I will get back on object of schema urn:ietf:params:scim:schemas:core:2.0:User. What it does not say, but can be inferred by section 3.12 is that if the resource doesn't exist, it should return status code 404 with associated urn:ietf:params:scim:api:messages:2.0:Error message. But in section 3.4.2 it says "Queries MAY be made against a single resource...", "Responses MUST be identified using the following URI: "urn:ietf:params:scim:api:messages:2.0:ListResponse"", and "A query that does not return any matches SHALL return success (HTTP status code 200) with "totalResults" set to a value of 0." That would seem to be in conflict with section 3.4.1. Is the intent that the rules of 3.4.2 only apply to queries against a single resource (/Users/{id}) if one or more of the optional query parameters is specified? Shon Vella Identity Automation --94eb2c1b30c224143105405820d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just starting an implem= entation of the SCIM 2.0 specification and I found something that seems a l= ittle ambiguous in the RFC 7644.

In section 3.4.1= if I GET /Users/{id I will get back on object of schema urn:ietf:params:sc= im:schemas:core:2.0:User. What it does not say, but can be inferred by section= 3.12 is that if the resource doesn't exist, it should return status co= de 404 with associated urn:ietf:params:scim:api:messages:2.0:Error message.

But in section 3.4.2 it says "Queries MAY be m= ade against a single resource...", "Responses MUST be identified = using the following URI: "urn:ietf:params:scim:api:messages:2.0:ListRes= ponse"", and "A query that does not return any matches SHALL= return success (HTTP =C2=A0status code 200) with "totalResults" = set to a value of 0." That would seem to be in conflict with section 3= .4.1. Is the intent that the rules of 3.4.2 only apply to queries against a= single resource (/Users/{id}) if one or more of the optional query paramet= ers is specified?

Shon Vella
Identity Automation

--94eb2c1b30c224143105405820d6-- From nobody Wed Nov 2 14:50:09 2016 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 174A1129998 for ; Wed, 2 Nov 2016 14:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0GDangwlfuO for ; Wed, 2 Nov 2016 14:50:06 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A19B1298A3 for ; Wed, 2 Nov 2016 14:50:06 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uA2Lo3sW013250 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 Nov 2016 21:50:03 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uA2Lo2bV019870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Nov 2016 21:50:02 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id uA2Lo0Lv001388; Wed, 2 Nov 2016 21:50:01 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Nov 2016 14:50:00 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_03C3D2DF-12E0-4700-9C5D-F56980BFC832" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Wed, 2 Nov 2016 14:49:59 -0700 Message-Id: <623259F0-6D23-40CF-A774-C066F4988796@oracle.com> References: To: "Vella, Shon" X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: scim@ietf.org Subject: Re: [scim] Clarification on expected response to single resource request with query parameters X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 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 Nov 2016 21:50:08 -0000 --Apple-Mail=_03C3D2DF-12E0-4700-9C5D-F56980BFC832 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Vella, If you query the /Users endpoint typically you get a ListResponse = (ListResponse just allows for multiple objects to be returned). When = querying for a specific resource, the list response is not needed and = just the user resource is returned. If you query a specific resource that does not exist you just get a 404. = You typically only get an error response for a Status 400 class error. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Nov 2, 2016, at 2:28 PM, Vella, Shon wrote: >=20 > I just starting an implementation of the SCIM 2.0 specification and I = found something that seems a little ambiguous in the RFC 7644. >=20 > In section 3.4.1 if I GET /Users/{id I will get back on object of = schema urn:ietf:params:scim:schemas:core:2.0:User. What it does not say, = but can be inferred by section 3.12 is that if the resource doesn't = exist, it should return status code 404 with associated = urn:ietf:params:scim:api:messages:2.0:Error message. >=20 > But in section 3.4.2 it says "Queries MAY be made against a single = resource...", "Responses MUST be identified using the following URI: = "urn:ietf:params:scim:api:messages:2.0:ListResponse"", and "A query that = does not return any matches SHALL return success (HTTP status code 200) = with "totalResults" set to a value of 0." That would seem to be in = conflict with section 3.4.1. Is the intent that the rules of 3.4.2 only = apply to queries against a single resource (/Users/{id}) if one or more = of the optional query parameters is specified? >=20 > Shon Vella > Identity Automation >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_03C3D2DF-12E0-4700-9C5D-F56980BFC832 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Vella,

If you query the /Users endpoint typically you get a = ListResponse (ListResponse just allows for multiple objects to be = returned).  When querying for a specific resource, the list = response is not needed and just the user resource is returned.

If you query a specific = resource that does not exist you just get a 404.  You typically = only get an error response for a Status 400 class error.




On Nov 2, 2016, at 2:28 PM, Vella, Shon <svella@idauto.net> = wrote:

I = just starting an implementation of the SCIM 2.0 specification and I = found something that seems a little ambiguous in the RFC 7644.

In section 3.4.1 = if I GET /Users/{id I will get back on object of schema = urn:ietf:params:scim:schemas:core:2.0:User. = What it does not say, but can be inferred by section 3.12 is that if the = resource doesn't exist, it should return status code 404 with associated = urn:ietf:params:scim:api:messages:2.0:Error = message.

But in section 3.4.2 it says "Queries MAY be made against a = single resource...", "Responses MUST be identified using the following = URI: "urn:ietf:params:scim:api:messages:2.0:ListResponse"", and "A query that does not = return any matches SHALL return success (HTTP  status code 200) = with "totalResults" set to a value of 0." That would seem to be in = conflict with section 3.4.1. Is the intent that the rules of 3.4.2 only = apply to queries against a single resource (/Users/{id}) if one or more = of the optional query parameters is specified?

Shon = Vella
Identity Automation

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

= --Apple-Mail=_03C3D2DF-12E0-4700-9C5D-F56980BFC832-- From nobody Wed Nov 2 15:39:37 2016 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 3BBBD1293FD for ; Wed, 2 Nov 2016 15:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=idauto-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9th_OMVO2H8 for ; Wed, 2 Nov 2016 15:39:34 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB0A12946A for ; Wed, 2 Nov 2016 15:39:34 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id d65so25658368vkg.0 for ; Wed, 02 Nov 2016 15:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=idauto-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=NErACSRHFDHdVlHTxc9ENq8XVDR7CNu+ZA4CAUFv3Kw=; b=T9VT7w5ku1RjnS0h88b3lQ0J7c0WwzF902OqnNzd/5Zd+hhCCLUxwjJxVIG/wzkncZ EFBO25MvUsj1FCi9fS6RTg2wY7MZ00purlLYOmSHFebqUiVFZW9o2w1Rs0TDGJCHxH3y tnJmIOZpsAYG+fXSFz2DNxitPioc0oVUPi2XfztslM6VZw2HQTifGuCwPLHw5LPpnhV7 OVArkR5Jn9ojIuL+5sR0gHCfPAwaRol8A/H6GhmMbvNcPxKTo4nXknPQ7/k4M1UUav0A 9/2DQcEnuNLT3LV4Zs65iWdg+6haDFMkC7DcfHTdfIgUpw2zE6rizvB1E+YcImb5w+X5 mqJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=NErACSRHFDHdVlHTxc9ENq8XVDR7CNu+ZA4CAUFv3Kw=; b=b/W4q0XCdt2ijRnHnwf+vaOlaJ5tnPhpfVNkMtxIpv0ByawuSPydqUM/sIIlEzyBGy oacsFMcWR/wulkniL1v6u4P6shlBtMgwbghqg3px32WqHiYhO2aGqxSJWjI3alKk9FrJ eFOQwxPqWqkDTLc7T24HDzEpjoWfoklzeDv0yzG2qSX+SicyEOQjuvAZCevx72unJfYe JgFzV2Y0I0EK187nRk98PfL+JuYHnzDkkIk+eL8KwOqGiFwzVIUCjfogFOYm1/Ua29RT X+vKfwWIIUgrpiTYrsmK+hL9rHSdNV6s8DOyG55/Oi6WPtVNhMyZ5sxiS7Xd0DWjOmSE oczg== X-Gm-Message-State: ABUngvcRdEkzcQPKPrDXBBdCb3BFVxlQTdUnfrbSKxDTwcuvDQMPERTk62g1kl1vN/6HW2hgXRA0EwTBG4yX6rrd X-Received: by 10.31.209.6 with SMTP id i6mr4381214vkg.144.1478126373044; Wed, 02 Nov 2016 15:39:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.150 with HTTP; Wed, 2 Nov 2016 15:39:32 -0700 (PDT) In-Reply-To: References: <623259F0-6D23-40CF-A774-C066F4988796@oracle.com> From: "Vella, Shon" Date: Wed, 2 Nov 2016 16:39:32 -0600 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary=001a114bcda06615fd0540591d18 Archived-At: Subject: Re: [scim] Clarification on expected response to single resource request with query parameters X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 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 Nov 2016 22:39:36 -0000 --001a114bcda06615fd0540591d18 Content-Type: text/plain; charset=UTF-8 But if I query, for example, GET /Users/abc123?filter=whatever and user abc123 exists but doesn't match the filter? Or even better GET /Users/abc123?startIndex=2&itemsPerPage=1 Shon Vella Identity Automation On Wed, Nov 2, 2016 at 4:34 PM, Vella, Shon wrote: > But if I query, for example, GET /Users/abc123?filter=whatever and user > abc123 exists but doesn't match the filter? > > Or even better GET /Users/abc123?startIndex=2&itemsPerPage=1 > > *Shon Vella* > *Identity Automation* > Manager of Product Engineering > 281-220-0021 x2030 office > 281-817-5579 fax > www.identityautomation.com > > On Wed, Nov 2, 2016 at 3:49 PM, Phil Hunt wrote: > >> Vella, >> >> If you query the /Users endpoint typically you get a ListResponse >> (ListResponse just allows for multiple objects to be returned). When >> querying for a specific resource, the list response is not needed and just >> the user resource is returned. >> >> If you query a specific resource that does not exist you just get a 404. >> You typically only get an error response for a Status 400 class error. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On Nov 2, 2016, at 2:28 PM, Vella, Shon wrote: >> >> I just starting an implementation of the SCIM 2.0 specification and I >> found something that seems a little ambiguous in the RFC 7644. >> >> In section 3.4.1 if I GET /Users/{id I will get back on object of schema >> urn:ietf:params:scim:schemas:core:2.0:User. What it does not say, but >> can be inferred by section 3.12 is that if the resource doesn't exist, it >> should return status code 404 with associated urn:ietf:params:scim:api: >> messages:2.0:Error message. >> >> But in section 3.4.2 it says "Queries MAY be made against a single >> resource...", "Responses MUST be identified using the following URI: >> "urn:ietf:params:scim:api:messages:2.0:ListResponse"", and "A query that >> does not return any matches SHALL return success (HTTP status code 200) >> with "totalResults" set to a value of 0." That would seem to be in conflict >> with section 3.4.1. Is the intent that the rules of 3.4.2 only apply to >> queries against a single resource (/Users/{id}) if one or more of the >> optional query parameters is specified? >> >> Shon Vella >> Identity Automation >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> >> > --001a114bcda06615fd0540591d18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
But if I query, for = example, GET /Users/abc123?filter=3Dwhatever and user abc123 exists but doe= sn't match the filter?

Or even better GET /Users/abc= 123?startIndex=3D2&= ;itemsPerP= age=3D1

Shon Vella
Identity Automation

<= /div>

On Wed, Nov 2, 2016 at 4:34 PM, Vella, Shon = <svella@identityautomation.com> wrote:
But if I query, for example, GET = /Users/abc123?filter=3Dwhatever and user abc123 exists but doesn't matc= h the filter?

Or even better GET /Users/abc123?startIndex=3D2&itemsPerPage=3D1

Shon Vella
Identity Automation
Manager = of Product Engineering
281-220-0021 x2030=C2=A0office
281-817-5579=C2=A0fax

On Wed, Nov 2, 2016 at 3:49 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Vella,

If= you query the /Users endpoint typically you get a ListResponse (ListRespon= se just allows for multiple objects to be returned).=C2=A0 When querying fo= r a specific resource, the list response is not needed and just the user re= source is returned.

If you query a specific resource tha= t does not exist you just get a 404.=C2=A0 You typically only get an error = response for a Status 400 class error.


On Nov 2, 2016, at 2:28 PM, Vella, Shon <svella@idauto.net> wrote:
I just starting an implementatio= n of the SCIM 2.0 specification and I found something that seems a little a= mbiguous in the RFC 7644.

In section 3.4.1 if I G= ET /Users/{id I will get back on object of schema urn:ietf:params:scim:sche= mas:core:2.0:User. What it doe= s not say, but can be inferred by section 3.12 is that if the resource does= n't exist, it should return status code 404 with associated urn:ietf:pa= rams:scim:api:messages:2.0:Err= or message.

But in section 3.4.2 it says "Qu= eries MAY be made against a single resource...", "Responses MUST = be identified using the following URI: "urn:ietf:params:scim:api:messages:2.0:ListResponse"&quo= t;, and "A query that does not return any matches SHALL return success= (HTTP =C2=A0status code 200) with "totalResults" set to a value = of 0." That would seem to be in conflict with section 3.4.1. Is the in= tent that the rules of 3.4.2 only apply to queries against a single resourc= e (/Users/{id}) if one or more of the optional query parameters is specifie= d?

Shon Vella
Identity Automation

_______________________________________________
scim mailing listscim@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/scim" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/scim



--001a114bcda06615fd0540591d18-- From nobody Fri Nov 11 20:05:05 2016 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 E0B3712955A; Fri, 11 Nov 2016 20:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqMaPO2rX8ct; Fri, 11 Nov 2016 20:04:56 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0118.outbound.protection.outlook.com [104.47.40.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50B11293EE; Fri, 11 Nov 2016 20:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rLYa3K2+1fA4JUki2yJ9e9ufBk2vX5QINeaFKA0aRsU=; b=d4u0DP0TtMvOrHFXFTLDfdAIGwe1mzuY1jBCuQ9Q1AwACtU5GcG5hUHPmUapj8sPhvrgU0HWeL0212neleMh2QsFmRae+vqHdk01FY3ybRJ+k8J2gR96buPBrVQL3aJa5JdtpKzBb2z4PLDLRIJn+4sfougow9q+mHXxcAAshIU= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2353.namprd03.prod.outlook.com (10.166.74.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Sat, 12 Nov 2016 04:04:43 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0707.013; Sat, 12 Nov 2016 04:04:43 +0000 From: Mike Jones To: Phil Hunt , "id-event@ietf.org" Thread-Topic: [scim] Fwd: New Version Notification for draft-hunt-idevent-token-06.txt Thread-Index: AdI8md1yqAtFwtLyRmKmSyShi4kPow== Date: Sat, 12 Nov 2016 04:04:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [12.130.119.139] x-microsoft-exchange-diagnostics: 1; BN3PR03MB2353; 7:pe3gHjonneoSOha/8gUMcdFOkMVxgsWZFiBIbnI1/8KxtUD1OTFq6/bc0Vv0vFVm3Q8NZbUmi7b+9Vtam87+7E3uxkLKv8yLsjsyhyP4BLQ0ZPcjeyOXIuXx38I7nd8XL3cGYkgMX5y3ArlxAeMswzvJKQhL/hj6lVmf4t/g/YDNP1LDoT6ib/Jed+ml4LoqNWGwskGxg5u3z0FIMdoglnkbHHqnIl1DoZEZmZoOd6GCC7glvWhvCTIBNQm6FfKszM0DW+RT68ka/NgwjVgt/8JYT7GcY/VdmlQTiKhkdF3vddoJGDWZJQnDdVzC765ol6GVHsYzvQTFbtS+vMjzX9oMO846i4uVdf9xl4BBFzNVwJpj8Eo0/BuTlBsZ2zN3 x-ms-office365-filtering-correlation-id: af40bcbd-143f-4df9-814e-08d40ab108aa x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2353; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(211936372134217)(95692535739014)(21748063052155)(146099531331640)(201166117486090); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060229)(6045074)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6046074)(6061226); SRVR:BN3PR03MB2353; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2353; x-forefront-prvs: 01244308DF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(189002)(199003)(51444003)(377424004)(7906003)(4326007)(87936001)(10710500007)(74316002)(2900100001)(14971765001)(1680700002)(54356999)(68736007)(105586002)(99286002)(50986999)(19609705001)(16601075003)(7846002)(7736002)(2906002)(102836003)(122556002)(6116002)(86362001)(86612001)(106356001)(790700001)(3846002)(66066001)(76576001)(229853002)(2501003)(92566002)(33656002)(10290500002)(8676002)(101416001)(189998001)(5005710100001)(230783001)(97736004)(9686002)(586003)(8936002)(7696004)(3280700002)(81156014)(81166006)(5001770100001)(3660700001)(8990500004)(10090500001)(5660300001)(77096005)(7110500001)(2420400007)(15650500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2353; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB23553C80B757C75672449838F5BA0BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2016 04:04:43.4972 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2353 Archived-At: Cc: "scim@ietf.org WG" , "openid-specs-ab@lists.openid.net Ab" , "openid-specs-risc@lists.openid.net" Subject: Re: [scim] Fwd: New Version Notification for draft-hunt-idevent-token-06.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 04:05:00 -0000 --_000_BN3PR03MB23553C80B757C75672449838F5BA0BN3PR03MB2355namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBqdXN0IHJldmlld2VkIHRoZSBjaGFuZ2VzIGluIGRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0w NiBhbmQsIGZvciB0aGUgcmVjb3JkLCBJ4oCZbSBmaW5lIHdpdGggdGhlbS4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K RnJvbTogc2NpbSBbbWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBo aWwgSHVudA0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyOSwgMjAxNiAzOjM5IFBNDQpUbzog aWQtZXZlbnRAaWV0Zi5vcmcNCkNjOiBzY2ltQGlldGYub3JnIFdHIDxzY2ltQGlldGYub3JnPjsg b3BlbmlkLXNwZWNzLWFiQGxpc3RzLm9wZW5pZC5uZXQgQWIgPG9wZW5pZC1zcGVjcy1hYkBsaXN0 cy5vcGVuaWQubmV0Pjsgb3BlbmlkLXNwZWNzLXJpc2NAbGlzdHMub3BlbmlkLm5ldA0KU3ViamVj dDogW3NjaW1dIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LWlk ZXZlbnQtdG9rZW4tMDYudHh0DQoNClRoaXMgaXMgYSBtaW5vciB1cGRhdGUgdG8gdGhlIFNFVCBU b2tlbiBkcmFmdC4gIEJhc2VkIG9uIHRoZSBtYWlsaW5nIGxpc3QgZmVlZGJhY2ssIEkgbWFkZSBz b21lIHJldmlzaW9ucyB0byB0aGUgdGV4dCBvbiB0cmFuc2FjdGlvbnMgYW5kIHNlcXVlbmNpbmcu ICBJIGRyb3BwZWQgdGhlIHRlcm0g4oCcaWRlbXBvdGVuY3nigJ0gYXMgdGhpcyBpcyBub3QgcmVh bGx5IHRoZSBjb3JyZWN0IHVzYWdlIG9mIHRoZSB3b3JkLg0KDQpUaGUgaXNzdWUgSSB3YXMgdHJ5 aW5nIHRvIGdldCBhdCB3YXMgd2hldGhlciBTRVRzIGNhbiBiZSBkZWxpdmVyZWQgaW4gYW55IHNl cXVlbmNlIG9yIHdoZXRoZXIgdGhlcmUgc2VxdWVuY2UgaXMgY3JpdGljYWwuIEZvciBleGFtcGxl IGluIGFuIElkZW1wb3RlbnQgc2VydmljZSwgb25lIGNhbm5vdCBtb2RpZnkgYSByZXNvdXJjZSB0 aGF0IGhhcyBub3QgeWV0IGJlZW4gY3JlYXRlZC4gIFNvIHdoaWxlIGNvbW1hbmRzIG1heSBiZSBy ZXBlYXRlZCBhY2hpZXZpbmcgdGhlIHNhbWUgcmVzdWx0LCB0aGUgc2VxdWVuY2Ugb2YgZGlmZmVy ZW50IGNvbW1hbmRzIGlzIGNyaXRpY2FsLiA4KQ0KDQpNeSBndXQgZmVlbGluZyBvbiBzZXF1ZW5j aW5nICh3aGVuIG5lZWRlZCkgaXMgbW9zdCBsaWtlbHkgcmVzb2x2ZWQgYnkgc3BlY3MgdGhhdCBw cm9maWxlIFNFVCBUb2tlcyBieSBhZGRpbmcgc2VxdWVuY2luZyBjbGFpbSBvciBkZWZpbmluZyDi gJx0eG7igJ0gZm9yIHRoZSBwdXJwb3NlLiBUaGVyZSBtYXkgYmUgc29tZSBkZWxpdmVyeSBtZXRo b2RzIHRoYXQgY2FuIHByb3ZpZGUgc2VxdWVuY2luZywgYnV0IEkgdGhpbmsgdGhhdCBoYXMgbW9y ZSB0byBkbyB3aXRoIGRlcGxveW1lbnQgYXJjaGl0ZWN0dXJlIHJhdGhlciB0aGFuIHByb3RvY29s LiBGb3IgZXhhbXBsZSwgaW4gYSBkaXN0cmlidXRlZCBzeXN0ZW0sIHRoZSB3YXkgZXZlbnRzIGFy ZSBkZWxpdmVyZWQgdG8gYSBGZWVkIFB1Ymxpc2hpbmcgU2VydmljZSBtaWdodCBlbmFibGUgdGhl IEZlZWQgUHVibGlzaGVyIHRvIGd1YXJhbnRlZSBvcmRlci4gIFRoYXTigJlzIG5vdCB0byBzYXkg SSBoYXZlbuKAmXQgb3Zlcmxvb2tlZCBhIOKAnGR1aOKAnSBzaW1wbGUgc29sdXRpb24uDQoNClRo aXMgZHJhZnQgc2hvdWxkIGJlIGEgZ29vZCBzdGFydGluZyBwbGFjZSBmb3IgdGhlIFNFQyBFdmVu dCBXRyBwcm9wb3NlZCBjaGFydGVyLg0KDQpUaGFua3MsDQoNClBoaWwNCg0KQGluZGVwZW5kZW50 aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0K cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0K DQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTA2LnR4dA0KRGF0 ZTogU2VwdGVtYmVyIDI5LCAyMDE2IGF0IDM6MjA6NDUgUE0gUERUDQpUbzogIk1pY2hhZWwgQi4g Sm9uZXMiIDxtYmpAbWljcm9zb2Z0LmNvbTxtYWlsdG86bWJqQG1pY3Jvc29mdC5jb20+PiwgIldp bGxpYW0gRGVubmlzcyIgPHdkZW5uaXNzQGdvb2dsZS5jb208bWFpbHRvOndkZW5uaXNzQGdvb2ds ZS5jb20+PiwgIlBoaWwgSHVudCIgPHBoaWwuaHVudEB5YWhvby5jb208bWFpbHRvOnBoaWwuaHVu dEB5YWhvby5jb20+PiwgIk1vcnRlemEgQW5zYXJpIiA8bW9ydGV6YS5hbnNhcmlAY2lzY28uY29t PG1haWx0bzptb3J0ZXphLmFuc2FyaUBjaXNjby5jb20+PiwgIk1pY2hhZWwgSm9uZXMiIDxtYmpA bWljcm9zb2Z0LmNvbTxtYWlsdG86bWJqQG1pY3Jvc29mdC5jb20+Pg0KDQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDYudHh0DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBoaWwgSHVudCBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiBy ZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgICBkcmFmdC1odW50LWlkZXZlbnQtdG9rZW4N ClJldmlzaW9uOiAgICAgICAgIDA2DQpUaXRsZTogICAgICAgICAgICAgICBTZWN1cml0eSBFdmVu dCBUb2tlbiAoU0VUKQ0KRG9jdW1lbnQgZGF0ZTogICAgICAgICAgIDIwMTYtMDktMjkNCkdyb3Vw OiAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAgICAg MTkNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTA2LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi8NCkh0bWxp emVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1pZGV2ZW50 LXRva2VuLTA2DQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wNg0KDQpBYnN0cmFjdDoNCiAgVGhpcyBzcGVj aWZpY2F0aW9uIGRlZmluZXMgdGhlIFNlY3VyaXR5IEV2ZW50IHRva2VuLCB3aGljaCBtYXkgYmUN CiAgZGlzdHJpYnV0ZWQgdmlhIGEgcHJvdG9jb2wgc3VjaCBhcyBIVFRQLiAgVGhlIFNlY3VyaXR5 IEV2ZW50IFRva2VuDQogIChTRVQpIHNwZWNpZmljYXRpb24gcHJvZmlsZXMgdGhlIEpTT04gV2Vi IFRva2VuIChKV1QpIGFuZCBtYXkgYmUNCiAgb3B0aW9uYWxseSBzaWduZWQgYW5kL29yIGVuY3J5 cHRlZC4gIEEgU0VUIGRlc2NyaWJlcyBhIHN0YXRlbWVudCBvZg0KICBmYWN0IHRoYXQgbWF5IGJl IHNoYXJlZCBieSBhbiBldmVudCBwdWJsaXNoZXIgd2l0aCBldmVudCBzdWJzY3JpYmVycy4NCg0K DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5v cmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= --_000_BN3PR03MB23553C80B757C75672449838F5BA0BN3PR03MB2355namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30N CnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkkganVzdCByZXZpZXdlZCB0aGUgY2hh bmdlcyBpbiBkcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDYgYW5kLCBmb3IgdGhlIHJlY29yZCwg SeKAmW0gZmluZSB3aXRoIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29t cG9zZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPlBoaWwgSHVudDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgU2VwdGVtYmVy IDI5LCAyMDE2IDM6MzkgUE08YnI+DQo8Yj5Ubzo8L2I+IGlkLWV2ZW50QGlldGYub3JnPGJyPg0K PGI+Q2M6PC9iPiBzY2ltQGlldGYub3JnIFdHICZsdDtzY2ltQGlldGYub3JnJmd0Ozsgb3Blbmlk LXNwZWNzLWFiQGxpc3RzLm9wZW5pZC5uZXQgQWIgJmx0O29wZW5pZC1zcGVjcy1hYkBsaXN0cy5v cGVuaWQubmV0Jmd0Ozsgb3BlbmlkLXNwZWNzLXJpc2NAbGlzdHMub3BlbmlkLm5ldDxicj4NCjxi PlN1YmplY3Q6PC9iPiBbc2NpbV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWh1bnQtaWRldmVudC10b2tlbi0wNi50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGEgbWlub3IgdXBkYXRlIHRvIHRoZSBTRVQgVG9r ZW4gZHJhZnQuICZuYnNwO0Jhc2VkIG9uIHRoZSBtYWlsaW5nIGxpc3QgZmVlZGJhY2ssIEkgbWFk ZSBzb21lIHJldmlzaW9ucyB0byB0aGUgdGV4dCBvbiB0cmFuc2FjdGlvbnMgYW5kIHNlcXVlbmNp bmcuICZuYnNwO0kgZHJvcHBlZCB0aGUgdGVybSDigJxpZGVtcG90ZW5jeeKAnSBhcyB0aGlzIGlz IG5vdCByZWFsbHkgdGhlIGNvcnJlY3QgdXNhZ2Ugb2YgdGhlIHdvcmQuDQogJm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaXNzdWUgSSB3YXMg dHJ5aW5nIHRvIGdldCBhdCB3YXMgd2hldGhlciBTRVRzIGNhbiBiZSBkZWxpdmVyZWQgaW4gYW55 IHNlcXVlbmNlIG9yIHdoZXRoZXIgdGhlcmUgc2VxdWVuY2UgaXMgY3JpdGljYWwuIEZvciBleGFt cGxlIGluIGFuIElkZW1wb3RlbnQgc2VydmljZSwgb25lIGNhbm5vdCBtb2RpZnkgYSByZXNvdXJj ZSB0aGF0IGhhcyBub3QgeWV0IGJlZW4gY3JlYXRlZC4gJm5ic3A7U28gd2hpbGUgY29tbWFuZHMN CiBtYXkgYmUgcmVwZWF0ZWQgYWNoaWV2aW5nIHRoZSBzYW1lIHJlc3VsdCwgdGhlIHNlcXVlbmNl IG9mIGRpZmZlcmVudCBjb21tYW5kcyBpcyBjcml0aWNhbC4gOCk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgZ3V0IGZlZWxpbmcgb24gc2Vx dWVuY2luZyAod2hlbiBuZWVkZWQpIGlzIG1vc3QgbGlrZWx5IHJlc29sdmVkIGJ5IHNwZWNzIHRo YXQgcHJvZmlsZSBTRVQgVG9rZXMgYnkgYWRkaW5nIHNlcXVlbmNpbmcgY2xhaW0gb3IgZGVmaW5p bmcg4oCcdHhu4oCdIGZvciB0aGUgcHVycG9zZS4gVGhlcmUgbWF5IGJlIHNvbWUgZGVsaXZlcnkg bWV0aG9kcyB0aGF0IGNhbiBwcm92aWRlIHNlcXVlbmNpbmcsIGJ1dCBJIHRoaW5rDQogdGhhdCBo YXMgbW9yZSB0byBkbyB3aXRoIGRlcGxveW1lbnQgYXJjaGl0ZWN0dXJlIHJhdGhlciB0aGFuIHBy b3RvY29sLiBGb3IgZXhhbXBsZSwgaW4gYSBkaXN0cmlidXRlZCBzeXN0ZW0sIHRoZSB3YXkgZXZl bnRzIGFyZSBkZWxpdmVyZWQgdG8gYSBGZWVkIFB1Ymxpc2hpbmcgU2VydmljZSBtaWdodCBlbmFi bGUgdGhlIEZlZWQgUHVibGlzaGVyIHRvIGd1YXJhbnRlZSBvcmRlci4gJm5ic3A7VGhhdOKAmXMg bm90IHRvIHNheSBJIGhhdmVu4oCZdCBvdmVybG9va2VkDQogYSDigJxkdWjigJ0gc2ltcGxlIHNv bHV0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhpcyBkcmFmdCBzaG91bGQgYmUgYSBnb29kIHN0YXJ0aW5nIHBsYWNlIGZvciB0aGUgU0VD IEV2ZW50IFdHIHByb3Bvc2VkIGNoYXJ0ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBo aWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhy ZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0i bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVnaW4gZm9yd2FyZGVkIG1l c3NhZ2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTog PC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+ aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDYudHh0PC9zcGFuPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+RGF0ZTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U2VwdGVtYmVyIDI5LCAyMDE2IGF0IDM6MjA6NDUgUE0g UERUPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5UbzogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+JnF1b3Q7TWljaGFlbCBCLiBKb25lcyZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakBtaWNyb3NvZnQuY29tIj5tYmpAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7LCAmcXVvdDtXaWxsaWFtIERlbm5pc3MmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzp3ZGVubmlzc0Bnb29nbGUuY29tIj53ZGVubmlzc0Bnb29nbGUuY29tPC9hPiZndDssICZxdW90 O1BoaWwgSHVudCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEB5YWhvby5jb20i PnBoaWwuaHVudEB5YWhvby5jb208L2E+Jmd0OywNCiAmcXVvdDtNb3J0ZXphIEFuc2FyaSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vcnRlemEuYW5zYXJpQGNpc2NvLmNvbSI+bW9ydGV6YS5h bnNhcmlAY2lzY28uY29tPC9hPiZndDssICZxdW90O01pY2hhZWwgSm9uZXMmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzptYmpAbWljcm9zb2Z0LmNvbSI+bWJqQG1pY3Jvc29mdC5jb208L2E+Jmd0 Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWh1bnQtaWRldmVudC10b2tlbi0wNi50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFBoaWwgSHVudCBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3Np dG9yeS48YnI+DQo8YnI+DQpOYW1lOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj5kcmFmdC1odW50LWlkZXZlbnQtdG9rZW48YnI+DQpSZXZpc2lvbjo8 c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+MDY8YnI+DQpUaXRsZTo8c3BhbiBjbGFzcz0iYXBw bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+U2VjdXJpdHkg RXZlbnQgVG9rZW4gKFNFVCk8YnI+DQpEb2N1bWVudCBkYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS10 YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4yMDE2LTA5LTI5PGJyPg0KR3JvdXA6PHNwYW4gY2xhc3M9ImFw cGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPkluZGl2aWR1YWwgU3VibWlzc2lv bjxicj4NClBhZ2VzOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj4xOTxicj4NClVSTDogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wNi50eHQi Pmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odW50LWlkZXZlbnQt dG9rZW4tMDYudHh0PC9hPjxicj4NClN0YXR1czogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLzwvYT48YnI+DQpIdG1saXplZDogJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wNiI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wNjwvYT48YnI+DQpEaWZmOiAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaHVudC1p ZGV2ZW50LXRva2VuLTA2Ij5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aHVudC1pZGV2ZW50LXRva2VuLTA2PC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNw OyZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIHRoZSBTZWN1cml0eSBFdmVudCB0b2tl biwgd2hpY2ggbWF5IGJlPGJyPg0KJm5ic3A7Jm5ic3A7ZGlzdHJpYnV0ZWQgdmlhIGEgcHJvdG9j b2wgc3VjaCBhcyBIVFRQLiAmbmJzcDtUaGUgU2VjdXJpdHkgRXZlbnQgVG9rZW48YnI+DQombmJz cDsmbmJzcDsoU0VUKSBzcGVjaWZpY2F0aW9uIHByb2ZpbGVzIHRoZSBKU09OIFdlYiBUb2tlbiAo SldUKSBhbmQgbWF5IGJlPGJyPg0KJm5ic3A7Jm5ic3A7b3B0aW9uYWxseSBzaWduZWQgYW5kL29y IGVuY3J5cHRlZC4gJm5ic3A7QSBTRVQgZGVzY3JpYmVzIGEgc3RhdGVtZW50IG9mPGJyPg0KJm5i c3A7Jm5ic3A7ZmFjdCB0aGF0IG1heSBiZSBzaGFyZWQgYnkgYW4gZXZlbnQgcHVibGlzaGVyIHdp dGggZXZlbnQgc3Vic2NyaWJlcnMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIj4NCnRvb2xzLmll dGYub3JnPC9hPi48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_BN3PR03MB23553C80B757C75672449838F5BA0BN3PR03MB2355namp_-- From nobody Thu Nov 17 22:26:01 2016 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 6E1D11296C8; Thu, 17 Nov 2016 22:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vBglRpgEFUP; Thu, 17 Nov 2016 22:25:52 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17A5129497; Thu, 17 Nov 2016 22:25:52 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uAI6Pm7q032504 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 18 Nov 2016 06:25:48 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uAI6Pm6x023371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 18 Nov 2016 06:25:48 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id uAI6Plcn021197; Fri, 18 Nov 2016 06:25:47 GMT Received: from [10.56.16.123] (/116.84.110.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Nov 2016 22:25:47 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_AFAC2864-6AB2-4922-B18C-F84832CF6BA7" Date: Fri, 18 Nov 2016 15:25:42 +0900 Message-Id: <8CCC780F-E02B-4BC7-B4EF-7743F088FD05@oracle.com> To: id-event@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: Tony Nadalin , Marius Scurtescu , Nancy Cam-Winget , Dick Hardt , "scim@ietf.org WG" , PRATEEK MISHRA , openid-specs-risc@lists.openid.net, Morteza Ansari Subject: [scim] Follow-up from IETF97 - XMPP Grid X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 06:25:54 -0000 --Apple-Mail=_AFAC2864-6AB2-4922-B18C-F84832CF6BA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Note: cross-posted to IdEvents, SCIM, and OpenID RISC mailing lists. At the end of the Sec Events meeting, Nancy Cam-Winget mentioned the = XMPP-Grid draft which is about to go WGLC. See: https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ = I have taken a look and my initial impression is we should look at it: 1. Bi-directional signalling. A few use-cases (e.g. RISC) have = indicated a need to enable bi-directional flow. While HTTP post is = simple, it would involve managing two separate connections. It may be = possible XMPP-Grid turns out to be logistically simpler? 2. Firewall issues (e.g. cloud-to-enterprise). XMPP could be a good way = to avoid needing =E2=80=9Cpolling=E2=80=9D solutions such as HTTP GET = when it is inconvenient to open access for an HTTP POST. This may be of = great interest to the SCIM Synchronization work that some are = considering. 3. Fan-out distribution: It could potentially handle publishing to = multiple receivers simultaneously. This is particularly useful in cases = where multiple data centers or server clusters need to receive the = events. For example, in OpenID Connect logout, the ability to notify = all members of a Single-sign-on audience for ID Tokens. 4. It supports multiple data formats (e.g. not just JWTs) 5. There is a control-plane in XMPP-grid that may also prove useful for = some or all of our requirements. 6. While it seems more complex, it can provide simplification overall. = Thought over-kill for one-way pub-sub, XMPP-Grid might be more of a = universal solution for all cases. Recalling Kathleen=E2=80=99s comments = about TAXII, this could be one way to avoid connection-itus and = brokering. While this may seem like a very positive review on my part, I do suspect = that many will find this over-kill.=20 ACTION REQUESTED: I=E2=80=99d like to get a feel from the Sec Events community about this = idea. Would you like to see this idea explored further on the list? A. Does this look like something we should consider? What additional = capabilities do you see XMPP Grid bringing? B. If you see this as unnecessary, what would be your concerns? ps. I=E2=80=99m working on the other action items and hope to post a new = SEC Token draft early next week. Thanks for a great kick-off meeting! Phil @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_AFAC2864-6AB2-4922-B18C-F84832CF6BA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Note: cross-posted to IdEvents, SCIM, and = OpenID RISC mailing lists.

At = the end of the Sec Events meeting, Nancy Cam-Winget mentioned the = XMPP-Grid draft which is about to go WGLC. See:
  https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/=

I have taken = a look and my initial impression is we should look at it:

1. Bi-directional = signalling.  A few use-cases (e.g. RISC) have indicated a need to = enable bi-directional flow. While HTTP post is simple, it would involve = managing two separate connections. It may be possible XMPP-Grid turns = out to be logistically simpler?

2. Firewall issues (e.g. = cloud-to-enterprise). XMPP could be a good way to avoid needing = =E2=80=9Cpolling=E2=80=9D solutions such as HTTP GET when it is = inconvenient to open access for an HTTP POST.  This may be of great = interest to the SCIM Synchronization work that some are = considering.

3. = Fan-out distribution: It could potentially handle publishing to multiple = receivers simultaneously. This is particularly useful in cases where = multiple data centers or server clusters need to receive the events. =  For example, in OpenID Connect logout, the ability to notify all = members of a Single-sign-on audience for ID Tokens.

4. It supports multiple = data formats (e.g. not just JWTs)

5. There is a control-plane in = XMPP-grid that may also prove useful for some or all of our = requirements.

6.= While it seems more complex, it can provide simplification overall. = Thought over-kill for one-way pub-sub, XMPP-Grid might be more of a = universal solution for all cases. Recalling Kathleen=E2=80=99s comments = about TAXII, this could be one way to avoid connection-itus and = brokering.

While= this may seem like a very positive review on my part, I do suspect that = many will find this over-kill. 

ACTION REQUESTED:
I=E2=80=99d like to get a feel from the Sec Events community = about this idea. Would you like to see this idea explored further on the = list?

A. =  Does this look like something we should consider?  What = additional capabilities do you see XMPP Grid bringing?

B.  If you see this = as unnecessary, what would be your concerns?

ps. I=E2=80=99m working on the other = action items and hope to post a new SEC Token draft early next = week.

Thanks = for a great kick-off meeting!




= --Apple-Mail=_AFAC2864-6AB2-4922-B18C-F84832CF6BA7-- From nobody Sun Nov 20 14:00:56 2016 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 62F3D1294C2 for ; Sun, 20 Nov 2016 14:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY4MvslIUX7u for ; Sun, 20 Nov 2016 14:00:52 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50B3128874 for ; Sun, 20 Nov 2016 14:00:51 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id t79so115343949wmt.0 for ; Sun, 20 Nov 2016 14:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=fpWSA93klp+Bxo/vpDy+thuMlRIpI/WhLt7O5yIrOUY=; b=mEbHnhBN9BnLX4heepEIhdUq0J+tye5/3zPWDo2jHWaNuMzSd9UUM+mUcTrzkjxOA6 q1Y1aHi9igusHTnoGwmti5Q3mXZUT87VZVlSSfeQmOT77RN/FXZZqdplaetlHTm8aqip 8NFFCumyXr5PzFD2PTkovWT/s+/HAnyT51MCW3xJ/Z1KwfkX/fo4OeEWfo8lwLGQVDA3 QNa4TUTwx3+DrLHnS/a6V4I1EWVTuCgZqJgQ9hHP9GoRfEVvz//7orxZVJQbyEI2gh6R /D6HU1VP6yvAYKENfjnWvLeob50b4AXud0dkSPk5OehH0ixsVErUHPI7jnWev+AiJx45 cIDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fpWSA93klp+Bxo/vpDy+thuMlRIpI/WhLt7O5yIrOUY=; b=EjmmhQATW5IVdBiIwUC3PaIeqwLhfvzgSgtdkk5q2WRJQXUkqISPh+FAoDrlgieHbH i0eoKJqGqQDqN2gvPAJixdD36Ta5vKmO47JEkSgubPWOh+SAtda4GE9184rJu0OtwvC/ X17hoObSACGJ9gxZ2M8aKWEG3e5bzj5PKlPMla5FfPqWXyOxWyt1ZN/9CXseR+c1oVi0 0KiCQ7lK0ghPCGZ3+y9znNnRDOOiv3ouFpzroqwRLz8+4E1mJgNqeoqfRpMyTQxZBMg0 2cgKwB5O9Qch3S4NurKcD2Iu3i9LsoQ+LJNWz+uHNgmSurbZlk8qgV2VErJaCFHY8X4N leDw== X-Gm-Message-State: AKaTC00HPeN5fUEztynlru5WN6MwGfUPVqyOmKe08ZiqjXUVRyGcjVIBHg7JOYqv2EEc5A== X-Received: by 10.46.77.92 with SMTP id a89mr6139454ljb.28.1479679250364; Sun, 20 Nov 2016 14:00:50 -0800 (PST) Received: from [10.0.0.101] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by smtp.gmail.com with ESMTPSA id g84sm4769843ljg.31.2016.11.20.14.00.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Nov 2016 14:00:47 -0800 (PST) To: scim@ietf.org, id-event@ietf.org References: <8CCC780F-E02B-4BC7-B4EF-7743F088FD05@oracle.com> From: Leif Johansson Message-ID: <5e3bb755-515f-e632-9252-36b6823f0762@mnt.se> Date: Sun, 20 Nov 2016 23:00:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8CCC780F-E02B-4BC7-B4EF-7743F088FD05@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [scim] Follow-up from IETF97 - XMPP Grid X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 22:00:54 -0000 On 2016-11-18 07:25, Phil Hunt wrote: > Note: cross-posted to IdEvents, SCIM, and OpenID RISC mailing lists. > > At the end of the Sec Events meeting, Nancy Cam-Winget mentioned the > XMPP-Grid draft which is about to go WGLC. See: > https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ > > I have taken a look and my initial impression is we should look at it: > > 1. Bi-directional signalling. A few use-cases (e.g. RISC) have > indicated a need to enable bi-directional flow. While HTTP post is > simple, it would involve managing two separate connections. It may be > possible XMPP-Grid turns out to be logistically simpler? > > 2. Firewall issues (e.g. cloud-to-enterprise). XMPP could be a good way > to avoid needing “polling” solutions such as HTTP GET when it is > inconvenient to open access for an HTTP POST. This may be of great > interest to the SCIM Synchronization work that some are considering. > > 3. Fan-out distribution: It could potentially handle publishing to > multiple receivers simultaneously. This is particularly useful in cases > where multiple data centers or server clusters need to receive the > events. For example, in OpenID Connect logout, the ability to notify > all members of a Single-sign-on audience for ID Tokens. > > 4. It supports multiple data formats (e.g. not just JWTs) > > 5. There is a control-plane in XMPP-grid that may also prove useful for > some or all of our requirements. > > 6. While it seems more complex, it can provide simplification overall. > Thought over-kill for one-way pub-sub, XMPP-Grid might be more of a > universal solution for all cases. Recalling Kathleen’s comments about > TAXII, this could be one way to avoid connection-itus and brokering. > > While this may seem like a very positive review on my part, I do suspect > that many will find this over-kill. > > ACTION REQUESTED: > I’d like to get a feel from the Sec Events community about this idea. > Would you like to see this idea explored further on the list? > > A. Does this look like something we should consider? What additional > capabilities do you see XMPP Grid bringing? > > B. If you see this as unnecessary, what would be your concerns? > > ps. I’m working on the other action items and hope to post a new SEC > Token draft early next week. > > Thanks for a great kick-off meeting! > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > In an earlier life (about 10 years ago) I built and deployed (what is now called) "chat ops" based on XMPP pubsub - very similar in requirements to what we're talking about here. XMPP is quite nice once you get it deployed but building and maintaining scalable xmpp pubsub infrastructure can be a bit more than many organizations is able to deal with. I guess that part will be up to Dick :-) Cheers Leif