Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement

From: "Anne Brown" <[email-masked]>
Date: Tue, 27 Jun 2000 08:11:15 -0500

My comments in text below.

Anne Brown
Nortel Networks
[email-masked]
+1 613 765 5274

 -----Original Message-----
From: 	Patrik Fältström [mailto:[email-masked]] 
Sent:	June 26, 2000 5:56 PM
To:	Brown, Anne [CAR:5N00:EXCH]; 'ENUM'
Cc:	Scott Bradner
Subject:	Re: FW: [Enum] NAPTR is not as an ENUM Requirement

At 10.45 -0500 00-06-26, Anne Brown wrote:
>As stated in the requirements draft, the ENUM system provides a 
>service for the retrieval of service-specific endpoint addresses OR 
>the retrieval of the addresses of servers, if  available, which may 
>contain this endpoint information.

I quote the charter of this Working Group:

>This working group will define a DNS-based architecture and 
>protocols for mapping a telephone number to a set of attributes 
>(e.g. URLs) which can be used to contact a resource associated with 
>that number.

This doesn't contradict with my request.  The resource associated with a
number could be a directory server.  The top level RR pointing to the
directory server need not have service-specific information associated with
it.  I would still like to see text in the abstract and introduction,
stating that there are alternative uses of the ENUM service than retrieval
of service-specific information.  That is, there are alternatives to the
NAPTR RR in the ENUM service.

This is what this working group is working with.

That said, the mapping from a E.164 number to a domainname can be 
(re)used for other things, but that is up to other working groups to 
talk about.

I don't know what other groups you are talking about.  We need the ability
in ENUM to locate either end-point address information, or the location of a
repository that contains that information.

Quoting Greg in an earlier message in which you agreed:
>Coming out of the Adelaide meetings, I understood we had agreement that
>NAPTR is good and useful but not a requirement for the deployment of the
>ENUM service.  

Let's state that, please.

Regards,
Anne

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 27 Jun 2000 15:44:47 +0200

At 08.11 -0500 00-06-27, Anne Brown wrote:
>This doesn't contradict with my request.  The resource associated 
>with a number could be a directory server.  The top level RR 
>pointing to the directory server need not have service-specific 
>information associated with it.  I would still like to see text in 
>the abstract and introduction, stating that there are alternative 
>uses of the ENUM service than retrieval of service-specific 
>information.  That is, there are alternatives to the NAPTR RR in the 
>ENUM service.

Can you describe one?

Note that the algorithm should be DNS based, the input is a E.164 and 
the output URL(s).

>I don't know what other groups you are talking about.  We need the 
>ability in ENUM to locate either end-point address information, or 
>the location of a repository that contains that information.

Other wg's can be created when there is interest and firm statement 
on what they are supposed to deliver.

Note that in the world, the client which only have one E.164 number 
is to know what to do with that number and get more information. 
Having an _or_ in the algorithm is normally "a good thing" because 
that means that the client have to do two things, out of which one 
will fail (if two choices exist).

My take is that I have not seen any other proposal on how to take an 
E.164 number and get URL(s) back than using DNS and NAPTR RRs.

Note that _additional_ information can be found by using LDAP URIs or 
SIP URIs or whatever after the first DNS resolution. So I am not 
saying that the NAPTRs are enough for building services, only that 
having alternative ways of fetching the (initial) URLs will create 
interoperability problems.

    paf

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