Hi Lars,
--On January 22, 2016 at 2:57:57 PM +0000 "Eggert, Lars" <lars(_at_)netapp(_dot_)com>
wrote:
But .well-known could easily provide, if nothing else, a redirect to
such services.
If whoever wants to deploy this other service has the ability to change
the configuration of the server running on 80/443, to add that redirect.
For the IANA assignment requests we see, they usually don't. (Fragile or
impossible due to permissions to have one software install change the
configuration of another.)
Allowing a service name in the URL that is looked up with DNS-SD
Actually I think that concern is overblown.
The original draft version of RFC 6764 (SRV+well-known for CalDAV and
CardDAV) just used an SRV record and a well-known registration. After some
comments during IETF last call I was persuaded to add an addition TXT
record mechanism that would allow an alternative URI path to be used
instead of /.well-known/xxx. The principal argument for that was what you
stated above.
The reality is no one has deployed TXT record mechanism. Current
deployments for this for some major service providers can be seen here:
dig _caldavs._tcp.google.com srv
dig _caldavs._tcp.yahoo.com srv
dig _caldavs._tcp.icloud.com srv
dig _caldavs._tcp.fastmail.com srv
They all support both caldavs and carddavs. None of them have matching TXT
records and I am pretty sure none of the client implementations look for
TXT either.
What's important here is that CalDAV and CardDAV are major services that
will almost certainly be associated with a dedicated host (A-record)
different from the providers top-level DNS entry (which you can see via
those dig commands). In that case, the calendar/contacts server admin does
have control over the /.well-known paths for port 80/443 so there is no
issue with configuring those.
For smaller web-services, if those end up being deployed on a dedicated
host, then the SRV record can simply point to that one and whoever has
control over the config for port 80/443 can add the .well-known since they
will likely already be adding config to support the web services
themselves. I believe the same is true if the service ends up being hosted
on the top-level HTTP server too. i.e., since the config will already need
to be changed to add the actual web service, the extra cost of setting up a
redirect for a .well-known is negligible.
So rather than saying that setting up .well-known is too difficult, we must
instead encourage HTTP server vendors to make it easy to add .well-known
redirects/hooks in the config (just as we had to persuade the people
writing DNS server config UIs to support the ability to configure SRV
records - something that was always seen as a hinderance for use of SRV,
and in some cases still is).
--
Cyrus Daboo