Subject: RE: [Enum] Reverse ENUM

From: "Stastny Richard" <[email-masked]>
Date: Fri, 18 Oct 2002 10:10:31 +0200

Hi MM,
Thank you for the (loooong...) explanation, it helped ;-)

Anyway, the explanation raised some other questions,
mainly what is already defined and what needs still 
to be standardized.

1.Regarding the uri.arpa:

Do I understand it correctly, that you may have normally
one entry per URI e.g. in sip.uri.arpa for the decomposting (ups)
deconstruction rules for sip or may you have more than one?

What is required to get the rules into uri.arpa, a RFC?
If there is only one rule possible, would not be a RFC for 
IANA registration stating the deconstruction rules sufficient?

Furthermore, I do not see much sense having one additional query 
on each DNS lookup to get the deconstruction rules.

2.Regarding the nice chat with the ldap servers etc.:

> that connects to ldap.neonym.net and asks it "What email 
> attachment formats does the user 'michael' prefer?"

or
> connect and ask that LDAP server "What is the E.164 reverse 
> lookup for this SIP address?" and then you get back 

Is this somewhere standardized already, or is there still work
to be done?

3.Regarding your two examples

> 0    0    "u"    "ldap+I2C"
> "!^sip:(.*)@(.*)$!ldap://ldap.verisign.com/user=\1!" .
>  
> 0    0    "u"    "tel+I2R"
> "^sip:[email-masked]$!tel:+1-779-555-1212" .
> 
> But I personally prefer the one that redirects to some 
> intermediary directory service so you can insert policy 'n stuff....

Of course I would also prefer the first example, because
the second would not scale with more than 10 records (users)
in a domain. Imagine you get back 1000 NAPTRs in one query.

I still would prefer the more simplistic version with the
at. Domain. This would be in your example

either

IN NAPTR 0    0    "u"    "tel+I2R"
"^sip:[email-masked]$!tel:+1-779-555-1212" 
in mmmealling.at.verisign.com

which scales better for few users
or
 
If you have many records, you may use
* IN NAPTR 0    0    "u"    "ldap+I2C"
"!^sip:(.*)@(.*)$!ldap://ldap.verisign.com/user=\1!" 
in at.verisign.com

4.And finally, to my favorite, the enum: URI

The first example is IMHO another reason why we need an 
enum: URI, 
because if a tel URI is returned here, this means you 
should make a phone call directly, 
if you want to indicate an ENUM query should be done, 
the enum: URI should be used.

IN NAPTR 0    0    "u"    "tel+I2R"
"^sip:[email-masked]$!enum:+1-779-555-1212" 

Regards
Richard

