Movatterモバイル変換

Network Working Group                                     H. SchulzrinneRequest for Comments: 5031                                   Columbia U.Category: Standards Track                                   January 2008A Uniform Resource Name (URN) forEmergency and Other Well-Known ServicesStatus 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.Abstract   The content of many communication services depends on the context,   such as the user's location.  We describe a 'service' URN that allows   well-known context-dependent services that can be resolved in a   distributed manner to be identified.  Examples include emergency   services, directory assistance, and call-before-you-dig hot lines.Table of Contents1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .22.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .43.  Registration Template  . . . . . . . . . . . . . . . . . . . .44.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .64.1.  New Service-Identifying Labels . . . . . . . . . . . . . .64.2.  Sub-Services for the 'sos' Service . . . . . . . . . . . .74.3.  Sub-Services for the 'counseling' Service  . . . . . . . .84.4.  Initial IANA Registration  . . . . . . . . . . . . . . . .95.  Internationalization Considerations  . . . . . . . . . . . . .96.  Security Considerations  . . . . . . . . . . . . . . . . . . .107.  References . . . . . . . . . . . . . . . . . . . . . . . . . .107.1.  Normative References . . . . . . . . . . . . . . . . . . .107.2.  Informative References . . . . . . . . . . . . . . . . . .11Appendix A.  Alternative Approaches Considered . . . . . . . . . .13Appendix B.  Acknowledgments . . . . . . . . . . . . . . . . . . .14Schulzrinne                 Standards Track                     [Page 1]

RFC 5031                      Service URN                   January 20081.  Introduction   In existing telecommunications systems, there are many well-known   communication and information services that are offered by loosely   coordinated entities across a large geographic region, with well-   known identifiers.  Some of the services are operated by governments   or regulated monopolies, others by competing commercial enterprises.   Examples include emergency services (reached by dialing 9-1-1 in   North America, 1-1-2 in Europe), community services and volunteer   opportunities (2-1-1 in some regions of the United States), telephone   directory and repair services (4-1-1 and 6-1-1 in the United States   and Canada), government information services (3-1-1 in some cities in   the United States), lawyer referral services (1-800-LAWYER), car   roadside assistance (automobile clubs), and pizza delivery services.   Unfortunately, almost all of them are limited in scope to a single   country or possibly a group of countries, such as those belonging to   the North American Numbering Plan or the European Union.  The same   identifiers are often used for other purposes outside that region,   making access to such services difficult when users travel or use   devices produced outside their home country.   These services are characterized by long-term stability of user-   visible identifiers, decentralized administration of the underlying   service, and a well-defined resolution or mapping mechanism.  For   example, there is no national coordination or call center for "9-1-1"   in the United States; rather, various local government organizations   cooperate to provide this service based on jurisdictions.   In this document, we propose a URN namespace that, together with   resolution protocols beyond the scope of this document, allows us to   define such global, well-known services, while distributing the   actual implementation across a large number of service-providing   entities.  There are many ways to divide provision of such services,   such as dividing responsibility by geographic region or by the   service provider a user chooses.  In addition, users can choose   different mapping service providers that in turn manage how   geographic locations are mapped to service providers.   Availability of such service identifiers allows end systems to convey   information about the desired service to other network entities.  For   example, an IP phone could have a special set of short cuts, address   book entries, or buttons that invoke emergency services.  When such a   service identifier is put into the outgoing Session Initiation   Protocol (SIP) [RFC3261] message, it allows SIP proxies to   unambiguously take actions, as it would not be practical to configure   them with dial strings and emergency numbers used throughout the   world.  Hence, such service identifiers make it possible to delegate   routing decisions to third parties and to mark certain requests asSchulzrinne                 Standards Track                     [Page 2]

