idnits 2.17.1 draft-ietf-enum-enumservice-sms-smpp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 611. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 672 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 85 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The abstract seems to indicate that this document updates RFC4355, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2008) is 5825 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) ** Obsolete normative reference: RFC 3761 (ref. '2') (Obsoleted by RFC 6116, RFC 6117) ** Obsolete normative reference: RFC 4395 (ref. '5') (Obsoleted by RFC 7595) == Outdated reference: A later version (-22) exists of draft-ietf-enum-enumservices-guide-08 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM Working Group J. Yu 3 Internet Draft NeuStar 4 Document: draft-ietf-enum-enumservice-sms-smpp-01.txt May 2008 5 Category: Standards Track 7 IANA Registrations of Enumservice 8 "sms:smpp" and URI Scheme "smpp" 9 draft-ietf-enum-enumservice-sms-smpp-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 7, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document updates RFC 4355 by registering a new enumservice 43 subtype "smpp" under the existing type "sms" using the URI scheme 44 "smpp" as per the IANA registration process defined in RFC 3761 and 45 draft-ietf-enum-enumservices-guide-07 and registers a new URI scheme 46 "smpp" according to the URI registration procedure in RFC 4395. 48 This enumservice subtype indicates that the remote resource 49 identified by the URI can receive short messages using the Short 50 Message Peer-to-Peer Protocol (SMPP). 52 Standards Track - Expires November 7, 2008 1 53 IANA Registrations for Enumservice May 2008 54 "sms:smpp" and URI Scheme "smpp" 56 Table of Contents 58 1. Conventions Used in this Document . . . . . . . . . . . . 2 59 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 2 60 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 63 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Security Considerations . . . . . . . . . . . . . . . . . 7 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 7 66 8.1 IANA Registration for Enumservice "sms:smpp" . . . . . . . 7 67 8.2 IANA Registration for URI Scheme "smpp" . . . . . . . . . 8 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 70 9.2 Informative References . . . . . . . . . . . . . . . . . . 10 72 1. Conventions Used in this Document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in BCP 14, RFC 2119 [1]. 78 2. Abbreviations 80 3GPP 3rd Generation Partnership Project 81 BNF Backus-Naur Form 82 DNS Domain Name System 83 GPRS General Packet Radio Service 84 GSM Global System for Mobile communications 85 GW Gateway 86 HLR Home Location Register 87 ID Identifier; Identity 88 IM Immediate Messaging; Instant Messaging 89 ITU-T International Telecommunication Union-Telecommunication 90 MNP Mobile Number Portability 91 MSC Mobile-services Switching Center 92 NAPTR Naming Authority Pointer 93 RR Resource Record 94 SC Service Center 95 SGSN Serving GPRS Support Node 96 SMPP Short Message Peer-to-Peer Protocol 97 SMS Short Message Service 98 SMS-GMSC Gateway MSC for SMS 99 SMS-IWMSC Interworking MSC for SMS 100 SMSC Short Message Service Center 101 SRV Service 102 SS7 Signaling System Number 7 103 URI Uniform Resource Identifier 104 VPN Virtual Private Network 106 Standards Track - Expires November 7, 2008 2 107 IANA Registrations for Enumservice May 2008 108 "sms:smpp" and URI Scheme "smpp" 110 3. Introduction 112 ENUM (E.164 Number Mapping) [2] is a system that transforms 113 E.164 [10] telephone numbers into domain names and then uses 114 the Domain Name System (DNS) [11] and Naming Authority Pointer 115 (NAPTR) [3] resource records (RRs) to query for the services 116 or resources that are available for a specific domain name. 118 This document updates RFC 4355 [4] by registering a new enumservice 119 subtype "smpp" under the existing type "sms" using the URI scheme 120 "smpp" as per the IANA registration process defined in RFC 3761 [2] 121 and draft-ietf-enum-enumservices-guide-07 [12] and registers a new 122 URI scheme "smpp" according to the URI registration procedure in RFC 123 4395 [5]. 125 This enumservice subtype indicates that the remote resource 126 identified by the URI can receive short messages using the Short 127 Message Peer-to-Peer Protocol (SMPP) [13]. 129 The purpose of the registered enumservice subtype and URI 130 scheme is to enable service providers to exchange the short 131 message traffic over IP using the widely supported SMPP. 133 SMPP sessions can be established over TCP/IP or X.25 [14] 134 connections. This document discusses only the TCP/IP case. 135 Several radio access technologies are used by the mobile networks 136 worldwide, the way the Global system for Mobile Communications 137 (GSM) systems handle the short message delivery [15,16] is used in 138 this document to simplify the discussions. 140 For a mobile-originated short message, the Mobile-services 141 Switching Center (MSC) or Serving GPRS Support Node (SGSN) that 142 serves the sender submits the short message to the Service Center 143 (SC) in the sender's home network via the Interworking MSC for 144 Short Message Service (SMS-IWMSC). A successful short message 145 delivery to a mobile user involves the SC and Gateway MSC for Short 146 Message Service (SMS-GMSC) in the sender's home network that 147 queries the Home Location Register (HLR) in the receiver's home 148 network via Signaling System Number 7 (SS7) to retrieve information 149 about the MSC and/or SGSN that currently serve(s) the receiver 150 followed by the short message delivery to the MSC or SGSN via SS7. 151 This document uses the Short Message Service Center (SMSC) to avoid 152 mentioning the SMS-GMSC, SMS-IWMSC and SC to simplify the 153 discussions. 155 Standards Track - Expires November 7, 2008 3 156 IANA Registrations for Enumservice May 2008 157 "sms:smpp" and URI Scheme "smpp" 159 4. Formal Syntax 161 RFC 4355 [4] allows subtypes be defined under the type "sms". This 162 document proposes a new subtype "smpp" so the enumservice is 163 "sms:smpp". 165 The syntax specification using the augmented Backus-Naur Form (BNF) 166 as described in RFC 5234 [6] for the "smpp" URI can be found in 167 Section 8.2. 169 5. Use Cases 171 There are at least five use cases where some network entities in 172 the mobile networks that deal with short message submission or 173 delivery may want to retrieve the "smpp" URI via ENUM queries so as 174 to deliver the short messages via SMPP/IP instead of SS7. 176 a. An SMS hub provider that receives a short message from the 177 originating network can send an ENUM query to retrieve the 178 "smpp" URI for the destination mobile telephone number. If the 179 destination mobile telephone number is served by a mobile 180 operator (identified by the information in the host part of the 181 URI) that uses this SMS hub provider's service, the SMS hub 182 provider can use the information in the "smpp" URI to terminate 183 the short message via SMPP/IP. If the destination mobile 184 telephone number is served by a mobile operator that does not 185 use this SMS hub provider's service, the SMS hub provider simply 186 forwards the short message to the SMS hub provider that can 187 reach the destination mobile operator. 189 b. The SMSC in the sender's home network that receives a short 190 message from the sender can send an ENUM query to see if the 191 home operator that serves the destination mobile telephone 192 number has an SMS Gateway (GW) (e.g., SMS Router [17] or IP-SM- 193 GW in [18,19,20]) that can receive all the mobile-terminated 194 short messages via SMPP/IP. If the "smpp" URI is found and SMPP 195 sessions with the remote resource are allowed, the short message 196 is delivered to the SMS Gateway via SMPP/IP. Otherwise, the 197 SMSC handles the short message as is done today except that it 198 may send the ENUM query as is described in case #c after it 199 receives the positive response from the HLR. 201 c. The SMSC in the sender's home network that has queried the HLR 202 associated with the destination mobile telephone number and 203 received the E.164 number associated with the MSC and/or SGSN 204 that currently serve(s) the destination mobile telephone number 205 can send an ENUM query to see if the MSC or SGSN can receive the 207 Standards Track - Expires November 7, 2008 4 208 IANA Registrations for Enumservice May 2008 209 "sms:smpp" and URI Scheme "smpp" 211 short messages via SMPP/IP. If the "smpp" URI is found and SMPP 212 sessions with the remote resource are allowed, the short message 213 is delivered via SMPP/IP. Otherwise, the short message is 214 delivered via SS7. 216 d. The SMS GW mentioned in case #b above that receives an incoming 217 short message via SS7 or IP and wants to send the short message 218 to the MSC or SGSN that currently serves the destination mobile 219 telephone number can send an ENUM query to see if that MSC or 220 SGSN can receive the short messages via SMPP/IP. If the "smpp" 221 URI is found and SMPP sessions with the remote resource are 222 allowed, the short message is delivered via SMPP/IP. Otherwise, 223 the short message is delivered via SS7. Certainly, the SMS GW 224 can deliver the message via IP if the terminating device 225 supports the capabilities specified in [18,19,20]. 227 e. The MSC or SGSN serving the sender can use the E.164 number 228 associated with the sender's home SMSC to send an ENUM query to 229 see if that SMSC can receive short messages via SMPP/IP. If the 230 "smpp" URI is found and SMPP sessions with the remote resource 231 are allowed, the short message is delivered via SMPP/IP. 232 Otherwise, the short message is delivered via SS7. 234 ENUM queries may not be needed for countries that do not support 235 mobile number portability (MNP) because the prefix of the 236 destination mobile telephone number or the E.164 numbers associated 237 with the MSC, SGSN and SMSC and locally provisioned data together 238 may be sufficient to identify the remote entity/resource and 239 whether the remote entity/resource supports SMPP/IP. When the 240 destination mobile telephone number is subject to MNP and ENUM 241 provides MNP-corrected responses, the querier can use an ENUM query 242 to see if the response contains the "smpp" URI. 244 For the five cases above, case #a is the most likely case to happen 245 because the SMS hub providers currently use SMPP to communicate 246 with the originating SMSC, with each other, and/or with the 247 destination SMS GW. But they currently use local or remote 248 databases and/or other operator-specific information to identify 249 the destination operator and the destination SMS GW. 251 More and more operators may deploy SMS GWs to receive all incoming 252 mobile-terminated short messages for reasons stated in [17] or for 253 delivering the messages over IP [18,19,20]. When that happens, 254 more SMSCs may send ENUM queries to see if they can retrieve the 255 "smpp" URI in the ENUM responses so as to deliver the short 256 messages via SMPP/IP without querying the HLR and delivering the 258 Standards Track - Expires November 7, 2008 5 259 IANA Registrations for Enumservice May 2008 260 "sms:smpp" and URI Scheme "smpp" 262 short messages via SS7. [18,19,20] discuss and specify how short 263 messages can be delivered to the terminating devices over IP when 264 the terminating devices support SMS over IP or Immediate Messaging 265 (IM) after the SMS GW (e.g., IP-SM-GW) receives the short messages 266 from the SMSCs over SS7. Since the SMSCs are more likely to 267 support SMPP rather than Session Initiation Protocol (SIP) [7], the 268 SMS GW can advertise its ability to receive short messages over 269 SMPP/IP via ENUM. Using SIP to receive the short messages from the 270 SMSCs at the SMS GW that can deliver the messages to the 271 terminating devices via SIP is outside the scope of this document. 273 Cases #c, #d and #e may happen when many MSCs and SGSNs support 274 SMPP/IP. 276 An SMPP message is acknowledged immediately when received; 277 therefore, the SMPP mechanism that requests for notification on 278 actual message delivery should be used so as not to impact the 279 message delivery status reporting mechanism that is available when 280 the short message is delivered via SS7. 282 6. Example 284 $ORIGIN 4.3.2.1.4.3.4.1.7.5.1.example.net. 285 NAPTR 10 100 "u" "E2U+sms:smpp" 286 "!^.*!smpp:smsgw.mnoX.example.com!" . 288 In this example, an "smpp" URI is returned in the ENUM response. 289 The querying node, if supporting SMPP and having established 290 business relationship and prior exchange of security information 291 (e.g., system ID and password for SMPP session setup) with the 292 remote domain for sending the short messages via SMPP, can first 293 query to see if any Service (SRV) RR [21] can be retrieved via DNS 294 for 296 _smpp._tcp.smsgw.mnoX.example.com. 298 The querying node selects an SRV RR based on [21] if more than one 299 SRV RRs are retrieved and uses the host name in the "Target" field 300 of the SRV RR to retrieve the IP address via DNS. If no SRV RR can 301 be found, it retrieves the IP address of "smsgw.mnoX.example.com" 302 via DNS. It then establishes the SMPP session over TCP/IP, if not 303 yet established, and sends the short message via SMPP to that IP 304 address. If an SRV RR is retrieved and selected, the port number in 305 the SRV RR is used for the TCP connection. Otherwise, the default 306 port number of 2775 is used. 308 Standards Track - Expires November 7, 2008 6 309 IANA Registrations for Enumservice May 2008 310 "sms:smpp" and URI Scheme "smpp" 312 7. Security Considerations 314 Please see the discussions on security considerations for the 315 registrations of Enumservice "sms:smpp" and URI scheme "smpp" in 316 Sections 8.1 and 8.2 respectively. 318 8. IANA Considerations 320 This document registers the "smpp" Enumservice using the subtype 321 "smpp" under the existing type "sms" in the Enumservice registry 322 described in the IANA considerations in RFC 3761 [2] and draft-ietf- 323 enum-enumservices-guide-07 [12]. This document also registers with 324 the IANA the "smpp" URI scheme per RFC 4395 [5]. Details of the two 325 registrations can be found in Sections 8.1 and 8.2 below. 327 8.1. IANA Registration for Enumservice "sms:smpp" 329 Enumservice Name: smpp 331 Enumservice Class: Common Application 333 Enumservice Type: sms 335 Enumservice subtype: smpp 337 URI scheme: smpp 339 Functional Specification: This Enumservice indicates that the 340 resource identified by the associated URI is capable of receiving 341 short messages using the SMPP protocol [13]. 343 Security Considerations: Use of the "sms:smpp" Enumservice shall 344 either be within a service provider's internal network, or on a 345 private basis between one or more parties. It is assumed that 346 this Enumservice is used in an environment where entities are 347 trusted and general public or attackers are not supposed to have 348 access to the DNS RRs containing the "smpp" URI. 350 The initial purpose of this Enumservice and the "smpp" URI is to 351 indicate that the remote resource can receive short messages using 352 SMPP. It is recommended that only the appears in the 353 URI. If the is present, it is recommended that it 354 contains the international telephone number with the leading "+" 355 so as not to convey user-specific information in the "smpp" URI. 357 Intended Usage: COMMON 359 Registration Document: This document contains all the information 360 needed for the registration of this enumservice subtype. 362 Standards Track - Expires November 7, 2008 7 363 IANA Registrations for Enumservice May 2008 364 "sms:smpp" and URI Scheme "smpp" 366 Author: James Yu (see Author's Address Section for author contact 367 detail) 369 Further Information: See Section 5 of this document. 371 8.2. IANA Registration for URI Scheme "smpp" 373 URI scheme name: smpp 375 Status: Permanent 377 SMPP is used by network entities operated by the 378 carriers/operators, inter-carrier vendors and service providers. 379 Use of this URI should be either be within a service provider's or 380 carrier's/operator's internal network, or on a private basis 381 between one or more parties using a variety of security mechanisms 382 to prevent general public access. The DNS RRs that contain this 383 URI and are to be returned in ENUM responses should not be part of 384 the e164.arpa zone or any other portion of the Internet DNS tree. 386 URI scheme syntax: 388 smpp-uri = "smpp:" [userinfo "@"] hostport 389 *(";" uri-param) [headers] 390 userinfo = user / telephone-subscriber 391 uri-param = user-param / other-param 392 user-param = "user=" ( "phone" / other-user ) 394 , , , and are 395 imported from RFC 3261 [7]. is imported 396 from RFC 3966 [8]. 398 URI scheme semantics: "user=phone" must be present when appears in the of the URI. The default TCP 400 port number for SMPP is 2775. If a port number appears in the 401 , that port number should be used. 403 The initial purpose of an "smpp" URI is to return the host 404 information in the "smpp" URI in an ENUM response to identify the 405 remote resource that can receive short messages via SMPP/IP. 406 This URI is not intended to be used in other protocols (e.g., SIP 407 Request-URI) for addressing and routing purposes, at least for the 408 purpose of this document. The URI scheme syntax provides an 409 extension mechanism to add parameters and header fields in the 410 future for other uses of this URI. 412 Encoding considerations: US-ASCII characters are included in the URI 413 without any conversion. Non-US-ASCII characters MUST be percent- 414 encoded as described in Section 2.1 of RFC 3986 [9]. 416 Standards Track - Expires November 7, 2008 8 417 IANA Registrations for Enumservice May 2008 418 "sms:smpp" and URI Scheme "smpp" 420 Intended usage: An "smpp" URI identifies a remote resource that can 421 receive short messages using the SMPP protocol. The of 422 the URI can be used to locate the IP address of that remote 423 resource. Please see Section 6 of this document for an example on 424 how the host name in the of the URI is used to locate 425 the IP address. 427 Applications/protocols that use this URL scheme name: The "smpp" URI 428 is intended to be used by entities that communicate with each 429 other using the SMPP protocol. An entity that has a short message 430 to deliver and wants to find out if the remote entity that deals 431 with the destination telephone number or associated with a 432 telephone number can be reached via SMPP/IP, can make an ENUM 433 query to see if such a URI is returned in the ENUM response. 435 Interoperability considerations: The URI is designed to be used 436 specifically for nodes in trusted systems that query private ENUM 437 implementations (e.g., Carrier ENUM). 439 Security considerations: The initial use of the "smpp" URI is for 440 Enumservice "sms:smpp" where the <"hostport> in the "smpp" URI 441 identifies the remote resource that can receive short messages 442 over SMPP/IP. It is recommended that only the appears 443 in the URI. If the is present, it is recommended that 444 it contains the international telephone number with the leading 445 "+" so as not to convey user-specific information in the "smpp" 446 URI. 448 Frame Relay and Virtual Private Network (VPN) connections are 449 usually used to establish the SMPP sessions and each SMPP session 450 is authorized by verifying the System ID and password at session 451 setup time. Those security related measures should be used. 453 Contact: See the Author's Address Section of this document for 454 author's contact information. 456 Author/change controller: This URI scheme is registered under the 457 IETF tree. As such, the IETF maintains change control. 459 References: See Sections 5 and 8.1 of this document and [13] and 460 [15] in Section 9 of this document. 462 Standards Track - Expires November 7, 2008 9 463 IANA Registrations for Enumservice May 2008 464 "sms:smpp" and URI Scheme "smpp" 466 9. References 468 9.1. Normative References 470 [1] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement 471 Levels", BCP 14, RFC 2119, March 1997. 473 [2] P. Faltstrom and M. Mealling, "The E.164 to Uniform Resource 474 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 475 Application (ENUM)", RFC 3761, April 2004. 477 [3] M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part 478 Four: The Uniform Resource Identifiers (URI)", RFC 3404, 479 October 2002. 481 [4] R. Brandner, et al., "IANA Registration for Enumservices email, 482 fax, mms, ems, and sms", RFC 4355, January 2006. 484 [5] T. Hansen, et al., "Guidelines and Registration Procedures for 485 New URI Schemes", RFC 4395, February 2006. 487 [6] D. Crocker and P. Overell, "Augmented BNF for Syntax 488 Specifications: ABNF", STD 68, RFC 5234, January 2008. 490 [7] J. Rosenberg, et al., RFC3261, "SIP: Session Initiation 491 Protocol", June 2002. 493 [8] H. Schulzrinne, "The tel URI for Telephone Numbers", RFC 3966, 494 December 2004. 496 [9] T. Berners-Lee, et al., "Uniform Resource Identifiers (URI): 497 Generic Syntax", RFC 3986, January 2005. 499 9.2. Informative References 501 [10] ITU-T, "The International Public Telecommunication Numbering 502 Plan", Recommendation E.164, May 1997. 504 [11] P. Mockapetris, "Domain Names - Concepts and Facilities", STD 505 13, RFC 1034, November 1987. 507 [12] B. Hoeneisen, et al., "IANA Registration of Enumservices: 508 Guide, Template and IANA Considerations", draft-ietf-enum- 509 enumservices-guide-08, March 2008. 511 [13] SMS Forum, "Short Message Peer-to-Peer Protocol (SMPP) 512 Specification Version 5.0 ", February 19, 2003. 514 [14] ITU-T Recommendation X.25, "Interface between Data Terminal 515 Equipment (DTE) and Data Circuit-terminating Equipment (DCE) 517 Standards Track - Expires November 7, 2008 10 518 IANA Registrations for Enumservice May 2008 519 "sms:smpp" and URI Scheme "smpp" 521 for terminals operating in the packet mode and connected to 522 public data networks by dedicated circuit", October 1996. 524 [15] 3GPP TS 23.040 v7.0.1, "3rd Generation Partnership Project; 525 Technical Specification Group Core Network and Terminals; 526 Technical realization of the Short Message Service (SMS) 527 (Release 7)", March 2007. 529 [16] 3GPP TS 29.002 v7.9.0, "3rd Generation Partnership Project; 530 Technical Specification Group Core Network and Terminals; 531 Mobile Application Part (MAP specification; (Release 7)", 532 September 2007. 534 [17] 3GPP TS 23.840 v7.1.0, "3rd Generation Partnership Project; 535 Technical Specification Group Core Network and Terminals; Study 536 into routeing of MT-SMs via the HPLMN; (Release 7)", March 537 2007. 539 [18] 3GPP TS 24.341 v7.2.0, "3rd Generation Partnership Project; 540 Technical Specification Group Core Network and Terminals; 541 Support of SMS over IP networks; Stage 3 (Release 7)", December 542 2007. 544 [19] 3GPP TR 23.811 v8.0.0, "3rd Generation Partnership Project; 545 Technical Specification Group Core Network and Terminals; 546 Service Level Interworking for Messaging Services; Stage 2 547 (Release 8)", March 2008. 549 [20] 3GPP TS 23.204 v7.5.0, "3rd Generation Partnership Project; 550 Technical Specification Group Services and System Aspects; 551 Support of Short Message Service (SMS) over generic 3GPP 552 Internet Protocol (IP) access; Stage 2 (Release 7)", March 553 2008. 555 [21] A. Gulbrandsen, et al., "A DNS RR for specifying the location 556 of services (DNS SRV)", RFC 2782, February 2000. 558 Author's Address 560 James Yu 561 NeuStar, Inc. 562 46000 Center Oak Plaza 563 Sterling, VA 20166 564 U.S.A. 565 Phone: +1-571-434-5572 566 Email: james.yu@neustar.biz 568 Standards Track - Expires November 7, 2008 11 569 IANA Registrations for Enumservice May 2008 570 "sms:smpp" and URI Scheme "smpp" 572 Full Copyright Statement 574 Copyright (C) The IETF Trust (2008). 576 This document is subject to the rights, licenses and restrictions 577 contained in BCP 78, and except as set forth therein, the authors 578 retain all their rights. 580 This document and the information contained herein are provided on 581 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 582 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 583 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 584 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 585 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 586 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 587 FOR A PARTICULAR PURPOSE. 589 Intellectual Property 591 The IETF takes no position regarding the validity or scope of any 592 Intellectual Property Rights or other rights that might be claimed 593 to pertain to the implementation or use of the technology described 594 in this document or the extent to which any license under such 595 rights might or might not be available; nor does it represent that 596 it has made any independent effort to identify any such rights. 597 Information on the procedures with respect to rights in RFC 598 documents can be found in BCP 78 and BCP 79. 600 Copies of IPR disclosures made to the IETF Secretariat and any 601 assurances of licenses to be made available, or the result of an 602 attempt made to obtain a general license or permission for the use 603 of such proprietary rights by implementers or users of this 604 specification can be obtained from the IETF on-line IPR repository 605 at http://www.ietf.org/ipr. 607 The IETF invites any interested party to bring to its attention any 608 copyrights, patents or patent applications, or other proprietary 609 rights that may cover technology that may be required to implement 610 this standard. Please address the information to the IETF at ietf- 611 ipr@ietf.org. 613 Acknowledgment 615 Funding for the RFC Editor function is provided by the IETF 616 Administrative Support Activity (IASA). 618 Standards Track - Expires November 7, 2008 12