Re: [auth48] AUTH48: RFC-to-be 9560 <draft-ietf-regext-rdap-openid-27> for your review
Sarah Tarrant <starrant@amsl.com> Thu, 11 April 2024 17:48 UTC
Return-Path: <starrant@amsl.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 E3C2AC151090; Thu, 11 Apr 2024 10:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 yBx99IIGVB3Y; Thu, 11 Apr 2024 10:48:11 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024E0C151087; Thu, 11 Apr 2024 10:48:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E3183424B432; Thu, 11 Apr 2024 10:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jA5Qf3b5388K; Thu, 11 Apr 2024 10:48:10 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2600:1700:8f1d:4000:d8cf:f1b2:dd42:bcdd]) by c8a.amsl.com (Postfix) with ESMTPSA id 30D1F424B427; Thu, 11 Apr 2024 10:48:10 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
From: Sarah Tarrant <starrant@amsl.com>
In-Reply-To: <94106941ea1449eaa9c768edeea238c7@verisign.com>
Date: Thu, 11 Apr 2024 12:47:59 -0500
Cc: RFC Editor <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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D6C21C1-753E-473C-B13C-6C9B9C7F9928@amsl.com>
References: <20240405215407.0FA11192F7B5@rfcpa.amsl.com> <0becadf40961493f84b9c887b122c191@verisign.com> <F602EDA7-3CE3-40C1-A6BE-DBF9A4BB0346@amsl.com> <94106941ea1449eaa9c768edeea238c7@verisign.com>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/wFea1dqCdrN6ersTTXdLxBFHttI>
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 17:48:15 -0000
Hi Scott, Thank you for letting us know. We look forward to hearing from you. Sincerely, RFC Editor/st > On Apr 11, 2024, at 8:35 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote: > > 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