RFC5115 日本語訳

Network Working Group                                        K. Carlberg
Request for Comments: 5115                                           G11
Category: Standards Track                                    P. O'Hanlon
                                                                     UCL
                                                            January 2008

Carlbergがコメントのために要求するワーキンググループK.をネットワークでつないでください: 5115年のG11カテゴリ: 標準化過程P.オーハンロンUCL2008年1月

    Telephony Routing over IP (TRIP) Attribute for Resource Priority

リソース優先権のためのIP(旅行)属性の上の電話ルート設定

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

要約

   This document defines a new attribute for the Telephony Routing over
   IP (TRIP) protocol.  The attribute associates protocols/services in
   the PSTN offering authorized prioritization during call setup that
   are reachable through a TRIP gateway.  Current examples of
   preferential service in the Public Switched Telephone Network (PSTN)
   are Government Emergency Telecommunications Service (GETS) in the
   U.S. and Government Telephone Preference Scheme (GTPS) in the U.K.
   The proposed attribute for TRIP is based on the NameSpace.Value tuple
   defined for the SIP Resource-Priority field.

このドキュメントはIP(TRIP)プロトコルの上のTelephonyルート設定のために新しい属性を定義します。 属性は、TRIPゲートウェイを通して届いた状態で呼び出しセットアップの間の認可された優先順位づけを提供しながら、PSTNでプロトコル/サービスを関連づけます。 Public Switched Telephone Network(PSTN)での優先のサービスの現在の例は、米国の政府Emergency Telecommunications Service(GETS)とイギリスの政府Telephone Preference Scheme(GTPS)です。TRIPのための提案された属性はSIP Resource-優先権分野と定義されたNameSpace.Value tupleに基づいています。

1.  Introduction

1. 序論

   An IP telephony gateway allows nodes on an IP-based network to
   communicate with other entities on the circuit switched telephone
   network.  The Telephony Routing over IP (TRIP) protocol [rfc3219]
   provides a way for nodes on the IP network to locate a suitable
   gateway through the use of Location Servers.  TRIP is a policy-
   driven, inter-administrative domain protocol for advertising the
   reachability, negotiating the capabilities, and specifying the
   attributes of these gateways.

IP電話技術ゲートウェイで、IP接続を基本にしたネットワークのノードは回路の切り換えられた電話網に関する他の実体で交信できます。 IP(TRIP)プロトコル[rfc3219]の上のTelephonyルート設定はIPネットワークのノードがLocation Serversの使用で適当なゲートウェイの場所を見つける方法を提供します。 TRIPは追い立てられた方針です、可到達性の広告を出すための相互管理のドメインプロトコル、能力を交渉して、これらのゲートウェイの属性を指定して。

   The TRIP protocol is modeled after BGP-4 [rfc4271] and uses path-
   vector advertisements distributed in a hop-by-hop manner (resembling
   a Bellman-Ford routing algorithm) via Location Servers.  These
   Location Servers are grouped in administrative clusters known as
   Internet Telephony Administrative Domains (ITADs).  A more extensive
   framework discussion on TRIP can be found in [rfc2871].

TRIPプロトコルは、BGP-4[rfc4271]に倣われて、ホップごとの方法(Bellman-フォードルーティング・アルゴリズムに類似している)でLocation Serversを通して配布された経路ベクトル広告を使用します。 これらのLocation ServersはインターネットTelephony Administrative Domains(ITADs)として知られている管理クラスタで分類されます。 [rfc2871]でTRIPについての、より大規模なフレームワーク議論を見つけることができます。

Carlberg & O'Hanlon         Standards Track                     [Page 1]

RFC 5115              Resource Priority Attribute           January 2008

CarlbergとオーハンロンStandardsはリソース優先権属性2008年1月にRFC5115を追跡します[1ページ]。

   This document defines a new attribute that has been registered with
   IANA.  The purpose of this new attribute, and the rationale behind
   its specification, is explained in the following sections.

