[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    RE: XPTR Drafts
From:       "Hallam-Baker, Phillip" <pbaker () verisign ! com>
Date:       2007-07-05 18:56:11
Message-ID: 198A730C2044DE4A96749D13E167AD37012F69D8 () MOU1WNEXMB04 ! vcorp ! ad ! vrsn ! com
[Download RAW message or body]

Thank you very much for the comments. I will attempt to get another draft in before \
the cutoff but I am having much trouble at the moment with windows...

..as in the glazing kind. Having to repair an antique bay window that has suffered \
from not having had new putty for a century or so. 

> -----Original Message-----
> From: Florian Weimer [mailto:fw@deneb.enyo.de] 
> Sent: Thursday, July 05, 2007 9:27 AM
> To: Hallam-Baker, Phillip
> Cc: namedroppers@ops.ietf.org
> Subject: Re: XPTR Drafts
> 
> * Phillip Hallam-Baker:
> 
> > Record BasicPrefixResolve (
> > String node, String prefix, RecordType  record)
> > 1.   Record F1 =  Lookup (prefix + "." + node, record)
> 
> Nit: You don't want string concatenation, but domain name 
> concatenation.
> 
> > If  (F1 <> NIL) Return F1
> 
> You should explicitly address error code and no data 
> behavior, instead of just looking at the data section.  The 
> resolution algorithm should only proceed if there is an 
> RCODE=0, no data response.  You should also reference the 
> wildcard-clarify RFC (sorry, forgot its number), which is 
> said to specify that the query does not return NXDOMAIN when 
> there is the XPTR record there which is queried below.
> 
> > 2.   Record F2 = Lookup (node, PREPTR)
> > If (F2 = NIL) Return NIL
> 
> The error code should be passed on to the application.
> 
> > 3.   Record F3 = Lookup (prefix + "." + F2.domain)
> > Return F3
> 
> 
> > In such situations the service discovery process MAY 
> specify the use
> > of the Reverse DNS.  The reverse DNS is an area of the 
> DNS space (in-
> > addr.arpa, ipv6.arpa).  A PTR record in the reverse DNS maps an 
> > IPv4
> 
> I think it's ip6.arpa.  And your proposal might also apply to 
> e164.arpa in some way, so this whole section should probably 
> be generalized.
> 
> > Depending on the requirements of the service it MAY be 
> desirable for
> > discovery to process XPTR records in the reverse DNS 
> directly or to
> > first attempt to follow a PTR record to obtain a DNS 
> node where basic
> > prefix resolution is to be performed.
> 
> Hmm, hmm.  Is this really necessary?  It's less clear to me 
> what should happen if the reversed DNS name already has got a 
> NAPTR or SRV entry.
> 
> 
> The document should specifiy that the LHS of XPTR MUST NOT be 
> subject to label compression.  Name servers SHOULD NOT 
> perform additional section processing, and resolvers and 
> applications MUST NOT rely on it.
> 
> 
> Apart from that, I like your approach better than the dynamic 
> record type extension I described some time ago.  It seems to 
> address a similar set of issues, and the XPTR records are 
> much easier to write down and maintain manually.
> 

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>


[prev in list] [next in list] [prev in thread] [next in thread]