RE: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish post-ENUM signaling f lows

Right now, however, phone numbers are a little like democracy - "the
worst system imaginable except for all others"
P2P folks don't seem serious about interoperability  (look at IM) and
only TNs provide reachability from the PSTN.

Penn
(sorry, Henry, couldn't resist)

-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On
Behalf Of Henry Sinnreich
Sent: Monday, February 06, 2006 10:33 AM
To: 'Tony Rutkowski'; 'lconroy'; 'Stafford, Matthew'; 'Otmar Lendl'
Cc: enum@ietf.org; speermint@ietf.org
Subject: RE: [Speermint] Re: [Enum] a suggestion re: using flags
todistinguish post-ENUM signaling f lows

The information provided by Tony Rutkowski are a welcome reminder that
phone
numbers are not only a crippled addressing system but a huge trap with
legacy telecom regulatory issues and big legal staffing costs.

Let's use the Internet and the DNS for what they were designed: URIs

The other alternative are the name spaces in P2P systems.

Sincere apology to all my friends working on ENUM: 
Keep it within strict bounds, simple and use with caution.

Thanks, Henry

-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On
Behalf Of Tony Rutkowski
Sent: Sunday, February 05, 2006 10:42 AM
To: lconroy; Stafford, Matthew; Otmar Lendl
Cc: enum@ietf.org; speermint@ietf.org
Subject: [Speermint] Re: [Enum] a suggestion re: using flags to
distinguish
post-ENUM signaling f lows

Hi Lawrence,

>The first is the process issue - what group (if any) coordinates
>between the different DDDS applications and their uses; this topic
...
>3761bis. It seems that your proposal is purely for Carrier/
Infrastructure/
>Private ENUM; in this case, changing 3761 has unintended consequences
>for Public/User ENUM applications.

These are great understatements.  The use of
E.164 identifiers, internationally and
domestically, is subject to more statutory,
regulatory, national security, and industry
practice requirements than any identifier
space in existence - not to mention well
established institutional jurisdiction.

The following list is a current tabulation
of E.164 resolver-directory capability
requirements, parsed into three categories,
currently in play in various industry NGN
forums.  The recently enacted EC Data
Retention Directive, and the U.S. Prevent
Cyberstalking law, add further complexity
to the mix. ;-)

best,
--tony

>basic resolver capability
>
>supplementary capability
>         Number Portability
>         Priority Access
>         Roaming
>         Quality of Service
>         Directory Assistance
>         CallerID
>         Disability Assistance
>         Language preference
>         Personal emergency (E112/911)
>         Public emergency alerts
>         Law enforcement assistance
>         DoNotCall
>         Payment Methods
>         Intercarrier Compensation
>         Profile Management
>         Presence
>         Availability
>         Location
>         Push Management
>         Digital Rights Management
>         Device Management
>         Authentication Credentials
>         Information verification level
>
>protocol feature
>         Authentication
>         Auditing
>         Multiple Syntax Support
>         Mutiple Language Support
>         Extensibility and Localisation Mechanisms

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum