From nobody Wed Aug 9 07:02:06 2017 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 798001321D2 for ; Wed, 9 Aug 2017 07:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VFxQLYWynb3w for ; Wed, 9 Aug 2017 07:02:02 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 D4A6A132360 for ; Wed, 9 Aug 2017 07:01:43 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id q25so28866478uah.1 for ; Wed, 09 Aug 2017 07:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sm+xzpaGbGt+56ZgchYbKtjQycRwuVdStAno/nhsN6g=; b=sgsOvKfWnanW9XzREwNCeVeZgCAXchPos4xiWtek41iwxGrb7ZUufpoguayABfd0hM bWv2K+TApLFihBxXh8ZYNXNDChD+jVj/+q7NzupgFMApvZnircMXRdyonW8L4LwZ/H78 QJOc++Lr94toHtfpzJfNYu1FMKWFPm3DvAhi9bzx3F92yLoCsEKPKcITdVEITHsQFpI0 dmaAJGzPiySdPL+h6fo2o0PfdD8V7FMJWkpN74CIJ5H+Y8WZnWPp3BEdHxoVykPfjtjp Brx0n41dHrVmJp20hCm/8Cy2NwUBHhSYRyON7es6rDMop0eN7NP+uQ7CkBb+RGk63xx4 L1CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sm+xzpaGbGt+56ZgchYbKtjQycRwuVdStAno/nhsN6g=; b=EkznxTPwigKuhM3sQLdGUJw1r2vZ4relCTDbVZ+BG0ct5arXW/MZsJvrL8IFOrvxTV CLKKwFfLYBlxlDO2MkNUL0Ngy2h6taNMa0a6OaRCb2GRuxahyksftrnKLxRM1Ual1hDS V/FwNsB53F0+xncSfLe1roUU/uyh8m6zP6vX2jgbHu5sBxrazNoAnTeBV5zv9ddP43Qk CWzupPpk5m0KQxC/VRP8ZMeFA1z+M6woG4bayfh0g4EvfmhjhxkdaIJQheNGRR/sXOul nCwaga6UuF7YzNtS0h8quRlHJ4fBNGWaUtk9ZMSG/1Y590fAaTfEyV7EutEwmgsy8+qT +EHw== X-Gm-Message-State: AHYfb5iXqm+rIfLQ/ugjxBI0pRr0FvBCLfV2zxZ1QVr7frUv8DM2nxjz HMOfCEVN3rmVClhUZfNoyo93UNvoOQ== X-Received: by 10.176.88.66 with SMTP id p2mr5938346uac.181.1502287302804; Wed, 09 Aug 2017 07:01:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.197.135 with HTTP; Wed, 9 Aug 2017 07:01:42 -0700 (PDT) In-Reply-To: References: <56C3C758F9D6534CA3778EAA1E0C343753AB2F38@BLUPRD0412MB643.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343753AC4630@BLUPRD0412MB643.namprd04.prod.outlook.com> From: Shelley Date: Wed, 9 Aug 2017 09:01:42 -0500 Message-ID: To: Kelly Grizzle Cc: "scim@ietf.org" Content-Type: multipart/alternative; boundary="f403045f38f208c842055652856a" Archived-At: Subject: Re: [scim] Groups Member Type X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 14:02:04 -0000 --f403045f38f208c842055652856a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *Resurrecting this old thread, as this question has recently come up during some of our interoperability testing, and there still appears to be some ambiguity in the spec...* The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected behavior if the type sub-attribute is not provided on a Group resource member. Neither spec seems to explicitly require this attribute, so what is the expected behavior if no type is provided? Is there a default (e.g. "Use= r" or "Group"), must Service Providers search for the member across *all *reso= urce types, or should it be treated as REQUIRED (e.g. returning a 400 error)? On Mon, Feb 25, 2013 at 10:38 AM, Shelley wrote: > Thanks, Kelly. Given that the ID may represent either a User or Group and > only the combination of "type" and "value" uniquely identify the referenc= e, > should the canonical "type" attribute for group members be REQUIRED as > well? (Further, the majority of examples throughout the Protocol > specification only include a "value" and not "type", so it's ambiguous as > to whether these "values" represent Users or Groups.) > > > > On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle < > kelly.grizzle@sailpoint.com> wrote: > >> I opened ticket #35 to change this. >> >> >> >> http://trac.tools.ietf.org/wg/scim/trac/ticket/35 >> >> >> >> --Kelly >> >> >> >> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf >> Of *Shelley >> *Sent:* Monday, February 11, 2013 11:36 AM >> *To:* Kelly Grizzle >> *Cc:* scim@ietf.org >> *Subject:* Re: [scim] Groups Member Type >> >> >> >> +1 to mark it as "immutable". >> >> On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle < >> kelly.grizzle@sailpoint.com> wrote: >> >> Good point. It seems like this should say =E2=80=9Cimmutable=E2=80=9D r= ather than >> =E2=80=9Cread-only=E2=80=9D, since it can be set initially but not updat= ed. Thoughts from >> anyone else? If this seems reasonable I=E2=80=99ll open an issue to get= this fixed. >> >> >> >> --Kelly >> >> >> >> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf >> Of *Shelley >> *Sent:* Friday, February 01, 2013 1:37 PM >> *To:* scim@ietf.org >> *Subject:* [scim] Groups Member Type >> >> >> >> As indicated in Section 8, the canonical types for Group members are >> READ-ONLY. As such, how can consumers provide the type (i.e. "User" or >> "Group")? Is it implied that IDs are unique across both users and groups= in >> order for service providers to fulfill this requirement? >> >> >> > > --f403045f38f208c842055652856a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Resurrecting this old thread, as this question has rece= ntly come up during some of our interoperability testing, and there still a= ppears to be some ambiguity in the spec...

The SCIM 1.1 and= 2.0 specifications do not seem to indicate the expected behavior if the type sub-attribute is = not provided on a Group resource member.= Neither spec seems to explicitly require this attribute, so what is the ex= pected behavior if no type<= /span> is provided? Is there a default (e.g. "User" or "Group"), must Service Providers search = for the member across all resource types, or should it be treated as= REQUIRED (e.g. returning a 400 error)?

On Mon, Feb 25, 2013 at 10:38 AM, Shelley <randomshelley@gmail.com> wrote:
Thanks, Kelly. Given that the ID may represent either a User or Gr= oup and only the combination of "type" and "value" uniq= uely identify the reference, should the canonical "type" attribut= e for group members be REQUIRED as well? (Further, the majority of examples= throughout the Protocol specification only include a "value" and= not "type", so it's ambiguous as to whether these "valu= es" represent Users or Groups.)



On Mon, Feb 11, 2013 at 4:02 PM, Kelly G= rizzle <kelly.grizzle@sailpoint.com> wrote:

I opened ticket #35 to ch= ange this.

=C2=A0

http://trac.tools.ie= tf.org/wg/scim/trac/ticket/35

=C2=A0

--Kelly

=C2=A0

From: scim-bounces@ietf.org [mailto:scim-= bounces@ietf.org] On Behalf Of Shelley
Sent: Monday, February 11, 2013 11:36 AM
To: Kelly Grizzle
Cc: scim@ietf.org=
Subject: Re: [scim] Groups Member Type

=

=C2=A0

+1 to mark it as &quo= t;immutable".

On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle <kelly.grizzl= e@sailpoint.com> wrote:

Good point.=C2=A0 It seem= s like this should say =E2=80=9Cimmutable=E2=80=9D rather than =E2=80=9Crea= d-only=E2=80=9D, since it can be set initially but not updated.=C2=A0 Thoughts from anyone else?=C2=A0 If this = seems reasonable I=E2=80=99ll open an issue to get this fixed.

=C2=A0

--Kelly<= /u>

=C2=A0

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Shelley
Sent: Friday, February 01, 2013 1:37 PM
To: scim@ietf.org=
Subject: [scim] Groups Member Type

=C2=A0

As indicated in Section 8, the canonical types for G= roup members are READ-ONLY. As such, how can consumers provide the type (i.= e. "User" or "Group")? Is it implied that IDs are unique across both users and groups in order for service providers to fulf= ill this requirement?

=C2=A0



--f403045f38f208c842055652856a-- From nobody Wed Aug 9 08:32:19 2017 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 665571323BF for ; Wed, 9 Aug 2017 08:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sailpoint.onmicrosoft.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 OeU_weiwfzPs for ; Wed, 9 Aug 2017 08:32:15 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0093.outbound.protection.outlook.com [104.47.34.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817881323BC for ; Wed, 9 Aug 2017 08:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sailpoint.onmicrosoft.com; s=selector1-sailpoint-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QWvCdJiRYw50VHxpXlUQz1TRsthhMIG+oGuFFh1TisM=; b=CZcCwIb0MoI8LRfE0X+iTxYIomXVzQHa+3KOJRpUa14iBD9weZCDbtfuqJA7zPsWnAf+8XJFtQ4QY5DU7L0Q9Da21kf/B4OO4hHMG78xJlh5ynya/V6LDrSCDvePmfQhiZllbFM+4OizlzrE/Bn1L8T8al8aeqK0ujgJ3CFNGk8= Received: from CY1PR04MB2363.namprd04.prod.outlook.com (10.167.10.143) by CY1PR04MB2363.namprd04.prod.outlook.com (10.167.10.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Wed, 9 Aug 2017 15:32:14 +0000 Received: from CY1PR04MB2363.namprd04.prod.outlook.com ([10.167.10.143]) by CY1PR04MB2363.namprd04.prod.outlook.com ([10.167.10.143]) with mapi id 15.01.1320.018; Wed, 9 Aug 2017 15:32:14 +0000 From: Kelly Grizzle To: Shelley CC: "scim@ietf.org" Thread-Topic: [scim] Groups Member Type Thread-Index: AQHOALOOeHp6hjJutkGc7C2Tyxq6nZhpv6cAgAs7UQCAAEp64IAVpkqAiftC6wCAABjZ4A== Date: Wed, 9 Aug 2017 15:32:13 +0000 Message-ID: References: <56C3C758F9D6534CA3778EAA1E0C343753AB2F38@BLUPRD0412MB643.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343753AC4630@BLUPRD0412MB643.namprd04.prod.outlook.com> In-Reply-To: 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=kelly.grizzle@sailpoint.com; x-originating-ip: [70.114.154.180] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR04MB2363; 6:oLKNJqddzu9O90o/RNeFVtP2HD7Ace87i85/TqeFlDhVrYvqemgek0v/XYCmjK3ACo/mjcQcnrDjkexDdMBwlbbZzha0vEuU7JMIKrhuAGzDfhRn0sl3go0Esm1l5XwZXfWrys+tZsFS6WaaVyEEARDuxDeHyn62cfXIb/AasBL/N68sVGUSBWuGwZ5nHNrU8tYXp6dXety9ZwzKyBTp0XfGdixt6EcSAiWkE+dWCjfDCoISsBQgenq0l31NPJkX5HsHwItizX0XScoljUEmq+gP7skNcSZFJu0wNw71Iv4p8aFHPcR9eCwiHsyurOhXUyEDIrEeJ30PAqz3hqEVuw==; 5:14ay7Ovop1+mjVJF+bPXsiBG6tWgGJSw5DJ80ZqeuL9gJXBHKs7uASNGtsBrbhNcbu9VbKOyDklujakZB/lPI42IhIXBFamJyTSnXI/ykdWQMm/gRikRkl3qBu6N2vi6rChFGkRRL//G9d8pJNg+UQ==; 24:D5abJ446Xys4Fw9vJfR9ha6mEVSDG+VNd9lhxo0G8GcLwwgj65aHfgKMXJvIDEY4pGNL5r9bc3K0KdXSyWlEFJWZomkqNz8MJu3VPvGyi04=; 7:F8QC5IuUHL2K9TSCW52OOpZ3IR8986VTio8dpMTqrtSDGOpc7w4LLvmNw/HR7bpaFaMRrBM88CPfh/veXlj7q1nDVpOn+KTLgqZuWyuGsEO4cRJCz4UqfBHzoXW32cYV+TbftD0+iLgulotZIl3ILYkEmtO3aRNXPwJ6MMqJUP/gYJEkBDEG9/CsHBZj9KSO0d35vrCjiUrXFHslIklw2boRV2PhSL34SuNewN1DLXM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 00344cb1-05ec-46f6-ff67-08d4df3bcf5c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR04MB2363; x-ms-traffictypediagnostic: CY1PR04MB2363: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR04MB2363; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR04MB2363; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39450400003)(39840400002)(24454002)(189002)(377454003)(199003)(2900100001)(6436002)(86362001)(14454004)(3280700002)(3660700001)(8676002)(68736007)(93886004)(50986999)(76176999)(81156014)(54356999)(66066001)(81166006)(6306002)(19609705001)(6246003)(236005)(6506006)(229853002)(54896002)(53936002)(6916009)(2950100002)(38730400002)(39060400002)(9686003)(25786009)(77096006)(110136004)(4326008)(966005)(99286003)(55016002)(478600001)(6116002)(74316002)(106356001)(102836003)(7696004)(3846002)(606006)(790700001)(2906002)(5660300001)(8936002)(7736002)(105586002)(101416001)(53546010)(189998001)(1411001)(97736004)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR04MB2363; H:CY1PR04MB2363.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sailpoint.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR04MB2363D61AB4E1F0C5843904F5E28B0CY1PR04MB2363namp_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2017 15:32:14.0187 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR04MB2363 Archived-At: Subject: Re: [scim] Groups Member Type X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 15:32:18 -0000 --_000_CY1PR04MB2363D61AB4E1F0C5843904F5E28B0CY1PR04MB2363namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R2l2ZW4gdGhlIGdlbmVyYWwgZGVzaXJlIGZvciBTQ0lNIHRvIGFsbG93IGxvb3NlIHJlYWRpbmcg YnV0IHN0cmljdCB3cml0aW5nLCBJIHdvdWxkIHZvdGUgZm9yIG9wdGlvbiAxLiAgSWYgdHlwZSBp cyBub3Qgc3BlY2lmaWVkIGluIGEgUFVUL1BPU1QvUEFUQ0ggdGhlbiB0aGUgc2VydmVyIGNhbiBh c3N1bWUg4oCcVXNlcuKAnS4NCg0KLS1LZWxseQ0KDQpGcm9tOiBTaGVsbGV5IFttYWlsdG86cmFu ZG9tc2hlbGxleUBnbWFpbC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCA5LCAyMDE3IDk6 MDIgQU0NClRvOiBLZWxseSBHcml6emxlIDxrZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20+DQpD Yzogc2NpbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzY2ltXSBHcm91cHMgTWVtYmVyIFR5cGUN Cg0KUmVzdXJyZWN0aW5nIHRoaXMgb2xkIHRocmVhZCwgYXMgdGhpcyBxdWVzdGlvbiBoYXMgcmVj ZW50bHkgY29tZSB1cCBkdXJpbmcgc29tZSBvZiBvdXIgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5n LCBhbmQgdGhlcmUgc3RpbGwgYXBwZWFycyB0byBiZSBzb21lIGFtYmlndWl0eSBpbiB0aGUgc3Bl Yy4uLg0KDQpUaGUgU0NJTSAxLjEgYW5kIDIuMCBzcGVjaWZpY2F0aW9ucyBkbyBub3Qgc2VlbSB0 byBpbmRpY2F0ZSB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgaWYgdGhlIHR5cGUgc3ViLWF0dHJpYnV0 ZSBpcyBub3QgcHJvdmlkZWQgb24gYSBHcm91cCByZXNvdXJjZSBtZW1iZXIuIE5laXRoZXIgc3Bl YyBzZWVtcyB0byBleHBsaWNpdGx5IHJlcXVpcmUgdGhpcyBhdHRyaWJ1dGUsIHNvIHdoYXQgaXMg dGhlIGV4cGVjdGVkIGJlaGF2aW9yIGlmIG5vIHR5cGUgaXMgcHJvdmlkZWQ/IElzIHRoZXJlIGEg ZGVmYXVsdCAoZS5nLiAiVXNlciIgb3IgIkdyb3VwIiksIG11c3QgU2VydmljZSBQcm92aWRlcnMg c2VhcmNoIGZvciB0aGUgbWVtYmVyIGFjcm9zcyBhbGwgcmVzb3VyY2UgdHlwZXMsIG9yIHNob3Vs ZCBpdCBiZSB0cmVhdGVkIGFzIFJFUVVJUkVEIChlLmcuIHJldHVybmluZyBhIDQwMCBlcnJvcik/ DQoNCg0KT24gTW9uLCBGZWIgMjUsIDIwMTMgYXQgMTA6MzggQU0sIFNoZWxsZXkgPHJhbmRvbXNo ZWxsZXlAZ21haWwuY29tPG1haWx0bzpyYW5kb21zaGVsbGV5QGdtYWlsLmNvbT4+IHdyb3RlOg0K VGhhbmtzLCBLZWxseS4gR2l2ZW4gdGhhdCB0aGUgSUQgbWF5IHJlcHJlc2VudCBlaXRoZXIgYSBV c2VyIG9yIEdyb3VwIGFuZCBvbmx5IHRoZSBjb21iaW5hdGlvbiBvZiAidHlwZSIgYW5kICJ2YWx1 ZSIgdW5pcXVlbHkgaWRlbnRpZnkgdGhlIHJlZmVyZW5jZSwgc2hvdWxkIHRoZSBjYW5vbmljYWwg InR5cGUiIGF0dHJpYnV0ZSBmb3IgZ3JvdXAgbWVtYmVycyBiZSBSRVFVSVJFRCBhcyB3ZWxsPyAo RnVydGhlciwgdGhlIG1ham9yaXR5IG9mIGV4YW1wbGVzIHRocm91Z2hvdXQgdGhlIFByb3RvY29s IHNwZWNpZmljYXRpb24gb25seSBpbmNsdWRlIGEgInZhbHVlIiBhbmQgbm90ICJ0eXBlIiwgc28g aXQncyBhbWJpZ3VvdXMgYXMgdG8gd2hldGhlciB0aGVzZSAidmFsdWVzIiByZXByZXNlbnQgVXNl cnMgb3IgR3JvdXBzLikNCg0KDQpPbiBNb24sIEZlYiAxMSwgMjAxMyBhdCA0OjAyIFBNLCBLZWxs eSBHcml6emxlIDxrZWxseS5ncml6emxlQHNhaWxwb2ludC5jb208bWFpbHRvOmtlbGx5LmdyaXp6 bGVAc2FpbHBvaW50LmNvbT4+IHdyb3RlOg0KSSBvcGVuZWQgdGlja2V0ICMzNSB0byBjaGFuZ2Ug dGhpcy4NCg0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvc2NpbS90cmFjL3RpY2tldC8z NQ0KDQotLUtlbGx5DQoNCkZyb206IHNjaW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2NpbS1i b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2Np bS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFNoZWxsZXkNClNlbnQ6IE1vbmRheSwg RmVicnVhcnkgMTEsIDIwMTMgMTE6MzYgQU0NClRvOiBLZWxseSBHcml6emxlDQpDYzogc2NpbUBp ZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2NpbV0gR3JvdXBz IE1lbWJlciBUeXBlDQoNCisxIHRvIG1hcmsgaXQgYXMgImltbXV0YWJsZSIuDQpPbiBNb24sIEZl YiA0LCAyMDEzIGF0IDg6MDggQU0sIEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6bGVAc2FpbHBv aW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPj4gd3JvdGU6DQpHb29k IHBvaW50LiAgSXQgc2VlbXMgbGlrZSB0aGlzIHNob3VsZCBzYXkg4oCcaW1tdXRhYmxl4oCdIHJh dGhlciB0aGFuIOKAnHJlYWQtb25seeKAnSwgc2luY2UgaXQgY2FuIGJlIHNldCBpbml0aWFsbHkg YnV0IG5vdCB1cGRhdGVkLiAgVGhvdWdodHMgZnJvbSBhbnlvbmUgZWxzZT8gIElmIHRoaXMgc2Vl bXMgcmVhc29uYWJsZSBJ4oCZbGwgb3BlbiBhbiBpc3N1ZSB0byBnZXQgdGhpcyBmaXhlZC4NCg0K LS1LZWxseQ0KDQpGcm9tOiBzY2ltLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNjaW0tYm91bmNl c0BpZXRmLm9yZz4gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNjaW0tYm91 bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBTaGVsbGV5DQpTZW50OiBGcmlkYXksIEZlYnJ1 YXJ5IDAxLCAyMDEzIDE6MzcgUE0NClRvOiBzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYu b3JnPg0KU3ViamVjdDogW3NjaW1dIEdyb3VwcyBNZW1iZXIgVHlwZQ0KDQpBcyBpbmRpY2F0ZWQg aW4gU2VjdGlvbiA4LCB0aGUgY2Fub25pY2FsIHR5cGVzIGZvciBHcm91cCBtZW1iZXJzIGFyZSBS RUFELU9OTFkuIEFzIHN1Y2gsIGhvdyBjYW4gY29uc3VtZXJzIHByb3ZpZGUgdGhlIHR5cGUgKGku ZS4gIlVzZXIiIG9yICJHcm91cCIpPyBJcyBpdCBpbXBsaWVkIHRoYXQgSURzIGFyZSB1bmlxdWUg YWNyb3NzIGJvdGggdXNlcnMgYW5kIGdyb3VwcyBpbiBvcmRlciBmb3Igc2VydmljZSBwcm92aWRl cnMgdG8gZnVsZmlsbCB0aGlzIHJlcXVpcmVtZW50Pw0KDQoNCg0K --_000_CY1PR04MB2363D61AB4E1F0C5843904F5E28B0CY1PR04MB2363namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5HaXZlbiB0aGUgZ2VuZXJhbCBkZXNpcmUgZm9yIFNDSU0gdG8gYWxsb3cgbG9v c2UgcmVhZGluZyBidXQgc3RyaWN0IHdyaXRpbmcsIEkgd291bGQgdm90ZSBmb3Igb3B0aW9uIDEu Jm5ic3A7IElmIHR5cGUgaXMgbm90IHNwZWNpZmllZCBpbiBhIFBVVC9QT1NUL1BBVENIIHRoZW4g dGhlIHNlcnZlciBjYW4gYXNzdW1lIOKAnFVzZXLigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tS2VsbHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFNoZWxsZXkgW21h aWx0bzpyYW5kb21zaGVsbGV5QGdtYWlsLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgQXVndXN0IDksIDIwMTcgOTowMiBBTTxicj4NCjxiPlRvOjwvYj4gS2VsbHkgR3JpenpsZSAm bHQ7a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gc2NpbUBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NjaW1dIEdyb3VwcyBNZW1iZXIgVHlw ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+UmVzdXJyZWN0aW5nIHRoaXMgb2xk IHRocmVhZCwgYXMgdGhpcyBxdWVzdGlvbiBoYXMgcmVjZW50bHkgY29tZSB1cCBkdXJpbmcgc29t ZSBvZiBvdXIgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5nLCBhbmQgdGhlcmUgc3RpbGwgYXBwZWFy cyB0byBiZSBzb21lIGFtYmlndWl0eSBpbiB0aGUgc3BlYy4uLjwvaT48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGUgU0NJTSAxLjEgYW5kIDIuMCBz cGVjaWZpY2F0aW9ucyBkbyBub3Qgc2VlbSB0byBpbmRpY2F0ZSB0aGUgZXhwZWN0ZWQgYmVoYXZp b3IgaWYgdGhlDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPnR5cGU8L3NwYW4+IHN1Yi1hdHRyaWJ1dGUgaXMgbm90IHByb3ZpZGVkIG9uIGENCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+R3JvdXA8L3NwYW4+ IHJlc291cmNlIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+DQptZW1iZXI8L3NwYW4+LiBOZWl0aGVyIHNwZWMgc2VlbXMgdG8gZXhwbGljaXRseSByZXF1 aXJlIHRoaXMgYXR0cmlidXRlLCBzbyB3aGF0IGlzIHRoZSBleHBlY3RlZCBiZWhhdmlvciBpZiBu bw0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij50eXBl PC9zcGFuPiBpcyBwcm92aWRlZD8gSXMgdGhlcmUgYSBkZWZhdWx0IChlLmcuICZxdW90OzxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VXNlcjwvc3Bhbj4m cXVvdDsgb3IgJnF1b3Q7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5Hcm91cDwvc3Bhbj4mcXVvdDspLCBtdXN0IFNlcnZpY2UgUHJvdmlkZXJzIHNlYXJj aCBmb3IgdGhlIG1lbWJlciBhY3Jvc3MNCjxpPmFsbCA8L2k+cmVzb3VyY2UgdHlwZXMsIG9yIHNo b3VsZCBpdCBiZSB0cmVhdGVkIGFzIFJFUVVJUkVEIChlLmcuIHJldHVybmluZyBhIDxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo0MDA8L3NwYW4+IGVy cm9yKT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBNb24sIEZlYiAyNSwgMjAxMyBhdCAxMDozOCBBTSwgU2hlbGxleSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJhbmRvbXNoZWxsZXlAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmFuZG9t c2hlbGxleUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsIEtlbGx5LiBHaXZlbiB0aGF0IHRoZSBJ RCBtYXkgcmVwcmVzZW50IGVpdGhlciBhIFVzZXIgb3IgR3JvdXAgYW5kIG9ubHkgdGhlIGNvbWJp bmF0aW9uIG9mICZxdW90O3R5cGUmcXVvdDsgYW5kICZxdW90O3ZhbHVlJnF1b3Q7IHVuaXF1ZWx5 IGlkZW50aWZ5IHRoZSByZWZlcmVuY2UsIHNob3VsZCB0aGUgY2Fub25pY2FsICZxdW90O3R5cGUm cXVvdDsgYXR0cmlidXRlIGZvciBncm91cCBtZW1iZXJzIGJlIFJFUVVJUkVEIGFzIHdlbGw/IChG dXJ0aGVyLA0KIHRoZSBtYWpvcml0eSBvZiBleGFtcGxlcyB0aHJvdWdob3V0IHRoZSBQcm90b2Nv bCBzcGVjaWZpY2F0aW9uIG9ubHkgaW5jbHVkZSBhICZxdW90O3ZhbHVlJnF1b3Q7IGFuZCBub3Qg JnF1b3Q7dHlwZSZxdW90Oywgc28gaXQncyBhbWJpZ3VvdXMgYXMgdG8gd2hldGhlciB0aGVzZSAm cXVvdDt2YWx1ZXMmcXVvdDsgcmVwcmVzZW50IFVzZXJzIG9yIEdyb3Vwcy4pPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gTW9uLCBGZWIgMTEsIDIwMTMgYXQgNDowMiBQTSwgS2VsbHkgR3Jpenps ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBvcGVuZWQgdGlja2V0ICMzNSB0byBj aGFuZ2UgdGhpcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48YSBo cmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9zY2ltL3RyYWMvdGlja2V0LzM1IiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvc2NpbS90cmFjL3Rp Y2tldC8zNTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tLUtl bGx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oyxz YW5zLXNlcmlmIj4NCjxhIGhyZWY9Im1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zY2ltLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW0tYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlNoZWxsZXk8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBGZWJydWFyeSAxMSwgMjAxMyAxMTozNiBBTTxicj4NCjxiPlRvOjwvYj4gS2Vs bHkgR3JpenpsZTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5zY2ltQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3NjaW1dIEdyb3VwcyBNZW1iZXIgVHlwZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+JiM0MzsxIHRvIG1hcmsgaXQgYXMgJnF1b3Q7aW1tdXRhYmxlJnF1b3Q7 LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBG ZWIgNCwgMjAxMyBhdCA4OjA4IEFNLCBLZWxseSBHcml6emxlICZsdDs8YSBocmVmPSJtYWlsdG86 a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2VsbHkuZ3Jpenps ZUBzYWlscG9pbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkdv b2QgcG9pbnQuJm5ic3A7IEl0IHNlZW1zIGxpa2UgdGhpcyBzaG91bGQgc2F5IOKAnGltbXV0YWJs ZeKAnSByYXRoZXIgdGhhbiDigJxyZWFkLW9ubHnigJ0sIHNpbmNlIGl0IGNhbiBiZSBzZXQgaW5p dGlhbGx5IGJ1dCBub3QgdXBkYXRlZC4mbmJzcDsgVGhvdWdodHMgZnJvbSBhbnlvbmUNCiBlbHNl PyZuYnNwOyBJZiB0aGlzIHNlZW1zIHJlYXNvbmFibGUgSeKAmWxsIG9wZW4gYW4gaXNzdWUgdG8g Z2V0IHRoaXMgZml4ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ LS1LZWxseTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssc2Fucy1zZXJpZiI+DQo8YSBocmVmPSJtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TaGVsbGV5PGJyPg0KPGI+U2Vu dDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMDEsIDIwMTMgMTozNyBQTTxicj4NCjxiPlRvOjwvYj4g PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc2NpbV0gR3JvdXBzIE1lbWJlciBUeXBlPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIGluZGljYXRlZCBpbiBT ZWN0aW9uIDgsIHRoZSBjYW5vbmljYWwgdHlwZXMgZm9yIEdyb3VwIG1lbWJlcnMgYXJlIFJFQUQt T05MWS4gQXMgc3VjaCwgaG93IGNhbiBjb25zdW1lcnMgcHJvdmlkZSB0aGUgdHlwZSAoaS5lLiAm cXVvdDtVc2VyJnF1b3Q7IG9yICZxdW90O0dyb3VwJnF1b3Q7KT8gSXMgaXQgaW1wbGllZCB0aGF0 IElEcyBhcmUNCiB1bmlxdWUgYWNyb3NzIGJvdGggdXNlcnMgYW5kIGdyb3VwcyBpbiBvcmRlciBm b3Igc2VydmljZSBwcm92aWRlcnMgdG8gZnVsZmlsbCB0aGlzIHJlcXVpcmVtZW50PzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR04MB2363D61AB4E1F0C5843904F5E28B0CY1PR04MB2363namp_-- From nobody Wed Aug 9 09:06:33 2017 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 9DF031323CB for ; Wed, 9 Aug 2017 09:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 BJ4XaManPW2B for ; Wed, 9 Aug 2017 09:06:27 -0700 (PDT) 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 5DFD013240C for ; Wed, 9 Aug 2017 09:06:27 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v79G6OOj007156 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Aug 2017 16:06:25 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v79G6Nwk027268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Aug 2017 16:06:24 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v79G6Mi7006387; Wed, 9 Aug 2017 16:06:23 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Aug 2017 09:06:22 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-4281E78F-46CB-4302-BB98-401C646D28E1 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 9 Aug 2017 09:06:19 -0700 Cc: Shelley , "scim@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <56C3C758F9D6534CA3778EAA1E0C343753AB2F38@BLUPRD0412MB643.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343753AC4630@BLUPRD0412MB643.namprd04.prod.outlook.com> To: Kelly Grizzle X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [scim] Groups Member Type X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 16:06:32 -0000 --Apple-Mail-4281E78F-46CB-4302-BB98-401C646D28E1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree the server can decide.=20 IMO the server should check referential integrity. By doing so it would like= ly know the type. The spec is silent (as far as i recall) on whether it expr= esses it.=20 You can also tell via id which is local and $ref path given's scim's strict p= ath rules (look at the parent of the last segment).=20 =46rom my recollection some of these items were not that important given sci= m was provisioning api for apps - apps implementing server side are free to d= o what they can/want. Now that it is being used as directory, closing some u= nspecified / loose areas might be better for interop IMO.=20 Phil > On Aug 9, 2017, at 8:32 AM, Kelly Grizzle wr= ote: >=20 > Given the general desire for SCIM to allow loose reading but strict writin= g, I would vote for option 1. If type is not specified in a PUT/POST/PATCH t= hen the server can assume =E2=80=9CUser=E2=80=9D. > =20 > --Kelly > =20 > From: Shelley [mailto:randomshelley@gmail.com]=20 > Sent: Wednesday, August 9, 2017 9:02 AM > To: Kelly Grizzle > Cc: scim@ietf.org > Subject: Re: [scim] Groups Member Type > =20 > Resurrecting this old thread, as this question has recently come up during= some of our interoperability testing, and there still appears to be some am= biguity in the spec... >=20 > The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected b= ehavior if the type sub-attribute is not provided on a Group resource member= . Neither spec seems to explicitly require this attribute, so what is the ex= pected behavior if no type is provided? Is there a default (e.g. "User" or "= Group"), must Service Providers search for the member across all resource ty= pes, or should it be treated as REQUIRED (e.g. returning a 400 error)? > =20 > =20 > On Mon, Feb 25, 2013 at 10:38 AM, Shelley wrote:= > Thanks, Kelly. Given that the ID may represent either a User or Group and o= nly the combination of "type" and "value" uniquely identify the reference, s= hould the canonical "type" attribute for group members be REQUIRED as well? (= Further, the majority of examples throughout the Protocol specification only= include a "value" and not "type", so it's ambiguous as to whether these "va= lues" represent Users or Groups.) >=20 >=20 >=20 > On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle wrote: > I opened ticket #35 to change this. > =20 > http://trac.tools.ietf.org/wg/scim/trac/ticket/35 > =20 > --Kelly > =20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Sh= elley > Sent: Monday, February 11, 2013 11:36 AM > To: Kelly Grizzle > Cc: scim@ietf.org > Subject: Re: [scim] Groups Member Type > =20 > +1 to mark it as "immutable". >=20 > On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle wrote: > Good point. It seems like this should say =E2=80=9Cimmutable=E2=80=9D rat= her than =E2=80=9Cread-only=E2=80=9D, since it can be set initially but not u= pdated. Thoughts from anyone else? If this seems reasonable I=E2=80=99ll o= pen an issue to get this fixed. > =20 > --Kelly > =20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Sh= elley > Sent: Friday, February 01, 2013 1:37 PM > To: scim@ietf.org > Subject: [scim] Groups Member Type > =20 > As indicated in Section 8, the canonical types for Group members are READ-= ONLY. As such, how can consumers provide the type (i.e. "User" or "Group")? I= s it implied that IDs are unique across both users and groups in order for s= ervice providers to fulfill this requirement? > =20 > =20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r= =3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DnXj1uLbLovxxCW-VPX0d1geWg= hpaAIZtMXKkPYyACLo&s=3DrCY_ttBwpsTcGVSsZT2hsLHWPXL17cWyIBS5WDT4oDs&e=3D=20 --Apple-Mail-4281E78F-46CB-4302-BB98-401C646D28E1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I agree the server can decide. 

= IMO the server should check referential integrity. By doing so it would like= ly know the type. The spec is silent (as far as i recall) on whether it expr= esses it. 

You can also tell via id which is local and $ref path given= 's scim's strict path rules (look at the parent of the last segment). <= br>
=46rom my recollection some of t= hese items were not that important given scim was provisioning api for apps -= apps implementing server side are free to do what they can/want. Now that i= t is being used as directory, closing some unspecified / loose areas might b= e better for interop IMO. 

Phil=

On Aug 9, 2017, at 8:32 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Given the general desire for SCIM to allow loose read= ing but strict writing, I would vote for option 1.  If type is not spec= ified in a PUT/POST/PATCH then the server can assume =E2=80=9CUser=E2=80=9D.=

 

--Kelly

 

From: Shelley [mailto:randomshelley@gmail.com]
Sent: Wednesday, August 9, 2017 9:02 AM
To: Kelly Grizzle <= kelly.grizzle@sailpoint.com>
Cc: scim@ietf.org
Subject: Re: [scim] Groups Member Type

 

Resurrecting this old thread, as this question has= recently come up during some of our interoperability testing, and there sti= ll appears to be some ambiguity in the spec...


The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected beh= avior if the type sub-attribut= e is not provided on a Group resource member. Neither spec seems to explicitly require this attribute, so w= hat is the expected behavior if no type is provided?= Is there a default (e.g. "User" or "Grou= p"), must Service Providers search for the member across all resource types, or should it be treated as REQUIRED (e.g. returni= ng a 400 error)?

 

 

On Mon, Feb 25, 2013 at 10:38 AM, Shelley <randomshelley@gmail.co= m> wrote:

Thanks, Kelly. Given that the ID may represent either= a User or Group and only the combination of "type" and "value" uniquely ide= ntify the reference, should the canonical "type" attribute for group members= be REQUIRED as well? (Further, the majority of examples throughout the Protocol specification only include= a "value" and not "type", so it's ambiguous as to whether these "values" re= present Users or Groups.)



On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle <kelly.grizzle= @sailpoint.com> wrote:

I opened ticket #35 to change this.

 

http://trac.tools.ietf.org/wg/scim/trac/ticket/35<= o:p>

 

--Kelly

 

From: scim-bounces@ietf= .org [mailto:= scim-bounces@ietf.org] On Behalf Of Shelley
Sent: Monday, February 11, 2013 11:36 AM
To: Kelly Grizzle
Cc: scim@ietf.org<= /a>
Subject: Re: [scim] Groups Member Type

 

+1 to mark it as "immutable".

On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

 

 

 

<= /body>= --Apple-Mail-4281E78F-46CB-4302-BB98-401C646D28E1-- From nobody Wed Aug 9 11:42:02 2017 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 85D9A132457 for ; Wed, 9 Aug 2017 11:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 C-5QRrtPl3fw for ; Wed, 9 Aug 2017 11:41:51 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 BCC0C132452 for ; Wed, 9 Aug 2017 11:41:50 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id k43so32097145uaf.3 for ; Wed, 09 Aug 2017 11:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9ljnu2XAMCM4neVmSaia/PiajxVWkobRpfooa3RzsQc=; b=UXo2NtI7m5Zf5qRN6GYhM8KLY6e1E91LaDb6+LJAkXuOQxXJLQB128KxhM86vBtq0z VzJdGic9DRIi9LmFKRtLmZmociot+Y+ZJ3UKF4Iox+sY8KUf1bBnfro6ps9GGNgZYk3M qL+JDLw156SvvIgvz2NjjWvDpk2zJa9xJhwgeHjVOus8i4iMLDIiDEz184FFRNk5EHsO fQWPrVF/kTB+6RORjy/AahGvUjiJC8LkNLZBirjZGo4vuPdBbRI5EkRXChmcWTS0a7if g6AOV+va4vMPd0YHcHeCr7+YkSiPMWuBaAm9RWsQ3yGm8nZJW+nR2OWbKufuCvVNeMhX JC/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9ljnu2XAMCM4neVmSaia/PiajxVWkobRpfooa3RzsQc=; b=qHOoVpw8ayo6srz+89zqWmtMKA3HwvKc0QPVAA9OCsNOJzW0J2B7R1azEftEzS3E8u Jsm4DxSDIjYzTcEUG62zhLoNT+HDubDoGYmw4Yu90xyPc+MjU7qU2Ocp6N3sd7J396rw i3fl1mArTrRl1PlnyCT2dXHFPMLNIE6/ZNP2FqTmVjTdFt3Esw4fCr9VSF0VDhCGiBbE o/IKVusX4joEbo+OvvUgWhE4wTbH1IaKvJ9A00rznpBOVI7KEFWSfOMNV418byrlGQRa H84HtQaA62wOhTVRlm/p6fdW2HQGEcqNOxkkSc4dN+J5jeNWKn+ChTHRQZzB3o6dC/cm oKyg== X-Gm-Message-State: AHYfb5jkff6FDa4p1+DfMLKWzuZr36kd+KFVsZGZ1Z99ixIXDmOGJpiW p4bPlHG8wr2mt7h/UF0Kh3S6+FeoSw== X-Received: by 10.159.53.36 with SMTP id o33mr6745850uao.95.1502304109808; Wed, 09 Aug 2017 11:41:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.197.135 with HTTP; Wed, 9 Aug 2017 11:41:49 -0700 (PDT) In-Reply-To: References: <56C3C758F9D6534CA3778EAA1E0C343753AB2F38@BLUPRD0412MB643.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343753AC4630@BLUPRD0412MB643.namprd04.prod.outlook.com> From: Shelley Date: Wed, 9 Aug 2017 13:41:49 -0500 Message-ID: To: "Phil Hunt (IDM)" Cc: Kelly Grizzle , "scim@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c03ce80cf51650556566e8d" Archived-At: Subject: Re: [scim] Groups Member Type X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 18:41:56 -0000 --94eb2c03ce80cf51650556566e8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > *You can also tell via id which is local and $ref path given's scim's > strict path rules (look at the parent of the last segment). * > - Is the id now required to be globally unique across all resource types? If not, there is no *guarantee *that an SP can determine the resource type from the id. - The $ref is also optional, so this cannot be consistently used to determine the type. Further, I was under the impression that the $ref is primarily used for SPs to communicate the resource location to consumers= , rather than vice versa (i.e. it's essentially a *read-only* attribute). Here is my tentative plan for our SP implementation for evaluating *group members*: - Treat *value* as *REQUIRED*. While the example SCIM schema does not actually require the group member value sub-attribute, this is the most consistent identifier for referring to members. - Treat *$ref* as *READ-ONLY* (i.e. ignore it completely when processing requests). Using a $ref provided by consumers seems a bit fragile (aside from eliminating the complexity of URI comparison, it's possible that a single resource may have multiple DNS names, which further complicates absolute URI comparisons and integrity), and introduces redundancy (and potential ambiguity) with value/type. - Treat *type *as *OPTIONAL*. My *preference *would be to treat this as REQUIRED in order to eliminate any ambiguity, but given that the SCIM sp= ecs don't require it, doing this would limit interoperability for consumers that may not be sending it. - If *type *is not provided, assume the *default value is "User"*. - Perform *referential integrity *to ensure that any provided group member resources exist, based on value and type. *Examples* Given the existence of the following resources, here are some example requests/responses based on this proposal: - ../Users/abc - ../Groups/xyz Group Members Response "members": [ { "value": "abc", "type": "User" }, { "value": "xyz", "type": "Group" } ] 2xx - Success "members": [ { "value": "abc" }, { "value": "xyz", "type": "Group" } ] "members": [ { "value": "abc", "$ref": "anything at all" }, { "value": "xyz", "type": "Group", "$ref": "anything at all" } ] "members": [ { "value": "xyz" } ] 400 - Missing =E2=80=9CGroup=E2=80=9D "type" on nested group member definit= ion "members": [ { "value": "xyz" "$ref": "../Groups/xyz" } ] "members": [ { "$ref": "../Users/abc" } ] 400 - Missing "value" on group member definition "members": [ { "$ref": "../Groups/xyz" } ] "members": [ { "value": "abc", "type": "Group" } ] 400 - Wrong "type" provided "members": [ { "value": "xyz", "type": "User" } ] "members": [ { "value": "abc", "type": "UnsupportedType" } ] 400 - Unsupported "type" provided "members": [ { "value": "no such resource with or without type" } ] 400 - Member does not exist On Wed, Aug 9, 2017 at 11:06 AM, Phil Hunt (IDM) wrote: > I agree the server can decide. > > IMO the server should check referential integrity. By doing so it would > likely know the type. The spec is silent (as far as i recall) on whether = it > expresses it. > > You can also tell via id which is local and $ref path given's scim's > strict path rules (look at the parent of the last segment). > > From my recollection some of these items were not that important given > scim was provisioning api for apps - apps implementing server side are fr= ee > to do what they can/want. Now that it is being used as directory, closing > some unspecified / loose areas might be better for interop IMO. > > Phil > > On Aug 9, 2017, at 8:32 AM, Kelly Grizzle > wrote: > > Given the general desire for SCIM to allow loose reading but strict > writing, I would vote for option 1. If type is not specified in a > PUT/POST/PATCH then the server can assume =E2=80=9CUser=E2=80=9D. > > > > --Kelly > > > > *From:* Shelley [mailto:randomshelley@gmail.com = ] > > *Sent:* Wednesday, August 9, 2017 9:02 AM > *To:* Kelly Grizzle > *Cc:* scim@ietf.org > *Subject:* Re: [scim] Groups Member Type > > > > *Resurrecting this old thread, as this question has recently come up > during some of our interoperability testing, and there still appears to b= e > some ambiguity in the spec...* > > > The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected > behavior if the type sub-attribute is not provided on a Group resource > member. Neither spec seems to explicitly require this attribute, so what > is the expected behavior if no type is provided? Is there a default (e.g. > "User" or "Group"), must Service Providers search for the member across *= all > *resource types, or should it be treated as REQUIRED (e.g. returning a 40= 0 > error)? > > > > > > On Mon, Feb 25, 2013 at 10:38 AM, Shelley wrote= : > > Thanks, Kelly. Given that the ID may represent either a User or Group and > only the combination of "type" and "value" uniquely identify the referenc= e, > should the canonical "type" attribute for group members be REQUIRED as > well? (Further, the majority of examples throughout the Protocol > specification only include a "value" and not "type", so it's ambiguous as > to whether these "values" represent Users or Groups.) > > > > On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle < > kelly.grizzle@sailpoint.com> wrote: > > I opened ticket #35 to change this. > > > > http://trac.tools.ietf.org/wg/scim/trac/ticket/35 > > > > > --Kelly > > > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Shelley > *Sent:* Monday, February 11, 2013 11:36 AM > *To:* Kelly Grizzle > *Cc:* scim@ietf.org > *Subject:* Re: [scim] Groups Member Type > > > > +1 to mark it as "immutable". > > On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle > wrote: > > Good point. It seems like this should say =E2=80=9Cimmutable=E2=80=9D ra= ther than > =E2=80=9Cread-only=E2=80=9D, since it can be set initially but not update= d. Thoughts from > anyone else? If this seems reasonable I=E2=80=99ll open an issue to get = this fixed. > > > > --Kelly > > > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Shelley > *Sent:* Friday, February 01, 2013 1:37 PM > *To:* scim@ietf.org > *Subject:* [scim] Groups Member Type > > > > As indicated in Section 8, the canonical types for Group members are > READ-ONLY. As such, how can consumers provide the type (i.e. "User" or > "Group")? Is it implied that IDs are unique across both users and groups = in > order for service providers to fulfill this requirement? > > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKC= X5Y > TpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > nXj1uLbLovxxCW-VPX0d1geWghpaAIZtMXKkPYyACLo&s=3DrCY_ > ttBwpsTcGVSsZT2hsLHWPXL17cWyIBS5WDT4oDs&e=3D > > --94eb2c03ce80cf51650556566e8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You c= an also tell via id which is local and $ref path given's scim's str= ict path rules (look at the parent of the last segment).
  • Is the id= now required to be globally unique across all resource types? If not, ther= e is no guarantee that an SP can determine the resource type from th= e id.
  • The $ref is also optional, so this cannot be consistently used to determine the t= ype. Further, I was under the impression that the $ref is primarily used for SPs to communicate= the resource location to consumers, rather than vice versa (i.e. it's = essentially a read-only attribute).

Here is my tenta= tive plan for our SP implementation for evaluating group members<= /b>:

  • Treat <= b>value as REQUIRED. While the example SCIM schema does not actually req= uire the group member value= sub-attribute, this is the most consistent identifier for referring= to members.
  • Treat $ref as READ-ONLY (i.e. ignore it completely when = processing requests). Using a $ref provided by consumers seems a bit fragile (aside from elimin= ating the complexity of URI comparison, it's possible that a single res= ource may have multiple DNS names, which further complicates absolute URI = comparisons and integrity), and introduces redundancy (and potential ambigu= ity) with value/type= .
  • Treat type as OPTIONAL. My preference would be to treat this as REQUIRED in order to eliminate any ambiguity, but=20 given that the SCIM specs don't require it, doing this would limit=20 interoperability for consumers that may not be sending it.
  • If type is not provid= ed, assume the default value is "User".
  • Perform referential integri= ty to ensure that any provided group member resources exist, based on <= span style=3D"font-family:monospace,monospace">value and type.

Examples

Given the existence of the foll= owing resources, here are some example requests/responses based on this pro= posal:

  • ../Us= ers/abc
  • ../G= roups/xyz

"members": [

=C2=A0 {

=C2= =A0=C2=A0=C2=A0 "value": "xyz"

=C2=A0 =C2=A0 &q= uot;$ref": "../Groups/xyz"

=C2=A0 }

=

= ]

=

"members": [

=C2=A0 {

=C2= =A0=C2=A0=C2=A0 "value": "abc",

=C2=A0 =C2=A0 &q= uot;type": "UnsupportedType"

=C2=A0 }

]=

Group Members

Response

"members": [=

=C2=A0 {
=C2=A0=C2=A0=C2=A0 "value": "abc",<= /font>

= =C2=A0=C2=A0=C2=A0=C2=A0"type": "User"

=C2=A0 }= ,

=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0"value": "= xyz",

=C2=A0=C2=A0=C2=A0=C2=A0"type": "Group&qu= ot;

=C2=A0 }

]

2xx - Success

"members": [

=C2=A0 {

=C2=A0=C2=A0=C2=A0 &= quot;value": "abc"

=C2=A0 },

=C2=A0 {<= /font>

= =C2=A0=C2=A0=C2=A0 "value": "xyz",

=C2=A0 =C2= =A0 "type": "Group"

<= span style=3D"font-family:monospace,monospace">=C2=A0 }

]

&qu= ot;members": [

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "valu= e": "abc",

=C2=A0 =C2=A0 "$ref": "anyt= hing at all"

=C2=A0 },

=C2=A0 {

=C2=A0=C2=A0=C2= =A0 "value": "xyz",

<= span style=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 "type&quo= t;: "Group",

=C2=A0 =C2=A0 "$ref": "anythin= g at all"

=C2=A0 }

]

"members": [=

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "value": "xyz"

=C2=A0 }

]

400 - Missing =E2=80=9CGroup=E2=80=9D "type" on nested= group member definition

&q= uot;members": [

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "$ref= ": "../Users/abc"

=C2=A0 }

]

