idnits 2.17.1 draft-ietf-enum-msg-05.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 727. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 9, 2005) is 6920 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) == Unused Reference: '21' is defined on line 668, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 671, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 674, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3761 (ref. '2') (Obsoleted by RFC 6116, RFC 6117) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 3401 (ref. '6') ** Obsolete normative reference: RFC 2368 (ref. '11') (Obsoleted by RFC 6068) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' == Outdated reference: A later version (-06) exists of draft-ietf-lemonade-mms-mapping-03 -- Obsolete informational reference (is this intentional?): RFC 3978 (ref. '22') (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 3979 (ref. '23') (Obsoleted by RFC 8179) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM R. Brandner 3 Internet-Draft Siemens AG 4 Expires: November 10, 2005 L. Conroy 5 Siemens Roke Manor Research 6 R. Stastny 7 Oefeg 8 May 9, 2005 10 IANA Registration for Enumservices email, fax, mms, ems and sms 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 10, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document registers the Enumservices "email", "fax", "sms", "ems" 45 and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA 46 registration process defined in the ENUM specification RFC3761. 48 Table of Contents 50 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Email Service Registration . . . . . . . . . . . . . . . . . . 6 53 4. Fax Service Registration . . . . . . . . . . . . . . . . . . . 7 54 5. MMS, EMS, SMS Service . . . . . . . . . . . . . . . . . . . . 8 55 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 8 56 5.2 SMS Service Registrations . . . . . . . . . . . . . . . . 8 57 5.2.1 SMS Service Registration with tel: URI . . . . . . . . 8 58 5.2.2 SMS Service Registration with mailto: URI . . . . . . 9 59 5.3 EMS Service Registrations . . . . . . . . . . . . . . . . 10 60 5.3.1 EMS Service Registration with tel: URI . . . . . . . . 10 61 5.3.2 EMS Service Registration with mailto: URI . . . . . . 11 62 5.4 MMS Service Registrations . . . . . . . . . . . . . . . . 11 63 5.4.1 MMS Service Registration with tel: URI . . . . . . . . 11 64 5.4.2 MMS Service Registration with mailto: URI . . . . . . 12 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 8.1 Normative References . . . . . . . . . . . . . . . . . . . 18 69 8.2 Informative References . . . . . . . . . . . . . . . . . . 19 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 71 Intellectual Property and Copyright Statements . . . . . . . . 21 73 1. Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in BCP 14, RFC2119 [1]. 79 2. Introduction 81 ENUM (E.164 Number Mapping, RFC3761 [2]) is a system that transforms 82 E.164 numbers [3] into domain names and then uses DNS (Domain Name 83 Service, RFC1034 [4]) services like delegation through NS records and 84 NAPTR records to look up what services are available for a specific 85 domain name. 87 This document registers Enumservices according to the guidelines 88 given in RFC3761 to be used for provisioning in the services field of 89 a NAPTR [5] resource record to indicate what class of functionality a 90 given end point offers. The registration is defined within the DDDS 91 (Dynamic Delegation Discovery System [6][7] [5][8] [9]) hierarchy, 92 for use with the "E2U" DDDS Application defined in RFC3761. 94 The following Enumservices are registered with this document: 95 "email", "fax", "sms", "ems" and "mms". These share a common feature 96 in that they each indicate that the functionality of the given end 97 points and the associated resources are capable of receiving discrete 98 messages, albeit of different types. 100 According to RFC3761, the Enumservice registered must be able to 101 function as a selection mechanism when choosing one NAPTR resource 102 record from another. That means that the registration MUST specify 103 what is expected when using that very NAPTR record, and the URI 104 scheme which is the outcome of the use of it. 106 Therefore an Enumservice acts as a hint, indicating the kind of 107 service with which the URI constructed using the regexp field is 108 associated. There can be more than one Enumservice included within a 109 single NAPTR; this indicates that there is more than one service that 110 can be achieved using the associated URI scheme. 112 The common thread with this set of definitions is that they reflect 113 the kind of service that the end user will hope to achieve with the 114 communication using the associated URI. 116 The services specified here are intended not to specify the protocol 117 or even method of connection that must be used to achieve each 118 service. Instead they define the kind of interactive behaviour that 119 an end user will expect, leaving the end system to decide (based on 120 policies outside the remit of this specification) how to execute the 121 service. 123 Since the same URI scheme may be used for different services (e.g. 124 'tel:'), and the same kind of service may use different URI schemes 125 (e.g. for VoIP 'h323:' and 'tel:' may be used), it is necessary in 126 some cases to specify the service and the URI scheme used. 128 The service parameters defined in RFC3761 allow therefore a "type" 129 and a "subtype" to be specified. Within this set of specifications 130 the convention is assumed that the "type" (being the more generic 131 term) defines the service and the "subtype" defines the URI scheme. 133 Even where currently only one URI scheme is associated with a given 134 service, it should be considered that an additional URI scheme to be 135 used with this service may be added later. Thus the subtype is 136 needed to identify the specific Enumservice intended. 138 In this document, there are two URI schemes that are used within the 139 various services. These are 'tel:', as specified in RFC3966 [10] and 140 'mailto:', as specified in RFC2368 [11]. 142 3. Email Service Registration 144 Enumservice Name: "email" 146 Enumservice Type: "email" 148 Enumservice Subtype: "mailto" 150 URI Scheme: 'mailto:' 152 Functional Specification: 154 This Enumservice indicates that the remote resource can be 155 addressed by the associated URI scheme in order to send an email. 157 Security Considerations: 159 See Section 6. 161 Intended Usage: COMMON 163 Authors: 165 Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 166 contact detail see Authors' Addresses section) 168 Any other information the author deems interesting: 170 None 172 4. Fax Service Registration 174 Enumservice Name: "fax" 176 Enumservice Type: "fax" 178 Enumservice Subtype: "tel" 180 URI Scheme: 'tel:' 182 Functional Specification: 184 This Enumservice indicates that the resource identified by the 185 associated URI scheme is capable of being contacted to provide a 186 communication session during which facsimile documents can be 187 sent. 189 A client selecting this NAPTR will have support for generating and 190 sending facsimile documents to the recipient using the PSTN 191 session and transfer protocols specified in [12] and [13] - in 192 short, they will have a fax program with a local or shared PSTN 193 access over which they can send faxes. 195 Security Considerations: 197 See Section 6. 199 Intended Usage: COMMON 201 Authors: 203 Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 204 contact detail see Authors' Addresses section) 206 Any other information the author deems interesting: 208 None 210 5. MMS, EMS, SMS Service 212 5.1 Introduction 214 An ENUM NAPTR indicates ability on the part of the Subscriber to 215 receive specified communication service (or services) provided via 216 the contact address (shown in the generated URI). 218 In the case of MMS, EMS, and SMS services, the capability of these 219 services is a nested superset; thus a service supporting MMS can 220 support also delivery of EMS or SMS message content to a recipient 221 that is receiving a Multimedia Message, whilst a service supporting 222 EMS can also deliver SMS message content to a recipient that can 223 accept receipt of EMS Messages. 225 Thus, even if a client wants only to generate and send content that 226 could be carried in an SMS message, they MAY choose to consider also 227 NAPTRs holding EMS and/or MMS Enumservices, as these indicate that 228 the destination can accept EMS and/or MMS messages; these services 229 will be able to deliver SMS content to the recipient address. 231 Conversely, a client capable of sending MMS messages may choose to 232 consider also NAPTRs indicating support for EMS or SMS messages, 233 (assuming that the network to which it is connected provides these 234 services as well, or is capable of providing a gateway to systems 235 that do provide these services). In taking this choice, it would 236 have to "downgrade" its User Interface to allow only generation of 237 content that conforms to SMS or EMS standards. 239 These behaviours on the part of the client are purely optional, and 240 are NOT the subject of any protocol standardisation. 242 5.2 SMS Service Registrations 244 5.2.1 SMS Service Registration with tel: URI 246 Enumservice Name: "sms" 248 Enumservice Type: "sms" 250 Enumservice Subtypes: "tel" 252 URI Scheme: 'tel:' 254 Functional Specification: 256 This Enumservice indicates that the resource identified by the 257 associated URI scheme is capable of receiving a message using the 258 Short Message Service (SMS) [14]. 260 Security Considerations: 262 There are no specific security issues with this Enumservice. 263 However, the general considerations of Section 6 apply. 265 Intended Usage: COMMON 267 Authors: 269 Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 270 contact detail see Authors' Addresses section) 272 Any other information the author deems interesting: 274 None 276 5.2.2 SMS Service Registration with mailto: URI 278 Enumservice Name: "sms" 280 Enumservice Type: "sms" 282 Enumservice Subtypes: "mailto" 284 URI Scheme: 'mailto:' 286 Functional Specification: 288 This Enumservice indicates that the resource identified by the 289 associated URI scheme is capable of receiving a message using an 290 email protocol. 292 SMS content is sent over SMTP using the format specified by TS 293 23.140 [15] section 8.4.4 and TS 26.140 [16] section 4, as an MMS 294 message. Within such a message, SMS content is carried as either 295 a text or application/octet-stream MIME sub-part (see TS 26.140 296 [16] , section 4.1). 298 Security Considerations: 300 There are no specific security issues with this Enumservice. 301 However, the general considerations of Section 6 apply. 303 Intended Usage: COMMON 305 Authors: 307 Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 308 contact detail see Authors' Addresses section) 310 Any other information the author deems interesting: 312 None 314 5.3 EMS Service Registrations 316 5.3.1 EMS Service Registration with tel: URI 318 Enumservice Name: "ems" 320 Enumservice Type: "ems" 322 Enumservice Subtype: "tel" 324 URI Scheme: 'tel:' 326 Functional Specification: 328 This Enumservice indicates that the resource identified by the 329 associated URI scheme is capable of receiving a message using the 330 Enhanced Message Service (EMS) [14]. 332 Security Considerations: 334 There are no specific security issues with this Enumservice. 335 However, the general considerations of Section 6 apply. 337 Intended Usage: COMMON 339 Authors: 341 Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 342 contact detail see Authors' Addresses section) 344 Any other information the author deems interesting: 346 Note that an indication of EMS can be taken as implying that the 347 recipient is capable of receiving SMS messages at this address as 348 well. 350 5.3.2 EMS Service Registration with mailto: URI 352 Enumservice Name: "ems" 354 Enumservice Type: "ems" 356 Enumservice Subtypes: "mailto" 358 URI Scheme: 'mailto:' 360 Functional Specification: 362 This Enumservice indicates that the resource identified by the 363 associated URI scheme is capable of receiving a message using an 364 email protocol. 366 EMS content is sent over SMTP using the format specified by TS 367 23.140 [15] section 8.4.4 and TS 26.140 [16] section 4, as an MMS 368 message. Within such a message, EMS content is carried as either 369 a text or application/octet-stream MIME sub-part (see TS 26.140 370 [16] , section 4.1). 372 Security Considerations: 374 There are no specific security issues with this Enumservice. 375 However, the general considerations of Section 6 apply. 377 Intended Usage: COMMON 379 Authors: 381 Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 382 contact detail see Authors' Addresses section) 384 Any other information the author deems interesting: 386 None 388 5.4 MMS Service Registrations 390 5.4.1 MMS Service Registration with tel: URI 392 Enumservice Name: "mms" 394 Enumservice Type: "mms" 396 Enumservice Subtype: "tel" 397 URI Scheme: 'tel:' 399 Functional Specification: 401 This Enumservice indicates that the resource identified by the 402 associated URI scheme is capable of receiving a message using the 403 Multimedia Messaging Service (MMS) [15]. 405 Security Considerations: 407 There are no specific security issues with this Enumservice. 408 However, the general considerations of Section 6 apply. 410 Intended Usage: COMMON 412 Authors: 414 Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 415 contact detail see Authors' Addresses section) 417 Any other information the author deems interesting: 419 Note that MMS can be used as an alternative to deliver an SMS RP- 420 DATA RPDU if, for example, the SMS bearer is not supported. If an 421 entry includes this Enumservice, then in effect this can be taken 422 as implying that the recipient is capable of receiving EMS or SMS 423 messages at this address. Such choices on the end system design 424 do have two small caveats; whilst in practice all terminals 425 supporting MMS today support SMS as well, it might not necessarily 426 be the case in the future, and there may be tariff differences in 427 using the MMS rather than using the SMS or EMS. 429 5.4.2 MMS Service Registration with mailto: URI 431 Enumservice Name: "mms" 433 Enumservice Type: "mms" 435 Enumservice Subtypes: "mailto" 437 URI Scheme: 'mailto:' 439 Functional Specification: 441 This Enumservice indicates that the resource identified by the 442 associated URI scheme is capable of receiving a message using an 443 email protocol. 445 MMS messages are sent over SMTP using the format specified by TS 446 23.140 [15] section 8.4.4 and TS 26.140 [16] section 4. 448 Within and between MMS Environments (MMSE, network infrastructures 449 that support the MultiMedia Service), other pieces of state data 450 (for example, charging-significant information) are exchanged 451 between MMS Relay Servers. Thus, although these servers use SMTP 452 as the "bearer" for their application exchanges, they map their 453 internal state to specialised headers carried in the SMTP message 454 exchanges. The headers used in such MMSE are described in detail 455 in [17]. 457 Security Considerations: 459 There are no specific security issues with this Enumservice. 460 However, the general considerations of Section 6 apply. 462 Intended Usage: COMMON 464 Authors: 466 Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 467 contact detail see Authors' Addresses section) 469 Any other information the author deems interesting: 471 The MMS Architecture describes an interface between the MMSE and 472 "legacy messaging systems" (labelled as MM3) which accepts 473 "standard" SMTP messages. Thus although the MMS Relay Server 474 that supports this interface appears as a standard SMTP server 475 from the perspective of an Internet-based mail server, it acts as 476 a gateway and translator, adding the internal state data that is 477 used within and between the MMS Environments. This mechanism is 478 described in [17], which also includes references to the 479 specifications agreed by those bodies responsible for the design 480 of the MMS. 482 6. Security Considerations 484 DNS, as used by ENUM, is a global, distributed database. Thus any 485 information stored there is visible to anyone anonymously. Whilst 486 this is not qualitatively different from publication in a Telephone 487 Directory, it does open the data subject to having "their" 488 information collected automatically without any indication that this 489 has been done or by whom. 491 Such data harvesting by third parties is often used to generate lists 492 of targets for unrequested information; in short, they are used to 493 address "spam". Anyone who uses a Web-archived mailing list is aware 494 that the volume of "spam" email they are sent increases when they 495 post to the mailing list; publication of a telephone number in ENUM 496 is no different, and may be used to send "junk faxes" or "junk SMS" 497 for example. 499 Many mailing list users have more than one email address and use 500 "sacrificial" email accounts when posting to such lists to help 501 filter out unrequested emails sent to them. This is not so easy with 502 published telephone numbers; the PSTN E.164 number assignment process 503 is much more involved and usually a single E.164 number (or a fixed 504 range of numbers) is associated with each PSTN access. Thus 505 providing a "sacrificial" phone number in any publication is not 506 possible. 508 Due to the implications of publishing data on a globally accessible 509 database, as a principle the data subject MUST give their explicit 510 informed consent to data being published in ENUM. 512 In addition, they should be made aware that, due to storage of such 513 data during harvesting by third parties, removal of the data from 514 publication will not remove any copies that have been taken; in 515 effect, any publication may be permanent. 517 However, regulations in many regions will require that the data 518 subject can at any time request that the data is removed from 519 publication, and that their consent for its publication is explicitly 520 confirmed at regular intervals. 522 When placing a fax call via the PSTN or a sending a message via the 523 Public Land Mobile Network, the sender may be charged for this 524 action. In both kinds of network, calling or messaging to some 525 numbers is more expensive than sending to others; both networks have 526 "premium rate" services that can charge considerably more than a 527 "normal" call or message destination. As such, it is important that 528 the end user be asked to confirm sending the message, and that the 529 destination number be presented to them. It is the originating 530 user's choice on whether or not to send a message to this destination 531 number, but they SHOULD be shown the destination number so that they 532 can make this decision. 534 Although a fax number, like other E.164 numbers, doesn't appear to 535 reveal as much identity information about a user as a name in the 536 format user@host (e.g. an email or sip address), the information is 537 still publicly available, thus there is still the risk of unwanted 538 communication. 540 An analysis of threats specific to the dependence of ENUM on the DNS, 541 and the applicability of DNSSEC [18] to these, is provided in RFC3761 542 [2]. A thorough analysis of threats to the DNS itself is covered in 543 RFC3833 [19]. 545 An email address is a canonical address by which a user is known. 546 Placing this address in ENUM is comparable to placing a SIP or H.323 547 address in the DNS. 549 DNS does not make any policy decisions about the records that it 550 shares with an inquirer. All DNS records must be assumed to be 551 available to all inquirers at all times. The information provided 552 within an ENUM NAPTR resource record must therefore be considered to 553 be open to the public, which is a cause for some privacy 554 considerations. 556 Therefore ENUM Subscribers should be made aware of this risk. Since 557 it is within the responsibility of the ENUM Subscriber which data is 558 entered in ENUM, it is within the ENUM Subscribers control if he 559 enters email addresses: 561 1. allowing inference of private data e.g. his first and last name 563 2. at all 565 It should also be considered that it is the purpose of public 566 communication identifiers to be publicly known. To reduce spam and 567 other unwanted communication other means should be made available, 568 such as incoming message filtering. 570 Some Value Added Service Providers use receipt of a short message to 571 a given special service telephone number as a trigger to start 572 delivery of data messages to the calling number. By sending an SMS 573 (or, in principle, an EMS or MMS) to one of these special service 574 numbers, one is entering into a contract to pay for receipt of a set 575 of messages containing information (e.g. news, sports results, "Ring 576 Tones"). 578 Thus it is very important that the end terminal presents the 579 destination number to which any message is to be sent using the "sms: 580 tel", "ems:tel" or "mms:tel" Enumservices, to allow the end user to 581 cancel any message before it is sent to one of these numbers. 583 At present these systems use the circuit switched network trusted 584 calling line identifier to identify the destination for the 585 subsequent charged information messages, and so it is believed that 586 sending using the "sms:mailto", "ems:mailto" or "mms:mailto" 587 Enumservices does not have this risk currently. 589 7. Acknowledgements 591 Many thanks to Ville Warsta for his close reading of the draft and 592 extracting the right references. Thanks also to those who are 593 involved in the parallel effort to specify the requirements for "real 594 world" ENUM trials resulting in TS 102 172 [20], in which this and 595 other Enumservices are referenced. 597 8. References 599 8.1 Normative References 601 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 602 Levels", RFC 2119, BCP 14, March 1997. 604 [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 605 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 606 Application (ENUM)", RFC 3761, April 2004. 608 [3] ITU-T, "The International Public Telecommunication Number 609 Plan", Recommendation E.164, May 1997. 611 [4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 612 RFC 1034, November 1987. 614 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 615 Three: The Domain Name System (DNS) Database", RFC 3403, 616 October 2002. 618 [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 619 One: The Comprehensive DDDS", RFC 3401, October 2002. 621 [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 622 Two: The Algorithm", RFC 3402, October 2002. 624 [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 625 Four: The Uniform Resource Identifiers (URI)", RFC 3404, 626 October 2002. 628 [9] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 629 Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002. 631 [10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 632 December 2004. 634 [11] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL 635 scheme", RFC 2368, July 1998. 637 [12] ITU-T, "Standardization of Group 3 facsimile terminals for 638 document transmission", Recommendation T.4, April 1999. 640 [13] ITU-T, "Procedures for document facsimile transmission in the 641 general switched telephone network", Recommendation T.30, 642 April 1999. 644 [14] 3GPP, "Technical realization of the Short Message Service 645 (SMS); (Release5)", 3GPP TS 23.040. 647 [15] 3GPP, "Multimedia Messaging Service (MMS); Functional 648 description; Stage 2 (Release 5)", 3GPP TS 23.140. 650 [16] 3GPP, "Multimedia Messaging Service (MMS); Media formats and 651 codecs; (Release 5)", 3GPP TS 26.140. 653 [17] Gellens, R., "Mapping Between the Multimedia Messaging Service 654 (MMS) and Internet Mail", draft-ietf-lemonade-mms-mapping-03 655 (Work in Progress), April 2005. 657 8.2 Informative References 659 [18] Arends, R. and et al. , "Protocol Modifications for the DNS 660 Security Extensions", RFC 4035, March 2005. 662 [19] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name 663 System (DNS)", RFC 3833, August 2004. 665 [20] ETSI, "Minimum Requirements for Interoperability of ENUM 666 Implementations", ETSI TS 102 172, January 2005. 668 [21] Bradner, S., "The Internet Standards Process -- Revision 3", 669 RFC 2026, BCP 9, October 1996. 671 [22] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, 672 March 2005. 674 [23] Bradner, S., "Intellectual Property Rights in IETF Technology", 675 BCP 79, RFC 3979, March 2005. 677 Authors' Addresses 679 Rudolf Brandner 680 Siemens AG 681 Hofmannstr. 51 682 81359 Munich 683 Germany 685 Phone: +49-89-722-51003 686 Email: rudolf.brandner@siemens.com 687 Lawrence Conroy 688 Siemens Roke Manor Research 689 Roke Manor 690 Romsey 691 United Kingdom 693 Phone: +44-1794-833666 694 Email: lwc@roke.co.uk 696 Richard Stastny 697 Oefeg 698 Postbox 147 699 1103 Vienna 700 Austria 702 Phone: +43-664-420-4100 703 Email: Richard.stastny@oefeg.at 705 Intellectual Property Statement 707 The IETF takes no position regarding the validity or scope of any 708 Intellectual Property Rights or other rights that might be claimed to 709 pertain to the implementation or use of the technology described in 710 this document or the extent to which any license under such rights 711 might or might not be available; nor does it represent that it has 712 made any independent effort to identify any such rights. Information 713 on the procedures with respect to rights in RFC documents can be 714 found in BCP 78 and BCP 79. 716 Copies of IPR disclosures made to the IETF Secretariat and any 717 assurances of licenses to be made available, or the result of an 718 attempt made to obtain a general license or permission for the use of 719 such proprietary rights by implementers or users of this 720 specification can be obtained from the IETF on-line IPR repository at 721 http://www.ietf.org/ipr. 723 The IETF invites any interested party to bring to its attention any 724 copyrights, patents or patent applications, or other proprietary 725 rights that may cover technology that may be required to implement 726 this standard. Please address the information to the IETF at 727 ietf-ipr@ietf.org. 729 Disclaimer of Validity 731 This document and the information contained herein are provided on an 732 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 733 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 734 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 735 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 736 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 737 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 739 Copyright Statement 741 Copyright (C) The Internet Society (2005). This document is subject 742 to the rights, licenses and restrictions contained in BCP 78, and 743 except as set forth therein, the authors retain all their rights. 745 Acknowledgment 747 Funding for the RFC Editor function is currently provided by the 748 Internet Society.