Subject: [Enum] Reverse ENUM

From: "Stastny Richard" <[email-masked]>
Date: Thu, 17 Oct 2002 10:35:35 +0200

Hi MM,

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.
> 

At the last Pulver Conference in Atlanta VON Fall2002 the idea
of "Reverse ENUM" was discussed at various places. Even Vint Cerf
mentioned it in his speech. BTW, Vint Cerf talked about 10 min about
the importance of ENUM and Rich nearly got a heart-attack because
he had no voice-recorder on ;-)

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).

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.

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 ;-)

Best regards
Richard Stastny

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Michael Mealling" <[email-masked]>
Date: Thu, 17 Oct 2002 09:24:24 -0400

(loooong....)

> to the ENUM entry for the phone number (e.g. with a tel: or enum: URI).

Correct.

> 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).

> 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

---

From: "James Seng" <[email-masked]>
Date: Fri, 18 Oct 2002 01:34:13 +0800

I hate to be the one pouring cold water on this stuff but...I probably
should inform the group that there was a patent filed in Oct 2001 by my
previous employee on a titled 'Phone Name'. The broad claim involve using
the DNS to resolve a name into a tel: or fax: URL via NAPTR records.

In a couple of months, it should appear on the USPTO website.

Regardless of the merits of the patent filing, the group should take note of
this IPR.

-James Seng