Re: [Enum] Reverse ENUM

["Michael Mealling" <michael@neonym.net>]

(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 user@foo.bar. 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 user@foo.bar. 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:michael@neonym.net). 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:mmealling@verisign.com 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:mmealling@verisign.com$!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
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum