From szegedi at terena.org Wed May 16 11:38:57 2012 From: szegedi at terena.org (Peter Szegedi) Date: Wed, 16 May 2012 11:38:57 +0200 Subject: [enum-wg] NRENum.net service goes global, recognised as viable alternative to e164.arpa for academia Message-ID: <4FB375B1.2070304@terena.org> Dear ENUM WG participants, I'd like to kindly inform you about the latest progress of the TERENA's ENUM service for academia, called NRENum.net http://www.nrenum.net On 9 May 2012 the NRENum.net service participants agreed to change the service policy as follows: - As you may know, NRENum.net has been an ENUM service run by the National Research and Education Networks (NRENs) for trial purposes mainly targeting those countries where the Golden Tree (e164.arpa) is not operational yet. - Recently, it's turned out that (in some countries) the Golden Tree production service roll out is not progressing (due to various reasons), and it will definitely not reach out to academia, while the R&E community in Europe and beyond desperately needs a seamless and scalable dialling solution among different communication technologies. - Therefore TERENA service participants agreed to position NRENum.net as a valid alternative to the Golden Tree for academia. The number migration to the Golden Tree (where it is available) is recommended but not mandatory any more. NRENs can join the NRENum.net service whether or not the Golden Tree is available in their country. - In addition to this, NRENum.net has become a global service. The NREN of Argentina, Brazil and Australia joined the service during the last one and a half months and there are other candidates in both the Latin-American and Asia-Pacific regions. Read more in the TERENA news item at http://www.terena.org/news/3159/fullstory Kind regards, Peter -- ----------------------------- Project Development Officer TERENA Secretariat Singel 468D, 1017AW Amsterdam The Netherlands T: +31 20 530 4488 F: +31 20 530 4499 http://www.terena.org ----------------------------- From rick at openfortress.nl Wed May 16 13:23:54 2012 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 16 May 2012 11:23:54 +0000 Subject: [enum-wg] Why is there no "SMS center is here" ENUM record? Message-ID: <20120516112354.GA9659@newphantom.local> Hello, As far as I can tell, there is no ENUM record that says "please deliver SMS for this number at the SMS Centre at IP address 123:456::789" -- is there a reason for that? The SMS records that I've seen are in fact simulations of the SMS-sending intention over another protocol, and they are not easy. This requires the sender to either be able (and willing) to initiatie messaging using that simulation *instead* of SMS, so an SMS Centre should be able to translate the protocols. This is not likely to catch on as a general mechanism. What I am missing is a record that says "yeah sure, I'll take in SMS PDUs and will process them as my number user has seen fit to setup in the receiving messaging switch. This is much simpler, as it does not involve simulation of one protocol (SMS) over another (XMPP, email, SIMPLE) but just lets service providers map I/O channels with a generic messaging swith. This mechanism could unleash SMS to fixed numbers, thus widening the market for SMS. That could be a no-brainer for telecom operators to implement? Is this a new angle, or am I overlooking problems? Thanks, -Rick From jim at rfc1035.com Wed May 16 14:08:39 2012 From: jim at rfc1035.com (Jim Reid) Date: Wed, 16 May 2012 13:08:39 +0100 Subject: [enum-wg] Why is there no "SMS center is here" ENUM record? In-Reply-To: <20120516112354.GA9659@newphantom.local> References: <20120516112354.GA9659@newphantom.local> Message-ID: <61D6EFC2-C676-408E-A3A9-7D3675071E90@rfc1035.com> On 16 May 2012, at 12:23, Rick van Rein wrote: > As far as I can tell, there is no ENUM record that says > "please deliver SMS for this number at the SMS Centre > at IP address 123:456::789" -- is there a reason for that? NAPTRs can point at just about anything that has a URI scheme. So does RFC5724 "URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS) not meet your need? Admittedly, this talks about delivery to phone numbers rather than IP addresses. From lwc at roke.co.uk Wed May 16 15:52:44 2012 From: lwc at roke.co.uk (Lawrence Conroy) Date: Wed, 16 May 2012 14:52:44 +0100 Subject: [enum-wg] Why is there no "SMS center is here" ENUM record? In-Reply-To: <61D6EFC2-C676-408E-A3A9-7D3675071E90@rfc1035.com> References: <20120516112354.GA9659@newphantom.local> <61D6EFC2-C676-408E-A3A9-7D3675071E90@rfc1035.com> Message-ID: <92DC38B2-78FB-4E74-AE2F-5C84E29BE931@roke.co.uk> On 16 May 2012, at 13:08, Jim Reid wrote: > On 16 May 2012, at 12:23, Rick van Rein wrote: > >> As far as I can tell, there is no ENUM record that says >> "please deliver SMS for this number at the SMS Centre >> at IP address 123:456::789" -- is there a reason for that? > > NAPTRs can point at just about anything that has a URI scheme. So does RFC5724 "URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS) not meet your need? Admittedly, this talks about delivery to phone numbers rather than IP addresses. To which I add: You seem to be describing any set of telephone numbers from the perspective of the SMSC. So ... 1. OK -- as Jim says, with a NAPTR one has a URI -- let's say that has an IP address in that URI. So, there's something listening at a given IP address. You'll also need to specify the port (relatively easy, and the NEW spec may even spell out a default port). But ... What protocol? You would need to spell out the protocol for a start, in detail. ++ 2. Who controls provisioning records into the particular ENUM domains associated with devices served by the SMSC? 3. Is a carrier running an SMSC really going to provision thousands/millions of such records into the ENUM-domain-space associated with its customers' telephone numbers? all the best, Lawrence Conroy ++ As an unimportant aside... strictly the IETF sms NAPTR spec (rfc4355) would be updated, as it doesn't mention the sms: URI [or whatever URI scheme you're going to define for entities that handle your SMSC protocol]. IIUC, that's just a case of writing an sms:sms template (as shown in rfc6117/rfc6118) and dropping that into the IETF system (where, I believe, Bernie will check it and then nudge IANA to publish it). Biggest pain would be spec'ing the URI scheme for entities handling the SMSC protocol (and making sure that was specified correctly). From rick at openfortress.nl Thu May 17 16:29:07 2012 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 17 May 2012 14:29:07 +0000 Subject: [enum-wg] delivering SMS beyond mobile phones In-Reply-To: <829C6CA0-F66E-4697-A9DB-BAD6CE3A0885@rfc1035.com> References: <20120516112354.GA9659@newphantom.local> <61D6EFC2-C676-408E-A3A9-7D3675071E90@rfc1035.com> <20120517090001.GA14363@newphantom.local> <829C6CA0-F66E-4697-A9DB-BAD6CE3A0885@rfc1035.com> Message-ID: <20120517142907.GA15968@newphantom.local> Hello, Thanks for the responses. My question is thoroughtly answered: My idea for accepting SMS on an Internet server was of course technically inspired; I already was a bit weary about acceptance in the IETF and from the sound of it, this is not going to be easy. More importantly, I had thought about the opportune delivery of SMS to a broader network (creating money for the telco's from which they were sent) but not about the ability to also bypass the same SMS-sending mechanism. This does indeed give a strong incentive to telco's to not support it. Given that mobile users are discovering chat (although they still accept lock-in XMPP providers like FaceBook) I think we are already moving away from the problems of lock-in messaging. With that in mind, it may actually be safe to simply ignore SMS' closed setup. (It may even be a reason for countries or markets to demand network neutrality!) Cheers, -Rick