Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-discovery-09: (with DISCUSS and COMMENT)

Mike Jones <Michael.Jones@microsoft.com> Sun, 04 March 2018 18:40 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430EF124BAC; Sun, 4 Mar 2018 10:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22BIIGPYQmdm; Sun, 4 Mar 2018 10:40:47 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0106.outbound.protection.outlook.com [104.47.42.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792631242F7; Sun, 4 Mar 2018 10:40:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OQzxct5xH8OVNAraA+RwWEXdJPM5mfyYCjWnPmn9tOc=; b=My5uWI6I1zstYyEItSph0im7wLfeg3RrIPhr8sTgeZrswYiSfh1fim8U6mGlhCr22cuSIGtb5YYLmGixaBaom9M9xuCH6hKcdfvjqW6k1zRCrE2FKhH8TnzZ6vc5vzlcwjfU2VRqBi/YwoR7idVFK1DUXA/9GIiCzHGSXgbg1rU=
Received: from SN6PR2101MB0943.namprd21.prod.outlook.com (52.132.114.20) by SN6PR2101MB1039.namprd21.prod.outlook.com (52.132.115.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.588.3; Sun, 4 Mar 2018 18:40:46 +0000
Received: from SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50]) by SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50%2]) with mapi id 15.20.0588.001; Sun, 4 Mar 2018 18:40:46 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>
CC: "draft-ietf-oauth-discovery@ietf.org" <draft-ietf-oauth-discovery@ietf.org>, "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-discovery-09: (with DISCUSS and COMMENT)
Thread-Index: AQHTsKKMrlpj/FsDKEO0KKpCHm5EIKO6MjGggAXtIgCAAE+F8A==
Date: Sun, 04 Mar 2018 18:40:45 +0000
Message-ID: <SN6PR2101MB094370DDD6DE166894BDC3B2F5DB0@SN6PR2101MB0943.namprd21.prod.outlook.com>
References: <151982902113.5155.16065862366702262286.idtracker@ietfa.amsl.com> <SN6PR2101MB09439981ED94AE59AC51B355F5C70@SN6PR2101MB0943.namprd21.prod.outlook.com> <1520171662.1990144.1290896928.2DD0F37B@webmail.messagingengine.com>
In-Reply-To: <1520171662.1990144.1290896928.2DD0F37B@webmail.messagingengine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [50.47.88.236]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR2101MB1039; 7:sQWdp3TJglTZN9hnLe3UCvA16G6cph26Rubc7QMzvuUzDrAWJlLMOflwscmwhhu4ByXyc20T2w18sBo0nMOhEG6o1Gq0dr9i2f4jKX+OuDtR5kNJjdAqXus3oVcRc80lqsTEGsDGc7Z5e9RbhrSOXL3ELfU+qUa16dOZXanDSHl0RCXkS9puQx2RMpK5+n8ADovzoVgFeyBeSnKoufvCzj9b2xNxIEN5Lz7lYVU61lLaY7oPThF7yBNQFIUfw/oG
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 2b5d4e50-9c18-40b3-a5ad-08d581ff7148
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:SN6PR2101MB1039;
x-ms-traffictypediagnostic: SN6PR2101MB1039:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-microsoft-antispam-prvs: <SN6PR2101MB103936E0216A7CC07DAB9844F5DB0@SN6PR2101MB1039.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(120809045254105);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231220)(944501244)(52105095)(3002001)(6055026)(61426038)(61427038)(6041288)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:SN6PR2101MB1039; BCL:0; PCL:0; RULEID:; SRVR:SN6PR2101MB1039;
x-forefront-prvs: 060166847D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(376002)(39860400002)(39380400002)(366004)(13464003)(199004)(189003)(69234005)(26005)(25786009)(3280700002)(229853002)(4326008)(10290500003)(6246003)(81156014)(5660300001)(8676002)(6306002)(2950100002)(9686003)(7696005)(6436002)(305945005)(97736004)(54906003)(186003)(7736002)(72206003)(55016002)(53546011)(106356001)(110136005)(6506007)(86362001)(102836004)(74316002)(345774005)(966005)(76176011)(8666007)(66066001)(3846002)(6116002)(14454004)(105586002)(99286004)(478600001)(3660700001)(2906002)(33656002)(10090500001)(86612001)(5250100002)(81166006)(2900100001)(8936002)(68736007)(8990500004)(316002)(53936002)(22452003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB1039; H:SN6PR2101MB0943.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: dwZBDNnaUVA3VEs2Ijvzk07B88BQt6lvAZPUoWAcysQ49OPtHTsVHzTikKu+HB6LjG70673U4F7JxJoDaA6PdwwsTm0BDpsoh69GofmtHtcS1d3n/DkQsgSXE46Y8oT30mJt8nNswOfQ2WKdTjxFbhFLvkoILNGwrGeOibgra7ah8XmFmTM61JfViBVeIZXvZagIheIWQwDDbXnOILkFglezQV4XkyBFmc7L8cY2qBnlG/UIR7JVg0eC8IF4xfnGQt5VbMjrgsH//fqA5whK2Ci34z4Y79z2Ee8LPuI6lIEHCxkvBrp+0gDJVlNdzdNvW9Oyw3/mTLuKtXhb/KjLIQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2b5d4e50-9c18-40b3-a5ad-08d581ff7148
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2018 18:40:45.9042 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB1039
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ZcL_TxQOuyit-Hv7sNaP7-poJco>
Subject: Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-discovery-09: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Mar 2018 18:40:51 -0000

Thanks for getting back to me, Alexey.  Draft -10, in the third sentence at https://tools.ietf.org/html/draft-ietf-oauth-discovery-10#section-7.1.1, contains the requested clarification.  Hopefully this satisfies the intent of your DISCUSS.

See you in London!

				-- Mike

-----Original Message-----
From: Alexey Melnikov <aamelnikov@fastmail.fm> 
Sent: Sunday, March 4, 2018 5:54 AM
To: Mike Jones <Michael.Jones@microsoft.com>; The IESG <iesg@ietf.org>
Cc: draft-ietf-oauth-discovery@ietf.org; oauth-chairs@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-discovery-09: (with DISCUSS and COMMENT)

Hi Mike,
Sorry for the slow response, I forgot (for a moment) about the Monday draft submission deadline.

On Wed, Feb 28, 2018, at 7:44 PM, Mike Jones wrote:
> Hi Alexey,
> 
> FYI, the only place in the spec that case-insensitive comparisons 
> exist are comparisons done by the Designated Experts when considering 
> IANA registrations.  If implementations had to do case-insensitive 
> comparisons, then yes, recommending toLowerCase() would absolutely 
> make sense, but it's human beings doing the case folding when 
> evaluating proposed registrations.

I was thinking more about this and came to conclusions that this distinction doesn't make a difference in practice. The problem is that Unicode case insensitive comparison means that Designated Experts need to be experts in Unicode or they have to use tools that will do comparision for them. I can show several examples of strings that are case insensitive according to toLowerCase(), but people not knowing corresponding scripts (or having more general idea about Unicode) wouldn't be able to evaluate for case insensitivity just by looking at them.

>  I'll also note that this is exactly the same language used in the 
> instructions to Designated Experts in related registries.  For 
> instance, you can see it in use at these (and many
> other) locations:
> 	https://tools.ietf.org/html/rfc7515#section-9.1.1
> 	https://tools.ietf.org/html/rfc7517#section-8.1.1
> 	https://tools.ietf.org/html/rfc7518#section-7.1.1
> 	https://tools.ietf.org/html/rfc7519#section-10.1.1
> 	https://tools.ietf.org/html/rfc7800#section-6.2.1
> 
> Whereas the use of toLowerCase() in
> https://tools.ietf.org/html/rfc8265#section-3.3.1 makes perfect sense, 
> because it's a transformation performed by computer programs.
> 
> That said, I'll leave it up to you.  If you still want me to make a 
> change, I'd propose making this one:  Change "Names may not match 
> other registered names in a case-insensitive manner unless the 
> Designated Experts state that there is a compelling reason to allow an exception"
> to "Names may not match other registered names in a case-insensitive 
> manner (one that would cause a match if the Unicode toLowerCase() 
> operation were applied to both strings) unless the Designated Experts 
> state that there is a compelling reason to allow an exception".

I still prefer the above version.

Thank you,
Alexey

> If you still want a change, I'll add this parenthetical remark during 
> the next set of edits.  (However, I'll wait for Adam to weigh in on 
> his DISCUSS before republishing.)
> 
> Let me know.
> 
> 				Thanks again,
> 				-- Mike
> 
> -----Original Message-----
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Alexey Melnikov
> Sent: Wednesday, February 28, 2018 6:44 AM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-oauth-discovery@ietf.org; oauth-chairs@ietf.org; 
> oauth@ietf.org
> Subject: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-
> discovery-09: (with DISCUSS and COMMENT)
> 
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-oauth-discovery-09: Discuss
> 
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thank you for the well written IANA Considerations section. I have one 
> comment on it which should be easy to resolve:
> 
> The document doesn't seem to say anything about allowed characters in 
> Metadata names. When the document talks about "case-insensitive 
> matching", it is not clear how to implement the matching, because it 
> is not clear whether or not Metadata names are ASCII only. If they are 
> not, then you need to better define what "case insensitive" means.
> 
> You've made a change in section 7.1, which looks good. However there 
> is still the following text in 7.1.1:
> 
>    Metadata Name:
>       The name requested (e.g., "issuer").  This name is case-sensitive.
>       Names may not match other registered names in a case-insensitive
> 
> I suggest replacing "in a case-insensitive manner" with something like 
> "if when applying Unicode toLowerCase() to both, they compare equal".
> 
> Or maybe keep "case-insensitive" and just add a sentence explaining 
> what it is.
> I think you should use toLowerCase(), as it is already recommended in 
> other IETF specs, like RFC 8265.
> 
>       manner unless the Designated Experts state that there is a
>       compelling reason to allow an exception.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I am agreeing with Adam's DISCUSS. I believe it was addressed in the 
> latest version.
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth