Re: [dnsext] URI RRTYPE review - Comments period end Aug 15th

[Ted Hardie <[e-mail]>]

Hi Patrik,

Thanks for the quick reply; sorry that I'm not in Maastricht to have this
discussion over a friendly beverage (and I hear some of the beverages
in Maastricht are very friendly indeed).

2010/7/27 Patrik Fältström <[e-mail]>:
> On 26 jul 2010, at 21.43, Ted Hardie wrote:
>
>> The template notes that the RRTYPE contains a URI, but it does not
>> give any specific relationship between that URI and domain name at
>> which it is found.  U-NAPTR and other ways of connecting URIs
>> and domain names start from a service (or an application), and work
>> their way to a URI; they start, in other words, from the relationship.
>
> Hmm...this confuses me a bit, and it might be that you have to explain a bit more to me what you feel is missing. I have, just in case, re-read U-NAPTR, and do not see any difference.
>
> The U-NAPTR talk about the service type, and URI talk about the prefix to the name (as in SRV), and the ultimate algorithm you use depends on the registration of that service.
>
>> This proposal simply juxtaposes the two, and gives you no way to
>> formal way to describe what relationship the URI
>> stands in to the domain name at which it is found.
>
> Can you explain more what you mean by "relationship" here? Pointing to explicit pieces in the U-NAPTR RFC would maybe be perfect, so I understand what you mean.
>

Sorry that my explanation was so poor.  At the moment, the draft
describes a mechanism that
relies on two associated things:  a composed service name and an RR with format:

Ownername TTL Class URI Priority Weight Target

One composed service name example you give is

$ORIGIN example.com.
   _http._web    IN URI 10 1 "http://www.example.com/"

That is, someone looks up _http._web.example.com and discovers
this URI there.  The first issue is the one draft notes, that you
must know in advance to check for this in order to populate
the fields correctly.  For your "two domains, one homepage"
example, the querier must know in advance, in other words,
to check for the _http._web.example.net in order to
discover that there is another domain.  That's not going
to happen as an adjunct for standard web queries without
a lot of other work, so it really relies on some application
that wants that bit of data (as opposed to just wanting
the home page).

It's okay that it is only useful to applications that
already know they want it, but, unfortunately,
it's also not really enough.  _http._web is a very general
service name, and there is no way with that level of
granularity to know whether the URI you're getting
is meant to be an equivalent, an alternate, or to
stand in some other relationship (e.g. hold meta data).
Each pairing of composed service name and URI
has to have some semantic that tells you what the
URI has to do with the related service name.

It may very well look obvious (uh, it's an imap URI dude),
but there is a pretty large number of URIs with some
level of ambiguity.  Some are the known risks (data)
and some are specific to this context (the dns URI scheme
seems to be both a potentially powerful construct here
and a potential source of serious confusion).

This could simply mean that what _http._web.example.net
points to is the URI of an alternative and what _http._web.library.example
points to is meta-data.  The less agreement there is, though,
the less applications are going to be able to rely on this.
It could also mean that we explode the service name space to
include new types for each new semantic, but that has
obvious downsides as well.

If I create a URI record at  _dns._udp.example.net
with a target of dns:example.org.?clAsS=IN;tYpE=CNAME
am I reporting the CNAMES which point to example.net?
Or am I telling you that example.net is authoritative for
the domain name that is the result of that query?
The service name and URI pointer aren't really enough
to know.

You touch on this in the draft by noting that the service
name usage may be subtly different for each RR that uses,
but I think the situation is far more complicated than that.
URIs are inherently sub-typable (by scheme, query, etc.),
and that means that the semantics here seem to me to
need a much richer description capability than the draft
assumes.

To tale a different example, it seems to me relatively easy to
create a mechanism using this method that would give
you a pointer equivalent to MX (or even CNAME).  But
it is not easy to be sure that the mechanism so created
has that and only that function without either serious amounts of out
of band knowledge and agreement or some tool beyond
the current set of service name and target URI.

I'm not sure that this explanation is all that much better,
so feel free to batter away at the results.

thanks,

Ted






>> If there are multiple URIs present at a domain name,
>> should they be considered alternates?  Is each independent?  Is
>> this based on internal structures of the data (e.g. the scheme)?  What
>> does that imply if there has to be truncation in the data returned?
>> What does it mean if the URI returned is a dns uri?  How about a data
>> uri?
>
> Many of these things are things that have to do with the service. Some do, I admit, imply things that are solved because of the generic description of how DDDS works, other things finally are I think unclear for URI as well as for U-NAPTR, as they might imply generic DNS issues.
>
> I have a few other comments as well, and will complement the draft with that information (in the form of a new version).
>
>   Patrik
>
>