Subject: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt]

From: Richard Shockey <[email-masked]>
Date: Sat, 22 Oct 2005 11:46:29 -0400

-------- Original Message --------
Subject: I-D ACTION:draft-sajitha-enum-api-00.txt
Date: Fri, 21 Oct 2005 15:50:01 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: An ENUM Library API
	Author(s)	: T. Sajitha
	Filename	: draft-sajitha-enum-api-00.txt
	Pages		: 7
	Date		: 2005-10-21
	
This draft defines a library API for ENUM. The API takes telephone
number as input and returns the URI associated with that telephone
number.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sajitha-enum-api-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-sajitha-enum-api-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-sajitha-enum-api-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 24 Oct 2005 11:47:37 +0200

Hi!

Some comments to this draft:

The API is very simple and thus easy to use in simple applications. But 
IMO the API is too simple. Consider the case of an universal messaging 
application which supports voice (sip,h323,iax), email, fax and sms. 
Then it will be useful to retrieve all supported service types and ask 
the user which service it would like to use.

Using this API you would have to call geturiinfo() several times for 
each service type suported by the application (which probably ends up 
with multiple DNS lookups).

I would suggest a more flexible API which seperates the ENUM lookup into 
smaller pieces.

eg.:

   int get_enum(const char *telephonenum, int enumhandle);
This makes the DNS lookup and stores the NAPTRs somewehere

   ... get_servicetypes(int enumhandle);
returns the supported servicetypes (a pointer to a list of strings or 
something simmilar)

   int get_uri(int enumhandle, char *service_type, struct
     uriinfo **res);
get the URI for a certain service type

   void free_enum(int enumhandle);
free the ENUM resources

regards
klaus

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 24 Oct 2005 15:12:57 +0200

> http://www.ietf.org/internet-drafts/draft-sajitha-enum-api-00.txt

This API misses one rather critical aspect for production system
ENUM deployment: Configurable timeouts.

Misconfigured ENUM delegations/nameservers can lead to significant
delays before the resolver program gives up. It should thus be
possible to tell the ENUM resolver API to give up after x seconds.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: "sajitha" <[email-masked]>
Date: Wed, 26 Oct 2005 09:30:38 +0530

Hi,

The timeout configuration comes as part of the API implementation. The
implementation can use res_*() calls for DNS look-ups wherein many vendors
already provide the timeout configuration option. Does this make sense for
the ENUM deployment? Do you think there is a need for timeout configuration
which is specific to ENUM resolution as compared to any other DNS
resolution?

Regards,
Sajitha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Otmar Lendl
Sent: Monday, October 24, 2005 6:43 PM
To: [email-masked]
Subject: Re: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt]

/ol

---

From: "sajitha" <[email-masked]>
Date: Wed, 26 Oct 2005 09:30:38 +0530

Hi,

A NULL service type argument to the API will retrieve all supported service
types. Applications can traverse the uriinfo linked list returned by this
API to get all the information. Please see page 3 of the draft :

"The DNS response should be parsed by the API as given below:

1.	If service type is NULL, all URIs corresponding to this E.164 
number should be returned along with the corresponding service 
type, service type length, all service subtypes & service subtype 
length. In case of non NULL service type, all the records in the 
DNS response should be parsed one by one applying the following 
rule: ..."

So multiple DNS lookups or call to geturiinfo() is not required.

Regards,
Sajitha

-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]] 
Sent: Monday, October 24, 2005 3:18 PM
To: [email-masked]'
Cc: [email-masked]
Subject: comments on draft-sajitha-enum-api-00.txt

Hi!

eg.:

regards
klaus

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 27 Oct 2005 12:26:32 +0200

> which is specific to ENUM resolution as compared to any other DNS

The timeout requirements regarding ENUM may be different than for other
DNS lookups. Typically DNS resolutions need to complete before the
application can proceed. e.g. SRV and A lookups for SIP calls.
If the DNS fails, then your application fails and you notify your
user that "sorry, I tried everything I could but it don't work out".

ENUM can be different: if your application does transparent re-routing
of calls to VoIP based on ENUM then a DNS failure during the ENUM
lookup does cause the call to fail. It just means that the VoIP path is
not possible. But you don't want to spend 60 seconds trying a set of
unreachable nameserver to get that info. The user-experience would be
terrible. You want a definite upper bound on how long that ENUM lookup
can take before you give up and go for the PSTN route.

I don't like your reference to res_*(). These calls are not defined in your API.
You're implying that any implementation of your API will be based on
libresolv and not some other DNS library like adns or firedns.
(see http://www.chiark.greenend.org.uk/~ian/adns/ http://freshmeat.net/projects/firedns/)

But even I we assume libresolv, your API does not expose the underlying
res_state structure, so I have to conclude that you use res_init() and
not res_ninit(). This implies the user cannot set the timeouts in a
thread-safe way.

Furthermore, I don't think that the timeout configuration in libresolv
is all that helpful as you can only set RES_RETRANS and RES_RETRY for
individual servers and not an overall timeout.

IMHO a feature-complete ENUM API should also contain functions to:

	* query more than one tree in parallel
	* asynchronous operation

As I'm doing some programming on the Asterisk ENUM code again I would
really appreciate a decent API for ENUM lookups to rely on. Your API is a
fine first step, but it does not solve all the issues that crop up in
production use.

Cheers,

/ol

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 Oct 2005 15:19:48 +0100

On Oct 27, 2005, at 11:26, Otmar Lendl wrote:

> DNS lookups.

Agreed. Someone needs to capture those requirements: ie how long will  
it be after someone picks up an ENUM handset before they get a ring  
signal?

> libresolv and not some other DNS library like adns or firedns.

True enough, but libresolv (for all its many faults) is ubiquitous.  
The DNS is badly in need of a decent API. And not just for ENUM. So  
far nobody has shown much interest in working on this or funding it.  
So until that changes, we're pretty much stuck with an API that's  
almost 20 years old.

> individual servers and not an overall timeout.

These parameters only affect the stub resolver. So they're not much  
help if the recursive server that gets these queries is playing by  
different rules.

> really appreciate a decent API for ENUM lookups to rely on.

Indeed. But who can develop this API and steer it through the likes  
of X/Open or IEEE?

---

From: Richard Shockey <[email-masked]>
Date: Fri, 28 Oct 2005 12:34:39 -0400

> Indeed. But who can develop this API and steer it through the likes  of 
> X/Open or IEEE?

This is the question I have for this document.

Are API's an appropriate standardization task for the IETF?

IMHO no. but I'd like some one to convince me otherwise or show me other 
examples of API's in the IETF along with the underlying justification 
and problem statement as to why the work should be done here.

--

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 31 Oct 2005 15:18:38 +0000

> Are API's an appropriate standardization task for the IETF?

No.

> and problem statement as to why the work should be done here.

The only one I've seen as an RFC contained significant fallacies based on a
lack of understanding of the C Standard.

APIs should be developed in IEEE, X/Open, ISO/IEC, Austin Group, etc. Pick
one and petition them to do it.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |