Subject: [Enum] enum uri considered harmful?

From: Lawrence Conroy <[email-masked]>
Date: Tue, 30 Jul 2002 16:54:58 +0100

Hi Folks,
  hope you have all recovered from the meeting/journeys.

I was told that, in answer to the enum: URI proposal, a
counter-proposal to change the enum: URI into a tel:
parameter was discussed in YOK.

Well...Unless someone can give answers to these points,
I am not happy with this - IMHO enum: is not the same as
tel: ; enum=yes.

I'd appreciate your comments.

all the best,
    Lawrence

-----------------------------
There are a number of tel: URL clients that exist and do NOT
support this 'enum' parameter (it isn't even written yet :).

The URL/parameter is intended to be mandatory - if the client
cannot or is unwilling to do an ENUM lookup, the URI (or URL
containing the parameter) *CANNOT be resolved*.

If we are applying this *retrospectively* to all tel: clients,
then this implies that all existing tel: clients are non-compliant,
as they ignore unknown parameters (as per. RFC2806).

With James' tel: URL (RN & CIC) parameters, this is not a problem,
as these will only be used within the infrastructure - if I get a tel:
URL with a RN parameter on my home PC, then I can ignore it - it is not
intended for me. All tel: clients used within the Operator infrastructure
will be new or updated ones and so this is fine.

However...
An enum: URI (or a tel: URL with an enum parameter) *will* be encountered
out "in the wild" - not just within the Operator infrastructure. They
could well exist on web pages, inside e-mail I receive, or within the
"public" ENUM space.

There will be tel: clients that have not been updated. If they receive
a "standard" tel: URL, then there's no problem - they will work the
same as ever. This may or may not include an ENUM lookup (it's likely
that there will be no such lookup with existing clients).

However, now we introduce the enum parameter. It will be unknown to
the tel: client, so that existing clients will just ignore it (according
to RFC2806). Result - we have no way to say "do an enum lookup on this
number, or reject the URI".

If we introduce a new enum: URI specifically to do the ENUM lookup,
then we will be clear - either there is an enum: client that works
as defined, or the URI is rejected. It will not be passed to a tel:
client - that is now focused on making phone calls over the PSTN
(or networks that use E.164 numbers natively :).

Thus, from a practical perspective, I'm against the change from an
enum: URI to a tel: parameter, as it breaks with existing clients.

I'm happy to make the es parameter and the svc parameter common.
This is a GOOD IDEA, ->as long as<- we can define all of the services
together, *and* know what to do when someone puts in <tel:+1234456;es=srs>
or some other enumservice that can't be handled by the PSTN.

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

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

---

From: Richard Shockey <[email-masked]>
Date: Tue, 30 Jul 2002 16:50:20 -0400

>I'd appreciate your comments.

First you note what clients would the additon of a enum=yes parameter break?

As the problem statement is defined .. folks want to pass a URI that 
explicitly tells the application processing the URI to preform a ENUM query 
on the TN ... if that is the case the question in Yokohama was ..why go 
through the bother of developing a new URI when you can just add a new flag 
to the existing tel URL?

why does this need to be MUST

>that there will be no such lookup with existing clients).

i'm having a serious grok problem here ... very little is deployed out 
there now ..what are you suggesting is broken

>or some other enumservice that can't be handled by the PSTN.

well the idea of a SRS service is an interesting idea ...I'm still 
interested to see what the protocol is that delivers the service.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza   Bldg 10    Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
<http://shockey.us > ; <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Dave Crocker <[email-masked]>
Date: Tue, 30 Jul 2002 15:39:27 -0700

>explicitly tells the application processing the URI to preform a ENUM 
>query on the TN ... if that is the case the question in Yokohama was ..why 
>go through the bother of developing a new URI when you can just add a new 
>flag to the existing tel URL?

Folks,

Part of what makes this sort of discussion so difficult is the history of 
URIs.  They have very different flavors.  http: and ftp: refer to 
"protocols".  mailto: refers to a service and says nothing at all about 
what protocol to use.

why not just have a URI like "domain:foo.bar;proto=http"?  It is just as 
easy, no?  If we are not careful, that is what enum: will be like.

Enum is neither a service nor a protocol.  By design, it is a component to 
a range of different services.  Specifically, it is a lookup mechanism that 
will be used as part of services that use e.164 numbers.  That's the same 
kind of description as we would give to domain names.  We would not give 
that sort of description to any of the popular URIs around today.

Note that tel: is defined along with modem: and fax: URIs.  They all have a 
common syntax, for the e.164 part.  So the string: preface really is 
describing specific user services (or protocols, I'm not sure which).  They 
are definitely specifying far more than just a number format.  They are 
saying something quite semantic about what the number is to be used for.

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: Richard Shockey <[email-masked]>
Date: Wed, 31 Jul 2002 10:45:31 -0400

>a range of different services.  Specifically, it is a lookup mechanism 
>that will be used as part of services that use e.164 numbers.  That's the 
>same kind of description as we would give to domain names.  We would not 
>give that sort of description to any of the popular URIs around today.
>
>Note that tel: is defined along with modem: and fax: URIs.  They all have 
>a common syntax, for the e.164 part.  So the string: preface really is 
>describing specific user services (or protocols, I'm not sure 
>which).  They are definitely specifying far more than just a number 
>format.  They are saying something quite semantic about what the number is 
>to be used for.

Ok Dave ..but we now have flags for a tel URL ( a draft written by my 
colleague James Yu) that indicate  the number has received a database dip 
for Number Portability the true LRN and a dip indicator... The concept 
behind ;ENUM=YES strikes me a similar.  The flag tells the application here 
is a e164 number it can be resolved in e164.arpa, go do that.

I'm open minded here ... given the problem statement what would be your 
solution?