Enumservice VOID draftstastnyenumvoid00

About This Presentation

Title:

Description:

Number of Views:35

Avg rating:3.0/5.0

Slides: 10

Provided by: enum6

Category:

Tags: void | draftstastnyenumvoid00 | enumservice | unassigned

Transcript and Presenter's Notes

Title: Enumservice VOID draftstastnyenumvoid00

1
Enumservice VOIDdraft-stastny-enum-void-00

2
Abstract

Registers the 'ENUMservice' 'void' using the URI
scheme 'mailto'
This 'ENUMservice' SHALL be used to indicate that
the E.164 number or E.164 number range connected
to the domain used in DNS as described in RFC3761
is not assigned to
an end-user in case of an E.164 number or
to a communication service provider in case of an
E.164 number range.

3
Current Situation

For ENUM, the E.164 number assignee has the
exclusive right to register a domain associated
with "their" number, and has exclusive control
over the content made available in this zone.
If an assignee of an E.164 number does not choose
to register the associated ENUM domain, then any
DNS query on that domain will return a response
indicating 'no such domain' (NXDOMAIN, code 3).
If no registration exists associated with an
E.164 number, then that potential caller (or
their agents) have no further information, and
drop the call to their default network (e.g. the
PSTN), assuming that this will route the call
appropriately.

4
The problem

Some NRAs now allocate number ranges for
exclusive use of ENUM registrations (e.g. 43780
in Austria).
Calls to E.164 numbers in this range MUST be
processed using ENUM, and delivered to the URI
generated as a result of a successful ENUM query.
Such a call CANNOT be simply "dropped" onto the
default network for delivery.

5
The issue

The originating user agent is unaware of this
choice, may assume to drop the call to the PSTN
and the call will fail.
So a mechanism "between" a registration holding
NAPTRs with URIs and the lack of a domain
registration would be useful.
As there is no end user as an assignee for an
unused number, there cannot be a registration for
the associated ENUM domain.
It would be useful if the originating end user
could receive a response that states "there is no
service via this number.

6
The proposed solution

We propose an explicit indication of this "number
unassigned" state.
This uses a NAPTR in the "enclosing" zone, with
an enumservice called VOID that should be taken
as an assertion that the associated E.164 number
is not assigned to an end user for communications
service it's an unused number.
This NAPTR can also be used by an NRA to indicate
number blocks that it has reserved or has not
allocated, or has not assigned to a service
provider.

7
The mailto URI

Where a number (or number range) has not been
assigned to an end user, there cannot be an
associated ENUM registration.
Thus there cannot be information made available
via ISIS/Whois on the identity of the current
"owner" of the number.
For this reason, we propose that the VOID
indication also includes an email address by
which the authority responsible for this number
(or range) can be contacted.
This may not be the same entity as the one that
maintains the DNS service for that "enclosing
zone" often the NRA will sub-contract a Registry
Operator to maintain the DNS, but it is the NRA
who is the authority for the E.164 number range,
not that Registry Operator.

8
Enumservice VOID

Enumservice Name "void"
Type(s) "void"
Subtype(s) "mailto"
URI Scheme(s) "mailto"
Definition of expected action
If a NAPTR with this ENUMservice is received, it
indicates that the queried E.164 number is
currently unassigned to an end user for
communications service.
The recipient SHOULD treat this response as if
they had received a "number not in service"
indication from a terminating network.

9
Example

ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa.
8.3.0 NAPTR 10 100 "u" "E2Uvoidmailto"
"!.!mailtonum-drama-info_at_ofcom.org.uk!"
This indicates that the controller of the number
block 441632960xxx does not provide telephony
service via the number 441632960038 it is not
assigned to an end user.

Write a Comment

User Comments (0)