From nobody Mon Jun 2 13:04:14 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3402A1A045E for ; Mon, 2 Jun 2014 13:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RusaOF1mb2t for ; Mon, 2 Jun 2014 13:04:00 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D471A045D for ; Mon, 2 Jun 2014 13:03:59 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s52K3qBM008684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Jun 2014 20:03:53 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 s52K3q5F006184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Jun 2014 20:03:52 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s52K3qNh006176 for ; Mon, 2 Jun 2014 20:03:52 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Jun 2014 13:03:52 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_13CDC269-A386-472F-BC32-0EB4075411E6" Message-Id: Date: Mon, 2 Jun 2014 13:03:51 -0700 To: Scim WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ajPTc-gwdw2U_kwZQJZjpY7PgRA Subject: [scim] Proposed new text for PUT (ticket 76) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:04:11 -0000 --Apple-Mail=_13CDC269-A386-472F-BC32-0EB4075411E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Here is some proposed new text. I=92ve tried to tweak the text a bit to = help solve Ticket 76 regarding what to do about missing or omitted = attributes. After some analysis, I think this is closest in logic to how people are = using PUT now. Because PUT is mandatory, I believe we need to be very = precise. I have also added text stating that PUT should not be used to create new = resources. Is the word =93SHOULD=94 appropriate? The real problem with = using PUT for resource creation is the client gets to create their own = identifier. > 3.3.1. Modifying with PUT >=20 > HTTP PUT is used to perform a full update of a resource's = attributes. > Clients having previously retrieved the entire resource in advance, > update the desired attributes and use HTTP PUT to replace = previously > stored attributes. HTTP PUT SHOULD NOT be used to create a new > resource. >=20 > As the operation intent is to replace attributes, SCIM clients MAY > send all attributes regardless of each attribute's mutability. The > server will apply attribute by attribute replace according to the > following attribute mutability rules: >=20 > readWrite, writeOnly Any values provided SHALL replace the = existing > attribute values. >=20 > immutable If values are already set in the attribute they MUST = match > existing data or an error is returned. If the service provider > has no existing values, the new value(s) SHALL be applied. >=20 > readOnly Any values provided (e.g. meta.resourceType) SHALL be > ignored. >=20 > If an attribute is "required", clients MUST specify the attribute = in > the PUT request. >=20 > Clients MAY specify "null" or empty set "[]" to clear an existing > value or clear a multi-valued array. >=20 > Since a client may not have access to, or may not be aware of, the > full schema for a resource, omitted or unspecified values SHOULD be > ignored. >=20 > If a value provided for an immutable attribute with an existing = value > is NOT matched, the server SHALL respond with an HTTP response code > of 400 and an appropriate human readable message indicating an > attempt to change an immutable attribute. [[Editor: An appropriate > error code should be indicated e.g. 'mutability']] >=20 > Unless otherwise specified a successful PUT operation returns a 200 > OK response code and the entire resource within the response body, > enabling the client to correlate the client's and Provider's views = of > the updated resource. Example: >=20 Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_13CDC269-A386-472F-BC32-0EB4075411E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Here = is some proposed new text.  I=92ve tried to tweak the text a bit to = help solve Ticket 76 regarding what to do about missing or omitted = attributes.

After some analysis, I think this is = closest in logic to how people are using PUT now.  Because PUT is = mandatory, I believe we need to be very = precise.

I have also added text stating that = PUT should not be used to create new resources. Is the word =93SHOULD=94 = appropriate?  The real problem with using PUT for resource creation = is the client gets to create their own = identifier.

3.3.1.  Modifying with PUT

   HTTP PUT is used to perform a full update of a resource's attributes.
   Clients having previously retrieved the entire resource in advance,
   update the desired attributes and use HTTP PUT to replace previously
   stored attributes.  HTTP PUT SHOULD NOT be used to create a new
   resource.

   As the operation intent is to replace attributes, SCIM clients MAY
   send all attributes regardless of each attribute's mutability.  The
   server will apply attribute by attribute replace according to the
   following attribute mutability rules:

   readWrite, writeOnly  Any values provided SHALL replace the existing
      attribute values.

   immutable  If values are already set in the attribute they MUST match
      existing data or an error is returned.  If the service provider
      has no existing values, the new value(s) SHALL be applied.

   readOnly  Any values provided (e.g.  meta.resourceType) SHALL be
      ignored.

   If an attribute is "required", clients MUST specify the attribute in
   the PUT request.

   Clients MAY specify "null" or empty set "[]" to clear an existing
   value or clear a multi-valued array.

   Since a client may not have access to, or may not be aware of, the
   full schema for a resource, omitted or unspecified values SHOULD be
   ignored.

   If a value provided for an immutable attribute with an existing value
   is NOT matched, the server SHALL respond with an HTTP response code
   of 400 and an appropriate human readable message indicating an
   attempt to change an immutable attribute.  [[Editor: An appropriate
   error code should be indicated e.g. 'mutability']]

   Unless otherwise specified a successful PUT operation returns a 200
   OK response code and the entire resource within the response body,
   enabling the client to correlate the client's and Provider's views of
   the updated resource.  Example:
=



Phil

@independentid
phil.hunt@oracle.com



= --Apple-Mail=_13CDC269-A386-472F-BC32-0EB4075411E6-- From nobody Tue Jun 3 07:24:08 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2240A1A0270 for ; Tue, 3 Jun 2014 07:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7thrdRaXPSb for ; Tue, 3 Jun 2014 07:24:02 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DF81A0263 for ; Tue, 3 Jun 2014 07:24:02 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB012.namprd04.prod.outlook.com (10.255.203.18) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 3 Jun 2014 14:23:56 +0000 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.954.9; Tue, 3 Jun 2014 14:23:53 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.118]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.118]) with mapi id 15.00.0954.000; Tue, 3 Jun 2014 14:23:53 +0000 From: Kelly Grizzle To: "scim@ietf.org" Thread-Topic: SCIM Interop at Cloud Identity Summit 2014 Thread-Index: Ac9/NyldslN8XTZFR4mZE1GgSZ0Msg== Date: Tue, 3 Jun 2014 14:23:52 +0000 Message-ID: <0583386da24e4aa0bb2e4e4e37995314@BN1PR04MB392.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [97.79.140.10] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02318D10FB x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(199002)(189002)(20776003)(74502001)(4396001)(16236675002)(77982001)(66066001)(79102001)(74662001)(31966008)(80022001)(101416001)(19609705001)(15975445006)(76576001)(64706001)(99396002)(2656002)(19300405004)(81342001)(99286001)(19625215002)(15202345003)(74316001)(92566001)(86362001)(83072002)(21056001)(85852003)(76482001)(83322001)(81542001)(46102001)(19580395003)(87936001)(50986999)(54356999)(33646001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: sailpoint.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kelly.grizzle@sailpoint.com; Content-Type: multipart/alternative; boundary="_000_0583386da24e4aa0bb2e4e4e37995314BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/2t_sBgZ8vpc21ON-uC6ybuSmTBA Subject: [scim] SCIM Interop at Cloud Identity Summit 2014 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 14:24:07 -0000 --_000_0583386da24e4aa0bb2e4e4e37995314BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Cloud Identity Summit is again pre= senting an opportunity to do some SCIM interop testing. If you have a SCIM= client and/or server and would like to participate, please respond here - = https://groups.google.com/forum/#!topic/scim-interop-cis/mihTDoGr8jI. The = format will be similar to last year - clients and servers will be paired up= and try to execute a variety of test cases. Interop testing should happen= prior to CIS, and the results will be presented at the SCIM Interop on Jul= y 19th. I know that this is directly before the IETF meeting in Toronto, however, e= ven if you cannot attend CIS you can still participate. The goal is to get= as many clients and servers talking as possible so that we can help test y= our implementations and find any issues with the spec. --Kelly --_000_0583386da24e4aa0bb2e4e4e37995314BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Cloud Identity Summit is again presenting an opportunity = to do some SCIM interop testing.  If you have a SCIM client and/or server and would like to participate, please respond here - = https://groups.google.com/forum/#!topic/scim-interop-cis/mihTDoGr8jI. &= nbsp;The format will be similar to last year - clients and servers will be = paired up and try to execute a variety of test cases.  Interop testing= should happen prior to CIS, and the results will be presented at the SCIM Interop on July 19th.

 

I know that this is directly before the IETF meeting= in Toronto, however, even if you cannot attend CIS you can still participa= te.  The goal is to get as many clients and servers talking as possibl= e so that we can help test your implementations and find any issues with the spec.

 

--Kelly

 

--_000_0583386da24e4aa0bb2e4e4e37995314BN1PR04MB392namprd04pro_-- From nobody Wed Jun 11 11:00:58 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2501B27B8 for ; Wed, 11 Jun 2014 11:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPatyWvk48_W for ; Wed, 11 Jun 2014 11:00:55 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8A61B27A8 for ; Wed, 11 Jun 2014 11:00:55 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5BI0rqU002069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Jun 2014 18:00:54 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5BI0qbn014886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Jun 2014 18:00:53 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5BI0pc8003462 for ; Wed, 11 Jun 2014 18:00:51 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Jun 2014 11:00:51 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_C7E9D947-6BAD-4AAA-9F0A-FF14231D07B6" Message-Id: Date: Wed, 11 Jun 2014 11:00:49 -0700 To: Scim WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ZOtNDO_Odze197sgf6CT6qfj0-M Subject: [scim] Clarification on DELETE handling of unique attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 18:00:56 -0000 --Apple-Mail=_C7E9D947-6BAD-4AAA-9F0A-FF14231D07B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In the current draft, DELETE indicates that when a resource is actually = deleted, attributes like userName must not be considered in conflict = calculations. I am thinking that this requirement is not necessary for = inter-operability. As well, there may be valid reasons why an attribute = value might be held for a period of time after a resource is deleted = that might have much more than simple resource resurrection. For = example, many telcos often hold telephone numbers for a period of time = before re-use. I agree however that once deleted, a search based on = that attribute value should not return a match since the resource is = deleted. I would like to propose we remove the last two sentences: 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. =20 Original text from section 3.4 on HTTP DELETE:=20 Clients 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. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_C7E9D947-6BAD-4AAA-9F0A-FF14231D07B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In the = current draft, DELETE indicates that when a resource is actually = deleted, attributes like userName must not be considered in conflict = calculations.  I am thinking that this requirement is not necessary = for inter-operability. As well, there may be valid reasons why an = attribute value might be held for a period of time after a resource is = deleted that might have much more than simple resource resurrection. =  For example, many telcos often hold telephone numbers for a period = of time before re-use.  I agree however that once deleted, a search = based on that attribute value should not return a match since the = resource is deleted.

I would like to propose we = remove the last two sentences:
   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.

 
Original text from = section 3.4 on HTTP DELETE: 

   Clients 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.

= --Apple-Mail=_C7E9D947-6BAD-4AAA-9F0A-FF14231D07B6-- From nobody Wed Jun 11 11:38:26 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D7E1A021E for ; Wed, 11 Jun 2014 11:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxD_Xsf6D5WU for ; Wed, 11 Jun 2014 11:38:22 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29FA21A00D4 for ; Wed, 11 Jun 2014 11:38:21 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so83101lbv.21 for ; Wed, 11 Jun 2014 11:38:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jRyMe0e4ZadNblOGq+w4Yuzoi0YTOI/ws+TRbZflIlM=; b=BrdJ9983ND1HOyPrJjmqbtgu4PEjpnlmITuM5AQnFJyH+dHpRWIdsmPq4OUnswVpw7 0be0z1GDTX1bSiUxIbYBLyz17WFFTKOolveEwasfsuXa/fdAafQRq0TWbjzdbfzS0MB6 jBdMT1tDkcQUBMrB6FrERF+/9BibmodtiUNgegBMIiP3so5rT9kJq5bhZEixEiIfXBQZ Iu/brYBi0tuk17XpLIcuHNFD00t7yiuOMPeFA5dogH8GzV8GlnCiEuT2gcm+yDMM4n+F saFJXYejkzINl8yICC7DXxgoXxcwXFcWrsh+wHLZ/GCh4rEorDIQwrvvm867K54z9Se2 WNsA== X-Gm-Message-State: ALoCoQmuCC3e/EJQYc36Nw/ENV4S9zgUtMbUN8Q/gKdmBce650Fk6XVBt/VX8dm6bdQHwFfSa0eC X-Received: by 10.112.210.165 with SMTP id mv5mr2713151lbc.68.1402511900239; Wed, 11 Jun 2014 11:38:20 -0700 (PDT) Received: from [10.0.0.115] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id ul4sm25602897lbb.33.2014.06.11.11.38.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 11:38:19 -0700 (PDT) Message-ID: <5398A21B.4000502@mnt.se> Date: Wed, 11 Jun 2014 20:38:19 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: scim@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/wlUvUn5K9fr-WQa_5-SmzZlJ4Dk Subject: Re: [scim] Proposed new text for PUT (ticket 76) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 18:38:24 -0000 On 2014-06-02 22:03, Phil Hunt wrote: > Here is some proposed new text. I’ve tried to tweak the text a bit to > help solve Ticket 76 regarding what to do about missing or omitted > attributes. > I want to encourage/urge everyone to think about and review this proposal. It is very likely the last big issue left to us! > After some analysis, I think this is closest in logic to how people are > using PUT now. Because PUT is mandatory, I believe we need to be very > precise. > > I have also added text stating that PUT should not be used to create new > resources. Is the word “SHOULD” appropriate? The real problem with > using PUT for resource creation is the client gets to create their own > identifier. > >> 3.3.1. Modifying with PUT >> >> HTTP PUT is used to perform a full update of a resource's attributes. >> Clients having previously retrieved the entire resource in advance, >> update the desired attributes and use HTTP PUT to replace previously >> stored attributes. HTTP PUT SHOULD NOT be used to create a new >> resource. >> >> As the operation intent is to replace attributes, SCIM clients MAY >> send all attributes regardless of each attribute's mutability. The >> server will apply attribute by attribute replace according to the >> following attribute mutability rules: >> >> readWrite, writeOnly Any values provided SHALL replace the existing >> attribute values. >> >> immutable If values are already set in the attribute they MUST match >> existing data or an error is returned. If the service provider >> has no existing values, the new value(s) SHALL be applied. >> >> readOnly Any values provided (e.g. meta.resourceType) SHALL be >> ignored. >> >> If an attribute is "required", clients MUST specify the attribute in >> the PUT request. >> >> Clients MAY specify "null" or empty set "[]" to clear an existing >> value or clear a multi-valued array. >> >> Since a client may not have access to, or may not be aware of, the >> full schema for a resource, omitted or unspecified values SHOULD be >> ignored. >> >> If a value provided for an immutable attribute with an existing value >> is NOT matched, the server SHALL respond with an HTTP response code >> of 400 and an appropriate human readable message indicating an >> attempt to change an immutable attribute. [[Editor: An appropriate >> error code should be indicated e.g. 'mutability']] >> >> Unless otherwise specified a successful PUT operation returns a 200 >> OK response code and the entire resource within the response body, >> enabling the client to correlate the client's and Provider's views of >> the updated resource. Example: >> > > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From nobody Sun Jun 15 06:11:31 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDD11B2A61 for ; Sun, 15 Jun 2014 06:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.499 X-Spam-Level: * X-Spam-Status: No, score=1.499 tagged_above=-999 required=5 tests=[BAYES_60=1.5, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSPGCJkSkOKL for ; Sun, 15 Jun 2014 06:11:23 -0700 (PDT) Received: from c15s9xb8.securesites.net (c15s9xb8.securesites.net [118.23.75.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E981B28FB for ; Sun, 15 Jun 2014 06:11:23 -0700 (PDT) Received: from [192.168.0.7] (softbank220025207006.bbtec.net [220.25.207.6]) (authenticated bits=0) by c15s9xb8.securesites.net (8.14.5/8.13.1) with ESMTP id s5FDBIHg019543 for ; Sun, 15 Jun 2014 22:11:21 +0900 MIME-Version: 1.0 Date: Sun, 15 Jun 2014 22:11:20 +0900 Message-ID: From: ueda@exgen.co.jp To: scim@ietf.org X-Mailer: JsvMail 9.0 (Shuriken 2009) Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/R7BKEHrcODkPlpUEyiDsVkAINgI Subject: [scim] EnterpriseUser's URI X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 13:11:29 -0000 Hello, I have a question about enterprise user extension. In section 7 of schema document, enterprise user's URI is "urn:scim:schemas:extension:enterprise:2.0:EnterpriseUser". But section 12 is "urn:scim:schemas:extension:enterprise:2.0:User", and api document is "urn:scim:schemas:extension:enterprise:2.0:User". Which is right? - Takanori Ueda. From nobody Sun Jun 15 13:08:40 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496BE1B296E for ; Sun, 15 Jun 2014 13:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qe5hC4YciTBS for ; Sun, 15 Jun 2014 13:08:36 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD0F1B2968 for ; Sun, 15 Jun 2014 13:08:36 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5FK8VcO030844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 15 Jun 2014 20:08:31 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5FK8Ut6018158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jun 2014 20:08:30 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5FK8SW9013184; Sun, 15 Jun 2014 20:08:29 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 15 Jun 2014 13:08:28 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: Date: Sun, 15 Jun 2014 13:08:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6C17B827-2CA8-40C9-AE86-951922F4DBD9@oracle.com> References: To: ueda@exgen.co.jp X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/cIygv-aq9RCQ-NUS5Rfokh8vkjM Cc: scim@ietf.org Subject: Re: [scim] EnterpriseUser's URI X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 20:08:38 -0000 Takanori, Thanks for pointing this out. It looks like one of the URIs was missed when we corrected in SCIM WG = Ticket #63. The ticket indicates it should be: = urn:scim:schemas:extension:enterprise:2.0:User I will re-open the ticket and indicate that Section 7 should be amended. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 15, 2014, at 6:11 AM, ueda@exgen.co.jp wrote: > Hello, >=20 > I have a question about enterprise user extension. >=20 > In section 7 of schema document, enterprise user's URI is > "urn:scim:schemas:extension:enterprise:2.0:EnterpriseUser". > But section 12 is > "urn:scim:schemas:extension:enterprise:2.0:User", > and api document is=20 > "urn:scim:schemas:extension:enterprise:2.0:User". >=20 > Which is right? >=20 > - > Takanori Ueda. >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Sun Jun 15 17:57:28 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830B01B299D for ; Sun, 15 Jun 2014 17:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6DuFQLQXggY for ; Sun, 15 Jun 2014 17:57:24 -0700 (PDT) Received: from c15s9xb8.securesites.net (c15s9xb8.securesites.net [118.23.75.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BFB61B2997 for ; Sun, 15 Jun 2014 17:57:24 -0700 (PDT) Received: from [192.168.2.236] (122x220x11x94.ap122.ftth.ucom.ne.jp [122.220.11.94]) (authenticated bits=0) by c15s9xb8.securesites.net (8.14.5/8.13.1) with ESMTP id s5G0vKTM024424; Mon, 16 Jun 2014 09:57:22 +0900 MIME-Version: 1.0 Date: Mon, 16 Jun 2014 09:57:24 +0900 Message-ID: In-Reply-To: <6C17B827-2CA8-40C9-AE86-951922F4DBD9@oracle.com> References: <6C17B827-2CA8-40C9-AE86-951922F4DBD9@oracle.com> From: ueda@exgen.co.jp To: Phil Hunt X-Mailer: JsvMail 9.0 (Shuriken 2009) Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/GjklUotsADJRVCWLnuZhb6bjvdE Cc: scim@ietf.org Subject: Re: [scim] EnterpriseUser's URI X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 00:57:27 -0000 Phil, It understood. Thank you! - Takanori Ueda. Phil Hunt $B!'(B > Takanori, > > Thanks for pointing this out. > > It looks like one of the URIs was missed when we corrected in SCIM WG Ticket #63. > > The ticket indicates it should be: urn:scim:schemas:extension:enterprise:2.0:User > > I will re-open the ticket and indicate that Section 7 should be amended. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jun 15, 2014, at 6:11 AM, ueda@exgen.co.jp wrote: > > > Hello, > > > > I have a question about enterprise user extension. > > > > In section 7 of schema document, enterprise user's URI is > > "urn:scim:schemas:extension:enterprise:2.0:EnterpriseUser". > > But section 12 is > > "urn:scim:schemas:extension:enterprise:2.0:User", > > and api document is > > "urn:scim:schemas:extension:enterprise:2.0:User". > > > > Which is right? > > > > - > > Takanori Ueda. > > > > _______________________________________________ > > scim mailing list > > scim@ietf.org > > https://www.ietf.org/mailman/listinfo/scim > From nobody Mon Jun 16 04:15:13 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582741B2BBC for ; Mon, 16 Jun 2014 04:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWT8tDEMzvlR for ; Mon, 16 Jun 2014 04:15:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74721B2BBA for ; Mon, 16 Jun 2014 04:15:09 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MWk3f-1XFykq0XCF-00Xwu2; Mon, 16 Jun 2014 13:15:07 +0200 Message-ID: <539ED1B9.9070300@gmx.de> Date: Mon, 16 Jun 2014 13:15:05 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ueda@exgen.co.jp, scim@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:NSsLsHuW8mcFtp+3f/1IChTem7aiD/xI4uw94Sykk/Ql/r/gzBK mvGz/Q7emXzWKeWfBcNAG8Ro4uc0ffhErsDjxnVLP9fD5HV4Paw+djI38L/Oqa6CZWkPOzy tm62c4upa3B6miQh8DVcbaA6lsmK9zhMlJEis39KOj86FGA9MwtZxvHW8OslaADHG5wM/v7 WCcTBJIj+BOnEMQGMvcTw== Archived-At: http://mailarchive.ietf.org/arch/msg/scim/l5KRdAg2TYSIip27cwOzHMmdnW8 Subject: Re: [scim] EnterpriseUser's URI X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 11:15:11 -0000 On 2014-06-15 15:11, ueda@exgen.co.jp wrote: > Hello, > > I have a question about enterprise user extension. > > In section 7 of schema document, enterprise user's URI is > "urn:scim:schemas:extension:enterprise:2.0:EnterpriseUser". > But section 12 is > "urn:scim:schemas:extension:enterprise:2.0:User", > and api document is > "urn:scim:schemas:extension:enterprise:2.0:User". > > Which is right? > ... Speaking of which, who's going to register the "scim" NIS? (see http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml) Best regards, Julian From nobody Mon Jun 16 04:40:39 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C73A1B2BB7 for ; Mon, 16 Jun 2014 04:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xFrDtQLA5NP for ; Mon, 16 Jun 2014 04:40:35 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF271B2BBF for ; Mon, 16 Jun 2014 04:40:35 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id q8so662901lbi.20 for ; Mon, 16 Jun 2014 04:40:33 -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=iH4t8Xi3S0eITZkLp6joZkXQ2UhXjwBsoEiWKCMKJBw=; b=Ig4RUHAN+fP+B4YX+SS0yYrMBiun1aAEdNRCcIIKf75eudFt6bnRz4zI7itv5QIa0E N7+aiuyezCpZqHJhtTIxuhLK3uy6OlApBYWWv7Xt+vd3Emst/L93+uKjMI7QRCPlTUC1 Fm5CTAgOlYJRi+G8/KoRVf6eKaGnq6tVq9U/j+rzQ06LNRune9zhLH1y4lTfwh+gVhhm xVUvCZOQARIrBjsBJ99wKH12Zn/08wiB6V50cM3X1a2b2sP3BnFwYZQRHQUfXsjmD4q0 GraWcu48Vx6z2Dt3Uuk9s3jzHZeRRHxb/aIzq99n3qEewo8fCz0P6f//ksIi5IUmkAyf IH4g== X-Gm-Message-State: ALoCoQkps6Zx22DHyLwx/7y9WabK2xI5M7zQ0kEkTEfjistCCcKe98wfhan9QIv5k7g3nvLdT/3X X-Received: by 10.112.173.136 with SMTP id bk8mr286130lbc.99.1402918833396; Mon, 16 Jun 2014 04:40:33 -0700 (PDT) Received: from [192.36.125.225] (dhcp.pilsnet.sunet.se. [192.36.125.225]) by mx.google.com with ESMTPSA id l8sm8451097lbh.26.2014.06.16.04.40.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Jun 2014 04:40:32 -0700 (PDT) Message-ID: <539ED7B0.8040601@mnt.se> Date: Mon, 16 Jun 2014 13:40:32 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: scim@ietf.org References: <539ED1B9.9070300@gmx.de> In-Reply-To: <539ED1B9.9070300@gmx.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/zYUeKgG_mkq4i_hkzNaXus7v10c Subject: Re: [scim] EnterpriseUser's URI X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 11:40:37 -0000 On 2014-06-16 13:15, Julian Reschke wrote: > On 2014-06-15 15:11, ueda@exgen.co.jp wrote: >> Hello, >> >> I have a question about enterprise user extension. >> >> In section 7 of schema document, enterprise user's URI is >> "urn:scim:schemas:extension:enterprise:2.0:EnterpriseUser". >> But section 12 is >> "urn:scim:schemas:extension:enterprise:2.0:User", >> and api document is >> "urn:scim:schemas:extension:enterprise:2.0:User". >> >> Which is right? >> ... > > Speaking of which, who's going to register the "scim" NIS? (see > http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml) Good catch. We should probably use the urn:ietf:params namespace and include this in the IANA section - cf http://www.iana.org/assignments/params/params.xhtml Cheers Leif > > Best regards, Julian > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon Jun 16 10:48:13 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0184A1A0156 for ; Mon, 16 Jun 2014 10:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFVFe91W4zN8 for ; Mon, 16 Jun 2014 10:47:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF94A1A0126 for ; Mon, 16 Jun 2014 10:47:32 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5GHlS6x021192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jun 2014 17:47:29 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5GHlOUx010983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2014 17:47:26 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5GHlN7Q028076; Mon, 16 Jun 2014 17:47:24 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Jun 2014 10:47:23 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: <539ED7B0.8040601@mnt.se> Date: Mon, 16 Jun 2014 10:47:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <539ED1B9.9070300@gmx.de> <539ED7B0.8040601@mnt.se> To: Leif Johansson , Julian Reschke X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Dfw15MlL6s7YGavnKONnv2a5nig Cc: scim@ietf.org Subject: Re: [scim] EnterpriseUser's URI X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 17:48:02 -0000 Is there a need to register the namespace for the scim registry that was = established in: http://tools.ietf.org/html/draft-ietf-scim-core-schema-05#section-14 Draft 06 of the API will also register the JSON messages as part of the = registry in section 14 above. I hope to have it out shortly. Do we then need a separate namespace registration for the registry = established in section 14? I=92m not sure we need to register with the IETF params namespace. = AFAIK, SCIM schema is not really a protocol parameter. The parameters in = the SCIM API do not use URIs and are not extensible (e.g. totalResults, = startIndex, filter, attributes, ...). ps. Regarding Takanori=92s original post, I note we also have the same = inconsistency for enterprise user between section 12, 7, and 14.2 (where = enterpriseUser is registered). Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 16, 2014, at 4:40 AM, Leif Johansson wrote: > On 2014-06-16 13:15, Julian Reschke wrote: >> On 2014-06-15 15:11, ueda@exgen.co.jp wrote: >>> Hello, >>>=20 >>> I have a question about enterprise user extension. >>>=20 >>> In section 7 of schema document, enterprise user's URI is >>> "urn:scim:schemas:extension:enterprise:2.0:EnterpriseUser". >>> But section 12 is >>> "urn:scim:schemas:extension:enterprise:2.0:User", >>> and api document is >>> "urn:scim:schemas:extension:enterprise:2.0:User". >>>=20 >>> Which is right? >>> ... >>=20 >> Speaking of which, who's going to register the "scim" NIS? (see >> http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml) >=20 > Good catch. We should probably use the urn:ietf:params namespace and > include this in the IANA section - cf > http://www.iana.org/assignments/params/params.xhtml >=20 > Cheers Leif >=20 >>=20 >> Best regards, Julian >>=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 From nobody Mon Jun 16 11:53:29 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8411A014C for ; Mon, 16 Jun 2014 11:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfTlUjPfYxGC for ; Mon, 16 Jun 2014 11:53:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9881A013B for ; Mon, 16 Jun 2014 11:53:18 -0700 (PDT) Received: from [192.168.2.117] ([93.217.68.72]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lurin-1Wni3s0QpV-0107ma; Mon, 16 Jun 2014 20:53:13 +0200 Message-ID: <539F3D18.4070502@gmx.de> Date: Mon, 16 Jun 2014 20:53:12 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Phil Hunt , Leif Johansson References: <539ED1B9.9070300@gmx.de> <539ED7B0.8040601@mnt.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:cOiirNg98anKTNf4aGFw/njD60GV+/MZ66JfUNKUa2Ka/3Oqy04 BsYLjetX0L+MiLuME2DoCFywa6GqQlWY3oOw1+zmaP7jKpVdxXvTL56oi1nfZH9wC92GU2W Ccj/jh1kQ92L6KIZsk1bNHa87FufXLlJKdkUtLcFsiSP2x8UV7+a4Oc/XmJoT8c8ISKFy8K gb909KzRCRF7KNqdTwSRA== Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ougnEwYG-hvnwEMEiwD_Hwq5EEM Cc: scim@ietf.org Subject: Re: [scim] EnterpriseUser's URI X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 18:53:23 -0000 On 2014-06-16 19:47, Phil Hunt wrote: > Is there a need to register the namespace for the scim registry that was established in: > http://tools.ietf.org/html/draft-ietf-scim-core-schema-05#section-14 Yes, you'll need to register the URN namespaces (or use something that doesn't need registration, such as a HTTP URI). > ... Best regards, Julian From nobody Mon Jun 16 15:24:47 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446121A0290 for ; Mon, 16 Jun 2014 15:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM0gSDjoQqQM for ; Mon, 16 Jun 2014 15:24:44 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D4C1A0285 for ; Mon, 16 Jun 2014 15:24:43 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5GMOcVQ007558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jun 2014 22:24:39 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5GMOcZa022370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Jun 2014 22:24:38 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5GMObXJ024856; Mon, 16 Jun 2014 22:24:38 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Jun 2014 15:24:37 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_05FD9986-A19E-450C-BB8A-1544E3901642" Date: Mon, 16 Jun 2014 15:24:35 -0700 Message-Id: <16FB60C9-8059-4AF5-AF6B-0F26A91963F0@oracle.com> To: Scim WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Kx2ebfQqYPRZxcyGPpbEQ9LCZm4 Cc: Julian Reschke Subject: [scim] URIs for schemas vs. api messages X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 22:24:45 -0000 --Apple-Mail=_05FD9986-A19E-450C-BB8A-1544E3901642 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am just going through all of the IANA issues and about to register the = SCIM namespace. Looking at how we are using URIs, I notice that we are using the same = base URI of "urn:scim:schemas:core:2.0" for both core schema AND for API = messages. For example, for the search request: urn:scim:schemas:core:2.0:SearchRequest Shouldn=92t the URI be something like: urn:scim:messages:api:2.0:SearchRequest If we follow this format, then all of the following URIs would change: urn:scim:schemas:core:2.0:ListResponse=20 urn:scim:schemas:core:2.0:SearchRequest urn:scim:schemas:core:2.0:PatchOp urn:scim:schemas:core:2.0:BulkRequest urn:scim:schemas:core:2.0:BulkResponse urn:scim:schemas:core:2.0:Error The IANA registration for our URI would be to register =93scim=94 as the = base and establish a short name, sub-name, and version naming format of: urn:scim:{shortname}:{subname}:{scimvers} In the specs then, {shortname} would be =93messages=94 or =93schemas=94, = and {subname} would be {core} for core-schema, =93extension=94 for the = extension schema (e.g. enterprise user) and, uri:scim:messages:api:2.0 = for the JSON messages in the SCIM 2 API running over HTTP. Does this make sense? Or is there more history to this from SCIM 1? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_05FD9986-A19E-450C-BB8A-1544E3901642 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I am = just going through all of the IANA issues and about to register the SCIM = namespace.

Looking at how we are using URIs, I notice = that we are using the same base URI of "urn:scim:schemas:core:2.0" for = both core schema AND for API messages.

For = example, for the search = request:
urn:scim:schemas:core:2.0:SearchRequest

Shouldn=92t the URI be = something like:
urn:scim:messages:api:2.0:SearchRequest

If = we follow this format, then all of the following URIs would = change:
urn:scim:schemas:core:2.0:ListResponse 
urn:scim:schemas:core:2.0:SearchRequest
urn:scim:schemas:core:2.0:PatchOp
urn:scim:schemas:core:2.0:BulkRequest
urn:scim:schemas:core:2.0:BulkResponse
urn:scim:schemas:core:2.0:Error

The = IANA registration for our URI would be to register =93scim=94 as the = base and establish a short name, sub-name, and version naming format = of:

urn:scim:{shortname}:{subname}:{scimvers}

In = the specs then, {shortname} would be =93messages=94 or =93schemas=94, = and {subname} would be {core} for core-schema, =93extension=94 for the = extension schema (e.g. enterprise user) and, uri:scim:messages:api:2.0 = for the JSON messages in the SCIM 2 API running over HTTP.

Does this make sense? Or is there more history to this from SCIM = 1?

Phil

@independentid
phil.hunt@oracle.com



= --Apple-Mail=_05FD9986-A19E-450C-BB8A-1544E3901642-- From nobody Mon Jun 16 16:20:36 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF341A02BE for ; Mon, 16 Jun 2014 16:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ImhPax02Dh5 for ; Mon, 16 Jun 2014 16:20:28 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E06E1A02BD for ; Mon, 16 Jun 2014 16:20:28 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5GNKOmo026530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jun 2014 23:20:25 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 s5GNKNYq020902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2014 23:20:24 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5GNKNIt001611; Mon, 16 Jun 2014 23:20:23 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Jun 2014 16:20:23 -0700 References: <16FB60C9-8059-4AF5-AF6B-0F26A91963F0@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: <16FB60C9-8059-4AF5-AF6B-0F26A91963F0@oracle.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2978577B-7E1F-4478-893D-F107DA6AB9B5 Content-Transfer-Encoding: 7bit Message-Id: <8D86BBB9-3BD2-4E15-A81B-53203FA03D55@oracle.com> X-Mailer: iPhone Mail (11D201) From: Phil Hunt Date: Mon, 16 Jun 2014 16:20:22 -0700 To: Scim WG X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/XcUZ5K6nmOwZtoQRoIJ5txs9RZk Cc: Julian Reschke Subject: Re: [scim] URIs for schemas vs. api messages X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 23:20:34 -0000 --Apple-Mail-2978577B-7E1F-4478-893D-F107DA6AB9B5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable One more thought. I think the designation of urn:scim:schemas was to be a ba= se for all uris referenced in the schemas attribute.=20 If this is the case maybe we should use urn:scim:schemas:messages for scim a= pi messages? Phil > On Jun 16, 2014, at 15:24, Phil Hunt wrote: >=20 > I am just going through all of the IANA issues and about to register the S= CIM namespace. >=20 > Looking at how we are using URIs, I notice that we are using the same base= URI of "urn:scim:schemas:core:2.0" for both core schema AND for API message= s. >=20 > For example, for the search request: > urn:scim:schemas:core:2.0:SearchRequest >=20 > Shouldn=E2=80=99t the URI be something like: > urn:scim:messages:api:2.0:SearchRequest >=20 > If we follow this format, then all of the following URIs would change: > urn:scim:schemas:core:2.0:ListResponse > urn:scim:schemas:core:2.0:SearchRequest > urn:scim:schemas:core:2.0:PatchOp > urn:scim:schemas:core:2.0:BulkRequest > urn:scim:schemas:core:2.0:BulkResponse > urn:scim:schemas:core:2.0:Error >=20 > The IANA registration for our URI would be to register =E2=80=9Cscim=E2=80= =9D as the base and establish a short name, sub-name, and version naming for= mat of: >=20 > urn:scim:{shortname}:{subname}:{scimvers} >=20 > In the specs then, {shortname} would be =E2=80=9Cmessages=E2=80=9D or =E2=80= =9Cschemas=E2=80=9D, and {subname} would be {core} for core-schema, =E2=80=9C= extension=E2=80=9D for the extension schema (e.g. enterprise user) and, uri:= scim:messages:api:2.0 for the JSON messages in the SCIM 2 API running over H= TTP. >=20 > Does this make sense? Or is there more history to this from SCIM 1? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-2978577B-7E1F-4478-893D-F107DA6AB9B5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
One more thought. I think the designat= ion of urn:scim:schemas was to be a base for all uris referenced in the sche= mas attribute. 

If this is the case maybe we s= hould use urn:scim:schemas:messages for scim api messages?

Phi= l

On Jun 16, 2014, at 15:24, Phil Hunt <phil.hunt@oracle.com> wrote:

I am just going through all of the IANA issues a= nd about to register the SCIM namespace.

Looking at how w= e are using URIs, I notice that we are using the same base URI of "urn:scim:= schemas:core:2.0" for both core schema AND for API messages.

<= /div>
For example, for the search request:
urn:scim:schemas:co= re:2.0:SearchRequest

Shouldn=E2=80=99t the URI= be something like:
urn:scim:messages:a= pi:2.0:SearchRequest

If we follow this format, then all of the following U= RIs would change:
urn:scim:schemas:core:2.0:ListResponse 
urn:scim:sche= mas:core:2.0:SearchRequest
urn:scim:schemas:core:2.0:PatchOp
urn:scim:sche= mas:core:2.0:BulkRequest
urn:scim:schemas:core:2.0:BulkResponse
urn:scim:s= chemas:core:2.0:Error

=
The IANA registration for our URI woul= d be to register =E2=80=9Cscim=E2=80=9D as the base and establish a short na= me, sub-name, and version naming format of:

urn:scim:{shortname}:{subname= }:{scimvers}

In the specs then, {shortname} would be =E2=80=9Cmessages=E2= =80=9D or =E2=80=9Cschemas=E2=80=9D, and {subname} would be {core} for core-= schema, =E2=80=9Cextension=E2=80=9D for the extension schema (e.g. enterpris= e user) and, uri:scim:messages:api:2.0 for the JSON messages in the SCIM 2 A= PI running over HTTP.

Does this make sense? Or is there more history to t= his from SCIM 1?

Phil

= @independentid
phil.hunt@oracle.com


__________= _____________________________________
scim mailing list
scim@ietf.org
https://www.ietf.o= rg/mailman/listinfo/scim
= --Apple-Mail-2978577B-7E1F-4478-893D-F107DA6AB9B5-- From nobody Wed Jun 18 01:51:05 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC3B1A00B6 for ; Wed, 18 Jun 2014 01:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMFRPyvTD_en for ; Wed, 18 Jun 2014 01:51:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C441A0099 for ; Wed, 18 Jun 2014 01:50:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFO05034; Wed, 18 Jun 2014 08:50:58 +0000 (GMT) Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Jun 2014 09:50:57 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.214]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 16:50:44 +0800 From: Likepeng To: Bert Greevenbosch , "scim@ietf.org" Thread-Topic: Comments on SCIM use cases draft Thread-Index: Ac80U7F22qnyVrgbSjS4DDnIQc0t+RWeejVQ Date: Wed, 18 Jun 2014 08:50:44 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F25815CE1C@SZXEMA501-MBS.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB63E44C4D1@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E44C4D1@SZXEMA510-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Bee2ViRMutezFaP65fDZ4kPe83U Subject: Re: [scim] Comments on SCIM use cases draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 08:51:02 -0000 SGVsbG8gQmVydCwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyBjb21tZW50cy4NCg0KPiBbQkcx XSBTZWN0aW9uIDIuMi4xLCAzZCBsaW5lOiBjaGFuZ2UgImlkZW50aXR5IiB0byAiaWRlbnRpZnki Lg0KDQpPSy4gQ2hhbmdlZCBpbiAtMDIuDQoNCj4gW0JHMl0gU2VjdGlvbiAyLjIuMSwgdGhlIGFi YnJldmlhdGlvbiAiQy5SLlUuRC4iIGlzIGV4cGFuZGVkLCB3aGVyZWFzICJTU08iIGlzIG5vdC4g DQo+SSBzdWdnZXN0IHRvIGV4cGFuZCBTU08gdG9vLg0KDQpPSy4gQ2hhbmdlZCBpbiAtMDIuDQoN Cj4gW0JHM10gU2VjdGlvbiAyLjIuMSwgSSBhbSBub3QgY2xlYXIgb24gdGhlIHZhcmlvdXMgdHJp Z2dlcnMuIEVhY2ggaXRlbSBoYXMgdGhlDQo+IG5hbWUgb2YgYSB0cmlnZ2VyLCBidXQgaW4gdGhl IGRlc2NyaXB0aW9uIHRoZXJlIGlzIGFub3RoZXIgbmFtZSBvZiBhIHRyaWdnZXIuIEZvcg0KPiBl eGFtcGxlLCBpbiB0aGUgZmlyc3QgaXRlbSB0aGVyZSBpcyAiQ3JlYXRlIFNDSU0gSWRlbnRpdHkg UmVzb3VyY2UgLSBTZXJ2aWNlDQo+IE9uLWJvYXJkaW5nIFRyaWdnZXIiLCBhbmQgaW4gdGhlIGRl c2NyaXB0aW9uICJjcmVhdGUgU0NJTSByZXNvdXJjZSB0cmlnZ2VyIi4NCj4gQXJlIHRoZXNlIHRo ZSBzYW1lPyBUaGVuIHVzZSBhIHNpbmdsZSBuYW1lLiBBbHNvLCBmb3IgcmVhZGFiaWxpdHkgSSBz dWdnZXN0IHRvDQo+IHB1dCB0aGUgbmFtZSBiZXR3ZWVuIHF1b3RlcywgZS5nLiAiY3JlYXRlIFND SU0gcmVzb3VyY2UiIHRyaWdnZXIuDQoNCk9LLiBDaGFuZ2VkIGluIC0wMi4NCg0KPiBbQkc0XSBT ZWN0aW9uIDIuMi4xLCBmaXJzdCBpdGVtIGxhc3Qgc2VudGVuY2UsIGFkZCAiLCBhbmQiIGJldHdl ZW4NCj4gImltcGxlbWVudGF0aW9uIiBhbmQgIm5vdCB0byB0aGUgdXNlIGNhc2VzIi4NCg0KT0su IENoYW5nZWQgaW4gLTAyLg0KDQo+IFtCRzVdIFNlY3Rpb24gMi4yLjIsIHNlY29uZCBpdGVtOiBy ZXBsYWNlICJlbnRpdGxlIiBieSAiZW50aXR5Ii4NCg0KT0suIENoYW5nZWQgaW4gLTAyLg0KDQo+ IFtCRzZdIFNlY3Rpb24gMi4yLjIsIHRoaXJkIGl0ZW06IHJlcGxhY2UgImVuZC1lbmQiIGJ5ICJl bmQiLg0KDQpPSy4gQ2hhbmdlZCBpbiAtMDIuDQoNCj4gW0JHN10gU2VjdGlvbiAyLjIuMywgInJl YWwgd29yayB1c2UgY2FzZXMiIC0+ICJyZWFsIHdvcmxkIHVzZSBjYXNlcyIuDQoNCk9LLiBDaGFu Z2VkIGluIC0wMi4NCg0KPiBbQkc4XSBTZWN0aW9uIDIuMy4zOiAiVGhpcyB1c2UgY2FzZSBoaWdo bGlnaHRzIGhvdyBkaWZmZXJlbnQgQ1NQcyBtYXkNCj4gaW1wbGVtZW50IGRpZmZlcmVudCBvcGVy YXRpb25hbCBzZW1hbnRpY3MgYmVoaW5kIHRoZSBzYW1lIFNDSU0gb3BlcmF0aW9uLg0KPiBOb3Rl IHRoYXQgQ1NQLTEgc3VzcGVuZHMgdGhlIGFjY291bnQgcmVwcmVzZW50YXRpb24gZm9yIGl0cyBz ZXJ2aWNlIHdoZXJlYXMNCj4gQ1BTLTIgaW1wbGVtZW50cyBhIHRydWUgZGVsZXRlIG9wZXJhdGlv bi4iDQo+IEludGVyZXN0aW5nIGlkZWEuIElzIGl0IHRydWx5IGRlc2lyZWQgdG8gaGF2ZSBkaWZm ZXJlbnQgQ1NQcyB0cmVhdCB0aGUgc2FtZQ0KPiByZXF1ZXN0IGRpZmZlcmVudGx5PyBPYnZpb3Vz bHkgdGhlcmUgd2lsbCBhbHdheXMgYmUgc29tZSBkaWZmZXJlbmNlIGJldHdlZW4NCj4gaW1wbGVt ZW50YXRpb25zLCBidXQgdGhpcyBkaWZmZXJlbmNlIHNlZW1zIHF1aXRlIGJpZy4NCj4gT24gdGhl IG90aGVyIGhhbmQsIG1heWJlIHRoaXMgaXMgYWxzbyBub3QgdHJ1bHkgdGhlIHNhbWUgU0NJTSBv cGVyYXRpb24sIHNpbmNlDQo+IENTUC0xIHJlY2VpdmVzIHRoZSB0cmlnZ2VyIGZyb20gdGhlIEVD Uywgd2hlcmVhcyBDU1AtMiByZWNlaXZlcyBhIHRlcm1pbmF0aW9uDQo+IHJlcXVlc3QgZnJvbSBD U1AtMS4NCg0KSSBjaGFuZ2VkIHRoZSBzZW50ZW5jZSB0byB0aGUgZm9sbG93aW5nIHRvIGNsYXJp ZnkgdGhhdDoNCiAgIEFmdGVyIHJlY2VpdmluZyB0aGUgY29uZmlybWF0aW9uIGZyb20gQ1NQLTIs IENTUC0xDQogICBmaW5hbGl6ZXMgdGhlIGRlbGV0aW9uIG9wZXJhdGlvbiBhbmQgc2VuZHMgYW4g YWNrbm93bGVkZ21lbnQgdG8gdGhlDQogICByZXF1ZXN0aW5nIEVDUy4NCg0KPiBbQkc5XSBTZWN0 aW9uIDIuMi40LCBsYXN0IHNlbnRlbmNlOg0KPiAiSG93ZXZlciwgcmF0aGVyIHRoYW4gcHJlLXBy b3Zpc2lvbmluZyBhY2NvdW50cyBmcm9tIEVDUy0xIHRvIENTUC0xLCBDU1AtMQ0KPiB3YWl0cyBm b3IgYSBzZXJ2aWNlIGFjY2VzcyByZXF1ZXN0IGZyb20gdGhlIENsb3VkIFNlcnZpY2UgVXNlciAo Q1NVLTEpIHVuZGVyDQo+IHRoZSBjb250cm9sIGRvbWFpbiBvZiBFQ1MtMSwgYmVmb3JlIGlzc3Vp bmcgYW4gYWNjb3VudCBQdWxsIHJlcXVlc3QgdG8gQ1NQLTEuIg0KPiBTb21ldGhpbmcgc2VlbXMg d3JvbmcgaW4gdGhpcyBzZW50ZW5jZSwgYXMgaXQgc2VlbXMgdG8gc2F5IHRoYXQgQ1NQLTEgaXNz dWVzIGENCj4gUHVsbCByZXF1ZXN0IHRvIGl0c2VsZi4gTWF5YmUgdGhlIGFjY291bnQgUHVsbCBy ZXF1ZXN0IGlzIHNlbnQgdG8gIkVDUy0xIiwgbm90IHRvDQo+ICJDU1AtMSI/DQoNClRoZSBjb21t ZW50IGFjdHVhbGx5IGlzIHRvIHNlY3Rpb24gMi40LjQuIFllcywgaXQgc2hvdWxkIGJlICJFQ1Mt MSIuIENoYW5nZWQgaW4gLTAyLg0KDQo+IFtCRzEwXSBJbiB2YXJpb3VzIHVzZSBjYXNlcywgdGhl cmUgYXJlIHJlcXVpcmVtZW50cyBmb3IgbG9ncy4gSG93ZXZlciwgdGhlcmUgaXMNCj4gbm8gdGV4 dCBpbiB0aGUgdXNlIGNhc2VzIGl0c2VsZi4gTWF5YmUgaXQgd291bGQgYmUgYmV0dGVyIHRvIGVs YWJvcmF0ZSBhIGJpdCBvbg0KPiB0aGUgbG9ncyBpbiB0aGUgdXNlIGNhc2VzPyBUaGlzIHNob3Vs ZCBhbHNvIGludm9sdmUgdGhlIG1lbnRpb25lZCBhdWRpdGluZy4NCg0KU3RvcmluZyBpbmZvcm1h dGlvbiBpcyBtZW50aW9uZWQgaW4gdGhlIHVzZSBjYXNlcy4gVGhhdCBjYW4gZGVyaXZlIHRoZSBs b2cgcmVxdWlyZW1lbnQuDQoNCj4gW0JHMTFdIFNlY3Rpb24gMy40LCB0aGUgc2VudGVuY2UgIlRo ZSBsb2NhbCBZb3VyQ29JIG9mZmljZXMgYXJlIHJlc3BvbnNpYmxlIGZvcg0KPiBlc3RhYmxpc2hp bmcgcGVyc29uYWwgaW5mb3JtYXRpb24gYW5kIChpLmUuLCBzZXR0aW5nIHRoZSB1c2VyIGlkZW50 aXRpZXMgYW5kDQo+IGF0dHJpYnV0ZXMpLiIgbmVlZHMgd29yZHNtaXRoaW5nLg0KDQpJIGNoYW5n ZWQgdGhlIHNlbnRlbmNlIHRvIHRoZSBmb2xsb3dpbmc6DQogICBUaGUgbG9jYWwgWW91ckNvSSBv ZmZpY2VzIGFyZSByZXNwb25zaWJsZSBmb3IgY29sbGVjdGluZw0KICAgcGVyc29uYWwgaW5mb3Jt YXRpb24oaS5lLiB1c2VyIGlkZW50aXRpZXMgYW5kIGF0dHJpYnV0ZXMpLiAgDQoNCj4gW0JHMTJd IFNlY3Rpb24gMy40LCAiSWRlbnRpdHkgbWFuYWdlbWVudCBvZiB0aGUgcGVyc29uYWwgZGF0YSBt dXN0IGJlDQo+IHNlY3VyZSIgaXMgYSBiaXQgdmFndWUuIEkgZ3Vlc3MgaXQgbWVhbnMgcHJvdGVj dGVkIGFnYWluc3QgdW5hdXRob3Jpc2VkIGFjY2Vzcw0KPiBhbmQgcmVtYWluaW5nIGNvbmZpZGVu dGlhbGl0eT8gVGhlbiBtYXliZSB0aGUgZm9sbG93aW5nIHdvcmRpbmcgd291bGQgYmUNCj4gYmV0 dGVyOiAiSWRlbnRpdHkgbWFuYWdlbWVudCBvZiB0aGUgcGVyc29uYWwgZGF0YSBtdXN0IGJlIHBy b3RlY3RlZCBhZ2FpbnN0DQo+IHVuYXV0aG9yaXNlZCBhY2Nlc3MgYW5kIHJlbWFpbiBjb25maWRl bnRpYWwgdG8gb25seSBhdXRob3Jpc2VkIHBhcnRpZXMuIg0KDQpPSywgY2hhbmdlZCBpbiAtMDIu DQoNCj4gW0JHMTNdIFNlY3Rpb24gMy41OiBzaG91bGQgdGhlcmUgYmUgYSByZXF1aXJlbWVudCBm b3IgZXhwaXJhdGlvbiBvZiB0aGUgY2FjaGVkDQo+IGNvcHksIGkuZS4gYSBtYXhpbXVtIHBlcmlv ZCBmb3Igd2hpY2ggdGhlIHJlbHlpbmcgcGFydHkgbWF5IGNhY2hlIHRoZQ0KPiBpbmZvcm1hdGlv bj8NCg0KT0ssIEkgYWRkZWQgdGhpcyBzZW50ZW5jZToNCkEgbWF4aW11bSBwZXJpb2Qgc2hvdWxk IGJlIHNldCBmb3IgdGhlIHJlbHlpbmcgcGFydHkgdG8gY2FjaGUgdGhlIGluZm9ybWF0aW9uLg0K DQo+IFtCRzE0XSBUaGUgInNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIiBzZWN0aW9uIGlzIHJhdGhl ciBzaG9ydCwgb25seSBtZW50aW9uaW5nDQo+IGF1dGhvcmlzYXRpb24gYW5kIGF1dGhlbnRpY2F0 aW9uLiBJdCB3b3VsZCBiZSBnb29kIHRvIGFkZCBzb21lIHRleHQgYWJvdXQNCj4gY29uZmlkZW50 aWFsaXR5IGFuZCBwcml2YWN5IHByb3RlY3Rpb24uDQoNCk9LLCBJIGFkZGVkIHRoZSBmb2xsb3dp bmcgdHdvIHBhcmFncmFwaHMgdG8gdGhlICJTZWN1cml0eSBDb25zaWRlcmF0aW9ucyIgc2VjdGlv bjoNCg0KICAgU0NJTSByZXNvdXJjZXMgKGUuZy4sIFVzZXJzIGFuZCBHcm91cHMpIGNhbiBjb250 YWluIHNlbnNpdGl2ZQ0KICAgaW5mb3JtYXRpb24uICBUaGVyZWZvcmUsIGF1dGhlbnRpY2F0aW9u IGFuZCBhdXRob3JpemF0aW9uIG11c3QgYmUNCiAgIGd1YXJhbnRlZWQgZm9yIHRoZSBTQ0lNIG9w ZXJhdGlvbnMuDQoNCiAgIEFsc28sIHByaXZhdGUgaW5mb3JtYXRpb24gb2YgdGhlIFNDSU0gcmVz b3VyY2VzIG11c3QgYmUga2VwdA0KICAgY29uZmlkZW50aWFsIGFuZCBwcm90ZWN0ZWQuDQoNCkkg d2lsbCB1cGxvYWQgLTAyIHNvb24uDQoNClRoYW5rcywNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoN Cj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7Iyzogc2NpbSBbbWFpbHRvOnNjaW0tYm91bmNl c0BpZXRmLm9yZ10gtPqx7SBCZXJ0IEdyZWV2ZW5ib3NjaA0KPiC3osvNyrG85DogMjAxNMTqMtTC MjjI1SAxNTowNw0KPiDK1bz+yMs6IHNjaW1AaWV0Zi5vcmcNCj4g1vfM4jogW3NjaW1dIENvbW1l bnRzIG9uIFNDSU0gdXNlIGNhc2VzIGRyYWZ0DQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBJIGhhdmUg cmV2aWV3ZWQgdGhlIFNDSU0gdXNlIGNhc2VzIGRyYWZ0Og0KPiANCj4gaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zY2ltLXVzZS1jYXNlcy0wMA0KPiANCj4gSSBoYXZlIHNv bWUgY29tbWVudHMgbGlzdGVkIGJlbG93LiBJIHRoaW5rIHRoZXkgYXJlIG5vdCB0b28gZGlmZmlj dWx0IHRvDQo+IGhhbmRsZS4gOi0pDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IEJlcnQNCj4gDQo+ IC0tLQ0KPiANCj4gW0JHMV0gU2VjdGlvbiAyLjIuMSwgM2QgbGluZTogY2hhbmdlICJpZGVudGl0 eSIgdG8gImlkZW50aWZ5Ii4NCj4gDQo+IFtCRzJdIFNlY3Rpb24gMi4yLjEsIHRoZSBhYmJyZXZp YXRpb24gIkMuUi5VLkQuIiBpcyBleHBhbmRlZCwgd2hlcmVhcyAiU1NPIiBpcw0KPiBub3QuIEkg c3VnZ2VzdCB0byBleHBhbmQgU1NPIHRvby4NCj4gDQo+IFtCRzNdIFNlY3Rpb24gMi4yLjEsIEkg YW0gbm90IGNsZWFyIG9uIHRoZSB2YXJpb3VzIHRyaWdnZXJzLiBFYWNoIGl0ZW0gaGFzIHRoZQ0K PiBuYW1lIG9mIGEgdHJpZ2dlciwgYnV0IGluIHRoZSBkZXNjcmlwdGlvbiB0aGVyZSBpcyBhbm90 aGVyIG5hbWUgb2YgYSB0cmlnZ2VyLiBGb3INCj4gZXhhbXBsZSwgaW4gdGhlIGZpcnN0IGl0ZW0g dGhlcmUgaXMgIkNyZWF0ZSBTQ0lNIElkZW50aXR5IFJlc291cmNlIC0gU2VydmljZQ0KPiBPbi1i b2FyZGluZyBUcmlnZ2VyIiwgYW5kIGluIHRoZSBkZXNjcmlwdGlvbiAiY3JlYXRlIFNDSU0gcmVz b3VyY2UgdHJpZ2dlciIuDQo+IEFyZSB0aGVzZSB0aGUgc2FtZT8gVGhlbiB1c2UgYSBzaW5nbGUg bmFtZS4gQWxzbywgZm9yIHJlYWRhYmlsaXR5IEkgc3VnZ2VzdCB0bw0KPiBwdXQgdGhlIG5hbWUg YmV0d2VlbiBxdW90ZXMsIGUuZy4gImNyZWF0ZSBTQ0lNIHJlc291cmNlIiB0cmlnZ2VyLg0KPiAN Cj4gW0JHNF0gU2VjdGlvbiAyLjIuMSwgZmlyc3QgaXRlbSBsYXN0IHNlbnRlbmNlLCBhZGQgIiwg YW5kIiBiZXR3ZWVuDQo+ICJpbXBsZW1lbnRhdGlvbiIgYW5kICJub3QgdG8gdGhlIHVzZSBjYXNl cyIuDQo+IA0KPiBbQkc1XSBTZWN0aW9uIDIuMi4yLCBzZWNvbmQgaXRlbTogcmVwbGFjZSAiZW50 aXRsZSIgYnkgImVudGl0eSIuDQo+IA0KPiBbQkc2XSBTZWN0aW9uIDIuMi4yLCB0aGlyZCBpdGVt OiByZXBsYWNlICJlbmQtZW5kIiBieSAiZW5kIi4NCj4gDQo+IFtCRzddIFNlY3Rpb24gMi4yLjMs ICJyZWFsIHdvcmsgdXNlIGNhc2VzIiAtPiAicmVhbCB3b3JsZCB1c2UgY2FzZXMiLg0KPiANCj4g W0JHOF0gU2VjdGlvbiAyLjMuMzogIlRoaXMgdXNlIGNhc2UgaGlnaGxpZ2h0cyBob3cgZGlmZmVy ZW50IENTUHMgbWF5DQo+IGltcGxlbWVudCBkaWZmZXJlbnQgb3BlcmF0aW9uYWwgc2VtYW50aWNz IGJlaGluZCB0aGUgc2FtZSBTQ0lNIG9wZXJhdGlvbi4NCj4gTm90ZSB0aGF0IENTUC0xIHN1c3Bl bmRzIHRoZSBhY2NvdW50IHJlcHJlc2VudGF0aW9uIGZvciBpdHMgc2VydmljZSB3aGVyZWFzDQo+ IENQUy0yIGltcGxlbWVudHMgYSB0cnVlIGRlbGV0ZSBvcGVyYXRpb24uIg0KPiBJbnRlcmVzdGlu ZyBpZGVhLiBJcyBpdCB0cnVseSBkZXNpcmVkIHRvIGhhdmUgZGlmZmVyZW50IENTUHMgdHJlYXQg dGhlIHNhbWUNCj4gcmVxdWVzdCBkaWZmZXJlbnRseT8gT2J2aW91c2x5IHRoZXJlIHdpbGwgYWx3 YXlzIGJlIHNvbWUgZGlmZmVyZW5jZSBiZXR3ZWVuDQo+IGltcGxlbWVudGF0aW9ucywgYnV0IHRo aXMgZGlmZmVyZW5jZSBzZWVtcyBxdWl0ZSBiaWcuDQo+IE9uIHRoZSBvdGhlciBoYW5kLCBtYXli ZSB0aGlzIGlzIGFsc28gbm90IHRydWx5IHRoZSBzYW1lIFNDSU0gb3BlcmF0aW9uLCBzaW5jZQ0K PiBDU1AtMSByZWNlaXZlcyB0aGUgdHJpZ2dlciBmcm9tIHRoZSBFQ1MsIHdoZXJlYXMgQ1NQLTIg cmVjZWl2ZXMgYSB0ZXJtaW5hdGlvbg0KPiByZXF1ZXN0IGZyb20gQ1NQLTEuDQo+IA0KPiBbQkc5 XSBTZWN0aW9uIDIuMi40LCBsYXN0IHNlbnRlbmNlOg0KPiAiSG93ZXZlciwgcmF0aGVyIHRoYW4g cHJlLXByb3Zpc2lvbmluZyBhY2NvdW50cyBmcm9tIEVDUy0xIHRvIENTUC0xLCBDU1AtMQ0KPiB3 YWl0cyBmb3IgYSBzZXJ2aWNlIGFjY2VzcyByZXF1ZXN0IGZyb20gdGhlIENsb3VkIFNlcnZpY2Ug VXNlciAoQ1NVLTEpIHVuZGVyDQo+IHRoZSBjb250cm9sIGRvbWFpbiBvZiBFQ1MtMSwgYmVmb3Jl IGlzc3VpbmcgYW4gYWNjb3VudCBQdWxsIHJlcXVlc3QgdG8gQ1NQLTEuIg0KPiBTb21ldGhpbmcg c2VlbXMgd3JvbmcgaW4gdGhpcyBzZW50ZW5jZSwgYXMgaXQgc2VlbXMgdG8gc2F5IHRoYXQgQ1NQ LTEgaXNzdWVzIGENCj4gUHVsbCByZXF1ZXN0IHRvIGl0c2VsZi4gTWF5YmUgdGhlIGFjY291bnQg UHVsbCByZXF1ZXN0IGlzIHNlbnQgdG8gIkVDUy0xIiwgbm90IHRvDQo+ICJDU1AtMSI/DQo+IA0K PiBbQkcxMF0gSW4gdmFyaW91cyB1c2UgY2FzZXMsIHRoZXJlIGFyZSByZXF1aXJlbWVudHMgZm9y IGxvZ3MuIEhvd2V2ZXIsIHRoZXJlIGlzDQo+IG5vIHRleHQgaW4gdGhlIHVzZSBjYXNlcyBpdHNl bGYuIE1heWJlIGl0IHdvdWxkIGJlIGJldHRlciB0byBlbGFib3JhdGUgYSBiaXQgb24NCj4gdGhl IGxvZ3MgaW4gdGhlIHVzZSBjYXNlcz8gVGhpcyBzaG91bGQgYWxzbyBpbnZvbHZlIHRoZSBtZW50 aW9uZWQgYXVkaXRpbmcuDQo+IA0KPiBbQkcxMV0gU2VjdGlvbiAzLjQsIHRoZSBzZW50ZW5jZSAi VGhlIGxvY2FsIFlvdXJDb0kgb2ZmaWNlcyBhcmUgcmVzcG9uc2libGUgZm9yDQo+IGVzdGFibGlz aGluZyBwZXJzb25hbCBpbmZvcm1hdGlvbiBhbmQgKGkuZS4sIHNldHRpbmcgdGhlIHVzZXIgaWRl bnRpdGllcyBhbmQNCj4gYXR0cmlidXRlcykuIiBuZWVkcyB3b3Jkc21pdGhpbmcuDQo+IA0KPiBb QkcxMl0gU2VjdGlvbiAzLjQsICJJZGVudGl0eSBtYW5hZ2VtZW50IG9mIHRoZSBwZXJzb25hbCBk YXRhIG11c3QgYmUNCj4gc2VjdXJlIiBpcyBhIGJpdCB2YWd1ZS4gSSBndWVzcyBpdCBtZWFucyBw cm90ZWN0ZWQgYWdhaW5zdCB1bmF1dGhvcmlzZWQgYWNjZXNzDQo+IGFuZCByZW1haW5pbmcgY29u ZmlkZW50aWFsaXR5PyBUaGVuIG1heWJlIHRoZSBmb2xsb3dpbmcgd29yZGluZyB3b3VsZCBiZQ0K PiBiZXR0ZXI6ICJJZGVudGl0eSBtYW5hZ2VtZW50IG9mIHRoZSBwZXJzb25hbCBkYXRhIG11c3Qg YmUgcHJvdGVjdGVkIGFnYWluc3QNCj4gdW5hdXRob3Jpc2VkIGFjY2VzcyBhbmQgcmVtYWluIGNv bmZpZGVudGlhbCB0byBvbmx5IGF1dGhvcmlzZWQgcGFydGllcy4iDQo+IA0KPiBbQkcxM10gU2Vj dGlvbiAzLjU6IHNob3VsZCB0aGVyZSBiZSBhIHJlcXVpcmVtZW50IGZvciBleHBpcmF0aW9uIG9m IHRoZSBjYWNoZWQNCj4gY29weSwgaS5lLiBhIG1heGltdW0gcGVyaW9kIGZvciB3aGljaCB0aGUg cmVseWluZyBwYXJ0eSBtYXkgY2FjaGUgdGhlDQo+IGluZm9ybWF0aW9uPw0KPiANCj4gW0JHMTRd IFRoZSAic2VjdXJpdHkgY29uc2lkZXJhdGlvbnMiIHNlY3Rpb24gaXMgcmF0aGVyIHNob3J0LCBv bmx5IG1lbnRpb25pbmcNCj4gYXV0aG9yaXNhdGlvbiBhbmQgYXV0aGVudGljYXRpb24uIEl0IHdv dWxkIGJlIGdvb2QgdG8gYWRkIHNvbWUgdGV4dCBhYm91dA0KPiBjb25maWRlbnRpYWxpdHkgYW5k IHByaXZhY3kgcHJvdGVjdGlvbi4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHNjaW0gbWFpbGluZyBsaXN0DQo+IHNjaW1AaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQo= From nobody Wed Jun 18 02:00:21 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944CA1A0104; Wed, 18 Jun 2014 01:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDbbz5ZBEX1j; Wed, 18 Jun 2014 01:59:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 451591A008E; Wed, 18 Jun 2014 01:59:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140618085956.12264.23957.idtracker@ietfa.amsl.com> Date: Wed, 18 Jun 2014 01:59:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/K5IxhV70cLbE0Y5l8yrvh7TtHSc Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-use-cases-02.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 08:59:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : SCIM Use Cases Authors : Phil Hunt Bhumip Khasnabish Anthony Nadalin Kepeng LI Zachary Zeltsan Filename : draft-ietf-scim-use-cases-02.txt Pages : 18 Date : 2014-06-18 Abstract: This document lists the user scenarios and use cases of System for Cross-domain Identity Management (SCIM). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-use-cases-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-use-cases-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 18 02:09:09 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFE81A00F0 for ; Wed, 18 Jun 2014 02:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsArbqPupixi for ; Wed, 18 Jun 2014 02:09:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00911A00BF for ; Wed, 18 Jun 2014 02:09:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFO07115; Wed, 18 Jun 2014 09:08:59 +0000 (GMT) Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Jun 2014 10:08:58 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.214]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 17:08:52 +0800 From: Likepeng To: "scim@ietf.org" Thread-Topic: [scim] I-D Action: draft-ietf-scim-use-cases-02.txt Thread-Index: AQHPitO/TBooaB9vskWBkKvbtCXZk5t2khYQ Date: Wed, 18 Jun 2014 09:08:51 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F25815CE70@SZXEMA501-MBS.china.huawei.com> References: <20140618085956.12264.23957.idtracker@ietfa.amsl.com> In-Reply-To: <20140618085956.12264.23957.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/scim/12apxjqOqXxS1I8B-N0hKqOgy8w Subject: Re: [scim] I-D Action: draft-ietf-scim-use-cases-02.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 09:09:05 -0000 SGVsbG8gYWxsLA0KDQpJIHVwZGF0ZWQgdGhlIHVzZSBjYXNlIGRyYWZ0IGFjY29yZGluZyB0byB0 aGUgY29tbWVudHMgcmVjZWl2ZWQgZHVyaW5nIHRoZSBXR0xDLg0KDQpXZWxjb21lIG1vcmUgcmV2 aWV3cyBhbmQgY29tbWVudHMuDQoNClRoYW5rcywNCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCg0K PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBzY2ltIFttYWlsdG86c2NpbS1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiC3osvNyrG85DogMjAx NMTqNtTCMTjI1SAxNzowMA0KPiDK1bz+yMs6IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiCzrcvN OiBzY2ltQGlldGYub3JnDQo+INb3zOI6IFtzY2ltXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNj aW0tdXNlLWNhc2VzLTAyLnR4dA0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiAgVGhp cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU3lzdGVtIGZvciBDcm9zcy1kb21haW4gSWRl bnRpdHkNCj4gTWFuYWdlbWVudCBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPiANCj4gICAg ICAgICBUaXRsZSAgICAgICAgICAgOiBTQ0lNIFVzZSBDYXNlcw0KPiAgICAgICAgIEF1dGhvcnMg ICAgICAgICA6IFBoaWwgSHVudA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEJodW1pcCBL aGFzbmFiaXNoDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQW50aG9ueSBOYWRhbGluDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgS2VwZW5nIExJDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgWmFjaGFyeSBaZWx0c2FuDQo+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm LXNjaW0tdXNlLWNhc2VzLTAyLnR4dA0KPiAJUGFnZXMgICAgICAgICAgIDogMTgNCj4gCURhdGUg ICAgICAgICAgICA6IDIwMTQtMDYtMTgNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3Vt ZW50IGxpc3RzIHRoZSB1c2VyIHNjZW5hcmlvcyBhbmQgdXNlIGNhc2VzIG9mIFN5c3RlbSBmb3IN Cj4gICAgQ3Jvc3MtZG9tYWluIElkZW50aXR5IE1hbmFnZW1lbnQgKFNDSU0pLg0KPiANCj4gVGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2NpbS11c2UtY2FzZXMvDQo+ IA0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zY2ltLXVzZS1jYXNlcy0wMg0KPiAN Cj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBo dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNjaW0tdXNlLWNhc2Vz LTAyDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4g SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0K PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2NpbSBtYWlsaW5nIGxpc3QN Cj4gc2NpbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NjaW0NCg== From nobody Wed Jun 18 05:52:10 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94D61A01E2 for ; Wed, 18 Jun 2014 05:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eIkLjjbb5_B for ; Wed, 18 Jun 2014 05:52:03 -0700 (PDT) Received: from mail-ie0-f199.google.com (mail-ie0-f199.google.com [209.85.223.199]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C4C1A01D3 for ; Wed, 18 Jun 2014 05:52:02 -0700 (PDT) Received: by mail-ie0-f199.google.com with SMTP id rd18so5714408iec.10 for ; Wed, 18 Jun 2014 05:52: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bFCSSRuXI+dMsNJvnHNBTC+cNKObN/TRaqebgr3y4EA=; b=Vb4K37mqpHVI7g9BV/cYG0YyRtqsw11bcYnRlm4fNwdB+TENCKOGSbr3nE4qn2bL9R vfBD1Ago+SSiNAMJah3QMs6QEw4eHmFCHCeMLwmlZGYjVtzaXHsynJ5/2czNXWrauhpM PZY2WrYacmECJtfTtpKZr5UyvLWaJOz1KJ+hQ8nInFhPOGlumQsNu/msi5W20FCUnxXy oaT3IoRvmBvPDwV/tm1kVP360vjWS2PLV5Cc3kZG9vF5gc/vZe+Lb+QxvjVmXrvXxYll RhtbP5EH0u9wYPv9V45E2/2TVMWs+shiC6BZVjayPAHqi4Phgf/ofNFGqIOH6FWcq1ls iBZw== X-Gm-Message-State: ALoCoQmn0PeSxHYsguKzXOiid+XmATzYnSWeqryECL8NKQpdUyPUkB8q3nrWFEP8k00plb3qUkoe X-Received: by 10.42.210.74 with SMTP id gj10mr2157903icb.46.1403095922181; Wed, 18 Jun 2014 05:52:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.18 with HTTP; Wed, 18 Jun 2014 05:51:42 -0700 (PDT) In-Reply-To: <5398A21B.4000502@mnt.se> References: <5398A21B.4000502@mnt.se> From: Thomas Krille Date: Wed, 18 Jun 2014 14:51:42 +0200 Message-ID: To: Leif Johansson Content-Type: multipart/alternative; boundary=20cf303dd77407206304fc1bba52 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/MKKU-lCKPE9mcbsHFkf88H7r2Jo Cc: "scim@ietf.org" Subject: Re: [scim] Proposed new text for PUT (ticket 76) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 12:52:06 -0000 --20cf303dd77407206304fc1bba52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, looks good to me. +1 for not creating new resources via PUT. i will have to try to implement the revised behavior in order to issue a final, more qualified statement. Best Regards Thomas Krille Softwareentwicklung tarent solutions GmbH Telefon +49 (0) 30 138803-128 Telefax +49 (0) 228 54881-235 t.krille@tarent.de Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/ Tel: +49 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235 HRB AG Bonn 5168 =E2=80=A2 USt-ID (VAT): DE122264941 Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale= xander Steeg 2014-06-11 20:38 GMT+02:00 Leif Johansson : > On 2014-06-02 22:03, Phil Hunt wrote: > > Here is some proposed new text. I=E2=80=99ve tried to tweak the text a= bit to > > help solve Ticket 76 regarding what to do about missing or omitted > > attributes. > > > > I want to encourage/urge everyone to think about and review this > proposal. It is very likely the last big issue left to us! > > > After some analysis, I think this is closest in logic to how people are > > using PUT now. Because PUT is mandatory, I believe we need to be very > > precise. > > > > I have also added text stating that PUT should not be used to create ne= w > > resources. Is the word =E2=80=9CSHOULD=E2=80=9D appropriate? The real = problem with > > using PUT for resource creation is the client gets to create their own > > identifier. > > > >> 3.3.1. Modifying with PUT > >> > >> HTTP PUT is used to perform a full update of a resource's attribute= s. > >> Clients having previously retrieved the entire resource in advance, > >> update the desired attributes and use HTTP PUT to replace previousl= y > >> stored attributes. HTTP PUT SHOULD NOT be used to create a new > >> resource. > >> > >> As the operation intent is to replace attributes, SCIM clients MAY > >> send all attributes regardless of each attribute's mutability. The > >> server will apply attribute by attribute replace according to the > >> following attribute mutability rules: > >> > >> readWrite, writeOnly Any values provided SHALL replace the existin= g > >> attribute values. > >> > >> immutable If values are already set in the attribute they MUST mat= ch > >> existing data or an error is returned. If the service provider > >> has no existing values, the new value(s) SHALL be applied. > >> > >> readOnly Any values provided (e.g. meta.resourceType) SHALL be > >> ignored. > >> > >> If an attribute is "required", clients MUST specify the attribute i= n > >> the PUT request. > >> > >> Clients MAY specify "null" or empty set "[]" to clear an existing > >> value or clear a multi-valued array. > >> > >> Since a client may not have access to, or may not be aware of, the > >> full schema for a resource, omitted or unspecified values SHOULD be > >> ignored. > >> > >> If a value provided for an immutable attribute with an existing val= ue > >> is NOT matched, the server SHALL respond with an HTTP response code > >> of 400 and an appropriate human readable message indicating an > >> attempt to change an immutable attribute. [[Editor: An appropriate > >> error code should be indicated e.g. 'mutability']] > >> > >> Unless otherwise specified a successful PUT operation returns a 200 > >> OK response code and the entire resource within the response body, > >> enabling the client to correlate the client's and Provider's views = of > >> the updated resource. Example: > >> > > > > > > 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 > --20cf303dd77407206304fc1bba52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

looks good to me. +1 for not cre= ating new resources via PUT.

i will have to try to= implement the revised behavior in order to issue a final, more qualified s= tatement.

Best Regard= s

T= homas Krille
Softwareentwicklung
tarent solutions GmbH

Telefon= +49 (0) 30 138803-128
Telefax +49 (0) 228 54881-235
t.krille@tarent.de

Rochusstra=C3=9Fe 2-4, D-53123= Bonn =E2=80=A2=C2=A0http://www.tarent.de/
Tel: +49 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235
HRB AG Bonn 5168 = =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefa= n Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


2014-06-11 20:38 GMT+02:00 Leif Johansso= n <l= eifj@mnt.se>:
On 2014-06-02 22:03, Phil Hunt wrote:
> Here is some proposed new text. =C2=A0I=E2=80=99ve tried to tweak the = text a bit to
> help solve Ticket 76 regarding what to do about missing or omitted
> attributes.
>

I want to encourage/urge everyone to think about and review this
proposal. It is very likely the last big issue left to us!

> After some analysis, I think this is closest in logic to how people ar= e
> using PUT now. =C2=A0Because PUT is mandatory, I believe we need to be= very
> precise.
>
> I have also added text stating that PUT should not be used to create n= ew
> resources. Is the word =E2=80=9CSHOULD=E2=80=9D appropriate? =C2=A0The= real problem with
> using PUT for resource creation is the client gets to create their own=
> identifier.
>
>> 3.3.1. =C2=A0Modifying with PUT
>>
>> =C2=A0 =C2=A0HTTP PUT is used to perform a full update of a resour= ce's attributes.
>> =C2=A0 =C2=A0Clients having previously retrieved the entire resour= ce in advance,
>> =C2=A0 =C2=A0update the desired attributes and use HTTP PUT to rep= lace previously
>> =C2=A0 =C2=A0stored attributes. =C2=A0HTTP PUT SHOULD NOT be used = to create a new
>> =C2=A0 =C2=A0resource.
>>
>> =C2=A0 =C2=A0As the operation intent is to replace attributes, SCI= M clients MAY
>> =C2=A0 =C2=A0send all attributes regardless of each attribute'= s mutability. =C2=A0The
>> =C2=A0 =C2=A0server will apply attribute by attribute replace acco= rding to the
>> =C2=A0 =C2=A0following attribute mutability rules:
>>
>> =C2=A0 =C2=A0readWrite, writeOnly =C2=A0Any values provided SHALL = replace the existing
>> =C2=A0 =C2=A0 =C2=A0 attribute values.
>>
>> =C2=A0 =C2=A0immutable =C2=A0If values are already set in the attr= ibute they MUST match
>> =C2=A0 =C2=A0 =C2=A0 existing data or an error is returned. =C2=A0= If the service provider
>> =C2=A0 =C2=A0 =C2=A0 has no existing values, the new value(s) SHAL= L be applied.
>>
>> =C2=A0 =C2=A0readOnly =C2=A0Any values provided (e.g. =C2=A0meta.r= esourceType) SHALL be
>> =C2=A0 =C2=A0 =C2=A0 ignored.
>>
>> =C2=A0 =C2=A0If an attribute is "required", clients MUST= specify the attribute in
>> =C2=A0 =C2=A0the PUT request.
>>
>> =C2=A0 =C2=A0Clients MAY specify "null" or empty set &qu= ot;[]" to clear an existing
>> =C2=A0 =C2=A0value or clear a multi-valued array.
>>
>> =C2=A0 =C2=A0Since a client may not have access to, or may not be = aware of, the
>> =C2=A0 =C2=A0full schema for a resource, omitted or unspecified va= lues SHOULD be
>> =C2=A0 =C2=A0ignored.
>>
>> =C2=A0 =C2=A0If a value provided for an immutable attribute with a= n existing value
>> =C2=A0 =C2=A0is NOT matched, the server SHALL respond with an HTTP= response code
>> =C2=A0 =C2=A0of 400 and an appropriate human readable message indi= cating an
>> =C2=A0 =C2=A0attempt to change an immutable attribute. =C2=A0[[Edi= tor: An appropriate
>> =C2=A0 =C2=A0error code should be indicated e.g. 'mutability&#= 39;]]
>>
>> =C2=A0 =C2=A0Unless otherwise specified a successful PUT operation= returns a 200
>> =C2=A0 =C2=A0OK response code and the entire resource within the r= esponse body,
>> =C2=A0 =C2=A0enabling the client to correlate the client's and= Provider's views of
>> =C2=A0 =C2=A0the updated resource. =C2=A0Example:
>>
>
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> phil.hunt@oracle.com <m= ailto:phil.hunt@oracle.com><= br> >
>
>
>
>
> _______________________________________________
> 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

--20cf303dd77407206304fc1bba52-- From nobody Wed Jun 18 11:44:15 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70DC1A019A for ; Wed, 18 Jun 2014 11:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deXUAgqUCczF for ; Wed, 18 Jun 2014 11:44:09 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CCF1A00FF for ; Wed, 18 Jun 2014 11:44:08 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5IIi7BH008821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jun 2014 18:44:07 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5IIi3rt018211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2014 18:44:05 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5IIi344008916; Wed, 18 Jun 2014 18:44:03 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Jun 2014 11:44:03 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_90293C68-8E8B-4E1D-B542-6721B3BA432F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: Date: Wed, 18 Jun 2014 11:44:01 -0700 Message-Id: <7CDF2C44-56C1-4B34-A0EA-437D631E411B@oracle.com> References: <5398A21B.4000502@mnt.se> To: Thomas Krille X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/EdzEoZo6w8he2Wpq6iDqSzxXFG0 Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Proposed new text for PUT (ticket 76) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 18:44:12 -0000 --Apple-Mail=_90293C68-8E8B-4E1D-B542-6721B3BA432F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Another complication is =93default=94 values. A client omitting an attribute: * may not know about the attribute as being part of the representation = (e.g. because of access control) * may intend to replace the values of the attribute with nothing (null). * may be simply saying assign the default value. Having a client being able to say =93attribute=94:null would be a nice = way to allow clients to differentiate between, don=92t know/want = default and explicitly intend to replace with a null value. e.g. set = roles to null. Do we want to put this in the next draft and give it a try? We can = always pull it out in the following draft if implementers find it = doesn=92t make the logic simpler. I do caution that we are hoping to go = to last call in Toronto. =20 Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 18, 2014, at 5:51 AM, Thomas Krille wrote: > Hello, >=20 > looks good to me. +1 for not creating new resources via PUT. >=20 > i will have to try to implement the revised behavior in order to issue = a final, more qualified statement. >=20 > Best Regards >=20 > Thomas Krille > Softwareentwicklung > tarent solutions GmbH >=20 > Telefon +49 (0) 30 138803-128 > Telefax +49 (0) 228 54881-235 > t.krille@tarent.de >=20 > Rochusstra=DFe 2-4, D-53123 Bonn =95 http://www.tarent.de/ > Tel: +49 228 54881-0 =95 Fax: +49 228 54881-235 > HRB AG Bonn 5168 =95 USt-ID (VAT): DE122264941 > Gesch=E4ftsf=FChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, = Alexander Steeg >=20 >=20 > 2014-06-11 20:38 GMT+02:00 Leif Johansson : > On 2014-06-02 22:03, Phil Hunt wrote: > > Here is some proposed new text. I=92ve tried to tweak the text a = bit to > > help solve Ticket 76 regarding what to do about missing or omitted > > attributes. > > >=20 > I want to encourage/urge everyone to think about and review this > proposal. It is very likely the last big issue left to us! >=20 > > After some analysis, I think this is closest in logic to how people = are > > using PUT now. Because PUT is mandatory, I believe we need to be = very > > precise. > > > > I have also added text stating that PUT should not be used to create = new > > resources. Is the word =93SHOULD=94 appropriate? The real problem = with > > using PUT for resource creation is the client gets to create their = own > > identifier. > > > >> 3.3.1. Modifying with PUT > >> > >> HTTP PUT is used to perform a full update of a resource's = attributes. > >> Clients having previously retrieved the entire resource in = advance, > >> update the desired attributes and use HTTP PUT to replace = previously > >> stored attributes. HTTP PUT SHOULD NOT be used to create a new > >> resource. > >> > >> As the operation intent is to replace attributes, SCIM clients = MAY > >> send all attributes regardless of each attribute's mutability. = The > >> server will apply attribute by attribute replace according to = the > >> following attribute mutability rules: > >> > >> readWrite, writeOnly Any values provided SHALL replace the = existing > >> attribute values. > >> > >> immutable If values are already set in the attribute they MUST = match > >> existing data or an error is returned. If the service = provider > >> has no existing values, the new value(s) SHALL be applied. > >> > >> readOnly Any values provided (e.g. meta.resourceType) SHALL be > >> ignored. > >> > >> If an attribute is "required", clients MUST specify the = attribute in > >> the PUT request. > >> > >> Clients MAY specify "null" or empty set "[]" to clear an = existing > >> value or clear a multi-valued array. > >> > >> Since a client may not have access to, or may not be aware of, = the > >> full schema for a resource, omitted or unspecified values SHOULD = be > >> ignored. > >> > >> If a value provided for an immutable attribute with an existing = value > >> is NOT matched, the server SHALL respond with an HTTP response = code > >> of 400 and an appropriate human readable message indicating an > >> attempt to change an immutable attribute. [[Editor: An = appropriate > >> error code should be indicated e.g. 'mutability']] > >> > >> Unless otherwise specified a successful PUT operation returns a = 200 > >> OK response code and the entire resource within the response = body, > >> enabling the client to correlate the client's and Provider's = views of > >> the updated resource. Example: > >> > > > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > > > _______________________________________________ > > scim mailing list > > scim@ietf.org > > https://www.ietf.org/mailman/listinfo/scim > > >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_90293C68-8E8B-4E1D-B542-6721B3BA432F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Another complication is =93default=94 = values.

A client omitting an attribute:
* = may not know about the attribute as being part of the representation = (e.g. because of access control)
* may intend to replace the = values of the attribute with nothing (null).
* may be simply = saying assign the default value.

Having a = client being able to say =93attribute=94:null would be a nice way to = allow clients to differentiate between,  don=92t know/want default = and explicitly intend to replace with a null value.  e.g. set roles = to null.

Do we want to put this in the next = draft and give it a try? We can always pull it out in the following = draft if implementers find it doesn=92t make the logic simpler.  I = do caution that we are hoping to go to last call in Toronto. =  


On Jun 18, 2014, at 5:51 AM, Thomas Krille <t.krille@tarent.de> = wrote:

Hello,

looks good to = me. +1 for not creating new resources via = PUT.

i will have to try to implement the = revised behavior in order to issue a final, more qualified = statement.

Best = Regards

Thomas Krille
Softwareentwicklung
tarent solutions = GmbH

Telefon +49 (0) 30 138803-128
Telefax +49 (0) 228 54881-235
t.krille@tarent.de

Rochusstra=DFe 2-4, = D-53123 Bonn =95 http://www.tarent.de/
Tel: +49 228 54881-0 =95 Fax: +49 228 54881-235
HRB AG Bonn 5168 =95 = USt-ID (VAT): DE122264941
Gesch=E4ftsf=FChrer: Dr. Stefan Barth, Kai = Ebenrett, Boris Esser, Alexander Steeg


2014-06-11 20:38 GMT+02:00 Leif = Johansson <leifj@mnt.se>:
On 2014-06-02 22:03, Phil Hunt wrote:
> Here is some proposed new text.  I=92ve tried to tweak the = text a bit to
> help solve Ticket 76 regarding what to do about missing or = omitted
> attributes.
>

I want to encourage/urge everyone to think about and review = this
proposal. It is very likely the last big issue left to us!

> After some analysis, I think this is closest in logic to how people = are
> using PUT now.  Because PUT is mandatory, I believe we need to = be very
> precise.
>
> I have also added text stating that PUT should not be used to = create new
> resources. Is the word =93SHOULD=94 appropriate?  The real = problem with
> using PUT for resource creation is the client gets to create their = own
> identifier.
>
>> 3.3.1.  Modifying with PUT
>>
>>    HTTP PUT is used to perform a full update of a = resource's attributes.
>>    Clients having previously retrieved the entire = resource in advance,
>>    update the desired attributes and use HTTP PUT to = replace previously
>>    stored attributes.  HTTP PUT SHOULD NOT be = used to create a new
>>    resource.
>>
>>    As the operation intent is to replace attributes, = SCIM clients MAY
>>    send all attributes regardless of each attribute's = mutability.  The
>>    server will apply attribute by attribute replace = according to the
>>    following attribute mutability rules:
>>
>>    readWrite, writeOnly  Any values provided = SHALL replace the existing
>>       attribute values.
>>
>>    immutable  If values are already set in the = attribute they MUST match
>>       existing data or an error is returned. =  If the service provider
>>       has no existing values, the new value(s) = SHALL be applied.
>>
>>    readOnly  Any values provided (e.g. =  meta.resourceType) SHALL be
>>       ignored.
>>
>>    If an attribute is "required", clients MUST = specify the attribute in
>>    the PUT request.
>>
>>    Clients MAY specify "null" or empty set "[]" to = clear an existing
>>    value or clear a multi-valued array.
>>
>>    Since a client may not have access to, or may not = be aware of, the
>>    full schema for a resource, omitted or unspecified = values SHOULD be
>>    ignored.
>>
>>    If a value provided for an immutable attribute = with an existing value
>>    is NOT matched, the server SHALL respond with an = HTTP response code
>>    of 400 and an appropriate human readable message = indicating an
>>    attempt to change an immutable attribute. =  [[Editor: An appropriate
>>    error code should be indicated e.g. = 'mutability']]
>>
>>    Unless otherwise specified a successful PUT = operation returns a 200
>>    OK response code and the entire resource within = the response body,
>>    enabling the client to correlate the client's and = Provider's views of
>>    the updated resource.  Example:
>>
>
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> phil.hunt@oracle.com = <mailto: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/ma= ilman/listinfo/scim

= --Apple-Mail=_90293C68-8E8B-4E1D-B542-6721B3BA432F-- From nobody Thu Jun 19 11:04:19 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2011A02CF for ; Thu, 19 Jun 2014 11:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x61M6tCiBH5H for ; Thu, 19 Jun 2014 11:04:11 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2C21A02BA for ; Thu, 19 Jun 2014 11:04:11 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5JI49RZ018299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Jun 2014 18:04:10 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 s5JI44wO001194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2014 18:04:05 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5JI426B009715; Thu, 19 Jun 2014 18:04:03 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Jun 2014 11:04:02 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_3B77CE41-67AC-45FF-A401-1849D8CC3D67" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: <7CDF2C44-56C1-4B34-A0EA-437D631E411B@oracle.com> Date: Thu, 19 Jun 2014 11:04:00 -0700 Message-Id: <36DDD84B-9E95-4799-A852-2CC1C5741BE1@oracle.com> References: <5398A21B.4000502@mnt.se> <7CDF2C44-56C1-4B34-A0EA-437D631E411B@oracle.com> To: Thomas Krille X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/9wJQlslvZNJ5Q9ZPacqJqlM2osE Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Proposed new text for PUT (ticket 76) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 18:04:15 -0000 --Apple-Mail=_3B77CE41-67AC-45FF-A401-1849D8CC3D67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Group, Please find below, some new text for PUT. This should keep most of our = current logic intact but I hope addresses the issues giving clients and = servers the right balance of =93intent=94 and =93interpretation=94. As I mentioned in my previous issue, there is the issue of unspecified = values being defaulted by the server.In the example below, I show the = client setting =93roles=94 to [] in order to say the User is to have no = roles (as opposed to a default set). If you like this, I will apply = similar language to the POST operation. See bold sections below... 3.3.1. Replacing with PUT HTTP PUT is used to perform a full update of a resource's attributes. Clients that MAY have previously retrieved the entire resource in advance and revised it, MAY replace the resource using an HTTP PUT. Because SCIM resource identifiers are typically assigned by the service provider, HTTP PUT SHOULD NOT be used to create new resources. As the operation intent is to replace all attributes, SCIM clients MAY send all attributes regardless of each attribute's mutability. The server will apply attribute by attribute replace according to the following attribute mutability rules: readWrite, writeOnly Any values provided SHALL replace the existing attribute values. immutable If value(s) are already set for the attribute, the input value(s) MUST match or HTTP status 400 SHOULD be returned with error code "mutability". If the service provider has no existing values, the new value(s) SHALL be applied. readOnly Any values provided (e.g. meta.resourceType) SHALL be ignored. If an attribute is "required", clients MUST specify the attribute in the PUT request. Attributes whose mutability is "readWrite", that are omitted from the request body, MAY be assumed to be not asserted by the client. The service provider MAY assume any existing values are to be cleared or the service provider MAY assign a default value to the final resource representation. Service providers MAY take into account whether a client has access to, or understands, all of the resource's attributes when deciding whether non-asserted attributes SHALL be removed or defaulted. Clients that would like to override a server defaults, MAY specify "null" for a single-valued attribute or an empty array "[]" for a multi-valued attribute to clear all values. Unless otherwise specified a successful PUT operation returns a 200 OK response code and the entire resource within the response body, enabling the client to correlate the client's and Provider's views of the updated resource. Example: PUT /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/scim+json Content-Type: application/scim+json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas":["urn:scim:schemas:core:2.0:User"], "id":"2819c223-7f76-453a-919d-413861904646", "userName":"bjensen", "externalId":"bjensen", "name":{ "formatted":"Ms. Barbara J Jensen III", "familyName":"Jensen", "givenName":"Barbara", "middleName":"Jane" }, "roles":[], "emails":[ { "value":"bjensen@example.com" }, { "value":"babs@jensen.org" } ] } Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 18, 2014, at 11:44 AM, Phil Hunt wrote: > Another complication is =93default=94 values. >=20 > A client omitting an attribute: > * may not know about the attribute as being part of the representation = (e.g. because of access control) > * may intend to replace the values of the attribute with nothing = (null). > * may be simply saying assign the default value. >=20 > Having a client being able to say =93attribute=94:null would be a nice = way to allow clients to differentiate between, don=92t know/want = default and explicitly intend to replace with a null value. e.g. set = roles to null. >=20 > Do we want to put this in the next draft and give it a try? We can = always pull it out in the following draft if implementers find it = doesn=92t make the logic simpler. I do caution that we are hoping to go = to last call in Toronto. =20 >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Jun 18, 2014, at 5:51 AM, Thomas Krille wrote: >=20 >> Hello, >>=20 >> looks good to me. +1 for not creating new resources via PUT. >>=20 >> i will have to try to implement the revised behavior in order to = issue a final, more qualified statement. >>=20 >> Best Regards >>=20 >> Thomas Krille >> Softwareentwicklung >> tarent solutions GmbH >>=20 >> Telefon +49 (0) 30 138803-128 >> Telefax +49 (0) 228 54881-235 >> t.krille@tarent.de >>=20 >> Rochusstra=DFe 2-4, D-53123 Bonn =95 http://www.tarent.de/ >> Tel: +49 228 54881-0 =95 Fax: +49 228 54881-235 >> HRB AG Bonn 5168 =95 USt-ID (VAT): DE122264941 >> Gesch=E4ftsf=FChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, = Alexander Steeg >>=20 >>=20 >> 2014-06-11 20:38 GMT+02:00 Leif Johansson : >> On 2014-06-02 22:03, Phil Hunt wrote: >> > Here is some proposed new text. I=92ve tried to tweak the text a = bit to >> > help solve Ticket 76 regarding what to do about missing or omitted >> > attributes. >> > >>=20 >> I want to encourage/urge everyone to think about and review this >> proposal. It is very likely the last big issue left to us! >>=20 >> > After some analysis, I think this is closest in logic to how people = are >> > using PUT now. Because PUT is mandatory, I believe we need to be = very >> > precise. >> > >> > I have also added text stating that PUT should not be used to = create new >> > resources. Is the word =93SHOULD=94 appropriate? The real problem = with >> > using PUT for resource creation is the client gets to create their = own >> > identifier. >> > >> >> 3.3.1. Modifying with PUT >> >> >> >> HTTP PUT is used to perform a full update of a resource's = attributes. >> >> Clients having previously retrieved the entire resource in = advance, >> >> update the desired attributes and use HTTP PUT to replace = previously >> >> stored attributes. HTTP PUT SHOULD NOT be used to create a new >> >> resource. >> >> >> >> As the operation intent is to replace attributes, SCIM clients = MAY >> >> send all attributes regardless of each attribute's mutability. = The >> >> server will apply attribute by attribute replace according to = the >> >> following attribute mutability rules: >> >> >> >> readWrite, writeOnly Any values provided SHALL replace the = existing >> >> attribute values. >> >> >> >> immutable If values are already set in the attribute they MUST = match >> >> existing data or an error is returned. If the service = provider >> >> has no existing values, the new value(s) SHALL be applied. >> >> >> >> readOnly Any values provided (e.g. meta.resourceType) SHALL = be >> >> ignored. >> >> >> >> If an attribute is "required", clients MUST specify the = attribute in >> >> the PUT request. >> >> >> >> Clients MAY specify "null" or empty set "[]" to clear an = existing >> >> value or clear a multi-valued array. >> >> >> >> Since a client may not have access to, or may not be aware of, = the >> >> full schema for a resource, omitted or unspecified values = SHOULD be >> >> ignored. >> >> >> >> If a value provided for an immutable attribute with an existing = value >> >> is NOT matched, the server SHALL respond with an HTTP response = code >> >> of 400 and an appropriate human readable message indicating an >> >> attempt to change an immutable attribute. [[Editor: An = appropriate >> >> error code should be indicated e.g. 'mutability']] >> >> >> >> Unless otherwise specified a successful PUT operation returns a = 200 >> >> OK response code and the entire resource within the response = body, >> >> enabling the client to correlate the client's and Provider's = views of >> >> the updated resource. Example: >> >> >> > >> > >> > Phil >> > >> > @independentid >> > www.independentid.com >> > phil.hunt@oracle.com >> > >> > >> > >> > >> > >> > _______________________________________________ >> > scim mailing list >> > scim@ietf.org >> > https://www.ietf.org/mailman/listinfo/scim >> > >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >>=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=_3B77CE41-67AC-45FF-A401-1849D8CC3D67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Group,

Please find below, some = new text for PUT. This should keep most of our current logic intact but = I hope addresses the issues giving clients and servers the right balance = of =93intent=94 and =93interpretation=94.

As I = mentioned in my previous issue, there is the issue of unspecified values = being defaulted by the server.In the example below, I show the client = setting =93roles=94 to [] in order to say the User is to have no roles = (as opposed to a default set).  If you like this, I will apply = similar language to the POST operation.

See = bold sections = below...
3.3.1.  Replacing with PUT

   HTTP PUT is used to perform a full update =
of a resource's attributes.
   Clients that MAY have previously retrieved the entire resource in
   advance and revised it, MAY replace the resource using an HTTP PUT.
   Because SCIM resource identifiers are typically assigned by the
   service provider, HTTP PUT SHOULD NOT be used to create new
   resources.

   As the operation intent is to replace all attributes, SCIM clients
   MAY send all attributes regardless of each attribute's mutability.
   The server will apply attribute by attribute replace according to the
   following attribute mutability rules:

   readWrite, writeOnly  Any values provided SHALL replace the existing
      attribute values.

   immutable  If value(s) are already set for the attribute, the input
      value(s) MUST match or HTTP status 400 SHOULD be returned with
      error code "mutability".  If the service provider has no existing
      values, the new value(s) SHALL be applied.

   readOnly  Any values provided (e.g.  meta.resourceType) SHALL be
      ignored.

   If an attribute is "required", clients MUST specify the attribute in
   the PUT request.

   Attributes whose mutability is =
"readWrite", that are omitted from the
   request body, MAY be assumed to be not asserted by the client.  The
   service provider MAY assume any existing values are to be cleared or
   the service provider MAY assign a default value to the final resource
   representation.  Service providers MAY take into account whether a
   client has access to, or understands, all of the resource's
   attributes when deciding whether non-asserted attributes SHALL be
   removed or defaulted.  Clients that would like to override a server
   defaults, MAY specify "null" for a single-valued attribute or an
   empty array "[]" for a multi-valued attribute to clear all =
values.

   Unless otherwise specified a successful PUT operation returns a 200
   OK response code and the entire resource within the response body,
   enabling the client to correlate the client's and Provider's views of
   the updated resource.  Example:

   PUT /Users/2819c223-7f76-453a-919d-413861904646
   Host: example.com
   Accept: application/scim+json
   Content-Type: application/scim+json
   Authorization: Bearer h480djs93hd8
   If-Match: W/"a330bc54f0671c9"

   {
     "schemas":["urn:scim:schemas:core:2.0:User"],
     "id":"2819c223-7f76-453a-919d-413861904646",
     "userName":"bjensen",
     "externalId":"bjensen",
     "name":{
       "formatted":"Ms. Barbara J Jensen III",
       "familyName":"Jensen",
       "givenName":"Barbara",
       "middleName":"Jane"
     },
     "roles":[],
     "emails":[
       {
           "value":"bjensen@example.com"
       },
       {
           "value":"babs@jensen.org"
       }
     ]
   }


On Jun 18, 2014, at 11:44 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:

Another complication is =93default=94 = values.

A client omitting an attribute:
* = may not know about the attribute as being part of the representation = (e.g. because of access control)
* may intend to replace the = values of the attribute with nothing (null).
* may be simply = saying assign the default value.

Having a = client being able to say =93attribute=94:null would be a nice way to = allow clients to differentiate between,  don=92t know/want default = and explicitly intend to replace with a null value.  e.g. set roles = to null.

Do we want to put this in the next = draft and give it a try? We can always pull it out in the following = draft if implementers find it doesn=92t make the logic simpler.  I = do caution that we are hoping to go to last call in Toronto. =  


On Jun 18, 2014, at 5:51 AM, Thomas Krille <t.krille@tarent.de> = wrote:

Hello,

looks good to = me. +1 for not creating new resources via = PUT.

i will have to try to implement the = revised behavior in order to issue a final, more qualified = statement.

Best = Regards

Thomas Krille
Softwareentwicklung
tarent solutions = GmbH

Telefon +49 (0) 30 138803-128
Telefax +49 (0) 228 54881-235
t.krille@tarent.de

Rochusstra=DFe 2-4, = D-53123 Bonn =95 http://www.tarent.de/
Tel: +49 228 54881-0 =95 Fax: +49 228 54881-235
HRB AG Bonn 5168 =95 = USt-ID (VAT): DE122264941
Gesch=E4ftsf=FChrer: Dr. Stefan Barth, Kai = Ebenrett, Boris Esser, Alexander Steeg


2014-06-11 20:38 GMT+02:00 Leif = Johansson <leifj@mnt.se>:
On 2014-06-02 22:03, Phil Hunt wrote:
> Here is some proposed new text.  I=92ve tried to tweak the = text a bit to
> help solve Ticket 76 regarding what to do about missing or = omitted
> attributes.
>

I want to encourage/urge everyone to think about and review = this
proposal. It is very likely the last big issue left to us!

> After some analysis, I think this is closest in logic to how people = are
> using PUT now.  Because PUT is mandatory, I believe we need to = be very
> precise.
>
> I have also added text stating that PUT should not be used to = create new
> resources. Is the word =93SHOULD=94 appropriate?  The real = problem with
> using PUT for resource creation is the client gets to create their = own
> identifier.
>
>> 3.3.1.  Modifying with PUT
>>
>>    HTTP PUT is used to perform a full update of a = resource's attributes.
>>    Clients having previously retrieved the entire = resource in advance,
>>    update the desired attributes and use HTTP PUT to = replace previously
>>    stored attributes.  HTTP PUT SHOULD NOT be = used to create a new
>>    resource.
>>
>>    As the operation intent is to replace attributes, = SCIM clients MAY
>>    send all attributes regardless of each attribute's = mutability.  The
>>    server will apply attribute by attribute replace = according to the
>>    following attribute mutability rules:
>>
>>    readWrite, writeOnly  Any values provided = SHALL replace the existing
>>       attribute values.
>>
>>    immutable  If values are already set in the = attribute they MUST match
>>       existing data or an error is returned. =  If the service provider
>>       has no existing values, the new value(s) = SHALL be applied.
>>
>>    readOnly  Any values provided (e.g. =  meta.resourceType) SHALL be
>>       ignored.
>>
>>    If an attribute is "required", clients MUST = specify the attribute in
>>    the PUT request.
>>
>>    Clients MAY specify "null" or empty set "[]" to = clear an existing
>>    value or clear a multi-valued array.
>>
>>    Since a client may not have access to, or may not = be aware of, the
>>    full schema for a resource, omitted or unspecified = values SHOULD be
>>    ignored.
>>
>>    If a value provided for an immutable attribute = with an existing value
>>    is NOT matched, the server SHALL respond with an = HTTP response code
>>    of 400 and an appropriate human readable message = indicating an
>>    attempt to change an immutable attribute. =  [[Editor: An appropriate
>>    error code should be indicated e.g. = 'mutability']]
>>
>>    Unless otherwise specified a successful PUT = operation returns a 200
>>    OK response code and the entire resource within = the response body,
>>    enabling the client to correlate the client's and = Provider's views of
>>    the updated resource.  Example:
>>
>
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> phil.hunt@oracle.com = <mailto: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/m= ailman/listinfo/scim

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

= --Apple-Mail=_3B77CE41-67AC-45FF-A401-1849D8CC3D67-- From nobody Fri Jun 20 12:21:59 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182D51B28DA for ; Fri, 20 Jun 2014 12:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jpi34KFgqICT for ; Fri, 20 Jun 2014 12:21:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BBCB1B28DC for ; Fri, 20 Jun 2014 12:21:51 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB439.namprd04.prod.outlook.com (10.141.58.18) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 20 Jun 2014 19:21:50 +0000 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.954.9; Fri, 20 Jun 2014 19:21:47 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.118]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.97]) with mapi id 15.00.0954.000; Fri, 20 Jun 2014 19:21:47 +0000 From: Kelly Grizzle To: Phil Hunt , Thomas Krille Thread-Topic: [scim] Proposed new text for PUT (ticket 76) Thread-Index: AQHPfp3qCXWazdfo2E+aDPxz8dSdJZtsS2WAgAqfegCAAGJvgIABhycAgAGoAwA= Date: Fri, 20 Jun 2014 19:21:47 +0000 Message-ID: <0cf6b5a92cb5467386263b554cd04b52@BN1PR04MB392.namprd04.prod.outlook.com> References: <5398A21B.4000502@mnt.se> <7CDF2C44-56C1-4B34-A0EA-437D631E411B@oracle.com> <36DDD84B-9E95-4799-A852-2CC1C5741BE1@oracle.com> In-Reply-To: <36DDD84B-9E95-4799-A852-2CC1C5741BE1@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: B5A6411F007716B5A6426C x-originating-ip: [97.79.140.10] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(377424004)(24454002)(51704005)(377454003)(199002)(189002)(19300405004)(66066001)(92566001)(101416001)(64706001)(76176999)(33646001)(46102001)(76482001)(19580395003)(83322001)(85306003)(86362001)(81542001)(16601075003)(561944003)(106116001)(81342001)(54356999)(83072002)(85852003)(19625215002)(77096002)(15202345003)(4396001)(99396002)(79102001)(80022001)(50986999)(95666004)(31966008)(20776003)(87936001)(16236675004)(74662001)(2656002)(93886003)(99286002)(19580405001)(105586002)(19609705001)(15975445006)(74316001)(106356001)(77982001)(74502001)(21056001)(76576001)(24736002)(106276001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: sailpoint.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kelly.grizzle@sailpoint.com; Content-Type: multipart/alternative; boundary="_000_0cf6b5a92cb5467386263b554cd04b52BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/XPW6B8AbT687NEvctsmy_g8dsbE Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Proposed new text for PUT (ticket 76) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 19:21:58 -0000 --_000_0cf6b5a92cb5467386263b554cd04b52BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1. I like this, Phil. Good work! From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, June 19, 2014 1:04 PM To: Thomas Krille Cc: Leif Johansson; scim@ietf.org Subject: Re: [scim] Proposed new text for PUT (ticket 76) Group, Please find below, some new text for PUT. This should keep most of our curr= ent logic intact but I hope addresses the issues giving clients and servers= the right balance of "intent" and "interpretation". As I mentioned in my previous issue, there is the issue of unspecified valu= es being defaulted by the server.In the example below, I show the client se= tting "roles" to [] in order to say the User is to have no roles (as oppose= d to a default set). If you like this, I will apply similar language to th= e POST operation. See bold sections below... 3.3.1. Replacing with PUT HTTP PUT is used to perform a full update of a resource's attributes. Clients that MAY have previously retrieved the entire resource in advance and revised it, MAY replace the resource using an HTTP PUT. Because SCIM resource identifiers are typically assigned by the service provider, HTTP PUT SHOULD NOT be used to create new resources. As the operation intent is to replace all attributes, SCIM clients MAY send all attributes regardless of each attribute's mutability. The server will apply attribute by attribute replace according to the following attribute mutability rules: readWrite, writeOnly Any values provided SHALL replace the existing attribute values. immutable If value(s) are already set for the attribute, the input value(s) MUST match or HTTP status 400 SHOULD be returned with error code "mutability". If the service provider has no existing values, the new value(s) SHALL be applied. readOnly Any values provided (e.g. meta.resourceType) SHALL be ignored. If an attribute is "required", clients MUST specify the attribute in the PUT request. Attributes whose mutability is "readWrite", that are omitted from the request body, MAY be assumed to be not asserted by the client. The service provider MAY assume any existing values are to be cleared or the service provider MAY assign a default value to the final resource representation. Service providers MAY take into account whether a client has access to, or understands, all of the resource's attributes when deciding whether non-asserted attributes SHALL be removed or defaulted. Clients that would like to override a server defaults, MAY specify "null" for a single-valued attribute or an empty array "[]" for a multi-valued attribute to clear all values. Unless otherwise specified a successful PUT operation returns a 200 OK response code and the entire resource within the response body, enabling the client to correlate the client's and Provider's views of the updated resource. Example: PUT /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/scim+json Content-Type: application/scim+json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas":["urn:scim:schemas:core:2.0:User"], "id":"2819c223-7f76-453a-919d-413861904646", "userName":"bjensen", "externalId":"bjensen", "name":{ "formatted":"Ms. Barbara J Jensen III", "familyName":"Jensen", "givenName":"Barbara", "middleName":"Jane" }, "roles":[], "emails":[ { "value":"bjensen@example.com" }, { "value":"babs@jensen.org" } ] } Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 18, 2014, at 11:44 AM, Phil Hunt > wrote: Another complication is "default" values. A client omitting an attribute: * may not know about the attribute as being part of the representation (e.g= . because of access control) * may intend to replace the values of the attribute with nothing (null). * may be simply saying assign the default value. Having a client being able to say "attribute":null would be a nice way to a= llow clients to differentiate between, don't know/want default and explici= tly intend to replace with a null value. e.g. set roles to null. Do we want to put this in the next draft and give it a try? We can always p= ull it out in the following draft if implementers find it doesn't make the = logic simpler. I do caution that we are hoping to go to last call in Toron= to. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 18, 2014, at 5:51 AM, Thomas Krille > wrote: Hello, looks good to me. +1 for not creating new resources via PUT. i will have to try to implement the revised behavior in order to issue a fi= nal, more qualified statement. Best Regards Thomas Krille Softwareentwicklung tarent solutions GmbH Telefon +49 (0) 30 138803-128 Telefax +49 (0) 228 54881-235 t.krille@tarent.de Rochusstra=DFe 2-4, D-53123 Bonn * http://www.tarent.de/ Tel: +49 228 54881-0 * Fax: +49 228 54881-235 HRB AG Bonn 5168 * USt-ID (VAT): DE122264941 Gesch=E4ftsf=FChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander= Steeg 2014-06-11 20:38 GMT+02:00 Leif Johansson >: On 2014-06-02 22:03, Phil Hunt wrote: > Here is some proposed new text. I've tried to tweak the text a bit to > help solve Ticket 76 regarding what to do about missing or omitted > attributes. > I want to encourage/urge everyone to think about and review this proposal. It is very likely the last big issue left to us! > After some analysis, I think this is closest in logic to how people are > using PUT now. Because PUT is mandatory, I believe we need to be very > precise. > > I have also added text stating that PUT should not be used to create new > resources. Is the word "SHOULD" appropriate? The real problem with > using PUT for resource creation is the client gets to create their own > identifier. > >> 3.3.1. Modifying with PUT >> >> HTTP PUT is used to perform a full update of a resource's attributes. >> Clients having previously retrieved the entire resource in advance, >> update the desired attributes and use HTTP PUT to replace previously >> stored attributes. HTTP PUT SHOULD NOT be used to create a new >> resource. >> >> As the operation intent is to replace attributes, SCIM clients MAY >> send all attributes regardless of each attribute's mutability. The >> server will apply attribute by attribute replace according to the >> following attribute mutability rules: >> >> readWrite, writeOnly Any values provided SHALL replace the existing >> attribute values. >> >> immutable If values are already set in the attribute they MUST match >> existing data or an error is returned. If the service provider >> has no existing values, the new value(s) SHALL be applied. >> >> readOnly Any values provided (e.g. meta.resourceType) SHALL be >> ignored. >> >> If an attribute is "required", clients MUST specify the attribute in >> the PUT request. >> >> Clients MAY specify "null" or empty set "[]" to clear an existing >> value or clear a multi-valued array. >> >> Since a client may not have access to, or may not be aware of, the >> full schema for a resource, omitted or unspecified values SHOULD be >> ignored. >> >> If a value provided for an immutable attribute with an existing value >> is NOT matched, the server SHALL respond with an HTTP response code >> of 400 and an appropriate human readable message indicating an >> attempt to change an immutable attribute. [[Editor: An appropriate >> error code should be indicated e.g. 'mutability']] >> >> Unless otherwise specified a successful PUT operation returns a 200 >> OK response code and the entire resource within the response body, >> enabling the client to correlate the client's and Provider's views of >> the updated resource. Example: >> > > > 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 --_000_0cf6b5a92cb5467386263b554cd04b52BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1.  I like this= , Phil.  Good work!

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, June 19, 2014 1:04 PM
To: Thomas Krille
Cc: Leif Johansson; scim@ietf.org
Subject: Re: [scim] Proposed new text for PUT (ticket 76)=

 

Group,

 

Please find below, some new text for PUT. This shoul= d keep most of our current logic intact but I hope addresses the issues giv= ing clients and servers the right balance of “intent” and ̶= 0;interpretation”.

 

As I mentioned in my previous issue, there is the is= sue of unspecified values being defaulted by the server.In the example belo= w, I show the client setting “roles” to [] in order to say the = User is to have no roles (as opposed to a default set).  If you like this, I will apply similar language to the POST op= eration.

 

See bold= sections below...

3.3.1.  Repl=
acing with PUT
 
   HTTP PUT is used to perf=
orm a full update of a resource's attributes.
   Clients that MAY have pr=
eviously retrieved the entire resource in
   advance and revised it, =
MAY replace the resource using an HTTP PUT.
   Because SCIM resource id=
entifiers are typically assigned by the
   service provider, HTTP P=
UT SHOULD NOT be used to create new
   resources.
 
   As the operation intent is to replace all attributes, SCI=
M clients
   MAY send all attributes regardless of each attribute's mu=
tability.
   The server will apply attribute by attribute replace acco=
rding to the
   following attribute mutability rules:
 
   readWrite, writeOnly  Any values provided SHALL repl=
ace the existing
      attribute values.
 
   immutable  If value(s) are already set for the attri=
bute, the input
      value(s) MUST match or HTTP status 400 =
SHOULD be returned with
      error code "mutability". =
; If the service provider has no existing
      values, the new value(s) SHALL be appli=
ed.
 
   readOnly  Any values provided (e.g.  meta.resou=
rceType) SHALL be
      ignored.
 
   If an attribute is "required", clients MUST spe=
cify the attribute in
   the PUT request.
 
   Attributes whose mutabil=
ity is "readWrite", that are omitted from the
   request body, MAY be ass=
umed to be not asserted by the client.  The

   service provider MAY ass=
ume any existing values are to be cleared or


   the service provider MAY=
 assign a default value to the final resource


   representation.  Se=
rvice providers MAY take into account whether a


   client has access to, or=
 understands, all of the resource's


   attributes when deciding=
 whether non-asserted attributes SHALL be


   removed or defaulted.&nb=
sp; Clients that would like to override a server

   defaults, MAY specify &q=
uot;null" for a single-valued attribute or an

   empty array "[]&quo=
t; for a multi-valued attribute to clear all values.


 


   Unless otherwise specified a successful PUT operation ret=
urns a 200


   OK response code and the entire resource within the respo=
nse body,


   enabling the client to correlate the client's and Provide=
r's views of


   the updated resource.  Example:


 


   PUT /Users/2819c223-7f76-453a-919d-413861904646


   Host: example.com=



   Accept: application/scim+json


   Content-Type: application/scim+json


   Authorization: Bearer h480djs93hd8


   If-Match: W/"a330bc54f0671c9"


 


   {


     "schemas":["urn:scim:schemas:c=
ore:2.0:User"],


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


     "userName":"bjensen",


     "externalId":"bjensen",


     "name":{


       "formatted":"Ms. B=
arbara J Jensen III",


       "familyName":"Jens=
en",


       "givenName":"Barba=
ra",


       "middleName":"Jane=
"


     },


     "roles&=
quot;:[],


     "emails":[


       {


           "val=
ue":"bjensen@example.com"


       },


       {


           "val=
ue":"babs@jensen.org"=



       }


     ]


   }

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

On Jun 18, 2014, at 11:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:



Another complication is “default” values= .

 

A client omitting an attribute:

* may not know about the attribute as being part of = the representation (e.g. because of access control)

* may intend to replace the values of the attribute = with nothing (null).

* may be simply saying assign the default value.

 

Having a client being able to say “attribute&#= 8221;:null would be a nice way to allow clients to differentiate between, &= nbsp;don’t know/want default and explicitly intend to replace with a = null value.  e.g. set roles to null.

 

Do we want to put this in the next draft and give it= a try? We can always pull it out in the following draft if implementers fi= nd it doesn’t make the logic simpler.  I do caution that we are = hoping to go to last call in Toronto.  

 

 

 

 

On Jun 18, 2014, at 5:51 AM, Thomas Krille <t.krille@tarent.de> wrote:



Hello,

 

looks good to me. +1 for not creating new resour= ces via PUT.

 

i will have to try to implement the revised behavior= in order to issue a final, more qualified statement.

 

Best Regards


Thomas Krille
Softwareentwicklung
tarent solutions GmbH

Telefon +49 (0) 30 138803-128
Telefax +49 (0) 228 54881-235
t.krille@tarent.de<= /a>


Rochusstra=DFe 2-4, D-53123 Bonn • http://www.tarent.de/<= /span>
Tel: +49 228 54881-0 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Gesch=E4ftsf=FChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander= Steeg

 

2014-06-11 20:38 GMT+02:00 Leif Johansson <leifj@mnt.se>:<= /o:p>

On 2014-06-02 22:03, = Phil Hunt wrote:
> Here is some proposed new text.  I’ve tried to tweak the te= xt a bit to
> help solve Ticket 76 regarding what to do about missing or omitted
> attributes.
>

I want to encourage/urge everyone to think about and= review this
proposal. It is very likely the last big issue left to us!


> After some analysis, I think this is closest in logic to how people ar= e
> using PUT now.  Because PUT is mandatory, I believe we need to be= very
> precise.
>
> I have also added text stating that PUT should not be used to create n= ew
> resources. Is the word “SHOULD” appropriate?  The rea= l problem with
> using PUT for resource creation is the client gets to create their own=
> identifier.
>
>> 3.3.1.  Modifying with PUT
>>
>>    HTTP PUT is used to perform a full update of a resour= ce's attributes.
>>    Clients having previously retrieved the entire resour= ce in advance,
>>    update the desired attributes and use HTTP PUT to rep= lace previously
>>    stored attributes.  HTTP PUT SHOULD NOT be used = to create a new
>>    resource.
>>
>>    As the operation intent is to replace attributes, SCI= M clients MAY
>>    send all attributes regardless of each attribute's mu= tability.  The
>>    server will apply attribute by attribute replace acco= rding to the
>>    following attribute mutability rules:
>>
>>    readWrite, writeOnly  Any values provided SHALL = replace the existing
>>       attribute values.
>>
>>    immutable  If values are already set in the attr= ibute they MUST match
>>       existing data or an error is returned.  = If the service provider
>>       has no existing values, the new value(s) SHAL= L be applied.
>>
>>    readOnly  Any values provided (e.g.  meta.r= esourceType) SHALL be
>>       ignored.
>>
>>    If an attribute is "required", clients MUST= specify the attribute in
>>    the PUT request.
>>
>>    Clients MAY specify "null" or empty set &qu= ot;[]" to clear an existing
>>    value or clear a multi-valued array.
>>
>>    Since a client may not have access to, or may not be = aware of, the
>>    full schema for a resource, omitted or unspecified va= lues SHOULD be
>>    ignored.
>>
>>    If a value provided for an immutable attribute with a= n existing value
>>    is NOT matched, the server SHALL respond with an HTTP= response code
>>    of 400 and an appropriate human readable message indi= cating an
>>    attempt to change an immutable attribute.  [[Edi= tor: An appropriate
>>    error code should be indicated e.g. 'mutability']] >>
>>    Unless otherwise specified a successful PUT operation= returns a 200
>>    OK response code and the entire resource within the r= esponse body,
>>    enabling the client to correlate the client's and Pro= vider's views of
>>    the updated resource.  Example:
>>
>
>
> Phil
>
> @independentid

> www.independentid.com <http://www.independentid.com>
> phil.hunt@oracle.com <m= ailto:phil.hunt@oracle.com><= br> >
>
>
>
>
> _______________________________________________
> 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

 

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

 

--_000_0cf6b5a92cb5467386263b554cd04b52BN1PR04MB392namprd04pro_-- From nobody Sat Jun 21 16:13:37 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E361A0313 for ; Sat, 21 Jun 2014 16:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0Gyl-F_Dens for ; Sat, 21 Jun 2014 16:13:34 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1EA81A0400 for ; Sat, 21 Jun 2014 16:13:34 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5LNDXfb007264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 21 Jun 2014 23:13:34 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5LNDXXn001903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Jun 2014 23:13:33 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5LNDVMr016379 for ; Sat, 21 Jun 2014 23:13:32 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 21 Jun 2014 16:13:31 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_EFE7FDA0-BB13-4B4A-8B9D-D349D8E861E6" Message-Id: <40EBEE3A-705D-489B-A90D-23F5FA2784EC@oracle.com> Date: Sat, 21 Jun 2014 16:13:30 -0700 To: Scim WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Hn7lNALXye1db58WjkZMc4Ld2iw Subject: [scim] Intent of externalId X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 23:13:36 -0000 --Apple-Mail=_EFE7FDA0-BB13-4B4A-8B9D-D349D8E861E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 FYI=85 I am going through the drafts gradually now and will be asking = =93dumb=94 questions on things where intent may have changed over time = or may no longer be clear. On of those issues is externalId. Currently the spec states: > externalId An identifier for the resource as defined by the client. > The "externalId" may simplify identification of the resource > between client and service provider by allowing the client to > refer to the resource with its own identifier, obviating the = need > to store a local mapping between the local identifier of the > resource and the identifier used by the service provider. Each > resource MAY include a non-empty externalId value. The value of > the "externalId" attribute is always issued by the client and = can > never be specified by the service provider. The service = provider > MUST always interpret the externalId as scoped to the client's > tenant. What is meant by =93allowing the client to refer to the resource with = its own identifier=94? I am assuming what this means is to query for = the resource using a filter. OR do we mean that that both of the = following URL are valid and return the same object?: http://example.com/Users/{externalId} http://example.com/Users/{id} May I assume that externalId is only usable in a filter to refer to the = resource? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_EFE7FDA0-BB13-4B4A-8B9D-D349D8E861E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
FYI=85 I am going through the drafts gradually = now and will be asking =93dumb=94 questions on things where intent may = have changed over time or may no longer be = clear.

On of those issues is externalId. = Currently the spec states:
 externalId  An =
identifier for the resource as defined by the client.
      The "externalId" may simplify identification of the resource
      between client and service provider by allowing the client to
      refer to the resource with its own identifier, obviating the =
need
      to store a local mapping between the local identifier of the
      resource and the identifier used by the service provider.  Each
      resource MAY include a non-empty externalId value.  The value of
      the "externalId" attribute is always issued by the client and can
      never be specified by the service provider.  The service provider
      MUST always interpret the externalId as scoped to the client's
      tenant.
What is meant by =93allowing the = client to refer to the resource with its own identifier=94?  I am = assuming what this means is to query for the resource using a filter. =  OR do we mean that that both of the following URL are valid and = return the same object?:

http://example.com/Users/{id}

May I assume that externalId is only usable in a filter to = refer to the = resource?

Phil

@independ= entid
phil.hunt@oracle.com



= --Apple-Mail=_EFE7FDA0-BB13-4B4A-8B9D-D349D8E861E6-- From nobody Sat Jun 21 16:24:21 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC881A040C for ; Sat, 21 Jun 2014 16:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKnZOevERmjG for ; Sat, 21 Jun 2014 16:24:14 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B81F1A0283 for ; Sat, 21 Jun 2014 16:24:13 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id mc6so3188064lab.24 for ; Sat, 21 Jun 2014 16:24:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=S+vG0l+UMEk6GY09bSEO39Qan9pTDIzKetn/O0ZUlw8=; b=BL/qnwSzTB76QaEO8224mKmXjm5uGtxJPspM+/uooYoSz8qDcUexBbZWhvaQTROECc LKTcu/AkwZ346RE+g6d86qAoyL72yawLDe4n6229NQZWCNdv8dcx2Ewyrzymd7WVGSdn pRKb/e9ruXxFNYM6hHA9LKp4rAghq0aKOMC9EsjZemvUW8XCE8eXNz4qJcj4t7m5Iy5B HV1l11PQDhWwA1/rQbxrZ1XkZpXrqn9Bof+/rFDshpdP73RPohiWqKfk1XIdHLzgeRAI lNySMeEKelRdiWdTdQAL/X/OISyPIeyQ79uDFpYNgkLwUTPvP73i4Ai8nvbHTeTSYHyl mfsw== X-Gm-Message-State: ALoCoQmPwX5i8NMzNN84rkoMQfNNanJxaeUfMqEzsNn1fBiUdO5Wu6w7bfsFlhWEd7IHEiZx+h3g X-Received: by 10.112.91.163 with SMTP id cf3mr8713310lbb.42.1403393052209; Sat, 21 Jun 2014 16:24:12 -0700 (PDT) Received: from [10.0.0.115] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id si9sm5650221lac.42.2014.06.21.16.24.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Jun 2014 16:24:11 -0700 (PDT) Message-ID: <53A6141A.4010601@mnt.se> Date: Sun, 22 Jun 2014 01:24:10 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: scim@ietf.org References: <40EBEE3A-705D-489B-A90D-23F5FA2784EC@oracle.com> In-Reply-To: <40EBEE3A-705D-489B-A90D-23F5FA2784EC@oracle.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/4uNTuItX9xmgBccwHaAqtXfrmlg Subject: Re: [scim] Intent of externalId X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 23:24:19 -0000 On 2014-06-22 01:13, Phil Hunt wrote: > FYI… I am going through the drafts gradually now and will be asking > “dumb” questions on things where intent may have changed over time or > may no longer be clear. > > On of those issues is externalId. Currently the spec states: >> externalId An identifier for the resource as defined by the client. >> The "externalId" may simplify identification of the resource >> between client and service provider by *allowing the client to >> refer to the resource with its own identifier*, obviating the need >> to store a local mapping between the local identifier of the >> resource and the identifier used by the service provider. Each >> resource MAY include a non-empty externalId value. The value of >> the "externalId" attribute is always issued by the client and can >> never be specified by the service provider. The service provider >> MUST always interpret the externalId as scoped to the client's >> tenant. > What is meant by “allowing the client to refer to the resource with its > own identifier”? I am assuming what this means is to query for the > resource using a filter. OR do we mean that that both of the following > URL are valid and return the same object?: > > http://example.com/Users/{externalId} > http://example.com/Users/{id} > > May I assume that externalId is only usable in a filter to refer to the > resource? Not sure I grok you fully but I don't think its reasonable for the client-supplied id namespace to overlap the system id namespace so I think you're right: externalId must be used in filters. However the client should be able to expect a unique match. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From nobody Sun Jun 22 13:11:06 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31A41A02FA for ; Sun, 22 Jun 2014 13:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fv82ZiDcvRMo for ; Sun, 22 Jun 2014 13:10:55 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CFA01A01BB for ; Sun, 22 Jun 2014 13:10:53 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Sun, 22 Jun 2014 22:10:37 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0847.030; Sun, 22 Jun 2014 22:10:37 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Leif Johansson Thread-Topic: [scim] Intent of externalId Thread-Index: AQHPjaZzzIGq82rKX0uKlzHrrFhmWZt8EvsAgAFcPwA= Date: Sun, 22 Jun 2014 20:10:36 +0000 Message-ID: <470B0171-A0CB-4CEF-B047-FD21DDA58D69@nexusgroup.com> References: <40EBEE3A-705D-489B-A90D-23F5FA2784EC@oracle.com> <53A6141A.4010601@mnt.se> In-Reply-To: <53A6141A.4010601@mnt.se> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.69] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2915866DF739DE4C97B8430D8BE459C6@nexusgroup.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/5NMfryFU7dSaDvNg1LwL4kXEigg Cc: "scim@ietf.org" Subject: Re: [scim] Intent of externalId X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 20:11:04 -0000 Yes, I agree. It should be possible to use it in filters, but not as an par= t of an URI like http://example.com/Users/{externalId} / Erik On 22 Jun 2014, at 01:24, Leif Johansson wrote: > On 2014-06-22 01:13, Phil Hunt wrote: >> FYI=85 I am going through the drafts gradually now and will be asking >> =93dumb=94 questions on things where intent may have changed over time o= r >> may no longer be clear. >>=20 >> On of those issues is externalId. Currently the spec states: >>> externalId An identifier for the resource as defined by the client. >>> The "externalId" may simplify identification of the resource >>> between client and service provider by *allowing the client to >>> refer to the resource with its own identifier*, obviating the need >>> to store a local mapping between the local identifier of the >>> resource and the identifier used by the service provider. Each >>> resource MAY include a non-empty externalId value. The value of >>> the "externalId" attribute is always issued by the client and can >>> never be specified by the service provider. The service provider >>> MUST always interpret the externalId as scoped to the client's >>> tenant. >> What is meant by =93allowing the client to refer to the resource with it= s >> own identifier=94? I am assuming what this means is to query for the >> resource using a filter. OR do we mean that that both of the following >> URL are valid and return the same object?: >>=20 >> http://example.com/Users/{externalId} >> http://example.com/Users/{id} >>=20 >> May I assume that externalId is only usable in a filter to refer to the >> resource? >=20 > Not sure I grok you fully but I don't think its reasonable for the > client-supplied id namespace to overlap the system id namespace so > I think you're right: externalId must be used in filters. However > the client should be able to expect a unique match. >=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >>=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Sun Jun 22 15:04:05 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF351A03AD for ; Sun, 22 Jun 2014 15:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9mCzuBudkeh for ; Sun, 22 Jun 2014 15:04:00 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5C91A03B3 for ; Sun, 22 Jun 2014 15:04:00 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5MM3xSC010138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 Jun 2014 22:04:00 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 s5MM3tRc019628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jun 2014 22:03:56 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5MM3twN022181; Sun, 22 Jun 2014 22:03:55 GMT Received: from [25.64.168.183] (/24.114.44.196) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 22 Jun 2014 15:03:55 -0700 References: <40EBEE3A-705D-489B-A90D-23F5FA2784EC@oracle.com> <53A6141A.4010601@mnt.se> <470B0171-A0CB-4CEF-B047-FD21DDA58D69@nexusgroup.com> Mime-Version: 1.0 (1.0) In-Reply-To: <470B0171-A0CB-4CEF-B047-FD21DDA58D69@nexusgroup.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <3E00DFFD-45B0-413E-A6E9-72843E1F5743@oracle.com> X-Mailer: iPhone Mail (11D201) From: Phil Hunt Date: Sun, 22 Jun 2014 15:03:50 -0700 To: =?utf-8?Q?Erik_Wahlstr=C3=B6m?= X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/_1DzzPpCBVXS-scP37lIbZ_TAu0 Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Intent of externalId X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 22:04:03 -0000 Thanks! I will clarify the paragraph.=20 Phil > On Jun 22, 2014, at 13:10, Erik Wahlstr=C3=B6m wrote: >=20 > Yes, I agree. It should be possible to use it in filters, but not as an pa= rt of an URI like http://example.com/Users/{externalId} >=20 > / Erik >=20 >=20 >> On 22 Jun 2014, at 01:24, Leif Johansson wrote: >>=20 >>> On 2014-06-22 01:13, Phil Hunt wrote: >>> FYI=E2=80=A6 I am going through the drafts gradually now and will be ask= ing >>> =E2=80=9Cdumb=E2=80=9D questions on things where intent may have changed= over time or >>> may no longer be clear. >>>=20 >>> On of those issues is externalId. Currently the spec states: >>>> externalId An identifier for the resource as defined by the client. >>>> The "externalId" may simplify identification of the resource >>>> between client and service provider by *allowing the client to >>>> refer to the resource with its own identifier*, obviating the need >>>> to store a local mapping between the local identifier of the >>>> resource and the identifier used by the service provider. Each >>>> resource MAY include a non-empty externalId value. The value of >>>> the "externalId" attribute is always issued by the client and can >>>> never be specified by the service provider. The service provider >>>> MUST always interpret the externalId as scoped to the client's >>>> tenant. >>> What is meant by =E2=80=9Callowing the client to refer to the resource w= ith its >>> own identifier=E2=80=9D? I am assuming what this means is to query for t= he >>> resource using a filter. OR do we mean that that both of the following >>> URL are valid and return the same object?: >>>=20 >>> http://example.com/Users/{externalId} >>> http://example.com/Users/{id} >>>=20 >>> May I assume that externalId is only usable in a filter to refer to the >>> resource? >>=20 >> Not sure I grok you fully but I don't think its reasonable for the >> client-supplied id namespace to overlap the system id namespace so >> I think you're right: externalId must be used in filters. However >> the client should be able to expect a unique match. >>=20 >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon Jun 23 01:17:42 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90EB1B2899 for ; Mon, 23 Jun 2014 01:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.724 X-Spam-Level: X-Spam-Status: No, score=0.724 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRopPFGmEkKs for ; Mon, 23 Jun 2014 01:17:35 -0700 (PDT) Received: from mail-ob0-f198.google.com (mail-ob0-f198.google.com [209.85.214.198]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028521A0294 for ; Mon, 23 Jun 2014 01:17:34 -0700 (PDT) Received: by mail-ob0-f198.google.com with SMTP id uy5so21396960obc.1 for ; Mon, 23 Jun 2014 01:17: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VfMC/MGG6xpboQtqgyb19l6HWBi2UIiQCWs/UVtlSpE=; b=G+lRQ0I5QUrE/2F4Cj/bctJQFtQJtRDhK7wmfl7v6I0YSb289y8sl1pkqMBviMOY0c bkgf82B3MY2aYF+7aELosQu0sUfIcIIo8wN9rWvjTBfU88Kkq8Kdmdl3SyvWC6IWqtbg dkOcYAZxLEBOVXMpCR+6AfmkBX/wt25LDnylEc08M1HnT5BdhgI3maiq2BPGRWwSRhVk kKGsIq0YE7j3cxLJ9yqG8DJJmfFkbxkPNOOTg3xeCDcPcVZ+BekL9jKDa4PdP6PfN0OH pTmhsHKw52FNCMNdvMQjc/etNil0zLedeWjO9wzcptLgrGSB6qMYr9q4hPCntjl56fCt N/2g== X-Gm-Message-State: ALoCoQlAPTKE/UU3FLd/ofHXuDvG7NKc3+E/BlXKWLKWqh7SOwVm/keHrvf2I77keQnyoRAkemOY X-Received: by 10.50.176.167 with SMTP id cj7mr24896072igc.44.1403511454048; Mon, 23 Jun 2014 01:17:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.78.101 with HTTP; Mon, 23 Jun 2014 01:17:12 -0700 (PDT) In-Reply-To: <0cf6b5a92cb5467386263b554cd04b52@BN1PR04MB392.namprd04.prod.outlook.com> References: <5398A21B.4000502@mnt.se> <7CDF2C44-56C1-4B34-A0EA-437D631E411B@oracle.com> <36DDD84B-9E95-4799-A852-2CC1C5741BE1@oracle.com> <0cf6b5a92cb5467386263b554cd04b52@BN1PR04MB392.namprd04.prod.outlook.com> From: Thomas Krille Date: Mon, 23 Jun 2014 10:17:12 +0200 Message-ID: To: Kelly Grizzle Content-Type: multipart/alternative; boundary=089e0111be12a840f204fc7c79be Archived-At: http://mailarchive.ietf.org/arch/msg/scim/iyEIs5iWLlctwsJSJ_PGg4JxHpQ Cc: Leif Johansson , "scim@ietf.org" , Phil Hunt Subject: Re: [scim] Proposed new text for PUT (ticket 76) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 08:17:40 -0000 --089e0111be12a840f204fc7c79be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1, thank you Phil Thomas Krille Softwareentwicklung tarent solutions GmbH Telefon +49 (0) 30 138803-128 Telefax +49 (0) 228 54881-235 t.krille@tarent.de Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/ Tel: +49 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235 HRB AG Bonn 5168 =E2=80=A2 USt-ID (VAT): DE122264941 Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale= xander Steeg 2014-06-20 21:21 GMT+02:00 Kelly Grizzle : > +1. I like this, Phil. Good work! > > > > *From:* scim [mailto:scim-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Thursday, June 19, 2014 1:04 PM > *To:* Thomas Krille > *Cc:* Leif Johansson; scim@ietf.org > *Subject:* Re: [scim] Proposed new text for PUT (ticket 76) > > > > Group, > > > > Please find below, some new text for PUT. This should keep most of our > current logic intact but I hope addresses the issues giving clients and > servers the right balance of =E2=80=9Cintent=E2=80=9D and =E2=80=9Cinterp= retation=E2=80=9D. > > > > As I mentioned in my previous issue, there is the issue of unspecified > values being defaulted by the server.In the example below, I show the > client setting =E2=80=9Croles=E2=80=9D to [] in order to say the User is = to have no roles > (as opposed to a default set). If you like this, I will apply similar > language to the POST operation. > > > > See *bold* sections below... > > 3.3.1. Replacing with PUT > > > > *HTTP PUT is used to perform a full update of a resource's attributes.= * > > * Clients that MAY have previously retrieved the entire resource in* > > * advance and revised it, MAY replace the resource using an HTTP PUT.* > > * Because SCIM resource identifiers are typically assigned by the* > > * service provider, HTTP PUT SHOULD NOT be used to create new* > > * resources.* > > > > As the operation intent is to replace all attributes, SCIM clients > > MAY send all attributes regardless of each attribute's mutability. > > The server will apply attribute by attribute replace according to the > > following attribute mutability rules: > > > > readWrite, writeOnly Any values provided SHALL replace the existing > > attribute values. > > > > immutable If value(s) are already set for the attribute, the input > > value(s) MUST match or HTTP status 400 SHOULD be returned with > > error code "mutability". If the service provider has no existing > > values, the new value(s) SHALL be applied. > > > > readOnly Any values provided (e.g. meta.resourceType) SHALL be > > ignored. > > > > If an attribute is "required", clients MUST specify the attribute in > > the PUT request. > > > > * Attributes whose mutability is "readWrite", that are omitted from the= * > > * request body, MAY be assumed to be not asserted by the client. The* > > * service provider MAY assume any existing values are to be cleared or* > > * the service provider MAY assign a default value to the final resource= * > > * representation. Service providers MAY take into account whether a* > > * client has access to, or understands, all of the resource's* > > * attributes when deciding whether non-asserted attributes SHALL be* > > * removed or defaulted. Clients that would like to override a server* > > * defaults, MAY specify "null" for a single-valued attribute or an* > > * empty array "[]" for a multi-valued attribute to clear all values.* > > > > Unless otherwise specified a successful PUT operation returns a 200 > > OK response code and the entire resource within the response body, > > enabling the client to correlate the client's and Provider's views of > > the updated resource. Example: > > > > PUT /Users/2819c223-7f76-453a-919d-413861904646 > > Host: example.com > > Accept: application/scim+json > > Content-Type: application/scim+json > > Authorization: Bearer h480djs93hd8 > > If-Match: W/"a330bc54f0671c9" > > > > { > > "schemas":["urn:scim:schemas:core:2.0:User"], > > "id":"2819c223-7f76-453a-919d-413861904646", > > "userName":"bjensen", > > "externalId":"bjensen", > > "name":{ > > "formatted":"Ms. Barbara J Jensen III", > > "familyName":"Jensen", > > "givenName":"Barbara", > > "middleName":"Jane" > > }, > > *"roles":[],* > > "emails":[ > > { > > "value":"bjensen@example.com" > > }, > > { > > "value":"babs@jensen.org" > > } > > ] > > } > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > On Jun 18, 2014, at 11:44 AM, Phil Hunt wrote: > > > > Another complication is =E2=80=9Cdefault=E2=80=9D values. > > > > A client omitting an attribute: > > * may not know about the attribute as being part of the representation > (e.g. because of access control) > > * may intend to replace the values of the attribute with nothing (null). > > * may be simply saying assign the default value. > > > > Having a client being able to say =E2=80=9Cattribute=E2=80=9D:null would = be a nice way to > allow clients to differentiate between, don=E2=80=99t know/want default = and > explicitly intend to replace with a null value. e.g. set roles to null. > > > > Do we want to put this in the next draft and give it a try? We can always > pull it out in the following draft if implementers find it doesn=E2=80=99= t make the > logic simpler. I do caution that we are hoping to go to last call in > Toronto. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > On Jun 18, 2014, at 5:51 AM, Thomas Krille wrote: > > > > Hello, > > > > looks good to me. +1 for not creating new resources via PUT. > > > > i will have to try to implement the revised behavior in order to issue a > final, more qualified statement. > > > > Best Regards > > > Thomas Krille > Softwareentwicklung > tarent solutions GmbH > > Telefon +49 (0) 30 138803-128 > Telefax +49 (0) 228 54881-235 > t.krille@tarent.de > > > Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/ > Tel: +49 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235 > HRB AG Bonn 5168 =E2=80=A2 USt-ID (VAT): DE122264941 > Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, A= lexander > Steeg > > > > 2014-06-11 20:38 GMT+02:00 Leif Johansson : > > On 2014-06-02 22:03, Phil Hunt wrote: > > Here is some proposed new text. I=E2=80=99ve tried to tweak the text a= bit to > > help solve Ticket 76 regarding what to do about missing or omitted > > attributes. > > > > I want to encourage/urge everyone to think about and review this > proposal. It is very likely the last big issue left to us! > > > > After some analysis, I think this is closest in logic to how people are > > using PUT now. Because PUT is mandatory, I believe we need to be very > > precise. > > > > I have also added text stating that PUT should not be used to create ne= w > > resources. Is the word =E2=80=9CSHOULD=E2=80=9D appropriate? The real = problem with > > using PUT for resource creation is the client gets to create their own > > identifier. > > > >> 3.3.1. Modifying with PUT > >> > >> HTTP PUT is used to perform a full update of a resource's attribute= s. > >> Clients having previously retrieved the entire resource in advance, > >> update the desired attributes and use HTTP PUT to replace previousl= y > >> stored attributes. HTTP PUT SHOULD NOT be used to create a new > >> resource. > >> > >> As the operation intent is to replace attributes, SCIM clients MAY > >> send all attributes regardless of each attribute's mutability. The > >> server will apply attribute by attribute replace according to the > >> following attribute mutability rules: > >> > >> readWrite, writeOnly Any values provided SHALL replace the existin= g > >> attribute values. > >> > >> immutable If values are already set in the attribute they MUST mat= ch > >> existing data or an error is returned. If the service provider > >> has no existing values, the new value(s) SHALL be applied. > >> > >> readOnly Any values provided (e.g. meta.resourceType) SHALL be > >> ignored. > >> > >> If an attribute is "required", clients MUST specify the attribute i= n > >> the PUT request. > >> > >> Clients MAY specify "null" or empty set "[]" to clear an existing > >> value or clear a multi-valued array. > >> > >> Since a client may not have access to, or may not be aware of, the > >> full schema for a resource, omitted or unspecified values SHOULD be > >> ignored. > >> > >> If a value provided for an immutable attribute with an existing val= ue > >> is NOT matched, the server SHALL respond with an HTTP response code > >> of 400 and an appropriate human readable message indicating an > >> attempt to change an immutable attribute. [[Editor: An appropriate > >> error code should be indicated e.g. 'mutability']] > >> > >> Unless otherwise specified a successful PUT operation returns a 200 > >> OK response code and the entire resource within the response body, > >> enabling the client to correlate the client's and Provider's views = of > >> the updated resource. Example: > >> > > > > > > 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 > > > --089e0111be12a840f204fc7c79be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1, thank you Phil

Thomas Krille
Softwareentwicklung
tarent s= olutions GmbH

Telefon +49 (0) 30 138803-128
Telefax +49 (0) 228 5= 4881-235
t.krille@tarent.de<= /a>

Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2=C2=A0http= ://www.tarent.de/
Tel: +49 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235
HRB AG Bonn 5168 = =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefa= n Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


2014-06-20 21:21 GMT+02:00 Kelly Grizzle= <kelly.grizzle@sailpoint.com>:

+1.=C2=A0 I like this, Ph= il.=C2=A0 Good work!

=C2=A0

From: scim [ma= ilto:scim-bounce= s@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, June 19, 2014 1:04 PM
To: Thomas Krille
Cc: Leif Johansson; scim@ietf.org
Subject: Re: [scim] Proposed new text for PUT (ticket 76)<= /u>

=C2=A0

Group,

=C2=A0

Please find below, some new text for PUT. This shoul= d keep most of our current logic intact but I hope addresses the issues giv= ing clients and servers the right balance of =E2=80=9Cintent=E2=80=9D and = =E2=80=9Cinterpretation=E2=80=9D.

=C2=A0

As I mentioned in my previous issue, there is the is= sue of unspecified values being defaulted by the server.In the example belo= w, I show the client setting =E2=80=9Croles=E2=80=9D to [] in order to say = the User is to have no roles (as opposed to a default set). =C2=A0If you like this, I will apply similar language to the POST op= eration.

=C2=A0

See bold= sections below...

3.3.1.=C2=A0 Repla=
cing with PUT
=C2=A0
=C2=A0 =C2=A0HTTP PUT is used to perf=
orm a full update of a resource's attributes.<=
/pre>

=C2=A0=C2=A0 Clients that MAY have pr=
eviously retrieved the entire resource in


=C2=A0=C2=A0 advance and revised it, =
MAY replace the resource using an HTTP PUT.


=C2=A0=C2=A0 Because SCIM resource id=
entifiers are typically assigned by the


=C2=A0=C2=A0 service provider, HTTP P=
UT SHOULD NOT be used to create new


=C2=A0=C2=A0 resources.=



=C2=A0


=C2=A0=C2=A0 As the operation intent is to replace all attributes, SCI=
M clients


=C2=A0=C2=A0 MAY send all attributes regardless of each attribute'=
s mutability.


=C2=A0=C2=A0 The server will apply attribute by attribute replace acco=
rding to the


=C2=A0=C2=A0 following attribute mutability rules:


=C2=A0


=C2=A0=C2=A0 readWrite, writeOnly=C2=A0 Any values provided SHALL repl=
ace the existing


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attribute values.


=C2=A0


=C2=A0=C2=A0 immutable=C2=A0 If value(s) are already set for the attri=
bute, the input


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value(s) MUST match or HTTP status 400 =
SHOULD be returned with


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 error code "mutability".=C2=
=A0 If the service provider has no existing


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 values, the new value(s) SHALL be appli=
ed.


=C2=A0


=C2=A0=C2=A0 readOnly=C2=A0 Any values provided (e.g.=C2=A0 meta.resou=
rceType) SHALL be


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ignored.


=C2=A0


=C2=A0=C2=A0 If an attribute is "required", clients MUST spe=
cify the attribute in


=C2=A0=C2=A0 the PUT request.


=C2=A0


=C2=A0 =C2=A0Attributes whose mutabil=
ity is "readWrite", that are omitted from the


=C2=A0=C2=A0 request body, MAY be ass=
umed to be not asserted by the client.=C2=A0 The

=C2=A0=C2=A0 service provider MAY ass=
ume any existing values are to be cleared or


=C2=A0=C2=A0 the service provider MAY=
 assign a default value to the final resource

=C2=A0=C2=A0 representation.=C2=A0 Se=
rvice providers MAY take into account whether a

=C2=A0=C2=A0 client has access to, or=
 understands, all of the resource's


=C2=A0=C2=A0 attributes when deciding=
 whether non-asserted attributes SHALL be


=C2=A0=C2=A0 removed or defaulted.=C2=
=A0 Clients that would like to override a server

=C2=A0=C2=A0 defaults, MAY specify &q=
uot;null" for a single-valued attribute or an=



=C2=A0=C2=A0 empty array "[]&quo=
t; for a multi-valued attribute to clear all values.


=C2=A0


=C2=A0=C2=A0 Unless otherwise specified a successful PUT operation ret=
urns a 200


=C2=A0=C2=A0 OK response code and the entire resource within the respo=
nse body,


=C2=A0=C2=A0 enabling the client to correlate the client's and Pro=
vider's views of


=C2=A0=C2=A0 the updated resource.=C2=A0 Example:


=C2=A0


=C2=A0=C2=A0 PUT /Users/2819c223-7f76-453a-919d-413861904646=



=C2=A0=C2=A0 Host: ex=
ample.com


=C2=A0=C2=A0 Accept: application/scim+json


=C2=A0=C2=A0 Content-Type: application/scim+json


=C2=A0=C2=A0 Authorization: Bearer h480djs93hd8


=C2=A0=C2=A0 If-Match: W/"a330bc54f0671c9"

=C2=A0


=C2=A0=C2=A0 {


=C2=A0=C2=A0=C2=A0=C2=A0 "schemas":["urn:scim:schemas:c=
ore:2.0:User"],


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


=C2=A0=C2=A0=C2=A0=C2=A0 "userName":"bjensen",<=
/u>


=C2=A0=C2=A0=C2=A0=C2=A0 "externalId":"bjensen",


=C2=A0=C2=A0=C2=A0=C2=A0 "name":{


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "formatted":"Ms. B=
arbara J Jensen III",


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "familyName":"Jens=
en",


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "givenName":"Barba=
ra",


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "middleName":"Jane=
"


=C2=A0=C2=A0=C2=A0=C2=A0 },


=C2=A0=C2=A0=C2=A0=C2=A0 "roles&=
quot;:[],


=C2=A0=C2=A0=C2=A0=C2=A0 "emails":[


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "val=
ue":"bje=
nsen@example.com"


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "val=
ue":"babs@je=
nsen.org"


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }


=C2=A0=C2=A0=C2=A0=C2=A0 ]


=C2=A0=C2=A0 }

=C2=A0

Phil<= /p>

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jun 18, 2014, at 11:44 AM, Phil Hunt <phil.hunt@oracle.com= > wrote:



Another complication is =E2=80=9Cdefault=E2=80=9D va= lues.

=C2=A0

A client omitting an attribute:

* may not know about the attribute as being part of = the representation (e.g. because of access control)

* may intend to replace the values of the attribute = with nothing (null).

* may be simply saying assign the default value.<= /u>

=C2=A0

Having a client being able to say =E2=80=9Cattribute= =E2=80=9D:null would be a nice way to allow clients to differentiate betwee= n, =C2=A0don=E2=80=99t know/want default and explicitly intend to replace w= ith a null value. =C2=A0e.g. set roles to null.

=C2=A0

Do we want to put this in the next draft and give it= a try? We can always pull it out in the following draft if implementers fi= nd it doesn=E2=80=99t make the logic simpler. =C2=A0I do caution that we ar= e hoping to go to last call in Toronto. =C2=A0

=C2=A0

Phil

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Jun 18, 2014, at 5:51 AM, Thomas Krille <t.krille@tarent.de&g= t; wrote:



Hello,

=C2=A0

looks good to me. +1 for not creating new resources = via PUT.

=C2=A0

i will have to try to implement the revised behavior= in order to issue a final, more qualified statement.

=C2=A0

Best Regards


Thomas Krille
Softwareentwicklung
tarent solutions GmbH

Telefon +49 (0) 30 138803-128
Telefax +49 (0) 228 54881-235
t.krille@tarent.de<= /a>


Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2=C2=A0http://www.tarent= .de/
Tel: +49 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235
HRB AG Bonn 5168 =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale= xander Steeg

=C2=A0<= /p>

2014-06-11 20:38 GMT+02:00 Leif Johansson <leifj@mnt.se>:=

On 2014-06-02 22:03, = Phil Hunt wrote:
> Here is some proposed new text. =C2=A0I=E2=80=99ve tried to tweak the = text a bit to
> help solve Ticket 76 regarding what to do about missing or omitted
> attributes.
>

I want to encourage/urge everyone to think about and= review this
proposal. It is very likely the last big issue left to us!


> After some analysis, I think this is closest in logic to how people ar= e
> using PUT now. =C2=A0Because PUT is mandatory, I believe we need to be= very
> precise.
>
> I have also added text stating that PUT should not be used to create n= ew
> resources. Is the word =E2=80=9CSHOULD=E2=80=9D appropriate? =C2=A0The= real problem with
> using PUT for resource creation is the client gets to create their own=
> identifier.
>
>> 3.3.1. =C2=A0Modifying with PUT
>>
>> =C2=A0 =C2=A0HTTP PUT is used to perform a full update of a resour= ce's attributes.
>> =C2=A0 =C2=A0Clients having previously retrieved the entire resour= ce in advance,
>> =C2=A0 =C2=A0update the desired attributes and use HTTP PUT to rep= lace previously
>> =C2=A0 =C2=A0stored attributes. =C2=A0HTTP PUT SHOULD NOT be used = to create a new
>> =C2=A0 =C2=A0resource.
>>
>> =C2=A0 =C2=A0As the operation intent is to replace attributes, SCI= M clients MAY
>> =C2=A0 =C2=A0send all attributes regardless of each attribute'= s mutability. =C2=A0The
>> =C2=A0 =C2=A0server will apply attribute by attribute replace acco= rding to the
>> =C2=A0 =C2=A0following attribute mutability rules:
>>
>> =C2=A0 =C2=A0readWrite, writeOnly =C2=A0Any values provided SHALL = replace the existing
>> =C2=A0 =C2=A0 =C2=A0 attribute values.
>>
>> =C2=A0 =C2=A0immutable =C2=A0If values are already set in the attr= ibute they MUST match
>> =C2=A0 =C2=A0 =C2=A0 existing data or an error is returned. =C2=A0= If the service provider
>> =C2=A0 =C2=A0 =C2=A0 has no existing values, the new value(s) SHAL= L be applied.
>>
>> =C2=A0 =C2=A0readOnly =C2=A0Any values provided (e.g. =C2=A0meta.r= esourceType) SHALL be
>> =C2=A0 =C2=A0 =C2=A0 ignored.
>>
>> =C2=A0 =C2=A0If an attribute is "required", clients MUST= specify the attribute in
>> =C2=A0 =C2=A0the PUT request.
>>
>> =C2=A0 =C2=A0Clients MAY specify "null" or empty set &qu= ot;[]" to clear an existing
>> =C2=A0 =C2=A0value or clear a multi-valued array.
>>
>> =C2=A0 =C2=A0Since a client may not have access to, or may not be = aware of, the
>> =C2=A0 =C2=A0full schema for a resource, omitted or unspecified va= lues SHOULD be
>> =C2=A0 =C2=A0ignored.
>>
>> =C2=A0 =C2=A0If a value provided for an immutable attribute with a= n existing value
>> =C2=A0 =C2=A0is NOT matched, the server SHALL respond with an HTTP= response code
>> =C2=A0 =C2=A0of 400 and an appropriate human readable message indi= cating an
>> =C2=A0 =C2=A0attempt to change an immutable attribute. =C2=A0[[Edi= tor: An appropriate
>> =C2=A0 =C2=A0error code should be indicated e.g. 'mutability&#= 39;]]
>>
>> =C2=A0 =C2=A0Unless otherwise specified a successful PUT operation= returns a 200
>> =C2=A0 =C2=A0OK response code and the entire resource within the r= esponse body,
>> =C2=A0 =C2=A0enabling the client to correlate the client's and= Provider's views of
>> =C2=A0 =C2=A0the updated resource. =C2=A0Example:
>>
>
>
> Phil
>
> @independentid

> www.independentid.com <http://www.independentid.com>
> phil.hunt@or= acle.com <mailto:phil.hunt@oracle.com>
>
>
>
>
>
> _______________________________________________
> 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

=C2=A0

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

=C2=A0

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

=C2=A0


--089e0111be12a840f204fc7c79be-- From nobody Mon Jun 23 12:06:21 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C615A1B2C8C for ; Mon, 23 Jun 2014 12:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOwsvKunQRs3 for ; Mon, 23 Jun 2014 12:06:17 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451301B2C46 for ; Mon, 23 Jun 2014 12:02:47 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s5NJ2iJR003809 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Jun 2014 21:02:44 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s5NJ2gQP019652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Jun 2014 21:02:44 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.115] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128 bits)) for scim@ietf.org; Mon, 23 Jun 2014 21:02:41 +0200 Message-ID: <53A879D1.9010105@sunet.se> Date: Mon, 23 Jun 2014 21:02:41 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "scim@ietf.org" References: <20140623183124.30660.37065.idtracker@ietfa.amsl.com> In-Reply-To: <20140623183124.30660.37065.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20140623183124.30660.37065.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, 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: 09MhT2IbL - cfa0d374fea3 - 20140623 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/scim/13Gv2LdZVOSj7XXjeDMxtREqwe0 Subject: [scim] Fwd: scim - Requested session has been scheduled for IETF 90 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:06:19 -0000 How does this work for folks? -------- Original Message -------- Subject: scim - Requested session has been scheduled for IETF 90 Date: Mon, 23 Jun 2014 11:31:24 -0700 From: "IETF Secretariat" To: leifj@sunet.se CC: scim-ads@tools.ietf.org, moransar@cisco.com, leifj@sunet.se Dear Leif Johansson, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. scim Session 1 (2:00:00) Wednesday, Afternoon Session I 1300-1500 Room Name: Salon A size: 75 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: System for Cross-domain Identity Management Area Name: Applications Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: abfab apparea appsawg oauth tls jose uta Second Priority: kitten xmpp Special Requests: avoid security & identity related bofs We'd like a session late in the week but not on Friday please (pretty please!) --------------------------------------------------------- From nobody Mon Jun 23 13:53:35 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1828B1B2B9A for ; Mon, 23 Jun 2014 13:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgAaF1FtUwca for ; Mon, 23 Jun 2014 13:53:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D37411A02B2 for ; Mon, 23 Jun 2014 13:53:31 -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.949.11; Mon, 23 Jun 2014 20:53:24 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.126]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.126]) with mapi id 15.00.0954.000; Mon, 23 Jun 2014 20:53:24 +0000 From: Kelly Grizzle To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] Fwd: scim - Requested session has been scheduled for IETF 90 Thread-Index: AQHPjxZFPfttrjbN30eqR2pY2AF6ypt/LCKQ Date: Mon, 23 Jun 2014 20:53:23 +0000 Message-ID: <6286d4d335644e6391901941044d1df3@BN1PR04MB392.namprd04.prod.outlook.com> References: <20140623183124.30660.37065.idtracker@ietfa.amsl.com> <53A879D1.9010105@sunet.se> In-Reply-To: <53A879D1.9010105@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: C56D3F9C007776C56D40E9 x-originating-ip: [97.79.140.10] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 025100C802 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(2473001)(13464003)(377454003)(189002)(199002)(81542001)(87936001)(74662001)(46102001)(76482001)(81342001)(77982001)(99396002)(21056001)(4396001)(85852003)(83072002)(76176999)(74502001)(33646001)(54356999)(50986999)(76576001)(15975445006)(2656002)(101416001)(74316001)(86362001)(83322001)(19580405001)(19580395003)(92566001)(64706001)(105586002)(77096002)(106356001)(66066001)(79102001)(20776003)(31966008)(85306003)(95666004)(99286002)(80022001)(106116001)(24736002)(106276001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: sailpoint.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kelly.grizzle@sailpoint.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/83l1K8YrblLLVkLqDr4irpA4jOs Subject: Re: [scim] Fwd: scim - Requested session has been scheduled for IETF 90 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 20:53:34 -0000 Works for me. -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson Sent: Monday, June 23, 2014 2:03 PM To: scim@ietf.org Subject: [scim] Fwd: scim - Requested session has been scheduled for IETF 9= 0 How does this work for folks? -------- Original Message -------- Subject: scim - Requested session has been scheduled for IETF 90 Date: Mon, 23 Jun 2014 11:31:24 -0700 From: "IETF Secretariat" To: leifj@sunet.se CC: scim-ads@tools.ietf.org, moransar@cisco.com, leifj@sunet.se Dear Leif Johansson, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request= . scim Session 1 (2:00:00) Wednesday, Afternoon Session I 1300-1500 Room Name: Salon A size: 75 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: System for Cross-domain Identity Management Area Name: = Applications Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: abfab apparea appsawg oauth tls jose uta Second Priority:= kitten xmpp Special Requests: avoid security & identity related bofs We'd like a session late i= n the week but not on Friday please (pretty please!) --------------------------------------------------------- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From nobody Mon Jun 23 13:59:28 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F267A1B2B9A for ; Mon, 23 Jun 2014 13:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cy8n1OjbvOaW for ; Mon, 23 Jun 2014 13:59:24 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936C71A0350 for ; Mon, 23 Jun 2014 13:59:24 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5NKxNwr016418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jun 2014 20:59:23 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5NKxM5D016672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Jun 2014 20:59:23 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5NKxMoZ001257; Mon, 23 Jun 2014 20:59:22 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jun 2014 13:59:21 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: <6286d4d335644e6391901941044d1df3@BN1PR04MB392.namprd04.prod.outlook.com> Date: Mon, 23 Jun 2014 13:59:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140623183124.30660.37065.idtracker@ietfa.amsl.com> <53A879D1.9010105@sunet.se> <6286d4d335644e6391901941044d1df3@BN1PR04MB392.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/KSeInCErn19EIxKp_YVc6sp90o4 Cc: "scim@ietf.org" , Leif Johansson Subject: Re: [scim] Fwd: scim - Requested session has been scheduled for IETF 90 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 20:59:27 -0000 +1 Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 23, 2014, at 1:53 PM, Kelly Grizzle = wrote: > Works for me. >=20 > -----Original Message----- > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson > Sent: Monday, June 23, 2014 2:03 PM > To: scim@ietf.org > Subject: [scim] Fwd: scim - Requested session has been scheduled for = IETF 90 >=20 >=20 > How does this work for folks? >=20 >=20 >=20 > -------- Original Message -------- > Subject: scim - Requested session has been scheduled for IETF 90 > Date: Mon, 23 Jun 2014 11:31:24 -0700 > From: "IETF Secretariat" > To: leifj@sunet.se > CC: scim-ads@tools.ietf.org, moransar@cisco.com, leifj@sunet.se >=20 > Dear Leif Johansson, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by the original = request. >=20 > scim Session 1 (2:00:00) > Wednesday, Afternoon Session I 1300-1500 > Room Name: Salon A size: 75 > --------------------------------------------- >=20 >=20 >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name: System for Cross-domain Identity Management Area = Name: Applications Area Session Requester: Leif Johansson >=20 > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 40 > Conflicts to Avoid: > First Priority: abfab apparea appsawg oauth tls jose uta Second = Priority: kitten xmpp >=20 >=20 >=20 > Special Requests: > avoid security & identity related bofs We'd like a session = late in the week but not on Friday please (pretty please!) > --------------------------------------------------------- >=20 >=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 From nobody Mon Jun 23 14:03:03 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC65F1B2C37; Mon, 23 Jun 2014 14:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYL6tpSsYelY; Mon, 23 Jun 2014 14:03:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 338611B2BDA; Mon, 23 Jun 2014 14:03:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623210300.13588.92419.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 14:03:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/NmzG9oWqpXyiCj08BMIb7kutgcg Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-06.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 21:03:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Core Schema Authors : Kelly Grizzle Phil Hunt Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-core-schema-06.txt Pages : 63 Date : 2014-06-23 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move identity in to, out of, and around the cloud. This document provides a platform neutral schema and extension model for representing users and groups in JSON format. This schema is intended for exchange and use with cloud service providers. An HTTP protocol binding document is also provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-core-schema-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 23 14:21:23 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44011B2BD4 for ; Mon, 23 Jun 2014 14:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLJ3AOB6wo5U for ; Mon, 23 Jun 2014 14:21:18 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EC21B2BB2 for ; Mon, 23 Jun 2014 14:21:18 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5NLLGOJ012649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Jun 2014 21:21:17 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 s5NLLGh7023918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Jun 2014 21:21:16 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5NLLGWD023914 for ; Mon, 23 Jun 2014 21:21:16 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jun 2014 14:21:16 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: <20140623210300.13588.92419.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 14:21:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140623210300.13588.92419.idtracker@ietfa.amsl.com> To: Scim WG X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/X3KJlGaMvtwklQl1DTjakdLBblQ Subject: Re: [scim] I-D Action: draft-ietf-scim-core-schema-06.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 21:21:20 -0000 This draft includes the following changes: * support proper IANA namespace registration. * updated references to new HTTP/1.1 RFCs (7230-7235) * remove =93meta.attributes=94 as no longer required by API document * re-ordered introduction text to be more consistent with API and other = IETF drafts. I will post a parallel update to the SCIM API document shortly. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 23, 2014, at 2:03 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the System for Cross-domain Identity = Management Working Group of the IETF. >=20 > Title : System for Cross-Domain Identity Management: = Core Schema > Authors : Kelly Grizzle > Phil Hunt > Erik Wahlstroem > Chuck Mortimore > Filename : draft-ietf-scim-core-schema-06.txt > Pages : 63 > Date : 2014-06-23 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) specification > is designed to make managing user identity in cloud based > applications and services easier. The specification suite builds > upon experience with existing schemas and deployments, placing > specific emphasis on simplicity of development and integration, = while > applying existing authentication, authorization, and privacy models. > Its intent is to reduce the cost and complexity of user management > operations by providing a common user schema and extension model, as > well as binding documents to provide patterns for exchanging this > schema using standard protocols. In essence, make it fast, cheap, > and easy to move identity in to, out of, and around the cloud. >=20 > This document provides a platform neutral schema and extension model > for representing users and groups in JSON format. This schema is > intended for exchange and use with cloud service providers. An HTTP > protocol binding document is also provided. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-scim-core-schema-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-core-schema-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon Jun 23 14:39:05 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F0D1B2C45; Mon, 23 Jun 2014 14:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-RwLDyYnbDb; Mon, 23 Jun 2014 14:38:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D841B2CFC; Mon, 23 Jun 2014 14:38:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623213857.20613.72952.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 14:38:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/x8yocQ221O8zV1G9oXcvavUh-Y0 Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-06.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 21:39:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management:Protocol Authors : Phil Hunt Kelly Grizzle Morteza Ansari Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-api-06.txt Pages : 67 Date : 2014-06-23 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. It's intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-api-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 23 14:46:41 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564891B2D09 for ; Mon, 23 Jun 2014 14:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_4-wBCDc6SB for ; Mon, 23 Jun 2014 14:46:34 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53AF1B2D02 for ; Mon, 23 Jun 2014 14:46:34 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5NLkWKJ021616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Jun 2014 21:46:34 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 s5NLkVWY019978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 23 Jun 2014 21:46:31 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5NLkUv8002781 for ; Mon, 23 Jun 2014 21:46:31 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jun 2014 14:46:30 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: <20140623213857.20613.72952.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 14:46:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <73F703BD-9C67-461F-B0C2-86D07BA3EB4B@oracle.com> References: <20140623213857.20613.72952.idtracker@ietfa.amsl.com> To: Scim WG X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/94m3mzu2-gGM4wcFn5m5VSxKO5I Subject: Re: [scim] I-D Action: draft-ietf-scim-api-06.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 21:46:37 -0000 A new revision of the API draft is now online. Please note, that in order to register the schema namespace, I had to = make changes to the namespace for JSON message schema values. There was also some clarification text (previously shared) added to the = PUT command. POST was also adjusted for consistency with PUT in that it = now ignores read-only attributes. If this is not desired, please = discuss on the list. For the next major draft update, I plan to review and complete error = reporting. =20 Please note, there are only a couple of weeks left before submission = closes for the IETF 90 meeting. Changes in this draft include: 41 - Revised content types from application/json to application/ scim+json, registered API schemas, json messages have new schema = namespace 63 - Revised uri schema prefixes for API json message schemas 66 - Updated references for RFC2616 to HTTPbis 75 - Added security considerations for International Strings and "PRECIS" support 76 - Clarified handling of PUT (& POST) with regards to mutability and default values - Corrected version numbers in sec 3.11 API Versioning to v2 (from v1) - Clarified that no filter matches should return success totalResults=3D0 Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 23, 2014, at 2:38 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the System for Cross-domain Identity = Management Working Group of the IETF. >=20 > Title : System for Cross-Domain Identity = Management:Protocol > Authors : Phil Hunt > Kelly Grizzle > Morteza Ansari > Erik Wahlstroem > Chuck Mortimore > Filename : draft-ietf-scim-api-06.txt > Pages : 67 > Date : 2014-06-23 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) specification > is designed to make managing user identity in cloud based > applications and services easier. The specification suite seeks to > build upon experience with existing schemas and deployments, placing > specific emphasis on simplicity of development and integration, = while > applying existing authentication, authorization, and privacy models. > It's intent is to reduce the cost and complexity of user management > operations by providing a common user schema and extension model, as > well as binding documents to provide patterns for exchanging this > schema using standard protocols. In essence, make it fast, cheap, > and easy to move users in to, out of, and around the cloud. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-scim-api-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-api-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue Jun 24 12:02:02 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F561B2ECA for ; Tue, 24 Jun 2014 12:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIGjQ25eS2zV for ; Tue, 24 Jun 2014 12:01:59 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897DB1B2EA6 for ; Tue, 24 Jun 2014 12:01:45 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5OJ1ipW006207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Jun 2014 19:01:45 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5OJ1hRL022064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Jun 2014 19:01:43 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5OJ1hNS006578 for ; Tue, 24 Jun 2014 19:01:43 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Jun 2014 12:01:42 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_2DBAA5D7-9B1A-4378-8E1A-F57BA5F185E5" Message-Id: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> Date: Tue, 24 Jun 2014 12:01:42 -0700 To: Scim WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/-85iezSQ3EXbFu1sHRruTCBeB0E Subject: [scim] Detailed error and status codes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:02:01 -0000 --Apple-Mail=_2DBAA5D7-9B1A-4378-8E1A-F57BA5F185E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 With regards to tickets 37, 46, 67, it looks like we will have some = normative changes required. I am also expecting new SCIM error codes as = we look at the possible reasons a server might return Bad Request or = other HTTP status codes. Currently, the example response from PATCH, we use =93error=94 to = indicate a detailed error.=20 "error":"mutability" =46rom Response Codes Section, no detail error is defined: HTTP/1.1 404 NOT FOUND { "schemas": ["urn:scim:api:messages:2.0:Error"], "Errors":[ { "description":"Resource 2819c223-7f76-453a-919d-413861904646 not = found", "code":"404" } ] } Doing a search around Twitter, AWS, and many others, I see that =93code=94= is often used to indicate a detailed error message (=93mutability=94) = and status is used to indicate HTTP status. =20 In an attempt to bring consistency across the API document, I am = proposing we use http_status and scim_code. This will help make clear = what we are referring to and allow existing implementations to co-exist = for a while (by having different names). Are there any objections to normalizing the spec around following format = and attributes? Proposed example: HTTP/1.1 400 Bad Request Content-Type: application/scim+json;charset=3DUTF-8 Cache-Control: no-store Pragma: no-cache { "schemas": ["urn:scim:api:messages:2.0:Error"], "Errors":[ { =93scim_code":"mutability=94, =93http_status=94:400, "error_description":"Attribute 'id' is readOnly." }, . . . ] } Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_2DBAA5D7-9B1A-4378-8E1A-F57BA5F185E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
With regards to tickets 37, 46, 67, it looks = like we will have some normative changes required.  I am also = expecting new SCIM error codes as we look at the possible reasons a = server might return Bad Request or other HTTP status = codes.

Currently, the example response from = PATCH, we use =93error=94 to indicate a detailed = error. 

=  "error":"mutability"

=46rom Response = Codes Section, no detail error is defined:
HTTP/1.1 404 NOT FOUND

{
  "schemas": ["urn:scim:api:messages:2.0:Error"],
  "Errors":[
    {
      "description":"Resource 2819c223-7f76-453a-919d-413861904646 =
not found",
      "code":"404"
    }
  ]
}

Doing a search around Twitter, AWS, and many = others, I see that =93code=94 is often used to indicate a detailed error = message (=93mutability=94) and status is used to indicate HTTP status. =  

In an attempt to bring consistency = across the API document, I am proposing we use http_status and = scim_code. This will help make clear what we are referring to and allow = existing implementations to co-exist for a while (by having different = names).

Are there any objections to = normalizing the spec around following format and = attributes?

Proposed = example:

HTTP/1.1 400 Bad Request
   Content-Type: =
application/scim+json;charset=3DUTF-8
   Cache-Control: no-store
   Pragma: no-cache

   {
     "schemas": ["urn:scim:api:messages:2.0:Error"],
     "Errors":[
       {
         =93scim_code":"mutability=94,
         =93http_status=94:400,
         "error_description":"Attribute 'id' is readOnly."
       },
        =
. . .
     ]
   }

= --Apple-Mail=_2DBAA5D7-9B1A-4378-8E1A-F57BA5F185E5-- From nobody Tue Jun 24 12:23:40 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB2B1B2C92 for ; Tue, 24 Jun 2014 12:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC81yWJKXag5 for ; Tue, 24 Jun 2014 12:23:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8CD1B28C7 for ; Tue, 24 Jun 2014 12:23:36 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MYfJW-1XDDhX1w2M-00VTts; Tue, 24 Jun 2014 21:23:34 +0200 Message-ID: <53A9D021.2060906@gmx.de> Date: Tue, 24 Jun 2014 21:23:13 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Phil Hunt , Scim WG References: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> In-Reply-To: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Z70gnm3/rHu5dpBEWf3pub54ZPT8PMTHy9k6srSQsnFovMEmTPG ZOWh2UgLDZdBCcYLvHCLtRosiuSu4TgizwsR3A1JtAeEALGY9VOqPf2Ntxurr0mR7LvJKwK mxCsW0VIItLRsqYyLiL/1n4YQFvHjGvN2Xka8Esdb7oZrRxPOU/kqZgRcsaDMyPrmEku7P/ Uv9FV0Whvhtm15V4EvimQ== Archived-At: http://mailarchive.ietf.org/arch/msg/scim/2k1UfOmSCbpp8PbR9qkRy0QgFDQ Subject: Re: [scim] Detailed error and status codes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:23:38 -0000 On 2014-06-24 21:01, Phil Hunt wrote: > With regards to tickets 37, 46, 67, it looks like we will have some > normative changes required. I am also expecting new SCIM error codes as > we look at the possible reasons a server might return Bad Request or > other HTTP status codes. > > Currently, the example response from PATCH, we use “error” to indicate a > detailed error. > > * "error":"mutability"* > > From Response Codes Section, no detail error is defined: > > *HTTP/1.1 404 NOT FOUND* > > { > "schemas": ["urn:scim:api:messages:2.0:Error"], > "Errors":[ > { > *"description":"Resource 2819c223-7f76-453a-919d-413861904646 not found", > "code":"404"* > } > ] > } > > > Doing a search around Twitter, AWS, and many others, I see that “code” > is often used to indicate a detailed error message (“mutability”) and > status is used to indicate HTTP status. > > In an attempt to bring consistency across the API document, I am > proposing we use http_status and scim_code. This will help make clear > what we are referring to and allow existing implementations to co-exist > for a while (by having different names). > > _Are there any objections to normalizing the spec around following > format and attributes?_ > > Proposed example: > > *HTTP/1.1 400 Bad Request* > > Content-Type: application/scim+json;charset=UTF-8 > Cache-Control: no-store > Pragma: no-cache > > { > "schemas": ["urn:scim:api:messages:2.0:Error"], > "Errors":[ > { > *“scim_code":"mutability”,* > > * “http_status”:400,* > "error_description":"Attribute 'id' is readOnly." > }, > > . . . > > ] > > } > ... You may want to read ... Best regards, Julian From nobody Tue Jun 24 12:25:27 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383C31B2EF2 for ; Tue, 24 Jun 2014 12:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAFkBSW5ylF7 for ; Tue, 24 Jun 2014 12:25:22 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C968C1B2BD2 for ; Tue, 24 Jun 2014 12:25:21 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 24 Jun 2014 21:25:01 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0847.030; Tue, 24 Jun 2014 21:25:01 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] Detailed error and status codes Thread-Index: AQHPj97TKGZvm+Je4UahBj7VC9gPVpuAgrYA Date: Tue, 24 Jun 2014 19:25:00 +0000 Message-ID: <7DD1CA44-33C4-4BEB-9BFA-12FA5B57AB49@nexusgroup.com> References: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> In-Reply-To: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.90] Content-Type: multipart/alternative; boundary="_000_7DD1CA4433C44BEB9BFA12FA5B57AB49nexusgroupcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/xQ7EjqgHGY0lZbPEElrMf0b4Quo Cc: Scim WG Subject: Re: [scim] Detailed error and status codes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:25:25 -0000 --_000_7DD1CA4433C44BEB9BFA12FA5B57AB49nexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Phil, Prefer camel case though, not personally, but just to keep it according to = rest of spec :) Hence scimCode, httpStatus, errorDescription instead. I=92m still not fully on board of having multiple error codes in one respon= se. I think it was mostly a typo in 1.0 specs to be frank :) All scim imple= mentations I=92ve seen just display one error code at the time. By the way, I liked the fact that you made http status an int instead of st= ring. / Erik On 24 Jun 2014, at 21:01, Phil Hunt > wrote: With regards to tickets 37, 46, 67, it looks like we will have some normati= ve changes required. I am also expecting new SCIM error codes as we look a= t the possible reasons a server might return Bad Request or other HTTP stat= us codes. Currently, the example response from PATCH, we use =93error=94 to indicate = a detailed error. "error":"mutability" >From Response Codes Section, no detail error is defined: HTTP/1.1 404 NOT FOUND { "schemas": ["urn:scim:api:messages:2.0:Error"], "Errors":[ { "description":"Resource 2819c223-7f76-453a-919d-413861904646 not foun= d", "code":"404" } ] } Doing a search around Twitter, AWS, and many others, I see that =93code=94 = is often used to indicate a detailed error message (=93mutability=94) and s= tatus is used to indicate HTTP status. In an attempt to bring consistency across the API document, I am proposing = we use http_status and scim_code. This will help make clear what we are ref= erring to and allow existing implementations to co-exist for a while (by ha= ving different names). Are there any objections to normalizing the spec around following format an= d attributes? Proposed example: HTTP/1.1 400 Bad Request Content-Type: application/scim+json;charset=3DUTF-8 Cache-Control: no-store Pragma: no-cache { "schemas": ["urn:scim:api:messages:2.0:Error"], "Errors":[ { =93scim_code":"mutability=94, =93http_status=94:400, "error_description":"Attribute 'id' is readOnly." }, . . . ] } Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_7DD1CA4433C44BEB9BFA12FA5B57AB49nexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <292540AB269EC249BD5D2E9E62BF1E59@nexusgroup.com> Content-Transfer-Encoding: quoted-printable Hi Phil,

Prefer camel case though, not personally, but just to keep it accordin= g to rest of spec :) Hence scimCode, httpStatus, errorDescription instead.<= /div>

I=92m still not fully on board of having multiple error codes in one r= esponse. I think it was mostly a typo in 1.0 specs to be frank :) All scim = implementations I=92ve seen just display one error code at the time.

By the way, I liked the fact that you made http status an int instead = of string.

/ Erik


On 24 Jun 2014, at 21:01, Phil Hunt <phil.hunt@oracle.com> wrote:

With regards to tickets 37, 46, 67, it looks like we will have some no= rmative changes required.  I am also expecting new SCIM error codes as= we look at the possible reasons a server might return Bad Request or other= HTTP status codes.

Currently, the example response from PATCH, we use =93error=94 to indi= cate a detailed error. 

&n= bsp;"error":"mutability"

>From Response Codes Section, no detail error is defined: 
HTTP/1.1 404 NOT FOUND

{
  "schemas": ["urn:scim:api:messages:2.0:Error"],
  "Errors":[
    {
      "description":"Resource 2819c223-7f76-453a-919d-413=
861904646 not found",
      "code":"404"
    }
  ]
}

Doing a search around Twitter, AWS, and many others, I see that =93cod= e=94 is often used to indicate a detailed error message (=93mutability=94) = and status is used to indicate HTTP status.  

In an attempt to bring consistency across the API document, I am propo= sing we use http_status and scim_code. This will help make clear what we ar= e referring to and allow existing implementations to co-exist for a while (= by having different names).

Are there any objections to normalizing the spec around following f= ormat and attributes?

Proposed example:

HTTP/1.1 400 Bad Request= 
   Content-Type: application/scim+=
;json;charset=3DUTF-8
   Cache-Control: no-store
   Pragma: no-cache

   {
     "schemas": ["urn:scim:api:messages:2.0:Error"],
     "Errors":[
       {
         =93scim_code":"mutability=94,
         =93http_status=94:400,
         "error_description":"Attribute 'id' is readOnly.&qu=
ot;
       },
        . . .
     ]
   }

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

--_000_7DD1CA4433C44BEB9BFA12FA5B57AB49nexusgroupcom_-- From nobody Tue Jun 24 16:30:42 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599C81B29B9 for ; Tue, 24 Jun 2014 16:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.651 X-Spam-Level: X-Spam-Status: No, score=-3.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLcJZu8sMPyl for ; Tue, 24 Jun 2014 16:30:37 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96ABA1B29B6 for ; Tue, 24 Jun 2014 16:30:37 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5ONUXtf031267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jun 2014 23:30:34 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 s5ONUWnd010811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2014 23:30:33 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5ONUWU3010795; Tue, 24 Jun 2014 23:30:32 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Jun 2014 16:30:32 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_7BB12BEF-2C41-4D0A-B96C-456BE36F0FCB" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: <53A9D021.2060906@gmx.de> Date: Tue, 24 Jun 2014 16:30:31 -0700 Message-Id: <71B45AEC-9B79-4F3F-A933-23B0C2AF868E@oracle.com> References: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> <53A9D021.2060906@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/jBLKz9I6XG8Aw50oxd_ZNVGV97U Cc: Scim WG Subject: [scim] [INPUT REQUESTED] Re: Detailed error and status codes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 23:30:40 -0000 --Apple-Mail=_7BB12BEF-2C41-4D0A-B96C-456BE36F0FCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Note: July 04 is the LAST day for us to potentially submit updates for = the IETF90 meeting. This gives us about 1.5 weeks to close off the = error issues and update the drafts. If you have a moment please take a = look and comment as soon as possible... Julian thanks for the suggestion. For the rest of the group=92s = benefit, the draft Julian referenced suggests the following attributes = be returned in a standardized detailed error JSON body=85 > A problem details object MAY have the following members: >=20 > o "type" (string) - An absolute URI [RFC3986] that identifies the > problem type. When dereferenced, it SHOULD provide = human-readable > documentation for the problem type (e.g., using HTML > [W3C.REC-html401-19991224]). When this member is not present, = its > value is assumed to be "about:blank". > o "title" (string) - A short, human-readable summary of the = problem > type. It SHOULD NOT change from occurrence to occurrence of the > problem, except for purposes of localisation. > o "status" (number) - The HTTP status code ([RFC2616], Section 6) > generated by the origin server for this occurrence of the = problem. > o "detail" (string) - An human readable explanation specific to = this > occurrence of the problem. > o "instance" (string) - An absolute URI that identifies the = specific > occurrence of the problem. It may or may not yield further > information if dereferenced. Here is the corresponding example error response: > HTTP/1.1 403 Forbidden > Content-Type: application/problem+json > Content-Language: en >=20 > { > "type": "http://example.com/probs/out-of-credit", > "title": "You do not have enough credit.", > "detail": "Your current balance is 30, but that costs 50.", > "instance": "http://example.net/account/12345/msgs/abc", > "balance": 30, > "accounts": ["http://example.net/account/12345", > "http://example.net/account/67890"] > } Julian, what is the value of having =93type=94 be a URI? Why not just = have a SCIM specific attribute (scimType) and use simple keywords? = (asking mainly for the WG=92s benefit). I guess the strong case is that = by standardizing HTTP responses, client code gets simplified. However, = using standard attributes creates the namespace conflict issue. So we = need URI based error codes. The SCIM specs could adopt the =93type=94, =93detail=94, and =93status=94.= We would register a namespace of urn:scim:error:apil:2.0 in the SCIM = IANA section in addition to api:messages, schema:core, etc. This would = give detail error types of: urn:scim:error:api:2.0:mutability, urnscim:error:api:2.0:filter, etc. The other items, like title, instance, etc could be optional or just = omitted from SCIM spec. =97> we would just indicate that clients should = expect attributes within the JSON message other than those defined by = the SCIM drafts. IMPORTANT NOTE: the format suggested by Julian allows for only one = error at a time. Erik had commented he prefers to return only one. I = tend to agree. In the case of BULK requests, this is not really an issue = since each BULK operation gets its own response block. In the interests of time, any objections to using type (with URI based = error codes), detail, status, per above and limiting to ONE per = response?=20 I know these are normative changes=85.however I=92m pretty sure we can=92t= avoid changes in the final document clean up whether or not we adopt = the proposed standardized error response. Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 24, 2014, at 12:23 PM, Julian Reschke = wrote: > On 2014-06-24 21:01, Phil Hunt wrote: >> With regards to tickets 37, 46, 67, it looks like we will have some >> normative changes required. I am also expecting new SCIM error codes = as >> we look at the possible reasons a server might return Bad Request or >> other HTTP status codes. >>=20 >> Currently, the example response from PATCH, we use =93error=94 to = indicate a >> detailed error. >>=20 >> * "error":"mutability"* >>=20 >> =46rom Response Codes Section, no detail error is defined: >>=20 >> *HTTP/1.1 404 NOT FOUND* >>=20 >> { >> "schemas": ["urn:scim:api:messages:2.0:Error"], >> "Errors":[ >> { >> *"description":"Resource 2819c223-7f76-453a-919d-413861904646 = not found", >> "code":"404"* >> } >> ] >> } >>=20 >>=20 >> Doing a search around Twitter, AWS, and many others, I see that = =93code=94 >> is often used to indicate a detailed error message (=93mutability=94) = and >> status is used to indicate HTTP status. >>=20 >> In an attempt to bring consistency across the API document, I am >> proposing we use http_status and scim_code. This will help make clear >> what we are referring to and allow existing implementations to = co-exist >> for a while (by having different names). >>=20 >> _Are there any objections to normalizing the spec around following >> format and attributes?_ >>=20 >> Proposed example: >>=20 >> *HTTP/1.1 400 Bad Request* >>=20 >> Content-Type: application/scim+json;charset=3DUTF-8 >> Cache-Control: no-store >> Pragma: no-cache >>=20 >> { >> "schemas": ["urn:scim:api:messages:2.0:Error"], >> "Errors":[ >> { >> *=93scim_code":"mutability=94,* >>=20 >> * =93http_status=94:400,* >> "error_description":"Attribute 'id' is readOnly." >> }, >>=20 >> . . . >>=20 >> ] >>=20 >> } >> ... >=20 > You may want to read = ... >=20 > Best regards, Julian >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_7BB12BEF-2C41-4D0A-B96C-456BE36F0FCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Note: July 04 is the = LAST day for us to potentially submit updates for the IETF90 meeting. =  This gives us about 1.5 weeks to close off the error issues and = update the drafts.  If you have a moment please take a look and = comment as soon as possible...

Julian = thanks for the suggestion.  For the rest of the group=92s benefit, = the draft Julian referenced suggests the following attributes be = returned in a standardized detailed error JSON = body=85

   A problem details =
object MAY have the following members:

   o  "type" (string) - An absolute URI [RFC3986] that =
identifies the
      problem type.  When dereferenced, it SHOULD provide human-readable
      documentation for the problem type (e.g., using HTML
      [W3C.REC-html401-19991224]).  When this =
member is not present, its
      value is assumed to be "about:blank".
   o  "title" (string) - A short, human-readable summary of the problem
      type.  It SHOULD NOT change from occurrence to occurrence of the
      problem, except for purposes of localisation.
   o  "status" (number) - The HTTP status code ([RFC2616], =
Section 6)
      generated by the origin server for this occurrence of the problem.
   o  "detail" (string) - An human readable explanation specific to this
      occurrence of the problem.
   o  "instance" (string) - An absolute URI that identifies the specific
      occurrence of the problem.  It may or may not yield further
      information if dereferenced.

Here is the corresponding example = error response:
   HTTP/1.1 403 Forbidden
   Content-Type: application/problem+json
   Content-Language: en

   {
    "type": "http://example.com/probs/o=
ut-of-credit",
    "title": "You do not have enough credit.",
    "detail": "Your current balance is 30, but that costs 50.",
    "instance": "http://example.net/acco=
unt/12345/msgs/abc",
    "balance": 30,
    "accounts": ["http://example.net/account/12345=
",
                 "http://example.net/account/67890=
"]
   }

Julian, what is the value of having =93type=94= be a URI?  Why not just have a SCIM specific attribute (scimType) = and use simple keywords? (asking mainly for the WG=92s benefit). I guess = the strong case is that by standardizing HTTP responses, client code = gets simplified. However, using standard attributes creates the = namespace conflict issue.  So we need URI based error = codes.

The SCIM specs could adopt the =93type=94,= =93detail=94, and =93status=94. We would register a namespace of = urn:scim:error:apil:2.0 in the SCIM IANA section in addition to = api:messages, schema:core, etc.  This would give detail error types = of:
  urn:scim:error:api:2.0:mutability, = urnscim:error:api:2.0:filter, etc.

The other = items, like title, instance, etc could be optional or just omitted from = SCIM spec. =97> we would just indicate that clients should expect = attributes within the JSON message other than those defined by the SCIM = drafts.

IMPORTANT NOTE:  the format = suggested by Julian allows for only one error at a time.  Erik had = commented he prefers to return only one. I tend to agree. In the case of = BULK requests, this is not really an issue since each BULK operation = gets its own response block.

In the interests = of time, any objections to using type (with URI based error codes), = detail, status, per above and limiting to ONE per response? =  

I know these are normative = changes=85.however I=92m pretty sure we can=92t avoid changes in the = final document clean up whether or not we adopt the proposed = standardized error = response.

Cheers,

P= hil

@independentid
www.independentid.com
phil.hu= nt@oracle.com



On Jun 24, 2014, at 12:23 PM, Julian = Reschke <julian.reschke@gmx.de> = wrote:

On 2014-06-24 21:01, Phil Hunt = wrote:
With regards to tickets 37, 46, 67, = it looks like we will have some
normative changes required.  I = am also expecting new SCIM error codes as
we look at the possible = reasons a server might return Bad Request or
other HTTP status = codes.

Currently, the example response from PATCH, we use =93error=94= to indicate a
detailed error.

* = "error":"mutability"*

=46rom Response Codes Section, no detail = error is defined:

*HTTP/1.1 404 NOT FOUND*

{
  = "schemas": ["urn:scim:api:messages:2.0:Error"],
  = "Errors":[
    {
      = *"description":"Resource 2819c223-7f76-453a-919d-413861904646 not = found",
      "code":"404"*
    = }
  ]
}


Doing a search around Twitter, AWS, and = many others, I see that =93code=94
is often used to indicate a = detailed error message (=93mutability=94) and
status is used to = indicate HTTP status.

In an attempt to bring consistency across = the API document, I am
proposing we use http_status and scim_code. = This will help make clear
what we are referring to and allow existing = implementations to co-exist
for a while (by having different = names).

_Are there any objections to normalizing the spec around = following
format and attributes?_

Proposed = example:

*HTTP/1.1 400 Bad Request*

  =  Content-Type: application/scim+json;charset=3DUTF-8
  =  Cache-Control: no-store
   Pragma: = no-cache

   {
     "schemas": = ["urn:scim:api:messages:2.0:Error"],
    =  "Errors":[
       {
      =    *=93scim_code":"mutability=94,*

*     =      =93http_status=94:400,*
      =    "error_description":"Attribute 'id' is readOnly."
  =      },

        . . = .

     ]

  =  }
...

You may want to read <http:= //tools.ietf.org/html/draft-nottingham-http-problem-06>...

B= est regards, = Julian

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

= --Apple-Mail=_7BB12BEF-2C41-4D0A-B96C-456BE36F0FCB-- From nobody Wed Jun 25 00:25:33 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A941B2B06 for ; Wed, 25 Jun 2014 00:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjo2Go5cYfs2 for ; Wed, 25 Jun 2014 00:25:25 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4340F1B2B05 for ; Wed, 25 Jun 2014 00:25:23 -0700 (PDT) Received: from NG-EX04.ad.nexusgroup.com (10.75.28.9) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 25 Jun 2014 09:25:20 +0200 Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX04.ad.nexusgroup.com (10.75.28.9) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 25 Jun 2014 09:25:19 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0847.030; Wed, 25 Jun 2014 09:25:19 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] [INPUT REQUESTED] Re: Detailed error and status codes Thread-Index: AQHPkARU/kJO3uaFVEmXGlkVn798fZuBS6sA Date: Wed, 25 Jun 2014 07:25:19 +0000 Message-ID: References: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> <53A9D021.2060906@gmx.de> <71B45AEC-9B79-4F3F-A933-23B0C2AF868E@oracle.com> In-Reply-To: <71B45AEC-9B79-4F3F-A933-23B0C2AF868E@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.88] Content-Type: multipart/alternative; boundary="_000_BE66EB7040F34FC387DAF828DDB300ADnexusgroupcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/aq08wnYsTwChwD6MpCDcFTYQHCQ Cc: Julian Reschke , Scim WG Subject: Re: [scim] [INPUT REQUESTED] Re: Detailed error and status codes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 07:25:28 -0000 --_000_BE66EB7040F34FC387DAF828DDB300ADnexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So that would make it look like the following right? { "schemas": ["urn:scim:api:messages:2.0:Error"], "Error": { "type": "urn:scim:api:error:2.0:mutability", "title": =93Attribute is readOnly.", "detail": =93Attribute 'id' is readOnly and can=92t be changed in a P= ATCH request.", =93status": 400 } } I replaced Errors with Error. Also replaced urn:scim:error:api:2.0:mutability with urn:scim:api:error:2.0= :mutability That works for me. / Erik On 25 Jun 2014, at 01:30, Phil Hunt > wrote: Note: July 04 is the LAST day for us to potentially submit updates for the = IETF90 meeting. This gives us about 1.5 weeks to close off the error issue= s and update the drafts. If you have a moment please take a look and comme= nt as soon as possible... Julian thanks for the suggestion. For the rest of the group=92s benefit, t= he draft Julian referenced suggests the following attributes be returned in= a standardized detailed error JSON body=85 A problem details object MAY have the following members: o "type" (string) - An absolute URI [RFC3986] that identifies the problem type. When dereferenced, it SHOULD provide human-readable documentation for the problem type (e.g., using HTML [W3C.REC-html401-19991224]). When this member is not = present, its value is assumed to be "about:blank". o "title" (string) - A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localisation. o "status" (number) - The HTTP status code ([RFC2616], Section 6) generated by the origin server for this occurrence of the problem. o "detail" (string) - An human readable explanation specific to this occurrence of the problem. o "instance" (string) - An absolute URI that identifies the specific occurrence of the problem. It may or may not yield further information if dereferenced. Here is the corresponding example error response: HTTP/1.1 403 Forbidden Content-Type: application/problem+json Content-Language: en { "type": "http://example.com/probs/out-of-credit", "title": "You do not have enough credit.", "detail": "Your current balance is 30, but that costs 50.", "instance": "http://example.net/account/12345/msgs/abc", "balance": 30, "accounts": ["http://example.net/account/12345", "http://example.net/account/67890"] } Julian, what is the value of having =93type=94 be a URI? Why not just have= a SCIM specific attribute (scimType) and use simple keywords? (asking main= ly for the WG=92s benefit). I guess the strong case is that by standardizin= g HTTP responses, client code gets simplified. However, using standard attr= ibutes creates the namespace conflict issue. So we need URI based error co= des. The SCIM specs could adopt the =93type=94, =93detail=94, and =93status=94. = We would register a namespace of urn:scim:error:apil:2.0 in the SCIM IANA s= ection in addition to api:messages, schema:core, etc. This would give deta= il error types of: urn:scim:error:api:2.0:mutability, urnscim:error:api:2.0:filter, etc. The other items, like title, instance, etc could be optional or just omitte= d from SCIM spec. =97> we would just indicate that clients should expect at= tributes within the JSON message other than those defined by the SCIM draft= s. IMPORTANT NOTE: the format suggested by Julian allows for only one error a= t a time. Erik had commented he prefers to return only one. I tend to agre= e. In the case of BULK requests, this is not really an issue since each BUL= K operation gets its own response block. In the interests of time, any objections to using type (with URI based erro= r codes), detail, status, per above and limiting to ONE per response? I know these are normative changes=85.however I=92m pretty sure we can=92t = avoid changes in the final document clean up whether or not we adopt the pr= oposed standardized error response. Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 24, 2014, at 12:23 PM, Julian Reschke > wrote: On 2014-06-24 21:01, Phil Hunt wrote: With regards to tickets 37, 46, 67, it looks like we will have some normative changes required. I am also expecting new SCIM error codes as we look at the possible reasons a server might return Bad Request or other HTTP status codes. Currently, the example response from PATCH, we use =93error=94 to indicate = a detailed error. * "error":"mutability"* >From Response Codes Section, no detail error is defined: *HTTP/1.1 404 NOT FOUND* { "schemas": ["urn:scim:api:messages:2.0:Error"], "Errors":[ { *"description":"Resource 2819c223-7f76-453a-919d-413861904646 not fou= nd", "code":"404"* } ] } Doing a search around Twitter, AWS, and many others, I see that =93code=94 is often used to indicate a detailed error message (=93mutability=94) and status is used to indicate HTTP status. In an attempt to bring consistency across the API document, I am proposing we use http_status and scim_code. This will help make clear what we are referring to and allow existing implementations to co-exist for a while (by having different names). _Are there any objections to normalizing the spec around following format and attributes?_ Proposed example: *HTTP/1.1 400 Bad Request* Content-Type: application/scim+json;charset=3DUTF-8 Cache-Control: no-store Pragma: no-cache { "schemas": ["urn:scim:api:messages:2.0:Error"], "Errors":[ { *=93scim_code":"mutability=94,* * =93http_status=94:400,* "error_description":"Attribute 'id' is readOnly." }, . . . ] } ... You may want to read ... Best regards, Julian _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_BE66EB7040F34FC387DAF828DDB300ADnexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <53E1A0AC24BB24479D0FDF767CE966FD@nexusgroup.com> Content-Transfer-Encoding: quoted-printable So that would make it look like the following right?

{
  "schemas": ["urn:scim:api:messages:2.0:Error"],<= br>   "Error":
    {
      "type": "urn:scim:api:error:2.0:mu= tability",
      "title": =93Attribute is readOnly."= ;,
      "detail": =93Attribute 'id' is readOnly= and can=92t be changed in a PATCH request.",
      =93status": 400  
    }
}

I replaced Errors with Error.
Also replaced urn:scim:error:api:2.0:mutability with urn:scim:api:erro= r:2.0:mutability

That works for me.
/ Erik



On 25 Jun 2014, at 01:30, Phil Hunt <phil.hunt@oracle.com> wrote:

Note: July 04 is the LAST day for us to potentially submit updates for= the IETF90 meeting.  This gives us about 1.5 weeks to close off the e= rror issues and update the drafts.  If you have a moment please take a= look and comment as soon as possible...

Julian thanks for the suggestion.  For the rest of the group=92s = benefit, the draft Julian referenced suggests the following attributes be r= eturned in a standardized detailed error JSON body=85

   A problem details object MAY have =
the following members:

   o  "type" (string) - An absolute URI [RFC3986] that identifies the
      problem type.  When dereferenced, it SHOULD provide human-readable
      documentation for the problem type (e.g., using HTML
      [W3C.REC-html401-19991224]).  When this=
 member is not present, its
      value is assumed to be "about:blank&=
quot;.
   o  "title" (string) - A short, human-readable summary of the p=
roblem
      type.  It SHOULD NOT change from occurrence to occurrence of the
      problem, except for purposes of localisation.
   o  "status" (number) - The HTTP status code ([RFC2616], Section 6)
      generated by the origin server for this occurrence of the problem.
   o  "detail" (string) - An human readable explanation specific =
to this
      occurrence of the problem.
   o  "instance" (string) - An absolute URI that identifies the s=
pecific
      occurrence of the problem.  It may or may not yield further
      information if dereferenced.

Here is the corresponding example error response:
   HTTP/1.1 403 Forbidden
   Content-Type: application/problem+json
   Content-Language: en

   {
    "type": "http://example.com/probs/out-of-credit",
    "title": "You do not have enough credit.",
    "detail": "Your current balance is 30, but that costs 50=
.",
    "instance": "http://example.net/account/12345/msgs/abc",
    "balance": 30,
    "accounts": ["http://example.net/account/12345",
                 "http://=
example.net/account/67890"]
   }

Julian, what is the value of having =93type=94 be a URI?  Why not= just have a SCIM specific attribute (scimType) and use simple keywords? (a= sking mainly for the WG=92s benefit). I guess the strong case is that by st= andardizing HTTP responses, client code gets simplified. However, using standard attributes creates the namespace confl= ict issue.  So we need URI based error codes.

The SCIM specs could adopt the =93type=94, =93detail=94, and =93status= =94. We would register a namespace of urn:scim:error:apil:2.0 in the SCIM I= ANA section in addition to api:messages, schema:core, etc.  This would= give detail error types of:
  urn:scim:error:api:2.0:mutability, urnscim:error:api:2.0:filter= , etc.

The other items, like title, instance, etc could be optional or just o= mitted from SCIM spec. =97> we would just indicate that clients should e= xpect attributes within the JSON message other than those defined by the SC= IM drafts.

IMPORTANT NOTE:  the format suggested by Julian allows for only o= ne error at a time.  Erik had commented he prefers to return only one.= I tend to agree. In the case of BULK requests, this is not really an issue= since each BULK operation gets its own response block.

In the interests of time, any objections to using type (with URI base= d error codes), detail, status, per above and limiting to ONE per response?=  

I know these are normative changes=85.however I=92m pretty sure we can= =92t avoid changes in the final document clean up whether or not we adopt t= he proposed standardized error response.

Cheers,


On Jun 24, 2014, at 12:23 PM, Julian Reschke <julian.reschke@gmx.de> wrote:

On 2014-06-24 21:01, Phil Hunt wrote:
With regards to tickets 37, 46, 67, it looks like= we will have some
normative changes required.  I am also expecting new SCIM error codes = as
we look at the possible reasons a server might return Bad Request or
other HTTP status codes.

Currently, the example response from PATCH, we use =93error=94 to indicate = a
detailed error.

* "error":"mutability"*

>From Response Codes Section, no detail error is defined:

*HTTP/1.1 404 NOT FOUND*

{
  "schemas": ["urn:scim:api:messages:2.0:Error"],<= br>   "Errors":[
    {
      *"description":"Resource 2819c223-7f76-= 453a-919d-413861904646 not found",
      "code":"404"*
    }
  ]
}


Doing a search around Twitter, AWS, and many others, I see that =93code=94<= br> is often used to indicate a detailed error message (=93mutability=94) and status is used to indicate HTTP status.

In an attempt to bring consistency across the API document, I am
proposing we use http_status and scim_code. This will help make clear
what we are referring to and allow existing implementations to co-exist
for a while (by having different names).

_Are there any objections to normalizing the spec around following
format and attributes?_

Proposed example:

*HTTP/1.1 400 Bad Request*

   Content-Type: application/scim+json;charset=3DUTF-8
   Cache-Control: no-store
   Pragma: no-cache

   {
     "schemas": ["urn:scim:api:messages:2.0:E= rror"],
     "Errors":[
       {
         *=93scim_code":"mutability=94,*=

*          =93http_status=94:400,*
         "error_description":"Attri= bute 'id' is readOnly."
       },

        . . .

     ]

   }
...

You may want to read <http://tools.ietf.org/html/draft-nottingham-http-prob= lem-06>...

Best regards, Julian

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

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

--_000_BE66EB7040F34FC387DAF828DDB300ADnexusgroupcom_-- From nobody Wed Jun 25 08:05:29 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965501B2CF9 for ; Wed, 25 Jun 2014 08:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIt0KcFBlIz2 for ; Wed, 25 Jun 2014 08:05:21 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447561B2CE2 for ; Wed, 25 Jun 2014 08:05:20 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5PF5Dom012860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jun 2014 15:05:14 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5PF5BmI026425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2014 15:05:12 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5PF5An3027604; Wed, 25 Jun 2014 15:05:10 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Jun 2014 08:05:09 -0700 References: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> <53A9D021.2060906@gmx.de> <71B45AEC-9B79-4F3F-A933-23B0C2AF868E@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-B02B8E46-EB2B-4EEC-962F-6B7C3511F299 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D201) From: Phil Hunt Date: Wed, 25 Jun 2014 08:05:08 -0700 To: =?utf-8?Q?Erik_Wahlstr=C3=B6m?= X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/coyEThCsQ37UjOR_lmwD6R3MoSE Cc: Julian Reschke , Scim WG Subject: Re: [scim] [INPUT REQUESTED] Re: Detailed error and status codes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 15:05:27 -0000 --Apple-Mail-B02B8E46-EB2B-4EEC-962F-6B7C3511F299 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes. :-) Phil > On Jun 25, 2014, at 0:25, Erik Wahlstr=C3=B6m wrote: >=20 > So that would make it look like the following right? >=20 > { > "schemas": ["urn:scim:api:messages:2.0:Error"], > "Error": > { > "type": "urn:scim:api:error:2.0:mutability", > "title": =E2=80=9CAttribute is readOnly.", > "detail": =E2=80=9CAttribute 'id' is readOnly and can=E2=80=99t be c= hanged in a PATCH request.", > =E2=80=9Cstatus": 400 =20 > } > } >=20 > I replaced Errors with Error. > Also replaced urn:scim:error:api:2.0:mutability with urn:scim:api:error:2.= 0:mutability >=20 > That works for me. > / Erik >=20 >=20 >=20 >> On 25 Jun 2014, at 01:30, Phil Hunt wrote: >>=20 >> Note: July 04 is the LAST day for us to potentially submit updates for th= e IETF90 meeting. This gives us about 1.5 weeks to close off the error issu= es and update the drafts. If you have a moment please take a look and comme= nt as soon as possible... >>=20 >> Julian thanks for the suggestion. For the rest of the group=E2=80=99s be= nefit, the draft Julian referenced suggests the following attributes be retu= rned in a standardized detailed error JSON body=E2=80=A6 >>=20 >>> A problem details object MAY have the following members: >>>=20 >>> o "type" (string) - An absolute URI [RFC3986] that identifies the >>> problem type. When dereferenced, it SHOULD provide human-readable= >>> documentation for the problem type (e.g., using HTML >>> [W3C.REC-html401-19991224]). When this member is not present, its= >>> value is assumed to be "about:blank". >>> o "title" (string) - A short, human-readable summary of the problem >>> type. It SHOULD NOT change from occurrence to occurrence of the >>> problem, except for purposes of localisation. >>> o "status" (number) - The HTTP status code ([RFC2616], Section 6) >>> generated by the origin server for this occurrence of the problem.= >>> o "detail" (string) - An human readable explanation specific to this= >>> occurrence of the problem. >>> o "instance" (string) - An absolute URI that identifies the specific= >>> occurrence of the problem. It may or may not yield further >>> information if dereferenced. >>=20 >> Here is the corresponding example error response: >>> HTTP/1.1 403 Forbidden >>> Content-Type: application/problem+json >>> Content-Language: en >>>=20 >>> { >>> "type": "http://example.com/probs/out-of-credit", >>> "title": "You do not have enough credit.", >>> "detail": "Your current balance is 30, but that costs 50.", >>> "instance": "http://example.net/account/12345/msgs/abc", >>> "balance": 30, >>> "accounts": ["http://example.net/account/12345", >>> "http://example.net/account/67890"] >>> } >>=20 >>=20 >> Julian, what is the value of having =E2=80=9Ctype=E2=80=9D be a URI? Why= not just have a SCIM specific attribute (scimType) and use simple keywords?= (asking mainly for the WG=E2=80=99s benefit). I guess the strong case is th= at by standardizing HTTP responses, client code gets simplified. However, us= ing standard attributes creates the namespace conflict issue. So we need UR= I based error codes. >>=20 >> The SCIM specs could adopt the =E2=80=9Ctype=E2=80=9D, =E2=80=9Cdetail=E2= =80=9D, and =E2=80=9Cstatus=E2=80=9D. We would register a namespace of urn:s= cim:error:apil:2.0 in the SCIM IANA section in addition to api:messages, sch= ema:core, etc. This would give detail error types of: >> urn:scim:error:api:2.0:mutability, urnscim:error:api:2.0:filter, etc. >>=20 >> The other items, like title, instance, etc could be optional or just omit= ted from SCIM spec. =E2=80=94> we would just indicate that clients should ex= pect attributes within the JSON message other than those defined by the SCIM= drafts. >>=20 >> IMPORTANT NOTE: the format suggested by Julian allows for only one error= at a time. Erik had commented he prefers to return only one. I tend to agr= ee. In the case of BULK requests, this is not really an issue since each BUL= K operation gets its own response block. >>=20 >> In the interests of time, any objections to using type (with URI based er= ror codes), detail, status, per above and limiting to ONE per response? =20 >>=20 >> I know these are normative changes=E2=80=A6.however I=E2=80=99m pretty su= re we can=E2=80=99t avoid changes in the final document clean up whether or n= ot we adopt the proposed standardized error response. >>=20 >> Cheers, >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Jun 24, 2014, at 12:23 PM, Julian Reschke wrot= e: >>=20 >>>> On 2014-06-24 21:01, Phil Hunt wrote: >>>> With regards to tickets 37, 46, 67, it looks like we will have some >>>> normative changes required. I am also expecting new SCIM error codes a= s >>>> we look at the possible reasons a server might return Bad Request or >>>> other HTTP status codes. >>>>=20 >>>> Currently, the example response from PATCH, we use =E2=80=9Cerror=E2=80= =9D to indicate a >>>> detailed error. >>>>=20 >>>> * "error":"mutability"* >>>>=20 >>>> >=46rom Response Codes Section, no detail error is defined: >>>>=20 >>>> *HTTP/1.1 404 NOT FOUND* >>>>=20 >>>> { >>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>> "Errors":[ >>>> { >>>> *"description":"Resource 2819c223-7f76-453a-919d-413861904646 not= found", >>>> "code":"404"* >>>> } >>>> ] >>>> } >>>>=20 >>>>=20 >>>> Doing a search around Twitter, AWS, and many others, I see that =E2=80=9C= code=E2=80=9D >>>> is often used to indicate a detailed error message (=E2=80=9Cmutability= =E2=80=9D) and >>>> status is used to indicate HTTP status. >>>>=20 >>>> In an attempt to bring consistency across the API document, I am >>>> proposing we use http_status and scim_code. This will help make clear >>>> what we are referring to and allow existing implementations to co-exist= >>>> for a while (by having different names). >>>>=20 >>>> _Are there any objections to normalizing the spec around following >>>> format and attributes?_ >>>>=20 >>>> Proposed example: >>>>=20 >>>> *HTTP/1.1 400 Bad Request* >>>>=20 >>>> Content-Type: application/scim+json;charset=3DUTF-8 >>>> Cache-Control: no-store >>>> Pragma: no-cache >>>>=20 >>>> { >>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>> "Errors":[ >>>> { >>>> *=E2=80=9Cscim_code":"mutability=E2=80=9D,* >>>>=20 >>>> * =E2=80=9Chttp_status=E2=80=9D:400,* >>>> "error_description":"Attribute 'id' is readOnly." >>>> }, >>>>=20 >>>> . . . >>>>=20 >>>> ] >>>>=20 >>>> } >>>> ... >>>=20 >>> You may want to read ... >>>=20 >>> Best regards, Julian >>>=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 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-B02B8E46-EB2B-4EEC-962F-6B7C3511F299 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes. :-)

Phil
=
On Jun 25, 2014, at 0:25, Erik Wahlstr=C3=B6m <erik.wahlstrom@nexusgroup.com> wrote:
<= br>
So that would make it look like the following right?

{
  "schemas": ["urn:scim:api:messages:2.0:Error"],
  "Error":
    {
      "type": "urn:scim:api:error:2.0:mutability",
=
      "title": =E2=80=9CAttribute is readOnly.",
      "detail": =E2=80=9CAttribute 'id' is readOnly and c= an=E2=80=99t be changed in a PATCH request.",
      =E2=80=9Cstatus": 400  
    }
}

I replaced Errors with Error.
Also replaced urn:scim:error:api:2.0:mutability with urn:scim:api:error= :2.0:mutability

That works for me.
/ Erik



On 25 Jun 2014, at 01:30, Phil Hunt <phil.hunt@oracle.com> wrote:

Note: July 04 is the LAST day for us to potentially submit updates for t= he IETF90 meeting.  This gives us about 1.5 weeks to close off the erro= r issues and update the drafts.  If you have a moment please take a loo= k and comment as soon as possible...

Julian thanks for the suggestion.  For the rest of the group=E2=80= =99s benefit, the draft Julian referenced suggests the following attributes b= e returned in a standardized detailed error JSON body=E2=80=A6

   A problem details object MAY have th=
e following members:

   o  "type" (string) - An absolute URI [RFC3986] that identifies the
      problem type.  When dereferenced, it SHOULD provide human-readable
      documentation for the problem type (e.g., using HTML
      [W3C.REC-html401-19991224]).  When this m=
ember is not present, its
      value is assumed to be "about:blank".
   o  "title" (string) - A short, human-readable summary of the problem
      type.  It SHOULD NOT change from occurrence to occurrence of the
      problem, except for purposes of localisation.
   o  "status" (number) - The HTTP status code ([RFC2616], Section 6)
      generated by the origin server for this occurrence of the problem.
   o  "detail" (string) - An human readable explanation specific to this
      occurrence of the problem.
   o  "instance" (string) - An absolute URI that identifies the specific
      occurrence of the problem.  It may or may not yield further
      information if dereferenced.

Here is the corresponding example error response:
   HTTP/1.1 403 Forbidden
   Content-Type: application/problem+json
   Content-Language: en

   {
    "type": "http://examp=
le.com/probs/out-of-credit",
    "title": "You do not have enough credit.",
    "detail": "Your current balance is 30, but that costs 50.",
    "instance": "http:=
//example.net/account/12345/msgs/abc",
    "balance": 30,
    "accounts": ["http://exampl=
e.net/account/12345",
                 "http://exampl=
e.net/account/67890"]
   }

Julian, what is the value of having =E2=80=9Ctype=E2=80=9D be a URI? &n= bsp;Why not just have a SCIM specific attribute (scimType) and use simple ke= ywords? (asking mainly for the WG=E2=80=99s benefit). I guess the strong cas= e is that by standardizing HTTP responses, client code gets simplified. However, using standard attributes creates the namespace confli= ct issue.  So we need URI based error codes.

The SCIM specs could adopt the =E2=80=9Ctype=E2=80=9D, =E2=80=9Cdetail=E2= =80=9D, and =E2=80=9Cstatus=E2=80=9D. We would register a namespace of urn:s= cim:error:apil:2.0 in the SCIM IANA section in addition to api:messages, sch= ema:core, etc.  This would give detail error types of:
  urn:scim:error:api:2.0:mutability, urnscim:error:api:2.0:filter,= etc.

The other items, like title, instance, etc could be optional or just om= itted from SCIM spec. =E2=80=94> we would just indicate that clients shou= ld expect attributes within the JSON message other than those defined by the= SCIM drafts.

IMPORTANT NOTE:  the format suggested by Julian allows for only on= e error at a time.  Erik had commented he prefers to return only one. I= tend to agree. In the case of BULK requests, this is not really an issue si= nce each BULK operation gets its own response block.

In the interests of time, any objections to using type (with URI based= error codes), detail, status, per above and limiting to ONE per response? &= nbsp;

I know these are normative changes=E2=80=A6.however I=E2=80=99m pretty s= ure we can=E2=80=99t avoid changes in the final document clean up whether or= not we adopt the proposed standardized error response.

Cheers,


On Jun 24, 2014, at 12:23 PM, Julian Reschke <julian.reschke@gmx.de> wrote:

On 2014-06-24 21:01, Phil Hunt wrote:
With regards to tickets 37, 46, 67, it looks like w= e will have some
normative changes required.  I am also expecting new SCIM error codes a= s
we look at the possible reasons a server might return Bad Request or
other HTTP status codes.

Currently, the example response from PATCH, we use =E2=80=9Cerror=E2=80=9D t= o indicate a
detailed error.

* "error":"mutability"*

>=46rom Response Codes Section, no detail error is defined:

*HTTP/1.1 404 NOT FOUND*

{
  "schemas": ["urn:scim:api:messages:2.0:Error"],
  "Errors":[
    {
      *"description":"Resource 2819c223-7f76-453a-919d-413861= 904646 not found",
      "code":"404"*
    }
  ]
}


Doing a search around Twitter, AWS, and many others, I see that =E2=80=9Ccod= e=E2=80=9D
is often used to indicate a detailed error message (=E2=80=9Cmutability=E2=80= =9D) and
status is used to indicate HTTP status.

In an attempt to bring consistency across the API document, I am
proposing we use http_status and scim_code. This will help make clear
what we are referring to and allow existing implementations to co-exist
for a while (by having different names).

_Are there any objections to normalizing the spec around following
format and attributes?_

Proposed example:

*HTTP/1.1 400 Bad Request*

   Content-Type: application/scim+json;charset=3DUTF-8
   Cache-Control: no-store
   Pragma: no-cache

   {
     "schemas": ["urn:scim:api:messages:2.0:Error"],
     "Errors":[
       {
         *=E2=80=9Cscim_code":"mutability=E2=80=9D,= *

*          =E2=80=9Chttp_status=E2=80=9D:400,*
         "error_description":"Attribute 'id' is rea= dOnly."
       },

        . . .

     ]

   }
...

You may want to read <http://tools.ietf.org/html/draft-nottingham-http-proble= m-06>...

Best regards, Julian

_______________________________________________
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
= --Apple-Mail-B02B8E46-EB2B-4EEC-962F-6B7C3511F299-- From nobody Wed Jun 25 12:07:46 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B133E1B2E48 for ; Wed, 25 Jun 2014 12:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.651 X-Spam-Level: X-Spam-Status: No, score=-3.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJlwyjuQRv0x for ; Wed, 25 Jun 2014 12:07:28 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B6A1B2E2E for ; Wed, 25 Jun 2014 12:07:15 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5PJ7E98006610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Jun 2014 19:07:15 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 s5PJ7Dil002362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jun 2014 19:07:14 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5PJ7CVQ004703 for ; Wed, 25 Jun 2014 19:07:13 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Jun 2014 12:07:12 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_38D9A428-B9D6-44F4-9B62-547F06596BC5" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Wed, 25 Jun 2014 12:07:11 -0700 References: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> <53A9D021.2060906@gmx.de> <71B45AEC-9B79-4F3F-A933-23B0C2AF868E@oracle.com> To: Scim WG In-Reply-To: X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Hxz_rp8IwQWzLIYmTuJ3G4kHVAM Subject: Re: [scim] [INPUT REQUESTED] Re: Detailed error and status codes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 19:07:39 -0000 --Apple-Mail=_38D9A428-B9D6-44F4-9B62-547F06596BC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On the call today (Erik, Bjorn, Morteza, and myself), we discussed the = error issue. The major concern with the draft suggested by Julian is really one of = timing - we would prefer not to hold SCIM up. A good middle-ground = approach is to align with the draft, but define the error fully within = SCIM (using the SCIM mime type and schema namespace). The proposal on the call is to SCIM mime/type of application/scim+json = in error responses and include the SCIM error message schema = declaration. =20 { =93schema=94: "urn:scim:api:messages:2.0:Error=94 (indicates the SCIM = message type) "scimType" - a keyword indicating the detail error (e.g. =93mutability=94= ) "status" - the HTTP status (should correspond to the response header) "detail" - a detailed, human-readable message } Servers MAY return additional attributes (e.g. ones from http-problem = draft). The only mandatory attributes are =93schema=94 and =93status=94. = For example on anonymous self-registration scenarios, servers may be = unwilling to give detail error responses for security reasons. The reason for using scimType (instead of type) is to avoid any = confusion with =93type=94 from draft-nottingham-http-problem and its = eventual use of =93type=94. In a future update to SCIM we can then transition to align with the HTTP = Problem draft by simply adding =93type=94 in the way it defines.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 25, 2014, at 12:25 AM, Erik Wahlstr=F6m = wrote: > So that would make it look like the following right? >=20 > { > "schemas": ["urn:scim:api:messages:2.0:Error"], > "Error": > { > "type": "urn:scim:api:error:2.0:mutability", > "title": =93Attribute is readOnly.", > "detail": =93Attribute 'id' is readOnly and can=92t be changed = in a PATCH request.", > =93status": 400 =20 > } > } >=20 > I replaced Errors with Error. > Also replaced urn:scim:error:api:2.0:mutability with = urn:scim:api:error:2.0:mutability >=20 > That works for me. > / Erik >=20 >=20 >=20 > On 25 Jun 2014, at 01:30, Phil Hunt wrote: >=20 >> Note: July 04 is the LAST day for us to potentially submit updates = for the IETF90 meeting. This gives us about 1.5 weeks to close off the = error issues and update the drafts. If you have a moment please take a = look and comment as soon as possible... >>=20 >> Julian thanks for the suggestion. For the rest of the group=92s = benefit, the draft Julian referenced suggests the following attributes = be returned in a standardized detailed error JSON body=85 >>=20 >>> A problem details object MAY have the following members: >>>=20 >>> o "type" (string) - An absolute URI [RFC3986] that identifies = the >>> problem type. When dereferenced, it SHOULD provide = human-readable >>> documentation for the problem type (e.g., using HTML >>> [W3C.REC-html401-19991224]). When this member is not present, = its >>> value is assumed to be "about:blank". >>> o "title" (string) - A short, human-readable summary of the = problem >>> type. It SHOULD NOT change from occurrence to occurrence of = the >>> problem, except for purposes of localisation. >>> o "status" (number) - The HTTP status code ([RFC2616], Section = 6) >>> generated by the origin server for this occurrence of the = problem. >>> o "detail" (string) - An human readable explanation specific to = this >>> occurrence of the problem. >>> o "instance" (string) - An absolute URI that identifies the = specific >>> occurrence of the problem. It may or may not yield further >>> information if dereferenced. >>=20 >> Here is the corresponding example error response: >>> HTTP/1.1 403 Forbidden >>> Content-Type: application/problem+json >>> Content-Language: en >>>=20 >>> { >>> "type": "http://example.com/probs/out-of-credit", >>> "title": "You do not have enough credit.", >>> "detail": "Your current balance is 30, but that costs 50.", >>> "instance": "http://example.net/account/12345/msgs/abc", >>> "balance": 30, >>> "accounts": ["http://example.net/account/12345", >>> "http://example.net/account/67890"] >>> } >>=20 >>=20 >> Julian, what is the value of having =93type=94 be a URI? Why not = just have a SCIM specific attribute (scimType) and use simple keywords? = (asking mainly for the WG=92s benefit). I guess the strong case is that = by standardizing HTTP responses, client code gets simplified. However, = using standard attributes creates the namespace conflict issue. So we = need URI based error codes. >>=20 >> The SCIM specs could adopt the =93type=94, =93detail=94, and = =93status=94. We would register a namespace of urn:scim:error:apil:2.0 = in the SCIM IANA section in addition to api:messages, schema:core, etc. = This would give detail error types of: >> urn:scim:error:api:2.0:mutability, urnscim:error:api:2.0:filter, = etc. >>=20 >> The other items, like title, instance, etc could be optional or just = omitted from SCIM spec. =97> we would just indicate that clients should = expect attributes within the JSON message other than those defined by = the SCIM drafts. >>=20 >> IMPORTANT NOTE: the format suggested by Julian allows for only one = error at a time. Erik had commented he prefers to return only one. I = tend to agree. In the case of BULK requests, this is not really an issue = since each BULK operation gets its own response block. >>=20 >> In the interests of time, any objections to using type (with URI = based error codes), detail, status, per above and limiting to ONE per = response? =20 >>=20 >> I know these are normative changes=85.however I=92m pretty sure we = can=92t avoid changes in the final document clean up whether or not we = adopt the proposed standardized error response. >>=20 >> Cheers, >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Jun 24, 2014, at 12:23 PM, Julian Reschke = wrote: >>=20 >>> On 2014-06-24 21:01, Phil Hunt wrote: >>>> With regards to tickets 37, 46, 67, it looks like we will have some >>>> normative changes required. I am also expecting new SCIM error = codes as >>>> we look at the possible reasons a server might return Bad Request = or >>>> other HTTP status codes. >>>>=20 >>>> Currently, the example response from PATCH, we use =93error=94 to = indicate a >>>> detailed error. >>>>=20 >>>> * "error":"mutability"* >>>>=20 >>>> =46rom Response Codes Section, no detail error is defined: >>>>=20 >>>> *HTTP/1.1 404 NOT FOUND* >>>>=20 >>>> { >>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>> "Errors":[ >>>> { >>>> *"description":"Resource 2819c223-7f76-453a-919d-413861904646 = not found", >>>> "code":"404"* >>>> } >>>> ] >>>> } >>>>=20 >>>>=20 >>>> Doing a search around Twitter, AWS, and many others, I see that = =93code=94 >>>> is often used to indicate a detailed error message (=93mutability=94)= and >>>> status is used to indicate HTTP status. >>>>=20 >>>> In an attempt to bring consistency across the API document, I am >>>> proposing we use http_status and scim_code. This will help make = clear >>>> what we are referring to and allow existing implementations to = co-exist >>>> for a while (by having different names). >>>>=20 >>>> _Are there any objections to normalizing the spec around following >>>> format and attributes?_ >>>>=20 >>>> Proposed example: >>>>=20 >>>> *HTTP/1.1 400 Bad Request* >>>>=20 >>>> Content-Type: application/scim+json;charset=3DUTF-8 >>>> Cache-Control: no-store >>>> Pragma: no-cache >>>>=20 >>>> { >>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>> "Errors":[ >>>> { >>>> *=93scim_code":"mutability=94,* >>>>=20 >>>> * =93http_status=94:400,* >>>> "error_description":"Attribute 'id' is readOnly." >>>> }, >>>>=20 >>>> . . . >>>>=20 >>>> ] >>>>=20 >>>> } >>>> ... >>>=20 >>> You may want to read = ... >>>=20 >>> Best regards, Julian >>>=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=_38D9A428-B9D6-44F4-9B62-547F06596BC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On the = call today (Erik, Bjorn, Morteza, and myself), we discussed the error = issue.

The major concern with the draft suggested by = Julian is really one of timing - we would prefer not to hold SCIM up. A = good middle-ground approach is to align with the draft, but define the = error fully within SCIM (using the SCIM mime type and schema = namespace).

The proposal on the call is to SCIM = mime/type of application/scim+json in error responses and include the = SCIM error message schema declaration. =  

{
 =93schema=94: = "urn:scim:api:messages:2.0:Error=94 (indicates the SCIM message = type)
 "scimType" - a keyword indicating the detail error = (e.g.  =93mutability=94)
 "status" - the HTTP status = (should correspond to the response header)
 "detail" - a = detailed, human-readable = message
}

Servers MAY return = additional attributes (e.g. ones from http-problem draft).  The = only mandatory attributes are =93schema=94 and =93status=94.  For = example on anonymous self-registration scenarios, servers may be = unwilling to give detail error responses for security = reasons.

The reason for using scimType (instead = of type) is to avoid any confusion with =93type=94 from = draft-nottingham-http-problem and its eventual use of = =93type=94.

In a future update to SCIM we can = then transition to align with the HTTP Problem draft by simply adding = =93type=94 in the way it defines. 


On Jun 25, 2014, at 12:25 AM, Erik Wahlstr=F6m <erik.wahlstrom@nexusgroup.co= m> wrote:

So that would make it look like the following right?

{
  "schemas": ["urn:scim:api:messages:2.0:Error"],
  "Error":
    {
      "type": = "urn:scim:api:error:2.0:mutability",
      "title": =93Attribute is readOnly.",
      "detail": =93Attribute 'id' is readOnly and = can=92t be changed in a PATCH request.",
      =93status": 400  
    }
}

I replaced Errors with Error.
Also replaced urn:scim:error:api:2.0:mutability with = urn:scim:api:error:2.0:mutability

That works for me.
/ Erik



On 25 Jun 2014, at 01:30, Phil Hunt <phil.hunt@oracle.com> = wrote:

Note: July 04 is the LAST day for us to potentially submit updates = for the IETF90 meeting.  This gives us about 1.5 weeks to close off = the error issues and update the drafts.  If you have a moment = please take a look and comment as soon as possible...

Julian thanks for the suggestion.  For the rest of the group=92s= benefit, the draft Julian referenced suggests the following attributes = be returned in a standardized detailed error JSON body=85

   A problem details =
object MAY have the following members:

   o  "type" (string) - An absolute URI [RFC3986] that =
identifies the
      problem type.  When dereferenced, it SHOULD provide human-readable
      documentation for the problem type (e.g., using HTML
      [W3C.REC-html401-19991224]).  When this =
member is not present, its
      value is assumed to be "about:blank".
   o  "title" (string) - A short, human-readable summary of the problem
      type.  It SHOULD NOT change from occurrence to occurrence of the
      problem, except for purposes of localisation.
   o  "status" (number) - The HTTP status code ([RFC2616], =
Section 6)
      generated by the origin server for this occurrence of the problem.
   o  "detail" (string) - An human readable explanation specific to this
      occurrence of the problem.
   o  "instance" (string) - An absolute URI that identifies the specific
      occurrence of the problem.  It may or may not yield further
      information if dereferenced.

Here is the corresponding example error response:
   HTTP/1.1 403 =
Forbidden
   Content-Type: application/problem+json
   Content-Language: en

   {
    "type": "http://example.com/probs/o=
ut-of-credit",
    "title": "You do not have enough credit.",
    "detail": "Your current balance is 30, but that costs 50.",
    "instance": "http://example.net/acco=
unt/12345/msgs/abc",
    "balance": 30,
    "accounts": ["http://example.net/account/12345=
",
                 "http://example.net/account/67890=
"]
   }

Julian, what is the value of having =93type=94 be a URI?  Why = not just have a SCIM specific attribute (scimType) and use simple = keywords? (asking mainly for the WG=92s benefit). I guess the strong = case is that by standardizing HTTP responses, client code gets simplified. However, using standard attributes creates the namespace = conflict issue.  So we need URI based error codes.

The SCIM specs could adopt the =93type=94, =93detail=94, and = =93status=94. We would register a namespace of urn:scim:error:apil:2.0 = in the SCIM IANA section in addition to api:messages, schema:core, etc. =  This would give detail error types of:
  urn:scim:error:api:2.0:mutability, = urnscim:error:api:2.0:filter, etc.

The other items, like title, instance, etc could be optional or = just omitted from SCIM spec. =97> we would just indicate that clients = should expect attributes within the JSON message other than those = defined by the SCIM drafts.

IMPORTANT NOTE:  the format suggested by Julian allows for = only one error at a time.  Erik had commented he prefers to return = only one. I tend to agree. In the case of BULK requests, this is not = really an issue since each BULK operation gets its own response block.

In the interests of time, any objections to using type (with URI = based error codes), detail, status, per above and limiting to ONE per = response?  

I know these are normative changes=85.however I=92m pretty sure we = can=92t avoid changes in the final document clean up whether or not we = adopt the proposed standardized error response.

Cheers,


On Jun 24, 2014, at 12:23 PM, Julian Reschke <julian.reschke@gmx.de> = wrote:

On 2014-06-24 21:01, Phil Hunt wrote:
With regards to tickets 37, 46, 67, it looks = like we will have some
normative changes required.  I am also expecting new SCIM error = codes as
we look at the possible reasons a server might return Bad Request or
other HTTP status codes.

Currently, the example response from PATCH, we use =93error=94 to = indicate a
detailed error.

* "error":"mutability"*

=46rom Response Codes Section, no detail error is defined:

*HTTP/1.1 404 NOT FOUND*

{
  "schemas": ["urn:scim:api:messages:2.0:Error"],
  "Errors":[
    {
      *"description":"Resource = 2819c223-7f76-453a-919d-413861904646 not found",
      "code":"404"*
    }
  ]
}


Doing a search around Twitter, AWS, and many others, I see that = =93code=94
is often used to indicate a detailed error message (=93mutability=94) = and
status is used to indicate HTTP status.

In an attempt to bring consistency across the API document, I am
proposing we use http_status and scim_code. This will help make = clear
what we are referring to and allow existing implementations to = co-exist
for a while (by having different names).

_Are there any objections to normalizing the spec around following
format and attributes?_

Proposed example:

*HTTP/1.1 400 Bad Request*

   Content-Type: application/scim+json;charset=3DUTF-8
   Cache-Control: no-store
   Pragma: no-cache

   {
     "schemas": ["urn:scim:api:messages:2.0:Error"],
     "Errors":[
       {
         *=93scim_code":"mutability=94,*

*          =93http_status=94:400,*
         "error_description":"Attribute 'id' is = readOnly."
       },

        . . .

     ]

   }
...

You may want to read <http:= //tools.ietf.org/html/draft-nottingham-http-problem-06>...

Best regards, Julian

_______________________________________________
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


= --Apple-Mail=_38D9A428-B9D6-44F4-9B62-547F06596BC5-- From nobody Thu Jun 26 02:10:01 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAE81B2F50 for ; Thu, 26 Jun 2014 02:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.2 X-Spam-Level: * X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, J_CHICKENPOX_64=0.6, MANGLED_WANT=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fckNPEu_o1Fx for ; Thu, 26 Jun 2014 02:09:57 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B641B2CED for ; Thu, 26 Jun 2014 02:09:56 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w62so3310085wes.10 for ; Thu, 26 Jun 2014 02:09:54 -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=7S+Nkzh0C5m4FZsJ+KKKC+vno6l9frB2AGF9o0+ZNqA=; b=Sx8ri5b3rzfbENMaM9RzfdXzZhSW7uG6+oaq9Pz+EGUJ8okup5ukvtRbRkSkmnTttY IKYdRd6eZEtVZ962r/B8f1ef9XKtebtPx16U6mxsgZS0HFbrqZSHBCcihgrRKfia724U xCkzH/QYyKUTQX9QY1kc8JZ8S+2DyBwg4dX/dYPgpvrKJ09fnpIXDzZ2/l4m7yoTEd/5 Bm6PRG69z0NkzQ6ql/OtQdvpV2xk0OaSmeENPXwU+vi7E5mRZNcBydwBS0KEzS1e1t4s ZPYiRpzp5BUfVnY+DlCJgbsYU7Vow7OABC3KT6cc13Jo3xft5QEyYDDDakVi0dVG5dPV bwjg== X-Gm-Message-State: ALoCoQne+3TH0uBq1gpbbk25k0Y9/ngZrkgyO3rv8VVC2BS503PZgkx6d/8PgpLzuMTiGqnh6ULF X-Received: by 10.180.10.168 with SMTP id j8mr2663877wib.73.1403773794185; Thu, 26 Jun 2014 02:09:54 -0700 (PDT) Received: from [172.24.12.173] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id ub8sm22230914wib.0.2014.06.26.02.09.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 02:09:53 -0700 (PDT) Message-ID: <53ABE35E.7030404@tarent.de> Date: Thu, 26 Jun 2014 11:09:50 +0200 From: =?windows-1252?Q?David_M=F6bius?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: scim@ietf.org References: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> <53A9D021.2060906@gmx.de> <71B45AEC-9B79-4F3F-A933-23B0C2AF868E@oracle.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/6s-bnUZe9kvH9AcVqsYunh9aTJ8 Subject: Re: [scim] [INPUT REQUESTED] Re: Detailed error and status codes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 09:10:00 -0000 Hello, I would like to adjust to add a "error group" type to the error object. Example: { “schema”: "urn:scim:api:messages:2.0:Error” "scimGroupType" - "saving user" "scimDetailType" - "username allready taken" "status" - the HTTP status (should correspond to the response header) "detail" - "The username 'marissa' is already taken" } The scimGroupType and the scimDetailType should never change if you do the same mistage to make it machine readable. Example and Reason: I have a mask where the user can create an account. I have created my html page the way that the user can't do "anything" wrong. The only think the could do wrong is to use a existing username. After I send the new user to the backend I get an exception. Since I wan't to display the exception message in german or an other language I need to know what type of exception was the problem. I would like to give the User kind of messages: 1. The user used a given username: If this is the problem I can see it with the help of the scimDetailType which will always be "username already taken". 2. It is somethink wrong with the userdata (for example a email without @ which I forget to check in my frontend). That something is wrong with the userdata in generall I can see with the "scimGroupType" 3. Something else happens and I want to log the exception in my logs and give an general message to the user In my front end it could look like if(scimException.getScimDetailType.equals("username allready taken")){ errorMessage = "in german: Your username is already taken. Plase use a other one." }else if(scimException.getScimGroupType.equals("saving user")){ errorMessage = "in german: Could not save your data. Please check your given data."; }else{ log.Error(scimException); errorMessage= "in german: an error happen. Please try again later." } For this reason it would be good if we have 2 error codings in our error json object. What do you think about this? by David Am 25.06.2014 21:07, schrieb Phil Hunt: > On the call today (Erik, Bjorn, Morteza, and myself), we discussed the > error issue. > > The major concern with the draft suggested by Julian is really one of > timing - we would prefer not to hold SCIM up. A good middle-ground > approach is to align with the draft, but define the error fully within > SCIM (using the SCIM mime type and schema namespace). > > The proposal on the call is to SCIM mime/type of application/scim+json > in error responses and include the SCIM error message schema declaration. > > { > “schema”: "urn:scim:api:messages:2.0:Error” (indicates the SCIM message > type) > "scimType" - a keyword indicating the detail error (e.g. “mutability”) > "status" - the HTTP status (should correspond to the response header) > "detail" - a detailed, human-readable message > } > > Servers MAY return additional attributes (e.g. ones from http-problem > draft). The only mandatory attributes are “schema” and “status”. For > example on anonymous self-registration scenarios, servers may be > unwilling to give detail error responses for security reasons. > > The reason for using scimType (instead of type) is to avoid any > confusion with “type” from draft-nottingham-http-problem and its > eventual use of “type”. > > In a future update to SCIM we can then transition to align with the HTTP > Problem draft by simply adding “type” in the way it defines. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jun 25, 2014, at 12:25 AM, Erik Wahlström > > > wrote: > >> So that would make it look like the following right? >> >> { >> "schemas": ["urn:scim:api:messages:2.0:Error"], >> "Error": >> { >> "type": "urn:scim:api:error:2.0:mutability", >> "title": “Attribute is readOnly.", >> "detail": “Attribute 'id' is readOnly and can’t be changed in a >> PATCH request.", >> “status": 400 >> } >> } >> >> I replaced Errors with Error. >> Also replaced urn:scim:error:api:2.0:mutability with >> urn:scim:api:error:2.0:mutability >> >> That works for me. >> / Erik >> >> >> >> On 25 Jun 2014, at 01:30, Phil Hunt > > wrote: >> >>> Note: July 04 is the LAST day for us to potentially submit updates >>> for the IETF90 meeting. This gives us about 1.5 weeks to close off >>> the error issues and update the drafts. If you have a moment please >>> take a look and comment as soon as possible... >>> >>> Julian thanks for the suggestion. For the rest of the group’s >>> benefit, the draft Julian referenced suggests the following >>> attributes be returned in a standardized detailed error JSON body… >>> >>>> A problem details object MAY have the following members: >>>> >>>> o "type" (string) - An absolute URI [RFC3986 ] that identifies the >>>> problem type. When dereferenced, it SHOULD provide human-readable >>>> documentation for the problem type (e.g., using HTML >>>> [W3C.REC-html401-19991224 ]). When this member is not present, its >>>> value is assumed to be "about:blank". >>>> o "title" (string) - A short, human-readable summary of the problem >>>> type. It SHOULD NOT change from occurrence to occurrence of the >>>> problem, except for purposes of localisation. >>>> o "status" (number) - The HTTP status code ([RFC2616], Section 6 ) >>>> generated by the origin server for this occurrence of the problem. >>>> o "detail" (string) - An human readable explanation specific to this >>>> occurrence of the problem. >>>> o "instance" (string) - An absolute URI that identifies the specific >>>> occurrence of the problem. It may or may not yield further >>>> information if dereferenced. >>> >>> Here is the corresponding example error response: >>>> HTTP/1.1 403 Forbidden >>>> Content-Type: application/problem+json >>>> Content-Language: en >>>> >>>> { >>>> "type": "http://example.com/probs/out-of-credit", >>>> "title": "You do not have enough credit.", >>>> "detail": "Your current balance is 30, but that costs 50.", >>>> "instance": "http://example.net/account/12345/msgs/abc", >>>> "balance": 30, >>>> "accounts": ["http://example.net/account/12345", >>>> "http://example.net/account/67890"] >>>> } >>> >>> Julian, what is the value of having “type” be a URI? Why not just >>> have a SCIM specific attribute (scimType) and use simple keywords? >>> (asking mainly for the WG’s benefit). I guess the strong case is that >>> by standardizing HTTP responses, client code gets simplified. >>> However, using standard attributes creates the namespace conflict >>> issue. So we need URI based error codes. >>> >>> The SCIM specs could adopt the “type”, “detail”, and “status”. We >>> would register a namespace of urn:scim:error:apil:2.0 in the SCIM >>> IANA section in addition to api:messages, schema:core, etc. This >>> would give detail error types of: >>> urn:scim:error:api:2.0:mutability, urnscim:error:api:2.0:filter, etc. >>> >>> The other items, like title, instance, etc could be optional or just >>> omitted from SCIM spec. —> we would just indicate that clients should >>> expect attributes within the JSON message other than those defined by >>> the SCIM drafts. >>> >>> IMPORTANT NOTE: the format suggested by Julian allows for only one >>> error at a time. Erik had commented he prefers to return only one. I >>> tend to agree. In the case of BULK requests, this is not really an >>> issue since each BULK operation gets its own response block. >>> >>> *_In the interests of time, any objections to using type (with URI >>> based error codes), detail, status, per above and limiting to ONE per >>> response? _* >>> >>> I know these are normative changes….however I’m pretty sure we can’t >>> avoid changes in the final document clean up whether or not we adopt >>> the proposed standardized error response. >>> >>> Cheers, >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> On Jun 24, 2014, at 12:23 PM, Julian Reschke >> > wrote: >>> >>>> On 2014-06-24 21:01, Phil Hunt wrote: >>>>> With regards to tickets 37, 46, 67, it looks like we will have some >>>>> normative changes required. I am also expecting new SCIM error >>>>> codes as >>>>> we look at the possible reasons a server might return Bad Request or >>>>> other HTTP status codes. >>>>> >>>>> Currently, the example response from PATCH, we use “error” to >>>>> indicate a >>>>> detailed error. >>>>> >>>>> * "error":"mutability"* >>>>> >>>>> From Response Codes Section, no detail error is defined: >>>>> >>>>> *HTTP/1.1 404 NOT FOUND* >>>>> >>>>> { >>>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>>> "Errors":[ >>>>> { >>>>> *"description":"Resource 2819c223-7f76-453a-919d-413861904646 >>>>> not found", >>>>> "code":"404"* >>>>> } >>>>> ] >>>>> } >>>>> >>>>> >>>>> Doing a search around Twitter, AWS, and many others, I see that “code” >>>>> is often used to indicate a detailed error message (“mutability”) and >>>>> status is used to indicate HTTP status. >>>>> >>>>> In an attempt to bring consistency across the API document, I am >>>>> proposing we use http_status and scim_code. This will help make clear >>>>> what we are referring to and allow existing implementations to co-exist >>>>> for a while (by having different names). >>>>> >>>>> _Are there any objections to normalizing the spec around following >>>>> format and attributes?_ >>>>> >>>>> Proposed example: >>>>> >>>>> *HTTP/1.1 400 Bad Request* >>>>> >>>>> Content-Type: application/scim+json;charset=UTF-8 >>>>> Cache-Control: no-store >>>>> Pragma: no-cache >>>>> >>>>> { >>>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>>> "Errors":[ >>>>> { >>>>> *“scim_code":"mutability”,* >>>>> >>>>> * “http_status”:400,* >>>>> "error_description":"Attribute 'id' is readOnly." >>>>> }, >>>>> >>>>> . . . >>>>> >>>>> ] >>>>> >>>>> } >>>>> ... >>>> >>>> You may want to read >>>> ... >>>> >>>> Best regards, Julian >>>> >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>> >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From nobody Thu Jun 26 09:20:50 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985CC1B30D7 for ; Thu, 26 Jun 2014 09:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, J_CHICKENPOX_64=0.6, MANGLED_WANT=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MguLzjbH5mem for ; Thu, 26 Jun 2014 09:20:45 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A331B311A for ; Thu, 26 Jun 2014 08:35:25 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5QFZN14016839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2014 15:35:24 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 s5QFZM6E020411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2014 15:35:22 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5QFZM9F020402; Thu, 26 Jun 2014 15:35:22 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Jun 2014 08:35:21 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: <53ABE35E.7030404@tarent.de> Date: Thu, 26 Jun 2014 08:34:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> <53A9D021.2060906@gmx.de> <71B45AEC-9B79-4F3F-A933-23B0C2AF868E@oracle.com> <53ABE35E.7030404@tarent.de> To: =?windows-1252?Q?David_M=F6bius?= X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/mJOTS8OKgVkia_5h7iIWfHDuj2I Cc: scim@ietf.org Subject: Re: [scim] [INPUT REQUESTED] Re: Detailed error and status codes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 16:20:47 -0000 1. scimType is intended to indicate many of these details. Like a unique = index conflict (e.g. =93uniqueness=94). That said, I=92m not sure it = would indicate which attribute caused the failure. Should we indicate = which attribute is not unique or which attribute has a mutability error = through another response element? 2. Why isn=92t the standard accept-langauge headers not appropriate to = localize the detail message?=20 There are also some security considerations here in cross-domain = scenarios. It is very likely that even if we mandate detail errors that = many SPs will return generic Status 400 errors to non-privledged = clients. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 26, 2014, at 2:09 AM, David M=F6bius wrote: > Hello, >=20 > I would like to adjust to add a "error group" type to the error = object. >=20 > Example: >=20 > { > =93schema=94: "urn:scim:api:messages:2.0:Error=94 > "scimGroupType" - "saving user" > "scimDetailType" - "username allready taken" > "status" - the HTTP status (should correspond to the response header) > "detail" - "The username 'marissa' is already taken" > } >=20 >=20 > The scimGroupType and the scimDetailType should never change if you do > the same mistage to make it machine readable. >=20 > Example and Reason: > I have a mask where the user can create an account. I have created my > html page the way that the user can't do "anything" wrong. The only > think the could do wrong is to use a existing username. >=20 > After I send the new user to the backend I get an exception. Since I > wan't to display the exception message in german or an other language = I > need to know what type of exception was the problem. >=20 > I would like to give the User kind of messages: >=20 > 1. The user used a given username: If this is the problem I can see it > with the help of the scimDetailType which will always be "username > already taken". >=20 > 2. It is somethink wrong with the userdata (for example a email = without > @ which I forget to check in my frontend). That something is wrong = with > the userdata in generall I can see with the "scimGroupType" >=20 > 3. Something else happens and I want to log the exception in my logs = and > give an general message to the user >=20 > In my front end it could look like >=20 > if(scimException.getScimDetailType.equals("username allready taken")){ >=20 > errorMessage =3D "in german: Your username is already taken. Plase use = a > other one." > }else if(scimException.getScimGroupType.equals("saving user")){ >=20 > errorMessage =3D "in german: Could not save your data. Please check = your > given data."; > }else{ >=20 > log.Error(scimException); > errorMessage=3D "in german: an error happen. Please try again later." > } >=20 > For this reason it would be good if we have 2 error codings in our = error > json object. What do you think about this? >=20 > by David >=20 > Am 25.06.2014 21:07, schrieb Phil Hunt: >> On the call today (Erik, Bjorn, Morteza, and myself), we discussed = the >> error issue. >>=20 >> The major concern with the draft suggested by Julian is really one of >> timing - we would prefer not to hold SCIM up. A good middle-ground >> approach is to align with the draft, but define the error fully = within >> SCIM (using the SCIM mime type and schema namespace). >>=20 >> The proposal on the call is to SCIM mime/type of = application/scim+json >> in error responses and include the SCIM error message schema = declaration. =20 >>=20 >> { >> =93schema=94: "urn:scim:api:messages:2.0:Error=94 (indicates the SCIM = message >> type) >> "scimType" - a keyword indicating the detail error (e.g. = =93mutability=94) >> "status" - the HTTP status (should correspond to the response header) >> "detail" - a detailed, human-readable message >> } >>=20 >> Servers MAY return additional attributes (e.g. ones from http-problem >> draft). The only mandatory attributes are =93schema=94 and =93status=94= . For >> example on anonymous self-registration scenarios, servers may be >> unwilling to give detail error responses for security reasons. >>=20 >> The reason for using scimType (instead of type) is to avoid any >> confusion with =93type=94 from draft-nottingham-http-problem and its >> eventual use of =93type=94. >>=20 >> In a future update to SCIM we can then transition to align with the = HTTP >> Problem draft by simply adding =93type=94 in the way it defines.=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Jun 25, 2014, at 12:25 AM, Erik Wahlstr=F6m >> > >> wrote: >>=20 >>> So that would make it look like the following right? >>>=20 >>> { >>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>> "Error": >>> { >>> "type": "urn:scim:api:error:2.0:mutability", >>> "title": =93Attribute is readOnly.", >>> "detail": =93Attribute 'id' is readOnly and can=92t be changed = in a >>> PATCH request.", >>> =93status": 400 =20 >>> } >>> } >>>=20 >>> I replaced Errors with Error. >>> Also replaced urn:scim:error:api:2.0:mutability with >>> urn:scim:api:error:2.0:mutability >>>=20 >>> That works for me. >>> / Erik >>>=20 >>>=20 >>>=20 >>> On 25 Jun 2014, at 01:30, Phil Hunt >> > wrote: >>>=20 >>>> Note: July 04 is the LAST day for us to potentially submit updates >>>> for the IETF90 meeting. This gives us about 1.5 weeks to close off >>>> the error issues and update the drafts. If you have a moment = please >>>> take a look and comment as soon as possible... >>>>=20 >>>> Julian thanks for the suggestion. For the rest of the group=92s >>>> benefit, the draft Julian referenced suggests the following >>>> attributes be returned in a standardized detailed error JSON body=85 >>>>=20 >>>>> A problem details object MAY have the following members: >>>>>=20 >>>>> o "type" (string) - An absolute URI [RFC3986 = ] that identifies the >>>>> problem type. When dereferenced, it SHOULD provide = human-readable >>>>> documentation for the problem type (e.g., using HTML >>>>> [W3C.REC-html401-19991224 = ]). When this member is not present, its >>>>> value is assumed to be "about:blank". >>>>> o "title" (string) - A short, human-readable summary of the = problem >>>>> type. It SHOULD NOT change from occurrence to occurrence of = the >>>>> problem, except for purposes of localisation. >>>>> o "status" (number) - The HTTP status code ([RFC2616], Section = 6 ) >>>>> generated by the origin server for this occurrence of the = problem. >>>>> o "detail" (string) - An human readable explanation specific to = this >>>>> occurrence of the problem. >>>>> o "instance" (string) - An absolute URI that identifies the = specific >>>>> occurrence of the problem. It may or may not yield further >>>>> information if dereferenced. >>>>=20 >>>> Here is the corresponding example error response: >>>>> HTTP/1.1 403 Forbidden >>>>> Content-Type: application/problem+json >>>>> Content-Language: en >>>>>=20 >>>>> { >>>>> "type": "http://example.com/probs/out-of-credit", >>>>> "title": "You do not have enough credit.", >>>>> "detail": "Your current balance is 30, but that costs 50.", >>>>> "instance": "http://example.net/account/12345/msgs/abc", >>>>> "balance": 30, >>>>> "accounts": ["http://example.net/account/12345", >>>>> "http://example.net/account/67890"] >>>>> } >>>>=20 >>>> Julian, what is the value of having =93type=94 be a URI? Why not = just >>>> have a SCIM specific attribute (scimType) and use simple keywords? >>>> (asking mainly for the WG=92s benefit). I guess the strong case is = that >>>> by standardizing HTTP responses, client code gets simplified. >>>> However, using standard attributes creates the namespace conflict >>>> issue. So we need URI based error codes. >>>>=20 >>>> The SCIM specs could adopt the =93type=94, =93detail=94, and = =93status=94. We >>>> would register a namespace of urn:scim:error:apil:2.0 in the SCIM >>>> IANA section in addition to api:messages, schema:core, etc. This >>>> would give detail error types of: >>>> urn:scim:error:api:2.0:mutability, urnscim:error:api:2.0:filter, = etc. >>>>=20 >>>> The other items, like title, instance, etc could be optional or = just >>>> omitted from SCIM spec. =97> we would just indicate that clients = should >>>> expect attributes within the JSON message other than those defined = by >>>> the SCIM drafts. >>>>=20 >>>> IMPORTANT NOTE: the format suggested by Julian allows for only one >>>> error at a time. Erik had commented he prefers to return only one. = I >>>> tend to agree. In the case of BULK requests, this is not really an >>>> issue since each BULK operation gets its own response block. >>>>=20 >>>> *_In the interests of time, any objections to using type (with URI >>>> based error codes), detail, status, per above and limiting to ONE = per >>>> response? _* >>>>=20 >>>> I know these are normative changes=85.however I=92m pretty sure we = can=92t >>>> avoid changes in the final document clean up whether or not we = adopt >>>> the proposed standardized error response. >>>>=20 >>>> Cheers, >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>> On Jun 24, 2014, at 12:23 PM, Julian Reschke >>> > wrote: >>>>=20 >>>>> On 2014-06-24 21:01, Phil Hunt wrote: >>>>>> With regards to tickets 37, 46, 67, it looks like we will have = some >>>>>> normative changes required. I am also expecting new SCIM error >>>>>> codes as >>>>>> we look at the possible reasons a server might return Bad Request = or >>>>>> other HTTP status codes. >>>>>>=20 >>>>>> Currently, the example response from PATCH, we use =93error=94 to >>>>>> indicate a >>>>>> detailed error. >>>>>>=20 >>>>>> * "error":"mutability"* >>>>>>=20 >>>>>> =46rom Response Codes Section, no detail error is defined: >>>>>>=20 >>>>>> *HTTP/1.1 404 NOT FOUND* >>>>>>=20 >>>>>> { >>>>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>>>> "Errors":[ >>>>>> { >>>>>> *"description":"Resource = 2819c223-7f76-453a-919d-413861904646 >>>>>> not found", >>>>>> "code":"404"* >>>>>> } >>>>>> ] >>>>>> } >>>>>>=20 >>>>>>=20 >>>>>> Doing a search around Twitter, AWS, and many others, I see that = =93code=94 >>>>>> is often used to indicate a detailed error message (=93mutability=94= ) and >>>>>> status is used to indicate HTTP status. >>>>>>=20 >>>>>> In an attempt to bring consistency across the API document, I am >>>>>> proposing we use http_status and scim_code. This will help make = clear >>>>>> what we are referring to and allow existing implementations to = co-exist >>>>>> for a while (by having different names). >>>>>>=20 >>>>>> _Are there any objections to normalizing the spec around = following >>>>>> format and attributes?_ >>>>>>=20 >>>>>> Proposed example: >>>>>>=20 >>>>>> *HTTP/1.1 400 Bad Request* >>>>>>=20 >>>>>> Content-Type: application/scim+json;charset=3DUTF-8 >>>>>> Cache-Control: no-store >>>>>> Pragma: no-cache >>>>>>=20 >>>>>> { >>>>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>>>> "Errors":[ >>>>>> { >>>>>> *=93scim_code":"mutability=94,* >>>>>>=20 >>>>>> * =93http_status=94:400,* >>>>>> "error_description":"Attribute 'id' is readOnly." >>>>>> }, >>>>>>=20 >>>>>> . . . >>>>>>=20 >>>>>> ] >>>>>>=20 >>>>>> } >>>>>> ... >>>>>=20 >>>>> You may want to read >>>>> ... >>>>>=20 >>>>> Best regards, Julian >>>>>=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 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >>=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Fri Jun 27 01:32:39 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BCC1B318B for ; Fri, 27 Jun 2014 01:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.2 X-Spam-Level: * X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, J_CHICKENPOX_64=0.6, MANGLED_WANT=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_1xuD4IP3kX for ; Fri, 27 Jun 2014 01:32:35 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9351B3184 for ; Fri, 27 Jun 2014 01:32:34 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so2393079wib.0 for ; Fri, 27 Jun 2014 01:32:33 -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 :content-transfer-encoding; bh=jugjN60AS6YivccDBCgIfZ1S5u59HYTKLg7PrDBSV9Q=; b=SMp3RXe/yi4i75IdFFEaaRzdgPwQ8j/9OqAPBIKUpWPr6rsycR3x4V5iP/1c7OgYv+ V6heTjbBMDYJj3bJaLS6yfYkmkgUuBvrAJmSci/qwtzQD6txGoTKn5JQGq10zhHOf6Rm 25qkUM4Vd/0EZ7LroUzFDtBvCweagrPHuDxzV60zWfw/7luJ42/9CMA9b+DagbQQjA26 t4BBENnNcLaafAx97QdDkpQ0vDQHWfMiNN8CM67/VwYe283uhVF7ny5JRrn5ywlqycB3 s5bnZR5MK96NW9mBSeBh3v5C9sYSdC1+h2eZW/Oi8yCJ2MwNlaFVL5lwpeZIkjQqoXFU +Jrg== X-Gm-Message-State: ALoCoQkv0Cb5DwUNwbSTjZAikCQj+tVzzg14ICIZ0Iwve1ADoaWGIs6pUYQ1VzJ6/OBj71Sk1Qqd X-Received: by 10.180.207.48 with SMTP id lt16mr10260080wic.32.1403857953310; Fri, 27 Jun 2014 01:32:33 -0700 (PDT) Received: from [172.24.12.173] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id 20sm18063816wjt.42.2014.06.27.01.32.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 01:32:32 -0700 (PDT) Message-ID: <53AD2C1F.6090607@tarent.de> Date: Fri, 27 Jun 2014 10:32:31 +0200 From: =?windows-1252?Q?David_M=F6bius?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Phil Hunt References: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> <53A9D021.2060906@gmx.de> <71B45AEC-9B79-4F3F-A933-23B0C2AF868E@oracle.com> <53ABE35E.7030404@tarent.de> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/kJ3TU03FP0WU9qEFnPhzkyXYJZ8 Cc: scim@ietf.org Subject: Re: [scim] [INPUT REQUESTED] Re: Detailed error and status codes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 08:32:38 -0000 scimType is good, I just think that another type would be great. The names themself are not important for me. I think to generate a Exception message in the needed language would not be a part of the server. Every client should create their own exception messages. This way it is easy to translate my homepage to an other language. The scim server should only create exception messages in one standard language which would be english. Am 26.06.2014 17:34, schrieb Phil Hunt: > 1. scimType is intended to indicate many of these details. Like a unique index conflict (e.g. “uniqueness”). That said, I’m not sure it would indicate which attribute caused the failure. Should we indicate which attribute is not unique or which attribute has a mutability error through another response element? > > 2. Why isn’t the standard accept-langauge headers not appropriate to localize the detail message? > > There are also some security considerations here in cross-domain scenarios. It is very likely that even if we mandate detail errors that many SPs will return generic Status 400 errors to non-privledged clients. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Jun 26, 2014, at 2:09 AM, David Möbius wrote: > >> Hello, >> >> I would like to adjust to add a "error group" type to the error object. >> >> Example: >> >> { >> “schema”: "urn:scim:api:messages:2.0:Error” >> "scimGroupType" - "saving user" >> "scimDetailType" - "username allready taken" >> "status" - the HTTP status (should correspond to the response header) >> "detail" - "The username 'marissa' is already taken" >> } >> >> >> The scimGroupType and the scimDetailType should never change if you do >> the same mistage to make it machine readable. >> >> Example and Reason: >> I have a mask where the user can create an account. I have created my >> html page the way that the user can't do "anything" wrong. The only >> think the could do wrong is to use a existing username. >> >> After I send the new user to the backend I get an exception. Since I >> wan't to display the exception message in german or an other language I >> need to know what type of exception was the problem. >> >> I would like to give the User kind of messages: >> >> 1. The user used a given username: If this is the problem I can see it >> with the help of the scimDetailType which will always be "username >> already taken". >> >> 2. It is somethink wrong with the userdata (for example a email without >> @ which I forget to check in my frontend). That something is wrong with >> the userdata in generall I can see with the "scimGroupType" >> >> 3. Something else happens and I want to log the exception in my logs and >> give an general message to the user >> >> In my front end it could look like >> >> if(scimException.getScimDetailType.equals("username allready taken")){ >> >> errorMessage = "in german: Your username is already taken. Plase use a >> other one." >> }else if(scimException.getScimGroupType.equals("saving user")){ >> >> errorMessage = "in german: Could not save your data. Please check your >> given data."; >> }else{ >> >> log.Error(scimException); >> errorMessage= "in german: an error happen. Please try again later." >> } >> >> For this reason it would be good if we have 2 error codings in our error >> json object. What do you think about this? >> >> by David >> >> Am 25.06.2014 21:07, schrieb Phil Hunt: >>> On the call today (Erik, Bjorn, Morteza, and myself), we discussed the >>> error issue. >>> >>> The major concern with the draft suggested by Julian is really one of >>> timing - we would prefer not to hold SCIM up. A good middle-ground >>> approach is to align with the draft, but define the error fully within >>> SCIM (using the SCIM mime type and schema namespace). >>> >>> The proposal on the call is to SCIM mime/type of application/scim+json >>> in error responses and include the SCIM error message schema declaration. >>> >>> { >>> “schema”: "urn:scim:api:messages:2.0:Error” (indicates the SCIM message >>> type) >>> "scimType" - a keyword indicating the detail error (e.g. “mutability”) >>> "status" - the HTTP status (should correspond to the response header) >>> "detail" - a detailed, human-readable message >>> } >>> >>> Servers MAY return additional attributes (e.g. ones from http-problem >>> draft). The only mandatory attributes are “schema” and “status”. For >>> example on anonymous self-registration scenarios, servers may be >>> unwilling to give detail error responses for security reasons. >>> >>> The reason for using scimType (instead of type) is to avoid any >>> confusion with “type” from draft-nottingham-http-problem and its >>> eventual use of “type”. >>> >>> In a future update to SCIM we can then transition to align with the HTTP >>> Problem draft by simply adding “type” in the way it defines. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> On Jun 25, 2014, at 12:25 AM, Erik Wahlström >>> > >>> wrote: >>> >>>> So that would make it look like the following right? >>>> >>>> { >>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>> "Error": >>>> { >>>> "type": "urn:scim:api:error:2.0:mutability", >>>> "title": “Attribute is readOnly.", >>>> "detail": “Attribute 'id' is readOnly and can’t be changed in a >>>> PATCH request.", >>>> “status": 400 >>>> } >>>> } >>>> >>>> I replaced Errors with Error. >>>> Also replaced urn:scim:error:api:2.0:mutability with >>>> urn:scim:api:error:2.0:mutability >>>> >>>> That works for me. >>>> / Erik >>>> >>>> >>>> >>>> On 25 Jun 2014, at 01:30, Phil Hunt >>> > wrote: >>>> >>>>> Note: July 04 is the LAST day for us to potentially submit updates >>>>> for the IETF90 meeting. This gives us about 1.5 weeks to close off >>>>> the error issues and update the drafts. If you have a moment please >>>>> take a look and comment as soon as possible... >>>>> >>>>> Julian thanks for the suggestion. For the rest of the group’s >>>>> benefit, the draft Julian referenced suggests the following >>>>> attributes be returned in a standardized detailed error JSON body… >>>>> >>>>>> A problem details object MAY have the following members: >>>>>> >>>>>> o "type" (string) - An absolute URI [RFC3986 ] that identifies the >>>>>> problem type. When dereferenced, it SHOULD provide human-readable >>>>>> documentation for the problem type (e.g., using HTML >>>>>> [W3C.REC-html401-19991224 ]). When this member is not present, its >>>>>> value is assumed to be "about:blank". >>>>>> o "title" (string) - A short, human-readable summary of the problem >>>>>> type. It SHOULD NOT change from occurrence to occurrence of the >>>>>> problem, except for purposes of localisation. >>>>>> o "status" (number) - The HTTP status code ([RFC2616], Section 6 ) >>>>>> generated by the origin server for this occurrence of the problem. >>>>>> o "detail" (string) - An human readable explanation specific to this >>>>>> occurrence of the problem. >>>>>> o "instance" (string) - An absolute URI that identifies the specific >>>>>> occurrence of the problem. It may or may not yield further >>>>>> information if dereferenced. >>>>> >>>>> Here is the corresponding example error response: >>>>>> HTTP/1.1 403 Forbidden >>>>>> Content-Type: application/problem+json >>>>>> Content-Language: en >>>>>> >>>>>> { >>>>>> "type": "http://example.com/probs/out-of-credit", >>>>>> "title": "You do not have enough credit.", >>>>>> "detail": "Your current balance is 30, but that costs 50.", >>>>>> "instance": "http://example.net/account/12345/msgs/abc", >>>>>> "balance": 30, >>>>>> "accounts": ["http://example.net/account/12345", >>>>>> "http://example.net/account/67890"] >>>>>> } >>>>> >>>>> Julian, what is the value of having “type” be a URI? Why not just >>>>> have a SCIM specific attribute (scimType) and use simple keywords? >>>>> (asking mainly for the WG’s benefit). I guess the strong case is that >>>>> by standardizing HTTP responses, client code gets simplified. >>>>> However, using standard attributes creates the namespace conflict >>>>> issue. So we need URI based error codes. >>>>> >>>>> The SCIM specs could adopt the “type”, “detail”, and “status”. We >>>>> would register a namespace of urn:scim:error:apil:2.0 in the SCIM >>>>> IANA section in addition to api:messages, schema:core, etc. This >>>>> would give detail error types of: >>>>> urn:scim:error:api:2.0:mutability, urnscim:error:api:2.0:filter, etc. >>>>> >>>>> The other items, like title, instance, etc could be optional or just >>>>> omitted from SCIM spec. —> we would just indicate that clients should >>>>> expect attributes within the JSON message other than those defined by >>>>> the SCIM drafts. >>>>> >>>>> IMPORTANT NOTE: the format suggested by Julian allows for only one >>>>> error at a time. Erik had commented he prefers to return only one. I >>>>> tend to agree. In the case of BULK requests, this is not really an >>>>> issue since each BULK operation gets its own response block. >>>>> >>>>> *_In the interests of time, any objections to using type (with URI >>>>> based error codes), detail, status, per above and limiting to ONE per >>>>> response? _* >>>>> >>>>> I know these are normative changes….however I’m pretty sure we can’t >>>>> avoid changes in the final document clean up whether or not we adopt >>>>> the proposed standardized error response. >>>>> >>>>> Cheers, >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> On Jun 24, 2014, at 12:23 PM, Julian Reschke >>>> > wrote: >>>>> >>>>>> On 2014-06-24 21:01, Phil Hunt wrote: >>>>>>> With regards to tickets 37, 46, 67, it looks like we will have some >>>>>>> normative changes required. I am also expecting new SCIM error >>>>>>> codes as >>>>>>> we look at the possible reasons a server might return Bad Request or >>>>>>> other HTTP status codes. >>>>>>> >>>>>>> Currently, the example response from PATCH, we use “error” to >>>>>>> indicate a >>>>>>> detailed error. >>>>>>> >>>>>>> * "error":"mutability"* >>>>>>> >>>>>>> From Response Codes Section, no detail error is defined: >>>>>>> >>>>>>> *HTTP/1.1 404 NOT FOUND* >>>>>>> >>>>>>> { >>>>>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>>>>> "Errors":[ >>>>>>> { >>>>>>> *"description":"Resource 2819c223-7f76-453a-919d-413861904646 >>>>>>> not found", >>>>>>> "code":"404"* >>>>>>> } >>>>>>> ] >>>>>>> } >>>>>>> >>>>>>> >>>>>>> Doing a search around Twitter, AWS, and many others, I see that “code” >>>>>>> is often used to indicate a detailed error message (“mutability”) and >>>>>>> status is used to indicate HTTP status. >>>>>>> >>>>>>> In an attempt to bring consistency across the API document, I am >>>>>>> proposing we use http_status and scim_code. This will help make clear >>>>>>> what we are referring to and allow existing implementations to co-exist >>>>>>> for a while (by having different names). >>>>>>> >>>>>>> _Are there any objections to normalizing the spec around following >>>>>>> format and attributes?_ >>>>>>> >>>>>>> Proposed example: >>>>>>> >>>>>>> *HTTP/1.1 400 Bad Request* >>>>>>> >>>>>>> Content-Type: application/scim+json;charset=UTF-8 >>>>>>> Cache-Control: no-store >>>>>>> Pragma: no-cache >>>>>>> >>>>>>> { >>>>>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>>>>> "Errors":[ >>>>>>> { >>>>>>> *“scim_code":"mutability”,* >>>>>>> >>>>>>> * “http_status”:400,* >>>>>>> "error_description":"Attribute 'id' is readOnly." >>>>>>> }, >>>>>>> >>>>>>> . . . >>>>>>> >>>>>>> ] >>>>>>> >>>>>>> } >>>>>>> ... >>>>>> >>>>>> You may want to read >>>>>> ... >>>>>> >>>>>> Best regards, Julian >>>>>> >>>>>> _______________________________________________ >>>>>> 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 nobody Fri Jun 27 11:36:09 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEED1B2900 for ; Fri, 27 Jun 2014 11:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, J_CHICKENPOX_64=0.6, MANGLED_WANT=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q1TtZ_m2xcG for ; Fri, 27 Jun 2014 11:36:03 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21C01B28AB for ; Fri, 27 Jun 2014 11:36:03 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5RIa2wh020941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Jun 2014 18:36:02 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5RIa0wT012988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2014 18:36:01 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5RIZxFd006343; Fri, 27 Jun 2014 18:36:00 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 27 Jun 2014 11:35:58 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: <53AD2C1F.6090607@tarent.de> Date: Fri, 27 Jun 2014 11:35:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0094CEA3-E5AE-487C-B85C-14F0500C941C@oracle.com> References: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> <53A9D021.2060906@gmx.de> <71B45AEC-9B79-4F3F-A933-23B0C2AF868E@oracle.com> <53ABE35E.7030404@tarent.de> <53AD2C1F.6090607@tarent.de> To: =?windows-1252?Q?David_M=F6bius?= X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/nPbO4gthFipeRVvzxZUfVsnIjEI Cc: scim@ietf.org Subject: Re: [scim] [INPUT REQUESTED] Re: Detailed error and status codes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 18:36:07 -0000 David, The problem with going to more specific error code granularity is that = most of these codes would seem to fall outside the protocol and schema = specs themselves and depend very much on the context of the application = being built using SCIM or upon the provisioning system that backs the = SCIM API. I think I am clear on why you need them. I am less clear on why every = service provider should support an enhanced level of signalling or even = if it is possible they can. Can you provide a list of this error code detail you would like to see? Any other thoughts here? Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 27, 2014, at 1:32 AM, David M=F6bius wrote: > scimType is good, I just think that another type would be great. The > names themself are not important for me. >=20 > I think to generate a Exception message in the needed language would = not > be a part of the server. Every client should create their own = exception > messages. This way it is easy to translate my homepage to an other > language. The scim server should only create exception messages in one > standard language which would be english. >=20 > Am 26.06.2014 17:34, schrieb Phil Hunt: >> 1. scimType is intended to indicate many of these details. Like a = unique index conflict (e.g. =93uniqueness=94). That said, I=92m not = sure it would indicate which attribute caused the failure. Should we = indicate which attribute is not unique or which attribute has a = mutability error through another response element? >>=20 >> 2. Why isn=92t the standard accept-langauge headers not appropriate = to localize the detail message?=20 >>=20 >> There are also some security considerations here in cross-domain = scenarios. It is very likely that even if we mandate detail errors that = many SPs will return generic Status 400 errors to non-privledged = clients. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Jun 26, 2014, at 2:09 AM, David M=F6bius = wrote: >>=20 >>> Hello, >>>=20 >>> I would like to adjust to add a "error group" type to the error = object. >>>=20 >>> Example: >>>=20 >>> { >>> =93schema=94: "urn:scim:api:messages:2.0:Error=94 >>> "scimGroupType" - "saving user" >>> "scimDetailType" - "username allready taken" >>> "status" - the HTTP status (should correspond to the response = header) >>> "detail" - "The username 'marissa' is already taken" >>> } >>>=20 >>>=20 >>> The scimGroupType and the scimDetailType should never change if you = do >>> the same mistage to make it machine readable. >>>=20 >>> Example and Reason: >>> I have a mask where the user can create an account. I have created = my >>> html page the way that the user can't do "anything" wrong. The only >>> think the could do wrong is to use a existing username. >>>=20 >>> After I send the new user to the backend I get an exception. Since I >>> wan't to display the exception message in german or an other = language I >>> need to know what type of exception was the problem. >>>=20 >>> I would like to give the User kind of messages: >>>=20 >>> 1. The user used a given username: If this is the problem I can see = it >>> with the help of the scimDetailType which will always be "username >>> already taken". >>>=20 >>> 2. It is somethink wrong with the userdata (for example a email = without >>> @ which I forget to check in my frontend). That something is wrong = with >>> the userdata in generall I can see with the "scimGroupType" >>>=20 >>> 3. Something else happens and I want to log the exception in my logs = and >>> give an general message to the user >>>=20 >>> In my front end it could look like >>>=20 >>> if(scimException.getScimDetailType.equals("username allready = taken")){ >>>=20 >>> errorMessage =3D "in german: Your username is already taken. Plase = use a >>> other one." >>> }else if(scimException.getScimGroupType.equals("saving user")){ >>>=20 >>> errorMessage =3D "in german: Could not save your data. Please check = your >>> given data."; >>> }else{ >>>=20 >>> log.Error(scimException); >>> errorMessage=3D "in german: an error happen. Please try again = later." >>> } >>>=20 >>> For this reason it would be good if we have 2 error codings in our = error >>> json object. What do you think about this? >>>=20 >>> by David >>>=20 >>> Am 25.06.2014 21:07, schrieb Phil Hunt: >>>> On the call today (Erik, Bjorn, Morteza, and myself), we discussed = the >>>> error issue. >>>>=20 >>>> The major concern with the draft suggested by Julian is really one = of >>>> timing - we would prefer not to hold SCIM up. A good middle-ground >>>> approach is to align with the draft, but define the error fully = within >>>> SCIM (using the SCIM mime type and schema namespace). >>>>=20 >>>> The proposal on the call is to SCIM mime/type of = application/scim+json >>>> in error responses and include the SCIM error message schema = declaration. =20 >>>>=20 >>>> { >>>> =93schema=94: "urn:scim:api:messages:2.0:Error=94 (indicates the = SCIM message >>>> type) >>>> "scimType" - a keyword indicating the detail error (e.g. = =93mutability=94) >>>> "status" - the HTTP status (should correspond to the response = header) >>>> "detail" - a detailed, human-readable message >>>> } >>>>=20 >>>> Servers MAY return additional attributes (e.g. ones from = http-problem >>>> draft). The only mandatory attributes are =93schema=94 and = =93status=94. For >>>> example on anonymous self-registration scenarios, servers may be >>>> unwilling to give detail error responses for security reasons. >>>>=20 >>>> The reason for using scimType (instead of type) is to avoid any >>>> confusion with =93type=94 from draft-nottingham-http-problem and = its >>>> eventual use of =93type=94. >>>>=20 >>>> In a future update to SCIM we can then transition to align with the = HTTP >>>> Problem draft by simply adding =93type=94 in the way it defines.=20 >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>> On Jun 25, 2014, at 12:25 AM, Erik Wahlstr=F6m >>>> > >>>> wrote: >>>>=20 >>>>> So that would make it look like the following right? >>>>>=20 >>>>> { >>>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>>> "Error": >>>>> { >>>>> "type": "urn:scim:api:error:2.0:mutability", >>>>> "title": =93Attribute is readOnly.", >>>>> "detail": =93Attribute 'id' is readOnly and can=92t be changed = in a >>>>> PATCH request.", >>>>> =93status": 400 =20 >>>>> } >>>>> } >>>>>=20 >>>>> I replaced Errors with Error. >>>>> Also replaced urn:scim:error:api:2.0:mutability with >>>>> urn:scim:api:error:2.0:mutability >>>>>=20 >>>>> That works for me. >>>>> / Erik >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 25 Jun 2014, at 01:30, Phil Hunt >>>> > wrote: >>>>>=20 >>>>>> Note: July 04 is the LAST day for us to potentially submit = updates >>>>>> for the IETF90 meeting. This gives us about 1.5 weeks to close = off >>>>>> the error issues and update the drafts. If you have a moment = please >>>>>> take a look and comment as soon as possible... >>>>>>=20 >>>>>> Julian thanks for the suggestion. For the rest of the group=92s >>>>>> benefit, the draft Julian referenced suggests the following >>>>>> attributes be returned in a standardized detailed error JSON = body=85 >>>>>>=20 >>>>>>> A problem details object MAY have the following members: >>>>>>>=20 >>>>>>> o "type" (string) - An absolute URI [RFC3986 = ] that identifies the >>>>>>> problem type. When dereferenced, it SHOULD provide = human-readable >>>>>>> documentation for the problem type (e.g., using HTML >>>>>>> [W3C.REC-html401-19991224 = ]). When this member is not present, its >>>>>>> value is assumed to be "about:blank". >>>>>>> o "title" (string) - A short, human-readable summary of the = problem >>>>>>> type. It SHOULD NOT change from occurrence to occurrence of = the >>>>>>> problem, except for purposes of localisation. >>>>>>> o "status" (number) - The HTTP status code ([RFC2616], Section = 6 ) >>>>>>> generated by the origin server for this occurrence of the = problem. >>>>>>> o "detail" (string) - An human readable explanation specific = to this >>>>>>> occurrence of the problem. >>>>>>> o "instance" (string) - An absolute URI that identifies the = specific >>>>>>> occurrence of the problem. It may or may not yield further >>>>>>> information if dereferenced. >>>>>>=20 >>>>>> Here is the corresponding example error response: >>>>>>> HTTP/1.1 403 Forbidden >>>>>>> Content-Type: application/problem+json >>>>>>> Content-Language: en >>>>>>>=20 >>>>>>> { >>>>>>> "type": "http://example.com/probs/out-of-credit", >>>>>>> "title": "You do not have enough credit.", >>>>>>> "detail": "Your current balance is 30, but that costs 50.", >>>>>>> "instance": "http://example.net/account/12345/msgs/abc", >>>>>>> "balance": 30, >>>>>>> "accounts": ["http://example.net/account/12345", >>>>>>> "http://example.net/account/67890"] >>>>>>> } >>>>>>=20 >>>>>> Julian, what is the value of having =93type=94 be a URI? Why not = just >>>>>> have a SCIM specific attribute (scimType) and use simple = keywords? >>>>>> (asking mainly for the WG=92s benefit). I guess the strong case = is that >>>>>> by standardizing HTTP responses, client code gets simplified. >>>>>> However, using standard attributes creates the namespace conflict >>>>>> issue. So we need URI based error codes. >>>>>>=20 >>>>>> The SCIM specs could adopt the =93type=94, =93detail=94, and = =93status=94. We >>>>>> would register a namespace of urn:scim:error:apil:2.0 in the SCIM >>>>>> IANA section in addition to api:messages, schema:core, etc. This >>>>>> would give detail error types of: >>>>>> urn:scim:error:api:2.0:mutability, urnscim:error:api:2.0:filter, = etc. >>>>>>=20 >>>>>> The other items, like title, instance, etc could be optional or = just >>>>>> omitted from SCIM spec. =97> we would just indicate that clients = should >>>>>> expect attributes within the JSON message other than those = defined by >>>>>> the SCIM drafts. >>>>>>=20 >>>>>> IMPORTANT NOTE: the format suggested by Julian allows for only = one >>>>>> error at a time. Erik had commented he prefers to return only = one. I >>>>>> tend to agree. In the case of BULK requests, this is not really = an >>>>>> issue since each BULK operation gets its own response block. >>>>>>=20 >>>>>> *_In the interests of time, any objections to using type (with = URI >>>>>> based error codes), detail, status, per above and limiting to ONE = per >>>>>> response? _* >>>>>>=20 >>>>>> I know these are normative changes=85.however I=92m pretty sure = we can=92t >>>>>> avoid changes in the final document clean up whether or not we = adopt >>>>>> the proposed standardized error response. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Jun 24, 2014, at 12:23 PM, Julian Reschke = >>>>> > wrote: >>>>>>=20 >>>>>>> On 2014-06-24 21:01, Phil Hunt wrote: >>>>>>>> With regards to tickets 37, 46, 67, it looks like we will have = some >>>>>>>> normative changes required. I am also expecting new SCIM error >>>>>>>> codes as >>>>>>>> we look at the possible reasons a server might return Bad = Request or >>>>>>>> other HTTP status codes. >>>>>>>>=20 >>>>>>>> Currently, the example response from PATCH, we use =93error=94 = to >>>>>>>> indicate a >>>>>>>> detailed error. >>>>>>>>=20 >>>>>>>> * "error":"mutability"* >>>>>>>>=20 >>>>>>>> =46rom Response Codes Section, no detail error is defined: >>>>>>>>=20 >>>>>>>> *HTTP/1.1 404 NOT FOUND* >>>>>>>>=20 >>>>>>>> { >>>>>>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>>>>>> "Errors":[ >>>>>>>> { >>>>>>>> *"description":"Resource = 2819c223-7f76-453a-919d-413861904646 >>>>>>>> not found", >>>>>>>> "code":"404"* >>>>>>>> } >>>>>>>> ] >>>>>>>> } >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Doing a search around Twitter, AWS, and many others, I see that = =93code=94 >>>>>>>> is often used to indicate a detailed error message = (=93mutability=94) and >>>>>>>> status is used to indicate HTTP status. >>>>>>>>=20 >>>>>>>> In an attempt to bring consistency across the API document, I = am >>>>>>>> proposing we use http_status and scim_code. This will help make = clear >>>>>>>> what we are referring to and allow existing implementations to = co-exist >>>>>>>> for a while (by having different names). >>>>>>>>=20 >>>>>>>> _Are there any objections to normalizing the spec around = following >>>>>>>> format and attributes?_ >>>>>>>>=20 >>>>>>>> Proposed example: >>>>>>>>=20 >>>>>>>> *HTTP/1.1 400 Bad Request* >>>>>>>>=20 >>>>>>>> Content-Type: application/scim+json;charset=3DUTF-8 >>>>>>>> Cache-Control: no-store >>>>>>>> Pragma: no-cache >>>>>>>>=20 >>>>>>>> { >>>>>>>> "schemas": ["urn:scim:api:messages:2.0:Error"], >>>>>>>> "Errors":[ >>>>>>>> { >>>>>>>> *=93scim_code":"mutability=94,* >>>>>>>>=20 >>>>>>>> * =93http_status=94:400,* >>>>>>>> "error_description":"Attribute 'id' is readOnly." >>>>>>>> }, >>>>>>>>=20 >>>>>>>> . . . >>>>>>>>=20 >>>>>>>> ] >>>>>>>>=20 >>>>>>>> } >>>>>>>> ... >>>>>>>=20 >>>>>>> You may want to read >>>>>>> ... >>>>>>>=20 >>>>>>> Best regards, Julian >>>>>>>=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 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 From nobody Fri Jun 27 11:47:25 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8B01B27B9 for ; Fri, 27 Jun 2014 11:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtuUGyrZ2P74 for ; Fri, 27 Jun 2014 11:47:21 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181251B28CE for ; Fri, 27 Jun 2014 11:47:21 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5RIlIEk020568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 27 Jun 2014 18:47:19 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 s5RIlHYX017495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jun 2014 18:47:18 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5RIlHD0005635 for ; Fri, 27 Jun 2014 18:47:17 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 27 Jun 2014 11:47:17 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_F0A392CB-C571-4724-A060-8DC56AD9B97B" Message-Id: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> Date: Fri, 27 Jun 2014 11:47:17 -0700 To: Scim WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/FniIPm_7LFEn8Om3enRquWzXbNE Subject: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 18:47:23 -0000 --Apple-Mail=_F0A392CB-C571-4724-A060-8DC56AD9B97B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii After reviewing the API and Schema docs, here is a first cut of the = detailed error codes. For HTTP Status 400 (Bad Request) responses, the following detail error types are defined: +--------------+------------------------------+---------------------+ | scimType | Description | Applicability | +--------------+------------------------------+---------------------+ | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | | r | was invalid (does not comply | POST (Search - | | | with Figure 1) or the | Section 3.2.3), | | | specified attribute and | PATCH (Path Filter | | | filter comparison | - Section 3.3.2) | | | combination is not | | | | supported. | | | uniqueness | One or more of attribute | POST (Create - | | | values is already in use or | Section 3.1), PUT | | | is reserved. | (Section 3.3.1), | | | | PATCH (Section | | | | 3.3.2) | | mutability | The attempted modification | PUT (Section | | | is not compatible with the | 3.3.1), PATCH | | | target attributes mutability | (Section 3.3.2) | | | or current state (e.g. | | | | modification of an immutable | | | | attribute with an existing | | | | value). | | | invalidSynta | The request body message | POST (Search - | | x | structure was invalid or did | Section 3.2.2, | | | not conform to the request | Create - Section | | | schema. | 3.1, Bulk - Section | | | | 3.5), PUT (Section | | | | 3.3.1) | | invalidPath | The path attribute was | PATCH (Section | | | invalid or malformed (see | 3.3.2) | | | Figure 4). | | | noTarget | The specified "path" did not | PATCH (Section | | | yield an attribute or | 3.3.2) | | | attribute value that could | | | | be operated on. This occurs | | | | when the specified "path" | | | | value contains a filter that | | | | yields no match. | | | invalidValue | A required value was | GET (Section | | | missing, or the value | 3.2.2), POST | | | specified was not compatible | (Create - Section | | | with the operation or | 3.1, Search - | | | attribute type (see Section | Section 3.2.2), PUT | | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | | | ma]). | PATCH (Section | | | | 3.3.2) | | invalidVers | The specified API version is | GET (Section | | | not supported (see Section | 3.2.2), POST (ALL), | | | 3.11). | PUT (Section | | | | 3.3.1), PATCH | | | | (Section 3.3.2), | | | | DELETE (Section | | | | 3.4) | +--------------+------------------------------+---------------------+ I plan to put these into draft 07 of the API and will publish over the = weekend. As always, feedback welcome! Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_F0A392CB-C571-4724-A060-8DC56AD9B97B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii After = reviewing the API and Schema docs, here is a first cut of the detailed = error codes.

For HTTP Status 400 (Bad Request) responses, the =
following detail
   error types are defined:

+--------------+------------------------------+---------------------+
| scimType     | Description                  | Applicability       |
+--------------+------------------------------+---------------------+
| invalidFilte | The specified filter syntax  | GET(Section 3.2.2), |
| r            | was invalid (does not comply | POST (Search -      |
|              | with Figure 1) or the        | Section 3.2.3),     |
|              | specified attribute and      | PATCH (Path Filter  |
|              | filter comparison            | - Section 3.3.2)    |
|              | combination is not           |                     |
|              | supported.                   |                     |
| uniqueness   | One or more of attribute     | POST (Create -      |
|              | values is already in use or  | Section 3.1), PUT   |
|              | is reserved.                 | (Section 3.3.1),    |
|              |                              | PATCH (Section      |
|              |                              | 3.3.2)              |
| mutability   | The attempted modification   | PUT (Section        |
|              | is not compatible with the   | 3.3.1), PATCH       |
|              | target attributes mutability | (Section 3.3.2)     |
|              | or current state (e.g.       |                     |
|              | modification of an immutable |                     |
|              | attribute with an existing   |                     |
|              | value).                      |                     |
| invalidSynta | The request body message     | POST (Search -      |
| x            | structure was invalid or did | Section 3.2.2,      |
|              | not conform to the request   | Create - Section    |
|              | schema.                      | 3.1, Bulk - Section |
|              |                              | 3.5), PUT (Section  |
|              |                              | 3.3.1)              |
| invalidPath  | The path attribute was       | PATCH (Section      |
|              | invalid or malformed (see    | 3.3.2)              |
|              | Figure 4).                   |                     |
| noTarget     | The specified "path" did not | PATCH (Section      |
|              | yield an attribute or        | 3.3.2)              |
|              | attribute value that could   |                     |
|              | be operated on. This occurs  |                     |
|              | when the specified "path"    |                     |
|              | value contains a filter that |                     |
|              | yields no match.             |                     |
| invalidValue | A required value was         | GET (Section        |
|              | missing, or the value        | 3.2.2), POST        |
|              | specified was not compatible | (Create - Section   |
|              | with the operation or        | 3.1, Search -       |
|              | attribute type (see Section  | Section 3.2.2), PUT |
|              | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),    |
|              | ma]).                        | PATCH (Section      |
|              |                              | 3.3.2)              |
| invalidVers  | The specified API version is | GET (Section        |
|              | not supported (see Section   | 3.2.2), POST (ALL), |
|              | 3.11).                       | PUT (Section        |
|              |                              | 3.3.1), PATCH       |
|              |                              | (Section 3.3.2),    |
|              |                              | DELETE (Section     |
|              |                              | 3.4)                |
+--------------+------------------------------+---------------------+
I plan to put these into draft 07 of the API and will publish = over the weekend.

As always, feedback = welcome!

= --Apple-Mail=_F0A392CB-C571-4724-A060-8DC56AD9B97B-- From nobody Sun Jun 29 13:09:58 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393EE1A02F3 for ; Sun, 29 Jun 2014 13:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4trVUcqan02 for ; Sun, 29 Jun 2014 13:09:53 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34701A00DB for ; Sun, 29 Jun 2014 13:09:52 -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.974.11; Sun, 29 Jun 2014 20:09:50 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0974.002; Sun, 29 Jun 2014 20:09:50 +0000 From: Kelly Grizzle To: Phil Hunt , Scim WG Thread-Topic: [scim] Proposed Detail Errors Thread-Index: AQHPkjhB1v2CfJQHskiODjem+S8OQ5uIh3KA Date: Sun, 29 Jun 2014 20:09:49 +0000 Message-ID: <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> In-Reply-To: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: E42BA6D800781EE42BA825 x-originating-ip: [70.114.158.171] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 025796F161 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(46102001)(81342001)(85306003)(19580405001)(31966008)(19580395003)(74662001)(76576001)(16601075003)(77096002)(83322001)(16236675004)(76482001)(19300405004)(86362001)(20776003)(64706001)(19609705001)(106356001)(105586002)(74316001)(106116001)(83072002)(85852003)(15975445006)(19625215002)(2656002)(33646001)(54356999)(107886001)(79102001)(107046002)(76176999)(50986999)(15202345003)(101416001)(4396001)(99396002)(92566001)(87936001)(81542001)(99286002)(95666004)(74502001)(21056001)(80022001)(77982001)(66066001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_232fc398cb76462088c589f6244f3bf9BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/079W8CKinKbDQPSidMbHryxapzw Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 20:09:55 -0000 --_000_232fc398cb76462088c589f6244f3bf9BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like these, Phil. Should this list of error codes be extensible? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Friday, June 27, 2014 1:47 PM To: Scim WG Subject: [scim] Proposed Detail Errors After reviewing the API and Schema docs, here is a first cut of the detaile= d error codes. For HTTP Status 400 (Bad Request) responses, the following detail error types are defined: +--------------+------------------------------+---------------------+ | scimType | Description | Applicability | +--------------+------------------------------+---------------------+ | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | | r | was invalid (does not comply | POST (Search - | | | with Figure 1) or the | Section 3.2.3), | | | specified attribute and | PATCH (Path Filter | | | filter comparison | - Section 3.3.2) | | | combination is not | | | | supported. | | | uniqueness | One or more of attribute | POST (Create - | | | values is already in use or | Section 3.1), PUT | | | is reserved. | (Section 3.3.1), | | | | PATCH (Section | | | | 3.3.2) | | mutability | The attempted modification | PUT (Section | | | is not compatible with the | 3.3.1), PATCH | | | target attributes mutability | (Section 3.3.2) | | | or current state (e.g. | | | | modification of an immutable | | | | attribute with an existing | | | | value). | | | invalidSynta | The request body message | POST (Search - | | x | structure was invalid or did | Section 3.2.2, | | | not conform to the request | Create - Section | | | schema. | 3.1, Bulk - Section | | | | 3.5), PUT (Section | | | | 3.3.1) | | invalidPath | The path attribute was | PATCH (Section | | | invalid or malformed (see | 3.3.2) | | | Figure 4). | | | noTarget | The specified "path" did not | PATCH (Section | | | yield an attribute or | 3.3.2) | | | attribute value that could | | | | be operated on. This occurs | | | | when the specified "path" | | | | value contains a filter that | | | | yields no match. | | | invalidValue | A required value was | GET (Section | | | missing, or the value | 3.2.2), POST | | | specified was not compatible | (Create - Section | | | with the operation or | 3.1, Search - | | | attribute type (see Section | Section 3.2.2), PUT | | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | | | ma]). | PATCH (Section | | | | 3.3.2) | | invalidVers | The specified API version is | GET (Section | | | not supported (see Section | 3.2.2), POST (ALL), | | | 3.11). | PUT (Section | | | | 3.3.1), PATCH | | | | (Section 3.3.2), | | | | DELETE (Section | | | | 3.4) | +--------------+------------------------------+---------------------+ I plan to put these into draft 07 of the API and will publish over the week= end. As always, feedback welcome! Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_232fc398cb76462088c589f6244f3bf9BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like these, Phil. = Should this list of error codes be extensible?

 <= /p>

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, June 27, 2014 1:47 PM
To: Scim WG
Subject: [scim] Proposed Detail Errors

 

After reviewing the API and Schema docs, here is a f= irst cut of the detailed error codes.

 

For HTTP Status 4=
00 (Bad Request) responses, the following detail
   error types are defined:
 
+--------------+------------------------------+-----------=
----------+
| scimType     | Description   &nbs=
p;            &=
nbsp; | Applicability       |

+--------------+------------------------------+-----------=
----------+


| invalidFilte | The specified filter syntax  | GET(Section 3.2.2=
), |


| r            =
| was invalid (does not comply | POST (Search -    &nbs=
p; |


|           &nb=
sp;  | with Figure 1) or the       =
 | Section 3.2.3),     |


|           &nb=
sp;  | specified attribute and      | PATCH (=
Path Filter  |


|           &nb=
sp;  | filter comparison       &nbs=
p;    | - Section 3.3.2)    |

|           &nb=
sp;  | combination is not       &nb=
sp;   |         &nbs=
p;           |=



|           &nb=
sp;  | supported.         =
;          |   =
            &nb=
sp;     |


| uniqueness   | One or more of attribute   &=
nbsp; | POST (Create -      |


|           &nb=
sp;  | values is already in use or  | Section 3.1), PUT &nbs=
p; |


|           &nb=
sp;  | is reserved.        &nb=
sp;        | (Section 3.3.1),  =
;  |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | PATCH (Section    =
;  |


|           &nb=
sp;  |          &nbs=
p;             =
      | 3.3.2)     &=
nbsp;        |


| mutability   | The attempted modification   | PU=
T (Section        |


|           &nb=
sp;  | is not compatible with the   | 3.3.1), PATCH &nb=
sp;     |


|           &nb=
sp;  | target attributes mutability | (Section 3.3.2)   =
;  |


|            &n=
bsp; | or current state (e.g.       |&nb=
sp;            =
        |


|           &nb=
sp;  | modification of an immutable |     &nb=
sp;            =
   |


|           &nb=
sp;  | attribute with an existing   |    =
;            &n=
bsp;    |


|           &nb=
sp;  | value).         &n=
bsp;            |&nb=
sp;             =
;       |


| invalidSynta | The request body message     | PO=
ST (Search -      |


| x            =
| structure was invalid or did | Section 3.2.2,    &nbs=
p; |


|           &nb=
sp;  | not conform to the request   | Create - Section =
   |


|           &nb=
sp;  | schema.          &=
nbsp;           | 3.=
1, Bulk - Section |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.5), PUT (Section  |=



|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.1)     &=
nbsp;        |


| invalidPath  | The path attribute was    &n=
bsp;  | PATCH (Section      |

|            &n=
bsp; | invalid or malformed (see    | 3.3.2)  =
;            |<=
/o:p>


|           &nb=
sp;  | Figure 4).         =
;          |   =
            &nb=
sp;     |


| noTarget     | The specified "path" di=
d not | PATCH (Section      |


|           &nb=
sp;  | yield an attribute or       =
 | 3.3.2)            =
;  |


|           &nb=
sp;  | attribute value that could   |    =
;            &n=
bsp;    |


|           &nb=
sp;  | be operated on. This occurs  |    &nbs=
p;            &=
nbsp;   |


|           &nb=
sp;  | when the specified "path"    | &n=
bsp;            =
;       |


|           &nb=
sp;  | value contains a filter that |     &nb=
sp;            =
   |


|           &nb=
sp;  | yields no match.        =
;     |        =
             |<=
o:p>


| invalidValue | A required value was     &nb=
sp;   | GET (Section        |<=
o:p>


|           &nb=
sp;  | missing, or the value       =
 | 3.2.2), POST        |

|           &nb=
sp;  | specified was not compatible | (Create - Section   |<=
o:p>


|           &nb=
sp;  | with the operation or       =
 | 3.1, Search -       |


|           &nb=
sp;  | attribute type (see Section  | Section 3.2.2), PUT |<=
/o:p>


|           &nb=
sp;  | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),  &nbs=
p; |


|           &nb=
sp;  | ma]).         &nbs=
p;            &=
nbsp; | PATCH (Section      |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.2)     &=
nbsp;        |


| invalidVers  | The specified API version is | GET (Section =
;       |


|            &n=
bsp; | not supported (see Section   | 3.2.2), POST (ALL), |<=
o:p>


|           &nb=
sp;  | 3.11).         &nb=
sp;            =
 | PUT (Section        |

|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.1), PATCH    =
   |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | (Section 3.3.2),    |<=
o:p>


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | DELETE (Section   &nbs=
p; |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.4)     &nb=
sp;          |

+--------------+------------------------------+-----------=
----------+




I plan to put these into draft 07 of the API and wil=
l publish over the weekend.






 






As always, feedback welcome!






 
























Phil






 





@independentid<=
/span>







ph=
il.hunt@oracle.com






 
















 




 
--_000_232fc398cb76462088c589f6244f3bf9BN1PR04MB392namprd04pro_-- From nobody Sun Jun 29 13:27:24 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD1E1A0300 for ; Sun, 29 Jun 2014 13:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZDYvUoduYis for ; Sun, 29 Jun 2014 13:27:19 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB531A02FA for ; Sun, 29 Jun 2014 13:27:19 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5TKRIEn025414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 29 Jun 2014 20:27:18 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 s5TKRHBL029714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jun 2014 20:27:17 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5TKRHFN029708; Sun, 29 Jun 2014 20:27:17 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 29 Jun 2014 13:27:16 -0700 References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary=Apple-Mail-51E386B5-3D49-475D-8AE8-48C7267260C7 Content-Transfer-Encoding: 7bit Message-Id: <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> X-Mailer: iPhone Mail (11D201) From: Phil Hunt Date: Sun, 29 Jun 2014 13:27:13 -0700 To: Kelly Grizzle X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/_rtVYe8iQFZ_6LAvA8thRpolGpE Cc: Scim WG Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 20:27:21 -0000 --Apple-Mail-51E386B5-3D49-475D-8AE8-48C7267260C7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Could be if we use URIs for codes=20 Phil > On Jun 29, 2014, at 13:09, Kelly Grizzle wro= te: >=20 > I like these, Phil. Should this list of error codes be extensible? > =20 > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Friday, June 27, 2014 1:47 PM > To: Scim WG > Subject: [scim] Proposed Detail Errors > =20 > After reviewing the API and Schema docs, here is a first cut of the detail= ed error codes. > =20 > For HTTP Status 400 (Bad Request) responses, the following detail > error types are defined: > =20 > +--------------+------------------------------+---------------------+ > | scimType | Description | Applicability | > +--------------+------------------------------+---------------------+ > | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | > | r | was invalid (does not comply | POST (Search - | > | | with Figure 1) or the | Section 3.2.3), | > | | specified attribute and | PATCH (Path Filter | > | | filter comparison | - Section 3.3.2) | > | | combination is not | | > | | supported. | | > | uniqueness | One or more of attribute | POST (Create - | > | | values is already in use or | Section 3.1), PUT | > | | is reserved. | (Section 3.3.1), | > | | | PATCH (Section | > | | | 3.3.2) | > | mutability | The attempted modification | PUT (Section | > | | is not compatible with the | 3.3.1), PATCH | > | | target attributes mutability | (Section 3.3.2) | > | | or current state (e.g. | | > | | modification of an immutable | | > | | attribute with an existing | | > | | value). | | > | invalidSynta | The request body message | POST (Search - | > | x | structure was invalid or did | Section 3.2.2, | > | | not conform to the request | Create - Section | > | | schema. | 3.1, Bulk - Section | > | | | 3.5), PUT (Section | > | | | 3.3.1) | > | invalidPath | The path attribute was | PATCH (Section | > | | invalid or malformed (see | 3.3.2) | > | | Figure 4). | | > | noTarget | The specified "path" did not | PATCH (Section | > | | yield an attribute or | 3.3.2) | > | | attribute value that could | | > | | be operated on. This occurs | | > | | when the specified "path" | | > | | value contains a filter that | | > | | yields no match. | | > | invalidValue | A required value was | GET (Section | > | | missing, or the value | 3.2.2), POST | > | | specified was not compatible | (Create - Section | > | | with the operation or | 3.1, Search - | > | | attribute type (see Section | Section 3.2.2), PUT | > | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | > | | ma]). | PATCH (Section | > | | | 3.3.2) | > | invalidVers | The specified API version is | GET (Section | > | | not supported (see Section | 3.2.2), POST (ALL), | > | | 3.11). | PUT (Section | > | | | 3.3.1), PATCH | > | | | (Section 3.3.2), | > | | | DELETE (Section | > | | | 3.4) | > +--------------+------------------------------+---------------------+ > I plan to put these into draft 07 of the API and will publish over the wee= kend. > =20 > As always, feedback welcome! > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-51E386B5-3D49-475D-8AE8-48C7267260C7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Could be if we use URIs for codes 

Phil

On Jun 29, 2014, at 13:09, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I like these, Phil.  Should this list of error codes be extensible?

 

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, June 27, 2014 1:47 PM
To: Scim WG
Subject: [scim] Proposed Detail Errors

 

After reviewing the API and Schema docs, here is a first cut of the detailed error codes.

 

For HTTP Status 400 (Bad Request) responses, the following detail
   error types are defined:
 
+--------------+------------------------------+---------------------+
| scimType     | Description                  | Applicability       |
+--------------+------------------------------+---------------------+
| invalidFilte | The specified filter syntax  | GET(Section 3.2.2), |
| r            | was invalid (does not comply | POST (Search -      |
|              | with Figure 1) or the        | Section 3.2.3),     |
|              | specified attribute and      | PATCH (Path Filter  |
|              | filter comparison            | - Section 3.3.2)    |
|              | combination is not           |                     |
|              | supported.                   |                     |
| uniqueness   | One or more of attribute     | POST (Create -      |
|              | values is already in use or  | Section 3.1), PUT   |
|              | is reserved.                 | (Section 3.3.1),    |
|              |                              | PATCH (Section      |
|              |                              | 3.3.2)              |
| mutability   | The attempted modification   | PUT (Section        |
|              | is not compatible with the   | 3.3.1), PATCH       |
|              | target attributes mutability | (Section 3.3.2)     |
|              | or current state (e.g.       |                     |
|              | modification of an immutable |                     |
|              | attribute with an existing   |                     |
|              | value).                      |                     |
| invalidSynta | The request body message     | POST (Search -      |
| x            | structure was invalid or did | Section 3.2.2,      |
|              | not conform to the request   | Create - Section    |
|              | schema.                      | 3.1, Bulk - Section |
|              |                              | 3.5), PUT (Section  |
|              |                              | 3.3.1)              |
| invalidPath  | The path attribute was       | PATCH (Section      |
|              | invalid or malformed (see    | 3.3.2)              |
|              | Figure 4).                   |                     |
| noTarget     | The specified "path" did not | PATCH (Section      |
|              | yield an attribute or        | 3.3.2)              |
|              | attribute value that could   |                     |
|              | be operated on. This occurs  |                     |
|              | when the specified "path"    |                     |
|              | value contains a filter that |                     |
|              | yields no match.             |                     |
| invalidValue | A required value was         | GET (Section        |
|              | missing, or the value        | 3.2.2), POST        |
|              | specified was not compatible | (Create - Section   |
|              | with the operation or        | 3.1, Search -       |
|              | attribute type (see Section  | Section 3.2.2), PUT |
|              | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),    |
|              | ma]).                        | PATCH (Section      |
|              |                              | 3.3.2)              |
| invalidVers  | The specified API version is | GET (Section        |
|              | not supported (see Section   | 3.2.2), POST (ALL), |
|              | 3.11).                       | PUT (Section        |
|              |                              | 3.3.1), PATCH       |
|              |                              | (Section 3.3.2),    |
|              |                              | DELETE (Section     |
|              |                              | 3.4)                |
+--------------+------------------------------+---------------------+

I plan to put these into draft 07 of the API and will publish over the weekend.

 

As always, feedback welcome!

 

 

 

 

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--Apple-Mail-51E386B5-3D49-475D-8AE8-48C7267260C7-- From nobody Mon Jun 30 07:46:58 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A131A036A for ; Mon, 30 Jun 2014 07:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oGABGtEV_a5 for ; Mon, 30 Jun 2014 07:46:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBCC1A036C for ; Mon, 30 Jun 2014 07:46:55 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB390.namprd04.prod.outlook.com (10.141.60.147) with Microsoft SMTP Server (TLS) id 15.0.969.15; Mon, 30 Jun 2014 14:46:53 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0974.002; Mon, 30 Jun 2014 14:46:52 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: [scim] Proposed Detail Errors Thread-Index: AQHPkjhB1v2CfJQHskiODjem+S8OQ5uIh3KAgAAFIoCAATHUYA== Date: Mon, 30 Jun 2014 14:46:52 +0000 Message-ID: <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> In-Reply-To: <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: E82A5AD000781EE82A5C1D x-originating-ip: [70.114.158.171] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(51444003)(199002)(189002)(377454003)(74502001)(74662001)(31966008)(20776003)(64706001)(77096002)(81342001)(76176999)(54356999)(50986999)(99396002)(92566001)(86362001)(4396001)(81542001)(80022001)(66066001)(79102001)(85306003)(21056001)(76576001)(16236675004)(16601075003)(83072002)(107046002)(19580405001)(83322001)(101416001)(19580395003)(19300405004)(19625215002)(46102001)(74316001)(33646001)(77982001)(76482001)(106116001)(15975445006)(95666004)(85852003)(19609705001)(2656002)(106356001)(105586002)(15202345003)(99286002)(87936001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB390; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_9075316269e949418386ee90ebedee42BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/CfWzWo2ogeJ4ezEfMDy1wxSFKUA Cc: Scim WG Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 14:46:57 -0000 --_000_9075316269e949418386ee90ebedee42BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZW1lbWJlciB0aGF0IG9uZSBvZiB0aGUgaW5pdGlhbCBkcml2ZXJzIGZvciB0aGlzIHRpY2tl dCB3YXMgdGhlIGFiaWxpdHkgZm9yIHNlcnZpY2UgcHJvdmlkZXJzIHRvIHNlbmQgYmFjayBlcnJv ciBjb2RlcyB0aGF0IGFyZSBzcGVjaWZpYyB0byB0aGUgc2VydmljZSBwcm92aWRlci4NCg0KQW4g ZXhhbXBsZSBvbiBhIHVzZXIgY3JlYXRpb24gbWlnaHQgYmUg4oCcZXJyb3IgMjg3MzjigJ0g4oCm IOKAnGNsaWVudCBoYXMgZXhjZWVkZWQgdGhlIG1heGltdW0gbnVtYmVyIG9mIHVzZXJzIGluIHRo ZWlyIG9yZ2FuaXphdGlvbuKAnS4gIElkZWFsbHkgdGhlIFNQIHdvdWxkIGJlIGFibGUgdG8gY29t bXVuaWNhdGUgYmFjayB0aGUgZ2VuZXJhbCBIVFRQIGVycm9yIGNvZGUsIGEgcHJvdmlkZXItc3Bl Y2lmaWMgZXJyb3IgY29kZSwgYW5kIGEgaHVtYW4gcmVhZGFibGUgZGVzY3JpcHRpb24uDQoNCkkg dGhpbmsgdGhhdCBzY2ltVHlwZSB3b3VsZCBhbGxvdyBmb3IgdGhpcyBpZiB0aGUgbGlzdCB3ZXJl IGV4dGVuc2libGUuDQoNCi0tS2VsbHkNCg0KRnJvbTogUGhpbCBIdW50IFttYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb21dDQpTZW50OiBTdW5kYXksIEp1bmUgMjksIDIwMTQgMzoyNyBQTQ0KVG86 IEtlbGx5IEdyaXp6bGUNCkNjOiBTY2ltIFdHDQpTdWJqZWN0OiBSZTogW3NjaW1dIFByb3Bvc2Vk IERldGFpbCBFcnJvcnMNCg0KQ291bGQgYmUgaWYgd2UgdXNlIFVSSXMgZm9yIGNvZGVzDQoNClBo aWwNCg0KT24gSnVuIDI5LCAyMDE0LCBhdCAxMzowOSwgS2VsbHkgR3JpenpsZSA8a2VsbHkuZ3Jp enpsZUBzYWlscG9pbnQuY29tPG1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20+PiB3 cm90ZToNCkkgbGlrZSB0aGVzZSwgUGhpbC4gIFNob3VsZCB0aGlzIGxpc3Qgb2YgZXJyb3IgY29k ZXMgYmUgZXh0ZW5zaWJsZT8NCg0KDQpGcm9tOiBzY2ltIFttYWlsdG86c2NpbS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgUGhpbCBIdW50DQpTZW50OiBGcmlkYXksIEp1bmUgMjcsIDIw MTQgMTo0NyBQTQ0KVG86IFNjaW0gV0cNClN1YmplY3Q6IFtzY2ltXSBQcm9wb3NlZCBEZXRhaWwg RXJyb3JzDQoNCkFmdGVyIHJldmlld2luZyB0aGUgQVBJIGFuZCBTY2hlbWEgZG9jcywgaGVyZSBp cyBhIGZpcnN0IGN1dCBvZiB0aGUgZGV0YWlsZWQgZXJyb3IgY29kZXMuDQoNCg0KRm9yIEhUVFAg U3RhdHVzIDQwMCAoQmFkIFJlcXVlc3QpIHJlc3BvbnNlcywgdGhlIGZvbGxvd2luZyBkZXRhaWwN Cg0KICAgZXJyb3IgdHlwZXMgYXJlIGRlZmluZWQ6DQoNCg0KDQorLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KfCBz Y2ltVHlwZSAgICAgfCBEZXNjcmlwdGlvbiAgICAgICAgICAgICAgICAgIHwgQXBwbGljYWJpbGl0 eSAgICAgICB8DQoNCistLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQp8IGludmFsaWRGaWx0ZSB8IFRoZSBzcGVjaWZp ZWQgZmlsdGVyIHN5bnRheCAgfCBHRVQoU2VjdGlvbiAzLjIuMiksIHwNCg0KfCByICAgICAgICAg ICAgfCB3YXMgaW52YWxpZCAoZG9lcyBub3QgY29tcGx5IHwgUE9TVCAoU2VhcmNoIC0gICAgICB8 DQoNCnwgICAgICAgICAgICAgIHwgd2l0aCBGaWd1cmUgMSkgb3IgdGhlICAgICAgICB8IFNlY3Rp b24gMy4yLjMpLCAgICAgfA0KDQp8ICAgICAgICAgICAgICB8IHNwZWNpZmllZCBhdHRyaWJ1dGUg YW5kICAgICAgfCBQQVRDSCAoUGF0aCBGaWx0ZXIgIHwNCg0KfCAgICAgICAgICAgICAgfCBmaWx0 ZXIgY29tcGFyaXNvbiAgICAgICAgICAgIHwgLSBTZWN0aW9uIDMuMy4yKSAgICB8DQoNCnwgICAg ICAgICAgICAgIHwgY29tYmluYXRpb24gaXMgbm90ICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgfA0KDQp8ICAgICAgICAgICAgICB8IHN1cHBvcnRlZC4gICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgIHwNCg0KfCB1bmlxdWVuZXNzICAgfCBPbmUgb3IgbW9yZSBv ZiBhdHRyaWJ1dGUgICAgIHwgUE9TVCAoQ3JlYXRlIC0gICAgICB8DQoNCnwgICAgICAgICAgICAg IHwgdmFsdWVzIGlzIGFscmVhZHkgaW4gdXNlIG9yICB8IFNlY3Rpb24gMy4xKSwgUFVUICAgfA0K DQp8ICAgICAgICAgICAgICB8IGlzIHJlc2VydmVkLiAgICAgICAgICAgICAgICAgfCAoU2VjdGlv biAzLjMuMSksICAgIHwNCg0KfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgUEFUQ0ggKFNlY3Rpb24gICAgICB8DQoNCnwgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8IDMuMy4yKSAgICAgICAgICAgICAgfA0KDQp8IG11dGFi aWxpdHkgICB8IFRoZSBhdHRlbXB0ZWQgbW9kaWZpY2F0aW9uICAgfCBQVVQgKFNlY3Rpb24gICAg ICAgIHwNCg0KfCAgICAgICAgICAgICAgfCBpcyBub3QgY29tcGF0aWJsZSB3aXRoIHRoZSAgIHwg My4zLjEpLCBQQVRDSCAgICAgICB8DQoNCnwgICAgICAgICAgICAgIHwgdGFyZ2V0IGF0dHJpYnV0 ZXMgbXV0YWJpbGl0eSB8IChTZWN0aW9uIDMuMy4yKSAgICAgfA0KDQp8ICAgICAgICAgICAgICB8 IG9yIGN1cnJlbnQgc3RhdGUgKGUuZy4gICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCg0K fCAgICAgICAgICAgICAgfCBtb2RpZmljYXRpb24gb2YgYW4gaW1tdXRhYmxlIHwgICAgICAgICAg ICAgICAgICAgICB8DQoNCnwgICAgICAgICAgICAgIHwgYXR0cmlidXRlIHdpdGggYW4gZXhpc3Rp bmcgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KDQp8ICAgICAgICAgICAgICB8IHZhbHVlKS4g ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCg0KfCBpbnZhbGlk U3ludGEgfCBUaGUgcmVxdWVzdCBib2R5IG1lc3NhZ2UgICAgIHwgUE9TVCAoU2VhcmNoIC0gICAg ICB8DQoNCnwgeCAgICAgICAgICAgIHwgc3RydWN0dXJlIHdhcyBpbnZhbGlkIG9yIGRpZCB8IFNl Y3Rpb24gMy4yLjIsICAgICAgfA0KDQp8ICAgICAgICAgICAgICB8IG5vdCBjb25mb3JtIHRvIHRo ZSByZXF1ZXN0ICAgfCBDcmVhdGUgLSBTZWN0aW9uICAgIHwNCg0KfCAgICAgICAgICAgICAgfCBz Y2hlbWEuICAgICAgICAgICAgICAgICAgICAgIHwgMy4xLCBCdWxrIC0gU2VjdGlvbiB8DQoNCnwg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IDMuNSksIFBVVCAo U2VjdGlvbiAgfA0KDQp8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAzLjMuMSkgICAgICAgICAgICAgIHwNCg0KfCBpbnZhbGlkUGF0aCAgfCBUaGUgcGF0aCBh dHRyaWJ1dGUgd2FzICAgICAgIHwgUEFUQ0ggKFNlY3Rpb24gICAgICB8DQoNCnwgICAgICAgICAg ICAgIHwgaW52YWxpZCBvciBtYWxmb3JtZWQgKHNlZSAgICB8IDMuMy4yKSAgICAgICAgICAgICAg fA0KDQp8ICAgICAgICAgICAgICB8IEZpZ3VyZSA0KS4gICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgIHwNCg0KfCBub1RhcmdldCAgICAgfCBUaGUgc3BlY2lmaWVkICJwYXRo IiBkaWQgbm90IHwgUEFUQ0ggKFNlY3Rpb24gICAgICB8DQoNCnwgICAgICAgICAgICAgIHwgeWll bGQgYW4gYXR0cmlidXRlIG9yICAgICAgICB8IDMuMy4yKSAgICAgICAgICAgICAgfA0KDQp8ICAg ICAgICAgICAgICB8IGF0dHJpYnV0ZSB2YWx1ZSB0aGF0IGNvdWxkICAgfCAgICAgICAgICAgICAg ICAgICAgIHwNCg0KfCAgICAgICAgICAgICAgfCBiZSBvcGVyYXRlZCBvbi4gVGhpcyBvY2N1cnMg IHwgICAgICAgICAgICAgICAgICAgICB8DQoNCnwgICAgICAgICAgICAgIHwgd2hlbiB0aGUgc3Bl Y2lmaWVkICJwYXRoIiAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KDQp8ICAgICAgICAgICAg ICB8IHZhbHVlIGNvbnRhaW5zIGEgZmlsdGVyIHRoYXQgfCAgICAgICAgICAgICAgICAgICAgIHwN Cg0KfCAgICAgICAgICAgICAgfCB5aWVsZHMgbm8gbWF0Y2guICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICB8DQoNCnwgaW52YWxpZFZhbHVlIHwgQSByZXF1aXJlZCB2YWx1ZSB3YXMg ICAgICAgICB8IEdFVCAoU2VjdGlvbiAgICAgICAgfA0KDQp8ICAgICAgICAgICAgICB8IG1pc3Np bmcsIG9yIHRoZSB2YWx1ZSAgICAgICAgfCAzLjIuMiksIFBPU1QgICAgICAgIHwNCg0KfCAgICAg ICAgICAgICAgfCBzcGVjaWZpZWQgd2FzIG5vdCBjb21wYXRpYmxlIHwgKENyZWF0ZSAtIFNlY3Rp b24gICB8DQoNCnwgICAgICAgICAgICAgIHwgd2l0aCB0aGUgb3BlcmF0aW9uIG9yICAgICAgICB8 IDMuMSwgU2VhcmNoIC0gICAgICAgfA0KDQp8ICAgICAgICAgICAgICB8IGF0dHJpYnV0ZSB0eXBl IChzZWUgU2VjdGlvbiAgfCBTZWN0aW9uIDMuMi4yKSwgUFVUIHwNCg0KfCAgICAgICAgICAgICAg fCAyLjEgW0ktRC5pZXRmLXNjaW0tY29yZS1zY2hlIHwgKFNlY3Rpb24gMy4zLjEpLCAgICB8DQoN CnwgICAgICAgICAgICAgIHwgbWFdKS4gICAgICAgICAgICAgICAgICAgICAgICB8IFBBVENIIChT ZWN0aW9uICAgICAgfA0KDQp8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAzLjMuMikgICAgICAgICAgICAgIHwNCg0KfCBpbnZhbGlkVmVycyAgfCBUaGUgc3Bl Y2lmaWVkIEFQSSB2ZXJzaW9uIGlzIHwgR0VUIChTZWN0aW9uICAgICAgICB8DQoNCnwgICAgICAg ICAgICAgIHwgbm90IHN1cHBvcnRlZCAoc2VlIFNlY3Rpb24gICB8IDMuMi4yKSwgUE9TVCAoQUxM KSwgfA0KDQp8ICAgICAgICAgICAgICB8IDMuMTEpLiAgICAgICAgICAgICAgICAgICAgICAgfCBQ VVQgKFNlY3Rpb24gICAgICAgIHwNCg0KfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgMy4zLjEpLCBQQVRDSCAgICAgICB8DQoNCnwgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IChTZWN0aW9uIDMuMy4yKSwgICAgfA0KDQp8 ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBERUxFVEUgKFNl Y3Rpb24gICAgIHwNCg0KfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgMy40KSAgICAgICAgICAgICAgICB8DQoNCistLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KSSBwbGFuIHRvIHB1 dCB0aGVzZSBpbnRvIGRyYWZ0IDA3IG9mIHRoZSBBUEkgYW5kIHdpbGwgcHVibGlzaCBvdmVyIHRo ZSB3ZWVrZW5kLg0KDQpBcyBhbHdheXMsIGZlZWRiYWNrIHdlbGNvbWUhDQoNClBoaWwNCg0KQGlu ZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50 aWQuY29tPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t Pg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnNjaW0gbWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQo= --_000_9075316269e949418386ee90ebedee42BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLmFwcGxlLXN0eWxlLXNw YW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgcmVtZW1iZXIgdGhhdCBvbmUgb2YgdGhlIGluaXRpYWwgZHJpdmVycyBmb3IgdGhp cyB0aWNrZXQgd2FzIHRoZSBhYmlsaXR5IGZvciBzZXJ2aWNlIHByb3ZpZGVycyB0byBzZW5kIGJh Y2sgZXJyb3IgY29kZXMgdGhhdCBhcmUgc3BlY2lmaWMgdG8gdGhlIHNlcnZpY2UgcHJvdmlkZXIu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5BbiBleGFtcGxlIG9uIGEgdXNlciBjcmVhdGlvbiBtaWdodCBiZSDigJxlcnJv ciAyODczOOKAnSDigKYg4oCcY2xpZW50IGhhcyBleGNlZWRlZCB0aGUgbWF4aW11bSBudW1iZXIg b2YgdXNlcnMgaW4gdGhlaXIgb3JnYW5pemF0aW9u4oCdLiZuYnNwOyBJZGVhbGx5IHRoZSBTUCB3 b3VsZCBiZSBhYmxlDQogdG8gY29tbXVuaWNhdGUgYmFjayB0aGUgZ2VuZXJhbCBIVFRQIGVycm9y IGNvZGUsIGEgcHJvdmlkZXItc3BlY2lmaWMgZXJyb3IgY29kZSwgYW5kIGEgaHVtYW4gcmVhZGFi bGUgZGVzY3JpcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoYXQgc2NpbVR5cGUgd291bGQgYWxs b3cgZm9yIHRoaXMgaWYgdGhlIGxpc3Qgd2VyZSBleHRlbnNpYmxlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS1LZWxs eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgSnVuZSAyOSwgMjAxNCAzOjI3IFBNPGJy Pg0KPGI+VG86PC9iPiBLZWxseSBHcml6emxlPGJyPg0KPGI+Q2M6PC9iPiBTY2ltIFdHPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc2NpbV0gUHJvcG9zZWQgRGV0YWlsIEVycm9yczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db3VsZCBiZSBp ZiB3ZSB1c2UgVVJJcyBmb3IgY29kZXMmbmJzcDs8YnI+DQo8YnI+DQpQaGlsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NCk9uIEp1biAyOSwgMjAxNCwgYXQgMTM6MDksIEtlbGx5IEdyaXp6 bGUgJmx0OzxhIGhyZWY9Im1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20iPmtlbGx5 LmdyaXp6bGVAc2FpbHBvaW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBsaWtlIHRoZXNlLCBQaGlsLiZuYnNwOyBTaG91bGQgdGhp cyBsaXN0IG9mIGVycm9yIGNvZGVzIGJlIGV4dGVuc2libGU/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNjaW0gWzxhIGhyZWY9Im1haWx0 bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQ8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBKdW5lIDI3LCAyMDE0IDE6NDcgUE08YnI+DQo8Yj5Ubzo8L2I+IFNjaW0gV0c8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gW3NjaW1dIFByb3Bvc2VkIERldGFpbCBFcnJvcnM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZnRlciByZXZpZXdpbmcgdGhlIEFQSSBh bmQgU2NoZW1hIGRvY3MsIGhlcmUgaXMgYSBmaXJzdCBjdXQgb2YgdGhlIGRldGFpbGVkIGVycm9y IGNvZGVzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29yZC13cmFwOiBi cmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj5Gb3IgSFRUUCBTdGF0dXMgNDAwIChCYWQg UmVxdWVzdCkgcmVzcG9uc2VzLCB0aGUgZm9sbG93aW5nIGRldGFpbDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyBlcnJvciB0eXBlcyBhcmUgZGVmaW5lZDo8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mIzQzOy0tLS0tLS0tLS0t LS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0t LS0tLS0tLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+fCBzY2ltVHlwZSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8IERlc2NyaXB0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwgQXBwbGljYWJpbGl0eSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+JiM0MzstLS0tLS0tLS0tLS0tLSYj NDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0t LS0mIzQzOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwgaW52YWxpZEZpbHRlIHwgVGhlIHNwZWNp ZmllZCBmaWx0ZXIgc3ludGF4Jm5ic3A7IHwgR0VUKFNlY3Rpb24gMy4yLjIpLCB8PG86cD48L286 cD48L3ByZT4NCjxwcmU+fCByJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgd2FzIGludmFsaWQgKGRvZXMgbm90IGNvbXBs eSB8IFBPU1QgKFNlYXJjaCAtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgd2l0aCBGaWd1cmUgMSkg b3IgdGhlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgU2VjdGlv biAzLjIuMyksJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgc3BlY2lmaWVkIGF0dHJpYnV0ZSBhbmQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBQQVRDSCAoUGF0aCBGaWx0ZXImbmJzcDsgfDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7fCBmaWx0ZXIgY29tcGFy aXNvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8IC0gU2VjdGlvbiAzLjMuMikmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBjb21iaW5hdGlvbiBp cyBub3QmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8IHN1cHBvcnRlZC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCB1bmlxdWVu ZXNzJm5ic3A7Jm5ic3A7IHwgT25lIG9yIG1vcmUgb2YgYXR0cmlidXRlJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwgUE9TVCAoQ3JlYXRlIC0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCB2YWx1ZXMg aXMgYWxyZWFkeSBpbiB1c2Ugb3ImbmJzcDsgfCBTZWN0aW9uIDMuMSksIFBVVCZuYnNwOyZuYnNw OyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IGlzIHJl c2VydmVkLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IChTZWN0aW9u IDMuMy4xKSwmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFBBVENIIChTZWN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7fCAzLjMuMikmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPnwgbXV0YWJpbGl0eSZuYnNwOyZuYnNwOyB8IFRoZSBhdHRlbXB0ZWQgbW9kaWZpY2F0 aW9uJm5ic3A7Jm5ic3A7IHwgUFVUIChTZWN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwgaXMgbm90IGNvbXBhdGlibGUgd2l0aCB0aGUmbmJzcDsmbmJzcDsgfCAzLjMuMSks IFBBVENIJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgdGFyZ2V0IGF0dHJpYnV0ZXMgbXV0 YWJpbGl0eSB8IChTZWN0aW9uIDMuMy4yKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48 L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDt8IG9yIGN1cnJlbnQgc3Rh dGUgKGUuZy4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86 cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IG1vZGlmaWNhdGlv biBvZiBhbiBpbW11dGFibGUgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8IGF0dHJpYnV0ZSB3aXRoIGFuIGV4aXN0aW5nJm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCB2YWx1ZSkuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwg aW52YWxpZFN5bnRhIHwgVGhlIHJlcXVlc3QgYm9keSBtZXNzYWdlJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwgUE9TVCAoU2VhcmNoIC0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwgeCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHN0cnVjdHVyZSB3YXMgaW52YWxp ZCBvciBkaWQgfCBTZWN0aW9uIDMuMi4yLCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IG5vdCBjb25m b3JtIHRvIHRoZSByZXF1ZXN0Jm5ic3A7Jm5ic3A7IHwgQ3JlYXRlIC0gU2VjdGlvbiZuYnNwOyZu YnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8IHNjaGVtYS4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCAzLjEsIEJ1bGsgLSBTZWN0aW9uIHw8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAzLjUpLCBQVVQgKFNl Y3Rpb24mbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8IDMuMy4xKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4N CjxwcmU+fCBpbnZhbGlkUGF0aCZuYnNwOyB8IFRoZSBwYXRoIGF0dHJpYnV0ZSB3YXMmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBQQVRDSCAoU2VjdGlvbiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDt8IGludmFsaWQgb3IgbWFsZm9ybWVkIChzZWUmbmJzcDsmbmJzcDsmbmJzcDsg fCAzLjMuMikmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBGaWd1cmUgNCkuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPnwgbm9UYXJnZXQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBUaGUgc3BlY2lmaWVkICZx dW90O3BhdGgmcXVvdDsgZGlkIG5vdCB8IFBBVENIIChTZWN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwgeWllbGQgYW4gYXR0cmlidXRlIG9yJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwgMy4zLjIpJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgYXR0cmlidXRlIHZhbHVlIHRoYXQg Y291bGQmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8IGJlIG9wZXJhdGVkIG9uLiBUaGlzIG9jY3VycyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgd2hl biB0aGUgc3BlY2lmaWVkICZxdW90O3BhdGgmcXVvdDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHZhbHVl IGNvbnRhaW5zIGEgZmlsdGVyIHRoYXQgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+ fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHlpZWxkcyBubyBtYXRjaC4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCBpbnZhbGlkVmFsdWUgfCBBIHJlcXVp cmVkIHZhbHVlIHdhcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8IEdFVCAoU2VjdGlvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IG1p c3NpbmcsIG9yIHRoZSB2YWx1ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8IDMuMi4yKSwgUE9TVCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDt8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHNw ZWNpZmllZCB3YXMgbm90IGNvbXBhdGlibGUgfCAoQ3JlYXRlIC0gU2VjdGlvbiZuYnNwOyZuYnNw OyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHdpdGgg dGhlIG9wZXJhdGlvbiBvciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8IDMuMSwgU2VhcmNoIC0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBhdHRyaWJ1dGUg dHlwZSAoc2VlIFNlY3Rpb24mbmJzcDsgfCBTZWN0aW9uIDMuMi4yKSwgUFVUIHw8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgMi4xIFtJLUQuaWV0Zi1zY2lt LWNvcmUtc2NoZSB8IChTZWN0aW9uIDMuMy4xKSwmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBtYV0pLiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8IFBBVENIIChTZWN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCAzLjMuMikmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwg aW52YWxpZFZlcnMmbmJzcDsgfCBUaGUgc3BlY2lmaWVkIEFQSSB2ZXJzaW9uIGlzIHwgR0VUIChT ZWN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwO3wgbm90IHN1cHBvcnRlZCAo c2VlIFNlY3Rpb24mbmJzcDsmbmJzcDsgfCAzLjIuMiksIFBPU1QgKEFMTCksIHw8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgMy4xMSkuJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwgUFVUIChTZWN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCAzLjMuMSksIFBBVENIJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAoU2Vj dGlvbiAzLjMuMiksJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBERUxFVEUgKFNlY3Rpb24mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8IDMuNCkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwv cHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcGxhbiB0byBwdXQgdGhlc2UgaW50 byBkcmFmdCAwNyBvZiB0aGUgQVBJIGFuZCB3aWxsIHB1Ymxpc2ggb3ZlciB0aGUgd2Vla2VuZC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMg YWx3YXlzLCBmZWVkYmFjayB3ZWxjb21lITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5QaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ QGluZGVwZW5kZW50aWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tIj53d3cuaW5kZXBlbmRlbnRp ZC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2NpbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9075316269e949418386ee90ebedee42BN1PR04MB392namprd04pro_-- From nobody Mon Jun 30 08:56:40 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7BA1A0389 for ; Mon, 30 Jun 2014 08:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tyi-jxom1W-T for ; Mon, 30 Jun 2014 08:56:36 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73F61A0056 for ; Mon, 30 Jun 2014 08:56:36 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5UFuXTk015784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Jun 2014 15:56:35 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5UFuUE9004593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Jun 2014 15:56:31 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5UFuTbV004032; Mon, 30 Jun 2014 15:56:29 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Jun 2014 08:56:28 -0700 References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary=Apple-Mail-05D0A97B-30AF-4C47-BC80-EDB9C5730D16 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D201) From: Phil Hunt Date: Mon, 30 Jun 2014 08:56:27 -0700 To: Kelly Grizzle X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/s1CYJcOHQEECKM0hSVcGZHCxv_g Cc: Scim WG Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 15:56:39 -0000 --Apple-Mail-05D0A97B-30AF-4C47-BC80-EDB9C5730D16 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable David had a similar comment.=20 What if there was a separate attribute: spCode that allows the service provi= der to indicate non-protocol errors? Phil > On Jun 30, 2014, at 7:46, Kelly Grizzle wrot= e: >=20 > I remember that one of the initial drivers for this ticket was the ability= for service providers to send back error codes that are specific to the ser= vice provider. > =20 > An example on a user creation might be =E2=80=9Cerror 28738=E2=80=9D =E2=80= =A6 =E2=80=9Cclient has exceeded the maximum number of users in their organi= zation=E2=80=9D. Ideally the SP would be able to communicate back the gener= al HTTP error code, a provider-specific error code, and a human readable des= cription. > =20 > I think that scimType would allow for this if the list were extensible. > =20 > --Kelly > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Sunday, June 29, 2014 3:27 PM > To: Kelly Grizzle > Cc: Scim WG > Subject: Re: [scim] Proposed Detail Errors > =20 > Could be if we use URIs for codes=20 >=20 > Phil >=20 > On Jun 29, 2014, at 13:09, Kelly Grizzle wro= te: >=20 > I like these, Phil. Should this list of error codes be extensible? > =20 > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Friday, June 27, 2014 1:47 PM > To: Scim WG > Subject: [scim] Proposed Detail Errors > =20 > After reviewing the API and Schema docs, here is a first cut of the detail= ed error codes. > =20 > For HTTP Status 400 (Bad Request) responses, the following detail > error types are defined: > =20 > +--------------+------------------------------+---------------------+ > | scimType | Description | Applicability | > +--------------+------------------------------+---------------------+ > | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | > | r | was invalid (does not comply | POST (Search - | > | | with Figure 1) or the | Section 3.2.3), | > | | specified attribute and | PATCH (Path Filter | > | | filter comparison | - Section 3.3.2) | > | | combination is not | | > | | supported. | | > | uniqueness | One or more of attribute | POST (Create - | > | | values is already in use or | Section 3.1), PUT | > | | is reserved. | (Section 3.3.1), | > | | | PATCH (Section | > | | | 3.3.2) | > | mutability | The attempted modification | PUT (Section | > | | is not compatible with the | 3.3.1), PATCH | > | | target attributes mutability | (Section 3.3.2) | > | | or current state (e.g. | | > | | modification of an immutable | | > | | attribute with an existing | | > | | value). | | > | invalidSynta | The request body message | POST (Search - | > | x | structure was invalid or did | Section 3.2.2, | > | | not conform to the request | Create - Section | > | | schema. | 3.1, Bulk - Section | > | | | 3.5), PUT (Section | > | | | 3.3.1) | > | invalidPath | The path attribute was | PATCH (Section | > | | invalid or malformed (see | 3.3.2) | > | | Figure 4). | | > | noTarget | The specified "path" did not | PATCH (Section | > | | yield an attribute or | 3.3.2) | > | | attribute value that could | | > | | be operated on. This occurs | | > | | when the specified "path" | | > | | value contains a filter that | | > | | yields no match. | | > | invalidValue | A required value was | GET (Section | > | | missing, or the value | 3.2.2), POST | > | | specified was not compatible | (Create - Section | > | | with the operation or | 3.1, Search - | > | | attribute type (see Section | Section 3.2.2), PUT | > | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | > | | ma]). | PATCH (Section | > | | | 3.3.2) | > | invalidVers | The specified API version is | GET (Section | > | | not supported (see Section | 3.2.2), POST (ALL), | > | | 3.11). | PUT (Section | > | | | 3.3.1), PATCH | > | | | (Section 3.3.2), | > | | | DELETE (Section | > | | | 3.4) | > +--------------+------------------------------+---------------------+ > I plan to put these into draft 07 of the API and will publish over the wee= kend. > =20 > As always, feedback welcome! > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =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 --Apple-Mail-05D0A97B-30AF-4C47-BC80-EDB9C5730D16 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
David had a similar comment. 

What if there was a separate attribute: spCode that al= lows the service provider to indicate non-protocol errors?

Phi= l

On Jun 30, 2014, at 7:46, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I remember that one of the i= nitial drivers for this ticket was the ability for service providers to send= back error codes that are specific to the service provider.

 

An example on a user creati= on might be =E2=80=9Cerror 28738=E2=80=9D =E2=80=A6 =E2=80=9Cclient has exce= eded the maximum number of users in their organization=E2=80=9D.  Ideal= ly the SP would be able to communicate back the general HTTP error code, a provider-specific error c= ode, and a human readable description.

 

I think that scimType would= allow for this if the list were extensible.

 

--Kelly

 

From: Phil Hunt [= mailto:phil.hunt@oracle.com]
Sent: Sunday, June 29, 2014 3:27 PM
To: Kelly Grizzle
Cc: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

Could be if we use URIs for codes 

Phil


On Jun 29, 2014, at 13:09, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I like these, Phil.  S= hould this list of error codes be extensible?

 

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, June 27, 2014 1:47 PM
To: Scim WG
Subject: [scim] Proposed Detail Errors

 

After reviewing the API and Schema docs, here is a fi= rst cut of the detailed error codes.

 

For HTTP Status 40=
0 (Bad Request) responses, the following detail
   error types are defined:
 
+--------------+------------------------------+---------------------+
| scimType     | Description    =
;            &nb=
sp; | Applicability       |
+--------------+------------------------------+---------------------+
| invalidFilte | The specified filter syntax  | GET(Section 3.2.2)=
, |
| r            |=
 was invalid (does not comply | POST (Search -     =
 |
|           &nbs=
p;  | with Figure 1) or the        |=
 Section 3.2.3),     |
|           &nbs=
p;  | specified attribute and      | PATCH (Pa=
th Filter  |
|           &nbs=
p;  | filter comparison        =
    | - Section 3.3.2)    |
|           &nbs=
p;  | combination is not        =
;   |          &=
nbsp;          |

|           &nbs=
p;  | supported.         &=
nbsp;         |   &nb=
sp;            &=
nbsp;    |


| uniqueness   | One or more of attribute   &n=
bsp; | POST (Create -      |


|           &nbs=
p;  | values is already in use or  | Section 3.1), PUT  =
 |


|           &nbs=
p;  | is reserved.         =
;        | (Section 3.3.1),  &n=
bsp; |


|           &nbs=
p;  |           =
            &nbs=
p;      | PATCH (Section    &nb=
sp; |


|           &nbs=
p;  |           =
             &nb=
sp;     | 3.3.2)      =
;        |


| mutability   | The attempted modification   | PUT=
 (Section        |


|           &nbs=
p;  | is not compatible with the   | 3.3.1), PATCH  =
;     |


|           &nbs=
p;  | target attributes mutability | (Section 3.3.2)   &=
nbsp; |


|            &nb=
sp; | or current state (e.g.       | =
;            &nb=
sp;       |


|           &nbs=
p;  | modification of an immutable |      =
;            &nb=
sp;  |


|           &nbs=
p;  | attribute with an existing   |    &=
nbsp;            =
;    |


|           &nbs=
p;  | value).         &nbs=
p;            | =
             &nb=
sp;      |


| invalidSynta | The request body message     | POS=
T (Search -      |


| x            |=
 structure was invalid or did | Section 3.2.2,     =
 |


|           &nbs=
p;  | not conform to the request   | Create - Section &n=
bsp;  |


|           &nbs=
p;  | schema.          &nb=
sp;           | 3.1, B=
ulk - Section |


|           &nbs=
p;  |           =
            &nbs=
p;      | 3.5), PUT (Section  |

|           &nbs=
p;  |           =
            &nbs=
p;      | 3.3.1)      =
;        |


| invalidPath  | The path attribute was    &nb=
sp;  | PATCH (Section      |


|            &nb=
sp; | invalid or malformed (see    | 3.3.2)  &=
nbsp;           |


|           &nbs=
p;  | Figure 4).         &=
nbsp;         |   &nb=
sp;            &=
nbsp;    |


| noTarget     | The specified "path" did not | PAT=
CH (Section      |


|           &nbs=
p;  | yield an attribute or        |=
 3.3.2)            &n=
bsp; |


|           &nbs=
p;  | attribute value that could   |    &=
nbsp;            =
;    |


|           &nbs=
p;  | be operated on. This occurs  |     =
            &nbs=
p;   |


|           &nbs=
p;  | when the specified "path"    |   &n=
bsp;            =
     |


|           &nbs=
p;  | value contains a filter that |      =
;            &nb=
sp;  |


|           &nbs=
p;  | yields no match.        &=
nbsp;    |        &nb=
sp;            |=



| invalidValue | A required value was     &nbs=
p;   | GET (Section        |


|           &nbs=
p;  | missing, or the value        |=
 3.2.2), POST        |


|           &nbs=
p;  | specified was not compatible | (Create - Section   |


|           &nbs=
p;  | with the operation or        |=
 3.1, Search -       |


|           &nbs=
p;  | attribute type (see Section  | Section 3.2.2), PUT |


|           &nbs=
p;  | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),   =
 |


|           &nbs=
p;  | ma]).          =
            &nbs=
p; | PATCH (Section      |


|           &nbs=
p;  |           =
            &nbs=
p;      | 3.3.2)      =
;        |


| invalidVers  | The specified API version is | GET (Section =
       |


|            &nb=
sp; | not supported (see Section   | 3.2.2), POST (ALL), |


|           &nbs=
p;  | 3.11).          =
;             | P=
UT (Section        |


|           &nbs=
p;  |           =
            &nbs=
p;      | 3.3.1), PATCH    &nbs=
p;  |


|           &nbs=
p;  |           =
            &nbs=
p;      | (Section 3.3.2),    |=



|           &nbs=
p;  |           =
            &nbs=
p;      | DELETE (Section     |=



|           &nbs=
p;  |           =
            &nbs=
p;      | 3.4)      &=
nbsp;         |


+--------------+------------------------------+---------------------+




I plan to put these into draft 07 of the API and will=
 publish over the weekend.






 






As always, feedback welcome!






 





















 
















 




 

_______________________________________________
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-05D0A97B-30AF-4C47-BC80-EDB9C5730D16-- From nobody Mon Jun 30 11:14:33 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6BC1A0444 for ; Mon, 30 Jun 2014 11:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnokI2AftYAw for ; Mon, 30 Jun 2014 11:14:08 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465EB1A0428 for ; Mon, 30 Jun 2014 11:14:08 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5UIE6x6023260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Jun 2014 18:14:07 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5UIE5p8020694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Jun 2014 18:14:06 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5UIE5Vs015533; Mon, 30 Jun 2014 18:14:05 GMT Received: from [192.168.1.188] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Jun 2014 11:14:04 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_53F77AF0-4BC3-4863-9546-10C085B17F1E" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: Date: Mon, 30 Jun 2014 11:14:03 -0700 Message-Id: References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1878.2) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/HTmxQgCVAIxo7TswtJxyYUpdhfk Cc: Scim WG Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 18:14:16 -0000 --Apple-Mail=_53F77AF0-4BC3-4863-9546-10C085B17F1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 After thinking about this a bit, I think URIs for scimType is the best = way to go. While having a URI means a new IANA registry, it is probably = simpler to implement and allows for the capability for SPs to extend = errors as Kelly and David have requested. It is also in line with: = http://tools.ietf.org/html/draft-nottingham-http-problem-06 As many are off-line much of the week due to Canadian and US holidays, = and the window for submissions for IETF90 closes Friday, I will start = work amending the API draft to include the error codes listed at the = start of this thread but with URIs and will add the IANA registry for = errors. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 30, 2014, at 8:56 AM, Phil Hunt wrote: > David had a similar comment.=20 >=20 > What if there was a separate attribute: spCode that allows the service = provider to indicate non-protocol errors? >=20 > Phil >=20 > On Jun 30, 2014, at 7:46, Kelly Grizzle = wrote: >=20 >> I remember that one of the initial drivers for this ticket was the = ability for service providers to send back error codes that are specific = to the service provider. >> =20 >> An example on a user creation might be =93error 28738=94 =85 =93client = has exceeded the maximum number of users in their organization=94. = Ideally the SP would be able to communicate back the general HTTP error = code, a provider-specific error code, and a human readable description. >> =20 >> I think that scimType would allow for this if the list were = extensible. >> =20 >> --Kelly >> =20 >> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >> Sent: Sunday, June 29, 2014 3:27 PM >> To: Kelly Grizzle >> Cc: Scim WG >> Subject: Re: [scim] Proposed Detail Errors >> =20 >> Could be if we use URIs for codes=20 >>=20 >> Phil >>=20 >> On Jun 29, 2014, at 13:09, Kelly Grizzle = wrote: >>=20 >> I like these, Phil. Should this list of error codes be extensible? >> =20 >> =20 >> From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt >> Sent: Friday, June 27, 2014 1:47 PM >> To: Scim WG >> Subject: [scim] Proposed Detail Errors >> =20 >> After reviewing the API and Schema docs, here is a first cut of the = detailed error codes. >> =20 >> For HTTP Status 400 (Bad Request) responses, the following detail >> error types are defined: >> =20 >> +--------------+------------------------------+---------------------+ >> | scimType | Description | Applicability | >> +--------------+------------------------------+---------------------+ >> | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | >> | r | was invalid (does not comply | POST (Search - | >> | | with Figure 1) or the | Section 3.2.3), | >> | | specified attribute and | PATCH (Path Filter | >> | | filter comparison | - Section 3.3.2) | >> | | combination is not | | >> | | supported. | | >> | uniqueness | One or more of attribute | POST (Create - | >> | | values is already in use or | Section 3.1), PUT | >> | | is reserved. | (Section 3.3.1), | >> | | | PATCH (Section | >> | | | 3.3.2) | >> | mutability | The attempted modification | PUT (Section | >> | | is not compatible with the | 3.3.1), PATCH | >> | | target attributes mutability | (Section 3.3.2) | >> | | or current state (e.g. | | >> | | modification of an immutable | | >> | | attribute with an existing | | >> | | value). | | >> | invalidSynta | The request body message | POST (Search - | >> | x | structure was invalid or did | Section 3.2.2, | >> | | not conform to the request | Create - Section | >> | | schema. | 3.1, Bulk - Section | >> | | | 3.5), PUT (Section | >> | | | 3.3.1) | >> | invalidPath | The path attribute was | PATCH (Section | >> | | invalid or malformed (see | 3.3.2) | >> | | Figure 4). | | >> | noTarget | The specified "path" did not | PATCH (Section | >> | | yield an attribute or | 3.3.2) | >> | | attribute value that could | | >> | | be operated on. This occurs | | >> | | when the specified "path" | | >> | | value contains a filter that | | >> | | yields no match. | | >> | invalidValue | A required value was | GET (Section | >> | | missing, or the value | 3.2.2), POST | >> | | specified was not compatible | (Create - Section | >> | | with the operation or | 3.1, Search - | >> | | attribute type (see Section | Section 3.2.2), PUT | >> | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | >> | | ma]). | PATCH (Section | >> | | | 3.3.2) | >> | invalidVers | The specified API version is | GET (Section | >> | | not supported (see Section | 3.2.2), POST (ALL), | >> | | 3.11). | PUT (Section | >> | | | 3.3.1), PATCH | >> | | | (Section 3.3.2), | >> | | | DELETE (Section | >> | | | 3.4) | >> +--------------+------------------------------+---------------------+ >> I plan to put these into draft 07 of the API and will publish over = the weekend. >> =20 >> As always, feedback welcome! >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =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 --Apple-Mail=_53F77AF0-4BC3-4863-9546-10C085B17F1E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
After thinking about this a bit, I think URIs = for scimType is the best way to go. While having a URI means a new IANA = registry, it is probably simpler to implement and allows for the = capability for SPs to extend errors as Kelly and David have requested. =  It is also in line with: http:= //tools.ietf.org/html/draft-nottingham-http-problem-06

<= /div>As many are off-line much of the week due to Canadian and US = holidays, and the window for submissions for IETF90 closes Friday, I = will start work amending the API draft to include the error codes listed = at the start of this thread but with URIs and will add the IANA registry = for errors.

Phil

On Jun 30, 2014, at 8:56 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:

David had a similar = comment. 

What if there was a separate = attribute: spCode that allows the service provider to indicate = non-protocol errors?

Phil

On Jun 30, 2014, = at 7:46, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I remember that one of the initial drivers for = this ticket was the ability for service providers to send back error = codes that are specific to the service provider.

 

An example on a user creation might be =93error = 28738=94 =85 =93client has exceeded the maximum number of users in their = organization=94.  Ideally the SP would be able to communicate back the general HTTP error code, a provider-specific = error code, and a human readable description.

 

I think that scimType would allow for this if the = list were extensible.

 

--Kelly

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Sunday, June 29, 2014 3:27 PM
To: Kelly Grizzle
Cc: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

Could be if we use URIs for codes 

Phil


On Jun 29, 2014, at 13:09, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I like these, Phil.  Should this list of = error codes be extensible?

 

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, June 27, 2014 1:47 PM
To: Scim WG
Subject: [scim] Proposed Detail Errors

 

After reviewing the API and Schema docs, here is a = first cut of the detailed error codes.

 

For HTTP =
Status 400 (Bad Request) responses, the following =
detail
   error types are defined:
 
= 
+--------------+------------------------------+---------------------+=

| scimType     | =
Description          &nb=
sp;       | =
Applicability       |
= 
+--------------+------------------------------+---------------------+=

| invalidFilte | The specified filter syntax  | GET(Section =
3.2.2), |
| =
r            | =
was invalid (does not comply | POST (Search =
-      |
= 
|           &n=
bsp;  | with Figure 1) or =
the        | Section =
3.2.3),     |
= 
|           &n=
bsp;  | specified attribute and      | =
PATCH (Path Filter  |
= 
|           &n=
bsp;  | filter =
comparison          &nbs=
p; | - Section 3.3.2)    |
= 
|           &n=
bsp;  | combination is =
not           =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | =
supported.          &nbs=
p;        =
|            &=
nbsp;        |
| uniqueness   | One or more of =
attribute     | POST (Create =
-      |
= 
|           &n=
bsp;  | values is already in use or  | Section 3.1), =
PUT   |
= 
|           &n=
bsp;  | is =
reserved.           =
;      | (Section 3.3.1),    =
|
= 
|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | PATCH =
(Section      |
= 
|           &n=
bsp;  =
|            &=
nbsp;       =
          | =
3.3.2)           &n=
bsp;  |
| mutability   | The attempted modification   | =
PUT (Section        =
|
= 
|           &n=
bsp;  | is not compatible with the   | 3.3.1), =
PATCH       |
= 
|           &n=
bsp;  | target attributes mutability | (Section =
3.3.2)     |
|           =
   | or current state =
(e.g.       =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | modification of an immutable =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | attribute with an existing   =
|            &=
nbsp;        |
= 
|           &n=
bsp;  | =
value).           &=
nbsp;          =
|           =
          |

| invalidSynta | The request body message     | =
POST (Search -      |


| =
x            | =
structure was invalid or did | Section =
3.2.2,      |

=

|           &n=
bsp;  | not conform to the request   | Create - =
Section    |

=

|           &n=
bsp;  | =
schema.          =
            | =
3.1, Bulk - Section |

=

|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | 3.5), PUT (Section  =
|

=

|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | =
3.3.1)           &n=
bsp;  |


| invalidPath  | The path attribute =
was       | PATCH =
(Section      |


|         =
     | invalid or malformed =
(see    | =
3.3.2)           &n=
bsp;  |

=

|           &n=
bsp;  | Figure =
4).            =
;       =
|            &=
nbsp;        |


| noTarget     | The specified "path" did not | =
PATCH (Section      |

=

|           &n=
bsp;  | yield an attribute =
or        | 3.3.2)  =
            |<=
o:p>

=

|           &n=
bsp;  | attribute value that could   =
|            &=
nbsp;        |

=

|           &n=
bsp;  | be operated on. This occurs  =
|            &=
nbsp;        |

=

|           &n=
bsp;  | when the specified "path"    =
|            &=
nbsp;        |

=

|           &n=
bsp;  | value contains a filter that =
|            &=
nbsp;        |

=

|           &n=
bsp;  | yields no =
match.           &n=
bsp; =
|            &=
nbsp;        |


| invalidValue | A required value =
was         | GET =
(Section        |

=

|           &n=
bsp;  | missing, or the =
value        | 3.2.2), POST =
       |

=

|           &n=
bsp;  | specified was not compatible | (Create - =
Section   |

=

|           &n=
bsp;  | with the operation =
or        | 3.1, Search =
-       |

=

|           &n=
bsp;  | attribute type (see Section  | Section 3.2.2), PUT =
|

=

|           &n=
bsp;  | 2.1 [I-D.ietf-scim-core-sche | (Section =
3.3.1),    |

=

|           &n=
bsp;  | =
ma]).           &nb=
sp;            | =
PATCH (Section      |

=

|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | =
3.3.2)           &n=
bsp;  |


| invalidVers  | The specified API version is | GET =
(Section        |


|            =
  | not supported (see Section   | 3.2.2), POST =
(ALL), |

=

|           &n=
bsp;  | =
3.11).           &n=
bsp;           | PUT =
(Section        |

=

|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | 3.3.1), =
PATCH       |

=

|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | (Section 3.3.2),    =
|

=

|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | DELETE (Section     =
|

=

|           &n=
bsp;  =
|            &=
nbsp;           &nb=
sp;     | =
3.4)           &nbs=
p;    |

=

+--------------+------------------------------+---------------------+=



I plan to put these into draft 07 of the API =
and will publish over the weekend.




 




As always, feedback welcome!




 






















Phil




 




@independentid





phil.hunt@oracle.com<=
/o:p>




 














 


 

_______________________________________________
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=_53F77AF0-4BC3-4863-9546-10C085B17F1E-- From nobody Mon Jun 30 12:24:24 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAEB1A037D for ; Mon, 30 Jun 2014 12:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXPJl_A6FMjy for ; Mon, 30 Jun 2014 12:24:17 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BFA1A0379 for ; Mon, 30 Jun 2014 12:24:16 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) with Microsoft SMTP Server (TLS) id 15.0.974.11; Mon, 30 Jun 2014 19:24:14 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0974.002; Mon, 30 Jun 2014 19:24:14 +0000 From: Anthony Nadalin To: Phil Hunt , Kelly Grizzle Thread-Topic: [scim] Proposed Detail Errors Thread-Index: AQHPkjhIzbP18zhaFUGCaYkX6dnJmZuIh7iAgAAE3ICAATM9AIAAE3GAgAAmcoCAABN/MA== Date: Mon, 30 Jun 2014 19:24:14 +0000 Message-ID: References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> 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:ee43::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(199002)(189002)(51444003)(377454003)(19580405001)(83322001)(15975445006)(76176999)(54356999)(99396002)(19580395003)(64706001)(85306003)(50986999)(77982001)(76482001)(81542001)(80022001)(79102001)(81342001)(20776003)(16236675004)(46102001)(92566001)(16601075003)(107046002)(74502001)(31966008)(33646001)(21056001)(93886003)(74662001)(19625215002)(86362001)(4396001)(101416001)(15202345003)(95666004)(19300405004)(99286002)(85852003)(83072002)(87936001)(74316001)(76576001)(105586002)(106356001)(2656002)(106116001)(108616002)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB309; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_d6d14699caab45d98a7f660659a78e8dBLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/yXWR8ttj7QdLbEBkKVE8BOJRtjM Cc: Scim WG Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 19:24:22 -0000 --_000_d6d14699caab45d98a7f660659a78e8dBLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Isn't this going to be a continued problems with IANA updates ? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Monday, June 30, 2014 11:14 AM To: Kelly Grizzle Cc: Scim WG Subject: Re: [scim] Proposed Detail Errors After thinking about this a bit, I think URIs for scimType is the best way = to go. While having a URI means a new IANA registry, it is probably simpler= to implement and allows for the capability for SPs to extend errors as Kel= ly and David have requested. It is also in line with: http://tools.ietf.or= g/html/draft-nottingham-http-problem-06 As many are off-line much of the week due to Canadian and US holidays, and = the window for submissions for IETF90 closes Friday, I will start work amen= ding the API draft to include the error codes listed at the start of this t= hread but with URIs and will add the IANA registry for errors. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 30, 2014, at 8:56 AM, Phil Hunt > wrote: David had a similar comment. What if there was a separate attribute: spCode that allows the service prov= ider to indicate non-protocol errors? Phil On Jun 30, 2014, at 7:46, Kelly Grizzle > wrote: I remember that one of the initial drivers for this ticket was the ability = for service providers to send back error codes that are specific to the ser= vice provider. An example on a user creation might be "error 28738" ... "client has exceed= ed the maximum number of users in their organization". Ideally the SP woul= d be able to communicate back the general HTTP error code, a provider-speci= fic error code, and a human readable description. I think that scimType would allow for this if the list were extensible. --Kelly From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Sunday, June 29, 2014 3:27 PM To: Kelly Grizzle Cc: Scim WG Subject: Re: [scim] Proposed Detail Errors Could be if we use URIs for codes Phil On Jun 29, 2014, at 13:09, Kelly Grizzle > wrote: I like these, Phil. Should this list of error codes be extensible? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Friday, June 27, 2014 1:47 PM To: Scim WG Subject: [scim] Proposed Detail Errors After reviewing the API and Schema docs, here is a first cut of the detaile= d error codes. For HTTP Status 400 (Bad Request) responses, the following detail error types are defined: +--------------+------------------------------+---------------------+ | scimType | Description | Applicability | +--------------+------------------------------+---------------------+ | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | | r | was invalid (does not comply | POST (Search - | | | with Figure 1) or the | Section 3.2.3), | | | specified attribute and | PATCH (Path Filter | | | filter comparison | - Section 3.3.2) | | | combination is not | | | | supported. | | | uniqueness | One or more of attribute | POST (Create - | | | values is already in use or | Section 3.1), PUT | | | is reserved. | (Section 3.3.1), | | | | PATCH (Section | | | | 3.3.2) | | mutability | The attempted modification | PUT (Section | | | is not compatible with the | 3.3.1), PATCH | | | target attributes mutability | (Section 3.3.2) | | | or current state (e.g. | | | | modification of an immutable | | | | attribute with an existing | | | | value). | | | invalidSynta | The request body message | POST (Search - | | x | structure was invalid or did | Section 3.2.2, | | | not conform to the request | Create - Section | | | schema. | 3.1, Bulk - Section | | | | 3.5), PUT (Section | | | | 3.3.1) | | invalidPath | The path attribute was | PATCH (Section | | | invalid or malformed (see | 3.3.2) | | | Figure 4). | | | noTarget | The specified "path" did not | PATCH (Section | | | yield an attribute or | 3.3.2) | | | attribute value that could | | | | be operated on. This occurs | | | | when the specified "path" | | | | value contains a filter that | | | | yields no match. | | | invalidValue | A required value was | GET (Section | | | missing, or the value | 3.2.2), POST | | | specified was not compatible | (Create - Section | | | with the operation or | 3.1, Search - | | | attribute type (see Section | Section 3.2.2), PUT | | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | | | ma]). | PATCH (Section | | | | 3.3.2) | | invalidVers | The specified API version is | GET (Section | | | not supported (see Section | 3.2.2), POST (ALL), | | | 3.11). | PUT (Section | | | | 3.3.1), PATCH | | | | (Section 3.3.2), | | | | DELETE (Section | | | | 3.4) | +--------------+------------------------------+---------------------+ I plan to put these into draft 07 of the API and will publish over the week= end. As always, feedback welcome! 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 --_000_d6d14699caab45d98a7f660659a78e8dBLUPR03MB309namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Isn’t this going to= be a continued problems with IANA updates ?

 

From: scim [= mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, June 30, 2014 11:14 AM
To: Kelly Grizzle
Cc: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

After thinking about this a bit, I think URIs for sc= imType is the best way to go. While having a URI means a new IANA registry,= it is probably simpler to implement and allows for the capability for SPs = to extend errors as Kelly and David have requested.  It is also in line with: http://tools.ietf.org/htm= l/draft-nottingham-http-problem-06

 

As many are off-line much of the week due to Canadia= n and US holidays, and the window for submissions for IETF90 closes Friday,= I will start work amending the API draft to include the error codes listed= at the start of this thread but with URIs and will add the IANA registry for errors.

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

On Jun 30, 2014, at 8:56 AM, Phil Hunt <phil.hunt@oracle.com> wrote:



David had a similar comment. 

 

What if there was a separate attribute: spCode that = allows the service provider to indicate non-protocol errors?


Phil


On Jun 30, 2014, at 7:46, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I remember that one of th= e initial drivers for this ticket was the ability for service providers to = send back error codes that are specific to the service provider.

 <= /p>

An example on a user crea= tion might be “error 28738” … “client has exceeded = the maximum number of users in their organization”.  Ideally the= SP would be able to communicate back the general HTTP error code, a provider-specific error= code, and a human readable description.

 <= /p>

I think that scimType wou= ld allow for this if the list were extensible.

 <= /p>

--Kelly=

 <= /p>

From: Phil Hun= t [mailto:phil.hunt@oracle.com]
Sent: Sunday, June 29, 2014 3:27 PM
To: Kelly Grizzle
Cc: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

Could be if we use URIs for codes 

Phil


On Jun 29, 2014, at 13:09, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I like these, Phil. = Should this list of error codes be extensible?

 <= /p>

 <= /p>

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, June 27, 2014 1:47 PM
To: Scim WG
Subject: [scim] Proposed Detail Errors

 

After reviewing the API and Schema docs, here is a f= irst cut of the detailed error codes.

 

For HTTP Status 4=
00 (Bad Request) responses, the following detail
   error types are defined:
 
+--------------+------------------------------+-----------=
----------+
| scimType     | Description   &nbs=
p;            &=
nbsp; | Applicability       |

+--------------+------------------------------+-----------=
----------+


| invalidFilte | The specified filter syntax  | GET(Section 3.2.2=
), |


| r            =
| was invalid (does not comply | POST (Search -    &nbs=
p; |


|           &nb=
sp;  | with Figure 1) or the       =
 | Section 3.2.3),     |


|           &nb=
sp;  | specified attribute and      | PATCH (=
Path Filter  |


|           &nb=
sp;  | filter comparison       &nbs=
p;    | - Section 3.3.2)    |

|           &nb=
sp;  | combination is not       &nb=
sp;   |         &nbs=
p;           |=



|           &nb=
sp;  | supported.         =
;          |   =
            &nb=
sp;     |


| uniqueness   | One or more of attribute   &=
nbsp; | POST (Create -      |


|           &nb=
sp;  | values is already in use or  | Section 3.1), PUT &nbs=
p; |


|           &nb=
sp;  | is reserved.        &nb=
sp;        | (Section 3.3.1),  =
;  |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | PATCH (Section    =
;  |


|           &nb=
sp;  |          &nbs=
p;             =
      | 3.3.2)     &=
nbsp;        |


| mutability   | The attempted modification   | PU=
T (Section        |


|           &nb=
sp;  | is not compatible with the   | 3.3.1), PATCH &nb=
sp;     |


|           &nb=
sp;  | target attributes mutability | (Section 3.3.2)   =
;  |


|            &n=
bsp; | or current state (e.g.       |&nb=
sp;            =
        |


|           &nb=
sp;  | modification of an immutable |     &nb=
sp;            =
   |


|           &nb=
sp;  | attribute with an existing   |    =
;            &n=
bsp;    |


|           &nb=
sp;  | value).         &n=
bsp;            |&nb=
sp;             =
;       |


| invalidSynta | The request body message     | PO=
ST (Search -      |


| x            =
| structure was invalid or did | Section 3.2.2,    &nbs=
p; |


|           &nb=
sp;  | not conform to the request   | Create - Section =
   |


|           &nb=
sp;  | schema.          &=
nbsp;           | 3.=
1, Bulk - Section |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.5), PUT (Section  |=



|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.1)     &=
nbsp;        |


| invalidPath  | The path attribute was    &n=
bsp;  | PATCH (Section      |

|            &n=
bsp; | invalid or malformed (see    | 3.3.2)  =
;            |<=
/o:p>


|           &nb=
sp;  | Figure 4).         =
;          |   =
            &nb=
sp;     |


| noTarget     | The specified "path" di=
d not | PATCH (Section      |


|           &nb=
sp;  | yield an attribute or       =
 | 3.3.2)            =
;  |


|           &nb=
sp;  | attribute value that could   |    =
;            &n=
bsp;    |


|           &nb=
sp;  | be operated on. This occurs  |    &nbs=
p;            &=
nbsp;   |


|           &nb=
sp;  | when the specified "path"    | &n=
bsp;            =
;       |


|           &nb=
sp;  | value contains a filter that |     &nb=
sp;            =
   |


|           &nb=
sp;  | yields no match.        =
;     |        =
             |<=
o:p>


| invalidValue | A required value was     &nb=
sp;   | GET (Section        |<=
o:p>


|           &nb=
sp;  | missing, or the value       =
 | 3.2.2), POST        |

|           &nb=
sp;  | specified was not compatible | (Create - Section   |<=
o:p>


|           &nb=
sp;  | with the operation or       =
 | 3.1, Search -       |


|           &nb=
sp;  | attribute type (see Section  | Section 3.2.2), PUT |<=
/o:p>


|           &nb=
sp;  | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),  &nbs=
p; |


|           &nb=
sp;  | ma]).         &nbs=
p;            &=
nbsp; | PATCH (Section      |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.2)     &=
nbsp;        |


| invalidVers  | The specified API version is | GET (Section =
;       |


|            &n=
bsp; | not supported (see Section   | 3.2.2), POST (ALL), |<=
o:p>


|           &nb=
sp;  | 3.11).         &nb=
sp;            =
 | PUT (Section        |

|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.3.1), PATCH    =
   |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | (Section 3.3.2),    |<=
o:p>


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | DELETE (Section   &nbs=
p; |


|           &nb=
sp;  |          &nbs=
p;            &=
nbsp;      | 3.4)     &nb=
sp;          |

+--------------+------------------------------+-----------=
----------+




I plan to put these into draft 07 of the API and wil=
l publish over the weekend.






 






As always, feedback welcome!






 





















 
















 




 

_______________________________________________
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

 

--_000_d6d14699caab45d98a7f660659a78e8dBLUPR03MB309namprd03pro_-- From nobody Mon Jun 30 12:35:21 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F801A0659 for ; Mon, 30 Jun 2014 12:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj0EmgX9yWlV for ; Mon, 30 Jun 2014 12:35:15 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D824E1A037F for ; Mon, 30 Jun 2014 12:35:14 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5UJZDLr021837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Jun 2014 19:35:14 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5UJZCWB025064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jun 2014 19:35:13 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5UJZBax022631; Mon, 30 Jun 2014 19:35:11 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Jun 2014 12:35:10 -0700 References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-8F946159-9531-48FE-85D8-815ECB7FCACF Content-Transfer-Encoding: 7bit Message-Id: <3B339C76-F410-41EF-A574-EA3FA85D8590@oracle.com> X-Mailer: iPhone Mail (11D201) From: Phil Hunt Date: Mon, 30 Jun 2014 12:35:01 -0700 To: Anthony Nadalin X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/iJRsWJVvdq1tOxnpsuw_w7Z6PZ8 Cc: Scim WG , Kelly Grizzle Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 19:35:19 -0000 --Apple-Mail-8F946159-9531-48FE-85D8-815ECB7FCACF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable How so? Phil > On Jun 30, 2014, at 12:24, Anthony Nadalin wrote: >=20 > Isn=E2=80=99t this going to be a continued problems with IANA updates ? > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Monday, June 30, 2014 11:14 AM > To: Kelly Grizzle > Cc: Scim WG > Subject: Re: [scim] Proposed Detail Errors > =20 > After thinking about this a bit, I think URIs for scimType is the best way= to go. While having a URI means a new IANA registry, it is probably simpler= to implement and allows for the capability for SPs to extend errors as Kell= y and David have requested. It is also in line with: http://tools.ietf.org/= html/draft-nottingham-http-problem-06 > =20 > As many are off-line much of the week due to Canadian and US holidays, and= the window for submissions for IETF90 closes Friday, I will start work amen= ding the API draft to include the error codes listed at the start of this th= read but with URIs and will add the IANA registry for errors. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > On Jun 30, 2014, at 8:56 AM, Phil Hunt wrote: >=20 >=20 > David had a similar comment.=20 > =20 > What if there was a separate attribute: spCode that allows the service pro= vider to indicate non-protocol errors? >=20 > Phil >=20 > On Jun 30, 2014, at 7:46, Kelly Grizzle wrot= e: >=20 > I remember that one of the initial drivers for this ticket was the ability= for service providers to send back error codes that are specific to the ser= vice provider. > =20 > An example on a user creation might be =E2=80=9Cerror 28738=E2=80=9D =E2=80= =A6 =E2=80=9Cclient has exceeded the maximum number of users in their organi= zation=E2=80=9D. Ideally the SP would be able to communicate back the gener= al HTTP error code, a provider-specific error code, and a human readable des= cription. > =20 > I think that scimType would allow for this if the list were extensible. > =20 > --Kelly > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Sunday, June 29, 2014 3:27 PM > To: Kelly Grizzle > Cc: Scim WG > Subject: Re: [scim] Proposed Detail Errors > =20 > Could be if we use URIs for codes=20 >=20 > Phil >=20 > On Jun 29, 2014, at 13:09, Kelly Grizzle wro= te: >=20 > I like these, Phil. Should this list of error codes be extensible? > =20 > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Friday, June 27, 2014 1:47 PM > To: Scim WG > Subject: [scim] Proposed Detail Errors > =20 > After reviewing the API and Schema docs, here is a first cut of the detail= ed error codes. > =20 > For HTTP Status 400 (Bad Request) responses, the following detail > error types are defined: > =20 > +--------------+------------------------------+---------------------+ > | scimType | Description | Applicability | > +--------------+------------------------------+---------------------+ > | invalidFilte | The specified filter syntax | GET(Section 3.2.2), | > | r | was invalid (does not comply | POST (Search - | > | | with Figure 1) or the | Section 3.2.3), | > | | specified attribute and | PATCH (Path Filter | > | | filter comparison | - Section 3.3.2) | > | | combination is not | | > | | supported. | | > | uniqueness | One or more of attribute | POST (Create - | > | | values is already in use or | Section 3.1), PUT | > | | is reserved. | (Section 3.3.1), | > | | | PATCH (Section | > | | | 3.3.2) | > | mutability | The attempted modification | PUT (Section | > | | is not compatible with the | 3.3.1), PATCH | > | | target attributes mutability | (Section 3.3.2) | > | | or current state (e.g. | | > | | modification of an immutable | | > | | attribute with an existing | | > | | value). | | > | invalidSynta | The request body message | POST (Search - | > | x | structure was invalid or did | Section 3.2.2, | > | | not conform to the request | Create - Section | > | | schema. | 3.1, Bulk - Section | > | | | 3.5), PUT (Section | > | | | 3.3.1) | > | invalidPath | The path attribute was | PATCH (Section | > | | invalid or malformed (see | 3.3.2) | > | | Figure 4). | | > | noTarget | The specified "path" did not | PATCH (Section | > | | yield an attribute or | 3.3.2) | > | | attribute value that could | | > | | be operated on. This occurs | | > | | when the specified "path" | | > | | value contains a filter that | | > | | yields no match. | | > | invalidValue | A required value was | GET (Section | > | | missing, or the value | 3.2.2), POST | > | | specified was not compatible | (Create - Section | > | | with the operation or | 3.1, Search - | > | | attribute type (see Section | Section 3.2.2), PUT | > | | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1), | > | | ma]). | PATCH (Section | > | | | 3.3.2) | > | invalidVers | The specified API version is | GET (Section | > | | not supported (see Section | 3.2.2), POST (ALL), | > | | 3.11). | PUT (Section | > | | | 3.3.1), PATCH | > | | | (Section 3.3.2), | > | | | DELETE (Section | > | | | 3.4) | > +--------------+------------------------------+---------------------+ > I plan to put these into draft 07 of the API and will publish over the wee= kend. > =20 > As always, feedback welcome! > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =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 > =20 --Apple-Mail-8F946159-9531-48FE-85D8-815ECB7FCACF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
How so?

Phil

On J= un 30, 2014, at 12:24, Anthony Nadalin <tonynad@microsoft.com> wrote:

=

Isn=E2=80=99t this going to= be a continued problems with IANA updates ?

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, June 30, 2014 11:14 AM
To: Kelly Grizzle
Cc: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

After thinking about this a bit, I think URIs for sci= mType is the best way to go. While having a URI means a new IANA registry, i= t is probably simpler to implement and allows for the capability for SPs to e= xtend errors as Kelly and David have requested.  It is also in line with: http://tools.ietf.org/html/= draft-nottingham-http-problem-06

 

As many are off-line much of the week due to Canadian= and US holidays, and the window for submissions for IETF90 closes Friday, I= will start work amending the API draft to include the error codes listed at= the start of this thread but with URIs and will add the IANA registry for errors.

 

Phil

 

On Jun 30, 2014, at 8:56 AM, Phil Hunt <phil.hunt@oracle.com> wrote:=



David had a similar comment. 

 

What if there was a separate attribute: spCode that a= llows the service provider to indicate non-protocol errors?


Phil


On Jun 30, 2014, at 7:46, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I remember that one of the i= nitial drivers for this ticket was the ability for service providers to send= back error codes that are specific to the service provider.

 

An example on a user creati= on might be =E2=80=9Cerror 28738=E2=80=9D =E2=80=A6 =E2=80=9Cclient has exce= eded the maximum number of users in their organization=E2=80=9D.  Ideal= ly the SP would be able to communicate back the general HTTP error code, a provider-specific error c= ode, and a human readable description.

 

I think that scimType would= allow for this if the list were extensible.

 

--Kelly

 

From: Phil Hunt [= mailto:phil.hunt@oracle.com]
Sent: Sunday, June 29, 2014 3:27 PM
To: Kelly Grizzle
Cc: Scim WG
Subject: Re: [scim] Proposed Detail Errors

 

Could be if we use URIs for codes 

Phil


On Jun 29, 2014, at 13:09, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I like these, Phil.  S= hould this list of error codes be extensible?

 

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, June 27, 2014 1:47 PM
To: Scim WG
Subject: [scim] Proposed Detail Errors

 

After reviewing the API and Schema docs, here is a fi= rst cut of the detailed error codes.

 

For HTTP Status 40=
0 (Bad Request) responses, the following detail
   error types are defined:
 
+--------------+------------------------------+---------------------+
| scimType     | Description    =
;            &nb=
sp; | Applicability       |
+--------------+------------------------------+---------------------+
| invalidFilte | The specified filter syntax  | GET(Section 3.2.2)=
, |
| r            |=
 was invalid (does not comply | POST (Search -     =
 |
|           &nbs=
p;  | with Figure 1) or the        |=
 Section 3.2.3),     |
|           &nbs=
p;  | specified attribute and      | PATCH (Pa=
th Filter  |
|           &nbs=
p;  | filter comparison        =
    | - Section 3.3.2)    |
|           &nbs=
p;  | combination is not        =
;   |          &=
nbsp;          |

|           &nbs=
p;  | supported.         &=
nbsp;         |   &nb=
sp;            &=
nbsp;    |


| uniqueness   | One or more of attribute   &n=
bsp; | POST (Create -      |


|           &nbs=
p;  | values is already in use or  | Section 3.1), PUT  =
 |


|           &nbs=
p;  | is reserved.         =
;        | (Section 3.3.1),  &n=
bsp; |


|           &nbs=
p;  |           =
            &nbs=
p;      | PATCH (Section    &nb=
sp; |


|           &nbs=
p;  |           =
             &nb=
sp;     | 3.3.2)      =
;        |


| mutability   | The attempted modification   | PUT=
 (Section        |


|           &nbs=
p;  | is not compatible with the   | 3.3.1), PATCH  =
;     |


|           &nbs=
p;  | target attributes mutability | (Section 3.3.2)   &=
nbsp; |


|            &nb=
sp; | or current state (e.g.       | =
;            &nb=
sp;       |


|           &nbs=
p;  | modification of an immutable |      =
;            &nb=
sp;  |


|           &nbs=
p;  | attribute with an existing   |    &=
nbsp;            =
;    |


|           &nbs=
p;  | value).         &nbs=
p;            | =
             &nb=
sp;      |


| invalidSynta | The request body message     | POS=
T (Search -      |


| x            |=
 structure was invalid or did | Section 3.2.2,     =
 |


|           &nbs=
p;  | not conform to the request   | Create - Section &n=
bsp;  |


|           &nbs=
p;  | schema.          &nb=
sp;           | 3.1, B=
ulk - Section |


|           &nbs=
p;  |           =
            &nbs=
p;      | 3.5), PUT (Section  |

|           &nbs=
p;  |           =
            &nbs=
p;      | 3.3.1)      =
;        |


| invalidPath  | The path attribute was    &nb=
sp;  | PATCH (Section      |


|            &nb=
sp; | invalid or malformed (see    | 3.3.2)  &=
nbsp;           |


|           &nbs=
p;  | Figure 4).         &=
nbsp;         |   &nb=
sp;            &=
nbsp;    |


| noTarget     | The specified "path" did not | PAT=
CH (Section      |


|           &nbs=
p;  | yield an attribute or        |=
 3.3.2)            &n=
bsp; |


|           &nbs=
p;  | attribute value that could   |    &=
nbsp;            =
;    |


|           &nbs=
p;  | be operated on. This occurs  |     =
            &nbs=
p;   |


|           &nbs=
p;  | when the specified "path"    |   &n=
bsp;            =
     |


|           &nbs=
p;  | value contains a filter that |      =
;            &nb=
sp;  |


|           &nbs=
p;  | yields no match.        &=
nbsp;    |        &nb=
sp;            |=



| invalidValue | A required value was     &nbs=
p;   | GET (Section        |


|           &nbs=
p;  | missing, or the value        |=
 3.2.2), POST        |


|           &nbs=
p;  | specified was not compatible | (Create - Section   |


|           &nbs=
p;  | with the operation or        |=
 3.1, Search -       |


|           &nbs=
p;  | attribute type (see Section  | Section 3.2.2), PUT |


|           &nbs=
p;  | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),   =
 |


|           &nbs=
p;  | ma]).          =
            &nbs=
p; | PATCH (Section      |


|           &nbs=
p;  |           =
            &nbs=
p;      | 3.3.2)      =
;        |


| invalidVers  | The specified API version is | GET (Section =
       |


|            &nb=
sp; | not supported (see Section   | 3.2.2), POST (ALL), |


|           &nbs=
p;  | 3.11).          =
;             | P=
UT (Section        |


|           &nbs=
p;  |           =
            &nbs=
p;      | 3.3.1), PATCH    &nbs=
p;  |


|           &nbs=
p;  |           =
            &nbs=
p;      | (Section 3.3.2),    |=



|           &nbs=
p;  |           =
            &nbs=
p;      | DELETE (Section     |=



|           &nbs=
p;  |           =
            &nbs=
p;      | 3.4)      &=
nbsp;         |


+--------------+------------------------------+---------------------+




I plan to put these into draft 07 of the API and will=
 publish over the weekend.






 






As always, feedback welcome!






 





















 
















 




 

_______________________________________________
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

 

= --Apple-Mail-8F946159-9531-48FE-85D8-815ECB7FCACF-- From nobody Mon Jun 30 14:44:02 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F9A1A0AF3 for ; Mon, 30 Jun 2014 14:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdV-SDDh3cCn for ; Mon, 30 Jun 2014 14:43:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238521A0AF2 for ; Mon, 30 Jun 2014 14:43:56 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) with Microsoft SMTP Server (TLS) id 15.0.974.11; Mon, 30 Jun 2014 21:43:53 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0974.002; Mon, 30 Jun 2014 21:43:53 +0000 From: Anthony Nadalin To: Phil Hunt Thread-Topic: [scim] Proposed Detail Errors Thread-Index: AQHPkjhIzbP18zhaFUGCaYkX6dnJmZuIh7iAgAAE3ICAATM9AIAAE3GAgAAmcoCAABN/MIAAAyCAgAAjebA= Date: Mon, 30 Jun 2014 21:43:52 +0000 Message-ID: <29451b18f13248d1834c27b71b006df5@BLUPR03MB309.namprd03.prod.outlook.com> References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> <3B339C76-F410-41EF-A574-EA3FA85D8590@oracle.com> In-Reply-To: <3B339C76-F410-41EF-A574-EA3FA85D8590@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(189002)(199002)(24454002)(51444003)(86362001)(4396001)(19625215002)(74662001)(15202345003)(101416001)(95666004)(16601075003)(74502001)(21056001)(31966008)(107046002)(93886003)(33646001)(105586002)(106356001)(76576001)(2656002)(106116001)(99286002)(74316001)(85852003)(87936001)(19300405004)(83072002)(77982001)(85306003)(50986999)(99396002)(19580395003)(19580405001)(83322001)(54356999)(15975445006)(76176999)(64706001)(16236675004)(92566001)(46102001)(81542001)(76482001)(79102001)(20776003)(80022001)(81342001)(108616002)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB309; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_29451b18f13248d1834c27b71b006df5BLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/EsHKUWLYXPtY63B_sQ5oKTmnQIM Cc: Scim WG , Kelly Grizzle Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 21:43:59 -0000 --_000_29451b18f13248d1834c27b71b006df5BLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uY2VybiBpcyB0aGF0IHRoaXMgY2FuIGNhdXNlIGNvbnRpbnVvdXMgY29kZSBjaGFuZ2VzIGlu IGRpZmZlcmVudCBjb2RlcyBiZWluZyByZWdpc3RlcmVkLCBpZGVhbGx5IHRoZXJlIHdvdWxkIG9u bHkgYmUgYSBjb3VwbGUgYW5kIHRoZXkgd291bGQgYmUgZnJvbSB0aGUgc3RhcnQgYnV0IHRoaXMg Y291bGQgZ3JvdyBhbmQgY2F1c2UgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMgd2l0aCBmb2xrcyBy ZWdpc3RlcmluZyBlcnJvciBjb2Rlcw0KDQpGcm9tOiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVuZSAzMCwgMjAxNCAxMjozNSBQTQ0KVG86 IEFudGhvbnkgTmFkYWxpbg0KQ2M6IEtlbGx5IEdyaXp6bGU7IFNjaW0gV0cNClN1YmplY3Q6IFJl OiBbc2NpbV0gUHJvcG9zZWQgRGV0YWlsIEVycm9ycw0KDQpIb3cgc28/DQoNClBoaWwNCg0KT24g SnVuIDMwLCAyMDE0LCBhdCAxMjoyNCwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29m dC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSXNu4oCZdCB0aGlz IGdvaW5nIHRvIGJlIGEgY29udGludWVkIHByb2JsZW1zIHdpdGggSUFOQSB1cGRhdGVzID8NCg0K RnJvbTogc2NpbSBbbWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBo aWwgSHVudA0KU2VudDogTW9uZGF5LCBKdW5lIDMwLCAyMDE0IDExOjE0IEFNDQpUbzogS2VsbHkg R3JpenpsZQ0KQ2M6IFNjaW0gV0cNClN1YmplY3Q6IFJlOiBbc2NpbV0gUHJvcG9zZWQgRGV0YWls IEVycm9ycw0KDQpBZnRlciB0aGlua2luZyBhYm91dCB0aGlzIGEgYml0LCBJIHRoaW5rIFVSSXMg Zm9yIHNjaW1UeXBlIGlzIHRoZSBiZXN0IHdheSB0byBnby4gV2hpbGUgaGF2aW5nIGEgVVJJIG1l YW5zIGEgbmV3IElBTkEgcmVnaXN0cnksIGl0IGlzIHByb2JhYmx5IHNpbXBsZXIgdG8gaW1wbGVt ZW50IGFuZCBhbGxvd3MgZm9yIHRoZSBjYXBhYmlsaXR5IGZvciBTUHMgdG8gZXh0ZW5kIGVycm9y cyBhcyBLZWxseSBhbmQgRGF2aWQgaGF2ZSByZXF1ZXN0ZWQuICBJdCBpcyBhbHNvIGluIGxpbmUg d2l0aDogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbm90dGluZ2hhbS1odHRwLXBy b2JsZW0tMDYNCg0KQXMgbWFueSBhcmUgb2ZmLWxpbmUgbXVjaCBvZiB0aGUgd2VlayBkdWUgdG8g Q2FuYWRpYW4gYW5kIFVTIGhvbGlkYXlzLCBhbmQgdGhlIHdpbmRvdyBmb3Igc3VibWlzc2lvbnMg Zm9yIElFVEY5MCBjbG9zZXMgRnJpZGF5LCBJIHdpbGwgc3RhcnQgd29yayBhbWVuZGluZyB0aGUg QVBJIGRyYWZ0IHRvIGluY2x1ZGUgdGhlIGVycm9yIGNvZGVzIGxpc3RlZCBhdCB0aGUgc3RhcnQg b2YgdGhpcyB0aHJlYWQgYnV0IHdpdGggVVJJcyBhbmQgd2lsbCBhZGQgdGhlIElBTkEgcmVnaXN0 cnkgZm9yIGVycm9ycy4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50 aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNv bTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQpPbiBKdW4gMzAsIDIwMTQsIGF0 IDg6NTYgQU0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCg0KDQpEYXZpZCBoYWQgYSBzaW1pbGFyIGNvbW1lbnQu DQoNCldoYXQgaWYgdGhlcmUgd2FzIGEgc2VwYXJhdGUgYXR0cmlidXRlOiBzcENvZGUgdGhhdCBh bGxvd3MgdGhlIHNlcnZpY2UgcHJvdmlkZXIgdG8gaW5kaWNhdGUgbm9uLXByb3RvY29sIGVycm9y cz8NCg0KUGhpbA0KDQpPbiBKdW4gMzAsIDIwMTQsIGF0IDc6NDYsIEtlbGx5IEdyaXp6bGUgPGtl bGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQu Y29tPj4gd3JvdGU6DQpJIHJlbWVtYmVyIHRoYXQgb25lIG9mIHRoZSBpbml0aWFsIGRyaXZlcnMg Zm9yIHRoaXMgdGlja2V0IHdhcyB0aGUgYWJpbGl0eSBmb3Igc2VydmljZSBwcm92aWRlcnMgdG8g c2VuZCBiYWNrIGVycm9yIGNvZGVzIHRoYXQgYXJlIHNwZWNpZmljIHRvIHRoZSBzZXJ2aWNlIHBy b3ZpZGVyLg0KDQpBbiBleGFtcGxlIG9uIGEgdXNlciBjcmVhdGlvbiBtaWdodCBiZSDigJxlcnJv ciAyODczOOKAnSDigKYg4oCcY2xpZW50IGhhcyBleGNlZWRlZCB0aGUgbWF4aW11bSBudW1iZXIg b2YgdXNlcnMgaW4gdGhlaXIgb3JnYW5pemF0aW9u4oCdLiAgSWRlYWxseSB0aGUgU1Agd291bGQg YmUgYWJsZSB0byBjb21tdW5pY2F0ZSBiYWNrIHRoZSBnZW5lcmFsIEhUVFAgZXJyb3IgY29kZSwg YSBwcm92aWRlci1zcGVjaWZpYyBlcnJvciBjb2RlLCBhbmQgYSBodW1hbiByZWFkYWJsZSBkZXNj cmlwdGlvbi4NCg0KSSB0aGluayB0aGF0IHNjaW1UeXBlIHdvdWxkIGFsbG93IGZvciB0aGlzIGlm IHRoZSBsaXN0IHdlcmUgZXh0ZW5zaWJsZS4NCg0KLS1LZWxseQ0KDQpGcm9tOiBQaGlsIEh1bnQg W21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NClNlbnQ6IFN1bmRheSwgSnVuZSAyOSwgMjAx NCAzOjI3IFBNDQpUbzogS2VsbHkgR3JpenpsZQ0KQ2M6IFNjaW0gV0cNClN1YmplY3Q6IFJlOiBb c2NpbV0gUHJvcG9zZWQgRGV0YWlsIEVycm9ycw0KDQpDb3VsZCBiZSBpZiB3ZSB1c2UgVVJJcyBm b3IgY29kZXMNCg0KUGhpbA0KDQpPbiBKdW4gMjksIDIwMTQsIGF0IDEzOjA5LCBLZWxseSBHcml6 emxlIDxrZWxseS5ncml6emxlQHNhaWxwb2ludC5jb208bWFpbHRvOmtlbGx5LmdyaXp6bGVAc2Fp bHBvaW50LmNvbT4+IHdyb3RlOg0KSSBsaWtlIHRoZXNlLCBQaGlsLiAgU2hvdWxkIHRoaXMgbGlz dCBvZiBlcnJvciBjb2RlcyBiZSBleHRlbnNpYmxlPw0KDQoNCkZyb206IHNjaW0gW21haWx0bzpz Y2ltLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IEZyaWRh eSwgSnVuZSAyNywgMjAxNCAxOjQ3IFBNDQpUbzogU2NpbSBXRw0KU3ViamVjdDogW3NjaW1dIFBy b3Bvc2VkIERldGFpbCBFcnJvcnMNCg0KQWZ0ZXIgcmV2aWV3aW5nIHRoZSBBUEkgYW5kIFNjaGVt YSBkb2NzLCBoZXJlIGlzIGEgZmlyc3QgY3V0IG9mIHRoZSBkZXRhaWxlZCBlcnJvciBjb2Rlcy4N Cg0KDQpGb3IgSFRUUCBTdGF0dXMgNDAwIChCYWQgUmVxdWVzdCkgcmVzcG9uc2VzLCB0aGUgZm9s bG93aW5nIGRldGFpbA0KDQogICBlcnJvciB0eXBlcyBhcmUgZGVmaW5lZDoNCg0KDQoNCistLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KDQp8IHNjaW1UeXBlICAgICB8IERlc2NyaXB0aW9uICAgICAgICAgICAgICAgICAg fCBBcHBsaWNhYmlsaXR5ICAgICAgIHwNCg0KKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCnwgaW52YWxpZEZpbHRl IHwgVGhlIHNwZWNpZmllZCBmaWx0ZXIgc3ludGF4ICB8IEdFVChTZWN0aW9uIDMuMi4yKSwgfA0K DQp8IHIgICAgICAgICAgICB8IHdhcyBpbnZhbGlkIChkb2VzIG5vdCBjb21wbHkgfCBQT1NUIChT ZWFyY2ggLSAgICAgIHwNCg0KfCAgICAgICAgICAgICAgfCB3aXRoIEZpZ3VyZSAxKSBvciB0aGUg ICAgICAgIHwgU2VjdGlvbiAzLjIuMyksICAgICB8DQoNCnwgICAgICAgICAgICAgIHwgc3BlY2lm aWVkIGF0dHJpYnV0ZSBhbmQgICAgICB8IFBBVENIIChQYXRoIEZpbHRlciAgfA0KDQp8ICAgICAg ICAgICAgICB8IGZpbHRlciBjb21wYXJpc29uICAgICAgICAgICAgfCAtIFNlY3Rpb24gMy4zLjIp ICAgIHwNCg0KfCAgICAgICAgICAgICAgfCBjb21iaW5hdGlvbiBpcyBub3QgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICB8DQoNCnwgICAgICAgICAgICAgIHwgc3VwcG9ydGVkLiAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KDQp8IHVuaXF1ZW5lc3MgICB8 IE9uZSBvciBtb3JlIG9mIGF0dHJpYnV0ZSAgICAgfCBQT1NUIChDcmVhdGUgLSAgICAgIHwNCg0K fCAgICAgICAgICAgICAgfCB2YWx1ZXMgaXMgYWxyZWFkeSBpbiB1c2Ugb3IgIHwgU2VjdGlvbiAz LjEpLCBQVVQgICB8DQoNCnwgICAgICAgICAgICAgIHwgaXMgcmVzZXJ2ZWQuICAgICAgICAgICAg ICAgICB8IChTZWN0aW9uIDMuMy4xKSwgICAgfA0KDQp8ICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCBQQVRDSCAoU2VjdGlvbiAgICAgIHwNCg0KfCAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgMy4zLjIpICAgICAgICAgICAg ICB8DQoNCnwgbXV0YWJpbGl0eSAgIHwgVGhlIGF0dGVtcHRlZCBtb2RpZmljYXRpb24gICB8IFBV VCAoU2VjdGlvbiAgICAgICAgfA0KDQp8ICAgICAgICAgICAgICB8IGlzIG5vdCBjb21wYXRpYmxl IHdpdGggdGhlICAgfCAzLjMuMSksIFBBVENIICAgICAgIHwNCg0KfCAgICAgICAgICAgICAgfCB0 YXJnZXQgYXR0cmlidXRlcyBtdXRhYmlsaXR5IHwgKFNlY3Rpb24gMy4zLjIpICAgICB8DQoNCnwg ICAgICAgICAgICAgIHwgb3IgY3VycmVudCBzdGF0ZSAoZS5nLiAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgfA0KDQp8ICAgICAgICAgICAgICB8IG1vZGlmaWNhdGlvbiBvZiBhbiBpbW11dGFi bGUgfCAgICAgICAgICAgICAgICAgICAgIHwNCg0KfCAgICAgICAgICAgICAgfCBhdHRyaWJ1dGUg d2l0aCBhbiBleGlzdGluZyAgIHwgICAgICAgICAgICAgICAgICAgICB8DQoNCnwgICAgICAgICAg ICAgIHwgdmFsdWUpLiAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg fA0KDQp8IGludmFsaWRTeW50YSB8IFRoZSByZXF1ZXN0IGJvZHkgbWVzc2FnZSAgICAgfCBQT1NU IChTZWFyY2ggLSAgICAgIHwNCg0KfCB4ICAgICAgICAgICAgfCBzdHJ1Y3R1cmUgd2FzIGludmFs aWQgb3IgZGlkIHwgU2VjdGlvbiAzLjIuMiwgICAgICB8DQoNCnwgICAgICAgICAgICAgIHwgbm90 IGNvbmZvcm0gdG8gdGhlIHJlcXVlc3QgICB8IENyZWF0ZSAtIFNlY3Rpb24gICAgfA0KDQp8ICAg ICAgICAgICAgICB8IHNjaGVtYS4gICAgICAgICAgICAgICAgICAgICAgfCAzLjEsIEJ1bGsgLSBT ZWN0aW9uIHwNCg0KfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgMy41KSwgUFVUIChTZWN0aW9uICB8DQoNCnwgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8IDMuMy4xKSAgICAgICAgICAgICAgfA0KDQp8IGludmFsaWRQYXRo ICB8IFRoZSBwYXRoIGF0dHJpYnV0ZSB3YXMgICAgICAgfCBQQVRDSCAoU2VjdGlvbiAgICAgIHwN Cg0KfCAgICAgICAgICAgICAgfCBpbnZhbGlkIG9yIG1hbGZvcm1lZCAoc2VlICAgIHwgMy4zLjIp ICAgICAgICAgICAgICB8DQoNCnwgICAgICAgICAgICAgIHwgRmlndXJlIDQpLiAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KDQp8IG5vVGFyZ2V0ICAgICB8IFRoZSBz cGVjaWZpZWQgInBhdGgiIGRpZCBub3QgfCBQQVRDSCAoU2VjdGlvbiAgICAgIHwNCg0KfCAgICAg ICAgICAgICAgfCB5aWVsZCBhbiBhdHRyaWJ1dGUgb3IgICAgICAgIHwgMy4zLjIpICAgICAgICAg ICAgICB8DQoNCnwgICAgICAgICAgICAgIHwgYXR0cmlidXRlIHZhbHVlIHRoYXQgY291bGQgICB8 ICAgICAgICAgICAgICAgICAgICAgfA0KDQp8ICAgICAgICAgICAgICB8IGJlIG9wZXJhdGVkIG9u LiBUaGlzIG9jY3VycyAgfCAgICAgICAgICAgICAgICAgICAgIHwNCg0KfCAgICAgICAgICAgICAg fCB3aGVuIHRoZSBzcGVjaWZpZWQgInBhdGgiICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQoN CnwgICAgICAgICAgICAgIHwgdmFsdWUgY29udGFpbnMgYSBmaWx0ZXIgdGhhdCB8ICAgICAgICAg ICAgICAgICAgICAgfA0KDQp8ICAgICAgICAgICAgICB8IHlpZWxkcyBubyBtYXRjaC4gICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCg0KfCBpbnZhbGlkVmFsdWUgfCBBIHJlcXVp cmVkIHZhbHVlIHdhcyAgICAgICAgIHwgR0VUIChTZWN0aW9uICAgICAgICB8DQoNCnwgICAgICAg ICAgICAgIHwgbWlzc2luZywgb3IgdGhlIHZhbHVlICAgICAgICB8IDMuMi4yKSwgUE9TVCAgICAg ICAgfA0KDQp8ICAgICAgICAgICAgICB8IHNwZWNpZmllZCB3YXMgbm90IGNvbXBhdGlibGUgfCAo Q3JlYXRlIC0gU2VjdGlvbiAgIHwNCg0KfCAgICAgICAgICAgICAgfCB3aXRoIHRoZSBvcGVyYXRp b24gb3IgICAgICAgIHwgMy4xLCBTZWFyY2ggLSAgICAgICB8DQoNCnwgICAgICAgICAgICAgIHwg YXR0cmlidXRlIHR5cGUgKHNlZSBTZWN0aW9uICB8IFNlY3Rpb24gMy4yLjIpLCBQVVQgfA0KDQp8 ICAgICAgICAgICAgICB8IDIuMSBbSS1ELmlldGYtc2NpbS1jb3JlLXNjaGUgfCAoU2VjdGlvbiAz LjMuMSksICAgIHwNCg0KfCAgICAgICAgICAgICAgfCBtYV0pLiAgICAgICAgICAgICAgICAgICAg ICAgIHwgUEFUQ0ggKFNlY3Rpb24gICAgICB8DQoNCnwgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8IDMuMy4yKSAgICAgICAgICAgICAgfA0KDQp8IGludmFsaWRW ZXJzICB8IFRoZSBzcGVjaWZpZWQgQVBJIHZlcnNpb24gaXMgfCBHRVQgKFNlY3Rpb24gICAgICAg IHwNCg0KfCAgICAgICAgICAgICAgfCBub3Qgc3VwcG9ydGVkIChzZWUgU2VjdGlvbiAgIHwgMy4y LjIpLCBQT1NUIChBTEwpLCB8DQoNCnwgICAgICAgICAgICAgIHwgMy4xMSkuICAgICAgICAgICAg ICAgICAgICAgICB8IFBVVCAoU2VjdGlvbiAgICAgICAgfA0KDQp8ICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAzLjMuMSksIFBBVENIICAgICAgIHwNCg0KfCAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgKFNlY3Rpb24gMy4z LjIpLCAgICB8DQoNCnwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8IERFTEVURSAoU2VjdGlvbiAgICAgfA0KDQp8ICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAzLjQpICAgICAgICAgICAgICAgIHwNCg0KKy0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQpJIHBsYW4gdG8gcHV0IHRoZXNlIGludG8gZHJhZnQgMDcgb2YgdGhlIEFQSSBhbmQgd2lsbCBw dWJsaXNoIG92ZXIgdGhlIHdlZWtlbmQuDQoNCkFzIGFsd2F5cywgZmVlZGJhY2sgd2VsY29tZSEN Cg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93 d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tPg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpz Y2ltQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2lt DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2NpbSBt YWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzY2ltIG1haWxpbmcgbGlzdA0Kc2NpbUBpZXRm Lm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2NpbQ0KDQo= --_000_29451b18f13248d1834c27b71b006df5BLUPR03MB309namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHls ZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uY2VybiBpcyB0aGF0 IHRoaXMgY2FuIGNhdXNlIGNvbnRpbnVvdXMgY29kZSBjaGFuZ2VzIGluIGRpZmZlcmVudCBjb2Rl cyBiZWluZyByZWdpc3RlcmVkLCBpZGVhbGx5IHRoZXJlIHdvdWxkIG9ubHkgYmUgYSBjb3VwbGUg YW5kIHRoZXkgd291bGQgYmUgZnJvbSB0aGUNCiBzdGFydCBidXQgdGhpcyBjb3VsZCBncm93IGFu ZCBjYXVzZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyB3aXRoIGZvbGtzIHJlZ2lzdGVyaW5nIGVy cm9yIGNvZGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBNb25kYXksIEp1bmUgMzAsIDIwMTQgMTI6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+IEFu dGhvbnkgTmFkYWxpbjxicj4NCjxiPkNjOjwvYj4gS2VsbHkgR3JpenpsZTsgU2NpbSBXRzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3NjaW1dIFByb3Bvc2VkIERldGFpbCBFcnJvcnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IHNvPzxi cj4NCjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVuIDMwLCAy MDE0LCBhdCAxMjoyNCwgQW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5h ZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklzbuKAmXQgdGhpcyBnb2luZyB0 byBiZSBhIGNvbnRpbnVlZCBwcm9ibGVtcyB3aXRoIElBTkEgdXBkYXRlcyA/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBzY2ltIFs8YSBocmVmPSJtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnIj5t YWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGhp bCBIdW50PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVuZSAzMCwgMjAxNCAxMToxNCBBTTxi cj4NCjxiPlRvOjwvYj4gS2VsbHkgR3JpenpsZTxicj4NCjxiPkNjOjwvYj4gU2NpbSBXRzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3NjaW1dIFByb3Bvc2VkIERldGFpbCBFcnJvcnM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWZ0ZXIgdGhp bmtpbmcgYWJvdXQgdGhpcyBhIGJpdCwgSSB0aGluayBVUklzIGZvciBzY2ltVHlwZSBpcyB0aGUg YmVzdCB3YXkgdG8gZ28uIFdoaWxlIGhhdmluZyBhIFVSSSBtZWFucyBhIG5ldyBJQU5BIHJlZ2lz dHJ5LCBpdCBpcyBwcm9iYWJseSBzaW1wbGVyIHRvIGltcGxlbWVudCBhbmQgYWxsb3dzIGZvciB0 aGUgY2FwYWJpbGl0eSBmb3IgU1BzIHRvIGV4dGVuZCBlcnJvcnMgYXMgS2VsbHkgYW5kIERhdmlk DQogaGF2ZSByZXF1ZXN0ZWQuICZuYnNwO0l0IGlzIGFsc28gaW4gbGluZSB3aXRoOiZuYnNwOzxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5vdHRpbmdoYW0taHR0cC1w cm9ibGVtLTA2Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ub3R0aW5naGFtLWh0 dHAtcHJvYmxlbS0wNjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BcyBtYW55IGFyZSBvZmYtbGluZSBtdWNoIG9mIHRoZSB3ZWVrIGR1ZSB0byBDYW5h ZGlhbiBhbmQgVVMgaG9saWRheXMsIGFuZCB0aGUgd2luZG93IGZvciBzdWJtaXNzaW9ucyBmb3Ig SUVURjkwIGNsb3NlcyBGcmlkYXksIEkgd2lsbCBzdGFydCB3b3JrIGFtZW5kaW5nIHRoZSBBUEkg ZHJhZnQgdG8gaW5jbHVkZSB0aGUgZXJyb3IgY29kZXMgbGlzdGVkIGF0IHRoZSBzdGFydCBvZiB0 aGlzIHRocmVhZCBidXQgd2l0aA0KIFVSSXMgYW5kIHdpbGwgYWRkIHRoZSBJQU5BIHJlZ2lzdHJ5 IGZvciBlcnJvcnMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkBpbmRlcGVuZGVudGlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSI+d3d3LmluZGVwZW5kZW50 aWQuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gSnVuIDMwLCAyMDE0LCBhdCA4OjU2IEFNLCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9 Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RGF2aWQgaGFkIGEgc2ltaWxhciBjb21tZW50LiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGlmIHRoZXJl IHdhcyBhIHNlcGFyYXRlIGF0dHJpYnV0ZTogc3BDb2RlIHRoYXQgYWxsb3dzIHRoZSBzZXJ2aWNl IHByb3ZpZGVyIHRvIGluZGljYXRlIG5vbi1wcm90b2NvbCBlcnJvcnM/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpQaGlsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEp1biAzMCwgMjAxNCwgYXQgNzo0NiwgS2VsbHkgR3Jp enpsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbSI+a2Vs bHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgcmVtZW1iZXIgdGhhdCBvbmUgb2YgdGhlIGluaXRpYWwgZHJpdmVy cyBmb3IgdGhpcyB0aWNrZXQgd2FzIHRoZSBhYmlsaXR5IGZvciBzZXJ2aWNlIHByb3ZpZGVycyB0 byBzZW5kIGJhY2sgZXJyb3IgY29kZXMgdGhhdCBhcmUgc3BlY2lmaWMgdG8gdGhlIHNlcnZpY2Ug cHJvdmlkZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BbiBleGFtcGxlIG9uIGEgdXNlciBjcmVhdGlvbiBtaWdodCBi ZSDigJxlcnJvciAyODczOOKAnSDigKYg4oCcY2xpZW50IGhhcyBleGNlZWRlZCB0aGUgbWF4aW11 bSBudW1iZXIgb2YgdXNlcnMgaW4gdGhlaXIgb3JnYW5pemF0aW9u4oCdLiZuYnNwOyBJZGVhbGx5 IHRoZSBTUCB3b3VsZCBiZSBhYmxlDQogdG8gY29tbXVuaWNhdGUgYmFjayB0aGUgZ2VuZXJhbCBI VFRQIGVycm9yIGNvZGUsIGEgcHJvdmlkZXItc3BlY2lmaWMgZXJyb3IgY29kZSwgYW5kIGEgaHVt YW4gcmVhZGFibGUgZGVzY3JpcHRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoYXQgc2NpbVR5cGUg d291bGQgYWxsb3cgZm9yIHRoaXMgaWYgdGhlIGxpc3Qgd2VyZSBleHRlbnNpYmxlLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+LS1LZWxseTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBoaWwgSHVudCBbPGEgaHJlZj0ibWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tIj5tYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb208L2E+XQ0K PGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgSnVuZSAyOSwgMjAxNCAzOjI3IFBNPGJyPg0KPGI+ VG86PC9iPiBLZWxseSBHcml6emxlPGJyPg0KPGI+Q2M6PC9iPiBTY2ltIFdHPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbc2NpbV0gUHJvcG9zZWQgRGV0YWlsIEVycm9yczwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db3VsZCBiZSBpZiB3ZSB1 c2UgVVJJcyBmb3IgY29kZXMmbmJzcDs8YnI+DQo8YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCk9uIEp1biAyOSwgMjAxNCwgYXQgMTM6MDksIEtlbGx5IEdyaXp6bGUgJmx0 OzxhIGhyZWY9Im1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20iPmtlbGx5LmdyaXp6 bGVAc2FpbHBvaW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSBsaWtlIHRoZXNlLCBQaGlsLiZuYnNwOyBTaG91bGQgdGhpcyBsaXN0 IG9mIGVycm9yIGNvZGVzIGJlIGV4dGVuc2libGU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNjaW0gWzxhIGhyZWY9Im1haWx0bzpzY2lt LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQ8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdW5l IDI3LCAyMDE0IDE6NDcgUE08YnI+DQo8Yj5Ubzo8L2I+IFNjaW0gV0c8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gW3NjaW1dIFByb3Bvc2VkIERldGFpbCBFcnJvcnM8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZnRlciByZXZpZXdpbmcgdGhlIEFQSSBhbmQgU2No ZW1hIGRvY3MsIGhlcmUgaXMgYSBmaXJzdCBjdXQgb2YgdGhlIGRldGFpbGVkIGVycm9yIGNvZGVz LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29yZC13cmFwOiBicmVhay13 b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj5Gb3IgSFRUUCBTdGF0dXMgNDAwIChCYWQgUmVxdWVz dCkgcmVzcG9uc2VzLCB0aGUgZm9sbG93aW5nIGRldGFpbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBlcnJvciB0eXBlcyBhcmUgZGVmaW5lZDo8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mIzQzOy0tLS0tLS0tLS0tLS0tJiM0 MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0t LSYjNDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+fCBzY2ltVHlwZSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8IERlc2NyaXB0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwgQXBwbGljYWJpbGl0eSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+JiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQz OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwgaW52YWxpZEZpbHRlIHwgVGhlIHNwZWNpZmllZCBm aWx0ZXIgc3ludGF4Jm5ic3A7IHwgR0VUKFNlY3Rpb24gMy4yLjIpLCB8PG86cD48L286cD48L3By ZT4NCjxwcmU+fCByJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgd2FzIGludmFsaWQgKGRvZXMgbm90IGNvbXBseSB8IFBP U1QgKFNlYXJjaCAtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgd2l0aCBGaWd1cmUgMSkgb3IgdGhl Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgU2VjdGlvbiAzLjIu MyksJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgc3BlY2lmaWVkIGF0dHJpYnV0ZSBhbmQmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCBQQVRDSCAoUGF0aCBGaWx0ZXImbmJzcDsgfDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7fCBmaWx0ZXIgY29tcGFyaXNvbiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8IC0gU2VjdGlvbiAzLjMuMikmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBjb21iaW5hdGlvbiBpcyBub3Qm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8IHN1cHBvcnRlZC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCB1bmlxdWVuZXNzJm5i c3A7Jm5ic3A7IHwgT25lIG9yIG1vcmUgb2YgYXR0cmlidXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwgUE9TVCAoQ3JlYXRlIC0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCB2YWx1ZXMgaXMgYWxy ZWFkeSBpbiB1c2Ugb3ImbmJzcDsgfCBTZWN0aW9uIDMuMSksIFBVVCZuYnNwOyZuYnNwOyB8PG86 cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IGlzIHJlc2VydmVk LiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IChTZWN0aW9uIDMuMy4x KSwmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8IFBBVENIIChTZWN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7fCAzLjMuMikmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PnwgbXV0YWJpbGl0eSZuYnNwOyZuYnNwOyB8IFRoZSBhdHRlbXB0ZWQgbW9kaWZpY2F0aW9uJm5i c3A7Jm5ic3A7IHwgUFVUIChTZWN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgaXMgbm90IGNvbXBhdGlibGUgd2l0aCB0aGUmbmJzcDsmbmJzcDsgfCAzLjMuMSksIFBBVENI Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgdGFyZ2V0IGF0dHJpYnV0ZXMgbXV0YWJpbGl0 eSB8IChTZWN0aW9uIDMuMy4yKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48 L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDt8IG9yIGN1cnJlbnQgc3RhdGUgKGUu Zy4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286 cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IG1vZGlmaWNhdGlvbiBvZiBh biBpbW11dGFibGUgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8IGF0dHJpYnV0ZSB3aXRoIGFuIGV4aXN0aW5nJm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCB2YWx1 ZSkuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwgaW52YWxp ZFN5bnRhIHwgVGhlIHJlcXVlc3QgYm9keSBtZXNzYWdlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgUE9TVCAoU2VhcmNoIC0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPnwgeCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHN0cnVjdHVyZSB3YXMgaW52YWxpZCBvciBk aWQgfCBTZWN0aW9uIDMuMi4yLCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48 L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IG5vdCBjb25mb3JtIHRv IHRoZSByZXF1ZXN0Jm5ic3A7Jm5ic3A7IHwgQ3JlYXRlIC0gU2VjdGlvbiZuYnNwOyZuYnNwOyZu YnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHNj aGVtYS4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7fCAzLjEsIEJ1bGsgLSBTZWN0aW9uIHw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAzLjUpLCBQVVQgKFNlY3Rpb24m bmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8IDMuMy4xKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+ fCBpbnZhbGlkUGF0aCZuYnNwOyB8IFRoZSBwYXRoIGF0dHJpYnV0ZSB3YXMmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBQQVRDSCAoU2VjdGlvbiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDt8IGludmFsaWQgb3IgbWFsZm9ybWVkIChzZWUmbmJzcDsmbmJzcDsmbmJzcDsgfCAzLjMu MikmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCBGaWd1cmUgNCkuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwg bm9UYXJnZXQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBUaGUgc3BlY2lmaWVkICZxdW90O3Bh dGgmcXVvdDsgZGlkIG5vdCB8IFBBVENIIChTZWN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwg eWllbGQgYW4gYXR0cmlidXRlIG9yJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwgMy4zLjIpJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgYXR0cmlidXRlIHZhbHVlIHRoYXQgY291bGQm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8IGJlIG9wZXJhdGVkIG9uLiBUaGlzIG9jY3VycyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgd2hlbiB0aGUg c3BlY2lmaWVkICZxdW90O3BhdGgmcXVvdDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86 cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHZhbHVlIGNvbnRh aW5zIGEgZmlsdGVyIHRoYXQgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8IHlpZWxkcyBubyBtYXRjaC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+fCBpbnZhbGlkVmFsdWUgfCBBIHJlcXVpcmVkIHZh bHVlIHdhcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 IEdFVCAoU2VjdGlvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IG1pc3Npbmcs IG9yIHRoZSB2YWx1ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 IDMuMi4yKSwgUE9TVCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8 PG86cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHNwZWNpZmll ZCB3YXMgbm90IGNvbXBhdGlibGUgfCAoQ3JlYXRlIC0gU2VjdGlvbiZuYnNwOyZuYnNwOyB8PG86 cD48L286cD48L3ByZT4NCjxwcmU+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHdpdGggdGhlIG9w ZXJhdGlvbiBvciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IDMu MSwgU2VhcmNoIC0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBhdHRyaWJ1dGUgdHlwZSAo c2VlIFNlY3Rpb24mbmJzcDsgfCBTZWN0aW9uIDMuMi4yKSwgUFVUIHw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgMi4xIFtJLUQuaWV0Zi1zY2ltLWNvcmUt c2NoZSB8IChTZWN0aW9uIDMuMy4xKSwmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBtYV0pLiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8IFBBVENIIChTZWN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAzLjMu MikmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwgaW52YWxp ZFZlcnMmbmJzcDsgfCBUaGUgc3BlY2lmaWVkIEFQSSB2ZXJzaW9uIGlzIHwgR0VUIChTZWN0aW9u Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwO3wgbm90IHN1cHBvcnRlZCAoc2VlIFNl Y3Rpb24mbmJzcDsmbmJzcDsgfCAzLjIuMiksIFBPU1QgKEFMTCksIHw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgMy4xMSkuJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgUFVUIChTZWN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAz LjMuMSksIFBBVENIJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAoU2VjdGlvbiAz LjMuMiksJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT58Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBERUxFVEUgKFNlY3Rpb24mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8IDMuNCkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcGxhbiB0byBwdXQgdGhlc2UgaW50byBkcmFm dCAwNyBvZiB0aGUgQVBJIGFuZCB3aWxsIHB1Ymxpc2ggb3ZlciB0aGUgd2Vla2VuZC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgYWx3YXlz LCBmZWVkYmFjayB3ZWxjb21lITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QaGls PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyI+d3d3LmluZGVwZW5k ZW50aWQuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnNjaW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5v cmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zY2ltIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NjaW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzY2ltIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNjaW0gbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_29451b18f13248d1834c27b71b006df5BLUPR03MB309namprd03pro_-- From nobody Mon Jun 30 15:40:18 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728321A0B13 for ; Mon, 30 Jun 2014 15:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.477 X-Spam-Level: X-Spam-Status: No, score=0.477 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X9502ouGUhh for ; Mon, 30 Jun 2014 15:40:15 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3732C1A0B10 for ; Mon, 30 Jun 2014 15:40:15 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s5UMeCNi010705 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Jul 2014 00:40:12 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s5UMe955003685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Jul 2014 00:40:12 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.115] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128 bits)) for scim@ietf.org; Tue, 1 Jul 2014 00:40:09 +0200 Message-ID: <53B1E749.7070905@sunet.se> Date: Tue, 01 Jul 2014 00:40:09 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "scim@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, 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: 09MkKEchB - b67900496693 - 20140701 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/scim/PmaZme0EbWBm3bcQyUVr50I0MBA Subject: [scim] closing ticket 47 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 22:40:17 -0000 I'm calling ticket 47 in favour of closing with wontfix - there has been no oposition whatsoever to Phils proposal to do so. From nobody Mon Jun 30 15:54:29 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD891A0BE8 for ; Mon, 30 Jun 2014 15:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foK2R3HOts_I for ; Mon, 30 Jun 2014 15:54:25 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5541A0B11 for ; Mon, 30 Jun 2014 15:54:24 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id ty20so5326575lab.17 for ; Mon, 30 Jun 2014 15:54:23 -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=sFoXWoW5fYFbMxQ1LSbLR6jBgOcz2y0DKe4t199pXDo=; b=hLs5lwrRD3YexS3wNOZ1+d5HyrNVgFa4/qM5p4z7p4ChZd6oZ2+7XCKeDQkEThbw0Y 1lyRX1dwrBjcXaQNlgzuEcfw27l0re3x8lg6VkN25JpBz9bEOQxXRilKWkg6vn/xiod6 WUF2HA/876MlsbnMfsSvPW9S/91do25guJYjOGztol/HJbmLaCdyVJumrtnw85E/4/O/ fWcuOX9/i1c6bN3E22CKnIGcbtCOe8wJPRFvSGJELQDhAZyPvoiay2GdjA3FtcfKIaJq /p18pIX7m/0vjCTPd9nWNYWRA3bBUiOl1egt0mAA2YPiuQWghRIvTSMssgPFajjPgsGk Em3Q== X-Gm-Message-State: ALoCoQly7QgYJ6MrYC4Rl91soOMaIu+Rc5jxISPy5sq2gSNO2+UF2vJyTWxlMu65CV35JsSYU1en X-Received: by 10.152.6.131 with SMTP id b3mr33056345laa.9.1404168863236; Mon, 30 Jun 2014 15:54:23 -0700 (PDT) Received: from [10.0.0.115] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id z7sm9359386laa.28.2014.06.30.15.54.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 15:54:22 -0700 (PDT) Message-ID: <53B1EA9E.4070101@mnt.se> Date: Tue, 01 Jul 2014 00:54:22 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: scim@ietf.org References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> <3B339C76-F410-41EF-A574-EA3FA85D8590@oracle.com> <29451b18f13248d1834c27b71b006df5@BLUPR03MB309.namprd03.prod.outlook.com> In-Reply-To: <29451b18f13248d1834c27b71b006df5@BLUPR03MB309.namprd03.prod.outlook.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/DWyfSeRon5-6ezIdXOYxDEnvHVs Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 22:54:27 -0000 On 2014-06-30 23:43, Anthony Nadalin wrote: > Concern is that this can cause continuous code changes in different > codes being registered, ideally there would only be a couple and they > would be from the start but this could grow and cause interoperability > issues with folks registering error codes Thats going to be true for any extension though, right? Errors are no worse in this respect. From nobody Mon Jun 30 16:14:00 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19EC1A8BB6 for ; Mon, 30 Jun 2014 16:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0A_gL40uQbY for ; Mon, 30 Jun 2014 16:13:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1C01A0B11 for ; Mon, 30 Jun 2014 16:13:55 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB390.namprd04.prod.outlook.com (10.141.60.147) with Microsoft SMTP Server (TLS) id 15.0.969.15; Mon, 30 Jun 2014 23:13:53 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0974.002; Mon, 30 Jun 2014 23:13:53 +0000 From: Kelly Grizzle To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] Proposed Detail Errors Thread-Index: AQHPkjhB1v2CfJQHskiODjem+S8OQ5uIh3KAgAAFIoCAATHUYIAAFNqAgAAmcoCAABOcAIAAAwOAgAAkAACAABOzAIAAAusg Date: Mon, 30 Jun 2014 23:13:52 +0000 Message-ID: References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> <3B339C76-F410-41EF-A574-EA3FA85D8590@oracle.com> <29451b18f13248d1834c27b71b006df5@BLUPR03MB309.namprd03.prod.outlook.com> <53B1EA9E.4070101@mnt.se> In-Reply-To: <53B1EA9E.4070101@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: E9FA874600786AE9FA8893 x-originating-ip: [97.79.140.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(24454002)(13464003)(377424004)(189002)(199002)(46102001)(74316001)(83072002)(107886001)(83322001)(107046002)(19580405001)(19580395003)(101416001)(95666004)(2656002)(105586002)(106356001)(99286002)(106116001)(15975445006)(87936001)(77982001)(21056001)(33646001)(76482001)(85852003)(76576001)(76176999)(54356999)(92566001)(99396002)(86362001)(50986999)(64706001)(20776003)(74502001)(31966008)(74662001)(77096002)(81342001)(66066001)(85306003)(81542001)(79102001)(4396001)(80022001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB390; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/D6yd3M2yspsGb5rHPwCTE0wBgEc Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 23:13:58 -0000 I don't know that service providers should have to register codes that are = specific to their implementation ... that kind of seems like overkill to me= . What benefit does that provide other than possibly preventing collisions= ? As long as the SP can provide information to the client about what error oc= curred, it feels like that is enough. The error code sent in the response = could either be one of the SCIM-defined errors (mutability, etc...) or a pr= ovider-defined error (eg - an error code number, etc...). -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson Sent: Monday, June 30, 2014 5:54 PM To: scim@ietf.org Subject: Re: [scim] Proposed Detail Errors On 2014-06-30 23:43, Anthony Nadalin wrote: > Concern is that this can cause continuous code changes in different=20 > codes being registered, ideally there would only be a couple and they=20 > would be from the start but this could grow and cause interoperability=20 > issues with folks registering error codes Thats going to be true for any extension though, right? Errors are no worse= in this respect. _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From nobody Mon Jun 30 20:50:42 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB471A00E6 for ; Mon, 30 Jun 2014 20:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwAl-f-ULwmT for ; Mon, 30 Jun 2014 20:50:38 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830F51A00DF for ; Mon, 30 Jun 2014 20:50:38 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s613oZj4017808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Jul 2014 03:50:36 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s613oXse004687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2014 03:50:34 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s613oWjC016630; Tue, 1 Jul 2014 03:50:33 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Jun 2014 20:50:32 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Phil Hunt In-Reply-To: Date: Mon, 30 Jun 2014 20:50:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <348F75D5-7C0F-4B93-A7B7-88E0B2FFD4ED@oracle.com> <232fc398cb76462088c589f6244f3bf9@BN1PR04MB392.namprd04.prod.outlook.com> <42A78180-7AA1-40FD-B257-DD6ECF06784E@oracle.com> <9075316269e949418386ee90ebedee42@BN1PR04MB392.namprd04.prod.outlook.com> <3B339C76-F410-41EF-A574-EA3FA85D8590@oracle.com> <29451b18f13248d1834c27b71b006df5@BLUPR03MB309.namprd03.prod.outlook.com> <53B1EA9E.4070101@mnt.se> To: Kelly Grizzle X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/jgbRcN34IzgNKiGsbhlUHiqiN5U Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Proposed Detail Errors X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 03:50:40 -0000 My worry is that if service providers implement non-standard codes and = than do not register them, then they can expect that clients shall = ignore their proprietary custom codes. Still, service providers should also expect that not every client will = implement registered codes either. Clients will need to keep in mind that many service providers will = likely only return a general 400 bad request for *any* error as they may = be cautious about proving attacks. I recommend we limit error codes to protocol and schema issues only in = order to get to a final draft in Toronto. I understand the value of detailed error codes to coding smart UIs. But = I would prefer to deal with these fine-grained errors in a future = charter. Phil @independentid www.independentid.com phil.hunt@oracle.com On Jun 30, 2014, at 4:13 PM, Kelly Grizzle = wrote: > I don't know that service providers should have to register codes that = are specific to their implementation ... that kind of seems like = overkill to me. What benefit does that provide other than possibly = preventing collisions? >=20 > As long as the SP can provide information to the client about what = error occurred, it feels like that is enough. The error code sent in = the response could either be one of the SCIM-defined errors (mutability, = etc...) or a provider-defined error (eg - an error code number, etc...). >=20 >=20 > -----Original Message----- > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson > Sent: Monday, June 30, 2014 5:54 PM > To: scim@ietf.org > Subject: Re: [scim] Proposed Detail Errors >=20 > On 2014-06-30 23:43, Anthony Nadalin wrote: >> Concern is that this can cause continuous code changes in different=20= >> codes being registered, ideally there would only be a couple and they=20= >> would be from the start but this could grow and cause = interoperability=20 >> issues with folks registering error codes >=20 > Thats going to be true for any extension though, right? Errors are no = worse in this respect. >=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