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

From: Frederico A C Neves <[email-masked]>
Date: Sun, 25 Jul 2010 15:41:19 -0300

Dear Colleagues,

Bellow is a completed template requesting a new RRTYPE assignment
under the procedures of RFC5395.

This message starts a 3 weeks period for an expert-review of the DNS
RRTYPE parameter allocation for URI specified in
http://tools.ietf.org/html/draft-faltstrom-uri-05

If you have comments on the request, please post them here before Aug
15th 18:00 UTC

Best Regards,
Frederico Neves

--begin 5395 template URI--
A.   Submission Date:

     May 23, 2009

B.   Submission Type:

     [X] New RRTYPE
     [ ] Modification to existing RRTYPE

C.   Contact Information for submitter:

     Name: Patrik Faltstrom
     Email Address: [email-masked]
     International telephone number: +46-8-6859131
     Other contact handles:
     (Note: This information will be publicly posted.)

D.   Motivation for the new RRTYPE application?

     There is no easy way to get from a domain name to a URI.  Some
     mechanisms exists via use of the NAPTR [RFC3403] resource
     record.  That implies quite complicated rules that are
     simplified via the S-NAPTR [RFC3958] specification.  But, the
     ability to directly look up a URI still exists.  This
     specification uses a prefix based naming mechanism originated in
     the definition of the SRV [RFC2782] resource record, and the
     RDATA is a URI, encoded as one text field.

     See also Section 1 in draft-faltstrom-uri-05.txt.

E.   Description of the proposed RR type.

     The format of the URI resource record is as follows:

     Ownername TTL Class URI Priority Weight Target

     The URI RR has service information encoded in its ownername.  In
     order to encode the service for a specific owner name one uses
     service parameters.  Valid service parameters used are either
     Enumservice Registrations registered by IANA, or prefixes used
     for the SRV resource record.

     The wire format of the RDATA is as follows:

                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Priority             |          Weight               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               /
    /                             Target                            /
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

F.   What existing RRTYPE or RRTYPEs come closest to filling that
     need and why are they unsatisfactory?

     The RRTYPE that come closest is the NAPTR resource record.  It
     is for example used in the DDDS and S-NAPTR algorithms.  The
     main problem with the NAPTR is that selection of what record (or
     records) one is interested in is based on data stored in the
     RDATA portion of the NAPTR resource record.  This, as explained
     in RFC 5507 [RFC5507], is not optimal for DNS lookups.  Further,
     most applications using NAPTR resource records uses regular
     expression based rewrite rules for creation of the URI, and that
     has shown be complicated to implement.

     The second closest RRTYPE is the SRV record that given a
     prefixed based naming just like is suggested for the URI
     resource record, one get back a port number and domain name.
     This can also be used for creation of a URI, but, only URIs
     without path components.

G.   What mnemonic is requested for the new RRTYPE (optional)?

     URI

H.   Does the requested RRTYPE make use of any existing IANA Registry
     or require the creation of a new IANA sub-registry in DNS
     Parameters?

     Yes, partially.

     One of the mechanisms to select a service is to use the
     Enumservice Registry managed by IANA.  Another is to use
     services and protocols used for SRV records.

I.   Does the proposal require/expect any changes in DNS servers/
     resolvers that prevent the new type from being processed as an
     unknown RRTYPE (see [RFC3597])?

     No

J.   Comments:

     None
--end 5395 template URI--

---

From: Klaus Malorny <[email-masked]>
Date: Sun, 25 Jul 2010 21:26:32 +0200

> If you have comments on the request, please post them here before Aug

Hi,

dumb question: I don't consider myself an expert in that respect, but wouldn't 
it make more sense nowadays to use UTF-8 encoded IRIs (RFC 3987) instead of 
URIs? Or is there a need to keep everything ASCII-safe?

Regards,

Klaus

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 25 Jul 2010 16:17:52 -0400

No hat

On Sun, Jul 25, 2010 at 09:26:32PM +0200, Klaus Malorny wrote:
>
> dumb question: I don't consider myself an expert in that respect, but 
> wouldn't it make more sense nowadays to use UTF-8 encoded IRIs (RFC 3987) 
> instead of URIs? Or is there a need to keep everything ASCII-safe?