RFC 5031                      Service URN                   January 2008   having special characteristics while preventing these characteristics   from being accidentally invoked.   This URN identifies services independent of the particular protocol   that is used to request or deliver the service.  The URN may appear   in protocols that allow general URIs, such as the SIP [RFC3261]   request URIs, web pages, or mapping protocols.   The service URN is a protocol element and is generally not expected   to be visible to humans.  For example, it is expected that callers   will still dial the emergency number '9-1-1' in the United States to   reach emergency services.  In some other cases, speed dial buttons   might identify the service, as is common practice on hotel phones   today.  (Speed dial buttons for summoning emergency help are   considered inappropriate by most emergency services professionals, at   least for mobile devices, as they are too prone to being triggered   accidentally.)   The translation of service dial strings or service numbers to service   URNs in the end host is beyond the scope of this document.  These   translations likely depend on the location of the caller and may be   many-to-one, i.e., several service numbers may map to one service   URN.  For example, a phone for a traveler could recognize the   emergency service number for both the traveler's home location and   the traveler's visited location, mapping both to the same universal   service URN, urn:service:sos.   Since service URNs are not routable, a SIP proxy or user agent has to   translate the service URN into a routable URI for a location-   appropriate service provider, such as a SIP URL.  A Location-to-   Service Translation Protocol (LoST) [LOST] is expected to be used as   a resolution system for mapping service URNs to URLs based on   geographic location.  In the future, there may be several such   protocols, possibly different ones for different services.   Services are described by top-level service type, and may contain a   hierarchy of sub-services that further describe the service, as   outlined inSection 3.   We discuss alternative approaches for creating service identifiers,   and why they are unsatisfactory, inAppendix A.Schulzrinne                 Standards Track                     [Page 3]

RFC 5031                      Service URN                   January 20082.  Terminology   In this document, the key words "MUST", "MUST NOT", "REQUIRED",   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",   and "OPTIONAL" are to be interpreted as described inRFC 2119   [RFC2119].   Terminology specific to emergency services is defined in [RFC5012].3.  Registration Template   Below, we include the registration template for the URN scheme   according toRFC 3406 [RFC3406].   Namespace ID:  service   Registration Information:      Registration version:  1      Registration date:  2006-04-02   Declared registrant of the namespace:      Registering organization:  IETF      Designated contact:  Henning Schulzrinne      Designated contact email:  hgs@cs.columbia.edu   Declaration of syntactic structure:  The URN consists of a      hierarchical service identifier, with a sequence of labels      separated by periods.  The left-most label is the most significant      one and is called 'top-level service', while names to the right      are called 'sub-services'.  The set of allowable characters is the      same as that for domain names [RFC1123] and a subset of the labels      allowed in [RFC3958].  Labels are case-insensitive, but MUST be      specified in all lower-case.  For any given service URN, service-      identifiers can be removed right-to-left; the resulting URN is      still valid, referring to a more generic service.  In other words,      if a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid      service URNs.  The ABNF [RFC4234] is shown below.Schulzrinne                 Standards Track                     [Page 4]