=

400 - Missing "value&qu= ot; on group member definition

"members": [

=C2=A0 {=

=C2=A0=C2=A0=C2=A0 "$ref": "../Groups/xyz"

=C2= =A0 }

]

"members": [

=C2=A0 {

=C2=A0= =C2=A0=C2=A0 "value": "abc",

=C2=A0 =C2=A0 "= ;type": "Group"

=C2=A0 }

]

<= /td>

400 - Wrong "type" provided

"members&qu= ot;: [

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "value": "= xyz",

=C2=A0 =C2=A0 "type": "User"

= =C2=A0 }

]

400 - Unsupported "type" provided

"members= ": [

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "value": &qu= ot;no such resource with or without type"

=C2=A0 }

]

400 - Member does not exist



On Wed, Aug 9, 2017 at 11:06 AM, Phil Hunt (IDM) <phil.hunt@= oracle.com> wrote:
I agree the server can decide.=C2=A0

IMO the server should c= heck referential integrity. By doing so it would likely know the type. The = spec is silent (as far as i recall) on whether it expresses it.=C2=A0
=

You can also tell via id= which is local and $ref path given's scim's strict path rules (loo= k at the parent of the last segment).=C2=A0

From my recollection some of these = items were not that important given scim was provisioning api for apps - ap= ps implementing server side are free to do what they can/want. Now that it = is being used as directory, closing some unspecified / loose areas might be= better for interop IMO.=C2=A0

