Code change:
This rewrites the context-free URI section to give more context. It also moves the section out from underneath the example identifiers section, and into a proper sub-section of the top level "User Equipment Identity" section. Closes issue
NAME , I mostly took your text word-for-word. Thanks for it!
A reviewer writes, I think this is trying to say the server should not be looking at Ethernet addresses, for example, because the server is probably not on the same subnet as the User Equipment. So the info needs to be in the URL. Figure out what we're trying to say, and whether this is the right section for it.
That's exactly what it's talking about. That said, while it is related to identifying the UE, it's not an example identifier. It has been a while since I thought about this, and I wasn't at the meeting where it was discussed, but I think the intention here was to limit any URIs provide in the API to these context-free URIs. That is, the resource pointed to by the URI cannot depend on information not present in the URI. For example, the API draft (URL) provides a 'user-portal-url'. Suppose that URL is "captive-URL". That resource could be implemented by checking the source ethernet address of the connection to see if you're already logged in. But, that won't be correct if you're not in the same subnet. Instead, the URL should be something like: "captive-URL" So, this is more of a constraint on the API and how it uses identifiers than an example of an identifier. Did we just get the indentation wrong? Or was this a misunderstanding of what the working group requested?
Maybe all this needs is a preface explaining how some systems operate. The last two paragraphs are a direct copy of existing text.
Hardly surprising that I think this is OK :)

Related discussion:
text: addresses on a single link.  In such cases, identification could be performed by subnet, such as the /64 to which the IP belongs. <del> 3.4.3. The URIs provided in the API SHOULD contain all the information 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 URIs is correct and meaningful to the User Equipment, even when accessed from a network other than the one that contains the captive portal.  One consequence of this is that URIs provided in the API are expected to be resolved using public global DNS (as defined in Section 2 of RFC8499). </del> <ins> 3.5. A Captive Portal API needs to present information to clients that is unique to that client.  To do this, some systems use information from the context of a request, such as the source address, to identify the UE. Using information from context rather than information from the URI allows the same URI to be used for different clients.  However, it also means that the resource is unable to provide relevant information if the UE makes a request using a different network path. This might happen when UE has multiple network interfaces.  It might also happen if the address of the API provided by DNS depends on where the query originates (as in split DNS RFC8499). Accessing the API MAY depend on contextual information.  However, the URIs provided in the API SHOULD be unique to the UE and not dependent on contextual information to function correctly. </ins> Though a URI might still correctly resolve when the UE makes the request from a different network, it is possible that some functions