Re: [Captive-portals] option 160 conflict
[as an individual] I agree that this seems like an almost magically good solution to the conundrum that CAPPORT has, and strongly agree that this is the proper solution for this WG. I am a bit sad that it doesn't scale to future DHCP options that other protocols may want to use. /a On 1/3/20 11:01 AM, Michael Richardson wrote: Warren Kumari wrote: >> 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. > I *really* like this idea - the options even contains something that > looks like a URL :-) I also like it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ 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
Re: [Captive-portals] API access and .well-known
On 1/18/18 4:18 PM, Michael Richardson wrote: Adam Roach <a...@nostrum.com> wrote: > I agree that we should strictly avoid synthesizing URLs in general, > and should try to avoid .well-known URLs in particular. Sometimes > you're forced to use .well-known (e.g., when there's literally no way > to get a full URL to the client), but that doesn't seem to be the case > here. Is it reasonable for different enforcements points to return different URLs to different clients? If so, that solves much of the multi-tenancy problems, and I guess I recant some of my previous message. Sure, either in a 3xx response; or, if we're using Link: relations, those URLs can vary based on the client. If you want to get fancy about it, you can even have your DHCP server hand out different URLs in the RFC7710 field. There are a lot of ways to deal with multi-tenancy. I'd still like to register a /.well-known value as a suggestion. Why? /a ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] API access and .well-known
[as an individual] On 1/18/18 4:15 PM, Michael Richardson wrote: I think that we need the 7710 mechanism to get the HOST part, and that the URL part SHOULD be .well-known/blah, but MAY be something else. No, please don't. That's very much *not* what .well-known is meant for. See RFC 5785, section 1.1. /a ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