このドキュメントはIANAに示された新しい属性を定義します。 この新しい属性の目的、および仕様の後ろの原理は以下のセクションで説明されます。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [rfc2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[rfc2119]で説明されるように本書では解釈されることであるべきですか?

2.  Emergency Telecommunications Service

2. 非常時のテレコムサービス

   Emergency Telecommunications Service is a broad term that refers to
   the services provided by systems used to support emergency
   communications.  One example of these systems is the U.S. Government
   Emergency Telecommunications Service (GETS).  This system currently
   operates over the U.S. Public Switched Telephone Network (PSTN) as a
   pay-per-use system by authorized personnel.  It uses the T1.631-1993
   ANSI standard [ANSI] to signal the presence of the National Security
   / Emergency Preparedness (NS/EP) codepoint in an ISDN User Part
   (ISUP) Initial Address Message (IAM) for Signaling System No. 7
   (SS7).  A key aspect of GETS is that a signaling standard in the U.S.
   PSTN is used to convey the activation/request of the GETS service.

非常時Telecommunications Serviceは非常時のコミュニケーションをサポートするのに使用されるシステムによって提供されたサービスについて言及する広義語です。 これらのシステムに関する1つの例が米国政府Emergency Telecommunications Service(GETS)です。 このシステムは現在、米国の上で作動します。aがシステムを賃金で熟読するので、Public Switched Telephone Network(PSTN)は人員に権限を与えました。 それは、Signaling System No.7(SS7)のためにISDN User Part(ISUP)の初期のAddress Message(IAM)での国家安全保障/非常時Preparedness(NS/EP)codepointの存在に合図するのに、T1.631-1993ANSI規格[ANSI]を使用します。 GETSの特徴はU.S. PSTNのシグナリング規格がGETSサービスの起動/要求を伝えるのに使用されるということです。

   From a protocol perspective, other examples of priority (and which
   can be argued as emergency/disaster related) standards are the
   H.460.4 ITU [itu460] standard on Call Priority designation for H.323
   calls, and the I.255.3 [itu255] ITU standard on Multi-Level
   Precedence and Preemption Service.  The latter has been integrated
   into private telephony systems like AUTOVON.  In both cases,
   signaling codepoints exist to distinguish telephony calls by
   authenticated and prioritized end-user from the normal end-user.  The
   form of this distinction varies and is outside the scope of this
   document.  [rfc3689] and [rfc3690] provide additional information on
   ETS and its requirements.

プロトコル見解から、優先権(非常時/災害が関係づけたようにどれを論争できる)規格に関する他の例は、Call Priority名称のH.323呼び出しのH.460.4 ITU[itu460]規格と、Multi-レベルのPrecedenceとPreemption ServiceのI.255.3[itu255]ITU規格です。 後者はAUTOVONのような個人的な電話技術システムと統合されました。 どちらの場合も、シグナリングcodepointsは、普通のエンドユーザと電話電話するのを認証されて最優先しているエンドユーザが区別するために存在しています。 この区別のフォームは、異なって、このドキュメントの範囲の外にあります。 [rfc3689]と[rfc3690]はETSに関する追加情報とその要件を提供します。

3.  SIP Resource-Priority Effort

3. 一口リソース優先権取り組み

   The initial discussions in the IEPREP working group list, along with
   the presentation at the Adelaide IETF [ADEL00], led to strawman
   requirements to augment SIP to have the ability to prioritize call
   signaling.  This effort was then advanced formally in the SIPPING
   working group so that SIP would be able to prioritize access to
   circuit-switched networks, end systems, and proxy resources for
   emergency preparedness communication [rfc3487].

IEPREPワーキンググループリストにおける初期の議論はアデレードIETF[ADEL00]のプレゼンテーションと共に呼び出しシグナリングを最優先させる能力を持つためにSIPを増大させるというわら人形要件につながりました。 そして、この取り組みは、SIPが非常時の気構えコミュニケーション[rfc3487]のための回路交換ネットワーク、エンドシステム、およびプロキシリソースへのアクセスを最優先させることができるように、SIPPINGワーキンググループで正式に進められました。

   The requirements in [rfc3487] produced the corresponding document
   [rfc4412] in the SIP working group, which defines a new header for
   SIP called Resource-Priority.  This new header, which is optional, is

[rfc3487]の要件はSIPワーキンググループで対応するドキュメント[rfc4412]を製作しました。(それは、Resource-優先権と呼ばれるSIPのために新しいヘッダーを定義します)。 この新しいヘッダー(任意である)はそうです。

Carlberg & O'Hanlon         Standards Track                     [Page 2]

RFC 5115              Resource Priority Attribute           January 2008

CarlbergとオーハンロンStandardsはリソース優先権属性2008年1月にRFC5115を追跡します[2ページ]。

   divided into two parts: a NameSpace and a Value.  The NameSpace part
   uniquely identifies a group of one or more priorities.  The Value
   part identifies one of a set of priorities used for a SIP message.

2つの部品に分割されます: 名前空間と値。 NameSpace部分は唯一1つ以上のプライオリティのグループを特定します。 Value部分はSIPメッセージに使用される1セットのプライオリティの1つを特定します。

3.1.  Benefits

3.1. 利益

   There are three basic benefits derived from the addition of the
   Resource Priority header in SIP.  The first is an ability to signal
   the priority within a SIP message to other entities in an IP network.
   The caveat is that some entities may not recognize/support the
   priority or namespace, but at least the ability to signal the
   priority with respect to resources has been specified in the SIP
   protocol.

SIPでResource Priorityヘッダーの追加から得られた3つの基本的な利益があります。 1番目はSIPメッセージの中でIPネットワークで他の実体に優先権に合図する能力です。 警告はいくつかの実体が優先権か名前空間を認識しないか、サポートしないかもしれないということですが、リソースに関して優先権に合図する少なくとも能力はSIPプロトコルで指定されました。

   The second benefit is that telephony-related protocol/codepoints from
   other standards can have a corresponding mapping to SIP NameSpace and
   Value tokens in the Resource-Priority header.  Hence, the current
   NS/EP codepoint in ANSI standard T1.631-1993 could have a
   corresponding NameSpace.Value token set for the IETF standards body.
   And as a result, this mapping would facilitate the transparent
   bridging of signals (i.e., codepoints) between standards defined by
   various organizations -- be they private or public.

2番目の利益は他の規格からの電話関連のプロトコル/codepointsがResource-優先権ヘッダーにSIP NameSpaceとValueトークンに対応するマッピングを持つことができるということです。 したがって、ANSI規格T1.631-1993の現在のNS/EP codepointは対応するNameSpace.ValueトークンをIETF標準化団体に設定させることができました。 そして、その結果、このマッピングはそれらが個人的であるか、または公共であったなら様々な組織によって定義された規格の間の信号(すなわち、codepoints)を透明なブリッジすることを容易にするでしょう。

   The third benefit of the Resource-Priority header, and its definition
   of alphanumeric tokens, is that it is highly versatile.  The
   NameSpace allows for a wide set of priorities to be defined and
   updated, if the need arises, by simply defining a new NameSpace
   token.  Hence, there is no reliance on a single set of priorities
   applied for all cases.

Resource-優先権ヘッダーの3番目の利益、およびその英数字のトークンの定義はそれが非常に多能であるということです。 NameSpaceは広いセットのプライオリティを定義して、アップデートするのを許容します、必要性が起こるなら、単に新しいNameSpaceトークンを定義することによって。 したがって、すべてのケースのために適用された1セットのプライオリティへの信用が全くありません。

3.2  Issue

3.2 問題

   Having defined a means of signaling priority through gateways, the
   follow-on question arises of how does one determine which gateways
   support a given NameSpace.  The dissemination of this type of
   information is within the scope of TRIP.  However, the current
   specification of TRIP does not include a component that advertises
   associations of gateways with specific NameSpaces.  To address this
   omission, the following section defines a new TRIP attribute that
   associates one or more NameSpaces with a gateway.

優先権に合図する手段を定義したので、ゲートウェイ、質問が起こるフォローオンを通して、人は、どのゲートウェイが与えられたNameSpaceをサポートするかをどのように決定しますか? TRIPの範囲の中にこの情報の種類の普及があります。 しかしながら、TRIPの現在の仕様は特定のNameSpacesがあるゲートウェイの協会の広告を出すコンポーネントを含んでいません。 この省略を扱うために、以下のセクションは1NameSpacesをゲートウェイに関連づける新しいTRIP属性を定義します。

Carlberg & O'Hanlon         Standards Track                     [Page 3]

RFC 5115              Resource Priority Attribute           January 2008

CarlbergとオーハンロンStandardsはリソース優先権属性2008年1月にRFC5115を追跡します[3ページ]。

4.  New Attribute: ResourcePriority

4. 新しい属性: ResourcePriority

   This section provides details on the syntax and semantics of the
   ResourcePriority TRIP attribute.  Its presentation reflects the form
   of existing attributes presented in Section 5 of [rfc3219].

このセクションはResourcePriority TRIP属性の構文と意味論に関する詳細を明らかにします。 プレゼンテーションは[rfc3219]のセクション5に提示された既存の属性のフォームを反映します。

   Attribute Flags are set to the following:

属性Flagsは以下に用意ができています:

      Conditional Mandatory: False
      Required Flags: Not Well-Known, Independent Transitive
      Potential Flags: None
      TRIP Type Code: 12

条件付きである、義務的: 偽の必要な旗: どんなよく知られて、独立している遷移的な可能性も弛みません: なにも以下をコード化しません旅行が、タイプする。 12

   There are no dependencies on other attributes, thus Conditional
   Mandatory is set to "False".

依存が全く他の属性にありません、その結果、Conditional Mandatoryは「誤ること」に用意ができています。

   Since the Resource-Priority field in SIP, with its corresponding
   NameSpace token, is optional, the ResourcePriority attribute in TRIP
   is also optional.  Hence, it is set to "Not Well-Known".

対応するNameSpaceトークンによって、SIPのResource-優先権分野が任意であるので、また、TRIPのResourcePriority属性も任意です。 したがって、それは「よく知られること」に設定されません。

   The Independent Transitive condition indicates that the attribute is
   to be forwarded amongst all ITADs.  The Location Server that does not
   recognize the attribute sets the Partial flag as well.

無党派Transitive状態は、属性がすべてのITADsの中で進められることであることを示します。 属性を認識しないLocation Serverはまた、Partial旗を設定します。

4.1.  Syntax of ResourcePriority

4.1. ResourcePriorityの構文

   The ResourcePriority attribute contains one or more NameSpace token
   identifiers.  An initial set of identifiers is defined in [rfc4412],
   with subsequent identifiers to be found in the IANA registry.  The
   syntax of the ResourcePriority attribute is copied from the
   "namespace" token syntax from [rfc4412], which in turn imported
   "alphanum" from [rfc3261], and is an alphanumeric value as shown
   below:

ResourcePriority属性は1つ以上のNameSpaceトークン識別子を含んでいます。 1人の始発に関する識別子はIANA登録で見つけられるその後の識別子で[rfc4412]で定義されます。 ResourcePriority属性の構文は、「名前空間」トークン構文から[rfc3261]から"alphanum"を順番にインポートした[rfc4412]からコピーされて、以下に示すように英数字値です:

   namespace = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+"
                   / "`" / "'" / "~" )