> -----Original Message-----
> From: Michael Mealling [mailto:[email-masked]] 
> Sent: Thursday, October 17, 2002 3:24 PM
> To: Stastny Richard; Zmolek, Andrew (Andy); Lind, Steven D, 
> ALASO; Keats, Evan
> Cc: [email-masked]
> Subject: Re: [Enum] Reverse ENUM
> 
> 
> (loooong....)
> 
> Richard Stastny said this:
> > Michael Mealling wrote:
> > > This is what RFC 3404 does. It takes _any_ URI and looks up the 
> > > deconstruction rules for how to find an authoritative 
> server for it. 
> > > I.e. the NAPTR record for sip.uri.arpa would look like this:
> > >
> > > sip.uri.arpa    IN      NAPTR    0    0    ""    ""
> > > "!^sip:(.*)@(.*)$!/2!"    .
> > >
> > > Which says, "go ask the domain-name in that address for a NAPTR 
> > > record that can tell me if a server can answer questions 
> about this 
> > > URI". One of the obvious questions would
> > > be: "since a SIP server isn't responding, what should I do to 
> > > contact that user?" and the result would be a tel: URL, 
> or an error 
> > > message sayign what happened, or a redirect to another 
> sip address, 
> > > etc.
> >
> > The principle of "Reverse ENUM" should be, that in the same way you 
> > use a client querying for an E.164 Number in the format 
> +1234xxx you 
> > may use the same client entering [email-masked]. The idea is, that in 
> > the domain foo.bar somewhere a NAPTR? is stored pointing to 
> the ENUM 
> > entry for the phone number (e.g. with a tel: or enum: URI).
> 
> Correct.
> 
> > The user would always get the same information regardless if he is 
> > entering either the +431xxx or the [email-masked]. One simple 
> approach 
> > was (as proposed by Rich et.al) to store the NAPTRs? by 
> convention in 
> > subdomains user.at.foo.bar of the domain foo.bar. A more 
> sophisticated 
> > approach may retrieve the "user" part with a ldap pointer from the 
> > mail or sip server.
> 
> That is what RFC 3404 (will) say: that there is a NAPTR or 
> series of NAPTRs for the right hand side of the sip/email 
> address. Those NAPTR records will point you to one or more 
> services that can answer questions about the left hand side 
> of the address. Some have suggested LDAP as you have. I 
> prefer something like what the RESCAP working group was 
> trying to do. The trick of turning the @ into an 'at' domain 
> causes the number of NAPTR records in the zone to equal the 
> number of users which causes there to be a huge number of 
> unneeded DNS records (i.e. _Everyone_ in your company would 
> have a NAPTR record instead of every phone).
> 
> > Michael, since I do not fully understand your example and also your 
> > (soon to come) RFC3404, (I tried, but it gave me a 
> headache) could you 
> > please elaborate more on your proposal, to enlighten me ;-)
> 
> I'll run through a more typical RFC 3404 example and then do a SIP
> example:
> 
> Let's say you want to send me a document but you don't know 
> whether or not I prefer postscript or PDF. You have my email 
> address so you turn that email address into a URI by just 
> sticking 'mailto:' in the front (e.g. 
> mailto:[email-masked]). Now, your uber-DDDS tool does a 
> NAPTR query for 'mailto.uri.arpa' (uri.arpa == e164.arpa but 
> for URIs). One NAPTR record comes back that has a  rewrite 
> rule that essentially says to take the domain-name portion of 
> the email address and use that to go find more NAPTR records 
> (remember the "non-terminal NAPTR" discussion we had a month 
> or so ago?). So, the client goes off and requests NAPTR 
> records for "neonym.net". It recieves a couple of them but 
> one in particular looks like this:
> 
> 0    0    "u"    "ldap+I2C"
> "!^mailto:.*$!ldap://ldap.neonym.net/ldapstuff!"    .
> 
> Which says that for mailto URIs you should talk to my LDAP 
> server. Your uber-DDDS client then runs some little LDAP tool 
> that connects to ldap.neonym.net and asks it "What email 
> attachment formats does the user 'michael' prefer?". You get 
> the answer and send me the attachment as a PDF instead of 
> postscript (also getting my public key in the process so that 
> you can encrypt it).
> 
> Ok, so back to SIP and ENUM. As with the example above you 
> have one of my three SIP addresses (one for home, one for 
> work sip:[email-masked] and one that I got free with 
> my Voicestream phone). But the odd thing is that the one for 
> work isn't responding, so you take the SIP address and hand 
> it to your uber-DDDS client and it requests NAPTR records for 
> 'sip.uri.arpa' and gets back a record that says "take the 
> domain-name on the right hand side of the @ and look up more 
> NAPTRs for that domain-name". Your client does that and gets
> this:
> 
> 0    0    "u"    "ldap+I2C"
> "!^sip:(.*)@(.*)$!ldap://ldap.verisign.com/user=\1!" .
> 
> Which says, take the first part of the sip address and use it 
> in the LDAP URL to ask questions about that SIP user. You 
> connect and ask that LDAP server "What is the E.164 reverse 
> lookup for this SIP address?" and then you get back 
> "+1-779-555-1212". That's one way of doing it. You could also do this:
> 
> 0    0    "u"    "tel+I2R"
> "^sip:[email-masked]$!tel:+1-779-555-1212" .
> 
> But I personally prefer the one that redirects to some 
> intermediary directory service so you can insert policy 'n stuff....
> 
> Does that make sense?
> 
> -MM
> 
> 
> 
> 
> 
> 
> 
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Michael Mealling" <[email-masked]>
Date: Fri, 18 Oct 2002 09:31:26 -0400

