Subject: [URN] a proposed technical change to the NAPTR drafts...

From: Michael Mealling <[email-masked]>
Date: Thu, 8 Apr 1999 10:18:24 -0400 (EDT)

Hi guys,
  In our Last Call comments we have received some from the DNSIND folx
concerning our use of SRV. Their suggestion is that we _not_ include
the protocol stuff in the domain-name that is found in either
the replacement field or the rewrite. In order to be more in line with
what the expected behavior of SRV will be we should use the protocol
out of our own Services field to construct the SRV.

Examples:

This is how we do it now:

IN NAPTR 100  50  "s"  "z3950+N2L+N2C"     ""    _z3950._tcp.gatech.edu.

This is how they would like it to behave:

IN NAPTR 100  50  "s"  "z3950+N2L+N2C"     ""    gatech.edu.

Then the client does the _z3950._tcp construct itself and prepends it to
the domain found in the replacement field.

In the first one the SRV component is explicit, thus creating a potential
error condition where the protocol in the Services field doesn't jive
with the stated protocol in the replacement. In the second its
emplicitly done by the client as part of the standard way clients use SRV
records, thus mitigating that error condition.

This is a content change as opposed to simple wordsmithing. The issues
for me are the following:

Code changes...

How do we know whether to use TCP or UDP for a given protocol? Most don't
have a UDP equivalent so its not that big of a deal. Those protocols that
do have a negotiated internal process for fall back (DNS itself does this).

I'm not aware of any other issues. If there are any please let me know...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 19 Apr 1999 11:40:20 -0400

> out of our own Services field to construct the SRV.

that's silly.  part of the point of NAPTR is to allow client selection
of protocols to perform a particular service.  the proposed change would
make NAPTR much less functional.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 19 Apr 1999 11:51:06 -0400

> The main
> reason is that we are providing a NAPTR specific protocol (defined by
> the application that uses NAPTR) and that list of protocols may be 
> seperate from the list of services that may be offered at that site.

yep. and more generally for the purpose of NAPTR lookup we really might 
want to use "nonstandard" SRV labels rather than the defaults.  
so the "http" service to which NAPTR lookups are directed might be a 
completely different service than the "normal" http service.

Keith

---

From: Michael Mealling <[email-masked]>
Date: Mon, 19 Apr 1999 11:39:23 -0400 (EDT)

> make NAPTR much less functional.

How so? As it stands the SRV draft requires the protocol to be there, which
means we're duplicating it. Actually, no it doesn't. I'm not sure if you're
right but I just realized that we have to have it in both places. The main
reason is that we are providing a NAPTR specific protocol (defined by
the application that uses NAPTR) and that list of protocols may be 
seperate from the list of services that may be offered at that site.

I.e. in the thttp example for the URN RDS the protocol _we_ put in our
services field is 'thttp'. THTTP defines how to use resolve URNs via http
so the service we ask for in the SRV would be '_http._tcp'. The distinction
between the RDS's use of 'thttp' and the SRV protocol of 'http' is an
important one for NAPTR based services to make.

Does that jive with what other folx think?  

-MM

---

From: Michael Mealling <[email-masked]>
Date: Mon, 19 Apr 1999 11:48:46 -0400 (EDT)

> completely different service than the "normal" http service.

Yep. Unless I hear something other wise I'm going to add this reasoning
to the section of the NAPTR draft to clarify how it uses SRV. Since we
are using SRV somewhat differently than the folx in DNSIND had originally
invisioned I think a few words to that effect would be useful to the
reader. Especially since it has become obvious that SRV implementers are
making some assumptions that may not be correct for our usage.

-MM