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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（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.
既存の通信システムでは、よく知られた識別子と、大きな地理的地域全体緩く協調エンティティによって提供されている多くのよく知られた通信・情報サービスがあります。サービスの一部は、営利企業が競合することにより、政府や規制独占、他の人によって運営されています。例としては、（米国の一部の地域で2-1-1）を、コミュニティサービスやボランティアの機会を（ヨーロッパでは、1-1-2北米で9-1-1をダイヤルすることにより到達した）緊急サービス、電話帳や修理が含まれますサービス（4-1-1と6-1-1米国およびカナダでは）、政府の情報サービス（米国では、いくつかの都市で3-1-1）、弁護士紹介サービス（1-800-弁護士）、車の道端での援助（自動車クラブ）、そしてピザの配達サービス。残念ながら、ほとんどすべての単一の国またはおそらく、このような北米番号計画や欧州連合に属するものとして国のグループに範囲が限定されています。同じ識別子は、多くの場合、ユーザーが旅行や自国外に生産機器を使用する際に困難なサービスへのアクセスを作り、その領域外の他の目的に使用されています。
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を、ウェブページ、またはマッピングプロトコルなどの一般的な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.
エンドホストでのサービス壺にサービスダイヤル文字列またはサービス番号の翻訳は、このドキュメントの範囲を超えています。これらの翻訳は、おそらく、すなわち、いくつかのサービス番号は、一つのサービスURNにマッピングすることができる、発呼者の位置に依存し、多対一であってもよいです。サービス：SOSたとえば、旅行者のための電話は同じユニバーサルサービスURN、壷の両方にマッピングし、旅行者の自宅の場所や旅行者の訪問場所の両方のための緊急サービス番号を認識することができます。
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として、位置適切なサービス・プロバイダのためにルーティング可能なURIにサービスURNを変換しなければなりません。ロケーション・ツー・サービス翻訳プロトコル（LOST）[LOST]は、地理的位置に基づいて、URLへのマッピングサービス壺の解決システムとして使用されることが期待されます。将来的には、いくつかのようなプロトコル、異なるサービスのためにおそらく異なるものがあるかもしれません。
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].
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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
指定された連絡先：ヘニング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」は存在する場合は、URNの「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
サービスURN = "壷：サービス：" トップレベル=わずかなアップ[* 25let-あなた-Hypをライトアップ]サブサービス=わずかなアップサービスサービス=トップレベル*（サブサービス ""） [*簡単お-Hypをアップ簡単]光-あなた-Hypを=わずかなアップ/ " - " ライトアップ= ALPHA / DIGIT x41-5A ALPHA =％/％x61-7A。 -Z / 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.
名前空間の考慮事項：そこは一意に広く利用可能な通信および情報サービスを特定するのと同じニーズを満たす他のURN名前空間であることが表示されません。他のほとんどの現在登録されているURN名前空間とは異なり、サービスURNは（[RFC3044]、[RFC3187]、[RFC4179]、および[RFC4195]、例えば）、通信機器の種類[RFC4152]、人々、または文書やプロトコルオブジェクトを識別しません団体[RFC3043]。 TEL URIは[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.
識別子の解決のためのプロセス：「サービス」URNのための単一のグローバルな解決サービスはありません。しかし、各トップレベルのサービスは、そのサービスの「サービス」のURNで使用するマッピング・プロトコルのセットを提供することができます。
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
サービスとサブサービスは、「サービスURNラベル」と呼ばれる新しいレジストリ内の[RFC2434]に概説された方法に従って、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コントロール動物の制御は、通常、動物の制御及び管理に関する法律や条例を施行動物虐待の事例を調査し、責任あるペットの所有権と野生動物のケアにコミュニティを教育し、ホームレスの動物の住宅とケアを提供、他の動物に関連するサービスの中。
urn:service:sos.fire The 'fire' service identifier summons the fire service, also known as the fire brigade or fire department.
URN：サービス：「火」のサービス識別子はまた、消防隊や消防として知られている火災サービスを、召喚sos.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。
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は、山岳救助サービス（山岳環境で発生する、すなわち、捜索救助活動）を指します。
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。これらの毒物管理センターでは、毒と適切な応急処置のデータベースを維持します。
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：サービス：counseling.children「子供たちのサービスは、特に子供たちのニーズに合わせたカウンセリングとサポートサービスを指します。このようなサービスは、例えば、あるいは児童虐待の被害者遠かっを実行するためのアドバイスを提供することができます。
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：サービス：counseling.mental-健康メンタルヘルス」サービスが参照する「診断、治療、および精神疾患を持つ人は、彼らが他の人と対話する方法の両方の物理的および感情的に感じるだけでなく、どのように向上させることができます予防医療」 。 （保健社会福祉省、米国）
urn:service:counseling.suicide The 'suicide' service refers to the suicide prevention hotline.
URN：サービス：「自殺」サービスは、自殺予防ホットラインを指しcounseling.suicide。
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
SOSのRFC 5031の緊急サービスsos.ambulanceのRFC 5031救急車サービスsos.animal制御RFC 5031アニマル制御sos.fireのRFC 5031消防サービスsos.gas RFC 5031のガス漏れやガスの緊急事態sos.marine RFC 5031海上捜索救助のsos.mountain RFC 5031山岳救助sos.physician RFC 5031医師の紹介サービスsos.poisonのRFC 5031毒物管理センターsos.policeのRFC 5031警察、法執行機関
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.
ウェブページ上のサービスURNを含む具体的なプライバシーの問題は、例えば、可能性はありません。一方、シグナリングプロトコルでURNを運んする攻撃者に発信者が所望するサービスの種類に関する情報を与えることができます。例えば、これは、簡単に攻撃者が自動的に緊急サービスまたはディレクトリ支援のためのすべてのコールを見つけるようになります。適切には、プロトコル固有のセキュリティメカニズムは、サービスのURNを搬送するプロトコルのために実施される必要があります。 [RFC5069]に詳述されるようにマッピングプロトコルは、脅威の数に対処する必要があります。その文書には、緊急サービスのサービスURNの使用に関連するセキュリティ上の考慮事項について説明します。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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.ニュートン、RFC 3958、2005年1月 "SRVのRRを使用したアプリケーションサービスの場所とダイナミックな委譲発見サービス（DDDS）をドメインベース"。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[LOST] Hardie, T., "LoST: A Location-to-Service Translation Protocol", Work in Progress, March 2007.
[LOST]ハーディ、T.は、「失われた：場所・ツー・サービス翻訳・プロトコル」、進歩、2007年3月に仕事を。
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997.
[RFC2142]クロッカー、D.、 "COMMON SERVICES FORメールボックス名、役割・機能"、RFC 2142、1997年5月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、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.、RFC 3044、2001年1月 "ISSN-URN名前空間内のURN（ユニフォームリソース名）としてISSN（国際標準シリアルナンバー）の使用"。
[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.、バン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]ホフマン、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.フォックス、RFC 4152 "共通言語機器識別子（CLEI）コードのための統一リソース名（URN）名前空間"、2005年8月。
[RFC4179] Kang, S., "Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)", RFC 4179, October 2005.
[RFC4179]カン、S.、 "統一リソース名（URN）とユニバーサル内容識別子（UCI）の使用"、RFC 4179、2005年10月。
[RFC4195] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum", RFC 4195, October 2005.
[RFC4195]亀山、W.、 "たTV-AnytimeフォーラムのためのURN（Uniform Resource Name）の名前空間"、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.マーシャル、エド。、 "インターネット技術との緊急コンテキスト解決のための要件"、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]テイラー、T.、エド。、Tschofenig、H.、Schulzrinneと、H.、およびM・シャンミューガム、 "セキュリティの脅威と緊急マーキングコールとマッピングのための要件"、RFC 5069、2008年1月。
Appendix A. Alternative Approaches Considered
考慮付録A.代替アプローチ
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;文脈= + Cこのアプローチは、TEL URIは[RFC3966]を使用します。それはすべてのnumber-について知っなければならないだろうとここで、NNNは、国がコンテキストCでこのアプローチを識別している国家の緊急電話番号は、ユーザエージェントが実装するのは簡単ですが、プロキシおよび他のSIP要素が認識するのは難しいですコンテキストの世界での組み合わせとは時折変更を追跡します。また、これらの数値の多くは、他のサービスに使用されています。例えば、パラグアイ（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以前の仕事は特別なユーザ識別子、SOS、SIP URIで、発信者のホーム・ドメイン内で、例えば、SIP定義されていた：sos@example.comを。そのようなユーザ識別子は、RFCの慣例2142 [RFC2142]及びRFC 2822 [RFC2822]に記載され、「ポストマスター」規則に従います。このアプローチは、既存のユーザエージェントでのダイヤルプランの利点は、おそらく、そのようなURIを生成するために変換され、唯一のドメインのホームプロキシは、ユーザーの命名規則を理解しなければならないことをすることができました。しかし、特定のセマンティクスではなく、不透明なURIのユーザ部分をオーバーロード、アウトバウンドプロキシ通常のSIP要求URI処理規則に準拠し、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ドメイン;ユーザー= 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は」緊急通話を識別するために使用することができます。それは確かにある有効なURIことを除いて、URI：「SOS TEL」これは、同様の特性を持っています。これを使用可能にするには、特別なドメインは、適切な緊急サービスプロキシに運用し、ポイントでなければなりません。全世界のための単一の論理的であれば、緊急サービスプロキシを持つことは望ましくないスケーリングおよび管理の性質を持っているようです。
Appendix B. Acknowledgments
付録B.謝辞
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.
この文書では、ジョナサン・ローゼンバーグとの協議に基づいており、レスリーDaigle氏、キース糖剤、ベンジャFallenstein、ポールKyzivat、アンドリュー・ニュートン、ブライアン・ローゼン、ジョナサン・ローゼンバーグ、マーティン・トムソン、およびハンネスTschofenigのコメントの恩恵を受けています。
Author's Address
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
コンピュータサイエンス450コンピュータサイエンスビル、ニューヨーク、NY 10027米国のヘニングSchulzrinneとコロンビア大学学部
Phone: +1 212 939 7004 EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu
電話：+1 212 939 7004 Eメール：hgs+ecrit@cs.columbia.edu URI：http://www.cs.columbia.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。