Phil

On A= ug 9, 2017, at 8:32 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:<= br>

Given the general desire for SCIM to allow loose rea= ding but strict writing, I would vote for option 1.=C2=A0 If type is not sp= ecified in a PUT/POST/PATCH then the server can assume =E2=80=9CUser=E2=80= =9D.

=C2=A0

--Kelly

=C2=A0

From: Shelley [mailto:randomshelley@gmail.com] Sent: Wednesday, August 9, 2017 9:02 AM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: scim@ietf.org=
Subject: Re: [scim] Groups Member Type

=C2=A0

Resurrecting this old thread, as this question ha= s recently come up during some of our interoperability testing, and there s= till appears to be some ambiguity in the spec...


The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected be= havior if the type sub-attribu= te is not provided on a Group resource <= span style=3D"font-family:"Courier New""> member. Neither spec seems to explicitly require this attribute, so = what is the expected behavior if no type is provided= ? Is there a default (e.g. "User" or "Group"), must Service Providers search for the me= mber across all resource types, or should it be treated as REQUIRED (e.g. return= ing a 400 error)?

=C2=A0

=C2=A0

On Mon, Feb 25, 2013 at 10:38 AM, Shelley <randomshelley@gmail.= com> wrote:

Thanks, Kelly. Given that the ID may represent eithe= r a User or Group and only the combination of "type" and "va= lue" uniquely identify the reference, should the canonical "type&= quot; attribute for group members be REQUIRED as well? (Further, the majority of examples throughout the Protocol specification only includ= e a "value" and not "type", so it's ambiguous as to= whether these "values" represent Users or Groups.)=



On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle <<= a href=3D"mailto:kelly.grizzle@sailpoint.com" target=3D"_blank">kelly.grizz= le@sailpoint.com> wrote:

I opened ticket= #35 to change this.

=C2=A0

http://trac.tools.ietf.org/wg/<= wbr>scim/trac/ticket/35

=C2=A0

--Kelly<= u>

=C2=A0

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Shelley
Sent: Monday, February 11, 2013 11:36 AM
To: Kelly Grizzle
Cc: scim@ietf.org=
Subject: Re: [scim] Groups Member Type

=C2=A0

+1 to mark it as "= immutable".

On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle <kelly.grizzl= e@sailpoint.com> wrote:

Good point.=C2= =A0 It seems like this should say =E2=80=9Cimmutable=E2=80=9D rather than = =E2=80=9Cread-only=E2=80=9D, since it can be set initially but not updated.= =C2=A0 Thoughts from anyone else?=C2=A0 If this seems reasonable I=E2=80=99ll open an issue to get thi= s fixed.

=C2=A0

--Kelly<= u>

=C2=A0

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Shelley
Sent: Friday, February 01, 2013 1:37 PM
To: scim@ietf.org=
Subject: [scim] Groups Member Type

=C2=A0

As indicated in Section 8, the canonical types for G= roup members are READ-ONLY. As such, how can consumers provide the type (i.= e. "User" or "Group")? Is it implied that IDs are unique across both users and groups in order for service providers to fulf= ill this requirement?

=C2=A0

=C2=A0

=C2=A0

