One option we have is to use Code 114, which was reserved for use by Apple as a "URL" option. That particular codepoint wasn't ever used, so it should be open to be reclaimed as a CAPPORT API URL. Since this is in the range below 128, it should be safer to use.
Best, Tommy > On Dec 23, 2019, at 11:27 AM, Bernie Volz (volz) <v...@cisco.com> wrote: > > Hi: > > OK, good to know. I had thought that there was support for using option 160 > in implementations as RFC7710 was published in December 2015. > > I guess Warren will need to update the bis document to request IANA to assign > a new DHCPv4 option (replacing 160) because of the potential conflict > regarding its use – likely it would be useful to give some short > justification for this (about the conflict). Likely the listing for option > 160 will need to be something like: > > 160 DEPRECATED (see new-option-code) - DHCP Captive-Portal > N DHCP Captive-Portal [RFC7710] > 160 Polycom (vendor specific) > > It may also be appropriate to request IANA assign 111 (if still available) as > it has no reported use and is in the original (<128) IANA assigned space (as > per RFC2132). > > BTW: Code 115 (which was listed as used by failover in RFC3679) could also be > a good choice as I am pretty sure it this was ever used (and if it was, it > was for failover communication and not normal clients; and that use has long > been deprecated). > > Bernie > > From: tpa...@apple.com <tpa...@apple.com> > Sent: Monday, December 23, 2019 12:58 PM > To: Lorenzo Colitti <lorenzo=40google....@dmarc.ietf.org> > Cc: Bernie Volz (volz) <v...@cisco.com>; Michael Richardson > <mcr+i...@sandelman.ca>; captive-portals@ietf.org; Warren Kumari > <war...@kumari.net> > Subject: Re: [Captive-portals] option 160 conflict > > > > > On Dec 21, 2019, at 7:48 PM, Lorenzo Colitti > <lorenzo=40google....@dmarc.ietf.org > <mailto:lorenzo=40google....@dmarc.ietf.org>> wrote: > > > On Sat, 21 Dec 2019, 07:53 Bernie Volz (volz), <v...@cisco.com > <mailto:v...@cisco.com>> wrote: > 1) It would not really remove the overlap for a long while (until all of the > clients that used the "old" 160 Capport option are upgraded). So, devices > will still need to deal with it for a long while. > > Do any clients or networks actually implement 160 to mean capport? I know > that iOS and Android, which seem most interested in this option, do not yet. > > I am not aware of anything using the option yet. iOS does not use it; we used > it for interop testing, but that is not in production code. > > > If they do not, the right thing to do would be to get a new option code, and > do so as soon as possible so the implementations that are being written this > year can immediately start using the new one. > > I would also urge that if we want a new code, we allocate it soon so that the > implementations can quickly test it out and ship the right value. > > Tommy > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org <mailto:Captive-portals@ietf.org> > https://www.ietf.org/mailman/listinfo/captive-portals > <https://www.ietf.org/mailman/listinfo/captive-portals>
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
