RFC5031 日本語訳
5031 A Uniform Resource Name (URN) for Emergency and Other Well-KnownServices. H. Schulzrinne. January 2008. (Format: TXT=32960 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Schulzrinne Request for Comments: 5031 Columbia U. Category: Standards Track January 2008
Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 5031年のコロンビアU.カテゴリ: 標準化過程2008年1月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 登録テンプレート. . . . . . . . . . . . . . . . . . . . 4 4。 IANA問題. . . . . . . . . . . . . . . . . . . . . 6 4.1。 新しいサービスを特定するラベル. . . . . . . . . . . . . . 6 4.2。 'sos'のためのサブサービスは.74.3を修理します。 'カウンセリング'のためのサブサービスは.84.4を修理します。 IANA登録. . . . . . . . . . . . . . . . 9 5に頭文字をつけてください。 国際化問題. . . . . . . . . . . . . 9 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 10 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 10 7.2。 .13の付録B.承認. . . . . . . . . . . . . . . . . . . 14であると考えられた有益な参照. . . . . . . . . . . . . . . . . . 11付録A.代替的アプローチ
Schulzrinne Standards Track [Page 1] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[1ページ]。
1. Introduction
1. 序論
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.
既存の情報通信システムには、大きい地理的な領域の向こう側に緩く調整された実体によって提供される多くの周知のコミュニケーションと情報サービスがあります、よく知られている識別子で。 サービスのいくつかが競争している営利事業によって政府か規制された独占、他のものによって運用されます。 例が緊急サービス(ヨーロッパで北アメリカで1-1-2に9-1-1にダイヤルすることによって、達している)、ボランティア活動、およびボランティアの機会を含んでいる、(中の2-1-1、合衆国のいくつかの領域)、電話帳と修理サービス、(4-1-1、6-1-1 コネが合衆国とカナダをそうする、)、政府情報サービス、(中の3-1-1、合衆国のいくつかの都市)、弁護士紹介は(1-800-LAWYER)、車の道端での援助(自動車クラブ)、およびピザデリバリ・サービスを修理します。 残念ながら、それらのほとんどすべてが範囲で単一の国かことによると国のグループに制限されます、北米のNumbering Planかヨーロッパ連合に属すものなどのように。 同じ識別子はその領域の外の他の目的にしばしば使用されます、ユーザがそれらの自国の外で生産された装置を旅行するか、または使用するとそのようなサービスへのアクセスを難しくして。
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-11インチ、合衆国、」、。 むしろ、様々な地方自治体組織は協力して、管内に基づくこのサービスを提供します。
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
そのようなサービス識別子の有用性で、エンドシステムは他のネットワーク実体に対する必要なサービスに関して情報を伝達します。 例えば、IP電話には、緊急サービスを呼び出す特別なセットのショートカット、アドレス帳エントリー、またはボタンがあるかもしれません。 外向的なSession Initiationプロトコル(SIP)[RFC3261]メッセージにそのようなサービス識別子を入れるとき、SIPプロキシはそれで明白に行動を取ることができます、世界中で使用されるダイヤルストリングと緊急電話番号で彼らを構成するのが実用的でないだろうというときに。 したがって、そのようなサービス識別子で、それはルーティング決定を第三者へ代表として派遣して、ある要求をマークするのにおいて可能になります。
Schulzrinne Standards Track [Page 2] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[2ページ]。
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.
このURNはサービスを要求するか、または提供するのに使用される特定のプロトコルの如何にかかわらずサービスを特定します。 URNは一般的なURIを許容するプロトコルに現れるかもしれません、SIP[RFC3261]要求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.
終わりのホストのサービスURNsへのサービスダイヤルストリングか認識番号に関する翻訳はこのドキュメントの範囲を超えています。 これらの翻訳は、おそらく訪問者の位置によって、1つへの多く、すなわち、いくつかの認識番号が1つのサービスにURNを写像するかもしれないということであるかもしれません。 例えば、旅行者のための電話は、旅行者の家の位置と旅行者の両方の非常時の認識番号が位置を訪問したと認めるかもしれません、同じユニバーサル・サービスURN(つぼ:サービス: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.
サービスURNsが発送可能でないので、SIPプロキシかユーザエージェントが位置の適切なサービスプロバイダーのためにサービスURNを発送可能URIに翻訳しなければなりません、SIP URLのように。 地理的な位置に基づくURLにサービスURNsを写像する解決システムとしてLocationからサービスへのTranslationプロトコル(LoST)[LOST]が使用されると予想されます。 将来、そのようないくつかのプロトコル、異なったサービスのためのことによると異なったものがあるかもしれません。
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.
私たちはサービス識別子を作成するための代替的アプローチ、およびAppendix Aのそれらが不十分である理由について議論します。
Schulzrinne Standards Track [Page 3] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[3ページ]。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように解釈されることであるべきですか?
Terminology specific to emergency services is defined in [RFC5012].
緊急サービスに特定の用語は[RFC5012]で定義されます。
3. Registration Template
3. 登録テンプレート
Below, we include the registration template for the URN scheme according to RFC 3406 [RFC3406].
以下では、RFC3406[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'が存在しているなら、また、URNs'x'と'x.y'は有効なサービスURNsです。 ABNF[RFC4234]は以下で見せられます。
Schulzrinne Standards Track [Page 4] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[4ページ]。
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
サービスつぼ、= 「つぼ: 以下を修理してください」 サービスサービスがトップレベル*と等しい、(「. 」 サブサービス) トップレベルが皮肉をさせている[*-hypに皮肉をさせて25let掘ってください]サブサービス=と皮肉をさせて等しい、[*皮肉をhypさせてください、皮肉をさせる、]、皮肉がhypされた=皮肉をさせている皮肉をさせている/「-」=アルファ/ケタアルファ=%x41-5A/%x61-7A。 1Zの/1zの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 Considerations(セクション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 Considerations(セクション4)を見てください)。 うまくいくと、URNの決議は特定のサービスの例を返すでしょう、そして、同じ箇所に同時に同じ要求をする2人のユーザにとってさえ、この例は異なっているかもしれません。 しかしながら、URNによって特定された論理的なサービスは、しつこくて、ユニークです。 それぞれのユニークなサービスに、サービスURNsはユニークであるに違いありません。 これはセクション4で説明されたこの名前空間の中でそれぞれのサービスの登録で保証されます。
Schulzrinne Standards Track [Page 5] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[5ページ]。
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 Considerations(セクション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.
識別子解決には、処理してください: どんな'サービス'URNsに、ただ一つのグローバルな解決サービスもありません。 しかしながら、それぞれのトップレベルサービスはそのサービスの'サービス'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のための範囲は、公共であって、グローバルです。
4. IANA Considerations
4. IANA問題
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は新しいサービスを特定するラベルを登録する方法を詳しく述べます。 セクション4.2とセクション4.3でそれぞれ、最初の2つのサービスが登録されるサブサービスの記述(sosとカウンセリング)を与えます。 最終的に、セクション4.4は新規登録テーブルを含みます。
4.1. New Service-Identifying Labels
4.1. 新しいサービスを特定するラベル
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
サービスとサブサービスはIANAによって管理されたラベルによって特定されます、「サービスつぼのラベル」と呼ばれる新しい登録の[RFC2434]に概説された過程に従って。 したがって、新しいサービスを作成するのはIANA動作を必要とします。 トップレベルサービスラベルを加えるための方針はそうです。
Schulzrinne Standards Track [Page 6] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[6ページ]。
'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
サービス参照記述-------------------------------------------------------------------- 'foo.bar'サービスの'foo'トップレベルサービスfoo.bar RFCabc記述のfoo RFCxyz Brief記述
To allow use within the constraints of S-NAPTR [RFC3958], all top- level service names MUST NOT exceed 27 characters.
S-NAPTR[RFC3958]の規制の中で使用を許すために、すべての先端の平らなサービス名が27のキャラクタを超えてはいけません。
4.2. Sub-Services for the 'sos' Service
4.2. 'sos'サービスのためのサブサービス
This section defines the first service registration within the IANA registry defined in Section 4.1, using the top-level service label 'sos'.
このセクションはセクション4.1で定義されたIANA登録の中でファーストサービス登録を定義します、サービスラベル'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.
'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.
つぼ:サービス:sos一般的な'sos'サービスは非常時に適切な援助を順番に急いでいる公安回答ポイント(PSAP)に達します。 それは以下に記載されたサービスのすべてを取り囲みます。
urn:service:sos.ambulance This service identifier reaches an
ambulance service that provides emergency medical assistance and
transportation.
つぼ:サービス:sos.ambulance Thisサービス識別子は非常時の医療扶助と乗り物を用意する救急業務に達します。
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.
つぼ:サービス:sos.animal-control Animalコントロールは、動物管理局と管理に関係する法と法令を通常実施して、動物虐待に関するケースを調査して、原因となるペットの所有権と野生生物注意で共同体を教育して、住所不定の動物の住宅と注意に備えます、他の動物関連のサービスの中で。
Schulzrinne Standards Track [Page 7] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[7ページ]。
urn:service:sos.fire The 'fire' service identifier summons the fire
service, also known as the fire brigade or fire department.
つぼ:サービス: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.
つぼ:サービス: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.
'海洋'のサービスが参照するつぼ:サービス: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.
つぼ:サービス:sos.mountain'山'サービスは山の救助活動団体(すなわち、山の多い環境で起こる捜索救援活動)について言及します、また、用語が他の荒野環境で捜索、救出に適用するのに時々使用されますが。
urn:service:sos.physician The 'physician' emergency service connects
the caller to a physician referral service.
つぼ:サービス: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.
つぼ:サービス:sos.poison'毒'サービスは、周囲で潜在的中毒に応じる方法を市民に知らせるために設立された特別な情報センターについて言及します。 これらの毒コントロールセンターは毒と適切な応急処置に関するデータベースを維持します。
urn:service:sos.police The 'police' service refers to the police
department or other law enforcement authorities.
'警察'が調整するつぼ:サービス:sos.policeは警察署か他の法執行当局について言及します。
4.3. Sub-Services for the 'counseling' Service
4.3. 'カウンセリング'サービスのためのサブサービス
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.
つぼ: サービス: 一般的な'カウンセリング'サービスをカウンセリングするのはその人の特定の必要性に基づく訪問者を移すコールセンターに達します。
Schulzrinne Standards Track [Page 8] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[8ページ]。
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.
'子供'が調整するつぼ:サービス: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)
つぼ:サービス:counseling.mental-health'メンタル・ヘルス'サービスは「彼らがどう他の人々と対話するかと同様に精神病がある人々がどう物理的に感情的に感じるかを改良するのを助ける病気の特徴、処理、および予防医療」について言及します。 (米国保健・福祉省)
urn:service:counseling.suicide The 'suicide' service refers to the
suicide prevention hotline.
つぼ:サービス:counseling.suicide'自殺'サービスは自殺防止ホットラインについて言及します。
4.4. Initial IANA Registration
4.4. 初期のIANA登録
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
サービス参照記述-------------------------------------------------------------------- カウンセリングRFC5031Counselingは子供counseling.mental-health RFC5031Mental健康相談counseling.suicide RFC5031Suicide防止ホットラインのためにcounseling.children RFC5031Counselingを調整します。
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.marine RFC5031Maritime捜索、救出sos.mountain RFC5031Mountain救出sos.physician RFC5031Physician紹介サービスsos.poison RFC5031Poisonが制御するsos.ambulance RFC5031Ambulanceサービスsos.animal-control RFC5031Animalコントロールsos.fire RFC5031Fireサービスsos.gas RFC5031Gasが漏らすsos RFC5031Emergencyサービスとガス非常時はsos.police RFC5031警察を中心に置きます、法施行
5. Internationalization Considerations
5. 国際化問題
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で説明されるように制限されます。
Schulzrinne Standards Track [Page 9] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[9ページ]。
6. Security Considerations
6. セキュリティ問題
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を輸送すると、サービスの種類の攻撃者情報を訪問者で必要に教えることができます。 例えば、これで、攻撃者が自動的に緊急サービスかディレクトリ支援のためのすべての呼び出しを見つけるのが、より簡単になります。 適切で、プロトコル特有のセキュリティー対策は、サービスURNsを運ぶプロトコルのために実行される必要があります。 マッピングプロトコルは、[RFC5069]で詳しく述べられるように多くの脅威を記述する必要があります。 また、そのドキュメントはサービスURNの緊急サービスの使用に関連するセキュリティ問題について議論します。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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.ニュートン、「SRV RRsを使用するドメインベースのアプリケーション・サービス位置とダイナミックな代表団発見は(DDDS)を修理します」、RFC3958、2005年1月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
エド[RFC4234]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
Schulzrinne Standards Track [Page 10] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[10ページ]。
7.2. Informative References
7.2. 有益な参照
[LOST] Hardie, T., "LoST: A Location-to-Service Translation
Protocol", Work in Progress, March 2007.
[失われています] ハーディー、T.、「失われました」。 「位置からサービスへの翻訳プロトコル」、処理中の作業、2007年3月。
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997.
[RFC2142]クロッカー(D.、「共益サービス、役割、および機能のためのメールボックス名」、RFC2142)は1997がそうするかもしれません。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC3043] Mealling, M., "The Network Solutions Personal Internet
Name (PIN): A URN Namespace for People and Organizations",
RFC 3043, January 2001.
[RFC3043] 食事、M.、「ネットワークソリューションパーソナルインターネットは以下を命名(ピンで止めます)」。 「人々と組織のためのつぼの名前空間」、RFC3043、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.
S. [RFC3044]Rozenfeld、「つぼ(一定のリソース名)としてISSN-つぼの名前空間の中でISSN(国際連続の標準の数)を使用すること」でのRFC3044(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、「一定のリソース名として国際標準図書番号を使用します」、RFC3187、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、「一定のリソースは(つぼ)名前空間定義をメカニズムと命名します」、BCP66、RFC3406、2002年10月。
[RFC3536] Hoffman, P., "Terminology Used in Internationalization in
the IETF", RFC 3536, May 2003.
[RFC3536]ホフマン(P.、「IETFでの国際化に使用される用語」、RFC3536)は2003がそうするかもしれません。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC3966]Schulzrinne、2004年12月のH.、「Telephone民数記のためのtel URI」RFC3966。
[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.フォックス、「共通語設備識別子(CLEI)コードのための一定のリソース名前(つぼ)名前空間」、RFC4152、2005年8月。
[RFC4179] Kang, S., "Using Universal Content Identifier (UCI) as
Uniform Resource Names (URN)", RFC 4179, October 2005.
[RFC4179] カン、S.、「一定のリソース名(つぼ)として普遍的な満足している識別子(UCI)を使用します」、RFC4179、2005年10月。
[RFC4195] Kameyama, W., "A Uniform Resource Name (URN) Namespace for
the TV-Anytime Forum", RFC 4195, October 2005.
[RFC4195] 亀山、W.、「いつでもテレビのフォーラムへの一定のリソース名前(つぼ)名前空間」、RFC4195、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.マーシャル、エド、「インターネット技術との非常時の文脈解決のための要件」、RFC5012、1月2008日
Schulzrinne Standards Track [Page 11] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[11ページ]。
[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.Shanmugam、「非常時の間の軍事的脅威と要件は、マークとマッピングと呼びます」、RFC5069、2008年1月。
Schulzrinne Standards Track [Page 12] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[12ページ]。
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 Thisアプローチはtel URI[RFC3966]を使用します。 NNNがここの、有事番号である、世界ですべての数文脈組み合わせに関して知って、時々の変化を追わなければならないでしょう、国がどこで文脈C.Thisアプローチで特定されるかは、ユーザエージェントが実行するのが、簡単ですが、プロキシと他の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 This解決策は、名前闘争を避けますが、"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.
一口: sos@domain Earlier仕事は特別なユーザ識別子を定義しました、sos、SIP URI、例えば、一口における訪問者の家のドメインの中で: sos@example.com 。 そのようなユーザ識別子はRFC2142のコンベンション[RFC2142]とRFC2822に記録された「郵便局長」コンベンション[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
SIP URIユーザパラメタ: 1つは「aor-ドメイン;ユーザはsosと等しいことなど」の特別なURIを作成するかもしれません。 これは、名前闘争問題を避けますが、この特別なURIを放つことができるメカニズム意識しているユーザエージェントを必要とします。 また、'ユーザ'パラメタはこの用法がしないSIP URIのユーザ部分の形式について説明することになっています。 まだ他のパラメタを加えているのが不明瞭に残す、何
Schulzrinne Standards Track [Page 13] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[13ページ]。
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.
いくらか、コンベンションは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.
特別なドメイン: 緊急通報を特定するのに「一口: fire@sos.int 」などの特別なドメインを使用できました。 これには、「tel: sos」URIとして本当に、それが有効なURIであるのを除いて、同様の特性があります。 特別なドメインは、これを使用可能にするように、操作上であり、適切な緊急サービスプロキシを示さなければならないでしょう。 全世界の単一の、そして、論理的な緊急サービスプロキシがあるのは望ましくないスケーリングと行政財産を持っているように思えます。
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、キースDrage、Benja Fallenstein、ポールKyzivat、アンドリュー・ニュートン、ブライアン・ローゼン、ジョナサン・ローゼンバーグ、マーチン・トムソン、およびハンネスTschofenigのコメントからジョナサン・ローゼンバーグとの議論に基づいていて、ためになられます。
Author's Address
作者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
Buildingニューヨーク、コンピュータサイエンス450コンピュータサイエンスニューヨーク10027米国のヘニングSchulzrinneコロンビア大学部
Phone: +1 212 939 7004 EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu
以下に電話をしてください。 +1 7004年の212 939メール: hgs+ ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu
Schulzrinne Standards Track [Page 14] RFC 5031 Service URN January 2008
Schulzrinne規格はサービスつぼの2008年1月にRFC5031を追跡します[14ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Schulzrinne Standards Track [Page 15]
Schulzrinne標準化過程[15ページ]
一覧
スポンサーリンク
