[要約] RFC 5031は、緊急およびその他のよく知られたサービスのための統一資源名（URN）に関するものです。このRFCの目的は、緊急サービスや他の重要なサービスに対して一意の識別子を提供することです。
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
緊急事態およびその他の有名なサービスのためのユニフォームリソース名（URN）
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
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.
多くの通信サービスの内容は、ユーザーの場所など、コンテキストに依存します。特定される分散方法で解決できる、よく知られているコンテキスト依存サービスを許可する「サービス」のurnについて説明します。例には、緊急サービス、ディレクトリアシスタンス、およびコール前にホットラインが含まれます。
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
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.
既存の電気通信システムでは、よく知られている識別子を備えた、大規模な地理的地域全体で大まかに調整されたエンティティによって提供される多くのよく知られたコミュニケーションおよび情報サービスがあります。一部のサービスは、政府または規制された独占によって運営されており、他のサービスは競合する商業企業によって運営されています。例には、緊急サービス（北米で9-1-1、ヨーロッパで1-1-2でダイヤルすることで到達）、コミュニティサービスとボランティアの機会（米国の一部の地域で2-1-1）、電話ディレクトリ、修理サービス（米国とカナダの4-1-1および6-1-1）、政府情報サービス（米国の一部の都市で3-1-1）、弁護士紹介サービス（1-800-Lawyer）、車の道端の支援（自動車クラブ）、ピザ配達サービス。残念ながら、それらのほとんどすべては、単一の国またはおそらく北米の番号付け計画や欧州連合に属する国などのグループの範囲に限定されています。同じ識別子は、その地域以外の他の目的に使用されることがよくあり、ユーザーが母国外で生産されたデバイスを旅行または使用するときに、このようなサービスへのアクセスが困難になります。
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.
これらのサービスは、ユーザー可視識別子の長期的な安定性、基礎となるサービスの分散型管理、および明確に定義された解像度またはマッピングメカニズムによって特徴付けられます。たとえば、米国には「9-1-1」のための全国的な調整やコールセンターはありません。むしろ、さまざまな地方自治体組織が協力して、管轄区域に基づいてこのサービスを提供しています。
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.
このドキュメントでは、このドキュメントの範囲を超えた解像度プロトコルとともに、このようなグローバルで有名なサービスを定義しながら、多くのサービスを提供するエンティティ全体に実際の実装を配布できるようにするURNネームスペースを提案します。地理的地域やユーザーが選択したサービスプロバイダーによる責任を分割するなど、そのようなサービスの提供を分割する方法はたくさんあります。さらに、ユーザーはさまざまなマッピングサービスプロバイダーを選択して、地理的な場所がサービスプロバイダーにマッピングされる方法を管理することができます。
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 having special characteristics while preventing these characteristics from being accidentally invoked.
このようなサービス識別子の可用性により、最終システムは、他のネットワークエンティティに目的のサービスに関する情報を伝えることができます。たとえば、IP電話には、緊急サービスを呼び出すショートカット、アドレス帳エントリ、またはボタンの特別なセットがあります。このようなサービス識別子が発信セッション開始プロトコル（SIP）[RFC3261]メッセージに入れられると、SIPプロキシは、世界中で使用されているダイヤル文字列や緊急番号でそれらを構成することは実用的ではないため、明確に行動を起こすことができます。したがって、このようなサービス識別子は、ルーティングの決定を第三者に委任し、特定の要求を特別な特性があるとマークし、これらの特性が誤って呼び出されるのを防ぐことを可能にします。
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.
このurnは、サービスを要求または配信するために使用される特定のプロトコルとは無関係にサービスを識別します。URNは、SIP [RFC3261]要求URI、Webページ、またはマッピングプロトコルなど、一般的なURIを許可するプロトコルに表示される場合があります。
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.)
サービスURNはプロトコル要素であり、一般に人間に表示されるとは予想されていません。たとえば、発信者は、米国の緊急番号「9-1-1」にダイヤルして緊急サービスに到達することが予想されます。他の場合には、今日のホテル携帯電話で一般的な慣行と同様に、スピードダイヤルボタンがサービスを識別する場合があります。（緊急ヘルプを召喚するためのスピードダイヤルボタンは、少なくとも誤ってトリガーされる傾向があるため、少なくともモバイルデバイスでは、ほとんどの緊急サービスの専門家によって不適切と見なされます。）
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.
最終ホストのサービスダイヤル文字列またはサービス番号のサービス番号の翻訳は、このドキュメントの範囲を超えています。これらの翻訳は、おそらく発信者の位置に依存している可能性が高く、多くのものである可能性があります。つまり、いくつかのサービス番号が1つのサービスurnにマッピングされる場合があります。たとえば、旅行者向けの電話は、旅行者の家の場所と旅行者の訪問場所の両方の緊急サービス番号を認識し、同じユニバーサルサービス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.
サービスURNはルーティングできないため、SIPプロキシまたはユーザーエージェントは、SIP URLなどの場所に適したサービスプロバイダーのために、サービスURNをルーティング可能なURIに変換する必要があります。場所からサービスへの翻訳プロトコル（LOST）[LOST]は、地理的位置に基づいてURLにサービスURNをマッピングするための解像度システムとして使用されると予想されます。将来的には、このようなプロトコルがいくつかあり、おそらく異なるサービスのプロトコルが異なる場合があります。
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.
サービスは、トップレベルのサービスタイプで説明されており、セクション3で概説されているように、サービスをさらに説明するサブサービスの階層が含まれている場合があります。
We discuss alternative approaches for creating service identifiers, and why they are unsatisfactory, in Appendix A.
付録Aで、サービス識別子を作成するための代替アプローチと、それらが不十分な理由について説明します。
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].
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "RFC 2119 [RFC2119]に記載されているように解釈されます。
Terminology specific to emergency services is defined in [RFC5012].
緊急サービスに固有の用語は、[RFC5012]で定義されています。
Below, we include the registration template for the URN scheme according to RFC 3406 [RFC3406].
以下に、RFC 3406 [RFC3406]に従って、URNスキームの登録テンプレートを含めます。
Namespace ID: service
名前空間ID：サービス
Registration Information:
登録情報：
Registration version: 1
登録バージョン：1
Registration date: 2006-04-02
登録日：2006-04-02
Declared registrant of the namespace:
名前空間の登録者を宣言する：
Registering organization: IETF
登録組織：IETF
Designated contact: Henning Schulzrinne
指定された連絡先：Henning Schulzrinne
Designated contact email: hgs@cs.columbia.edu
指定された連絡先メール：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.
構文構造の宣言：urnは階層サービス識別子で構成され、一連のラベルが期間で区切られています。最も重要なラベルは最も重要なもので、「トップレベルサービス」と呼ばれ、右側の名前は「サブサービス」と呼ばれます。許容文字のセットは、ドメイン名[RFC1123]と[RFC3958]で許可されているラベルのサブセットのセットと同じです。ラベルはケースに依存しませんが、すべての低ケースで指定する必要があります。任意のサービスのurnについて、サービス識別子は右から左に削除できます。結果のurnは依然として有効であり、より一般的なサービスを参照しています。言い換えれば、サービス 'x.y.z'が存在する場合、urns 'x'および 'x.y'も有効なサービスのurnです。ABNF [RFC4234]を以下に示します。
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.
コミュニティの考慮事項：サービスURNは、さまざまなデバイスで、特にモバイルおよび遊牧民のユーザー向けに、技術ユーザーと非技術ユーザーの両方を含むインターネットユーザーの大規模な断面に関連すると考えられています。サービスURNにより、インターネットユーザーは、ユーザーの現在のコンテキスト（ユーザーの現在の場所）で特定のサービスを提供する人を手動で決定することなく、親切にサービスを特定するためにサービスを必要とする必要があります。たとえば、旅行者は、訪問した国の緊急ダイヤル文字列を知らずに、モバイルデバイスを使用して緊急サービスを要求することができます。識別子の割り当ては、IANAの考慮事項（セクション4）で説明されています。サービスURNは特定の解像度メカニズムを規定していませんが、多くの異なるエンティティが動作し、そのようなメカニズムを提供できると想定されています。
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.
名前空間の考慮事項：広く利用可能な通信および情報サービスを一意に識別する同じ必要性を提供する他のurnamepacesはないようです。現在登録されている他のほとんどの登録されているURNネームスペースとは異なり、サービスURNはドキュメントやプロトコルオブジェクト（[RFC3044]、[RFC3187]、[RFC4179]、および[RFC4195]）を識別しません。組織[RFC3043]。Tel Uris [RFC3966]は電話番号を識別しますが、一般的に特定のサービス（911や112など）が特定の地域または国に固有の数値を特定します。
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.
識別子の一意性に関する考慮事項：サービスURNは、サービス登録で指定された論理サービスを識別します（IANAの考慮事項（セクション4）を参照）。成功した場合、URNの解像度はサービスの特定のインスタンスを返します。このインスタンスは、2人のユーザーが同じ場所で同じリクエストを同時に行う場合でも異なる場合があります。ただし、URNによって特定された論理サービスは、持続的でユニークです。サービスURNは、ユニークなサービスごとにユニークでなければなりません。これは、セクション4で説明されているこの名前空間内の各サービスの登録を通じて保証されます。
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.
識別子の持続性の考慮事項：同じサービスの「サービス」urnは持続すると予想されますが、当然、特定のサービスが常にグローバルまたは常に利用可能になることを保証することはできません。
Process of identifier assignment: The process of identifier assignment is described in the IANA Considerations (Section 4).
識別子割り当てのプロセス：識別子割り当てのプロセスは、IANAの考慮事項（セクション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.
識別子解像度のプロセス：「サービス」urの単一のグローバル解像度サービスはありません。ただし、各トップレベルサービスは、そのサービスの「サービス」のurnsで使用する一連のマッピングプロトコルを提供できます。
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.
URN構文への適合：上記の「構文構造の宣言」のBNFは、このURNスキームの構文を制約します。
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.
検証メカニズム：検証は、特定の文字列が現在有効に割り当てられたuRN [RFC3406]であるかどうかを決定します。マッピングメカニズムの分散性により、すべてのサービスがどこでも利用できるわけではなく、すべてのマッピングサーバーが現在のすべてのサービス登録で構成されているわけではないため、この意味での検証は不可能です。また、マッピングメカニズムの発見メカニズムは、現在のすべてのトップレベルサービスで構成されていない場合があります。
Scope: The scope for this URN is public and global.
範囲：このurnの範囲は公開およびグローバルです。
This section registers a new URN scheme with the registration template provided in Section 3.
このセクションでは、セクション3に記載されている登録テンプレートを使用して、新しいURNスキームを登録します。
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では、新しいサービスを特定するラベルを登録する方法について詳しく説明しています。登録する最初の2つのサービスのサブサービスの説明、SOSおよびカウンセリングは、それぞれセクション4.2とセクション4.3に記載されています。最後に、セクション4.4には初期登録表が含まれています。
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
[RFC2434]で「Service URNラベル」と呼ばれる新しいレジストリで概説されているプロセスに従って、サービスとサブサービスは、IANAが管理するラベルによって識別されます。したがって、新しいサービスを作成するには、IANAアクションが必要です。トップレベルのサービスラベルを追加するためのポリシーは次のとおりです
'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.
「標準アクション」。（このドキュメントでは、トップレベルのサービス「SOS」と「カウンセリング」を定義しています。）サブサービスにラベルを割り当てるためのポリシーは、各トップレベルのサービス指定に対して異なる場合があり、トップレベルのサービスを説明するドキュメントで定義する必要があります。
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.
S-NAPTR [RFC3958]の制約内での使用を許可するには、すべてのトップレベルのサービス名が27文字を超えてはなりません。
This section defines the first service registration within the IANA registry defined in Section 4.1, using the top-level service label 'sos'.
このセクションでは、トップレベルのサービスラベル「SOS」を使用して、セクション4.1で定義されているIANAレジストリ内の最初のサービス登録を定義します。
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.
「SOS」サービスタイプは、通常、政府または他の公的機関のさまざまな支店によって提供される即時の対応を必要とする緊急サービスを説明しています。専門家のレビュー後に追加のサブサービスを追加でき、一般的な公益であり、同様の緊急性を持つ必要があります。専門家は、Ecritワーキンググループ、その後継者、またはIESGの不在で指定されています。専門家のレビューでは、さまざまな国で広く提供されている緊急サービスのみを承認する必要があります。「SOS」サービスは、一般政府、公開情報、カウンセリング、または社会サービスを呼び出すことを意図したものではありません。
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：サービス：SOSジェネリック「SOS」サービスは、公共の安全留守ポイント（PSAP）に到達します。以下にリストされているすべてのサービスが含まれます。
urn:service:sos.ambulance This service identifier reaches an ambulance service that provides emergency medical assistance and transportation.
urn：サービス：sos.ambulanceこのサービス識別子は、救急医療支援と輸送を提供する救急車サービスに到達します。
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.
URN：サービス：SOS.Animal-Control動物管理は通常、動物の制御と管理に関する法律と条例を実施し、動物虐待のケースを調査し、責任あるペットの所有権と野生生物ケアのコミュニティを教育し、ホームレス動物の住宅とケアを提供する、他の動物関連サービスの中でも。
urn:service:sos.fire The 'fire' service identifier summons the fire service, also known as the fire brigade or fire department.
urn：サービス：Sos.Fire 'fire'サービス識別子は、消防隊または消防署としても知られる消防隊を召喚します。
urn:service:sos.gas The 'gas' service allows the reporting of natural gas (and other flammable gas) leaks or other natural gas emergencies.
URN：サービス：SOS.GAS「ガス」サービスにより、天然ガス（およびその他の可燃性ガス）漏れやその他の天然ガスの緊急事態の報告が可能になります。
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：サービス：Sos.Marine「Marine」サービスとは、沿岸警備隊、救命艇、サーフライフセーバーが提供するような海上捜索救助サービスを指します。
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：サービス：sos.mountain 'Mountain' Serviceとは、山の救助サービス（つまり、山岳環境で発生する捜索救助活動）を指しますが、この用語は他の荒野環境での捜索と救助に適用するためにも使用されることがあります。
urn:service:sos.physician The 'physician' emergency service connects the caller to a physician referral service.
urn：サービス：sos.physician「医師」の緊急サービスは、発信者を医師の紹介サービスに結び付けます。
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：サービス：sos.poison 'poison' serviceとは、潜在的な中毒に対応する方法について市民に知らせるために設定された特別な情報センターを指します。これらの毒物管理センターは、毒物と適切な緊急治療のデータベースを維持しています。
urn:service:sos.police The 'police' service refers to the police department or other law enforcement authorities.
URN：サービス：sos.police「警察」サービスとは、警察署または他の法執行機関を指します。
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.
「カウンセリング」サービスタイプは、発信者が多くの場合匿名でアドバイスやサポートを受け取ることができるサービスを説明していますが、緊急対応は必要ありません。（当然、そのようなサービスは、状況が保証された場合、発信者を緊急サービスに転送するか、そのようなサービスを召喚する場合があります。）専門家のレビュー後に追加のサブサービスを追加でき、一般的な公益である必要があります。専門家は、「SOS」サービスで説明されているのと同じ方法で選択されます。専門家のレビューでは、これらのサービスが広く、さまざまな国で提供されているかどうかを考慮に入れる必要があります。
urn:service:counseling The generic 'counseling' service reaches a call center that transfers the caller based on his or her specific needs.
urn：サービス：一般的な「カウンセリング」サービスのカウンセリングは、特定のニーズに基づいて発信者を転送するコールセンターに到達します。
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：サービス：カウンセリング。学童「子供」サービスとは、子供のニーズに合わせて特別に調整されたカウンセリングとサポートサービスを指します。このようなサービスは、たとえば、児童虐待の暴走または被害者へのアドバイスを提供する場合があります。
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：urn：counseling.mental-health「精神衛生」サービスとは、「診断、治療、および予防ケアを指します。これは、精神疾患のある人が肉体的および感情的にどのように感じるか、そして他の人との対話方法を改善するのに役立つ」。（米国保健福祉省）
urn:service:counseling.suicide The 'suicide' service refers to the suicide prevention hotline.
urn：service：counsiling.suicide '' suicide 'serviceは、自殺予防ホットラインを指します。
The following table contains the initial IANA registration for emergency and counseling services.
次の表には、緊急およびカウンセリングサービスの最初のIANA登録が含まれています。
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
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.
サービスラベルはプロトコル要素[RFC3536]であり、通常はユーザーには見られません。したがって、セクション3で説明されているように、これらの要素の文字セットは制限されています。
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.
識別子として、サービスURNは特定のセキュリティの問題を提起するようには見えません。urnによって説明されているサービスは、特定のサービスインスタンスがアクセス制御されていても、よく知られることを意図しているため、プライバシーの考慮事項は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.
たとえば、WebページにサービスURNを含める場合、特定のプライバシーの問題はない可能性があります。一方、シグナリングプロトコルでurnをフェリーすると、攻撃者が呼び出し元が望むサービスの種類に関する情報を提供できます。たとえば、これにより、攻撃者は緊急サービスまたはディレクトリ支援のすべての呼び出しを自動的に見つけやすくなります。適切なプロトコル固有のセキュリティメカニズムは、サービスのurnを運ぶプロトコルに実装する必要があります。マッピングプロトコルは、[RFC5069]で詳述されているように、多くの脅威に対処する必要があります。このドキュメントでは、緊急サービスへのサービスURNの使用に関するセキュリティ上の考慮事項についても説明しています。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[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.
[RFC3958] Daigle、L。およびA. Newton、「SRV RRSを使用したドメインベースのアプリケーションサービスの場所（DDDS）」、RFC 3958、2005年1月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[LOST] Hardie, T., "LoST: A Location-to-Service Translation Protocol", Work in Progress, March 2007.
[Lost] Hardie、T。、「Lost：A Location-s-Service Translation Protocol」、2007年3月、進行中の作業。
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997.
[RFC2142] Crocker、D。、「一般的なサービス、役割、機能のメールボックス名」、RFC 2142、1997年5月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[RFC3043] Mealling, M., "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations", RFC 3043, January 2001.
[RFC3043] Mealling、M。、「ネットワークソリューションパーソナルインターネット名（PIN）：人と組織向けのURNネームスペース」、RFC 3043、2001年1月。
[RFC3044] Rozenfeld, S., "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, January 2001.
[RFC3044] Rozenfeld、S。、「ISSN（国際シリアル標準番号）をISSN-urnネームスペース内のURN（ユニフォームリソース名）として使用する」、RFC 3044、2001年1月。
[RFC3187] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001.
[RFC3187] Hakala、J。およびH. Walravens、「国際標準の帳簿番号をユニフォームリソース名として使用」、RFC 3187、2001年10月。
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
[RFC3406] Daigle、L.、Van Gulik、D.、Iannella、R。、およびP. Faltstrom、「ユニフォームリソース名（URN）名前空間定義メカニズム」、BCP 66、RFC 3406、2002年10月。
[RFC3536] Hoffman, P., "Terminology Used in Internationalization in the IETF", RFC 3536, May 2003.
[RFC3536] Hoffman、P。、「IETFの国際化で使用される用語」、RFC 3536、2003年5月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinne、H。、「電話番号のTel URI」、RFC 3966、2004年12月。
[RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code", RFC 4152, August 2005.
[RFC4152] Tesink、K。およびR. Fox、「共通言語機器識別子（CLEI）コードのユニフォームリソース名（URN）名前空間」、RFC 4152、2005年8月。
[RFC4179] Kang, S., "Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)", RFC 4179, October 2005.
[RFC4179] Kang、S。、「ユニバーサルコンテンツ識別子（UCI）をユニフォームリソース名（URN）として使用する」、RFC 4179、2005年10月。
[RFC4195] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum", RFC 4195, October 2005.
[RFC4195] Kameyama、W。、「TV-Anytimeフォーラムのユニフォームリソース名（URN）名前空間」、RFC 4195、2005年10月。
[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[RFC5012] Schulzrinne、H。およびR. Marshall、ed。、「インターネットテクノロジーとの緊急コンテキスト解決の要件」、RFC 5012、2008年1月。
[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.
[RFC5069] Taylor、T.、Ed。、Tschofenig、H.、Schulzrinne、H。、およびM. Shanmugam、「緊急コールマーキングとマッピングのセキュリティの脅威と要件」、RFC 5069、2008年1月。
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：nnn; context = cこのアプローチはTel Uris [RFC3966]を使用します。ここでは、NNNは国家の緊急電話番号であり、国はContext Cによって特定されます。このアプローチはユーザーエージェントが実装するのが簡単ですが、すべての番号について知る必要があるため、プロキシやその他のSIP要素が認識するのは難しいです。世界のコンテキストの組み合わせと時折の変化を追跡します。さらに、これらの数値の多くは他のサービスに使用されています。たとえば、Paraguay（00）の緊急電話番号は、米国の国際オペレーターを呼び出すためにも使用されます。別の例として、イタリアなどの多くの国では、118を緊急番号として使用していますが、フィンランドのディレクトリ支援にも接続しています。
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.
Tel：SOSこのソリューションは名前の競合を回避しますが、「Tel "URI" Tel "[RFC3966]を拡張する必要があります。また、すべてのアウトバウンドプロキシが、Tel URIが宛先サーバーを識別しないため、緊急サービスに到達できるプロキシにリクエストをルーティングする方法を知っている場合にのみ機能します。
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：SOS@ドメイン以前の作業は、SIP URIの発信者のホームドメイン内で、SIP：sos@example.comの特別なユーザー識別子SOSを定義していました。このようなユーザー識別子は、RFC 2142 [RFC2142]およびRFC 2822 [RFC2822]に文書化された「ポストマスター」条約の条約に従います。このアプローチには、既存のユーザーエージェントのダイヤルプランをおそらく変換してそのようなURIを生成できるという利点があり、ドメインのホームプロキシのみがユーザーネーミング条約を理解する必要があるということです。ただし、URIのユーザー部分に不透明ではなく特定のセマンティクスでユーザー部分を過負荷にし、アウトバウンドプロキシによるルーティングを、通常のSIPリクエスト-RI処理ルールに準拠せず、SIP固有の特別なケースにします。また、メカニズムは他のサービスに容易に拡張されません。
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 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.
SIP URIユーザーパラメーター：「aor-domain; user = sos」などの特別なURIを作成できます。これにより、名前の競合の問題が回避されますが、この特別なURIを放出できるメカニズムを意識するユーザーエージェントが必要です。また、「ユーザー」パラメーターは、SIP URIのユーザー部分の形式を記述することを目的としていますが、この使用は行われません。他のパラメーターを追加すると、URLのユーザーとドメインの一部に規則を使用する必要がある場合は、まだ不明確です。どちらのソリューションも、既存のクライアントと後方互換性がある可能性があります。
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.
特別なドメイン：「sip：fire@sos.int」などの特別なドメインを使用して、緊急通話を識別できます。これには、「Tel：sos」URIと同様の特性がありますが、実際に有効なURIであることを除いて。これを使用できるようにするには、特別なドメインが動作し、適切な緊急サービスプロキシを指す必要があります。全世界に単一の論理的な緊急サービスプロキシを持つことは、望ましくないスケーリングおよび管理プロパティを持っているようです。
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
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク、ニューヨーク10027米国
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78および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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。