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

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 27 Jun 2000 09:24:18 -0500

I believe a set of SRV DNS RRs or MX RRs qualifies as a "set of attribute
which can be used to contact a resource associated with that number."  I
read the "(e.g. URLs)" as a parenthetical example, not a restriction on the
types of resources that may be supported by the resulting protocol.

Greg V.

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Tuesday, June 27, 2000 8:45 AM
To: Anne Brown; '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

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

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

---

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

>types of resources that may be supported by the resulting protocol.

I do not agree. You need more information than what is stored in an 
MX or SRV, for both SMTP and LDAP and other protocols I know of.

Why do you oppose a URI as the outcome?

What can you not express as a URI?

   paf