200 likes | 337 Views
E.212 ENUMService Type Definition E.212 Parameters for the "tel" URI. Edward Lewis NeuStar IETF 68 ENUM WG meeting. Back-to-Back Items. draft-lewis-enum-enumservice-e212-00.txt To register "E2U+E212" as enumservice Indicates NAPTR has ITU E.212 infomation
E N D
E.212 ENUMService Type DefinitionE.212 Parameters for the "tel" URI Edward Lewis NeuStar IETF 68 ENUM WG meeting ed.lewis@neustar.biz
Back-to-Back Items • draft-lewis-enum-enumservice-e212-00.txt • To register "E2U+E212" as enumservice • Indicates NAPTR has ITU E.212 infomation • draft-lewis-enum-teluri-e212-00.txt • To define parameters in tel: for E.212 ed.lewis@neustar.biz
Plans for the two • Go over comments received so far, get more while here • Edit the documents in the coming week(s) post IETF68 • Submit again as directed (WG or not) ed.lewis@neustar.biz
E.212 for IETF'ers • E.212 is an ITU document/standard defining meta-data for a mobile-phone telephone number • MCC (Mobile Country Code) • MNC (Mobile Network Code) • MSIN (Mobile Subscriber Identification #) • IMSI (International Mobile Subscriber Identity) - the concatenation of the other 3 ed.lewis@neustar.biz
A diagram MCC MNC MSIN IMSI MCC - 3 digits MNC - 2 or 3 digits MSIN - up to 10 digits IMSI - up to 15 digits ed.lewis@neustar.biz
Why IETF documents? • This is about ENUM • Wanting to store the ITU-defined parameters in ENUM • This isn't so much about E.212, 'cept that that is the "payload" ed.lewis@neustar.biz
draft-lewis-enum-enumservice-e212-00.txt • First, it's a -00 individual, happy to make it a WG document • Fills in an ENUM service "application" • E2U+E212 means the NAPTR RR has a tel: URI (with extensions in the other draft) ed.lewis@neustar.biz
Comments on that one • Would like a good use case • Fair enough, the draft is minimal and am happy to add that. Still in the process of writing it. • Is it worth getting a non-SIP ENUM extension defined? • Suggestion to use an experimental (x-) but really want a "real" definition See next slide. ed.lewis@neustar.biz
Use case • With number porting, can't tell the carrier by the number alone • Knowing the receiving operator of a call could impact business decisions • In Softswitch draft "...interconnection only with trusted carriers" • For IM knowing the MCC+MNC can determine the receiving server name ed.lewis@neustar.biz
More comments • What about "aux-info:e212"? • Although workable, a few reservations • We/WG don't have other "aux-info's" in mind, I don't like to generalize from a single case • E.212 is subjectively significant enough to stand on its own, and is reliant on an external (ITU) definition • Linking in other (unknown) types would likely slow this process ed.lewis@neustar.biz
First doc question to WG • Should this be adopted as WG item? • What is missing from the application and supporting document? • Sub-note: I couldn't find a reliable "how to" to follow when submitting these drafts, so I "undercut" the submission draft-ietf-enum-enumservices-guide-03.txt ed.lewis@neustar.biz
draft-lewis-enum-teluri-e212-00.txt • This document defines parameters for the tel: URI to hold the E.212 data • In the spirit of RFC 4694, but for different data • Four parameters are defined, as per earlier slide (MCC, MNC, MSIN, IMSI) ed.lewis@neustar.biz
My goal • I am interested in retrieving the MCC and MNC for a telephone number via ENUM • The draft includes MSIN and IMSI parameters for completeness ed.lewis@neustar.biz
Comments • This draft ought to go to IPTEL • No response to that yet from me • What's E.212? • Should this draft explain it or just refer to the ITU document (now freely available)? • When I prepared the draft, I went for not including an explanation but can be convinced otherwise ed.lewis@neustar.biz
More comments • Need an illustrative use case • Working on that, went for brevity in the -00 • The ABNF is wrong • A few pointed this out, you are all right, I'll fix that • The URI is wrong • Sorry - sigh, I wrote the draft on an airplane and it shows ;) (Goes for the ABNF too.) ed.lewis@neustar.biz
Yet more comments • MCC+MNC xor IMSI? • Should the syntax require either both MCC and MNC be present or the IMSI be present? • My response is - that's the probable use case, but does this have to be encoded in the syntax rules? I prefer to let the syntax be freer than the use ed.lewis@neustar.biz
And more comments... • Isn't it unwise to have the IMSI, MSIN, and maybe even the MCC and MNC in a public database? • I'd agree with that, but the drafts are just providing a means to put this in ENUM and not saying that the data would be public • Not all DNS servers are on public networks ed.lewis@neustar.biz
Second doc questions • Should this be an ENUM WG doc or go ask IPTEL WG to adopt this? ed.lewis@neustar.biz
Well, I'm out of slides • Discussion? ed.lewis@neustar.biz