<= br>
--94eb2c03ce80cf51650556566e8d-- From nobody Wed Aug 9 12:18:48 2017 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 D4B701324AB for ; Wed, 9 Aug 2017 12:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 QE7KNc0uEgWL for ; Wed, 9 Aug 2017 12:18:30 -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 BCC321324A3 for ; Wed, 9 Aug 2017 12:18:00 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v79JHwXu008601 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Aug 2017 19:17:58 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v79JHwY3013342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Aug 2017 19:17:58 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v79JHvWj013433; Wed, 9 Aug 2017 19:17:57 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Aug 2017 12:17:57 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-6A3BEB81-DF80-4B81-8726-94B53D6D4B2F Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 9 Aug 2017 12:17:55 -0700 Cc: "scim@ietf.org" , Kelly Grizzle Content-Transfer-Encoding: 7bit Message-Id: <5F234BB3-842D-4BF6-8896-0F583F85F64C@oracle.com> References: <56C3C758F9D6534CA3778EAA1E0C343753AB2F38@BLUPRD0412MB643.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343753AC4630@BLUPRD0412MB643.namprd04.prod.outlook.com> To: Shelley X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [scim] Groups Member Type X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 19:18:36 -0000 --Apple-Mail-6A3BEB81-DF80-4B81-8726-94B53D6D4B2F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Shelley, Yes.. =46rom the defn of id: > A unique identifier for a SCIM resource as defined by the service provider= . Each representation of the resource MUST include a non-empty "id" value. T= his identifier MUST be unique across the SCIM service provider's entire set o= f resources. It MUST be a stable, non-reassignable identifier that does not c= hange when the same resource is returned in subsequent requests. The value o= f the "id" attribute is always issued by the service provider and MUST NOT b= e specified by the client... Phil On Aug 9, 2017, at 11:41 AM, Shelley wrote: >> You can also tell via id which is local and $ref path given's scim's stri= ct path rules (look at the parent of the last segment).=20 > Is the id now required to be globally unique across all resource types? If= not, there is no guarantee that an SP can determine the resource type from t= he id. > The $ref is also optional, so this cannot be consistently used to determin= e the type. Further, I was under the impression that the $ref is primarily u= sed for SPs to communicate the resource location to consumers, rather than v= ice versa (i.e. it's essentially a read-only attribute). > Here is my tentative plan for our SP implementation for evaluating group m= embers: >=20 > Treat value as REQUIRED. While the example SCIM schema does not actually r= equire the group member value sub-attribute, this is the most consistent ide= ntifier for referring to members. > Treat $ref as READ-ONLY (i.e. ignore it completely when processing request= s). Using a $ref provided by consumers seems a bit fragile (aside from elimi= nating the complexity of URI comparison, it's possible that a single resourc= e may have multiple DNS names, which further complicates absolute URI compar= isons and integrity), and introduces redundancy (and potential ambiguity) wi= th value/type. > Treat type as OPTIONAL. My preference would be to treat this as REQUIRED i= n order to eliminate any ambiguity, but given that the SCIM specs don't requ= ire it, doing this would limit interoperability for consumers that may not b= e sending it. > If type is not provided, assume the default value is "User". > Perform referential integrity to ensure that any provided group member res= ources exist, based on value and type. > Examples >=20 > Given the existence of the following resources, here are some example requ= ests/responses based on this proposal: >=20 > ../Users/abc > ../Groups/xyz >=20 > Group Members > Response > "members": [ > { > "value": "abc", > "type": "User" > }, > { > "value": "xyz", > "type": "Group" > } > ] > 2xx - Success > "members": [ > { > "value": "abc" > }, > { > "value": "xyz", > "type": "Group" > } > ] > "members": [ > { > "value": "abc", > "$ref": "anything at all" > }, > { > "value": "xyz", > "type": "Group", > "$ref": "anything at all" > } > ] > "members": [ > { > "value": "xyz" > } > ] > 400 - Missing =E2=80=9CGroup=E2=80=9D "type" on nested group member defini= tion > "members": [ > { > "value": "xyz" > "$ref": "../Groups/xyz" > } > ] > "members": [ > { > "$ref": "../Users/abc" > } > ] > 400 - Missing "value" on group member definition > "members": [ > { > "$ref": "../Groups/xyz" > } > ] > "members": [ > { > "value": "abc", > "type": "Group" > } > ] > 400 - Wrong "type" provided > "members": [ > { > "value": "xyz", > "type": "User" > } > ] > "members": [ > { > "value": "abc", > "type": "UnsupportedType" > } > ] > 400 - Unsupported "type" provided > "members": [ > { > "value": "no such resource with or without type" > } > ] > 400 - Member does not exist >=20 >=20 >> On Wed, Aug 9, 2017 at 11:06 AM, Phil Hunt (IDM) w= rote: >> I agree the server can decide.=20 >>=20 >> IMO the server should check referential integrity. By doing so it would l= ikely know the type. The spec is silent (as far as i recall) on whether it e= xpresses it.=20 >>=20 >> You can also tell via id which is local and $ref path given's scim's stri= ct path rules (look at the parent of the last segment).=20 >>=20 >> =46rom my recollection some of these items were not that important given s= cim was provisioning api for apps - apps implementing server side are free t= o do what they can/want. Now that it is being used as directory, closing som= e unspecified / loose areas might be better for interop IMO.=20 >>=20 >> Phil >>=20 >>> On Aug 9, 2017, at 8:32 AM, Kelly Grizzle w= rote: >>>=20 >>> Given the general desire for SCIM to allow loose reading but strict writ= ing, I would vote for option 1. If type is not specified in a PUT/POST/PATC= H then the server can assume =E2=80=9CUser=E2=80=9D. >>>=20 >>> =20 >>>=20 >>> --Kelly >>>=20 >>> =20 >>>=20 >>> From: Shelley [mailto:randomshelley@gmail.com]=20 >>> Sent: Wednesday, August 9, 2017 9:02 AM >>> To: Kelly Grizzle >>> Cc: scim@ietf.org >>> Subject: Re: [scim] Groups Member Type >>>=20 >>> =20 >>>=20 >>> Resurrecting this old thread, as this question has recently come up duri= ng some of our interoperability testing, and there still appears to be some a= mbiguity in the spec... >>>=20 >>>=20 >>> The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected= behavior if the type sub-attribute is not provided on a Group resource memb= er. Neither spec seems to explicitly require this attribute, so what is the e= xpected behavior if no type is provided? Is there a default (e.g. "User" or "= Group"), must Service Providers search for the member across all resource ty= pes, or should it be treated as REQUIRED (e.g. returning a 400 error)? >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> On Mon, Feb 25, 2013 at 10:38 AM, Shelley wrot= e: >>>=20 >>> Thanks, Kelly. Given that the ID may represent either a User or Group an= d only the combination of "type" and "value" uniquely identify the reference= , should the canonical "type" attribute for group members be REQUIRED as wel= l? (Further, the majority of examples throughout the Protocol specification o= nly include a "value" and not "type", so it's ambiguous as to whether these "= values" represent Users or Groups.) >>>=20 >>>=20 >>>=20 >>>=20 >>> On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle wrote: >>>=20 >>> I opened ticket #35 to change this. >>>=20 >>> =20 >>>=20 >>> http://trac.tools.ietf.org/wg/scim/trac/ticket/35 >>>=20 >>> =20 >>>=20 >>> --Kelly >>>=20 >>> =20 >>>=20 >>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of S= helley >>> Sent: Monday, February 11, 2013 11:36 AM >>> To: Kelly Grizzle >>> Cc: scim@ietf.org >>> Subject: Re: [scim] Groups Member Type >>>=20 >>> =20 >>>=20 >>> +1 to mark it as "immutable". >>>=20 >>> On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle wrote: >>>=20 >>> Good point. It seems like this should say =E2=80=9Cimmutable=E2=80=9D r= ather than =E2=80=9Cread-only=E2=80=9D, since it can be set initially but no= t updated. Thoughts from anyone else? If this seems reasonable I=E2=80=99l= l open an issue to get this fixed. >>>=20 >>> =20 >>>=20 >>> --Kelly >>>=20 >>> =20 >>>=20 >>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of S= helley >>> Sent: Friday, February 01, 2013 1:37 PM >>> To: scim@ietf.org >>> Subject: [scim] Groups Member Type >>>=20 >>> =20 >>>=20 >>> As indicated in Section 8, the canonical types for Group members are REA= D-ONLY. As such, how can consumers provide the type (i.e. "User" or "Group")= ? Is it implied that IDs are unique across both users and groups in order fo= r service providers to fulfill this requirement? >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10= &r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DnXj1uLbLovxxCW-VPX0d1ge= WghpaAIZtMXKkPYyACLo&s=3DrCY_ttBwpsTcGVSsZT2hsLHWPXL17cWyIBS5WDT4oDs&e=3D=20= >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r= =3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Dwp8wcoem5mojtpf1ZRHs5MIsg= J3x1z1mF4KRgHjkL6c&s=3DbyhGtJG7J3hI2TFkSQI2fne2B4UrhBY1oHZDWyUvuyw&e=3D=20 --Apple-Mail-6A3BEB81-DF80-4B81-8726-94B53D6D4B2F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Shelley,

Yes..

=46rom the defn of id= :
A unique identifier for a SCIM r= esource 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= SCIM 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 NOT be specified by the client...

Phil

On Aug 9, 2017, at 11:41 AM,= Shelley <randomshelley@gmail.= com> wrote:

You can also tell vi= a id which is local and $ref path given's scim's strict path rules (look at t= he parent of the last segment).
  • Is the id now required to be globall= y unique across all resource types? If not, there is no guarantee tha= t an SP can determine the resource type from the id.
  • The $ref is also optional, so this c= annot be consistently used to determine the type. Further, I was under the i= mpression that the $ref is primarily used for SPs to communicate the resource location to consume= rs, rather than vice versa (i.e. it's essentially a read-only attribu= te).

Here is my tentative plan for our SP implementation for= evaluating group members:

  • Treat value as REQUIRED. Wh= ile the example SCIM schema does not a= ctually require the group member value sub-attribute, this is the most consistent identifier for r= eferring to members.
  • Treat $ref as READ-ONLY (i.e. ignore it completely= when processing requests). Using a $ref provided by consumers seems a bit fragile (aside from el= iminating the complexity of URI comparison, it's possible that a single reso= urce may have multiple DNS names, which further complicates absolute URI co= mparisons and integrity), and introduces redundancy (and potential ambiguity= ) with value/type.
  • Treat type <= /b>as OPTIONAL. My preference would be to treat this as REQUIRED in order to eliminate any ambiguity, but=20 given that the SCIM specs don't require it, doing this would limit=20 interoperability for consumers that may not be sending it.
  • If type is not provided= , assume the default value is "User".
  • Perform referential integrity to ensu= re that any provided group member resources exist, based on value and type.

Exa= mples

Given the existence of the following resources, h= ere are some example requests/responses based on this proposal:

    <= li>../Users/abc<= li>../Groups/xyz=

Group Members

Res= ponse

"members": [

  {
    "value": "abc",

&nb= sp;   "type": "User"

  },

  {

 =    "value": "xyz",

    "type": "Gro= up"

  }

]

2xx - Success

"members"= : [

  {

    "value": "abc"

  },

  {

    "value": "xyz",

    "type":= "Group"

  }

]

"members": [

  {

=  &nbs= p;  "value": "abc",

    "$ref": "anything at all"=

&= nbsp; },

  {

    "value": "xyz",

  &= nbsp; "type": "Group",

    "$ref": "anything at all"

&nb= sp; }

]

"members": [

  {

<= span style=3D"font-family:monospace,monospace">     "value": "= xyz"

  }

]

400 - Missing =E2=80=9CGroup=E2=80=9D "type" on nested group member d= efinition

"members": [

  {

    "value": "xyz"

    "$ref": "../Groups/xyz"

  }

]"members": [

  {

    "$ref": "../Users/abc"

  }

]

= 400 - Missing= "value" on group member definition

"members": [

=   {

  &= nbsp; "$ref": "../Groups/xyz"

  }

= ]

"members": [

 = {

    "value": "abc",

=     "type": "Group= "

  }

]

400 - Wrong "type" provided

"members": [

  {

    "value": "xyz",<= /font>

&n= bsp;   "type": "User"

  }

]

<= tr style=3D"height:55.5pt">

"members": [=

  {=

    "value": "abc",

<= span style=3D"font-family:monospace,monospace">    "type": "Unsupp= ortedType"

  }

]

400 - Unsupported "type" provided<= /span>

"members": [

  {

    "value": "no such reso= urce with or without type"

  }

]

400 - Member does not exi= st



On Wed, Aug 9, 2017 at 11= :06 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
I agre= e the server can decide. 

IMO the server should check referential integrity. By doing so it w= ould likely know the type. The spec is silent (as far as i recall) on whethe= r it expresses it. 

You can also tell via id which is local and $ref path given's scim's str= ict path rules (look at the parent of the last segment). 

=
=46rom my recollec= tion some of these items were not that important given scim was provisioning= api for apps - apps implementing server side are free to do what they can/w= ant. Now that it is being used as directory, closing some unspecified / loos= e areas might be better for interop IMO. 

Phil

On Aug 9, 2017, at 8:32 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com= > wrote:

Given the general desire for SCIM to allow loose read= ing but strict writing, I would vote for option 1.  If type is not spec= ified in a PUT/POST/PATCH then the server can assume =E2=80=9CUser=E2=80=9D.=

 

--Kelly

 

From: Shelley [mailto:randomshelley@gmail.com]
Sent: Wednesday, August 9, 2017 9:02 AM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: scim@ietf.org<= /a>
Subject: Re: [scim] Groups Member Type

 

Resurrecting this old thread, as this question has= recently come up during some of our interoperability testing, and there sti= ll appears to be some ambiguity in the spec...


The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected beh= avior if the type sub-attribut= e is not provided on a Group resource member. Neither spec seems to explicitly require this attribute, so w= hat is the expected behavior if no type is provided?= Is there a default (e.g. "User" or "Grou= p"), must Service Providers search for the member across all resource types, or should it be treated as REQUIRED (e.g. returni= ng a 400 error)?

 

 

On Mon, Feb 25, 2013 at 10:38 AM, Shelley <randomshelley@gmail.co= m> wrote:

Thanks, Kelly. Given that the ID may represent either= a User or Group and only the combination of "type" and "value" uniquely ide= ntify the reference, should the canonical "type" attribute for group members= be REQUIRED as well? (Further, the majority of examples throughout the Protocol specification only include= a "value" and not "type", so it's ambiguous as to whether these "values" re= present Users or Groups.)



On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle <kelly.grizzle= @sailpoint.com> wrote:

I opened ticket #= 35 to change this.

 =

http://trac.tools.ietf.org/wg/sc= im/trac/ticket/35

 =

--Kelly

 =

From: scim-bounces@ietf= .org [mailto:= scim-bounces@ietf.org] On Behalf Of Shelley
Sent: Monday, February 11, 2013 11:36 AM
To: Kelly Grizzle
Cc: scim@ietf.org<= /a>
Subject: Re: [scim] Groups Member Type

 

+1 to mark it as "immuta= ble".

On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle <kelly.grizzle@s= ailpoint.com> wrote:

Good point. = ; It seems like this should say =E2=80=9Cimmutable=E2=80=9D rather than =E2=80= =9Cread-only=E2=80=9D, since it can be set initially but not updated.  T= houghts from anyone else?  If this seems reasonable I=E2=80=99ll open an issue to get this= fixed.

 =

--Kelly

 =

From: scim-bounces@ietf= .org [mailto:= scim-bounces@ietf.org] On Behalf Of Shelley
Sent: Friday, February 01, 2013 1:37 PM
To: scim@ietf.org<= /a>
Subject: [scim] Groups Member Type

 

As indicated in Section 8, the canonical types for Gr= oup members are READ-ONLY. As such, how can consumers provide the type (i.e.= "User" or "Group")? Is it implied that IDs are unique across both users and groups in order for service providers to fulfi= ll this requirement?

 

 

 


=
<= /body>= --Apple-Mail-6A3BEB81-DF80-4B81-8726-94B53D6D4B2F-- From nobody Wed Aug 9 14:45:22 2017 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 5D93713244B for ; Wed, 9 Aug 2017 14:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sailpoint.onmicrosoft.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 Zb9fq-tWmaIM for ; Wed, 9 Aug 2017 14:45:16 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0103.outbound.protection.outlook.com [104.47.32.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E53132458 for ; Wed, 9 Aug 2017 14:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sailpoint.onmicrosoft.com; s=selector1-sailpoint-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TP4AL+iPxZ9JIM1yZ591R1+OnHasTQrsXxFAhm04SRw=; b=HHntPyO+z820zG1abGBV43lf/82B51g/jW4CF44ET+apOQ00tP5XOxoKrtnqIa+jvs3WjgsFQOa1mNKL5OxYWo9BxItTqJN0F7jSQKjT/BCFZuWOR/YfS2NFyKSqrGN/fgaDESS2czB1hgLYTLMaHQ8QjaHT+OhRGsdlQGIC10g= Received: from CY1PR04MB2363.namprd04.prod.outlook.com (10.167.10.143) by CY1PR04MB2362.namprd04.prod.outlook.com (10.167.10.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Wed, 9 Aug 2017 21:45:13 +0000 Received: from CY1PR04MB2363.namprd04.prod.outlook.com ([10.167.10.143]) by CY1PR04MB2363.namprd04.prod.outlook.com ([10.167.10.143]) with mapi id 15.01.1320.018; Wed, 9 Aug 2017 21:45:13 +0000 From: Kelly Grizzle To: Shelley , "Phil Hunt (IDM)" CC: "scim@ietf.org" Thread-Topic: [scim] Groups Member Type Thread-Index: AQHOALOOeHp6hjJutkGc7C2Tyxq6nZhpv6cAgAs7UQCAAEp64IAVpkqAiftC6wCAABjZ4IAACfiAgAArcoCAADMQsA== Date: Wed, 9 Aug 2017 21:45:13 +0000 Message-ID: References: <56C3C758F9D6534CA3778EAA1E0C343753AB2F38@BLUPRD0412MB643.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343753AC4630@BLUPRD0412MB643.namprd04.prod.outlook.com> In-Reply-To: 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=kelly.grizzle@sailpoint.com; x-originating-ip: [70.114.154.180] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR04MB2362; 6:wOLqoa0fVc5uI8BA69rrcSYQhHJz9BzU5HUzxoU+AOg/aKsUixt4+tdZUmn9uOWzgA1oO8KaEVxFs1pNVAAZlI++OaSIVS+VASMS3OiTxm2DQE813xDteoebHC3Ysu6posABRIvldv3teGEAbVC3z5jPMDTqFpOXcT4piT+uQd/aUm3ozXW/jM33Is4gyzwTGyffP5kfIBkL+EfUG8eD/L7FGKm1iuM8L4Lzmz/Tfx+kTpmumYO6iR7ReSuNQZR/aZ8lAHVdPaHgml6ZtyVvPtEVy9dRO22TICveZqmnrOPxf8Hhg3+0CSv1/17qqjUQPweY9kJXxsEQJ/iylBqYUw==; 5:Q+m3aj6gUc00Bg0/wR7R7uebxW/HzbpApACZWuuLAladztFeDh8oTOlgpPETR1IRn2On6GqdWeoryMdAEr3EDkJ/+HpuG8GC8vqb99xMRpdFLsjoM8MHUHJIuwy8C+0eovayJTRIFWNZV4PSzEYTFw==; 24:/H3NtBSQaFkbtN4c71lhkF4ZH9aFze5B9UOE6IJjxFWakg6ZJCKkm1D+2+K1s+trD/LNmcyuZccgNtchZN+6zOzoipBxXRqubToRSQmfrGU=; 7:CAFftUzf4FCZ4PwkjCLfoPm4H3yafI26tLq8es2yE1Dh3/FGx8HXxgJsH8TeGkx7BvkZvUrZzWk9VtATOKAdqqTpO8ZXa3VFzzfq5mzwLEx0yHFhb/TbmKveJHGTNFLhMR8uqjARGdVOk+OXqkfTydFtNWCc47P8lMHRrVon4/92XTTonvK9Uw5+Vnp7EjaScR6pCWakHw7oyzfeD8zl3zBUAO8QB6lxehl0zjzJQNI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2de8735a-7e31-4f04-e992-08d4df6fea93 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR04MB2362; x-ms-traffictypediagnostic: CY1PR04MB2362: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(21748063052155)(146099531331640); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR04MB2362; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR04MB2362; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39400400002)(39410400002)(39840400002)(24454002)(189002)(199003)(377454003)(966005)(81166006)(478600001)(106356001)(4326008)(33656002)(5660300001)(3280700002)(105586002)(3660700001)(6506006)(2900100001)(66066001)(6436002)(517774005)(93886004)(7696004)(53546010)(606006)(8676002)(229853002)(14454004)(2950100002)(77096006)(19609705001)(39060400002)(8936002)(7736002)(55016002)(99286003)(102836003)(790700001)(189998001)(54896002)(575784001)(101416001)(81156014)(97736004)(6116002)(53946003)(53936002)(561944003)(9686003)(68736007)(3846002)(6246003)(236005)(2906002)(74316002)(86362001)(50986999)(25786009)(38730400002)(54356999)(76176999)(6306002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR04MB2362; H:CY1PR04MB2363.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sailpoint.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR04MB2363D27C3FCAE2AD9AFEDB61E28B0CY1PR04MB2363namp_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2017 21:45:13.5383 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR04MB2362 Archived-At: Subject: Re: [scim] Groups Member Type X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 21:45:20 -0000 --_000_CY1PR04MB2363D27C3FCAE2AD9AFEDB61E28B0CY1PR04MB2363namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91ciBwbGFuIHNvdW5kcyBnb29kIHRvIG1lLCBTaGVsbHkuICBUaGF04oCZcyBob3cgSSB3b3Vs ZCBpbXBsZW1lbnQgaXQuDQoNCkZyb206IFNoZWxsZXkgW21haWx0bzpyYW5kb21zaGVsbGV5QGdt YWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDksIDIwMTcgMTo0MiBQTQ0KVG86IFBo aWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb20+DQpDYzogS2VsbHkgR3JpenpsZSA8 a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPjsgc2NpbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtzY2ltXSBHcm91cHMgTWVtYmVyIFR5cGUNCg0KWW91IGNhbiBhbHNvIHRlbGwgdmlhIGlkIHdo aWNoIGlzIGxvY2FsIGFuZCAkcmVmIHBhdGggZ2l2ZW4ncyBzY2ltJ3Mgc3RyaWN0IHBhdGggcnVs ZXMgKGxvb2sgYXQgdGhlIHBhcmVudCBvZiB0aGUgbGFzdCBzZWdtZW50KS4NCg0KICAqICAgSXMg dGhlIGlkIG5vdyByZXF1aXJlZCB0byBiZSBnbG9iYWxseSB1bmlxdWUgYWNyb3NzIGFsbCByZXNv dXJjZSB0eXBlcz8gSWYgbm90LCB0aGVyZSBpcyBubyBndWFyYW50ZWUgdGhhdCBhbiBTUCBjYW4g ZGV0ZXJtaW5lIHRoZSByZXNvdXJjZSB0eXBlIGZyb20gdGhlIGlkLg0KICAqICAgVGhlICRyZWYg aXMgYWxzbyBvcHRpb25hbCwgc28gdGhpcyBjYW5ub3QgYmUgY29uc2lzdGVudGx5IHVzZWQgdG8g ZGV0ZXJtaW5lIHRoZSB0eXBlLiBGdXJ0aGVyLCBJIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0 aGF0IHRoZSAkcmVmIGlzIHByaW1hcmlseSB1c2VkIGZvciBTUHMgdG8gY29tbXVuaWNhdGUgdGhl IHJlc291cmNlIGxvY2F0aW9uIHRvIGNvbnN1bWVycywgcmF0aGVyIHRoYW4gdmljZSB2ZXJzYSAo aS5lLiBpdCdzIGVzc2VudGlhbGx5IGEgcmVhZC1vbmx5IGF0dHJpYnV0ZSkuDQoNCkhlcmUgaXMg bXkgdGVudGF0aXZlIHBsYW4gZm9yIG91ciBTUCBpbXBsZW1lbnRhdGlvbiBmb3IgZXZhbHVhdGlu ZyBncm91cCBtZW1iZXJzOg0KDQogICogICBUcmVhdCB2YWx1ZSBhcyBSRVFVSVJFRC4gV2hpbGUg dGhlIGV4YW1wbGUgU0NJTSBzY2hlbWE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2 NDMjcGFnZS02OT4gZG9lcyBub3QgYWN0dWFsbHkgcmVxdWlyZSB0aGUgZ3JvdXAgbWVtYmVyIHZh bHVlIHN1Yi1hdHRyaWJ1dGUsIHRoaXMgaXMgdGhlIG1vc3QgY29uc2lzdGVudCBpZGVudGlmaWVy IGZvciByZWZlcnJpbmcgdG8gbWVtYmVycy4NCiAgKiAgIFRyZWF0ICRyZWYgYXMgUkVBRC1PTkxZ IChpLmUuIGlnbm9yZSBpdCBjb21wbGV0ZWx5IHdoZW4gcHJvY2Vzc2luZyByZXF1ZXN0cykuIFVz aW5nIGEgJHJlZiBwcm92aWRlZCBieSBjb25zdW1lcnMgc2VlbXMgYSBiaXQgZnJhZ2lsZSAoYXNp ZGUgZnJvbSBlbGltaW5hdGluZyB0aGUgY29tcGxleGl0eSBvZiBVUkkgY29tcGFyaXNvbiwgaXQn cyBwb3NzaWJsZSB0aGF0IGEgc2luZ2xlIHJlc291cmNlIG1heSBoYXZlIG11bHRpcGxlIEROUyBu YW1lcywgd2hpY2ggZnVydGhlciBjb21wbGljYXRlcyBhYnNvbHV0ZSBVUkkgY29tcGFyaXNvbnMg YW5kIGludGVncml0eSksIGFuZCBpbnRyb2R1Y2VzIHJlZHVuZGFuY3kgKGFuZCBwb3RlbnRpYWwg YW1iaWd1aXR5KSB3aXRoIHZhbHVlL3R5cGUuDQogICogICBUcmVhdCB0eXBlIGFzIE9QVElPTkFM LiBNeSBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIHRyZWF0IHRoaXMgYXMgUkVRVUlSRUQgaW4gb3Jk ZXIgdG8gZWxpbWluYXRlIGFueSBhbWJpZ3VpdHksIGJ1dCBnaXZlbiB0aGF0IHRoZSBTQ0lNIHNw ZWNzIGRvbid0IHJlcXVpcmUgaXQsIGRvaW5nIHRoaXMgd291bGQgbGltaXQgaW50ZXJvcGVyYWJp bGl0eSBmb3IgY29uc3VtZXJzIHRoYXQgbWF5IG5vdCBiZSBzZW5kaW5nIGl0Lg0KICAqICAgSWYg dHlwZSBpcyBub3QgcHJvdmlkZWQsIGFzc3VtZSB0aGUgZGVmYXVsdCB2YWx1ZSBpcyAiVXNlciIu DQogICogICBQZXJmb3JtIHJlZmVyZW50aWFsIGludGVncml0eSB0byBlbnN1cmUgdGhhdCBhbnkg cHJvdmlkZWQgZ3JvdXAgbWVtYmVyIHJlc291cmNlcyBleGlzdCwgYmFzZWQgb24gdmFsdWUgYW5k IHR5cGUuDQoNCkV4YW1wbGVzDQoNCkdpdmVuIHRoZSBleGlzdGVuY2Ugb2YgdGhlIGZvbGxvd2lu ZyByZXNvdXJjZXMsIGhlcmUgYXJlIHNvbWUgZXhhbXBsZSByZXF1ZXN0cy9yZXNwb25zZXMgYmFz ZWQgb24gdGhpcyBwcm9wb3NhbDoNCg0KICAqICAgLi4vVXNlcnMvYWJjDQogICogICAuLi9Hcm91 cHMveHl6DQoNCg0KR3JvdXAgTWVtYmVycw0KDQoNClJlc3BvbnNlDQoNCg0KIm1lbWJlcnMiOiBb DQoNCiAgew0KICAgICJ2YWx1ZSI6ICJhYmMiLA0KDQogICAgInR5cGUiOiAiVXNlciINCg0KICB9 LA0KDQogIHsNCg0KICAgICJ2YWx1ZSI6ICJ4eXoiLA0KDQogICAgInR5cGUiOiAiR3JvdXAiDQoN CiAgfQ0KDQpdDQoNCg0KMnh4IC0gU3VjY2Vzcw0KDQoNCiJtZW1iZXJzIjogWw0KDQogIHsNCg0K ICAgICJ2YWx1ZSI6ICJhYmMiDQoNCiAgfSwNCg0KICB7DQoNCiAgICAidmFsdWUiOiAieHl6IiwN Cg0KICAgICJ0eXBlIjogIkdyb3VwIg0KDQogIH0NCg0KXQ0KDQoNCiJtZW1iZXJzIjogWw0KDQog IHsNCg0KICAgICJ2YWx1ZSI6ICJhYmMiLA0KDQogICAgIiRyZWYiOiAiYW55dGhpbmcgYXQgYWxs Ig0KDQogIH0sDQoNCiAgew0KDQogICAgInZhbHVlIjogInh5eiIsDQoNCiAgICAidHlwZSI6ICJH cm91cCIsDQoNCiAgICAiJHJlZiI6ICJhbnl0aGluZyBhdCBhbGwiDQoNCiAgfQ0KDQpdDQoNCg0K Im1lbWJlcnMiOiBbDQoNCiAgew0KDQogICAgInZhbHVlIjogInh5eiINCg0KICB9DQoNCl0NCg0K DQo0MDAgLSBNaXNzaW5nIOKAnEdyb3Vw4oCdICJ0eXBlIiBvbiBuZXN0ZWQgZ3JvdXAgbWVtYmVy IGRlZmluaXRpb24NCg0KDQoibWVtYmVycyI6IFsNCg0KICB7DQoNCiAgICAidmFsdWUiOiAieHl6 Ig0KDQogICAgIiRyZWYiOiAiLi4vR3JvdXBzL3h5eiINCg0KICB9DQoNCl0NCg0KDQoibWVtYmVy cyI6IFsNCg0KICB7DQoNCiAgICAiJHJlZiI6ICIuLi9Vc2Vycy9hYmMiDQoNCiAgfQ0KDQpdDQoN Cg0KNDAwIC0gTWlzc2luZyAidmFsdWUiIG9uIGdyb3VwIG1lbWJlciBkZWZpbml0aW9uDQoNCg0K Im1lbWJlcnMiOiBbDQoNCiAgew0KDQogICAgIiRyZWYiOiAiLi4vR3JvdXBzL3h5eiINCg0KICB9 DQoNCl0NCg0KDQoibWVtYmVycyI6IFsNCg0KICB7DQoNCiAgICAidmFsdWUiOiAiYWJjIiwNCg0K ICAgICJ0eXBlIjogIkdyb3VwIg0KDQogIH0NCg0KXQ0KDQoNCjQwMCAtIFdyb25nICJ0eXBlIiBw cm92aWRlZA0KDQoNCiJtZW1iZXJzIjogWw0KDQogIHsNCg0KICAgICJ2YWx1ZSI6ICJ4eXoiLA0K DQogICAgInR5cGUiOiAiVXNlciINCg0KICB9DQoNCl0NCg0KDQoibWVtYmVycyI6IFsNCg0KICB7 DQoNCiAgICAidmFsdWUiOiAiYWJjIiwNCg0KICAgICJ0eXBlIjogIlVuc3VwcG9ydGVkVHlwZSIN Cg0KICB9DQoNCl0NCg0KDQo0MDAgLSBVbnN1cHBvcnRlZCAidHlwZSIgcHJvdmlkZWQNCg0KDQoi bWVtYmVycyI6IFsNCg0KICB7DQoNCiAgICAidmFsdWUiOiAibm8gc3VjaCByZXNvdXJjZSB3aXRo IG9yIHdpdGhvdXQgdHlwZSINCg0KICB9DQoNCl0NCg0KDQo0MDAgLSBNZW1iZXIgZG9lcyBub3Qg ZXhpc3QNCg0KDQoNCk9uIFdlZCwgQXVnIDksIDIwMTcgYXQgMTE6MDYgQU0sIFBoaWwgSHVudCAo SURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4g d3JvdGU6DQpJIGFncmVlIHRoZSBzZXJ2ZXIgY2FuIGRlY2lkZS4NCg0KSU1PIHRoZSBzZXJ2ZXIg c2hvdWxkIGNoZWNrIHJlZmVyZW50aWFsIGludGVncml0eS4gQnkgZG9pbmcgc28gaXQgd291bGQg bGlrZWx5IGtub3cgdGhlIHR5cGUuIFRoZSBzcGVjIGlzIHNpbGVudCAoYXMgZmFyIGFzIGkgcmVj YWxsKSBvbiB3aGV0aGVyIGl0IGV4cHJlc3NlcyBpdC4NCg0KWW91IGNhbiBhbHNvIHRlbGwgdmlh IGlkIHdoaWNoIGlzIGxvY2FsIGFuZCAkcmVmIHBhdGggZ2l2ZW4ncyBzY2ltJ3Mgc3RyaWN0IHBh dGggcnVsZXMgKGxvb2sgYXQgdGhlIHBhcmVudCBvZiB0aGUgbGFzdCBzZWdtZW50KS4NCkZyb20g bXkgcmVjb2xsZWN0aW9uIHNvbWUgb2YgdGhlc2UgaXRlbXMgd2VyZSBub3QgdGhhdCBpbXBvcnRh bnQgZ2l2ZW4gc2NpbSB3YXMgcHJvdmlzaW9uaW5nIGFwaSBmb3IgYXBwcyAtIGFwcHMgaW1wbGVt ZW50aW5nIHNlcnZlciBzaWRlIGFyZSBmcmVlIHRvIGRvIHdoYXQgdGhleSBjYW4vd2FudC4gTm93 IHRoYXQgaXQgaXMgYmVpbmcgdXNlZCBhcyBkaXJlY3RvcnksIGNsb3Npbmcgc29tZSB1bnNwZWNp ZmllZCAvIGxvb3NlIGFyZWFzIG1pZ2h0IGJlIGJldHRlciBmb3IgaW50ZXJvcCBJTU8uDQoNClBo aWwNCg0KT24gQXVnIDksIDIwMTcsIGF0IDg6MzIgQU0sIEtlbGx5IEdyaXp6bGUgPGtlbGx5Lmdy aXp6bGVAc2FpbHBvaW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPj4g d3JvdGU6DQpHaXZlbiB0aGUgZ2VuZXJhbCBkZXNpcmUgZm9yIFNDSU0gdG8gYWxsb3cgbG9vc2Ug cmVhZGluZyBidXQgc3RyaWN0IHdyaXRpbmcsIEkgd291bGQgdm90ZSBmb3Igb3B0aW9uIDEuICBJ ZiB0eXBlIGlzIG5vdCBzcGVjaWZpZWQgaW4gYSBQVVQvUE9TVC9QQVRDSCB0aGVuIHRoZSBzZXJ2 ZXIgY2FuIGFzc3VtZSDigJxVc2Vy4oCdLg0KDQotLUtlbGx5DQoNCkZyb206IFNoZWxsZXkgW21h aWx0bzpyYW5kb21zaGVsbGV5QGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDks IDIwMTcgOTowMiBBTQ0KVG86IEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6bGVAc2FpbHBvaW50 LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPj4NCkNjOiBzY2ltQGlldGYu b3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzY2ltXSBHcm91cHMgTWVt YmVyIFR5cGUNCg0KUmVzdXJyZWN0aW5nIHRoaXMgb2xkIHRocmVhZCwgYXMgdGhpcyBxdWVzdGlv biBoYXMgcmVjZW50bHkgY29tZSB1cCBkdXJpbmcgc29tZSBvZiBvdXIgaW50ZXJvcGVyYWJpbGl0 eSB0ZXN0aW5nLCBhbmQgdGhlcmUgc3RpbGwgYXBwZWFycyB0byBiZSBzb21lIGFtYmlndWl0eSBp biB0aGUgc3BlYy4uLg0KDQpUaGUgU0NJTSAxLjEgYW5kIDIuMCBzcGVjaWZpY2F0aW9ucyBkbyBu b3Qgc2VlbSB0byBpbmRpY2F0ZSB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgaWYgdGhlIHR5cGUgc3Vi LWF0dHJpYnV0ZSBpcyBub3QgcHJvdmlkZWQgb24gYSBHcm91cCByZXNvdXJjZSBtZW1iZXIuIE5l aXRoZXIgc3BlYyBzZWVtcyB0byBleHBsaWNpdGx5IHJlcXVpcmUgdGhpcyBhdHRyaWJ1dGUsIHNv IHdoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGlmIG5vIHR5cGUgaXMgcHJvdmlkZWQ/IElz IHRoZXJlIGEgZGVmYXVsdCAoZS5nLiAiVXNlciIgb3IgIkdyb3VwIiksIG11c3QgU2VydmljZSBQ cm92aWRlcnMgc2VhcmNoIGZvciB0aGUgbWVtYmVyIGFjcm9zcyBhbGwgcmVzb3VyY2UgdHlwZXMs IG9yIHNob3VsZCBpdCBiZSB0cmVhdGVkIGFzIFJFUVVJUkVEIChlLmcuIHJldHVybmluZyBhIDQw MCBlcnJvcik/DQoNCg0KT24gTW9uLCBGZWIgMjUsIDIwMTMgYXQgMTA6MzggQU0sIFNoZWxsZXkg PHJhbmRvbXNoZWxsZXlAZ21haWwuY29tPG1haWx0bzpyYW5kb21zaGVsbGV5QGdtYWlsLmNvbT4+ IHdyb3RlOg0KVGhhbmtzLCBLZWxseS4gR2l2ZW4gdGhhdCB0aGUgSUQgbWF5IHJlcHJlc2VudCBl aXRoZXIgYSBVc2VyIG9yIEdyb3VwIGFuZCBvbmx5IHRoZSBjb21iaW5hdGlvbiBvZiAidHlwZSIg YW5kICJ2YWx1ZSIgdW5pcXVlbHkgaWRlbnRpZnkgdGhlIHJlZmVyZW5jZSwgc2hvdWxkIHRoZSBj YW5vbmljYWwgInR5cGUiIGF0dHJpYnV0ZSBmb3IgZ3JvdXAgbWVtYmVycyBiZSBSRVFVSVJFRCBh cyB3ZWxsPyAoRnVydGhlciwgdGhlIG1ham9yaXR5IG9mIGV4YW1wbGVzIHRocm91Z2hvdXQgdGhl IFByb3RvY29sIHNwZWNpZmljYXRpb24gb25seSBpbmNsdWRlIGEgInZhbHVlIiBhbmQgbm90ICJ0 eXBlIiwgc28gaXQncyBhbWJpZ3VvdXMgYXMgdG8gd2hldGhlciB0aGVzZSAidmFsdWVzIiByZXBy ZXNlbnQgVXNlcnMgb3IgR3JvdXBzLikNCg0KT24gTW9uLCBGZWIgMTEsIDIwMTMgYXQgNDowMiBQ TSwgS2VsbHkgR3JpenpsZSA8a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPG1haWx0bzprZWxs eS5ncml6emxlQHNhaWxwb2ludC5jb20+PiB3cm90ZToNCkkgb3BlbmVkIHRpY2tldCAjMzUgdG8g Y2hhbmdlIHRoaXMuDQoNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3NjaW0vdHJhYy90 aWNrZXQvMzU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAt M0FfX3RyYWMudG9vbHMuaWV0Zi5vcmdfd2dfc2NpbV90cmFjX3RpY2tldF8zNSZkPUR3TUdhUSZj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1 Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09blhqMXVMYkxvdnh4Q1ctVlBYMGQx Z2VXZ2hwYUFJWnRNWEtrUFl5QUNMbyZzPWF6TFNyWWxPQlJpU1daM0JpQTduRW5TdWp6ME9QQ2Vw MmJ4OFBlQWRvYkUmZT0+DQoNCi0tS2VsbHkNCg0KRnJvbTogc2NpbS1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86c2NpbS1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgU2hlbGxleQ0K U2VudDogTW9uZGF5LCBGZWJydWFyeSAxMSwgMjAxMyAxMTozNiBBTQ0KVG86IEtlbGx5IEdyaXp6 bGUNCkNjOiBzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtzY2ltXSBHcm91cHMgTWVtYmVyIFR5cGUNCg0KKzEgdG8gbWFyayBpdCBhcyAiaW1tdXRhYmxl Ii4NCk9uIE1vbiwgRmViIDQsIDIwMTMgYXQgODowOCBBTSwgS2VsbHkgR3JpenpsZSA8a2VsbHku Z3JpenpsZUBzYWlscG9pbnQuY29tPG1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20+ PiB3cm90ZToNCkdvb2QgcG9pbnQuICBJdCBzZWVtcyBsaWtlIHRoaXMgc2hvdWxkIHNheSDigJxp bW11dGFibGXigJ0gcmF0aGVyIHRoYW4g4oCccmVhZC1vbmx54oCdLCBzaW5jZSBpdCBjYW4gYmUg c2V0IGluaXRpYWxseSBidXQgbm90IHVwZGF0ZWQuICBUaG91Z2h0cyBmcm9tIGFueW9uZSBlbHNl PyAgSWYgdGhpcyBzZWVtcyByZWFzb25hYmxlIEnigJlsbCBvcGVuIGFuIGlzc3VlIHRvIGdldCB0 aGlzIGZpeGVkLg0KDQotLUtlbGx5DQoNCkZyb206IHNjaW0tYm91bmNlc0BpZXRmLm9yZzxtYWls dG86c2NpbS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFNoZWxsZXkNClNlbnQ6 IEZyaWRheSwgRmVicnVhcnkgMDEsIDIwMTMgMTozNyBQTQ0KVG86IHNjaW1AaWV0Zi5vcmc8bWFp bHRvOnNjaW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc2NpbV0gR3JvdXBzIE1lbWJlciBUeXBlDQoN CkFzIGluZGljYXRlZCBpbiBTZWN0aW9uIDgsIHRoZSBjYW5vbmljYWwgdHlwZXMgZm9yIEdyb3Vw IG1lbWJlcnMgYXJlIFJFQUQtT05MWS4gQXMgc3VjaCwgaG93IGNhbiBjb25zdW1lcnMgcHJvdmlk ZSB0aGUgdHlwZSAoaS5lLiAiVXNlciIgb3IgIkdyb3VwIik/IElzIGl0IGltcGxpZWQgdGhhdCBJ RHMgYXJlIHVuaXF1ZSBhY3Jvc3MgYm90aCB1c2VycyBhbmQgZ3JvdXBzIGluIG9yZGVyIGZvciBz ZXJ2aWNlIHByb3ZpZGVycyB0byBmdWxmaWxsIHRoaXMgcmVxdWlyZW1lbnQ/DQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2NpbSBtYWlsaW5n IGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX3NjaW0mZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NY NVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19s TElHayZtPW5YajF1TGJMb3Z4eENXLVZQWDBkMWdlV2docGFBSVp0TVhLa1BZeUFDTG8mcz1yQ1lf dHRCd3BzVGNHVlNzWlQyaHNMSFdQWEwxN2NXeUlCUzVXRFQ0b0RzJmU9DQoNCg== --_000_CY1PR04MB2363D27C3FCAE2AD9AFEDB61E28B0CY1PR04MB2363namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0 eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6NTc0Nzc3NTg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0y MDY5MTc0NzE2O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo3 NTY1NTU3MzM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04NDc0NzA3OTg7fQ0KQGxpc3QgbDE6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE2ODk1MjY5MzE7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjExNzc4NTgzMjg7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3VyIHBsYW4gc291bmRzIGdv b2QgdG8gbWUsIFNoZWxseS4mbmJzcDsgVGhhdOKAmXMgaG93IEkgd291bGQgaW1wbGVtZW50IGl0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gU2hlbGxleSBbbWFpbHRvOnJh bmRvbXNoZWxsZXlAZ21haWwuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1 c3QgOSwgMjAxNyAxOjQyIFBNPGJyPg0KPGI+VG86PC9iPiBQaGlsIEh1bnQgKElETSkgJmx0O3Bo aWwuaHVudEBvcmFjbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gS2VsbHkgR3JpenpsZSAmbHQ7 a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tJmd0Ozsgc2NpbUBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3NjaW1dIEdyb3VwcyBNZW1iZXIgVHlwZTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPllvdSBjYW4gYWxzbyB0ZWxsIHZpYSBpZCB3 aGljaCBpcyBsb2NhbCBhbmQgJHJlZiBwYXRoIGdpdmVuJ3Mgc2NpbSdzIHN0cmljdCBwYXRoIHJ1 bGVzIChsb29rIGF0IHRoZSBwYXJlbnQgb2YgdGhlIGxhc3Qgc2VnbWVudCkuDQo8L2k+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJcyB0 aGUgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5pZDwv c3Bhbj4gbm93IHJlcXVpcmVkIHRvIGJlIGdsb2JhbGx5IHVuaXF1ZSBhY3Jvc3MgYWxsIHJlc291 cmNlIHR5cGVzPyBJZiBub3QsIHRoZXJlIGlzIG5vDQo8aT5ndWFyYW50ZWUgPC9pPnRoYXQgYW4g U1AgY2FuIGRldGVybWluZSB0aGUgcmVzb3VyY2UgdHlwZSBmcm9tIHRoZSBpZC48bzpwPjwvbzpw PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPg0KVGhlIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+JHJlZjwvc3Bhbj4gaXMgYWxzbyBvcHRpb25hbCwgc28gdGhpcyBjYW5ub3Qg YmUgY29uc2lzdGVudGx5IHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSB0eXBlLiBGdXJ0aGVyLCBJIHdh cyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoZQ0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4kcmVmPC9zcGFuPiBpcyBwcmltYXJpbHkgdXNlZCBm b3IgU1BzIHRvIGNvbW11bmljYXRlIHRoZSByZXNvdXJjZSBsb2NhdGlvbiB0byBjb25zdW1lcnMs IHJhdGhlciB0aGFuIHZpY2UgdmVyc2EgKGkuZS4gaXQncyBlc3NlbnRpYWxseSBhDQo8aT5yZWFk LW9ubHk8L2k+IGF0dHJpYnV0ZSkuPG86cD48L286cD48L2xpPjwvdWw+DQo8cD5IZXJlIGlzIG15 IHRlbnRhdGl2ZSBwbGFuIGZvciBvdXIgU1AgaW1wbGVtZW50YXRpb24gZm9yIGV2YWx1YXRpbmcg PGI+PGk+Z3JvdXAgbWVtYmVyczwvaT48L2I+OjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzIiPg0KVHJlYXQgPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij52YWx1ZTwvc3Bhbj48L2I+IGFzIDxiPlJFUVVJUkVEPC9iPi4gV2hp bGUgdGhlDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzY0MyNwYWdl LTY5Ij5leGFtcGxlIFNDSU0gc2NoZW1hPC9hPiBkb2VzIG5vdCBhY3R1YWxseSByZXF1aXJlIHRo ZSBncm91cCBtZW1iZXINCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+dmFsdWU8L3NwYW4+IHN1Yi1hdHRyaWJ1dGUsIHRoaXMgaXMgdGhlIG1vc3QgY29u c2lzdGVudCBpZGVudGlmaWVyIGZvciByZWZlcnJpbmcgdG8gbWVtYmVycy48bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2 ZWwxIGxmbzIiPg0KVHJlYXQgPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4kcmVmPC9zcGFuPjwvYj4gYXMgPGI+UkVBRC1PTkxZPC9iPiAoaS5lLiBp Z25vcmUgaXQgY29tcGxldGVseSB3aGVuIHByb2Nlc3NpbmcgcmVxdWVzdHMpLiBVc2luZyBhDQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiRyZWY8L3Nw YW4+IHByb3ZpZGVkIGJ5IGNvbnN1bWVycyBzZWVtcyBhIGJpdCBmcmFnaWxlIChhc2lkZSBmcm9t IGVsaW1pbmF0aW5nIHRoZSBjb21wbGV4aXR5IG9mIFVSSSBjb21wYXJpc29uLCBpdCdzIHBvc3Np YmxlIHRoYXQgYSBzaW5nbGUgcmVzb3VyY2UgbWF5IGhhdmUgbXVsdGlwbGUgRE5TIG5hbWVzLCB3 aGljaCBmdXJ0aGVyIGNvbXBsaWNhdGVzIGFic29sdXRlIFVSSQ0KIGNvbXBhcmlzb25zIGFuZCBp bnRlZ3JpdHkpLCBhbmQgaW50cm9kdWNlcyByZWR1bmRhbmN5IChhbmQgcG90ZW50aWFsIGFtYmln dWl0eSkgd2l0aA0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij52YWx1ZS90eXBlPC9zcGFuPi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KVHJlYXQgPGI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij50eXBlPC9z cGFuPiA8L2I+YXMgPGI+T1BUSU9OQUw8L2I+LiBNeQ0KPGk+cHJlZmVyZW5jZSA8L2k+d291bGQg YmUgdG8gdHJlYXQgdGhpcyBhcyBSRVFVSVJFRCBpbiBvcmRlciB0byBlbGltaW5hdGUgYW55IGFt YmlndWl0eSwgYnV0IGdpdmVuIHRoYXQgdGhlIFNDSU0gc3BlY3MgZG9uJ3QgcmVxdWlyZSBpdCwg ZG9pbmcgdGhpcyB3b3VsZCBsaW1pdCBpbnRlcm9wZXJhYmlsaXR5IGZvciBjb25zdW1lcnMgdGhh dCBtYXkgbm90IGJlIHNlbmRpbmcgaXQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCklmIDxiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+dHlwZTwvc3Bh bj4gPC9iPmlzIG5vdCBwcm92aWRlZCwgYXNzdW1lIHRoZQ0KPGI+ZGVmYXVsdCB2YWx1ZSBpcyA8 L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m cXVvdDtVc2VyJnF1b3Q7PC9zcGFuPjwvYj4uPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NClBlcmZv cm0gPGI+cmVmZXJlbnRpYWwgaW50ZWdyaXR5IDwvYj50byBlbnN1cmUgdGhhdCBhbnkgcHJvdmlk ZWQgZ3JvdXAgbWVtYmVyIHJlc291cmNlcyBleGlzdCwgYmFzZWQgb24NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+dmFsdWU8L3NwYW4+IGFuZCA8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KdHlwZTwvc3Bh bj4uPG86cD48L286cD48L2xpPjwvdWw+DQo8cD48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEz LjVwdCI+RXhhbXBsZXM8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHA+R2l2ZW4gdGhlIGV4 aXN0ZW5jZSBvZiB0aGUgZm9sbG93aW5nIHJlc291cmNlcywgaGVyZSBhcmUgc29tZSBleGFtcGxl IHJlcXVlc3RzL3Jlc3BvbnNlcyBiYXNlZCBvbiB0aGlzIHByb3Bvc2FsOjxvOnA+PC9vOnA+PC9w Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4uLi9Vc2Vycy9hYmM8L3NwYW4+PG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVs MSBsZm8zIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Li4vR3JvdXBzL3h5ejwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8dGFibGUgY2xh c3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGlu Zz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpjb2xsYXBzZTtib3JkZXItY29sb3I6Y3VycmVu dGNvbG9yIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjIyLjVwdCI+DQo8dGQgdmFsaWdu PSJ0b3AiIHN0eWxlPSJib3JkZXI6c29saWQgI0I3QjdCNyAxLjBwdDtwYWRkaW5nOjUuMHB0IDUu MHB0IDUuMHB0IDUuMHB0O2hlaWdodDoyMi41cHQiPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Hcm91cCBN ZW1iZXJzPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3Ai IHN0eWxlPSJib3JkZXI6c29saWQgI0I3QjdCNyAxLjBwdDtib3JkZXItbGVmdDpub25lO3BhZGRp bmc6NS4wcHQgNS4wcHQgNS4wcHQgNS4wcHQ7aGVpZ2h0OjIyLjVwdCI+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPlJlc3BvbnNlPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRy IHN0eWxlPSJoZWlnaHQ6MTAwLjVwdCI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6 c29saWQgI0I3QjdCNyAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzo1LjBwdCA1LjBwdCA1 LjBwdCA1LjBwdDtoZWlnaHQ6MTAwLjVwdCI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZxdW90O21lbWJlcnMmcXVvdDs6IFs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3ZhbHVlJnF1 b3Q7OiAmcXVvdDthYmMmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmcXVvdDt0eXBlJnF1b3Q7OiAmcXVvdDtVc2VyJnF1b3Q7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsgfSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyB7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDt2YWx1ZSZxdW90OzogJnF1b3Q7eHl6 JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7 dHlwZSZxdW90OzogJnF1b3Q7R3JvdXAmcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyB9 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5dPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBy b3dzcGFuPSIzIiB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlci10b3A6bm9uZTtib3JkZXItbGVm dDpub25lO2JvcmRlci1ib3R0b206c29saWQgI0I3QjdCNyAxLjBwdDtib3JkZXItcmlnaHQ6c29s aWQgI0I3QjdCNyAxLjBwdDtwYWRkaW5nOjUuMHB0IDUuMHB0IDUuMHB0IDUuMHB0O2hlaWdodDox MDAuNXB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMzg3NjFEIj4yeHg8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiAtIFN1Y2Nlc3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90 cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjkxLjVwdCI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJi b3JkZXI6c29saWQgI0I3QjdCNyAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzo1LjBwdCA1 LjBwdCA1LjBwdCA1LjBwdDtoZWlnaHQ6OTEuNXB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JnF1b3Q7bWVtYmVycyZxdW90OzogWzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyAmcXVvdDt2YWx1ZSZxdW90OzogJnF1b3Q7YWJjJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsgfSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyB7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7dmFsdWUmcXVvdDs6ICZxdW90O3h5eiZxdW90Oyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7dHlwZSZxdW90OzogJnF1b3Q7 R3JvdXAmcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5dPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdo dDoxMDkuNXB0Ij4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQjdCN0I3 IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjUuMHB0IDUuMHB0IDUuMHB0IDUuMHB0O2hl aWdodDoxMDkuNXB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+JnF1b3Q7bWVtYmVycyZxdW90OzogWzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDt2YWx1ZSZx dW90OzogJnF1b3Q7YWJjJnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAm cXVvdDskcmVmJnF1b3Q7OiAmcXVvdDthbnl0aGluZyBhdCBhbGwmcXVvdDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyB9LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IHs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDt2YWx1ZSZxdW90OzogJnF1b3Q7eHl6JnF1 b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmcXVvdDt0eXBlJnF1b3Q7OiAm cXVvdDtHcm91cCZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7 JHJlZiZxdW90OzogJnF1b3Q7YW55dGhpbmcgYXQgYWxsJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6NTUuNXB0Ij4NCjx0ZCB2YWxpZ249InRvcCIg c3R5bGU9ImJvcmRlcjpzb2xpZCAjQjdCN0I3IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5n OjUuMHB0IDUuMHB0IDUuMHB0IDUuMHB0O2hlaWdodDo1NS41cHQiPg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDttZW1iZXJzJnF1b3Q7 OiBbPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90O3ZhbHVlJnF1b3Q7OiAmcXVvdDt4eXomcXVvdDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5dPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjx0ZCByb3dzcGFuPSIyIiB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlci10 b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgI0I3QjdCNyAxLjBw dDtib3JkZXItcmlnaHQ6c29saWQgI0I3QjdCNyAxLjBwdDtwYWRkaW5nOjUuMHB0IDUuMHB0IDUu MHB0IDUuMHB0O2hlaWdodDo1NS41cHQiPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPjQwMA0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LSBNaXNz aW5nIOKAnEdyb3Vw4oCdICZxdW90O3R5cGUmcXVvdDsgb24gbmVzdGVkIGdyb3VwIG1lbWJlciBk ZWZpbml0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9 ImhlaWdodDo2NC41cHQiPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOnNvbGlkICNC N0I3QjcgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6NS4wcHQgNS4wcHQgNS4wcHQgNS4w cHQ7aGVpZ2h0OjY0LjVwdCI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZxdW90O21lbWJlcnMmcXVvdDs6IFs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7dmFs dWUmcXVvdDs6ICZxdW90O3h5eiZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNw OyAmcXVvdDskcmVmJnF1b3Q7OiAmcXVvdDsuLi9Hcm91cHMveHl6JnF1b3Q7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6NTUuNXB0Ij4NCjx0ZCB2YWxpZ249 InRvcCIgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQjdCN0I3IDEuMHB0O2JvcmRlci10b3A6bm9uZTtw YWRkaW5nOjUuMHB0IDUuMHB0IDUuMHB0IDUuMHB0O2hlaWdodDo1NS41cHQiPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDttZW1iZXJz JnF1b3Q7OiBbPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgezwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OyRyZWYmcXVvdDs6ICZxdW90Oy4uL1VzZXJzL2FiYyZx dW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl08L3Nw YW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHJvd3NwYW49IjIiIHZhbGlnbj0idG9wIiBz dHlsZT0iYm9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xp ZCAjQjdCN0I3IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCAjQjdCN0I3IDEuMHB0O3BhZGRpbmc6 NS4wcHQgNS4wcHQgNS4wcHQgNS4wcHQ7aGVpZ2h0OjU1LjVwdCI+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnJlZCI+NDAwDQo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4tIE1pc3NpbmcgJnF1b3Q7dmFsdWUmcXVvdDsgb24gZ3JvdXAgbWVtYmVyIGRlZmlu aXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVp Z2h0OjU1LjVwdCI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6c29saWQgI0I3QjdC NyAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzo1LjBwdCA1LjBwdCA1LjBwdCA1LjBwdDto ZWlnaHQ6NTUuNXB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+JnF1b3Q7bWVtYmVycyZxdW90OzogWzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDskcmVmJnF1 b3Q7OiAmcXVvdDsuLi9Hcm91cHMveHl6JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsg fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+XTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6NjQuNXB0Ij4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJv cmRlcjpzb2xpZCAjQjdCN0I3IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjUuMHB0IDUu MHB0IDUuMHB0IDUuMHB0O2hlaWdodDo2NC41cHQiPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDttZW1iZXJzJnF1b3Q7OiBbPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZxdW90O3ZhbHVlJnF1b3Q7OiAmcXVvdDthYmMmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsgJm5ic3A7ICZxdW90O3R5cGUmcXVvdDs6ICZxdW90O0dyb3VwJnF1b3Q7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8dGQgcm93c3Bhbj0iMiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3Jk ZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICNCN0I3Qjcg MS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICNCN0I3QjcgMS4wcHQ7cGFkZGluZzo1LjBwdCA1LjBw dCA1LjBwdCA1LjBwdDtoZWlnaHQ6NjQuNXB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPjQwMA0KPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4tIFdyb25nICZxdW90O3R5cGUmcXVvdDsg cHJvdmlkZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0i aGVpZ2h0OjY0LjVwdCI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6c29saWQgI0I3 QjdCNyAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzo1LjBwdCA1LjBwdCA1LjBwdCA1LjBw dDtoZWlnaHQ6NjQuNXB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+JnF1b3Q7bWVtYmVycyZxdW90OzogWzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDt2YWx1 ZSZxdW90OzogJnF1b3Q7eHl6JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNw OyAmcXVvdDt0eXBlJnF1b3Q7OiAmcXVvdDtVc2VyJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6NTUuNXB0Ij4NCjx0ZCB2YWxpZ249InRvcCIgc3R5 bGU9ImJvcmRlcjpzb2xpZCAjQjdCN0I3IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjUu MHB0IDUuMHB0IDUuMHB0IDUuMHB0O2hlaWdodDo1NS41cHQiPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDttZW1iZXJzJnF1b3Q7OiBb PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90O3ZhbHVlJnF1b3Q7OiAmcXVvdDthYmMmcXVvdDssPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZxdW90O3R5cGUmcXVvdDs6ICZxdW90O1Vuc3VwcG9ydGVk VHlwZSZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pl08L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0i Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjQjdC N0I3IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCAjQjdCN0I3IDEuMHB0O3BhZGRpbmc6NS4wcHQg NS4wcHQgNS4wcHQgNS4wcHQ7aGVpZ2h0OjU1LjVwdCI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkIj40MDANCjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LSBVbnN1cHBvcnRlZCAmcXVvdDt0 eXBlJnF1b3Q7IHByb3ZpZGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 dHIgc3R5bGU9ImhlaWdodDo1NS41cHQiPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYm9yZGVy OnNvbGlkICNCN0I3QjcgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6NS4wcHQgNS4wcHQg NS4wcHQgNS4wcHQ7aGVpZ2h0OjU1LjVwdCI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZxdW90O21lbWJlcnMmcXVvdDs6IFs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsg JnF1b3Q7dmFsdWUmcXVvdDs6ICZxdW90O25vIHN1Y2ggcmVzb3VyY2Ugd2l0aCBvciB3aXRob3V0 IHR5cGUmcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5dPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9 ImJvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgI0I3 QjdCNyAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgI0I3QjdCNyAxLjBwdDtwYWRkaW5nOjUuMHB0 IDUuMHB0IDUuMHB0IDUuMHB0O2hlaWdodDo1NS41cHQiPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnJlZCI+NDAwDQo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPi0gTWVtYmVyIGRvZXMgbm90IGV4 aXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJs ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEF1ZyA5LCAyMDE3IGF0IDExOjA2 IEFNLCBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGFncmVlIHRoZSBzZXJ2ZXIgY2FuIGRlY2lkZS4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8yNDIwNjc2MDkyOTMyNzU5Mjk4QXBwbGVNYWls U2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzI0MjA2NzYwOTI5MzI3NTkyOThBcHBsZU1haWxTaWdu YXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1PIHRoZSBzZXJ2ZXIgc2hvdWxkIGNoZWNr IHJlZmVyZW50aWFsIGludGVncml0eS4gQnkgZG9pbmcgc28gaXQgd291bGQgbGlrZWx5IGtub3cg dGhlIHR5cGUuIFRoZSBzcGVjIGlzIHNpbGVudCAoYXMgZmFyIGFzIGkgcmVjYWxsKSBvbiB3aGV0 aGVyIGl0IGV4cHJlc3NlcyBpdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBp ZD0iZ21haWwtbV8yNDIwNjc2MDkyOTMyNzU5Mjk4QXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJn bWFpbC1tXzI0MjA2NzYwOTI5MzI3NTkyOThBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Zb3UgY2FuIGFsc28gdGVs bCB2aWEgaWQgd2hpY2ggaXMgbG9jYWwgYW5kICRyZWYgcGF0aCBnaXZlbidzIHNjaW0ncyBzdHJp Y3QgcGF0aCBydWxlcyAobG9vayBhdCB0aGUgcGFyZW50IG9mIHRoZSBsYXN0IHNlZ21lbnQpLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzI0MjA2NzYwOTI5 MzI3NTkyOThBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJvbSBt eSByZWNvbGxlY3Rpb24gc29tZSBvZiB0aGVzZSBpdGVtcyB3ZXJlIG5vdCB0aGF0IGltcG9ydGFu dCBnaXZlbiBzY2ltIHdhcyBwcm92aXNpb25pbmcgYXBpIGZvciBhcHBzIC0gYXBwcyBpbXBsZW1l bnRpbmcgc2VydmVyIHNpZGUgYXJlIGZyZWUgdG8gZG8gd2hhdCB0aGV5IGNhbi93YW50LiBOb3cg dGhhdCBpdCBpcyBiZWluZyB1c2VkIGFzIGRpcmVjdG9yeSwgY2xvc2luZyBzb21lIHVuc3BlY2lm aWVkDQogLyBsb29zZSBhcmVhcyBtaWdodCBiZSBiZXR0ZXIgZm9yIGludGVyb3AgSU1PLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzI0MjA2NzYwOTI5MzI3 NTkyOThBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUGhp bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEF1ZyA5LCAy MDE3LCBhdCA4OjMyIEFNLCBLZWxseSBHcml6emxlICZsdDs8YSBocmVmPSJtYWlsdG86a2VsbHku Z3JpenpsZUBzYWlscG9pbnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2VsbHkuZ3JpenpsZUBzYWls cG9pbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkdpdmVuIHRoZSBnZW5lcmFsIGRlc2lyZSBm b3IgU0NJTSB0byBhbGxvdyBsb29zZSByZWFkaW5nIGJ1dCBzdHJpY3Qgd3JpdGluZywgSSB3b3Vs ZCB2b3RlIGZvciBvcHRpb24gMS4mbmJzcDsgSWYgdHlwZSBpcyBub3Qgc3BlY2lmaWVkIGluIGEg UFVUL1BPU1QvUEFUQ0ggdGhlbiB0aGUgc2VydmVyIGNhbiBhc3N1bWUNCiDigJxVc2Vy4oCdLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS1LZWxseTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+RnJvbTo8L2I+IFNoZWxsZXkgWzxhIGhyZWY9Im1haWx0bzpyYW5kb21zaGVsbGV5 QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpyYW5kb21zaGVsbGV5QGdtYWlsLmNv bTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgOSwgMjAxNyA5OjAy IEFNPGJyPg0KPGI+VG86PC9iPiBLZWxseSBHcml6emxlICZsdDs8YSBocmVmPSJtYWlsdG86a2Vs bHkuZ3JpenpsZUBzYWlscG9pbnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2VsbHkuZ3JpenpsZUBz YWlscG9pbnQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzY2lt QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtzY2ltXSBHcm91cHMgTWVtYmVyIFR5cGU8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48aT5SZXN1cnJlY3RpbmcgdGhpcyBvbGQgdGhyZWFkLCBhcyB0aGlz IHF1ZXN0aW9uIGhhcyByZWNlbnRseSBjb21lIHVwIGR1cmluZyBzb21lIG9mIG91ciBpbnRlcm9w ZXJhYmlsaXR5IHRlc3RpbmcsIGFuZCB0aGVyZSBzdGlsbCBhcHBlYXJzIHRvIGJlIHNvbWUgYW1i aWd1aXR5IGluIHRoZSBzcGVjLi4uPC9pPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGJyPg0KVGhlIFNDSU0gMS4xIGFuZCAyLjAgc3BlY2lmaWNhdGlvbnMg ZG8gbm90IHNlZW0gdG8gaW5kaWNhdGUgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGlmIHRoZQ0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij50eXBlPC9zcGFu PiBzdWItYXR0cmlidXRlIGlzIG5vdCBwcm92aWRlZCBvbiBhDQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkdyb3VwPC9zcGFuPiByZXNvdXJjZSA8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KbWVtYmVyPC9z cGFuPi4gTmVpdGhlciBzcGVjIHNlZW1zIHRvIGV4cGxpY2l0bHkgcmVxdWlyZSB0aGlzIGF0dHJp YnV0ZSwgc28gd2hhdCBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgaWYgbm8NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+dHlwZTwvc3Bhbj4gaXMgcHJv dmlkZWQ/IElzIHRoZXJlIGEgZGVmYXVsdCAoZS5nLiAmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlVzZXI8L3NwYW4+JnF1b3Q7IG9yICZxdW90 OzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+R3JvdXA8 L3NwYW4+JnF1b3Q7KSwgbXVzdCBTZXJ2aWNlIFByb3ZpZGVycyBzZWFyY2ggZm9yIHRoZSBtZW1i ZXIgYWNyb3NzDQo8aT5hbGwgPC9pPnJlc291cmNlIHR5cGVzLCBvciBzaG91bGQgaXQgYmUgdHJl YXRlZCBhcyBSRVFVSVJFRCAoZS5nLiByZXR1cm5pbmcgYSA8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KNDAwPC9zcGFuPiBlcnJvcik/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g TW9uLCBGZWIgMjUsIDIwMTMgYXQgMTA6MzggQU0sIFNoZWxsZXkgJmx0OzxhIGhyZWY9Im1haWx0 bzpyYW5kb21zaGVsbGV5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJhbmRvbXNoZWxsZXlA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29s b3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciByZ2IoMjA0LDIwNCwyMDQpIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGhhbmtzLCBLZWxseS4gR2l2ZW4gdGhhdCB0aGUgSUQgbWF5IHJlcHJl c2VudCBlaXRoZXIgYSBVc2VyIG9yIEdyb3VwIGFuZCBvbmx5IHRoZSBjb21iaW5hdGlvbiBvZiAm cXVvdDt0eXBlJnF1b3Q7IGFuZCAmcXVvdDt2YWx1ZSZxdW90OyB1bmlxdWVseSBpZGVudGlmeSB0 aGUgcmVmZXJlbmNlLCBzaG91bGQgdGhlIGNhbm9uaWNhbCAmcXVvdDt0eXBlJnF1b3Q7DQogYXR0 cmlidXRlIGZvciBncm91cCBtZW1iZXJzIGJlIFJFUVVJUkVEIGFzIHdlbGw/IChGdXJ0aGVyLCB0 aGUgbWFqb3JpdHkgb2YgZXhhbXBsZXMgdGhyb3VnaG91dCB0aGUgUHJvdG9jb2wgc3BlY2lmaWNh dGlvbiBvbmx5IGluY2x1ZGUgYSAmcXVvdDt2YWx1ZSZxdW90OyBhbmQgbm90ICZxdW90O3R5cGUm cXVvdDssIHNvIGl0J3MgYW1iaWd1b3VzIGFzIHRvIHdoZXRoZXIgdGhlc2UgJnF1b3Q7dmFsdWVz JnF1b3Q7IHJlcHJlc2VudCBVc2VycyBvciBHcm91cHMuKTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBGZWIgMTEsIDIwMTMgYXQgNDowMiBQTSwgS2Vs bHkgR3JpenpsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJy ZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgb3BlbmVkIHRpY2tldCAjMzUg dG8gY2hhbmdlIHRoaXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAt M0FfX3RyYWMudG9vbHMuaWV0Zi5vcmdfd2dfc2NpbV90cmFjX3RpY2tldF8zNSZhbXA7ZD1Ed01H YVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7 cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPW5YajF1 TGJMb3Z4eENXLVZQWDBkMWdlV2docGFBSVp0TVhLa1BZeUFDTG8mYW1wO3M9YXpMU3JZbE9CUmlT V1ozQmlBN25FblN1anowT1BDZXAyYng4UGVBZG9iRSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9zY2ltL3RyYWMvdGlja2V0LzM1PC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi0tS2VsbHk8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPGEg aHJlZj0ibWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW0t Ym91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86c2NpbS1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+U2hlbGxleTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1 YXJ5IDExLCAyMDEzIDExOjM2IEFNPGJyPg0KPGI+VG86PC9iPiBLZWxseSBHcml6emxlPGJyPg0K PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2NpbV0gR3JvdXBz IE1lbWJlciBUeXBlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4m IzQzOzEgdG8gbWFyayBpdCBhcyAmcXVvdDtpbW11dGFibGUmcXVvdDsuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIEZlYiA0LCAyMDEzIGF0IDg6 MDggQU0sIEtlbGx5IEdyaXp6bGUgJmx0OzxhIGhyZWY9Im1haWx0bzprZWxseS5ncml6emxlQHNh aWxwb2ludC5jb20iIHRhcmdldD0iX2JsYW5rIj5rZWxseS5ncml6emxlQHNhaWxwb2ludC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R29vZCBwb2ludC4mbmJzcDsg SXQgc2VlbXMgbGlrZSB0aGlzIHNob3VsZCBzYXkg4oCcaW1tdXRhYmxl4oCdIHJhdGhlciB0aGFu IOKAnHJlYWQtb25seeKAnSwgc2luY2UgaXQgY2FuIGJlIHNldCBpbml0aWFsbHkgYnV0IG5vdCB1 cGRhdGVkLiZuYnNwOyBUaG91Z2h0cyBmcm9tIGFueW9uZQ0KIGVsc2U/Jm5ic3A7IElmIHRoaXMg c2VlbXMgcmVhc29uYWJsZSBJ4oCZbGwgb3BlbiBhbiBpc3N1ZSB0byBnZXQgdGhpcyBmaXhlZC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tLUtlbGx5PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4N CjxhIGhyZWY9Im1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5z Y2ltLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNjaW0tYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW0tYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlNoZWxsZXk8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBG ZWJydWFyeSAwMSwgMjAxMyAxOjM3IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86 c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFtzY2ltXSBHcm91cHMgTWVtYmVyIFR5cGU8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgaW5kaWNhdGVkIGluIFNlY3Rpb24gOCwgdGhlIGNh bm9uaWNhbCB0eXBlcyBmb3IgR3JvdXAgbWVtYmVycyBhcmUgUkVBRC1PTkxZLiBBcyBzdWNoLCBo b3cgY2FuIGNvbnN1bWVycyBwcm92aWRlIHRoZSB0eXBlIChpLmUuICZxdW90O1VzZXImcXVvdDsg b3IgJnF1b3Q7R3JvdXAmcXVvdDspPyBJcyBpdCBpbXBsaWVkIHRoYXQgSURzIGFyZQ0KIHVuaXF1 ZSBhY3Jvc3MgYm90aCB1c2VycyBhbmQgZ3JvdXBzIGluIG9yZGVyIGZvciBzZXJ2aWNlIHByb3Zp ZGVycyB0byBmdWxmaWxsIHRoaXMgcmVxdWlyZW1lbnQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzY2lt IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX3NjaW0mYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFj eEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empX d2xOS2U0Q19sTElHayZhbXA7bT1uWGoxdUxiTG92eHhDVy1WUFgwZDFnZVdnaHBhQUladE1YS2tQ WXlBQ0xvJmFtcDtzPXJDWV90dEJ3cHNUY0dWU3NaVDJoc0xIV1BYTDE3Y1d5SUJTNVdEVDRvRHMm YW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19zY2ltJmFt cDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1Ni SzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1w O209blhqMXVMYkxvdnh4Q1ctVlBYMGQxZ2VXZ2hwYUFJWnRNWEtrUFl5QUNMbyZhbXA7cz1yQ1lf dHRCd3BzVGNHVlNzWlQyaHNMSFdQWEwxN2NXeUlCUzVXRFQ0b0RzJmFtcDtlPTwvYT4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR04MB2363D27C3FCAE2AD9AFEDB61E28B0CY1PR04MB2363namp_-- From nobody Wed Aug 9 14:59:39 2017 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 56C7213228D for ; Wed, 9 Aug 2017 14:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XZUWkhlT4MGG for ; Wed, 9 Aug 2017 14:59:33 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 223A4132195 for ; Wed, 9 Aug 2017 14:59:33 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id w45so34027178uac.5 for ; Wed, 09 Aug 2017 14:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xlsa3v9VONOjIv/Dg8LRkwgDLP3oh81TC5o7OhQoUmE=; b=jBvU0fmtvdTj0xkgjCrscMGW9siJ5BeQHsu1Z6azwIi4z3av82hpWBZyP3+BT6pRGi cNpEscdHaLrDACEktGAOn71/WC9oAG9dMt56HHICZzbwl4eE3FBu0giwzr3xtnfJQ6C5 gk8IUdTVKGE+OgdGD20Q4cY4/f3buOiyN7appH0k/+KO58UlIsTTmPz+ItE3HCwV2I3b FXgf5IOPt8QFRKX7VBH9elrtU/NRT3aUGyzDmAEHUD5Rpy5VfrKyGw/E1KrpYI17Bjtl YU1foWsd8lguOHhnf4wrN6OW/dTTFBe4oMH2ivO2kFtFpDSYMOuPRAkw4N6pTYHzdbRy Co3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xlsa3v9VONOjIv/Dg8LRkwgDLP3oh81TC5o7OhQoUmE=; b=OQjyhHIZGo8DMVHP5gRPZR+93cPhl0uOCk89JF5J8//1T1OUmIafWuR4e8QE3WZAdr ew7LDOD/C9HhQD3k0u4DHjg8aeo6aXX5CMhAF1AZ2PT7JJBeAZGtJ5hQEm+AWJnD2VnO YXxgzB6lwsbp21JIqXWGOt1JbQ37o1Tc+e1rgz2HbhVUYDeYTWp+lAoXxPLOIZPetRsE zb4zavf46fc1oISneQtEfQOBbfA/m3jrXlYusVaDY4UbnBXYp+hhmH66AX2FqKSnWCMJ ZDwtZV76/eTUBD/JSos7A4Ttn4JacB/Yg+18qKwuKuMG0zjWQjeaP4WMxR9dYKb5dRT3 exoA== X-Gm-Message-State: AHYfb5hpb+cGmcAhumnRkLwatk/8foVYiQYV6g+BFhR5YfkNVUl8k+3o QwUFK7gYPG/2pn6MBXiLP1vy0Iqg5w== X-Received: by 10.159.53.36 with SMTP id o33mr7212980uao.95.1502315972205; Wed, 09 Aug 2017 14:59:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.197.135 with HTTP; Wed, 9 Aug 2017 14:59:31 -0700 (PDT) In-Reply-To: References: <56C3C758F9D6534CA3778EAA1E0C343753AB2F38@BLUPRD0412MB643.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343753AC4630@BLUPRD0412MB643.namprd04.prod.outlook.com> From: Shelley Date: Wed, 9 Aug 2017 16:59:31 -0500 Message-ID: To: Kelly Grizzle Cc: "Phil Hunt (IDM)" , "scim@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c03ce80dd2006055659313e" Archived-At: Subject: Re: [scim] Groups Member Type X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 21:59:37 -0000 --94eb2c03ce80dd2006055659313e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the feedback. *Now that it is being used as directory, closing some unspecified / loose > areas might be better for interop IMO. * > Is it possible to fold some of these clarifications into the next SCIM RFC? On Wed, Aug 9, 2017 at 4:45 PM, Kelly Grizzle wrote: > Your plan sounds good to me, Shelly. That=E2=80=99s how I would implemen= t it. > > > > *From:* Shelley [mailto:randomshelley@gmail.com] > *Sent:* Wednesday, August 9, 2017 1:42 PM > *To:* Phil Hunt (IDM) > *Cc:* Kelly Grizzle ; scim@ietf.org > > *Subject:* Re: [scim] Groups Member Type > > > > *You can also tell via id which is local and $ref path given's scim's > strict path rules (look at the parent of the last segment). * > > > - Is the id now required to be globally unique across all resource > types? If not, there is no *guarantee *that an SP can determine the > resource type from the id. > - The $ref is also optional, so this cannot be consistently used to > determine the type. Further, I was under the impression that the $ref > is primarily used for SPs to communicate the resource location to > consumers, rather than vice versa (i.e. it's essentially a *read-only* > attribute). > > Here is my tentative plan for our SP implementation for evaluating *group > members*: > > - Treat *value* as *REQUIRED*. While the example SCIM schema > does not actually > require the group member value sub-attribute, this is the most > consistent identifier for referring to members. > - Treat *$ref* as *READ-ONLY* (i.e. ignore it completely when > processing requests). Using a $ref provided by consumers seems a bit > fragile (aside from eliminating the complexity of URI comparison, it's > possible that a single resource may have multiple DNS names, which fur= ther > complicates absolute URI comparisons and integrity), and introduces > redundancy (and potential ambiguity) with value/type. > - Treat *type *as *OPTIONAL*. My *preference *would be to treat this > as REQUIRED in order to eliminate any ambiguity, but given that the SC= IM > specs don't require it, doing this would limit interoperability for > consumers that may not be sending it. > - If *type *is not provided, assume the *default value is **"User"*. > - Perform *referential integrity *to ensure that any provided group > member resources exist, based on value and type. > > *Examples* > > Given the existence of the following resources, here are some example > requests/responses based on this proposal: > > - ../Users/abc > - ../Groups/xyz > > > > *Group Members* > > *Response* > > "members": [ > > { > "value": "abc", > > "type": "User" > > }, > > { > > "value": "xyz", > > "type": "Group" > > } > > ] > > *2xx* - Success > > "members": [ > > { > > "value": "abc" > > }, > > { > > "value": "xyz", > > "type": "Group" > > } > > ] > > "members": [ > > { > > "value": "abc", > > "$ref": "anything at all" > > }, > > { > > "value": "xyz", > > "type": "Group", > > "$ref": "anything at all" > > } > > ] > > "members": [ > > { > > "value": "xyz" > > } > > ] > > *400 *- Missing =E2=80=9CGroup=E2=80=9D "type" on nested group member def= inition > > "members": [ > > { > > "value": "xyz" > > "$ref": "../Groups/xyz" > > } > > ] > > "members": [ > > { > > "$ref": "../Users/abc" > > } > > ] > > *400 *- Missing "value" on group member definition > > "members": [ > > { > > "$ref": "../Groups/xyz" > > } > > ] > > "members": [ > > { > > "value": "abc", > > "type": "Group" > > } > > ] > > *400 *- Wrong "type" provided > > "members": [ > > { > > "value": "xyz", > > "type": "User" > > } > > ] > > "members": [ > > { > > "value": "abc", > > "type": "UnsupportedType" > > } > > ] > > *400 *- Unsupported "type" provided > > "members": [ > > { > > "value": "no such resource with or without type" > > } > > ] > > *400 *- Member does not exist > > > > > > On Wed, Aug 9, 2017 at 11:06 AM, Phil Hunt (IDM) > wrote: > > I agree the server can decide. > > > > IMO the server should check referential integrity. By doing so it would > likely know the type. The spec is silent (as far as i recall) on whether = it > expresses it. > > > > You can also tell via id which is local and $ref path given's scim's > strict path rules (look at the parent of the last segment). > > From my recollection some of these items were not that important given > scim was provisioning api for apps - apps implementing server side are fr= ee > to do what they can/want. Now that it is being used as directory, closing > some unspecified / loose areas might be better for interop IMO. > > > Phil > > > On Aug 9, 2017, at 8:32 AM, Kelly Grizzle > wrote: > > Given the general desire for SCIM to allow loose reading but strict > writing, I would vote for option 1. If type is not specified in a > PUT/POST/PATCH then the server can assume =E2=80=9CUser=E2=80=9D. > > > > --Kelly > > > > *From:* Shelley [mailto:randomshelley@gmail.com = ] > > *Sent:* Wednesday, August 9, 2017 9:02 AM > *To:* Kelly Grizzle > *Cc:* scim@ietf.org > *Subject:* Re: [scim] Groups Member Type > > > > *Resurrecting this old thread, as this question has recently come up > during some of our interoperability testing, and there still appears to b= e > some ambiguity in the spec...* > > > The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected > behavior if the type sub-attribute is not provided on a Group resource > member. Neither spec seems to explicitly require this attribute, so what > is the expected behavior if no type is provided? Is there a default (e.g. > "User" or "Group"), must Service Providers search for the member across *= all > *resource types, or should it be treated as REQUIRED (e.g. returning a 40= 0 > error)? > > > > > > On Mon, Feb 25, 2013 at 10:38 AM, Shelley wrote= : > > Thanks, Kelly. Given that the ID may represent either a User or Group and > only the combination of "type" and "value" uniquely identify the referenc= e, > should the canonical "type" attribute for group members be REQUIRED as > well? (Further, the majority of examples throughout the Protocol > specification only include a "value" and not "type", so it's ambiguous as > to whether these "values" represent Users or Groups.) > > > > On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle < > kelly.grizzle@sailpoint.com> wrote: > > I opened ticket #35 to change this. > > > > http://trac.tools.ietf.org/wg/scim/trac/ticket/35 > > > > > --Kelly > > > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Shelley > *Sent:* Monday, February 11, 2013 11:36 AM > *To:* Kelly Grizzle > *Cc:* scim@ietf.org > *Subject:* Re: [scim] Groups Member Type > > > > +1 to mark it as "immutable". > > On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle > wrote: > > Good point. It seems like this should say =E2=80=9Cimmutable=E2=80=9D ra= ther than > =E2=80=9Cread-only=E2=80=9D, since it can be set initially but not update= d. Thoughts from > anyone else? If this seems reasonable I=E2=80=99ll open an issue to get = this fixed. > > > > --Kelly > > > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Shelley > *Sent:* Friday, February 01, 2013 1:37 PM > *To:* scim@ietf.org > *Subject:* [scim] Groups Member Type > > > > As indicated in Section 8, the canonical types for Group members are > READ-ONLY. As such, how can consumers provide the type (i.e. "User" or > "Group")? Is it implied that IDs are unique across both users and groups = in > order for service providers to fulfill this requirement? > > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKC= X5Y > TpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > nXj1uLbLovxxCW-VPX0d1geWghpaAIZtMXKkPYyACLo&s=3DrCY_ > ttBwpsTcGVSsZT2hsLHWPXL17cWyIBS5WDT4oDs&e=3D > > > --94eb2c03ce80dd2006055659313e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the feedback.

Now that it is being used as directory, closing= some unspecified / loose areas might be better for interop IMO.

Is it = possible to fold some of these clarifications into the next SCIM RFC?
=


<= div class=3D"gmail_quote">On Wed, Aug 9, 2017 at 4:45 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Your plan sounds good to me, Shelly.=C2=A0 That=E2= =80=99s how I would implement it.

=C2=A0

From: Shelley [mailto:randomshelley@gmail.com] Sent: Wednesday, August 9, 2017 1:42 PM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: Kelly Grizzle <kelly.grizzle@sailpoint.com>; scim@ietf.org


Subject: Re: [scim] Groups Member Type

<= /p>

=C2=A0

You can also tell via id which is local and $ref = path given's scim's strict path rules (look at the parent of the la= st segment).

  • Is the id now re= quired to be globally unique across all resource types? If not, there is no guarantee that an SP can determine the resource type from the id.=
  • The $ref is also= optional, so this cannot be consistently used to determine the type. Furth= er, I was under the impression that the $ref is primaril= y used for SPs to communicate the resource location to consumers, rather th= an vice versa (i.e. it's essentially a read-only attribute).

Here is my tentative plan for our SP implementation for evaluating group members:

  • Treat value as REQUIRED. While the e= xample SCIM schema does not actually require the group member value sub-attrib= ute, this is the most consistent identifier for referring to members.
  • Treat $ref as READ-ONLY (i.e. ignore it completely when processing requests).= Using a $ref provided by= consumers seems a bit fragile (aside from eliminating the complexity of UR= I comparison, it's possible that a single resource may have multiple DN= S names, which further complicates absolute URI comparisons and integrity), and introduces redundancy (and potential ambig= uity) with value/type.
  • Treat type as OPTIONAL. My preference would be to treat this as REQUIRED in order to eliminate = any ambiguity, but given that the SCIM specs don't require it, doing th= is would limit interoperability for consumers that may not be sending it.
  • If type i= s not provided, assume the default value is "User".
  • Perform referential integrity to ensure that any provided group memb= er resources exist, based on value and type.

Examples

Given the existence of the following resources, here are some example re= quests/responses based on this proposal:

  • ../Users/abc<= /u>
  • ../Groups/xyz=

=C2=A0

Group Members

Response=

"members": [=

=C2=A0 {
=C2=A0=C2=A0=C2=A0 "value": "abc",=

=C2=A0=C2=A0=C2=A0=C2=A0"type&q= uot;: "User"

=C2=A0 },

=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0"value&= quot;: "xyz",

=C2=A0=C2=A0=C2=A0=C2=A0"type&q= uot;: "Group"

=C2=A0 }

]

2xx - Success

"members": [=

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "value"= : "abc"

=C2=A0 },

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "value"= : "xyz",

=C2=A0 =C2=A0 "type": &quo= t;Group"

=C2=A0 }

]

"members": [=

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "value"= : "abc",

=C2=A0 =C2=A0 "$ref": &quo= t;anything at all"

=C2=A0 },

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "value"= : "xyz",

=C2=A0 =C2=A0 "type": &quo= t;Group",

=C2=A0 =C2=A0 "$ref": &quo= t;anything at all"

=C2=A0 }

]

"members": [=

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "value"= : "xyz"

=C2=A0 }

]

400 - Missing =E2=80=9CGroup=E2=80=9D "type" on nested group mem= ber definition

"members": [=

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "value"= : "xyz"

=C2=A0 =C2=A0 "$ref": &quo= t;../Groups/xyz"

=C2=A0 }

]

"members": [=

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "$ref":= "../Users/abc"

=C2=A0 }

]

400 - Missing "value" on group member definition

"members": [=

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "$ref":= "../Groups/xyz"

=C2=A0 }

]

