Re: On IETF policy for protocol registries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Lars,

--On January 22, 2016 at 2:57:57 PM +0000 "Eggert, Lars" <lars@xxxxxxxxxx> 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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]