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

From: "sajitha" <[email-masked]>
Date: Wed, 2 Nov 2005 23:02:44 +0530

The timeout value can be made configurable for this API. I will revise the
draft with this information. The asynchronous operation can be implemented
for this API, which will allow parallel lookups. In that case res_*() calls
cannot be used & the API has to implement send/receive by its own. Does this
sound okay?

-sajitha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim
Reid
Sent: Thursday, October 27, 2005 7:50 PM
To: Otmar Lendl
Cc: [email-masked]
Subject: Re: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt]

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

> The timeout requirements regarding ENUM may be different than for  
> other
> 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?

> 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.

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.

> 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.

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.

> 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.

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

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

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

---

From: Jim Reid <[email-masked]>
Date: Thu, 3 Nov 2005 14:01:23 +0000

> cannot be used & the API has to implement send/receive by its own.  

I'm not sure: probably not. It might be a good starting point for a  
discussion about an API though. A lot of work would need to be done  
on a requirements document before an API could be worked on. And  
there's still the unresolved question of where that API  
standarisation work would be done.

---

From: Richard Shockey <[email-masked]>
Date: Thu, 03 Nov 2005 10:30:16 -0500

Jim Reid wrote:
>> for this API, which will allow parallel lookups. In that case res_* () 
>> calls
> discussion about an API though. A lot of work would need to be done  on 
> a requirements document before an API could be worked on. And  there's 
> still the unresolved question of where that API  standarisation work 
> would be done.

Where is right.

We can discuss this in Vancouver ( quickly ) but frankly I do not see 
this document as being relevant to our revised charter.

Speaking as co-chair IMHO this document is out of scope.

-- 

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>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<