On Wed, Jan 20, 2016 at 3:45 AM, Matthew Kerwin <matthew@xxxxxxxxxxxxx> wrote: > > On 19/01/2016 9:04 PM, "Eggert, Lars" <lars@xxxxxxxxxx> wrote: >> >> On 2016-01-19, at 10:24, Matthew Kerwin <matthew@xxxxxxxxxxxxx> wrote: >> > >> > Can DNS-SD tell you what path to query (along with server and port), in >> > case the foo-speaking part of the server is nested within the regular >> > port-80 web server? >> >> 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") This is indeed about resolving such identifiers. And also about being able to use identifiers in DNS records and config files without extraneous syntax. Every bit of syntactic noise that is introduced is another opportunity to make a config error. With ids the problem is not just that http://openid.example.com/ids/alice is simply not going to be acceptable to 99% of Alices. The other part of the problem is that we often want to use an account identifier inside another protocol URI. So lets say I have a FTP url with an account specifier: ftp://alice@xxxxxxxxxxx/file/path That syntax really isn't going to work if you have a URI inside a URI: ftp://{http://openid.example.com/ids/alice}/file/path People can make up whatever they like for translating the contents of {} into a URI safe fashion, I can't see it being viable. Point is that syntactic clutter tends to accumulate. So being able to strip everything back to just the domain name and the service identifier is actually very useful. One of the biggest hassles I find using SSH is having to type in the entire key into config files rather than the fingerprint of a key. Such choices have consequences.