Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows

Adrian Georgescu <ag@ag-projects.com> Tue, 07 February 2006 18:42 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Xnj-0004TD-6W; Tue, 07 Feb 2006 13:42:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Xn3-0004DP-L6; Tue, 07 Feb 2006 13:42:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19338; Tue, 7 Feb 2006 13:40:03 -0500 (EST)
Received: from ws1.dns-hosting.info ([81.23.228.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Xz2-0002J9-0j; Tue, 07 Feb 2006 13:54:36 -0500
Received: from [192.168.0.6] (mit.xs4all.nl [213.84.95.205]) (authenticated bits=0) by ws1.dns-hosting.info (8.13.5/8.13.5/Debian-3) with ESMTP id k17IfS1s009647 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 7 Feb 2006 19:41:30 +0100
In-Reply-To: <DE175C3426C51144B22109E3346CFFA42177409C@S75202E004049.sbms.sbc.com>
References: <DE175C3426C51144B22109E3346CFFA42177409C@S75202E004049.sbms.sbc.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Message-Id: <3DB884D5-3577-46B4-894F-658007636BA6@ag-projects.com>
From: Adrian Georgescu <ag@ag-projects.com>
Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows
Date: Tue, 07 Feb 2006 19:41:27 +0100
To: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 1.3 (+)
X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1
Cc: enum@ietf.org, speermint@ietf.org, Tony Rutkowski <trutkowski@verisign.com>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1972083551=="
Sender: enum-bounces@ietf.org
Errors-To: enum-bounces@ietf.org

Matt,

May I refine your logic? The best description should be:

I can change my telephone number whenever I change my operator. But  
as long as I can control my own SIP URI ag@ag-projects.com I can map  
my URI from  ag@provider1.com to ag@provider2.com and people can  
reach me at my own URI regardless of operator I am using for the  
voice/whatever service.

The main identity is the SIP URI, is not anymore the telephone  
number. The telephone number is just another attribute of a SIP URI.  
I can have one or more telephone numbers pointing to the same URI.  
The opposite is impossible to realize due to scarcity, regulatory  
issues and geographic nature of telephone numbers.

Regards,
Adrian


On Feb 7, 2006, at 7:20 PM, Stafford, Matthew wrote:

> Tony- The E.164 space is a many-encumbered thing. No argument there.
>
> All the same, I see two benefits of E.164 numbers: although *some*  
> mobile devices have QWERTY keyboards, many of them still don't. IMO  
> a telephone number is far and away the easiest thing to punch into  
> a cellphone keypad. That's the first one. The second one is  
> (essentially) number portability. My SIP URI can change from  
> sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. As  
> long as my phone number stays the same, it can be used to obtain my  
> current SIP URI.
>
> Best,
> Matt
>
> -----Original Message-----
> From: Tony Rutkowski [mailto:trutkowski@verisign.com]
> Sent: Sunday, February 05, 2006 10:42 AM
> To: lconroy; Stafford, Matthew; Otmar Lendl
> Cc: enum@ietf.org; speermint@ietf.org
> Subject: 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
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum

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