On Fri, May 01, 2020 at 09:32:27AM +1000, Mark Nottingham wrote: > (a) (b) Appendix A already talks about it some: > > """ > Why aren't per-directory well-known locations defined? > Allowing every URI path segment to have a well-known location > (e.g., "/images/.well-known/") would increase the risks of > colliding with a preexisting URI on a site, and generally these > solutions are found not to scale well because they're too > "chatty". > """ > > We could say more in the spec proper, I suppose.
The more to say really is to have some examples showing how to do the multi-tenancy thing. I mean, it's obvious -- it's obvious to me anyways. But evidently it's not actually that obvious. At least one person I've spoken to thought the text in section 3 of RFC 8615 does allow use below the root, and I can see how such a misunderstanding can happen: "each app has its own root, no?". Because, yes, if you think about "mounting an app" on the URI local-part "filesystem", then "each app has its own root" makes sense. > (c) seems like a good pattern to recommend for people who really want > to scratch this itch -- although I suspect some will complain that > it's hard to maintain the linkages (it's not really, they just need a > competent sysadmin). It's not an itch though, more like an accident. People do this because they build a service, they put it under /mysvc, then they add multi-tenancy and don't set up a separate authority for each tenant because hey, local-part components are cheap. > (d) is not something I'm keen to do. Just because people have done it > shouldn't mean that we should give that practice any formal air cover. +1 (I wrote "possibly" because I'm not keen on it either.) > (e) The current approach we take is that every registration is > effectively its own name space; it can do what it likes with > substructure (including establishing another registry). That gives a > lot of freedom, but it's caused some confusion (e.g., most recently > with EST and extensions to it), so some indication of what policy is > in use would be interesting -- either in the spec, or the registry > itself. It may be too early or this, but I could see a list of common > management mechanisms being created for easy reuse. Well, as you're the Expert Reviewer, maybe you can just start looking out for this, asking registrants to write a blurb about this in their specs and user-facing docs. Maybe that's all that needs to be done for the moment. > Question: do you see any of these issues as urgent? .well-known got > revised relatively recently, so I'd like to collect some more > feedback/issues before reopening the box, ideally. If they're not > urgent, would it be OK to just log them as open issues (I use > <https://github.com/mnot/I-D/labels/well-known>)? Not urgent. I think this can be handled by the Expert Reviewer for new registrations until more changes pile up for RFC 8615. I've opened https://github.com/mnot/I-D/issues/315 Thanks for the quick reply! Nico -- _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
