Re: [Enum] Re: URI Portability

[Patrik Fältström <[e-mail]>]

There is absolutely no difference between SIP and email and other  
services. Either the end user get a domain name he own (as a  
registrant) and ask the provider of whatever services he buy to use  
that domain for the services. Or, he uses the default domain the  
provider has, but that domain name belongs to the service provider,  
and is because of that not portable.

So, domain names are portable, you have to (only) make sure you have  
one.

     paf

On 8 feb 2006, at 16.00, Stastny Richard wrote:

> Jim Baskin sent a private comment on URI Portability to Matt and me,
> but had no objections to comment this on the list, which I do, because
> I consider this relevant:
>
>> Number portability and SIP URI portability may sound like
>> similar concepts, but there is at least one big difference.
>> Moving sip:[e-mail] from one provider to another
>> may be really simple, assuming that you own stastny.com and
>> you have control over its nameserver.
>
> Agreed
>
>> However, if you are
>> a SIP customer of acme-sip.com (e.g., sip:[e-mail]),
>> it isn't a strictly technical issue.  It is not likely that
>> the owners of acme-sip.com would want their company name or
>> its domain used by someone who has a different SIP service
>> provider.  The same issue is why I don't ever expect to see
>> email address portability for [e-mail] or
>> [e-mail].
>
> I agree in principal, but we have to distinguish between to cases  
> here:
>
>
> 1. sip:[e-mail] can be compared your company extension  
> with DDI
> I have eg [phone] as office number, where 32 is my extension.
> It is obvious that if I change company I cannot take (port) this  
> number with
> me, because [phone] belongs to OeFEG. Same with acme-sip.com
> [phone] is public, the rest is private. In the PSTN there exists
> a clear distinction between what a public telephone service is and
> what is private (corporate)
>
> 2. On the Internet this distincion is not existing, but of course
> one could be found:
>
> acme-sip.com is not providing a service for the public
> yahoo.com and aol.com is.
>
> A bored regulator could come to the conclusion at some time to
> foster competition and require URI portability vor public
> SIP URIs.
>
> First every SIP service provider would rant that this is
> impossible, expensive, whatever, but we had this also on the
> PSTN.
>
> Of course this can be implemented in the same way as
> it was implemented in the PSTN, with onward routing and/or
> redirect, with the same drawback: the donor is always involved
>
> Next step would be to standardise a DNS lookup for sip:[e-mail]
>
> in something like fred.at.yahoo.com to find the current URI.
> of course there are a lot of problems, such as a certified
> from information, but this can be solved.
>
>> E.164 telephone numbers, on the other hand, don't have service
>> provider trademark issues.  In addition, number portability,
>> if done with a database and originating or n-1 carrier dips,
>> takes the ported-from service provider completely out of call
>> processing for the ported number.  Of course, number portability
>> isn't "perfect" yet.  There are still regulatory limits on
>> what numbers can be ported where.
>
> SIP URI portability of course must work global, an this
> will delay or prevent the idea for some time ;-)
>
>> Oh yes, regarding Tony's statement, "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."
>> That may be exactly why E.164 telephone numbers have been used so
>> successfully as a nearly seamless identifier standard providing
>> worldwide telecommunications for longer than many IETF
>> participants can remember.
>
> True, at least as long as we do not have global reachability
> provided by a Public User Identity in the form of a SIP AoR.
>
> Richard
>
>> Jim Baskin
>
> =======================================
> Original messages:
>
> Richard-
> ===> What I want to have is SIP URI portability too, or in other  
> words: I ===> want to have my sip URI sip:[e-mail]
> ===> hosted by one provider and the possibility to port this to  
> another.
> No disagreement there. I guess I view these portability options as  
> complementary (i.e., both useful depending on individual preferences).
> Thanks for the document pointers.
> Matt
> -----Original Message-----
> From: Stastny Richard [mailto:[e-mail]  
> <mailto:[e-mail]> ]
> Sent: Tuesday, February 07, 2006 12:50 PM
> To: Stafford, Matthew
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Enum] a suggestion re: using flags to distinguish  
> post-ENUM signaling f lows
>
>> The second one is (essentially) number portability. My SIP URI can  
>> change from sip:[e-mail] to  
>> >sip:[e-mail]. As long as my phone number stays  
>> the same, it can be used to obtain my current SIP URI.
>
> What I want to have is SIP URI portability too, or in other words:  
> I want to have my sip URI sip:[e-mail]
> hosted by one provider and the possibility to port this to another.
>
> Especially if I am a company.
>
> For more information see the ECMA christmas wish-list presented  
> today at ETSI TISPAN:
> Technical Report TR/91
> Enterprise Communication in Next Generation Corporate Networks  
> (NGCN) involving Public Next Generation Networks (NGN)
> (December 2005)
> http://www.ecma-international.org/publications/files/ECMA-TR/ 
> TR-091.pdf <http://www.ecma-international.org/publications/files/ 
> ECMA-TR/TR-091.pdf>
>
> and also
> Technical Report TR/92
> Corporate Telecommunication Networks - Mobility for Enterprise  
> Communications
> (December 2005)
> http://www.ecma-international.org/publications/files/ECMA-TR/ 
> TR-092.pdf <http://www.ecma-international.org/publications/files/ 
> ECMA-TR/TR-092.pdf>
>
> The scenarios and requirements described in these two documents  
> will not
> be really easy to implement with NGNs ;-)
> Of course they want to have best of both sides: peering with each  
> other in all variants
> AND in addition to be connected to an NGN, just to be on the safe  
> side.
> One could also say: the overflow traffic is for the telcos (say max  
> 20%)
>
> Richard
> _______________________________
>
> Von: [e-mail] im Auftrag von Stafford, Matthew
> Gesendet: Di 07.02.2006 19:20
> An: Tony Rutkowski
> Cc: [e-mail]; [e-mail]
> Betreff: RE: [Enum] a suggestion re: using flags to distinguish  
> post-ENUM signaling f lows
>
> 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:[e-mail] to sip:[e-mail]. 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:[e-mail]  
> <mailto:[e-mail]> ]
> Sent: Sunday, February 05, 2006 10:42 AM
> To: lconroy; Stafford, Matthew; Otmar Lendl
> Cc: [e-mail]; [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/enum
>
>
> _______________________________________________
> enum mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/enum

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