Subject: [dnsext] New approach to URI scheme parameters

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Feb 2013 14:08:07 -0500

As mentioned earlier, I would like to use the URI scheme for
discovery. But I need a little more information that the current
format allows:

http://tools.ietf.org/html/draft-faltstrom-uri-06

The URI of the target, enclosed in double-quote characters ('"').
   Resolution of the URI is according to the definitions for the Scheme
   of the URI.

   The URI is encoded as one or more <character-string> RFC1035
section  <http://tools.ietf.org/html/rfc1035#section-3.3>
   3.3 <http://tools.ietf.org/html/draft-faltstrom-uri-06#section-3.3>
[RFC1035 <http://tools.ietf.org/html/rfc1035>].

It occurred to me that since a URI must not contain a space character, it
would be possible to add the optional parameters I would like to add for
discovery by simply changing the format of the target field as follows:

target = uri [ ' ' parameters]

So a domain might be specified as follows:

_foo._wk.example.com  URI 10 10 URI "http://host1.example.com/"
_foo._wk.example.com  URI 10 10 URI "http://host2.example.com/ v=2.1"

The first is a regular URI specification without any parameter. The second
add in a version parameter to tell a client which version of the protocol
that service supports.

In most cases we only really need to know if the service supports a minimum
version of the protocol. But there might be occasions where the service
required clients support a minimum protocol version, particularly in the
case of an incompatible protocol upgrade, this might be supported by a 'mv'
parameter for minimum version:

_foo._wk.example.com  URI 10 10 URI "http://host3.example.com/ v=2.1 mv=2.0"

The main advantage to this approach is that it allows the URI scheme to be
used to express all the information relevant to a client discovery
decision, either explicitly or by reference.

I see two routes to achieving this functionality

1) Redefine URI as outlined above

Pro: It is compatible, does not need new code for those already
implementing URI in servers
Con: It might be seen as breaking the principle that a change to the format
Con: If there is implementation of the URI scheme, records with parameters
could cause things to break

2) Define another record as outlined above

Pro: Guarantees nothing breaks
Con: Will need new code
Con: Means there are 3 SRV like discovery schemes instead of just 2.

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

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 13 Feb 2013 14:11:18 -0500

On 13 feb 2013, at 14:08, Phillip Hallam-Baker <[email-masked]> wrote:

> It occurred to me that since a URI must not contain a space character, it would be possible to add the optional parameters I would like to add for discovery by simply changing the format of the target field as follows:
> 

If you go down this path, why not have multiple strings:

_foo._wk.example.com  URI 10 10 URI "http://host2.example.com/" "v=2.1"

   Patrik

---

From: Brian Dickson <[email-masked]>
Date: Wed, 13 Feb 2013 15:31:00 -0500

Clever hack:

Since the (current) wire format is URI without double quotes, this can be
extended to multiple strings by using double-quote character(s) on-the-wire
to delimit the individual strings.
"foo" "bar" <=> foo"bar
(And the current trick of extra-long strings being broken at every 255th
character into separate <string> objects also works.)

Just suggesting technical tricks.

Brian

On Wed, Feb 13, 2013 at 2:11 PM, Patrik Fältström <[email-masked]> wrote:

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>
>

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 13 Feb 2013 15:34:20 -0500

On 13 feb 2013, at 15:31, Brian Dickson <[email-masked]> wrote:

> Since the (current) wire format is URI without double quotes, this can be extended to multiple strings by using double-quote character(s) on-the-wire to delimit the individual strings.

I was just suggesting imitating the syntax of the TXT format.

   Patrik

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Feb 2013 15:59:52 -0500

> _foo._wk.example.com  URI 10 10 URI "http://host2.example.com/" "v=2.1"
The URI record as currently specified permits multiple strings but does not
explicitly state what having more than one string means.

I am quite happy to use multiple strings for the same effect. In fact that
ends up with a scheme that looks essentially the same as my proposal for an
optional extra string.

Question then would be whether multiple parameters would require separate
strings or could be space separated in one string.

The syntax does not worry me. All that I care about is to find the shortest
path from where we are to a DNS record that allows discovery 'with
parameters'.

One other question that should be addressed in the URI spec (unless I
missed it) is what the discovery process should be if there is an SRV
record and a URI record. The drift of the spec was that the protocol
designer should choose. I don't think that is the way to go.

If we have a 'service discovery API' that we ask questions like 'how should
I connect to service X at DNS name Y', we should factor out as much of the
'special case handling' from the scheme as possible.

URI offers a superset of the A, AAAA, and SRV discovery capabilities. It
makes sense to make a URI record take precedence over all others if it is
present because that means we can use the URI parameters to tell an aware
discovery API that there may be a 'better' choice for its needs than they
would have chosen through round robin A records.

So lets imagine we want to advertise support for the new version of the
HTTP protocol but only for one of the two servers deployed. Our DNS file
might look like this:

; A records to be used by legacy hosts
www.example.com   A 10.1.1.1
www.example.com   A 10.1.1.2

host1.example.com   A 10.1.1.1
host2.example.com   A 10.1.1.2

; URI records, can be used by aware clients only host2 supports HTTP/2.0

_http._tcp.www.example.com URI 10 10 "http://host1.example.com/"
_http._tcp.www.example.com URI 10 10 "http://host2.example.com/" "v=2.0"

OK, so you might think that looks a silly way to encode a host name for a
web server. But look what else you could do:

_http._tcp.legacy.example.com 10 10 "http://archive.example.com/legacy/"

We have just created a way of specifying a site level http redirect in the
DNS at no extra cost.

You might argue as to whether that is a desirable approach. But it is clean
and it is consistent. I think that shows it is the right path at the very
least.

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 14 Feb 2013 10:25:26 +0000

On 13 Feb 2013, at 20:31, Brian Dickson wrote:

> (And the current trick of extra-long strings being broken at every 255th character into separate <string> objects also works.)
> 

	Please, no!

	I feel this notation is sure to cause confusion because people are used
	to recognizing the qouble quote as a balanced encloser and not as a
	separator.  I thnk this is a practical, and not just an aesthetic point.

	Consider (for example) "foo" "bar" "mumble" <=>  foo"bar"mumble.

	/Niall

---

From: Jim Reid <[email-masked]>
Date: Thu, 14 Feb 2013 11:00:08 +0000

> separator.  I thnk this is a practical, and not just an aesthetic point.

+1

Using the doublequote character as a separator is a very bad idea. Don't do it.