RFC 5031                      Service URN                   January 2008     service-URN  = "URN:service:" service     service      = top-level *("." sub-service)     top-level    = let-dig [ *25let-dig-hyp let-dig ]     sub-service  = let-dig [ *let-dig-hyp let-dig ]     let-dig-hyp  = let-dig / "-"     let-dig      = ALPHA / DIGIT     ALPHA        = %x41-5A / %x61-7A   ; A-Z / a-z     DIGIT        = %x30-39 ; 0-9   Relevant ancillary documentation:  None   Community considerations:  The service URN is believed to be relevant      to a large cross-section of Internet users, including both      technical and non-technical users, on a variety of devices, but      particularly for mobile and nomadic users.  The service URN will      allow Internet users needing services to identify the service by      kind, without having to determine manually who provides the      particular service in the user's current context, e.g., at the      user's current location.  For example, travelers will be able to      use their mobile devices to request emergency services without      having to know the emergency dial string of the visited country.      The assignment of identifiers is described in the IANA      Considerations (Section 4).  The service URN does not prescribe a      particular resolution mechanism, but it is assumed that a number      of different entities could operate and offer such mechanisms.   Namespace considerations:  There do not appear to be other URN      namespaces that serve the same need of uniquely identifying      widely-available communication and information services.  Unlike      most other currently registered URN namespaces, the service URN      does not identify documents and protocol objects (e.g., [RFC3044],      [RFC3187], [RFC4179], and [RFC4195]), types of telecommunications      equipment [RFC4152], people, or organizations [RFC3043].  tel URIs      [RFC3966] identify telephone numbers, but numbers commonly      identifying services (such as 911 or 112) are specific to a      particular region or country.   Identifier uniqueness considerations:  A service URN identifies a      logical service, specified in the service registration (see IANA      Considerations (Section 4)).  Resolution of the URN, if      successful, will return a particular instance of the service, and      this instance may be different even for two users making the same      request in the same place at the same time; the logical service      identified by the URN, however, is persistent and unique.  Service      URNs MUST be unique for each unique service; this is guaranteed      through the registration of each service within this namespace,      described inSection 4.Schulzrinne                 Standards Track                     [Page 5]

RFC 5031                      Service URN                   January 2008   Identifier persistence considerations:  The 'service' URN for the      same service is expected to be persistent, although there      naturally cannot be a guarantee that a particular service will      continue to be available globally or at all times.   Process of identifier assignment:  The process of identifier      assignment is described in the IANA Considerations (Section 4).   Process for identifier resolution:  There is no single global      resolution service for 'service' URNs.  However, each top-level      service can provide a set of mapping protocols to be used with      'service' URNs of that service.   Rules for lexical equivalence:  'service' identifiers are compared      according to case-insensitive string equality.   Conformance with URN syntax:  The BNF in the 'Declaration of      syntactic structure' above constrains the syntax for this URN      scheme.   Validation mechanism:  Validation determines whether a given string      is currently a validly-assigned URN [RFC3406].  Due to the      distributed nature of the mapping mechanism, and since not all      services are available everywhere and not all mapping servers may      be configured with all current service registrations, validation      in this sense is not possible.  Also, the discovery mechanism for      the mapping mechanism may not be configured with all current top-      level services.   Scope:  The scope for this URN is public and global.4.  IANA Considerations   This section registers a new URN scheme with the registration   template provided inSection 3.   Below,Section 4.1 details how to register new service-identifying   labels.  Descriptions of sub-services for the first two services to   be registered, sos and counseling, are given inSection 4.2 andSection 4.3, respectively.  Finally,Section 4.4 contains the initial   registration table.4.1.  New Service-Identifying Labels   Services and sub-services are identified by labels managed by IANA,   according to the processes outlined in [RFC2434] in a new registry   called "Service URN Labels".  Thus, creating a new service requires   IANA action.  The policy for adding top-level service labels isSchulzrinne                 Standards Track                     [Page 6]

