--On Wednesday, January 20, 2016 08:22 +0100 Eliot Lear <lear@xxxxxxxxx> wrote: > This having been said, I don't know that this is a serious > problem with the 5785 registry, nor do I believe we should > make changes based on a single request/response. My > experience is that there is no perfect policy; and actually I > appreciate that Mark and company are willing to donate their > time to the cause. Agreed. While I understand and sympathize with the various grievances, much of this very long thread has seemed to me to be mostly fairly minor, falling into issues that should either be taken up with the relevant AD (as Barry suggested) or handled as appeals if the AD is non-responsive, or as proposed amendments to 5785, either to change the model or to conclude it wasn't such a good idea in the first place. In either of the latter cases, I would have expected to see an I-D and, if needed, a request for a separate mailing list long before this. However, one branch of the conversation, of which the following seems to be a member, seems to call for comment on the IETF list. --On Wednesday, January 20, 2016 18:45 +1000 Matthew Kerwin <matthew@xxxxxxxxxxxxx> wrote: > On 19/01/2016 9:04 PM, "Eggert, Lars" <lars@xxxxxxxxxx> wrote: >... >> I'm not sure. But would you even need that? You can just make >> foo resolve to 80. > Because I might have strong reasons to make my service > available under http://example.net/foo/ ... so I'd need a well > known location that links to the relevant entry points under > "/foo" -- be that special headers or markup in "/", or > something in "/.well-known/", or something else. > > At which point I'd have to ask, why not just use .well-known > in the first place? > > I'm assuming that either: the person minting the URL doesn't > know my server setup (otherwise they could include the full > path *and* the numerical port from the start, and skip the > whole dance); or this is for resolving non-URL identifiers > (like "foo:matty@xxxxxxxxxxx") The above, and some postings like it, seem to me to raise two issues that I believe we should be thinking about more broadly: (1) The Internet has gained a good deal of robustness and, arguably, much of its worldwide availability and utility, from its extremely distributed nature. If I want to do something for myself or within my family, a small circle of friends, or even my country, I generally don't need to get the permission of the IETF or anyone else. We know there are exceptions that require some sort of central administration, at least at the top level, with the root of the DNS and IP addresses being the examples that are most visible to the broader community but we have traditionally tried to minimize the number and impact of such cases. Parts of the community have been pushing the issues of which this is a part as "permissionless innovation". The importance of that robustness and distributed decision model suggests that we need to be very careful about creating new mechanisms that, in turn, create a greater requirement for central administration, regardless of the style of that administration and who performs it. Registries for the convenience of others in avoiding collisions but that do not create requirements because collisions are unlikely are in a sort of in-between area. In that context, these arguments about ".well-known" or anything else that requires making global decisions about what does and does not match the category, with probably high risk of collisions, especially if the main criteria for wanting to be in the registry starts with "I want to do..." suggest that the whole idea may be, on balance, a bad one. Given the history of the last 10 or 15 years, it is not hard to imagine demands for national control over names, requirements that ".well-known" be defined for a dozen (or many more) languages other than English (with or without restrictions to Latin script). From my point of view, getting into those positions are bad for the Internet and their tendency to draw in those who main interests lie in centralized control and policy debates are an unfortunate symptom, but one could equally argue that the latter are the problem and the implications for the Internet are just collateral damage. Either way, I do not suggest that we should never have such things (and .well-known in URLs in particular), only that we should be insisting on a level of justification for them --including analysis of whether other, less-centralized, alternatives are available-- that is strong enough to overcome the risks and costs. In the case of RFC 5785, it may be time to hold that discussion more intensely than was the case when it was approved (rather than picking at the review and approval mechanisms). We might perhaps also wonder why the discussion about principles didn't occur in more depth earlier and what might be done to facilitate discussions of that type in the future. (2) It seems to me that some of the comments on this thread come close to demonstrations of the old adage about hammers and things that look like nails. While it is clear that .well-known has good and useful applications, it doesn't seem to me to be the only way to think about some of the possibilities that have been mentioned. Looking at the examples above, "foo:matty@xxxxxxxxxxx" could be a perfectly good URL in the foo scheme. matty.example.net could point to an DNS record with a URI RRTYPE. I don't remember whether urn:foo:matty@xxxxxxxxxxx could be valid, but urn:foo:matty.example.net certainly could be. And it is likely that other approaches are possible, ones that do not have the same dependencies and tradeoffs that .well-known does (even if they have some of their own). So I would encourage people to try to be clear about the problems they are trying to solve and then consider the full range of options for solving them: if one option seems problematic, whether because of the technology or its administration, then look at, or if necessary invent another one. And, unless what you want to invent is something like a new URI scheme bound to some unique identity of your own, try to avoid arrangements that require central administration, review, or approval... at least unless you like discussions like the one we've been having. best, john