名前空間=1*(alphanum/「-」/“!"/「%」/「*」/"_"/「+」/、「'、「/、「'「/「~」)」'

   Note that an augmented version of Backus-Naur Form is found in
   [rfc4234].

BN記法の増大しているバージョンが[rfc4234]で見つけられることに注意してください。

   Since NameSpaces are arbitrary in length, each tuple consists of a
   Length value with a NameSpace value as shown in the figure below.
   There is no padding between tuples.

NameSpacesが長さで任意であるので、各tupleは以下の図に示されるようにNameSpace値でLength価値から成ります。 tuplesの間でそっと歩いてはいけません。

Carlberg & O'Hanlon         Standards Track                     [Page 4]

RFC 5115              Resource Priority Attribute           January 2008

CarlbergとオーハンロンStandardsはリソース優先権属性2008年1月にRFC5115を追跡します[4ページ]。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+--------------+----------------+
   |        NameSpace Length       |   NameSpace Value (variable)  |
   +---------------+---------------+--------------+----------------+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | 名前空間の長さ| 名前空間値(可変)| +---------------+---------------+--------------+----------------+

   It is important to note that the priority (i.e., "r-priority" token
   syntax) from [rfc4412] is NOT used in the ResourcePriority attribute.
   This is because the objective of the attribute is to advertise the
   NameSpace associated with a gateway and not the individual priorities
   within that NameSpace.

[rfc4412]からの優先権(すなわち、「r-優先権」トークン構文)がResourcePriority属性に使用されないことに注意するのは重要です。 これは属性の目的がそのNameSpaceの中に個々のプライオリティではなく、ゲートウェイに関連しているNameSpaceの広告を出すことであるからです。

4.2  Additional TRIP Considerations

4.2 追加旅行問題

   Section 5.12 of TRIP lists a number of considerations that should be
   addressed when defining new attributes.  The first three
   considerations (use of the attribute, its flags, and syntax) have
   been discussed above in this section.  The final three considerations
   are the following.

TRIPのセクション5.12は新しい属性を定義するとき扱われるべきである多くの問題を記載します。 上でこのセクションで最初の3つの問題(属性、旗、および構文の使用)について議論しました。 最終的な3つの問題が以下です。

4.2.1.  Route Origination

4.2.1. ルート創作

   The ResourcePriority attribute is not well-known.  If a route has a
   ResourcePriority attribute associated with it, the Location Server
   (LS) MUST include that attribute in the advertisement it originates.

ResourcePriority属性は周知のことではありません。 ルートにそれに関連しているResourcePriority属性があるなら、Location Server(LS)はそれが溯源する広告にその属性を含まなければなりません。

4.2.2.  Route Aggregation

4.2.2. ルート集合

   Routes with differing ResourcePriority token values MUST NOT be
   aggregated.  Routes with the same token values in the
   ResourcePriority attribute MAY be aggregated and the same
   ResourcePriority attribute attached to the aggregated object.

異なったResourcePriorityトークン値があるルートを集めてはいけません。 ResourcePriority属性における同じトークン値があるルートは集められたかもしれません、そして、同じResourcePriority属性は集められたオブジェクトに付きました。

4.2.3.  Route Dissemination and Attribute Scope

4.2.3. ルート普及と属性範囲

   An LS MUST include the ResourcePriority attribute when communicating
   with peer LSs within its own domain.

それ自身のドメインの中で同輩LSsとコミュニケートするとき、LS MUSTはResourcePriority属性を含んでいます。

   If received from a peer LS in another domain, an LS MUST propagate
   the ResourcePriority attribute to other LSs within its domain.

同輩から受け取るなら、別のドメインのLS、LS MUSTはドメインの中でResourcePriority属性を他のLSsに伝播します。

   An LS MAY add the ResourcePriority attribute when propagating routing
   objects to an LS in another domain.  The inclusion of the
   ResourcePriority attribute is a matter of local administrative
   policy.

別のドメインでルーティングオブジェクトをLSに伝播するとき、LS MAYはResourcePriority属性を加えます。 ResourcePriority属性の包含はローカルの施政方針の問題です。

Carlberg & O'Hanlon         Standards Track                     [Page 5]

RFC 5115              Resource Priority Attribute           January 2008

CarlbergとオーハンロンStandardsはリソース優先権属性2008年1月にRFC5115を追跡します[5ページ]。

5.  Security Considerations

5. セキュリティ問題

   The document defines a new attribute for the TRIP protocol and has no
   direct security considerations applied to it.  However, the security
   considerations for TRIP and its messages remain the same and are
   articulated in Section 14 of [rfc3219].

ドキュメントで、TRIPプロトコルのために新しい属性を定義して、どんなダイレクトセキュリティ問題もそれに適用しません。 しかしながら、TRIPのためのセキュリティ問題とそのメッセージは、同じままで残っていて、[rfc3219]のセクション14で明確に話されます。

6.  IANA Considerations

6. IANA問題

   As described in Section 4 above, one new "TRIP attribute" has been
   defined.  Its name and code value are the following:

上のセクション4で説明されるように、1新しい「TRIP属性」が定義されました。 その名前とコード値は以下です:

      Code                    Attribute Name
      ----                   ----------------
       12                    ResourcePriority

コード属性名---- ---------------- 12 ResourcePriority

   These assignments are recorded in the following registry:
      http://www.iana.org/assignments/trip-parameters

これらの課題は以下の登録に記録されます: http://www.iana.org/assignments/trip-parameters

7.  Acknowledgements

7. 承認

   The authors appreciate review and subsequent comments from James Polk
   and Henning Schulzrinne.

作者はジェイムズ・ポークとヘニングSchulzrinneからレビューとその後のコメントを鑑賞します。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [rfc3219] Rosenberg, J., Salama, H., and M. Squire, "Telephony
             Routing over IP (TRIP)", RFC 3219, January 2002.

[rfc3219] ローゼンバーグ、J.、サラマ、H.、およびM.は2002年1月に「電話はIP(旅行)の上で掘る」RFC3219に付き添います。

   [rfc4412] Schulzrinne, H. and J. Polk, "Communications Resource
             Priority for the Session Initiation Protocol (SIP)", RFC
             4412, February 2006.

[rfc4412]SchulzrinneとH.とJ.ポーク、「セッション開始プロトコル(一口)のためのコミュニケーションリソース優先権」、RFC4412、2006年2月。

8.2.  Informative References

8.2. 有益な参照

   [ADEL00]  IETF Proceedings (47th), SIP Working Group, Adelaide,
             Australia, June 2000.

[ADEL00]IETF議事(47番目)、一口作業部会、アデレード、オーストラリア、2000年6月。

   [ANSI]    ANSI, "Signaling System No. 7 (SS7): High Probability of
             Completion (HPC) Network Capability", ANSI T1.631, 1993.

[ANSI]ANSI、「シグナリングシステムNo.7(SS7):」 「完成(HPC)ネットワーク能力の高い確率」、ANSI T1.631、1993。

   [itu460]  ITU, "Call Priority Designation for H.323 Calls", ITU
             Recommendation H.460.4, November 2002.

[itu460]ITU、「H.323のための呼び出し優先権名称は呼ぶ」ITU推薦H.460.4、2002年11月。

   [itu255]  ITU, "Multi-Level Precedence and Preemption Service", ITU
             Recommendation I.255.3, July 1990.

ITU推薦I.255.3、1990年7月[itu255]ITUと、「マルチレベル先行と先取りサービス」

Carlberg & O'Hanlon         Standards Track                     [Page 6]

RFC 5115              Resource Priority Attribute           January 2008

CarlbergとオーハンロンStandardsはリソース優先権属性2008年1月にRFC5115を追跡します[6ページ]。

   [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月。

   [rfc2871] Rosenberg, J. and H. Schulzrinne, "A Framework for
             Telephony Routing over IP", RFC 2871, June 2000.

[rfc2871] ローゼンバーグとJ.とH.Schulzrinne、「IPの上の電話ルート設定のためのフレームワーク」、RFC2871、2000年6月。

   [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月。

   [rfc3487] Schulzrinne, H., "Requirements for Resource Priority
             Mechanisms for the Session Initiation Protocol (SIP)", RFC
             3487, February 2003.

[rfc3487] Schulzrinne、H.、「セッション開始プロトコル(一口)のためのリソース優先権メカニズムのための要件」、RFC3487、2003年2月。

   [rfc3689] Carlberg, K. and R. Atkinson, "General Requirements for
             Emergency Telecommunication Service (ETS)", RFC 3689,
             February 2004.

[rfc3689] CarlbergとK.とR.アトキンソン、「非常時の電気通信サービス(ETS)のための一般要件」、RFC3689、2004年2月。

   [rfc3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
             for Emergency Telecommunications Service (ETS)", RFC 3690,
             February 2004.

[rfc3690] CarlbergとK.とR.アトキンソン、「非常時のテレコムサービス(ETS)のためのIP電話要件」、RFC3690、2004年2月。

   [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。

   [rfc4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border
             Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[rfc4271]Rekhter、Y.(エド)、李、T.(エド)、およびS.野兎(エド)、「境界ゲートウェイは4(BGP-4)について議定書の中で述べます」、RFC4271、2006年1月。

Authors' Addresses

作者のアドレス

   Ken Carlberg
   G11
   123a Versailles Circle
   Baltimore, MD
   USA

ケン・Carlberg G11 123aベルサイユ円のMDボルチモア(米国)

   EMail: carlberg@g11.org.uk

メール: carlberg@g11.org.uk

   Piers O'Hanlon
   University College London
   Gower Street
   London
   UK

埠頭のオーハンロン・ユニバーシティ・カレッジロンドンガウアー・ストリートロンドンイギリス

   EMail: p.ohanlon@cs.ucl.ac.uk

メール: p.ohanlon@cs.ucl.ac.uk

Carlberg & O'Hanlon         Standards Track                     [Page 7]

RFC 5115              Resource Priority Attribute           January 2008

CarlbergとオーハンロンStandardsはリソース優先権属性2008年1月にRFC5115を追跡します[7ページ]。

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に情報を扱ってください。

Carlberg & O'Hanlon         Standards Track                     [Page 8]

Carlbergとオーハンロン標準化過程[8ページ]