[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Enum] Reverse ENUM
- To: "Michael Mealling" <michael@neonym.net>, "Zmolek, Andrew (Andy)" <zmolek@avaya.com>, "Lind, Steven D, ALASO" <sdlind@att.com>, "Keats, Evan" <evan.keats@nz.unisys.com>
- Subject: [Enum] Reverse ENUM
- From: "Stastny Richard" <Richard.Stastny@oefeg.at>
- Date: Thu, 17 Oct 2002 10:35:35 +0200
- Cc: <enum@ietf.org>
- List-help: <mailto:enum-request@ietf.org?subject=help>
- List-id: Enum Discussion List <enum.ietf.org>
- List-post: <mailto:enum@ietf.org>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,<mailto:enum-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,<mailto:enum-request@ietf.org?subject=unsubscribe>
- Sender: enum-admin@ietf.org
- Thread-index: AcJ1QD7Ov2vuHFUwTeuUUu9OvXVvJgAdDvVg
- Thread-topic: Reverse ENUM
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 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).
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.
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
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum