From phil.hunt@oracle.com Thu Nov 1 14:25:04 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B4621F92DF for ; Thu, 1 Nov 2012 14:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22dhLd9eceuR for ; Thu, 1 Nov 2012 14:25:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8BE21F9149 for ; Thu, 1 Nov 2012 14:25:03 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA1LP2d1006962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Nov 2012 21:25:03 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA1LP1pP003439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Nov 2012 21:25:02 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qA1LP1gQ004446 for ; Thu, 1 Nov 2012 16:25:01 -0500 Received: from [192.168.1.131] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Nov 2012 14:25:01 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Nov 2012 14:25:01 -0700 Message-Id: <00CE51F8-F54E-4D97-A7D4-DFC3065827E9@oracle.com> To: "scim@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [scim] Non URL based Search X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 21:25:05 -0000 In case its already there, do we have a tracker issue for an alternative = form of search so that filter parameters are not included in the URL?=20 Specifically I'm worried about confidentiality (in access logs) and = injection attacks. Phil @independentid www.independentid.com phil.hunt@oracle.com From melinda.shore@gmail.com Thu Nov 1 14:38:40 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC84721F89A0 for ; Thu, 1 Nov 2012 14:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4LcP3TJKKkV for ; Thu, 1 Nov 2012 14:38:40 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB9C821F89EF for ; Thu, 1 Nov 2012 14:38:11 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so2009404pad.31 for ; Thu, 01 Nov 2012 14:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=dJIPX2N50mtIs68ZZFxdrBOzBmrr/zU5K2AbfMC6Ol0=; b=YRMVwT+pcfIvPanEDsZEhs2uKC7tom2cNhhIK0rMCtMJZILHnVcqGYAQ5fVl7FfFSt 6WLCl8DtTcr5aDJ1IXmj9yi1jPnupM2iziGs/R1/4RcK/QYkn2yxX1v5mF899HmSpKvr ER1Um4RfxJkQLioHpakzr8gihBcwFf3L0oCuAY5PULzld4r+6/zwhfosRNbvo/HhND0n ohV5Es1mh1kbdR3Rm3YHhkZH65Al1hlrKGmNnT/+7PdY5VdFM5uOIAXSlmV8NjYqABsn cy5T7KUHMmw1uo0M3UYXKgUTfZOfNCbfH0BWJ07QiKB1BQPb75BqggKqojAVSQZSYG/a v2tg== Received: by 10.68.192.97 with SMTP id hf1mr125575693pbc.106.1351805891577; Thu, 01 Nov 2012 14:38:11 -0700 (PDT) Received: from spandex.local (209-193-56-73-rb1.fai.dsl.dynamic.acsalaska.net. [209.193.56.73]) by mx.google.com with ESMTPS id j9sm4533147pav.15.2012.11.01.14.38.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 14:38:11 -0700 (PDT) Message-ID: <5092EBC0.4010002@gmail.com> Date: Thu, 01 Nov 2012 13:38:08 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <00CE51F8-F54E-4D97-A7D4-DFC3065827E9@oracle.com> In-Reply-To: <00CE51F8-F54E-4D97-A7D4-DFC3065827E9@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] Non URL based Search X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 21:38:41 -0000 On 11/1/12 1:25 PM, Phil Hunt wrote: > In case its already there, do we have a tracker issue for an > alternative form of search so that filter parameters are not included > in the URL? Yes, that's #25, which says "Add ability to retrieve a resource without including the type in the URL". At the same time, we've got #17, which reads "Add the ability to put resource types in URL paths". The latter was moved over from the Google issue tracker. Might be good to work up some text describing what you need from URL semantics, including privacy and/or security requirements. Melinda From phil.hunt@oracle.com Thu Nov 1 14:44:58 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1C821F9269 for ; Thu, 1 Nov 2012 14:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hoy1sJy63J35 for ; Thu, 1 Nov 2012 14:44:57 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9039121F91D5 for ; Thu, 1 Nov 2012 14:44:57 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA1LitN6018803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Nov 2012 21:44:56 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA1LitRf022943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Nov 2012 21:44:55 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qA1Lis4q014039; Thu, 1 Nov 2012 16:44:54 -0500 Received: from [192.168.1.131] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Nov 2012 14:44:54 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <5092EBC0.4010002@gmail.com> Date: Thu, 1 Nov 2012 14:44:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <909793F9-216E-4419-9178-302C779BCFF2@oracle.com> References: <00CE51F8-F54E-4D97-A7D4-DFC3065827E9@oracle.com> <5092EBC0.4010002@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: scim@ietf.org Subject: Re: [scim] Non URL based Search X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 21:44:58 -0000 I think the issue in 25 was to eliminate the resource endpoint from the = operation so multiple resource types could be matched against a filter. This requirement is to eliminate the filter entirely from the URL in the = GET operation. E.g. by creating a /search endpoint that can be accessed = using GET or POST (aka X-Search). I'll add a separate item. The two may turn out to impact the same parts = of the spec. But I think it is a separate issue. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-11-01, at 2:38 PM, Melinda Shore wrote: > On 11/1/12 1:25 PM, Phil Hunt wrote: >> In case its already there, do we have a tracker issue for an >> alternative form of search so that filter parameters are not included >> in the URL? >=20 > Yes, that's #25, which says "Add ability to retrieve a resource = without > including the type in the URL". At the same time, we've got #17, = which > reads "Add the ability to put resource types in URL paths". The = latter > was moved over from the Google issue tracker. Might be good to work = up > some text describing what you need from URL semantics, including > privacy and/or security requirements. >=20 > Melinda > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From bjorn.aannestad@unboundid.com Thu Nov 1 15:32:49 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4884021F9714 for ; Thu, 1 Nov 2012 15:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhDE6Ss+SUHf for ; Thu, 1 Nov 2012 15:32:48 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA42621F96EA for ; Thu, 1 Nov 2012 15:32:48 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so3297139obq.31 for ; Thu, 01 Nov 2012 15:32:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=nwlUfu3d/+361wfYnug0g001z/EIooiodghFwg/BCac=; b=FgJANG6T/zL71WGGSmKNUrjwgp28IvWhupmphSm2//ANefuyutr/qI9p5apvY/8U9e c/61dtsDk8OFCl4IuQ+3TlZ21LSJV85YhgGvskXhedIwvzmu61JkhyZvuawzje5Ylo5q PWAmFmC8szWwgcsP3SSVnrgckJMkn7NaaUw3gjzPQKs48pW1kbyJN0WDKLVNwJr1ATax uERpNavQlLdR9KsxAML6Vl27ja6GNwAh0Z6dcq9lQd3AkPMxIlxe01v32oszZU+C+9tw Oi6byQlTtm3foH0XG7PrJ9lEX6rBwAJvd5jlpvHyXZTwoI4WRaf1J6F8QKv7SsXlTCIx U2+A== Received: by 10.182.150.105 with SMTP id uh9mr33917736obb.85.1351809168271; Thu, 01 Nov 2012 15:32:48 -0700 (PDT) Received: from [10.8.1.249] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id b20sm7477995obu.4.2012.11.01.15.32.46 (version=SSLv3 cipher=OTHER); Thu, 01 Nov 2012 15:32:47 -0700 (PDT) Message-ID: <5092F887.7020903@unboundid.com> Date: Thu, 01 Nov 2012 17:32:39 -0500 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: scim WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040303070600050903090104" X-Gm-Message-State: ALoCoQlkDVFzh5A8yc/m0tzZv7BpDYbXNtp+QRettfnsk1hgvdKY+IxrS4Lm/WGcpczBb4BmqTnH Subject: [scim] Considerations for evaluating the suitability of vCard? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 22:32:49 -0000 This is a cryptographically signed message in MIME format. --------------ms040303070600050903090104 Content-Type: multipart/mixed; boundary="------------020303020509080600000500" This is a multi-part message in MIME format. --------------020303020509080600000500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Based on a suggestion from Morteza, Kelly Grizzle and I volunteered to=20 assemble some "findings" about vCard for presentation to the group at=20 IETF next week. The same information will be sent to the list for=20 everyone to review. Our goal is to provide some of the information needed for the group to=20 make an eventual decision on #19 - "Incorporate vCard as the SCIM schema.= " To do that, we're considering the following: * Extensibility for additional attributes * Extensibility for additional resource types * Support for meta-data on attributes and on values * Alignment with SCIM's charter goals ("simplicity", etc) * Gap analysis between what SCIM now supports and vCard, leading to a=20 sense of how much work there is to bring it in. * Existence and suitability of a JSON representation * Degree of adoption, and by whom. Existence of client libraries. * Support for complex objects * Support for relationships between objects * Ability to work together with the vCard group for advice and=20 (potentially) changes to vCard itself * Any "baggage" that vCard may bring with it Some of these are objective and easy to answer, others are subjective. What other aspects should we consider? Is an important consideration=20 missing from the above? Thanks! -Bjorn Aannestad --=20 __________________________________________________________ Bjorn Aannestad | Dir, Product Management | UnboundID Corp mailto:bjorn@unboundid.com | 512-769-6461 --------------020303020509080600000500 Content-Type: text/x-vcard; charset=utf-8; name="bjorn_aannestad.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="bjorn_aannestad.vcf" begin:vcard fn:Bjorn Aannestad n:Aannestad;Bjorn org:UnboundID email;internet:bjorn@unboundid.com title:Director, Product Management tel;work:512 600 7753 tel;cell:512 769 6461 note:skype: bjorn_aannestad version:2.1 end:vcard --------------020303020509080600000500-- --------------ms040303070600050903090104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMUjCC BVwwggREoAMCAQICECStp7X80wzNJ6GfICadV/cwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjAyMjMwMDAwMDBaFw0xMzAyMjIyMzU5NTlaMIIBHzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRgwFgYDVQQDFA9Cam9ybiBBYW5u ZXN0YWQxLDAqBgkqhkiG9w0BCQEWHWJqb3JuLmFhbm5lc3RhZEB1bmJvdW5kaWQuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw+4r+Le4uODrErBgJsA7UoexcjH/r2Ds 62wKyDCY5CQfOFMROnynV9GWWXp8zmCj7/N9I2hOU7poaqR4kkJjoiKiNHQdVfyM1yFZTurW AV5PCT5NouiqlruJDM6s2HV3B7mSRhtHFOSfhiDP+/kHf/JEdFJ7zEPaP0Kuy8XKpPR5nVCz k4zFKPBc4T9+HAlXeGY1PnwOsxPEevZlHOTThF9RunZu5Z/uaObR2JplM6KxXDfXNRjSkmK7 6kW8wFC1C0GleHKfM85nQTvVicuSK4GbbvhMjqovMtUIR1SNG8vsmTvU4PY9G/WkDM4Ge/97 phIcQIm9W/DXjC78wBfa/QIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5Bgtg hkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh MAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkw RzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5k QzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQC345zS3026vrJVysBCE3TN BhQ4VlqRtwj5AcAXhhF2c3krlbgJRLV6STYky+/i7YRdezIZYgY2eo693dlIQUnkZMb6D2PL dRs1Lgw4NJKB+WGLGkmyV8YqqKrTm/ZbPdl/+Y4Pc88DLcYEmr0OsEDel8LqLPpongUDnGU5 2wxAvaHn9sZ4nyDa3bAy9RyqrAdWhsfRttlgAbvMeHSXhvDa63AbdGdZbzBfqGpBTYZJqrA/ fzcbVZQIw7ULW0YRpUNx8bmmgxFd5ovdDVZnfiKNd7QHy+BcTQgfxLYsBYZhICz1ud1QKn88 pW944VjwHTzxyErX43AGoPYoZKA8b3XXMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT 3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5 OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6 ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f 0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Iba k2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+ wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBn MGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNV HR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNV HQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAH BgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24u Y29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0 LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHm oYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSo WufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6 jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvi d+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5l UkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaM xmgD5yKocwuxvKDaUljdCg5/wYIxggT5MIIE9QIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhAkrae1/NMMzSeh nyAmnVf3MAkGBSsOAwIaBQCgggLbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMTEwMTIyMzIzOVowIwYJKoZIhvcNAQkEMRYEFCtsASEdgHXUmrLcP3Ss Tr8nRx12MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQJK2ntfzTDM0noZ8gJp1X 9zCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCECStp7X80wzNJ6GfICadV/cwDQYJ KoZIhvcNAQEBBQAEggEAHB+9m5q8xXIXgMCxrmlX8aQOkUMa+2slHVljyJVyywF4SGBa4K++ aGpEkYm4Yb/33Jb8GcVId+9pGZCecW/coJ97+cBJuOcdLXH1CQriPiWPxkw3+bXBGmKjjQwZ 7FpydjzdUadrb7TEosp7QV9TTOuiDjKlOYEqiDvzhWxCIMKyggEL1e5WkQUAt7VDRP5IxlTk +naybNH1FhI3VPPjJ8IWA+SXGLluZgQpzJXOW4v0MPlSv8vkF0HyuPtZSS8LKvDGaBQtPEND P1zGS0lUFjC3/B4HUAvtOb3ZPI9zIbir+1xFAJ1Pz/Jnm34uvvbRy9En5WWMvSZ6jFmrXMSM SAAAAAAAAA== --------------ms040303070600050903090104-- From likepeng@huawei.com Thu Nov 1 18:19:02 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B19321F94E6 for ; Thu, 1 Nov 2012 18:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8HSZSalE5aI for ; Thu, 1 Nov 2012 18:19:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5751B21F94ED for ; Thu, 1 Nov 2012 18:19:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALD41871; Fri, 02 Nov 2012 01:18:53 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 2 Nov 2012 01:18:06 +0000 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 2 Nov 2012 01:18:37 +0000 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.161]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Fri, 2 Nov 2012 09:18:32 +0800 From: Likepeng To: Bjorn Aannestad , scim WG Thread-Topic: [scim] Considerations for evaluating the suitability of vCard? Thread-Index: AQHNuIDXDLOMaXOaKk2S9bwavnc8lZfVvf+A Date: Fri, 2 Nov 2012 01:18:32 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F21ED6B19C@szxeml525-mbx.china.huawei.com> References: <5092F887.7020903@unboundid.com> In-Reply-To: <5092F887.7020903@unboundid.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.63] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [scim] Considerations for evaluating the suitability of vCard? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 01:19:02 -0000 VGhlcmUgaXMgYW4gYXZhaWxhYmxlIGRyYWZ0IHJlbGF0ZWQgdG8gdGhpcyB0b3BpYzoNCmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ3JlZXZlbmJvc2NoLXNjaW0tdmNhcmQt bWFwcGluZy8NCg0KV2UgY2FuIHVzZSB0aGF0IGFzIGEgYmFzZWxpbmUgZm9yIGRpc2N1c3Npb24s IG9yIHlvdSBndXlzIGNhbiB3b3JrIHRvZ2V0aGVyIGZvciB0aGlzIHRvcGljLg0KDQpLaW5kIFJl Z2FyZHMNCktlcGVuZw0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzogc2NpbS1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEJqb3JuIEFhbm5l c3RhZA0Kt6LLzcqxvOQ6IDIwMTLE6jEx1MIyyNUgNjozMw0KytW8/sjLOiBzY2ltIFdHDQrW98zi OiBbc2NpbV0gQ29uc2lkZXJhdGlvbnMgZm9yIGV2YWx1YXRpbmcgdGhlIHN1aXRhYmlsaXR5IG9m IHZDYXJkPw0KDQpCYXNlZCBvbiBhIHN1Z2dlc3Rpb24gZnJvbSBNb3J0ZXphLCBLZWxseSBHcml6 emxlIGFuZCBJIHZvbHVudGVlcmVkIHRvIGFzc2VtYmxlIHNvbWUgImZpbmRpbmdzIiBhYm91dCB2 Q2FyZCBmb3IgcHJlc2VudGF0aW9uIHRvIHRoZSBncm91cCBhdCBJRVRGIG5leHQgd2Vlay4gIFRo ZSBzYW1lIGluZm9ybWF0aW9uIHdpbGwgYmUgc2VudCB0byB0aGUgbGlzdCBmb3IgZXZlcnlvbmUg dG8gcmV2aWV3Lg0KDQpPdXIgZ29hbCBpcyB0byBwcm92aWRlIHNvbWUgb2YgdGhlIGluZm9ybWF0 aW9uIG5lZWRlZCBmb3IgdGhlIGdyb3VwIHRvIG1ha2UgYW4gZXZlbnR1YWwgZGVjaXNpb24gb24g IzE5IC0gIkluY29ycG9yYXRlIHZDYXJkIGFzIHRoZSBTQ0lNIHNjaGVtYS4iDQoNClRvIGRvIHRo YXQsIHdlJ3JlIGNvbnNpZGVyaW5nIHRoZSBmb2xsb3dpbmc6DQoqIEV4dGVuc2liaWxpdHkgZm9y IGFkZGl0aW9uYWwgYXR0cmlidXRlcw0KKiBFeHRlbnNpYmlsaXR5IGZvciBhZGRpdGlvbmFsIHJl c291cmNlIHR5cGVzDQoqIFN1cHBvcnQgZm9yIG1ldGEtZGF0YSBvbiBhdHRyaWJ1dGVzIGFuZCBv biB2YWx1ZXMNCg0KKiBBbGlnbm1lbnQgd2l0aCBTQ0lNJ3MgY2hhcnRlciBnb2FscyAoInNpbXBs aWNpdHkiLCBldGMpDQoqIEdhcCBhbmFseXNpcyBiZXR3ZWVuIHdoYXQgU0NJTSBub3cgc3VwcG9y dHMgYW5kIHZDYXJkLCBsZWFkaW5nIHRvIGEgc2Vuc2Ugb2YgaG93IG11Y2ggd29yayB0aGVyZSBp cyB0byBicmluZyBpdCBpbi4NCg0KKiBFeGlzdGVuY2UgYW5kIHN1aXRhYmlsaXR5IG9mIGEgSlNP TiByZXByZXNlbnRhdGlvbg0KKiBEZWdyZWUgb2YgYWRvcHRpb24sIGFuZCBieSB3aG9tLiAgRXhp c3RlbmNlIG9mIGNsaWVudCBsaWJyYXJpZXMuDQoNCiogU3VwcG9ydCBmb3IgY29tcGxleCBvYmpl Y3RzDQoqIFN1cHBvcnQgZm9yIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBvYmplY3RzDQoNCiogQWJp bGl0eSB0byB3b3JrIHRvZ2V0aGVyIHdpdGggdGhlIHZDYXJkIGdyb3VwIGZvciBhZHZpY2UgYW5k DQoocG90ZW50aWFsbHkpIGNoYW5nZXMgdG8gdkNhcmQgaXRzZWxmDQoNCiogQW55ICJiYWdnYWdl IiB0aGF0IHZDYXJkIG1heSBicmluZyB3aXRoIGl0DQoNClNvbWUgb2YgdGhlc2UgYXJlIG9iamVj dGl2ZSBhbmQgZWFzeSB0byBhbnN3ZXIsIG90aGVycyBhcmUgc3ViamVjdGl2ZS4NCg0KV2hhdCBv dGhlciBhc3BlY3RzIHNob3VsZCB3ZSBjb25zaWRlcj8gICBJcyBhbiBpbXBvcnRhbnQgY29uc2lk ZXJhdGlvbiANCm1pc3NpbmcgZnJvbSB0aGUgYWJvdmU/DQoNClRoYW5rcyENCi1Cam9ybiBBYW5u ZXN0YWQNCg0KDQoNCi0tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpCam9ybiBBYW5uZXN0YWQgfCBEaXIsIFByb2R1Y3QgTWFuYWdl bWVudCB8IFVuYm91bmRJRCBDb3JwIG1haWx0bzpiam9ybkB1bmJvdW5kaWQuY29tIHwgNTEyLTc2 OS02NDYxDQoNCg== From leifj@mnt.se Fri Nov 2 01:53:08 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3897221F89B3 for ; Fri, 2 Nov 2012 01:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WEQ0Ht68waY for ; Fri, 2 Nov 2012 01:53:07 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 339F321F89F4 for ; Fri, 2 Nov 2012 01:53:06 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2654034lam.31 for ; Fri, 02 Nov 2012 01:53:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=A5tzaUH2wz5/0ms8YXDwhgOfV1I6Jc377QTp9YEJmbg=; b=pHe9L48CudeGNH30VPwsDVM717Wcbso+/2X6SbUG/SOTI5nz7XvysNl86OGPgy9LBA ajhRPsF7SgJw4i9XdvT9HsMdVws+V0RAb8WZion8Hwt0Z63bG6WoTatWryu7JyRDODLm 6548GPCR9sPeJzHwuwQ2LcvYdoqAfdBaqLBNWxuA+v2TpR3QT0lhozCa5DN0MexO5nSJ Jf6fIo0KJ85gqC6afa1webzOgiXQ9XJWfZiNXWtemIiaxhT1wC+sToJqOw/wCzY8mDyb izGrzfhMvOAkPvPacXb8kNVJvqBMDgVfMz3zSS97qXrx0HRSXX+xpYpXppCbgqhRkBIc hlWw== Received: by 10.152.104.148 with SMTP id ge20mr914512lab.51.1351846385987; Fri, 02 Nov 2012 01:53:05 -0700 (PDT) Received: from [192.168.177.35] ([193.214.121.242]) by mx.google.com with ESMTPS id sx3sm2904798lab.9.2012.11.02.01.53.02 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 01:53:04 -0700 (PDT) Message-ID: <509389EB.8060509@mnt.se> Date: Fri, 02 Nov 2012 09:52:59 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: scim WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmKBTapoTKufpyt4AxvASjpadDgmkY9kH9WDaAZ3Bo0+xhInmQNxwchyFFvmJL5ziHqCu7Z Subject: [scim] Agenda for ATL X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 08:53:08 -0000 Here is the agenda for Atlanta. The current version of the agenda has us meeting 13:00-15:00 on Thursday. 1. Note Well and Agenda Bashing (5min) 2. Goals for the DT (Chairs, 10min) 3. A word from the tracker general (Shore,15min) 4. Use-case document [1] (Zeltzan,20min) 5. vCard mapping document [2] (Grevenbosch,20min) 6. Open Mic, Open issues, Technical discussion (*all*, 50min) [1] https://datatracker.ietf.org/doc/draft-zeltsan-scim-use-cases/ [2] http://datatracker.ietf.org/doc/draft-greevenbosch-scim-vcard-mapping/ Leif & Morteza From lear@cisco.com Fri Nov 2 02:09:45 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E27221F99CF for ; Fri, 2 Nov 2012 02:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tp9LQt6HzLlz for ; Fri, 2 Nov 2012 02:09:44 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 165FB21F99C6 for ; Fri, 2 Nov 2012 02:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=969; q=dns/txt; s=iport; t=1351847384; x=1353056984; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VUVY+35GEskopmDz3Xtv71oo+esRhu7IAiMhfH9Akzw=; b=E2jPCrtIvBx9ppnnFREk/8wHxPeRtxMn8F9p1Gc/ClmuPqx7JoukVrPk QNhEvHHnyMGoUR6uNbmdq3NI6YeAyAQUnf3GTCKZn72h0ILU6HsUd71kQ 1oqLU8xhpUPsdB6tB/nwTTZ7IUXjQVNg3+qQ+RnB5fjwLViXITNZpIvEC I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukFAKKMk1CtJXHA/2dsb2JhbABEhVBHvSCBCIIeAQEBBAEBAQ8BEEsKARALGAICBRYLAgIJAwIBAgEVMAYNAQUCAQEeh2gLnBGNKZJjgSCQCYETA5V5gRyNPYFrgnA X-IronPort-AV: E=Sophos;i="4.80,697,1344211200"; d="scan'208";a="138064683" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 02 Nov 2012 09:09:43 +0000 Received: from sjc-vpn7-1440.cisco.com (sjc-vpn7-1440.cisco.com [10.21.149.160]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA299f0U022501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2012 09:09:42 GMT Message-ID: <50938DD4.1030407@cisco.com> Date: Fri, 02 Nov 2012 10:09:40 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Leif Johansson References: <509389EB.8060509@mnt.se> In-Reply-To: <509389EB.8060509@mnt.se> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim WG Subject: Re: [scim] Agenda for ATL X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 09:09:45 -0000 Hi Leif and Morteza, Sorry to be a pain, but may I request that we have some discussion time reserved between items 2 and 3? Or in the alternative, swap items 2 and 5? Eliot On 11/2/12 9:52 AM, Leif Johansson wrote: > Here is the agenda for Atlanta. The current version of the agenda has us > meeting 13:00-15:00 on Thursday. > > 1. Note Well and Agenda Bashing (5min) > 2. Goals for the DT (Chairs, 10min) > 3. A word from the tracker general (Shore,15min) > 4. Use-case document [1] (Zeltzan,20min) > 5. vCard mapping document [2] (Grevenbosch,20min) > 6. Open Mic, Open issues, Technical discussion (*all*, 50min) > > > [1] https://datatracker.ietf.org/doc/draft-zeltsan-scim-use-cases/ > [2] http://datatracker.ietf.org/doc/draft-greevenbosch-scim-vcard-mapping/ > > > Leif & Morteza > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > From leifj@mnt.se Fri Nov 2 02:22:35 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D2021F9973 for ; Fri, 2 Nov 2012 02:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FoD9ymuYGHf for ; Fri, 2 Nov 2012 02:22:35 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0C1E21F9933 for ; Fri, 2 Nov 2012 02:22:34 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2696973lbo.31 for ; Fri, 02 Nov 2012 02:22:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=lxWzV1iWZbn5Qj08p5p1unUhTshljUqtigOZXYRx0j8=; b=J1Lu6Ash+o7EXzkBiqT8o9EEsG2YqW6lW5rx9VuAu+E0SsgIESblseGVev5b9wW9pB zoShoTAjq9ygf4+GlcVmuWHvY89cYlFsCz5ZJYiQptsDGeVKdlMzVB/X+WG/dT+k861+ 4+1aShxXklT8/6ra2dYFvcSxZ22KePV715kiwuwjkxILg9sC7s5NWjWzfrSNJxvMCcGd NDM1pmOYpc04U1N6uxnnvTfBuuNE+MFZxF4wsPScZy21I3Vos8hxagm4ASZGAhxuwHXS FvEcVQPmcSh4FJeGCeMql9wG9u01Z53WenjJW1X+3amiqDb+d3uAj6iR0Rs2n0aYbAS/ 3pWA== Received: by 10.112.49.201 with SMTP id w9mr487996lbn.100.1351848153790; Fri, 02 Nov 2012 02:22:33 -0700 (PDT) Received: from [192.168.177.35] ([193.214.121.242]) by mx.google.com with ESMTPS id ts2sm2924010lab.10.2012.11.02.02.22.31 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 02:22:32 -0700 (PDT) Message-ID: <509390D6.9010009@mnt.se> Date: Fri, 02 Nov 2012 10:22:30 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eliot Lear References: <509389EB.8060509@mnt.se> <50938DD4.1030407@cisco.com> In-Reply-To: <50938DD4.1030407@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmKY/0PbBoqFL6/LbtkaBoEn8k/5/9YVTF1OoJKC63GtUONKcR5IghNimkQV49ZM2nelreB Cc: scim WG Subject: Re: [scim] Agenda for ATL X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 09:22:36 -0000 On 11/02/2012 10:09 AM, Eliot Lear wrote: > Hi Leif and Morteza, > > Sorry to be a pain, but may I request that we have some discussion time > reserved between items 2 and 3? Or in the alternative, swap items 2 and 5? How about the chairs try to keep 2 very short and try to carve out most of those 10 minutes for questions and comments? > > Eliot > > On 11/2/12 9:52 AM, Leif Johansson wrote: >> Here is the agenda for Atlanta. The current version of the agenda has us >> meeting 13:00-15:00 on Thursday. >> >> 1. Note Well and Agenda Bashing (5min) >> 2. Goals for the DT (Chairs, 10min) >> 3. A word from the tracker general (Shore,15min) >> 4. Use-case document [1] (Zeltzan,20min) >> 5. vCard mapping document [2] (Grevenbosch,20min) >> 6. Open Mic, Open issues, Technical discussion (*all*, 50min) >> >> >> [1] https://datatracker.ietf.org/doc/draft-zeltsan-scim-use-cases/ >> [2] http://datatracker.ietf.org/doc/draft-greevenbosch-scim-vcard-mapping/ >> >> >> Leif & Morteza >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> From bjorn.aannestad@unboundid.com Fri Nov 2 08:30:51 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0DA21F8B9A for ; Fri, 2 Nov 2012 08:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=-1.394, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfQ7SxWM-Qfr for ; Fri, 2 Nov 2012 08:30:51 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 29A7B11E809C for ; Fri, 2 Nov 2012 08:30:51 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so4008930obq.31 for ; Fri, 02 Nov 2012 08:30:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=hlJMyqgGX+N8ko7skEfflF+XX7UqrQZVPb+TA7slAvM=; b=P0AByHe1XzEXAkZpt+ue+zLzYxH8CyVagjJLavZJkO7GseBxhP+n274JWCSbFSJqDL Z+xE2fRKBjSVmxgGj4F7MGPA1eyCxDcmnyenyrXS8OMO8BbA5culISHq3Z7ftVLU6PB7 zinL+A0J9X4YG8fC/+LV9d4BFeB6PlhP29uABarEZTlJzFfMxyb7jsKlsoLgB9+V+Ut7 x1uI0XKqMjxy9By5aRpSabc8Fd+sl0RelJCtWIR55Ta9RxzEfogg51vPQmOazZ9FzfP9 A5p8WwMBgnmxq6Fwc6+kLASbePiYelz7eB9w4q9OCNXhSb6noeXleLB+1K4wxmVXOCUj 4XNQ== Received: by 10.60.168.230 with SMTP id zz6mr1723659oeb.38.1351870244490; Fri, 02 Nov 2012 08:30:44 -0700 (PDT) Received: from [10.8.1.249] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id g17sm3032869oei.10.2012.11.02.08.30.42 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 08:30:42 -0700 (PDT) Message-ID: <5093E719.8080909@unboundid.com> Date: Fri, 02 Nov 2012 10:30:33 -0500 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Likepeng References: <5092F887.7020903@unboundid.com> <34966E97BE8AD64EAE9D3D6E4DEE36F21ED6B19C@szxeml525-mbx.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F21ED6B19C@szxeml525-mbx.china.huawei.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070402070507000104050104" X-Gm-Message-State: ALoCoQkog5mRPIvL9LfJWU4DU14SKTr3WnPoI6VmvYlBPgOgPiX42aavOzokfcYsyAjAEW2xLZud Cc: scim WG Subject: Re: [scim] Considerations for evaluating the suitability of vCard? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 15:30:52 -0000 This is a cryptographically signed message in MIME format. --------------ms070402070507000104050104 Content-Type: multipart/mixed; boundary="------------090607070802040903090903" This is a multi-part message in MIME format. --------------090607070802040903090903 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Thank you very much for pointing that out! It contains good work that we can simply refer to. -Bjorn On 11/1/2012 20:18, Likepeng wrote: > There is an available draft related to this topic: > http://datatracker.ietf.org/doc/draft-greevenbosch-scim-vcard-mapping/ > > We can use that as a baseline for discussion, or you guys can work toge= ther for this topic. > > Kind Regards > Kepeng > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org= ] =B4=FA=B1=ED Bjorn Aannestad > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C22=C8=D5 6:33 > =CA=D5=BC=FE=C8=CB: scim WG > =D6=F7=CC=E2: [scim] Considerations for evaluating the suitability of v= Card? > > Based on a suggestion from Morteza, Kelly Grizzle and I volunteered to = assemble some "findings" about vCard for presentation to the group at IET= F next week. The same information will be sent to the list for everyone = to review. > > Our goal is to provide some of the information needed for the group to = make an eventual decision on #19 - "Incorporate vCard as the SCIM schema.= " > > To do that, we're considering the following: > * Extensibility for additional attributes > * Extensibility for additional resource types > * Support for meta-data on attributes and on values > > * Alignment with SCIM's charter goals ("simplicity", etc) > * Gap analysis between what SCIM now supports and vCard, leading to a s= ense of how much work there is to bring it in. > > * Existence and suitability of a JSON representation > * Degree of adoption, and by whom. Existence of client libraries. > > * Support for complex objects > * Support for relationships between objects > > * Ability to work together with the vCard group for advice and > (potentially) changes to vCard itself > > * Any "baggage" that vCard may bring with it > > Some of these are objective and easy to answer, others are subjective. > > What other aspects should we consider? Is an important consideration = > missing from the above? > > Thanks! > -Bjorn Aannestad > > > > -- > __________________________________________________________ > Bjorn Aannestad | Dir, Product Management | UnboundID Corp mailto:bjorn= @unboundid.com | 512-769-6461 > --=20 __________________________________________________________ Bjorn Aannestad | Dir, Product Management | UnboundID Corp mailto:bjorn@unboundid.com | 512-769-6461 --------------090607070802040903090903 Content-Type: text/x-vcard; charset=utf-8; name="bjorn_aannestad.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bjorn_aannestad.vcf" YmVnaW46dmNhcmQNCmZuOkJqb3JuIEFhbm5lc3RhZA0KbjpBYW5uZXN0YWQ7Qmpvcm4NCm9y ZzpVbmJvdW5kSUQNCmVtYWlsO2ludGVybmV0OmJqb3JuQHVuYm91bmRpZC5jb20NCnRpdGxl OkRpcmVjdG9yLCBQcm9kdWN0IE1hbmFnZW1lbnQNCnRlbDt3b3JrOjUxMiA2MDAgNzc1Mw0K dGVsO2NlbGw6NTEyIDc2OSA2NDYxDQpub3RlOnNreXBlOiBiam9ybl9hYW5uZXN0YWQNCnZl cnNpb246Mi4xDQplbmQ6dmNhcmQNCg0K --------------090607070802040903090903-- --------------ms070402070507000104050104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMUjCC BVwwggREoAMCAQICECStp7X80wzNJ6GfICadV/cwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjAyMjMwMDAwMDBaFw0xMzAyMjIyMzU5NTlaMIIBHzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRgwFgYDVQQDFA9Cam9ybiBBYW5u ZXN0YWQxLDAqBgkqhkiG9w0BCQEWHWJqb3JuLmFhbm5lc3RhZEB1bmJvdW5kaWQuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw+4r+Le4uODrErBgJsA7UoexcjH/r2Ds 62wKyDCY5CQfOFMROnynV9GWWXp8zmCj7/N9I2hOU7poaqR4kkJjoiKiNHQdVfyM1yFZTurW AV5PCT5NouiqlruJDM6s2HV3B7mSRhtHFOSfhiDP+/kHf/JEdFJ7zEPaP0Kuy8XKpPR5nVCz k4zFKPBc4T9+HAlXeGY1PnwOsxPEevZlHOTThF9RunZu5Z/uaObR2JplM6KxXDfXNRjSkmK7 6kW8wFC1C0GleHKfM85nQTvVicuSK4GbbvhMjqovMtUIR1SNG8vsmTvU4PY9G/WkDM4Ge/97 phIcQIm9W/DXjC78wBfa/QIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5Bgtg hkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh MAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkw RzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5k QzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQC345zS3026vrJVysBCE3TN BhQ4VlqRtwj5AcAXhhF2c3krlbgJRLV6STYky+/i7YRdezIZYgY2eo693dlIQUnkZMb6D2PL dRs1Lgw4NJKB+WGLGkmyV8YqqKrTm/ZbPdl/+Y4Pc88DLcYEmr0OsEDel8LqLPpongUDnGU5 2wxAvaHn9sZ4nyDa3bAy9RyqrAdWhsfRttlgAbvMeHSXhvDa63AbdGdZbzBfqGpBTYZJqrA/ fzcbVZQIw7ULW0YRpUNx8bmmgxFd5ovdDVZnfiKNd7QHy+BcTQgfxLYsBYZhICz1ud1QKn88 pW944VjwHTzxyErX43AGoPYoZKA8b3XXMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT 3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5 OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6 ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f 0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Iba k2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+ wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBn MGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNV HR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNV HQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAH BgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24u Y29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0 LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHm oYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSo WufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6 jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvi d+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5l UkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaM xmgD5yKocwuxvKDaUljdCg5/wYIxggT5MIIE9QIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhAkrae1/NMMzSeh nyAmnVf3MAkGBSsOAwIaBQCgggLbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMTEwMjE1MzAzM1owIwYJKoZIhvcNAQkEMRYEFOGwhGqqRCaH7DW5vgOo 15goSzRMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQJK2ntfzTDM0noZ8gJp1X 9zCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCECStp7X80wzNJ6GfICadV/cwDQYJ KoZIhvcNAQEBBQAEggEALBGK8KEBL9FfrUbLmuHh40Lmt0x3N49nVueJZ9moFIoyAH4olVpK 3lnCgJCCRUTjg2OdxoBFsKOe5XWFqi+UdJ6JLUWzRZ4/I2t9brAUsAHAcm6DHhHGqwsTqS+6 1x5itxdQIbtVQFLCiAsVlZEcI91o+0eHHvapUtYcq8AnIJ2xzCmQRlL51pINLtIjuthmK95R 6NuLQYy9CKwNryWe3RnWOVSdtM5lCvgA0dqeGBBjWkO3XD75UiM7crWDA/xOQESMa3GLYRdd EmjLtX20UHw492XwPU4lTRv34CkKucEuMySWMZXKwkejM1SeURfaGSpAnRs4+f/PmuHqWm1v EQAAAAAAAA== --------------ms070402070507000104050104-- From kelly.grizzle@sailpoint.com Fri Nov 2 09:55:21 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2582421F86B6 for ; Fri, 2 Nov 2012 09:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=-3.517, BAYES_50=0.001, FM_ASCII_ART_SPACINGc=0.833, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYXlwbC-kvqk for ; Fri, 2 Nov 2012 09:55:14 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 42AD021F87DB for ; Fri, 2 Nov 2012 09:55:12 -0700 (PDT) Received: from mail234-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.23; Fri, 2 Nov 2012 16:55:11 +0000 Received: from mail234-ch1 (localhost [127.0.0.1]) by mail234-ch1-R.bigfish.com (Postfix) with ESMTP id A9D084000A7 for ; Fri, 2 Nov 2012 16:55:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zz9371Ic89bh542Mc857hzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h) Received-SPF: pass (mail234-ch1: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail234-ch1 (localhost.localdomain [127.0.0.1]) by mail234-ch1 (MessageSwitch) id 1351875309791732_28302; Fri, 2 Nov 2012 16:55:09 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail234-ch1.bigfish.com (Postfix) with ESMTP id B31A21780045 for ; Fri, 2 Nov 2012 16:55:09 +0000 (UTC) Received: from BY2PRD0410HT002.namprd04.prod.outlook.com (157.56.236.85) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 2 Nov 2012 16:55:08 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.11.81]) by BY2PRD0410HT002.namprd04.prod.outlook.com ([10.255.83.37]) with mapi id 14.16.0233.002; Fri, 2 Nov 2012 16:55:07 +0000 From: Kelly Grizzle To: "scim@ietf.org" Thread-Topic: [scim] #27: Make support for XML optional or drop it; JSON required Thread-Index: AQHNuRmMyWmYbsw9YEeH5YBLB7wTh5fWwlfQ Date: Fri, 2 Nov 2012 16:55:07 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <068.6f8ea83285aaea9cd481e0e5a8490f9c@tools.ietf.org> <083.1dd51238238687e2c8a67e0faf29da50@tools.ietf.org> In-Reply-To: <083.1dd51238238687e2c8a67e0faf29da50@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-vipre-scanned: 6C5850F60035DD6C585243 x-originating-ip: [173.226.147.242] Content-Type: multipart/mixed; boundary="_003_56C3C758F9D6534CA3778EAA1E0C34373E7F2E20BY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] #27: Make support for XML optional or drop it; JSON required X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:55:21 -0000 --_003_56C3C758F9D6534CA3778EAA1E0C34373E7F2E20BY2PRD0410MB354_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHJldmlldyB0aGUgcHJvcG9zZWQgY2hhbmdlcyB0byByZW1vdmUgWE1MIHN1cHBvcnQg ZnJvbSBTQ0lNLiAgQW55IGZlZWRiYWNrIGlzIGdyZWF0bHkgYXBwcmVjaWF0ZWQuICBJIGhhdmUg YXR0YWNoZWQgdGhlIGZ1bGwgdHh0IGRvY3VtZW50cywgd2hpY2ggbWF5IGJlIGVhc2llciB0byBy ZWFkIHRoYW4gdGhlIGRpZmZzIChhdHRhY2hlZCB0byB0aWNrZXQgIzI3KS4NCg0KLS1LZWxseQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2NpbSBpc3N1ZSB0cmFja2VyIFtt YWlsdG86dHJhYytzY2ltQHRvb2xzLmlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIg MDIsIDIwMTIgMTE6NDYgQU0NClRvOiBLZWxseSBHcml6emxlOyBiam9ybi5hYW5uZXN0YWRAdW5i b3VuZGlkLmNvbQ0KQ2M6IHNjaW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2NpbV0gIzI3OiBN YWtlIHN1cHBvcnQgZm9yIFhNTCBvcHRpb25hbCBvciBkcm9wIGl0OyBKU09OIHJlcXVpcmVkDQoN CiMyNzogTWFrZSBzdXBwb3J0IGZvciBYTUwgb3B0aW9uYWwgb3IgZHJvcCBpdDsgSlNPTiByZXF1 aXJlZA0KDQoNCkNvbW1lbnQgKGJ5IGtlbGx5LmdyaXp6bGVA4oCmKToNCg0KIEF0dGFjaGVkIGEg ZGlmZiBmcm9tIHJldmlzaW9uIDIwNiBvZg0KIGh0dHBzOi8vc2NpbS5nb29nbGVjb2RlLmNvbS9z dm4vdHJ1bmsvc3BlY3MvaWV0ZiB3aXRoIHByb3Bvc2VkIGNoYW5nZXMuDQogQXQgYSBoaWdoIGxl dmVsLCB0aGUgZm9sbG93aW5nIGNoYW5nZXMgd2VyZSBtYWRlOg0KDQogMSkgUmVtb3ZlZCBtZW50 aW9ucyBvZiBYTUwgZm9ybWF0IGZyb20gYm90aCBzY2hlbWEgYW5kIEFQSSBkb2N1bWVudHMuDQog MikgQ2hhbmdlZCBzZWN0aW9uIDMgKFNDSU0gU2NoZW1hIFN0cnVjdHVyZSkgb2Ygc2NoZW1hIGRv Y3VtZW50IHRvIGJlICBiYXNlZCBvZmYgb2YgSlNPTi4gIEF0dHJpYnV0ZSB0eXBlcyBhcmUgbm93 IGFsbCBkZXJpdmVkIGZyb20gSlNPTi4gIEJpbmFyeSAgYW5kIERhdGVUaW1lIGhhdmUgbm8gSlNP TiByZXByZXNlbnRhdGlvbiwgc28gdGhlc2UgYm90aCB1c2UgWE1MICBmb3JtYXR0aW5nLg0KIDMp IFJlbW92ZWQgeG1sRGF0YUZvcm1hdCBmcm9tIHRoZSBTZXJ2aWNlUHJvdmlkZXJDb25maWcgcmVz b3VyY2UuDQogNCkgUmVtb3ZlZCBtdWx0aVZhbHVlZEF0dHJpYnV0ZUNoaWxkTmFtZSBmcm9tIHRo ZSBTY2hlbWEgcmVzb3VyY2UuDQogNSkgUmVtb3ZlZCBhbGwgWE1MIHJlcHJlc2VudGF0aW9uIGV4 YW1wbGVzIGZyb20gdGhlIHNjaGVtYSBkb2N1bWVudC4NCiA2KSBSZW1vdmVkIGFwcGxpY2F0aW9u L3htbCBjb250ZW50IHR5cGUgZnJvbSB0aGUgRGF0YSBJbnB1dC9PdXRwdXQgRm9ybWF0ICBzZWN0 aW9uIG9mIHRoZSBBUEkgZG9jdW1lbnQuDQogNykgUmVtb3ZlZCBYTUwgZXhhbXBsZXMgZnJvbSB0 aGUgRGF0YSBJbnB1dC9PdXRwdXQgRm9ybWF0IHNlY3Rpb24gb2YgdGhlICBBUEkgZG9jdW1lbnQu DQoNCi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIGJqb3JuLmFhbm5lc3RhZEDigKYgIHwgICAgICAg T3duZXI6ICBrZWxseS5ncml6emxlQOKApg0KICAgICBUeXBlOiAgZW5oYW5jZW1lbnQgICAgICAg IHwgICAgICBTdGF0dXM6ICBhc3NpZ25lZA0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAg IHwgICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBhcGkgICAgICAgICAgICAgICAgfCAgICAgVmVy c2lvbjoNCiBTZXZlcml0eTogIC0gICAgICAgICAgICAgICAgICB8ICBSZXNvbHV0aW9uOg0KIEtl eXdvcmRzOiAgICAgICAgICAgICAgICAgICAgIHwNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRw Oi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9zY2ltL3RyYWMvdGlja2V0LzI3I2NvbW1lbnQ6ND4N CnNjaW0gPGh0dHA6Ly90b29scy5pZXRmLm9yZy9zY2ltLz4NCg0KDQo= --_003_56C3C758F9D6534CA3778EAA1E0C34373E7F2E20BY2PRD0410MB354_ Content-Type: text/plain; name="draft-ietf-scim-api-01.txt" Content-Description: draft-ietf-scim-api-01.txt Content-Disposition: attachment; filename="draft-ietf-scim-api-01.txt"; size=80760; creation-date="Fri, 02 Nov 2012 16:09:31 GMT"; modification-date="Fri, 02 Nov 2012 16:09:32 GMT" Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBULiBEcmFrZSwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFVuYm91bmRJRApJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICBDLiBNb3J0aW1vcmUKRXhwaXJl czogTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBT YWxlc0ZvcmNlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE0uIEFuc2FyaQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lzY28KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBLLiBHcml6emxl CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFNhaWxQb2ludAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEUuIFdhaGxzdHJvZW0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUZWNobm9sb2d5IE5leHVzCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTm92ZW1iZXIg MSwgMjAxMgoKCiAgICAgICAgICBTeXN0ZW0gZm9yIENyb3NzLURvbWFpbiBJZGVudGl0eSBNYW5h Z2VtZW50OlByb3RvY29sCiAgICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLXNjaW0t YXBpLTAxCgpBYnN0cmFjdAoKICAgVGhlIFN5c3RlbSBmb3IgQ3Jvc3MtRG9tYWluIElkZW50aXR5 IE1hbmFnZW1lbnQgKFNDSU0pIHNwZWNpZmljYXRpb24KICAgaXMgZGVzaWduZWQgdG8gbWFrZSBt YW5hZ2luZyB1c2VyIGlkZW50aXR5IGluIGNsb3VkIGJhc2VkCiAgIGFwcGxpY2F0aW9ucyBhbmQg c2VydmljZXMgZWFzaWVyLiAgVGhlIHNwZWNpZmljYXRpb24gc3VpdGUgc2Vla3MgdG8KICAgYnVp bGQgdXBvbiBleHBlcmllbmNlIHdpdGggZXhpc3Rpbmcgc2NoZW1hcyBhbmQgZGVwbG95bWVudHMs IHBsYWNpbmcKICAgc3BlY2lmaWMgZW1waGFzaXMgb24gc2ltcGxpY2l0eSBvZiBkZXZlbG9wbWVu dCBhbmQgaW50ZWdyYXRpb24sIHdoaWxlCiAgIGFwcGx5aW5nIGV4aXN0aW5nIGF1dGhlbnRpY2F0 aW9uLCBhdXRob3JpemF0aW9uLCBhbmQgcHJpdmFjeSBtb2RlbHMuCiAgIEl0J3MgaW50ZW50IGlz IHRvIHJlZHVjZSB0aGUgY29zdCBhbmQgY29tcGxleGl0eSBvZiB1c2VyIG1hbmFnZW1lbnQKICAg b3BlcmF0aW9ucyBieSBwcm92aWRpbmcgYSBjb21tb24gdXNlciBzY2hlbWEgYW5kIGV4dGVuc2lv biBtb2RlbCwgYXMKICAgd2VsbCBhcyBiaW5kaW5nIGRvY3VtZW50cyB0byBwcm92aWRlIHBhdHRl cm5zIGZvciBleGNoYW5naW5nIHRoaXMKICAgc2NoZW1hIHVzaW5nIHN0YW5kYXJkIHByb3RvY29s cy4gIEluIGVzc2VuY2UsIG1ha2UgaXQgZmFzdCwgY2hlYXAsCiAgIGFuZCBlYXN5IHRvIG1vdmUg dXNlcnMgaW4gdG8sIG91dCBvZiwgYW5kIGFyb3VuZCB0aGUgY2xvdWQuCgpTdGF0dXMgb2YgdGhp cyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZv cm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJ bnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdp bmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5 IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMu ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBh cmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1l bnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQt RHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhh biBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhw aXJlIG9uIE1heSA1LCAyMDEzLgoKQ29weXJpZ2h0IE5vdGljZQoKCgpEcmFrZSwgZXQgYWwuICAg ICAgICAgICAgICBFeHBpcmVzIE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgZHJhZnQtc2NpbS1hcGktMDEgICAgICAgICAg ICAgIE5vdmVtYmVyIDIwMTIKCgogICBDb3B5cmlnaHQgKGMpIDIwMTIgSUVURiBUcnVzdCBhbmQg dGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCBy aWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFu ZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBE b2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZm ZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVh c2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUg eW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1 bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QK ICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNl Y3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlk ZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNE IExpY2Vuc2UuCgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gYW5kIE92 ZXJ2aWV3ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAgIDEuMS4g IEludGVuZGVkIEF1ZGllbmNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDMKICAgICAxLjIuICBOb3RhdGlvbmFsIENvbnZlbnRpb25zIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgICAgMS4zLiAgRGVmaW5pdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAyLiAgQXV0aGVudGljYXRp b24gYW5kIEF1dGhvcml6YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMKICAg My4gIEFQSSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA0CiAgICAgMy4xLiAgQ3JlYXRpbmcgUmVzb3VyY2VzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDMuMi4gIFJldHJpZXZpbmcgUmVzb3Vy Y2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAgICAgIDMuMi4x LiAgUmV0cmlldmluZyBhIGtub3duIFJlc291cmNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA3CiAgICAgICAzLjIuMi4gIExpc3QvUXVlcnkgUmVzb3VyY2VzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgOAogICAgIDMuMy4gIE1vZGlmeWluZyBSZXNvdXJjZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAgICAgIDMuMy4xLiAgTW9kaWZ5 aW5nIHdpdGggUFVUIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgICAg ICAzLjMuMi4gIE1vZGlmeWluZyB3aXRoIFBBVENIIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxNwogICAgIDMuNC4gIERlbGV0aW5nIFJlc291cmNlcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjUKICAgICAzLjUuICBCdWxrIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2CiAgICAgMy42LiAgRGF0 YSBJbnB1dC9PdXRwdXQgRm9ybWF0cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0 MQogICAgIDMuNy4gIEFkZGl0aW9uYWwgcmV0cmlldmFsIHF1ZXJ5IHBhcmFtZXRlcnMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gNDEKICAgICAzLjguICBBdHRyaWJ1dGUgTm90YXRpb24gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQyCiAgICAgMy45LiAgSFRUUCBSZXNwb25z ZSBDb2RlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MgogICAgIDMu MTAuIEFQSSBWZXJzaW9uaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNDQKICAgICAzLjExLiBWZXJzaW9uaW5nIFJlc291cmNlcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ0CiAgICAgMy4xMi4gSFRUUCBNZXRob2QgT3ZlcmxvYWRp bmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NgogICA0LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDYK ICAgNS4gIENvbnRyaWJ1dG9ycyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDQ2CiAgIDYuICBBY2tub3dsZWRnbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NwogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDcKCgoKCgoKCgoK RHJha2UsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAg ICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGRyYWZ0LXNjaW0t YXBpLTAxICAgICAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKMS4gIEludHJvZHVjdGlvbiBhbmQg T3ZlcnZpZXcKCiAgIFRoZSBTQ0lNIFByb3RvY29sIGlzIGFuIGFwcGxpY2F0aW9uLWxldmVsLCBS RVNUIHByb3RvY29sIGZvcgogICBwcm92aXNpb25pbmcgYW5kIG1hbmFnaW5nIGlkZW50aXR5IGRh dGEgb24gdGhlIHdlYi4gIFRoZSBwcm90b2NvbAogICBzdXBwb3J0cyBjcmVhdGlvbiwgbW9kaWZp Y2F0aW9uLCByZXRyaWV2YWwsIGFuZCBkaXNjb3Zlcnkgb2YgY29yZQogICBpZGVudGl0eSBSZXNv dXJjZXM7IGkuZS4sIFVzZXJzIGFuZCBHcm91cHMsIGFzIHdlbGwgYXMgY3VzdG9tCiAgIFJlc291 cmNlIGV4dGVuc2lvbnMuCgoxLjEuICBJbnRlbmRlZCBBdWRpZW5jZQoKICAgVGhpcyBkb2N1bWVu dCBpcyBpbnRlbmRlZCBhcyBhIGd1aWRlIHRvIFNDSU0gQVBJIHVzYWdlIGZvciBib3RoCiAgIGlk ZW50aXR5IFNlcnZpY2UgUHJvdmlkZXJzIGFuZCBDb25zdW1lcnMuCgoxLjIuICBOb3RhdGlvbmFs IENvbnZlbnRpb25zCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJ UkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJS RUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFy ZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLiAgVGhlc2UKICAg a2V5d29yZHMgYXJlIGNhcGl0YWxpemVkIHdoZW4gdXNlZCB0byB1bmFtYmlndW91c2x5IHNwZWNp ZnkKICAgcmVxdWlyZW1lbnRzIG9mIHRoZSBwcm90b2NvbCBvciBhcHBsaWNhdGlvbiBmZWF0dXJl cyBhbmQgYmVoYXZpb3IKICAgdGhhdCBhZmZlY3QgdGhlIGludGVyb3BlcmFiaWxpdHkgYW5kIHNl Y3VyaXR5IG9mIGltcGxlbWVudGF0aW9ucy4KICAgV2hlbiB0aGVzZSB3b3JkcyBhcmUgbm90IGNh cGl0YWxpemVkLCB0aGV5IGFyZSBtZWFudCBpbiB0aGVpcgogICBuYXR1cmFsLWxhbmd1YWdlIHNl bnNlLgoKICAgRm9yIHB1cnBvc2VzIG9mIHJlYWRhYmlsaXR5IGV4YW1wbGVzIGFyZSBub3QgVVJM IGVuY29kZWQuCiAgIEltcGxlbWVudGVycyBNVVNUIHBlcmNlbnQgZW5jb2RlIFVSTHMgYXMgZGVz Y3JpYmVkIGluIFJGQzM4OTYgMi4xLgoKMS4zLiAgRGVmaW5pdGlvbnMKCiAgIEJhc2UgVVJMOiAg VGhlIFNDSU0gUkVTVCBBUEkgaXMgYWx3YXlzIHJlbGF0aXZlIHRvIGEgQmFzZSBVUkwuICBUaGUK ICAgICAgQmFzZSBVUkwgTVVTVCBOT1QgY29udGFpbiBhIHF1ZXJ5IHN0cmluZyBhcyBDb25zdW1l cnMgbWF5IGFwcGVuZAogICAgICBhZGRpdGlvbmFsIHBhdGggaW5mb3JtYXRpb24gYW5kIHF1ZXJ5 IHBhcmFtZXRlcnMgYXMgcGFydCBvZgogICAgICBmb3JtaW5nIHRoZSByZXF1ZXN0LiAgRXhhbXBs ZTogaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL3YxLwoKCjIuICBBdXRoZW50aWNhdGlvbiBhbmQg QXV0aG9yaXphdGlvbgoKICAgVGhlIFNDSU0gcHJvdG9jb2wgZG9lcyBub3QgZGVmaW5lIGEgc2No ZW1lIGZvciBhdXRoZW50aWNhdGlvbiBhbmQKICAgYXV0aG9yaXphdGlvbiB0aGVyZWZvcmUgaW1w bGVtZW50ZXJzIGFyZSBmcmVlIHRvIGNob29zZSBtZWNoYW5pc21zCiAgIGFwcHJvcHJpYXRlIHRv IHRoZWlyIHVzZSBjYXNlcy4gIFRoZSBjaG9pY2Ugb2YgYXV0aGVudGljYXRpb24KICAgbWVjaGFu aXNtIHdpbGwgaW1wYWN0IGludGVyb3BlcmFiaWxpdHkuICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0 CiAgIGNsaWVudHMgYmUgaW1wbGVtZW50ZWQgaW4gc3VjaCBhIHdheSB0aGF0IG5ldyBhdXRoZW50 aWNhdGlvbiBzY2hlbWVzCiAgIGNhbiBiZSBkZXBsb3llZC4gIEltcGxlbWVudGVycyBTSE9VTEQg c3VwcG9ydCBleGlzdGluZwogICBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIHNjaGVtZXMu ICBJbiBwYXJ0aWN1bGFyLCBPQXV0aDIgQmVhcmVyCiAgIFRva2VuIFsxXSBpcyBSRUNPTU1FTkRF RC4gIEFwcHJvcHJpYXRlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9mIHRoZQogICBzZWxlY3Rl ZCBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBzY2hlbWVzIFNIT1VMRCBiZSB0YWtl bi4KICAgQmVjYXVzZSB0aGlzIHByb3RvY29sIHVzZXMgSFRUUCByZXNwb25zZSBzdGF0dXMgY29k ZXMgYXMgdGhlIHByaW1hcnkKICAgbWVhbnMgb2YgcmVwb3J0aW5nIHRoZSByZXN1bHQgb2YgYSBy ZXF1ZXN0LCBzZXJ2ZXJzIGFyZSBhZHZpc2VkIHRvCgoKCkRyYWtlLCBldCBhbC4gICAgICAgICAg ICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAgTm92 ZW1iZXIgMjAxMgoKCiAgIHJlc3BvbmQgdG8gdW5hdXRob3JpemVkIG9yIHVuYXV0aGVudGljYXRl ZCByZXF1ZXN0cyB1c2luZyB0aGUgNDAxCiAgIHJlc3BvbnNlIGNvZGUgaW4gYWNjb3JkYW5jZSB3 aXRoIHNlY3Rpb24gMTAuNC4yIG9mIFJGQzI2MTYuCgogICBBbGwgZXhhbXBsZXMgYXNzdW1lIE9B dXRoMiBiZWFyZXIgdG9rZW47IGUuZy4sCgogICBHRVQgL1VzZXJzLzI4MTljMjIzLTdmNzYtNDUz YS05MTlkLTQxMzg2MTkwNDY0NiBIVFRQLzEuMQogICBIb3N0OiBleGFtcGxlLmNvbQogICBBdXRo b3JpemF0aW9uOiBCZWFyZXIgaDQ4MGRqczkzaGQ4CgogICBUaGUgY29udGV4dCBvZiB0aGUgcmVx dWVzdCAoaS5lLiB0aGUgdXNlciBmb3Igd2hvbSBkYXRhIGlzIGJlaW5nCiAgIHJlcXVlc3RlZCkg TVVTVCBiZSBpbmZlcnJlZCBieSBTZXJ2aWNlIFByb3ZpZGVycy4KCgozLiAgQVBJCgogICBUaGUg U0NJTSBwcm90b2NvbCBzcGVjaWZpZXMgd2VsbCBrbm93biBlbmRwb2ludHMgYW5kIEhUVFAgbWV0 aG9kcyBmb3IKICAgbWFuYWdpbmcgUmVzb3VyY2VzIGRlZmluZWQgaW4gdGhlIGNvcmUgc2NoZW1h OyBpLmUuLCBVc2VyIGFuZCBHcm91cAogICBSZXNvdXJjZXMgY29ycmVzcG9uZCB0byAvVXNlcnMg YW5kIC9Hcm91cHMgcmVzcGVjdGl2ZWx5LiAgU2VydmljZQogICBQcm92aWRlcnMgdGhhdCBzdXBw b3J0IGV4dGVuZGVkIFJlc291cmNlcyBTSE9VTEQgZGVmaW5lIFJlc291cmNlCiAgIGVuZHBvaW50 cyB1c2luZyB0aGUgZXN0YWJsaXNoZWQgY29udmVudGlvbjsgcGx1cmFsaXplIHRoZSBSZXNvdXJj ZQogICBuYW1lIGRlZmluZWQgaW4gdGhlIGV4dGVuZGVkIHNjaGVtYSBieSBhcHBlbmRpbmcgYW4g J3MnLiAgR2l2ZW4gdGhlcmUKICAgYXJlIGNhc2VzIHdoZXJlIFJlc291cmNlIHBsdXJhbGl6YXRp b24gaXMgYW1iaWd1b3VzOyBlLmcuLCBhIFJlc291cmNlCiAgIG5hbWVkICdwZXJzb24nIGlzIGxl Z2l0aW1hdGVseSAncGVyc29ucycgYW5kICdwZW9wbGUnIENvbnN1bWVycwogICBTSE9VTEQgZGlz Y292ZXIgUmVzb3VyY2UgZW5kcG9pbnRzIHZpYSB0aGUgU2NoZW1hIFN1Yi1BdHRyaWJ1dGUKICAg J2VuZHBvaW50Jy4KCiAgIEdFVCAgUmV0cmlldmVzIGEgY29tcGxldGUgb3IgcGFydGlhbCBSZXNv dXJjZS4KCiAgIFBPU1QgIENyZWF0ZSBuZXcgUmVzb3VyY2Ugb3IgYnVsayBtb2RpZnkgUmVzb3Vy Y2VzLgoKICAgUFVUICBNb2RpZmllcyBhIFJlc291cmNlIHdpdGggYSBjb21wbGV0ZSwgQ29uc3Vt ZXIgc3BlY2lmaWVkIFJlc291cmNlCiAgICAgIChyZXBsYWNlKS4KCiAgIFBBVENIICBNb2RpZmll cyBhIFJlc291cmNlIHdpdGggYSBzZXQgb2YgQ29uc3VtZXIgc3BlY2lmaWVkIGNoYW5nZXMKICAg ICAgKHBhcnRpYWwgdXBkYXRlKS4KCiAgIERFTEVURSAgRGVsZXRlcyBhIFJlc291cmNlLgoKCgoK CgoKCgoKCgoKCkRyYWtlLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMg ICAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBk cmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxMgoKCiAgICstLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tKwogICB8IFJlc291cmNlICAgfCBFbmRwb2ludCAgICAgICAgICAgfCBPcGVyYXRpb25zICAg IHwgRGVzY3JpcHRpb24gICAgIHwKICAgKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgVXNlciAgICAgICB8IC9V c2VycyAgICAgICAgICAgICB8IEdFVCAgICAgICAgICAgfCBSZXRyaWV2ZS9BZGQvTW8gfAogICB8 ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAoU2VjdGlvbiAzLjIuIHwgZGlmeSBV c2VycyAgICAgIHwKICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwgMSksIFBP U1QgICAgICB8ICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICB8ICAoU2VjdGlvbiAzLjEgfCAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgfCApLFBVVCAgICAgICAgIHwgICAgICAgICAgICAgICAg IHwKICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwgICAoU2VjdGlvbiAzLiB8 ICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8 IDMuMSksIFBBVENIICAgfCAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgfCAgICAoU2VjdGlvbiAzIHwgICAgICAgICAgICAgICAgIHwKICAgfCAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwgLjMuMiksIERFTEVURSB8ICAgICAgICAg ICAgICAgICB8CiAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8ICAgICAoU2Vj dGlvbiAgfCAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgfCAzLjQpICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwKICAgfCBHcm91cCAgICAg IHwgL0dyb3VwcyAgICAgICAgICAgIHwgR0VUICAgICAgICAgICB8IFJldHJpZXZlL0FkZC9NbyB8 CiAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8IChTZWN0aW9uIDMuMi4gfCBk aWZ5IEdyb3VwcyAgICAgfAogICB8ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAx KSwgUE9TVCAgICAgIHwgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgIHwgIChTZWN0aW9uIDMuMSB8ICAgICAgICAgICAgICAgICB8CiAgIHwgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8ICksUFVUICAgICAgICAgfCAgICAgICAgICAg ICAgICAgfAogICB8ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgIChTZWN0aW9u IDMuIHwgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgIHwgMy4xKSwgUEFUQ0ggICB8ICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICB8ICAgIChTZWN0aW9uIDMgfCAgICAgICAgICAgICAgICAgfAog ICB8ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAuMy4yKSwgREVMRVRFIHwgICAg ICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwgICAg IChTZWN0aW9uICB8ICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICB8IDMuNCkgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfAogICB8IFNlcnZp Y2UgICAgfCAvU2VydmljZVByb3ZpZGVyQ28gfCBHRVQgICAgICAgICAgIHwgUmV0cmlldmUgdGhl ICAgIHwKICAgfCBQcm92aWRlciAgIHwgbmZpZ3MgICAgICAgICAgICAgIHwgKFNlY3Rpb24gMy4y LiB8IFNlcnZpY2UgICAgICAgICB8CiAgIHwgQ29uZmlndXJhdCB8ICAgICAgICAgICAgICAgICAg ICB8IDEpICAgICAgICAgICAgfCBQcm92aWRlcidzICAgICAgfAogICB8IGlvbiAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgQ29uZmlndXJhdGlvbiAgIHwKICAg fCBTY2hlbWEgICAgIHwgL1NjaGVtYXMgICAgICAgICAgIHwgR0VUICAgICAgICAgICB8IFJldHJp ZXZlIGEgICAgICB8CiAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8IChTZWN0 aW9uIDMuMi4gfCBSZXNvdXJjZSdzICAgICAgfAogICB8ICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgfCAxKSAgICAgICAgICAgIHwgU2NoZW1hICAgICAgICAgIHwKICAgfCBCdWxrICAg ICAgIHwgL0J1bGsgICAgICAgICAgICAgIHwgUE9TVCAgICAgICAgICB8IEJ1bGsgbW9kaWZ5ICAg ICB8CiAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8IChTZWN0aW9uIDMuNSkg fCBSZXNvdXJjZXMgICAgICAgfAogICArLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAgICAg ICAgIFRhYmxlIDE6IERlZmluZWQgZW5kcG9pbnRzCgogICBBbGwgcmVxdWVzdHMgdG8gdGhlIFNl cnZpY2UgUHJvdmlkZXIgYXJlIG1hZGUgdmlhIEhUVFAgb3BlcmF0aW9ucyBvbgogICBhIFVSTCBk ZXJpdmVkIGZyb20gdGhlIEJhc2UgVVJMLiAgUmVzcG9uc2VzIGFyZSByZXR1cm5lZCBpbiB0aGUg Ym9keQogICBvZiB0aGUgSFRUUCByZXNwb25zZSwgZm9ybWF0dGVkIGFzIEpTT04uICBSZXNwb25z ZSBhbmQgZXJyb3IgY29kZXMKICAgU0hPVUxEIGJlIHRyYW5zbWl0dGVkIHZpYSB0aGUgSFRUUCBz dGF0dXMgY29kZSBvZiB0aGUgcmVzcG9uc2UgKGlmCiAgIHBvc3NpYmxlKSwgYW5kIFNIT1VMRCBh bHNvIGJlIHNwZWNpZmllZCBpbiB0aGUgYm9keSBvZiB0aGUgcmVzcG9uc2UuCgozLjEuICBDcmVh dGluZyBSZXNvdXJjZXMKCiAgIFRvIGNyZWF0ZSBuZXcgUmVzb3VyY2VzLCBjbGllbnRzIHNlbmQg UE9TVCByZXF1ZXN0cyB0byB0aGUgUmVzb3VyY2UKICAgZW5kcG9pbnQ7IGkuZS4sIC9Vc2VycyBv ciAvR3JvdXBzLgoKCgpEcmFrZSwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA1LCAy MDEzICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgZHJhZnQtc2NpbS1hcGktMDEgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgogICBTdWNj ZXNzZnVsIFJlc291cmNlIGNyZWF0aW9uIGlzIGluZGljYXRlZCB3aXRoIGEgMjAxICgiQ3JlYXRl ZCIpCiAgIHJlc3BvbnNlIGNvZGUuICBVcG9uIHN1Y2Nlc3NmdWwgY3JlYXRpb24sIHRoZSByZXNw b25zZSBib2R5IE1VU1QKICAgY29udGFpbiB0aGUgbmV3bHkgY3JlYXRlZCBSZXNvdXJjZS4gIFNp bmNlIHRoZSBzZXJ2ZXIgaXMgZnJlZSB0bwogICBhbHRlciBhbmQvb3IgaWdub3JlIFBPU1RlZCBj b250ZW50LCByZXR1cm5pbmcgdGhlIGZ1bGwgcmVwcmVzZW50YXRpb24KICAgY2FuIGJlIHVzZWZ1 bCB0byB0aGUgY2xpZW50LCBlbmFibGluZyBpdCB0byBjb3JyZWxhdGUgdGhlIGNsaWVudCBhbmQK ICAgc2VydmVyIHZpZXdzIG9mIHRoZSBuZXcgUmVzb3VyY2UuICBXaGVuIGEgUmVzb3VyY2UgaXMg Y3JlYXRlZCwgaXRzCiAgIFVSSSBtdXN0IGJlIHJldHVybmVkIGluIHRoZSByZXNwb25zZSBMb2Nh dGlvbiBoZWFkZXIuCgogICBJZiB0aGUgU2VydmljZSBQcm92aWRlciBkZXRlcm1pbmVzIGNyZWF0 aW9uIG9mIHRoZSByZXF1ZXN0ZWQgUmVzb3VyY2UKICAgY29uZmxpY3RzIHdpdGggZXhpc3Rpbmcg cmVzb3VyY2VzOyBlLmcuLCBhIFVzZXIgUmVzb3VyY2Ugd2l0aCBhCiAgIGR1cGxpY2F0ZSB1c2Vy TmFtZSwgdGhlIFNlcnZpY2UgUHJvdmlkZXIgTVVTVCByZXR1cm4gYSA0MDkgZXJyb3IgYW5kCiAg IFNIT1VMRCBpbmRpY2F0ZSB0aGUgY29uZmxpY3RpbmcgYXR0cmlidXRlKHMpIGluIHRoZSBib2R5 IG9mIHRoZQogICByZXNwb25zZS4KCiAgIEJlbG93LCB0aGUgY2xpZW50IHNlbmRzIGEgUE9TVCBy ZXF1ZXN0IGNvbnRhaW5pbmcgYSBVc2VyCgogICBQT1NUIC9Vc2VycyAgSFRUUC8xLjEKICAgSG9z dDogZXhhbXBsZS5jb20KICAgQWNjZXB0OiBhcHBsaWNhdGlvbi9qc29uCiAgIENvbnRlbnQtVHlw ZTogYXBwbGljYXRpb24vanNvbgogICBBdXRob3JpemF0aW9uOiBCZWFyZXIgaDQ4MGRqczkzaGQ4 CiAgIENvbnRlbnQtTGVuZ3RoOiAuLi4KCiAgIHsKICAgICAic2NoZW1hcyI6WyJ1cm46c2NpbTpz Y2hlbWFzOmNvcmU6MS4wIl0sCiAgICAgInVzZXJOYW1lIjoiYmplbnNlbiIsCiAgICAgImV4dGVy bmFsSWQiOiJiamVuc2VuIiwKICAgICAibmFtZSI6ewogICAgICAgImZvcm1hdHRlZCI6Ik1zLiBC YXJiYXJhIEogSmVuc2VuIElJSSIsCiAgICAgICAiZmFtaWx5TmFtZSI6IkplbnNlbiIsCiAgICAg ICAiZ2l2ZW5OYW1lIjoiQmFyYmFyYSIKICAgICB9CiAgIH0KCgogICBUaGUgc2VydmVyIHNpZ25h bHMgYSBzdWNjZXNzZnVsIGNyZWF0aW9uIHdpdGggYSBzdGF0dXMgY29kZSBvZiAyMDEuCiAgIFRo ZSByZXNwb25zZSBpbmNsdWRlcyBhIExvY2F0aW9uIGhlYWRlciBpbmRpY2F0aW5nIHRoZSBVc2Vy IFVSSSwgYW5kCiAgIGEgcmVwcmVzZW50YXRpb24gb2YgdGhhdCBVc2VyIGluIHRoZSBib2R5IG9m IHRoZSByZXNwb25zZS4KCgoKCgoKCgoKCgoKCkRyYWtlLCBldCBhbC4gICAgICAgICAgICAgIEV4 cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAgTm92ZW1iZXIg MjAxMgoKCkhUVFAvMS4xIDIwMSBDcmVhdGVkCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNv bgpMb2NhdGlvbjogaHR0cHM6Ly9leGFtcGxlLmNvbS92MS9Vc2Vycy8yODE5YzIyMy03Zjc2LTQ1 M2EtOTE5ZC00MTM4NjE5MDQ2NDYKRVRhZzogVy8iZTE4MGVlODRmMDY3MWIxIgoKewogICJzY2hl bWFzIjpbInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiXSwKICAiaWQiOiIyODE5YzIyMy03Zjc2 LTQ1M2EtOTE5ZC00MTM4NjE5MDQ2NDYiLAogICJleHRlcm5hbElkIjoiYmplbnNlbiIsCiAgIm1l dGEiOnsKICAgICJjcmVhdGVkIjoiMjAxMS0wOC0wMVQyMTozMjo0NC44ODJaIiwKICAgICJsYXN0 TW9kaWZpZWQiOiIyMDExLTA4LTAxVDIxOjMyOjQ0Ljg4MloiLAogICAgImxvY2F0aW9uIjoiaHR0 cHM6Ly9leGFtcGxlLmNvbS92MS9Vc2Vycy8yODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5 MDQ2NDYiLAogICAgInZlcnNpb24iOiJXXC9cImUxODBlZTg0ZjA2NzFiMVwiIgogIH0sCiAgIm5h bWUiOnsKICAgICJmb3JtYXR0ZWQiOiJNcy4gQmFyYmFyYSBKIEplbnNlbiBJSUkiLAogICAgImZh bWlseU5hbWUiOiJKZW5zZW4iLAogICAgImdpdmVuTmFtZSI6IkJhcmJhcmEiCiAgfSwKICAidXNl ck5hbWUiOiJiamVuc2VuIgp9CgozLjIuICBSZXRyaWV2aW5nIFJlc291cmNlcwoKICAgVXNlcnMg YW5kIEdyb3VwIFJlc291cmNlcyBhcmUgcmV0cmlldmVkIHZpYSBvcGFxdWUsIHVuaXF1ZSBVUkxz IG9yCiAgIHZpYSBRdWVyeS4gIFNlcnZpY2UgUHJvdmlkZXJzIE1BWSBjaG9vc2UgdG8gcmVzcG9u ZCB3aXRoIGEgc3ViLXNldCBvZgogICBSZXNvdXJjZSBhdHRyaWJ1dGVzLCB0aG91Z2ggTVVTVCBt aW5pbWFsbHkgcmV0dXJuIHRoZSBSZXNvdXJjZSBpZCBhbmQKICAgbWV0YSBhdHRyaWJ1dGVzLgoK My4yLjEuICBSZXRyaWV2aW5nIGEga25vd24gUmVzb3VyY2UKCiAgIFRvIHJldHJpZXZlIGEga25v d24gUmVzb3VyY2UsIGNsaWVudHMgc2VuZCBHRVQgcmVxdWVzdHMgdG8gdGhlCiAgIFJlc291cmNl IGVuZHBvaW50OyBlLmcuLCAvVXNlcnMve2lkfSBvciAvR3JvdXBzL3tpZH0uCgogICBJZiB0aGUg UmVzb3VyY2UgZXhpc3RzIHRoZSBzZXJ2ZXIgcmVzcG9uZHMgd2l0aCBhIHN0YXR1cyBjb2RlIG9m IDIwMAogICBhbmQgaW5jbHVkZXMgdGhlIHJlc3VsdCBpbiB0aGUgYm9keSBvZiB0aGUgcmVzcG9u c2UuCgogICBUaGUgYmVsb3cgZXhhbXBsZSByZXRyaWV2ZXMgYSBzaW5nbGUgVXNlciB2aWEgdGhl IC9Vc2VycyBlbmRwb2ludC4KCgoKICAgR0VUIC9Vc2Vycy8yODE5YzIyMy03Zjc2LTQ1M2EtOTE5 ZC00MTM4NjE5MDQ2NDYKICAgSG9zdDogZXhhbXBsZS5jb20KICAgQWNjZXB0OiBhcHBsaWNhdGlv bi9qc29uCiAgIEF1dGhvcml6YXRpb246IEJlYXJlciBoNDgwZGpzOTNoZDgKCgoKCgpEcmFrZSwg ZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICAg W1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgZHJhZnQtc2NpbS1hcGktMDEg ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgogICBUaGUgc2VydmVyIHJlc3BvbmRzIHdpdGg6 CgoKCkhUVFAvMS4xIDIwMCBPSwpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb24KTG9jYXRp b246IGh0dHBzOi8vZXhhbXBsZS5jb20vdjEvVXNlcnMvMjgxOWMyMjMtN2Y3Ni00NTNhLTkxOWQt NDEzODYxOTA0NjQ2CkVUYWc6IFcvImYyNTBkZDg0ZjA2NzFjMyIKCnsKICAic2NoZW1hcyI6WyJ1 cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4wIl0sCiAgImlkIjoiMjgxOWMyMjMtN2Y3Ni00NTNhLTkx OWQtNDEzODYxOTA0NjQ2LAogICJleHRlcm5hbElkIjoiYmplbnNlbiIsCiAgIm1ldGEiOnsKICAg ICJjcmVhdGVkIjoiMjAxMS0wOC0wMVQxODoyOTo0OS43OTNaIiwKICAgICJsYXN0TW9kaWZpZWQi OiIyMDExLTA4LTAxVDE4OjI5OjQ5Ljc5M1oiLAogICAgImxvY2F0aW9uIjoiaHR0cHM6Ly9leGFt cGxlLmNvbS92MS9Vc2Vycy8yODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5MDQ2NDYiLAog ICAgInZlcnNpb24iOiJXXC9cImYyNTBkZDg0ZjA2NzFjM1wiIgogIH0sCiAgIm5hbWUiOnsKICAg ICJmb3JtYXR0ZWQiOiJNcy4gQmFyYmFyYSBKIEplbnNlbiBJSUkiLAogICAgImZhbWlseU5hbWUi OiJKZW5zZW4iLAogICAgImdpdmVuTmFtZSI6IkJhcmJhcmEiCiAgfSwKICAidXNlck5hbWUiOiJi amVuc2VuIiwKICAicGhvbmVOdW1iZXJzIjpbCiAgICB7CiAgICAgICJ2YWx1ZSI6IjU1NS01NTUt ODM3NyIsCiAgICAgICJ0eXBlIjoid29yayIKICAgIH0KICBdLAogICJlbWFpbHMiOlsKICAgIHsK ICAgICAgInZhbHVlIjoiYmplbnNlbkBleGFtcGxlLmNvbSIsCiAgICAgICJ0eXBlIjoid29yayIK ICAgIH0KICBdCn0KCjMuMi4yLiAgTGlzdC9RdWVyeSBSZXNvdXJjZXMKCiAgIFNDSU0gZGVmaW5l cyBhIHN0YW5kYXJkIHNldCBvZiBvcGVyYXRpb25zIHRoYXQgY2FuIGJlIHVzZWQgdG8gZmlsdGVy LAogICBzb3J0LCBhbmQgcGFnaW5hdGUgcmVzcG9uc2UgcmVzdWx0cy4gIFRoZSBvcGVyYXRpb25z IGFyZSBzcGVjaWZpZWQgYnkKICAgYWRkaW5nIHF1ZXJ5IHBhcmFtZXRlcnMgdG8gdGhlIFJlc291 cmNlJ3MgZW5kcG9pbnQuICBTZXJ2aWNlCiAgIFByb3ZpZGVycyBNQVkgc3VwcG9ydCBhZGRpdGlv bmFsIHF1ZXJ5IHBhcmFtZXRlcnMgbm90IHNwZWNpZmllZCBoZXJlLAogICBhbmQgUHJvdmlkZXJz IFNIT1VMRCBpZ25vcmUgYW55IHF1ZXJ5IHBhcmFtZXRlcnMgdGhleSBkb24ndAogICByZWNvZ25p emUuCgoKCgpEcmFrZSwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA1LCAyMDEzICAg ICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgZHJh ZnQtc2NpbS1hcGktMDEgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgogICBUaGUgYmVsb3cg ZXhhbXBsZSByZXR1cm5zIHRoZSB1c2VyTmFtZSBmb3IgYWxsIFVzZXJzOgoKCiAgIEdFVCAvVXNl cnM/YXR0cmlidXRlcz11c2VyTmFtZQogICBIb3N0OiBleGFtcGxlLmNvbQogICBBY2NlcHQ6IGFw cGxpY2F0aW9uL2pzb24KICAgQXV0aG9yaXphdGlvbjogQmVhcmVyIGg0ODBkanM5M2hkOAoKCgog ICBIVFRQLzEuMSAyMDAgT0sKICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uCgogICB7 CiAgICAgInRvdGFsUmVzdWx0cyI6MiwKICAgICAic2NoZW1hcyI6WyJ1cm46c2NpbTpzY2hlbWFz OmNvcmU6MS4wIl0sCiAgICAgIlJlc291cmNlcyI6WwogICAgICAgewogICAgICAgICAidXNlck5h bWUiOiJiamVuc2VuIgogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgInVzZXJOYW1lIjoianNt aXRoIgogICAgICAgfQogICAgIF0KICAgfQoKMy4yLjIuMS4gIEZpbHRlcmluZwoKICAgRmlsdGVy aW5nIGlzIE9QVElPTkFMLiAgQ29uc3VtZXJzIG1heSByZXF1ZXN0IGEgc3Vic2V0IG9mIFJlc291 cmNlcwogICBieSBzcGVjaWZ5aW5nIHRoZSAnZmlsdGVyJyBVUkwgcXVlcnkgcGFyYW1ldGVyIGNv bnRhaW5pbmcgYSBmaWx0ZXIKICAgZXhwcmVzc2lvbi4gIFdoZW4gc3BlY2lmaWVkIG9ubHkgdGhv c2UgUmVzb3VyY2VzIG1hdGNoaW5nIHRoZSBmaWx0ZXIKICAgZXhwcmVzc2lvbiBTSEFMTCBiZSBy ZXR1cm5lZC4gIFRoZSBleHByZXNzaW9uIGxhbmd1YWdlIHRoYXQgaXMgdXNlZAogICBpbiB0aGUg ZmlsdGVyIHBhcmFtZXRlciBzdXBwb3J0cyByZWZlcmVuY2VzIHRvIGF0dHJpYnV0ZXMgYW5kCiAg IGxpdGVyYWxzLiAgVGhlIGxpdGVyYWwgdmFsdWVzIGNhbiBiZSBzdHJpbmdzIGVuY2xvc2VkIGlu IGRvdWJsZQogICBxdW90ZXMsIG51bWJlcnMsIGRhdGUgdGltZXMgZW5jbG9zZWQgaW4gZG91Ymxl IHF1b3RlcywgYW5kIEJvb2xlYW4KICAgdmFsdWVzOyBpLmUuLCB0cnVlIG9yIGZhbHNlLiAgU3Ry aW5nIGxpdGVyYWxzIE1VU1QgYmUgdmFsaWQgSlNPTgogICBzdHJpbmdzIFsyXS4KCiAgIFRoZSBh dHRyaWJ1dGUgbmFtZSBhbmQgYXR0cmlidXRlIG9wZXJhdG9yIGFyZSBjYXNlIGluc2Vuc2l0aXZl LiAgRm9yCiAgIGV4YW1wbGUsIHRoZSBmb2xsb3dpbmcgdHdvIGV4cHJlc3Npb25zIHdpbGwgZXZh bHVhdGUgdG8gdGhlIHNhbWUKICAgbG9naWNhbCB2YWx1ZToKCiAgIGZpbHRlcj11c2VyTmFtZSBF cSAiam9obiIKCiAgIGZpbHRlcj1Vc2VybmFtZSBlcSAiam9obiIKCiAgIFRoZSBmaWx0ZXIgcGFy YW1ldGVyIE1VU1QgY29udGFpbiBhdCBsZWFzdCBvbmUgdmFsaWQgQm9vbGVhbgogICBleHByZXNz aW9uLiAgRWFjaCBleHByZXNzaW9uIE1VU1QgY29udGFpbiBhbiBhdHRyaWJ1dGUgbmFtZSBmb2xs b3dlZAoKCgpEcmFrZSwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA1LCAyMDEzICAg ICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgZHJh ZnQtc2NpbS1hcGktMDEgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgogICBieSBhbiBhdHRy aWJ1dGUgb3BlcmF0b3IgYW5kIG9wdGlvbmFsIHZhbHVlLiAgTXVsdGlwbGUgZXhwcmVzc2lvbnMK ICAgTUFZIGJlIGNvbWJpbmVkIHVzaW5nIHRoZSB0d28gbG9naWNhbCBvcGVyYXRvcnMuICBGdXJ0 aGVybW9yZQogICBleHByZXNzaW9ucyBjYW4gYmUgZ3JvdXBlZCB0b2dldGhlciB1c2luZyAiKCki LgoKICAgVGhlIG9wZXJhdG9ycyBzdXBwb3J0ZWQgaW4gdGhlIGV4cHJlc3Npb24gYXJlIGxpc3Rl ZCBpbiB0aGUgZm9sbG93aW5nCiAgIHRhYmxlLgoKICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgT3BlcmF0 b3IgfCBEZXNjcmlwdGlvbiB8IEJlaGF2aW9yICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICArLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgfCBlcSAgICAgICB8IGVxdWFsICAgICAgIHwgVGhlIGF0 dHJpYnV0ZSBhbmQgb3BlcmF0b3IgdmFsdWVzIG11c3QgICB8CiAgIHwgICAgICAgICAgfCAgICAg ICAgICAgICB8IGJlIGlkZW50aWNhbCBmb3IgYSBtYXRjaC4gICAgICAgICAgICAgICAgfAogICB8 IGNvICAgICAgIHwgY29udGFpbnMgICAgfCBUaGUgZW50aXJlIG9wZXJhdG9yIHZhbHVlIG11c3Qg YmUgYSAgICAgIHwKICAgfCAgICAgICAgICB8ICAgICAgICAgICAgIHwgc3Vic3RyaW5nIG9mIHRo ZSBhdHRyaWJ1dGUgdmFsdWUgZm9yIGEgICB8CiAgIHwgICAgICAgICAgfCAgICAgICAgICAgICB8 IG1hdGNoLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IHN3ICAgICAg IHwgc3RhcnRzIHdpdGggfCBUaGUgZW50aXJlIG9wZXJhdG9yIHZhbHVlIG11c3QgYmUgYSAgICAg IHwKICAgfCAgICAgICAgICB8ICAgICAgICAgICAgIHwgc3Vic3RyaW5nIG9mIHRoZSBhdHRyaWJ1 dGUgdmFsdWUsICAgICAgICB8CiAgIHwgICAgICAgICAgfCAgICAgICAgICAgICB8IHN0YXJ0aW5n IGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlICAgICAgICAgfAogICB8ICAgICAgICAgIHwgICAgICAg ICAgICAgfCBhdHRyaWJ1dGUgdmFsdWUuICBUaGlzIGNyaXRlcmlvbiBpcyAgICAgIHwKICAgfCAg ICAgICAgICB8ICAgICAgICAgICAgIHwgc2F0aXNmaWVkIGlmIHRoZSB0d28gc3RyaW5ncyBhcmUg ICAgICAgICB8CiAgIHwgICAgICAgICAgfCAgICAgICAgICAgICB8IGlkZW50aWNhbC4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IHByICAgICAgIHwgcHJlc2VudCAgICAgfCBJ ZiB0aGUgYXR0cmlidXRlIGhhcyBhIG5vbi1lbXB0eSB2YWx1ZSwgIHwKICAgfCAgICAgICAgICB8 IChoYXMgdmFsdWUpIHwgb3IgaWYgaXQgY29udGFpbnMgYSBub24tZW1wdHkgbm9kZSBmb3IgICB8 CiAgIHwgICAgICAgICAgfCAgICAgICAgICAgICB8IGNvbXBsZXggYXR0cmlidXRlcyB0aGVyZSBp cyBhIG1hdGNoLiAgICAgfAogICB8IGd0ICAgICAgIHwgZ3JlYXRlciAgICAgfCBJZiB0aGUgYXR0 cmlidXRlIHZhbHVlIGlzIGdyZWF0ZXIgdGhhbiAgIHwKICAgfCAgICAgICAgICB8IHRoYW4gICAg ICAgIHwgb3BlcmF0b3IgdmFsdWUsIHRoZXJlIGlzIGEgbWF0Y2guICBUaGUgICB8CiAgIHwgICAg ICAgICAgfCAgICAgICAgICAgICB8IGFjdHVhbCBjb21wYXJpc29uIGlzIGRlcGVuZGVudCBvbiB0 aGUgICAgfAogICB8ICAgICAgICAgIHwgICAgICAgICAgICAgfCBhdHRyaWJ1dGUgdHlwZS4gIEZv ciBzdHJpbmcgYXR0cmlidXRlICAgIHwKICAgfCAgICAgICAgICB8ICAgICAgICAgICAgIHwgdHlw ZXMsIHRoaXMgaXMgYSBsZXhpY29ncmFwaGljYWwgICAgICAgICB8CiAgIHwgICAgICAgICAgfCAg ICAgICAgICAgICB8IGNvbXBhcmlzb24gYW5kIGZvciBEYXRlVGltZSB0eXBlcywgaXQgaXMgfAog ICB8ICAgICAgICAgIHwgICAgICAgICAgICAgfCBhIGNocm9ub2xvZ2ljYWwgY29tcGFyaXNvbi4g ICAgICAgICAgICAgIHwKICAgfCBnZSAgICAgICB8IGdyZWF0ZXIgICAgIHwgSWYgdGhlIGF0dHJp YnV0ZSB2YWx1ZSBpcyBncmVhdGVyIHRoYW4gICB8CiAgIHwgICAgICAgICAgfCB0aGFuIG9yICAg ICB8IG9yIGVxdWFsIHRvIHRoZSBvcGVyYXRvciB2YWx1ZSwgdGhlcmUgaXMgfAogICB8ICAgICAg ICAgIHwgZXF1YWwgICAgICAgfCBhIG1hdGNoLiAgVGhlIGFjdHVhbCBjb21wYXJpc29uIGlzICAg ICAgIHwKICAgfCAgICAgICAgICB8ICAgICAgICAgICAgIHwgZGVwZW5kZW50IG9uIHRoZSBhdHRy aWJ1dGUgdHlwZS4gIEZvciAgICB8CiAgIHwgICAgICAgICAgfCAgICAgICAgICAgICB8IHN0cmlu ZyBhdHRyaWJ1dGUgdHlwZXMsIHRoaXMgaXMgYSAgICAgICAgfAogICB8ICAgICAgICAgIHwgICAg ICAgICAgICAgfCBsZXhpY29ncmFwaGljYWwgY29tcGFyaXNvbiBhbmQgZm9yICAgICAgIHwKICAg fCAgICAgICAgICB8ICAgICAgICAgICAgIHwgRGF0ZVRpbWUgdHlwZXMsIGl0IGlzIGEgY2hyb25v bG9naWNhbCAgICB8CiAgIHwgICAgICAgICAgfCAgICAgICAgICAgICB8IGNvbXBhcmlzb24uICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IGx0ICAgICAgIHwgbGVzcyB0aGFuICAg fCBJZiB0aGUgYXR0cmlidXRlIHZhbHVlIGlzIGxlc3MgdGhhbiAgICAgIHwKICAgfCAgICAgICAg ICB8ICAgICAgICAgICAgIHwgb3BlcmF0b3IgdmFsdWUsIHRoZXJlIGlzIGEgbWF0Y2guICBUaGUg ICB8CiAgIHwgICAgICAgICAgfCAgICAgICAgICAgICB8IGFjdHVhbCBjb21wYXJpc29uIGlzIGRl cGVuZGVudCBvbiB0aGUgICAgfAogICB8ICAgICAgICAgIHwgICAgICAgICAgICAgfCBhdHRyaWJ1 dGUgdHlwZS4gIEZvciBzdHJpbmcgYXR0cmlidXRlICAgIHwKICAgfCAgICAgICAgICB8ICAgICAg ICAgICAgIHwgdHlwZXMsIHRoaXMgaXMgYSBsZXhpY29ncmFwaGljYWwgICAgICAgICB8CiAgIHwg ICAgICAgICAgfCAgICAgICAgICAgICB8IGNvbXBhcmlzb24gYW5kIGZvciBEYXRlVGltZSB0eXBl cywgaXQgaXMgfAogICB8ICAgICAgICAgIHwgICAgICAgICAgICAgfCBhIGNocm9ub2xvZ2ljYWwg Y29tcGFyaXNvbi4gICAgICAgICAgICAgIHwKCgoKCgpEcmFrZSwgZXQgYWwuICAgICAgICAgICAg ICBFeHBpcmVzIE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgZHJhZnQtc2NpbS1hcGktMDEgICAgICAgICAgICAgIE5vdmVt YmVyIDIwMTIKCgogICB8IGxlICAgICAgIHwgbGVzcyB0aGFuICAgfCBJZiB0aGUgYXR0cmlidXRl IHZhbHVlIGlzIGxlc3MgdGhhbiBvciAgIHwKICAgfCAgICAgICAgICB8IG9yIGVxdWFsICAgIHwg ZXF1YWwgdG8gdGhlIG9wZXJhdG9yIHZhbHVlLCB0aGVyZSBpcyBhICB8CiAgIHwgICAgICAgICAg fCAgICAgICAgICAgICB8IG1hdGNoLiAgVGhlIGFjdHVhbCBjb21wYXJpc29uIGlzICAgICAgICAg fAogICB8ICAgICAgICAgIHwgICAgICAgICAgICAgfCBkZXBlbmRlbnQgb24gdGhlIGF0dHJpYnV0 ZSB0eXBlLiAgRm9yICAgIHwKICAgfCAgICAgICAgICB8ICAgICAgICAgICAgIHwgc3RyaW5nIGF0 dHJpYnV0ZSB0eXBlcywgdGhpcyBpcyBhICAgICAgICB8CiAgIHwgICAgICAgICAgfCAgICAgICAg ICAgICB8IGxleGljb2dyYXBoaWNhbCBjb21wYXJpc29uIGFuZCBmb3IgICAgICAgfAogICB8ICAg ICAgICAgIHwgICAgICAgICAgICAgfCBEYXRlVGltZSB0eXBlcywgaXQgaXMgYSBjaHJvbm9sb2dp Y2FsICAgIHwKICAgfCAgICAgICAgICB8ICAgICAgICAgICAgIHwgY29tcGFyaXNvbi4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgICAgICAgICAgICAg ICAgICAgICBUYWJsZSAyOiBBdHRyaWJ1dGUgT3BlcmF0b3JzCgogICArLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAg fCBPcGVyYXRvciB8IERlc2NyaXB0aW9uIHwgQmVoYXZpb3IgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8IGFuZCAgICAgIHwgTG9naWNhbCBBbmQg fCBUaGUgZmlsdGVyIGlzIG9ubHkgYSBtYXRjaCBpZiBib3RoICAgICAgIHwKICAgfCAgICAgICAg ICB8ICAgICAgICAgICAgIHwgZXhwcmVzc2lvbnMgZXZhbHVhdGUgdG8gdHJ1ZS4gICAgICAgICAg ICB8CiAgIHwgb3IgICAgICAgfCBMb2dpY2FsIG9yICB8IFRoZSBmaWx0ZXIgaXMgYSBtYXRjaCBp ZiBlaXRoZXIgICAgICAgICAgfAogICB8ICAgICAgICAgIHwgICAgICAgICAgICAgfCBleHByZXNz aW9uIGV2YWx1YXRlcyB0byB0cnVlLiAgICAgICAgICAgIHwKICAgKy0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICAg ICAgICAgICAgICAgICAgICAgICBUYWJsZSAzOiBMb2dpY2FsIE9wZXJhdG9ycwoKICAgKy0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rCiAgIHwgT3BlcmF0b3IgfCBEZXNjcmlwdGlvbiB8IEJlaGF2aW9yICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfAogICArLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgfCAoKSAgICAgICB8IFBy ZWNlZGVuY2UgIHwgQm9vbGVhbiBleHByZXNzaW9ucyBtYXkgYmUgZ3JvdXBlZCB1c2luZyB8CiAg IHwgICAgICAgICAgfCBncm91cGluZyAgICB8IHBhcmVudGhlc2VzIHRvIGNoYW5nZSB0aGUgc3Rh bmRhcmQgb3JkZXIgfAogICB8ICAgICAgICAgIHwgICAgICAgICAgICAgfCBvZiBvcGVyYXRpb25z OyBpLmUuLCBldmFsdWF0ZSBPUiBsb2dpY2FsIHwKICAgfCAgICAgICAgICB8ICAgICAgICAgICAg IHwgb3BlcmF0b3JzIGJlZm9yZSBsb2dpY2FsIEFORCBvcGVyYXRvcnMuICB8CiAgICstLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKwoKICAgICAgICAgICAgICAgICAgICAgICAgVGFibGUgNDogR3JvdXBpbmcgT3BlcmF0b3Jz CgogICBGaWx0ZXJzIE1VU1QgYmUgZXZhbHVhdGVkIHVzaW5nIHN0YW5kYXJkIG9yZGVyIG9mIG9w ZXJhdGlvbnMuCiAgIEF0dHJpYnV0ZSBvcGVyYXRvcnMgaGF2ZSB0aGUgaGlnaGVzdCBwcmVjZWRl bmNlLCBmb2xsb3dlZCBieSB0aGUKICAgZ3JvdXBpbmcgb3BlcmF0b3IgKGkuZSwgcGFyZW50aGVz ZXMpLCBmb2xsb3dlZCBieSB0aGUgbG9naWNhbCBBTkQKICAgb3BlcmF0b3IsIGZvbGxvd2VkIGJ5 IHRoZSBsb2dpY2FsIE9SIG9wZXJhdG9yLgoKICAgSWYgdGhlIHNwZWNpZmllZCBhdHRyaWJ1dGUg aW4gYSBmaWx0ZXIgZXhwcmVzc2lvbiBpcyBhIG11bHRpLXZhbHVlZAogICBhdHRyaWJ1dGUsIHRo ZSBSZXNvdXJjZSBNVVNUIG1hdGNoIGlmIGFueSBvZiB0aGUgaW5zdGFuY2VzIG9mIHRoZQogICBn aXZlbiBhdHRyaWJ1dGUgbWF0Y2ggdGhlIHNwZWNpZmllZCBjcml0ZXJpb247IGUuZy4gaWYgYSBV c2VyIGhhcwogICBtdWx0aXBsZSBlbWFpbHMgdmFsdWVzLCBvbmx5IG9uZSBoYXMgdG8gbWF0Y2gg Zm9yIHRoZSBlbnRpcmUgVXNlciB0bwogICBtYXRjaC4gIEZvciBjb21wbGV4IGF0dHJpYnV0ZXMs IGEgZnVsbHkgcXVhbGlmaWVkIFN1Yi1BdHRyaWJ1dGUgTVVTVAogICBiZSBzcGVjaWZpZWQgdXNp bmcgc3RhbmRhcmQgYXR0cmlidXRlIG5vdGF0aW9uIChTZWN0aW9uIDMuOCkuICBGb3IKICAgZXhh bXBsZSwgdG8gZmlsdGVyIGJ5IHVzZXJOYW1lIHRoZSBwYXJhbWV0ZXIgdmFsdWUgaXMgdXNlck5h bWUgYW5kIHRvCiAgIGZpbHRlciBieSBmaXJzdCBuYW1lLCB0aGUgcGFyYW1ldGVyIHZhbHVlIGlz IG5hbWUuZ2l2ZW5OYW1lLgoKCgoKRHJha2UsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBN YXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGRyYWZ0LXNjaW0tYXBpLTAxICAgICAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoK ICAgUHJvdmlkZXJzIE1BWSBzdXBwb3J0IGFkZGl0aW9uYWwgZmlsdGVyIG9wZXJhdGlvbnMgaWYg dGhleSBjaG9vc2UuCiAgIFByb3ZpZGVycyBNVVNUIGRlY2xpbmUgdG8gZmlsdGVyIHJlc3VsdHMg aWYgdGhlIHNwZWNpZmllZCBmaWx0ZXIKICAgb3BlcmF0aW9uIGlzIG5vdCByZWNvZ25pemVkIGFu ZCByZXR1cm4gYSBIVFRQIDQwMCBlcnJvciB3aXRoIGFuCiAgIGFwcHJvcHJpYXRlIGh1bWFuIHJl YWRhYmxlIHJlc3BvbnNlLiAgRm9yIGV4YW1wbGUsIGlmIGEgQ29uc3VtZXIKICAgc3BlY2lmaWVk IGFuIHVuc3VwcG9ydGVkIG9wZXJhdG9yIG5hbWVkICdyZWdleCcgdGhlIFNlcnZpY2UgUHJvdmlk ZXIKICAgc2hvdWxkIHNwZWNpZnkgYW4gZXJyb3IgcmVzcG9uc2UgZGVzY3JpcHRpb24gaWRlbnRp ZnlpbmcgdGhlIENvbnN1bWVyCiAgIGVycm9yOyBlLmcuLCAnVGhlIG9wZXJhdG9yICdyZWdleCcg aXMgbm90IHN1cHBvcnRlZC4nCgogICBTdHJpbmcgdHlwZSBhdHRyaWJ1dGVzIGFyZSBjYXNlIGlu c2Vuc2l0aXZlIGJ5IGRlZmF1bHQgdW5sZXNzIHRoZQogICBhdHRyaWJ1dGUgdHlwZSBpcyBkZWZp bmVkIGFzIGEgY2FzZUV4YWN0IHN0cmluZy4gIEF0dHJpYnV0ZSBvcGVyYXRvcnMKICAgJ2VxJywg J2NvJywgYW5kICdzdycgTVVTVCBwZXJmb3JtIGNhc2VJZ25vcmUgbWF0Y2hpbmcgZm9yIGFsbCBz dHJpbmcKICAgYXR0cmlidXRlcyB1bmxlc3MgdGhlIGF0dHJpYnV0ZSBpcyBkZWZpbmVkIGFzIGNh c2VFeGFjdC4gIEJ5IGRlZmF1bHQKICAgYWxsIHN0cmluZyBhdHRyaWJ1dGVzIGFyZSBjYXNlSWdu b3JlLgoKICAgRXhhbXBsZXM6CgoKICAgZmlsdGVyPXVzZXJOYW1lIGVxICJiamVuc2VuIgoKICAg ZmlsdGVyPW5hbWUuZmFtaWx5TmFtZSBjbyAiTydNYWxsZXkiCgogICBmaWx0ZXI9dXNlck5hbWUg c3cgIkoiCgogICBmaWx0ZXI9dGl0bGUgcHIKCiAgIGZpbHRlcj1tZXRhLmxhc3RNb2RpZmllZCBn dCAiMjAxMS0wNS0xM1QwNDo0MjozNFoiCgogICBmaWx0ZXI9bWV0YS5sYXN0TW9kaWZpZWQgZ2Ug IjIwMTEtMDUtMTNUMDQ6NDI6MzRaIgoKICAgZmlsdGVyPW1ldGEubGFzdE1vZGlmaWVkIGx0ICIy MDExLTA1LTEzVDA0OjQyOjM0WiIKCiAgIGZpbHRlcj1tZXRhLmxhc3RNb2RpZmllZCBsZSAiMjAx MS0wNS0xM1QwNDo0MjozNFoiCgogICBmaWx0ZXI9dGl0bGUgcHIgYW5kIHVzZXJUeXBlIGVxICJF bXBsb3llZSIKCiAgIGZpbHRlcj10aXRsZSBwciBvciB1c2VyVHlwZSBlcSAiSW50ZXJuIgoKICAg ZmlsdGVyPXVzZXJUeXBlIGVxICJFbXBsb3llZSIgYW5kIChlbWFpbHMgY28gImV4YW1wbGUuY29t IiBvciBlbWFpbHMKICAgY28gImV4YW1wbGUub3JnIikKCjMuMi4yLjIuICBTb3J0aW5nCgogICBT b3J0IGlzIE9QVElPTkFMLiAgU29ydGluZyBhbGxvd3MgQ29uc3VtZXJzIHRvIHNwZWNpZnkgdGhl IG9yZGVyIGluCiAgIHdoaWNoIFJlc291cmNlcyBhcmUgcmV0dXJuZWQgYnkgc3BlY2lmeWluZyBh IGNvbWJpbmF0aW9uIG9mIHNvcnRCeQogICBhbmQgc29ydE9yZGVyIFVSTCBwYXJhbWV0ZXJzLgoK CgoKCgpEcmFrZSwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA1LCAyMDEzICAgICAg ICAgICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgZHJhZnQt c2NpbS1hcGktMDEgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgogICBzb3J0Qnk6ICBUaGUg c29ydEJ5IHBhcmFtZXRlciBzcGVjaWZpZXMgdGhlIGF0dHJpYnV0ZSB3aG9zZSB2YWx1ZQogICAg ICBTSEFMTCBiZSB1c2VkIHRvIG9yZGVyIHRoZSByZXR1cm5lZCByZXNwb25zZXMuICBJZiB0aGUg c29ydEJ5CiAgICAgIGF0dHJpYnV0ZSBjb3JyZXNwb25kcyB0byBhIFNpbmd1bGFyIEF0dHJpYnV0 ZSwgUmVzb3VyY2VzIGFyZQogICAgICBzb3J0ZWQgYWNjb3JkaW5nIHRvIHRoYXQgYXR0cmlidXRl J3MgdmFsdWU7IGlmIGl0J3MgYSBNdWx0aS12YWx1ZWQKICAgICAgQXR0cmlidXRlLCBSZXNvdXJj ZXMgYXJlIHNvcnRlZCBieSB0aGUgdmFsdWUgb2YgdGhlIHByaW1hcnkKICAgICAgYXR0cmlidXRl LCBpZiBhbnksIG9yIGVsc2UgdGhlIGZpcnN0IHZhbHVlIGluIHRoZSBsaXN0LCBpZiBhbnkuCiAg ICAgIElmIHRoZSBhdHRyaWJ1dGUgaXMgY29tcGxleCB0aGUgYXR0cmlidXRlIG5hbWUgbXVzdCBi ZSBhIHBhdGggdG8gYQogICAgICBTdWItQXR0cmlidXRlIGluIHN0YW5kYXJkIGF0dHJpYnV0ZSBu b3RhdGlvbiAoU2VjdGlvbiAzLjgpIDsgZS5nLiwKICAgICAgc29ydEJ5PW5hbWUuZ2l2ZW5OYW1l LiAgRm9yIGFsbCBhdHRyaWJ1dGUgdHlwZXMsIGlmIHRoZXJlIGlzIG5vCiAgICAgIGRhdGEgZm9y IHRoZSBzcGVjaWZpZWQgc29ydEJ5IHZhbHVlIHRoZXkgYXJlIHNvcnRlZCB2aWEgdGhlCiAgICAg ICdzb3J0T3JkZXInIHBhcmFtZXRlcjsgaS5lLiwgdGhleSBhcmUgb3JkZXJlZCBsYXN0IGlmIGFz Y2VuZGluZwogICAgICBhbmQgZmlyc3QgaWYgZGVzY2VuZGluZy4KCiAgIHNvcnRPcmRlcjogIFRo ZSBvcmRlciBpbiB3aGljaCB0aGUgc29ydEJ5IHBhcmFtZXRlciBpcyBhcHBsaWVkLgogICAgICBB bGxvd2VkIHZhbHVlcyBhcmUgImFzY2VuZGluZyIgYW5kICJkZXNjZW5kaW5nIi4gIElmIGEgdmFs dWUgZm9yCiAgICAgIHNvcnRCeSBpcyBwcm92aWRlZCBhbmQgbm8gc29ydE9yZGVyIGlzIHNwZWNp ZmllZCwgdGhlIHNvcnRPcmRlcgogICAgICBTSEFMTCBkZWZhdWx0IHRvIGFzY2VuZGluZy4gIFN0 cmluZyB0eXBlIGF0dHJpYnV0ZXMgYXJlIGNhc2UKICAgICAgaW5zZW5zaXRpdmUgYnkgZGVmYXVs dCB1bmxlc3MgdGhlIGF0dHJpYnV0ZSB0eXBlIGlzIGRlZmluZWQgYXMgYQogICAgICBjYXNlRXhh Y3Qgc3RyaW5nLiBzb3J0T3JkZXIgTVVTVCBzb3J0IGFjY29yZGluZyB0byB0aGUgYXR0cmlidXRl CiAgICAgIHR5cGU7IGkuZS4sIGZvciBjYXNlSWdub3JlIGF0dHJpYnV0ZXMsIHNvcnQgdGhlIHJl c3VsdCB1c2luZyBjYXNlCiAgICAgIGluc2Vuc2l0aXZlLCBVbmljb2RlIGFscGhhYmV0aWMgc29y dCBvcmRlciwgd2l0aCBubyBzcGVjaWZpYwogICAgICBsb2NhbGUgaW1wbGllZCBhbmQgZm9yIGNh c2VFeGFjdCBhdHRyaWJ1dGUgdHlwZXMsIHNvcnQgdGhlIHJlc3VsdAogICAgICB1c2luZyBjYXNl IHNlbnNpdGl2ZSwgVW5pY29kZSBhbHBoYWJldGljIHNvcnQgb3JkZXIuCgozLjIuMi4zLiAgUGFn aW5hdGlvbgoKICAgUGFnaW5hdGlvbiBwYXJhbWV0ZXJzIGNhbiBiZSB1c2VkIHRvZ2V0aGVyIHRv ICJwYWdlIHRocm91Z2giIGxhcmdlCiAgIG51bWJlcnMgb2YgUmVzb3VyY2VzIHNvIGFzIG5vdCB0 byBvdmVyd2hlbG0gdGhlIENvbnN1bWVyIG9yIFNlcnZpY2UKICAgUHJvdmlkZXIuICBQYWdpbmF0 aW9uIGlzIG5vdCBzZXNzaW9uIGJhc2VkIGhlbmNlIENvbnN1bWVycyBTSE9VTEQKICAgbmV2ZXIg YXNzdW1lIHJlcGVhdGFibGUgcmVzdWx0cy4gIEZvciBleGFtcGxlLCBhIHJlcXVlc3QgZm9yIGEg bGlzdAogICBvZiAxMCBSZXNvdXJjZXMgYmVnaW5uaW5nIHdpdGggYSBzdGFydEluZGV4IG9mIDEg bWF5IHJldHVybiBkaWZmZXJlbnQKICAgcmVzdWx0cyB3aGVuIHJlcGVhdGVkIGFzIGEgUmVzb3Vy Y2UgaW4gdGhlIG9yaWdpbmFsIHJlc3VsdCBjb3VsZCBiZQogICBkZWxldGVkIG9yIG5ldyBvbmVz IGNvdWxkIGJlIGFkZGVkIGluLWJldHdlZW4gcmVxdWVzdHMuICBQYWdpbmF0aW9uCiAgIHBhcmFt ZXRlcnMgYW5kIGdlbmVyYWwgYmVoYXZpb3IgYXJlIGRlcml2ZWQgZnJvbSB0aGUgT3BlblNlYXJj aAogICBQcm90b2NvbCBbM10uCgogICBUaGUgZm9sbG93aW5nIHRhYmxlIGRlc2NyaWJlcyB0aGUg VVJMIHBhZ2luYXRpb24gcGFyYW1ldGVycy4KCiAgICstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8IFBhcmFtZXRl ciAgfCBEZXNjcmlwdGlvbiAgICAgICB8IERlZmF1bHQgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgc3RhcnRJbmRleCB8IFRoZSAxLWJhc2VkIGluZGV4IHwg MSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgfCBvZiB0 aGUgZmlyc3QgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAg ICAgICAgICAgIHwgc2VhcmNoIHJlc3VsdC4gICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CgoKCgoKCgpEcmFrZSwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA1 LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgZHJhZnQtc2NpbS1hcGktMDEgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgogICB8 IGNvdW50ICAgICAgfCBOb24tbmVnYXRpdmUgICAgICB8IE5vbmUuICBXaGVuIHNwZWNpZmllZCB0 aGUgICAgICAgIHwKICAgfCAgICAgICAgICAgIHwgSW50ZWdlci4gICAgICAgICAgfCBTZXJ2aWNl IFByb3ZpZGVyIE1VU1Qgbm90IHJldHVybiB8CiAgIHwgICAgICAgICAgICB8IFNwZWNpZmllcyB0 aGUgICAgIHwgbW9yZSByZXN1bHRzIHRoYW4gc3BlY2lmaWVkICAgICAgfAogICB8ICAgICAgICAg ICAgfCBkZXNpcmVkIG1heGltdW0gICB8IHRob3VnaCBNQVkgcmV0dXJuIGZld2VyIHJlc3VsdHMu IHwKICAgfCAgICAgICAgICAgIHwgbnVtYmVyIG9mIHNlYXJjaCAgfCBJZiB1bnNwZWNpZmllZCwg dGhlIG1heGltdW0gICAgICB8CiAgIHwgICAgICAgICAgICB8IHJlc3VsdHMgcGVyIHBhZ2U7IHwg bnVtYmVyIG9mIHJlc3VsdHMgaXMgc2V0IGJ5IHRoZSAgfAogICB8ICAgICAgICAgICAgfCBlLmcu LCAxMC4gICAgICAgICB8IFNlcnZpY2UgUHJvdmlkZXIuICAgICAgICAgICAgICAgIHwKICAgKy0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rCgogICAgICAgICAgICAgICAgICBUYWJsZSA1OiBQYWdpbmF0aW9uIFJlcXVlc3Qg cGFyYW1ldGVycwoKICAgVGhlIGZvbGxvd2luZyB0YWJsZSBkZXNjcmliZXMgdGhlIHF1ZXJ5IHJl c3BvbnNlIHBhZ2luYXRpb24KICAgYXR0cmlidXRlcyBzcGVjaWZpZWQgYnkgdGhlIFNlcnZpY2Ug UHJvdmlkZXIuCgogICArLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgfCBFbGVtZW50ICAgICAgfCBEZXNjcmlwdGlv biAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t KwogICB8IGl0ZW1zUGVyUGFnZSB8IE5vbi1uZWdhdGl2ZSBJbnRlZ2VyLiAgU3BlY2lmaWVzIHRo ZSBudW1iZXIgb2YgICAgIHwKICAgfCAgICAgICAgICAgICAgfCBzZWFyY2ggcmVzdWx0cyByZXR1 cm5lZCBpbiBhIHF1ZXJ5IHJlc3BvbnNlIHBhZ2U7ICB8CiAgIHwgICAgICAgICAgICAgIHwgZS5n LiwgMTAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IHRv dGFsUmVzdWx0cyB8IE5vbi1uZWdhdGl2ZSBJbnRlZ2VyLiAgU3BlY2lmaWVzIHRoZSB0b3RhbCBu dW1iZXIgIHwKICAgfCAgICAgICAgICAgICAgfCBvZiByZXN1bHRzIG1hdGNoaW5nIHRoZSBDb25z dW1lciBxdWVyeTsgZS5nLiwgICAgICB8CiAgIHwgICAgICAgICAgICAgIHwgMTAwMC4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IHN0YXJ0SW5kZXgg ICB8IFRoZSAxLWJhc2VkIGluZGV4IG9mIHRoZSBmaXJzdCByZXN1bHQgaW4gdGhlICAgICAgIHwK ICAgfCAgICAgICAgICAgICAgfCBjdXJyZW50IHNldCBvZiBzZWFyY2ggcmVzdWx0czsgZS5nLiwg MS4gICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgICAgICAgICAgICAgICAgIFRhYmxl IDY6IFBhZ2luYXRpb24gUmVzcG9uc2UgRWxlbWVudHMKCiAgIEZvciBleGFtcGxlLCB0byByZXRy aWV2ZSB0aGUgZmlyc3QgMTAgVXNlcnMgc2V0IHRoZSBzdGFydEluZGV4IHRvIDEKICAgYW5kIHRo ZSBjb3VudCB0byAxMC4KCgogICBHRVQgL1VzZXJzP3N0YXJ0SW5kZXg9MSZjb3VudD0xMAogICBI b3N0OiBleGFtcGxlLmNvbQogICBBY2NlcHQ6IGFwcGxpY2F0aW9uL2pzb24KICAgQXV0aG9yaXph dGlvbjogQmVhcmVyIGg0ODBkanM5M2hkOAoKCiAgIHsKICAgICAidG90YWxSZXN1bHRzIjoxMDAs CiAgICAgIml0ZW1zUGVyUGFnZSI6MTAsCiAgICAgInN0YXJ0SW5kZXgiOjEsCiAgICAgInNjaGVt YXMiOlsidXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCJdLAogICAgICJSZXNvdXJjZXMiOlt7CiAg ICAgICAuLi4KICAgICB9XQogICB9CgoKCkRyYWtlLCBldCBhbC4gICAgICAgICAgICAgIEV4cGly ZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAx MgoKCiAgIEdpdmVuIHRoZSBleGFtcGxlIGFib3ZlLCB0byBjb250aW51ZSBwYWdpbmcgc2V0IHRo ZSBzdGFydEluZGV4IHRvIDExCiAgIGFuZCByZS1mZXRjaDsgaS5lLiwgL1VzZXJzP3N0YXJ0SW5k ZXg9MTEmY291bnQ9MTAKCjMuMy4gIE1vZGlmeWluZyBSZXNvdXJjZXMKCiAgIFJlc291cmNlcyBj YW4gYmUgbW9kaWZpZWQgaW4gd2hvbGUgb3IgaW4gcGFydCB2aWEgUFVUIG9yIFBBVENILAogICBy ZXNwZWN0aXZlbHkuICBJbXBsZW1lbnRlcnMgTVVTVCBzdXBwb3J0IFBVVCBhcyBzcGVjaWZpZWQg aW4gUkZDMjYxNgogICAuICBSZXNvdXJjZXMgc3VjaCBhcyBHcm91cHMgbWF5IGJlIHZlcnkgbGFy Z2UgaGVuY2UgaW1wbGVtZW50ZXJzCiAgIFNIT1VMRCBzdXBwb3J0IFBBVENIIFs0XSB0byBlbmFi bGUgcGFydGlhbCByZXNvdXJjZSBtb2RpZmljYXRpb25zLgoKMy4zLjEuICBNb2RpZnlpbmcgd2l0 aCBQVVQKCiAgIFBVVCBwZXJmb3JtcyBhIGZ1bGwgdXBkYXRlLiAgQ29uc3VtZXJzIG11c3QgcmV0 cmlldmUgdGhlIGVudGlyZQogICBSZXNvdXJjZSBhbmQgUFVUIHRoZSBkZXNpcmVkIG1vZGlmaWNh dGlvbnMgYXMgdGhlIG9wZXJhdGlvbgogICBvdmVyd3JpdGVzIGFsbCBwcmV2aW91c2x5IHN0b3Jl ZCBkYXRhIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiB0aGUKICAgcGFzc3dvcmQgYXR0cmlidXRlLiAg SWYgdGhlIHBhc3N3b3JkIGF0dHJpYnV0ZSBvZiB0aGUgVXNlciByZXNvdXJjZQogICBpcyB1bnNw ZWNpZmllZCwgaXQgc2hvdWxkIGJlIGxlZnQgaW4tdGFjdC4gIFNpbmNlIHRoaXMgcGVyZm9ybXMg YQogICBmdWxsIHVwZGF0ZSwgQ29uc3VtZXJzIE1BWSBzZW5kIHJlYWQtb25seSBhdHRyaWJ1dGVz IG9mIHRoZSByZXRyaWV2ZWQKICAgcmVzb3VyY2UgYW5kIFNlcnZpY2UgUHJvdmlkZXIgTVVTVCBp Z25vcmUgYW55IHJlYWQtb25seSBhdHRyaWJ1dGVzCiAgIHRoYXQgYXJlIHByZXNlbnQgaW4gdGhl IHBheWxvYWQgb2YgYSBQVVQgcmVxdWVzdC4gIFVubGVzcyBvdGhlcndpc2UKICAgc3BlY2lmaWVk IGEgc3VjY2Vzc2Z1bCBQVVQgb3BlcmF0aW9uIHJldHVybnMgYSAyMDAgT0sgcmVzcG9uc2UgY29k ZQogICBhbmQgdGhlIGVudGlyZSBSZXNvdXJjZSB3aXRoaW4gdGhlIHJlc3BvbnNlIGJvZHksIGVu YWJsaW5nIHRoZQogICBDb25zdW1lciB0byBjb3JyZWxhdGUgdGhlIENvbnN1bWVyJ3MgYW5kIFBy b3ZpZGVyJ3Mgdmlld3Mgb2YgdGhlCiAgIHVwZGF0ZWQgUmVzb3VyY2UuICBFeGFtcGxlOgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpEcmFrZSwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVz IE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgZHJhZnQtc2NpbS1hcGktMDEgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTIK CgogICBQVVQgL1VzZXJzLzI4MTljMjIzLTdmNzYtNDUzYS05MTlkLTQxMzg2MTkwNDY0NgogICBI b3N0OiBleGFtcGxlLmNvbQogICBBY2NlcHQ6IGFwcGxpY2F0aW9uL2pzb24KICAgQ29udGVudC1U eXBlOiBhcHBsaWNhdGlvbi9qc29uCiAgIEF1dGhvcml6YXRpb246IEJlYXJlciBoNDgwZGpzOTNo ZDgKICAgSWYtTWF0Y2g6IFcvImEzMzBiYzU0ZjA2NzFjOSIKCiAgIHsKICAgICAic2NoZW1hcyI6 WyJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4wIl0sCiAgICAgImlkIjoiMjgxOWMyMjMtN2Y3Ni00 NTNhLTkxOWQtNDEzODYxOTA0NjQ2IiwKICAgICAidXNlck5hbWUiOiJiamVuc2VuIiwKICAgICAi ZXh0ZXJuYWxJZCI6ImJqZW5zZW4iLAogICAgICJuYW1lIjp7CiAgICAgICAiZm9ybWF0dGVkIjoi TXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJIiwKICAgICAgICJmYW1pbHlOYW1lIjoiSmVuc2VuIiwK ICAgICAgICJnaXZlbk5hbWUiOiJCYXJiYXJhIiwKICAgICAgICJtaWRkbGVOYW1lIjoiSmFuZSIK ICAgICB9LAogICAgICJlbWFpbHMiOlsKICAgICAgIHsKICAgICAgICAgICAidmFsdWUiOiJiamVu c2VuQGV4YW1wbGUuY29tIgogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgICAidmFsdWUiOiJi YWJzQGplbnNlbi5vcmciCiAgICAgICB9CiAgICAgXQogICB9CgoKCiAgIFRoZSBzZXJ2aWNlIHJl c3BvbmRzIHdpdGggdGhlIGVudGlyZSwgdXBkYXRlZCBVc2VyCgoKCgoKCgoKCgoKCgoKCgoKCgoK RHJha2UsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAg ICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGRyYWZ0LXNjaW0t YXBpLTAxICAgICAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKSFRUUC8xLjEgMjAwIE9LCkNvbnRl bnQtVHlwZTogYXBwbGljYXRpb24vanNvbgpFVGFnOiBXLyJiNDMxYWY1NGYwNjcxYTIiCkxvY2F0 aW9uOiJodHRwczovL2V4YW1wbGUuY29tL3YxL1VzZXJzLzI4MTljMjIzLTdmNzYtNDUzYS05MTlk LTQxMzg2MTkwNDY0NiIKewogICJzY2hlbWFzIjpbInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAi XSwKICAiaWQiOiIyODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5MDQ2NDYiLAogICJ1c2Vy TmFtZSI6ImJqZW5zZW4iLAogICJleHRlcm5hbElkIjoiYmplbnNlbiIsCiAgIm5hbWUiOnsKICAg ICJmb3JtYXR0ZWQiOiJNcy4gQmFyYmFyYSBKIEplbnNlbiBJSUkiLAogICAgImZhbWlseU5hbWUi OiJKZW5zZW4iLAogICAgImdpdmVuTmFtZSI6IkJhcmJhcmEiLAogICAgIm1pZGRsZU5hbWUiOiJK YW5lIgogIH0sCiAgImVtYWlscyI6WwogICAgewogICAgICAgICJ2YWx1ZSI6ImJqZW5zZW5AZXhh bXBsZS5jb20iCiAgICB9LAogICAgewogICAgICAgICJ2YWx1ZSI6ImJhYnNAamVuc2VuLm9yZyIK ICAgIH0KICBdLAogICJtZXRhIjogewogICAgImNyZWF0ZWQiOiIyMDExLTA4LTA4VDA0OjU2OjIy WiIsCiAgICAibGFzdE1vZGlmaWVkIjoiMjAxMS0wOC0wOFQwODowMDoxMloiLAogICAgImxvY2F0 aW9uIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS92MS9Vc2Vycy8yODE5YzIyMy03Zjc2LTQ1M2EtOTE5 ZC00MTM4NjE5MDQ2NDYiLAogICAgInZlcnNpb24iOiJXXC9cImI0MzFhZjU0ZjA2NzFhMlwiIgog IH0KfQoKMy4zLjIuICBNb2RpZnlpbmcgd2l0aCBQQVRDSAoKICAgUEFUQ0ggaXMgT1BUSU9OQUwu ICBQQVRDSCBlbmFibGVzIGNvbnN1bWVycyB0byBzZW5kIG9ubHkgdGhvc2UKICAgYXR0cmlidXRl cyByZXF1aXJpbmcgbW9kaWZpY2F0aW9uLCByZWR1Y2luZyBuZXR3b3JrIGFuZCBwcm9jZXNzaW5n CiAgIG92ZXJoZWFkLiAgQXR0cmlidXRlcyBtYXkgYmUgZGVsZXRlZCwgcmVwbGFjZWQsIG1lcmdl ZCwgb3IgYWRkZWQgaW4gYQogICBzaW5nbGUgcmVxdWVzdC4KCiAgIFRoZSBib2R5IG9mIGEgUEFU Q0ggcmVxdWVzdCBNVVNUIGNvbnRhaW4gYSBwYXJ0aWFsIFJlc291cmNlIHdpdGggdGhlCiAgIGRl c2lyZWQgbW9kaWZpY2F0aW9ucy4gIFRoZSBzZXJ2ZXIgTVVTVCByZXR1cm4gZWl0aGVyIGEgMjAw IE9LCiAgIHJlc3BvbnNlIGNvZGUgYW5kIHRoZSBlbnRpcmUgUmVzb3VyY2UgKHN1YmplY3QgdG8g dGhlICJhdHRyaWJ1dGVzIgogICBxdWVyeSBwYXJhbWV0ZXIgLSBzZWUgQWRkaXRpb25hbCBSZXRy aWV2YWwgUXVlcnkgUGFyYW1ldGVycwogICAoU2VjdGlvbiAzLjcpKSB3aXRoaW4gdGhlIHJlc3Bv bnNlIGJvZHksIG9yIGEgMjA0IE5vIENvbnRlbnQgcmVzcG9uc2UKICAgY29kZSBhbmQgdGhlIGFw cHJvcHJpYXRlIHJlc3BvbnNlIGhlYWRlcnMgZm9yIGEgc3VjY2Vzc2Z1bCBQQVRDSAogICByZXF1 ZXN0LiAgVGhlIHNlcnZlciBNVVNUIHJldHVybiBhIDIwMCBPSyBpZiB0aGUgImF0dHJpYnV0ZXMi CiAgIHBhcmFtZXRlciBpcyBzcGVjaWZpZWQgb24gdGhlIHJlcXVlc3QuCgogICBUaGUgc2VydmVy IE1VU1QgcHJvY2VzcyBhIFBBVENIIHJlcXVlc3QgYnkgZmlyc3QgcmVtb3ZpbmcgYW55CgoKCkRy YWtlLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAg ICAgIFtQYWdlIDE3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBkcmFmdC1zY2ltLWFw aS0wMSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxMgoKCiAgIGF0dHJpYnV0ZXMgc3BlY2lmaWVk IGluIHRoZSBtZXRhLmF0dHJpYnV0ZXMgU3ViLUF0dHJpYnV0ZSAoaWYKICAgcHJlc2VudCkgYW5k IHRoZW4gbWVyZ2luZyB0aGUgYXR0cmlidXRlcyBpbiB0aGUgUEFUQ0ggcmVxdWVzdCBib2R5CiAg IGludG8gdGhlIFJlc291cmNlLgoKICAgVGhlIG1ldGEuYXR0cmlidXRlcyBTdWItQXR0cmlidXRl IE1BWSBjb250YWluIGEgbGlzdCBvZiBhdHRyaWJ1dGVzIHRvCiAgIGJlIHJlbW92ZWQgZnJvbSB0 aGUgUmVzb3VyY2UuICBJZiB0aGUgUEFUQ0ggcmVxdWVzdCBib2R5IGNvbnRhaW5zIGFuCiAgIGF0 dHJpYnV0ZSB0aGF0IGlzIHByZXNlbnQgaW4gdGhlIG1ldGEuYXR0cmlidXRlcyBsaXN0LCB0aGUg YXR0cmlidXRlCiAgIG9uIHRoZSBSZXNvdXJjZSBpcyByZXBsYWNlZCB3aXRoIHRoZSB2YWx1ZSBm cm9tIHRoZSBQQVRDSCBib2R5LiAgSWYKICAgdGhlIGF0dHJpYnV0ZSBpcyBjb21wbGV4IHRoZSBh dHRyaWJ1dGUgbmFtZSBtdXN0IGJlIGEgcGF0aCB0byBhIFN1Yi0KICAgQXR0cmlidXRlIGluIHN0 YW5kYXJkIGF0dHJpYnV0ZSBub3RhdGlvbiAoU2VjdGlvbiAzLjgpOyBlLmcuLAogICBuYW1lLmdp dmVuTmFtZS4KCiAgIEF0dHJpYnV0ZXMgdGhhdCBleGlzdCBpbiB0aGUgUEFUQ0ggcmVxdWVzdCBi b2R5IGJ1dCBub3QgaW4gdGhlCiAgIG1ldGEuYXR0cmlidXRlcyBTdWItQXR0cmlidXRlIHdpbGwg YmUgZWl0aGVyIGJlIHVwZGF0ZWQgb3IgYWRkZWQgdG8KICAgdGhlIFJlc291cmNlIGFjY29yZGlu ZyB0byB0aGUgZm9sbG93aW5nIHJ1bGVzLgoKICAgU2luZ3VsYXIgYXR0cmlidXRlczogIFNpbmd1 bGFyIGF0dHJpYnV0ZXMgaW4gdGhlIFBBVENIIHJlcXVlc3QgYm9keQogICAgICByZXBsYWNlIHRo ZSBhdHRyaWJ1dGUgb24gdGhlIFJlc291cmNlLgoKICAgQ29tcGxleCBhdHRyaWJ1dGVzOiAgQ29t cGxleCBTdWItQXR0cmlidXRlIHZhbHVlcyBpbiB0aGUgUEFUQ0gKICAgICAgcmVxdWVzdCBib2R5 IGFyZSBtZXJnZWQgaW50byB0aGUgY29tcGxleCBhdHRyaWJ1dGUgb24gdGhlCiAgICAgIFJlc291 cmNlLgoKICAgTXVsdGktdmFsdWVkIGF0dHJpYnV0ZXM6ICBBbiBhdHRyaWJ1dGUgdmFsdWUgaW4g dGhlIFBBVENIIHJlcXVlc3QKICAgICAgYm9keSBpcyBhZGRlZCB0byB0aGUgdmFsdWUgY29sbGVj dGlvbiBpZiB0aGUgdmFsdWUgZG9lcyBub3QgZXhpc3QKICAgICAgYW5kIG1lcmdlZCBpZiBhIG1h dGNoaW5nIHZhbHVlIGlzIHByZXNlbnQuICBWYWx1ZXMgYXJlIG1hdGNoZWQgYnkKICAgICAgY29t cGFyaW5nIHRoZSB2YWx1ZSBTdWItQXR0cmlidXRlIGZyb20gdGhlIFBBVENIIHJlcXVlc3QgYm9k eSB0bwogICAgICB0aGUgdmFsdWUgU3ViLUF0dHJpYnV0ZSBvZiB0aGUgUmVzb3VyY2UuICBBdHRy aWJ1dGVzIHRoYXQgZG8gbm90CiAgICAgIGhhdmUgYSB2YWx1ZSBTdWItQXR0cmlidXRlOyBlLmcu LCBhZGRyZXNzZXMsIG9yIGRvIG5vdCBoYXZlIHVuaXF1ZQogICAgICB2YWx1ZSBTdWItQXR0cmli dXRlcyBjYW5ub3QgYmUgbWF0Y2hlZCBhbmQgbXVzdCBpbnN0ZWFkIGJlIGRlbGV0ZWQKICAgICAg dGhlbiBhZGRlZC4gIFNwZWNpZmljIHZhbHVlcyBjYW4gYmUgcmVtb3ZlZCBmcm9tIGEgUmVzb3Vy Y2UgYnkKICAgICAgYWRkaW5nIGFuICJvcGVyYXRpb24iIFN1Yi1BdHRyaWJ1dGUgd2l0aCB0aGUg dmFsdWUgImRlbGV0ZSIgdG8gdGhlCiAgICAgIGF0dHJpYnV0ZSBpbiB0aGUgUEFUQ0ggcmVxdWVz dCBib2R5LiAgQXMgd2l0aCBhZGRpbmcvdXBkYXRpbmcKICAgICAgYXR0cmlidXRlIHZhbHVlIGNv bGxlY3Rpb25zLCB0aGUgdmFsdWUgdG8gZGVsZXRlIGlzIGRldGVybWluZWQgYnkKICAgICAgY29t cGFyaW5nIHRoZSB2YWx1ZSBTdWItQXR0cmlidXRlIGZyb20gdGhlIFBBVENIIHJlcXVlc3QgYm9k eSB0bwogICAgICB0aGUgdmFsdWUgU3ViLUF0dHJpYnV0ZSBvZiB0aGUgUmVzb3VyY2UuICBBdHRy aWJ1dGVzIHRoYXQgZG8gbm90CiAgICAgIGhhdmUgYSB2YWx1ZSBTdWItQXR0cmlidXRlIG9yIHRo YXQgaGF2ZSBhIG5vbi11bmlxdWUgdmFsdWUgU3ViLQogICAgICBBdHRyaWJ1dGUgYXJlIG1hdGNo ZWQgYnkgY29tcGFyaW5nIGFsbCBTdWItQXR0cmlidXRlIHZhbHVlcyBmcm9tCiAgICAgIHRoZSBQ QVRDSCByZXF1ZXN0IGJvZHkgdG8gdGhlIFN1Yi1BdHRyaWJ1dGUgdmFsdWVzIG9mIHRoZQogICAg ICBSZXNvdXJjZS4gIEEgZGVsZXRlIG9wZXJhdGlvbiBpcyBpZ25vcmVkIGlmIHRoZSBhdHRyaWJ1 dGUncyBuYW1lCiAgICAgIGlzIGluIHRoZSBtZXRhLmF0dHJpYnV0ZXMgbGlzdC4gIElmIHRoZSBy ZXF1ZXN0ZWQgdmFsdWUgdG8gZGVsZXRlCiAgICAgIGRvZXMgbm90IG1hdGNoIGEgdW5pcXVlIHZh bHVlIG9uIHRoZSBSZXNvdXJjZSB0aGUgc2VydmVyIE1BWQogICAgICByZXR1cm4gYSBIVFRQIDQw MCBlcnJvci4KCiAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBzaG93cyBob3cgdG8gYWRkIGEgbWVt YmVyIHRvIGEgZ3JvdXA6CgoKCgoKCkRyYWtlLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMg TWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDE4XQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxMgoK CiAgIFBBVENIIC9Hcm91cHMvYWNiZjNhZTctODQ2My00NjkyLWI0ZmQtOWI0ZGEzZjkwOGNlCiAg IEhvc3Q6IGV4YW1wbGUuY29tCiAgIEFjY2VwdDogYXBwbGljYXRpb24vanNvbgogICBDb250ZW50 LVR5cGU6IGFwcGxpY2F0aW9uL2pzb24KICAgQXV0aG9yaXphdGlvbjogQmVhcmVyIGg0ODBkanM5 M2hkOAogICBJZi1NYXRjaDogVy8iYTMzMGJjNTRmMDY3MWM5IgoKICAgewogICAgICJzY2hlbWFz IjogWyJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4wIl0sCiAgICAgIm1lbWJlcnMiOiBbCiAgICAg ICB7CiAgICAgICAgICJkaXNwbGF5IjogIkJhYnMgSmVuc2VuIiwKICAgICAgICAgInZhbHVlIjog IjI4MTljMjIzLTdmNzYtNDUzYS05MTlkLTQxMzg2MTkwNDY0NiIKICAgICAgIH0KICAgICBdCiAg IH0KCiAgIFRoZSAiZGlzcGxheSIgU3ViLUF0dHJpYnV0ZSBpbiB0aGlzIHJlcXVlc3QgaXMgb3B0 aW9uYWwgc2luY2UgdGhlCiAgIHZhbHVlIGF0dHJpYnV0ZSB1bmlxdWVseSBpZGVudGlmaWVzIHRo ZSB1c2VyIHRvIGJlIGFkZGVkLiAgSWYgdGhlCiAgIHVzZXIgd2FzIGFscmVhZHkgYSBtZW1iZXIg b2YgdGhpcyBncm91cCwgbm8gY2hhbmdlcyBzaG91bGQgYmUgbWFkZSB0bwogICB0aGUgUmVzb3Vy Y2UgYW5kIGEgc3VjY2VzcyByZXNwb25zZSBzaG91bGQgYmUgcmV0dXJuZWQuICBUaGUgc2VydmVy CiAgIHJlc3BvbmRzIHdpdGggZWl0aGVyIHRoZSBlbnRpcmUgdXBkYXRlZCBHcm91cCBvciBubyBy ZXNwb25zZSBib2R5OgoKSFRUUC8xLjEgMjA0IE5vIENvbnRlbnQKQXV0aG9yaXphdGlvbjogQmVh cmVyIGg0ODBkanM5M2hkOApFVGFnOiBXLyJiNDMxYWY1NGYwNjcxYTIiCkxvY2F0aW9uOiAiaHR0 cHM6Ly9leGFtcGxlLmNvbS92MS9Hcm91cHMvYWNiZjNhZTctODQ2My00NjkyLWI0ZmQtOWI0ZGEz ZjkwOGNlIgoKICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIGhvdyB0byByZW1vdmUgYSBt ZW1iZXIgZnJvbSBhIGdyb3VwLiAgQXMKICAgd2l0aCB0aGUgcHJldmlvdXMgZXhhbXBsZSwgdGhl ICJkaXNwbGF5IiBTdWItQXR0cmlidXRlIGlzIG9wdGlvbmFsLgogICBJZiB0aGUgdXNlciB3YXMg bm90IGEgbWVtYmVyIG9mIHRoaXMgZ3JvdXAsIG5vIGNoYW5nZXMgc2hvdWxkIGJlIG1hZGUKICAg dG8gdGhlIFJlc291cmNlIGFuZCBhIHN1Y2Nlc3MgcmVzcG9uc2Ugc2hvdWxkIGJlIHJldHVybmVk LgoKICAgTm90ZSB0aGF0IHNlcnZlciByZXNwb25zZXMgaGF2ZSBiZWVuIG9taXR0ZWQgZm9yIHRo ZSByZXN0IG9mIHRoZQogICBQQVRDSCBleGFtcGxlcy4KCgoKCgoKCgoKCgoKCgoKCkRyYWtlLCBl dCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQ YWdlIDE5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAg ICAgICAgICAgICAgTm92ZW1iZXIgMjAxMgoKCiAgIFBBVENIIC9Hcm91cHMvYWNiZjNhZTctODQ2 My00NjkyLWI0ZmQtOWI0ZGEzZjkwOGNlCiAgIEhvc3Q6IGV4YW1wbGUuY29tCiAgIEFjY2VwdDog YXBwbGljYXRpb24vanNvbgogICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb24KICAgQXV0 aG9yaXphdGlvbjogQmVhcmVyIGg0ODBkanM5M2hkOAogICBJZi1NYXRjaDogVy8iYTMzMGJjNTRm MDY3MWM5IgoKICAgewogICAgICJzY2hlbWFzIjogWyJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4w Il0sCiAgICAgIm1lbWJlcnMiOiBbCiAgICAgICB7CiAgICAgICAgICJkaXNwbGF5IjogIkJhYnMg SmVuc2VuIiwKICAgICAgICAgInZhbHVlIjogIjI4MTljMjIzLTdmNzYtNDUzYS05MTlkLTQxMzg2 MTkwNDY0NiIKICAgICAgICAgIm9wZXJhdGlvbiI6ICJkZWxldGUiCiAgICAgICB9CiAgICAgXQog ICB9CgogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgaG93IHRvIHJlbW92ZSBhbGwgbWVt YmVycyBmcm9tIGEgZ3JvdXA6CgogICBQQVRDSCAvR3JvdXBzL2FjYmYzYWU3LTg0NjMtNDY5Mi1i NGZkLTliNGRhM2Y5MDhjZQogICBIb3N0OiBleGFtcGxlLmNvbQogICBBY2NlcHQ6IGFwcGxpY2F0 aW9uL2pzb24KICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uCiAgIEF1dGhvcml6YXRp b246IEJlYXJlciBoNDgwZGpzOTNoZDgKICAgSWYtTWF0Y2g6IFcvImEzMzBiYzU0ZjA2NzFjOSIK CiAgIHsKICAgICAic2NoZW1hcyI6IFsidXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCJdLAogICAg ICJtZXRhIjogewogICAgICAgImF0dHJpYnV0ZXMiOiBbCiAgICAgICAgICJtZW1iZXJzIgogICAg ICAgXQogICAgIH0KICAgfQoKICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIGhvdyB0byBy ZXBsYWNlIGFsbCBvZiB0aGUgbWVtYmVycyBvZiBhCiAgIGdyb3VwIHdpdGggYSBkaWZmZXJlbnQg bWVtYmVycyBsaXN0OgoKCgoKCgoKCgoKCgoKRHJha2UsIGV0IGFsLiAgICAgICAgICAgICAgRXhw aXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgMjBdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIGRyYWZ0LXNjaW0tYXBpLTAxICAgICAgICAgICAgICBOb3ZlbWJlciAy MDEyCgoKICAgUEFUQ0ggL0dyb3Vwcy9hY2JmM2FlNy04NDYzLTQ2OTItYjRmZC05YjRkYTNmOTA4 Y2UKICAgSG9zdDogZXhhbXBsZS5jb20KICAgQWNjZXB0OiBhcHBsaWNhdGlvbi9qc29uCiAgIENv bnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbgogICBBdXRob3JpemF0aW9uOiBCZWFyZXIgaDQ4 MGRqczkzaGQ4CiAgIElmLU1hdGNoOiBXLyJhMzMwYmM1NGYwNjcxYzkiCgogICB7CiAgICAgInNj aGVtYXMiOiBbInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiXSwKICAgICAibWV0YSI6IHsKICAg ICAgICJhdHRyaWJ1dGVzIjogWwogICAgICAgICAibWVtYmVycyIKICAgICAgIF0KICAgICB9LAog ICAgICJtZW1iZXJzIjogWwogICAgICAgewogICAgICAgICAiZGlzcGxheSI6ICJCYWJzIEplbnNl biIsCiAgICAgICAgICJ2YWx1ZSI6ICIyODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5MDQ2 NDYiCiAgICAgICB9LAogICAgICAgewogICAgICAgICAiZGlzcGxheSI6ICJKYW1lcyBTbWl0aCIs CiAgICAgICAgICJ2YWx1ZSI6ICIwOGUxZDA1ZC0xMjFjLTQ1NjEtOGI5Ni00NzNkOTNkZjkyMTAi CiAgICAgICB9CiAgICAgXQogICB9CgogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgaG93 IHRvIGFkZCBhIG1lbWJlciB0byBhbmQgcmVtb3ZlIGEKICAgbWVtYmVyIGZyb20gYSBHcm91cCBp biBhIHNpbmdsZSByZXF1ZXN0OgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkRyYWtlLCBldCBhbC4g ICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDIx XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAg ICAgICAgTm92ZW1iZXIgMjAxMgoKCiAgIFBBVENIIC9Hcm91cHMvYWNiZjNhZTctODQ2My00Njky LWI0ZmQtOWI0ZGEzZjkwOGNlCiAgIEhvc3Q6IGV4YW1wbGUuY29tCiAgIEFjY2VwdDogYXBwbGlj YXRpb24vanNvbgogICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb24KICAgQXV0aG9yaXph dGlvbjogQmVhcmVyIGg0ODBkanM5M2hkOAogICBJZi1NYXRjaDogVy8iYTMzMGJjNTRmMDY3MWM5 IgoKICAgewogICAgICJzY2hlbWFzIjogWyJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4wIl0sCiAg ICAgIm1lbWJlcnMiOiBbCiAgICAgICB7CiAgICAgICAgICJkaXNwbGF5IjogIkJhYnMgSmVuc2Vu IiwKICAgICAgICAgInZhbHVlIjogIjI4MTljMjIzLTdmNzYtNDUzYS05MTlkLTQxMzg2MTkwNDY0 NiIKICAgICAgICAgIm9wZXJhdGlvbiI6ICJkZWxldGUiCiAgICAgICB9LAogICAgICAgewogICAg ICAgICAiZGlzcGxheSI6ICJKYW1lcyBTbWl0aCIsCiAgICAgICAgICJ2YWx1ZSI6ICIwOGUxZDA1 ZC0xMjFjLTQ1NjEtOGI5Ni00NzNkOTNkZjkyMTAiCiAgICAgICB9CiAgICAgXQogICB9CgogICBU aGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgaG93IHRvIGNoYW5nZSBhIFVzZXIncyBwcmltYXJ5 IGVtYWlsLiAgSWYKICAgdGhlIFVzZXIgYWxyZWFkeSBoYXMgdGhlIGVtYWlsIGFkZHJlc3MsIGl0 IGlzIG1hZGUgdGhlIHByaW1hcnkKICAgYWRkcmVzcyBhbmQgdGhlIGN1cnJlbnQgcHJpbWFyeSBh ZGRyZXNzIChpZiBwcmVzZW50KSBpcyBtYWRlIG5vbi0KICAgcHJpbWFyeS4gIElmIHRoZSBVc2Vy IGRvZXMgbm90IGFscmVhZHkgaGF2ZSB0aGUgZW1haWwgYWRkcmVzcywgaXQgaXMKICAgYWRkZWQg YW5kIG1hZGUgdGhlIHByaW1hcnkgYWRkcmVzcy4KCiAgIFBBVENIIC9Vc2Vycy8yODE5YzIyMy03 Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5MDQ2NDYKICAgSG9zdDogZXhhbXBsZS5jb20KICAgQWNjZXB0 OiBhcHBsaWNhdGlvbi9qc29uCiAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbgogICBB dXRob3JpemF0aW9uOiBCZWFyZXIgaDQ4MGRqczkzaGQ4CiAgIElmLU1hdGNoOiBXLyJhMzMwYmM1 NGYwNjcxYzkiCgogICB7CiAgICAgInNjaGVtYXMiOiBbInVybjpzY2ltOnNjaGVtYXM6Y29yZTox LjAiXSwKICAgICAiZW1haWxzIjogWwogICAgICAgewogICAgICAgICAidmFsdWUiOiAiYmplbnNl bkBleGFtcGxlLmNvbSIsCiAgICAgICAgICJwcmltYXJ5IjogdHJ1ZQogICAgICAgfQogICAgIF0K ICAgfQoKICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIGhvdyB0byBjaGFuZ2UgYSBVc2Vy J3MgYWRkcmVzcy4gIFNpbmNlCiAgIGFkZHJlc3MgZG9lcyBub3QgaGF2ZSBhIHZhbHVlIFN1Yi1B dHRyaWJ1dGUsIHRoZSBleGlzdGluZyBhZGRyZXNzCiAgIG11c3QgYmUgcmVtb3ZlZCBhbmQgdGhl IG1vZGlmaWVkIGFkZHJlc3MgYWRkZWQuCgoKCkRyYWtlLCBldCBhbC4gICAgICAgICAgICAgIEV4 cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDIyXQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAgTm92ZW1iZXIg MjAxMgoKCiAgUEFUQ0ggL1VzZXJzLzI4MTljMjIzLTdmNzYtNDUzYS05MTlkLTQxMzg2MTkwNDY0 NgogIEhvc3Q6IGV4YW1wbGUuY29tCiAgQWNjZXB0OiBhcHBsaWNhdGlvbi9qc29uCiAgQ29udGVu dC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uCiAgQXV0aG9yaXphdGlvbjogQmVhcmVyIGg0ODBkanM5 M2hkOAogIElmLU1hdGNoOiBXLyJhMzMwYmM1NGYwNjcxYzkiCgogIHsKICAgICJzY2hlbWFzIjog WyJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4wIl0sCiAgICAiYWRkcmVzc2VzIjogWwogICAgICB7 CiAgICAgICAgInR5cGUiOiAid29yayIsCiAgICAgICAgInN0cmVldEFkZHJlc3MiOiAiMTAwIFVu aXZlcnNhbCBDaXR5IFBsYXphIiwKICAgICAgICAibG9jYWxpdHkiOiAiSG9sbHl3b29kIiwKICAg ICAgICAicmVnaW9uIjogIkNBIiwKICAgICAgICAicG9zdGFsQ29kZSI6ICI5MTYwOCIsCiAgICAg ICAgImNvdW50cnkiOiAiVVMiLAogICAgICAgICJmb3JtYXR0ZWQiOiAiMTAwIFVuaXZlcnNhbCBD aXR5IFBsYXphXG5Ib2xseXdvb2QsIENBIDkxNjA4IFVTIiwKICAgICAgICAicHJpbWFyeSI6IHRy dWUKICAgICAgICAib3BlcmF0aW9uIjogImRlbGV0ZSIKICAgICAgfSwKICAgICAgewogICAgICAg ICJ0eXBlIjogIndvcmsiLAogICAgICAgICJzdHJlZXRBZGRyZXNzIjogIjkxMSBVbml2ZXJzYWwg Q2l0eSBQbGF6YSIsCiAgICAgICAgImxvY2FsaXR5IjogIkhvbGx5d29vZCIsCiAgICAgICAgInJl Z2lvbiI6ICJDQSIsCiAgICAgICAgInBvc3RhbENvZGUiOiAiOTE2MDgiLAogICAgICAgICJjb3Vu dHJ5IjogIlVTIiwKICAgICAgICAiZm9ybWF0dGVkIjogIjkxMSBVbml2ZXJzYWwgQ2l0eSBQbGF6 YVxuSG9sbHl3b29kLCBDQSA5MTYwOCBVUyIsCiAgICAgICAgInByaW1hcnkiOiB0cnVlCiAgICAg IH0KICAgIF0KICB9CgogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgaG93IHRvIGNoYW5n ZSBhIFVzZXIncyBuaWNrbmFtZToKCiAgIFBBVENIIC9Vc2Vycy8yODE5YzIyMy03Zjc2LTQ1M2Et OTE5ZC00MTM4NjE5MDQ2NDYKICAgSG9zdDogZXhhbXBsZS5jb20KICAgQWNjZXB0OiBhcHBsaWNh dGlvbi9qc29uCiAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbgogICBBdXRob3JpemF0 aW9uOiBCZWFyZXIgaDQ4MGRqczkzaGQ4CiAgIElmLU1hdGNoOiBXLyJhMzMwYmM1NGYwNjcxYzki CgogICB7CiAgICAgInNjaGVtYXMiOiBbInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiXSwKICAg ICAibmlja05hbWUiOiAiQmFyYmllIgogICB9CgoKCgpEcmFrZSwgZXQgYWwuICAgICAgICAgICAg ICBFeHBpcmVzIE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAyM10KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgZHJhZnQtc2NpbS1hcGktMDEgICAgICAgICAgICAgIE5vdmVt YmVyIDIwMTIKCgogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgaG93IHRvIHJlbW92ZSBh IFVzZXIncyBuaWNrbmFtZToKCiAgIFBBVENIIC9Vc2Vycy8yODE5YzIyMy03Zjc2LTQ1M2EtOTE5 ZC00MTM4NjE5MDQ2NDYKICAgSG9zdDogZXhhbXBsZS5jb20KICAgQWNjZXB0OiBhcHBsaWNhdGlv bi9qc29uCiAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbgogICBBdXRob3JpemF0aW9u OiBCZWFyZXIgaDQ4MGRqczkzaGQ4CiAgIElmLU1hdGNoOiBXLyJhMzMwYmM1NGYwNjcxYzkiCgog ICB7CiAgICAgInNjaGVtYXMiOiBbInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiXSwKICAgICAi bWV0YSI6IHsKICAgICAgICJhdHRyaWJ1dGVzIjogWwogICAgICAgICAibmlja05hbWUiCiAgICAg ICBdCiAgICAgfQogICB9CgogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgaG93IHRvIGNo YW5nZSBhIFVzZXIncyBmYW1pbHlOYW1lLiAgVGhpcwogICBvbmx5IHVwZGF0ZXMgdGhlIGZhbWls eU5hbWUgYW5kIGZvcm1hdHRlZCBvbiB0aGUgIm5hbWUiIGNvbXBsZXgKICAgYXR0cmlidXRlLiAg QW55IG90aGVyIG5hbWUgU3ViLUF0dHJpYnV0ZXMgb24gdGhlIFJlc291cmNlIHJlbWFpbgogICB1 bmNoYW5nZWQuCgogICBQQVRDSCAvVXNlcnMvMjgxOWMyMjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYx OTA0NjQ2CiAgIEhvc3Q6IGV4YW1wbGUuY29tCiAgIEFjY2VwdDogYXBwbGljYXRpb24vanNvbgog ICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb24KICAgQXV0aG9yaXphdGlvbjogQmVhcmVy IGg0ODBkanM5M2hkOAogICBJZi1NYXRjaDogVy8iYTMzMGJjNTRmMDY3MWM5IgoKICAgewogICAg ICJzY2hlbWFzIjogWyJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4wIl0sCiAgICAgIm5hbWUiOiB7 CiAgICAgICAiZm9ybWF0dGVkIjogIk1zLiBCYXJiYXJhIEogSmVuc2VuIElJSSIsCiAgICAgICAi ZmFtaWx5TmFtZSI6ICJKZW5zZW4iCiAgICAgfQogICB9CgogICBUaGUgZm9sbG93aW5nIGV4YW1w bGUgc2hvd3MgaG93IHRvIHJlbW92ZSBhIGNvbXBsZXggU3ViLUF0dHJpYnV0ZSBhbmQKICAgYW4g ZXh0ZW5kZWQgc2NoZW1hIGF0dHJpYnV0ZSBmcm9tIGEgVXNlci4KCgoKCgoKCgoKCgpEcmFrZSwg ZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICBb UGFnZSAyNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgZHJhZnQtc2NpbS1hcGktMDEg ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgogICBQQVRDSCAvVXNlcnMvMjgxOWMyMjMtN2Y3 Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2CiAgIEhvc3Q6IGV4YW1wbGUuY29tCiAgIEFjY2VwdDog YXBwbGljYXRpb24vanNvbgogICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb24KICAgQXV0 aG9yaXphdGlvbjogQmVhcmVyIGg0ODBkanM5M2hkOAogICBJZi1NYXRjaDogVy8iYTMzMGJjNTRm MDY3MWM5IgoKICAgewogICAgICJzY2hlbWFzIjogWyJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4w Il0sCiAgICAgIm1ldGEiOiB7CiAgICAgICAiYXR0cmlidXRlcyI6IFsKICAgICAgICAgIm5hbWUu Zm9ybWF0dGVkIiwKICAgICAgICAgInVybjpocjpzY2hlbWFzOnVzZXI6YWdlIgogICAgICAgXQog ICAgIH0KICAgfQoKMy40LiAgRGVsZXRpbmcgUmVzb3VyY2VzCgogICBDb25zdW1lcnMgcmVxdWVz dCBSZXNvdXJjZSByZW1vdmFsIHZpYSBERUxFVEUuICBTZXJ2aWNlIFByb3ZpZGVycyBNQVkKICAg Y2hvb3NlIG5vdCB0byBwZXJtYW5lbnRseSBkZWxldGUgdGhlIFJlc291cmNlLCBidXQgTVVTVCBy ZXR1cm4gYSA0MDQKICAgZXJyb3IgY29kZSBmb3IgYWxsIG9wZXJhdGlvbnMgYXNzb2NpYXRlZCB3 aXRoIHRoZSBwcmV2aW91c2x5IGRlbGV0ZWQKICAgSWQuICBTZXJ2aWNlIFByb3ZpZGVycyBNVVNU IGFsc28gb21pdCB0aGUgUmVzb3VyY2UgZnJvbSBmdXR1cmUgcXVlcnkKICAgcmVzdWx0cy4gIElu IGFkZGl0aW9uIHRoZSBTZXJ2aWNlIFByb3ZpZGVyIE1VU1Qgbm90IGNvbnNpZGVyIHRoZQogICBk ZWxldGVkIHJlc291cmNlIGluIGNvbmZsaWN0IGNhbGN1bGF0aW9uLiAgRm9yIGV4YW1wbGUgaWYg YSBVc2VyCiAgIHJlc291cmNlIGlzIGRlbGV0ZWQsIGEgQ1JFQVRFIHJlcXVlc3QgZm9yIGEgVXNl ciByZXNvdXJjZSB3aXRoIHRoZQogICBzYW1lIHVzZXJOYW1lIGFzIHRoZSBwcmV2aW91c2x5IGRl bGV0ZWQgcmVzb3VyY2Ugc2hvdWxkIG5vdCBmYWlsIHdpdGgKICAgYSA0MDkgZXJyb3IgZHVlIHRv IHVzZXJOYW1lIGNvbmZsaWN0LgoKCgogICBERUxFVEUgL1VzZXJzLzI4MTljMjIzLTdmNzYtNDUz YS05MTlkLTQxMzg2MTkwNDY0NgogICBIb3N0OiBleGFtcGxlLmNvbQogICBBdXRob3JpemF0aW9u OiBCZWFyZXIgaDQ4MGRqczkzaGQ4CiAgIElmLU1hdGNoOiBXLyJjMzEwY2Q4NGYwMjgxYjciCgoK CgogICBIVFRQLzEuMSAyMDAgT0sKCiAgIEV4YW1wbGU6IENvbnN1bWVyIGF0dGVtcHQgdG8gcmV0 cmlldmUgdGhlIHByZXZpb3VzbHkgZGVsZXRlZCBVc2VyCgoKCiAgIEdFVCAvVXNlcnMvMjgxOWMy MjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2CiAgIEhvc3Q6IGV4YW1wbGUuY29tCiAgIEF1 dGhvcml6YXRpb246IEJlYXJlciBoNDgwZGpzOTNoZDgKCgoKRHJha2UsIGV0IGFsLiAgICAgICAg ICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgMjVdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGRyYWZ0LXNjaW0tYXBpLTAxICAgICAgICAgICAgICBO b3ZlbWJlciAyMDEyCgoKSFRUUC8xLjEgNDA0IE5PVCBGT1VORAoKewogICJFcnJvcnMiOlsKICAg IHsKICAgICAgImRlc2NyaXB0aW9uIjoiUmVzb3VyY2UgMjgxOWMyMjMtN2Y3Ni00NTNhLTkxOWQt NDEzODYxOTA0NjQ2IG5vdCBmb3VuZCIsCiAgICAgICJjb2RlIjoiNDA0IgogICAgfQogIF0KfQoK CjMuNS4gIEJ1bGsKCiAgIEJ1bGsgaXMgT1BUSU9OQUwuICBUaGUgYnVsayBvcGVyYXRpb24gZW5h YmxlcyBDb25zdW1lcnMgdG8gc2VuZCBhCiAgIHBvdGVudGlhbGx5IGxhcmdlIGNvbGxlY3Rpb24g b2YgUmVzb3VyY2Ugb3BlcmF0aW9ucyBpbiBhIHNpbmdsZQogICByZXF1ZXN0LiAgVGhlIGJvZHkg b2YgYSBhIGJ1bGsgb3BlcmF0aW9uIGNvbnRhaW5zIGEgc2V0IG9mIEhUVFAKICAgUmVzb3VyY2Ug b3BlcmF0aW9ucyB1c2luZyBvbmUgb2YgdGhlIEFQSSBzdXBwb3J0ZWQgSFRUUCBtZXRob2RzOwog ICBpLmUuLCBQT1NULCBQVVQsIFBBVENIIG9yIERFTEVURS4KCiAgIFRoZSBmb2xsb3dpbmcgU2lu Z3VsYXIgQXR0cmlidXRlIGlzIGRlZmluZWQgaW4gYWRkaXRpb24gdG8gdGhlIGNvbW1vbgogICBh dHRyaWJ1dGVzIGRlZmluZWQgaW4gU0NJTSBjb3JlIHNjaGVtYS4KCiAgIGZhaWxPbkVycm9ycyAg QW4gSW50ZWdlciBzcGVjaWZ5aW5nIHRoZSBudW1iZXIgb2YgZXJyb3JzIHRoYXQgdGhlCiAgICAg IFNlcnZpY2UgUHJvdmlkZXIgd2lsbCBhY2NlcHQgYmVmb3JlIHRoZSBvcGVyYXRpb24gaXMgdGVy bWluYXRlZAogICAgICBhbmQgYW4gZXJyb3IgcmVzcG9uc2UgaXMgcmV0dXJuZWQuICBPUFRJT05B TC4KCiAgIFRoZSBmb2xsb3dpbmcgQ29tcGxleCBNdWx0aS12YWx1ZWQgQXR0cmlidXRlIGlzIGRl ZmluZWQgaW4gYWRkaXRpb24KICAgdG8gdGhlIGNvbW1vbiBhdHRyaWJ1dGVzIGRlZmluZWQgaW4g Y29yZSBzY2hlbWEuCgogICBPcGVyYXRpb25zICBEZWZpbmVzIG9wZXJhdGlvbnMgd2l0aGluIGEg YnVsayBqb2IuICBFYWNoIG9wZXJhdGlvbgogICAgICBjb3JyZXNwb25kcyB0byBhIHNpbmdsZSBI VFRQIHJlcXVlc3QgYWdhaW5zdCBhIFJlc291cmNlIGVuZHBvaW50LgogICAgICBSRVFVSVJFRC4K CiAgICAgIG1ldGhvZCAgVGhlIEhUVFAgbWV0aG9kIG9mIHRoZSBjdXJyZW50IG9wZXJhdGlvbi4g IFBvc3NpYmxlIHZhbHVlcwogICAgICAgICBhcmUgUE9TVCwgUFVULCBQQVRDSCBvciBERUxFVEUu ICBSRVFVSVJFRC4KCiAgICAgIGJ1bGtJZCAgVGhlIHRyYW5zaWVudCBpZGVudGlmaWVyIG9mIGEg bmV3bHkgY3JlYXRlZCBSZXNvdXJjZSwKICAgICAgICAgdW5pcXVlIHdpdGhpbiBhIGJ1bGsgcmVx dWVzdCBhbmQgY3JlYXRlZCBieSB0aGUgQ29uc3VtZXIuICBUaGUKICAgICAgICAgYnVsa0lkIHNl cnZlcyBhcyBhIHN1cnJvZ2F0ZSBSZXNvdXJjZSBpZCBlbmFibGluZyBDb25zdW1lcnMgdG8KICAg ICAgICAgdW5pcXVlbHkgaWRlbnRpZnkgbmV3bHkgY3JlYXRlZCBSZXNvdXJjZXMgaW4gdGhlIFJl c3BvbnNlIGFuZAogICAgICAgICBjcm9zcyByZWZlcmVuY2UgbmV3IFJlc291cmNlcyBpbiBhbmQg YWNyb3NzIG9wZXJhdGlvbnMgd2l0aGluIGEKICAgICAgICAgYnVsayByZXF1ZXN0LiAgUkVRVUlS RUQgd2hlbiBtZXRob2QgaXMgUE9TVC4KCiAgICAgIHZlcnNpb24gIFRoZSBjdXJyZW50IFJlc291 cmNlIHZlcnNpb24uICBWZXJzaW9uIGlzIFJFUVVJUkVEIGlmIHRoZQogICAgICAgICBTZXJ2aWNl IFByb3ZpZGVyIHN1cHBvcnRzIEVUYWdzIGFuZCB0aGUgbWV0aG9kIGlzIFBVVCwgREVMRVRFLAog ICAgICAgICBvciBQQVRDSC4KCgoKCkRyYWtlLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMg TWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDI2XQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxMgoK CiAgICAgIHBhdGggIFRoZSBSZXNvdXJjZSdzIHJlbGF0aXZlIHBhdGguICBJZiB0aGUgbWV0aG9k IGlzIFBPU1QgdGhlCiAgICAgICAgIHZhbHVlIG11c3Qgc3BlY2lmeSBhIFJlc291cmNlIHR5cGUg ZW5kcG9pbnQ7IGUuZy4sIC9Vc2VycyBvcgogICAgICAgICAvR3JvdXBzIHdoZXJlYXMgYWxsIG90 aGVyIG1ldGhvZCB2YWx1ZXMgbXVzdCBzcGVjaWZ5IHRoZSBwYXRoCiAgICAgICAgIHRvIGEgc3Bl Y2lmaWMgUmVzb3VyY2U7IGUuZy4sIC9Vc2Vycy8KICAgICAgICAgMjgxOWMyMjMtN2Y3Ni00NTNh LTkxOWQtNDEzODYxOTA0NjQ2LiAgUkVRVUlSRUQgaW4gYSByZXF1ZXN0LgoKICAgICAgZGF0YSAg VGhlIFJlc291cmNlIGRhdGEgYXMgaXQgd291bGQgYXBwZWFyIGZvciBhIHNpbmdsZSBQT1NULCBQ VVQKICAgICAgICAgb3IgUEFUQ0ggUmVzb3VyY2Ugb3BlcmF0aW9uLiAgUkVRVUlSRUQgaW4gYSBy ZXF1ZXN0IHdoZW4gbWV0aG9kCiAgICAgICAgIGlzIFBPU1QsIFBVVCBhbmQgUEFUQ0guCgogICAg ICBsb2NhdGlvbiAgVGhlIFJlc291cmNlIGVuZHBvaW50IFVSTC4gIFJFUVVJUkVEIGluIGEgcmVz cG9uc2UsCiAgICAgICAgIGV4Y2VwdCBpbiB0aGUgZXZlbnQgb2YgYSBQT1NUIGZhaWx1cmUuCgog ICAgICBzdGF0dXMgIEEgY29tcGxleCB0eXBlIHRoYXQgY29udGFpbnMgaW5mb3JtYXRpb24gYWJv dXQgdGhlIHN1Y2Nlc3MKICAgICAgICAgb3IgZmFpbHVyZSBvZiBvbmUgb3BlcmF0aW9uIHdpdGhp biB0aGUgYnVsayBqb2IuICBSRVFVSVJFRCBpbiBhCiAgICAgICAgIHJlc3BvbnNlLgoKICAgICAg ICAgY29kZSAgVGhlIEhUVFAgcmVzcG9uc2UgY29kZSB0aGF0IHdvdWxkIGhhdmUgYmVlbiByZXR1 cm5lZCBpZiBhCiAgICAgICAgICAgIGEgc2luZ2xlIEhUVFAgcmVxdWVzdCB3b3VsZCBoYXZlIGJl ZW4gdXNlZC4gIFJFUVVJUkVELgoKICAgICAgICAgZGVzY3JpcHRpb24gIEEgaHVtYW4gcmVhZGFi bGUgZXJyb3IgbWVzc2FnZS4gIFJFUVVJUkVEIHdoZW4gYW4KICAgICAgICAgICAgZXJyb3Igb2Nj dXJyZWQuCgogICBJZiBhIGJ1bGsgam9iIGlzIHByb2Nlc3NlZCBzdWNjZXNzZnVsbHkgdGhlIEhU VFAgcmVzcG9uc2UgY29kZSAyMDAgT0sKICAgTVVTVCBiZSByZXR1cm5lZCwgb3RoZXJ3aXNlIGFu IGFwcHJvcHJpYXRlIEhUVFAgZXJyb3IgY29kZSBNVVNUIGJlCiAgIHJldHVybmVkLgoKICAgVGhl IFNlcnZpY2UgUHJvdmlkZXIgTVVTVCBjb250aW51ZSBwZXJmb3JtaW5nIGFzIG1hbnkgY2hhbmdl cyBhcwogICBwb3NzaWJsZSBhbmQgZGlzcmVnYXJkIHBhcnRpYWwgZmFpbHVyZXMuICBUaGUgQ29u c3VtZXIgTUFZIG92ZXJyaWRlCiAgIHRoaXMgYmVoYXZpb3IgYnkgc3BlY2lmeWluZyBhIHZhbHVl IGZvciBmYWlsT25FcnJvcnMgYXR0cmlidXRlLiAgVGhlCiAgIGZhaWxPbkVycm9ycyBhdHRyaWJ1 dGUgZGVmaW5lcyB0aGUgbnVtYmVyIG9mIGVycm9ycyB0aGF0IHRoZSBTZXJ2aWNlCiAgIFByb3Zp ZGVyIHNob3VsZCBhY2NlcHQgYmVmb3JlIGZhaWxpbmcgdGhlIHJlbWFpbmluZyBvcGVyYXRpb25z CiAgIHJldHVybmluZyB0aGUgcmVzcG9uc2UuCgogICBUbyBiZSBhYmxlIHRvIHJlZmVyZW5jZSBh IG5ld2x5IGNyZWF0ZWQgUmVzb3VyY2UgdGhlIGF0dHJpYnV0ZSBidWxrSWQKICAgTVVTVCBiZSBz cGVjaWZpZWQgd2hlbiBjcmVhdGluZyBuZXcgUmVzb3VyY2VzLiAgVGhlIGJ1bGtJZCBpcyBkZWZp bmVkCiAgIGJ5IHRoZSBDb25zdW1lciBhcyBhIHN1cnJvZ2F0ZSBpZGVudGlmaWVyIGluIGEgUE9T VCBvcGVyYXRpb24uICBUaGUKICAgU2VydmljZSBQcm92aWRlciBNVVNUIHJldHVybiB0aGUgc2Ft ZSBidWxrSWQgdG9nZXRoZXIgd2l0aCB0aGUgbmV3bHkKICAgY3JlYXRlZCBSZXNvdXJjZS4gIFRo ZSBidWxrSWQgY2FuIHRoZW4gYmUgdXNlZCBieSB0aGUgQ29uc3VtZXIgdG8gbWFwCiAgIHRoZSBT ZXJ2aWNlIFByb3ZpZGVyIGlkIHdpdGggdGhlIGJ1bGtJZCBvZiB0aGUgY3JlYXRlZCBSZXNvdXJj ZS4KCiAgIFRoZXJlIGNhbiBiZSBtb3JlIHRoZW4gb25lIG9wZXJhdGlvbiBwZXIgUmVzb3VyY2Ug aW4gZWFjaCBidWxrIGpvYi4KICAgVGhlIFNlcnZpY2UgQ29uc3VtZXIgTVVTVCB0YWtlIG5vdGlj ZSBvZiB0aGUgdW5vcmRlcmVkIHN0cnVjdHVyZSBvZgogICBKU09OIGFuZCB0aGUgU2VydmljZSBQ cm92aWRlciBjYW4gcHJvY2VzcyBvcGVyYXRpb25zIGluIGFueSBvcmRlci4KICAgRm9yIGV4YW1w bGUsIGlmIHRoZSBTZXJ2aWNlIENvbnN1bWVyIHNlbmRzIHR3byBQVVQgb3BlcmF0aW9ucyBpbiBv bmUKICAgcmVxdWVzdCwgdGhlIG91dGNvbWUgaXMgbm9uLWRldGVybWluaXN0aWMuCgogICBUaGUg U2VydmljZSBQcm92aWRlciByZXNwb25zZSBNVVNUIGluY2x1ZGUgdGhlIHJlc3VsdCBvZiBhbGwK CgoKRHJha2UsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAg ICAgICAgICAgW1BhZ2UgMjddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGRyYWZ0LXNj aW0tYXBpLTAxICAgICAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAgcHJvY2Vzc2VkIG9wZXJh dGlvbnMuICBBIGxvY2F0aW9uIGF0dHJpYnV0ZSB0aGF0IGluY2x1ZGVzIHRoZQogICBSZXNvdXJj ZSdzIGVuZCBwb2ludCBNVVNUIGJlIHJldHVybmVkIGZvciBhbGwgb3BlcmF0aW9ucyBleGNsdWRp bmcKICAgZmFpbGVkIFBPU1RzLiAgVGhlIHN0YXR1cyBhdHRyaWJ1dGUgaW5jbHVkZXMgaW5mb3Jt YXRpb24gYWJvdXQgdGhlCiAgIHN1Y2Nlc3Mgb3IgZmFpbHVyZSBvZiBvbmUgb3BlcmF0aW9uIHdp dGhpbiB0aGUgYnVsayBqb2IuICBUaGUKICAgYXR0cmlidXRlIHN0YXR1cyBNVVNUIGluY2x1ZGUg dGhlIGNvZGUgYXR0cmlidXRlIHRoYXQgaG9sZHMgdGhlIEhUVFAKICAgcmVzcG9uc2UgY29kZSB0 aGF0IHdvdWxkIGhhdmUgYmVlbiByZXR1cm5lZCBpZiBhIHNpbmdsZSBIVFRQIHJlcXVlc3QKICAg d291bGQgaGF2ZSBiZWVuIHVzZWQuICBJZiBhbiBlcnJvciBvY2N1cnJlZCB0aGUgc3RhdHVzIE1V U1QgYWxzbwogICBpbmNsdWRlIHRoZSBkZXNjcmlwdGlvbiBhdHRyaWJ1dGUgY29udGFpbmluZyBh IGh1bWFuIHJlYWRhYmxlCiAgIGV4cGxhbmF0aW9uIG9mIHRoZSBlcnJvci4KCgogICAic3RhdHVz IjogewogICAgICJjb2RlIjogIjIwMSIKICAgfQoKICAgVGhlIGZvbGxvd2luZyBpcyBhbiBleGFt cGxlIG9mIGEgc3RhdHVzIGluIGEgZmFpbGVkIG9wZXJhdGlvbi4KCgoic3RhdHVzIjogewogICJj b2RlIjogIjQwMCIsCiAgImRlc2NyaXB0aW9uIjogIlJlcXVlc3QgaXMgdW5wYXJzZWFibGUsIHN5 bnRhY3RpY2FsbHkgaW5jb3JyZWN0LCBvciB2aW9sYXRlcyBzY2hlbWEuIgp9CgogICBUaGUgZm9s bG93aW5nIGV4YW1wbGUgc2hvd3MgaG93IHRvIGFkZCwgdXBkYXRlLCBhbmQgcmVtb3ZlIGEgdXNl ci4KICAgVGhlIGZhaWxPbkVycm9ycyBhdHRyaWJ1dGUgaXMgc2V0IHRvICcxJyBpbmRpY2F0aW5n IHRoZSBTZXJ2aWNlCiAgIFByb3ZpZGVyIHNob3VsZCByZXR1cm4gb24gdGhlIGZpcnN0IGVycm9y LiAgVGhlIFBPU1Qgb3BlcmF0aW9uJ3MKICAgYnVsa0lkIHZhbHVlIGlzIHNldCB0byAncXdlcnR5 JyBlbmFibGluZyB0aGUgQ29uc3VtZXIgdG8gbWF0Y2ggdGhlCiAgIG5ldyBVc2VyIHdpdGggdGhl IHJldHVybmVkIFJlc291cmNlIGlkICc5MmI3MjVjZC05NDY1LTRlN2QtOGMxNi0KICAgMDFmOGUx NDZiODdhJy4KCgogICBQT1NUIC92MS9CdWxrCiAgIEhvc3Q6IGV4YW1wbGUuY29tCiAgIEFjY2Vw dDogYXBwbGljYXRpb24vanNvbgogICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb24KICAg QXV0aG9yaXphdGlvbjogQmVhcmVyIGg0ODBkanM5M2hkOAogICBDb250ZW50LUxlbmd0aDogLi4u CgogICB7CiAgICAgInNjaGVtYXMiOlsKICAgICAgICJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4w IgogICAgIF0sCiAgICAgImZhaWxPbkVycm9ycyI6MSwKICAgICAiT3BlcmF0aW9ucyI6WwogICAg ICAgewogICAgICAgICAibWV0aG9kIjoiUE9TVCIsCiAgICAgICAgICJwYXRoIjoiL1VzZXJzIiwK ICAgICAgICAgImJ1bGtJZCI6InF3ZXJ0eSIsCgoKCkRyYWtlLCBldCBhbC4gICAgICAgICAgICAg IEV4cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDI4XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAgTm92ZW1i ZXIgMjAxMgoKCiAgICAgICAgICJkYXRhIjp7CiAgICAgICAgICAgInNjaGVtYXMiOlsKICAgICAg ICAgICAgICJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4wIgogICAgICAgICAgIF0sCiAgICAgICAg ICAgInVzZXJOYW1lIjoiQWxpY2UiCiAgICAgICAgIH0KICAgICAgIH0sCiAgICAgICB7CiAgICAg ICAgICJtZXRob2QiOiJQVVQiLAogICAgICAgICAicGF0aCI6Ii9Vc2Vycy9iN2MxNDc3MS0yMjZj LTRkMDUtODg2MC0xMzQ3MTE2NTMwNDEiLAogICAgICAgICAidmVyc2lvbiI6IldcL1wiMzY5NGUw NWU5ZGZmNTkxXCIiLAogICAgICAgICAiZGF0YSI6ewogICAgICAgICAgICJzY2hlbWFzIjpbCiAg ICAgICAgICAgICAidXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCIKICAgICAgICAgICBdLAogICAg ICAgICAgICJpZCI6ImI3YzE0NzcxLTIyNmMtNGQwNS04ODYwLTEzNDcxMTY1MzA0MSIsCiAgICAg ICAgICAgInVzZXJOYW1lIjoiQm9iIgogICAgICAgICB9CiAgICAgICB9LAogICAgICAgewogICAg ICAgICAibWV0aG9kIjoiUEFUQ0giLAogICAgICAgICAicGF0aCI6Ii9Vc2Vycy81ZDhkMjlkMy0z NDJjLTRiNWYtODY4My1hM2NiNjc2M2ZmY2MiLAogICAgICAgICAidmVyc2lvbiI6IldcL1wiZWRh YzMyNTNlMmMwZWYyXCIiLAogICAgICAgICAiZGF0YSI6ewogICAgICAgICAgICJzY2hlbWFzIjpb CiAgICAgICAgICAgICAidXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCIKICAgICAgICAgICBdLAog ICAgICAgICAgICJpZCI6IjVkOGQyOWQzLTM0MmMtNGI1Zi04NjgzLWEzY2I2NzYzZmZjYyIsCiAg ICAgICAgICAgInVzZXJOYW1lIjoiRGF2ZSIsCiAgICAgICAgICAgIm1ldGEiOnsKICAgICAgICAg ICAgICJhdHRyaWJ1dGVzIjpbCiAgICAgICAgICAgICAgICJuaWNrTmFtZSIKICAgICAgICAgICAg IF0KICAgICAgICAgICB9CiAgICAgICAgIH0KICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJt ZXRob2QiOiJERUxFVEUiLAogICAgICAgICAicGF0aCI6Ii9Vc2Vycy9lOTAyNTMxNS02YmVhLTQ0 ZTEtODk5Yy0xZTA3NDU0ZTQ2OGIiLAogICAgICAgICAidmVyc2lvbiI6IldcL1wiMGVlOGFkZDBh OTM4ZTFhXCIiCiAgICAgICB9CiAgICAgXQogICB9CgogICBUaGUgU2VydmljZSBQcm92aWRlciBy ZXR1cm5zIHRoZSBmb2xsb3dpbmcgcmVzcG9uc2UuCgoKCgoKCkRyYWtlLCBldCBhbC4gICAgICAg ICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDI5XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAg Tm92ZW1iZXIgMjAxMgoKCkhUVFAvMS4xIDIwMCBPSwpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9u L2pzb24KCnsKICAgICJzY2hlbWFzIjogWwogICAgICAgICJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6 MS4wIgogICAgXSwKICAgICJPcGVyYXRpb25zIjogWwogICAgICAgIHsKICAgICAgICAgICAgImxv Y2F0aW9uIjogImh0dHBzOi8vZXhhbXBsZS5jb20vdjEvVXNlcnMvOTJiNzI1Y2QtOTQ2NS00ZTdk LThjMTYtMDFmOGUxNDZiODdhIiwKICAgICAgICAgICAgIm1ldGhvZCI6ICJQT1NUIiwKICAgICAg ICAgICAgImJ1bGtJZCI6ICJxd2VydHkiLAogICAgICAgICAgICAidmVyc2lvbiI6ICJXXC9cIm9Z NG00d241OHRrVmpKeEtcIiIsCiAgICAgICAgICAgICJzdGF0dXMiOiB7CiAgICAgICAgICAgICAg ICAiY29kZSI6ICIyMDEiCiAgICAgICAgICAgIH0KICAgICAgICB9LAogICAgICAgIHsKICAgICAg ICAgICAgImxvY2F0aW9uIjogImh0dHBzOi8vZXhhbXBsZS5jb20vdjEvVXNlcnMvYjdjMTQ3NzEt MjI2Yy00ZDA1LTg4NjAtMTM0NzExNjUzMDQxIiwKICAgICAgICAgICAgIm1ldGhvZCI6ICJQVVQi LAogICAgICAgICAgICAidmVyc2lvbiI6ICJXXC9cImh1SmoyOWRNTmd1M1dYUERcIiIsCiAgICAg ICAgICAgICJzdGF0dXMiOiB7CiAgICAgICAgICAgICAgICAiY29kZSI6ICIyMDAiCiAgICAgICAg ICAgIH0KICAgICAgICB9LAogICAgICAgIHsKICAgICAgICAgICAgImxvY2F0aW9uIjogImh0dHBz Oi8vZXhhbXBsZS5jb20vdjEvVXNlcnMvNWQ4ZDI5ZDMtMzQyYy00YjVmLTg2ODMtYTNjYjY3NjNm ZmNjIiwKICAgICAgICAgICAgIm1ldGhvZCI6ICJQQVRDSCIsCiAgICAgICAgICAgICJ2ZXJzaW9u IjogIldcL1wiaHVKajI5ZE1OZ3UzV1hQRFwiIiwKICAgICAgICAgICAgInN0YXR1cyI6IHsKICAg ICAgICAgICAgICAgICJjb2RlIjogIjIwMCIKICAgICAgICAgICAgfQogICAgICAgIH0sCiAgICAg ICAgewogICAgICAgICAgICAibG9jYXRpb24iOiAiaHR0cHM6Ly9leGFtcGxlLmNvbS92MS9Vc2Vy cy9lOTAyNTMxNS02YmVhLTQ0ZTEtODk5Yy0xZTA3NDU0ZTQ2OGIiLAogICAgICAgICAgICAibWV0 aG9kIjogIkRFTEVURSIsCiAgICAgICAgICAgICJzdGF0dXMiOiB7CiAgICAgICAgICAgICAgICAi Y29kZSI6ICIyMDAiCiAgICAgICAgICAgIH0KICAgICAgICB9CiAgICBdCn0KCiAgIFRoZSBmb2xs b3dpbmcgcmVzcG9uc2UgaXMgcmV0dXJuZWQgaWYgYW4gZXJyb3Igb2NjdXJyZWQgd2hlbgogICBh dHRlbXB0aW5nIHRvIGNyZWF0ZSB0aGUgVXNlciAnQWxpY2UnLiAgVGhlIFNlcnZpY2UgUHJvdmlk ZXIgc3RvcHMKICAgcHJvY2Vzc2luZyB0aGUgYnVsayBvcGVyYXRpb24gYW5kIGltbWVkaWF0ZWx5 IHJldHVybnMgYSByZXNwb25zZSB0bwogICB0aGUgQ29uc3VtZXIuICBUaGUgcmVzcG9uc2UgY29u dGFpbnMgdGhlIGVycm9yIGFuZCBhbnkgc3VjY2Vzc2Z1bAogICByZXN1bHRzIHByaW9yIHRvIHRo ZSBlcnJvci4KCgoKRHJha2UsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAx MyAgICAgICAgICAgICAgICAgW1BhZ2UgMzBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg IGRyYWZ0LXNjaW0tYXBpLTAxICAgICAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKSFRUUC8xLjEg MjAwIE9LCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbgoKewogICJzY2hlbWFzIjogWwog ICAgInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiCiAgXSwKICAiT3BlcmF0aW9ucyI6IFsKICAg IHsKICAgICAgIm1ldGhvZCI6ICJQT1NUIiwKICAgICAgImJ1bGtJZCI6ICJxd2VydHkiLAogICAg ICAic3RhdHVzIjogewogICAgICAgICJjb2RlIjogIjQwMCIsCiAgICAgICAgImRlc2NyaXB0aW9u IjogIlJlcXVlc3QgaXMgdW5wYXJzZWFibGUsIHN5bnRhY3RpY2FsbHkgaW5jb3JyZWN0LCBvciB2 aW9sYXRlcyBzY2hlbWEuIgogICAgICB9CiAgICB9CiAgXQp9CgogICBJZiB0aGUgZmFpbE9uRXJy b3JzIGF0dHJpYnV0ZSBpcyBub3Qgc3BlY2lmaWVkIG9yIHRoZSBTZXJ2aWNlCiAgIFByb3ZpZGVy IGhhcyBub3QgcmVhY2hlZCB0aGUgZXJyb3IgbGltaXQgZGVmaW5lZCBieSB0aGUgQ29uc3VtZXIg dGhlCiAgIFNlcnZpY2UgUHJvdmlkZXIgd2lsbCBjb250aW51ZSB0byBwcm9jZXNzIGFsbCBvcGVy YXRpb25zLiAgVGhlCiAgIGZvbGxvd2luZyBpcyBhbiBleGFtcGxlIGluIHdoaWNoIGFsbCBvcGVy YXRpb25zIGZhaWxlZC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkRyYWtlLCBldCBhbC4g ICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDMx XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAg ICAgICAgTm92ZW1iZXIgMjAxMgoKCkhUVFAvMS4xIDIwMCBPSwpDb250ZW50LVR5cGU6IGFwcGxp Y2F0aW9uL2pzb24KCnsKICAic2NoZW1hcyI6IFsKICAgICJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6 MS4wIgogIF0sCiAgIk9wZXJhdGlvbnMiOiBbCiAgICB7CiAgICAgICJtZXRob2QiOiAiUE9TVCIs CiAgICAgICJidWxrSWQiOiAicXdlcnR5IiwKICAgICAgInN0YXR1cyI6IHsKICAgICAgICAiY29k ZSI6ICI0MDAiLAogICAgICAgICJkZXNjcmlwdGlvbiI6ICJSZXF1ZXN0IGlzIHVucGFyc2VhYmxl LCBzeW50YWN0aWNhbGx5IGluY29ycmVjdCwgb3IgdmlvbGF0ZXMgc2NoZW1hLiIKICAgICAgfQog ICAgfSwKICAgIHsKICAgICAgImxvY2F0aW9uIjogImh0dHBzOi8vZXhhbXBsZS5jb20vdjEvVXNl cnMvYjdjMTQ3NzEtMjI2Yy00ZDA1LTg4NjAtMTM0NzExNjUzMDQxIiwKICAgICAgIm1ldGhvZCI6 ICJQVVQiLAogICAgICAic3RhdHVzIjogewogICAgICAgICJjb2RlIjogIjQxMiIsCiAgICAgICAg ImRlc2NyaXB0aW9uIjogIkZhaWxlZCB0byB1cGRhdGUgYXMgdXNlciBjaGFuZ2VkIG9uIHRoZSBz ZXJ2ZXIgc2luY2UgeW91IGxhc3QgcmV0cmlldmVkIGl0LiIKICAgICAgfQogICAgfSwKICAgIHsK ICAgICAgImxvY2F0aW9uIjogImh0dHBzOi8vZXhhbXBsZS5jb20vdjEvVXNlcnMvNWQ4ZDI5ZDMt MzQyYy00YjVmLTg2ODMtYTNjYjY3NjNmZmNjIiwKICAgICAgIm1ldGhvZCI6ICJQQVRDSCIsCiAg ICAgICJzdGF0dXMiOiB7CiAgICAgICAgImNvZGUiOiAiNDEyIiwKICAgICAgICAiZGVzY3JpcHRp b24iOiAiRmFpbGVkIHRvIHVwZGF0ZSBhcyB1c2VyIGNoYW5nZWQgb24gdGhlIHNlcnZlciBzaW5j ZSB5b3UgbGFzdCByZXRyaWV2ZWQgaXQuIgogICAgICB9CiAgICB9LAogICAgewogICAgICAibG9j YXRpb24iOiAiaHR0cHM6Ly9leGFtcGxlLmNvbS92MS9Vc2Vycy9lOTAyNTMxNS02YmVhLTQ0ZTEt ODk5Yy0xZTA3NDU0ZTQ2OGIiLAogICAgICAibWV0aG9kIjogIkRFTEVURSIsCiAgICAgICJzdGF0 dXMiOiB7CiAgICAgICAgImNvZGUiOiAiNDA0IiwKICAgICAgICAiZGVzY3JpcHRpb24iOiAiU3Bl Y2lmaWVkIHJlc291cmNlOyBlLmcuLCBVc2VyLCBkb2VzIG5vdCBleGlzdC4iCiAgICAgIH0KICAg IH0KICBdCn0KCiAgIFRoZSBDb25zdW1lciBjYW4sIHdpdGhpbiBvbmUgYnVsayBvcGVyYXRpb24s IGNyZWF0ZSBhIG5ldyBVc2VyLCBhIG5ldwogICBHcm91cCBhbmQgYWRkIHRoZSBuZXdseSBjcmVh dGVkIFVzZXIgdG8gdGhlIG5ld2x5IGNyZWF0ZWQgR3JvdXAuICBJbgogICBvcmRlciB0byBhZGQg dGhlIG5ldyBVc2VyIHRvIHRoZSBHcm91cCB0aGUgQ29uc3VtZXIgbXVzdCB1c2UgdGhlCiAgIHN1 cnJvZ2F0ZSBpZCBhdHRyaWJ1dGUsIGJ1bGtJZCwgdG8gcmVmZXJlbmNlIHRoZSBVc2VyLiAgVGhl IGJ1bGtJZAogICBhdHRyaWJ1dGUgdmFsdWUgbXVzdCBiZSBwcmUtcGVuZGVkIHdpdGggdGhlIGxp dGVyYWwgImJ1bGtJZDoiOyBlLmcuLAoKCgpEcmFrZSwgZXQgYWwuICAgICAgICAgICAgICBFeHBp cmVzIE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAzMl0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgZHJhZnQtc2NpbS1hcGktMDEgICAgICAgICAgICAgIE5vdmVtYmVyIDIw MTIKCgogICBpZiB0aGUgYnVsa0lkIGlzICdxd2VydHknIHRoZSB2YWx1ZSBpcyAiYnVsa0lkOnF3 ZXJ0eSIuICBUaGUgU2VydmljZQogICBQcm92aWRlciBNVVNUIHJlcGxhY2UgdGhlIHN0cmluZyAi YnVsa0lkOnF3ZXJ0eSIgd2l0aCB0aGUgcGVybWFuZW50CiAgIFJlc291cmNlIGlkIG9uY2UgY3Jl YXRlZC4KCiAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBjcmVhdGVzIGEgVXNlciB3aXRoIHRoZSB1 c2VyTmFtZSAnQWxpY2UnIGFuZCBhCiAgIEdyb3VwIHdpdGggdGhlIGRpc3BsYXlOYW1lICdUb3Vy IEd1aWRlcycgd2l0aCBBbGljZSBhcyBhIG1lbWJlci4KCgogICBQT1NUIC92MS9CdWxrCiAgIEhv c3Q6IGV4YW1wbGUuY29tCiAgIEFjY2VwdDogYXBwbGljYXRpb24vanNvbgogICBDb250ZW50LVR5 cGU6IGFwcGxpY2F0aW9uL2pzb24KICAgQXV0aG9yaXphdGlvbjogQmVhcmVyIGg0ODBkanM5M2hk OAogICBDb250ZW50LUxlbmd0aDogLi4uCgogICB7CiAgICAgInNjaGVtYXMiOiBbCiAgICAgICAi dXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCIKICAgICBdLAogICAgICJPcGVyYXRpb25zIjogWwog ICAgICAgewogICAgICAgICAibWV0aG9kIjogIlBPU1QiLAogICAgICAgICAicGF0aCI6ICIvVXNl cnMiLAogICAgICAgICAiYnVsa0lkIjogInF3ZXJ0eSIsCiAgICAgICAgICJkYXRhIjogewogICAg ICAgICAgICJzY2hlbWFzIjogWwogICAgICAgICAgICAgInVybjpzY2ltOnNjaGVtYXM6Y29yZTox LjAiCiAgICAgICAgICAgXSwKICAgICAgICAgICAidXNlck5hbWUiOiAiQWxpY2UiCiAgICAgICAg IH0KICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJtZXRob2QiOiAiUE9TVCIsCiAgICAgICAg ICJwYXRoIjogIi9Hcm91cHMiLAogICAgICAgICAiYnVsa0lkIjogInl0cmV3cSIsCiAgICAgICAg ICJkYXRhIjogewogICAgICAgICAgICJzY2hlbWFzIjogWwogICAgICAgICAgICAgInVybjpzY2lt OnNjaGVtYXM6Y29yZToxLjAiCiAgICAgICAgICAgXSwKICAgICAgICAgICAiZGlzcGxheU5hbWUi OiAiVG91ciBHdWlkZXMiLAogICAgICAgICAgICJtZW1iZXJzIjogWwogICAgICAgICAgICAgewog ICAgICAgICAgICAgICAidHlwZSI6ICJ1c2VyIiwKICAgICAgICAgICAgICAgInZhbHVlIjogImJ1 bGtJZDpxd2VydHkiCiAgICAgICAgICAgICB9CiAgICAgICAgICAgXQogICAgICAgICB9CiAgICAg ICB9CgoKCkRyYWtlLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMgICAg ICAgICAgICAgICAgIFtQYWdlIDMzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBkcmFm dC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxMgoKCiAgICAgXQogICB9Cgog ICBUaGUgU2VydmljZSBQcm92aWRlciByZXR1cm5zIHRoZSBmb2xsb3dpbmcgcmVzcG9uc2UuCgoK SFRUUC8xLjEgMjAwIE9LCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbgoKewogICJzY2hl bWFzIjogWwogICAgInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiCiAgXSwKICAiT3BlcmF0aW9u cyI6IFsKICAgIHsKICAgICAgImxvY2F0aW9uIjogImh0dHBzOi8vZXhhbXBsZS5jb20vdjEvVXNl cnMvOTJiNzI1Y2QtOTQ2NS00ZTdkLThjMTYtMDFmOGUxNDZiODdhIiwKICAgICAgIm1ldGhvZCI6 ICJQT1NUIiwKICAgICAgImJ1bGtJZCI6ICJxd2VydHkiLAogICAgICAidmVyc2lvbiI6ICJXXC9c IjR3ZXltckVzaDVPNmNBRUtcIiIsCiAgICAgICJzdGF0dXMiOiB7CiAgICAgICAgImNvZGUiOiAi MjAxIgogICAgICB9CiAgICB9LAogICAgewogICAgICAibG9jYXRpb24iOiAiaHR0cHM6Ly9leGFt cGxlLmNvbS92MS9Hcm91cHMvZTllMzBkYmEtZjA4Zi00MTA5LTg0ODYtZDVjNmEzMzE2NjBhIiwK ICAgICAgIm1ldGhvZCI6ICJQT1NUIiwKICAgICAgImJ1bGtJZCI6ICJ5dHJld3EiLAogICAgICAi dmVyc2lvbiI6ICJXXC9cImxoYTViYmF6VTNmTnZmZTVcIiIsCiAgICAgICJzdGF0dXMiOiB7CiAg ICAgICAgImNvZGUiOiAiMjAxIgogICAgICB9CiAgICB9CiAgXQp9CgogICBBIHN1YnNlcXVlbnQg cmVxdWVzdCBmb3IgdGhlICdUb3VyIEd1aWRlcycgR3JvdXAgKCdlOWUzMGRiYS1mMDhmLQogICA0 MTA5LTg0ODYtZDVjNmEzMzE2NjBhJykgcmV0dXJucyB0aGUgZm9sbG93aW5nOgoKCiAgIEdFVCAv djEvR3JvdXBzL2U5ZTMwZGJhLWYwOGYtNDEwOS04NDg2LWQ1YzZhMzMxNjYwYQogICBIb3N0OiBl eGFtcGxlLmNvbQogICBBY2NlcHQ6IGFwcGxpY2F0aW9uL2pzb24KICAgQXV0aG9yaXphdGlvbjog QmVhcmVyIGg0ODBkanM5M2hkOAoKCgoKCgoKCkRyYWtlLCBldCBhbC4gICAgICAgICAgICAgIEV4 cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDM0XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAgTm92ZW1iZXIg MjAxMgoKCkhUVFAvMS4xIDIwMCBPSwpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb24KTG9j YXRpb246IGh0dHBzOi8vZXhhbXBsZS5jb20vdjEvR3JvdXBzL2U5ZTMwZGJhLWYwOGYtNDEwOS04 NDg2LWQ1YzZhMzMxNjYwYQpFVGFnOiBXLyJsaGE1YmJhelUzZk52ZmU1IgoKewogICJzY2hlbWFz IjpbInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiXSwKICAiaWQiOiAiZTllMzBkYmEtZjA4Zi00 MTA5LTg0ODYtZDVjNmEzMzE2NjBhIiwKICAiZGlzcGxheU5hbWUiOiAiVG91ciBHdWlkZXMiLAog ICJtZXRhIjogewogICAgImNyZWF0ZWQiOiIyMDExLTA4LTAxVDE4OjI5OjQ5Ljc5M1oiLAogICAg Imxhc3RNb2RpZmllZCI6IjIwMTEtMDgtMDFUMjA6MzE6MDIuMzE1WiIsCiAgICAibG9jYXRpb24i OiAiaHR0cHM6Ly9leGFtcGxlLmNvbS92MS9Hcm91cHMvZTllMzBkYmEtZjA4Zi00MTA5LTg0ODYt ZDVjNmEzMzE2NjBhIiwKICAgICJ2ZXJzaW9uIjogIldcL1wibGhhNWJiYXpVM2ZOdmZlNVwiIgog IH0sCiAgIm1lbWJlcnMiOiBbCiAgICB7CiAgICAgICJ2YWx1ZSI6ICI5MmI3MjVjZC05NDY1LTRl N2QtOGMxNi0wMWY4ZTE0NmI4N2EiLAogICAgICAidHlwZSI6ICJ1c2VyIgogICAgfQogIF0KfQoK ICAgRXh0ZW5zaW9ucyB0aGF0IGluY2x1ZGUgcmVmZXJlbmNlcyB0byBvdGhlciBSZXNvdXJjZXMg TVVTVCBiZSBoYW5kbGVkCiAgIGluIHRoZSBzYW1lIHdheSBieSB0aGUgU2VydmljZSBQcm92aWRl ci4gIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSB1c2VzCiAgIHRoZSBidWxrSWQgYXR0cmlidXRlIHdp dGhpbiB0aGUgZW50ZXJwcmlzZSBleHRlbnNpb24gbWFuYWdlcklkCiAgIGF0dHJpYnV0ZS4KCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKRHJha2UsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBN YXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgMzVdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGRyYWZ0LXNjaW0tYXBpLTAxICAgICAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoK ICAgUE9TVCAvdjEvQnVsawogICBIb3N0OiBleGFtcGxlLmNvbQogICBBY2NlcHQ6IGFwcGxpY2F0 aW9uL2pzb24KICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uCiAgIEF1dGhvcml6YXRp b246IEJlYXJlciBoNDgwZGpzOTNoZDgKICAgQ29udGVudC1MZW5ndGg6IC4uLgoKICAgewogICAg ICJzY2hlbWFzIjogWwogICAgICAgInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiCiAgICAgXSwK ICAgICAiT3BlcmF0aW9ucyI6IFsKICAgICAgIHsKICAgICAgICAgIm1ldGhvZCI6ICJQT1NUIiwK ICAgICAgICAgInBhdGgiOiAiL1VzZXJzIiwKICAgICAgICAgImJ1bGtJZCI6ICJxd2VydHkiLAog ICAgICAgICAiZGF0YSI6IHsKICAgICAgICAgICAic2NoZW1hcyI6IFsKICAgICAgICAgICAgICJ1 cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4wIgogICAgICAgICAgIF0sCiAgICAgICAgICAgInVzZXJO YW1lIjogIkFsaWNlIgogICAgICAgICB9CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibWV0 aG9kIjogIlBPU1QiLAogICAgICAgICAicGF0aCI6ICIvVXNlcnMiLAogICAgICAgICAiYnVsa0lk IjogInl0cmV3cSIsCiAgICAgICAgICJkYXRhIjogewogICAgICAgICAgICJzY2hlbWFzIjogWwog ICAgICAgICAgICAgInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiLAogICAgICAgICAgICAgInVy bjpzY2ltOnNjaGVtYXM6ZXh0ZW5zaW9uOmVudGVycHJpc2U6MS4wIgogICAgICAgICAgIF0sCiAg ICAgICAgICAgInVzZXJOYW1lIjogIkJvYiIsCiAgICAgICAgICAgInVybjpzY2ltOnNjaGVtYXM6 ZXh0ZW5zaW9uOmVudGVycHJpc2U6MS4wIjogewogICAgICAgICAgICAgImVtcGxveWVlTnVtYmVy IjogIjExMjUwIiwKICAgICAgICAgICAgICJtYW5hZ2VyIjogewogICAgICAgICAgICAgICAibWFu YWdlcklkIjogImJhdGNoSWQ6cXdlcnR5IiwKICAgICAgICAgICAgICAgImRpc3BsYXlOYW1lIjog IkFsaWNlIgogICAgICAgICAgICAgfQogICAgICAgICAgIH0KICAgICAgICAgfQogICAgICAgfQog ICAgIF0KICAgfQoKICAgVGhlIFNlcnZpY2UgUHJvdmlkZXIgTVVTVCB0cnkgdG8gcmVzb2x2ZSBj aXJjdWxhciBjcm9zcyByZWZlcmVuY2VzCiAgIGJldHdlZW4gUmVzb3VyY2VzIGluIGEgc2luZ2xl IGJ1bGsgam9iIGJ1dCBNQVkgc3RvcCBhZnRlciBhIGZhaWxlZAogICBhdHRlbXB0IGFuZCBpbnN0 ZWFkIHJldHVybiB0aGUgc3RhdHVzIGNvZGUgNDA5IENvbmZsaWN0LiAgVGhlCgoKCkRyYWtlLCBl dCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQ YWdlIDM2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAg ICAgICAgICAgICAgTm92ZW1iZXIgMjAxMgoKCiAgIGZvbGxvd2luZyBleGFtcGxlIGV4aGliaXRz IHRoZSBwb3RlbnRpYWwgY29uZmxpY3QuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKRHJha2UsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkg NSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgMzddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGRyYWZ0LXNjaW0tYXBpLTAxICAgICAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAg UE9TVCAvdjEvQnVsawogICBIb3N0OiBleGFtcGxlLmNvbQogICBBY2NlcHQ6IGFwcGxpY2F0aW9u L2pzb24KICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uCiAgIEF1dGhvcml6YXRpb246 IEJlYXJlciBoNDgwZGpzOTNoZDgKICAgQ29udGVudC1MZW5ndGg6IC4uLgoKICAgewogICAgICJz Y2hlbWFzIjogWwogICAgICAgInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiCiAgICAgXSwKICAg ICAiT3BlcmF0aW9ucyI6IFsKICAgICAgIHsKICAgICAgICAgIm1ldGhvZCI6ICJQT1NUIiwKICAg ICAgICAgInBhdGgiOiAiL0dyb3VwcyIsCiAgICAgICAgICJidWxrSWQiOiAicXdlcnR5IiwKICAg ICAgICAgImRhdGEiOiB7CiAgICAgICAgICAgInNjaGVtYXMiOiBbCiAgICAgICAgICAgICAidXJu OnNjaW06c2NoZW1hczpjb3JlOjEuMCIKICAgICAgICAgICBdLAogICAgICAgICAgICJkaXNwbGF5 TmFtZSI6ICJHcm91cCBBIiwKICAgICAgICAgICAibWVtYmVycyI6IFsKICAgICAgICAgICAgIHsK ICAgICAgICAgICAgICAgInR5cGUiOiAiZ3JvdXAiLAogICAgICAgICAgICAgICAidmFsdWUiOiAi YnVsa0lkOnl0cmV3cSIKICAgICAgICAgICAgIH0KICAgICAgICAgICBdCiAgICAgICAgIH0KICAg ICAgIH0sCiAgICAgICB7CiAgICAgICAgICJtZXRob2QiOiAiUE9TVCIsCiAgICAgICAgICJwYXRo IjogIi9Hcm91cHMiLAogICAgICAgICAiYnVsa0lkIjogInl0cmV3cSIsCiAgICAgICAgICJkYXRh IjogewogICAgICAgICAgICJzY2hlbWFzIjogWwogICAgICAgICAgICAgInVybjpzY2ltOnNjaGVt YXM6Y29yZToxLjAiCiAgICAgICAgICAgXSwKICAgICAgICAgICAiZGlzcGxheU5hbWUiOiAiR3Jv dXAgQiIsCiAgICAgICAgICAgIm1lbWJlcnMiOiBbCiAgICAgICAgICAgICB7CiAgICAgICAgICAg ICAgICJ0eXBlIjogImdyb3VwIiwKICAgICAgICAgICAgICAgInZhbHVlIjogImJ1bGtJZDpxd2Vy dHkiCiAgICAgICAgICAgICB9CiAgICAgICAgICAgXQogICAgICAgICB9CiAgICAgICB9CiAgICAg XQogICB9CgoKCkRyYWtlLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMg ICAgICAgICAgICAgICAgIFtQYWdlIDM4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBk cmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxMgoKCiAgIElmIHRoZSBT ZXJ2aWNlIFByb3ZpZGVyIHJlc29sdmVkIHRoZSBhYm92ZSBjaXJjdWxhciByZWZlcmVuY2VzIHRo ZQogICBmb2xsb3dpbmcgaXMgcmV0dXJuZWQgZnJvbSBhIHN1YnNlcXVlbnQgR0VUIHJlcXVlc3Qu CgoKICAgR0VUIC92MS9Hcm91cHM/ZmlsdGVyPWRpc3BsYXlOYW1lIHN3ICdHcm91cCcKICAgSG9z dDogZXhhbXBsZS5jb20KICAgQWNjZXB0OiBhcHBsaWNhdGlvbi9qc29uCiAgIEF1dGhvcml6YXRp b246IEJlYXJlciBoNDgwZGpzOTNoZDgKCgoKSFRUUC8xLjEgMjAwIE9LCkNvbnRlbnQtVHlwZTog YXBwbGljYXRpb24vanNvbgoKewogICJ0b3RhbFJlc3VsdHMiOiAyLAogICJzY2hlbWFzIjogWwog ICAgInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiCiAgXSwKICAiUmVzb3VyY2VzIjogWwogICAg ewogICAgICAiaWQiOiAiYzNhMjZkZDMtMjdhMC00ZGVjLWEyYWMtY2UyMTFlMTA1Zjk3IiwKICAg ICAgInNjaGVtYXMiOiBbCiAgICAgICAgInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiCiAgICAg IF0sCiAgICAgICJkaXNwbGF5TmFtZSI6ICJHcm91cCBBIiwKICAgICAgIm1ldGEiOiB7CiAgICAg ICAgImNyZWF0ZWQiOiIyMDExLTA4LTAxVDE4OjI5OjQ5Ljc5M1oiLAogICAgICAgICJsYXN0TW9k aWZpZWQiOiIyMDExLTA4LTAxVDE4OjI5OjUxLjEzNVoiLAogICAgICAgICJsb2NhdGlvbiI6Imh0 dHBzOi8vZXhhbXBsZS5jb20vdjEvR3JvdXBzL2MzYTI2ZGQzLTI3YTAtNGRlYy1hMmFjLWNlMjEx ZTEwNWY5NyIsCiAgICAgICAgInZlcnNpb24iOiJXXC9cIm12d05HYXhCNVNEcTA3NHBcIiIKICAg ICAgfSwKICAgICAgIm1lbWJlcnMiOiBbCiAgICAgICAgewogICAgICAgICAgInZhbHVlIjogIjZj NWJiNDY4LTE0YjItNDE4My1iYWYyLTA2ZDUyM2UwM2JkMyIsCiAgICAgICAgICAidHlwZSI6ICJn cm91cCIKICAgICAgICB9CiAgICAgIF0KICAgIH0sCiAgICB7CiAgICAgICJpZCI6ICI2YzViYjQ2 OC0xNGIyLTQxODMtYmFmMi0wNmQ1MjNlMDNiZDMiLAogICAgICAic2NoZW1hcyI6IFsKICAgICAg ICAidXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCIKICAgICAgXSwKICAgICAgImRpc3BsYXlOYW1l IjogIkdyb3VwIEIiLAogICAgICAibWV0YSI6IHsKICAgICAgICAiY3JlYXRlZCI6IjIwMTEtMDgt MDFUMTg6Mjk6NTAuODczWiIsCiAgICAgICAgImxhc3RNb2RpZmllZCI6IjIwMTEtMDgtMDFUMTg6 Mjk6NTAuODczWiIsCgoKCkRyYWtlLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDUs IDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDM5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxMgoKCiAgICAg ICAgImxvY2F0aW9uIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS92MS9Hcm91cHMvNmM1YmI0NjgtMTRi Mi00MTgzLWJhZjItMDZkNTIzZTAzYmQzIiwKICAgICAgICAidmVyc2lvbiI6IldcL1wid0dCODVz MlFKTWppTm51SVwiIgogICAgICB9LAogICAgICAibWVtYmVycyI6IFsKICAgICAgICB7CiAgICAg ICAgICAidmFsdWUiOiAiYzNhMjZkZDMtMjdhMC00ZGVjLWEyYWMtY2UyMTFlMTA1Zjk3IiwKICAg ICAgICAgICJ0eXBlIjogImdyb3VwIgogICAgICAgIH0KICAgICAgXQogICAgfQogIF0KfQoKICAg VGhlIFNlcnZpY2UgUHJvdmlkZXIgTVVTVCBkZWZpbmUgdGhlIG1heGltdW0gbnVtYmVyIG9mIG9w ZXJhdGlvbnMgYW5kCiAgIG1heGltdW0gcGF5bG9hZCBzaXplIGEgQ29uc3VtZXIgbWF5IHNlbmQg aW4gYSBzaW5nbGUgcmVxdWVzdC4gIElmCiAgIGVpdGhlciBsaW1pdHMgYXJlIGV4Y2VlZGVkIHRo ZSBTZXJ2aWNlIFByb3ZpZGVyIE1VU1QgcmV0dXJuIHRoZSBIVFRQCiAgIHJlc3BvbnNlIGNvZGUg NDEzIFJlcXVlc3QgRW50aXR5IFRvbyBMYXJnZS4gIFRoZSByZXR1cm5lZCByZXNwb25zZQogICBN VVNUIHNwZWNpZnkgdGhlIGxpbWl0IGV4Y2VlZGVkIGluIHRoZSBib2R5IG9mIHRoZSBlcnJvciBy ZXNwb25zZS4KCiAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSB0aGUgQ29uc3VtZXIgc2VudCBhIHJl cXVlc3QgZXhjZWVkaW5nIHRoZQogICBTZXJ2aWNlIFByb3ZpZGVyJ3MgbWF4IHBheWxvYWQgc2l6 ZSBvZiAxIG1lZ2FieXRlLgoKCiAgIFBPU1QgL3YxL0J1bGsKICAgSG9zdDogZXhhbXBsZS5jb20K ICAgQWNjZXB0OiBhcHBsaWNhdGlvbi9qc29uCiAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24v anNvbgogICBBdXRob3JpemF0aW9uOiBCZWFyZXIgaDQ4MGRqczkzaGQ4CiAgIENvbnRlbnQtTGVu Z3RoOiA0Mjk0OTY3Mjk2CgogICAuLi4KCgpIVFRQLzEuMSA0MTMgUmVxdWVzdCBFbnRpdHkgVG9v IExhcmdlCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbgpMb2NhdGlvbjogaHR0cHM6Ly9l eGFtcGxlLmNvbS92MS9CdWxrL3lmQ3JWSmhGSUphZ0FIajgKCnsKICAiRXJyb3JzIjpbCiAgICB7 CiAgICAgICJkZXNjcmlwdGlvbiI6IlRoZSBzaXplIG9mIHRoZSBidWxrIG9wZXJhdGlvbiBleGNl ZWRzIHRoZSBtYXhQYXlsb2FkU2l6ZSAoMTA0ODU3NikuIiwKICAgICAgImNvZGUiOiI0MTMiCiAg ICB9CiAgXQp9CgoKCgoKCkRyYWtlLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDUs IDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDQwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxMgoKCjMuNi4g IERhdGEgSW5wdXQvT3V0cHV0IEZvcm1hdHMKCiAgIENvbnN1bWVycyBNVVNUIHNwZWNpZnkgdGhl IGZvcm1hdCBpbiB3aGljaCB0aGUgZGF0YSBpcyBzdWJtaXR0ZWQgdmlhCiAgIHRoZSBIVFRQIGhl YWRlciBjb250ZW50LXR5cGUgYW5kIE1BWSBzcGVjaWZ5IHRoZSBkZXNpcmVkIHJlc3BvbnNlCiAg IGRhdGEgZm9ybWF0IHZpYSBhbiBIVFRQIEFjY2VwdCBIZWFkZXI7IGUuZy4sIkFjY2VwdDogYXBw bGljYXRpb24vCiAgIGpzb24iIG9yIHZpYSBVUkkgc3VmZml4OyBlLmcuLAoKCiAgIEdFVCAvVXNl cnMvMjgxOWMyMjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2Lmpzb24KICAgSG9zdDogZXhh bXBsZS5jb20KCiAgIFNlcnZpY2UgUHJvdmlkZXJzIE1VU1Qgc3VwcG9ydCB0aGUgQWNjZXB0IEhl YWRlcnMgIkFjY2VwdDoKICAgYXBwbGljYXRpb24vanNvbiIgZm9yIEpTT04gWzVdLiAgVGhlIGZv cm1hdCBkZWZhdWx0cyB0byBKU09OIGlmIG5vCiAgIGZvcm1hdCBpcyBzcGVjaWZpZWQuCgogICBT aW5ndWxhciBhdHRyaWJ1dGVzIGFyZSBlbmNvZGVkIGFzIHN0cmluZyBuYW1lLXZhbHVlLXBhaXJz IGluIEpTT047CiAgIGUuZy4sCgogICAiYXR0cmlidXRlIjogInZhbHVlIgoKICAgTXVsdGktdmFs dWVkIGF0dHJpYnV0ZXMgaW4gSlNPTiBhcmUgZW5jb2RlZCBhcyBhcnJheXM7IGUuZy4sCgogICAi YXR0cmlidXRlcyI6IFsgInZhbHVlMSIsICJ2YWx1ZTIiIF0KCiAgIEVsZW1lbnRzIHdpdGggbmVz dGVkIGVsZW1lbnRzIGFyZSByZXByZXNlbnRlZCBhcyBvYmplY3RzIGluIEpTT047CiAgIGUuZywK CiAgICJhdHRyaWJ1dGUiOiB7ICJzdWJhdHRyaWJ1dGUxIjogInZhbHVlMSIsICJzdWJhdHRyaWJ1 dGUyIjogInZhbHVlMiIgfQoKMy43LiAgQWRkaXRpb25hbCByZXRyaWV2YWwgcXVlcnkgcGFyYW1l dGVycwoKICAgQ29uc3VtZXJzIE1BWSByZXF1ZXN0IGEgcGFydGlhbCBSZXNvdXJjZSByZXByZXNl bnRhdGlvbiBvbiBhbnkKICAgb3BlcmF0aW9uIHRoYXQgcmV0dXJucyBhIFJlc291cmNlIHdpdGhp biB0aGUgcmVzcG9uc2UgYnkgc3BlY2lmeWluZwogICB0aGUgVVJMIHF1ZXJ5IHBhcmFtZXRlciAn YXR0cmlidXRlcycuICBXaGVuIHNwZWNpZmllZCwgZWFjaCBSZXNvdXJjZQogICByZXR1cm5lZCBN VVNUIGNvbnRhaW4gdGhlIG1pbmltYWwgc2V0IG9mIFJlc291cmNlIGF0dHJpYnV0ZXMgYW5kLAog ICBNVVNUIGNvbnRhaW4gbm8gb3RoZXIgYXR0cmlidXRlcyBvciBTdWItQXR0cmlidXRlcyB0aGFu IHRob3NlCiAgIGV4cGxpY2l0bHkgcmVxdWVzdGVkLiAgVGhlIHF1ZXJ5IHBhcmFtZXRlciBhdHRy aWJ1dGVzIHZhbHVlIGlzIGEKICAgY29tbWEgc2VwYXJhdGVkIGxpc3Qgb2YgUmVzb3VyY2UgYXR0 cmlidXRlIG5hbWVzIGluIHN0YW5kYXJkLAogICBhdHRyaWJ1dGUgbm90YXRpb24gKFNlY3Rpb24g My44KSBmb3JtIChlLmcuIHVzZXJOYW1lLCBuYW1lLCBlbWFpbHMpLgoKICAgR0VUIC9Vc2Vycy8y ODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5MDQ2NDY/YXR0cmlidXRlcz11c2VyTmFtZQog ICBIb3N0OiBleGFtcGxlLmNvbQogICBBY2NlcHQ6IGFwcGxpY2F0aW9uL2pzb24KICAgQXV0aG9y aXphdGlvbjogQmVhcmVyIGg0ODBkanM5M2hkOAoKCiAgIEdpdmluZyB0aGUgcmVzcG9uc2UKCgoK CkRyYWtlLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAg ICAgICAgIFtQYWdlIDQxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBkcmFmdC1zY2lt LWFwaS0wMSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxMgoKCkhUVFAvMS4xIDIwMCBPSwpDb250 ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb24KTG9jYXRpb246IGh0dHBzOi8vZXhhbXBsZS5jb20v djEvVXNlcnMvMjgxOWMyMjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2CkVUYWc6IFcvImEz MzBiYzU0ZjA2NzFjOSIKCnsKICAic2NoZW1hcyI6WyJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4w Il0sCiAgImlkIjoiMjgxOWMyMjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2IiwKICAidXNl ck5hbWUiOiJiamVuc2VuIiwKICAibWV0YSI6ewogICAgImNyZWF0ZWQiOiIyMDExLTA4LTAxVDE4 OjI5OjQ5Ljc5M1oiLAogICAgImxhc3RNb2RpZmllZCI6IjIwMTEtMDgtMDFUMTg6Mjk6NDkuNzkz WiIsCiAgICAibG9jYXRpb24iOiJodHRwczovL2V4YW1wbGUuY29tL3YxL1VzZXJzLzI4MTljMjIz LTdmNzYtNDUzYS05MTlkLTQxMzg2MTkwNDY0NiIsCiAgICAidmVyc2lvbiI6IldcL1wiYTMzMGJj NTRmMDY3MWM5XCIiCiAgfQp9CgoKMy44LiAgQXR0cmlidXRlIE5vdGF0aW9uCgogICBBbGwgb3Bl cmF0aW9ucyBzaGFyZSBhIGNvbW1vbiBzY2hlbWUgZm9yIHJlZmVyZW5jaW5nIHNpbXBsZSBhbmQK ICAgY29tcGxleCBhdHRyaWJ1dGVzLiAgSW4gZ2VuZXJhbCwgYXR0cmlidXRlcyBhcmUgaWRlbnRp ZmllZCBieQogICBwcmVmaXhpbmcgdGhlIGF0dHJpYnV0ZSBuYW1lIHdpdGggaXRzIHNjaGVtYSBV Uk4gc2VwYXJhdGVkIGJ5IGEgJzonCiAgIGNoYXJhY3RlcjsgZS5nLiwgdGhlIGNvcmUgVXNlciBS ZXNvdXJjZSBhdHRyaWJ1dGUgJ3VzZXJOYW1lJyBpcwogICBpZGVudGlmaWVkIGFzICd1cm46c2Np bTpzY2hlbWFzOmNvcmU6MS4wOnVzZXJOYW1lJy4gIENvbnN1bWVycyBNQVkKICAgb21pdCBjb3Jl IHNjaGVtYSBhdHRyaWJ1dGUgVVJOIHByZWZpeGVzIHRob3VnaCBNVVNUIGZ1bGx5IHF1YWxpZnkK ICAgZXh0ZW5kZWQgYXR0cmlidXRlcyB3aXRoIHRoZSBhc3NvY2lhdGVkIFJlc291cmNlIFVSTjsg ZS5nLiwgdGhlCiAgIGF0dHJpYnV0ZSAnYWdlJyBkZWZpbmVkIGluICd1cm46aHI6c2NoZW1hczp1 c2VyJyBpcyBmdWxseSBlbmNvZGVkIGFzCiAgICd1cm46aHI6c2NoZW1hczp1c2VyOmFnZScuICBB IENvbXBsZXggYXR0cmlidXRlcycgU3ViLUF0dHJpYnV0ZXMgYXJlCiAgIHJlZmVyZW5jZWQgdmlh IG5lc3RlZCwgZG90ICgnLicpIG5vdGF0aW9uOyBpLmUuLCB7dXJufTp7QXR0cmlidXRlCiAgIG5h bWV9LntTdWItQXR0cmlidXRlIG5hbWV9LiAgRm9yIGV4YW1wbGUsIHRoZSBmdWxseSBxdWFsaWZp ZWQgcGF0aAogICBmb3IgYSBVc2VyJ3MgZ2l2ZW5OYW1lIGlzIHVybjpzY2ltOnNjaGVtYXM6Y29y ZToxLjA6bmFtZS5naXZlbk5hbWUKICAgQWxsIGZhY2V0cyAoVVJOLCBhdHRyaWJ1dGUgYW5kIFN1 Yi1BdHRyaWJ1dGUgbmFtZSkgb2YgdGhlIGZ1bGx5CiAgIGVuY29kZWQgQXR0cmlidXRlIG5hbWUg YXJlIGNhc2UgaW5zZW5zaXRpdmUuCgozLjkuICBIVFRQIFJlc3BvbnNlIENvZGVzCgogICBUaGUg U0NJTSBQcm90b2NvbCB1c2VzIHRoZSByZXNwb25zZSBzdGF0dXMgY29kZXMgZGVmaW5lZCBpbiBI VFRQIFs2XQogICB0byBpbmRpY2F0ZSBvcGVyYXRpb24gc3VjY2VzcyBvciBmYWlsdXJlLiAgSW4g YWRkaXRpb24gdG8gcmV0dXJuaW5nIGEKICAgSFRUUCByZXNwb25zZSBjb2RlIGltcGxlbWVudGVy cyBNVVNUIHJldHVybiB0aGUgZXJyb3JzIGluIHRoZSBib2R5IG9mCiAgIHRoZSByZXNwb25zZSBp biB0aGUgY2xpZW50IHJlcXVlc3RlZCBmb3JtYXQgY29udGFpbmluZyB0aGUgZXJyb3IKICAgcmVz cG9uc2UgYW5kLCBwZXIgdGhlIEhUVFAgc3BlY2lmaWNhdGlvbiwgaHVtYW4tcmVhZGFibGUKICAg ZXhwbGFuYXRpb25zLiAgSW1wbGVtZW50ZXJzIFNIT1VMRCBoYW5kbGUgdGhlIGlkZW50aWZpZWQg ZXJyb3JzIGFzCiAgIGRlc2NyaWJlZCBiZWxvdy4KCgoKCgoKCkRyYWtlLCBldCBhbC4gICAgICAg ICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDQyXQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBkcmFmdC1zY2ltLWFwaS0wMSAgICAgICAgICAgICAg Tm92ZW1iZXIgMjAxMgoKCiAgICstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8IENvZGUgICAgICAgICB8IEFwcGxp Y2FiaWxpdHkgICAgICAgICAgICAgfCBTdWdnZXN0ZWQgRXhwbGFuYXRpb24gIHwKICAgKy0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rCiAgIHwgNDAwIEJBRCAgICAgIHwgR0VULFBPU1QsUFVULFBBVENILERFTEVURSB8IFJl cXVlc3QgaXMgICAgICAgICAgICAgfAogICB8IFJFUVVFU1QgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCB1bnBhcnNlYWJsZSwgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgc3ludGFjdGljYWxseSAgICAgICAgICB8CiAg IHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8IGluY29ycmVjdCwg b3IgdmlvbGF0ZXMgfAogICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCBzY2hlbWEgICAgICAgICAgICAgICAgIHwKICAgfCA0MDEgICAgICAgICAgfCBHRVQsUE9T VCxQVVQsUEFUQ0gsREVMRVRFIHwgQXV0aG9yaXphdGlvbiBmYWlsdXJlICB8CiAgIHwgVU5BVVRI T1JJWkVEIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgfAogICB8IDQwMyAgICAgICAgICB8IEdFVCxQT1NULFBVVCxQQVRDSCxERUxFVEUgfCBTZXJ2 ZXIgZG9lcyBub3QgICAgICAgIHwKICAgfCBGT1JCSURERU4gICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgc3VwcG9ydCByZXF1ZXN0ZWQgICAgICB8CiAgIHwgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IG9wZXJhdGlvbiAgICAgICAgICAgICAgfAogICB8 IDQwNCBOT1QgICAgICB8IEdFVCxQVVQsUEFUQ0gsREVMRVRFICAgICAgfCBTcGVjaWZpZWQgcmVz b3VyY2U7ICAgIHwKICAgfCBGT1VORCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgZS5nLiwgVXNlciwgZG9lcyBub3QgICB8CiAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICB8IGV4aXN0ICAgICAgICAgICAgICAgICAgfAogICB8IDQwOSBDT05G TElDVCB8IFBPU1QsIFBVVCxQQVRDSCxERUxFVEUgICAgfCBUaGUgc3BlY2lmaWVkIHZlcnNpb24g IHwKICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgbnVtYmVy IGRvZXMgbm90IG1hdGNoICB8CiAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICB8IHRoZSByZXNvdXJjZSdzIGxhdGVzdCAgfAogICB8ICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCB2ZXJzaW9uIG51bWJlciBvciBhICAgIHwKICAgfCAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgU2VydmljZSBQcm92aWRl ciAgICAgICB8CiAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8 IHJlZnVzZWQgdG8gY3JlYXRlIGEgICAgfAogICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCBuZXcsIGR1cGxpY2F0ZSAgICAgICAgIHwKICAgfCAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgcmVzb3VyY2UgICAgICAgICAgICAgICB8 CiAgIHwgNDEyICAgICAgICAgIHwgUFVULFBBVENILERFTEVURSAgICAgICAgICB8IEZhaWxlZCB0 byB1cGRhdGUgYXMgICAgfAogICB8IFBSRUNPTkRJVElPTiB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCBSZXNvdXJjZSB7aWR9IGNoYW5nZWQgIHwKICAgfCBGQUlMRUQgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgb24gdGhlIHNlcnZlciBsYXN0ICAgICB8CiAgIHwgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHJldHJpZXZlZCAgICAgICAg ICAgICAgfAogICB8IDQxMyBSRVFVRVNUICB8IFBPU1QgICAgICAgICAgICAgICAgICAgICAgfCB7 Im1heE9wZXJhdGlvbnMiOiAgICAgIHwKICAgfCBFTlRJVFkgVE9PICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgMTAwMCwibWF4UGF5bG9hZCI6ICAgICB8CiAgIHwgTEFSR0UgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8IDEwNDg1NzZ9ICAgICAgICAgICAgICAgfAog ICB8IDUwMCBJTlRFUk5BTCB8IEdFVCxQT1NULFBVVCxQQVRDSCxERUxFVEUgfCBBbiBpbnRlcm5h bCBlcnJvci4gICAgIHwKICAgfCBTRVJWRVIgRVJST1IgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgSW1wbGVtZW50ZXJzIFNIT1VMRCAgICB8CiAgIHwgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICB8IHByb3ZpZGUgZGVzY3JpcHRpdmUgICAgfAogICB8ICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBkZWJ1Z2dpbmcgYWR2aWNlICAg ICAgIHwKICAgfCA1MDEgTk9UICAgICAgfCBHRVQsUE9TVCxQVVQsUEFUQ0gsREVMRVRFIHwgU2Vy dmljZSBQcm92aWRlciBkb2VzICB8CiAgIHwgSU1QTEVNRU5URUQgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICB8IG5vdCBzdXBwb3J0IHRoZSAgICAgICAgfAogICB8ICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCByZXF1ZXN0IG9wZXJhdGlvbjsgICAgIHwKICAg fCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgZS5nLiwgUEFUQ0gg ICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgICAgICAgICAgICAgICAgICAgICBUYWJs ZSA3OiBEZWZpbmVkIGVycm9yIGNhc2VzCgogICBFcnJvciBleGFtcGxlIGluIHJlc3BvbnNlIHRv IGEgbm9uLWV4aXN0ZW50IEdFVCByZXF1ZXN0LgoKCgoKCgoKRHJha2UsIGV0IGFsLiAgICAgICAg ICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgNDNdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGRyYWZ0LXNjaW0tYXBpLTAxICAgICAgICAgICAgICBO b3ZlbWJlciAyMDEyCgoKSFRUUC8xLjEgNDA0IE5PVCBGT1VORAoKewogICJFcnJvcnMiOlsKICAg IHsKICAgICAgImRlc2NyaXB0aW9uIjoiUmVzb3VyY2UgMjgxOWMyMjMtN2Y3Ni00NTNhLTkxOWQt NDEzODYxOTA0NjQ2IG5vdCBmb3VuZCIsCiAgICAgICJjb2RlIjoiNDA0IgogICAgfQogIF0KfQoK My4xMC4gIEFQSSBWZXJzaW9uaW5nCgogICBUaGUgQmFzZSBVUkwgTUFZIGJlIGFwcGVuZGVkIHdp dGggYSB2ZXJzaW9uIGlkZW50aWZpZXIgYXMgYSBzZXBhcmF0ZQogICBzZWdtZW50IGluIHRoZSBV UkwgcGF0aC4gIEF0IHRoaXMgdGltZSB0aGUgb25seSB2YWxpZCBpZGVudGlmaWVyIGlzCiAgICd2 MScuICBJZiBzcGVjaWZpZWQsIHRoZSB2ZXJzaW9uIGlkZW50aWZpZXIgTVVTVCBhcHBlYXIgaW4g dGhlIFVSTAogICBwYXRoIGltbWVkaWF0ZWx5IHByZWNlZGluZyB0aGUgUmVzb3VyY2UgZW5kcG9p bnQgYW5kIGNvbmZvcm0gdG8gdGhlCiAgIGZvbGxvd2luZyBzY2hlbWU6IHRoZSBjaGFyYWN0ZXIg J3YnIGZvbGxvd2VkIGJ5IHRoZSBkZXNpcmVkIFNDSU0KICAgdmVyc2lvbiBudW1iZXI7IGUuZy4s IGEgdmVyc2lvbiAndjEnIFVzZXIgcmVxdWVzdCBpcyBzcGVjaWZpZWQgYXMKICAgL3YxL1VzZXJz LiAgV2hlbiBzcGVjaWZpZWQgU2VydmljZSBQcm92aWRlcnMgTVVTVCBwZXJmb3JtIHRoZQogICBv cGVyYXRpb24gdXNpbmcgdGhlIGRlc2lyZWQgdmVyc2lvbiBvciByZWplY3QgdGhlIHJlcXVlc3Qu ICBXaGVuCiAgIG9taXR0ZWQgU2VydmljZSBQcm92aWRlcnMgU0hPVUxEIHBlcmZvcm0gdGhlIG9w ZXJhdGlvbiB1c2luZyB0aGUgbW9zdAogICByZWNlbnQgQVBJIHN1cHBvcnRlZCBieSB0aGUgU2Vy dmljZSBQcm92aWRlci4KCjMuMTEuICBWZXJzaW9uaW5nIFJlc291cmNlcwoKICAgVGhlIEFQSSBz dXBwb3J0cyByZXNvdXJjZSB2ZXJzaW9uaW5nIHZpYSBzdGFuZGFyZCxIVFRQIEVUYWdzLgogICBT ZXJ2aWNlIHByb3ZpZGVycyBNQVkgc3VwcG9ydCB3ZWFrIEVUYWdzIGFzIHRoZSBwcmVmZXJyZWQg bWVjaGFuaXNtCiAgIGZvciBwZXJmb3JtaW5nIGNvbmRpdGlvbmFsIHJldHJpZXZhbHMgYW5kIGVu c3VyaW5nIENvbnN1bWVycyBkbyBub3QKICAgaW5hZHZlcnRlbnRseSBvdmVyd3JpdGUgZWFjaCBv dGhlcnMgY2hhbmdlcywgcmVzcGVjdGl2ZWx5LiAgV2hlbgogICBzdXBwb3J0ZWQgU0NJTSBFVGFn cyBNVVNUIGJlIHNwZWNpZmllZCBhcyBhbiBIVFRQIGhlYWRlciBhbmQgU0hPVUxECiAgIGJlIHNw ZWNpZmllZCB3aXRoaW4gdGhlICd2ZXJzaW9uJyBhdHRyaWJ1dGUgY29udGFpbmVkIGluIHRoZQog ICBSZXNvdXJjZSdzICdtZXRhJyBhdHRyaWJ1dGUuCgogICBFeGFtcGxlOgoKCgoKCgoKCgoKCgoK CgoKRHJha2UsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAg ICAgICAgICAgW1BhZ2UgNDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGRyYWZ0LXNj aW0tYXBpLTAxICAgICAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAgUE9TVCAvVXNlcnMgIEhU VFAvMS4xCiAgIEhvc3Q6IGV4YW1wbGUuY29tCiAgIENvbnRlbnQtVHlwZTogIGFwcGxpY2F0aW9u L2pzb24KICAgQXV0aG9yaXphdGlvbjogQmVhcmVyIGg0ODBkanM5M2hkOAogICBDb250ZW50LUxl bmd0aDogLi4uCgogICB7CiAgICAgInNjaGVtYXMiOlsidXJuOnNjaW06c2NoZW1hczpjb3JlOjEu MCJdLAogICAgICJ1c2VyTmFtZSI6ImJqZW5zZW4iLAogICAgICJleHRlcm5hbElkIjoiYmplbnNl biIsCiAgICAgIm5hbWUiOnsKICAgICAgICJmb3JtYXR0ZWQiOiJNcy4gQmFyYmFyYSBKIEplbnNl biBJSUkiLAogICAgICAgImZhbWlseU5hbWUiOiJKZW5zZW4iLAogICAgICAgImdpdmVuTmFtZSI6 IkJhcmJhcmEiCiAgICAgfQogICB9CgogICBUaGUgc2VydmVyIHJlc3BvbmRzIHdpdGggYW4gRVRh ZyBpbiB0aGUgcmVzcG9uc2UgaGVhZGVyIGFuZCBtZXRhCiAgIHN0cnVjdHVyZS4KCkhUVFAvMS4x IDIwMSBDcmVhdGVkCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbgpMb2NhdGlvbjogaHR0 cHM6Ly9leGFtcGxlLmNvbS92MS9Vc2Vycy8yODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5 MDQ2NDYKRVRhZzogVy8iZTE4MGVlODRmMDY3MWIxIgoKewogICJzY2hlbWFzIjpbInVybjpzY2lt OnNjaGVtYXM6Y29yZToxLjAiXSwKICAiaWQiOiIyODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4 NjE5MDQ2NDYiLAogICJtZXRhIjp7CiAgICAiY3JlYXRlZCI6IjIwMTEtMDgtMDFUMjE6MzI6NDQu ODgyWiIsCiAgICAibGFzdE1vZGlmaWVkIjoiMjAxMS0wOC0wMVQyMTozMjo0NC44ODJaIiwKICAg ICJsb2NhdGlvbiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vdjEvVXNlcnMvMjgxOWMyMjMtN2Y3Ni00 NTNhLTkxOWQtNDEzODYxOTA0NjQ2IiwKICAgICJ2ZXJzaW9uIjoiV1wvXCJlMTgwZWU4NGYwNjcx YjFcIiIKICB9LAogICJuYW1lIjp7CiAgICAiZm9ybWF0dGVkIjoiTXMuIEJhcmJhcmEgSiBKZW5z ZW4gSUlJIiwKICAgICJmYW1pbHlOYW1lIjoiSmVuc2VuIiwKICAgICJnaXZlbk5hbWUiOiJCYXJi YXJhIgogIH0sCiAgInVzZXJOYW1lIjoiYmplbnNlbiIKfQoKICAgV2l0aCB0aGUgcmV0dXJuZWQg RVRhZywgQ29uc3VtZXJzIE1BWSBjaG9vc2UgdG8gcmV0cmlldmUgdGhlIFJlc291cmNlCiAgIG9u bHkgaWYgdGhlIFJlc291cmNlIGhhcyBiZWVuIG1vZGlmaWVkLgoKICAgQ29uZGl0aW9uYWwgcmV0 cmlldmFsIGV4YW1wbGUgdXNpbmcgSWYtTm9uZS1NYXRjaCBoZWFkZXI6CgoKCgoKRHJha2UsIGV0 IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1Bh Z2UgNDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGRyYWZ0LXNjaW0tYXBpLTAxICAg ICAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICBHRVQgL1VzZXJzLzI4MTljMjIzLTdmNzYtNDUz YS05MTlkLTQxMzg2MTkwNDY0Nj9hdHRyaWJ1dGVzPWRpc3BsYXlOYW1lCiAgSG9zdDogZXhhbXBs ZS5jb20KICBBY2NlcHQ6IGFwcGxpY2F0aW9uL2pzb24KICBBdXRob3JpemF0aW9uOiBCZWFyZXIg aDQ4MGRqczkzaGQ4CiAgSWYtTm9uZS1NYXRjaDogVy8iZTE4MGVlODRmMDY3MWIxIgoKCiAgIElm IHRoZSBSZXNvdXJjZSBoYXMgbm90IGNoYW5nZWQgdGhlIFNlcnZpY2UgUHJvdmlkZXIgc2ltcGx5 IHJldHVybnMKICAgYW4gZW1wdHkgYm9keSB3aXRoIGEgMzA0ICJOb3QgTW9kaWZpZWQiIHJlc3Bv bnNlIGNvZGUuCgogICBJZiB0aGUgU2VydmljZSBQcm92aWRlcnMgc3VwcG9ydHMgdmVyc2lvbmlu ZyBvZiByZXNvdXJjZXMgdGhlCiAgIENvbnN1bWVyIE1VU1Qgc3VwcGx5IGFuIElmLU1hdGNoIGhl YWRlciBmb3IgUFVUIGFuZCBQQVRDSCBvcGVyYXRpb25zCiAgIHRvIGVuc3VyZSB0aGF0IHRoZSBy ZXF1ZXN0ZWQgb3BlcmF0aW9uIHN1Y2NlZWRzIG9ubHkgaWYgdGhlIHN1cHBsaWVkCiAgIEVUYWcg bWF0Y2hlcyB0aGUgbGF0ZXN0IFNlcnZpY2UgUHJvdmlkZXIgUmVzb3VyY2U7IGUuZy4sIElmLU1h dGNoOgogICBXLyJlMTgwZWU4NGYwNjcxYjEiCgozLjEyLiAgSFRUUCBNZXRob2QgT3ZlcmxvYWRp bmcKCiAgIEluIHJlY29nbml0aW9uIHRoYXQgc29tZSBjbGllbnRzLCBzZXJ2ZXJzIGFuZCBmaXJl d2FsbHMgcHJldmVudCBQVVQsCiAgIFBBVENIIGFuZCBERUxFVEUgb3BlcmF0aW9ucyBhIGNsaWVu dCBNQVkgb3ZlcnJpZGUgdGhlIFBPU1Qgb3BlcmF0aW9uCiAgIGJ5IHNwZWNpZnlpbmcgdGhlIGN1 c3RvbSBoZWFkZXIgIlgtSFRUUC1NZXRob2QtT3ZlcnJpZGUiIHdpdGggdGhlCiAgIGRlc2lyZWQg UFVULCBQQVRDSCwgREVMRVRFIG9wZXJhdGlvbi4gIEZvciBleGFtcGxlOgoKCiAgIFBPU1QgL1Vz ZXJzLzI4MTljMjIzLTdmNzYtNDUzYS05MTlkLTQxMzg2MTkwNDY0NgogICBYLUhUVFAtTWV0aG9k LU92ZXJyaWRlOiBERUxFVEUKCgo0LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRoZSBT Q0lNIFByb3RvY29sIGlzIGJhc2VkIG9uIEhUVFAgYW5kIHRodXMgc3ViamVjdCB0byB0aGUgc2Vj dXJpdHkKICAgY29uc2lkZXJhdGlvbnMgZm91bmQgaW4gU2VjdGlvbiAxNSBvZiBbUkZDMjYxNl0u ICBTQ0lNIFJlc291cmNlcwogICAoZS5nLiwgVXNlcnMgYW5kIEdyb3VwcykgY2FuIGNvbnRhaW4g c2Vuc2l0aXZlIGluZm9ybWF0aW9uLgogICBUaGVyZWZvcmUsIFNDSU0gQ29uc3VtZXJzIGFuZCBT ZXJ2aWNlIFByb3ZpZGVycyBNVVNUIGltcGxlbWVudCBUTFMuCiAgIFdoaWNoIHZlcnNpb24ocykg b3VnaHQgdG8gYmUgaW1wbGVtZW50ZWQgd2lsbCB2YXJ5IG92ZXIgdGltZSwgYW5kCiAgIGRlcGVu ZCBvbiB0aGUgd2lkZXNwcmVhZCBkZXBsb3ltZW50IGFuZCBrbm93biBzZWN1cml0eQogICB2dWxu ZXJhYmlsaXRpZXMgYXQgdGhlIHRpbWUgb2YgaW1wbGVtZW50YXRpb24uICBBdCB0aGUgdGltZSBv ZiB0aGlzCiAgIHdyaXRpbmcsIFRMUyB2ZXJzaW9uIDEuMiBbUkZDNTI0NiBbN11dIGlzIHRoZSBt b3N0IHJlY2VudCB2ZXJzaW9uLAogICBidXQgaGFzIHZlcnkgbGltaXRlZCBhY3R1YWwgZGVwbG95 bWVudCwgYW5kIG1pZ2h0IG5vdCBiZSByZWFkaWx5CiAgIGF2YWlsYWJsZSBpbiBpbXBsZW1lbnRh dGlvbiB0b29sa2l0cy4gIFRMUyB2ZXJzaW9uIDEuMCBbUkZDMjI0NiBbN11dCiAgIGlzIHRoZSBt b3N0IHdpZGVseSBkZXBsb3llZCB2ZXJzaW9uLCBhbmQgd2lsbCBnaXZlIHRoZSBicm9hZGVzdAog ICBpbnRlcm9wZXJhYmlsaXR5LgoKCjUuICBDb250cmlidXRvcnMKCgoKCgoKRHJha2UsIGV0IGFs LiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2Ug NDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGRyYWZ0LXNjaW0tYXBpLTAxICAgICAg ICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAgICAgU2FtdWVsIEVyZHRtYW4gKHNhbXVlbEBlcmR0 bWFuLnNlKQoKICAgICAgUGF0cmljayBIYXJkaW5nIChwaGFyZGluZ0BwaW5naWRlbnRpdHkuY29t KQoKCjYuICBBY2tub3dsZWRnbWVudHMKCiAgIFRoZSBlZGl0b3Igd291bGQgbGlrZSB0byB0aGFu ayB0aGUgcGFydGljaXBhbnRzIGluIHRoZSB0aGUgU0NJTQogICB3b3JraW5nIGdyb3VwIGZvciB0 aGVpciBzdXBwb3J0IG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4KCgpBdXRob3JzJyBBZGRyZXNzZXMK CiAgIFRyZXkgRHJha2UgKGVkaXRvcikKICAgVW5ib3VuZElECgogICBFbWFpbDogdHJleS5kcmFr ZUB1bmJvdW5kaWQuY29tCgoKICAgQ2h1Y2sgTW9ydGltb3JlCiAgIFNhbGVzRm9yY2UKCiAgIEVt YWlsOiBjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tCgoKICAgTW9ydGV6YSBBbnNhcmkKICAgQ2lz Y28KCiAgIEVtYWlsOiBtb3J0ZXphLmFuc2FyaUBjaXNjby5jb20KCgogICBLZWxseSBHcml6emxl CiAgIFNhaWxQb2ludAoKICAgRW1haWw6IGtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbQoKCiAg IEVyaWsgV2FobHN0cm9lbQogICBUZWNobm9sb2d5IE5leHVzCgogICBFbWFpbDogZXJpay53YWhs c3Ryb21AbmV4dXNzYWZlLmNvbQoKCgoKCgoKCgoKRHJha2UsIGV0IGFsLiAgICAgICAgICAgICAg RXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgNDddCgwK --_003_56C3C758F9D6534CA3778EAA1E0C34373E7F2E20BY2PRD0410MB354_ Content-Type: text/plain; name="draft-ietf-scim-core-schema-01.txt" Content-Description: draft-ietf-scim-core-schema-01.txt Content-Disposition: attachment; filename="draft-ietf-scim-core-schema-01.txt"; size=63199; creation-date="Fri, 02 Nov 2012 16:16:31 GMT"; modification-date="Fri, 02 Nov 2012 16:16:32 GMT" Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEMuIE1vcnRpbW9yZSwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgU2FsZXNmb3JjZQpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFAuIEhhcmRpbmcKRXhwaXJl czogTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg UC4gTWFkc2VuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgUGluZwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gRHJha2UKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVW5ib3VuZElE CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Tm92ZW1iZXIgMSwgMjAxMgoKCiAgICAgICAgU3lzdGVtIGZvciBDcm9zcy1Eb21haW4gSWRlbnRp dHkgTWFuYWdlbWVudDogQ29yZSBTY2hlbWEKICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0 Zi1zY2ltLWNvcmUtc2NoZW1hLTAxCgpBYnN0cmFjdAoKICAgVGhlIFN5c3RlbSBmb3IgQ3Jvc3Mt RG9tYWluIElkZW50aXR5IE1hbmFnZW1lbnQgKFNDSU0pIHNwZWNpZmljYXRpb24KICAgaXMgZGVz aWduZWQgdG8gbWFrZSBtYW5hZ2luZyB1c2VyIGlkZW50aXR5IGluIGNsb3VkIGJhc2VkCiAgIGFw cGxpY2F0aW9ucyBhbmQgc2VydmljZXMgZWFzaWVyLiAgVGhlIHNwZWNpZmljYXRpb24gc3VpdGUg YnVpbGRzCiAgIHVwb24gZXhwZXJpZW5jZSB3aXRoIGV4aXN0aW5nIHNjaGVtYXMgYW5kIGRlcGxv eW1lbnRzLCBwbGFjaW5nCiAgIHNwZWNpZmljIGVtcGhhc2lzIG9uIHNpbXBsaWNpdHkgb2YgZGV2 ZWxvcG1lbnQgYW5kIGludGVncmF0aW9uLCB3aGlsZQogICBhcHBseWluZyBleGlzdGluZyBhdXRo ZW50aWNhdGlvbiwgYXV0aG9yaXphdGlvbiwgYW5kIHByaXZhY3kgbW9kZWxzLgogICBJdHMgaW50 ZW50IGlzIHRvIHJlZHVjZSB0aGUgY29zdCBhbmQgY29tcGxleGl0eSBvZiB1c2VyIG1hbmFnZW1l bnQKICAgb3BlcmF0aW9ucyBieSBwcm92aWRpbmcgYSBjb21tb24gdXNlciBzY2hlbWEgYW5kIGV4 dGVuc2lvbiBtb2RlbCwgYXMKICAgd2VsbCBhcyBiaW5kaW5nIGRvY3VtZW50cyB0byBwcm92aWRl IHBhdHRlcm5zIGZvciBleGNoYW5naW5nIHRoaXMKICAgc2NoZW1hIHVzaW5nIHN0YW5kYXJkIHBy b3RvY29scy4gIEluIGVzc2VuY2UsIG1ha2UgaXQgZmFzdCwgY2hlYXAsCiAgIGFuZCBlYXN5IHRv IG1vdmUgaWRlbnRpdHkgaW4gdG8sIG91dCBvZiwgYW5kIGFyb3VuZCB0aGUgY2xvdWQuCgogICBU aGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgcGxhdGZvcm0gbmV1dHJhbCBzY2hlbWEgYW5kIGV4dGVu c2lvbiBtb2RlbAogICBmb3IgcmVwcmVzZW50aW5nIHVzZXJzIGFuZCBncm91cHMgaW4gSlNPTiBm b3JtYXQuICBUaGlzIHNjaGVtYSBpcwogICBpbnRlbmRlZCBmb3IgZXhjaGFuZ2UgYW5kIHVzZSB3 aXRoIGNsb3VkIHNlcnZpY2UgcHJvdmlkZXJzLgogICBBZGRpdGlvbmFsIGJpbmRpbmcgZG9jdW1l bnRzIHByb3ZpZGUgYSBzdGFuZGFyZCBSRVNUIEFQSSwgU0FNTAogICBiaW5kaW5nLCBhbmQgdXNl IGNhc2VzLgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBz dWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJD UCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50 cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3Rl IHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVu dHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAg RHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8u CgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhp bXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jz b2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3Ig dG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKCgoKTW9ydGlt b3JlLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAg IFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgZHJhZnQtc2NpbS1jb3JlLXNjaGVt YS0wMSAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxs IGV4cGlyZSBvbiBNYXkgNSwgMjAxMy4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAo YykgMjAxMiBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBk b2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQg aXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlz aW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5v cmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24g b2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVm dWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGgg cmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBm cm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2Ug dGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2FsIFBy b3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJl ZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgpNb3J0aW1vcmUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIE1heSA1LCAyMDEz ICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBkcmFm dC1zY2ltLWNvcmUtc2NoZW1hLTAxICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgpUYWJsZSBvZiBD b250ZW50cwoKICAgMS4gIFJlcXVpcmVtZW50cyBOb3RhdGlvbiBhbmQgQ29udmVudGlvbnMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgIDIuICBPdmVydmlldyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAgIDIuMS4gIERlZmlu aXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQK ICAgMy4gIFNDSU0gU2NoZW1hIFN0cnVjdHVyZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA1CiAgICAgMy4xLiAgQXR0cmlidXRlIERhdGEgVHlwZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgICAgMy4xLjEuICBTdHJpbmcgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYKICAgICAgIDMu MS4yLiAgQm9vbGVhbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA2CiAgICAgICAzLjEuMy4gIERlY2ltYWwgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAgICAgMy4xLjQuICBJbnRlZ2VyICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYKICAgICAgIDMuMS41LiAgRGF0 ZVRpbWUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2CiAg ICAgICAzLjEuNi4gIEJpbmFyeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgNgogICAgICAgMy4xLjcuICBDb21wbGV4ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAgICAzLjIuICBNdWx0aS12YWx1ZWQgQXR0 cmlidXRlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgIDQuICBTY2hl bWEgRXh0ZW5zaW9uIE1vZGVsIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgOAogICA1LiAgU0NJTSBDb3JlIFNjaGVtYSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgICA1LjEuICBDb21tb24gU2NoZW1hIEF0dHJpYnV0ZXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4CiAgICAgNS4yLiAgInNjaGVtYXMi IEF0dHJpYnV0ZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICA2 LiAgU0NJTSBVc2VyIFNjaGVtYSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTAKICAgICA2LjEuICBTaW5ndWxhciBBdHRyaWJ1dGVzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgICAgNi4yLiAgTXVsdGktdmFsdWVkIEF0dHJp YnV0ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMgogICA3LiAgU0NJTSBF bnRlcnByaXNlIFVzZXIgU2NoZW1hIEV4dGVuc2lvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTQKICAgOC4gIFNDSU0gR3JvdXAgU2NoZW1hICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDE1CiAgIDkuICBTZXJ2aWNlIFByb3ZpZGVyIENvbmZpZ3VyYXRpb24g U2NoZW1hICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQogICAxMC4gUmVzb3VyY2UgU2NoZW1h ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcKICAgMTEu IEpTT04gUmVwcmVzZW50YXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDE5CiAgICAgMTEuMS4gTWluaW1hbCBVc2VyIFJlcHJlc2VudGF0aW9uICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQogICAgIDExLjIuIEZ1bGwgVXNlciBSZXByZXNlbnRh dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkKICAgICAxMS4zLiBFbnRl cnByaXNlIFVzZXIgRXh0ZW5zaW9uIFJlcHJlc2VudGF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIDIy CiAgICAgMTEuNC4gR3JvdXAgUmVwcmVzZW50YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAyNQogICAgIDExLjUuIFNlcnZpY2UgUHJvdmlkZXIgQ29uZmlndXJhdGlv biBSZXByZXNlbnRhdGlvbiAgLiAuIC4gLiAuIC4gMjUKICAgICAxMS42LiBSZXNvdXJjZSBTY2hl bWEgUmVwcmVzZW50YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3CiAgIDEyLiBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAzMQogICBBcHBlbmRpeCBBLiAgQ29udHJpYnV0b3JzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMzEKICAgMTMuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMyCiAgIEF1dGhvcnMnIEFkZHJl c3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMgoK CgoKCgoKCgoKCgoKCk1vcnRpbW9yZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIw MTMgICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIGRy YWZ0LXNjaW0tY29yZS1zY2hlbWEtMDEgICAgICAgICAgTm92ZW1iZXIgMjAxMgoKCjEuICBSZXF1 aXJlbWVudHMgTm90YXRpb24gYW5kIENvbnZlbnRpb25zCgogICBUaGUga2V5IHdvcmRzICJNVVNU IiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9V TEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBp biB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4g W1JGQzIxMTldIC4KCiAgIFRocm91Z2hvdXQgdGhpcyBkb2N1bWVudCwgdmFsdWVzIGFyZSBxdW90 ZWQgdG8gaW5kaWNhdGUgdGhhdCB0aGV5IGFyZQogICB0byBiZSB0YWtlbiBsaXRlcmFsbHkuICBX aGVuIHVzaW5nIHRoZXNlIHZhbHVlcyBpbiBwcm90b2NvbCBtZXNzYWdlcywKICAgdGhlIHF1b3Rl cyBNVVNUIE5PVCBiZSB1c2VkIGFzIHBhcnQgb2YgdGhlIHZhbHVlLgoKCjIuICBPdmVydmlldwoK ICAgV2hpbGUgdGhlcmUgYXJlIGV4aXN0aW5nIHN0YW5kYXJkcyBmb3IgZGVzY3JpYmluZyBhbmQg ZXhjaGFuZ2luZyB1c2VyCiAgIGluZm9ybWF0aW9uLCBtYW55IG9mIHRoZXNlIHN0YW5kYXJkcyBj YW4gYmUgZGlmZmljdWx0IHRvIGltcGxlbWVudAogICBhbmQvb3IgdXNlOyBlLmcuLCB0aGVpciB3 aXJlIHByb3RvY29scyBkbyBub3QgZWFzaWx5IHRyYXZlcnNlCiAgIGZpcmV3YWxscyBhbmQvb3Ig YXJlIG5vdCBlYXNpbHkgbGF5ZXJlZCBvbnRvIGV4aXN0aW5nIHdlYiBwcm90b2NvbHMuCiAgIEFz IGEgcmVzdWx0LCBtYW55IGNsb3VkIHByb3ZpZGVycyBpbXBsZW1lbnQgbm9uLXN0YW5kYXJkIEFQ SXMgZm9yCiAgIG1hbmFnaW5nIHVzZXJzIHdpdGhpbiB0aGVpciBzZXJ2aWNlcy4gIFRoaXMgaW5j cmVhc2VzIGJvdGggdGhlIGNvc3QKICAgYW5kIGNvbXBsZXhpdHkgYXNzb2NpYXRlZCB3aXRoIG9y Z2FuaXphdGlvbnMgYWRvcHRpbmcgcHJvZHVjdHMgYW5kCiAgIHNlcnZpY2VzIGZyb20gbXVsdGlw bGUgY2xvdWQgcHJvdmlkZXJzIGFzIHRoZXkgbXVzdCBwZXJmb3JtIHJlZHVuZGFudAogICBpbnRl Z3JhdGlvbiBkZXZlbG9wbWVudC4gIFNpbWlsYXJseSwgY2xvdWQgc2VydmljZXMgcHJvdmlkZXJz IHNlZWtpbmcKICAgdG8gaW50ZXJvcGVyYXRlIHdpdGggbXVsdGlwbGUgYXBwbGljYXRpb24gbWFy a2V0cGxhY2VzIG9yIGNsb3VkCiAgIGlkZW50aXR5IHByb3ZpZGVycyBtdXN0IGJlIHJlZHVuZGFu dGx5IGludGVncmF0ZWQuCgogICBTQ0lNIHNlZWtzIHRvIHNpbXBsaWZ5IHRoaXMgcHJvYmxlbSB0 aHJvdWdoIGEgc2ltcGxlIHRvIGltcGxlbWVudAogICBzcGVjaWZpY2F0aW9uIHN1aXRlIHRoYXQg cHJvdmlkZXMgYSBjb21tb24gdXNlciBzY2hlbWEgYW5kIGV4dGVuc2lvbgogICBtb2RlbCwgYXMg d2VsbCBhcyBiaW5kaW5nIGRvY3VtZW50cyB0byBwcm92aWRlIHBhdHRlcm5zIGZvcgogICBleGNo YW5naW5nIHRoaXMgc2NoZW1hIHZpYSBhIFJFU1QgQVBJLiAgSXQgZHJhd3MgaW5zcGlyYXRpb24g YW5kIGJlc3QKICAgcHJhY3RpY2UsIGJ1aWxkaW5nIHVwb24gZXhpc3RpbmcgdXNlciBBUElzIGFu ZCBzY2hlbWFzIGZyb20gYSB3aWRlCiAgIHZhcmlldHkgb2Ygc291cmNlcyBpbmNsdWRpbmcsIGJ1 dCBub3QgbGltaXRlZCB0bywgZXhpc3RpbmcgQVBJcwogICBleHBvc2VkIGJ5IGNsb3VkIHByb3Zp ZGVycywgUG9ydGFibGVDb250YWN0cywgYW5kIExEQVAgZGlyZWN0b3J5CiAgIHNlcnZpY2VzLgoK ICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIHBsYXRmb3JtIG5ldXRyYWwgc2NoZW1hIGFuZCBl eHRlbnNpb24gbW9kZWwKICAgZm9yIHJlcHJlc2VudGluZyB1c2VycyBhbmQgZ3JvdXBzIGluIEpT T04gZm9ybWF0LiAgVGhpcyBzY2hlbWEgaXMKICAgaW50ZW5kZWQgZm9yIGV4Y2hhbmdlIGFuZCB1 c2Ugd2l0aCBjbG91ZCBzZXJ2aWNlIHByb3ZpZGVycy4KICAgQWRkaXRpb25hbCBiaW5kaW5nIGRv Y3VtZW50cyBwcm92aWRlIGEgc3RhbmRhcmQgUkVTVCBBUEksIFNBTUwKICAgYmluZGluZywgYW5k IHVzZSBjYXNlcy4KCjIuMS4gIERlZmluaXRpb25zCgogICBTZXJ2aWNlIFByb3ZpZGVyOiAgQSB3 ZWIgYXBwbGljYXRpb24gdGhhdCBwcm92aWRlcyBpZGVudGl0eQogICAgICBpbmZvcm1hdGlvbiB2 aWEgdGhlIFNDSU0gcHJvdG9jb2wuCgoKCgoKCgpNb3J0aW1vcmUsIGV0IGFsLiAgICAgICAgICBF eHBpcmVzIE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICBkcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAxICAgICAgICAgIE5vdmVtYmVy IDIwMTIKCgogICBDb25zdW1lcjogIEEgd2Vic2l0ZSBvciBhcHBsaWNhdGlvbiB0aGF0IHVzZXMg dGhlIFNDSU0gcHJvdG9jb2wgdG8KICAgICAgbWFuYWdlIGlkZW50aXR5IGRhdGEgbWFpbnRhaW5l ZCBieSB0aGUgU2VydmljZSBQcm92aWRlci4KCiAgIFJlc291cmNlOiAgVGhlIFNlcnZpY2UgUHJv dmlkZXIgbWFuYWdlZCBhcnRpZmFjdCBjb250YWluaW5nIG9uZSBvcgogICAgICBtb3JlIGF0dHJp YnV0ZXM7IGUuZy4sIFVzZXIgb3IgR3JvdXAKCiAgIFNpbmd1bGFyIEF0dHJpYnV0ZTogIEEgUmVz b3VyY2UgYXR0cmlidXRlIHRoYXQgY29udGFpbnMgMC4uMSB2YWx1ZXM7CiAgICAgIGUuZy4sIGRp c3BsYXlOYW1lLgoKICAgTXVsdGktdmFsdWVkIEF0dHJpYnV0ZTogIEEgUmVzb3VyY2UgYXR0cmli dXRlIHRoYXQgY29udGFpbnMgMC4ubgogICAgICB2YWx1ZXM7IGUuZy4sIGVtYWlscy4KCiAgIFNp bXBsZSBBdHRyaWJ1dGU6ICBBIFNpbmd1bGFyIG9yIE11bHRpLXZhbHVlZCBBdHRyaWJ1dGUgd2hv c2UgdmFsdWUKICAgICAgaXMgYSBwcmltaXRpdmU7IGUuZy4sIFN0cmluZy4KCiAgIENvbXBsZXgg QXR0cmlidXRlOiAgQSBTaW5ndWxhciBvciBNdWx0aS12YWx1ZWQgQXR0cmlidXRlIHdob3NlIHZh bHVlCiAgICAgIGlzIGEgY29tcG9zaXRpb24gb2Ygb25lIG9yIG1vcmUgU2ltcGxlIEF0dHJpYnV0 ZXMuCgogICBTdWItQXR0cmlidXRlOiAgQSBTaW1wbGUgQXR0cmlidXRlIGNvbnRhaW5lZCB3aXRo aW4gYSBDb21wbGV4CiAgICAgIEF0dHJpYnV0ZS4KCgozLiAgU0NJTSBTY2hlbWEgU3RydWN0dXJl CgogICBTQ0lNIHNjaGVtYSBwcm92aWRlcyBhIG1pbmltYWwgY29yZSBzY2hlbWEgZm9yIHJlcHJl c2VudGluZyB1c2VycyBhbmQKICAgZ3JvdXBzIChyZXNvdXJjZXMpLCBlbmNvbXBhc3NpbmcgY29t bW9uIGF0dHJpYnV0ZXMgZm91bmQgaW4gbWFueQogICBleGlzdGluZyBkZXBsb3ltZW50cyBhbmQg c2NoZW1hcy4KCiAgIEEgcmVzb3VyY2UgaXMgYSBjb2xsZWN0aW9uIG9mIGF0dHJpYnV0ZXMgaWRl bnRpZmllZCBieSBvbmUgb3IgbW9yZQogICBzY2hlbWFzLiAgTWluaW1hbGx5LCBhbiBhdHRyaWJ1 dGUgY29uc2lzdHMgb2YgdGhlIGF0dHJpYnV0ZSBuYW1lIGFuZAogICBhdCBsZWFzdCBvbmUgU2lt cGxlIG9yIENvbXBsZXggdmFsdWUgZWl0aGVyIG9mIHdoaWNoIG1heSBiZSBNdWx0aS0KICAgdmFs dWVkLiAgU0NJTSBzY2hlbWEgZGVmaW5lcyB0aGUgZGF0YSB0eXBlLCBwbHVyYWxpdHkgYW5kIG90 aGVyCiAgIGRpc3Rpbmd1aXNoaW5nIGZlYXR1cmVzIG9mIGFuIGF0dHJpYnV0ZS4gIFVubGVzcyBv dGhlcndpc2Ugc3BlY2lmaWVkCiAgIGFsbCBhdHRyaWJ1dGVzIGFyZSBtb2RpZmlhYmxlIGJ5IENv bnN1bWVycy4gIEltbXV0YWJsZSAocmVhZC1vbmx5KQogICBhdHRyaWJ1dGVzIFNIQUxMIGJlIHNw ZWNpZmllZCBhcyAnUkVBRC1PTkxZJyB3aXRoaW4gdGhlIGF0dHJpYnV0ZQogICBkZWZpbml0aW9u LiAgQWRkaXRpb25hbGx5LCBTZXJ2aWNlIFByb3ZpZGVycyBNQVkgY2hvb3NlIHRvIG1ha2Ugc29t ZQogICBvciBhbGwgUmVzb3VyY2UgYXR0cmlidXRlcyBpbW11dGFibGUgYW5kIFNIT1VMRCBpZGVu dGlmeSB0aG9zZQogICBhdHRyaWJ1dGVzIHZpYSB0aGUgYXNzb2NpYXRlZCBSZXNvdXJjZSdzIHNj aGVtYSBlbmRwb2ludAogICAoU2VjdGlvbiA1LjIpLgoKICAgQSBKU09OIFsxXSAoSmF2YVNjcmlw dCBPYmplY3QgTm90YXRpb24pIGZvcm1hdCBpcyBkZWZpbmVkLiAgQXR0cmlidXRlCiAgIG5hbWVz IFNIT1VMRCBiZSBjYW1lbENhc2VkLiAgU0NJTSByZXNvdXJjZXMgcmVwcmVzZW50ZWQgaW4gSlNP TiBNVVNUCiAgIHNwZWNpZnkgc2NoZW1hIHZpYSB0aGUgc2NoZW1hcyBhdHRyaWJ1dGUgKFNlY3Rp b24gNS4yKS4KCjMuMS4gIEF0dHJpYnV0ZSBEYXRhIFR5cGVzCgogICBBdHRyaWJ1dGUgZGF0YSB0 eXBlcyBhcmUgZGVyaXZlZCBmcm9tIEpTT04gWzJdIGFuZCB1bmxlc3Mgb3RoZXJ3aXNlCiAgIHNw ZWNpZmllZCBhcmUgb3B0aW9uYWwsIG1vZGlmaWFibGUgYnkgQ29uc3VtZXJzLCBhbmQgb2YgdHlw ZSBTdHJpbmcKCgoKTW9ydGltb3JlLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAx MyAgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgZHJh ZnQtc2NpbS1jb3JlLXNjaGVtYS0wMSAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAgKFNlY3Rp b24gMy4xLjEpLiAgVGhlIEpTT04gZm9ybWF0IGRlZmluZXMgYSBsaW1pdGVkIHNldCBvZiBkYXRh CiAgIHR5cGVzLCBoZW5jZSwgd2hlcmUgYXBwcm9wcmlhdGUsIGFsdGVybmF0ZSBKU09OIHJlcHJl c2VudGF0aW9ucwogICBkZXJpdmVkIGZyb20gWE1MIHNjaGVtYSBbM10gYXJlIGRlZmluZWQgYmVs b3cuICBTQ0lNIGV4dGVuc2lvbnMKICAgU0hPVUxEIG5vdCBpbnRyb2R1Y2UgbmV3IGRhdGEgdHlw ZXMuCgozLjEuMS4gIFN0cmluZwoKICAgQSBzZXF1ZW5jZSBvZiB6ZXJvIG9yIG1vcmUgVW5pY29k ZSBjaGFyYWN0ZXJzLiAgVGhlIEpTT04gZm9ybWF0IGlzCiAgIGRlZmluZWQgaW4gc2VjdGlvbiAy LjUgb2YgUkZDIDQ2MjcuICBBIFN0cmluZyBhdHRyaWJ1dGUgTUFZIHNwZWNpZnkgYQogICByZXF1 aXJlZCBkYXRhIGZvcm1hdC4gIEFkZGl0aW9uYWxseSwgd2hlbiBDYW5vbmljYWwgVmFsdWVzIGFy ZQogICBzcGVjaWZpZWQgU2VydmljZSBQcm92aWRlcnMgU0hPVUxEIGNvbmZvcm0gdG8gdGhvc2Ug dmFsdWVzIGlmCiAgIGFwcHJvcHJpYXRlLCBidXQgTUFZIHByb3ZpZGUgYWx0ZXJuYXRlIFN0cmlu ZyB2YWx1ZXMgdG8gcmVwcmVzZW50CiAgIGFkZGl0aW9uYWwgdmFsdWVzLgoKMy4xLjIuICBCb29s ZWFuCgogICBUaGUgbGl0ZXJhbCAidHJ1ZSIgb3IgImZhbHNlIi4gIFRoZSBKU09OIGZvcm1hdCBp cyBkZWZpbmVkIGluIHNlY3Rpb24KICAgMi4xIG9mIFJGQyA0NjI3LgoKMy4xLjMuICBEZWNpbWFs CgogICBBIHJlYWwgbnVtYmVyIHdpdGggYXQgbGVhc3Qgb25lIGRpZ2l0IHRvIHRoZSBsZWZ0IGFu ZCByaWdodCBvZiB0aGUKICAgcGVyaW9kLiAgVGhlIEpTT04gZm9ybWF0IGlzIGRlZmluZWQgaW4g c2VjdGlvbiAyLjQgb2YgUkZDIDQ2MjcuCgozLjEuNC4gIEludGVnZXIKCiAgIEEgRGVjaW1hbCBu dW1iZXIgd2l0aCBubyBmcmFjdGlvbmFsIGRpZ2l0cy4gIFRoZSBKU09OIGZvcm1hdCBpcwogICBk ZWZpbmVkIGluIHNlY3Rpb24gMi40IG9mIFJGQyA0NjI3IHdpdGggdGhlIGFkZGl0aW9uYWwgY29u c3RyYWludAogICB0aGF0IHRoZSB2YWx1ZSBNVVNUIE5PVCBjb250YWluIGZyYWN0aW9uaWFsIG9y IGV4cG9uZW50IHBhcnRzLgoKMy4xLjUuICBEYXRlVGltZQoKICAgQSBEYXRlVGltZSB2YWx1ZSAo ZS5nLiAyMDA4LTAxLTIzVDA0OjU2OjIyWikuICBUaGUgYXR0cmlidXRlIHZhbHVlCiAgIE1VU1Qg YmUgZW5jb2RlZCBhcyBhIHZhbGlkIHhzZDpkYXRlVGltZSBhcyBzcGVjaWZpZWQgaW4gc2VjdGlv biAzLjIuNwogICBvZiB0aGUgWE1MIFNjaGVtYSBEYXRhdHlwZXMgU3BlY2lmaWNhdGlvbi4KCiAg IFZhbHVlcyByZXByZXNlbnRlZCBpbiBKU09OIE1VU1QgY29uZm9ybSB0byB0aGUgWE1MIGNvbnN0 cmFpbnRzIGFib3ZlCiAgIGFuZCBhcmUgcmVwcmVzZW50ZWQgYXMgYSBKU09OIFN0cmluZy4KCjMu MS42LiAgQmluYXJ5CgogICBBcmJpdHJhcnkgYmluYXJ5IGRhdGEuICBUaGUgYXR0cmlidXRlIHZh bHVlIE1VU1QgYmUgZW5jb2RlZCBhcyBhCiAgIHZhbGlkIHhzZDpiYXNlNjRCaW5hcnkgYXMgc3Bl Y2lmaWVkIGluIHNlY3Rpb24gMy4yLjE2IG9mIHRoZSBYTUwKICAgU2NoZW1hIERhdGF0eXBlcyBT cGVjaWZpY2F0aW9uLgoKICAgVmFsdWVzIHJlcHJlc2VudGVkIGluIEpTT04gTVVTVCBjb25mb3Jt IHRvIHRoZSBYTUwgY29uc3RyYWludHMgYWJvdmUKICAgYW5kIGFyZSByZXByZXNlbnRlZCBhcyBh IEpTT04gU3RyaW5nLgoKCgoKTW9ydGltb3JlLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBNYXkg NSwgMjAxMyAgICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0wMSAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKMy4x LjcuICBDb21wbGV4CgogICBBIFNpbmd1bGFyIG9yIE11bHRpLXZhbHVlZCBBdHRyaWJ1dGUgd2hv c2UgdmFsdWUgaXMgYSBjb21wb3NpdGlvbiBvZgogICBvbmUgb3IgbW9yZSBTaW1wbGUgQXR0cmli dXRlcy4gIFRoZSBKU09OIGZvcm1hdCBpcyBkZWZpbmVkIGluIHNlY3Rpb24KICAgMi4yIG9mIFJG QyA0NjI3LgoKMy4yLiAgTXVsdGktdmFsdWVkIEF0dHJpYnV0ZXMKCiAgIE11bHRpLXZhbHVlZCBh dHRyaWJ1dGVzIGFyZSB1bm9yZGVyZWQgbGlzdHMgb2YgYXR0cmlidXRlcy4gIEVhY2gKICAgYXR0 cmlidXRlIE1BWSBjb250YWluIFN1Yi1BdHRyaWJ1dGVzIGFuZCB0aGVyZWZvcmUgbXVsdGktdmFs dWVkCiAgIGF0dHJpYnV0ZXMgbWF5IGNvbnRhaW4gQ29tcGxleCBBdHRyaWJ1dGVzLiAgVGhlIGJl bG93IFN1Yi1BdHRyaWJ1dGVzCiAgIGFyZSBjb25zaWRlcmVkIG5vcm1hdGl2ZSBhbmQgd2hlbiBz cGVjaWZpZWQgU0hPVUxEIGJlIHVzZWQgYXMKICAgZGVmaW5lZC4KCiAgIHR5cGUgIEEgbGFiZWwg aW5kaWNhdGluZyB0aGUgYXR0cmlidXRlJ3MgZnVuY3Rpb247IGUuZy4sICJ3b3JrIiBvcgogICAg ICAiaG9tZSIuCgogICBwcmltYXJ5ICBBIEJvb2xlYW4gdmFsdWUgaW5kaWNhdGluZyB0aGUgJ3By aW1hcnknIG9yIHByZWZlcnJlZAogICAgICBhdHRyaWJ1dGUgdmFsdWUgZm9yIHRoaXMgYXR0cmli dXRlLCBlLmcuIHRoZSBwcmVmZXJyZWQgbWFpbGluZwogICAgICBhZGRyZXNzIG9yIHByaW1hcnkg ZS1tYWlsIGFkZHJlc3MuICBUaGUgcHJpbWFyeSBhdHRyaWJ1dGUgdmFsdWUKICAgICAgJ3RydWUn IE1VU1QgYXBwZWFyIG5vIG1vcmUgdGhhbiBvbmNlLgoKICAgZGlzcGxheSAgQSBodW1hbiByZWFk YWJsZSBuYW1lLCBwcmltYXJpbHkgdXNlZCBmb3IgZGlzcGxheSBwdXJwb3Nlcy4KICAgICAgUkVB RC1PTkxZLgoKICAgb3BlcmF0aW9uICBUaGUgb3BlcmF0aW9uIHRvIHBlcmZvcm0gb24gdGhlIG11 bHRpLXZhbHVlZCBhdHRyaWJ1dGUKICAgICAgZHVyaW5nIGEgUEFUQ0ggcmVxdWVzdC4gIFRoZSBv bmx5IHZhbGlkIHZhbHVlIGlzICJkZWxldGUiLCB3aGljaAogICAgICBzaWduaWZpZXMgdGhhdCB0 aGlzIGluc3RhbmNlIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIFJlc291cmNlLgoKICAgdmFs dWUgIFRoZSBhdHRyaWJ1dGUncyBzaWduaWZpY2FudCB2YWx1ZTsgZS5nLiwgdGhlIGUtbWFpbCBh ZGRyZXNzLAogICAgICBwaG9uZSBudW1iZXIsIGV0Yy4gIEF0dHJpYnV0ZXMgdGhhdCBkZWZpbmUg YSAidmFsdWUiIHN1Yi1hdHRyaWJ1dGUKICAgICAgTUFZIGJlIGFsdGVybmF0ZWx5IHJlcHJlc2Vu dGVkIGFzIGEgY29sbGVjdGlvbiBvZiBwcmltaXRpdmUgdHlwZXMuCiAgICAgIEZvciBleGFtcGxl OgoKICAgewogICAgICJlbWFpbHMiOiBbCiAgICAgICB7InZhbHVlIjoiYmplbnNlbkBleGFtcGxl LmNvbSJ9LAogICAgICAgeyJ2YWx1ZSI6ImJhYnNAZXhhbXBsZS5jb20ifQogICAgIF0KICAgfQoK ICAgICAgTWF5IGFsc28gYmUgcmVwcmVzZW50ZWQgYXM6CgogICB7CiAgICAgImVtYWlscyI6IFsi YmplbnNlbkBleGFtcGxlLmNvbSIsImJhYnNAZXhhbXBsZS5jb20iXQogICB9CgoKCgoKTW9ydGlt b3JlLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAg IFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgZHJhZnQtc2NpbS1jb3JlLXNjaGVt YS0wMSAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAgV2hlbiByZXR1cm5pbmcgbXVsdGktdmFs dWVkIGF0dHJpYnV0ZXMsIFNlcnZpY2UgUHJvdmlkZXJzIFNIT1VMRAogICBjYW5vbmljYWxpemUg dGhlIHZhbHVlIHJldHVybmVkLCBpZiBhcHByb3ByaWF0ZSAoZS5nLiBmb3IgZS1tYWlsCiAgIGFk ZHJlc3NlcyBhbmQgVVJMcykuICBQcm92aWRlcnMgTUFZIHJldHVybiB0aGUgc2FtZSB2YWx1ZSBt b3JlIHRoYW4KICAgb25jZSB3aXRoIGRpZmZlcmVudCB0eXBlcyAoZS5nLiB0aGUgc2FtZSBlLW1h aWwgYWRkcmVzcyBtYXkgdXNlZCBmb3IKICAgd29yayBhbmQgaG9tZSksIGJ1dCBTSE9VTEQgTk9U IHJldHVybiB0aGUgc2FtZSAodHlwZSwgdmFsdWUpCiAgIGNvbWJpbmF0aW9uIG1vcmUgdGhhbiBv bmNlIHBlciBBdHRyaWJ1dGUsIGFzIHRoaXMgY29tcGxpY2F0ZXMKICAgcHJvY2Vzc2luZyBieSB0 aGUgQ29uc3VtZXIuCgoKNC4gIFNjaGVtYSBFeHRlbnNpb24gTW9kZWwKCiAgIFNDSU0gc2NoZW1h IGZvbGxvd3MgYW4gb2JqZWN0IGV4dGVuc2lvbiBtb2RlbCBzaW1pbGFyIHRvCiAgIE9iamVjdENs YXNzZXMgdXNlZCBpbiBMREFQLiAgVW5saWtlIExEQVAgdGhlcmUgaXMgbm8gaW5oZXJpdGFuY2UK ICAgbW9kZWw7IGFsbCBleHRlbnNpb25zIGFyZSBhZGRpdGl2ZSAoc2ltaWxhciB0byBMREFQIEF1 eGlsaWFyeSBPYmplY3QKICAgQ2xhc3NlcyBbNF0pLiAgRWFjaCB2YWx1ZSBpbmRpY2F0ZXMgYWRk aXRpdmUgc2NoZW1hIHRoYXQgbWF5IGV4aXN0IGluCiAgIGEgU0NJTSByZXByZXNlbnRhdGlvbiBh cyBzcGVjaWZpZWQgYnkgZXh0ZW5zaW9ucyBub3QgZGVmaW5lZCBpbiB0aGlzCiAgIHN1aXRlLiAg U2NoZW1hIGV4dGVuc2lvbnMgTVVTVCBOT1QgcmVkZWZpbmUgYW55IGF0dHJpYnV0ZXMgZGVmaW5l ZCBpbgogICB0aGlzIHNwZWNpZmljYXRpb24gYW5kIFNIT1VMRCBmb2xsb3cgY29udmVudGlvbnMg ZGVmaW5lZCBpbiB0aGlzCiAgIHNwZWNpZmljYXRpb24uICBFYWNoIHNjaGVtYSBleHRlbnNpb24g bXVzdCBpZGVudGlmeSBhIFVSSSB1c2VkIHRvCiAgIGlkZW50aWZ5IHRoZSBleHRlbnNpb24uICBU aGUgSlNPTiBmb3JtYXQgTVVTVCB1c2UgdGhlICJzY2hlbWFzIgogICBhdHRyaWJ1dGUgKFNlY3Rp b24gNS4yKSB0byBkaXN0aW5ndWlzaCBleHRlbmRlZCByZXNvdXJjZXMgYW5kCiAgIGF0dHJpYnV0 ZXMuCgoKNS4gIFNDSU0gQ29yZSBTY2hlbWEKCjUuMS4gIENvbW1vbiBTY2hlbWEgQXR0cmlidXRl cwoKICAgRWFjaCBTQ0lNIFJlc291cmNlIChVc2VycywgR3JvdXBzLCBldGMuKSBpbmNsdWRlcyB0 aGUgYmVsb3cgY29tbW9uCiAgIGF0dHJpYnV0ZXMuICBUaGVzZSBhdHRyaWJ1dGVzIE1VU1QgYmUg aW5jbHVkZWQgaW4gYWxsIFJlc291cmNlcywKICAgaW5jbHVkaW5nIGFueSBleHRlbmRlZCBSZXNv dXJjZSB0eXBlcy4gIEl0IGlzIG5vdCBuZWNlc3NhcnkgdG8KICAgc3BlY2lmeSB0aGUgc2NoZW1h cyBhdHRyaWJ1dGUgaWYgdGhlIFJlc291cmNlIGlzIGZ1bGx5IGRlZmluZWQgaW4KICAgdGhpcyBk b2N1bWVudCBhcyB0aGUgY29yZSBzY2hlbWEgaXMgaW1wbGljaXRseSBpbmNsdWRlZC4KCiAgIGlk IFVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgU0NJTSBSZXNvdXJjZSBhcyBkZWZpbmVkIGJ5IHRo ZSBTZXJ2aWNlCiAgICAgIFByb3ZpZGVyLiAgRWFjaCByZXByZXNlbnRhdGlvbiBvZiB0aGUgUmVz b3VyY2UgTVVTVCBpbmNsdWRlIGEgbm9uLQogICAgICBlbXB0eSBpZCB2YWx1ZS4gIFRoaXMgaWRl bnRpZmllciBNVVNUIGJlIHVuaXF1ZSBhY3Jvc3MgdGhlIFNlcnZpY2UKICAgICAgUHJvdmlkZXIn cyBlbnRpcmUgc2V0IG9mIFJlc291cmNlcy4gIEl0IE1VU1QgYmUgYSBzdGFibGUsIG5vbi0KICAg ICAgcmVhc3NpZ25hYmxlIGlkZW50aWZpZXIgdGhhdCBkb2VzIG5vdCBjaGFuZ2Ugd2hlbiB0aGUg c2FtZQogICAgICBSZXNvdXJjZSBpcyByZXR1cm5lZCBpbiBzdWJzZXF1ZW50IHJlcXVlc3RzLiAg VGhlIHZhbHVlIG9mIHRoZSBpZAogICAgICBhdHRyaWJ1dGUgaXMgYWx3YXlzIGlzc3VlZCBieSB0 aGUgU2VydmljZSBQcm92aWRlciBhbmQgTVVTVCBuZXZlcgogICAgICBiZSBzcGVjaWZpZWQgYnkg dGhlIFNlcnZpY2UgQ29uc3VtZXIuIGJ1bGtJZDogaXMgYSByZXNlcnZlZAogICAgICBrZXl3b3Jk IGFuZCBNVVNUIE5PVCBiZSB1c2VkIGluIHRoZSB1bmlxdWUgaWRlbnRpZmllci4gIFJFUVVJUkVE CiAgICAgIGFuZCBSRUFELU9OTFkuCgoKCgoKCgpNb3J0aW1vcmUsIGV0IGFsLiAgICAgICAgICBF eHBpcmVzIE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICBkcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAxICAgICAgICAgIE5vdmVtYmVy IDIwMTIKCgogICBleHRlcm5hbElkICBBbiBpZGVudGlmaWVyIGZvciB0aGUgUmVzb3VyY2UgYXMg ZGVmaW5lZCBieSB0aGUgU2VydmljZQogICAgICBDb25zdW1lci4gIFRoZSBleHRlcm5hbElkIG1h eSBzaW1wbGlmeSBpZGVudGlmaWNhdGlvbiBvZiB0aGUKICAgICAgUmVzb3VyY2UgYmV0d2VlbiBT ZXJ2aWNlIENvbnN1bWVyIGFuZCBTZXJ2aWNlIHByb3ZpZGVyIGJ5IGFsbG93aW5nCiAgICAgIHRo ZSBDb25zdW1lciB0byByZWZlciB0byB0aGUgUmVzb3VyY2Ugd2l0aCBpdHMgb3duIGlkZW50aWZp ZXIsCiAgICAgIG9idmlhdGluZyB0aGUgbmVlZCB0byBzdG9yZSBhIGxvY2FsIG1hcHBpbmcgYmV0 d2VlbiB0aGUgbG9jYWwKICAgICAgaWRlbnRpZmllciBvZiB0aGUgUmVzb3VyY2UgYW5kIHRoZSBp ZGVudGlmaWVyIHVzZWQgYnkgdGhlIFNlcnZpY2UKICAgICAgUHJvdmlkZXIuICBFYWNoIFJlc291 cmNlIE1BWSBpbmNsdWRlIGEgbm9uLWVtcHR5IGV4dGVybmFsSWQgdmFsdWUuCiAgICAgIFRoZSB2 YWx1ZSBvZiB0aGUgZXh0ZXJuYWxJZCBhdHRyaWJ1dGUgaXMgYWx3YXlzIGlzc3VlZCBiZSB0aGUK ICAgICAgU2VydmljZSBDb25zdW1lciBhbmQgY2FuIG5ldmVyIGJlIHNwZWNpZmllZCBieSB0aGUg U2VydmljZQogICAgICBQcm92aWRlci4gIFRoZSBTZXJ2aWNlIFByb3ZpZGVyIE1VU1QgYWx3YXlz IGludGVycHJldCB0aGUKICAgICAgZXh0ZXJuYWxJZCBhcyBzY29wZWQgdG8gdGhlIFNlcnZpY2Ug Q29uc3VtZXIncyB0ZW5hbnQuCgogICBtZXRhICBBIGNvbXBsZXggYXR0cmlidXRlIGNvbnRhaW5p bmcgcmVzb3VyY2UgbWV0YWRhdGEuICBBbGwgc3ViLQogICAgICBhdHRyaWJ1dGVzIGFyZSBPUFRJ T05BTAoKICAgICAgY3JlYXRlZCAgVGhlIERhdGVUaW1lIHRoZSBSZXNvdXJjZSB3YXMgYWRkZWQg dG8gdGhlIFNlcnZpY2UKICAgICAgICAgUHJvdmlkZXIuICBUaGUgYXR0cmlidXRlIE1VU1QgYmUg YSBEYXRlVGltZS4gIFJFQUQtT05MWS4KCiAgICAgIGxhc3RNb2RpZmllZCAgVGhlIG1vc3QgcmVj ZW50IERhdGVUaW1lIHRoZSBkZXRhaWxzIG9mIHRoaXMKICAgICAgICAgUmVzb3VyY2Ugd2VyZSB1 cGRhdGVkIGF0IHRoZSBTZXJ2aWNlIFByb3ZpZGVyLiAgSWYgdGhpcwogICAgICAgICBSZXNvdXJj ZSBoYXMgbmV2ZXIgYmVlbiBtb2RpZmllZCBzaW5jZSBpdHMgaW5pdGlhbCBjcmVhdGlvbiwKICAg ICAgICAgdGhlIHZhbHVlIE1VU1QgYmUgdGhlIHNhbWUgYXMgdGhlIHZhbHVlIG9mIGNyZWF0ZWQu ICBUaGUKICAgICAgICAgYXR0cmlidXRlIE1VU1QgYmUgYSBEYXRlVGltZS4gIFJFQUQtT05MWS4K CiAgICAgIGxvY2F0aW9uICBUaGUgVVJJIG9mIHRoZSBSZXNvdXJjZSBiZWluZyByZXR1cm5lZC4g IFRoaXMgdmFsdWUgTVVTVAogICAgICAgICBiZSB0aGUgc2FtZSBhcyB0aGUgTG9jYXRpb24gSFRU UCByZXNwb25zZSBoZWFkZXIuICBSRUFELU9OTFkuCgogICAgICB2ZXJzaW9uICBUaGUgdmVyc2lv biBvZiB0aGUgUmVzb3VyY2UgYmVpbmcgcmV0dXJuZWQuICBUaGlzIHZhbHVlCiAgICAgICAgIG11 c3QgYmUgdGhlIHNhbWUgYXMgdGhlIEVUYWcgSFRUUCByZXNwb25zZSBoZWFkZXIuICBSRUFELU9O TFkuCgogICAgICBhdHRyaWJ1dGVzICBUaGUgbmFtZXMgb2YgdGhlIGF0dHJpYnV0ZXMgdG8gcmVt b3ZlIGZyb20gdGhlCiAgICAgICAgIFJlc291cmNlIGR1cmluZyBhIFBBVENIIG9wZXJhdGlvbi4K CjUuMi4gICJzY2hlbWFzIiBBdHRyaWJ1dGUKCiAgIFNDSU0gc3VwcG9ydHMgcmVzb3VyY2VzIG9m IGRpZmZlcmVudCB0eXBlcywgd2l0aCBleHRlbnNpYmxlIHNjaGVtYXMuCiAgIEVhY2ggcmVzb3Vy Y2UgTVVTVCBiZSBpbmRpY2F0ZWQgdXNpbmcgZnVsbHkgcXVhbGlmaWVkIFVSTHMuCgogICBXaGVu IGEgcmVwcmVzZW50YXRpb24gZG9lcyBub3QgZXhwbGljaXRseSBwcm92aWRlIHN1cHBvcnQgZm9y CiAgIGluZGljYXRpbmcgYSBzY2hlbWEsIHN1Y2ggYXMgSlNPTiwgYSBzY2hlbWFzIGF0dHJpYnV0 ZSBpcyB1c2VkIHRvCiAgIGluZGljYXRlIHRoZSB2ZXJzaW9uIG9mIFNDSU0gc2NoZW1hIGFzIHdl bGwgYXMgYW55IHNjaGVtYSBleHRlbnNpb25zLgoKICAgc2NoZW1hcyAgVGhlIHNjaGVtYXMgYXR0 cmlidXRlIGlzIGFuIGFycmF5IG9mIFN0cmluZ3Mgd2hpY2ggYWxsb3dzCiAgICAgIGludHJvc3Bl Y3Rpb24gb2YgdGhlIHN1cHBvcnRlZCBzY2hlbWEgdmVyc2lvbiBmb3IgYSBTQ0lNCiAgICAgIHJl cHJlc2VudGF0aW9uIGFzIHdlbGwgYW55IHNjaGVtYSBleHRlbnNpb25zIHN1cHBvcnRlZCBieSB0 aGF0CiAgICAgIHJlcHJlc2VudGF0aW9uLiAgRWFjaCBTdHJpbmcgdmFsdWUgbXVzdCBiZSBhIHVu aXF1ZSBVUkkuICBUaGlzCiAgICAgIHNwZWNpZmljYXRpb24gZGVmaW5lcyBVUklzIGZvciBVc2Vy LCBHcm91cCwgYW5kIGEgc3RhbmRhcmQKICAgICAgImVudGVycHJpc2UiIGV4dGVuc2lvbi4gIEFs bCByZXByZXNlbnRhdGlvbnMgb2YgU0NJTSBzY2hlbWEgTVVTVAoKCgpNb3J0aW1vcmUsIGV0IGFs LiAgICAgICAgICBFeHBpcmVzIE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBkcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAxICAgICAg ICAgIE5vdmVtYmVyIDIwMTIKCgogICAgICBpbmNsdWRlIGEgbm9uLXplcm8gdmFsdWUgYXJyYXkg d2l0aCB2YWx1ZShzKSBvZiB0aGUgVVJJcyBzdXBwb3J0ZWQKICAgICAgYnkgdGhhdCByZXByZXNl bnRhdGlvbi4gIER1cGxpY2F0ZSB2YWx1ZXMgTVVTVCBOT1QgYmUgaW5jbHVkZWQuCiAgICAgIFZh bHVlIG9yZGVyIGlzIG5vdCBzcGVjaWZpZWQgYW5kIE1VU1Qgbm90IGltcGFjdCBiZWhhdmlvci4K ICAgICAgUkVRVUlSRUQuCgoKNi4gIFNDSU0gVXNlciBTY2hlbWEKCiAgIFNDSU0gcHJvdmlkZXMg YSBzY2hlbWEgZm9yIHJlcHJlc2VudGluZyBVc2VycywgaWRlbnRpZmllZCB1c2luZyB0aGUKICAg Zm9sbG93aW5nIFVSSTogJ3VybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAnLiAgVGhlIGZvbGxvd2lu ZyBhdHRyaWJ1dGVzCiAgIGFyZSBkZWZpbmVkIGluIGFkZGl0aW9uIHRvIHRob3NlIGF0dHJpYnV0 ZXMgZGVmaW5lZCBpbiBTQ0lNIENvcmUKICAgU2NoZW1hOgoKNi4xLiAgU2luZ3VsYXIgQXR0cmli dXRlcwoKICAgdXNlck5hbWUgIFVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgVXNlciwgdHlwaWNh bGx5IHVzZWQgYnkgdGhlIHVzZXIKICAgICAgdG8gZGlyZWN0bHkgYXV0aGVudGljYXRlIHRvIHRo ZSBzZXJ2aWNlIHByb3ZpZGVyLiAgT2Z0ZW4gZGlzcGxheWVkCiAgICAgIHRvIHRoZSB1c2VyIGFz IHRoZWlyIHVuaXF1ZSBpZGVudGlmaWVyIHdpdGhpbiB0aGUgc3lzdGVtIChhcwogICAgICBvcHBv c2VkIHRvIGlkIG9yIGV4dGVybmFsSWQsIHdoaWNoIGFyZSBnZW5lcmFsbHkgb3BhcXVlIGFuZCBu b3QKICAgICAgdXNlci1mcmllbmRseSBpZGVudGlmaWVycykuICBFYWNoIFVzZXIgTVVTVCBpbmNs dWRlIGEgbm9uLWVtcHR5CiAgICAgIHVzZXJOYW1lIHZhbHVlLiAgVGhpcyBpZGVudGlmaWVyIE1V U1QgYmUgdW5pcXVlIGFjcm9zcyB0aGUgU2VydmljZQogICAgICBDb25zdW1lcidzIGVudGlyZSBz ZXQgb2YgVXNlcnMuICBSRVFVSVJFRC4KCiAgIG5hbWUgIFRoZSBjb21wb25lbnRzIG9mIHRoZSBV c2VyJ3MgcmVhbCBuYW1lLiAgUHJvdmlkZXJzIE1BWSByZXR1cm4KICAgICAganVzdCB0aGUgZnVs bCBuYW1lIGFzIGEgc2luZ2xlIHN0cmluZyBpbiB0aGUgZm9ybWF0dGVkIHN1Yi0KICAgICAgYXR0 cmlidXRlLCBvciB0aGV5IE1BWSByZXR1cm4ganVzdCB0aGUgaW5kaXZpZHVhbCBjb21wb25lbnQK ICAgICAgYXR0cmlidXRlcyB1c2luZyB0aGUgb3RoZXIgc3ViLWF0dHJpYnV0ZXMsIG9yIHRoZXkg TUFZIHJldHVybgogICAgICBib3RoLiAgSWYgYm90aCB2YXJpYW50cyBhcmUgcmV0dXJuZWQsIHRo ZXkgU0hPVUxEIGJlIGRlc2NyaWJpbmcKICAgICAgdGhlIHNhbWUgbmFtZSwgd2l0aCB0aGUgZm9y bWF0dGVkIG5hbWUgaW5kaWNhdGluZyBob3cgdGhlCiAgICAgIGNvbXBvbmVudCBhdHRyaWJ1dGVz IHNob3VsZCBiZSBjb21iaW5lZC4KCiAgICAgIGZvcm1hdHRlZCAgVGhlIGZ1bGwgbmFtZSwgaW5j bHVkaW5nIGFsbCBtaWRkbGUgbmFtZXMsIHRpdGxlcywgYW5kCiAgICAgICAgIHN1ZmZpeGVzIGFz IGFwcHJvcHJpYXRlLCBmb3JtYXR0ZWQgZm9yIGRpc3BsYXkgKGUuZy4gIE1zLgogICAgICAgICBC YXJiYXJhIEphbmUgSmVuc2VuLCBJSUkuKS4KCiAgICAgIGZhbWlseU5hbWUgIFRoZSBmYW1pbHkg bmFtZSBvZiB0aGUgVXNlciwgb3IgIkxhc3QgTmFtZSIgaW4gbW9zdAogICAgICAgICBXZXN0ZXJu IGxhbmd1YWdlcyAoZS5nLiAgSmVuc2VuIGdpdmVuIHRoZSBmdWxsIG5hbWUgTXMuIEJhcmJhcmEK ICAgICAgICAgSmFuZSBKZW5zZW4sIElJSS4pLgoKICAgICAgZ2l2ZW5OYW1lICBUaGUgZ2l2ZW4g bmFtZSBvZiB0aGUgVXNlciwgb3IgIkZpcnN0IE5hbWUiIGluIG1vc3QKICAgICAgICAgV2VzdGVy biBsYW5ndWFnZXMgKGUuZy4gIEJhcmJhcmEgZ2l2ZW4gdGhlIGZ1bGwgbmFtZSBNcy4KICAgICAg ICAgQmFyYmFyYSBKYW5lIEplbnNlbiwgSUlJLikuCgogICAgICBtaWRkbGVOYW1lICBUaGUgbWlk ZGxlIG5hbWUocykgb2YgdGhlIFVzZXIgKGUuZy4gIEphbmUgZ2l2ZW4gdGhlCiAgICAgICAgIGZ1 bGwgbmFtZSBNcy4gQmFyYmFyYSBKYW5lIEplbnNlbiwgSUlJLikuCgoKCgoKCk1vcnRpbW9yZSwg ZXQgYWwuICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdl IDEwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIGRyYWZ0LXNjaW0tY29yZS1zY2hlbWEtMDEg ICAgICAgICAgTm92ZW1iZXIgMjAxMgoKCiAgICAgIGhvbm9yaWZpY1ByZWZpeCAgVGhlIGhvbm9y aWZpYyBwcmVmaXgoZXMpIG9mIHRoZSBVc2VyLCBvciAiVGl0bGUiCiAgICAgICAgIGluIG1vc3Qg V2VzdGVybiBsYW5ndWFnZXMgKGUuZy4gIE1zLiBnaXZlbiB0aGUgZnVsbCBuYW1lIE1zLgogICAg ICAgICBCYXJiYXJhIEphbmUgSmVuc2VuLCBJSUkuKS4KCiAgICAgIGhvbm9yaWZpY1N1ZmZpeCAg VGhlIGhvbm9yaWZpYyBzdWZmaXgoZXMpIG9mIHRoZSBVc2VyLCBvciAiU3VmZml4IgogICAgICAg ICBpbiBtb3N0IFdlc3Rlcm4gbGFuZ3VhZ2VzIChlLmcuICBJSUkuIGdpdmVuIHRoZSBmdWxsIG5h bWUgTXMuCiAgICAgICAgIEJhcmJhcmEgSmFuZSBKZW5zZW4sIElJSS4pLgoKICAgZGlzcGxheU5h bWUgIFRoZSBuYW1lIG9mIHRoZSBVc2VyLCBzdWl0YWJsZSBmb3IgZGlzcGxheSB0byBlbmQtdXNl cnMuCiAgICAgIEVhY2ggVXNlciByZXR1cm5lZCBNQVkgaW5jbHVkZSBhIG5vbi1lbXB0eSBkaXNw bGF5TmFtZSB2YWx1ZS4gIFRoZQogICAgICBuYW1lIFNIT1VMRCBiZSB0aGUgZnVsbCBuYW1lIG9m IHRoZSBVc2VyIGJlaW5nIGRlc2NyaWJlZCBpZiBrbm93bgogICAgICAoZS5nLiAgQmFicyBKZW5z ZW4gb3IgTXMuIEJhcmJhcmEgSiBKZW5zZW4sIElJSSksIGJ1dCBNQVkgYmUgYQogICAgICB1c2Vy bmFtZSBvciBoYW5kbGUsIGlmIHRoYXQgaXMgYWxsIHRoYXQgaXMgYXZhaWxhYmxlIChlLmcuCiAg ICAgIGJqZW5zZW4pLiAgVGhlIHZhbHVlIHByb3ZpZGVkIFNIT1VMRCBiZSB0aGUgcHJpbWFyeSB0 ZXh0dWFsIGxhYmVsCiAgICAgIGJ5IHdoaWNoIHRoaXMgVXNlciBpcyBub3JtYWxseSBkaXNwbGF5 ZWQgYnkgdGhlIFNlcnZpY2UgUHJvdmlkZXIKICAgICAgd2hlbiBwcmVzZW50aW5nIGl0IHRvIGVu ZC11c2Vycy4KCiAgIG5pY2tOYW1lICBUaGUgY2FzdWFsIHdheSB0byBhZGRyZXNzIHRoZSB1c2Vy IGluIHJlYWwgbGlmZSwgZS5nLgogICAgICAiQm9iIiBvciAiQm9iYnkiIGluc3RlYWQgb2YgIlJv YmVydCIuICBUaGlzIGF0dHJpYnV0ZSBTSE9VTEQgTk9UCiAgICAgIGJlIHVzZWQgdG8gcmVwcmVz ZW50IGEgVXNlcidzIHVzZXJuYW1lIChlLmcuIGJqZW5zZW4gb3IKICAgICAgbXBlcHBlcmlkZ2Up LgoKICAgcHJvZmlsZVVybCAgQSBmdWxseSBxdWFsaWZpZWQgVVJMIHRvIGEgcGFnZSByZXByZXNl bnRpbmcgdGhlIFVzZXIncwogICAgICBvbmxpbmUgcHJvZmlsZS4KCiAgIHRpdGxlICBUaGUgdXNl cidzIHRpdGxlLCBzdWNoIGFzICJWaWNlIFByZXNpZGVudC4iCgogICB1c2VyVHlwZSAgVXNlZCB0 byBpZGVudGlmeSB0aGUgb3JnYW5pemF0aW9uIHRvIHVzZXIgcmVsYXRpb25zaGlwLgogICAgICBU eXBpY2FsIHZhbHVlcyB1c2VkIG1pZ2h0IGJlICJDb250cmFjdG9yIiwgIkVtcGxveWVlIiwgIklu dGVybiIsCiAgICAgICJUZW1wIiwgIkV4dGVybmFsIiwgYW5kICJVbmtub3duIiBidXQgYW55IHZh bHVlIG1heSBiZSB1c2VkLgoKICAgcHJlZmVycmVkTGFuZ3VhZ2UgIEluZGljYXRlcyB0aGUgVXNl cidzIHByZWZlcnJlZCB3cml0dGVuIG9yIHNwb2tlbgogICAgICBsYW5ndWFnZS4gIEdlbmVyYWxs eSB1c2VkIGZvciBzZWxlY3RpbmcgYSBsb2NhbGl6ZWQgVXNlcgogICAgICBpbnRlcmZhY2UuICBW YWxpZCB2YWx1ZXMgYXJlIGNvbmNhdGVuYXRpb24gb2YgdGhlIElTTyA2MzktMSB0d28KICAgICAg bGV0dGVyIGxhbmd1YWdlIGNvZGUgWzVdLCBhbiB1bmRlcnNjb3JlLCBhbmQgdGhlIElTTyAzMTY2 LTEgMgogICAgICBsZXR0ZXIgY291bnRyeSBjb2RlIFs2XTsgZS5nLiwgJ2VuX1VTJyBzcGVjaWZp ZXMgdGhlIGxhbmd1YWdlCiAgICAgIEVuZ2xpc2ggYW5kIGNvdW50cnkgVVMuCgogICBsb2NhbGUg IFVzZWQgdG8gaW5kaWNhdGUgdGhlIFVzZXIncyBkZWZhdWx0IGxvY2F0aW9uIGZvciBwdXJwb3Nl cyBvZgogICAgICBsb2NhbGl6aW5nIGl0ZW1zIHN1Y2ggYXMgY3VycmVuY3ksIGRhdGUgdGltZSBm b3JtYXQsIG51bWVyaWNhbAogICAgICByZXByZXNlbnRhdGlvbnMsIGV0Yy4gIEEgbG9jYWxlIHZh bHVlIGlzIGEgY29uY2F0ZW5hdGlvbiBvZiB0aGUKICAgICAgSVNPIDYzOS0xIHR3byBsZXR0ZXIg bGFuZ3VhZ2UgY29kZSBbNV0sIGFuIHVuZGVyc2NvcmUsIGFuZCB0aGUgSVNPCiAgICAgIDMxNjYt MSAyIGxldHRlciBjb3VudHJ5IGNvZGUgWzZdOyBlLmcuLCAnZW5fVVMnIHNwZWNpZmllcyB0aGUK ICAgICAgbGFuZ3VhZ2UgRW5nbGlzaCBhbmQgY291bnRyeSBVUy4KCgoKCgoKCk1vcnRpbW9yZSwg ZXQgYWwuICAgICAgICAgIEV4cGlyZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdl IDExXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIGRyYWZ0LXNjaW0tY29yZS1zY2hlbWEtMDEg ICAgICAgICAgTm92ZW1iZXIgMjAxMgoKCiAgIHRpbWV6b25lICBUaGUgVXNlcidzIHRpbWUgem9u ZSBpbiB0aGUgIk9sc29uIiB0aW1lem9uZSBkYXRhYmFzZQogICAgICBmb3JtYXQgWzddOyBlLmcu LCdBbWVyaWNhL0xvc19BbmdlbGVzJy4KCiAgIGFjdGl2ZSAgQSBCb29sZWFuIHZhbHVlIGluZGlj YXRpbmcgdGhlIFVzZXIncyBhZG1pbmlzdHJhdGl2ZSBzdGF0dXMuCiAgICAgIFRoZSBkZWZpbml0 aXZlIG1lYW5pbmcgb2YgdGhpcyBhdHRyaWJ1dGUgaXMgZGV0ZXJtaW5lZCBieSB0aGUKICAgICAg U2VydmljZSBQcm92aWRlciB0aG91Z2ggYSB2YWx1ZSBvZiB0cnVlIGluZmVycyB0aGUgVXNlciBp cywgZm9yCiAgICAgIGV4YW1wbGUsIGFibGUgdG8gbG9naW4gd2hpbGUgYSB2YWx1ZSBvZiBmYWxz ZSBpbXBsaWVzIHRoZSBVc2VyJ3MKICAgICAgYWNjb3VudCBoYXMgYmVlbiBzdXNwZW5kZWQuCgog ICBwYXNzd29yZCAgVGhlIFVzZXIncyBjbGVhciB0ZXh0IHBhc3N3b3JkLiAgVGhpcyBhdHRyaWJ1 dGUgaXMgaW50ZW5kZWQKICAgICAgdG8gYmUgdXNlZCBhcyBhIG1lYW5zIHRvIHNwZWNpZnkgYW4g aW5pdGlhbCBwYXNzd29yZCB3aGVuIGNyZWF0aW5nCiAgICAgIGEgbmV3IFVzZXIgb3IgdG8gcmVz ZXQgYW4gZXhpc3RpbmcgVXNlcidzIHBhc3N3b3JkLiAgTm8gYWNjZXB0ZWQKICAgICAgc3RhbmRh cmRzIGV4aXN0IHRvIGNvbnZleSBwYXNzd29yZCBwb2xpY2llcywgaGVuY2UgQ29uc3VtZXJzCiAg ICAgIHNob3VsZCBleHBlY3QgU2VydmljZSBQcm92aWRlcnMgdG8gcmVqZWN0IHBhc3N3b3JkIHZh bHVlcy4gIFRoaXMKICAgICAgdmFsdWUgTVVTVCBuZXZlciBiZSByZXR1cm5lZCBieSBhIFNlcnZp Y2UgUHJvdmlkZXIgaW4gYW55IGZvcm0uCgo2LjIuICBNdWx0aS12YWx1ZWQgQXR0cmlidXRlcwoK ICAgVGhlIGZvbGxvd2luZyBtdWx0aS12YWx1ZWQgYXR0cmlidXRlcyBhcmUgZGVmaW5lZC4KCiAg IGVtYWlscyAgRS1tYWlsIGFkZHJlc3NlcyBmb3IgdGhlIFVzZXIuICBUaGUgdmFsdWUgU0hPVUxE IGJlCiAgICAgIGNhbm9uaWNhbGl6ZWQgYnkgdGhlIFNlcnZpY2UgUHJvdmlkZXIsIGUuZy4gYmpl bnNlbkBleGFtcGxlLmNvbQogICAgICBpbnN0ZWFkIG9mIGJqZW5zZW5ARVhBTVBMRS5DT00uICBD YW5vbmljYWwgVHlwZSB2YWx1ZXMgb2Ygd29yaywKICAgICAgaG9tZSwgYW5kIG90aGVyLgoKICAg cGhvbmVOdW1iZXJzICBQaG9uZSBudW1iZXJzIGZvciB0aGUgVXNlci4gIFRoZSB2YWx1ZSBTSE9V TEQgYmUKICAgICAgY2Fub25pY2FsaXplZCBieSB0aGUgU2VydmljZSBQcm92aWRlciBhY2NvcmRp bmcgdG8gZm9ybWF0IGluCiAgICAgIFJGQzM5NjYgWzhdIGUuZy4gJ3RlbDorMS0yMDEtNTU1LTAx MjMnLiAgQ2Fub25pY2FsIFR5cGUgdmFsdWVzIG9mCiAgICAgIHdvcmssIGhvbWUsIG1vYmlsZSwg ZmF4LCBwYWdlciBhbmQgb3RoZXIuCgogICBpbXMgIEluc3RhbnQgbWVzc2FnaW5nIGFkZHJlc3Mg Zm9yIHRoZSBVc2VyLiAgTm8gb2ZmaWNpYWwKICAgICAgY2Fub25pY2FsaXphdGlvbiBydWxlcyBl eGlzdCBmb3IgYWxsIGluc3RhbnQgbWVzc2FnaW5nIGFkZHJlc3NlcywKICAgICAgYnV0IFNlcnZp Y2UgUHJvdmlkZXJzIFNIT1VMRCwgd2hlbiBhcHByb3ByaWF0ZSwgcmVtb3ZlIGFsbAogICAgICB3 aGl0ZXNwYWNlIGFuZCBjb252ZXJ0IHRoZSBhZGRyZXNzIHRvIGxvd2VyY2FzZS4gIEluc3RlYWQg b2YgdGhlCiAgICAgIHN0YW5kYXJkIENhbm9uaWNhbCBWYWx1ZXMgZm9yIHR5cGUsIHRoaXMgYXR0 cmlidXRlIGRlZmluZXMgdGhlCiAgICAgIGZvbGxvd2luZyBDYW5vbmljYWwgVmFsdWVzIHRvIHJl cHJlc2VudCBjdXJyZW50bHkgcG9wdWxhciBJTQogICAgICBzZXJ2aWNlczogYWltLCBndGFsaywg aWNxLCB4bXBwLCBtc24sIHNreXBlLCBxcSwgYW5kIHlhaG9vLgoKICAgcGhvdG9zICBVUkwgb2Yg YSBwaG90byBvZiB0aGUgVXNlci4gIFRoZSB2YWx1ZSBTSE9VTEQgYmUgYQogICAgICBjYW5vbmlj YWxpemVkIFVSTCwgYW5kIE1VU1QgcG9pbnQgdG8gYW4gaW1hZ2UgZmlsZSAoZS5nLiBhIEdJRiwK ICAgICAgSlBFRywgb3IgUE5HIGltYWdlIGZpbGUpIHJhdGhlciB0aGFuIHRvIGEgd2ViIHBhZ2Ug Y29udGFpbmluZyBhbgogICAgICBpbWFnZS4gIFNlcnZpY2UgUHJvdmlkZXJzIE1BWSByZXR1cm4g dGhlIHNhbWUgaW1hZ2UgYXQgZGlmZmVyZW50CiAgICAgIHNpemVzLCB0aG91Z2ggaXQgaXMgcmVj b2duaXplZCB0aGF0IG5vIHN0YW5kYXJkIGZvciBkZXNjcmliaW5nCiAgICAgIGltYWdlcyBvZiB2 YXJpb3VzIHNpemVzIGN1cnJlbnRseSBleGlzdHMuICBOb3RlIHRoYXQgdGhpcwogICAgICBhdHRy aWJ1dGUgU0hPVUxEIE5PVCBiZSB1c2VkIHRvIHNlbmQgZG93biBhcmJpdHJhcnkgcGhvdG9zIHRh a2VuCiAgICAgIGJ5IHRoaXMgVXNlciwgYnV0IHNwZWNpZmljYWxseSBwcm9maWxlIHBob3RvcyBv ZiB0aGUgVXNlciBzdWl0YWJsZQogICAgICBmb3IgZGlzcGxheSB3aGVuIGRlc2NyaWJpbmcgdGhl IFVzZXIuICBJbnN0ZWFkIG9mIHRoZSBzdGFuZGFyZAogICAgICBDYW5vbmljYWwgVmFsdWVzIGZv ciB0eXBlLCB0aGlzIGF0dHJpYnV0ZSBkZWZpbmVzIHRoZSBmb2xsb3dpbmcKCgoKTW9ydGltb3Jl LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1Bh Z2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0w MSAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAgICAgQ2Fub25pY2FsIFZhbHVlcyB0byByZXBy ZXNlbnQgcG9wdWxhciBwaG90byBzaXplczogcGhvdG8sCiAgICAgIHRodW1ibmFpbC4KCiAgIGFk ZHJlc3NlcyAgQSBwaHlzaWNhbCBtYWlsaW5nIGFkZHJlc3MgZm9yIHRoaXMgVXNlci4gIENhbm9u aWNhbCBUeXBlCiAgICAgIFZhbHVlcyBvZiB3b3JrLCBob21lLCBhbmQgb3RoZXIuICBUaGUgdmFs dWUgYXR0cmlidXRlIGlzIGEgY29tcGxleAogICAgICB0eXBlIHdpdGggdGhlIGZvbGxvd2luZyBz dWItYXR0cmlidXRlcy4gIEFsbCBTdWItQXR0cmlidXRlcyBhcmUKICAgICAgT1BUSU9OQUwuCgog ICAgICBmb3JtYXR0ZWQgIFRoZSBmdWxsIG1haWxpbmcgYWRkcmVzcywgZm9ybWF0dGVkIGZvciBk aXNwbGF5IG9yIHVzZQogICAgICAgICB3aXRoIGEgbWFpbGluZyBsYWJlbC4gIFRoaXMgYXR0cmli dXRlIE1BWSBjb250YWluIG5ld2xpbmVzLgoKICAgICAgc3RyZWV0QWRkcmVzcyAgVGhlIGZ1bGwg c3RyZWV0IGFkZHJlc3MgY29tcG9uZW50LCB3aGljaCBtYXkKICAgICAgICAgaW5jbHVkZSBob3Vz ZSBudW1iZXIsIHN0cmVldCBuYW1lLCBQLk8uIGJveCwgYW5kIG11bHRpLWxpbmUKICAgICAgICAg ZXh0ZW5kZWQgc3RyZWV0IGFkZHJlc3MgaW5mb3JtYXRpb24uICBUaGlzIGF0dHJpYnV0ZSBNQVkK ICAgICAgICAgY29udGFpbiBuZXdsaW5lcy4KCiAgICAgIGxvY2FsaXR5ICBUaGUgY2l0eSBvciBs b2NhbGl0eSBjb21wb25lbnQuCgogICAgICByZWdpb24gIFRoZSBzdGF0ZSBvciByZWdpb24gY29t cG9uZW50LgoKICAgICAgcG9zdGFsQ29kZSAgVGhlIHppcGNvZGUgb3IgcG9zdGFsIGNvZGUgY29t cG9uZW50LgoKICAgICAgY291bnRyeSAgVGhlIGNvdW50cnkgbmFtZSBjb21wb25lbnQuICBXaGVu IHNwZWNpZmllZCB0aGUgdmFsdWUKICAgICAgICAgTVVTVCBiZSBpbiBJU08gMzE2Ni0xIGFscGhh IDIgInNob3J0IiBjb2RlIGZvcm1hdCBbNl07IGUuZy4sCiAgICAgICAgIHRoZSBVbml0ZWQgU3Rh dGVzIGFuZCBTd2VkZW4gYXJlICJVUyIgYW5kICJTRSIsIHJlc3BlY3RpdmVseS4KCiAgIGdyb3Vw cyAgQSBsaXN0IG9mIGdyb3VwcyB0aGF0IHRoZSB1c2VyIGJlbG9uZ3MgdG8sIGVpdGhlciB0aG9y b3VnaAogICAgICBkaXJlY3QgbWVtYmVyc2hpcCwgbmVzdGVkIGdyb3Vwcywgb3IgZHluYW1pY2Fs bHkgY2FsY3VsYXRlZC4gIFRoZQogICAgICB2YWx1ZXMgYXJlIG1lYW50IHRvIGVuYWJsZSBleHBy ZXNzaW9uIG9mIGNvbW1vbiBncm91cCBvciByb2xlCiAgICAgIGJhc2VkIGFjY2VzcyBjb250cm9s IG1vZGVscywgYWx0aG91Z2ggbm8gZXhwbGljaXQgYXV0aG9yaXphdGlvbgogICAgICBtb2RlbCBp cyBkZWZpbmVkLiAgSXQgaXMgaW50ZW5kZWQgdGhhdCB0aGUgc2VtYW50aWNzIG9mIGdyb3VwCiAg ICAgIG1lbWJlcnNoaXAgYW5kIGFueSBiZWhhdmlvciBvciBhdXRob3JpemF0aW9uIGdyYW50ZWQg YXMgYSByZXN1bHQKICAgICAgb2YgbWVtYmVyc2hpcCBhcmUgZGVmaW5lZCBieSB0aGUgU2Vydmlj ZSBQcm92aWRlci4gIFRoZSBDYW5vbmljYWwKICAgICAgdHlwZXMgImRpcmVjdCIgYW5kICJpbmRp cmVjdCIgYXJlIGRlZmluZWQgdG8gZGVzY3JpYmUgaG93IHRoZQogICAgICBncm91cCBtZW1iZXJz aGlwIHdhcyBkZXJpdmVkLiAgRGlyZWN0IGdyb3VwIG1lbWJlcnNoaXAgaW5kaWNhdGVzCiAgICAg IHRoZSBVc2VyIGlzIGRpcmVjdGx5IGFzc29jaWF0ZWQgd2l0aCB0aGUgZ3JvdXAgYW5kIFNIT1VM RCBpbmRpY2F0ZQogICAgICB0aGF0IENvbnN1bWVycyBtYXkgbW9kaWZ5IG1lbWJlcnNoaXAgdGhy b3VnaCB0aGUgR3JvdXAgUmVzb3VyY2UuCiAgICAgIEluZGlyZWN0IG1lbWJlcnNoaXAgaW5kaWNh dGVzIFVzZXIgbWVtYmVyc2hpcCBpcyB0cmFuc2l0aXZlIG9yCiAgICAgIGR5bmFtaWMgYW5kIGlt cGxpZXMgdGhhdCBDb25zdW1lcnMgY2Fubm90IG1vZGlmeSBpbmRpcmVjdCBncm91cAogICAgICBt ZW1iZXJzaGlwIHRocm91Z2ggdGhlIEdyb3VwIHJlc291cmNlIGJ1dCBNQVkgbW9kaWZ5IGRpcmVj dCBncm91cAogICAgICBtZW1iZXJzaGlwIHRocm91Z2ggdGhlIEdyb3VwIHJlc291cmNlIHdoaWNo IE1BWSBpbmZsdWVuY2UgaW5kaXJlY3QKICAgICAgbWVtYmVyc2hpcHMuICBJZiB0aGUgU0NJTSBT ZXJ2aWNlIFByb3ZpZGVyIGV4cG9zZXMgYSBHcm91cAogICAgICByZXNvdXJjZSwgdGhlIHZhbHVl IE1VU1QgYmUgdGhlICJpZCIgYXR0cmlidXRlIG9mIHRoZQogICAgICBjb3JyZXNwb25kaW5nIEdy b3VwIHJlc291cmNlcyB0byB3aGljaCB0aGUgdXNlciBiZWxvbmdzLiAgU2luY2UKICAgICAgdGhp cyBhdHRyaWJ1dGUgaXMgcmVhZC1vbmx5LCBncm91cCBtZW1iZXJzaGlwIGNoYW5nZXMgTVVTVCBi ZQogICAgICBhcHBsaWVkIHZpYSB0aGUgR3JvdXAgUmVzb3VyY2UgKFNlY3Rpb24gOCkuICBSRUFE LU9OTFkuCgoKCgoKTW9ydGltb3JlLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAx MyAgICAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgZHJh ZnQtc2NpbS1jb3JlLXNjaGVtYS0wMSAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAgZW50aXRs ZW1lbnRzICBBIGxpc3Qgb2YgZW50aXRsZW1lbnRzIGZvciB0aGUgVXNlciB0aGF0IHJlcHJlc2Vu dCBhCiAgICAgIHRoaW5nIHRoZSBVc2VyIGhhcy4gIFRoYXQgaXMsIGFuIGVudGl0bGVtZW50IGlz IGFuIGFkZGl0aW9uYWwKICAgICAgcmlnaHQgdG8gYSB0aGluZywgb2JqZWN0IG9yIHNlcnZpY2Uu ICBObyB2b2NhYnVsYXJ5IG9yIHN5bnRheCBpcwogICAgICBzcGVjaWZpZWQgYW5kIFNlcnZpY2Ug UHJvdmlkZXJzL0NvbnN1bWVycyBhcmUgZXhwZWN0ZWQgdG8gZW5jb2RlCiAgICAgIHN1ZmZpY2ll bnQgaW5mb3JtYXRpb24gaW4gdGhlIHZhbHVlIHNvIGFzIHRvIGFjY3VyYXRlbHkgYW5kCiAgICAg IHdpdGhvdXQgYW1iaWd1aXR5IGRldGVybWluZSB3aGF0IHRoZSBVc2VyIGhhcyBhY2Nlc3MgdG8u ICBUaGlzCiAgICAgIHZhbHVlIGhhcyBOTyBjYW5vbmljYWwgdHlwZXMgdGhvdWdoIHR5cGUgbWF5 IGJlIHVzZWZ1bCBhcyBhIG1lYW5zCiAgICAgIHRvIHNjb3BlIGVudGl0bGVtZW50cy4KCiAgIHJv bGVzICBBIGxpc3Qgb2Ygcm9sZXMgZm9yIHRoZSBVc2VyIHRoYXQgY29sbGVjdGl2ZWx5IHJlcHJl c2VudCB3aG8KICAgICAgdGhlIFVzZXIgaXM7IGUuZy4sICdTdHVkZW50JywgIkZhY3VsdHkiLiAg Tm8gdm9jYWJ1bGFyeSBvciBzeW50YXgKICAgICAgaXMgc3BlY2lmaWVkIHRob3VnaCBpdCBpcyBl eHBlY3RlZCB0aGF0IGEgcm9sZSB2YWx1ZSBpcyBhIFN0cmluZwogICAgICBvciBsYWJlbCByZXBy ZXNlbnRpbmcgYSBjb2xsZWN0aW9uIG9mIGVudGl0bGVtZW50cy4gIFRoaXMgdmFsdWUKICAgICAg aGFzIE5PIGNhbm9uaWNhbCB0eXBlcy4KCiAgIHg1MDlDZXJ0aWZpY2F0ZXMgIEEgbGlzdCBvZiBj ZXJ0aWZpY2F0ZXMgaXNzdWVkIHRvIHRoZSBVc2VyLiAgVmFsdWVzCiAgICAgIGFyZSBCaW5hcnkg KFNlY3Rpb24gMy4xLjYpIGFuZCBERVIgZW5jb2RlZCB4NTA5LiAgVGhpcyB2YWx1ZSBoYXMKICAg ICAgTk8gY2Fub25pY2FsIHR5cGVzLgoKCjcuICBTQ0lNIEVudGVycHJpc2UgVXNlciBTY2hlbWEg RXh0ZW5zaW9uCgogICBUaGUgZm9sbG93aW5nIFNDSU0gZXh0ZW5zaW9uIGRlZmluZXMgYXR0cmli dXRlcyBjb21tb25seSB1c2VkIGluCiAgIHJlcHJlc2VudGluZyB1c2VycyB0aGF0IGJlbG9uZyB0 bywgb3IgYWN0IG9uIGJlaGFsZiBvZiBhIGJ1c2luZXNzIG9yCiAgIGVudGVycHJpc2UuICBUaGUg ZW50ZXJwcmlzZSB1c2VyIGV4dGVuc2lvbiBpcyBpZGVudGlmaWVkIHVzaW5nIHRoZQogICBmb2xs b3dpbmcgVVJJOiAndXJuOnNjaW06c2NoZW1hczpleHRlbnNpb246ZW50ZXJwcmlzZToxLjAnLgoK ICAgVGhlIGZvbGxvd2luZyBTaW5ndWxhciBBdHRyaWJ1dGVzIGFyZSBkZWZpbmVkOgoKICAgZW1w bG95ZWVOdW1iZXIgIE51bWVyaWMgb3IgYWxwaGFudW1lcmljIGlkZW50aWZpZXIgYXNzaWduZWQg dG8gYQogICAgICBwZXJzb24sIHR5cGljYWxseSBiYXNlZCBvbiBvcmRlciBvZiBoaXJlIG9yIGFz c29jaWF0aW9uIHdpdGggYW4KICAgICAgb3JnYW5pemF0aW9uLgoKICAgY29zdENlbnRlciAgSWRl bnRpZmllcyB0aGUgbmFtZSBvZiBhIGNvc3QgY2VudGVyLgoKICAgb3JnYW5pemF0aW9uICBJZGVu dGlmaWVzIHRoZSBuYW1lIG9mIGFuIG9yZ2FuaXphdGlvbi4KCiAgIGRpdmlzaW9uICBJZGVudGlm aWVzIHRoZSBuYW1lIG9mIGEgZGl2aXNpb24uCgogICBkZXBhcnRtZW50ICBJZGVudGlmaWVzIHRo ZSBuYW1lIG9mIGEgZGVwYXJ0bWVudC4KCiAgIG1hbmFnZXIgIFRoZSBVc2VyJ3MgbWFuYWdlci4g IEEgY29tcGxleCB0eXBlIHRoYXQgb3B0aW9uYWxseSBhbGxvd3MKICAgICAgU2VydmljZSBQcm92 aWRlcnMgdG8gcmVwcmVzZW50IG9yZ2FuaXphdGlvbmFsIGhpZXJhcmNoeSBieQogICAgICByZWZl cmVuY2luZyB0aGUgImlkIiBhdHRyaWJ1dGUgb2YgYW5vdGhlciBVc2VyLgoKCgoKCgoKTW9ydGlt b3JlLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAg W1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgZHJhZnQtc2NpbS1jb3JlLXNjaGVt YS0wMSAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAgICAgbWFuYWdlcklkICBUaGUgaWQgb2Yg dGhlIFNDSU0gcmVzb3VyY2UgcmVwcmVzZW50aW5nIHRoZSBVc2VyJ3MKICAgICAgICAgbWFuYWdl ci4gIFJFUVVJUkVELgoKICAgICAgZGlzcGxheU5hbWUgIFRoZSBkaXNwbGF5TmFtZSBvZiB0aGUg VXNlcidzIG1hbmFnZXIuICBPUFRJT05BTCBhbmQKICAgICAgICAgUkVBRC1PTkxZLgoKCjguICBT Q0lNIEdyb3VwIFNjaGVtYQoKICAgU0NJTSBwcm92aWRlcyBhIHNjaGVtYSBmb3IgcmVwcmVzZW50 aW5nIGdyb3VwcywgaWRlbnRpZmllZCB1c2luZyB0aGUKICAgZm9sbG93aW5nIFVSSTogJ3Vybjpz Y2ltOnNjaGVtYXM6Y29yZToxLjAnLgoKICAgR3JvdXAgcmVzb3VyY2VzIGFyZSBtZWFudCB0byBl bmFibGUgZXhwcmVzc2lvbiBvZiBjb21tb24gR3JvdXAgb3IKICAgcm9sZSBiYXNlZCBhY2Nlc3Mg Y29udHJvbCBtb2RlbHMsIGFsdGhvdWdoIG5vIGV4cGxpY2l0IGF1dGhvcml6YXRpb24KICAgbW9k ZWwgaXMgZGVmaW5lZC4gIEl0IGlzIGludGVuZGVkIHRoYXQgdGhlIHNlbWFudGljcyBvZiBncm91 cAogICBtZW1iZXJzaGlwIGFuZCBhbnkgYmVoYXZpb3Igb3IgYXV0aG9yaXphdGlvbiBncmFudGVk IGFzIGEgcmVzdWx0IG9mCiAgIG1lbWJlcnNoaXAgYXJlIGRlZmluZWQgYnkgdGhlIFNlcnZpY2Ug UHJvdmlkZXIgYXJlIGNvbnNpZGVyZWQgb3V0IG9mCiAgIHNjb3BlIGZvciB0aGlzIHNwZWNpZmlj YXRpb24uCgogICBUaGUgZm9sbG93aW5nIFNpbmd1bGFyIEF0dHJpYnV0ZSBpcyBkZWZpbmVkIGlu IGFkZGl0aW9uIHRvIHRoZSBjb21tb24KICAgYXR0cmlidXRlcyBkZWZpbmVkIGluIFNDSU0gQ29y ZSBTY2hlbWE6CgogICBkaXNwbGF5TmFtZSAgQSBodW1hbiByZWFkYWJsZSBuYW1lIGZvciB0aGUg R3JvdXAuICBSRVFVSVJFRC4KCiAgIFRoZSBmb2xsb3dpbmcgbXVsdGktdmFsdWVkIGF0dHJpYnV0 ZSBpcyBkZWZpbmVkIGluIGFkZGl0aW9uIHRvIHRoZQogICBjb21tb24gYXR0cmlidXRlcyBkZWZp bmVkIGluIFNDSU0gQ29yZSBTY2hlbWE6CgogICBtZW1iZXJzICBBIGxpc3Qgb2YgbWVtYmVycyBv ZiB0aGUgR3JvdXAuICBDYW5vbmljYWwgVHlwZXMgIlVzZXIiIGFuZAogICAgICAiR3JvdXAiIGFy ZSBSRUFELU9OTFkuICBUaGUgdmFsdWUgbXVzdCBiZSB0aGUgImlkIiBvZiBhIFNDSU0KICAgICAg cmVzb3VyY2UsIGVpdGhlciBhIFVzZXIsIG9yIGEgR3JvdXAuICBUaGUgaW50ZW50aW9uIG9mIHRo ZSBHcm91cAogICAgICB0eXBlIGlzIHRvIGFsbG93IHRoZSBTZXJ2aWNlIFByb3ZpZGVyIHRvIHN1 cHBvcnQgbmVzdGVkIEdyb3Vwcy4KICAgICAgU2VydmljZSBQcm92aWRlcnMgTUFZIHJlcXVpcmUg Q29uc3VtZXJzIHRvIHByb3ZpZGUgYSBub24tZW1wdHkKICAgICAgbWVtYmVycyB2YWx1ZSBiYXNl ZCBvbiB0aGUgInJlcXVpcmVkIiBzdWIgYXR0cmlidXRlIG9mIHRoZQogICAgICAibWVtYmVycyIg YXR0cmlidXRlIGluIEdyb3VwIFJlc291cmNlIFNjaGVtYS4KCgo5LiAgU2VydmljZSBQcm92aWRl ciBDb25maWd1cmF0aW9uIFNjaGVtYQoKICAgU0NJTSBwcm92aWRlcyBhIHNjaGVtYSBmb3IgcmVw cmVzZW50aW5nIHRoZSBTZXJ2aWNlIFByb3ZpZGVyJ3MKICAgY29uZmlndXJhdGlvbiBpZGVudGlm aWVkIHVzaW5nIHRoZSBmb2xsb3dpbmcgVVJJOgogICAndXJuOnNjaW06c2NoZW1hczpjb3JlOjEu MCcKCiAgIFRoZSBTZXJ2aWNlIFByb3ZpZGVyIENvbmZpZ3VyYXRpb24gUmVzb3VyY2UgZW5hYmxl cyBhIFNlcnZpY2UKICAgUHJvdmlkZXIgdG8gZXhwb3NlIGl0cyBjb21wbGlhbmNlIHdpdGggdGhl IFNDSU0gc3BlY2lmaWNhdGlvbiBpbiBhCiAgIHN0YW5kYXJkaXplZCBmb3JtIGFzIHdlbGwgYXMg cHJvdmlkZSBhZGRpdGlvbmFsIGltcGxlbWVudGF0aW9uCiAgIGRldGFpbHMgdG8gQ29uc3VtZXJz LiAgQWxsIGF0dHJpYnV0ZXMgYXJlIFJFQUQtT05MWS4KCiAgIFRoZSBmb2xsb3dpbmcgU2luZ3Vs YXIgQXR0cmlidXRlcyBhcmUgZGVmaW5lZCBpbiBhZGRpdGlvbiB0byB0aGUKCgoKTW9ydGltb3Jl LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1Bh Z2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0w MSAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAgY29tbW9uIGF0dHJpYnV0ZXMgZGVmaW5lZCBp biBDb3JlIFNjaGVtYToKCiAgIGRvY3VtZW50YXRpb25VcmwgIEFuIEhUVFAgYWRkcmVzc2FibGUg VVJMIHBvaW50aW5nIHRvIHRoZSBTZXJ2aWNlCiAgICAgIFByb3ZpZGVyJ3MgaHVtYW4gY29uc3Vt YWJsZSBoZWxwIGRvY3VtZW50YXRpb24uCgogICBwYXRjaCAgQSBjb21wbGV4IHR5cGUgdGhhdCBz cGVjaWZpZXMgUEFUQ0ggY29uZmlndXJhdGlvbiBvcHRpb25zLgogICAgICBSRVFVSVJFRC4KCiAg ICAgIHN1cHBvcnRlZCAgQm9vbGVhbiB2YWx1ZSBzcGVjaWZ5aW5nIHdoZXRoZXIgdGhlIG9wZXJh dGlvbiBpcwogICAgICAgICBzdXBwb3J0ZWQuICBSRVFVSVJFRC4KCiAgIGJ1bGsgIEEgY29tcGxl eCB0eXBlIHRoYXQgc3BlY2lmaWVzIEJVTEsgY29uZmlndXJhdGlvbiBvcHRpb25zLgogICAgICBS RVFVSVJFRAoKICAgICAgc3VwcG9ydGVkICBCb29sZWFuIHZhbHVlIHNwZWNpZnlpbmcgd2hldGhl ciB0aGUgb3BlcmF0aW9uIGlzCiAgICAgICAgIHN1cHBvcnRlZC4gIFJFUVVJUkVELgoKICAgICAg bWF4T3BlcmF0aW9ucyAgQW4gaW50ZWdlciB2YWx1ZSBzcGVjaWZ5aW5nIHRoZSBtYXhpbXVtIG51 bWJlciBvZgogICAgICAgICBvcGVyYXRpb25zLiAgUkVRVUlSRUQuCgogICAgICBtYXhQYXlsb2Fk U2l6ZSAgQW4gaW50ZWdlciB2YWx1ZSBzcGVjaWZ5aW5nIHRoZSBtYXhpbXVtIHBheWxvYWQKICAg ICAgICAgc2l6ZSBpbiBieXRlcy4gIFJFUVVJUkVELgoKICAgZmlsdGVyICBBIGNvbXBsZXggdHlw ZSB0aGF0IHNwZWNpZmllcyBGSUxURVIgb3B0aW9ucy4gIFJFUVVJUkVELgoKICAgICAgc3VwcG9y dGVkICBCb29sZWFuIHZhbHVlIHNwZWNpZnlpbmcgd2hldGhlciB0aGUgb3BlcmF0aW9uIGlzCiAg ICAgICAgIHN1cHBvcnRlZC4gIFJFUVVJUkVELgoKICAgICAgbWF4UmVzdWx0cyAgSW50ZWdlciB2 YWx1ZSBzcGVjaWZ5aW5nIHRoZSBtYXhpbXVtIG51bWJlciBvZgogICAgICAgICBSZXNvdXJjZXMg cmV0dXJuZWQgaW4gYSByZXNwb25zZS4gIFJFUVVJUkVELgoKICAgY2hhbmdlUGFzc3dvcmQgIEEg Y29tcGxleCB0eXBlIHRoYXQgc3BlY2lmaWVzIENoYW5nZSBQYXNzd29yZAogICAgICBjb25maWd1 cmF0aW9uIG9wdGlvbnMuICBSRVFVSVJFRC4KCiAgICAgIHN1cHBvcnRlZCAgQm9vbGVhbiB2YWx1 ZSBzcGVjaWZ5aW5nIHdoZXRoZXIgdGhlIG9wZXJhdGlvbiBpcwogICAgICAgICBzdXBwb3J0ZWQu ICBSRVFVSVJFRC4KCiAgIHNvcnQgIEEgY29tcGxleCB0eXBlIHRoYXQgc3BlY2lmaWVzIFNvcnQg Y29uZmlndXJhdGlvbiBvcHRpb25zLgogICAgICBSRVFVSVJFRC4KCiAgICAgIHN1cHBvcnRlZCAg Qm9vbGVhbiB2YWx1ZSBzcGVjaWZ5aW5nIHdoZXRoZXIgc29ydGluZyBpcyBzdXBwb3J0ZWQuCiAg ICAgICAgIFJFUVVJUkVELgoKICAgZXRhZyAgQSBjb21wbGV4IHR5cGUgdGhhdCBzcGVjaWZpZXMg RXRhZyBjb25maWd1cmF0aW9uIG9wdGlvbnMuCiAgICAgIFJFUVVJUkVELgoKCgoKCgpNb3J0aW1v cmUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICBb UGFnZSAxNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBkcmFmdC1zY2ltLWNvcmUtc2NoZW1h LTAxICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgogICAgICBzdXBwb3J0ZWQgIEJvb2xlYW4gdmFs dWUgc3BlY2lmeWluZyB3aGV0aGVyIHRoZSBvcGVyYXRpb24gaXMKICAgICAgICAgc3VwcG9ydGVk LiAgUkVRVUlSRUQuCgogICBUaGUgZm9sbG93aW5nIG11bHRpLXZhbHVlZCBhdHRyaWJ1dGUgaXMg ZGVmaW5lZCBpbiBhZGRpdGlvbiB0byB0aGUKICAgY29tbW9uIGF0dHJpYnV0ZXMgZGVmaW5lZCBp biBDb3JlIFNjaGVtYToKCiAgIGF1dGhlbnRpY2F0aW9uU2NoZW1lcyAgQSBjb21wbGV4IHR5cGUg dGhhdCBzcGVjaWZpZXMgc3VwcG9ydGVkCiAgICAgIEF1dGhlbnRpY2F0aW9uIFNjaGVtZSBwcm9w ZXJ0aWVzLiAgSW5zdGVhZCBvZiB0aGUgc3RhbmRhcmQKICAgICAgQ2Fub25pY2FsIFZhbHVlcyBm b3IgdHlwZSwgdGhpcyBhdHRyaWJ1dGUgZGVmaW5lcyB0aGUgZm9sbG93aW5nCiAgICAgIENhbm9u aWNhbCBWYWx1ZXMgdG8gcmVwcmVzZW50IGNvbW1vbiBzY2hlbWVzOiBvYXV0aCwgb2F1dGgyLAog ICAgICBvYXV0aGJlYXJlcnRva2VuLCBodHRwYmFzaWMsIGFuZCBodHRwZGlnZXN0LiAgVG8gZW5h YmxlIHNlYW1sZXNzCiAgICAgIGRpc2NvdmVyeSBvZiBjb25maWd1cmF0aW9uLCB0aGUgU2Vydmlj ZSBQcm92aWRlciBTSE9VTEQsIHdpdGggdGhlCiAgICAgIGFwcHJvcHJpYXRlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zLCBtYWtlIHRoZQogICAgICBhdXRoZW50aWNhdGlvblNjaGVtZXMgYXR0cmli dXRlIHB1YmxpY2x5IGFjY2Vzc2libGUgd2l0aG91dCBwcmlvcgogICAgICBhdXRoZW50aWNhdGlv bi4gIFJFUVVJUkVELgoKICAgICAgbmFtZSAgVGhlIGNvbW1vbiBhdXRoZW50aWNhdGlvbiBzY2hl bWUgbmFtZTsgZS5nLiwgSFRUUCBCYXNpYy4KICAgICAgICAgUkVRVUlSRUQuCgogICAgICBkZXNj cmlwdGlvbiAgQSBkZXNjcmlwdGlvbiBvZiB0aGUgQXV0aGVudGljYXRpb24gU2NoZW1lLgogICAg ICAgICBSRVFVSVJFRC4KCiAgICAgIHNwZWNVcmwgIEEgSFRUUCBhZGRyZXNzYWJsZSBVUkwgcG9p bnRpbmcgdG8gdGhlIEF1dGhlbnRpY2F0aW9uCiAgICAgICAgIFNjaGVtZSdzIHNwZWNpZmljYXRp b24uICBPUFRJT05BTC4KCiAgICAgIGRvY3VtZW50YXRpb25VcmwgIEEgSFRUUCBhZGRyZXNzYWJs ZSBVUkwgcG9pbnRpbmcgdG8gdGhlCiAgICAgICAgIEF1dGhlbnRpY2F0aW9uIFNjaGVtZSdzIHVz YWdlIGRvY3VtZW50YXRpb24uICBPUFRJT05BTC4KCgoxMC4gIFJlc291cmNlIFNjaGVtYQoKICAg VGhlIFJlc291cmNlIHNjaGVtYSBzcGVjaWZpZXMgdGhlIEF0dHJpYnV0ZShzKSBhbmQgbWV0YS1k YXRhIHRoYXQKICAgY29uc3RpdHV0ZSBhIFJlc291cmNlLiAgU2NoZW1hIFJlc291cmNlcyBhcmUg UkVBRC1PTkxZIGFuZCBpZGVudGlmaWVkCiAgIHVzaW5nIHRoZSBmb2xsb3dpbmcgVVJJOiAndXJu OnNjaW06c2NoZW1hczpjb3JlOjEuMCcuICBVbmxpa2Ugb3RoZXIKICAgY29yZSBSZXNvdXJjZXMg dGhlIHNjaGVtYSBSZXNvdXJjZSBNQVkgY29udGFpbiBhIGNvbXBsZXggb2JqZWN0CiAgIHdpdGhp biBhIFN1Yi1BdHRyaWJ1dGUgYW5kIGFsbCBBdHRyaWJ1dGVzIGFyZSBSRVFVSVJFRCB1bmxlc3Mg b3RoZXIKICAgc3BlY2lmaWVkLgoKICAgVGhlIGZvbGxvd2luZyBTaW5ndWxhciBBdHRyaWJ1dGVz IGFyZSBkZWZpbmVkOgoKICAgbmFtZSAgVGhlIFJlc291cmNlIG5hbWUuICBXaGVuIGFwcGxpY2Fi bGUgU2VydmljZSBQcm92aWRlcnMgTVVTVAogICAgICBzcGVjaWZ5IHRoZSBuYW1lIHNwZWNpZmll ZCBpbiB0aGUgY29yZSBzY2hlbWEgc3BlY2lmaWNhdGlvbjsgZS5nLiwKICAgICAgIlVzZXIiIG9y ICJHcm91cCIuCgogICBkZXNjcmlwdGlvbiAgVGhlIFJlc291cmNlJ3MgaHVtYW4gcmVhZGFibGUg ZGVzY3JpcHRpb24uICBXaGVuCiAgICAgIGFwcGxpY2FibGUgU2VydmljZSBQcm92aWRlcnMgTVVT VCBzcGVjaWZ5IHRoZSBkZXNjcmlwdGlvbgogICAgICBzcGVjaWZpZWQgaW4gdGhlIGNvcmUgc2No ZW1hIHNwZWNpZmljYXRpb24uCgoKCgpNb3J0aW1vcmUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAxN10KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICBkcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAxICAgICAgICAgIE5vdmVtYmVyIDIwMTIK CgogICBzY2hlbWEgIFRoZSBSZXNvdXJjZSdzIGFzc29jaWF0ZWQgc2NoZW1hIFVSSTsgZS5nLiwK ICAgICAgdXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMC4KCiAgIGVuZHBvaW50ICBUaGUgUmVzb3Vy Y2UncyBIVFRQIGFkZHJlc3NhYmxlIGVuZHBvaW50IHJlbGF0aXZlIHRvIHRoZQogICAgICBCYXNl IFVSTDsgZS5nLiwgL1VzZXJzLgoKICAgVGhlIGZvbGxvd2luZyBtdWx0aS12YWx1ZWQgYXR0cmli dXRlIGlzIGRlZmluZWQ6CgogICBhdHRyaWJ1dGVzICBBIGNvbXBsZXggdHlwZSB0aGF0IHNwZWNp ZmllcyB0aGUgc2V0IG9mIFJlc291cmNlCiAgICAgIGF0dHJpYnV0ZXMuCgogICAgICBuYW1lICBU aGUgYXR0cmlidXRlJ3MgbmFtZS4KCiAgICAgIHR5cGUgIFRoZSBhdHRyaWJ1dGUncyBkYXRhIHR5 cGU7IGUuZy4sIFN0cmluZy4KCiAgICAgIG11bHRpVmFsdWVkICBCb29sZWFuIHZhbHVlIGluZGlj YXRpbmcgdGhlIGF0dHJpYnV0ZSdzIHBsdXJhbGl0eS4KCiAgICAgIGRlc2NyaXB0aW9uICBUaGUg YXR0cmlidXRlJ3MgaHVtYW4gcmVhZGFibGUgZGVzY3JpcHRpb24uICBXaGVuCiAgICAgICAgIGFw cGxpY2FibGUgU2VydmljZSBQcm92aWRlcnMgTVVTVCBzcGVjaWZ5IHRoZSBkZXNjcmlwdGlvbgog ICAgICAgICBzcGVjaWZpZWQgaW4gdGhlIGNvcmUgc2NoZW1hIHNwZWNpZmljYXRpb24uCgogICAg ICBzY2hlbWEgIFRoZSBhdHRyaWJ1dGUncyBhc3NvY2lhdGVkIHNjaGVtYTsgZS5nLiwKICAgICAg ICAgdXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMC4KCiAgICAgIHJlYWRPbmx5ICBBIEJvb2xlYW4g dmFsdWUgdGhhdCBzcGVjaWZpZXMgaWYgdGhlIGF0dHJpYnV0ZSBpcwogICAgICAgICBtdXRhYmxl LgoKICAgICAgcmVxdWlyZWQgIEEgQm9vbGVhbiB2YWx1ZSB0aGF0IHNwZWNpZmllcyBpZiB0aGUg YXR0cmlidXRlIGlzCiAgICAgICAgIHJlcXVpcmVkLgoKICAgICAgY2FzZUV4YWN0ICBBIEJvb2xl YW4gdmFsdWUgdGhhdCBzcGVjaWZpZXMgaWYgdGhlIFN0cmluZyBhdHRyaWJ1dGUKICAgICAgICAg aXMgY2FzZSBzZW5zaXRpdmUuCgogICAgICAgICBUaGUgZm9sbG93aW5nIG11bHRpLXZhbHVlZCBh dHRyaWJ1dGVzIGFyZSBkZWZpbmVkLiAgVGhlcmUgYXJlCiAgICAgICAgIG5vIGNhbm9uaWNhbCB0 eXBlIHZhbHVlcyBkZWZpbmVkIGFuZCB0aGUgcHJpbWFyeSB2YWx1ZSBzZXJ2ZXMKICAgICAgICAg bm8gdXNlZnVsIHB1cnBvc2UuCgogICAgICAgICBzdWJBdHRyaWJ1dGVzICBBIGxpc3Qgc3BlY2lm eWluZyB0aGUgY29udGFpbmVkIGF0dHJpYnV0ZXMuCiAgICAgICAgICAgIE9QVElPTkFMLgoKICAg ICAgICAgICAgbmFtZSAgVGhlIGF0dHJpYnV0ZSdzIG5hbWUuCgogICAgICAgICAgICB0eXBlICBU aGUgYXR0cmlidXRlJ3MgZGF0YSB0eXBlOyBlLmcuLCBTdHJpbmcuCgogICAgICAgICAgICBkZXNj cmlwdGlvbiAgVGhlIGF0dHJpYnV0ZSdzIGh1bWFuIHJlYWRhYmxlIGRlc2NyaXB0aW9uLgogICAg ICAgICAgICAgICBXaGVuIGFwcGxpY2FibGUgU2VydmljZSBQcm92aWRlcnMgTVVTVCBzcGVjaWZ5 IHRoZQogICAgICAgICAgICAgICBkZXNjcmlwdGlvbiBzcGVjaWZpZWQgaW4gdGhlIGNvcmUgc2No ZW1hIHNwZWNpZmljYXRpb24uCgoKCgpNb3J0aW1vcmUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICBkcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAxICAgICAgICAgIE5vdmVtYmVyIDIwMTIK CgogICAgICAgICAgICByZWFkT25seSAgQSBCb29sZWFuIHZhbHVlIHRoYXQgc3BlY2lmaWVzIGlm IHRoZSBhdHRyaWJ1dGUgaXMKICAgICAgICAgICAgICAgbXV0YWJsZS4KCiAgICAgICAgICAgIHJl cXVpcmVkICBBIEJvb2xlYW4gdmFsdWUgdGhhdCBzcGVjaWZpZXMgaWYgdGhlIGF0dHJpYnV0ZSBp cwogICAgICAgICAgICAgICByZXF1aXJlZC4KCiAgICAgICAgICAgIGNhc2VFeGFjdCAgQSBCb29s ZWFuIHZhbHVlIHRoYXQgc3BlY2lmaWVzIGlmIHRoZSBTdHJpbmcKICAgICAgICAgICAgICAgYXR0 cmlidXRlIGlzIGNhc2Ugc2Vuc2l0aXZlLgoKICAgICAgICAgICAgY2Fub25pY2FsVmFsdWVzICBB IGNvbGxlY3Rpb24gb2YgY2Fub25pY2FsIHZhbHVlcy4gIFdoZW4KICAgICAgICAgICAgICAgYXBw bGljYWJsZSBTZXJ2aWNlIFByb3ZpZGVycyBNVVNUIHNwZWNpZnkgdGhlIGNhbm9uaWNhbAogICAg ICAgICAgICAgICB0eXBlcyBzcGVjaWZpZWQgaW4gdGhlIGNvcmUgc2NoZW1hIHNwZWNpZmljYXRp b247CiAgICAgICAgICAgICAgIGUuZy4sIndvcmsiLCJob21lIi4gIE9QVElPTkFMLgoKCjExLiAg SlNPTiBSZXByZXNlbnRhdGlvbgoKMTEuMS4gIE1pbmltYWwgVXNlciBSZXByZXNlbnRhdGlvbgoK ICAgVGhlIGZvbGxvd2luZyBpcyBhIG5vbi1ub3JtYXRpdmUgZXhhbXBsZSBvZiB0aGUgbWluaW1h bCByZXF1aXJlZCBTQ0lNCiAgIHJlcHJlc2VudGF0aW9uIGluIEpTT04gZm9ybWF0LgoKICAgewog ICAgICJzY2hlbWFzIjogWyJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4wIl0sCiAgICAgImlkIjog IjI4MTljMjIzLTdmNzYtNDUzYS05MTlkLTQxMzg2MTkwNDY0NiIsCiAgICAgInVzZXJOYW1lIjog ImJqZW5zZW5AZXhhbXBsZS5jb20iCiAgIH0KCgoxMS4yLiAgRnVsbCBVc2VyIFJlcHJlc2VudGF0 aW9uCgogICBUaGUgZm9sbG93aW5nIGlzIGEgbm9uLW5vcm1hdGl2ZSBleGFtcGxlIG9mIHRoZSBm dWxseSBwb3B1bGF0ZWQgU0NJTQogICByZXByZXNlbnRhdGlvbiBpbiBKU09OIGZvcm1hdC4KCgp7 CiAgInNjaGVtYXMiOiBbInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiXSwKICAiaWQiOiAiMjgx OWMyMjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2IiwKICAiZXh0ZXJuYWxJZCI6ICI3MDE5 ODQiLAogICJ1c2VyTmFtZSI6ICJiamVuc2VuQGV4YW1wbGUuY29tIiwKICAibmFtZSI6IHsKICAg ICJmb3JtYXR0ZWQiOiAiTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJIiwKICAgICJmYW1pbHlOYW1l IjogIkplbnNlbiIsCiAgICAiZ2l2ZW5OYW1lIjogIkJhcmJhcmEiLAogICAgIm1pZGRsZU5hbWUi OiAiSmFuZSIsCiAgICAiaG9ub3JpZmljUHJlZml4IjogIk1zLiIsCiAgICAiaG9ub3JpZmljU3Vm Zml4IjogIklJSSIKICB9LAoKCgpNb3J0aW1vcmUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIE1h eSA1LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAxOV0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICBkcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAxICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgog ICJkaXNwbGF5TmFtZSI6ICJCYWJzIEplbnNlbiIsCiAgIm5pY2tOYW1lIjogIkJhYnMiLAogICJw cm9maWxlVXJsIjogImh0dHBzOi8vbG9naW4uZXhhbXBsZS5jb20vYmplbnNlbiIsCiAgImVtYWls cyI6IFsKICAgIHsKICAgICAgInZhbHVlIjogImJqZW5zZW5AZXhhbXBsZS5jb20iLAogICAgICAi dHlwZSI6ICJ3b3JrIiwKICAgICAgInByaW1hcnkiOiB0cnVlCiAgICB9LAogICAgewogICAgICAi dmFsdWUiOiAiYmFic0BqZW5zZW4ub3JnIiwKICAgICAgInR5cGUiOiAiaG9tZSIKICAgIH0KICBd LAogICJhZGRyZXNzZXMiOiBbCiAgICB7CiAgICAgICJ0eXBlIjogIndvcmsiLAogICAgICAic3Ry ZWV0QWRkcmVzcyI6ICIxMDAgVW5pdmVyc2FsIENpdHkgUGxhemEiLAogICAgICAibG9jYWxpdHki OiAiSG9sbHl3b29kIiwKICAgICAgInJlZ2lvbiI6ICJDQSIsCiAgICAgICJwb3N0YWxDb2RlIjog IjkxNjA4IiwKICAgICAgImNvdW50cnkiOiAiVVNBIiwKICAgICAgImZvcm1hdHRlZCI6ICIxMDAg VW5pdmVyc2FsIENpdHkgUGxhemFcbkhvbGx5d29vZCwgQ0EgOTE2MDggVVNBIiwKICAgICAgInBy aW1hcnkiOiB0cnVlCiAgICB9LAogICAgewogICAgICAidHlwZSI6ICJob21lIiwKICAgICAgInN0 cmVldEFkZHJlc3MiOiAiNDU2IEhvbGx5d29vZCBCbHZkIiwKICAgICAgImxvY2FsaXR5IjogIkhv bGx5d29vZCIsCiAgICAgICJyZWdpb24iOiAiQ0EiLAogICAgICAicG9zdGFsQ29kZSI6ICI5MTYw OCIsCiAgICAgICJjb3VudHJ5IjogIlVTQSIsCiAgICAgICJmb3JtYXR0ZWQiOiAiNDU2IEhvbGx5 d29vZCBCbHZkXG5Ib2xseXdvb2QsIENBIDkxNjA4IFVTQSIKICAgIH0KICBdLAogICJwaG9uZU51 bWJlcnMiOiBbCiAgICB7CiAgICAgICJ2YWx1ZSI6ICI1NTUtNTU1LTU1NTUiLAogICAgICAidHlw ZSI6ICJ3b3JrIgogICAgfSwKICAgIHsKICAgICAgInZhbHVlIjogIjU1NS01NTUtNDQ0NCIsCiAg ICAgICJ0eXBlIjogIm1vYmlsZSIKICAgIH0KICBdLAogICJpbXMiOiBbCiAgICB7CiAgICAgICJ2 YWx1ZSI6ICJzb21lYWltaGFuZGxlIiwKCgoKTW9ydGltb3JlLCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgMjBdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0wMSAgICAgICAgICBOb3ZlbWJlciAy MDEyCgoKICAgICAgInR5cGUiOiAiYWltIgogICAgfQogIF0sCiAgInBob3RvcyI6IFsKICAgIHsK ICAgICAgInZhbHVlIjogImh0dHBzOi8vcGhvdG9zLmV4YW1wbGUuY29tL3Byb2ZpbGVwaG90by83 MjkzMDAwMDAwMENjbmUvRiIsCiAgICAgICJ0eXBlIjogInBob3RvIgogICAgfSwKICAgIHsKICAg ICAgInZhbHVlIjogImh0dHBzOi8vcGhvdG9zLmV4YW1wbGUuY29tL3Byb2ZpbGVwaG90by83Mjkz MDAwMDAwMENjbmUvVCIsCiAgICAgICJ0eXBlIjogInRodW1ibmFpbCIKICAgIH0KICBdLAogICJ1 c2VyVHlwZSI6ICJFbXBsb3llZSIsCiAgInRpdGxlIjogIlRvdXIgR3VpZGUiLAogICJwcmVmZXJy ZWRMYW5ndWFnZSI6ImVuX1VTIiwKICAibG9jYWxlIjogImVuX1VTIiwKICAidGltZXpvbmUiOiAi QW1lcmljYS9Mb3NfQW5nZWxlcyIsCiAgImFjdGl2ZSI6dHJ1ZSwKICAicGFzc3dvcmQiOiJ0MW1l TWEkaGVlbiIsCiAgImdyb3VwcyI6IFsKICAgIHsKICAgICAgImRpc3BsYXkiOiAiVG91ciBHdWlk ZXMiLAogICAgICAidmFsdWUiOiAiMDAzMDAwMDAwMDVOMlk2QUEiCiAgICB9LAogICAgewogICAg ICAiZGlzcGxheSI6ICJFbXBsb3llZXMiLAogICAgICAidmFsdWUiOiAiMDAzMDAwMDAwMDVOMzRI NzgiCiAgICB9LAogICAgewogICAgICAiZGlzcGxheSI6ICJVUyBFbXBsb3llZXMiLAogICAgICAi dmFsdWUiOiAiMDAzMDAwMDAwMDVOOThZVDEiCiAgICB9CiAgXSwKICAieDUwOUNlcnRpZmljYXRl cyI6IFsKICAgIHsKICAgICAgInZhbHVlIjogIk1JSURRekNDQXF5Z0F3SUJBZ0lDRUFBd0RRWUpL b1pJaHZjTkFRRUZCUUF3VGpFTE1Ba0dBMVVFQmhNQ1ZWTXgKICAgICAgICAgICAgICAgIEV6QVJC Z05WQkFnTUNrTmhiR2xtYjNKdWFXRXhGREFTQmdOVkJBb01DMlY0WVcxd2JHVXVZMjl0TVJRd0Vn WUQKICAgICAgICAgICAgICAgIFZRUUREQXRsZUdGdGNHeGxMbU52YlRBZUZ3MHhNVEV3TWpJd05q STBNekZhRncweE1qRXdNRFF3TmpJME16RmEKICAgICAgICAgICAgICAgIE1IOHhDekFKQmdOVkJB WVRBbFZUTVJNd0VRWURWUVFJREFwRFlXeHBabTl5Ym1saE1SUXdFZ1lEVlFRS0RBdGwKICAgICAg ICAgICAgICAgIGVHRnRjR3hsTG1OdmJURWhNQjhHQTFVRUF3d1lUWE11SUVKaGNtSmhjbUVnU2lC S1pXNXpaVzRnU1VsSk1TSXcKICAgICAgICAgICAgICAgIElBWUpLb1pJaHZjTkFRa0JGaE5pYW1W dWMyVnVRR1Y0WVcxd2JHVXVZMjl0TUlJQklqQU5CZ2txaGtpRzl3MEIKICAgICAgICAgICAgICAg IEFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQTdLcitEY2RzL0pRNUd3ZWpKRmNCSVA2ODJYM3hwamlz NTZBSzAyYmMKICAgICAgICAgICAgICAgIDFGTGd6ZExJOGF1b1IrY0M5L1ZyaDV0NjZIa1FJT2RB NHVuSGgwQWFaNHhMNVBoVmJYSVBNQjV2QVBLcHp6NWkKICAgICAgICAgICAgICAgIFBTaTh4TzhT TDdJN1NEaGNCVkpocVZxcjNIZ2xsRUc2VUNsRGRITzdua0x1d1hxOEhjSVNLa2JUNVdGVFZmRloK ICAgICAgICAgICAgICAgIHppZFBsOEhaN0RoWGtaSVJ0SndCd2VxNGJ2bTNoTTFPczdVUUgwNVpT NmNWRGd3ZUtOd2RMTHJUNTFpa1NRRzMKICAgICAgICAgICAgICAgIERZcmwrZnQ3ODFVUVJJcXhn d3FDZlhFdURpaW5QaDBra3ZJaTVqaXZWdTFaOVFpd2xZRWRSYkxKNHpKUUJtRHIKICAgICAgICAg ICAgICAgIFNHVE1ZbjRsUmMySGdITzREcUIvYm5NVm9ySEIwQ0M2QVYxUW9GSzRHUGUxTHdJREFR QUJvM3N3ZVRBSkJnTlYKCgoKTW9ydGltb3JlLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBNYXkg NSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgMjFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0wMSAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAg ICAgICAgICAgICAgIEhSTUVBakFBTUN3R0NXQ0dTQUdHK0VJQkRRUWZGaDFQY0dWdVUxTk1JRWRs Ym1WeVlYUmxaQ0JEWlhKMGFXWnAKICAgICAgICAgICAgICAgIFkyRjBaVEFkQmdOVkhRNEVGZ1FV OHBEMFUwdnNaSXNhQTE2bEw4RW44YngwRi9nd0h3WURWUjBqQkJnd0ZvQVUKICAgICAgICAgICAg ICAgIGRHZUtpdGNhRjdnbnpzTndEeDcwOGtxYVZ0MHdEUVlKS29aSWh2Y05BUUVGQlFBRGdZRUFB ODFTc0ZuT2RZSnQKICAgICAgICAgICAgICAgIE5nNVRjcSsvQnlFRHJCZ251c3gwamxvVWhCeVBN RVZrb01aM0o3ajFaZ0k4ckFiT2tObmdYOCtwS2ZUaUR6MVIKICAgICAgICAgICAgICAgIEM0K2R4 OG9VNlphKzROSlhVamxMNUN2VjZCRVliMStRQUVKd2l0VFZ2eEIvQTY3ZzQyL3Z6Z0F0b1JVZURv djEKICAgICAgICAgICAgICAgICtHRmlCWitHTkYvY0FZS2NNdEdjcnMyaTk3WmtKTW89IgogICAg fQogIF0sCiAgIm1ldGEiOiB7CiAgICAiY3JlYXRlZCI6ICIyMDEwLTAxLTIzVDA0OjU2OjIyWiIs CiAgICAibGFzdE1vZGlmaWVkIjogIjIwMTEtMDUtMTNUMDQ6NDI6MzRaIiwKICAgICJ2ZXJzaW9u IjogIldcL1wiYTMzMGJjNTRmMDY3MWM5XCIiLAogICAgImxvY2F0aW9uIjogImh0dHBzOi8vZXhh bXBsZS5jb20vdjEvVXNlcnMvMjgxOWMyMjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2Igog IH0KfQoKMTEuMy4gIEVudGVycHJpc2UgVXNlciBFeHRlbnNpb24gUmVwcmVzZW50YXRpb24KCiAg IFRoZSBmb2xsb3dpbmcgaXMgYSBub24tbm9ybWF0aXZlIGV4YW1wbGUgb2YgdGhlIGZ1bGx5IHBv cHVsYXRlZCBVc2VyCiAgIHVzaW5nIHRoZSBlbnRlcnByaXNlIFVzZXIgZXh0ZW5zaW9uIGluIEpT T04gZm9ybWF0LgoKCnsKICAic2NoZW1hcyI6IFsidXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCIs ICJ1cm46c2NpbTpzY2hlbWFzOmV4dGVuc2lvbjplbnRlcnByaXNlOjEuMCJdLAogICJpZCI6ICIy ODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5MDQ2NDYiLAogICJleHRlcm5hbElkIjogIjcw MTk4NCIsCiAgInVzZXJOYW1lIjogImJqZW5zZW5AZXhhbXBsZS5jb20iLAogICJuYW1lIjogewog ICAgImZvcm1hdHRlZCI6ICJNcy4gQmFyYmFyYSBKIEplbnNlbiBJSUkiLAogICAgImZhbWlseU5h bWUiOiAiSmVuc2VuIiwKICAgICJnaXZlbk5hbWUiOiAiQmFyYmFyYSIsCiAgICAibWlkZGxlTmFt ZSI6ICJKYW5lIiwKICAgICJob25vcmlmaWNQcmVmaXgiOiAiTXMuIiwKICAgICJob25vcmlmaWNT dWZmaXgiOiAiSUlJIgogIH0sCiAgImRpc3BsYXlOYW1lIjogIkJhYnMgSmVuc2VuIiwKICAibmlj a05hbWUiOiAiQmFicyIsCiAgInByb2ZpbGVVcmwiOiAiaHR0cHM6Ly9sb2dpbi5leGFtcGxlLmNv bS9iamVuc2VuIiwKICAiZW1haWxzIjogWwogICAgewogICAgICAidmFsdWUiOiAiYmplbnNlbkBl eGFtcGxlLmNvbSIsCiAgICAgICJ0eXBlIjogIndvcmsiLAogICAgICAicHJpbWFyeSI6IHRydWUK ICAgIH0sCiAgICB7CiAgICAgICJ2YWx1ZSI6ICJiYWJzQGplbnNlbi5vcmciLAogICAgICAidHlw ZSI6ICJob21lIgogICAgfQoKCgpNb3J0aW1vcmUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIE1h eSA1LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAyMl0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICBkcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAxICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgog IF0sCiAgImFkZHJlc3NlcyI6IFsKICAgIHsKICAgICAgInN0cmVldEFkZHJlc3MiOiAiMTAwIFVu aXZlcnNhbCBDaXR5IFBsYXphIiwKICAgICAgImxvY2FsaXR5IjogIkhvbGx5d29vZCIsCiAgICAg ICJyZWdpb24iOiAiQ0EiLAogICAgICAicG9zdGFsQ29kZSI6ICI5MTYwOCIsCiAgICAgICJjb3Vu dHJ5IjogIlVTQSIsCiAgICAgICJmb3JtYXR0ZWQiOiAiMTAwIFVuaXZlcnNhbCBDaXR5IFBsYXph XG5Ib2xseXdvb2QsIENBIDkxNjA4IFVTQSIsCiAgICAgICJ0eXBlIjogIndvcmsiLAogICAgICAi cHJpbWFyeSI6IHRydWUKICAgIH0sCiAgICB7CiAgICAgICJzdHJlZXRBZGRyZXNzIjogIjQ1NiBI b2xseXdvb2QgQmx2ZCIsCiAgICAgICJsb2NhbGl0eSI6ICJIb2xseXdvb2QiLAogICAgICAicmVn aW9uIjogIkNBIiwKICAgICAgInBvc3RhbENvZGUiOiAiOTE2MDgiLAogICAgICAiY291bnRyeSI6 ICJVU0EiLAogICAgICAiZm9ybWF0dGVkIjogIjQ1NiBIb2xseXdvb2QgQmx2ZFxuSG9sbHl3b29k LCBDQSA5MTYwOCBVU0EiLAogICAgICAidHlwZSI6ICJob21lIgogICAgIH0KICBdLAogICJwaG9u ZU51bWJlcnMiOiBbCiAgICB7CiAgICAgICJ2YWx1ZSI6ICI1NTUtNTU1LTU1NTUiLAogICAgICAi dHlwZSI6ICJ3b3JrIgogICAgfSwKICAgIHsKICAgICAgInZhbHVlIjogIjU1NS01NTUtNDQ0NCIs CiAgICAgICJ0eXBlIjogIm1vYmlsZSIKICAgIH0KICBdLAogICJpbXMiOiBbCiAgICB7CiAgICAg ICJ2YWx1ZSI6ICJzb21lYWltaGFuZGxlIiwKICAgICAgInR5cGUiOiAiYWltIgogICAgfQogIF0s CiAgInBob3RvcyI6IFsKICAgIHsKICAgICAgInZhbHVlIjogImh0dHBzOi8vcGhvdG9zLmV4YW1w bGUuY29tL3Byb2ZpbGVwaG90by83MjkzMDAwMDAwMENjbmUvRiIsCiAgICAgICJ0eXBlIjogInBo b3RvIgogICAgfSwKICAgIHsKICAgICAgInZhbHVlIjogImh0dHBzOi8vcGhvdG9zLmV4YW1wbGUu Y29tL3Byb2ZpbGVwaG90by83MjkzMDAwMDAwMENjbmUvVCIsCiAgICAgICJ0eXBlIjogInRodW1i bmFpbCIKICAgIH0KICBdLAoKCgpNb3J0aW1vcmUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIE1h eSA1LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAyM10KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICBkcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAxICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgog ICJ1c2VyVHlwZSI6ICJFbXBsb3llZSIsCiAgInRpdGxlIjogIlRvdXIgR3VpZGUiLAogICJwcmVm ZXJyZWRMYW5ndWFnZSI6ImVuX1VTIiwKICAibG9jYWxlIjogImVuX1VTIiwKICAidGltZXpvbmUi OiAiQW1lcmljYS9Mb3NfQW5nZWxlcyIsCiAgImFjdGl2ZSI6dHJ1ZSwKICAicGFzc3dvcmQiOiJ0 MW1lTWEkaGVlbiIsCiAgImdyb3VwcyI6IFsKICAgIHsKICAgICAgInZhbHVlIjogImU5ZTMwZGJh LWYwOGYtNDEwOS04NDg2LWQ1YzZhMzMxNjYwYSIsCiAgICAgICJkaXNwbGF5IjogIlRvdXIgR3Vp ZGVzIgogICAgfSwKICAgIHsKICAgICAgInZhbHVlIjogImZjMzQ4YWE4LTM4MzUtNDBlYi1hMjBi LWM3MjZlMTVjNTViNSIsCiAgICAgICJkaXNwbGF5IjogIkVtcGxveWVlcyIKICAgIH0sCiAgICB7 CiAgICAgICJ2YWx1ZSI6ICI3MWRkYWNkMi1hOGU3LTQ5YjgtYTVkYi1hZTUwZDBhNWJmZDciLAog ICAgICAiZGlzcGxheSI6ICJVUyBFbXBsb3llZXMiCiAgICB9CiAgXSwKICAieDUwOUNlcnRpZmlj YXRlcyI6IFsKICAgIHsKICAgICAgInZhbHVlIjogIk1JSURRekNDQXF5Z0F3SUJBZ0lDRUFBd0RR WUpLb1pJaHZjTkFRRUZCUUF3VGpFTE1Ba0dBMVVFQmhNQ1ZWTXgKICAgICAgICAgICAgICAgIEV6 QVJCZ05WQkFnTUNrTmhiR2xtYjNKdWFXRXhGREFTQmdOVkJBb01DMlY0WVcxd2JHVXVZMjl0TVJR d0VnWUQKICAgICAgICAgICAgICAgIFZRUUREQXRsZUdGdGNHeGxMbU52YlRBZUZ3MHhNVEV3TWpJ d05qSTBNekZhRncweE1qRXdNRFF3TmpJME16RmEKICAgICAgICAgICAgICAgIE1IOHhDekFKQmdO VkJBWVRBbFZUTVJNd0VRWURWUVFJREFwRFlXeHBabTl5Ym1saE1SUXdFZ1lEVlFRS0RBdGwKICAg ICAgICAgICAgICAgIGVHRnRjR3hsTG1OdmJURWhNQjhHQTFVRUF3d1lUWE11SUVKaGNtSmhjbUVn U2lCS1pXNXpaVzRnU1VsSk1TSXcKICAgICAgICAgICAgICAgIElBWUpLb1pJaHZjTkFRa0JGaE5p YW1WdWMyVnVRR1Y0WVcxd2JHVXVZMjl0TUlJQklqQU5CZ2txaGtpRzl3MEIKICAgICAgICAgICAg ICAgIEFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQTdLcitEY2RzL0pRNUd3ZWpKRmNCSVA2ODJYM3hw amlzNTZBSzAyYmMKICAgICAgICAgICAgICAgIDFGTGd6ZExJOGF1b1IrY0M5L1ZyaDV0NjZIa1FJ T2RBNHVuSGgwQWFaNHhMNVBoVmJYSVBNQjV2QVBLcHp6NWkKICAgICAgICAgICAgICAgIFBTaTh4 TzhTTDdJN1NEaGNCVkpocVZxcjNIZ2xsRUc2VUNsRGRITzdua0x1d1hxOEhjSVNLa2JUNVdGVFZm RloKICAgICAgICAgICAgICAgIHppZFBsOEhaN0RoWGtaSVJ0SndCd2VxNGJ2bTNoTTFPczdVUUgw NVpTNmNWRGd3ZUtOd2RMTHJUNTFpa1NRRzMKICAgICAgICAgICAgICAgIERZcmwrZnQ3ODFVUVJJ cXhnd3FDZlhFdURpaW5QaDBra3ZJaTVqaXZWdTFaOVFpd2xZRWRSYkxKNHpKUUJtRHIKICAgICAg ICAgICAgICAgIFNHVE1ZbjRsUmMySGdITzREcUIvYm5NVm9ySEIwQ0M2QVYxUW9GSzRHUGUxTHdJ REFRQUJvM3N3ZVRBSkJnTlYKICAgICAgICAgICAgICAgIEhSTUVBakFBTUN3R0NXQ0dTQUdHK0VJ QkRRUWZGaDFQY0dWdVUxTk1JRWRsYm1WeVlYUmxaQ0JEWlhKMGFXWnAKICAgICAgICAgICAgICAg IFkyRjBaVEFkQmdOVkhRNEVGZ1FVOHBEMFUwdnNaSXNhQTE2bEw4RW44YngwRi9nd0h3WURWUjBq QkJnd0ZvQVUKICAgICAgICAgICAgICAgIGRHZUtpdGNhRjdnbnpzTndEeDcwOGtxYVZ0MHdEUVlK S29aSWh2Y05BUUVGQlFBRGdZRUFBODFTc0ZuT2RZSnQKICAgICAgICAgICAgICAgIE5nNVRjcSsv QnlFRHJCZ251c3gwamxvVWhCeVBNRVZrb01aM0o3ajFaZ0k4ckFiT2tObmdYOCtwS2ZUaUR6MVIK ICAgICAgICAgICAgICAgIEM0K2R4OG9VNlphKzROSlhVamxMNUN2VjZCRVliMStRQUVKd2l0VFZ2 eEIvQTY3ZzQyL3Z6Z0F0b1JVZURvdjEKICAgICAgICAgICAgICAgICtHRmlCWitHTkYvY0FZS2NN dEdjcnMyaTk3WmtKTW89IgogICAgfQogIF0sCiAgInVybjpzY2ltOnNjaGVtYXM6ZXh0ZW5zaW9u OmVudGVycHJpc2U6MS4wIjogewogICAgImVtcGxveWVlTnVtYmVyIjogIjcwMTk4NCIsCiAgICAi Y29zdENlbnRlciI6ICI0MTMwIiwKICAgICJvcmdhbml6YXRpb24iOiAiVW5pdmVyc2FsIFN0dWRp b3MiLAogICAgImRpdmlzaW9uIjogIlRoZW1lIFBhcmsiLAoKCgpNb3J0aW1vcmUsIGV0IGFsLiAg ICAgICAgICBFeHBpcmVzIE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAyNF0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICBkcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAxICAgICAgICAg IE5vdmVtYmVyIDIwMTIKCgogICAgImRlcGFydG1lbnQiOiAiVG91ciBPcGVyYXRpb25zIiwKICAg ICJtYW5hZ2VyIjogewogICAgICAibWFuYWdlcklkIjogIjI2MTE4OTE1LTYwOTAtNDYxMC04N2U0 LTQ5ZDhjYTlmODA4ZCIsCiAgICAgICJkaXNwbGF5TmFtZSI6ICJKb2huIFNtaXRoIgogICAgfQog IH0sCiAgIm1ldGEiOiB7CiAgICAiY3JlYXRlZCI6ICIyMDEwLTAxLTIzVDA0OjU2OjIyWiIsCiAg ICAibGFzdE1vZGlmaWVkIjogIjIwMTEtMDUtMTNUMDQ6NDI6MzRaIiwKICAgICJ2ZXJzaW9uIjog IldcL1wiMzY5NGUwNWU5ZGZmNTkxXCIiLAogICAgImxvY2F0aW9uIjogImh0dHBzOi8vZXhhbXBs ZS5jb20vdjEvVXNlcnMvMjgxOWMyMjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2IgogIH0K fQoKCjExLjQuICBHcm91cCBSZXByZXNlbnRhdGlvbgoKICAgVGhlIGZvbGxvd2luZyBpcyBhIG5v bi1ub3JtYXRpdmUgZXhhbXBsZSBvZiBTQ0lNIEdyb3VwIHJlcHJlc2VudGF0aW9uCiAgIGluIEpT T04gZm9ybWF0LgoKCiAgIHsKICAgICAic2NoZW1hcyI6IFsidXJuOnNjaW06c2NoZW1hczpjb3Jl OjEuMCJdLAogICAgICJpZCI6ICJlOWUzMGRiYS1mMDhmLTQxMDktODQ4Ni1kNWM2YTMzMTY2MGEi LAogICAgICJkaXNwbGF5TmFtZSI6ICJUb3VyIEd1aWRlcyIsCiAgICAgIm1lbWJlcnMiOiBbCiAg ICAgICB7CiAgICAgICAgICJ2YWx1ZSI6ICIyODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5 MDQ2NDYiLAogICAgICAgICAiZGlzcGxheSI6ICJCYWJzIEplbnNlbiIKICAgICAgIH0sCiAgICAg ICB7CiAgICAgICAgICJ2YWx1ZSI6ICI5MDJjMjQ2Yi02MjQ1LTQxOTAtOGUwNS0wMDgxNmJlNzM0 NGEiLAogICAgICAgICAiZGlzcGxheSI6ICJNYW5keSBQZXBwZXJpZGdlIgogICAgICAgfQogICAg IF0KICAgfQoKCjExLjUuICBTZXJ2aWNlIFByb3ZpZGVyIENvbmZpZ3VyYXRpb24gUmVwcmVzZW50 YXRpb24KCiAgIFRoZSBmb2xsb3dpbmcgaXMgYSBub24tbm9ybWF0aXZlIGV4YW1wbGUgb2YgdGhl IFNDSU0gU2VydmljZSBQcm92aWRlcgogICBDb25maWd1cmF0aW9uIHJlcHJlc2VudGF0aW9uIGlu IEpTT04gZm9ybWF0LgoKCgoKCgoKCgpNb3J0aW1vcmUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAyNV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICBkcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAxICAgICAgICAgIE5vdmVtYmVyIDIwMTIK Cgp7CiAgInNjaGVtYXMiOiBbInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiXSwKICAiZG9jdW1l bnRhdGlvblVybCI6Imh0dHA6Ly9leGFtcGxlLmNvbS9oZWxwL3NjaW0uaHRtbCIsCiAgInBhdGNo IjogewogICAgInN1cHBvcnRlZCI6dHJ1ZQogIH0sCiAgImJ1bGsiOiB7CiAgICAic3VwcG9ydGVk Ijp0cnVlLAogICAgIm1heE9wZXJhdGlvbnMiOjEwMDAsCiAgICAibWF4UGF5bG9hZFNpemUiOjEw NDg1NzYKICB9LAogICJmaWx0ZXIiOiB7CiAgICAic3VwcG9ydGVkIjp0cnVlLAogICAgIm1heFJl c3VsdHMiOiAyMDAKICB9LAogICJjaGFuZ2VQYXNzd29yZCIgOiB7CiAgICAic3VwcG9ydGVkIjp0 cnVlCiAgfSwKICAic29ydCI6IHsKICAgICJzdXBwb3J0ZWQiOnRydWUKICB9LAogICJldGFnIjog ewogICAgInN1cHBvcnRlZCI6dHJ1ZQogIH0sCiAgImF1dGhlbnRpY2F0aW9uU2NoZW1lcyI6IFsK ICAgIHsKICAgICAgIm5hbWUiOiAiT0F1dGggQmVhcmVyIFRva2VuIiwKICAgICAgImRlc2NyaXB0 aW9uIjogIkF1dGhlbnRpY2F0aW9uIFNjaGVtZSB1c2luZyB0aGUgT0F1dGggQmVhcmVyIFRva2Vu IFN0YW5kYXJkIiwKICAgICAgInNwZWNVcmwiOiJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wMSIsCiAgICAgICJkb2N1bWVudGF0aW9uVXJsIjoi aHR0cDovL2V4YW1wbGUuY29tL2hlbHAvb2F1dGguaHRtbCIsCiAgICAgICJ0eXBlIjoib2F1dGhi ZWFyZXJ0b2tlbiIsCiAgICAgICJwcmltYXJ5IjogdHJ1ZQogICAgfSwKICAgIHsKICAgICAgIm5h bWUiOiAiSFRUUCBCYXNpYyIsCiAgICAgICJkZXNjcmlwdGlvbiI6ICJBdXRoZW50aWNhdGlvbiBT Y2hlbWUgdXNpbmcgdGhlIEh0dHAgQmFzaWMgU3RhbmRhcmQiLAogICAgICAic3BlY1VybCI6Imh0 dHA6Ly93d3cuaWV0Zi5vcmcvcmZjL3JmYzI2MTcudHh0IiwKICAgICAgImRvY3VtZW50YXRpb25V cmwiOiJodHRwOi8vZXhhbXBsZS5jb20vaGVscC9odHRwQmFzaWMuaHRtbCIsCiAgICAgICJ0eXBl IjoiaHR0cGJhc2ljIgogICAgIH0KICBdCn0KCgoKCgoKCgoKTW9ydGltb3JlLCBldCBhbC4gICAg ICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgMjZdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0wMSAgICAgICAgICBO b3ZlbWJlciAyMDEyCgoKMTEuNi4gIFJlc291cmNlIFNjaGVtYSBSZXByZXNlbnRhdGlvbgoKICAg VGhlIGZvbGxvd2luZyBpcyBhIG5vcm1hdGl2ZSBleGFtcGxlIG9mIHRoZSBTQ0lNIFJlc291cmNl IFNjaGVtYQogICByZXByZXNlbnRhdGlvbiBpbiBKU09OIGZvcm1hdC4KCnsKICAiaWQiOiJ1cm46 c2NpbTpzY2hlbWFzOmNvcmU6MS4wOlVzZXIiLAogICJuYW1lIjoiVXNlciIsCiAgImRlc2NyaXB0 aW9uIjoiQ29yZSBVc2VyIiwKICAic2NoZW1hIjoidXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCIs CiAgImVuZHBvaW50IjoiL1VzZXJzIiwKICAiYXR0cmlidXRlcyI6WwogICAgewogICAgICAibmFt ZSI6ImlkIiwKICAgICAgInR5cGUiOiJzdHJpbmciLAogICAgICAibXVsdGlWYWx1ZWQiOmZhbHNl LAogICAgICAiZGVzY3JpcHRpb24iOiJVbmlxdWUgaWRlbnRpZmllciBmb3IgdGhlIFNDSU0gcmVz b3VyY2UgYXMgZGVmaW5lZCBieSB0aGUgU2VydmljZSBQcm92aWRlci4gRWFjaCByZXByZXNlbnRh dGlvbiBvZiB0aGUgcmVzb3VyY2UgTVVTVCBpbmNsdWRlIGEgbm9uLWVtcHR5IGlkIHZhbHVlLiBU aGlzIGlkZW50aWZpZXIgTVVTVCBiZSB1bmlxdWUgYWNyb3NzIHRoZSBTZXJ2aWNlIFByb3ZpZGVy J3MgZW50aXJlIHNldCBvZiByZXNvdXJjZXMuIEl0IE1VU1QgYmUgYSBzdGFibGUsIG5vbi1yZWFz c2lnbmFibGUgaWRlbnRpZmllciB0aGF0IGRvZXMgbm90IGNoYW5nZSB3aGVuIHRoZSBzYW1lIHJl c291cmNlIGlzIHJldHVybmVkIGluIHN1YnNlcXVlbnQgcmVxdWVzdHMuIFRoZSB2YWx1ZSBvZiB0 aGUgaWQgYXR0cmlidXRlIGlzIGFsd2F5cyBpc3N1ZWQgYnkgdGhlIFNlcnZpY2UgUHJvdmlkZXIg YW5kIE1VU1QgbmV2ZXIgYmUgc3BlY2lmaWVkIGJ5IHRoZSBTZXJ2aWNlIENvbnN1bWVyLiBSRVFV SVJFRC4iLAogICAgICAic2NoZW1hIjoidXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCIsCiAgICAg ICJyZWFkT25seSI6dHJ1ZSwKICAgICAgInJlcXVpcmVkIjp0cnVlLAogICAgICAiY2FzZUV4YWN0 IjpmYWxzZQogICAgfSwKICAgIHsKICAgICAgIm5hbWUiOiJuYW1lIiwKICAgICAgInR5cGUiOiJj b21wbGV4IiwKICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgImRlc2NyaXB0aW9uIjoi VGhlIGNvbXBvbmVudHMgb2YgdGhlIHVzZXIncyByZWFsIG5hbWUuIFByb3ZpZGVycyBNQVkgcmV0 dXJuIGp1c3QgdGhlIGZ1bGwgbmFtZSBhcyBhIHNpbmdsZSBzdHJpbmcgaW4gdGhlIGZvcm1hdHRl ZCBzdWItYXR0cmlidXRlLCBvciB0aGV5IE1BWSByZXR1cm4ganVzdCB0aGUgaW5kaXZpZHVhbCBj b21wb25lbnQgYXR0cmlidXRlcyB1c2luZyB0aGUgb3RoZXIgc3ViLWF0dHJpYnV0ZXMsIG9yIHRo ZXkgTUFZIHJldHVybiBib3RoLiBJZiBib3RoIHZhcmlhbnRzIGFyZSByZXR1cm5lZCwgdGhleSBT SE9VTEQgYmUgZGVzY3JpYmluZyB0aGUgc2FtZSBuYW1lLCB3aXRoIHRoZSBmb3JtYXR0ZWQgbmFt ZSBpbmRpY2F0aW5nIGhvdyB0aGUgY29tcG9uZW50IGF0dHJpYnV0ZXMgc2hvdWxkIGJlIGNvbWJp bmVkLiIsCiAgICAgICJzY2hlbWEiOiJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4wIiwKICAgICAg InJlYWRPbmx5IjpmYWxzZSwKICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgImNhc2VFeGFj dCI6ZmFsc2UsCiAgICAgICJzdWJBdHRyaWJ1dGVzIjpbCiAgICAgICAgewogICAgICAgICAgIm5h bWUiOiJmb3JtYXR0ZWQiLAogICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAgIm11 bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAgICJkZXNjcmlwdGlvbiI6IlRoZSBmdWxsIG5hbWUs IGluY2x1ZGluZyBhbGwgbWlkZGxlIG5hbWVzLCB0aXRsZXMsIGFuZCBzdWZmaXhlcyBhcyBhcHBy b3ByaWF0ZSwgZm9ybWF0dGVkIGZvciBkaXNwbGF5IChlLmcuIE1zLiBCYXJiYXJhIEogSmVuc2Vu LCBJSUkuKS4iICwKICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAicmVxdWly ZWQiOmZhbHNlLAogICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICB9LAogICAgICAg IHsKICAgICAgICAgICJuYW1lIjoiZmFtaWx5TmFtZSIsCiAgICAgICAgICAidHlwZSI6InN0cmlu ZyIsCiAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgImRlc2NyaXB0aW9u IjoiVGhlIGZhbWlseSBuYW1lIG9mIHRoZSBVc2VyLCBvciBMYXN0IE5hbWUgaW4gbW9zdCBXZXN0 ZXJuIGxhbmd1YWdlcyAoZS5nLiBKZW5zZW4gZ2l2ZW4gdGhlIGZ1bGwgbmFtZSBNcy4gQmFyYmFy YSBKIEplbnNlbiwgSUlJLikuIiwKICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAg ICAicmVxdWlyZWQiOmZhbHNlLAoKCgpNb3J0aW1vcmUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IE1heSA1LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAyN10KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICBkcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAxICAgICAgICAgIE5vdmVtYmVyIDIwMTIK CgogICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICB9LAogICAgICAgIHsKICAgICAg ICAgICJuYW1lIjoiZ2l2ZW5OYW1lIiwKICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAg ICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAiZGVzY3JpcHRpb24iOiJUaGUgZ2l2 ZW4gbmFtZSBvZiB0aGUgVXNlciwgb3IgRmlyc3QgTmFtZSBpbiBtb3N0IFdlc3Rlcm4gbGFuZ3Vh Z2VzIChlLmcuIEJhcmJhcmEgZ2l2ZW4gdGhlIGZ1bGwgbmFtZSBNcy4gQmFyYmFyYSBKIEplbnNl biwgSUlJLikuIiwKICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAicmVxdWly ZWQiOmZhbHNlLAogICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICB9LAogICAgICAg IHsKICAgICAgICAgICJuYW1lIjoibWlkZGxlTmFtZSIsCiAgICAgICAgICAidHlwZSI6InN0cmlu ZyIsCiAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgImRlc2NyaXB0aW9u IjoiVGhlIG1pZGRsZSBuYW1lKHMpIG9mIHRoZSBVc2VyIChlLmcuIFJvYmVydCBnaXZlbiB0aGUg ZnVsbCBuYW1lIE1zLiBCYXJiYXJhIEogSmVuc2VuLCBJSUkuKS4iLAogICAgICAgICAgInJlYWRP bmx5IjpmYWxzZSwKICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAiY2FzZUV4 YWN0IjpmYWxzZQogICAgICAgIH0sCiAgICAgICAgewogICAgICAgICAgIm5hbWUiOiJob25vcmlm aWNQcmVmaXgiLAogICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAgIm11bHRpVmFs dWVkIjpmYWxzZSwKICAgICAgICAgICJkZXNjcmlwdGlvbiI6IlRoZSBob25vcmlmaWMgcHJlZml4 KGVzKSBvZiB0aGUgVXNlciwgb3IgVGl0bGUgaW4gbW9zdCBXZXN0ZXJuIGxhbmd1YWdlcyAoZS5n LiBNcy4gZ2l2ZW4gdGhlIGZ1bGwgbmFtZSBNcy4gQmFyYmFyYSBKIEplbnNlbiwgSUlJLikuIiwK ICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAog ICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICB9LAogICAgICAgIHsKICAgICAgICAg ICJuYW1lIjoiaG9ub3JpZmljU3VmZml4IiwKICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAg ICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAgICAgICAiZGVzY3JpcHRpb24iOiJUaGUg aG9ub3JpZmljIHN1ZmZpeChlcykgb2YgdGhlIFVzZXIsIG9yIFN1ZmZpeCBpbiBtb3N0IFdlc3Rl cm4gbGFuZ3VhZ2VzIChlLmcuIElJSS4gZ2l2ZW4gdGhlIGZ1bGwgbmFtZSBNcy4gQmFyYmFyYSBK IEplbnNlbiwgSUlJLikuIiwKICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAi cmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAgICAgICB9CiAg ICAgIF0KICAgICB9LAogICAgIHsKICAgICAgICJuYW1lIjoiZW1haWxzIiwKICAgICAgICJ0eXBl IjoiY29tcGxleCIsCiAgICAgICAibXVsdGlWYWx1ZWQiOnRydWUsCiAgICAgICAiZGVzY3JpcHRp b24iOiJFLW1haWwgYWRkcmVzc2VzIGZvciB0aGUgdXNlci4gVGhlIHZhbHVlIFNIT1VMRCBiZSBj YW5vbmljYWxpemVkIGJ5IHRoZSBTZXJ2aWNlIFByb3ZpZGVyLCBlLmcuIGJqZW5zZW5AZXhhbXBs ZS5jb20gaW5zdGVhZCBvZiBiamVuc2VuQEVYQU1QTEUuQ09NLiBDYW5vbmljYWwgVHlwZSB2YWx1 ZXMgb2Ygd29yaywgaG9tZSwgYW5kIG90aGVyLiIsCiAgICAgICAic2NoZW1hIjoidXJuOnNjaW06 c2NoZW1hczpjb3JlOjEuMCIsCiAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAgICAgInJlcXVp cmVkIjpmYWxzZSwKCgoKTW9ydGltb3JlLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBNYXkgNSwg MjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgMjhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0wMSAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAgICAg ICJjYXNlRXhhY3QiOmZhbHNlLAogICAgICAgInN1YkF0dHJpYnV0ZXMiOlsKICAgICAgICAgewog ICAgICAgICAgICJuYW1lIjoidmFsdWUiLAogICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAg ICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICJkZXNjcmlwdGlvbiI6IkUt bWFpbCBhZGRyZXNzZXMgZm9yIHRoZSB1c2VyLiBUaGUgdmFsdWUgU0hPVUxEIGJlIGNhbm9uaWNh bGl6ZWQgYnkgdGhlIFNlcnZpY2UgUHJvdmlkZXIsIGUuZy4gYmplbnNlbkBleGFtcGxlLmNvbSBp bnN0ZWFkIG9mIGJqZW5zZW5ARVhBTVBMRS5DT00uIENhbm9uaWNhbCBUeXBlIHZhbHVlcyBvZiB3 b3JrLCBob21lLCBhbmQgb3RoZXIuIiwKICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNlLAogICAg ICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAgImNhc2VFeGFjdCI6ZmFsc2UKICAg ICAgICAgfSwKICAgICAgICAgewogICAgICAgICAgICJuYW1lIjoiZGlzcGxheSIsCiAgICAgICAg ICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFsc2UsCiAgICAg ICAgICAgImRlc2NyaXB0aW9uIjoiQSBodW1hbiByZWFkYWJsZSBuYW1lLCBwcmltYXJpbHkgdXNl ZCBmb3IgZGlzcGxheSBwdXJwb3Nlcy4gUkVBRC1PTkxZLiIsCiAgICAgICAgICAgInJlYWRPbmx5 Ijp0cnVlLAogICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAgImNhc2VFeGFj dCI6ZmFsc2UKICAgICAgICAgfSwKICAgICAgICAgewogICAgICAgICAgICJuYW1lIjoidHlwZSIs CiAgICAgICAgICAgInR5cGUiOiJzdHJpbmciLAogICAgICAgICAgICJtdWx0aVZhbHVlZCI6ZmFs c2UsCiAgICAgICAgICAgImRlc2NyaXB0aW9uIjoiQSBsYWJlbCBpbmRpY2F0aW5nIHRoZSBhdHRy aWJ1dGUncyBmdW5jdGlvbjsgZS5nLiwgJ3dvcmsnIG9yICdob21lJy4iLAogICAgICAgICAgICJy ZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAi Y2FzZUV4YWN0IjpmYWxzZSwKICAgICAgICAgICAiY2Fub25pY2FsVmFsdWVzIjpbIndvcmsiLCJo b21lIiwib3RoZXIiXQogICAgICAgICB9LAogICAgICAgICB7CiAgICAgICAgICAgIm5hbWUiOiJw cmltYXJ5IiwKICAgICAgICAgICAidHlwZSI6ImJvb2xlYW4iLAogICAgICAgICAgICJtdWx0aVZh bHVlZCI6ZmFsc2UsCiAgICAgICAgICAgImRlc2NyaXB0aW9uIjoiQSBCb29sZWFuIHZhbHVlIGlu ZGljYXRpbmcgdGhlICdwcmltYXJ5JyBvciBwcmVmZXJyZWQgYXR0cmlidXRlIHZhbHVlIGZvciB0 aGlzIGF0dHJpYnV0ZSwgZS5nLiB0aGUgcHJlZmVycmVkIG1haWxpbmcgYWRkcmVzcyBvciBwcmlt YXJ5IGUtbWFpbCBhZGRyZXNzLiBUaGUgcHJpbWFyeSBhdHRyaWJ1dGUgdmFsdWUgJ3RydWUnIE1V U1QgYXBwZWFyIG5vIG1vcmUgdGhhbiBvbmNlLiIsCiAgICAgICAgICAgInJlYWRPbmx5IjpmYWxz ZSwKICAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgICJjYXNlRXhhY3QiOmZh bHNlCiAgICAgICAgIH0KICAgICB9LAogICAgIHsKICAgICAgICJuYW1lIjoiYWRkcmVzc2VzIiwK ICAgICAgICJ0eXBlIjoiY29tcGxleCIsCiAgICAgICAibXVsdGlWYWx1ZWQiOnRydWUsCiAgICAg ICAiZGVzY3JpcHRpb24iOiJBIHBoeXNpY2FsIG1haWxpbmcgYWRkcmVzcyBmb3IgdGhpcyBVc2Vy LCBhcyBkZXNjcmliZWQgaW4gKGFkZHJlc3MgRWxlbWVudCkuIENhbm9uaWNhbCBUeXBlIFZhbHVl cyBvZiB3b3JrLCBob21lLCBhbmQgb3RoZXIuIFRoZSB2YWx1ZSBhdHRyaWJ1dGUgaXMgYSBjb21w bGV4IHR5cGUgd2l0aCB0aGUgZm9sbG93aW5nIHN1Yi1hdHRyaWJ1dGVzLiIsCiAgICAgICAic2No ZW1hIjoidXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCIsCiAgICAgICAicmVhZE9ubHkiOmZhbHNl LAogICAgICAgInJlcXVpcmVkIjpmYWxzZSwKCgoKTW9ydGltb3JlLCBldCBhbC4gICAgICAgICAg RXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgMjldCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0wMSAgICAgICAgICBOb3ZlbWJl ciAyMDEyCgoKICAgICAgICJjYXNlRXhhY3QiOmZhbHNlLAogICAgICAgInN1YkF0dHJpYnV0ZXMi OlsKICAgICAgICAgewogICAgICAgICAgICJuYW1lIjoiZm9ybWF0dGVkIiwKICAgICAgICAgICAi dHlwZSI6InN0cmluZyIsCiAgICAgICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAg ICAiZGVzY3JpcHRpb24iOiJUaGUgZnVsbCBtYWlsaW5nIGFkZHJlc3MsIGZvcm1hdHRlZCBmb3Ig ZGlzcGxheSBvciB1c2Ugd2l0aCBhIG1haWxpbmcgbGFiZWwuIFRoaXMgYXR0cmlidXRlIE1BWSBj b250YWluIG5ld2xpbmVzLiIsCiAgICAgICAgICAgInJlYWRPbmx5IjpmYWxzZSwKICAgICAgICAg ICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgICJjYXNlRXhhY3QiOmZhbHNlCiAgICAgICAg IH0sCiAgICAgICAgIHsKICAgICAgICAgICAibmFtZSI6InN0cmVldEFkZHJlc3MiLAogICAgICAg ICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAg ICAgICAgICJkZXNjcmlwdGlvbiI6IlRoZSBmdWxsIHN0cmVldCBhZGRyZXNzIGNvbXBvbmVudCwg d2hpY2ggbWF5IGluY2x1ZGUgaG91c2UgbnVtYmVyLCBzdHJlZXQgbmFtZSwgUE8gQk9YLCBhbmQg bXVsdGktbGluZSBleHRlbmRlZCBzdHJlZXQgYWRkcmVzcyBpbmZvcm1hdGlvbi4gVGhpcyBhdHRy aWJ1dGUgTUFZIGNvbnRhaW4gbmV3bGluZXMuIiwKICAgICAgICAgICAicmVhZE9ubHkiOmZhbHNl LAogICAgICAgICAgICJyZXF1aXJlZCI6ZmFsc2UsCiAgICAgICAgICAgImNhc2VFeGFjdCI6ZmFs c2UKICAgICAgICAgfSwKICAgICAgICAgewogICAgICAgICAgICJuYW1lIjoibG9jYWxpdHkiLAog ICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNl LAogICAgICAgICAgICJkZXNjcmlwdGlvbiI6IlRoZSBjaXR5IG9yIGxvY2FsaXR5IGNvbXBvbmVu dC4iLAogICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAgInJlcXVpcmVkIjpm YWxzZSwKICAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZQogICAgICAgICB9LAogICAgICAgICB7 CiAgICAgICAgICAgIm5hbWUiOiJyZWdpb24iLAogICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwK ICAgICAgICAgICAibXVsdGlWYWx1ZWQiOmZhbHNlLAogICAgICAgICAgICJkZXNjcmlwdGlvbiI6 IlRoZSBzdGF0ZSBvciByZWdpb24gY29tcG9uZW50LiIsCiAgICAgICAgICAgInJlYWRPbmx5Ijpm YWxzZSwKICAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgICJjYXNlRXhhY3Qi OmZhbHNlCiAgICAgICAgIH0sCiAgICAgICAgIHsKICAgICAgICAgICAibmFtZSI6InBvc3RhbENv ZGUiLAogICAgICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICAgICAibXVsdGlWYWx1ZWQi OmZhbHNlLAogICAgICAgICAgICJkZXNjcmlwdGlvbiI6IlRoZSB6aXBjb2RlIG9yIHBvc3RhbCBj b2RlIGNvbXBvbmVudC4iLAogICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAgICAg InJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZQogICAgICAgICB9 LAogICAgICAgICB7CgoKCk1vcnRpbW9yZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgTWF5IDUs IDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDMwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg IGRyYWZ0LXNjaW0tY29yZS1zY2hlbWEtMDEgICAgICAgICAgTm92ZW1iZXIgMjAxMgoKCiAgICAg ICAgICAgIm5hbWUiOiJjb3VudHJ5IiwKICAgICAgICAgICAidHlwZSI6InN0cmluZyIsCiAgICAg ICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAgICAgICAiZGVzY3JpcHRpb24iOiJUaGUg Y291bnRyeSBuYW1lIGNvbXBvbmVudC4iLAogICAgICAgICAgICJyZWFkT25seSI6ZmFsc2UsCiAg ICAgICAgICAgInJlcXVpcmVkIjpmYWxzZSwKICAgICAgICAgICAiY2FzZUV4YWN0IjpmYWxzZQog ICAgICAgICB9LAogICAgICAgICB7CiAgICAgICAgICAgIm5hbWUiOiJ0eXBlIiwKICAgICAgICAg ICAidHlwZSI6InN0cmluZyIsCiAgICAgICAgICAgIm11bHRpVmFsdWVkIjpmYWxzZSwKICAgICAg ICAgICAiZGVzY3JpcHRpb24iOiJBIGxhYmVsIGluZGljYXRpbmcgdGhlIGF0dHJpYnV0ZSdzIGZ1 bmN0aW9uOyBlLmcuLCAnd29yaycgb3IgJ2hvbWUnLiIsCiAgICAgICAgICAgInJlYWRPbmx5Ijpm YWxzZSwKICAgICAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgICAgICJjYXNlRXhhY3Qi OmZhbHNlLAogICAgICAgICAgICJjYW5vbmljYWxWYWx1ZXMiOlsid29yayIsImhvbWUiLCJvdGhl ciJdCiAgICAgICAgIH0sCiAgICAgICBdCiAgICAgfSwKICAgICB7CiAgICAgICAibmFtZSI6ImVt cGxveWVlTnVtYmVyIiwKICAgICAgICJ0eXBlIjoic3RyaW5nIiwKICAgICAgICJtdWx0aVZhbHVl ZCI6ZmFsc2UsCiAgICAgICAiZGVzY3JpcHRpb24iOiJOdW1lcmljIG9yIGFscGhhbnVtZXJpYyBp ZGVudGlmaWVyIGFzc2lnbmVkIHRvIGEgcGVyc29uLCB0eXBpY2FsbHkgYmFzZWQgb24gb3JkZXIg b2YgaGlyZSBvciBhc3NvY2lhdGlvbiB3aXRoIGFuIG9yZ2FuaXphdGlvbi4iLAogICAgICAgInNj aGVtYSI6InVybjpzY2ltOnNjaGVtYXM6ZXh0ZW5zaW9uOmVudGVycHJpc2U6MS4wIiwKICAgICAg ICJyZWFkT25seSI6ZmFsc2UsCiAgICAgICAicmVxdWlyZWQiOmZhbHNlLAogICAgICAgImNhc2VF eGFjdCI6ZmFsc2UKICAgICB9CiAgIF0KfQoKCgoxMi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z CgogICBUaGUgU0NJTSBDb3JlIHNjaGVtYSBjb250YWlucyBwZXJzb25hbGx5IGlkZW50aWZpYWJs ZSBpbmZvcm1hdGlvbiBhcwogICB3ZWxsIGFzIG90aGVyIHNlbnNpdGl2ZSBkYXRhLiAgQXNpZGUg ZnJvbSBwcm9oaWJpdGluZyBwYXNzd29yZCB2YWx1ZXMKICAgaW4gYSBTQ0lNIHJlc3BvbnNlIHRo aXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBwcm92aWRlIGFueSBtZWFucyBvcgogICBndWFyYW50 ZWUgb2YgY29uZmlkZW50aWFsaXR5LgoKCkFwcGVuZGl4IEEuICBDb250cmlidXRvcnMKCiAgIFRo ZSBTQ0lNIENvbW11bml0eSB3b3VsZCBsaWtlIHRvIHRoYW5rIHRoZSBmb2xsb3dpbmcgcGVvcGxl IGZvciB0aGUKICAgd29yayB0aGV5J3ZlIGRvbmUgaW4gdGhlIHJlc2VhcmNoLCBmb3JtdWxhdGlv biwgZHJhZnRpbmcsIGVkaXRpbmcsCiAgIGFuZCBzdXBwb3J0IG9mIHRoaXMgc3BlY2lmaWNhdGlv bi4KCgoKTW9ydGltb3JlLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAg ICAgICAgICAgICAgW1BhZ2UgMzFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgZHJhZnQtc2Np bS1jb3JlLXNjaGVtYS0wMSAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAgICAgTW9ydGV6YSBB bnNhcmkgKG1vcnRlemEuYW5zYXJpQGNpc2NvLmNvbSkKCiAgICAgIFNpZGhhcnRoIENob3VkaHVy eSAoc2Nob3VkaHVyeUBzYWxlc2ZvcmNlLmNvbSkKCiAgICAgIFNhbXVlbCBFcmR0bWFuIChzYW11 ZWxAZXJkdG1hbi5zZSkKCiAgICAgIEtlbGx5IEdyaXp6bGUgKGtlbGx5LmdyaXp6bGVAc2FpbHBv aW50LmNvbSkKCiAgICAgIENocmlzIFBoaWxsaXBzIChjanBoaWxsaXBzQGdtYWlsLmNvbSkKCiAg ICAgIEVyaWsgV2FobHN0cm9lbSAoZXJpay53YWhsc3Ryb21AbmV4dXNzYWZlLmNvbSkKCiAgIFNw ZWNpYWwgdGhhbmtzIHRvIEpvZXNlcGggU21hcnIsIHdobydzIGV4Y2VsbGVudCB3b3JrIG9uIHRo ZSBQb3J0YWJsZQogICBDb250YWN0cyBTcGVjaWZpY2F0aW9uIFtQb3J0YWJsZUNvbnRhY3RzXSBw cm92aWRlZCBhIGJhc2lzIGZvciB0aGUKICAgU0NJTSBzY2hlbWEgc3RydWN0dXJlIGFuZCB0ZXh0 LgoKCjEzLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtQb3J0YWJsZUNvbnRhY3RzXQogICAg ICAgICAgICAgIFNtYXJyLCBKLiwgIlBvcnRhYmxlIENvbnRhY3RzIDEuMCBEcmFmdCBDIC0gU2No ZW1hIE9ubHkiLAogICAgICAgICAgICAgIEF1Z3VzdCAyMDA4LgoKICAgW1JGQzIxMTldICBCcmFk bmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAg ICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoK ICAgWzFdICA8aHR0cDovL2pzb24ub3JnPgoKICAgWzJdICA8aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNDYyNz4KCiAgIFszXSAgPGh0dHA6Ly93d3cudzMub3JnL1RSL3htbHNjaGVtYS0y Lz4KCiAgIFs0XSAgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ1MTI+CgogICBbNV0g IDxodHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOS0yL3BocC9jb2RlX2xpc3QucGhw PgoKICAgWzZdICA8aHR0cDovL3d3dy5pc28ub3JnL2lzby9jb3VudHJ5X2NvZGVzL2lzb18zMTY2 X2NvZGVfbGlzdHMvCiAgICAgICAgY291bnRyeV9uYW1lc19hbmRfY29kZV9lbGVtZW50cy5odG0+ CgogICBbN10gIDxodHRwOi8vd3d3LnR3aW5zdW4uY29tL3R6L3R6LWxpbmsuaHRtPgoKICAgWzhd ICA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzk2Nj4KCgoKCgoKCgoKTW9ydGltb3Jl LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBNYXkgNSwgMjAxMyAgICAgICAgICAgICAgICAgW1Bh Z2UgMzJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0w MSAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBDaHVjayBN b3J0aW1vcmUgKGVkaXRvcikKICAgU2FsZXNmb3JjZS5jb20KCiAgIEVtYWlsOiBjbW9ydGltb3Jl QHNhbGVzZm9yY2UuY29tCgoKICAgUGF0cmljayBIYXJkaW5nCiAgIFBpbmcgSWRlbnRpdHkKCiAg IEVtYWlsOiBwaGFyZGluZ0BwaW5naWRlbnRpdHkuY29tCgoKICAgUGF1bCBNYWRzZW4KICAgUGlu ZyBJZGVudGl0eQoKICAgRW1haWw6IHBtYWRzZW5AcGluZ2lkZW50aXR5LmNvbQoKCiAgIFRyZXkg RHJha2UKICAgVW5ib3VuZElECgogICBFbWFpbDogdHJleS5kcmFrZUB1bmJvdW5kaWQuY29tCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCk1vcnRpbW9yZSwgZXQgYWwuICAgICAgICAgIEV4cGly ZXMgTWF5IDUsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDMzXQoMCg== --_003_56C3C758F9D6534CA3778EAA1E0C34373E7F2E20BY2PRD0410MB354_-- From phil.hunt@oracle.com Fri Nov 2 13:22:11 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E271F0C8B for ; Fri, 2 Nov 2012 13:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.259 X-Spam-Level: X-Spam-Status: No, score=-7.259 tagged_above=-999 required=5 tests=[AWL=3.340, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKVDInoOtDjS for ; Fri, 2 Nov 2012 13:22:10 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 118961F0C84 for ; Fri, 2 Nov 2012 13:22:10 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA2KM870014202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Nov 2012 20:22:09 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA2KM7jR018351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2012 20:22:08 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qA2KM6gI008787; Fri, 2 Nov 2012 15:22:06 -0500 Received: from [192.168.1.131] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Nov 2012 13:20:42 -0700 MIME-Version: 1.0 Message-ID: <7A23DE4D-9051-40B3-84F6-0A1BD72007FB@oracle.com> Date: Fri, 2 Nov 2012 13:20:50 -0700 (PDT) From: Phil Hunt To: Kelly Grizzle References: <068.6f8ea83285aaea9cd481e0e5a8490f9c@tools.ietf.org> <083.1dd51238238687e2c8a67e0faf29da50@tools.ietf.org> <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "scim@ietf.org" Subject: Re: [scim] #27: Make support for XML optional or drop it; JSON required X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 20:22:11 -0000 +1 I haven't read the changes yet, but in principal I think this is an = important simplification. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-11-02, at 9:55 AM, Kelly Grizzle wrote: > Please review the proposed changes to remove XML support from SCIM. = Any feedback is greatly appreciated. I have attached the full txt = documents, which may be easier to read than the diffs (attached to = ticket #27). >=20 > --Kelly >=20 > -----Original Message----- > From: scim issue tracker [mailto:trac+scim@tools.ietf.org]=20 > Sent: Friday, November 02, 2012 11:46 AM > To: Kelly Grizzle; bjorn.aannestad@unboundid.com > Cc: scim@ietf.org > Subject: Re: [scim] #27: Make support for XML optional or drop it; = JSON required >=20 > #27: Make support for XML optional or drop it; JSON required >=20 >=20 > Comment (by kelly.grizzle@=85): >=20 > Attached a diff from revision 206 of > https://scim.googlecode.com/svn/trunk/specs/ietf with proposed = changes. > At a high level, the following changes were made: >=20 > 1) Removed mentions of XML format from both schema and API documents. > 2) Changed section 3 (SCIM Schema Structure) of schema document to be = based off of JSON. Attribute types are now all derived from JSON. = Binary and DateTime have no JSON representation, so these both use XML = formatting. > 3) Removed xmlDataFormat from the ServiceProviderConfig resource. > 4) Removed multiValuedAttributeChildName from the Schema resource. > 5) Removed all XML representation examples from the schema document. > 6) Removed application/xml content type from the Data Input/Output = Format section of the API document. > 7) Removed XML examples from the Data Input/Output Format section of = the API document. >=20 > --=20 > -------------------------------+------------------------------ > Reporter: bjorn.aannestad@=85 | Owner: kelly.grizzle@=85 > Type: enhancement | Status: assigned > Priority: major | Milestone: > Component: api | Version: > Severity: - | Resolution: > Keywords: | > -------------------------------+------------------------------ >=20 > Ticket URL: = > scim >=20 >=20 > = __________= _____________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From melinda.shore@gmail.com Fri Nov 2 15:10:55 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD4811E80E1 for ; Fri, 2 Nov 2012 15:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpNI-vxhrBVN for ; Fri, 2 Nov 2012 15:10:54 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7F7F11E80DF for ; Fri, 2 Nov 2012 15:10:54 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1816013dan.31 for ; Fri, 02 Nov 2012 15:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xLstVne1PWGdtUfrkDZRzQrWySu1kAxhllbf7epWXjY=; b=V/aS6VYCzQQP3mYvddWWfMP+JrbWZvyW355QcbP6fnA5R76JY+6CNKqUwqoqB5XmxY 5f1neSPRNUmoDdIiSQNoS0qTQcoUmroKCo1WkBg+1gj9+lXWuvTooVOiMZPKc1GQMua4 W7ht5xGa3/aC3hLunIm3s2d7GyINmj12wRAlXj3NcAddJqjmRIrQHfIcvCEe4u4xau+L TJ211Ez5XUs7JR8uXgM+fAZsVwGtCOEqTIFpzqreuzCCiiz3eNxU0XDCMGHrw1UdH59B k6KUcbfmWot9XvOhUInzTLq2sC97BJw7ag3kwu1c1CbG8APLDTxZEeH+RjBUZey1xSa9 Vx3w== Received: by 10.66.74.65 with SMTP id r1mr8797030pav.75.1351894254179; Fri, 02 Nov 2012 15:10:54 -0700 (PDT) Received: from ?IPv6:2001:df8:0:64:2cf4:29c6:be9f:b7c7? ([2001:df8:0:64:2cf4:29c6:be9f:b7c7]) by mx.google.com with ESMTPS id uh10sm1606655pbc.35.2012.11.02.15.10.51 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 15:10:52 -0700 (PDT) Message-ID: <509444EB.8040900@gmail.com> Date: Fri, 02 Nov 2012 14:10:51 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org References: <068.6f8ea83285aaea9cd481e0e5a8490f9c@tools.ietf.org> <083.1dd51238238687e2c8a67e0faf29da50@tools.ietf.org> <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> <7A23DE4D-9051-40B3-84F6-0A1BD72007FB@oracle.com> In-Reply-To: <7A23DE4D-9051-40B3-84F6-0A1BD72007FB@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [scim] #27: Make support for XML optional or drop it; JSON required X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 22:10:55 -0000 On 11/2/2012 12:20 PM, Phil Hunt wrote: > I haven't read the changes yet, but in principal I think this is an important simplification. I do, too. It seems to me that if there is interest in an optional alternate encoding at a later time it could in theory be specified in a separate document, however a negotiation mechanism would be needed and those are probably best avoided. But it also seems to me that if there's an actual need it will almost certainly be raised before working group last call. Melinda From phil.hunt@oracle.com Fri Nov 2 15:52:00 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CF011E80FC for ; Fri, 2 Nov 2012 15:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.816 X-Spam-Level: X-Spam-Status: No, score=-3.816 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1H3Q7Lg7bO1 for ; Fri, 2 Nov 2012 15:51:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 45F5A11E80F9 for ; Fri, 2 Nov 2012 15:51:59 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA2MpurB017839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Nov 2012 22:51:57 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA2MpuGg013126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2012 22:51:56 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qA2MpuZp029917; Fri, 2 Nov 2012 17:51:56 -0500 Received: from [192.168.1.131] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Nov 2012 15:51:56 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <509444EB.8040900@gmail.com> Date: Fri, 2 Nov 2012 15:52:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8258F0DB-3037-4BE0-8944-86F3DF4A7096@oracle.com> References: <068.6f8ea83285aaea9cd481e0e5a8490f9c@tools.ietf.org> <083.1dd51238238687e2c8a67e0faf29da50@tools.ietf.org> <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> <7A23DE4D-9051-40B3-84F6-0A1BD72007FB@oracle.com> <509444EB.8040900@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: scim@ietf.org Subject: Re: [scim] #27: Make support for XML optional or drop it; JSON required X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 22:52:00 -0000 Do we need to leave a "hook" such as saying use of accept headers to = specify alternate types is acceptable as an extension. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-11-02, at 3:10 PM, Melinda Shore wrote: > On 11/2/2012 12:20 PM, Phil Hunt wrote: >> I haven't read the changes yet, but in principal I think this is an = important simplification. >=20 > I do, too. It seems to me that if there is interest in an > optional alternate encoding at a later time it could in theory > be specified in a separate document, however a negotiation > mechanism would be needed and those are probably best avoided. > But it also seems to me that if there's an actual need it > will almost certainly be raised before working group last > call. >=20 > Melinda >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From leifj@mnt.se Sat Nov 3 10:03:28 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979C521F85FD for ; Sat, 3 Nov 2012 10:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMGpWs36HKEO for ; Sat, 3 Nov 2012 10:03:27 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1B2421F85D6 for ; Sat, 3 Nov 2012 10:03:27 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so2071086dan.31 for ; Sat, 03 Nov 2012 10:03:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=b8nI5LjXyrFk4BBRK2ZXGsasHmHfuxyOdnOXvSPd/vY=; b=pMhkPXrZwcn4wmuozhFF4kSASO9leT844rgKpl0s1GcyAII0qnPiIV0Z2zQTphQrcI waG31SVlgBDE7H9bLm6ami+ltKCUSQyCP79AbNepXIv+QInClzN9ahc+0iVkPUMl7HOg uWXEF2tlVTs/DfpYPpAuH/5vw/Sgaqyj4PWHantVnVamPj90PXVbtHvav9yxAnsgmQEs zA/EC70pUrDghu9Y99JI4hfSePcnObp1nooFFdQn48Ltac/UoW10+EHmAMdlCZcIUt9I Ti4yEa+SMrirzLsyQD6ZQdSxdCmMsr1mxAL7PQGcsfH4KvDP+Hd/vlQRjcic/94Rk/cq wxow== Received: by 10.68.225.5 with SMTP id rg5mr16447399pbc.73.1351962207496; Sat, 03 Nov 2012 10:03:27 -0700 (PDT) Received: from ?IPv6:2001:df8:0:64:7f:7b6e:bb97:9281? ([2001:df8:0:64:7f:7b6e:bb97:9281]) by mx.google.com with ESMTPS id jx4sm7625174pbc.27.2012.11.03.10.03.25 (version=SSLv3 cipher=OTHER); Sat, 03 Nov 2012 10:03:26 -0700 (PDT) Message-ID: <50954E5B.9030901@mnt.se> Date: Sat, 03 Nov 2012 18:03:23 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: scim@ietf.org References: <068.6f8ea83285aaea9cd481e0e5a8490f9c@tools.ietf.org> <083.1dd51238238687e2c8a67e0faf29da50@tools.ietf.org> <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> <7A23DE4D-9051-40B3-84F6-0A1BD72007FB@oracle.com> <509444EB.8040900@gmail.com> <8258F0DB-3037-4BE0-8944-86F3DF4A7096@oracle.com> In-Reply-To: <8258F0DB-3037-4BE0-8944-86F3DF4A7096@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnphq76wdT3yOFWzPU7ZiyfWmaGmttP/h7hSGrp99h1J4CrUkME9GJSawucQxlXXbmZDOD9 Subject: Re: [scim] #27: Make support for XML optional or drop it; JSON required X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 17:03:29 -0000 On 11/02/2012 11:52 PM, Phil Hunt wrote: > Do we need to leave a "hook" such as saying use of accept headers to specify alternate types is acceptable as an extension. As an individual I'd advocate staying away from negotiating features unless there is real need for them - remember we can always rev the version of the protocol at some later date when/if such extensibility becomes necessary. The impact on implementers will be roughly the same. From lear@cisco.com Sat Nov 3 12:17:36 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4FE21F9CB9 for ; Sat, 3 Nov 2012 12:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.586 X-Spam-Level: X-Spam-Status: No, score=-110.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+tbQxY80BBp for ; Sat, 3 Nov 2012 12:17:34 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id C2CA521F9CAF for ; Sat, 3 Nov 2012 12:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=566; q=dns/txt; s=iport; t=1351970253; x=1353179853; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sfwAbtZJDp3rVhU5PFsQuQSAu6orsUhu1NeGOh00WZY=; b=DJzFkZcbEIb9AvDHO5FXf8QzSIMcbnn3evqMbGav6LDes4Ny0C1Egorh dR/8ps/1jnqQm18+2ghTWoymOdMhqYG1w48aSyuz5NpChKMf1so/Ys0Hr RB0niECRsKb4aZ0gZKW9wv95+JSrDrozgbKlhMk4MrU2CqibTe7Uel0uD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYJAMRslVCQ/khN/2dsb2JhbABEhhe5UYI9BASBCIEIgh4BAQEEEgEQVQEQCxgCAgUWCwICCQMCAQIBRQYNAQcBAR6HaJlljSiSGIEgimGFKYETA5V7jlmBa4Jw X-IronPort-AV: E=Sophos;i="4.80,705,1344211200"; d="scan'208";a="9326105" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 03 Nov 2012 19:17:31 +0000 Received: from dhcp-10-55-88-93.cisco.com (dhcp-10-55-88-93.cisco.com [10.55.88.93]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA3JHUhJ027003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Nov 2012 19:17:30 GMT Message-ID: <50956DCA.4090701@cisco.com> Date: Sat, 03 Nov 2012 20:17:30 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Leif Johansson References: <068.6f8ea83285aaea9cd481e0e5a8490f9c@tools.ietf.org> <083.1dd51238238687e2c8a67e0faf29da50@tools.ietf.org> <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> <7A23DE4D-9051-40B3-84F6-0A1BD72007FB@oracle.com> <509444EB.8040900@gmail.com> <8258F0DB-3037-4BE0-8944-86F3DF4A7096@oracle.com> <50954E5B.9030901@mnt.se> In-Reply-To: <50954E5B.9030901@mnt.se> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] #27: Make support for XML optional or drop it; JSON required X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 19:17:36 -0000 On 11/3/12 6:03 PM, Leif Johansson wrote: > On 11/02/2012 11:52 PM, Phil Hunt wrote: >> Do we need to leave a "hook" such as saying use of accept headers to specify alternate types is acceptable as an extension. > As an individual I'd advocate staying away from negotiating features > unless there is real need for them - remember we can always rev > the version of the protocol at some later date when/if such extensibility > becomes necessary. The impact on implementers will be roughly the same. > +1. Options are bad for interoperability. Eliot From hasini@wso2.com Sun Nov 4 04:38:06 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFED21F869C for ; Sun, 4 Nov 2012 04:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS+HTEB06i-U for ; Sun, 4 Nov 2012 04:38:05 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E5E1221F869F for ; Sun, 4 Nov 2012 04:38:04 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5660014vbb.31 for ; Sun, 04 Nov 2012 04:38:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=V9Kl3ZtPiSJALSgASiIwSn0V4gqQC5xw46opqG1au1g=; b=CPxAQZGWmppuTtYPalywiFEtA8HAPWWxUPLJVFk7ZO/ySzEEeAn3+Xw0e7ha3u+vpC jW83VmkoeE1GZ6XB8YoNkker5Cx/o6WLlizfgsWuNU7iBzb5ai2RdVs+CxWZVtzRgKZX tWcmYpiMlY6Iuxf9KkEcKWAO91+6K+0YYk96wARKO1PbH+EKWiFY7EKGOjiTOgJI1pUw pxTXjjYpAObfNvkc87APAwo69VbJDbuEcO7fStPC/KhfAKpQWlYXovUEH2M02ATFq0H4 9BYbT48EwP2xwR4ofZoiYJIGTBGyBAxy7XcYEoh3VgL0jrHs1EQ6w8qiScTfxHcMLmky AR4A== MIME-Version: 1.0 Received: by 10.58.201.73 with SMTP id jy9mr7003908vec.29.1352032683795; Sun, 04 Nov 2012 04:38:03 -0800 (PST) Received: by 10.220.183.8 with HTTP; Sun, 4 Nov 2012 04:38:03 -0800 (PST) In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <068.6f8ea83285aaea9cd481e0e5a8490f9c@tools.ietf.org> <083.1dd51238238687e2c8a67e0faf29da50@tools.ietf.org> <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> Date: Sun, 4 Nov 2012 18:08:03 +0530 Message-ID: From: Hasini Gunasinghe To: Kelly Grizzle Content-Type: multipart/alternative; boundary=047d7b677afad7a61004cdaaa324 X-Gm-Message-State: ALoCoQmbl7SqtIxnZKJ2yHjsfZK5RFsh330Ax0n68r04oHue8TLUrd7oV5sLTDmBIkcUZjAm+Hp/ Cc: "scim@ietf.org" Subject: Re: [scim] #27: Make support for XML optional or drop it; JSON required X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 12:38:06 -0000 --047d7b677afad7a61004cdaaa324 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Nov 2, 2012 at 10:25 PM, Kelly Grizzle wrote: > Please review the proposed changes to remove XML support from SCIM. Any > feedback is greatly appreciated. I have attached the full txt documents, > which may be easier to read than the diffs (attached to ticket #27). > > --Kelly > > -----Original Message----- > From: scim issue tracker [mailto:trac+scim@tools.ietf.org] > Sent: Friday, November 02, 2012 11:46 AM > To: Kelly Grizzle; bjorn.aannestad@unboundid.com > Cc: scim@ietf.org > Subject: Re: [scim] #27: Make support for XML optional or drop it; JSON > required > > #27: Make support for XML optional or drop it; JSON required > +1. JSON is adequate. Thanks, Hasini. > > > Comment (by kelly.grizzle@=85): > > Attached a diff from revision 206 of > https://scim.googlecode.com/svn/trunk/specs/ietf with proposed changes. > At a high level, the following changes were made: > > 1) Removed mentions of XML format from both schema and API documents. > 2) Changed section 3 (SCIM Schema Structure) of schema document to be > based off of JSON. Attribute types are now all derived from JSON. Bina= ry > and DateTime have no JSON representation, so these both use XML > formatting. > 3) Removed xmlDataFormat from the ServiceProviderConfig resource. > 4) Removed multiValuedAttributeChildName from the Schema resource. > 5) Removed all XML representation examples from the schema document. > 6) Removed application/xml content type from the Data Input/Output Forma= t > section of the API document. > 7) Removed XML examples from the Data Input/Output Format section of the > API document. > > -- > -------------------------------+------------------------------ > Reporter: bjorn.aannestad@=85 | Owner: kelly.grizzle@=85 > Type: enhancement | Status: assigned > Priority: major | Milestone: > Component: api | Version: > Severity: - | Resolution: > Keywords: | > -------------------------------+------------------------------ > > Ticket URL: > scim > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --047d7b677afad7a61004cdaaa324 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Fri, Nov 2, 2012 at 10:25 PM, Kelly G= rizzle <kelly.grizzle@sailpoint.com> wrote:
Please review the proposed changes to remove XML support from SCIM. =A0Any = feedback is greatly appreciated. =A0I have attached the full txt documents,= which may be easier to read than the diffs (attached to ticket #27).

--Kelly

-----Original Message-----
From: scim issue tracker [mailto:trac+scim@tools.ietf.org]
Sent: Friday, November 02, 2012 11:46 AM
To: Kelly Grizzle; bjorn.a= annestad@unboundid.com
Cc: scim@ietf.org
Subject: Re: [scim] #27: Make support for XML optional or drop it; JSON req= uired

#27: Make support for XML optional or drop it; JSON required

+1. JSON is adequate.

Thanks= ,
Hasini.
=A0


Comment (by kelly.grizzle@=85):

=A0Attached a diff from revision 206 of
=A0https://scim.googlecode.com/svn/trunk/specs/ietf with proposed c= hanges.
=A0At a high level, the following changes were made:

=A01) Removed mentions of XML format from both schema and API documents. =A02) Changed section 3 (SCIM Schema Structure) of schema document to be = =A0based off of JSON. =A0Attribute types are now all derived from JSON. =A0= Binary =A0and DateTime have no JSON representation, so these both use XML = =A0formatting.
=A03) Removed xmlDataFormat from the ServiceProviderConfig resource.
=A04) Removed multiValuedAttributeChildName from the Schema resource.
=A05) Removed all XML representation examples from the schema document.
=A06) Removed application/xml content type from the Data Input/Output Forma= t =A0section of the API document.
=A07) Removed XML examples from the Data Input/Output Format section of the= =A0API document.

--
-------------------------------+------------------------------
=A0Reporter: =A0bjorn.aannestad@=85 =A0| =A0 =A0 =A0 Owner: =A0kelly.grizzl= e@=85
=A0 =A0 =A0Type: =A0enhancement =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0assi= gned
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone:
Component: =A0api =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0Resolution:
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac/tick= et/27#comment:4>
scim <http://t= ools.ietf.org/scim/>



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


--047d7b677afad7a61004cdaaa324-- From hannes.tschofenig@gmx.net Sun Nov 4 06:36:52 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB7D21F8615 for ; Sun, 4 Nov 2012 06:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQ6Q570UTIM2 for ; Sun, 4 Nov 2012 06:36:52 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B0DE621F84E0 for ; Sun, 4 Nov 2012 06:36:51 -0800 (PST) Received: (qmail invoked by alias); 04 Nov 2012 14:36:49 -0000 Received: from dhcp-17ac.meeting.ietf.org (EHLO dhcp-17ac.meeting.ietf.org) [130.129.23.172] by mail.gmx.net (mp036) with SMTP; 04 Nov 2012 15:36:49 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+S3WpRFKCS7ccQz+nbEBR/VVbgb7zPKhV3+RBqcM vU5/EMbiusE2ge From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Nov 2012 09:36:47 -0500 Message-Id: To: scim@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig Subject: [scim] Complexity X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 14:36:52 -0000 Hi all,=20 in light of the discussions about deciding for XML vs. JSON to reduce = the complexity of the protocol I thought I should raise a few remarks = about complexity in the rest of the protocol suite.=20 draft-ietf-scim-api defines two protocols that roughly accomplish the = same functionality but are encoded differently.=20 The main part of the document focuses on changing and modifying a single = entry in the database. It is based on a REST-ful design (since that's = very popular). Then, of course people realize that that leads to slow = interactions when multiple exchanges are being made. For this reason, an = entirely different protocol is defined for bulk transfer. Of course this = bulk transfer has to replicate all the functionality of the rest of the = exchange and will also have to do this with any future extension. Is = there room to harmonize this a bit more. For example, a bulk transfer = with a single entry provides the functionality of the other approach.=20 Section 3 of draft-ietf-scim-api defines what HTTP messages are being = used, such as GET, POST, PUT, PATCH, DELETE. It is nice to re-use the = HTTP functionality but as some folks had found out that there are = misbehaving intermediaries. Section 3.12 then introduces an alternative = approach. It might be nice to have some data about the problem caused by = intermediaries. Does it make sense to decide for one approach rather = than using two? The base specification has a lot of optional functionality. For this = reason there is a feature discovery mechanism introduced. I wonder why = the core specification does not only contain the mandatory-to-implement = functionality. It also feels strange that the functionality for the = configuration parameters are actually defined in a separate document, = namely in draft-ietf-scim-core-schema rather than in = draft-ietf-scim-api where the actual features are described. Section 4 of draft-ietf-scim-api talks about TLS being mandatory to = implement. I believe that the specification should go further and say = that it is mandatory to use for the type of data that is being shuffled = around that is highly sensible. The document refers to OAuth about = client authentication but I am not sure how you came to that conclusion. = OAuth is a good protocol for delegated authorization but here there is = no delegation happening.=20 More related to the complexity of the specification: I also wonder why = you have to introduce a "schema" for JSON, as you did it in Section 11.6 = of draft-ietf-scim-core-schema. If you remove the XML support is there = actually a need for Section 3 anymore? JSON supports certain data types. = If this schema concept is of more generic usage, which may well be, then = maybe that should be in a separate document for others to use as well.=20= The schema / namespace concept is interesting since it is different to = how XML does it. So, I am wondering how you ensure that two schema = specifications do not define the same attribute names.=20 Ciao Hannes =20 From lear@cisco.com Sun Nov 4 22:35:33 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CDF21F8B05 for ; Sun, 4 Nov 2012 22:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.588 X-Spam-Level: X-Spam-Status: No, score=-110.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMW2r7BPHedm for ; Sun, 4 Nov 2012 22:35:28 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id D618221F8B18 for ; Sun, 4 Nov 2012 22:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=802; q=dns/txt; s=iport; t=1352097327; x=1353306927; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=z511PSoaREigxqprKSMLiuOJg7hpKuSc/oQm0LcN0sM=; b=BCRwz5x7xrAmiXIYZhDrWv4DUASfDDGAm5p3vfCoVAqjTRk3JcMqEJTN DqwVI6uc3bIdcdAnOijj+HxwI2krLUsbqQOM1fSJqUDJlZ/LpzUGe3dOp UZy0vjg3ndofOK4+y6H3hg3DuweUXDcdcbdo3Fw32Ug85uUobOPV/kNVb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAldl1CQ/khL/2dsb2JhbABEhhe9JIEIgh4BAQEDARIBEFUBBQsLGgIFFgsCAgkDAgECAUUGDQEHAQEeh2IGmgGNKJF4gSCQCoETA5V7jlmBa4Jw X-IronPort-AV: E=Sophos;i="4.80,713,1344211200"; d="scan'208";a="9343103" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 05 Nov 2012 06:35:26 +0000 Received: from dhcp-10-55-88-197.cisco.com (dhcp-10-55-88-197.cisco.com [10.55.88.197]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA56ZQ1k013120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2012 06:35:26 GMT Message-ID: <50975E31.7060604@cisco.com> Date: Mon, 05 Nov 2012 07:35:29 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Hannes Tschofenig References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] Complexity X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 06:35:35 -0000 On 11/4/12 3:36 PM, Hannes Tschofenig wrote: > Section 3 of draft-ietf-scim-api defines what HTTP messages are being used, such as GET, POST, PUT, PATCH, DELETE. It is nice to re-use the HTTP functionality but as some folks had found out that there are misbehaving intermediaries. Section 3.12 then introduces an alternative approach. It might be nice to have some data about the problem caused by intermediaries. Does it make sense to decide for one approach rather than using two? Yes, but intermediaries shouldn't be our concern in this case. The protocol requires TLS by its nature, and so the usual plain text problems should be dispensed with. In the case where we're talking about a reverse TLS proxy, that something that can be dealt with by a party to the transaction. Eliot From kelly.grizzle@sailpoint.com Mon Nov 5 06:17:44 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD5821F8718 for ; Mon, 5 Nov 2012 06:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.841 X-Spam-Level: X-Spam-Status: No, score=-2.841 tagged_above=-999 required=5 tests=[AWL=0.758, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEWyPGkFY2Ww for ; Mon, 5 Nov 2012 06:17:43 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 99BAC21F871F for ; Mon, 5 Nov 2012 06:17:43 -0800 (PST) Received: from mail16-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 14:17:42 +0000 Received: from mail16-ch1 (localhost [127.0.0.1]) by mail16-ch1-R.bigfish.com (Postfix) with ESMTP id 4936B2C01DA; Mon, 5 Nov 2012 14:17:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT005.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: PS-30(zzbb2dI98dI9371Id6eah168aJ542Mzz1de0h1202h1d1ah1d2ahzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received-SPF: pass (mail16-ch1: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT005.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail16-ch1 (localhost.localdomain [127.0.0.1]) by mail16-ch1 (MessageSwitch) id 1352125060234257_21081; Mon, 5 Nov 2012 14:17:40 +0000 (UTC) Received: from CH1EHSMHS041.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail16-ch1.bigfish.com (Postfix) with ESMTP id 34B9CC0073; Mon, 5 Nov 2012 14:17:40 +0000 (UTC) Received: from BY2PRD0410HT005.namprd04.prod.outlook.com (157.56.236.85) by CH1EHSMHS041.bigfish.com (10.43.69.250) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 5 Nov 2012 14:17:39 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.11.81]) by BY2PRD0410HT005.namprd04.prod.outlook.com ([10.255.83.40]) with mapi id 14.16.0233.002; Mon, 5 Nov 2012 14:17:38 +0000 From: Kelly Grizzle To: Eliot Lear , Leif Johansson Thread-Topic: [scim] #27: Make support for XML optional or drop it; JSON required Thread-Index: AQHNuUb0UDOLmDZDbUyAUSExP74v8JfXJswAgAEw6YCAACV5AIACzp9A Date: Mon, 5 Nov 2012 14:17:37 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34373E7F4042@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <068.6f8ea83285aaea9cd481e0e5a8490f9c@tools.ietf.org> <083.1dd51238238687e2c8a67e0faf29da50@tools.ietf.org> <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> <7A23DE4D-9051-40B3-84F6-0A1BD72007FB@oracle.com> <509444EB.8040900@gmail.com> <8258F0DB-3037-4BE0-8944-86F3DF4A7096@oracle.com> <50954E5B.9030901@mnt.se> <50956DCA.4090701@cisco.com> In-Reply-To: <50956DCA.4090701@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 7B3B345000360C7B3B359D x-originating-ip: [173.226.147.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] #27: Make support for XML optional or drop it; JSON required X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:17:44 -0000 Section 3.6 of the api doc - Data Input/Output Formats - specifies that the= Content-Type and Accept headers are used to declare what content type is i= ncluded in a request body and what content type is desired for the response= . The only allowed value is "application/json". This could eventually be = an extension point, but as Eliot and others have said I don't think we shou= ld open up this option for now. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Eli= ot Lear Sent: Saturday, November 03, 2012 2:18 PM To: Leif Johansson Cc: scim@ietf.org Subject: Re: [scim] #27: Make support for XML optional or drop it; JSON req= uired On 11/3/12 6:03 PM, Leif Johansson wrote: > On 11/02/2012 11:52 PM, Phil Hunt wrote: >> Do we need to leave a "hook" such as saying use of accept headers to spe= cify alternate types is acceptable as an extension. > As an individual I'd advocate staying away from negotiating features=20 > unless there is real need for them - remember we can always rev the=20 > version of the protocol at some later date when/if such extensibility=20 > becomes necessary. The impact on implementers will be roughly the same. > +1. Options are bad for interoperability. Eliot _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From bjorn.aannestad@unboundid.com Thu Nov 8 06:36:31 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A8E21F8B4C for ; Thu, 8 Nov 2012 06:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z0O28d2wYqw for ; Thu, 8 Nov 2012 06:36:30 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5585921F8B85 for ; Thu, 8 Nov 2012 06:36:30 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id l13so547074yen.31 for ; Thu, 08 Nov 2012 06:36:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=uspIziBpZsWBvW2NViBfAuBBUpQ06vDIbhMSsf9loL0=; b=BpUSUn5ZPihHnTONVqcbHF1hSGNhr/m1WX6v8wbxhj3Df6rerqW23IyVHoBr/A9GTn crXc9joxDgSonzoQkkn/6SSRU0Gav0tnkbBbbTL1jlRzHMWEEhjliRr0nOFqt0/pWLZL 5/bkmqOQImXCoYBwvJJl8glnvOLltk+GYl/G2YUd0QvDaohzt7CDenEYjUjAWK8dkR8n 1rz1FKwnutVe0ZKN3XifOsr0j2bYxsozLRdFMXRefy7Ws08VLsE16DcxHtNo+l5BNbTh hW6M3vIWQPMuB/foveCKaV7NQcKbdA0Emf9T+YYGOMHCxDtn+WZ7h9PohzPlOi8Z7Emo aNzw== Received: by 10.236.173.9 with SMTP id u9mr8644818yhl.129.1352385386855; Thu, 08 Nov 2012 06:36:26 -0800 (PST) Received: from [70.43.3.250] (173-15-223-105-BusName-Atlanta.hfc.comcastbusiness.net. [173.15.223.105]) by mx.google.com with ESMTPS id h22sm26967884yhk.13.2012.11.08.06.36.25 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 06:36:25 -0800 (PST) Message-ID: <509BC364.3080209@unboundid.com> Date: Thu, 08 Nov 2012 08:36:20 -0600 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: scim WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000202050703040906030809" X-Gm-Message-State: ALoCoQn/VnVVWdxJitWrA9IYKrGz7k8nSD9CfG8496qt4IAyqAzF/0h5UpaNUGS0ldsl3ufGSTQu Subject: [scim] SCIM and Cloud-based Directory Services X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:36:31 -0000 This is a cryptographically signed message in MIME format. --------------ms000202050703040906030809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I'll be giving a short talk next week introducing "SCIM and Cloud-based=20 Directory Services". (The Ping event in Ft.Worth/Dallas). To=20 encourage further adoption of SCIM, I'd like to cite the momentum it=20 already has. If you have or know of a SCIM implementation effort that extends SCIM=20 beyond provisioning, please let me know. All I need is the company=20 name/project name, though I'd be very interested in further=20 conversations here at IETF or later. UnboundID has one, and I am aware of Phil Hunt's draft directory spec. Thanks! -Bjorn Aannestad --=20 __________________________________________________________ Bjorn Aannestad | Dir, Product Management | UnboundID Corp mailto:bjorn@unboundid.com | 512-769-6461 --------------ms000202050703040906030809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMUjCC BVwwggREoAMCAQICECStp7X80wzNJ6GfICadV/cwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjAyMjMwMDAwMDBaFw0xMzAyMjIyMzU5NTlaMIIBHzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRgwFgYDVQQDFA9Cam9ybiBBYW5u ZXN0YWQxLDAqBgkqhkiG9w0BCQEWHWJqb3JuLmFhbm5lc3RhZEB1bmJvdW5kaWQuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw+4r+Le4uODrErBgJsA7UoexcjH/r2Ds 62wKyDCY5CQfOFMROnynV9GWWXp8zmCj7/N9I2hOU7poaqR4kkJjoiKiNHQdVfyM1yFZTurW AV5PCT5NouiqlruJDM6s2HV3B7mSRhtHFOSfhiDP+/kHf/JEdFJ7zEPaP0Kuy8XKpPR5nVCz k4zFKPBc4T9+HAlXeGY1PnwOsxPEevZlHOTThF9RunZu5Z/uaObR2JplM6KxXDfXNRjSkmK7 6kW8wFC1C0GleHKfM85nQTvVicuSK4GbbvhMjqovMtUIR1SNG8vsmTvU4PY9G/WkDM4Ge/97 phIcQIm9W/DXjC78wBfa/QIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5Bgtg hkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh MAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkw RzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5k QzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQC345zS3026vrJVysBCE3TN BhQ4VlqRtwj5AcAXhhF2c3krlbgJRLV6STYky+/i7YRdezIZYgY2eo693dlIQUnkZMb6D2PL dRs1Lgw4NJKB+WGLGkmyV8YqqKrTm/ZbPdl/+Y4Pc88DLcYEmr0OsEDel8LqLPpongUDnGU5 2wxAvaHn9sZ4nyDa3bAy9RyqrAdWhsfRttlgAbvMeHSXhvDa63AbdGdZbzBfqGpBTYZJqrA/ fzcbVZQIw7ULW0YRpUNx8bmmgxFd5ovdDVZnfiKNd7QHy+BcTQgfxLYsBYZhICz1ud1QKn88 pW944VjwHTzxyErX43AGoPYoZKA8b3XXMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT 3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5 OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6 ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f 0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Iba k2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+ wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBn MGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNV HR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNV HQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAH BgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24u Y29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0 LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHm oYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSo WufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6 jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvi d+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5l UkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaM xmgD5yKocwuxvKDaUljdCg5/wYIxggT5MIIE9QIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhAkrae1/NMMzSeh nyAmnVf3MAkGBSsOAwIaBQCgggLbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMTEwODE0MzYyMFowIwYJKoZIhvcNAQkEMRYEFNuQA6pIhFT3CQC0KYfA hwvtFJjCMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQJK2ntfzTDM0noZ8gJp1X 9zCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCECStp7X80wzNJ6GfICadV/cwDQYJ KoZIhvcNAQEBBQAEggEAP604oFc1dNHuWEHqGcgTZVVR1iY6FE+i253Wg40606hFJhD7guvx nRrS4nP2Q0pn8J0uNNrMSAYZ5d21v5W2NFjz/xvVsFzoZy1Iv5qdkSF/zE4esxKDN4+QAz2r jUzJ/ae/512YD5MReESAINz68Zj5NxxI4iYQl3AWuVOFdgfEYc6olmU68Sk9tpy7W5YZDwy/ KQZGV/0giWCNQeXo8UJU9/Q8sFLcBoILf+yQUzxgRlwGWn/n0L32y2OyIdiwilD0+j7flWdl KoIxQsdDDGCikcz1KImuwdKRkHnfxY/0U3EYMdDRxou3M+UDnqyactJ1z9DJIH9k49FOOOUO 4gAAAAAAAA== --------------ms000202050703040906030809-- From leifj@mnt.se Thu Nov 8 12:21:00 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C90D21F8901 for ; Thu, 8 Nov 2012 12:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGlJqOqCnO2H for ; Thu, 8 Nov 2012 12:21:00 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2077D21F8738 for ; Thu, 8 Nov 2012 12:21:00 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1420634dan.31 for ; Thu, 08 Nov 2012 12:20:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=blsreEGD7Tdbtljtw9tcLOwcJfZAC0tFVlhWpBUq/2c=; b=a+pPvQllA5FIPN0kb1hbjJHowdTCZiF8PuVQnZIF6OMfA6ESJCKHvSpp4b8CoImsCN eg2C135R1sUiHtsFlCgUSdZaFWr7Wu77tJgisRTNFK9SLIAfyKiAM3DmgU9/11fZ8TA7 4vmgQQwpSQ0DuPvzgzmffECZkzXm3FkJKxkwrvayGPcf7A060ffE3g5I5la/iYIvtjL3 TgsLZhK/HPbDHUGbQxyrwVLlgVVjniF/BZx/fr0cbpurJeqVtT7yQzVwnqUGXYbZ9awE QY4DXNW4q572lkFCB0VFPpgbn0Z0b+eDT2UWaZXGgTHlJfZYqrU+0g+/WcD4s+JfRIV3 UXIw== Received: by 10.66.73.226 with SMTP id o2mr19247487pav.83.1352406059663; Thu, 08 Nov 2012 12:20:59 -0800 (PST) Received: from [130.129.9.70] (dhcp-9146.meeting.ietf.org. [130.129.9.70]) by mx.google.com with ESMTPS id is6sm16422795pbc.55.2012.11.08.12.20.58 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 12:20:58 -0800 (PST) Message-ID: <509C1429.3010205@mnt.se> Date: Thu, 08 Nov 2012 21:20:57 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: scim@ietf.org References: <068.6f8ea83285aaea9cd481e0e5a8490f9c@tools.ietf.org> <083.1dd51238238687e2c8a67e0faf29da50@tools.ietf.org> <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl7nHeBOTPHEjoZDt2J4GiwQFD4p0WUdrk33dT+DCKoUdSn5ECqnGoD3mrBkEdS1OVIceic Subject: Re: [scim] #27: Make support for XML optional or drop it; JSON required X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 20:21:00 -0000 On 11/02/2012 05:55 PM, Kelly Grizzle wrote: > Please review the proposed changes to remove XML support from SCIM. Any feedback is greatly appreciated. I have attached the full txt documents, which may be easier to read than the diffs (attached to ticket #27). > There was strong consensus in the WG meeting in Atlanta for dropping XML in favour of JSON. If anyone opposes this change, now is the time to speak up, or the chairs will call consensus on this issue. Cheers Leif From edreux@cloudiway.com Thu Nov 8 14:19:10 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8211621F87F2 for ; Thu, 8 Nov 2012 14:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEh0KfyOwPoC for ; Thu, 8 Nov 2012 14:19:09 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7DE21F85A1 for ; Thu, 8 Nov 2012 14:19:09 -0800 (PST) Received: from mail150-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Nov 2012 22:19:08 +0000 Received: from mail150-co1 (localhost [127.0.0.1]) by mail150-co1-R.bigfish.com (Postfix) with ESMTP id AD8CCD011E0; Thu, 8 Nov 2012 22:19:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT003.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -49 X-BigFish: PS-49(zzc89bh103dKd772h15caKJzz1de0h1202h1d1ah1d2ahzz17326ah8275bhz2fh2a8h668h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received-SPF: pass (mail150-co1: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT003.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail150-co1 (localhost.localdomain [127.0.0.1]) by mail150-co1 (MessageSwitch) id 135241314510790_9837; Thu, 8 Nov 2012 22:19:05 +0000 (UTC) Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.234]) by mail150-co1.bigfish.com (Postfix) with ESMTP id EADCF940019; Thu, 8 Nov 2012 22:19:04 +0000 (UTC) Received: from AMXPRD0610HT003.eurprd06.prod.outlook.com (157.56.248.213) by CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Nov 2012 22:19:04 +0000 Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.1.229]) by AMXPRD0610HT003.eurprd06.prod.outlook.com ([10.255.58.38]) with mapi id 14.16.0233.004; Thu, 8 Nov 2012 22:19:02 +0000 From: Emmanuel Dreux To: Bjorn Aannestad , scim WG Thread-Topic: [scim] SCIM and Cloud-based Directory Services Thread-Index: AQHNvevgF5HVx7jRNE6+ivx3G/fIr5fgfNlQ Date: Thu, 8 Nov 2012 22:19:02 +0000 Message-ID: References: <509BC364.3080209@unboundid.com> In-Reply-To: <509BC364.3080209@unboundid.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.41.78.204] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Subject: Re: [scim] SCIM and Cloud-based Directory Services X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 22:19:10 -0000 We have merged SCIM into a WEBID implementation to provide authentication w= ithout password. We presented it last week at the W3C TPAC who took place in Lyon with the p= resence of Tim Berners Lee in the room. We have used the open source project https://my-profile.eu/ which has a bui= ltin webid profile server implementation and added automatic provisioning o= f webid profiles through SCIM (Active Directory to webid synchronization). For that, we had to create a brand new SCIM schema. The first deployment is planned beginning of January for a SAAS partner who= provides virtual desktops for BYOD scenarios. Target: about 15 000 student= s. We'll be able to communicate about it in the beginning of 2013. Additional note: The interesting thing in this project is that we imagined exchanging data d= irectly in RDF instead of JSON or XML. (And you could/would argue that it's not SCIM anymore). I remember a thread this week about removing XML and adding vcard support. -1 for this. If you want a technological breakthrough, integrate native rdf support, and= this will open IAM platforms to semantic intelligence, with native storage= of identities as RDF graphs. -- Cordialement / Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux -----Message d'origine----- De=A0: Bjorn Aannestad [mailto:bjorn.aannestad@unboundid.com]=20 Envoy=E9=A0: jeudi 8 novembre 2012 15:36 =C0=A0: scim WG Objet=A0: [scim] SCIM and Cloud-based Directory Services I'll be giving a short talk next week introducing "SCIM and Cloud-based=20 Directory Services". (The Ping event in Ft.Worth/Dallas). To=20 encourage further adoption of SCIM, I'd like to cite the momentum it=20 already has. If you have or know of a SCIM implementation effort that extends SCIM=20 beyond provisioning, please let me know. All I need is the company=20 name/project name, though I'd be very interested in further=20 conversations here at IETF or later. UnboundID has one, and I am aware of Phil Hunt's draft directory spec. Thanks! -Bjorn Aannestad --=20 __________________________________________________________ Bjorn Aannestad | Dir, Product Management | UnboundID Corp mailto:bjorn@unboundid.com | 512-769-6461 From ietf@meetecho.com Fri Nov 9 09:08:56 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C9621F8553 for ; Fri, 9 Nov 2012 09:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4AYDC5ENWSD for ; Fri, 9 Nov 2012 09:08:56 -0800 (PST) Received: from smtpdg7.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id 702BB21F84ED for ; Fri, 9 Nov 2012 09:08:56 -0800 (PST) Received: from [130.129.19.11] ([130.129.19.11]) by smtpcmd03.ad.aruba.it with bizsmtp id MV8t1k00t0ELJoa01V8uh7; Fri, 09 Nov 2012 18:08:54 +0100 Message-ID: <509D38A3.7080106@meetecho.com> Date: Fri, 09 Nov 2012 18:08:51 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: scim@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [scim] Meetecho session recording X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:08:57 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From bjorn.aannestad@unboundid.com Fri Nov 9 13:04:39 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAA021F8630 for ; Fri, 9 Nov 2012 13:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3VtUy2NaGuv for ; Fri, 9 Nov 2012 13:04:38 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51F5621F862A for ; Fri, 9 Nov 2012 13:04:38 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so4803305oag.31 for ; Fri, 09 Nov 2012 13:04:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=b7MLSoRcSgxcIxqJszFhRwlrveHzVSwOJXk9hgbdoHk=; b=VavTgGhVZw+qiFeqCjtKicFdlgzkJQtMO8d23PvKBHbJ4WcG2+ncvhXlUK71gAGgCB sBS16S8w8pwtaWjuedPgaVJXOwPb+00GftaKJ0BwnRJYzmhqdUZq/GABJ5KaU9Y9m6DN 0jn1QGsTVrW0E7zJ79irKTio/kwiiYmFxgPQnwKBLZvmn5mt1vaPVwmpLOHuEWuqwCV+ f4WzsrbthMxWhWT24D8bdU8yyos4QjZ+Amev+M15K8cMzBsCNpmbXzM532XzLHKxWUgt exvM/9kH8UjUXg/Rk2FqQb0MSz4se9JhhtpFTQCMExiDsQq+9p8zhT71EjBDNIBDv8E8 cW/g== Received: by 10.60.170.43 with SMTP id aj11mr9113153oec.71.1352495077644; Fri, 09 Nov 2012 13:04:37 -0800 (PST) Received: from [10.8.1.249] (rrcs-97-77-98-66.sw.biz.rr.com. [97.77.98.66]) by mx.google.com with ESMTPS id z1sm8614447oeh.7.2012.11.09.13.04.35 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 13:04:36 -0800 (PST) Message-ID: <509D6FDE.70206@unboundid.com> Date: Fri, 09 Nov 2012 15:04:30 -0600 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Emmanuel Dreux References: <509BC364.3080209@unboundid.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090108010303080506090107" X-Gm-Message-State: ALoCoQnwn72PB1o9bZ4C+M0HJmfiIiUaMo6RA4kO8ixZec9gF3a4hHmnNiWmsVtVJhFEbHnqW6p0 Cc: scim WG Subject: Re: [scim] SCIM and Cloud-based Directory Services X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 21:04:39 -0000 This is a cryptographically signed message in MIME format. --------------ms090108010303080506090107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Thank you, Emmanuel, that is this helpful! -Bjorn On 11/8/2012 16:19, Emmanuel Dreux wrote: > We have merged SCIM into a WEBID implementation to provide authenticati= on without password. > We presented it last week at the W3C TPAC who took place in Lyon with t= he presence of Tim Berners Lee in the room. > > We have used the open source project https://my-profile.eu/ which has a= builtin webid profile server implementation and added automatic provisio= ning of webid profiles through SCIM (Active Directory to webid synchroniz= ation). > > For that, we had to create a brand new SCIM schema. > The first deployment is planned beginning of January for a SAAS partner= who provides virtual desktops for BYOD scenarios. Target: about 15 000 s= tudents. > We'll be able to communicate about it in the beginning of 2013. > > Additional note: > The interesting thing in this project is that we imagined exchanging da= ta directly in RDF instead of JSON or XML. > (And you could/would argue that it's not SCIM anymore). > > I remember a thread this week about removing XML and adding vcard suppo= rt. > -1 for this. > If you want a technological breakthrough, integrate native rdf support,= and this will open IAM platforms to semantic intelligence, with native s= torage of identities as RDF graphs. > > -- > Cordialement / Regards, > Emmanuel Dreux > http://www.cloudiway.com > Tel: +33 4 26 78 17 58 > Mobile: +33 6 47 81 26 70 > skype: Emmanuel.Dreux > > -----Message d'origine----- > De : Bjorn Aannestad [mailto:bjorn.aannestad@unboundid.com] > Envoy=E9 : jeudi 8 novembre 2012 15:36 > =C0 : scim WG > Objet : [scim] SCIM and Cloud-based Directory Services > > > I'll be giving a short talk next week introducing "SCIM and Cloud-based= > Directory Services". (The Ping event in Ft.Worth/Dallas). To > encourage further adoption of SCIM, I'd like to cite the momentum it > already has. > > If you have or know of a SCIM implementation effort that extends SCIM > beyond provisioning, please let me know. All I need is the company > name/project name, though I'd be very interested in further > conversations here at IETF or later. > > UnboundID has one, and I am aware of Phil Hunt's draft directory spec. > > Thanks! > -Bjorn Aannestad > --=20 __________________________________________________________ Bjorn Aannestad | Dir, Product Management | UnboundID Corp mailto:bjorn@unboundid.com | 512-769-6461 --------------ms090108010303080506090107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMUjCC BVwwggREoAMCAQICECStp7X80wzNJ6GfICadV/cwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjAyMjMwMDAwMDBaFw0xMzAyMjIyMzU5NTlaMIIBHzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRgwFgYDVQQDFA9Cam9ybiBBYW5u ZXN0YWQxLDAqBgkqhkiG9w0BCQEWHWJqb3JuLmFhbm5lc3RhZEB1bmJvdW5kaWQuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw+4r+Le4uODrErBgJsA7UoexcjH/r2Ds 62wKyDCY5CQfOFMROnynV9GWWXp8zmCj7/N9I2hOU7poaqR4kkJjoiKiNHQdVfyM1yFZTurW AV5PCT5NouiqlruJDM6s2HV3B7mSRhtHFOSfhiDP+/kHf/JEdFJ7zEPaP0Kuy8XKpPR5nVCz k4zFKPBc4T9+HAlXeGY1PnwOsxPEevZlHOTThF9RunZu5Z/uaObR2JplM6KxXDfXNRjSkmK7 6kW8wFC1C0GleHKfM85nQTvVicuSK4GbbvhMjqovMtUIR1SNG8vsmTvU4PY9G/WkDM4Ge/97 phIcQIm9W/DXjC78wBfa/QIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5Bgtg hkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh MAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkw RzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5k QzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQC345zS3026vrJVysBCE3TN BhQ4VlqRtwj5AcAXhhF2c3krlbgJRLV6STYky+/i7YRdezIZYgY2eo693dlIQUnkZMb6D2PL dRs1Lgw4NJKB+WGLGkmyV8YqqKrTm/ZbPdl/+Y4Pc88DLcYEmr0OsEDel8LqLPpongUDnGU5 2wxAvaHn9sZ4nyDa3bAy9RyqrAdWhsfRttlgAbvMeHSXhvDa63AbdGdZbzBfqGpBTYZJqrA/ fzcbVZQIw7ULW0YRpUNx8bmmgxFd5ovdDVZnfiKNd7QHy+BcTQgfxLYsBYZhICz1ud1QKn88 pW944VjwHTzxyErX43AGoPYoZKA8b3XXMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT 3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5 OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6 ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f 0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Iba k2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+ wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBn MGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNV HR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNV HQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAH BgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24u Y29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0 LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHm oYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSo WufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6 jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvi d+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5l UkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaM xmgD5yKocwuxvKDaUljdCg5/wYIxggT5MIIE9QIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhAkrae1/NMMzSeh nyAmnVf3MAkGBSsOAwIaBQCgggLbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMTEwOTIxMDQzMFowIwYJKoZIhvcNAQkEMRYEFGRSRXnca0o7kTUE5mF/ 4Yf2SD4MMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQJK2ntfzTDM0noZ8gJp1X 9zCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCECStp7X80wzNJ6GfICadV/cwDQYJ KoZIhvcNAQEBBQAEggEAIWb7b560qbIQEjHKIi5yzFbwKTD1aeV2ejU+DJ2m9AD9V8j0tTff zB70SueV46hNYx5aSN808i5zscNudKH5gbrtXc157LA0HV4Lflf350kL17Ils6718Wp9EgzK H2b1D9DwRHtZD3zwidifBq1PrpspD5DRoiwBi+AN3gDMa5BlrQxHsWmkwO0M42PtIE9kuRZR bDuKGCBO+SJDo87QdjXRTG/jq4bH/5jz+IL+tjDmjlrBdZqlX6T+eICpulV56ea8rc7zz2wL pXaTYTJHcm2ANPotm8H6J3varcatnD25D48KftC5vl0iWMMXTMZCxRBxH+CGLiVBhcdcZQ80 nwAAAAAAAA== --------------ms090108010303080506090107-- From phil.hunt@oracle.com Fri Nov 9 13:15:59 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215D621F8C31 for ; Fri, 9 Nov 2012 13:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=-1.362, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HvMei68e7e2 for ; Fri, 9 Nov 2012 13:15:58 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5990221F8BC9 for ; Fri, 9 Nov 2012 13:15:58 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA9LFt9c031894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Nov 2012 21:15:56 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA9LFsoo013898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2012 21:15:55 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qA9LFs6Z006360; Fri, 9 Nov 2012 15:15:54 -0600 Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Nov 2012 13:15:54 -0800 References: <509BC364.3080209@unboundid.com> <509D6FDE.70206@unboundid.com> Mime-Version: 1.0 (1.0) In-Reply-To: <509D6FDE.70206@unboundid.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <2B53B93B-5D64-4A4E-A9B4-F49FE55A876D@oracle.com> X-Mailer: iPhone Mail (10A523) From: Phil Hunt Date: Fri, 9 Nov 2012 13:15:52 -0800 To: Bjorn Aannestad X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: scim WG , Emmanuel Dreux Subject: Re: [scim] SCIM and Cloud-based Directory Services X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 21:15:59 -0000 I would very much prefer keeping authn out of scim. I don't want to imply or= limit possibilities for authn support. Keep it to other layers.=20 Phil On 2012-11-09, at 13:04, Bjorn Aannestad wro= te: > Thank you, Emmanuel, that is this helpful! >=20 > -Bjorn >=20 > On 11/8/2012 16:19, Emmanuel Dreux wrote: >> We have merged SCIM into a WEBID implementation to provide authentication= without password. >> We presented it last week at the W3C TPAC who took place in Lyon with the= presence of Tim Berners Lee in the room. >>=20 >> We have used the open source project https://my-profile.eu/ which has a b= uiltin webid profile server implementation and added automatic provisioning o= f webid profiles through SCIM (Active Directory to webid synchronization). >>=20 >> For that, we had to create a brand new SCIM schema. >> The first deployment is planned beginning of January for a SAAS partner w= ho provides virtual desktops for BYOD scenarios. Target: about 15 000 studen= ts. >> We'll be able to communicate about it in the beginning of 2013. >>=20 >> Additional note: >> The interesting thing in this project is that we imagined exchanging data= directly in RDF instead of JSON or XML. >> (And you could/would argue that it's not SCIM anymore). >>=20 >> I remember a thread this week about removing XML and adding vcard support= . >> -1 for this. >> If you want a technological breakthrough, integrate native rdf support, a= nd this will open IAM platforms to semantic intelligence, with native storag= e of identities as RDF graphs. >>=20 >> -- >> Cordialement / Regards, >> Emmanuel Dreux >> http://www.cloudiway.com >> Tel: +33 4 26 78 17 58 >> Mobile: +33 6 47 81 26 70 >> skype: Emmanuel.Dreux >>=20 >> -----Message d'origine----- >> De : Bjorn Aannestad [mailto:bjorn.aannestad@unboundid.com] >> Envoy=C3=A9 : jeudi 8 novembre 2012 15:36 >> =C3=80 : scim WG >> Objet : [scim] SCIM and Cloud-based Directory Services >>=20 >>=20 >> I'll be giving a short talk next week introducing "SCIM and Cloud-based >> Directory Services". (The Ping event in Ft.Worth/Dallas). To >> encourage further adoption of SCIM, I'd like to cite the momentum it >> already has. >>=20 >> If you have or know of a SCIM implementation effort that extends SCIM >> beyond provisioning, please let me know. All I need is the company >> name/project name, though I'd be very interested in further >> conversations here at IETF or later. >>=20 >> UnboundID has one, and I am aware of Phil Hunt's draft directory spec. >>=20 >> Thanks! >> -Bjorn Aannestad >=20 > --=20 > __________________________________________________________ > Bjorn Aannestad | Dir, Product Management | UnboundID Corp > mailto:bjorn@unboundid.com | 512-769-6461 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From melinda.shore@gmail.com Fri Nov 9 13:21:46 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406CD21F87E5 for ; Fri, 9 Nov 2012 13:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izO+YxMnGEuM for ; Fri, 9 Nov 2012 13:21:45 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B39C021F86F1 for ; Fri, 9 Nov 2012 13:21:45 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id l13so897127yen.31 for ; Fri, 09 Nov 2012 13:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=sFnMgyGf3XCYmeKOKhRotrEw8s3+WOa6C4GU3ai5Xlo=; b=rdaA0gyXhRkbQcUp/4XqwjhPIqWnd88ZT4yAK3RlIHFQQImTIVEquCjXdksz6mJLYF oPvkk0mBFf4Y6je0tYv6by4zRfzAO4KVxdTWx+2HsdTy32YueMthonGQMk8bpQ8IpBum 9wNUiejxveS23EinwMHtabDS8xtdehKctAHrULQOLWHQ52eQYN2mm+SjvdiTnE1l5h1Q ARCDEYot2fEV3RPrEPOAijYaQRZQ1m+Qau1zY9sHjh6AEPVhMdmyPEP/uXuY5Glhu37M 1jDOZm/9yU+9vMlBvcCryfanzf91zTnStGlOxqeOrByq7Y+X4UlLjRp/AvNT4AH1FqFW G/SA== Received: by 10.101.73.2 with SMTP id a2mr3696742anl.82.1352496095343; Fri, 09 Nov 2012 13:21:35 -0800 (PST) Received: from [107.17.123.237] (dhcp107-17-123-237.hil-atlahhh.atl.wayport.net. [107.17.123.237]) by mx.google.com with ESMTPS id t12sm14459562ane.6.2012.11.09.13.21.34 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 13:21:34 -0800 (PST) Message-ID: <509D73DE.8080900@gmail.com> Date: Fri, 09 Nov 2012 12:21:34 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org References: <509BC364.3080209@unboundid.com> <509D6FDE.70206@unboundid.com> <2B53B93B-5D64-4A4E-A9B4-F49FE55A876D@oracle.com> In-Reply-To: <2B53B93B-5D64-4A4E-A9B4-F49FE55A876D@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [scim] SCIM and Cloud-based Directory Services X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 21:21:46 -0000 On 11/9/2012 12:15 PM, Phil Hunt wrote: > I would very much prefer keeping authn out of scim. I don't want to > imply or limit possibilities for authn support. Keep it to other > layers. I don't think that's possible, since it can lead to interoperability problems and has potentially serious consequences (do you really want to allow an unauthenticated entity to provision identities?). At a minimum it will need to be discussed in the security considerations section. Melinda From bjorn.aannestad@unboundid.com Fri Nov 9 13:28:52 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830F521F89F4 for ; Fri, 9 Nov 2012 13:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCUVD5h4IBxh for ; Fri, 9 Nov 2012 13:28:52 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E631621F8862 for ; Fri, 9 Nov 2012 13:28:51 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so4821799oag.31 for ; Fri, 09 Nov 2012 13:28:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:x-gm-message-state; bh=HP0sZk9uAa5kKVHjy1tGptAXtSKER7zS10zcsX9SSeU=; b=KfwB10XsCauBf9N96H/3Hwb5n+LUE39yvtlUYGANg/8lPlH8EUQq2RlC77E1KJoo7H geUbr0qvVAHHi43N1iqw2C2uDwD96aoADFKkkxZD9/Tu8riwZDqUuNc3E+CQc+oXJYJy lh79CABvl5wCzg+p4+DhTAcjvZ7EBXuIFzs5c6jDS+uAbfp6QKtdFqoqzWnroZSuNPDF 7cBenYdei/GkxuIloTg4GFkDzt0dC8LJE61yx+U0Ht81Q4lOSVs+LQCKp/Ebc454zYc9 wP1OBZA4aSxsd0CQcuq/pACOHGIZSorhi2gHqt08kW4Mpq2/uWMwhneV6Q4Dh6lAnioy W92Q== Received: by 10.60.31.241 with SMTP id d17mr8839856oei.107.1352496531507; Fri, 09 Nov 2012 13:28:51 -0800 (PST) Received: from [10.8.1.249] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id zy9sm6611899oeb.4.2012.11.09.13.28.50 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 13:28:50 -0800 (PST) Message-ID: <509D758D.5030809@unboundid.com> Date: Fri, 09 Nov 2012 15:28:45 -0600 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Melinda Shore , scim WG References: <509BC364.3080209@unboundid.com> <509D6FDE.70206@unboundid.com> <2B53B93B-5D64-4A4E-A9B4-F49FE55A876D@oracle.com> <509D73DE.8080900@gmail.com> In-Reply-To: <509D73DE.8080900@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020108030007010501080303" X-Gm-Message-State: ALoCoQncdQDkWmYF0W1TV9eXtti6sl9+VZ5ywFhbIq24h50ELazcfHvhgLHfOj3ylF9PVGaVkJrl Subject: Re: [scim] SCIM and Cloud-based Directory Services X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 21:28:52 -0000 This is a cryptographically signed message in MIME format. --------------ms020108030007010501080303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Two points: 1. This thread started as a request by me to surface SCIM-as-directory=20 projects 2. I think the SCIM docs already cover the stance with respect to=20 authN. However, if we want to discuss that, let's start a different thre= ad. -Bjorn On 11/9/2012 15:21, Melinda Shore wrote: > On 11/9/2012 12:15 PM, Phil Hunt wrote: >> I would very much prefer keeping authn out of scim. I don't want to >> imply or limit possibilities for authn support. Keep it to other >> layers. > I don't think that's possible, since it can lead to interoperability > problems and has potentially serious consequences (do you > really want to allow an unauthenticated entity to provision > identities?). At a minimum it will need to be discussed in the > security considerations section. > > Melinda > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --=20 __________________________________________________________ Bjorn Aannestad | Dir, Product Management | UnboundID Corp mailto:bjorn@unboundid.com | 512-769-6461 --------------ms020108030007010501080303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMUjCC BVwwggREoAMCAQICECStp7X80wzNJ6GfICadV/cwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjAyMjMwMDAwMDBaFw0xMzAyMjIyMzU5NTlaMIIBHzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRgwFgYDVQQDFA9Cam9ybiBBYW5u ZXN0YWQxLDAqBgkqhkiG9w0BCQEWHWJqb3JuLmFhbm5lc3RhZEB1bmJvdW5kaWQuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw+4r+Le4uODrErBgJsA7UoexcjH/r2Ds 62wKyDCY5CQfOFMROnynV9GWWXp8zmCj7/N9I2hOU7poaqR4kkJjoiKiNHQdVfyM1yFZTurW AV5PCT5NouiqlruJDM6s2HV3B7mSRhtHFOSfhiDP+/kHf/JEdFJ7zEPaP0Kuy8XKpPR5nVCz k4zFKPBc4T9+HAlXeGY1PnwOsxPEevZlHOTThF9RunZu5Z/uaObR2JplM6KxXDfXNRjSkmK7 6kW8wFC1C0GleHKfM85nQTvVicuSK4GbbvhMjqovMtUIR1SNG8vsmTvU4PY9G/WkDM4Ge/97 phIcQIm9W/DXjC78wBfa/QIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5Bgtg hkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh MAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkw RzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5k QzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQC345zS3026vrJVysBCE3TN BhQ4VlqRtwj5AcAXhhF2c3krlbgJRLV6STYky+/i7YRdezIZYgY2eo693dlIQUnkZMb6D2PL dRs1Lgw4NJKB+WGLGkmyV8YqqKrTm/ZbPdl/+Y4Pc88DLcYEmr0OsEDel8LqLPpongUDnGU5 2wxAvaHn9sZ4nyDa3bAy9RyqrAdWhsfRttlgAbvMeHSXhvDa63AbdGdZbzBfqGpBTYZJqrA/ fzcbVZQIw7ULW0YRpUNx8bmmgxFd5ovdDVZnfiKNd7QHy+BcTQgfxLYsBYZhICz1ud1QKn88 pW944VjwHTzxyErX43AGoPYoZKA8b3XXMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT 3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5 OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6 ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f 0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Iba k2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+ wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBn MGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNV HR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNV HQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAH BgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24u Y29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0 LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHm oYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSo WufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6 jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvi d+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5l UkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaM xmgD5yKocwuxvKDaUljdCg5/wYIxggT5MIIE9QIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhAkrae1/NMMzSeh nyAmnVf3MAkGBSsOAwIaBQCgggLbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMTEwOTIxMjg0NVowIwYJKoZIhvcNAQkEMRYEFLrYMOl4f8ILzx+NCRbl 11xs/dXlMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQJK2ntfzTDM0noZ8gJp1X 9zCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCECStp7X80wzNJ6GfICadV/cwDQYJ KoZIhvcNAQEBBQAEggEAQJ2Pwpn52RSsTXSPLzMVRCpnbkXiaBSsn+YuN00FXpAqyoVOiYqG AZfdLmdJGGatiianFXmVs6yfVz60+DOTGlCrPm1zGhJv3NLkTBhDGEdWB7bD4oJzbLkPbJ8c dlkfzOI4r683SSiNKbLr0oEUUx0z309ZZXWacp+V6wkKJFTClmFpUNtWCLFMJWyupYslMeKe DcK0HPeWLcvqcWlWKp7mGlVfGy3ST5WlxxeQtQ8avtYO1Kh3+CCiIVEFpOEK37CsAptJWozT bhWKrVnTrGFfuFyQufjn7lytm/F5g3CJYpXX74MSC8ePtV0mgdr9xHSCUiu9cZHF6oT9yX4r CAAAAAAAAA== --------------ms020108030007010501080303-- From melinda.shore@gmail.com Fri Nov 9 13:46:15 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181FC21F8661 for ; Fri, 9 Nov 2012 13:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foLLvFPg1ooA for ; Fri, 9 Nov 2012 13:46:14 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBDE21F865B for ; Fri, 9 Nov 2012 13:46:14 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id wo10so1096935obc.31 for ; Fri, 09 Nov 2012 13:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QjRufUJB6fkII7hg9E3/G3QgjGx1Xv6kFMfDhQ3OMvM=; b=GbWBFX+iPPW1oRwD3/32Paw2yILcCSOwD3cdYgSVqh20HHjiSDTxPhex5An/FeBUuS 66ErHZIgtgvwPlOJbNVWI9D8KVDT2Ov3NhOyv/nuBfzivy5N0ipYlfo4IUmqHNtYJmCL Q1rVQkDjzIBts7VClp4j7uMKOEW4SeEdsM7WyDllOvU6bQ3N6KYYKRSgtCmwgwZW8pTv qe/A9cFQks3QqZazjRuvpCM97/8A6AVqHfP+Ubn7N8grPpm/nX2RO+l1q2Kf0Ifg1+yG Lp7RKH8M1V3L7meLDM2uW/zub9aC+afYkpLH1bwdiHtANauu3BbsM7HU148mowCrHLYL AXGQ== Received: by 10.60.170.81 with SMTP id ak17mr1125658oec.38.1352497574101; Fri, 09 Nov 2012 13:46:14 -0800 (PST) Received: from [107.17.123.237] (dhcp107-17-123-237.hil-atlahhh.atl.wayport.net. [107.17.123.237]) by mx.google.com with ESMTPS id d6sm30687287obx.15.2012.11.09.13.46.13 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 13:46:13 -0800 (PST) Message-ID: <509D79A5.3070502@gmail.com> Date: Fri, 09 Nov 2012 12:46:13 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Bjorn Aannestad References: <509BC364.3080209@unboundid.com> <509D6FDE.70206@unboundid.com> <2B53B93B-5D64-4A4E-A9B4-F49FE55A876D@oracle.com> <509D73DE.8080900@gmail.com> <509D758D.5030809@unboundid.com> In-Reply-To: <509D758D.5030809@unboundid.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: scim WG Subject: Re: [scim] SCIM and Cloud-based Directory Services X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 21:46:15 -0000 On 11/9/2012 12:28 PM, Bjorn Aannestad wrote: > 2. I think the SCIM docs already cover the stance with respect to > authN. However, if we want to discuss that, let's start a different > thread. Here's what's in the API draft: "The SCIM protocol does not define a scheme for authentication and authorization therefore implementers are free to choose mechanisms appropriate to their use cases." That is definitely going to need to be revisited at some point in the not-too-distant future, but it doesn't need to be discussed today. Melinda From phil.hunt@oracle.com Fri Nov 9 15:11:36 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA1F21F86BC for ; Fri, 9 Nov 2012 15:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrS68Ena13sS for ; Fri, 9 Nov 2012 15:11:35 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB1521F86A8 for ; Fri, 9 Nov 2012 15:11:35 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qA9NBXi3001115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Nov 2012 23:11:34 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qA9NBW7x013996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2012 23:11:33 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qA9NBWG6030876; Fri, 9 Nov 2012 17:11:32 -0600 Received: from [192.168.1.131] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Nov 2012 15:11:32 -0800 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <509D79A5.3070502@gmail.com> Date: Fri, 9 Nov 2012 15:11:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <85A8C428-262F-4BC6-9810-244F642E3126@oracle.com> References: <509BC364.3080209@unboundid.com> <509D6FDE.70206@unboundid.com> <2B53B93B-5D64-4A4E-A9B4-F49FE55A876D@oracle.com> <509D73DE.8080900@gmail.com> <509D758D.5030809@unboundid.com> <509D79A5.3070502@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: scim WG Subject: Re: [scim] SCIM and Cloud-based Directory Services X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 23:11:36 -0000 I agree there may be need for further clarification in both the core API = draft and the directory drafts on authentication. The phrase quoted below (specifically "SCIM protocol"), is incorrect. = Unlike LDAP, SCIM is not a TCP/IP protocol. SCIM is a RESTful service = that runs on HTTP protocol. =20 So while LDAP needed to have an authentication method (bind), HTTP = already has one. SCIM defining one is redundant and represents a lot of = potential complexity. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-11-09, at 1:46 PM, Melinda Shore wrote: > On 11/9/2012 12:28 PM, Bjorn Aannestad wrote: >> 2. I think the SCIM docs already cover the stance with respect to >> authN. However, if we want to discuss that, let's start a different >> thread. >=20 > Here's what's in the API draft: >=20 > "The SCIM protocol does not define a scheme for authentication and > authorization therefore implementers are free to choose mechanisms > appropriate to their use cases." >=20 > That is definitely going to need to be revisited at some point in the > not-too-distant future, but it doesn't need to be discussed today. >=20 > Melinda >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From melinda.shore@gmail.com Fri Nov 9 15:14:10 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B56921F84DF for ; Fri, 9 Nov 2012 15:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvP8UttQ3r3A for ; Fri, 9 Nov 2012 15:14:09 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3876921F84CE for ; Fri, 9 Nov 2012 15:14:09 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so3456803iak.31 for ; Fri, 09 Nov 2012 15:14:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=CKXKNEMBsxzZYnX9hssUmochriPcY9aS79aw+yw0Wug=; b=f5F/59TYI3+zrtX3EH8xEf8RSgWRvOGG6oO0pq4I04ZYYr7/Du0HZRlFJBiecJwOzu SFaxUpDKUHAD4mm/V7n+VMkHW9lHZaXFkILWvBTCxlhxdIHPww2/+mGu7cogDNGHx3sW EOwirDLhzFqhngJXClvU6dpRS8+jjSeBP7YQEaWwhCj5V8a5687huip8Jeiliwt51mee /GrcJQCQTNmc+dJ+JmE4FVCcY1ZOShupqNkfIVeiC85IQ/j1eoCfxk4CIopFP7W8WEkG hYLbGsK6vwSxetIKz+O20CVOxq+3fBKuLkwEQQkK57tBXo16oJchvqNm5+qpmzvuApif 9haQ== Received: by 10.43.98.196 with SMTP id cp4mr11551146icc.25.1352502845568; Fri, 09 Nov 2012 15:14:05 -0800 (PST) Received: from [107.17.123.237] (dhcp107-17-123-237.hil-atlahhh.atl.wayport.net. [107.17.123.237]) by mx.google.com with ESMTPS id 10sm2347221ign.5.2012.11.09.15.14.04 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 15:14:04 -0800 (PST) Message-ID: <509D8E3B.9050600@gmail.com> Date: Fri, 09 Nov 2012 14:14:03 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Phil Hunt References: <509BC364.3080209@unboundid.com> <509D6FDE.70206@unboundid.com> <2B53B93B-5D64-4A4E-A9B4-F49FE55A876D@oracle.com> <509D73DE.8080900@gmail.com> <509D758D.5030809@unboundid.com> <509D79A5.3070502@gmail.com> <85A8C428-262F-4BC6-9810-244F642E3126@oracle.com> In-Reply-To: <85A8C428-262F-4BC6-9810-244F642E3126@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: scim WG Subject: Re: [scim] SCIM and Cloud-based Directory Services X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 23:14:10 -0000 On 11/9/2012 2:11 PM, Phil Hunt wrote: > So while LDAP needed to have an authentication method (bind), HTTP > already has one. SCIM defining one is redundant and represents a lot > of potential complexity. Right, not to mention the considerable possibility of getting it wrong. I don't think that anybody was suggesting that the SCIM working group cook up a new authentication protocol, at least I hope not. But what needs to be done is to define/ describe/profile the use of an existing authentication mechanism. Melinda From hasini@wso2.com Fri Nov 9 16:03:03 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C6B21F85BC for ; Fri, 9 Nov 2012 16:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC-UdXPt8gUk for ; Fri, 9 Nov 2012 16:03:02 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2EA21F85BB for ; Fri, 9 Nov 2012 16:03:01 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4933585vbb.31 for ; Fri, 09 Nov 2012 16:03:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Y+cFdpKYjklI2LCC0CY+CAvJx2UbGnD2qqptFMzhQU4=; b=LGR7s83EXZzcQq1G2dldaqSAv+lAM97lW2ZJmwRHdisTeDdxoQQVQFRvJMlapoCYnk 2RjvhuZ5LLi15yRUunvhpbqWOfe75tPS7Z1rmP2LTUCo5TUWtzk0mjBWoOvOAMcnCkrK zp4uvuPyA2+/F5LAkZIt7DqTDulrfE34YcQeRfM4NnmM1qRT5SjPZ02MNSMNUqQKlOib o2m6QnCC2Vg6SlmZhgWkOgwwQitofS2C9I9ahrwrnYpUUqKmsGxvVNmLqgFEGzGt/KH1 rkZ4S41cGbvp/JRFNZxacTrnz12qbP3TuRdOhvVYQL56tXnx5YQihPbiQ1JVt57i2J8V rAPQ== MIME-Version: 1.0 Received: by 10.52.23.225 with SMTP id p1mr10953921vdf.79.1352505780780; Fri, 09 Nov 2012 16:03:00 -0800 (PST) Received: by 10.220.207.208 with HTTP; Fri, 9 Nov 2012 16:03:00 -0800 (PST) In-Reply-To: <509BC364.3080209@unboundid.com> References: <509BC364.3080209@unboundid.com> Date: Sat, 10 Nov 2012 05:33:00 +0530 Message-ID: From: Hasini Gunasinghe To: Bjorn Aannestad Content-Type: multipart/alternative; boundary=20cf307ca1ac9ebfc104ce18caa5 X-Gm-Message-State: ALoCoQlJMy+EJS3cCM4W0lTWKxvmm1tlV7EWou6AE+Nku6vUjrnKHK1zToLI24ZThKBHB6v832D1 Cc: scim WG Subject: Re: [scim] SCIM and Cloud-based Directory Services X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 00:03:03 -0000 --20cf307ca1ac9ebfc104ce18caa5 Content-Type: text/plain; charset=ISO-8859-1 Hi Bjorn, WSO2 Identity Server supports SCIM in its 4.0.0 release, based on WSO2 Charon which implements the SCIM specification under Apache 2.0 license. You can find more info about the supported use cases etc at: http://hasini-gunasinghe.blogspot.com/search/label/SCIM Thanks, Hasini. On Thu, Nov 8, 2012 at 8:06 PM, Bjorn Aannestad < bjorn.aannestad@unboundid.com> wrote: > > I'll be giving a short talk next week introducing "SCIM and Cloud-based > Directory Services". (The Ping event in Ft.Worth/Dallas). To encourage > further adoption of SCIM, I'd like to cite the momentum it already has. > > If you have or know of a SCIM implementation effort that extends SCIM > beyond provisioning, please let me know. All I need is the company > name/project name, though I'd be very interested in further conversations > here at IETF or later. > > UnboundID has one, and I am aware of Phil Hunt's draft directory spec. > > Thanks! > -Bjorn Aannestad > > -- > ______________________________**____________________________ > Bjorn Aannestad | Dir, Product Management | UnboundID Corp > mailto:bjorn@unboundid.com | 512-769-6461 > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --20cf307ca1ac9ebfc104ce18caa5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Bjorn,

WSO2 Identity Server supports SCIM in its 4.0.0 release, based = on WSO2 Charon which implements the SCIM specification under Apache 2.0 lic= ense.

You can find more info about the supported use cases et= c at:=A0http://hasini-gunasinghe.blogspot.com/search/label/SCIM

Thanks,
Hasini.

On T= hu, Nov 8, 2012 at 8:06 PM, Bjorn Aannestad <bjorn.aannestad= @unboundid.com> wrote:

I'll be giving a short talk next week introducing "SCIM and Cloud-= based Directory Services". =A0 (The Ping event in Ft.Worth/Dallas). = =A0 =A0To encourage further adoption of SCIM, I'd like to cite the mome= ntum it already has.

If you have or know of a SCIM implementation effort that extends SCIM beyon= d provisioning, please let me know. =A0 =A0All I need is the company name/p= roject name, though I'd be very interested in further conversations her= e at IETF or later.

UnboundID has one, and I am aware of Phil Hunt's draft directory spec.<= br>
Thanks!
-Bjorn Aannestad

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



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


--20cf307ca1ac9ebfc104ce18caa5-- From kelly.grizzle@sailpoint.com Mon Nov 12 06:35:06 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8906321F85AF for ; Mon, 12 Nov 2012 06:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRtECMsgWae4 for ; Mon, 12 Nov 2012 06:35:06 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id ED9A121F8419 for ; Mon, 12 Nov 2012 06:35:05 -0800 (PST) Received: from mail57-co1-R.bigfish.com (10.243.78.235) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.23; Mon, 12 Nov 2012 14:35:05 +0000 Received: from mail57-co1 (localhost [127.0.0.1]) by mail57-co1-R.bigfish.com (Postfix) with ESMTP id 0FEDC2E03EA for ; Mon, 12 Nov 2012 14:35:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic89bh542Mzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received-SPF: pass (mail57-co1: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail57-co1 (localhost.localdomain [127.0.0.1]) by mail57-co1 (MessageSwitch) id 1352730890245606_29080; Mon, 12 Nov 2012 14:34:50 +0000 (UTC) Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.226]) by mail57-co1.bigfish.com (Postfix) with ESMTP id 307C6700611 for ; Mon, 12 Nov 2012 14:34:50 +0000 (UTC) Received: from BY2PRD0410HT002.namprd04.prod.outlook.com (157.56.236.85) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 12 Nov 2012 14:34:48 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.12.218]) by BY2PRD0410HT002.namprd04.prod.outlook.com ([10.255.83.37]) with mapi id 14.16.0233.002; Mon, 12 Nov 2012 14:34:46 +0000 From: Kelly Grizzle To: "scim@ietf.org" Thread-Topic: Proposal to close ticket #5 as "won't fix" Thread-Index: Ac3A4J2e7cFScCBFQXei+4RyK7xduQ== Date: Mon, 12 Nov 2012 14:34:45 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34373E8301FD@BY2PRD0410MB354.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 2395466C003654239547B9 x-originating-ip: [72.182.10.254] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: [scim] Proposal to close ticket #5 as "won't fix" X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 14:35:06 -0000 VGlja2V0ICM1IGluIHRoZSBpc3N1ZSB0cmFja2VyIHN1Z2dlc3RzIGFsbG93aW5nIGFuIGF0dHJp YnV0ZSBvdGhlciB0aGFuIHRoZSBVc2VyIGlkIHRvIGJlIHVzZWQgZm9yIHJlZmVyZW5jZXMgaW4g dGhlIG1lbWJlcnMgYXR0cmlidXRlIG9mIHRoZSBHcm91cCBzY2hlbWEuICBUaGUgcmVhc29uaW5n IGZvciB0aGlzIHByb3Bvc2FsIHdhcyB0aGF0IGl0IHdvdWxkIGFsbG93IGNsaWVudHMgdG8gcHJv Y2VzcyBncm91cCBtZW1iZXJzaGlwIHdpdGhvdXQgaGF2aW5nIHRvIG1hcCBhIHNlcnZlci1nZW5l cmF0ZWQgaWQgdG8gdGhlIGNsaWVudCdzIHVuaXF1ZSBpZGVudGlmaWVyLiAgSG93ZXZlciwgdGhl IGV4dGVybmFsSWQgaXMgbmVpdGhlciByZXF1aXJlZCB0byBiZSBwcmVzZW50IG9yIGd1YXJhbnRl ZWQgdG8gYmUgdW5pcXVlIChzZWUgaXNzdWUgNzkgaW4gdGhlIGdvb2dsZSBpc3N1ZSB0cmFja2Vy IC0gaHR0cDovL2NvZGUuZ29vZ2xlLmNvbS9wL3NjaW0vaXNzdWVzL2RldGFpbD9pZD03OSkuICBJ IGFtIHByb3Bvc2luZyB0byBjbG9zZSB0aGlzIHRpY2tldCBhcyAid29uJ3QgZml4IiBzaW5jZSB0 aGVyZSBpcyBub3QgYSByZWxpYWJsZSB3YXkgdG8gcmVmZXJlbmNlIGEgdXNlciB3aXRob3V0IHVz aW5nIHRoZSBpZC4NCg0KUGxlYXNlIHJlc3BvbmQgd2l0aCBhbnkgY29tbWVudHMuDQoNCi0tS2Vs bHkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNjaW0gaXNzdWUgdHJhY2tl ciBbbWFpbHRvOnRyYWMrc2NpbUB0b29scy5pZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgTm92 ZW1iZXIgMDgsIDIwMTIgNTowMyBQTQ0KVG86IGRyYWZ0LWlldGYtc2NpbS1jb3JlLXNjaGVtYUB0 b29scy5pZXRmLm9yZzsgbWVsaW5kYS5zaG9yZUBnbWFpbC5jb207IEtlbGx5IEdyaXp6bGUNCkNj OiBzY2ltQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NjaW1dICM1OiBDb25zaWRlciBzdXBwb3J0 aW5nIGF0dHJpYnV0ZSBvdGhlciB0aGFuICJpZCIgZm9yIHRoZSAibWVtYmVycyIgYXR0cmlidXRl IGluIEdyb3VwIFNjaGVtYQ0KDQojNTogQ29uc2lkZXIgc3VwcG9ydGluZyBhdHRyaWJ1dGUgb3Ro ZXIgdGhhbiAiaWQiIGZvciB0aGUgIm1lbWJlcnMiIGF0dHJpYnV0ZSBpbiBHcm91cCBTY2hlbWEN Cg0KDQpDb21tZW50IChieSBrZWxseS5ncml6emxlQOKApik6DQoNCiBJIHNlZW0gdG8gcmVtZW1i ZXIgdGhhdCBtb3N0IG9mIHRoZSBTQ0lNIDEueCB0ZWFtIHdhcyBvcHBvc2VkIHRvIHRoaXMgIHNp bmNlIHRoZSBpZCBpcyB0aGUgb25seSBndWFyYW50ZWVkIHVuaXF1ZSBpZGVudGlmaWVyLiAgSSdt IC0xIGFuZCB3b3VsZCAgc3VnZ2VzdCB0aGF0IHdlIGNsb3NlIHRoaXMgYXMgd29udGZpeC4NCg0K LS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tDQog UmVwb3J0ZXI6ICBtZWxpbmRhLnNob3JlQOKApiAgfCAgICAgICBPd25lcjogIGRyYWZ0LWlldGYt c2NpbS1jb3JlLXNjaGVtYUDigKYNCiAgICAgVHlwZTogIGVuaGFuY2VtZW50ICAgICAgfCAgICAg IFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICB8ICAgTWlsZXN0b25l Og0KQ29tcG9uZW50OiAgY29yZS1zY2hlbWEgICAgICB8ICAgICBWZXJzaW9uOg0KIFNldmVyaXR5 OiAgLSAgICAgICAgICAgICAgICB8ICBSZXNvbHV0aW9uOg0KIEtleXdvcmRzOiAgICAgICAgICAg ICAgICAgICB8DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tDQoNClRpY2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9zY2ltL3Ry YWMvdGlja2V0LzUjY29tbWVudDoyPg0Kc2NpbSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3NjaW0v Pg0KDQoNCg== From hasini@wso2.com Mon Nov 12 08:21:11 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B679621F8660 for ; Mon, 12 Nov 2012 08:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZdhuNHgSpBL for ; Mon, 12 Nov 2012 08:21:11 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0C721F8635 for ; Mon, 12 Nov 2012 08:21:10 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so7108951vbb.31 for ; Mon, 12 Nov 2012 08:21:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=fVMzsxdS4kQMkh2zuoEeZTr0xTn7E/ttGRp2Qoj69Q4=; b=nB9vT6MJR9TDgEpDZiAK8DuvpbyAVPTE2l+nYyQMGb4NLRXW9fG37QGbY3+BUlfXmy Z/+DMAFJUzrHtWUWzSJmU8wF6iEw5pqvOej+P6nvuOEre9y2aLEMCweZUV1AZsv7vpiI prqfudhQKNi/H+WVw+KHjBu031ip/hLjNW9HStc6L/M6BtE6qOzt/43JZElwYZVkmlSq /Zim9zLY/lLTB2f4aD9pMf4xcHtpVBUTI7jvIG8korj0SA0XsaarBZr4cmkQoxamQQZ7 3TA1V220rlPa4UGzCIMdMy38Vge9rN7O2OFs3nE7FXjG3CoB/wXeCHtJoIy2hBz+f7zG UR1w== MIME-Version: 1.0 Received: by 10.220.225.132 with SMTP id is4mr625582vcb.47.1352737269623; Mon, 12 Nov 2012 08:21:09 -0800 (PST) Received: by 10.220.207.208 with HTTP; Mon, 12 Nov 2012 08:21:09 -0800 (PST) In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34373E8301FD@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <56C3C758F9D6534CA3778EAA1E0C34373E8301FD@BY2PRD0410MB354.namprd04.prod.outlook.com> Date: Mon, 12 Nov 2012 21:51:09 +0530 Message-ID: From: Hasini Gunasinghe To: Kelly Grizzle Content-Type: multipart/alternative; boundary=14dae9ccd52c6e2c8804ce4eb0fc X-Gm-Message-State: ALoCoQmRcjyApVayalFz3r14nTAHm5EBQK0uy+wVIYW9MMOW06R5xXxr++eeSBS5C4rUsRkjiCuD Cc: "scim@ietf.org" Subject: Re: [scim] Proposal to close ticket #5 as "won't fix" X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 16:21:11 -0000 --14dae9ccd52c6e2c8804ce4eb0fc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In the implementation point of view, If the consumer is not storing the user to server-side id mapping, whenever a group is created or updated wrt its members, consumer has to first query the user resource through filter operation using a unique attribute that consumer maintains related to users, obtain the server-generated id, create the request including that id and send the create/update request to group end point. If the group includes multiple users, multiple calls need to be made to obtain the sever-generated ids of the relevant user resources. On the other hand, it might not be practical to maintain resource to server-generated id mapping at the consumer side since one consumer can be provisioning to multiple providers. What I suggest is: if the consumer specifies an attribute name (eg: username) [not necessarily a unique attribute according to the schema] and the value to reference the user who is a member of a group being manipulated, the server should honor that. And the consumer must make sure to use an attribute which it maintains as unique over all the user resources. If the uniqueness is not maintained on the attribute used by the consumer to reference the user, then server can throw an error and reject the request. Thanks, Hasini. On Mon, Nov 12, 2012 at 8:04 PM, Kelly Grizzle wrote: > Ticket #5 in the issue tracker suggests allowing an attribute other than > the User id to be used for references in the members attribute of the Gro= up > schema. The reasoning for this proposal was that it would allow clients = to > process group membership without having to map a server-generated id to t= he > client's unique identifier. However, the externalId is neither required = to > be present or guaranteed to be unique (see issue 79 in the google issue > tracker - http://code.google.com/p/scim/issues/detail?id=3D79). I am > proposing to close this ticket as "won't fix" since there is not a reliab= le > way to reference a user without using the id. > > Please respond with any comments. > > --Kelly > > -----Original Message----- > From: scim issue tracker [mailto:trac+scim@tools.ietf.org] > Sent: Thursday, November 08, 2012 5:03 PM > To: draft-ietf-scim-core-schema@tools.ietf.org; melinda.shore@gmail.com; > Kelly Grizzle > Cc: scim@ietf.org > Subject: Re: [scim] #5: Consider supporting attribute other than "id" for > the "members" attribute in Group Schema > > #5: Consider supporting attribute other than "id" for the "members" > attribute in Group Schema > > > Comment (by kelly.grizzle@=85): > > I seem to remember that most of the SCIM 1.x team was opposed to this > since the id is the only guaranteed unique identifier. I'm -1 and would > suggest that we close this as wontfix. > > -- > -----------------------------+------------------------------------------ > -----------------------------+-- > Reporter: melinda.shore@=85 | Owner: draft-ietf-scim-core-schem= a@=85 > Type: enhancement | Status: new > Priority: major | Milestone: > Component: core-schema | Version: > Severity: - | Resolution: > Keywords: | > -----------------------------+------------------------------------------ > -----------------------------+-- > > Ticket URL: > scim > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > --14dae9ccd52c6e2c8804ce4eb0fc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In the implementation point of view,=A0
If the consumer is not storing = the user to server-side id mapping, whenever a group is created or updated = wrt its members, consumer has to first query the user resource through filt= er operation using a unique attribute that consumer maintains related to us= ers, obtain the server-generated id, create the request including that id a= nd send the create/update request to group end point.

If the group includes multiple users, multiple calls ne= ed to be made to obtain the sever-generated ids of the relevant user resour= ces.

On the other hand, it might not be practical = to maintain resource to server-generated id mapping at the consumer side si= nce one consumer can be provisioning to multiple providers.

What I suggest is: if the consumer specifies an attribu= te name (eg: username) [not necessarily a unique attribute according to the= schema] and the value to reference the user who is a member of a group bei= ng manipulated, the server should honor that. And the consumer must make su= re to use an attribute which it maintains as unique over all the user resou= rces.
If the uniqueness is not maintained on the attribute used by the consu= mer to reference the user, then server can throw an error and reject the re= quest.

Thanks,
Hasini.

On Mon, Nov 12, 2012 at 8:04 PM, Kelly Grizz= le <kelly.grizzle@sailpoint.com> wrote:
Ticket #5 in the issue tracker suggests allowing an attribute other than th= e User id to be used for references in the members attribute of the Group s= chema. =A0The reasoning for this proposal was that it would allow clients t= o process group membership without having to map a server-generated id to t= he client's unique identifier. =A0However, the externalId is neither re= quired to be present or guaranteed to be unique (see issue 79 in the google= issue tracker - http://code.google.com/p/scim/issues/detail?id=3D7= 9). =A0I am proposing to close this ticket as "won't fix"= since there is not a reliable way to reference a user without using the id= .

Please respond with any comments.

--Kelly

-----Original Message-----
From: scim issue tracker [mailto:trac+scim@tools.ietf.org]
Sent: Thursday, November 08, 2012 5:03 PM
To: draft-iet= f-scim-core-schema@tools.ietf.org; melinda.shore@gmail.com; Kelly Grizzle
Cc: scim@ietf.org
Subject: Re: [scim] #5: Consider supporting attribute other than "id&q= uot; for the "members" attribute in Group Schema

#5: Consider supporting attribute other than "id" for the "m= embers" attribute in Group Schema


Comment (by kelly.grizzle@=85):

=A0I seem to remember that most of the SCIM 1.x team was opposed to this = =A0since the id is the only guaranteed unique identifier. =A0I'm -1 and= would =A0suggest that we close this as wontfix.

--
-----------------------------+------------------------------------------ -----------------------------+--
=A0Reporter: =A0melinda.shore@=85 =A0| =A0 =A0 =A0 Owner: =A0draft-ietf-sci= m-core-schema@=85
=A0 =A0 =A0Type: =A0enhancement =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone:
Component: =A0core-schema =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0Resolution:
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-----------------------------+------------------------------------------ -----------------------------+--

Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac/ticke= t/5#comment:2>
scim <http://t= ools.ietf.org/scim/>


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

--14dae9ccd52c6e2c8804ce4eb0fc-- From phil.hunt@oracle.com Mon Nov 12 08:48:42 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C7021F8674 for ; Mon, 12 Nov 2012 08:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.106 X-Spam-Level: X-Spam-Status: No, score=-3.106 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub0LsY2wkjt7 for ; Mon, 12 Nov 2012 08:48:41 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 219C721F847C for ; Mon, 12 Nov 2012 08:48:41 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qACGmdtV018023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Nov 2012 16:48:40 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qACGmcew026018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 16:48:39 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qACGmcJY014029; Mon, 12 Nov 2012 10:48:38 -0600 Received: from [192.168.1.131] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Nov 2012 08:48:38 -0800 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_DCCE83D2-E183-4A12-8202-97AED042BE7D" From: Phil Hunt In-Reply-To: Date: Mon, 12 Nov 2012 08:48:57 -0800 Message-Id: <918656E0-C84C-415D-8824-70EBED206543@oracle.com> References: <56C3C758F9D6534CA3778EAA1E0C34373E8301FD@BY2PRD0410MB354.namprd04.prod.outlook.com> To: Hasini Gunasinghe X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "scim@ietf.org" , Kelly Grizzle Subject: Re: [scim] Proposal to close ticket #5 as "won't fix" X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 16:48:42 -0000 --Apple-Mail=_DCCE83D2-E183-4A12-8202-97AED042BE7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Kelly, If I understand correctly, the problem is how/when to convert from = client group representation to SP SCIM representation.=20 I'd like to explore this a bit... 1. [CURRENT DRAFT] Client converts to Id in advance: Pro: The client must convert their local identifier to the SP = identifier (objectid). Con: The SP will undergo a lot more query traffic converting = externalid, uid, mail, etc to object 'id'. This is not an issue if = client stores previously provisioned object Id values. Con: It takes an extra network operation per non-objectid member. 2. [PROPOSED] SP auto-converts unique object key attributes (externalId, = uid, mail, etc): Pro: the client can present group updates using any unique key = attribute using its own group representation. Pro: update is completed in a single network operation. Neutral: Instead of incurring many lookups, the SP converts unique keys = into object identifiers. Con: This could lead to a long-running operation for a large group in = order to indicate success since chance of failure is increased. Con: The client could NOT compare the group values after reading the = group back--> member values would be converted to object 'id' values. 3. [PROSPOSAL 2] SP allows for any unique id to be used as a member = value with no conversion I want to exclude this, I think this leads to much complexity and = referential integrity issues and suggests membership may not be = validated. Pro: SP represents group the same way client represents it making = comparison possible Con: at some point, SP has to normalize the data. Con: when is group validated Con: unique key attributes are not as stable as object 'id' attributes As an example many LDAP clients will have DN's as members. If the client = previously provisioned Users and set externalId to their local LDAP DN, = then updating groups could conceivably become easier. I don't think there is a great answer here. For current implementers, = any experience on this issue? Has option 1 been a problem? =46rom an error handling perspective, I like the current draft the best. = It forces the client to ensure the group is valid before updating the = SP. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-11-12, at 8:21 AM, Hasini Gunasinghe wrote: > In the implementation point of view,=20 > If the consumer is not storing the user to server-side id mapping, = whenever a group is created or updated wrt its members, consumer has to = first query the user resource through filter operation using a unique = attribute that consumer maintains related to users, obtain the = server-generated id, create the request including that id and send the = create/update request to group end point. >=20 > If the group includes multiple users, multiple calls need to be made = to obtain the sever-generated ids of the relevant user resources. >=20 > On the other hand, it might not be practical to maintain resource to = server-generated id mapping at the consumer side since one consumer can = be provisioning to multiple providers. >=20 > What I suggest is: if the consumer specifies an attribute name (eg: = username) [not necessarily a unique attribute according to the schema] = and the value to reference the user who is a member of a group being = manipulated, the server should honor that. And the consumer must make = sure to use an attribute which it maintains as unique over all the user = resources. > If the uniqueness is not maintained on the attribute used by the = consumer to reference the user, then server can throw an error and = reject the request. >=20 > Thanks, > Hasini. >=20 > On Mon, Nov 12, 2012 at 8:04 PM, Kelly Grizzle = wrote: > Ticket #5 in the issue tracker suggests allowing an attribute other = than the User id to be used for references in the members attribute of = the Group schema. The reasoning for this proposal was that it would = allow clients to process group membership without having to map a = server-generated id to the client's unique identifier. However, the = externalId is neither required to be present or guaranteed to be unique = (see issue 79 in the google issue tracker - = http://code.google.com/p/scim/issues/detail?id=3D79). I am proposing to = close this ticket as "won't fix" since there is not a reliable way to = reference a user without using the id. >=20 > Please respond with any comments. >=20 > --Kelly >=20 > -----Original Message----- > From: scim issue tracker [mailto:trac+scim@tools.ietf.org] > Sent: Thursday, November 08, 2012 5:03 PM > To: draft-ietf-scim-core-schema@tools.ietf.org; = melinda.shore@gmail.com; Kelly Grizzle > Cc: scim@ietf.org > Subject: Re: [scim] #5: Consider supporting attribute other than "id" = for the "members" attribute in Group Schema >=20 > #5: Consider supporting attribute other than "id" for the "members" = attribute in Group Schema >=20 >=20 > Comment (by kelly.grizzle@=85): >=20 > I seem to remember that most of the SCIM 1.x team was opposed to this = since the id is the only guaranteed unique identifier. I'm -1 and = would suggest that we close this as wontfix. >=20 > -- > = -----------------------------+------------------------------------------ > -----------------------------+-- > Reporter: melinda.shore@=85 | Owner: = draft-ietf-scim-core-schema@=85 > Type: enhancement | Status: new > Priority: major | Milestone: > Component: core-schema | Version: > Severity: - | Resolution: > Keywords: | > = -----------------------------+------------------------------------------ > -----------------------------+-- >=20 > Ticket URL: = > scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_DCCE83D2-E183-4A12-8202-97AED042BE7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
=46rom an error handling = perspective, I like the current draft the best. It forces the client to = ensure the group is valid before updating the = SP.

Phil

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





On 2012-11-12, at 8:21 AM, Hasini Gunasinghe = wrote:

In the implementation point of view, 
If the = consumer is not storing the user to server-side id mapping, whenever a = group is created or updated wrt its members, consumer has to first query = the user resource through filter operation using a unique attribute that = consumer maintains related to users, obtain the server-generated id, = create the request including that id and send the create/update request = to group end point.

If the group includes multiple users, multiple calls = need to be made to obtain the sever-generated ids of the relevant user = resources.

On the other hand, it might not be = practical to maintain resource to server-generated id mapping at the = consumer side since one consumer can be provisioning to multiple = providers.

What I suggest is: if the consumer specifies an = attribute name (eg: username) [not necessarily a unique attribute = according to the schema] and the value to reference the user who is a = member of a group being manipulated, the server should honor that. And = the consumer must make sure to use an attribute which it maintains as = unique over all the user resources.
If the uniqueness is not maintained on the attribute used by the = consumer to reference the user, then server can throw an error and = reject the = request.

Thanks,
Hasini.

On Mon, Nov 12, 2012 at 8:04 PM, Kelly = Grizzle <kelly.grizzle@sailpoint.com> = wrote:
Ticket #5 in the issue tracker suggests allowing an attribute other than = the User id to be used for references in the members attribute of the = Group schema.  The reasoning for this proposal was that it would = allow clients to process group membership without having to map a = server-generated id to the client's unique identifier.  However, = the externalId is neither required to be present or guaranteed to be = unique (see issue 79 in the google issue tracker - http://code.google.com/p/scim/issues/detail?id=3D79)= .  I am proposing to close this ticket as "won't fix" since there = is not a reliable way to reference a user without using the id.

Please respond with any comments.

--Kelly

-----Original Message-----
From: scim issue tracker [mailto:trac+scim@tools.ietf.org] Sent: Thursday, November 08, 2012 5:03 PM
To: draft-ietf-scim= -core-schema@tools.ietf.org; melinda.shore@gmail.com; = Kelly Grizzle
Cc: scim@ietf.org
Subject: Re: [scim] #5: Consider supporting attribute other than "id" = for the "members" attribute in Group Schema

#5: Consider supporting attribute other than "id" for the "members" = attribute in Group Schema


Comment (by kelly.grizzle@=85):

 I seem to remember that most of the SCIM 1.x team was opposed to = this  since the id is the only guaranteed unique identifier. =  I'm -1 and would  suggest that we close this as wontfix.

--
= -----------------------------+------------------------------------------ -----------------------------+--
 Reporter:  melinda.shore@=85  |       = Owner:  draft-ietf-scim-core-schema@=85
     Type:  enhancement      |   =    Status:  new
 Priority:  major            | =   Milestone:
Component:  core-schema      |     = Version:
 Severity:  -               =  |  Resolution:
 Keywords:                 =   |
= -----------------------------+------------------------------------------ -----------------------------+--

Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac/ticket/5#comment= :2>
scim <http://tools.ietf.org/scim/>


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

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

= --Apple-Mail=_DCCE83D2-E183-4A12-8202-97AED042BE7D-- From edreux@cloudiway.com Mon Nov 12 14:31:05 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2535721F861C for ; Mon, 12 Nov 2012 14:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPYOmOjBhSnG for ; Mon, 12 Nov 2012 14:31:04 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id DC92721F8623 for ; Mon, 12 Nov 2012 14:31:03 -0800 (PST) Received: from mail39-am1-R.bigfish.com (10.3.201.226) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 12 Nov 2012 22:31:02 +0000 Received: from mail39-am1 (localhost [127.0.0.1]) by mail39-am1-R.bigfish.com (Postfix) with ESMTP id 9CCF92C031D; Mon, 12 Nov 2012 22:31:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT001.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -70 X-BigFish: PS-70(zzbb2dI98dI9371Ic89bh1dbaI15caKJzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received-SPF: pass (mail39-am1: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT001.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail39-am1 (localhost.localdomain [127.0.0.1]) by mail39-am1 (MessageSwitch) id 1352759459799427_14905; Mon, 12 Nov 2012 22:30:59 +0000 (UTC) Received: from AM1EHSMHS019.bigfish.com (unknown [10.3.201.241]) by mail39-am1.bigfish.com (Postfix) with ESMTP id B7828E0061; Mon, 12 Nov 2012 22:30:59 +0000 (UTC) Received: from AMXPRD0610HT001.eurprd06.prod.outlook.com (157.56.248.213) by AM1EHSMHS019.bigfish.com (10.3.207.157) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 12 Nov 2012 22:30:57 +0000 Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.1.229]) by AMXPRD0610HT001.eurprd06.prod.outlook.com ([10.255.58.36]) with mapi id 14.16.0233.002; Mon, 12 Nov 2012 22:30:56 +0000 From: Emmanuel Dreux To: Leif Johansson , "scim@ietf.org" Thread-Topic: : [scim] #27: Make support for XML optional or drop it; JSON required Thread-Index: AQHNvrUIthU8s+Y1LUOJzkFEyL8SqJfmvL8A Date: Mon, 12 Nov 2012 22:30:55 +0000 Message-ID: References: <068.6f8ea83285aaea9cd481e0e5a8490f9c@tools.ietf.org> <083.1dd51238238687e2c8a67e0faf29da50@tools.ietf.org> <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> <509C1429.3010205@mnt.se> In-Reply-To: <509C1429.3010205@mnt.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.200.82.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Subject: [scim] : #27: Make support for XML optional or drop it; JSON required X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:31:05 -0000 +1 for dropping XML. I have also a strong request to use natively FOAF as "identity schema" and = exchange data on the wire in Turtle N3 format (eventually JSON-LD). I found this old article that tries to explain why :https://blogs.oracle.co= m/bblfish/entry/the_limitations_of_json We are convinced of the future of semantic web in IAM platforms ( See what = others are saying: http://labs.safelayer.com/en/research-and-development/fo= cus-areas/semantic-web/327-semantic-technologies-in-the-identity-management= -metasystem). And we are convinced of the convergence of semantic with IAM. If IAM platforms use FOAF/RDF and if SAAS platforms also use FOAF (example = facebook with open graph apis, F8 apis), it would be great if we could sta= y FOAF/RDF from end to end without having to break the chain using JSON on = the wire. Therefore I propose to add Turtle as optional format (or JSON-LD?) and prop= ose FOAF optionally as standard schema for identities. We have already this needs that we will have to implement. This is for us e= ventually a marketing issue: Will we call it SCIM or will we implement it w= ithout giving it a name :-) What do you think of making SCIM ready for the future of IAM. I'm strongly = confident that this would open the door to a lot of other opportunities tha= t we are not thinking of today. -- Cordialement / Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux -----Message d'origine----- De=A0: Leif Johansson [mailto:leifj@mnt.se]=20 Envoy=E9=A0: jeudi 8 novembre 2012 21:21 =C0=A0: scim@ietf.org Objet=A0: Re: [scim] #27: Make support for XML optional or drop it; JSON re= quired On 11/02/2012 05:55 PM, Kelly Grizzle wrote: > Please review the proposed changes to remove XML support from SCIM. Any = feedback is greatly appreciated. I have attached the full txt documents, w= hich may be easier to read than the diffs (attached to ticket #27). > There was strong consensus in the WG meeting in Atlanta for dropping XML in= favour of JSON. If anyone opposes this change, now is the time to speak up, or the chairs w= ill call consensus on this issue. Cheers Leif From prvs=06646D11F3=erik.wahlstrom@nexussafe.com Tue Nov 13 01:14:10 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC69E21F860D for ; Tue, 13 Nov 2012 01:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc2dZvhfTAz6 for ; Tue, 13 Nov 2012 01:14:05 -0800 (PST) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8689121F8646 for ; Tue, 13 Nov 2012 01:13:56 -0800 (PST) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.1.421.2; Tue, 13 Nov 2012 10:13:51 +0100 Received: from MARVMAILDB.technxs.com ([fe80::e05a:552e:6731:125f]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Tue, 13 Nov 2012 10:13:52 +0100 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] Proposal to close ticket #5 as "won't fix" Thread-Index: Ac3A4J2e7cFScCBFQXei+4RyK7xduQACLnKAAAD4jYAAImWLAA== Date: Tue, 13 Nov 2012 09:13:51 +0000 Message-ID: References: <56C3C758F9D6534CA3778EAA1E0C34373E8301FD@BY2PRD0410MB354.namprd04.prod.outlook.com> <918656E0-C84C-415D-8824-70EBED206543@oracle.com> In-Reply-To: <918656E0-C84C-415D-8824-70EBED206543@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.77] Content-Type: multipart/alternative; boundary="_000_C7EDA7AD758D4BEFB8495B98835A99BEnexussafecom_" MIME-Version: 1.0 Cc: Hasini Gunasinghe , Kelly Grizzle , "scim@ietf.org" Subject: Re: [scim] Proposal to close ticket #5 as "won't fix" X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 09:14:10 -0000 --_000_C7EDA7AD758D4BEFB8495B98835A99BEnexussafecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I prefer the current draft version. The ID looses it's unique identifier st= atus rather quickly if we start accepting other unique identifiers a part f= rom the original unique identifier. I also like the simplicity of always requiring the ID. There are no special= cases that clients and servers must support. I prefer more server roundtri= ps over increased complexity and if server roundtrips is a problem for a cl= ient, the client can always persists the mapping. So, all in all, +1 on "wont fix". / Erik On Nov 12, 2012, at 5:48 PM, Phil Hunt wrote: Kelly, If I understand correctly, the problem is how/when to convert from client g= roup representation to SP SCIM representation. I'd like to explore this a bit... 1. [CURRENT DRAFT] Client converts to Id in advance: Pro: The client must convert their local identifier to the SP identifier = (objectid). Con: The SP will undergo a lot more query traffic converting externalid, = uid, mail, etc to object 'id'. This is not an issue if client stores previ= ously provisioned object Id values. Con: It takes an extra network operation per non-objectid member. 2. [PROPOSED] SP auto-converts unique object key attributes (externalId, ui= d, mail, etc): Pro: the client can present group updates using any unique key attribute = using its own group representation. Pro: update is completed in a single network operation. Neutral: Instead of incurring many lookups, the SP converts unique keys int= o object identifiers. Con: This could lead to a long-running operation for a large group in ord= er to indicate success since chance of failure is increased. Con: The client could NOT compare the group values after reading the grou= p back--> member values would be converted to object 'id' values. 3. [PROSPOSAL 2] SP allows for any unique id to be used as a member value w= ith no conversion I want to exclude this, I think this leads to much complexity and referenti= al integrity issues and suggests membership may not be validated. Pro: SP represents group the same way client represents it making comparis= on possible Con: at some point, SP has to normalize the data. Con: when is group validated Con: unique key attributes are not as stable as object 'id' attributes As an example many LDAP clients will have DN's as members. If the client pr= eviously provisioned Users and set externalId to their local LDAP DN, then = updating groups could conceivably become easier. I don't think there is a great answer here. For current implementers, any e= xperience on this issue? Has option 1 been a problem? >From an error handling perspective, I like the current draft the best. It f= orces the client to ensure the group is valid before updating the SP. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-11-12, at 8:21 AM, Hasini Gunasinghe wrote: In the implementation point of view, If the consumer is not storing the user to server-side id mapping, whenever= a group is created or updated wrt its members, consumer has to first query= the user resource through filter operation using a unique attribute that c= onsumer maintains related to users, obtain the server-generated id, create = the request including that id and send the create/update request to group e= nd point. If the group includes multiple users, multiple calls need to be made to obt= ain the sever-generated ids of the relevant user resources. On the other hand, it might not be practical to maintain resource to server= -generated id mapping at the consumer side since one consumer can be provis= ioning to multiple providers. What I suggest is: if the consumer specifies an attribute name (eg: usernam= e) [not necessarily a unique attribute according to the schema] and the val= ue to reference the user who is a member of a group being manipulated, the = server should honor that. And the consumer must make sure to use an attribu= te which it maintains as unique over all the user resources. If the uniqueness is not maintained on the attribute used by the consumer t= o reference the user, then server can throw an error and reject the request= . Thanks, Hasini. On Mon, Nov 12, 2012 at 8:04 PM, Kelly Grizzle > wrote: Ticket #5 in the issue tracker suggests allowing an attribute other than th= e User id to be used for references in the members attribute of the Group s= chema. The reasoning for this proposal was that it would allow clients to = process group membership without having to map a server-generated id to the= client's unique identifier. However, the externalId is neither required t= o be present or guaranteed to be unique (see issue 79 in the google issue t= racker - http://code.google.com/p/scim/issues/detail?id=3D79). I am propos= ing to close this ticket as "won't fix" since there is not a reliable way t= o reference a user without using the id. Please respond with any comments. --Kelly -----Original Message----- From: scim issue tracker [mailto:trac+scim@tools.ietf.org] Sent: Thursday, November 08, 2012 5:03 PM To: draft-ietf-scim-core-schema@tools.ietf.org; melinda.shore@gmail.com; Kelly Grizzle Cc: scim@ietf.org Subject: Re: [scim] #5: Consider supporting attribute other than "id" for t= he "members" attribute in Group Schema #5: Consider supporting attribute other than "id" for the "members" attribu= te in Group Schema Comment (by kelly.grizzle@=85): I seem to remember that most of the SCIM 1.x team was opposed to this sin= ce the id is the only guaranteed unique identifier. I'm -1 and would sugg= est that we close this as wontfix. -- -----------------------------+------------------------------------------ -----------------------------+-- Reporter: melinda.shore@=85 | Owner: draft-ietf-scim-core-schema@= =85 Type: enhancement | Status: new Priority: major | Milestone: Component: core-schema | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------------------------------ -----------------------------+-- Ticket URL: scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_C7EDA7AD758D4BEFB8495B98835A99BEnexussafecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <521B81FE421AF34B9C57D29CF62CB17B@nexussafe.com> Content-Transfer-Encoding: quoted-printable
Hi,

I prefer the current draft version. The ID looses it's unique identifi= er status rather quickly if we start accepting other unique identifiers a p= art from the original unique identifier.

I also like the simplicity of always requiring the ID. There are no sp= ecial cases that clients and servers must support. I prefer more serve= r roundtrips over increased complexity and if server roundtrips is a proble= m for a client, the client can always persists the mapping.

So, all in all, +1 on "wont fix".

/ Erik


On Nov 12, 2012, at 5:48 PM, Phil Hunt wrote:

Kelly,

If I understand correctly, the problem is how/when to convert from cli= ent group representation to SP SCIM representation. 

I'd like to explore this a bit...

1.  [CURRENT DRAFT] Client converts to Id in advance:
  Pro: The client must convert their local identifier to the SP i= dentifier (objectid).
  Con: The SP will undergo a lot more query traffic converting ex= ternalid, uid, mail, etc to object 'id'.  This is not an issue if clie= nt stores previously provisioned object Id values.
  Con: It takes an extra network operation per non-objectid membe= r.

2. [PROPOSED] SP auto-converts unique object key attributes (externalI= d, uid, mail, etc):
  Pro: the client can present group updates using any unique key = attribute using its own group representation.
  Pro: update is completed in a single network operation.
Neutral: Instead of incurring many lookups, the SP converts unique key= s into object identifiers.
  Con: This could lead to a long-running operation for a large gr= oup in order to indicate success since chance of failure is increased.
  Con: The client could NOT compare the group values after readin= g the group back--> member values would be converted to object 'id' valu= es.

3. [PROSPOSAL 2] SP allows for any unique id to be used as a member va= lue with no conversion
I want to exclude this, I think this leads to much complexity and refe= rential integrity issues and suggests membership may not be validated.
 Pro: SP represents group the same way client represents it makin= g comparison possible
 Con: at some point, SP has to normalize the data.
 Con: when is group validated
 Con: unique key attributes are not as stable as object 'id' attr= ibutes

As an example many LDAP clients will have DN's as members. If the clie= nt previously provisioned Users and set externalId to their local LDAP DN, = then updating groups could conceivably become easier.

I don't think there is a great answer here. For current implementers, = any experience on this issue? Has option 1 been a problem?

From an error handling perspective, I like the current draft the best.= It forces the client to ensure the group is valid before updating the SP.<= /div>


On 2012-11-12, at 8:21 AM, Hasini Gunasinghe wrote:

In the implementation point of view, 
If the consumer is not storing the user to server-side id mapping, whe= never a group is created or updated wrt its members, consumer has to first = query the user resource through filter operation using a unique attribute t= hat consumer maintains related to users, obtain the server-generated id, create the request including that i= d and send the create/update request to group end point.

If the group includes multiple users, multiple calls need to be made t= o obtain the sever-generated ids of the relevant user resources.

On the other hand, it might not be practical to maintain resource to s= erver-generated id mapping at the consumer side since one consumer can be p= rovisioning to multiple providers.

What I suggest is: if the consumer specifies an attribute name (eg: us= ername) [not necessarily a unique attribute according to the schema] and th= e value to reference the user who is a member of a group being manipulated,= the server should honor that. And the consumer must make sure to use an attribute which it maintains as uniq= ue over all the user resources.
If the uniqueness is not maintained on the attribute used by the consu= mer to reference the user, then server can throw an error and reject the re= quest.

Thanks,
Hasini.

On Mon, Nov 12, 2012 at 8:04 PM, Kelly Grizzle <= span dir=3D"ltr"> <kelly.= grizzle@sailpoint.com> wrote:
Ticket #5 in the issue tracker suggests allowing an attribute other than th= e User id to be used for references in the members attribute of the Group s= chema.  The reasoning for this proposal was that it would allow client= s to process group membership without having to map a server-generated id to the client's unique identifier. &nb= sp;However, the externalId is neither required to be present or guaranteed = to be unique (see issue 79 in the google issue tracker - http://code.google.com/p/scim/issues/detail?id=3D79).  I am= proposing to close this ticket as "won't fix" since there is not= a reliable way to reference a user without using the id.

Please respond with any comments.

--Kelly

-----Original Message-----
From: scim issue tracker [mailto:trac+scim@tools.ietf.org]
Sent: Thursday, November 08, 2012 5:03 PM
To: draft-iet= f-scim-core-schema@tools.ietf.org; melinda.shore@gmail.com; Kel= ly Grizzle
Cc: scim@ietf.org
Subject: Re: [scim] #5: Consider supporting attribute other than "id&q= uot; for the "members" attribute in Group Schema

#5: Consider supporting attribute other than "id" for the "m= embers" attribute in Group Schema


Comment (by kelly.grizzle@=85):

 I seem to remember that most of the SCIM 1.x team was opposed to this=  since the id is the only guaranteed unique identifier.  I'm -1 = and would  suggest that we close this as wontfix.

--
-----------------------------+-----------------------------------------= -
-----------------------------+--
 Reporter:  melinda.shore@=85  |       Owner:=  draft-ietf-scim-core-schema@=85
     Type:  enhancement      |   &n= bsp;  Status:  new
 Priority:  major            | &nbs= p; Milestone:
Component:  core-schema      |     Version:  Severity:  -               &n= bsp;|  Resolution:
 Keywords:                 &nb= sp; |
-----------------------------+-----------------------------------------= -
-----------------------------+--

Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac/ticke= t/5#comment:2>
scim <http://t= ools.ietf.org/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_C7EDA7AD758D4BEFB8495B98835A99BEnexussafecom_-- From leifj@mnt.se Tue Nov 13 02:06:00 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DC221F861D for ; Tue, 13 Nov 2012 02:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhVEWXHRMQ08 for ; Tue, 13 Nov 2012 02:05:59 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CAE1B21F861B for ; Tue, 13 Nov 2012 02:05:58 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1770020lah.31 for ; Tue, 13 Nov 2012 02:05:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=/fBQRcqX2SArAGeH5vLr7nZU5fRINM/rfOINxwdPgu4=; b=NBCQwMLtMwy4QP+t7D4GtXnpcln8xLybMhsLm+lR4G++ea4IWAKHeG7LYbQlwKOtas 9e2ittyja6osExOt4cpwRi8L8xJD6dalabIEnUMdEDS70tEyvwWX7rvP2C7Ub74uVWJd 8+auWV24Hbi7Y5si+nfEKno4RhcycpsO1ZiYa06KLX8ZAzSvqkKx5IarV+rOVd+0Ki9q TFs+IFf/vR2ddkGuRhN8HrGnZWbMAetxCJ5rDmOIP2RElXWotL005Hy+0lvhbGTBgXXD LD7NVfiT6jwHV1q4DTt3Uq8vTQvzAX/sZMrOmvs8O68QrJVuBpvWKM/pHHymCeW8U0SY OYNw== Received: by 10.152.114.65 with SMTP id je1mr15011503lab.33.1352801155825; Tue, 13 Nov 2012 02:05:55 -0800 (PST) Received: from ?IPv6:2001:6b0:7:0:1c4c:3030:e8c9:dada? ([2001:6b0:7:0:1c4c:3030:e8c9:dada]) by mx.google.com with ESMTPS id ew2sm3525743lbb.2.2012.11.13.02.05.53 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 02:05:54 -0800 (PST) Message-ID: <50A21B7E.6030608@mnt.se> Date: Tue, 13 Nov 2012 11:05:50 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: scim@ietf.org References: <068.6f8ea83285aaea9cd481e0e5a8490f9c@tools.ietf.org> <083.1dd51238238687e2c8a67e0faf29da50@tools.ietf.org> <56C3C758F9D6534CA3778EAA1E0C34373E7F2E20@BY2PRD0410MB354.namprd04.prod.outlook.com> <509C1429.3010205@mnt.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl8MLAFSqguvJWxisu22PXn6/+Is7f5bVh6bYKwa1JhE9JtMiXGS6Ly2Bd5VqKsP5hcq7Oy Subject: Re: [scim] : #27: Make support for XML optional or drop it; JSON required X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 10:06:00 -0000 On 11/12/2012 11:30 PM, Emmanuel Dreux wrote: > +1 for dropping XML. > I'm calling consensus on this. Kelly & Melinda - go ahead and close this issue. From hasini@wso2.com Tue Nov 13 23:43:15 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7144D21F87AC for ; Tue, 13 Nov 2012 23:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2AiKAdB4v6d for ; Tue, 13 Nov 2012 23:43:14 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC2CC21F8798 for ; Tue, 13 Nov 2012 23:43:13 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so156831vcb.31 for ; Tue, 13 Nov 2012 23:43:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ZJ9Nkg/2dqEqK/GNL5IAoPvjiNT/6IRRXaTxgm/fnPc=; b=hWAod6mkQolUZAZiWSOF5zGisrvLYLP1lURk6LSP6GbiWu5oIzAnM5xs6MdCyu34aK 4xM15fyPJi1m6A1jVRACMyM5qDh2l4sUnHCb/xkJE2Mj+oKvQH40Llu6Z/TkaPF/MY8n iUiyiFdN6IA8foTlPAq5hKsvLT2qkJLJyhVTaGMopw+z46E36vgPJsddLs2UTy1jgQwG Bg+Y9QzRtqry1wM6BA6WtOOKK2pnYRnjy4RLhDWgyY/8axMgvucARNcRWz2MKetQUpvS 9YXl2MSR+YqDiKUW1Q0SHksNuqU3TPmCvlZFf5idI3xEqEGXYkBU/U8G0g0zffBG57/1 D0fg== MIME-Version: 1.0 Received: by 10.58.15.227 with SMTP id a3mr31194112ved.38.1352878992905; Tue, 13 Nov 2012 23:43:12 -0800 (PST) Received: by 10.220.207.208 with HTTP; Tue, 13 Nov 2012 23:43:12 -0800 (PST) In-Reply-To: References: <56C3C758F9D6534CA3778EAA1E0C34373E8301FD@BY2PRD0410MB354.namprd04.prod.outlook.com> <918656E0-C84C-415D-8824-70EBED206543@oracle.com> Date: Wed, 14 Nov 2012 13:13:12 +0530 Message-ID: From: Hasini Gunasinghe To: =?ISO-8859-1?Q?Erik_Wahlstr=F6m?= Content-Type: multipart/alternative; boundary=047d7b5daf50cbd7b204ce6faff8 X-Gm-Message-State: ALoCoQnLgWqfE4gzz7wCaTL3SNxhU4LA/LP9XBOnxRhUpiAhxmiwM3FMAzihVnnN38kszh/RJ5/R Cc: "scim@ietf.org" , Kelly Grizzle , Phil Hunt Subject: Re: [scim] Proposal to close ticket #5 as "won't fix" X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 07:43:15 -0000 --047d7b5daf50cbd7b204ce6faff8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 2:43 PM, Erik Wahlstr=F6m < erik.wahlstrom@nexussafe.com> wrote: > Hi, > > I prefer the current draft version. The ID looses it's unique identifier > status rather quickly if we start accepting other unique identifiers a pa= rt > from the original unique identifier. > > I also like the simplicity of always requiring the ID. There are no > special cases that clients and servers must support. I prefer more server > roundtrips over increased complexity > Yes, if more server round trips are preferred over the complexity in accommodating the requirement raised in ticket #5, we can stick to the current draft with regard to this. So +1 for resolving as 'won't fix'. Thanks, Hasini. > and if server roundtrips is a problem for a client, the client can always > persists the mapping. > > So, all in all, +1 on "wont fix". > > / Erik > > > On Nov 12, 2012, at 5:48 PM, Phil Hunt wrote: > > Kelly, > > If I understand correctly, the problem is how/when to convert from > client group representation to SP SCIM representation. > > I'd like to explore this a bit... > > 1. [CURRENT DRAFT] Client converts to Id in advance: > Pro: The client must convert their local identifier to the SP identifie= r > (objectid). > Con: The SP will undergo a lot more query traffic converting externalid= , > uid, mail, etc to object 'id'. This is not an issue if client stores > previously provisioned object Id values. > Con: It takes an extra network operation per non-objectid member. > > 2. [PROPOSED] SP auto-converts unique object key attributes (externalId, > uid, mail, etc): > Pro: the client can present group updates using any unique key attribut= e > using its own group representation. > Pro: update is completed in a single network operation. > Neutral: Instead of incurring many lookups, the SP converts unique keys > into object identifiers. > Con: This could lead to a long-running operation for a large group in > order to indicate success since chance of failure is increased. > Con: The client could NOT compare the group values after reading the > group back--> member values would be converted to object 'id' values. > > 3. [PROSPOSAL 2] SP allows for any unique id to be used as a member > value with no conversion > I want to exclude this, I think this leads to much complexity and > referential integrity issues and suggests membership may not be validated= . > Pro: SP represents group the same way client represents it making > comparison possible > Con: at some point, SP has to normalize the data. > Con: when is group validated > Con: unique key attributes are not as stable as object 'id' attributes > > As an example many LDAP clients will have DN's as members. If the client > previously provisioned Users and set externalId to their local LDAP DN, > then updating groups could conceivably become easier. > > I don't think there is a great answer here. For current implementers, > any experience on this issue? Has option 1 been a problem? > > From an error handling perspective, I like the current draft the best. > It forces the client to ensure the group is valid before updating the SP. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-11-12, at 8:21 AM, Hasini Gunasinghe wrote: > > In the implementation point of view, > If the consumer is not storing the user to server-side id mapping, > whenever a group is created or updated wrt its members, consumer has to > first query the user resource through filter operation using a unique > attribute that consumer maintains related to users, obtain the > server-generated id, create the request including that id and send the > create/update request to group end point. > > If the group includes multiple users, multiple calls need to be made to > obtain the sever-generated ids of the relevant user resources. > > On the other hand, it might not be practical to maintain resource to > server-generated id mapping at the consumer side since one consumer can b= e > provisioning to multiple providers. > > What I suggest is: if the consumer specifies an attribute name (eg: > username) [not necessarily a unique attribute according to the schema] an= d > the value to reference the user who is a member of a group being > manipulated, the server should honor that. And the consumer must make sur= e > to use an attribute which it maintains as unique over all the user > resources. > If the uniqueness is not maintained on the attribute used by the consumer > to reference the user, then server can throw an error and reject the > request. > > Thanks, > Hasini. > > On Mon, Nov 12, 2012 at 8:04 PM, Kelly Grizzle < > kelly.grizzle@sailpoint.com> wrote: > >> Ticket #5 in the issue tracker suggests allowing an attribute other than >> the User id to be used for references in the members attribute of the Gr= oup >> schema. The reasoning for this proposal was that it would allow clients= to >> process group membership without having to map a server-generated id to = the >> client's unique identifier. However, the externalId is neither required= to >> be present or guaranteed to be unique (see issue 79 in the google issue >> tracker - http://code.google.com/p/scim/issues/detail?id=3D79). I am >> proposing to close this ticket as "won't fix" since there is not a relia= ble >> way to reference a user without using the id. >> >> Please respond with any comments. >> >> --Kelly >> >> -----Original Message----- >> From: scim issue tracker [mailto:trac+scim@tools.ietf.org] >> Sent: Thursday, November 08, 2012 5:03 PM >> To: draft-ietf-scim-core-schema@tools.ietf.org; melinda.shore@gmail.com; >> Kelly Grizzle >> Cc: scim@ietf.org >> Subject: Re: [scim] #5: Consider supporting attribute other than "id" fo= r >> the "members" attribute in Group Schema >> >> #5: Consider supporting attribute other than "id" for the "members" >> attribute in Group Schema >> >> >> Comment (by kelly.grizzle@=85): >> >> I seem to remember that most of the SCIM 1.x team was opposed to this >> since the id is the only guaranteed unique identifier. I'm -1 and woul= d >> suggest that we close this as wontfix. >> >> -- >> -----------------------------+------------------------------------------ >> -----------------------------+-- >> Reporter: melinda.shore@=85 | Owner: draft-ietf-scim-core-sche= ma@ >> =85 >> Type: enhancement | Status: new >> Priority: major | Milestone: >> Component: core-schema | Version: >> Severity: - | Resolution: >> Keywords: | >> -----------------------------+------------------------------------------ >> -----------------------------+-- >> >> Ticket URL: >> scim >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > --047d7b5daf50cbd7b204ce6faff8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Tue, Nov 13, 2012 at 2:43 PM, Erik Wa= hlstr=F6m <erik.wahlstrom@nexussafe.com> wrote:
Hi,

I prefer the current draft version. The ID looses it's unique iden= tifier status rather quickly if we start accepting other unique identifiers= a part from the original unique identifier.

I also like the simplicity of always requiring the ID. There are no sp= ecial cases that clients and servers must support.=A0I prefer more server r= oundtrips over increased complexity

Yes, if more server round trips are preferred over the complexity in= =A0accommodating=A0the requirement raised in ticket #5, we can stick to the= current draft with regard to this.
So +1 for resolving as 'w= on't fix'.

Thanks,
Hasini.
and if server roundtrips is= a problem for a client, the client can always persists the mapping.

So, all in all, +1 on "wont fix".

/ Erik


On Nov 12, 2012, at 5:48 PM, Phil Hunt wrote:

Kelly,

If I understand correctly, the problem is how/when to convert from cli= ent group representation to SP SCIM representation.=A0

I'd like to explore this a bit...

1. =A0[CURRENT DRAFT] Client converts to Id in advance:
=A0 Pro: The client must convert their local identifier to the SP iden= tifier (objectid).
=A0 Con: The SP will undergo a lot more query traffic converting exter= nalid, uid, mail, etc to object 'id'. =A0This is not an issue if cl= ient stores previously provisioned object Id values.
=A0 Con: It takes an extra network operation per non-objectid member.<= /div>

2. [PROPOSED] SP auto-converts unique object key attributes (externalI= d, uid, mail, etc):
=A0 Pro: the client can present group updates using any unique key att= ribute using its own group representation.
=A0 Pro: update is completed in a single network operation.
Neutral: Instead of incurring many lookups, the SP converts unique key= s into object identifiers.
=A0 Con: This could lead to a long-running operation for a large group= in order to indicate success since chance of failure is increased.
=A0 Con: The client could NOT compare the group values after reading t= he group back--> member values would be converted to object 'id'= values.

3. [PROSPOSAL 2] SP allows for any unique id to be used as a member va= lue with no conversion
I want to exclude this, I think this leads to much complexity and refe= rential integrity issues and suggests membership may not be validated.
=A0Pro: SP represents group the same way client represents it making c= omparison possible
=A0Con: at some point, SP has to normalize the data.
=A0Con: when is group validated
=A0Con: unique key attributes are not as stable as object 'id'= attributes

As an example many LDAP clients will have DN's as members. If the = client previously provisioned Users and set externalId to their local LDAP = DN, then updating groups could conceivably become easier.

I don't think there is a great answer here. For current implemente= rs, any experience on this issue? Has option 1 been a problem?

From an error handling perspective, I like the current draft the best.= It forces the client to ensure the group is valid before updating the SP.<= /div>


On 2012-11-12, at 8:21 AM, Hasini Gunasinghe wrote:

In the implementation point of view,=A0
If the consumer is not storing the user to server-side id mapping, whe= never a group is created or updated wrt its members, consumer has to first = query the user resource through filter operation using a unique attribute t= hat consumer maintains related to users, obtain the server-generated id, create the request including that i= d and send the create/update request to group end point.

If the group includes multiple users, multiple calls need to be made t= o obtain the sever-generated ids of the relevant user resources.

On the other hand, it might not be practical to maintain resource to s= erver-generated id mapping at the consumer side since one consumer can be p= rovisioning to multiple providers.

What I suggest is: if the consumer specifies an attribute name (eg: us= ername) [not necessarily a unique attribute according to the schema] and th= e value to reference the user who is a member of a group being manipulated,= the server should honor that. And the consumer must make sure to use an attribute which it maintains as uniq= ue over all the user resources.
If the uniqueness is not maintained on the attribute used by the consu= mer to reference the user, then server can throw an error and reject the re= quest.

Thanks,
Hasini.

On Mon, Nov 12, 2012 at 8:04 PM, Kelly Grizzle <= span dir=3D"ltr"> <kelly.= grizzle@sailpoint.com> wrote:
Ticket #5 in the issue tracker suggests allowing an attribute other than th= e User id to be used for references in the members attribute of the Group s= chema. =A0The reasoning for this proposal was that it would allow clients t= o process group membership without having to map a server-generated id to the client's unique identifier.= =A0However, the externalId is neither required to be present or guaranteed= to be unique (see issue 79 in the google issue tracker - http://code.google.com/p/scim/issues/detail?id=3D79). =A0I am pr= oposing to close this ticket as "won't fix" since there is no= t a reliable way to reference a user without using the id.

Please respond with any comments.

--Kelly

-----Original Message-----
From: scim issue tracker [mailto:trac+scim@tools.ietf.org]
Sent: Thursday, November 08, 2012 5:03 PM
To: draft-ietf-scim-core-schema@tools.ietf.org; melinda.shore@= gmail.com; Kelly Grizzle
Cc: scim@ietf.org Subject: Re: [scim] #5: Consider supporting attribute other than "id&q= uot; for the "members" attribute in Group Schema

#5: Consider supporting attribute other than "id" for the "m= embers" attribute in Group Schema


Comment (by kelly.grizzle@=85):

=A0I seem to remember that most of the SCIM 1.x team was opposed to this = =A0since the id is the only guaranteed unique identifier. =A0I'm -1 and= would =A0suggest that we close this as wontfix.

--
-----------------------------+------------------------------------------ -----------------------------+--
=A0Reporter: =A0melinda.shore@=85 =A0| =A0 =A0 =A0 Owner: =A0draft-ietf-sci= m-core-schema@=85
=A0 =A0 =A0Type: =A0enhancement =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone:
Component: =A0core-schema =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0Resolution:
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-----------------------------+------------------------------------------ -----------------------------+--

Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac/ticke= t/5#comment:2>
scim <http://t= ools.ietf.org/scim/>


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

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

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


--047d7b5daf50cbd7b204ce6faff8-- From leifj@mnt.se Wed Nov 14 01:08:53 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45B821F859A for ; Wed, 14 Nov 2012 01:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIb3g7dwWTFa for ; Wed, 14 Nov 2012 01:08:53 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 010DC21F857C for ; Wed, 14 Nov 2012 01:08:51 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so226841lbk.31 for ; Wed, 14 Nov 2012 01:08:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=HabP+F27hCvJaD55DsPk86l6tjuCNs9cSultUH03P7I=; b=Oi46esXdYHioCFXoMZ1E1nmfxdv5x9g9FF5oQAy6ZyrBmzxyX6StVpYJVW6e6Y9tKP xxtvtMJr4Jeqylm4LU3K+kuBOjfjTrrHxn8P7BT4iJXpSQefwe/2Cw1QLHROpgHDbIUp 8U5qz85O0icUwjIk5KjTLnQ4WtfHncRmZdcX7F9XASb8fnvNKKDmSTV39aONFo9lthok JlT5CZchvsTFBkpdbdoica+YrDMg4PePZm3GdZ5hM+8+GGRkeUte4XlVQ+MDJuBjacXn 5iyKk8MHRMdF4fpxj/S27dQhHBdcZ5xbV3qsJXOJfjNKw6H8hYH4bX2NxwEbdN51y5FW 01Pg== Received: by 10.112.25.161 with SMTP id d1mr10441414lbg.118.1352884128920; Wed, 14 Nov 2012 01:08:48 -0800 (PST) Received: from ?IPv6:2001:6b0:7:0:1c4c:3030:e8c9:dada? ([2001:6b0:7:0:1c4c:3030:e8c9:dada]) by mx.google.com with ESMTPS id hu6sm4702381lab.13.2012.11.14.01.08.46 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 01:08:47 -0800 (PST) Message-ID: <50A35F9D.90006@mnt.se> Date: Wed, 14 Nov 2012 10:08:45 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: scim WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmXjd0pp7g5+IWAMNCZINF3m/c9Ei7NAZEZJsi8zwNvHHOfab1YrH4IfQPxck3GrRypiIaZ Subject: [scim] all hands on deck X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:08:53 -0000 Folks, Right now Kelly and Melinda is doing most of the heavy lifting looking at issues. We need more people actively working on analysing and proposing solutions to issues! Leif From hasini@wso2.com Wed Nov 14 06:33:47 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C1E21F860C for ; Wed, 14 Nov 2012 06:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQVa2HDt04Mv for ; Wed, 14 Nov 2012 06:33:47 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4AE321F860B for ; Wed, 14 Nov 2012 06:33:46 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so565775vcb.31 for ; Wed, 14 Nov 2012 06:33:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=hzgyBpXm7fPuiVaujz1cyz6OABhPhWD/ovUrQrKu44M=; b=hV/mAntiKcBKvX5hKByDZw7IuH7KH1fbFPkIEUp/pS4mrTpAvUmHI2lG+7v/RaxkLD AbTBgkRKX5VtvMFVZ+FXbQQ5DKZyL058fA7M4Ol/+cNrR+El0u/wMuaZk9hhATkFHq+X nBoti+TV0eGdeKlISTx1LMWiCHXcr3DhpIg3nF/f8AvdzFnRhuyc+QP/0pXXIE/HNT+j zKAaVx7Kd02bOGIKgx4a472C2MzqKL+JO783wc0ONfBJQ0l9ET/cuc/i/v5L2rsP7xJW AmUMagYHt6eyR9WHNSTwGFsc4WIJEyWM+8uufIfrW+gYUCCvaKtKCIYIXJEx7EsvWxsg 3xJQ== MIME-Version: 1.0 Received: by 10.220.225.132 with SMTP id is4mr11150143vcb.47.1352903625928; Wed, 14 Nov 2012 06:33:45 -0800 (PST) Received: by 10.220.207.208 with HTTP; Wed, 14 Nov 2012 06:33:45 -0800 (PST) Date: Wed, 14 Nov 2012 20:03:45 +0530 Message-ID: From: Hasini Gunasinghe To: scim@ietf.org Content-Type: multipart/alternative; boundary=14dae9ccd52c09f1d004ce756c71 X-Gm-Message-State: ALoCoQmGGWwV6vOtqTFfVfF+2S8/1oo+gUEZrc76/uTNuHfxhZsirM3uh0nZBygOumDnoxP5fEag Subject: [scim] #28: Clarify the spec on multi-tenancy X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 14:33:47 -0000 --14dae9ccd52c09f1d004ce756c71 Content-Type: text/plain; charset=ISO-8859-1 Hi all, As the description of ticket #28suggests, we will mention that the spec doesn't address multi-tenancy, but will provide some pointers/guidance/recommendation. I would like to start the discussion on what are the things we intend to mention and to which extent wrt pointers/guidance/recommendation that would go under the topic 'multi-tenancy'. To start with, IMO, things to be considered are basically: - Identifying the tenant pertaining to a particular SCIM request. (If a common endpoint is exposed for all tenants, identification can be done at the authentication of the SCIM request by requiring the initiator of the request to provide the fully qualified name) - Identifying the user-storage space of the particular tenant to which the SCIM request belongs, and performing the SCIM operation in that space. - Allowing to register the details of tenant-specific SCIM Service Providers at the consumer side, if the SCIM consumer is multi-tenanted. Any other aspects that we can consider? or anything from above that we do not need to consider? And to which extent we intend to specify them in the spec? Appreciate feedback and I would like to take the WG ideas into consideration and compose the text that goes under the topic multitenancy. Thanks, Hasini. --14dae9ccd52c09f1d004ce756c71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

As the description of ticket #28= suggests, we will mention that the spec doesn't address multi-tena= ncy, but will provide some pointers/guidance/recommendation.

I would like to start the discussion on what are the th= ings we intend to mention and to which extent wrt=A0pointers/guidance/recom= mendation that would go under the topic 'multi-tenancy'.

To start with, IMO, things to be considered are basically:

- Identifying the tenant pertaining to a particular SCI= M request.
(If a common endpoint is exposed for all tenants, iden= tification can be done at the authentication of the SCIM request by requiri= ng the initiator of the request to provide the fully qualified name)

- Identifying the user-storage space of the particular = tenant to which the SCIM request belongs, and performing the SCIM operation= in that space.

- Allowing to register the details= of tenant-specific SCIM Service Providers at the consumer side, if the SCI= M consumer is multi-tenanted.

Any other aspects that we can consider? or anything fro= m above that we do not need to consider?
And to which extent we i= ntend to specify them in the spec?

Appreciate feed= back and I would like to take the WG ideas into consideration and compose t= he text that goes under the topic multitenancy.

Thanks,
Hasini.
--14dae9ccd52c09f1d004ce756c71-- From kelly.grizzle@sailpoint.com Thu Nov 15 06:01:54 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4419821F8502 for ; Thu, 15 Nov 2012 06:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVv1xkPJ7mgd for ; Thu, 15 Nov 2012 06:01:49 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 26FB821F84E6 for ; Thu, 15 Nov 2012 06:01:47 -0800 (PST) Received: from mail201-co1-R.bigfish.com (10.243.78.246) by CO1EHSOBE011.bigfish.com (10.243.66.74) with Microsoft SMTP Server id 14.1.225.23; Thu, 15 Nov 2012 14:01:47 +0000 Received: from mail201-co1 (localhost [127.0.0.1]) by mail201-co1-R.bigfish.com (Postfix) with ESMTP id 0F8AAA801B0; Thu, 15 Nov 2012 14:01:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT001.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zz98dI9371Ic89bhd6eah936eI542Mc85dh4015Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh18602ehz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h15d0l1155h) Received-SPF: pass (mail201-co1: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT001.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail201-co1 (localhost.localdomain [127.0.0.1]) by mail201-co1 (MessageSwitch) id 1352988103755590_26224; Thu, 15 Nov 2012 14:01:43 +0000 (UTC) Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.238]) by mail201-co1.bigfish.com (Postfix) with ESMTP id AB53844005E; Thu, 15 Nov 2012 14:01:43 +0000 (UTC) Received: from BY2PRD0410HT001.namprd04.prod.outlook.com (157.56.236.85) by CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 15 Nov 2012 14:01:42 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.12.218]) by BY2PRD0410HT001.namprd04.prod.outlook.com ([10.255.83.36]) with mapi id 14.16.0233.002; Thu, 15 Nov 2012 14:01:41 +0000 From: Kelly Grizzle To: Hasini Gunasinghe , =?iso-8859-1?Q?Erik_Wahlstr=F6m?= Thread-Topic: [scim] Proposal to close ticket #5 as "won't fix" Thread-Index: Ac3A4J2e7cFScCBFQXei+4RyK7xduQAERuOAAAD4jYAAImWygAAvICEAAD97tTA= Date: Thu, 15 Nov 2012 14:01:40 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34373EF1A42E@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <56C3C758F9D6534CA3778EAA1E0C34373E8301FD@BY2PRD0410MB354.namprd04.prod.outlook.com> <918656E0-C84C-415D-8824-70EBED206543@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 32EA184C0036A632EA1999 x-originating-ip: [72.182.10.254] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C34373EF1A42EBY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" , Phil Hunt Subject: Re: [scim] Proposal to close ticket #5 as "won't fix" X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 14:01:54 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C34373EF1A42EBY2PRD0410MB354_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, Hasini. It feels like we have consensus on this one. If anyone di= sagrees, please speak now. --Kelly From: Hasini Gunasinghe [mailto:hasini@wso2.com] Sent: Wednesday, November 14, 2012 1:43 AM To: Erik Wahlstr=F6m Cc: Phil Hunt; scim@ietf.org; Kelly Grizzle Subject: Re: [scim] Proposal to close ticket #5 as "won't fix" On Tue, Nov 13, 2012 at 2:43 PM, Erik Wahlstr=F6m > wrote: Hi, I prefer the current draft version. The ID looses it's unique identifier st= atus rather quickly if we start accepting other unique identifiers a part f= rom the original unique identifier. I also like the simplicity of always requiring the ID. There are no special= cases that clients and servers must support. I prefer more server roundtri= ps over increased complexity Yes, if more server round trips are preferred over the complexity in accomm= odating the requirement raised in ticket #5, we can stick to the current dr= aft with regard to this. So +1 for resolving as 'won't fix'. Thanks, Hasini. and if server roundtrips is a problem for a client, the client can always p= ersists the mapping. So, all in all, +1 on "wont fix". / Erik On Nov 12, 2012, at 5:48 PM, Phil Hunt wrote: Kelly, If I understand correctly, the problem is how/when to convert from client g= roup representation to SP SCIM representation. I'd like to explore this a bit... 1. [CURRENT DRAFT] Client converts to Id in advance: Pro: The client must convert their local identifier to the SP identifier = (objectid). Con: The SP will undergo a lot more query traffic converting externalid, = uid, mail, etc to object 'id'. This is not an issue if client stores previ= ously provisioned object Id values. Con: It takes an extra network operation per non-objectid member. 2. [PROPOSED] SP auto-converts unique object key attributes (externalId, ui= d, mail, etc): Pro: the client can present group updates using any unique key attribute = using its own group representation. Pro: update is completed in a single network operation. Neutral: Instead of incurring many lookups, the SP converts unique keys int= o object identifiers. Con: This could lead to a long-running operation for a large group in ord= er to indicate success since chance of failure is increased. Con: The client could NOT compare the group values after reading the grou= p back--> member values would be converted to object 'id' values. 3. [PROSPOSAL 2] SP allows for any unique id to be used as a member value w= ith no conversion I want to exclude this, I think this leads to much complexity and referenti= al integrity issues and suggests membership may not be validated. Pro: SP represents group the same way client represents it making comparis= on possible Con: at some point, SP has to normalize the data. Con: when is group validated Con: unique key attributes are not as stable as object 'id' attributes As an example many LDAP clients will have DN's as members. If the client pr= eviously provisioned Users and set externalId to their local LDAP DN, then = updating groups could conceivably become easier. I don't think there is a great answer here. For current implementers, any e= xperience on this issue? Has option 1 been a problem? >From an error handling perspective, I like the current draft the best. It f= orces the client to ensure the group is valid before updating the SP. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-11-12, at 8:21 AM, Hasini Gunasinghe wrote: In the implementation point of view, If the consumer is not storing the user to server-side id mapping, whenever= a group is created or updated wrt its members, consumer has to first query= the user resource through filter operation using a unique attribute that c= onsumer maintains related to users, obtain the server-generated id, create = the request including that id and send the create/update request to group e= nd point. If the group includes multiple users, multiple calls need to be made to obt= ain the sever-generated ids of the relevant user resources. On the other hand, it might not be practical to maintain resource to server= -generated id mapping at the consumer side since one consumer can be provis= ioning to multiple providers. What I suggest is: if the consumer specifies an attribute name (eg: usernam= e) [not necessarily a unique attribute according to the schema] and the val= ue to reference the user who is a member of a group being manipulated, the = server should honor that. And the consumer must make sure to use an attribu= te which it maintains as unique over all the user resources. If the uniqueness is not maintained on the attribute used by the consumer t= o reference the user, then server can throw an error and reject the request= . Thanks, Hasini. On Mon, Nov 12, 2012 at 8:04 PM, Kelly Grizzle > wrote: Ticket #5 in the issue tracker suggests allowing an attribute other than th= e User id to be used for references in the members attribute of the Group s= chema. The reasoning for this proposal was that it would allow clients to = process group membership without having to map a server-generated id to the= client's unique identifier. However, the externalId is neither required t= o be present or guaranteed to be unique (see issue 79 in the google issue t= racker - http://code.google.com/p/scim/issues/detail?id=3D79). I am propos= ing to close this ticket as "won't fix" since there is not a reliable way t= o reference a user without using the id. Please respond with any comments. --Kelly -----Original Message----- From: scim issue tracker [mailto:trac+scim@tools.ietf.org] Sent: Thursday, November 08, 2012 5:03 PM To: draft-ietf-scim-core-schema@tools.ietf.org; melinda.shore@gmail.com; Kelly Grizzle Cc: scim@ietf.org Subject: Re: [scim] #5: Consider supporting attribute other than "id" for t= he "members" attribute in Group Schema #5: Consider supporting attribute other than "id" for the "members" attribu= te in Group Schema Comment (by kelly.grizzle@...): I seem to remember that most of the SCIM 1.x team was opposed to this sin= ce the id is the only guaranteed unique identifier. I'm -1 and would sugg= est that we close this as wontfix. -- -----------------------------+------------------------------------------ -----------------------------+-- Reporter: melinda.shore@... | Owner: draft-ietf-scim-core-schema@= ... Type: enhancement | Status: new Priority: major | Milestone: Component: core-schema | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------------------------------ -----------------------------+-- Ticket URL: scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_56C3C758F9D6534CA3778EAA1E0C34373EF1A42EBY2PRD0410MB354_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks, Hasini.  It = feels like we have consensus on this one.  If anyone disagrees, please= speak now.

 <= /p>

--Kelly=

 <= /p>

From: Hasini G= unasinghe [mailto:hasini@wso2.com]
Sent: Wednesday, November 14, 2012 1:43 AM
To: Erik Wahlstr=F6m
Cc: Phil Hunt; scim@ietf.org; Kelly Grizzle
Subject: Re: [scim] Proposal to close ticket #5 as "won't fix&q= uot;

 

 

On Tue, Nov 13, 2012 at 2:43 PM, Erik Wahlstr=F6m &l= t;erik.wa= hlstrom@nexussafe.com> wrote:

Hi,

 

I prefer the current draft version. The ID looses it= 's unique identifier status rather quickly if we start accepting other uniq= ue identifiers a part from the original unique identifier.

 

I also like the simplicity of always requiring the I= D. There are no special cases that clients and servers must support. I= prefer more server roundtrips over increased complexity

 

Yes, if more server round trips are preferred over t= he complexity in accommodating the requirement raised in ticket #= 5, we can stick to the current draft with regard to this.

So +1 for resolving as 'won't fix'.

 

Thanks,

Hasini.

and if server roundtrips is a problem for a client, = the client can always persists the mapping.

 

So, all in all, +1 on "wont fix".=

 

/ Erik

 

 

On Nov 12, 2012, at 5:48 PM, Phil Hunt wrote:



Kelly,

 

If I understand correctly, the problem is how/when t= o convert from client group representation to SP SCIM representation. =

 

I'd like to explore this a bit...

 

1.  [CURRENT DRAFT] Client converts to Id in ad= vance:

  Pro: The client must convert their local iden= tifier to the SP identifier (objectid).

  Con: The SP will undergo a lot more query tra= ffic converting externalid, uid, mail, etc to object 'id'.  This is no= t an issue if client stores previously provisioned object Id values.

  Con: It takes an extra network operation per = non-objectid member.

 

2. [PROPOSED] SP auto-converts unique object key att= ributes (externalId, uid, mail, etc):

  Pro: the client can present group updates usi= ng any unique key attribute using its own group representation.<= /p>

  Pro: update is completed in a single network = operation.

Neutral: Instead of incurring many lookups, the SP c= onverts unique keys into object identifiers.

  Con: This could lead to a long-running operat= ion for a large group in order to indicate success since chance of failure = is increased.

  Con: The client could NOT compare the group v= alues after reading the group back--> member values would be converted t= o object 'id' values.

 

3. [PROSPOSAL 2] SP allows for any unique id to be u= sed as a member value with no conversion

I want to exclude this, I think this leads to much c= omplexity and referential integrity issues and suggests membership may not = be validated.

 Pro: SP represents group the same way client r= epresents it making comparison possible

 Con: at some point, SP has to normalize the da= ta.

 Con: when is group validated

 Con: unique key attributes are not as stable a= s object 'id' attributes

 

As an example many LDAP clients will have DN's as me= mbers. If the client previously provisioned Users and set externalId to the= ir local LDAP DN, then updating groups could conceivably become easier.

 

I don't think there is a great answer here. For curr= ent implementers, any experience on this issue? Has option 1 been a problem= ?

 

From an error handling perspective, I like the curre= nt draft the best. It forces the client to ensure the group is valid before= updating the SP.

 

 

On 2012-11-12, at 8:21 AM, Hasini Gunasinghe wrote:<= o:p>



In the implementation point of view, 

If the consumer is not storing the user to server-si= de id mapping, whenever a group is created or updated wrt its members, cons= umer has to first query the user resource through filter operation using a = unique attribute that consumer maintains related to users, obtain the server-generated id, create the request inclu= ding that id and send the create/update request to group end point.

 

If the group includes multiple users, multiple calls= need to be made to obtain the sever-generated ids of the relevant user res= ources.

 

On the other hand, it might not be practical to main= tain resource to server-generated id mapping at the consumer side since one= consumer can be provisioning to multiple providers.

 

What I suggest is: if the consumer specifies an attr= ibute name (eg: username) [not necessarily a unique attribute according to = the schema] and the value to reference the user who is a member of a group = being manipulated, the server should honor that. And the consumer must make sure to use an attribute which it m= aintains as unique over all the user resources.

If the uniqueness is not maintained on the attribute= used by the consumer to reference the user, then server can throw an error= and reject the request.

 

Thanks,

Hasini.

 

On Mon, Nov 12, 2012 at 8:04 PM, Kelly Grizzle <<= a href=3D"mailto:kelly.grizzle@sailpoint.com" target=3D"_blank">kelly.grizz= le@sailpoint.com> wrote:

Ticket #5 in the issue tracker suggests allowing an = attribute other than the User id to be used for references in the members a= ttribute of the Group schema.  The reasoning for this proposal was tha= t it would allow clients to process group membership without having to map a server-generated id to the client's uni= que identifier.  However, the externalId is neither required to be pre= sent or guaranteed to be unique (see issue 79 in the google issue tracker - http://code.google.com/p/scim/issues/detail?id=3D79).  I am= proposing to close this ticket as "won't fix" since there is not= a reliable way to reference a user without using the id.

Please respond with any comments.

--Kelly

-----Original Message-----
From: scim issue tracker [mailto:trac+scim@tools.ietf.org]
Sent: Thursday, November 08, 2012 5:03 PM
To: draft-ietf-scim-core-schema@tools.ietf.org; melinda.shore@= gmail.com; Kelly Grizzle
Cc: scim@ietf.org Subject: Re: [scim] #5: Consider supporting attribute other than "id&q= uot; for the "members" attribute in Group Schema

#5: Consider supporting attribute other than "id" for the "m= embers" attribute in Group Schema


Comment (by kelly.grizzle@…):

 I seem to remember that most of the SCIM 1.x team was opposed to this=  since the id is the only guaranteed unique identifier.  I'm -1 = and would  suggest that we close this as wontfix.

--
-----------------------------+-----------------------------------------= -
-----------------------------+--
 Reporter:  melinda.shore@…  |       Ow= ner:  draft-ietf-scim-core-schema@…
     Type:  enhancement      |   &n= bsp;  Status:  new
 Priority:  major            | &nbs= p; Milestone:
Component:  core-schema      |     Version:  Severity:  -               &n= bsp;|  Resolution:
 Keywords:                 &nb= sp; |
-----------------------------+-----------------------------------------= -
-----------------------------+--

Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac/ticke= t/5#comment:2>
scim <http://t= ools.ietf.org/scim/>


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

 

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

 

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

 

 

--_000_56C3C758F9D6534CA3778EAA1E0C34373EF1A42EBY2PRD0410MB354_-- From leifj@mnt.se Thu Nov 15 11:49:02 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3299B21F858F for ; Thu, 15 Nov 2012 11:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nXK9fyT0TMi for ; Thu, 15 Nov 2012 11:49:01 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58EFD21F8522 for ; Thu, 15 Nov 2012 11:49:00 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1642181lah.31 for ; Thu, 15 Nov 2012 11:48:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:x-gm-message-state; bh=HUD7OsooYdJCjYZsAwpBqPyNYzKBR5poLLuATp10Imk=; b=AySdXwEdqoHHeyA6pr0aTkFz6nClEpdGBvamkXz6XwGPTLZM/XYuT9KkQO7jE+6xYj dJhBPWsgb6MXLfwR9jC5QIi4lfM+FLFQiXx6eaYzWAeFj654Bw/lZ2PZEjaZctfipHdS f57CZ6Nut1Y2vLfQdbAXIaKXDrjwVKHa3R8LSEVsOTIfg0wqAXulCg8324X9pvfyeN8s CUHkWCCUGLtdUmBai9FLN920vbFOdkeX6ajDz5LwaQjx4IQd5gOVegEahnQWQUB3liw8 kXvaA1RUXrMcNrpYkoC1favqf0/YyjzcfCpaqoZ2K+hsCkEwoYDNYWuvCgI0yORgGADQ 3tMw== Received: by 10.152.110.42 with SMTP id hx10mr2174004lab.0.1353008935771; Thu, 15 Nov 2012 11:48:55 -0800 (PST) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPS id d5sm2213578lbk.10.2012.11.15.11.48.53 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 11:48:54 -0800 (PST) Message-ID: <50A54724.60406@mnt.se> Date: Thu, 15 Nov 2012 20:48:52 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: scim@ietf.org References: <56C3C758F9D6534CA3778EAA1E0C34373E8301FD@BY2PRD0410MB354.namprd04.prod.outlook.com> <918656E0-C84C-415D-8824-70EBED206543@oracle.com> <56C3C758F9D6534CA3778EAA1E0C34373EF1A42E@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34373EF1A42E@BY2PRD0410MB354.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------000907040403010808040701" X-Gm-Message-State: ALoCoQmqTG6PfZgbo9xFTX0lAq9fMz6qMq7yUWCwuEoHJsvwdMSC8hFtpQ+BQIAJFx6HCtrqfF2N Subject: Re: [scim] Proposal to close ticket #5 as "won't fix" X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:49:02 -0000 This is a multi-part message in MIME format. --------------000907040403010808040701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/15/2012 03:01 PM, Kelly Grizzle wrote: > > Thanks, Hasini. It feels like we have consensus on this one. If > anyone disagrees, please speak now. > > OK. Nobody speaks up. I'm calling this consensus. --------------000907040403010808040701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/15/2012 03:01 PM, Kelly Grizzle wrote:

Thanks, Hasini.  It feels like we have consensus on this one.  If anyone disagrees, please speak now.


OK. Nobody speaks up. I'm calling this consensus.
--------------000907040403010808040701-- From soohongp@gmail.com Fri Nov 16 20:00:09 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E90921F8E3A; Fri, 16 Nov 2012 20:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.804 X-Spam-Level: * X-Spam-Status: No, score=1.804 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1, TVD_SPACE_RATIO=2.219, URIBL_PH_SURBL=1.787] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l8bJ44irYPE; Fri, 16 Nov 2012 20:00:08 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B95C421F8D7A; Fri, 16 Nov 2012 20:00:04 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1576491bku.31 for ; Fri, 16 Nov 2012 20:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yOUVkb/OHyQj/dTAA0mSxL/GwYKJSyF5YuQ5j6dvWaw=; b=zz2hhsBwvo/H0FHd9xt9TDf1Sjzcw02pl+mMdWROBBjmz9loxwQEmllFIkVvWgOXf/ /Pklfqotqjqx1d2TX+MUmJU0z2Un08YivsqIfCN00N95YSaH3F57qUeRAQij9e0LPUnu 0iqkjvSIjUUGGjJuQPUrDBc06tqqfQV+DJWbhJFW+RtnlDulYdT1qOCl0IXRwXms6YtK eYvFuko/EJYchg//NhCZZ55/jAx6piufuAXjDj1lJehYIa3KUxwuSfLC7dRRYhOQUgo8 S2fOAYQknx3Oc0FU5dtN12bK67yVKyv9Edtcdy+Xxo9qb6DSs5LLWesXpLt220wGY4T+ OoFg== MIME-Version: 1.0 Received: by 10.205.137.7 with SMTP id im7mr2728090bkc.25.1353124803678; Fri, 16 Nov 2012 20:00:03 -0800 (PST) Received: by 10.204.60.81 with HTTP; Fri, 16 Nov 2012 20:00:03 -0800 (PST) Date: Sat, 17 Nov 2012 13:00:03 +0900 Message-ID: From: Daniel Park To: scim@ietf.org, sungyoon9@yahoo.com, kim.geunhyung@gmail.com, marco.viviani@insa-lyon.fr, fun-request@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [scim] (no subject) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 04:00:09 -0000 http://australianrenewableenergy.com.au/wp-content/plugins/akismet/google235.html From soohongp@gmail.com Sat Nov 17 04:01:25 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A48621F850E; Sat, 17 Nov 2012 04:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[AWL=1.751, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgcsJhtkA8yg; Sat, 17 Nov 2012 04:01:25 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7441321F850B; Sat, 17 Nov 2012 04:01:24 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1644289bku.31 for ; Sat, 17 Nov 2012 04:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=D1KA08zfs5sMZoLnHMx26I9Zik9uppY02rK7Gp+ZH+s=; b=XJEkpZqTNlAHa/di/KNGO8ufyvxwZAtfbI8tk/9LFCMsXLoS7enrnYhz+UlF8u4NUX YxX3bB9hPjqZCmzvh2Zh+RmuX8yPrQUXBvLllzpKDxvPz93pz52tAPhdgDjQwqh3YTHY H0x6Zc/jA5xErakjEMB9jgOvZsFNtylmkf3n9EAEAVojCVsQnWD64i9kf4BtsymYrf/c G8q0BwdrpLQzXS4vI6PHBOV1tVdvloQOdIJR+AYWQQ8eBGdHgQM+DsJDRj+vSNFKisQI M3V5/BqEa3XmtyD0+zMELHG+n+Wa+0ivHxXDv8YgFv7t+U5eqbEQBHkOMGuAiwS24rFP Y4Fg== MIME-Version: 1.0 Received: by 10.204.4.133 with SMTP id 5mr3137717bkr.21.1353153683521; Sat, 17 Nov 2012 04:01:23 -0800 (PST) Received: by 10.204.60.81 with HTTP; Sat, 17 Nov 2012 04:01:23 -0800 (PST) Received: by 10.204.60.81 with HTTP; Sat, 17 Nov 2012 04:01:23 -0800 (PST) Date: Sat, 17 Nov 2012 21:01:23 +0900 Message-ID: From: Daniel Park To: kim.geunhyung@gmail.com, marco.viviani@insa-lyon.fr, sungyoon9@yahoo.com, fun-request@ietf.org, scim@ietf.org Content-Type: multipart/alternative; boundary=0015175884c4a2023a04ceafa49e Subject: Re: [scim] span for the previous email. apology... X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 12:01:25 -0000 --0015175884c4a2023a04ceafa49e Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Folks. I do not really know why this mail was sent to this address using my gmail account without my click. By the way apology to bother you all. Sigh... Regards. Daniel. Soohong Daniel Park from my Galaxy Note 2012. 11. 17. =BF=C0=C8=C4 1:00=BF=A1 "Daniel Park" =B4= =D4=C0=CC =C0=DB=BC=BA: --0015175884c4a2023a04ceafa49e Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable

Folks.
I do not really know why this mail was sent to this address using my gmail = account without my click.

By the way apology to bother you all.
Sigh...

Regards. Daniel.

Soohong Daniel Park from my Galaxy Note

2012. 11. 17. =BF=C0=C8=C4 1:00=BF=A1 "Dani= el Park" <soohongp@gmail.com<= /a>>=B4=D4=C0=CC =C0=DB=BC=BA:
--0015175884c4a2023a04ceafa49e-- From bjorn.aannestad@unboundid.com Mon Nov 19 12:07:09 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA27121F8616 for ; Mon, 19 Nov 2012 12:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Azspy5szn5U1 for ; Mon, 19 Nov 2012 12:07:09 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E456921F8708 for ; Mon, 19 Nov 2012 12:07:08 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so5647115oag.31 for ; Mon, 19 Nov 2012 12:07:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=wi8Xyh3SqHD4sXuVssdawxJd0p5a40FTRdaDSGqxLyQ=; b=hkhoOPlnluww8U6R3Y0S98z1na71nul9lw/VfTAZ8dStmmpx++OOBlr0yLm352gJFR fA/2fkJbmI/p/hCrsEJI+sUh0zQo/22eKtyZGxnhoblLrHTEh2hM6nRZNcXRIDqVm3iN RlmrcY4LDKIpfL2CEhzYbzt275cAHnT9nuQMn3cisivfmYY55ZrzbClHpysyh9fwrqOg IdTDyCvXRI63OqwDb26VcfXmcA+uuRbRaFalYQXD8akr05r9sxySG4dq0YOc3YcS+9bF bb8oAinIsHeaIGrFvOxghGncr+H276z5eSea2+TNycg0kQj0Fkdcpmrxg1wJ2NLGMsN5 Ma/g== Received: by 10.182.192.74 with SMTP id he10mr11487419obc.87.1353355627362; Mon, 19 Nov 2012 12:07:07 -0800 (PST) Received: from [10.8.1.249] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id m8sm8477772oeb.3.2012.11.19.12.07.05 (version=SSLv3 cipher=OTHER); Mon, 19 Nov 2012 12:07:06 -0800 (PST) Message-ID: <50AA9168.2040706@unboundid.com> Date: Mon, 19 Nov 2012 14:07:04 -0600 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: scim WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080503050203020001020308" X-Gm-Message-State: ALoCoQmskfsAa9U4RdVwRE6Fjb535oP+yzpnyzo0UefsfMqh00E/vCsGu/wjhLdnHeqdnJt95cLN Subject: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 20:07:10 -0000 This is a cryptographically signed message in MIME format. --------------ms080503050203020001020308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, Based on the discussions in Atlanta and the rough consensus sampling=20 there, I'd like to propose that we close the vCard adoption question by=20 resolving to NOT adopt the vCard attribute schema, nor its JSON=20 representation. Issue #19 has my summary of the additional points that have been made=20 since the meeting. Two important notes: 1. The work to produce a vCard-SCIM mapping is, I believe, still=20 valuable and should continue. This is=20 draft-greevenbosch-scim-vcard-mapping. 2. I have created a separate issue (#30) for adopting the IANA=20 registration aspects of vCard into SCIM. This was proposed as one of=20 the important aspects of vCard to consider. Any other vCard aspects that we feel could be worth incorporating into=20 SCIM can also be made into separate issues. However, let's close the big question which is holding up the other SCIM = schema adjustments. Please respond with assent or objections, especially if you feel a=20 strong case can still be made for vCard-in-SCIM. Regards, -Bjorn --=20 __________________________________________________________ Bjorn Aannestad | Dir, Product Management | UnboundID Corp mailto:bjorn@unboundid.com | 512-769-6461 --------------ms080503050203020001020308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMUjCC BVwwggREoAMCAQICECStp7X80wzNJ6GfICadV/cwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjAyMjMwMDAwMDBaFw0xMzAyMjIyMzU5NTlaMIIBHzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRgwFgYDVQQDFA9Cam9ybiBBYW5u ZXN0YWQxLDAqBgkqhkiG9w0BCQEWHWJqb3JuLmFhbm5lc3RhZEB1bmJvdW5kaWQuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw+4r+Le4uODrErBgJsA7UoexcjH/r2Ds 62wKyDCY5CQfOFMROnynV9GWWXp8zmCj7/N9I2hOU7poaqR4kkJjoiKiNHQdVfyM1yFZTurW AV5PCT5NouiqlruJDM6s2HV3B7mSRhtHFOSfhiDP+/kHf/JEdFJ7zEPaP0Kuy8XKpPR5nVCz k4zFKPBc4T9+HAlXeGY1PnwOsxPEevZlHOTThF9RunZu5Z/uaObR2JplM6KxXDfXNRjSkmK7 6kW8wFC1C0GleHKfM85nQTvVicuSK4GbbvhMjqovMtUIR1SNG8vsmTvU4PY9G/WkDM4Ge/97 phIcQIm9W/DXjC78wBfa/QIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5Bgtg hkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh MAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkw RzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5k QzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQC345zS3026vrJVysBCE3TN BhQ4VlqRtwj5AcAXhhF2c3krlbgJRLV6STYky+/i7YRdezIZYgY2eo693dlIQUnkZMb6D2PL dRs1Lgw4NJKB+WGLGkmyV8YqqKrTm/ZbPdl/+Y4Pc88DLcYEmr0OsEDel8LqLPpongUDnGU5 2wxAvaHn9sZ4nyDa3bAy9RyqrAdWhsfRttlgAbvMeHSXhvDa63AbdGdZbzBfqGpBTYZJqrA/ fzcbVZQIw7ULW0YRpUNx8bmmgxFd5ovdDVZnfiKNd7QHy+BcTQgfxLYsBYZhICz1ud1QKn88 pW944VjwHTzxyErX43AGoPYoZKA8b3XXMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT 3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5 OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6 ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f 0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Iba k2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+ wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBn MGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNV HR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNV HQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAH BgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24u Y29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0 LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHm oYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSo WufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6 jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvi d+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5l UkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaM xmgD5yKocwuxvKDaUljdCg5/wYIxggT5MIIE9QIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhAkrae1/NMMzSeh nyAmnVf3MAkGBSsOAwIaBQCgggLbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMTExOTIwMDcwNFowIwYJKoZIhvcNAQkEMRYEFHUIOhpetsjZapUGPnkF dz238DBdMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQJK2ntfzTDM0noZ8gJp1X 9zCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCECStp7X80wzNJ6GfICadV/cwDQYJ KoZIhvcNAQEBBQAEggEAbQxfP574SclQvk4XwA4rnFYYjEq1D+ClKsmM1DJFg53anaOTHmMU sJCzQjrBttOTElXT1CjCQ9UzdgJJx3XcqIxPzsDzMZ2qgFdPisWAFzDXsk+vHBv2lDXPCNVT 5+BDsFRSIhmJMNzVKYWxx+pHFeMOPdZVKk88ADfQBZwSfrvlojV0/vyPApRGFNQbWV23B/kA SZb0REa3F4nljFpy4xsbFkYUECjSPcqje46yYCKz+GeEEA2/YmC4byDyQCjjMcGc95QXIW2v UJ3L+rpB0MpselvCNaCJeuM1KcKBZVQEB4ejlE1MjNw8P4jCNGeQxLWLk7zzn4QggYo6vu7s 6AAAAAAAAA== --------------ms080503050203020001020308-- From igor.faynberg@alcatel-lucent.com Mon Nov 19 14:14:35 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EA021F84BB for ; Mon, 19 Nov 2012 14:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.265 X-Spam-Level: X-Spam-Status: No, score=-9.265 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqhpXJJWGrOW for ; Mon, 19 Nov 2012 14:14:34 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4884E21F87CA for ; Mon, 19 Nov 2012 14:14:33 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id qAJMEW6J018391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Nov 2012 16:14:32 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id qAJMEW4f012558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Nov 2012 16:14:32 -0600 Received: from [135.244.41.206] (faynberg.lra.lucent.com [135.244.41.206]) by umail.lucent.com (8.13.8/TPES) with ESMTP id qAJMEVPk012538; Mon, 19 Nov 2012 16:14:32 -0600 (CST) Message-ID: <50AAAF47.5090007@alcatel-lucent.com> Date: Mon, 19 Nov 2012 17:14:31 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <50AA9168.2040706@unboundid.com> In-Reply-To: <50AA9168.2040706@unboundid.com> Content-Type: multipart/alternative; boundary="------------050009050004030104010007" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 22:14:35 -0000 This is a multi-part message in MIME format. --------------050009050004030104010007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 Igor On 11/19/2012 3:07 PM, Bjorn Aannestad wrote: > Hi all, > > Based on the discussions in Atlanta and the rough consensus sampling > there, I'd like to propose that we close the vCard adoption question > by resolving to NOT adopt the vCard attribute schema, nor its JSON > representation. > > Issue #19 has my summary of the additional points that have been made > since the meeting. > > Two important notes: > 1. The work to produce a vCard-SCIM mapping is, I believe, still > valuable and should continue. This is > draft-greevenbosch-scim-vcard-mapping. > 2. I have created a separate issue (#30) for adopting the IANA > registration aspects of vCard into SCIM. This was proposed as one of > the important aspects of vCard to consider. > > Any other vCard aspects that we feel could be worth incorporating into > SCIM can also be made into separate issues. > > However, let's close the big question which is holding up the other > SCIM schema adjustments. > > Please respond with assent or objections, especially if you feel a > strong case can still be made for vCard-in-SCIM. > > Regards, > -Bjorn > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------050009050004030104010007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

Igor

On 11/19/2012 3:07 PM, Bjorn Aannestad wrote:
Hi all,

Based on the discussions in Atlanta and the rough consensus sampling there, I'd like to propose that we close the vCard adoption question by resolving to NOT adopt the vCard attribute schema, nor its JSON representation.

Issue #19 has my summary of the additional points that have been made since the meeting.

Two important notes:
1. The work to produce a vCard-SCIM mapping is, I believe, still valuable and should continue.  This is draft-greevenbosch-scim-vcard-mapping.
2. I have created a separate issue (#30) for adopting the IANA registration aspects of vCard into SCIM.   This was proposed as one of the important aspects of vCard to consider.

Any other vCard aspects that we feel could be worth incorporating into SCIM can also be made into separate issues.

However, let's close the big question which is holding up the other SCIM schema adjustments.

Please respond with assent or objections, especially if you feel a strong case can still be made for vCard-in-SCIM.

Regards,
-Bjorn 


_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--------------050009050004030104010007-- From melinda.shore@gmail.com Mon Nov 19 14:31:37 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC86521F858B for ; Mon, 19 Nov 2012 14:31:37 -0800 (PST) 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=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybwbabhJEFjn for ; Mon, 19 Nov 2012 14:31:37 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 424ED21F8589 for ; Mon, 19 Nov 2012 14:31:37 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so3762499pbc.31 for ; Mon, 19 Nov 2012 14:31:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ByUIAtUfCExzdA38ZQn5Qrj2WArJUa3UDTWtRNtjbNo=; b=DTrQxfJTRjmDtGrjUfo69JCV+e17EAVKdWOB5PveHs07biyjgwVx3gtt2SNYFYCxXu TAN1VCsxy98atBfutqRwaeKU7safg+FRNNUvG+J2CQMa6VLWS21F7+xeJD+VeEBa2EX6 fD/QcgbF3kzfOm1EHicIfR0eJbnoA2J7WcHmc+kQAkzHkpW/vBVgakohEtThBMdrYQ1r 43IQd+uKf57Hog2Ih/acZTjzWDczPrwSv7p/aXAcBLSwJeDdQgRFaX/vv/SDazDfHZMH JahHJlKc+1B81pZ3NihfdsCgwJyAQPwYx9uWsUpBYQq7RgYQ49PTJ9iL9RnTKIbb18K3 VSvw== Received: by 10.68.192.66 with SMTP id he2mr36988136pbc.112.1353364297003; Mon, 19 Nov 2012 14:31:37 -0800 (PST) Received: from spandex.local (216-67-56-77-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.56.77]) by mx.google.com with ESMTPS id om10sm6848572pbc.73.2012.11.19.14.31.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Nov 2012 14:31:36 -0800 (PST) Message-ID: <50AAB346.9090500@gmail.com> Date: Mon, 19 Nov 2012 13:31:34 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <50AA9168.2040706@unboundid.com> In-Reply-To: <50AA9168.2040706@unboundid.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 22:31:37 -0000 On 11/19/12 11:07 AM, Bjorn Aannestad wrote: > However, let's close the big question which is holding up the other SCIM > schema adjustments. That seems reasonable to me, but that does open other questions with regard to the schema. I believe that using inetOrgPerson as the basis for the core SCIM schema was kicked to the curb before the working group was chartered and that should probably be documented lest some helpful participant put forth a proposal to use it. But I think it might be worth taking some care that in closing the ticket the working group isn't saying that there will never be work on mapping between vCard and SCIM, but just that the core SCIM schema will not be based on vCard. Melinda From leifj@mnt.se Mon Nov 19 14:36:10 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948DF21F88A4 for ; Mon, 19 Nov 2012 14:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMJDGK+PRUt1 for ; Mon, 19 Nov 2012 14:36:10 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4370421F8850 for ; Mon, 19 Nov 2012 14:36:08 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so4357483lah.31 for ; Mon, 19 Nov 2012 14:36:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=x5DddAtJh9azDmgHOfiCMaaNZ6esnZwjSTBpke6vvLA=; b=fkkxSXxl4qnqTQClgtWB5E4EY/zeieVLMmsqJrBAj7wXQALm0MLick/T4E14SGs1cq ETsJjJi9B9etpj2yIPM4thEMBqN1eifbRyt6VIJCz3inNgWDTjkD1QB3ew7jgFf8V2nF I4Llp7m/0hxKm98cBmJm1bu6ygzcsy0Uhm1D2Sp3aPRXvTk19zMXXmtIJwh4rjSlNh4G olIG2Ey7U+Gh7/F2SlJoFbC1WKbTby7MIlC+vTA0Ihh4OTu8Dp/eqWrZ3HnvW5uG62Zw rGyRwS+DLxgZVNO7AlY24+LLKorjs5fUhudiSRY3/MYKY9NEb27KIhXsafHTYNpkvqvM wAWw== Received: by 10.152.103.38 with SMTP id ft6mr12741281lab.40.1353364567896; Mon, 19 Nov 2012 14:36:07 -0800 (PST) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPS id l1sm4163196lbm.1.2012.11.19.14.36.05 (version=SSLv3 cipher=OTHER); Mon, 19 Nov 2012 14:36:06 -0800 (PST) Message-ID: <50AAB454.6070508@mnt.se> Date: Mon, 19 Nov 2012 23:36:04 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: scim@ietf.org References: <50AA9168.2040706@unboundid.com> In-Reply-To: <50AA9168.2040706@unboundid.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmMeDbFNSSoZCEZPs7cO5Q7699CUkvuv6o2X53OlgDTDvY49wk4C/q3V0ZRMIbdEBNVRcpk Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 22:36:11 -0000 On 11/19/2012 09:07 PM, Bjorn Aannestad wrote: > Hi all, > > Based on the discussions in Atlanta and the rough consensus sampling > there, I'd like to propose that we close the vCard adoption question > by resolving to NOT adopt the vCard attribute schema, nor its JSON > representation. > > Issue #19 has my summary of the additional points that have been made > since the meeting. > > Two important notes: > 1. The work to produce a vCard-SCIM mapping is, I believe, still > valuable and should continue. This is > draft-greevenbosch-scim-vcard-mapping. > 2. I have created a separate issue (#30) for adopting the IANA > registration aspects of vCard into SCIM. This was proposed as one of > the important aspects of vCard to consider. > > Any other vCard aspects that we feel could be worth incorporating into > SCIM can also be made into separate issues. > > However, let's close the big question which is holding up the other > SCIM schema adjustments. > > Please respond with assent or objections, especially if you feel a > strong case can still be made for vCard-in-SCIM. > I think we need to hear from some of the people who were at the mic in ATL on this issue. Cheers Leif From phil.hunt@oracle.com Mon Nov 19 15:04:52 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D136F21F8471 for ; Mon, 19 Nov 2012 15:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.039 X-Spam-Level: X-Spam-Status: No, score=-5.039 tagged_above=-999 required=5 tests=[AWL=1.560, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf9dNkm7F-+K for ; Mon, 19 Nov 2012 15:04:52 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0575221F8463 for ; Mon, 19 Nov 2012 15:04:51 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAJN4nhZ032462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Nov 2012 23:04:50 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAJN4n03027582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2012 23:04:49 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAJN4ntx025754; Mon, 19 Nov 2012 17:04:49 -0600 Received: from [192.168.1.200] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Nov 2012 15:04:49 -0800 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <50AAB346.9090500@gmail.com> Date: Mon, 19 Nov 2012 15:04:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50AA9168.2040706@unboundid.com> <50AAB346.9090500@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: scim@ietf.org Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 23:04:52 -0000 In the spirit of documentation, I think the key issue for inetorgperson = is how LDAP defines attributes. For example, LDAP has no support for = complex attributes - address information is spread across several = attributes like locality, zipcode, etc. The effect is only one address = is possible for most scenarios.=20 This is in stark contrast to poco and vcards which support multiple = typed addresses and seemed to be a founding requirement. Can someone = confirm the history here? My SCIM Directory draft goes into this issue at some length. Dual = bi-directional mapping support is a complex issue. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-11-19, at 2:31 PM, Melinda Shore wrote: > On 11/19/12 11:07 AM, Bjorn Aannestad wrote: >> However, let's close the big question which is holding up the other = SCIM >> schema adjustments. >=20 > That seems reasonable to me, but that does open other questions > with regard to the schema. I believe that using inetOrgPerson as > the basis for the core SCIM schema was kicked to the curb before > the working group was chartered and that should probably be > documented lest some helpful participant put forth a proposal > to use it. >=20 > But I think it might be worth taking some care that in closing > the ticket the working group isn't saying that there will never > be work on mapping between vCard and SCIM, but just that the > core SCIM schema will not be based on vCard. >=20 > Melinda >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From bjorn.aannestad@unboundid.com Mon Nov 19 15:55:10 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68ABF21F842A for ; Mon, 19 Nov 2012 15:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4NTkvvc8Wls for ; Mon, 19 Nov 2012 15:55:09 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9AB921F841A for ; Mon, 19 Nov 2012 15:55:09 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so5842101oag.31 for ; Mon, 19 Nov 2012 15:55:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=7tKvfBUUsFDw24vSeisT1Uh8x+KamLt61d1+PQrrPOo=; b=OnVz32EOGhK0GjgdhdC2lsreAzvL8hrLUoiLtwZ0D+eH9huta4fAJTgNKayKIZDoCC BkbmMhlQvhPo46qQ+8FgSykjjHsldPEcmIVvJb36t8TmJBkB7lzpGr3aaRBMFkOLB16l y4tJk26l/DiyJxJdRo/x9aCRvXJuw8YA7edrQgaKc7P7GDRqNTivF4YtD46UjXERZmDn sfiB7UlvpnYX+2azkX1pHBOSCZvg2VlWKsVEZZl/VqD2SvsmbqpX9LYYMMN6fvRYZ+xs ss4Q/qazm64vScT2JU89KQ6G0dn8/5qWs4W62uqKP9OchWfz4T1z3HYYnqg1HxAFLMr4 nBfA== Received: by 10.60.8.68 with SMTP id p4mr11763434oea.7.1353369309252; Mon, 19 Nov 2012 15:55:09 -0800 (PST) Received: from [10.8.1.249] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id v3sm8906965oee.0.2012.11.19.15.55.07 (version=SSLv3 cipher=OTHER); Mon, 19 Nov 2012 15:55:08 -0800 (PST) Message-ID: <50AAC6DA.8090007@unboundid.com> Date: Mon, 19 Nov 2012 17:55:06 -0600 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Melinda Shore References: <50AA9168.2040706@unboundid.com> <50AAB346.9090500@gmail.com> In-Reply-To: <50AAB346.9090500@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060405090408060504020205" X-Gm-Message-State: ALoCoQlSIk8IxdF0p5C5DM4h2dCYt88XaPAqpnxv6HBAEu0aj0qH2NTonGzD89602Y5q/bnIwBEP Cc: scim@ietf.org Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 23:55:10 -0000 This is a cryptographically signed message in MIME format. --------------ms060405090408060504020205 Content-Type: multipart/alternative; boundary="------------010408020508010206030308" This is a multi-part message in MIME format. --------------010408020508010206030308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 11/19/2012 16:31, Melinda Shore wrote: > But I think it might be worth taking some care that in closing the=20 > ticket the working group isn't saying that there will never be work on = > mapping between vCard and SCIM, but just that the core SCIM schema=20 > will not be based on vCard.=20 That's right, Melinda. The following text appear in the issue comment: "The valuable work on the SCIM-to-vCard mapping draft should continue as = a separate effort" -Bjorn --=20 __________________________________________________________ Bjorn Aannestad | Dir, Product Management | UnboundID Corp mailto:bjorn@unboundid.com | 512-769-6461 --------------010408020508010206030308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 11/19/2012 16:31, Melinda Shore wrote:
But I think it might be worth taking some care that in closing the ticket the working group isn't saying that there will never be work on mapping between vCard and SCIM, but just that the core SCIM schema will not be based on vCard. 

That's right, Melinda.   The following text appear in the i= ssue comment:
"The valuable work on the SCIM-to-vCard mapping draft should continue as a separate effort"

-Bjorn
 
--=20
__________________________________________________________
Bjorn Aannestad | Dir, Product Management | UnboundID Corp
ma=
ilto:bjorn@unboundid.com | 512-769-6461
--------------010408020508010206030308-- --------------ms060405090408060504020205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMUjCC BVwwggREoAMCAQICECStp7X80wzNJ6GfICadV/cwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjAyMjMwMDAwMDBaFw0xMzAyMjIyMzU5NTlaMIIBHzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRgwFgYDVQQDFA9Cam9ybiBBYW5u ZXN0YWQxLDAqBgkqhkiG9w0BCQEWHWJqb3JuLmFhbm5lc3RhZEB1bmJvdW5kaWQuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw+4r+Le4uODrErBgJsA7UoexcjH/r2Ds 62wKyDCY5CQfOFMROnynV9GWWXp8zmCj7/N9I2hOU7poaqR4kkJjoiKiNHQdVfyM1yFZTurW AV5PCT5NouiqlruJDM6s2HV3B7mSRhtHFOSfhiDP+/kHf/JEdFJ7zEPaP0Kuy8XKpPR5nVCz k4zFKPBc4T9+HAlXeGY1PnwOsxPEevZlHOTThF9RunZu5Z/uaObR2JplM6KxXDfXNRjSkmK7 6kW8wFC1C0GleHKfM85nQTvVicuSK4GbbvhMjqovMtUIR1SNG8vsmTvU4PY9G/WkDM4Ge/97 phIcQIm9W/DXjC78wBfa/QIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5Bgtg hkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh MAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkw RzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5k QzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQC345zS3026vrJVysBCE3TN BhQ4VlqRtwj5AcAXhhF2c3krlbgJRLV6STYky+/i7YRdezIZYgY2eo693dlIQUnkZMb6D2PL dRs1Lgw4NJKB+WGLGkmyV8YqqKrTm/ZbPdl/+Y4Pc88DLcYEmr0OsEDel8LqLPpongUDnGU5 2wxAvaHn9sZ4nyDa3bAy9RyqrAdWhsfRttlgAbvMeHSXhvDa63AbdGdZbzBfqGpBTYZJqrA/ fzcbVZQIw7ULW0YRpUNx8bmmgxFd5ovdDVZnfiKNd7QHy+BcTQgfxLYsBYZhICz1ud1QKn88 pW944VjwHTzxyErX43AGoPYoZKA8b3XXMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT 3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5 OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6 ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f 0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Iba k2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+ wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBn MGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNV HR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNV HQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAH BgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24u Y29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0 LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHm oYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSo WufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6 jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvi d+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5l UkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaM xmgD5yKocwuxvKDaUljdCg5/wYIxggT5MIIE9QIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhAkrae1/NMMzSeh nyAmnVf3MAkGBSsOAwIaBQCgggLbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMTExOTIzNTUwNlowIwYJKoZIhvcNAQkEMRYEFN4RVosjv0hZX5fcRM0S 0UH+Ig/XMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQJK2ntfzTDM0noZ8gJp1X 9zCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCECStp7X80wzNJ6GfICadV/cwDQYJ KoZIhvcNAQEBBQAEggEAwwdeU1zhaH0rT++0QEMRN2Qlxz3yDkGjzz12A4rWJ7XwoOG1S6CQ QKN33JckeGo42MMOaUl1xN4DIKjyB4Lltloc2UK+OlFny1vVB7Tph/zYHLaB9rcRLBApfDWp Gk245L07MQJTZ43aufAQCpD49GXVPq7EdXXshlMmR6Dvao2/6vQ/gS+pQnTBwrHMC+knTXBJ O92PhWcDTvRR0pr28h0yGhZf6Stcf5rKYutJaAImOJ8aa8f1i+Hboo8cF7Jdt3htjU24yjI2 JTQk7CqRp87g6z2QpRKjNnr9W6EFgrGvMTG+4cnc+AITCkDezcjj5MqmobQvaN0wejZXYDMq 3QAAAAAAAA== --------------ms060405090408060504020205-- From likepeng@huawei.com Mon Nov 19 18:31:21 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A6521F87F7 for ; Mon, 19 Nov 2012 18:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDvOt4l8oB3B for ; Mon, 19 Nov 2012 18:31:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9900021F87F6 for ; Mon, 19 Nov 2012 18:31:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALS34818; Tue, 20 Nov 2012 02:31:12 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 02:30:44 +0000 Received: from SZXEML447-HUB.china.huawei.com (10.82.67.185) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 02:31:11 +0000 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.161]) by szxeml447-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.01.0323.003; Tue, 20 Nov 2012 10:31:07 +0800 From: Likepeng To: Bjorn Aannestad , scim WG Thread-Topic: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema Thread-Index: AQHNxpF72Enj1XzrjUSNtYaPvjTvo5fyAOiA Date: Tue, 20 Nov 2012 02:31:06 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F21ED72903@szxeml525-mbx.china.huawei.com> References: <50AA9168.2040706@unboundid.com> In-Reply-To: <50AA9168.2040706@unboundid.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.103] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 02:31:21 -0000 PlRoZSB3b3JrIHRvIHByb2R1Y2UgYSB2Q2FyZC1TQ0lNIG1hcHBpbmcgaXMsIEkgYmVsaWV2ZSwg c3RpbGwgdmFsdWFibGUgYW5kIHNob3VsZCBjb250aW51ZS4gIFRoaXMgaXMgZHJhZnQtZ3JlZXZl bmJvc2NoLXNjaW0tdmNhcmQtbWFwcGluZy4NCg0KKzEuDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5n DQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBzY2ltLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQmpvcm4gQWFubmVzdGFkDQq3osvNyrG8 5DogMjAxMsTqMTHUwjIwyNUgNDowNw0KytW8/sjLOiBzY2ltIFdHDQrW98ziOiBbc2NpbV0gUHJv cG9zYWwgdG8gcmVzb2x2ZSBhcyAid29udGZpeCI6ICMxOTogSW5jb3Jwb3JhdGUgdGhlIHZDYXJk IG1vZGVsIGludG8gdGhlIHNjaGVtYQ0KDQpIaSBhbGwsDQoNCkJhc2VkIG9uIHRoZSBkaXNjdXNz aW9ucyBpbiBBdGxhbnRhIGFuZCB0aGUgcm91Z2ggY29uc2Vuc3VzIHNhbXBsaW5nIHRoZXJlLCBJ J2QgbGlrZSB0byBwcm9wb3NlIHRoYXQgd2UgY2xvc2UgdGhlIHZDYXJkIGFkb3B0aW9uIHF1ZXN0 aW9uIGJ5IHJlc29sdmluZyB0byBOT1QgYWRvcHQgdGhlIHZDYXJkIGF0dHJpYnV0ZSBzY2hlbWEs IG5vciBpdHMgSlNPTiByZXByZXNlbnRhdGlvbi4NCg0KSXNzdWUgIzE5IGhhcyBteSBzdW1tYXJ5 IG9mIHRoZSBhZGRpdGlvbmFsIHBvaW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlIHNpbmNlIHRoZSBt ZWV0aW5nLg0KDQpUd28gaW1wb3J0YW50IG5vdGVzOg0KMS4gVGhlIHdvcmsgdG8gcHJvZHVjZSBh IHZDYXJkLVNDSU0gbWFwcGluZyBpcywgSSBiZWxpZXZlLCBzdGlsbCB2YWx1YWJsZSBhbmQgc2hv dWxkIGNvbnRpbnVlLiAgVGhpcyBpcyBkcmFmdC1ncmVldmVuYm9zY2gtc2NpbS12Y2FyZC1tYXBw aW5nLg0KMi4gSSBoYXZlIGNyZWF0ZWQgYSBzZXBhcmF0ZSBpc3N1ZSAoIzMwKSBmb3IgYWRvcHRp bmcgdGhlIElBTkEgDQpyZWdpc3RyYXRpb24gYXNwZWN0cyBvZiB2Q2FyZCBpbnRvIFNDSU0uICAg VGhpcyB3YXMgcHJvcG9zZWQgYXMgb25lIG9mIA0KdGhlIGltcG9ydGFudCBhc3BlY3RzIG9mIHZD YXJkIHRvIGNvbnNpZGVyLg0KDQpBbnkgb3RoZXIgdkNhcmQgYXNwZWN0cyB0aGF0IHdlIGZlZWwg Y291bGQgYmUgd29ydGggaW5jb3Jwb3JhdGluZyBpbnRvIFNDSU0gY2FuIGFsc28gYmUgbWFkZSBp bnRvIHNlcGFyYXRlIGlzc3Vlcy4NCg0KSG93ZXZlciwgbGV0J3MgY2xvc2UgdGhlIGJpZyBxdWVz dGlvbiB3aGljaCBpcyBob2xkaW5nIHVwIHRoZSBvdGhlciBTQ0lNIHNjaGVtYSBhZGp1c3RtZW50 cy4NCg0KUGxlYXNlIHJlc3BvbmQgd2l0aCBhc3NlbnQgb3Igb2JqZWN0aW9ucywgZXNwZWNpYWxs eSBpZiB5b3UgZmVlbCBhIHN0cm9uZyBjYXNlIGNhbiBzdGlsbCBiZSBtYWRlIGZvciB2Q2FyZC1p bi1TQ0lNLg0KDQpSZWdhcmRzLA0KLUJqb3JuDQoNCi0tDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpCam9ybiBBYW5uZXN0YWQgfCBE aXIsIFByb2R1Y3QgTWFuYWdlbWVudCB8IFVuYm91bmRJRCBDb3JwIG1haWx0bzpiam9ybkB1bmJv dW5kaWQuY29tIHwgNTEyLTc2OS02NDYxDQoNCg0K From mrutkows@us.ibm.com Mon Nov 19 19:36:38 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A0D21F8801 for ; Mon, 19 Nov 2012 19:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otAruNvyuFoC for ; Mon, 19 Nov 2012 19:36:38 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id E28B021F87CD for ; Mon, 19 Nov 2012 19:36:37 -0800 (PST) Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 19 Nov 2012 20:36:34 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 19 Nov 2012 20:36:32 -0700 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 0B53319D8036 for ; Mon, 19 Nov 2012 20:36:32 -0700 (MST) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAK3aVPI275718 for ; Mon, 19 Nov 2012 20:36:31 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAK3cNeV017704 for ; Mon, 19 Nov 2012 20:38:23 -0700 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.63.34.21]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qAK3cMOX017685 for ; Mon, 19 Nov 2012 20:38:22 -0700 Auto-Submitted: auto-generated From: Matt Rutkowski To: scim@ietf.org Message-ID: Date: Mon, 19 Nov 2012 20:36:26 -0700 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF2|October 8, 2012) at 11/19/2012 08:36:27 PM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBF02FDF8056488f9e8a93df938690918c08BBF02FDF805648" Content-Disposition: inline X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12112003-7282-0000-0000-00000F182FF9 Subject: [scim] AUTO: Matt Rutkowski/Austin/IBM is travelling (returning 11/26/2012) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 03:36:38 -0000 --0__=08BBF02FDF8056488f9e8a93df938690918c08BBF02FDF805648 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 11/26/2012. I will be travelling on business and unable to respond to email reliabl= y. For emergencies please contact my manager Johanna Koester or call my mo= bile number in Bluepages. Note: This is an automated response to your message "scim Digest, Vol = 11, Issue 16" sent on 11/19/2012 4:55:10 PM. This is the only notification you will receive while this person is awa= y.= --0__=08BBF02FDF8056488f9e8a93df938690918c08BBF02FDF805648 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 11= /26/2012.

I will be travelling on bus= iness and unable to respond to email reliably.  For emergencies pl= ease contact my manager Johanna Koester or call my mobile number in Blu= epages.


Note: Thi= s is an automated response to your message  "scim Digest, Vol 11, Issue 16"<= /font> sent= on 11/19/2012 4:55:10 P= M.
This is t= he only notification you will receive while this person is away.= = --0__=08BBF02FDF8056488f9e8a93df938690918c08BBF02FDF805648-- From Chris.Phillips@canarie.ca Tue Nov 20 05:39:29 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244DB21F85F9 for ; Tue, 20 Nov 2012 05:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMrW38P4LI0U for ; Tue, 20 Nov 2012 05:39:28 -0800 (PST) Received: from mail.canarie.ca (mail.canarie.ca [205.189.33.5]) by ietfa.amsl.com (Postfix) with ESMTP id 39EC321F8464 for ; Tue, 20 Nov 2012 05:39:13 -0800 (PST) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Tue, 20 Nov 2012 08:39:12 -0500 From: Chris Phillips To: "scim@ietf.org" Date: Tue, 20 Nov 2012 08:39:10 -0500 Thread-Topic: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema Thread-Index: Ac3HJGzSiFgVp9DDTHeSknvLD3fsJQ== Message-ID: In-Reply-To: <50AAAF47.5090007@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CCD067D9DCC04chrisphillipscanarieca_" MIME-Version: 1.0 Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 13:39:29 -0000 --_000_CCD067D9DCC04chrisphillipscanarieca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 To Bjorn's email below resolving to NOT adopt the vCard Attribute schema= , nor its JSON representation. Chris. From: Igor Faynberg > Organization: Alcatel-Lucent Reply-To: "igor.faynberg@alcatel-lucent.com" > Date: Monday, 19 November, 2012 5:14 PM To: "scim@ietf.org" > Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the = vCard model into the schema +1 Igor On 11/19/2012 3:07 PM, Bjorn Aannestad wrote: Hi all, Based on the discussions in Atlanta and the rough consensus sampling there,= I'd like to propose that we close the vCard adoption question by resolving= to NOT adopt the vCard attribute schema, nor its JSON representation. Issue #19 has my summary of the additional points that have been made since= the meeting. Two important notes: 1. The work to produce a vCard-SCIM mapping is, I believe, still valuable a= nd should continue. This is draft-greevenbosch-scim-vcard-mapping. 2. I have created a separate issue (#30) for adopting the IANA registration= aspects of vCard into SCIM. This was proposed as one of the important as= pects of vCard to consider. Any other vCard aspects that we feel could be worth incorporating into SCIM= can also be made into separate issues. However, let's close the big question which is holding up the other SCIM sc= hema adjustments. Please respond with assent or objections, especially if you feel a strong c= ase can still be made for vCard-in-SCIM. Regards, -Bjorn _______________________________________________ scim mailing list scim@ietf.orghttps://www.ietf.org/mailman/listinfo/sc= im --_000_CCD067D9DCC04chrisphillipscanarieca_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 To Bjorn's email belo= w resolving to NOT adopt the vCard Attribute schema, nor its JSON represent= ation.


Chris.

<= div>


From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
Reply-To: "igor.faynberg@alcatel-lucent.com" <igor.faynberg@alcatel-lucent.com>
= Date: Monday, 19 November, 2012 5:= 14 PM
To: "scim@ietf.org" <scim@i= etf.org>
Subject: Re: [s= cim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model int= o the schema

+1

Igor

On 11/19/2012 3:07 PM, Bjorn Aannestad wrote:
Hi al= l,

Based on the discussions in Atlanta and the rough consensus sampling there,= I'd like to propose that we close the vCard adoption question by resolving= to NOT adopt the vCard attribute schema, nor its JSON representation.

Issue #19 has my summary of the additional points that have been made since= the meeting.

Two important notes:
1. The work to produce a vCard-SCIM mapping is, I believe, still valuable a= nd should continue.  This is draft-greevenbosch-scim-vcard-mapping.
2. I have created a separate issue (#30) for adopting the IANA registration= aspects of vCard into SCIM.   This was proposed as one of the im= portant aspects of vCard to consider.

Any other vCard aspects that we feel could be worth incorporating into SCIM= can also be made into separate issues.

However, let's close the big question which is holding up the other SCIM sc= hema adjustments.

Please respond with assent or objections, especially if you feel a strong c= ase can still be made for vCard-in-SCIM.

Regards,
-Bjorn 


_______________________________________________
scim mailing list
scim@ie=
tf.orghttps://www.ietf.org/mailman/listinfo/scim
<= /blockquote>
 --_000_CCD067D9DCC04chrisphillipscanarieca_-- From kelly.grizzle@sailpoint.com Tue Nov 20 06:09:30 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14ED021F84FF for ; Tue, 20 Nov 2012 06:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30efxmGFq9X9 for ; Tue, 20 Nov 2012 06:09:28 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id D44E521F851A for ; Tue, 20 Nov 2012 06:09:27 -0800 (PST) Received: from mail67-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Tue, 20 Nov 2012 14:09:26 +0000 Received: from mail67-co1 (localhost [127.0.0.1]) by mail67-co1-R.bigfish.com (Postfix) with ESMTP id CD833802BB; Tue, 20 Nov 2012 14:09:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zzbb2dI98dI9371Ic85fh14ffIzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h15d0l1155h) Received-SPF: pass (mail67-co1: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail67-co1 (localhost.localdomain [127.0.0.1]) by mail67-co1 (MessageSwitch) id 135342056563590_12177; Tue, 20 Nov 2012 14:09:25 +0000 (UTC) Received: from CO1EHSMHS018.bigfish.com (unknown [10.243.78.233]) by mail67-co1.bigfish.com (Postfix) with ESMTP id 03E648000E1; Tue, 20 Nov 2012 14:09:25 +0000 (UTC) Received: from BY2PRD0410HT002.namprd04.prod.outlook.com (157.56.236.85) by CO1EHSMHS018.bigfish.com (10.243.66.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 20 Nov 2012 14:09:22 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.12.218]) by BY2PRD0410HT002.namprd04.prod.outlook.com ([10.255.83.37]) with mapi id 14.16.0233.002; Tue, 20 Nov 2012 14:09:17 +0000 From: Kelly Grizzle To: Chris Phillips , "scim@ietf.org" Thread-Topic: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema Thread-Index: AQHNxpF63tdLJTYxRkKJbqZJLcpP55fxuVuAgAECWQCAAAeVAA== Date: Tue, 20 Nov 2012 14:09:17 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34373EF1CA16@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <50AAAF47.5090007@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 144F6BA80036EA144F6CF5 x-originating-ip: [72.182.10.254] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C34373EF1CA16BY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 14:09:30 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C34373EF1CA16BY2PRD0410MB354_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 I agree that Bert's mapping work is very valuable and also agree with Peter= 's sentiment that if we were starting from scratch vCard would be a great p= lace to start. Given the adoption and momentum of SCIM I am +1 for keeping= the current schema. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Chr= is Phillips Sent: Tuesday, November 20, 2012 7:39 AM To: scim@ietf.org Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the = vCard model into the schema +1 To Bjorn's email below resolving to NOT adopt the vCard Attribute schema= , nor its JSON representation. Chris. From: Igor Faynberg > Organization: Alcatel-Lucent Reply-To: "igor.faynberg@alcatel-lucent.com" > Date: Monday, 19 November, 2012 5:14 PM To: "scim@ietf.org" > Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the = vCard model into the schema +1 Igor On 11/19/2012 3:07 PM, Bjorn Aannestad wrote: Hi all, Based on the discussions in Atlanta and the rough consensus sampling there,= I'd like to propose that we close the vCard adoption question by resolving= to NOT adopt the vCard attribute schema, nor its JSON representation. Issue #19 has my summary of the additional points that have been made since= the meeting. Two important notes: 1. The work to produce a vCard-SCIM mapping is, I believe, still valuable a= nd should continue. This is draft-greevenbosch-scim-vcard-mapping. 2. I have created a separate issue (#30) for adopting the IANA registration= aspects of vCard into SCIM. This was proposed as one of the important as= pects of vCard to consider. Any other vCard aspects that we feel could be worth incorporating into SCIM= can also be made into separate issues. However, let's close the big question which is holding up the other SCIM sc= hema adjustments. Please respond with assent or objections, especially if you feel a strong c= ase can still be made for vCard-in-SCIM. Regards, -Bjorn _______________________________________________ scim mailing list scim@ietf.orghttps://www.ietf.org/mailman/listinfo/sc= im --_000_56C3C758F9D6534CA3778EAA1E0C34373EF1CA16BY2PRD0410MB354_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

I agree that Bert’s= mapping work is very valuable and also agree with Peter’s sentiment = that if we were starting from scratch vCard would be a great place to start.  Given the adoption and momentum of SCIM I am +1 for keepi= ng the current schema.

 <= /p>

--Kelly=

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Chris Phillips
Sent: Tuesday, November 20, 2012 7:39 AM
To: scim@ietf.org
Subject: Re: [scim] Proposal to resolve as "wontfix": #19:= Incorporate the vCard model into the schema

 

+1 To Bjorn's email bel= ow resolving to NOT adopt the vCard Attribute schema, nor its JSON represen= tation.

 

 

Chris.

 

 

 

 

From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
Reply-To: "= igor.faynberg@alcatel-lucent.com" <igor.faynberg@alcatel-lucent.com>
Date: Monday, 19 November, 2012 5:14 PM
To: "scim@ietf.org" &= lt;scim@ietf.org>
Subject: Re: [scim] Proposal to resolve as "wontfix": #19:= Incorporate the vCard model into the schema

 

+1

Igor

On 11/19/2012 3:07 PM, Bjorn Aannestad wrote:

Hi all,

Based on the discussions in Atlanta and the rough consensus sampling there,= I'd like to propose that we close the vCard adoption question by resolving= to NOT adopt the vCard attribute schema, nor its JSON representation.

Issue #19 has my summary of the additional points that have been made since= the meeting.

Two important notes:
1. The work to produce a vCard-SCIM mapping is, I believe, still valuable a= nd should continue.  This is draft-greevenbosch-scim-vcard-mapping.
2. I have created a separate issue (#30) for adopting the IANA registration= aspects of vCard into SCIM.   This was proposed as one of the im= portant aspects of vCard to consider.

Any other vCard aspects that we feel could be worth incorporating into SCIM= can also be made into separate issues.

However, let's close the big question which is holding up the other SCIM sc= hema adjustments.

Please respond with assent or objections, especially if you feel a strong c= ase can still be made for vCard-in-SCIM.

Regards,
-Bjorn 


 
__________________________________________=
_____
scim mailing list
scim@ietf=
.orghttps://www.=
ietf.org/mailman/listinfo/scim
--_000_56C3C758F9D6534CA3778EAA1E0C34373EF1CA16BY2PRD0410MB354_-- From pradtke@stanford.edu Tue Nov 20 10:56:17 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19E921F87A3 for ; Tue, 20 Nov 2012 10:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPPbO5KZ64NZ for ; Tue, 20 Nov 2012 10:56:17 -0800 (PST) Received: from smtp.stanford.edu (smtp1.Stanford.EDU [171.67.219.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB9421F8787 for ; Tue, 20 Nov 2012 10:56:17 -0800 (PST) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5F88612DCBB for ; Tue, 20 Nov 2012 10:56:17 -0800 (PST) Received: from polml-pradtke.stanford.edu (POLML-pradtke.Stanford.EDU [171.64.18.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pradtke) by smtp.stanford.edu (Postfix) with ESMTPSA id 3522A12DE43 for ; Tue, 20 Nov 2012 10:56:17 -0800 (PST) Message-ID: <50ABD250.5010307@stanford.edu> Date: Tue, 20 Nov 2012 10:56:16 -0800 From: Patrick Radtke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: scim@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 18:56:18 -0000 We've (internally) been discussing a need for a read only Web API for our directory servers. I've been reading Phil Hunt's scim-directory draft and had some questions about the mapping inetOrgPerson to User, but first I'll describe some of the issues that make it impractical for us to map inetOrgPerson to User. In our directory, inetOrgPerson often do not have uids. These are often incoming students or affiliates that have not yet created accounts and that we'll need to make available through the Web API. In this case we wouldn't have a valid SCIM userName for these Users and couldn't expose them as a valid User resource. Our inetOrgPerson entries frequently have multiple names (e.g. former lastnames, Anglicized first names, etc), and we couldn't return the additional names in a current User resource. Similar issues arise for any multi-valued LDAP attribute that map to single value User or Enterprise User attributes (organization, department, etc). Our inetOrgPerson may, at some point, be allowed multiple uids, etc. Is our use case missing the point of the draft? Is the intent of the draft to be a quickstart in providing an LDAP backed SCIM endpoint, rather then a 'Cloud Directory'? In a 'Cloud Directory' future, would there be new standard Resources and Attributes that roughly correspond to existing LDAP ObjectClasses (e.g. an Organization resources to map organizationalUnit)? Or would organizations initially define their own ( e.g. suOrganization, eduPerson, etc)? thanks for any answers or crystal ball gazing, -Patrick From melinda.shore@gmail.com Tue Nov 20 11:26:29 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2C721F881B for ; Tue, 20 Nov 2012 11:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUB30n+za+gE for ; Tue, 20 Nov 2012 11:26:29 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7774921F87F7 for ; Tue, 20 Nov 2012 11:26:29 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so4473955pbc.31 for ; Tue, 20 Nov 2012 11:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0PLiOysn7yZQ8yeDXDze+qZz4vshNlJRWBcuCIiKxEY=; b=JOVWY4jfXfemckjzLZq9NL4Q3AJcWKw3mB2lihtVQwM2kXlX+Fh8LwMeG6+FYNFpCG zW37Y65X1lfMBoKf7UcQ8oAY/4jPSePa+FgV0l/QmH7dmrx/XlxpWWsbc74gkf82UP0p tK+FumiWJDImmOlw8wGtfO7rSWwLp0Z8V9+lxjWaOixOg3go3BW58bFdmzW8xevlx7gF zHSliwjc8nsD0505dGBqdbKyhB/gkBuv7Vjt0nsXN0s1osHgZfq4fcdD7ZiaLJXLx7M9 9azqIonDgCpUDpwtWe2c9InIdaQrloilRsb12LVLi687BvJTL4iAf+Unc0g1vDyfDZyU piJQ== Received: by 10.68.241.73 with SMTP id wg9mr45358018pbc.3.1353439589278; Tue, 20 Nov 2012 11:26:29 -0800 (PST) Received: from spandex.local (216-67-56-77-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.56.77]) by mx.google.com with ESMTPS id is6sm8497518pbc.55.2012.11.20.11.26.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Nov 2012 11:26:28 -0800 (PST) Message-ID: <50ABD961.40106@gmail.com> Date: Tue, 20 Nov 2012 10:26:25 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <50ABD250.5010307@stanford.edu> In-Reply-To: <50ABD250.5010307@stanford.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 19:26:30 -0000 On 11/20/12 9:56 AM, Patrick Radtke wrote: > We've (internally) been discussing a need for a read only Web API for > our directory servers. I've been reading Phil Hunt's scim-directory > draft and had some questions about the mapping inetOrgPerson to User, > but first I'll describe some of the issues that make it impractical for > us to map inetOrgPerson to User. This may be off-topic but might, on the other hand, go to the use case question - why don't you want to use one of the standard LDAP APIs? Melinda From phil.hunt@oracle.com Tue Nov 20 11:48:40 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1B421F8787 for ; Tue, 20 Nov 2012 11:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.137 X-Spam-Level: X-Spam-Status: No, score=-5.137 tagged_above=-999 required=5 tests=[AWL=1.462, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUR5FcX+U4if for ; Tue, 20 Nov 2012 11:48:39 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3670221F866C for ; Tue, 20 Nov 2012 11:48:39 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAKJmcgQ010282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Nov 2012 19:48:38 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAKJmb2w014251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2012 19:48:37 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAKJmbTQ015817; Tue, 20 Nov 2012 13:48:37 -0600 Received: from [192.168.1.200] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Nov 2012 11:48:37 -0800 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <50ABD250.5010307@stanford.edu> Date: Tue, 20 Nov 2012 11:48:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50ABD250.5010307@stanford.edu> To: Patrick Radtke X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: scim@ietf.org Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 19:48:40 -0000 Patrick, You are on the right track looking at the directory draft. =46rom your = description, I see you've already been working hard to extend LDAP to = support a lot more cases like multiple values etc. I came to the conclusion that a SCIM has a vastly different data model = than that of LDAP and are not compatible. =20 So the question is, should the LDAPv3 community propose an LDAP REST API = specification or should they plan to migrate to SCIM? In looking at the = data requirements of the cloud, I came to the conclusion that classic = LDAP data was not the same as what was proposed for the cloud where = vCards and PoCo are popular. My feeling is an LDAP REST spec would be = short-lived or have limited use. If anyone feels otherwise, I'd love to = here from you! It was from this perspective that I wrote the SCIM Directory draft. It = proposes directory features based on the SCIM data model. As part of = this I proposed a mapping that could give backwards mapping support for = LDAPv3 clients since it is easier to support LDAP name/value pairs on = top of SCIM complex attributes rather than the other way around. However, with all the extensions you've made at Stanford, I suspect, = this mapping will be insufficient. It is something those of us familiar = with LDAP should talk about some more. Regarding eduPerson etc, I would expect many organizations to start = defining new SCIM resource extensions to define attributes that core = SCIM does not already define. In doing so, it might be nice to collect = related attributes together in a complex attribute structure as was done = with Address in the core User schema. Thanks for bringing forward your case.=20 Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-11-20, at 10:56 AM, Patrick Radtke wrote: > We've (internally) been discussing a need for a read only Web API for = our directory servers. I've been reading Phil Hunt's scim-directory = draft and had some questions about the mapping inetOrgPerson to User, = but first I'll describe some of the issues that make it impractical for = us to map inetOrgPerson to User. >=20 > In our directory, inetOrgPerson often do not have uids. These are = often incoming students or affiliates that have not yet created accounts = and that we'll need to make available through the Web API. In this case = we wouldn't have a valid SCIM userName for these Users and couldn't = expose them as a valid User resource. >=20 > Our inetOrgPerson entries frequently have multiple names (e.g. former = lastnames, Anglicized first names, etc), and we couldn't return the = additional names in a current User resource. Similar issues arise for = any multi-valued LDAP attribute that map to single value User or = Enterprise User attributes (organization, department, etc). Our = inetOrgPerson may, at some point, be allowed multiple uids, etc. >=20 > Is our use case missing the point of the draft? > Is the intent of the draft to be a quickstart in providing an LDAP = backed SCIM endpoint, rather then a 'Cloud Directory'? > In a 'Cloud Directory' future, would there be new standard Resources = and Attributes that roughly correspond to existing LDAP ObjectClasses = (e.g. an Organization resources to map organizationalUnit)? Or would = organizations initially define their own ( e.g. suOrganization, = eduPerson, etc)? >=20 > thanks for any answers or crystal ball gazing, >=20 > -Patrick >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From pradtke@stanford.edu Tue Nov 20 12:50:47 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0136421F8817 for ; Tue, 20 Nov 2012 12:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWwM3KcKFnn0 for ; Tue, 20 Nov 2012 12:50:46 -0800 (PST) Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7345D21F8810 for ; Tue, 20 Nov 2012 12:50:46 -0800 (PST) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 502C545D2A0; Tue, 20 Nov 2012 12:50:46 -0800 (PST) Received: from polml-pradtke.stanford.edu (POLML-pradtke.Stanford.EDU [171.64.18.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pradtke) by smtp.stanford.edu (Postfix) with ESMTPSA id 047EB45D121; Tue, 20 Nov 2012 12:50:46 -0800 (PST) Message-ID: <50ABED25.6070306@stanford.edu> Date: Tue, 20 Nov 2012 12:50:45 -0800 From: Patrick Radtke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Melinda Shore References: <50ABD250.5010307@stanford.edu> <50ABD961.40106@gmail.com> In-Reply-To: <50ABD961.40106@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 20:50:47 -0000 On 11/20/12 11:26 AM, Melinda Shore wrote: > On 11/20/12 9:56 AM, Patrick Radtke wrote: >> We've (internally) been discussing a need for a read only Web API for >> our directory servers. I've been reading Phil Hunt's scim-directory >> draft and had some questions about the mapping inetOrgPerson to User, >> but first I'll describe some of the issues that make it impractical for >> us to map inetOrgPerson to User. > > This may be off-topic but might, on the other hand, go to the > use case question - why don't you want to use one of the standard > LDAP APIs? The primary reason is that there are some mobile phone apps being developed on campus that need to search for people. This directory data requires authenticated access. We don't want users to enter/save their central credentials into these applications and would prefer to use something like Web SSO and OAuth2 to handle the authn/authz. Not enough of our mobile users have client certificates for us to pursue that option. -Patrick From pradtke@stanford.edu Tue Nov 20 12:55:28 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A273E21F8479 for ; Tue, 20 Nov 2012 12:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uo0m7Ol0-zcZ for ; Tue, 20 Nov 2012 12:55:28 -0800 (PST) Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by ietfa.amsl.com (Postfix) with ESMTP id F287421F8472 for ; Tue, 20 Nov 2012 12:55:27 -0800 (PST) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DF14E45DC2C; Tue, 20 Nov 2012 12:55:27 -0800 (PST) Received: from polml-pradtke.stanford.edu (POLML-pradtke.Stanford.EDU [171.64.18.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pradtke) by smtp.stanford.edu (Postfix) with ESMTPSA id A7E1C45CFA2; Tue, 20 Nov 2012 12:55:27 -0800 (PST) Message-ID: <50ABEE3F.5080608@stanford.edu> Date: Tue, 20 Nov 2012 12:55:27 -0800 From: Patrick Radtke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Phil Hunt References: <50ABD250.5010307@stanford.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 20:55:28 -0000 Thanks Phil. That really helps my mental picture of this stuff. On 11/20/12 11:48 AM, Phil Hunt wrote: > Patrick, > > You are on the right track looking at the directory draft. From your description, I see you've already been working hard to extend LDAP to support a lot more cases like multiple values etc. > > I came to the conclusion that a SCIM has a vastly different data model than that of LDAP and are not compatible. > > So the question is, should the LDAPv3 community propose an LDAP REST API specification or should they plan to migrate to SCIM? In looking at the data requirements of the cloud, I came to the conclusion that classic LDAP data was not the same as what was proposed for the cloud where vCards and PoCo are popular. My feeling is an LDAP REST spec would be short-lived or have limited use. If anyone feels otherwise, I'd love to here from you! > > It was from this perspective that I wrote the SCIM Directory draft. It proposes directory features based on the SCIM data model. As part of this I proposed a mapping that could give backwards mapping support for LDAPv3 clients since it is easier to support LDAP name/value pairs on top of SCIM complex attributes rather than the other way around. > > However, with all the extensions you've made at Stanford, I suspect, this mapping will be insufficient. It is something those of us familiar with LDAP should talk about some more. > > Regarding eduPerson etc, I would expect many organizations to start defining new SCIM resource extensions to define attributes that core SCIM does not already define. In doing so, it might be nice to collect related attributes together in a complex attribute structure as was done with Address in the core User schema. > > Thanks for bringing forward your case. > > Cheers, > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-11-20, at 10:56 AM, Patrick Radtke wrote: > >> We've (internally) been discussing a need for a read only Web API for our directory servers. I've been reading Phil Hunt's scim-directory draft and had some questions about the mapping inetOrgPerson to User, but first I'll describe some of the issues that make it impractical for us to map inetOrgPerson to User. >> >> In our directory, inetOrgPerson often do not have uids. These are often incoming students or affiliates that have not yet created accounts and that we'll need to make available through the Web API. In this case we wouldn't have a valid SCIM userName for these Users and couldn't expose them as a valid User resource. >> >> Our inetOrgPerson entries frequently have multiple names (e.g. former lastnames, Anglicized first names, etc), and we couldn't return the additional names in a current User resource. Similar issues arise for any multi-valued LDAP attribute that map to single value User or Enterprise User attributes (organization, department, etc). Our inetOrgPerson may, at some point, be allowed multiple uids, etc. >> >> Is our use case missing the point of the draft? >> Is the intent of the draft to be a quickstart in providing an LDAP backed SCIM endpoint, rather then a 'Cloud Directory'? >> In a 'Cloud Directory' future, would there be new standard Resources and Attributes that roughly correspond to existing LDAP ObjectClasses (e.g. an Organization resources to map organizationalUnit)? Or would organizations initially define their own ( e.g. suOrganization, eduPerson, etc)? >> >> thanks for any answers or crystal ball gazing, >> >> -Patrick >> >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > From edreux@cloudiway.com Tue Nov 20 14:08:43 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343FC21F874B for ; Tue, 20 Nov 2012 14:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNWngGwpo+NO for ; Tue, 20 Nov 2012 14:08:42 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 39AA121F86B9 for ; Tue, 20 Nov 2012 14:08:41 -0800 (PST) Received: from mail162-co1-R.bigfish.com (10.243.78.235) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Tue, 20 Nov 2012 22:08:35 +0000 Received: from mail162-co1 (localhost [127.0.0.1]) by mail162-co1-R.bigfish.com (Postfix) with ESMTP id E68F93001F1; Tue, 20 Nov 2012 22:08:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0610HT004.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -71 X-BigFish: PS-71(zzc89bh15caKJzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh186Mz2fh2a8h668h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h) Received-SPF: pass (mail162-co1: domain of cloudiway.com designates 157.56.252.53 as permitted sender) client-ip=157.56.252.53; envelope-from=edreux@cloudiway.com; helo=DB3PRD0610HT004.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail162-co1 (localhost.localdomain [127.0.0.1]) by mail162-co1 (MessageSwitch) id 1353449311764566_30145; Tue, 20 Nov 2012 22:08:31 +0000 (UTC) Received: from CO1EHSMHS007.bigfish.com (unknown [10.243.78.227]) by mail162-co1.bigfish.com (Postfix) with ESMTP id B5A221C0019; Tue, 20 Nov 2012 22:08:31 +0000 (UTC) Received: from DB3PRD0610HT004.eurprd06.prod.outlook.com (157.56.252.53) by CO1EHSMHS007.bigfish.com (10.243.66.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 20 Nov 2012 22:08:26 +0000 Received: from DB3PRD0610MB356.eurprd06.prod.outlook.com ([169.254.8.60]) by DB3PRD0610HT004.eurprd06.prod.outlook.com ([10.255.47.39]) with mapi id 14.16.0233.002; Tue, 20 Nov 2012 22:08:24 +0000 From: Emmanuel Dreux To: Patrick Radtke , "scim@ietf.org" Thread-Topic: [scim] SCIM as Cloud Directory API Thread-Index: AQHNx1nLS2fYCHWHWEirnAgw4JfIjJfzOJMw Date: Tue, 20 Nov 2012 22:08:24 +0000 Message-ID: References: <50ABD250.5010307@stanford.edu> In-Reply-To: <50ABD250.5010307@stanford.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.209.187.209] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 22:08:43 -0000 I see 2 points in your thread: 1. inetOrgPerson often do not have uids [...] =3D> LDAP directories do not (generally) provide immutable ids. =3D> You can allocate uniqueIDs in your SCIM implementation and maintain a = mapping table between your LDAP objects and SCIM Identifiers. =3D> This also simplifies group membership and roles synchronization. 2. Schema: The SCIM default schemas are extensible and you can easily imple= ment yours. Personal feedback from a real experience. Today: a. We synchronize LDAP organizational units with google and postini. b. We allocate licences during provisioning of Office 365. c. We sync public keys with a SAAS provider for specific needs. In a "SCIM" world, for each of these scenario, the provider would have to i= mplement a specific schema. Said differently, today, if we want to provision Salesforce, Google, Dropbo= x, office365,etc., we have to learn and integrate their heterogeneous apis= .=20 Tomorrow, in a SCIM world, we'll have to integrate as many proprietary sche= mas as we would have providers.=20 What's the difference, is it more practicable? In parallal, Microsoft has implemented his LDAP restful apis (see phil comm= ents). It is very convenient to use and entirely fits LDAP scenarii (schema= : http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspx) In parallal, we've also discovered FOAF and RDF. This is, according to us, = the most extensible solution: a unique and universal schemas, transparently= extensible for everybody (compared to LDAP and OIDS definitions, and compa= red to SCIM and the need to define your own classes when you need additiona= l attributes). I'm really afraid that if we have 100 SAAS providers, we'll endup with 100 = proprietary schemas. Please send me your comments on this.=20 -- Cordialement / Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux -----Message d'origine----- De=A0: Patrick Radtke [mailto:pradtke@stanford.edu]=20 Envoy=E9=A0: mardi 20 novembre 2012 19:56 =C0=A0: scim@ietf.org Objet=A0: [scim] SCIM as Cloud Directory API We've (internally) been discussing a need for a read only Web API for our d= irectory servers. I've been reading Phil Hunt's scim-directory draft and ha= d some questions about the mapping inetOrgPerson to User, but first I'll de= scribe some of the issues that make it impractical for us to map inetOrgPer= son to User. In our directory, inetOrgPerson often do not have uids. These are often inc= oming students or affiliates that have not yet created accounts and that we= 'll need to make available through the Web API. In this case we wouldn't h= ave a valid SCIM userName for these Users and couldn't expose them as a val= id User resource. Our inetOrgPerson entries frequently have multiple names (e.g. former lastn= ames, Anglicized first names, etc), and we couldn't return the additional n= ames in a current User resource. Similar issues arise for any multi-valued = LDAP attribute that map to single value User or Enterprise User attributes = (organization, department, etc). Our inetOrgPerson may, at some point, be a= llowed multiple uids, etc. Is our use case missing the point of the draft? Is the intent of the draft to be a quickstart in providing an LDAP backed S= CIM endpoint, rather then a 'Cloud Directory'? In a 'Cloud Directory' future, would there be new standard Resources and At= tributes that roughly correspond to existing LDAP ObjectClasses (e.g.=20 an Organization resources to map organizationalUnit)? Or would organization= s initially define their own ( e.g. suOrganization, eduPerson, etc)? thanks for any answers or crystal ball gazing, -Patrick From leifj@mnt.se Wed Nov 21 00:26:14 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56A821F8443 for ; Wed, 21 Nov 2012 00:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3H-3VXIBJuM for ; Wed, 21 Nov 2012 00:26:14 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9387421F842D for ; Wed, 21 Nov 2012 00:26:13 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so5671403lbk.31 for ; Wed, 21 Nov 2012 00:26:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=YTPKHG7sMEXYwKBIzObW6sgraC2g9L+uD2hB1HJPfbs=; b=b0lo9JtEFEpapVxJS79eFYDy0pTqgJ2YolxNmYxTO2dkI71zgSOU/fvQSagklm7xER YPJe3So447EBe+zgVXoG5Q+rOtKKYJxKebSfV0gwiKouuhqFthkC+bu1VqSuPBil1jRO bHbLyzM7mW4Sm8J/qOBuIZs9ZsdDJ8wsvbaLiJbr1YCKsL7wKq9RsuXMfumkBSBcE62Z q3dXCbSzSqe8eKBcWQm6Qcjnp2s3y6jCu70run26RbxtuXiMUHIjRM6eiBV3aZHeY1ax aB1exkrhTlzcGlk6OarsjcswupZCIziqiSuOJdlB04pPtlmE84gr4OuIBYW1LsUe+Egw ApWw== Received: by 10.112.50.205 with SMTP id e13mr5289868lbo.57.1353486372018; Wed, 21 Nov 2012 00:26:12 -0800 (PST) Received: from ?IPv6:2001:948:6:2:b4e4:2f8a:9bbd:9cf8? ([2001:948:6:2:b4e4:2f8a:9bbd:9cf8]) by mx.google.com with ESMTPS id pw17sm5710987lab.5.2012.11.21.00.26.10 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 00:26:10 -0800 (PST) Message-ID: <50AC9020.8070707@mnt.se> Date: Wed, 21 Nov 2012 09:26:08 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: scim WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQngU6BW3JfnbGukKItxW+lafGIM3ajVhlINWzHq1ZEvgxV/4EU4LeC88d1OLztZ2t19oxgA Subject: [scim] Minutes from ATL X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 08:26:15 -0000 The minutes from ATL (IETF-85) is now online at http://www.ietf.org/proceedings/85/minutes/minutes-85-scim Many thanks to Milan Sova. Cheers Leif & Morteza From Bert.Greevenbosch@huawei.com Fri Nov 23 17:04:36 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D6821F85AA for ; Fri, 23 Nov 2012 17:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDxdgYRljzHC for ; Fri, 23 Nov 2012 17:04:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BF52A21F8518 for ; Fri, 23 Nov 2012 17:04:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANC08852; Sat, 24 Nov 2012 01:04:30 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 24 Nov 2012 01:03:48 +0000 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 24 Nov 2012 01:04:27 +0000 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Sat, 24 Nov 2012 09:04:20 +0800 From: Bert Greevenbosch To: Kelly Grizzle , Chris Phillips , "scim@ietf.org" Thread-Topic: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema Thread-Index: AQHNxpF502YfXuswVkK8T6UUR7XqNJfxMz+AgAECWACAAAhqgIAF80ZA Date: Sat, 24 Nov 2012 01:04:20 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CAA39E7@szxeml509-mbs> References: <50AAAF47.5090007@alcatel-lucent.com> <56C3C758F9D6534CA3778EAA1E0C34373EF1CA16@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34373EF1CA16@BY2PRD0410MB354.namprd04.prod.outlook.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB63CAA39E7szxeml509mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 01:04:36 -0000 --_000_46A1DF3F04371240B504290A071B4DB63CAA39E7szxeml509mbs_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for keeping the current schema. I will be happy to continue the work on = the mapping draft. Best regards, Bert From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kel= ly Grizzle Sent: 20 November 2012 22:09 To: Chris Phillips; scim@ietf.org Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the = vCard model into the schema +1 I agree that Bert's mapping work is very valuable and also agree with Peter= 's sentiment that if we were starting from scratch vCard would be a great p= lace to start. Given the adoption and momentum of SCIM I am +1 for keeping= the current schema. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Chr= is Phillips Sent: Tuesday, November 20, 2012 7:39 AM To: scim@ietf.org Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the = vCard model into the schema +1 To Bjorn's email below resolving to NOT adopt the vCard Attribute schema= , nor its JSON representation. Chris. From: Igor Faynberg > Organization: Alcatel-Lucent Reply-To: "igor.faynberg@alcatel-lucent.com" > Date: Monday, 19 November, 2012 5:14 PM To: "scim@ietf.org" > Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the = vCard model into the schema +1 Igor On 11/19/2012 3:07 PM, Bjorn Aannestad wrote: Hi all, Based on the discussions in Atlanta and the rough consensus sampling there,= I'd like to propose that we close the vCard adoption question by resolving= to NOT adopt the vCard attribute schema, nor its JSON representation. Issue #19 has my summary of the additional points that have been made since= the meeting. Two important notes: 1. The work to produce a vCard-SCIM mapping is, I believe, still valuable a= nd should continue. This is draft-greevenbosch-scim-vcard-mapping. 2. I have created a separate issue (#30) for adopting the IANA registration= aspects of vCard into SCIM. This was proposed as one of the important as= pects of vCard to consider. Any other vCard aspects that we feel could be worth incorporating into SCIM= can also be made into separate issues. However, let's close the big question which is holding up the other SCIM sc= hema adjustments. Please respond with assent or objections, especially if you feel a strong c= ase can still be made for vCard-in-SCIM. Regards, -Bjorn _______________________________________________ scim mailing list scim@ietf.orghttps://www.ietf.org/mailman/listinfo/sc= im --_000_46A1DF3F04371240B504290A071B4DB63CAA39E7szxeml509mbs_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 for keeping the current schema. = I will be happy to continue the work on the mapping draft.

 

Best regards,

Bert

 

 

From: scim-bounces@ietf.o= rg [mailto:scim-bounces@ietf.org] On Behalf Of Kelly Grizzle
Sent: 20 November 2012 22:09
To: Chris Phillips; scim@ietf.org
Subject: Re: [scim] Proposal to resolve as "wontfix": #19:= Incorporate the vCard model into the schema

 

+1

 

I agree that Bert’s mapping work is very valuable and = also agree with Peter’s sentiment that if we were starting from scrat= ch vCard would be a great place to start.  Given the adoption and momentum of SCIM I am= +1 for keeping the current schema.

 

--Kelly

 

From: scim-bounces@ietf.o= rg [mailto:scim-bounces@ietf.org] On Behalf Of Chris Phillips
Sent: Tuesday, November 20, 2012 7:39 AM
To: scim@ietf.org
Subject: Re: [scim] Proposal to resolve as "wontfix": #19:= Incorporate the vCard model into the schema

 

+1 To Bjorn's email below resolving to NOT adopt the vCard= Attribute schema, nor its JSON representation.

 

 

Chris.

 

 

 

 

From: Igor Faynberg <igor.faynberg@alcatel-lucent.= com>
Organization: Alcatel-Lucent
Reply-To: "= igor.faynberg@alcatel-lucent.com" <igor.faynberg@alcatel-lucent.com>
Date: Monday, 19 November, 2012 5:14 PM
To: "scim@ietf.org" &= lt;scim@ietf.org>
Subject: Re: [scim] Proposal to resolve as "wontfix": #19:= Incorporate the vCard model into the schema

 

+1

Igor

On 11/19/2012 3:07 PM, Bjorn Aannestad wrote:

Hi all,

Based on the discussions in Atlanta and the rough consensus sampling there,= I'd like to propose that we close the vCard adoption question by resolving= to NOT adopt the vCard attribute schema, nor its JSON representation.

Issue #19 has my summary of the additional points that have been made since= the meeting.

Two important notes:
1. The work to produce a vCard-SCIM mapping is, I believe, still valuable a= nd should continue.  This is draft-greevenbosch-scim-vcard-mapping.
2. I have created a separate issue (#30) for adopting the IANA registration= aspects of vCard into SCIM.   This was proposed as one of the im= portant aspects of vCard to consider.

Any other vCard aspects that we feel could be worth incorporating into SCIM= can also be made into separate issues.

However, let's close the big question which is holding up the other SCIM sc= hema adjustments.

Please respond with assent or objections, especially if you feel a strong c= ase can still be made for vCard-in-SCIM.

Regards,
-Bjorn 

 

___________________________=
____________________


scim mailing list


scim@ietf.orghttps://www.ietf.org/mailman/listinfo/scim
--_000_46A1DF3F04371240B504290A071B4DB63CAA39E7szxeml509mbs_-- From leifj@mnt.se Sat Nov 24 07:28:26 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3929421F8588 for ; Sat, 24 Nov 2012 07:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZrj+UHT84Mj for ; Sat, 24 Nov 2012 07:28:25 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 592A421F8587 for ; Sat, 24 Nov 2012 07:28:25 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so8233437lbk.31 for ; Sat, 24 Nov 2012 07:28:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=mnP7TJfLbSSmqQnWRQgNk1hetX7PkQO/X49Q7c4knvk=; b=kVZwrf8OtemIyKDXPPKQR48P2E/QbUoY2R0Pj1hVoNBpU6iIXW/fG6+ZnOaT7oZGdO 6o7+qk44GLae1ZcxOMi2i5hnDPYHcUr9g4CM6yj3rGspltloZUDcg50rVkboWYXE5EVZ 5ivTK49s26G3OBI3crZPvO9R5/zU9sda2lRfqq4rAa72AxpegyyJixGGefax8VDta1eI IEgzJ1ZxJvkjiGoiLlYqpGgzSrXkcApvn/4xfFqfpmtR6pX+13b9Uoxf6B3WEPb/3mah ztu44BiwFdU1Gh62vVdjsKlwqBr1pWMVB544RBZ/WA8ef+N8Gy2bpY3yLIaIvc6AE3ra AGRg== Received: by 10.112.37.138 with SMTP id y10mr2890114lbj.121.1353770904116; Sat, 24 Nov 2012 07:28:24 -0800 (PST) Received: from [10.33.3.161] ([212.247.15.226]) by mx.google.com with ESMTPS id lv1sm3409481lab.14.2012.11.24.07.28.21 (version=SSLv3 cipher=OTHER); Sat, 24 Nov 2012 07:28:22 -0800 (PST) Message-ID: <50B0E794.5060808@mnt.se> Date: Sat, 24 Nov 2012 16:28:20 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: scim@ietf.org References: <50AA9168.2040706@unboundid.com> In-Reply-To: <50AA9168.2040706@unboundid.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlPJGTBBa3uRzk/mYVPGlX3LpW3e+PAFjmouqr+U1IgOOpaSb2VeZerwU2KHc1RPysSoIyC Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 15:28:26 -0000 On 11/19/2012 09:07 PM, Bjorn Aannestad wrote: > Hi all, > > Based on the discussions in Atlanta and the rough consensus sampling > there, I'd like to propose that we close the vCard adoption question > by resolving to NOT adopt the vCard attribute schema, nor its JSON > representation. > So far this sounds like pretty solid consensus but I'd like to give the WG a _little_ more time collecting +1/-1's since there were a few people at the mic in ATL if not arguing for vCard, at least being very much on the fence. By a little more time I mean at least a week(ish) since we're in the middle of a major US holiday. Cheers Leif From tonynad@microsoft.com Sat Nov 24 08:22:37 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBC721F84F3 for ; Sat, 24 Nov 2012 08:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27FQBYZ7gECt for ; Sat, 24 Nov 2012 08:22:36 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id A833021F84DC for ; Sat, 24 Nov 2012 08:22:36 -0800 (PST) Received: from mail123-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Sat, 24 Nov 2012 16:22:34 +0000 Received: from mail123-co1 (localhost [127.0.0.1]) by mail123-co1-R.bigfish.com (Postfix) with ESMTP id C6AEB200448 for ; Sat, 24 Nov 2012 16:22:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VS-25(zzbb2dI98dI9371I14ffI542M1432Izz1de0h1202h1d1ah1d2ah1082kzz1033IL8275dhz2fh2a8h683h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h9a9j1155h) Received-SPF: pass (mail123-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail123-co1 (localhost.localdomain [127.0.0.1]) by mail123-co1 (MessageSwitch) id 1353774152577181_30257; Sat, 24 Nov 2012 16:22:32 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.249]) by mail123-co1.bigfish.com (Postfix) with ESMTP id 8B3C1600463 for ; Sat, 24 Nov 2012 16:22:32 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 24 Nov 2012 16:22:30 +0000 Received: from db3outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sat, 24 Nov 2012 16:22:30 +0000 Received: from mail51-db3-R.bigfish.com (10.3.81.247) by DB3EHSOBE010.bigfish.com (10.3.84.30) with Microsoft SMTP Server id 14.1.225.23; Sat, 24 Nov 2012 16:22:28 +0000 Received: from mail51-db3 (localhost [127.0.0.1]) by mail51-db3-R.bigfish.com (Postfix) with ESMTP id A1D892E0421 for ; Sat, 24 Nov 2012 16:22:28 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(299001);DIR:OUT;LANG:en; Received: from mail51-db3 (localhost.localdomain [127.0.0.1]) by mail51-db3 (MessageSwitch) id 1353774146791083_27666; Sat, 24 Nov 2012 16:22:26 +0000 (UTC) Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.230]) by mail51-db3.bigfish.com (Postfix) with ESMTP id B5276180094; Sat, 24 Nov 2012 16:22:26 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 24 Nov 2012 16:22:24 +0000 Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.239.5; Sat, 24 Nov 2012 16:22:12 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.545.9; Sat, 24 Nov 2012 16:21:37 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.10.178]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.10.252]) with mapi id 15.00.0545.000; Sat, 24 Nov 2012 16:21:06 +0000 From: Anthony Nadalin To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema Thread-Index: AQHNxpGTQMj+JwyYvka1mO3mHiEg7Zf5I4cAgAAN9iA= Date: Sat, 24 Nov 2012 16:21:06 +0000 Message-ID: References: <50AA9168.2040706@unboundid.com> <50B0E794.5060808@mnt.se> In-Reply-To: <50B0E794.5060808@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.93.23] x-forefront-prvs: 067553F396 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT005.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MNT.SE$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 16:22:37 -0000 So the way this question is proposed this does not close the question of sc= hema or representation, it just says that we won't adopt the vCard proposal= but leave us open to changing existing schema and representation as I'm no= t really happy with existing proposal, as I think it can be far simpler wit= h better extensibility.=20 -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Saturday, November 24, 2012 7:28 AM To: scim@ietf.org Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the = vCard model into the schema On 11/19/2012 09:07 PM, Bjorn Aannestad wrote: > Hi all, > > Based on the discussions in Atlanta and the rough consensus sampling=20 > there, I'd like to propose that we close the vCard adoption question=20 > by resolving to NOT adopt the vCard attribute schema, nor its JSON=20 > representation. > So far this sounds like pretty solid consensus but I'd like to give the WG = a _little_ more time collecting +1/-1's since there were a few people at th= e mic in ATL if not arguing for vCard, at least being very much on the fenc= e. By a little more time I mean at least a week(ish) since we're in the middle= of a major US holiday. Cheers Leif _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From pradtke@stanford.edu Mon Nov 26 09:14:42 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE5921F853B for ; Mon, 26 Nov 2012 09:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuLeCdmJQXBn for ; Mon, 26 Nov 2012 09:14:41 -0800 (PST) Received: from smtp.stanford.edu (smtp1.Stanford.EDU [171.67.219.81]) by ietfa.amsl.com (Postfix) with ESMTP id 70E2921F84EB for ; Mon, 26 Nov 2012 09:14:40 -0800 (PST) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 56C9B14097E; Mon, 26 Nov 2012 09:14:40 -0800 (PST) Received: from radtke.local (c-50-131-40-145.hsd1.ca.comcast.net [50.131.40.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pradtke) by smtp.stanford.edu (Postfix) with ESMTPSA id 4091514096D; Mon, 26 Nov 2012 09:14:39 -0800 (PST) Message-ID: <50B3A37F.3060900@stanford.edu> Date: Mon, 26 Nov 2012 09:14:39 -0800 From: Patrick Radtke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Emmanuel Dreux References: <50ABD250.5010307@stanford.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "scim@ietf.org" Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 17:14:42 -0000 Thanks for the feedback Emmanuel, and the pointer to the Microsoft Graph API - it is interesting to read their approach. As for your point on "100 SAAS providers and 100 proprietary schemas" I suspect that a SAAS provider would not require more than the core schemas for basic provisioning, and the proprietary schemas would come in to play for SAAS specific settings (data visibility, privacy settings, access controls, in app 'theme' selection, etc) that are somewhat tangential to provisioning but are linked to a user's account. I think the proprietary schema would provided an enhanced experience but would not be required for provisioning. -Patrick On 11/20/12 2:08 PM, Emmanuel Dreux wrote: > I see 2 points in your thread: > 1. inetOrgPerson often do not have uids [...] > => LDAP directories do not (generally) provide immutable ids. > => You can allocate uniqueIDs in your SCIM implementation and maintain a mapping table between your LDAP objects and SCIM Identifiers. > => This also simplifies group membership and roles synchronization. > > 2. Schema: The SCIM default schemas are extensible and you can easily implement yours. > Personal feedback from a real experience. Today: > a. We synchronize LDAP organizational units with google and postini. > b. We allocate licences during provisioning of Office 365. > c. We sync public keys with a SAAS provider for specific needs. > > In a "SCIM" world, for each of these scenario, the provider would have to implement a specific schema. > Said differently, today, if we want to provision Salesforce, Google, Dropbox, office365,etc., we have to learn and integrate their heterogeneous apis. > Tomorrow, in a SCIM world, we'll have to integrate as many proprietary schemas as we would have providers. > What's the difference, is it more practicable? > > In parallal, Microsoft has implemented his LDAP restful apis (see phil comments). It is very convenient to use and entirely fits LDAP scenarii (schema : http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspx) > In parallal, we've also discovered FOAF and RDF. This is, according to us, the most extensible solution: a unique and universal schemas, transparently extensible for everybody (compared to LDAP and OIDS definitions, and compared to SCIM and the need to define your own classes when you need additional attributes). > > I'm really afraid that if we have 100 SAAS providers, we'll endup with 100 proprietary schemas. Please send me your comments on this. > > -- > Cordialement / Regards, > Emmanuel Dreux > http://www.cloudiway.com > Tel: +33 4 26 78 17 58 > Mobile: +33 6 47 81 26 70 > skype: Emmanuel.Dreux > > -----Message d'origine----- > De : Patrick Radtke [mailto:pradtke@stanford.edu] > Envoyé : mardi 20 novembre 2012 19:56 > À : scim@ietf.org > Objet : [scim] SCIM as Cloud Directory API > > We've (internally) been discussing a need for a read only Web API for our directory servers. I've been reading Phil Hunt's scim-directory draft and had some questions about the mapping inetOrgPerson to User, but first I'll describe some of the issues that make it impractical for us to map inetOrgPerson to User. > > In our directory, inetOrgPerson often do not have uids. These are often incoming students or affiliates that have not yet created accounts and that we'll need to make available through the Web API. In this case we wouldn't have a valid SCIM userName for these Users and couldn't expose them as a valid User resource. > > Our inetOrgPerson entries frequently have multiple names (e.g. former lastnames, Anglicized first names, etc), and we couldn't return the additional names in a current User resource. Similar issues arise for any multi-valued LDAP attribute that map to single value User or Enterprise User attributes (organization, department, etc). Our inetOrgPerson may, at some point, be allowed multiple uids, etc. > > Is our use case missing the point of the draft? > Is the intent of the draft to be a quickstart in providing an LDAP backed SCIM endpoint, rather then a 'Cloud Directory'? > In a 'Cloud Directory' future, would there be new standard Resources and Attributes that roughly correspond to existing LDAP ObjectClasses (e.g. > an Organization resources to map organizationalUnit)? Or would organizations initially define their own ( e.g. suOrganization, eduPerson, etc)? > > thanks for any answers or crystal ball gazing, > > -Patrick > > > > > > From edreux@cloudiway.com Mon Nov 26 10:02:05 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F101B21F851E for ; Mon, 26 Nov 2012 10:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJdeqRAoqI9r for ; Mon, 26 Nov 2012 10:02:04 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABC821F84F8 for ; Mon, 26 Nov 2012 10:02:02 -0800 (PST) Received: from mail23-db3-R.bigfish.com (10.3.81.237) by DB3EHSOBE008.bigfish.com (10.3.84.28) with Microsoft SMTP Server id 14.1.225.23; Mon, 26 Nov 2012 18:02:02 +0000 Received: from mail23-db3 (localhost [127.0.0.1]) by mail23-db3-R.bigfish.com (Postfix) with ESMTP id D9D6B1A0223; Mon, 26 Nov 2012 18:02:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT005.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -76 X-BigFish: PS-76(zzbb2dI98dI9371Ic89bh1432I15caKJ1447Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh186Mz2fh2a8h668h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h) Received-SPF: pass (mail23-db3: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT005.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail23-db3 (localhost.localdomain [127.0.0.1]) by mail23-db3 (MessageSwitch) id 1353952919959582_27299; Mon, 26 Nov 2012 18:01:59 +0000 (UTC) Received: from DB3EHSMHS003.bigfish.com (unknown [10.3.81.227]) by mail23-db3.bigfish.com (Postfix) with ESMTP id DE09F40019E; Mon, 26 Nov 2012 18:01:59 +0000 (UTC) Received: from AMXPRD0610HT005.eurprd06.prod.outlook.com (157.56.248.213) by DB3EHSMHS003.bigfish.com (10.3.87.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 26 Nov 2012 18:01:57 +0000 Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.1.210]) by AMXPRD0610HT005.eurprd06.prod.outlook.com ([10.255.58.40]) with mapi id 14.16.0239.002; Mon, 26 Nov 2012 18:01:56 +0000 From: Emmanuel Dreux To: Patrick Radtke Thread-Topic: [scim] SCIM as Cloud Directory API Thread-Index: AQHNx1nLS2fYCHWHWEirnAgw4JfIjJfzOJMwgAkrwYCAAAoLMA== Date: Mon, 26 Nov 2012 18:01:55 +0000 Message-ID: References: <50ABD250.5010307@stanford.edu> <50B3A37F.3060900@stanford.edu> In-Reply-To: <50B3A37F.3060900@stanford.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.214.0.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Cc: "scim@ietf.org" Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 18:02:05 -0000 If you look at the 2 main providers for online messaging systems, you will = notice that the core SCIM schema is not sufficient: - Google syncs AD organizational Unit to Google Organizations =3D Need for = Extended schema - Office 365 needs to assign specific licences =3D Extended schema. In fact, for all the SAAS providers that we sync, the core schema has never= been sufficient. For example, - We provision RunMyProcess: they have a notion of roles and entities, (=3D= 2 distinct level of roles). - We are plugging a new SAAS provider with which we need to sync public key= s (not the full certificate handled by SCIM). Etc... Etc... In fact, we have noticed that all of our SAAS partners have particularities= and if we want to sync them through SCIM, we have to build a proprietary s= chema for each of them, reason why we're asking the possibility to extend m= ore simply the core schema (add attributes without having to create a separ= ate schema). (Finally we have noticed that FOAF is THE flexible and evolutive identity s= chema that would 100% address all the needs of identity management, but if = you allow to add attributes to the core SCIM schema, it would also be fine.= ..) -- Cordialement / Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux -----Message d'origine----- De=A0: Patrick Radtke [mailto:pradtke@stanford.edu]=20 Envoy=E9=A0: lundi 26 novembre 2012 18:15 =C0=A0: Emmanuel Dreux Cc=A0: scim@ietf.org Objet=A0: Re: [scim] SCIM as Cloud Directory API Thanks for the feedback Emmanuel, and the pointer to the Microsoft Graph AP= I - it is interesting to read their approach. As for your point on "100 SAAS providers and 100 proprietary schemas" I sus= pect that a SAAS provider would not require more than the core schemas for = basic provisioning, and the proprietary schemas would come in to play for S= AAS specific settings (data visibility, privacy settings, access controls, = in app 'theme' selection, etc) that are somewhat tangential to provisioning= but are linked to a user's account.=20 I think the proprietary schema would provided an enhanced experience but wo= uld not be required for provisioning. -Patrick On 11/20/12 2:08 PM, Emmanuel Dreux wrote: > I see 2 points in your thread: > 1. inetOrgPerson often do not have uids [...] =3D> LDAP directories do=20 > not (generally) provide immutable ids. > =3D> You can allocate uniqueIDs in your SCIM implementation and maintain = a mapping table between your LDAP objects and SCIM Identifiers. > =3D> This also simplifies group membership and roles synchronization. > > 2. Schema: The SCIM default schemas are extensible and you can easily imp= lement yours. > Personal feedback from a real experience. Today: > a. We synchronize LDAP organizational units with google and postini. > b. We allocate licences during provisioning of Office 365. > c. We sync public keys with a SAAS provider for specific needs. > > In a "SCIM" world, for each of these scenario, the provider would have to= implement a specific schema. > Said differently, today, if we want to provision Salesforce, Google, Drop= box, office365,etc., we have to learn and integrate their heterogeneous ap= is. > Tomorrow, in a SCIM world, we'll have to integrate as many proprietary sc= hemas as we would have providers. > What's the difference, is it more practicable? > > In parallal, Microsoft has implemented his LDAP restful apis (see phil=20 > comments). It is very convenient to use and entirely fits LDAP=20 > scenarii (schema :=20 > http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspx) > In parallal, we've also discovered FOAF and RDF. This is, according to us= , the most extensible solution: a unique and universal schemas, transparent= ly extensible for everybody (compared to LDAP and OIDS definitions, and com= pared to SCIM and the need to define your own classes when you need additio= nal attributes). > > I'm really afraid that if we have 100 SAAS providers, we'll endup with 10= 0 proprietary schemas. Please send me your comments on this. > > -- > Cordialement / Regards, > Emmanuel Dreux > http://www.cloudiway.com > Tel: +33 4 26 78 17 58 > Mobile: +33 6 47 81 26 70 > skype: Emmanuel.Dreux > > -----Message d'origine----- > De : Patrick Radtke [mailto:pradtke@stanford.edu] Envoy=E9 : mardi 20=20 > novembre 2012 19:56 =C0 : scim@ietf.org Objet : [scim] SCIM as Cloud=20 > Directory API > > We've (internally) been discussing a need for a read only Web API for our= directory servers. I've been reading Phil Hunt's scim-directory draft and = had some questions about the mapping inetOrgPerson to User, but first I'll = describe some of the issues that make it impractical for us to map inetOrgP= erson to User. > > In our directory, inetOrgPerson often do not have uids. These are often i= ncoming students or affiliates that have not yet created accounts and that = we'll need to make available through the Web API. In this case we wouldn't= have a valid SCIM userName for these Users and couldn't expose them as a v= alid User resource. > > Our inetOrgPerson entries frequently have multiple names (e.g. former las= tnames, Anglicized first names, etc), and we couldn't return the additional= names in a current User resource. Similar issues arise for any multi-value= d LDAP attribute that map to single value User or Enterprise User attribute= s (organization, department, etc). Our inetOrgPerson may, at some point, be= allowed multiple uids, etc. > > Is our use case missing the point of the draft? > Is the intent of the draft to be a quickstart in providing an LDAP backed= SCIM endpoint, rather then a 'Cloud Directory'? > In a 'Cloud Directory' future, would there be new standard Resources and = Attributes that roughly correspond to existing LDAP ObjectClasses (e.g. > an Organization resources to map organizationalUnit)? Or would organizati= ons initially define their own ( e.g. suOrganization, eduPerson, etc)? > > thanks for any answers or crystal ball gazing, > > -Patrick > > > > > > From prvs=1678082495=erik.wahlstrom@nexussafe.com Tue Nov 27 06:07:56 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B299A21F850E for ; Tue, 27 Nov 2012 06:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SUfpRQKz+hI for ; Tue, 27 Nov 2012 06:07:55 -0800 (PST) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 34AA521F8456 for ; Tue, 27 Nov 2012 06:07:54 -0800 (PST) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.1.421.2; Tue, 27 Nov 2012 15:07:47 +0100 Received: from MARVMAILDB.technxs.com ([fe80::95d1:b13:6f90:bdad]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Tue, 27 Nov 2012 15:07:48 +0100 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Emmanuel Dreux Thread-Topic: [scim] SCIM as Cloud Directory API Thread-Index: AQHNx1C7bl7eEqMfGU+e/2uUf4ah5JfzN7kAgAkb6oCAAA01gIABUOkA Date: Tue, 27 Nov 2012 14:07:47 +0000 Message-ID: <0512D30E-391C-4DC5-A59D-8AF55B5CEB9D@nexussafe.com> References: <50ABD250.5010307@stanford.edu> <50B3A37F.3060900@stanford.edu> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.77] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "scim@ietf.org" , Patrick Radtke Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 14:07:56 -0000 Hi, Why isn't schema discovery and some well crafted code that adopts from it i= t enough for the scenarios described? It sounds from your description that = you use SCIM internally but call the proprietary/heterogeneous API:s using = different methods and schemas. If you would use FOAF wouldn't you be forced= to parse that especially to depending on where you send the data? I also think that there is a finite numbers of extension that would exist a= nd that we could handle them in the way vCard handles extensions. The probl= em with having just a bucket to add attributes the schema quickly looses it= 's value. / Erik On Nov 26, 2012, at 7:01 PM, Emmanuel Dreux wrote: > If you look at the 2 main providers for online messaging systems, you wil= l notice that the core SCIM schema is not sufficient: >=20 > - Google syncs AD organizational Unit to Google Organizations =3D Need fo= r Extended schema > - Office 365 needs to assign specific licences =3D Extended schema. >=20 > In fact, for all the SAAS providers that we sync, the core schema has nev= er been sufficient. For example, > - We provision RunMyProcess: they have a notion of roles and entities, (= =3D 2 distinct level of roles). > - We are plugging a new SAAS provider with which we need to sync public k= eys (not the full certificate handled by SCIM). > Etc... Etc... >=20 > In fact, we have noticed that all of our SAAS partners have particulariti= es and if we want to sync them through SCIM, we have to build a proprietary= schema for each of them, reason why we're asking the possibility to extend= more simply the core schema (add attributes without having to create a sep= arate schema). >=20 > (Finally we have noticed that FOAF is THE flexible and evolutive identity= schema that would 100% address all the needs of identity management, but i= f you allow to add attributes to the core SCIM schema, it would also be fin= e...) >=20 >=20 > -- > Cordialement / Regards, > Emmanuel Dreux > http://www.cloudiway.com > Tel: +33 4 26 78 17 58 > Mobile: +33 6 47 81 26 70 > skype: Emmanuel.Dreux >=20 > -----Message d'origine----- > De : Patrick Radtke [mailto:pradtke@stanford.edu]=20 > Envoy=E9 : lundi 26 novembre 2012 18:15 > =C0 : Emmanuel Dreux > Cc : scim@ietf.org > Objet : Re: [scim] SCIM as Cloud Directory API >=20 > Thanks for the feedback Emmanuel, and the pointer to the Microsoft Graph = API - it is interesting to read their approach. >=20 > As for your point on "100 SAAS providers and 100 proprietary schemas" I s= uspect that a SAAS provider would not require more than the core schemas fo= r basic provisioning, and the proprietary schemas would come in to play for= SAAS specific settings (data visibility, privacy settings, access controls= , in app 'theme' selection, etc) that are somewhat tangential to provisioni= ng but are linked to a user's account.=20 > I think the proprietary schema would provided an enhanced experience but = would not be required for provisioning. >=20 > -Patrick >=20 >=20 >=20 > On 11/20/12 2:08 PM, Emmanuel Dreux wrote: >> I see 2 points in your thread: >> 1. inetOrgPerson often do not have uids [...] =3D> LDAP directories do=20 >> not (generally) provide immutable ids. >> =3D> You can allocate uniqueIDs in your SCIM implementation and maintain= a mapping table between your LDAP objects and SCIM Identifiers. >> =3D> This also simplifies group membership and roles synchronization. >>=20 >> 2. Schema: The SCIM default schemas are extensible and you can easily im= plement yours. >> Personal feedback from a real experience. Today: >> a. We synchronize LDAP organizational units with google and postini. >> b. We allocate licences during provisioning of Office 365. >> c. We sync public keys with a SAAS provider for specific needs. >>=20 >> In a "SCIM" world, for each of these scenario, the provider would have t= o implement a specific schema. >> Said differently, today, if we want to provision Salesforce, Google, Dro= pbox, office365,etc., we have to learn and integrate their heterogeneous a= pis. >> Tomorrow, in a SCIM world, we'll have to integrate as many proprietary s= chemas as we would have providers. >> What's the difference, is it more practicable? >>=20 >> In parallal, Microsoft has implemented his LDAP restful apis (see phil=20 >> comments). It is very convenient to use and entirely fits LDAP=20 >> scenarii (schema :=20 >> http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspx) >> In parallal, we've also discovered FOAF and RDF. This is, according to u= s, the most extensible solution: a unique and universal schemas, transparen= tly extensible for everybody (compared to LDAP and OIDS definitions, and co= mpared to SCIM and the need to define your own classes when you need additi= onal attributes). >>=20 >> I'm really afraid that if we have 100 SAAS providers, we'll endup with 1= 00 proprietary schemas. Please send me your comments on this. >>=20 >> -- >> Cordialement / Regards, >> Emmanuel Dreux >> http://www.cloudiway.com >> Tel: +33 4 26 78 17 58 >> Mobile: +33 6 47 81 26 70 >> skype: Emmanuel.Dreux >>=20 >> -----Message d'origine----- >> De : Patrick Radtke [mailto:pradtke@stanford.edu] Envoy=E9 : mardi 20=20 >> novembre 2012 19:56 =C0 : scim@ietf.org Objet : [scim] SCIM as Cloud=20 >> Directory API >>=20 >> We've (internally) been discussing a need for a read only Web API for ou= r directory servers. I've been reading Phil Hunt's scim-directory draft and= had some questions about the mapping inetOrgPerson to User, but first I'll= describe some of the issues that make it impractical for us to map inetOrg= Person to User. >>=20 >> In our directory, inetOrgPerson often do not have uids. These are often = incoming students or affiliates that have not yet created accounts and that= we'll need to make available through the Web API. In this case we wouldn'= t have a valid SCIM userName for these Users and couldn't expose them as a = valid User resource. >>=20 >> Our inetOrgPerson entries frequently have multiple names (e.g. former la= stnames, Anglicized first names, etc), and we couldn't return the additiona= l names in a current User resource. Similar issues arise for any multi-valu= ed LDAP attribute that map to single value User or Enterprise User attribut= es (organization, department, etc). Our inetOrgPerson may, at some point, b= e allowed multiple uids, etc. >>=20 >> Is our use case missing the point of the draft? >> Is the intent of the draft to be a quickstart in providing an LDAP backe= d SCIM endpoint, rather then a 'Cloud Directory'? >> In a 'Cloud Directory' future, would there be new standard Resources and= Attributes that roughly correspond to existing LDAP ObjectClasses (e.g. >> an Organization resources to map organizationalUnit)? Or would organizat= ions initially define their own ( e.g. suOrganization, eduPerson, etc)? >>=20 >> thanks for any answers or crystal ball gazing, >>=20 >> -Patrick >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From prvs=06788E109E=erik.wahlstrom@nexussafe.com Tue Nov 27 06:25:31 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E34E21F86F5 for ; Tue, 27 Nov 2012 06:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSMz7Qrzrs9b for ; Tue, 27 Nov 2012 06:25:30 -0800 (PST) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5B48D21F85C5 for ; Tue, 27 Nov 2012 06:25:30 -0800 (PST) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.1.421.2; Tue, 27 Nov 2012 15:25:23 +0100 Received: from MARVMAILDB.technxs.com ([fe80::95d1:b13:6f90:bdad]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Tue, 27 Nov 2012 15:25:24 +0100 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Kelly Grizzle Thread-Topic: [scim] Design Team Status Thread-Index: AQHNtikogAbmMhr8CEquejbjNj+ElJfQ4xwAgAD/8gCAAADUAIAAEr6AgAAf5QCAAA9AgIArszeA Date: Tue, 27 Nov 2012 14:25:23 +0000 Message-ID: <25D14F62-0C4B-4962-B3DF-395A4342C805@nexussafe.com> References: <508EB590.6020706@unboundid.com> <508F0A80.40004@unboundid.com> <508F1624.3060205@gmail.com> <508FECD8.7000008@unboundid.com> <508FED8A.5040608@cisco.com> <50901804.2000009@gmail.com> <56C3C758F9D6534CA3778EAA1E0C34373E7F02EA@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34373E7F02EA@BY2PRD0410MB354.namprd04.prod.outlook.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.77] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "scim@ietf.org" , Melinda Shore Subject: Re: [scim] Design Team Status X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 14:25:31 -0000 +1 on keeping uppercase G on the Group resource. / Erik On Oct 30, 2012, at 8:04 PM, Kelly Grizzle wrote: > The nice thing about capital types for the members attribute on the Group= resource is that the type value corresponds to the resource name. In othe= r words, given a group you could traverse the object relationship to the me= mber. Something like this: >=20 > resource =3D GET /Schemas?name eq {member.type} > GET {resource.endpoint}/{member.value} >=20 > Of course, with a lowercase name you could just upper case the first lett= er. To me it is a little more apparent with the upper-case letter. >=20 > On the other hand, this might become a moot point depending on how we add= ress this: "Should the spec define how to create and traverse parent-child = relationships and/or arbitrary relationships, or stay as-is?". >=20 > --Kelly From Chris.Phillips@canarie.ca Tue Nov 27 07:05:52 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E75121F8428 for ; Tue, 27 Nov 2012 07:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRBR2i+NEuMo for ; Tue, 27 Nov 2012 07:05:51 -0800 (PST) Received: from mail.canarie.ca (mail.canarie.ca [IPv6:2001:410:102:3::5]) by ietfa.amsl.com (Postfix) with ESMTP id 83DEE21F8413 for ; Tue, 27 Nov 2012 07:05:51 -0800 (PST) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Tue, 27 Nov 2012 10:05:50 -0500 From: Chris Phillips To: "scim@ietf.org" Date: Tue, 27 Nov 2012 10:05:48 -0500 Thread-Topic: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema Thread-Index: Ac3MsK9M/8wrDQn2SrumLyzpP3g4dg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:05:52 -0000 Hi Anthony, It has always been a challenge to try and capture which attributes should be core and what should exist in the extensions area using an 80/20 style rule. Coupled with complex attribute representation many data constructs/relationships can be encapsulated in the SCIM schema. Can you describe in more depth the comment '...it can be far simpler with better extensibility.' so we can better understand where you see the gaps? Chris. On 12-11-24 11:21 AM, "Anthony Nadalin" wrote: >So the way this question is proposed this does not close the question of >schema or representation, it just says that we won't adopt the vCard >proposal but leave us open to changing existing schema and representation >as I'm not really happy with existing proposal, as I think it can be far >simpler with better extensibility. > >-----Original Message----- >From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >Leif Johansson >Sent: Saturday, November 24, 2012 7:28 AM >To: scim@ietf.org >Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate >the vCard model into the schema > >On 11/19/2012 09:07 PM, Bjorn Aannestad wrote: >> Hi all, >> >> Based on the discussions in Atlanta and the rough consensus sampling >> there, I'd like to propose that we close the vCard adoption question >> by resolving to NOT adopt the vCard attribute schema, nor its JSON >> representation. >> >So far this sounds like pretty solid consensus but I'd like to give the >WG a _little_ more time collecting +1/-1's since there were a few people >at the mic in ATL if not arguing for vCard, at least being very much on >the fence. > >By a little more time I mean at least a week(ish) since we're in the >middle of a major US holiday. > > Cheers Leif >_______________________________________________ >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 edreux@cloudiway.com Tue Nov 27 13:56:13 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF1B21F85A4 for ; Tue, 27 Nov 2012 13:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFVJjGjs4-AC for ; Tue, 27 Nov 2012 13:56:11 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id DF11D21F859D for ; Tue, 27 Nov 2012 13:56:10 -0800 (PST) Received: from mail141-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Nov 2012 21:56:09 +0000 Received: from mail141-ch1 (localhost [127.0.0.1]) by mail141-ch1-R.bigfish.com (Postfix) with ESMTP id AC09C4001DC; Tue, 27 Nov 2012 21:56:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT004.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -76 X-BigFish: PS-76(zzbb2dI98dI9371Ic89bh1432I15caKJ1447Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh186Mz2fh2a8h668h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h) Received-SPF: pass (mail141-ch1: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT004.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail141-ch1 (localhost.localdomain [127.0.0.1]) by mail141-ch1 (MessageSwitch) id 1354053366211353_3712; Tue, 27 Nov 2012 21:56:06 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail141-ch1.bigfish.com (Postfix) with ESMTP id 2790F1A003F; Tue, 27 Nov 2012 21:56:06 +0000 (UTC) Received: from AMXPRD0610HT004.eurprd06.prod.outlook.com (157.56.248.213) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Nov 2012 21:56:04 +0000 Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.1.210]) by AMXPRD0610HT004.eurprd06.prod.outlook.com ([10.255.58.39]) with mapi id 14.16.0239.002; Tue, 27 Nov 2012 21:56:02 +0000 From: Emmanuel Dreux To: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= Thread-Topic: [scim] SCIM as Cloud Directory API Thread-Index: AQHNx1nLS2fYCHWHWEirnAgw4JfIjJfzOJMwgAkrwYCAAAoLMIABVBWAgACCzwA= Date: Tue, 27 Nov 2012 21:56:01 +0000 Message-ID: References: <50ABD250.5010307@stanford.edu> <50B3A37F.3060900@stanford.edu> <0512D30E-391C-4DC5-A59D-8AF55B5CEB9D@nexussafe.com> In-Reply-To: <0512D30E-391C-4DC5-A59D-8AF55B5CEB9D@nexussafe.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.214.4.228] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Cc: "scim@ietf.org" , Patrick Radtke Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 21:56:13 -0000 If Salesforce adopts SCIM, how do you provision it? SCIM schema is ko for i= t. They will have to create an extended schema (currency, division, etc...) If Google adopts SCIM, how do you provision it? SCIM schema is ko for it. They will have to create an extended schema. ( Organizational units) If Office 365 adopts SCIM, how do you provision it? SCIM schema is ko for i= t. They will have to create an extended schema. ( pictures as jpeg not as html= link, licences, etc...) Etc... I'm just trying to prove (and hope to have proven that n providers =3D n sc= hema). Is it what we want?=20 Or could we allow the root core schema to be extensible for more flexibilit= y (and simplicity?). The format JSON/XML/FOAF/VCARD or whatever is another story, we have fully = understood his value but I will not try to convince this working group as i= t is not a very easy and accessible technology. -- Cordialement / Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux -----Message d'origine----- De=A0: Erik Wahlstr=F6m [mailto:erik.wahlstrom@nexussafe.com]=20 Envoy=E9=A0: mardi 27 novembre 2012 15:08 =C0=A0: Emmanuel Dreux Cc=A0: scim@ietf.org; Patrick Radtke Objet=A0: Re: [scim] SCIM as Cloud Directory API Hi, Why isn't schema discovery and some well crafted code that adopts from it i= t enough for the scenarios described? It sounds from your description that = you use SCIM internally but call the proprietary/heterogeneous API:s using = different methods and schemas. If you would use FOAF wouldn't you be forced= to parse that especially to depending on where you send the data? I also think that there is a finite numbers of extension that would exist a= nd that we could handle them in the way vCard handles extensions. The probl= em with having just a bucket to add attributes the schema quickly looses it= 's value. / Erik On Nov 26, 2012, at 7:01 PM, Emmanuel Dreux wrote: > If you look at the 2 main providers for online messaging systems, you wil= l notice that the core SCIM schema is not sufficient: >=20 > - Google syncs AD organizational Unit to Google Organizations =3D Need=20 > for Extended schema > - Office 365 needs to assign specific licences =3D Extended schema. >=20 > In fact, for all the SAAS providers that we sync, the core schema has=20 > never been sufficient. For example, > - We provision RunMyProcess: they have a notion of roles and entities, (= =3D 2 distinct level of roles). > - We are plugging a new SAAS provider with which we need to sync public k= eys (not the full certificate handled by SCIM). > Etc... Etc... >=20 > In fact, we have noticed that all of our SAAS partners have particulariti= es and if we want to sync them through SCIM, we have to build a proprietary= schema for each of them, reason why we're asking the possibility to extend= more simply the core schema (add attributes without having to create a sep= arate schema). >=20 > (Finally we have noticed that FOAF is THE flexible and evolutive=20 > identity schema that would 100% address all the needs of identity=20 > management, but if you allow to add attributes to the core SCIM=20 > schema, it would also be fine...) >=20 >=20 > -- > Cordialement / Regards, > Emmanuel Dreux > http://www.cloudiway.com > Tel: +33 4 26 78 17 58 > Mobile: +33 6 47 81 26 70 > skype: Emmanuel.Dreux >=20 > -----Message d'origine----- > De : Patrick Radtke [mailto:pradtke@stanford.edu] Envoy=E9 : lundi 26=20 > novembre 2012 18:15 =C0 : Emmanuel Dreux Cc : scim@ietf.org Objet : Re:=20 > [scim] SCIM as Cloud Directory API >=20 > Thanks for the feedback Emmanuel, and the pointer to the Microsoft Graph = API - it is interesting to read their approach. >=20 > As for your point on "100 SAAS providers and 100 proprietary schemas" I s= uspect that a SAAS provider would not require more than the core schemas fo= r basic provisioning, and the proprietary schemas would come in to play for= SAAS specific settings (data visibility, privacy settings, access controls= , in app 'theme' selection, etc) that are somewhat tangential to provisioni= ng but are linked to a user's account.=20 > I think the proprietary schema would provided an enhanced experience but = would not be required for provisioning. >=20 > -Patrick >=20 >=20 >=20 > On 11/20/12 2:08 PM, Emmanuel Dreux wrote: >> I see 2 points in your thread: >> 1. inetOrgPerson often do not have uids [...] =3D> LDAP directories do=20 >> not (generally) provide immutable ids. >> =3D> You can allocate uniqueIDs in your SCIM implementation and maintain= a mapping table between your LDAP objects and SCIM Identifiers. >> =3D> This also simplifies group membership and roles synchronization. >>=20 >> 2. Schema: The SCIM default schemas are extensible and you can easily im= plement yours. >> Personal feedback from a real experience. Today: >> a. We synchronize LDAP organizational units with google and postini. >> b. We allocate licences during provisioning of Office 365. >> c. We sync public keys with a SAAS provider for specific needs. >>=20 >> In a "SCIM" world, for each of these scenario, the provider would have t= o implement a specific schema. >> Said differently, today, if we want to provision Salesforce, Google, Dro= pbox, office365,etc., we have to learn and integrate their heterogeneous a= pis. >> Tomorrow, in a SCIM world, we'll have to integrate as many proprietary s= chemas as we would have providers. >> What's the difference, is it more practicable? >>=20 >> In parallal, Microsoft has implemented his LDAP restful apis (see=20 >> phil comments). It is very convenient to use and entirely fits LDAP=20 >> scenarii (schema : >> http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspx) >> In parallal, we've also discovered FOAF and RDF. This is, according to u= s, the most extensible solution: a unique and universal schemas, transparen= tly extensible for everybody (compared to LDAP and OIDS definitions, and co= mpared to SCIM and the need to define your own classes when you need additi= onal attributes). >>=20 >> I'm really afraid that if we have 100 SAAS providers, we'll endup with 1= 00 proprietary schemas. Please send me your comments on this. >>=20 >> -- >> Cordialement / Regards, >> Emmanuel Dreux >> http://www.cloudiway.com >> Tel: +33 4 26 78 17 58 >> Mobile: +33 6 47 81 26 70 >> skype: Emmanuel.Dreux >>=20 >> -----Message d'origine----- >> De : Patrick Radtke [mailto:pradtke@stanford.edu] Envoy=E9 : mardi 20=20 >> novembre 2012 19:56 =C0 : scim@ietf.org Objet : [scim] SCIM as Cloud=20 >> Directory API >>=20 >> We've (internally) been discussing a need for a read only Web API for ou= r directory servers. I've been reading Phil Hunt's scim-directory draft and= had some questions about the mapping inetOrgPerson to User, but first I'll= describe some of the issues that make it impractical for us to map inetOrg= Person to User. >>=20 >> In our directory, inetOrgPerson often do not have uids. These are often = incoming students or affiliates that have not yet created accounts and that= we'll need to make available through the Web API. In this case we wouldn'= t have a valid SCIM userName for these Users and couldn't expose them as a = valid User resource. >>=20 >> Our inetOrgPerson entries frequently have multiple names (e.g. former la= stnames, Anglicized first names, etc), and we couldn't return the additiona= l names in a current User resource. Similar issues arise for any multi-valu= ed LDAP attribute that map to single value User or Enterprise User attribut= es (organization, department, etc). Our inetOrgPerson may, at some point, b= e allowed multiple uids, etc. >>=20 >> Is our use case missing the point of the draft? >> Is the intent of the draft to be a quickstart in providing an LDAP backe= d SCIM endpoint, rather then a 'Cloud Directory'? >> In a 'Cloud Directory' future, would there be new standard Resources and= Attributes that roughly correspond to existing LDAP ObjectClasses (e.g. >> an Organization resources to map organizationalUnit)? Or would organizat= ions initially define their own ( e.g. suOrganization, eduPerson, etc)? >>=20 >> thanks for any answers or crystal ball gazing, >>=20 >> -Patrick >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From tonynad@microsoft.com Tue Nov 27 14:03:15 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AB821F85A5 for ; Tue, 27 Nov 2012 14:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.517 X-Spam-Level: X-Spam-Status: No, score=-1.517 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxPwHyaCFkzM for ; Tue, 27 Nov 2012 14:03:14 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9801521F8559 for ; Tue, 27 Nov 2012 14:03:13 -0800 (PST) Received: from mail47-co9-R.bigfish.com (10.236.132.232) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Nov 2012 22:03:13 +0000 Received: from mail47-co9 (localhost [127.0.0.1]) by mail47-co9-R.bigfish.com (Postfix) with ESMTP id 064F1C801B8 for ; Tue, 27 Nov 2012 22:03:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -80 X-BigFish: VS-80(zzbb2dI98dI9371Ic89bhd6eah542M1432I15caKJ1447Izz1de0h1202h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dh186Mz2fh2a8h683h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h9a9j1155h) Received-SPF: pass (mail47-co9: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail47-co9 (localhost.localdomain [127.0.0.1]) by mail47-co9 (MessageSwitch) id 1354053790944538_4026; Tue, 27 Nov 2012 22:03:10 +0000 (UTC) Received: from CO9EHSMHS016.bigfish.com (unknown [10.236.132.230]) by mail47-co9.bigfish.com (Postfix) with ESMTP id E43C2700049 for ; Tue, 27 Nov 2012 22:03:10 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by CO9EHSMHS016.bigfish.com (10.236.130.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Nov 2012 22:03:06 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 27 Nov 2012 22:03:06 +0000 Received: from mail80-am1-R.bigfish.com (10.3.201.241) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Nov 2012 22:03:03 +0000 Received: from mail80-am1 (localhost [127.0.0.1]) by mail80-am1-R.bigfish.com (Postfix) with ESMTP id 6422C4600F7 for ; Tue, 27 Nov 2012 22:03:03 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(299001);DIR:OUT;LANG:en; Received: from mail80-am1 (localhost.localdomain [127.0.0.1]) by mail80-am1 (MessageSwitch) id 1354053781796151_26105; Tue, 27 Nov 2012 22:03:01 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.234]) by mail80-am1.bigfish.com (Postfix) with ESMTP id B4430E0103; Tue, 27 Nov 2012 22:03:01 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Nov 2012 22:03:01 +0000 Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.239.5; Tue, 27 Nov 2012 22:03:00 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.545.9; Tue, 27 Nov 2012 22:02:56 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.10.178]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.10.252]) with mapi id 15.00.0545.000; Tue, 27 Nov 2012 22:02:56 +0000 From: Anthony Nadalin To: Emmanuel Dreux , =?iso-8859-1?Q?Erik_Wahlstr=F6m?= Thread-Topic: [scim] SCIM as Cloud Directory API Thread-Index: AQHNx1ERR6tXbHskJkitrxUqhStWqJfzSHwAgAkb6oCAAA01gIABUOqAgACC04CAAAGPUA== Date: Tue, 27 Nov 2012 22:02:56 +0000 Message-ID: <473182aedd034f4f8c38379134f77fd8@BY2PR03MB041.namprd03.prod.outlook.com> References: <50ABD250.5010307@stanford.edu> <50B3A37F.3060900@stanford.edu> <0512D30E-391C-4DC5-A59D-8AF55B5CEB9D@nexussafe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.93.28] x-forefront-prvs: 06780E24F8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%STANFORD.EDU$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CLOUDIWAY.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NEXUSSAFE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "scim@ietf.org" , Patrick Radtke Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 22:03:15 -0000 >From the Office365 perspective we would need to be able to specify a schema= or discover a schema at the root, as I think we would get into extensibili= ty issues sooner or later. -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emm= anuel Dreux Sent: Tuesday, November 27, 2012 1:56 PM To: Erik Wahlstr=F6m Cc: scim@ietf.org; Patrick Radtke Subject: Re: [scim] SCIM as Cloud Directory API If Salesforce adopts SCIM, how do you provision it? SCIM schema is ko for i= t. They will have to create an extended schema (currency, division, etc...) If Google adopts SCIM, how do you provision it? SCIM schema is ko for it. They will have to create an extended schema. ( Organizational units) If Office 365 adopts SCIM, how do you provision it? SCIM schema is ko for i= t. They will have to create an extended schema. ( pictures as jpeg not as html= link, licences, etc...) Etc... I'm just trying to prove (and hope to have proven that n providers =3D n sc= hema). Is it what we want?=20 Or could we allow the root core schema to be extensible for more flexibilit= y (and simplicity?). The format JSON/XML/FOAF/VCARD or whatever is another story, we have fully = understood his value but I will not try to convince this working group as i= t is not a very easy and accessible technology. -- Cordialement / Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux -----Message d'origine----- De=A0: Erik Wahlstr=F6m [mailto:erik.wahlstrom@nexussafe.com] Envoy=E9=A0: mardi 27 novembre 2012 15:08 =C0=A0: Emmanuel Dreux Cc=A0: scim@ietf.org; Patrick Radtke Objet=A0: Re: [scim] SCIM as Cloud Directory API Hi, Why isn't schema discovery and some well crafted code that adopts from it i= t enough for the scenarios described? It sounds from your description that = you use SCIM internally but call the proprietary/heterogeneous API:s using = different methods and schemas. If you would use FOAF wouldn't you be forced= to parse that especially to depending on where you send the data? I also think that there is a finite numbers of extension that would exist a= nd that we could handle them in the way vCard handles extensions. The probl= em with having just a bucket to add attributes the schema quickly looses it= 's value. / Erik On Nov 26, 2012, at 7:01 PM, Emmanuel Dreux wrote: > If you look at the 2 main providers for online messaging systems, you wil= l notice that the core SCIM schema is not sufficient: >=20 > - Google syncs AD organizational Unit to Google Organizations =3D Need=20 > for Extended schema > - Office 365 needs to assign specific licences =3D Extended schema. >=20 > In fact, for all the SAAS providers that we sync, the core schema has=20 > never been sufficient. For example, > - We provision RunMyProcess: they have a notion of roles and entities, (= =3D 2 distinct level of roles). > - We are plugging a new SAAS provider with which we need to sync public k= eys (not the full certificate handled by SCIM). > Etc... Etc... >=20 > In fact, we have noticed that all of our SAAS partners have particulariti= es and if we want to sync them through SCIM, we have to build a proprietary= schema for each of them, reason why we're asking the possibility to extend= more simply the core schema (add attributes without having to create a sep= arate schema). >=20 > (Finally we have noticed that FOAF is THE flexible and evolutive=20 > identity schema that would 100% address all the needs of identity=20 > management, but if you allow to add attributes to the core SCIM=20 > schema, it would also be fine...) >=20 >=20 > -- > Cordialement / Regards, > Emmanuel Dreux > http://www.cloudiway.com > Tel: +33 4 26 78 17 58 > Mobile: +33 6 47 81 26 70 > skype: Emmanuel.Dreux >=20 > -----Message d'origine----- > De : Patrick Radtke [mailto:pradtke@stanford.edu] Envoy=E9 : lundi 26=20 > novembre 2012 18:15 =C0 : Emmanuel Dreux Cc : scim@ietf.org Objet : Re: > [scim] SCIM as Cloud Directory API >=20 > Thanks for the feedback Emmanuel, and the pointer to the Microsoft Graph = API - it is interesting to read their approach. >=20 > As for your point on "100 SAAS providers and 100 proprietary schemas" I s= uspect that a SAAS provider would not require more than the core schemas fo= r basic provisioning, and the proprietary schemas would come in to play for= SAAS specific settings (data visibility, privacy settings, access controls= , in app 'theme' selection, etc) that are somewhat tangential to provisioni= ng but are linked to a user's account.=20 > I think the proprietary schema would provided an enhanced experience but = would not be required for provisioning. >=20 > -Patrick >=20 >=20 >=20 > On 11/20/12 2:08 PM, Emmanuel Dreux wrote: >> I see 2 points in your thread: >> 1. inetOrgPerson often do not have uids [...] =3D> LDAP directories do=20 >> not (generally) provide immutable ids. >> =3D> You can allocate uniqueIDs in your SCIM implementation and maintain= a mapping table between your LDAP objects and SCIM Identifiers. >> =3D> This also simplifies group membership and roles synchronization. >>=20 >> 2. Schema: The SCIM default schemas are extensible and you can easily im= plement yours. >> Personal feedback from a real experience. Today: >> a. We synchronize LDAP organizational units with google and postini. >> b. We allocate licences during provisioning of Office 365. >> c. We sync public keys with a SAAS provider for specific needs. >>=20 >> In a "SCIM" world, for each of these scenario, the provider would have t= o implement a specific schema. >> Said differently, today, if we want to provision Salesforce, Google, Dro= pbox, office365,etc., we have to learn and integrate their heterogeneous a= pis. >> Tomorrow, in a SCIM world, we'll have to integrate as many proprietary s= chemas as we would have providers. >> What's the difference, is it more practicable? >>=20 >> In parallal, Microsoft has implemented his LDAP restful apis (see=20 >> phil comments). It is very convenient to use and entirely fits LDAP=20 >> scenarii (schema : >> http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspx) >> In parallal, we've also discovered FOAF and RDF. This is, according to u= s, the most extensible solution: a unique and universal schemas, transparen= tly extensible for everybody (compared to LDAP and OIDS definitions, and co= mpared to SCIM and the need to define your own classes when you need additi= onal attributes). >>=20 >> I'm really afraid that if we have 100 SAAS providers, we'll endup with 1= 00 proprietary schemas. Please send me your comments on this. >>=20 >> -- >> Cordialement / Regards, >> Emmanuel Dreux >> http://www.cloudiway.com >> Tel: +33 4 26 78 17 58 >> Mobile: +33 6 47 81 26 70 >> skype: Emmanuel.Dreux >>=20 >> -----Message d'origine----- >> De : Patrick Radtke [mailto:pradtke@stanford.edu] Envoy=E9 : mardi 20=20 >> novembre 2012 19:56 =C0 : scim@ietf.org Objet : [scim] SCIM as Cloud=20 >> Directory API >>=20 >> We've (internally) been discussing a need for a read only Web API for ou= r directory servers. I've been reading Phil Hunt's scim-directory draft and= had some questions about the mapping inetOrgPerson to User, but first I'll= describe some of the issues that make it impractical for us to map inetOrg= Person to User. >>=20 >> In our directory, inetOrgPerson often do not have uids. These are often = incoming students or affiliates that have not yet created accounts and that= we'll need to make available through the Web API. In this case we wouldn'= t have a valid SCIM userName for these Users and couldn't expose them as a = valid User resource. >>=20 >> Our inetOrgPerson entries frequently have multiple names (e.g. former la= stnames, Anglicized first names, etc), and we couldn't return the additiona= l names in a current User resource. Similar issues arise for any multi-valu= ed LDAP attribute that map to single value User or Enterprise User attribut= es (organization, department, etc). Our inetOrgPerson may, at some point, b= e allowed multiple uids, etc. >>=20 >> Is our use case missing the point of the draft? >> Is the intent of the draft to be a quickstart in providing an LDAP backe= d SCIM endpoint, rather then a 'Cloud Directory'? >> In a 'Cloud Directory' future, would there be new standard Resources and= Attributes that roughly correspond to existing LDAP ObjectClasses (e.g. >> an Organization resources to map organizationalUnit)? Or would organizat= ions initially define their own ( e.g. suOrganization, eduPerson, etc)? >>=20 >> thanks for any answers or crystal ball gazing, >>=20 >> -Patrick >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From stpeter@stpeter.im Tue Nov 27 21:44:54 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCD61F0C5F for ; Tue, 27 Nov 2012 21:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, J_BACKHAIR_45=1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeP2Y0MXyStH for ; Tue, 27 Nov 2012 21:44:53 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4091F0C82 for ; Tue, 27 Nov 2012 21:44:53 -0800 (PST) Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 032BE40092; Tue, 27 Nov 2012 22:49:47 -0700 (MST) Message-ID: <50B5A4D4.5030507@stpeter.im> Date: Tue, 27 Nov 2012 22:44:52 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Leif Johansson References: <50AA9168.2040706@unboundid.com> <50B0E794.5060808@mnt.se> In-Reply-To: <50B0E794.5060808@mnt.se> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] Proposal to resolve as "wontfix": #19: Incorporate the vCard model into the schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 05:44:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/24/12 8:28 AM, Leif Johansson wrote: > On 11/19/2012 09:07 PM, Bjorn Aannestad wrote: >> Hi all, >> >> Based on the discussions in Atlanta and the rough consensus >> sampling there, I'd like to propose that we close the vCard >> adoption question by resolving to NOT adopt the vCard attribute >> schema, nor its JSON representation. >> > So far this sounds like pretty solid consensus but I'd like to give > the WG a _little_ more time collecting +1/-1's since there were a > few people at the mic in ATL if not arguing for vCard, at least > being very much on the fence. > > By a little more time I mean at least a week(ish) since we're in > the middle of a major US holiday. Hej Leif, I was one of those people at the mic. My sense is still that, if we were designing from scratch, it might sense to look seriously at vCard, but that at this point there's really no deeply compelling reason (e.g., code reuse or interoperability) to change the format used in SCIM. However, I reiterate that it's really important for this WG to "get it right" with regard to the extensibility model, and secondarily with regard to registration of extensions. I see the SCIM<=>vCArd mapping as tertiary but still of interest. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC1pNQACgkQNL8k5A2w/vx9OgCfVxDV8mj/ZwR2KtIFM1F+ws0Y 2o8AoO7XE3ZR6pyG7oyTUeEsUV2S9eO9 =txI9 -----END PGP SIGNATURE----- From prvs=5679411F26=erik.wahlstrom@nexussafe.com Wed Nov 28 07:12:49 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43B821F886F for ; Wed, 28 Nov 2012 07:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oALiL94id8Po for ; Wed, 28 Nov 2012 07:12:48 -0800 (PST) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2890521F885C for ; Wed, 28 Nov 2012 07:12:47 -0800 (PST) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.1.421.2; Wed, 28 Nov 2012 16:12:44 +0100 Received: from MARVMAILDB.technxs.com ([fe80::95d1:b13:6f90:bdad]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Wed, 28 Nov 2012 16:12:30 +0100 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Emmanuel Dreux Thread-Topic: [scim] SCIM as Cloud Directory API Thread-Index: AQHNx1C7bl7eEqMfGU+e/2uUf4ah5JfzN7kAgAkb6oCAAA01gIABUOkAgACC1ICAASGUAA== Date: Wed, 28 Nov 2012 15:12:29 +0000 Message-ID: References: <50ABD250.5010307@stanford.edu> <50B3A37F.3060900@stanford.edu> <0512D30E-391C-4DC5-A59D-8AF55B5CEB9D@nexussafe.com> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.12] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "scim@ietf.org" , Patrick Radtke Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:12:49 -0000 The current schema is extensible. You can define new resource types and add= attributes to an existing one, that's rather extensible and flexible to me= :) Some examples of the type of changes you would like to have would be great = to help understand what types of changes to the schema spec you need. It do= esn't sound like we are talking about resource relations here right? Best regards Erik On Nov 27, 2012, at 10:56 PM, Emmanuel Dreux wrote: > If Salesforce adopts SCIM, how do you provision it? SCIM schema is ko for= it. > They will have to create an extended schema (currency, division, etc...) >=20 > If Google adopts SCIM, how do you provision it? SCIM schema is ko for it. > They will have to create an extended schema. ( Organizational units) >=20 > If Office 365 adopts SCIM, how do you provision it? SCIM schema is ko for= it. > They will have to create an extended schema. ( pictures as jpeg not as ht= ml link, licences, etc...) >=20 > Etc... > I'm just trying to prove (and hope to have proven that n providers =3D n = schema). > Is it what we want?=20 > Or could we allow the root core schema to be extensible for more flexibil= ity (and simplicity?). >=20 > The format JSON/XML/FOAF/VCARD or whatever is another story, we have full= y understood his value but I will not try to convince this working group as= it is not a very easy and accessible technology. >=20 > -- > Cordialement / Regards, > Emmanuel Dreux > http://www.cloudiway.com > Tel: +33 4 26 78 17 58 > Mobile: +33 6 47 81 26 70 > skype: Emmanuel.Dreux >=20 >=20 > -----Message d'origine----- > De : Erik Wahlstr=F6m [mailto:erik.wahlstrom@nexussafe.com]=20 > Envoy=E9 : mardi 27 novembre 2012 15:08 > =C0 : Emmanuel Dreux > Cc : scim@ietf.org; Patrick Radtke > Objet : Re: [scim] SCIM as Cloud Directory API >=20 > Hi, >=20 > Why isn't schema discovery and some well crafted code that adopts from it= it enough for the scenarios described? It sounds from your description tha= t you use SCIM internally but call the proprietary/heterogeneous API:s usin= g different methods and schemas. If you would use FOAF wouldn't you be forc= ed to parse that especially to depending on where you send the data? >=20 > I also think that there is a finite numbers of extension that would exist= and that we could handle them in the way vCard handles extensions. The pro= blem with having just a bucket to add attributes the schema quickly looses = it's value. >=20 > / Erik >=20 >=20 > On Nov 26, 2012, at 7:01 PM, Emmanuel Dreux wrote: >=20 >> If you look at the 2 main providers for online messaging systems, you wi= ll notice that the core SCIM schema is not sufficient: >>=20 >> - Google syncs AD organizational Unit to Google Organizations =3D Need=20 >> for Extended schema >> - Office 365 needs to assign specific licences =3D Extended schema. >>=20 >> In fact, for all the SAAS providers that we sync, the core schema has=20 >> never been sufficient. For example, >> - We provision RunMyProcess: they have a notion of roles and entities, (= =3D 2 distinct level of roles). >> - We are plugging a new SAAS provider with which we need to sync public = keys (not the full certificate handled by SCIM). >> Etc... Etc... >>=20 >> In fact, we have noticed that all of our SAAS partners have particularit= ies and if we want to sync them through SCIM, we have to build a proprietar= y schema for each of them, reason why we're asking the possibility to exten= d more simply the core schema (add attributes without having to create a se= parate schema). >>=20 >> (Finally we have noticed that FOAF is THE flexible and evolutive=20 >> identity schema that would 100% address all the needs of identity=20 >> management, but if you allow to add attributes to the core SCIM=20 >> schema, it would also be fine...) >>=20 >>=20 >> -- >> Cordialement / Regards, >> Emmanuel Dreux >> http://www.cloudiway.com >> Tel: +33 4 26 78 17 58 >> Mobile: +33 6 47 81 26 70 >> skype: Emmanuel.Dreux >>=20 >> -----Message d'origine----- >> De : Patrick Radtke [mailto:pradtke@stanford.edu] Envoy=E9 : lundi 26=20 >> novembre 2012 18:15 =C0 : Emmanuel Dreux Cc : scim@ietf.org Objet : Re:= =20 >> [scim] SCIM as Cloud Directory API >>=20 >> Thanks for the feedback Emmanuel, and the pointer to the Microsoft Graph= API - it is interesting to read their approach. >>=20 >> As for your point on "100 SAAS providers and 100 proprietary schemas" I = suspect that a SAAS provider would not require more than the core schemas f= or basic provisioning, and the proprietary schemas would come in to play fo= r SAAS specific settings (data visibility, privacy settings, access control= s, in app 'theme' selection, etc) that are somewhat tangential to provision= ing but are linked to a user's account.=20 >> I think the proprietary schema would provided an enhanced experience but= would not be required for provisioning. >>=20 >> -Patrick >>=20 >>=20 >>=20 >> On 11/20/12 2:08 PM, Emmanuel Dreux wrote: >>> I see 2 points in your thread: >>> 1. inetOrgPerson often do not have uids [...] =3D> LDAP directories do= =20 >>> not (generally) provide immutable ids. >>> =3D> You can allocate uniqueIDs in your SCIM implementation and maintai= n a mapping table between your LDAP objects and SCIM Identifiers. >>> =3D> This also simplifies group membership and roles synchronization. >>>=20 >>> 2. Schema: The SCIM default schemas are extensible and you can easily i= mplement yours. >>> Personal feedback from a real experience. Today: >>> a. We synchronize LDAP organizational units with google and postini. >>> b. We allocate licences during provisioning of Office 365. >>> c. We sync public keys with a SAAS provider for specific needs. >>>=20 >>> In a "SCIM" world, for each of these scenario, the provider would have = to implement a specific schema. >>> Said differently, today, if we want to provision Salesforce, Google, Dr= opbox, office365,etc., we have to learn and integrate their heterogeneous = apis. >>> Tomorrow, in a SCIM world, we'll have to integrate as many proprietary = schemas as we would have providers. >>> What's the difference, is it more practicable? >>>=20 >>> In parallal, Microsoft has implemented his LDAP restful apis (see=20 >>> phil comments). It is very convenient to use and entirely fits LDAP=20 >>> scenarii (schema : >>> http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspx) >>> In parallal, we've also discovered FOAF and RDF. This is, according to = us, the most extensible solution: a unique and universal schemas, transpare= ntly extensible for everybody (compared to LDAP and OIDS definitions, and c= ompared to SCIM and the need to define your own classes when you need addit= ional attributes). >>>=20 >>> I'm really afraid that if we have 100 SAAS providers, we'll endup with = 100 proprietary schemas. Please send me your comments on this. >>>=20 >>> -- >>> Cordialement / Regards, >>> Emmanuel Dreux >>> http://www.cloudiway.com >>> Tel: +33 4 26 78 17 58 >>> Mobile: +33 6 47 81 26 70 >>> skype: Emmanuel.Dreux >>>=20 >>> -----Message d'origine----- >>> De : Patrick Radtke [mailto:pradtke@stanford.edu] Envoy=E9 : mardi 20=20 >>> novembre 2012 19:56 =C0 : scim@ietf.org Objet : [scim] SCIM as Cloud=20 >>> Directory API >>>=20 >>> We've (internally) been discussing a need for a read only Web API for o= ur directory servers. I've been reading Phil Hunt's scim-directory draft an= d had some questions about the mapping inetOrgPerson to User, but first I'l= l describe some of the issues that make it impractical for us to map inetOr= gPerson to User. >>>=20 >>> In our directory, inetOrgPerson often do not have uids. These are often= incoming students or affiliates that have not yet created accounts and tha= t we'll need to make available through the Web API. In this case we wouldn= 't have a valid SCIM userName for these Users and couldn't expose them as a= valid User resource. >>>=20 >>> Our inetOrgPerson entries frequently have multiple names (e.g. former l= astnames, Anglicized first names, etc), and we couldn't return the addition= al names in a current User resource. Similar issues arise for any multi-val= ued LDAP attribute that map to single value User or Enterprise User attribu= tes (organization, department, etc). Our inetOrgPerson may, at some point, = be allowed multiple uids, etc. >>>=20 >>> Is our use case missing the point of the draft? >>> Is the intent of the draft to be a quickstart in providing an LDAP back= ed SCIM endpoint, rather then a 'Cloud Directory'? >>> In a 'Cloud Directory' future, would there be new standard Resources an= d Attributes that roughly correspond to existing LDAP ObjectClasses (e.g. >>> an Organization resources to map organizationalUnit)? Or would organiza= tions initially define their own ( e.g. suOrganization, eduPerson, etc)? >>>=20 >>> thanks for any answers or crystal ball gazing, >>>=20 >>> -Patrick >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 From edreux@cloudiway.com Wed Nov 28 14:51:06 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3736121F8597 for ; Wed, 28 Nov 2012 14:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gPMa-aiXMho for ; Wed, 28 Nov 2012 14:51:05 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA7221F844D for ; Wed, 28 Nov 2012 14:51:03 -0800 (PST) Received: from mail50-db3-R.bigfish.com (10.3.81.248) by DB3EHSOBE007.bigfish.com (10.3.84.27) with Microsoft SMTP Server id 14.1.225.23; Wed, 28 Nov 2012 22:51:02 +0000 Received: from mail50-db3 (localhost [127.0.0.1]) by mail50-db3-R.bigfish.com (Postfix) with ESMTP id 2D67E480484; Wed, 28 Nov 2012 22:51:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0610HT001.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -80 X-BigFish: PS-80(zzbb2dI98dI9371Ic89bh1432I15caKJ1447Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh186Mz2fh2a8h668h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1155h) Received-SPF: pass (mail50-db3: domain of cloudiway.com designates 157.56.252.53 as permitted sender) client-ip=157.56.252.53; envelope-from=edreux@cloudiway.com; helo=DB3PRD0610HT001.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail50-db3 (localhost.localdomain [127.0.0.1]) by mail50-db3 (MessageSwitch) id 1354143059305104_30561; Wed, 28 Nov 2012 22:50:59 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.246]) by mail50-db3.bigfish.com (Postfix) with ESMTP id 3E4A220008D; Wed, 28 Nov 2012 22:50:59 +0000 (UTC) Received: from DB3PRD0610HT001.eurprd06.prod.outlook.com (157.56.252.53) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 28 Nov 2012 22:50:57 +0000 Received: from DB3PRD0610MB356.eurprd06.prod.outlook.com ([169.254.8.56]) by DB3PRD0610HT001.eurprd06.prod.outlook.com ([10.255.47.36]) with mapi id 14.16.0239.002; Wed, 28 Nov 2012 22:50:56 +0000 From: Emmanuel Dreux To: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= Thread-Topic: [scim] SCIM as Cloud Directory API Thread-Index: AQHNx1nLS2fYCHWHWEirnAgw4JfIjJfzOJMwgAkrwYCAAAoLMIABVBWAgACCzwCAASGZgIAAgBZg Date: Wed, 28 Nov 2012 22:50:56 +0000 Message-ID: References: <50ABD250.5010307@stanford.edu> <50B3A37F.3060900@stanford.edu> <0512D30E-391C-4DC5-A59D-8AF55B5CEB9D@nexussafe.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.27.206.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Cc: "scim@ietf.org" , Patrick Radtke Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:51:06 -0000 Hi Erik, Correct me if I'm wrong, but you would not extend the schema, you would rep= lace it with your own one. The question is (as I didn't cross any yet): can someone post a link to a S= AAS provider (or on premise app) for which the default SCIM schema would be= sufficient to provision (not partially) the identities? Is it then useful to define a schema in SCIM if the schema is not used / ad= opted because not practicable? In one sense, it helps normalize the name of a few attributes, but in other= way, as soon as you have to create your own "user class", you have to rede= fine them and get free to change the name of the attributes (firstname,give= nName,sn, familyname,givenname, etc...). Wouldn't it be fine to force to "derive" your own user "class" from the cor= e user schema? (in a sense really "extend" it). Or, are we allowed to say that any traffic based on rest api, authenticated= with Oauth and exchanging user informations in JSON will be labeled "SCIM"= . (Is Microsoft Azure graph API the first live SCIM implementation?) -- Cordialement / Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux -----Message d'origine----- De=A0: Erik Wahlstr=F6m [mailto:erik.wahlstrom@nexussafe.com]=20 Envoy=E9=A0: mercredi 28 novembre 2012 16:12 =C0=A0: Emmanuel Dreux Cc=A0: scim@ietf.org; Patrick Radtke Objet=A0: Re: [scim] SCIM as Cloud Directory API The current schema is extensible. You can define new resource types and add= attributes to an existing one, that's rather extensible and flexible to me= :) Some examples of the type of changes you would like to have would be great = to help understand what types of changes to the schema spec you need. It do= esn't sound like we are talking about resource relations here right? Best regards Erik On Nov 27, 2012, at 10:56 PM, Emmanuel Dreux wrote: > If Salesforce adopts SCIM, how do you provision it? SCIM schema is ko for= it. > They will have to create an extended schema (currency, division,=20 > etc...) >=20 > If Google adopts SCIM, how do you provision it? SCIM schema is ko for it. > They will have to create an extended schema. ( Organizational units) >=20 > If Office 365 adopts SCIM, how do you provision it? SCIM schema is ko for= it. > They will have to create an extended schema. ( pictures as jpeg not as=20 > html link, licences, etc...) >=20 > Etc... > I'm just trying to prove (and hope to have proven that n providers =3D n = schema). > Is it what we want?=20 > Or could we allow the root core schema to be extensible for more flexibil= ity (and simplicity?). >=20 > The format JSON/XML/FOAF/VCARD or whatever is another story, we have full= y understood his value but I will not try to convince this working group as= it is not a very easy and accessible technology. >=20 > -- > Cordialement / Regards, > Emmanuel Dreux > http://www.cloudiway.com > Tel: +33 4 26 78 17 58 > Mobile: +33 6 47 81 26 70 > skype: Emmanuel.Dreux >=20 >=20 > -----Message d'origine----- > De : Erik Wahlstr=F6m [mailto:erik.wahlstrom@nexussafe.com] > Envoy=E9 : mardi 27 novembre 2012 15:08 > =C0 : Emmanuel Dreux > Cc : scim@ietf.org; Patrick Radtke > Objet : Re: [scim] SCIM as Cloud Directory API >=20 > Hi, >=20 > Why isn't schema discovery and some well crafted code that adopts from it= it enough for the scenarios described? It sounds from your description tha= t you use SCIM internally but call the proprietary/heterogeneous API:s usin= g different methods and schemas. If you would use FOAF wouldn't you be forc= ed to parse that especially to depending on where you send the data? >=20 > I also think that there is a finite numbers of extension that would exist= and that we could handle them in the way vCard handles extensions. The pro= blem with having just a bucket to add attributes the schema quickly looses = it's value. >=20 > / Erik >=20 >=20 > On Nov 26, 2012, at 7:01 PM, Emmanuel Dreux wrote: >=20 >> If you look at the 2 main providers for online messaging systems, you wi= ll notice that the core SCIM schema is not sufficient: >>=20 >> - Google syncs AD organizational Unit to Google Organizations =3D Need=20 >> for Extended schema >> - Office 365 needs to assign specific licences =3D Extended schema. >>=20 >> In fact, for all the SAAS providers that we sync, the core schema has=20 >> never been sufficient. For example, >> - We provision RunMyProcess: they have a notion of roles and entities, (= =3D 2 distinct level of roles). >> - We are plugging a new SAAS provider with which we need to sync public = keys (not the full certificate handled by SCIM). >> Etc... Etc... >>=20 >> In fact, we have noticed that all of our SAAS partners have particularit= ies and if we want to sync them through SCIM, we have to build a proprietar= y schema for each of them, reason why we're asking the possibility to exten= d more simply the core schema (add attributes without having to create a se= parate schema). >>=20 >> (Finally we have noticed that FOAF is THE flexible and evolutive=20 >> identity schema that would 100% address all the needs of identity=20 >> management, but if you allow to add attributes to the core SCIM=20 >> schema, it would also be fine...) >>=20 >>=20 >> -- >> Cordialement / Regards, >> Emmanuel Dreux >> http://www.cloudiway.com >> Tel: +33 4 26 78 17 58 >> Mobile: +33 6 47 81 26 70 >> skype: Emmanuel.Dreux >>=20 >> -----Message d'origine----- >> De : Patrick Radtke [mailto:pradtke@stanford.edu] Envoy=E9 : lundi 26=20 >> novembre 2012 18:15 =C0 : Emmanuel Dreux Cc : scim@ietf.org Objet : Re: >> [scim] SCIM as Cloud Directory API >>=20 >> Thanks for the feedback Emmanuel, and the pointer to the Microsoft Graph= API - it is interesting to read their approach. >>=20 >> As for your point on "100 SAAS providers and 100 proprietary schemas" I = suspect that a SAAS provider would not require more than the core schemas f= or basic provisioning, and the proprietary schemas would come in to play fo= r SAAS specific settings (data visibility, privacy settings, access control= s, in app 'theme' selection, etc) that are somewhat tangential to provision= ing but are linked to a user's account.=20 >> I think the proprietary schema would provided an enhanced experience but= would not be required for provisioning. >>=20 >> -Patrick >>=20 >>=20 >>=20 >> On 11/20/12 2:08 PM, Emmanuel Dreux wrote: >>> I see 2 points in your thread: >>> 1. inetOrgPerson often do not have uids [...] =3D> LDAP directories do= =20 >>> not (generally) provide immutable ids. >>> =3D> You can allocate uniqueIDs in your SCIM implementation and maintai= n a mapping table between your LDAP objects and SCIM Identifiers. >>> =3D> This also simplifies group membership and roles synchronization. >>>=20 >>> 2. Schema: The SCIM default schemas are extensible and you can easily i= mplement yours. >>> Personal feedback from a real experience. Today: >>> a. We synchronize LDAP organizational units with google and postini. >>> b. We allocate licences during provisioning of Office 365. >>> c. We sync public keys with a SAAS provider for specific needs. >>>=20 >>> In a "SCIM" world, for each of these scenario, the provider would have = to implement a specific schema. >>> Said differently, today, if we want to provision Salesforce, Google, Dr= opbox, office365,etc., we have to learn and integrate their heterogeneous = apis. >>> Tomorrow, in a SCIM world, we'll have to integrate as many proprietary = schemas as we would have providers. >>> What's the difference, is it more practicable? >>>=20 >>> In parallal, Microsoft has implemented his LDAP restful apis (see=20 >>> phil comments). It is very convenient to use and entirely fits LDAP=20 >>> scenarii (schema : >>> http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspx) >>> In parallal, we've also discovered FOAF and RDF. This is, according to = us, the most extensible solution: a unique and universal schemas, transpare= ntly extensible for everybody (compared to LDAP and OIDS definitions, and c= ompared to SCIM and the need to define your own classes when you need addit= ional attributes). >>>=20 >>> I'm really afraid that if we have 100 SAAS providers, we'll endup with = 100 proprietary schemas. Please send me your comments on this. >>>=20 >>> -- >>> Cordialement / Regards, >>> Emmanuel Dreux >>> http://www.cloudiway.com >>> Tel: +33 4 26 78 17 58 >>> Mobile: +33 6 47 81 26 70 >>> skype: Emmanuel.Dreux >>>=20 >>> -----Message d'origine----- >>> De : Patrick Radtke [mailto:pradtke@stanford.edu] Envoy=E9 : mardi 20=20 >>> novembre 2012 19:56 =C0 : scim@ietf.org Objet : [scim] SCIM as Cloud=20 >>> Directory API >>>=20 >>> We've (internally) been discussing a need for a read only Web API for o= ur directory servers. I've been reading Phil Hunt's scim-directory draft an= d had some questions about the mapping inetOrgPerson to User, but first I'l= l describe some of the issues that make it impractical for us to map inetOr= gPerson to User. >>>=20 >>> In our directory, inetOrgPerson often do not have uids. These are often= incoming students or affiliates that have not yet created accounts and tha= t we'll need to make available through the Web API. In this case we wouldn= 't have a valid SCIM userName for these Users and couldn't expose them as a= valid User resource. >>>=20 >>> Our inetOrgPerson entries frequently have multiple names (e.g. former l= astnames, Anglicized first names, etc), and we couldn't return the addition= al names in a current User resource. Similar issues arise for any multi-val= ued LDAP attribute that map to single value User or Enterprise User attribu= tes (organization, department, etc). Our inetOrgPerson may, at some point, = be allowed multiple uids, etc. >>>=20 >>> Is our use case missing the point of the draft? >>> Is the intent of the draft to be a quickstart in providing an LDAP back= ed SCIM endpoint, rather then a 'Cloud Directory'? >>> In a 'Cloud Directory' future, would there be new standard Resources an= d Attributes that roughly correspond to existing LDAP ObjectClasses (e.g. >>> an Organization resources to map organizationalUnit)? Or would organiza= tions initially define their own ( e.g. suOrganization, eduPerson, etc)? >>>=20 >>> thanks for any answers or crystal ball gazing, >>>=20 >>> -Patrick >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 From melinda.shore@gmail.com Wed Nov 28 22:56:55 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D370D21F89DE for ; Wed, 28 Nov 2012 22:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4S9O4nuV6dR for ; Wed, 28 Nov 2012 22:56:55 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC9921F8AFC for ; Wed, 28 Nov 2012 22:56:55 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so8152515pad.31 for ; Wed, 28 Nov 2012 22:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=l57j+2AqmA/UnLB1luwNGgf/8MfW9+I7SG2wP2v6Szk=; b=gGHu4pUbOp2U0KOxTkx4Q4MX0FWyN+vE/9oB2siy0RiK7HjJ2wHPD0O7/Ja4G25FCy NZYxwawDJwqr0r//EXfgCeivfU6kOBibA3rJdr1tQ0FDATfLwYjzvc+OK8cHbMyAelLT xqx6e0PRe9REejL24eCxjQx3mharxHeqF+a9s+fzHaCkv+P4DUbTpv+2e0lma6jgMCHS BFKAtuUjiZzxV4wIXJX/49mSnFd8I72kX8JERvNIpsLAB9nZ2JqOmIOa+wt4Z2jqlPTI f9Imz8XsKm+BpdDIV0nKh9TaDuDttff4F/JEJkt2pUKo3kF9rhfTJgCttj8JHLxd7rSn LMZQ== Received: by 10.68.83.68 with SMTP id o4mr66505155pby.25.1354172214980; Wed, 28 Nov 2012 22:56:54 -0800 (PST) Received: from spandex.local (66-230-82-44-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.82.44]) by mx.google.com with ESMTPS id pu4sm748885pbb.72.2012.11.28.22.56.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Nov 2012 22:56:54 -0800 (PST) Message-ID: <50B70734.1070107@gmail.com> Date: Wed, 28 Nov 2012 21:56:52 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: scim@ietf.org References: <50ABD250.5010307@stanford.edu> <50B3A37F.3060900@stanford.edu> <0512D30E-391C-4DC5-A59D-8AF55B5CEB9D@nexussafe.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 06:56:55 -0000 On 11/28/12 6:12 AM, Erik Wahlström wrote: > The current schema is extensible. You can define new resource types > and add attributes to an existing one, that's rather extensible and > flexible to me :) It might be worth identifying what is meant by "extensible," and how to avoid non-interoperable implementations. Also, this might be a good time to start thinking about IANA considerations - what goes into an IANA registry, if anything, and what doesn't. But the main issue is avoiding interoperability problems while still supporting extensibility. Melinda From prvs=5680ACF6A1=erik.wahlstrom@nexussafe.com Thu Nov 29 08:30:44 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E029821F85E6 for ; Thu, 29 Nov 2012 08:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUCu3bh+HYDn for ; Thu, 29 Nov 2012 08:30:43 -0800 (PST) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id E31C521F8A85 for ; Thu, 29 Nov 2012 08:30:41 -0800 (PST) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.1.421.2; Thu, 29 Nov 2012 17:30:34 +0100 Received: from MARVMAILDB.technxs.com ([fe80::95d1:b13:6f90:bdad]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Thu, 29 Nov 2012 17:30:39 +0100 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Emmanuel Dreux Thread-Topic: [scim] SCIM as Cloud Directory API Thread-Index: AQHNx1C7bl7eEqMfGU+e/2uUf4ah5JfzN7kAgAkb6oCAAA01gIABUOkAgACC1ICAASGUAIAAgBkAgAEoCIA= Date: Thu, 29 Nov 2012 16:30:38 +0000 Message-ID: <2286FB8F-C7E8-4E3E-81F2-DEBB6454954E@nexussafe.com> References: <50ABD250.5010307@stanford.edu> <50B3A37F.3060900@stanford.edu> <0512D30E-391C-4DC5-A59D-8AF55B5CEB9D@nexussafe.com> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.77] Content-Type: multipart/alternative; boundary="_000_2286FB8FC7E84E3E81F2DEBB6454954Enexussafecom_" MIME-Version: 1.0 Cc: "scim@ietf.org" , Patrick Radtke Subject: Re: [scim] SCIM as Cloud Directory API X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 16:30:45 -0000 --_000_2286FB8FC7E84E3E81F2DEBB6454954Enexussafecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, http://tools.ietf.org/html/draft-scim-core-schema-01#section-11.3 In that example the core User schema is extended with an enterprise extensi= on (that's just one extension that acts as an example in the specification)= . The enterprise extension is discoverable using the following format http:= //tools.ietf.org/html/draft-scim-core-schema-01#section-11.6 and you can ge= t all extensions a server supports using the /Schemas endpoint. That means = that a core resource is extendable in my book. In the same way you can totally define your new types of Resources that you= can control your self. For example /Device or /Machine, /Person or whateve= r that's all derived from Resource. Those are all still very discoverable. You are more then welcome to propose new attributes you think is missing in= the core schema (have the 80/20 rule in mind). The examples you mentioned = sounds good to me. I guess keeping your attributes in the core specificatio= n is in the interest of a service provider to ease onboarding to it's servi= ce. If a service provider decides (or more probably and probably more commo= n, is forced) to use an extension they have the possibility to do that and = your system have the possibility to adopt to that. I do think your system will need some smart mapping functionality for some = attributes (for example entitlements). I'm hoping that we will find some common extensions and a process to handle= that (as Melinda talked about) / Erik On Nov 28, 2012, at 11:50 PM, Emmanuel Dreux wrote: Hi Erik, Correct me if I'm wrong, but you would not extend the schema, you would rep= lace it with your own one. The question is (as I didn't cross any yet): can someone post a link to a S= AAS provider (or on premise app) for which the default SCIM schema would be= sufficient to provision (not partially) the identities? Is it then useful to define a schema in SCIM if the schema is not used / ad= opted because not practicable? In one sense, it helps normalize the name of a few attributes, but in other= way, as soon as you have to create your own "user class", you have to rede= fine them and get free to change the name of the attributes (firstname,give= nName,sn, familyname,givenname, etc...). Wouldn't it be fine to force to "derive" your own user "class" from the cor= e user schema? (in a sense really "extend" it). Or, are we allowed to say that any traffic based on rest api, authenticated= with Oauth and exchanging user informations in JSON will be labeled "SCIM"= . (Is Microsoft Azure graph API the first live SCIM implementation?) -- Cordialement / Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux -----Message d'origine----- De : Erik Wahlstr=F6m [mailto:erik.wahlstrom@nexussafe.com] Envoy=E9 : mercredi 28 novembre 2012 16:12 =C0 : Emmanuel Dreux Cc : scim@ietf.org; Patrick Radtke Objet : Re: [scim] SCIM as Cloud Directory API The current schema is extensible. You can define new resource types and add= attributes to an existing one, that's rather extensible and flexible to me= :) Some examples of the type of changes you would like to have would be great = to help understand what types of changes to the schema spec you need. It do= esn't sound like we are talking about resource relations here right? Best regards Erik On Nov 27, 2012, at 10:56 PM, Emmanuel Dreux wrote: If Salesforce adopts SCIM, how do you provision it? SCIM schema is ko for i= t. They will have to create an extended schema (currency, division, etc...) If Google adopts SCIM, how do you provision it? SCIM schema is ko for it. They will have to create an extended schema. ( Organizational units) If Office 365 adopts SCIM, how do you provision it? SCIM schema is ko for i= t. They will have to create an extended schema. ( pictures as jpeg not as html link, licences, etc...) Etc... I'm just trying to prove (and hope to have proven that n providers =3D n sc= hema). Is it what we want? Or could we allow the root core schema to be extensible for more flexibilit= y (and simplicity?). The format JSON/XML/FOAF/VCARD or whatever is another story, we have fully = understood his value but I will not try to convince this working group as i= t is not a very easy and accessible technology. -- Cordialement / Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux -----Message d'origine----- De : Erik Wahlstr=F6m [mailto:erik.wahlstrom@nexussafe.com] Envoy=E9 : mardi 27 novembre 2012 15:08 =C0 : Emmanuel Dreux Cc : scim@ietf.org; Patrick Radtke Objet : Re: [scim] SCIM as Cloud Directory API Hi, Why isn't schema discovery and some well crafted code that adopts from it i= t enough for the scenarios described? It sounds from your description that = you use SCIM internally but call the proprietary/heterogeneous API:s using = different methods and schemas. If you would use FOAF wouldn't you be forced= to parse that especially to depending on where you send the data? I also think that there is a finite numbers of extension that would exist a= nd that we could handle them in the way vCard handles extensions. The probl= em with having just a bucket to add attributes the schema quickly looses it= 's value. / Erik On Nov 26, 2012, at 7:01 PM, Emmanuel Dreux wrote: If you look at the 2 main providers for online messaging systems, you will = notice that the core SCIM schema is not sufficient: - Google syncs AD organizational Unit to Google Organizations =3D Need for Extended schema - Office 365 needs to assign specific licences =3D Extended schema. In fact, for all the SAAS providers that we sync, the core schema has never been sufficient. For example, - We provision RunMyProcess: they have a notion of roles and entities, (=3D= 2 distinct level of roles). - We are plugging a new SAAS provider with which we need to sync public key= s (not the full certificate handled by SCIM). Etc... Etc... In fact, we have noticed that all of our SAAS partners have particularities= and if we want to sync them through SCIM, we have to build a proprietary s= chema for each of them, reason why we're asking the possibility to extend m= ore simply the core schema (add attributes without having to create a separ= ate schema). (Finally we have noticed that FOAF is THE flexible and evolutive identity schema that would 100% address all the needs of identity management, but if you allow to add attributes to the core SCIM schema, it would also be fine...) -- Cordialement / Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux -----Message d'origine----- De : Patrick Radtke [mailto:pradtke@stanford.edu] Envoy=E9 : lundi 26 novembre 2012 18:15 =C0 : Emmanuel Dreux Cc : scim@ietf.org Objet : Re: [scim] SCIM as Cloud Directory API Thanks for the feedback Emmanuel, and the pointer to the Microsoft Graph AP= I - it is interesting to read their approach. As for your point on "100 SAAS providers and 100 proprietary schemas" I sus= pect that a SAAS provider would not require more than the core schemas for = basic provisioning, and the proprietary schemas would come in to play for S= AAS specific settings (data visibility, privacy settings, access controls, = in app 'theme' selection, etc) that are somewhat tangential to provisioning= but are linked to a user's account. I think the proprietary schema would provided an enhanced experience but wo= uld not be required for provisioning. -Patrick On 11/20/12 2:08 PM, Emmanuel Dreux wrote: I see 2 points in your thread: 1. inetOrgPerson often do not have uids [...] =3D> LDAP directories do not (generally) provide immutable ids. =3D> You can allocate uniqueIDs in your SCIM implementation and maintain a = mapping table between your LDAP objects and SCIM Identifiers. =3D> This also simplifies group membership and roles synchronization. 2. Schema: The SCIM default schemas are extensible and you can easily imple= ment yours. Personal feedback from a real experience. Today: a. We synchronize LDAP organizational units with google and postini. b. We allocate licences during provisioning of Office 365. c. We sync public keys with a SAAS provider for specific needs. In a "SCIM" world, for each of these scenario, the provider would have to i= mplement a specific schema. Said differently, today, if we want to provision Salesforce, Google, Dropbo= x, office365,etc., we have to learn and integrate their heterogeneous apis= . Tomorrow, in a SCIM world, we'll have to integrate as many proprietary sche= mas as we would have providers. What's the difference, is it more practicable? In parallal, Microsoft has implemented his LDAP restful apis (see phil comments). It is very convenient to use and entirely fits LDAP scenarii (schema : http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspx) In parallal, we've also discovered FOAF and RDF. This is, according to us, = the most extensible solution: a unique and universal schemas, transparently= extensible for everybody (compared to LDAP and OIDS definitions, and compa= red to SCIM and the need to define your own classes when you need additiona= l attributes). I'm really afraid that if we have 100 SAAS providers, we'll endup with 100 = proprietary schemas. Please send me your comments on this. -- Cordialement / Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux -----Message d'origine----- De : Patrick Radtke [mailto:pradtke@stanford.edu] Envoy=E9 : mardi 20 novembre 2012 19:56 =C0 : scim@ietf.org Objet : [scim] SCIM as Cloud Directory API We've (internally) been discussing a need for a read only Web API for our d= irectory servers. I've been reading Phil Hunt's scim-directory draft and ha= d some questions about the mapping inetOrgPerson to User, but first I'll de= scribe some of the issues that make it impractical for us to map inetOrgPer= son to User. In our directory, inetOrgPerson often do not have uids. These are often inc= oming students or affiliates that have not yet created accounts and that we= 'll need to make available through the Web API. In this case we wouldn't h= ave a valid SCIM userName for these Users and couldn't expose them as a val= id User resource. Our inetOrgPerson entries frequently have multiple names (e.g. former lastn= ames, Anglicized first names, etc), and we couldn't return the additional n= ames in a current User resource. Similar issues arise for any multi-valued = LDAP attribute that map to single value User or Enterprise User attributes = (organization, department, etc). Our inetOrgPerson may, at some point, be a= llowed multiple uids, etc. Is our use case missing the point of the draft? Is the intent of the draft to be a quickstart in providing an LDAP backed S= CIM endpoint, rather then a 'Cloud Directory'? In a 'Cloud Directory' future, would there be new standard Resources and At= tributes that roughly correspond to existing LDAP ObjectClasses (e.g. an Organization resources to map organizationalUnit)? Or would organization= s initially define their own ( e.g. suOrganization, eduPerson, etc)? thanks for any answers or crystal ball gazing, -Patrick _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_2286FB8FC7E84E3E81F2DEBB6454954Enexussafecom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

In the same way you can totally define your new types of Resources tha= t you can control your self. For example /Device or /Machine, /Person or wh= atever that's all derived from Resource. Those are all still very discovera= ble.

You are more then welcome to propose new attributes you think is missi= ng in the core schema (have the 80/20 rule in mind). The examples you menti= oned sounds good to me. I guess keeping your attributes in the core specifi= cation is in the interest of a service provider to ease onboarding to it's service. If a service provider decides= (or more probably and probably more common, is forced) to use an extension= they have the possibility to do that and your system have the possibility = to adopt to that.

I do think your system will need some smart mapping functionality for = some attributes (for example entitlements).

I'm hoping that we will find some common extensions and a process to h= andle that (as Melinda  talked about)

/ Erik



On Nov 28, 2012, at 11:50 PM, Emmanuel Dreux wrote:

Hi Erik,

Correct me if I'm wrong, but you would not extend the schema, you would rep= lace it with your own one.
The question is (as I didn't cross any yet): can someone post a link to a S= AAS provider (or on premise app) for which the default SCIM schema would be= sufficient to provision (not partially) the identities?

Is it then useful to define a schema in SCIM if the schema is not used / ad= opted because not practicable?
In one sense, it helps normalize the name of a few attributes, but in other= way, as soon as you have to create your own "user class", you ha= ve to redefine them and get free to change the name of the attributes (firs= tname,givenName,sn, familyname,givenname, etc...).

Wouldn't it be fine to force to "derive" your own user "clas= s" from the core user schema? (in a sense really "extend" it= ).
Or, are we allowed to say that any traffic based on rest api, authenticated= with Oauth and exchanging user informations in JSON will be labeled "= SCIM". (Is Microsoft Azure graph API the first live SCIM implementatio= n?)

--
Cordialement / Regards,
Emmanuel Dreux
http://www.cloudiway.com
Tel: +33 4 26 78 17 58
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

-----Message d'origine-----
De : Erik Wahlstr=F6m [mailto:erik.wahlstrom@nexussafe.com]
Envoy=E9 : mercredi 28 novembre 2012 16:12
=C0 : Emmanuel Dreux
Cc : scim@ietf.org; Patrick Radtke
Objet : Re: [scim] SCIM as Cloud Directory API

The current schema is extensible. You can define new resource types and add= attributes to an existing one, that's rather extensible and flexible to me= :)

Some examples of the type of changes you would like to have would be great = to help understand what types of changes to the schema spec you need. It do= esn't sound like we are talking about resource relations here right?

Best regards
Erik

On Nov 27, 2012, at 10:56 PM, Emmanuel Dreux wrote:

If Salesforce adopts SCIM, how do you provision i= t? SCIM schema is ko for it.
They will have to create an extended schema (curr= ency, division,
etc...)

If Google adopts SCIM, how do you provision it? S= CIM schema is ko for it.
They will have to create an extended schema. ( Or= ganizational units)

If Office 365 adopts SCIM, how do you provision i= t? SCIM schema is ko for it.
They will have to create an extended schema. ( pi= ctures as jpeg not as
html link, licences, etc...)

Etc...
I'm just trying to prove (and hope to have proven= that n providers =3D n schema).
Is it what we want?
Or could we allow the root core schema to be exte= nsible for more flexibility (and simplicity?).

The format JSON/XML/FOAF/VCARD or whatever is ano= ther story, we have fully understood his value but I will not try to convin= ce this working group as it is not a very easy and accessible technology.

--
Cordialement / Regards,
Emmanuel Dreux
http://www.cloudiway.com
Tel: +33 4 26 78 17 58
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux


-----Message d'origine-----
De : Erik Wahlstr=F6m [mailto:erik.wahlstrom@nexu= ssafe.com]
Envoy=E9 : mardi 27 novembre 2012 15:08
=C0 : Emmanuel Dreux
Cc : scim@ietf.org; Patrick Radtke
Objet : Re: [scim] SCIM as Cloud Directory API

Hi,

Why isn't schema discovery and some well crafted = code that adopts from it it enough for the scenarios described? It sounds f= rom your description that you use SCIM internally but call the proprietary/= heterogeneous API:s using different methods and schemas. If you would use FOAF wouldn't you be forced to parse= that especially to depending on where you send the data?

I also think that there is a finite numbers of ex= tension that would exist and that we could handle them in the way vCard han= dles extensions. The problem with having just a bucket to add attributes th= e schema quickly looses it's value.

/ Erik


On Nov 26, 2012, at 7:01 PM, Emmanuel Dreux wrote= :

If you look at the 2 main providers for online me= ssaging systems, you will notice that the core SCIM schema is not sufficien= t:

- Google syncs AD organizational Unit to Google O= rganizations =3D Need
for Extended schema
- Office 365 needs to assign specific licences = =3D Extended schema.

In fact, for all the SAAS providers that we sync,= the core schema has
never been sufficient. For example,
- We provision RunMyProcess: they have a notion o= f roles and entities, (=3D 2 distinct level of roles).
- We are plugging a new SAAS provider with which = we need to sync public keys (not the full certificate handled by SCIM).
Etc... Etc...

In fact, we have noticed that all of our SAAS par= tners have particularities and if we want to sync them through SCIM, we hav= e to build a proprietary schema for each of them, reason why we're asking t= he possibility to extend more simply the core schema (add attributes without having to create a separate schema= ).

(Finally we have noticed that FOAF is THE flexibl= e and evolutive
identity schema that would 100% address all the n= eeds of identity
management, but if you allow to add attributes to= the core SCIM
schema, it would also be fine...)


--
Cordialement / Regards,
Emmanuel Dreux
http://www.cloudiway.com
Tel: +33 4 26 78 17 58
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

-----Message d'origine-----
De : Patrick Radtke [mailto:pradtke@stanford.edu]= Envoy=E9 : lundi 26
novembre 2012 18:15 =C0 : Emmanuel Dreux Cc : sci= m@ietf.org Objet : Re:
[scim] SCIM as Cloud Directory API

Thanks for the feedback Emmanuel, and the pointer= to the Microsoft Graph API - it is interesting to read their approach.

As for your point on "100 SAAS providers and= 100 proprietary schemas" I suspect that a SAAS provider would not req= uire more than the core schemas for basic provisioning, and the proprietary= schemas would come in to play for SAAS specific settings (data visibility, privacy settings, access controls, in app 'them= e' selection, etc) that are somewhat tangential to provisioning but are lin= ked to a user's account.
I think the proprietary schema would provided an = enhanced experience but would not be required for provisioning.

-Patrick



On 11/20/12 2:08 PM, Emmanuel Dreux wrote:
I see 2 points in your thread:
1. inetOrgPerson often do not have uids [...] =3D= > LDAP directories do
not (generally) provide immutable ids.
=3D> You can allocate uniqueIDs in your SCIM i= mplementation and maintain a mapping table between your LDAP objects and SC= IM Identifiers.
=3D> This also simplifies group membership and= roles synchronization.

2. Schema: The SCIM default schemas are extensibl= e and you can easily implement yours.
Personal feedback from a real experience. Today:<= br>
a. We synchronize LDAP organizational units with = google and postini.
b. We allocate licences during provisioning of Of= fice 365.
c. We sync public keys with a SAAS provider for s= pecific needs.

In a "SCIM" world, for each of these sc= enario, the provider would have to implement a specific schema.
Said differently, today, if we want to provision = Salesforce, Google, Dropbox, office365,etc.,  we have to learn and int= egrate their heterogeneous apis.
Tomorrow, in a SCIM world, we'll have to integrat= e as many proprietary schemas as we would have providers.
What's the difference, is it more practicable?

In parallal, Microsoft has implemented his LDAP r= estful apis (see
phil comments). It is very convenient to use and = entirely fits LDAP
scenarii (schema :
http://msdn.microsoft.com/en-us/library/windowsaz= ure/hh974478.aspx)
In parallal, we've also discovered FOAF and RDF. = This is, according to us, the most extensible solution: a unique and univer= sal schemas, transparently extensible for everybody (compared to LDAP and O= IDS definitions, and compared to SCIM and the need to define your own classes when you need additional attribute= s).

I'm really afraid that if we have 100 SAAS provid= ers, we'll endup with 100 proprietary schemas. Please send me your comments= on this.

--
Cordialement / Regards,
Emmanuel Dreux
http://www.cloudiway.com
Tel: +33 4 26 78 17 58
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

-----Message d'origine-----
De : Patrick Radtke [mailto:pradtke@stanford.edu]= Envoy=E9 : mardi 20
novembre 2012 19:56 =C0 : scim@ietf.org Objet : [= scim] SCIM as Cloud
Directory API

We've (internally) been discussing a need for a r= ead only Web API for our directory servers. I've been reading Phil Hunt's s= cim-directory draft and had some questions about the mapping inetOrgPerson = to User, but first I'll describe some of the issues that make it impractical for us to map inetOrgPerson to User= .

In our directory, inetOrgPerson often do not have= uids. These are often incoming students or affiliates that have not yet cr= eated accounts and that we'll need to make available through the Web API. &= nbsp;In this case we wouldn't have a valid SCIM userName for these Users and couldn't expose them as a valid User res= ource.

Our inetOrgPerson entries frequently have multipl= e names (e.g. former lastnames, Anglicized first names, etc), and we couldn= 't return the additional names in a current User resource. Similar issues a= rise for any multi-valued LDAP attribute that map to single value User or Enterprise User attributes (organization,= department, etc). Our inetOrgPerson may, at some point, be allowed multipl= e uids, etc.

Is our use case missing the point of the draft?
Is the intent of the draft to be a quickstart in = providing an LDAP backed SCIM endpoint, rather then a 'Cloud Directory'?
In a 'Cloud Directory' future, would there be new= standard Resources and Attributes that roughly correspond to existing LDAP= ObjectClasses (e.g.
an Organization resources to map organizationalUn= it)? Or would organizations initially define their own ( e.g. suOrganizatio= n, eduPerson, etc)?

thanks for any answers or crystal ball gazing,

-Patrick









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







--_000_2286FB8FC7E84E3E81F2DEBB6454954Enexussafecom_--