RE: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows
"Stafford, Matthew" <matthew.stafford@cingular.com> Tue, 07 February 2006 18:20 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 1F6XSN-0003aX-WB; Tue, 07 Feb 2006 13:20:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6XSK-0003Yt-Hg; Tue, 07 Feb 2006 13:20:50 -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 NAA17836; Tue, 7 Feb 2006 13:18:57 -0500 (EST)
Received: from extmail09.cingular.com ([170.35.225.24] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Xeb-0001at-Aj; Tue, 07 Feb 2006 13:33:30 -0500
Received: from ([10.3.188.52]) by extmail09.cingular.com with ESMTP id KP-VYGZ6.56947271; Tue, 07 Feb 2006 13:20:13 -0500
Received: by s75202e004001.tdc.cingular.net with Internet Mail Service (5.5.2657.72) id <1FCBYTQ2>; Tue, 7 Feb 2006 12:23:48 -0600
Message-ID: <DE175C3426C51144B22109E3346CFFA42177409C@S75202E004049.sbms.sbc.com>
To: Tony Rutkowski <trutkowski@verisign.com>
Subject: RE: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows
Date: Tue, 07 Feb 2006 12:20:58 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
From: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc
Cc: enum@ietf.org, speermint@ietf.org
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="===============0385326954=="
Sender: enum-bounces@ietf.org
Errors-To: enum-bounces@ietf.org
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] 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