On Wed, Jan 20, 2016 at 3:45 AM, Matthew Kerwin
<matthew(_at_)kerwin(_dot_)net(_dot_)au> wrote:
On 19/01/2016 9:04 PM, "Eggert, Lars" <lars(_at_)netapp(_dot_)com> wrote:
On 2016-01-19, at 10:24, Matthew Kerwin
<matthew(_at_)kerwin(_dot_)net(_dot_)au> 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(_at_)example(_dot_)net")
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(_at_)example(_dot_)com/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.