"members": [=

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "value"= : "abc",

=C2=A0 =C2=A0 "type": &quo= t;Group"

=C2=A0 }

]

400 - Wrong "type" provided

"members": [=

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "value"= : "xyz",

=C2=A0 =C2=A0 "type": &quo= t;User"

=C2=A0 }

]

"members": [=

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "value"= : "abc",

=C2=A0 =C2=A0 "type": &quo= t;UnsupportedType"

=C2=A0 }

]

400 - Unsupported "type" provided=

"members": [=

=C2=A0 {

=C2=A0=C2=A0=C2=A0 "value"= : "no such resource with or without type"

=C2=A0 }

]

400 - Member does not exist

=C2=A0

=C2=A0

On Wed, Aug 9, 2017 at 11:06 AM, Phil Hunt (IDM) <= ;phil.hunt@oracle= .com> wrote:

I agree the server can decide.=C2=A0

=C2=A0

IMO the server should check referential integrity. B= y doing so it would likely know the type. The spec is silent (as far as i r= ecall) on whether it expresses it.=C2=A0

=C2=A0

You can also tell via= id which is local and $ref path given's scim's strict path rules (= look at the parent of the last segment).=C2=A0

From my recollection some of these items were not th= at important given scim was provisioning api for apps - apps implementing s= erver side are free to do what they can/want. Now that it is being used as = directory, closing some unspecified / loose areas might be better for interop IMO.=C2=A0


