Draft: draft-ietf-capport-architecture

Commentary: 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 
 , 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 was n'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 can not depend on information not present in the URI . For example , the API draft ( ) provides a ' user - portal - url ' . Suppose that URL is " captive- " . That resource could be implemented by checking the source ethernet address of the connection to see if you 're already logged in . But , that wo n't be correct if you 're not in the same subnet . Instead , the URL should be something like : " captive-<user - equipment - id " 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 :)
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).
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.