idnits 2.17.1
draft-goix-appsawg-enum-sn-service-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 11, 2012) is 4306 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-18) exists of
draft-ietf-appsawg-webfinger-00
Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 appsawg L. Goix
3 Internet-Draft Telecom Italia
4 Intended status: Standards Track K. Li
5 Expires: January 12, 2013 Huawei Technologies
6 July 11, 2012
8 ENUM Service Registration for Social Networking (SN) Services
9 draft-goix-appsawg-enum-sn-service-02
11 Abstract
13 This document registers a Telephone Number Mapping (ENUM) service for
14 Social Networking (SN). Specifically, this document focuses on
15 provisioning 'acct:' URIs (Uniform Resource Identifiers) in ENUM.
17 Status of this Memo
19 This Internet-Draft is submitted in full conformance with the
20 provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF). Note that other groups may also distribute
24 working documents as Internet-Drafts. The list of current Internet-
25 Drafts is at http://datatracker.ietf.org/drafts/current/.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 This Internet-Draft will expire on January 12, 2013.
34 Copyright Notice
36 Copyright (c) 2012 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
52 1.1. Justification . . . . . . . . . . . . . . . . . . . . . . . . 3
53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
55 2. IANA Registration . . . . . . . . . . . . . . . . . . . . . . 3
57 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4
59 4. DNS Considerations . . . . . . . . . . . . . . . . . . . . . 5
61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
67 8. Change log (to be deleted before publication) . . . . . . . . 6
69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
70 9.1. Normative References . . . . . . . . . . . . . . . . . . . . 7
71 9.2. Informative References . . . . . . . . . . . . . . . . . . . 7
73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
75 1. Introduction
77 ENUM (E.164 Number Mapping, [RFC6116]) is a system that uses DNS
78 (Domain Name Service, [RFC1034]) to translate telephone numbers, such
79 as '+44 01632 960123', into URIs (Uniform Resource Identifiers,
80 [RFC3986], such as 'acct:user@example.com'. ENUM exists primarily to
81 facilitate the interconnection of systems that rely on telephone
82 numbers with those that use URIs to identify resources.
84 Social Networking (SN) services allow users to post and retrieve
85 activities (e.g. status updates or media uploads) and related
86 replies. [I-D.saintandre-acct-uri] is proposing a generic URI to
87 identify an SN service account for a particular resource: the 'acct:'
88 URI scheme.
90 This document registers an enumservice for advertising account
91 information associated with an E.164 number.
93 1.1. Justification
95 The requirement to map an SN account with an E.164 number is from the
96 Open Mobile Alliance (OMA) Social Network Web Enabler Release
97 [OMA-SNeW-ER].
99 In Mobile networks, users are traditionally identified through a
100 Mobile Subscriber ISDN (MSISDN) number. In order to provide SN
101 functionality to mobile subscribers identified by their MSISDN, a
102 mapping is needed to identify a corresponding SN account and
103 provider.
105 1.2. Terminology
107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
109 document are to be interpreted as described in [RFC2119].
111 2. IANA Registration
113 As defined in [RFC6117], the following is a template covering
114 information needed for the registration of the enumservice specified
115 in this document:
117
118 Application-Based, Common
119 sn
120 acct
121
122
123 This Enumservice indicates that the resource
124 can be addressed by the associated URI using
125 SN protocols, including
126
127 to discover additional information.
128
129
130
131 See .
132
133 COMMON
134
135 This document.
136
137
138
139
140
142
143
144 Laurent-Walter Goix
145 Telecom Italia
146 mailto:laurentwalter.goix@telecomitalia.it
147 2012-07-10
148
149
151 3. Examples
153 The following is an example of the use of the enumservice registered
154 by this document in a NAPTR resource record for phone number +44
155 01632 960123.
157 $ORIGIN 3.2.1.0.6.9.2.3.6.1.0.4.4.e164.arpa.
159 IN NAPTR 10 100 "u" "E2U+sn" "!^.*$!acct:john.doe@example.com!" .
161 4. DNS Considerations
163 If no "E2U+sn" NAPTR record exist for the requested number, the
164 resolution process over issuing ENUM queries may be recursively
165 performed over E.164 numbers identified by other NAPTR records for
166 the requested number pointing to "tel" URIs [RFC3966]. Whilst this
167 process is useful to support, amongst others, number portability as
168 per [RFC4769], Section 4, this may also create potential loops in
169 this resolution process. As such ENUM clients performing such ENUM
170 queries over "tel" URIs to identify "acct" URIs SHOULD understand the
171 "enumdi" indicator defined in [RFC4759]. In particular, if the
172 result of the query does not include "E2U+sn" NAPTR records, and
173 includes a NAPTR resource record containing a "tel" URI that has the
174 same E.164 number, or a "tel" URI with the "enumdi" parameter set,
175 that client SHOULD NOT perform subsequent ENUM queries over such
176 numbers and SHOULD consider that the original requested number cannot
177 be mapped.
179 Furthermore the client MAY stop performing subsequent ENUM queries
180 after the fifth recursive query as suggested in [RFC6116] section
181 5.2.1.
183 5. Security Considerations
185 DNS, as used by ENUM, is a global, distributed database. Should
186 implementers of this specification use e164.arpa or any other
187 publicly available domain as the tree for maintaining PSTN
188 Enumservice data, this information would be visible to anyone
189 anonymously.
191 As noted earlier, carriers, service providers, and other users may
192 choose not to publish such information in the public e164.arpa tree.
193 They may instead simply publish this in an internal ENUM
194 infrastructure that is only able to be queried by trusted elements of
195 their network, thus limiting threats.
197 Per se, this enumservice does not introduce specific security
198 considerations beyond [RFC6116], section 7. However, it has to be
199 acknowledged that the proposed Enumservice could lead to the
200 discovery or disclosure of Personally Identifiable Information (PII)
201 if used in combination with the WebFinger protocol. Please see
202 [I-D.ietf-appsawg-webfinger], section 10 for additional information
203 regarding WebFinger security to avoid unwanted disclosure of
204 information.
206 Similar security concerns are associated with potential attacks
207 against an underlying Social Networking system. Unlike a traditional
208 telephone number, and as per the indirect nature of SN communication
209 (typically through an intermediary network element), the resource
210 identified by an 'acct:' URI may not be subject to direct
211 communication with other peers. However (e.g. in case of private
212 message exchange) it may require that peers provide cryptographic
213 credentials for authentication and authorization before messages are
214 exchanged. For this reason, SN protocols should have a number of
215 security requirements that call for authentication, integrity and
216 confidentiality properties, and similar measures to prevent such
217 attacks.
219 6. IANA Considerations
221 This document requests the IANA registration of the Enumservice with
222 Type "sn" according to the definitions in this document, [RFC6116]
223 and [RFC6117].
225 Details of the registration are given in Section 2.
227 7. Acknowledgements
229 The authors would like to thank Gonzalo Salgueiro, Paul Jones,
230 Lawrence Conroy, and Enrico Marocco for their valuable feedback to
231 improve this document.
233 8. Change log (to be deleted before publication)
235 -02 Draft
237 * Updated references to acct: URI I-D and OMA specifications
239 * Added changelog section
241 -01 Draft
243 * Made changes to example phone numbers
245 * Updated security and DNS considerations
247 * Fixed IANA registration template
249 * Added acknowledgment section
251 9. References
252 9.1. Normative References
254 [I-D.ietf-appsawg-webfinger]
255 Jones, P., Salgueiro, G., and J. Smarr, "WebFinger",
256 draft-ietf-appsawg-webfinger-00 (work in progress),
257 July 2012.
259 [I-D.saintandre-acct-uri]
260 Saint-Andre, P., "The 'acct' URI Scheme",
261 draft-saintandre-acct-uri-01 (work in progress),
262 July 2012.
264 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
265 STD 13, RFC 1034, November 1987.
267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
268 Requirement Levels", BCP 14, RFC 2119, March 1997.
270 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
271 RFC 3966, December 2004.
273 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
274 Resource Identifier (URI): Generic Syntax", STD 66,
275 RFC 3986, January 2005.
277 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip
278 Indicator Parameter for the "tel" URI", RFC 4759,
279 December 2006.
281 [RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an
282 Enumservice Containing Public Switched Telephone Network
283 (PSTN) Signaling Information", RFC 4769, November 2006.
285 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
286 Uniform Resource Identifiers (URI) Dynamic Delegation
287 Discovery System (DDDS) Application (ENUM)", RFC 6116,
288 March 2011.
290 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
291 Registration of Enumservices: Guide, Template, and IANA
292 Considerations", RFC 6117, March 2011.
294 9.2. Informative References
296 [OMA-SNeW-ER]
297 Open Mobile Alliance, "Social Network Web Enabler", OMA-
298 ER-SNeW-V1_0 20120702-D, July 2012.
300 Authors' Addresses
302 Laurent-Walter Goix
303 Telecom Italia
304 P.za Einaudi, 8
305 Milano 20124
306 Italy
308 Email: laurentwalter.goix@telecomitalia.it
310 Kepeng Li
311 Huawei Technologies
312 Huawei Base, Bantian, Longgang District
313 Shenzhen, Guangdong 518129
314 P. R. China
316 Phone: +86-755-28974289
317 Email: likepeng@huawei.com