My impression anyway is that IRIs are being updated, so in that case
it'd be better to wait for the update.  But of course, we could add
another RRTYPE for IRIs once the update is available, I guess, and do
URIs now.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 25 Jul 2010 23:33:59 +0200

> another RRTYPE for IRIs once the update is available, I guess, and do

This is indeed a very good question. The URI could be said to be in UTF-8 already now because *my*guess* is that that actually make most sense.

But I take on the task to check with the IRI people really fast, and I will come back with a response (for example how to handle cases where one "would like to" (note the quotes) url-encode some characters, in one of the various ways possible).

   Patrik

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 26 Jul 2010 08:20:27 +0900

Klaus Malorny wrote:

> wouldn't it make more sense nowadays to use UTF-8 encoded IRIs (RFC 
> 3987) instead of URIs? Or is there a need to keep everything ASCII-safe?

UTF-8 is causing a lot of problems, some of which was predicted
but some are new, with CJK unification and will never be stable.

Patrik;

> But I take on the task to check with the IRI people really fast,

They are the wrong people to ask, because only the positive
answers are expected.

						Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 25 Jul 2010 20:43:49 -0400

Use the same RR for both.

As far as the infrastructure is concerned there is absolutely no
difference. DNS does not need to know the semantics of the bits being
shipped.

IRIs are going to have to fit into slots where URLs are used. In most
cases the application will not know which is being used.

The justification for IRIs is that they are friendlier for human use.
This is another technology meant to make things easier for human use.
There is really no reason that the target should be another human
friendly format. But there is no particular harm either. Provided that
the target is something that the app can just use as a blind chunk of
bits.

-- 
Website: http://hallambaker.com/

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 26 Jul 2010 09:56:06 +0900

> difference. DNS does not need to know the semantics of the bits being

RFC3987 says:

   a.  A protocol or format element should be explicitly designated to
       be able to carry IRIs.

> The justification for IRIs is that they are friendlier for human use.

IRIs are unusably human unfriendly.

						Masataka Ohta

---

From: Florian Weimer <[email-masked]>
Date: Mon, 26 Jul 2010 07:35:22 +0200

>      The wire format of the RDATA is as follows:

Would it make sense to include an "insert original domain here"
placeholder in the target part?  This would help with aliasing.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 26 Jul 2010 09:01:33 +0200

> placeholder in the target part?  This would help with aliasing.

You talk about a subset of the NAPTR regexp now are you not...

http://cloud-4711.example.com/${domain}/foo/bar

The problem with any such thing is that you immediately end up in a discussion on how to encode the '$' that should be in the URI.

   Patrik

---

From: Florian Weimer <[email-masked]>
Date: Mon, 26 Jul 2010 20:14:58 +0200

* Patrik Fältström:

> The problem with any such thing is that you immediately end up in a
> discussion on how to encode the '$' that should be in the URI.

If the URI is encoded in UTF-8, you could use \255 as the marker. 8-)

But I can see that this is a problem.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 26 Jul 2010 12:43:57 -0700

Howdy,

I do not think this proposal is quite baked enough.

I would strongly suggest trying this out in private use space as
the primary method of baking, because there are a lot of
potential issues that may turn out to be either imaginary
or un-imagined.

Specifically, I think this template processing should
be delayed on the following grounds from RFc 5395:

3. The documentation of the proposed RRTYPE or RRTYPE(s) is
      incomplete.  (Additional documentation can be provided during the
      public comment period or by the Expert.)

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.

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.

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?

I suspect that playing in the private use space for a while would show
us that associating a URI with a domain name needs more context
than a simple juxtaposition will allow.  It may be that a meta-type
can do this with specific uri types below it, but I think that the baseline
here is that the URI type by itself will inherently sub-type (minimally by
scheme and possibly by much more).    That needs a lot more design
than this template seems to carry, and if we don't start from that
presumption, I think we'll end up with a useless swamp.

Just my two cents,

Ted

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 27 Jul 2010 16:40:01 +0200

> 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.

> 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.

> What does it mean if the URI returned is a dns uri?  How about a data

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

---

From: Ted Hardie <[email-masked]>
Date: Tue, 27 Jul 2010 11:48:43 -0700

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).

> 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:

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