Phil


On Aug 9, 2017, at 8:32 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wro= te:

Given the general desire for SCIM to allow loose rea= ding but strict writing, I would vote for option 1.=C2=A0 If type is not sp= ecified in a PUT/POST/PATCH then the server can assume =E2=80=9CUser=E2=80=9D.

=C2=A0

--Kelly

=C2=A0

From: Shelley [mailto:randomshelley@gmail.com]
Sent: Wednesday, August 9, 2017 9:02 AM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: scim@ietf.org=
Subject: Re: [scim] Groups Member Type

=C2=A0

Resurrecting this old thread, as this question ha= s recently come up during some of our interoperability testing, and there s= till appears to be some ambiguity in the spec...


The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected be= havior if the type sub-attribu= te is not provided on a Group resource <= span style=3D"font-family:"Courier New""> member. Neither spec seems to explicitly require this attribute, so = what is the expected behavior if no type is provided= ? Is there a default (e.g. "User" or "Group"), must Service Providers search for the me= mber across all resource types, or should it be treated as REQUIRED (e.g. return= ing a 400 error)?

=C2=A0

=C2=A0

On Mon, Feb 25, 2013 at 10:38 AM, Shelley <randomshelley@gmail.= com> wrote:

Thanks, Kelly. Given that the ID may represent eithe= r a User or Group and only the combination of "type" and "va= lue" uniquely identify the reference, should the canonical "type&= quot; attribute for group members be REQUIRED as well? (Further, the majority of= examples throughout the Protocol specification only include a "value&= quot; and not "type", so it's ambiguous as to whether these &= quot;values" represent Users or Groups.)

