Draft: draft-ietf-capport-api

Commentary: As discussed in , define an IANA registry for extending  keys use for Captive Portal API . 
 thanks for the comments . Please take another pass ! 
 Should we define an IANA registry for adding new keys ? 
 Yes , yes we should . 
 and i already commented in the PR , but if possible it would be beneficial to have some distinction between IETF or a relevant organization ( like WFA , WBA ) requested keys vs from some individual organization 
 Would we want to suggest having a nested dictionary format for organization - specific extensions ? Like " wba " as a key to a dictionary ; or a sub - dictionary indicating that there are WISPr - related settings to be aware of ? 
 i think it would be a good idea . We have seen WBA start to take active interest in the documents . Also there 's work happening in WFA that could benefit from having an extension point 
 RFC 6648 might suggest otherwise . If there are things that a group wants to add that are truly unique to that group , this is probably fine . 
 Yes , I think that more than having per - group keys ( with almost certain overlap ) , I 'd imagine that compatibility with certain technologies would be handled via these sub - dictionaries , such as what I mentioned for WISPr . Not sure how critical mentioning this is in the document though . 
 Can we call this one done ? 
 I 'm assuming we will go down the path of defining an IANA registry with access technology specific extension ? 
 The description in " Captive Portal API Keys Registry " gives some guidance for prefixes , etc . I assume the experts once designated can work with WFA / WBA to define proper entries .
"user-portal-url" (required, string): provides the URL of a web
portal with which a user can interact.
"vendor-info-url" (optional, string): provides the URL of a
webpage or site on which the operator of the network has
information that it wishes to share with the user (e.g. store
info, maps, flight status, or entertainment).
"user-portal-url" (optional, string): provides the URL of a web
portal with which a user can interact.
"vendor-info-url" (optional, string): provides the URL of a
webpage or site on which the operator of the network has
information that it wishes to share with the user (e.g., store
info, maps, flight status, or entertainment).
The valid JSON keys can be extended by adding entries to the Captive
Portal API Keys Registry iana-section.  If a client receives a key
that it does not recognize, it MUST ignore the key and any associated
values.  All keys other than the ones defined in this document as
"required" will be considered optional.
IANA is requested to create a registration for an "application/
captive+json" media type (iana-json) and a registry for fields in
that format (iana-field-reg).
IANA is asked to create and maintain a new registry called "Captive
Portal API Keys", which will reserve JSON keys for use in Captive
Portal API data structures.  The initial contents of this registry
are provided in json-keys.
The JSON key being registered, in string format.
The type of the JSON value to be stored, as one of the value types
defined in RFC8259.
A brief description explaining the meaning of the value, how it
might be used, and/or how it should be interpreted by clients.
New assignments for Captive Portal API Keys Registry will be
administered by IANA through Expert Review RFC8126.  The Designated
Expert is expected to validate the existence of documentation
describing new keys in a permanent publicly available specification.
The expert is expected to validate that new keys have a clear meaning
and do not create unnecessary confusion or overlap with existing
keys.  Keys that are specific to non-generic use cases, particularly
ones that are not specified as part of an IETF document, are
encouraged to use a domain-specific prefix.