RFC3968 日本語訳
3968 The Internet Assigned Number Authority (IANA) Header FieldParameter Registry for the Session Initiation Protocol (SIP). G.Camarillo. December 2004. (Format: TXT=20615 bytes) (Updates RFC3427) (Also BCP0098) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Camarillo Request for Comments: 3968 Ericsson Updates: 3427 December 2004 BCP: 98 Category: Best Current Practice
コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 3968のエリクソンアップデート: 3427 2004年12月のBCP: 98カテゴリ: 最も良い現在の習慣
The Internet Assigned Number Authority (IANA)
Header Field Parameter Registry for
the Session Initiation Protocol (SIP)
セッション開始プロトコルのためのISOCの機関の一つで(IANA)ヘッダーフィールドパラメタ登録(一口)
Status of This Memo
このメモの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry.
このドキュメントはSession Initiationプロトコル(SIP)ヘッダーフィールドパラメタとパラメタ値のためにISOCの機関の一つで(IANA)登録を作成します。 また、それは、この登録に初期のエントリーとして使用されるために既に既存のパラメタとパラメタ値をリストアップします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Use of the Registry . . . . . . . . . . . . . . . . . . . . . 2
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4.1. Header Field Parameters Sub-Registry . . . . . . . . . . 3
4.2. Registration Policy for SIP Header Field Parameters. . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 登録. . . . . . . . . . . . . . . . . . . . . 2 4の使用。 IANA問題. . . . . . . . . . . . . . . . . . . . . 3 4.1。 ヘッダーフィールドパラメタサブ登録. . . . . . . . . . 3 4.2。 一口ヘッダーフィールドパラメタのための登録方針。 . . 6 5. セキュリティ問題. . . . . . . . . . . . . . . . . . . 7 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 7 7。 引用規格. . . . . . . . . . . . . . . . . . . . . 7作者のアドレスの.7の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 8
Camarillo Best Current Practice [Page 1] RFC 3968 SIP Parameter Registry December 2004
キャマリロの最も良い現在の習慣[1ページ]RFC3968はパラメタ登録2004年12月にちびちび飲みます。
1. Introduction
1. 序論
RFC 3261 [3] allows new header field parameters and new parameter values to be defined. However, RFC 3261 omitted an IANA registry for them. This document creates such a registry.
RFC3261[3]は、新しいヘッダーフィールドパラメタと新しいパラメタ値が定義されるのを許容します。 しかしながら、RFC3261はそれらのためにIANA登録を省略しました。 このドキュメントはそのような登録を作成します。
RFC 3427 [4] documents the process to extend SIP. This document updates RFC 3427 by specifying how to define and register new SIP header field parameters and parameter values.
RFC3427[4]は、SIPを広げるために過程を記録します。 どのように新しいSIPヘッダーフィールドパラメタとパラメタ値を定義して、示すかを指定することによって、このドキュメントはRFC3427をアップデートします。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[1]ということであり、対応する実現のために要件レベルを示すべきであるかをさせましょう。
3. Use of the Registry
3. 登録の使用
SIP header field parameters and parameter values MUST be documented in an RFC in order to be registered by IANA. This documentation MUST fully explain the syntax, intended usage, and semantics of the parameter or parameter value. The intent of this requirement is to assure interoperability between independent implementations, and to prevent accidental namespace collisions between implementations of dissimilar features.
IANAによって登録されるように、SIPヘッダーフィールドパラメタとパラメタ値をRFCに記録しなければなりません。 このドキュメンテーションで、パラメタかパラメタ価値の構文、意図している用法、および意味論が完全にわからなければなりません。 この要件の意図は、独立している実現の間の相互運用性を保証して、異なった特徴の実現の間の偶然の名前空間衝突を防ぐことです。
Note that this registry, unlike other protocol registries, only
deals with parameters and parameter values defined in RFCs (i.e.,
it lacks a vendor-extension tree). RFC 3427 [4] documents
concerns with regards to new SIP extensions which may damage
security, greatly increase the complexity of the protocol, or
both. New parameters and parameter values need to be documented
in RFCs as a result of these concerns.
この登録が他のプロトコル登録と異なってRFCsで定義されたパラメタとパラメタ値に対処するだけであることに注意してください(すなわち、それは業者拡大木を欠いています)。 RFC3427[4]はセキュリティを破損するかもしれない新しいSIP拡張子にあいさつがある関心を記録して、プロトコル、または両方の複雑さを大いに増加させてください。 新しいパラメタとパラメタ値は、これらの関心の結果、RFCsに記録される必要があります。
RFCs defining SIP header field parameters or parameter values MUST register them with IANA as described below.
SIPヘッダーフィールドパラメタかパラメタ値を定義するRFCsは以下で説明されるようにIANAにそれらを登録しなければなりません。
Registered SIP header field parameters and parameter values are to be considered "reserved words". In order to preserve interoperability, registered parameters and parameter values MUST be used in a manner consistent with that described in their defining RFC. Implementations MUST NOT utilize "private" or "locally defined" SIP header field parameters or parameter values that conflict with registered parameters.
登録されたSIPヘッダーフィールドパラメタとパラメタ値は「リザーブドワード」であると考えられることです。 相互運用性を保存するために、RFCを定義する際に説明されるそれと一致した方法で登録されたパラメタとパラメタ値を使用しなければなりません。 実現は「個人的である」か「局所的に定義された」SIPヘッダーフィールドパラメタか登録されたパラメタと衝突するパラメタ値を利用してはいけません。
Camarillo Best Current Practice [Page 2] RFC 3968 SIP Parameter Registry December 2004
キャマリロの最も良い現在の習慣[2ページ]RFC3968はパラメタ登録2004年12月にちびちび飲みます。
Note that although unregistered SIP header field parameters and
parameter values may be used in implementations, developers are
cautioned that usage of such parameters is risky. New SIP header
field parameters and parameter values may be registered at any
time, and there is no assurance that these new registered
parameters or parameter values will not conflict with unregistered
parameters currently in use.
登録されていないSIPヘッダーフィールドパラメタとパラメタ値が実現に使用されるかもしれませんが、開発者がそのようなパラメタの用法が危険であると警告されることに注意してください。 新しいSIPヘッダーフィールドパラメタとパラメタ値はいつでも示されるかもしれません、そして、これらの新しい登録されたパラメタかパラメタ値が現在使用中の登録されていないパラメタと衝突しないという保証が全くありません。
Some SIP header field parameters only accept a set of predefined parameter values. For example, a parameter indicating the transport protocol in use may only accept the predefined tokens TCP, UDP, and SCTP as valid values. Registering all parameter values for all SIP header field parameters of this type would require a large number of subregistries. Instead, we have chosen to register parameter values by reference. That is, the entry in the parameter registry for a given header field parameter contains references to the RFCs defining new values of the parameter. References to RFCs defining parameter values appear in double brackets in the registry.
いくつかのSIPヘッダーフィールドパラメタが1セットの事前に定義されたパラメタ値を受け入れるだけです。 例えば、使用中のトランスポート・プロトコルを示すパラメタは有効値として事前に定義された象徴のTCP、UDP、およびSCTPを認めるだけであるかもしれません。 このタイプのすべてのSIPヘッダーフィールドパラメタのためにすべてのパラメタ値を示すのは多くの副登録を必要とするでしょう。 代わりに、私たちは、参照でパラメタ値を示すのを選びました。 すなわち、与えられたヘッダーフィールドパラメタのためのパラメタ登録のエントリーはパラメタの新しい値を定義するRFCsの参照を含んでいます。 パラメタ値を定義するRFCsの参照は登録の二重括弧に現れます。
So, the header field parameter registry contains a column that indicates whether or not each parameter only accepts a set of predefined values. Implementers of parameters with a "yes" in that column need to find all the valid parameter values in the RFCs provided as references.
それで、ヘッダーフィールドパラメタ登録は各パラメタが1セットの事前に定義された値を受け入れるだけであるかどうかを示すコラムを含んでいます。 「はい」がそのコラムにあるパラメタのImplementersは、参照として提供されたRFCsですべての有効なパラメタ値を見つける必要があります。
4. IANA Considerations
4. IANA問題
Section 27 of RFC 3261 [3] creates an IANA registry for method names, header field names, warning codes, status codes, and option tags. This specification creates a new sub-registry for header field parameters under the SIP Parameters registry.
RFC3261[3]のセクション27は方法名、ヘッダーフィールド名、警告コード、ステータスコード、およびオプションタグのためのIANA登録を作成します。 この仕様はSIP Parameters登録の下でヘッダーフィールドパラメタのための新しいサブ登録を作成します。
4.1. Header Field Parameters Sub-Registry
4.1. ヘッダーフィールドパラメタサブ登録
The majority of the SIP header fields can be extended by defining new parameters. New SIP header field parameters are registered by the IANA. When registering a new parameter for a header field or a new value for a parameter, the following information MUST be provided.
新しいパラメタを定義することによって、SIPヘッダーフィールドの大部分を広げることができます。 新しいSIPヘッダーフィールドパラメタはIANAによって示されます。 ヘッダーフィールドのための新しいパラメタかパラメタのための新しい値を示すとき、以下の情報を提供しなければなりません。
o Header field in which the parameter can appear.
o パラメタが現れることができるヘッダーフィールド。
o Name of the header field parameter being registered.
o 示されるヘッダーフィールドパラメタの名前。
o Whether the parameter only accepts a set of predefined values.
o パラメタは1セットの事前に定義された値を受け入れるのであるだけであるかどうか
Camarillo Best Current Practice [Page 3] RFC 3968 SIP Parameter Registry December 2004
キャマリロの最も良い現在の習慣[3ページ]RFC3968はパラメタ登録2004年12月にちびちび飲みます。
o A reference to the RFC where the parameter is defined and to any
RFC that defines new values for the parameter. References to RFCs
defining parameter values appear in double brackets in the
registry.
o パラメタが定義されるRFCとパラメタのために新しい値を定義するどんなRFCの参照。 パラメタ値を定義するRFCsの参照は登録の二重括弧に現れます。
Parameters that can appear in different header fields MAY have the same name. However, parameters that can appear in the same header field MUST have different names.
異なったヘッダーフィールドに現れることができるパラメタは同じ名前を持っているかもしれません。 しかしながら、同じヘッダーフィールドに現れることができるパラメタは異なった名前を持たなければなりません。
The following are the initial values for this sub-registry.
↓これはこのサブ登録への初期の値です。
Header Field Parameter Name Predefined Reference
Values
_____________________________________________________________________
Accept q No [RFC 3261]
Accept-Encoding q No [RFC 3261]
Accept-Language q No [RFC 3261]
Authorization algorithm Yes [RFC 3261]
[[RFC 3310]]
Authorization auts No [RFC 3310]
Authorization cnonce No [RFC 3261]
Authorization nc No [RFC 3261]
Authorization nonce No [RFC 3261]
Authorization opaque No [RFC 3261]
Authorization qop Yes [RFC 3261]
Authorization realm No [RFC 3261]
Authorization response No [RFC 3261]
Authorization uri No [RFC 3261]
Authorization username No [RFC 3261]
Authentication-Info cnonce No [RFC 3261]
Authentication-Info nc No [RFC 3261]
Authentication-Info nextnonce No [RFC 3261]
Authentication-Info qop Yes [RFC 3261]
Authentication-Info rspauth No [RFC 3261]
Call-Info purpose Yes [RFC 3261]
Contact expires No [RFC 3261]
Contact q No [RFC 3261]
Content-Disposition handling Yes [RFC 3261]
Event id No [RFC 3265]
From tag No [RFC 3261]
P-Access-Network-Info cgi-3gpp No [RFC 3455]
P-Access-Network-Info utran-cell-id-3gpp No [RFC 3455]
P-Charging-Function-Addresses ccf No [RFC 3455]
P-Charging-Function-Addresses ecf No [RFC 3455]
P-Charging-Vector icid-value No [RFC 3455]
P-Charging-Vector icid-generated-at No [RFC 3455]
P-Charging-Vector orig-ioi No [RFC 3455]
P-Charging-Vector term-ioi No [RFC 3455]
ヘッダーフィールドのパラメタの名前の事前に定義された基準値_____________________________________________________________________ はい、RFC3261RFC3310のいいえのRFC3261のAuthorizationの一回だけのAuthorization autsいいえRFC3310Authorization cnonceいいえRFC3261Authorization ncノーRFC3261Authorizationが不透明にするAuthorizationのAcceptをコード化しているqいいえRFC3261Accept-言語qいいえRFC3261qノーRFC3261アルゴリズムを受け入れてください、いいえRFC3261、Authorization qop、はい、Authentication-インフォメーションのcnonceのRFC3261Authorization分野いいえRFC3261Authorization応答いいえRFC3261Authorization uriいいえRFC3261Authorizationユーザ名ノーRFC3261ノーRFC; 3261年の認証インフォメーションncいいえRFC3261Authentication-インフォメーションnextnonceノーRFC3261Authentication-インフォメーションははい、P充電のセルイド3gppをutranしているrspauthはい、RFC3261Call-インフォメーションがない目的RFC3261Contactが吐き出すRFC3261Authentication-インフォメーションのいいえRFC3455P充電機能アドレスccf Pアクセスネットワークインフォメーションの3261年のRFC3261Contact qはい、RFC3261Content-気質がない取り扱いRFC EventイドいいえRFC3265FromタグノーRFC3261管路気中送電-3gppがないいいえRFC3455PアクセスネットワークインフォメーションノーRFC3455Functをqopします。P充電ベクトルの用語-ioiのP充電ベクトルのP充電ベクトルのorig-ioiのP充電ベクトルのicid-値のイオンアドレスecfノー[RFC3455]ノー[RFC3455]icidに発生しているノー[RFC3455]ノー[RFC3455]ノー[RFC3455]
Camarillo Best Current Practice [Page 4] RFC 3968 SIP Parameter Registry December 2004
キャマリロの最も良い現在の習慣[4ページ]RFC3968はパラメタ登録2004年12月にちびちび飲みます。
P-DCS-Billing-Info called No [RFC 3603]
P-DCS-Billing-Info calling No [RFC 3603]
P-DCS-Billing-Info charge No [RFC 3603]
P-DCS-Billing-Info locroute No [RFC 3603]
P-DCS-Billing-Info rksgroup No [RFC 3603]
P-DCS-Billing-Info routing No [RFC 3603]
P-DCS-LAES content No [RFC 3603]
P-DCS-LAES key No [RFC 3603]
P-DCS-Redirect count No [RFC 3603]
P-DCS-Redirect redirector-uri No [RFC 3603]
Proxy-Authenticate algorithm Yes [RFC 3261]
[[RFC 3310]]
Proxy-Authenticate domain No [RFC 3261]
Proxy-Authenticate nonce No [RFC 3261]
Proxy-Authenticate opaque No [RFC 3261]
Proxy-Authenticate qop Yes [RFC 3261]
Proxy-Authenticate realm No [RFC 3261]
Proxy-Authenticate stale Yes [RFC 3261]
Proxy-Authorization algorithm Yes [RFC 3261]
[[RFC 3310]]
Proxy-Authorization auts No [RFC 3310]
Proxy-Authorization cnonce No [RFC 3261]
Proxy-Authorization nc No [RFC 3261]
Proxy-Authorization nonce No [RFC 3261]
Proxy-Authorization opaque No [RFC 3261]
Proxy-Authorization qop Yes [RFC 3261]
Proxy-Authorization realm No [RFC 3261]
Proxy-Authorization response No [RFC 3261]
Proxy-Authorization uri No [RFC 3261]
Proxy-Authorization username No [RFC 3261]
Reason cause Yes [RFC 3326]
Reason text No [RFC 3326]
Retry-After duration No [RFC 3261]
Security-Client alg Yes [RFC 3329]
Security-Client ealg Yes [RFC 3329]
Security-Client d-alg Yes [RFC 3329]
Security-Client d-qop Yes [RFC 3329]
Security-Client d-ver No [RFC 3329]
Security-Client mod Yes [RFC 3329]
Security-Client port1 No [RFC 3329]
Security-Client port2 No [RFC 3329]
Security-Client prot Yes [RFC 3329]
Security-Client q No [RFC 3329]
Security-Client spi No [RFC 3329]
Security-Server alg Yes [RFC 3329]
Security-Server ealg Yes [RFC 3329]
Security-Server d-alg Yes [RFC 3329]
Security-Server d-qop Yes [RFC 3329]
RFC3603P-DCS支払いインフォメーションがない料金RFC3603P-DCS支払いインフォメーションがないlocrouteノーRFCをどんなRFC3261もProxy認証しない3603年のP-DCS支払いインフォメーションrksgroupはい、RFC3261RFC3310がProxy認証するどんなRFC3603もProxy認証しないどんなP-DCS再直接の主要なRFC3603のいいえRFC3603P-DCS再直接のカウントP-DCS-LAESノーRFC3603リダイレクタ-uriのRFC3603のP-DCS-LAESの満足しているアルゴリズムがないも発送しないどんなRFC3603P-DCS支払いインフォメーションドメインとも呼びながらRFC3603P-DCS支払いインフォメーションがないと呼ばれるP-DCS支払いインフォメーション一回だけ; どんなRFC3261もProxy認証しない、不明瞭なノーRFC3261がはい、RFC3261がProxy認証するqopをProxy認証する、どんなRFC3261もProxy認証しない分野が古くさくなる、はい、一回だけのRFC3261のいいえRFC3261Proxy-認可不明瞭なはい、3261RFC3310Proxy-認可がautsするProxy-認可アルゴリズムRFCいいえRFC3310Proxy-認可cnonceいいえRFC3261Proxy-認可ncいいえRFC3261Proxy-認可ノーRFC3261Proxy-認可ははい、RFC3261Proxy-認可分野ノーRFC3261Proxyをqopします。-認可応答RFC3261Proxy-認可がないuri RFC3261Proxy-認可がないユーザ名ノーRFC3261Reasonがはい、はい、RFC3329Security-クライアントがealgするSecurity-クライアントのRFC3326ReasonテキストいいえRFC3326後のRetry持続時間ノーRFC3261algにはい、RFC3329Security-クライアントd-algを引き起こす、はい、RFC3329Security-クライアントd-qop、はい、RFC3329Security-クライアント; 3329年のd-verはい、RFC3329Security-クライアントがないモッズRFC Security-クライアントport1ノーRFC3329Security-クライアントport2はい、RFC3329Security-クライアントqノーRFC3329Security-クライアントがspiするRFC3329Security-クライアントがないprotノーRFC3329Security-サーバがはい、RFC3329Security-サーバealgをalgする、はい、RFC3329Security-サーバd-alg、はい、RFC3329Security-サーバd-qop、はい。[RFC3329]
Camarillo Best Current Practice [Page 5] RFC 3968 SIP Parameter Registry December 2004
キャマリロの最も良い現在の習慣[5ページ]RFC3968はパラメタ登録2004年12月にちびちび飲みます。
Security-Server d-ver No [RFC 3329]
Security-Server mod Yes [RFC 3329]
Security-Server port1 No [RFC 3329]
Security-Server port2 No [RFC 3329]
Security-Server prot Yes [RFC 3329]
Security-Server q No [RFC 3329]
Security-Server spi No [RFC 3329]
Security-Verify alg Yes [RFC 3329]
Security-Verify ealg Yes [RFC 3329]
Security-Verify d-alg Yes [RFC 3329]
Security-Verify d-qop Yes [RFC 3329]
Security-Verify d-ver No [RFC 3329]
Security-Verify mod Yes [RFC 3329]
Security-Verify port1 No [RFC 3329]
Security-Verify port2 No [RFC 3329]
Security-Verify prot Yes [RFC 3329]
Security-Verify q No [RFC 3329]
Security-Verify spi No [RFC 3329]
Subscription-State expires No [RFC 3265]
Subscription-State reason Yes [RFC 3265]
Subscription-State retry-after No [RFC 3265]
To tag No [RFC 3261]
Via branch No [RFC 3261]
Via comp Yes [RFC 3486]
Via maddr No [RFC 3261]
Via received No [RFC 3261]
Via rport No [RFC 3581]
Via ttl No [RFC 3261]
WWW-Authenticate algorithm Yes [RFC 3261]
[[RFC 3310]]
WWW-Authenticate domain Yes [RFC 3261]
WWW-Authenticate nonce No [RFC 3261]
WWW-Authenticate opaque No [RFC 3261]
WWW-Authenticate qop Yes [RFC 3261]
WWW-Authenticate realm No [RFC 3261]
WWW-Authenticate stale Yes [RFC 3261]
RFC3329Security-サーバがないことのセキュリティサーバのd-verのモッズ風のはい、はい、algするいいえ、RFC3329がはい、RFC3329についてSecurity確かめるRFC3329Security-サーバq RFC3329Security-サーバがないspiがはい、RFCをealgすることをSecurity確かめるRFC3329Security-サーバport1RFC3329Security-サーバがないport2RFC3329Security-サーバがないprot3329がはい、RFC3329がSecurity確かめるd-algについてSecurity確かめる、はい、RFC3329がSecurity確かめるd-qop、d-verノーRFC3329、がはい、RFC3329がSecurity確かめるモッズについてSecurity確かめる、どんなRFC3329もSecurity確かめないport1; protにspiしないはい、RFC3329が、Security確かめるRFC3329が、Security確かめるqノーRFC3329、が3329年のRFC Subscription-状態について全くSecurity確かめるport2ノー、が容認されたVia maddrのVia rportいいえRFC3581Via ttlいいえRFC3261ViaいいえRFC3261ノーRFC3261がWWW認証しないはい、3265年のSubscription-州の後の再試行ノーRFC3265Toがはい、ViaのいいえRFC3261ViaブランチノーRFC3261コンピュータRFCにタグ付けをするというRFC3265Subscription-州の理由RFC3486を全く吐き出す、アルゴリズム、はい、RFC3261RFC3310がはい、ドメインRFCをWWW認証する、3261]がWWW認証する、一回だけのノー[RFC3261]が[RFC3261]がqopにWWW認証する不明瞭なノーをWWW認証する、はい、[RFC3261]が聞き古したであるいいえ、[RFC3261]がWWW認証する分野をWWW認証する、はい。[RFC3261]
4.2. Registration Policy for SIP Header Field Parameters
4.2. 一口ヘッダーフィールドパラメタのための登録方針
As per the terminology in RFC 2434 [2], the registration policy for SIP header field parameters and parameter values shall be "IETF Consensus."
RFC2434[2]の用語に従って、SIPヘッダーフィールドパラメタとパラメタ値のための登録方針は「IETFコンセンサス」でしょう。
For the purposes of this registry, the parameter or the parameter value for which IANA registration is requested MUST be defined by an RFC. There is no requirement that this RFC be standards-track.
この登録の目的のために、RFCはIANA登録が要求されているパラメタかパラメタ値を定義しなければなりません。 このRFCが標準化過程であるという要件が全くありません。
Camarillo Best Current Practice [Page 6] RFC 3968 SIP Parameter Registry December 2004
キャマリロの最も良い現在の習慣[6ページ]RFC3968はパラメタ登録2004年12月にちびちび飲みます。
5. Security Considerations
5. セキュリティ問題
The registry in this document does not in itself have security considerations. However, as mentioned in RFC 3427, an important reason for the IETF to manage the extensions of SIP is to ensure that all extensions and parameters are able to provide secure usage. The supporting RFC publications for parameter registrations described this specification MUST provide detailed security considerations for them.
登録には、本来、セキュリティ問題が本書ではありません。 しかしながら、IETFがSIPの拡大を管理する重要な理由はRFC3427で言及されるようにすべての拡大とパラメタが安全な用法を提供できるのを保証することです。 パラメタ登録証明書がこの仕様を説明したので、支持しているRFC刊行物は詳細なセキュリティ問題をそれらに提供しなければなりません。
6. Acknowledgements
6. 承認
Jonathan Rosenberg, Henning Schulzrinne, Rohan Mahy, Dean Willis, Aki Niemi, Bill Marshall, Miguel A. Garcia-Martin, Jean Francois Mule, and Allison Mankin provided useful comments on this document.
ジョナサン・ローゼンバーグ、ヘニングSchulzrinne、Rohanマーイ、ディーン・ウィリス、アキNiemi、ビル・マーシャル、ミゲル・A.ガルシア-マーチン、ジーンフランソアMule、およびアリソン・マンキンはこのドキュメントの役に立つコメントを提供しました。
7. Normative References
7. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[3] 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.
[3] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[4] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC 3427, December 2002.
[4] マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼンは「セッション開始プロトコル(一口)のために過程を変えます」、BCP67、RFC3427、2002年12月。
Author's Address
作者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Camarillo Best Current Practice [Page 7] RFC 3968 SIP Parameter Registry December 2004
キャマリロの最も良い現在の習慣[7ページ]RFC3968はパラメタ登録2004年12月にちびちび飲みます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Camarillo Best Current Practice [Page 8]
キャマリロの最も良い現在の習慣[8ページ]
一覧
スポンサーリンク
