DNS-based discovery in "HTTP-based Resource Descriptor Discovery"

[Breno de Medeiros]

First I would like to say that I think the draft is in terrific shape, and compliment Eran for the effort that he showed in putting this together.

In the rest of this email, I am offering my viewpoint on the DNS discovery issue.

-On the need to make DNS discovery authoritative for site-meta-based discovery on other URI schemes:

--In practice, I think this is a finer-grained decision that should be left to applications, while the current form binds this obligation to the scheme, which is somewhere on the application/transport boundary. A more realistic standpoint would be to have the standard say that clients performing discovery on a URI scheme other than HTTP MAY perform DNS discovery and MAY fail if the DNS record is not available. It could also indicate that application-level standards that adopt this standard by reference MAY elect to make this step mandatory (MUST) or recommended (SHOULD) or not recommended (SHOULD NOT), according to their specific needs.

--Venturing a guess, I expect that HTTP-based schemes such as OpenID/OAuth will likely spouse the view that DNS discovery is not required for authoritativeness and will instead infer authority and trust through other means (e.g., X.509 digital certificates and signatures).


-On the need for a well-known location:
--'/site-meta' or equivalent is unavoidable for HTTP-based discovery, in particular because the only proposed alternative (DNS records lookup) is not typically available within popular HTTP API frameworks and this situation is unlikely to change.

--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

[David Fuelling]

+1, both on the spec itself, and on your comments Breno -- though IMHO an appropriate compromise would be for the spec to allow an optional, yet authoritative DNS entry that takes precedence over /site-meta (yet typically pointing to /site-meta).  Libraries SHOULD (MUST?) check for this DNS entry, but if it's not there, then discovery should not fail -- instead, /site-meta should be the fall-back for non-HTTP URI's in the case where nothing has been put into DNS.

Currently does the opposite -- it says that discovery just fails if nothing is found in DNS.

david 

On Sat, Jan 10, 2009 at 5:05 PM, Breno de Medeiros <breno@...> wrote:

First I would like to say that I think the draft is in terrific shape, and compliment Eran for the effort that he showed in putting this together.

In the rest of this email, I am offering my viewpoint on the DNS discovery issue.

-On the need to make DNS discovery authoritative for site-meta-based discovery on other URI schemes:

--In practice, I think this is a finer-grained decision that should be left to applications, while the current form binds this obligation to the scheme, which is somewhere on the application/transport boundary. A more realistic standpoint would be to have the standard say that clients performing discovery on a URI scheme other than HTTP MAY perform DNS discovery and MAY fail if the DNS record is not available. It could also indicate that application-level standards that adopt this standard by reference MAY elect to make this step mandatory (MUST) or recommended (SHOULD) or not recommended (SHOULD NOT), according to their specific needs.

--Venturing a guess, I expect that HTTP-based schemes such as OpenID/OAuth will likely spouse the view that DNS discovery is not required for authoritativeness and will instead infer authority and trust through other means (e.g., X.509 digital certificates and signatures).


-On the need for a well-known location:
--'/site-meta' or equivalent is unavoidable for HTTP-based discovery, in particular because the only proposed alternative (DNS records lookup) is not typically available within popular HTTP API frameworks and this situation is unlikely to change.

--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)