[Iptel] RE: [Enum] FW: draft-enum-teluri-e212-00.txt

["Richard Shockey" <[e-mail]>]

Ed the answer to your question in this draft is. 

A., Yes these parameters need to be registered according to the new TEL
parameter registry.

B. Do you intend to create a specific ENUM service associated with just
these paramaters.



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Telephony Working Group of the IETF.

	Title		: The Internet Assigned Number Authority (IANA) tel
Uniform Resource Identifier (URI) Parameter Registry
	Author(s)	: C. Jennings, V. Gurbani
	Filename	: draft-ietf-iptel-tel-reg-04.txt
	Pages		: 8
	Date		: 2006-12-8
	
This document creates an Internet Assigned Number Authority (IANA)
   registry for tel Uniform Resource Identifier (URI) parameters and
   their values.  It populates the registry with the parameters defined
   in the tel URI specification, along with the parameters in tel URI
   extensions defined for number portability and trunk groups.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-04.txt




> -----Original Message-----
> From: Richard Shockey [mailto:[e-mail]]
> Sent: Sunday, February 18, 2007 10:04 AM
> To: 'IETF ENUM WG'
> Subject: [Enum] FW: draft-enum-teluri-e212-00.txt
> 
> 
> FYI  this should be on the ID list early next week.
> 
> >
> > INTERNET-DRAFT                                            Edward Lewis
> > February 18, 2007                                         NeuStar, Inc.
> >
> >                      E.212 Parameters for the "tel" URI
> >                         draft-enum-teluri-e212-00.txt
> >
> > By submitting this Internet-Draft, each author represents that any
> > applicable patent or other IPR claims of which he or she is aware have
> > been or will be disclosed, and any of which he or she becomes aware will
> > be disclosed, in accordance with Section 6 of BCP 79.
> >
> > Internet-Drafts are working documents of the Internet Engineering Task
> > Force (IETF), its areas, and its working groups. Note that other groups
> > may also distribute working documents as Internet-Drafts.
> >
> > Internet-Drafts are draft documents valid for a maximum of six months
> and
> > may be updated, replaced, or obsoleted by other documents at any time.
> It
> > is inappropriate to use Internet-Drafts as reference material or to cite
> > them other than as "work in progress."
> >
> > The list of current Internet-Drafts can be accessed at
> >       http://www.ietf.org/1id-abstracts.html
> >
> > The list of Internet-Draft Shadow Directories can be accessed at
> >       http://www.ietf.org/shadow.html
> >
> > Discussion of this document should include the following list address:
> >       Provisioning Extensions in Peering Registries for Multimedia
> >       INTerconnection <[e-mail]>
> >
> > Abstract
> >
> > Parameters are defined in the "tel" Uniform Resource Identifier (URI)
> > to carry ITU E.212-related information.
> >
> > 1 Introduction
> >
> > Three parameters are defined for the tel URI [RFC3966] to permit
> > storage of E.212 [ITUE212] data.  E.212 data has three components,
> > the Mobile Country Code (MCC), the Mobile Network Code (MNC), and the
> > Mobile Subscriber Identification Number (MSIN).  Collectively, these
> > form the Internation Mobile Subscriber Identity.
> >
> > To store an IMSI, and therefore all three components, just one
> > parameter would be needed if not for concern over exposing the MSIN
> > in a public database like DNS.  There is a need to publically view the
> > MCC and MNC numbers though, so individual parameters are defined for
> > those values.
> >
> > The parameter for the entire IMSI will be "imsi", the parameter for
> > the MCC will be "mcc" and the parameter for the MNC will be "mnc."
> > In the parlance of RFC 4694 [RFC4694], these parameters are suitable
> > for placement in static content.
> >
> > 2 Terminology
> >
> > The key words "MUST," "SHOULD," and "MAY" in this document are to be
> > interpreted as described in RFC 2119 [RFC2119].
> >
> > 3 Formal Syntax
> >
> > The following syntax specification uses the Augmented Backus-Naur
> > Form (ABNF) as described in RFC 4234 [RFC4234] and defines the three
> > parameters, imsi, mcc, and mnc by extending the "parameter" production
> > rule of the "tel" URI defined in [RFC3966].
> >
> > parameter               = / imsi / mcc / mnc
> > imsi                    = ";imsi=" imsi-digits
> > mcc                     = ";mcc=" 3(DIGIT)
> > mnc                     = ";mnc=" (2(DIGIT) / 3(DIGIT))
> > imsi-digits             = (upto) 15(DIGIT) ; ed.note, fix this
> >
> > 4 Normative Rules
> >
> > If the imsi parameter is in use, all three values are expected to be
> > present.  Rules for the use of the parameter's value are contained
> > in the ITU document defining the IMSI.
> >
> > The other two parameters, mcc and mnc are used in tandem to identify
> > the network serving the telephone number.
> >
> > 5 Examples
> >
> > For a telephone number [phone], served on a network whose MCC
> > is 330, MNC is 110 and MSIN is 123456789, the two "tel" URI's that
> > might appear with these parameters are:
> >
> >      tel:[phone];imsi=330110123456789
> >      tel:[phone];mcc=330;mnc=110
> >
> > 6 Security Considerations
> >
> > The one concern raised in this document is the potential concern over
> > the provacy required for the MSIN that appears in the IMSI.  If the
> > IMSC parameter is used, the operator must understand the exposure that
> > may be had by the data.  The full IMSI ought to be restricted to
> > situations in which the exposure of the MSIN is acceptable.
> >
> > To alleviate this concern, the MCC and MNC parameters are defined, these
> > are expected to be what appears in a pubic or otherwise widely (or
> > externally) distributed environment.
> >
> > 7 IANA Considerations
> >
> > This document requires no IANA actions.
> >
> > 8 Internationalization Considerations
> >
> > There are no internationalization considerations in these parameters.
> > All data are numeric.
> >
> > 9 References
> >
> > 9.1 Normative
> >
> >     [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> >               Requirement Levels", BCP 14, RFC 2119, March 1997.
> >
> >     [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
> >               3966, December 2004.
> >
> >     [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
> >               Specifications: ABNF", RFC 4234, October 2005.
> >
> >     [ITUE212] ITU-T Recommendation E.212, "The International
> >               Identification Plan for Mobile Terminals and Mobile
> >               Users, " May 2004.
> >
> > 9.2 Informative
> >
> > (ed.note - do I need this, i.e., should it be mentioned in IANA
> consid.?)
> >     [TELREG]  Jennings, C. and V. Gurbani, "The Internet Assigned
> Numbers
> >               Authority (IANA) tel Uniform Resource Identifier (URI)
> >               Parameter Registry", Work in Progress, May 2006.
> >
> > 10 Author's Address
> >     Edward Lewis
> >     NeuStar
> >     46000 Center Oak Plaza
> >     Sterling, VA
> >     20166, US
> >
> >     Phone: [phone]
> >     EMail: [e-mail]
> >
> >
> > Copies of IPR disclosures made to the IETF Secretariat and any
> > assurances of licenses to be made available, or the result of an
> > attempt made to obtain a general license or permission for the use of
> > such proprietary rights by implementers or users of this
> > specification can be obtained from the IETF on-line IPR repository at
> > http://www.ietf.org/ipr.
> >
> > Copyright (C) The IETF Trust (2007).
> >
> > This document is subject to the rights, licenses and restrictions
> > contained in BCP 78, and except as set forth therein, the authors retain
> > all their rights.
> >
> > This document and the information contained herein are provided
> > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
> > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
> > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
> > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
> > WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
> > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
> > FOR A PARTICULAR PURPOSE.
> 
> 
> _______________________________________________
> enum mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/enum


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