| Hi David, My thoughts with regards to RFC 7710 is that it is not deployed as far as I know, and no client stack respects the value sent in 7710. Without some API extensions, it isn't directly better than what we currently have. Ideally, this would not be an API that would get deployed if we were also using PvDs. My concern is that if PvDs are used for enterprise and private networks, we'll have a very similar but less complete path based on RFC 7710. We could end up deprecating or replacing that RFC, which was mentioned in our last meeting. I don't think RFC 7710 can be used without a URL, which is why I think we need a solution that does a better job of indicating the lack of captive or other extended network info. I would hope that since both iOS and Android stack developers are working on the UE side, we would actually see UE deployment of PvDs before any captive vendors adopt PvDs, and we'd be standardizing around Cisco/etc enterprise deployments. By the time there were NAS vendors deploying, they would test with both iOS and Android devices to validate support. Basing our standards on the idea that devices (either networks or UE's) may implement the RFCs incorrectly seems to be a difficult starting point. I like the point you bring up of splitting network notifications from web APIs. There is a need to be judicious about what properties fall into each category. I think you're saying that the fact that there is a captive network can be signaled via ICMP, etc, as a network-level property. While ICMP is a fine solution for giving the UE hints when something has expired, I am concerned that (possibly unsolicited) network signaling is not the correct mechanism for the content details of the network, whether that is the enterprise network properties, or the captive network Terms & Conditions, tokens, expiration timers, and URLs for various kinds of user interaction. An JSON API is one form of grabbing information—I don't think we should necessarily interpret that as something that is a high-level Web interaction. We could create some custom protocol over UDP like DNS records to get the information (that would be a lot of new protocol work here that people may not be willing to get into), but the key is that it needs to be the choice of a UE device that understands how to request and parse content that initiates a lookup, and can fetch information from the network infrastructure. With regards to your assertion that we'll always revert to doing a probe, I still would like to believe that if we have a network that advertises a PvD with no extended information, or extended information that doesn't include a captive portal, we can avoid the probe altogether. Will we still have networks that redirect HTTP requests? Yes. But that's no different from the scenario today in which a network whitelists our captive detection probes. We can still get to a captive portal once the user goes into the browser. We can stop doing probes whenever the RA on the network indicates that it supports explicit signaling about network properties. If a network operator wants to invoke the system-level captive interaction, then they will follow the RFCs we come up in the CAPPORT group as long as UEs end up deploying support first. If they want to avoid it, or they have a broken network, things will be like networks that whitelist our probes today. Not great, but still possible for the user to get through. My main goal in these standards is to make it possible for a network to give the user a good experience; not to make it impossible for the user to have a sub-par experience (since I don't think that goal is achievable). Best, Tommy
|