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-iet
f-iptel-tel-reg-04.txt
> -----Original Message-----
> From: Richard Shockey [mailto:richard shockey.us]
> 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.iet
f.org/1id-abstracts.html
> >
> > The list of Internet-Draft Shadow Directories can
be accessed at
> > http://www.ietf.org/s
hadow.html
> >
> > Discussion of this document should include the
following list address:
> > Provisioning Extensions in Peering
Registries for Multimedia
> > INTerconnection <peppermintietf.org>
> >
> > 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 +1-571-555-1000, 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:+15715551000;imsi=330110123456789
> > tel:+15715551000;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: +1-571-434-5468
> > EMail: ed.lewisneustar.biz
> >
> >
> > 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
> enumietf.org
> https://w
ww1.ietf.org/mailman/listinfo/enum
_______________________________________________
Iptel mailing list
Iptelietf.org
https://
www1.ietf.org/mailman/listinfo/iptel
|
