RFC3795 日本語訳
3795 Survey of IPv4 Addresses in Currently Deployed IETF ApplicationArea Standards Track and Experimental Documents. R. Sofia, P. Nesser,II. June 2004. (Format: TXT=92584 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Sofia
Request for Comments: 3795 P. Nesser, II
Category: Informational Nesser & Nesser Consulting
June 2004
コメントを求めるワーキンググループR.ソフィアの要求をネットワークでつないでください: 3795P.Nesser、IIカテゴリ: 2004年6月に相談する情報のNesser&Nesser
Survey of IPv4 Addresses in Currently Deployed
IETF Application Area Standards Track and Experimental Documents
IPv4の調査は、現在配布しているIETFでアプリケーションが領域標準化過程と実験ドキュメントであると扱います。
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6.
このドキュメントがネットワーク・アドレス独立者になるように仕様を再設計して、再履行する際に必要なステップをはっきりさせる試みにおける依存を扱うIPv4について説明するか、または少なくとも、二元的であるのはIPv4とIPv6をサポートします。 この変遷はそれらの1つがアドレシング図式が使用したIPのタイプの如何にかかわらず形式への現在のIPv4依存する仕様の発展であるいくつかの中間の段階を必要とします。 したがって、仕様がネットワーク・アドレス独立者になるか、または少なくともサポートIPv4とIPv6が二元的であるように再設計されていて、再履行されることが望まれています。
To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, and Proposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience.
そのステップを達成するために、Experimental RFCsと同様に現在の規格(完全、Draft、およびProposed)によって経験されたすべてのIPv4の依存について調査して、記録するのが必要です。 したがって、このドキュメントは記録されたStandardsが経験するかもしれない依存のそんなに配布しているIETF Application Areaを扱うIPv4について説明します。
Sofia & Nesser II Informational [Page 1] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[1ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organization. . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . . 10
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . 34
7. Summary of Results . . . . . . . . . . . . . . . . . . . . . . 45
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 48
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.1. Normative References. . . . . . . . . . . . . . . . . . 48
10.2. Informative References. . . . . . . . . . . . . . . . . 48
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 50
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 組織を記録してください。 . . . . . . . . . . . . . . . . . . . . 2 3. 完全な規格. . . . . . . . . . . . . . . . . . . . . . . . 3 4。 規格を作成してください。 . . . . . . . . . . . . . . . . . . . . . . . 5 5. 提案された標準. . . . . . . . . . . . . . . . . . . . . . 10 6。 実験的なRFCs。 . . . . . . . . . . . . . . . . . . . . . . 34 7. 結果. . . . . . . . . . . . . . . . . . . . . . 45 8の概要。 承認. . . . . . . . . . . . . . . . . . . . . . . 47 9。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 48 10. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 48 10.1。 引用規格。 . . . . . . . . . . . . . . . . . 48 10.2. 有益な参照。 . . . . . . . . . . . . . . . . 48 11. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 49 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 50
1. Introduction
1. 序論
The exhaustive documentation of IPv4 addresses usage in currently deployed IETF documented standards has now been broken into seven documents conforming to current IETF main areas, i.e., Applications, Internet, Operations and Management, Routing, Sub-IP, and Transport. A general overview of the documentation, as well as followed methodology and historical perspective can be found in [1]. This document represents one of the seven blocks, and its scope is limited to surveying possible IPv4 dependencies in IETF Application Area documented Standards.
現在のIPv4アドレス用法の徹底的なドキュメンテーションは現在のIETF主な領域、すなわち、Applications、インターネット、Operations、Management、ルート設定、Sub-IP、およびTransportに一致している7通のドキュメントを記録された規格が今細かく分けられたIETFに配布しました。 また、ドキュメンテーションの概要であり、続かれているように[1]で方法論と歴史観を見つけることができます。 このドキュメントは7ブロックの1つを表します、そして、範囲はIETF Application AreaのIPv4の依存がStandardsを記録したのが可能な測量学に制限されます。
2. Document Organization
2. ドキュメント組織
The remainder sections are organized as follows. Sections 3, 4, 5, and 6 describe, respectively, the raw analysis of Internet Standards [2]:
残り部は以下の通り組織化されます。 セクション3、4、5、および6 それぞれインターネットStandards[2]の生の分析について説明してください:
Full, Draft, and Proposed Standards, and Experimental RFCs. For each section, standards are analysed by their RFC number, in sequential order, i.e., from RFC 1 to RFC 3200. Exceptions to this are some RFCs above RFC 3200. They have been included, given that they obsoleted RFCs within the range 1-3200. Also, the comments presented for each RFC are raw in their nature, i.e., each RFC is simply analysed in terms of possible IPv4 addressing dependencies. Finally, Section 7 presents a global overview of the data described in the previous sections, and suggests possible future steps.
完全で、草稿の、そして、提案された規格、および実験的なRFCs。 各セクションにおいて、規格はすなわち、それらのRFC番号、連続した注文、RFC1からRFC3200まで分析されます。 これへの例外はRFC3200の上のいくつかのRFCsです。 彼らが範囲1-3200の中でRFCsを時代遅れにしたなら、それらは含まれています。 また、各RFCのために提示されたコメントも彼らの自然で生である、すなわち、各RFCは依存を扱う可能なIPv4に関して単に分析されます。 最終的に、セクション7は、前項で説明されたデータのグローバルな概要を提示して、可能な今後のステップを示します。
Sofia & Nesser II Informational [Page 2] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[2ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
3. Full Standards
3. 完全な規格
Internet Full Standards have attained the highest level of maturity on the standards track process. They are commonly referred to as "Standards", and represent fully technical mature specifications that are widely implemented and used throughout the Internet.
インターネットFull Standardsは標準化過程プロセスの上で円熟の最高水準に達しました。 彼らは、一般的に「規格」と呼ばれて、広く履行されて、インターネット中で使用される完全に技術的な熟している仕様を表します。
3.1. RFC854: Telnet Protocol Specifications
3.1. RFC854: テルネット・プロトコル仕様
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.2. RFC 855: Telnet Option Specifications
3.2. RFC855: telnetオプション仕様
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.3. RFC 856: Binary Transmission Telnet Option
3.3. RFC856: 2進のトランスミッションtelnetオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.4. RFC 857: Echo Telnet Option
3.4. RFC857: エコーtelnetオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.5. RFC 858: Suppress Go Ahead Telnet Option
3.5. RFC858: 先のtelnetがゆだねる碁を抑圧してください。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.6. RFC 859: Status Telnet Option
3.6. RFC859: 状態telnetオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.7. RFC 860: Timing Mark Telnet Option
3.7. RFC860: タイミング・マークtelnetオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.8. RFC 861: Extended Options List Telnet Option
3.8. RFC861: 拡張オプションリストtelnetオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.9. RFC 862: Echo Protocol
3.9. RFC862: エコープロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.10. RFC 863: Discard Protocol
3.10. RFC863: プロトコルを捨ててください。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 3] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[3ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
3.11. RFC 864: Character Generator Protocol
3.11. RFC864: 文字発生機構プロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.12. RFC 865: Quote of the Day Protocol
3.12. RFC865: 今日の名言プロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.13. RFC 866: Active Users Protocol
3.13. RFC866: アクティブなユーザプロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.14. RFC 867: Daytime Protocol
3.14. RFC867: 昼間のプロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.15. RFC 868: Time Server Protocol
3.15. RFC868: 時間サーバプロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.16. RFC 959: File Transfer Protocol
3.16. RFC959: ファイル転送プロトコル
Section 4.1.2 (TRANSFER PARAMETER COMMANDS) describes the port command using the following format:
セクション4.1 .2 (TRANSFER PARAMETER COMMANDS)は以下の形式を使用することで移植コマンドについて説明します:
"A port command would be:
PORT h1,h2,h3,h4,p1,p2
where h1 is the high order 8 bits of the internet host
address."
「移植コマンドは以下の通りでしょう」 「PORT h1、h2、h3、h4、p1、h1がインターネットホストの8ビットが扱う高位であるp2。」
This is a clear reference to an IPv4 address. In sections 4.2.1 and 4.2.2, on reply codes, the code:
これはIPv4アドレスの明確な参照です。 コネは4.2に.1と4.2を区分します。.2 コード、コードは返答します:
"227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)"
「227入る受け身の形態(h1、h2、h3、h4、p1、p2)」
also needs to be reworked for IPv6 addressing. Also, Section 5.3.2 (FTP COMMAND ARGUMENTS) contains:
また、IPv6アドレシングのために作りなおされるのが必要です。 (FTP COMMAND ARGUMENTS)が含むセクション5.3.2も:
"<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number>
<number> ::= any decimal integer 1 through 255"
「<ホスト番号>:、:、」= <番号>、<番号>、<番号>、<番号><ポートナンバー>:、:= <番号>、<数の><番号>:、:= 「どんな10進整数1〜255も」
This needs to be solved to transition to IPv6.
これは、IPv6への変遷に解決される必要があります。
3.17. RFC 1350: Trivial File Transfer Protocol
3.17. RFC1350: トリビアル・ファイル転送プロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 4] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[4ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
3.18. RFC 1870: SMTP Service Extension for Message Size
Declaration
3.18. RFC1870: メッセージサイズ宣言のためのSMTPサービス拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.19. RFC 1939: Post Office Protocol - Version 3
3.19. RFC1939: POP--バージョン3
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.20. RFC 2920: SMTP Service Extension for Command Pipelining
3.20. RFC2920: コマンド連続送信のためのSMTPサービス拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4. Draft Standards
4. 草稿規格
Draft Standards is the nomenclature given to specifications that are on the penultimate maturity level of the IETF standards track process. They are considered to be final specifications, which may only experience changes to solve specific problems found. A specification is only considered to be a Draft Standard if there are at least two known independent and interoperable implementations. Hence, Draft Standards are usually quite mature and widely used.
草稿StandardsはIETF標準化過程プロセスの終わりから二番目の成熟レベルにある仕様に与えられた用語体系です。 それらは最終的な仕様であると考えられます。(仕様は、見つけられた特定の問題を解決するために変化になるだけであるかもしれません)。 少なくとも2つの知られている独立していて共同利用できる実装がある場合にだけ、仕様はDraft Standardであると考えられます。 したがって、Draft Standardsは通常、かなり熟して広く使用されています。
4.1. RFC 954: NICNAME/WHOIS
4.1. RFC954: NICNAME/WHOIS
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.2. RFC 1184: Telnet Linemode Option
4.2. RFC1184: telnet Linemodeオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.3. RFC 1288: The Finger User Information Protocol
4.3. RFC1288: 指のユーザー情報プロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.4. RFC 1305: Network Time Protocol (Version 3) Specification,
Implementation
4.4. RFC1305: ネットワーク時間プロトコル(バージョン3)仕様、実装
Section 3.2.1 (Common Variables) provides the following variable definitions:
セクション3.2 .1 (一般的なVariables)は以下の可変定義を提供します:
"Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port
(peer.peerport, pkt.peerport): These are the 32-bit Internet
address and 16-bit port number of the peer.
「同輩Address(peer.peeraddr、pkt.peeraddr)、Peer Port(peer.peerport、pkt.peerport):」 これらは、同輩の32ビットのインターネット・アドレスと16ビットのポートナンバーです。
Sofia & Nesser II Informational [Page 5] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[5ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
Host Address (peer.hostaddr, pkt.hostaddr), Host Port
(peer.hostport, pkt.hostport): These are the 32-bit Internet
address and 16-bit port number of the host. They are included
among the state variables to support multi-homing."
Address(peer.hostaddr、pkt.hostaddr)、Host Port(peer.hostport、pkt.hostport)を接待してください: これらは、ホストの32ビットのインターネット・アドレスと16ビットのポートナンバーです。 「それらはマルチホーミングをサポートするために州の変数の中に含まれています。」
Section 3.4.3 (Receive Procedure) defines the following procedure:
セクション3.4 .3 (Procedureを受けます) 以下の手順を定義します:
"The source and destination Internet addresses and ports in the IP
and UDP headers are matched to the correct peer. If there is no
match a new instantiation of the protocol machine is created and
the association mobilized."
「IPとUDPヘッダーのソース、送付先インターネットアドレス、およびポートは正しい同輩に合わせられています。」 「マッチが全くなければ、プロトコルマシンの新しい具体化は作成されました、そして、協会は流動しました。」
Section 3.6 (Access Control Issues) proposes a simple authentication scheme in the following way:
セクション3.6(アクセスControl Issues)は以下の方法で簡易認証体系を提案します:
"If a more comprehensive trust model is required, the design can
be based on an access-control list with each entry consisting of a
32-bit Internet address, 32-bit mask and three-bit mode. If the
logical AND of the source address (pkt.peeraddr) and the mask in
an entry matches the corresponding address in the entry and the
mode (pkt.mode) matches the mode in the entry, the access is
allowed; otherwise an ICMP error message is returned to the
requestor. Through appropriate choice of mask, it is possible to
restrict requests by mode to individual addresses, a particular
subnet or net addresses, or have no restriction at all. The
access-control list would then serve as a filter controlling which
peers could create associations."
「より包括的な信頼モデルが必要であるなら、デザインは各エントリーが32ビットのインターネット・アドレス、32ビットのマスク、および3ビットのモードから成っているアクセスコントロールリストに基づくことができます。」 ソースアドレス(pkt.peeraddr)とエントリーにおけるマスクの論理的なANDがエントリーで対応するアドレスに合っていて、モード(pkt.mode)がエントリーでモードに合っているなら、アクセスは許されています。 さもなければ、ICMPエラーメッセージを要請者に返します。 マスクの適当な選択で、モードで要求を個々のアドレス、特定のサブネットまたはネットのアドレスに制限するか、または制限を全く持っていないのが可能です。 「そして、どの同輩を監督するフィルタが協会を創設するかもしれないようにアクセスコントロールリストは役立つでしょう。」
Appendix B Section 3 (B.3 Commands) defines the following command:
付録Bセクション3(B.3 Commands)は以下のコマンドを定義します:
"Set Trap Address/Port (6): The command association identifier,
status and data fields are ignored. The address and port number
for subsequent trap messages are taken from the source address and
port of the control message itself. The initial trap counter for
trap response messages is taken from the sequence field of the
command. The response association identifier, status and data
fields are not significant. Implementations should include sanity
timeouts which prevent trap transmissions if the monitoring
program does not renew this information after a lengthy interval."
「トラップ・アドレス/ポート(6)を設定してください」 コマンド協会識別子、状態、およびデータ・フィールドは無視されます。 コントロールメッセージ自体のソースアドレスとポートからその後のトラップメッセージのためのアドレスとポートナンバーを取ります。 コマンドの系列分野から罠応答メッセージのための初期の罠カウンタを取ります。 応答協会識別子、状態、およびデータ・フィールドは重要ではありません。 「実装は監視プログラムが長い間隔の後にこの情報を更新しないなら罠送信を防ぐ正気タイムアウトを含むべきです。」
The address clearly assumes the IPv4 version. Also, there are numerous places in sample code and in algorithms that use the above mentioned variables. It seems that there is no reason to modify the actual protocol. A small number of textual changes and an update to implementations, so they can understand both IPv4 and IPv6 addresses, will suffice to have a NTP version that works on both network layer protocols.
アドレスは明確にIPv4バージョンを仮定します。 また、サンプルコードと上記の変数を使用するアルゴリズムには多数の場所があります。 実際のプロトコルを変更する理由が全くないように思えます。 彼らがIPv4とIPv6アドレスの両方を理解できて、少ない数の原文の変化と実装へのアップデートは、両方のネットワーク層プロトコルに取り組むNTPバージョンを持つために十分でしょう。
Sofia & Nesser II Informational [Page 6] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[6ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
4.5. RFC 1575: An Echo Function for CLNP (ISO 8473)
4.5. RFC1575: CLNPのためのエコー機能(ISO8473)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.6. RFC 1652: SMTP Service Extension for 8bit-MIME Transport
4.6. RFC1652: 8ビットのMIME輸送のためのSMTPサービス拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.7. RFC 1832: eXternal Data Representation Standard
4.7. RFC1832: 外部データ表現規格
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.8. RFC 2045: Multipurpose Internet Mail Extensions (MIME),
Part One: Format of Internet Message Bodies
4.8. RFC2045: マルチパーパスインターネットメールエクステンション(MIME)、パート1: インターネットメッセージ本体の形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.9. RFC 2046: MIME, Part Two: Media Types
4.9. RFC2046: MIME、パートTwo: メディアタイプ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.10. RFC 2047: MIME, Part Three: Message Header Extensions
for Non-ASCII Text
4.10. RFC2047: MIME、パートThree: 非ASCIIテキストのためのメッセージヘッダー拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.11. RFC 2049: MIME Part Five: Conformance Criteria and
Examples
4.11. RFC2049: パートFiveをまねてください: 順応評価基準と例
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.12. RFC 2279: UTF-8, a transformation format of ISO 10646
4.12. RFC2279: UTF-8、ISO10646の変換形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.13. RFC 2347: TFTP Option Extension
4.13. RFC2347: TFTPオプション拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 7] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[7ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
4.14. RFC 2348: TFTP Blocksize Option
4.14. RFC2348: TFTP Blocksizeオプション
Section "Blocksize Option Specification" gives the following example:
「Blocksizeオプション仕様」というセクションは以下の例を出します:
"For example:
「例えば:、」
+-------+--------+---+--------+---+--------+---+--------+---+
| 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+
+-------+--------+---+--------+---+--------+---+--------+---+ | 1 | foobar| 0 | 八重奏| 0 | blksizeします。| 0 | 1428 | 0 | +-------+--------+---+--------+---+--------+---+--------+---+
is a Read Request, for the file named "foobar", in octet (binary)
transfer mode, with a block size of 1428 octets (Ethernet MTU,
less the TFTP, UDP and IP header lengths)."
「ファイルのためのRead Requestが1428の八重奏のブロック・サイズで八重奏(バイナリー)転送モードで"foobar"と命名される、(イーサネットMTUで、より少ない、TFTP、UDP、およびIPヘッダ長)、」
Clearly, the given blocksize example would not work with IPv6 header sizes, but it has no practical implications, since larger blocksizes are also available.
明確に、付与は例をblocksizeします。IPv6ヘッダーサイズで働いていないでしょうが、それにはどんな実用的な意味もない、 より大きい、blocksizesする、また、利用可能です。
4.15. RFC 2349: TFTP Timeout Interval and Transfer Size Options
4.15. RFC2349: TFTPタイムアウト間隔と転送サイズオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.16. RFC 2355: TN3270 Enhancements
4.16. RFC2355: TN3270増進
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.17. RFC 2396: Uniform Resource Identifiers (URI): Generic
Syntax
4.17. RFC2396: Uniform Resource Identifier(URI): ジェネリック構文
Section 3.2.2. (Server-based Naming Authority) states:
セクション3.2.2。 (サーバベースの命名権威) 州:
"The host is a domain name of a network host, or its IPv4 address
as a set of four decimal digit groups separated by ".". Literal
IPv6 addresses are not supported.
...
Note: A suitable representation for including a literal IPv6
address as the host part of a URL is desired, but has not yet been
determined or implemented in practice."
「「ホストは、ネットワークホストのドメイン名、またはグループが分離した1セットの4 10進数字としてそのIPv4アドレスです」。」 文字通りのIPv6アドレスはサポートされません。 ... 以下に注意してください。 「1つのURLのホスト部分として文字通りのIPv6アドレスを含む適当な表現は、実際にはまだ望まれていますが、決定もしませんし、実装されてもいません。」
4.18. RFC 2616: Hypertext Transfer Protocol HTTP/1.1
4.18. RFC2616: ハイパーテキスト転送プロトコルHTTP/1.1
Section 3.2.2 (http URL) states:
セクション3.2 .2 (http URL)は以下を述べます。
"The "http" scheme is used to locate network resources via the
HTTP protocol. This section defines the scheme-specific syntax
and semantics for http URLs.
「"http"体系はHTTPプロトコルでネットワーク資源の場所を見つけるのに使用されます。」 このセクションはhttp URLのために体系特有の構文と意味論を定義します。
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
http_URL=は「以下をhttpします」。 「//」ホスト[「:」 ポート][腹筋_経路[“?"質問]]
Sofia & Nesser II Informational [Page 8] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[8ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
If the port is empty or not given, port 80 is assumed. The
semantics are that the identified resource is located at the
server listening for TCP connections on that port of that host,
and the Request-URI for the resource is abs_path (section 5.1.2).
The use of IP addresses in URLs SHOULD be avoided whenever
possible (see RFC 1900 [24])."
ポートが人影がないか考えないで、ポート80は想定されます。 意味論は特定されたリソースがそのホストのそのポートの上でTCP接続の聞こうとするサーバで位置しているということです、そして、リソースのためのRequest-URIは腹筋_経路(セクション5.1.2)です。 「使用、可能であるときはいつも、URL SHOULDのIPアドレスでは、避けられてください、(RFC1900[24])を見てください、」
The text is version neutral, but it is unclear whether individual implementations will support IPv6 addresses. In fact, the use of the ":"separator in IPv6 addresses will cause misinterpretation when parsing URI's. There are other discussions regarding a server recognizing its own IP addresses, spoofing DNS/IP address combinations, as well as issues regarding multiple HTTP servers running on a single IP interface. Again, the text is version neutral, but clearly, such statements represent implementation issues.
テキストはバージョン中立ですが、個々の実装がIPv6にアドレスをサポートするかどうかが、不明瞭です。 「事実上、」 : 「ユリのものを分析するとき、IPv6アドレスの分離符は誤解を引き起こすこと」の使用。 それ自身のIPアドレスを認識するサーバに関して他の議論があります、DNS/IPアドレスが組み合わせであると偽造して、単一のIPインタフェースで走る複数のHTTPサーバに関する問題と同様に。 一方、テキストはバージョン中立ですが、明確に、そのような声明は導入問題を表します。
4.19. RFC 3191: Minimal GSTN address format in Internet Mail
4.19. RFC3191: インターネットメールにおける最小量のGSTNアドレス形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.20. RFC 3192: Minimal FAX address format in Internet Mail
4.20. RFC3192: インターネットメールにおける最小量のFAXアドレス形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.21. RFC 3282: Content Language Headers
4.21. RFC3282: 満足している言語ヘッダー
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.22. RFC 3461: Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications
4.22. RFC3461: 配送状態通知のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.23. RFC 3462: The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages
4.23. RFC3462: メールのシステムの管理メッセージの報告のための複合/レポートcontent type
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.24. RFC 3463: Enhanced Mail System Status Codes
4.24. RFC3463: 高められたメールシステムステータスコード
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.25. RFC 3464: An Extensible Message Format for Delivery Status
Notifications
4.25. RFC3464: 配送状態通知のための広げることができるメッセージ・フォーマット
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 9] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[9ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5. Proposed Standards
5. 提案された標準
Proposed Standards represent initial level documents in the IETF standards track process. They are stable in terms of design, but do not require the existence of implementations. In several cases, these specifications are simply proposed as solid technical ideas, to be analysed by the Internet community, but are never implemented or advanced in the IETF standards process.
提案されたStandardsはIETF標準化過程プロセスに初期の平らなドキュメントを表します。 それらはデザインで安定していますが、実装の存在を必要としないでください。 いろいろな場合に、これらの仕様は、IETF標準化過程でインターネットコミュニティによって分析されるためにしっかりした技術的な考えとして単に提案されますが、履行されるか、または決して進められません。
5.1. RFC 698: Telnet extended ASCII option
5.1. RFC698: telnetの拡張ASCIIオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.2. RFC 726: Remote Controlled Transmission and Echoing Telnet
option
5.2. RFC726: リモートControlled TransmissionとEchoing Telnetオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.3. RFC 727: Telnet logout option
5.3. RFC727: telnetがログアウトする、オプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.4. RFC 735: Revised Telnet byte macro option
5.4. RFC735: 改訂されたTelnetバイトマクロオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.5. RFC 736: Telnet SUPDUP option
5.5. RFC736: telnet SUPDUPオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.6. RFC 749: Telnet SUPDUP-Output option
5.6. RFC749: telnet SUPDUP-出力オプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.7. RFC 779: Telnet send-location option
5.7. RFC779: 位置を発信させているtelnetオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.8. RFC 885: Telnet end of record option
5.8. RFC885: 記録的なオプションのtelnet終わり
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.9. RFC 927: TACACS user identification Telnet option
5.9. RFC927: TACACSユーザ登録名Telnetオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 10] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[10ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.10. RFC 933: Output marking Telnet option
5.10. RFC933: Telnetがオプションであるとマークする出力
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.11. RFC 946: Telnet terminal location number option
5.11. RFC946: telnet端末位置の数のオプション
Section "TTYLOC Number" states:
セクション「TTYLOC番号」州:
"The TTYLOC number is a 64-bit number composed of two (2) 32-bit
numbers: The 32-bit official ARPA Internet host address (may be
any one of the addresses for multi-homed hosts) and a 32-bit
number representing the terminal on the specified host. The host
address of [0.0.0.0] is defined to be "unknown", the terminal
number of FFFFFFFF (hex, r or-1 in decimal) is defined to be
"unknown" and the terminal number of FFFFFFFE (hex, or -2 in
decimal) is defined to be "detached" for processes that are not
attached to a terminal."
「TTYLOC番号は2つの(2)の32ビットの番号で構成された64ビットの数です」 32ビットの公式のARPAインターネットホスト・アドレス、(アドレスのどれかであるかもしれない、マルチ、家へ帰り、ホスト) そして、指定されたホストの上の端末を表す32ビットの数。 中、「アドレスをホスティングする、[0.0、.0、.0は]「未知である」ために定義されます、FFFFFFFFの端末の数、(十六進法、r、-1、小数) 「」 端末の数の未知のFFFFFFFE(十六進法、または小数における-2)は定義端末に付けられていないプロセスのために「取り外される」ためににされる」ようになるように、定義されます。
The clear reference to 32-bit numbers, and to the use of literal addresses in the form [0.0.0.0] is clearly an IPv4-dependency. Thus, the text above needs to be re-written.
32ビットの数、およびフォームにおける文字通りのアドレスの使用の明確な参照、[0.0 .0 .0は]明確にIPv4-依存です。 その結果、書き直されるべき必要性を超えたテキスト。
5.12. RFC 977: Network News Transfer Protocol
5.12. RFC977: ネットワークの電子情報を転送するプロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.13. RFC 1041: Telnet 3270 regime option
5.13. RFC1041: telnet3270政権オプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.14. RFC 1043: Telnet Data Entry Terminal option: DODIIS
implementation
5.14. RFC1043: telnet Data Entry Terminalオプション: DODIIS実装
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.15. RFC 1053: Telnet X.3 PAD option
5.15. RFC1053: telnet X.3 PADオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.16. RFC 1073: Telnet window size option
5.16. RFC1073: telnetウィンドウサイズオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.17. RFC 1079: Telnet terminal speed option
5.17. RFC1079: telnet端末速度オプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 11] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[11ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.18. RFC 1091: Telnet terminal-type option
5.18. RFC1091: telnet端末のタイプオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.19. RFC 1096: Telnet X display location option
5.19. RFC1096: telnet Xディスプレイ位置のオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.20. RFC 1274: The COSINE and Internet X.500 Schema
5.20. RFC1274: コサインとインターネットX.500図式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.21. RFC 1276: Replication and Distributed Operations extensions
to provide an Internet Directory using X.500
5.21. RFC1276: X.500を使用することでインターネットディレクトリを提供する模写とDistributed Operations拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.22. RFC 1314: A File Format for the Exchange of Images in the
Internet
5.22. RFC1314: インターネットのイメージズの交換のためのファイル形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.23. RFC 1328: X.400 1988 to 1984 downgrading
5.23. RFC1328: X.400 1988年から1984格下げ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.24. RFC 1372: Telnet Remote Flow Control Option
5.24. RFC1372: telnetのリモートフロー制御オプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.25. RFC 1415: FTP-FTAM Gateway Specification
5.25. RFC1415: FTP-FTAMゲートウェイ仕様
Since this document defines a gateway for interaction between FTAM and FTP, the only possible IPv4 dependencies are associated with FTP, which has already been investigated above, in section 3.16.
このドキュメントがFTAMとFTPとの相互作用のためにゲートウェイを定義するので、唯一の可能なIPv4の依存がFTPに関連しています、セクション3.16で。(既に、上でFTPを調査してあります)。
5.26. RFC 1494: Equivalences between 1988 X.400 and RFC-822
Message Bodies
5.26. RFC1494: 1988X.400とRFC-822メッセージボディーの間の等価性
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.27. RFC 1496: Rules for downgrading messages from X.400/88 to
X.400/84 when MIME content-types are present in the messages
5.27. RFC1496: MIME content typeがメッセージに存在しているときX.400/88からX.400/84までメッセージを格下げするための規則
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 12] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[12ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.28. RFC 1502: X.400 Use of Extended Character Sets
5.28. RFC1502: 拡張文字集合のX.400使用
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.29. RFC 1572: Telnet Environment Option
5.29. RFC1572: telnet環境オプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.30. RFC 1648: Postmaster Convention for X.400 Operations
5.30. RFC1648: X.400操作のための郵便局長コンベンション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.31. RFC 1738: Uniform Resource Locators
5.31. RFC1738: Uniform Resource Locator
Section 3.1. (Common Internet Scheme Syntax) states:
セクション3.1。 (一般的なインターネット体系構文) 州:
"host
The fully qualified domain name of a network host, or its IP
address as a set of four decimal digit groups separated by ".".
Fully qualified domain names take the form as described in
Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [4]: a
sequence of domain labels separated by ".", each domain label
starting and ending with an alphanumerical character and
possibly also containing "-" characters. The rightmost domain
label will never start with a digit, though, which
syntactically distinguishes all domain names from the IP
addresses."
「「ネットワークホストの完全修飾ドメイン名、またはグループが分離した1セットの4 10進数字としてのそのIPアドレスをホスティングしてください」。」 完全修飾ドメイン名はRFC1034[13]のセクション3.5とRFC1123[4]のセクション2.1で説明されるように形を取ります: 「ラベルが分離したドメインの系列」、」、英数字のキャラクタとまた、ことによると「-」キャラクタを含む各ドメインラベル始めと結末。 「もっとも、一番右のドメインラベルはケタから決して始まらないでしょう(IPアドレスとすべてのドメイン名をシンタクス上区別します)。」
Clearly, this is only valid when using IPv4 addresses. Later in Section 5. (BNF for specific URL schemes), there is the following text:
IPv4アドレスを使用するときだけ、明確に、これは有効です。 セクション5で、より遅く。 (特定のURL体系のためのBNF), 以下のテキストがあります:
"; URL schemeparts for ip based protocols:
"; ipのためのURL schemepartsはプロトコルを基礎づけました:
ip-schemepart = "//" login [ "/" urlpath ]
「ip-schemepartは」 //と等しい」というログイン[「/」urlpath]
login = [ user [ ":" password ] "@" ] hostport
hostport = host [ ":" port ]
host = hostname | hostnumber"
ログイン=[ユーザ[「:」 パスワード]"@"]hostport hostportはホスト[「:」 ポート]ホスト=ホスト名と等しいです。| "hostnumber"
Again, this also has implications in terms of IP-version neutrality.
また、一方、これには、IP-バージョン中立に関して意味があります。
5.32. RFC 1740: MIME Encapsulation of Macintosh Files -
MacMIME
5.32. RFC1740: マッキントッシュファイルのMIMEカプセル化--MacMIME
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 13] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[13ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.33. RFC 1767: MIME Encapsulation of EDI Objects
5.33. RFC1767: EDIオブジェクトのMIMEカプセル化
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.34. RFC 1808: Relative Uniform Resource Locators
5.34. RFC1808: 相対的なUniform Resource Locator
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.35. RFC 1835: Architecture of the WHOIS++ service
5.35. RFC1835: WHOIS++サービスのアーキテクチャ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.36. RFC 1913: Architecture of the WHOIS++ Index Service
5.36. RFC1913: WHOIS++インデックスサービスのアーキテクチャ
Section 6.5. (Query referral) makes the following statement:
セクション6.5。 (質問紹介) 以下の声明を出します:
"When referrals are included in the body of a response to a query,
each referral is listed in a separate SERVER-TO-ASK block as shown
below.
「紹介が質問への応答のボディーに含まれているとき、各紹介は別々のSERVER-TO-ASKブロックに以下に示すように記載されます。」
# SERVER-TO-ASK
Version-number: // version number of index software, used to insure
// compatibility
Body-of-Query: // the original query goes here
Server-Handle: // WHOIS++ handle of the referred server
Host-Name: // DNS name or IP address of the referred server
Port-Number: // Port number to which to connect, if different from the
// WHOIS++ port number"
# 尋ねるサーババージョン番号: 質問の//互換性Bodyを保障するのに使用されるインデックスソフトウェアの//バージョン番号: オリジナルが質問する//は以下をServer扱いにここに行きます。 参照されたサーバHost-名の//WHOIS++ハンドル: 参照されたサーバPort-番号の//DNS名かIPアドレス: 「//WHOIS++ポートナンバーと異なるなら、//は接続する数を移植します」
The syntax used does not present specific IPv4 dependencies, but implementations should be modified to check, in incoming packets, which IP version was used by the original request, so they can determine whether or not to return an IPv6 address.
使用される構文が特定のIPv4の依存を提示しませんが、実装が入って来るパケットでどのIPバージョンがオリジナルの要求で使用されたかをチェックするように変更されるべきであるので、それらは、IPv6アドレスを返すかどうか決定できます。
5.37. RFC 1914: How to Interact with a Whois++ Mesh
5.37. RFC1914: Whois++メッシュと対話する方法
Section 4 (Caching) states the following:
セクション4(キャッシュします)は以下を述べます:
"A client can cache all information it gets from a server for some
time. For example records, IP-addresses of Whois++ servers, the
Directory of Services server etc.
「クライアントはそれがしばらくサーバから得るすべての情報をキャッシュできます。」 例えば、+ + サーバ、ServicesのWhoisディレクトリのIP-アドレスサーバ記録など
A client can itself choose for how long it should cache the
information.
クライアント缶自体はそれがどれくらい長い間情報をキャッシュするべきであるかに選ばれます。
The IP-address of the Directory of Services server might not
change for a day or two, and neither might any other information."
「ServicesサーバのディレクトリのIP-アドレスは1日か2日間、変化しないかもしれません、そして、いかなる他の情報もそうしないかもしれません。」
Sofia & Nesser II Informational [Page 14] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[14ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
Also, subsection 4.1. (Caching a Whois++ servers hostname) contains:
小区分4.1も。 (Whois++サーバホスト名をキャッシュします) 含んでいます:
"An example of cached information that might change is the cached
hostname, IP-address and portnumber which a client gets back in a
servers-to-ask response. That information is cached in the server
since the last poll, which might occurred several weeks ago.
Therefore, when such a connection fails, the client should fall
back to use the serverhandle instead, which means that it contacts
the Directory of Services server and queries for a server with
that serverhandle. By doing this, the client should always get
the last known hostname.
「変化するかもしれないキャッシュされた情報に関する例は、キャッシュされたホスト名と、IP-アドレスとクライアントが尋ねるサーバ応答で取り戻すportnumberです。」 最後の投票以来情報がサーバでキャッシュされるのは数週間前に起こりました。(投票はそうするかもしれません)。 したがって、そのような接続が失敗すると、クライアントは、代わりにserverhandleを使用するために後ろへ下がるべきです。(serverhandleはそのserverhandleでサーバのためのServicesサーバと質問のディレクトリに連絡することを意味します)。 そうすれば、クライアントはいつも最後に知られているホスト名を得るべきです。
An algorithm for this might be:
これのためのアルゴリズムは以下の通りです。
response := servers-to-ask response from server A
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
connect to Directory of Services server
query for host with serverhandle response.serverhandle
response := response from Directory of Services server
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
exit with error message
}
}
Query this new server"
「接続やり損ないがエラーメッセージと共に出るなら接続やり損ないがホストのためのサーバIP-アドレス:=がDNSで接続するのがresponse.hostnameのためのip-アドレスがわかるServicesのディレクトリからポートresponse.portnumberのip-アドレスまでのserverhandle response.serverhandle応答:=応答によるServicesサーバ質問のディレクトリに接続するなら、A IP-アドレス:=が、ポートresponse.portnumberでipに扱うために中のresponse.hostnameのためのipアドレスのDNSが接続するのがわかるサーバからの応答:=尋ねるサーバ応答はこの新しいサーバについて質問します」
The paragraph does not contain IPv4 specific syntax. Hence, IPv6 compliance will be implementation dependent.
パラグラフはIPv4の特定の構文を含んでいません。 したがって、IPv6コンプライアンスは実装に依存するようになるでしょう。
5.38. RFC 1985: SMTP Service Extension for Remote Message
Queue Starting
5.38. RFC1985: リモートメッセージキュー始めのためのSMTPサービス拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.39. RFC 2017: Definition of the URL MIME External-Body
Access-Type
5.39. RFC2017: URL MIME外部のボディーアクセス型の定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.40. RFC 2034: SMTP Service Extension for Returning Enhanced
Error Codes
5.40. RFC2034: 戻るためのSMTPサービス拡張子はエラーコードを高めました。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 15] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[15ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.41. RFC 2056: Uniform Resource Locators for Z39.50
5.41. RFC2056: Z39.50のためのUniform Resource Locator
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.42. RFC 2077: The Model Primary Content Type for
Multipurpose Internet Mail Extensions
5.42. RFC2077: マルチパーパスインターネットメールエクステンションのためのモデルのプライマリcontent type
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.43. RFC 2079: Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers (URIs)
5.43. RFC2079: X.500属性タイプとUniform Resource Identifierを保持するオブジェクトのクラスの定義(URI)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.44. RFC 2086: IMAP4 ACL extension
5.44. RFC2086: IMAP4 ACL拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.45. RFC 2087: IMAP4 QUOTA extension
5.45. RFC2087: IMAP4 QUOTA拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.46. RFC 2088: IMAP4 non-synchronizing literals
5.46. RFC2088: IMAP4非連動リテラル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.47. RFC 2122: VEMMI URL Specification
5.47. RFC2122: VEMMI URL仕様
Section 3 (Description of the VEMMI scheme) states:
セクション3(VEMMI体系の記述)州:
"The VEMMI URL scheme is used to designate multimedia interactive
services conforming to the VEMMI standard (ITU/T T.107 and ETS 300
709).
「VEMMI URL体系はVEMMI規格(ITU/T T.107とETS300 709)に従う双方向サービスにマルチメディアを指定するのに使用されます。」
A VEMMI URL takes the form:
vemmi://<host>:<port>/<vemmiservice>;
<attribute>=<value>
VEMMI URLは形を取ります: vemmi://<ホスト>: <ポート>/<vemmiservice>。 <属性>は<値の>と等しいです。
as specified in Section 3.1. of RFC 1738. If :<port> is omitted,
the port defaults to 575 (client software may choose to ignore the
optional port number in order to increase security). The
<vemmiservice> part is optional and may be omitted."
RFC1738のセクション3.1で指定されるように。 : <ポート>が省略されるなら、ポートは575をデフォルトとします(クライアントソフトウェアは、セキュリティを増強するために任意のポートナンバーを無視するのを選ぶかもしれません)。 「<vemmiservice>部分は、任意であり、省略されるかもしれません。」
IPv4 dependencies may relate to the possibility of the <host> portion containing an IPv4 address, as defined in RFC 1738 (see section 5.31. above). Once the problem is solved in the context of RFC 1738, this issue will be automatically solved.
IPv4の依存はIPv4アドレスを含む<ホスト>部分の可能性に関連するかもしれません、RFC1738で定義されるように(セクション5.31が上であることを見てください)。 問題がRFC1738の文脈でいったん解決されていると、この問題は自動的に解決されるでしょう。
Sofia & Nesser II Informational [Page 16] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[16ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.48. RFC 2141: URN Syntax
5.48. RFC2141: つぼの構文
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.49. RFC 2142: Mailbox Names for Common Services, Roles and
Functions
5.49. RFC2142: 共益サービス、役割、および機能のためのメールボックス名
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.50. RFC 2156: MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/MIME
5.50. RFC2156: ミキサー(パントマイムインターネットX.400はリレーを機能アップしました): X.400とRFC822/MIMEの間のマッピング
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.51. RFC 2157: Mapping between X.400 and RFC-822/MIME
Message Bodies
5.51. RFC2157: X.400とRFC-822/MIMEメッセージの間でボディーを写像します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.52. RFC 2158: X.400 Image Body Parts
5.52. RFC2158: X.400イメージボディ・パーツ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.53. RFC 2159: A MIME Body Part for FAX
5.53. RFC2159: ファックスのためのMIME身体の部分
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.54. RFC 2160: Carrying PostScript in X.400 and MIME
5.54. RFC2160: X.400とMIMEにおけるポストスクリプトを運びます。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.55. RFC 2163: Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping
5.55. RFC2163: ミキサーConformantグローバルアドレスマッピングを分配するのにインターネットDNSを使用します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.56. RFC 2164: Use of an X.500/LDAP directory to support
MIXER address mapping
5.56. RFC2164: MIXERがアドレス・マッピングであるとサポートするX.500/LDAPディレクトリの使用
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.57. RFC 2165: Service Location Protocol
5.57. RFC2165: サービス位置のプロトコル
Section 7. (Service Type Request Message Format) and Section 9. (Service Registration Message Format) have an 80-bit field from addr-spec (see below) which cannot support IPv6 addresses. Also, Section 20.1. (Previous Responders' Address Specification) states:
セクション7。 (サービスタイプ要求メッセージ形式) そして、セクション9。 (サービス登録メッセージ・フォーマット) IPv6にアドレスをサポートできないaddr-仕様(以下を見る)からの80ビットの分野を持ってください。 セクション20.1も。 (前の応答者のアドレス指定) 州:
Sofia & Nesser II Informational [Page 17] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[17ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
"The previous responders' Address Specification is specified as
「前の応答者のAddress Specificationとして、指定されます」
<Previous Responders' Address Specification> ::=
<addr-spec> |
<addr-spec>, <Previous Responders' Address Specification>
<前の応答者のアドレス指定>:、:= <addr-仕様>。| <addr-仕様>、<前の応答者のアドレス指定>。
i.e., a list separated by commas with no intervening white space.
The Address Specification is the address of the Directory Agent or
Service Agent which supplied the previous response. The format
for Address Specifications in Service Location is defined in
section 20.4. The comma delimiter is required between each
<addr-spec>. The use of dotted decimal IP address notation should
only be used in environments which have no Domain Name Service."
すなわち、リストは介入している余白のないコンマで分離しました。 Address Specificationは前の応答を供給したディレクトリエージェントかServiceエージェントのアドレスです。 Service LocationのAddress Specificationsのための書式はセクション20.4で定義されます。 コンマデリミタがそれぞれの<addr-仕様>の間で必要です。 「ドット付き10進法IPアドレス記法の使用はDomain Name Serviceを全く持っていない環境で使用されるだけであるべきです。」
Later, in Section 20.4. (Address Specification in Service Location) there is also the following reference to addr-spec:
セクション20.4により遅れています。 (アドレス指定の使用中の位置) また、addr-仕様の以下の参照があります:
"The address specification used in Service Location is:
「Service Locationで使用されるアドレス指定は以下の通りです」
<addr-spec> ::= [<user>:<password>@]<host>[:<port>]
<addr-仕様>:、:= [<ユーザ>: <パスワード>@]<ホスト>。[: <ポート>]
<host> ::= Fully qualified domain name |
dotted decimal IP address notation
<ホスト>:、:= 完全修飾ドメイン名| ドット付き10進法IPアドレス記法
When no Domain Name Server is available, SAs and DAs must use
dotted decimal conventions for IP addresses. Otherwise, it is
preferable to use a fully qualified domain name wherever possible
as renumbering of host addresses will make IP addresses invalid
over time."
どんなDomain Name Serverも利用可能でないときに、SAsとDAsはIPアドレスにドット付き10進法コンベンションを使用しなければなりません。 「さもなければ、IPアドレスが時間がたつにつれてホスト・アドレスの番号を付け替えることで無効になるので、どこでも、可能であるところで完全修飾ドメイン名を使用するのは望ましいです。」
The whole Section 21. (Protocol Requirements) defines the requirements for each of the elements of this protocol. Several IPv4 statements are made, but the syntax used is sufficiently neutral to apply to the use of IPv6.
全体のセクション21。 (プロトコル要件) それぞれのこのプロトコルの原理のための要件を定義します。 いくつかのIPv4声明が出されますが、使用される構文はIPv6の使用に適用できるくらい中立です。
Section 22. (Configurable Parameters and Default Values) states:
セクション22。 (構成可能なパラメタとデフォルト値) 州:
"There are several configuration parameters for Service Location.
Default values are chosen to allow protocol operation without the
need for selection of these configuration parameters, but other
values may be selected by the site administrator. The
configurable parameters will allow an implementation of Service
Location to be more useful in a variety of scenarios.
「Service Locationのためのいくつかの設定パラメータがあります。」 デフォルト値はこれらの選択の必要性なしで設定パラメータにもかかわらず、他でプロトコル操作を許すために選ばれて、値がサイトの管理者によって選択されるかもしれないということです。 構成可能なパラメタは、さまざまなシナリオでは、Service Locationの実装が、より役に立つのを許容するでしょう。
Sofia & Nesser II Informational [Page 18] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[18ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
Multicast vs. Broadcast
All Service Location entities must use multicast by default.
The ability to use broadcast messages must be configurable
for UAs and SAs. Broadcast messages are to be used in
environments where not all Service Location entities have
hardware or software which supports multicast.
マルチキャスト対Broadcast All Service Location実体はデフォルトでマルチキャストを使用しなければなりません。 UAsとSAsに、同報メッセージを使用する能力は構成可能であるに違いありません。 同報メッセージはすべてのService Location実体がマルチキャストをサポートするハードウェアかソフトウェアを持っているというわけではない環境で使用されることです。
Multicast Radius
Multicast requests should be sent to all subnets in a site.
The default multicast radius for a site is 32. This value
must be configurable. The value for the site's multicast
TTL may be obtained from DHCP using an option which is
currently unassigned."
マルチキャストRadius Multicast要求をサイトのすべてのサブネットに送るべきです。 サイトへのデフォルトマルチキャスト半径は32です。 この値は構成可能であるに違いありません。 「DHCPから現在割り当てられないオプションを使用することでサイトのマルチキャストTTLのための値を得るかもしれません。」
Once again, nothing here precludes IPv6, Section 23.
もう一度、ここの何もIPv6、セクション23を排除しません。
(Non-configurable Parameters) states:
(非構成可能なParameters)は以下を述べます。
"IP Port number for unicast requests to Directory Agents:
「ユニキャストのIP Port番号はディレクトリエージェントに以下を要求します」
UDP and TCP Port Number: 427
UDPとTCPは数を移植します: 427
Multicast Addresses
マルチキャストアドレス
Service Location General Multicast Address: 224.0.1.22
Directory Agent Discovery Multicast Address: 224.0.1.35
位置の一般マルチキャストアドレスを修理してください: 224.0.1.22 ディレクトリエージェント発見マルチキャストアドレス: 224.0.1.35
A range of 1024 contiguous multicast addresses for use as Service
Specific Discovery Multicast Addresses will be assigned by IANA."
「Service SpecificディスカバリーMulticast Addressesとしての使用のための1024の隣接のマルチキャストアドレスの範囲はIANAによって割り当てられるでしょう。」
Clearly, the statements above require specifications related to the use of IPv6 multicast addresses with equivalent functionality.
明確に、上の声明は同等な機能性でIPv6マルチキャストアドレスの使用に関連する仕様を必要とします。
5.58. RFC 2177: IMAP4 IDLE command
5.58. RFC2177: IMAP4 IDLEコマンド
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.59. RFC 2183: Communicating Presentation Information in
Internet Messages: The Content-Disposition Header Field
5.59. RFC2183: インターネットメッセージのプレゼンテーション情報を伝えます: 満足している気質ヘッダーフィールド
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.60. RFC 2192: IMAP URL Scheme
5.60. RFC2192: IMAP URL体系
The specification has IPv4 dependencies, as RFC 1738, which is integral to the document, is not IPv6 aware.
IPv6は仕様にはRFC1738としてIPv4の依存があるのを意識していませんか?(RFCはドキュメントに不可欠です)。
Sofia & Nesser II Informational [Page 19] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[19ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.61. RFC 2193: IMAP4 Mailbox Referrals
5.61. RFC2193: IMAP4メールボックス紹介
Section 6. (Formal Syntax) presents the following statement:
セクション6。 (正式な構文) プレゼント、以下の声明:
"referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"; See
[RFC-1738] for <url> definition"
「紹介_応答_コードは「[「「紹介」1*(スペース<url>)」]」と等しいです」。 「<url>定義に関して[RFC-1738]を見てください」
The above presents dependencies on RFC 1738 URL definitions, which have already been mentioned in this document, section 5.31.
上記はRFCにおける依存に1738のURL定義を提示します。(このドキュメント、セクション5.31で定義は既に言及されました)。
5.62. RFC 2218: A Common Schema for the Internet White Pages
Service
5.62. RFC2218: インターネットホワイトページサービスのための一般的な図式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.63. RFC 2221: IMAP4 Login Referrals
5.63. RFC2221: IMAP4ログイン紹介
Section 4.1. (LOGIN and AUTHENTICATE Referrals) provides the following example:
セクション4.1。 (ログインして、紹介を認証します) 以下の例を提供します:
"Example: C: A001 LOGIN MIKE PASSWORD
S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified
user is invalid on this server. Try SERVER2."
「例:」 C: A001ログインマイクパスワードS: A001 NO[REFERRAL IMAP: //MIKE@SERVER2/ ]の指定されたユーザはこのサーバで無効です。「SERVER2を試みてください。」
Even though the syntax "user@SERVER2" is presented often, there are no specifications related to the format of "SERVER2". Hence, it is up to individual implementations to determine acceptable values for the hostname. This may or not include explicit IPv6 addresses.
構文" user@SERVER2 "はしばしば提示されますが、"SERVER2""の形式に関連する仕様が全くありません。 したがって、ホスト名のために許容値を決定するのは個々の実装まで達しています。 これはそうするかもしれません。または、明白なIPv6が扱うインクルードでない。
5.64. RFC 2227: Simple Hit-Metering and Usage-Limiting for
HTTP
5.64. RFC2227: HTTPのための簡単なヒット計量と用法制限
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.65. RFC 2231: MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations
5.65. RFC2231: パラメタ値とコード化されたWord拡大をまねてください: 文字コード、言語、および続刊
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.66. RFC 2234: Augmented BNF for Syntax Specifications: ABNF
5.66. RFC2234: 構文仕様のための増大しているBNF: ABNF
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.67. RFC 2244: Application Configuration Access Protocol
5.67. RFC2244: アプリケーション構成アクセス・プロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 20] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[20ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.68. RFC 2247: Using Domains in LDAP/X.500 Distinguished
Names
5.68. RFC2247: LDAP/X.500分類名にドメインを使用します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.69. RFC 2251: Lightweight Directory Access Protocol (v3)
5.69. RFC2251: ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.70. RFC 2252: Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions
5.70. RFC2252: ライトウェイト・ディレクトリ・アクセス・プロトコル(v3): 属性構文定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.71. RFC 2253: Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names
5.71. RFC2253: ライトウェイト・ディレクトリ・アクセス・プロトコル(v3): 分類名のUTF-8ストリング表現
Section 7.1. (Disclosure) states:
セクション7.1。 (公開) 州:
"Distinguished Names typically consist of descriptive information
about the entries they name, which can be people, organizations,
devices or other real-world objects. This frequently includes
some of the following kinds of information:
「顕著なNamesは彼らが命名する人々、組織、デバイスまたは他の本当の世界オブジェクトであるかもしれないエントリーの描写的である情報から通常成ります。」 これは頻繁に情報の以下の数種類を含んでいます:
- the common name of the object (i.e., a person's full name)
- an email or TCP/IP address
- its physical location (country, locality, city, street address)
- organizational attributes (such as department name or
affiliation)"
- 「オブジェクト(すなわち、人のフルネーム)の一般名--メールかTCP/IPが組織的な属性(部の名か提携などの)を扱います(物理的な位置(国、場所、都市、住所))」
This section requires the caveat "Without putting any limitations on the version of the IP address.", to avoid ambiguity in terms of IP version.
このセクションが「IPアドレスのバージョンにどんな制限も置くこと」なしで警告を必要とする、IPバージョンに関してあいまいさを避けるために。
5.72. RFC 2254: The String Representation of LDAP Search Filters
5.72. RFC2254: LDAP検索フィルタのストリング表現
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.73. RFC 2255: The LDAP URL Format
5.73. RFC2255: LDAP URL形式
The specification has IPv4 dependencies, as RFC 1738, which is integral to the document, is not IPv6 aware.
IPv6は仕様にはRFC1738としてIPv4の依存があるのを意識していませんか?(RFCはドキュメントに不可欠です)。
5.74. RFC 2256: A Summary of the X.500(96) User Schema for use
with LDAPv3
5.74. RFC2256: LDAPv3との使用のためのX.500(96)ユーザSchemaのSummary
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 21] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[21ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.75. RFC 2293: Representing Tables and Subtrees in the X.500
Directory
5.75. RFC2293: X.500ディレクトリにおけるテーブルと下位木を表します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.76. RFC 2294: Representing the O/R Address hierarchy in the
X.500 Directory Information Tree
5.76. RFC2294: X.500ディレクトリ情報TreeのO/R Address階層構造を表します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.77. RFC 2298: An Extensible Message Format for Message
Disposition Notifications
5.77. RFC2298: メッセージ気質通知のための広げることができるメッセージ・フォーマット
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.78. RFC 2301: File Format for Internet Fax
5.78. RFC2301: インターネットファックスのためのファイル形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.79. RFC 2305: A Simple Mode of Facsimile Using Internet Mail
5.79. RFC2305: インターネットメールを使用するファクシミリの簡単なモード
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.80. RFC 2334: Server Cache Synchronization Protocol
5.80. RFC2334: サーバキャッシュ同期プロトコル
Appendix B, part 2.0.1 (Mandatory Common Part) states:
付録B、第2部.0.1(義務的なCommon Part)の州:
"Cache Key
This is a database lookup key that uniquely identifies a piece
of data which the originator of a CSA Record wishes to
synchronize with its peers for a given "Protocol ID/Server
Group ID" pair. This key will generally be a small opaque byte
string which SCSP will associate with a given piece of data in
a cache. Thus, for example, an originator might assign a
particular 4 byte string to the binding of an IP address with
that of an ATM address. Generally speaking, the originating
server of a CSA record is responsible for generating a Cache
Key for every element of data that the given server originates
and which the server wishes to synchronize with its peers in
the SG."
「キャッシュKey Thisは与えられた「プロトコルID/サーバグループID」組のために、唯一、CSA Recordの創始者が同輩と同期させたがっている1つのデータを特定するデータベースルックアップキーです。」 一般に、このキーはバイトSCSPがキャッシュにおける、与えられた片のデータに関連づける小さい不透明なストリングになるでしょう。 このようにして、例えば、創始者はATMアドレスのものがあるIPアドレスの製本に4バイトの特定のストリングを割り当てるかもしれません。 「概して、CSA記録の起因するサーバはサーバが与えられたサーバが溯源して、同輩と同期させたがっているデータのあらゆる要素のためにSGでCache Keyを生成するのに原因となります。」
The statement above is simply meant as an example. Hence, any IPv4 possible dependency of this protocol is an implementation issue.
上の声明は例として単に意味されます。 したがって、このプロトコルのどんなIPv4の可能な依存も導入問題です。
5.81. RFC 2342: IMAP4 Namespace
5.81. RFC2342: IMAP4名前空間
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 22] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[22ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.82. RFC 2359: IMAP4 UIDPLUS extension
5.82. RFC2359: IMAP4 UIDPLUS拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.83. RFC 2368: The mailto URL scheme
5.83. RFC2368: mailto URL体系
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.84. RFC 2369: The Use of URLs as Meta-Syntax for Core Mail
List Commands and their Transport through Message Header Fields
5.84. RFC2369: CoreメールList CommandsとMessage Headerフィールズを通した彼らのTransportのためのMeta-構文としてのURLのUse
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.85. RFC 2371: Transaction Internet Protocol Version 3.0
5.85. RFC2371: トランザクションインターネットプロトコルバージョン3.0
In section 7. (TIP Transaction Manager Identification and Connection Establishment):
セクション7で。 (チップトランザクションマネージャ識別とコネクション確立):
"The <hostport> component comprises:
「<hostport>の部品は以下を包括します」
<host>[:<port>]
<ホスト>。[: <ポート>]
where <host> is either a <dns name> or an <ip address>; and <port>
is a decimal number specifying the port at which the transaction
manager (or proxy) is listening for requests to establish TIP
connections. If the port number is omitted, the standard TIP port
number (3372) is used.
<ホスト>が<dns名前>か<ipのどちらかであるところでは、>を扱ってください。 そして、<ポート>はトランザクションマネージャ(または、プロキシ)がTIP接続を確立するという要求の聞こうとしているポートを指定する10進数です。 ポートナンバーが省略されるなら、標準のTIPポートナンバー(3372)は使用されています。
A <dns name> is a standard name, acceptable to the domain name
service. It must be sufficiently qualified to be useful to the
receiver of the command.
<dns名前>はドメイン名サービスに許容できる標準の名前です。 コマンドの受信機の役に立つのは十分適切でなければなりません。
An <ip address> is an IP address, in the usual form: four decimal
numbers separated by period characters."
<ipアドレス>は普通のフォームでのIPアドレスです: 「期間のキャラクタによって切り離された4つの10進数。」
This section has to be re-written to become IP-version neutral. Besides adding a reference to the use of IPv6 addresses, the "host" field should only be defined as a "dns name". However, if the use of literal IP addresses is to be included, the format specified in RFC 2372 has to be followed.
このセクションは、IP-バージョン中立になるように書き直されなければなりません。 参照がさらにIPv6アドレスの使用の一助となる場合、「ホスト」分野は「dns名」と定義されるだけであるべきです。 しかしながら、文字通りのIPアドレスの使用が含まれることであるなら、RFC2372で指定された形式は続かれなければなりません。
Later in section 8. (TIP Uniform Resource Locators):
セクション8で、より遅く。 (チップUniform Resource Locator):
"A TIP URL takes the form:
「TIP URLは形を取ります」
tip://<transaction manager address>?<transaction string>
チップ://<トランザクションマネージャアドレス>?<トランザクションストリング>。
Sofia & Nesser II Informational [Page 23] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[23ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
where <transaction manager address> identifies the TIP transaction
manager (as defined in Section 7 above); and <transaction string>
specifies a transaction identifier, which may take one of two
forms (standard or non-standard):
<トランザクションマネージャアドレス>がTIPトランザクションマネージャを特定する(上のセクション7で定義されるように)ところ。 そして、<トランザクションストリング>はトランザクション識別子を指定します:(識別子は2つのフォーム(標準の、または、標準的でない)の1つを取るかもしれません)。
i. "urn:" <NID> ":" <NSS>
i。 「つぼ:」 「<NID>」:、」 <NSS>。
A standard transaction identifier, conforming to the proposed
Internet Standard for Uniform Resource Names (URNs), as
specified by RFC2141; where <NID> is the Namespace Identifier,
and <NSS> is the Namespace Specific String. The Namespace ID
determines the syntactic interpretation of the Namespace
Specific String. The Namespace Specific String is a sequence
of characters representing a transaction identifier (as defined
by <NID>). The rules for the contents of these fields are
specified by [6] (valid characters, encoding, etc.).
RFC2141によって指定されるようにUniform Resource Names(URNs)のための提案されたインターネットStandardに従う標準のトランザクション識別子。 <NID>がNamespace Identifierであり、<NSS>がNamespace Specific Stringであるところ。 Namespace IDはNamespace Specific Stringの統語的解釈を決定します。 Namespace Specific Stringはトランザクション識別子を表すキャラクタの系列(<NID>によって定義されるように)です。 [6](有効なキャラクタ、コード化など)によってこれらの分野のコンテンツのための規則は指定されます。
This format of <transaction string> may be used to express
global transaction identifiers in terms of standard
representations. Examples for <NID> might be <iso> or <xopen>.
e.g.,
<トランザクションストリング>のこの形式は、標準の表現でグローバルなトランザクション識別子を言い表すのに使用されるかもしれません。 <NID>のための例が<iso>か<xopen>であるかもしれない、例えば。
tip://123.123.123.123/?urn:xopen:xid
チップ://123.123.123.123/?つぼ:xopen:xid
Note that Namespace Ids require registration. See [7] for
details on how to do this."
Namespace Idsが登録を必要とすることに注意してください。 「どうこれをするかに関する詳細のための[7]を見てください。」
There are other references in section 8, regarding the use of literal IP addresses. Therefore, this section also needs to be re-written, and special care should be taken to avoid the use of IP (either IPv4 or IPv6) literal addresses. However, if such use is exemplified, the format specified in RFC 2732 has to be respected.
他の参照が文字通りのIPアドレスの使用に関するセクション8にあります。 したがって、また、このセクションは、書き直される必要があります、そして、特別な注意は、IP(IPv4かIPv6のどちらか)の文字通りのアドレスの使用を避けるために払われるべきです。 しかしながら、そのような使用が例示されるなら、RFC2732で指定された形式は尊敬されなければなりません。
5.86. RFC 2384: POP URL Scheme
5.86. RFC2384: 大衆的なURL体系
Section 3. (POP Scheme) states:
セクション3。 (大衆的な体系) 州:
"A POP URL is of the general form:
「POP URLは一般的なフォームのものです」
pop://<user>;auth=<auth>@<host>:<port>
://<ユーザ>を飛び出させてください; authは<auth>@<ホスト>: <ポート>と等しいです。
Where <user>, <host>, and <port> are as defined in RFC 1738, and
some or all of the elements, except "pop://" and <host>, may be
omitted."
「<ユーザ>、<ホスト>、および<ポート>がRFC1738で定義されるようにあって、要素のいくつかか「ポップス://」と<ホスト>以外のすべてが省略されるかもしれないところ。」
RFC 1738 (please refer to section 5.31) has a potential IPv4 limitation. Hence, RFC 2384 will only be IPv6 compliant when RFC 1738 becomes properly updated.
RFC1738(セクション5.31を示してください)には、潜在的IPv4制限があります。 RFC1738が適切にアップデートするようになるときだけ、したがって、RFC2384はIPv6対応するのになるでしょう。
Sofia & Nesser II Informational [Page 24] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[24ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.87. RFC 2387: The MIME Multipart/Related Content-type
5.87. RFC2387: MIMEの複合の、または、関連の文書内容
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.88. RFC 2388: Returning Values from Forms: multipart/form-data
5.88. RFC2388: フォームからの戻っている値: 複合かデータを形成します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.89. RFC 2389: Feature negotiation mechanism for the File
Transfer Protocol
5.89. RFC2389: File Transferプロトコルのための特徴交渉メカニズム
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.90. RFC 2392: Content-ID and Message-ID Uniform Resource
Locators (CIDMID-URL)
5.90. RFC2392: コンテントIDとMessage ID Uniform Resource Locator(CIDMID-URL)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.91. RFC 2397: The "data" URL scheme
5.91. RFC2397: 「データ」URL体系
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.92. RFC 2421: Voice Profile for Internet Mail - version 2
5.92. RFC2421: インターネットメールのための声のProfile--バージョン2
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.93. RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM MIME
Sub-type Registration
5.93. RFC2422: 料金Quality Voice--32kbit/s ADPCM MIME Sub-タイプRegistration
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.94. RFC 2423: VPIM Voice Message MIME Sub-type Registration
5.94. RFC2423: VPIM音声メールMIMEサブタイプ登録
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.95. RFC 2424: Content Duration MIME Header Definition
5.95. RFC2424: 満足している持続時間MIMEヘッダー定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.96. RFC 2425: A MIME Content-Type for Directory Information
5.96. RFC2425: ディレクトリ情報のためのMIMEコンテントタイプ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.97. RFC 2426: vCard MIME Directory Profile
5.97. RFC2426: vCard MIMEディレクトリプロフィール
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 25] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[25ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.98. RFC 2428: FTP Extensions for IPv6 and NATs
5.98. RFC2428: IPv6とNATsのためのFTP拡大
This RFC documents an IPv6 extension and hence, it is not considered in the context of the current discussion.
このRFCはIPv6拡張子を記録します、そして、したがって、それは現在の議論の文脈で考えられません。
5.99. RFC 2445: Internet Calendaring and Scheduling Core Object
Specification (iCalendar)
5.99. RFC2445: インターネットCalendaringとスケジューリングコアオブジェクト仕様(iCalendar)
Section 4.8.4.7 (Unique Identifier) states:
セクション4.8 .4 .7 (ユニークなIdentifier)は以下を述べます。
"Property Name: UID
「特性の名:」 UID
Purpose: This property defines the persistent, globally unique
identifier for the calendar component.
目的: この特性はカレンダーコンポーネントのための永続的で、グローバルにユニークな識別子を定義します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: The property MUST be specified in the "VEVENT",
"VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.
順応: "VEVENT"、"VTODO"、"VJOURNAL"または"VFREEBUSY"カレンダーコンポーネントで特性を指定しなければなりません。
Description: The UID itself MUST be a globally unique identifier.
The generator of the identifier MUST guarantee that the identifier
is unique. There are several algorithms that can be used to
accomplish this. The identifier is RECOMMENDED to be the
identical syntax to the [RFC 822] addr-spec. A good method to
assure uniqueness is to put the domain name or a domain literal IP
address of the host on which the identifier was created on the
right hand side of the "@", and on the left hand side, put a
combination of the current calendar date and time of day (i.e.,
formatted in as a DATE-TIME value) along with some other currently
unique (perhaps sequential) identifier available on the system
(for example, a process id number). Using a date/time value on
the left hand side and a domain name or domain literal on the
right hand side makes it possible to guarantee uniqueness since no
two hosts should be using the same domain name or IP address at
the same time. Though other algorithms will work, it is
RECOMMENDED that the right hand side contain some domain
identifier (either of the host itself or otherwise) such that the
generator of the message identifier can guarantee the uniqueness
of the left hand side within the scope of that domain."
記述: UID自身はグローバルにユニークな識別子であるに違いありません。 識別子のジェネレータは、識別子がユニークであることを保証しなければなりません。 これを達成するのに使用できるいくつかのアルゴリズムがあります。 識別子は[RFC822]addr-仕様への同じ構文であるRECOMMENDEDです。 ユニークさを保証する良いメソッドはドメイン名か識別子が"@"の正しい手の側、および現在のカレンダ日付と時刻の左手の横の、そして、かかっているa組み合わせのときにシステム(例えば、プロセスイド番号)の上で利用可能なある他の現在ユニークな(恐らく連続した)識別子と共に作成された(すなわち、中では、日付時間的価値としてフォーマットされます)ホストのドメインリテラルIPアドレスを置くことです。 右手側で左側とドメイン名かドメインリテラルで日付/時間的価値を使用するのに、ホストが同時に同じドメイン名かIPアドレスを使用するべきであるのを2がないの以来のユニークさに保証するのが可能になります。 「他のアルゴリズムは利くでしょうが、メッセージ識別子のジェネレータがそのドメインの範囲の中で左側のユニークさを保証できるように、右手側が何らかのドメイン識別子(ホスト自身かそうでなのどちらかさ)を含んでいるのは、RECOMMENDEDです。」
Although the above does not explicitly state the use of IPv4 addresses, it addresses the explicit use of RFC 822 (obsoleted by RFC 2822). To become IPv6 compliant it should follow the guidelines for RFC 2822 (see section 5.129).
上記は明らかにIPv4アドレスの使用を述べませんが、それはRFC822(RFC2822によって時代遅れにされます)の明白な使用を扱います。 IPv6対応するのになるように、それはRFC2822のためのガイドラインに従うべきです(セクション5.129を見てください)。
Sofia & Nesser II Informational [Page 26] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[26ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.100. RFC 2446: iCalendar Transport-Independent Interoperability
Protocol (iTIP) Scheduling Events, BusyTime, To-dos and
Journal Entries
5.100. RFC2446: イベント、BusyTime、大騒ぎ、および仕訳記入の計画をするiCalendarの輸送から独立している相互運用性プロトコル(iTIP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.101. RFC 2447: iCalendar Message-Based Interoperability
Protocol (iMIP)
5.101. RFC2447: iCalendarのメッセージベースの相互運用性プロトコル(iMIP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.102. RFC 2449: POP3 Extension Mechanism
5.102. RFC2449: POP3拡張機能
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.103. RFC 2476: Message Submission
5.103. RFC2476: メッセージ提案
This RFC contains several discussions on the usage of IP Address authorization schemes, but it does not limit those addresses to IPv4.
このRFCはIP Address承認体系の用法についてのいくつかの議論を含んでいますが、それはそれらのアドレスをIPv4に制限しません。
5.104. RFC 2480: Gateways and MIME Security Multiparts
5.104. RFC2480: ゲートウェイとMIMEセキュリティMultiparts
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.105. RFC 2518: HTTP Extensions for Distributed Authoring
5.105. RFC2518: 分配されたオーサリングのためのHTTP拡大
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.106. RFC 2530: Indicating Supported Media Features Using
Extensions to DSN and MDN
5.106. RFC2530: 表示は、メディアが特徴であるとDSNとMDNに拡張子を使用することでサポートしました。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.107. RFC 2532: Extended Facsimile Using Internet Mail
5.107. RFC2532: インターネットメールを使用する拡張ファクシミリ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.108. RFC 2533: A Syntax for Describing Media Feature Sets
5.108. RFC2533: メディア機能について説明するための構文はセットします。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.109. RFC 2534: Media Features for Display, Print, and Fax
5.109. RFC2534: ディスプレイ、印刷、およびファックスのためのメディア機能
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.110. RFC 2554: SMTP Service Extension for Authentication
5.110. RFC2554: 認証のためのSMTPサービス拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 27] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[27ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.111. RFC 2557: MIME Encapsulation of Aggregate Documents,
such as HTML
5.111. RFC2557: HTMLなどのAggregate DocumentsのMIME Encapsulation
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.112. RFC 2589: Lightweight Directory Access Protocol (v3):
Extensions for Dynamic Directory Services
5.112. RFC2589: ライトウェイト・ディレクトリ・アクセス・プロトコル(v3): ダイナミックなディレクトリサービスのための拡大
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.113. RFC 2595: Using TLS with IMAP, POP3 and ACAP
5.113. RFC2595: IMAP、POP3、およびACAPとTLSを使用します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.114. RFC 2596: Use of Language Codes in LDAP
5.114. RFC2596: LDAPにおける言語コードの使用
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.115. RFC 2608: Service Location Protocol, Version 2
5.115. RFC2608: サービス位置のプロトコル、バージョン2
Section 8.1. (Service Request) contains the following:
セクション8.1。 (サービスのリクエスト) 以下を含んでいます:
"
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRqst = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <PRList> | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <service-type> | <service-type> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of predicate string | Service Request <predicate> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
" 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスLocationヘッダー(機能=SrvRqst=1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <PRList>の長さ| <PRList>ストリング\+++++++++++++++++++++++++++++++++| <サービスタイプ>の長さ| <サービスタイプ>は\+++++++++++++++++++++++++++++++++を結びます。| <範囲リスト>の長さ| <範囲リスト>は\+++++++++++++++++++++++++++++++++を結びます。| 述部ストリングの長さ| サービスのリクエスト<述部>\+++++++++++++++++++++++++++++++++| <SLP SPI>ストリングの長さ| <SLP SPI>ストリング\+++++++++++++++++++++++++++++++++
...
...
<PRList> is the Previous Responder List. This <string-list>
contains dotted decimal notation IP (v4) addresses, and is
iteratively multicast to obtain all possible results (see Section
6.3). UAs SHOULD implement this discovery algorithm. SAs MUST
use this to discover all available DAs in their scope, if they are
not already configured with DA addresses by some other means."
<PRList>はPrevious Responder Listです。 この<ストリングリスト>はドット付き10進法IP(v4)アドレスを含んでいて、すべての可能な結果を得る繰り返しマルチキャスト(セクション6.3を見る)です。 UAs SHOULDはこの発見アルゴリズムを実装します。 「SAsは彼らの範囲ですべての利用可能なDAsを発見するのにこれを使用しなければなりません、彼らがDAアドレスによってある他の手段で既に構成されないなら。」
Sofia & Nesser II Informational [Page 28] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[28ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
And later:
より遅れています:
"A SA silently drops all requests which include the SA's address
in the <PRList>. An SA which has multiple network interfaces MUST
check if any of the entries in the <PRList> equal any of its
interfaces. An entry in the PRList which does not conform to an
IPv4 dotted decimal address is ignored: The rest of the <PRList>
is processed normally and an error is not returned."
「SAは静かに<PRList>のSAのアドレスを含んでいるすべての要求を下げます。」 複数のネットワーク・インターフェースを持っているSAは、<PRList>のエントリーのどれかがインタフェースのどれかと等しいかどうかチェックしなければなりません。 IPv4ドット付き10進法アドレスに従わないPRListのエントリーは無視されます: 「通常、<PRList>の残りは処理されます、そして、誤りは返されません。」
To become IPv6 compliant, this protocol requires a new version.
IPv6対応するのになるように、このプロトコルは新しいバージョンを必要とします。
5.116. RFC 2609: Service Templates and Service: Schemes
5.116. RFC2609: テンプレートとサービスを調整してください: 体系
Section 2.1. (Service URL Syntax) defines:
セクション2.1。 (サービスURL構文) 定義します:
"The ABNF for a service: URL is:
「サービスのためのABNF:」 URLは以下の通りです。
hostnumber = ipv4-number
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)"
「hostnumber=ipv4-数ipv4-番号は1*3DIGIT3(「.」 1*3DIGIT)と等しいです」
This document presents many other references to hostnumber, which requires an update to support IPv6.
このドキュメントはhostnumberの他の多くの参照を提示します。(hostnumberは、IPv6をサポートするためにアップデートを必要とします)。
5.117. RFC 2640: Internationalization of the File Transfer Protocol
5.117. RFC2640: ファイル転送プロトコルの国際化
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.118. RFC 2645: ON-DEMAND MAIL RELAY (ODMR) SMTP
with Dynamic IP Addresses
5.118. RFC2645: ダイナミックなIPアドレスがある要求次第のメール中継(ODMR)SMTP
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.119. RFC 2646: The Text/Plain Format Parameter
5.119. RFC2646: テキスト/明瞭な形式パラメタ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.120. RFC 2651: The Architecture of the Common Indexing
Protocol (CIP)
5.120. RFC2651: 一般的なインデックスプロトコルのアーキテクチャ(CIP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.121. RFC 2652: MIME Object Definitions for the Common
Indexing Protocol
5.121. RFC2652: 一般的なインデックスのためのMIMEオブジェクト定義は議定書を作ります。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 29] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[29ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.122. RFC 2653: CIP Transport Protocols
5.122. RFC2653: CIPトランスポート・プロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.123. RFC 2732: Format for Literal IPv6 Addresses in URL's
5.123. RFC2732: URLの文字通りのIPv6アドレスのための形式
This document defines an IPv6 specific protocol and hence, it is not discussed in this document.
このドキュメントはIPv6の特定のプロトコルを定義します、そして、したがって、本書ではそれについて議論しません。
5.124. RFC 2738: Corrections to "A Syntax for Describing Media
Feature Sets"
5.124. RFC2738: 「メディア機能について説明するための構文はセットすること」への修正
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.125. RFC 2739: Calendar Attributes for vCard and LDAP
5.125. RFC2739: vCardとLDAPのためのカレンダー属性
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.126. RFC 2806: URLs for Telephone Calls
5.126. RFC2806: 通話のためのURL
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.127. RFC 2821: Simple Mail Transfer Protocol
5.127. RFC2821: シンプルメールトランスファプロトコル
The specification discusses A records at length, and the MX record handling with the different combinations of A and AAAA records and IPv4/IPv6-only nodes might cause several kinds of failure modes.
仕様は十分A記録について議論します、そして、MXはAの異なった組み合わせで取り扱いを記録します、そして、AAAA記録とIPv4/IPv6だけノードは数種類の故障モードを引き起こすかもしれません。
5.128. RFC 2822: Internet Message Format
5.128. RFC2822: インターネットメッセージ・フォーマット
Section 3.4.1 (Addr-spec specification) contains:
セクション3.4 .1 (Addr-仕様仕様) 含んでいます:
"The domain portion identifies the point to which the mail is
delivered. In the dot-atom form, this is interpreted as an
Internet domain name (either a host name or a mail exchanger name)
as described in [STD3, STD13, STD14]. In the domain-literal form,
the domain is interpreted as the literal Internet address of the
particular host. In both cases, how addressing is used and how
messages are transported to a particular host is covered in the
mail transport document [RFC2821]. These mechanisms are outside
of the scope of this document.
「ドメイン部分はメールが提供されるポイントを特定します。」 ドット原子フォームでは、これは[STD3、STD13、STD14]で説明されるようにインターネットドメイン名として解釈されます(ホスト名かメール交換器名のどちらか)。 ドメインリテラルフォームでは、ドメインは特定のホストの文字通りのインターネット・アドレスとして解釈されます。 アドレシングは使用されています、そして、どちらの場合も、メッセージがどう特定のホストに輸送されるかはメール運送書類[RFC2821]でどうカバーされているか。 これらのメカニズムがこのドキュメントの範囲の外にあります。
The local-part portion is a domain dependent string. In
addresses, it is simply interpreted on the particular host as a
name of a particular mailbox."
地方の部分の部分はドメインに依存するストリングです。 「アドレスでは、それが特定のメールボックスの名前として特定のホストの上で単に解釈されます。」
Sofia & Nesser II Informational [Page 30] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[30ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
Literal IP addresses should be avoided. However, in case they are used, there should be a reference to the format described in RFC 2732.
文字通りのIPアドレスは避けられるべきです。 しかしながら、それらが使用されているといけないので、RFC2732で説明された形式の参照があるべきです。
5.129. RFC 2846: GSTN Address Element Extensions in E-mail
Services
5.129. RFC2846: メールサービスにおけるGSTNアドレス要素拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.130. RFC 2849: The LDAP Data Interchange Format (LDIF) -
Technical Specification
5.130. RFC2849: LDAPデータ置き換え形式(LDIF)--技術的な仕様
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.131. RFC 2852: Deliver By SMTP Service Extension
5.131. RFC2852: SMTPサービス拡張子で、配送してください。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.132. RFC 2879: Content Feature Schema for Internet Fax (V2)
5.132. RFC2879: インターネットファックスのための満足している特徴図式(V2)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.133. RFC 2891: LDAP Control Extension for Server Side Sorting
of Search Results
5.133. RFC2891: 検索結果のサーバサイドソーティングのためのLDAPコントロール拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.134. RFC 2910: Internet Printing Protocol/1.1: Encoding and
Transport
5.134. RFC2910: インターネット印刷プロトコル/1.1: コード化と輸送
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.135. RFC 2911: Internet Printing Protocol/1.1: Model and
Semantics
5.135. RFC2911: インターネット印刷プロトコル/1.1: モデルと意味論
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.136. RFC 2912: Indicating Media Features for MIME Content
5.136. RFC2912: MIME内容のためのメディア機能を示します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.137. RFC 2913: MIME Content Types in Media Feature
Expressions
5.137. RFC2913: メディアによるMIME content typeは式を特徴とします。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 31] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[31ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.138. RFC 2919: List-Id: A Structured Field and Namespace for
the Identification of Mailing Lists
5.138. RFC2919: リストイド: メーリングリストの識別のための構造化された分野と名前空間
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.139. RFC 2938: Identifying Composite Media Features
5.139. RFC2938: 合成メディア機能を特定します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.140. RFC 2965: HTTP State Management Mechanism
5.140. RFC2965: HTTP国家管理メカニズム
This document includes several references to host IP addresses, but there is no explicit mention to a particular protocol version. A caveat similar to "Without putting any limitations on the version of the IP address." should be added, so that there will remain no doubts about possible IPv4 dependencies.
このドキュメントはホストIPアドレスにいくつかの指示するものを含んでいますが、特定のプロトコルバージョンへのどんな明白な言及もありません。 A警告同様である、「IPアドレスのバージョンにどんな制限も置く. 」 加えられるべきです、可能なIPv4の依存に関する疑問が全く残らないように。
5.141. RFC 2971: IMAP4 ID extension
5.141. RFC2971: IMAP4 ID拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.142. RFC 2987: Registration of Charset and Languages Media
Features Tags
5.142. RFC2987: Charsetと言語メディアの登録はタグを特集します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.143. RFC 3009: Registration of parityfec MIME types
5.143. RFC3009: parityfec MIMEの種類の登録
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.144. RFC 3017: XML DTD for Roaming Access Phone Book
5.144. RFC3017: ローミングアクセス電話帳のためのXML DTD
Section 6.2.1. (DNS Server Address) states:
セクション6.2.1。 (DNSサーバアドレス) 州:
"The dnsServerAddress element represents the IP address of the
Domain Name Service (DNS) server which should be used when
connected to this POP.
「dnsServerAddress要素はこのPOPに接続されると使用されるべきであるDomain Name Service(DNS)サーバのIPアドレスを表します。」
The address is represented in the form of a string in dotted-
decimal notation (e.g., 192.168.101.1).
アドレスが点を打たされた10進法によるストリングの形に表される、(例えば、192.168 .101 .1)。
Syntax:
<!-- Domain Name Server IP address -->
<!ELEMENT dnsServerAddress (#PCDATA)>
<!ATTLIST dnsServerAddress
value NOTATION (IPADR) #IMPLIED>"
構文: 「<!--ドメインName Server IPアドレス--><!ELEMENT dnsServerAddress(#PCDATA)><!ATTLIST dnsServerAddress値のNOTATION(IPADR)#IMPLIED>」
Sofia & Nesser II Informational [Page 32] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[32ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
Additionally, it is stated in Section 6.2.9. (Default Gateway Address):
さらに、それはセクション6.2.9で述べられています。 (デフォルトゲートウェイアドレス):
"The defaulttGatewayAddress element represents the address of the
default gateway which should be used when connected to this POP.
The address is represented in the form of a string in dotted-
decimal notation (e.g., 192.168.101.1).
「defaulttGatewayAddress要素はこのPOPに接続されると使用されるべきであるデフォルトゲートウェイのアドレスを表します。」 アドレスが点を打たされた10進法によるストリングの形に表される、(例えば、192.168 .101 .1)。
Syntax:
<!-- Default Gateway IP address (in dotted decimal notation) -->
<!ELEMENT defaultGatewayAddress (#PCDATA)>
<!ATTLIST defaultGatewayAddress
value NOTATION (IPADR) #IMPLIED>"
構文: 「<!--デフォルトゲートウェイIPアドレス(ドット付き10進法による)--><!ELEMENT defaultGatewayAddress(#PCDATA)><!ATTLIST defaultGatewayAddress値のNOTATION(IPADR)#IMPLIED>」
It should be straightforward to implement elements that are IPv6 aware.
意識していた状態でIPv6である要素を実装するのは簡単であるべきです。
5.145. RFC 3023: XML Media Types
5.145. RFC3023: XMLメディアタイプ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.146. RFC 3028: Sieve: A Mail Filtering Language
5.146. RFC3028: ふるい: 言語をフィルターにかけるメール
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.147. RFC 3030: SMTP Service Extensions for Transmission of
Large and Binary MIME Messages
5.147. RFC3030: 大きくて2進のMIMEメッセージの伝達のためのSMTPサービス拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.148. RFC 3049: TN3270E Service Location and Session
Balancing
5.148. RFC3049: TN3270Eサービス位置とセッションバランスをとること
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.149. RFC 3059: Attribute List Extension for the Service Location
Protocol
5.149. RFC3059: サービス位置のプロトコルのための属性リスト拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.150. RFC 3080: The Blocks Extensible Exchange Protocol Core
(BEEP)
5.150. RFC3080: ブロックの広げることができる交換プロトコルコア(ビープ音)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.151. RFC 3081: Mapping the BEEP Core onto TCP
5.151. RFC3081: TCPへのビープ音コアを写像します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 33] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[33ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
5.152. RFC 3111: Service Location Protocol Modifications for IPv6
5.152. RFC3111: IPv6のためのサービス位置のプロトコル変更
This is an IPv6 related document and is not discussed in this document.
これについて、IPv6の関連するドキュメントであり、本書では議論しません。
5.153. RFC 3302: Tag Image File Format (TIFF) - image/tiff MIME
Sub-type Registration
5.153. RFC3302: タグImage File Format(TIFF)--イメージ/いさかいMIME Sub-タイプRegistration
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.154. RFC 3404: Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)
Resolution Application
5.154. RFC3404: ダイナミックな委譲発見システム(DDDS)パートFour: Uniform Resource Identifier(URI)解決アプリケーション
This specification has no explicit dependency on IPv4. However, when referring to the URI format specified in RFC 2396 (see section 4.3. flags, first paragraph), a reference to RFC 2732 should be also added.
この仕様はIPv4にどんな明白な依存も持っていません。 しかしながら、URI書式を示すのがRFC2396で指定したとき(セクション4.3旗を見てください、第一節)、また、RFC2732の参照は加えられるべきです。
5.155. RFC 3501: Internet Message Access Protocol - Version 4rev1
5.155. RFC3501: インターネットメッセージアクセス・プロトコル--バージョン4rev1
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6. Experimental RFCs
6. 実験的なRFCs
Experimental RFCs belong to the category of "non-standard" specifications. This group involves specifications considered "off- track", e.g., specifications that haven't yet reach an adequate standardization level, or that have been superseded by more recent specifications.
実験的なRFCsは「標準的でない」仕様のカテゴリに属します。 このグループは「オフ道」であると考えられた仕様、例えば適切な標準化レベルに持っていませんが、達するか、または、より最近の仕様で取って代わられた仕様にかかわります。
Experimental RFCs represent specifications that are currently part of some research effort, and that are often propriety in nature, or used in limited arenas. They are documented to the Internet community in order to allow potential interoperability or some other potential useful scenario. In a few cases, they are presented as alternatives to the mainstream solution of an acknowledged problem.
実験的なRFCsは現在何らかの研究取り組みの一部であり、しばしば自然、限られたアリーナで中古の正当である仕様を表します。 それらは、潜在的相互運用性かある他の潜在的役に立つシナリオを許容するためにインターネットコミュニティに記録されます。 いくつかの場合では、それらは承認された問題の主流の解決への代替手段として提示されます。
6.1. RFC 887: Resource Location Protocol
6.1. RFC887: リソース位置のプロトコル
Section 3.1 (Request Messages) contains:
セクション3.1(Messagesを要求します) 含んでいます:
"<Who-Anywhere-Provides?>
This message parallels the <Who-Provides?> message with the
"third-party" variant described above. The confirming host is
required to return at least its own IP address (if it provides the
named resource) as well as the IP addresses of any other hosts it
believes may provide the named resource. The confirming host
「どこでも提供する<?」これが<が「第三者」異形が説明されている>メッセージをWho提供する平行線を通信させる>。 確認しているホストはそれが命名されたリソースを提供するかもしれないと信じているいかなる他のホストのIPアドレスと同様に少なくともそれ自身のIPアドレスを返さなければなりません(命名されたリソースを提供するなら)。 確認しているホスト
Sofia & Nesser II Informational [Page 34] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[34ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
though, may never return an IP address for a resource which is the
same as an IP address listed with the resource name in the request
message. In this case it must treat the resource as if it was
unsupported at that IP address and omit it from any reply list.
もっとも、リソース名が要求メッセージにある状態でIPアドレスが記載したように同じであるリソースのためのIPアドレスを決して返さないかもしれません。 この場合、それは、まるでそれがそのIPアドレスでサポートされないかのようにリソースを扱って、どんな回答リストからもそれを省略しなければなりません。
<Does-Anyone-Provide?>
This message parallels the <Do-You-Provide?> message again with
the "third-party" variant described above. As before, the
confirming host is required to return its own IP address as well
as the IP addresses of any other hosts it believes may provide the
named resource and is prohibited from returning the same IP
address in the reply resource specifier as was listed in the
request resource specifier. As in the <Do-You-Provide?> case and
for the same reason, this message also may not be broadcast."
<、だれでも提供する、--これが通信させる>が<Doに沿う、-、あなた、-提供してください--再び「第三者」異形が上で説明されている>メッセージ。 従来と同様、確認しているホストは、それが命名されたリソースを提供するかもしれないと信じているいかなる他のホストのIPアドレスと同様にそれ自身のIPアドレスを返すのが必要であり、要求リソース特許説明書の作成書に記載された回答リソース特許説明書の作成書で同じ戻っているIPアドレスから禁じられます。 -提供してくれますか?「<Do、-、あなた、>ケースと同じ理由で、このメッセージも放送される必要はありません」
Throughout this section, there are several other references to IP address. To avoid ambiguity, a reference to IPv6 addressing should be added.
このセクション中に、IPアドレスの他のいくつかの参照があります。 あいまいさを避けるために、IPv6アドレシングの参照は加えられるべきです。
Section 4.1. (Resource Lists) presents the following qualifier format:
セクション4.1。 (リソースリスト) 以下の資格を与える人がフォーマットするプレゼント:
"In addition, resource specifiers in all <Who-Anywhere-Provides?>,
<Does-Anyone-Provide?> and <They-Provide> messages also contain an
additional qualifier following the <Protocol-ID>. This qualifier
has the format
-供給してくれますか?「追加、どこでもすべての<Whoのリソース特許説明書の作成書、-、>、<Doesが提供する、-、だれ、も<Protocol ID>に続いて、>と<はまたメッセージが含む>に追加資格を与える人をThey供給します」 この資格を与える人には、形式があります。
+--------+--------+--------+--------+---//---+
| | |
|IPLength| IP-Address-List |
| | |
+--------+--------+--------+--------+---//---+
+--------+--------+--------+--------+---//---+ | | | |IPLength| IP-住所録| | | | +--------+--------+--------+--------+---//---+
where
どこ
<IPLength>
is the number of IP addresses containing in the following <IP-
Address-List> (the <IP-Address-List> field thus occupies the
last 4*<IPLength> octets in its resource specifier). In
request messages, this is the maximum number of qualifying
addresses which may be included in the corresponding reply
resource specifier. Although not particularly useful, it may
be 0 and in that case provides no space for qualifying the
resource name with IP addresses in the returned specifier. In
reply messages, this is the number of qualifying addresses
known to provide the resource. It may not exceed the number
specified in the corresponding request specifier. This field
may not be 0 in a reply message unless it was supplied as 0 in
<IPLength>は以下の<IP-アドレスリストに>を含むIPアドレスの数(その結果IP-アドレスリスト>がさばく<はリソース特許説明書の作成書でベスト4*<IPLength>八重奏を占領する)です。 要求メッセージでは、これは対応する回答リソース特許説明書の作成書に含まれるかもしれない資格を得るアドレスの最大数です。 特に役に立ちませんが、それは、0であるかもしれなく、その場合返された特許説明書の作成書でIPアドレスのリソース名に資格を与えるのにスペースを全く提供しません。 応答メッセージでは、これはリソースを提供するのが知られている資格を得るアドレスの数です。 それは対応する要求特許説明書の作成書で指定された数を超えないかもしれません。 それが0つのコネとして供給されなかったなら、この分野は応答メッセージの0でないかもしれません。
Sofia & Nesser II Informational [Page 35] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[35ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
the request message and the confirming host would have returned
one or more IP addresses had any space been provided.
何かスペースを提供したなら、要求メッセージと確認しているホストは1つ以上のIPアドレスを返したでしょうに。
<IP-Address-List>
is a list of four-octet IP addresses used to qualify the
resource specifier with respect to those particular addresses.
In reply messages, these are the IP addresses of the confirming
host (when appropriate) and the addresses of any other hosts
known to provide that resource (subject to the list length
limitations). In request messages, these are the IP addresses
of hosts for which resource information may not be returned.
In such messages, these addresses should normally be
initialized to some "harmless" value (such as the address of
the querying host) unless it is intended to specifically
exclude the supplied addresses from consideration in any reply
messages."
<IP-アドレスリスト>はそれらの特定のアドレスに関してリソース特許説明書の作成書に資格を与えるのに使用される4八重奏のIPアドレスのリストです。 応答メッセージでは、これらは、確認のアドレスが接待する(適切であるときに)IPとそのリソース(リスト長さの制限を条件とした)を提供するのが知られているいかなる他のホストのアドレスです。 要求メッセージでは、これらはリソース情報が返されないかもしれないホストのIPアドレスです。 「そのようなメッセージでは、明確にどんな応答メッセージでも考慮に供給されたアドレスを入れないようにするのが意図していない場合、通常、これらのアドレスは何らかの「無害な」値(質問しているホストのアドレスなどの)に初期化されるはずです。」
This section requires re-writing considering the 128-bit length of IPv6 addresses, and will clearly impact implementations.
このセクションは、128ビットの長さのIPv6アドレスを考える場合書き直すのが必要であり、明確に実装に影響を与えるでしょう。
6.2. RFC 909: Loader Debugger Protocol (LDP)
6.2. RFC909: 荷物を積む人デバッガプロトコル(自由民主党)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.3. RFC 1143: The Q Method of Implementing TELNET Option
Negotiation
6.3. RFC1143: telnetオプションが交渉であると実装するQメソッド
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.4. RFC 1153: Digest message format (DMF-MAIL)
6.4. RFC1153: ダイジェストメッセージ・フォーマット(DMF-メール)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.5. RFC 1165: Network Time Protocol (NTP) over the OSI Remote
Operations Service
6.5. RFC1165: OSIのリモート操作サービスの上のネットワーク時間プロトコル(NTP)
The only dependency this protocol presents is included in Appendix A (ROS Header Format):
このプロトコルが提示する唯一の依存がAppendix A(ROS Header Format)に含まれています:
"ClockIdentifier ::= CHOICE {
referenceClock[0] PrintableString,
inetaddr[1] OCTET STRING,
psapaddr[2] OCTET STRING
}"
「ClockIdentifier:、:、」= 「CHOICE、referenceClock[0] PrintableString、inetaddr[1] OCTET STRING、psapaddr[2] OCTET STRING、」
6.6. RFC 1176: Interactive Mail Access Protocol: Version 2
6.6. RFC1176: 対話的なメールアクセス・プロトコル: バージョン2
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 36] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[36ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
6.7. RFC 1204: Message Posting Protocol
6.7. RFC1204: メッセージの投稿プロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.8. RFC 1235: Coherent File Distribution Protocol
6.8. RFC1235: コヒーレントファイル分配プロトコル
Section "Protocol Specification" provides the following example, for the Initial Handshake:
「プロトコル仕様」というセクションはInitial Handshakeのための以下の例を提供します:
"The ticket server replies with a "This is Your Ticket" (TIYT)
packet containing the ticket. Figure 2 shows the format of this
packet.
「「これはYour Ticket(TIYT)である」パケットがチケットを含んでいて、チケットサーバは返答します。」 図2はこのパケットの書式を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'T' | 'I' | 'Y' | 'T' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "ticket" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BLKSZ (by default 512) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILSZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address of CFDP server (network order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client UDP port# (cfdpcln) | server UDP port# (cfdpsrv) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | '、'| '私'| 'Y'| '、'| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 「チケット」| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BLKSZ、(デフォルトで、512)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FILSZ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CFDPサーバ(ネットワークオーダー)のIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントUDPは#cfdpcln()を移植します。| サーバUDPポート#(cfdpsrv)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 2: "This Is Your Ticket" packet."
図2: 「「このIs Your Ticket」パケット。」
This protocol assumes IPv4 multicast, but could be converted to IPv6 multicast with a little effort.
このプロトコルをIPv4がマルチキャストであると仮定しますが、小さい取り組みでIPv6マルチキャストに変換できました。
6.9. RFC 1279: X.500 and Domains
6.9. RFC1279: X.500とドメイン
This protocol specifies a protocol that assumes IPv4, but does not actually have any limitations which would limit its operation in an IPv6 environment.
このプロトコルはIPv4を仮定しますが、実際にIPv6環境における操作を制限する少しの制限も持っていないプロトコルを指定します。
6.10. RFC 1312: Message Send Protocol 2
6.10. RFC1312: メッセージはプロトコル2を送ります。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.11. RFC 1339: Remote Mail Checking Protocol
6.11. RFC1339: リモートメール照合プロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 37] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[37ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
6.12. RFC 1440: SIFT/UFT: Sender-Initiated/Unsolicited File
Transfer
6.12. RFC1440: /UFTをふるいわけてください: 送付者によって開始されたか求められていないファイル転送
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.13. RFC 1459: Internet Relay Chat Protocol
6.13. RFC1459: インターネットリレーチャットプロトコル
There are only two specific IPv4 addressing references. The first is presented in Section 6.2. (Command Response):
参照を扱う2の特定のIPv4しかありません。 1番目はセクション6.2に提示されます。 (コマンド応答):
"203 RPL_TRACEUNKNOWN
"???? <class> [<client IP address in dot form>]""
「203RPL_TRACEUNKNOWN」? 「<のクラス>[ドットフォーム>の<クライアントIPアドレス]」、」
The second appears in Section 8.12 (Configuration File):
2番目はセクション8.12(構成File)に現れます:
"In specifying hostnames, both domain names and use of the 'dot'
notation (127.0.0.1) should both be accepted."
「ホスト名、ドメイン名と'ドットの使用の両方を指定する'記法、(127.0、.0、ともに.1を)受け入れるべきである、」
After correcting the above, IPv6 support can be added straightforwardly.
上記を修正した後に、IPv6サポートをまっすぐ加えることができます。
6.14. RFC 1465: Routing Coordination for X.400 MHS Services
Within a Multi Protocol / Multi Network Environment Table
Format V3 for Static Routing
6.14. RFC1465: スタティックルーティングのためのマルチプロトコル/マルチネットワーク環境テーブル形式V3の中のX.400 MHSサービスのためのルート設定コーディネート
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.15. RFC 1505: Encoding Header Field for Internet Messages
6.15. RFC1505: インターネットメッセージのためのヘッダーフィールドをコード化します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.16. RFC 1528: Principles of Operation for the TPC.INT Subdomain:
Remote Printing -- Technical Procedures
6.16. RFC1528: TPC.INTサブドメインのための操作のプリンシプルズ: リモート印刷--技術的な手順
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.17. RFC 1608: Representing IP Information in the X.500
Directory
6.17. RFC1608: X.500ディレクトリにおけるIP情報を表します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.18. RFC 1609: Charting Networks in the X.500 Directory
6.18. RFC1609: X.500ディレクトリでネットワークを図にします。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 38] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[38ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
6.19. RFC 1639: FTP Operation Over Big Address Records
6.19. RFC1639: 大きいアドレス記録の上のFTP操作
This document defines a method for overcoming FTP IPv4 limitations and is therefore both IPv4 and IPv6 aware.
このドキュメントは、FTP IPv4限界を克服するためのメソッドを定義して、したがって、IPv4とIPv6ともに意識しています。
6.20. RFC 1641: Using Unicode with MIME
6.20. RFC1641: MIMEがあるユニコードを使用します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.21. RFC 1756: Remote Write Protocol - Version 1.0
6.21. RFC1756: リモートである、1.0にプロトコル--バージョンを書いてください。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.22. RFC 1801: MHS use of the X.500 Directory to support MHS
Routing
6.22. RFC1801: MHSがルート設定であるとサポートするX.500ディレクトリのMHS使用
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.23. RFC 1804: Schema Publishing in X.500 Directory
6.23. RFC1804: X.500ディレクトリにおける図式出版
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.24. RFC 1806: Communicating Presentation Information in
Internet Messages: The Content-Disposition Header
6.24. RFC1806: インターネットメッセージのプレゼンテーション情報を伝えます: 満足している気質ヘッダー
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.25. RFC 1845: SMTP Service Extension for Checkpoint/Restart
6.25. RFC1845: チェックポイント/再開のためのSMTPサービス拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.26. RFC 1846: SMTP 521 Reply Code
6.26. RFC1846: SMTP521回答コード
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.27. RFC 1873: Message/External-Body Content-ID Access Type
6.27. RFC1873: 外部のメッセージ/ボディーコンテントIDアクセス型
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.28. RFC 1874: SGML Media Types
6.28. RFC1874: SGMLメディアタイプ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 39] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[39ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
6.29. RFC 1986: Experiments with a Simple File Transfer Protocol
for Radio Links using Enhanced Trivial File Transfer Protocol
6.29. RFC1986: ラジオリンクへの簡単なファイル転送プロトコルが高められたトリビアル・ファイル転送プロトコルを使用している実験
This protocol is IPv4 dependent, as can be seen from the segment presented below, taken from Section 2. (PROTOCOL DESCRIPTION):
このプロトコルは以下に提示されたセグメントから見ることができるようにセクション2から連れて行かれたIPv4扶養家族です。 (プロトコル記述):
"Table 3: ETFTP Data Encapsulation
「3を見送ってください」 ETFTPデータカプセル化
+------------+------------+------------+------------+-----------+
|Ethernet(14)| | |ETFTP/ | |
|SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) |
|AX.25(20) | | | | |
+------------+------------+------------+------------+-----------+"
+------------+------------+------------+------------+-----------+ |イーサネット(14)| | |ETFTP/| | |メモ用紙(2)|IP(20)|UDP(8)|NETBLT(24)|データ(1448)| |斧の.25(20)| | | | | +------------+------------+------------+------------+-----------+"
6.30. RFC 2016: Uniform Resource Agents (URAs)
6.30. RFC2016: 一定のリソースエージェント(URAs)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.31. RFC 2066: TELNET CHARSET Option
6.31. RFC2066: telnet CHARSETオプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.32. RFC 2075: IP Echo Host Service
6.32. RFC2075: IPエコーホストサービス
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.33. RFC 2090: TFTP Multicast Option
6.33. RFC2090: TFTPマルチキャストオプション
This protocol is limited to IPv4 multicast. It is expected that a similar functionality could be implemented on top of IPv6 multicast.
このプロトコルはIPv4マルチキャストに制限されます。 IPv6マルチキャストの上で同様の機能性を実装することができたと予想されます。
6.34. RFC 2120: Managing the X.500 Root Naming Context
6.34. RFC2120: X.500根の命名文脈を管理します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.35. RFC 2161: A MIME Body Part for ODA
6.35. RFC2161: ODAのためのMIME身体の部分
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.36. RFC 2162: MaXIM-11 - Mapping between X.400 / Internet
mail and Mail-11 mail
6.36. RFC2162: MaXIM-11--X.400/インターネット・メールとメール-11メールの間のマッピング
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.37. RFC 2169: A Trivial Convention for using HTTP in URN
Resolution
6.37. RFC2169: つぼの解決にHTTPを使用するための些細なコンベンション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 40] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[40ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
6.38. RFC 2217: Telnet Com Port Control Option
6.38. RFC2217: telnet Comポート規制オプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.39. RFC 2295: Transparent Content Negotiation in HTTP
6.39. RFC2295: HTTPにおけるわかりやすい満足している交渉
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.40. RFC 2296: HTTP Remote Variant Selection Algorithm
RVSA/1.0
6.40. RFC2296: HTTPのリモート異形選択アルゴリズムRVSA/1.0
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.41. RFC 2307: An Approach for Using LDAP as a Network
Information Service
6.41. RFC2307: ネットワーク情報サービスとしてLDAPを使用するためのアプローチ
This protocol assumes IPv4 addressing in its schema, as shown in Section 3. (Attribute definitions):
このプロトコルは、セクション3に示されるようにIPv4が図式のアドレシングであると仮定します。 (属性定義):
"( nisSchema.1.19 NAME 'ipHostNumber'
DESC 'IP address as a dotted decimal, eg. 192.168.1.1,
omitting leading zeros'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' )
"(nisSchema.1.19NAME'ipHostNumber'DESC'IPがaドット付き10進法、例えば、192.168として.1を扱う、先行ゼロ'EQUALITY caseIgnoreIA5Match SYNTAX'IA5String128'を省略することでの.1
( nisSchema.1.20 NAME 'ipNetworkNumber'
DESC 'IP network as a dotted decimal, eg. 192.168,
omitting leading zeros'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' SINGLE-VALUE )
(nisSchema.1.20NAME'ドット付き10進法、例えば、先行ゼロを省略する192.168としてのipNetworkNumber'DESC'IPネットワーク'EQUALITY caseIgnoreIA5Match SYNTAX'IA5String128'SINGLE-VALUE)
( nisSchema.1.21 NAME 'ipNetmaskNumber'
DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0,
omitting leading zeros'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' SINGLE-VALUE )"
「(ドット付き10進法、例えば、255.255としてのnisSchema.1.21NAME'ipNetmaskNumber'DESC'IPネットマスク、.255 先行ゼロ'EQUALITY caseIgnoreIA5Match SYNTAX'IA5String128'SINGLE-VALUEを省略することでの.0、」
The document does try to provide some IPv6 support as in Section 5.4. (Interpreting Hosts and Networks):
ドキュメントはセクション5.4のように何らかのIPv6サポートを提供しようとします。 (ホストを解釈して、ネットワーク):
"Hosts with IPv6 addresses MUST be written in their "preferred" form as defined in section 2.2.1 of [RFC1884], such that all components of the address are indicated and leading zeros are omitted. This provides a consistent means of resolving ipHosts by address."
「.1セクション2.2[RFC1884]、アドレスのすべての成分が示されるようなもの、および先行ゼロで定義されるようにそれらの「都合のよい」フォームにアドレスを書かなければならないIPv6のホストは省略されます。」 「これはアドレスでipHostsを決議する一貫した手段を提供します。」
However, the defined format mentioned above has been replaced, hence it is no longer valid.
しかしながら、前記のように定義された形式を取り替えました、したがって、それはもう有効ではありません。
Sofia & Nesser II Informational [Page 41] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[41ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
6.42. RFC 2310: The Safe Response Header Field
6.42. RFC2310: 安全な応答ヘッダーフィールド
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.43. RFC 2483: URI Resolution Services Necessary for URN
Resolution
6.43. RFC2483: つぼの解決に必要なURI解決サービス
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.44. RFC 2567: Design Goals for an Internet Printing Protocol
6.44. RFC2567: インターネット印刷プロトコルのデザイン目標
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.45. RFC 2568: Rationale for the Structure of the Model and
Protocol for the Internet Printing Protocol
6.45. RFC2568: インターネット印刷プロトコルのためのモデルとプロトコルの構造への原理
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.46. RFC 2569: Mapping between LPD and IPP Protocols
6.46. RFC2569: LPDとIPPの間でプロトコルを写像します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.47. RFC 2649: An LDAP Control and Schema for Holding
Operation Signatures
6.47. RFC2649: 引き延ばし作戦署名のためのLDAPコントロールと図式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.48. RFC 2654: A Tagged Index Object for use in the Common
Indexing Protocol
6.48. RFC2654: Common Indexingプロトコルにおける使用のためのTagged Index Object
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.49. RFC 2655: CIP Index Object Format for SOIF Objects
6.49. RFC2655: SOIFオブジェクトのためのCIPインデックスオブジェクト形式
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.50. RFC 2656: Registration Procedures for SOIF Template Types
6.50. RFC2656: SOIFテンプレートタイプのための登録手順
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.51. RFC 2657: LDAPv2 Client vs. the Index Mesh
6.51. RFC2657: LDAPv2クライアント対インデックスメッシュ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Sofia & Nesser II Informational [Page 42] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[42ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
6.52. RFC 2756: Hyper Text Caching Protocol
6.52. RFC2756: プロトコルをキャッシュする超-テキスト
This specification claims to be both IPv4 and IPv6 aware, but in Section 2.8. (An HTCP/0.0 AUTH has the following structure), it makes the following statement:
IPv4とIPv6の両方が意識していたなら主張しますが、この仕様はセクション2.8でそうします。 (HTCP/0.0 AUTHには、以下の構造があります), それは以下の声明を出します:
"SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5 digest
(see [RFC 2104]), with a B value of 64, of the
following elements, each of which is digested in its
"on the wire" format, including transmitted padding
if any is covered by a field's associated LENGTH:
「SIGNATUREはHMAC-MD5ダイジェストを保持するCOUNTSTR[3.1]です([RFC2104]を見てください)、それのそれぞれがそれが「ワイヤ」であるという形式で読みこなされる64、以下の要素のB価値で、いずれかフィールドの関連LENGTHでカバーされているなら伝えられた詰め物を含んでいて」
IP SRC ADDR [4 octets]
IP SRC PORT [2 octets]
IP DST ADDR [4 octets]
IP DST PORT [2 octets]
HTCP MAJOR version number [1 octet]
HTCP MINOR version number [1 octet]
SIG-TIME [4 octets]
SIG-EXPIRE [4 octets]
HTCP DATA [variable]
KEY-NAME (the whole COUNTSTR [3.1]) [variable]"
「IP SRC ADDR[4つの八重奏]IP SRC PORT[2つの八重奏]IP DST ADDR[4つの八重奏]IP DST PORT[2つの八重奏]HTCP MAJORバージョン番号[1つの八重奏]HTCP MINORバージョン番号[1つの八重奏]SIGタイム誌[4つの八重奏]SIG-EXPIRE[4つの八重奏]のHTCP DATAの[可変]のKEY-NAME、(全体のCOUNTSTR[3.1])[可変]、」
The given SIGNATURE calculation should be expanded to support IPv6 16 byte addresses.
与えられたSIGNATURE計算は、IPv6 16にバイト・アドレスをサポートするために広げられるべきです。
6.53. RFC 2774: An HTTP Extension Framework
6.53. RFC2774: HTTP拡大フレームワーク
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.54. RFC 2974: Session Announcement Protocol
6.54. RFC2974: セッション発表プロトコル
This protocol is both IPv4 and IPv6 aware and needs no changes.
このプロトコルは、IPv4とIPv6ともに意識していて、変化を全く必要としません。
6.55. RFC 3018: Unified Memory Space Protocol Specification
6.55. RFC3018: 統一されたメモリスペースプロトコル仕様
In section 3.4 (Address Formats), there are explicit references to IPv4 addressing:
セクション3.4(アドレスFormats)に、IPv4アドレシングの明白な参照があります:
"The following address format numbers are definite for nodes,
immediately connected to the global IPv4 network:
「以下のアドレス形式番号は、ノードに明確であって、すぐに、グローバルなIPv4ネットワークに関連しています」
N 4-0-0 (4)
N 4-0-1 (4-1)
N 4-0-2 (4-2)
N4-0-0(4)N4-0-1(4-1)N4-0-2(4-2)
Sofia & Nesser II Informational [Page 43] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[43ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
The appropriate formats of 128-bit addresses:
128ビットのアドレスの適切な形式:
Octets:
+0 +1 +2 +3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
八重奏: +0 +1 +2 +3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0: |0 1 0 0|0 0|0 0| 自由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4: | 自由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8: | 自由| IPアドレス| +++++++++++++++++++++++++++++++++12: | IPアドレス| 地方のメモリアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 1| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0: |0 1 0 0|0 0|0 1| 自由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4: | 自由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8: | 自由| IPアドレス| +++++++++++++++++++++++++++++++++12: | IPアドレス| 地方のメモリアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|1 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0: |0 1 0 0|0 0|1 0| 自由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4: | 自由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8: | IPアドレス| +++++++++++++++++++++++++++++++++12: | 地方のメモリアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Free
自由
It is not used by the protocol.
それはプロトコルによって使用されません。
IP address
IPアドレス
It sets the node address in the global IPv4 network."
「グローバルなIPv4ネットワークにノードアドレスをはめ込みます。」
This section needs to be re-written, so that the specification becomes IPv6 compliant.
このセクションが、書き直される必要があるので、仕様はIPv6対応するのになります。
Sofia & Nesser II Informational [Page 44] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[44ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
6.56. RFC 3082: Notification and Subscription for SLP
6.56. RFC3082: SLPのための通知と購読
This protocol is both IPv4 and IPv6 aware, and thus requires no changes.
このプロトコルは、IPv4とIPv6ともに意識していて、その結果、変化を全く必要としません。
6.57. RFC 3088: OpenLDAP Root Service An experimental LDAP
referral service
6.57. RFC3088: OpenLDAP Root Service Anの実験的なLDAP紹介サービス
Section 5. (Using the Service) states:
セクション5。 (サービスを利用します) 州:
"The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over
TCP/IPv4. Future incarnations of this service may support
TCP/IPv6 or other transport/internet protocols."
「サービスはTCP/IPv4の上で+ [LDAPv2+]クライアントをLDAPv3とLDAPv2にサポートします。」 「このサービスの将来の肉体化は、TCP/IPv6か他の輸送/インターネットがプロトコルであるとサポートするかもしれません。」
7. Summary of Results
7. 結果の概要
This survey contemplates 257 RFCs, having 34 (12.84%) been identified as having some form of IPv4 dependency. Results are broken down as follows:
この調査は257RFCs、有34のために何らかのフォームのIPv4の依存を持っているとして特定された(12.84%)を熟考します。 結果は以下の通り砕けています:
Standards: 1 out of 20 or 5.00%
Draft Standards: 4 out of 25 or 16.00%
Proposed Standards: 19 out of 155 or 12.26%
Experimental RFCs: 10 out of 57 or 17.54%
規格: 20のうちの1か5.00%が規格を作成します: 25%か16.00%のうちの4は規格を提案しました: 155のうちの19か12.26%の実験的なRFCs: 10 57%か17.54%から
Of the 33 identified, the majority simply require minor actions, such as adding a caveat to IPv6 addressing that would avoid ambiguity, or re-writing a section to avoid IP-version dependent syntax. The remaining instances are documented below. The authors have attempted to organize the results in a format that allows easy referencing by other protocol designers.
大部分が単に小さい方の動作を必要とします、特定された33ではそれを扱うIPv6への警告があいまいさを避けると言い足すか、またはIP-バージョンに依存する構文を避けるためにセクションを書き直すのなどように。 残っているインスタンスは以下に記録されます。 作者は、他のプロトコルデザイナーによる簡単な参照箇所を許す形式で結果を組織化するのを試みました。
7.1. Full Standards
7.1. 完全な規格
7.1.1. RFC 959: STD 9 File Transfer Protocol
7.1.1. RFC959: STD9ファイル転送プロトコル
Problems have already been fixed in [5].
[5]で既に問題を修正してあります。
7.2. Draft Standards
7.2. 草稿規格
7.2.1. RFC 1305: Network Time Protocol (version 3): Specification,
Implementation and Analysis
7.2.1. RFC1305: 時間プロトコル(バージョン3)をネットワークでつないでください: 仕様、実装、および分析
As documented in Section 4.4. above, there are too many specific references to the use of 32-bit IPv4 addresses. An updated specification to support NTP over IPv6 is needed. However, there has been some work related with this issue, as an already expired
セクション4.4に記録されるように、32ビットのIPv4アドレスの使用にはあまりに多くの特定指示が上に、あります。 IPv6の上でNTPをサポートするアップデートされた仕様が必要です。 しかしながら、この問題に関連づけられたいくらかの仕事があった、既に、期限が切れます。
Sofia & Nesser II Informational [Page 45] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[45ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
work in progress, allegedly documents. Also, there is at least one IPv6 NTP implementation.
進歩、申し立てによるとドキュメントで働いてください。 また、少なくとも1つのIPv6 NTP実装があります。
7.2.2. RFC 2396: URI Syntax
7.2.2. RFC2396: URI構文
URI's allow the literal use of IPv4 addresses but have no specific recommendations on how to represent literal IPv6 addresses. This problem has already been addressed in [3].
IPv4アドレスの文字通りの使用を許しますが、URIのものには、どう文字通りのIPv6アドレスを表すかにおけるどんな特定の推薦もありません。 この問題は[3]で既に扱われました。
7.2.3. RFC 2616: Hypertext Transfer Protocol HTTP/1.1
7.2.3. RFC2616: ハイパーテキスト転送プロトコルHTTP/1.1
HTTP allows the literal use of IPv4 addresses, but has no specific recommendations on how to represent literal IPv6 addresses. This problem has already been addressed in [3].
HTTPには、IPv4アドレスの文字通りの使用を許しますが、どう文字通りのIPv6アドレスを表すかにおけるどんな特定の推薦もありません。 この問題は[3]で既に扱われました。
7.3. Proposed Standards
7.3. 提案された標準
7.3.1. RFC 946: Telnet Terminal LOC
7.3.1. RFC946: telnet端末LOC
There is a dependency in the definition of the TTYLOC Number which would require an updated version of the protocol. However, since this functionality is of marginal value today, an updated version might not make sense.
プロトコルのアップデートされたバージョンを必要とするTTYLOC Numberの定義における依存があります。 しかしながら、今日、限界価値がこの機能性にあるので、アップデートされたバージョンは理解できないかもしれません。
7.3.2. RFC 1738: URLs
7.3.2. RFC1738: URL
URL's with IPv4 dependencies have already been addressed in [3].
IPv4の依存に伴うURLは[3]で既に扱われました。
Note that these dependencies affect other specifications as well, such as RFC 2122, RFC 2192, RFC 2193, RFC 2255, RFC 2371, and RFC 2384. All of these protocols have to revisited, and are not described separately in this memo.
RFC2122や、RFC2192や、RFC2193や、RFC2255や、RFC2371や、RFC2384などのようにこれらの依存がまた、他の仕様に影響することに注意してください。 これらのプロトコルのすべては、再訪していた状態で説明しなければならなくて、別々にこのメモで説明されません。
7.3.3. RFC 2165: Service Location Protocol
7.3.3. RFC2165: サービス位置のプロトコル
The problems of this specification have already been addressed in [4].
この仕様の問題は[4]で既に扱われました。
7.3.4. RFC 2384: POP3 URL Scheme
7.3.4. RFC2384: POP3URL体系
POP URL IPv4 dependencies have already been addressed in [3].
POP URL IPv4の依存は[3]で既に扱われました。
7.3.5. RFC 2608: Service Location Protocol v2
7.3.5. RFC2608: サービスLocationプロトコルv2
The problems of this specification have already been addressed in [4].
この仕様の問題は[4]で既に扱われました。
Sofia & Nesser II Informational [Page 46] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[46ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
7.3.6. RFC 2821: Simple Mail Transfer Protocol
7.3.6. RFC2821: シンプルメールトランスファプロトコル
Some textual updates and clarifications to MX processing would likely be useful. The operational scenarios and guidelines to avoid the problems have been described in [6].
MX処理へのいくつかの原文のアップデートと明確化がおそらく役に立つでしょう。 問題を避ける操作上のシナリオとガイドラインは[6]で説明されます。
7.3.7. RFC 3017: XML DTP For Roaming Access Phone Books
7.3.7. RFC3017: ローミングアクセス電話帳のためのXML DTP
Extensions should be defined to support IPv6 addresses.
拡大は、IPv6にアドレスをサポートするために定義されるべきです。
7.4. Experimental RFCs
7.4. 実験的なRFCs
7.4.1. RFC 1235: The Coherent File Distribution Protocol
7.4.1. RFC1235: コヒーレントファイル分配プロトコル
The packet format of this protocol depends on IPv4, and would require updating to add IPv6 support. However, the protocol is not believed to be in use, so such an update may not be warranted.
このプロトコルのパケット・フォーマットは、IPv4によって、IPv6サポートを加えるためにアップデートするのを必要とするでしょう。 しかしながら、プロトコルが使用中であると信じられていないので、そのようなアップデートは保証されないかもしれません。
7.4.2. RFC 1459: Internet Relay Chat Protocol
7.4.2. RFC1459: インターネットリレーチャットプロトコル
This specification only requires a text update to become IPv6 compliant.
この仕様は、テキスト最新版がIPv6対応するのになるのを必要とするだけです。
7.4.3. RFC 1986: Simple File Transfer Using Enhanced TFTP
7.4.3. RFC1986: 簡単なファイル転送使用はTFTPを高めました。
This specification only requires a text update to become IPv6 compliant.
この仕様は、テキスト最新版がIPv6対応するのになるのを必要とするだけです。
7.4.4. RFC 2090: TFTP Multicast Option
7.4.4. RFC2090: TFTPマルチキャストオプション
This protocol relies on IPv4 IGMP Multicast. To become IPv6 compliant, a new version should be produced.
このプロトコルはIPv4 IGMP Multicastを当てにします。 IPv6対応するのになるように、新しいバージョンは生産されるべきです。
7.4.5. RFC 2307: Using LDAP as a NIS
7.4.5. RFC2307: NISとしてLDAPを使用します。
This document tries to provide IPv6 support but it relies on an outdated format for IPv6 addresses. Thus, there is the need for an IPv6 compliant version.
このドキュメントはサポートをIPv6に供給しようとしますが、それはIPv6アドレスのための時代遅れの形式を当てにします。 したがって、IPv6対応バージョンの必要があります。
8. Acknowledgements
8. 承認
Phil would like to acknowledge the support of the Internet Society in the research and production of this document. Additionally, Phil would like to thank his partner in all ways, Wendy M. Nesser.
フィルは研究における、インターネット協会のサポートとこのドキュメントの生産を承諾したがっています。 ウェンディーM.Nesser、さらに、フィルはすべての方法で彼のパートナーに感謝したがっています。
Sofia & Nesser II Informational [Page 47] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[47ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
9. Security Considerations
9. セキュリティ問題
This document provides an exhaustive documentation of current IETF documented standards IPv4 address dependencies. Such process does not have security implications in itself.
このドキュメントは記録された規格IPv4アドレスの依存を現在のIETFの徹底的なドキュメンテーションに供給します。 そのようなプロセスには、本来、セキュリティ意味がありません。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the
Survey of IPv4 Addresses in Currently Deployed IETF Standards",
RFC 3789, June 2004.
[1] Nesser、II、P.、およびA.ベルイストローム、エディタ、「IPv4の調査への紹介は現在配布しているIETFで規格を扱います」、RFC3789、2004年6月。
[2] Bradner, S., "The Internet Standards Process - version 3", BCP 9,
RFC 2026, October 1996.
[2] ブラドナー、S.、「バージョン3インチ、BCP9、RFC2026、1996年インターネットStandards Process--10月。」
10.2. Informative References
10.2. 有益な参照
[3] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999.
[3]Hinden、R.、大工、B.、およびL.Masinter、「URLの文字通りのIPv6アドレスのための形式」、RFC2732、1999年12月。
[4] Guttman, E., "Service Location Protocol Modifications for IPv6",
RFC 3111, May 2001.
[4] Guttman(E.)は「2001年5月にIPv6"、RFC3111年の位置のプロトコル変更を修理します」。
[5] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6
and NATs", RFC 2428, September 1998.
[5] オールマンとM.とオステルマンとS.とC.メス、「IPv6とNATsのためのFTP拡大」、RFC2428、1998年9月。
[6] Hagino, J. and M. Nakamura, "SMTP operational experience in mixed
IPv4/IPv6 environements", Work in Progress.
[6] ProgressのHaginoとJ.とM.中村、「混ぜられたIPv4/IPv6 environementsのSMTP運用経験」、Work。
Sofia & Nesser II Informational [Page 48] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[48ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
11. Authors' Addresses
11. 作者のアドレス
Rute Sofia FCCN Av. Brasil, 101 1700 Lisboa, Portugal
ルーテソフィアFCCN Av。 ブラジル、101 1700リスボア(ポルトガル)
Phone: +351 91 2507372 EMail: rsofia@zmail.pt
以下に電話をしてください。 +351 91 2507372はメールされます: rsofia@zmail.pt
Philip J. Nesser II Principal Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034
ワシントン フィリップJ.Nesser II主体Nesser&Nesserコンサルティング13501第100Ave Ne、#5202カークランド、98034
Phone: +1 425 481 4303 Fax: +1 425 482 9721 EMail: phil@nesser.com
以下に電話をしてください。 +1 425 481、4303Fax: +1 9721年の425 482メール: phil@nesser.com
Sofia & Nesser II Informational [Page 49] RFC 3895 IPv4 Addresses in the IETF Application Area June 2004
ソフィアとNesserのIIの情報[49ページ]のRFC3895IPv4は、2004年6月にIETFでアプリケーションが領域であると扱います。
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (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.
Copyright(C)インターネット協会(2004)。 このドキュメントは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 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に情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Sofia & Nesser II Informational [Page 50]
ソフィアとNesser II情報です。[50ページ]
一覧
スポンサーリンク
