Change:
This replaces any 'URL' terminology with 'URI'. It also adds an informative reference to RFC 3986 , as suggested. Fixes issue
Multiple reviewers have suggested that we use URI instead of URL. I think we should make this change, and add the informative reference.

Discussion:
2.2. Here we discuss candidate mechanisms for provisioning the User <del> Equipment with the URL of the API to query captive portal state and </del> <ins> Equipment with the URI of the API to query captive portal state and </ins> navigate the portal. 2.2.1. <del> A standard for providing a portal URL using DHCP or Router </del> <ins> A standard for providing a portal URI using DHCP or Router </ins> Advertisements is described in RFC7710bis.  The CAPPORT architecture <del> expects this URL to indicate the API described in section_api. </del> <ins> expects this URI to indicate the API described in section_api. </ins> 2.2.2. Although still a work in progress, I-D.pfister-capport-pvd proposes a mechanism for User Equipment to be provided with PvD Bootstrap <del> Information containing the URL for the JSON-based API described in </del> <ins> Information containing the URI for the JSON-based API described in </ins> section_api. 2.3.

the need for User Equipment to perform clear-text "canary" HTTP queries to check for response tampering. <del> The URL of this API will have been provisioned to the User Equipment. </del> <ins> The URI of this API will have been provisioned to the User Equipment. </ins> (Refer to section_provisioning). This architecture expects the User Equipment to query the API when

the equipment. At minimum, the API MUST provide: (1) the state of captivity and (2) <del> a URL for the Captive Portal Server.  The API SHOULD provide evidence </del> <ins> a URI for the Captive Portal Server.  The API SHOULD provide evidence </ins> to the caller that it supports the present architecture. When User Equipment receives Captive Portal Signals, the User

3.4.3. <del> The URLs provided in the API SHOULD contain all the information </del> <ins> The URIs provided in the API SHOULD contain all the information </ins> necessary to render the resources requested: the resources should not depend on ambient information, such as remote address on the connection.  This is to ensure that the content served from these <del> URLs is correct and meaningful to the User Equipment, even when </del> <ins> URIs is correct and meaningful to the User Equipment, even when </ins> accessed from a network other than the one that contains the captive <del> portal.  One consequence of this is that URLs provided in the API are </del> <ins> portal.  One consequence of this is that URIs provided in the API are </ins> expected to be resolved using public global DNS (as defined in Section 2 of RFC8499). <del> Though a URL might still correctly resolve when the UE makes the </del> <ins> Though a URI might still correctly resolve when the UE makes the </ins> request from a different network, it is possible that some functions could be limited to when the UE makes requests using the captive network.  For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection. <del> URLs could include some means of identifying the User Equipment in the URLs.  However, including unauthenticated User Equipment identifiers in the URL may expose the service to spoofing or replay </del> <ins> URIs could include some means of identifying the User Equipment in the URIs.  However, including unauthenticated User Equipment identifiers in the URI may expose the service to spoofing or replay </ins> attacks. 4.

4.3. <del> A different Captive Portal API URL could be returned in the following </del> <ins> A different Captive Portal API URI could be returned in the following </ins> cases: <del> Whenever a new Portal URL is received by end User Equipment, it SHOULD discard the old URL and use the new one for future requests to </del> <ins> Whenever a new Portal URI is received by end User Equipment, it SHOULD discard the old URI and use the new one for future requests to </ins> the API. 5.

Architecture RFC7556 provides some discussion on authenticating an operator. <del> Given that a user chooses to visit a Captive Portal URL, the URL </del> <ins> Given that a user chooses to visit a Captive Portal URI, the URI </ins> location SHOULD be securely provided to the user's device.  E.g., the DHCPv6 AUTH option can sign this information.