Re: [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-regext-rdap-openid-27> for your review
"Hollenbeck, Scott" <shollenbeck@verisign.com> Thu, 11 April 2024 13:35 UTC
Return-Path: <shollenbeck@verisign.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE192C14F706; Thu, 11 Apr 2024 06:35:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBTQ9Sd-1xRR; Thu, 11 Apr 2024 06:35:25 -0700 (PDT)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9191C14F708; Thu, 11 Apr 2024 06:35:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=50550; q=dns/txt; s=VRSN; t=1712842525; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=4P9cQyU7LEmTahiphR37jOknibjcS0T00h5MWgT83I0=; b=IalIXFo4WAfEuLwSMcsfgx/xWo8rFkDGBcp0/UbkC306yqjhkyY1qNlK 1bj3pK7fnLJPhipoM+dAUu4snXkhZvpRcN6bt33m173YTNcQiLas2AOiQ bA0LKkl2Dlec0uTKpbWPHCGTX7Svf0xadS1OnKvYMrBZNb4BRTsrhXKRE NxLtWAvp30ZRgPv0vHMdmUM5IdVaqSkIU9E3ij0rOKq9OFlOk5q7+cvyU 6RcwHvTPrbA5fKlAy+PymVRJZStqiW5bWAsWy0uG1PGw1RJyuTGbHVDR5 vfAKkn3KFJRLK0ytrYayi0JNMRcNUf4jwLNTQVq6dv+tQRnFEColNdBAW Q==;
X-CSE-ConnectionGUID: qx58qbE0TQqbhiThFmBJ2w==
X-CSE-MsgGUID: MkYm2pixQFiHD/63FUJEsg==
X-ThreatScanner-Verdict: Negative
IronPort-Data: A9a23:Gv/tqKMkn7ytwIXvrR14lsFynXyQoLVcMsEvi/4bfWQNrUp2gTwOz WsdCjiHa6mIMWvwe913aIixp0NTvpSDx4NhTwZtpSBmQkwRpJueD7x1DKtS0wC6dZSfER09v 63yTvGacajYm1eF/k/F3oDJ9CQ6jefQAOOkVIYoAwgpLSd8UiAtlBl/rOAwh49skLCRDhiE0 T/Ii5S31GSNhXgsbQr414rZ8Ekz5Kir4WtC1rADTasjUGH2xiF94K03ePnZw0vQGuF8AuO8T uDf+7C1lkuxE8AFU47Nfh7TKyXmc5aKVeS8oiM+t5uK23CukhcPPpMTb5LwX28M0mnUwIoho Dl6ncfYpQ8BZsUgkcxDC0UIS3kW0aduoNcrKlDn2SCfItGvn9IBDJyCAWlvVbD09NqbDklX5 aFIMTogNiy6nui2wY67ZOxGpJ48eZyD0IM34hmMzBnzN9B/frbuc/2To8FT2y0owMlCW+jEf MxfYj1qBPjCS0QXfA5IU9Rnwbzu2imXnz5w8Tp5oYIs42/XyAF32rXmM/LLd8aLXsRamACTo WeuE2HRWUlAaY3GlWPtHnSEo+z+mHnjWZIrOryY2rk023Ou5EEIB0hDPbe8ibzj4qKkYPpEN 0UO4CMosYA78VevCNL6WnWQunCP+xMQWsZXCcUg5grIx6bV/wGDQG8eQVZpctEpud8qADUmz XeIks/nQzt1v9W9U3+S+6eI6DiyMCkPNkcDaDMKCwwf7LHLu5wrgwjSVdt5OKGwh9zxXzr3x liipTUih+lDhNQA16Sl8HjdjTnpq5TIUgkvoALNUQqYAhhRbpSjPpOu5EiDtLNbMpzfS1ia+ XID3cKE6rlIE4uWkmqGR+Bl8KyV2stp+Qb02TZHd6TNPRz0k5J/Vei8OA1DGXo=
IronPort-HdrOrdr: A9a23:D1gq9axfKI9jVn1VtGD1KrPw8b1zdoMgy1knxilNoHtuA6mlfq GV7ZYmPHDP6Ar5NEtPpTniAsa9qBrnnPZICOIqTNSftWfd2VeAHcVN4Yzv2DX8FyC73f4178 tdWpk7LNHrF1B1gYLZ7BnQKbwd6ejC1Kyzn+/RwzNWUAdwZ8hbgjtREAqBDUFsfgVACKc4EJ b03KF6mwY=
X-Talos-CUID: 9a23:xCAz4Gr5PN7IBYTDhzSKnqDmUdk1Ly3ExlqIH3ahA2ZodL27THWyorwxxg==
X-Talos-MUID: 9a23:llRBGQthsqUtX1nr8s2noTJTMZ1w4rSXJkEtvdJY4Oe5FwFrNGLI
X-IronPort-AV: E=Sophos;i="6.07,193,1708387200"; d="scan'208";a="30259141"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.37; Thu, 11 Apr 2024 09:35:23 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) by BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) with mapi id 15.01.2507.037; Thu, 11 Apr 2024 09:35:23 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "starrant@amsl.com" <starrant@amsl.com>
CC: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "regext-ads@ietf.org" <regext-ads@ietf.org>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "AlBanna, Zaid" <zalbanna@verisign.com>, "superuser@gmail.com" <superuser@gmail.com>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Thread-Topic: [EXTERNAL] Re: AUTH48: RFC-to-be 9560 <draft-ietf-regext-rdap-openid-27> for your review
Thread-Index: AQHah6PKQlko8rWdf0umkOM7GZVcRrFee1XQgAO01oCAAOqJ8A==
Date: Thu, 11 Apr 2024 13:35:23 +0000
Message-ID: <94106941ea1449eaa9c768edeea238c7@verisign.com>
References: <20240405215407.0FA11192F7B5@rfcpa.amsl.com> <0becadf40961493f84b9c887b122c191@verisign.com> <F602EDA7-3CE3-40C1-A6BE-DBF9A4BB0346@amsl.com>
In-Reply-To: <F602EDA7-3CE3-40C1-A6BE-DBF9A4BB0346@amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/A9Gib0M9r_RqWsF0F1SH61X6Pz8>
Subject: Re: [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-regext-rdap-openid-27> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2024 13:35:30 -0000
I'm currently taking a few vacation days. I'll get to this early next week. Thanks for your patience. Scott > -----Original Message----- > From: Sarah Tarrant <starrant@amsl.com> > Sent: Wednesday, April 10, 2024 3:35 PM > To: Hollenbeck, Scott <shollenbeck@verisign.com> > Cc: RFC Editor <rfc-editor@rfc-editor.org>; regext-ads@ietf.org; regext- > chairs@ietf.org; AlBanna, Zaid <zalbanna@verisign.com>; > superuser@gmail.com; auth48archive@rfc-editor.org > Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9560 <draft-ietf-regext-rdap- > openid-27> for your review > > Caution: This email originated from outside the organization. Do not click links > or open attachments unless you recognize the sender and know the content is > safe. > > Hi Scott, > > Thank you for your reply. We have updated the document accordingly. Please > review the document carefully to ensure satisfaction as we do not make > changes once it has been published as an RFC. > > We have one followup request: > > 1) Regarding: > >> 7) <!-- [rfced] Should the following lines also appear within the > >> <artwork> element to match the examples in Sections 5.2.1 and 5.2.2? > >> > >> Section 4.2.1: > >> > >> https://secure-web.cisco.com/1B- > NRuvNpIpdUUCYnzYW05FoyqzxfFfAfvVWrC-b > >> hkh7qHky-O22cthU6Xow9P80JbHKE-Ekz- > RcPJ3WWqHdyEHdEcvXgK3s7TYajOLZ8fyX8 > >> uq0iicqG817FTfO3SdVtWscM1ZbQDERu5MYpAV- > Vi_x8UXkUu4eI_0FFgmzLEnxKsqaqu > >> bX7UG71lVoLO0uUruvgsVuyaSk0iWZ1hijun54C6Q6ooZ2- > 0qYHc9m2Ke0ypMqj5--yrb > >> bwAHfqQCr2rqabDgi3yyzofbKX1zZojBkJ1RrGEvvK- > SLaXojQvaaOvf8DqNOIgoli-Pz > >> > 6edIF/https%3A%2F%2Fexample.com%2Frdap%2Fdomain%2Fexample.com > %3Ffarv1 > >> _qp%3DlegalActions > >> > >> > >> Section 4.2.2 > >> > >> https://secure-web.cisco.com/16U7IPDKP3UxhhRN- > a073_zDJ5bY2FNLfYdjdis8 > >> wZTD8GF8SZZUeu0D96BQA- > E6aaxZPhIEFYBQu74MuElbs5oVQpvJEcGUxfEm_g5sVL8Xv > >> > HPBTonjXHgPvIxjA5eSFBrmVBBeqltVk4jcN7wwHnMAvifwd_Rx7vg2CaBG0m > 4tj68nAO > >> BSjhGd- > 8vL9fefOwu7SvvpXPNDRqUbg3QsQqyUAdD6vnnLz4xdX2K4aJYQJPnUnsCjJV > 0 > >> IMO8Xpjlv81oHFAFPbzjQupgQ2XPouftJdEA0O9U_AfzVn5- > WpXKDgs_uPO4sLqm0FZzr > >> > rhN5E/https%3A%2F%2Fexample.com%2Frdap%2Fdomain%2Fexample.com > %3Ffarv1 > >> _dnt%3Dtrue > >> > >> Section 5.2.1: > >> https://secure- > web.cisco.com/1Umih56NNSc3GnWgpsbfqfNHFvJvEHTUdkbgb4NIvb5MUm > w1TscAa8DOHTPTB4BpU_OBZbu70etf_Oe30Bb6tNH3E8yFZN2wf- > qym7hCpRIEc7aREk7T_X2L7vdIqJUwpnTo4kscpsXIF6Pc9TZ8ZxAHLBpKyIjn3f > 4GMRaD0YlBKTnH4X8eqTlbyp3cu_bTNsHPfFyOaMCimZ9D- > f8Iiz9wGAn_kCgfqrAQ_W8gbn7oAfjVhG6bOU73iw3CX7GFuIuAav7ZaDgqxz8 > _DNl7tvzR3kQQG-RM9dimI- > 58XmUqk3m2stOdkkitsPtjDMZiP/https%3A%2F%2Fexample.com%2Frdap% > 2Ffarv1_session%2Flogin > >> ... > >> > >> https://secure- > web.cisco.com/1Umih56NNSc3GnWgpsbfqfNHFvJvEHTUdkbgb4NI > >> > vb5MUmw1TscAa8DOHTPTB4BpU_OBZbu70etf_Oe30Bb6tNH3E8yFZN2wf- > qym7hCpRIEc > >> > 7aREk7T_X2L7vdIqJUwpnTo4kscpsXIF6Pc9TZ8ZxAHLBpKyIjn3f4GMRaD0YlBK > TnH4X > >> 8eqTlbyp3cu_bTNsHPfFyOaMCimZ9D- > f8Iiz9wGAn_kCgfqrAQ_W8gbn7oAfjVhG6bOU7 > >> 3iw3CX7GFuIuAav7ZaDgqxz8_DNl7tvzR3kQQG-RM9dimI- > 58XmUqk3m2stOdkkitsPtj > >> > DMZiP/https%3A%2F%2Fexample.com%2Frdap%2Ffarv1_session%2Flogin > >> > >> Section 5.3: > >> > >> https://secure- > web.cisco.com/1We1qBVVLvm1sCCU_ZSmhkWGvqqBDElpUqYxatG_ > >> > 0zf8JZBVZNWegJ7srVG7cxGdyfnA1adqIPdSPkvdzjFNJMwlGy8iLwA4ibw12hy > rBocfE > >> s5mvmJqCyS1M5Jx5dNyuLNSIKJ0rnuy2L- > C_5A1k7fG9q2xdCjgnoHZC_66rWCT7S_SpQ > >> 7V-Yt12EiXg11LnN-OOu- > RpnuFXUALt5zJRSSOqxWlJ5kJFnNa9r6yJPDrSIKKGbcd13n > >> > G7jLeYbz40kwuxfuG3SwRmR20Kc1BMaE_3K0IMJMUFDNMuHbaAbIqqV1dG > 14EWw-LjGj_ > >> N- > BFv/https%3A%2F%2Fexample.com%2Frdap%2Ffarv1_session%2Fstatus > >> > >> Section 5.4: > >> > >> https://secure- > web.cisco.com/1TVn4s0tg0ehAMhKu8n35TaVJv5Og1wp_P-MEs4M > >> YyqXKkLuke-4w1a_wIZeYa- > Um8gWkbk_rEu4AjVEimlCMAgGcDCQtVwb7c6W5kNLqkHgg > >> qHSF_i4eZ3MvqqfliaBvLKBMI6R0hYYcY03Y66OMWcn53D4Sf- > JUyGZqyTbDHNPzIkv-V > >> cUb7bclq1ApG8RWrZmNLS_MzypmTIRb-tT7fl2_O4yubvNGJ- > nu2CDD7N6zxU30qPCVW9 > >> k5X- > imtYr5DlUCqypGON1RZJXlt9VXti2ALMQMZw7Ik_zdRu303e46d72Pv9wypup > Rzvr > >> > 04Q3h/https%3A%2F%2Fexample.com%2Frdap%2Ffarv1_session%2Frefres > h > >> > >> Section 5.5: > >> > >> https://secure-web.cisco.com/1xsm9_Dx5VG43f7oP6bKddPpPC9- > oNfPvIe8aSS7 > >> r3j2wlGi7sfAbUq84NHAsABPcvMAi4cyG2c2Sbsu7RZnkfpk- > n73JxWI2ynJ7mrkfU9fO > >> RQOZ6Hb7OzUwBuJlnK4fTuCV2Fr7bX7tRYYz3Kdr3bZBjP8b- > 1mCorhxWHJBmq1uGrfwV > >> RGeKDXfggN- > LyeyZsjuzJKuLtUl6Q0GGJ4ptpyx48QYTAmKNt1TL1QNd4KLiHGAqriLsW > >> QDY- > ES2eQ9oacBRZG199NaY1aa56gC8GA9EznzbnDQIIbDp3w5LJFg55y0BzlmBa1 > bs8z > >> > QNKll/https%3A%2F%2Fexample.com%2Frdap%2Ffarv1_session%2Flogout > >> --> > > > > [SAH] I'd like to trust your judgment for each of these. They're all examples, > and if it's preferable to mark them as artwork for display/font consistency > purposes, that's fine with me. > > Please review our formatting of these lines as we updated them to artwork > elements. > > > The updated files have been posted here (please refresh): > https://secure- > web.cisco.com/1sdgDjQOT2PLtuQyDC_qzn6dohViyEgXxEt2CCoxXDORcZZf0g > vBWq9LH6ZptMKG2meLHzWkzA9vvbN7dWLeh25H0_U- > At9H7IQ2Ryfb2Vxjg3OpBqnC83mn2JlsUY_P9Q_9xOKVmFMXHQvhLC1FaGyU > uPNs89DxraG5hsv4nVWBhSn32L1qcjZVC_NVdoJs2rAj- > GjB52mZnFiGww5Y8DDyhy8HA23C04ulrtOML8JuSYPDD1rVL7qFNNjWj7NoE > PxvNIDrxfBZPj987gXQQeH3K0q4xEPQhADwCO2cyHaEFkeKAQ6CSVCGODjq1 > d0Vt/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9560.txt > https://secure- > web.cisco.com/1NUtgfrUlX29jLK_qblKvAWwWGuiogBRYtVDgPiw3W0SEDzgo > RLbeKN_SE5m0f4Nmb2EBzyPmWNHpjMK- > RatJZieo_uDo3ir6DHzWwvMT8YnHWEy9lRqraM7pat9D48MQZWUOCMKkye > fCb7FbUKA8HPtdSHPiLz6j7fLjiy7O2I693MbB9cNfQx7IwGgEQ4_eJgo53env5 > HB5bB-wd-Uc-x- > bDKvcmjzuqQXIfakFZlg9OjoXvpJNtNIDL9ZSUgumlUNh6MUIPLJed1l1LyRGLbb > En1FLK- > l6slKpDQGpgebX1C0hERMVLG5usaaAtom2/https%3A%2F%2Fwww.rfc- > editor.org%2Fauthors%2Frfc9560.pdf > https://secure- > web.cisco.com/1GOr2kn1R0Iebz3_wm937s6PZGv6Nl5jeIi26tWKvmNi3DwM > P5e4TC613R0RW-bk-975sxYXlS7zDMnUdHmULRUO5LJpnecrLk7vg7Y8v- > skrkAwdDZFu2FNCzETMSNiIMTBO2W2YVrOmklUjPtvIcMmOillMKYbwSLAup > RaSnNRc-4SdR5FGssDUkUK1BEeh5JMSwGi-tuImAAPkO0eTCn- > yuoFNqcpv1iLfcJd23-5i1vCdrvyelq12dI_GWeYg1iex6AqZGetNjQvDyB- > GGopMsVKLv5RfXwLAyvBPB0QApWH- > nm7TKrVy4NUxxJTC/https%3A%2F%2Fwww.rfc- > editor.org%2Fauthors%2Frfc9560.html > https://secure- > web.cisco.com/1wV8vP8wCSuaz63UWDGMaGF2TCGfCK8myBRikv4Bq1lBE- > gKAW4U- > 3bd9hTbgTwczFkSdQgcGOJjcln5G8NPTkeQ1Vo4BTHZ0knlb70ETOLZXmtHloXI > wtKix- > HuUNZTqL38i7XrBRNuzJ0e2UsSFli9D8nlpHUu3IsHMNyEO6ZO8QBjCjMIZ4k > WrdYAb9un4WyG0IiXu_8npEKbkcY6aVPqfcSqhZLM9mlCikk32Mmd5LB4qRQ > h_JiTU60EqkzkkU83O_CvTuBfLxaM_I109yPX10azd10gl301zhqGDSSq3yL4do > Qp-R3yyLLmPOE1A/https%3A%2F%2Fwww.rfc- > editor.org%2Fauthors%2Frfc9560.xml > > The relevant diff files have been posted here (please refresh): > https://secure-web.cisco.com/1rK_gNeYT4e2J9F4jyr9ob-AoDR-Lp- > iB5mTeyXixMqAIXbeSeEJn1erHjRJ0- > 0GxyQ64h4YLVLuyRMuzqwlxzjjsknm4CFxfLDXqF2io02ET0JqZUih5WbGRACe > W0cEeZ-QiPJ_76DF4kh0AsTYQDeARL2MwGCI- > eJWIs5uyFu5Lj5axi2XlAkkmk8Ng06nwt8rwDcnSdZn5fEBBWtvoQy3pg1XFKJ > uJXtChP1kTfJ84_DvB-ZUbTRGFczE5dIf72NSiAUclplLeIwi1C7DjuRxCH- > UaHH5DzVHZtUbW4- > PsL9LKn_zpNmAHdlMyc6xn/https%3A%2F%2Fwww.rfc- > editor.org%2Fauthors%2Frfc9560-diff.html (comprehensive diff) > https://secure-web.cisco.com/1xzoaugIAak54KtJ2B_k4PPf6gTQ-V- > 6B4Q59eOPY96NZmQb5Y48OYtilnN6UcXva5J8Ig7V7vjd1wAWizR74Fufmz57 > UN3wVnRBiE2ztD1ktgldzFuHL9gyI1_VqIuHG9edsyMRv29DIasd1S_gh- > GAiFf2tcAi-95- > FLXa8L3gLZoKWCUMUTWIZ3tdW6GOqTS3RCc41fagGiIfyvKMkORVqkIvV1S- > oF_cVKmfsWPcmZQEkCoR7228NgublQZZF0RMs5RxxwpZmtkonD1T5I1helEEz > _jPH1vh2ZckvEN1xV0j1w2qt0C-YcwikuFts/https%3A%2F%2Fwww.rfc- > editor.org%2Fauthors%2Frfc9560-auth48diff.html (AUTH48 changes only) > > Note that it may be necessary for you to refresh your browser to view the > most recent version. > > For the AUTH48 status of this document, please see: > https://secure-web.cisco.com/1KTE2nE21cNEGM6fsZJd9M9L-8vreZvq- > rIZBKNCQ85sqib8U1mgXoB1pbOfy1K8TKRV5-ZkI- > 3WLCgTmaT6nMEbauoD3lxBt8nUXbiXK_3yPnUSRxy4kJJlV8CTOebuj2omzHYt > DNNNjxXF7MJcccJWaom9VBtN- > ERyCIKMbQtpQxTekVF1Ud2qEuU8VqGrCSdXx43IoSDbyUHLllrZGlP7zY3P_71L > OnRl_Q4AJV- > EoBQ2dFxjwJ8Fad1kxwgX9iaOMAB1AwKL2tlGxaVCAu1Fvjj3b72ZrkTny_kFrtk > CTvAkd2LI0HqWz0-S1eiHq/https%3A%2F%2Fwww.rfc- > editor.org%2Fauth48%2Frfc9560 > > Thank you, > RFC Editor/st > > > > On Apr 8, 2024, at 11:00 AM, Hollenbeck, Scott > <shollenbeck=40verisign.com@dmarc.ietf.org> wrote: > > > > Thanks for your suggestions and questions. I've added my replies below. > > > > Scott > > > >> -----Original Message----- > >> From: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> > >> Sent: Friday, April 5, 2024 5:54 PM > >> To: Hollenbeck, Scott <shollenbeck@verisign.com> > >> Cc: rfc-editor@rfc-editor.org; regext-ads@ietf.org; > >> regext-chairs@ietf.org; AlBanna, Zaid <zalbanna@verisign.com>; > >> superuser@gmail.com; auth48archive@rfc-editor.org > >> Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9560 > >> <draft-ietf-regext-rdap- > >> openid-27> for your review > >> > >> Caution: This email originated from outside the organization. Do not > >> click links or open attachments unless you recognize the sender and > >> know the content is safe. > >> > >> Authors, > >> > >> While reviewing this document during AUTH48, please resolve (as > >> necessary) the following questions, which are also in the XML file. > >> > >> 1) <!-- [rfced] To improve readability, would you like these > >> sentences to be formatted more like a list? > >> > >> Original: > >> This document uses the terms "client" and "server" as defined by RDAP > >> [RFC7480]. > >> > >> This document uses the terms "Access Token", "Authorization Code", > >> "Authorization Endpoint", "Authorization Grant", "Client > >> Authentication", "Client Identifier", "Protected Resource", "Refresh > >> Token", "Resource Owner", "Resource Server", and "Token Endpoint" > >> defined by OAuth 2.0 [RFC6749]; the terms "Claim Name", "Claim > >> Value", and "JSON Web Token (JWT)" defined by JSON Web Token (JWT) > >> [RFC7519]; the terms "ID Token" and "UserInfo Endpoint" defined by > >> OpenID Connect Core 1.0 [OIDCC]; and the term "JWT Access Token" > >> defined by RFC 9068 [RFC9068]. > >> > >> Perhaps: > >> This document uses the following terminology. > >> > >> Terms defined by [RFC7480]: > >> > >> * client > >> * server > >> > >> Terms defined by [RFC6749]: > >> > >> * Access Token > >> * Authorization Code > >> * Authorization Endpoint > >> * Authorization Grant > >> * Client Authentication > >> * Client Identifier > >> * Protected Resource > >> * Refresh Token > >> * Resource Owner > >> * Resource Server > >> * Token Endpoint > >> > >> Terms defined by [RFC7519]: > >> > >> * Claim Name > >> * Claim Value > >> * JSON Web Token (JWT) > >> > >> Terms defined by [OIDCC]: > >> > >> * ID Token > >> * UserInfo Endpoint > >> > >> Term defined by [RFC9068]: > >> > >> * JWT Access Token > >> --> > > > > [SAH] This is fine. > > > >> 2) <!--[rfced] As "capabilities" is plural, should "type" also be made plural? > >> Note that this sentence occurs twice in Section 3.1.3. > >> > >> Original: > >> An RDAP client sends an RDAP "help" query to an RDAP server to > >> determine the type and capabilities of the OpenID Providers that > >> are used by the RDAP server. > >> > >> Perhaps: > >> An RDAP client sends an RDAP "help" query to an RDAP server to > >> determine the types and capabilities of the OpenID Providers that > >> are used by the RDAP server. > >> --> > > > > [SAH] Yes, plural "types". > > > >> 3) <!-- [rfced] We suggest updating Sections 4.1 and 5.1.1 to use > >> definition lists <dl> instead of ordered lists <ol> because each item > >> is in the form of term and definition. Please let us know if this is acceptable. > >> --> > > > > [SAH] Yes, that's acceptable. > > > >> 4) <!-- [rfced] Please review each artwork element in the xml file. > >> Specifically, should any artwork element be tagged as sourcecode or > another element? > > > > [SAH] The artwork element was used to display sequence diagrams. It's not > source code, so I think the artwork elements can be left as-is. > > > >> Additionally, please review the "type" attribute for the sourcecode > >> elements in the XML file and let us know if any further changes are > >> needed. If the current list of preferred values for "type" > >> (https://secure- > >> > web.cisco.com/1SmMZVHCsNzI2WXHLS9Cl7LwVjGvHr397vUhaBYl4EvM_QK > >> > 31oZNnJi85unYFsxF5vDlTwJVWMwZO5wdAeZlpbunA3g3AKgkMPAEVZRr4- > >> aDUNSNvxerzmhLQP85lhU1iyz84mRwWnhVHwLyk5cluKlOoi9U6G- > >> JzwQCyhTowXr_21b8f-nDKh1oOY1XOVFTp6Y- > >> > EqOytCw1309r8HQE3i2_edpt6vTYcw6cTVps0jQKdUtPKrrPB8BuuULaI4GL8iB > >> k65o-vL-oFCWpZ49HbCP96r- > >> KJD2fax0vo4j4Coxk/https%3A%2F%2Fwww.rfc- > >> editor.org%2Fmaterials%2Fsourcecode-types.txt) does not contain an > >> applicable type, then feel free to suggest a new one. Also, it is > >> acceptable to leave the "type" attribute not set. > >> --> > > > > [SAH] I didn't see any sourcecode elements in the XML file. "sourcecode" > appears three times, and only in the comment above. > > > >> 5) <!-- [rfced] FYI - In Section 5.1, we updated the following > >> paragraph to a definition list, which matches the definition list in > >> Section 4.2. Please let us know if there are any objections. > >> > >> Original: > >> This specification describes two new data structures that are used to > >> return information to a session-oriented client: a "farv1_session" > >> data structure that contains information that describes an > >> established session, and a "farv1_deviceInfo" data structure that > >> contains information that describes an active attempt to establish a > >> session on a UI-constrained device. > >> > >> Current: > >> This specification describes two new data structures that are used to > >> return information to a session-oriented client: > >> > >> "farv1_session": A data structure that contains information that > >> describes an established session. > >> "farv1_deviceInfo": A data structure that contains information that > >> describes an active attempt to establish a session on a UI- > >> constrained device. > >> --> > > > > [SAH] That's fine. > > > >> 6) <!-- [rfced] FYI - In Sections 5.2.1, 5.2.2, 5.2.4.1, and 5.2.4.2, > >> we moved the instances of "NOTE:" regarding line wrapping into the > >> artwork to match RFC 8792. > >> --> > > > > [SAH] That's fine. > > > >> 7) <!-- [rfced] Should the following lines also appear within the > >> <artwork> element to match the examples in Sections 5.2.1 and 5.2.2? > >> > >> Section 4.2.1: > >> https://secure- > >> > web.cisco.com/1113pv331Ww1amx2sItr3suMCpJjoCeuz8QoSI9TMwdy5a2u > >> eIqRp6-96pfn0Eq0ef6w7_ow74OFRt1p8dOcO7xXXjY62vZdecKS0SAAvNlI- > >> > U21me5RwjymI3V3qOr35uuqMINvYIJ3WFExWOfqcV9p986DFcEVHDrSQ7z > >> wMX2iVPUYaN6Q_vvpPD2jAJqh- > >> D8orkzmpv9xlUDoAL8XTewfXPqi4cIDWCL_BXcwEd5V7Y7- > >> k4q226I7HKJT8ZDCHYMc4zgsxG8RnGkHRTLSv4t6- > >> > q8I3FBYRahIi9WQJx84/https%3A%2F%2Fexample.com%2Frdap%2Fdomain > >> %2Fexample.com%3Ffarv1_qp%3DlegalActions > >> > >> Section 4.2.2 > >> https://secure- > >> > web.cisco.com/1om323DtiaAEw0xP6n0YKzj5yKRrtGVVXUxwWGJu6biNEmCi > >> > zN1z2r2wtzk6ydH_v4415xqWURujVBZHRtizKO2PkXX5FQJ8AVumdHEUb6KR > >> Uj_LWDrJayjgKuL4p6UXOy9-5Trrk92t4z3Y1rpe- > >> lCHWQfAQpqGvxkxFMtCArr7yvcKSoWnG- > >> > wLvqzl0tQjdWQJRVIV35a6_Pz_EaG15Y6qS9hAu5EeWJNswmBEUTnWUI4wR > >> Lk6284oeL1MQNNQb8WlGqgQ9lkiCVHo44Sx0NGB3gq- > >> > 4Roo7EHukBUw1660/https%3A%2F%2Fexample.com%2Frdap%2Fdomain% > >> 2Fexample.com%3Ffarv1_dnt%3Dtrue > >> > >> Section 5.2.1: > >> https://secure- > >> > web.cisco.com/16yAuvu8AN84mbw625w2O7XKgdR19Ll3JMnguOYzR2vuq > >> M7U4NlGgYMFDAKZt6-wsysBluRAUpDsOxbJsyZIUKpPTm- > >> > 9xmG9h5AtAmrJ0zSxf17DFu0EkOiaajGHo6S5nf4zZBmQBPEudUcRsbgewqaX > >> KHpeZFIDLe0w2Br-9sVeNKk_Snwn9iBjQXSl- > >> > 4MmRDTtoHd7AgKOfltzU8JFBqfWiC3urDgN8FwzzH94epvB0shpZPsS21DkLR > >> phxEc4Rb_OU5BGam9as228MtiF1e5Z8sVm-PHMcg- > >> > lXa4tgrXw/https%3A%2F%2Fexample.com%2Frdap%2Ffarv1_session%2Flogi > >> n > >> ... > >> https://secure- > >> > web.cisco.com/16yAuvu8AN84mbw625w2O7XKgdR19Ll3JMnguOYzR2vuq > >> M7U4NlGgYMFDAKZt6-wsysBluRAUpDsOxbJsyZIUKpPTm- > >> > 9xmG9h5AtAmrJ0zSxf17DFu0EkOiaajGHo6S5nf4zZBmQBPEudUcRsbgewqaX > >> KHpeZFIDLe0w2Br-9sVeNKk_Snwn9iBjQXSl- > >> > 4MmRDTtoHd7AgKOfltzU8JFBqfWiC3urDgN8FwzzH94epvB0shpZPsS21DkLR > >> phxEc4Rb_OU5BGam9as228MtiF1e5Z8sVm-PHMcg- > >> > lXa4tgrXw/https%3A%2F%2Fexample.com%2Frdap%2Ffarv1_session%2Flogi > >> n > >> > >> Section 5.3: > >> https://secure- > >> > web.cisco.com/1dPdCKMspJLQEXvDjPdeIkRgQ4p8WZ7plWPdzNKvMs_e_h8E > >> > RMx4I0Cl5lue4S8zTgDLF1Xa1DUTVDECImGjjIMEzD8TSNn4jOUv9d_5I4K1O- > >> > b6IPLoKXXb509PA5iP8oSHUwS3kNWVXgDkVklyDq4pP14EC4R1NEELiWLhV7 > >> > rw_poNoDQxlZ5UqXjMP803uaaNFyRFXRJN_kQtUG8hnWndImN7tjh6VoMV > >> ei--b1-KxfqdRV62peojx2xEv-m-hr-cMwBYygIwOj20E2K4Ng- > >> > rMQcFO59eDa6V96f09Wg8/https%3A%2F%2Fexample.com%2Frdap%2Ffar > >> v1_session%2Fstatus > >> > >> Section 5.4: > >> https://secure-web.cisco.com/1idPQJA- > >> > Hy84EM4kSnQM_1dONZ_mOkQimBuSiYQ2s3PoNPsmxYBD4RJUZoDGID1DB > >> dMxJBDkOF- > >> > y2NgMWCpwVddWQNKLSGrGkkpocXefnA2ZfSadyUwD_I96dVqNBn2EGs1b > >> QnAp8BkrMsG_jU7ZWhTGRZ- > >> > gEJe8_GbCJCwEK2kTXCQCHvhcBG7AQ2QtditgZxBhQSXLO6U1UaHrgL7Q_JKX > >> - > >> > BnMevtzc8IpZ8bJbASKT2BUpML9P47IjqvL2xz4l_UG8rM9Q02jjcl9BeRL7HDN > >> 7DcB3FQqwr- > >> > mNLoW8Bbs/https%3A%2F%2Fexample.com%2Frdap%2Ffarv1_session%2Fr > >> efresh > >> > >> Section 5.5: > >> https://secure- > >> > web.cisco.com/1j6nbaaJZIgxAdoev_dQn3krOPFky3QfwGCvFXCspP3Aphwab > >> 1utQli7fGIFtx54QZMD4tMBC09rnDaUjMc- > >> 5aLxkbr6stKPYkhhPLC7EhCaKOka3b1oW9c- > >> SWOfnveEROZ1PZLhADbUEdNL2HGhb- > >> EdkMNFg8LRGy12zsOhxxCjqUJkfpI7u1hpoxdbCpRgaGDB3- > >> 8KI6Q3km7jy4YZbiqwzs96nrNjlVNiU5Tsiw69nMD0a8SopdQjzK-Pv_- > >> 24JhgRdGnaxvaDE_HhnPcqfL6aGYV8FXPpiAc- > >> > _JzkEks/https%3A%2F%2Fexample.com%2Frdap%2Ffarv1_session%2Flogout > >> --> > > > > [SAH] I'd like to trust your judgment for each of these. They're all examples, > and if it's preferable to mark them as artwork for display/font consistency > purposes, that's fine with me. > > > >> 8) <!-- [rfced] To match common usage, would you like to update > >> "smart telephone" > >> to "smartphone"? > >> > >> Original: > >> This method requires an End-User to use a > >> second device (such as a smart telephone) that has access to a web > >> browser for entry of a code sequence that is presented on the UI- > >> constrained device. > >> --> > > > > [SAH] Sure, that's fine. > > > >> 9) <!--[rfced] Would using a list improve the readability of this text? > >> > >> Original: > >> The requests described in this document are typically performed in a > >> specific sequence: "farv1_session/login" (or the related > >> "farv1_session/device" and "farv1_session/devicepoll" requests) to > >> start a session, "farv1_session/status" and/or "farv1_session/ > >> refresh" to manage a session, and "farv1_session/logout" to end a > >> session. > >> > >> Perhaps: > >> The requests described in this document are typically performed in a > >> specific sequence: > >> > >> 1. "farv1_session/login" (or the related "farv1_session/device" and > >> "farv1_session/devicepoll" requests) to start a session, > >> > >> 2. "farv1_session/status" and/or "farv1_session/refresh" to manage a > >> session, and > >> > >> 3. "farv1_session/logout" to end a session. > >> --> > > > > [SAH] Yes, that works. > > > >> 10) <!--[rfced] IANA Considerations > >> > >> A) Since the Value and Description columns are defined in Section 9.3 > >> for the "Registration Data Access Protocol (RDAP) Query Purpose Values" > >> registry, should a definition for the Reference column also be > >> included? And should "Reference: RFC 9560" be added to each entry to > match the registry? > > > > [SAH] Yes, please. > > > >> B) To make the Description of domainNameControl more concise, may we > >> update it as follows? > >> > >> Original: > >> Value: domainNameControl > >> > >> Description: Tasks within the scope of this purpose include > >> creating and managing and monitoring a registrant's own domain > >> name, including creating the domain name, updating information > >> about the domain name, transferring the domain name, renewing the > >> domain name, deleting the domain name, maintaining a domain name > >> portfolio, and detecting fraudulent use of the Registrant's own > >> contact information. > >> > >> Perhaps: > >> Value: domainNameControl > >> > >> Description: Tasks within the scope of this purpose include, for a > >> registrant's own domain name, creating the domain name, updating > >> information about the domain name, transferring the domain name, > >> renewing the domain name, deleting the domain name, maintaining a > >> domain name portfolio, and detecting fraudulent use of the > >> registrant's own contact information. > > > > [SAH] Sure, that works. It differs from the definition found in the EWG > report, though. Perhaps we should also change the text that describes the > source of the values, changing "taken from" to "derived from" or "based on". > > > > OLD: > > The set of initial values used to populate the registry as described > > below are taken from the final report produced by the Expert Working > > Group on gTLD Directory Services chartered by the Internet Corporation > > for Assigned Names and Numbers (ICANN) > > > > NEW: > > The set of initial values used to populate the registry as described > > below are derived from the final report produced by the Expert Working > > Group on gTLD Directory Services chartered by the Internet Corporation > > for Assigned Names and Numbers (ICANN) > > > >> C) To reflect the verbiage of other Descriptions in the "Registration > >> Data Access Protocol (RDAP) Query Purpose Values" registry, may we > >> update the Description of regulatoryAndContractEnforcement as follows? > >> > >> Original: > >> Value: regulatoryAndContractEnforcement > >> > >> Description: Tasks within the scope of this purpose include tax > >> authority investigation of businesses with online presence, > >> Uniform Dispute Resolution Policy (UDRP) investigation, > >> contractual compliance investigation, and registration data escrow > >> audits. > >> > >> Perhaps: > >> Value: regulatoryAndContractEnforcement > >> > >> Description: Tasks within the scope of this purpose include > >> investigating the tax authority of businesses with online presences, > >> investigating Uniform Domain-Name Dispute-Resolution Policy (UDRP), > >> investigating contractual compliance, and registering data escrow > >> audits. > >> --> > > > > [SAH] Yes, as noted above. > > > >> 11) <!--[rfced] Instead of using a link, may we update this sentence > >> to use a citation and add a reference entry to the Informative References > section? > >> > >> Original: > >> The set of initial values used to populate the registry as described > >> here are taken from the final report > >> (https://secure- > >> > web.cisco.com/15_7KMQ1muuBMyg88fsOKiXbzC1YP0hULXYkxdtakqMbgIjJ > >> p-YA6ZzpDn0Y0fone3lxH1jpKNAi7Bm89CSebT8Jz- > >> v40hlEM_g4HqMaL3IoGvBF87KO9ZTJsamgc- > >> HwF6_muMSplS_8Vc8Yhhr2CGdwTn02HJ_YO-pk- > >> > hfFsQgOgazEiNGMBCxM0J6uuiCFEZTuFH4p52UpSIJ_BUshQtU36TNqKsFumv > >> > iilZuS3lKLfmhqrcmsxTWOQ3k7QUdTkETfUKreIn9FMGKkEuq3G_qF5hxHo1dQ > >> > ybhpCs5NVdCw/https%3A%2F%2Fwww.icann.org%2Fen%2Fsystem%2Ffiles > >> %2Ffiles%2Ffinal-report- > >> 06jun14-en.pdf) produced by the Expert Working Group on gTLD > >> Directory Services chartered by the Internet Corporation for Assigned > >> Names and Numbers (ICANN). > >> > >> Perhaps: > >> The set of initial values used to populate the registry as described > >> below are taken from the final report produced by the Expert Working > >> Group on gTLD Directory Services chartered by the Internet Corporation > >> for Assigned Names and Numbers (ICANN) [gTLD]. > >> ... > >> [gTLD] Expert Working Group on gTLD Directory Services (EWG), "Final > >> Report from the Expert Working Group on gTLD Directory Services: > >> A Next-Generation Registration Directory Service (RDS)", June > >> 2014, <https://secure- > >> > web.cisco.com/15_7KMQ1muuBMyg88fsOKiXbzC1YP0hULXYkxdtakqMbgIjJ > >> p-YA6ZzpDn0Y0fone3lxH1jpKNAi7Bm89CSebT8Jz- > >> v40hlEM_g4HqMaL3IoGvBF87KO9ZTJsamgc- > >> HwF6_muMSplS_8Vc8Yhhr2CGdwTn02HJ_YO-pk- > >> > hfFsQgOgazEiNGMBCxM0J6uuiCFEZTuFH4p52UpSIJ_BUshQtU36TNqKsFumv > >> > iilZuS3lKLfmhqrcmsxTWOQ3k7QUdTkETfUKreIn9FMGKkEuq3G_qF5hxHo1dQ > >> > ybhpCs5NVdCw/https%3A%2F%2Fwww.icann.org%2Fen%2Fsystem%2Ffiles > >> %2Ffiles%2Ffinal-report- > >> 06jun14-en.pdf>. > >> --> > > > > [SAH] Yes, as noted above. > > > >> 12) <!-- [rfced] References > >> > >> A) The following OpenID Connect references appear to have been > >> superseded by 2023 versions. As we were unable to find URLs to the > >> previous versions, we have updated them to reflect the most current > versions. > >> > >> Original: > >> [OIDCC] OpenID Foundation, "OpenID Connect Core incorporating > >> errata set 1", November 2014, > >> <https://secure- > >> > web.cisco.com/1j1jAbYtrpDW_cjsb8d1REltF3dUV0S_aPF06IbjmRFMNGz7hg > >> hkBv2QkTL8zV1G3II8Y7rYmy8vkHLcbI- > >> KrHg_tban0mgoD3ArBeeS8a_q8R5ldrcL26F8EAJ794eePy26- > >> > e2SOSdGC5NNljmWcUZVGj8CbxEV4le3b5b7RQwVObka76oLaDp9PdQjpECV > >> _tlOA2T- > >> > ZxlGosrCpbgKbCmd70XoJZPDvFeMJl55WSpU8Vt_6_I_zhyssET6RwGvoo0ligZ > >> R9v- > >> > SWpD5xko6ME1KpCtbwLyLijtv_VuJiBzI/https%3A%2F%2Fopenid.net%2Fspe > >> cs%2Fopenid-connect-core-1_0.html>. > >> > >> Current: > >> [OIDCC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and > >> C. Mortimore, "OpenID Connect Core 1.0 incorporating > >> errata set 2", December 2023, > >> <https://secure- > >> > web.cisco.com/1j1jAbYtrpDW_cjsb8d1REltF3dUV0S_aPF06IbjmRFMNGz7hg > >> hkBv2QkTL8zV1G3II8Y7rYmy8vkHLcbI- > >> KrHg_tban0mgoD3ArBeeS8a_q8R5ldrcL26F8EAJ794eePy26- > >> > e2SOSdGC5NNljmWcUZVGj8CbxEV4le3b5b7RQwVObka76oLaDp9PdQjpECV > >> _tlOA2T- > >> > ZxlGosrCpbgKbCmd70XoJZPDvFeMJl55WSpU8Vt_6_I_zhyssET6RwGvoo0ligZ > >> R9v- > >> > SWpD5xko6ME1KpCtbwLyLijtv_VuJiBzI/https%3A%2F%2Fopenid.net%2Fspe > >> cs%2Fopenid-connect-core-1_0.html>. > >> ... > >> Original: > >> [OIDCD] OpenID Foundation, "OpenID Connect Discovery 1.0 > >> incorporating errata set 1", November 2014, > >> <https://secure- > >> web.cisco.com/1mwliIUdewEEDtBi9G_tscxkHtmPkQFm6nBHjgd3ixXC- > >> TBalT57OQDT- > >> > 9ydSvkU1S_DxFmPA1BnpsQtxZFhrirWQ7ObZ5JRamqUBvDxQ6HrXcF0wZ_fQ > >> Gc3W8ZC0q3nGWXcTed4EYwF_F7- > >> > AWqhRMHki2BYYwK_z9zrrjKI57bWnO2oPCXa7n5pUXPGxCXaezNjnoTf7TE_l > >> XpAbCf276zLQxHyW6Mm5FbkD_Q0VNlMBi6SxzFXuo- > >> > I5zAn6WwEEzw6N20B1bTWswXrb80xMZgfLOTDd3IJMLRrsFIKl6iM/https%3 > >> A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-discovery- > >> 1_0.html>. > >> > >> Current: > >> [OIDCD] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID > >> Connect Discovery 1.0 incorporating errata set 2", > >> December 2023, <https://secure- > >> > web.cisco.com/1foVjwVGURxqOSSouI6iMZEbTCbAlkZLskB1ero3uM0FkjBJ8T > >> > BLMauKA4YYOGSLfGI5ZJ6rnxKCxaALugf6wk5f9wUvwCZU5A3Zc15BUsdDAO > >> XPkh5E4ZU5yTNVerJM0sX8UmF_hQG5sp7FHPoFX3iRp2bBlEfOtoElKcZ3y- > >> > jGh7fBDFPjI5NyhMzji201YgzzrplEYQ5UPTWkhfPZFGP1ro1yxy24aOz6AAFI76 > >> > 0XPpRT__Muu4XLI7gE6pNPaoeblQ_a0VzgwLdMVjcLZUWtQKs1BM8LXl8DYY > >> AeiIDo/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect- > >> discovery-1_0.html>. > >> ... > >> Original: > >> [OIDCR] OpenID Foundation, "OpenID Connect Dynamic Client > >> Registration 1.0 incorporating errata set 1", November > >> 2014, <https://secure- > >> > web.cisco.com/1foVjwVGURxqOSSouI6iMZEbTCbAlkZLskB1ero3uM0FkjBJ8T > >> > BLMauKA4YYOGSLfGI5ZJ6rnxKCxaALugf6wk5f9wUvwCZU5A3Zc15BUsdDAO > >> XPkh5E4ZU5yTNVerJM0sX8UmF_hQG5sp7FHPoFX3iRp2bBlEfOtoElKcZ3y- > >> > jGh7fBDFPjI5NyhMzji201YgzzrplEYQ5UPTWkhfPZFGP1ro1yxy24aOz6AAFI76 > >> > 0XPpRT__Muu4XLI7gE6pNPaoeblQ_a0VzgwLdMVjcLZUWtQKs1BM8LXl8DYY > >> AeiIDo/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect- > >> registration-1_0.html>. > >> > >> Current: > >> [OIDCR] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect > >> Dynamic Client Registration 1.0 incorporating errata set > >> 2", December 2023, <https://secure- > >> web.cisco.com/1BgqlLr8mYHntx0CQL- > >> > 548Z19ntEk4GaRDvAThFUaCouk9Cdn6X1FlvhG0ApA15HoOJLinkyEXeaZXSCd > >> XxWv-FSHNlzZGxtJhaynNGk-kuUrNG_Kin4ndHeLggDE4fsZryl5- > >> jhBITg06zWfekW9kf- > >> ZVskfDMGL8tRUOuZwDLyYdLVOW119aVIlw3BcRd9uRazoilk- > >> jtiIz0pdZNKFmJG-Q- > >> > GY092waBpjU448s8nnRBUD3FarrAlUivIWjjmZPmcsalqDbniZmayJoZouefWK > >> aAK65akwm7YXIzc- > 2G4/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid- > >> connect-registration-1_0.html>. > > > > [SAH] Those are all fine. Those updates were published after the document > was reviewed by the IESG. > > > >> B) As the "application/x-www-form-urlencoded" section is mentioned > >> within the body of the document when [HTMLURL] is cited, we have > >> updated the URL of this reference to link to the whole document > >> rather than the specific section. > >> > >> Original: > >> [HTMLURL] Web Hypertext Application Technology Working Group > >> (WHATWG), "URL (Living Standard)", September 2023, > >> <https://secure- > >> > web.cisco.com/1fcFtvLynBykC28ML19oHed0Q593AEcIVLh4z2t08TFyNPA2C > >> > 7Uya4REl4Wib4PSiaJ3ieNBO1q4QCDfKZt0tAqJrqcztRWZo4EX_CXfHOVhNEK > >> > Vdqm45GP6oQAhUp_wmIvmH3kQ0PpFyK4djtn0VffCjObOeqoxcp3D4fuvbt > >> > w738FJC97VwmOZMN4WjkX1BhmPFW0WAB0O00GuLSSJ4Gw9fnI5bA8gtL > >> eHWIs58_TcLRRMJQReJBHbqmnkA- > >> > jaks4PYICHJc3zG58LbF9YErMJWhWDPejZVTSBfX_WnBbo/https%3A%2F%2F > >> url.spec.whatwg.org%2F%23application%2Fx-www-form- > >> urlencoded>. > >> > >> Current: > >> > >> [HTMLURL] WHATWG, "URL (Living Standard)", March 2024, > >> <https://secure- > >> web.cisco.com/1FIyZHErwYvQfB9GqHd7V9igs79n9795A_gO6- > >> V5pHiO21vHJ- > >> > Qb6k4FaFhmQOUGOoJQvIlGKeCaHI9pn7R_DyTWZsOtz0CxgDz4c7k6323DCS > >> > gLuflXZIRI9ytdUYnrt26tbKNSSEnMcNR7bg88hvwMie47brh4RKH1rzJcW4L40 > >> R1OJeqb3EpLAxoXQUicUEy5ZuE-pmEYtZ5RvGzq4bN- > >> > qfH61l419cyXPTwRrZHzKNgoZaaPDEYpxubZ1tCn0j8ACdKb0qIOZf3DCBfll8vx > >> hiCYvxmkoCqjoVxFRXXM/https%3A%2F%2Furl.spec.whatwg.org%2F>. > >> --> > > > > [SAH] That's fine. > > > >> 13) <!-- [rfced] Throughout the text, when citing non-RFC section > >> numbers, the formats somewhat vary. For simplicity, would you like to > >> update all instances to the following format to match how RFCs are > >> referenced? Note that we haven't included every example below. > >> > >> Current: > >> the "application/x-www-form-urlencoded" section of > >> WHATWG URL Standard [HTMLURL] > >> ... > >> Section 5 of the OpenID Connect Core protocol [OIDCC] > >> > >> Perhaps: > >> Section "application/x-www-form-urlencoded" of > >> [HTMLURL] > >> ... > >> Section 5 of [OIDCC] > >> --> > > > > [SAH] Yes, that's fine. > > > >> 14) <!-- [rfced] Terminology > >> > >> A) The following terms are capitalized in the text but are lowercase > >> in the corresponding cited RFCs. Should these be made lowercase to > >> match the corresponding RFCs? > >> > >> Lowercase in RFC 6749: > >> Access Token > >> Authorization Code > >> Authorization Code Flow > >> Authorization Endpoint > >> Authorization Grant > >> Token Endpoint > >> Token Request > >> Token Response > >> > >> Lowercase in RFC 6750: > >> "Bearer" authentication scheme > >> > >> Lowercase in RFC 8628 and only hyphenated when in attributive > >> position (i.e., when followed by a noun): > >> End User > >> > >> Lowercase in RFC 9068: > >> JWT Access Token > >> > >> Additionally, should "Authorization Request" also be made lowercase > >> to parallel usage in other previously published RFCs? > > > > [SAH] Yes, please be consistent with other RFCs. > > > >> B) The following terms appear to be used inconsistently throughout > >> the document. Should they be made lowercase for consistency and to > >> match the corresponding cited RFCs? > >> > >> Lowercase in RFC 6749: > >> Client Authentication vs. client authentication > >> Client Identifier vs. client identifier > >> Protected Resource vs. protected resource > >> Refresh Token vs. refresh token > >> Resource Owner vs. resource owner > >> Resource Server vs. resource server > >> > >> Lowercase in RFC 6750: > >> "Authorization" header vs. authorization header > >> > >> Not consistently capitalized in RFC 7519: > >> Claim Value vs. claim value > > > > [SAH] Yes, please be consistent. > > > >> C) Throughout the text, the following terminology appears to be used > >> inconsistently. May we update to the version on the right to match > >> more common usage? > >> > >> Identity Provider > identity provider > >> issuer identifier > Issuer Identifier > >> RDAP Client > RDAP client > >> RDAP Server > RDAP server > >> End-User Identifier > end-user identifier > > > > [SAH] Yes, please match common use. > > > >> D) Might it be helpful to the reader to clarify the slash in cases > >> like the following (i.e., does it stand for "and", "or", or > >> "and/or")? Note that this appears in several places; the following is just an > example. > >> > >> Original: > >> An RDAP server/RP needs to be able to map an End-User's identifier to > >> an OP. > >> > >> Perhaps: > >> An RDAP server or RP needs to be able to map an End-User's identifier > >> to an OP. > > > > [SAH] That’s fine. > > > >> E) We see "farv1" expanded two different ways. May we update both > >> instances to the following to be consistent? > >> > >> Current: > >> Federated Authentication for RDAP version 1 > >> ... > >> version 1 of a federated authentication method for RDAP > >> > >> Perhaps: > >> federated authentication method for RDAP version 1 > > > > [SAH] Yes, that's fine. > > > >> F) FYI - To match the OpenID Connect Core 1.0 reference, we updated > >> one instance of "ID token" to "ID Token". Please let us know if there > >> is any objection. > >> --> > > > > [SAH] No objection. > > > >> 15) <!--[rfced] Acronyms > >> > >> A) FYI - We have added expansions for abbreviations upon first use > >> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > >> expansion in the document carefully to ensure correctness. > >> > >> Representational State Transfer (RESTful) > > > > [SAH] That's fine. > > > >> B) For the term "OpenID Provider", may we update the first instance > >> to be "OpenID Provider (OP)" and all subsequent instance to "OP"? > >> --> > > > > [SAH] Yes, that's fine. > > > >> 16) <!--[rfced] Please review the "Inclusive Language" portion of the > >> online Style Guide <https://secure- > >> > web.cisco.com/1VMcTDIlJnnotcZuv_P4j8x8ITPnfdvnF4etNChbQ9ZDF1J4p7 > >> W2Jod45sBwOz5vqggmjCYV4a49lwGilAzD9Dam6rx6fXsBgMzYjDi56HJbIs- > >> 7DQb1DRBAC1vd- > >> 4LKGwKv3zO0Plpborkr4losGEF4zjRLBrLO9B71PCTpcwfgmBvTP4Zuk6D- > >> > oBoYJtVoTDmNBd2YLJBFv7RUuTk7v8wgS_8wjoBcy6AWjSGmztXSTEQQJzPdA > >> > B50nGoFZe3rPRBZ5d3MBPRVF0iJMMTzSmpXHYySQ8ByFZvBqAP4F1lc/https > >> %3A%2F%2Fwww.rfc- > >> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language> > >> and let us know if any changes are needed. > >> > >> Note that our script did not flag any words in particular, but this > >> should still be reviewed as a best practice. > >> --> > > > > [SAH] I didn't see anything that required change. > > > > I didn't see anything else in my review of the RFC. Thanks again! > > > > Scott >
- [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-regex… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-r… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-r… Hollenbeck, Scott
- Re: [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-r… Sarah Tarrant
- Re: [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-r… Hollenbeck, Scott
- Re: [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-r… Sarah Tarrant
- Re: [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-r… Hollenbeck, Scott
- [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-regex… Sarah Tarrant
- Re: [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-r… Hollenbeck, Scott
- [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-regex… Sarah Tarrant
- Re: [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-r… Hollenbeck, Scott
- [auth48] [IANA] AUTH48: RFC-to-be 9560 <draft-iet… Sarah Tarrant
- [auth48] [IANA #1363266] [IANA] AUTH48: RFC-to-be… David Dong via RT
- Re: [auth48] [IANA #1363266] [IANA] AUTH48: RFC-t… Sarah Tarrant
- [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-regex… Sarah Tarrant