|
I also agree that the only new component is the API server. We have extended the responsibilities of the others, or maybe, to put it differently, tried to solidify them (since as
David pointed out, many devices were already doing many of these things).
It looks like most of the discussion recently has been centered around the responsibilities of the Captive Portal Enforcement device and the CAPPORT API server.
How can we go about coming to a consensus on these? Should we propose a few options, along with their pros and cons, then vote on them? Once we've done that, the architecture could capture the results, and the drafts that discuss implementations/protocols/standards/etc
to satisfy those components can expand further.
Does that make sense?
From: Captive-portals [[email protected]] on behalf of David Bird [[email protected]]
Sent: Saturday, April 15, 2017 10:47 AM To: Erik Kline Cc: [email protected] Subject: Re: [Captive-portals] Improve the user experience of captive portals as they're commonly understood and currently deployed The only new element is the CAPPORT API Server.
Though, similar things do exists in proprietary environments (e.g. Walled garden entry plus proprietary Apps).
Even though I started the thread 'Arguments against (any) CAPPORT API', I would like to take back the "(any)" part. I just wanted to make a point that we should NOT make the API the enforcer, or otherwise give the API the opportunity to give us wrong,
misleading, or misconfigured information about what the network will enforce. I don't think the goal of the API should be to get rid of the portal in all cases. But, there could be other useful information and interaction (like WISPr demonstrates, plus minimally
more). For instance, the API could advertise 'access methods' like:
wispr { realm: "abc", login: "https://...", logout: "https://..." }
wispr { realm: "xyz", login: "https://...", logout: "https://..." }
mime-type { name: "application/my-hotspot-app" }
mime-type { name: "application/roaming-partner-
It can replace WISPr XML, even abilities by allowing the advertising of multiple roaming aggregators. It can also indicate to the UE what apps might assist- or auto- login. If this information is wrong, the Smartclient or App will
figure it out (because they are likely doing their own proprietary API in the walled garden).
On Sat, Apr 15, 2017 at 6:15 AM, Erik Kline
<[email protected]> wrote:
|