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

From: "Anne Brown" <[email-masked]>
Date: Tue, 27 Jun 2000 09:56:52 -0400

Quoting Greg, again, 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.  

Again, let's state that, please.

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

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

At 08.11 -0500 00-06-27, Anne Brown wrote:
>  >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.

Can you describe one?

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

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

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

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jun 2000 07:17:41 +0200

>Again, let's state that, please.

I asked you, and have not got a response:

- Give me text which describes one algorithm which can be used to go 
from an E.164 number to a URL

What I agreed to is that the domain name itself which is outcome of 
the pure mapping from E.164 to a domain name can be used for other 
things, but that is NOT part of the charter of this wg.

This wg is to find URLs given a E.164 number.

Other wg's can work with other things.

   paf

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