> Thank you for the (loooong...) explanation, it helped ;-)

Great!

> mainly what is already defined and what needs still

IMHO, the one to reckon with now is James' previous employers IP claims.....

> deconstruction rules for sip or may you have more than one?

You would have one per URI scheme and it would have an insanely long TTL.
Essentially you want caches to keep this record for as long as possible
because it should never really change.

> IANA registration stating the deconstruction rules sufficient?

An RFC isn't necessary for the registration of the NAPTR record but an RFC
is required that documents the actual URI scheme itself. Since 'sip' has
been registered in RFC 2543 its
just a matter of getting the appropriate people to review the registration
and send it to
[email-masked]'. The members of the list will approve it, it will get
reviewed by the IESG and
it goes in the nameserver.

> on each DNS lookup to get the deconstruction rules.

Hence the really long TTL for that record. Its there for two reasons:
1) you can delegate that record directly out to a zone that has a shorter
TTL if there is a need for this particular scheme's NAPTR record to change
(feature additions, services, etc).

2) For systems that do not understand the actual scheme but do understand
the DDDS they can find gateways that can proxy that scheme for them, thus
allowing bootstrapping of new URI schemes without having to upgrade very
client in the world.

> Is this somewhere standardized already, or is there still work

Still work to be done... Seems like it would be easy, fun work since you can
start getting into all sorts of AAA and policy stuff as well as interesting
call routing questions. I.e. ENUM is kind of limited in order to be
interoperable. By using something like LDAP/RESCAP/etc you get to have
schemas which lets you interoperate a diferent way. Thus, this is where you
can go crazy and do all the fun stuff.

> in a domain. Imagine you get back 1000 NAPTRs in one query.

Exactly...

> "!^sip:(.*)@(.*)$!ldap://ldap.verisign.com/user=\1!"

But why the 'at.versign.com'? Putting it in 'verisign.com' does
the exact same thing.....

> enum: URI,  because if a tel URI is returned here, this means you

Yep. But you could do both since the protocol profile is in the Services
field...
It looks like you grokked it all to me!

-MM

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 18 Oct 2002 15:39:33 +0100

>Thank you for the (loooong...) explanation, it helped ;-)

<snip>

>at. Domain.

Hi Folks,

Forgive the question, but...

As the goal was to map from email address to "e-number",
then IFF we have an "enum:" URI, then why not just have:

$ORIGIN lwc.at.roke.co.uk.
.    IN  NAPTR  0  0  "u"  "X2U" "!^.*$!enum:+441794833666!" .

Now, this means a constructed lookup based on my email address
should submit an ENUM query based on the E.164 number to find my
contact information.

I'm only looking up one email address at a time, so this seems
to work for me. I may be missing something, but why would I need
ANYTHING more complex?

----

If every email address within a group mapped to a single "e-number"
then I guess we'd use a * entry with the same data.

In D3S application terms I guess that X2U accepts an email address,
converts the '@' to '.at.', and submits the result.
The AUS is (maybe) an email address, the 1st well known rule is either
null/identity or "replace the '@' with ".at.'", the database is DNS,
and the result is a URI.

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.

---

From: "Michael Mealling" <[email-masked]>
Date: Fri, 18 Oct 2002 11:06:29 -0400

> to work for me. I may be missing something, but why would I need

1) It means having a DNS entry for each email address. For a small domain
like VeriSign this would be fine. But for something like hotmail, AOL, MSN,
etc it would mean a huge increase in the number of subdomains for the given
zone.

2) There is a direct correlation between an email address and a user. As a
rule of thumb the DNS shouldn't be used to store information about users or
documents directly. Instead it should be used to denote devices in domains
in order for aggregation to allow the caching mechanisms to work. I.e. zones
like '.com' shouldn't be encouraged to happen.