=C2=A0<= /p>

On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle <<= a href=3D"mailto:kelly.grizzle@sailpoint.com" target=3D"_blank">kelly.grizz= le@sailpoint.com> wrote:

I opened ticket #35 to= change this.

=C2=A0

http://trac.tools.ietf.org/wg/sci= m/trac/ticket/35

=C2=A0

--Kelly<= u>

=C2=A0

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Shelley
Sent: Monday, February 11, 2013 11:36 AM
To: Kelly Grizzle
Cc: scim@ietf.org=
Subject: Re: [scim] Groups Member Type

=C2=A0

+1 to mark it as &quo= t;immutable".

On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle <kelly.grizzl= e@sailpoint.com> wrote:

Good point.=C2=A0 It s= eems like this should say =E2=80=9Cimmutable=E2=80=9D rather than =E2=80=9C= read-only=E2=80=9D, since it can be set initially but not updated.=C2=A0 Th= oughts from anyone else?=C2=A0 If this seems reasonable I=E2=80=99ll open an issue to get thi= s fixed.

=C2=A0

--Kelly<= u>

=C2=A0

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Shelley
Sent: Friday, February 01, 2013 1:37 PM
To: scim@ietf.org=
Subject: [scim] Groups Member Type

=C2=A0

As indicated in Section 8, the canonical types for G= roup members are READ-ONLY. As such, how can consumers provide the type (i.= e. "User" or "Group")? Is it implied that IDs are unique across both users and groups in order for service providers to fulf= ill this requirement?

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--94eb2c03ce80dd2006055659313e-- From nobody Wed Aug 9 15:07:51 2017 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 25E2C132454 for ; Wed, 9 Aug 2017 15:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8Tz8pznVYdS7 for ; Wed, 9 Aug 2017 15:07:36 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 9B1B11323C6 for ; Wed, 9 Aug 2017 15:07:36 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id d29so34166776uai.2 for ; Wed, 09 Aug 2017 15:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VOWrXUpX53gj4xFNB5KJHx5eu42QIATJkmWGBBZJiKo=; b=SauVSNojV5EazGyDlifarnUnXjHHJGTYIsfH1It6LfvypKpjdFvhs4jNChcpzFqsez QHtnJnFK3XAdZe5rLAudINWjBkeF262ijezVCr875u4YmgyoZphXFv7OpO6z4Yhm0M8R 4/CfapecNOEYMdc0eR9GjbLPxbp6KrOnKkd03G8CdLEUc57kGq0/qw8bawykkma4AwVc X/GYnZB0PiTxQv8ZUuIwN1TrnL9B+tpuoeDAtT/YoipRHFchLQq22QICgAVaJU1QeWQ/ 5VRH4NLSYj+RtEJD/GxNwKp+LgfsyK/BhOtlIReJAsaPExGioYldecsw9DWZzDOTPpE5 BG2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VOWrXUpX53gj4xFNB5KJHx5eu42QIATJkmWGBBZJiKo=; b=hRegtOk0OheKwmhc2rTVJbv0U8jFq9C3+ezR4DCvx0IBYpUPv7JczVI9K3eUbN4KlX +N6ps9Bjas72Ow0NbnuMZRxQ4mZ87lqJHhN0MD/V8ZtNB/zA+tQCdA/aWFVq1dT27N6s N+6Udy7pJlhIs7ls3kbQsXDG6XrNuxKizssHz/LhVcxevckx4F/LOHpl2gAkPif+YS1D hmrbnOyxWm+pqqJXKBLHguAeEQuu5nJyxU43YjHIiqjxAu7qlFAySIPXTTyg0UNecrXm 2kBPLrzlQxK2lFoo1Pk62r+Xcag4OHMHehaJxZ5Va/PuGj/ofbDUd5scJ3zL29w9nRDv WdGg== X-Gm-Message-State: AHYfb5iqpLDlniv/gwLmPPA9WabcwlOihgxUSgqOZxkm3Q6FYMcpEGt6 qU+2dJykBBmyFgWOG/Ee25/FLvEQE/8D X-Received: by 10.159.62.212 with SMTP id n20mr7346085uaj.142.1502316455549; Wed, 09 Aug 2017 15:07:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.197.135 with HTTP; Wed, 9 Aug 2017 15:07:35 -0700 (PDT) From: Shelley Date: Wed, 9 Aug 2017 17:07:35 -0500 Message-ID: To: "scim@ietf.org" Content-Type: multipart/alternative; boundary="089e08205ee0ac63300556594e42" Archived-At: Subject: [scim] Globally Unique Resource Identifiers X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 22:07:49 -0000 --089e08205ee0ac63300556594e42 Content-Type: text/plain; charset="UTF-8" The SCIM specification indicates that the id [1]: *MUST be unique across the SCIM service provider's entire set of resources.* > Is this implying that the identifier must be globally unique across *all types of resources*, or simply that the identifier must be unique across *all resources of the same type*? Further, how does this statement account for *tenancy*? Requiring uniqueness across resource types may incur undue burden on service providers to maintain. All resources are relative to a type, e.g. /Users/. Even the global search functionality doesn't require global uniqueness because the combination of resourceType and id may be used to uniquely identify resources. Further, the SCIM 1.1 specification did not have this requirement, so this could make uplifting to SCIM 2.0 more difficult for some providers. [1] https://tools.ietf.org/html/rfc7643#section-3.1 --089e08205ee0ac63300556594e42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The SCIM specification indicates that the id [1]:

MUST be unique across the SCIM service= provider's entire set of resources.

Is this im= plying that the identifier must be globally unique across all types of r= esources, or simply that the identifier must be unique across all re= sources of the same type? Further, how does this statement account for = tenancy?

