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 <tpauly=
40apple....@dmarc.ietf.org> 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 <e...@loon.com> 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 <liucou...@google.com> 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 <tpa...@apple.com> 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 <tpauly=
>>>> 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 <e...@loon.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Mon, 13 Jan 2020 at 15:26, Heng Liu <liucougar=
>>>>> 40google....@dmarc.ietf.org> wrote:
>>>>>
>>>>>> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline <ek.i...@gmail.com> 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 session.. By providing a 3rd URL, we can accommodate
>>>>>> this use case..
>>>>>>
>>>>>
>>>>> If the remediation URL is available but the user (somehow) navigates
>>>>> to the user-portal-url, what do they see?
>>>>>
>>>>>
>>>>>>
>>>>>>> With this 3rd URL, if the bytes/time does expire should the OS try
>>>>>>> to launch an interaction the remediation URL and then fallback to the
>>>>>>> user
>>>>>>> URL if it failed to load? In which case, why not just leave all
>>>>>>> interaction with the user-portal-url?
>>>>>>>
>>>>>> if a remediation URL is present, and if it fails to load for whatever
>>>>>> reason, no need to fallback to user portal URL: CP vendor should make
>>>>>> sure
>>>>>> the remediation URL is working properly (this is similar to user-portal
>>>>>> url
>>>>>> should work properly, if not, there is no other way for user to clear a
>>>>>> CP)
>>>>>>
>>>>>
>>>>> I guess I'm just trying to be mindful of one person's flexibility is
>>>>> another person's complexity.. I think this just doubles the number of
>>>>> URLs
>>>>> that the CP vendor needs to make sure function correctly.
>>>>>
>>>>> If the vendor doesn't implement a means to extend your session without
>>>>>>> completely shutting everything down and forcing to the user to restart
>>>>>>> the
>>>>>>> interaction flow anew, I could see that an OS would not want to bother
>>>>>>> the
>>>>>>> user with an interaction where they couldn't actually do anything
>>>>>>> useful.
>>>>>>> But that might suggest a boolean capability, rather than a new URL
>>>>>>> (remediation-supported={true|false})?
>>>>>>>
>>>>>> A boolean field could also be a positive signal to notify UE that
>>>>>> remediation is possible, but this would prevent CP vendors from using
>>>>>> different URLs for remediation.
>>>>>>
>>>>>> (As mentioned in the initial thread, this URL approach is also taken
>>>>>> by the Passpoint release 2.0 spec to signal remediation process.)
>>>>>>
>>>>>> regards,
>>>>>> Heng
>>>>>> _______________________________________________
>>>>>> Captive-portals mailing list
>>>>>> Captive-portals@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>>>>
>>>>> _______________________________________________
>>>>> Captive-portals mailing list
>>>>> Captive-portals@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>
>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