RFC 5031                      Service URN                   January 2008   'Standards Action'.  (This document defines the top-level services   'sos' and 'counseling'.)  The policy for assigning labels to sub-   services may differ for each top-level service designation and MUST   be defined by the document describing the top-level service.   Entries in the registration table have the following format:   Service  Reference  Description   --------------------------------------------------------------------   foo      RFCxyz     Brief description of the 'foo' top-level service   foo.bar  RFCabc     Description of the 'foo.bar' service   To allow use within the constraints of S-NAPTR [RFC3958], all top-   level service names MUST NOT exceed 27 characters.4.2.  Sub-Services for the 'sos' Service   This section defines the first service registration within the IANA   registry defined inSection 4.1, using the top-level service label   'sos'.   The 'sos' service type describes emergency services requiring an   immediate response, typically offered by various branches of the   government or other public institutions.  Additional sub-services can   be added after expert review and must be of general public interest   and have a similar emergency nature.  The expert is designated by the   ECRIT working group, its successor, or, in their absence, the IESG.   The expert review should only approve emergency services that are   offered widely and in different countries, with approximately the   same caller expectation in terms of services rendered.  The 'sos'   service is not meant to invoke general government, public   information, counseling, or social services.   urn:service:sos  The generic 'sos' service reaches a public safety      answering point (PSAP), which in turn dispatches aid appropriate      to the emergency.  It encompasses all of the services listed      below.   urn:service:sos.ambulance  This service identifier reaches an      ambulance service that provides emergency medical assistance and      transportation.   urn:service:sos.animal-control  Animal control typically enforces      laws and ordinances pertaining to animal control and management,      investigates cases of animal abuse, educates the community in      responsible pet ownership and wildlife care, and provides for the      housing and care of homeless animals, among other animal-related      services.Schulzrinne                 Standards Track                     [Page 7]

RFC 5031                      Service URN                   January 2008   urn:service:sos.fire  The 'fire' service identifier summons the fire      service, also known as the fire brigade or fire department.   urn:service:sos.gas  The 'gas' service allows the reporting of      natural gas (and other flammable gas) leaks or other natural gas      emergencies.   urn:service:sos.marine  The 'marine' service refers to maritime      search and rescue services such as those offered by the coast      guard, lifeboat, or surf lifesavers.   urn:service:sos.mountain  The 'mountain' service refers to mountain      rescue services (i.e., search and rescue activities that occur in      a mountainous environment), although the term is sometimes also      used to apply to search and rescue in other wilderness      environments.   urn:service:sos.physician  The 'physician' emergency service connects      the caller to a physician referral service.   urn:service:sos.poison  The 'poison' service refers to special      information centers set up to inform citizens about how to respond      to potential poisoning.  These poison control centers maintain a      database of poisons and appropriate emergency treatment.   urn:service:sos.police  The 'police' service refers to the police      department or other law enforcement authorities.4.3.  Sub-Services for the 'counseling' Service   The 'counseling' service type describes services where callers can   receive advice and support, often anonymous, but not requiring an   emergency response.  (Naturally, such services may transfer callers   to an emergency service or summon such services if the situation   warrants.)  Additional sub-services can be added after expert review   and should be of general public interest.  The expert is chosen in   the same manner as described for the 'sos' service.  The expert   review should take into account whether these services are offered   widely and in different countries, with approximately the same caller   expectation in terms of services rendered.   urn:service:counseling  The generic 'counseling' service reaches a      call center that transfers the caller based on his or her specific      needs.Schulzrinne                 Standards Track                     [Page 8]

RFC 5031                      Service URN                   January 2008   urn:service:counseling.children  The 'children' service refers to      counseling and support services that are specifically tailored to      the needs of children.  Such services may, for example, provide      advice to run-aways or victims of child abuse.   urn:service:counseling.mental-health  The 'mental-health' service      refers to the "diagnostic, treatment, and preventive care that      helps improve how persons with mental illness feel both physically      and emotionally as well as how they interact with other persons".      (U.S. Department of Health and Human Services)   urn:service:counseling.suicide  The 'suicide' service refers to the      suicide prevention hotline.4.4.  Initial IANA Registration   The following table contains the initial IANA registration for   emergency and counseling services.   Service                   Reference  Description   --------------------------------------------------------------------   counselingRFC 5031   Counseling services   counseling.childrenRFC 5031   Counseling for children   counseling.mental-healthRFC 5031   Mental health counseling   counseling.suicideRFC 5031   Suicide prevention hotline   sosRFC 5031   Emergency services   sos.ambulanceRFC 5031   Ambulance service   sos.animal-controlRFC 5031   Animal control   sos.fireRFC 5031   Fire service   sos.gasRFC 5031   Gas leaks and gas emergencies   sos.marineRFC 5031   Maritime search and rescue   sos.mountainRFC 5031   Mountain rescue   sos.physicianRFC 5031   Physician referral service   sos.poisonRFC 5031   Poison control center   sos.policeRFC 5031   Police, law enforcement5.  Internationalization Considerations   The service labels are protocol elements [RFC3536] and are not   normally seen by users.  Thus, the character set for these elements   is restricted, as described inSection 3.Schulzrinne                 Standards Track                     [Page 9]

