diff options
Diffstat (limited to 'doc/rfc/rfc4355.txt')
| -rw-r--r-- | doc/rfc/rfc4355.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc4355.txt b/doc/rfc/rfc4355.txt new file mode 100644 index 0000000..80c6baa --- /dev/null +++ b/doc/rfc/rfc4355.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group R. Brandner +Request for Comments: 4355 Siemens AG +Category: Standards Track L. Conroy + Siemens Roke Manor Research + R. Stastny + Oefeg + January 2006 + + + IANA Registration for Enumservices email, fax, mms, ems, and sms + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document registers the Enumservices "email", "fax", "sms", + "ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per + the IANA registration process defined in the ENUM specification RFC + 3761. + + + + + + + + + + + + + + + + + + + + + + +Brandner, et al. Standards Track [Page 1] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. Email Service Registration ......................................4 + 4. Fax Service Registration ........................................4 + 5. MMS, EMS, SMS Service ...........................................5 + 5.1. Introduction ...............................................5 + 5.2. SMS Service Registrations ..................................6 + 5.2.1. SMS Service Registration with tel: URI ..............6 + 5.2.2. SMS Service Registration with mailto: URI ...........6 + 5.3. EMS Service Registrations ..................................7 + 5.3.1. EMS Service Registration with tel: URI ..............7 + 5.3.2. EMS Service Registration with mailto: URI ...........8 + 5.4. MMS Service Registrations ..................................9 + 5.4.1. MMS Service Registration with tel: URI ..............9 + 5.4.2. MMS Service Registration with mailto: URI ..........10 + 6. Security Considerations ........................................11 + 7. Acknowledgements ...............................................13 + 8. References .....................................................13 + 8.1. Normative References ......................................13 + 8.2. Informative References ....................................14 + +1. Introduction + + ENUM (E.164 Number Mapping, RFC 3761 [2]) is a system that transforms + E.164 numbers [3] into domain names and then uses DNS (Domain Name + Service, RFC 1034 [4]) services like delegation through NS records + and NAPTR records to look up what services are available for a + specific domain name. + + This document registers Enumservices according to the guidelines + given in RFC 3761 to be used for provisioning in the services field + of a NAPTR [5] resource record to indicate what class of + functionality a given endpoint offers. The registration is defined + within the DDDS (Dynamic Delegation Discovery System [6][7][5][8][9]) + hierarchy, for use with the "E2U" DDDS Application defined in RFC + 3761. + + The following Enumservices are registered with this document: + "email", "fax", "sms", "ems", and "mms". These share a common + feature in that they each indicate that the functionality of the + given endpoints and the associated resources are capable of receiving + discrete messages, albeit of different types. + + According to RFC 3761, the Enumservice registered must be able to + function as a selection mechanism when choosing one NAPTR resource + record from another. That means that the registration MUST specify + + + +Brandner, et al. Standards Track [Page 2] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + + what is expected when using that very NAPTR record, and the Uniform + Resource Identifier (URI) scheme that is the outcome of the use of + it. + + Therefore, an Enumservice acts as a hint, indicating the kind of + service with which the URI constructed using the regexp field is + associated. There can be more than one Enumservice included within a + single NAPTR; this indicates that there is more than one service that + can be achieved using the associated URI scheme. + + The common thread with this set of definitions is that they reflect + the kind of service that the end-user will hope to achieve with the + communication using the associated URI. + + The services specified here are intended not to specify the protocol + or even method of connection that must be used to achieve each + service. Instead they define the kind of interactive behaviour that + an end-user will expect, leaving the end system to decide (based on + policies outside the remit of this specification) how to execute the + service. + + Since the same URI scheme may be used for different services (e.g., + 'tel:'), and the same kind of service may use different URI schemes + (e.g., for VoIP 'h323:' and 'tel:' may be used), it is necessary in + some cases to specify the service and the URI scheme used. + + The service parameters defined in RFC 3761 allow, therefore, a "type" + and a "subtype" to be specified. Within this set of specifications, + the convention is assumed that the "type" (being the more generic + term) defines the service and the "subtype" defines the URI scheme. + + Even where currently only one URI scheme is associated with a given + service, it should be considered that an additional URI scheme to be + used with this service may be added later. Thus, the subtype is + needed to identify the specific Enumservice intended. + + In this document, there are two URI schemes that are used within the + various services. These are 'tel:', as specified in RFC 3966 [10] + and 'mailto:', as specified in RFC 2368 [11]. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 [1]. + + + + + + +Brandner, et al. Standards Track [Page 3] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + +3. Email Service Registration + + Enumservice Name: "email" + + Enumservice Type: "email" + + Enumservice Subtypes: "mailto" + + URI Scheme: 'mailto:' + + Functional Specification: + + This Enumservice indicates that the remote resource can be + addressed by the associated URI scheme in order to send an email. + + Security Considerations: + + See Section 6. + + Intended Usage: COMMON + + Authors: + + Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author + contact detail, see Authors' Addresses section) + + Any other information the author deems interesting: + + None + +4. Fax Service Registration + + Enumservice Name: "fax" + + Enumservice Type: "fax" + + Enumservice Subtype: "tel" + + URI Scheme: 'tel:' + + Functional Specification: + + This Enumservice indicates that the resource identified by the + associated URI scheme is capable of being contacted to provide a + communication session during which facsimile documents can be + sent. + + + + + +Brandner, et al. Standards Track [Page 4] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + + Clients selecting this NAPTR will have support for generating and + sending facsimile documents to the recipient using the Public + Switched Telephone Network (PSTN) session and transfer protocols + specified in [12] and [13]. In short, they will have a fax + program with a local or shared PSTN access over which they can + send faxes. + + Security Considerations: + + See Section 6. + + Intended Usage: COMMON + + Authors: + + Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author + contact detail see Authors' Addresses section) + + Any other information the author deems interesting: + + None + +5. MMS, EMS, SMS Service + +5.1. Introduction + + An ENUM NAPTR indicates ability on the part of the Subscriber to + receive specified communication service (or services) provided via + the contact address (shown in the generated URI). + + In the case of MMS, EMS, and SMS services, the capability of these + services is a nested superset; thus, a service supporting MMS can + support also delivery of EMS or SMS message content to a recipient + that is receiving a Multimedia Message, whilst a service supporting + EMS can also deliver SMS message content to a recipient that can + accept receipt of EMS Messages. + + Thus, even if a client wants only to generate and send content that + could be carried in an SMS message, the client MAY choose to consider + also NAPTRs holding EMS and/or MMS Enumservices, as these indicate + that the destination can accept EMS and/or MMS messages. These + services will be able to deliver SMS content to the recipient + address. + + Conversely, a client capable of sending MMS messages may choose to + consider also NAPTRs indicating support for EMS or SMS messages + (assuming that the network to which it is connected provides these + services as well, or is capable of providing a gateway to systems + + + +Brandner, et al. Standards Track [Page 5] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + + that do provide these services). In taking this choice, it would + have to "downgrade" its User Interface to allow only generation of + content that conforms to SMS or EMS standards. + + These behaviours on the part of the client are purely optional and + are NOT the subject of any protocol standardisation. + +5.2. SMS Service Registrations + +5.2.1. SMS Service Registration with tel: URI + + Enumservice Name: "sms" + + Enumservice Type: "sms" + + Enumservice Subtypes: "tel" + + URI Scheme: 'tel:' + + Functional Specification: + + This Enumservice indicates that the resource identified by the + associated URI scheme is capable of receiving a message using the + Short Message Service (SMS) [14]. + + Security Considerations: + + There are no specific security issues with this Enumservice. + However, the general considerations of Section 6 apply. + + Intended Usage: COMMON + + Authors: + + Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author + contact detail, see Authors' Addresses section) + + Any other information the author deems interesting: + + None + +5.2.2. SMS Service Registration with mailto: URI + + Enumservice Name: "sms" + + Enumservice Type: "sms" + + Enumservice Subtypes: "mailto" + + + +Brandner, et al. Standards Track [Page 6] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + + URI Scheme: 'mailto:' + + Functional Specification: + + This Enumservice indicates that the resource identified by the + associated URI scheme is capable of receiving a message using an + email protocol. + + SMS content is sent over SMTP using the format specified by TS + 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4, as an MMS + message. Within such a message, SMS content is carried as either + a text or application/octet-stream MIME sub-part (see TS 26.140 + [16] Section 4.1). + + Security Considerations: + + There are no specific security issues with this Enumservice. + However, the general considerations of Section 6 apply. + + Intended Usage: COMMON + + Authors: + + Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author + contact detail, see Authors' Addresses section) + + Any other information the author deems interesting: + + None + +5.3. EMS Service Registrations + +5.3.1. EMS Service Registration with tel: URI + + Enumservice Name: "ems" + + Enumservice Type: "ems" + + Enumservice Subtype: "tel" + + URI Scheme: 'tel:' + + Functional Specification: + + This Enumservice indicates that the resource identified by the + associated URI scheme is capable of receiving a message using the + Enhanced Message Service (EMS) [14]. + + + + +Brandner, et al. Standards Track [Page 7] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + + Security Considerations: + + There are no specific security issues with this Enumservice. + However, the general considerations of Section 6 apply. + + Intended Usage: COMMON + + Authors: + + Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author + contact detail, see Authors' Addresses section) + + Any other information the author deems interesting: + + Note that an indication of EMS can be taken as implying that the + recipient is capable of receiving SMS messages at this address as + well. + +5.3.2. EMS Service Registration with mailto: URI + + Enumservice Name: "ems" + + Enumservice Type: "ems" + + Enumservice Subtypes: "mailto" + + URI Scheme: 'mailto:' + + Functional Specification: + + This Enumservice indicates that the resource identified by the + associated URI scheme is capable of receiving a message using an + email protocol. + + EMS content is sent over SMTP using the format specified by TS + 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4, as an MMS + message. Within such a message, EMS content is carried as either + a text or application/octet-stream MIME sub-part (see TS 26.140 + [16] section 4.1). + + Security Considerations: + + There are no specific security issues with this Enumservice. + However, the general considerations of Section 6 apply. + + Intended Usage: COMMON + + + + + +Brandner, et al. Standards Track [Page 8] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + + Authors: + + Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author + contact detail, see Authors' Addresses section) + + Any other information the author deems interesting: + + None + +5.4. MMS Service Registrations + +5.4.1. MMS Service Registration with tel: URI + + Enumservice Name: "mms" + + Enumservice Type: "mms" + + Enumservice Subtype: "tel" + + URI Scheme: 'tel:' + + Functional Specification: + + This Enumservice indicates that the resource identified by the + associated URI scheme is capable of receiving a message using the + Multimedia Messaging Service (MMS) [15]. + + Security Considerations: + + There are no specific security issues with this Enumservice. + However, the general considerations of Section 6 apply. + + Intended Usage: COMMON + + Authors: + + Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author + contact detail, see Authors' Addresses section) + + Any other information the author deems interesting: + + Note that MMS can be used as an alternative to deliver an SMS + RP-DATA RPDU if, for example, the SMS bearer is not supported. If + an entry includes this Enumservice, then in effect this can be + taken as implying that the recipient is capable of receiving EMS + or SMS messages at this address. Such choices on the end system + design do have two small caveats; whilst in practice all terminals + + + + +Brandner, et al. Standards Track [Page 9] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + + supporting MMS today support SMS as well, it might not necessarily + be the case in the future, and there may be tariff differences in + using the MMS rather than using the SMS or EMS. + +5.4.2. MMS Service Registration with mailto: URI + + Enumservice Name: "mms" + + Enumservice Type: "mms" + + Enumservice Subtypes: "mailto" + + URI Scheme: 'mailto:' + + Functional Specification: + + This Enumservice indicates that the resource identified by the + associated URI scheme is capable of receiving a message using an + email protocol. + + MMS messages are sent over SMTP using the format specified by TS + 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4. + + Within and between MMS Environments (MMSE, network infrastructures + that support the MultiMedia Service), other pieces of state data + (for example, charging-significant information) are exchanged + between MMS Relay Servers. Thus, although these servers use SMTP + as the "bearer" for their application exchanges, they map their + internal state to specialised headers carried in the SMTP message + exchanges. The headers used in such MMSE are described in detail + in [17]. + + Security Considerations: + + There are no specific security issues with this Enumservice. + However, the general considerations of Section 6 apply. + + Intended Usage: COMMON + + Authors: + + Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author + contact detail see Authors' Addresses section) + + Any other information the author deems interesting: + + The MMS Architecture describes an interface between the MMSE and + "legacy messaging systems" (labelled as MM3) that accepts + + + +Brandner, et al. Standards Track [Page 10] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + + "standard" SMTP messages. Thus, although the MMS Relay Server + that supports this interface appears as a standard SMTP server + from the perspective of an Internet-based mail server, it acts as + a gateway and translator, adding the internal state data that is + used within and between the MMS Environments. This mechanism is + described in [17], which also includes references to the + specifications agreed by those bodies responsible for the design + of the MMS. + +6. Security Considerations + + DNS, as used by ENUM, is a global, distributed database. Thus, any + information stored there is visible to anyone anonymously. Whilst + this is not qualitatively different from publication in a Telephone + Directory, it does open data subjects to having "their" information + collected automatically without any indication that this has been + done or by whom. + + Such data harvesting by third parties is often used to generate lists + of targets for unrequested information; in short, they are used to + address "spam". Anyone who uses a Web-archived mailing list is aware + that the volume of "spam" email they are sent increases when they + post to the mailing list. Publication of a telephone number in ENUM + is no different, and may be used to send "junk faxes" or "junk SMS", + for example. + + Many mailing list users have more than one email address and use + "sacrificial" email accounts when posting to such lists to help + filter out unrequested emails sent to them. This is not so easy with + published telephone numbers; the PSTN E.164 number assignment process + is much more involved, and usually a single E.164 number (or a fixed + range of numbers) is associated with each PSTN access. Thus, + providing a "sacrificial" phone number in any publication is not + possible. + + Due to the implications of publishing data on a globally accessible + database, as a principle, data subjects MUST give their explicit + informed consent to data being published in ENUM. + + In addition, they should be made aware that, due to storage of such + data during harvesting by third parties, removal of the data from + publication will not remove any copies that have been taken; in + effect, any publication may be permanent. + + However, regulations in many regions will require that data subjects + can at any time request that the data is removed from publication and + that their consent for its publication is explicitly confirmed at + regular intervals. + + + +Brandner, et al. Standards Track [Page 11] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + + When placing a fax call via the PSTN or a sending a message via the + Public Land Mobile Network, the sender may be charged for this + action. In both kinds of network, calling or messaging to some + numbers is more expensive than sending to others; both networks have + "premium rate" services that can charge considerably more than a + "normal" call or message destination. As such, it is important that + end-users be asked to confirm sending the message and that the + destination number be presented to them. It is the originating + user's choice on whether or not to send a message to this destination + number, but end-users SHOULD be shown the destination number so that + they can make this decision. + + Although a fax number, like other E.164 numbers, doesn't appear to + reveal as much identity information about a user as a name in the + format user@host (e.g., an email or SIP address), the information is + still publicly available; thus, there is still the risk of unwanted + communication. + + An analysis of threats specific to the dependence of ENUM on the DNS, + and the applicability of DNSSEC [18] to these, is provided in RFC + 3761 [2]. A thorough analysis of threats to the DNS itself is + covered in RFC 3833 [19]. + + An email address is a canonical address by which a user is known. + Placing this address in ENUM is comparable to placing a SIP or H.323 + address in the DNS. + + DNS does not make any policy decisions about the records that it + shares with an inquirer. All DNS records must be assumed to be + available to all inquirers at all times. The information provided + within an ENUM NAPTR resource record must, therefore, be considered + to be open to the public, which is a cause for some privacy + considerations. + + Therefore, ENUM Subscribers should be made aware of this risk. Since + it is within the responsibility of the ENUM Subscriber which data is + entered in ENUM, it is within the ENUM Subscriber's control if he + enters email addresses: + + 1. allowing inference of private data, e.g., his first and last name + 2. at all + + It should also be considered that it is the purpose of public + communication identifiers to be publicly known. To reduce spam and + other unwanted communication, other means should be made available, + such as incoming message filtering. + + + + + +Brandner, et al. Standards Track [Page 12] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + + Some Value Added Service Providers use receipt of a short message to + a given special service telephone number as a trigger to start + delivery of data messages to the calling number. By sending an SMS + (or, in principle, an EMS or MMS) to one of these special service + numbers, one is entering into a contract to pay for receipt of a set + of messages containing information (e.g., news, sports results, "ring + tones"). + + Thus, it is very important that the end terminal presents the + destination number to which any message is to be sent using the "sms: + tel", "ems:tel", or "mms:tel" Enumservices, to allow the end-user to + cancel any message before it is sent to one of these numbers. + + At present, these systems use the circuit switched network trusted + calling line identifier to identify the destination for the + subsequent charged information messages, and so it is believed that + sending using the "sms:mailto", "ems:mailto", or "mms:mailto" + Enumservices does not have this risk currently. + +7. Acknowledgements + + Many thanks to Ville Warsta for his close reading of the document and + extracting the right references. Thanks also to those who are + involved in the parallel effort to specify the requirements for "real + world" ENUM trials resulting in TS 102 172 [20], in which this and + other Enumservices are referenced. + +8. References + +8.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, BCP 14, March 1997. + + [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource + Identifiers (URI) Dynamic Delegation Discovery System (DDDS) + Application (ENUM)", RFC 3761, April 2004. + + [3] ITU-T, "The International Public Telecommunication Number + Plan", Recommendation E.164, May 1997. + + [4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", + RFC 1034, November 1987. + + [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Three: The Domain Name System (DNS) Database", RFC 3403, + October 2002. + + + + +Brandner, et al. Standards Track [Page 13] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + + [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + One: The Comprehensive DDDS", RFC 3401, October 2002. + + [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Two: The Algorithm", RFC 3402, October 2002. + + [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Four: The Uniform Resource Identifiers (URI)", RFC 3404, + October 2002. + + [9] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002. + + [10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, + December 2004. + + [11] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL + scheme", RFC 2368, July 1998. + + [12] ITU-T, "Standardization of Group 3 facsimile terminals for + document transmission", Recommendation T.4, April 1999. + + [13] ITU-T, "Procedures for document facsimile transmission in the + general switched telephone network", Recommendation T.30, + April 1999. + + [14] 3GPP, "Technical realization of the Short Message Service + (SMS); (Release5)", 3GPP TS 23.040. + + [15] 3GPP, "Multimedia Messaging Service (MMS); Functional + description; Stage 2 (Release 5)", 3GPP TS 23.140. + + [16] 3GPP, "Multimedia Messaging Service (MMS); Media formats and + codecs; (Release 5)", 3GPP TS 26.140. + + [17] Gellens, R., "Mapping Between the Multimedia Messaging Service + (MMS) and Internet Mail", RFC 4356, January 2006. + +8.2. Informative References + + [18] Arends, R. and et al. , "Protocol Modifications for the DNS + Security Extensions", RFC 4035, March 2005. + + [19] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + + [20] ETSI, "Minimum Requirements for Interoperability of ENUM + Implementations", ETSI TS 102 172, January 2005. + + + +Brandner, et al. Standards Track [Page 14] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + +Authors' Addresses + + Rudolf Brandner + Siemens AG + Hofmannstr. 51 + 81359 Munich + Germany + + Phone: +49-89-722-51003 + EMail: rudolf.brandner@siemens.com + + + Lawrence Conroy + Siemens Roke Manor Research + Roke Manor + Romsey + United Kingdom + + Phone: +44-1794-833666 + EMail: lwc@roke.co.uk + + + Richard Stastny + Oefeg + Postbox 147 + 1103 Vienna + Austria + + Phone: +43-664-420-4100 + EMail: Richard.stastny@oefeg.at + + + + + + + + + + + + + + + + + + + + + +Brandner, et al. Standards Track [Page 15] + +RFC 4355 IANA Msg Enumservice Registrations January 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + 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. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Brandner, et al. Standards Track [Page 16] + |