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
- [Enum] a suggestion re: using flags to distinguis… Stafford, Matthew
- Re: [Enum] a suggestion re: using flags to distin… lconroy
- Re: [Enum] a suggestion re: using flags to distin… Richard Shockey
- Re: [Enum] a suggestion re: using flags to distin… Tony Rutkowski
- RE: [Speermint] Re: [Enum] a suggestion re: using… Henry Sinnreich
- [Enum] ENUM Test Specificatiobns Tony Rutkowski
- Re: [Enum] ENUM Test Specificatiobns Jim Reid
- Re: [Enum] ENUM Test Specificatiobns Adrian Georgescu
- Re: [Enum] ENUM Test Specificatiobns lconroy
- RE: [Enum] a suggestion re: using flags to distin… Stafford, Matthew
- RE: [Enum] a suggestion re: using flags to distin… Stafford, Matthew
- RE: [Enum] a suggestion re: using flags to distin… Stafford, Matthew
- Re: [Enum] a suggestion re: using flags to distin… Richard Shockey
- Re: [Enum] a suggestion re: using flags to distin… Adrian Georgescu
- Re: [Enum] a suggestion re: using flags to distin… Stastny Richard
- Re: [Enum] a suggestion re: using flags to distin… Richard Shockey
- RE: [Enum] a suggestion re: using flags to distin… Stafford, Matthew
- Re: [Speermint] Re: [Enum] a suggestion re: using… Dean Willis
- Re: [Speermint] RE: [Enum] a suggestion re: using… Duane