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

+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@google.com> 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
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>