RFC 5031                      Service URN                   January 20086.  Security Considerations   As an identifier, the service URN does not appear to raise any   particular security issues.  The services described by the URN are   meant to be well-known, even if the particular service instance is   access-controlled, so privacy considerations do not apply to the URN.   There are likely no specific privacy issues when including a service   URN on a web page, for example.  On the other hand, ferrying the URN   in a signaling protocol can give attackers information on the kind of   service desired by the caller.  For example, this makes it easier for   the attacker to automatically find all calls for emergency services   or directory assistance.  Appropriate, protocol-specific security   mechanisms need to be implemented for protocols carrying service   URNs.  The mapping protocol needs to address a number of threats, as   detailed in [RFC5069].  That document also discusses the security   considerations related to the use of the service URN for emergency   services.7.  References7.1.  Normative References   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application              and Support", STD 3,RFC 1123, October 1989.   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119, March 1997.   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an              IANA Considerations Section in RFCs",BCP 26,RFC 2434,              October 1998.   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,              A., Peterson, J., Sparks, R., Handley, M., and E.              Schooler, "SIP: Session Initiation Protocol",RFC 3261,              June 2002.   [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application              Service Location Using SRV RRs and the Dynamic Delegation              Discovery Service (DDDS)",RFC 3958, January 2005.   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax              Specifications: ABNF",RFC 4234, October 2005.Schulzrinne                 Standards Track                    [Page 10]

RFC 5031                      Service URN                   January 20087.2.  Informative References   [LOST]     Hardie, T., "LoST: A Location-to-Service Translation              Protocol", Work in Progress, March 2007.   [RFC2142]  Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND              FUNCTIONS",RFC 2142, May 1997.   [RFC2822]  Resnick, P., "Internet Message Format",RFC 2822,              April 2001.   [RFC3043]  Mealling, M., "The Network Solutions Personal Internet              Name (PIN): A URN Namespace for People and Organizations",RFC 3043, January 2001.   [RFC3044]  Rozenfeld, S., "Using The ISSN (International Serial              Standard Number) as URN (Uniform Resource Names) within an              ISSN-URN Namespace",RFC 3044, January 2001.   [RFC3187]  Hakala, J. and H. Walravens, "Using International Standard              Book Numbers as Uniform Resource Names",RFC 3187,              October 2001.   [RFC3406]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,              "Uniform Resource Names (URN) Namespace Definition              Mechanisms",BCP 66,RFC 3406, October 2002.   [RFC3536]  Hoffman, P., "Terminology Used in Internationalization in              the IETF",RFC 3536, May 2003.   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",RFC 3966, December 2004.   [RFC4152]  Tesink, K. and R. Fox, "A Uniform Resource Name (URN)              Namespace for the Common Language Equipment Identifier              (CLEI) Code",RFC 4152, August 2005.   [RFC4179]  Kang, S., "Using Universal Content Identifier (UCI) as              Uniform Resource Names (URN)",RFC 4179, October 2005.   [RFC4195]  Kameyama, W., "A Uniform Resource Name (URN) Namespace for              the TV-Anytime Forum",RFC 4195, October 2005.   [RFC5012]  Schulzrinne, H. and R. Marshall, Ed., "Requirements for              Emergency Context Resolution with Internet Technologies",RFC 5012, January 2008.Schulzrinne                 Standards Track                    [Page 11]

RFC 5031                      Service URN                   January 2008   [RFC5069]  Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M.              Shanmugam, "Security Threats and Requirements for              Emergency Call Marking and Mapping",RFC 5069,              January 2008.Schulzrinne                 Standards Track                    [Page 12]

RFC 5031                      Service URN                   January 2008Appendix A.  Alternative Approaches Considered   The discussions of ways to identify emergency calls has yielded a   number of proposals.  Since these are occasionally brought up during   discussions, we briefly summarize why this document chose not to   pursue these solutions.   tel:NNN;context=+C  This approach uses tel URIs [RFC3966].  Here, NNN      is the national emergency number, where the country is identified      by the context C.  This approach is easy for user agents to      implement, but hard for proxies and other SIP elements to      recognize, as it would have to know about all number-context      combinations in the world and track occasional changes.  In      addition, many of these numbers are being used for other services.      For example, the emergency number in Paraguay (00) is also used to      call the international operator in the United States.  As another      example, a number of countries, such as Italy, use 118 as an      emergency number, but it also connects to directory assistance in      Finland.   tel:sos  This solution avoids name conflicts, but requires extending      the "tel" URI "tel" [RFC3966].  It also only works if every      outbound proxy knows how to route requests to a proxy that can      reach emergency services since tel URIs do not identify the      destination server.   sip:sos@domain  Earlier work had defined a special user identifier,      sos, within the caller's home domain in a SIP URI, for example,      sip:sos@example.com.  Such a user identifier follows the      convention ofRFC 2142 [RFC2142] and the "postmaster" convention      documented inRFC 2822 [RFC2822].  This approach had the advantage      that dial plans in existing user agents could probably be      converted to generate such a URI and that only the home proxy for      the domain has to understand the user naming convention.  However,      it overloads the user part of the URI with specific semantics      rather than being opaque, makes routing by the outbound proxy a      special case that does not conform to normal SIP request-URI      handling rules and is SIP-specific.  The mechanism also does not      extend readily to other services.   SIP URI user parameter:  One could create a special URI, such as      "aor-domain;user=sos".  This avoids the name conflict problem, but      requires mechanism-aware user agents that are capable of emitting      this special URI.  Also, the 'user' parameter is meant to describe      the format of the user part of the SIP URI, which this usage does      not do.  Adding other parameters still leaves unclear what, ifSchulzrinne                 Standards Track                    [Page 13]

RFC 5031                      Service URN                   January 2008      any, conventions should be used for the user and domain part of      the URL.  Neither solution is likely to be backward-compatible      with existing clients.   Special domain:  A special domain, such as "sip:fire@sos.int" could      be used to identify emergency calls.  This has similar properties      as the "tel:sos" URI, except that it is indeed a valid URI.  To      make this usable, the special domain would have to be operational      and point to an appropriate emergency services proxy.  Having a      single, if logical, emergency services proxy for the whole world      seems to have undesirable scaling and administrative properties.Appendix B.  Acknowledgments   This document is based on discussions with Jonathan Rosenberg and   benefited from the comments of Leslie Daigle, Keith Drage, Benja   Fallenstein, Paul Kyzivat, Andrew Newton, Brian Rosen, Jonathan   Rosenberg, Martin Thomson, and Hannes Tschofenig.Author's Address   Henning Schulzrinne   Columbia University   Department of Computer Science   450 Computer Science Building   New York, NY  10027   US   Phone: +1 212 939 7004   EMail: hgs+ecrit@cs.columbia.edu   URI:http://www.cs.columbia.eduSchulzrinne                 Standards Track                    [Page 14]

RFC 5031                      Service URN                   January 2008Full Copyright Statement   Copyright (C) The IETF Trust (2008).   This document is subject to the rights, licenses and restrictions   contained inBCP 78, and except as set forth therein, the authors   retain all their rights.   This document and the information contained herein are provided on an   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.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 inBCP 78 andBCP 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 athttp://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.Schulzrinne                 Standards Track                    [Page 15]