RFC4084 日本語訳
4084 Terminology for Describing Internet Connectivity. J. Klensin. May 2005. (Format: TXT=24522 bytes) (Also BCP0104) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Klensin Request for Comments: 4084 May 2005 BCP: 104 Category: Best Current Practice
Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4084 2005年5月のBCP: 104カテゴリ: 最も良い現在の習慣
Terminology for Describing Internet Connectivity
インターネットの接続性について説明するための用語
Status of This Memo
このメモの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered.
インターネットが発展したとき、「インターネットの接続性」として多くのタイプのアレンジメントは広告を出して、販売しました。 これらはそれらが提供する能力、選択の範囲、およびどんな標準の用語の不足においても有意差があるかもしれないので、これらのサービスの間で区別する取り組みはかなりの消費者混乱を引き起こしました。 このドキュメントはプロバイダー、消費者、および潜在的に監視委員にとって、提供されるサービスのタイプとキャラクタをはっきりさせるのに有用であるかもしれない用語と定義のリストを提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The Problem and the Requirement . . . . . . . . . . . . 2
1.2. Adoption and a Non-pejorative Terminology . . . . . . . 2
2. General Terminology . . . . . . . . . . . . . . . . . . . . . 3
3. Filtering or Security Issues and Terminology . . . . . . . . . 5
4. Additional Terminology . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . . 9
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 問題と要件. . . . . . . . . . . . 2 1.2。 採用と非軽蔑語用語. . . . . . . 2 2。 一般用語. . . . . . . . . . . . . . . . . . . . . 3 3。 フィルタリングか安全保障問題と用語. . . . . . . . . 5 4。 追加用語. . . . . . . . . . . . . . . . . . . . 7 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 9 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 9 7。 有益な参照. . . . . . . . . . . . . . . . . . . . 9
Klensin Best Current Practice [Page 1] RFC 4084 IP Service Terms May 2005
最も良い現在のKlensinの練習[1ページ]RFC4084IPサービス用語2005年5月
1. Introduction
1. 序論
1.1. The Problem and the Requirement
1.1. 問題と要件
Different ISPs and other providers offer a wide variety of products that are identified as "Internet" or "Internet access". These products offer different types of functionality and, as a result, some may be appropriate for certain users and uses and not others. For example, a service that offers only access to the Web (in this context, the portion of the Internet that is accessible via the HTTP and HTTPS protocols) may be appropriate for someone who is exclusively interested in browsing and in Web-based email services. It will not be appropriate for someone who needs to download files or use email more frequently. And it is likely to be even less appropriate for someone who needs to operate servers for other users, who needs virtual private network (VPN) capabilities or other secured access to a remote office, or who needs to synchronize mail for offline use.
異なったISPと他のプロバイダーは「インターネット」か「インターネット・アクセス」として特定されるさまざまな製品を提供します。 これらの製品は異なったタイプの機能性を提供します、そして、その結果、他のものではなく、確信しているユーザと用途に、或るものは適切であるかもしれません。 例えば、排他的にブラウジングとウェブベースのメールサービスに興味を持っているだれかにとって、ウェブ(この文脈のHTTPとHTTPSプロトコルでアクセスしやすいインターネットの部分)へのアクセスだけを提供するサービスは適切であるかもしれません。 それはファイルをダウンロードするか、または、より頻繁にメールを使用する必要があるだれかにとって適切にならないでしょう。 そして、それは他のユーザのためにサーバを操作するのが必要であり、遠く離れたオフィスへのアクセスであることを何らかの仮想私設網(VPN)能力を保証するのが必要である、またはオフライン使用のためのメールを同期させる必要があるだれかにはそれほど適切でないのさえ傾向があります。
Recent and rapidly evolving changes to the Internet's email environment have led to additional restrictions on sending and retrieving email. These restrictions, most of them developed as part of well intentioned attempts to prevent or fight unsolicited mail, may be imposed independently of the service types described below and are discussed separately in Section 3.
インターネットのメール環境への最近の、そして、急速に発展している変化はメールを送って、検索するときの追加制限に通じました。 これらの制限、それらの大部分について、迷惑メールと防ぐか、または戦うよく意図を持った試みの一部として展開して、以下で説明されたサービスタイプの如何にかかわらず課されるかもしれなくて、別々にセクション3で議論します。
This document describes only the functions provided or permitted by the service provider. It does not and cannot specify the functions that pass through and are supported by various user-provided equipment.
このドキュメントはサービスプロバイダーが提供したか、または受入れた機能だけについて説明します。 それは指定しません、そして、通り抜けて、様々なユーザによって提供された設備によってサポートされる機能は指定できません。
The terms SHOULD, MUST, or MAY are capitalized in this document, as defined in [1].
SHOULDという用語、[1]で定義されるように本書では5月を大文字で書かなければなりません。
1.2. Adoption and a Non-pejorative Terminology
1.2. 採用と非軽蔑語用語
The definitions proposed here are of little value if service providers and vendors are not willing to adopt them. The terms proposed are intended not to be pejorative, despite the belief of some members of the IETF community that some of these connectivity models are simply "broken" or "not really an Internet service". The mention of a particular service or model in this document does not imply any endorsement of it, only recognition of something that exists or might exist in the marketplace. Thus, the Best Current Practice described in this document is about terminology and information that should be supplied to the user and not about the types of service that should be offered.
ここで提案された定義には、サービスプロバイダーとベンダーがそれらを採用することを望んでいないなら、価値がほとんどありません。 提案された用語は軽蔑語でないことを意図します、これらの何人かの接続性モデルが単に「壊れてい」て「本当にインターネットのサービスでない」であるというIETF共同体の何人かのメンバーの信念にもかかわらず。 特定のサービスかモデルの言及は本書ではそれ(存在しているか、または市場に存在するかもしれない何かの認識だけ)の少しの裏書きも含意しません。 したがって、本書では説明されたBest Current Practiceは提供されるべきであるサービスのタイプではなく、ユーザに提供されるべきである用語と情報に関するものです。
Klensin Best Current Practice [Page 2] RFC 4084 IP Service Terms May 2005
最も良い現在のKlensinの練習[2ページ]RFC4084IPサービス用語2005年5月
2. General Terminology
2. 一般用語
This section lists the primary IP service terms. It is hoped that service providers will adopt these terms, to better define the services to potential users or customers. The terms refer to the intent of the provider (ISP), as expressed in either technical measures or terms and conditions of service. It may be possible to work around particular implementations of these characteristic connectivity types, but that freedom is generally not the intent of the provider and is unlikely to be supported if the workarounds stop working.
このセクションはプライマリIPサービス用語をリストアップします。サービスプロバイダーが潜在的ユーザか顧客に対するサービスをよりよく定義するためにこれらの用語を採用することが望まれています。 用語はプロバイダー(ISP)の意図について言及します、サービスの技術的な測定か条件のどちらかで言い表されるように。 これらの独特の接続性タイプの特定の実装の周りで働いているのが可能であるかもしれませんが、その自由は一般にプロバイダーの意図でなく、回避策が仕事を中止するなら、サポートされそうにはありません。
The service terms are listed in order of ascending capability, to reach "full Internet connectivity".
「完全なインターネットの接続性」に達するように能力を昇ることの順にサービス用語はリストアップされています。
o Web connectivity.
o ウェブの接続性。
This service provides connectivity to the Web, i.e., to services
supported through a "Web browser" (such as Firefox, Internet
Explorer, Mozilla, Netscape, Lynx, or Opera), particularly those
services using the HTTP or HTTPS protocols. Other services are
generally not supported. In particular, there may be no access to
POP3 or IMAP4 email, encrypted tunnels or other VPN mechanisms.
このサービスは接続性をウェブに提供します、すなわち、「ウェブブラウザ」(ファイヤーフォックス、インターネット・エクスプローラー、Mozilla、Netscape、Lynx、またはOperaなどの)を通してサポートされたサービス、特にHTTPを使用するそれらのサービスまたはHTTPSプロトコルに。 一般に、他のサービスはサポートされません。 特に、POP3、IMAP4メール、暗号化されたトンネルまたは他のVPNメカニズムへのアクセスが全くないかもしれません。
The addresses used may be private and/or not globally reachable.
They are generally dynamic (see the discussion of dynamic
addresses in Section 3 for further discussion of this terminology
and its implications) and relatively short-lived (hours or days
rather than months or years). These addresses are often announced
as "dynamic" to those who keep lists of dial-up or dynamic
addresses. The provider may impose a filtering Web proxy on the
connections; that proxy may change and redirect URLs to other
sites than the one originally specified by the user or embedded
link.
使用されるアドレスは、個人的である、そして/または、グローバルに届いていないかもしれません。 それらは、一般に、ダイナミックであって(この用語とその含意のさらなる議論に関してセクション3における、ダイナミックなアドレスの議論を見ます)、比較的短命です(何カ月もの何年ものむしろ何時間も何日も)。 これらのアドレスは「動力」としてしばしばダイヤルアップかダイナミックなアドレスのリストを保つ人に発表されます。 プロバイダーはフィルタリングウェブプロキシを接続に課すかもしれません。 そのプロキシは、1個の元々ユーザによって指定されたか、または埋め込まれたリンク以外のサイトにURLを変えて、向け直すかもしれません。
o Client connectivity only, without a public address.
o 場内放送のないクライアントの接続性専用。
This service provides access to the Internet without support for
servers or most peer-to-peer functions. The IP address assigned
to the customer is dynamic and is characteristically assigned from
non-public address space. Servers and peer-to-peer functions are
generally not supported by the network address translation (NAT)
systems that are required by the use of private addresses. (The
more precise categorization of types of NATs given in [2] are
somewhat orthogonal to this document, but they may be provided as
additional terms, as described in Section 4.)
このサービスはサーバのサポートもほとんどのピアツーピア機能なしでインターネットへのアクセスを提供します。 顧客に割り当てられたIPアドレスは、ダイナミックであり、非場内放送スペースから特徴として割り当てられます。 サーバとピアツーピア機能はプライベート・アドレスの使用で必要である一般に、ネットワークアドレス変換でサポートしていない(NAT)システムです。 ([2]で与えられているNATsのタイプの、より正確な分類はこのドキュメントといくらか直交していますが、追加用語として彼らを提供するかもしれません、セクション4で説明されるように。)
Klensin Best Current Practice [Page 3] RFC 4084 IP Service Terms May 2005
最も良い現在のKlensinの練習[3ページ]RFC4084IPサービス用語2005年5月
Filtering Web proxies are common with this type of service, and
the provider SHOULD indicate whether or not one is present.
フィルタリングウェブプロキシはこのタイプのサービスについて一般的です、そして、プロバイダーSHOULDは1つが存在しているかどうかを示します。
o Client only, public address.
o クライアントの唯一の、そして、公共のアドレス。
This service provides access to the Internet without support for
servers or most peer-to-peer functions. The IP address assigned
to the customer is in the public address space. It is usually
nominally dynamic or otherwise subject to change, but it may not
change for months at a time. Most VPN and similar connections
will work with this service. The provider may prohibit the use of
server functions by either legal (contractual) restrictions or by
filtering incoming connection attempts.
このサービスはサーバのサポートもほとんどのピアツーピア機能なしでインターネットへのアクセスを提供します。 顧客に割り当てられたIPアドレスが場内放送スペースにあります。 変化するのは通常、名目上はダイナミックであるか、またはそうでなければ、受けることがありますが、それは一度に数か月にわたって変化しないかもしれません。 ほとんどのVPNと同様の接続はこのサービスで働くでしょう。 プロバイダーは、法的な(契約上の)制限か接続要求試みをフィルターにかけることによって、サーバ機能の使用を禁止するかもしれません。
Filtering Web proxies are uncommon with this type of service, and
the provider SHOULD indicate if one is present.
フィルタリングウェブプロキシはこのタイプのサービスによって珍しいです、そして、プロバイダーSHOULDは1つが存在しているかどうかを示します。
o Firewalled Internet Connectivity.
o インターネットの接続性をFirewalledしました。
This service provides access to the Internet and supports most
servers and most peer-to-peer functions, with one or (usually)
more static public addresses. It is similar to "Full Internet
Connectivity", below, and all of the qualifications and
restrictions described there apply. However, this service places
a provider-managed "firewall" between the customer and the public
Internet, typically at customer request and at extra cost compared
to non-firewalled services. Typically by contractual arrangements
with the customer, this may result in blocking of some services.
このサービスは、ほとんどのサーバとほとんどのピアツーピアが機能であるとインターネットへのアクセスを前提として、サポートします、1か(通常)より静的な場内放送で。 それは以下で「完全なインターネットの接続性」と同様です、そして、そこで説明された資格と制限のすべてが適用されます。 しかしながら、このサービスは顧客と公共のインターネットの間と、そして、通常顧客の要求において非firewalledされたサービスにたとえられた追加費用においてプロバイダーで管理された「ファイアウォール」を置きます。 通常顧客との契約の約定で、これはいくつかのサービスのブロッキングをもたらすかもしれません。
Other services may be intercepted by proxies, content-filtering
arrangements, or application gateways. The provider SHOULD
specify which services are blocked and which are intercepted or
altered in other ways.
他のサービスはプロキシ、コンテントのフィルタリングアレンジメント、またはアプリケーションゲートウェイによって妨害されるかもしれません。 プロバイダーSHOULDは、どれが他の方法でどのサービスが妨げられるか、そして、妨害されるか、または変更されるかを指定します。
In most areas, this service arrangement is offered as an add-on,
extra-cost, option with what would otherwise be Full Internet
Connectivity. It is distinguished from the models above by the
fact that any filtering or blocking services are ultimately
performed at customer request, rather than being imposed as
service restrictions.
ほとんどの領域では、アドオンとしてこのサービスアレンジメントを提供します、追加費用、そうでなければ、FullインターネットConnectivityであることがあるオプション。 どんなフィルタリングやブロッキングサービスも結局サービス制限として課されるより顧客の要求でむしろ実行されるという事実によってそれは上でモデルと区別されます。
o Full Internet Connectivity.
o 完全なインターネットの接続性。
This service provides the user full Internet connectivity, with
one or more static public addresses. Dynamic addresses that are
long-lived enough to make operating servers practical without
highly dynamic DNS entries are possible, provided that they are
not characterized as "dynamic" to third parties.
このサービスはユーザの完全なインターネットの接続性を1つ以上の静的な場内放送に提供します。 非常にダイナミックなDNSエントリーなしで実用的なサーバを操作しながら作るほど長命であることのダイナミックなアドレスは可能です、それらが「動力」として第三者に特徴付けられなければ。
Klensin Best Current Practice [Page 4] RFC 4084 IP Service Terms May 2005
最も良い現在のKlensinの練習[4ページ]RFC4084IPサービス用語2005年5月
Filtering Web proxies, interception proxies, NAT, and other
provider-imposed restrictions on inbound or outbound ports and
traffic are incompatible with this type of service. Servers on a
connected customer LAN are typically considered normal. The only
compatible restrictions are bandwidth limitations and prohibitions
against network abuse or illegal activities.
ウェブプロキシをフィルターにかけて、妨害プロキシ、NAT、および本国行きの、または、外国行きのポートとトラフィックにおける他のプロバイダーで課された制限はこのタイプのサービスと両立しないです。 接続顧客LANに関するサーバは正常であると通常考えられます。 唯一のコンパチブル制限は、ネットワーク乱用か非合法活動に対する帯域幅制限と禁止です。
3. Filtering or Security Issues and Terminology
3. フィルタリングか安全保障問題と用語
As mentioned in the Introduction, the effort to control or limit objectionable network traffic has led to additional restrictions on the behavior and capabilities of internet services. Such objectionable traffic may include unsolicited mail of various types (including "spam"), worms, viruses, and their impact, and in some cases, specific content.
Introductionで言及されるように、好ましくないネットワークトラフィックを制御するか、または制限する取り組みは振舞いの追加制限とインターネットサービスの能力につながりました。 そのような好ましくないトラフィックは様々なタイプ(「スパム」を含んでいる)、ワーム、ウイルス、それらの影響、およびいくつかの場合特定の内容に関する迷惑メールを含むかもしれません。
In general, significant restrictions are most likely to be encountered with Web connectivity and non-public-address services, but some current recommendations would apply restrictions at all levels. Some of these mail restrictions may prevent sending outgoing mail (except through servers operated by the ISP for that purpose), may prevent use of return addresses of the user's choice, and may even prevent access to mail repositories (other than those supplied by the provider) by remote-access protocols such as POP3 or IMAP4. Because users may have legitimate reasons to access remote file services, remote mail submission servers (or, at least, to use their preferred email addresses from multiple locations), and to access remote mail repositories (again, a near-requirement if a single address is to be used), it is important that providers disclose the services they are making available and the filters and conditions they are imposing.
一般に、重要な制限はウェブの接続性と非場内放送サービスで最も遭遇しそうですが、いくつかの現在の推薦がすべてのレベルで制限を適用するでしょう。 これらのメール制限のいくつかが、送信するメール(ISPによってそのために操作されたサーバを除いた)を送るのを防いで、ユーザの選択の返送先の使用を防いで、POP3かIMAP4などの遠隔アクセスプロトコルで、倉庫(プロバイダーによって供給されたものを除いた)を郵送するためにアクセスを防ぎさえするかもしれません。 ユーザがアクセスするもっともな理由をリモートにするかもしれないので、サービスをファイルしてください、リモートメール服従サーバ、(アクセスにリモートな複数の所在地からのそれらの都合のよいEメールアドレスを使用するために、少なくとも、倉庫を郵送してください、(再びa、ほぼ要件に、aただ一つのアドレスであるなら使用されることになっていてください、)、プロバイダーがそれらが課しているそれらが利用可能にしているサービス、フィルタ、および状態を明らかにするのは、重要です。
Several key issues in email filtering are of particular importance.
メールフィルタリングにおけるいくつかの主要な問題が特別に重要です。
o Dynamic Addresses.
o ダイナミックなアドレス。
A number of systems, including several "blacklist" systems, are
based on the assumption that most undesired email originates from
systems with dynamic addresses, especially dialup and home
broadband systems. Consequently, they attempt to prevent the
addresses from being used to send mail, or perform some other
services, except through provider systems designated for that
purpose.
数個の「ブラックリスト」システムを含む多くのシステムが最も望まれないメールがシステムからダイナミックなアドレス、特にダイアルアップ、およびホームブロードバンド方式で発するという仮定に基づいています。その結果、アドレスがメールを送るか、またはある他のサービスを実行するのに使用されるのを防ぐのを試みます、そのために指定されたプロバイダーシステムを除いて。
Different techniques are used to identify systems with dynamic
addresses, including provider advertising of such addresses to
blacklist operators, heuristics that utilize certain address
ranges, and inspection of reverse-mapping domain names to see if
異なったテクニックはダイナミックなアドレスとシステムを同一視するのに使用されます、見るためにオペレータをブラックリストに載せるそのようなアドレスのプロバイダー広告、ある一定のアドレスの範囲を利用する発見的教授法、および逆マッピングドメイン名の点検を含んでいて
Klensin Best Current Practice [Page 5] RFC 4084 IP Service Terms May 2005
最も良い現在のKlensinの練習[5ページ]RFC4084IPサービス用語2005年5月
they contain telltale strings such as "dsl" or "dial". In some
cases, the absence of a reverse-mapping DNS address is taken as an
indication that the address is "dynamic". (Prohibition on
connections based on the absence of a reverse-mapping DNS record
was a technique developed for FTP servers many years ago; it was
found to have fairly high rates of failure, both prohibiting
legitimate connection attempts and failing to prevent illegitimate
ones). Service providers SHOULD describe what they are doing in
this area for both incoming and outgoing message traffic, and
users should be aware that, if an address is advertised as
"dynamic", it may be impossible to use it to send mail to an
arbitrary system even if Full Internet Connectivity is otherwise
provided.
それらは"dsl"か「ダイヤル」などの密告者のストリングを含んでいます。 いくつかの場合、逆マッピングDNSアドレスの欠如はアドレスが「ダイナミックである」という指示としてみなされます。 (逆マッピングDNS記録の欠如に基づく接続での禁止は何年も前にFTPサーバのために見いだされた技術でした; 高い率の失敗を公正に持っているのがわかりました、正統の接続試みを禁止して、違法なものを防がないで。) サービスプロバイダーSHOULDはそれらが両方の送受信のメッセージトラフィックのためにこの領域でしていることについて説明します、そして、別の方法でFullインターネットConnectivityを提供しても、ユーザはアドレスが「動力」として広告に掲載されるなら任意のシステムにメールを送るのにそれを使用するのが不可能であるかもしれないことを意識しているべきです。
o Non-public addresses and NATs.
o 非場内放送とNATs。
The NAT systems that are used to map between private and public
address spaces may support connections to distant mail systems for
outbound and inbound mail, but terms of service often prohibit the
use of systems not supplied by the connectivity provider and
prohibit the operation of "servers" (typically not precisely
defined) on the client connection.
個人的で公共のアドレスの間で空間を写像するのに使用されるNATシステムが外国行きの、そして、本国行きのメールの遠方のメールシステムに接続をサポートするかもしれませんが、サービスの諸条件は、しばしば接続性プロバイダーによって供給されなかったシステムの使用を禁止して、クライアント接続の「サーバ」(正確に通常定義されない)の操作を禁止します。
o Outbound port filtering from the provider.
o プロバイダーからの外国行きのポートフィルタリング。
Another common technique involves blocking connections to servers
outside the provider's control by blocking TCP "ports" that are
commonly used for messaging functions. Different providers have
different theories about this. Some prohibit their customers from
accessing external SMTP servers for message submission, but they
permit the use of the mail submission protocol ([3]) with sender
authentication. Others try to block all outgoing messaging-
related protocols, including remote mail retrieval protocols;
however, this is less common with public-address services than
those that are dependent on private addresses and NATs. If this
type of filtering is present, especially with "Client only, public
address" and "Full Internet Connectivity" services, the provider
MUST indicate that fact (see also Section 4).
別の一般的なテクニックは、メッセージング機能に一般的に使用されるTCP「ポート」を妨げることによってプロバイダーのコントロールの外におけるサーバに接続を妨げることを伴います。 異なったプロバイダーには、これに関する異なった理論があります。 或るものはメッセージ提案のための外部のSMTPサーバーにアクセスするのから彼らの顧客を禁じますが、それらは送付者認証によるメール服従プロトコル([3])の使用を可能にします。 リモートメール検索プロトコルを含んでいて、他のものはすべての外向的なメッセージング関連するプロトコルを妨げようとします。 しかしながら、これはプライベート・アドレスに依存するものとNATsほど場内放送サービスについて一般的ではありません。 このタイプのフィルタリングが存在しているなら、特に「クライアントの唯一の、そして、公共のアドレス」と「完全なインターネットの接続性」サービスで、プロバイダーはその事実を示さなければなりません(また、セクション4を見てください)。
Still others may divert (reroute) outbound email traffic to their
own servers, on the theory that this eliminates the need for
reconfiguring portable machines as they connect from a different
network location. Again, such diversion MUST be disclosed,
especially since it can have significant security and privacy
implications.
それでも、他のものは外国行きのメールトラフィックをそれら自身のサーバに紛らすかもしれません(コースを変更します)、これが異なったネットワークの位置から接続するので携帯用のマシンを再構成する必要性を排除するという理論で。 一方、特に重要なセキュリティとプライバシー意味を持つことができるので、そのような転換を明らかにしなければなりません。
Klensin Best Current Practice [Page 6] RFC 4084 IP Service Terms May 2005
最も良い現在のKlensinの練習[6ページ]RFC4084IPサービス用語2005年5月
More generally, filters that block some or all mail being sent to
(or submitted to) remote systems (other than via provider-
supported servers), or that attempt to divert that traffic to
their own servers, are, as discussed above, becoming common and
SHOULD be disclosed.
より一般に、(または、提出します)リモートシステム(サーバであるとサポートされたプロバイダーを除いた)、またはそのトラフィックをそれら自身のサーバに紛らすその試みにいくつかを妨げるフィルタかすべてのメールを送って、上で議論するようにあって、コモンとSHOULDになって、明らかにされてください。
4. Additional Terminology
4. 追加用語
These additional terms, while not as basic to understanding a service offering as the ones identified above, are listed as additional information that a service provider might choose to provide to complement those general definitions. A potential customer might use those that are relevant to construct a list of specific questions to ask, for example.
これらの追加用語はサービス提供を理解しているのに上で特定されたものほど基本的でない間、サービスプロバイダーが、それらの一般的な定義の補足となるように提供するのを選ぶかもしれないという追加情報としてリストアップされています。 見込み客は例えば尋ねるために具体的な質問のリストを構成するために関連しているものを使用するかもしれません。
o Version support.
o バージョンサポート。
Does the service include IPv4 support only, both IPv4 and IPv6
support, or IPv6 support only?
サービスはIPv4とIPv6の両方がサポートするだけであるIPv4サポート、またはIPv6サポートだけを含んでいますか?
o Authentication support.
o 認証サポート。
Which technical mechanism(s) are used by the service to establish
and possibly authenticate connections? Examples might include
unauthenticated DHCP, PPP, RADIUS, or HTTP interception.
どの技術的機構が、確立するサービスで使用されて、ことによると接続を認証しますか? 例はunauthenticated DHCP、PPP、RADIUS、またはHTTP妨害を含むかもしれません。
o VPNs and Tunnels.
o VPNsとTunnels。
Is IPSec blocked or permitted? Are other tunneling techniques at
the IP layer or below, such as L2TP, permitted? Is there any
attempt to block applications-layer tunnel mechanisms such as SSH?
IPSecは妨げられますか、受入れられますか? L2TPなどのように、IP層における以下の他のトンネリングのテクニックは受入れられますか? 何かSSHなどのアプリケーション層のトンネルメカニズムを妨げる試みがありますか?
o Multicast support
o マルチキャストサポート
Does the user machine have access to multicast packets and
services?
ユーザマシンはマルチキャストパケットとサービスに近づく手段を持っていますか?
o DNS support.
o DNSサポート。
Are users required to utilize DNS servers provided by the service
provider, or are DNS queries permitted to reach arbitrary servers?
ユーザがサービスプロバイダーによって提供されたDNSサーバを利用しなければならない、さもなければ、DNS質問が任意のサーバに達することが許可されていますか?
o IP-related services.
o IP関連のサービス。
Are ICMP messages to and from end user sites generally blocked or
permitted? Are specific functions such as ping and traceroute
blocked and, if so, at what point in the network?
サイトとエンドユーザサイトからのICMPメッセージは、一般に、妨げられますか、受入れられますか? ピングやトレースルートなどの具体的な機能は妨げられます、そして、そうだとすれば、ネットワークで何を指してくれますか?
Klensin Best Current Practice [Page 7] RFC 4084 IP Service Terms May 2005
最も良い現在のKlensinの練習[7ページ]RFC4084IPサービス用語2005年5月
o Roaming support.
o サポートに移動します。
Does the service intentionally include support for IP roaming and,
if so, how is this defined? For "broadband" connections, is some
dialup arrangement provided for either backup or customer travel?
If present, does that arrangement have full access to mailboxes,
etc.
サービスは故意にIPローミングのサポートを含んでいます、そして、そうだとすれば、これはどのように定義されますか? 「広帯域」の接続のために、備えられた何らかのダイアルアップアレンジメントは、バックアップかそれとも顧客旅行のどちらかですか? 存在しているなら、そのアレンジメントはメールボックスなどに完全に近づく手段を持っています。
o Applications services provided.
o アプリケーションサービスは提供されました。
Are email services and/or Web hosting provided as part of the
service, and on what basis? An email services listing should
identify whether POP3, IMAP4, or Web access are provided and in
what combinations, and what types of authentication and privacy
services are supported or required for each.
メールサービス、そして/または、ウェブ接待は、サービスの一部を提供して、どんなベースでそうしますか? メールサービスリストはそれぞれのためにどんな組み合わせ、およびどんなタイプの認証とプライバシーにサービスをPOP3、IMAP4、またはウェブアクセスを提供するかどうかと、サポートするか、または必要とするかを特定するはずです。
o Use and Blocking of Outbound Applications Services.
o 外国行きのアプリケーションサービスを使用して、妨げてください。
Does the service block use of SMTP or mail submission to other
than its own servers or intercept such submissions and route them
to its servers? Do its servers restrict the user to use of its
domain names on outbound email? (For email specifically, also see
Section 3 above.) Is the FTP PASV command supported or blocked?
Are blocks or intercepts imposed on other file sharing or file
transfer mechanisms, on conferencing applications, or on private
applications services?
サービスは、サーバに自分自身のを除いたサーバへのSMTPかメール提案の使用を妨げますか、そのような差出を妨害して、それらを発送しますか? サーバはユーザを外国行きのメールにおけるドメイン名の使用に制限しますか? (また、メールに関して、明確に、セクション3が上であることを見てください。) FTP PASVコマンドは、サポートされますか、妨げられますか? ブロックかインタセプトが会議アプリケーション、または個人的なアプリケーションサービスのときに他のファイル共有かファイル転送メカニズムに課されますか?
More generally, the provider should identify any actions of the
service to block, restrict, or alter the destination of, the
outbound use (i.e., the use of services not supplied by the
provider or on the provider's network) of applications services.
より一般に、プロバイダーはどんな目的地を妨げるか、制限するか、または変更するサービスの動作も特定するべきであり、アプリケーションの外国行きの使用(すなわち、プロバイダーの近く、または、プロバイダーのネットワークの上で供給されなかったサービスの使用)はサービスです。
o Blocking of Inbound Applications Services.
o 本国行きのアプリケーションサービスのブロッキング。
In addition to issues raised by dynamic or private address space
(when present), does the service take any other measures that
specifically restrict the connections that can be made to
equipment operated by the customer? Specifically, are inbound
SMTP, HTTP or HTTPS, FTP, or various peer-to-peer or other
connections (possibly including applications not specifically
recognized by the provider) prohibited and, if so, which ones?
ダイナミックであるか個人的なアドレスのスペース(存在しているとき)によって提起された問題に加えて、サービスは明確に、顧客によって操作された設備にすることができる接続を制限する他の対策を実施しますか? 明確に、本国行きのSMTP、HTTP、HTTPS、FTP、または様々なピアツーピアの、または、他の接続(ことによると、プロバイダーによって明確に認識されなかったアプリケーションを含んでいる)が禁止されています、そして、そうだとすれば、どれですか?
o Application Content Filtering.
o アプリケーションコンテントのフィルタリング。
The service should declare whether it provides filtering or
protection against worms or denial of service attacks against its
customers, virus and spam filtering for its mail services (if
それがフィルタリングかワームに対する保護かメールのためにサービスをフィルターにかける顧客、ウイルス、およびスパムに対するサービス不能攻撃を提供するか否かに関係なく、サービスが宣言するべきである、(
Klensin Best Current Practice [Page 8] RFC 4084 IP Service Terms May 2005
最も良い現在のKlensinの練習[8ページ]RFC4084IPサービス用語2005年5月
any), non-discretionary or "parental control" filtering of
content, and so on.
いずれも)、内容などの非任意か「ペアレンタル・コントロール」フィルタリング。
o Wiretapping and interception.
o 盗聴と妨害。
The service SHOULD indicate whether traffic passing through it is
subject to lawful intercept, and whether the provider will make a
proactive attempt to inform the user of such an intercept when
such notice is legal. Analogous questions can be asked for
traffic data that is stored for possible use by law enforcement.
サービスSHOULDは、それを通り抜けるトラフィックは合法的なインタセプトを受けることがあるかどうかと、プロバイダーがそのような通知がいつ法的であるかをそのようなインタセプトのユーザに知らせる先を見越す試みをするかどうかを示します。 活用可能性のために法施行で保存されるトラフィックデータは類似の質問に求めることができます。
5. Security Considerations
5. セキュリティ問題
This document is about terminology, not protocols, so it does not raise any particular security issues. However, if the type of terminology that is proposed is widely adopted, it may become easier to identify security-related expectations of particular hosts, LANs, and types of connections.
このドキュメントがプロトコルではなく、用語に関するものであるので、それは少しの特定の安全保障問題も提起しません。 しかしながら、提案される用語のタイプが広く採用されるなら、特定のホスト、LAN、およびタイプの接続へのセキュリティ関連の期待を特定するのは、より簡単になるかもしれません。
6. Acknowledgements
6. 承認
This document was inspired by an email conversation with Vernon Schryver, Paul Vixie, and Nathaniel Bornstein. While there have been proposals to produce such definitions for many years, that conversation convinced the author that it was finally time to put a strawman on the table to see if the IETF could actually carry it forward. Harald Alvestrand, Brian Carpenter, George Michaelson, Vernon Schryver, and others made several suggestions on the initial draft that resulted in clarifications to the second one and Stephane Bortzmeyer, Brian Carpenter, Tony Finch, Susan Harris, David Kessens, Pekka Savola, and Vernon Schryver made very useful suggestions that were incorporated into subsequent versions. Susan Harris also gave the penultimate version an exceptionally careful reading, which is greatly appreciated, as are editorial suggestions by the RFC Editor.
このドキュメントはヴァーノンSchryver、ポールVixie、およびナザニエルBornsteinとのメールの会話で奮い立たせられました。 何年間もそのような定義を起こすという提案がありましたが、その会話は、最終的にIETFが実際にそれを進展させることができるかどうか確認するためにもうわら人形をテーブルに置くべき時間であると作者に納得させました。 ハラルドAlvestrand、ブライアンCarpenter、ジョージMichaelson、ヴァーノンSchryver、および他のものは2番目のものへの明確化をもたらした初期の草稿のいくつかの提案をしました、そして、ステファーヌBortzmeyer、ブライアンCarpenter、トニーFinch、スーザン・ハリス、デヴィッドKessens、ペッカSavola、およびヴァーノンSchryverは法人組織である非常に役に立つ提案をその後のバージョンに作りかえました。 また、スーザン・ハリスは例外的に慎重な読みを終わりから二番目のバージョンに与えました、RFC Editorによる編集の勧めのように。(読みに大いに感謝します)。
7. Informative References
7. 有益な参照
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[2]SrisureshとP.とM.Holdrege、「IPはアドレス変換機構(NAT)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
[3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
December 1998.
[3]GellensとR.とJ.Klensin、「メッセージ提案」、RFC2476、1998年12月。
Klensin Best Current Practice [Page 9] RFC 4084 IP Service Terms May 2005
最も良い現在のKlensinの練習[9ページ]RFC4084IPサービス用語2005年5月
Author's Address
作者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
Ave、ジョンC Klensin1770マサチューセッツ#322MA02140ケンブリッジ(米国)
Phone: +1 617 491 5735 EMail: john-ietf@jck.com
以下に電話をしてください。 +1 5735年の617 491メール: john-ietf@jck.com
Klensin Best Current Practice [Page 10] RFC 4084 IP Service Terms May 2005
最も良い現在のKlensinの練習[10ページ]RFC4084IPサービス用語2005年5月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Klensin Best Current Practice [Page 11]
Klensinの最も良い現在の習慣[11ページ]
一覧
スポンサーリンク