3) Users expect to be able to exert policy restrictions surrounding their
email address. Putting mappings directly from email to telephone number in a
public space will cause a lot of headaches.

> then I guess we'd use a * entry with the same data.

But DNS doesn't allow you to do that on a subset basis. I.e. everything
below at.example.com has the same record or everything under at.example.com
must have its own record. You can't do the in between without using the DDDS
regular expression method.

> null/identity or "replace the '@' with ".at.'", the database is DNS,

But by doing that you're creating an unneeded rewrite. Also remember, the
mailto URI scheme will have other services associated with it. You want to
delegate down to the authority for that domain and then ask _that_
nameserver whether or not it has any idea what E.164 number mapping service
exists for that domain. Hard examples:

mailto:[email-masked]

mailto.uri.arpa    IN NAPTR 0    0    ""    ""    "!^mailto:(.*)@(.*)$!\2!"
.

example.com    IN NAPTR 0    0    ""    "enum+X2U"
"!^mailto:(.*)@example.com!\2.at.example.com" .

foo.at.example.com IN NAPTR 0    0    "u"    "enum+X2U"
"!^.*$!+1-679-555-1212!" .

That method creates an additional subdomain when none is necessary. Either
the bloat occurs in the 'at.example.com' domain or it occurs in the
'example.com' domain, it doesn't really buy you anything other being able to
set a zone level TTL.

Here's one really important issue: is this really "ENUM reverse lookups" or
is it "find an e.164
number given a sip address" because ENUM can point you to any URI so this
won't work for all of ENUM. If its "I want to find a telephone number given
an email address" then you're talking about suggesting putting information
in DNS for email when the email guys will tell you it had better be in some
kind of redirected server (LDAP).

I think we're discussing several diferrent services depending on what the
starting identifier is. If its a SIP address then its pretty simple. If its
an email address then you're part of a much larger application that the
RESCAP WG is looking at. If its _any_ URI (which is what ENUM does) then
you're talking about a specific global Service level definition that would
need to be available for any URI scheme that's resolveable by the DDDS.

-MM

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 18 Oct 2002 17:48:14 +0100

>etc it would mean a huge increase in the number of subdomains for the given

This is indeed a lot of work for AOL's DNS admin folk. And this means it does
not work for me because...?

>like '.com' shouldn't be encouraged to happen.

Correlated person for email address [email-masked]' is...?
For the rest, that is a valid opinion.

>public space will cause a lot of headaches.

That is also an opinion. However, technically, the "direct mapping" works?

>>  then I guess we'd use a * entry with the same data.
   c/group/zone/
oops...
>regular expression method.

Works for me, as per Section 4.3.3 of RFC1034.

>foo.at.example.com IN NAPTR 0    0    "u"    "enum+X2U"

Hmmm....I don't understand the "un-needed rewrite" statement.
I have an email address - I want the associated ENUM number. The 
examples do not
help to explain why I cannot place a NAPTR within the foo.at.exaple.com zone.
I'm not clear on why I care whether or not the "mailto scheme having other
services associated with it".

The first example seems to be the <scheme>.uri.arpa RR.

The second example seems to be a redundant step.
I have an application that is passed an email address and converts it as
described in my earlier email. This is part of the first well known rule,
or the database key step (akin to "reverse digits, interpose bullets,
and append .e164.arpa" in RFC2916bis). This is done by the program on the
querying client machine.
=> I cannot understand why this extra NAPTR is required or useful.

The third example is incorrect. There is no URI output from this NAPTR.

>kind of redirected server (LDAP).

SIP can already return (has always returned) a URI in a 3xx redirect; It'll
return whatever URI you have registered.  This is a non-problem, IMHO.

I'm interested solely in Reverse ENUM.

I cannot see from these comments why the scheme I mentioned doesn't suffice.
I'll agree that it's a lot of work for AOL, and my heart bleeds for them.
However, how is it illegal?

all the best,
   Lawrence