From kelly.grizzle@sailpoint.com Tue Sep 3 06:02:22 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED64321E812D for ; Tue, 3 Sep 2013 06:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6uD2JqM7dhf for ; Tue, 3 Sep 2013 06:02:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 2640721E8147 for ; Tue, 3 Sep 2013 06:02:15 -0700 (PDT) Received: from BLUPR04MB184.namprd04.prod.outlook.com (10.255.189.155) by BLUPR04MB184.namprd04.prod.outlook.com (10.255.189.155) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 13:02:12 +0000 Received: from BLUPR04MB184.namprd04.prod.outlook.com ([169.254.5.58]) by BLUPR04MB184.namprd04.prod.outlook.com ([169.254.5.58]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 13:02:12 +0000 From: Kelly Grizzle To: scim issue tracker , "draft-ietf-scim-core-schema@tools.ietf.org" , "phil.hunt@oracle.com" Thread-Topic: Issue #38 - please review Thread-Index: Ac6opVskRvtbKIzUT9m+d90qceMvLA== Date: Tue, 3 Sep 2013 13:02:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 024750F800528C02475245 x-originating-ip: [72.182.10.254] x-forefront-prvs: 09583628E0 x-forefront-antispam-report: SFV:NSPM; SFS:(5383001)(199002)(189002)(13464003)(377454003)(164054003)(81342001)(66066001)(74706001)(19580395003)(74876001)(65816001)(80022001)(74316001)(46102001)(15975445006)(74366001)(81542001)(47736001)(47976001)(50986001)(19580405001)(83322001)(49866001)(69226001)(4396001)(51856001)(56816003)(77096001)(15202345003)(81816001)(76176001)(31966008)(74662001)(63696002)(47446002)(74502001)(33646001)(56776001)(54316002)(53806001)(76482001)(81686001)(54356001)(79102001)(59766001)(77982001)(76576001)(76786001)(76796001)(80976001)(83072001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR04MB184; H:BLUPR04MB184.namprd04.prod.outlook.com; CLIP:72.182.10.254; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: [scim] Issue #38 - please review X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 13:02:23 -0000 SSBoYXZlIHB1Ymxpc2hlZCBuZXcgZHJhZnRzIHdpdGggY2hhbmdlcyBmb3IgaXNzdWUgIzM4LiAg QSBzdW1tYXJ5IG9mIHRoZSBjaGFuZ2VzIGNhbiBiZSBzZWVuIGhlcmUgLSBodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2NpbS9jdXJyZW50L21zZzAxMTUzLmh0bWwuDQoNClBs ZWFzZSByZXZpZXcgYm90aCB0aGUgc2NoZW1hIGFuZCBBUEkgZHJhZnRzIGFuZCBzZW5kIHlvdXIg ZmVlZGJhY2suICBUaGVzZSBhcmUgYXZhaWxhYmxlIGhlcmU6DQoNCmh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zY2ltLWNvcmUtc2NoZW1hLw0KaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNjaW0tYXBpLw0KDQpPciAuLi4gaWYgeW91 IHByZWZlciB0byBqdXN0IHZpZXcgdGhlIGRpZmZzOg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc2NpbS1jb3JlLXNjaGVtYS0wMi50eHQNCmh0dHA6Ly90 b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zY2ltLWFwaS0wMi50eHQNCg0K VGhhbmtzLA0KDQotLUtlbGx5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBz Y2ltIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjK3NjaW1AdG9vbHMuaWV0Zi5vcmddIA0KU2Vu dDogRnJpZGF5LCBBdWd1c3QgMzAsIDIwMTMgMzo1NyBQTQ0KVG86IGRyYWZ0LWlldGYtc2NpbS1j b3JlLXNjaGVtYUB0b29scy5pZXRmLm9yZzsgS2VsbHkgR3JpenpsZTsgcGhpbC5odW50QG9yYWNs ZS5jb20NCkNjOiBzY2ltQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NjaW1dICMzODogQ2xhcmlm eSB0aGUgc2NoZW1hIGV4dGVuc2lvbiBtb2RlbA0KDQojMzg6IENsYXJpZnkgdGhlIHNjaGVtYSBl eHRlbnNpb24gbW9kZWwNCg0KDQpDb21tZW50IChieSBrZWxseS5ncml6emxlQHNhaWxwb2ludC5j b20pOg0KDQogQWRkZWQgcHJvcG9zZWQgY2hhbmdlcyBpbnRvIHRoZSAtMDIgZHJhZnRzLiAgU2Vl IGEgc3VtbWFyeSBvZiB0aGUgY2hhbmdlcw0KIGhlcmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9zY2ltL2N1cnJlbnQvbXNnMDExNTMuaHRtbC4NCg0KLS0gDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg IE93bmVyOiAgZHJhZnQtaWV0Zi1zY2ltLWNvcmUtDQogIGtlbGx5LmdyaXp6bGVAc2FpbHBvaW50 LmNvbSAgICAgICAgfCAgc2NoZW1hQHRvb2xzLmlldGYub3JnDQogICAgIFR5cGU6ICBkZWZlY3Qg ICAgICAgICAgICAgICAgICAgfCAgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3Ig ICAgICAgICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBjb3JlLXNjaGVt YSAgICAgICAgICAgICAgfCAgICAgVmVyc2lvbjoNCiBTZXZlcml0eTogIC0gICAgICAgICAgICAg ICAgICAgICAgICB8ICBSZXNvbHV0aW9uOg0KIEtleXdvcmRzOiAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvd2cvc2NpbS90cmFjL3RpY2tldC8zOCNjb21tZW50OjU+DQpzY2ltIDxo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvc2NpbS8+DQoNCg== From swm16@psu.edu Tue Sep 3 08:40:42 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA65B21E8143 for ; Tue, 3 Sep 2013 08:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01FQt3gtFMMf for ; Tue, 3 Sep 2013 08:40:35 -0700 (PDT) Received: from tr21g10.aset.psu.edu (tr21g10.aset.psu.edu [146.186.149.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2007821E8157 for ; Tue, 3 Sep 2013 08:40:35 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr21g10.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r83FeY9L3076180 for ; Tue, 3 Sep 2013 11:40:34 -0400 Date: Tue, 3 Sep 2013 11:40:33 -0400 (EDT) From: "Steven W. Moyer" To: scim@ietf.org Message-ID: <280662630.503530.1378222833568.JavaMail.zimbra@psu.edu> In-Reply-To: <864794342.259897.1378219309142.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.118.58.157] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - FF22 (Mac)/8.0.4_GA_5737) Thread-Topic: Error responses Thread-Index: OK7K095jRB4ktCCnA9g7LVYvpCQTSw== X-Virus-Scanned: by amavisd-new Subject: [scim] Error responses X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Steven W. Moyer" List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:40:43 -0000 After reviewing the latest drafts of the 2.0 specification, it dawned on me that we could do a better job of providing error responses. I'll make several observations and a proposal at the bottom of this e-mail, but wanted to reference the appropriate sections of the API document. The sections that refer to error handling are as follows: - Section 3. API All requests to the Service Provider are made via HTTP operations on a URL derived from the Base URL. Responses are returned in the body of the HTTP response, formatted as JSON. Response and error codes SHOULD be transmitted via the HTTP status code of the response (if possible), and SHOULD also be specified in the body of the response. - Section 3.1 Creating Resources If the Service Provider determines creation of the requested Resource conflicts with existing resources; e.g., a User Resource with a duplicate userName, the Service Provider MUST return a 409 error and SHOULD indicate the conflicting attribute(s) in the body of the response. - 3.2.2.2. Filtering Providers MAY support additional filter operations if they choose. Providers MUST decline to filter results if the specified filter operation is not recognized and return a HTTP 400 error with an appropriate human readable response. For example, if a Consumer specified an unsupported operator named 'regex' the Service Provider should specify an error response description identifying the Consumer error; e.g., 'The operator 'regex' is not supported.' - 3.3.2. Modifying with PATCH A delete operation is ignored if the attribute's name is in the meta.attributes list. If the requested value to delete does not match a unique value on the Resource the server MAY return a HTTP 400 error. - 3.4. Deleting Resources Consumers request Resource removal via DELETE. Service Providers MAY choose not to permanently delete the Resource, but MUST return a 404 error code for all operations associated with the previously deleted Id. Service Providers MUST also omit the Resource from future query results. In addition the Service Provider MUST not consider the deleted resource in conflict calculation. For example if a User resource is deleted, a CREATE request for a User resource with the same userName as the previously deleted resource should not fail with a 409 error due to userName conflict. { "Errors":[ { "description":"Resource 2819c223-7f76-453a-919d-413861904646 not found", "code":"404" } ] } 3.5. Bulk If a bulk job is processed successfully the HTTP response code 200 OK MUST be returned, otherwise an appropriate HTTP error code MUST be returned. The Service Provider response MUST include the result of all processed operations. A location attribute that includes the Resource's end point MUST be returned for all operations excluding failed POSTs. The status attribute includes information about the success or failure of one operation within the bulk job. The attribute status MUST include the code attribute that holds the HTTP response code that would have been returned if a single HTTP request would have been used. If an error occurred the status MUST also include the description attribute containing a human readable explanation of the error. "status": { "code": "400", "description": "Request is unparseable, syntactically incorrect, or violates schema." } ... { "location": "https://example.com/v1/Users/b7c14771-226c-4d05-8860-134711653041", "method": "PUT", "status": { "code": "412", "description": "Failed to update as user changed on the server since you last retrieved it." } }, ... - 3.9. HTTP Response Codes The SCIM Protocol uses the response status codes defined in HTTP [6] to indicate operation success or failure. In addition to returning a HTTP response code implementers MUST return the errors in the body of the response in the client requested format containing the error response and, per the HTTP specification, human-readable explanations. Implementers SHOULD handle the identified errors as described below. { "Errors":[ { "description":"Resource 2819c223-7f76-453a-919d-413861904646 not found", "code":"404" } ] } My observations are as follows: - Several of the sections refer to the fact that error messages might be plural (such as the phrase "conflicting attribute(s)" in section 3.1), so the error message structure should allow for plural descriptions. - Several of the sections state that the error message should be human-readable, but the overall error message structure should also be machine parseable. - It's stated that a service provider MUST return a status code, but SHOULD/MAY return a description of the error in the entity body. Shouldn't the entity body be consistent if it's sent? - The Bulk API operation states that an error code must be accompanied by a human-readable error description (which is inconsistent with the underlying single operations). - When I see the "description" sub-attribute in the "status" attribute, I mentally expect it to contain the HTTP status message associated with the status codes (as found here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). - Section 3.9 states that the provider "MUST return the errors in the body of the response in the client requested format containing the error response and, per the HTTP specification, human-readable explanations" but that's not consistent with the description of responses for some of the operations. The array of "Errors" might return several messages (in the case of a conflict) but (except for the Bulk operations) there will only every be a single error code (and it should match the one returned from the server. So my proposal would be to strengthen section 3.9 and to make it consistent with the format needed for the Bulk operations. These needs could be met by a structure similar to the following fragment: { "location": "https://example.com/v1/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", "method": "PUT", "status": { "code": 409, "description": "Conflict" }, "reasons": [ "The userName attribute may not be modified on this system", "The SSN provided with this request does not match the one stored in the user's record" ] } In addition, it could be also be used within the BulkResponse's "Operations" array attribute (though I haven't thought through where to put the transient value of the "bulkId" sub-attribute). It's my opinion that having a unified format for the responses is highly desireable, and that the format above reduces the inconsistencies stated above. I also believe it meets the requirements of being both human-readable and machine-parseable. I'm sure I've made some mistakes in my assertions and there are probably gaps in my proposal, but I wanted to present a straw-man to get the discussion started. Thanks for putting up with my long-winded e-mail! Steve From moransar@cisco.com Tue Sep 3 23:34:50 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CD811E817C for ; Tue, 3 Sep 2013 23:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT4hsjPb7OCr for ; Tue, 3 Sep 2013 23:34:46 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB0121F9ADA for ; Tue, 3 Sep 2013 23:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5028; q=dns/txt; s=iport; t=1378276486; x=1379486086; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=9a7FKwMpCgayExoM6UardOkgQybDWh8WWmiw9/5RaIY=; b=GSl4WXUAYyNrrqJkSQSbhzzXZN1tOyCGOyNgCz1vWAt1N94KiNZb0DbP FcmacDILqe+NmuV3Vp6ER3WnNI/hWe/WLzFmxkuBwJ6cOgCLHRIAwTqS5 I2P7EnWhYSczV6ZdVdenLe2uLO/NeaMnndlS1Rv3izjNhAZ2mxpacEYUv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8FACvUJlKtJXG//2dsb2JhbABAGoJDRDVRwT2BIxZtB4ImAQRoIwEqDgw8JQIEG4d6DDSYT5MfjRcEji2BGC0LGIMFgQADqVuDIIFxOQ X-IronPort-AV: E=Sophos;i="4.89,1019,1367971200"; d="scan'208,217";a="255402942" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 04 Sep 2013 06:34:35 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r846YZdL024497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 4 Sep 2013 06:34:35 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.27]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 01:34:35 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: Reminder - SCIM WG conf call on Sep. 9th 11:00AM Pacific time Thread-Index: AQHOqTjRsEFr3iOIUEKbok1IpUqSog== Date: Wed, 4 Sep 2013 06:34:34 +0000 Message-ID: In-Reply-To: <5215B177.2010502@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.94.213] Content-Type: multipart/alternative; boundary="_000_CA3B67220D628A4780D6FEB31F18A3E32ABCA677xmbrcdx08ciscoc_" MIME-Version: 1.0 Subject: [scim] Reminder - SCIM WG conf call on Sep. 9th 11:00AM Pacific time X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 06:34:51 -0000 --_000_CA3B67220D628A4780D6FEB31F18A3E32ABCA677xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, Just a reminder of our upcoming conf call: Here is the agenda for the 4/9 conference call: - Issue tracker reivew focused on the following issues: 2,9,10,13,24,34,35,= 37,39,42 & 46 The intent of the confcalls is to agree on a jump-off point for discussions= on these issues which will then be concluded on the list. Missing a call doesn't mean missi= ng the discussion but joining the call means we get additional voices for framing the discuss= ion around each issue. The conferencing info is sent separately to the group, but the short versio= n of it is: ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&RT=3DMiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting doe= s not require a password.) 4. Click "Join". Cheers, Morteza & Leif --_000_CA3B67220D628A4780D6FEB31F18A3E32ABCA677xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <3A310AE30FA7DC42BBD92EBE9F1979F4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi folks,

Just a reminder of our upcoming conf call:

Here is the agenda for the 4/9 conference call:

- Issue tracker reivew focused on the following issues: 2,9,10,13,24,34,35,= 37,39,42 & 46

The intent of the confcalls is to agree on a jump-off point for discussions= on these issues
which will then be concluded on the list. Missing a call doesn't mean missi= ng the discussion
but joining the call means we get additional voices for framing the discuss= ion around each
issue.

The conferencing info is sent separately to the group, but the short v= ersion of it is:

---------------------------------------------------= ---- 
To join the online meeting (Now from mobile devices!)&nb= sp;
-------------------------------------------------------&= nbsp;
1. Go to https://go.webex.com/go/j.ph= p?ED=3D153193777&UID=3D0&RT=3DMiM0 
2. If requested, enter your name and email address. = ;
3. If a password is required, enter the meeting password= : (This meeting does not require a password.) 
4. Click "Join". 


Cheers,
Morteza & Leif
 --_000_CA3B67220D628A4780D6FEB31F18A3E32ABCA677xmbrcdx08ciscoc_-- From barryleiba.mailing.lists@gmail.com Wed Sep 4 08:12:39 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2685521F99D5 for ; Wed, 4 Sep 2013 08:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.008 X-Spam-Level: X-Spam-Status: No, score=-102.008 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jK+xbjb943su for ; Wed, 4 Sep 2013 08:12:38 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 810EF21F99D0 for ; Wed, 4 Sep 2013 08:12:33 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id x14so297623vbb.9 for ; Wed, 04 Sep 2013 08:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rx8uxHbsKBh1RMvjIzaVjdLBpeV1kNdvO+ywYUGa7rI=; b=Mz9R+y8xkOJ0nQYoJAxk/qXAY0Bs6Djz7t1Qmta250r4IM/v7dwoYQizVCVGmt27Sr WKG7O5AN39WixSnaRiOGNpFvDOCMMERPczJvHAjvKd0lxn+NunRyA4Z4ykZGZVIJ+P97 6YzlItMzf/iExvwSJR6JO8Ew+GKoE01wTp9+xfTUZE+2coomeREDnOdtae5KT8z4GFj9 Zs5MkQPjGhgNDDhFNzyxkylJSpho4TvtrZ2vONGwLQwWCIl1pJO4OMqVs2gOW56eRaIb /4S93phsMsJ5TbJGGnxPQhl3/8u3U12xsrKd3XBvDCdXh8f3Chbr4pt9z5kQqVgzXvC8 ZZ2w== MIME-Version: 1.0 X-Received: by 10.58.137.167 with SMTP id qj7mr3051491veb.1.1378307552954; Wed, 04 Sep 2013 08:12:32 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.215.16 with HTTP; Wed, 4 Sep 2013 08:12:32 -0700 (PDT) In-Reply-To: References: <5215B177.2010502@mnt.se> Date: Wed, 4 Sep 2013 11:12:32 -0400 X-Google-Sender-Auth: gFA72U9ADYFQKyC_hWpLdjl8Hig Message-ID: From: Barry Leiba To: "Morteza Ansari (moransar)" Content-Type: multipart/mixed; boundary=047d7b677efa15cea104e5903ce2 Cc: "scim@ietf.org" Subject: Re: [scim] Reminder - SCIM WG conf call on Sep. 9th 11:00AM Pacific time X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 15:12:39 -0000 --047d7b677efa15cea104e5903ce2 Content-Type: text/plain; charset=ISO-8859-1 > Here is the agenda for the 4/9 conference call: > > - Issue tracker reivew focused on the following issues: > 2,9,10,13,24,34,35,37,39,42 & 46 I had a few minutes, so I took the liberty of putting the attached PPT together, which we can share in WebEX. Barry --047d7b677efa15cea104e5903ce2 Content-Type: application/vnd.ms-powerpoint; name="scim-2013-09-04.ppt" Content-Disposition: attachment; filename="scim-2013-09-04.ppt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hl6opzp50 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAAQAAAAAAAAAA EAAAmQAAAAEAAAD+////AAAAAAAAAAARAAAAEgAAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////mAAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEwAAAP3////9////FAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgA AABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAA AFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAA ZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABz AAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAH4AAAB/AAAAgAAAAFIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAACAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAJy0jBiBqc4B mgAAAIAAAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAA9v8AAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIQAAAAoFQAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjwAAACQRAAAAAAAADwDo A+8jAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAABAAAAAgAAAAAAAAAAAAAAAQAAAAAAAAEPAAkE jBYAAAAACgQEAAAARgAAAA8A1w8YAQAAAADTDwQAAAAWAAAAAAC6D34AAABoAHQAdABwADoALwAv AHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUA YgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0AbAAQ ALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0A YQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAw ADAAOQAyADkALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAYAAAAAAC6D34AAABoAHQAdABwADoA LwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3 AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0A bAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBs AC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMA ZwAwADAAOQAyADkALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAaAAAAAAC6D34AAABoAHQAdABw ADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUA LwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0 AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEA aQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBt AHMAZwAwADAAOQAyADkALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAcAAAAAAC6D34AAABoAHQA dABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2 AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4A aAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBt AGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQA LwBtAHMAZwAwADAAOQAyADkALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAeAAAAAAC6D34AAABo AHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgA aQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5 AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcA LwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBu AHQALwBtAHMAZwAwADAAOQAyADkALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAgAAAAAAC6D34A AABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBj AGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAxADAA MgA3AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwBy AGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIA ZQBuAHQALwBtAHMAZwAwADEAMAAyADcALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAiAAAAAAC6 D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEA cgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAx ADAAMgA3AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4A bwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQBy AHIAZQBuAHQALwBtAHMAZwAwADEAMAAyADcALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAkAAAA AAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAt AGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcA MAAxADAAMgA3AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABm AC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMA dQByAHIAZQBuAHQALwBtAHMAZwAwADEAMAAyADcALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAm AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkA bAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBz AGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUA dABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAv AGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADEAMAAyADcALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQA AAAoAAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBh AGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8A bQBzAGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBp AGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkA bQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADEAMAAyADcALgBoAHQAbQBsAA8A1w8YAQAAAADT DwQAAAA0AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8A bQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0 AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcA LgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBj AGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADAAOQAyADkALgBoAHQAbQBsAA8A1w8YAQAA AADTDwQAAAA2AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBn AC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUA bgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3 AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8A cwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADAAOQAyADkALgBoAHQAbQBsAA8A1w8Y AQAAAADTDwQAAAA4AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8A cgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgBy AGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8A dwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBi AC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADAAOQAyADkALgBoAHQAbQBsAA8A 1w8YAQAAAADTDwQAAAA6AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAu AG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUA cgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAv AC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcA ZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADAAOQAyADkALgBoAHQAbQBs AA8A1w8YAQAAAADTDwQAAAA8AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQA ZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBj AHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAA OgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAv AHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADAAOQAyADkALgBoAHQA bQBsAA8A1w8YAQAAAADTDwQAAAA+AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBl AHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0A LwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0 AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYA ZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADEAMAAyADcALgBo AHQAbQBsAA8A1w8YAQAAAADTDwQAAABAAAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4A aQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBp AG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQALoPfgAAAGgA dAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABp AHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADEAMAAyADcA LgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAABCAAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3 AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMA YwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQALoPfgAA AGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMA aABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADEAMAAy ADcALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAABEAAAAAAC6D34AAABoAHQAdABwADoALwAvAHcA dwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAv AHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQALoP fgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQBy AGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADEA MAAyADcALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAABGAAAAAAC6D34AAABoAHQAdABwADoALwAv AHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUA YgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQ ALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0A YQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAw ADEAMAAyADcALgBoAHQAbQBsAA8A8gOuAQAALwDIDwwAAAAwANIPBAAAAAEAAAAPANUH5AAAAAAA tw9EAAAAQwBhAGwAaQBiAHIAaQAAAP39/f39/f39/f39/f39/f0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAKwQALcPRAAAAC3/M/8gADD/tDC3MMMwrzAAAP39/f39/f39/f39/f39 /f0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACsIAC3D0QAAABBAHIAaQBhAGwAAAD9 /f39/f39/f39/f39/f39AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArAAA pA8IAAAAgABAAAAAAAAAAKUPDgAAAAAAAIguAAAAQAIHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACj D24AAAAFAP/9PwAAACIgAgBkAAAAAAAAAGQAAAAAAAAAAAAgAQAAAAAHAAAA///vAAAAAAABAAAA //8SAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAA AA8ACwTMAAAADwAA8MQAAAAAAAbweAAAAAM0AAAOAAAAKgAAAA0AAAABAAAABwAAAAIAAAADAAAA AwAAAAMAAAAEAAAAAwAAAAUAAAADAAAABgAAAAMAAAAHAAAAAwAAAAgAAAADAAAACQAAAAMAAAAK AAAAAwAAAAsAAAADAAAADAAAAAMAAAANAAAAAwAAAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAA wAEBAAAI/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAA AAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQByQBAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAA ZAAAAKfYYAC4NPm/cCD5vwgAAABAzr55TmBLAAAAAAAAAAAAAAEAAA8A+gNnAAAAAAD+AwMAAAAA AAEAAP0DNAAAAHwAAABkAAAAfAAAAGQAAABYBtWGCAAAAAgAAAAoIPm/AwAAAJs++b/g+v//oP// /wEAZoRwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAA8AiBNpAAAADwCKEykAAAAAALoP EAAAAF8AXwBfAFAAUABUADEAMgAAAIsTCQAAAAAAJQQBAAAAAA8AihMwAAAAAAC6DxAAAABfAF8A XwBQAFAAVAAxADAAAACLExAAAAAAAA0ECAAAAADAAAAAwAAAPwDZDwwAAAAAANoPBAAAAA0AAgBP ANkPDAAAAAAA2g8EAAAAAAACAA8A8A9QAQAAAADzAxQAAAADAAAABAAAAAAAAAAAAQAAAAAAAAAA 8wMUAAAABAAAAAQAAAAAAAAAAQEAAAAAAAAAAPMDFAAAAAUAAAAEAAAAAAAAAAIBAAAAAAAAAADz AxQAAAAGAAAABAAAAAAAAAADAQAAAAAAAAAA8wMUAAAABwAAAAQAAAAAAAAABAEAAAAAAAAAAPMD FAAAAAgAAAAEAAAAAAAAAAUBAAAAAAAAAADzAxQAAAAJAAAABAAAAAAAAAAGAQAAAAAAAAAA8wMU AAAACgAAAAQAAAAAAAAABwEAAAAAAAAAAPMDFAAAAAsAAAAEAAAAAAAAAAgBAAAAAAAAAADzAxQA AAAMAAAABAAAAAAAAAAJAQAAAAAAAAAA8wMUAAAADQAAAAQAAAAAAAAACgEAAAAAAAAAAPMDFAAA AA4AAAAEAAAAAAAAAAsBAAAAAAAAAAAoBMEHAABQSwMEFAAGAAgAAAAhAJ3GccL2AAAAqQEAABMA CAJbQ29udGVudF9UeXBlc10ueG1sIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgQAAAIIAAACDAAAA/v///4UA AACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAAD+////kAAAAJEAAACSAAAAkwAA AJQAAACVAAAAlgAAAJcAAAD+/////v////7////+//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8kM1qwzAQhO+FvoPQtVhyeyilxM6hP8e20PQBtvLa FtEf2k2I376yk0IpIadFu5qZj1mtD96JPWayMTTyVtVSYDCxs2Fo5NfmtXqQghhCBy4GbOSEJNft 9dVqMyUkUdSBGjkyp0etyYzogVRMGMqlj9kDl2cedAKzhQH1XV3faxMDY+CKZw/Zrp6xh51j8XIo 6yNJkUvxdPw3RzUSUnLWABdQPV/1WV1GRxeE+9D9o6tOZKooF3MabaKbU8J7qSbbDsUHZH4DXzg0 w7fDT54ckrqMeSYt9r012EWz86UBlTJSmUuwd+qP9S+BXopufwAAAP//AwBQSwMEFAAGAAgAAAAh AO3kDEu7AAAAJgEAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEj80KwjAQhO+C7xD2blM9iEjTXkTw qvUB1nT7g2kSklXs25tjC4LH2WG+2Smqz2jEm0IcnFWwzXIQZLVrBtspuNfnzQFEZLQNGmdJwUQR qnK9Kq5kkFMo9oOPIlFsVNAz+6OUUfc0YsycJ5uc1oUROcnQSY/6iR3JXZ7vZZgzoFwwxaVREC7N FkQ9+dT8n+3adtB0cvo1kuUfFZLxYejGk0krRI2hI1YwO2bpW5BlIRfryi8AAAD//wMAUEsDBBQA BgAIAAAAIQDY/Y2PrAAAALYAAAAPAAAAdGFibGVTdHlsZXMueG1sDMxJDoIwGEDhvYl3aP59LUNR JBTCICt36gEqlCHpQGijEuPdZfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97g2NA1nHdcWm0YLAK C3m236U8cU95c6sUV+vQpmibcAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h705UkgecdieKTBtSJ nsE3qoIgorTAp8vliGlIA1x6NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAQItABQABgAIAAAAIQCd xnHC9gAAAKkBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG AAgAAAAhAO3kDEu7AAAAJgEAAAsAAAAAAAAAAAAAAAAALwMAAF9yZWxzLy5yZWxzUEsBAi0AFAAG AAgAAAAhANj9jY+sAAAAtgAAAA8AAAAAAAAAAAAAAAAAGwYAAHRhYmxlU3R5bGVzLnhtbFBLBQYA AAAAAwADALcAAAD0BgAAAAAAAOoDAAAAAA8A+ANNfwAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAA AAAAAAIA+b9gAPAHIAAAAP///wAAAAAA7uzhAB9JfQBPgb0AwFBNAAAA/wCAAIAAAACjDz4AAAAB AP/9PwAAACIgAgBkAAAAAAABAGQAAAAAAAAAAAAgAQAAAAAHAAAA///vAAAAAAABAAAA//8sAAAA AAEAABAAow98AAAABQD//T8AAwAiIAIAZAAAAAAAAABkABQAAADYAAAAIAEAAAAABwAAAP//7wAA AAAAAQAAAP//IAAAAAABAACABQAAEyDUASABAAACABwAgAUAACIg0AJAAgAAAgAYAIAFAAATIPAD YAMAAAIAFACABQAAuwAQBYAEAAAAACAAow9uAAAABQD//T8AAAAiIAIAZAAAAAAAAABkAB4AAAAA AAAAIAEAAAAABwAAAP//7wAAAAAAAQAAAP//DAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAA AAAABQAAYANgAwAAAAAABQAAgASABAAAAABAAKMPbgAAAAUA//0/AAAAIiACAGQAAAAAAAAAZAAA AAAAAAAAACABAAAAAAcAAAD//+8AAAAAAAEAAAD//xIAAAAAAQAAAAUAACABIAEAAAAAAAUAAEAC QAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAIAAQAAAAAAAAAB AAEJAAACAAEAIAEAAAAAAgABCQAAAgABAEACAAAAAAMAAQkAAAIAAQBgAwAAAAAEAAEJAAACAAEA gAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABwAAQAAAAAAAAAC ABgAAgAAAAAAAAACABQAAwAAAAAAAAACABIABAAAAAAAAAACABIAgACjDz4AAAAFAAAAAAAAAAAA AgAYAAEAAAAAAAAAAgAUAAIAAAAAAAAAAgASAAMAAAAAAAAAAgAQAAQAAAAAAAAAAgAQAAAAIwRT BgAAUEsDBBQABgAIAAAAIQCbEwW7+gAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy2rD MBBF94X+g9C2WHK6KKXYzqKPXR+L9AMGeWyL6oVGCcnfd+ykEErIapjHnXu4zXrvndhhJhtDK1eq lgKDib0NYyu/N2/VoxRUIPTgYsBWHpDkuru9aTaHhCRYHaiVUynpSWsyE3ogFRMG3gwxeyjc5lEn MD8wor6v6wdtYigYSlXmH7JrXnCArSvidc/jIwnLpXg+3s1WrYSUnDVQGFTPW31Rl9HRFeEu9P/o qhOZYuXynCab6O7k8MnRZNuj+IJcPsAzh+4zaXI8fAcqnNx5s1LXwS/4x2GwBvtotp4zUSkjcV1Q vFNnRn9Meom++wUAAP//AwBQSwMEFAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsAAABfcmVscy8ucmVs c4SPwQrCMBBE74L/EPZu03oQkaa9iNCDF9EPWJJtG2yTkI2if2+OFgSPwzBvZur2NU/iSZGtdwqq ogRBTntj3aDgdj1t9iA4oTM4eUcK3sTQNutVfaEJUw7xaAOLTHGsYEwpHKRkPdKMXPhALju9jzOm LOMgA+o7DiS3ZbmT8ZsBzYIpOqMgdqYCcX2H3Pyf7fveajp6/ZjJpR8Vkidr6IycKGYsxoGSAhP5 21iIqsj7QTa1XPxtPgAAAP//AwBQSwMEFAAGAAgAAAAhAI+8DdIjAwAAHBsAACEAAABkcnMvc2xp ZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsmUtu2zAQhvcFegeB28KxJT8kC5aDJkVWQWHUyQFo mbbVUJRA0WncVe/QG/Qa3fUoPUlnSDpWYivIwgKiwhvDIqUROd9wOD81On9IuXPPZJFkIiLuWYc4 TMTZPBHLiNzeXLUC4hSKijnlmWAR2bCCnI/fvxvloXqYqg1nhQMmRBHSiKyUysN2u4hXLKXFWZYz AX2LTKZUwaVctueSfgPTKW97nc6gndJEEPu8fM3z2WKRxOxTFq9TJpQxIhmnCoZfrJK82FrLX2Mt l6wAM/rpJ0Ma4/QSxZme4XhEQ37P3XwiHcqX4KdYSeLM2eKGzqbfI9Lr+zAd4kjFI4IepNfiQt6B P4mDYxP2ErpWVCzBAZO1iBX2o+0ijy/Ywv6bxMq5p9pOezxql3tn68/AAFppCO/+AqMp8OU9fPUd k8gPh6ENZTyZXyWc6wvkwS65NIbVg0us6fJdeqCO2uRsQWMg/SH92uIK76Qho886GDUdcfGsIy6s bTNCPQPrO/j/1Kt5OMvmmz0Xp1ReR6Tb84Y4sUTMAVFEWtsGQ4DX7n9wJbx/n8FVJlRp0h9lQrlx xmx9uaLSieEnIn9//DKtJVRdHSV1oBJVqESrApVovYhKR7yHEW9w+ICjX8bhBX0fGxqD4+ceDi+o a+UcEQcywCUIi6i7w+G6vS6G5255eF4wwIbG8NhfHl5tmeyIPBCC5dEr8QDf68X9mK4ax+PA+tAR 9sbTFUKwPPo7Hl6n7+toaiqPP7/301UTcCADi2NQwtF3ezo7NRXHod0cC4R6Cq8jpiuEYHn4JR5D 39Wb34mHqbFfLoSPyAMhWB7Bjoepbf+37bwJ6wMhWB7DEo8gGDR8Oz9QXjWBB0LQQrEkDfMwUysm H4UiKKqJoWa1FQdRHREmWrdT3DVBNO9u2Qp3I2NqKZBLCs9k1TdeMuFBho35ksLbHmIcX0A0zT+H JdfQNSctJ/9USKCu79akQJsWQIc1iRt4gS66ThFUoRL0EcYpRcOWVVG2+z1zhHiKoIo6Goo2LftP DqoobAd9/5Sk9WnqY6VZLi7xC4X9rDX+BwAA//8DAFBLAQItABQABgAIAAAAIQCbEwW7+gAAALsB AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAI7q Kvq+AAAAOAEAAAsAAAAAAAAAAAAAAAAAKwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAI+8 DdIjAwAAHBsAACEAAAAAAAAAAAAAAAAAEgIAAGRycy9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIx LnhtbFBLBQYAAAAAAwADAMkAAAB0BQAAAAAPAAwEuCIAAA8AAvCwIgAAEAAI8AgAAAAGAAAABgQA AA8AA/AkHQAADwAE8CgAAAABAAnwEAAAACgmTqwAAAAAAAAAABAqAQACAArwCAAAAAAEAAAFAAAA DwAE8PoAAAASAArwCAAAAAIEAAAACgAAkwAL8F4AAAB/AAEA7wGAALhPwoSHAAEAAAC/AAAABgC/ AQEAEQD/AREAGQA/AwAACACAwygAAAC/AwAAAgBUAGkAdABsAGUAIABQAGwAYQBjAGUAaABvAGwA ZABlAHIAIAAxAAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAAAQD5vw8ADfBU AAAAAACfDwQAAAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAA og8GAAAAIQAAAAAAAACqDwoAAAAhAAAAAQAAAAAADwAE8DwBAAASAArwCAAAAAMEAAAACgAAgwAL 8FYAAAB/AAEA7wGAAMglZoS/AAAABgC/AQEAEQD/AREAGQA/AwAACACAwyYAAAC/AwAAAgBUAGUA eAB0ACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAA AAAAwwsIAAAAAQAAAAIA+b8PAA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRp dCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZl bA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoA AABTAAAAAQAAAAAADwAE8PgIAAASAArwCAAAAAQEAAAACgAAkwAL8FwAAAB/AAEA7wGAAFiBZYSH AAEAAAC/AAAABgC/AQEAEQD/AREAGQA/AwAACACAwyYAAAC/AwAAAgBEAGEAdABlACAAUABsAGEA YwBlAGgAbwBsAGQAZQByACAAMwAAABMAIvHkBwAAqcPeBwAAUEsDBBQABgAIAAAAIQAyPL0++wAA AOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7 klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9 bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO6 38r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0zi YVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQA BgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC 1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocT RzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFU B2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L 8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQCzq2l2egMAAIcKAAAQAAAAZHJzL3NoYXBl eG1sLnhtbOxVTW/jNhC9F+h/IHgtvJbijzRC5EWSxtsCxsJYZ8+LMUXFqilSIGnXTtH/3kdSjrN7 KBabPRRFAUOmNEPOmzczj9dvD61ie2ldY3TJ8zcZZ1ILUzX6seQfH+aDnzlznnRFymhZ8qN0/O3s xx+uu8J1DJu1K7qSb7zviuHQiY1syb0xndSw1ca25PFqH4edlU5qTx6BWjW8yLLpsKVG8xmO0vtV t7RhJd7vl5Y1VcnHnGlqEfIX8pItFQm5MaqSlo34sHdNuwhQFkZsXY+HvgZPZekPJPkZFKbNO4ts 8hBgGMGccGnACkG7DfPHDqgqD2KeEIlUzQH4UPKLflvyxf5zWi6mR8Whtu1rUc6uqTB1zRBxPLkE kZwdSz4dTfDLAgQq5MEzERDlo9E0OAh4jKaT/GISMSYgwbOzzr+T5tWgWDio5FYKj4pSQfuF84HF c4hIaSKiK/zh1lTH4LnGP0qeWunbS4ceRvyNsU+cqd+0K/lVPh4jdR9fIlOc2ZeW9WcWr+6MKjl2 kBY4p+TC20Sncn7lj0q+FmRIV+1VjmZgpB4xcCqSVcn6Az6FdspDPYOfM6qp5o1S8SXMlbxTlu0J GP0hjz6+0T59uZxk2Jf4jkMYnCP7L85BLVKkaOiBpHWfYIh1mupvLkU8BOm0ZBeRTyw+xAVCxv9G V5CCxHVPAwOyB1qvQMGpqa1P3pIW+tZuw1iy2mh/E7fQzhtUGnqiezMqtyH9iKFe7rTA8YkkpVed iCR2Yil6vnLQ9UzYS49bWZ98vUvcPvPaibP1pvb/4Ndb1ztU4eEQR3K9Wz09L+dI4/nlPYQ1unha p6E51amfn6A8VNSqirr4Z3ZzcXk/vpoPxtndfDCZjiHSV/ejQXY5zabTPLvP8vu/0PdRpjZ1kM+H ppWxYyzqst21TWt+b1JJwFjJpR58XCU9iw3I1qlO8bkruQbEcA/YZgvp02YVV5xtpQ23RtQgQVDO 3rETcacO+q+aJ/lrfF2Tk6oJtwhKpc3SGlPHtWv9nZKEo1LvKx0S1ia0f+IgfXnRyxiQ7zIT0Mq6 hmidiN8tdF+YXYjer2ObRUZrXEMl/6nVA+V7raUvDJKSQbgvDML1E4oqhASDDPw/JN91SPzsU7hy MJt4YmICzVJXS7IUFPZf1/oB33+928/8x6p0eJ7vfyxdN/sbAAD//wMAUEsDBBQABgAIAAAAIQBZ eKsk1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/BSgMxFEX3gv8QnuDOZhQtOjYtRSjqwsXU gu3uzeR1MnTyMiTpNP17gwu7vNzLuZzZItlejORD51jB/aQAQdw43XGrYPO9unsGESKyxt4xKThT gMX8+mqGpXYnrmhcx1ZkCIcSFZgYh1LK0BiyGCZuIM7d3nmLMUffSu3xlOG2lw9FMZUWO84PBgd6 M9Qc1kerYOufpnW9Waaqxuqw+ypWx2R6pW5v0vIVRKQUL+PPl58xxf/yD/WhFTyC2L+fa9/pCkMk ryC7ZdNsCXL+CwAA//8DAFBLAQItABQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAA AAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAA AAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhALOraXZ6AwAAhwoAABAAAAAA AAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAWXirJNYAAAD5AAAA DwAAAAAAAAAAAAAAAADQBQAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAANMGAAAAAAAA EPAIAAAApA8gAWAGihAPABHwEAAAAAAAwwsIAAAAAgAAAAcB+b8PAA3waAAAAAAAnw8EAAAABAAA AAAAoA8CAAAAKgAAAKEPGAAAAAIAAAAAAAAAAAACAAAAAAAGAAwAiYmJ/gAA+A8EAAAAAAAAAAAA qg8KAAAAAgAAAAEAAAAAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8IgIAAASAArwCAAAAAUEAAAA CgAAkwAL8GAAAAB/AAEA7wGAAGiWYISHAAEAAAC/AAAABgC/AQEAEQD/AREAGQA/AwAACACAwyoA AAC/AwAAAgBGAG8AbwB0AGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADQAAAATACLxhAcA AKnDfgcAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyU kUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1dhrVjIl9 oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwRSSZdSBNk OabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5lUs48glw JvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L91e4C5+U cP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAACwAAAF9yZWxz Ly5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BBv9D3Ce32 lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCWkrZaix0p oDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz33j6iahkx 0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQUAAYACAAA ACEAt9/snBoDAABZBwAAEAAAAGRycy9zaGFwZXhtbC54bWysVW1P2zAQ/j5p/8Hy1wnalJaXiBQB EmxShSoKP+DqOG1W5+zZTtfy63e20xb4ME0wKUrOvrPvuedecnm1aRRbS+tqjQXPjvucSRS6rHFR 8Oenu6NzzpwHLEFplAXfSsevxl+/XJrcGUaH0eWm4EvvTd7rObGUDbhjbSSSrtK2AU9Lu+gZK51E D54cNao36PdPew3UyMd0Fa5nZmqDJB7WU8vqsuAjzhAacnmntZeWTRUIudSqJHnIe51xOgcEZqLF ynWI4F8QlRZ+U5hvwDDU95biyYKDXoSzQ4YELDg1S+a3hnBV3hI3LwX/1YIlhJxgbwp+0h1N9nTH ITgXg4R8U9nms0jHl5DrqmLBYzYYEp+cbQt+ejKipx8wQC43ngkyGJxfjE6DgSCLk9NRNhhFkAlJ sDTW+XupP42KhYsKbqXwlFjIYT1xPlB5cBF5TUyY3G9udLkNlnP6UuZTRX08f1TK5H+p7Qtn6ge6 gl9kwyGF7uNiODob0MK+1szfaLy61argZAQo6J6CC8pzpFM5P/NbJT8LMoSr1iqjamCgFtR3wUXY LWX1SJuhqLKQ0bDntKrLu1qpuAgNJm+VZWsglH6TRRtfo087Z6M+nUuMx24MxpH/V/dQNpKnqOig JLkLMfjatfeHkxEvoXAasJPIKAmPUSCX8VtjSTMhsb0nghG2J5jPiISYrpAvn+wlTPDGrkJ/skqj v46HoPWask2jBTs1HVkCLqi7py0KcpBoUjgzItJoxFR0jGVE2J6y1xY3strZepfY3TNrxEF7Xfm/ 2HXaeUt5eNrEOpq3s5e9eEdh7BcPNGOjiYd5apxdplJGu/khsZyChVAqq7apG/2zTrRSzAWXePQ8 S5MpFhGbJ67juy04kpMw1G29oimGehYlzlbShl9AnCQCaAh2hkbEkxiGuapf5Pe4nIOTqg6/BCIb 9dRqXQU5UKEwvFGHqk3A086rEqS6/i+lTEOuqmja7NhqJ9ix2QbvnRxrI47tin4iBf/W4JHy3ZCE dwoJSSHcO4VwXWMd+I9NY+h9GGUkOjP+AwAA//8DAFBLAwQUAAYACAAAACEA/1qZ0dYAAAD5AAAA DwAAAGRycy9kb3ducmV2LnhtbESPsW7CMBRF90r9B+tV6lYcWoFQwCAERe3SIZQBtpf4EVvEdmQb cP6+Vod2vLpX5+osVsl07EY+aGcFjEcFMLKNk9q2Ag7fu5cZsBDRSuycJQEDBVgtHx8WWEp3txXd 9rFlGWJDiQJUjH3JeWgUGQwj15PN3dl5gzFH33Lp8Z7hpuOvRTHlBrXNDwp72ihqLvurEXD0k2ld H9apqrG6nL6K3TWpTojnp7SeA4uU4v94q2fvb8Nf+Yv6lAImwM4fQ+21rDBE8gKyWzbNlsCXPwAA AP//AwBQSwECLQAUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwB AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQC33+ycGgMAAFkHAAAQAAAAAAAAAAAAAAAAACgC AABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAP9amdHWAAAA+QAAAA8AAAAAAAAAAAAA AAAAcAUAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAABzBgAAAAAAABDwCAAAAKQPsAfQ DooQDwAR8BAAAAAAAMMLCAAAAAMAAAAJAvm/DwAN8FQAAAAAAJ8PBAAAAAQAAAAAAKEPGgAAAAEA AAAAAAAIAAABAAEAAAAAAAYADACJiYn+AACqDwoAAAABAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQ AvADEAUPAATwFgkAABIACvAIAAAABgQAAAAKAACTAAvwbAAAAH8AAQDvAYAAqKJIhYcAAQAAAL8A AAAGAL8BAQARAP8BEQAZAD8DAAAIAIDDNgAAAL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIAZQBy ACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAANQAAABMAIvHwBwAAqcPqBwAAUEsDBBQABgAIAAAA IQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJN uiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVac gRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQl QzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0 yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD/ /wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo 7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz 9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSm bd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+b N0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQBhJyUVhgMAAJUKAAAQAAAA ZHJzL3NoYXBleG1sLnhtbOxVXW/bNhR9H7D/QPB1cG3ZltIKkYs4WboBRmDU6fNAUVSsmiJVkvLs DPvvOyTlOO3DUDR9KIYBgnSpe8l77rkfvHx7aCXZC2MbrQqavJpQIhTXVaMeCvrh/nb0mhLrmKqY 1EoU9Cgsfbv4+afLLrcdwWZl866gW+e6fDy2fCtaZl/pTijoam1a5rA0D+POCCuUYw6OWjmeTibZ uGWNogscpfabbm28xO/2a0OaqqAZJYq1cLmRTSXIXd+WwpC1ZFxstawgp3Q8bIm7GSCtNN/ZARf7 GlyVYX8i2M8gEaXfGUSVeAfjAOqETwGed9ptiTt2QGdlBWgg6bGgn3pmnDAU+A8FnQ+74xYcc47S hmhZfqhN+1Kwi0uW67om8Jil6QzEUnKEPEvxTDwGlouDIxwG02Q2y7wBh8UsS5Np4HAckXjLzlj3 TugXoyL+oIIawR0yzHK2X1nn2Ty7CNRGJrrcHZa6OnrLEl+UQCytb08hahr+t9o8UiJ/V7agb5L5 HKG7sJinF1MszHNN+ZnGyWstCwojpjjOKSh3JtIprdu4oxQvBenDlXuZoBoIkw9oQBPIqkT9Hr98 SSU+n97OarTBbSNlWPg+E9fSkD0DRndIgo1rlIt/LtIJ9kW+Q1N648D+s3OQi+gpKAYgUR4C9L5O Xf7NqQiHIJyWmVXgE8L7IMBl+DaqwmiIXA80ECC7Z+UGFIRU+Vy5aC3YSi3NzrcnqbVyV2EL651G pjFf1KDGli1TD2juda84jo8kSbXpeCCx42s+8JWArifCnlssRX2ydTZy+8Rrx8/aq9r9i92gLXtk 4f4QWrLsN49P4i3CeFrcYdAGE8fK2DSnPA394ycQy2tZhTn5102aTpY302yUTLPZKHkzn4yWy+xi lKavb369Wl5cp9nt36j7YVxhmCoMLH+EQVZ2fdu0+mMTEwK+CirU6MMmTrRQfqSMWQrvvqAKAP2t YJodBqDSmyBRshPG3yFhAnGG+TkYdjzsVP42kM2j+C0sS2aFbPydgkQpvTZa10G2rbuWguGoWPlS eaxK++KPDMQ/zyoZ7fFdOgKTsq4xsk609ys1pKX33gc5FFngs8ZlVNBfWjWSbpi07AuFYFHB7RcK bof+RBZ8gH4I/N8i37VF3OIPf+GgM/FGv3iaharWzDA/X3+40vf4/uvVfuY/ZKXD+3z7Q7Td4h8A AAD//wMAUEsDBBQABgAIAAAAIQBWHigD1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/BSgMx FEX3gv8QnuDOZlQcZGxailDUhcLULnT3ZvI6GTp5GZNMm/69wYVdXu7lXM58mewgDuRD71jB7awA Qdw63XOnYPu5vnkEESKyxsExKThRgOXi8mKOlXZHrumwiZ3IEA4VKjAxjpWUoTVkMczcSJy7nfMW Y46+k9rjMcPtIO+KopQWe84PBkd6NtTuN5NV8OUfyqbZrlLdYL3/fi/WUzKDUtdXafUEIlKK5zFN bz/3H//lH+pVKyhB7F5Oje91jSGSV5Ddsmm2BLn4BQAA//8DAFBLAQItABQABgAIAAAAIQAyPL0+ +wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhAGEnJRWGAwAAlQoAABAAAAAAAAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAU AAYACAAAACEAVh4oA9YAAAD5AAAADwAAAAAAAAAAAAAAAADcBQAAZHJzL2Rvd25yZXYueG1sUEsF BgAAAAAEAAQA9QAAAN8GAAAAAAAAEPAIAAAApA8gEGAVihAPABHwEAAAAAAAwwsIAAAABAAAAAgC +b8PAA3wagAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPGgAAAAIAAAAAAAAIAAACAAIAAAAA AAYADACJiYn+AADYDwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvAD EAUPAATwbAUAABIACvAIAAAAAQQAAAAMAABjAAvwJAAAAIEBAAAACIMBBQAACL8BEAAQAP8BAAAI AAQDCQAAAD8DAQABABMAIvEoBQAAqcMiBQAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAA W0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7 Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZC E9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4O e0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3y tOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCq i10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzO lrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997La HWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1Oma qvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUb uxsAAAD//wMAUEsDBBQABgAIAAAAIQBrS7SjvgAAABEBAAAQAAAAZHJzL3NoYXBleG1sLnhtbIyP TW4CMQxG90i9Q+R9SaYLhEaTYYHEAar2AJ6JCSMSJ0oCnd6e8CMkduxsf9J7/rrN7J04U8pTYA3N UoEgHoOZ2Gr4/dl9rkHkgmzQBSYN/5Rh038sutgOOB5tCic2okI4t1HDoZTYSpnHA3nMyxCJa7YP yWOpa7IyJsrEBUsVeie/lFpJjxNDf0Xab9qLycz1FaWaesP2xqKtSw8LvmMxCf9qhReBOKPTMNgG ZN/Jh+w+PZv0FwAAAP//AwBQSwMEFAAGAAgAAAAhAEtzQUzWAAAA/wAAAA8AAABkcnMvZG93bnJl di54bWxMj0FLw0AQhe+C/2EZwZvdKFgkzaYURQQPio2gx2l2uolmZ0N2m8b+eqde6uUxwxvefK9Y Tr5TIw2xDWzgepaBIq6DbdkZeK8er+5AxYRssQtMBn4owrI8Pyswt2HPbzSuk1MSwjFHA01Kfa51 rBvyGGehJxZvGwaPSdbBaTvgXsJ9p2+ybK49tiwfGuzpvqH6e73zBl4e5uPB3x5c9fn1utJT9ZE9 uydjLi+m1QJUoimdjuGIL+hQCtMm7NhG1RmQIulPxZN5c1RdFvo/d/kLAAD//wMAUEsBAi0AFAAG AAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEAa0u0o74AAAARAQAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1s LnhtbFBLAQItABQABgAIAAAAIQBLc0FM1gAAAP8AAAAPAAAAAAAAAAAAAAAAABQDAABkcnMvZG93 bnJldi54bWxQSwUGAAAAAAQABAD1AAAAFwQAAAAAEADwByAAAAD///8AAAAAAO7s4QAfSX0AT4G9 AMBQTQAAAP8AgACAAAAADgSIDAAAUEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRl bnRfVHlwZXNdLnhtbKyRy2rDMBBF94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQS AoVuBNLMvffMqFwfxkHtMSbnqdKrvNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU 6Z45PBiTbI8jpNwHJKm0Po7Aco2dCWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+K qjSEMDgLLKBmqpqzuohDuiDcU/OLLlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5 ZeYz0b5tncXG290o68hn48XsTwCr/4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AA AAA2AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb 69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGj PM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8Mw zJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBr eZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZ N2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzh xxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD/ /wMAUEsDBBQABgAIAAAAIQCTCm11EwcAAOcdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZ zW8bRRS/I/E/jPbexk6cNInqVLFjt9CmjWK3qMfx7tg7zezOamacxDfUHpGQEAVxQeLGAQGVWolL +WsCRVCk/gu8mdld78TjxinhQ9AcWu/s77157/c+5mOvXjtOGDokQlKeNoP65VqASBryiKajZnC3 3720HiCpcBphxlPSDCZEBte23n3nKt5UMUkIAvlUbuJmECuVbS4tyRCGsbzMM5LCuyEXCVbwKEZL kcBHoDdhS8u12tpSgmkaoBQnoPbOcEhDgvpaZbBVKO8weEyV1AMhEz2tmjgSBhsd1DVCTmSbCXSI WTOAeSJ+1CfHKkAMSwUvmkHN/AVLW1eX8GYuxNQc2Ypc1/zlcrlAdLBs5hSjQTlpvdvYuLJT6jcA pmZxnU6n3amX+gwAhyF4am2p6mx01+utQmcFZH/O6m7XVmsNF1/RvzJj80ar1VrdyG2xSg3I/mzM 4Ndra43tZQdvQBa/OoNvtLbb7TUHb0AWvzaD717ZWGu4eAOKGU0PZtA6oN1urr2EDDm74YWvA3y9 lsOnKMiGMrv0FEOeqnm5luAHXHQBoIEMK5oiNcnIEIeQxW3M6EBQPQHeJLjyxg6FcmZIz4VkKGim msH7GYaKmOp79fzbV8+folfPn5w8fHby8IeTR49OHn5vdTmCN3A6qgq+/PqT37/8EP329KuXjz/z 42UV//N3H/3046d+IFTQ1KIXnz/55dmTF198/Os3jz3wbYEHVXifJkSi2+QI7fMEfDPEuJaTgTif RD/GtCqxnY4kTrGexaO/o2IHfXuCGfbgWsRl8J6ADuIDXh8/cAzuxWKs8pA7nt2MEwe4yzlrceFl 4aaeq0Jzf5yO/JOLcRW3j/Ghb+42Tp34dsYZtE7qU9mOiWPmHsOpwiOSEoX0O35AiIev+5Q6vO7S UHDJhwrdp6iFqZeSPh042TQVukETiMvEZyDE2+Fm9x5qcebzeoccukioCsw8xvcJc2i8jscKJz6V fZywKuG3sIp9RvYmIqziOlJBpEeEcdSJiJQ+mTsC/K0E/SZ0D3/Yd9kkcZFC0QOfzluY8ypyhx+0 Y5xkPmyPpnEV+548gBTFaI8rH3yXuxWinyEOOJ0b7nuUOOE+uxvcpSPHpGmC6Ddj4YnldcKd/O1N 2BAT02qgrzvtOqHp2969cO/eFtRbPDdOdex5uNN9us1FRP/9bXoHj9M9ApUxu1a97dJvu3Twn+/S 8+r54nvztB1Dp9Z7J7vpNlvwZO4OfEgZ66kJI7ek2YRLWISiLgxqOXP6JOWJLIvhp65kmMDBjQQ2 Mkhw9QFVcS/GGWzg64FWMpK56pFEGZdwcDTDXt0aD4cAZY+dq/pAYjuHxGqXR3Z4RQ8X545SjbFq ZA63xUQrWsGik61cyZWCb28yWV0btfBsdWOaaYrObKXLmmJzQAfKS9dgsGQTdjcI9kTA8hqc//XU cPDBjESadxujIiwmCn9NiHKvrSMxjogNkTNcYbNuYlek0Ix/2j2bI+djs2QNSDvbCJMW8/NnQZIL BVOSQfB0NbG0WlssRUfNYGN1eTVAIc6awRCOvPAzySBoUu8HMRvBvVGohM3aM2vRFOnU4w1/VtXh FmNOwThlnAmpdrCMbQzNqzxULNUzWfuXVxs62S7GAU8zWcyKlXVIkX/MCgi1G1oyHJJQVYNdGdHc 2ce8E/KxIqIXR0dowMZiH0P4gVPtT0Ql3FyYgtYPcM2m2Tav3N6ad5rq5ZbB2XHMshjn3VJf0xQV Z+Gmn5Q2mKeKeeCb13bj3Pld0RV/Ua5U0/h/5opeDuAWYSXSEQjhlldgpCulGXChYg5dKItp2BWw 7pveAdkCV7XwGsiHu2bzvyCH+n9bc1aHKWs4DKp9OkKCwnKiYkHIHrQlk31nKKvnS49VyXJFJqMq 5srMmj0gh4T1dQ9c0z04QDGkuukmeRswuNP55z7nFTQY6T1Ktd6cTlYunbYG/u6Niy1mcOrUXkLn b8F/aWK5uk9XPytvxIs1suqIfjHdJTWKqnAWv42NfKo3NGGRBbiy1tqONePx8mphHERx1mMYLPcz GdwFIf0PrH9UhMx+uNALap/vQ29F8B3C8ocgqy/prgYZpBuk/TWAfY8dtMmkVVlq852PZq1YrC94 o1rOe4psbdki8T4n2eUmyp3OqcWLJDtn2OHajs2lGiJ7ukRhaFicQ0xgzBev6kcpPngAgd6B6/8x s5+pZAZPpg6yPWGya8CjSf6TSbvg2qzTZxiNZOk+GSIaHRfnj5IJW0L2U0mxRTZoLaYTrRRc8R0a XMEcr0XtalkKL58tXEqYmaFll8LmUs2nAD6U5Y1bH+0Ab5us9VoXV8EUS/8MZQsY76fMe/JZlDJ7 UHxtoN6AMnX8espypoC82cSDT50Cw9GrZ/ovLDo2003Kbv0BAAD//wMAUEsDBBQABgAIAAAAIQAN 0ZCftgAAABsBAAAnAAAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzhI9N CsIwFIT3gncIb2/TuhCRJt2I0K3UA4TkNQ02PyRR7O0NriwILodhvplpu5edyRNjMt4xaKoaCDrp lXGawW247I5AUhZOidk7ZLBggo5vN+0VZ5FLKE0mJFIoLjGYcg4nSpOc0IpU+YCuOKOPVuQio6ZB yLvQSPd1faDxmwF8xSS9YhB71QAZllCa/7P9OBqJZy8fFl3+UUFz2YUFKKLGzOAjm6pMBMpburrE 3wAAAP//AwBQSwECLQAUAAYACAAAACEAm+hwT/wAAAAcAgAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAAAAAAAAAAAAAA AC0BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAAAAAAAAAAAAA ABYCAAB0aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sUEsBAi0AFAAGAAgAAAAhAJMKbXUTBwAA 5x0AABYAAAAAAAAAAAAAAAAA0wIAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAA ACEADdGQn7YAAAAbAQAAJwAAAAAAAAAAAAAAAAAaCgAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVN YW5hZ2VyLnhtbC5yZWxzUEsFBgAAAAAFAAUAXQEAABULAAAAAAAADwQ6AQAAPD94bWwgdmVyc2lv bj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0KPGE6Y2xyTWFwIHht bG5zOmE9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9kcmF3aW5nbWwvMjAwNi9t YWluIiBiZzE9Imx0MSIgdHgxPSJkazEiIGJnMj0ibHQyIiB0eDI9ImRrMiIgYWNjZW50MT0iYWNj ZW50MSIgYWNjZW50Mj0iYWNjZW50MiIgYWNjZW50Mz0iYWNjZW50MyIgYWNjZW50ND0iYWNjZW50 NCIgYWNjZW50NT0iYWNjZW50NSIgYWNjZW50Nj0iYWNjZW50NiIgaGxpbms9ImhsaW5rIiBmb2xI bGluaz0iZm9sSGxpbmsiLz6wAB4E3gUAAFBLAwQUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAFtD b250ZW50X1R5cGVzXS54bWx8kMtOwzAQRfdI/IPlLYqdskAIJemCxwoBi/IBlj1JLPySx6mav2eS FglQ1dVoHnfu0W22B+/YHjLaGFq+ETVnEHQ0Ngwt/9y9VPecYVHBKBcDtHwG5Nvu+qrZzQmQkTpg y8dS0oOUqEfwCkVMEGjTx+xVoTYPMin9pQaQt3V9J3UMBUKpyvKDd80T9GpyhT0faHwkITlnj8e7 xarlKiVntSoEKpetPKvL4PCCcB/MP7rqRCZIuT7H0Sa8OTm8UzTZGmAfKpc35YlDmowSHQ1f1Ryn 8qfZiMvgZ/xj31sNJurJUyYiZUCqK4p34pfRD5Nco+++AQAA//8DAFBLAwQUAAYACAAAACEAcPA4 3L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZ KPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zrFdxvp80eBCd0BkfvSMFMDG2zXtVXGjHlEA82 sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAsmOJsFMSzqUDc5pCb/7N911lN R6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA//8DAFBLAwQUAAYACAAAACEA 8AjbFK0CAAC2BwAAIQAAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbLRVTW8aMRC9 V+p/sHxPFjZAyAqIWtr0kg9USO+u12SteG3LNlv49x3bayIIlZZWveyHPfNm5r0Ze3K7rQVqmLFc ySnuX/YwYpKqksuXKX5e3V2MMbKOyJIIJdkU75jFt7OPHya6sKK8Jzu1cQgwpC3IFFfO6SLLLK1Y Teyl0kzC3lqZmjj4NS9ZacgvwK5Flvd6o6wmXOLW33TxV+s1p+yLopuaSRdBDBPEQf624tomNN0F TRtmASZ4H6bkdhqqBWLcijvBPslytcUo2JsGdvp4BhTQpSiRJDUs/ABTTolAwR4BY2jFti6YWb0y jHkH2XwzeqkXJng/NguDeOnRWhSctRutWfiVYAYf2ZH7S0IixXZt6tmEFMAO2k4xiLjzT3AiBSSB aFykb6u0ejphS6uvJ6yzFAAy2AcF/XWs6H05eSrniJT+vrzoQwDjXtFXi6SCgj0PsU762CRUX7yP oysUNXFeD4yU4aBclKj1iqaBpuRtA9Up/z1Bo1F+M+hFmvLrwehqfMhV3hteh33P2HA87A/zYQiS kCBIhNaF235W5c4z/RPeIKhvmilmxBcfYYV1S7cTLOgBrJECSoIHGAviB43Ji+clDFrt5oIRGMRW OzebC05fkVOIldyhB2IdMyhQAGMJkBMQx0FvtJBMlgtiyPcjZM8qKSAy5J3yDSV4Zv+s49V7HX03 LQShrFKihFRyXyEMQhLsryT1xB0pCmMBPZv6obuyg+E1HCyh/08JO+r1b8Z+/38JC/2GRCP2Cv6j 0J7uoLM9EDqKGRSFRwoZ2Dqjt5aMKjimBGuY6AAfpD4DflVx0x39Ko5KZ77u1Ma4qnPyg3Ph+fok OpynZ49YmLR4A8CnvzPCyAjzQPRTEyqG2xIGex6WNNyP7TH4ZuIx0n07+w0AAP//AwBQSwECLQAU AAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht bFBLAQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVs c1BLAQItABQABgAIAAAAIQDwCNsUrQIAALYHAAAhAAAAAAAAAAAAAAAAABMCAABkcnMvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAA/wQAAAAAoAAeBJoFAABQSwME FAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDLTsMwEEX3SPyD 5S2KnbJACCXpgscKAYvyAZY9SSz8ksepmr9nkhYJUNXVaB537tFttgfv2B4y2hhavhE1ZxB0NDYM Lf/cvVT3nGFRwSgXA7R8BuTb7vqq2c0JkJE6YMvHUtKDlKhH8ApFTBBo08fsVaE2DzIp/aUGkLd1 fSd1DAVCqcryg3fNE/RqcoU9H2h8JCE5Z4/Hu8Wq5SolZ7UqBCqXrTyry+DwgnAfzD+66kQmSLk+ x9EmvDk5vFM02RpgHyqXN+WJQ5qMEh0NX9Ucp/Kn2YjL4Gf8Y99bDSbqyVMmImVAqiuKd+KX0Q+T XKPvvgEAAP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrC MBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDIaW+s 6xXcb6fNHgQndAZH70jBTAxts17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYyoH5g T3JbljsZvxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLv B9nUcvG3+QAAAP//AwBQSwMEFAAGAAgAAAAhAKBAHdJpAgAA1gYAACEAAABkcnMvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0MS54bWysVU1vGyEQvVfqf0Dck81HVVUr25HqNr3kw6qd3qcs9qKwgIBs 7X/fB+wmSupKttoLy8LMY96bGZhcbTvNeumDsmbKz0/POJNG2EaZzZQ/rK5PPnEWIpmGtDVyyncy 8KvZ+3cTVwfd3NDOPkUGDBNqmvI2RldXVRCt7CicWicN9tbWdxTx6zdV4+kXsDtdXZydfaw6UoYP /v4Qf7teKyG/WPHUSRMLiJeaIuIPrXJhRHOHoDkvA2Cy9+uQ4s6BLYSJqy1n2c73WDnnM1AXS90w Qx0WVipqySAQ+wFjJUizldzGbBbcykuZHEz/zbulW/jsfdcvPFNNQhtQeDVsDGb518AMk+qN+2ZE onq79t1sQjVUYdspR/J2aYQT1QiCibIoXlZFe7/HVrRf91hX4wGI4PlQ5N0VRn/SuRjpFFHOn1kV U4LrjRWPgRkLnol+oSfu+hEscU7wrmUlBTHpO9iVzazHaB+gaRYrbj/bZpeI/8Q3L1KtQ1zGnZZZ EIRNNcAxQH5NqcKlOXlYosK7ONeS0AGDeHE210o8smiZbFRktxSi9CwHg34A5ATqRCRngJSmWZCn 72+QEz+qcTKCHiPEtEj4dyEvRyFf1RRbaBKytbpBKBf/Q9wkFWfWKzRBqXaOukTRjJk5RvF0jQBF Ugo6RbdPf6SL6V4/C/2P+UhFntMRXuWjaJ6FxzAemUkdUQJLKSz6Wste6gPgc0aOgF+1yh+OflkU PViva/vkY3tw8B+OhVfrvei4d47uhNwQ5abENN2t+TLU/pbcfZ8Z4zVB/83zksP7kfoKpi8mCWN8 j2a/AQAA//8DAFBLAQItABQABgAIAAAAIQBHcju1+wAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABb Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAA AAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAKBAHdJpAgAA1gYAACEAAAAAAAAAAAAA AAAAEwIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAAC7 BAAAAACQAB4EQAgAAFBLAwQUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAFtDb250ZW50X1R5cGVz XS54bWx8kMtOwzAQRfdI/IPlLYqdskAIJemCxwoBi/IBlj1JLPySx6mav2eSFglQ1dVoHnfu0W22 B+/YHjLaGFq+ETVnEHQ0Ngwt/9y9VPecYVHBKBcDtHwG5Nvu+qrZzQmQkTpgy8dS0oOUqEfwCkVM EGjTx+xVoTYPMin9pQaQt3V9J3UMBUKpyvKDd80T9GpyhT0faHwkITlnj8e7xarlKiVntSoEKpet PKvL4PCCcB/MP7rqRCZIuT7H0Sa8OTm8UzTZGmAfKpc35YlDmowSHQ1f1Ryn8qfZiMvgZ/xj31sN JurJUyYiZUCqK4p34pfRD5Nco+++AQAA//8DAFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAA AF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M 3b6nUbwosvVOQVWUIMhpb6zrFdxvp80eBCd0BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYD TciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAsmOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1d cPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA//8DAFBLAwQUAAYACAAAACEAHJx+kg8FAABVEAAA IQAAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbKxY227jNhB9L9B/IPRaZB35HiPO Ikm7bYFs1lh7P4CWqFgNRQkk7XXy9T1DUpaUZgvD6xdHIoeHnJkzc6hcf9wXku2ENnmp5lH84TJi QiVlmqunefRt9eliGjFjuUq5LJWYRy/CRB9vfv3lupoZmT7wl3JrGTCUmfF5tLG2mvV6JtmIgpsP ZSUU5rJSF9ziVT/1Us2/A7uQvf7l5bhX8FxFYb0+Zn2ZZXkifi+TbSGU9SBaSG5xfrPJK1OjVceg VVoYwLjV3SPZlwreVnmy2kfMmekdBuLoBp4nS5kyxQsMLPLEbrVg33O7Yfe8onM4G1OttBBkrXZ/ 6mpZLbRb+rhbaJanBBUgol6YCGbuVcEMD703y59qJD7bZ7q4ueYzRITt5xES90K/WMRnYm9Z4geT ZjTZfHnHNtn88Y51r94AJzhsipxX3qP/utOv3VnlVgoWH7zyphxLH8rk2TBVwk9y37uXPO5qMPKZ 4KsN8+G3BBXs/KSLR21vXEzrgx4iEU+u+v0peAvPh1Ow7PJNVEbD6XiIQUaxGY3Hk8HUbVIjYRMP Xc3s/q5MXyika/xF5rhKNiWYuqYVfCaNXdoXiTzjeSdjnIhx+YRSkmABn6Ui+4oh8zqPwHdsua49 P9gjyV0chJjPEAj8YKnkVIlCXXxbohILey8FB3xwyd7cyzx5ZrZkIs0t+8yNFZq5wKFucTJCt24P BylUuuCa06HayJQLPsPO8L322YWB8vHjpA/qpNdlsJA8EZtSpjhEn0KEYqkTfBIFUIERygVcrglz GhHGcX8yGfmk1dXR4cEwjoksRxMBPdOixZT6NWLyb2Xm0VU8HCLD1r0MR5M+XnR7Zt2ZsfK+lJRI yrRCi7zd2jLLrU+FpxtNvUexgusHV/K5StG/apT19hFN2hGzRbwBmBfcChR1sDvZJ7Z6KHdcnPcY vH4TJuARSMAbNHguFsfiUS16r4FHIAFv2ODFg0lMdXzcAanSDoCEEgBHLcApWsRpgIQSAMcNIFoO DnjSCQklAE5agJOhy9wJLhNKAJw2gITm2t5RSe7EkFAC4FULcDyanJgUQnm/8TXwiCXI+dXxHMR4 w/dDm2Wg+oqvl2ixNYu19daCP6g7/ey0NiuVvXWdmaPOULMQfRWmsdMGbRb3ksVWJSgnknlUnlpW CT2YKlkklu04YGMEpqFXy+JOZG9tqeXXTARGY3GboSV7XGs8bssuzK6391Kv9q6c19vl6+HxE1xx Cpmh2c6jW51zSXyHSDUNwPL1g6FmUouQL4iQyJYMPG+LvCj/yX2cO2qDkHoKQrWI2e53O48Uugxd C3X+jP1VuXRPEXsWmi6R1G9YwiHywbBK3Epqclzmr+Iv97rmRsicLpUwV+VCl2VGz3RkqehXlZ9y Kf3B/YgpZZ7SIE27a6ZAkHwE7d5LBCbaViLLRGLrWGwfVIjjlmDCsyNDK6S/FepCWh9Twd9MCO4n EvNmIjGh6zTRPU1Wh7Wsrkiq2po6oB1+VlNJW5A+ZHfDZRbk1ak1JP80eR0NcIvy16jm9tnR1+kl bl1+kyPuWY63P618cUdZ6HLmuHWy8jlmBzqeQ/molwTKnEf5rtp4ZxC+Dt4ZdK+DdwbZ6+CdQfU6 eGcQvQ7e/2teUDhHfEfT0y//1DTc3d90Lv8/uuC7e77/WMUjfdu6FiP1Z1592bmz4GMenxXotBiq IJNUAzBtTAij/nfAzb8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAAAAAAAA AAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAcPA43L4AAAA4AQAA CwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAHJx+kg8FAABVEAAA IQAAAAAAAAAAAAAAAAATAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsFBgAA AAADAAMAyQAAAGEHAAAAAIAAHgQfBwAAUEsDBBQABgAIAAAAIQBHcju1+wAAALsBAAATAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbHyQy07DMBBF90j8g+Utip2yQAgl6YLHCgGL8gGWPUks/JLHqZq/Z5IW CVDV1Wged+7RbbYH79geMtoYWr4RNWcQdDQ2DC3/3L1U95xhUcEoFwO0fAbk2+76qtnNCZCROmDL x1LSg5SoR/AKRUwQaNPH7FWhNg8yKf2lBpC3dX0ndQwFQqnK8oN3zRP0anKFPR9ofCQhOWePx7vF quUqJWe1KgQql608q8vg8IJwH8w/uupEJki5PsfRJrw5ObxTNNkaYB8qlzfliUOajBIdDV/VHKfy p9mIy+Bn/GPfWw0m6slTJiJlQKorinfil9EPk1yj774BAAD//wMAUEsDBBQABgAIAAAAIQBw8Djc vgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYggeBL9gCXZtsE2Cdko 9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4EJ3QGR+9IwUwMbbNe1VcaMeUQDzaw yBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/s33XWU1H r58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAIAAAAIQDa 39dV7gMAAMsNAAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1szFfLkps4FN1P 1fyDin1iA8Z2U22napzHptPpGjsfIIPcMBESJdSOna+fI4HcwDgx7s5iNhiLo8N9nXvF7btDwcme qSqXYuH5b8ceYSKRaS4eF97Xzcc3c49UmoqUcinYwjuyynu3/POP2zKueHpHj/JJE3CIKqYLL9O6 jEejKslYQau3smQCz3ZSFVTjr3ocpYp+B3fBR8F4PB0VNBdes18N2S93uzxh72XyVDChaxLFONWw v8rysnJs5RC2UrEKNHZ31yR9LOGt3P6zOXjEwtQeC763hOfJmqdE0AILKyk0GMj3XGdkRUtjh8VU 5UYxZtBi/0mV6/JB2a33+wdF8tRQNRTeqHnQwOxfARhuRr3tj46JxoedKpa3NEZEyGHhIXFHc8Um GrODJkm9mDyvJtmXM9gk+3AGPXIvgAWnlyLnZe3Rf90JnDubXHNG/JNXNZRi651MvlVESPhp3K/d S+73jsz4bOjLjNTh14aqwdUPbTwcvrIxdYaeIjGJZqgtG45gFo6jXkzC8Xge+qFHTGR8fxo0iLbH NXMZ68NfMj2aiG7xi8RRkWQShbqt48wrvdZHjjTTmO+5D4MI5Y9QEkcR0Dhlu7+xVP1YeDAJNm2d 4yc8coz7Fg8iTGPEARds5dQIkYk3X9cQYqFXnFHQNz7p5YrnyTeiJWFprslnWmmmiI0bZAvLDLu2 77CUTKQPVFFjVJvZpILGeDPi63zGbZ3tn+ccQeyq4IHThGWSpzAieF0F5Cnq1xXJ8OSH0SwyCTVi OJf9yPd9IOrsR/Mo9FEKtfu1oKzbdR26SLjsW2m1U9WkvJfp0FRfTdkC4DZo6rVdFfM21gGADc9g J22sAwA7OYM11XaywQGAjS5hHQDY6SWsAwA7u4R1AGDnl7AOAOzNJWwNOKch7CRgOInllZoyPdVK qupoqtaNFQ8u7pW2cK+Q8ZolUqSEsz3jA+ittq6g32S5Gs5uBXEF+0f5pDD9hho/MYV5DX2+O8uO Mfdbu9nEdbONSXW7ldmAYOy7UfWiYWYmCFo4RkFG+c7DGQANzibSDjXTcuzN2la8ab5m6VfTzZ+E kV/r/Hnkd8bbZHrjj6evbnCkoOrOHjFykeK0Y26NadunexwKbTZbPc3v9CkzEw0WSjTtraFyM3oQ X6ef9npkw3fjT8xbySC+Tm/s9dGGzw9n/nQo4c0veq3jmwdz0+oHGdjh6/Xjhi8I5jDvJXy9nu34 ZhM7tq63r9fXGz5DNjghHX97vd/xTaPZy/Lx/5gPULY7TdgDhtW6+0TAivmisF8BXH2m5Ze9lQw+ oXCaW9mlEh9NZp4D+gwxVO4jbPkvAAAA//8DAFBLAQItABQABgAIAAAAIQBHcju1+wAAALsBAAAT AAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+ AAAAOAEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhANrf11Xu AwAAyw0AACEAAAAAAAAAAAAAAAAAEwIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnht bFBLBQYAAAAAAwADAMkAAABABgAAAABwAB4EcwQAAFBLAwQUAAYACAAAACEAR3I7tfsAAAC7AQAA EwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOwzAQRfdI/IPlLYqdskAIJemCxwoBi/IBlj1JLPyS x6mav2eSFglQ1dVoHnfu0W22B+/YHjLaGFq+ETVnEHQ0Ngwt/9y9VPecYVHBKBcDtHwG5Nvu+qrZ zQmQkTpgy8dS0oOUqEfwCkVMEGjTx+xVoTYPMin9pQaQt3V9J3UMBUKpyvKDd80T9GpyhT0faHwk ITlnj8e7xarlKiVntSoEKpetPKvL4PCCcB/MP7rqRCZIuT7H0Sa8OTm8UzTZGmAfKpc35YlDmowS HQ1f1Ryn8qfZiMvgZ/xj31sNJurJUyYiZUCqK4p34pfRD5Nco+++AQAA//8DAFBLAwQUAAYACAAA ACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2IIHgS/YAl 2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zrFdxvp80eBCd0BkfvSMFMDG2zXtVX GjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAsmOJsFMSzqUDc5pCb /7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA//8DAFBLAwQUAAYA CAAAACEA/+70YUIBAABwAgAAIQAAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbIxS y07DMBC8I/EPlu/ULQeEoiaVeF6AVmr5gMVxmgi/tHZD8vds3AQE6qEXaz2eGe94vVx1RrNWYWic zfliNudMWenKxu5z/r57urrlLESwJWhnVc57FfiquLxY+izo8gV6d4iMPGzIIOd1jD4TIshaGQgz 55Wls8qhgUhb3IsS4Yu8jRbX8/mNMNBYPurxHL2rqkaqBycPRtl4NEGlIVL/oW58mNz8OW4eVSCb pP7bUuw9pf3QYD85SzRsCVjwgpLLrS6ZBUPAXWIMYPA7VGqobPuMfus3mLhv7QZZUw7aUcPFeDDS 0tYSjQrxT76fnCDrKjTFEjJ6AtblnCbVDyuJIFNdZPIIyl9U1usTXFk/nmCL6QLq4OdSqqdYVA6x U+caX8GvW8oHGc05KrxPkKfJHjPIX8rgMf2U4hsAAP//AwBQSwECLQAUAAYACAAAACEAR3I7tfsA AAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAA IQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAA IQD/7vRhQgEAAHACAAAhAAAAAAAAAAAAAAAAABMCAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5 b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAAlAMAAAAAYAAeBA0FAABQSwMEFAAGAAgAAAAhAEdyO7X7 AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDLTsMwEEX3SPyD5S2KnbJACCXpgscKAYvy AZY9SSz8ksepmr9nkhYJUNXVaB537tFttgfv2B4y2hhavhE1ZxB0NDYMLf/cvVT3nGFRwSgXA7R8 BuTb7vqq2c0JkJE6YMvHUtKDlKhH8ApFTBBo08fsVaE2DzIp/aUGkLd1fSd1DAVCqcryg3fNE/Rq coU9H2h8JCE5Z4/Hu8Wq5SolZ7UqBCqXrTyry+DwgnAfzD+66kQmSLk+x9EmvDk5vFM02RpgHyqX N+WJQ5qMEh0NX9Ucp/Kn2YjL4Gf8Y99bDSbqyVMmImVAqiuKd+KX0Q+TXKPvvgEAAP//AwBQSwME FAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9 iCB4Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDIaW+s6xXcb6fNHgQndAZH70jB TAxts17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYyoH5gT3JbljsZvxnQLJjibBTE s6lA3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLvB9nUcvG3+QAAAP//AwBQ SwMEFAAGAAgAAAAhALhSHtjcAQAAwgMAACEAAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0 MS54bWyMU8tu2zAQvBfoPxC8J7JzKArCUoA4bS9JbNTOB2yptSWEIglyo0p/3yUlJW2aQy58LGeH O8Pl5nrojOgxxNbZUq4vV1Kg1a5u7bmUj8fvF1+liAS2BuMslnLEKK+rz582XkVT38Honkkwh40K StkQeVUUUTfYQbx0Hi2fnVzogHgbzkUd4Ddzd6a4Wq2+FB20Vs754SP57nRqNd46/dyhpYkkoAHi +mPT+riw+Y+w+YCRaXL2vyXR6FkttWRwZ80oRYaGnoNrWbF6fTC1sNBx4JhQIsPSSfTHgJhWtv8R /MHvQ0546PdBtHUimBNlMR/MsLy1DONF8Sb9vDCBGk6hqzag2AsxlJKfbEwjJ4HCgYSegvo1qpvd O1jdfHsHXSwXcAUvlyZVk6L/5VwtciYf1i+qJihw6p3TT1FYxzqT/EmefugXsqQ50ftG/GX8jJsO sx8LPrKn2Swablw9JuG/eM5BUCbSgUaD2RAuGxST88D2G0h9jfbi8cB93dHWIHDfz+ZRtTWtfhLk BNYtiXuIhEHkLuBfwJQbdof4cWZKtPUeAvx8w5z0geKbueilQl4mC/M09QcvUxPlFjDhHvyuz3Xy z+Fbtznk+a/Mbr1CEsfy96o/AAAA//8DAFBLAQItABQABgAIAAAAIQBHcju1+wAAALsBAAATAAAA AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAA OAEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhALhSHtjcAQAA wgMAACEAAAAAAAAAAAAAAAAAEwIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBL BQYAAAAAAwADAMkAAAAuBAAAAABQAB4EogcAAFBLAwQUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAA AFtDb250ZW50X1R5cGVzXS54bWx8kMtOwzAQRfdI/IPlLYqdskAIJemCxwoBi/IBlj1JLPySx6ma v2eSFglQ1dVoHnfu0W22B+/YHjLaGFq+ETVnEHQ0Ngwt/9y9VPecYVHBKBcDtHwG5Nvu+qrZzQmQ kTpgy8dS0oOUqEfwCkVMEGjTx+xVoTYPMin9pQaQt3V9J3UMBUKpyvKDd80T9GpyhT0faHwkITln j8e7xarlKiVntSoEKpetPKvL4PCCcB/MP7rqRCZIuT7H0Sa8OTm8UzTZGmAfKpc35YlDmowSHQ1f 1Ryn8qfZiMvgZ/xj31sNJurJUyYiZUCqK4p34pfRD5Nco+++AQAA//8DAFBLAwQUAAYACAAAACEA cPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2IIHgS/YAl2bbB NgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zrFdxvp80eBCd0BkfvSMFMDG2zXtVXGjHl EA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAsmOJsFMSzqUDc5pCb/7N9 11lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA//8DAFBLAwQUAAYACAAA ACEA8BdhJXEEAABAFwAAIQAAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbOxY25La OBB936r9B5XfEzCYy7gGUrXsZl8mM1ML+QBhi7E3tuSVBQP79dvdssBcnPKQVCVVywsI+ei4L+qj RvcftnnGNkKXqZITz3/f9ZiQkYpT+TLxPi8+vht7rDRcxjxTUky8nSi9D9Nff7kvwjKLH/hOrQ0D DlmGfOIlxhRhp1NGich5+V4VQsKzldI5N/BTv3RizV+BO886vW532Ml5Kr1qvW6zXq1WaSR+V9E6 F9JYEi0ybsD+MkmL0rEVbdgKLUqgodXHJpldAd6aV7XYLl7V0/JvjxFYb2Da96bgfzTPYiZ5DhMz lRdcp6WS9KQsFloIxMjNn7qYF8+aFjxunjVLYySoFnqd6kEFo58SYDDonCx/cUw83K50Pr3nIUSD bSceJG2Hn7CIh2JrWGQno8NslDxdwEbJHxfQHfcCsGD/Ush3YT06d6fn3FmkJhPM33tloRyWPqjo S8mkAj/Rfete9LhxZOgz0hcJq0KPVBXOPqR4OHwJMaVgme1vKt6h40v4pkkeZqWZm10GKYDxJvMp ATyMxeovG9raNHhbh4OTPART4AOSlXGsAyHffZ5DHeRmlgkOdVKF2kxnWRp9YUYxEaeGfeKlEZoZ ikKJBtwDu4FUVpRCxs9cczDiiBmjwUN4M7jo/IGhDXhz2Pv7sGPOnzMeiURlMVjQ+x4ZwHh6sF1h L7mENSQCo3WyJYPBCAqc9qU/6A98v48mHXZn0A26/hjEBffosH83GpLNEAZLRO7bLeEi4jLMuIwS BWqxtJT17FXJZjnXD1QXqYyhwHGIb1+uH0HFyBC7F1j578TrBWjp0rlZ2xs07MHuqQidV61Yu+es SIV2gJn9A+udH5AFbVj98TkrUlWswYHV74/8IYJb0RLyOATIVdEOarTj3phsuJYWuSra4YG21xuD Cd9gLXJVtKMa7Sjo0z681lrkqmjHB1rkbJ+yC7FFror2rkY7HIy+KWXIRVpSrwlSNHwJ7Lq9dNHb r1c4FBwSuPJI4a5RscCp2ExJA7V6JGSkGnDUuoPijUcJVnfCs1UlY1Zi8FilMOGgfp5gQpplrOeP gvFo8BUZ698NfCgORLTRMZKheqLOTqqDOlnKGgCGTkzqSoYltMc6AGCdRNSwpCR7rAMA1tV9HYu7 co91AMC6Ym7EOgBgXYU2Yh0AsK7sGrEOAFhXS41YBwCsLRDXCVB8SST3vv0cFUTNAHy4oqXz9w1t yVxESsYsExuRXSjQU3qqizfQL5JUt2evTv7WivNRrbVJWhsf2IpsT5+uLrJDb/Jdu7OB07XFaXdG Fl8varY/tt0ZCtw/a66h7aw0jqJNrXJrjRsGg24PzIVOrKlX80egfLdebeLdejXol2+92sTr/x97 taHTtEu9GrVG18vauZSRTl4tZU392kHKbv0axvy4/7n1aw13Ol/9x3PaUN36NbxCs/8GT2PzI/s1 ulWyd7MwxAtcun7N9CdePG2ohYR7a2imZjRVwE01/jMA6AGCHO7me/ofAAAA//8DAFBLAQItABQA BgAIAAAAIQBHcju1+wAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s UEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxz UEsBAi0AFAAGAAgAAAAhAPAXYSVxBAAAQBcAACEAAAAAAAAAAAAAAAAAEwIAAGRycy9zbGlkZUxh eW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAADDBgAAAABAAB4ESAYAAFBLAwQU AAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOwzAQRfdI/IPl LYqdskAIJemCxwoBi/IBlj1JLPySx6mav2eSFglQ1dVoHnfu0W22B+/YHjLaGFq+ETVnEHQ0Ngwt /9y9VPecYVHBKBcDtHwG5Nvu+qrZzQmQkTpgy8dS0oOUqEfwCkVMEGjTx+xVoTYPMin9pQaQt3V9 J3UMBUKpyvKDd80T9GpyhT0faHwkITlnj8e7xarlKiVntSoEKpetPKvL4PCCcB/MP7rqRCZIuT7H 0Sa8OTm8UzTZGmAfKpc35YlDmowSHQ1f1Ryn8qfZiMvgZ/xj31sNJurJUyYiZUCqK4p34pfRD5Nc o+++AQAA//8DAFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIw EETvgv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zr Fdxvp80eBCd0BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBP cluWOxm/GdAsmOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H 2dRy8bf5AAAA//8DAFBLAwQUAAYACAAAACEA5BV1nBcDAABxDQAAIQAAAGRycy9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQxLnhtbOxXy3LaMBTdd6b/oPE+MQ+HEA+QmdKmmzyYQj5AsUXsRpY8kuJA v75HskUIIQUmXbIBWT46uvfch+TB5aLgpGJK51IMg/ZpKyBMJDLNxeMwuJ9dnfQDog0VKeVSsGGw ZDq4HH39MihjzdNrupTPhoBD6JgOg8yYMg5DnWSsoPpUlkzg3Vyqgho8qscwVfQF3AUPO61WLyxo LoJmvdpnvZzP84R9l8lzwYSpSRTj1MB+neWl9mzlPmylYho0bvVbk8yyhLfmRd49/A6Iw6kKM+1g BNeTKU+JoAUmZi+SjKUwoHGvdDlTjFmQqH6qclpOlFtxW00UyVPL0KwMwuZFA3OPAjAMwo3lj56J xou5KkYDGkMJshgGCNjS/mIRjdnCkKSeTF5nk+xuCzbJfmxBh34DWLDaFLEua4/eu9Px7sxywxlp r7yqoRRLr2XypImQ8NO6X7uX3FaezPps6cuMNLJbqgZXv3R6eLyGpk4ss/gm06V1/AH/bpLGXJup WXLmBIHZNAY5fiA/pzarmTi5nyKrCzPmjCLrG/HMaMzz5IkYSViaG3JDtWGKGOeXtpQDqGMQnIaS iXRCFf21wWz9ozF2htHeQgxrCT8WsuuFbLKJTDhNWCZ5CiM6n5NV/0E1UD4PkIFIDx+DD7S1cm1k WXR2jnp1qdbutVp27PT1CRe1un3MB8SmXXTWObvodV0APZMToA6z12Rr1OzevOJtVzY0Ttncymvt 7/TrTaHtGgDDzhZstI71AGC7W7CtdawHABu9x7bf2OABwJ7twnoAsL1dWA8A9nwX1gOA7e/CegCw F7uwNcBq3ZSTDYyrJqwkYFiVzSery2aQKy79prrqCtrc0iXuAQU9ZYkUKeGsYnwPeldlB9DPslzt z+4K4gD2K/msTLa38VFdkXuH4yqfb2XHKfJf+1r0r77mNMF56g+DA4+Ljb7m4ueOCttp3GD9zNjW 13pR/9jYcCIcG1t8bGyri9CxsTUXNvdXX+gxtNd+d2fn6oaWd5XrtfjQwTVx7KZKfNrY6x+grxDL 4T+VRn8BAAD//wMAUEsBAi0AFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAA AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAAAAAAAA AAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA5BV1nBcDAABxDQAAIQAAAAAAAAAA AAAAAAATAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsFBgAAAAADAAMAyQAA AGkFAAAAADAAHgSoBgAAUEsDBBQABgAIAAAAIQBHcju1+wAAALsBAAATAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbHyQy07DMBBF90j8g+Utip2yQAgl6YLHCgGL8gGWPUks/JLHqZq/Z5IWCVDV1Wged+7R bbYH79geMtoYWr4RNWcQdDQ2DC3/3L1U95xhUcEoFwO0fAbk2+76qtnNCZCROmDLx1LSg5SoR/AK RUwQaNPH7FWhNg8yKf2lBpC3dX0ndQwFQqnK8oN3zRP0anKFPR9ofCQhOWePx7vFquUqJWe1KgQq l608q8vg8IJwH8w/uupEJki5PsfRJrw5ObxTNNkaYB8qlzfliUOajBIdDV/VHKfyp9mIy+Bn/GPf Ww0m6slTJiJlQKorinfil9EPk1yj774BAAD//wMAUEsDBBQABgAIAAAAIQBw8DjcvgAAADgBAAAL AAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYggeBL9gCXZtsE2Cdko9u/N0YLgcRjm zUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4EJ3QGR+9IwUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK 1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/s33XWU1Hr58TufSjQvJo DV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAIAAAAIQDmJZVYdwMAAGIM AAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1szJdbT9swFMffJ+07WHmHJukl JaJFGhvbAzet8AGM49IIx4ls07X79PsfO2kLA6nioeIlTezjc37nZrunZ6tKsaU0tqz1JEqO44hJ Leqi1I+T6P7u4mgcMeu4LriqtZxEa2mjs+nXL6dNblVxydf1s2PQoW3OJ9HCuSbv9axYyIrb47qR GnPz2lTc4dM89grD/0B3pXppHI96FS911K43+6yv5/NSyO+1eK6kdkGJkYo78NtF2dhOW7OPtsZI CzV+9Uskt27grZXil+RFxLygWWIoiabwXcxUwTSvMDCTgowzEpTGz9rmzkhJcnr50zSz5tb4RdfL W8PKgpS0i6NeO9GK+U8NMbz0Xi1/7DTxfDU31fSU54gGW00iJG1NTyziuVw5JsKg2I6Kxc0bsmLx 4w3pXmcABBujyHcTPPrfnbRz5650SrJk41UQ5Vh6WYsny3QNP8n94J64XnbKyGdS3yxYCL0jVa1c mPTx6OStj2kHuolElqb9pO/DMRjEo5P4VVCyLEsHGGQUmqQ/SuNs6I10mmAkqG5yt/pWF2sK6QN+ kTmuxaJGlTpawXNl3cytFfKM96VKQMS4ekQbKVQBzws5/40h+3cSwSRsPvjEC44IcKVas+1KpPul RgSb5wgJHlCiOPWj1Ef3M/Rj5c6V5DDUeuem56oUT8zVTBalY1fcOmmYDyG6F4yk3XkbXqXUxS03 nPB2NVNWeA7LiELnvQ8IZeb99CPeoRXuqPZuFRdyUSs0A0vJSXRLl+cPVQJFP0LboKa7wvlQQaQn 8ShDcfjkdV3ysiCGcZyMszYzocn2KYiHoPOtgqi4ufQNWuoCOw29Uk4fnq+xnXqSnTLBlhimba3K 4qJUimT9birPlWFLrlB9K9qCkM5SuzCSAdtXApK3Efap3NGDuWDJT2yqzpduSqUbSAfDDBQI9x64 yfiAuMRIboO8v8U9SdDm++KODohLjC3uYIub9LOEKPYLL3nmC+AA1UCQLe9wh3ecjinJn4+XIFve 0ZY3TccI72fkJciWN9vhzQb9/dvtkPVAkC3veMtLsPv32yF5CbLlPdnhHQ2zz9lvBBl24p1bhD/z iR6b3OZw9259/A5AB52/AtgXd4D3znl/3IXbK17pmusPcGWueHOz9Cy42eN2gfMIQw3u8nRrgOhW hHR0/w2m/wAAAP//AwBQSwECLQAUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAAAAAAAAAAAAAAAA AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAA AAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDmJZVYdwMAAGIMAAAhAAAAAAAA AAAAAAAAABMCAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJ AAAAyQUAAAAAIAAeBIAFAABQSwMEFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAABbQ29udGVudF9U eXBlc10ueG1sfJDLTsMwEEX3SPyD5S2KnbJACCXpgscKAYvyAZY9SSz8ksepmr9nkhYJUNXVaB53 7tFttgfv2B4y2hhavhE1ZxB0NDYMLf/cvVT3nGFRwSgXA7R8BuTb7vqq2c0JkJE6YMvHUtKDlKhH 8ApFTBBo08fsVaE2DzIp/aUGkLd1fSd1DAVCqcryg3fNE/RqcoU9H2h8JCE5Z4/Hu8Wq5SolZ7Uq BCqXrTyry+DwgnAfzD+66kQmSLk+x9EmvDk5vFM02RpgHyqXN+WJQ5qMEh0NX9Ucp/Kn2YjL4Gf8 Y99bDSbqyVMmImVAqiuKd+KX0Q+TXKPvvgEAAP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAAOAEA AAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783RguBx GObNTN2+p1G8KLL1TkFVlCDIaW+s6xXcb6fNHgQndAZH70jBTAxts17VVxox5RAPNrDIFMcKhpTC QUrWA03IhQ/kstP5OGHKMvYyoH5gT3JbljsZvxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO59KNC 8mgNXXD2z5SxGHtKCkzkb2MhqiLvB9nUcvG3+QAAAP//AwBQSwMEFAAGAAgAAAAhAIs7VsRPAgAA nwYAACEAAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWyslctu2zAQRfcF+g8E94ls pygKwXaAuk03eRi18wETcmyxoUiCpFXr7zukJAdJXcBGutGDmrmcezikptf7WrMGfVDWzPj4csQZ GmGlMtsZf1zfXHzhLEQwErQ1OOMtBn49//hh6sqg5S20dhcZaZhQwoxXMbqyKIKosIZwaR0a+rax voZIr35bSA+/SbvWxWQ0+lzUoAzv8/0p+XazUQK/WbGr0cROxKOGSPWHSrkwqLlT1JzHQDI5+3VJ sXXk1j794iwH+YZex3xOvsVKS2agpoG1ihoZ0WELayIp5YDg1h4xhZrmh3crt/Q5775ZeqZk0unz edF/6MPyq6EweijepG8HJSj3G1/Pp1ASDLafcVqzNl0pCUrcRya6QfEyKqqHI7Gi+n4kuhgmoAoO k9Jyu87R33Ymg50Ox/jgqgsFSr214jkwY8lnst/ZE/fNIJY8J3lXsY58TGT7uO5j5jHEB2KaYcX9 VyvbZPyJ7nkQSh3iKrYaMxAqG0oSpwvh15AaG83F44oau44LjUCN38OL84VW4plFy1CqyO4gRPQs F0PbgCSnRCfS4vSSaOQSPPx8o5z8QUkzU9FDhfTYIfw3yKsBZN9NbKlBYGW1pCIm78OqJDXFQP4/ EKUFYLrRB3TvJJzaNgMOrwh3FDNKugxTZhtnLOoKhaU9qrFBfYJ8Jn2G/LpS/nT1q7SOZ6jf2J2P 1cnFfzpXXm2OqtNJcnZv5xbvzj56TOdkPt60vwP30OQOod8C7ahFHnL0I0g7hUJfQpLG8GOZ/wEA AP//AwBQSwECLQAUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAACwB AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCLO1bETwIAAJ8GAAAhAAAAAAAAAAAAAAAAABMC AABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAAoQQAAAAA EAAeBFMGAABQSwMEFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1s fJDLTsMwEEX3SPyD5S2KnbJACCXpgscKAYvyAZY9SSz8ksepmr9nkhYJUNXVaB537tFttgfv2B4y 2hhavhE1ZxB0NDYMLf/cvVT3nGFRwSgXA7R8BuTb7vqq2c0JkJE6YMvHUtKDlKhH8ApFTBBo08fs VaE2DzIp/aUGkLd1fSd1DAVCqcryg3fNE/RqcoU9H2h8JCE5Z4/Hu8Wq5SolZ7UqBCqXrTyry+Dw gnAfzD+66kQmSLk+x9EmvDk5vFM02RpgHyqXN+WJQ5qMEh0NX9Ucp/Kn2YjL4Gf8Y99bDSbqyVMm ImVAqiuKd+KX0Q+TXKPvvgEAAP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVs cy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8 KLL1TkFVlCDIaW+s6xXcb6fNHgQndAZH70jBTAxts17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/k stP5OGHKMvYyoH5gT3JbljsZvxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5Sx GHtKCkzkb2MhqiLvB9nUcvG3+QAAAP//AwBQSwMEFAAGAAgAAAAhAGTm8BUiAwAADgwAACEAAABk cnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWzMVstu2zAQvBfoPxC6J3pYshTBdoCmTS95 IU4+gJFoWwhFESSt2n/fXZKynTQFcshBF5uidkezM1ySs8tdy0nPlG46MQ/i8yggTFRd3Yj1PHh+ uj4rAqINFTXlnWDzYM90cLn4/m0mS83rG7rvtoYAhtAlnQcbY2QZhrrasJbq804yAe9WnWqpgUe1 DmtF/wB2y8MkiqZhSxsR+Hz1mfxutWoq9rOrti0TxoEoxqkB/nrTSD2gyc+gScU0wNjst5TMXkK1 pjGcBcSGqR4m4mABlVdLXhNBW5h4wgiy5E3N7CstnxRjGCT630ou5YOyGXf9gyJNjQg+Mwj9Cx9m HwWEwSB8l74ekGi5W6l2MaMlCEF28wD82uMvJNGS7Qyp3GR1nK029x/EVptfH0SHwweAweGjYLV0 Ff1bTjKU44SID1W5UAqpN131qonooE4s35VX3fUDGNaM8HJDnOqVURbNh7r3VpIhRVtZB64HMaZF VkROkSSeRGmSvdUlz/MkxQBUJ07zKHIRp1U7aFma3Y+u3qOqL/BvXaEl12Zp9pxZtUETWgJz+AFv OcWOYeLseQkd05orzih0lHfGLK54U70S0xFWN4bcUm2YIsauHo2QMyBhwHkPyUT9QBV9fIeM4tES vgxyDAxh6Pz5v0uTwaXl9sV9M/kKo/T2xRkFKxuW3eDt5w2LJ3k89Y5NimIKe8Jbx6Zgl7XUOpZn CUY7EVwj2OLd+hn0+NAxtIn3PIaFQ1qqbmznNKKG7rdDytfgFqw86GIA2N7BbmddrtkKTMBJ3UGX Xzec2wfc4tgVV6SnHDaKHe4M4GAjjJvJs+hA1e6HGGzdO8EBLwd8GHp+iAPD5Eg1zXJUhoyPL5L0 fCdHvhdxattsfHyRpOebHvkeluH4CCNLTzg7IVwkhW2L8RFGlp7w9Eg4SQro3FEuYWTpCecnhPN0 MtKeQ5aecHEkjGxH2nTI0hO+OCE8zXK7949vDSNLu1UP5z2y/4LjHs7Lrzzx7dnnrpswxEupvVFy dUvlfW8lh1s43DPg5IEpCfduPDoh9BiCGMM9fvEXAAD//wMAUEsBAi0AFAAGAAgAAAAhAEdyO7X7 AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA ACEAcPA43L4AAAA4AQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA ACEAZObwFSIDAAAODAAAIQAAAAAAAAAAAAAAAAATAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDEueG1sUEsFBgAAAAADAAMAyQAAAHQFAAAAAAAAHAQEAAAAAQAAACAAug8YAAAATwBmAGYA aQBjAGUAIABUAGgAZQBtAGUADwDuA1sKAAACAO8DGAAAABAAAAAAAAAAAAAAAAAAAIAAAAAABwAA AA8ADAT7CQAADwAC8PMJAAAgAAjwCAAAAAMAAAACCAAADwAD8NsJAAAPAATwKAAAAAEACfAQAAAA AwAAAGQAcgBzAC8AZABvAAIACvAIAAAAAAgAAAUAAAAPAATw7AAAABIACvAIAAAAAQgAACACAAAD AQvwcAAAAAQAAAAAAH8AAQDvAYAAmDpghIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcA AQAAAIgAAAAAAL8AAAAGAP8BEAARAAEDAgQAAD8DAAAIAIDDEAAAAL8DAAACAFQAaQB0AGwAZQAg ADEAAAAAABDwCAAAAD4FsAHQFNwIDwAR8BwAAAAAAMMLCAAAAP////8PAPm/AAAfBAQAAAACAAAA DwAN8CgAAAAAAJ8PBAAAAAYAAAAAAKgPFAAAAFNDSU0gY29uZmVyZW5jZSBjYWxsDwAE8K8IAAAS AArwCAAAAAIIAAAgAgAAAwEL8HYAAAAEAAAAAAB/AAEA7wGAAAjLxYSBADBlAQCCAJiyAACDADBl AQCEAJiyAACFAAAAAACHAAAAAACIAAAAAAC/AAAABgD/ARAAEQABAwMEAAA/AwAACACAwxYAAAC/ AwAAAgBTAHUAYgB0AGkAdABsAGUAIAAyAAAAEwAi8YcHAACpw4EHAABQSwMEFAAGAAgAAAAhADI8 vT77AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJFBTsMwEEX3SNzB8hYlDiwQQk26ILAE BOUAI3uSWCRjy2NCe3smbdkgVMTSnnn/P9mr9XYa1YyJfaBaX5aVVkg2OE99rd82D8WNVpyBHIyB sNY7ZL1uzs9Wm11EVkIT13rIOd4aw3bACbgMEUkmXUgTZDmm3kSw79Cjuaqqa2MDZaRc5CVDN6sW O/gYs7rfyvXBRHCt7g57S1WtIcbRW8giapap+ZVLOPIJcCb3w644mpVC7sN58JEvjg1P8jTJO1TP kPIjTOJhXGLDA0SUnfK051I3cRG6zlss28SvC/dXuAuflHD+b3Yr2AvO3+lm/0PNFwAAAP//AwBQ SwMEFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQsWoDMQyG90DfwWjv+ZKh lBBftkLWkEJXYevuTM6Wscw1efu4lEIvZMugQb/Q9wnt9pcwqZmyeI4G1k0LiqJl5+Ng4PP08foO SgpGhxNHMnAlgX33stodacJSl2T0SVSlRDEwlpK2WosdKaA0nCjWSc85YKltHnRCe8aB9KZt33T+ z4BuwVQHZyAf3BrU6Zqq+Y4dvM0s3JfGctDc994+omoZMdFXmCoG80DFgMvym9bTmlqgH5s3T5od f8cjzUvxT5hp/vPqxRu7GwAAAP//AwBQSwMEFAAGAAgAAAAhACA9GGAcAwAAJwgAABAAAABkcnMv c2hhcGV4bWwueG1s3FVNb9swDL0P2H8QdB26fDRNWqNO0RboNiAogqY9D7Qst15kyZDkLOmv35Pk 9Os0tJdhOSS0+Sg+PpLK6dm2UWwjrauNzvno65AzqYUpa32f87vbq4NjzpwnXZIyWuZ8Jx0/m3/+ dNpmrmUI1i5rc/7gfZsNBk48yIbcV9NKDV9lbEMej/Z+0FrppPbkkahRg/FwOB00VGs+x1F6s2qX NljierO0rC5zfsiZpgYpV13ha68kG/NBD0loAoWFEWvX86C/4VFa+o3iXlFg2nyzqGIUEgwiiT0f DTohafvA/K4FG9cVt4ENB8ltzifjk8nJdDY+OepjUwAOea7Jxdoo21a2+SjV+SllpqoYUo8OZ6Pp EA3bQazj4ykkDRwok1vPBADTyXB4HAACiNHsaBzQocJEJZaauLWZ316YcheiC/yiBam175cUM+XR D2MfOVM/tMv5yWgyARkfHyZHszEe7EtP8crj1aVROR9iQCjTmKTzzpuq9qmAxDK4lPMrv8N4fJBx lG4/0u+uOzBCu1lDdhHIB+MmGmoTq2G1LrEH8RWpeyyd8JazUla3VKweMVFBmSCNT3hJC31h12E6 WWW0P49BBDEgLNZJ926EPJC+x2wvOy2QYBSVU3rVisDKtWIpPNsQjh0Nw6efhZeIC1m9xYLMExRn PCPOK7/HepfO3R8JXO8tuktlb7dR3KJbPT6ZVyglrlRFAmt1bmtSaXyL7hpXTYzwVCxc6DhlEOhm aWFievt9wmJSZiH2umvqxvyqk84QIedSH9ytcHVB0MMoZxGdCdLlXCNFuNlsvUZ2bVbR4mwtbbgH Y4gg3Ak9sBUxPswhqfpRfo+PBTmp6nAvQn1tltaYKtplbT2WDm9d4y+VJByaJlnpwFqbq1qpVE16 44yqy/AyahruUQnlkqx+m3qJZvcNnB29aMoeHLV5dY6sKin8XsJuoXv5u5Cot+MMvejEl0YfKJ9a IemNQ1JyCPfGIVxwoDfoR6jAzxljP/sPTMaCEwMTIAEgdbkkS+jpv9y+wPR/79hzJ9Jy4fv5/wCm a+d/AAAA//8DAFBLAwQUAAYACAAAACEA8ZQWb9cAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESP TUvDQBRF94L/YXiCm2InWqoh9rWIUCKC9Hv/mnlNQjMzcWaapP/ewYUuL/dyLme2GHQjOna+tgbh cZyAYFNYVZsSYb9bPqQgfCCjqLGGEa7sYTG/vZlRpmxvNtxtQykixPiMEKoQ2kxKX1SsyY9tyyZ2 J+s0hRhdKZWjPsJ1I5+S5Flqqk18qKjl94qL8/aiEUb7fHd5Oa/zL/c9OXyu2n7ajdaI93fD2yuI wEP4H0/TZdqlf+Uv6kMhTECc8uvR1WpDPrBDiG7RNFqCnP8AAAD//wMAUEsBAi0AFAAGAAgAAAAh ADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU AAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAU AAYACAAAACEAID0YYBwDAAAnCAAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBL AQItABQABgAIAAAAIQDxlBZv1wAAAPkAAAAPAAAAAAAAAAAAAAAAAHIFAABkcnMvZG93bnJldi54 bWxQSwUGAAAAAAQABAD1AAAAdgYAAAAAAAAQ8AgAAACQCWADIBPgDQ8AEfAcAAAAAADDCwgAAAD/ ////EAD5vwAAHwQEAAAAAwAAAA8ADfBWAAAAAACfDwQAAAAFAAAAAACoDxAAAAA0IFNlcHRlbWJl ciAyMDEzAAChDxYAAAARAAAAAAAAAAAAEQAAAAAABACJiYn+AACmDwwAAADwAAAA1AHQAvADEAUQ APAHIAAAAP///wAAAAAA7uzhAB9JfQBPgb0AwFBNAAAA/wCAAIAAAAAiBAgAAAABAAAAAQAAAA8A 7gNnAwAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAAAAcAAAAPAAwEBwMAAA8AAvD/AgAAMAAI 8AgAAAADAAAAAgwAAA8AA/DnAgAADwAE8CgAAAABAAnwEAAAAF8AXwBfAF8AXwBfAF8AIAACAArw CAAAAAAMAAAFAAAADwAE8OAAAAASAArwCAAAAAEMAAAgAgAAAwEL8HAAAAAEAAAAAAB/AAEA7wGA AKhlS4WBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAAABgD/ARAA EQABAwIEAAA/AwAACACAwxAAAAC/AwAAAgBUAGkAdABsAGUAIAAxAAAAAAAQ8AgAAACtACABYBV9 Aw8AEfAcAAAAAADDCwgAAAD/////DQD5vwAAHwQEAAAAAgAAAA8ADfAcAAAAAACfDwQAAAAAAAAA AACoDwgAAABJc3N1ZSAjMg8ABPDHAQAAEgAK8AgAAAACDAAAIAIAABMBC/CSAAAABAAAAAAAfwAB AO8BgADoo2SEgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYA vwEBAAEA/wEQABEAAQMDBAAAPwMAAAgAgMMsAAAAvwMAAAIAQwBvAG4AdABlAG4AdAAgAFAAbABh AGMAZQBoAG8AbABkAGUAcgAgADIAAAAAABDwCAAAAPADIAFgFRMPDwAR8BwAAAAAAMMLCAAAAP// //8TAPm/AAAfBAQAAAADAAAADwAN8OEAAAAAAJ8PBAAAAAEAAAAAAKgPkwAAAEFkZCBwYWdpbmF0 aW9uIGNhcGFiaWxpdHkgdG8gcGx1cmFsIFJlc291cmNlIGF0dHJpYnV0ZXMNDVVzZXIgR3JvdXAg cmV0cmlldmFsIGNvdWxkIGJlIHJlc291cmNlIGludGVuc2l2ZSwgaGVuY2Ugc3VwcG9ydCBhdHRy aWJ1dGUgbGV2ZWwgcGFnaW5hdGlvbgAAoQ8kAAAAlAAAAAAAAQAAAAIAOAAAAAQAAgAEABgAXAAA AAAEAgAABBgAAACmDwYAAAAIAAAAAAAQAPAHIAAAAP///wAAAAAA7uzhAB9JfQBPgb0AwFBNAAAA /wCAAIAAAAAiBAgAAAABAAAAAgAAAA8A7gOHAwAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAA AAcAAAAPAAwEJwMAAA8AAvAfAwAAQAAI8AgAAAADAAAAAhAAAA8AA/AHAwAADwAE8CgAAAABAAnw EAAAAF8AXwAgAF8AXwBfAF8AXwACAArwCAAAAAAQAAAFAAAADwAE8OAAAAASAArwCAAAAAEQAAAg AgAAAwEL8HAAAAAEAAAAAAB/AAEA7wGAAGhrQYWBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAA AACHAAEAAACIAAAAAAC/AAAABgD/ARAAEQABAwIEAAA/AwAACACAwxAAAAC/AwAAAgBUAGkAdABs AGUAIAAxAAAAAAAQ8AgAAACtACABYBV9Aw8AEfAcAAAAAADDCwgAAAD/////DQD5vwAAHwQEAAAA AgAAAA8ADfAcAAAAAACfDwQAAAAAAAAAAACoDwgAAABJc3N1ZSAjOQ8ABPDnAQAAEgAK8AgAAAAC EAAAIAIAABMBC/CSAAAABAAAAAAAfwABAO8BgACYDUKFgQAwZQEAggCYsgAAgwAwZQEAhACYsgAA hQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYAvwEBAAEA/wEQABEAAQMDBAAAPwMAAAgAgMMsAAAAvwMA AAIAQwBvAG4AdABlAG4AdAAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAAAABDwCAAAAPAD IAFgFRMPDwAR8BwAAAAAAMMLCAAAAP////8TAPm/AAAfBAQAAAADAAAADwAN8AEBAAAAAJ8PBAAA AAEAAAAAAKgPkQAAAEFkZCBhYmlsaXR5IHRvIG1hcmsgYXR0cmlidXRlcyBhcyB1bmlxdWUgaW4g dGhlIHNjaGVtYXMNDUFkZCBhYmlsaXR5IHRvIG1hcmsgYXR0cmlidXRlcyBhcyB1bmlxdWUgaW4g U2VydmljZVByb3ZpZGVyQ29uZmlnIChvciB1bmlxdWUgaW4gU2NoZW1hPykAAKEPJAAAAJIAAAAA AAEAAAACADgAAAAEAAIABAAYAFoAAAAABAIAAAQYAAAAqg8aAAAAZQAAAAAAAAAVAAAAAQAAAAMA GAAAAAAAAAAAAKYPBgAAAAgAAAAAABAA8AcgAAAA////AAAAAADu7OEAH0l9AE+BvQDAUE0AAAD/ AIAAgAAAACIECAAAAAEAAAACAAAADwDuA6cDAAACAO8DGAAAABAAAAAAAAAAAAAAAAAAAIAAAAAA BwAAAA8ADARHAwAADwAC8D8DAABQAAjwCAAAAAMAAAACFAAADwAD8CcDAAAPAATwKAAAAAEACfAQ AAAAbwByACAAdQBuAGkAcQB1AAIACvAIAAAAABQAAAUAAAAPAATw4QAAABIACvAIAAAAARQAACAC AAADAQvwcAAAAAQAAAAAAH8AAQDvAYAA+N1hhIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAA AIcAAQAAAIgAAAAAAL8AAAAGAP8BEAARAAEDAgQAAD8DAAAIAIDDEAAAAL8DAAACAFQAaQB0AGwA ZQAgADEAAAAAABDwCAAAAK0AIAFgFX0DDwAR8BwAAAAAAMMLCAAAAP////8NAPm/AAAfBAQAAAAC AAAADwAN8B0AAAAAAJ8PBAAAAAAAAAAAAKgPCQAAAElzc3VlICMxMA8ABPAGAgAAEgAK8AgAAAAC FAAAIAIAABMBC/CSAAAABAAAAAAAfwABAO8BgAA4DUKFgQAwZQEAggCYsgAAgwAwZQEAhACYsgAA hQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYAvwEBAAEA/wEQABEAAQMDBAAAPwMAAAgAgMMsAAAAvwMA AAIAQwBvAG4AdABlAG4AdAAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAAAABDwCAAAAPAD IAFgFRMPDwAR8BwAAAAAAMMLCAAAAP////8TAPm/AAAfBAQAAAADAAAADwAN8CABAAAAAJ8PBAAA AAEAAAAAAKgPsAAAAEFkZCBhYmlsaXR5IHRvIG1hcmsgYXR0cmlidXRlcyBhcyBzZW5zaXRpdmUg aW4gdGhlIHNjaGVtYXMNDUFkZCBhYmlsaXR5IHRvIG1hcmsgYXR0cmlidXRlcyBhcyBzZW5zaXRp dmUgaW4gU2VydmljZVByb3ZpZGVyQ29uZmlnIChvciBzZW5zaXRpdmUgaW4gU2NoZW1hPykNVXNl IHRoaXMgZm9yIHBhc3N3b3JkAAChDyQAAACxAAAAAAABAAAAAgA7AAAABAACAAQAGAB2AAAAAAQC AAAEGAAAAKoPGgAAAGsAAAAAAAAAFQAAAAEAAAADADEAAAAAAAAAAACmDwYAAAAIAAAAAAAQAPAH IAAAAP///wAAAAAA7uzhAB9JfQBPgb0AwFBNAAAA/wCAAIAAAAAiBAgAAAABAAAAAgAAAA8A7gMv AwAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAAAAcAAAAPAAwEzwIAAA8AAvDHAgAAYAAI8AgA AAADAAAAAhgAAA8AA/CvAgAADwAE8CgAAAABAAnwEAAAACAAIABfAF8AIABfAF8AXwACAArwCAAA AAAYAAAFAAAADwAE8OEAAAASAArwCAAAAAEYAAAgAgAAAwEL8HAAAAAEAAAAAAB/AAEA7wGAANgI YoSBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAAABgD/ARAAEQAB AwIEAAA/AwAACACAwxAAAAC/AwAAAgBUAGkAdABsAGUAIAAxAAAAAAAQ8AgAAACtACABYBV9Aw8A EfAcAAAAAADDCwgAAAD/////DQD5vwAAHwQEAAAAAgAAAA8ADfAdAAAAAACfDwQAAAAAAAAAAACo DwkAAABJc3N1ZSAjMTMPAATwjgEAABIACvAIAAAAAhgAACACAAATAQvwkgAAAAQAAAAAAH8AAQDv AYAAaCxihIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAL8B AQABAP8BEAARAAEDAwQAAD8DAAAIAIDDLAAAAL8DAAACAEMAbwBuAHQAZQBuAHQAIABQAGwAYQBj AGUAaABvAGwAZABlAHIAIAAyAAAAAAAQ8AgAAADwAyABYBUTDw8AEfAcAAAAAADDCwgAAAD///// EwD5vwAAHwQEAAAAAwAAAA8ADfCoAAAAAACfDwQAAAABAAAAAACoDzgAAABBZGQgYSAicmVxdWly ZWQiIGZsYWcgaW4gY29uZmlndXJhdGlvbiB0byBzdXBwb3J0IGV0YWdzDQAAoQ8kAAAAOQAAAAAA AQAAAAIAOAAAAAQAAgAEABgAAQAAAAAEAgAABBgAAACqDxoAAAAyAAAAAAAAAAUAAAABAAAAAwAC AAAAAAAAAAAApg8GAAAACAAAAAAAEADwByAAAAD///8AAAAAAO7s4QAfSX0AT4G9AMBQTQAAAP8A gACAAAAAIgQIAAAAAQAAAAIAAAAPAO4DWQQAAAIA7wMYAAAAEAAAAAAAAAAAAAAAAAAAgAAAAAAH AAAADwAMBPkDAAAPAALw8QMAAHAACPAIAAAAAwAAAAIcAAAPAAPw2QMAAA8ABPAoAAAAAQAJ8BAA AAABAAAAAQAAAP7///8AAAAAAgAK8AgAAAAAHAAABQAAAA8ABPDhAAAAEgAK8AgAAAABHAAAIAIA AAMBC/BwAAAABAAAAAAAfwABAO8BgABoHc6EgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAA hwABAAAAiAAAAAAAvwAAAAYA/wEQABEAAQMCBAAAPwMAAAgAgMMQAAAAvwMAAAIAVABpAHQAbABl ACAAMQAAAAAAEPAIAAAArQAgAWAVfQMPABHwHAAAAAAAwwsIAAAA/////w0A+b8AAB8EBAAAAAIA AAAPAA3wHQAAAAAAnw8EAAAAAAAAAAAAqA8JAAAASXNzdWUgIzI0DwAE8LgCAAASAArwCAAAAAIc AAAgAgAAEwEL8JIAAAAEAAAAAAB/AAEA7wGAAPgsYoSBADBlAQCCAJiyAACDADBlAQCEAJiyAACF AAAAAACHAAAAAACIAAAAAAC/AAAABgC/AQEAAQD/ARAAEQABAwMEAAA/AwAACACAwywAAAC/AwAA AgBDAG8AbgB0AGUAbgB0ACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAAAAAAEPAIAAAA8AMg AWAVEw8PABHwHAAAAAAAwwsIAAAA/////xMA+b8AAB8EBAAAAAMAAAAPAA3w0gEAAAAAnw8EAAAA AQAAAAAAqA+EAQAAQWRkIHRoZSBuZWdhdGlvbiBvcGVyYXRvciB0byB0aGUgRmlsdGVyaW5nIHNl Y3Rpb24NDUknbSByZWFkaW5nIHRoZSAzLjIuMi4xLiBGaWx0ZXJpbmcgc2VjdGlvbiBpbiB0aGUg QVBJIHNwZWNpZmljYXRpb24gYW5kIEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBiZWNhdXNlIEkgbWlz cyBzb21lIGZpbHRlciBvcGVyYXRvcnMuIEkgbm90aWNlZCB0aGUgcHJpb3JpdHkgaXMgbm90IG9u IHRoZSBmaWx0ZXJpbmcgbm93IGFuZCB0aGUgc3BlY2lmaWNhdGlvbnMgc3RhdGVzICJQcm92aWRl cnMgTUFZIHN1cHBvcnQgYWRkaXRpb25hbCBmaWx0ZXIgb3BlcmF0aW9ucyBpZiB0aGV5IGNob29z ZS4iIHNvIEl0J3MgYWxsIGZpbmUgYnV0IHdoYXQgSSBtaXNzIGlzIHRoZSB3YXkgdG8gbmVnYXRl LgAAoQ8kAAAAhQEAAAAAAQAAAAIANAAAAAQAAgAEABgAUQEAAAAEAgAABBgAAACmDwYAAAAIAAAA AAAQAPAHIAAAAP///wAAAAAA7uzhAB9JfQBPgb0AwFBNAAAA/wCAAIAAAAAiBAgAAAABAAAAAgAA AA8A7gP5AwAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAAAAcAAAAPAAwEmQMAAA8AAvCRAwAA gAAI8AgAAAADAAAAAiAAAA8AA/B5AwAADwAE8CgAAAABAAnwEAAAAAEAAAABAAAA/v///wAAAAAC AArwCAAAAAAgAAAFAAAADwAE8OEAAAASAArwCAAAAAEgAAAgAgAAAwEL8HAAAAAEAAAAAAB/AAEA 7wGAAEgGa4SBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAAABgD/ ARAAEQABAwIEAAA/AwAACACAwxAAAAC/AwAAAgBUAGkAdABsAGUAIAAxAAAAAAAQ8AgAAACtACAB YBV9Aw8AEfAcAAAAAADDCwgAAAD/////DQD5vwAAHwQEAAAAAgAAAA8ADfAdAAAAAACfDwQAAAAA AAAAAACoDwkAAABJc3N1ZSAjMzQPAATwWAIAABIACvAIAAAAAiAAACACAAATAQvwkgAAAAQAAAAA AH8AAQDvAYAA2AVChYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8A AAAGAL8BAQABAP8BEAARAAEDAwQAAD8DAAAIAIDDLAAAAL8DAAACAEMAbwBuAHQAZQBuAHQAIABQ AGwAYQBjAGUAaABvAGwAZABlAHIAIAAyAAAAAAAQ8AgAAADwAyABYBUTDw8AEfAcAAAAAADDCwgA AAD/////EwD5vwAAHwQEAAAAAwAAAA8ADfByAQAAAACfDwQAAAABAAAAAACoDyQBAABSZXNvdXJj ZSBTY2hlbWEgUmVwcmVzZW50YXRpb24gc2hvdWxkIGJlIG5vbi1ub3JtYXRpdmUNDVRoZSBKU09O IHNjaGVtYSByZXByZXNlbnRhdGlvbiBpbiAiMTEuNi4gUmVzb3VyY2UgU2NoZW1hIFJlcHJlc2Vu dGF0aW9uIiBkb2Vzbid0IGFwcGVhciB0byBiZSAibm9ybWF0aXZlIiBhcyBpbmRpY2F0ZWQsIHNp bmNlIGl0IG1lcmVseSBwcm92aWRlcyBhbiBleGFtcGxlIFNjaGVtYSByZXNvdXJjZSBmb3IgYSBV c2VyLg1UaGlzIHNob3VsZCBiZSBsYWJlbGVkIGFzIGEgIm5vbi1ub3JtYXRpdmUiIGV4YW1wbGUu AAChDyQAAAAlAQAAAAABAAAAAgA4AAAABAACAAQAGADtAAAAAAQCAAAEGAAAAKYPBgAAAAgAAAAA ABAA8AcgAAAA////AAAAAADu7OEAH0l9AE+BvQDAUE0AAAD/AIAAgAAAACIECAAAAAEAAAACAAAA DwDuA40GAAACAO8DGAAAABAAAAAAAAAAAAAAAAAAAIAAAAAABwAAAA8ADAQtBgAADwAC8CUGAACQ AAjwCAAAAAMAAAACJAAADwAD8A0GAAAPAATwKAAAAAEACfAQAAAAAQAAAAEAAAD+////AAAAAAIA CvAIAAAAACQAAAUAAAAPAATw4QAAABIACvAIAAAAASQAACACAAADAQvwcAAAAAQAAAAAAH8AAQDv AYAASH5ghIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAQAAAIgAAAAAAL8AAAAGAP8B EAARAAEDAgQAAD8DAAAIAIDDEAAAAL8DAAACAFQAaQB0AGwAZQAgADEAAAAAABDwCAAAAK0AIAFg FX0DDwAR8BwAAAAAAMMLCAAAAP////8NAPm/AAAfBAQAAAACAAAADwAN8B0AAAAAAJ8PBAAAAAAA AAAAAKgPCQAAAElzc3VlICMzNQ8ABPDsBAAAEgAK8AgAAAACJAAAIAIAABMBC/CSAAAABAAAAAAA fwABAO8BgACIEE96gQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAA AAYAvwEBAAEA/wEQABEAAQMDBAAAPwMAAAgAgMMsAAAAvwMAAAIAQwBvAG4AdABlAG4AdAAgAFAA bABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAAAABDwCAAAAPADIAFgFRMPDwAR8BwAAAAAAMMLCAAA AP////8TAPm/AAAfBAQAAAADAAAADwAN8AYEAAAAAJ8PBAAAAAEAAAAAAKAPbAIAAEMAYQBuAG8A bgBpAGMAYQBsACAAdAB5AHAAZQBzACAAZgBvAHIAIABHAHIAbwB1AHAAIABtAGUAbQBiAGUAcgBz ACAAcwBoAG8AdQBsAGQAIABuAG8AdAAgAGIAZQAgAFIARQBBAEQALQBPAE4ATABZAA0ADQBTAGUA ZQAgAHQAaABlACAAZQBtAGEAaQBsACAAdABoAHIAZQBhAGQAIABoAGUAcgBlADoADQALIGgAdAB0 AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYA ZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADAAOQAyADkALgBo AHQAbQBsAA0ADQBCAGEAcwBpAGMAYQBsAGwAeQAsACAAdABoAGUAIABjAGEAbgBvAG4AaQBjAGEA bAAgAHQAeQBwAGUAcwAgAGYAbwByACAARwByAG8AdQBwACAAbQBlAG0AYgBlAHIAcwAgAHMAaABv AHUAbABkACAAYgBlACAAbQBhAHIAawBlAGQAIABhAHMAIAAiAGkAbQBtAHUAdABhAGIAbABlACIA IABpAG4AcwB0AGUAYQBkACAAbwBmACAAcgBlAGEAZAAtAG8AbgBsAHkAIABzAGkAbgBjAGUAIAB0 AGgAZQB5ACAAYwBhAG4AIABiAGUAIABzAHAAZQBjAGkAZgBpAGUAZAAgAHcAaABlAG4AIABpAG4A cwBlAHIAdABpAG4AZwAgAG4AZQB3ACAAZQBsAGUAbQBlAG4AdABzAC4AAAChDzwAAAA3AQAAAAAB AAAAAgA7AAAABAACAAQAGAAcAAAAAAQCAAAEGABBAAAAAAgCAAAIFACfAAAAAAwCAAAMGAAAAKoP PAAAAFcAAAAAAAAABwAAAAAAAAAMAAAAAQAAAAMAEgAAAAAAAAAEAAAAAQAAAAMAFgAAAAAAAACh AAAAAAAAAA8A8g8YAAAAAADzDxAAAAAAAAAANAAAAAQAAAAInDsAAADfDwgAAABXAAAAXgAAAA8A 8g8YAAAAAADzDxAAAAAAAAAANgAAAAQAAAAInDsAAADfDwgAAABeAAAAagAAAA8A8g8YAAAAAADz DxAAAAAAAAAAOAAAAAQAAAAInDsAAADfDwgAAABqAAAAfAAAAA8A8g8YAAAAAADzDxAAAAAAAAAA OgAAAAQAAAAInDsAAADfDwgAAAB8AAAAgAAAAA8A8g8YAAAAAADzDxAAAAAAAAAAPAAAAAQAAAAI nDsAAADfDwgAAACAAAAAlgAAAAAApg8GAAAACAAAAAAAEADwByAAAAD///8AAAAAAO7s4QAfSX0A T4G9AMBQTQAAAP8AgACAAAAAIgQIAAAAAQAAAAIAAAAPAO4DzQ8AAAIA7wMYAAAAEAAAAAAAAAAA AAAAAAAAgAAAAAAHAAAADwAMBG0PAAAPAALwZQ8AAKAACPAIAAAAAwAAAAIoAAAPAAPwTQ8AAA8A BPAoAAAAAQAJ8BAAAAABAAAAAQAAAP3///8AAAAAAgAK8AgAAAAAKAAABQAAAA8ABPDhAAAAEgAK 8AgAAAABKAAAIAIAAAMBC/BwAAAABAAAAAAAfwABAO8BgAAof2CEgQAwZQEAggCYsgAAgwAwZQEA hACYsgAAhQAAAAAAhwABAAAAiAAAAAAAvwAAAAYA/wEQABEAAQMCBAAAPwMAAAgAgMMQAAAAvwMA AAIAVABpAHQAbABlACAAMQAAAAAAEPAIAAAArQAgAWAVfQMPABHwHAAAAAAAwwsIAAAA/////w0A +b8AAB8EBAAAAAIAAAAPAA3wHQAAAAAAnw8EAAAAAAAAAAAAqA8JAAAASXNzdWUgIzM3DwAE8CwO AAASAArwCAAAAAIoAAAgAgAAEwEL8JIAAAAEAAAAAAB/AAEA7wGAADhrQoWBADBlAQCCAJiyAACD ADBlAQCEAJiyAACFAAAAAACHAAAAAACIAAAAAAC/AAAABgC/AQEAAQD/ARAAEQABAwMEAAA/AwAA CACAwywAAAC/AwAAAgBDAG8AbgB0AGUAbgB0ACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAA ABMAIvH3CAAAqcPxCAAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Z q/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4 DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqW qfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvE rwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAAL AAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TL oEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQx MJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ 3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsD BBQABgAIAAAAIQAQrJ9GiQQAALklAAAQAAAAZHJzL3NoYXBleG1sLnhtbOxa70/jNhj+Pmn/g+Wv J67QFW6tCCdAYpuEUEW5z8hNXMjh2JHtMOCv3/PacZugTcfdpgFVIrV5f9mxn9dP3sTt4eeHSrF7 aV1pdMb3Pu5yJnVuilLfZPzL1dnOr5w5L3QhlNEy44/S8c9HP/90WM9czdBYu1md8Vvv69lo5PJb WQn30dRSw7cythIeqr0Z1VY6qb3wuFClRuPd3YNRJUrNj9CVvl/Uc0tSfnE/t6wsMv4LZ1pUuOSp 0R4t2VyJXN4aVUjLxnzURseGAqM5N/mda4ckXjKkwoo/Mc/eaJg2v1lMaI8uMArjSUPTGBldtL7F +B4yPhlPJ9ODT+PpfhsbA9BoMx2HaYWR+ocTUzweHYrZEmdMMUL34+NEzjwmaewTZ+oP7TI+3ZtM kD4flMn+pzEU2/Usex6vTo3K+C4SIGYamTpuvFmVnq2A9yIXCtBPx/u76EXpRZ1fyqLJKXsZR/Jg JoDSdKgP5fzCPyr5b6eGfsUsra0fBih0ApwrYc9pliRcBkHdh2mzUhdYVsEk1A2mpTgr5OpKLBdP yC4BSAj6GC3FuT6xd7QyAkLHoYkAZsAHq1q3bjS5FfoG62re6Bzd7wWAA4Q0Jlfn89yze4Fu9wjH BGQ34kSunsd2MUcfm4jjlU+x3sV+U5eIa73L5lTZq4cA7bJZPK3FMySb+cdarkCujB/bUijKLBLb XIDxQfRiee58EAHQZVjSSH2grJiBFPgC1HdNVVbmaxlRBggZl3rnywJ3EAA6PiA4l8EZQ5qMO31D 9xdb3uHi2iyCxNmdtHQ3CgnIBeioMRQE1nloTqtVqPJJ/h7UpXBSlXR3wgW0mVtjVkEuSusfg+Qq f6qkQKdxvStNg9bmrFQK88JkosUZVRZkDJDS3UwCuIiqf4g3BeSwGyVXK5n7hE9zrltsG+qmlcMC 6cD8odI7ykecpXjmkCI6cvfMkbuWcwCbxueP2DUd3e+kstZKp+hvI5PSBkSVAMAqwjc6psxS9wMF AUKXrm+XglIXc2EFmPktEk5ej4S0pt437zYwDyyJ3NiUoXVRe7sseWmh+juOtAVoqFTpSYFK2HdX qmsWj1iTgkxliY5NXQoyqShRdAR3GxIUfEVjx4Ww5KOWyUNnfJLaU6Jx40qByULn9Ok2DENaB0HY BMULdXQYWK+4vvxx6VVXobQ2POlu6XMTraaYq/eYnC1NyoY2Gylxiyw9Dga9ZyIl8H4dG90U2ekw pp2MOGIoCb11MDwB03PvUNuHt1Axe/FbaCBU5NT/wqa0QfOP+zo7KWLY3Wl3dz5UX9fbDsuG9vsu mipsMmQcr4/LMp9LW5oi7j/8N7s+r/oYs8WVcl27UMNSGUti1JM1usm3tpApKa01neIzd3KmqKAP tH6bm7YDrbdoNzcxD+eOmJRkCsW2DWF9Xg5vmGn//vV35vspvO69ZLyTPG1zCSUWtRtMkVgto4I9 Um7g1tv71YuyRikKx8Cpt/Nr5HvMxfbvdLZcodN7TNA2F6DNbYzuZUnrZSnuReJPRekfRBBdffQX AAAA//8DAFBLAwQUAAYACAAAACEAgtrKaNoAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPS0vD QBSF94L/YbiCm2InpviKnRYRJFoQ+3Lh7jZzm4Rm7sSZaZL+ewcXujycw3f4pvPBNKIj52vLCq7H CQjiwuqaSwXbzcvVPQgfkDU2lknBiTzMZ+dnU8y07XlF3TqUIkLYZ6igCqHNpPRFRQb92LbEsdtb ZzDE6EqpHfYRbhqZJsmtNFhzfKiwpeeKisP6aBSMtvnmeHdY5u/ue/K5+Gj7m260VOryYnh6BBFo CP/jh3T39pX+lb+oV61gAmKfn3au1iv0gZyC6BZNoyXI2Q8AAAD//wMAUEsBAi0AFAAGAAgAAAAh ADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU AAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAU AAYACAAAACEAEKyfRokEAAC5JQAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBL AQItABQABgAIAAAAIQCC2spo2gAAAPkAAAAPAAAAAAAAAAAAAAAAAN8GAABkcnMvZG93bnJldi54 bWxQSwUGAAAAAAQABAD1AAAA5gcAAAAAAAAQ8AgAAADwAyABYBUTDw8AEfCKAAAAAADDCwgAAAD/ ////EwD5vw8AiBNmAAAADwCKE14AAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLE0AAAAAAAKwP OAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAP//wEAAwABAAAAAAAA AAAAAAAfBAQAAAADAAAADwAN8NkDAAAAAJ8PBAAAAAEAAAAAAKgPBwMAAERlZmluZSBlcnJvciBy ZXNwb25zZSB3aGVuIGEgc2VydmVyIGlzIHVud2lsbGluZyB0byBwZXJmb3JtIGEgbGlzdC9xdWVy eQ0NU2VjdGlvbiAzLjIuMiBvZiB0aGUgQVBJIGRvY3VtZW50IGRlZmluZXMgaG93IHRvIHVzZSBh IEdFVCBvcGVyYXRpb24gdG8gbGlzdCBvciBxdWVyeSByZXNvdXJjZXMuIEluIHNvbWUgY2FzZXMs IHNlcnZlcnMgbWF5IGJlIHVud2lsbGluZyB0byBwZXJmb3JtIHRoZXNlIG9wZXJhdGlvbnMgaWYg dGhlIHJlc3VsdHMgYXJlIHRvbyBsYXJnZSB0byByZXR1cm4uIEZvciBleGFtcGxlLCBpZiB0aGUg Y2xpZW50IGRvZXMgbm90IHNwZWNpZnkgYSBzdGFydEluZGV4IGFuZCBjb3VudCB0aGUgc2VydmVy IG1heSBiZSBhc2tlZCB0byByZXR1cm4gbWlsbGlvbnMgb2YgcmVzb3VyY2VzLiBUaGlzIGNvdWxk IGNhdXNlIHNlcnZlciBhbmQgbmV0d29yayBwZXJmb3JtYW5jZSBwcm9ibGVtcy4NUmVjb21tZW5k YXRpb24gdG86DUFsbG93IHNlcnZlcnMgdG8gcmVzcG9uZCB0byBsaXN0L3F1ZXJ5IHJlcXVlc3Rz IHdpdGggYW4gInVud2lsbGluZyB0byBwZXJmb3JtIiBlcnJvciAobWF5YmUgYSA0MDMgRm9yYmlk ZGVuIHN0YXR1cyBjb2RlKQ1BbGxvdyBzZXJ2ZXJzIHRvIHB1Ymxpc2ggbGlzdC9xdWVyeSByZXN0 cmljdGlvbnMgaW4gdGhlIC9TZXJ2aWNlUHJvdmlkZXJDb25maWcgcmVzb3VyY2UuIFRoZXNlIG1p Z2h0IGJlIHNpbWlsYXIgdG8gdGhlIG1heE9wZXJhdGlvbnMvbWF4UGF5bG9hZFNpemUgYnVsayBj b25maWd1cmF0aW9uIG9wdGlvbnMAAKEPUAAAAOABAAAAAAEQAAACAFAAKAEAAAAAkhAAAAMAIiAA AFAASQAAAAQAAgAEABgAAQAAAAQEAgAEBBYAlgEAAAAIAgAACBYAKAEAAAAMAgAADBYAAACqD1AA AABFAQAAAAAAAAoAAAABAAAAAwBDAQAAAAAAABUAAAABAAAAAwApAAAAAAAAAA0AAAABAAAAAwAB AAAAAAAAAA4AAAABAAAAAwAcAAAAAAAAAAAApg8GAAAACAAAAAAAEADwByAAAAD///8AAAAAAO7s 4QAfSX0AT4G9AMBQTQAAAP8AgACAAAAAIgQIAAAAAQAAAAIAAAAPAO4DuAMAAAIA7wMYAAAAEAAA AAAAAAAAAAAAAAAAgAAAAAAHAAAADwAMBFgDAAAPAALwUAMAALAACPAIAAAAAwAAAAIsAAAPAAPw OAMAAA8ABPAoAAAAAQAJ8BAAAABfAF8AAAAGAHpTbU0MAAAAAgAK8AgAAAAALAAABQAAAA8ABPDh AAAAEgAK8AgAAAABLAAAIAIAAAMBC/BwAAAABAAAAAAAfwABAO8BgABoTWCEgQAwZQEAggCYsgAA gwAwZQEAhACYsgAAhQAAAAAAhwABAAAAiAAAAAAAvwAAAAYA/wEQABEAAQMCBAAAPwMAAAgAgMMQ AAAAvwMAAAIAVABpAHQAbABlACAAMQAAAAAAEPAIAAAArQAgAWAVfQMPABHwHAAAAAAAwwsIAAAA /////w0A+b8AAB8EBAAAAAIAAAAPAA3wHQAAAAAAnw8EAAAAAAAAAAAAqA8JAAAASXNzdWUgIzM5 DwAE8BcCAAASAArwCAAAAAIsAAAgAgAAEwEL8JIAAAAEAAAAAAB/AAEA7wGAAIgvQoWBADBlAQCC AJiyAACDADBlAQCEAJiyAACFAAAAAACHAAAAAACIAAAAAAC/AAAABgC/AQEAAQD/ARAAEQABAwME AAA/AwAACACAwywAAAC/AwAAAgBDAG8AbgB0AGUAbgB0ACAAUABsAGEAYwBlAGgAbwBsAGQAZQBy ACAAMgAAAAAAEPAIAAAA8AMgAWAVEw8PABHwHAAAAAAAwwsIAAAA/////xMA+b8AAB8EBAAAAAMA AAAPAA3wMQEAAAAAnw8EAAAAAQAAAAAAqA/jAAAAQ2xhcmlmaWNhdGlvbiBvbiByZXNwb25zZSBi b2R5IGZvciBERUxFVEUNDVNob3VsZCB0aGUgcmVzb3VyY2UgYmUgcmV0dXJuZWQgYXMgcGFydCBv ZiB0aGUgcmVzcG9uc2UgYm9keSBmb3IgYSBERUxFVEU/DVNlY3Rpb24gIjMuNCBEZWxldGluZyBS ZXNvdXJjZXMiIG9ubHkgbWVudGlvbnMgdGhlIHJldHVybiBjb2RlcywgYnV0IG5vdCB3aGF0IHNo b3VsZCBiZSBpbiB0aGUgcmVzcG9uc2UgYm9keS4AAKEPJAAAAOQAAAAAAAEAAAACACsAAAAEAAIA BAAYALkAAAAABAIAAAQYAAAApg8GAAAACAAAAAAAEADwByAAAAD///8AAAAAAO7s4QAfSX0AT4G9 AMBQTQAAAP8AgACAAAAAIgQIAAAAAQAAAAIAAAAPAO4D4hAAAAIA7wMYAAAAEAAAAAAAAAAAAAAA AAAAgAAAAAAHAAAADwAMBIIQAAAPAALwehAAAMAACPAIAAAAAwAAAAIwAAAPAAPwYhAAAA8ABPAo AAAAAQAJ8BAAAABuACAAIgAzAC4ANAAgAEQAAgAK8AgAAAAAMAAABQAAAA8ABPDhAAAAEgAK8AgA AAABMAAAIAIAAAMBC/BwAAAABAAAAAAAfwABAO8BgABYN0KFgQAwZQEAggCYsgAAgwAwZQEAhACY sgAAhQAAAAAAhwABAAAAiAAAAAAAvwAAAAYA/wEQABEAAQMCBAAAPwMAAAgAgMMQAAAAvwMAAAIA VABpAHQAbABlACAAMQAAAAAAEPAIAAAArQAgAWAVfQMPABHwHAAAAAAAwwsIAAAA/////w0A+b8A AB8EBAAAAAIAAAAPAA3wHQAAAAAAnw8EAAAAAAAAAAAAqA8JAAAASXNzdWUgIzQyDwAE8EEPAAAS AArwCAAAAAIwAAAgAgAAEwEL8JIAAAAEAAAAAAB/AAEA7wGAAKiuQYWBADBlAQCCAJiyAACDADBl AQCEAJiyAACFAAAAAACHAAAAAACIAAAAAAC/AAAABgC/AQEAAQD/ARAAEQABAwMEAAA/AwAACACA wywAAAC/AwAAAgBDAG8AbgB0AGUAbgB0ACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAAABMA IvG5CgAAqcOzCgAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNd LnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2 GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJ Jl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmV SzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3 V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAA X3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/ 0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaS tlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3Pfe PqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQA BgAIAAAAIQAvMDih4wQAABw4AAAQAAAAZHJzL3NoYXBleG1sLnhtbOxbXU/jOBR9X2n/Q5TXFVPo lpklIoyAFbsjoVFFmWfkJg7N1rEj22GBXz/n2kmbVitR4KG06zzUjr9in3uP782Ne/r1sRLRA9em VDKNjz4dxhGXmcpLeZ/GP26vDv6II2OZzJlQkqfxEzfx17NffzmtE1NH6CxNUqfxzNo6GQxMNuMV M59UzSXqCqUrZnGr7we15oZLyyweVInB8PDw86BipYzPMJR8mNRjTbns+8NYR2Wexr/HkWQVHnmp pEXPaCxYxmdK5FxHw3jQtvYdGWZzrbK5aafENplSrtm/WOfKbCKp/tJY0BE9YODm001NYmb00HqG +T2m8Wh4Mjr5/GV4cty29Q3Qabkcg2W5mdrHC5U/nZ2yZIoUS/TQvX2ekJnFIpV+jiPxTZo0Pjka jSA+625Gx1+GuNH9mulKjRWXSqTxIQTAEglJnTdWFaWNCuA9yZgA9CfD40OMIuSkzm543mQkvTSG 8FBMAHXLoTGEsRP7JPh7l4ZxWdLp1psBcoMA54rpa1olZW5cRjy4ZUelzKFWroiJeyxLxFHOi1s2 nTxDugQgIWh9a86u5YWek2Y4hM5dFwbMgA+0WrbV6DJj8h56NW5khuGPHMAOQpqTqbNxZqMHhmGP CMcOyH6LC16st+1jjjGWLc4L27W1xo/bDYl2be20uRT69tFBO20mz4vsFYQd2aeaFyBXGp/rkgmS LATbfAfjXday6bWxLguAbpxKQ/SOsiwBKfADqOdNVVbqn9KjDBDSmMuDHxPsIAB0+JngnLpK36RJ YyPvaX/R5RwPl2ricnE055p2IyeAjIGOElNBwzpz3UlbmSif+d/udsoMFyXtTniAVGOtVOHyeant k8uZyl4KzjCo13chadJSXZVCYF1YjC8xSpQ5FTpIaTfjAM6jah/9pgAZ9lvxouCZ7fBprmWLbUPD tHmnID2Yf6vkgbAeZ87WKjjzFZlZq8hMyzmATfOzZ9Gdv9q0n3RVd4sMrRKqgl/0JvHRGIFnAKHP yY/LMy7zMdMM9HuJaaPtMY10arfJtYQ5sMRzY2lrFpbr47JkU2v0XxxprUwwR507QHbqVebIG5vI XTBNne1B2mZ7JStFVO7romCnWodkUmfODel7ezvAwOUG+hY7FTjIkje4hEvQg9UKVguvU+Elyr2v bv4S1dqszkB15ohSb8+CXdptuxQ8ww8QqACZHJ0obhGtunqbR5K26rtzrV0QcE9DSiSYu7uVvW5H BLOnAoHxWZFGiNxRvC7EJEKInCWbe3cwNtjWFs4d7np2iExRG3ygNNAtOHrhi1T7RfDVIUByHzzZ Oo4F+9V9YgwRvfCRN403o1SI6JEd3vtTEVt9l93XVyayQZ0Vcjl33/P/yBMkj69NfHXvhkyXu1zi 872s79nrHkzcjpu4EBzcanCQuOVZ1rGuX7JkXuDZ/4Rn7ujf2mHB8Gn49Z+GWTLD0cj5pSizeXsw F+Hrl49rq6IoM/6nypoKh2T9cW3N6RyjkmZW1gYnYxM6pq2/5d2xyMWxROLwethy8yDyVkW/h9H9 banAYtdeiaftiB7skWe8FfkvhO/2AtoPdlELwm6w+P/Ouw3CLso/7AKDd8nd7QJEfu8QtF9Z1jRh Geh66bzgVj2DPdIFxNWWoHfnBfG/te5Pasia+uwnAAAA//8DAFBLAwQUAAYACAAAACEAa4dl1tYA AAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPS0sDMRSF94L/IVzBTWkzWtQy9raIICOC9On+Ormd GTpJxiTz8tcbXOjycA7f4VuuB12Ljp2vrEG4mSUg2ORWVaZAOB5epgsQPpBRVFvDCCN7WK8uL5aU KtubHXf7UIgIMT4lhDKEJpXS5yVr8jPbsIndyTpNIUZXSOWoj3Bdy9skuZeaKhMfSmr4ueT8vG81 wuSYHdqH8zZ7d1/zj7dN0991ky3i9dXw9Agi8BD+x988Jqr9K39RrwphDuKUjZ+uUjvygR1CdIum 0RLk6gcAAP//AwBQSwMEFAAGAAgAAAAhAFeD0O3qAAAAagEAABsAAABkcnMvX3JlbHMvc2hhcGV4 bWwueG1sLnJlbHOE0M1OwzAMB/A7Eu8Q+b6m3QEQarrLQNqBCxoPYFK3iZYvOdm6vT0BCcQkJI6W 5d/fdr85eydOxNnGoKBrWhAUdBxtmBW87Z9XDyBywTCii4EUXCjDZri96V/JYalD2diURVVCVmBK SY9SZm3IY25iolA7U2SPpZY8y4T6gDPJddveSf5twHBlit2ogHdjB2J/STX5fztOk9W0jfroKZQ/ IqSpEjsbDhVFnqn8sMuyNJbK9LWkR+tWyNrYE8mF3utB1kt9ZP50fZ7brl3fN6Z49w29xLHu+HQu xAEdyKGXVx8aPgAAAP//AwBQSwECLQAUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAAAAAAAAAAAA AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAA AAAAAAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAvMDih4wQAABw4AAAQAAAA AAAAAAAAAAAAACgCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAGuHZdbWAAAA+QAA AA8AAAAAAAAAAAAAAAAAOQcAAGRycy9kb3ducmV2LnhtbFBLAQItABQABgAIAAAAIQBXg9Dt6gAA AGoBAAAbAAAAAAAAAAAAAAAAADwIAABkcnMvX3JlbHMvc2hhcGV4bWwueG1sLnJlbHNQSwUGAAAA AAUABQA+AQAAXwkAAAAAAAAQ8AgAAADwAyABYBUTDw8AEfAcAAAAAADDCwgAAAD/////EwD5vwAA HwQEAAAAAwAAAA8ADfCaAwAAAACfDwQAAAABAAAAAACoD+wBAABDb25zaWRlciBtYWtpbmcgc2Vy dmVyIHJvb3Qgc2VhcmNoZXMgb3B0aW9uYWwNDUluIGlzc3VlICMyNSwgdGhlIGFiaWxpdHkgdG8g c2VhcmNoIGFnYWluc3QgdGhlIHNlcnZlciByb290IHdhcyBhZGRlZDoNDVF1ZXJpZXMgTUFZIGJl IHBlcmZvcm1lZCBhZ2FpbnN0IGEgU0NJTToNUmVzb3VyY2UgKGUuZy4gL1VzZXJzL3t1c2VyaWR9 KSwNUmVzb3VyY2UgVHlwZSBlbmRwb2ludCAoZS5nLiAvVXNlcnMgb3IgL0dyb3VwcyksIG9yDVNl cnZlciBSb290IChlLmcuIC8pLg0NSG93ZXZlciwgZm9yIHNvbWUgc2VydmljZSBwcm92aWRlcnMg aXQgbWF5IGJlIGRpZmZpY3VsdCB0byBwZXJmb3JtIGEgc2VydmVyIHJvb3QgcXVlcnkgdGhhdCBw ZXJmb3JtcyB3ZWxsIGF0IHNjYWxlLg1TZWUgdGhlIGRpc2N1c3Npb24gb24gdGhlIG1haWxpbmcg bGlzdCBoZXJlOg1odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2NpbS9jdXJy ZW50L21zZzAxMDI3Lmh0bWwAAKEPPgAAAO0BAAAAAAEQAAACAFAALgAAAAQAAgAEABgAAQAAAAQE AgAEBBYAfgEAAAAIAgAACBYAQAAAAAAMAgAADBQAAACqD04AAAC3AAAAAAAAAAYAAAABAAAAAwDw AAAAAAAAAAcAAAAAAAAADAAAAAEAAAADABIAAAAAAAAABAAAAAEAAAADABYAAAAAAAAAAQAAAAAA AAAPAPIPGAAAAAAA8w8QAAAAAAAAAD4AAAAEAAAACJw7AAAA3w8IAAAArQEAALQBAAAPAPIPGAAA AAAA8w8QAAAAAAAAAEAAAAAEAAAACJw7AAAA3w8IAAAAtAEAAMABAAAPAPIPGAAAAAAA8w8QAAAA AAAAAEIAAAAEAAAACJw7AAAA3w8IAAAAwAEAANIBAAAPAPIPGAAAAAAA8w8QAAAAAAAAAEQAAAAE AAAACJw7AAAA3w8IAAAA0gEAANYBAAAPAPIPGAAAAAAA8w8QAAAAAAAAAEYAAAAEAAAACJw7AAAA 3w8IAAAA1gEAAOwBAAAAAKYPBgAAAAgAAAAAABAA8AcgAAAA////AAAAAADu7OEAH0l9AE+BvQDA UE0AAAD/AIAAgAAAACIECAAAAAEAAAACAAAADwDuA30QAAACAO8DGAAAABAAAAAAAAAAAAAAAAAA AIAAAAAABwAAAA8ADAQdEAAADwAC8BUQAADQAAjwCAAAAAMAAAACNAAADwAD8P0PAAAPAATwKAAA AAEACfAQAAAAAF+3AgYAAADsekGFPwAAAAIACvAIAAAAADQAAAUAAAAPAATw4QAAABIACvAIAAAA ATQAACACAAADAQvwcAAAAAQAAAAAAH8AAQDvAYAAWDhChYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIA AIUAAAAAAIcAAQAAAIgAAAAAAL8AAAAGAP8BEAARAAEDAgQAAD8DAAAIAIDDEAAAAL8DAAACAFQA aQB0AGwAZQAgADEAAAAAABDwCAAAAK0AIAFgFX0DDwAR8BwAAAAAAMMLCAAAAP////8NAPm/AAAf BAQAAAACAAAADwAN8B0AAAAAAJ8PBAAAAAAAAAAAAKgPCQAAAElzc3VlICM0Ng8ABPDcDgAAEgAK 8AgAAAACNAAAIAIAABMBC/CSAAAABAAAAAAAfwABAO8BgADIhUKFgQAwZQEAggCYsgAAgwAwZQEA hACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYAvwEBAAEA/wEQABEAAQMDBAAAPwMAAAgAgMMs AAAAvwMAAAIAQwBvAG4AdABlAG4AdAAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAATACLx UQkAAKnDSwkAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54 bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1dhrV jIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwRSSZd SBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5lUs4 8glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L91e4 C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAACwAAAF9y ZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BBv9D3 Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCWkrZa ix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz33j6i ahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQUAAYA CAAAACEAAF79qeMEAAAvKwAAEAAAAGRycy9zaGFwZXhtbC54bWzsWlFP4zgQfj/p/oPl1xVb6Jbl qAgrQOLuJIQqyj4jN3Ehi2NHtsMBv35nxnaSVnfaLodYQKmqZDweT+xvPB5nnIMv95Vid9K60uiM 73zc5kzq3BSlvs7418vTrT84c17oQiijZcYfpONfDn//7aCeuppBY+2mdcZvvK+no5HLb2Ql3EdT Sw11S2Mr4aFor0e1lU5qLzw8qFKj8fb251ElSs0PQZW+m9czi1R+fjezrCwy/okzLSp45InRHlqy mRK5vDGqkJaN+ShKh4YCenNm8lsXuyQ26VJhxT8wzpXeMG3+tDCgHXzAiPqTuqahZ/jQ+gb6d5/x yXh/sv95b7y/G2WDADTqhuNgWNRTf39siofDAzFdwB2GGKB7ej/BZh4GaewjZ+pv7TK+vzOZgPk8 FSa7e2Mo2H7NYqXGqxOjMr4NBhBTDZY6arxZlp4tAe95LhRAv7e3uw1alJ7X+YUsmhytl3EwHrAR oDQc1KGcn/sHJf/v0ECvmKa59WSASAngXAl7hqNE4oIIdUfDZqUuYFoRS6hrGJbirJDLS7GYP4J1 EUBE0AdpKc70sb3FmUEIHVETAZgBPjCrdayGJjdCX8O8mjU6B/U7BDBBiH1ydT7LPbsToHYHcUxA 9iWO5XJdto856OgkjpY+yXoX9CaVIBdrF82Jspf3BO2imT+25CkYm/mHWi7BuTJ+ZEuh0LJg2OYc PJ5ILxZnzhMJAF3QlAbTk8uKKTgFXADq26YqK/OtDCgDCBmXeuvrHFYQAPQTjJazBVUGkSbjTl/j +mLLW3i4NnOiOLuVFlcjMkAuwB01dAUE65ya42wVqnyUf1FxIZxUJa5O8ABtZtaYJdFFaf0DUa7y J0oKUBrmu9LYaW1OS6VgXDCYwHFGlQUyCVJczSQAF1D192FRABv2peRyKXOf8GnOdMS2QTWRpgnS g/lDpbeUDzhLsVYhRajI3VpF7qLPAdjYP3/IrugXbrEAHKQ6HqNfTxCHC3MGrqAG7YjKBocDEPrO +XodTupiJqwAP/yBy40nv87lcE69bS/rYB68JPhGF3TaEPZ6vWTDsPSvPhLDzRCX0r4AA9bPxaX1 oBMCUhujiIgluIU/hq1etOrFsSSQmuGdaAxrsXEst+wk0DGIE4otEwlGFyLw8aiz/cViy2wJlGBs iKVx9zSvc9oz9bemb2CV6Bb5p8TSYZ0Q0yfsXzvQh8g6RFZ49xve+OjleqM3PgpAcEmBKN7x1pFd KfIwViUm68VBimIhlJFkd0naot6kJ9xT6epFAmDKxfxnCmcrSQyJnJjI+VB9azMMiwZTe+dNRfmE jMO746LMZ9KWpgiphmdJ8Aw76bV8zTNleMDXyN3SHUvE6Dw+OHdgpqokk6QHT32dKdfBU99PLhZ9 j/yvJTC0tqzoir1X3CD8Ei+RKUIOMRRONjY7DBk88714Ztjxtq7YEdEjkQFeGryRClQOXCSxhmrx Gv7IbdlUF/mJjg1aJUjAry8ViquC1HxVajV0b3zi9ms3ZNJaOix9p0dvZMurq5Wl+41Y5p1aZNVL hnNNPM18Uyc2XVpwyMViLv1FviXoQB9ysUMudsjF/tQpZ9rqhT1b3MfFwtreDrhYQZWBTiRy17YR nVP+aCWkT6TWPqoaTqWe6VQKPuVM320C6erD7wAAAP//AwBQSwMEFAAGAAgAAAAhAKw9Gd/aAAAA +QAAAA8AAABkcnMvZG93bnJldi54bWxEj01Lw0AURfeC/2F4gptiJ1o/SuxrEUEiUrFNW3D5zLwm oZmZODNN0n/v4EKXl3s5lzNbDLoRHTtfW4NwPU5AsCmsqk2JsN28XE1B+EBGUWMNI5zYw2J+fjaj VNnerLnLQykixPiUEKoQ2lRKX1SsyY9tyyZ2e+s0hRhdKZWjPsJ1I2+S5F5qqk18qKjl54qLQ37U CKNttjk+HFbZu/ue7N4+2v6uG60QLy+Gp0cQgYfwP15+TvPd7V/5i3pVCBMQ++z05Wq1Jh/YIUS3 aBotQc5/AAAA//8DAFBLAQItABQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAAAAAA AABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAA AAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAABe/anjBAAALysAABAAAAAAAAAA AAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEArD0Z39oAAAD5AAAADwAA AAAAAAAAAAAAAAA5BwAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAEAIAAAAAAAAEPAI AAAA8AMgAWAVEw8PABHwogAAAAAAwwsIAAAA/////xMA+b8PAIgTfgAAAA8AihN2AAAAAAC6Dw4A AABfAF8AXwBQAFAAVAA5AAAAixNYAAAAAACsD1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAIAD//8BAAMAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA HwQEAAAAAwAAAA8ADfAXBAAAAACfDwQAAAABAAAAAACoD1UDAABDbGFyaWZ5IGVycm9yIHJlc3Bv bnNlcyBhbmQgYWxsb3cgbm9uLUhUVFAgZXJyb3IgY29kZXMNDVRoZSBBUEkgZHJhZnQgc3RhdGVz IHRoYXQgcmVxdWVzdHMgdGhhdCByZXN1bHQgaW4gYW4gZXJyb3IgIk1VU1QgcmV0dXJuIHRoZSBl cnJvcnMgaW4gdGhlIGJvZHkgb2YgdGhlIHJlc3BvbnNlIGluIHRoZSBjbGllbnQgcmVxdWVzdGVk IGZvcm1hdCBjb250YWluaW5nIHRoZSBlcnJvciByZXNwb25zZSBhbmQsIHBlciB0aGUgSFRUUCBz cGVjaWZpY2F0aW9uLCBodW1hbi1yZWFkYWJsZSBleHBsYW5hdGlvbnMuIg0NV2UgbmVlZCB0byBj bGVhcmx5IGRlZmluZSB0aGUgZm9ybWF0IG9mIHRoZSBlcnJvciByZXNwb25zZS4gSGVyZSBhcmUg YSBmZXcgcXVlc3Rpb25zIHRoYXQgSSBoYXZlIGJlZW4gYXNrZWQgcmVnYXJkaW5nIHRoZSBjdXJy ZW50IGVycm9yIHJlc3BvbnNlOg1XaHkgaXMgdGhpcyBhbiBhcnJheSBvZiBjb21wbGV4IG9iamVj dHM/IEhvdyB3b3VsZCBtdWx0aXBsZSBlcnJvcnMgYmUgdXNlZD8NRG9lcyB0aGUgY29kZSBzdWIt YXR0cmlidXRlIGhhdmUgdG8gYmUgdGhlIEhUVFAgZXJyb3IgY29kZT8NSWYgYSBzZXJ2aWNlIHBy b3ZpZGVyIHdhbnRzIHRvIHRyYW5zbWl0IGEgbW9yZSBkZXRhaWxlZCBlcnJvciBjb2RlLCBob3cg d291bGQgaXQgZG8gdGhpcz8gRG9lcyB0aGlzIGhhdmUgdG8gZml0IGludG8gdGhlIGZvcm1hdHRl ZCBkZXNjcmlwdGlvbiBvciBjYW4gYW5vdGhlciBzdWItYXR0cmlidXRlIGJlIGFkZGVkIHRvIHRo ZSBlcnJvciByZXBvbnNlPw0NV2UgbmVlZCB0byBhbnN3ZXIgdGhlc2UgcXVlc3Rpb25zIGFuZCB0 aWdodGVuIHVwIHRoZSBzcGVjIHRvIGJlIG1vcmUgY2xlYXIuAAChD3YAAAC2AQAAAAABEAAAAgBQ AFMBAAAAAJIQAAADACIgAABQAE0AAAAAAAEQAAACAFAANwAAAAQAAgAEABgAAQAAAAQEAgAEBBMA fgEAAAAIAgAACBMAUwEAAAAMAgAADBMATAAAAAAQAgAAEBMAAQAAAAAUAgAAFBEAAACqDxoAAAAA AwAAAAAAAAcAAAABAAAAAwBPAAAAAAAAAAAApg8GAAAACAAAAAAAEADwByAAAAD///8AAAAAAO7s 4QAfSX0AT4G9AMBQTQAAAP8AgACAAAAAIgQIAAAAAQAAAAIAAAAAAHIXPAAAAAEA4AAAAAAA9yMA AEyjAACvrQAAHrEAAK20AABcuAAAk7sAAPS/AAD1wwAAisoAAF/aAAAf3gAACe8AAAAA9Q8cAAAA AAAAAPE+AAMAAAAAjv8AAAEAAAAOAAAADwAAAAAAAAAAAAAAAAD+/wAAAwoBAAAAAAAAAAAAAAAA AAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAD4FAAACwAAAAEAAABgAAAAAgAAAGgAAAAEAAAA iAAAAAgAAACcAAAACQAAALAAAAASAAAAvAAAAAoAAADkAAAADAAAAPAAAAANAAAA/AAAAA8AAAAI AQAAEQAAABABAAACAAAAECcAAB4AAAAYAAAAU0NJTSBjb25mZXJlbmNlIGNhbGwAAAAAHgAAAAwA AABCYXJyeSBMZWliYQAeAAAADAAAAEJhcnJ5IExlaWJhAB4AAAAEAAAAOQAAAB4AAAAgAAAATWlj cm9zb2Z0IE1hY2ludG9zaCBQb3dlclBvaW50AABAAAAAtoTtgwMAAABAAAAAAIwCXH2pzgFAAAAA UHmHGIGpzgEDAAAA4AIAAEcAAADeEwAA/v///1BJQ1QT1gAAAAAAhwC0ABEC/wwA//4AAABIAAAA SAAAAAAAAACHALQAAAAAAB4AAQAKAAAAAACHALQAmv8AAACC0AAAAAAAhwC0AAAABAAAAAAASAAA AEgAAAAQACAABAAIAAAAIAAAAAAAAAAAAAAAAACHALQAAAAAAIcAtAAAAAyB/4H/gf+B/4H/sf8A DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB /4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/ gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B /4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/ gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B /4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/ gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B /4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/ gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B /7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/ sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wBGgf+g/wH8/f3/AP3f /wLZhNHW/wOw6eysqP8B/P39/wD93/8C2YTR1v8DsOnsrKj/Afz9/f8A/d//AtmE0db/A7Dp7KzV /wB2gf+h/w9uNzOl/+pSMSuK/zXp8xRy/v8C2xeT7f8CNK/a1v8DUsrSSqn/D243M6X/6lIxK4r/ NenzFHL+/wLbF5Pt/wI0r9rW/wNSytJKqf8Pbjczpf/qUjEriv816fMUcv7/AtsXk+3/AjSv2tb/ A1LK0krV/wEbgf+i/xbeLf//7v9Ok//+xv8s5+wqJvD//29LhP3/L/fU9///9NX2///p/Nn5/+sZ 5Pz/8df7//zt5uj/+db1///p/Nn5///92Oz///nW9fz/DO7W/f/70+X//1LK0kqq/xbeLf//7v9O k//+xv8s5+wqJvD//29LhP3/L/fU9///9NX2///p/Nn5/+sZ5Pz/8df7//zt5uj/+db1///p/Nn5 ///92Oz///nW9fz/DO7W/f/70+X//1LK0kqq/xbeLf//7v9Ok//+xv8s5+wqJvD//29LhP3/L/fU 9///9NX2///p/Nn5/+sZ5Pz/8df7//zt5uj/+db1///p/Nn5///92Oz///nW9fz/DO7W/f/70+X/ /1LK0krV/wEhgf+i/wfxF7D//+4V/f3/Cizn7C18lP/0MJOE/v8x1yRgO/60M2kryv8mTlsv+4MK X+SyQmc389IwPozdO3Etzf8mTlsv+/g6UUHR3TtxLc3+/w2pJWNl/kVyOpz/UsrSSqr/B/EXsP// 7hX9/f8KLOfsLXyU//Qwk4T+/zHXJGA7/rQzaSvK/yZOWy/7gwpf5LJCZzfz0jA+jN07cS3N/yZO Wy/7+DpRQdHdO3Etzf7/DaklY2X+RXI6nP9SytJKqv8H8Rew///uFf39/wos5+wtfJT/9DCThP7/ MdckYDv+tDNpK8r/Jk5bL/uDCl/kskJnN/PSMD6M3TtxLc3/Jk5bL/v4OlFB0d07cS3N/v8NqSVj Zf5Fcjqc/1LK0krV/wEbgf+h/wXLOTfYzzL8/wos5+wt3jD/mYaVhP7/MWSc//r/KeX/tlL/GOb/ Rs//G///Len5aKPSJ/n/aa75pmP/GOb/Rs+kXP//+2mu+aZj/v8DJNz/+v7/Bs1P/1LK0kqp/wXL OTfYzzL8/wos5+wt3jD/mYaVhP7/MWSc//r/KeX/tlL/GOb/Rs//G///Len5aKPSJ/n/aa75pmP/ GOb/Rs+kXP//+2mu+aZj/v8DJNz/+v7/Bs1P/1LK0kqp/wXLOTfYzzL8/wos5+wt3jD/mYaVhP7/ MWSc//r/KeX/tlL/GOb/Rs//G///Len5aKPSJ/n/aa75pmP/GOb/Rs+kXP//+2mu+aZj/v8DJNz/ +v7/Bs1P/1LK0krV/wEVgf+f/wOXOeQa/P8KLOfsLf9DxzTolYT+/wFEzf7/DxT//9s4/x3//1nD /xv//w3+XxHB0kr//0hMX1+Z/x3//1nDhI3+/wRITF9fmf7/ABL+/wn8bldNSf9SytJKp/8Dlznk Gvz/Cizn7C3/Q8c06JWE/v8BRM3+/w8U///bOP8d//9Zw/8b//8N/l8RwdJK//9ITF9fmf8d//9Z w4SN/v8ESExfX5n+/wAS/v8J/G5XTUn/UsrSSqf/A5c55Br8/wos5+wt/0PHNOiVhP7/AUTN/v8P FP//2zj/Hf//WcP/G///Df5fEcHSSv//SExfX5n/Hf//WcOEjf7/BEhMX1+Z/v8AEv7/CfxuV01J /1LK0krV/wEYgf+i/xbr9//UMP8ypv//0P8s5+wt/6cwVv+VhP7/FWOi/+n+J9z/p2T/Hf//WcT/ G///LOL+/wXSSv//a6L9/wsd//9ZxKNi//jua6L7/w0l4f/nzUP/xkn/UsrSSqr/Fuv3/9Qw/zKm ///Q/yzn7C3/pzBW/5WE/v8VY6L/6f4n3P+nZP8d//9ZxP8b//8s4v7/BdJK//9rov3/Cx3//1nE o2L/+O5rovv/DSXh/+fNQ//GSf9SytJKqv8W6/f/1DD/Mqb//9D/LOfsLf+nMFb/lYT+/xVjov/p /ifc/6dk/x3//1nE/xv//yzi/v8F0kr//2ui/f8LHf//WcSjYv/47mui+/8NJeH/581D/8ZJ/1LK 0krV/wEkgf+i/xbJLEYtu//WNjMwf/8u6O0v//gTv/+Xhv7/MdgrSUD7titNPuP/H///WsX/Hv// ujFZRtjTTP//4ThUTKj/H///WsX3QUM31eE4VEyo/v8NrSdGbvIwVVlK/1PM00yq/xbJLEYtu//W NjMwf/8u6O0v//gTv/+Xhv7/MdgrSUD7titNPuP/H///WsX/Hv//ujFZRtjTTP//4ThUTKj/H/// WsX3QUM31eE4VEyo/v8NrSdGbvIwVVlK/1PM00yq/xbJLEYtu//WNjMwf/8u6O0v//gTv/+Xhv7/ MdgrSUD7titNPuP/H///WsX/Hv//ujFZRtjTTP//4ThUTKj/H///WsX3QUM31eE4VEyo/v8NrSdG bvIwVVlK/1PM00zV/wEPgf+h/wL97f79/w71+////P///P///P///v78/wDu/v8B/vL+/wb8///8 ///8/v8F/uz9///8/f8H8Pn///z///z+/wHx/P7/AfD5/P8M+/H///7y//3//P///Kn/Av3t/v3/ DvX7///8///8///8///+/vz/AO7+/wH+8v7/Bvz///z///z+/wX+7P3///z9/wfw+f///P///P7/ AfH8/v8B8Pn8/wz78f///vL//f/8///8qf8C/e3+/f8O9fv///z///z///z///7+/P8A7v7/Af7y /v8G/P///P///P7/Bf7s/f///P3/B/D5///8///8/v8B8fz+/wHw+fz/DPvx///+8v/9//z///zV /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/ AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB /4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wB8gf+Q/wj9wPn///bBw/35/wH3/Pb/Ab779v8O2brf /+vA1f//1Of/5b7Qh/8I/cD5///2wcP9+f8B9/z2/wG++/b/Dtm63//rwNX//9Tn/+W+0If/CP3A +f//9sHD/fn/Aff89v8Bvvv2/w7Zut//68DV///U5//lvtDE/wC+gf+Q/zrLqvP//8Hq9f395Pb/ 8e3t/7zU+/nj+v/x5/bv7v+47+f//+3p//Xy7f//6vyi/6/9vezfwdT/7v+v9Yj/Osuq8///wer1 /f3k9v/x7e3/vNT7+eP6//Hn9u/u/7jv5///7en/9fLt///q/KL/r/297N/B1P/u/6/1iP86y6rz ///B6vX9/eT2//Ht7f+81Pv54/r/8ef27+7/uO/n///t6f/18u3//+r8ov+v/b3s38HU/+7/r/XF /wC+gf+R/ynzw7/z///frer/udyt+qrPs+i1yvW03LL/nNSiy671uMXC1NvIxdXQs+T+/w37qve5 /9jX/9vU//XQtYj/KfPDv/P//9+t6v+53K36qs+z6LXK9bTcsv+c1KLLrvW4xcLU28jF1dCz5P7/ Dfuq97n/2Nf/29T/9dC1iP8p88O/8///363q/7ncrfqqz7Potcr1tNyy/5zUosuu9bjFwtTbyMXV 0LPk/v8N+6r3uf/Y1//b1P/10LXE/wC+gf+R/wO537Ti/v8h8q3noMi28bT/4NDK6eiryLP/tP+z /8znuPv3uLnExM3Q4/3/Drvn9rj/2Nn/29T/++ew6on/A7nftOL+/yHyreegyLbxtP/g0Mrp6KvI s/+0/7P/zOe4+/e4ucTEzdDj/f8Ou+f2uP/Y2f/b1P/757Dqif8Dud+04v7/IfKt56DItvG0/+DQ yunoq8iz/7T/s//M57j797i5xMTN0OP9/w675/a4/9jZ/9vU//vnsOrF/wDBgf+R/yjg163Y///n +sbfrvv2/6nux+DN3/S1//X/tP+0/8znud/fycjh/vfQ4/7/D8LV9/+r+rny/tjR/ur+v+GJ/yjg 163Y///n+sbfrvv2/6nux+DN3/S1//X/tP+0/8znud/fycjh/vfQ4/7/D8LV9/+r+rny/tjR/ur+ v+GJ/yjg163Y///n+sbfrvv2/6nux+DN3/S1//X/tP+0/8znud/fycjh/vfQ4/7/D8LV9/+r+rny /tjR/ur+v+HF/wC4gf+P/ybf+v//5MDU/+zDy/+xytL/9cH04MLW/9r/2v/m897UyPz8y8Pt5/L+ /w7JxMT16sLh/+TExOjewNaG/ybf+v//5MDU/+zDy/+xytL/9cH04MLW/9r/2v/m897UyPz8y8Pt 5/L+/w7JxMT16sLh/+TExOjewNaG/ybf+v//5MDU/+zDy/+xytL/9cH04MLW/9r/2v/m897UyPz8 y8Pt5/L+/w7JxMT16sLh/+TExOjewNbE/wAUgf+D/wC7gf/O/wC7gf/O/wC7mP8ADIH/gf+B/4H/ gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B /7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/ sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/ AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB /4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/ gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B /4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/ gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B /4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A/wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAAAgAAAALV zdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rsgCAACEAgAAEAAAAAEAAACIAAAAAwAA AJAAAAAPAAAAsAAAAAQAAADYAAAABgAAAOAAAAAHAAAA6AAAAAgAAADwAAAACQAAAPgAAAAKAAAA AAEAABcAAAAIAQAACwAAABABAAAQAAAAGAEAABMAAAAgAQAAFgAAACgBAAANAAAAMAEAAAwAAAAr AgAAAgAAAOn9AAAeAAAAGAAAAE9uLXNjcmVlbiBTaG93ICg0OjMpAAAAAB4AAAAgAAAASW50ZXJu ZXQgTWVzc2FnaW5nIFRlY2hub2xvZ3kAAAADAAAA9v8AAAMAAABFAAAAAwAAAAwAAAADAAAAAAAA AAMAAAAAAAAAAwAAAAAAAAADAAAAAAAOAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA HhAAABAAAAAIAAAAQ2FsaWJyaQAXAAAA77yt77yzIO+8sOOCtOOCt+ODg+OCrwAGAAAAQXJpYWwA DQAAAE9mZmljZSBUaGVtZQAVAAAAU0NJTSBjb25mZXJlbmNlIGNhbGwACQAAAElzc3VlICMyAAkA AABJc3N1ZSAjOQAKAAAASXNzdWUgIzEwAAoAAABJc3N1ZSAjMTMACgAAAElzc3VlICMyNAAKAAAA SXNzdWUgIzM0AAoAAABJc3N1ZSAjMzUACgAAAElzc3VlICMzNwAKAAAASXNzdWUgIzM5AAoAAABJ c3N1ZSAjNDIACgAAAElzc3VlICM0NgAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZAADAAAAAwAA AB4AAAAGAAAAVGhlbWUAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAADAAAAAAAAFwO AAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAAAQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAA AOn9AABBAAAAFA4AAHgAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAA aAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBo AGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5ADIA OQAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAA AB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwA LQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBn ADAAMAA5ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAA AAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAv AG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4A dAAvAG0AcwBnADAAMAA5ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAG AAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYA LgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1 AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAA BwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAu AGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMA aQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAA AAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8A LwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBl AGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMQAwADIANwAuAGgAdABtAGwA AAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0 AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkA dgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMQAwADIANwAu AGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8A AABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBh AHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAA MQAwADIANwAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAAD AAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0A YQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAv AG0AcwBnADAAMQAwADIANwAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAA AwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBv AHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIA cgBlAG4AdAAvAG0AcwBnADAAMQAwADIANwAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAA AAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkA ZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBt AC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAAAAAA AAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3 AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIA LwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5ADIAOQAuAGgAdABtAGwAAAAf AAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQA cAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBl AC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5ADIAOQAuAGgA dABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABA AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIA YwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5 ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAA BwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBp AGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0A cwBnADAAMAA5ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAA AAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIA ZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBl AG4AdAAvAG0AcwBnADAAMQAwADIANwAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMA AAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0 AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8A YwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMQAwADIANwAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAAD AAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcA dwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBz AGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMQAwADIANwAuAGgAdABtAGwAAAAfAAAA AQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6 AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8A dwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMQAwADIANwAuAGgAdABt AGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAA aAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBo AGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMQAwADIA NwAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////wAA9g8jAAAAFAAAAF/AkePS/wAACwD0AwMA+b9CYXJyeSBMZWliYQgA AABCAGEAcgByAHkAIABMAGUAaQBiAGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA --047d7b677efa15cea104e5903ce2-- From samuel@erdtman.se Wed Sep 4 09:42:39 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC7421F9B0D for ; Wed, 4 Sep 2013 09:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOrlVV1eAO1A for ; Wed, 4 Sep 2013 09:42:35 -0700 (PDT) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id EE9C521F9A13 for ; Wed, 4 Sep 2013 09:42:34 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id d51so323493eek.9 for ; Wed, 04 Sep 2013 09:42:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+GPpybvdW3EilmbpS8WPPWP5OL5/wl4nJ02vzBnnWQY=; b=Hw0xQiRGq5ixoPo5HmCiEfPpVf/QgsoEeF520074uTNTQvmtnNWRusoMcIVo/YX2Hc +HZhWDhXRYLwRwUCPS/16VWqyRpGcJ/A8nRtNzELc2pKHrwE5oONIqJFjNhGFSFugQzA gQgPWTZWpJFIVq94NkdgEfKNGy+BdJAtxM2x6C3ytaQfNlVj+lrycOmSublHgG+s/7Rl P6asZwsla+6pZR2ju6nejCG6n7GRFPX0D2rhMrX/W5wFx8Ed+o+Xk5MMGZ2js/S8baBN caL+FHAI+vZs6N9mgfYUAhXeFign9OEU1uIWgNJeIxYmrjzpDtB14ItFD1q0p6cqOS0K eqVA== X-Gm-Message-State: ALoCoQlZvkmcY3AupCp/tQ8PVlAMwY2XE+s4xS8+CXInIjrYiDFrxmCCT7Vy0kA/AOHVziKicu0q MIME-Version: 1.0 X-Received: by 10.14.241.74 with SMTP id f50mr6156101eer.29.1378312952223; Wed, 04 Sep 2013 09:42:32 -0700 (PDT) Received: by 10.14.147.5 with HTTP; Wed, 4 Sep 2013 09:42:32 -0700 (PDT) In-Reply-To: <280662630.503530.1378222833568.JavaMail.zimbra@psu.edu> References: <864794342.259897.1378219309142.JavaMail.zimbra@psu.edu> <280662630.503530.1378222833568.JavaMail.zimbra@psu.edu> Date: Wed, 4 Sep 2013 11:42:32 -0500 Message-ID: From: Samuel Erdtman To: "Steven W. Moyer" Content-Type: multipart/alternative; boundary=001a1132e8dae8514b04e5917d59 Cc: "scim@ietf.org" Subject: Re: [scim] Error responses X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 16:42:40 -0000 --001a1132e8dae8514b04e5917d59 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Interesting, thanks for a very detailed suggestion. When I read it I see that you have found inconsistencies that at least needs to be fixed. It might also be desirable to have both description and reason, however it was my belief the 409 meant conflict and that it therefor did not needed to be spelled out. Regarding the multiple reasons e.g. multiple conflicting attributes I=B4m n= ot so sure it is needed. This is the reason that I do not think it is needed: First, when I implemented for SCIM 1.1 I failed on first error and did not proceed to find all potential errors. The reason that i did it that way was that it was easier. When the client got an error it had to fix it try again and get the next error, fix it and try again until it worked. I can of course do it this way with your proposal to but it creates a more complex error response and it might give the client the impression that all errors are in the first response (which might not be possible). Then it comes to when we would need multiple status codes e.g 400 bad request for a request missing attributes and at the same time has conflicting attributes, which status code should we chose? we could create a more complex structure e.g.: { "location": " https://example.com/v1/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", "method": "PUT", }, "errors": [ { "code": 409, "description": "Conflict" "reason" : "The userName attribute may not be modified on this system", }, { "code": 400, "description": "Bad Request" "reason" : "userType is mandatory", } ] } Finally the backend system might not support to return multiple error messages, this is a minor if returning just one message is ok. So as I wrote initially I would prefer the less complex object type since the benefit of this is minor form my point of view. Cheers //Samuel On Tue, Sep 3, 2013 at 5:40 PM, Steven W. Moyer wrote: > After reviewing the latest drafts of the 2.0 specification, it dawned on > me that we could do a better job of providing error responses. I'll make > several observations and a proposal at the bottom of this e-mail, but > wanted to reference the appropriate sections of the API document. The > sections that refer to error handling are as follows: > > - Section 3. API > > All requests to the Service Provider are made via HTTP operations on > a URL derived from the Base URL. Responses are returned in the body > of the HTTP response, formatted as JSON. Response and error codes > SHOULD be transmitted via the HTTP status code of the response (if > possible), and SHOULD also be specified in the body of the response. > > - Section 3.1 Creating Resources > > If the Service Provider determines creation of the requested Resource > conflicts with existing resources; e.g., a User Resource with a > duplicate userName, the Service Provider MUST return a 409 error and > SHOULD indicate the conflicting attribute(s) in the body of the > response. > > - 3.2.2.2. Filtering > > Providers MAY support additional filter operations if they choose. > Providers MUST decline to filter results if the specified filter > operation is not recognized and return a HTTP 400 error with an > appropriate human readable response. For example, if a Consumer > specified an unsupported operator named 'regex' the Service Provider > should specify an error response description identifying the Consumer > error; e.g., 'The operator 'regex' is not supported.' > > - 3.3.2. Modifying with PATCH > > A delete operation is ignored if the attribute's name > is in the meta.attributes list. If the requested value to delete > does not match a unique value on the Resource the server MAY > return a HTTP 400 error. > > - 3.4. Deleting Resources > > Consumers request Resource removal via DELETE. Service Providers MAY > choose not to permanently delete the Resource, but MUST return a 404 > error code for all operations associated with the previously deleted > Id. Service Providers MUST also omit the Resource from future query > results. In addition the Service Provider MUST not consider the > deleted resource in conflict calculation. For example if a User > resource is deleted, a CREATE request for a User resource with the > same userName as the previously deleted resource should not fail with > a 409 error due to userName conflict. > > { > "Errors":[ > { > "description":"Resource 2819c223-7f76-453a-919d-413861904646 not > found", > "code":"404" > } > ] > } > > 3.5. Bulk > > If a bulk job is processed successfully the HTTP response code 200 OK > MUST be returned, otherwise an appropriate HTTP error code MUST be > returned. > > The Service Provider response MUST include the result of all > processed operations. A location attribute that includes the > Resource's end point MUST be returned for all operations excluding > failed POSTs. The status attribute includes information about the > success or failure of one operation within the bulk job. The > attribute status MUST include the code attribute that holds the HTTP > response code that would have been returned if a single HTTP request > would have been used. If an error occurred the status MUST also > include the description attribute containing a human readable > explanation of the error. > > "status": { > "code": "400", > "description": "Request is unparseable, syntactically incorrect, or > violates schema." > } > > ... > { > "location": " > https://example.com/v1/Users/b7c14771-226c-4d05-8860-134711653041", > "method": "PUT", > "status": { > "code": "412", > "description": "Failed to update as user changed on the server > since you last retrieved it." > } > }, > ... > > - 3.9. HTTP Response Codes > > The SCIM Protocol uses the response status codes defined in HTTP [6] > to indicate operation success or failure. In addition to returning a > HTTP response code implementers MUST return the errors in the body of > the response in the client requested format containing the error > response and, per the HTTP specification, human-readable > explanations. Implementers SHOULD handle the identified errors as > described below. > > { > "Errors":[ > { > "description":"Resource 2819c223-7f76-453a-919d-413861904646 not > found", > "code":"404" > } > ] > } > > My observations are as follows: > > - Several of the sections refer to the fact that error messages might be > plural (such as the phrase "conflicting attribute(s)" in section 3.1), so > the error message structure should allow for plural descriptions. > > - Several of the sections state that the error message should be > human-readable, but the overall error message structure should also be > machine parseable. > > - It's stated that a service provider MUST return a status code, but > SHOULD/MAY return a description of the error in the entity body. Shouldn= 't > the entity body be consistent if it's sent? > > - The Bulk API operation states that an error code must be accompanied by > a human-readable error description (which is inconsistent with the > underlying single operations). > > - When I see the "description" sub-attribute in the "status" attribute, I > mentally expect it to contain the HTTP status message associated with the > status codes (as found here: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). > > - Section 3.9 states that the provider "MUST return the errors in the bod= y > of the response in the client requested format containing the error > response and, per the HTTP specification, human-readable explanations" bu= t > that's not consistent with the description of responses for some of the > operations. The array of "Errors" might return several messages (in the > case of a conflict) but (except for the Bulk operations) there will only > every be a single error code (and it should match the one returned from t= he > server. > > So my proposal would be to strengthen section 3.9 and to make it > consistent with the format needed for the Bulk operations. These needs > could be met by a structure similar to the following fragment: > > { > "location": " > https://example.com/v1/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", > "method": "PUT", > "status": { > "code": 409, > "description": "Conflict" > }, > "reasons": [ > "The userName attribute may not be modified on this system", > "The SSN provided with this request does not match the one stored > in the user's record" > ] > } > > In addition, it could be also be used within the BulkResponse's > "Operations" array attribute (though I haven't thought through where to p= ut > the transient value of the "bulkId" sub-attribute). It's my opinion that > having a unified format for the responses is highly desireable, and that > the format above reduces the inconsistencies stated above. I also believ= e > it meets the requirements of being both human-readable and > machine-parseable. > > I'm sure I've made some mistakes in my assertions and there are probably > gaps in my proposal, but I wanted to present a straw-man to get the > discussion started. Thanks for putting up with my long-winded e-mail! > > Steve > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > --001a1132e8dae8514b04e5917d59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Interesting, thanks for a very detailed suggestion.
Wh= en I read it I see that you have found inconsistencies that at least needs = to be fixed. It might also be desirable to have both description and reason= , however it was my belief the 409 meant conflict and that it therefor did = not needed to be spelled out.


Regarding the multiple reasons e.g. mult= iple conflicting attributes I=B4m not so sure it is needed.

<= /div>
This is the reason that I do not think it is needed:
First, when I implemented for SCIM 1.1 I failed on first error and did not = proceed to find all potential errors. The reason that i did it that way was= that it was easier. When the client got an error it had to fix it try agai= n and get the next error, fix it and try again until it worked. I can of co= urse do it this way with your proposal to but it creates a more complex err= or response and it might give the client the impression that all errors are= in the first response (which might not be possible).

Then it comes to when we would need multiple status cod= es e.g 400 bad request for a request missing attributes and at the same tim= e has conflicting attributes, which status code should we chose? we could c= reate a more complex structure e.g.:
=A0{
=A0 =A0 =A0"location"= : "https://example.com/v1/Users/5d8d29d3-342c-4b5f-8683-a3cb676= 3ffcc"= ,
=A0 =A0 =A0&quo= t;method": "PUT",
=A0 =A0 =A0},
=A0 =A0 =A0&quo= t;errors": [
=A0 =A0 = =A0 =A0{=
=A0 =A0 =A0 =A0= =A0"code": 409,
=A0 =A0 =A0 =A0 =A0"description": "Conflict"
=A0 =A0 = =A0 =A0 =A0"reason" : "The userName attribute may not be mod= ified on this system",
=A0 =A0 =A0 =A0= },
=A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0= =A0"code": 400,
=A0 =A0 =A0 =A0 =A0"description": "Bad Request"=
=A0 =A0 = =A0 =A0 =A0"reason" : "userType is mandatory",
=A0 =A0 = =A0 =A0}
=A0 =A0 =A0]
= =A0 =A0}

Finally the backend system might not support to r= eturn multiple error messages, this is a minor if returning just one messag= e is ok.

So as I wrote initially I would prefer th= e less complex object type since the benefit of this is minor form my point= of view.

Cheers
//Samuel



On Tue, Sep 3, 2= 013 at 5:40 PM, Steven W. Moyer <smoyer@psu.edu> wrote:
After reviewing the latest drafts of the 2.0= specification, it dawned on me that we could do a better job of providing = error responses. =A0I'll make several observations and a proposal at th= e bottom of this e-mail, but wanted to reference the appropriate sections o= f the API document. =A0The sections that refer to error handling are as fol= lows:

- Section 3. API

=A0 =A0All requests to the Service Provider are made via HTTP operations on=
=A0 =A0a URL derived from the Base URL. =A0Responses are returned in the bo= dy
=A0 =A0of the HTTP response, formatted as JSON. =A0Response and error codes=
=A0 =A0SHOULD be transmitted via the HTTP status code of the response (if =A0 =A0possible), and SHOULD also be specified in the body of the response.=

- Section 3.1 Creating Resources

=A0 =A0If the Service Provider determines creation of the requested Resourc= e
=A0 =A0conflicts with existing resources; e.g., a User Resource with a
=A0 =A0duplicate userName, the Service Provider MUST return a 409 error and=
=A0 =A0SHOULD indicate the conflicting attribute(s) in the body of the
=A0 =A0response.

- 3.2.2.2. Filtering

=A0 =A0Providers MAY support additional filter operations if they choose. =A0 =A0Providers MUST decline to filter results if the specified filter
=A0 =A0operation is not recognized and return a HTTP 400 error with an
=A0 =A0appropriate human readable response. =A0For example, if a Consumer =A0 =A0specified an unsupported operator named 'regex' the Service = Provider
=A0 =A0should specify an error response description identifying the Consume= r
=A0 =A0error; e.g., 'The operator 'regex' is not supported.'= ;

- 3.3.2. Modifying with PATCH

=A0 =A0A delete operation is ignored if the attribute's name
=A0 =A0is in the meta.attributes list. =A0If the requested value to delete<= br> =A0 =A0does not match a unique value on the Resource the server MAY
=A0 =A0return a HTTP 400 error.

- 3.4. Deleting Resources

=A0 =A0Consumers request Resource removal via DELETE. =A0Service Providers = MAY
=A0 =A0choose not to permanently delete the Resource, but MUST return a 404=
=A0 =A0error code for all operations associated with the previously deleted=
=A0 =A0Id. =A0Service Providers MUST also omit the Resource from future que= ry
=A0 =A0results. =A0In addition the Service Provider MUST not consider the =A0 =A0deleted resource in conflict calculation. =A0For example if a User =A0 =A0resource is deleted, a CREATE request for a User resource with the =A0 =A0same userName as the previously deleted resource should not fail wit= h
=A0 =A0a 409 error due to userName conflict.

=A0 =A0{
=A0 =A0 =A0"Errors":[
=A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0"description":"Resource 2819c223-7f76-453= a-919d-413861904646 not found",
=A0 =A0 =A0 =A0 =A0"code":"404"
=A0 =A0 =A0 =A0}
=A0 =A0 =A0]
=A0 =A0}

3.5. Bulk

=A0 =A0If a bulk job is processed successfully the HTTP response code 200 O= K
=A0 =A0MUST be returned, otherwise an appropriate HTTP error code MUST be =A0 =A0returned.

=A0 =A0The Service Provider response MUST include the result of all
=A0 =A0processed operations. =A0A location attribute that includes the
=A0 =A0Resource's end point MUST be returned for all operations excludi= ng
=A0 =A0failed POSTs. =A0The status attribute includes information about the=
=A0 =A0success or failure of one operation within the bulk job. =A0The
=A0 =A0attribute status MUST include the code attribute that holds the HTTP=
=A0 =A0response code that would have been returned if a single HTTP request=
=A0 =A0would have been used. =A0If an error occurred the status MUST also =A0 =A0include the description attribute containing a human readable
=A0 =A0explanation of the error.

=A0 =A0"status": {
=A0 =A0 =A0"code": "400",
=A0 =A0 =A0"description": "Request is unparseable, syntactic= ally incorrect, or violates schema."
=A0 =A0}

=A0 =A0...
=A0 =A0 =A0{
=A0 =A0 =A0 =A0"location": "https://exa= mple.com/v1/Users/b7c14771-226c-4d05-8860-134711653041",
=A0 =A0 =A0 =A0"method": "PUT",
=A0 =A0 =A0 =A0"status": {
=A0 =A0 =A0 =A0 =A0"code": "412",
=A0 =A0 =A0 =A0 =A0"description": "Failed to update as user = changed on the server since you last retrieved it."
=A0 =A0 =A0 =A0}
=A0 =A0 =A0},
=A0 =A0...

- 3.9. HTTP Response Codes

=A0 =A0The SCIM Protocol uses the response status codes defined in HTTP [6]=
=A0 =A0to indicate operation success or failure. =A0In addition to returnin= g a
=A0 =A0HTTP response code implementers MUST return the errors in the body o= f
=A0 =A0the response in the client requested format containing the error
=A0 =A0response and, per the HTTP specification, human-readable
=A0 =A0explanations. =A0Implementers SHOULD handle the identified errors as=
=A0 =A0described below.

=A0 =A0{
=A0 =A0 =A0"Errors":[
=A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0"description":"Resource 2819c223-7f76-453= a-919d-413861904646 not found",
=A0 =A0 =A0 =A0 =A0"code":"404"
=A0 =A0 =A0 =A0}
=A0 =A0 =A0]
=A0 =A0}

My observations are as follows:

- Several of the sections refer to the fact that error messages might be pl= ural (such as the phrase "conflicting attribute(s)" in section 3.= 1), so the error message structure should allow for plural descriptions.
- Several of the sections state that the error message should be human-read= able, but the overall error message structure should also be machine parsea= ble.

- It's stated that a service provider MUST return a status code, but SH= OULD/MAY return a description of the error in the entity body. =A0Shouldn&#= 39;t the entity body be consistent if it's sent?

- The Bulk API operation states that an error code must be accompanied by a= human-readable error description (which is inconsistent with the underlyin= g single operations).

- When I see the "description" sub-attribute in the "status&= quot; attribute, I mentally expect it to contain the HTTP status message as= sociated with the status codes (as found here: http://www.w3.org/= Protocols/rfc2616/rfc2616-sec10.html).

- Section 3.9 states that the provider "MUST return the errors in the = body of the response in the client requested format containing the error re= sponse and, per the HTTP specification, human-readable explanations" b= ut that's not consistent with the description of responses for some of = the operations. =A0The array of "Errors" might return several mes= sages (in the case of a conflict) but (except for the Bulk operations) ther= e will only every be a single error code (and it should match the one retur= ned from the server.

So my proposal would be to strengthen section 3.9 and to make it consistent= with the format needed for the Bulk operations. =A0These needs could be me= t by a structure similar to the following fragment:

=A0 =A0{
=A0 =A0 =A0"location": "https://example= .com/v1/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
=A0 =A0 =A0"method": "PUT",
=A0 =A0 =A0"status": {
=A0 =A0 =A0 =A0"code": 409,
=A0 =A0 =A0 =A0"description": "Conflict"
=A0 =A0 =A0},
=A0 =A0 =A0"reasons": [
=A0 =A0 =A0 =A0"The userName attribute may not be modified on this sys= tem",
=A0 =A0 =A0 =A0"The SSN provided with this request does not match the = one stored in the user's record"
=A0 =A0 =A0]
=A0 =A0}

In addition, it could be also be used within the BulkResponse's "O= perations" array attribute (though I haven't thought through where= to put the transient value of the "bulkId" sub-attribute). =A0It= 's my opinion that having a unified format for the responses is highly = desireable, and that the format above reduces the inconsistencies stated ab= ove. =A0I also believe it meets the requirements of being both human-readab= le and machine-parseable.

I'm sure I've made some mistakes in my assertions and there are pro= bably gaps in my proposal, but I wanted to present a straw-man to get the d= iscussion started. =A0Thanks for putting up with my long-winded e-mail!

Steve

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

--001a1132e8dae8514b04e5917d59-- From phil.hunt@oracle.com Thu Sep 5 07:04:00 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1361211E819E for ; Thu, 5 Sep 2013 07:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.929 X-Spam-Level: X-Spam-Status: No, score=-5.929 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arakKwGQ0T9k for ; Thu, 5 Sep 2013 07:03:54 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1578511E819C for ; Thu, 5 Sep 2013 07:03:53 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r85E3qJc001442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Sep 2013 14:03:53 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r85E3p96002820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Sep 2013 14:03:52 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r85E3pSx025695 for ; Thu, 5 Sep 2013 14:03:51 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 05 Sep 2013 07:03:50 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_1A79B8F5-A140-4787-959D-72209C68C6A7" Date: Thu, 5 Sep 2013 07:03:47 -0700 References: <52287B50.8090608@oracle.com> To: "scim@ietf.org WG" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [scim] Query - What should attributes parameter inconsistency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 14:04:00 -0000 --Apple-Mail=_1A79B8F5-A140-4787-959D-72209C68C6A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 A colleague of mine has pointed out an inconsistency in the spec = regarding what should be returned when the attributes parameter is used. = I have no opinion other then results should be consistent, and shouldn't = the record identifier always be returned at minimum? > I have a question on the query of SCIM resources.=20 > In the SCIM specifications (draft-ietf-scim-api-02), in the paragraph = "3.2.2 List/Query Resources", the following request processing is = described: >=20 > Get /Users?attributes=3DuserName >=20 > In the response, 2 resources are returned to the client with for each = one only the attribute userName: >=20 > HTTP/1.1 200 OK > Content-Type: application/json > { > "schemas":["urn:scim:schemas:core:2.0:ListResponse"], > "totalResults":2, > "Resources":[ > { > "userName":"bjensen" > }, > { > "userName":"jsmith" > } > ] > } >=20 >=20 >=20 > Then in "3.7 Additional retrieval query parameter", a similar request = is described with the difference that the id is specified: >=20 > Get /Users/?attributes=3DuserName >=20 > In the response, the resource returned contains the userName = attribute, but also the attributes schemas, id, and meta (with all its = sub-attributes): >=20 > HTTP/1.1 200 OK > Content-Type: application/json > Location: = https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 > ETag: W/"a330bc54f0671c9" > { > "schemas":["urn:scim:schemas:core:2.0:User"], > "id":"2819c223-7f76-453a-919d-413861904646", > "userName":"bjensen", > "meta":{ > "resourceType": "User", > "created":"2011-08-01T18:29:49.793Z", > "lastModified":"2011-08-01T18:29:49.793Z", > = "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904= 646", > "version":"W\/\"a330bc54f0671c9\"" > } > } >=20 > So it is confusing to understand what to return when query attributes = are required:=20 > do we have to have 2 separate processing: one when a list of resources = is returned, and one when a single resource is returned > or is it an error in the specification examples. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_1A79B8F5-A140-4787-959D-72209C68C6A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 A = colleague of mine has pointed out an inconsistency in the spec regarding = what should be returned when the attributes parameter is used. I have no = opinion other then results should be consistent, and shouldn't the = record identifier always be returned at minimum?


I = have a question on the query of SCIM resources. 
In the SCIM = specifications (draft-ietf-scim-api-02), in the paragraph "3.2.2 = List/Query Resources", the following request processing is = described:

Get /Users?attributes=3DuserName

In the = response, 2 resources are returned to the client with for each one only = the attribute userName:

HTTP/1.1 200 =
OK
   Content-Type: =
application/json
   =
{
     =
"schemas":["urn:scim:schemas:core:2.0:ListResponse"],
 &nbs=
p;   "totalResults":2,
     =
"Resources":[
       =
{
         =
"userName":"bjensen"
       =
},
       =
{
         =
"userName":"jsmith"
       =
}
     ]
   =
}



Then in "3.7 Additional retrieval query parameter", a = similar request is described with the difference that the id is = specified:

Get /Users/<id>?attributes=3DuserName

In = the response, the resource returned contains the userName attribute, but = also the attributes schemas, id, and meta (with all its = sub-attributes):

HTTP/1.1 200 OK
   =
Content-Type: application/json
   Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
   ETag: W/"a330bc54f0671c9"
   =
{
     =
"schemas":["urn:scim:schemas:core:2.0:User"],
   =
  =
"id":"2819c223-7f76-453a-919d-413861904646",
   &=
nbsp; "userName":"bjensen",
     =
"meta":{
       "resourceType": =
"User",
       =
"created":"2011-08-01T18:29:49.793Z",
    &n=
bsp;  =
"lastModified":"2011-08-01T18:29:49.793Z",
   &nb=
sp;   "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",<=
/pre>
       =
"version":"W\/\"a330bc54f0671c9\""
     =
}
   }

So it is confusing to understand =
what to return when query attributes are required: 
  1. do =
we have to have 2 separate processing: one when a list of resources is =
returned, and one when a single resource is returned
  2. or is =
it an error in the specification =
examples.
Phil

=
@independentid
phil.hunt@oracle.com
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Thu, 5 Sep 2013 09:22:20 -0700 References: <52287B50.8090608@oracle.com> To: "scim@ietf.org WG" In-Reply-To: X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [scim] Query - What should attributes parameter inconsistency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 16:22:32 -0000 --Apple-Mail=_DC5FD274-CF8D-4E36-9E6A-68F25F212324 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 As an addition, we should specify what should happen when a complex = attribute is specified. I believe on the design call yesterday we discussed that the entire = complex attribute and all of its values are always returned. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-05, at 7:03 AM, Phil Hunt wrote: > A colleague of mine has pointed out an inconsistency in the spec = regarding what should be returned when the attributes parameter is used. = I have no opinion other then results should be consistent, and shouldn't = the record identifier always be returned at minimum? >=20 >=20 >> I have a question on the query of SCIM resources.=20 >> In the SCIM specifications (draft-ietf-scim-api-02), in the paragraph = "3.2.2 List/Query Resources", the following request processing is = described: >>=20 >> Get /Users?attributes=3DuserName >>=20 >> In the response, 2 resources are returned to the client with for each = one only the attribute userName: >>=20 >> HTTP/1.1 200 OK >> Content-Type: application/json >> { >> "schemas":["urn:scim:schemas:core:2.0:ListResponse"], >> "totalResults":2, >> "Resources":[ >> { >> "userName":"bjensen" >> }, >> { >> "userName":"jsmith" >> } >> ] >> } >>=20 >>=20 >>=20 >> Then in "3.7 Additional retrieval query parameter", a similar request = is described with the difference that the id is specified: >>=20 >> Get /Users/?attributes=3DuserName >>=20 >> In the response, the resource returned contains the userName = attribute, but also the attributes schemas, id, and meta (with all its = sub-attributes): >>=20 >> HTTP/1.1 200 OK >> Content-Type: application/json >> Location: = https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >> ETag: W/"a330bc54f0671c9" >> { >> "schemas":["urn:scim:schemas:core:2.0:User"], >> "id":"2819c223-7f76-453a-919d-413861904646", >> "userName":"bjensen", >> "meta":{ >> "resourceType": "User", >> "created":"2011-08-01T18:29:49.793Z", >> "lastModified":"2011-08-01T18:29:49.793Z", >> = "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904= 646", >> "version":"W\/\"a330bc54f0671c9\"" >> } >> } >>=20 >> So it is confusing to understand what to return when query attributes = are required:=20 >> do we have to have 2 separate processing: one when a list of = resources is returned, and one when a single resource is returned >> or is it an error in the specification examples. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_DC5FD274-CF8D-4E36-9E6A-68F25F212324 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 As an = addition, we should specify what should happen when a complex attribute = is specified.

I believe on the design call yesterday = we discussed that the entire complex attribute and all of its values are = always returned.


On 2013-09-05, at 7:03 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:

A = colleague of mine has pointed out an inconsistency in the spec regarding = what should be returned when the attributes parameter is used. I have no = opinion other then results should be consistent, and shouldn't the = record identifier always be returned at minimum?


I have a question on the query of SCIM = resources. 
In the SCIM specifications (draft-ietf-scim-api-02), = in the paragraph "3.2.2 List/Query Resources", the following request = processing is described:

Get /Users?attributes=3DuserName

In= the response, 2 resources are returned to the client with for each one = only the attribute userName:

HTTP/1.1 200 =
OK
   Content-Type: =
application/json
   =
{
     =
"schemas":["urn:scim:schemas:core:2.0:ListResponse"],
 &nbs=
p;   "totalResults":2,
     =
"Resources":[
       =
{
         =
"userName":"bjensen"
       =
},
       =
{
         =
"userName":"jsmith"
       =
}
     ]
   =
}



Then in "3.7 Additional retrieval query parameter", a = similar request is described with the difference that the id is = specified:

Get /Users/<id>?attributes=3DuserName

In = the response, the resource returned contains the userName attribute, but = also the attributes schemas, id, and meta (with all its = sub-attributes):

HTTP/1.1 200 OK
   =
Content-Type: application/json
   Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
   ETag: W/"a330bc54f0671c9"
   =
{
     =
"schemas":["urn:scim:schemas:core:2.0:User"],
   =
  =
"id":"2819c223-7f76-453a-919d-413861904646",
   &=
nbsp; "userName":"bjensen",
     =
"meta":{
       "resourceType": =
"User",
       =
"created":"2011-08-01T18:29:49.793Z",
    &n=
bsp;  =
"lastModified":"2011-08-01T18:29:49.793Z",
   &nb=
sp;   "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",<=
/pre>
       =
"version":"W\/\"a330bc54f0671c9\""
     =
}
   }

So it is confusing to understand =
what to return when query attributes are required: 
  1. do =
we have to have 2 separate processing: one when a list of resources is =
returned, and one when a single resource is returned
  2. or is =
it an error in the specification =
examples.
Phil

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

= --Apple-Mail=_DC5FD274-CF8D-4E36-9E6A-68F25F212324-- From kelly.grizzle@sailpoint.com Thu Sep 5 11:27:34 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DCF21E80EF for ; Thu, 5 Sep 2013 11:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAv-7+VAiOi4 for ; Thu, 5 Sep 2013 11:27:20 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0152.outbound.protection.outlook.com [207.46.163.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3F311E81C0 for ; Thu, 5 Sep 2013 11:27:18 -0700 (PDT) Received: from BLUPR04MB184.namprd04.prod.outlook.com (10.255.189.155) by BLUPR04MB181.namprd04.prod.outlook.com (10.255.189.151) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 5 Sep 2013 18:27:15 +0000 Received: from BLUPR04MB184.namprd04.prod.outlook.com ([169.254.5.56]) by BLUPR04MB184.namprd04.prod.outlook.com ([169.254.5.56]) with mapi id 15.00.0745.000; Thu, 5 Sep 2013 18:27:15 +0000 From: Kelly Grizzle To: Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Query - What should attributes parameter inconsistency Thread-Index: AQHOqkDJSTieDv7cBEKhc8I3DJBXOJm3U64AgAAhlkA= Date: Thu, 5 Sep 2013 18:27:14 +0000 Message-ID: <22b8e3a5422d4f61a289c46c17a2f20c@BLUPR04MB184.namprd04.prod.outlook.com> References: <52287B50.8090608@oracle.com> <035C775B-284F-4EED-8301-A93A40F97512@oracle.com> In-Reply-To: <035C775B-284F-4EED-8301-A93A40F97512@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0DBD9DFB0052CE0DBD9F48 x-originating-ip: [173.226.147.242] x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(189002)(199002)(377454003)(377424004)(16236675002)(69226001)(54356001)(76482001)(54316002)(19609705001)(81816001)(16601075003)(56776001)(53806001)(66066001)(47976001)(80022001)(74316001)(65816001)(15202345003)(31966008)(50986001)(81542001)(83072001)(56816003)(77096001)(74366001)(59766001)(81342001)(77982001)(19300405004)(19580395003)(4396001)(79102001)(74662001)(15975445006)(47736001)(19580405001)(83322001)(74706001)(49866001)(47446002)(74502001)(80976001)(76796001)(63696002)(51856001)(81686001)(46102001)(74876001)(76576001)(76786001)(33646001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR04MB181; H:BLUPR04MB184.namprd04.prod.outlook.com; CLIP:173.226.147.242; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_22b8e3a5422d4f61a289c46c17a2f20cBLUPR04MB184namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Query - What should attributes parameter inconsistency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 18:27:36 -0000 --_000_22b8e3a5422d4f61a289c46c17a2f20cBLUPR04MB184namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is definitely a spec bug since it is not consistent. My vote would be that when the attributes query parameter is specified, *on= ly* the requested attributes are returned (ie - not schema, id, meta, etc..= .). Issue #3 deals with adding an excludedAttributes query parameter, which mig= ht be easier to use if a client were to want most of the information. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Thursday, September 05, 2013 11:22 AM To: scim@ietf.org WG Subject: Re: [scim] Query - What should attributes parameter inconsistency As an addition, we should specify what should happen when a complex attribu= te is specified. I believe on the design call yesterday we discussed that the entire complex= attribute and all of its values are always returned. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-05, at 7:03 AM, Phil Hunt > wrote: A colleague of mine has pointed out an inconsistency in the spec regarding = what should be returned when the attributes parameter is used. I have no op= inion other then results should be consistent, and shouldn't the record ide= ntifier always be returned at minimum? I have a question on the query of SCIM resources. In the SCIM specifications (draft-ietf-scim-api-02), in the paragraph "3.2.= 2 List/Query Resources", the following request processing is described: Get /Users?attributes=3DuserName In the response, 2 resources are returned to the client with for each one o= nly the attribute userName: HTTP/1.1 200 OK Content-Type: application/json { "schemas":["urn:scim:schemas:core:2.0:ListResponse"], "totalResults":2, "Resources":[ { "userName":"bjensen" }, { "userName":"jsmith" } ] } Then in "3.7 Additional retrieval query parameter", a similar request is de= scribed with the difference that the id is specified: Get /Users/?attributes=3DuserName In the response, the resource returned contains the userName attribute, but= also the attributes schemas, id, and meta (with all its sub-attributes): HTTP/1.1 200 OK Content-Type: application/json Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904= 646 ETag: W/"a330bc54f0671c9" { "schemas":["urn:scim:schemas:core:2.0:User"], "id":"2819c223-7f76-453a-919d-413861904646", "userName":"bjensen", "meta":{ "resourceType": "User", "created":"2011-08-01T18:29:49.793Z", "lastModified":"2011-08-01T18:29:49.793Z", "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413= 861904646", "version":"W\/\"a330bc54f0671c9\"" } } So it is confusing to understand what to return when query attributes are r= equired: 1. do we have to have 2 separate processing: one when a list of resources= is returned, and one when a single resource is returned 2. or is it an error in the specification examples. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_22b8e3a5422d4f61a289c46c17a2f20cBLUPR04MB184namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is definitely a spec= bug since it is not consistent.

 <= /p>

My vote would be that whe= n the attributes query parameter is specified, *only* the requested = attributes are returned (ie – not schema, id, meta, etc…).=

 <= /p>

Issue #3 deals with addin= g an excludedAttributes query parameter, which might be easier to use if a = client were to want most of the information.

 <= /p>

--Kelly=

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, September 05, 2013 11:22 AM
To: scim@ietf.org WG
Subject: Re: [scim] Query - What should attributes parameter inconsi= stency

 

As an addition, we should specify what should happen= when a complex attribute is specified.

 

I believe on the design call yesterday we discussed = that the entire complex attribute and all of its values are always returned= .

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com

 

 <= /p>

 <= /p>

 

 

On 2013-09-05, at 7:03 AM, Phil Hunt <phil.hunt@oracle.com> wrote:=



A colleague of mine has pointed out an inconsistency= in the spec regarding what should be returned when the attributes paramete= r is used. I have no opinion other then results should be consistent, and s= houldn't the record identifier always be returned at minimum?

 

 

I have= a question on the query of SCIM resources. 
In the SCIM specifications (draft-ietf-scim-api-02), in the paragraph "= ;3.2.2 List/Query Resources", the following request processing is desc= ribed:

Get /Users?attributes=3DuserName

In the response, 2 resources are returned to the client with for each one o= nly the attribute userName:

HTTP/1.1 200 OK
   Content-Type: application/json
   {
     "schemas":["urn:scim:schemas:c=
ore:2.0:ListResponse"],
     "totalResults":2,
     "Resources":[
       {
         "userName":=
"bjensen"
       },
       {
         "userName":=
"jsmith"
       }
     ]
   }




Then in "3.7 Additional retrieval query parameter", a similar req= uest is described with the difference that the id is specified:

Get /Users/<id>?attributes=3DuserName

In the response, the resource returned contains the userName attribute, but= also the attributes schemas, id, and meta (with all its sub-attributes):

HTTP/1.1 200 OK
   Content-Type: application/json
   Location: https://example.com/v1/Users/2819c223-7f76-4=
53a-919d-413861904646
   ETag: W/"a330bc54f0671c9"
   {
     "schemas":["urn:scim:schemas:c=
ore:2.0:User"],
     "id":"2819c223-7f76-453a-919d-=
413861904646",
     "userName":"bjensen",
     "meta":{
       "resourceType": "U=
ser",
       "created":"2011-08=
-01T18:29:49.793Z",
       "lastModified":"20=
11-08-01T18:29:49.793Z",
       "location":"htt=
ps://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
       "version":"W\/\&qu=
ot;a330bc54f0671c9\""
     }
   }


So it is confusing to understand what to return when query attributes are r= equired: 

1.   do we have to have 2 separate= processing: one when a list of resources is returned, and one when a singl= e resource is returned

2.   or is it an error in the spec= ification examples.

Phil

 

@independentid

phil.hunt@oracle.com

&= nbsp;

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

 

--_000_22b8e3a5422d4f61a289c46c17a2f20cBLUPR04MB184namprd04pro_-- From bjorn.aannestad@unboundid.com Thu Sep 5 11:57:11 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2387F21E8109 for ; Thu, 5 Sep 2013 11:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TRxfUqYfJio for ; Thu, 5 Sep 2013 11:57:06 -0700 (PDT) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id BE35E21E80F2 for ; Thu, 5 Sep 2013 11:57:05 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id ta17so2444731obb.32 for ; Thu, 05 Sep 2013 11:57:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=ULiOr71MUeyehhREYdNbSj/P1RbnrURSTnMOt/gNkh4=; b=ZkvUgkGU0gg4Jq/3nxUFZ42cuKdbLLmvuGzR/onBn0nxo37YPh+g2AvADMrPeGKJAH nCXnvQLgYz44fRInqVKcrQNRWhIuYiAqg4F5gOp0UzpGSQ4000fE3fEVLozCAO+a0fNs 2v5tTH3ZTllmPTRgFQ1gZoW2klylL7N0xiWtzV1vtD+bxlrGonW0hJwapFY4796kk1cU kh+WV8ihlq1RnETXjPV6EG1LvkH4Av8QY+mfeRp0BFSHyUzg2lae9VnWJy3nW16OtbeH a7JVUfEnSjIHYG3/In6t6mvPsDQwEAxRR4B+oUlm3Yqfi610AiiGmd3rB0b+I71Mzoki nvQg== X-Gm-Message-State: ALoCoQk3MFu2OykiqB3wSUGQ+VljwJkLaw/ocF0DY/2yhLFPV17Pvl7nvclTSyhAoHagGBjWJ+yR X-Received: by 10.182.226.199 with SMTP id ru7mr7506454obc.12.1378407425091; Thu, 05 Sep 2013 11:57:05 -0700 (PDT) Received: from [10.8.1.116] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPSA id bq4sm30932089obb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Sep 2013 11:57:04 -0700 (PDT) Message-ID: <5228D3FE.7090902@unboundid.com> Date: Thu, 05 Sep 2013 13:57:02 -0500 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Phil Hunt References: <52287B50.8090608@oracle.com> <035C775B-284F-4EED-8301-A93A40F97512@oracle.com> In-Reply-To: <035C775B-284F-4EED-8301-A93A40F97512@oracle.com> Content-Type: multipart/alternative; boundary="------------080502020902010000000507" Cc: "scim@ietf.org WG" Subject: Re: [scim] Query - What should attributes parameter inconsistency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 18:57:11 -0000 This is a multi-part message in MIME format. --------------080502020902010000000507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Only the requested attributes should be returned. Although "meta" is arguably a special attribute, it's easy enough for a client to include it in the request if they depend on it. -Bjorn __________________________________________________________ Bjorn Aannestad | Dir, Product Management | UnboundID Corp mailto:bjorn@unboundid.com | 512-769-6461 On 2013-09-05 11:22 AM, Phil Hunt wrote: > As an addition, we should specify what should happen when a complex > attribute is specified. > > I believe on the design call yesterday we discussed that the entire > complex attribute and all of its values are always returned. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > On 2013-09-05, at 7:03 AM, Phil Hunt > wrote: > >> A colleague of mine has pointed out an inconsistency in the spec >> regarding what should be returned when the attributes parameter is >> used. I have no opinion other then results should be consistent, and >> shouldn't the record identifier always be returned at minimum? >> >> >>> I have a question on the query of SCIM resources. >>> In the SCIM specifications (draft-ietf-scim-api-02), in the >>> paragraph "3.2.2 List/Query Resources", the following request >>> processing is described: >>> >>> Get /Users?attributes=userName >>> >>> In the response, 2 resources are returned to the client with for >>> each one only the attribute userName: >>> >>> HTTP/1.1 200 OK >>> Content-Type: application/json >>> { >>> "schemas":["urn:scim:schemas:core:2.0:ListResponse"], >>> "totalResults":2, >>> "Resources":[ >>> { >>> "userName":"bjensen" >>> }, >>> { >>> "userName":"jsmith" >>> } >>> ] >>> } >>> >>> >>> >>> Then in "3.7 Additional retrieval query parameter", a similar >>> request is described with the difference that the id is specified: >>> >>> Get /Users/?attributes=userName >>> >>> In the response, the resource returned contains the userName >>> attribute, but also the attributes schemas, id, and meta (with all >>> its sub-attributes): >>> >>> HTTP/1.1 200 OK >>> Content-Type: application/json >>> Location:https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>> ETag: W/"a330bc54f0671c9" >>> { >>> "schemas":["urn:scim:schemas:core:2.0:User"], >>> "id":"2819c223-7f76-453a-919d-413861904646", >>> "userName":"bjensen", >>> "meta":{ >>> "resourceType": "User", >>> "created":"2011-08-01T18:29:49.793Z", >>> "lastModified":"2011-08-01T18:29:49.793Z", >>> "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646", >>> "version":"W\/\"a330bc54f0671c9\"" >>> } >>> } >>> >>> So it is confusing to understand what to return when query >>> attributes are required: >>> >>> 1. do we have to have 2 separate processing: one when a list of >>> resources is returned, and one when a single resource is returned >>> 2. or is it an error in the specification examples. >>> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------080502020902010000000507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Only the requested attributes should be returned.   Although "meta" is arguably a special attribute, it's easy enough for a client to include it in the request if they depend on it.

-Bjorn

 
__________________________________________________________
Bjorn Aannestad | Dir, Product Management | UnboundID Corp
mailto:bjorn@unboundid.com | 512-769-6461

On 2013-09-05 11:22 AM, Phil Hunt wrote:
As an addition, we should specify what should happen when a complex attribute is specified.

I believe on the design call yesterday we discussed that the entire complex attribute and all of its values are always returned.


On 2013-09-05, at 7:03 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

A colleague of mine has pointed out an inconsistency in the spec regarding what should be returned when the attributes parameter is used. I have no opinion other then results should be consistent, and shouldn't the record identifier always be returned at minimum?


I have a question on the query of SCIM resources. 
In the SCIM specifications (draft-ietf-scim-api-02), in the paragraph "3.2.2 List/Query Resources", the following request processing is described:

Get /Users?attributes=userName

In the response, 2 resources are returned to the client with for each one only the attribute userName:

HTTP/1.1 200 OK
   Content-Type: application/json
   {
     "schemas":["urn:scim:schemas:core:2.0:ListResponse"],
     "totalResults":2,
     "Resources":[
       {
         "userName":"bjensen"
       },
       {
         "userName":"jsmith"
       }
     ]
   }



Then in "3.7 Additional retrieval query parameter", a similar request is described with the difference that the id is specified:

Get /Users/<id>?attributes=userName

In the response, the resource returned contains the userName attribute, but also the attributes schemas, id, and meta (with all its sub-attributes):

HTTP/1.1 200 OK
   Content-Type: application/json
   Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
   ETag: W/"a330bc54f0671c9"
   {
     "schemas":["urn:scim:schemas:core:2.0:User"],
     "id":"2819c223-7f76-453a-919d-413861904646",
     "userName":"bjensen",
     "meta":{
       "resourceType": "User",
       "created":"2011-08-01T18:29:49.793Z",
       "lastModified":"2011-08-01T18:29:49.793Z",
       "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
       "version":"W\/\"a330bc54f0671c9\""
     }
   }

So it is confusing to understand what to return when query attributes are required: 
  1. do we have to have 2 separate processing: one when a list of resources is returned, and one when a single resource is returned
  2. or is it an error in the specification examples.
Phil

@independentid
phil.hunt@oracle.com


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



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

--------------080502020902010000000507-- From phil.hunt@oracle.com Thu Sep 5 12:02:59 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE52321E814F for ; Thu, 5 Sep 2013 12:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.956 X-Spam-Level: X-Spam-Status: No, score=-5.956 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTOpkmITkmUh for ; Thu, 5 Sep 2013 12:02:54 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEA621E814C for ; Thu, 5 Sep 2013 12:02:54 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r85J2rCY023806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Sep 2013 19:02:53 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r85J2qbI028925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Sep 2013 19:02:53 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r85J2qBN019066; Thu, 5 Sep 2013 19:02:52 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 05 Sep 2013 12:02:51 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_135181D7-95F7-46DE-99C7-E47DB2C81CE5" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Phil Hunt In-Reply-To: <5228D3FE.7090902@unboundid.com> Date: Thu, 5 Sep 2013 12:02:51 -0700 Message-Id: <299BB16F-7DE8-464B-B99B-B69F446D8839@oracle.com> References: <52287B50.8090608@oracle.com> <035C775B-284F-4EED-8301-A93A40F97512@oracle.com> <5228D3FE.7090902@unboundid.com> To: Bjorn Aannestad X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "scim@ietf.org WG" Subject: Re: [scim] Query - What should attributes parameter inconsistency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 19:02:59 -0000 --Apple-Mail=_135181D7-95F7-46DE-99C7-E47DB2C81CE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 We should discuss meta attributes that are always returned vs. those = that are "operational" (only returned on request). For example, I doubt = a client asking for "username" is interested in any time stamp values. My feeling is that only the requested attributes and the record = identifier should be returned. One other consideration is schema -- the client needs enough information = to parse the result. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-05, at 11:57 AM, Bjorn Aannestad = wrote: > Only the requested attributes should be returned. Although "meta" is = arguably a special attribute, it's easy enough for a client to include = it in the request if they depend on it. >=20 > -Bjorn >=20 > __________________________________________________________ > Bjorn Aannestad | Dir, Product Management | UnboundID Corp > mailto:bjorn@unboundid.com | 512-769-6461 >=20 > On 2013-09-05 11:22 AM, Phil Hunt wrote: >> As an addition, we should specify what should happen when a complex = attribute is specified. >>=20 >> I believe on the design call yesterday we discussed that the entire = complex attribute and all of its values are always returned. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-09-05, at 7:03 AM, Phil Hunt wrote: >>=20 >>> A colleague of mine has pointed out an inconsistency in the spec = regarding what should be returned when the attributes parameter is used. = I have no opinion other then results should be consistent, and shouldn't = the record identifier always be returned at minimum? >>>=20 >>>=20 >>>> I have a question on the query of SCIM resources.=20 >>>> In the SCIM specifications (draft-ietf-scim-api-02), in the = paragraph "3.2.2 List/Query Resources", the following request processing = is described: >>>>=20 >>>> Get /Users?attributes=3DuserName >>>>=20 >>>> In the response, 2 resources are returned to the client with for = each one only the attribute userName: >>>>=20 >>>> HTTP/1.1 200 OK >>>> Content-Type: application/json >>>> { >>>> "schemas":["urn:scim:schemas:core:2.0:ListResponse"], >>>> "totalResults":2, >>>> "Resources":[ >>>> { >>>> "userName":"bjensen" >>>> }, >>>> { >>>> "userName":"jsmith" >>>> } >>>> ] >>>> } >>>>=20 >>>>=20 >>>>=20 >>>> Then in "3.7 Additional retrieval query parameter", a similar = request is described with the difference that the id is specified: >>>>=20 >>>> Get /Users/?attributes=3DuserName >>>>=20 >>>> In the response, the resource returned contains the userName = attribute, but also the attributes schemas, id, and meta (with all its = sub-attributes): >>>>=20 >>>> HTTP/1.1 200 OK >>>> Content-Type: application/json >>>> Location: = https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>>> ETag: W/"a330bc54f0671c9" >>>> { >>>> "schemas":["urn:scim:schemas:core:2.0:User"], >>>> "id":"2819c223-7f76-453a-919d-413861904646", >>>> "userName":"bjensen", >>>> "meta":{ >>>> "resourceType": "User", >>>> "created":"2011-08-01T18:29:49.793Z", >>>> "lastModified":"2011-08-01T18:29:49.793Z", >>>> = "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904= 646", >>>> "version":"W\/\"a330bc54f0671c9\"" >>>> } >>>> } >>>>=20 >>>> So it is confusing to understand what to return when query = attributes are required:=20 >>>> do we have to have 2 separate processing: one when a list of = resources is returned, and one when a single resource is returned >>>> or is it an error in the specification examples. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_135181D7-95F7-46DE-99C7-E47DB2C81CE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 We = should discuss meta attributes that are always returned vs. those that = are "operational" (only returned on request).  For example, I doubt = a client asking for "username" is interested in any time stamp = values.

My feeling is that only the requested = attributes and the record identifier should be = returned.

One other consideration is schema -- = the client needs enough information to parse the = result.


On 2013-09-05, at 11:57 AM, Bjorn Aannestad <bjorn.aannestad@unboundid.co= m> wrote:

=20 =20
Only the requested attributes should be returned. =   Although "meta" is arguably a special attribute, it's easy enough for a client to include it in the request if they depend on = it.

-Bjorn

 
__________________________________________________________
Bjorn Aannestad | Dir, Product Management | UnboundID Corp
mailto:bjorn@unboundid.com | =
512-769-6461

On 2013-09-05 11:22 AM, Phil Hunt wrote:
As an addition, we should specify what should happen when a complex attribute is specified.

I believe on the design call yesterday we discussed that the entire complex attribute and all of its values are always returned.


On 2013-09-05, at 7:03 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

A colleague of mine has pointed out an inconsistency in the spec regarding what should be returned when the attributes parameter is used. I have no opinion other then results should be consistent, and shouldn't the record identifier always be returned at minimum?


I have a question on the query of SCIM = resources. 
In the SCIM specifications (draft-ietf-scim-api-02), in the paragraph "3.2.2 List/Query Resources", the following request processing is = described:

Get = /Users?attributes=3DuserName

In the response, 2 resources are returned to the client with for each one only the attribute userName:

HTTP/1.1 200 OK
   Content-Type: =
application/json
   {
     =
"schemas":["urn:scim:schemas:core:2.0:ListResponse"],
     =
"totalResults":2,
     =
"Resources":[
= 
       {
= 
         =
"userName":"bjensen"
= 
       },
= 
       {
= 
         =
"userName":"jsmith"
= 
       }
     =
]
   }



Then in "3.7 Additional retrieval query parameter", a similar request is described with the difference that the id is specified:

Get = /Users/<id>?attributes=3DuserName

In the response, the resource returned contains the userName attribute, but also the attributes schemas, id, and meta (with all its = sub-attributes):

HTTP/1.1 200 OK
   Content-Type: =
application/json
   Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
                                        
   ETag: =
W/"a330bc54f0671c9"

                                        
   {

                                        
     =
"schemas":["urn:scim:schemas:core:2.0:User"],

                                        
     =
"id":"2819c223-7f76-453a-919d-413861904646",

                                        
     =
"userName":"bjensen",

                                        
     =
"meta":{

                                        =

       "resourceType": "User",

                                        =

       =
"created":"2011-08-01T18:29:49.793Z",

                                        =

       =
"lastModified":"2011-08-01T18:29:49.793Z",

                                        =

       "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",<=
/pre>
                                        =

       =
"version":"W\/\"a330bc54f0671c9\""

                                        
     =
}

                                        
   }

                                        

                                        So it is confusing to understand
                                        what to return when query
                                        attributes are =
required: 

                                        
    
                                          
  1. do we have to have 2
                                            separate processing: one
                                            when a list of resources is
                                            returned, and one when a
                                            single resource is =
returned
    
                                          
    2. 
                                          
  2. or is it an error in the
                                            specification examples.
    3.
Phil

@independentid
phil.hunt@oracle.com



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

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

= --Apple-Mail=_135181D7-95F7-46DE-99C7-E47DB2C81CE5-- From samuel@erdtman.se Thu Sep 5 15:51:33 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F2221E818C for ; Thu, 5 Sep 2013 15:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhKlp6cjBwDQ for ; Thu, 5 Sep 2013 15:51:28 -0700 (PDT) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1D721E8185 for ; Thu, 5 Sep 2013 15:51:27 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id o10so1249940eaj.27 for ; Thu, 05 Sep 2013 15:51:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=X6g0R51FHaJ1wdCtLKFouloKBc/YopgCTqpNIG4vAJU=; b=LW4Wo68zqpTOda3KyhRwEK7LGDib1g+RMaLgmXrzXQrN69Az94xnoVlTU74dS/GKVN zJXqEFgOt3AZsU1MSQvNjTHPbK+DIBhPzcbP0cuO4EOhbB8L1z4XMSDJhKjLUFtctLL3 EpgeFsAsEZqEY5xRpqmRchXo3805gy9df31bh166VW/veEsPTP7IXWAjSh3MljAtr0sK dK0OSF2+UsspJMx6o/XCKKsAGQLwKJ5BswFFHcknJRi4anR0XphyL3xSRtOtrs53EwEE U9A93Ugr5zzMNtCFi6vasQCTTVKWIpqr9lXDlc0YBx5nGzrW8E0gl1tgBJOrC/sHjhvb 4j6g== X-Gm-Message-State: ALoCoQmWxvi+/FgkJutzQxH2BZbQ7efa49EFbKCz5J+jUmDFlc7mw/TuZOtnuyCB6V2rKqlTm4hB MIME-Version: 1.0 X-Received: by 10.14.183.130 with SMTP id q2mr17293049eem.5.1378421487113; Thu, 05 Sep 2013 15:51:27 -0700 (PDT) Received: by 10.14.147.5 with HTTP; Thu, 5 Sep 2013 15:51:27 -0700 (PDT) In-Reply-To: <299BB16F-7DE8-464B-B99B-B69F446D8839@oracle.com> References: <52287B50.8090608@oracle.com> <035C775B-284F-4EED-8301-A93A40F97512@oracle.com> <5228D3FE.7090902@unboundid.com> <299BB16F-7DE8-464B-B99B-B69F446D8839@oracle.com> Date: Thu, 5 Sep 2013 17:51:27 -0500 Message-ID: From: Samuel Erdtman To: Phil Hunt Content-Type: multipart/alternative; boundary=047d7b34429e1748bc04e5aac39a Cc: "scim@ietf.org WG" Subject: Re: [scim] Query - What should attributes parameter inconsistency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 22:51:33 -0000 --047d7b34429e1748bc04e5aac39a Content-Type: text/plain; charset=ISO-8859-1 +1 on requested attribute only. It will give better flexibility since it is not hard to include meta and schema if those are desired. Cheers //Samuel On Thu, Sep 5, 2013 at 2:02 PM, Phil Hunt wrote: > We should discuss meta attributes that are always returned vs. those that > are "operational" (only returned on request). For example, I doubt a > client asking for "username" is interested in any time stamp values. > > My feeling is that only the requested attributes and the record identifier > should be returned. > > One other consideration is schema -- the client needs enough information > to parse the result. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > On 2013-09-05, at 11:57 AM, Bjorn Aannestad > wrote: > > Only the requested attributes should be returned. Although "meta" is > arguably a special attribute, it's easy enough for a client to include it > in the request if they depend on it. > > -Bjorn > > __________________________________________________________ > Bjorn Aannestad | Dir, Product Management | UnboundID Corpmailto:bjorn@unboundid.com | 512-769-6461 > > > On 2013-09-05 11:22 AM, Phil Hunt wrote: > > As an addition, we should specify what should happen when a complex > attribute is specified. > > I believe on the design call yesterday we discussed that the entire > complex attribute and all of its values are always returned. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > On 2013-09-05, at 7:03 AM, Phil Hunt wrote: > > A colleague of mine has pointed out an inconsistency in the spec > regarding what should be returned when the attributes parameter is used. I > have no opinion other then results should be consistent, and shouldn't the > record identifier always be returned at minimum? > > > I have a question on the query of SCIM resources. > In the SCIM specifications (draft-ietf-scim-api-02), in the paragraph > "3.2.2 List/Query Resources", the following request processing is described: > > Get /Users?attributes=userName > > In the response, 2 resources are returned to the client with for each one > only the attribute userName: > > HTTP/1.1 200 OK > > Content-Type: application/json > > { > > "schemas":["urn:scim:schemas:core:2.0:ListResponse"], > > "totalResults":2, > > "Resources":[ > > { > > "userName":"bjensen" > > }, > > { > > "userName":"jsmith" > > } > > ] > > } > > > > > Then in "3.7 Additional retrieval query parameter", a similar request is > described with the difference that the id is specified: > > Get /Users/?attributes=userName > > In the response, the resource returned contains the userName attribute, > but also the attributes schemas, id, and meta (with all its sub-attributes): > > HTTP/1.1 200 OK > > Content-Type: application/json > > Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 > > ETag: W/"a330bc54f0671c9" > > { > > "schemas":["urn:scim:schemas:core:2.0:User"], > > "id":"2819c223-7f76-453a-919d-413861904646", > > "userName":"bjensen", > > "meta":{ > > "resourceType": "User", > > "created":"2011-08-01T18:29:49.793Z", > > "lastModified":"2011-08-01T18:29:49.793Z", > > "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646" , > > "version":"W\/\"a330bc54f0671c9\"" > > } > > } > > > So it is confusing to understand what to return when query attributes are > required: > > 1. do we have to have 2 separate processing: one when a list of > resources is returned, and one when a single resource is returned > 2. or is it an error in the specification examples. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > > > _______________________________________________ > scim mailing listscim@ietf.orghttps://www.ietf.org/mailman/listinfo/scim > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --047d7b34429e1748bc04e5aac39a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 on requested attribute only.

It will= give better flexibility since it is not hard to include meta and schema if= those are desired.

Cheers
//Samuel


On Thu,= Sep 5, 2013 at 2:02 PM, Phil Hunt <phil.hunt@oracle.com>= wrote:
We shoul= d discuss meta attributes that are always returned vs. those that are "= ;operational" (only returned on request). =A0For example, I doubt a cl= ient asking for "username" is interested in any time stamp values= .

My feeling is that only the requested attributes and the rec= ord identifier should be returned.

One other consi= deration is schema -- the client needs enough information to parse the resu= lt.




On 2013-09-05, at 11:57 AM, Bjorn Aannestad <bjorn.aannestad@unbou= ndid.com> wrote:

=20 =20 =20
Only the requested attributes should be returned. =A0 Although "meta" is arguably a special attribute, it's e= asy enough for a client to include it in the request if they depend on it.

-Bjorn

 
______________________________________________________=
____
Bjorn Aannestad | Dir, Product Management | UnboundID Corp
mailto:bjorn@unbou=
ndid.com | 512-769-6461

On 2013-09-05 11:22 AM, Phil Hunt wrote:
=20 As an addition, we should specify what should happen when a complex attribute is specified.

I believe on the design call yesterday we discussed that the entire complex attribute and all of its values are always returned.


On 2013-09-05, at 7:03 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

=20
A colleague of mine has pointed out an inconsistency in the spec regarding what should be returned when the attributes parameter is used. I have no opinion other then results should be consistent, and shouldn't the record identifier always be returned at minimum?


I have a question on the query of SCIM resources.=A0<= br> In the SCIM specifications (draft-ietf-scim-api-02), in the paragraph "3.2.2 List/Query Resources", the following request processing is described:
Get /Users?attributes=3DuserName
In the response, 2 resources are returned to the client with for each one only the attribute userName:

HTTP/1.1 200 OK
=A0=A0 Content-Type: applicati=
on/json
=A0=A0 {
=A0=A0=A0=A0 "schemas&quo=
t;:["urn:scim:schemas:core:2.0:ListResponse"],
=A0=A0=A0=A0 "totalResult=
s":2,
=A0=A0=A0=A0 "Resources&q=
uot;:[
=A0=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0=A0 "=
;userName":"bjensen"
=A0=A0=A0=A0=A0=A0 },
=A0=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0=A0 "=
;userName":"jsmith"
=A0=A0=A0=A0=A0=A0 }
=A0=A0=A0=A0 ]
=A0=A0 }



Then in "3.7 Additional retrieval query parameter", a similar request is described with the difference that the id is specified:

Get /Users/<id>?attributes=3Duser= Name

In the response, the resource returned contains the userName attribute, but also the attributes schemas, id, and meta (with all its sub-attributes):

HTTP/1.1 200 OK
=A0=A0 Content-Type: applicati=
on/json
=A0=A0 Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
=A0=A0 ETag: W/"a330bc54f=
0671c9"
=A0=A0 {
=A0=A0=A0=A0 "schemas&quo=
t;:["urn:scim:schemas:core:2.0:User"],
=A0=A0=A0=A0 "id":&q=
uot;2819c223-7f76-453a-919d-413861904646",
=A0=A0=A0=A0 "userName&qu=
ot;:"bjensen",
=A0=A0=A0=A0 "meta":=
{
=A0=A0=A0=A0=A0=A0 "resou=
rceType": "User",
=A0=A0=A0=A0=A0=A0 "creat=
ed":"2011-08-01T18:29:49.793Z",
=A0=A0=A0=A0=A0=A0 "lastM=
odified":"2011-08-01T18:29:49.793Z",
=A0=A0=A0=A0=A0=A0 "locat=
ion":"https://example.com/v1/Users/2819c223-=
7f76-453a-919d-413861904646",
=A0=A0=A0=A0=A0=A0 "versi=
on":"W\/\"a330bc54f0671c9\""
=A0=A0=A0=A0 }
=A0=A0 }

So it is confusing to understand what to return when query attributes are required:=A0
  1. do we have to have 2 separate processing: one when a list of resources is returned, and one when a single resource is returned
  2. or is it an error in the specification examples.
Phil

@independentid
phil.hunt@oracle.com


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



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

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


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


--047d7b34429e1748bc04e5aac39a-- From t.rossner@tarent.de Fri Sep 6 06:11:27 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139BE21E80FD for ; Fri, 6 Sep 2013 06:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-VrP0S7nBNO for ; Fri, 6 Sep 2013 06:11:23 -0700 (PDT) Received: from ugs.tarent.de (ugs.tarent.de [193.107.123.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5985711E8145 for ; Fri, 6 Sep 2013 06:11:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ugs.tarent.de (Postfix) with ESMTP id 21A8B60612D21 for ; Fri, 6 Sep 2013 15:11:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ugs.tarent.de (Postfix) with ESMTP id F240660612D22 for ; Fri, 6 Sep 2013 15:11:19 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at tarent.de Received: from ugs.tarent.de ([127.0.0.1]) by localhost (ugs.tarent.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7u2HHPYXtuGN for ; Fri, 6 Sep 2013 15:11:19 +0200 (CEST) Received: from [172.26.15.200] (dhcp-172-26-15-200.dynamic.tarent.de [172.26.15.200]) by ugs.tarent.de (Postfix) with ESMTPSA id 4412760612D21 for ; Fri, 6 Sep 2013 15:11:19 +0200 (CEST) Message-ID: <5229D476.2080403@tarent.de> Date: Fri, 06 Sep 2013 15:11:18 +0200 From: =?ISO-8859-1?Q?Thorsten_Ro=DFner?= Organization: tarent AG User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: scim@ietf.org References: <52287B50.8090608@oracle.com> <035C775B-284F-4EED-8301-A93A40F97512@oracle.com> <5228D3FE.7090902@unboundid.com> <299BB16F-7DE8-464B-B99B-B69F446D8839@oracle.com> In-Reply-To: <299BB16F-7DE8-464B-B99B-B69F446D8839@oracle.com> Content-Type: multipart/alternative; boundary="------------080603060200020302060305" Subject: Re: [scim] Query - What should attributes parameter inconsistency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 13:11:27 -0000 This is a multi-part message in MIME format. --------------080603060200020302060305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1 Requested attribute(s) plus mandatory attribute record identifier. I don't think schema is necessary, but would rather see schema in there than missing the record-id. Cheers Thorsten Am 05.09.2013 21:02, schrieb Phil Hunt: > We should discuss meta attributes that are always returned vs. those > that are "operational" (only returned on request). For example, I > doubt a client asking for "username" is interested in any time stamp > values. > > My feeling is that only the requested attributes and the record > identifier should be returned. > > One other consideration is schema -- the client needs enough > information to parse the result. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > On 2013-09-05, at 11:57 AM, Bjorn Aannestad > > > wrote: > >> Only the requested attributes should be returned. Although "meta" >> is arguably a special attribute, it's easy enough for a client to >> include it in the request if they depend on it. >> >> -Bjorn >> >> __________________________________________________________ >> Bjorn Aannestad | Dir, Product Management | UnboundID Corp >> mailto:bjorn@unboundid.com | 512-769-6461 >> >> On 2013-09-05 11:22 AM, Phil Hunt wrote: >>> As an addition, we should specify what should happen when a complex >>> attribute is specified. >>> >>> I believe on the design call yesterday we discussed that the entire >>> complex attribute and all of its values are always returned. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> >>> >>> On 2013-09-05, at 7:03 AM, Phil Hunt >> > wrote: >>> >>>> A colleague of mine has pointed out an inconsistency in the spec >>>> regarding what should be returned when the attributes parameter is >>>> used. I have no opinion other then results should be consistent, >>>> and shouldn't the record identifier always be returned at minimum? >>>> >>>> >>>>> I have a question on the query of SCIM resources. >>>>> In the SCIM specifications (draft-ietf-scim-api-02), in the >>>>> paragraph "3.2.2 List/Query Resources", the following request >>>>> processing is described: >>>>> >>>>> Get /Users?attributes=userName >>>>> >>>>> In the response, 2 resources are returned to the client with for >>>>> each one only the attribute userName: >>>>> >>>>> HTTP/1.1 200 OK >>>>> Content-Type: application/json >>>>> { >>>>> "schemas":["urn:scim:schemas:core:2.0:ListResponse"], >>>>> "totalResults":2, >>>>> "Resources":[ >>>>> { >>>>> "userName":"bjensen" >>>>> }, >>>>> { >>>>> "userName":"jsmith" >>>>> } >>>>> ] >>>>> } >>>>> >>>>> >>>>> >>>>> Then in "3.7 Additional retrieval query parameter", a similar >>>>> request is described with the difference that the id is specified: >>>>> >>>>> Get /Users/?attributes=userName >>>>> >>>>> In the response, the resource returned contains the userName >>>>> attribute, but also the attributes schemas, id, and meta (with all >>>>> its sub-attributes): >>>>> >>>>> HTTP/1.1 200 OK >>>>> Content-Type: application/json >>>>> Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>>>> ETag: W/"a330bc54f0671c9" >>>>> { >>>>> "schemas":["urn:scim:schemas:core:2.0:User"], >>>>> "id":"2819c223-7f76-453a-919d-413861904646", >>>>> "userName":"bjensen", >>>>> "meta":{ >>>>> "resourceType": "User", >>>>> "created":"2011-08-01T18:29:49.793Z", >>>>> "lastModified":"2011-08-01T18:29:49.793Z", >>>>> "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646", >>>>> "version":"W\/\"a330bc54f0671c9\"" >>>>> } >>>>> } >>>>> >>>>> So it is confusing to understand what to return when query >>>>> attributes are required: >>>>> >>>>> 1. do we have to have 2 separate processing: one when a list of >>>>> resources is returned, and one when a single resource is returned >>>>> 2. or is it an error in the specification examples. >>>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>> >>> >>> >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------080603060200020302060305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
+1

Requested attribute(s) plus mandatory attribute record identifier. I don't think schema is necessary, but would rather see schema in there than missing the record-id.

Cheers
Thorsten

Am 05.09.2013 21:02, schrieb Phil Hunt:
We should discuss meta attributes that are always returned vs. those that are "operational" (only returned on request).  For example, I doubt a client asking for "username" is interested in any time stamp values.

My feeling is that only the requested attributes and the record identifier should be returned.

One other consideration is schema -- the client needs enough information to parse the result.


On 2013-09-05, at 11:57 AM, Bjorn Aannestad <bjorn.aannestad@unboundid.com> wrote:

Only the requested attributes should be returned.   Although "meta" is arguably a special attribute, it's easy enough for a client to include it in the request if they depend on it.

-Bjorn

 
__________________________________________________________
Bjorn Aannestad | Dir, Product Management | UnboundID Corp
mailto:bjorn@unboundid.com | 512-769-6461

On 2013-09-05 11:22 AM, Phil Hunt wrote:
As an addition, we should specify what should happen when a complex attribute is specified.

I believe on the design call yesterday we discussed that the entire complex attribute and all of its values are always returned.


On 2013-09-05, at 7:03 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

A colleague of mine has pointed out an inconsistency in the spec regarding what should be returned when the attributes parameter is used. I have no opinion other then results should be consistent, and shouldn't the record identifier always be returned at minimum?


I have a question on the query of SCIM resources. 
In the SCIM specifications (draft-ietf-scim-api-02), in the paragraph "3.2.2 List/Query Resources", the following request processing is described:

Get /Users?attributes=userName

In the response, 2 resources are returned to the client with for each one only the attribute userName:

HTTP/1.1 200 OK
   Content-Type: application/json
   {
     "schemas":["urn:scim:schemas:core:2.0:ListResponse"],
     "totalResults":2,
     "Resources":[
       {
         "userName":"bjensen"
       },
       {
         "userName":"jsmith"
       }
     ]
   }



Then in "3.7 Additional retrieval query parameter", a similar request is described with the difference that the id is specified:

Get /Users/<id>?attributes=userName

In the response, the resource returned contains the userName attribute, but also the attributes schemas, id, and meta (with all its sub-attributes):

HTTP/1.1 200 OK
   Content-Type: application/json
   Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
   ETag: W/"a330bc54f0671c9"
   {
     "schemas":["urn:scim:schemas:core:2.0:User"],
     "id":"2819c223-7f76-453a-919d-413861904646",
     "userName":"bjensen",
     "meta":{
       "resourceType": "User",
       "created":"2011-08-01T18:29:49.793Z",
       "lastModified":"2011-08-01T18:29:49.793Z",
       "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
       "version":"W\/\"a330bc54f0671c9\""
     }
   }

So it is confusing to understand what to return when query attributes are required: 
  1. do we have to have 2 separate processing: one when a list of resources is returned, and one when a single resource is returned
  2. or is it an error in the specification examples.
Phil

@independentid
phil.hunt@oracle.com


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



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

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



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

--------------080603060200020302060305-- From swm16@psu.edu Fri Sep 6 13:47:42 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A467D11E812A for ; Fri, 6 Sep 2013 13:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HknGB7o85fiC for ; Fri, 6 Sep 2013 13:47:38 -0700 (PDT) Received: from tr21g10.aset.psu.edu (tr21g10.aset.psu.edu [146.186.149.132]) by ietfa.amsl.com (Postfix) with ESMTP id E6BD211E80F4 for ; Fri, 6 Sep 2013 13:47:36 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr21g10.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r86KlYs73772648 for ; Fri, 6 Sep 2013 16:47:35 -0400 Date: Fri, 6 Sep 2013 16:47:34 -0400 (EDT) From: "Steven W. Moyer" To: scim@ietf.org Message-ID: <179870374.1368372.1378500454512.JavaMail.zimbra@psu.edu> In-Reply-To: <1484660120.1326939.1378499845488.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.118.58.157] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF22 (Mac)/8.0.4_GA_5737) Thread-Topic: Minor clean-up for the Schema document - DateTime Thread-Index: OsciUk6Q3Qq4Y+oNBURAisz3q0mk3A== X-Virus-Scanned: by amavisd-new Subject: [scim] Minor clean-up for the Schema document - DateTime X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Steven W. Moyer" List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 20:47:42 -0000 Section 3.1.5. (Headed: DateTime) of the SCIM v2 Schema refers to section 3.2.7 which no longer exists and to the (XML Schema Datatypes Specification) which is no longer supported. I'd suggest we refer to the relevant standards in this paragraph and link to RFC3339 - section 5.6 (http://tools.ietf.org/html/rfc3339#section-5.6), ISO-8601 (http://www.iso.org/iso/catalogue_detail?csnumber=40874) and if humor is tolerated, to Randall Munroe's opinion (https://xkcd.com/1179/). Have a great weekend! Steve From moransar@cisco.com Mon Sep 9 00:11:15 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACF721E80AD for ; Mon, 9 Sep 2013 00:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah-vXJtbP+2b for ; Mon, 9 Sep 2013 00:11:03 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F05A021E8143 for ; Mon, 9 Sep 2013 00:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=111385; q=dns/txt; s=iport; t=1378710662; x=1379920262; h=from:to:subject:date:message-id:mime-version; bh=DMUAWOfs4zUNUPDMxFOKEP8mhy46jcMhVm5hqW2iTrU=; b=MCvooPDforXqcxql72T+GI3BDvyk0a2R8D9R3pfjlHNiU5/ltdVF2Bfr x+43nSdtm0DpWmjatefBCqjiu6Gvr4k7JWjOWR2YAWZ6H5O39wqMafuVi +ybeWCQ9B7wf/gYFsHnR5kKGG9muy0GCrl6830SuZkgTKJsfEupIspP9T E=; X-Files: scim-2013-09-04.ppt : 79872 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFABt0LVKtJXG+/2dsb2JhbABagkNEgQnCFIEcFm0HghwLAQRFRgELAR4mMCcEGwaHdKUxoAWPT4NVgQADkCOZOIMggio X-IronPort-AV: E=Sophos;i="4.90,866,1371081600"; d="ppt'32?scan'32,208,217,32";a="257200001" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 09 Sep 2013 07:10:21 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r897AKLh001346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Sep 2013 07:10:20 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.27]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 02:10:20 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: Next SCIM WG call agenda - Sep. 18th @11AM Pacific Thread-Index: AQHOrSukO3iNsV3+wUSd5c/l6JpgzQ== Date: Mon, 9 Sep 2013 07:10:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.79.231] Content-Type: multipart/mixed; boundary="_004_CA3B67220D628A4780D6FEB31F18A3E32ABCED20xmbrcdx08ciscoc_" MIME-Version: 1.0 Subject: [scim] Next SCIM WG call agenda - Sep. 18th @11AM Pacific X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 07:11:15 -0000 --_004_CA3B67220D628A4780D6FEB31F18A3E32ABCED20xmbrcdx08ciscoc_ Content-Type: multipart/alternative; boundary="_000_CA3B67220D628A4780D6FEB31F18A3E32ABCED20xmbrcdx08ciscoc_" --_000_CA3B67220D628A4780D6FEB31F18A3E32ABCED20xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, Just a reminder that the next SCIM WG call is scheduled for Sep. 18th at 11= AM Pacific time. The agenda for that meeting is to continue going through = the backlog of the issues from tracker. See the attached slides. Cheers, Morteza --_000_CA3B67220D628A4780D6FEB31F18A3E32ABCED20xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <7D13D8C10E743B4688003779C836405D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi folks,

Just a reminder that the next SCIM WG call is scheduled for Sep. 18th = at 11AM Pacific time.  The agenda for that meeting is to continue goin= g through the backlog of the issues from tracker. See the attached slides.<= /div>


Cheers,
Morteza
--_000_CA3B67220D628A4780D6FEB31F18A3E32ABCED20xmbrcdx08ciscoc_-- --_004_CA3B67220D628A4780D6FEB31F18A3E32ABCED20xmbrcdx08ciscoc_ Content-Type: application/vnd.ms-powerpoint; name="scim-2013-09-04.ppt" Content-Description: scim-2013-09-04.ppt Content-Disposition: attachment; filename="scim-2013-09-04.ppt"; size=79872; creation-date="Mon, 09 Sep 2013 07:10:19 GMT"; modification-date="Mon, 09 Sep 2013 07:10:19 GMT" Content-ID: <771D09BFE912D74F8980899EBB560351@emea.cisco.com> Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAAQAAAAAAAAAA EAAAmQAAAAEAAAD+////AAAAAAAAAAARAAAAEgAAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////mAAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEwAAAP3////9////FAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgA AABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAA AFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAA ZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABz AAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAH4AAAB/AAAAgAAAAFIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAACAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAJy0jBiBqc4B mgAAAIAAAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAA9v8AAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIQAAAAoFQAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjwAAACQRAAAAAAAADwDo A+8jAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAABAAAAAgAAAAAAAAAAAAAAAQAAAAAAAAEPAAkE jBYAAAAACgQEAAAARgAAAA8A1w8YAQAAAADTDwQAAAAWAAAAAAC6D34AAABoAHQAdABwADoALwAv AHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUA YgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0AbAAQ ALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0A YQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAw ADAAOQAyADkALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAYAAAAAAC6D34AAABoAHQAdABwADoA LwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3 AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0A bAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBs AC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMA ZwAwADAAOQAyADkALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAaAAAAAAC6D34AAABoAHQAdABw ADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUA LwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0 AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEA aQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBt AHMAZwAwADAAOQAyADkALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAcAAAAAAC6D34AAABoAHQA dABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2 AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4A aAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBt AGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQA LwBtAHMAZwAwADAAOQAyADkALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAeAAAAAAC6D34AAABo AHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgA aQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5 AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcA LwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBu AHQALwBtAHMAZwAwADAAOQAyADkALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAgAAAAAAC6D34A AABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBj AGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAxADAA MgA3AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwBy AGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIA ZQBuAHQALwBtAHMAZwAwADEAMAAyADcALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAiAAAAAAC6 D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEA cgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAx ADAAMgA3AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4A bwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQBy AHIAZQBuAHQALwBtAHMAZwAwADEAMAAyADcALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAkAAAA AAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAt AGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcA MAAxADAAMgA3AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABm AC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMA dQByAHIAZQBuAHQALwBtAHMAZwAwADEAMAAyADcALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAAAm AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkA bAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBz AGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUA dABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAv AGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADEAMAAyADcALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQA AAAoAAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBh AGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8A bQBzAGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBp AGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkA bQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADEAMAAyADcALgBoAHQAbQBsAA8A1w8YAQAAAADT DwQAAAA0AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8A bQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0 AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcA LgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBj AGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADAAOQAyADkALgBoAHQAbQBsAA8A1w8YAQAA AADTDwQAAAA2AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBn AC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgByAGUA bgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3 AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8A cwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADAAOQAyADkALgBoAHQAbQBsAA8A1w8Y AQAAAADTDwQAAAA4AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8A cgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUAcgBy AGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAvAC8A dwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBi AC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADAAOQAyADkALgBoAHQAbQBsAA8A 1w8YAQAAAADTDwQAAAA6AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAu AG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBjAHUA cgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAAOgAv AC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcA ZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADAAOQAyADkALgBoAHQAbQBs AA8A1w8YAQAAAADTDwQAAAA8AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQA ZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0ALwBj AHUAcgByAGUAbgB0AC8AbQBzAGcAMAAwADkAMgA5AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0AHAA OgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAv AHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADAAOQAyADkALgBoAHQA bQBsAA8A1w8YAQAAAADTDwQAAAA+AAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBl AHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBpAG0A LwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQALoPfgAAAGgAdAB0 AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYA ZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADEAMAAyADcALgBo AHQAbQBsAA8A1w8YAQAAAADTDwQAAABAAAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3AC4A aQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMAYwBp AG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQALoPfgAAAGgA dAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABp AHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADEAMAAyADcA LgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAABCAAAAAAC6D34AAABoAHQAdABwADoALwAvAHcAdwB3 AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAvAHMA YwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQALoPfgAA AGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMA aABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADEAMAAy ADcALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAABEAAAAAAC6D34AAABoAHQAdABwADoALwAvAHcA dwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUAYgAv AHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQALoP fgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQBy AGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADEA MAAyADcALgBoAHQAbQBsAA8A1w8YAQAAAADTDwQAAABGAAAAAAC6D34AAABoAHQAdABwADoALwAv AHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUALwB3AGUA YgAvAHMAYwBpAG0ALwBjAHUAcgByAGUAbgB0AC8AbQBzAGcAMAAxADAAMgA3AC4AaAB0AG0AbAAQ ALoPfgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0A YQByAGMAaABpAHYAZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAw ADEAMAAyADcALgBoAHQAbQBsAA8A8gOuAQAALwDIDwwAAAAwANIPBAAAAAEAAAAPANUH5AAAAAAA tw9EAAAAQwBhAGwAaQBiAHIAaQAAAP39/f39/f39/f39/f39/f0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAKwQALcPRAAAAC3/M/8gADD/tDC3MMMwrzAAAP39/f39/f39/f39/f39 /f0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACsIAC3D0QAAABBAHIAaQBhAGwAAAD9 /f39/f39/f39/f39/f39AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArAAA pA8IAAAAgABAAAAAAAAAAKUPDgAAAAAAAIguAAAAQAIHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACj D24AAAAFAP/9PwAAACIgAgBkAAAAAAAAAGQAAAAAAAAAAAAgAQAAAAAHAAAA///vAAAAAAABAAAA //8SAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAA AA8ACwTMAAAADwAA8MQAAAAAAAbweAAAAAM0AAAOAAAAKgAAAA0AAAABAAAABwAAAAIAAAADAAAA AwAAAAMAAAAEAAAAAwAAAAUAAAADAAAABgAAAAMAAAAHAAAAAwAAAAgAAAADAAAACQAAAAMAAAAK AAAAAwAAAAsAAAADAAAADAAAAAMAAAANAAAAAwAAAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAA wAEBAAAI/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAA AAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQByQBAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAA ZAAAAKfYYAC4NPm/cCD5vwgAAABAzr55TmBLAAAAAAAAAAAAAAEAAA8A+gNnAAAAAAD+AwMAAAAA AAEAAP0DNAAAAHwAAABkAAAAfAAAAGQAAABYBtWGCAAAAAgAAAAoIPm/AwAAAJs++b/g+v//oP// /wEAZoRwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAA8AiBNpAAAADwCKEykAAAAAALoP EAAAAF8AXwBfAFAAUABUADEAMgAAAIsTCQAAAAAAJQQBAAAAAA8AihMwAAAAAAC6DxAAAABfAF8A XwBQAFAAVAAxADAAAACLExAAAAAAAA0ECAAAAADAAAAAwAAAPwDZDwwAAAAAANoPBAAAAA0AAgBP ANkPDAAAAAAA2g8EAAAAAAACAA8A8A9QAQAAAADzAxQAAAADAAAABAAAAAAAAAAAAQAAAAAAAAAA 8wMUAAAABAAAAAQAAAAAAAAAAQEAAAAAAAAAAPMDFAAAAAUAAAAEAAAAAAAAAAIBAAAAAAAAAADz AxQAAAAGAAAABAAAAAAAAAADAQAAAAAAAAAA8wMUAAAABwAAAAQAAAAAAAAABAEAAAAAAAAAAPMD FAAAAAgAAAAEAAAAAAAAAAUBAAAAAAAAAADzAxQAAAAJAAAABAAAAAAAAAAGAQAAAAAAAAAA8wMU AAAACgAAAAQAAAAAAAAABwEAAAAAAAAAAPMDFAAAAAsAAAAEAAAAAAAAAAgBAAAAAAAAAADzAxQA AAAMAAAABAAAAAAAAAAJAQAAAAAAAAAA8wMUAAAADQAAAAQAAAAAAAAACgEAAAAAAAAAAPMDFAAA AA4AAAAEAAAAAAAAAAsBAAAAAAAAAAAoBMEHAABQSwMEFAAGAAgAAAAhAJ3GccL2AAAAqQEAABMA CAJbQ29udGVudF9UeXBlc10ueG1sIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgQAAAIIAAACDAAAA/v///4UA AACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAAD+////kAAAAJEAAACSAAAAkwAA AJQAAACVAAAAlgAAAJcAAAD+/////v////7////+//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8kM1qwzAQhO+FvoPQtVhyeyilxM6hP8e20PQBtvLa FtEf2k2I376yk0IpIadFu5qZj1mtD96JPWayMTTyVtVSYDCxs2Fo5NfmtXqQghhCBy4GbOSEJNft 9dVqMyUkUdSBGjkyp0etyYzogVRMGMqlj9kDl2cedAKzhQH1XV3faxMDY+CKZw/Zrp6xh51j8XIo 6yNJkUvxdPw3RzUSUnLWABdQPV/1WV1GRxeE+9D9o6tOZKooF3MabaKbU8J7qSbbDsUHZH4DXzg0 w7fDT54ckrqMeSYt9r012EWz86UBlTJSmUuwd+qP9S+BXopufwAAAP//AwBQSwMEFAAGAAgAAAAh AO3kDEu7AAAAJgEAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEj80KwjAQhO+C7xD2blM9iEjTXkTw qvUB1nT7g2kSklXs25tjC4LH2WG+2Smqz2jEm0IcnFWwzXIQZLVrBtspuNfnzQFEZLQNGmdJwUQR qnK9Kq5kkFMo9oOPIlFsVNAz+6OUUfc0YsycJ5uc1oUROcnQSY/6iR3JXZ7vZZgzoFwwxaVREC7N FkQ9+dT8n+3adtB0cvo1kuUfFZLxYejGk0krRI2hI1YwO2bpW5BlIRfryi8AAAD//wMAUEsDBBQA BgAIAAAAIQDY/Y2PrAAAALYAAAAPAAAAdGFibGVTdHlsZXMueG1sDMxJDoIwGEDhvYl3aP59LUNR JBTCICt36gEqlCHpQGijEuPdZfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97g2NA1nHdcWm0YLAK C3m236U8cU95c6sUV+vQpmibcAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h705UkgecdieKTBtSJ nsE3qoIgorTAp8vliGlIA1x6NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAQItABQABgAIAAAAIQCd xnHC9gAAAKkBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG AAgAAAAhAO3kDEu7AAAAJgEAAAsAAAAAAAAAAAAAAAAALwMAAF9yZWxzLy5yZWxzUEsBAi0AFAAG AAgAAAAhANj9jY+sAAAAtgAAAA8AAAAAAAAAAAAAAAAAGwYAAHRhYmxlU3R5bGVzLnhtbFBLBQYA AAAAAwADALcAAAD0BgAAAAAAAOoDAAAAAA8A+ANNfwAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAA AAAAAAIA+b9gAPAHIAAAAP///wAAAAAA7uzhAB9JfQBPgb0AwFBNAAAA/wCAAIAAAACjDz4AAAAB AP/9PwAAACIgAgBkAAAAAAABAGQAAAAAAAAAAAAgAQAAAAAHAAAA///vAAAAAAABAAAA//8sAAAA AAEAABAAow98AAAABQD//T8AAwAiIAIAZAAAAAAAAABkABQAAADYAAAAIAEAAAAABwAAAP//7wAA AAAAAQAAAP//IAAAAAABAACABQAAEyDUASABAAACABwAgAUAACIg0AJAAgAAAgAYAIAFAAATIPAD YAMAAAIAFACABQAAuwAQBYAEAAAAACAAow9uAAAABQD//T8AAAAiIAIAZAAAAAAAAABkAB4AAAAA AAAAIAEAAAAABwAAAP//7wAAAAAAAQAAAP//DAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAA AAAABQAAYANgAwAAAAAABQAAgASABAAAAABAAKMPbgAAAAUA//0/AAAAIiACAGQAAAAAAAAAZAAA AAAAAAAAACABAAAAAAcAAAD//+8AAAAAAAEAAAD//xIAAAAAAQAAAAUAACABIAEAAAAAAAUAAEAC QAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAIAAQAAAAAAAAAB AAEJAAACAAEAIAEAAAAAAgABCQAAAgABAEACAAAAAAMAAQkAAAIAAQBgAwAAAAAEAAEJAAACAAEA gAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABwAAQAAAAAAAAAC ABgAAgAAAAAAAAACABQAAwAAAAAAAAACABIABAAAAAAAAAACABIAgACjDz4AAAAFAAAAAAAAAAAA AgAYAAEAAAAAAAAAAgAUAAIAAAAAAAAAAgASAAMAAAAAAAAAAgAQAAQAAAAAAAAAAgAQAAAAIwRT BgAAUEsDBBQABgAIAAAAIQCbEwW7+gAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy2rD MBBF94X+g9C2WHK6KKXYzqKPXR+L9AMGeWyL6oVGCcnfd+ykEErIapjHnXu4zXrvndhhJhtDK1eq lgKDib0NYyu/N2/VoxRUIPTgYsBWHpDkuru9aTaHhCRYHaiVUynpSWsyE3ogFRMG3gwxeyjc5lEn MD8wor6v6wdtYigYSlXmH7JrXnCArSvidc/jIwnLpXg+3s1WrYSUnDVQGFTPW31Rl9HRFeEu9P/o qhOZYuXynCab6O7k8MnRZNuj+IJcPsAzh+4zaXI8fAcqnNx5s1LXwS/4x2GwBvtotp4zUSkjcV1Q vFNnRn9Meom++wUAAP//AwBQSwMEFAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsAAABfcmVscy8ucmVs c4SPwQrCMBBE74L/EPZu03oQkaa9iNCDF9EPWJJtG2yTkI2if2+OFgSPwzBvZur2NU/iSZGtdwqq ogRBTntj3aDgdj1t9iA4oTM4eUcK3sTQNutVfaEJUw7xaAOLTHGsYEwpHKRkPdKMXPhALju9jzOm LOMgA+o7DiS3ZbmT8ZsBzYIpOqMgdqYCcX2H3Pyf7fveajp6/ZjJpR8Vkidr6IycKGYsxoGSAhP5 21iIqsj7QTa1XPxtPgAAAP//AwBQSwMEFAAGAAgAAAAhAI+8DdIjAwAAHBsAACEAAABkcnMvc2xp ZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsmUtu2zAQhvcFegeB28KxJT8kC5aDJkVWQWHUyQFo mbbVUJRA0WncVe/QG/Qa3fUoPUlnSDpWYivIwgKiwhvDIqUROd9wOD81On9IuXPPZJFkIiLuWYc4 TMTZPBHLiNzeXLUC4hSKijnlmWAR2bCCnI/fvxvloXqYqg1nhQMmRBHSiKyUysN2u4hXLKXFWZYz AX2LTKZUwaVctueSfgPTKW97nc6gndJEEPu8fM3z2WKRxOxTFq9TJpQxIhmnCoZfrJK82FrLX2Mt l6wAM/rpJ0Ma4/QSxZme4XhEQ37P3XwiHcqX4KdYSeLM2eKGzqbfI9Lr+zAd4kjFI4IepNfiQt6B P4mDYxP2ErpWVCzBAZO1iBX2o+0ijy/Ywv6bxMq5p9pOezxql3tn68/AAFppCO/+AqMp8OU9fPUd k8gPh6ENZTyZXyWc6wvkwS65NIbVg0us6fJdeqCO2uRsQWMg/SH92uIK76Qho886GDUdcfGsIy6s bTNCPQPrO/j/1Kt5OMvmmz0Xp1ReR6Tb84Y4sUTMAVFEWtsGQ4DX7n9wJbx/n8FVJlRp0h9lQrlx xmx9uaLSieEnIn9//DKtJVRdHSV1oBJVqESrApVovYhKR7yHEW9w+ICjX8bhBX0fGxqD4+ceDi+o a+UcEQcywCUIi6i7w+G6vS6G5255eF4wwIbG8NhfHl5tmeyIPBCC5dEr8QDf68X9mK4ax+PA+tAR 9sbTFUKwPPo7Hl6n7+toaiqPP7/301UTcCADi2NQwtF3ezo7NRXHod0cC4R6Cq8jpiuEYHn4JR5D 39Wb34mHqbFfLoSPyAMhWB7Bjoepbf+37bwJ6wMhWB7DEo8gGDR8Oz9QXjWBB0LQQrEkDfMwUysm H4UiKKqJoWa1FQdRHREmWrdT3DVBNO9u2Qp3I2NqKZBLCs9k1TdeMuFBho35ksLbHmIcX0A0zT+H JdfQNSctJ/9USKCu79akQJsWQIc1iRt4gS66ThFUoRL0EcYpRcOWVVG2+z1zhHiKoIo6Goo2LftP DqoobAd9/5Sk9WnqY6VZLi7xC4X9rDX+BwAA//8DAFBLAQItABQABgAIAAAAIQCbEwW7+gAAALsB AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAI7q Kvq+AAAAOAEAAAsAAAAAAAAAAAAAAAAAKwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAI+8 DdIjAwAAHBsAACEAAAAAAAAAAAAAAAAAEgIAAGRycy9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIx LnhtbFBLBQYAAAAAAwADAMkAAAB0BQAAAAAPAAwEuCIAAA8AAvCwIgAAEAAI8AgAAAAGAAAABgQA AA8AA/AkHQAADwAE8CgAAAABAAnwEAAAACgmTqwAAAAAAAAAABAqAQACAArwCAAAAAAEAAAFAAAA DwAE8PoAAAASAArwCAAAAAIEAAAACgAAkwAL8F4AAAB/AAEA7wGAALhPwoSHAAEAAAC/AAAABgC/ AQEAEQD/AREAGQA/AwAACACAwygAAAC/AwAAAgBUAGkAdABsAGUAIABQAGwAYQBjAGUAaABvAGwA ZABlAHIAIAAxAAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAAAQD5vw8ADfBU AAAAAACfDwQAAAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAA og8GAAAAIQAAAAAAAACqDwoAAAAhAAAAAQAAAAAADwAE8DwBAAASAArwCAAAAAMEAAAACgAAgwAL 8FYAAAB/AAEA7wGAAMglZoS/AAAABgC/AQEAEQD/AREAGQA/AwAACACAwyYAAAC/AwAAAgBUAGUA eAB0ACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAA AAAAwwsIAAAAAQAAAAIA+b8PAA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRp dCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZl bA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoA AABTAAAAAQAAAAAADwAE8PgIAAASAArwCAAAAAQEAAAACgAAkwAL8FwAAAB/AAEA7wGAAFiBZYSH AAEAAAC/AAAABgC/AQEAEQD/AREAGQA/AwAACACAwyYAAAC/AwAAAgBEAGEAdABlACAAUABsAGEA YwBlAGgAbwBsAGQAZQByACAAMwAAABMAIvHkBwAAqcPeBwAAUEsDBBQABgAIAAAAIQAyPL0++wAA AOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7 klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9 bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO6 38r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0zi YVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQA BgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC 1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocT RzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFU B2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L 8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQCzq2l2egMAAIcKAAAQAAAAZHJzL3NoYXBl eG1sLnhtbOxVTW/jNhC9F+h/IHgtvJbijzRC5EWSxtsCxsJYZ8+LMUXFqilSIGnXTtH/3kdSjrN7 KBabPRRFAUOmNEPOmzczj9dvD61ie2ldY3TJ8zcZZ1ILUzX6seQfH+aDnzlznnRFymhZ8qN0/O3s xx+uu8J1DJu1K7qSb7zviuHQiY1syb0xndSw1ca25PFqH4edlU5qTx6BWjW8yLLpsKVG8xmO0vtV t7RhJd7vl5Y1VcnHnGlqEfIX8pItFQm5MaqSlo34sHdNuwhQFkZsXY+HvgZPZekPJPkZFKbNO4ts 8hBgGMGccGnACkG7DfPHDqgqD2KeEIlUzQH4UPKLflvyxf5zWi6mR8Whtu1rUc6uqTB1zRBxPLkE kZwdSz4dTfDLAgQq5MEzERDlo9E0OAh4jKaT/GISMSYgwbOzzr+T5tWgWDio5FYKj4pSQfuF84HF c4hIaSKiK/zh1lTH4LnGP0qeWunbS4ceRvyNsU+cqd+0K/lVPh4jdR9fIlOc2ZeW9WcWr+6MKjl2 kBY4p+TC20Sncn7lj0q+FmRIV+1VjmZgpB4xcCqSVcn6Az6FdspDPYOfM6qp5o1S8SXMlbxTlu0J GP0hjz6+0T59uZxk2Jf4jkMYnCP7L85BLVKkaOiBpHWfYIh1mupvLkU8BOm0ZBeRTyw+xAVCxv9G V5CCxHVPAwOyB1qvQMGpqa1P3pIW+tZuw1iy2mh/E7fQzhtUGnqiezMqtyH9iKFe7rTA8YkkpVed iCR2Yil6vnLQ9UzYS49bWZ98vUvcPvPaibP1pvb/4Ndb1ztU4eEQR3K9Wz09L+dI4/nlPYQ1unha p6E51amfn6A8VNSqirr4Z3ZzcXk/vpoPxtndfDCZjiHSV/ejQXY5zabTPLvP8vu/0PdRpjZ1kM+H ppWxYyzqst21TWt+b1JJwFjJpR58XCU9iw3I1qlO8bkruQbEcA/YZgvp02YVV5xtpQ23RtQgQVDO 3rETcacO+q+aJ/lrfF2Tk6oJtwhKpc3SGlPHtWv9nZKEo1LvKx0S1ia0f+IgfXnRyxiQ7zIT0Mq6 hmidiN8tdF+YXYjer2ObRUZrXEMl/6nVA+V7raUvDJKSQbgvDML1E4oqhASDDPw/JN91SPzsU7hy MJt4YmICzVJXS7IUFPZf1/oB33+928/8x6p0eJ7vfyxdN/sbAAD//wMAUEsDBBQABgAIAAAAIQBZ eKsk1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/BSgMxFEX3gv8QnuDOZhQtOjYtRSjqwsXU gu3uzeR1MnTyMiTpNP17gwu7vNzLuZzZItlejORD51jB/aQAQdw43XGrYPO9unsGESKyxt4xKThT gMX8+mqGpXYnrmhcx1ZkCIcSFZgYh1LK0BiyGCZuIM7d3nmLMUffSu3xlOG2lw9FMZUWO84PBgd6 M9Qc1kerYOufpnW9Waaqxuqw+ypWx2R6pW5v0vIVRKQUL+PPl58xxf/yD/WhFTyC2L+fa9/pCkMk ryC7ZdNsCXL+CwAA//8DAFBLAQItABQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAA AAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAA AAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhALOraXZ6AwAAhwoAABAAAAAA AAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAWXirJNYAAAD5AAAA DwAAAAAAAAAAAAAAAADQBQAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAANMGAAAAAAAA EPAIAAAApA8gAWAGihAPABHwEAAAAAAAwwsIAAAAAgAAAAcB+b8PAA3waAAAAAAAnw8EAAAABAAA AAAAoA8CAAAAKgAAAKEPGAAAAAIAAAAAAAAAAAACAAAAAAAGAAwAiYmJ/gAA+A8EAAAAAAAAAAAA qg8KAAAAAgAAAAEAAAAAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8IgIAAASAArwCAAAAAUEAAAA CgAAkwAL8GAAAAB/AAEA7wGAAGiWYISHAAEAAAC/AAAABgC/AQEAEQD/AREAGQA/AwAACACAwyoA AAC/AwAAAgBGAG8AbwB0AGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADQAAAATACLxhAcA AKnDfgcAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyU kUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1dhrVjIl9 oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwRSSZdSBNk OabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5lUs48glw JvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L91e4C5+U cP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAACwAAAF9yZWxz Ly5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BBv9D3Ce32 lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCWkrZaix0p oDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz33j6iahkx 0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQUAAYACAAA ACEAt9/snBoDAABZBwAAEAAAAGRycy9zaGFwZXhtbC54bWysVW1P2zAQ/j5p/8Hy1wnalJaXiBQB EmxShSoKP+DqOG1W5+zZTtfy63e20xb4ME0wKUrOvrPvuedecnm1aRRbS+tqjQXPjvucSRS6rHFR 8Oenu6NzzpwHLEFplAXfSsevxl+/XJrcGUaH0eWm4EvvTd7rObGUDbhjbSSSrtK2AU9Lu+gZK51E D54cNao36PdPew3UyMd0Fa5nZmqDJB7WU8vqsuAjzhAacnmntZeWTRUIudSqJHnIe51xOgcEZqLF ynWI4F8QlRZ+U5hvwDDU95biyYKDXoSzQ4YELDg1S+a3hnBV3hI3LwX/1YIlhJxgbwp+0h1N9nTH ITgXg4R8U9nms0jHl5DrqmLBYzYYEp+cbQt+ejKipx8wQC43ngkyGJxfjE6DgSCLk9NRNhhFkAlJ sDTW+XupP42KhYsKbqXwlFjIYT1xPlB5cBF5TUyY3G9udLkNlnP6UuZTRX08f1TK5H+p7Qtn6ge6 gl9kwyGF7uNiODob0MK+1szfaLy61argZAQo6J6CC8pzpFM5P/NbJT8LMoSr1iqjamCgFtR3wUXY LWX1SJuhqLKQ0bDntKrLu1qpuAgNJm+VZWsglH6TRRtfo087Z6M+nUuMx24MxpH/V/dQNpKnqOig JLkLMfjatfeHkxEvoXAasJPIKAmPUSCX8VtjSTMhsb0nghG2J5jPiISYrpAvn+wlTPDGrkJ/skqj v46HoPWask2jBTs1HVkCLqi7py0KcpBoUjgzItJoxFR0jGVE2J6y1xY3strZepfY3TNrxEF7Xfm/ 2HXaeUt5eNrEOpq3s5e9eEdh7BcPNGOjiYd5apxdplJGu/khsZyChVAqq7apG/2zTrRSzAWXePQ8 S5MpFhGbJ67juy04kpMw1G29oimGehYlzlbShl9AnCQCaAh2hkbEkxiGuapf5Pe4nIOTqg6/BCIb 9dRqXQU5UKEwvFGHqk3A086rEqS6/i+lTEOuqmja7NhqJ9ix2QbvnRxrI47tin4iBf/W4JHy3ZCE dwoJSSHcO4VwXWMd+I9NY+h9GGUkOjP+AwAA//8DAFBLAwQUAAYACAAAACEA/1qZ0dYAAAD5AAAA DwAAAGRycy9kb3ducmV2LnhtbESPsW7CMBRF90r9B+tV6lYcWoFQwCAERe3SIZQBtpf4EVvEdmQb cP6+Vod2vLpX5+osVsl07EY+aGcFjEcFMLKNk9q2Ag7fu5cZsBDRSuycJQEDBVgtHx8WWEp3txXd 9rFlGWJDiQJUjH3JeWgUGQwj15PN3dl5gzFH33Lp8Z7hpuOvRTHlBrXNDwp72ihqLvurEXD0k2ld H9apqrG6nL6K3TWpTojnp7SeA4uU4v94q2fvb8Nf+Yv6lAImwM4fQ+21rDBE8gKyWzbNlsCXPwAA AP//AwBQSwECLQAUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwB AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQC33+ycGgMAAFkHAAAQAAAAAAAAAAAAAAAAACgC AABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAP9amdHWAAAA+QAAAA8AAAAAAAAAAAAA AAAAcAUAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAABzBgAAAAAAABDwCAAAAKQPsAfQ DooQDwAR8BAAAAAAAMMLCAAAAAMAAAAJAvm/DwAN8FQAAAAAAJ8PBAAAAAQAAAAAAKEPGgAAAAEA AAAAAAAIAAABAAEAAAAAAAYADACJiYn+AACqDwoAAAABAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQ AvADEAUPAATwFgkAABIACvAIAAAABgQAAAAKAACTAAvwbAAAAH8AAQDvAYAAqKJIhYcAAQAAAL8A AAAGAL8BAQARAP8BEQAZAD8DAAAIAIDDNgAAAL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIAZQBy ACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAANQAAABMAIvHwBwAAqcPqBwAAUEsDBBQABgAIAAAA IQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJN uiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVac gRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQl QzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0 yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD/ /wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo 7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz 9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSm bd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+b N0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQBhJyUVhgMAAJUKAAAQAAAA ZHJzL3NoYXBleG1sLnhtbOxVXW/bNhR9H7D/QPB1cG3ZltIKkYs4WboBRmDU6fNAUVSsmiJVkvLs DPvvOyTlOO3DUDR9KIYBgnSpe8l77rkfvHx7aCXZC2MbrQqavJpQIhTXVaMeCvrh/nb0mhLrmKqY 1EoU9Cgsfbv4+afLLrcdwWZl866gW+e6fDy2fCtaZl/pTijoam1a5rA0D+POCCuUYw6OWjmeTibZ uGWNogscpfabbm28xO/2a0OaqqAZJYq1cLmRTSXIXd+WwpC1ZFxstawgp3Q8bIm7GSCtNN/ZARf7 GlyVYX8i2M8gEaXfGUSVeAfjAOqETwGed9ptiTt2QGdlBWgg6bGgn3pmnDAU+A8FnQ+74xYcc47S hmhZfqhN+1Kwi0uW67om8Jil6QzEUnKEPEvxTDwGlouDIxwG02Q2y7wBh8UsS5Np4HAckXjLzlj3 TugXoyL+oIIawR0yzHK2X1nn2Ty7CNRGJrrcHZa6OnrLEl+UQCytb08hahr+t9o8UiJ/V7agb5L5 HKG7sJinF1MszHNN+ZnGyWstCwojpjjOKSh3JtIprdu4oxQvBenDlXuZoBoIkw9oQBPIqkT9Hr98 SSU+n97OarTBbSNlWPg+E9fSkD0DRndIgo1rlIt/LtIJ9kW+Q1N648D+s3OQi+gpKAYgUR4C9L5O Xf7NqQiHIJyWmVXgE8L7IMBl+DaqwmiIXA80ECC7Z+UGFIRU+Vy5aC3YSi3NzrcnqbVyV2EL651G pjFf1KDGli1TD2juda84jo8kSbXpeCCx42s+8JWArifCnlssRX2ydTZy+8Rrx8/aq9r9i92gLXtk 4f4QWrLsN49P4i3CeFrcYdAGE8fK2DSnPA394ycQy2tZhTn5102aTpY302yUTLPZKHkzn4yWy+xi lKavb369Wl5cp9nt36j7YVxhmCoMLH+EQVZ2fdu0+mMTEwK+CirU6MMmTrRQfqSMWQrvvqAKAP2t YJodBqDSmyBRshPG3yFhAnGG+TkYdjzsVP42kM2j+C0sS2aFbPydgkQpvTZa10G2rbuWguGoWPlS eaxK++KPDMQ/zyoZ7fFdOgKTsq4xsk609ys1pKX33gc5FFngs8ZlVNBfWjWSbpi07AuFYFHB7RcK bof+RBZ8gH4I/N8i37VF3OIPf+GgM/FGv3iaharWzDA/X3+40vf4/uvVfuY/ZKXD+3z7Q7Td4h8A AAD//wMAUEsDBBQABgAIAAAAIQBWHigD1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/BSgMx FEX3gv8QnuDOZlQcZGxailDUhcLULnT3ZvI6GTp5GZNMm/69wYVdXu7lXM58mewgDuRD71jB7awA Qdw63XOnYPu5vnkEESKyxsExKThRgOXi8mKOlXZHrumwiZ3IEA4VKjAxjpWUoTVkMczcSJy7nfMW Y46+k9rjMcPtIO+KopQWe84PBkd6NtTuN5NV8OUfyqbZrlLdYL3/fi/WUzKDUtdXafUEIlKK5zFN bz/3H//lH+pVKyhB7F5Oje91jSGSV5Ddsmm2BLn4BQAA//8DAFBLAQItABQABgAIAAAAIQAyPL0+ +wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhAGEnJRWGAwAAlQoAABAAAAAAAAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAU AAYACAAAACEAVh4oA9YAAAD5AAAADwAAAAAAAAAAAAAAAADcBQAAZHJzL2Rvd25yZXYueG1sUEsF BgAAAAAEAAQA9QAAAN8GAAAAAAAAEPAIAAAApA8gEGAVihAPABHwEAAAAAAAwwsIAAAABAAAAAgC +b8PAA3wagAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPGgAAAAIAAAAAAAAIAAACAAIAAAAA AAYADACJiYn+AADYDwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvAD EAUPAATwbAUAABIACvAIAAAAAQQAAAAMAABjAAvwJAAAAIEBAAAACIMBBQAACL8BEAAQAP8BAAAI AAQDCQAAAD8DAQABABMAIvEoBQAAqcMiBQAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAA W0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7 Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZC E9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4O e0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3y tOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCq i10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzO lrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997La HWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1Oma qvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUb uxsAAAD//wMAUEsDBBQABgAIAAAAIQBrS7SjvgAAABEBAAAQAAAAZHJzL3NoYXBleG1sLnhtbIyP TW4CMQxG90i9Q+R9SaYLhEaTYYHEAar2AJ6JCSMSJ0oCnd6e8CMkduxsf9J7/rrN7J04U8pTYA3N UoEgHoOZ2Gr4/dl9rkHkgmzQBSYN/5Rh038sutgOOB5tCic2okI4t1HDoZTYSpnHA3nMyxCJa7YP yWOpa7IyJsrEBUsVeie/lFpJjxNDf0Xab9qLycz1FaWaesP2xqKtSw8LvmMxCf9qhReBOKPTMNgG ZN/Jh+w+PZv0FwAAAP//AwBQSwMEFAAGAAgAAAAhAEtzQUzWAAAA/wAAAA8AAABkcnMvZG93bnJl di54bWxMj0FLw0AQhe+C/2EZwZvdKFgkzaYURQQPio2gx2l2uolmZ0N2m8b+eqde6uUxwxvefK9Y Tr5TIw2xDWzgepaBIq6DbdkZeK8er+5AxYRssQtMBn4owrI8Pyswt2HPbzSuk1MSwjFHA01Kfa51 rBvyGGehJxZvGwaPSdbBaTvgXsJ9p2+ybK49tiwfGuzpvqH6e73zBl4e5uPB3x5c9fn1utJT9ZE9 uydjLi+m1QJUoimdjuGIL+hQCtMm7NhG1RmQIulPxZN5c1RdFvo/d/kLAAD//wMAUEsBAi0AFAAG AAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEAa0u0o74AAAARAQAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1s LnhtbFBLAQItABQABgAIAAAAIQBLc0FM1gAAAP8AAAAPAAAAAAAAAAAAAAAAABQDAABkcnMvZG93 bnJldi54bWxQSwUGAAAAAAQABAD1AAAAFwQAAAAAEADwByAAAAD///8AAAAAAO7s4QAfSX0AT4G9 AMBQTQAAAP8AgACAAAAADgSIDAAAUEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRl bnRfVHlwZXNdLnhtbKyRy2rDMBBF94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQS AoVuBNLMvffMqFwfxkHtMSbnqdKrvNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU 6Z45PBiTbI8jpNwHJKm0Po7Aco2dCWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+K qjSEMDgLLKBmqpqzuohDuiDcU/OLLlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5 ZeYz0b5tncXG290o68hn48XsTwCr/4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AA AAA2AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb 69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGj PM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8Mw zJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBr eZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZ N2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzh xxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD/ /wMAUEsDBBQABgAIAAAAIQCTCm11EwcAAOcdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZ zW8bRRS/I/E/jPbexk6cNInqVLFjt9CmjWK3qMfx7tg7zezOamacxDfUHpGQEAVxQeLGAQGVWolL +WsCRVCk/gu8mdld78TjxinhQ9AcWu/s77157/c+5mOvXjtOGDokQlKeNoP65VqASBryiKajZnC3 3720HiCpcBphxlPSDCZEBte23n3nKt5UMUkIAvlUbuJmECuVbS4tyRCGsbzMM5LCuyEXCVbwKEZL kcBHoDdhS8u12tpSgmkaoBQnoPbOcEhDgvpaZbBVKO8weEyV1AMhEz2tmjgSBhsd1DVCTmSbCXSI WTOAeSJ+1CfHKkAMSwUvmkHN/AVLW1eX8GYuxNQc2Ypc1/zlcrlAdLBs5hSjQTlpvdvYuLJT6jcA pmZxnU6n3amX+gwAhyF4am2p6mx01+utQmcFZH/O6m7XVmsNF1/RvzJj80ar1VrdyG2xSg3I/mzM 4Ndra43tZQdvQBa/OoNvtLbb7TUHb0AWvzaD717ZWGu4eAOKGU0PZtA6oN1urr2EDDm74YWvA3y9 lsOnKMiGMrv0FEOeqnm5luAHXHQBoIEMK5oiNcnIEIeQxW3M6EBQPQHeJLjyxg6FcmZIz4VkKGim msH7GYaKmOp79fzbV8+folfPn5w8fHby8IeTR49OHn5vdTmCN3A6qgq+/PqT37/8EP329KuXjz/z 42UV//N3H/3046d+IFTQ1KIXnz/55dmTF198/Os3jz3wbYEHVXifJkSi2+QI7fMEfDPEuJaTgTif RD/GtCqxnY4kTrGexaO/o2IHfXuCGfbgWsRl8J6ADuIDXh8/cAzuxWKs8pA7nt2MEwe4yzlrceFl 4aaeq0Jzf5yO/JOLcRW3j/Ghb+42Tp34dsYZtE7qU9mOiWPmHsOpwiOSEoX0O35AiIev+5Q6vO7S UHDJhwrdp6iFqZeSPh042TQVukETiMvEZyDE2+Fm9x5qcebzeoccukioCsw8xvcJc2i8jscKJz6V fZywKuG3sIp9RvYmIqziOlJBpEeEcdSJiJQ+mTsC/K0E/SZ0D3/Yd9kkcZFC0QOfzluY8ypyhx+0 Y5xkPmyPpnEV+548gBTFaI8rH3yXuxWinyEOOJ0b7nuUOOE+uxvcpSPHpGmC6Ddj4YnldcKd/O1N 2BAT02qgrzvtOqHp2969cO/eFtRbPDdOdex5uNN9us1FRP/9bXoHj9M9ApUxu1a97dJvu3Twn+/S 8+r54nvztB1Dp9Z7J7vpNlvwZO4OfEgZ66kJI7ek2YRLWISiLgxqOXP6JOWJLIvhp65kmMDBjQQ2 Mkhw9QFVcS/GGWzg64FWMpK56pFEGZdwcDTDXt0aD4cAZY+dq/pAYjuHxGqXR3Z4RQ8X545SjbFq ZA63xUQrWsGik61cyZWCb28yWV0btfBsdWOaaYrObKXLmmJzQAfKS9dgsGQTdjcI9kTA8hqc//XU cPDBjESadxujIiwmCn9NiHKvrSMxjogNkTNcYbNuYlek0Ix/2j2bI+djs2QNSDvbCJMW8/NnQZIL BVOSQfB0NbG0WlssRUfNYGN1eTVAIc6awRCOvPAzySBoUu8HMRvBvVGohM3aM2vRFOnU4w1/VtXh FmNOwThlnAmpdrCMbQzNqzxULNUzWfuXVxs62S7GAU8zWcyKlXVIkX/MCgi1G1oyHJJQVYNdGdHc 2ce8E/KxIqIXR0dowMZiH0P4gVPtT0Ql3FyYgtYPcM2m2Tav3N6ad5rq5ZbB2XHMshjn3VJf0xQV Z+Gmn5Q2mKeKeeCb13bj3Pld0RV/Ua5U0/h/5opeDuAWYSXSEQjhlldgpCulGXChYg5dKItp2BWw 7pveAdkCV7XwGsiHu2bzvyCH+n9bc1aHKWs4DKp9OkKCwnKiYkHIHrQlk31nKKvnS49VyXJFJqMq 5srMmj0gh4T1dQ9c0z04QDGkuukmeRswuNP55z7nFTQY6T1Ktd6cTlYunbYG/u6Niy1mcOrUXkLn b8F/aWK5uk9XPytvxIs1suqIfjHdJTWKqnAWv42NfKo3NGGRBbiy1tqONePx8mphHERx1mMYLPcz GdwFIf0PrH9UhMx+uNALap/vQ29F8B3C8ocgqy/prgYZpBuk/TWAfY8dtMmkVVlq852PZq1YrC94 o1rOe4psbdki8T4n2eUmyp3OqcWLJDtn2OHajs2lGiJ7ukRhaFicQ0xgzBev6kcpPngAgd6B6/8x s5+pZAZPpg6yPWGya8CjSf6TSbvg2qzTZxiNZOk+GSIaHRfnj5IJW0L2U0mxRTZoLaYTrRRc8R0a XMEcr0XtalkKL58tXEqYmaFll8LmUs2nAD6U5Y1bH+0Ab5us9VoXV8EUS/8MZQsY76fMe/JZlDJ7 UHxtoN6AMnX8espypoC82cSDT50Cw9GrZ/ovLDo2003Kbv0BAAD//wMAUEsDBBQABgAIAAAAIQAN 0ZCftgAAABsBAAAnAAAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzhI9N CsIwFIT3gncIb2/TuhCRJt2I0K3UA4TkNQ02PyRR7O0NriwILodhvplpu5edyRNjMt4xaKoaCDrp lXGawW247I5AUhZOidk7ZLBggo5vN+0VZ5FLKE0mJFIoLjGYcg4nSpOc0IpU+YCuOKOPVuQio6ZB yLvQSPd1faDxmwF8xSS9YhB71QAZllCa/7P9OBqJZy8fFl3+UUFz2YUFKKLGzOAjm6pMBMpburrE 3wAAAP//AwBQSwECLQAUAAYACAAAACEAm+hwT/wAAAAcAgAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAAAAAAAAAAAAAA AC0BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAAAAAAAAAAAAA ABYCAAB0aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sUEsBAi0AFAAGAAgAAAAhAJMKbXUTBwAA 5x0AABYAAAAAAAAAAAAAAAAA0wIAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAA ACEADdGQn7YAAAAbAQAAJwAAAAAAAAAAAAAAAAAaCgAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVN YW5hZ2VyLnhtbC5yZWxzUEsFBgAAAAAFAAUAXQEAABULAAAAAAAADwQ6AQAAPD94bWwgdmVyc2lv bj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0KPGE6Y2xyTWFwIHht bG5zOmE9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9kcmF3aW5nbWwvMjAwNi9t YWluIiBiZzE9Imx0MSIgdHgxPSJkazEiIGJnMj0ibHQyIiB0eDI9ImRrMiIgYWNjZW50MT0iYWNj ZW50MSIgYWNjZW50Mj0iYWNjZW50MiIgYWNjZW50Mz0iYWNjZW50MyIgYWNjZW50ND0iYWNjZW50 NCIgYWNjZW50NT0iYWNjZW50NSIgYWNjZW50Nj0iYWNjZW50NiIgaGxpbms9ImhsaW5rIiBmb2xI bGluaz0iZm9sSGxpbmsiLz6wAB4E3gUAAFBLAwQUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAFtD b250ZW50X1R5cGVzXS54bWx8kMtOwzAQRfdI/IPlLYqdskAIJemCxwoBi/IBlj1JLPySx6mav2eS FglQ1dVoHnfu0W22B+/YHjLaGFq+ETVnEHQ0Ngwt/9y9VPecYVHBKBcDtHwG5Nvu+qrZzQmQkTpg y8dS0oOUqEfwCkVMEGjTx+xVoTYPMin9pQaQt3V9J3UMBUKpyvKDd80T9GpyhT0faHwkITlnj8e7 xarlKiVntSoEKpetPKvL4PCCcB/MP7rqRCZIuT7H0Sa8OTm8UzTZGmAfKpc35YlDmowSHQ1f1Ryn 8qfZiMvgZ/xj31sNJurJUyYiZUCqK4p34pfRD5Nco+++AQAA//8DAFBLAwQUAAYACAAAACEAcPA4 3L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZ KPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zrFdxvp80eBCd0BkfvSMFMDG2zXtVXGjHlEA82 sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAsmOJsFMSzqUDc5pCb/7N911lN R6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA//8DAFBLAwQUAAYACAAAACEA 8AjbFK0CAAC2BwAAIQAAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbLRVTW8aMRC9 V+p/sHxPFjZAyAqIWtr0kg9USO+u12SteG3LNlv49x3bayIIlZZWveyHPfNm5r0Ze3K7rQVqmLFc ySnuX/YwYpKqksuXKX5e3V2MMbKOyJIIJdkU75jFt7OPHya6sKK8Jzu1cQgwpC3IFFfO6SLLLK1Y Teyl0kzC3lqZmjj4NS9ZacgvwK5Flvd6o6wmXOLW33TxV+s1p+yLopuaSRdBDBPEQf624tomNN0F TRtmASZ4H6bkdhqqBWLcijvBPslytcUo2JsGdvp4BhTQpSiRJDUs/ABTTolAwR4BY2jFti6YWb0y jHkH2XwzeqkXJng/NguDeOnRWhSctRutWfiVYAYf2ZH7S0IixXZt6tmEFMAO2k4xiLjzT3AiBSSB aFykb6u0ejphS6uvJ6yzFAAy2AcF/XWs6H05eSrniJT+vrzoQwDjXtFXi6SCgj0PsU762CRUX7yP oysUNXFeD4yU4aBclKj1iqaBpuRtA9Up/z1Bo1F+M+hFmvLrwehqfMhV3hteh33P2HA87A/zYQiS kCBIhNaF235W5c4z/RPeIKhvmilmxBcfYYV1S7cTLOgBrJECSoIHGAviB43Ji+clDFrt5oIRGMRW OzebC05fkVOIldyhB2IdMyhQAGMJkBMQx0FvtJBMlgtiyPcjZM8qKSAy5J3yDSV4Zv+s49V7HX03 LQShrFKihFRyXyEMQhLsryT1xB0pCmMBPZv6obuyg+E1HCyh/08JO+r1b8Z+/38JC/2GRCP2Cv6j 0J7uoLM9EDqKGRSFRwoZ2Dqjt5aMKjimBGuY6AAfpD4DflVx0x39Ko5KZ77u1Ma4qnPyg3Ph+fok OpynZ49YmLR4A8CnvzPCyAjzQPRTEyqG2xIGex6WNNyP7TH4ZuIx0n07+w0AAP//AwBQSwECLQAU AAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht bFBLAQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVs c1BLAQItABQABgAIAAAAIQDwCNsUrQIAALYHAAAhAAAAAAAAAAAAAAAAABMCAABkcnMvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAA/wQAAAAAoAAeBJoFAABQSwME FAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDLTsMwEEX3SPyD 5S2KnbJACCXpgscKAYvyAZY9SSz8ksepmr9nkhYJUNXVaB537tFttgfv2B4y2hhavhE1ZxB0NDYM Lf/cvVT3nGFRwSgXA7R8BuTb7vqq2c0JkJE6YMvHUtKDlKhH8ApFTBBo08fsVaE2DzIp/aUGkLd1 fSd1DAVCqcryg3fNE/RqcoU9H2h8JCE5Z4/Hu8Wq5SolZ7UqBCqXrTyry+DwgnAfzD+66kQmSLk+ x9EmvDk5vFM02RpgHyqXN+WJQ5qMEh0NX9Ucp/Kn2YjL4Gf8Y99bDSbqyVMmImVAqiuKd+KX0Q+T XKPvvgEAAP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrC MBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDIaW+s 6xXcb6fNHgQndAZH70jBTAxts17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYyoH5g T3JbljsZvxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLv B9nUcvG3+QAAAP//AwBQSwMEFAAGAAgAAAAhAKBAHdJpAgAA1gYAACEAAABkcnMvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0MS54bWysVU1vGyEQvVfqf0Dck81HVVUr25HqNr3kw6qd3qcs9qKwgIBs 7X/fB+wmSupKttoLy8LMY96bGZhcbTvNeumDsmbKz0/POJNG2EaZzZQ/rK5PPnEWIpmGtDVyyncy 8KvZ+3cTVwfd3NDOPkUGDBNqmvI2RldXVRCt7CicWicN9tbWdxTx6zdV4+kXsDtdXZydfaw6UoYP /v4Qf7teKyG/WPHUSRMLiJeaIuIPrXJhRHOHoDkvA2Cy9+uQ4s6BLYSJqy1n2c73WDnnM1AXS90w Qx0WVipqySAQ+wFjJUizldzGbBbcykuZHEz/zbulW/jsfdcvPFNNQhtQeDVsDGb518AMk+qN+2ZE onq79t1sQjVUYdspR/J2aYQT1QiCibIoXlZFe7/HVrRf91hX4wGI4PlQ5N0VRn/SuRjpFFHOn1kV U4LrjRWPgRkLnol+oSfu+hEscU7wrmUlBTHpO9iVzazHaB+gaRYrbj/bZpeI/8Q3L1KtQ1zGnZZZ EIRNNcAxQH5NqcKlOXlYosK7ONeS0AGDeHE210o8smiZbFRktxSi9CwHg34A5ATqRCRngJSmWZCn 72+QEz+qcTKCHiPEtEj4dyEvRyFf1RRbaBKytbpBKBf/Q9wkFWfWKzRBqXaOukTRjJk5RvF0jQBF Ugo6RbdPf6SL6V4/C/2P+UhFntMRXuWjaJ6FxzAemUkdUQJLKSz6Wste6gPgc0aOgF+1yh+OflkU PViva/vkY3tw8B+OhVfrvei4d47uhNwQ5abENN2t+TLU/pbcfZ8Z4zVB/83zksP7kfoKpi8mCWN8 j2a/AQAA//8DAFBLAQItABQABgAIAAAAIQBHcju1+wAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABb Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAA AAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAKBAHdJpAgAA1gYAACEAAAAAAAAAAAAA AAAAEwIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAAC7 BAAAAACQAB4EQAgAAFBLAwQUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAFtDb250ZW50X1R5cGVz XS54bWx8kMtOwzAQRfdI/IPlLYqdskAIJemCxwoBi/IBlj1JLPySx6mav2eSFglQ1dVoHnfu0W22 B+/YHjLaGFq+ETVnEHQ0Ngwt/9y9VPecYVHBKBcDtHwG5Nvu+qrZzQmQkTpgy8dS0oOUqEfwCkVM EGjTx+xVoTYPMin9pQaQt3V9J3UMBUKpyvKDd80T9GpyhT0faHwkITlnj8e7xarlKiVntSoEKpet PKvL4PCCcB/MP7rqRCZIuT7H0Sa8OTm8UzTZGmAfKpc35YlDmowSHQ1f1Ryn8qfZiMvgZ/xj31sN JurJUyYiZUCqK4p34pfRD5Nco+++AQAA//8DAFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAA AF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M 3b6nUbwosvVOQVWUIMhpb6zrFdxvp80eBCd0BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYD TciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAsmOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1d cPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA//8DAFBLAwQUAAYACAAAACEAHJx+kg8FAABVEAAA IQAAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbKxY227jNhB9L9B/IPRaZB35HiPO Ikm7bYFs1lh7P4CWqFgNRQkk7XXy9T1DUpaUZgvD6xdHIoeHnJkzc6hcf9wXku2ENnmp5lH84TJi QiVlmqunefRt9eliGjFjuUq5LJWYRy/CRB9vfv3lupoZmT7wl3JrGTCUmfF5tLG2mvV6JtmIgpsP ZSUU5rJSF9ziVT/1Us2/A7uQvf7l5bhX8FxFYb0+Zn2ZZXkifi+TbSGU9SBaSG5xfrPJK1OjVceg VVoYwLjV3SPZlwreVnmy2kfMmekdBuLoBp4nS5kyxQsMLPLEbrVg33O7Yfe8onM4G1OttBBkrXZ/ 6mpZLbRb+rhbaJanBBUgol6YCGbuVcEMD703y59qJD7bZ7q4ueYzRITt5xES90K/WMRnYm9Z4geT ZjTZfHnHNtn88Y51r94AJzhsipxX3qP/utOv3VnlVgoWH7zyphxLH8rk2TBVwk9y37uXPO5qMPKZ 4KsN8+G3BBXs/KSLR21vXEzrgx4iEU+u+v0peAvPh1Ow7PJNVEbD6XiIQUaxGY3Hk8HUbVIjYRMP Xc3s/q5MXyika/xF5rhKNiWYuqYVfCaNXdoXiTzjeSdjnIhx+YRSkmABn6Ui+4oh8zqPwHdsua49 P9gjyV0chJjPEAj8YKnkVIlCXXxbohILey8FB3xwyd7cyzx5ZrZkIs0t+8yNFZq5wKFucTJCt24P BylUuuCa06HayJQLPsPO8L322YWB8vHjpA/qpNdlsJA8EZtSpjhEn0KEYqkTfBIFUIERygVcrglz GhHGcX8yGfmk1dXR4cEwjoksRxMBPdOixZT6NWLyb2Xm0VU8HCLD1r0MR5M+XnR7Zt2ZsfK+lJRI yrRCi7zd2jLLrU+FpxtNvUexgusHV/K5StG/apT19hFN2hGzRbwBmBfcChR1sDvZJ7Z6KHdcnPcY vH4TJuARSMAbNHguFsfiUS16r4FHIAFv2ODFg0lMdXzcAanSDoCEEgBHLcApWsRpgIQSAMcNIFoO DnjSCQklAE5agJOhy9wJLhNKAJw2gITm2t5RSe7EkFAC4FULcDyanJgUQnm/8TXwiCXI+dXxHMR4 w/dDm2Wg+oqvl2ixNYu19daCP6g7/ey0NiuVvXWdmaPOULMQfRWmsdMGbRb3ksVWJSgnknlUnlpW CT2YKlkklu04YGMEpqFXy+JOZG9tqeXXTARGY3GboSV7XGs8bssuzK6391Kv9q6c19vl6+HxE1xx Cpmh2c6jW51zSXyHSDUNwPL1g6FmUouQL4iQyJYMPG+LvCj/yX2cO2qDkHoKQrWI2e53O48Uugxd C3X+jP1VuXRPEXsWmi6R1G9YwiHywbBK3Epqclzmr+Iv97rmRsicLpUwV+VCl2VGz3RkqehXlZ9y Kf3B/YgpZZ7SIE27a6ZAkHwE7d5LBCbaViLLRGLrWGwfVIjjlmDCsyNDK6S/FepCWh9Twd9MCO4n EvNmIjGh6zTRPU1Wh7Wsrkiq2po6oB1+VlNJW5A+ZHfDZRbk1ak1JP80eR0NcIvy16jm9tnR1+kl bl1+kyPuWY63P618cUdZ6HLmuHWy8jlmBzqeQ/molwTKnEf5rtp4ZxC+Dt4ZdK+DdwbZ6+CdQfU6 eGcQvQ7e/2teUDhHfEfT0y//1DTc3d90Lv8/uuC7e77/WMUjfdu6FiP1Z1592bmz4GMenxXotBiq IJNUAzBtTAij/nfAzb8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAAAAAAAA AAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAcPA43L4AAAA4AQAA CwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAHJx+kg8FAABVEAAA IQAAAAAAAAAAAAAAAAATAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsFBgAA AAADAAMAyQAAAGEHAAAAAIAAHgQfBwAAUEsDBBQABgAIAAAAIQBHcju1+wAAALsBAAATAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbHyQy07DMBBF90j8g+Utip2yQAgl6YLHCgGL8gGWPUks/JLHqZq/Z5IW CVDV1Wged+7RbbYH79geMtoYWr4RNWcQdDQ2DC3/3L1U95xhUcEoFwO0fAbk2+76qtnNCZCROmDL x1LSg5SoR/AKRUwQaNPH7FWhNg8yKf2lBpC3dX0ndQwFQqnK8oN3zRP0anKFPR9ofCQhOWePx7vF quUqJWe1KgQql608q8vg8IJwH8w/uupEJki5PsfRJrw5ObxTNNkaYB8qlzfliUOajBIdDV/VHKfy p9mIy+Bn/GPfWw0m6slTJiJlQKorinfil9EPk1yj774BAAD//wMAUEsDBBQABgAIAAAAIQBw8Djc vgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYggeBL9gCXZtsE2Cdko 9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4EJ3QGR+9IwUwMbbNe1VcaMeUQDzaw yBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/s33XWU1H r58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAIAAAAIQDa 39dV7gMAAMsNAAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1szFfLkps4FN1P 1fyDin1iA8Z2U22napzHptPpGjsfIIPcMBESJdSOna+fI4HcwDgx7s5iNhiLo8N9nXvF7btDwcme qSqXYuH5b8ceYSKRaS4eF97Xzcc3c49UmoqUcinYwjuyynu3/POP2zKueHpHj/JJE3CIKqYLL9O6 jEejKslYQau3smQCz3ZSFVTjr3ocpYp+B3fBR8F4PB0VNBdes18N2S93uzxh72XyVDChaxLFONWw v8rysnJs5RC2UrEKNHZ31yR9LOGt3P6zOXjEwtQeC763hOfJmqdE0AILKyk0GMj3XGdkRUtjh8VU 5UYxZtBi/0mV6/JB2a33+wdF8tRQNRTeqHnQwOxfARhuRr3tj46JxoedKpa3NEZEyGHhIXFHc8Um GrODJkm9mDyvJtmXM9gk+3AGPXIvgAWnlyLnZe3Rf90JnDubXHNG/JNXNZRi651MvlVESPhp3K/d S+73jsz4bOjLjNTh14aqwdUPbTwcvrIxdYaeIjGJZqgtG45gFo6jXkzC8Xge+qFHTGR8fxo0iLbH NXMZ68NfMj2aiG7xi8RRkWQShbqt48wrvdZHjjTTmO+5D4MI5Y9QEkcR0Dhlu7+xVP1YeDAJNm2d 4yc8coz7Fg8iTGPEARds5dQIkYk3X9cQYqFXnFHQNz7p5YrnyTeiJWFprslnWmmmiI0bZAvLDLu2 77CUTKQPVFFjVJvZpILGeDPi63zGbZ3tn+ccQeyq4IHThGWSpzAieF0F5Cnq1xXJ8OSH0SwyCTVi OJf9yPd9IOrsR/Mo9FEKtfu1oKzbdR26SLjsW2m1U9WkvJfp0FRfTdkC4DZo6rVdFfM21gGADc9g J22sAwA7OYM11XaywQGAjS5hHQDY6SWsAwA7u4R1AGDnl7AOAOzNJWwNOKch7CRgOInllZoyPdVK qupoqtaNFQ8u7pW2cK+Q8ZolUqSEsz3jA+ittq6g32S5Gs5uBXEF+0f5pDD9hho/MYV5DX2+O8uO Mfdbu9nEdbONSXW7ldmAYOy7UfWiYWYmCFo4RkFG+c7DGQANzibSDjXTcuzN2la8ab5m6VfTzZ+E kV/r/Hnkd8bbZHrjj6evbnCkoOrOHjFykeK0Y26NadunexwKbTZbPc3v9CkzEw0WSjTtraFyM3oQ X6ef9npkw3fjT8xbySC+Tm/s9dGGzw9n/nQo4c0veq3jmwdz0+oHGdjh6/Xjhi8I5jDvJXy9nu34 ZhM7tq63r9fXGz5DNjghHX97vd/xTaPZy/Lx/5gPULY7TdgDhtW6+0TAivmisF8BXH2m5Ze9lQw+ oXCaW9mlEh9NZp4D+gwxVO4jbPkvAAAA//8DAFBLAQItABQABgAIAAAAIQBHcju1+wAAALsBAAAT AAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+ AAAAOAEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhANrf11Xu AwAAyw0AACEAAAAAAAAAAAAAAAAAEwIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnht bFBLBQYAAAAAAwADAMkAAABABgAAAABwAB4EcwQAAFBLAwQUAAYACAAAACEAR3I7tfsAAAC7AQAA EwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOwzAQRfdI/IPlLYqdskAIJemCxwoBi/IBlj1JLPyS x6mav2eSFglQ1dVoHnfu0W22B+/YHjLaGFq+ETVnEHQ0Ngwt/9y9VPecYVHBKBcDtHwG5Nvu+qrZ zQmQkTpgy8dS0oOUqEfwCkVMEGjTx+xVoTYPMin9pQaQt3V9J3UMBUKpyvKDd80T9GpyhT0faHwk ITlnj8e7xarlKiVntSoEKpetPKvL4PCCcB/MP7rqRCZIuT7H0Sa8OTm8UzTZGmAfKpc35YlDmowS HQ1f1Ryn8qfZiMvgZ/xj31sNJurJUyYiZUCqK4p34pfRD5Nco+++AQAA//8DAFBLAwQUAAYACAAA ACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2IIHgS/YAl 2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zrFdxvp80eBCd0BkfvSMFMDG2zXtVX GjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAsmOJsFMSzqUDc5pCb /7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA//8DAFBLAwQUAAYA CAAAACEA/+70YUIBAABwAgAAIQAAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbIxS y07DMBC8I/EPlu/ULQeEoiaVeF6AVmr5gMVxmgi/tHZD8vds3AQE6qEXaz2eGe94vVx1RrNWYWic zfliNudMWenKxu5z/r57urrlLESwJWhnVc57FfiquLxY+izo8gV6d4iMPGzIIOd1jD4TIshaGQgz 55Wls8qhgUhb3IsS4Yu8jRbX8/mNMNBYPurxHL2rqkaqBycPRtl4NEGlIVL/oW58mNz8OW4eVSCb pP7bUuw9pf3QYD85SzRsCVjwgpLLrS6ZBUPAXWIMYPA7VGqobPuMfus3mLhv7QZZUw7aUcPFeDDS 0tYSjQrxT76fnCDrKjTFEjJ6AtblnCbVDyuJIFNdZPIIyl9U1usTXFk/nmCL6QLq4OdSqqdYVA6x U+caX8GvW8oHGc05KrxPkKfJHjPIX8rgMf2U4hsAAP//AwBQSwECLQAUAAYACAAAACEAR3I7tfsA AAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAA IQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAA IQD/7vRhQgEAAHACAAAhAAAAAAAAAAAAAAAAABMCAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5 b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAAlAMAAAAAYAAeBA0FAABQSwMEFAAGAAgAAAAhAEdyO7X7 AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDLTsMwEEX3SPyD5S2KnbJACCXpgscKAYvy AZY9SSz8ksepmr9nkhYJUNXVaB537tFttgfv2B4y2hhavhE1ZxB0NDYMLf/cvVT3nGFRwSgXA7R8 BuTb7vqq2c0JkJE6YMvHUtKDlKhH8ApFTBBo08fsVaE2DzIp/aUGkLd1fSd1DAVCqcryg3fNE/Rq coU9H2h8JCE5Z4/Hu8Wq5SolZ7UqBCqXrTyry+DwgnAfzD+66kQmSLk+x9EmvDk5vFM02RpgHyqX N+WJQ5qMEh0NX9Ucp/Kn2YjL4Gf8Y99bDSbqyVMmImVAqiuKd+KX0Q+TXKPvvgEAAP//AwBQSwME FAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9 iCB4Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDIaW+s6xXcb6fNHgQndAZH70jB TAxts17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYyoH5gT3JbljsZvxnQLJjibBTE s6lA3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLvB9nUcvG3+QAAAP//AwBQ SwMEFAAGAAgAAAAhALhSHtjcAQAAwgMAACEAAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0 MS54bWyMU8tu2zAQvBfoPxC8J7JzKArCUoA4bS9JbNTOB2yptSWEIglyo0p/3yUlJW2aQy58LGeH O8Pl5nrojOgxxNbZUq4vV1Kg1a5u7bmUj8fvF1+liAS2BuMslnLEKK+rz582XkVT38Honkkwh40K StkQeVUUUTfYQbx0Hi2fnVzogHgbzkUd4Ddzd6a4Wq2+FB20Vs754SP57nRqNd46/dyhpYkkoAHi +mPT+riw+Y+w+YCRaXL2vyXR6FkttWRwZ80oRYaGnoNrWbF6fTC1sNBx4JhQIsPSSfTHgJhWtv8R /MHvQ0546PdBtHUimBNlMR/MsLy1DONF8Sb9vDCBGk6hqzag2AsxlJKfbEwjJ4HCgYSegvo1qpvd O1jdfHsHXSwXcAUvlyZVk6L/5VwtciYf1i+qJihw6p3TT1FYxzqT/EmefugXsqQ50ftG/GX8jJsO sx8LPrKn2Swablw9JuG/eM5BUCbSgUaD2RAuGxST88D2G0h9jfbi8cB93dHWIHDfz+ZRtTWtfhLk BNYtiXuIhEHkLuBfwJQbdof4cWZKtPUeAvx8w5z0geKbueilQl4mC/M09QcvUxPlFjDhHvyuz3Xy z+Fbtznk+a/Mbr1CEsfy96o/AAAA//8DAFBLAQItABQABgAIAAAAIQBHcju1+wAAALsBAAATAAAA AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAA OAEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhALhSHtjcAQAA wgMAACEAAAAAAAAAAAAAAAAAEwIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBL BQYAAAAAAwADAMkAAAAuBAAAAABQAB4EogcAAFBLAwQUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAA AFtDb250ZW50X1R5cGVzXS54bWx8kMtOwzAQRfdI/IPlLYqdskAIJemCxwoBi/IBlj1JLPySx6ma v2eSFglQ1dVoHnfu0W22B+/YHjLaGFq+ETVnEHQ0Ngwt/9y9VPecYVHBKBcDtHwG5Nvu+qrZzQmQ kTpgy8dS0oOUqEfwCkVMEGjTx+xVoTYPMin9pQaQt3V9J3UMBUKpyvKDd80T9GpyhT0faHwkITln j8e7xarlKiVntSoEKpetPKvL4PCCcB/MP7rqRCZIuT7H0Sa8OTm8UzTZGmAfKpc35YlDmowSHQ1f 1Ryn8qfZiMvgZ/xj31sNJurJUyYiZUCqK4p34pfRD5Nco+++AQAA//8DAFBLAwQUAAYACAAAACEA cPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2IIHgS/YAl2bbB NgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zrFdxvp80eBCd0BkfvSMFMDG2zXtVXGjHl EA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAsmOJsFMSzqUDc5pCb/7N9 11lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA//8DAFBLAwQUAAYACAAA ACEA8BdhJXEEAABAFwAAIQAAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbOxY25La OBB936r9B5XfEzCYy7gGUrXsZl8mM1ML+QBhi7E3tuSVBQP79dvdssBcnPKQVCVVywsI+ei4L+qj RvcftnnGNkKXqZITz3/f9ZiQkYpT+TLxPi8+vht7rDRcxjxTUky8nSi9D9Nff7kvwjKLH/hOrQ0D DlmGfOIlxhRhp1NGich5+V4VQsKzldI5N/BTv3RizV+BO886vW532Ml5Kr1qvW6zXq1WaSR+V9E6 F9JYEi0ybsD+MkmL0rEVbdgKLUqgodXHJpldAd6aV7XYLl7V0/JvjxFYb2Da96bgfzTPYiZ5DhMz lRdcp6WS9KQsFloIxMjNn7qYF8+aFjxunjVLYySoFnqd6kEFo58SYDDonCx/cUw83K50Pr3nIUSD bSceJG2Hn7CIh2JrWGQno8NslDxdwEbJHxfQHfcCsGD/Ush3YT06d6fn3FmkJhPM33tloRyWPqjo S8mkAj/Rfete9LhxZOgz0hcJq0KPVBXOPqR4OHwJMaVgme1vKt6h40v4pkkeZqWZm10GKYDxJvMp ATyMxeovG9raNHhbh4OTPART4AOSlXGsAyHffZ5DHeRmlgkOdVKF2kxnWRp9YUYxEaeGfeKlEZoZ ikKJBtwDu4FUVpRCxs9cczDiiBmjwUN4M7jo/IGhDXhz2Pv7sGPOnzMeiURlMVjQ+x4ZwHh6sF1h L7mENSQCo3WyJYPBCAqc9qU/6A98v48mHXZn0A26/hjEBffosH83GpLNEAZLRO7bLeEi4jLMuIwS BWqxtJT17FXJZjnXD1QXqYyhwHGIb1+uH0HFyBC7F1j578TrBWjp0rlZ2xs07MHuqQidV61Yu+es SIV2gJn9A+udH5AFbVj98TkrUlWswYHV74/8IYJb0RLyOATIVdEOarTj3phsuJYWuSra4YG21xuD Cd9gLXJVtKMa7Sjo0z681lrkqmjHB1rkbJ+yC7FFror2rkY7HIy+KWXIRVpSrwlSNHwJ7Lq9dNHb r1c4FBwSuPJI4a5RscCp2ExJA7V6JGSkGnDUuoPijUcJVnfCs1UlY1Zi8FilMOGgfp5gQpplrOeP gvFo8BUZ698NfCgORLTRMZKheqLOTqqDOlnKGgCGTkzqSoYltMc6AGCdRNSwpCR7rAMA1tV9HYu7 co91AMC6Ym7EOgBgXYU2Yh0AsK7sGrEOAFhXS41YBwCsLRDXCVB8SST3vv0cFUTNAHy4oqXz9w1t yVxESsYsExuRXSjQU3qqizfQL5JUt2evTv7WivNRrbVJWhsf2IpsT5+uLrJDb/Jdu7OB07XFaXdG Fl8varY/tt0ZCtw/a66h7aw0jqJNrXJrjRsGg24PzIVOrKlX80egfLdebeLdejXol2+92sTr/x97 taHTtEu9GrVG18vauZSRTl4tZU392kHKbv0axvy4/7n1aw13Ol/9x3PaUN36NbxCs/8GT2PzI/s1 ulWyd7MwxAtcun7N9CdePG2ohYR7a2imZjRVwE01/jMA6AGCHO7me/ofAAAA//8DAFBLAQItABQA BgAIAAAAIQBHcju1+wAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s UEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxz UEsBAi0AFAAGAAgAAAAhAPAXYSVxBAAAQBcAACEAAAAAAAAAAAAAAAAAEwIAAGRycy9zbGlkZUxh eW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAADDBgAAAABAAB4ESAYAAFBLAwQU AAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOwzAQRfdI/IPl LYqdskAIJemCxwoBi/IBlj1JLPySx6mav2eSFglQ1dVoHnfu0W22B+/YHjLaGFq+ETVnEHQ0Ngwt /9y9VPecYVHBKBcDtHwG5Nvu+qrZzQmQkTpgy8dS0oOUqEfwCkVMEGjTx+xVoTYPMin9pQaQt3V9 J3UMBUKpyvKDd80T9GpyhT0faHwkITlnj8e7xarlKiVntSoEKpetPKvL4PCCcB/MP7rqRCZIuT7H 0Sa8OTm8UzTZGmAfKpc35YlDmowSHQ1f1Ryn8qfZiMvgZ/xj31sNJurJUyYiZUCqK4p34pfRD5Nc o+++AQAA//8DAFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIw EETvgv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zr Fdxvp80eBCd0BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBP cluWOxm/GdAsmOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H 2dRy8bf5AAAA//8DAFBLAwQUAAYACAAAACEA5BV1nBcDAABxDQAAIQAAAGRycy9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQxLnhtbOxXy3LaMBTdd6b/oPE+MQ+HEA+QmdKmmzyYQj5AsUXsRpY8kuJA v75HskUIIQUmXbIBWT46uvfch+TB5aLgpGJK51IMg/ZpKyBMJDLNxeMwuJ9dnfQDog0VKeVSsGGw ZDq4HH39MihjzdNrupTPhoBD6JgOg8yYMg5DnWSsoPpUlkzg3Vyqgho8qscwVfQF3AUPO61WLyxo LoJmvdpnvZzP84R9l8lzwYSpSRTj1MB+neWl9mzlPmylYho0bvVbk8yyhLfmRd49/A6Iw6kKM+1g BNeTKU+JoAUmZi+SjKUwoHGvdDlTjFmQqH6qclpOlFtxW00UyVPL0KwMwuZFA3OPAjAMwo3lj56J xou5KkYDGkMJshgGCNjS/mIRjdnCkKSeTF5nk+xuCzbJfmxBh34DWLDaFLEua4/eu9Px7sxywxlp r7yqoRRLr2XypImQ8NO6X7uX3FaezPps6cuMNLJbqgZXv3R6eLyGpk4ss/gm06V1/AH/bpLGXJup WXLmBIHZNAY5fiA/pzarmTi5nyKrCzPmjCLrG/HMaMzz5IkYSViaG3JDtWGKGOeXtpQDqGMQnIaS iXRCFf21wWz9ozF2htHeQgxrCT8WsuuFbLKJTDhNWCZ5CiM6n5NV/0E1UD4PkIFIDx+DD7S1cm1k WXR2jnp1qdbutVp27PT1CRe1un3MB8SmXXTWObvodV0APZMToA6z12Rr1OzevOJtVzY0Ttncymvt 7/TrTaHtGgDDzhZstI71AGC7W7CtdawHABu9x7bf2OABwJ7twnoAsL1dWA8A9nwX1gOA7e/CegCw F7uwNcBq3ZSTDYyrJqwkYFiVzSery2aQKy79prrqCtrc0iXuAQU9ZYkUKeGsYnwPeldlB9DPslzt z+4K4gD2K/msTLa38VFdkXuH4yqfb2XHKfJf+1r0r77mNMF56g+DA4+Ljb7m4ueOCttp3GD9zNjW 13pR/9jYcCIcG1t8bGyri9CxsTUXNvdXX+gxtNd+d2fn6oaWd5XrtfjQwTVx7KZKfNrY6x+grxDL 4T+VRn8BAAD//wMAUEsBAi0AFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAA AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAAAAAAAA AAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA5BV1nBcDAABxDQAAIQAAAAAAAAAA AAAAAAATAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsFBgAAAAADAAMAyQAA AGkFAAAAADAAHgSoBgAAUEsDBBQABgAIAAAAIQBHcju1+wAAALsBAAATAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbHyQy07DMBBF90j8g+Utip2yQAgl6YLHCgGL8gGWPUks/JLHqZq/Z5IWCVDV1Wged+7R bbYH79geMtoYWr4RNWcQdDQ2DC3/3L1U95xhUcEoFwO0fAbk2+76qtnNCZCROmDLx1LSg5SoR/AK RUwQaNPH7FWhNg8yKf2lBpC3dX0ndQwFQqnK8oN3zRP0anKFPR9ofCQhOWePx7vFquUqJWe1KgQq l608q8vg8IJwH8w/uupEJki5PsfRJrw5ObxTNNkaYB8qlzfliUOajBIdDV/VHKfyp9mIy+Bn/GPf Ww0m6slTJiJlQKorinfil9EPk1yj774BAAD//wMAUEsDBBQABgAIAAAAIQBw8DjcvgAAADgBAAAL AAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYggeBL9gCXZtsE2Cdko9u/N0YLgcRjm zUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4EJ3QGR+9IwUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK 1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/s33XWU1Hr58TufSjQvJo DV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAIAAAAIQDmJZVYdwMAAGIM AAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1szJdbT9swFMffJ+07WHmHJukl JaJFGhvbAzet8AGM49IIx4ls07X79PsfO2kLA6nioeIlTezjc37nZrunZ6tKsaU0tqz1JEqO44hJ Leqi1I+T6P7u4mgcMeu4LriqtZxEa2mjs+nXL6dNblVxydf1s2PQoW3OJ9HCuSbv9axYyIrb47qR GnPz2lTc4dM89grD/0B3pXppHI96FS911K43+6yv5/NSyO+1eK6kdkGJkYo78NtF2dhOW7OPtsZI CzV+9Uskt27grZXil+RFxLygWWIoiabwXcxUwTSvMDCTgowzEpTGz9rmzkhJcnr50zSz5tb4RdfL W8PKgpS0i6NeO9GK+U8NMbz0Xi1/7DTxfDU31fSU54gGW00iJG1NTyziuVw5JsKg2I6Kxc0bsmLx 4w3pXmcABBujyHcTPPrfnbRz5650SrJk41UQ5Vh6WYsny3QNP8n94J64XnbKyGdS3yxYCL0jVa1c mPTx6OStj2kHuolElqb9pO/DMRjEo5P4VVCyLEsHGGQUmqQ/SuNs6I10mmAkqG5yt/pWF2sK6QN+ kTmuxaJGlTpawXNl3cytFfKM96VKQMS4ekQbKVQBzws5/40h+3cSwSRsPvjEC44IcKVas+1KpPul RgSb5wgJHlCiOPWj1Ef3M/Rj5c6V5DDUeuem56oUT8zVTBalY1fcOmmYDyG6F4yk3XkbXqXUxS03 nPB2NVNWeA7LiELnvQ8IZeb99CPeoRXuqPZuFRdyUSs0A0vJSXRLl+cPVQJFP0LboKa7wvlQQaQn 8ShDcfjkdV3ysiCGcZyMszYzocn2KYiHoPOtgqi4ufQNWuoCOw29Uk4fnq+xnXqSnTLBlhimba3K 4qJUimT9birPlWFLrlB9K9qCkM5SuzCSAdtXApK3Efap3NGDuWDJT2yqzpduSqUbSAfDDBQI9x64 yfiAuMRIboO8v8U9SdDm++KODohLjC3uYIub9LOEKPYLL3nmC+AA1UCQLe9wh3ecjinJn4+XIFve 0ZY3TccI72fkJciWN9vhzQb9/dvtkPVAkC3veMtLsPv32yF5CbLlPdnhHQ2zz9lvBBl24p1bhD/z iR6b3OZw9259/A5AB52/AtgXd4D3znl/3IXbK17pmusPcGWueHOz9Cy42eN2gfMIQw3u8nRrgOhW hHR0/w2m/wAAAP//AwBQSwECLQAUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAAAAAAAAAAAAAAAA AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAA AAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDmJZVYdwMAAGIMAAAhAAAAAAAA AAAAAAAAABMCAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJ AAAAyQUAAAAAIAAeBIAFAABQSwMEFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAABbQ29udGVudF9U eXBlc10ueG1sfJDLTsMwEEX3SPyD5S2KnbJACCXpgscKAYvyAZY9SSz8ksepmr9nkhYJUNXVaB53 7tFttgfv2B4y2hhavhE1ZxB0NDYMLf/cvVT3nGFRwSgXA7R8BuTb7vqq2c0JkJE6YMvHUtKDlKhH 8ApFTBBo08fsVaE2DzIp/aUGkLd1fSd1DAVCqcryg3fNE/RqcoU9H2h8JCE5Z4/Hu8Wq5SolZ7Uq BCqXrTyry+DwgnAfzD+66kQmSLk+x9EmvDk5vFM02RpgHyqXN+WJQ5qMEh0NX9Ucp/Kn2YjL4Gf8 Y99bDSbqyVMmImVAqiuKd+KX0Q+TXKPvvgEAAP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAAOAEA AAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783RguBx GObNTN2+p1G8KLL1TkFVlCDIaW+s6xXcb6fNHgQndAZH70jBTAxts17VVxox5RAPNrDIFMcKhpTC QUrWA03IhQ/kstP5OGHKMvYyoH5gT3JbljsZvxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO59KNC 8mgNXXD2z5SxGHtKCkzkb2MhqiLvB9nUcvG3+QAAAP//AwBQSwMEFAAGAAgAAAAhAIs7VsRPAgAA nwYAACEAAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWyslctu2zAQRfcF+g8E94ls pygKwXaAuk03eRi18wETcmyxoUiCpFXr7zukJAdJXcBGutGDmrmcezikptf7WrMGfVDWzPj4csQZ GmGlMtsZf1zfXHzhLEQwErQ1OOMtBn49//hh6sqg5S20dhcZaZhQwoxXMbqyKIKosIZwaR0a+rax voZIr35bSA+/SbvWxWQ0+lzUoAzv8/0p+XazUQK/WbGr0cROxKOGSPWHSrkwqLlT1JzHQDI5+3VJ sXXk1j794iwH+YZex3xOvsVKS2agpoG1ihoZ0WELayIp5YDg1h4xhZrmh3crt/Q5775ZeqZk0unz edF/6MPyq6EweijepG8HJSj3G1/Pp1ASDLafcVqzNl0pCUrcRya6QfEyKqqHI7Gi+n4kuhgmoAoO k9Jyu87R33Ymg50Ox/jgqgsFSr214jkwY8lnst/ZE/fNIJY8J3lXsY58TGT7uO5j5jHEB2KaYcX9 VyvbZPyJ7nkQSh3iKrYaMxAqG0oSpwvh15AaG83F44oau44LjUCN38OL84VW4plFy1CqyO4gRPQs F0PbgCSnRCfS4vSSaOQSPPx8o5z8QUkzU9FDhfTYIfw3yKsBZN9NbKlBYGW1pCIm78OqJDXFQP4/ EKUFYLrRB3TvJJzaNgMOrwh3FDNKugxTZhtnLOoKhaU9qrFBfYJ8Jn2G/LpS/nT1q7SOZ6jf2J2P 1cnFfzpXXm2OqtNJcnZv5xbvzj56TOdkPt60vwP30OQOod8C7ahFHnL0I0g7hUJfQpLG8GOZ/wEA AP//AwBQSwECLQAUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAACwB AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCLO1bETwIAAJ8GAAAhAAAAAAAAAAAAAAAAABMC AABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAAoQQAAAAA EAAeBFMGAABQSwMEFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1s fJDLTsMwEEX3SPyD5S2KnbJACCXpgscKAYvyAZY9SSz8ksepmr9nkhYJUNXVaB537tFttgfv2B4y 2hhavhE1ZxB0NDYMLf/cvVT3nGFRwSgXA7R8BuTb7vqq2c0JkJE6YMvHUtKDlKhH8ApFTBBo08fs VaE2DzIp/aUGkLd1fSd1DAVCqcryg3fNE/RqcoU9H2h8JCE5Z4/Hu8Wq5SolZ7UqBCqXrTyry+Dw gnAfzD+66kQmSLk+x9EmvDk5vFM02RpgHyqXN+WJQ5qMEh0NX9Ucp/Kn2YjL4Gf8Y99bDSbqyVMm ImVAqiuKd+KX0Q+TXKPvvgEAAP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVs cy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8 KLL1TkFVlCDIaW+s6xXcb6fNHgQndAZH70jBTAxts17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/k stP5OGHKMvYyoH5gT3JbljsZvxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5Sx GHtKCkzkb2MhqiLvB9nUcvG3+QAAAP//AwBQSwMEFAAGAAgAAAAhAGTm8BUiAwAADgwAACEAAABk cnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWzMVstu2zAQvBfoPxC6J3pYshTBdoCmTS95 IU4+gJFoWwhFESSt2n/fXZKynTQFcshBF5uidkezM1ySs8tdy0nPlG46MQ/i8yggTFRd3Yj1PHh+ uj4rAqINFTXlnWDzYM90cLn4/m0mS83rG7rvtoYAhtAlnQcbY2QZhrrasJbq804yAe9WnWqpgUe1 DmtF/wB2y8MkiqZhSxsR+Hz1mfxutWoq9rOrti0TxoEoxqkB/nrTSD2gyc+gScU0wNjst5TMXkK1 pjGcBcSGqR4m4mABlVdLXhNBW5h4wgiy5E3N7CstnxRjGCT630ou5YOyGXf9gyJNjQg+Mwj9Cx9m HwWEwSB8l74ekGi5W6l2MaMlCEF28wD82uMvJNGS7Qyp3GR1nK029x/EVptfH0SHwweAweGjYLV0 Ff1bTjKU44SID1W5UAqpN131qonooE4s35VX3fUDGNaM8HJDnOqVURbNh7r3VpIhRVtZB64HMaZF VkROkSSeRGmSvdUlz/MkxQBUJ07zKHIRp1U7aFma3Y+u3qOqL/BvXaEl12Zp9pxZtUETWgJz+AFv OcWOYeLseQkd05orzih0lHfGLK54U70S0xFWN4bcUm2YIsauHo2QMyBhwHkPyUT9QBV9fIeM4tES vgxyDAxh6Pz5v0uTwaXl9sV9M/kKo/T2xRkFKxuW3eDt5w2LJ3k89Y5NimIKe8Jbx6Zgl7XUOpZn CUY7EVwj2OLd+hn0+NAxtIn3PIaFQ1qqbmznNKKG7rdDytfgFqw86GIA2N7BbmddrtkKTMBJ3UGX Xzec2wfc4tgVV6SnHDaKHe4M4GAjjJvJs+hA1e6HGGzdO8EBLwd8GHp+iAPD5Eg1zXJUhoyPL5L0 fCdHvhdxattsfHyRpOebHvkeluH4CCNLTzg7IVwkhW2L8RFGlp7w9Eg4SQro3FEuYWTpCecnhPN0 MtKeQ5aecHEkjGxH2nTI0hO+OCE8zXK7949vDSNLu1UP5z2y/4LjHs7Lrzzx7dnnrpswxEupvVFy dUvlfW8lh1s43DPg5IEpCfduPDoh9BiCGMM9fvEXAAD//wMAUEsBAi0AFAAGAAgAAAAhAEdyO7X7 AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA ACEAcPA43L4AAAA4AQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA ACEAZObwFSIDAAAODAAAIQAAAAAAAAAAAAAAAAATAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDEueG1sUEsFBgAAAAADAAMAyQAAAHQFAAAAAAAAHAQEAAAAAQAAACAAug8YAAAATwBmAGYA aQBjAGUAIABUAGgAZQBtAGUADwDuA1sKAAACAO8DGAAAABAAAAAAAAAAAAAAAAAAAIAAAAAABwAA AA8ADAT7CQAADwAC8PMJAAAgAAjwCAAAAAMAAAACCAAADwAD8NsJAAAPAATwKAAAAAEACfAQAAAA AwAAAGQAcgBzAC8AZABvAAIACvAIAAAAAAgAAAUAAAAPAATw7AAAABIACvAIAAAAAQgAACACAAAD AQvwcAAAAAQAAAAAAH8AAQDvAYAAmDpghIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcA AQAAAIgAAAAAAL8AAAAGAP8BEAARAAEDAgQAAD8DAAAIAIDDEAAAAL8DAAACAFQAaQB0AGwAZQAg ADEAAAAAABDwCAAAAD4FsAHQFNwIDwAR8BwAAAAAAMMLCAAAAP////8PAPm/AAAfBAQAAAACAAAA DwAN8CgAAAAAAJ8PBAAAAAYAAAAAAKgPFAAAAFNDSU0gY29uZmVyZW5jZSBjYWxsDwAE8K8IAAAS AArwCAAAAAIIAAAgAgAAAwEL8HYAAAAEAAAAAAB/AAEA7wGAAAjLxYSBADBlAQCCAJiyAACDADBl AQCEAJiyAACFAAAAAACHAAAAAACIAAAAAAC/AAAABgD/ARAAEQABAwMEAAA/AwAACACAwxYAAAC/ AwAAAgBTAHUAYgB0AGkAdABsAGUAIAAyAAAAEwAi8YcHAACpw4EHAABQSwMEFAAGAAgAAAAhADI8 vT77AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJFBTsMwEEX3SNzB8hYlDiwQQk26ILAE BOUAI3uSWCRjy2NCe3smbdkgVMTSnnn/P9mr9XYa1YyJfaBaX5aVVkg2OE99rd82D8WNVpyBHIyB sNY7ZL1uzs9Wm11EVkIT13rIOd4aw3bACbgMEUkmXUgTZDmm3kSw79Cjuaqqa2MDZaRc5CVDN6sW O/gYs7rfyvXBRHCt7g57S1WtIcbRW8giapap+ZVLOPIJcCb3w644mpVC7sN58JEvjg1P8jTJO1TP kPIjTOJhXGLDA0SUnfK051I3cRG6zlss28SvC/dXuAuflHD+b3Yr2AvO3+lm/0PNFwAAAP//AwBQ SwMEFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQsWoDMQyG90DfwWjv+ZKh lBBftkLWkEJXYevuTM6Wscw1efu4lEIvZMugQb/Q9wnt9pcwqZmyeI4G1k0LiqJl5+Ng4PP08foO SgpGhxNHMnAlgX33stodacJSl2T0SVSlRDEwlpK2WosdKaA0nCjWSc85YKltHnRCe8aB9KZt33T+ z4BuwVQHZyAf3BrU6Zqq+Y4dvM0s3JfGctDc994+omoZMdFXmCoG80DFgMvym9bTmlqgH5s3T5od f8cjzUvxT5hp/vPqxRu7GwAAAP//AwBQSwMEFAAGAAgAAAAhACA9GGAcAwAAJwgAABAAAABkcnMv c2hhcGV4bWwueG1s3FVNb9swDL0P2H8QdB26fDRNWqNO0RboNiAogqY9D7Qst15kyZDkLOmv35Pk 9Os0tJdhOSS0+Sg+PpLK6dm2UWwjrauNzvno65AzqYUpa32f87vbq4NjzpwnXZIyWuZ8Jx0/m3/+ dNpmrmUI1i5rc/7gfZsNBk48yIbcV9NKDV9lbEMej/Z+0FrppPbkkahRg/FwOB00VGs+x1F6s2qX NljierO0rC5zfsiZpgYpV13ha68kG/NBD0loAoWFEWvX86C/4VFa+o3iXlFg2nyzqGIUEgwiiT0f DTohafvA/K4FG9cVt4ENB8ltzifjk8nJdDY+OepjUwAOea7Jxdoo21a2+SjV+SllpqoYUo8OZ6Pp EA3bQazj4ykkDRwok1vPBADTyXB4HAACiNHsaBzQocJEJZaauLWZ316YcheiC/yiBam175cUM+XR D2MfOVM/tMv5yWgyARkfHyZHszEe7EtP8crj1aVROR9iQCjTmKTzzpuq9qmAxDK4lPMrv8N4fJBx lG4/0u+uOzBCu1lDdhHIB+MmGmoTq2G1LrEH8RWpeyyd8JazUla3VKweMVFBmSCNT3hJC31h12E6 WWW0P49BBDEgLNZJ926EPJC+x2wvOy2QYBSVU3rVisDKtWIpPNsQjh0Nw6efhZeIC1m9xYLMExRn PCPOK7/HepfO3R8JXO8tuktlb7dR3KJbPT6ZVyglrlRFAmt1bmtSaXyL7hpXTYzwVCxc6DhlEOhm aWFievt9wmJSZiH2umvqxvyqk84QIedSH9ytcHVB0MMoZxGdCdLlXCNFuNlsvUZ2bVbR4mwtbbgH Y4gg3Ak9sBUxPswhqfpRfo+PBTmp6nAvQn1tltaYKtplbT2WDm9d4y+VJByaJlnpwFqbq1qpVE16 44yqy/AyahruUQnlkqx+m3qJZvcNnB29aMoeHLV5dY6sKin8XsJuoXv5u5Cot+MMvejEl0YfKJ9a IemNQ1JyCPfGIVxwoDfoR6jAzxljP/sPTMaCEwMTIAEgdbkkS+jpv9y+wPR/79hzJ9Jy4fv5/wCm a+d/AAAA//8DAFBLAwQUAAYACAAAACEA8ZQWb9cAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESP TUvDQBRF94L/YXiCm2InWqoh9rWIUCKC9Hv/mnlNQjMzcWaapP/ewYUuL/dyLme2GHQjOna+tgbh cZyAYFNYVZsSYb9bPqQgfCCjqLGGEa7sYTG/vZlRpmxvNtxtQykixPiMEKoQ2kxKX1SsyY9tyyZ2 J+s0hRhdKZWjPsJ1I5+S5Flqqk18qKjl94qL8/aiEUb7fHd5Oa/zL/c9OXyu2n7ajdaI93fD2yuI wEP4H0/TZdqlf+Uv6kMhTECc8uvR1WpDPrBDiG7RNFqCnP8AAAD//wMAUEsBAi0AFAAGAAgAAAAh ADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU AAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAU AAYACAAAACEAID0YYBwDAAAnCAAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBL AQItABQABgAIAAAAIQDxlBZv1wAAAPkAAAAPAAAAAAAAAAAAAAAAAHIFAABkcnMvZG93bnJldi54 bWxQSwUGAAAAAAQABAD1AAAAdgYAAAAAAAAQ8AgAAACQCWADIBPgDQ8AEfAcAAAAAADDCwgAAAD/ ////EAD5vwAAHwQEAAAAAwAAAA8ADfBWAAAAAACfDwQAAAAFAAAAAACoDxAAAAA0IFNlcHRlbWJl ciAyMDEzAAChDxYAAAARAAAAAAAAAAAAEQAAAAAABACJiYn+AACmDwwAAADwAAAA1AHQAvADEAUQ APAHIAAAAP///wAAAAAA7uzhAB9JfQBPgb0AwFBNAAAA/wCAAIAAAAAiBAgAAAABAAAAAQAAAA8A 7gNnAwAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAAAAcAAAAPAAwEBwMAAA8AAvD/AgAAMAAI 8AgAAAADAAAAAgwAAA8AA/DnAgAADwAE8CgAAAABAAnwEAAAAF8AXwBfAF8AXwBfAF8AIAACAArw CAAAAAAMAAAFAAAADwAE8OAAAAASAArwCAAAAAEMAAAgAgAAAwEL8HAAAAAEAAAAAAB/AAEA7wGA AKhlS4WBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAAABgD/ARAA EQABAwIEAAA/AwAACACAwxAAAAC/AwAAAgBUAGkAdABsAGUAIAAxAAAAAAAQ8AgAAACtACABYBV9 Aw8AEfAcAAAAAADDCwgAAAD/////DQD5vwAAHwQEAAAAAgAAAA8ADfAcAAAAAACfDwQAAAAAAAAA AACoDwgAAABJc3N1ZSAjMg8ABPDHAQAAEgAK8AgAAAACDAAAIAIAABMBC/CSAAAABAAAAAAAfwAB AO8BgADoo2SEgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYA vwEBAAEA/wEQABEAAQMDBAAAPwMAAAgAgMMsAAAAvwMAAAIAQwBvAG4AdABlAG4AdAAgAFAAbABh AGMAZQBoAG8AbABkAGUAcgAgADIAAAAAABDwCAAAAPADIAFgFRMPDwAR8BwAAAAAAMMLCAAAAP// //8TAPm/AAAfBAQAAAADAAAADwAN8OEAAAAAAJ8PBAAAAAEAAAAAAKgPkwAAAEFkZCBwYWdpbmF0 aW9uIGNhcGFiaWxpdHkgdG8gcGx1cmFsIFJlc291cmNlIGF0dHJpYnV0ZXMNDVVzZXIgR3JvdXAg cmV0cmlldmFsIGNvdWxkIGJlIHJlc291cmNlIGludGVuc2l2ZSwgaGVuY2Ugc3VwcG9ydCBhdHRy aWJ1dGUgbGV2ZWwgcGFnaW5hdGlvbgAAoQ8kAAAAlAAAAAAAAQAAAAIAOAAAAAQAAgAEABgAXAAA AAAEAgAABBgAAACmDwYAAAAIAAAAAAAQAPAHIAAAAP///wAAAAAA7uzhAB9JfQBPgb0AwFBNAAAA /wCAAIAAAAAiBAgAAAABAAAAAgAAAA8A7gOHAwAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAA AAcAAAAPAAwEJwMAAA8AAvAfAwAAQAAI8AgAAAADAAAAAhAAAA8AA/AHAwAADwAE8CgAAAABAAnw EAAAAF8AXwAgAF8AXwBfAF8AXwACAArwCAAAAAAQAAAFAAAADwAE8OAAAAASAArwCAAAAAEQAAAg AgAAAwEL8HAAAAAEAAAAAAB/AAEA7wGAAGhrQYWBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAA AACHAAEAAACIAAAAAAC/AAAABgD/ARAAEQABAwIEAAA/AwAACACAwxAAAAC/AwAAAgBUAGkAdABs AGUAIAAxAAAAAAAQ8AgAAACtACABYBV9Aw8AEfAcAAAAAADDCwgAAAD/////DQD5vwAAHwQEAAAA AgAAAA8ADfAcAAAAAACfDwQAAAAAAAAAAACoDwgAAABJc3N1ZSAjOQ8ABPDnAQAAEgAK8AgAAAAC EAAAIAIAABMBC/CSAAAABAAAAAAAfwABAO8BgACYDUKFgQAwZQEAggCYsgAAgwAwZQEAhACYsgAA hQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYAvwEBAAEA/wEQABEAAQMDBAAAPwMAAAgAgMMsAAAAvwMA AAIAQwBvAG4AdABlAG4AdAAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAAAABDwCAAAAPAD IAFgFRMPDwAR8BwAAAAAAMMLCAAAAP////8TAPm/AAAfBAQAAAADAAAADwAN8AEBAAAAAJ8PBAAA AAEAAAAAAKgPkQAAAEFkZCBhYmlsaXR5IHRvIG1hcmsgYXR0cmlidXRlcyBhcyB1bmlxdWUgaW4g dGhlIHNjaGVtYXMNDUFkZCBhYmlsaXR5IHRvIG1hcmsgYXR0cmlidXRlcyBhcyB1bmlxdWUgaW4g U2VydmljZVByb3ZpZGVyQ29uZmlnIChvciB1bmlxdWUgaW4gU2NoZW1hPykAAKEPJAAAAJIAAAAA AAEAAAACADgAAAAEAAIABAAYAFoAAAAABAIAAAQYAAAAqg8aAAAAZQAAAAAAAAAVAAAAAQAAAAMA GAAAAAAAAAAAAKYPBgAAAAgAAAAAABAA8AcgAAAA////AAAAAADu7OEAH0l9AE+BvQDAUE0AAAD/ AIAAgAAAACIECAAAAAEAAAACAAAADwDuA6cDAAACAO8DGAAAABAAAAAAAAAAAAAAAAAAAIAAAAAA BwAAAA8ADARHAwAADwAC8D8DAABQAAjwCAAAAAMAAAACFAAADwAD8CcDAAAPAATwKAAAAAEACfAQ AAAAbwByACAAdQBuAGkAcQB1AAIACvAIAAAAABQAAAUAAAAPAATw4QAAABIACvAIAAAAARQAACAC AAADAQvwcAAAAAQAAAAAAH8AAQDvAYAA+N1hhIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAA AIcAAQAAAIgAAAAAAL8AAAAGAP8BEAARAAEDAgQAAD8DAAAIAIDDEAAAAL8DAAACAFQAaQB0AGwA ZQAgADEAAAAAABDwCAAAAK0AIAFgFX0DDwAR8BwAAAAAAMMLCAAAAP////8NAPm/AAAfBAQAAAAC AAAADwAN8B0AAAAAAJ8PBAAAAAAAAAAAAKgPCQAAAElzc3VlICMxMA8ABPAGAgAAEgAK8AgAAAAC FAAAIAIAABMBC/CSAAAABAAAAAAAfwABAO8BgAA4DUKFgQAwZQEAggCYsgAAgwAwZQEAhACYsgAA hQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYAvwEBAAEA/wEQABEAAQMDBAAAPwMAAAgAgMMsAAAAvwMA AAIAQwBvAG4AdABlAG4AdAAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAAAABDwCAAAAPAD IAFgFRMPDwAR8BwAAAAAAMMLCAAAAP////8TAPm/AAAfBAQAAAADAAAADwAN8CABAAAAAJ8PBAAA AAEAAAAAAKgPsAAAAEFkZCBhYmlsaXR5IHRvIG1hcmsgYXR0cmlidXRlcyBhcyBzZW5zaXRpdmUg aW4gdGhlIHNjaGVtYXMNDUFkZCBhYmlsaXR5IHRvIG1hcmsgYXR0cmlidXRlcyBhcyBzZW5zaXRp dmUgaW4gU2VydmljZVByb3ZpZGVyQ29uZmlnIChvciBzZW5zaXRpdmUgaW4gU2NoZW1hPykNVXNl IHRoaXMgZm9yIHBhc3N3b3JkAAChDyQAAACxAAAAAAABAAAAAgA7AAAABAACAAQAGAB2AAAAAAQC AAAEGAAAAKoPGgAAAGsAAAAAAAAAFQAAAAEAAAADADEAAAAAAAAAAACmDwYAAAAIAAAAAAAQAPAH IAAAAP///wAAAAAA7uzhAB9JfQBPgb0AwFBNAAAA/wCAAIAAAAAiBAgAAAABAAAAAgAAAA8A7gMv AwAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAAAAcAAAAPAAwEzwIAAA8AAvDHAgAAYAAI8AgA AAADAAAAAhgAAA8AA/CvAgAADwAE8CgAAAABAAnwEAAAACAAIABfAF8AIABfAF8AXwACAArwCAAA AAAYAAAFAAAADwAE8OEAAAASAArwCAAAAAEYAAAgAgAAAwEL8HAAAAAEAAAAAAB/AAEA7wGAANgI YoSBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAAABgD/ARAAEQAB AwIEAAA/AwAACACAwxAAAAC/AwAAAgBUAGkAdABsAGUAIAAxAAAAAAAQ8AgAAACtACABYBV9Aw8A EfAcAAAAAADDCwgAAAD/////DQD5vwAAHwQEAAAAAgAAAA8ADfAdAAAAAACfDwQAAAAAAAAAAACo DwkAAABJc3N1ZSAjMTMPAATwjgEAABIACvAIAAAAAhgAACACAAATAQvwkgAAAAQAAAAAAH8AAQDv AYAAaCxihIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAL8B AQABAP8BEAARAAEDAwQAAD8DAAAIAIDDLAAAAL8DAAACAEMAbwBuAHQAZQBuAHQAIABQAGwAYQBj AGUAaABvAGwAZABlAHIAIAAyAAAAAAAQ8AgAAADwAyABYBUTDw8AEfAcAAAAAADDCwgAAAD///// EwD5vwAAHwQEAAAAAwAAAA8ADfCoAAAAAACfDwQAAAABAAAAAACoDzgAAABBZGQgYSAicmVxdWly ZWQiIGZsYWcgaW4gY29uZmlndXJhdGlvbiB0byBzdXBwb3J0IGV0YWdzDQAAoQ8kAAAAOQAAAAAA AQAAAAIAOAAAAAQAAgAEABgAAQAAAAAEAgAABBgAAACqDxoAAAAyAAAAAAAAAAUAAAABAAAAAwAC AAAAAAAAAAAApg8GAAAACAAAAAAAEADwByAAAAD///8AAAAAAO7s4QAfSX0AT4G9AMBQTQAAAP8A gACAAAAAIgQIAAAAAQAAAAIAAAAPAO4DWQQAAAIA7wMYAAAAEAAAAAAAAAAAAAAAAAAAgAAAAAAH AAAADwAMBPkDAAAPAALw8QMAAHAACPAIAAAAAwAAAAIcAAAPAAPw2QMAAA8ABPAoAAAAAQAJ8BAA AAABAAAAAQAAAP7///8AAAAAAgAK8AgAAAAAHAAABQAAAA8ABPDhAAAAEgAK8AgAAAABHAAAIAIA AAMBC/BwAAAABAAAAAAAfwABAO8BgABoHc6EgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAA hwABAAAAiAAAAAAAvwAAAAYA/wEQABEAAQMCBAAAPwMAAAgAgMMQAAAAvwMAAAIAVABpAHQAbABl ACAAMQAAAAAAEPAIAAAArQAgAWAVfQMPABHwHAAAAAAAwwsIAAAA/////w0A+b8AAB8EBAAAAAIA AAAPAA3wHQAAAAAAnw8EAAAAAAAAAAAAqA8JAAAASXNzdWUgIzI0DwAE8LgCAAASAArwCAAAAAIc AAAgAgAAEwEL8JIAAAAEAAAAAAB/AAEA7wGAAPgsYoSBADBlAQCCAJiyAACDADBlAQCEAJiyAACF AAAAAACHAAAAAACIAAAAAAC/AAAABgC/AQEAAQD/ARAAEQABAwMEAAA/AwAACACAwywAAAC/AwAA AgBDAG8AbgB0AGUAbgB0ACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAAAAAAEPAIAAAA8AMg AWAVEw8PABHwHAAAAAAAwwsIAAAA/////xMA+b8AAB8EBAAAAAMAAAAPAA3w0gEAAAAAnw8EAAAA AQAAAAAAqA+EAQAAQWRkIHRoZSBuZWdhdGlvbiBvcGVyYXRvciB0byB0aGUgRmlsdGVyaW5nIHNl Y3Rpb24NDUknbSByZWFkaW5nIHRoZSAzLjIuMi4xLiBGaWx0ZXJpbmcgc2VjdGlvbiBpbiB0aGUg QVBJIHNwZWNpZmljYXRpb24gYW5kIEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBiZWNhdXNlIEkgbWlz cyBzb21lIGZpbHRlciBvcGVyYXRvcnMuIEkgbm90aWNlZCB0aGUgcHJpb3JpdHkgaXMgbm90IG9u IHRoZSBmaWx0ZXJpbmcgbm93IGFuZCB0aGUgc3BlY2lmaWNhdGlvbnMgc3RhdGVzICJQcm92aWRl cnMgTUFZIHN1cHBvcnQgYWRkaXRpb25hbCBmaWx0ZXIgb3BlcmF0aW9ucyBpZiB0aGV5IGNob29z ZS4iIHNvIEl0J3MgYWxsIGZpbmUgYnV0IHdoYXQgSSBtaXNzIGlzIHRoZSB3YXkgdG8gbmVnYXRl LgAAoQ8kAAAAhQEAAAAAAQAAAAIANAAAAAQAAgAEABgAUQEAAAAEAgAABBgAAACmDwYAAAAIAAAA AAAQAPAHIAAAAP///wAAAAAA7uzhAB9JfQBPgb0AwFBNAAAA/wCAAIAAAAAiBAgAAAABAAAAAgAA AA8A7gP5AwAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAAAAcAAAAPAAwEmQMAAA8AAvCRAwAA gAAI8AgAAAADAAAAAiAAAA8AA/B5AwAADwAE8CgAAAABAAnwEAAAAAEAAAABAAAA/v///wAAAAAC AArwCAAAAAAgAAAFAAAADwAE8OEAAAASAArwCAAAAAEgAAAgAgAAAwEL8HAAAAAEAAAAAAB/AAEA 7wGAAEgGa4SBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAAABgD/ ARAAEQABAwIEAAA/AwAACACAwxAAAAC/AwAAAgBUAGkAdABsAGUAIAAxAAAAAAAQ8AgAAACtACAB YBV9Aw8AEfAcAAAAAADDCwgAAAD/////DQD5vwAAHwQEAAAAAgAAAA8ADfAdAAAAAACfDwQAAAAA AAAAAACoDwkAAABJc3N1ZSAjMzQPAATwWAIAABIACvAIAAAAAiAAACACAAATAQvwkgAAAAQAAAAA AH8AAQDvAYAA2AVChYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8A AAAGAL8BAQABAP8BEAARAAEDAwQAAD8DAAAIAIDDLAAAAL8DAAACAEMAbwBuAHQAZQBuAHQAIABQ AGwAYQBjAGUAaABvAGwAZABlAHIAIAAyAAAAAAAQ8AgAAADwAyABYBUTDw8AEfAcAAAAAADDCwgA AAD/////EwD5vwAAHwQEAAAAAwAAAA8ADfByAQAAAACfDwQAAAABAAAAAACoDyQBAABSZXNvdXJj ZSBTY2hlbWEgUmVwcmVzZW50YXRpb24gc2hvdWxkIGJlIG5vbi1ub3JtYXRpdmUNDVRoZSBKU09O IHNjaGVtYSByZXByZXNlbnRhdGlvbiBpbiAiMTEuNi4gUmVzb3VyY2UgU2NoZW1hIFJlcHJlc2Vu dGF0aW9uIiBkb2Vzbid0IGFwcGVhciB0byBiZSAibm9ybWF0aXZlIiBhcyBpbmRpY2F0ZWQsIHNp bmNlIGl0IG1lcmVseSBwcm92aWRlcyBhbiBleGFtcGxlIFNjaGVtYSByZXNvdXJjZSBmb3IgYSBV c2VyLg1UaGlzIHNob3VsZCBiZSBsYWJlbGVkIGFzIGEgIm5vbi1ub3JtYXRpdmUiIGV4YW1wbGUu AAChDyQAAAAlAQAAAAABAAAAAgA4AAAABAACAAQAGADtAAAAAAQCAAAEGAAAAKYPBgAAAAgAAAAA ABAA8AcgAAAA////AAAAAADu7OEAH0l9AE+BvQDAUE0AAAD/AIAAgAAAACIECAAAAAEAAAACAAAA DwDuA40GAAACAO8DGAAAABAAAAAAAAAAAAAAAAAAAIAAAAAABwAAAA8ADAQtBgAADwAC8CUGAACQ AAjwCAAAAAMAAAACJAAADwAD8A0GAAAPAATwKAAAAAEACfAQAAAAAQAAAAEAAAD+////AAAAAAIA CvAIAAAAACQAAAUAAAAPAATw4QAAABIACvAIAAAAASQAACACAAADAQvwcAAAAAQAAAAAAH8AAQDv AYAASH5ghIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAQAAAIgAAAAAAL8AAAAGAP8B EAARAAEDAgQAAD8DAAAIAIDDEAAAAL8DAAACAFQAaQB0AGwAZQAgADEAAAAAABDwCAAAAK0AIAFg FX0DDwAR8BwAAAAAAMMLCAAAAP////8NAPm/AAAfBAQAAAACAAAADwAN8B0AAAAAAJ8PBAAAAAAA AAAAAKgPCQAAAElzc3VlICMzNQ8ABPDsBAAAEgAK8AgAAAACJAAAIAIAABMBC/CSAAAABAAAAAAA fwABAO8BgACIEE96gQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAA AAYAvwEBAAEA/wEQABEAAQMDBAAAPwMAAAgAgMMsAAAAvwMAAAIAQwBvAG4AdABlAG4AdAAgAFAA bABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAAAABDwCAAAAPADIAFgFRMPDwAR8BwAAAAAAMMLCAAA AP////8TAPm/AAAfBAQAAAADAAAADwAN8AYEAAAAAJ8PBAAAAAEAAAAAAKAPbAIAAEMAYQBuAG8A bgBpAGMAYQBsACAAdAB5AHAAZQBzACAAZgBvAHIAIABHAHIAbwB1AHAAIABtAGUAbQBiAGUAcgBz ACAAcwBoAG8AdQBsAGQAIABuAG8AdAAgAGIAZQAgAFIARQBBAEQALQBPAE4ATABZAA0ADQBTAGUA ZQAgAHQAaABlACAAZQBtAGEAaQBsACAAdABoAHIAZQBhAGQAIABoAGUAcgBlADoADQALIGgAdAB0 AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYA ZQAvAHcAZQBiAC8AcwBjAGkAbQAvAGMAdQByAHIAZQBuAHQALwBtAHMAZwAwADAAOQAyADkALgBo AHQAbQBsAA0ADQBCAGEAcwBpAGMAYQBsAGwAeQAsACAAdABoAGUAIABjAGEAbgBvAG4AaQBjAGEA bAAgAHQAeQBwAGUAcwAgAGYAbwByACAARwByAG8AdQBwACAAbQBlAG0AYgBlAHIAcwAgAHMAaABv AHUAbABkACAAYgBlACAAbQBhAHIAawBlAGQAIABhAHMAIAAiAGkAbQBtAHUAdABhAGIAbABlACIA IABpAG4AcwB0AGUAYQBkACAAbwBmACAAcgBlAGEAZAAtAG8AbgBsAHkAIABzAGkAbgBjAGUAIAB0 AGgAZQB5ACAAYwBhAG4AIABiAGUAIABzAHAAZQBjAGkAZgBpAGUAZAAgAHcAaABlAG4AIABpAG4A cwBlAHIAdABpAG4AZwAgAG4AZQB3ACAAZQBsAGUAbQBlAG4AdABzAC4AAAChDzwAAAA3AQAAAAAB AAAAAgA7AAAABAACAAQAGAAcAAAAAAQCAAAEGABBAAAAAAgCAAAIFACfAAAAAAwCAAAMGAAAAKoP PAAAAFcAAAAAAAAABwAAAAAAAAAMAAAAAQAAAAMAEgAAAAAAAAAEAAAAAQAAAAMAFgAAAAAAAACh AAAAAAAAAA8A8g8YAAAAAADzDxAAAAAAAAAANAAAAAQAAAAInDsAAADfDwgAAABXAAAAXgAAAA8A 8g8YAAAAAADzDxAAAAAAAAAANgAAAAQAAAAInDsAAADfDwgAAABeAAAAagAAAA8A8g8YAAAAAADz DxAAAAAAAAAAOAAAAAQAAAAInDsAAADfDwgAAABqAAAAfAAAAA8A8g8YAAAAAADzDxAAAAAAAAAA OgAAAAQAAAAInDsAAADfDwgAAAB8AAAAgAAAAA8A8g8YAAAAAADzDxAAAAAAAAAAPAAAAAQAAAAI nDsAAADfDwgAAACAAAAAlgAAAAAApg8GAAAACAAAAAAAEADwByAAAAD///8AAAAAAO7s4QAfSX0A T4G9AMBQTQAAAP8AgACAAAAAIgQIAAAAAQAAAAIAAAAPAO4DzQ8AAAIA7wMYAAAAEAAAAAAAAAAA AAAAAAAAgAAAAAAHAAAADwAMBG0PAAAPAALwZQ8AAKAACPAIAAAAAwAAAAIoAAAPAAPwTQ8AAA8A BPAoAAAAAQAJ8BAAAAABAAAAAQAAAP3///8AAAAAAgAK8AgAAAAAKAAABQAAAA8ABPDhAAAAEgAK 8AgAAAABKAAAIAIAAAMBC/BwAAAABAAAAAAAfwABAO8BgAAof2CEgQAwZQEAggCYsgAAgwAwZQEA hACYsgAAhQAAAAAAhwABAAAAiAAAAAAAvwAAAAYA/wEQABEAAQMCBAAAPwMAAAgAgMMQAAAAvwMA AAIAVABpAHQAbABlACAAMQAAAAAAEPAIAAAArQAgAWAVfQMPABHwHAAAAAAAwwsIAAAA/////w0A +b8AAB8EBAAAAAIAAAAPAA3wHQAAAAAAnw8EAAAAAAAAAAAAqA8JAAAASXNzdWUgIzM3DwAE8CwO AAASAArwCAAAAAIoAAAgAgAAEwEL8JIAAAAEAAAAAAB/AAEA7wGAADhrQoWBADBlAQCCAJiyAACD ADBlAQCEAJiyAACFAAAAAACHAAAAAACIAAAAAAC/AAAABgC/AQEAAQD/ARAAEQABAwMEAAA/AwAA CACAwywAAAC/AwAAAgBDAG8AbgB0AGUAbgB0ACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAA ABMAIvH3CAAAqcPxCAAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Z q/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4 DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqW qfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvE rwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAAL AAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TL oEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQx MJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ 3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsD BBQABgAIAAAAIQAQrJ9GiQQAALklAAAQAAAAZHJzL3NoYXBleG1sLnhtbOxa70/jNhj+Pmn/g+Wv J67QFW6tCCdAYpuEUEW5z8hNXMjh2JHtMOCv3/PacZugTcfdpgFVIrV5f9mxn9dP3sTt4eeHSrF7 aV1pdMb3Pu5yJnVuilLfZPzL1dnOr5w5L3QhlNEy44/S8c9HP/90WM9czdBYu1md8Vvv69lo5PJb WQn30dRSw7cythIeqr0Z1VY6qb3wuFClRuPd3YNRJUrNj9CVvl/Uc0tSfnE/t6wsMv4LZ1pUuOSp 0R4t2VyJXN4aVUjLxnzURseGAqM5N/mda4ckXjKkwoo/Mc/eaJg2v1lMaI8uMArjSUPTGBldtL7F +B4yPhlPJ9ODT+PpfhsbA9BoMx2HaYWR+ocTUzweHYrZEmdMMUL34+NEzjwmaewTZ+oP7TI+3ZtM kD4flMn+pzEU2/Usex6vTo3K+C4SIGYamTpuvFmVnq2A9yIXCtBPx/u76EXpRZ1fyqLJKXsZR/Jg JoDSdKgP5fzCPyr5b6eGfsUsra0fBih0ApwrYc9pliRcBkHdh2mzUhdYVsEk1A2mpTgr5OpKLBdP yC4BSAj6GC3FuT6xd7QyAkLHoYkAZsAHq1q3bjS5FfoG62re6Bzd7wWAA4Q0Jlfn89yze4Fu9wjH BGQ34kSunsd2MUcfm4jjlU+x3sV+U5eIa73L5lTZq4cA7bJZPK3FMySb+cdarkCujB/bUijKLBLb XIDxQfRiee58EAHQZVjSSH2grJiBFPgC1HdNVVbmaxlRBggZl3rnywJ3EAA6PiA4l8EZQ5qMO31D 9xdb3uHi2iyCxNmdtHQ3CgnIBeioMRQE1nloTqtVqPJJ/h7UpXBSlXR3wgW0mVtjVkEuSusfg+Qq f6qkQKdxvStNg9bmrFQK88JkosUZVRZkDJDS3UwCuIiqf4g3BeSwGyVXK5n7hE9zrltsG+qmlcMC 6cD8odI7ykecpXjmkCI6cvfMkbuWcwCbxueP2DUd3e+kstZKp+hvI5PSBkSVAMAqwjc6psxS9wMF AUKXrm+XglIXc2EFmPktEk5ej4S0pt437zYwDyyJ3NiUoXVRe7sseWmh+juOtAVoqFTpSYFK2HdX qmsWj1iTgkxliY5NXQoyqShRdAR3GxIUfEVjx4Ww5KOWyUNnfJLaU6Jx40qByULn9Ok2DENaB0HY BMULdXQYWK+4vvxx6VVXobQ2POlu6XMTraaYq/eYnC1NyoY2Gylxiyw9Dga9ZyIl8H4dG90U2ekw pp2MOGIoCb11MDwB03PvUNuHt1Axe/FbaCBU5NT/wqa0QfOP+zo7KWLY3Wl3dz5UX9fbDsuG9vsu mipsMmQcr4/LMp9LW5oi7j/8N7s+r/oYs8WVcl27UMNSGUti1JM1usm3tpApKa01neIzd3KmqKAP tH6bm7YDrbdoNzcxD+eOmJRkCsW2DWF9Xg5vmGn//vV35vspvO69ZLyTPG1zCSUWtRtMkVgto4I9 Um7g1tv71YuyRikKx8Cpt/Nr5HvMxfbvdLZcodN7TNA2F6DNbYzuZUnrZSnuReJPRekfRBBdffQX AAAA//8DAFBLAwQUAAYACAAAACEAgtrKaNoAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPS0vD QBSF94L/YbiCm2InpviKnRYRJFoQ+3Lh7jZzm4Rm7sSZaZL+ewcXujycw3f4pvPBNKIj52vLCq7H CQjiwuqaSwXbzcvVPQgfkDU2lknBiTzMZ+dnU8y07XlF3TqUIkLYZ6igCqHNpPRFRQb92LbEsdtb ZzDE6EqpHfYRbhqZJsmtNFhzfKiwpeeKisP6aBSMtvnmeHdY5u/ue/K5+Gj7m260VOryYnh6BBFo CP/jh3T39pX+lb+oV61gAmKfn3au1iv0gZyC6BZNoyXI2Q8AAAD//wMAUEsBAi0AFAAGAAgAAAAh ADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU AAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAU AAYACAAAACEAEKyfRokEAAC5JQAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBL AQItABQABgAIAAAAIQCC2spo2gAAAPkAAAAPAAAAAAAAAAAAAAAAAN8GAABkcnMvZG93bnJldi54 bWxQSwUGAAAAAAQABAD1AAAA5gcAAAAAAAAQ8AgAAADwAyABYBUTDw8AEfCKAAAAAADDCwgAAAD/ ////EwD5vw8AiBNmAAAADwCKE14AAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLE0AAAAAAAKwP OAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAP//wEAAwABAAAAAAAA AAAAAAAfBAQAAAADAAAADwAN8NkDAAAAAJ8PBAAAAAEAAAAAAKgPBwMAAERlZmluZSBlcnJvciBy ZXNwb25zZSB3aGVuIGEgc2VydmVyIGlzIHVud2lsbGluZyB0byBwZXJmb3JtIGEgbGlzdC9xdWVy eQ0NU2VjdGlvbiAzLjIuMiBvZiB0aGUgQVBJIGRvY3VtZW50IGRlZmluZXMgaG93IHRvIHVzZSBh IEdFVCBvcGVyYXRpb24gdG8gbGlzdCBvciBxdWVyeSByZXNvdXJjZXMuIEluIHNvbWUgY2FzZXMs IHNlcnZlcnMgbWF5IGJlIHVud2lsbGluZyB0byBwZXJmb3JtIHRoZXNlIG9wZXJhdGlvbnMgaWYg dGhlIHJlc3VsdHMgYXJlIHRvbyBsYXJnZSB0byByZXR1cm4uIEZvciBleGFtcGxlLCBpZiB0aGUg Y2xpZW50IGRvZXMgbm90IHNwZWNpZnkgYSBzdGFydEluZGV4IGFuZCBjb3VudCB0aGUgc2VydmVy IG1heSBiZSBhc2tlZCB0byByZXR1cm4gbWlsbGlvbnMgb2YgcmVzb3VyY2VzLiBUaGlzIGNvdWxk IGNhdXNlIHNlcnZlciBhbmQgbmV0d29yayBwZXJmb3JtYW5jZSBwcm9ibGVtcy4NUmVjb21tZW5k YXRpb24gdG86DUFsbG93IHNlcnZlcnMgdG8gcmVzcG9uZCB0byBsaXN0L3F1ZXJ5IHJlcXVlc3Rz IHdpdGggYW4gInVud2lsbGluZyB0byBwZXJmb3JtIiBlcnJvciAobWF5YmUgYSA0MDMgRm9yYmlk ZGVuIHN0YXR1cyBjb2RlKQ1BbGxvdyBzZXJ2ZXJzIHRvIHB1Ymxpc2ggbGlzdC9xdWVyeSByZXN0 cmljdGlvbnMgaW4gdGhlIC9TZXJ2aWNlUHJvdmlkZXJDb25maWcgcmVzb3VyY2UuIFRoZXNlIG1p Z2h0IGJlIHNpbWlsYXIgdG8gdGhlIG1heE9wZXJhdGlvbnMvbWF4UGF5bG9hZFNpemUgYnVsayBj b25maWd1cmF0aW9uIG9wdGlvbnMAAKEPUAAAAOABAAAAAAEQAAACAFAAKAEAAAAAkhAAAAMAIiAA AFAASQAAAAQAAgAEABgAAQAAAAQEAgAEBBYAlgEAAAAIAgAACBYAKAEAAAAMAgAADBYAAACqD1AA AABFAQAAAAAAAAoAAAABAAAAAwBDAQAAAAAAABUAAAABAAAAAwApAAAAAAAAAA0AAAABAAAAAwAB AAAAAAAAAA4AAAABAAAAAwAcAAAAAAAAAAAApg8GAAAACAAAAAAAEADwByAAAAD///8AAAAAAO7s 4QAfSX0AT4G9AMBQTQAAAP8AgACAAAAAIgQIAAAAAQAAAAIAAAAPAO4DuAMAAAIA7wMYAAAAEAAA AAAAAAAAAAAAAAAAgAAAAAAHAAAADwAMBFgDAAAPAALwUAMAALAACPAIAAAAAwAAAAIsAAAPAAPw OAMAAA8ABPAoAAAAAQAJ8BAAAABfAF8AAAAGAHpTbU0MAAAAAgAK8AgAAAAALAAABQAAAA8ABPDh AAAAEgAK8AgAAAABLAAAIAIAAAMBC/BwAAAABAAAAAAAfwABAO8BgABoTWCEgQAwZQEAggCYsgAA gwAwZQEAhACYsgAAhQAAAAAAhwABAAAAiAAAAAAAvwAAAAYA/wEQABEAAQMCBAAAPwMAAAgAgMMQ AAAAvwMAAAIAVABpAHQAbABlACAAMQAAAAAAEPAIAAAArQAgAWAVfQMPABHwHAAAAAAAwwsIAAAA /////w0A+b8AAB8EBAAAAAIAAAAPAA3wHQAAAAAAnw8EAAAAAAAAAAAAqA8JAAAASXNzdWUgIzM5 DwAE8BcCAAASAArwCAAAAAIsAAAgAgAAEwEL8JIAAAAEAAAAAAB/AAEA7wGAAIgvQoWBADBlAQCC AJiyAACDADBlAQCEAJiyAACFAAAAAACHAAAAAACIAAAAAAC/AAAABgC/AQEAAQD/ARAAEQABAwME AAA/AwAACACAwywAAAC/AwAAAgBDAG8AbgB0AGUAbgB0ACAAUABsAGEAYwBlAGgAbwBsAGQAZQBy ACAAMgAAAAAAEPAIAAAA8AMgAWAVEw8PABHwHAAAAAAAwwsIAAAA/////xMA+b8AAB8EBAAAAAMA AAAPAA3wMQEAAAAAnw8EAAAAAQAAAAAAqA/jAAAAQ2xhcmlmaWNhdGlvbiBvbiByZXNwb25zZSBi b2R5IGZvciBERUxFVEUNDVNob3VsZCB0aGUgcmVzb3VyY2UgYmUgcmV0dXJuZWQgYXMgcGFydCBv ZiB0aGUgcmVzcG9uc2UgYm9keSBmb3IgYSBERUxFVEU/DVNlY3Rpb24gIjMuNCBEZWxldGluZyBS ZXNvdXJjZXMiIG9ubHkgbWVudGlvbnMgdGhlIHJldHVybiBjb2RlcywgYnV0IG5vdCB3aGF0IHNo b3VsZCBiZSBpbiB0aGUgcmVzcG9uc2UgYm9keS4AAKEPJAAAAOQAAAAAAAEAAAACACsAAAAEAAIA BAAYALkAAAAABAIAAAQYAAAApg8GAAAACAAAAAAAEADwByAAAAD///8AAAAAAO7s4QAfSX0AT4G9 AMBQTQAAAP8AgACAAAAAIgQIAAAAAQAAAAIAAAAPAO4D4hAAAAIA7wMYAAAAEAAAAAAAAAAAAAAA AAAAgAAAAAAHAAAADwAMBIIQAAAPAALwehAAAMAACPAIAAAAAwAAAAIwAAAPAAPwYhAAAA8ABPAo AAAAAQAJ8BAAAABuACAAIgAzAC4ANAAgAEQAAgAK8AgAAAAAMAAABQAAAA8ABPDhAAAAEgAK8AgA AAABMAAAIAIAAAMBC/BwAAAABAAAAAAAfwABAO8BgABYN0KFgQAwZQEAggCYsgAAgwAwZQEAhACY sgAAhQAAAAAAhwABAAAAiAAAAAAAvwAAAAYA/wEQABEAAQMCBAAAPwMAAAgAgMMQAAAAvwMAAAIA VABpAHQAbABlACAAMQAAAAAAEPAIAAAArQAgAWAVfQMPABHwHAAAAAAAwwsIAAAA/////w0A+b8A AB8EBAAAAAIAAAAPAA3wHQAAAAAAnw8EAAAAAAAAAAAAqA8JAAAASXNzdWUgIzQyDwAE8EEPAAAS AArwCAAAAAIwAAAgAgAAEwEL8JIAAAAEAAAAAAB/AAEA7wGAAKiuQYWBADBlAQCCAJiyAACDADBl AQCEAJiyAACFAAAAAACHAAAAAACIAAAAAAC/AAAABgC/AQEAAQD/ARAAEQABAwMEAAA/AwAACACA wywAAAC/AwAAAgBDAG8AbgB0AGUAbgB0ACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAAABMA IvG5CgAAqcOzCgAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNd LnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2 GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJ Jl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmV SzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3 V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAA X3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/ 0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaS tlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3Pfe PqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQA BgAIAAAAIQAvMDih4wQAABw4AAAQAAAAZHJzL3NoYXBleG1sLnhtbOxbXU/jOBR9X2n/Q5TXFVPo lpklIoyAFbsjoVFFmWfkJg7N1rEj22GBXz/n2kmbVitR4KG06zzUjr9in3uP782Ne/r1sRLRA9em VDKNjz4dxhGXmcpLeZ/GP26vDv6II2OZzJlQkqfxEzfx17NffzmtE1NH6CxNUqfxzNo6GQxMNuMV M59UzSXqCqUrZnGr7we15oZLyyweVInB8PDw86BipYzPMJR8mNRjTbns+8NYR2Wexr/HkWQVHnmp pEXPaCxYxmdK5FxHw3jQtvYdGWZzrbK5aafENplSrtm/WOfKbCKp/tJY0BE9YODm001NYmb00HqG +T2m8Wh4Mjr5/GV4cty29Q3Qabkcg2W5mdrHC5U/nZ2yZIoUS/TQvX2ekJnFIpV+jiPxTZo0Pjka jSA+625Gx1+GuNH9mulKjRWXSqTxIQTAEglJnTdWFaWNCuA9yZgA9CfD40OMIuSkzm543mQkvTSG 8FBMAHXLoTGEsRP7JPh7l4ZxWdLp1psBcoMA54rpa1olZW5cRjy4ZUelzKFWroiJeyxLxFHOi1s2 nTxDugQgIWh9a86u5YWek2Y4hM5dFwbMgA+0WrbV6DJj8h56NW5khuGPHMAOQpqTqbNxZqMHhmGP CMcOyH6LC16st+1jjjGWLc4L27W1xo/bDYl2be20uRT69tFBO20mz4vsFYQd2aeaFyBXGp/rkgmS LATbfAfjXday6bWxLguAbpxKQ/SOsiwBKfADqOdNVVbqn9KjDBDSmMuDHxPsIAB0+JngnLpK36RJ YyPvaX/R5RwPl2ricnE055p2IyeAjIGOElNBwzpz3UlbmSif+d/udsoMFyXtTniAVGOtVOHyeant k8uZyl4KzjCo13chadJSXZVCYF1YjC8xSpQ5FTpIaTfjAM6jah/9pgAZ9lvxouCZ7fBprmWLbUPD tHmnID2Yf6vkgbAeZ87WKjjzFZlZq8hMyzmATfOzZ9Gdv9q0n3RVd4sMrRKqgl/0JvHRGIFnAKHP yY/LMy7zMdMM9HuJaaPtMY10arfJtYQ5sMRzY2lrFpbr47JkU2v0XxxprUwwR507QHbqVebIG5vI XTBNne1B2mZ7JStFVO7romCnWodkUmfODel7ezvAwOUG+hY7FTjIkje4hEvQg9UKVguvU+Elyr2v bv4S1dqszkB15ohSb8+CXdptuxQ8ww8QqACZHJ0obhGtunqbR5K26rtzrV0QcE9DSiSYu7uVvW5H BLOnAoHxWZFGiNxRvC7EJEKInCWbe3cwNtjWFs4d7np2iExRG3ygNNAtOHrhi1T7RfDVIUByHzzZ Oo4F+9V9YgwRvfCRN403o1SI6JEd3vtTEVt9l93XVyayQZ0Vcjl33/P/yBMkj69NfHXvhkyXu1zi 872s79nrHkzcjpu4EBzcanCQuOVZ1rGuX7JkXuDZ/4Rn7ujf2mHB8Gn49Z+GWTLD0cj5pSizeXsw F+Hrl49rq6IoM/6nypoKh2T9cW3N6RyjkmZW1gYnYxM6pq2/5d2xyMWxROLwethy8yDyVkW/h9H9 banAYtdeiaftiB7skWe8FfkvhO/2AtoPdlELwm6w+P/Ouw3CLso/7AKDd8nd7QJEfu8QtF9Z1jRh Geh66bzgVj2DPdIFxNWWoHfnBfG/te5Pasia+uwnAAAA//8DAFBLAwQUAAYACAAAACEAa4dl1tYA AAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPS0sDMRSF94L/IVzBTWkzWtQy9raIICOC9On+Ormd GTpJxiTz8tcbXOjycA7f4VuuB12Ljp2vrEG4mSUg2ORWVaZAOB5epgsQPpBRVFvDCCN7WK8uL5aU KtubHXf7UIgIMT4lhDKEJpXS5yVr8jPbsIndyTpNIUZXSOWoj3Bdy9skuZeaKhMfSmr4ueT8vG81 wuSYHdqH8zZ7d1/zj7dN0991ky3i9dXw9Agi8BD+x988Jqr9K39RrwphDuKUjZ+uUjvygR1CdIum 0RLk6gcAAP//AwBQSwMEFAAGAAgAAAAhAFeD0O3qAAAAagEAABsAAABkcnMvX3JlbHMvc2hhcGV4 bWwueG1sLnJlbHOE0M1OwzAMB/A7Eu8Q+b6m3QEQarrLQNqBCxoPYFK3iZYvOdm6vT0BCcQkJI6W 5d/fdr85eydOxNnGoKBrWhAUdBxtmBW87Z9XDyBywTCii4EUXCjDZri96V/JYalD2diURVVCVmBK SY9SZm3IY25iolA7U2SPpZY8y4T6gDPJddveSf5twHBlit2ogHdjB2J/STX5fztOk9W0jfroKZQ/ IqSpEjsbDhVFnqn8sMuyNJbK9LWkR+tWyNrYE8mF3utB1kt9ZP50fZ7brl3fN6Z49w29xLHu+HQu xAEdyKGXVx8aPgAAAP//AwBQSwECLQAUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAAAAAAAAAAAA AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAA AAAAAAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAvMDih4wQAABw4AAAQAAAA AAAAAAAAAAAAACgCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAGuHZdbWAAAA+QAA AA8AAAAAAAAAAAAAAAAAOQcAAGRycy9kb3ducmV2LnhtbFBLAQItABQABgAIAAAAIQBXg9Dt6gAA AGoBAAAbAAAAAAAAAAAAAAAAADwIAABkcnMvX3JlbHMvc2hhcGV4bWwueG1sLnJlbHNQSwUGAAAA AAUABQA+AQAAXwkAAAAAAAAQ8AgAAADwAyABYBUTDw8AEfAcAAAAAADDCwgAAAD/////EwD5vwAA HwQEAAAAAwAAAA8ADfCaAwAAAACfDwQAAAABAAAAAACoD+wBAABDb25zaWRlciBtYWtpbmcgc2Vy dmVyIHJvb3Qgc2VhcmNoZXMgb3B0aW9uYWwNDUluIGlzc3VlICMyNSwgdGhlIGFiaWxpdHkgdG8g c2VhcmNoIGFnYWluc3QgdGhlIHNlcnZlciByb290IHdhcyBhZGRlZDoNDVF1ZXJpZXMgTUFZIGJl IHBlcmZvcm1lZCBhZ2FpbnN0IGEgU0NJTToNUmVzb3VyY2UgKGUuZy4gL1VzZXJzL3t1c2VyaWR9 KSwNUmVzb3VyY2UgVHlwZSBlbmRwb2ludCAoZS5nLiAvVXNlcnMgb3IgL0dyb3VwcyksIG9yDVNl cnZlciBSb290IChlLmcuIC8pLg0NSG93ZXZlciwgZm9yIHNvbWUgc2VydmljZSBwcm92aWRlcnMg aXQgbWF5IGJlIGRpZmZpY3VsdCB0byBwZXJmb3JtIGEgc2VydmVyIHJvb3QgcXVlcnkgdGhhdCBw ZXJmb3JtcyB3ZWxsIGF0IHNjYWxlLg1TZWUgdGhlIGRpc2N1c3Npb24gb24gdGhlIG1haWxpbmcg bGlzdCBoZXJlOg1odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2NpbS9jdXJy ZW50L21zZzAxMDI3Lmh0bWwAAKEPPgAAAO0BAAAAAAEQAAACAFAALgAAAAQAAgAEABgAAQAAAAQE AgAEBBYAfgEAAAAIAgAACBYAQAAAAAAMAgAADBQAAACqD04AAAC3AAAAAAAAAAYAAAABAAAAAwDw AAAAAAAAAAcAAAAAAAAADAAAAAEAAAADABIAAAAAAAAABAAAAAEAAAADABYAAAAAAAAAAQAAAAAA AAAPAPIPGAAAAAAA8w8QAAAAAAAAAD4AAAAEAAAACJw7AAAA3w8IAAAArQEAALQBAAAPAPIPGAAA AAAA8w8QAAAAAAAAAEAAAAAEAAAACJw7AAAA3w8IAAAAtAEAAMABAAAPAPIPGAAAAAAA8w8QAAAA AAAAAEIAAAAEAAAACJw7AAAA3w8IAAAAwAEAANIBAAAPAPIPGAAAAAAA8w8QAAAAAAAAAEQAAAAE AAAACJw7AAAA3w8IAAAA0gEAANYBAAAPAPIPGAAAAAAA8w8QAAAAAAAAAEYAAAAEAAAACJw7AAAA 3w8IAAAA1gEAAOwBAAAAAKYPBgAAAAgAAAAAABAA8AcgAAAA////AAAAAADu7OEAH0l9AE+BvQDA UE0AAAD/AIAAgAAAACIECAAAAAEAAAACAAAADwDuA30QAAACAO8DGAAAABAAAAAAAAAAAAAAAAAA AIAAAAAABwAAAA8ADAQdEAAADwAC8BUQAADQAAjwCAAAAAMAAAACNAAADwAD8P0PAAAPAATwKAAA AAEACfAQAAAAAF+3AgYAAADsekGFPwAAAAIACvAIAAAAADQAAAUAAAAPAATw4QAAABIACvAIAAAA ATQAACACAAADAQvwcAAAAAQAAAAAAH8AAQDvAYAAWDhChYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIA AIUAAAAAAIcAAQAAAIgAAAAAAL8AAAAGAP8BEAARAAEDAgQAAD8DAAAIAIDDEAAAAL8DAAACAFQA aQB0AGwAZQAgADEAAAAAABDwCAAAAK0AIAFgFX0DDwAR8BwAAAAAAMMLCAAAAP////8NAPm/AAAf BAQAAAACAAAADwAN8B0AAAAAAJ8PBAAAAAAAAAAAAKgPCQAAAElzc3VlICM0Ng8ABPDcDgAAEgAK 8AgAAAACNAAAIAIAABMBC/CSAAAABAAAAAAAfwABAO8BgADIhUKFgQAwZQEAggCYsgAAgwAwZQEA hACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYAvwEBAAEA/wEQABEAAQMDBAAAPwMAAAgAgMMs AAAAvwMAAAIAQwBvAG4AdABlAG4AdAAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAATACLx UQkAAKnDSwkAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54 bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1dhrV jIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwRSSZd SBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5lUs4 8glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L91e4 C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAACwAAAF9y ZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BBv9D3 Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCWkrZa ix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz33j6i ahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQUAAYA CAAAACEAAF79qeMEAAAvKwAAEAAAAGRycy9zaGFwZXhtbC54bWzsWlFP4zgQfj/p/oPl1xVb6Jbl qAgrQOLuJIQqyj4jN3Ehi2NHtsMBv35nxnaSVnfaLodYQKmqZDweT+xvPB5nnIMv95Vid9K60uiM 73zc5kzq3BSlvs7418vTrT84c17oQiijZcYfpONfDn//7aCeuppBY+2mdcZvvK+no5HLb2Ql3EdT Sw11S2Mr4aFor0e1lU5qLzw8qFKj8fb251ElSs0PQZW+m9czi1R+fjezrCwy/okzLSp45InRHlqy mRK5vDGqkJaN+ShKh4YCenNm8lsXuyQ26VJhxT8wzpXeMG3+tDCgHXzAiPqTuqahZ/jQ+gb6d5/x yXh/sv95b7y/G2WDADTqhuNgWNRTf39siofDAzFdwB2GGKB7ej/BZh4GaewjZ+pv7TK+vzOZgPk8 FSa7e2Mo2H7NYqXGqxOjMr4NBhBTDZY6arxZlp4tAe95LhRAv7e3uw1alJ7X+YUsmhytl3EwHrAR oDQc1KGcn/sHJf/v0ECvmKa59WSASAngXAl7hqNE4oIIdUfDZqUuYFoRS6hrGJbirJDLS7GYP4J1 EUBE0AdpKc70sb3FmUEIHVETAZgBPjCrdayGJjdCX8O8mjU6B/U7BDBBiH1ydT7LPbsToHYHcUxA 9iWO5XJdto856OgkjpY+yXoX9CaVIBdrF82Jspf3BO2imT+25CkYm/mHWi7BuTJ+ZEuh0LJg2OYc PJ5ILxZnzhMJAF3QlAbTk8uKKTgFXADq26YqK/OtDCgDCBmXeuvrHFYQAPQTjJazBVUGkSbjTl/j +mLLW3i4NnOiOLuVFlcjMkAuwB01dAUE65ya42wVqnyUf1FxIZxUJa5O8ABtZtaYJdFFaf0DUa7y J0oKUBrmu9LYaW1OS6VgXDCYwHFGlQUyCVJczSQAF1D192FRABv2peRyKXOf8GnOdMS2QTWRpgnS g/lDpbeUDzhLsVYhRajI3VpF7qLPAdjYP3/IrugXbrEAHKQ6HqNfTxCHC3MGrqAG7YjKBocDEPrO +XodTupiJqwAP/yBy40nv87lcE69bS/rYB68JPhGF3TaEPZ6vWTDsPSvPhLDzRCX0r4AA9bPxaX1 oBMCUhujiIgluIU/hq1etOrFsSSQmuGdaAxrsXEst+wk0DGIE4otEwlGFyLw8aiz/cViy2wJlGBs iKVx9zSvc9oz9bemb2CV6Bb5p8TSYZ0Q0yfsXzvQh8g6RFZ49xve+OjleqM3PgpAcEmBKN7x1pFd KfIwViUm68VBimIhlJFkd0naot6kJ9xT6epFAmDKxfxnCmcrSQyJnJjI+VB9azMMiwZTe+dNRfmE jMO746LMZ9KWpgiphmdJ8Aw76bV8zTNleMDXyN3SHUvE6Dw+OHdgpqokk6QHT32dKdfBU99PLhZ9 j/yvJTC0tqzoir1X3CD8Ei+RKUIOMRRONjY7DBk88714Ztjxtq7YEdEjkQFeGryRClQOXCSxhmrx Gv7IbdlUF/mJjg1aJUjAry8ViquC1HxVajV0b3zi9ms3ZNJaOix9p0dvZMurq5Wl+41Y5p1aZNVL hnNNPM18Uyc2XVpwyMViLv1FviXoQB9ysUMudsjF/tQpZ9rqhT1b3MfFwtreDrhYQZWBTiRy17YR nVP+aCWkT6TWPqoaTqWe6VQKPuVM320C6erD7wAAAP//AwBQSwMEFAAGAAgAAAAhAKw9Gd/aAAAA +QAAAA8AAABkcnMvZG93bnJldi54bWxEj01Lw0AURfeC/2F4gptiJ1o/SuxrEUEiUrFNW3D5zLwm oZmZODNN0n/v4EKXl3s5lzNbDLoRHTtfW4NwPU5AsCmsqk2JsN28XE1B+EBGUWMNI5zYw2J+fjaj VNnerLnLQykixPiUEKoQ2lRKX1SsyY9tyyZ2e+s0hRhdKZWjPsJ1I2+S5F5qqk18qKjl54qLQ37U CKNttjk+HFbZu/ue7N4+2v6uG60QLy+Gp0cQgYfwP15+TvPd7V/5i3pVCBMQ++z05Wq1Jh/YIUS3 aBotQc5/AAAA//8DAFBLAQItABQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAAAAAA AABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAA AAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAABe/anjBAAALysAABAAAAAAAAAA AAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEArD0Z39oAAAD5AAAADwAA AAAAAAAAAAAAAAA5BwAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAEAIAAAAAAAAEPAI AAAA8AMgAWAVEw8PABHwogAAAAAAwwsIAAAA/////xMA+b8PAIgTfgAAAA8AihN2AAAAAAC6Dw4A AABfAF8AXwBQAFAAVAA5AAAAixNYAAAAAACsD1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAIAD//8BAAMAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA HwQEAAAAAwAAAA8ADfAXBAAAAACfDwQAAAABAAAAAACoD1UDAABDbGFyaWZ5IGVycm9yIHJlc3Bv bnNlcyBhbmQgYWxsb3cgbm9uLUhUVFAgZXJyb3IgY29kZXMNDVRoZSBBUEkgZHJhZnQgc3RhdGVz IHRoYXQgcmVxdWVzdHMgdGhhdCByZXN1bHQgaW4gYW4gZXJyb3IgIk1VU1QgcmV0dXJuIHRoZSBl cnJvcnMgaW4gdGhlIGJvZHkgb2YgdGhlIHJlc3BvbnNlIGluIHRoZSBjbGllbnQgcmVxdWVzdGVk IGZvcm1hdCBjb250YWluaW5nIHRoZSBlcnJvciByZXNwb25zZSBhbmQsIHBlciB0aGUgSFRUUCBz cGVjaWZpY2F0aW9uLCBodW1hbi1yZWFkYWJsZSBleHBsYW5hdGlvbnMuIg0NV2UgbmVlZCB0byBj bGVhcmx5IGRlZmluZSB0aGUgZm9ybWF0IG9mIHRoZSBlcnJvciByZXNwb25zZS4gSGVyZSBhcmUg YSBmZXcgcXVlc3Rpb25zIHRoYXQgSSBoYXZlIGJlZW4gYXNrZWQgcmVnYXJkaW5nIHRoZSBjdXJy ZW50IGVycm9yIHJlc3BvbnNlOg1XaHkgaXMgdGhpcyBhbiBhcnJheSBvZiBjb21wbGV4IG9iamVj dHM/IEhvdyB3b3VsZCBtdWx0aXBsZSBlcnJvcnMgYmUgdXNlZD8NRG9lcyB0aGUgY29kZSBzdWIt YXR0cmlidXRlIGhhdmUgdG8gYmUgdGhlIEhUVFAgZXJyb3IgY29kZT8NSWYgYSBzZXJ2aWNlIHBy b3ZpZGVyIHdhbnRzIHRvIHRyYW5zbWl0IGEgbW9yZSBkZXRhaWxlZCBlcnJvciBjb2RlLCBob3cg d291bGQgaXQgZG8gdGhpcz8gRG9lcyB0aGlzIGhhdmUgdG8gZml0IGludG8gdGhlIGZvcm1hdHRl ZCBkZXNjcmlwdGlvbiBvciBjYW4gYW5vdGhlciBzdWItYXR0cmlidXRlIGJlIGFkZGVkIHRvIHRo ZSBlcnJvciByZXBvbnNlPw0NV2UgbmVlZCB0byBhbnN3ZXIgdGhlc2UgcXVlc3Rpb25zIGFuZCB0 aWdodGVuIHVwIHRoZSBzcGVjIHRvIGJlIG1vcmUgY2xlYXIuAAChD3YAAAC2AQAAAAABEAAAAgBQ AFMBAAAAAJIQAAADACIgAABQAE0AAAAAAAEQAAACAFAANwAAAAQAAgAEABgAAQAAAAQEAgAEBBMA fgEAAAAIAgAACBMAUwEAAAAMAgAADBMATAAAAAAQAgAAEBMAAQAAAAAUAgAAFBEAAACqDxoAAAAA AwAAAAAAAAcAAAABAAAAAwBPAAAAAAAAAAAApg8GAAAACAAAAAAAEADwByAAAAD///8AAAAAAO7s 4QAfSX0AT4G9AMBQTQAAAP8AgACAAAAAIgQIAAAAAQAAAAIAAAAAAHIXPAAAAAEA4AAAAAAA9yMA AEyjAACvrQAAHrEAAK20AABcuAAAk7sAAPS/AAD1wwAAisoAAF/aAAAf3gAACe8AAAAA9Q8cAAAA AAAAAPE+AAMAAAAAjv8AAAEAAAAOAAAADwAAAAAAAAAAAAAAAAD+/wAAAwoBAAAAAAAAAAAAAAAA AAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAD4FAAACwAAAAEAAABgAAAAAgAAAGgAAAAEAAAA iAAAAAgAAACcAAAACQAAALAAAAASAAAAvAAAAAoAAADkAAAADAAAAPAAAAANAAAA/AAAAA8AAAAI AQAAEQAAABABAAACAAAAECcAAB4AAAAYAAAAU0NJTSBjb25mZXJlbmNlIGNhbGwAAAAAHgAAAAwA AABCYXJyeSBMZWliYQAeAAAADAAAAEJhcnJ5IExlaWJhAB4AAAAEAAAAOQAAAB4AAAAgAAAATWlj cm9zb2Z0IE1hY2ludG9zaCBQb3dlclBvaW50AABAAAAAtoTtgwMAAABAAAAAAIwCXH2pzgFAAAAA UHmHGIGpzgEDAAAA4AIAAEcAAADeEwAA/v///1BJQ1QT1gAAAAAAhwC0ABEC/wwA//4AAABIAAAA SAAAAAAAAACHALQAAAAAAB4AAQAKAAAAAACHALQAmv8AAACC0AAAAAAAhwC0AAAABAAAAAAASAAA AEgAAAAQACAABAAIAAAAIAAAAAAAAAAAAAAAAACHALQAAAAAAIcAtAAAAAyB/4H/gf+B/4H/sf8A DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB /4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/ gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B /4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/ gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B /4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/ gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B /4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/ gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B /7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/ sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wBGgf+g/wH8/f3/AP3f /wLZhNHW/wOw6eysqP8B/P39/wD93/8C2YTR1v8DsOnsrKj/Afz9/f8A/d//AtmE0db/A7Dp7KzV /wB2gf+h/w9uNzOl/+pSMSuK/zXp8xRy/v8C2xeT7f8CNK/a1v8DUsrSSqn/D243M6X/6lIxK4r/ NenzFHL+/wLbF5Pt/wI0r9rW/wNSytJKqf8Pbjczpf/qUjEriv816fMUcv7/AtsXk+3/AjSv2tb/ A1LK0krV/wEbgf+i/xbeLf//7v9Ok//+xv8s5+wqJvD//29LhP3/L/fU9///9NX2///p/Nn5/+sZ 5Pz/8df7//zt5uj/+db1///p/Nn5///92Oz///nW9fz/DO7W/f/70+X//1LK0kqq/xbeLf//7v9O k//+xv8s5+wqJvD//29LhP3/L/fU9///9NX2///p/Nn5/+sZ5Pz/8df7//zt5uj/+db1///p/Nn5 ///92Oz///nW9fz/DO7W/f/70+X//1LK0kqq/xbeLf//7v9Ok//+xv8s5+wqJvD//29LhP3/L/fU 9///9NX2///p/Nn5/+sZ5Pz/8df7//zt5uj/+db1///p/Nn5///92Oz///nW9fz/DO7W/f/70+X/ /1LK0krV/wEhgf+i/wfxF7D//+4V/f3/Cizn7C18lP/0MJOE/v8x1yRgO/60M2kryv8mTlsv+4MK X+SyQmc389IwPozdO3Etzf8mTlsv+/g6UUHR3TtxLc3+/w2pJWNl/kVyOpz/UsrSSqr/B/EXsP// 7hX9/f8KLOfsLXyU//Qwk4T+/zHXJGA7/rQzaSvK/yZOWy/7gwpf5LJCZzfz0jA+jN07cS3N/yZO Wy/7+DpRQdHdO3Etzf7/DaklY2X+RXI6nP9SytJKqv8H8Rew///uFf39/wos5+wtfJT/9DCThP7/ MdckYDv+tDNpK8r/Jk5bL/uDCl/kskJnN/PSMD6M3TtxLc3/Jk5bL/v4OlFB0d07cS3N/v8NqSVj Zf5Fcjqc/1LK0krV/wEbgf+h/wXLOTfYzzL8/wos5+wt3jD/mYaVhP7/MWSc//r/KeX/tlL/GOb/ Rs//G///Len5aKPSJ/n/aa75pmP/GOb/Rs+kXP//+2mu+aZj/v8DJNz/+v7/Bs1P/1LK0kqp/wXL OTfYzzL8/wos5+wt3jD/mYaVhP7/MWSc//r/KeX/tlL/GOb/Rs//G///Len5aKPSJ/n/aa75pmP/ GOb/Rs+kXP//+2mu+aZj/v8DJNz/+v7/Bs1P/1LK0kqp/wXLOTfYzzL8/wos5+wt3jD/mYaVhP7/ MWSc//r/KeX/tlL/GOb/Rs//G///Len5aKPSJ/n/aa75pmP/GOb/Rs+kXP//+2mu+aZj/v8DJNz/ +v7/Bs1P/1LK0krV/wEVgf+f/wOXOeQa/P8KLOfsLf9DxzTolYT+/wFEzf7/DxT//9s4/x3//1nD /xv//w3+XxHB0kr//0hMX1+Z/x3//1nDhI3+/wRITF9fmf7/ABL+/wn8bldNSf9SytJKp/8Dlznk Gvz/Cizn7C3/Q8c06JWE/v8BRM3+/w8U///bOP8d//9Zw/8b//8N/l8RwdJK//9ITF9fmf8d//9Z w4SN/v8ESExfX5n+/wAS/v8J/G5XTUn/UsrSSqf/A5c55Br8/wos5+wt/0PHNOiVhP7/AUTN/v8P FP//2zj/Hf//WcP/G///Df5fEcHSSv//SExfX5n/Hf//WcOEjf7/BEhMX1+Z/v8AEv7/CfxuV01J /1LK0krV/wEYgf+i/xbr9//UMP8ypv//0P8s5+wt/6cwVv+VhP7/FWOi/+n+J9z/p2T/Hf//WcT/ G///LOL+/wXSSv//a6L9/wsd//9ZxKNi//jua6L7/w0l4f/nzUP/xkn/UsrSSqr/Fuv3/9Qw/zKm ///Q/yzn7C3/pzBW/5WE/v8VY6L/6f4n3P+nZP8d//9ZxP8b//8s4v7/BdJK//9rov3/Cx3//1nE o2L/+O5rovv/DSXh/+fNQ//GSf9SytJKqv8W6/f/1DD/Mqb//9D/LOfsLf+nMFb/lYT+/xVjov/p /ifc/6dk/x3//1nE/xv//yzi/v8F0kr//2ui/f8LHf//WcSjYv/47mui+/8NJeH/581D/8ZJ/1LK 0krV/wEkgf+i/xbJLEYtu//WNjMwf/8u6O0v//gTv/+Xhv7/MdgrSUD7titNPuP/H///WsX/Hv// ujFZRtjTTP//4ThUTKj/H///WsX3QUM31eE4VEyo/v8NrSdGbvIwVVlK/1PM00yq/xbJLEYtu//W NjMwf/8u6O0v//gTv/+Xhv7/MdgrSUD7titNPuP/H///WsX/Hv//ujFZRtjTTP//4ThUTKj/H/// WsX3QUM31eE4VEyo/v8NrSdGbvIwVVlK/1PM00yq/xbJLEYtu//WNjMwf/8u6O0v//gTv/+Xhv7/ MdgrSUD7titNPuP/H///WsX/Hv//ujFZRtjTTP//4ThUTKj/H///WsX3QUM31eE4VEyo/v8NrSdG bvIwVVlK/1PM00zV/wEPgf+h/wL97f79/w71+////P///P///P///v78/wDu/v8B/vL+/wb8///8 ///8/v8F/uz9///8/f8H8Pn///z///z+/wHx/P7/AfD5/P8M+/H///7y//3//P///Kn/Av3t/v3/ DvX7///8///8///8///+/vz/AO7+/wH+8v7/Bvz///z///z+/wX+7P3///z9/wfw+f///P///P7/ AfH8/v8B8Pn8/wz78f///vL//f/8///8qf8C/e3+/f8O9fv///z///z///z///7+/P8A7v7/Af7y /v8G/P///P///P7/Bf7s/f///P3/B/D5///8///8/v8B8fz+/wHw+fz/DPvx///+8v/9//z///zV /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/ AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB /4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wB8gf+Q/wj9wPn///bBw/35/wH3/Pb/Ab779v8O2brf /+vA1f//1Of/5b7Qh/8I/cD5///2wcP9+f8B9/z2/wG++/b/Dtm63//rwNX//9Tn/+W+0If/CP3A +f//9sHD/fn/Aff89v8Bvvv2/w7Zut//68DV///U5//lvtDE/wC+gf+Q/zrLqvP//8Hq9f395Pb/ 8e3t/7zU+/nj+v/x5/bv7v+47+f//+3p//Xy7f//6vyi/6/9vezfwdT/7v+v9Yj/Osuq8///wer1 /f3k9v/x7e3/vNT7+eP6//Hn9u/u/7jv5///7en/9fLt///q/KL/r/297N/B1P/u/6/1iP86y6rz ///B6vX9/eT2//Ht7f+81Pv54/r/8ef27+7/uO/n///t6f/18u3//+r8ov+v/b3s38HU/+7/r/XF /wC+gf+R/ynzw7/z///frer/udyt+qrPs+i1yvW03LL/nNSiy671uMXC1NvIxdXQs+T+/w37qve5 /9jX/9vU//XQtYj/KfPDv/P//9+t6v+53K36qs+z6LXK9bTcsv+c1KLLrvW4xcLU28jF1dCz5P7/ Dfuq97n/2Nf/29T/9dC1iP8p88O/8///363q/7ncrfqqz7Potcr1tNyy/5zUosuu9bjFwtTbyMXV 0LPk/v8N+6r3uf/Y1//b1P/10LXE/wC+gf+R/wO537Ti/v8h8q3noMi28bT/4NDK6eiryLP/tP+z /8znuPv3uLnExM3Q4/3/Drvn9rj/2Nn/29T/++ew6on/A7nftOL+/yHyreegyLbxtP/g0Mrp6KvI s/+0/7P/zOe4+/e4ucTEzdDj/f8Ou+f2uP/Y2f/b1P/757Dqif8Dud+04v7/IfKt56DItvG0/+DQ yunoq8iz/7T/s//M57j797i5xMTN0OP9/w675/a4/9jZ/9vU//vnsOrF/wDBgf+R/yjg163Y///n +sbfrvv2/6nux+DN3/S1//X/tP+0/8znud/fycjh/vfQ4/7/D8LV9/+r+rny/tjR/ur+v+GJ/yjg 163Y///n+sbfrvv2/6nux+DN3/S1//X/tP+0/8znud/fycjh/vfQ4/7/D8LV9/+r+rny/tjR/ur+ v+GJ/yjg163Y///n+sbfrvv2/6nux+DN3/S1//X/tP+0/8znud/fycjh/vfQ4/7/D8LV9/+r+rny /tjR/ur+v+HF/wC4gf+P/ybf+v//5MDU/+zDy/+xytL/9cH04MLW/9r/2v/m897UyPz8y8Pt5/L+ /w7JxMT16sLh/+TExOjewNaG/ybf+v//5MDU/+zDy/+xytL/9cH04MLW/9r/2v/m897UyPz8y8Pt 5/L+/w7JxMT16sLh/+TExOjewNaG/ybf+v//5MDU/+zDy/+xytL/9cH04MLW/9r/2v/m897UyPz8 y8Pt5/L+/w7JxMT16sLh/+TExOjewNbE/wAUgf+D/wC7gf/O/wC7gf/O/wC7mP8ADIH/gf+B/4H/ gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B /7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/ sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/ AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB /4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/ gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B /4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/ gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B /4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A/wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAAAgAAAALV zdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rsgCAACEAgAAEAAAAAEAAACIAAAAAwAA AJAAAAAPAAAAsAAAAAQAAADYAAAABgAAAOAAAAAHAAAA6AAAAAgAAADwAAAACQAAAPgAAAAKAAAA AAEAABcAAAAIAQAACwAAABABAAAQAAAAGAEAABMAAAAgAQAAFgAAACgBAAANAAAAMAEAAAwAAAAr AgAAAgAAAOn9AAAeAAAAGAAAAE9uLXNjcmVlbiBTaG93ICg0OjMpAAAAAB4AAAAgAAAASW50ZXJu ZXQgTWVzc2FnaW5nIFRlY2hub2xvZ3kAAAADAAAA9v8AAAMAAABFAAAAAwAAAAwAAAADAAAAAAAA AAMAAAAAAAAAAwAAAAAAAAADAAAAAAAOAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA HhAAABAAAAAIAAAAQ2FsaWJyaQAXAAAA77yt77yzIO+8sOOCtOOCt+ODg+OCrwAGAAAAQXJpYWwA DQAAAE9mZmljZSBUaGVtZQAVAAAAU0NJTSBjb25mZXJlbmNlIGNhbGwACQAAAElzc3VlICMyAAkA AABJc3N1ZSAjOQAKAAAASXNzdWUgIzEwAAoAAABJc3N1ZSAjMTMACgAAAElzc3VlICMyNAAKAAAA SXNzdWUgIzM0AAoAAABJc3N1ZSAjMzUACgAAAElzc3VlICMzNwAKAAAASXNzdWUgIzM5AAoAAABJ c3N1ZSAjNDIACgAAAElzc3VlICM0NgAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZAADAAAAAwAA AB4AAAAGAAAAVGhlbWUAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAADAAAAAAAAFwO AAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAAAQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAA AOn9AABBAAAAFA4AAHgAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAA aAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBo AGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5ADIA OQAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAA AB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwA LQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBn ADAAMAA5ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAA AAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAv AG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4A dAAvAG0AcwBnADAAMAA5ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAG AAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYA LgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1 AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAA BwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAu AGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMA aQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAA AAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8A LwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBl AGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMQAwADIANwAuAGgAdABtAGwA AAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0 AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkA dgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMQAwADIANwAu AGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8A AABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBh AHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAA MQAwADIANwAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAAD AAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0A YQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAv AG0AcwBnADAAMQAwADIANwAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAA AwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBv AHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIA cgBlAG4AdAAvAG0AcwBnADAAMQAwADIANwAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAA AAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkA ZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBt AC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAAAAAA AAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3 AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIA LwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5ADIAOQAuAGgAdABtAGwAAAAf AAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQA cAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBl AC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5ADIAOQAuAGgA dABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABA AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIA YwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMAA5 ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAA BwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBp AGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0A cwBnADAAMAA5ADIAOQAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAA AAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIA ZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBl AG4AdAAvAG0AcwBnADAAMQAwADIANwAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMA AAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0 AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8A YwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMQAwADIANwAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAAD AAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6AC8ALwB3AHcA dwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8AdwBlAGIALwBz AGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMQAwADIANwAuAGgAdABtAGwAAAAfAAAA AQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAAaAB0AHQAcAA6 AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBoAGkAdgBlAC8A dwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMQAwADIANwAuAGgAdABt AGwAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAABAAAAA aAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwALQBhAHIAYwBo AGkAdgBlAC8AdwBlAGIALwBzAGMAaQBtAC8AYwB1AHIAcgBlAG4AdAAvAG0AcwBnADAAMQAwADIA NwAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////wAA9g8jAAAAFAAAAF/AkePS/wAACwD0AwMA+b9CYXJyeSBMZWliYQgA AABCAGEAcgByAHkAIABMAGUAaQBiAGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA --_004_CA3B67220D628A4780D6FEB31F18A3E32ABCED20xmbrcdx08ciscoc_-- From leifj@mnt.se Mon Sep 9 00:26:00 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2504F21F9928 for ; Mon, 9 Sep 2013 00:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8GM8R7IX2Rn for ; Mon, 9 Sep 2013 00:25:49 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB6621F9926 for ; Mon, 9 Sep 2013 00:25:37 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id eo20so4588594lab.34 for ; Mon, 09 Sep 2013 00:25:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=PGHdQi+W5hYb1HdAshAd6DE8rhecbYkomYyzemvYJg8=; b=dCq1bzs6LKbRwPz8qezVJ7EeCI03UIsUNUNFeultFU0kMUfzMg8NGt7x49Fcym3H36 4FeXuINrlFXw2yFElFw/Xgmn9gHLVoDt64Yq7DxC5P3bL+BmRMQ4Mdm1RtTUuXFQdpHR l6oWvQPJ2BxxUeC0U26e+XemMsuwBWGHFUV0EfelR4flDdTH4y61XpH1kT8tWtmpNkQp F6RaNg6beoTceU7KFFgpJHuzQAZsh/Rc+Kla81+ta33kHdjsfKdYDKUjy4fyGg8Pors7 nROrCjZRiJ7/FIkH7usdugQmx+Qis8Zd9N85B0986nDoEeOT58nRtwM3B30TejTOKBrM 5cqw== X-Gm-Message-State: ALoCoQnxs8YpYuYwupCCVGBspZn49+gWA2jH7yhE+yN2GU3TLkeiH1T6oGypNsG/MisrDpHVQSHe X-Received: by 10.112.143.3 with SMTP id sa3mr15153389lbb.12.1378711536203; Mon, 09 Sep 2013 00:25:36 -0700 (PDT) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id b1sm5520027lah.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 00:25:35 -0700 (PDT) Message-ID: <522D77ED.8030104@mnt.se> Date: Mon, 09 Sep 2013 09:25:33 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: scim@ietf.org References: <60c663911d4842299ef93e5440925c1c@BLUPR04MB184.namprd04.prod.outlook.com> In-Reply-To: <60c663911d4842299ef93e5440925c1c@BLUPR04MB184.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------040804080601070904000209" Subject: Re: [scim] PATCH and Meta.Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 07:26:00 -0000 This is a multi-part message in MIME format. --------------040804080601070904000209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/16/2013 04:12 PM, Kelly Grizzle wrote: > > You are correct -- this should be an xs:string rather than a > multiValuedAttribute. As of draft -01 XML is no longer supported, so > we should probably just remove the xsd from the site. > > > > --Kelly > Just reviewing old email on the list. It would help if somebody could update the site to clearly point to the 2.0 effort in the IETF so implementers don't get confused and spend a lot of resources on XML. Cheers Leif > > > > *From:*scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Alexandre Santos > *Sent:* Monday, July 15, 2013 4:52 PM > *To:* scim@ietf.org > *Subject:* [scim] PATCH and Meta.Attributes > > > > In http://www.simplecloud.info/specs/draft-scim-core-schema-01.html#anchor2 > (5.1 Common Schema Attributes) says > > > > attributes > > The names of the attributes to remove from the Resource during a PATCH > operation. > > > > Which suggests a simple list of strings, also indicated by the > examples in the usage of PATCH. However the XSD that defines the > schema (http://www.simplecloud.info/specs/schema/scim-core.xsd) > defines the attributes as multi valued attribute: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should the xsd be changed, or am I missing something? > > > > Thanks! > > > > > *Alexandre Santos* | Sr. Development Engineer > *Ping**Identity* | www.pingidentity.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - > *O:* 604.697.7056 > *Email:* asantos@pingidentity.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - > > *Connect with Ping* > Twitter: @pingidentity > LinkedIn Group: Ping's Identity Cloud > Facebook.com/pingidentitypage > > * * > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------040804080601070904000209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/16/2013 04:12 PM, Kelly Grizzle wrote:

You are correct – this should be an xs:string rather than a multiValuedAttribute.  As of draft -01 XML is no longer supported, so we should probably just remove the xsd from the site.

 

--Kelly


Just reviewing old email on the list. It would help if somebody could update the
site to clearly point to the 2.0 effort in the IETF so implementers don't get
confused and spend a lot of resources on XML.

        Cheers Leif

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Alexandre Santos
Sent: Monday, July 15, 2013 4:52 PM
To: scim@ietf.org
Subject: [scim] PATCH and Meta.Attributes

 

 

attributes

The names of the attributes to remove from the Resource during a PATCH operation. 

 

Which suggests a simple list of strings, also indicated by the examples in the usage of PATCH. However the XSD that defines the schema (http://www.simplecloud.info/specs/schema/scim-core.xsd) defines the attributes as multi valued attribute:

 

<xs:complexType name="meta">

<xs:sequence>

<xs:element name="created" type="xs:dateTime" minOccurs="0"/>

<xs:element name="lastModified" type="xs:dateTime" minOccurs="0"/>

<xs:element name="location" type="xs:string" minOccurs="0"/>

<xs:element name="version" type="xs:string" minOccurs="0"/>

<xs:element name="attributes" minOccurs="0">

<xs:complexType>

<xs:sequence>

<xs:element name="attribute" type="tns:multiValuedAttribute" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

Should the xsd be changed, or am I missing something?

 

Thanks!

 


Alexandre Santos  | Sr. Development Engineer
PingIdentity  |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
O: 604.697.7056
Email: asantos@pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Connect with Ping
Twitter: @pingidentity
LinkedIn Group: Ping's Identity Cloud    
Facebook.com/pingidentitypage

 

 



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

--------------040804080601070904000209-- From leifj@sunet.se Mon Sep 9 00:55:58 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A472811E818C for ; Mon, 9 Sep 2013 00:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWuIB0go8IDl for ; Mon, 9 Sep 2013 00:55:45 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) by ietfa.amsl.com (Postfix) with ESMTP id 8280721F880F for ; Mon, 9 Sep 2013 00:55:44 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter02.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r897tbgv000429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 Sep 2013 09:55:41 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id r897tYcF005268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Sep 2013 09:55:37 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.244] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.1.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for scim@ietf.org; Mon, 9 Sep 2013 09:55:34 +0200 Message-ID: <522D7EF5.60706@sunet.se> Date: Mon, 09 Sep 2013 09:55:33 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 0aKmTTBWc - 6fee8a6e34f0 - 20130909 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [scim] scheduling for Vancouver X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 07:55:58 -0000 Folks, Seeing as it is closer to "home" for a lot of the active participants I've asked for a 2hr slot in Vancouver in the hope that we'll be able to close a lot of remaining open issues in the room. Cheers Leif From tonynad@microsoft.com Mon Sep 9 09:31:20 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AED11E810E for ; Mon, 9 Sep 2013 09:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX-bjBNlQY1o for ; Mon, 9 Sep 2013 09:31:13 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id 21ECC11E8114 for ; Mon, 9 Sep 2013 09:28:19 -0700 (PDT) Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) with Microsoft SMTP Server (TLS) id 15.0.745.25; Mon, 9 Sep 2013 16:28:15 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.221]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.70]) with mapi id 15.00.0745.000; Mon, 9 Sep 2013 16:28:15 +0000 From: Anthony Nadalin To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] scheduling for Vancouver Thread-Index: AQHOrTIIZRn+OtBxEEWsqzsMrwIni5m9mMCQ Date: Mon, 9 Sep 2013 16:28:14 +0000 Message-ID: <53b3e85de226478685dd8e8ff0f06e4d@BY2PR03MB189.namprd03.prod.outlook.com> References: <522D7EF5.60706@sunet.se> In-Reply-To: <522D7EF5.60706@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::2] x-forefront-prvs: 09645BAC66 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(13464003)(189002)(199002)(46102001)(65816001)(79102001)(19580395003)(19580405001)(83322001)(63696002)(69226001)(81686001)(47736001)(4396001)(47976001)(49866001)(33646001)(76796001)(81542001)(50986001)(51856001)(74876001)(81342001)(80976001)(81816001)(76576001)(76786001)(74366001)(83072001)(56776001)(31966008)(74662001)(47446002)(74502001)(15975445006)(54356001)(53806001)(77096001)(54316002)(76482001)(74316001)(56816003)(77982001)(74706001)(59766001)(80022001)(42262001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB189; H:BY2PR03MB189.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: Re: [scim] scheduling for Vancouver X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:31:20 -0000 +1 -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Monday, September 9, 2013 12:56 AM To: scim@ietf.org Subject: [scim] scheduling for Vancouver Folks, Seeing as it is closer to "home" for a lot of the active participants I've = asked for a 2hr slot in Vancouver in the hope that we'll be able to close a= lot of remaining open issues in the room. Cheers Leif _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Mon Sep 9 10:26:13 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C1411E81C8 for ; Mon, 9 Sep 2013 10:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U6ynxUWG3Qa for ; Mon, 9 Sep 2013 10:26:07 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4B80921F9DBE for ; Mon, 9 Sep 2013 10:25:35 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r89HPWJV003917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 Sep 2013 17:25:33 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r89HPWW5028142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Sep 2013 17:25:32 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r89HPVsi026743 for ; Mon, 9 Sep 2013 17:25:31 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Sep 2013 10:25:31 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_6BA4CBD6-1F52-4B3B-80C6-C58C4316B158" Message-Id: Date: Mon, 9 Sep 2013 10:25:30 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [scim] Querying and Attr list expected formats and results with extended schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 17:26:13 -0000 --Apple-Mail=_6BA4CBD6-1F52-4B3B-80C6-C58C4316B158 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In the case where extended schema is being used, I'd like to clarify = attribute use in filters, attributes, results. Let's say I am using urn:scim:schemas:extension:enterprise:2.0:User and = I want to query employeeNumber that is part of that schema. =20 For both filters and attributes would the following apply: a. The plain attribute name can be used if no conflicts b. In case of conflicts, a fully qualified name may be used in = attributes and filters, eg: urn:scim:schemas:extension:enterprise:2.0:User:employeeNumber Note above, I have used ':' between the schema qualifier and the = attribute name. Likewise, a filter for a complex attribute: urn:myOfficeExtension:addresses.type=3D"main" Where this hypothetical addresses might be a similarly defined User = addresses but contains a set of work locations. GET /Users?attributes=3DuserName,employeeNumber Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 HTTP/1.1 200 OK Content-Type: application/json { "schemas":["urn:scim:schemas:core:2.0:ListResponse"], "totalResults":2, "Resources":[ { "id":"5bd1b1f6-b337-452e-942a-786dd50e66f2", "userName":"bjensen", "urn:scim:schemas:extension:enterprise:2.0:User": { "employeeNumber": "11250" } } }, { "id":"9168eea2-4f76-4997-bf7e-d9c90277b31a". "userName":"jsmith" } ] } Is this what the group feels should be occurring? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_6BA4CBD6-1F52-4B3B-80C6-C58C4316B158 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

=
Where this hypothetical addresses might be a similarly defined User = addresses but contains a set of work = locations.

GET =
/Users?attributes=3DuserName,employeeNumber
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8



   HTTP/1.1 200 OK
   Content-Type: application/json

   {
     "schemas":["urn:scim:schemas:core:2.0:ListResponse"],
     "totalResults":2,
     "Resources":[
       {
       =
  "id":"5bd1b1f6-b337-452e-942a-786dd50e66f2",
         "userName":"bjensen",
  =
       "urn:scim:schemas:extension:enterprise:2.0:User": {
             "employeeNumber": "11250"
             }
           }


       },
       {
	 =
"id":"9168eea2-4f76-4997-bf7e-d9c90277b31a".
         "userName":"jsmith"
       }
     ]
   }

Is this what the group feels should be = occurring?
= --Apple-Mail=_6BA4CBD6-1F52-4B3B-80C6-C58C4316B158-- From leifj@sunet.se Mon Sep 9 11:32:07 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBC611E8125; Mon, 9 Sep 2013 11:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.382 X-Spam-Level: X-Spam-Status: No, score=-1.382 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znnY2iBa1lWT; Mon, 9 Sep 2013 11:32:00 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1A711E8123; Mon, 9 Sep 2013 11:31:58 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r89IVtrR010492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Sep 2013 20:31:56 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id r89IVouZ009762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Sep 2013 20:31:55 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.244] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.1.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Mon, 9 Sep 2013 20:31:48 +0200 Message-ID: <522E1413.3070000@sunet.se> Date: Mon, 09 Sep 2013 20:31:47 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: ietf-secretariat@ietf.org, "scim@ietf.org" Content-Type: multipart/alternative; boundary="------------020203070806010009050907" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Kn6vUmU - 3602c452af6e - 20130909 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [scim] Meeting notes from WG confcall 2013-09-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 18:32:07 -0000 This is a multi-part message in MIME format. --------------020203070806010009050907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit SCIM Working Group Meeting: 13-09-04 Minutes: Mark Diodati In attendance: * Anthony Nadalin * Barry Leiba * Bjorn Aannestad * Erik Wahlström * Kelly Grizzle * Leif Johansson (chair) * Mark Diodati * Mortezza Ansari (briefly) * Phil Hunt * Sal D'Agostino Notes: Issue #2 Add pagination capability for plural resource attributes. GET on group resource could return many user references, which is resource intensive. Phil Hunt--ostensibly provides performance enhancements. Mark Diodati--Enforced pagination makes common provisioning queries more challengin. Must have two loops. One inward loop for groups references, then an outward loop for users. Kelly/Phil--provide an ability to return the number of attributes so that the client can be smarter? Phil--return only the groups that the user belongs to? Kelly--maybe modify schema to limit which attributes are returned in a rest call? Decision: issue will not be addressed, but Kelly will provide documentation/guidance on expected behavior of consumer and service provider. Issue #9 Ability to mark attributes as unique in ServiceProviderConfig. Kelly--not a strong use case for this issue. Bjorn--not much of an advantage in implementing fix. Leif--No real consensus fixing or not. Decision: postpone discussion. Issue 10 Ability to mark attributes as "sensitive" in ServiceProviderConfig. Erik--questions reason to add feature. Kelly--password attribute is write-only. Maybe requestor wants the ability to set for other attributes? Leif--worry that anything we do with respect to issue will be under-specified. Kelly--alternate proposal is to have write-only attributes. Decision: Phil will create two separate issues. 1 - ability to specify write-only attributes. 2 - Return specific attributes only upon request. Issue 13 Add a "required" flag in configuration to support etags. Erik--example: match with an etag. One server can support different clients. Kelly--add subattribute to etags attribute in ServiceProviderConfig to specify whether server requires etags? Decision: Erik will provide additional information on how etags should be addressed. Issue 24 Add the negation operator to the Filtering Section. Kelly--Perhaps look at the OpenSearch protocol for inspiration? Decision: Bjorn to take a stab at proposed language for the spec. --------------020203070806010009050907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

SCIM Working Group Meeting: 13-09-04

Minutes: Mark Diodati

In attendance:

  • Anthony Nadalin

  • Barry Leiba

  • Bjorn Aannestad

  • Erik Wahlström

  • Kelly Grizzle

  • Leif Johansson (chair)

  • Mark Diodati

  • Mortezza Ansari (briefly)

  • Phil Hunt

  • Sal D'Agostino

Notes:

Issue #2

Add pagination capability for plural resource attributes. GET on group resource could return many user references, which is resource intensive.

Phil Hunt--ostensibly provides performance enhancements.

Mark Diodati--Enforced pagination makes common provisioning queries more challengin. Must have two loops. One inward loop for groups references, then an outward loop for users.

Kelly/Phil--provide an ability to return the number of attributes so that the client can be smarter?

Phil--return only the groups that the user belongs to?

Kelly--maybe modify schema to limit which attributes are returned in a rest call?

Decision: issue will not be addressed, but Kelly will provide documentation/guidance on expected behavior of consumer and service provider.



Issue #9

Ability to mark attributes as unique in ServiceProviderConfig.

Kelly--not a strong use case for this issue.

Bjorn--not much of an advantage in implementing fix.

Leif--No real consensus fixing or not.

Decision: postpone discussion.



Issue 10

Ability to mark attributes as “sensitive” in ServiceProviderConfig.

Erik--questions reason to add feature.

Kelly--password attribute is write-only. Maybe requestor wants the ability to set for other attributes?

Leif--worry that anything we do with respect to issue will be under-specified.

Kelly--alternate proposal is to have write-only attributes.

Decision: Phil will create two separate issues. 1 - ability to specify write-only attributes. 2 - Return specific attributes only upon request.



Issue 13

Add a “required” flag in configuration to support etags.

Erik--example: match with an etag. One server can support different clients.

Kelly--add subattribute to etags attribute in ServiceProviderConfig to specify whether server requires etags?

Decision: Erik will provide additional information on how etags should be addressed.



Issue 24

Add the negation operator to the Filtering Section.

Kelly--Perhaps look at the OpenSearch protocol for inspiration?

Decision: Bjorn to take a stab at proposed language for the spec.

--------------020203070806010009050907-- From phil.hunt@oracle.com Mon Sep 9 14:08:22 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FA821F9AD2 for ; Mon, 9 Sep 2013 14:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0Gc+aqkAcwL for ; Mon, 9 Sep 2013 14:08:14 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA9011E8156 for ; Mon, 9 Sep 2013 14:07:59 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r89L7vsM005169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 Sep 2013 21:07:57 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r89L7ura021166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Sep 2013 21:07:56 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r89L7tum009874 for ; Mon, 9 Sep 2013 21:07:55 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Sep 2013 14:07:55 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 9 Sep 2013 14:07:54 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [scim] Agenda request for sept 18 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 21:08:22 -0000 * Sensitivity/index/returnability (see update on Item 10) * Passwords - Can passwords be validated? Regarding validating = passwords, I understand some want to keep this out of scope of SCIM.=20 Related to both above is the notion of mutability. Is an attribute write = only / read only / immutable, etc? Phil @independentid www.independentid.com phil.hunt@oracle.com From barryleiba.mailing.lists@gmail.com Mon Sep 9 18:50:59 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C323B21E8055 for ; Mon, 9 Sep 2013 18:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.022 X-Spam-Level: X-Spam-Status: No, score=-102.022 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPIEt3c4nLwE for ; Mon, 9 Sep 2013 18:50:59 -0700 (PDT) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 021EB11E80F8 for ; Mon, 9 Sep 2013 18:50:46 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id f12so4416270vbg.39 for ; Mon, 09 Sep 2013 18:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=CuN2ry1FcV67h4BMgD+GLyT0QMkyo+RRDtrH4MexKrQ=; b=o5rYUviSCKaul5ip2aJH6XoB19Z+mqijpoyGl9sex///CkaSkNhNR05lDDV6zp9Eha vaoW/nWz0aNU+byqEa0C7oJ5v1CbqcM4XFA0Wq9a36BQVvpXCjFDKc3AYRQktGVz74Ra P17Js3gffwWgwO/OWfWZAxbkSpJIUJMPe8ziuMTh6S83vyvF7AOTG9f361L1cHpTAInv yaI1Tu8oI6u7vlU5Hyl2T4QJay2OqMGVyrj0jWlNgjw4j0du9xIFxY9ct//Mw/1YGrha N+lRTfa3dvbe8ZTIPUBIVjNUYpyK+POYLxaeal5WiAJDC8awamSTWXSn9QgEYbDrtBkK umhw== MIME-Version: 1.0 X-Received: by 10.220.140.69 with SMTP id h5mr20424034vcu.0.1378777844603; Mon, 09 Sep 2013 18:50:44 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.215.16 with HTTP; Mon, 9 Sep 2013 18:50:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Sep 2013 21:50:44 -0400 X-Google-Sender-Auth: DvF2ok1Jys1C9e5Rqi5WElG_WwI Message-ID: From: Barry Leiba To: "scim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [scim] Next SCIM WG call agenda - Sep. 18th @11AM Pacific X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 01:50:59 -0000 > Just a reminder that the next SCIM WG call is scheduled for Sep. 18th at > 11AM Pacific time. The agenda for that meeting is to continue going through > the backlog of the issues from tracker. See the attached slides. And a further reminder that we should be addressing these issues on the mailing list, and using the conference calls to address points that haven't gotten resolution on the list. *Please* work on resolving the issues on the list first, and make the most of the high-bandwidth conference-call time. Barry, doing the AD thing From kelly.grizzle@sailpoint.com Tue Sep 10 06:42:19 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D17921F9FB1 for ; Tue, 10 Sep 2013 06:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIBE0zZdCtZ6 for ; Tue, 10 Sep 2013 06:42:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA3721F8447 for ; Tue, 10 Sep 2013 06:42:13 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 10 Sep 2013 13:42:12 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) with mapi id 15.00.0745.000; Tue, 10 Sep 2013 13:42:12 +0000 From: Kelly Grizzle To: scim issue tracker , "draft-ietf-scim-core-schema@tools.ietf.org" , "phil.hunt@oracle.com" Thread-Topic: [scim] #10: Add ability to mark attributes as sensitive in the schemas Thread-Index: AQHOrZ61C3McU7HQ0069L6D/ofKUTJm++tGQ Date: Tue, 10 Sep 2013 13:42:12 +0000 Message-ID: References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> In-Reply-To: <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 2678843600535C26788583 x-originating-ip: [72.182.10.254] x-forefront-prvs: 096507C068 x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(377454003)(199002)(189002)(50986001)(47976001)(33646001)(51856001)(74366001)(46102001)(54356001)(74706001)(74876001)(80022001)(53806001)(74316001)(56776001)(83072001)(49866001)(77982001)(31966008)(4396001)(63696002)(77096001)(81816001)(79102001)(47446002)(81686001)(65816001)(69226001)(74502001)(19580395003)(76482001)(56816003)(59766001)(54316002)(66066001)(47736001)(81342001)(551544002)(81542001)(80976001)(74662001)(19580405001)(76796001)(76576001)(83322001)(76786001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:72.182.10.254; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 13:42:19 -0000 KzEgZm9yIHRoZSAicmV0dXJuZWQiIGF0dHJpYnV0ZSBhbmQgaXRzIHZhbHVlcy4NCg0KUmVnYXJk aW5nICJpbmRleCIsIHRoaXMgbWlnaHQgYmUgb3ZlcmtpbGwuICBGaWx0ZXJzIHN1cHBvcnQgZGlm ZmVyZW50IG9wZXJhdG9ycyAoZXEsIHN3LCBjbykgdG8gZG8gZXhhY3QgYW5kIHN1YnN0cmluZyBt YXRjaGluZy4gIFRoZSBpbmRleCBqdXN0IGluZGljYXRlcyBzZXJ2ZXItc2lkZSBiZWhhdmlvciBh Ym91dCB0aGUgbW9zdCBvcHRpbWFsIHdheSB0byBxdWVyeS4gIFdoaWxlIHRoaXMgaW5mb3JtYXRp b24gaXNuJ3QgaGFybWZ1bCwgaXQgbWF5IGJlIG1vcmUgdGhhbiB3aGF0IHdlIG5lZWQuDQoNCi0t S2VsbHkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2NpbSBpc3N1ZSB0 cmFja2VyIFttYWlsdG86dHJhYytzY2ltQHRvb2xzLmlldGYub3JnXSANClNlbnQ6IE1vbmRheSwg U2VwdGVtYmVyIDA5LCAyMDEzIDM6NTQgUE0NClRvOiBkcmFmdC1pZXRmLXNjaW0tY29yZS1zY2hl bWFAdG9vbHMuaWV0Zi5vcmc7IEtlbGx5IEdyaXp6bGU7IHBoaWwuaHVudEBvcmFjbGUuY29tDQpD Yzogc2NpbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzY2ltXSAjMTA6IEFkZCBhYmlsaXR5IHRv IG1hcmsgYXR0cmlidXRlcyBhcyBzZW5zaXRpdmUgaW4gdGhlIHNjaGVtYXMNCg0KIzEwOiBBZGQg YWJpbGl0eSB0byBtYXJrIGF0dHJpYnV0ZXMgYXMgc2Vuc2l0aXZlIGluIHRoZSBzY2hlbWFzDQoN Cg0KQ29tbWVudCAoYnkgcGhpbC5odW50QG9yYWNsZS5jb20pOg0KDQogSSB3b3VsZCBsaWtlIHRv IHByb3Bvc2UgYSBzZXJpZXMgb2Ygc2V0dGluZ3MgcGVyIGF0dHJpYnV0ZSB0byBjb3ZlciB0aGlz ICBpc3N1ZS4gIFVuZGVyIC9zY2hlbWFzLCBlYWNoIGF0dHJpYnV0ZSB3b3VsZCBoYXZlIHRoZSBm b2xsb3dpbmcNCiBhdHRyaWJ1dGVzOg0KDQogImluZGV4Ij0ibm9uZSJ8InN1YnN0cmluZyJ8ImV4 YWN0Ig0KICJyZXR1cm5lZCI9ImFsd2F5cyJ8Im5ldmVyInwiZGVmYXVsdCJ8InJlcXVlc3QiDQoN CiBGb3IgZXhhbXBsZSwgcGFzc3dvcmQgd291bGQgaGF2ZSAgICJpbmRleCI9ImV4YWN0IiBzaW5j ZSB0aGUgY2xpZW50IHdvdWxkDQogaGF2ZSB0byBkbyBhbiBleGFjdCBtYXRjaCwgYW5kICJyZXR1 cm5lZCI9Im5ldmVyIiBzaW5jZSB0aGUgdmFsdWUgaXMgIGhhc2hlZCBhbmQgc2hvdWxkIG5vdCBi ZSByZXR1cm5lZC4NCg0KIE5vdGU6ICB0aGUgaW5kZXggdHlwZSB3aWxsIGFsc28gZGVwZW5kIG9u IHRoZSB2YWx1ZSBvZiBjYXNlRXhhY3QuIEZvciAgZXhhbXBsZSBjYXNlRXhhY3QgPSBmYWxzZSBt ZWFucyB0aGUgc2VhcmNoIGluZGV4IGlzIGNhc2UgaW5zZW5zaXRpdmUuDQogY2FzZUV4YWN0PSJ0 cnVlIiBtZWFucyBpbmRleCBpcyBjYXNlIHNlbnNpdGl2ZS4NCg0KICJhbHdheXMiIGlzIHVzZWQg Zm9yIGF0dHJpYnV0ZXMgdGhhdCBtdXN0IGFsd2F5cyBiZSByZXR1cm5lZCBzdWNoIGFzICJpZCIN CiAibmV2ZXIiIGlzIHVzZWQgZm9yIHdyaXRlLW9ubHkgYXR0cmlidXRlcyB0aGF0IGNhbm5vdCBv ciBzaG91bGQgbm90IGJlICByZXR1cm5lZC4NCiAiZGVmYXVsdCIgaXMgdXNlZCBieSBtb3N0IGF0 dHJpYnV0ZXMgYW5kIG1lYW5zIGFyZSByZXR1cm5lZCBpZiB0aGUgIGF0dHJpYnV0ZSBwYXJhbSBp cyBtaXNzaW5nLiBJbiBvdGhlciB3b3JkcyB0aGUgYXR0cmlidXRlIGlzIHJldHVybmVkIG9uICBk ZWZhdWx0Lg0KICJyZXF1ZXN0IiBtZWFucyB0aGF0IHRoZSBhdHRyaWJ1dGUgd2lsbCBvbmx5IGJl IHJldHVybmVkIGlmIHJlcXVlc3RlZC4NCiBOb3RlOiB0aGlzIGlzIHNpbWlsYXIgdG8gb3BlcmF0 aW9uYWwgYXR0cmlidXRlcyBpbiBMREFQLg0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0NCiBSZXBvcnRlcjogICAgICAgICAgICAgICB8ICAgICAg IE93bmVyOiAgZHJhZnQtaWV0Zi1zY2ltLWNvcmUtDQogIG1lbGluZGEuc2hvcmVAZ21haWwuY29t fCAgc2NoZW1hQHRvb2xzLmlldGYub3JnDQogICAgIFR5cGU6ICBlbmhhbmNlbWVudCAgfCAgICAg IFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgIHwgICBNaWxlc3RvbmU6DQpD b21wb25lbnQ6ICBjb3JlLXNjaGVtYSAgfCAgICAgVmVyc2lvbjoNCiBTZXZlcml0eTogIC0gICAg ICAgICAgICB8ICBSZXNvbHV0aW9uOg0KIEtleXdvcmRzOiAgICAgICAgICAgICAgIHwNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0NCg0KVGlja2V0IFVSTDog PGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3NjaW0vdHJhYy90aWNrZXQvMTAjY29tbWVu dDoyPg0Kc2NpbSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3NjaW0vPg0KDQo= From kelly.grizzle@sailpoint.com Tue Sep 10 06:45:32 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FC421F9ACA for ; Tue, 10 Sep 2013 06:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSvKTtDnQRia for ; Tue, 10 Sep 2013 06:45:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id 0010F21F9A70 for ; Tue, 10 Sep 2013 06:45:21 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 10 Sep 2013 13:45:15 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) with mapi id 15.00.0745.000; Tue, 10 Sep 2013 13:45:15 +0000 From: Kelly Grizzle To: Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Agenda request for sept 18 Thread-Index: AQHOraDAbSkDhvOzRUS0x/Z/XD+wfZm+/Anw Date: Tue, 10 Sep 2013 13:45:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 267B547F00535C267B55CC x-originating-ip: [72.182.10.254] x-forefront-prvs: 096507C068 x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(377454003)(189002)(199002)(79102001)(69226001)(551544002)(80022001)(59766001)(77982001)(80976001)(83322001)(19580405001)(76482001)(19580395003)(83072001)(74662001)(74502001)(56776001)(81686001)(54316002)(81816001)(56816003)(77096001)(15975445006)(66066001)(81342001)(76576001)(76796001)(76786001)(65816001)(81542001)(51856001)(74316001)(54356001)(74366001)(46102001)(4396001)(47736001)(49866001)(53806001)(74706001)(15974865002)(31966008)(47446002)(63696002)(74876001)(33646001)(50986001)(47976001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:72.182.10.254; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Agenda request for sept 18 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 13:45:33 -0000 Regarding passwords, I would say that this is outside of the scope of SCIM = and should be handled by a complimentary protocol (eg - OpenID Connect). T= he charter explicitly excludes authn: The group considers the following out of scope for this group: Defining new authentication schemes To me, password validation (even with an authenticated SCIM request) seems = out of scope. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Monday, September 09, 2013 4:08 PM To: scim@ietf.org WG Subject: [scim] Agenda request for sept 18 * Sensitivity/index/returnability (see update on Item 10) * Passwords - Can passwords be validated? Regarding validating passwords, I= understand some want to keep this out of scope of SCIM.=20 Related to both above is the notion of mutability. Is an attribute write on= ly / read only / immutable, etc? Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Tue Sep 10 07:54:19 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BED11E81EB for ; Tue, 10 Sep 2013 07:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyXHx2g604Ob for ; Tue, 10 Sep 2013 07:54:12 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 93CDB11E81ED for ; Tue, 10 Sep 2013 07:53:39 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8AErc60016680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Sep 2013 14:53:39 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8AErb9r017066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Sep 2013 14:53:38 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8AErbDt019321; Tue, 10 Sep 2013 14:53:37 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Sep 2013 07:53:37 -0700 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <99FA57F5-74B2-48AF-B9C6-CD253AE935E0@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Tue, 10 Sep 2013 07:53:31 -0700 To: Kelly Grizzle X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "scim@ietf.org WG" Subject: Re: [scim] Agenda request for sept 18 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 14:54:19 -0000 I am not referring to authen mechanisms in scim. I am referring to password m= anagement only.=20 Phil On 2013-09-10, at 6:45, Kelly Grizzle wrote: > Regarding passwords, I would say that this is outside of the scope of SCIM= and should be handled by a complimentary protocol (eg - OpenID Connect). T= he charter explicitly excludes authn: >=20 > The group considers the following out of scope for this group: > Defining new authentication schemes >=20 >=20 > To me, password validation (even with an authenticated SCIM request) seems= out of scope. >=20 > --Kelly >=20 >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ph= il Hunt > Sent: Monday, September 09, 2013 4:08 PM > To: scim@ietf.org WG > Subject: [scim] Agenda request for sept 18 >=20 > * Sensitivity/index/returnability (see update on Item 10) >=20 > * Passwords - Can passwords be validated? Regarding validating passwords, I= understand some want to keep this out of scope of SCIM.=20 >=20 > Related to both above is the notion of mutability. Is an attribute write o= nly / read only / immutable, etc? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Tue Sep 10 08:23:30 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5C221F960E for ; Tue, 10 Sep 2013 08:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BrbsM+4+jCD for ; Tue, 10 Sep 2013 08:23:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB5421F99DE for ; Tue, 10 Sep 2013 08:23:16 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 10 Sep 2013 15:23:15 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) with mapi id 15.00.0745.000; Tue, 10 Sep 2013 15:23:15 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: [scim] Agenda request for sept 18 Thread-Index: AQHOraDAbSkDhvOzRUS0x/Z/XD+wfZm+/AnwgAATvYCAAAgNsA== Date: Tue, 10 Sep 2013 15:23:14 +0000 Message-ID: <056442e1432b48c395ad85ef1ba64243@BN1PR04MB392.namprd04.prod.outlook.com> References: <99FA57F5-74B2-48AF-B9C6-CD253AE935E0@oracle.com> In-Reply-To: <99FA57F5-74B2-48AF-B9C6-CD253AE935E0@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 26D506FE00535C26D5084B x-originating-ip: [2001:4870:600a:500::2] x-forefront-prvs: 096507C068 x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(13464003)(24454002)(377454003)(377424004)(199002)(189002)(47976001)(50986001)(33646001)(51856001)(74366001)(46102001)(54356001)(74706001)(74876001)(80022001)(53806001)(74316001)(56776001)(83072001)(49866001)(77982001)(31966008)(4396001)(63696002)(77096001)(81816001)(79102001)(47446002)(81686001)(65816001)(69226001)(15975445006)(74502001)(76482001)(19580395003)(59766001)(56816003)(54316002)(47736001)(81342001)(551544002)(15974865002)(80976001)(81542001)(74662001)(19580405001)(76796001)(83322001)(76576001)(76786001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:2001:4870:600a:500::2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org WG" Subject: Re: [scim] Agenda request for sept 18 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 15:23:30 -0000 What features do you think fall under password management? -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Tuesday, September 10, 2013 9:54 AM To: Kelly Grizzle Cc: scim@ietf.org WG Subject: Re: [scim] Agenda request for sept 18 I am not referring to authen mechanisms in scim. I am referring to password= management only.=20 Phil On 2013-09-10, at 6:45, Kelly Grizzle wrote: > Regarding passwords, I would say that this is outside of the scope of SCI= M and should be handled by a complimentary protocol (eg - OpenID Connect). = The charter explicitly excludes authn: >=20 > The group considers the following out of scope for this group: > Defining new authentication schemes >=20 >=20 > To me, password validation (even with an authenticated SCIM request) seem= s out of scope. >=20 > --Kelly >=20 >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of P= hil Hunt > Sent: Monday, September 09, 2013 4:08 PM > To: scim@ietf.org WG > Subject: [scim] Agenda request for sept 18 >=20 > * Sensitivity/index/returnability (see update on Item 10) >=20 > * Passwords - Can passwords be validated? Regarding validating passwords,= I understand some want to keep this out of scope of SCIM.=20 >=20 > Related to both above is the notion of mutability. Is an attribute write = only / read only / immutable, etc? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Tue Sep 10 09:06:09 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A91921E8136 for ; Tue, 10 Sep 2013 09:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01D4vPEd2+p4 for ; Tue, 10 Sep 2013 09:06:02 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1D921E814C for ; Tue, 10 Sep 2013 09:02:26 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8AG2M2Y006129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Sep 2013 16:02:23 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8AG2KX3020592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Sep 2013 16:02:21 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8AG2KiW022707; Tue, 10 Sep 2013 16:02:20 GMT Received: from [192.168.1.89] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Sep 2013 09:02:20 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Phil Hunt In-Reply-To: Date: Tue, 10 Sep 2013 09:02:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <21F50FE4-BD8E-4A61-9140-2E1E048F4F50@oracle.com> References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> To: Kelly Grizzle X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "scim@ietf.org" , "draft-ietf-scim-core-schema@tools.ietf.org" , scim issue tracker Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 16:06:13 -0000 Kelly, The problem is that if the index is anything other than "substring", = then the client has to restrict the type of filter it generates, since = the index may not be able to match using the filter specified. If the = filter result become unspecified (because index doesn't support filter = type) and a match should not occur, what should the server do? A. Throw an error B. Simply not match the entry Because of REST style and the public nature of these APIs, I would = rather avoid complex error messages and go with B. This means that = clients need discovery to find out what query filters are supported. It goes without saying I would be open to expanding index to = multi-valued and being specific as to what search filters are supported. = When I wrote the message below, I was thinking about the exact match = case and that it is different from substring. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-10, at 6:42 AM, Kelly Grizzle = wrote: > +1 for the "returned" attribute and its values. >=20 > Regarding "index", this might be overkill. Filters support different = operators (eq, sw, co) to do exact and substring matching. The index = just indicates server-side behavior about the most optimal way to query. = While this information isn't harmful, it may be more than what we need. >=20 > --Kelly >=20 >=20 > -----Original Message----- > From: scim issue tracker [mailto:trac+scim@tools.ietf.org]=20 > Sent: Monday, September 09, 2013 3:54 PM > To: draft-ietf-scim-core-schema@tools.ietf.org; Kelly Grizzle; = phil.hunt@oracle.com > Cc: scim@ietf.org > Subject: Re: [scim] #10: Add ability to mark attributes as sensitive = in the schemas >=20 > #10: Add ability to mark attributes as sensitive in the schemas >=20 >=20 > Comment (by phil.hunt@oracle.com): >=20 > I would like to propose a series of settings per attribute to cover = this issue. Under /schemas, each attribute would have the following > attributes: >=20 > "index"=3D"none"|"substring"|"exact" > "returned"=3D"always"|"never"|"default"|"request" >=20 > For example, password would have "index"=3D"exact" since the client = would > have to do an exact match, and "returned"=3D"never" since the value is = hashed and should not be returned. >=20 > Note: the index type will also depend on the value of caseExact. For = example caseExact =3D false means the search index is case insensitive. > caseExact=3D"true" means index is case sensitive. >=20 > "always" is used for attributes that must always be returned such as = "id" > "never" is used for write-only attributes that cannot or should not be = returned. > "default" is used by most attributes and means are returned if the = attribute param is missing. In other words the attribute is returned on = default. > "request" means that the attribute will only be returned if requested. > Note: this is similar to operational attributes in LDAP. >=20 > --=20 > = -------------------------+---------------------------------------------- > -------------------------+--- > Reporter: | Owner: draft-ietf-scim-core- > melinda.shore@gmail.com| schema@tools.ietf.org > Type: enhancement | Status: new > Priority: major | Milestone: > Component: core-schema | Version: > Severity: - | Resolution: > Keywords: | > = -------------------------+---------------------------------------------- > -------------------------+--- >=20 > Ticket URL: = > scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Tue Sep 10 10:12:58 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884B421E808E for ; Tue, 10 Sep 2013 10:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvVxYkdt+Cm4 for ; Tue, 10 Sep 2013 10:12:53 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 615C521E815F for ; Tue, 10 Sep 2013 10:12:53 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8AHCq67024883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Sep 2013 17:12:53 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8AHCpVR008073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Sep 2013 17:12:52 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8AHCp2A019604; Tue, 10 Sep 2013 17:12:51 GMT Received: from [192.168.1.89] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Sep 2013 10:12:51 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Phil Hunt In-Reply-To: <056442e1432b48c395ad85ef1ba64243@BN1PR04MB392.namprd04.prod.outlook.com> Date: Tue, 10 Sep 2013 10:12:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9566537E-8F2A-48E5-AA69-D6A6A0AFB8D7@oracle.com> References: <99FA57F5-74B2-48AF-B9C6-CD253AE935E0@oracle.com> <056442e1432b48c395ad85ef1ba64243@BN1PR04MB392.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "scim@ietf.org WG" Subject: Re: [scim] Agenda request for sept 18 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 17:12:58 -0000 There seems to be confusion between authentication "mechanism" and = "data". I don't believe management of authentication data is out of = scope. Quite the contrary, it is a major reason why clients do = provisioning. An authentication mechanism would be an actual function like "bind" that = is part of the protocol. This is not needed since SCIM is just a REST = API so the web server platform picks this up. The confusion may come = from LDAP, which in fact is its own access protocol and thus must have a = mechanism of its own. In contrast, SCIM sits on HTTP. Hence, then = authentication mechanism should be out of scope. A password by itself is just data (well data with security concerns). It = seems reasonable for a trusted client to be able to test a value just as = for any other attribute. It may be testing that value as part of a = change password service it is implementing (as an example). Such a = client may also want to maintain and evaluate other data like password = policy and password history.=20 The reason for discussing passwords on the call is because of the = possible special restriction on password attributes (can't be queried).=20= I would like to leave it open for the group to either include password = management in the base drafts, or more importantly write an extension = draft in the future. Either is fine by me. However, time is short for = agreement since many are either in production or are rapidly headed that = way. It seems like a good time to discuss the issue now. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-10, at 8:23 AM, Kelly Grizzle = wrote: > What features do you think fall under password management? >=20 >=20 > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Tuesday, September 10, 2013 9:54 AM > To: Kelly Grizzle > Cc: scim@ietf.org WG > Subject: Re: [scim] Agenda request for sept 18 >=20 > I am not referring to authen mechanisms in scim. I am referring to = password management only.=20 >=20 > Phil >=20 > On 2013-09-10, at 6:45, Kelly Grizzle = wrote: >=20 >> Regarding passwords, I would say that this is outside of the scope of = SCIM and should be handled by a complimentary protocol (eg - OpenID = Connect). The charter explicitly excludes authn: >>=20 >> The group considers the following out of scope for this group: >> Defining new authentication schemes >>=20 >>=20 >> To me, password validation (even with an authenticated SCIM request) = seems out of scope. >>=20 >> --Kelly >>=20 >>=20 >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Phil Hunt >> Sent: Monday, September 09, 2013 4:08 PM >> To: scim@ietf.org WG >> Subject: [scim] Agenda request for sept 18 >>=20 >> * Sensitivity/index/returnability (see update on Item 10) >>=20 >> * Passwords - Can passwords be validated? Regarding validating = passwords, I understand some want to keep this out of scope of SCIM.=20 >>=20 >> Related to both above is the notion of mutability. Is an attribute = write only / read only / immutable, etc? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From bjorn.aannestad@unboundid.com Tue Sep 10 12:52:02 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BD211E80E2 for ; Tue, 10 Sep 2013 12:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q88zndGddMC4 for ; Tue, 10 Sep 2013 12:51:56 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id 16D4D11E80AD for ; Tue, 10 Sep 2013 12:51:55 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id e14so2804008iej.38 for ; Tue, 10 Sep 2013 12:51:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=daiazD34oNcw3R7ZKAkAvrLeJQ9ZWCJi8MjIPjaMn9k=; b=WpV38/YfOCoi7y2DMkD9diIdnagSCVC5WQIGZjeXy7NY6/KpMV2k6qA/819DOevzxX pAx2+/Czfyi60DUwTSJWamdBlk9ovSBImk7lHEUu//9NCuXsD2G/gr00lkwHGzkGiOa9 qVH2VcM/V1cNlbGG8GHj5EZxL6zLCLoqYCASdnkBiZ3WuoGEh9ApSnWN6decuFpPfdAY iKT838fMBJjsDQnQZs4QUNgATN2xUpDdfyYgm9gmEnYsbrabcvUXtN1GgASjfm5/WR4l vNN3ZFlT4NLrZKtACWpP43+htUHc6gyV58Kyh/A737Ce7oTsnFweSwUO7fD7/XORQf3R N3rA== X-Gm-Message-State: ALoCoQke/chdb+PQpKC4jpl17lEMijjulZz3+bcTwu8Rwi79lPjSCdbWWb1SfxzuFfDVejNGuFjg X-Received: by 10.50.122.102 with SMTP id lr6mr11416981igb.0.1378842715490; Tue, 10 Sep 2013 12:51:55 -0700 (PDT) Received: from [10.8.1.116] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPSA id lp9sm1994962igb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Sep 2013 12:51:54 -0700 (PDT) Message-ID: <522F7859.9000109@unboundid.com> Date: Tue, 10 Sep 2013 14:51:53 -0500 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: scim@ietf.org References: <99FA57F5-74B2-48AF-B9C6-CD253AE935E0@oracle.com> <056442e1432b48c395ad85ef1ba64243@BN1PR04MB392.namprd04.prod.outlook.com> <9566537E-8F2A-48E5-AA69-D6A6A0AFB8D7@oracle.com> In-Reply-To: <9566537E-8F2A-48E5-AA69-D6A6A0AFB8D7@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Agenda request for sept 18 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:52:02 -0000 +1 -Bjorn On 2013-09-10 12:12 PM, Phil Hunt wrote: > There seems to be confusion between authentication "mechanism" and "data". I don't believe management of authentication data is out of scope. Quite the contrary, it is a major reason why clients do provisioning. > > An authentication mechanism would be an actual function like "bind" that is part of the protocol. This is not needed since SCIM is just a REST API so the web server platform picks this up. The confusion may come from LDAP, which in fact is its own access protocol and thus must have a mechanism of its own. In contrast, SCIM sits on HTTP. Hence, then authentication mechanism should be out of scope. > > A password by itself is just data (well data with security concerns). It seems reasonable for a trusted client to be able to test a value just as for any other attribute. It may be testing that value as part of a change password service it is implementing (as an example). Such a client may also want to maintain and evaluate other data like password policy and password history. > > The reason for discussing passwords on the call is because of the possible special restriction on password attributes (can't be queried). > > I would like to leave it open for the group to either include password management in the base drafts, or more importantly write an extension draft in the future. Either is fine by me. However, time is short for agreement since many are either in production or are rapidly headed that way. > > It seems like a good time to discuss the issue now. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > On 2013-09-10, at 8:23 AM, Kelly Grizzle wrote: > >> What features do you think fall under password management? >> >> >> -----Original Message----- >> From: Phil Hunt [mailto:phil.hunt@oracle.com] >> Sent: Tuesday, September 10, 2013 9:54 AM >> To: Kelly Grizzle >> Cc: scim@ietf.org WG >> Subject: Re: [scim] Agenda request for sept 18 >> >> I am not referring to authen mechanisms in scim. I am referring to password management only. >> >> Phil >> >> On 2013-09-10, at 6:45, Kelly Grizzle wrote: >> >>> Regarding passwords, I would say that this is outside of the scope of SCIM and should be handled by a complimentary protocol (eg - OpenID Connect). The charter explicitly excludes authn: >>> >>> The group considers the following out of scope for this group: >>> Defining new authentication schemes >>> >>> >>> To me, password validation (even with an authenticated SCIM request) seems out of scope. >>> >>> --Kelly >>> >>> >>> -----Original Message----- >>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt >>> Sent: Monday, September 09, 2013 4:08 PM >>> To: scim@ietf.org WG >>> Subject: [scim] Agenda request for sept 18 >>> >>> * Sensitivity/index/returnability (see update on Item 10) >>> >>> * Passwords - Can passwords be validated? Regarding validating passwords, I understand some want to keep this out of scope of SCIM. >>> >>> Related to both above is the notion of mutability. Is an attribute write only / read only / immutable, etc? >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From mdiodati@pingidentity.com Tue Sep 10 13:17:43 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A5721E80BE for ; Tue, 10 Sep 2013 13:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcmLijVCMQ0u for ; Tue, 10 Sep 2013 13:17:39 -0700 (PDT) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id 88D7A21E80C7 for ; Tue, 10 Sep 2013 13:17:38 -0700 (PDT) Received: from mail-ie0-f173.google.com ([209.85.223.173]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKUi9+YQtJKP5vjBEwjeh++wTR6L3Du6G2@postini.com; Tue, 10 Sep 2013 13:17:38 PDT Received: by mail-ie0-f173.google.com with SMTP id m16so1736533ieq.32 for ; Tue, 10 Sep 2013 13:17:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=KGg1PUuAvfDOtDpYEIkogo8KCDkgmF1CogzsDa159H4=; b=ZAIG7vXxXiNLVtQsnU01oWIgUze9aPPO5oKwaUyrMFR+yfaNFUOP+c4UW62CZQz3PR 59jQ6LGiayagBg+/g+DZhw188Dit0XaVjV2Lu9CCPIRD9tyPkQsdXJsueOgvwW4vVMgK GyIAWTAZqaMA41Qq7P/LYNYVSkeNbppZwbfHt3FfjumTZbkeGYeUyrVFOgXBAe7z/bBT 8IEypHoOaIRu79hzxgud7sE6NLn/DbwTw2tH48qH5s6fFL/fpLHIHm2HWwi7p3nhduRv bcGBlRdIByu2Nxc5mT5SVI8XGgqQwuVBohIosQ+ZWQXxUdnboK2HRq660oy+jtg7rhlr 1Xaw== X-Gm-Message-State: ALoCoQk0OYTp7LeT/QwphMdCjSVu145v+rdJstnb/dtfHcrnGpjDAKLZjjmJ4/vZAzg0fC5HLmtQlQb1tYrMxWqP+nl2TCUx1VDvkwk7kHO8braV0j+EgvYkh1UgXE2siZHWxTT8jLe9taRvuTfRRW1jW1DgtqqiVA== X-Received: by 10.50.43.170 with SMTP id x10mr11179648igl.45.1378844256779; Tue, 10 Sep 2013 13:17:36 -0700 (PDT) X-Received: by 10.50.43.170 with SMTP id x10mr11179645igl.45.1378844256651; Tue, 10 Sep 2013 13:17:36 -0700 (PDT) From: Mark Diodati References: <99FA57F5-74B2-48AF-B9C6-CD253AE935E0@oracle.com> <056442e1432b48c395ad85ef1ba64243@BN1PR04MB392.namprd04.prod.outlook.com> <9566537E-8F2A-48E5-AA69-D6A6A0AFB8D7@oracle.com> In-Reply-To: <9566537E-8F2A-48E5-AA69-D6A6A0AFB8D7@oracle.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGvlm7IIFcyWKJrjrI7fXNOyhwZsgIUL0kcAdV2FBEA5DrmUAFtMkfomcu6w6A= Date: Tue, 10 Sep 2013 15:17:35 -0500 Message-ID: <7a0eb946e206cf8c5c85e31f58da85f1@mail.gmail.com> To: Phil Hunt , Kelly Grizzle Content-Type: text/plain; charset=ISO-8859-1 Cc: scim@ietf.org Subject: Re: [scim] Agenda request for sept 18 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 20:17:43 -0000 Hi All, It would be nice to see a tightly scoped, limited authentication capability, for password only (today). The consumer could POST with uname/password combination to a common authentication endpoint, then receive a response. I suppose that introduces a requirement for uniqueness on the attribute that functions as the uname. There is precedence for adding a bare-bones authentication method to a (primarily) provisioning protocol. Perhaps with the presence of growing long-term demand for authentication functionality within SCIM, we could explore other authentication options like . Mark -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Tuesday, September 10, 2013 12:13 PM To: Kelly Grizzle Cc: scim@ietf.org WG Subject: Re: [scim] Agenda request for sept 18 There seems to be confusion between authentication "mechanism" and "data". I don't believe management of authentication data is out of scope. Quite the contrary, it is a major reason why clients do provisioning. An authentication mechanism would be an actual function like "bind" that is part of the protocol. This is not needed since SCIM is just a REST API so the web server platform picks this up. The confusion may come from LDAP, which in fact is its own access protocol and thus must have a mechanism of its own. In contrast, SCIM sits on HTTP. Hence, then authentication mechanism should be out of scope. A password by itself is just data (well data with security concerns). It seems reasonable for a trusted client to be able to test a value just as for any other attribute. It may be testing that value as part of a change password service it is implementing (as an example). Such a client may also want to maintain and evaluate other data like password policy and password history. The reason for discussing passwords on the call is because of the possible special restriction on password attributes (can't be queried). I would like to leave it open for the group to either include password management in the base drafts, or more importantly write an extension draft in the future. Either is fine by me. However, time is short for agreement since many are either in production or are rapidly headed that way. It seems like a good time to discuss the issue now. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-10, at 8:23 AM, Kelly Grizzle wrote: > What features do you think fall under password management? > > > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Tuesday, September 10, 2013 9:54 AM > To: Kelly Grizzle > Cc: scim@ietf.org WG > Subject: Re: [scim] Agenda request for sept 18 > > I am not referring to authen mechanisms in scim. I am referring to password management only. > > Phil > > On 2013-09-10, at 6:45, Kelly Grizzle wrote: > >> Regarding passwords, I would say that this is outside of the scope of SCIM and should be handled by a complimentary protocol (eg - OpenID Connect). The charter explicitly excludes authn: >> >> The group considers the following out of scope for this group: >> Defining new authentication schemes >> >> >> To me, password validation (even with an authenticated SCIM request) seems out of scope. >> >> --Kelly >> >> >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt >> Sent: Monday, September 09, 2013 4:08 PM >> To: scim@ietf.org WG >> Subject: [scim] Agenda request for sept 18 >> >> * Sensitivity/index/returnability (see update on Item 10) >> >> * Passwords - Can passwords be validated? Regarding validating passwords, I understand some want to keep this out of scope of SCIM. >> >> Related to both above is the notion of mutability. Is an attribute write only / read only / immutable, etc? >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Tue Sep 10 13:32:54 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58E521E808D for ; Tue, 10 Sep 2013 13:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMxICy+LOo3I for ; Tue, 10 Sep 2013 13:32:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0156.outbound.protection.outlook.com [207.46.163.156]) by ietfa.amsl.com (Postfix) with ESMTP id 53CC921E8050 for ; Tue, 10 Sep 2013 13:32:49 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 10 Sep 2013 20:32:48 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) with mapi id 15.00.0745.000; Tue, 10 Sep 2013 20:32:48 +0000 From: Kelly Grizzle To: Mark Diodati , Phil Hunt Thread-Topic: [scim] Agenda request for sept 18 Thread-Index: AQHOraDAbSkDhvOzRUS0x/Z/XD+wfZm+/AnwgAATvYCAAAgNsIAAHt6AgAAzoICAAAF9kA== Date: Tue, 10 Sep 2013 20:32:48 +0000 Message-ID: References: <99FA57F5-74B2-48AF-B9C6-CD253AE935E0@oracle.com> <056442e1432b48c395ad85ef1ba64243@BN1PR04MB392.namprd04.prod.outlook.com> <9566537E-8F2A-48E5-AA69-D6A6A0AFB8D7@oracle.com> <7a0eb946e206cf8c5c85e31f58da85f1@mail.gmail.com> In-Reply-To: <7a0eb946e206cf8c5c85e31f58da85f1@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 27F06F1800536227F07065 x-originating-ip: [10.255.93.4] x-forefront-prvs: 096507C068 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(377424004)(189002)(13464003)(51704005)(24454002)(53754006)(377454003)(79102001)(81686001)(47446002)(63696002)(81816001)(77096001)(74662001)(19580405001)(15975445006)(65816001)(69226001)(74502001)(56776001)(53806001)(74316001)(49866001)(83072001)(4396001)(77982001)(31966008)(76796001)(80976001)(81542001)(76786001)(83322001)(76576001)(59766001)(56816003)(54316002)(19580395003)(76482001)(15202345003)(81342001)(551544002)(15974865002)(47736001)(33646001)(50986001)(47976001)(74706001)(80022001)(74876001)(51856001)(74366001)(46102001)(54356001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:10.255.93.4; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] Agenda request for sept 18 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 20:32:54 -0000 I totally agree with the need to manage passwords. Issue #14 (http://trac.= tools.ietf.org/wg/scim/trac/ticket/14) is geared toward some enhancements a= round this. And I'm starting to see your point on the ability to test a password. Like= Mark said, if we do something here, it feels like it should be very tightl= y scoped. What about something like doing a POST-based search to the speci= fic user that you want to test: POST /v1/Users/12345/.search filter=3Dpassword eq "s3cret!" This specific pattern could be extended to provide slightly more informatio= n in the response to indicate the results (eg - expired password, locked ac= count, etc...). --Kelly -----Original Message----- From: Mark Diodati [mailto:mdiodati@pingidentity.com]=20 Sent: Tuesday, September 10, 2013 3:18 PM To: Phil Hunt; Kelly Grizzle Cc: scim@ietf.org Subject: RE: [scim] Agenda request for sept 18 Hi All, It would be nice to see a tightly scoped, limited authentication capability= , for password only (today). The consumer could POST with uname/password co= mbination to a common authentication endpoint, then receive a response. I s= uppose that introduces a requirement for uniqueness on the attribute that f= unctions as the uname. There is precedence for adding a bare-bones authenti= cation method to a (primarily) provisioning protocol. Perhaps with the presence of growing long-term demand for authentication fu= nctionality within SCIM, we could explore other authentication options like= . Mark -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Tuesday, September 10, 2013 12:13 PM To: Kelly Grizzle Cc: scim@ietf.org WG Subject: Re: [scim] Agenda request for sept 18 There seems to be confusion between authentication "mechanism" and "data". I don't believe management of authentication data is out of scope. Quite t= he contrary, it is a major reason why clients do provisioning. An authentication mechanism would be an actual function like "bind" that is= part of the protocol. This is not needed since SCIM is just a REST API so = the web server platform picks this up. The confusion may come from LDAP, w= hich in fact is its own access protocol and thus must have a mechanism of i= ts own. In contrast, SCIM sits on HTTP. Hence, then authentication mechani= sm should be out of scope. A password by itself is just data (well data with security concerns). It se= ems reasonable for a trusted client to be able to test a value just as for = any other attribute. It may be testing that value as part of a change passw= ord service it is implementing (as an example). Such a client may also wan= t to maintain and evaluate other data like password policy and password his= tory. The reason for discussing passwords on the call is because of the possible = special restriction on password attributes (can't be queried). I would like to leave it open for the group to either include password mana= gement in the base drafts, or more importantly write an extension draft in = the future. Either is fine by me. However, time is short for agreement sin= ce many are either in production or are rapidly headed that way. It seems like a good time to discuss the issue now. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-10, at 8:23 AM, Kelly Grizzle wrote: > What features do you think fall under password management? > > > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Tuesday, September 10, 2013 9:54 AM > To: Kelly Grizzle > Cc: scim@ietf.org WG > Subject: Re: [scim] Agenda request for sept 18 > > I am not referring to authen mechanisms in scim. I am referring to password management only. > > Phil > > On 2013-09-10, at 6:45, Kelly Grizzle wrote: > >> Regarding passwords, I would say that this is outside of the scope of SCIM and should be handled by a complimentary protocol (eg - OpenID Connect= ). The charter explicitly excludes authn: >> >> The group considers the following out of scope for this group: >> Defining new authentication schemes >> >> >> To me, password validation (even with an authenticated SCIM request) seems out of scope. >> >> --Kelly >> >> >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf=20 >> Of Phil Hunt >> Sent: Monday, September 09, 2013 4:08 PM >> To: scim@ietf.org WG >> Subject: [scim] Agenda request for sept 18 >> >> * Sensitivity/index/returnability (see update on Item 10) >> >> * Passwords - Can passwords be validated? Regarding validating passwords, I understand some want to keep this out of scope of SCIM. >> >> Related to both above is the notion of mutability. Is an attribute write only / read only / immutable, etc? >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From leifj@mnt.se Tue Sep 10 13:42:14 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C22111E8145 for ; Tue, 10 Sep 2013 13:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4yCLriXrYvJ for ; Tue, 10 Sep 2013 13:42:05 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0C62211E8137 for ; Tue, 10 Sep 2013 13:42:04 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id q8so6797715lbi.11 for ; Tue, 10 Sep 2013 13:42:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rxzBrse+9JLJ8fL4sL3Wzo2clmJ0H/9KuoRTVdiyLNQ=; b=b2QRsfW+mrzvBsmEi/XCcdIkxwm4L/P/zefUQL5uep0e80xKJCUaQqUttfCBImesNC RssRUl8dbG3lNHRnBx+5RbyzkAl6g78zHAv8Bc794kyGeT8Xg8X83pjXROQJxHb+6Gkc SM9Hvb7jazgQicb2ZS8CcXUwOD9xYggzymxTOdIH4sFwq83h0CGBmWlW5FUimMRgIv57 SyjB2s90EVMOy0YV4x9l8wfoGHbTJlT22+f+TG8qEBqrzpZtFkNR/6E0a9ysjBMjb6fn AbZzH78OaNAV7j+CKACJpqQtDyufYpTv8+JmZGSHvEiS9yRLGAlAQVUjO17GrRXejiTd x8lA== X-Gm-Message-State: ALoCoQn7/hncTZddTyXwJKpUQM6LNNF7jaco9QATxM47z3NVl5/BCxVMR8Ar/dyOvx6kfuaDPceh X-Received: by 10.152.44.225 with SMTP id h1mr23074193lam.15.1378845723483; Tue, 10 Sep 2013 13:42:03 -0700 (PDT) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id ua4sm9498825lbb.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Sep 2013 13:42:02 -0700 (PDT) Message-ID: <522F8418.4050303@mnt.se> Date: Tue, 10 Sep 2013 22:42:00 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: scim@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] Agenda request for sept 18 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 20:42:14 -0000 On 09/09/2013 11:07 PM, Phil Hunt wrote: > * Sensitivity/index/returnability (see update on Item 10) > * Passwords - Can passwords be validated? Regarding validating passwords, I understand some want to keep this out of scope of SCIM. > > Related to both above is the notion of mutability. Is an attribute write only / read only / immutable, etc? Looks like we're getting this done on the list instead. > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From samuel@erdtman.se Wed Sep 11 10:19:35 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9FA11E824C for ; Wed, 11 Sep 2013 10:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4eiDbZ2bfpB for ; Wed, 11 Sep 2013 10:19:31 -0700 (PDT) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id DF78D21F9FC9 for ; Wed, 11 Sep 2013 10:18:54 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c1so4697266eek.24 for ; Wed, 11 Sep 2013 10:18:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=21NLn0tS7Z0z9BK/GKdWqGqbSlJ6gkS1YixoyB2IL+k=; b=JtQBHsOvtpS/dwnnVaU6elvltV4xFsxrJYUNF4myNgz43p/oxQ57osKMUMas/IRMY9 bwU4whzdus+YkVuDnfduSrmL+IUnbcATJ+sDWAcr0mNfcTRRNOa4G5SE5N4iNd1QaCEN joLeGkvr8HrpXz41kiJ0AJAm3vcj0+5RT97yb1wwwz0pHBQzF/gj92cWTpg752f+IB9x QvuJeDKaVTsvQgusLbFgCwLu+x9L7h2/LfaZkSa0WcgZQ/sgXgg8XxrghnKo+QrBLsw4 iGJLmmk3aZ5eX3D9dU8NpnbjwihZkrKHBmTVaeoN1++L+X+uA3G5Q7b97ysTxSXPUUfD Bwlg== X-Gm-Message-State: ALoCoQly9dC2ynYwe3CT7obSMY7SpT0qKC1dt1W3GHjQPS87aNC/OrkqHTxdriVbbdztNM+Z//2M MIME-Version: 1.0 X-Received: by 10.14.39.73 with SMTP id c49mr3712163eeb.61.1378919931935; Wed, 11 Sep 2013 10:18:51 -0700 (PDT) Received: by 10.14.147.5 with HTTP; Wed, 11 Sep 2013 10:18:51 -0700 (PDT) In-Reply-To: <21F50FE4-BD8E-4A61-9140-2E1E048F4F50@oracle.com> References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> <21F50FE4-BD8E-4A61-9140-2E1E048F4F50@oracle.com> Date: Wed, 11 Sep 2013 18:18:51 +0100 Message-ID: From: Samuel Erdtman To: Phil Hunt Content-Type: multipart/alternative; boundary=089e01681aa2b7b86d04e61ed04e Cc: "scim@ietf.org" , scim issue tracker , "draft-ietf-scim-core-schema@tools.ietf.org" , Kelly Grizzle Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 17:19:35 -0000 --089e01681aa2b7b86d04e61ed04e Content-Type: text/plain; charset=ISO-8859-1 I agree with Kelly. +1 for returned And for index I cannot se the benefit. What is the use case that needs this? Cheers //Samuel On Tue, Sep 10, 2013 at 5:02 PM, Phil Hunt wrote: > Kelly, > > The problem is that if the index is anything other than "substring", then > the client has to restrict the type of filter it generates, since the index > may not be able to match using the filter specified. If the filter result > become unspecified (because index doesn't support filter type) and a match > should not occur, what should the server do? > A. Throw an error > B. Simply not match the entry > > Because of REST style and the public nature of these APIs, I would rather > avoid complex error messages and go with B. This means that clients need > discovery to find out what query filters are supported. > > It goes without saying I would be open to expanding index to multi-valued > and being specific as to what search filters are supported. When I wrote > the message below, I was thinking about the exact match case and that it is > different from substring. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > On 2013-09-10, at 6:42 AM, Kelly Grizzle > wrote: > > > +1 for the "returned" attribute and its values. > > > > Regarding "index", this might be overkill. Filters support different > operators (eq, sw, co) to do exact and substring matching. The index just > indicates server-side behavior about the most optimal way to query. While > this information isn't harmful, it may be more than what we need. > > > > --Kelly > > > > > > -----Original Message----- > > From: scim issue tracker [mailto:trac+scim@tools.ietf.org] > > Sent: Monday, September 09, 2013 3:54 PM > > To: draft-ietf-scim-core-schema@tools.ietf.org; Kelly Grizzle; > phil.hunt@oracle.com > > Cc: scim@ietf.org > > Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in > the schemas > > > > #10: Add ability to mark attributes as sensitive in the schemas > > > > > > Comment (by phil.hunt@oracle.com): > > > > I would like to propose a series of settings per attribute to cover this > issue. Under /schemas, each attribute would have the following > > attributes: > > > > "index"="none"|"substring"|"exact" > > "returned"="always"|"never"|"default"|"request" > > > > For example, password would have "index"="exact" since the client would > > have to do an exact match, and "returned"="never" since the value is > hashed and should not be returned. > > > > Note: the index type will also depend on the value of caseExact. For > example caseExact = false means the search index is case insensitive. > > caseExact="true" means index is case sensitive. > > > > "always" is used for attributes that must always be returned such as "id" > > "never" is used for write-only attributes that cannot or should not be > returned. > > "default" is used by most attributes and means are returned if the > attribute param is missing. In other words the attribute is returned on > default. > > "request" means that the attribute will only be returned if requested. > > Note: this is similar to operational attributes in LDAP. > > > > -- > > -------------------------+---------------------------------------------- > > -------------------------+--- > > Reporter: | Owner: draft-ietf-scim-core- > > melinda.shore@gmail.com| schema@tools.ietf.org > > Type: enhancement | Status: new > > Priority: major | Milestone: > > Component: core-schema | Version: > > Severity: - | Resolution: > > Keywords: | > > -------------------------+---------------------------------------------- > > -------------------------+--- > > > > Ticket URL: > > > scim > > > > _______________________________________________ > > scim mailing list > > scim@ietf.org > > https://www.ietf.org/mailman/listinfo/scim > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > --089e01681aa2b7b86d04e61ed04e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with Kelly.
+1 for returned
And for = index I cannot se the benefit. What is the use case that needs this?
<= div>
Cheers
//Samuel


On Tue, Sep 10, 2013 at 5:02 PM, Phil Hu= nt <phil.hunt@oracle.com> wrote:
Kelly,

The problem is that if the index is anything other than "substring&quo= t;, then the client has to restrict the type of filter it generates, since = the index may not be able to match using the filter specified. If the filte= r result become unspecified (because index doesn't support filter type)= and a match should not occur, what should the server do?
A. =A0Throw an error
B. =A0Simply not match the entry

Because of REST style and the public nature of these APIs, I would rather a= void complex error messages and go with B. This means that clients need dis= covery to find out what query filters are supported.

It goes without saying I would be open to expanding index to multi-valued a= nd being specific as to what search filters are supported. =A0When I wrote = the message below, I was thinking about the exact match case and that it is= different from substring.

Phil

@independentid
www.independenti= d.com
phil.hunt@oracle.com







On 2013-09-10, at 6:42 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

> +1 for the "returned" attribute and its values.
>
> Regarding "index", this might be overkill. =A0Filters suppor= t different operators (eq, sw, co) to do exact and substring matching. =A0T= he index just indicates server-side behavior about the most optimal way to = query. =A0While this information isn't harmful, it may be more than wha= t we need.
>
> --Kelly
>
>
> -----Original Message-----
> From: scim issue tracker [mailto:trac+scim@tools.ietf.org]
> Sent: Monday, September 09, 2013 3:54 PM
> To: draf= t-ietf-scim-core-schema@tools.ietf.org; Kelly Grizzle; phil.hunt@oracle.com
> Cc: scim@ietf.org
> Subject: Re: [scim] #10: Add ability to mark attributes as sensitive i= n the schemas
>
> #10: Add ability to mark attributes as sensitive in the schemas
>
>
> Comment (by phil.hunt@oracle.c= om):
>
> I would like to propose a series of settings per attribute to cover th= is =A0issue. =A0Under /schemas, each attribute would have the following
> attributes:
>
> "index"=3D"none"|"substring"|"exact= "
> "returned"=3D"always"|"never"|"defa= ult"|"request"
>
> For example, password would have =A0 "index"=3D"exact&q= uot; since the client would
> have to do an exact match, and "returned"=3D"never"= ; since the value is =A0hashed and should not be returned.
>
> Note: =A0the index type will also depend on the value of caseExact. Fo= r =A0example caseExact =3D false means the search index is case insensitive= .
> caseExact=3D"true" means index is case sensitive.
>
> "always" is used for attributes that must always be returned= such as "id"
> "never" is used for write-only attributes that cannot or sho= uld not be =A0returned.
> "default" is used by most attributes and means are returned = if the =A0attribute param is missing. In other words the attribute is retur= ned on =A0default.
> "request" means that the attribute will only be returned if = requested.
> Note: this is similar to operational attributes in LDAP.
>
> --
> -------------------------+--------------------------------------------= --
> -------------------------+---
> Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: =A0draft-ie= tf-scim-core-
> =A0melinda.shore@gmail.com<= /a>| =A0schema@tools.ietf.org<= br> > =A0 =A0 Type: =A0enhancement =A0| =A0 =A0 =A0Status: =A0new
> Priority: =A0major =A0 =A0 =A0 =A0| =A0 Milestone:
> Component: =A0core-schema =A0| =A0 =A0 Version:
> Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0| =A0Resolution:
> Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> -------------------------+--------------------------------------------= --
> -------------------------+---
>
> Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac= /ticket/10#comment:2>
> scim <htt= p://tools.ietf.org/scim/>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim

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

--089e01681aa2b7b86d04e61ed04e-- From phil.hunt@oracle.com Wed Sep 11 10:20:30 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4579111E8269 for ; Wed, 11 Sep 2013 10:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDNiRiF9fFLB for ; Wed, 11 Sep 2013 10:20:08 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEBA11E8240 for ; Wed, 11 Sep 2013 10:19:27 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8BHJ2OW019624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Sep 2013 17:19:03 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8BHJ2NF026417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Sep 2013 17:19:02 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8BHJ1vP026404 for ; Wed, 11 Sep 2013 17:19:01 GMT Received: from [192.168.1.89] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Sep 2013 10:19:01 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_3D5B7CAB-1559-44B2-A172-0E2C8659AF9A" Message-Id: <026D72FC-9C7C-4E33-8E64-AC13FC426B06@oracle.com> Date: Wed, 11 Sep 2013 10:18:59 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [scim] extended schema: clarifications on operations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 17:20:30 -0000 --Apple-Mail=_3D5B7CAB-1559-44B2-A172-0E2C8659AF9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In implementing the new 02 draft, a couple of questions have come up = regarding operations against attributes that are part of extended schema = (e.g. enterprise User). This not only impacts search filters and = attribute retrieval parameters, but also impacts PATCH and other = operations. My general feeling is that when the attribute is unique, the client MAY = use the attribute name alone. However, if the attribute name is not = unique, the operation may fail (what error should be indicated?). Further,=20 Clients may fully qualify an address an attribute by prefixing the = attribute name with the schema urn + ":". The right-most colon = separates the attribute name from the URN. [[Should we choose a = different separator?]] For example with an enterpriseUser (part of the core schema), a client = may use displayName or = urn:scim:schemas:extension:enterprise:2.0:User:displayName to refer to = the attribute. =20 For PATCH a fully qualified update would look like: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:2.0:Group"], "urn:scim:schemas:core:2.0:Group:members": [ { "display": "Babs Jensen", "$ref": = "https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646", "value": "2819c223-7f76-453a-919d-413861904646" } ] } Note that in this case, "display", "$ref", and "value" do not have to = have the fully qualified name since the context is known from the parent = "members" attribute. I will follow this up with a new ticket. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_3D5B7CAB-1559-44B2-A172-0E2C8659AF9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In = implementing the new 02 draft, a couple of questions have come up = regarding operations against attributes that are part of extended schema = (e.g. enterprise User).  This not only impacts search filters and = attribute retrieval parameters, but also impacts PATCH and other = operations.

My general feeling is that when the = attribute is unique, the client MAY use the attribute name alone. = However, if the attribute name is not unique, the operation may fail = (what error should be = indicated?).

Further, 
Clients = may fully qualify an address an attribute by prefixing the attribute = name with the schema urn + ":".  The right-most colon separates the = attribute name from the URN.  [[Should we choose a different = separator?]]

For example with an enterpriseUser = (part of the core schema), a client may use displayName or  PATCH = /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json 
   Content-Type: =
application/json
   Authorization: Bearer h480djs93hd8
   If-Match: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:2.0:Group"],
     "members": [
       {
         "display": "Babs Jensen",
         "$ref": "https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
         "value": "2819c223-7f76-453a-919d-413861904646"
       }
     ]
   }

Note that in this case, = "display", "$ref", and "value" do not have to have the fully qualified = name since the context is known from the parent "members" = attribute.

I will follow this up with a new = ticket.

= --Apple-Mail=_3D5B7CAB-1559-44B2-A172-0E2C8659AF9A-- From phil.hunt@oracle.com Wed Sep 11 11:05:40 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0375821E80A3 for ; Wed, 11 Sep 2013 11:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaUy15-VIXrD for ; Wed, 11 Sep 2013 11:05:34 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF5C11E80A2 for ; Wed, 11 Sep 2013 11:05:32 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8BI4xPK003400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Sep 2013 18:04:59 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8BI4vm3020710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Sep 2013 18:04:58 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8BI4v7f013275; Wed, 11 Sep 2013 18:04:57 GMT Received: from [192.168.1.89] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Sep 2013 11:04:54 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_256B2C01-D5E3-4A2D-B455-D52E1F0DD7B5" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Phil Hunt In-Reply-To: Date: Wed, 11 Sep 2013 11:04:30 -0700 Message-Id: References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> <21F50FE4-BD8E-4A61-9140-2E1E048F4F50@oracle.com> To: Samuel Erdtman X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "scim@ietf.org" , "draft-ietf-scim-core-schema@tools.ietf.org" , scim issue tracker , Kelly Grizzle Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 18:05:40 -0000 --Apple-Mail=_256B2C01-D5E3-4A2D-B455-D52E1F0DD7B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Samuel, Regarding use case for index discovery=85. Building a user self-service component that allows searching for = colleages/friends, whatever. The UI needs to know what attributes are = searchable and what search queries are allowed (exact, startsWith, = endsWith, isLike, substring, etc). The UI could be client side tool that allows an administrator to query = the data each of the cloud service providers they use. The implication from an inter-op perspective is that either all SCIM SPs = support substring indexing of all attributes, OR deployers can set = specific indexes based on their performance needs and abilities. If the = latter, the client has to know in order to know what searches are = possible. It is doubtful that many of us can support substring indexing of all = attributes. Putting aside the performance issue, there are issues with = some attributes where privacy or security would block partial match = searches and only exact match searches would be allowed - very much = acting like an 'Identity Oracle'. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-11, at 10:18 AM, Samuel Erdtman wrote: > I agree with Kelly. > +1 for returned > And for index I cannot se the benefit. What is the use case that needs = this? >=20 > Cheers > //Samuel >=20 >=20 > On Tue, Sep 10, 2013 at 5:02 PM, Phil Hunt = wrote: > Kelly, >=20 > The problem is that if the index is anything other than "substring", = then the client has to restrict the type of filter it generates, since = the index may not be able to match using the filter specified. If the = filter result become unspecified (because index doesn't support filter = type) and a match should not occur, what should the server do? > A. Throw an error > B. Simply not match the entry >=20 > Because of REST style and the public nature of these APIs, I would = rather avoid complex error messages and go with B. This means that = clients need discovery to find out what query filters are supported. >=20 > It goes without saying I would be open to expanding index to = multi-valued and being specific as to what search filters are supported. = When I wrote the message below, I was thinking about the exact match = case and that it is different from substring. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 2013-09-10, at 6:42 AM, Kelly Grizzle = wrote: >=20 > > +1 for the "returned" attribute and its values. > > > > Regarding "index", this might be overkill. Filters support = different operators (eq, sw, co) to do exact and substring matching. = The index just indicates server-side behavior about the most optimal way = to query. While this information isn't harmful, it may be more than = what we need. > > > > --Kelly > > > > > > -----Original Message----- > > From: scim issue tracker [mailto:trac+scim@tools.ietf.org] > > Sent: Monday, September 09, 2013 3:54 PM > > To: draft-ietf-scim-core-schema@tools.ietf.org; Kelly Grizzle; = phil.hunt@oracle.com > > Cc: scim@ietf.org > > Subject: Re: [scim] #10: Add ability to mark attributes as sensitive = in the schemas > > > > #10: Add ability to mark attributes as sensitive in the schemas > > > > > > Comment (by phil.hunt@oracle.com): > > > > I would like to propose a series of settings per attribute to cover = this issue. Under /schemas, each attribute would have the following > > attributes: > > > > "index"=3D"none"|"substring"|"exact" > > "returned"=3D"always"|"never"|"default"|"request" > > > > For example, password would have "index"=3D"exact" since the = client would > > have to do an exact match, and "returned"=3D"never" since the value = is hashed and should not be returned. > > > > Note: the index type will also depend on the value of caseExact. = For example caseExact =3D false means the search index is case = insensitive. > > caseExact=3D"true" means index is case sensitive. > > > > "always" is used for attributes that must always be returned such as = "id" > > "never" is used for write-only attributes that cannot or should not = be returned. > > "default" is used by most attributes and means are returned if the = attribute param is missing. In other words the attribute is returned on = default. > > "request" means that the attribute will only be returned if = requested. > > Note: this is similar to operational attributes in LDAP. > > > > -- > > = -------------------------+---------------------------------------------- > > -------------------------+--- > > Reporter: | Owner: draft-ietf-scim-core- > > melinda.shore@gmail.com| schema@tools.ietf.org > > Type: enhancement | Status: new > > Priority: major | Milestone: > > Component: core-schema | Version: > > Severity: - | Resolution: > > Keywords: | > > = -------------------------+---------------------------------------------- > > -------------------------+--- > > > > Ticket URL: = > > scim > > > > _______________________________________________ > > scim mailing list > > scim@ietf.org > > https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_256B2C01-D5E3-4A2D-B455-D52E1F0DD7B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 2013-09-11, at 10:18 AM, Samuel Erdtman <samuel@erdtman.se> = wrote:

I agree with Kelly.
+1 for = returned
And for index I cannot se the benefit. What is the = use case that needs = this?

Cheers
//Samuel


On Tue, Sep 10, 2013 at 5:02 PM, Phil = Hunt <phil.hunt@oracle.com> = wrote:
Kelly,

The problem is that if the index is anything other than "substring", = then the client has to restrict the type of filter it generates, since = the index may not be able to match using the filter specified. If the = filter result become unspecified (because index doesn't support filter = type) and a match should not occur, what should the server do?
A.  Throw an error
B.  Simply not match the entry

Because of REST style and the public nature of these APIs, I would = rather avoid complex error messages and go with B. This means that = clients need discovery to find out what query filters are supported.

It goes without saying I would be open to expanding index to = multi-valued and being specific as to what search filters are supported. =  When I wrote the message below, I was thinking about the exact = match case and that it is different from substring.

Phil

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







On 2013-09-10, at 6:42 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

> +1 for the "returned" attribute and its values.
>
> Regarding "index", this might be overkill.  Filters support = different operators (eq, sw, co) to do exact and substring matching. =  The index just indicates server-side behavior about the most = optimal way to query.  While this information isn't harmful, it may = be more than what we need.
>
> --Kelly
>
>
> -----Original Message-----
> From: scim issue tracker [mailto:trac+scim@tools.ietf.org] > Sent: Monday, September 09, 2013 3:54 PM
> To: draft-ietf-scim= -core-schema@tools.ietf.org; Kelly Grizzle; phil.hunt@oracle.com
> Cc: scim@ietf.org
> Subject: Re: [scim] #10: Add ability to mark attributes as = sensitive in the schemas
>
> #10: Add ability to mark attributes as sensitive in the schemas
>
>
> Comment (by phil.hunt@oracle.com):
>
> I would like to propose a series of settings per attribute to cover = this  issue.  Under /schemas, each attribute would have the = following
> attributes:
>
> "index"=3D"none"|"substring"|"exact"
> "returned"=3D"always"|"never"|"default"|"request"
>
> For example, password would have   "index"=3D"exact" since the = client would
> have to do an exact match, and "returned"=3D"never" since the value = is  hashed and should not be returned.
>
> Note:  the index type will also depend on the value of = caseExact. For  example caseExact =3D false means the search index = is case insensitive.
> caseExact=3D"true" means index is case sensitive.
>
> "always" is used for attributes that must always be returned such = as "id"
> "never" is used for write-only attributes that cannot or should not = be  returned.
> "default" is used by most attributes and means are returned if the =  attribute param is missing. In other words the attribute is = returned on  default.
> "request" means that the attribute will only be returned if = requested.
> Note: this is similar to operational attributes in LDAP.
>
> --
> = -------------------------+---------------------------------------------- > -------------------------+---
> Reporter:               |   =     Owner:  draft-ietf-scim-core-
>  melinda.shore@gmail.com| =  schema@tools.ietf.org
>     Type:  enhancement  |     =  Status:  new
> Priority:  major        |   = Milestone:
> Component:  core-schema  |     Version:
> Severity:  -            | =  Resolution:
> Keywords:               |
> = -------------------------+---------------------------------------------- > -------------------------+---
>
> Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac/ticket/10#commen= t:2>
> scim <http://tools.ietf.org/scim/>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim

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

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

= --Apple-Mail=_256B2C01-D5E3-4A2D-B455-D52E1F0DD7B5-- From samuel@erdtman.se Thu Sep 12 12:18:54 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5773111E80A2 for ; Thu, 12 Sep 2013 12:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT0dPOpKynAz for ; Thu, 12 Sep 2013 12:18:50 -0700 (PDT) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 3C52D21E80C1 for ; Thu, 12 Sep 2013 12:18:45 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e52so114509eek.2 for ; Thu, 12 Sep 2013 12:18:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3hdYWaVzGdDGRic9FnwDvbNkEcJdNnL384Buw2+a990=; b=krA8Iqh7OxQfO4je8wydbii/3/wzB5xHB2P4gUFnuNsWd8xwpvgTwSAsjO0ONN+nej g8/dp6rHE5gyVTo59wvEqQl+kZsvLk6V5N5pCwiLv1i4z8II3MtUZoHB3jjPabq6N5ma MvqIkPWj04Q2x+d2RFz4L/9TSJgRerMxGOBgrrm6hmankWzsl9yRzTpljWcLSKc4pWVW s8Pnz6g+w2bJf3P4IfZWVseDH6jhWj8Mr83rVkVp0u12EVL5MQ/aZ2VvOaUwdXFQ5x6r NDlWI417eEOm7lhy3XGnG3mNsWeR2Gvksf4XrKJ+dSbFeC00WjeZ8ffAQ86zEgsDK5Th XO+Q== X-Gm-Message-State: ALoCoQlnmDtu6QOTJWDlLqK1EgvvBELP6X8ZOhskNAqRBSD1a4+vw6Rtpr2q0PcQmJaGlOgwu2Eb MIME-Version: 1.0 X-Received: by 10.14.193.198 with SMTP id k46mr15515een.128.1379013524986; Thu, 12 Sep 2013 12:18:44 -0700 (PDT) Received: by 10.14.147.5 with HTTP; Thu, 12 Sep 2013 12:18:44 -0700 (PDT) In-Reply-To: References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> <21F50FE4-BD8E-4A61-9140-2E1E048F4F50@oracle.com> Date: Thu, 12 Sep 2013 20:18:44 +0100 Message-ID: From: Samuel Erdtman To: Phil Hunt Content-Type: multipart/alternative; boundary=047d7b343a904c540904e6349bd9 Cc: "scim@ietf.org" , "draft-ietf-scim-core-schema@tools.ietf.org" , scim issue tracker , Kelly Grizzle Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 19:18:54 -0000 --047d7b343a904c540904e6349bd9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Phil Are you saying that some backend systems might not allow some filter operations and that it therefore would be good to indicate which so that the client does not need to run into an error? Or is it just to indicate that certain searches might take a bit longer? this is how Kelly interprets it. If the server has search query limitations it would have to define the error any way since the client might ignore the not allowed information. I would vote for simplicity i.e. try the operation and adapt according to error message. And if it is just a speed indication I cannot se any reason for it, it just adds complexity. Cheers //Samuel On Wed, Sep 11, 2013 at 7:04 PM, Phil Hunt wrote: > Samuel, > > Regarding use case for index discovery=85. > > Building a user self-service component that allows searching for > colleages/friends, whatever. The UI needs to know what attributes are > searchable and what search queries are allowed (exact, startsWith, > endsWith, isLike, substring, etc). > > The UI could be client side tool that allows an administrator to query th= e > data each of the cloud service providers they use. > > The implication from an inter-op perspective is that either all SCIM SPs > support substring indexing of all attributes, OR deployers can set specif= ic > indexes based on their performance needs and abilities. If the latter, t= he > client has to know in order to know what searches are possible. > > It is doubtful that many of us can support substring indexing of all > attributes. Putting aside the performance issue, there are issues with so= me > attributes where privacy or security would block partial match searches a= nd > only exact match searches would be allowed - very much acting like an > 'Identity Oracle'. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > On 2013-09-11, at 10:18 AM, Samuel Erdtman wrote: > > I agree with Kelly. > +1 for returned > And for index I cannot se the benefit. What is the use case that needs > this? > > Cheers > //Samuel > > > On Tue, Sep 10, 2013 at 5:02 PM, Phil Hunt wrote: > >> Kelly, >> >> The problem is that if the index is anything other than "substring", the= n >> the client has to restrict the type of filter it generates, since the in= dex >> may not be able to match using the filter specified. If the filter resul= t >> become unspecified (because index doesn't support filter type) and a mat= ch >> should not occur, what should the server do? >> A. Throw an error >> B. Simply not match the entry >> >> Because of REST style and the public nature of these APIs, I would rathe= r >> avoid complex error messages and go with B. This means that clients need >> discovery to find out what query filters are supported. >> >> It goes without saying I would be open to expanding index to multi-value= d >> and being specific as to what search filters are supported. When I wrot= e >> the message below, I was thinking about the exact match case and that it= is >> different from substring. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> On 2013-09-10, at 6:42 AM, Kelly Grizzle >> wrote: >> >> > +1 for the "returned" attribute and its values. >> > >> > Regarding "index", this might be overkill. Filters support different >> operators (eq, sw, co) to do exact and substring matching. The index ju= st >> indicates server-side behavior about the most optimal way to query. Whi= le >> this information isn't harmful, it may be more than what we need. >> > >> > --Kelly >> > >> > >> > -----Original Message----- >> > From: scim issue tracker [mailto:trac+scim@tools.ietf.org] >> > Sent: Monday, September 09, 2013 3:54 PM >> > To: draft-ietf-scim-core-schema@tools.ietf.org; Kelly Grizzle; >> phil.hunt@oracle.com >> > Cc: scim@ietf.org >> > Subject: Re: [scim] #10: Add ability to mark attributes as sensitive i= n >> the schemas >> > >> > #10: Add ability to mark attributes as sensitive in the schemas >> > >> > >> > Comment (by phil.hunt@oracle.com): >> > >> > I would like to propose a series of settings per attribute to cover >> this issue. Under /schemas, each attribute would have the following >> > attributes: >> > >> > "index"=3D"none"|"substring"|"exact" >> > "returned"=3D"always"|"never"|"default"|"request" >> > >> > For example, password would have "index"=3D"exact" since the client >> would >> > have to do an exact match, and "returned"=3D"never" since the value is >> hashed and should not be returned. >> > >> > Note: the index type will also depend on the value of caseExact. For >> example caseExact =3D false means the search index is case insensitive. >> > caseExact=3D"true" means index is case sensitive. >> > >> > "always" is used for attributes that must always be returned such as >> "id" >> > "never" is used for write-only attributes that cannot or should not be >> returned. >> > "default" is used by most attributes and means are returned if the >> attribute param is missing. In other words the attribute is returned on >> default. >> > "request" means that the attribute will only be returned if requested. >> > Note: this is similar to operational attributes in LDAP. >> > >> > -- >> > -------------------------+--------------------------------------------= -- >> > -------------------------+--- >> > Reporter: | Owner: draft-ietf-scim-core- >> > melinda.shore@gmail.com| schema@tools.ietf.org >> > Type: enhancement | Status: new >> > Priority: major | Milestone: >> > Component: core-schema | Version: >> > Severity: - | Resolution: >> > Keywords: | >> > -------------------------+--------------------------------------------= -- >> > -------------------------+--- >> > >> > Ticket URL: < >> http://trac.tools.ietf.org/wg/scim/trac/ticket/10#comment:2> >> > scim >> > >> > _______________________________________________ >> > scim mailing list >> > scim@ietf.org >> > https://www.ietf.org/mailman/listinfo/scim >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > --047d7b343a904c540904e6349bd9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Phil

Are you saying that some backen= d systems might not allow some filter operations and that it therefore woul= d be good to indicate which so that the client does not need to run into an= error?

Or is it just to indicate that certain searches might t= ake a bit longer? this is how Kelly interprets it.

If the server has search query limitations it would have to define the err= or any way since the client might ignore the not allowed information.

I would vote for simplicity i.e. try the operation and = adapt according to error message. And if it is just a speed indication I ca= nnot se any reason for it, it just adds complexity.

Cheers
//Samuel



=



On Wed, Sep 11, 2013 at 7:04 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Sam= uel,

Regarding use case for index discovery=85.
Building a user self-service component that allows searching for colle= ages/friends, whatever. =A0The UI needs to know what attributes are searcha= ble and what search queries are allowed (exact, startsWith, endsWith, isLik= e, substring, etc).

The UI could be client side tool that allows an adminis= trator to query the data each of the cloud service providers they use.

The implication from an inter-op perspective is that e= ither all SCIM SPs support substring indexing of all attributes, OR deploye= rs can set specific indexes based on their performance needs and abilities.= =A0If the latter, the client has to know in order to know what searches ar= e possible.

It is doubtful that many of us can support substring in= dexing of all attributes. Putting aside the performance issue, there are is= sues with some attributes where privacy or security would block partial mat= ch searches and only exact match searches would be allowed - very much acti= ng like an 'Identity Oracle'.

Phil

@independentid
phil.hunt@oracle.co= m



<= br>



On 2013-09-11, at 10:18 AM, Samuel Erdtman <samuel@erdtman.se> wrote:
I agree with Kelly.
= +1 for returned
And for index I cannot se the benefit. What is the use case that needs= this?

Cheers
//Samuel


On Tue, Sep 10, 2013 at 5:02 PM, Phil Hu= nt <phil.hunt@oracle.com> wrote:
Kelly,

The problem is that if the index is anything other than "substring&quo= t;, then the client has to restrict the type of filter it generates, since = the index may not be able to match using the filter specified. If the filte= r result become unspecified (because index doesn't support filter type)= and a match should not occur, what should the server do?
A. =A0Throw an error
B. =A0Simply not match the entry

Because of REST style and the public nature of these APIs, I would rather a= void complex error messages and go with B. This means that clients need dis= covery to find out what query filters are supported.

It goes without saying I would be open to expanding index to multi-valued a= nd being specific as to what search filters are supported. =A0When I wrote = the message below, I was thinking about the exact match case and that it is= different from substring.

Phil

@independentid
www.independent= id.com
phil.hunt@oracle.= com







On 2013-09-10, at 6:42 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrot= e:

> +1 for the "returned" attribute and its values.
>
> Regarding "index", this might be overkill. =A0Filters suppor= t different operators (eq, sw, co) to do exact and substring matching. =A0T= he index just indicates server-side behavior about the most optimal way to = query. =A0While this information isn't harmful, it may be more than wha= t we need.
>
> --Kelly
>
>
> -----Original Message-----
> From: scim issue tracker [mailto:trac+scim@tools.ietf.org]
> Sent: Monday, September 09, 2013 3:54 PM
> To: draft-ietf-scim-core-schema@tools.ietf.org; Kelly Grizzle= ; phil.hunt@oracl= e.com
> Cc: scim@ietf.org
> Subject: Re: [scim] #10: Add ability to mark attributes as sensitive i= n the schemas
>
> #10: Add ability to mark attributes as sensitive in the schemas
>
>
> Comment (by = phil.hunt@oracle.com):
>
> I would like to propose a series of settings per attribute to cover th= is =A0issue. =A0Under /schemas, each attribute would have the following
> attributes:
>
> "index"=3D"none"|"substring"|"exact= "
> "returned"=3D"always"|"never"|"defa= ult"|"request"
>
> For example, password would have =A0 "index"=3D"exact&q= uot; since the client would
> have to do an exact match, and "returned"=3D"never"= ; since the value is =A0hashed and should not be returned.
>
> Note: =A0the index type will also depend on the value of caseExact. Fo= r =A0example caseExact =3D false means the search index is case insensitive= .
> caseExact=3D"true" means index is case sensitive.
>
> "always" is used for attributes that must always be returned= such as "id"
> "never" is used for write-only attributes that cannot or sho= uld not be =A0returned.
> "default" is used by most attributes and means are returned = if the =A0attribute param is missing. In other words the attribute is retur= ned on =A0default.
> "request" means that the attribute will only be returned if = requested.
> Note: this is similar to operational attributes in LDAP.
>
> --
> -------------------------+--------------------------------------------= --
> -------------------------+---
> Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: =A0draft-ie= tf-scim-core-
> =A0melind= a.shore@gmail.com| =A0schema@tools.ietf.org
> =A0 =A0 Type: =A0enhancement =A0| =A0 =A0 =A0Status: =A0new
> Priority: =A0major =A0 =A0 =A0 =A0| =A0 Milestone:
> Component: =A0core-schema =A0| =A0 =A0 Version:
> Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0| =A0Resolution:
> Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> -------------------------+--------------------------------------------= --
> -------------------------+---
>
> Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac= /ticket/10#comment:2>
> scim <htt= p://tools.ietf.org/scim/>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim

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

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


--047d7b343a904c540904e6349bd9-- From phil.hunt@oracle.com Thu Sep 12 13:51:31 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEF511E813B for ; Thu, 12 Sep 2013 13:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7a1CBmIKvkT for ; Thu, 12 Sep 2013 13:51:25 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD7311E80F4 for ; Thu, 12 Sep 2013 13:51:24 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8CKpKIM010949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Sep 2013 20:51:21 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8CKpJtE018053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 20:51:20 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8CKpJ88018050; Thu, 12 Sep 2013 20:51:19 GMT Received: from [25.64.248.47] (/24.114.40.182) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Sep 2013 13:51:18 -0700 References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> <21F50FE4-BD8E-4A61-9140-2E1E048F4F50@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-B80BE988-2C48-434F-B43D-11D504DC184C Content-Transfer-Encoding: 7bit Message-Id: <0B996C4F-4ACE-49AF-BD9A-CFF9B6525E69@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Thu, 12 Sep 2013 13:51:11 -0700 To: Samuel Erdtman X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "scim@ietf.org" , "draft-ietf-scim-core-schema@tools.ietf.org" , scim issue tracker , Kelly Grizzle Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 20:51:32 -0000 --Apple-Mail-B80BE988-2C48-434F-B43D-11D504DC184C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Inline Phil On 2013-09-12, at 12:18, Samuel Erdtman wrote: > Hi Phil >=20 > Are you saying that some backend systems might not allow some filter opera= tions and that it therefore would be good to indicate which so that the clie= nt does not need to run into an error? [ph] yes. And so that clients never receive an error.=20 >=20 > Or is it just to indicate that certain searches might take a bit longer? t= his is how Kelly interprets it. No >=20 > If the server has search query limitations it would have to define the err= or any way since the client might ignore the not allowed information. >=20 [ph] errors need to be avoided in a restful environment. I have put text in i= ssue 48(?) to cover processing rules for invalid filters.=20 > I would vote for simplicity i.e. try the operation and adapt according to e= rror message. And if it is just a speed indication I cannot se any reason fo= r it, it just adds complexity. [ph] errors mean huge complexity. Remember x.500? >=20 > Cheers > //Samuel >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Wed, Sep 11, 2013 at 7:04 PM, Phil Hunt wrote: >> Samuel, >>=20 >> Regarding use case for index discovery=E2=80=A6. >>=20 >> Building a user self-service component that allows searching for colleage= s/friends, whatever. The UI needs to know what attributes are searchable an= d what search queries are allowed (exact, startsWith, endsWith, isLike, subs= tring, etc). >>=20 >> The UI could be client side tool that allows an administrator to query th= e data each of the cloud service providers they use. >>=20 >> The implication from an inter-op perspective is that either all SCIM SPs s= upport substring indexing of all attributes, OR deployers can set specific i= ndexes based on their performance needs and abilities. If the latter, the c= lient has to know in order to know what searches are possible. >>=20 >> It is doubtful that many of us can support substring indexing of all attr= ibutes. Putting aside the performance issue, there are issues with some attr= ibutes where privacy or security would block partial match searches and only= exact match searches would be allowed - very much acting like an 'Identity O= racle'. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-09-11, at 10:18 AM, Samuel Erdtman wrote: >>=20 >>> I agree with Kelly. >>> +1 for returned >>> And for index I cannot se the benefit. What is the use case that needs t= his? >>>=20 >>> Cheers >>> //Samuel >>>=20 >>>=20 >>> On Tue, Sep 10, 2013 at 5:02 PM, Phil Hunt wrote:= >>>> Kelly, >>>>=20 >>>> The problem is that if the index is anything other than "substring", th= en the client has to restrict the type of filter it generates, since the ind= ex may not be able to match using the filter specified. If the filter result= become unspecified (because index doesn't support filter type) and a match s= hould not occur, what should the server do? >>>> A. Throw an error >>>> B. Simply not match the entry >>>>=20 >>>> Because of REST style and the public nature of these APIs, I would rath= er avoid complex error messages and go with B. This means that clients need d= iscovery to find out what query filters are supported. >>>>=20 >>>> It goes without saying I would be open to expanding index to multi-valu= ed and being specific as to what search filters are supported. When I wrote= the message below, I was thinking about the exact match case and that it is= different from substring. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-09-10, at 6:42 AM, Kelly Grizzle w= rote: >>>>=20 >>>> > +1 for the "returned" attribute and its values. >>>> > >>>> > Regarding "index", this might be overkill. Filters support different= operators (eq, sw, co) to do exact and substring matching. The index just i= ndicates server-side behavior about the most optimal way to query. While th= is information isn't harmful, it may be more than what we need. >>>> > >>>> > --Kelly >>>> > >>>> > >>>> > -----Original Message----- >>>> > From: scim issue tracker [mailto:trac+scim@tools.ietf.org] >>>> > Sent: Monday, September 09, 2013 3:54 PM >>>> > To: draft-ietf-scim-core-schema@tools.ietf.org; Kelly Grizzle; phil.h= unt@oracle.com >>>> > Cc: scim@ietf.org >>>> > Subject: Re: [scim] #10: Add ability to mark attributes as sensitive i= n the schemas >>>> > >>>> > #10: Add ability to mark attributes as sensitive in the schemas >>>> > >>>> > >>>> > Comment (by phil.hunt@oracle.com): >>>> > >>>> > I would like to propose a series of settings per attribute to cover t= his issue. Under /schemas, each attribute would have the following >>>> > attributes: >>>> > >>>> > "index"=3D"none"|"substring"|"exact" >>>> > "returned"=3D"always"|"never"|"default"|"request" >>>> > >>>> > For example, password would have "index"=3D"exact" since the client= would >>>> > have to do an exact match, and "returned"=3D"never" since the value i= s hashed and should not be returned. >>>> > >>>> > Note: the index type will also depend on the value of caseExact. For= example caseExact =3D false means the search index is case insensitive. >>>> > caseExact=3D"true" means index is case sensitive. >>>> > >>>> > "always" is used for attributes that must always be returned such as "= id" >>>> > "never" is used for write-only attributes that cannot or should not b= e returned. >>>> > "default" is used by most attributes and means are returned if the a= ttribute param is missing. In other words the attribute is returned on defa= ult. >>>> > "request" means that the attribute will only be returned if requested= . >>>> > Note: this is similar to operational attributes in LDAP. >>>> > >>>> > -- >>>> > -------------------------+-------------------------------------------= --- >>>> > -------------------------+--- >>>> > Reporter: | Owner: draft-ietf-scim-core- >>>> > melinda.shore@gmail.com| schema@tools.ietf.org >>>> > Type: enhancement | Status: new >>>> > Priority: major | Milestone: >>>> > Component: core-schema | Version: >>>> > Severity: - | Resolution: >>>> > Keywords: | >>>> > -------------------------+-------------------------------------------= --- >>>> > -------------------------+--- >>>> > >>>> > Ticket URL: >>>> > scim >>>> > >>>> > _______________________________________________ >>>> > scim mailing list >>>> > scim@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/scim >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >=20 --Apple-Mail-B80BE988-2C48-434F-B43D-11D504DC184C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Inline

Phil

On 20= 13-09-12, at 12:18, Samuel Erdtman <= samuel@erdtman.se> wrote:

Hi Phil

Are you saying that some backen= d systems might not allow some filter operations and that it therefore would= be good to indicate which so that the client does not need to run into an e= rror?
[ph] yes. And so that clients never rece= ive an error. 

Or is it just to indicate that certain searches might ta= ke a bit longer? this is how Kelly interprets it.
No

If the server has search query limitations it would have to define the err= or any way since the client might ignore the not allowed information.

[ph] errors need to be avoided in a r= estful environment. I have put text in issue 48(?) to cover processing rules= for invalid filters. 
I would vote for simplicity i.e. try the operation and adapt accordi= ng to error message. And if it is just a speed indication I cannot se any re= ason for it, it just adds complexity.
[ph] errors mean huge complexity. Remember x.500?

Cheers
//Samuel



<= /div>




=
On Wed, Sep 11, 2013 at 7:04 PM, Phil Hunt <phi= l.hunt@oracle.com> wrote:
Samue= l,

Regarding use case for index discovery=E2=80=A6.
=
Building a user self-service component that allows searching for collea= ges/friends, whatever.  The UI needs to know what attributes are search= able and what search queries are allowed (exact, startsWith, endsWith, isLik= e, substring, etc).

The UI could be client side tool that allows an administ= rator to query the data each of the cloud service providers they use.
<= div>
The implication from an inter-op perspective is that eith= er all SCIM SPs support substring indexing of all attributes, OR deployers c= an set specific indexes based on their performance needs and abilities. &nbs= p;If the latter, the client has to know in order to know what searches are p= ossible.

It is doubtful that many of us can support substring ind= exing of all attributes. Putting aside the performance issue, there are issu= es with some attributes where privacy or security would block partial match s= earches and only exact match searches would be allowed - very much acting li= ke an 'Identity Oracle'.

Phil

On 2013-09-11, at 10:18 AM, Samuel Erdtman <samuel@erdtman.se> wrote:
I agree with Kelly.
+1 f= or returned
And for index I cannot se the benefit. What is the use case that needs t= his?

Cheers
//Samuel


On Tue, Sep 10, 2013 at 5:02 PM, Phil Hun= t <phil.hunt@oracle.com> wrote:
Kelly,

The problem is that if the index is anything other than "substring", then th= e client has to restrict the type of filter it generates, since the index ma= y not be able to match using the filter specified. If the filter result beco= me unspecified (because index doesn't support filter type) and a match shoul= d not occur, what should the server do?
A.  Throw an error
B.  Simply not match the entry

Because of REST style and the public nature of these APIs, I would rather av= oid complex error messages and go with B. This means that clients need disco= very to find out what query filters are supported.

It goes without saying I would be open to expanding index to multi-valued an= d being specific as to what search filters are supported.  When I wrote= the message below, I was thinking about the exact match case and that it is= different from substring.

Phil

@independentid
www.independenti= d.com
phil.hunt@oracle.c= om







On 2013-09-10, at 6:42 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:=

> +1 for the "returned" attribute and its values.
>
> Regarding "index", this might be overkill.  Filters support differ= ent operators (eq, sw, co) to do exact and substring matching.  The ind= ex just indicates server-side behavior about the most optimal way to query. &= nbsp;While this information isn't harmful, it may be more than what we need.=
>
> --Kelly
>
>
> -----Original Message-----
> From: scim issue tracker [mailto:trac+scim@tools.ietf.org]
> Sent: Monday, September 09, 2013 3:54 PM
> To: draft-ietf-scim-core-schema@tools.ietf.org; Kelly Grizzle; <= a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.co= m
> Cc: scim@ietf.org
> Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in= the schemas
>
> #10: Add ability to mark attributes as sensitive in the schemas
>
>
> Comment (by p= hil.hunt@oracle.com):
>
> I would like to propose a series of settings per attribute to cover thi= s  issue.  Under /schemas, each attribute would have the following=
> attributes:
>
> "index"=3D"none"|"substring"|"exact"
> "returned"=3D"always"|"never"|"default"|"request"
>
> For example, password would have   "index"=3D"exact" since the cli= ent would
> have to do an exact match, and "returned"=3D"never" since the value is &= nbsp;hashed and should not be returned.
>
> Note:  the index type will also depend on the value of caseExact. = For  example caseExact =3D false means the search index is case insensi= tive.
> caseExact=3D"true" means index is case sensitive.
>
> "always" is used for attributes that must always be returned such as "i= d"
> "never" is used for write-only attributes that cannot or should not be &= nbsp;returned.
> "default" is used by most attributes and means are returned if the &nbs= p;attribute param is missing. In other words the attribute is returned on &n= bsp;default.
> "request" means that the attribute will only be returned if requested.<= br> > Note: this is similar to operational attributes in LDAP.
>
> --
> -------------------------+---------------------------------------------= -
> -------------------------+---
> Reporter:               |   &nb= sp;   Owner:  draft-ietf-scim-core-
>  meli= nda.shore@gmail.com|  schema@tools.ietf.org
>     Type:  enhancement  |      Statu= s:  new
> Priority:  major        |   Milestone: > Component:  core-schema  |     Version:
> Severity:  -            |  Reso= lution:
> Keywords:               |
> -------------------------+---------------------------------------------= -
> -------------------------+---
>
> Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac/t= icket/10#comment:2>
> scim <http= ://tools.ietf.org/scim/>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim

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

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


=
= --Apple-Mail-B80BE988-2C48-434F-B43D-11D504DC184C-- From phil.hunt@oracle.com Thu Sep 12 13:55:10 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D9D11E80F4 for ; Thu, 12 Sep 2013 13:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiOSvE16DmGr for ; Thu, 12 Sep 2013 13:55:04 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id F38EE21E808E for ; Thu, 12 Sep 2013 13:55:03 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8CKt1sT015235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Sep 2013 20:55:02 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8CKt092026793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 20:55:01 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8CKt0OM026778; Thu, 12 Sep 2013 20:55:00 GMT Received: from [25.64.248.47] (/24.114.40.182) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Sep 2013 13:54:59 -0700 References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> <21F50FE4-BD8E-4A61-9140-2E1E048F4F50@oracle.com> <0B996C4F-4ACE-49AF-BD9A-CFF9B6525E69@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: <0B996C4F-4ACE-49AF-BD9A-CFF9B6525E69@oracle.com> Content-Type: multipart/alternative; boundary=Apple-Mail-AE586830-4693-4EFA-AB0A-29166DDF0502 Content-Transfer-Encoding: 7bit Message-Id: <04B8A773-A22D-4BA3-8BF9-34A23BEEB031@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Thu, 12 Sep 2013 13:54:54 -0700 To: Samuel Erdtman X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "scim@ietf.org" , scim issue tracker , "draft-ietf-scim-core-schema@tools.ietf.org" , Kelly Grizzle Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 20:55:10 -0000 --Apple-Mail-AE586830-4693-4EFA-AB0A-29166DDF0502 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Also. Check rfc2251 filter processing rules. I think this is an example of a= proven model for filter processing.=20 Phil On 2013-09-12, at 13:51, Phil Hunt wrote: > Inline >=20 > Phil >=20 > On 2013-09-12, at 12:18, Samuel Erdtman wrote: >=20 >> Hi Phil >>=20 >> Are you saying that some backend systems might not allow some filter oper= ations and that it therefore would be good to indicate which so that the cli= ent does not need to run into an error? > [ph] yes. And so that clients never receive an error.=20 >>=20 >> Or is it just to indicate that certain searches might take a bit longer? t= his is how Kelly interprets it. > No >>=20 >> If the server has search query limitations it would have to define the er= ror any way since the client might ignore the not allowed information. > [ph] errors need to be avoided in a restful environment. I have put text i= n issue 48(?) to cover processing rules for invalid filters.=20 >> I would vote for simplicity i.e. try the operation and adapt according to= error message. And if it is just a speed indication I cannot se any reason f= or it, it just adds complexity. >=20 > [ph] errors mean huge complexity. Remember x.500? >>=20 >> Cheers >> //Samuel >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Wed, Sep 11, 2013 at 7:04 PM, Phil Hunt wrote: >>> Samuel, >>>=20 >>> Regarding use case for index discovery=E2=80=A6. >>>=20 >>> Building a user self-service component that allows searching for colleag= es/friends, whatever. The UI needs to know what attributes are searchable a= nd what search queries are allowed (exact, startsWith, endsWith, isLike, sub= string, etc). >>>=20 >>> The UI could be client side tool that allows an administrator to query t= he data each of the cloud service providers they use. >>>=20 >>> The implication from an inter-op perspective is that either all SCIM SPs= support substring indexing of all attributes, OR deployers can set specific= indexes based on their performance needs and abilities. If the latter, the= client has to know in order to know what searches are possible. >>>=20 >>> It is doubtful that many of us can support substring indexing of all att= ributes. Putting aside the performance issue, there are issues with some att= ributes where privacy or security would block partial match searches and onl= y exact match searches would be allowed - very much acting like an 'Identity= Oracle'. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2013-09-11, at 10:18 AM, Samuel Erdtman wrote: >>>=20 >>>> I agree with Kelly. >>>> +1 for returned >>>> And for index I cannot se the benefit. What is the use case that needs t= his? >>>>=20 >>>> Cheers >>>> //Samuel >>>>=20 >>>>=20 >>>> On Tue, Sep 10, 2013 at 5:02 PM, Phil Hunt wrote= : >>>>> Kelly, >>>>>=20 >>>>> The problem is that if the index is anything other than "substring", t= hen the client has to restrict the type of filter it generates, since the in= dex may not be able to match using the filter specified. If the filter resul= t become unspecified (because index doesn't support filter type) and a match= should not occur, what should the server do? >>>>> A. Throw an error >>>>> B. Simply not match the entry >>>>>=20 >>>>> Because of REST style and the public nature of these APIs, I would rat= her avoid complex error messages and go with B. This means that clients need= discovery to find out what query filters are supported. >>>>>=20 >>>>> It goes without saying I would be open to expanding index to multi-val= ued and being specific as to what search filters are supported. When I wrot= e the message below, I was thinking about the exact match case and that it i= s different from substring. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-09-10, at 6:42 AM, Kelly Grizzle = wrote: >>>>>=20 >>>>> > +1 for the "returned" attribute and its values. >>>>> > >>>>> > Regarding "index", this might be overkill. Filters support differen= t operators (eq, sw, co) to do exact and substring matching. The index just= indicates server-side behavior about the most optimal way to query. While t= his information isn't harmful, it may be more than what we need. >>>>> > >>>>> > --Kelly >>>>> > >>>>> > >>>>> > -----Original Message----- >>>>> > From: scim issue tracker [mailto:trac+scim@tools.ietf.org] >>>>> > Sent: Monday, September 09, 2013 3:54 PM >>>>> > To: draft-ietf-scim-core-schema@tools.ietf.org; Kelly Grizzle; phil.= hunt@oracle.com >>>>> > Cc: scim@ietf.org >>>>> > Subject: Re: [scim] #10: Add ability to mark attributes as sensitive= in the schemas >>>>> > >>>>> > #10: Add ability to mark attributes as sensitive in the schemas >>>>> > >>>>> > >>>>> > Comment (by phil.hunt@oracle.com): >>>>> > >>>>> > I would like to propose a series of settings per attribute to cover t= his issue. Under /schemas, each attribute would have the following >>>>> > attributes: >>>>> > >>>>> > "index"=3D"none"|"substring"|"exact" >>>>> > "returned"=3D"always"|"never"|"default"|"request" >>>>> > >>>>> > For example, password would have "index"=3D"exact" since the clien= t would >>>>> > have to do an exact match, and "returned"=3D"never" since the value i= s hashed and should not be returned. >>>>> > >>>>> > Note: the index type will also depend on the value of caseExact. Fo= r example caseExact =3D false means the search index is case insensitive. >>>>> > caseExact=3D"true" means index is case sensitive. >>>>> > >>>>> > "always" is used for attributes that must always be returned such as= "id" >>>>> > "never" is used for write-only attributes that cannot or should not b= e returned. >>>>> > "default" is used by most attributes and means are returned if the a= ttribute param is missing. In other words the attribute is returned on defa= ult. >>>>> > "request" means that the attribute will only be returned if requeste= d. >>>>> > Note: this is similar to operational attributes in LDAP. >>>>> > >>>>> > -- >>>>> > -------------------------+------------------------------------------= ---- >>>>> > -------------------------+--- >>>>> > Reporter: | Owner: draft-ietf-scim-core- >>>>> > melinda.shore@gmail.com| schema@tools.ietf.org >>>>> > Type: enhancement | Status: new >>>>> > Priority: major | Milestone: >>>>> > Component: core-schema | Version: >>>>> > Severity: - | Resolution: >>>>> > Keywords: | >>>>> > -------------------------+------------------------------------------= ---- >>>>> > -------------------------+--- >>>>> > >>>>> > Ticket URL: >>>>> > scim >>>>> > >>>>> > _______________________________________________ >>>>> > scim mailing list >>>>> > scim@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/scim >>>>>=20 >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-AE586830-4693-4EFA-AB0A-29166DDF0502 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Also. Check rfc2251 filter processing r= ules. I think this is an example of a proven model for filter processing.&nb= sp;

Phil

On 2013-09-12, at 13:51, Phil Hunt <phil.hunt@oracle.com> wrote:

=
Inline

Phil

On 2= 013-09-12, at 12:18, Samuel Erdtman <samuel@erdtman.se> wrote:

Hi Phil

Are you saying that some backe= nd systems might not allow some filter operations and that it therefore woul= d be good to indicate which so that the client does not need to run into an e= rror?
[ph] yes. And so that clients never rece= ive an error. 

Or is it just to indicate that certain searches might ta= ke a bit longer? this is how Kelly interprets it.
No

If the server has search query limitations it would have to define the err= or any way since the client might ignore the not allowed information.

[ph] errors need to be avoided in a r= estful environment. I have put text in issue 48(?) to cover processing rules= for invalid filters. 
I would vote for simplicity i.e. try the operation and adapt accordi= ng to error message. And if it is just a speed indication I cannot se any re= ason for it, it just adds complexity.
[ph] errors mean huge complexity. Remember x.500?

Cheers
//Samuel



<= /div>




=
On Wed, Sep 11, 2013 at 7:04 PM, Phil Hunt <phi= l.hunt@oracle.com> wrote:
Samue= l,

Regarding use case for index discovery=E2=80=A6.
=
Building a user self-service component that allows searching for collea= ges/friends, whatever.  The UI needs to know what attributes are search= able and what search queries are allowed (exact, startsWith, endsWith, isLik= e, substring, etc).

The UI could be client side tool that allows an administ= rator to query the data each of the cloud service providers they use.
<= div>
The implication from an inter-op perspective is that eith= er all SCIM SPs support substring indexing of all attributes, OR deployers c= an set specific indexes based on their performance needs and abilities. &nbs= p;If the latter, the client has to know in order to know what searches are p= ossible.

It is doubtful that many of us can support substring ind= exing of all attributes. Putting aside the performance issue, there are issu= es with some attributes where privacy or security would block partial match s= earches and only exact match searches would be allowed - very much acting li= ke an 'Identity Oracle'.

Phil

On 2013-09-11, at 10:18 AM, Samuel Erdtman <samuel@erdtman.se> wrote:
I agree with Kelly.
+1 f= or returned
And for index I cannot se the benefit. What is the use case that needs t= his?

Cheers
//Samuel


On Tue, Sep 10, 2013 at 5:02 PM, Phil Hun= t <phil.hunt@oracle.com> wrote:
Kelly,

The problem is that if the index is anything other than "substring", then th= e client has to restrict the type of filter it generates, since the index ma= y not be able to match using the filter specified. If the filter result beco= me unspecified (because index doesn't support filter type) and a match shoul= d not occur, what should the server do?
A.  Throw an error
B.  Simply not match the entry

Because of REST style and the public nature of these APIs, I would rather av= oid complex error messages and go with B. This means that clients need disco= very to find out what query filters are supported.

It goes without saying I would be open to expanding index to multi-valued an= d being specific as to what search filters are supported.  When I wrote= the message below, I was thinking about the exact match case and that it is= different from substring.

Phil

@independentid
www.independenti= d.com
phil.hunt@oracle.c= om







On 2013-09-10, at 6:42 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:=

> +1 for the "returned" attribute and its values.
>
> Regarding "index", this might be overkill.  Filters support differ= ent operators (eq, sw, co) to do exact and substring matching.  The ind= ex just indicates server-side behavior about the most optimal way to query. &= nbsp;While this information isn't harmful, it may be more than what we need.=
>
> --Kelly
>
>
> -----Original Message-----
> From: scim issue tracker [mailto:trac+scim@tools.ietf.org]
> Sent: Monday, September 09, 2013 3:54 PM
> To: draft-ietf-scim-core-schema@tools.ietf.org; Kelly Grizzle; <= a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.co= m
> Cc: scim@ietf.org
> Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in= the schemas
>
> #10: Add ability to mark attributes as sensitive in the schemas
>
>
> Comment (by p= hil.hunt@oracle.com):
>
> I would like to propose a series of settings per attribute to cover thi= s  issue.  Under /schemas, each attribute would have the following=
> attributes:
>
> "index"=3D"none"|"substring"|"exact"
> "returned"=3D"always"|"never"|"default"|"request"
>
> For example, password would have   "index"=3D"exact" since the cli= ent would
> have to do an exact match, and "returned"=3D"never" since the value is &= nbsp;hashed and should not be returned.
>
> Note:  the index type will also depend on the value of caseExact. = For  example caseExact =3D false means the search index is case insensi= tive.
> caseExact=3D"true" means index is case sensitive.
>
> "always" is used for attributes that must always be returned such as "i= d"
> "never" is used for write-only attributes that cannot or should not be &= nbsp;returned.
> "default" is used by most attributes and means are returned if the &nbs= p;attribute param is missing. In other words the attribute is returned on &n= bsp;default.
> "request" means that the attribute will only be returned if requested.<= br> > Note: this is similar to operational attributes in LDAP.
>
> --
> -------------------------+---------------------------------------------= -
> -------------------------+---
> Reporter:               |   &nb= sp;   Owner:  draft-ietf-scim-core-
>  meli= nda.shore@gmail.com|  schema@tools.ietf.org
>     Type:  enhancement  |      Statu= s:  new
> Priority:  major        |   Milestone: > Component:  core-schema  |     Version:
> Severity:  -            |  Reso= lution:
> Keywords:               |
> -------------------------+---------------------------------------------= -
> -------------------------+---
>
> Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac/t= icket/10#comment:2>
> scim <http= ://tools.ietf.org/scim/>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim

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

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


=
<= span>_______________________________________________
scim ma= iling list
scim@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/scim
= --Apple-Mail-AE586830-4693-4EFA-AB0A-29166DDF0502-- From kelly.grizzle@sailpoint.com Thu Sep 12 15:18:00 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CAA11E81C7 for ; Thu, 12 Sep 2013 15:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Abr+MXVum+xA for ; Thu, 12 Sep 2013 15:17:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0A24B11E81B0 for ; Thu, 12 Sep 2013 15:17:55 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 12 Sep 2013 22:17:48 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) with mapi id 15.00.0745.000; Thu, 12 Sep 2013 22:17:48 +0000 From: Kelly Grizzle To: Phil Hunt , Samuel Erdtman Thread-Topic: [scim] #10: Add ability to mark attributes as sensitive in the schemas Thread-Index: AQHOrZ61C3McU7HQ0069L6D/ofKUTJm++tGQgAAoMQCAAae4gIAADMEAgAGnEgCAABnVgIAAAQoAgAAS3eA= Date: Thu, 12 Sep 2013 22:17:47 +0000 Message-ID: References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> <21F50FE4-BD8E-4A61-9140-2E1E048F4F50@oracle.com> <0B996C4F-4ACE-49AF-BD9A-CFF9B6525E69@oracle.com> <04B8A773-A22D-4BA3-8BF9-34A23BEEB031@oracle.com> In-Reply-To: <04B8A773-A22D-4BA3-8BF9-34A23BEEB031@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 04B411470053A404B41294 x-originating-ip: [173.226.147.242] x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(13464003)(24454002)(377454003)(199002)(377424004)(189002)(51856001)(50986001)(47976001)(74366001)(74706001)(74876001)(46102001)(53806001)(80022001)(16601075003)(74316001)(54356001)(56776001)(83072001)(49866001)(31966008)(4396001)(63696002)(15202345003)(81686001)(81816001)(77096001)(551544002)(65816001)(79102001)(47446002)(74502001)(76796001)(74662001)(19580405001)(80976001)(15975445006)(69226001)(56816003)(81542001)(47736001)(77982001)(33646001)(83322001)(76786001)(76576001)(19300405004)(19580395003)(16236675002)(81342001)(59766001)(76482001)(66066001)(54316002)(19609705001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:173.226.147.242; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_e2abc6499e3d4a1491d943ecaf8622beBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" , "draft-ietf-scim-core-schema@tools.ietf.org" Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 22:18:01 -0000 --_000_e2abc6499e3d4a1491d943ecaf8622beBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SU1PLCBzaWxlbnRseSBpZ25vcmluZyBpbnZhbGlkIHF1ZXJpZXMgbGVhZHMgdG8gbW9yZSBwcm9i bGVtcyB0aGFuIHRoZSBjbGllbnQgaGF2aW5nIHRvIGhhbmRsZSBlcnJvcnMuICBJdCBzZWVtcyBs aWtlIGFuIGVycm9yIDUwMCB3aXRoIGEgcmVhc29uYWJsZSBlcnJvciBtZXNzYWdlIHdvdWxkIGJl IGVhc2llciBmb3IgYSBjbGllbnQgdG8gYmUgYWJsZSB0byB1bmRlcnN0YW5kIHdoeSB0aGVpciBx dWVyeSBkaWQgbm90IHdvcmsgdGhlIHdheSB0aGV5IGludGVuZGVkLg0KDQpXZSBjb3VsZCByZXR1 cm4gdGhlIHN1cHBvcnRlZCBpbmRleCB0eXBlIGluZm9ybWF0aW9uIGluIHRoZSBzY2hlbWEgc28g dGhhdCBzZXJ2ZXJzIGNhbiBiZSBtb3JlIHNlbGYtZG9jdW1lbnRpbmcuICBUaGlzIHdvdWxkIGJl IGVzcGVjaWFsbHkgdXNlZnVsIGlmIHlvdSBhcmUgdHJ5aW5nIHRvIGJ1aWxkIGEgZ2VuZXJpYyBj bGllbnQgdGhhdCBoYXMgbm8gYSBwcmlvcmkga25vd2xlZGdlIG9mIHRoZSBzZXJ2ZXIuDQoNCk9u IGFub3RoZXIgbm90ZSwgdG8gbWUgYW4g4oCcaW5kZXjigJ0gKGFuZCBtb3N0IGNvbWluZyBmcm9t IHRoZSBSREJNUyB3b3JsZCkgaW5kaWNhdGVzIHdoZXRoZXIgcXVlcnlpbmcgb3ZlciBhIGNvbHVt biB3aWxsIHJ1biBxdWlja2x5IG9yIG5vdC4gIElmIHdlIGFkZCB0aGlzIHRvIHRoZSBzY2hlbWEs IG1heWJlIHRoaXMgc2hvdWxkIGJlIOKAnHN1cHBvcnRlZEZpbHRlcnPigJ0gaW5zdGVhZC4NCg0K LS1LZWxseQ0KDQpGcm9tOiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0N ClNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTMgMzo1NSBQTQ0KVG86IFNhbXVlbCBF cmR0bWFuDQpDYzogc2NpbUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zY2ltLWNvcmUtc2NoZW1hQHRv b2xzLmlldGYub3JnOyBzY2ltIGlzc3VlIHRyYWNrZXI7IEtlbGx5IEdyaXp6bGUNClN1YmplY3Q6 IFJlOiBbc2NpbV0gIzEwOiBBZGQgYWJpbGl0eSB0byBtYXJrIGF0dHJpYnV0ZXMgYXMgc2Vuc2l0 aXZlIGluIHRoZSBzY2hlbWFzDQoNCkFsc28uIENoZWNrIHJmYzIyNTEgZmlsdGVyIHByb2Nlc3Np bmcgcnVsZXMuIEkgdGhpbmsgdGhpcyBpcyBhbiBleGFtcGxlIG9mIGEgcHJvdmVuIG1vZGVsIGZv ciBmaWx0ZXIgcHJvY2Vzc2luZy4NCg0KUGhpbA0KDQpPbiAyMDEzLTA5LTEyLCBhdCAxMzo1MSwg UGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5j b20+PiB3cm90ZToNCklubGluZQ0KDQpQaGlsDQoNCk9uIDIwMTMtMDktMTIsIGF0IDEyOjE4LCBT YW11ZWwgRXJkdG1hbiA8c2FtdWVsQGVyZHRtYW4uc2U8bWFpbHRvOnNhbXVlbEBlcmR0bWFuLnNl Pj4gd3JvdGU6DQpIaSBQaGlsDQoNCkFyZSB5b3Ugc2F5aW5nIHRoYXQgc29tZSBiYWNrZW5kIHN5 c3RlbXMgbWlnaHQgbm90IGFsbG93IHNvbWUgZmlsdGVyIG9wZXJhdGlvbnMgYW5kIHRoYXQgaXQg dGhlcmVmb3JlIHdvdWxkIGJlIGdvb2QgdG8gaW5kaWNhdGUgd2hpY2ggc28gdGhhdCB0aGUgY2xp ZW50IGRvZXMgbm90IG5lZWQgdG8gcnVuIGludG8gYW4gZXJyb3I/DQpbcGhdIHllcy4gQW5kIHNv IHRoYXQgY2xpZW50cyBuZXZlciByZWNlaXZlIGFuIGVycm9yLg0KDQoNCk9yIGlzIGl0IGp1c3Qg dG8gaW5kaWNhdGUgdGhhdCBjZXJ0YWluIHNlYXJjaGVzIG1pZ2h0IHRha2UgYSBiaXQgbG9uZ2Vy PyB0aGlzIGlzIGhvdyBLZWxseSBpbnRlcnByZXRzIGl0Lg0KTm8NCg0KDQpJZiB0aGUgc2VydmVy IGhhcyBzZWFyY2ggcXVlcnkgbGltaXRhdGlvbnMgaXQgd291bGQgaGF2ZSB0byBkZWZpbmUgdGhl IGVycm9yIGFueSB3YXkgc2luY2UgdGhlIGNsaWVudCBtaWdodCBpZ25vcmUgdGhlIG5vdCBhbGxv d2VkIGluZm9ybWF0aW9uLg0KDQpbcGhdIGVycm9ycyBuZWVkIHRvIGJlIGF2b2lkZWQgaW4gYSBy ZXN0ZnVsIGVudmlyb25tZW50LiBJIGhhdmUgcHV0IHRleHQgaW4gaXNzdWUgNDgoPykgdG8gY292 ZXIgcHJvY2Vzc2luZyBydWxlcyBmb3IgaW52YWxpZCBmaWx0ZXJzLg0KDQpJIHdvdWxkIHZvdGUg Zm9yIHNpbXBsaWNpdHkgaS5lLiB0cnkgdGhlIG9wZXJhdGlvbiBhbmQgYWRhcHQgYWNjb3JkaW5n IHRvIGVycm9yIG1lc3NhZ2UuIEFuZCBpZiBpdCBpcyBqdXN0IGEgc3BlZWQgaW5kaWNhdGlvbiBJ IGNhbm5vdCBzZSBhbnkgcmVhc29uIGZvciBpdCwgaXQganVzdCBhZGRzIGNvbXBsZXhpdHkuDQoN CltwaF0gZXJyb3JzIG1lYW4gaHVnZSBjb21wbGV4aXR5LiBSZW1lbWJlciB4LjUwMD8NCg0KQ2hl ZXJzDQovL1NhbXVlbA0KDQoNCg0KDQoNCg0KT24gV2VkLCBTZXAgMTEsIDIwMTMgYXQgNzowNCBQ TSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20+PiB3cm90ZToNClNhbXVlbCwNCg0KUmVnYXJkaW5nIHVzZSBjYXNlIGZvciBpbmRleCBk aXNjb3ZlcnnigKYuDQoNCkJ1aWxkaW5nIGEgdXNlciBzZWxmLXNlcnZpY2UgY29tcG9uZW50IHRo YXQgYWxsb3dzIHNlYXJjaGluZyBmb3IgY29sbGVhZ2VzL2ZyaWVuZHMsIHdoYXRldmVyLiAgVGhl IFVJIG5lZWRzIHRvIGtub3cgd2hhdCBhdHRyaWJ1dGVzIGFyZSBzZWFyY2hhYmxlIGFuZCB3aGF0 IHNlYXJjaCBxdWVyaWVzIGFyZSBhbGxvd2VkIChleGFjdCwgc3RhcnRzV2l0aCwgZW5kc1dpdGgs IGlzTGlrZSwgc3Vic3RyaW5nLCBldGMpLg0KDQpUaGUgVUkgY291bGQgYmUgY2xpZW50IHNpZGUg dG9vbCB0aGF0IGFsbG93cyBhbiBhZG1pbmlzdHJhdG9yIHRvIHF1ZXJ5IHRoZSBkYXRhIGVhY2gg b2YgdGhlIGNsb3VkIHNlcnZpY2UgcHJvdmlkZXJzIHRoZXkgdXNlLg0KDQpUaGUgaW1wbGljYXRp b24gZnJvbSBhbiBpbnRlci1vcCBwZXJzcGVjdGl2ZSBpcyB0aGF0IGVpdGhlciBhbGwgU0NJTSBT UHMgc3VwcG9ydCBzdWJzdHJpbmcgaW5kZXhpbmcgb2YgYWxsIGF0dHJpYnV0ZXMsIE9SIGRlcGxv eWVycyBjYW4gc2V0IHNwZWNpZmljIGluZGV4ZXMgYmFzZWQgb24gdGhlaXIgcGVyZm9ybWFuY2Ug bmVlZHMgYW5kIGFiaWxpdGllcy4gIElmIHRoZSBsYXR0ZXIsIHRoZSBjbGllbnQgaGFzIHRvIGtu b3cgaW4gb3JkZXIgdG8ga25vdyB3aGF0IHNlYXJjaGVzIGFyZSBwb3NzaWJsZS4NCg0KSXQgaXMg ZG91YnRmdWwgdGhhdCBtYW55IG9mIHVzIGNhbiBzdXBwb3J0IHN1YnN0cmluZyBpbmRleGluZyBv ZiBhbGwgYXR0cmlidXRlcy4gUHV0dGluZyBhc2lkZSB0aGUgcGVyZm9ybWFuY2UgaXNzdWUsIHRo ZXJlIGFyZSBpc3N1ZXMgd2l0aCBzb21lIGF0dHJpYnV0ZXMgd2hlcmUgcHJpdmFjeSBvciBzZWN1 cml0eSB3b3VsZCBibG9jayBwYXJ0aWFsIG1hdGNoIHNlYXJjaGVzIGFuZCBvbmx5IGV4YWN0IG1h dGNoIHNlYXJjaGVzIHdvdWxkIGJlIGFsbG93ZWQgLSB2ZXJ5IG11Y2ggYWN0aW5nIGxpa2UgYW4g J0lkZW50aXR5IE9yYWNsZScuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVu ZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9yYWNs ZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQoNCk9uIDIwMTMtMDkt MTEsIGF0IDEwOjE4IEFNLCBTYW11ZWwgRXJkdG1hbiA8c2FtdWVsQGVyZHRtYW4uc2U8bWFpbHRv OnNhbXVlbEBlcmR0bWFuLnNlPj4gd3JvdGU6DQoNCg0KSSBhZ3JlZSB3aXRoIEtlbGx5Lg0KKzEg Zm9yIHJldHVybmVkDQpBbmQgZm9yIGluZGV4IEkgY2Fubm90IHNlIHRoZSBiZW5lZml0LiBXaGF0 IGlzIHRoZSB1c2UgY2FzZSB0aGF0IG5lZWRzIHRoaXM/DQoNCkNoZWVycw0KLy9TYW11ZWwNCg0K T24gVHVlLCBTZXAgMTAsIDIwMTMgYXQgNTowMiBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3Jh Y2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCktlbGx5LA0KDQpU aGUgcHJvYmxlbSBpcyB0aGF0IGlmIHRoZSBpbmRleCBpcyBhbnl0aGluZyBvdGhlciB0aGFuICJz dWJzdHJpbmciLCB0aGVuIHRoZSBjbGllbnQgaGFzIHRvIHJlc3RyaWN0IHRoZSB0eXBlIG9mIGZp bHRlciBpdCBnZW5lcmF0ZXMsIHNpbmNlIHRoZSBpbmRleCBtYXkgbm90IGJlIGFibGUgdG8gbWF0 Y2ggdXNpbmcgdGhlIGZpbHRlciBzcGVjaWZpZWQuIElmIHRoZSBmaWx0ZXIgcmVzdWx0IGJlY29t ZSB1bnNwZWNpZmllZCAoYmVjYXVzZSBpbmRleCBkb2Vzbid0IHN1cHBvcnQgZmlsdGVyIHR5cGUp IGFuZCBhIG1hdGNoIHNob3VsZCBub3Qgb2NjdXIsIHdoYXQgc2hvdWxkIHRoZSBzZXJ2ZXIgZG8/ DQpBLiAgVGhyb3cgYW4gZXJyb3INCkIuICBTaW1wbHkgbm90IG1hdGNoIHRoZSBlbnRyeQ0KDQpC ZWNhdXNlIG9mIFJFU1Qgc3R5bGUgYW5kIHRoZSBwdWJsaWMgbmF0dXJlIG9mIHRoZXNlIEFQSXMs IEkgd291bGQgcmF0aGVyIGF2b2lkIGNvbXBsZXggZXJyb3IgbWVzc2FnZXMgYW5kIGdvIHdpdGgg Qi4gVGhpcyBtZWFucyB0aGF0IGNsaWVudHMgbmVlZCBkaXNjb3ZlcnkgdG8gZmluZCBvdXQgd2hh dCBxdWVyeSBmaWx0ZXJzIGFyZSBzdXBwb3J0ZWQuDQoNCkl0IGdvZXMgd2l0aG91dCBzYXlpbmcg SSB3b3VsZCBiZSBvcGVuIHRvIGV4cGFuZGluZyBpbmRleCB0byBtdWx0aS12YWx1ZWQgYW5kIGJl aW5nIHNwZWNpZmljIGFzIHRvIHdoYXQgc2VhcmNoIGZpbHRlcnMgYXJlIHN1cHBvcnRlZC4gIFdo ZW4gSSB3cm90ZSB0aGUgbWVzc2FnZSBiZWxvdywgSSB3YXMgdGhpbmtpbmcgYWJvdXQgdGhlIGV4 YWN0IG1hdGNoIGNhc2UgYW5kIHRoYXQgaXQgaXMgZGlmZmVyZW50IGZyb20gc3Vic3RyaW5nLg0K DQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3 dy5pbmRlcGVuZGVudGlkLmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20+DQoNCg0KDQoNCg0KDQoNCk9uIDIwMTMtMDktMTAsIGF0IDY6NDIgQU0s IEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTxtYWlsdG86a2VsbHku Z3JpenpsZUBzYWlscG9pbnQuY29tPj4gd3JvdGU6DQoNCj4gKzEgZm9yIHRoZSAicmV0dXJuZWQi IGF0dHJpYnV0ZSBhbmQgaXRzIHZhbHVlcy4NCj4NCj4gUmVnYXJkaW5nICJpbmRleCIsIHRoaXMg bWlnaHQgYmUgb3ZlcmtpbGwuICBGaWx0ZXJzIHN1cHBvcnQgZGlmZmVyZW50IG9wZXJhdG9ycyAo ZXEsIHN3LCBjbykgdG8gZG8gZXhhY3QgYW5kIHN1YnN0cmluZyBtYXRjaGluZy4gIFRoZSBpbmRl eCBqdXN0IGluZGljYXRlcyBzZXJ2ZXItc2lkZSBiZWhhdmlvciBhYm91dCB0aGUgbW9zdCBvcHRp bWFsIHdheSB0byBxdWVyeS4gIFdoaWxlIHRoaXMgaW5mb3JtYXRpb24gaXNuJ3QgaGFybWZ1bCwg aXQgbWF5IGJlIG1vcmUgdGhhbiB3aGF0IHdlIG5lZWQuDQo+DQo+IC0tS2VsbHkNCj4NCj4NCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2NpbSBpc3N1ZSB0cmFja2VyIFtt YWlsdG86dHJhYytzY2ltQHRvb2xzLmlldGYub3JnPG1haWx0bzp0cmFjJTJCc2NpbUB0b29scy5p ZXRmLm9yZz5dDQo+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDA5LCAyMDEzIDM6NTQgUE0NCj4g VG86IGRyYWZ0LWlldGYtc2NpbS1jb3JlLXNjaGVtYUB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJh ZnQtaWV0Zi1zY2ltLWNvcmUtc2NoZW1hQHRvb2xzLmlldGYub3JnPjsgS2VsbHkgR3JpenpsZTsg cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KPiBDYzog c2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtzY2lt XSAjMTA6IEFkZCBhYmlsaXR5IHRvIG1hcmsgYXR0cmlidXRlcyBhcyBzZW5zaXRpdmUgaW4gdGhl IHNjaGVtYXMNCj4NCj4gIzEwOiBBZGQgYWJpbGl0eSB0byBtYXJrIGF0dHJpYnV0ZXMgYXMgc2Vu c2l0aXZlIGluIHRoZSBzY2hlbWFzDQo+DQo+DQo+IENvbW1lbnQgKGJ5IHBoaWwuaHVudEBvcmFj bGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4pOg0KPg0KPiBJIHdvdWxkIGxpa2Ug dG8gcHJvcG9zZSBhIHNlcmllcyBvZiBzZXR0aW5ncyBwZXIgYXR0cmlidXRlIHRvIGNvdmVyIHRo aXMgIGlzc3VlLiAgVW5kZXIgL3NjaGVtYXMsIGVhY2ggYXR0cmlidXRlIHdvdWxkIGhhdmUgdGhl IGZvbGxvd2luZw0KPiBhdHRyaWJ1dGVzOg0KPg0KPiAiaW5kZXgiPSJub25lInwic3Vic3RyaW5n InwiZXhhY3QiDQo+ICJyZXR1cm5lZCI9ImFsd2F5cyJ8Im5ldmVyInwiZGVmYXVsdCJ8InJlcXVl c3QiDQo+DQo+IEZvciBleGFtcGxlLCBwYXNzd29yZCB3b3VsZCBoYXZlICAgImluZGV4Ij0iZXhh Y3QiIHNpbmNlIHRoZSBjbGllbnQgd291bGQNCj4gaGF2ZSB0byBkbyBhbiBleGFjdCBtYXRjaCwg YW5kICJyZXR1cm5lZCI9Im5ldmVyIiBzaW5jZSB0aGUgdmFsdWUgaXMgIGhhc2hlZCBhbmQgc2hv dWxkIG5vdCBiZSByZXR1cm5lZC4NCj4NCj4gTm90ZTogIHRoZSBpbmRleCB0eXBlIHdpbGwgYWxz byBkZXBlbmQgb24gdGhlIHZhbHVlIG9mIGNhc2VFeGFjdC4gRm9yICBleGFtcGxlIGNhc2VFeGFj dCA9IGZhbHNlIG1lYW5zIHRoZSBzZWFyY2ggaW5kZXggaXMgY2FzZSBpbnNlbnNpdGl2ZS4NCj4g Y2FzZUV4YWN0PSJ0cnVlIiBtZWFucyBpbmRleCBpcyBjYXNlIHNlbnNpdGl2ZS4NCj4NCj4gImFs d2F5cyIgaXMgdXNlZCBmb3IgYXR0cmlidXRlcyB0aGF0IG11c3QgYWx3YXlzIGJlIHJldHVybmVk IHN1Y2ggYXMgImlkIg0KPiAibmV2ZXIiIGlzIHVzZWQgZm9yIHdyaXRlLW9ubHkgYXR0cmlidXRl cyB0aGF0IGNhbm5vdCBvciBzaG91bGQgbm90IGJlICByZXR1cm5lZC4NCj4gImRlZmF1bHQiIGlz IHVzZWQgYnkgbW9zdCBhdHRyaWJ1dGVzIGFuZCBtZWFucyBhcmUgcmV0dXJuZWQgaWYgdGhlICBh dHRyaWJ1dGUgcGFyYW0gaXMgbWlzc2luZy4gSW4gb3RoZXIgd29yZHMgdGhlIGF0dHJpYnV0ZSBp cyByZXR1cm5lZCBvbiAgZGVmYXVsdC4NCj4gInJlcXVlc3QiIG1lYW5zIHRoYXQgdGhlIGF0dHJp YnV0ZSB3aWxsIG9ubHkgYmUgcmV0dXJuZWQgaWYgcmVxdWVzdGVkLg0KPiBOb3RlOiB0aGlzIGlz IHNpbWlsYXIgdG8gb3BlcmF0aW9uYWwgYXR0cmlidXRlcyBpbiBMREFQLg0KPg0KPiAtLQ0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0NCj4gUmVwb3J0 ZXI6ICAgICAgICAgICAgICAgfCAgICAgICBPd25lcjogIGRyYWZ0LWlldGYtc2NpbS1jb3JlLQ0K PiAgbWVsaW5kYS5zaG9yZUBnbWFpbC5jb208bWFpbHRvOm1lbGluZGEuc2hvcmVAZ21haWwuY29t PnwgIHNjaGVtYUB0b29scy5pZXRmLm9yZzxtYWlsdG86c2NoZW1hQHRvb2xzLmlldGYub3JnPg0K PiAgICAgVHlwZTogIGVuaGFuY2VtZW50ICB8ICAgICAgU3RhdHVzOiAgbmV3DQo+IFByaW9yaXR5 OiAgbWFqb3IgICAgICAgIHwgICBNaWxlc3RvbmU6DQo+IENvbXBvbmVudDogIGNvcmUtc2NoZW1h ICB8ICAgICBWZXJzaW9uOg0KPiBTZXZlcml0eTogIC0gICAgICAgICAgICB8ICBSZXNvbHV0aW9u Og0KPiBLZXl3b3JkczogICAgICAgICAgICAgICB8DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KPg0KPiBUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvd2cvc2NpbS90cmFjL3RpY2tldC8xMCNjb21tZW50OjI+DQo+IHNjaW0g PGh0dHA6Ly90b29scy5pZXRmLm9yZy9zY2ltLz4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2NpbSBtYWlsaW5nIGxpc3QNCj4gc2NpbUBp ZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zY2ltDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpzY2ltIG1haWxpbmcgbGlzdA0Kc2NpbUBpZXRmLm9yZzxtYWlsdG86c2Np bUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2NpbSBt YWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2NpbSBtYWlsaW5nIGxpc3QNCnNjaW1A aWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NjaW0NCg== --_000_e2abc6499e3d4a1491d943ecaf8622beBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PklNTywgc2lsZW50bHkgaWdub3JpbmcgaW52YWxpZCBxdWVyaWVzIGxlYWRzIHRvIG1vcmUgcHJv YmxlbXMgdGhhbiB0aGUgY2xpZW50IGhhdmluZyB0byBoYW5kbGUgZXJyb3JzLiZuYnNwOyBJdCBz ZWVtcyBsaWtlIGFuIGVycm9yIDUwMCB3aXRoIGEgcmVhc29uYWJsZSBlcnJvciBtZXNzYWdlDQog d291bGQgYmUgZWFzaWVyIGZvciBhIGNsaWVudCB0byBiZSBhYmxlIHRvIHVuZGVyc3RhbmQgd2h5 IHRoZWlyIHF1ZXJ5IGRpZCBub3Qgd29yayB0aGUgd2F5IHRoZXkgaW50ZW5kZWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5XZSBjb3VsZCByZXR1cm4gdGhlIHN1cHBvcnRlZCBpbmRleCB0eXBlIGluZm9ybWF0aW9uIGlu IHRoZSBzY2hlbWEgc28gdGhhdCBzZXJ2ZXJzIGNhbiBiZSBtb3JlIHNlbGYtZG9jdW1lbnRpbmcu Jm5ic3A7IFRoaXMgd291bGQgYmUgZXNwZWNpYWxseSB1c2VmdWwgaWYgeW91IGFyZQ0KIHRyeWlu ZyB0byBidWlsZCBhIGdlbmVyaWMgY2xpZW50IHRoYXQgaGFzIG5vIGEgcHJpb3JpIGtub3dsZWRn ZSBvZiB0aGUgc2VydmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T24gYW5vdGhlciBub3RlLCB0byBtZSBhbiDigJxp bmRleOKAnSAoYW5kIG1vc3QgY29taW5nIGZyb20gdGhlIFJEQk1TIHdvcmxkKSBpbmRpY2F0ZXMg d2hldGhlciBxdWVyeWluZyBvdmVyIGEgY29sdW1uIHdpbGwgcnVuIHF1aWNrbHkgb3Igbm90LiZu YnNwOyBJZiB3ZSBhZGQgdGhpcyB0bw0KIHRoZSBzY2hlbWEsIG1heWJlIHRoaXMgc2hvdWxkIGJl IOKAnHN1cHBvcnRlZEZpbHRlcnPigJ0gaW5zdGVhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tS2VsbHk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgU2VwdGVtYmVyIDEyLCAyMDEzIDM6NTUgUE08YnI+ DQo8Yj5Ubzo8L2I+IFNhbXVlbCBFcmR0bWFuPGJyPg0KPGI+Q2M6PC9iPiBzY2ltQGlldGYub3Jn OyBkcmFmdC1pZXRmLXNjaW0tY29yZS1zY2hlbWFAdG9vbHMuaWV0Zi5vcmc7IHNjaW0gaXNzdWUg dHJhY2tlcjsgS2VsbHkgR3JpenpsZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NjaW1dICMx MDogQWRkIGFiaWxpdHkgdG8gbWFyayBhdHRyaWJ1dGVzIGFzIHNlbnNpdGl2ZSBpbiB0aGUgc2No ZW1hczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BbHNvLiBDaGVjayByZmMyMjUxIGZpbHRlciBwcm9jZXNzaW5nIHJ1bGVzLiBJIHRoaW5rIHRo aXMgaXMgYW4gZXhhbXBsZSBvZiBhIHByb3ZlbiBtb2RlbCBmb3IgZmlsdGVyIHByb2Nlc3Npbmcu Jm5ic3A7PGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAy MDEzLTA5LTEyLCBhdCAxMzo1MSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J bmxpbmU8YnI+DQo8YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDIw MTMtMDktMTIsIGF0IDEyOjE4LCBTYW11ZWwgRXJkdG1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNh bXVlbEBlcmR0bWFuLnNlIj5zYW11ZWxAZXJkdG1hbi5zZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkg UGhpbDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXJlIHlv dSBzYXlpbmcgdGhhdCBzb21lIGJhY2tlbmQgc3lzdGVtcyBtaWdodCBub3QgYWxsb3cgc29tZSBm aWx0ZXIgb3BlcmF0aW9ucyBhbmQgdGhhdCBpdCB0aGVyZWZvcmUgd291bGQgYmUgZ29vZCB0byBp bmRpY2F0ZSB3aGljaCBzbyB0aGF0IHRoZSBjbGllbnQgZG9lcyBub3QgbmVlZCB0byBydW4gaW50 byBhbiBlcnJvcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltwaF0geWVzLiBBbmQgc28gdGhhdCBjbGll bnRzIG5ldmVyIHJlY2VpdmUgYW4gZXJyb3IuJm5ic3A7PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9yIGlzIGl0 IGp1c3QgdG8gaW5kaWNhdGUgdGhhdCBjZXJ0YWluIHNlYXJjaGVzIG1pZ2h0IHRha2UgYSBiaXQg bG9uZ2VyPyB0aGlzIGlzIGhvdyBLZWxseSBpbnRlcnByZXRzIGl0LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm88YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SWYgdGhlIHNlcnZlciBoYXMgc2VhcmNoIHF1ZXJ5IGxpbWl0YXRpb25zIGl0IHdvdWxk IGhhdmUgdG8gZGVmaW5lIHRoZSBlcnJvciBhbnkgd2F5IHNpbmNlIHRoZSBjbGllbnQgbWlnaHQg aWdub3JlIHRoZSBub3QgYWxsb3dlZCBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W3BoXSBlcnJvcnMgbmVl ZCB0byBiZSBhdm9pZGVkIGluIGEgcmVzdGZ1bCBlbnZpcm9ubWVudC4gSSBoYXZlIHB1dCB0ZXh0 IGluIGlzc3VlIDQ4KD8pIHRvIGNvdmVyIHByb2Nlc3NpbmcgcnVsZXMgZm9yIGludmFsaWQgZmls dGVycy4mbmJzcDs8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgdm90ZSBmb3Igc2ltcGxpY2l0eSBpLmUu IHRyeSB0aGUgb3BlcmF0aW9uIGFuZCBhZGFwdCBhY2NvcmRpbmcgdG8gZXJyb3IgbWVzc2FnZS4g QW5kIGlmIGl0IGlzIGp1c3QgYSBzcGVlZCBpbmRpY2F0aW9uIEkgY2Fubm90IHNlIGFueSByZWFz b24gZm9yIGl0LCBpdCBqdXN0IGFkZHMgY29tcGxleGl0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W3BoXSBlcnJvcnMgbWVh biBodWdlIGNvbXBsZXhpdHkuIFJlbWVtYmVyIHguNTAwPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi8vU2FtdWVs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgU2VwIDExLCAyMDEz IGF0IDc6MDQgUE0sIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2Ft dWVsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2Fy ZGluZyB1c2UgY2FzZSBmb3IgaW5kZXggZGlzY292ZXJ54oCmLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnVpbGRpbmcgYSB1c2VyIHNlbGYtc2VydmljZSBj b21wb25lbnQgdGhhdCBhbGxvd3Mgc2VhcmNoaW5nIGZvciBjb2xsZWFnZXMvZnJpZW5kcywgd2hh dGV2ZXIuICZuYnNwO1RoZSBVSSBuZWVkcyB0byBrbm93IHdoYXQgYXR0cmlidXRlcyBhcmUgc2Vh cmNoYWJsZSBhbmQgd2hhdCBzZWFyY2ggcXVlcmllcyBhcmUgYWxsb3dlZCAoZXhhY3QsIHN0YXJ0 c1dpdGgsIGVuZHNXaXRoLCBpc0xpa2UsIHN1YnN0cmluZywgZXRjKS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIFVJIGNvdWxkIGJlIGNs aWVudCBzaWRlIHRvb2wgdGhhdCBhbGxvd3MgYW4gYWRtaW5pc3RyYXRvciB0byBxdWVyeSB0aGUg ZGF0YSBlYWNoIG9mIHRoZSBjbG91ZCBzZXJ2aWNlIHByb3ZpZGVycyB0aGV5IHVzZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGltcGxp Y2F0aW9uIGZyb20gYW4gaW50ZXItb3AgcGVyc3BlY3RpdmUgaXMgdGhhdCBlaXRoZXIgYWxsIFND SU0gU1BzIHN1cHBvcnQgc3Vic3RyaW5nIGluZGV4aW5nIG9mIGFsbCBhdHRyaWJ1dGVzLCBPUiBk ZXBsb3llcnMgY2FuIHNldCBzcGVjaWZpYyBpbmRleGVzIGJhc2VkIG9uIHRoZWlyIHBlcmZvcm1h bmNlIG5lZWRzIGFuZCBhYmlsaXRpZXMuICZuYnNwO0lmIHRoZSBsYXR0ZXIsIHRoZSBjbGllbnQg aGFzDQogdG8ga25vdyBpbiBvcmRlciB0byBrbm93IHdoYXQgc2VhcmNoZXMgYXJlIHBvc3NpYmxl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J dCBpcyBkb3VidGZ1bCB0aGF0IG1hbnkgb2YgdXMgY2FuIHN1cHBvcnQgc3Vic3RyaW5nIGluZGV4 aW5nIG9mIGFsbCBhdHRyaWJ1dGVzLiBQdXR0aW5nIGFzaWRlIHRoZSBwZXJmb3JtYW5jZSBpc3N1 ZSwgdGhlcmUgYXJlIGlzc3VlcyB3aXRoIHNvbWUgYXR0cmlidXRlcyB3aGVyZSBwcml2YWN5IG9y IHNlY3VyaXR5IHdvdWxkIGJsb2NrIHBhcnRpYWwgbWF0Y2ggc2VhcmNoZXMgYW5kIG9ubHkgZXhh Y3QgbWF0Y2gNCiBzZWFyY2hlcyB3b3VsZCBiZSBhbGxvd2VkIC0gdmVyeSBtdWNoIGFjdGluZyBs aWtlIGFuICdJZGVudGl0eSBPcmFjbGUnLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij5QaGls PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJo dHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmluZGVwZW5k ZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0i bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9y YWNsZS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTMuNXB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjAxMy0wOS0xMSwgYXQgMTA6MTggQU0s IFNhbXVlbCBFcmR0bWFuICZsdDs8YSBocmVmPSJtYWlsdG86c2FtdWVsQGVyZHRtYW4uc2UiIHRh cmdldD0iX2JsYW5rIj5zYW11ZWxAZXJkdG1hbi5zZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdpdGggS2VsbHkuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxIGZvciByZXR1 cm5lZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QW5kIGZvciBpbmRleCBJIGNhbm5vdCBzZSB0aGUgYmVuZWZpdC4gV2hhdCBpcyB0aGUgdXNlIGNh c2UgdGhhdCBuZWVkcyB0aGlzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5DaGVlcnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi8vU2FtdWVsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VHVlLCBTZXAgMTAsIDIwMTMgYXQgNTowMiBQTSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWls dG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xl LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ S2VsbHksPGJyPg0KPGJyPg0KVGhlIHByb2JsZW0gaXMgdGhhdCBpZiB0aGUgaW5kZXggaXMgYW55 dGhpbmcgb3RoZXIgdGhhbiAmcXVvdDtzdWJzdHJpbmcmcXVvdDssIHRoZW4gdGhlIGNsaWVudCBo YXMgdG8gcmVzdHJpY3QgdGhlIHR5cGUgb2YgZmlsdGVyIGl0IGdlbmVyYXRlcywgc2luY2UgdGhl IGluZGV4IG1heSBub3QgYmUgYWJsZSB0byBtYXRjaCB1c2luZyB0aGUgZmlsdGVyIHNwZWNpZmll ZC4gSWYgdGhlIGZpbHRlciByZXN1bHQgYmVjb21lIHVuc3BlY2lmaWVkIChiZWNhdXNlIGluZGV4 DQogZG9lc24ndCBzdXBwb3J0IGZpbHRlciB0eXBlKSBhbmQgYSBtYXRjaCBzaG91bGQgbm90IG9j Y3VyLCB3aGF0IHNob3VsZCB0aGUgc2VydmVyIGRvPzxicj4NCkEuICZuYnNwO1Rocm93IGFuIGVy cm9yPGJyPg0KQi4gJm5ic3A7U2ltcGx5IG5vdCBtYXRjaCB0aGUgZW50cnk8YnI+DQo8YnI+DQpC ZWNhdXNlIG9mIFJFU1Qgc3R5bGUgYW5kIHRoZSBwdWJsaWMgbmF0dXJlIG9mIHRoZXNlIEFQSXMs IEkgd291bGQgcmF0aGVyIGF2b2lkIGNvbXBsZXggZXJyb3IgbWVzc2FnZXMgYW5kIGdvIHdpdGgg Qi4gVGhpcyBtZWFucyB0aGF0IGNsaWVudHMgbmVlZCBkaXNjb3ZlcnkgdG8gZmluZCBvdXQgd2hh dCBxdWVyeSBmaWx0ZXJzIGFyZSBzdXBwb3J0ZWQuPGJyPg0KPGJyPg0KSXQgZ29lcyB3aXRob3V0 IHNheWluZyBJIHdvdWxkIGJlIG9wZW4gdG8gZXhwYW5kaW5nIGluZGV4IHRvIG11bHRpLXZhbHVl ZCBhbmQgYmVpbmcgc3BlY2lmaWMgYXMgdG8gd2hhdCBzZWFyY2ggZmlsdGVycyBhcmUgc3VwcG9y dGVkLiAmbmJzcDtXaGVuIEkgd3JvdGUgdGhlIG1lc3NhZ2UgYmVsb3csIEkgd2FzIHRoaW5raW5n IGFib3V0IHRoZSBleGFjdCBtYXRjaCBjYXNlIGFuZCB0aGF0IGl0IGlzIGRpZmZlcmVudCBmcm9t IHN1YnN0cmluZy48YnI+DQo8YnI+DQpQaGlsPGJyPg0KPGJyPg0KQGluZGVwZW5kZW50aWQ8YnI+ DQo8YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyIgdGFyZ2V0PSJfYmxhbmsi Pnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48YnI+DQo8YSBocmVmPSJtYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gMjAxMy0wOS0xMCwgYXQgNjo0MiBB TSwgS2VsbHkgR3JpenpsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBv aW50LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTwvYT4m Z3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDsgJiM0MzsxIGZvciB0aGUgJnF1b3Q7cmV0dXJuZWQm cXVvdDsgYXR0cmlidXRlIGFuZCBpdHMgdmFsdWVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFJlZ2Fy ZGluZyAmcXVvdDtpbmRleCZxdW90OywgdGhpcyBtaWdodCBiZSBvdmVya2lsbC4gJm5ic3A7Rmls dGVycyBzdXBwb3J0IGRpZmZlcmVudCBvcGVyYXRvcnMgKGVxLCBzdywgY28pIHRvIGRvIGV4YWN0 IGFuZCBzdWJzdHJpbmcgbWF0Y2hpbmcuICZuYnNwO1RoZSBpbmRleCBqdXN0IGluZGljYXRlcyBz ZXJ2ZXItc2lkZSBiZWhhdmlvciBhYm91dCB0aGUgbW9zdCBvcHRpbWFsIHdheSB0byBxdWVyeS4g Jm5ic3A7V2hpbGUgdGhpcyBpbmZvcm1hdGlvbiBpc24ndCBoYXJtZnVsLCBpdA0KIG1heSBiZSBt b3JlIHRoYW4gd2hhdCB3ZSBuZWVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IC0tS2VsbHk8YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom Z3Q7IEZyb206IHNjaW0gaXNzdWUgdHJhY2tlciBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0cmFj JTJCc2NpbUB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYWMmIzQzO3NjaW1AdG9v bHMuaWV0Zi5vcmc8L2E+XTxicj4NCiZndDsgU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMDksIDIw MTMgMzo1NCBQTTxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNjaW0t Y29yZS1zY2hlbWFAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYt c2NpbS1jb3JlLXNjaGVtYUB0b29scy5pZXRmLm9yZzwvYT47IEtlbGx5IEdyaXp6bGU7IDxhIGhy ZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KcGhpbC5o dW50QG9yYWNsZS5jb208L2E+PGJyPg0KJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVj dDogUmU6IFtzY2ltXSAjMTA6IEFkZCBhYmlsaXR5IHRvIG1hcmsgYXR0cmlidXRlcyBhcyBzZW5z aXRpdmUgaW4gdGhlIHNjaGVtYXM8YnI+DQomZ3Q7PGJyPg0KJmd0OyAjMTA6IEFkZCBhYmlsaXR5 IHRvIG1hcmsgYXR0cmlidXRlcyBhcyBzZW5zaXRpdmUgaW4gdGhlIHNjaGVtYXM8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgQ29tbWVudCAoYnkgPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+KTo8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSBhIHNlcmllcyBvZiBz ZXR0aW5ncyBwZXIgYXR0cmlidXRlIHRvIGNvdmVyIHRoaXMgJm5ic3A7aXNzdWUuICZuYnNwO1Vu ZGVyIC9zY2hlbWFzLCBlYWNoIGF0dHJpYnV0ZSB3b3VsZCBoYXZlIHRoZSBmb2xsb3dpbmc8YnI+ DQomZ3Q7IGF0dHJpYnV0ZXM6PGJyPg0KJmd0Ozxicj4NCiZndDsgJnF1b3Q7aW5kZXgmcXVvdDs9 JnF1b3Q7bm9uZSZxdW90O3wmcXVvdDtzdWJzdHJpbmcmcXVvdDt8JnF1b3Q7ZXhhY3QmcXVvdDs8 YnI+DQomZ3Q7ICZxdW90O3JldHVybmVkJnF1b3Q7PSZxdW90O2Fsd2F5cyZxdW90O3wmcXVvdDtu ZXZlciZxdW90O3wmcXVvdDtkZWZhdWx0JnF1b3Q7fCZxdW90O3JlcXVlc3QmcXVvdDs8YnI+DQom Z3Q7PGJyPg0KJmd0OyBGb3IgZXhhbXBsZSwgcGFzc3dvcmQgd291bGQgaGF2ZSAmbmJzcDsgJnF1 b3Q7aW5kZXgmcXVvdDs9JnF1b3Q7ZXhhY3QmcXVvdDsgc2luY2UgdGhlIGNsaWVudCB3b3VsZDxi cj4NCiZndDsgaGF2ZSB0byBkbyBhbiBleGFjdCBtYXRjaCwgYW5kICZxdW90O3JldHVybmVkJnF1 b3Q7PSZxdW90O25ldmVyJnF1b3Q7IHNpbmNlIHRoZSB2YWx1ZSBpcyAmbmJzcDtoYXNoZWQgYW5k IHNob3VsZCBub3QgYmUgcmV0dXJuZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgTm90ZTogJm5ic3A7 dGhlIGluZGV4IHR5cGUgd2lsbCBhbHNvIGRlcGVuZCBvbiB0aGUgdmFsdWUgb2YgY2FzZUV4YWN0 LiBGb3IgJm5ic3A7ZXhhbXBsZSBjYXNlRXhhY3QgPSBmYWxzZSBtZWFucyB0aGUgc2VhcmNoIGlu ZGV4IGlzIGNhc2UgaW5zZW5zaXRpdmUuPGJyPg0KJmd0OyBjYXNlRXhhY3Q9JnF1b3Q7dHJ1ZSZx dW90OyBtZWFucyBpbmRleCBpcyBjYXNlIHNlbnNpdGl2ZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAm cXVvdDthbHdheXMmcXVvdDsgaXMgdXNlZCBmb3IgYXR0cmlidXRlcyB0aGF0IG11c3QgYWx3YXlz IGJlIHJldHVybmVkIHN1Y2ggYXMgJnF1b3Q7aWQmcXVvdDs8YnI+DQomZ3Q7ICZxdW90O25ldmVy JnF1b3Q7IGlzIHVzZWQgZm9yIHdyaXRlLW9ubHkgYXR0cmlidXRlcyB0aGF0IGNhbm5vdCBvciBz aG91bGQgbm90IGJlICZuYnNwO3JldHVybmVkLjxicj4NCiZndDsgJnF1b3Q7ZGVmYXVsdCZxdW90 OyBpcyB1c2VkIGJ5IG1vc3QgYXR0cmlidXRlcyBhbmQgbWVhbnMgYXJlIHJldHVybmVkIGlmIHRo ZSAmbmJzcDthdHRyaWJ1dGUgcGFyYW0gaXMgbWlzc2luZy4gSW4gb3RoZXIgd29yZHMgdGhlIGF0 dHJpYnV0ZSBpcyByZXR1cm5lZCBvbiAmbmJzcDtkZWZhdWx0Ljxicj4NCiZndDsgJnF1b3Q7cmVx dWVzdCZxdW90OyBtZWFucyB0aGF0IHRoZSBhdHRyaWJ1dGUgd2lsbCBvbmx5IGJlIHJldHVybmVk IGlmIHJlcXVlc3RlZC48YnI+DQomZ3Q7IE5vdGU6IHRoaXMgaXMgc2ltaWxhciB0byBvcGVyYXRp b25hbCBhdHRyaWJ1dGVzIGluIExEQVAuPGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7 IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0m IzQzOy0tLTxicj4NCiZndDsgUmVwb3J0ZXI6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE93bmVyOiAmbmJzcDtk cmFmdC1pZXRmLXNjaW0tY29yZS08YnI+DQomZ3Q7ICZuYnNwOzxhIGhyZWY9Im1haWx0bzptZWxp bmRhLnNob3JlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1lbGluZGEuc2hvcmVAZ21haWwu Y29tPC9hPnwgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOnNjaGVtYUB0b29scy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNjaGVtYUB0b29scy5pZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgVHlwZTogJm5ic3A7ZW5oYW5jZW1lbnQgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNw O1N0YXR1czogJm5ic3A7bmV3PGJyPg0KJmd0OyBQcmlvcml0eTogJm5ic3A7bWFqb3IgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgTWlsZXN0b25lOjxicj4NCiZndDsgQ29tcG9u ZW50OiAmbmJzcDtjb3JlLXNjaGVtYSAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgVmVyc2lvbjo8YnI+ DQomZ3Q7IFNldmVyaXR5OiAmbmJzcDstICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fCAmbmJzcDtSZXNvbHV0aW9uOjxicj4NCiZndDsgS2V5d29yZHM6ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzst LS08YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaWNrZXQgVVJMOiAmbHQ7PGEgaHJlZj0iaHR0cDovL3Ry YWMudG9vbHMuaWV0Zi5vcmcvd2cvc2NpbS90cmFjL3RpY2tldC8xMCNjb21tZW50OjIiIHRhcmdl dD0iX2JsYW5rIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9zY2ltL3RyYWMvdGlja2V0 LzEwI2NvbW1lbnQ6MjwvYT4mZ3Q7PGJyPg0KJmd0OyBzY2ltICZsdDs8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvc2NpbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5v cmcvc2NpbS88L2E+Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzY2ltIG1haWxpbmcgbGlzdDxi cj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5z Y2ltQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zY2ltIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2NpbSBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zY2ltIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zY2ltPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0Kc2NpbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2NpbUBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpzY2ltIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3Jn Ij5zY2ltQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2NpbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zY2ltPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_e2abc6499e3d4a1491d943ecaf8622beBN1PR04MB392namprd04pro_-- From phil.hunt@oracle.com Thu Sep 12 17:53:57 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C46E11E80E0 for ; Thu, 12 Sep 2013 17:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF8Gp6KmLKpP for ; Thu, 12 Sep 2013 17:53:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 38E2521F9CF3 for ; Thu, 12 Sep 2013 17:53:52 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8D0rmwU031378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Sep 2013 00:53:48 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8D0rkhN027257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 00:53:47 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8D0rksO027251; Fri, 13 Sep 2013 00:53:46 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Sep 2013 17:53:46 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_B56480E1-F89A-456D-BB68-45894452EB31" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Phil Hunt In-Reply-To: Date: Thu, 12 Sep 2013 17:53:44 -0700 Message-Id: <3CB53E1C-1144-445C-BFF8-8209E65616BB@oracle.com> References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> <21F50FE4-BD8E-4A61-9140-2E1E048F4F50@oracle.com> <0B996C4F-4ACE-49AF-BD9A-CFF9B6525E69@oracle.com> <04B8A773-A22D-4BA3-8BF9-34A23BEEB031@oracle.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Samuel Erdtman , "scim@ietf.org WG" Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 00:53:57 -0000 --Apple-Mail=_B56480E1-F89A-456D-BB68-45894452EB31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sorry Kelly, I have to disagree. Let's think this through carefully=85. REST APIs need to have simplistic error signalling. We have to assume = cases where no detailed error message will be returned.=20 When you state that any unresolved filter must fail the entire operation = it often may mean no query is possible. For example a filter with = multiple filter terms that are OR'd together would have to fail if even = one term could not be resolved. What happens when one attribute has an attribute and another does not? = How does the filter term resolve? IMPORTANT CASE: when we extended get to work at the root level, the = assumption is that for some namespaces some filters aren't resolvable. = The assumption was that items would not be matched but that processing = would return only those items that match (unresolvable items are = ignored). So if a SCIM searches throws error, we have to then re-write = how top level searching works since most of those would fail because = different branches have different attributes. The only queries that = could succeed are where attributes are common across all resources - = rendering the feature useless. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-12, at 3:17 PM, Kelly Grizzle = wrote: > IMO, silently ignoring invalid queries leads to more problems than the = client having to handle errors. It seems like an error 500 with a = reasonable error message would be easier for a client to be able to = understand why their query did not work the way they intended. > =20 > We could return the supported index type information in the schema so = that servers can be more self-documenting. This would be especially = useful if you are trying to build a generic client that has no a priori = knowledge of the server. > =20 > On another note, to me an =93index=94 (and most coming from the RDBMS = world) indicates whether querying over a column will run quickly or not. = If we add this to the schema, maybe this should be =93supportedFilters=94= instead. > =20 > --Kelly > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Thursday, September 12, 2013 3:55 PM > To: Samuel Erdtman > Cc: scim@ietf.org; draft-ietf-scim-core-schema@tools.ietf.org; scim = issue tracker; Kelly Grizzle > Subject: Re: [scim] #10: Add ability to mark attributes as sensitive = in the schemas > =20 > Also. Check rfc2251 filter processing rules. I think this is an = example of a proven model for filter processing.=20 >=20 > Phil >=20 > On 2013-09-12, at 13:51, Phil Hunt wrote: >=20 > Inline >=20 > Phil >=20 > On 2013-09-12, at 12:18, Samuel Erdtman wrote: >=20 > Hi Phil > =20 > Are you saying that some backend systems might not allow some filter = operations and that it therefore would be good to indicate which so that = the client does not need to run into an error? > [ph] yes. And so that clients never receive an error.=20 >=20 > =20 > Or is it just to indicate that certain searches might take a bit = longer? this is how Kelly interprets it. > No >=20 > =20 > If the server has search query limitations it would have to define the = error any way since the client might ignore the not allowed information. > =20 > [ph] errors need to be avoided in a restful environment. I have put = text in issue 48(?) to cover processing rules for invalid filters.=20 >=20 > I would vote for simplicity i.e. try the operation and adapt according = to error message. And if it is just a speed indication I cannot se any = reason for it, it just adds complexity. > =20 > [ph] errors mean huge complexity. Remember x.500? > =20 > Cheers > //Samuel > =20 > =20 > =20 > =20 > =20 > =20 >=20 > On Wed, Sep 11, 2013 at 7:04 PM, Phil Hunt = wrote: > Samuel, > =20 > Regarding use case for index discovery=85. > =20 > Building a user self-service component that allows searching for = colleages/friends, whatever. The UI needs to know what attributes are = searchable and what search queries are allowed (exact, startsWith, = endsWith, isLike, substring, etc). > =20 > The UI could be client side tool that allows an administrator to query = the data each of the cloud service providers they use. > =20 > The implication from an inter-op perspective is that either all SCIM = SPs support substring indexing of all attributes, OR deployers can set = specific indexes based on their performance needs and abilities. If the = latter, the client has to know in order to know what searches are = possible. > =20 > It is doubtful that many of us can support substring indexing of all = attributes. Putting aside the performance issue, there are issues with = some attributes where privacy or security would block partial match = searches and only exact match searches would be allowed - very much = acting like an 'Identity Oracle'. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 >=20 > =20 > =20 > =20 >=20 > =20 > On 2013-09-11, at 10:18 AM, Samuel Erdtman wrote: >=20 >=20 > I agree with Kelly. > +1 for returned > And for index I cannot se the benefit. What is the use case that needs = this? > =20 > Cheers > //Samuel > =20 >=20 > On Tue, Sep 10, 2013 at 5:02 PM, Phil Hunt = wrote: > Kelly, >=20 > The problem is that if the index is anything other than "substring", = then the client has to restrict the type of filter it generates, since = the index may not be able to match using the filter specified. If the = filter result become unspecified (because index doesn't support filter = type) and a match should not occur, what should the server do? > A. Throw an error > B. Simply not match the entry >=20 > Because of REST style and the public nature of these APIs, I would = rather avoid complex error messages and go with B. This means that = clients need discovery to find out what query filters are supported. >=20 > It goes without saying I would be open to expanding index to = multi-valued and being specific as to what search filters are supported. = When I wrote the message below, I was thinking about the exact match = case and that it is different from substring. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 2013-09-10, at 6:42 AM, Kelly Grizzle = wrote: >=20 > > +1 for the "returned" attribute and its values. > > > > Regarding "index", this might be overkill. Filters support = different operators (eq, sw, co) to do exact and substring matching. = The index just indicates server-side behavior about the most optimal way = to query. While this information isn't harmful, it may be more than = what we need. > > > > --Kelly > > > > > > -----Original Message----- > > From: scim issue tracker [mailto:trac+scim@tools.ietf.org] > > Sent: Monday, September 09, 2013 3:54 PM > > To: draft-ietf-scim-core-schema@tools.ietf.org; Kelly Grizzle; = phil.hunt@oracle.com > > Cc: scim@ietf.org > > Subject: Re: [scim] #10: Add ability to mark attributes as sensitive = in the schemas > > > > #10: Add ability to mark attributes as sensitive in the schemas > > > > > > Comment (by phil.hunt@oracle.com): > > > > I would like to propose a series of settings per attribute to cover = this issue. Under /schemas, each attribute would have the following > > attributes: > > > > "index"=3D"none"|"substring"|"exact" > > "returned"=3D"always"|"never"|"default"|"request" > > > > For example, password would have "index"=3D"exact" since the = client would > > have to do an exact match, and "returned"=3D"never" since the value = is hashed and should not be returned. > > > > Note: the index type will also depend on the value of caseExact. = For example caseExact =3D false means the search index is case = insensitive. > > caseExact=3D"true" means index is case sensitive. > > > > "always" is used for attributes that must always be returned such as = "id" > > "never" is used for write-only attributes that cannot or should not = be returned. > > "default" is used by most attributes and means are returned if the = attribute param is missing. In other words the attribute is returned on = default. > > "request" means that the attribute will only be returned if = requested. > > Note: this is similar to operational attributes in LDAP. > > > > -- > > = -------------------------+---------------------------------------------- > > -------------------------+--- > > Reporter: | Owner: draft-ietf-scim-core- > > melinda.shore@gmail.com| schema@tools.ietf.org > > Type: enhancement | Status: new > > Priority: major | Milestone: > > Component: core-schema | Version: > > Severity: - | Resolution: > > Keywords: | > > = -------------------------+---------------------------------------------- > > -------------------------+--- > > > > Ticket URL: = > > scim > > > > _______________________________________________ > > scim mailing list > > scim@ietf.org > > https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > =20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_B56480E1-F89A-456D-BB68-45894452EB31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 2013-09-12, at 3:17 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

IMO, silently ignoring = invalid queries leads to more problems than the client having to handle = errors.  It seems like an error 500 with a reasonable error message = would be easier for a client to be able to understand why their query = did not work the way they intended.
 
We could return the = supported index type information in the schema so that servers can be = more self-documenting.  This would be especially useful if you are = trying to build a generic client that has no a priori knowledge of the = server.
 
On another note, to me an =93index=94 (and = most coming from the RDBMS world) indicates whether querying over a = column will run quickly or not.  If we add this to the schema, = maybe this should be =93supportedFilters=94 = instead.
 
--Kelly
From: Phil Hunt = [mailto:phil.hunt@oracle.com] 
Sent: Thursday, September 12, = 2013 3:55 PM
To: Samuel = Erdtman
Cc: scim@ietf.org; draft-ietf-scim= -core-schema@tools.ietf.org; scim issue tracker; Kelly = Grizzle
Subject: Re: [scim] #10: Add ability = to mark attributes as sensitive in the = schemas
Also. Check = rfc2251 filter processing rules. I think this is an example of a proven = model for filter = processing. 

Phil


On 2013-09-12, at 13:51, = Phil Hunt <phil.hunt@oracle.com> = wrote:


On 2013-09-12, at 12:18, Samuel Erdtman <samuel@erdtman.se> = wrote:

Hi = Phil
Are = you saying that some backend systems might not allow some filter = operations and that it therefore would be good to indicate which so that = the client does not need to run into an = error?
[ph] = yes. And so that clients never receive an = error. 

Or = is it just to indicate that certain searches might take a bit longer? = this is how Kelly interprets it.
No

 
If the server has search query limitations it would = have to define the error any way since the client might ignore the not = allowed information.
 
 
[ph] errors mean huge complexity. Remember = x.500?
 

On = Wed, Sep 11, 2013 at 7:04 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
Regarding use = case for index discovery=85.
 
 
The UI could be client side tool that allows an = administrator to query the data each of the cloud service providers they = use.
The = implication from an inter-op perspective is that either all SCIM SPs = support substring indexing of all attributes, OR deployers can set = specific indexes based on their performance needs and abilities. =  If the latter, the client has to know in order to know what = searches are possible.
 
It = is doubtful that many of us can support substring indexing of all = attributes. Putting aside the performance issue, there are issues with = some attributes where privacy or security would block partial match = searches and only exact match searches would be allowed - very much = acting like an 'Identity Oracle'.
 
 
I agree with = Kelly.
+1 for = returned
And = for index I cannot se the benefit. What is the use case that needs = this?
 

On = Tue, Sep 10, 2013 at 5:02 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
A.  Throw an error
B.  Simply not match = the entry

Because of REST style and the public nature of these = APIs, I would rather avoid complex error messages and go with B. This = means that clients need discovery to find out what query filters are = supported.

It goes without saying I would be open to expanding = index to multi-valued and being specific as to what search filters are = supported.  When I wrote the message below, I was thinking about = the exact match case and that it is different from = substring.

Phil

@independentid
www.independentid.com







On 2013-09-10, at 6:42 AM, Kelly = Grizzle <>
> Regarding "index", = this might be overkill.  Filters support different operators (eq, = sw, co) to do exact and substring matching.  The index just = indicates server-side behavior about the most optimal way to query. =  While this information isn't harmful, it may be more than what we = need.
>
> --Kelly
>
>
> -----Original = Message-----
> From: scim issue tracker [mailto:  phil.hunt@oracle.com
> = Cc: scim@ietf.org
> Subject: Re: = [scim] #10: Add ability to mark attributes as sensitive in the = schemas
>
> #10: Add ability to mark attributes as sensitive = in the schemas
>
>
> Comment (by > = "returned"=3D"always"|"never"|"default"|"request"
>
> For = example, password would have   "index"=3D"exact" since the client = would
> have to do an exact match, and "returned"=3D"never" since = the value is  hashed and should not be returned.
>
> = Note:  the index type will also depend on the value of caseExact. = For  example caseExact =3D false means the search index is case = insensitive.
> caseExact=3D"true" means index is case = sensitive.
>
> "always" is used for attributes that must = always be returned such as "id"
> "never" is used for write-only = attributes that cannot or should not be  returned.
> = "default" is used by most attributes and means are returned if the =  attribute param is missing. In other words the attribute is = returned on  default.
> "request" means that the attribute = will only be returned if requested.
> Note: this is similar to = operational attributes in LDAP.
>
> --
> = -------------------------+----------------------------------------------> -------------------------+---
> Reporter:     =           |       Owner: =  draft-ietf-scim-core-
>  melinda.shore@gmail.com| =   scim@ietf.org
> scim@ietf.org
 

= --Apple-Mail=_B56480E1-F89A-456D-BB68-45894452EB31-- From leifj@mnt.se Thu Sep 12 23:47:10 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C52611E8151 for ; Thu, 12 Sep 2013 23:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTfB-eNLiRTW for ; Thu, 12 Sep 2013 23:47:04 -0700 (PDT) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id A79D511E8153 for ; Thu, 12 Sep 2013 23:47:03 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id c50so356442eek.4 for ; Thu, 12 Sep 2013 23:47:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=mvh6HpAflzhYuPQGs/gI9vvWfZ8Jp1Du4wdXzYf3W5o=; b=IFgxwROh/3Lu5We2a+bbzmXrN5Iz4V/hUn4SExA+pGTy2C5Dsm2A7kylwOHmBA9xNQ KmHVUjcgVW6GlVbUptAyNAe/c/eX2RIBSDnOQGr8aCi/3ilhvc30q0O/7UfsQtxZWvAi Ygq8gbPVhxtm6EkyA/QJ5qKQIVp9/dmODKT11PNWdt31Rnpej39aVyKRQbkkpTbQzktQ +1iiAPMBwdG2AAI4uEqZXbayxc5LyZ1gSve40pbye02EDcsZ45+84QujxptOxa2zNmnV h8gDy/GLuOnvlVwByRUXsLDrb/WVhdYkbdDKLEoRNjVFzgE3YxL7Gd1aTT2Gi7APTQts IN1A== X-Gm-Message-State: ALoCoQkf0NIAaaGHLgii0y0OQgi/qRiv8TdB7fmFNiWuTyqr3J50L58N478qh2cmSmEwRh9Ip6b/ X-Received: by 10.15.91.3 with SMTP id r3mr16227354eez.4.1379054822745; Thu, 12 Sep 2013 23:47:02 -0700 (PDT) Received: from [109.105.104.183] (dhcp49.se-tug.nordu.net. [109.105.104.183]) by mx.google.com with ESMTPSA id z12sm12075046eev.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 23:47:02 -0700 (PDT) Message-ID: <5232B4E4.5060009@mnt.se> Date: Fri, 13 Sep 2013 08:47:00 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: scim@ietf.org References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> <21F50FE4-BD8E-4A61-9140-2E1E048F4F50@oracle.com> <0B996C4F-4ACE-49AF-BD9A-CFF9B6525E69@oracle.com> <04B8A773-A22D-4BA3-8BF9-34A23BEEB031@oracle.com> <3CB53E1C-1144-445C-BFF8-8209E65616BB@oracle.com> In-Reply-To: <3CB53E1C-1144-445C-BFF8-8209E65616BB@oracle.com> Content-Type: multipart/alternative; boundary="------------050902080902030102070208" Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 06:47:10 -0000 This is a multi-part message in MIME format. --------------050902080902030102070208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/13/2013 02:53 AM, Phil Hunt wrote: > Sorry Kelly, I have to disagree. Let's think this through carefully.... > ... with the chair switch firmly locked in the OFF-position > REST APIs need to have simplistic error signalling. We have to assume > cases where no detailed error message will be returned. > > When you state that any unresolved filter must fail the entire > operation it often may mean no query is possible. For example a filter > with multiple filter terms that are OR'd together would have to fail > if even one term could not be resolved. > > What happens when one attribute has an attribute and another does not? > How does the filter term resolve? > > There is a *big* difference between being able to process a filter and not matching because data isn't available and not being able to process a filter because you don't understand the filter definition. Filtering on givenName=Foo when then entry doesn't have a givenName attribute clearly should resolve to False. The case when you don't have '=' in your set of filter operations should result in a 400 (bad request) imo Cheers Leif --------------050902080902030102070208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/13/2013 02:53 AM, Phil Hunt wrote:
Sorry Kelly, I have to disagree.  Let's think this through carefully….

... with the chair switch firmly locked in the OFF-position
REST APIs need to have simplistic error signalling.  We have to assume cases where no detailed error message will be returned. 

When you state that any unresolved filter must fail the entire operation it often may mean no query is possible. For example a filter with multiple filter terms that are OR'd together would have to fail if even one term could not be resolved.

What happens when one attribute has an attribute and another does not?  How does the filter term resolve?


There is a *big* difference between being able to process a filter and not matching because
data isn't available and not being able to process a filter because you don't understand the
filter definition. Filtering on givenName=Foo when then entry doesn't have a givenName
attribute clearly should resolve to False.

The case when you don't have '=' in your set of filter operations should result in a 400 (bad
request) imo

        Cheers Leif

       
--------------050902080902030102070208-- From phil.hunt@oracle.com Fri Sep 13 00:33:21 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1D421F9FD0 for ; Fri, 13 Sep 2013 00:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92gn9ZU9xjqS for ; Fri, 13 Sep 2013 00:33:16 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 54A9B21F9F31 for ; Fri, 13 Sep 2013 00:33:16 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8D7XEmj019691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Sep 2013 07:33:15 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8D7XDvF013165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 07:33:14 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8D7XDxa013161; Fri, 13 Sep 2013 07:33:13 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Sep 2013 00:33:13 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Phil Hunt In-Reply-To: <5232B4E4.5060009@mnt.se> Date: Fri, 13 Sep 2013 00:33:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9A2E5964-C9CE-483A-87C3-46E131B4B6E0@oracle.com> References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> <21F50FE4-BD8E-4A61-9140-2E1E048F4F50@oracle.com> <0B996C4F-4ACE-49AF-BD9A-CFF9B6525E69@oracle.com> <04B8A773-A22D-4BA3-8BF9-34A23BEEB031@oracle.com> <3CB53E1C-1144-445C-BFF8-8209E65616BB@oracle.com> <5232B4E4.5060009@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: scim@ietf.org Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 07:33:21 -0000 Leif, I think a little more detail of the detailed error response is known. = Returning 400 won't allow clients to figure out why their search didn't = work. It seems to me, this has only been superficially thought through.=20= I believe the text I put in is non-breaking where as changing processing = rules to throwing bad request errors is a major change. The example I gave was what happens across different data sets processed = in a single query. It turns out to not be a problem based on the = algorithm that LDAP uses. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-12, at 11:47 PM, Leif Johansson wrote: > On 09/13/2013 02:53 AM, Phil Hunt wrote: >> Sorry Kelly, I have to disagree. Let's think this through = carefully=85. >>=20 > ... with the chair switch firmly locked in the OFF-position >> REST APIs need to have simplistic error signalling. We have to = assume cases where no detailed error message will be returned.=20 >>=20 >> When you state that any unresolved filter must fail the entire = operation it often may mean no query is possible. For example a filter = with multiple filter terms that are OR'd together would have to fail if = even one term could not be resolved. >>=20 >> What happens when one attribute has an attribute and another does = not? How does the filter term resolve? >>=20 >>=20 > There is a *big* difference between being able to process a filter and = not matching because > data isn't available and not being able to process a filter because = you don't understand the=20 > filter definition. Filtering on givenName=3DFoo when then entry = doesn't have a givenName=20 > attribute clearly should resolve to False. >=20 > The case when you don't have '=3D' in your set of filter operations = should result in a 400 (bad > request) imo >=20 > Cheers Leif >=20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From tonynad@microsoft.com Fri Sep 13 09:08:27 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4108921F9951 for ; Fri, 13 Sep 2013 09:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0e+RqUirADK for ; Fri, 13 Sep 2013 09:08:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id C73D621F9D70 for ; Fri, 13 Sep 2013 09:08:21 -0700 (PDT) Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB142.namprd03.prod.outlook.com (10.242.35.147) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 13 Sep 2013 16:08:19 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.26]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.26]) with mapi id 15.00.0775.005; Fri, 13 Sep 2013 16:08:18 +0000 From: Anthony Nadalin To: Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Agenda request for sept 18 Thread-Index: AQHOraC/F2f7QEhEjUebEPHQEK/7QJnD20Ig Date: Fri, 13 Sep 2013 16:08:18 +0000 Message-ID: <74c642fa98ce40bda99a4cb415718b7d@BY2PR03MB189.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::3] x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(558084003)(74316001)(76786001)(74366001)(53806001)(74876001)(54316002)(76576001)(79102001)(59766001)(77982001)(63696002)(74706001)(81816001)(81686001)(76796001)(33646001)(83322001)(76482001)(56816003)(77096001)(46102001)(80976001)(47976001)(47736001)(56776001)(54356001)(49866001)(81342001)(4396001)(65816001)(81542001)(74502001)(47446002)(50986001)(74662001)(80022001)(69226001)(83072001)(51856001)(31966008)(42262001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB142; H:BY2PR03MB189.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::3; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: Lucy Lynch , Mark Wahl Subject: Re: [scim] Agenda request for sept 18 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:08:27 -0000 I would like to add a topic to next weeks call, and that would be about a 1= 0 min discussion of a interop at IETF 88 that Mark Wahl will lead. From kelly.grizzle@sailpoint.com Fri Sep 13 11:42:25 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16C211E8171 for ; Fri, 13 Sep 2013 11:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ips-8JmqX+3h for ; Fri, 13 Sep 2013 11:42:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 05DDC11E8184 for ; Fri, 13 Sep 2013 11:42:15 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 13 Sep 2013 18:42:09 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) with mapi id 15.00.0745.000; Fri, 13 Sep 2013 18:42:09 +0000 From: Kelly Grizzle To: Phil Hunt , Leif Johansson Thread-Topic: [scim] #10: Add ability to mark attributes as sensitive in the schemas Thread-Index: AQHOsFOM/Usy1fo0gUiej3wVYGbvGZnD/54Q Date: Fri, 13 Sep 2013 18:42:08 +0000 Message-ID: <6f2511e8461d494383f4e2c06cb906cd@BN1PR04MB392.namprd04.prod.outlook.com> References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> <21F50FE4-BD8E-4A61-9140-2E1E048F4F50@oracle.com> <0B996C4F-4ACE-49AF-BD9A-CFF9B6525E69@oracle.com> <04B8A773-A22D-4BA3-8BF9-34A23BEEB031@oracle.com> <3CB53E1C-1144-445C-BFF8-8209E65616BB@oracle.com> <5232B4E4.5060009@mnt.se> <9A2E5964-C9CE-483A-87C3-46E131B4B6E0@oracle.com> In-Reply-To: <9A2E5964-C9CE-483A-87C3-46E131B4B6E0@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 091501A40053BE091502F1 x-originating-ip: [2001:4870:600a:500::2] x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(479174003)(189002)(199002)(24454002)(377424004)(13464003)(51444003)(51704005)(79102001)(81342001)(80976001)(77982001)(69226001)(59766001)(81542001)(81686001)(65816001)(80022001)(51856001)(76796001)(76576001)(15975445006)(56816003)(77096001)(74316001)(74366001)(76786001)(46102001)(19580395003)(54356001)(54316002)(4396001)(74876001)(74502001)(47446002)(53806001)(15974865002)(74706001)(49866001)(47976001)(47736001)(33646001)(31966008)(63696002)(56776001)(19580405001)(83072001)(83322001)(76482001)(81816001)(50986001)(74662001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:2001:4870:600a:500::2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 18:42:25 -0000 I'm with Leif here - missing attribute handling is fine as-is, but a server= refusing to query because of an unsupported operation is quite different. Regarding detailed errors, the spec already has facilities for this: The SCIM Protocol uses the response status codes defined in HTTP [12] to indicate operation success or failure. In addition to returning a HTTP response code implementers MUST return the errors in the body of the response in the client requested format containing the error response and, per the HTTP specification, human-readable explanations. Error responses are identified using the following URI: 'urn:scim:schemas:core:2.0:Error'. In addition to this, issue #46 was opened to address allowing non-HTTP resp= onse codes (ie - SCIM-specific error codes) to be returned in addition to t= he HTTP response code to give more information. IMO, returning an error here would not be a breaking change. I think that = the current specs are just largely deficient around possible error conditio= ns. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Friday, September 13, 2013 2:33 AM To: Leif Johansson Cc: scim@ietf.org Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the= schemas Leif, I think a little more detail of the detailed error response is known. Retu= rning 400 won't allow clients to figure out why their search didn't work. = It seems to me, this has only been superficially thought through.=20 I believe the text I put in is non-breaking where as changing processing ru= les to throwing bad request errors is a major change. The example I gave was what happens across different data sets processed in= a single query. It turns out to not be a problem based on the algorithm t= hat LDAP uses. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-12, at 11:47 PM, Leif Johansson wrote: > On 09/13/2013 02:53 AM, Phil Hunt wrote: >> Sorry Kelly, I have to disagree. Let's think this through carefully.... >>=20 > ... with the chair switch firmly locked in the OFF-position >> REST APIs need to have simplistic error signalling. We have to assume c= ases where no detailed error message will be returned.=20 >>=20 >> When you state that any unresolved filter must fail the entire operation= it often may mean no query is possible. For example a filter with multiple= filter terms that are OR'd together would have to fail if even one term co= uld not be resolved. >>=20 >> What happens when one attribute has an attribute and another does not? = How does the filter term resolve? >>=20 >>=20 > There is a *big* difference between being able to process a filter and=20 > not matching because data isn't available and not being able to=20 > process a filter because you don't understand the filter definition.=20 > Filtering on givenName=3DFoo when then entry doesn't have a givenName att= ribute clearly should resolve to False. >=20 > The case when you don't have '=3D' in your set of filter operations=20 > should result in a 400 (bad > request) imo >=20 > Cheers Leif >=20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Fri Sep 13 12:21:39 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D058211E80D3 for ; Fri, 13 Sep 2013 12:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8iNRNJZ9xtV for ; Fri, 13 Sep 2013 12:21:34 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7C96321F942D for ; Fri, 13 Sep 2013 12:21:30 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8DJLPjG003627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Sep 2013 19:21:26 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8DJLNho005302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 19:21:23 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8DJLMQ3014867; Fri, 13 Sep 2013 19:21:22 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Sep 2013 12:21:22 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Phil Hunt In-Reply-To: <6f2511e8461d494383f4e2c06cb906cd@BN1PR04MB392.namprd04.prod.outlook.com> Date: Fri, 13 Sep 2013 12:21:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <14F2B2EB-1A32-486E-9E34-97813783FCE0@oracle.com> References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.a1f5bc2fb828e800e9cbcaffced83d3d@tools.ietf.org> <21F50FE4-BD8E-4A61-9140-2E1E048F4F50@oracle.com> <0B996C4F-4ACE-49AF-BD9A-CFF9B6525E69@oracle.com> <04B8A773-A22D-4BA3-8BF9-34A23BEEB031@oracle.com> <3CB53E1C-1144-445C-BFF8-8209E65616BB@oracle.com> <5232B4E4.5060009@mnt.se> <9A2E5964-C9CE-483A-87C3-46E131B4B6E0@oracle.com> <6f2511e8461d494383f4e2c06cb906cd@BN1PR04MB392.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 19:21:39 -0000 I am open to considering a proposal, but it needs to be fully defined = with detailed error messages. This is a major change for us. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-13, at 11:42 AM, Kelly Grizzle = wrote: > I'm with Leif here - missing attribute handling is fine as-is, but a = server refusing to query because of an unsupported operation is quite = different. >=20 > Regarding detailed errors, the spec already has facilities for this: >=20 > The SCIM Protocol uses the response status codes defined in HTTP = [12] > to indicate operation success or failure. In addition to returning = a > HTTP response code implementers MUST return the errors in the body = of > the response in the client requested format containing the error > response and, per the HTTP specification, human-readable > explanations. Error responses are identified using the following > URI: 'urn:scim:schemas:core:2.0:Error'. >=20 > In addition to this, issue #46 was opened to address allowing non-HTTP = response codes (ie - SCIM-specific error codes) to be returned in = addition to the HTTP response code to give more information. >=20 > IMO, returning an error here would not be a breaking change. I think = that the current specs are just largely deficient around possible error = conditions. >=20 > --Kelly >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Friday, September 13, 2013 2:33 AM > To: Leif Johansson > Cc: scim@ietf.org > Subject: Re: [scim] #10: Add ability to mark attributes as sensitive = in the schemas >=20 > Leif, >=20 > I think a little more detail of the detailed error response is known. = Returning 400 won't allow clients to figure out why their search didn't = work. It seems to me, this has only been superficially thought through.=20= >=20 > I believe the text I put in is non-breaking where as changing = processing rules to throwing bad request errors is a major change. >=20 > The example I gave was what happens across different data sets = processed in a single query. It turns out to not be a problem based on = the algorithm that LDAP uses. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 2013-09-12, at 11:47 PM, Leif Johansson wrote: >=20 >> On 09/13/2013 02:53 AM, Phil Hunt wrote: >>> Sorry Kelly, I have to disagree. Let's think this through = carefully.... >>>=20 >> ... with the chair switch firmly locked in the OFF-position >>> REST APIs need to have simplistic error signalling. We have to = assume cases where no detailed error message will be returned.=20 >>>=20 >>> When you state that any unresolved filter must fail the entire = operation it often may mean no query is possible. For example a filter = with multiple filter terms that are OR'd together would have to fail if = even one term could not be resolved. >>>=20 >>> What happens when one attribute has an attribute and another does = not? How does the filter term resolve? >>>=20 >>>=20 >> There is a *big* difference between being able to process a filter = and=20 >> not matching because data isn't available and not being able to=20 >> process a filter because you don't understand the filter definition.=20= >> Filtering on givenName=3DFoo when then entry doesn't have a givenName = attribute clearly should resolve to False. >>=20 >> The case when you don't have '=3D' in your set of filter operations=20= >> should result in a 400 (bad >> request) imo >>=20 >> Cheers Leif >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Wed Sep 18 08:53:22 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3793211E8124 for ; Wed, 18 Sep 2013 08:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYwgvTnzmYHN for ; Wed, 18 Sep 2013 08:53:08 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0648511E8115 for ; Wed, 18 Sep 2013 08:53:06 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8IFr5L4006809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Sep 2013 15:53:06 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8IFr5HF014134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Sep 2013 15:53:05 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8IFr4Go026711 for ; Wed, 18 Sep 2013 15:53:04 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Sep 2013 08:53:04 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8F0C62B8-B56B-4619-97F0-FCB99A43F69E@oracle.com> Date: Wed, 18 Sep 2013 08:53:03 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [scim] Filter negation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 15:53:22 -0000 Has there been any progress on negative filters. = http://tools.ietf.org/wg/scim/trac/ticket/24 We need to get these basics cleaned up. Phil @independentid www.independentid.com phil.hunt@oracle.com From kelly.grizzle@sailpoint.com Wed Sep 18 09:32:59 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC27821F9433 for ; Wed, 18 Sep 2013 09:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpITalLVWq0D for ; Wed, 18 Sep 2013 09:32:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bn1lp0156.outbound.protection.outlook.com [207.46.163.156]) by ietfa.amsl.com (Postfix) with ESMTP id 6B21A21F9360 for ; Wed, 18 Sep 2013 09:32:55 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 18 Sep 2013 16:32:54 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.206]) with mapi id 15.00.0745.000; Wed, 18 Sep 2013 16:32:54 +0000 From: Kelly Grizzle To: Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Filter negation Thread-Index: AQHOtIdLyE4BxWPaIEadQK1TsgbkNpnLsC2g Date: Wed, 18 Sep 2013 16:32:53 +0000 Message-ID: References: <8F0C62B8-B56B-4619-97F0-FCB99A43F69E@oracle.com> In-Reply-To: <8F0C62B8-B56B-4619-97F0-FCB99A43F69E@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0AC33E9D0054540AC33FEA x-originating-ip: [2001:4870:600a:500::2] x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(13464003)(199002)(189002)(4396001)(74316001)(63696002)(50986001)(47976001)(49866001)(47736001)(46102001)(15202345003)(76482001)(74876001)(56776001)(74366001)(15974865002)(81816001)(53806001)(54356001)(19580405001)(59766001)(51856001)(77982001)(79102001)(83322001)(19580395003)(80022001)(65816001)(561944002)(74706001)(83072001)(56816003)(74502001)(31966008)(74662001)(47446002)(33646001)(15975445006)(77096001)(76796001)(54316002)(81686001)(81342001)(80976001)(69226001)(76576001)(76786001)(81542001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:2001:4870:600a:500::2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Filter negation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 16:32:59 -0000 Bjorn has an action item from our last call to take a first crack at a prop= osal for this. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Wednesday, September 18, 2013 10:53 AM To: scim@ietf.org WG Subject: [scim] Filter negation Has there been any progress on negative filters. http://tools.ietf.org/wg/= scim/trac/ticket/24 We need to get these basics cleaned up. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Wed Sep 18 09:36:57 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8919511E80E4 for ; Wed, 18 Sep 2013 09:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ctmMDJqs3kA for ; Wed, 18 Sep 2013 09:36:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABDA11E8124 for ; Wed, 18 Sep 2013 09:36:48 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8IGajp7023736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Sep 2013 16:36:46 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8IGajGv011181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Sep 2013 16:36:45 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8IGajIQ017051; Wed, 18 Sep 2013 16:36:45 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Sep 2013 09:36:45 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: Date: Wed, 18 Sep 2013 09:36:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9DAD7C4E-D6AA-47B4-A093-0ED888A396FF@oracle.com> References: <8F0C62B8-B56B-4619-97F0-FCB99A43F69E@oracle.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "scim@ietf.org WG" Subject: Re: [scim] Filter negation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 16:36:57 -0000 I also see we have a "sw" filter operation but no "ew" or endswith = filter operation. Should we (or is it already) start a new ticket? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-18, at 9:32 AM, Kelly Grizzle = wrote: > Bjorn has an action item from our last call to take a first crack at a = proposal for this. >=20 > --Kelly >=20 >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Wednesday, September 18, 2013 10:53 AM > To: scim@ietf.org WG > Subject: [scim] Filter negation >=20 > Has there been any progress on negative filters. = http://tools.ietf.org/wg/scim/trac/ticket/24 >=20 > We need to get these basics cleaned up. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Wed Sep 18 09:44:02 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EAB11E80E4 for ; Wed, 18 Sep 2013 09:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g41x7mDjAgs for ; Wed, 18 Sep 2013 09:43:58 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id DF6D811E80ED for ; Wed, 18 Sep 2013 09:43:57 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 18 Sep 2013 16:43:54 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.206]) with mapi id 15.00.0745.000; Wed, 18 Sep 2013 16:43:54 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: [scim] Filter negation Thread-Index: AQHOtIdLyE4BxWPaIEadQK1TsgbkNpnLsC2ggAABSICAAAGroA== Date: Wed, 18 Sep 2013 16:43:53 +0000 Message-ID: <7560de8eedbe4738bf7d7baec9977ef1@BN1PR04MB392.namprd04.prod.outlook.com> References: <8F0C62B8-B56B-4619-97F0-FCB99A43F69E@oracle.com> <9DAD7C4E-D6AA-47B4-A093-0ED888A396FF@oracle.com> In-Reply-To: <9DAD7C4E-D6AA-47B4-A093-0ED888A396FF@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0ACD51330054540ACD5280 x-originating-ip: [2001:4870:600a:500::2] x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(13464003)(51704005)(377454003)(24454002)(377424004)(33646001)(15975445006)(74502001)(31966008)(56816003)(47446002)(74662001)(76786001)(76576001)(69226001)(81542001)(76796001)(77096001)(54316002)(81686001)(80976001)(81342001)(74876001)(76482001)(15202345003)(15974865002)(56776001)(74366001)(49866001)(4396001)(63696002)(74316001)(47976001)(50986001)(47736001)(46102001)(65816001)(80022001)(19580395003)(74706001)(83072001)(561944002)(54356001)(53806001)(19580405001)(81816001)(79102001)(77982001)(83322001)(51856001)(59766001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:2001:4870:600a:500::2; RD:InfoNoRecords; A:3; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org WG" Subject: Re: [scim] Filter negation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 16:44:02 -0000 This is not currently supported and I don't know of an open ticket for this= . I agree that it would be a valuable addition and worth opening a ticket = for. -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Wednesday, September 18, 2013 11:37 AM To: Kelly Grizzle Cc: scim@ietf.org WG Subject: Re: [scim] Filter negation I also see we have a "sw" filter operation but no "ew" or endswith filter o= peration. Should we (or is it already) start a new ticket? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-18, at 9:32 AM, Kelly Grizzle wrot= e: > Bjorn has an action item from our last call to take a first crack at a pr= oposal for this. >=20 > --Kelly >=20 >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of P= hil Hunt > Sent: Wednesday, September 18, 2013 10:53 AM > To: scim@ietf.org WG > Subject: [scim] Filter negation >=20 > Has there been any progress on negative filters. http://tools.ietf.org/w= g/scim/trac/ticket/24 >=20 > We need to get these basics cleaned up. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From bjorn.aannestad@unboundid.com Wed Sep 18 10:09:42 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E664511E826D for ; Wed, 18 Sep 2013 10:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6S46B2yusnt for ; Wed, 18 Sep 2013 10:09:35 -0700 (PDT) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 20C2111E8127 for ; Wed, 18 Sep 2013 10:09:35 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id f12so5315103vbg.25 for ; Wed, 18 Sep 2013 10:09:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FWzTb0Jbr/Kc2lbYj2DQswPvS94BQvSwwKQx51bNyD4=; b=by3N6zsmwHniK+msgUYXd+e5gAFlJw657h/7hM/p1RTPfoenu5/GlET2kmN7Qc+kjh /WsBkjzr7m1V3c7nvTKbUyNE0oKPAKcOrfIbl5sIPJXNhf5V2iZWBhCpfqWQj31Dk2vg 9UZjNCiJiDrYI5MyEpwFBjysXGiSPLqKYfWz3IhWNrA+5zOdJPOMCQBTI9dlEsudtfzl m95Mxd3fmgKyaiZsHWvm0eNwGOBzTM+/I2XQKvQ+8o9p9VQEz0ieRp8Z9P0lEfuQhzfN VtakbrEjY+2cQ0n0dwYfKVr49y1Hxpf1AaNncdGGMlSXNyHIso1fEh3cNLWl3UfD9aR7 y8WQ== X-Gm-Message-State: ALoCoQm/uVoxj4gJ3u9zGzJYW45mGbHEla5FYzBnG4ByoEnsqB3T9YJdGb4Mij7/DMY1wCPaXU48 X-Received: by 10.58.233.173 with SMTP id tx13mr1186440vec.31.1379524174433; Wed, 18 Sep 2013 10:09:34 -0700 (PDT) Received: from [10.8.1.116] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPSA id m6sm2199113vdi.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 10:09:33 -0700 (PDT) Message-ID: <5239DE4A.4040507@unboundid.com> Date: Wed, 18 Sep 2013 12:09:30 -0500 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: scim@ietf.org References: <8F0C62B8-B56B-4619-97F0-FCB99A43F69E@oracle.com> <9DAD7C4E-D6AA-47B4-A093-0ED888A396FF@oracle.com> <7560de8eedbe4738bf7d7baec9977ef1@BN1PR04MB392.namprd04.prod.outlook.com> In-Reply-To: <7560de8eedbe4738bf7d7baec9977ef1@BN1PR04MB392.namprd04.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Filter negation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 17:09:42 -0000 I'll take care of both of those today. -Bjorn On 2013-09-18 11:43 AM, Kelly Grizzle wrote: > This is not currently supported and I don't know of an open ticket for this. I agree that it would be a valuable addition and worth opening a ticket for. > > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Wednesday, September 18, 2013 11:37 AM > To: Kelly Grizzle > Cc: scim@ietf.org WG > Subject: Re: [scim] Filter negation > > I also see we have a "sw" filter operation but no "ew" or endswith filter operation. > > Should we (or is it already) start a new ticket? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > On 2013-09-18, at 9:32 AM, Kelly Grizzle wrote: > >> Bjorn has an action item from our last call to take a first crack at a proposal for this. >> >> --Kelly >> >> >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt >> Sent: Wednesday, September 18, 2013 10:53 AM >> To: scim@ietf.org WG >> Subject: [scim] Filter negation >> >> Has there been any progress on negative filters. http://tools.ietf.org/wg/scim/trac/ticket/24 >> >> We need to get these basics cleaned up. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Wed Sep 18 10:53:25 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866F111E810B for ; Wed, 18 Sep 2013 10:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M07bMG3MZ4Lf for ; Wed, 18 Sep 2013 10:53:17 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 63B8F11E80FF for ; Wed, 18 Sep 2013 10:53:17 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8IHrG4q030676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Sep 2013 17:53:16 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8IHrFhK009438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Sep 2013 17:53:16 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8IHrFAU009416 for ; Wed, 18 Sep 2013 17:53:15 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Sep 2013 10:53:15 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 18 Sep 2013 10:53:13 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [scim] WG Call today X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 17:53:25 -0000 Are we on for the call today? Are we following up on Barry's ppt from last time? Phil @independentid www.independentid.com phil.hunt@oracle.com From barryleiba.mailing.lists@gmail.com Wed Sep 18 10:57:59 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8706811E80E4 for ; Wed, 18 Sep 2013 10:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.982 X-Spam-Level: X-Spam-Status: No, score=-101.982 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+QN1iEVPcb3 for ; Wed, 18 Sep 2013 10:57:59 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0F56D11E80A2 for ; Wed, 18 Sep 2013 10:57:58 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz11so5969159veb.3 for ; Wed, 18 Sep 2013 10:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ad7mCuWMWDiARyXUYwFkiiD8RJFg1Is4ZfFeIPyy0dI=; b=GGpoH+O4m6ZiTK5rHpxmPCfDq7dlMxpS/OJHCxNekSen1IGmTug4ov/xS8q+LllOoR YAS9zVUBpeBcIX6TP2Lad9n98npo7YMv4QGfg6MlqHEeWdcaYiaGEMIUegtgYCAFcsHp 4DPMEP7XSubXtWzs4C4p6FsRxBKF7wBfNZWe0a87g1WDBjJKezqkEEpgvtS+BiCX3m57 b2VlWhYZsJRQC/KI1mzpzSN3oju7V9ovOIlDzBjkJk7KXcyKCt7utFQIcWpTfCgz3yD0 nc6GgZcYJO/SxRgcn1+B+nLXXBRItRtIYc4KAQFtsieQ1CbZnj7UrR0YgHHTu45fdZDQ 3B5g== MIME-Version: 1.0 X-Received: by 10.58.46.229 with SMTP id y5mr31561003vem.15.1379527078396; Wed, 18 Sep 2013 10:57:58 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.215.16 with HTTP; Wed, 18 Sep 2013 10:57:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Sep 2013 13:57:58 -0400 X-Google-Sender-Auth: TsKzkdTh3HzxrDL6OjvdrdSJQm4 Message-ID: From: Barry Leiba To: Phil Hunt Content-Type: text/plain; charset=ISO-8859-1 Cc: "scim@ietf.org WG" Subject: Re: [scim] WG Call today X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 17:57:59 -0000 > Are we on for the call today? > Are we following up on Barry's ppt from last time? That's how I understand it, and I'm on the WebEx bridge. Barry From bjorn.aannestad@unboundid.com Wed Sep 18 11:03:01 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07B811E80EC for ; Wed, 18 Sep 2013 11:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW8GumsZAg1c for ; Wed, 18 Sep 2013 11:02:57 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id 37C3111E80A2 for ; Wed, 18 Sep 2013 11:02:57 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hv10so3261726vcb.22 for ; Wed, 18 Sep 2013 11:02:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5LE4DxJH2zRju6zcWbxU6tan0wX673ZwKbxt6+TAOko=; b=cqJkEmpcQ2K6w8vHX7EqgCF+y47f0OdxylIkZuOT4rUBTZ9HltRJK0YzilQwlSOvjz rH5gFVr0SItog9M0GY/LNvwYUyCpVdDE3oUnHuCoEmUM+GdJyo9WIm7MhS9TTzuIq4V7 Dt46RB7wcoxZAxOxDT1sGSNaYM6CefMPjxMrHEzww+m366jyUPn71Q97Meh/cJ4LnA/X xqwABT99175fKqaepCg4lNnZBQw/Xtd7Ngljhgo8/CWga2t+xlLRZG+32vqzLoF31QJt nUcCY+10uwcY1yRDq33PBJsdFuWjpBQwlJHBz8wkFQyCCzfsEs1G0CMC8p56gCmCdEUS /rAQ== X-Gm-Message-State: ALoCoQkqisSkpW2aMesh+/v/nFXkjQIsHeNux/nkI9yDR49LS4B79CBB0KmK1QfFpYGJiKPtVZPS X-Received: by 10.58.155.68 with SMTP id vu4mr8269667veb.21.1379527376628; Wed, 18 Sep 2013 11:02:56 -0700 (PDT) Received: from [10.8.1.116] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPSA id i6sm2519087vdv.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 11:02:55 -0700 (PDT) Message-ID: <5239EAC9.2030903@unboundid.com> Date: Wed, 18 Sep 2013 13:02:49 -0500 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: scim@ietf.org References: <8F0C62B8-B56B-4619-97F0-FCB99A43F69E@oracle.com> <9DAD7C4E-D6AA-47B4-A093-0ED888A396FF@oracle.com> In-Reply-To: <9DAD7C4E-D6AA-47B4-A093-0ED888A396FF@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Filter negation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 18:03:01 -0000 Thank you for creating it Phil, looks good. http://trac.tools.ietf.org/wg/scim/trac/ticket/49 -Bjorn On 2013-09-18 11:36 AM, Phil Hunt wrote: > I also see we have a "sw" filter operation but no "ew" or endswith filter operation. > > Should we (or is it already) start a new ticket? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > On 2013-09-18, at 9:32 AM, Kelly Grizzle wrote: > >> Bjorn has an action item from our last call to take a first crack at a proposal for this. >> >> --Kelly >> >> >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt >> Sent: Wednesday, September 18, 2013 10:53 AM >> To: scim@ietf.org WG >> Subject: [scim] Filter negation >> >> Has there been any progress on negative filters. http://tools.ietf.org/wg/scim/trac/ticket/24 >> >> We need to get these basics cleaned up. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From swm16@psu.edu Wed Sep 18 13:02:07 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E38111E810D for ; Wed, 18 Sep 2013 13:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaJ89VZDSMSN for ; Wed, 18 Sep 2013 13:02:01 -0700 (PDT) Received: from tr21g12.aset.psu.edu (tr21g12.aset.psu.edu [146.186.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id B0CBA11E80A2 for ; Wed, 18 Sep 2013 13:02:00 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr21g12.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r8IK1qMj2363586 for ; Wed, 18 Sep 2013 16:01:53 -0400 Date: Wed, 18 Sep 2013 16:01:52 -0400 (EDT) From: "Steven W. Moyer" To: scim@ietf.org Message-ID: <1726944172.10889466.1379534512141.JavaMail.zimbra@psu.edu> In-Reply-To: <216716137.10807335.1379531981595.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.118.58.157] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF22 (Mac)/8.0.4_GA_5737) Thread-Topic: Processing SCIM search/query filters Thread-Index: N5HXcq7JaVGB0Rb5GAHgMBR6HnPY2A== X-Virus-Scanned: by amavisd-new Subject: [scim] Processing SCIM search/query filters X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Steven W. Moyer" List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 20:02:07 -0000 We've created a lexer and predictive parser (a recursive descent parser for LL grammars) that we believe will properly convert a filter string into an expression hierarchy. The only issue with this parser is that the precedence of AND over OR means that the SCIM filter grammar is not strictly LL, so this lexer/parser will currently produce errors for sum-of-product type filters when the AND clauses are not grouped in parenthesis (so the grammar is parsed into groups recursively but otherwise proceeds left-to-right). Currently, our requirements don't include OR clauses, but we do intend to make the parser compliant with the SCIM specifications (probably by adding a preprocessor that inserts grouping operators around and clauses). In the mean-time, we thought we'd post a sample of input/output here for comments and advice. We'd be happy to add filters to the test cases and would appreciate verification of the operation we've shown below. It's also our intention to share the Java code for this project as well as the (currently) minimal test suite. If anyone is interested, we'll make the repository public sooner rather than later. Thanks, Steve Moyer P.S. In the output below, the input filter string is printed, followed by the tree the parser created. ===== SNIP ===== [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: userName eq "bjensen" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: EQ | +---userName +---bjensen [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: name.familyName co "O'Malley" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: CO | +---name.familyName +---O'Malley [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: userName sw "J" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: SW | +---userName +---J [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: title pr [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: PR | +---title +---null [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: meta.lastModified gt "2011-05-13T04:42:34Z" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: GT | +---meta.lastModified +---2011-05-13T04:42:34Z [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: meta.lastModified ge "2011-05-13T04:42:34Z" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: GE | +---meta.lastModified +---2011-05-13T04:42:34Z [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: meta.lastModified lt "2011-05-13T04:42:34Z" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: LT | +---meta.lastModified +---2011-05-13T04:42:34Z [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: meta.lastModified le "2011-05-13T04:42:34Z" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: LE | +---meta.lastModified +---2011-05-13T04:42:34Z [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: title pr and userType eq "Employee" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: AND | +---PR | | | +---title | +---null | +---EQ | +---userType +---Employee [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: title pr or userType eq "Intern" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: OR | +---PR | | | +---title | +---null | +---EQ | +---userType +---Intern [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: userType eq "Employee" and (emails co "example.com" or emails co "example.org") [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: AND | +---EQ | | | +---userType | +---Employee | +---OR | +---CO | | | +---emails | +---example.com | +---CO | +---emails +---example.org [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: (emails co "example.com" or emails co "example.org") [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: OR | +---CO | | | +---emails | +---example.com | +---CO | +---emails +---example.org [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: (emails co "example.com" or emails co "example.org") and userType eq "Employee" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: AND | +---OR | | | +---CO | | | | | +---emails | | +---example.com | | | +---CO | | | +---emails | +---example.org | | +---EQ | +---userType +---Employee From bjorn.aannestad@unboundid.com Wed Sep 18 14:48:49 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E02621F9EA2 for ; Wed, 18 Sep 2013 14:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYT8KBclDSJN for ; Wed, 18 Sep 2013 14:48:44 -0700 (PDT) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBCE11E81F0 for ; Wed, 18 Sep 2013 14:48:44 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id pa12so6291761veb.30 for ; Wed, 18 Sep 2013 14:48:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=NSTJUDBis8A8ESPO7drFAAaDSwWepemNGMrxZ5Oj2EU=; b=jN/XX1euMNYw7YSHstYH+jD96F2+53pcDXW2ECN2LV+q5Er8PfEiUjtZm983nTs/ul T3mUYYBTKA3YHAc5rmig3qbc8DGICthRBvHM0xKz0EWbEgVDxNF//sFqG4xeTF7fnnrr Sn0bjGBgCWqC0AkJ+WwRK5lOe/A6JVBUurcLW60y6iJQKo40s1HaPz6v0ELSg31FY4Fc c5NnEkFjjbrGTpE6iW49u9GcywOOKFuGkC42QrHZ4or5yvK5RmHN2kpLmsl3/4bVA6qF 3Y83fQuXRXQ3DRuHXGxppfjZHynRhUCUT8mah4B9uvEo7Yn/+Eblm9sSrtdJDc+ozi7x YGGQ== X-Gm-Message-State: ALoCoQkSOoS7HID/6mFKWZXca4UEhEvkd9SezHMOkqrB0oaz5+PdCSuhG6RMdvD7ASuFQa3xUuwx X-Received: by 10.220.145.132 with SMTP id d4mr39642686vcv.9.1379540922625; Wed, 18 Sep 2013 14:48:42 -0700 (PDT) Received: from [10.8.1.116] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPSA id c16sm3931145vdj.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 14:48:42 -0700 (PDT) Message-ID: <523A1FB6.9000005@unboundid.com> Date: Wed, 18 Sep 2013 16:48:38 -0500 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: scim@ietf.org References: <8F0C62B8-B56B-4619-97F0-FCB99A43F69E@oracle.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010306010000090101010204" Subject: Re: [scim] Filter negation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 21:48:49 -0000 This is a multi-part message in MIME format. --------------010306010000090101010204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I've posted my first crack at filter negation to ticket #24: http://trac.tools.ietf.org/wg/scim/trac/ticket/24 It defines a not() operator which can only be used around other expressions. Based on the premise that most, if not all, implementations will be translating the SCIM filter syntax into equivalent SQL or LDAP syntax, I did not want to add redundant variety to the required expression forms. So, VALID: filter = not(userType eq "Employee") INVALID: filter = not userType eq "Employee" INVALID: filter = userType neq "Employee" VALID: userType eq "Employee" and not(emails co "example.com" or emails co "example.org") INVALID: filter = userType eq "Employee" and not emails co "example.com" and not emails co "example.org" VALID: filter = not(userType eq "Employee") and not(userType eq "Intern") VALID: filter = not(userType eq "Employee" or userType eq "Intern") INVALID: filter = userType not eq "Employee" and userType not eq "Intern" I believe the "negation grouping" method handles all cases. A specific point of discussion: Is there value in defining additional negative versions of the relational operators? neq => "not equal" npr => "not present" nco => "not contains", etc. Regards, -Bjorn On 2013-09-18 11:32 AM, Kelly Grizzle wrote: > Bjorn has an action item from our last call to take a first crack at a proposal for this. > > --Kelly > > > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Wednesday, September 18, 2013 10:53 AM > To: scim@ietf.org WG > Subject: [scim] Filter negation > > Has there been any progress on negative filters. http://tools.ietf.org/wg/scim/trac/ticket/24 > > We need to get these basics cleaned up. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------010306010000090101010204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

I've posted my first crack at filter negation to ticket #24:
http://trac.tools.ietf.org/wg/scim/trac/ticket/24

It defines a not() operator which can only be used around other expressions.  

Based on the premise that most, if not all, implementations will be translating the SCIM filter syntax into equivalent SQL or LDAP syntax, I did not want to add redundant variety to the required expression forms.

So,
VALID: filter = not(userType eq "Employee")
INVALID: filter = not userType eq "Employee"
INVALID: filter = userType neq "Employee"

VALID: userType eq "Employee" and not(emails co "example.com" or emails co "example.org")
INVALID: filter = userType eq "Employee" and not emails co "example.com" and not emails co "example.org"

VALID: filter = not(userType eq "Employee") and not(userType eq "Intern")
VALID: filter = not(userType eq "Employee" or userType eq "Intern")
INVALID: filter = userType not eq "Employee" and userType not eq "Intern"

I believe the "negation grouping" method handles all cases. 

A specific point of discussion: Is there value in defining additional negative versions of the relational operators?
neq => "not equal"
npr => "not present"
nco => "not contains", etc.

Regards,
-Bjorn



On 2013-09-18 11:32 AM, Kelly Grizzle wrote:
Bjorn has an action item from our last call to take a first crack at a proposal for this.

--Kelly


-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, September 18, 2013 10:53 AM
To: scim@ietf.org WG
Subject: [scim] Filter negation

Has there been any progress on negative filters.  http://tools.ietf.org/wg/scim/trac/ticket/24

We need to get these basics cleaned up.

Phil

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







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

--------------010306010000090101010204-- From phil.hunt@oracle.com Wed Sep 18 15:05:54 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAD811E82E6 for ; Wed, 18 Sep 2013 15:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHrNkXRh4zcy for ; Wed, 18 Sep 2013 15:05:49 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E79F111E81CD for ; Wed, 18 Sep 2013 15:05:48 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8IM5k6I000491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Sep 2013 22:05:47 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8IM5jeN011149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Sep 2013 22:05:45 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8IM5jJH011144; Wed, 18 Sep 2013 22:05:45 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Sep 2013 15:05:45 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_E9A877A4-7A48-4FBF-82FB-ED25654489E0" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <523A1FB6.9000005@unboundid.com> Date: Wed, 18 Sep 2013 15:05:43 -0700 Message-Id: <2D1D6F1E-F911-4CBB-BFA9-0163FAB6FDF7@oracle.com> References: <8F0C62B8-B56B-4619-97F0-FCB99A43F69E@oracle.com> <523A1FB6.9000005@unboundid.com> To: Bjorn Aannestad X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: scim@ietf.org Subject: Re: [scim] Filter negation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 22:05:54 -0000 --Apple-Mail=_E9A877A4-7A48-4FBF-82FB-ED25654489E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I think on balance what you have proposed is easier. Let's not do neq = etc. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-18, at 2:48 PM, Bjorn Aannestad = wrote: > Hi all,=20 >=20 > I've posted my first crack at filter negation to ticket #24: > http://trac.tools.ietf.org/wg/scim/trac/ticket/24 >=20 > It defines a not() operator which can only be used around other = expressions. =20 >=20 > Based on the premise that most, if not all, implementations will be = translating the SCIM filter syntax into equivalent SQL or LDAP syntax, I = did not want to add redundant variety to the required expression forms. >=20 > So, > VALID: filter =3D not(userType eq "Employee") > INVALID: filter =3D not userType eq "Employee" > INVALID: filter =3D userType neq "Employee" >=20 > VALID: userType eq "Employee" and not(emails co "example.com" or = emails co "example.org") > INVALID: filter =3D userType eq "Employee" and not emails co = "example.com" and not emails co "example.org" >=20 > VALID: filter =3D not(userType eq "Employee") and not(userType eq = "Intern") > VALID: filter =3D not(userType eq "Employee" or userType eq "Intern") > INVALID: filter =3D userType not eq "Employee" and userType not eq = "Intern" >=20 > I believe the "negation grouping" method handles all cases. =20 >=20 > A specific point of discussion: Is there value in defining additional = negative versions of the relational operators? > neq =3D> "not equal" > npr =3D> "not present" > nco =3D> "not contains", etc. >=20 > Regards, > -Bjorn >=20 >=20 >=20 > On 2013-09-18 11:32 AM, Kelly Grizzle wrote: >> Bjorn has an action item from our last call to take a first crack at = a proposal for this. >>=20 >> --Kelly >>=20 >>=20 >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Phil Hunt >> Sent: Wednesday, September 18, 2013 10:53 AM >> To: scim@ietf.org WG >> Subject: [scim] Filter negation >>=20 >> Has there been any progress on negative filters. = http://tools.ietf.org/wg/scim/trac/ticket/24 >>=20 >> We need to get these basics cleaned up. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_E9A877A4-7A48-4FBF-82FB-ED25654489E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = think on balance what you have proposed is easier.   Let's not do = neq etc.


On 2013-09-18, at 2:48 PM, Bjorn Aannestad <bjorn.aannestad@unboundid.co= m> wrote:

=20 =20
Hi all,

I've posted my first crack at filter negation to ticket #24:
http://trac.too= ls.ietf.org/wg/scim/trac/ticket/24

It defines a not() operator which can only be used around other expressions.  

Based on the premise that most, if not all, implementations will be translating the SCIM filter syntax into equivalent SQL or LDAP syntax, I did not want to add redundant variety to the required expression forms.

So,
VALID: filter =3D not(userType eq "Employee")
INVALID: filter =3D not userType eq "Employee"
INVALID: filter =3D userType neq "Employee"

VALID: userType eq "Employee" and not(emails co "example.com" or emails co "example.org")example.com" and not emails co = "example.org"

VALID: filter =3D not(userType eq "Employee") and not(userType eq "Intern")
VALID: filter =3D not(userType eq "Employee" or userType eq = "Intern")
INVALID: filter =3D userType not eq "Employee" and userType not eq "Intern"

I believe the "negation grouping" method handles all cases.  =

A specific point of discussion: Is there value in defining additional negative versions of the relational operators?
neq =3D> "not equal"
npr =3D> "not present"
nco =3D> "not contains", etc.

Regards,
-Bjorn



On 2013-09-18 11:32 AM, Kelly Grizzle wrote:
Bjorn has an action item from our last call to take =
a first crack at a proposal for this.

--Kelly


-----Original Message-----
From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] =
On Behalf Of Phil Hunt
Sent: Wednesday, September 18, 2013 10:53 AM
To: scim@ietf.org WG
Subject: [scim] Filter negation

Has there been any progress on negative filters.  http://tools.ietf.or=
g/wg/scim/trac/ticket/24

We need to get these basics cleaned up.

Phil

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







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

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

= --Apple-Mail=_E9A877A4-7A48-4FBF-82FB-ED25654489E0-- From swm16@psu.edu Wed Sep 18 18:20:03 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C056611E812F for ; Wed, 18 Sep 2013 18:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDAly0bb-ubP for ; Wed, 18 Sep 2013 18:19:56 -0700 (PDT) Received: from tr22g10.aset.psu.edu (tr22g10.aset.psu.edu [146.186.149.133]) by ietfa.amsl.com (Postfix) with ESMTP id 2627911E80D5 for ; Wed, 18 Sep 2013 18:19:54 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr22g10.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r8J1JqEA3539014 for ; Wed, 18 Sep 2013 21:19:52 -0400 Date: Wed, 18 Sep 2013 21:19:51 -0400 (EDT) From: "Steven W. Moyer" To: scim@ietf.org Message-ID: <2011087747.11209022.1379553591708.JavaMail.zimbra@psu.edu> In-Reply-To: <69912754.11146818.1379547369925.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [209.158.7.249] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF23 (Linux)/8.0.4_GA_5737) Thread-Topic: Filter negation Thread-Index: SAFr8Pi+h8Brm/YUlRZXERj10FsBLw== X-Virus-Scanned: by amavisd-new Subject: Re: [scim] Filter negation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Steven W. Moyer" List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 01:20:03 -0000 Since we're defining "NOT" as an operator, I thought I'd perform a simple test of the proposed change. I simply added NOT to the LogicalOperator enum in our lexer/parser and ran the example filters provided by Bjorn Aannestad along with two variations to see what happened in the absence of parenthesis. I didn't however enforce a grouping requirement on the NOT operator and I didn't fix the "over-recursion" that occurred in the fifth case. In any case, after seeing the results and looking at parser complexity, I'd like to make some comments and suggestions: 1) Enforcing the parenthesis after the NOT token (processed as a token stream) requires either a look-ahead or carrying state in the parser (beyond what's provided by the head and/or tail recursion). I'd suggest we not require parenthesis unless you want the NOT operator to apply to the group following it. Otherwise, the NOT operator is in reality a function. 2) Enforcing the parenthesis after the NOT is in effect saying that the NOT operator is a higher precedence than both the AND and OR operators (only considering the logical operators). It makes sense for the logical operators to be a lower precedence than both the attribute operators and the grouping operators, but I'd suggest that it doesn't make sense to specify the precedence between the AND and OR operators in the API document and the precedence of the NOT in relation to the AND and OR operators using explicit grouping. I'd like to suggest that the consistency of the filter specification would be better with any of the following: - Declare that AND, NOT and OR have equal precedence and always process them left to right, forcing grouping operators for cases where that's not desired. - Explicitly state that NOT has a higher precedence than AND and OR understanding that this will require the parser to either preprocess these operators or to vary the extent of the left to right processing in the absence of grouping operators. - Abandon the NOT operator as a prefix and either use it as a modifier to an attribute operator or provide a set of negated operators (or both). 3) I think we can all agree that logically, these filters are the same: - not userType eq "Employee" - userType not eq "Employee" - userType neq "Employee" But these filters will (without heroics in the parser), result in different expressions as follows: - not userType eq "Employee" ----> not usertype = 'Employee' - userType not eq "Employee" ----> usertype <> 'Employee' - userType neq "Employee" ----> usertype <> 'Employee' So in the first case, where using an SQL logical operator to negate the result of an "=" comparison operator, but in the second and third cases, we're realizing that "not eq" and "neq" are synonyms. I think it would require an optimizer to make all three expressions evaluate to the same SQL fragment. And in fact, the third and fourth examples that Bjorn provided are an example of a complex equality that follows De Morgan's Law (1), yet the effort to optimize those expressions in one common variant wouldn't be worth the effort. I realize I'm relatively new here and I'll freely admit I haven't read much of the mailing list prior to April (assuming the 01 specification was current when that document came out), so please don't take this as criticism and feel free to ignore points that don't align with the group's interests. We'll create our implementation to comply with whatever the group decides. Thanks again for all the effort that you (collectively) have put into making something that I believe will be revolutionary. Steve Moyer ===== SNIP ===== [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not(userType eq "Employee") [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: NOT | +---EQ | +---userType +---Employee [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not userType eq "Employee" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: NOT | +---EQ | +---userType +---Employee [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: userType eq "Employee" and not(emails co "example.com" or emails co "example.org") [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: AND | +---EQ | | | +---userType | +---Employee | +---NOT | +---OR | +---CO | | | +---emails | +---example.com | +---CO | +---emails +---example.org [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not(userType eq "Employee") and not(userType eq "Intern") [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: AND | +---NOT | | | +---EQ | | | +---userType | +---Employee | | +---NOT | +---EQ | +---userType +---Intern [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not userType eq "Employee" and not userType eq "Intern" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: NOT | +---AND | +---EQ | | | +---userType | +---Employee | +---NOT | +---EQ | +---userType +---Intern [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not(userType eq "Employee" or userType eq "Intern") [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: NOT | +---OR | +---EQ | | | +---userType | +---Employee | +---EQ | +---userType +---Intern From phil.hunt@oracle.com Wed Sep 18 19:30:42 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F83611E817F for ; Wed, 18 Sep 2013 19:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.403 X-Spam-Level: X-Spam-Status: No, score=-3.403 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT8FoSf3mME3 for ; Wed, 18 Sep 2013 19:30:36 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A77CF11E81DB for ; Wed, 18 Sep 2013 19:30:36 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8J2UYmK024406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Sep 2013 02:30:35 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8J2UXL5015338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Sep 2013 02:30:34 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8J2UXg2008833; Thu, 19 Sep 2013 02:30:33 GMT Received: from [25.71.72.73] (/24.114.37.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Sep 2013 19:30:33 -0700 References: <2011087747.11209022.1379553591708.JavaMail.zimbra@psu.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <2011087747.11209022.1379553591708.JavaMail.zimbra@psu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <04875CCE-090D-402B-B6A0-EB072E8375DE@oracle.com> X-Mailer: iPhone Mail (11A465) From: Phil Hunt Date: Wed, 18 Sep 2013 19:30:26 -0700 To: "Steven W. Moyer" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "scim@ietf.org" Subject: Re: [scim] Filter negation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 02:30:42 -0000 I think not as a function is a requirement. We need to be able to say NOT(a eq b AND c eq d) It is often easier to scale what something isn't than what it is.=20 We need both grouping and not functions.=20 The alternative means a much much longer filter. So any parsing performance i= s lost.=20 IMHO parsing is the smallest part of performance cost by several orders of m= agnitude when compared to database connections and http connection handling .= .. which is pretty darn fast. Just sayin' Phil > On Sep 18, 2013, at 18:19, "Steven W. Moyer" wrote: >=20 > Since we're defining "NOT" as an operator, I thought I'd perform a simple t= est of the proposed change. I simply added NOT to the LogicalOperator enum i= n our lexer/parser and ran the example filters provided by Bjorn Aannestad a= long with two variations to see what happened in the absence of parenthesis.= I didn't however enforce a grouping requirement on the NOT operator and I d= idn't fix the "over-recursion" that occurred in the fifth case. >=20 > In any case, after seeing the results and looking at parser complexity, I'= d like to make some comments and suggestions: >=20 > 1) Enforcing the parenthesis after the NOT token (processed as a token st= ream) requires either a look-ahead or carrying state in the parser (beyond w= hat's provided by the head and/or tail recursion). I'd suggest we not requi= re parenthesis unless you want the NOT operator to apply to the group follow= ing it. Otherwise, the NOT operator is in reality a function. >=20 > 2) Enforcing the parenthesis after the NOT is in effect saying that the N= OT operator is a higher precedence than both the AND and OR operators (only c= onsidering the logical operators). It makes sense for the logical operators= to be a lower precedence than both the attribute operators and the grouping= operators, but I'd suggest that it doesn't make sense to specify the preced= ence between the AND and OR operators in the API document and the precedence= of the NOT in relation to the AND and OR operators using explicit grouping.= I'd like to suggest that the consistency of the filter specification would= be better with any of the following: >=20 > - Declare that AND, NOT and OR have equal precedence and always process th= em left to right, forcing grouping operators for cases where that's not desi= red. >=20 > - Explicitly state that NOT has a higher precedence than AND and OR unders= tanding that this will require the parser to either preprocess these operato= rs or to vary the extent of the left to right processing in the absence of g= rouping operators. >=20 > - Abandon the NOT operator as a prefix and either use it as a modifier to a= n attribute operator or provide a set of negated operators (or both). >=20 > 3) I think we can all agree that logically, these filters are the same: >=20 > - not userType eq "Employee" > - userType not eq "Employee" > - userType neq "Employee" >=20 > But these filters will (without heroics in the parser), result in differen= t expressions as follows: >=20 > - not userType eq "Employee" ----> not usertype =3D 'Employee' > - userType not eq "Employee" ----> usertype <> 'Employee' > - userType neq "Employee" ----> usertype <> 'Employee' >=20 > So in the first case, where using an SQL logical operator to negate the re= sult of an "=3D" comparison operator, but in the second and third cases, we'= re realizing that "not eq" and "neq" are synonyms. I think it would require= an optimizer to make all three expressions evaluate to the same SQL fragmen= t. And in fact, the third and fourth examples that Bjorn provided are an ex= ample of a complex equality that follows De Morgan's Law (1), yet the effort= to optimize those expressions in one common variant wouldn't be worth the e= ffort. >=20 > I realize I'm relatively new here and I'll freely admit I haven't read muc= h of the mailing list prior to April (assuming the 01 specification was curr= ent when that document came out), so please don't take this as criticism and= feel free to ignore points that don't align with the group's interests. We= 'll create our implementation to comply with whatever the group decides. >=20 > Thanks again for all the effort that you (collectively) have put into maki= ng something that I believe will be revolutionary. >=20 > Steve Moyer >=20 > =3D=3D=3D=3D=3D SNIP =3D=3D=3D=3D=3D >=20 > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fi= lter string: not(userType eq "Employee") > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fi= lter expression: > NOT > | > +---EQ > | > +---userType > +---Employee >=20 >=20 >=20 > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fi= lter string: not userType eq "Employee" > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fi= lter expression: > NOT > | > +---EQ > | > +---userType > +---Employee >=20 >=20 >=20 > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fi= lter string: userType eq "Employee" and not(emails co "example.com" or email= s co "example.org") > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fi= lter expression: > AND > | > +---EQ > | | > | +---userType > | +---Employee > | =20 > +---NOT > | > +---OR > | > +---CO > | | > | +---emails > | +---example.com > | =20 > +---CO > | > +---emails > +---example.org >=20 >=20 >=20 >=20 >=20 > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fi= lter string: not(userType eq "Employee") and not(userType eq "Intern") > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fi= lter expression: > AND > | > +---NOT > | | > | +---EQ > | | > | +---userType > | +---Employee > | =20 > | =20 > +---NOT > | > +---EQ > | > +---userType > +---Intern >=20 >=20 >=20 >=20 > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fi= lter string: not userType eq "Employee" and not userType eq "Intern" > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fi= lter expression: > NOT > | > +---AND > | > +---EQ > | | > | +---userType > | +---Employee > | =20 > +---NOT > | > +---EQ > | > +---userType > +---Intern >=20 >=20 >=20 >=20 >=20 > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fi= lter string: not(userType eq "Employee" or userType eq "Intern") > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fi= lter expression: > NOT > | > +---OR > | > +---EQ > | | > | +---userType > | +---Employee > | =20 > +---EQ > | > +---userType > +---Intern >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From swm16@psu.edu Thu Sep 19 01:46:47 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E5521F99F3 for ; Thu, 19 Sep 2013 01:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCRo022kCoCZ for ; Thu, 19 Sep 2013 01:46:42 -0700 (PDT) Received: from tr21g10.aset.psu.edu (tr21g10.aset.psu.edu [146.186.149.132]) by ietfa.amsl.com (Postfix) with ESMTP id 44A6021F95D0 for ; Thu, 19 Sep 2013 01:46:41 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr21g10.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r8J8kZGd3276852; Thu, 19 Sep 2013 04:46:35 -0400 Date: Thu, 19 Sep 2013 04:46:35 -0400 (EDT) From: "Steven W. Moyer" To: Phil Hunt Message-ID: <922992321.11326038.1379580395022.JavaMail.zimbra@psu.edu> In-Reply-To: <04875CCE-090D-402B-B6A0-EB072E8375DE@oracle.com> References: <2011087747.11209022.1379553591708.JavaMail.zimbra@psu.edu> <04875CCE-090D-402B-B6A0-EB072E8375DE@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [209.158.7.249] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF23 (Linux)/8.0.4_GA_5737) Thread-Topic: Filter negation Thread-Index: SUZgYL+IHxcHl+F5CLA+73Wy7Z/S6g== X-Virus-Scanned: by amavisd-new Cc: scim@ietf.org Subject: Re: [scim] Filter negation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Steven W. Moyer" List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 08:46:47 -0000 I completely agree that the syntax you've shown should represent a valid filter, but I was more suggesting that using NOT as a negation operator for the expression that followed was more consistent. In that case, your example remains the same (I've added spaces where our lexer would tokenize it): NOT ( a EQ b AND c eq d ) Treating NOT as an operator would however change (shorten) some of the other uses: NOT ( userType EQ "Employee" ) would be equivalent to: NOT userType EQ "Employee" since the expression containing the EQ has a higher precedence anyway (I've again used spaces to indicate where our lexer is splitting tokens). Rereading issue #24 (http://trac.tools.ietf.org/wg/scim/trac/ticket/24), I'm realizing that perhaps my misunderstanding is thinking of the NOT token as a logical operator. As a grouping operator is the token really always "NOT("? Should the syntax support "NOT (" (with a space between the NOT and opening parenthesis)? In this case I understand why it's precedence is higher than the LogicalOperators and lower than the AttributeOperators, but when would the precedence of NOT( over ( come into play? The examples I've considered can all be resolved by matching those operators to their closing parenthesis. Steve ----- Original Message ----- From: "Phil Hunt" To: "Steven W. Moyer" Cc: scim@ietf.org Sent: Wednesday, September 18, 2013 10:30:26 PM Subject: Re: [scim] Filter negation I think not as a function is a requirement. We need to be able to say NOT(a eq b AND c eq d) It is often easier to scale what something isn't than what it is. We need both grouping and not functions. The alternative means a much much longer filter. So any parsing performance is lost. IMHO parsing is the smallest part of performance cost by several orders of magnitude when compared to database connections and http connection handling ... which is pretty darn fast. Just sayin' Phil > On Sep 18, 2013, at 18:19, "Steven W. Moyer" wrote: > > Since we're defining "NOT" as an operator, I thought I'd perform a simple test of the proposed change. I simply added NOT to the LogicalOperator enum in our lexer/parser and ran the example filters provided by Bjorn Aannestad along with two variations to see what happened in the absence of parenthesis. I didn't however enforce a grouping requirement on the NOT operator and I didn't fix the "over-recursion" that occurred in the fifth case. > > In any case, after seeing the results and looking at parser complexity, I'd like to make some comments and suggestions: > > 1) Enforcing the parenthesis after the NOT token (processed as a token stream) requires either a look-ahead or carrying state in the parser (beyond what's provided by the head and/or tail recursion). I'd suggest we not require parenthesis unless you want the NOT operator to apply to the group following it. Otherwise, the NOT operator is in reality a function. > > 2) Enforcing the parenthesis after the NOT is in effect saying that the NOT operator is a higher precedence than both the AND and OR operators (only considering the logical operators). It makes sense for the logical operators to be a lower precedence than both the attribute operators and the grouping operators, but I'd suggest that it doesn't make sense to specify the precedence between the AND and OR operators in the API document and the precedence of the NOT in relation to the AND and OR operators using explicit grouping. I'd like to suggest that the consistency of the filter specification would be better with any of the following: > > - Declare that AND, NOT and OR have equal precedence and always process them left to right, forcing grouping operators for cases where that's not desired. > > - Explicitly state that NOT has a higher precedence than AND and OR understanding that this will require the parser to either preprocess these operators or to vary the extent of the left to right processing in the absence of grouping operators. > > - Abandon the NOT operator as a prefix and either use it as a modifier to an attribute operator or provide a set of negated operators (or both). > > 3) I think we can all agree that logically, these filters are the same: > > - not userType eq "Employee" > - userType not eq "Employee" > - userType neq "Employee" > > But these filters will (without heroics in the parser), result in different expressions as follows: > > - not userType eq "Employee" ----> not usertype = 'Employee' > - userType not eq "Employee" ----> usertype <> 'Employee' > - userType neq "Employee" ----> usertype <> 'Employee' > > So in the first case, where using an SQL logical operator to negate the result of an "=" comparison operator, but in the second and third cases, we're realizing that "not eq" and "neq" are synonyms. I think it would require an optimizer to make all three expressions evaluate to the same SQL fragment. And in fact, the third and fourth examples that Bjorn provided are an example of a complex equality that follows De Morgan's Law (1), yet the effort to optimize those expressions in one common variant wouldn't be worth the effort. > > I realize I'm relatively new here and I'll freely admit I haven't read much of the mailing list prior to April (assuming the 01 specification was current when that document came out), so please don't take this as criticism and feel free to ignore points that don't align with the group's interests. We'll create our implementation to comply with whatever the group decides. > > Thanks again for all the effort that you (collectively) have put into making something that I believe will be revolutionary. > > Steve Moyer > > ===== SNIP ===== > > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not(userType eq "Employee") > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: > NOT > | > +---EQ > | > +---userType > +---Employee > > > > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not userType eq "Employee" > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: > NOT > | > +---EQ > | > +---userType > +---Employee > > > > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: userType eq "Employee" and not(emails co "example.com" or emails co "example.org") > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: > AND > | > +---EQ > | | > | +---userType > | +---Employee > | > +---NOT > | > +---OR > | > +---CO > | | > | +---emails > | +---example.com > | > +---CO > | > +---emails > +---example.org > > > > > > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not(userType eq "Employee") and not(userType eq "Intern") > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: > AND > | > +---NOT > | | > | +---EQ > | | > | +---userType > | +---Employee > | > | > +---NOT > | > +---EQ > | > +---userType > +---Intern > > > > > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not userType eq "Employee" and not userType eq "Intern" > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: > NOT > | > +---AND > | > +---EQ > | | > | +---userType > | +---Employee > | > +---NOT > | > +---EQ > | > +---userType > +---Intern > > > > > > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not(userType eq "Employee" or userType eq "Intern") > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: > NOT > | > +---OR > | > +---EQ > | | > | +---userType > | +---Employee > | > +---EQ > | > +---userType > +---Intern > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From swm16@psu.edu Thu Sep 19 02:39:38 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E675E21F8EDF for ; Thu, 19 Sep 2013 02:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9T9p0MFlQ1h for ; Thu, 19 Sep 2013 02:39:33 -0700 (PDT) Received: from tr21g12.aset.psu.edu (tr21g12.aset.psu.edu [146.186.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id AAD7F21F883D for ; Thu, 19 Sep 2013 02:39:24 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr21g12.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r8J9dMC53194936; Thu, 19 Sep 2013 05:39:22 -0400 Date: Thu, 19 Sep 2013 05:39:22 -0400 (EDT) From: "Steven W. Moyer" To: Phil Hunt Message-ID: <550224196.11339745.1379583562544.JavaMail.zimbra@psu.edu> In-Reply-To: <922992321.11326038.1379580395022.JavaMail.zimbra@psu.edu> References: <2011087747.11209022.1379553591708.JavaMail.zimbra@psu.edu> <04875CCE-090D-402B-B6A0-EB072E8375DE@oracle.com> <922992321.11326038.1379580395022.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [209.158.7.249] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF23 (Linux)/8.0.4_GA_5737) Thread-Topic: Filter negation Thread-Index: SUZgYL+IHxcHl+F5CLA+73Wy7Z/S6mrDISoX X-Virus-Scanned: by amavisd-new Cc: scim@ietf.org Subject: Re: [scim] Filter negation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Steven W. Moyer" List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 09:39:39 -0000 If I'd considered my previous examples using an LDAP filter representation instead of SQL, I'd have seen the rationale for using NOT( as a grouping operator immediately: - not userType eq "Employee" ----> not usertype = 'Employee' | (!(userType=Employee)) - userType not eq "Employee" ----> usertype <> 'Employee' | No inequality operator - userType neq "Employee" ----> usertype <> 'Employee' | No inequality operator This also makes me wonder how the SCIM GT and LT operators would be translated ... would: filter=meta.lastModified gt "2011-05-13T04:42:34Z" ----> (!(modifiedTimestamp<=2011-05-13T04:42:34Z)) In any case, I'll rework our lexer to tokenize "NOT *(" (regex) as NOT( and alter the parser to create an expression up to the terminating ")". If someone could provide one or more examples where the precedence of ( and NOT( matters, I'll add them to our test cases. I'd like to build up a library of examples (in addition to the thirteen I pulled from the specification). Would the group be interested in a simple web page that allowed a filter string to be entered, showed whether it was valid or invalid, what tokens the lexer found and the expression tree generated by the parser. I could also show examples of how the expression tree would be translated into an LDAP filter and SQL where clause. Since the mapping of SCIM attributes to database columns or LDAP attributes would vary, this would only be for educational purposes. Steve ----- Original Message ----- From: "Steven W. Moyer" To: "Phil Hunt" Cc: scim@ietf.org Sent: Thursday, September 19, 2013 4:46:35 AM Subject: Re: [scim] Filter negation I completely agree that the syntax you've shown should represent a valid filter, but I was more suggesting that using NOT as a negation operator for the expression that followed was more consistent. In that case, your example remains the same (I've added spaces where our lexer would tokenize it): NOT ( a EQ b AND c eq d ) Treating NOT as an operator would however change (shorten) some of the other uses: NOT ( userType EQ "Employee" ) would be equivalent to: NOT userType EQ "Employee" since the expression containing the EQ has a higher precedence anyway (I've again used spaces to indicate where our lexer is splitting tokens). Rereading issue #24 (http://trac.tools.ietf.org/wg/scim/trac/ticket/24), I'm realizing that perhaps my misunderstanding is thinking of the NOT token as a logical operator. As a grouping operator is the token really always "NOT("? Should the syntax support "NOT (" (with a space between the NOT and opening parenthesis)? In this case I understand why it's precedence is higher than the LogicalOperators and lower than the AttributeOperators, but when would the precedence of NOT( over ( come into play? The examples I've considered can all be resolved by matching those operators to their closing parenthesis. Steve ----- Original Message ----- From: "Phil Hunt" To: "Steven W. Moyer" Cc: scim@ietf.org Sent: Wednesday, September 18, 2013 10:30:26 PM Subject: Re: [scim] Filter negation I think not as a function is a requirement. We need to be able to say NOT(a eq b AND c eq d) It is often easier to scale what something isn't than what it is. We need both grouping and not functions. The alternative means a much much longer filter. So any parsing performance is lost. IMHO parsing is the smallest part of performance cost by several orders of magnitude when compared to database connections and http connection handling ... which is pretty darn fast. Just sayin' Phil > On Sep 18, 2013, at 18:19, "Steven W. Moyer" wrote: > > Since we're defining "NOT" as an operator, I thought I'd perform a simple test of the proposed change. I simply added NOT to the LogicalOperator enum in our lexer/parser and ran the example filters provided by Bjorn Aannestad along with two variations to see what happened in the absence of parenthesis. I didn't however enforce a grouping requirement on the NOT operator and I didn't fix the "over-recursion" that occurred in the fifth case. > > In any case, after seeing the results and looking at parser complexity, I'd like to make some comments and suggestions: > > 1) Enforcing the parenthesis after the NOT token (processed as a token stream) requires either a look-ahead or carrying state in the parser (beyond what's provided by the head and/or tail recursion). I'd suggest we not require parenthesis unless you want the NOT operator to apply to the group following it. Otherwise, the NOT operator is in reality a function. > > 2) Enforcing the parenthesis after the NOT is in effect saying that the NOT operator is a higher precedence than both the AND and OR operators (only considering the logical operators). It makes sense for the logical operators to be a lower precedence than both the attribute operators and the grouping operators, but I'd suggest that it doesn't make sense to specify the precedence between the AND and OR operators in the API document and the precedence of the NOT in relation to the AND and OR operators using explicit grouping. I'd like to suggest that the consistency of the filter specification would be better with any of the following: > > - Declare that AND, NOT and OR have equal precedence and always process them left to right, forcing grouping operators for cases where that's not desired. > > - Explicitly state that NOT has a higher precedence than AND and OR understanding that this will require the parser to either preprocess these operators or to vary the extent of the left to right processing in the absence of grouping operators. > > - Abandon the NOT operator as a prefix and either use it as a modifier to an attribute operator or provide a set of negated operators (or both). > > 3) I think we can all agree that logically, these filters are the same: > > - not userType eq "Employee" > - userType not eq "Employee" > - userType neq "Employee" > > But these filters will (without heroics in the parser), result in different expressions as follows: > > - not userType eq "Employee" ----> not usertype = 'Employee' > - userType not eq "Employee" ----> usertype <> 'Employee' > - userType neq "Employee" ----> usertype <> 'Employee' > > So in the first case, where using an SQL logical operator to negate the result of an "=" comparison operator, but in the second and third cases, we're realizing that "not eq" and "neq" are synonyms. I think it would require an optimizer to make all three expressions evaluate to the same SQL fragment. And in fact, the third and fourth examples that Bjorn provided are an example of a complex equality that follows De Morgan's Law (1), yet the effort to optimize those expressions in one common variant wouldn't be worth the effort. > > I realize I'm relatively new here and I'll freely admit I haven't read much of the mailing list prior to April (assuming the 01 specification was current when that document came out), so please don't take this as criticism and feel free to ignore points that don't align with the group's interests. We'll create our implementation to comply with whatever the group decides. > > Thanks again for all the effort that you (collectively) have put into making something that I believe will be revolutionary. > > Steve Moyer > > ===== SNIP ===== > > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not(userType eq "Employee") > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: > NOT > | > +---EQ > | > +---userType > +---Employee > > > > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not userType eq "Employee" > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: > NOT > | > +---EQ > | > +---userType > +---Employee > > > > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: userType eq "Employee" and not(emails co "example.com" or emails co "example.org") > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: > AND > | > +---EQ > | | > | +---userType > | +---Employee > | > +---NOT > | > +---OR > | > +---CO > | | > | +---emails > | +---example.com > | > +---CO > | > +---emails > +---example.org > > > > > > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not(userType eq "Employee") and not(userType eq "Intern") > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: > AND > | > +---NOT > | | > | +---EQ > | | > | +---userType > | +---Employee > | > | > +---NOT > | > +---EQ > | > +---userType > +---Intern > > > > > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not userType eq "Employee" and not userType eq "Intern" > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: > NOT > | > +---AND > | > +---EQ > | | > | +---userType > | +---Employee > | > +---NOT > | > +---EQ > | > +---userType > +---Intern > > > > > > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not(userType eq "Employee" or userType eq "Intern") > [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: > NOT > | > +---OR > | > +---EQ > | | > | +---userType > | +---Employee > | > +---EQ > | > +---userType > +---Intern > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Thu Sep 19 06:46:29 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E993821F92B9 for ; Thu, 19 Sep 2013 06:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DpIxEOI8LUq for ; Thu, 19 Sep 2013 06:46:23 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 20E4321F9248 for ; Thu, 19 Sep 2013 06:46:22 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 19 Sep 2013 13:46:19 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.206]) with mapi id 15.00.0745.000; Thu, 19 Sep 2013 13:46:19 +0000 From: Kelly Grizzle To: "Steven W. Moyer" , "scim@ietf.org" Thread-Topic: Processing SCIM search/query filters Thread-Index: Ac61PpzE6zqQS5oiTlyGY9C/RJSZgA== Date: Thu, 19 Sep 2013 13:46:16 +0000 Message-ID: <06ff6ca5422a4c158a09777fe0b00d7f@BN1PR04MB392.namprd04.prod.outlook.com> References: <216716137.10807335.1379531981595.JavaMail.zimbra@psu.edu> <1726944172.10889466.1379534512141.JavaMail.zimbra@psu.edu> In-Reply-To: <1726944172.10889466.1379534512141.JavaMail.zimbra@psu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0F5115C10054700F51170E x-originating-ip: [72.182.10.254] x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(377454003)(199002)(164054003)(189002)(74876001)(46102001)(74366001)(74706001)(74316001)(54356001)(56816003)(53806001)(47976001)(51856001)(56776001)(63696002)(31966008)(49866001)(83072001)(77096001)(50986001)(80022001)(81816001)(74502001)(47446002)(74662001)(76796001)(15975445006)(81542001)(69226001)(66066001)(47736001)(54316002)(76482001)(76786001)(19580395003)(76576001)(81342001)(83322001)(59766001)(19580405001)(81686001)(80976001)(79102001)(65816001)(77982001)(33646001)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:72.182.10.254; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Processing SCIM search/query filters X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 13:46:30 -0000 Thanks Steven ... this is great! The output below all looks correct to me. I have been asked by a number of people about SCIM libraries - specifically= around filter processing - so I know that there will be interest in this. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ste= ven W. Moyer Sent: Wednesday, September 18, 2013 3:02 PM To: scim@ietf.org Subject: [scim] Processing SCIM search/query filters We've created a lexer and predictive parser (a recursive descent parser for= LL grammars) that we believe will properly convert a filter string into an= expression hierarchy. The only issue with this parser is that the precede= nce of AND over OR means that the SCIM filter grammar is not strictly LL, s= o this lexer/parser will currently produce errors for sum-of-product type f= ilters when the AND clauses are not grouped in parenthesis (so the grammar = is parsed into groups recursively but otherwise proceeds left-to-right). Currently, our requirements don't include OR clauses, but we do intend to m= ake the parser compliant with the SCIM specifications (probably by adding a= preprocessor that inserts grouping operators around and clauses). In the = mean-time, we thought we'd post a sample of input/output here for comments = and advice. We'd be happy to add filters to the test cases and would appre= ciate verification of the operation we've shown below. It's also our intention to share the Java code for this project as well as = the (currently) minimal test suite. If anyone is interested, we'll make th= e repository public sooner rather than later. Thanks, Steve Moyer P.S. In the output below, the input filter string is printed, followed by = the tree the parser created. =3D=3D=3D=3D=3D SNIP =3D=3D=3D=3D=3D [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter string: userName eq "bjensen" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter expression: EQ | +---userName +---bjensen [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter string: name.familyName co "O'Malley" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter expression: CO | +---name.familyName +---O'Malley [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter string: userName sw "J" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter expression: SW | +---userName +---J [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter string: title pr [main] INFO org.apache.directory.scim.search.lexerpars= er.FilterParser - Filter expression: PR | +---title +---null [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter string: meta.lastModified gt "2011-05-13T04:42:34Z" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter expression: GT | +---meta.lastModified +---2011-05-13T04:42:34Z [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter string: meta.lastModified ge "2011-05-13T04:42:34Z" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter expression: GE | +---meta.lastModified +---2011-05-13T04:42:34Z [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter string: meta.lastModified lt "2011-05-13T04:42:34Z" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter expression: LT | +---meta.lastModified +---2011-05-13T04:42:34Z [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter string: meta.lastModified le "2011-05-13T04:42:34Z" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter expression: LE | +---meta.lastModified +---2011-05-13T04:42:34Z [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter string: title pr and userType eq "Employee" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter expression: AND | +---PR | | | +---title | +---null | =20 +---EQ | +---userType +---Employee =20 [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter string: title pr or userType eq "Intern" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter expression: OR | +---PR | | | +---title | +---null | =20 +---EQ | +---userType +---Intern =20 [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter string: userType eq "Employee" and (emails co "example.com" or emails c= o "example.org") [main] INFO org.apache.directory.scim.search.lexerparser.F= ilterParser - Filter expression: AND | +---EQ | | | +---userType | +---Employee | =20 +---OR | +---CO | | | +---emails | +---example.com | =20 +---CO | +---emails +---example.org =20 =20 [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter string: (emails co "example.com" or emails co "example.org") [main] INF= O org.apache.directory.scim.search.lexerparser.FilterParser - Filter expres= sion: OR | +---CO | | | +---emails | +---example.com | =20 +---CO | +---emails +---example.org =20 [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter string: (emails co "example.com" or emails co "example.org") and userTy= pe eq "Employee" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Fil= ter expression: AND | +---OR | | | +---CO | | | | | +---emails | | +---example.com | | =20 | +---CO | | | +---emails | +---example.org | =20 | =20 +---EQ | +---userType +---Employee =20 _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From swm16@psu.edu Thu Sep 19 07:01:17 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65B521F92C2 for ; Thu, 19 Sep 2013 07:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ConCgGv55kgq for ; Thu, 19 Sep 2013 07:01:11 -0700 (PDT) Received: from tr21g10.aset.psu.edu (tr21g10.aset.psu.edu [146.186.149.132]) by ietfa.amsl.com (Postfix) with ESMTP id 632D921F9048 for ; Thu, 19 Sep 2013 07:01:11 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr21g10.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r8JE16Ce3608626; Thu, 19 Sep 2013 10:01:06 -0400 Date: Thu, 19 Sep 2013 10:01:06 -0400 (EDT) From: Steve Moyer To: Kelly Grizzle Message-ID: <2141938191.11660927.1379599266640.JavaMail.zimbra@psu.edu> In-Reply-To: <06ff6ca5422a4c158a09777fe0b00d7f@BN1PR04MB392.namprd04.prod.outlook.com> References: <216716137.10807335.1379531981595.JavaMail.zimbra@psu.edu> <1726944172.10889466.1379534512141.JavaMail.zimbra@psu.edu> <06ff6ca5422a4c158a09777fe0b00d7f@BN1PR04MB392.namprd04.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.118.58.157] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF22 (Mac)/8.0.4_GA_5737) Thread-Topic: Processing SCIM search/query filters Thread-Index: Ac61PpzE6zqQS5oiTlyGY9C/RJSZgDOr1API X-Virus-Scanned: by amavisd-new Cc: scim@ietf.org Subject: Re: [scim] Processing SCIM search/query filters X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Steve Moyer List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 14:01:18 -0000 Thanks for checking our work. We're following the on-going discussion on filter negation, but considered the NOT operator to be a logical operator rather than a grouping operator in our first implementation. It's just about fixed now, and I'll post the results to that thread. Since we've tailored the filter negation around the ability to create LDAP filters, I'm wondering if we're going to have problems with LT and GT since those operators don't exist in the LDAP syntax. The alternative is using negation there too: a < b ----> !(a >= b) a > b ----> !(a <= b) Steve ----- Original Message ----- From: "Kelly Grizzle" To: "Steven W. Moyer" , scim@ietf.org Sent: Thursday, September 19, 2013 9:46:16 AM Subject: RE: Processing SCIM search/query filters Thanks Steven ... this is great! The output below all looks correct to me. I have been asked by a number of people about SCIM libraries - specifically around filter processing - so I know that there will be interest in this. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Steven W. Moyer Sent: Wednesday, September 18, 2013 3:02 PM To: scim@ietf.org Subject: [scim] Processing SCIM search/query filters We've created a lexer and predictive parser (a recursive descent parser for LL grammars) that we believe will properly convert a filter string into an expression hierarchy. The only issue with this parser is that the precedence of AND over OR means that the SCIM filter grammar is not strictly LL, so this lexer/parser will currently produce errors for sum-of-product type filters when the AND clauses are not grouped in parenthesis (so the grammar is parsed into groups recursively but otherwise proceeds left-to-right). Currently, our requirements don't include OR clauses, but we do intend to make the parser compliant with the SCIM specifications (probably by adding a preprocessor that inserts grouping operators around and clauses). In the mean-time, we thought we'd post a sample of input/output here for comments and advice. We'd be happy to add filters to the test cases and would appreciate verification of the operation we've shown below. It's also our intention to share the Java code for this project as well as the (currently) minimal test suite. If anyone is interested, we'll make the repository public sooner rather than later. Thanks, Steve Moyer P.S. In the output below, the input filter string is printed, followed by the tree the parser created. ===== SNIP ===== [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: userName eq "bjensen" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: EQ | +---userName +---bjensen [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: name.familyName co "O'Malley" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: CO | +---name.familyName +---O'Malley [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: userName sw "J" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: SW | +---userName +---J [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: title pr [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: PR | +---title +---null [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: meta.lastModified gt "2011-05-13T04:42:34Z" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: GT | +---meta.lastModified +---2011-05-13T04:42:34Z [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: meta.lastModified ge "2011-05-13T04:42:34Z" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: GE | +---meta.lastModified +---2011-05-13T04:42:34Z [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: meta.lastModified lt "2011-05-13T04:42:34Z" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: LT | +---meta.lastModified +---2011-05-13T04:42:34Z [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: meta.lastModified le "2011-05-13T04:42:34Z" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: LE | +---meta.lastModified +---2011-05-13T04:42:34Z [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: title pr and userType eq "Employee" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: AND | +---PR | | | +---title | +---null | +---EQ | +---userType +---Employee [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: title pr or userType eq "Intern" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: OR | +---PR | | | +---title | +---null | +---EQ | +---userType +---Intern [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: userType eq "Employee" and (emails co "example.com" or emails co "example.org") [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: AND | +---EQ | | | +---userType | +---Employee | +---OR | +---CO | | | +---emails | +---example.com | +---CO | +---emails +---example.org [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: (emails co "example.com" or emails co "example.org") [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: OR | +---CO | | | +---emails | +---example.com | +---CO | +---emails +---example.org [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: (emails co "example.com" or emails co "example.org") and userType eq "Employee" [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: AND | +---OR | | | +---CO | | | | | +---emails | | +---example.com | | | +---CO | | | +---emails | +---example.org | | +---EQ | +---userType +---Employee _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Thu Sep 19 07:06:38 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1706E21F9425 for ; Thu, 19 Sep 2013 07:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maWsWSGAx3Z1 for ; Thu, 19 Sep 2013 07:06:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 5814C21F93DB for ; Thu, 19 Sep 2013 07:06:33 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 19 Sep 2013 14:06:24 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.236]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.206]) with mapi id 15.00.0745.000; Thu, 19 Sep 2013 14:06:24 +0000 From: Kelly Grizzle To: Steve Moyer Thread-Topic: Processing SCIM search/query filters Thread-Index: Ac61PpzE6zqQS5oiTlyGY9C/RJSZgDOr1APIM6syixA= Date: Thu, 19 Sep 2013 14:06:23 +0000 Message-ID: <457af850ada649a09553d13af4092468@BN1PR04MB392.namprd04.prod.outlook.com> References: <216716137.10807335.1379531981595.JavaMail.zimbra@psu.edu> <1726944172.10889466.1379534512141.JavaMail.zimbra@psu.edu> <06ff6ca5422a4c158a09777fe0b00d7f@BN1PR04MB392.namprd04.prod.outlook.com> <2141938191.11660927.1379599266640.JavaMail.zimbra@psu.edu> In-Reply-To: <2141938191.11660927.1379599266640.JavaMail.zimbra@psu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0F6381020054700F63824F x-originating-ip: [72.182.10.254] x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(164054003)(13464003)(52604005)(377454003)(51444003)(76576001)(81342001)(76482001)(54316002)(47736001)(19580395003)(76786001)(83322001)(59766001)(76796001)(15975445006)(47446002)(74502001)(74662001)(81542001)(66066001)(69226001)(33646001)(77982001)(4396001)(81686001)(79102001)(15202345003)(80976001)(19580405001)(65816001)(53806001)(47976001)(51856001)(74366001)(74706001)(46102001)(74876001)(74316001)(54356001)(56816003)(77096001)(81816001)(80022001)(50986001)(63696002)(56776001)(83072001)(31966008)(49866001)(24736002)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:72.182.10.254; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] Processing SCIM search/query filters X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 14:06:38 -0000 WWVzIC0gSSB0aGluayB0aGF0IGNvbnZlcnRpbmcgbGVzcy10aGFuIHRvIGEgbm90LWdyZWF0ZXIt dGhhbi1vci1lcXVhbC10byBpcyB0aGUgdXN1YWwgd2F5IHRvIHNvbHZlIHRoaXMgbGltaXRhdGlv biBpbiBMREFQLg0KDQpGcm9tIHlvdXIgcHJldmlvdXMgZW1haWw6DQoNCj4gV291bGQgdGhlIGdy b3VwIGJlIGludGVyZXN0ZWQgaW4gYSBzaW1wbGUgd2ViIHBhZ2UgdGhhdCBhbGxvd2VkIGEgZmls dGVyIHN0cmluZyB0byBiZSBlbnRlcmVkLCBzaG93ZWQgd2hldGhlciBpdCB3YXMgdmFsaWQNCj4g b3IgaW52YWxpZCwgd2hhdCB0b2tlbnMgdGhlIGxleGVyIGZvdW5kIGFuZCB0aGUgZXhwcmVzc2lv biB0cmVlIGdlbmVyYXRlZCBieSB0aGUgcGFyc2VyLiAgSSBjb3VsZCBhbHNvIHNob3cgZXhhbXBs ZXMgb2YNCj4gaG93IHRoZSBleHByZXNzaW9uIHRyZWUgd291bGQgYmUgdHJhbnNsYXRlZCBpbnRv IGFuIExEQVAgZmlsdGVyIGFuZCBTUUwgd2hlcmUgY2xhdXNlLiAgU2luY2UgdGhlIG1hcHBpbmcg b2YgU0NJTSBhdHRyaWJ1dGVzDQo+IHRvIGRhdGFiYXNlIGNvbHVtbnMgb3IgTERBUCBhdHRyaWJ1 dGVzIHdvdWxkIHZhcnksIHRoaXMgd291bGQgb25seSBiZSBmb3IgZWR1Y2F0aW9uYWwgcHVycG9z ZXMuDQoNClllcyAtIHRoaXMgd291bGQgYmUgdmFsdWFibGUuICBQZXJoYXBzIHdlIGNvdWxkIGV2 ZW4gYWRkIGl0IGFzIGFub3RoZXIgbGluayBvZmYgb2YgdGhlIGNvbXBsaWFuY2UgdGVzdHMgLSBo dHRwOi8vd3d3LnNpbXBsZWNsb3VkLmluZm8vI2NvbXBsaWFuY2VUZXN0Lg0KDQotLUtlbGx5DQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGV2ZSBNb3llciBbbWFpbHRvOnNt b3llckBwc3UuZWR1XSANClNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTksIDIwMTMgOTowMSBB TQ0KVG86IEtlbGx5IEdyaXp6bGUNCkNjOiBzY2ltQGlldGYub3JnDQpTdWJqZWN0OiBSZTogUHJv Y2Vzc2luZyBTQ0lNIHNlYXJjaC9xdWVyeSBmaWx0ZXJzDQoNClRoYW5rcyBmb3IgY2hlY2tpbmcg b3VyIHdvcmsuICBXZSdyZSBmb2xsb3dpbmcgdGhlIG9uLWdvaW5nIGRpc2N1c3Npb24gb24gZmls dGVyIG5lZ2F0aW9uLCBidXQgY29uc2lkZXJlZCB0aGUgTk9UIG9wZXJhdG9yIHRvIGJlIGEgbG9n aWNhbCBvcGVyYXRvciByYXRoZXIgdGhhbiBhIGdyb3VwaW5nIG9wZXJhdG9yIGluIG91ciBmaXJz dCBpbXBsZW1lbnRhdGlvbi4gIEl0J3MganVzdCBhYm91dCBmaXhlZCBub3csIGFuZCBJJ2xsIHBv c3QgdGhlIHJlc3VsdHMgdG8gdGhhdCB0aHJlYWQuICBTaW5jZSB3ZSd2ZSB0YWlsb3JlZCB0aGUg ZmlsdGVyIG5lZ2F0aW9uIGFyb3VuZCB0aGUgYWJpbGl0eSB0byBjcmVhdGUgTERBUCBmaWx0ZXJz LCBJJ20gd29uZGVyaW5nIGlmIHdlJ3JlIGdvaW5nIHRvIGhhdmUgcHJvYmxlbXMgd2l0aCBMVCBh bmQgR1Qgc2luY2UgdGhvc2Ugb3BlcmF0b3JzIGRvbid0IGV4aXN0IGluIHRoZSBMREFQIHN5bnRh eC4gIFRoZSBhbHRlcm5hdGl2ZSBpcyB1c2luZyBuZWdhdGlvbiB0aGVyZSB0b286DQoNCmEgPCBi IC0tLS0+ICEoYSA+PSBiKQ0KYSA+IGIgLS0tLT4gIShhIDw9IGIpDQoNClN0ZXZlDQoNCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJLZWxseSBHcml6emxlIiA8a2VsbHkuZ3Jp enpsZUBzYWlscG9pbnQuY29tPg0KVG86ICJTdGV2ZW4gVy4gTW95ZXIiIDxzbW95ZXJAcHN1LmVk dT4sIHNjaW1AaWV0Zi5vcmcNClNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTksIDIwMTMgOTo0 NjoxNiBBTQ0KU3ViamVjdDogUkU6IFByb2Nlc3NpbmcgU0NJTSBzZWFyY2gvcXVlcnkgZmlsdGVy cw0KDQpUaGFua3MgU3RldmVuIC4uLiB0aGlzIGlzIGdyZWF0ISAgVGhlIG91dHB1dCBiZWxvdyBh bGwgbG9va3MgY29ycmVjdCB0byBtZS4NCg0KSSBoYXZlIGJlZW4gYXNrZWQgYnkgYSBudW1iZXIg b2YgcGVvcGxlIGFib3V0IFNDSU0gbGlicmFyaWVzIC0gc3BlY2lmaWNhbGx5IGFyb3VuZCBmaWx0 ZXIgcHJvY2Vzc2luZyAtIHNvIEkga25vdyB0aGF0IHRoZXJlIHdpbGwgYmUgaW50ZXJlc3QgaW4g dGhpcy4NCg0KLS1LZWxseQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2Np bS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgU3RldmVuIFcuIE1veWVyDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxOCwgMjAx MyAzOjAyIFBNDQpUbzogc2NpbUBpZXRmLm9yZw0KU3ViamVjdDogW3NjaW1dIFByb2Nlc3Npbmcg U0NJTSBzZWFyY2gvcXVlcnkgZmlsdGVycw0KDQpXZSd2ZSBjcmVhdGVkIGEgbGV4ZXIgYW5kIHBy ZWRpY3RpdmUgcGFyc2VyIChhIHJlY3Vyc2l2ZSBkZXNjZW50IHBhcnNlciBmb3IgTEwgZ3JhbW1h cnMpIHRoYXQgd2UgYmVsaWV2ZSB3aWxsIHByb3Blcmx5IGNvbnZlcnQgYSBmaWx0ZXIgc3RyaW5n IGludG8gYW4gZXhwcmVzc2lvbiBoaWVyYXJjaHkuICBUaGUgb25seSBpc3N1ZSB3aXRoIHRoaXMg cGFyc2VyIGlzIHRoYXQgdGhlIHByZWNlZGVuY2Ugb2YgQU5EIG92ZXIgT1IgbWVhbnMgdGhhdCB0 aGUgU0NJTSBmaWx0ZXIgZ3JhbW1hciBpcyBub3Qgc3RyaWN0bHkgTEwsIHNvIHRoaXMgbGV4ZXIv cGFyc2VyIHdpbGwgY3VycmVudGx5IHByb2R1Y2UgZXJyb3JzIGZvciBzdW0tb2YtcHJvZHVjdCB0 eXBlIGZpbHRlcnMgd2hlbiB0aGUgQU5EIGNsYXVzZXMgYXJlIG5vdCBncm91cGVkIGluIHBhcmVu dGhlc2lzIChzbyB0aGUgZ3JhbW1hciBpcyBwYXJzZWQgaW50byBncm91cHMgcmVjdXJzaXZlbHkg YnV0IG90aGVyd2lzZSBwcm9jZWVkcyBsZWZ0LXRvLXJpZ2h0KS4NCg0KQ3VycmVudGx5LCBvdXIg cmVxdWlyZW1lbnRzIGRvbid0IGluY2x1ZGUgT1IgY2xhdXNlcywgYnV0IHdlIGRvIGludGVuZCB0 byBtYWtlIHRoZSBwYXJzZXIgY29tcGxpYW50IHdpdGggdGhlIFNDSU0gc3BlY2lmaWNhdGlvbnMg KHByb2JhYmx5IGJ5IGFkZGluZyBhIHByZXByb2Nlc3NvciB0aGF0IGluc2VydHMgZ3JvdXBpbmcg b3BlcmF0b3JzIGFyb3VuZCBhbmQgY2xhdXNlcykuICBJbiB0aGUgbWVhbi10aW1lLCB3ZSB0aG91 Z2h0IHdlJ2QgcG9zdCBhIHNhbXBsZSBvZiBpbnB1dC9vdXRwdXQgaGVyZSBmb3IgY29tbWVudHMg YW5kIGFkdmljZS4gIFdlJ2QgYmUgaGFwcHkgdG8gYWRkIGZpbHRlcnMgdG8gdGhlIHRlc3QgY2Fz ZXMgYW5kIHdvdWxkIGFwcHJlY2lhdGUgdmVyaWZpY2F0aW9uIG9mIHRoZSBvcGVyYXRpb24gd2Un dmUgc2hvd24gYmVsb3cuDQoNCkl0J3MgYWxzbyBvdXIgaW50ZW50aW9uIHRvIHNoYXJlIHRoZSBK YXZhIGNvZGUgZm9yIHRoaXMgcHJvamVjdCBhcyB3ZWxsIGFzIHRoZSAoY3VycmVudGx5KSBtaW5p bWFsIHRlc3Qgc3VpdGUuICBJZiBhbnlvbmUgaXMgaW50ZXJlc3RlZCwgd2UnbGwgbWFrZSB0aGUg cmVwb3NpdG9yeSBwdWJsaWMgc29vbmVyIHJhdGhlciB0aGFuIGxhdGVyLg0KDQpUaGFua3MsDQoN ClN0ZXZlIE1veWVyDQoNClAuUy4gIEluIHRoZSBvdXRwdXQgYmVsb3csIHRoZSBpbnB1dCBmaWx0 ZXIgc3RyaW5nIGlzIHByaW50ZWQsIGZvbGxvd2VkIGJ5IHRoZSB0cmVlIHRoZSBwYXJzZXIgY3Jl YXRlZC4NCg0KPT09PT0gU05JUCA9PT09PQ0KDQpbbWFpbl0gSU5GTyBvcmcuYXBhY2hlLmRpcmVj dG9yeS5zY2ltLnNlYXJjaC5sZXhlcnBhcnNlci5GaWx0ZXJQYXJzZXIgLSBGaWx0ZXIgc3RyaW5n OiB1c2VyTmFtZSBlcSAiYmplbnNlbiINClttYWluXSBJTkZPIG9yZy5hcGFjaGUuZGlyZWN0b3J5 LnNjaW0uc2VhcmNoLmxleGVycGFyc2VyLkZpbHRlclBhcnNlciAtIEZpbHRlciBleHByZXNzaW9u Og0KRVENCnwNCistLS11c2VyTmFtZQ0KKy0tLWJqZW5zZW4NCg0KDQpbbWFpbl0gSU5GTyBvcmcu YXBhY2hlLmRpcmVjdG9yeS5zY2ltLnNlYXJjaC5sZXhlcnBhcnNlci5GaWx0ZXJQYXJzZXIgLSBG aWx0ZXIgc3RyaW5nOiBuYW1lLmZhbWlseU5hbWUgY28gIk8nTWFsbGV5Ig0KW21haW5dIElORk8g b3JnLmFwYWNoZS5kaXJlY3Rvcnkuc2NpbS5zZWFyY2gubGV4ZXJwYXJzZXIuRmlsdGVyUGFyc2Vy IC0gRmlsdGVyIGV4cHJlc3Npb246DQpDTw0KfA0KKy0tLW5hbWUuZmFtaWx5TmFtZQ0KKy0tLU8n TWFsbGV5DQoNCg0KW21haW5dIElORk8gb3JnLmFwYWNoZS5kaXJlY3Rvcnkuc2NpbS5zZWFyY2gu bGV4ZXJwYXJzZXIuRmlsdGVyUGFyc2VyIC0gRmlsdGVyIHN0cmluZzogdXNlck5hbWUgc3cgIkoi DQpbbWFpbl0gSU5GTyBvcmcuYXBhY2hlLmRpcmVjdG9yeS5zY2ltLnNlYXJjaC5sZXhlcnBhcnNl ci5GaWx0ZXJQYXJzZXIgLSBGaWx0ZXIgZXhwcmVzc2lvbjoNClNXDQp8DQorLS0tdXNlck5hbWUN CistLS1KDQoNCg0KW21haW5dIElORk8gb3JnLmFwYWNoZS5kaXJlY3Rvcnkuc2NpbS5zZWFyY2gu bGV4ZXJwYXJzZXIuRmlsdGVyUGFyc2VyIC0gRmlsdGVyIHN0cmluZzogdGl0bGUgcHIgW21haW5d IElORk8gb3JnLmFwYWNoZS5kaXJlY3Rvcnkuc2NpbS5zZWFyY2gubGV4ZXJwYXJzZXIuRmlsdGVy UGFyc2VyIC0gRmlsdGVyIGV4cHJlc3Npb246DQpQUg0KfA0KKy0tLXRpdGxlDQorLS0tbnVsbA0K DQoNClttYWluXSBJTkZPIG9yZy5hcGFjaGUuZGlyZWN0b3J5LnNjaW0uc2VhcmNoLmxleGVycGFy c2VyLkZpbHRlclBhcnNlciAtIEZpbHRlciBzdHJpbmc6IG1ldGEubGFzdE1vZGlmaWVkIGd0ICIy MDExLTA1LTEzVDA0OjQyOjM0WiINClttYWluXSBJTkZPIG9yZy5hcGFjaGUuZGlyZWN0b3J5LnNj aW0uc2VhcmNoLmxleGVycGFyc2VyLkZpbHRlclBhcnNlciAtIEZpbHRlciBleHByZXNzaW9uOg0K R1QNCnwNCistLS1tZXRhLmxhc3RNb2RpZmllZA0KKy0tLTIwMTEtMDUtMTNUMDQ6NDI6MzRaDQoN Cg0KW21haW5dIElORk8gb3JnLmFwYWNoZS5kaXJlY3Rvcnkuc2NpbS5zZWFyY2gubGV4ZXJwYXJz ZXIuRmlsdGVyUGFyc2VyIC0gRmlsdGVyIHN0cmluZzogbWV0YS5sYXN0TW9kaWZpZWQgZ2UgIjIw MTEtMDUtMTNUMDQ6NDI6MzRaIg0KW21haW5dIElORk8gb3JnLmFwYWNoZS5kaXJlY3Rvcnkuc2Np bS5zZWFyY2gubGV4ZXJwYXJzZXIuRmlsdGVyUGFyc2VyIC0gRmlsdGVyIGV4cHJlc3Npb246DQpH RQ0KfA0KKy0tLW1ldGEubGFzdE1vZGlmaWVkDQorLS0tMjAxMS0wNS0xM1QwNDo0MjozNFoNCg0K DQpbbWFpbl0gSU5GTyBvcmcuYXBhY2hlLmRpcmVjdG9yeS5zY2ltLnNlYXJjaC5sZXhlcnBhcnNl ci5GaWx0ZXJQYXJzZXIgLSBGaWx0ZXIgc3RyaW5nOiBtZXRhLmxhc3RNb2RpZmllZCBsdCAiMjAx MS0wNS0xM1QwNDo0MjozNFoiDQpbbWFpbl0gSU5GTyBvcmcuYXBhY2hlLmRpcmVjdG9yeS5zY2lt LnNlYXJjaC5sZXhlcnBhcnNlci5GaWx0ZXJQYXJzZXIgLSBGaWx0ZXIgZXhwcmVzc2lvbjoNCkxU DQp8DQorLS0tbWV0YS5sYXN0TW9kaWZpZWQNCistLS0yMDExLTA1LTEzVDA0OjQyOjM0Wg0KDQoN ClttYWluXSBJTkZPIG9yZy5hcGFjaGUuZGlyZWN0b3J5LnNjaW0uc2VhcmNoLmxleGVycGFyc2Vy LkZpbHRlclBhcnNlciAtIEZpbHRlciBzdHJpbmc6IG1ldGEubGFzdE1vZGlmaWVkIGxlICIyMDEx LTA1LTEzVDA0OjQyOjM0WiINClttYWluXSBJTkZPIG9yZy5hcGFjaGUuZGlyZWN0b3J5LnNjaW0u c2VhcmNoLmxleGVycGFyc2VyLkZpbHRlclBhcnNlciAtIEZpbHRlciBleHByZXNzaW9uOg0KTEUN CnwNCistLS1tZXRhLmxhc3RNb2RpZmllZA0KKy0tLTIwMTEtMDUtMTNUMDQ6NDI6MzRaDQoNCg0K W21haW5dIElORk8gb3JnLmFwYWNoZS5kaXJlY3Rvcnkuc2NpbS5zZWFyY2gubGV4ZXJwYXJzZXIu RmlsdGVyUGFyc2VyIC0gRmlsdGVyIHN0cmluZzogdGl0bGUgcHIgYW5kIHVzZXJUeXBlIGVxICJF bXBsb3llZSINClttYWluXSBJTkZPIG9yZy5hcGFjaGUuZGlyZWN0b3J5LnNjaW0uc2VhcmNoLmxl eGVycGFyc2VyLkZpbHRlclBhcnNlciAtIEZpbHRlciBleHByZXNzaW9uOg0KQU5EDQp8DQorLS0t UFINCnwgICB8DQp8ICAgKy0tLXRpdGxlDQp8ICAgKy0tLW51bGwNCnwgICANCistLS1FUQ0KICAg IHwNCiAgICArLS0tdXNlclR5cGUNCiAgICArLS0tRW1wbG95ZWUNCiAgICANCg0KDQpbbWFpbl0g SU5GTyBvcmcuYXBhY2hlLmRpcmVjdG9yeS5zY2ltLnNlYXJjaC5sZXhlcnBhcnNlci5GaWx0ZXJQ YXJzZXIgLSBGaWx0ZXIgc3RyaW5nOiB0aXRsZSBwciBvciB1c2VyVHlwZSBlcSAiSW50ZXJuIg0K W21haW5dIElORk8gb3JnLmFwYWNoZS5kaXJlY3Rvcnkuc2NpbS5zZWFyY2gubGV4ZXJwYXJzZXIu RmlsdGVyUGFyc2VyIC0gRmlsdGVyIGV4cHJlc3Npb246DQpPUg0KfA0KKy0tLVBSDQp8ICAgfA0K fCAgICstLS10aXRsZQ0KfCAgICstLS1udWxsDQp8ICAgDQorLS0tRVENCiAgICB8DQogICAgKy0t LXVzZXJUeXBlDQogICAgKy0tLUludGVybg0KICAgIA0KDQoNClttYWluXSBJTkZPIG9yZy5hcGFj aGUuZGlyZWN0b3J5LnNjaW0uc2VhcmNoLmxleGVycGFyc2VyLkZpbHRlclBhcnNlciAtIEZpbHRl ciBzdHJpbmc6IHVzZXJUeXBlIGVxICJFbXBsb3llZSIgYW5kIChlbWFpbHMgY28gImV4YW1wbGUu Y29tIiBvciBlbWFpbHMgY28gImV4YW1wbGUub3JnIikgW21haW5dIElORk8gb3JnLmFwYWNoZS5k aXJlY3Rvcnkuc2NpbS5zZWFyY2gubGV4ZXJwYXJzZXIuRmlsdGVyUGFyc2VyIC0gRmlsdGVyIGV4 cHJlc3Npb246DQpBTkQNCnwNCistLS1FUQ0KfCAgIHwNCnwgICArLS0tdXNlclR5cGUNCnwgICAr LS0tRW1wbG95ZWUNCnwgICANCistLS1PUg0KICAgIHwNCiAgICArLS0tQ08NCiAgICB8ICAgfA0K ICAgIHwgICArLS0tZW1haWxzDQogICAgfCAgICstLS1leGFtcGxlLmNvbQ0KICAgIHwgICANCiAg ICArLS0tQ08NCiAgICAgICAgfA0KICAgICAgICArLS0tZW1haWxzDQogICAgICAgICstLS1leGFt cGxlLm9yZw0KICAgICAgICANCiAgICANCg0KDQpbbWFpbl0gSU5GTyBvcmcuYXBhY2hlLmRpcmVj dG9yeS5zY2ltLnNlYXJjaC5sZXhlcnBhcnNlci5GaWx0ZXJQYXJzZXIgLSBGaWx0ZXIgc3RyaW5n OiAoZW1haWxzIGNvICJleGFtcGxlLmNvbSIgb3IgZW1haWxzIGNvICJleGFtcGxlLm9yZyIpIFtt YWluXSBJTkZPIG9yZy5hcGFjaGUuZGlyZWN0b3J5LnNjaW0uc2VhcmNoLmxleGVycGFyc2VyLkZp bHRlclBhcnNlciAtIEZpbHRlciBleHByZXNzaW9uOg0KT1INCnwNCistLS1DTw0KfCAgIHwNCnwg ICArLS0tZW1haWxzDQp8ICAgKy0tLWV4YW1wbGUuY29tDQp8ICAgDQorLS0tQ08NCiAgICB8DQog ICAgKy0tLWVtYWlscw0KICAgICstLS1leGFtcGxlLm9yZw0KICAgIA0KDQoNClttYWluXSBJTkZP IG9yZy5hcGFjaGUuZGlyZWN0b3J5LnNjaW0uc2VhcmNoLmxleGVycGFyc2VyLkZpbHRlclBhcnNl ciAtIEZpbHRlciBzdHJpbmc6IChlbWFpbHMgY28gImV4YW1wbGUuY29tIiBvciBlbWFpbHMgY28g ImV4YW1wbGUub3JnIikgYW5kIHVzZXJUeXBlIGVxICJFbXBsb3llZSINClttYWluXSBJTkZPIG9y Zy5hcGFjaGUuZGlyZWN0b3J5LnNjaW0uc2VhcmNoLmxleGVycGFyc2VyLkZpbHRlclBhcnNlciAt IEZpbHRlciBleHByZXNzaW9uOg0KQU5EDQp8DQorLS0tT1INCnwgICB8DQp8ICAgKy0tLUNPDQp8 ICAgfCAgIHwNCnwgICB8ICAgKy0tLWVtYWlscw0KfCAgIHwgICArLS0tZXhhbXBsZS5jb20NCnwg ICB8ICAgDQp8ICAgKy0tLUNPDQp8ICAgICAgIHwNCnwgICAgICAgKy0tLWVtYWlscw0KfCAgICAg ICArLS0tZXhhbXBsZS5vcmcNCnwgICAgICAgDQp8ICAgDQorLS0tRVENCiAgICB8DQogICAgKy0t LXVzZXJUeXBlDQogICAgKy0tLUVtcGxveWVlDQogICAgDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzY2ltIG1haWxpbmcgbGlzdA0Kc2NpbUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQo= From bjorn.aannestad@unboundid.com Thu Sep 19 08:17:27 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F5B21F991F for ; Thu, 19 Sep 2013 08:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43uR5k-Awl2K for ; Thu, 19 Sep 2013 08:17:23 -0700 (PDT) Received: from mail-ye0-f182.google.com (mail-ye0-f182.google.com [209.85.213.182]) by ietfa.amsl.com (Postfix) with ESMTP id 540B921F9611 for ; Thu, 19 Sep 2013 08:17:23 -0700 (PDT) Received: by mail-ye0-f182.google.com with SMTP id l10so3428750yen.13 for ; Thu, 19 Sep 2013 08:17:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7VuLt0UPHGAzOOTD5GI6GcSeyZLKKD/KkBt8/MLjzV4=; b=h5SnuvwNhgL6NZa9VAWJANoHOKswxJAoMz3rhQc8mPu1H4zzfxjoVjju4qa1xqPmS4 SGIPF++z3oxvkWu4savrfcuGmuORXUCk2xAgWFqyz75LHR4WMFm1ZdoMNok69xDvIXu7 mifKCOI9F1s/5xmNLUYlAZBdGson9y56p001m0KEgixeH0qlwv8C8qgRsa8WlzhH/IFI Z8S6Ma1wpD8SVQ3WLP8xMVwdrvgZZaTI59w/eNvucgs37EV8sOSIj30kojtcYJwEQjAf itZJpwkYGF04MFnf5qxu77S2lDv5XO1Je0fR6rZjDhuBiH+fquj+5V6N23TU8ZEvcsDb /4PQ== X-Gm-Message-State: ALoCoQkOBg53eZEEcrisEWmqKJk5+Jw8cRdT37OPzKbMcOqI4u6gq1UD9LvT8KpclkBjidhEB0/m X-Received: by 10.236.45.102 with SMTP id o66mr1581835yhb.13.1379603834688; Thu, 19 Sep 2013 08:17:14 -0700 (PDT) Received: from [10.8.1.116] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPSA id s20sm11437082yhi.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 08:17:14 -0700 (PDT) Message-ID: <523B1576.8060806@unboundid.com> Date: Thu, 19 Sep 2013 10:17:10 -0500 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: scim@ietf.org References: <2011087747.11209022.1379553591708.JavaMail.zimbra@psu.edu> <04875CCE-090D-402B-B6A0-EB072E8375DE@oracle.com> <922992321.11326038.1379580395022.JavaMail.zimbra@psu.edu> <550224196.11339745.1379583562544.JavaMail.zimbra@psu.edu> In-Reply-To: <550224196.11339745.1379583562544.JavaMail.zimbra@psu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] Filter negation X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 15:17:28 -0000 Steven, thank you for the in-depth discussion! This is a great exploration of the rationale. Couple of points: a) In your earlier note, you're right that I was intending "not(" or "not (" to be the token, just like "(" is the grouping token. b) I also couldn't discover a case where the precedence of "not(" vs "(" was important. If people agree, the text could say that those two have equal precedence. c) Although I used the word "INVALID" for examples with the logical-operator-not, it's more accurate to describe those forms as not being required to be supported. => userType not eq "Employee". A Service Provide _could_ support this, but it wouldn't be standard. d) If you do make an expression checker, consider linking it to simplecloud.info . Regards, -Bjorn On 2013-09-19 4:39 AM, Steven W. Moyer wrote: > If I'd considered my previous examples using an LDAP filter representation instead of SQL, I'd have seen the rationale for using NOT( as a grouping operator immediately: > > - not userType eq "Employee" ----> not usertype = 'Employee' | (!(userType=Employee)) > - userType not eq "Employee" ----> usertype <> 'Employee' | No inequality operator > - userType neq "Employee" ----> usertype <> 'Employee' | No inequality operator > > This also makes me wonder how the SCIM GT and LT operators would be translated ... would: > > filter=meta.lastModified gt "2011-05-13T04:42:34Z" ----> (!(modifiedTimestamp<=2011-05-13T04:42:34Z)) > > In any case, I'll rework our lexer to tokenize "NOT *(" (regex) as NOT( and alter the parser to create an expression up to the terminating ")". If someone could provide one or more examples where the precedence of ( and NOT( matters, I'll add them to our test cases. I'd like to build up a library of examples (in addition to the thirteen I pulled from the specification). > > Would the group be interested in a simple web page that allowed a filter string to be entered, showed whether it was valid or invalid, what tokens the lexer found and the expression tree generated by the parser. I could also show examples of how the expression tree would be translated into an LDAP filter and SQL where clause. Since the mapping of SCIM attributes to database columns or LDAP attributes would vary, this would only be for educational purposes. > > Steve > > ----- Original Message ----- > From: "Steven W. Moyer" > To: "Phil Hunt" > Cc: scim@ietf.org > Sent: Thursday, September 19, 2013 4:46:35 AM > Subject: Re: [scim] Filter negation > > I completely agree that the syntax you've shown should represent a valid filter, but I was more suggesting that using NOT as a negation operator for the expression that followed was more consistent. In that case, your example remains the same (I've added spaces where our lexer would tokenize it): > > NOT ( a EQ b AND c eq d ) > > Treating NOT as an operator would however change (shorten) some of the other uses: > > NOT ( userType EQ "Employee" ) > > would be equivalent to: > > NOT userType EQ "Employee" > > since the expression containing the EQ has a higher precedence anyway (I've again used spaces to indicate where our lexer is splitting tokens). > > Rereading issue #24 (http://trac.tools.ietf.org/wg/scim/trac/ticket/24), I'm realizing that perhaps my misunderstanding is thinking of the NOT token as a logical operator. As a grouping operator is the token really always "NOT("? Should the syntax support "NOT (" (with a space between the NOT and opening parenthesis)? In this case I understand why it's precedence is higher than the LogicalOperators and lower than the AttributeOperators, but when would the precedence of NOT( over ( come into play? The examples I've considered can all be resolved by matching those operators to their closing parenthesis. > > Steve > ----- Original Message ----- > From: "Phil Hunt" > To: "Steven W. Moyer" > Cc: scim@ietf.org > Sent: Wednesday, September 18, 2013 10:30:26 PM > Subject: Re: [scim] Filter negation > > I think not as a function is a requirement. We need to be able to say > NOT(a eq b AND c eq d) > > It is often easier to scale what something isn't than what it is. > > We need both grouping and not functions. > > The alternative means a much much longer filter. So any parsing performance is lost. > > IMHO parsing is the smallest part of performance cost by several orders of magnitude when compared to database connections and http connection handling ... which is pretty darn fast. Just sayin' > > Phil > >> On Sep 18, 2013, at 18:19, "Steven W. Moyer" wrote: >> >> Since we're defining "NOT" as an operator, I thought I'd perform a simple test of the proposed change. I simply added NOT to the LogicalOperator enum in our lexer/parser and ran the example filters provided by Bjorn Aannestad along with two variations to see what happened in the absence of parenthesis. I didn't however enforce a grouping requirement on the NOT operator and I didn't fix the "over-recursion" that occurred in the fifth case. >> >> In any case, after seeing the results and looking at parser complexity, I'd like to make some comments and suggestions: >> >> 1) Enforcing the parenthesis after the NOT token (processed as a token stream) requires either a look-ahead or carrying state in the parser (beyond what's provided by the head and/or tail recursion). I'd suggest we not require parenthesis unless you want the NOT operator to apply to the group following it. Otherwise, the NOT operator is in reality a function. >> >> 2) Enforcing the parenthesis after the NOT is in effect saying that the NOT operator is a higher precedence than both the AND and OR operators (only considering the logical operators). It makes sense for the logical operators to be a lower precedence than both the attribute operators and the grouping operators, but I'd suggest that it doesn't make sense to specify the precedence between the AND and OR operators in the API document and the precedence of the NOT in relation to the AND and OR operators using explicit grouping. I'd like to suggest that the consistency of the filter specification would be better with any of the following: >> >> - Declare that AND, NOT and OR have equal precedence and always process them left to right, forcing grouping operators for cases where that's not desired. >> >> - Explicitly state that NOT has a higher precedence than AND and OR understanding that this will require the parser to either preprocess these operators or to vary the extent of the left to right processing in the absence of grouping operators. >> >> - Abandon the NOT operator as a prefix and either use it as a modifier to an attribute operator or provide a set of negated operators (or both). >> >> 3) I think we can all agree that logically, these filters are the same: >> >> - not userType eq "Employee" >> - userType not eq "Employee" >> - userType neq "Employee" >> >> But these filters will (without heroics in the parser), result in different expressions as follows: >> >> - not userType eq "Employee" ----> not usertype = 'Employee' >> - userType not eq "Employee" ----> usertype <> 'Employee' >> - userType neq "Employee" ----> usertype <> 'Employee' >> >> So in the first case, where using an SQL logical operator to negate the result of an "=" comparison operator, but in the second and third cases, we're realizing that "not eq" and "neq" are synonyms. I think it would require an optimizer to make all three expressions evaluate to the same SQL fragment. And in fact, the third and fourth examples that Bjorn provided are an example of a complex equality that follows De Morgan's Law (1), yet the effort to optimize those expressions in one common variant wouldn't be worth the effort. >> >> I realize I'm relatively new here and I'll freely admit I haven't read much of the mailing list prior to April (assuming the 01 specification was current when that document came out), so please don't take this as criticism and feel free to ignore points that don't align with the group's interests. We'll create our implementation to comply with whatever the group decides. >> >> Thanks again for all the effort that you (collectively) have put into making something that I believe will be revolutionary. >> >> Steve Moyer >> >> ===== SNIP ===== >> >> [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not(userType eq "Employee") >> [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: >> NOT >> | >> +---EQ >> | >> +---userType >> +---Employee >> >> >> >> [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not userType eq "Employee" >> [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: >> NOT >> | >> +---EQ >> | >> +---userType >> +---Employee >> >> >> >> [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: userType eq "Employee" and not(emails co "example.com" or emails co "example.org") >> [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: >> AND >> | >> +---EQ >> | | >> | +---userType >> | +---Employee >> | >> +---NOT >> | >> +---OR >> | >> +---CO >> | | >> | +---emails >> | +---example.com >> | >> +---CO >> | >> +---emails >> +---example.org >> >> >> >> >> >> [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not(userType eq "Employee") and not(userType eq "Intern") >> [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: >> AND >> | >> +---NOT >> | | >> | +---EQ >> | | >> | +---userType >> | +---Employee >> | >> | >> +---NOT >> | >> +---EQ >> | >> +---userType >> +---Intern >> >> >> >> >> [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not userType eq "Employee" and not userType eq "Intern" >> [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: >> NOT >> | >> +---AND >> | >> +---EQ >> | | >> | +---userType >> | +---Employee >> | >> +---NOT >> | >> +---EQ >> | >> +---userType >> +---Intern >> >> >> >> >> >> [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter string: not(userType eq "Employee" or userType eq "Intern") >> [main] INFO org.apache.directory.scim.search.lexerparser.FilterParser - Filter expression: >> NOT >> | >> +---OR >> | >> +---EQ >> | | >> | +---userType >> | +---Employee >> | >> +---EQ >> | >> +---userType >> +---Intern >> >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Thu Sep 19 14:04:41 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A023921F85E3 for ; Thu, 19 Sep 2013 14:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMPXxcvJTJxy for ; Thu, 19 Sep 2013 14:04:32 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 42FFD21F85C3 for ; Thu, 19 Sep 2013 14:04:32 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8JL4VRB008767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 Sep 2013 21:04:31 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8JL4URF011637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Sep 2013 21:04:30 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8JL4TZS011492 for ; Thu, 19 Sep 2013 21:04:30 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Sep 2013 14:04:29 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <95B45515-AC52-4ED9-B21C-2FF586795890@oracle.com> Date: Thu, 19 Sep 2013 14:04:28 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [scim] Question on /schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 21:04:41 -0000 There seems to be an inconsistency between resourceType objects and = extensions and the attributes returned when querying /Schemas. Are = User and Group "special" or are they not extensions to Resource = themselves? For example, in section 12.7 of the scim schema draft 02 shows the = representation of the scim User schema. The example includes the "id" = attribute even though it's not really part of the scim User schema it is = part of the core Resource schema. Should it really be returned as part = of GET /Schemas/User request. Interesting that the example does NOT = include "externalId" and "meta" which are also part of the scim core = schema? I ask because the behaviour gets further unclear if someone creates an = extension to User. Should that extension include all the parent = attributes from User and Resource? My assumption is no. So I guess the question is, should the User example be amended to = remove, id, externalId, etc? Or should we somehow distinguish that = objects with a resourceType include core resource attributes? Phil @independentid www.independentid.com phil.hunt@oracle.com From moransar@cisco.com Thu Sep 19 22:21:53 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D816621F8495 for ; Thu, 19 Sep 2013 22:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeyn9LO3g2P2 for ; Thu, 19 Sep 2013 22:21:49 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFDD21F846E for ; Thu, 19 Sep 2013 22:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9095; q=dns/txt; s=iport; t=1379654508; x=1380864108; h=from:to:subject:date:message-id:mime-version; bh=IylfhTsGxm1ey/TglcvRS3qkvKaq3o7sOIoI3WFLzaU=; b=C6F/Ov5Mwr7My2v25fx9kUc8hllyeiMeO+WfNy6fvOMQUMLSh2zPHv/0 lQadkZrMSozlJUZrit98/O0O4wH+92OG8MW1UipSqtafYKzfWIBLmHyyI 6xfWV2UvXZp9iy1UAf/apGgdR5xWOo5qsq3O1aSykEFg4Q/VtCYEtejux 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAGPaO1KtJXG//2dsb2JhbABBGoJDRDhSwTSBIBZ0gicBBB5tASpWJwQBGod7DDa6CwSOKBB+LYMpgQADqXGDJIFoQg X-IronPort-AV: E=Sophos;i="4.90,941,1371081600"; d="scan'208,217";a="262203832" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 20 Sep 2013 05:21:47 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8K5LkBp010426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 05:21:46 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.27]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 00:21:46 -0500 From: "Morteza Ansari (moransar)" To: "ietf-secretaria@ietf.org" , "scim@ietf.org" Thread-Topic: Meeting notes from WG conical 2013-09-18 Thread-Index: AQHOtcFNRwUYtjOdBUys6ZWDtEbnuA== Date: Fri, 20 Sep 2013 05:21:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.21.98.171] Content-Type: multipart/alternative; boundary="_000_CA3B67220D628A4780D6FEB31F18A3E32ABEB94Cxmbrcdx08ciscoc_" MIME-Version: 1.0 Subject: [scim] Meeting notes from WG conical 2013-09-18 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 05:21:54 -0000 --_000_CA3B67220D628A4780D6FEB31F18A3E32ABEB94Cxmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to Sal for volunteering to take notes. Attendees: Morteza Ansari, Phil Hunt, Kelly Grizzle, Bjorn Aannestad, Barry= Leiba, Leif Johansson, Sal D'Agostino, Peter Gietz Assign responsible persons for issues based on issue tracker: #2 Kelly to provide text #9 Postponed #10 Phil to create separate item related to the thread on list #13 Eric to provide update on etags #24 Bjorn to provide language Morteza related to last IETF there are issued related to filter semantic for plural queries of complex attribute, "resource object not the value" #34 Hold for Kelly response #35 Hold for Kelly, comments on thread Text is incorrect, comments are valid, remove sentence vs. fixing piece, look at group member addressed in updated schema, added to ticket, Bjorn to take ticket #37 Extended discussion, OK to return http error How does a remote client find this out (other examples) akin to index error= s or bad filters, discovery upfront is different than detailed error message. Return "Error" only, vulnerabilities on the public internet a consideration If there is a desire for human understandable errors refer to security considerations and do what is appropriate. How does client figure it out, cannot guarantee interoperability if limited to rest error or http error codes All the protocol needs is unwilling to perform List query restriction Discovery holds no security risk LDAP versus X500 gives examples of good versus bad ways to do this, http restful codes sufficient, Concern comes from the need to have some clues, "Equal" # publisher and clients, need to be much more concerned given peer to peer nature of scim Discovery vs. detailed error message, later is a security consideration Attribute at server level vs. details are aspect of attribute. Remove searching entirely from the spec, make a provisioning only, otherwis= e it is a cloud directory, scim 1 with filters requires that Working group should look at issue of cloud directory and search extension Two issues: Error code More with discovery some related to error and some related to other things and what are the things that have a big impact on use case, complete set is slippery slope, start with making sure what is already in the spec #47 discovery of attribute indexing Being specific about discovery for clients, manageable if not about error messages Phil to look at 37 and 47 Phil to propose text Bad request mentioned on the list, LDAP laissez faire, sit on top of multiple datasets if one dataset throws an error, how do you handle it, it can be an ok result, admins can (want to) determine why, x500 to throw errors at first sign May still want to define bad request even to know what it isn't Don't use or seldom used codes, don't expect fully parsed error Filter needs to conform to scim syntax, filter comparison is valid due to server configuration, clients build in a lot of OR blocks for deployments, and this is breaking for some Show some error codes in context. Consider things like 501 and semantics Combine into a general error code ticket and merge into 47, defer to new issue, general error review, general review, or appendix with scim error codes table Meeting recording link: https://go.webex.com/go/lsr.php?AT=3Dpb&SP=3DMC&rID=3D6141242&rKey=3D6ee5ab= 19b38d45c3 SCIM WG bi-weekly call-20130918 1808-1 Wednesday, September 18, 2013 11:08 am San Francisco Time 52 Minutes --_000_CA3B67220D628A4780D6FEB31F18A3E32ABEB94Cxmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <3861F722E5061341B06ECB49B80AAB7E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks to Sal for volunteering to take notes.

Attendees: Morteza Ansari, Phil Hunt, Kelly Grizzle, Bjorn Aannestad, = Barry Leiba, Leif Johansson, Sal D'Agostino, Peter Gietz

Assign responsible persons for issues  based on issue tracke= r:

#2 Kelly to provide text

#9 Postponed

#10 Phil to create separate item related to the thread on list

#13 Eric to provide update on etags

#24 Bjorn to provide language
Morteza  related to last IETF there are issued related to fi= lter semantic
for plural queries of complex attribute, "resource object not the= value"

#34 Hold for Kelly response

#35 Hold for Kelly, comments on thread
Text is incorrect, comments are valid, remove sentence vs. fixing piec= e,
look at group member addressed in updated schema,  added to = ticket,  Bjorn
to take ticket

#37  Extended discussion,
OK to return http error
How does a remote client find this out (other examples) akin to index = errors
or bad filters, discovery upfront is different than detailed error mes= sage.
Return "Error" only, vulnerabilities on the public internet = a consideration
If there is a desire for human understandable errors refer to security=
considerations and do what is appropriate.
How does client figure it out, cannot guarantee interoperability if li= mited
to  rest error or http error codes
All the protocol needs is unwilling to perform
List query restriction
Discovery holds no security risk
LDAP  versus X500 gives examples of good versus bad ways to = do this,
http restful codes sufficient,
Concern comes from the need to have some clues,
"Equal" # publisher and clients, need to be much more concer= ned given peer
to peer nature of scim
Discovery vs. detailed error message, later is a security consideratio= n
Attribute at server level vs. details are aspect of attribute. &n= bsp;
Remove searching entirely from the spec, make a provisioning only, oth= erwise
it is a cloud directory, scim 1 with filters requires that
Working group should look at issue of cloud directory and search exten= sion
Two issues:
Error code
More with discovery some related to error and some related to other th= ings
and what are the things that have a big impact on use case, complete s= et is
slippery slope, start with making sure what is already in the spec
#47 discovery of attribute indexing
Being specific about discovery for clients, manageable if not about er= ror
messages
Phil to look at 37 and 47 Phil to propose text
Bad request mentioned on the list, LDAP laissez faire, sit on top of
multiple datasets if one dataset throws an error, how do you handle it= , it
can be an ok result, admins can (want to) determine why, x500 to throw=
errors at first sign
May still want to define bad request even to know what it isn't
Don't use or seldom used codes, don't expect fully parsed error
Filter needs to conform to scim syntax, filter comparison is valid due= to
server configuration, clients build in a lot of OR blocks for deployme= nts,
and this is breaking for some
Show some error codes in context.
Consider things like 501 and semantics
Combine into a general error code ticket and merge into 47, defer to n= ew
issue, general error review, general review, or appendix with scim err= or
codes table

Meeting recording link:

https://go.webex.= com/go/lsr.php?AT=3Dpb&SP=3DMC&rID=3D6141242&rKey=3D6ee5ab19b38= d45c3 

SCIM WG bi-weekly call-20130918 1808-1 
Wednesday, September 18, 2013 11:08 am San Francisco Time 
52 Minutes 
--_000_CA3B67220D628A4780D6FEB31F18A3E32ABEB94Cxmbrcdx08ciscoc_-- From moransar@cisco.com Thu Sep 19 22:28:45 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D584F21F84EA for ; Thu, 19 Sep 2013 22:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.298 X-Spam-Level: X-Spam-Status: No, score=-9.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCWOrarUTrKQ for ; Thu, 19 Sep 2013 22:28:40 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5D54F21F8517 for ; Thu, 19 Sep 2013 22:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2113; q=dns/txt; s=iport; t=1379654919; x=1380864519; h=from:to:subject:date:message-id:mime-version; bh=T9v4Eh3weF9Yxn0/bQb789KCcEYPAFcrmx3E1rL2oJc=; b=fYOaLq7YTWXqMcRkIGSxiKMpKyWAoXYKa4TKQebhmiY2XARdNHtwI6Ye B3IDsQ5ZVBdv/XducZJ47eSPPVgsiCsjkYC3/oJ0P2QXoOp4q1cypcHfs rU5bGRKhKRb+t92ch3tGU15d0nn/Wk8amqwZ9lS3vQ1w1PKfurLKHpMRd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFAI3cO1KtJXG+/2dsb2JhbABbgkNEgQrBNIEgFm0HghwLAQRoBh0BCwEeVicEG4d7mROhP482g1aBAAOpcYMkgio X-IronPort-AV: E=Sophos;i="4.90,941,1371081600"; d="scan'208,217";a="262240524" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 20 Sep 2013 05:28:38 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8K5SbeI000342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 20 Sep 2013 05:28:37 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.27]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 00:28:37 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: Next SCIM WG call agenda - Oct. 2nd @11AM Pacific Thread-Index: AQHOtcJBVwNVWbwwdEKAfWlGnHRyAA== Date: Fri, 20 Sep 2013 05:28:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.21.98.171] Content-Type: multipart/alternative; boundary="_000_CA3B67220D628A4780D6FEB31F18A3E32ABEB98Fxmbrcdx08ciscoc_" MIME-Version: 1.0 Subject: [scim] Next SCIM WG call agenda - Oct. 2nd @11AM Pacific X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 05:28:45 -0000 --_000_CA3B67220D628A4780D6FEB31F18A3E32ABEB98Fxmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, Just a reminder that the next SCIM WG call is scheduled for Oct. 2nd at 11A= M Pacific time. The agenda for that meeting is to continue going through t= he backlog of the issues from tracker. Currently up to issue #39. And a further reminder on behalf of Barry, that we should be addressing the= se issues on the mailing list, and using the conference calls to address po= ints that haven't gotten resolution on the list. *Please* work on resolvin= g the issues on the list first, and make the most of the high-bandwidth con= ference-call time. Cheers, Morteza --_000_CA3B67220D628A4780D6FEB31F18A3E32ABEB98Fxmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <4DDDB6F62AF0724DA4BEBB4C397030E2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi folks,

Just a reminder that the next SCIM WG call is scheduled for Oct. 2nd a= t 11AM Pacific time.  The agenda for that meeting is to continue going= through the backlog of the issues from tracker. Currently up to issue #39.=

And a further reminder on behalf of Barr= y, that we should be addressing these issues on the mailing list, and = using the conference calls to address points that haven't gotten resol= ution on the list.  *Please* work on resolving the issues on the list first, and make the most of the high-bandwidth= conference-call time.


Cheers,
Morteza
--_000_CA3B67220D628A4780D6FEB31F18A3E32ABEB98Fxmbrcdx08ciscoc_-- From ayyagarikiran@gmail.com Sun Sep 22 05:34:10 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E1D21F9FD7 for ; Sun, 22 Sep 2013 05:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.437 X-Spam-Level: X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jziHD19iRJoi for ; Sun, 22 Sep 2013 05:34:09 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0876A21F9FD6 for ; Sun, 22 Sep 2013 05:34:08 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id q59so2076274wes.41 for ; Sun, 22 Sep 2013 05:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=xAonEoRQxJROoERpfuzYJtxbiSQ5z5TWnCYfZlAN1Vs=; b=ncAxQrqA14Fp00nj0Df2APxueSAWjA2ZJJhite486bXWByBSpBcB9yGkJ6H3Y3nKKC 6XM0RhbbKp/ENT4xdpfItzEZ93+1bG59MeOLSZqHBhFBwC+kOW2WyQ7Z85Pm3FA6S3wA cVgaCA5QaXImOUYeazxABqyet9NmCwsBftm+lGpzMxns4fuFV2W5UDBBrVzpJywQhu9k 76lFSeyViqYK+jc/td6hlBmXIv46P2buqOIDyRmOqBYZv+Sp/0UwzfFCMBKxGAaW2s80 UdLX+ELLzjBhr2C13FB8vs0EjRdx/7qml689ErY+BvehAX6Dw1V87TKS1f0yI4kTtQnS msZg== MIME-Version: 1.0 X-Received: by 10.180.107.167 with SMTP id hd7mr9557624wib.13.1379853247959; Sun, 22 Sep 2013 05:34:07 -0700 (PDT) Sender: ayyagarikiran@gmail.com Received: by 10.216.245.200 with HTTP; Sun, 22 Sep 2013 05:34:07 -0700 (PDT) Date: Sun, 22 Sep 2013 18:04:07 +0530 X-Google-Sender-Auth: GlUQzNd3YZ8udHOma2bfcTDUa0g Message-ID: From: Kiran Ayyagari To: scim@ietf.org Content-Type: multipart/mixed; boundary=e89a8f2353a7aff40604e6f81efc Subject: [scim] [SCIM] schema files in JSON format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 12:35:48 -0000 --e89a8f2353a7aff40604e6f81efc Content-Type: multipart/alternative; boundary=e89a8f2353a7aff40104e6f81efa --e89a8f2353a7aff40104e6f81efa Content-Type: text/plain; charset=ISO-8859-1 I was trying to create schema files for each resource type and found that the normative example(section 12.7) of core User schema omits several attributes. I am not sure if this was done intentionally. I am attaching the schema files for User, Entrerprise user and Group resources. It would be great if they can be made available under the resources section of SCIM website. Finally, should the 'employeeNumber' attribute of Enterprise user be made a REQUIRED attribute? -- Kiran Ayyagari http://keydap.com --e89a8f2353a7aff40104e6f81efa Content-Type: text/html; charset=ISO-8859-1
I was trying to create schema files for each resource type and found
that the normative example(section 12.7) of core User schema omits
several attributes. I am not sure if this was done intentionally.

I am attaching the schema files for User, Entrerprise user and Group resources.
It would be great if they can be made available under the resources section of
SCIM website.

Finally, should the 'employeeNumber' attribute of Enterprise user be made
a REQUIRED attribute?


--
Kiran Ayyagari
http://keydap.com
--e89a8f2353a7aff40104e6f81efa-- --e89a8f2353a7aff40604e6f81efc Content-Type: application/json; name="enterprise-user-schema.json" Content-Disposition: attachment; filename="enterprise-user-schema.json" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hlw8xu880 ewogICAgICJpZCI6ICJ1cm46c2NpbTpzY2hlbWFzOmV4dGVuc2lvbjplbnRlcnByaXNlOjIuMDpV c2VyIiwKICAgICAibmFtZSI6ICJFbnRlcnByaXNlVXNlciIsCiAgICAgImRlc2NyaXB0aW9uIjog IkVudGVycHJpc2UgVXNlciIsCiAgICAgImF0dHJpYnV0ZXMiOlsKICAgICAgIHsKICAgICAgICAg Im5hbWUiOiJlbXBsb3llZU51bWJlciIsCiAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAg ICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAgImRlc2NyaXB0aW9uIjoiTnVtZXJpYyBv ciBhbHBoYW51bWVyaWMgaWRlbnRpZmllciBhc3NpZ25lZCB0byBhIHBlcnNvbiwgdHlwaWNhbGx5 IGJhc2VkIG9uIG9yZGVyIG9mIGhpcmUgb3IgYXNzb2NpYXRpb24gd2l0aCBhbiBvcmdhbml6YXRp b24uIiwKICAgICAgICAgInJlYWRPbmx5IjpmYWxzZSwKICAgICAgICAgInJlcXVpcmVkIjpmYWxz ZSwKICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAg ICJuYW1lIjoiY29zdENlbnRlciIsCiAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAg Im11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAgImRlc2NyaXB0aW9uIjoiSWRlbnRpZmllcyB0 aGUgbmFtZSBvZiBhIGNvc3QgY2VudGVyLiIsCiAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAg ICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAg ICB9LAogICAgICAgewogICAgICAgICAibmFtZSI6Im9yZ2FuaXphdGlvbiIsCiAgICAgICAgICJ0 eXBlIjoic3RyaW5nIiwKICAgICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAgImRl c2NyaXB0aW9uIjoiSWRlbnRpZmllcyB0aGUgbmFtZSBvZiBhbiBvcmdhbml6YXRpb24uIiwKICAg ICAgICAgInJlYWRPbmx5IjpmYWxzZSwKICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAg ICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lIjoi ZGl2aXNpb24iLAogICAgICAgICAidHlwZSI6InN0cmluZyIsCiAgICAgICAgICJtdWx0aVZhbHVl ZCI6ZmFsc2UsCiAgICAgICAgICJkZXNjcmlwdGlvbiI6IklkZW50aWZpZXMgdGhlIG5hbWUgb2Yg YSBkaXZpc2lvbi4iLAogICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAicmVxdWly ZWQiOmZhbHNlLAogICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZQogICAgICAgfSwKICAgICAgIHsK ICAgICAgICAgIm5hbWUiOiJkZXBhcnRtZW50IiwKICAgICAgICAgInR5cGUiOiJzdHJpbmciLAog ICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAiZGVzY3JpcHRpb24iOiJJZGVu dGlmaWVzIHRoZSBuYW1lIG9mIGEgZGVwYXJ0bWVudC4iLAogICAgICAgICAicmVhZE9ubHkiOmZh bHNlLAogICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAiY2FzZUV4YWN0IjpmYWxz ZQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWUiOiJtYW5hZ2VyIiwKICAgICAgICAg InR5cGUiOiJjb21wbGV4IiwKICAgICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAg ImRlc2NyaXB0aW9uIjoiVGhlIFVzZXIncyBtYW5hZ2VyLiBBIGNvbXBsZXggdHlwZSB0aGF0IG9w dGlvbmFsbHkgYWxsb3dzIFNlcnZpY2UgUHJvdmlkZXJzIHRvIHJlcHJlc2VudCBvcmdhbml6YXRp b25hbCBoaWVyYXJjaHkgYnkgcmVmZXJlbmNpbmcgdGhlIFwiaWRcIiBhdHRyaWJ1dGUgb2YgYW5v dGhlciBVc2VyLiIsCiAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICJyZXF1aXJl ZCI6ZmFsc2UsCiAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlLAogICAgICAgICAic3ViQXR0cmli dXRlcyI6WwogICAgICAgICAgIHsKICAgICAgICAgICAgICJuYW1lIjoibWFuYWdlcklkIiwKICAg ICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFs c2UsCiAgICAgICAgICAgICAiZGVzY3JpcHRpb24iOiJUaGUgaWQgb2YgdGhlIFNDSU0gcmVzb3Vy Y2UgcmVwcmVzZW50aW5nIHRoZSBVc2VyJ3MgIG1hbmFnZXIuICBSRVFVSVJFRC4iICwKICAgICAg ICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAog ICAgICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICAgICB9LAogICAgICAgICAgIHsK ICAgICAgICAgICAgICJuYW1lIjoiJHJlZiIsCiAgICAgICAgICAgICAidHlwZSI6InN0cmluZyIs CiAgICAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICAgImRlc2NyaXB0 aW9uIjoiVGhlIFVSSSBvZiB0aGUgU0NJTSByZXNvdXJjZSByZXByZXNlbnRpbmcgdGhlIFVzZXIn cyBtYW5hZ2VyLiAgUkVRVUlSRUQuIiAsCiAgICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAog ICAgICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICJjYXNlRXhhY3QiOmZh bHNlCiAgICAgICAgICAgfSwKICAgICAgICAgICB7CiAgICAgICAgICAgICAibmFtZSI6ImRpc3Bs YXlOYW1lIiwKICAgICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAgICJtdWx0 aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAiZGVzY3JpcHRpb24iOiJUaGUgZGlzcGxheU5h bWUgb2YgdGhlIFVzZXIncyBtYW5hZ2VyLiAgT1BUSU9OQUwgYW5kIFJFQUQtT05MWS4iICwKICAg ICAgICAgICAgICJyZWFkT25seSI6dHJ1ZSwKICAgICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2Us CiAgICAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZQogICAgICAgICAgIH1dCiAgICAgICAgfV0K fQ== --e89a8f2353a7aff40604e6f81efc Content-Type: application/json; name="group-schema.json" Content-Disposition: attachment; filename="group-schema.json" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hlw8xu8t1 ewogICAgICJpZCI6ICJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6Mi4wOkdyb3VwIiwKICAgICAibmFt ZSI6ICJHcm91cCIsCiAgICAgImRlc2NyaXB0aW9uIjogIkNvcmUgR3JvdXAiLAogICAgICJhdHRy aWJ1dGVzIjpbCiAgICAgICB7CiAgICAgICAgICJuYW1lIjoiaWQiLAogICAgICAgICAidHlwZSI6 InN0cmluZyIsCiAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICJkZXNjcmlw dGlvbiI6IlVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgU0NJTSByZXNvdXJjZSBhcyBkZWZpbmVk IGJ5IHRoZSBTZXJ2aWNlIFByb3ZpZGVyLiBFYWNoIHJlcHJlc2VudGF0aW9uIG9mIHRoZSByZXNv dXJjZSBNVVNUIGluY2x1ZGUgYSBub24tZW1wdHkgaWQgdmFsdWUuIFRoaXMgaWRlbnRpZmllciBN VVNUIGJlIHVuaXF1ZSBhY3Jvc3MgdGhlIFNlcnZpY2UgUHJvdmlkZXIncyBlbnRpcmUgc2V0IG9m IHJlc291cmNlcy4gSXQgTVVTVCBiZSBhIHN0YWJsZSwgbm9uLXJlYXNzaWduYWJsZSBpZGVudGlm aWVyIHRoYXQgZG9lcyBub3QgY2hhbmdlIHdoZW4gdGhlIHNhbWUgcmVzb3VyY2UgaXMgcmV0dXJu ZWQgaW4gc3Vic2VxdWVudCByZXF1ZXN0cy4gVGhlIHZhbHVlIG9mIHRoZSBpZCBhdHRyaWJ1dGUg aXMgYWx3YXlzIGlzc3VlZCBieSB0aGUgU2VydmljZSBQcm92aWRlciBhbmQgTVVTVCBuZXZlciBi ZSBzcGVjaWZpZWQgYnkgdGhlIFNlcnZpY2UgQ29uc3VtZXIuIFJFUVVJUkVELiIsCiAgICAgICAg ICJyZWFkT25seSI6dHJ1ZSwKICAgICAgICAgInJlcXVpcmVkIjp0cnVlLAogICAgICAgICAiY2Fz ZUV4YWN0IjpmYWxzZQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWUiOiJleHRlcm5h bElkIiwKICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAibXVsdGlWYWx1ZWQiOmZh bHNlLAogICAgICAgICAiZGVzY3JpcHRpb24iOiJBbiBpZGVudGlmaWVyIGZvciB0aGUgUmVzb3Vy Y2UgYXMgZGVmaW5lZCBieSB0aGUgU2VydmljZSBDb25zdW1lci4iLAogICAgICAgICAicmVhZE9u bHkiOnRydWUsCiAgICAgICAgICJyZXF1aXJlZCI6dHJ1ZSwKICAgICAgICAgImNhc2VFeGFjdCI6 ZmFsc2UKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lIjoiZGlzcGxheU5hbWUiLAog ICAgICAgICAidHlwZSI6InN0cmluZyIsCiAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAg ICAgICAgICJkZXNjcmlwdGlvbiI6IkEgaHVtYW4gcmVhZGFibGUgbmFtZSBmb3IgdGhlIEdyb3Vw LiAgUkVRVUlSRUQuIiwKICAgICAgICAgInJlYWRPbmx5Ijp0cnVlLAogICAgICAgICAicmVxdWly ZWQiOmZhbHNlLAogICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZQogICAgICAgfSwKICAgICAgIHsK ICAgICAgICAgIm5hbWUiOiJtZW1iZXJzIiwKICAgICAgICAgInR5cGUiOiJjb21wbGV4IiwKICAg ICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAgImRlc2NyaXB0aW9uIjoiQSBsaXN0 IG9mIG1lbWJlcnMgb2YgdGhlIEdyb3VwLiIsCiAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAg ICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlLAogICAg ICAgICAgInN1YkF0dHJpYnV0ZXMiOlsKICAgICAgICAgICAgewogICAgICAgICAgICAgICJuYW1l IjoidmFsdWUiLAogICAgICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAgICAi bXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICAgICJkZXNjcmlwdGlvbiI6IlRoZSBpZGVu dGlmaWVyIG9mIHRoZSBtZW1iZXIgb2YgdGhpcyBHcm91cC4iLAogICAgICAgICAgICAgICJyZWFk T25seSI6ZmFsc2UsCiAgICAgICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAg ICAiY2FzZUV4YWN0IjpmYWxzZQogICAgICAgICAgICB9LAogICAgICAgICAgICB7CiAgICAgICAg ICAgICAgIm5hbWUiOiIkcmVmIiwKICAgICAgICAgICAgICAidHlwZSI6InN0cmluZyIsCiAgICAg ICAgICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAgICAgICAiZGVzY3JpcHRpb24i OiJUaGUgVVJJIG9mIHRoZSBjb3JyZXNwb25kaW5nIHRvIHRoZSBtZW1iZXIgcmVzb3VyY2Ugb2Yg dGhpcyBHcm91cC4iLAogICAgICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAg ICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZQogICAg ICAgICAgICB9LAogICAgICAgICAgICB7CiAgICAgICAgICAgICAgIm5hbWUiOiJ0eXBlIiwKICAg ICAgICAgICAgICAidHlwZSI6InN0cmluZyIsCiAgICAgICAgICAgICAgIm11bHRpVmFsdWVkIjpm YWxzZSwKICAgICAgICAgICAgICAiZGVzY3JpcHRpb24iOiJBIGxhYmVsIGluZGljYXRpbmcgdGhl IHR5cGUgb2YgcmVzb3VyY2U7IGUuZy4sICdVc2VyJyBvciAnR3JvdXAnLiIsCiAgICAgICAgICAg ICAgInJlYWRPbmx5IjpmYWxzZSwKICAgICAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAg ICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlLAogICAgICAgICAgICAgICJjYW5vbmljYWxWYWx1 ZXMiOlsiVXNlciIsICJHcm91cCJdCiAgICAgICAgICAgIH1dCiAgICAgICAgfV0KfQ== --e89a8f2353a7aff40604e6f81efc Content-Type: application/json; name="user-schema.json" Content-Disposition: attachment; filename="user-schema.json" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hlw8xu912 ewogICAgICJpZCI6ICJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6Mi4wOlVzZXIiLAogICAgICJuYW1l IjogIlVzZXIiLAogICAgICJkZXNjcmlwdGlvbiI6ICJDb3JlIFVzZXIiLAogICAgICJhdHRyaWJ1 dGVzIjpbCiAgICAgICB7CiAgICAgICAgICJuYW1lIjoiaWQiLAogICAgICAgICAidHlwZSI6InN0 cmluZyIsCiAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICJkZXNjcmlwdGlv biI6IlVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgU0NJTSByZXNvdXJjZSBhcyBkZWZpbmVkIGJ5 IHRoZSBTZXJ2aWNlIFByb3ZpZGVyLiBFYWNoIHJlcHJlc2VudGF0aW9uIG9mIHRoZSByZXNvdXJj ZSBNVVNUIGluY2x1ZGUgYSBub24tZW1wdHkgaWQgdmFsdWUuIFRoaXMgaWRlbnRpZmllciBNVVNU IGJlIHVuaXF1ZSBhY3Jvc3MgdGhlIFNlcnZpY2UgUHJvdmlkZXIncyBlbnRpcmUgc2V0IG9mIHJl c291cmNlcy4gSXQgTVVTVCBiZSBhIHN0YWJsZSwgbm9uLXJlYXNzaWduYWJsZSBpZGVudGlmaWVy IHRoYXQgZG9lcyBub3QgY2hhbmdlIHdoZW4gdGhlIHNhbWUgcmVzb3VyY2UgaXMgcmV0dXJuZWQg aW4gc3Vic2VxdWVudCByZXF1ZXN0cy4gVGhlIHZhbHVlIG9mIHRoZSBpZCBhdHRyaWJ1dGUgaXMg YWx3YXlzIGlzc3VlZCBieSB0aGUgU2VydmljZSBQcm92aWRlciBhbmQgTVVTVCBuZXZlciBiZSBz cGVjaWZpZWQgYnkgdGhlIFNlcnZpY2UgQ29uc3VtZXIuIFJFUVVJUkVELiIsCiAgICAgICAgICJy ZWFkT25seSI6dHJ1ZSwKICAgICAgICAgInJlcXVpcmVkIjp0cnVlLAogICAgICAgICAiY2FzZUV4 YWN0IjpmYWxzZQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWUiOiJleHRlcm5hbElk IiwKICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNl LAogICAgICAgICAiZGVzY3JpcHRpb24iOiJBbiBpZGVudGlmaWVyIGZvciB0aGUgUmVzb3VyY2Ug YXMgZGVmaW5lZCBieSB0aGUgU2VydmljZSBDb25zdW1lci4iLAogICAgICAgICAicmVhZE9ubHki OnRydWUsCiAgICAgICAgICJyZXF1aXJlZCI6dHJ1ZSwKICAgICAgICAgImNhc2VFeGFjdCI6ZmFs c2UKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lIjoidXNlck5hbWUiLAogICAgICAg ICAidHlwZSI6InN0cmluZyIsCiAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAg ICJkZXNjcmlwdGlvbiI6IlVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgVXNlciB0eXBpY2FsbHkg dXNlZCBieSB0aGUgdXNlciB0byBkaXJlY3RseSBhdXRoZW50aWNhdGUgdG8gdGhlIHNlcnZpY2Ug cHJvdmlkZXIuIEVhY2ggVXNlciBNVVNUIGluY2x1ZGUgYSBub24tZW1wdHkgdXNlck5hbWUgdmFs dWUuICBUaGlzIGlkZW50aWZpZXIgTVVTVCBiZSB1bmlxdWUgYWNyb3NzIHRoZSBTZXJ2aWNlIENv bnN1bWVyJ3MgZW50aXJlIHNldCBvZiBVc2Vycy4gIFJFUVVJUkVEIiwKICAgICAgICAgInJlYWRP bmx5IjpmYWxzZSwKICAgICAgICAgInJlcXVpcmVkIjp0cnVlLAogICAgICAgICAiY2FzZUV4YWN0 IjpmYWxzZQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWUiOiJuYW1lIiwKICAgICAg ICAgInR5cGUiOiJjb21wbGV4IiwKICAgICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAg ICAgImRlc2NyaXB0aW9uIjoiVGhlIGNvbXBvbmVudHMgb2YgdGhlIHVzZXIncyByZWFsIG5hbWUu IFByb3ZpZGVycyBNQVkgcmV0dXJuIGp1c3QgdGhlIGZ1bGwgbmFtZSBhcyBhIHNpbmdsZSBzdHJp bmcgaW4gdGhlIGZvcm1hdHRlZCBzdWItYXR0cmlidXRlLCBvciB0aGV5IE1BWSByZXR1cm4ganVz dCB0aGUgaW5kaXZpZHVhbCBjb21wb25lbnQgYXR0cmlidXRlcyB1c2luZyB0aGUgb3RoZXIgc3Vi LWF0dHJpYnV0ZXMsIG9yIHRoZXkgTUFZIHJldHVybiBib3RoLiBJZiBib3RoIHZhcmlhbnRzIGFy ZSByZXR1cm5lZCwgdGhleSBTSE9VTEQgYmUgZGVzY3JpYmluZyB0aGUgc2FtZSBuYW1lLCB3aXRo IHRoZSBmb3JtYXR0ZWQgbmFtZSBpbmRpY2F0aW5nIGhvdyB0aGUgY29tcG9uZW50IGF0dHJpYnV0 ZXMgc2hvdWxkIGJlIGNvbWJpbmVkLiIsCiAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAg ICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlLAogICAgICAg ICAic3ViQXR0cmlidXRlcyI6WwogICAgICAgICAgIHsKICAgICAgICAgICAgICJuYW1lIjoiZm9y bWF0dGVkIiwKICAgICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAgICJtdWx0 aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAiZGVzY3JpcHRpb24iOiJUaGUgZnVsbCBuYW1l LCBpbmNsdWRpbmcgYWxsIG1pZGRsZSBuYW1lcywgdGl0bGVzLCBhbmQgc3VmZml4ZXMgYXMgYXBw cm9wcmlhdGUsIGZvcm1hdHRlZCBmb3IgZGlzcGxheSAoZS5nLiBNcy4gQmFyYmFyYSBKIEplbnNl biwgSUlJLikuIiAsCiAgICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAgICAg InJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAg ICAgfSwKICAgICAgICAgICB7CiAgICAgICAgICAgICAibmFtZSI6ImZhbWlseU5hbWUiLAogICAg ICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAgICAgIm11bHRpVmFsdWVkIjpmYWxz ZSwKICAgICAgICAgICAgICJkZXNjcmlwdGlvbiI6IlRoZSBmYW1pbHkgbmFtZSBvZiB0aGUgVXNl ciwgb3IgTGFzdCBOYW1lIGluIG1vc3QgV2VzdGVybiBsYW5ndWFnZXMgKGUuZy4gSmVuc2VuIGdp dmVuIHRoZSBmdWxsIG5hbWUgTXMuIEJhcmJhcmEgSiBKZW5zZW4sIElJSS4pLiIsCiAgICAgICAg ICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAg ICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAgICAgfSwKICAgICAgICAgICB7CiAg ICAgICAgICAgICAibmFtZSI6ImdpdmVuTmFtZSIsCiAgICAgICAgICAgICAidHlwZSI6InN0cmlu ZyIsCiAgICAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICAgImRlc2Ny aXB0aW9uIjoiVGhlIGdpdmVuIG5hbWUgb2YgdGhlIFVzZXIsIG9yIEZpcnN0IE5hbWUgaW4gbW9z dCBXZXN0ZXJuIGxhbmd1YWdlcyAoZS5nLiBCYXJiYXJhIGdpdmVuIHRoZSBmdWxsIG5hbWUgTXMu IEJhcmJhcmEgSiBKZW5zZW4sIElJSS4pLiIsCiAgICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNl LAogICAgICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICJjYXNlRXhhY3Qi OmZhbHNlCiAgICAgICAgICAgfSwKICAgICAgICAgICB7CiAgICAgICAgICAgICAibmFtZSI6Im1p ZGRsZU5hbWUiLAogICAgICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAgICAgIm11 bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAgICAgICJkZXNjcmlwdGlvbiI6IlRoZSBtaWRkbGUg bmFtZShzKSBvZiB0aGUgVXNlciAoZS5nLiBSb2JlcnQgZ2l2ZW4gdGhlIGZ1bGwgbmFtZSBNcy4g QmFyYmFyYSBKIEplbnNlbiwgSUlJLikuIiwKICAgICAgICAgICAgICJyZWFkT25seSI6ZmFsc2Us CiAgICAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgICAgImNhc2VFeGFjdCI6 ZmFsc2UKICAgICAgICAgICB9LAogICAgICAgICAgIHsKICAgICAgICAgICAgICJuYW1lIjoiaG9u b3JpZmljUHJlZml4IiwKICAgICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAg ICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAiZGVzY3JpcHRpb24iOiJUaGUgaG9u b3JpZmljIHByZWZpeChlcykgb2YgdGhlIFVzZXIsIG9yIFRpdGxlIGluIG1vc3QgV2VzdGVybiBs YW5ndWFnZXMgKGUuZy4gTXMuIGdpdmVuIHRoZSBmdWxsIG5hbWUgTXMuIEJhcmJhcmEgSiBKZW5z ZW4sIElJSS4pLiIsCiAgICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAgICAg InJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAg ICAgfSwKICAgICAgICAgICB7CiAgICAgICAgICAgICAibmFtZSI6Imhvbm9yaWZpY1N1ZmZpeCIs CiAgICAgICAgICAgICAidHlwZSI6InN0cmluZyIsCiAgICAgICAgICAgICAibXVsdGlWYWx1ZWQi OmZhbHNlLAogICAgICAgICAgICAgImRlc2NyaXB0aW9uIjoiVGhlIGhvbm9yaWZpYyBzdWZmaXgo ZXMpIG9mIHRoZSBVc2VyLCBvciBTdWZmaXggaW4gbW9zdCBXZXN0ZXJuIGxhbmd1YWdlcyAoZS5n LiBJSUkuIGdpdmVuIHRoZSBmdWxsIG5hbWUgTXMuIEJhcmJhcmEgSiBKZW5zZW4sIElJSS4pLiIs CiAgICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAgICAgInJlcXVpcmVkIjpm YWxzZSwKICAgICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAgICAgfQogICAgICAg ICBdCiAgICAgICAgfSwKICAgICAgICB7CiAgICAgICAgICAibmFtZSI6ImRpc3BsYXlOYW1lIiwK ICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2Us CiAgICAgICAgICAiZGVzY3JpcHRpb24iOiJUaGUgbmFtZSBvZiB0aGUgVXNlciwgc3VpdGFibGUg Zm9yIGRpc3BsYXkgdG8gZW5kLXVzZXJzLiBUaGUgbmFtZSBTSE9VTEQgYmUgdGhlIGZ1bGwgbmFt ZSBvZiB0aGUgVXNlciBiZWluZyBkZXNjcmliZWQgaWYga25vd24iLAogICAgICAgICAgInJlYWRP bmx5IjpmYWxzZSwKICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAiY2FzZUV4 YWN0IjpmYWxzZQogICAgICAgIH0sICAgICAgICAKICAgICAgICB7CiAgICAgICAgICAibmFtZSI6 Im5pY2tOYW1lIiwKICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICJtdWx0aVZh bHVlZCI6ZmFsc2UsCiAgICAgICAgICAiZGVzY3JpcHRpb24iOiJUaGUgY2FzdWFsIHdheSB0byBh ZGRyZXNzIHRoZSB1c2VyIGluIHJlYWwgbGlmZSwgZS5nLiBcIkJvYlwiIG9yIFwiQm9iYnlcIiBp bnN0ZWFkIG9mIFwiUm9iZXJ0XCIuICBUaGlzIGF0dHJpYnV0ZSBTSE9VTEQgTk9UIGJlIHVzZWQg dG8gcmVwcmVzZW50IGEgVXNlcidzIHVzZXJuYW1lIChlLmcuIGJqZW5zZW4gb3IgbXBlcHBlcmlk Z2UpIiwKICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAicmVxdWlyZWQiOmZh bHNlLAogICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICB9LAogICAgICAgIHsKICAg ICAgICAgICJuYW1lIjoicHJvZmlsZVVybCIsCiAgICAgICAgICAidHlwZSI6InN0cmluZyIsCiAg ICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgImRlc2NyaXB0aW9uIjoiQSBm dWxseSBxdWFsaWZpZWQgVVJMIHRvIGEgcGFnZSByZXByZXNlbnRpbmcgdGhlIFVzZXIncyBvbmxp bmUgcHJvZmlsZSIsCiAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAgInJlcXVp cmVkIjpmYWxzZSwKICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAgfSwKICAgICAg ICB7CiAgICAgICAgICAibmFtZSI6InRpdGxlIiwKICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwK ICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAiZGVzY3JpcHRpb24iOiJU aGUgdXNlcidzIHRpdGxlLCBzdWNoIGFzIFwiVmljZSBQcmVzaWRlbnQuXCIiLAogICAgICAgICAg InJlYWRPbmx5IjpmYWxzZSwKICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAi Y2FzZUV4YWN0IjpmYWxzZQogICAgICAgIH0sCiAgICAgICAgewogICAgICAgICAgIm5hbWUiOiJ1 c2VyVHlwZSIsCiAgICAgICAgICAidHlwZSI6InN0cmluZyIsCiAgICAgICAgICAibXVsdGlWYWx1 ZWQiOmZhbHNlLAogICAgICAgICAgImRlc2NyaXB0aW9uIjoiVXNlZCB0byBpZGVudGlmeSB0aGUg b3JnYW5pemF0aW9uIHRvIHVzZXIgcmVsYXRpb25zaGlwLiBUeXBpY2FsIHZhbHVlcyB1c2VkIG1p Z2h0IGJlIFwiQ29udHJhY3RvclwiLCBcIkVtcGxveWVlXCIsIFwiSW50ZXJuXCIsIFwiVGVtcFwi LCBcIkV4dGVybmFsXCIsIGFuZCBcIlVua25vd25cIiBidXQgYW55IHZhbHVlIG1heSBiZSB1c2Vk ICIsCiAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAgInJlcXVpcmVkIjpmYWxz ZSwKICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAgfSwKICAgICAgICB7CiAgICAg ICAgICAibmFtZSI6InByZWZlcnJlZExhbmd1YWdlIiwKICAgICAgICAgICJ0eXBlIjoic3RyaW5n IiwKICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAiZGVzY3JpcHRpb24i OiJJbmRpY2F0ZXMgdGhlIFVzZXIncyBwcmVmZXJyZWQgd3JpdHRlbiBvciBzcG9rZW4gbGFuZ3Vh Z2UuICBHZW5lcmFsbHkgdXNlZCBmb3Igc2VsZWN0aW5nIGEgbG9jYWxpemVkIFVzZXIgaW50ZXJm YWNlLiBlLmcuLCAnZW5fVVMnIHNwZWNpZmllcyB0aGUgbGFuZ3VhZ2UgRW5nbGlzaCBhbmQgY291 bnRyeSBVUy4iLAogICAgICAgICAgInJlYWRPbmx5IjpmYWxzZSwKICAgICAgICAgICJyZXF1aXJl ZCI6ZmFsc2UsCiAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZQogICAgICAgIH0sCiAgICAgICAg ewogICAgICAgICAgIm5hbWUiOiJsb2NhbGUiLAogICAgICAgICAgInR5cGUiOiJzdHJpbmciLAog ICAgICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAgICJkZXNjcmlwdGlvbiI6IlVz ZWQgdG8gaW5kaWNhdGUgdGhlIFVzZXIncyBkZWZhdWx0IGxvY2F0aW9uIGZvciBwdXJwb3NlcyBv ZiBsb2NhbGl6aW5nIGl0ZW1zIHN1Y2ggYXMgY3VycmVuY3ksIGRhdGUgdGltZSBmb3JtYXQsIG51 bWVyaWNhbCByZXByZXNlbnRhdGlvbnMsIGV0Yy4iLAogICAgICAgICAgInJlYWRPbmx5IjpmYWxz ZSwKICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxz ZQogICAgICAgIH0sCiAgICAgICAgewogICAgICAgICAgIm5hbWUiOiJ0aW1lem9uZSIsCiAgICAg ICAgICAidHlwZSI6InN0cmluZyIsCiAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAg ICAgICAgImRlc2NyaXB0aW9uIjoiVGhlIFVzZXIncyB0aW1lIHpvbmUgaW4gdGhlIFwiT2xzb25c IiB0aW1lem9uZSBkYXRhYmFzZSBmb3JtYXQgWzE5XTsgZS5nLiwnQW1lcmljYS9Mb3NfQW5nZWxl cyciLAogICAgICAgICAgInJlYWRPbmx5IjpmYWxzZSwKICAgICAgICAgICJyZXF1aXJlZCI6ZmFs c2UsCiAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZQogICAgICAgIH0sCiAgICAgICAgewogICAg ICAgICAgIm5hbWUiOiJhY3RpdmUiLAogICAgICAgICAgInR5cGUiOiJib29sZWFuIiwKICAgICAg ICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAiZGVzY3JpcHRpb24iOiJBIEJvb2xl YW4gdmFsdWUgaW5kaWNhdGluZyB0aGUgVXNlcidzIGFkbWluaXN0cmF0aXZlIHN0YXR1cy4iLAog ICAgICAgICAgInJlYWRPbmx5Ijp0cnVlLAogICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAg ICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAgfSwKICAgICAgICB7CiAgICAgICAgICAi bmFtZSI6InBhc3N3b3JkIiwKICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICJt dWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAiZGVzY3JpcHRpb24iOiJUaGUgVXNlcidzIGNs ZWFyIHRleHQgcGFzc3dvcmQuICBUaGlzIGF0dHJpYnV0ZSBpcyBpbnRlbmRlZCB0byBiZSB1c2Vk IGFzIGEgbWVhbnMgdG8gc3BlY2lmeSBhbiBpbml0aWFsIHBhc3N3b3JkIHdoZW4gY3JlYXRpbmcg YSBuZXcgVXNlciBvciB0byByZXNldCBhbiBleGlzdGluZyBVc2VyJ3MgcGFzc3dvcmQuIiwKICAg ICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAg ICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICB9LAogICAgICAgIHsKICAgICAgICAgICJu YW1lIjoiZW1haWxzIiwKICAgICAgICAgICJ0eXBlIjoiY29tcGxleCIsCiAgICAgICAgICAibXVs dGlWYWx1ZWQiOnRydWUsCiAgICAgICAgICAiZGVzY3JpcHRpb24iOiJFLW1haWwgYWRkcmVzc2Vz IGZvciB0aGUgdXNlci4gVGhlIHZhbHVlIFNIT1VMRCBiZSBjYW5vbmljYWxpemVkIGJ5IHRoZSBT ZXJ2aWNlIFByb3ZpZGVyLCBlLmcuIGJqZW5zZW5AZXhhbXBsZS5jb20gaW5zdGVhZCBvZiBiamVu c2VuQEVYQU1QTEUuQ09NLiBDYW5vbmljYWwgVHlwZSB2YWx1ZXMgb2Ygd29yaywgaG9tZSwgYW5k IG90aGVyLiIsCiAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAgInJlcXVpcmVk IjpmYWxzZSwKICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlLAogICAgICAgICAgInN1YkF0dHJp YnV0ZXMiOlsKICAgICAgICAgICAgewogICAgICAgICAgICAgICJuYW1lIjoidmFsdWUiLAogICAg ICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZh bHNlLAogICAgICAgICAgICAgICJkZXNjcmlwdGlvbiI6IkUtbWFpbCBhZGRyZXNzZXMgZm9yIHRo ZSB1c2VyLiBUaGUgdmFsdWUgU0hPVUxEIGJlIGNhbm9uaWNhbGl6ZWQgYnkgdGhlIFNlcnZpY2Ug UHJvdmlkZXIsIGUuZy4gYmplbnNlbkBleGFtcGxlLmNvbSBpbnN0ZWFkIG9mIGJqZW5zZW5ARVhB TVBMRS5DT00uIENhbm9uaWNhbCBUeXBlIHZhbHVlcyBvZiB3b3JrLCBob21lLCBhbmQgb3RoZXIu IiwKICAgICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAgICAgICJyZXF1aXJl ZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICAgICAgfSwK ICAgICAgICAgICAgewogICAgICAgICAgICAgICJuYW1lIjoiZGlzcGxheSIsCiAgICAgICAgICAg ICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAg ICAgICAgICAgICAgImRlc2NyaXB0aW9uIjoiQSBodW1hbiByZWFkYWJsZSBuYW1lLCBwcmltYXJp bHkgdXNlZCBmb3IgZGlzcGxheSBwdXJwb3Nlcy4gUkVBRC1PTkxZLiIsCiAgICAgICAgICAgICAg InJlYWRPbmx5Ijp0cnVlLAogICAgICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAg ICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICAgICAgfSwKICAgICAgICAgICAgewogICAg ICAgICAgICAgICJuYW1lIjoidHlwZSIsCiAgICAgICAgICAgICAgInR5cGUiOiJzdHJpbmciLAog ICAgICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImRlc2NyaXB0 aW9uIjoiQSBsYWJlbCBpbmRpY2F0aW5nIHRoZSBhdHRyaWJ1dGUncyBmdW5jdGlvbjsgZS5nLiwg J3dvcmsnIG9yICdob21lJy4iLAogICAgICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAg ICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxz ZSwKICAgICAgICAgICAgICAiY2Fub25pY2FsVmFsdWVzIjpbIndvcmsiLCJob21lIiwib3RoZXIi XQogICAgICAgICAgICB9LAogICAgICAgICAgICB7CiAgICAgICAgICAgICAgIm5hbWUiOiJwcmlt YXJ5IiwKICAgICAgICAgICAgICAidHlwZSI6ImJvb2xlYW4iLAogICAgICAgICAgICAgICJtdWx0 aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImRlc2NyaXB0aW9uIjoiQSBCb29sZWFuIHZh bHVlIGluZGljYXRpbmcgdGhlICdwcmltYXJ5JyBvciBwcmVmZXJyZWQgYXR0cmlidXRlIHZhbHVl IGZvciB0aGlzIGF0dHJpYnV0ZSwgZS5nLiB0aGUgcHJlZmVycmVkIG1haWxpbmcgYWRkcmVzcyBv ciBwcmltYXJ5IGUtbWFpbCBhZGRyZXNzLiBUaGUgcHJpbWFyeSBhdHRyaWJ1dGUgdmFsdWUgJ3Ry dWUnIE1VU1QgYXBwZWFyIG5vIG1vcmUgdGhhbiBvbmNlLiIsCiAgICAgICAgICAgICAgInJlYWRP bmx5IjpmYWxzZSwKICAgICAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgICAg ICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAgICAgIH1dCiAgICAgICAgfSwKICAgICAgICB7CiAg ICAgICAgICAibmFtZSI6InBob25lTnVtYmVycyIsCiAgICAgICAgICAidHlwZSI6ImNvbXBsZXgi LAogICAgICAgICAgIm11bHRpVmFsdWVkIjp0cnVlLAogICAgICAgICAgImRlc2NyaXB0aW9uIjoi UGhvbmUgbnVtYmVycyBmb3IgdGhlIFVzZXIuICBUaGUgdmFsdWUgU0hPVUxEIGJlIGNhbm9uaWNh bGl6ZWQgYnkgdGhlIFNlcnZpY2UgUHJvdmlkZXIgYWNjb3JkaW5nIHRvIGZvcm1hdCBpbiBSRkMz OTY2IFsyMF0gZS5nLiAndGVsOisxLTIwMS01NTUtMDEyMycuICBDYW5vbmljYWwgVHlwZSB2YWx1 ZXMgb2Ygd29yaywgaG9tZSwgbW9iaWxlLCBmYXgsIHBhZ2VyIGFuZCBvdGhlci4iLAogICAgICAg ICAgInJlYWRPbmx5IjpmYWxzZSwKICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAg ICAiY2FzZUV4YWN0IjpmYWxzZSwKICAgICAgICAgICJzdWJBdHRyaWJ1dGVzIjpbCiAgICAgICAg ICAgIHsKICAgICAgICAgICAgICAibmFtZSI6InZhbHVlIiwKICAgICAgICAgICAgICAidHlwZSI6 InN0cmluZyIsCiAgICAgICAgICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAgICAg ICAiZGVzY3JpcHRpb24iOiJQaG9uZSBudW1iZXIgb2YgdGhlIFVzZXIiLAogICAgICAgICAgICAg ICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAg ICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZQogICAgICAgICAgICB9LAogICAgICAgICAgICB7CiAg ICAgICAgICAgICAgIm5hbWUiOiJkaXNwbGF5IiwKICAgICAgICAgICAgICAidHlwZSI6InN0cmlu ZyIsCiAgICAgICAgICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAgICAgICAiZGVz Y3JpcHRpb24iOiJBIGh1bWFuIHJlYWRhYmxlIG5hbWUsIHByaW1hcmlseSB1c2VkIGZvciBkaXNw bGF5IHB1cnBvc2VzLiBSRUFELU9OTFkuIiwKICAgICAgICAgICAgICAicmVhZE9ubHkiOnRydWUs CiAgICAgICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICAiY2FzZUV4YWN0 IjpmYWxzZQogICAgICAgICAgICB9LAogICAgICAgICAgICB7CiAgICAgICAgICAgICAgIm5hbWUi OiJ0eXBlIiwKICAgICAgICAgICAgICAidHlwZSI6InN0cmluZyIsCiAgICAgICAgICAgICAgIm11 bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAgICAgICAiZGVzY3JpcHRpb24iOiJBIGxhYmVsIGlu ZGljYXRpbmcgdGhlIGF0dHJpYnV0ZSdzIGZ1bmN0aW9uOyBlLmcuLCAnd29yaycgb3IgJ2hvbWUn IG9yICdtb2JpbGUnIGV0Yy4iLAogICAgICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAg ICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxz ZSwKICAgICAgICAgICAgICAiY2Fub25pY2FsVmFsdWVzIjpbIndvcmsiLCAiaG9tZSIsICJtb2Jp bGUiLCAiZmF4IiwgInBhZ2VyIiwgIm90aGVyIl0KICAgICAgICAgICAgfSwKICAgICAgICAgICAg ewogICAgICAgICAgICAgICJuYW1lIjoicHJpbWFyeSIsCiAgICAgICAgICAgICAgInR5cGUiOiJi b29sZWFuIiwKICAgICAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICAg ICJkZXNjcmlwdGlvbiI6IkEgQm9vbGVhbiB2YWx1ZSBpbmRpY2F0aW5nIHRoZSAncHJpbWFyeScg b3IgcHJlZmVycmVkIGF0dHJpYnV0ZSB2YWx1ZSBmb3IgdGhpcyBhdHRyaWJ1dGUsIGUuZy4gdGhl IHByZWZlcnJlZCBwaG9uZSBudW1iZXIgb3IgcHJpbWFyeSBwaG9uZSBudW1iZXIuIFRoZSBwcmlt YXJ5IGF0dHJpYnV0ZSB2YWx1ZSAndHJ1ZScgTVVTVCBhcHBlYXIgbm8gbW9yZSB0aGFuIG9uY2Uu IiwKICAgICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAgICAgICJyZXF1aXJl ZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICAgICAgfV0K ICAgICAgICB9LAogICAgICAgICAgICAgICAgewogICAgICAgICAgIm5hbWUiOiJpbXMiLAogICAg ICAgICAgInR5cGUiOiJjb21wbGV4IiwKICAgICAgICAgICJtdWx0aVZhbHVlZCI6dHJ1ZSwKICAg ICAgICAgICJkZXNjcmlwdGlvbiI6Ikluc3RhbnQgbWVzc2FnaW5nIGFkZHJlc3NlcyBmb3IgdGhl IFVzZXIuIiwKICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAicmVxdWlyZWQi OmZhbHNlLAogICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UsCiAgICAgICAgICAic3ViQXR0cmli dXRlcyI6WwogICAgICAgICAgICB7CiAgICAgICAgICAgICAgIm5hbWUiOiJ2YWx1ZSIsCiAgICAg ICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFs c2UsCiAgICAgICAgICAgICAgImRlc2NyaXB0aW9uIjoiSW5zdGFudCBtZXNzYWdpbmcgYWRkcmVz cyBmb3IgdGhlIFVzZXIuIiwKICAgICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAg ICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UK ICAgICAgICAgICAgfSwKICAgICAgICAgICAgewogICAgICAgICAgICAgICJuYW1lIjoiZGlzcGxh eSIsCiAgICAgICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAgICAgICJtdWx0aVZh bHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImRlc2NyaXB0aW9uIjoiQSBodW1hbiByZWFkYWJs ZSBuYW1lLCBwcmltYXJpbHkgdXNlZCBmb3IgZGlzcGxheSBwdXJwb3Nlcy4gUkVBRC1PTkxZLiIs CiAgICAgICAgICAgICAgInJlYWRPbmx5Ijp0cnVlLAogICAgICAgICAgICAgICJyZXF1aXJlZCI6 ZmFsc2UsCiAgICAgICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICAgICAgfSwKICAg ICAgICAgICAgewogICAgICAgICAgICAgICJuYW1lIjoidHlwZSIsCiAgICAgICAgICAgICAgInR5 cGUiOiJzdHJpbmciLAogICAgICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAg ICAgICAgImRlc2NyaXB0aW9uIjoiQSBsYWJlbCBpbmRpY2F0aW5nIHRoZSBhdHRyaWJ1dGUncyBm dW5jdGlvbjsgZS5nLiwgJ2FpbScsICdndGFsaycsICdtb2JpbGUnIGV0Yy4iLAogICAgICAgICAg ICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAg ICAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZSwKICAgICAgICAgICAgICAiY2Fub25pY2FsVmFs dWVzIjpbImFpbSIsICJndGFsayIsICJpY3EiLCAieG1wcCIsICJtc24iLCAic2t5cGUiLCAicXEi LCAieWFob28iXQogICAgICAgICAgICB9LAogICAgICAgICAgICB7CiAgICAgICAgICAgICAgIm5h bWUiOiJwcmltYXJ5IiwKICAgICAgICAgICAgICAidHlwZSI6ImJvb2xlYW4iLAogICAgICAgICAg ICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImRlc2NyaXB0aW9uIjoiQSBC b29sZWFuIHZhbHVlIGluZGljYXRpbmcgdGhlICdwcmltYXJ5JyBvciBwcmVmZXJyZWQgYXR0cmli dXRlIHZhbHVlIGZvciB0aGlzIGF0dHJpYnV0ZSwgZS5nLiB0aGUgcHJlZmVycmVkIG1lc3Nlbmdl ciBvciBwcmltYXJ5IG1lc3Nlbmdlci4gVGhlIHByaW1hcnkgYXR0cmlidXRlIHZhbHVlICd0cnVl JyBNVVNUIGFwcGVhciBubyBtb3JlIHRoYW4gb25jZS4iLAogICAgICAgICAgICAgICJyZWFkT25s eSI6ZmFsc2UsCiAgICAgICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICAi Y2FzZUV4YWN0IjpmYWxzZQogICAgICAgICAgICB9XQogICAgICAgIH0sCiAgICAgICAgewogICAg ICAgICAgIm5hbWUiOiJwaG90b3MiLAogICAgICAgICAgInR5cGUiOiJjb21wbGV4IiwKICAgICAg ICAgICJtdWx0aVZhbHVlZCI6dHJ1ZSwKICAgICAgICAgICJkZXNjcmlwdGlvbiI6IlVSTHMgb2Yg cGhvdG9zIG9mIHRoZSBVc2VyLiIsCiAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAg ICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlLAogICAgICAg ICAgInN1YkF0dHJpYnV0ZXMiOlsKICAgICAgICAgICAgewogICAgICAgICAgICAgICJuYW1lIjoi dmFsdWUiLAogICAgICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAgICAibXVs dGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICAgICJkZXNjcmlwdGlvbiI6IlVSTCBvZiBhIHBo b3RvIG9mIHRoZSBVc2VyLiIsCiAgICAgICAgICAgICAgInJlYWRPbmx5IjpmYWxzZSwKICAgICAg ICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNl CiAgICAgICAgICAgIH0sCiAgICAgICAgICAgIHsKICAgICAgICAgICAgICAibmFtZSI6ImRpc3Bs YXkiLAogICAgICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAgICAibXVsdGlW YWx1ZWQiOmZhbHNlLAogICAgICAgICAgICAgICJkZXNjcmlwdGlvbiI6IkEgaHVtYW4gcmVhZGFi bGUgbmFtZSwgcHJpbWFyaWx5IHVzZWQgZm9yIGRpc3BsYXkgcHVycG9zZXMuIFJFQUQtT05MWS4i LAogICAgICAgICAgICAgICJyZWFkT25seSI6dHJ1ZSwKICAgICAgICAgICAgICAicmVxdWlyZWQi OmZhbHNlLAogICAgICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAgICAgIH0sCiAg ICAgICAgICAgIHsKICAgICAgICAgICAgICAibmFtZSI6InR5cGUiLAogICAgICAgICAgICAgICJ0 eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAg ICAgICAgICJkZXNjcmlwdGlvbiI6IkEgbGFiZWwgaW5kaWNhdGluZyB0aGUgYXR0cmlidXRlJ3Mg ZnVuY3Rpb247IGUuZy4sICdwaG90bycgb3IgJ3RodW1ibmFpbCcuIiwKICAgICAgICAgICAgICAi cmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAg ICAgICAgImNhc2VFeGFjdCI6ZmFsc2UsCiAgICAgICAgICAgICAgImNhbm9uaWNhbFZhbHVlcyI6 WyJwaG90byIsICJ0aHVtYm5haWwiXQogICAgICAgICAgICB9LAogICAgICAgICAgICB7CiAgICAg ICAgICAgICAgIm5hbWUiOiJwcmltYXJ5IiwKICAgICAgICAgICAgICAidHlwZSI6ImJvb2xlYW4i LAogICAgICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImRlc2Ny aXB0aW9uIjoiQSBCb29sZWFuIHZhbHVlIGluZGljYXRpbmcgdGhlICdwcmltYXJ5JyBvciBwcmVm ZXJyZWQgYXR0cmlidXRlIHZhbHVlIGZvciB0aGlzIGF0dHJpYnV0ZSwgZS5nLiB0aGUgcHJlZmVy cmVkIHBob3RvIG9yIHRodW1ibmFpbC4gVGhlIHByaW1hcnkgYXR0cmlidXRlIHZhbHVlICd0cnVl JyBNVVNUIGFwcGVhciBubyBtb3JlIHRoYW4gb25jZS4iLAogICAgICAgICAgICAgICJyZWFkT25s eSI6ZmFsc2UsCiAgICAgICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICAi Y2FzZUV4YWN0IjpmYWxzZQogICAgICAgICAgICB9XQogICAgICAgIH0sCiAgICAgICAgewogICAg ICAgICAgIm5hbWUiOiJhZGRyZXNzZXMiLAogICAgICAgICAgInR5cGUiOiJjb21wbGV4IiwKICAg ICAgICAgICJtdWx0aVZhbHVlZCI6dHJ1ZSwKICAgICAgICAgICJkZXNjcmlwdGlvbiI6IkEgcGh5 c2ljYWwgbWFpbGluZyBhZGRyZXNzIGZvciB0aGlzIFVzZXIsIGFzIGRlc2NyaWJlZCBpbiAoYWRk cmVzcyBFbGVtZW50KS4gQ2Fub25pY2FsIFR5cGUgVmFsdWVzIG9mIHdvcmssIGhvbWUsIGFuZCBv dGhlci4gVGhlIHZhbHVlIGF0dHJpYnV0ZSBpcyBhIGNvbXBsZXggdHlwZSB3aXRoIHRoZSBmb2xs b3dpbmcgc3ViLWF0dHJpYnV0ZXMuIiwKICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAg ICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UsCiAgICAg ICAgICAic3ViQXR0cmlidXRlcyI6WwogICAgICAgICAgICB7CiAgICAgICAgICAgICAgIm5hbWUi OiJmb3JtYXR0ZWQiLAogICAgICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAg ICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICAgICJkZXNjcmlwdGlvbiI6IlRoZSBm dWxsIG1haWxpbmcgYWRkcmVzcywgZm9ybWF0dGVkIGZvciBkaXNwbGF5IG9yIHVzZSB3aXRoIGEg bWFpbGluZyBsYWJlbC4gVGhpcyBhdHRyaWJ1dGUgTUFZIGNvbnRhaW4gbmV3bGluZXMuIiwKICAg ICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAgICAgICJyZXF1aXJlZCI6ZmFs c2UsCiAgICAgICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICAgICAgfSwKICAgICAg ICAgICAgewogICAgICAgICAgICAgICJuYW1lIjoic3RyZWV0QWRkcmVzcyIsCiAgICAgICAgICAg ICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAg ICAgICAgICAgICAgImRlc2NyaXB0aW9uIjoiVGhlIGZ1bGwgc3RyZWV0IGFkZHJlc3MgY29tcG9u ZW50LCB3aGljaCBtYXkgaW5jbHVkZSBob3VzZSBudW1iZXIsIHN0cmVldCBuYW1lLCBQTyBCT1gs IGFuZCBtdWx0aS1saW5lIGV4dGVuZGVkIHN0cmVldCBhZGRyZXNzIGluZm9ybWF0aW9uLiBUaGlz IGF0dHJpYnV0ZSBNQVkgY29udGFpbiBuZXdsaW5lcy4iLAogICAgICAgICAgICAgICJyZWFkT25s eSI6ZmFsc2UsCiAgICAgICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICAi Y2FzZUV4YWN0IjpmYWxzZQogICAgICAgICAgICB9LAogICAgICAgICAgICB7CiAgICAgICAgICAg ICAgIm5hbWUiOiJsb2NhbGl0eSIsCiAgICAgICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAg ICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImRlc2NyaXB0aW9u IjoiVGhlIGNpdHkgb3IgbG9jYWxpdHkgY29tcG9uZW50LiIsCiAgICAgICAgICAgICAgInJlYWRP bmx5IjpmYWxzZSwKICAgICAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgICAg ICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAgICAgIH0sCiAgICAgICAgICAgIHsKICAgICAgICAg ICAgICAibmFtZSI6InJlZ2lvbiIsCiAgICAgICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAg ICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImRlc2NyaXB0aW9u IjoiVGhlIHN0YXRlIG9yIHJlZ2lvbiBjb21wb25lbnQuIiwKICAgICAgICAgICAgICAicmVhZE9u bHkiOmZhbHNlLAogICAgICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAgICAg ImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICAgICAgfSwKICAgICAgICAgICAgewogICAgICAgICAg ICAgICJuYW1lIjoicG9zdGFsQ29kZSIsCiAgICAgICAgICAgICAgInR5cGUiOiJzdHJpbmciLAog ICAgICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImRlc2NyaXB0 aW9uIjoiVGhlIHppcGNvZGUgb3IgcG9zdGFsIGNvZGUgY29tcG9uZW50LiIsCiAgICAgICAgICAg ICAgInJlYWRPbmx5IjpmYWxzZSwKICAgICAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAg ICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAgICAgIH0sCiAgICAgICAgICAgIHsK ICAgICAgICAgICAgICAibmFtZSI6ImNvdW50cnkiLAogICAgICAgICAgICAgICJ0eXBlIjoic3Ry aW5nIiwKICAgICAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICAgICJk ZXNjcmlwdGlvbiI6IlRoZSBjb3VudHJ5IG5hbWUgY29tcG9uZW50LiIsCiAgICAgICAgICAgICAg InJlYWRPbmx5IjpmYWxzZSwKICAgICAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAg ICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAgICAgIH0sCiAgICAgICAgICAgIHsKICAg ICAgICAgICAgICAibmFtZSI6InR5cGUiLAogICAgICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwK ICAgICAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICAgICJkZXNjcmlw dGlvbiI6IkEgbGFiZWwgaW5kaWNhdGluZyB0aGUgYXR0cmlidXRlJ3MgZnVuY3Rpb247IGUuZy4s ICd3b3JrJyBvciAnaG9tZScuIiwKICAgICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAg ICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImNhc2VFeGFjdCI6ZmFs c2UsCiAgICAgICAgICAgICAgImNhbm9uaWNhbFZhbHVlcyI6WyJ3b3JrIiwiaG9tZSIsIm90aGVy Il0KICAgICAgICAgICAgfQogICAgICAgICAgXQogICAgICAgIH0sCiAgICAgICAgewogICAgICAg ICAgIm5hbWUiOiJncm91cHMiLAogICAgICAgICAgInR5cGUiOiJjb21wbGV4IiwKICAgICAgICAg ICJtdWx0aVZhbHVlZCI6dHJ1ZSwKICAgICAgICAgICJkZXNjcmlwdGlvbiI6IkEgbGlzdCBvZiBn cm91cHMgdGhhdCB0aGUgdXNlciBiZWxvbmdzIHRvLCBlaXRoZXIgdGhvcm91Z2ggZGlyZWN0IG1l bWJlcnNoaXAsIG5lc3RlZCBncm91cHMsIG9yIGR5bmFtaWNhbGx5IGNhbGN1bGF0ZWQiLAogICAg ICAgICAgInJlYWRPbmx5Ijp0cnVlLAogICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAg ICAgICJjYXNlRXhhY3QiOmZhbHNlLAogICAgICAgICAgInN1YkF0dHJpYnV0ZXMiOlsKICAgICAg ICAgICAgewogICAgICAgICAgICAgICJuYW1lIjoidmFsdWUiLAogICAgICAgICAgICAgICJ0eXBl Ijoic3RyaW5nIiwKICAgICAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAg ICAgICJkZXNjcmlwdGlvbiI6IlRoZSBpZGVudGlmaWVyIG9mIHRoZSBVc2VyJ3MgZ3JvdXAuIiwK ICAgICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAgICAgICJyZXF1aXJlZCI6 ZmFsc2UsCiAgICAgICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICAgICAgfSwKICAg ICAgICAgICAgewogICAgICAgICAgICAgICJuYW1lIjoiJHJlZiIsCiAgICAgICAgICAgICAgInR5 cGUiOiJzdHJpbmciLAogICAgICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAg ICAgICAgImRlc2NyaXB0aW9uIjoiVGhlIFVSSSBvZiB0aGUgY29ycmVzcG9uZGluZyBHcm91cCBy ZXNvdXJjZSB0byB3aGljaCB0aGUgdXNlciBiZWxvbmdzIiwKICAgICAgICAgICAgICAicmVhZE9u bHkiOmZhbHNlLAogICAgICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAgICAg ImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICAgICAgfSwKICAgICAgICAgICAgewogICAgICAgICAg ICAgICJuYW1lIjoiZGlzcGxheSIsCiAgICAgICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAg ICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImRlc2NyaXB0aW9u IjoiQSBodW1hbiByZWFkYWJsZSBuYW1lLCBwcmltYXJpbHkgdXNlZCBmb3IgZGlzcGxheSBwdXJw b3Nlcy4gUkVBRC1PTkxZLiIsCiAgICAgICAgICAgICAgInJlYWRPbmx5Ijp0cnVlLAogICAgICAg ICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UK ICAgICAgICAgICAgfSwKICAgICAgICAgICAgewogICAgICAgICAgICAgICJuYW1lIjoidHlwZSIs CiAgICAgICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAgICAgICJtdWx0aVZhbHVl ZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImRlc2NyaXB0aW9uIjoiQSBsYWJlbCBpbmRpY2F0aW5n IHRoZSBhdHRyaWJ1dGUncyBmdW5jdGlvbjsgZS5nLiwgJ2RpcmVjdCcgb3IgJ2luZGlyZWN0Jy4i LAogICAgICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAgICAgInJlcXVpcmVk IjpmYWxzZSwKICAgICAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZSwKICAgICAgICAgICAgICAi Y2Fub25pY2FsVmFsdWVzIjpbImRpcmVjdCIsICJpbmRpcmVjdCJdCiAgICAgICAgICAgIH0sCiAg ICAgICAgICAgIHsKICAgICAgICAgICAgICAibmFtZSI6InByaW1hcnkiLAogICAgICAgICAgICAg ICJ0eXBlIjoiYm9vbGVhbiIsCiAgICAgICAgICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAg ICAgICAgICAgICAiZGVzY3JpcHRpb24iOiJBIEJvb2xlYW4gdmFsdWUgaW5kaWNhdGluZyB0aGUg J3ByaW1hcnknIG9yIHByZWZlcnJlZCBhdHRyaWJ1dGUgdmFsdWUgZm9yIHRoaXMgYXR0cmlidXRl LiBUaGUgcHJpbWFyeSBhdHRyaWJ1dGUgdmFsdWUgJ3RydWUnIE1VU1QgYXBwZWFyIG5vIG1vcmUg dGhhbiBvbmNlLiIsCiAgICAgICAgICAgICAgInJlYWRPbmx5IjpmYWxzZSwKICAgICAgICAgICAg ICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAg ICAgICAgIH1dCiAgICAgICAgfSwKICAgICAgICB7CiAgICAgICAgICAibmFtZSI6ImVudGl0bGVt ZW50cyIsCiAgICAgICAgICAidHlwZSI6ImNvbXBsZXgiLAogICAgICAgICAgIm11bHRpVmFsdWVk Ijp0cnVlLAogICAgICAgICAgImRlc2NyaXB0aW9uIjoiQSBsaXN0IG9mIGVudGl0bGVtZW50cyBm b3IgdGhlIFVzZXIgdGhhdCByZXByZXNlbnQgYSB0aGluZyB0aGUgVXNlciBoYXMuIiwKICAgICAg ICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAg ICAgImNhc2VFeGFjdCI6ZmFsc2UsCiAgICAgICAgICAic3ViQXR0cmlidXRlcyI6WwogICAgICAg ICAgICB7CiAgICAgICAgICAgICAgIm5hbWUiOiJ2YWx1ZSIsCiAgICAgICAgICAgICAgInR5cGUi OiJzdHJpbmciLAogICAgICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAg ICAgImRlc2NyaXB0aW9uIjoiVGhlIHZhbHVlIG9mIGFuIGVudGl0bGVtZW50LiIsCiAgICAgICAg ICAgICAgInJlYWRPbmx5IjpmYWxzZSwKICAgICAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAog ICAgICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAgICAgIH0sCiAgICAgICAgICAg IHsKICAgICAgICAgICAgICAibmFtZSI6ImRpc3BsYXkiLAogICAgICAgICAgICAgICJ0eXBlIjoi c3RyaW5nIiwKICAgICAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICAg ICJkZXNjcmlwdGlvbiI6IkEgaHVtYW4gcmVhZGFibGUgbmFtZSwgcHJpbWFyaWx5IHVzZWQgZm9y IGRpc3BsYXkgcHVycG9zZXMuIFJFQUQtT05MWS4iLAogICAgICAgICAgICAgICJyZWFkT25seSI6 dHJ1ZSwKICAgICAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgICAgICJjYXNl RXhhY3QiOmZhbHNlCiAgICAgICAgICAgIH0sCiAgICAgICAgICAgIHsKICAgICAgICAgICAgICAi bmFtZSI6InR5cGUiLAogICAgICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAg ICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICAgICJkZXNjcmlwdGlvbiI6IkEgbGFi ZWwgaW5kaWNhdGluZyB0aGUgYXR0cmlidXRlJ3MgZnVuY3Rpb24uIiwKICAgICAgICAgICAgICAi cmVhZE9ubHkiOmZhbHNlLAogICAgICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAg ICAgICAgImNhc2VFeGFjdCI6ZmFsc2UsCiAgICAgICAgICAgICAgImNhbm9uaWNhbFZhbHVlcyI6 W10KICAgICAgICAgICAgfSwKICAgICAgICAgICAgewogICAgICAgICAgICAgICJuYW1lIjoicHJp bWFyeSIsCiAgICAgICAgICAgICAgInR5cGUiOiJib29sZWFuIiwKICAgICAgICAgICAgICAibXVs dGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICAgICJkZXNjcmlwdGlvbiI6IkEgQm9vbGVhbiB2 YWx1ZSBpbmRpY2F0aW5nIHRoZSAncHJpbWFyeScgb3IgcHJlZmVycmVkIGF0dHJpYnV0ZSB2YWx1 ZSBmb3IgdGhpcyBhdHRyaWJ1dGUuIFRoZSBwcmltYXJ5IGF0dHJpYnV0ZSB2YWx1ZSAndHJ1ZScg TVVTVCBhcHBlYXIgbm8gbW9yZSB0aGFuIG9uY2UuIiwKICAgICAgICAgICAgICAicmVhZE9ubHki OmZhbHNlLAogICAgICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImNh c2VFeGFjdCI6ZmFsc2UKICAgICAgICAgICAgfV0KICAgICAgICB9LAogICAgICAgIHsKICAgICAg ICAgICJuYW1lIjoicm9sZXMiLAogICAgICAgICAgInR5cGUiOiJjb21wbGV4IiwKICAgICAgICAg ICJtdWx0aVZhbHVlZCI6dHJ1ZSwKICAgICAgICAgICJkZXNjcmlwdGlvbiI6IkEgbGlzdCBvZiBy b2xlcyBmb3IgdGhlIFVzZXIgdGhhdCBjb2xsZWN0aXZlbHkgcmVwcmVzZW50IHdobyB0aGUgVXNl ciBpczsgZS5nLiwgJ1N0dWRlbnQnLCAnRmFjdWx0eScuIiwKICAgICAgICAgICJyZWFkT25seSI6 ZmFsc2UsCiAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgImNhc2VFeGFjdCI6 ZmFsc2UsCiAgICAgICAgICAic3ViQXR0cmlidXRlcyI6WwogICAgICAgICAgICB7CiAgICAgICAg ICAgICAgIm5hbWUiOiJ2YWx1ZSIsCiAgICAgICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAg ICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImRlc2NyaXB0aW9u IjoiVGhlIHZhbHVlIG9mIGEgcm9sZS4iLAogICAgICAgICAgICAgICJyZWFkT25seSI6ZmFsc2Us CiAgICAgICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICAiY2FzZUV4YWN0 IjpmYWxzZQogICAgICAgICAgICB9LAogICAgICAgICAgICB7CiAgICAgICAgICAgICAgIm5hbWUi OiJkaXNwbGF5IiwKICAgICAgICAgICAgICAidHlwZSI6InN0cmluZyIsCiAgICAgICAgICAgICAg Im11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAgICAgICAiZGVzY3JpcHRpb24iOiJBIGh1bWFu IHJlYWRhYmxlIG5hbWUsIHByaW1hcmlseSB1c2VkIGZvciBkaXNwbGF5IHB1cnBvc2VzLiBSRUFE LU9OTFkuIiwKICAgICAgICAgICAgICAicmVhZE9ubHkiOnRydWUsCiAgICAgICAgICAgICAgInJl cXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZQogICAgICAgICAg ICB9LAogICAgICAgICAgICB7CiAgICAgICAgICAgICAgIm5hbWUiOiJ0eXBlIiwKICAgICAgICAg ICAgICAidHlwZSI6InN0cmluZyIsCiAgICAgICAgICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwK ICAgICAgICAgICAgICAiZGVzY3JpcHRpb24iOiJBIGxhYmVsIGluZGljYXRpbmcgdGhlIGF0dHJp YnV0ZSdzIGZ1bmN0aW9uLiIsCiAgICAgICAgICAgICAgInJlYWRPbmx5IjpmYWxzZSwKICAgICAg ICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNl LAogICAgICAgICAgICAgICJjYW5vbmljYWxWYWx1ZXMiOltdCiAgICAgICAgICAgIH0sCiAgICAg ICAgICAgIHsKICAgICAgICAgICAgICAibmFtZSI6InByaW1hcnkiLAogICAgICAgICAgICAgICJ0 eXBlIjoiYm9vbGVhbiIsCiAgICAgICAgICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAg ICAgICAgICAiZGVzY3JpcHRpb24iOiJBIEJvb2xlYW4gdmFsdWUgaW5kaWNhdGluZyB0aGUgJ3By aW1hcnknIG9yIHByZWZlcnJlZCBhdHRyaWJ1dGUgdmFsdWUgZm9yIHRoaXMgYXR0cmlidXRlLiBU aGUgcHJpbWFyeSBhdHRyaWJ1dGUgdmFsdWUgJ3RydWUnIE1VU1QgYXBwZWFyIG5vIG1vcmUgdGhh biBvbmNlLiIsCiAgICAgICAgICAgICAgInJlYWRPbmx5IjpmYWxzZSwKICAgICAgICAgICAgICAi cmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAg ICAgIH1dCiAgICAgICAgfSwKICAgICAgICB7CiAgICAgICAgICAibmFtZSI6Ing1MDlDZXJ0aWZp Y2F0ZXMiLAogICAgICAgICAgInR5cGUiOiJjb21wbGV4IiwKICAgICAgICAgICJtdWx0aVZhbHVl ZCI6dHJ1ZSwKICAgICAgICAgICJkZXNjcmlwdGlvbiI6IkEgbGlzdCBvZiBjZXJ0aWZpY2F0ZXMg aXNzdWVkIHRvIHRoZSBVc2VyLiIsCiAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAg ICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlLAogICAgICAg ICAgInN1YkF0dHJpYnV0ZXMiOlsKICAgICAgICAgICAgewogICAgICAgICAgICAgICJuYW1lIjoi dmFsdWUiLAogICAgICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAgICAibXVs dGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICAgICJkZXNjcmlwdGlvbiI6IlRoZSB2YWx1ZSBv ZiBhIFg1MDkgY2VydGlmaWNhdGUuIiwKICAgICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAog ICAgICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImNhc2VFeGFjdCI6 ZmFsc2UKICAgICAgICAgICAgfSwKICAgICAgICAgICAgewogICAgICAgICAgICAgICJuYW1lIjoi ZGlzcGxheSIsCiAgICAgICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAgICAgICJt dWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImRlc2NyaXB0aW9uIjoiQSBodW1hbiBy ZWFkYWJsZSBuYW1lLCBwcmltYXJpbHkgdXNlZCBmb3IgZGlzcGxheSBwdXJwb3Nlcy4gUkVBRC1P TkxZLiIsCiAgICAgICAgICAgICAgInJlYWRPbmx5Ijp0cnVlLAogICAgICAgICAgICAgICJyZXF1 aXJlZCI6ZmFsc2UsCiAgICAgICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICAgICAg fSwKICAgICAgICAgICAgewogICAgICAgICAgICAgICJuYW1lIjoidHlwZSIsCiAgICAgICAgICAg ICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAg ICAgICAgICAgICAgImRlc2NyaXB0aW9uIjoiQSBsYWJlbCBpbmRpY2F0aW5nIHRoZSBhdHRyaWJ1 dGUncyBmdW5jdGlvbi4iLAogICAgICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAg ICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZSwK ICAgICAgICAgICAgICAiY2Fub25pY2FsVmFsdWVzIjpbXQogICAgICAgICAgICB9LAogICAgICAg ICAgICB7CiAgICAgICAgICAgICAgIm5hbWUiOiJwcmltYXJ5IiwKICAgICAgICAgICAgICAidHlw ZSI6ImJvb2xlYW4iLAogICAgICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAg ICAgICAgImRlc2NyaXB0aW9uIjoiQSBCb29sZWFuIHZhbHVlIGluZGljYXRpbmcgdGhlICdwcmlt YXJ5JyBvciBwcmVmZXJyZWQgYXR0cmlidXRlIHZhbHVlIGZvciB0aGlzIGF0dHJpYnV0ZS4gVGhl IHByaW1hcnkgYXR0cmlidXRlIHZhbHVlICd0cnVlJyBNVVNUIGFwcGVhciBubyBtb3JlIHRoYW4g b25jZS4iLAogICAgICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAgICAgInJl cXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZQogICAgICAgICAg ICB9XQogICAgICAgIH0KICAgICAgXSwKICAgICAibWV0YSI6IHsKICAgICAgICJyZXNvdXJjZVR5 cGUiOiAiU2NoZW1hIiwKICAgICAgICJjcmVhdGVkIjogIjIwMTAtMDEtMjNUMDQ6NTY6MjJaIiwK ICAgICAgICJsYXN0TW9kaWZpZWQiOiAiMjAxMS0wNS0xM1QwNDo0MjozNFoiLAogICAgICAgInZl cnNpb24iOiAiV1wvXCIzNjk0ZTA1ZTlkZmY1OTZcIiIsCiAgICAgICAibG9jYXRpb24iOiAiaHR0 cHM6Ly9leGFtcGxlLmNvbS92MS9TY2hlbWFzL3VybjpzY2ltOnNjaGVtYXM6Y29yZToyLjA6VXNl ciIKICAgICB9CiAgIH0= --e89a8f2353a7aff40604e6f81efc-- From swm16@psu.edu Sun Sep 22 09:57:00 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D3521F979E for ; Sun, 22 Sep 2013 09:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPgxQrAe1QkJ for ; Sun, 22 Sep 2013 09:56:54 -0700 (PDT) Received: from tr22g10.aset.psu.edu (tr22g10.aset.psu.edu [146.186.149.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4852B21F9DD6 for ; Sun, 22 Sep 2013 09:56:44 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr22g10.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r8MGugoN3342584 for ; Sun, 22 Sep 2013 12:56:42 -0400 Date: Sun, 22 Sep 2013 12:56:42 -0400 (EDT) From: Steve Moyer To: scim@ietf.org Message-ID: <1252987930.1865553.1379869002643.JavaMail.zimbra@psu.edu> In-Reply-To: <1980541291.1865335.1379868948773.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.197.15.150] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF23 (Mac)/8.0.4_GA_5737) Thread-Topic: SCIM meet-up at JavaOne Thread-Index: Nj4StxmKtXeb3wFh8ShSuFNNPWmfDA== X-Virus-Scanned: by amavisd-new Subject: [scim] SCIM meet-up at JavaOne X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Steve Moyer List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 16:57:01 -0000 If anyone else on the SCIM mailing list is attending JavaOne, Oracle OpenWorld or the MySQL conference in San Francisco this week, it would be nice to get together and talk about how SCIM is being used, will be used in the future. I'm specifically interested in what use-cases work well and which are known to be problematic. Please respond to this thread if you're interested and I'll attempt to mail everyone to arrange a date/time and place. Hope to see you here! Steve From swm16@psu.edu Sun Sep 22 10:00:55 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2827211E80FD for ; Sun, 22 Sep 2013 10:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSoShJF2S4Uo for ; Sun, 22 Sep 2013 10:00:47 -0700 (PDT) Received: from tr21g10.aset.psu.edu (tr21g10.aset.psu.edu [146.186.149.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD5A21F9C46 for ; Sun, 22 Sep 2013 10:00:47 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr21g10.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r8MH0kMT3326112 for ; Sun, 22 Sep 2013 13:00:46 -0400 Date: Sun, 22 Sep 2013 13:00:46 -0400 (EDT) From: Steve Moyer To: scim@ietf.org Message-ID: <973985158.1867189.1379869246338.JavaMail.zimbra@psu.edu> In-Reply-To: <1090203604.1866221.1379869127958.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.197.15.150] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF23 (Mac)/8.0.4_GA_5737) Thread-Topic: schema files in JSON format Thread-Index: NCLLbWn+fslx4JRVwc/y7k+F7ec13w== X-Virus-Scanned: by amavisd-new Subject: [scim] [SCIM] schema files in JSON format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Steve Moyer List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 17:00:55 -0000 I've been thinking about doing exactly what you've done, and I think there's value in the community adopting the schemas for the objects defined in the specifications as addendums to the specifications themselves, as well as providing a standard location for these files for each released version of the specification. For those who are generating code from schema definitions, having these schemas (by version) available at a constant location could be invaluable. Thanks for putting this together! Steve From kelly.grizzle@sailpoint.com Mon Sep 23 06:17:59 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAD921F9FB5 for ; Mon, 23 Sep 2013 06:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDE3XFRNTnVE for ; Mon, 23 Sep 2013 06:17:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bn1lp0156.outbound.protection.outlook.com [207.46.163.156]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB3A21F9F86 for ; Mon, 23 Sep 2013 06:17:54 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 23 Sep 2013 13:17:46 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.126]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.34]) with mapi id 15.00.0775.005; Mon, 23 Sep 2013 13:17:45 +0000 From: Kelly Grizzle To: Kiran Ayyagari , "scim@ietf.org" Thread-Topic: [scim] [SCIM] schema files in JSON format Thread-Index: AQHOt5BIMGrL/aRhIk+I89rWECdqs5nTTj9A Date: Mon, 23 Sep 2013 13:17:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 23D0777C0054F223D078C9 x-originating-ip: [72.182.10.254] x-forefront-prvs: 09781D4C35 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(47976001)(83072001)(47446002)(63696002)(80022001)(65816001)(74502001)(59766001)(74366001)(19300405004)(81542001)(56776001)(49866001)(47736001)(74662001)(54316002)(31966008)(77982001)(81342001)(80976001)(56816003)(76482001)(50986001)(81816001)(69226001)(66066001)(76796001)(15975445006)(4396001)(51856001)(74706001)(33646001)(74876001)(46102001)(54356001)(16236675002)(53806001)(19609705001)(77096001)(81686001)(16601075003)(76786001)(15202345003)(76576001)(19580395003)(83322001)(74316001)(19580405001)(79102001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:72.182.10.254; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_d2ecc86b33244281ad316429aad2e434BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] [SCIM] schema files in JSON format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:17:59 -0000 --_000_d2ecc86b33244281ad316429aad2e434BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These are great! Thank you, Kiran. I will attach these to issue #44 (http://trac.tools.ietf.org/wg/scim/trac/t= icket/44). I'm not sure whether these should somehow be included with the = I-D's as well or if they should just go on the website. Regarding employeeNumber, IMO this should be optional. I can imagine a sce= nario where a new employee is onboarded and gets created with a manager, et= c... but they do not yet have an employee number assigned. REQUIRED is sim= ilar to a database NOT NULL constraint, and I think it is a bit too strong = for this case. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kir= an Ayyagari Sent: Sunday, September 22, 2013 7:34 AM To: scim@ietf.org Subject: [scim] [SCIM] schema files in JSON format I was trying to create schema files for each resource type and found that the normative example(section 12.7) of core User schema omits several attributes. I am not sure if this was done intentionally. I am attaching the schema files for User, Entrerprise user and Group resour= ces. It would be great if they can be made available under the resources section= of SCIM website. Finally, should the 'employeeNumber' attribute of Enterprise user be made a REQUIRED attribute? -- Kiran Ayyagari http://keydap.com --_000_d2ecc86b33244281ad316429aad2e434BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These are great!  Th= ank you, Kiran.

 <= /p>

I will attach these to is= sue #44 (http= ://trac.tools.ietf.org/wg/scim/trac/ticket/44).  I’m not sure whether these should somehow be included with the I-D’s as well= or if they should just go on the website.

 <= /p>

Regarding employeeNumber,= IMO this should be optional.  I can imagine a scenario where a new em= ployee is onboarded and gets created with a manager, etc… but they do not yet have an employee number assigned.  REQUIRED is simila= r to a database NOT NULL constraint, and I think it is a bit too strong for= this case.

 <= /p>

--Kelly=

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kiran Ayyagari
Sent: Sunday, September 22, 2013 7:34 AM
To: scim@ietf.org
Subject: [scim] [SCIM] schema files in JSON format=

 

I was trying to create schema files for each resourc= e type and found

that the normative example(section 12.7) of core Use= r schema omits
several attributes. I am not sure if this was done intentionally.


I am attaching the schema files for User, Entrerprise user and Group resour= ces.

It would be great if they can be made available unde= r the resources section of

SCIM website.

Finally, should the 'employeeNumber' attribute of En= terprise user be made

a REQUIRED attribute?=


--
Kiran Ayyagari
http://keydap.com =

--_000_d2ecc86b33244281ad316429aad2e434BN1PR04MB392namprd04pro_-- From ayyagarikiran@gmail.com Mon Sep 23 07:23:09 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A957921F92DA for ; Mon, 23 Sep 2013 07:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztMOkG3Cd0Oh for ; Mon, 23 Sep 2013 07:23:08 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3371A21F92B8 for ; Mon, 23 Sep 2013 07:23:08 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hj3so2348549wib.7 for ; Mon, 23 Sep 2013 07:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=O8VOUwEgLV69+rJZS8Sokqu+wA2WsFyT2OSkFAVBcts=; b=riP4cm+aWFSz9e45TPac68x6Kg0Ypy5UkJ6JzvgTaUNWxZTmRY+oNgb3uEk8OUWG1A nB64co+FIWlxDDXVPKRtGZmIrIcfSiByKpYyiaC4nWOhcqhYGCOLuY2fa9RPK5B/Si5V 9IMiUjibCTBTRLx9rl7u0S2DfzYpmZ4UtUxOAX+4cOWac+zPwurtWulB7xW3ZloIETGb C/CWfmO/J28mOlyPKjfrJxjh0Un1WQOKXTuCnKfXJazXw8ibZLQXAXVRYhD6tr15fvil ze6Acc2u5adv/ww/qHdJRiBTs+MS6kbyl6umjTdKggyAXF0FfMl8rMg7VMx+/Ziuoun9 Kkow== MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr17253265wjc.7.1379946186373; Mon, 23 Sep 2013 07:23:06 -0700 (PDT) Sender: ayyagarikiran@gmail.com Received: by 10.216.245.200 with HTTP; Mon, 23 Sep 2013 07:23:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Sep 2013 19:53:06 +0530 X-Google-Sender-Auth: FKs6xZsPFv4n_VCJ0y1La4keg_Y Message-ID: From: Kiran Ayyagari To: Kelly Grizzle Content-Type: multipart/alternative; boundary=089e0141a0ae3fdd1d04e70dc25f Cc: "scim@ietf.org" , Kiran Ayyagari Subject: Re: [scim] [SCIM] schema files in JSON format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 14:23:09 -0000 --089e0141a0ae3fdd1d04e70dc25f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Sep 23, 2013 at 6:47 PM, Kelly Grizzle wrote: > These are great! Thank you, Kiran.**** > > ** ** > > I will attach these to issue #44 ( > http://trac.tools.ietf.org/wg/scim/trac/ticket/44). I=92m not sure wheth= er > these should somehow be included with the I-D=92s as well or if they shou= ld > just go on the website.**** > > ** > I have few more changes to these schemas will send them after updating > ** > > Regarding employeeNumber, IMO this should be optional. I can imagine a > scenario where a new employee is onboarded and gets created with a manage= r, > etc=85 but they do not yet have an employee number assigned. REQUIRED is > similar to a database NOT NULL constraint, and I think it is a bit too > strong for this case.**** > > ** > ok, makes sense thanks Kelly > ** > > --Kelly**** > > ** ** > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Kiran Ayyagari > *Sent:* Sunday, September 22, 2013 7:34 AM > *To:* scim@ietf.org > *Subject:* [scim] [SCIM] schema files in JSON format**** > > ** ** > > I was trying to create schema files for each resource type and found**** > > that the normative example(section 12.7) of core User schema omits > several attributes. I am not sure if this was done intentionally.**** > > > I am attaching the schema files for User, Entrerprise user and Group > resources.**** > > It would be great if they can be made available under the resources > section of**** > > SCIM website.**** > > Finally, should the 'employeeNumber' attribute of Enterprise user be made= * > *** > > a REQUIRED attribute?**** > > > -- > Kiran Ayyagari > http://keydap.com **** > --=20 Kiran Ayyagari http://keydap.com --089e0141a0ae3fdd1d04e70dc25f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Mon, Sep 23, 2013 at 6:47 PM, Kelly Grizzle &l= t;kelly.gr= izzle@sailpoint.com> wrote:

These are great!=A0 Thank= you, Kiran.

=A0<= /p>

I will attach these to is= sue #44 (http://trac.tools.ietf.org/wg/scim/trac/ticket/44).=A0 I= =92m not sure whether these should somehow be included with the I-D=92s as well or = if they should just go on the website.

=A0

I have few more changes to these schemas will sen= d them after updating

=

Regarding employeeNumber,= IMO this should be optional.=A0 I can imagine a scenario where a new emplo= yee is onboarded and gets created with a manager, etc=85 but they do not yet have an employee number assigned.=A0 REQUIRED is similar t= o a database NOT NULL constraint, and I think it is a bit too strong for th= is case.

=A0

ok, makes sense

thanks Kelly

=

--Kelly

=A0<= /p>

From: scim-bounces@ietf.org [mailto:scim-= bounces@ietf.org] On Behalf Of Kiran Ayyagari
Sent: Sunday, September 22, 2013 7:34 AM
To: scim@ietf.org=
Subject: [scim] [SCIM] schema files in JSON format

=A0

I was trying to create schema files for each resourc= e type and found

that the normative example(section 12.7) of core Use= r schema omits
several attributes. I am not sure if this was done intentionally.=


I am attaching the schema files for User, Entrerprise user and Group resour= ces.

It would be great if they can be made available unde= r the resources section of

SCIM website.<= u>

Finally, should the 'employeeNumber' attribu= te of Enterprise user be made

a REQUIRED attribute?=


--
Kiran Ayyagari
http://keydap.com




--
Kiran Ayyagari
http://keydap.com
--089e0141a0ae3fdd1d04e70dc25f-- From t.rossner@tarent.de Wed Sep 25 06:07:53 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9518C11E8115 for ; Wed, 25 Sep 2013 06:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2PY1wYcyk6c for ; Wed, 25 Sep 2013 06:07:48 -0700 (PDT) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by ietfa.amsl.com (Postfix) with ESMTP id 11B5411E810F for ; Wed, 25 Sep 2013 06:07:39 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id e11so2266062bkh.11 for ; Wed, 25 Sep 2013 06:07:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=BBJtyUti/cZoqT7rwzSQnP7tV1l/wz/R6pwAnoLKd8c=; b=NQy6GA7ym8EfyCIkk+k/0JatjrzNKjOZDHjid7WJtSjn3S8yfndCFd6AZoPU12VCnM Y6k9oXiYY4jrVpg0S+8ktAPj6JOxrG4ENj69ufiISYUJuqv/UJXKuuuIZWz2K+bpCoO/ M84Oh1ubptSTOp1OaZlsSvnSyk2v4SbvkIXS+9VSdUJp33sIMTGaYnSdDKL4oY1S/pbj osOiseVErJgCfXQ/uKAxSVRWj2b1XofGhhQqZa4G1MO5GXxyrPiFDW3X3WJltX6Gzzhk NbKGisXtkhBCTgJMzmCZDLgG5Tpakt1JEbWD2RTIroYRfuiL2zgX8ZDxTjtTVBovNAsr kU0g== X-Gm-Message-State: ALoCoQmvJgGk998LkJZQAldGkwYVuq22kbvnWGIzQwkzPPPxuu1QzpNCnY6f+256hVE770bEMASD X-Received: by 10.204.233.129 with SMTP id jy1mr1904748bkb.27.1380114457158; Wed, 25 Sep 2013 06:07:37 -0700 (PDT) Received: from [172.26.15.200] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id nv4sm14225652bkb.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 06:07:36 -0700 (PDT) Message-ID: <5242E013.9070902@tarent.de> Date: Wed, 25 Sep 2013 15:07:31 +0200 From: =?ISO-8859-15?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: scim@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [scim] Introduction & question X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 13:07:53 -0000 Dear SCIM folks, even that I already sent a couple of mails in this list and I'm a regular reader, I would like to quickly introduce myself. I'm Thorsten :) I'm working with osiam.org where we develop a MIT licenced implementation of SCIMv2. Unfortuantely I wasn't able to come to the IETF Meeting in Berlin to meet some of you in person as I just moved into a new, not yet ready, home the Monday after the Berlin-Meeting. Currently we hope to have a kitchen in there by x-mas, so still a lot to do for me beside osiam.org. ;-) I'll catch up with the latest development of the currently existing tickets and may come up with some comments in this list in the next days/weeks. But first of all I have question: When I look into most of the complex/multi-value attributes (e.g. emails, addresses, phoneNumbers) SCIM does not require the values below to be unique (within the user record). How should a PATCH based "delete" of a certain email-address work, when it's possible to have two identical entries? Would a solution using $refs for each item of a multi-value attribute be covered by the standard or are there other ways to handle the problem? Thanks Thorsten From davel@uchicago.edu Wed Sep 25 07:52:42 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3200F21F9E53 for ; Wed, 25 Sep 2013 07:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jyd5en8ppBae for ; Wed, 25 Sep 2013 07:52:27 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id AB8CA21F9DC9 for ; Wed, 25 Sep 2013 07:52:27 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wm4so6796193obc.2 for ; Wed, 25 Sep 2013 07:52:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Vhc05XzhBIQHaU88x0hPhhkXzZQTNypPL3GiKdEeoPU=; b=I/kKLNLGZh0iVThTR8b7yJPlboAl9e61K9ArBx6oTaYeX3gSSZshb3UOUUuYf+RDqE aDUoJn23ece2AHr6eLou8XVtsdZiyR4d/mbJGazDiAKEclEYDy1CLTtPrqth52zgk7+T Mp7577TEleExK9i1pg0kGKU+Z1zt4xDdJ8p4rD+e0bJPAecRVWs0K1/y7V5tS5xxLKkJ 8ZcSPLp7eqVxkklmLghFkL+1DGe8pFG8MsuvDP9vvmvT/+jEJSdy2TbshbHz4DtECk0e ndJRfXKv1NPWGLV01xyzjSPwUDfdOTm9bD6aPlm77u4QzfeJvOsAUp6CrvoYS/85py9K sCWQ== X-Gm-Message-State: ALoCoQkUVRfYbMnf8KJ/2T6WVNijFak1kWpkf+a4CK4CfpC2rcR8h1jcUqDPogUhuewAirZkUpIz MIME-Version: 1.0 X-Received: by 10.182.99.231 with SMTP id et7mr30873461obb.10.1380120745934; Wed, 25 Sep 2013 07:52:25 -0700 (PDT) Received: by 10.60.132.136 with HTTP; Wed, 25 Sep 2013 07:52:25 -0700 (PDT) Date: Wed, 25 Sep 2013 08:52:25 -0600 Message-ID: From: David Langenberg To: scim@ietf.org Content-Type: multipart/alternative; boundary=089e0158a92ecf1aac04e736665d Subject: [scim] Membership attributes expressed in a SCIM group X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 14:53:56 -0000 --089e0158a92ecf1aac04e736665d Content-Type: text/plain; charset=ISO-8859-1 Hello All, I'm presently engaged in adding SCIM support to the Internet2's Grouper product. One of the use-cases we're trying to address is to emit group membership attributes over SCIM. The more concrete case is decorating who is the manager of the group within the group's membership list. I'm trying to figure out a way to do that within the standard, but it seems that there is no way to do that at present. If there is a way, would somebody please point me in the right direction, else, what would be the process for getting it added? Thanks Dave -- David Langenberg Identity & Access Management The University of Chicago --089e0158a92ecf1aac04e736665d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello All,

I'm presently engaged in= adding SCIM support to the Internet2's Grouper product. =A0One of the = use-cases we're trying to address is to emit group membership attribute= s over SCIM. =A0The more concrete case is decorating who is the manager of = the group within the group's membership list. =A0I'm trying to figu= re out a way to do that within the standard, but it seems that there is no = way to do that at present. =A0If there is a way, would somebody please poin= t me in the right direction, else, what would be the process for getting it= added?

Thanks

Dave

--
David Langenberg
Identity & Access Management
T= he University of Chicago
--089e0158a92ecf1aac04e736665d-- From pradtke@stanford.edu Wed Sep 25 09:25:15 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E5921F9D94 for ; Wed, 25 Sep 2013 09:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp6BYA5UVf-W for ; Wed, 25 Sep 2013 09:24:59 -0700 (PDT) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id A734721F9D30 for ; Wed, 25 Sep 2013 09:24:54 -0700 (PDT) Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8E999340F1A; Wed, 25 Sep 2013 09:24:52 -0700 (PDT) Received: from radtke.local (c-50-131-40-145.hsd1.ca.comcast.net [50.131.40.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pradtke) by smtp.stanford.edu (Postfix) with ESMTPSA id 1531F340BCC; Wed, 25 Sep 2013 09:24:52 -0700 (PDT) Message-ID: <52430E70.8070206@stanford.edu> Date: Wed, 25 Sep 2013 09:25:20 -0700 From: Patrick Radtke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Langenberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] Membership attributes expressed in a SCIM group X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:25:15 -0000 Members is a multi-valued attribute so you could use any of the pre-defined attributes listed here http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-3.2 or add your own through an extension. IMHO, 'type' might be suitable for this. It is defined as "A label indicating the attribute's function". So you could do "members": [ { "value": "2819c223-7f76-453a-919d-413861904646", "$ref": "https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646", "display": "Babs Jensen", "type": "manager" }, { "value": "902c246b-6245-4190-8e05-00816be7344a", "$ref": "https://example.com/v1/Users/902c246b-6245-4190-8e05-00816be7344a", "display": "Mandy Pepperidge" } ] -Patrick On 9/25/13 7:52 AM, David Langenberg wrote: > Hello All, > > I'm presently engaged in adding SCIM support to the Internet2's Grouper > product. One of the use-cases we're trying to address is to emit group > membership attributes over SCIM. The more concrete case is decorating > who is the manager of the group within the group's membership list. I'm > trying to figure out a way to do that within the standard, but it seems > that there is no way to do that at present. If there is a way, would > somebody please point me in the right direction, else, what would be the > process for getting it added? > > Thanks > > Dave > > -- > David Langenberg > Identity & Access Management > The University of Chicago > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From ayyagarikiran@gmail.com Wed Sep 25 10:30:31 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E4A11E8122 for ; Wed, 25 Sep 2013 10:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.541 X-Spam-Level: X-Spam-Status: No, score=-0.541 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dG-3wT23cEbT for ; Wed, 25 Sep 2013 10:30:31 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6C65011E812B for ; Wed, 25 Sep 2013 10:30:27 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x55so6310127wes.24 for ; Wed, 25 Sep 2013 10:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=O2zN4MNF5jIw+Xx6ihldmM9/wDnDQTiiwWWvHhUphP0=; b=d5mb6YtK+5Sea/ycHs+ZxKa8e7WInukrXjuFYdW3iNVOStT1+p4Be1K7/7zJr2YkSU J/YrOZuxMGnk7TleJxBDN9udkKor04ElJHKF05tNcUJ2NJwPeGJxVH3Jnd+n3V4VoGez 1hkbJBVAGgcIBQrhgRW8YFF4+d1+W1aoHBg1C+0h1ruydCss75UPFvf95Vet7MpPc9bJ NmevBgogYkf5Z1zg3ZNwpQ5nrfSdbYws3gQznOy2XUX6a9HZDUB4uRuiVbbjutjDB5nj De2Z6sX1iWhwgIF5Z2Gu23OWCAp/nU45cYwTVZaC/YtXnn7KcgIta5DVvm5TdZrrCwZg lsEQ== MIME-Version: 1.0 X-Received: by 10.180.107.167 with SMTP id hd7mr23729875wib.13.1380130225009; Wed, 25 Sep 2013 10:30:25 -0700 (PDT) Sender: ayyagarikiran@gmail.com Received: by 10.216.245.200 with HTTP; Wed, 25 Sep 2013 10:30:24 -0700 (PDT) In-Reply-To: <52430E70.8070206@stanford.edu> References: <52430E70.8070206@stanford.edu> Date: Wed, 25 Sep 2013 23:00:24 +0530 X-Google-Sender-Auth: X0qnzvvsp3qiVB2UjijzvPO0zdg Message-ID: From: Kiran Ayyagari To: Patrick Radtke Content-Type: multipart/alternative; boundary=e89a8f2353a7ce3c5a04e7389b77 Cc: David Langenberg , "scim@ietf.org" Subject: Re: [scim] Membership attributes expressed in a SCIM group X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 17:30:32 -0000 --e89a8f2353a7ce3c5a04e7389b77 Content-Type: text/plain; charset=ISO-8859-1 AFAIK, the only canonical types defined[1] for 'type' in this context are "User" and "Group". [1] http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-8 On Wed, Sep 25, 2013 at 9:55 PM, Patrick Radtke wrote: > Members is a multi-valued attribute so you could use any of the > pre-defined attributes listed here > > http://tools.ietf.org/html/**draft-ietf-scim-core-schema-**02#section-3.2 > > or add your own through an extension. > > IMHO, 'type' might be suitable for this. It is defined as "A label > indicating the attribute's function". So you could do > > "members": [ > { > "value": "2819c223-7f76-453a-919d-**413861904646", > "$ref": "https://example.com/v1/Users/**2819c223-7f76-453a-919d-* > *413861904646 > ", > "display": "Babs Jensen", > "type": "manager" > }, > { > "value": "902c246b-6245-4190-8e05-**00816be7344a", > "$ref": "https://example.com/v1/Users/**902c246b-6245-4190-8e05-* > *00816be7344a > ", > "display": "Mandy Pepperidge" > } > ] > > -Patrick > > > On 9/25/13 7:52 AM, David Langenberg wrote: > >> Hello All, >> >> I'm presently engaged in adding SCIM support to the Internet2's Grouper >> product. One of the use-cases we're trying to address is to emit group >> membership attributes over SCIM. The more concrete case is decorating >> who is the manager of the group within the group's membership list. I'm >> trying to figure out a way to do that within the standard, but it seems >> that there is no way to do that at present. If there is a way, would >> somebody please point me in the right direction, else, what would be the >> process for getting it added? >> >> Thanks >> >> Dave >> >> -- >> David Langenberg >> Identity & Access Management >> The University of Chicago >> >> >> ______________________________**_________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/**listinfo/scim >> >> > ______________________________**_________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/**listinfo/scim > -- Kiran Ayyagari http://keydap.com --e89a8f2353a7ce3c5a04e7389b77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
AFAIK, the only canonical types defined[1] for 'type&#= 39; in this context are "User" and "Group".


= [1] http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-= 8


On Wed,= Sep 25, 2013 at 9:55 PM, Patrick Radtke <pradtke@stanford.edu><= /span> wrote:
Members is a multi-valued attribute so you c= ould use any of the pre-defined attributes listed here

http://tools.ietf.org/html/draft-ietf-scim-= core-schema-02#section-3.2

or add your own through an extension.

IMHO, 'type' might be suitable for this. It is defined as "A l= abel indicating the attribute's function". So you could do

"members": [
=A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0"value": "2819c223-7f76-453a-919d-= 413861904646",
=A0 =A0 =A0 =A0 =A0"$ref": "https://exa= mple.com/v1/Users/2819c223-7f76-453a-919d-413861904646&qu= ot;,
=A0 =A0 =A0 =A0 =A0"display": "Babs Jensen",
=A0 =A0 =A0 =A0 =A0"type": "manager"
=A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0"value": "902c246b-6245-4190-8e05-= 00816be7344a",
=A0 =A0 =A0 =A0 =A0"$ref": "https://exa= mple.com/v1/Users/902c246b-6245-4190-8e05-00816be7344a&qu= ot;,
=A0 =A0 =A0 =A0 =A0"display": "Mandy Pepperidge"
=A0 =A0 =A0 =A0}
=A0 =A0 =A0]

-Patrick


On 9/25/13 7:52 AM, David Langenberg wrote:
Hello All,

I'm presently engaged in adding SCIM support to the Internet2's Gro= uper
product. =A0One of the use-cases we're trying to address is to emit gro= up
membership attributes over SCIM. =A0The more concrete case is decorating who is the manager of the group within the group's membership list. =A0= I'm
trying to figure out a way to do that within the standard, but it seems
that there is no way to do that at present. =A0If there is a way, would
somebody please point me in the right direction, else, what would be the process for getting it added?

Thanks

Dave

--
David Langenberg
Identity & Access Management
The University of Chicago


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


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



--
Kiran Ayyagari
http://keydap.com
--e89a8f2353a7ce3c5a04e7389b77-- From pradtke@stanford.edu Wed Sep 25 10:41:46 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2532F21F94FF for ; Wed, 25 Sep 2013 10:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODmEZGW+lHQI for ; Wed, 25 Sep 2013 10:41:41 -0700 (PDT) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id EE55D11E812C for ; Wed, 25 Sep 2013 10:41:37 -0700 (PDT) Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A1C51341228; Wed, 25 Sep 2013 10:41:32 -0700 (PDT) Received: from radtke.local (c-50-131-40-145.hsd1.ca.comcast.net [50.131.40.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pradtke) by smtp.stanford.edu (Postfix) with ESMTPSA id DD4E8340E96; Wed, 25 Sep 2013 10:41:30 -0700 (PDT) Message-ID: <52432067.6000401@stanford.edu> Date: Wed, 25 Sep 2013 10:41:59 -0700 From: Patrick Radtke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Kiran Ayyagari References: <52430E70.8070206@stanford.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Langenberg , "scim@ietf.org" Subject: Re: [scim] Membership attributes expressed in a SCIM group X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 17:41:46 -0000 I read that section 8 as User and Group members are read only - e.g. you can't add or modify a User or Group through the group membership. Elsewhere in the spec when it refers to canonical values for an attribute it says "Canonical Values". Anyhow, 3.1.1 String says "Additionally, when Canonical Values are specified Service Providers SHOULD conform to those values if appropriate, but MAY provide alternate String values to represent additional values." which sounds like the service provider is allowed to add additional values. -Patrick http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-3.1.1 On 9/25/13 10:30 AM, Kiran Ayyagari wrote: > AFAIK, the only canonical types defined[1] for 'type' in this context > are "User" and "Group". > > > [1] http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-8 > > > On Wed, Sep 25, 2013 at 9:55 PM, Patrick Radtke > wrote: > > Members is a multi-valued attribute so you could use any of the > pre-defined attributes listed here > > http://tools.ietf.org/html/__draft-ietf-scim-core-schema-__02#section-3.2 > > > or add your own through an extension. > > IMHO, 'type' might be suitable for this. It is defined as "A label > indicating the attribute's function". So you could do > > "members": [ > { > "value": "2819c223-7f76-453a-919d-__413861904646", > "$ref": > "https://example.com/v1/Users/__2819c223-7f76-453a-919d-__413861904646 > ", > "display": "Babs Jensen", > "type": "manager" > }, > { > "value": "902c246b-6245-4190-8e05-__00816be7344a", > "$ref": > "https://example.com/v1/Users/__902c246b-6245-4190-8e05-__00816be7344a > ", > "display": "Mandy Pepperidge" > } > ] > > -Patrick > > > On 9/25/13 7:52 AM, David Langenberg wrote: > > Hello All, > > I'm presently engaged in adding SCIM support to the Internet2's > Grouper > product. One of the use-cases we're trying to address is to > emit group > membership attributes over SCIM. The more concrete case is > decorating > who is the manager of the group within the group's membership > list. I'm > trying to figure out a way to do that within the standard, but > it seems > that there is no way to do that at present. If there is a way, > would > somebody please point me in the right direction, else, what > would be the > process for getting it added? > > Thanks > > Dave > > -- > David Langenberg > Identity & Access Management > The University of Chicago > > > _________________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/__listinfo/scim > > > > _________________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/__listinfo/scim > > > > > > -- > Kiran Ayyagari > http://keydap.com From ayyagarikiran@gmail.com Wed Sep 25 10:53:52 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE09021F9E8D for ; Wed, 25 Sep 2013 10:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxRljPcbxJFE for ; Wed, 25 Sep 2013 10:53:51 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id ABDF921F9D33 for ; Wed, 25 Sep 2013 10:53:49 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hm2so5850721wib.16 for ; Wed, 25 Sep 2013 10:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dRNmIbmYa8LDdCo9vt980D+v2PHTXE/OibjVxkAMHbo=; b=GxaKAwWA+tUbabG6KgS66BXS6PiKkJKOWa4fzSzoO5iPC8YixQKYazKcG7VLYIlAT4 hy/hQm6VzAh0QFM2IF+ylGnTnXx1TsJ7cEGaQErEy7eIjanDh6B4mkNGKMCYDDckhWp6 OyBtB3K9asnySOGs6dW20v2dBe4otV+TZJlmVP/RanfoyBa4xDADp7Kt+0VFLgZjawep vTxniWnYMn67OK4BHgVthHsmrTITowktwzaLFXVGIJGRHOEH7Yuo4r3ycTWXftMwT9op kQLI0K4G+lvteHknJ0kPT3Q89NgiqKc9kTb10cKCBOrnh/Ur0t0TPVZLyIkGx38iymRp raNw== MIME-Version: 1.0 X-Received: by 10.180.182.68 with SMTP id ec4mr23795544wic.40.1380131626551; Wed, 25 Sep 2013 10:53:46 -0700 (PDT) Sender: ayyagarikiran@gmail.com Received: by 10.216.245.200 with HTTP; Wed, 25 Sep 2013 10:53:46 -0700 (PDT) In-Reply-To: <52432067.6000401@stanford.edu> References: <52430E70.8070206@stanford.edu> <52432067.6000401@stanford.edu> Date: Wed, 25 Sep 2013 23:23:46 +0530 X-Google-Sender-Auth: WRT2lhcNAKb01KzgQj7hbBa-pZY Message-ID: From: Kiran Ayyagari To: Patrick Radtke Content-Type: multipart/alternative; boundary=047d7b66f59958123e04e738efe3 Cc: David Langenberg , Kiran Ayyagari , "scim@ietf.org" Subject: Re: [scim] Membership attributes expressed in a SCIM group X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 17:53:52 -0000 --047d7b66f59958123e04e738efe3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 25, 2013 at 11:11 PM, Patrick Radtke wrote: > I read that section 8 as User and Group members are read only - e.g. you > can't add or modify a User or Group through the group membership. > > Elsewhere in the spec when it refers to canonical values for an attribute > it says "Canonical Values". Anyhow, 3.1.1 String says > > "Additionally, when Canonical Values > are specified Service Providers SHOULD conform to those values if > appropriate, but MAY provide alternate String values to represent > additional values." > > which sounds like the service provider is allowed to add additional values. > yeap, didn't notice it, thanks for the pointer > > -Patrick > > http://tools.ietf.org/html/**draft-ietf-scim-core-schema-** > 02#section-3.1.1 > > > On 9/25/13 10:30 AM, Kiran Ayyagari wrote: > >> AFAIK, the only canonical types defined[1] for 'type' in this context >> are "User" and "Group". >> >> >> [1] http://tools.ietf.org/html/**draft-ietf-scim-core-schema-** >> 02#section-8 >> >> >> On Wed, Sep 25, 2013 at 9:55 PM, Patrick Radtke > > wrote: >> >> Members is a multi-valued attribute so you could use any of the >> pre-defined attributes listed here >> >> http://tools.ietf.org/html/__**draft-ietf-scim-core-schema-__** >> 02#section-3.2 >> >> > 02#section-3.2 >> > >> >> or add your own through an extension. >> >> IMHO, 'type' might be suitable for this. It is defined as "A label >> indicating the attribute's function". So you could do >> >> "members": [ >> { >> "value": "2819c223-7f76-453a-919d-__**413861904646", >> "$ref": >> "https://example.com/v1/Users/**__2819c223-7f76-453a-919d-__** >> 413861904646 >> >> > 413861904646 >> >", >> "display": "Babs Jensen", >> "type": "manager" >> }, >> { >> "value": "902c246b-6245-4190-8e05-__**00816be7344a", >> "$ref": >> "https://example.com/v1/Users/**__902c246b-6245-4190-8e05-__** >> 00816be7344a >> >> > 00816be7344a >> >", >> "display": "Mandy Pepperidge" >> } >> ] >> >> -Patrick >> >> >> On 9/25/13 7:52 AM, David Langenberg wrote: >> >> Hello All, >> >> I'm presently engaged in adding SCIM support to the Internet2's >> Grouper >> product. One of the use-cases we're trying to address is to >> emit group >> membership attributes over SCIM. The more concrete case is >> decorating >> who is the manager of the group within the group's membership >> list. I'm >> trying to figure out a way to do that within the standard, but >> it seems >> that there is no way to do that at present. If there is a way, >> would >> somebody please point me in the right direction, else, what >> would be the >> process for getting it added? >> >> Thanks >> >> Dave >> >> -- >> David Langenberg >> Identity & Access Management >> The University of Chicago >> >> >> ______________________________**___________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/scim >> >> > >> >> >> ______________________________**___________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/scim >> >> >> > >> >> >> >> >> -- >> Kiran Ayyagari >> http://keydap.com >> > > -- Kiran Ayyagari http://keydap.com --047d7b66f59958123e04e738efe3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 25, 2013 at 11:11 PM, Patrick Radtke = <pradtke@stanf= ord.edu> wrote:
I read that section 8 as = User and Group members are read only - e.g. you can't add or modify a U= ser or Group through the group membership.

Elsewhere in the spec when it refers to canonical values for an attribute i= t says "Canonical Values". Anyhow, 3.1.1 String says

"Additionally, when Canonical Values
=A0 =A0are specified Service Providers SHOULD conform to those values if =A0 =A0appropriate, but MAY provide alternate String values to represent =A0 =A0additional values."

which sounds like the service provider is allowed to add additional values.=
yeap, didn't notice it, thanks for the pointer

-Patrick

http://tools.ietf.org/html/draft-ietf-sci= m-core-schema-02#section-3.1.1


On 9/25/13 10:30 AM, Kiran Ayyagari wrote:
AFAIK, the only canonical types defined[1] for 'type' in this conte= xt
are "User" and "Group".


[1] http://tools.ietf.org/html/draft-ietf-sci= m-core-schema-02#section-8


On Wed, Sep 25, 2013 at 9:55 PM, Patrick Radtke <pradtke@stanford.edu
<mailto:pradtk= e@stanford.edu>> wrote:

=A0 =A0 Members is a multi-valued attribute so you could use any of the
=A0 =A0 pre-defined attributes listed here

=A0 =A0 http://tools.ietf.org/html/__dr= aft-ietf-scim-core-schema-__02#section-3.2

=A0 =A0 <http://tools.ietf.org/html/draf= t-ietf-scim-core-schema-02#section-3.2>

=A0 =A0 or add your own through an extension.

=A0 =A0 IMHO, 'type' might be suitable for this. It is defined as &= quot;A label
=A0 =A0 indicating the attribute's function". So you could do

=A0 =A0 "members": [
=A0 =A0 =A0 =A0 =A0 =A0 {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "value": "2819c223-7f76-453a-919= d-__413861904646",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "$ref":
=A0 =A0 "https://example.com/v1/Users/= __2819c223-7f76-453a-919d-__413861904646

=A0 =A0 <https://example.com/v1/Users/2819c2= 23-7f76-453a-919d-413861904646>",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "display": "Babs Jensen", =A0 =A0 =A0 =A0 =A0 =A0 =A0 "type": "manager"
=A0 =A0 =A0 =A0 =A0 =A0 },
=A0 =A0 =A0 =A0 =A0 =A0 {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "value": "902c246b-6245-4190-8e0= 5-__00816be7344a",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "$ref":
=A0 =A0 "https://example.com/v1/Users/= __902c246b-6245-4190-8e05-__00816be7344a
<= br> =A0 =A0 <https://example.com/v1/Users/902c24= 6b-6245-4190-8e05-00816be7344a>",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "display": "Mandy Pepperidge&quo= t;
=A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 ]

=A0 =A0 -Patrick


=A0 =A0 On 9/25/13 7:52 AM, David Langenberg wrote:

=A0 =A0 =A0 =A0 Hello All,

=A0 =A0 =A0 =A0 I'm presently engaged in adding SCIM support to the Int= ernet2's
=A0 =A0 =A0 =A0 Grouper
=A0 =A0 =A0 =A0 product. =A0One of the use-cases we're trying to addres= s is to
=A0 =A0 =A0 =A0 emit group
=A0 =A0 =A0 =A0 membership attributes over SCIM. =A0The more concrete case = is
=A0 =A0 =A0 =A0 decorating
=A0 =A0 =A0 =A0 who is the manager of the group within the group's memb= ership
=A0 =A0 =A0 =A0 list. =A0I'm
=A0 =A0 =A0 =A0 trying to figure out a way to do that within the standard, = but
=A0 =A0 =A0 =A0 it seems
=A0 =A0 =A0 =A0 that there is no way to do that at present. =A0If there is = a way,
=A0 =A0 =A0 =A0 would
=A0 =A0 =A0 =A0 somebody please point me in the right direction, else, what=
=A0 =A0 =A0 =A0 would be the
=A0 =A0 =A0 =A0 process for getting it added?

=A0 =A0 =A0 =A0 Thanks

=A0 =A0 =A0 =A0 Dave

=A0 =A0 =A0 =A0 --
=A0 =A0 =A0 =A0 David Langenberg
=A0 =A0 =A0 =A0 Identity & Access Management
=A0 =A0 =A0 =A0 The University of Chicago


=A0 =A0 =A0 =A0 _________________________________________________ =A0 =A0 =A0 =A0 scim mailing list
=A0 =A0 =A0 =A0 scim@iet= f.org <mailto:sci= m@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/scim
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/scim>=


=A0 =A0 _________________________________________________
=A0 =A0 scim mailing list
=A0 =A0 scim@ietf.org <mailto:scim@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/scim

=A0 =A0 <https://www.ietf.org/mailman/listinfo/scim>




--
Kiran Ayyagari
http://keydap.com




--
Kiran Ayyagari
http://keydap.com
--047d7b66f59958123e04e738efe3-- From phil.hunt@oracle.com Wed Sep 25 10:54:46 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457C211E80F3 for ; Wed, 25 Sep 2013 10:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLpIQ6HOnOHN for ; Wed, 25 Sep 2013 10:54:36 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 168E121F81FF for ; Wed, 25 Sep 2013 10:54:31 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8PHsUYP018647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Sep 2013 17:54:30 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8PHsTKe015782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Sep 2013 17:54:30 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8PHsTPp015768 for ; Wed, 25 Sep 2013 17:54:29 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Sep 2013 10:54:29 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_B23D11B0-212F-4F18-83EB-37927B8AEB76" Message-Id: Date: Wed, 25 Sep 2013 10:54:33 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [scim] Questions on read-only attribute handling in POST/PUT/PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 17:54:46 -0000 --Apple-Mail=_B23D11B0-212F-4F18-83EB-37927B8AEB76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'd like to discuss handling of read-only attributes in POST/PUT/PATCH: For example, the PUT operation appears to allows read-only attribute = appear to be written for the convenience of the client. > 3.3.1. Modifying with PUT >=20 >=20 >=20 > PUT performs a full update. Consumers must retrieve the entire > Resource and PUT the desired modifications as the operation > overwrites all previously stored data with the exception of the > password attribute. If the password attribute of the User resource > is unspecified, it should be left in-tact. Since this performs a > full update, Consumers MAY send read-only attributes of the = retrieved > resource and the Service Provider MUST ignore any read-only > attributes that are present in the payload of a PUT request. = Unless > otherwise specified a successful PUT operation returns a 200 OK > response code and the entire Resource within the response body, > enabling the Consumer to correlate the Consumer's and Provider's > views of the updated Resource. Example: Makes sense as a convenience so a SCIM client doesn't have to remove = read-only attributes from a GET response before using it for a PUT = request. So, this is a case where including read only attributes in the = request is allowed. Should the same could go for POST (create)?=20 Let's say I do a GET /Users/xxxx on a specific user which returns the = complete resource including all attributes in the GET response. Now I = just want to copy / modify that json response content and pass it to a = POST. Should clients be allowed to include read-only attributes like = clients can for PUT? Should PATCH exclude read-only attributes? A PATCH request should not include read-only attributes since it's a = partial resource update request. If we decide to support "immutable" attributes, should they be treated = the same way as read-only once set? With regards to update responses: When a User is patched should it return the entire new object?=20 I notice that PATCH is unclear on what is returned on a successful = response. In one example it says the server can return nothing or = everything in non-normative text. I guess the issue here is that when = you PATCH a large group, you don't want the whole group returned. What = about for other objects like Users? What attributes are returned on success? As for what attributes are returned on a PUT/POST/PATCH successful = operation, I would suggest we return the "default" attributes -- the = ones you get when performing a query with no attributes list. That = said, one could argue etag and timestamp attributes should be returned = too. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_B23D11B0-212F-4F18-83EB-37927B8AEB76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I'd = like to discuss handling of read-only attributes in = POST/PUT/PATCH:

For example, the PUT operation = appears to allows read-only attribute appear to be written for the = convenience of the client.
3=
.3.1.  Modifying with PUT


   PUT performs a full update.  Consumers must retrieve the entire
   Resource and PUT the desired modifications as the operation
   overwrites all previously stored data with the exception of =
the
   password attribute.  If the password =
attribute of the User resource
   is unspecified, it should be left in-tact.  Since this performs a
   full update, Consumers MAY send read-only attributes of the retrieved
   resource and the Service Provider MUST ignore any read-only
   attributes that are present in the payload of a PUT request.  =
Unless
   otherwise specified a successful PUT operation returns a 200 OK
   response code and the entire Resource within the response body,
   enabling the Consumer to correlate the Consumer's and Provider's
   views of the updated Resource.  =
Example:
Makes sense as a convenience = so a SCIM client doesn't have to remove read-only attributes from a GET = response before using it for a PUT request. So, this is a case where = including read only attributes in the request is = allowed.

Should the same could go for = POST (create)? 
Let's say I do a GET /Users/xxxx on a = specific user which returns the complete resource including all = attributes in the GET response. Now I just want to copy / modify that = json response content and pass it to a POST. Should clients be allowed = to include read-only attributes like clients can for = PUT?

Should PATCH exclude read-only = attributes?
A PATCH request should not include read-only = attributes since it's a partial resource update = request.

If we decide to support "immutable" = attributes, should they be treated the same way as read-only once = set?

With regards to update = responses:

When a User is patched should it = return the entire new object? 
I notice that PATCH is = unclear on what is returned on a successful response.  In one = example it says the server can return nothing or everything in = non-normative text. I guess the issue here is that when you PATCH a = large group, you don't want the whole group returned.   What about = for other objects like Users?

What = attributes are returned on success?
As for what attributes = are returned on a PUT/POST/PATCH successful operation, I would suggest = we return the "default" attributes -- the ones you get when performing a = query with no attributes list.  That said, one could argue etag and = timestamp attributes should be returned too.

= --Apple-Mail=_B23D11B0-212F-4F18-83EB-37927B8AEB76-- From ayyagarikiran@gmail.com Wed Sep 25 11:12:12 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D163621F9CB0 for ; Wed, 25 Sep 2013 11:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.259 X-Spam-Level: X-Spam-Status: No, score=-1.259 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6iVqQoKoaMu for ; Wed, 25 Sep 2013 11:12:12 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8D36521F9AEF for ; Wed, 25 Sep 2013 11:12:11 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id f12so31675wgh.29 for ; Wed, 25 Sep 2013 11:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yHQbw9IpXxlFj7ZwVzwk5xk+hPUjOpezRaK30q8pVu4=; b=FVSQhJDvsbgsmC6snKTDaZCYVJ/CcTh8PzILiW/iOTkqW4POYst9gnoKkgjZhlKPd/ TX/jX4Ri1sx0ri8uYn3XlMxg31CYze1h24pSU5HfGRJQfqgebOJMYrQg1THHiDT2WnhY QWV1qKd3s+L86co5jCw5oOH6td88W0IAv8JptdU129GakT3qngpKGr7WTBVRsAY9FPb2 g7e+PJ/mZryOTXy78d88UQenMpOMReV2Z5dNpSt9Gjvz3CBCcpH2dccUfPgNFhKrcm2g pY4pJDs58nGKQ8XdijZ4dJ7QShcCTjM7JiUVtRh4v4SxezGrKs9xfxdp2rBFEyLg9Nqh clQw== MIME-Version: 1.0 X-Received: by 10.194.134.97 with SMTP id pj1mr2643518wjb.58.1380132730519; Wed, 25 Sep 2013 11:12:10 -0700 (PDT) Sender: ayyagarikiran@gmail.com Received: by 10.216.245.200 with HTTP; Wed, 25 Sep 2013 11:12:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Sep 2013 23:42:10 +0530 X-Google-Sender-Auth: o3qaiUKHtkQeRBrZ0NhTZvHMLXQ Message-ID: From: Kiran Ayyagari To: Phil Hunt Content-Type: multipart/alternative; boundary=089e012280582546b104e739312a Cc: "scim@ietf.org WG" Subject: Re: [scim] Questions on read-only attribute handling in POST/PUT/PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:12:12 -0000 --089e012280582546b104e739312a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 25, 2013 at 11:24 PM, Phil Hunt wrote: > I'd like to discuss handling of read-only attributes in POST/PUT/PATCH: > > For example, the PUT operation appears to allows read-only attribute > appear to be written for the convenience of the client. > > 3.3.1 . Modifying with PUT > > PUT performs a full update. Consumers must retrieve the entire > Resource and PUT the desired modifications as the operation > overwrites all previously stored data with the exception of the > > password attribute. If the password attribute of the User resource > is unspecified, it should be left in-tact. Since this performs a > full update, Consumers MAY send read-only attributes of the retrieved > resource and the Service Provider MUST ignore any read-only > attributes that are present in the payload of a PUT request. Unless > otherwise specified a successful PUT operation returns a 200 OK > response code and the entire Resource within the response body, > enabling the Consumer to correlate the Consumer's and Provider's > views of the updated Resource. Example: > > Makes sense as a convenience so a SCIM client doesn't have to remove > read-only attributes from a GET response before using it for a PUT request. > So, this is a case where including read only attributes in the request is > allowed. > > *Should the same could go for POST (create)? * > Let's say I do a GET /Users/xxxx on a specific user which returns the > complete resource including all attributes in the GET response. Now I just > want to copy / modify that json response content and pass it to a POST. > Should clients be allowed to include read-only attributes like clients can > for PUT? > > *Should PATCH exclude read-only attributes?* > A PATCH request should not include read-only attributes since it's a > partial resource update request. > IMO, the provider should make use of the schema and ignore all the read-only attributes cause providers are already forced by the spec to do this in the case of PUT > > *If we decide to support "immutable" attributes, should they be treated > the same way as read-only once set?* > > With regards to update responses: > > *When a User is patched should it return the entire new object? * > I notice that PATCH is unclear on what is returned on a successful > response. In one example it says the server can return nothing or > everything in non-normative text. I guess the issue here is that when you > PATCH a large group, you don't want the whole group returned. What about > for other objects like Users? > > *What attributes are returned on success?* > As for what attributes are returned on a PUT/POST/PATCH successful > operation, I would suggest we return the "default" attributes -- the ones > you get when performing a query with no attributes list. That said, one > could argue etag and timestamp attributes should be returned too. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > -- Kiran Ayyagari http://keydap.com --089e012280582546b104e739312a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 25, 2013 at 11:24 PM, Phil Hunt <<= a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.c= om> wrote:
I'd = like to discuss handling of read-only attributes in POST/PUT/PATCH:
For example, the PUT operation appears to allows read-only attribute a= ppear to be written for the convenience of the client.
=

3=
.3.1.  Modifying with PUT


   PUT performs a full update.  Consumers must retrieve the entire
   Resource and PUT the desired modifications as the operation
   overwrites all previously stored data with the exception of the
password attribute. If the password attribute of the User resource is unspecified, it should be left in-tact. Sinc= e this performs a full update, Consumers MAY send read-only attributes of the retrieved resource and the Service Provider MUST ignore any read-only attributes that are present in the payload of a PUT request. Unl= ess otherwise specified a successful PUT operation returns a 200 OK response code and the entire Resource within the response body, enabling the Consumer to correlate the Consumer's and Provider's views of the updated Resource. Example:
<= div>Makes sense as a convenience so a SCIM client doesn't have to remov= e read-only attributes from a GET response before using it for a PUT reques= t. So, this is a case where including read only attributes in the request i= s allowed.

Should the same could go for POST (create)?=A0<= /b>
Let's say I do a GET /Users/xxxx on a specific user which= returns the complete resource including all attributes in the GET response= . Now I just want to copy / modify that json response content and pass it t= o a POST. Should clients be allowed to include read-only attributes like cl= ients can for PUT?

Should PATCH exclude read-only attributes?
=
A PATCH request should not include read-only attributes since it's= a partial resource update request.
IMO, the provider should make use of the schema and ignore all the read-onl= y attributes
cause providers are already forced by the spec = to do this in the case of PUT

If we decid= e to support "immutable" attributes, should they be treated the s= ame way as read-only once set?

With regards to= update responses:

When a User is patched should it return the entire n= ew object?=A0
I notice that PATCH is unclear on what is retur= ned on a successful response. =A0In one example it says the server can retu= rn nothing or everything in non-normative text. I guess the issue here is t= hat when you PATCH a large group, you don't want the whole group return= ed. =A0 What about for other objects like Users?

What attributes are returned on success?
As for what attributes are returned on a PUT/POST/PATCH successful opera= tion, I would suggest we return the "default" attributes -- the o= nes you get when performing a query with no attributes list. =A0That said, = one could argue etag and timestamp attributes should be returned too.



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




--
Kiran Ayyagari
<= a href=3D"http://keydap.com" target=3D"_blank">http://keydap.com
--089e012280582546b104e739312a-- From phil.hunt@oracle.com Wed Sep 25 11:22:29 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F2721F9BC2 for ; Wed, 25 Sep 2013 11:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89CikuB+UAve for ; Wed, 25 Sep 2013 11:22:00 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4D18521F963F for ; Wed, 25 Sep 2013 11:21:56 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8PILReM015745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Sep 2013 18:21:28 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8PILQwQ023378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 18:21:27 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8PILQPS026238; Wed, 25 Sep 2013 18:21:26 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Sep 2013 11:21:25 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_8D21780E-87F5-4677-9344-4F4137C8BEC6" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: Date: Wed, 25 Sep 2013 11:21:30 -0700 Message-Id: References: To: Kiran Ayyagari X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "scim@ietf.org WG" Subject: Re: [scim] Questions on read-only attribute handling in POST/PUT/PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:22:30 -0000 --Apple-Mail=_8D21780E-87F5-4677-9344-4F4137C8BEC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Kiran, So what happens if the PATCH is only to an attribute that is read-only? = Should the operation fail? Or should it appear to succeed while nothing = happens? A further question. Let's assume we ignore attributes that are = read-only for PUT/POST/PATCH. What happens if the client changes the read-only value from what the = server already has? Should that cause an error? IOW=85should the = attempted modify of a read-only value only be ignored if the client = doesn't actually attempt to change the value? Also, there was special handling of password on the PUT operation where = it can be omitted from the PUT and the value is maintained. Is this = "sticky" value setting something that should apply to other attributes = and be reflected in schema? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-25, at 11:12 AM, Kiran Ayyagari wrote: >=20 >=20 >=20 > On Wed, Sep 25, 2013 at 11:24 PM, Phil Hunt = wrote: > I'd like to discuss handling of read-only attributes in = POST/PUT/PATCH: >=20 > For example, the PUT operation appears to allows read-only attribute = appear to be written for the convenience of the client. >> 3.3.1. Modifying with PUT >>=20 >>=20 >>=20 >> PUT performs a full update. Consumers must retrieve the entire >> Resource and PUT the desired modifications as the operation >> overwrites all previously stored data with the exception of the >> password attribute. If the password attribute of the User = resource >> is unspecified, it should be left in-tact. Since this performs a >> full update, Consumers MAY send read-only attributes of the = retrieved >> resource and the Service Provider MUST ignore any read-only >> attributes that are present in the payload of a PUT request. = Unless >> otherwise specified a successful PUT operation returns a 200 OK >> response code and the entire Resource within the response body, >> enabling the Consumer to correlate the Consumer's and Provider's >> views of the updated Resource. Example: > Makes sense as a convenience so a SCIM client doesn't have to remove = read-only attributes from a GET response before using it for a PUT = request. So, this is a case where including read only attributes in the = request is allowed. >=20 > Should the same could go for POST (create)?=20 > Let's say I do a GET /Users/xxxx on a specific user which returns the = complete resource including all attributes in the GET response. Now I = just want to copy / modify that json response content and pass it to a = POST. Should clients be allowed to include read-only attributes like = clients can for PUT? >=20 > Should PATCH exclude read-only attributes? > A PATCH request should not include read-only attributes since it's a = partial resource update request. > IMO, the provider should make use of the schema and ignore all the = read-only attributes=20 > cause providers are already forced by the spec to do this in the case = of PUT >=20 > If we decide to support "immutable" attributes, should they be treated = the same way as read-only once set? >=20 > With regards to update responses: >=20 > When a User is patched should it return the entire new object?=20 > I notice that PATCH is unclear on what is returned on a successful = response. In one example it says the server can return nothing or = everything in non-normative text. I guess the issue here is that when = you PATCH a large group, you don't want the whole group returned. What = about for other objects like Users? >=20 > What attributes are returned on success? > As for what attributes are returned on a PUT/POST/PATCH successful = operation, I would suggest we return the "default" attributes -- the = ones you get when performing a query with no attributes list. That = said, one could argue etag and timestamp attributes should be returned = too. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 > --=20 > Kiran Ayyagari > http://keydap.com > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_8D21780E-87F5-4677-9344-4F4137C8BEC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252


On 2013-09-25, at 11:12 AM, Kiran Ayyagari <kayyagari@apache.org> = wrote:




On Wed, Sep 25, 2013 at 11:24 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
I'd like to discuss handling of read-only = attributes in POST/PUT/PATCH:

For example, the PUT operation appears to allows read-only = attribute appear to be written for the convenience of the = client.
3.3.1.  Modifying with PUT


   PUT performs a full update.  Consumers must retrieve the entire
   Resource and PUT the desired modifications as the operation
   overwrites all previously stored data with the exception of =
the
   password attribute.  If the password attribute of the =
User resource
   is unspecified, it should be left in-tact.  Since this performs a
   full update, Consumers MAY send read-only attributes of the retrieved
   resource and the Service Provider MUST ignore any read-only
   attributes that are present in the payload of a PUT request.  =
Unless
   otherwise specified a successful PUT operation returns a 200 OK
   response code and the entire Resource within the response body,
   enabling the Consumer to correlate the Consumer's and Provider's
   views of the updated Resource.  Example:
Makes = sense as a convenience so a SCIM client doesn't have to remove read-only = attributes from a GET response before using it for a PUT request. So, = this is a case where including read only attributes in the request is = allowed.

Should the same could go for POST = (create)? 
Let's say I do a GET /Users/xxxx on a = specific user which returns the complete resource including all = attributes in the GET response. Now I just want to copy / modify that = json response content and pass it to a POST. Should clients be allowed = to include read-only attributes like clients can for PUT?

Should PATCH exclude read-only = attributes?
A PATCH request should not include read-only = attributes since it's a partial resource update = request.
IMO, the provider should make use of the schema and ignore all the = read-only attributes
cause providers are already forced = by the spec to do this in the case of PUT

If we decide = to support "immutable" attributes, should they be treated the same way = as read-only once set?

With regards to = update responses:

When a User is patched should it return the = entire new object? 
I notice that PATCH is unclear on = what is returned on a successful response.  In one example it says = the server can return nothing or everything in non-normative text. I = guess the issue here is that when you PATCH a large group, you don't = want the whole group returned.   What about for other objects like = Users?

What attributes are returned on = success?
As for what attributes are returned on a = PUT/POST/PATCH successful operation, I would suggest we return the = "default" attributes -- the ones you get when performing a query with no = attributes list.  That said, one could argue etag and timestamp = attributes should be returned too.



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




--
Kiran = Ayyagari
http://keydap.com
_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_8D21780E-87F5-4677-9344-4F4137C8BEC6-- From ayyagarikiran@gmail.com Wed Sep 25 11:31:35 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71D111E8135 for ; Wed, 25 Sep 2013 11:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmoek0Liwpkm for ; Wed, 25 Sep 2013 11:31:34 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 28EE911E812B for ; Wed, 25 Sep 2013 11:31:34 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id f12so58309wgh.29 for ; Wed, 25 Sep 2013 11:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=591iaJtf0M3bljkAFXrHwDmFDwkwvh+BgZu6a2URKWA=; b=jX8VF2nrSfH5yXuTzn2LukthrcpdkHNJIDiU6kmP5u5OQd5YcERMo5soyBnWmO453c U3mTGFN1VLFvtmLnGrdXuLsTxXym+CDar6wVU1yyGcJTMGlpj1aBA1N+0+6BMXebHDX+ 4ca5/7hYOrTJqijQuS3fxLG0DCa8B1EXV5Lh2jI/PlPwfH3ZQrQgB3/dFFQK76Vo0z8n IMETWBFRPLMN3LvMgH5PfMq3METIOFzVziZ9IaWL4B2n/6BcncT6BO0mr/gNFf6h/CwR 0kVlm4GtX5O/MxrL+6VJTSQvwbajyPm52r9TxgG3aF3xJj8EKsPzZH0GjC8waKs3jQg9 JDIw== MIME-Version: 1.0 X-Received: by 10.180.39.212 with SMTP id r20mr23936262wik.13.1380133891933; Wed, 25 Sep 2013 11:31:31 -0700 (PDT) Sender: ayyagarikiran@gmail.com Received: by 10.216.245.200 with HTTP; Wed, 25 Sep 2013 11:31:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Sep 2013 00:01:31 +0530 X-Google-Sender-Auth: xLQ_b0C9a2JURx66hNiK1yLroEA Message-ID: From: Kiran Ayyagari To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c2b01c5f0cbd04e7397609 Cc: "scim@ietf.org WG" , Kiran Ayyagari Subject: Re: [scim] Questions on read-only attribute handling in POST/PUT/PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:31:35 -0000 --001a11c2b01c5f0cbd04e7397609 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Sep 25, 2013 at 11:51 PM, Phil Hunt wrote: > Kiran, > > So what happens if the PATCH is only to an attribute that is read-only? > Should the operation fail? Or should it appear to succeed while nothing > happens? > I would consider it to be successful though nothing happens > > A further question. Let's assume we ignore attributes that are read-only > for PUT/POST/PATCH. > > What happens if the client changes the read-only value from what the > server already has? Should that cause an error? IOW=85should the attemp= ted > modify of a read-only value only be ignored if the client doesn't actuall= y > attempt to change the value? > yes, it should be ignored, and this is the main reason for keeping an attribute read-only, which is to prevent a client from updating it irrespective of the value sent by the client > > Also, there was special handling of password on the PUT operation where i= t > can be omitted from the PUT and the value is maintained. Is this "sticky" > value setting something that should apply to other attributes and be > reflected in schema? > yes, and will be great from an implementor's point of view, otherwise I imagine many hard-coded attribute name literals in code to handle the special cases like these. thanks Phil > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On 2013-09-25, at 11:12 AM, Kiran Ayyagari wrote: > > > > > On Wed, Sep 25, 2013 at 11:24 PM, Phil Hunt wrote: > >> I'd like to discuss handling of read-only attributes in POST/PUT/PATCH: >> >> For example, the PUT operation appears to allows read-only attribute >> appear to be written for the convenience of the client. >> >> 3.3.1 .= Modifying with PUT >> >> PUT performs a full update. Consumers must retrieve the entire >> Resource and PUT the desired modifications as the operation >> overwrites all previously stored data with the exception of the >> >> password attribute. If the password attribute of the User resource >> is unspecified, it should be left in-tact. Since this performs a >> full update, Consumers MAY send read-only attributes of the retrieved >> resource and the Service Provider MUST ignore any read-only >> attributes that are present in the payload of a PUT request. Unless >> otherwise specified a successful PUT operation returns a 200 OK >> response code and the entire Resource within the response body, >> enabling the Consumer to correlate the Consumer's and Provider's >> views of the updated Resource. Example: >> >> Makes sense as a convenience so a SCIM client doesn't have to remove >> read-only attributes from a GET response before using it for a PUT reque= st. >> So, this is a case where including read only attributes in the request i= s >> allowed. >> >> *Should the same could go for POST (create)? * >> Let's say I do a GET /Users/xxxx on a specific user which returns the >> complete resource including all attributes in the GET response. Now I ju= st >> want to copy / modify that json response content and pass it to a POST. >> Should clients be allowed to include read-only attributes like clients c= an >> for PUT? >> >> *Should PATCH exclude read-only attributes?* >> A PATCH request should not include read-only attributes since it's a >> partial resource update request. >> > IMO, the provider should make use of the schema and ignore all the > read-only attributes > cause providers are already forced by the spec to do this in the case of > PUT > >> >> *If we decide to support "immutable" attributes, should they be treated >> the same way as read-only once set?* >> >> With regards to update responses: >> >> *When a User is patched should it return the entire new object? * >> I notice that PATCH is unclear on what is returned on a successful >> response. In one example it says the server can return nothing or >> everything in non-normative text. I guess the issue here is that when yo= u >> PATCH a large group, you don't want the whole group returned. What abo= ut >> for other objects like Users? >> >> *What attributes are returned on success?* >> As for what attributes are returned on a PUT/POST/PATCH successful >> operation, I would suggest we return the "default" attributes -- the one= s >> you get when performing a query with no attributes list. That said, one >> could argue etag and timestamp attributes should be returned too. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > > > -- > Kiran Ayyagari > http://keydap.com > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > --=20 Kiran Ayyagari http://keydap.com --001a11c2b01c5f0cbd04e7397609 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 25, 2013 at 11:51 PM, Phil Hunt <<= a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.c= om> wrote:
Kiran,
So what happens if the PATCH is only to an attribute that= is read-only? =A0Should the operation fail? =A0Or should it appear to succ= eed while nothing happens?
I would consider it to be successful though nothing= happens

A further question. =A0Let's assume we ignore attri= butes that are read-only for PUT/POST/PATCH.

What = happens if the client changes the read-only value from what the server alre= ady has? =A0Should that cause an error? =A0IOW=85should the attempted modif= y of a read-only value only be ignored if the client doesn't actually a= ttempt to change the value?
yes, it should be ignored, and this is the main rea= son for keeping an attribute read-only, which is to prevent
a= client from updating it irrespective of the value sent by the client

Also, there was special handling of password on the PUT o= peration where it can be omitted from the PUT and the value is maintained. = Is this "sticky" value setting something that should apply to oth= er attributes and be reflected in schema?
yes, and will be great from an implementor's po= int of view, otherwise I imagine many hard-coded
attribute na= me literals in code to handle the special cases like these.

thanks Phil=A0


On 2013-09-25, at 11:12 AM, Kiran Ayyagari <kayyagari@apache.org> wr= ote:




On Wed, Sep 25, 2013 at 11:24 PM, Phil H= unt <phil.hunt@oracle.com> wrote:
I'd = like to discuss handling of read-only attributes in POST/PUT/PATCH:
For example, the PUT operation appears to allows read-only attribute a= ppear to be written for the convenience of the client.
3.3.1.  Modifying with PUT


   PUT performs a full update.  Consumers must retrieve the entire
   Resource and PUT the desired modifications as the operation
   overwrites all previously stored data with the exception of the
password attribute. If the password attribute of the User resource is unspecified, it should be left in-tact. Sinc= e this performs a full update, Consumers MAY send read-only attributes of the retrieved resource and the Service Provider MUST ignore any read-only attributes that are present in the payload of a PUT request. Unl= ess otherwise specified a successful PUT operation returns a 200 OK response code and the entire Resource within the response body, enabling the Consumer to correlate the Consumer's and Provider's views of the updated Resource. Example:
Makes se= nse as a convenience so a SCIM client doesn't have to remove read-only = attributes from a GET response before using it for a PUT request. So, this = is a case where including read only attributes in the request is allowed.

Should the same could go for POST (create)?=A0<= /b>
Let's say I do a GET /Users/xxxx on a specific user which= returns the complete resource including all attributes in the GET response= . Now I just want to copy / modify that json response content and pass it t= o a POST. Should clients be allowed to include read-only attributes like cl= ients can for PUT?

Should PATCH exclude read-only attributes?
=
A PATCH request should not include read-only attributes since it's= a partial resource update request.
IMO, the provider should make use of the schema and ignore all the read-onl= y attributes
cause providers are already forced by the spec = to do this in the case of PUT

If we decide to = support "immutable" attributes, should they be treated the same w= ay as read-only once set?

With regards to upda= te responses:

When a User is patched should it return the entire n= ew object?=A0
I notice that PATCH is unclear on what is retur= ned on a successful response. =A0In one example it says the server can retu= rn nothing or everything in non-normative text. I guess the issue here is t= hat when you PATCH a large group, you don't want the whole group return= ed. =A0 What about for other objects like Users?

What attributes are returned on success?
As for what attributes are returned on a PUT/POST/PATCH successful opera= tion, I would suggest we return the "default" attributes -- the o= nes you get when performing a query with no attributes list. =A0That said, = one could argue etag and timestamp attributes should be returned too.


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




--
Kiran Ayyagari
<= a href=3D"http://keydap.com/" target=3D"_blank">http://keydap.com
_______________________________________________
scim mailing list
scim@ietf.org
https://= www.ietf.org/mailman/listinfo/scim




--
Kiran Ayyagari
http://keydap.com
--001a11c2b01c5f0cbd04e7397609-- From kelly.grizzle@sailpoint.com Wed Sep 25 12:33:13 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300F511E80EC for ; Wed, 25 Sep 2013 12:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqGhAw9Q7HDk for ; Wed, 25 Sep 2013 12:33:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 3F98921F9B10 for ; Wed, 25 Sep 2013 12:33:06 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 25 Sep 2013 19:33:04 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.126]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.34]) with mapi id 15.00.0775.005; Wed, 25 Sep 2013 19:33:04 +0000 From: Kelly Grizzle To: Kiran Ayyagari , Patrick Radtke Thread-Topic: [scim] Membership attributes expressed in a SCIM group Thread-Index: AQHOuf8T2xMF1YktzUaW4oAcCghZhZnWo6kAgAASLgCAAAM8gIAAA0sAgAAZrnA= Date: Wed, 25 Sep 2013 19:33:03 +0000 Message-ID: References: <52430E70.8070206@stanford.edu> <52432067.6000401@stanford.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 000BE983005538000BEAD0 x-originating-ip: [72.182.10.254] x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(53754006)(51914003)(24454002)(377454003)(479174003)(199002)(189002)(15202345003)(16601075003)(31966008)(66066001)(74706001)(15975445006)(74876001)(81542001)(83322001)(19580395003)(19580405001)(69226001)(74366001)(76786001)(46102001)(76796001)(49866001)(47736001)(54356001)(16236675002)(63696002)(76576001)(53806001)(81686001)(51856001)(77096001)(54316002)(19609705001)(47446002)(74316001)(83072001)(80976001)(74662001)(74502001)(79102001)(56816003)(19300405004)(76482001)(47976001)(80022001)(4396001)(81816001)(59766001)(33646001)(81342001)(65816001)(50986001)(56776001)(77982001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:72.182.10.254; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_bf19ae08595b4b278a98fb8e15394a85BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: David Langenberg , "scim@ietf.org" Subject: Re: [scim] Membership attributes expressed in a SCIM group X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 19:33:13 -0000 --_000_bf19ae08595b4b278a98fb8e15394a85BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the thought with "MAY provide alternate String values to represent = additional values" was geared more toward multi-valued attributes like ims = where there are likely to be other types that are currently unknown. For i= nteroperability, I would not recommend deviating from User and Group as the= types for group members. Have you considered extending group to add a manager attribute? For exampl= e: { "schemas": ["urn:scim:schemas:core:2.0:Group", "urn:edu:2.0:Group" ], "id": "e9e30dba-f08f-4109-8486-d5c6a331660a", "displayName": "Tour Guides", "members": [ { "value": "2819c223-7f76-453a-919d-413861904646", "$ref": "https://example.com/v1/Users/2819c223-7f76-453a-919d-4138= 61904646", "display": "Babs Jensen" } ], "urn:edu:2.0:Group": { "manager": { "managerId": "26118915-6090-4610-87e4-49d8ca9f808d", "$ref": "/Users/26118915-6090-4610-87e4-49d8ca9f808d", "displayName": "John Smith" } }, "meta": { "resourceType": "Group", "created": "2010-01-23T04:56:22Z", "lastModified": "2011-05-13T04:42:34Z", "version": "W\/\"3694e05e9dff592\"", "location": "https://example.com/v1/Groups/e9e30dba-f08f-4109-8486-d= 5c6a331660a" } } From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kir= an Ayyagari Sent: Wednesday, September 25, 2013 12:54 PM To: Patrick Radtke Cc: David Langenberg; Kiran Ayyagari; scim@ietf.org Subject: Re: [scim] Membership attributes expressed in a SCIM group On Wed, Sep 25, 2013 at 11:11 PM, Patrick Radtke > wrote: I read that section 8 as User and Group members are read only - e.g. you ca= n't add or modify a User or Group through the group membership. Elsewhere in the spec when it refers to canonical values for an attribute i= t says "Canonical Values". Anyhow, 3.1.1 String says "Additionally, when Canonical Values are specified Service Providers SHOULD conform to those values if appropriate, but MAY provide alternate String values to represent additional values." which sounds like the service provider is allowed to add additional values. yeap, didn't notice it, thanks for the pointer -Patrick http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-3.1.1 On 9/25/13 10:30 AM, Kiran Ayyagari wrote: AFAIK, the only canonical types defined[1] for 'type' in this context are "User" and "Group". [1] http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-8 On Wed, Sep 25, 2013 at 9:55 PM, Patrick Radtke >> wrote: Members is a multi-valued attribute so you could use any of the pre-defined attributes listed here http://tools.ietf.org/html/__draft-ietf-scim-core-schema-__02#section-3= .2 or add your own through an extension. IMHO, 'type' might be suitable for this. It is defined as "A label indicating the attribute's function". So you could do "members": [ { "value": "2819c223-7f76-453a-919d-__413861904646", "$ref": "https://example.com/v1/Users/__2819c223-7f76-453a-919d-__413861904646 ", "display": "Babs Jensen", "type": "manager" }, { "value": "902c246b-6245-4190-8e05-__00816be7344a", "$ref": "https://example.com/v1/Users/__902c246b-6245-4190-8e05-__00816be7344a ", "display": "Mandy Pepperidge" } ] -Patrick On 9/25/13 7:52 AM, David Langenberg wrote: Hello All, I'm presently engaged in adding SCIM support to the Internet2's Grouper product. One of the use-cases we're trying to address is to emit group membership attributes over SCIM. The more concrete case is decorating who is the manager of the group within the group's membership list. I'm trying to figure out a way to do that within the standard, but it seems that there is no way to do that at present. If there is a way, would somebody please point me in the right direction, else, what would be the process for getting it added? Thanks Dave -- David Langenberg Identity & Access Management The University of Chicago _________________________________________________ scim mailing list scim@ietf.org > https://www.ietf.org/mailman/__listinfo/scim _________________________________________________ scim mailing list scim@ietf.org > https://www.ietf.org/mailman/__listinfo/scim -- Kiran Ayyagari http://keydap.com -- Kiran Ayyagari http://keydap.com --_000_bf19ae08595b4b278a98fb8e15394a85BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think the thought with = “MAY provide alternate String values to represent additional val= ues” was geared more toward multi-valued attributes like ims where there are likely to be other types that are currently unknown.  For i= nteroperability, I would not recommend deviating from User and Group as the= types for group members.

 <= /p>

Have you considered exten= ding group to add a manager attribute?  For example:=

 <= /p>

   {

     &qu= ot;schemas": ["urn:scim:schemas:core:2.0:Group",<= /span>

 &=
nbsp;           &nbs=
p;       "urn:edu:2.0:Group" ],

     &qu= ot;id": "e9e30dba-f08f-4109-8486-d5c6a331660a",

     &qu= ot;displayName": "Tour Guides",

     &qu= ot;members": [

    &nbs= p;  {

         "value"=
;: "2819c223-7f76-453a-919d-413861904646",

         "$ref"=
: "https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646&q=
uot;,


         "display&qu=
ot;: "Babs Jensen"


       }


     ],


     "urn:edu:2.0:Group": {

    &n=
bsp;  "manager": {


    &n=
bsp;    "managerId": "26118915-6090-4610-87e4=
-49d8ca9f808d",


    &n=
bsp;    "$ref": "/Users/26118915-6090-4610-87=
e4-49d8ca9f808d",


    &n=
bsp;    "displayName": "John Smith"=



    &n=
bsp;  }


     }=
,

     "meta": {

       "resourceType": &q=
uot;Group",


       "created": "2=
010-01-23T04:56:22Z",


       "lastModified": &q=
uot;2011-05-13T04:42:34Z",


       "version": "W=
\/\"3694e05e9dff592\"",


       "location": "=
https://example.com/v1/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a"


     }


   }


 <=
/p>

From: scim-bou=
nces@ietf.org [mailto:scim-bounces@ietf.org]
On Behalf Of Kiran Ayyagari

Sent: Wednesday, September 25, 2013 12:54 PM

To: Patrick Radtke

Cc: David Langenberg; Kiran Ayyagari; scim@ietf.org

Subject: Re: [scim] Membership attributes expressed in a SCIM group<=
o:p>


 




 




 




On Wed, Sep 25, 2013 at 11:11 PM, Patrick Radtke <=
;pradtke@stanford=
.edu> wrote:


I read that section 8 as User and Group members are =
read only - e.g. you can't add or modify a User or Group through the group =
membership.



Elsewhere in the spec when it refers to canonical values for an attribute i=
t says "Canonical Values". Anyhow, 3.1.1 String says



"Additionally, when Canonical Values

   are specified Service Providers SHOULD conform to those values=
 if

   appropriate, but MAY provide alternate String values to repres=
ent

   additional values."



which sounds like the service provider is allowed to add additional values.=





yeap, didn't notice it, thanks for the pointer<=
/o:p>








-Patrick



http://tools.ietf.org/html/draft-ietf-scim-core-=
schema-02#section-3.1.1








On 9/25/13 10:30 AM, Kiran Ayyagari wrote:








AFAIK, the only canonical types defined[1] for 'type=
' in this context

are "User" and "Group".





[1] 
http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-8





On Wed, Sep 25, 2013 at 9:55 PM, Patrick Radtke <pradtke@stanford.edu






<mailto:pradtke@stanford.edu>=
;> wrote:



    Members is a multi-valued attribute so you could use any of t=
he

    pre-defined attributes listed here




    
http://tools.ietf.org/html/__draft-ietf-scim-core-schema-__02#section-3.2






    <http://tools.ietf.org/html/draft=
-ietf-scim-core-schema-02#section-3.2>



    or add your own through an extension.



    IMHO, 'type' might be suitable for this. It is defined as &qu=
ot;A label

    indicating the attribute's function". So you could do


    "members": [

            {




              &qu=
ot;value": "2819c223-7f76-453a-919d-__413861904646",

              "$ref":

    "https://example.com/v1/Users/_=
_2819c223-7f76-453a-919d-__413861904646






    <https://example.com/v1/Users/2819c22=
3-7f76-453a-919d-413861904646>",

              "display": "=
;Babs Jensen",

              "type": "ma=
nager"

            },

            {




              &qu=
ot;value": "902c246b-6245-4190-8e05-__00816be7344a",

              "$ref":

    "https://example.com/v1/Users/_=
_902c246b-6245-4190-8e05-__00816be7344a








    <https://example.com/v1/Users/902c246=
b-6245-4190-8e05-00816be7344a>",

              "display": "=
;Mandy Pepperidge"

            }

          ]



    -Patrick





    On 9/25/13 7:52 AM, David Langenberg wrote:



        Hello All,



        I'm presently engaged in adding SCIM support to=
 the Internet2's

        Grouper

        product.  One of the use-cases we're tryin=
g to address is to

        emit group

        membership attributes over SCIM.  The more=
 concrete case is

        decorating

        who is the manager of the group within the grou=
p's membership

        list.  I'm

        trying to figure out a way to do that within th=
e standard, but

        it seems

        that there is no way to do that at present. &nb=
sp;If there is a way,

        would

        somebody please point me in the right direction=
, else, what

        would be the

        process for getting it added?



        Thanks



        Dave



        --

        David Langenberg

        Identity & Access Management

        The University of Chicago










        ________________________=
_________________________

        scim mailing list

        scim@ietf.org <mailto:scim@ietf.org>

        https://www.ietf.org/mailman/__listinfo/scim

        <https://www.ietf.org/mailman/listinfo/scim>





    _________________________________________________

    scim mailing list

    scim@ietf.=
org <mailto:scim@=
ietf.org>

    https://www.ietf.org/mailman/__listinfo/scim





 












-- 

Kiran Ayyagari

http://keydap.com =
--_000_bf19ae08595b4b278a98fb8e15394a85BN1PR04MB392namprd04pro_-- From kelly.grizzle@sailpoint.com Mon Sep 30 14:00:26 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E2021F9D15 for ; Mon, 30 Sep 2013 14:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdjqumN9Anwp for ; Mon, 30 Sep 2013 14:00:22 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id CAAEE21F994A for ; Mon, 30 Sep 2013 14:00:21 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 30 Sep 2013 21:00:11 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.199]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.199]) with mapi id 15.00.0775.005; Mon, 30 Sep 2013 21:00:11 +0000 From: Kelly Grizzle To: =?iso-8859-1?Q?Thorsten_Ro=DFner?= , "scim@ietf.org" Thread-Topic: [scim] Introduction & question Thread-Index: AQHOufBCP21b2MTLaEWbSgju4nvC7Znex+kw Date: Mon, 30 Sep 2013 21:00:10 +0000 Message-ID: <532697fe4a9f444b9c52bcc123277c4e@BN1PR04MB392.namprd04.prod.outlook.com> References: <5242E013.9070902@tarent.de> In-Reply-To: <5242E013.9070902@tarent.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 1A1B7B9D0055D41A1B7CEA x-originating-ip: [10.255.124.4] x-forefront-prvs: 0985DA2459 x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(377454003)(189002)(199002)(15975445006)(56776001)(76482001)(54316002)(33646001)(50986001)(54356001)(4396001)(49866001)(47976001)(47736001)(65816001)(74316001)(80022001)(63696002)(46102001)(51856001)(83072001)(79102001)(59766001)(53806001)(77982001)(76796001)(81686001)(74706001)(81816001)(56816003)(74876001)(74502001)(31966008)(74662001)(47446002)(69226001)(74366001)(76786001)(80976001)(81342001)(77096001)(76576001)(83322001)(19580395003)(19580405001)(81542001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:10.255.124.4; FPR:; RD:InfoNoRecords; MX:3; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Introduction & question X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 21:00:26 -0000 Hi Thorsten ... you're bumping up against the stickiest part of PATCH (and = believe me ... this has incited some debate in the past). The drafts say this: API section 3.3.2 Attributes that do not have a value Sub-Attribute or that have a non-unique value Sub-Attribute are matched by comparing all Sub-Attribute values from the PATCH request body to the Sub-Attribute values of the Resource. Schema section 3.2 Providers MAY return the same value more than once with different types (e.g. the same e-mail address may used for work and home), but SHOULD NOT return the same (type, value) combination more than once per Attribute, as this complicates processing by the Consumer. According to the draft, you should use the entire complex object to delete = an entry. For example: PATCH /Users/bjensen ... { "emails": [ { "value": "bjensen@example.com", "type": "work", "operation": "delete" ] } A $ref-like syntax has been discussed, but the consensus was that given eve= ry list element a unique identifier was too intrusive on the service provid= er since an SP is likely not storing an uid already for each element. Anot= her option would be using a list index, but this would be prone to concurre= nt modification problems for objects that are modified often (eg - the memb= ers list on a Group). --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Tho= rsten Ro=DFner Sent: Wednesday, September 25, 2013 8:08 AM To: scim@ietf.org Subject: [scim] Introduction & question Dear SCIM folks, even that I already sent a couple of mails in this list and I'm a regular r= eader, I would like to quickly introduce myself. I'm Thorsten :) I'm working with osiam.org where we develop a MIT licenced = implementation of SCIMv2. Unfortuantely I wasn't able to come to the IETF M= eeting in Berlin to meet some of you in person as I just moved into a new, = not yet ready, home the Monday after the Berlin-Meeting. Currently we hope = to have a kitchen in there by x-mas, so still a lot to do for me beside osi= am.org. ;-) I'll catch up with the latest development of the currently existing tickets= and may come up with some comments in this list in the next days/weeks. But first of all I have question: When I look into most of the complex/multi-value attributes (e.g. emails, addresses, phoneNumbers) SCIM does not require the values below to = be unique (within the user record). How should a PATCH based "delete" of a certain email-address work, when it'= s possible to have two identical entries? Would a solution using $refs for each item of a multi-value attribute be co= vered by the standard or are there other ways to handle the problem? Thanks Thorsten _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim