Re: [Captive-portals] Remediation url for CAPPORT
On Mon, Jan 20, 2020, at 17:54, Michael Richardson wrote: > There are a number of locations where you get 20 minutes free, and then you > have to purchase the extension. That doesn't seem to fit into remedial to > me. (Montreal Airport comes to mind) > > I guess such locations have an incentive to put something other than "you're > logged in" on that page. What should such a location do? Do they say the > offer extensions, or not? I don't see why not. Now you might not be inclined to sell your first-born child [1] to continue, but it's not like the option isn't there. [1] ...or kidney, or whatever more reasonable terms the network might offer. ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Remediation url for CAPPORT
Lorenzo, my impression is that the User Portal URL (already distinct from the Venue URL) should cover that use case; or at least we should encourage it to be so. Once a user is logged in, the page generally won’t just show a new log in. If for some reason the renew page needs to be a different URL, it could simply redirect the user portal URL whenever the user is logged in. If we have three URLs, then we’d have two URLs, the User Portal the new Extend URL, that would each only be useful at certain mutually exclusive times: one before log in and one while logged in. That seems like an easy opportunity to encourage portal designers to have a single page, so we don’t have a UI in android or iOS that ever presents a link that takes you to a useless “you’re logged in” page. I’m all for having the venue URL be distinct, but let’s just use a Boolean to indicate if the user portal URL is a useful URL while logged in or not. Tommy > On Jan 19, 2020, at 8:50 PM, Lorenzo Colitti wrote: > > I do think something is needed here because we don't want the device > to put up a "you're running out of time, please click here to extend" > prompt/notification, if tapping that prompt goes to a page that just > says "you're logged in" without allowing the user to extend. If the > network doesn't support extending sessions, then the device should not > display the prompt. So we should give the network a way to express via > the API whether it's possible to extend the user's time or not. > > Once we do decide to have something like that in the API, ISTM that a > separate URL is more useful than just a boolean. Whether the URL is > present or not gives you the boolean; the content of the URL makes it > easier for network operators because it means they can provide a > specific "manage my connection" page that is different from the login > page. The operator could of course decide what to display based on the > login state of the user; this just makes it easier. > > But as long as this is not the same as the venue URL, that works for > me. We do want it to be separate, because we expect most operators > will primarily want to surface the venue URL, and we don't want them > to have to make a choice between surfacing the venue URL and making > the session easy to extend. > > Cheers, > Lorenzo > >> On Fri, Jan 17, 2020 at 4:25 PM Remi NGUYEN VAN >> wrote: >> >> As far as the Android implementation is concerned, I think it would be nice >> to have capport API support in the next (android R) version; however due to >> deadlines, it's going to be harder for me to change the attributes read from >> the API very soon. >> Following this discussion my current plan is to support an optional >> "remediation-supported" boolean, and only prompt users to extend their >> session shortly before it expires when it is set to true. Hopefully the >> boolean can be added to the current draft or in a future, separate draft >> considering that we seem to roughly agree on it, but if the group eventually >> realizes that it wants to go in another direction, we'll update behavior in >> subsequent releases. >> >> Does that make sense ? >> >> Cheers, >> >> Remi >> >>> On Wed, Jan 15, 2020 at 9:30 AM Erik Kline wrote: >>> >>> If there's working group consensus to add it to the current API draft then >>> definitely add it. Otherwise, probably a separate document that would need >>> a call for wg adoption. >>> >>> Separately, and hopefully without starting a massive bikeshed, is there a >>> more apt word than "remediation"? I think this specific word carries the >>> connotation of "fixing an error" or "correcting damage" and it seems like >>> the use here would be broader. But perhaps I'm completely mistaken. >>> >>> On Tue, 14 Jan 2020 at 16:21, Heng Liu wrote: It seems most are comfortable with adding a remediation-capable boolean, which is simpler than another url while also making it explicit on whether remediation is provided or not, so UE could display different notifications. Anyone have any objections on adding this boolean please? If not, what's the next step on moving this forward please? Thanks, Heng On Tue, Jan 14, 2020 at 12:38 PM Tommy Pauly wrote: > > Any captive portal that is newly adopting the CAPPORT API will hopefully > be testing the setup in the new model, and will have to think about which > URLs to map to different user experiences. > > A page that only says "you're logged in!", and has no way of adding more > time, etc, is in my opinion a relatively useless page. If we provide a > separate URL for remediation, it would seem to encourage such a design. > Not including this would hopefully urge the portal design to a cleaner > model. > > I do think the boolean is nice for highlighting to the captive portal > deployer that they should think about
Re: [Captive-portals] Remediation url for CAPPORT
I also thought "remediation-supported" was not ideal but could not come up with a better name. "can-extend-session" does sound clearer to me. Cheers, Remi On Sat, Jan 18, 2020 at 1:53 AM Tommy Pauly wrote: > I'm fine with adding the boolean to the main draft. I discussed this a bit > with Heng yesterday, and we discussed naming it something like > "can-extend-session". Thoughts on that name? > > Thanks, > Tommy > > On Jan 16, 2020, at 11:25 PM, Remi NGUYEN VAN < > reminv=40google@dmarc.ietf.org> wrote: > > As far as the Android implementation is concerned, I think it would be > nice to have capport API support in the next (android R) version; however > due to deadlines, it's going to be harder for me to change the attributes > read from the API very soon. > Following this discussion my current plan is to support an optional > "remediation-supported" boolean, and only prompt users to extend their > session shortly before it expires when it is set to true. Hopefully the > boolean can be added to the current draft or in a future, separate draft > considering that we seem to roughly agree on it, but if the group > eventually realizes that it wants to go in another direction, we'll update > behavior in subsequent releases. > > Does that make sense ? > > Cheers, > > Remi > > On Wed, Jan 15, 2020 at 9:30 AM Erik Kline wrote: > >> If there's working group consensus to add it to the current API draft >> then definitely add it. Otherwise, probably a separate document that would >> need a call for wg adoption. >> >> Separately, and hopefully without starting a massive bikeshed, is there a >> more apt word than "remediation"? I think this specific word carries the >> connotation of "fixing an error" or "correcting damage" and it seems like >> the use here would be broader. But perhaps I'm completely mistaken. >> >> On Tue, 14 Jan 2020 at 16:21, Heng Liu wrote: >> >>> It seems most are comfortable with adding a remediation-capable boolean, >>> which is simpler than another url while also making it explicit on whether >>> remediation is provided or not, so UE could display different notifications. >>> >>> Anyone have any objections on adding this boolean please? >>> >>> If not, what's the next step on moving this forward please? >>> >>> Thanks, >>> Heng >>> >>> On Tue, Jan 14, 2020 at 12:38 PM Tommy Pauly wrote: >>> Any captive portal that is newly adopting the CAPPORT API will hopefully be testing the setup in the new model, and will have to think about which URLs to map to different user experiences. A page that only says "you're logged in!", and has no way of adding more time, etc, is in my opinion a relatively useless page. If we provide a separate URL for remediation, it would seem to encourage such a design. Not including this would hopefully urge the portal design to a cleaner model. I do think the boolean is nice for highlighting to the captive portal deployer that they should think about remediation. I'd be more ok with that model, although it could also be an extension as we gain experience in deployment. Thanks, Tommy On Jan 13, 2020, at 6:00 PM, Remi NGUYEN VAN < reminv=40google@dmarc.ietf.org> wrote: If we show prompts to the user shortly before the session expires, we'd like to make sure that we can redirect them to some page where they can fix the problem, instead of landing on a page saying "you're logged in". The user-portal-url would work fine with a remediation-supported boolean for that purpose; having a separate URL gives additional flexibility to the access point operator, but from the point of view of the client I think both are fine. Cheers, Remi On Tue, Jan 14, 2020 at 10:02 AM Tommy Pauly >>> 40apple@dmarc.ietf.org> wrote: > I have a similar initial reaction to Erik's. Adding another URL that > effectively is just another user portal, but meant to be used at certain > times, adds a lot of complexity. I'm certainly not ruling out adding such > a > key as need arises, but I'd hesitate to make it part of the initial set. > > Particularly, if we start seeing the "venue URL" be the main landing > page we redirect people to once they're logged it, it kind of makes sense > to let the user portal be the status/remediation/payment page. > > Tommy > > On Jan 13, 2020, at 4:06 PM, Erik Kline wrote: > > > > On Mon, 13 Jan 2020 at 15:26, Heng Liu 40google@dmarc.ietf.org> wrote: > >> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline wrote: >> >>> Why should this different from the user-portal-url? It seems to me >>> that either the user-portal-url would remediation UI elements or it >>> wouldn't. >>> >> Some CP vendors want to specify a different URL specifically tailored >> for remediation of a
