Subject: [Enum] "enum:" URI comments

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Thu, 14 Nov 2002 13:04:36 +0000

Hi John, Michael, Folks,

A long time ago, in a land far away, Jon said:
At 4:55 pm -0500 3/9/02, Peterson, Jon wrote:
>The ENUM URI in this case would be an opaque pointer
>to a set of communications records, but this requirement could be fulfilled
>by any number of existing URI schemes that have no bearing on telephone
>numbers (I'm sure DDDS would allow this in any number of ways).

Jon:
I don't see what existing URI schemes can do this - if there is such a URI
scheme that fulfills the "MUST check ENUM or die" requirement, then please
holler and we can save some meeting time.

Michael - our avowed D3S Wizard:
I don't see how D3S can generate a "ENUM golden tree" FQDN.
I did ask earlier, but was not specific enough. I understand that one
can point out to some other domain space - it's the RegExp mechanism
for creating a FQDN in e164.arpa that I can't get, particularly with
an open number plan.

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 14 Nov 2002 13:35:31 -0500

I had thought this thread had relocated to iptel, but, a response inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:[email-masked]]
> Sent: Thursday, November 14, 2002 5:05 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: "enum:" URI comments
> 
> 
> Hi John, Michael, Folks,
> 

It has been suggested that a tel URL parameter would be sufficient for this
purpose. There can be mandatory tel URL parameters (see the text about
behavior of the 'm-' prefix in rfc2806bis). An 'm-enum=yes' parameter on a
tel URL would do nicely, I think.

That much said, I maintain that this idea seems to have little practical
application. The text from me that you cite above was not intended to speak
to this 'check ENUM' concept, but rather to the fact that the ENUM URI
proposal satisfies requirements that are very much orthogonal to the ENUM
problem. If you want a URI scheme for some kind of opaque pointer and that
can be dereferenced to return a set of communications records, there are a
number to choose from that are totally unrelated to ENUM (why not just use
LDAP?). ENUM is a technology for translating telephone numbers into URIs -
you need that when you have a telephone number that you don't know what to
do with. If you know enough about a telephone number to be able to decide
that it should be represented with an ENUM URI scheme rather than a tel URL
scheme... then you are already well outside ENUM's problem space, and you
might as well be using LDAP URIs instead. In what context do you imagine
that that the ENUM URI would be used? What agent or machine will generate
ENUM URIs, and for what purpose? The use of telephone numbers as a component
of this opaque pointer is probably totally superfluous.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Thu, 14 Nov 2002 22:56:53 +0000

Hi Folks,
>I had thought this thread had relocated to iptel, but, a response inline.

To which I reply:
Sorry - didn't realise this - last posts on this were on this list so
must have missed the ones on ipTEL.

>>  Subject: "enum:" URI comments
Sorry for the misspelt name - didn't stop the spell checker on this one.

>tel URL would do nicely, I think.

<IPTEL aside>
That decides the destination for 2806bis - it has to obsolete 2806 to bring
in MANDATORY behaviour as that was NOT in 2806, and that means it's Proposed
as the required behaviour is radically different.

RFCs aside, you can't change existing tel: clients by fiat (or for free :).
</IPTEL aside>

>LDAP?).

(more on "the ENUM problem next")
So you suggest that I need an LDAP client to de-reference an opaque pointer?

>ENUM is a technology for translating telephone numbers into URIs -
>might as well be using LDAP URIs instead.

I agree that this is what the ENUM lookup is all about. As you put it, to
"de-reference" a phone number to a set of communications records.

If I, as a publisher of information (say, on a web page, or wherever), want
to ensure that the READERS of that page check ENUM, how do I do it?
The reader doesn't have enough information to know that they MUST check.
The sender/publisher does. Yes, if I wanted to store the information inside
an LDAP server instead of in the ENUM golden tree, and to force clients to
retrieve it from LDAP rather than DNS, then I could use LDAP URIs.

Are you seriously suggesting that we dump ENUM and go over to LDAP?

>In what context do you imagine

How will it be used? - on my web page (created using BBEdit on my TiBook
and uploaded to the web server using FTP) for a start.
Purpose? - to indicate where to go to find my contact info, WITHOUT requiring
an LDAP client (and opening pinholes to support this protocol) on the receiving
end.

Using telephone numbers as a tag is superfluous if one is NOT using ENUM DNS
lookups, I guess. They are the fundamental key to ENUM, hence they must be the
value of any "check ENUM" URI, seems to me.

all the best,
   Lawrence