Requiring uniqueness across resource types may incur= undue burden on service providers to maintain. All resources are relative = to a type, e.g. /Users/<= id>. Even the global search functionality doesn't require glo= bal uniqueness because the combination of resourceType and id may be used to uniquely identify resources. Further, = the SCIM 1.1 specification did not have this requirement, so this could mak= e uplifting to SCIM 2.0 more difficult for some providers.
--089e08205ee0ac63300556594e42-- From nobody Wed Aug 9 16:14:34 2017 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 5D112132026 for ; Wed, 9 Aug 2017 16:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 wdNQhZUmZ2Oh for ; Wed, 9 Aug 2017 16:14:29 -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 79A001204DA for ; Wed, 9 Aug 2017 16:14:29 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v79NEQno026960 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Aug 2017 23:14:27 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v79NEPDK025835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Aug 2017 23:14:25 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v79NEOfe007784; Wed, 9 Aug 2017 23:14:25 GMT Received: from [25.90.18.53] (/24.114.44.187) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Aug 2017 16:14:23 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-205EC626-CE59-4B2D-8C62-1F2B13F5BEDF Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 9 Aug 2017 16:14:20 -0700 Cc: Kelly Grizzle , "scim@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <7F30611D-1BCB-4101-B1CF-2391B8F0CD93@oracle.com> References: <56C3C758F9D6534CA3778EAA1E0C343753AB2F38@BLUPRD0412MB643.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343753AC4630@BLUPRD0412MB643.namprd04.prod.outlook.com> To: Shelley X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [scim] Groups Member Type X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 23:14:33 -0000 --Apple-Mail-205EC626-CE59-4B2D-8C62-1F2B13F5BEDF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don't know. We would have to have enough interest to re-charter.=20 Phil > On Aug 9, 2017, at 2:59 PM, Shelley wrote: >=20 > Thanks for the feedback.=20 >=20 >> Now that it is being used as directory, closing some unspecified / loose a= reas might be better for interop IMO.=20 >=20 > Is it possible to fold some of these clarifications into the next SCIM RFC= ? >=20 >=20 >> On Wed, Aug 9, 2017 at 4:45 PM, Kelly Grizzle wrote: >> Your plan sounds good to me, Shelly. That=E2=80=99s how I would implemen= t it. >>=20 >> =20 >>=20 >> From: Shelley [mailto:randomshelley@gmail.com]=20 >> Sent: Wednesday, August 9, 2017 1:42 PM >> To: Phil Hunt (IDM) >> Cc: Kelly Grizzle ; scim@ietf.org >>=20 >>=20 >> Subject: Re: [scim] Groups Member Type >> =20 >>=20 >> You can also tell via id which is local and $ref path given's scim's stri= ct path rules (look at the parent of the last segment). >>=20 >> Is the id now required to be globally unique across all resource types? I= f not, there is no guarantee that an SP can determine the resource type from= the id. >> The $ref is also optional, so this cannot be consistently used to determi= ne the type. Further, I was under the impression that the $ref is primarily u= sed for SPs to communicate the resource location to consumers, rather than v= ice versa (i.e. it's essentially a read-only attribute). >> Here is my tentative plan for our SP implementation for evaluating group m= embers: >>=20 >> Treat value as REQUIRED. While the example SCIM schema does not actually r= equire the group member value sub-attribute, this is the most consistent ide= ntifier for referring to members. >> Treat $ref as READ-ONLY (i.e. ignore it completely when processing reques= ts). Using a $ref provided by consumers seems a bit fragile (aside from elim= inating the complexity of URI comparison, it's possible that a single resour= ce may have multiple DNS names, which further complicates absolute URI compa= risons and integrity), and introduces redundancy (and potential ambiguity) w= ith value/type. >> Treat type as OPTIONAL. My preference would be to treat this as REQUIRED i= n order to eliminate any ambiguity, but given that the SCIM specs don't requ= ire it, doing this would limit interoperability for consumers that may not b= e sending it. >> If type is not provided, assume the default value is "User". >> Perform referential integrity to ensure that any provided group member re= sources exist, based on value and type. >> Examples >>=20 >> Given the existence of the following resources, here are some example req= uests/responses based on this proposal: >>=20 >> ../Users/abc >> ../Groups/xyz >> =20 >>=20 >> Group Members >> Response >> "members": [ >> { >> "value": "abc", >> "type": "User" >> }, >> { >> "value": "xyz", >> "type": "Group" >> } >> ] >> 2xx - Success >> "members": [ >> { >> "value": "abc" >> }, >> { >> "value": "xyz", >> "type": "Group" >> } >> ] >> "members": [ >> { >> "value": "abc", >> "$ref": "anything at all" >> }, >> { >> "value": "xyz", >> "type": "Group", >> "$ref": "anything at all" >> } >> ] >> "members": [ >> { >> "value": "xyz" >> } >> ] >> 400 - Missing =E2=80=9CGroup=E2=80=9D "type" on nested group member defin= ition >> "members": [ >> { >> "value": "xyz" >> "$ref": "../Groups/xyz" >> } >> ] >> "members": [ >> { >> "$ref": "../Users/abc" >> } >> ] >> 400 - Missing "value" on group member definition >> "members": [ >> { >> "$ref": "../Groups/xyz" >> } >> ] >> "members": [ >> { >> "value": "abc", >> "type": "Group" >> } >> ] >> 400 - Wrong "type" provided >> "members": [ >> { >> "value": "xyz", >> "type": "User" >> } >> ] >> "members": [ >> { >> "value": "abc", >> "type": "UnsupportedType" >> } >> ] >> 400 - Unsupported "type" provided >> "members": [ >> { >> "value": "no such resource with or without type" >> } >> ] >> 400 - Member does not exist >> =20 >>=20 >> =20 >>=20 >> On Wed, Aug 9, 2017 at 11:06 AM, Phil Hunt (IDM) w= rote: >>=20 >> I agree the server can decide.=20 >>=20 >> =20 >>=20 >> IMO the server should check referential integrity. By doing so it would l= ikely know the type. The spec is silent (as far as i recall) on whether it e= xpresses it.=20 >>=20 >> =20 >>=20 >> You can also tell via id which is local and $ref path given's scim's stri= ct path rules (look at the parent of the last segment).=20 >>=20 >> =46rom my recollection some of these items were not that important given s= cim was provisioning api for apps - apps implementing server side are free t= o do what they can/want. Now that it is being used as directory, closing som= e unspecified / loose areas might be better for interop IMO.=20 >>=20 >>=20 >> Phil >>=20 >>=20 >> On Aug 9, 2017, at 8:32 AM, Kelly Grizzle w= rote: >>=20 >> Given the general desire for SCIM to allow loose reading but strict writi= ng, I would vote for option 1. If type is not specified in a PUT/POST/PATCH= then the server can assume =E2=80=9CUser=E2=80=9D. >>=20 >> =20 >>=20 >> --Kelly >>=20 >> =20 >>=20 >> From: Shelley [mailto:randomshelley@gmail.com]=20 >> Sent: Wednesday, August 9, 2017 9:02 AM >> To: Kelly Grizzle >> Cc: scim@ietf.org >> Subject: Re: [scim] Groups Member Type >>=20 >> =20 >>=20 >> Resurrecting this old thread, as this question has recently come up durin= g some of our interoperability testing, and there still appears to be some a= mbiguity in the spec... >>=20 >>=20 >> The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected b= ehavior if the type sub-attribute is not provided on a Group resource member= . Neither spec seems to explicitly require this attribute, so what is the ex= pected behavior if no type is provided? Is there a default (e.g. "User" or "= Group"), must Service Providers search for the member across all resource ty= pes, or should it be treated as REQUIRED (e.g. returning a 400 error)? >>=20 >> =20 >>=20 >> =20 >>=20 >> On Mon, Feb 25, 2013 at 10:38 AM, Shelley wrote= : >>=20 >> Thanks, Kelly. Given that the ID may represent either a User or Group and= only the combination of "type" and "value" uniquely identify the reference,= should the canonical "type" attribute for group members be REQUIRED as well= ? (Further, the majority of examples throughout the Protocol specification o= nly include a "value" and not "type", so it's ambiguous as to whether these "= values" represent Users or Groups.) >>=20 >> =20 >>=20 >> On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle wrote: >>=20 >> I opened ticket #35 to change this. >>=20 >> =20 >>=20 >> http://trac.tools.ietf.org/wg/scim/trac/ticket/35 >>=20 >> =20 >>=20 >> --Kelly >>=20 >> =20 >>=20 >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of S= helley >> Sent: Monday, February 11, 2013 11:36 AM >> To: Kelly Grizzle >> Cc: scim@ietf.org >> Subject: Re: [scim] Groups Member Type >>=20 >> =20 >>=20 >> +1 to mark it as "immutable". >>=20 >> On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle wrote: >>=20 >> Good point. It seems like this should say =E2=80=9Cimmutable=E2=80=9D ra= ther than =E2=80=9Cread-only=E2=80=9D, since it can be set initially but not= updated. Thoughts from anyone else? If this seems reasonable I=E2=80=99ll= open an issue to get this fixed. >>=20 >> =20 >>=20 >> --Kelly >>=20 >> =20 >>=20 >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of S= helley >> Sent: Friday, February 01, 2013 1:37 PM >> To: scim@ietf.org >> Subject: [scim] Groups Member Type >>=20 >> =20 >>=20 >> As indicated in Section 8, the canonical types for Group members are READ= -ONLY. As such, how can consumers provide the type (i.e. "User" or "Group")?= Is it implied that IDs are unique across both users and groups in order for= service providers to fulfill this requirement? >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&= r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DnXj1uLbLovxxCW-VPX0d1geW= ghpaAIZtMXKkPYyACLo&s=3DrCY_ttBwpsTcGVSsZT2hsLHWPXL17cWyIBS5WDT4oDs&e=3D >>=20 >> =20 >>=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r= =3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Dr2m_MvDPC_E054FW8iS_KN21B= YONvlP0VoG5jrqmY1s&s=3DXfPtR8usf3qjskybyrZ_GpfWNWTn_l3pKiZNBe8O4tU&e=3D=20 --Apple-Mail-205EC626-CE59-4B2D-8C62-1F2B13F5BEDF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I don't know. We would have to have en= ough interest to re-charter. 

Phil

On Aug 9, 2017,= at 2:59 PM, Shelley <randomsh= elley@gmail.com> wrote:

<= div dir=3D"ltr">Thanks for the feedback.

Now that it is being used as directory, closing som= e unspecified / loose areas might be better for interop IMO.

Is it possib= le to fold some of these clarifications into the next SCIM RFC?


On Wed, Aug 9, 2017 at 4:45 PM, Kelly Grizzle <k= elly.grizzle@sailpoint.com> wrote:

Your plan sounds good to me, Shelly.  That=E2=80= =99s how I would implement it.

 

From: Shelley [mailto:randomshelley@gmail.com]
Sent: Wednesday, August 9, 2017 1:42 PM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: Kelly Grizzle <kelly.grizzle@sailpoint.com>; scim@ietf.org

Subject: Re: [scim] Groups Member Type

 

You can also tell via id which is local and $ref p= ath given's scim's strict path rules (look at the parent of the last segment= ).

  • Is the id now req= uired to be globally unique across all resource types? If not, there is no guarantee that an SP can determine the resource type from the id.<= /u>
  • The $ref is also o= ptional, so this cannot be consistently used to determine the type. Further,= I was under the impression that the $ref is primarily= used for SPs to communicate the resource location to consumers, rather than= vice versa (i.e. it's essentially a read-only attribute).

Here is my tentative plan for our SP implementation for evaluating = group members:

  • Treat value as REQUIRED. While the example SCIM schema= does not actually require the group member value sub-attribu= te, this is the most consistent identifier for referring to members.<= u>
  • Treat $ref= as READ-ONLY (i.e. ignore it completely when processing requests). U= sing a $ref provided by c= onsumers seems a bit fragile (aside from eliminating the complexity of URI c= omparison, it's possible that a single resource may have multiple DNS names,= which further complicates absolute URI comparisons and integrity), and introduces redundancy (and potential ambigu= ity) with value/type.
  • Treat type as OPTIONAL. My preference would be to treat this as REQUIRED in order to eliminate a= ny ambiguity, but given that the SCIM specs don't require it, doing this wou= ld limit interoperability for consumers that may not be sending it.
  • If type is= not provided, assume the default value is "User".
  • Perform referential integrity to ensure that any provided group membe= r resources exist, based on value and type.

Examples

=

Given the existence of the following resources, here are some example req= uests/responses based on this proposal:

  • ../Users/abc
  • ../Groups/xyz<= /u>

 

Group Members

Response

"members": [

  {
    "value": "abc",

    "type": "User"=

  },

  {

    "value": "xyz"= ,

    "type": "Group= "

  }

]

2xx<= span style=3D"font-size:10.0pt;font-family:"Arial",sans-serif;colo= r:black"> - Success

"members": [

  {

    "value": "abc"

  },

  {

    "value": "xyz",

    "type": "Group"

  }

]

"members": [

  {

    "value": "abc",

    "$ref": "anything at all= "

  },

  {

    "value": "xyz",

    "type": "Group",<= u>

    "$ref": "anything at all= "

  }

]

"members": [

  {

    "value": "xyz"

  }

]

400 - Missing =E2=80=9CGroup=E2=80=9D "type" on nested group member definiti= on

"members": [

  {

    "value": "xyz"

    "$ref": "../Groups/xyz"<= /span>

  }

]

"members": [

  {

    "$ref": "../Users/a= bc"

  }

]

400 - Missing "value" on group member definition

"members": [

  {

    "$ref": "../Groups/= xyz"

  }

]

"members": [

  {

    "value": "abc",

    "type": "Group"

  }

]

400 - Wrong "type" provided

"members": [

  {

    "value": "xyz",

    "type": "User"=

  }

]

"members": [

  {

    "value": "abc",

    "type": "UnsupportedType= "

  }

]

400 - Unsupported "type" provided

"members": [

  {

    "value": "no such r= esource with or without type"

  }

]

400 - Member does not exist

 

 

On Wed, Aug 9, 2017 at 11:06 AM, Phil Hunt (IDM) <= phil.hunt@oracle.c= om> wrote:

I agree the server can decide. 

 

IMO the server should check referential integrity. By= doing so it would likely know the type. The spec is silent (as far as i rec= all) on whether it expresses it. 

 

You can also tell via i= d which is local and $ref path given's scim's strict path rules (look at the= parent of the last segment). 

=46rom my recollection some of these items were not t= hat important given scim was provisioning api for apps - apps implementing s= erver side are free to do what they can/want. Now that it is being used as d= irectory, closing some unspecified / loose areas might be better for interop IMO. 


Phil


On Aug 9, 2017, at 8:32 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote= :

Given the general desire for SCIM to allow loose read= ing but strict writing, I would vote for option 1.  If type is not spec= ified in a PUT/POST/PATCH then the server can assume =E2=80=9CUser=E2=80=9D.

 

--Kelly

 

From: Shelley [mailto:randomshelley@gmail.com]
Sent: Wednesday, August 9, 2017 9:02 AM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: scim@ietf.org<= /a>
Subject: Re: [scim] Groups Member Type

 

Resurrecting this old thread, as this question has= recently come up during some of our interoperability testing, and there sti= ll appears to be some ambiguity in the spec...


The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected beh= avior if the type sub-attribut= e is not provided on a Group resource member. Neither spec seems to explicitly require this attribute, so w= hat is the expected behavior if no type is provided?= Is there a default (e.g. "User" or "Grou= p"), must Service Providers search for the member across all resource types, or should it be treated as REQUIRED (e.g. returni= ng a 400 error)?

 

 

On Mon, Feb 25, 2013 at 10:38 AM, Shelley <randomshelley@gmail.co= m> wrote:

Thanks, Kelly. Given that the ID may represent either= a User or Group and only the combination of "type" and "value" uniquely ide= ntify the reference, should the canonical "type" attribute for group members be REQUIRED as well? (Further, the majority of e= xamples throughout the Protocol specification only include a "value" and not= "type", so it's ambiguous as to whether these "values" represent Users or G= roups.)

 

On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle <kelly.grizzle= @sailpoint.com> wrote:

I opened ticket #35 to c= hange this.

 =

http://trac.tools.ietf.org/wg/scim/trac= /ticket/35

 =

--Kelly

 =

From: scim-bounces@ietf= .org [mailto:= scim-bounces@ietf.org] On Behalf Of Shelley
Sent: Monday, February 11, 2013 11:36 AM
To: Kelly Grizzle
Cc: scim@ietf.org<= /a>
Subject: Re: [scim] Groups Member Type

 

+1 to mark it as "immu= table".

On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle <kelly.grizzle@s= ailpoint.com> wrote:

Good point.  It se= ems like this should say =E2=80=9Cimmutable=E2=80=9D rather than =E2=80=9Cre= ad-only=E2=80=9D, since it can be set initially but not updated.  Thoug= hts from anyone else?  If this seems reasonable I=E2=80=99ll open an issue to get this= fixed.

 =

--Kelly

 =

From: scim-bounces@ietf= .org [mailto:= scim-bounces@ietf.org] On Behalf Of Shelley
Sent: Friday, February 01, 2013 1:37 PM
To: scim@ietf.org<= /a>
Subject: [scim] Groups Member Type

 

As indicated in Section 8, the canonical types for Gr= oup members are READ-ONLY. As such, how can consumers provide the type (i.e.= "User" or "Group")? Is it implied that IDs are unique across both users and groups in order for service providers to fulfi= ll this requirement?

 

 

 

 


<= /body>= --Apple-Mail-205EC626-CE59-4B2D-8C62-1F2B13F5BEDF-- From nobody Wed Aug 9 16:17:40 2017 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 98D7D131EA7 for ; Wed, 9 Aug 2017 16:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 El4lKEL5vfTb for ; Wed, 9 Aug 2017 16:17:37 -0700 (PDT) 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 6F1241204DA for ; Wed, 9 Aug 2017 16:17:37 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v79NHY3f030092 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Aug 2017 23:17:34 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v79NHX57005347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Aug 2017 23:17:33 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v79NHWYU003377; Wed, 9 Aug 2017 23:17:33 GMT Received: from [25.90.18.53] (/24.114.44.187) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Aug 2017 16:17:32 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-0CD06AF1-99F7-4834-AE3F-5636F3783EA6 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 9 Aug 2017 16:17:30 -0700 Cc: "scim@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: To: Shelley X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [scim] Globally Unique Resource Identifiers X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 23:17:39 -0000 --Apple-Mail-0CD06AF1-99F7-4834-AE3F-5636F3783EA6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Entire set of resources means all present on the server. At least that is ho= w I read it and how the discussion that I recall having occurred.=20 There was concern about naming conflicts (causing desire for renames of immu= table ids) and referential integrity as factors affecting this decision.=20 Phil > On Aug 9, 2017, at 3:07 PM, Shelley wrote: >=20 > The SCIM specification indicates that the id [1]: >=20 >> MUST be unique across the SCIM service provider's entire set of resources= . >=20 > Is this implying that the identifier must be globally unique across all ty= pes of resources, or simply that the identifier must be unique across all re= sources of the same type? Further, how does this statement account for tenan= cy? >=20 > Requiring uniqueness across resource types may incur undue burden on servi= ce providers to maintain. All resources are relative to a type, e.g. /Users/= . Even the global search functionality doesn't require global uniqueness= because the combination of resourceType and id may be used to uniquely iden= tify resources. Further, the SCIM 1.1 specification did not have this requir= ement, so this could make uplifting to SCIM 2.0 more difficult for some prov= iders. >=20 > [1] https://tools.ietf.org/html/rfc7643#section-3.1 > _______________________________________________ > scim mailing list > scim@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r= =3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DGhthQiFLtNDfeeWDzdzah76F9= C9b1Z6OivTWsj3UPas&s=3DS4YVRZEMfzCuzu7pj12Xn5Spd2lfIj03DsMls_2rOVY&e=3D=20 --Apple-Mail-0CD06AF1-99F7-4834-AE3F-5636F3783EA6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Entire set of resources means all pres= ent on the server. At least that is how I read it and how the discussion tha= t I recall having occurred. 

There was concern about naming conflicts (= causing desire for renames of immutable ids) and referential integrity as fa= ctors affecting this decision. 

Phil

On Aug 9, 201= 7, at 3:07 PM, Shelley <random= shelley@gmail.com> wrote:

The SCIM specification indicates that the id [1]:

MUST be unique across the SCIM service pr= ovider's entire set of resources.

Is this implying t= hat the identifier must be globally unique across all types of resources<= /i>, or simply that the identifier must be unique across all resources of= the same type? Further, how does this statement account for tenancy<= /i>?

Requiring uniqueness across resource types may incur undue burde= n on service providers to maintain. All resources are relative to a type, e.= g. /Users/<id>.= Even the global search functionality doesn't require global uniqueness beca= use the combination of resou= rceType and id= may be used to uniquely identify resources. Further, the SCIM 1.1 specifica= tion did not have this requirement, so this could make uplifting to SCIM 2.0= more difficult for some providers.
= --Apple-Mail-0CD06AF1-99F7-4834-AE3F-5636F3783EA6-- From nobody Wed Aug 9 16:19:51 2017 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 60B2A131EA7 for ; Wed, 9 Aug 2017 16:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 m9h78K2EH-Lq for ; Wed, 9 Aug 2017 16:19:48 -0700 (PDT) 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 4CCE81204DA for ; Wed, 9 Aug 2017 16:19:48 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v79NJkJq031843 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Aug 2017 23:19:47 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v79NJkfv007545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Aug 2017 23:19:46 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v79NJkWb016599; Wed, 9 Aug 2017 23:19:46 GMT Received: from [25.90.18.53] (/24.114.44.187) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Aug 2017 16:19:46 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-FBAAC704-0D5D-441D-AE2C-528BBD140468 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 9 Aug 2017 16:19:28 -0700 Cc: "scim@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: To: Shelley X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [scim] Globally Unique Resource Identifiers X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 23:19:50 -0000 --Apple-Mail-FBAAC704-0D5D-441D-AE2C-528BBD140468 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Missed the second part. Most people use guids for this purpose to avoid havi= ng to check for conflict. =20 If you use an id subject to change you are asking for problems. At least tha= t was the lesson of ldap DNs. Guids bring stability in many forms.=20 Phil > On Aug 9, 2017, at 3:07 PM, Shelley wrote: >=20 > The SCIM specification indicates that the id [1]: >=20 >> MUST be unique across the SCIM service provider's entire set of resources= . >=20 > Is this implying that the identifier must be globally unique across all ty= pes of resources, or simply that the identifier must be unique across all re= sources of the same type? Further, how does this statement account for tenan= cy? >=20 > Requiring uniqueness across resource types may incur undue burden on servi= ce providers to maintain. All resources are relative to a type, e.g. /Users/= . Even the global search functionality doesn't require global uniqueness= because the combination of resourceType and id may be used to uniquely iden= tify resources. Further, the SCIM 1.1 specification did not have this requir= ement, so this could make uplifting to SCIM 2.0 more difficult for some prov= iders. >=20 > [1] https://tools.ietf.org/html/rfc7643#section-3.1 > _______________________________________________ > scim mailing list > scim@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r= =3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DGhthQiFLtNDfeeWDzdzah76F9= C9b1Z6OivTWsj3UPas&s=3DS4YVRZEMfzCuzu7pj12Xn5Spd2lfIj03DsMls_2rOVY&e=3D=20 --Apple-Mail-FBAAC704-0D5D-441D-AE2C-528BBD140468 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Missed the second part. Most people us= e guids for this purpose to avoid having to check for conflict.  
=

If y= ou use an id subject to change you are asking for problems. At least that wa= s the lesson of ldap DNs.  Guids bring stability in many forms. 
Phil

On Aug 9, 2017, at 3:07 PM, Shelley <randomshelley@gmail.com> wrote:
The SCIM specif= ication indicates that the i= d [1]:

MUS= T be unique across the SCIM service provider's entire set of resources.<= br>

Is this implying that the identifier must be globally un= ique across all types of resources, or simply that the identifier mus= t be unique across all resources of the same type? Further, how does t= his statement account for tenancy?

Requiring uniqueness across= resource types may incur undue burden on service providers to maintain. All= resources are relative to a type, e.g. /Users/<id>. Even the global search functionality d= oesn't require global uniqueness because the combination of resourceType and id may be used to uniquely identify resou= rces. Further, the SCIM 1.1 specification did not have this requirement, so t= his could make uplifting to SCIM 2.0 more difficult for some providers.
= --Apple-Mail-FBAAC704-0D5D-441D-AE2C-528BBD140468--