GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5031

Network Working Group H. Schulzrinne Request for Comments: 5031 Columbia U. Category: Standards Track January 2008

                 A Uniform Resource Name (URN) for
              Emergency and Other Well-Known Services

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.

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 Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
 3.  Registration Template  . . . . . . . . . . . . . . . . . . . .  4
 4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   4.1.  New Service-Identifying Labels . . . . . . . . . . . . . .  6
   4.2.  Sub-Services for the 'sos' Service . . . . . . . . . . . .  7
   4.3.  Sub-Services for the 'counseling' Service  . . . . . . . .  8
   4.4.  Initial IANA Registration  . . . . . . . . . . . . . . . .  9
 5.  Internationalization Considerations  . . . . . . . . . . . . .  9
 6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
 7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
   7.2.  Informative References . . . . . . . . . . . . . . . . . . 11
 Appendix A.  Alternative Approaches Considered . . . . . . . . . . 13
 Appendix B.  Acknowledgments . . . . . . . . . . . . . . . . . . . 14

Schulzrinne Standards Track [Page 1] RFC 5031 Service URN January 2008

1. 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 as

Schulzrinne 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 in Section 3.
 We discuss alternative approaches for creating service identifiers,
 and why they are unsatisfactory, in Appendix A.

Schulzrinne Standards Track [Page 3] RFC 5031 Service URN January 2008

2. 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 in RFC 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 to RFC 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 in Section 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 in Section 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 in Section 4.2 and
 Section 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 is

Schulzrinne 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 in Section 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
 --------------------------------------------------------------------
 counseling                RFC 5031   Counseling services
 counseling.children       RFC 5031   Counseling for children
 counseling.mental-health  RFC 5031   Mental health counseling
 counseling.suicide        RFC 5031   Suicide prevention hotline
 sos                       RFC 5031   Emergency services
 sos.ambulance             RFC 5031   Ambulance service
 sos.animal-control        RFC 5031   Animal control
 sos.fire                  RFC 5031   Fire service
 sos.gas                   RFC 5031   Gas leaks and gas emergencies
 sos.marine                RFC 5031   Maritime search and rescue
 sos.mountain              RFC 5031   Mountain rescue
 sos.physician             RFC 5031   Physician referral service
 sos.poison                RFC 5031   Poison control center
 sos.police                RFC 5031   Police, law enforcement

5. 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 in Section 3.

Schulzrinne Standards Track [Page 9] RFC 5031 Service URN January 2008

6. 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. References

7.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 2008

7.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 2008

Appendix 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 of RFC 2142 [RFC2142] and the "postmaster" convention
    documented in RFC 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, if

Schulzrinne 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.edu

Schulzrinne Standards Track [Page 14] RFC 5031 Service URN January 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 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, 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 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.

Schulzrinne Standards Track [Page 15]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5031.txt · Last modified: 2008/01/04 23:03 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki