Subject: [Enum] combined user/infrastucture ENUM proposal - proof of concept implementation - updated to draft-haberler-carrier-enum-02 - CORRECTED

From: Michael Haberler <[email-masked]>
Date: Wed, 15 Mar 2006 12:30:36 +0100

[sorry, hit the wrong button - please disregard my last message -mah]

I've updated the the proof-of-concept C implementation of our draft 
to reflect -02 (see 
http://www.enum.at/ietf/draft-haberler-carrier-enum-02.html ).

Files for perusal: http://mah.priv.at/enum/dash-02/

The tarball is at: http://mah.priv.at/enum/dash-02.tgz

-Michael

--- dash-02/README :

Combined Carrier and User ENUM under e164.arpa
----------------------------------------------

updated 13-3-2006

This is my example implementation of our I-D as upgraded to the
semantics outlined in
http://www.enum.at/ietf/draft-haberler-carrier-enum-02.html .

We propose to have a 'branch location record' at the country code
level under e164.arpa which specifies the name of the label to be
inserted, the position in the number, and now also the apex under
which the carrier subtree is located. This permits us to specifiy
an arbitrary location for the carrier tree, i.e. also completely
outside e164.arpa. There is an example for +49 where the whole
carrier subtree is referred to resolution through e164.org .

Both label insertion and apex are independent parameters now - a zero
length label implies no branch insertion, and the apex parameter
allows to point to an arbitrary location. Thus this is a mechanism
to integrate arbitrary ENUM trees into e164.arpa if one would want to do
so, for instance to shortcut ITU politics at a national or NPA level.

We expect to introduce, in the next revision of the draft, a minor
change which changes the BLR (branch location record) to have a label
(currently it sits directly at <cc>.e164.arpa). This label we will call
'resolution context' and could be 'carrier', 'user', or in fact any
arbitrary name. This way several different resolution contexts - and
this independent trees - could be specified; even the standard user
ENUM behaviour can be described by such a context in a backwards compatible
way - by specifying a zero-length label (meaning no label insertion) and
e164.arpa as apex. Thus resolvers would only need to implement the
semantics as per draft-03 and still work with exisiting user ENUM trees
without special-casing in the resolver code.

Examples for this named resolution context is already in the code, the
zone files, the DNS (see below) although we havent publised this yet.

I've updated the e164.mah.priv.at 'miniworld' under e164.mah.priv.at,
which is publically accessible. If you want to play with your own DNS
setup: the zone files and named.conf fragment used for this are in the
'bind' subdirectory. The zones under mah.priv.at are open also for
zone transfer.

To compile and run the demo (see shell script demo.sh), type

make demo

The expected output is in 'demo.out'.

The demo script executes 5 scenarios, with sample user and carrier
NAPTR records; the latter's location either determined through the
subdomain location table or the DNS TXT RR as described above.

[c.]3.4.e164.mah.priv.at ('c' for 'carrier')
[c.]1.7.5.1.e164.mah.priv.at
[c.]0.1.8.7.8.e164.mah.priv.at
7.[c.]e164.mah.priv.at
9.4.e164.mah.priv.at or 9.4.e164.org for the carrier tree.

Installation notes
------------------

Compiles ok under Linux.

I've neither tried to be most efficient, nor are error scenarios
thoroughly checked - this is a proof-of-concept.

The only source file specific to the I-D is c-enum.c, the rest is
support routines mostly for DNS.  I've liberally reused code for DNS
resolution from the iptel.org SIP Express Router distribution -
thanks, guys.

Suggestions/feedback welcome.

Michael Haberler [email-masked] 13-3-2006

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