Draft: draft-ietf-capport-api

Commentary: Removed language for /.well - known URI . Made serving over port 443 a SHOULD requirement . Other editorial changes 
 Added your updated language , should be good to go . 
 I do n't think that we need this . 7710 gives us an entire URI , as can PvD. 
 I agree that we can use the URI from the DHCP option or from PvD. The reason I went this route was to avoid the scheme that was in the API draft to start with , which seemed to be : If you access the 7710 URI with a GET , you 'll receive the HTTP for the user interactive portal If you access the 7710 URI with a POST , you 'll get the JSON API That seemed problematic ( a ) because it implies the user portal and API are co - located and ( b ) it seemed overly complex . Do you have a preference for what methods are valid to access the JSON API , and whether we should specify that the URI needs to be JSON ? My concern was that if the DHCP option or whatever pointed to something that was clearly .html , something 's wrong , and using a well - known JSON URI to compare against would be a way to detect that . 
 Thoughts on the method for fetching the JSON API , or if that 's a non - issue ? 
 Let 's take this to the list . 
 PR fixes the well - known URI language . For now there is indication of Accept and Conent - Type header usage but we have n't explicitly called it out until we get a final decision . We can close this issue though .
This document describes an HTTP API that allows hosts to interact
with a Captive Portal system on a local network.
This document describes an HTTP API that allows hosts to interact
with a Captive Portal system.
This document is focused on the second step.  It is assumed that the
location of the Captive Portal API server has been provisioned as
part of the first step.  The mechanism for discovering this value not
covered by this document.
In order to communicate with the captive portal API server, the URI
provisioned to the host SHOULD use the form of a well-known URI
RFC5785 ending with the string ".well-known/captive-portal.json".  If
this suffix is not included in the URI already provisioned, a host
SHOULD append the suffix when communicating to the server.
The Captive Portal API MUST be accessed using HTTP over TLS on TCP
port 443 (HTTPS) RFC2818.
For example, if the Captive Portal API server is hosted at
example.org, the URI of the API would be: "https://example.org/.well-
known/captive-portal.json".
This document is focused on the second step.  It is assumed that the
location of the Captive Portal API server has been discovered by the
host as part of the first step.  The mechanism for discovering the
API Server endpoint is not covered by this document.
The URI of the API endpoint MUST be accessed using HTTP over TLS
(HTTPS) and SHOULD be served on port 443 RFC2818.  The host SHOULD
NOT assume that the URI for a given network attachment will stay the
same, and SHOULD rely on the discovery or provisioning process each
time it joins the network.  Depending on how the Captive Portal
system is configured, the URI may be unique for each host and between
sessions for the same host.
This document defines one ".well-known" URIs using the registration
procedure and template from Section 5.1 of RFC5785.