Subject: RE: [Enum] ENUM and location information

From: "Stastny Richard" <[email-masked]>
Date: Mon, 04 Jul 2005 06:15:27 -0400

And in addition to Lawrence:

LOC needs an additional query and it
is not very useful to query for LOC
on each ENUM query just to see if
a LOC is eventually there

Richard

Richard Stastny
OeFEG
tel:+43 664 420 4100
enum:+43 780 203 211
callto://fordprefect
http://voipandenum.blogspot.com

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Mon, 04 Jul 2005 10:07:47 -0400

On Jul 4, 2005, at 10:57, Stastny Richard wrote:
And in addition to Lawrence:
LOC needs an additional query and it is not very useful to query for 
LOC
on each ENUM query just to see if a LOC is eventually there
Hey, it's not much use querying for NAPTRs in e164.arpa.... :-(
The additional query defence is a non-sequitur IMO. Doing a lookup for 
a LOC record is likely to be just as quick as parsing some GML string. 
And far quicker than resolving any domain names that happen to be 
embedded in that string. If someone was *really* inconvenienced by the 
latency of an extra DNS query, they could do an ANY query instead of a 
NAPTR query for the domain name and the response would almost certainly 
include the LOC record if one existed.

Besides, this is yet another chicken-and-egg problem. There are no LOC 
records in the tree because no clients look for them. Clients don't 
lookup LOC records because there's no recommendation/standard to 
require that. So this is a disincentive for populating zones with LOC 
records. Sigh.

Frankly, I don't see the point of defining ENUM Services (and Subtypes) 
for things that can already be adequately be described by an existing 
DNS record type. This looks to be a bad example of re-inventing the 
wheel. [Coming soon: an ENUM Services definition for an IP address. Or 
a mail exchanger. Or...] Using GML strings seems particularly bad. The 
GML spec google found for me is 600+ pages while the LOC record 
definition only takes 3-4 pages of RFC1876. Which one would you choose 
to implement? For bonus points, which would  preferable for something 
like a mobile phone?

There's no rule that says only NAPTR record types are permitted in the 
e164.arpa tree.  In fact putting other DNS RRs in that part of the tree 
could be very, very useful. For instance an ENUM-aware location 
application could just lookup the LOC record for my phone number, 
assuming of course I put one in my zone file. [No need to plough 
through all the NAPTRs, do all the  precedence/order processing, then 
regexp substitions and GML decoding.] Or to take an other example, an 
SSH client could make a query for an SSHFP record to get any SSH keys 
for my phone number.