RFC3696 日本語訳
3696 Application Techniques for Checking and Transformation of Names.J. Klensin. February 2004. (Format: TXT=39238 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Klensin Request for Comments: 3696 February 2004 Category: Informational
Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3696 2004年2月のカテゴリ: 情報
Application Techniques for Checking and Transformation of Names
名前の照合と変化のためのアプリケーションのテクニック
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). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
Many Internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information. The introduction of new top-level domains, especially non-country-code ones, has exposed flaws in some of the methods used by these applications. These flaws make it more difficult, or impossible, for users of the applications to access the full Internet. This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves. This document draws summaries of the applicable rules together in one place and supplies references to the actual standards.
多くのインターネットアプリケーションが、部分的な情報から最上位のドメイン(または、他のドメイン名ラベル)を推論するように設計されています。 新しい最上位のドメインの導入(特に非国名略号もの)で、これらのアプリケーションで方法のいくつかによる露出している欠点を使用します。 これらの欠点で、アプリケーションが完全なインターネットにアクセスするのが難しいか、またはユーザにとって不可能になります。 このメモは、使用されたテクニックのいくつかについて議論して、ドメイン名環境が発展するのに従ってそれらの負の衝撃を最小にするための何らかの指導を与えます。 このドキュメントは、1つの場所で適切な規則の概要を接近させて、実際の規格に参照を供給します。
Klensin Informational [Page 1] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[1ページ]のRFC3696の照合と変化
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Restrictions on domain (DNS) names . . . . . . . . . . . . . . 3
3. Restrictions on email addresses . . . . . . . . . . . . . . . 5
4. URLs and URIs . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. URI syntax definitions and issues . . . . . . . . . . . 7
4.2. The HTTP URL . . . . . . . . . . . . . . . . . . . . . . 8
4.3. The MAILTO URL . . . . . . . . . . . . . . . . . . . . . 9
4.4. Guessing domain names in web contexts . . . . . . . . . 11
5. Implications of internationalization . . . . . . . . . . . . . 11
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 ドメイン(DNS)名. . . . . . . . . . . . . . 3 3における制限。 Eメールアドレス. . . . . . . . . . . . . . . 5 4における制限。 URLとURI. . . . . . . . . . . . . . . . . . . . . . . . 7 4.1。 URI構文定義と問題. . . . . . . . . . . 7 4.2。 HTTP URL. . . . . . . . . . . . . . . . . . . . . . 8 4.3。 MAILTO URL. . . . . . . . . . . . . . . . . . . . . 9 4.4。 ウェブ文脈. . . . . . . . . 11 5のドメイン名を推測します。 国際化. . . . . . . . . . . . . 11 6の含意。 概要. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 13 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1。 引用規格. . . . . . . . . . . . . . . . . . 14 9.2。 有益な参照. . . . . . . . . . . . . . . . . 15 10。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 15 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
Designers of user interfaces to Internet applications have often found it useful to examine user-provided values for validity before passing them to the Internet tools themselves. This type of test, most commonly involving syntax checks or application of other rules to domain names, email addresses, or "web addresses" (URLs or, occasionally, extended URI forms (see Section 4)) may enable better- quality diagnostics for the user than might be available from the protocol itself. Local validity tests on values are also thought to improve the efficiency of back-office processing programs and to reduce the load on the protocols themselves. Certainly, they are consistent with the well-established principle that it is better to detect errors as early as possible.
インターネットアプリケーションへのユーザインタフェースのデザイナーは、しばしばそれらをインターネット・ツール自体に通過する前に正当性がないかどうかユーザによって提供された値を調べるのが役に立つのがわかりました。 このタイプのテスト、最も一般的にドメイン名、Eメールアドレス、または「ウェブアドレス」(URLか時折拡張しているURIフォーム(セクション4を見る))に他の規則の構文チェックか適用にかかわると、ユーザには、プロトコル自体から利用可能であるかもしれないより良い上質の病気の特徴は可能にされるかもしれません。 また、バック・オフィス処理プログラムの効率を高めて、値のローカルの正当性テストがプロトコル自体で負荷を減少させると考えられます。 確かに、それらはできるだけ早く誤りを検出しているほうがよいという安定している原則と一致しています。
The tests must, however, be made correctly or at least safely. If criteria are applied that do not match the protocols, users will be inconvenienced, addresses and sites will effectively become inaccessible to some groups, and business and communications opportunities will be lost. Experience in recent years indicates that syntax tests are often performed incorrectly and that tests for top-level domain names are applied using obsolete lists and conventions. We assume that most of these incorrect tests are the result of the inability to conveniently locate exact definitions for the criteria to be applied. This document draws summaries of the applicable rules together in one place and supplies references to the
しかしながら、正しいか少なくとも安全にテストをしなければなりません。 評価基準が適用されているなら、それはプロトコルに合っていません、そして、ユーザは迷惑をかけられるでしょう、そして、事実上、アドレスとサイトは何らかのグループ、およびビジネスに近づきがたくなるでしょう、そして、コミュニケーションの機会は失われるでしょう。 経験は近年構文テストがしばしば不当に実行されて、最上位のドメイン名のためのテストが時代遅れのリストとコンベンションを使用することで適用されているのを示します。 私たちは、評価基準が適用されているためにこれらの不正確なテストの大部分が好都合なことに正確な定義の場所を見つけることができないことの結果であると思います。 このドキュメントは、1つの場所で適切な規則の概要を接近させて、参照を提供します。
Klensin Informational [Page 2] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[2ページ]のRFC3696の照合と変化
actual standards. It does not add anything to those standards; it merely draws the information together into a form that may be more accessible.
実際の規格。 それはそれらの規格に何も加えません。 それは、より理解できるかもしれないフォームに情報を単に接近させます。
Many experts on Internet protocols believe that tests and rules of these sorts should be avoided in applications and that the tests in the protocols and back-office systems should be relied on instead. Certainly implementations of the protocols cannot assume that the data passed to them will be valid. Unless the standards specify particular behavior, this document takes no position on whether or not the testing is desirable. It only identifies the correct tests to be made if tests are to be applied.
インターネットプロトコルの多くの専門家が、これらの種類のテストと規則がアプリケーションで避けられるべきであり、プロトコルとバック・オフィスシステムにおけるテストが代わりに依存されるべきであると信じています。 確かに、プロトコルの実現は、それらに通過されたデータが有効になると仮定できません。 規格が特定の振舞いを指定しないなら、このドキュメントはテストが望ましいかどうかの立場を全く取りません。 それはテストが適用されているだけことであるならされる正しいテストを特定します。
The sections that follow discuss domain names, email addresses, and URLs.
従うセクションはドメイン名、Eメールアドレス、およびURLについて論じます。
2. Restrictions on domain (DNS) names
2. ドメイン(DNS)名における制限
The authoritative definitions of the format and syntax of domain names appear in RFCs 1035 [RFC1035], 1123 [RFC1123], and 2181 [RFC2181].
ドメイン名の形式と構文の正式の定義はRFCs1035[RFC1035]、1123年[RFC1123]、および2181年[RFC2181]に現れます。
Any characters, or combination of bits (as octets), are permitted in DNS names. However, there is a preferred form that is required by most applications. This preferred form has been the only one permitted in the names of top-level domains, or TLDs. In general, it is also the only form permitted in most second-level names registered in TLDs, although some names that are normally not seen by users obey other rules. It derives from the original ARPANET rules for the naming of hosts (i.e., the "hostname" rule) and is perhaps better described as the "LDH rule", after the characters that it permits. The LDH rule, as updated, provides that the labels (words or strings separated by periods) that make up a domain name must consist of only the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen. No other symbols or punctuation characters are permitted, nor is blank space. If the hyphen is used, it is not permitted to appear at either the beginning or end of a label. There is an additional rule that essentially requires that top-level domain names not be all- numeric.
どんなキャラクタ、またはビットの組み合わせ(八重奏としての)もDNS名で受入れられます。 しかしながら、ほとんどのアプリケーションで必要である好まれた形があります。 この好まれた形は最上位のドメイン、またはTLDsという名前で受入れられた唯一無二です。 一般に、また、それはTLDsに登録されたほとんどの第2レベル名で受入れられた唯一のフォームです、通常、ユーザによって見られないいくつかの名前が他の規則に従いますが。 それは、オリジナルのアルパネットからホスト(すなわち、「ホスト名」規則)の命名のための規則を引き出して、恐らく「LDH規則」として記述されているほうがよいです、キャラクタのときにそれが可能にする後。 アップデートするLDH規則は、ドメイン名を作るラベル(周期的に分離されている単語かストリング)がASCII[ASCII]のアルファベットと数字、およびハイフンだけから成らなければならないのを前提とします。 どんな他のシンボルも句読文字も受入れられません、そして、空白はスペースではありません。 ハイフンが使用されているなら、ラベルの始めか端に現れることは許可されません。 最上位のドメイン名がオール数値でないことを本質的には必要とする付則があります。
When it is necessary to express labels with non-character octets, or to embed periods within labels, there is a mechanism for keying them in that utilizes an escape sequence. RFC 1035 [RFC1035] should be consulted if that mechanism is needed (most common applications, including email and the Web, will generally not permit those escaped strings). A special encoding is now available for non-ASCII characters, see the brief discussion in Section 5.
非キャラクタ八重奏でラベルを急送するか、またはラベルの中に期間を埋め込むために、メカニズムがあるのがいつそれでそれらを合わせるのに必要であるかがエスケープシーケンスを利用します。 そのメカニズムが必要であるなら(一般に、メールとウェブを含むほとんどの一般的なアプリケーションがそれらの逃げられたストリングを可能にしないでしょう)、RFC1035[RFC1035]に相談されるべきです。 特別なコード化は今、非ASCII文字に利用可能であり、セクション5で簡潔な議論を見てください。
Klensin Informational [Page 3] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[3ページ]のRFC3696の照合と変化
Most internet applications that reference other hosts or systems
assume they will be supplied with "fully-qualified" domain names,
i.e., ones that include all of the labels leading to the root,
including the TLD name. Those fully-qualified domain names are then
passed to either the domain name resolution protocol itself or to the
remote systems. Consequently, purported DNS names to be used in
applications and to locate resources generally must contain at least
one period (".") character. Those that do not are either invalid or
require the application to supply additional information. Of course,
this principle does not apply when the purpose of the application is
to process or query TLD names themselves. The DNS specification also
permits a trailing period to be used to denote the root, e.g.,
"a.b.c" and "a.b.c." are equivalent, but the latter is more explicit
and is required to be accepted by applications. This convention is
especially important when a TLD name is being referred to directly.
For example, while ".COM" has become the popular terminology for
referring to that top-level domain, "COM." would be strictly and
technically correct in talking about the DNS, since it shows that
"COM" is a top-level domain name.
参照他のホストかシステムが、それらが供給されると仮定するほとんどのインターネットアプリケーションがドメイン名に「完全に資格を与えました」、すなわち、根に通じるラベルのすべてを含んでいるもの、TLD名を含んでいて。 次に、それらの完全修飾ドメイン名はドメイン名解決プロトコル自体、または、リモートシステムに通過されます。その結果、一般に、リソースをアプリケーションで使用されて、場所を見つける主張されたDNS名が少なくとも1回の期間を含まなければならない、(「」、)、キャラクタ。 追加情報を提供するために無効でないか、またはアプリケーションを必要としないもの。 もちろん、アプリケーションの目的がTLD名自体について処理するか、または質問することであるときに、この原則は適用されません。 また、DNS仕様が、引きずっている期間が根を指示するために費やされることを許可して、例えば、「a.b.c」と「a.b.c.」が同等ですが、後者が、より明白であり、アプリケーションで受け入れるのに必要です。 TLD名が直接示されているとき、このコンベンションは特に重要です。 ".COM"はその最上位のドメイン、"COM"について言及するためのポピュラーな用語になりました。例えば、ゆったり過ごす、DNSに関して話すのにおいて厳密と技術的に正しいでしょう、"COM"が最上位のドメイン名であることを示すので。
There is a long history of applications moving beyond the "one or more periods" test in an attempt to verify that a valid TLD name is actually present. They have done this either by applying some heuristics to the form of the name or by consulting a local list of valid names. The historical heuristics are no longer effective. If one is to keep a local list, much more effort must be devoted to keeping it up-to-date than was the case several years ago.
アプリケーションが妥当なTLD名が実際に存在していることを確かめる試みにおける「より多くのある期間」のテストを超えて動く長い歴史があります。 彼らは、いくつかの発見的教授法を名前のフォームに適用するか、または妥当な名前のローカルのリストに相談することによって、これをしました。 歴史的な発見的教授法はもう効果的ではありません。 1つがローカルのリストを保つつもりであるなら、数年前のケースであったよりそれを最新に保つのにずっと多くの努力をささげなければなりません。
The heuristics were based on the observation that, since the DNS was first deployed, all top-level domain names were two, three, or four characters in length. All two-character names were associated with "country code" domains, with the specific labels (with a few early exceptions) drawn from the ISO list of codes for countries and similar entities [IS3166]. The three-letter names were "generic" TLDs, whose function was not country-specific, and there was exactly one four-letter TLD, the infrastructure domain "ARPA." [RFC1591]. However, these length-dependent rules were conventions, rather than anything on which the protocols depended.
発見的教授法はDNSが最初に配備されたので、すべての最上位のドメイン名が長さが2、3、または4つのキャラクタであったという観測に基づきました。 すべての2キャラクタの名前が「国名略号」ドメインに関連していました、国と同様の実体[IS3166]のためにコードのISOリストから得られた特定のラベル(いくつかの早めの例外がある)で。 3音名が機能が国の特有でなかった「一般的な」TLDsでした、そして、まさに、1 4文字のTLD、インフラストラクチャドメイン「アルパ」がありました。 [RFC1591。] しかしながら、これらの長さの依存する規則はプロトコルがよった何よりもむしろコンベンションでした。
Before the mid-1990s, lists of valid top-level domain names changed infrequently. New country codes were gradually, and then more rapidly, added as the Internet expanded, but the list of generic domains did not change at all between the establishment of the "INT." domain in 1988 and ICANN's allocation of new generic TLDs in 2000. Some application developers responded by assuming that any two-letter domain name could be valid as a TLD, but the list of generic TLDs was fixed and could be kept locally and tested. Several of these assumptions changed as ICANN started to allocate new top-level
1990年代の半ばの前に、妥当な最上位のドメイン名のリストはまれに変化しました。 新しい国名略号は徐々に、そして、次に、より急速にそうでした、インターネットが広がりましたが、一般ドメインのリストが2000年に"INT"の設立の間で新しい一般的なTLDsについて. 1988年のドメインとICANNの配分を全く変えなかったので加えられて。 どんな2文字のドメイン名もTLDとして有効であるかもしれないと仮定することによって何人かのアプリケーション開発者が応じましたが、一般的なTLDsのリストを修理して、局所的に保たれて、テストできました。 ICANNが新しいトップレベルを割り当て始めたとき変えられたこれらのいくつかの仮定
Klensin Informational [Page 4] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[4ページ]のRFC3696の照合と変化
domains: one two-letter domain that does not appear in the ISO 3166-1 table [ISO.3166.1988] was tentatively approved, and new domains were created with three, four, and even six letter codes.
ドメイン: ISO3166-1テーブルに現れない1つの2文字のドメイン、[ISO、.3166、.1988、]、試験的に承認されて、新しいドメインは3、4、および6つのレター・コードでさえ作成されました。
As of the first quarter of 2003, the list of valid, non-country, top-level domains was .AERO, .BIZ, .COM, .COOP, .EDU, .GOV, .INFO, .INT, .MIL, .MUSEUM, .NAME, .NET, .ORG, .PRO, and .ARPA. ICANN is expected to expand that list at regular intervals, so the list that appears here should not be used in testing. Instead, systems that filter by testing top-level domain names should regularly update their local tables of TLDs (both "generic" and country-code-related) by polling the list published by IANA [DomainList]. It is likely that the better strategy has now become to make the "at least one period" test, to verify LDH conformance (including verification that the apparent TLD name is not all-numeric), and then to use the DNS to determine domain name validity, rather than trying to maintain a local list of valid TLD names.
2003年の第1四半期の時点で、有効で、非国の最上位のドメインのリストは、.AEROと、.BIZと、.COMと、.COOPと、.EDUと、.GOVと、.INFOと、.INTと、.MILと、.MUSEUMと、.NAMEと、.NETと、.ORGと、.PROと、.ARPAでした。 ICANNが一定の間隔を置いてそのリストを広げると予想されるので、テストでここに現れるリストを使用するべきではありません。 代わりに、テストしている最上位のドメインで名前をフィルターにかけるシステムは定期的にIANA[DomainList]によって発表されたリストに投票するのによる(ともに「一般的で」国のコード関連)のTLDsの地元のテーブルをアップデートするはずです。 現在、より良い戦略は、「少なくとも1回の期間」のテストをするようにLDH順応(見かけのTLDが命名する検証を含むのは、オール数値でない)について確かめて、そして、妥当なTLD名のローカルのリストを維持しようとするよりむしろドメイン名の正当性を決定するのにDNSを使用するためになりそうでした。
A DNS label may be no more than 63 octets long. This is in the form actually stored; if a non-ASCII label is converted to encoded "punycode" form (see Section 5), the length of that form may restrict the number of actual characters (in the original character set) that can be accommodated. A complete, fully-qualified, domain name must not exceed 255 octets.
長い間、DNSラベルは63未満の八重奏であるかもしれません。 これは実際に格納された書式にあります。 非ASCIIラベルがコード化された"punycode"フォームに変換されるなら(セクション5を見てください)、そのフォームの長さは設備することができる実際のキャラクタ(オリジナルの文字の組の)の数を制限するかもしれません。 完全で、完全に適切なドメイン名は255の八重奏を超えてはいけません。
Some additional mechanisms for guessing correct domain names when incomplete information is provided have been developed for use with the web and are discussed in Section 4.4.
不完全情報を提供するとき正しいドメイン名を推測するためのいくつかの追加メカニズムについて、使用のためにウェブで開発されて、セクション4.4で議論します。
3. Restrictions on email addresses
3. Eメールアドレスにおける制限
Reference documents: RFC 2821 [RFC2821] and RFC 2822 [RFC2822]
参考書類: RFC2821[RFC2821]とRFC2822[RFC2822]
Contemporary email addresses consist of a "local part" separated from
a "domain part" (a fully-qualified domain name) by an at-sign ("@").
The syntax of the domain part corresponds to that in the previous
section. The concerns identified in that section about filtering and
lists of names apply to the domain names used in an email context as
well. The domain name can also be replaced by an IP address in
square brackets, but that form is strongly discouraged except for
testing and troubleshooting purposes.
現代のEメールアドレスはサインの("@")によって「ドメイン部分」(完全修飾ドメイン名)と切り離された「地方の部分」から成ります。 ドメイン部分の構文は前項でそれに対応しています。 名前についてフィルターにかけて、記載することに関するそのセクションで特定された関心はまた、メール文脈で使用されるドメイン名に適用されます。 また、ドメイン名を角括弧のIPアドレスに取り替えることができますが、目的をテストして、障害調査するのを除いて、そのフォームを強くがっかりさせます。
The local part may appear using the quoting conventions described below. The quoted forms are rarely used in practice, but are required for some legitimate purposes. Hence, they should not be rejected in filtering routines but, should instead be passed to the email system for evaluation by the destination host.
地方の部分は、コンベンションが以下で説明した引用を使用することで現れるかもしれません。 引用されたフォームが、実際にはめったに使用されませんが、いくつかの正当な目的に必要です。 したがって、ルーチンをフィルターにかける際にそれらを拒絶するべきではありませんが、代わりにあて先ホストによる評価のメールシステムに通るべきです。
Klensin Informational [Page 5] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[5ページ]のRFC3696の照合と変化
The exact rule is that any ASCII character, including control characters, may appear quoted, or in a quoted string. When quoting is needed, the backslash character is used to quote the following character. For example
正確な規則は制御文字を含むどんなASCII文字も引用されているのに現れるか、または引用文字列でそうするかもしれないということです。 引用が必要であるときに、バックスラッシュキャラクタは、以下のキャラクタを引用するのに使用されます。 例えば
Abc\@def@example.com
Abc\ @def@example.com
is a valid form of an email address. Blank spaces may also appear, as in
Eメールアドレスが有効なフォームがありますか? また、空白の空間は同じくらい中に現れるかもしれません。
Fred\ Bloggs@example.com
フレッド\ Bloggs@example.com
The backslash character may also be used to quote itself, e.g.,
また、バックスラッシュキャラクタは、例えばそれ自体を引用するのに使用されるかもしれません。
Joe.\\Blow@example.com
ジョー\\ Blow@example.com
In addition to quoting using the backslash character, conventional double-quote characters may be used to surround strings. For example
バックスラッシュキャラクタを使用する引用に加えて、従来の二重引用文字は、ストリングを囲むのに使用されるかもしれません。 例えば
"Abc@def"@example.com
" Abc@def "@example.com
"Fred Bloggs"@example.com
「フレッドBloggs」@example.com
are alternate forms of the first two examples above. These quoted forms are rarely recommended, and are uncommon in practice, but, as discussed above, must be supported by applications that are processing email addresses. In particular, the quoted forms often appear in the context of addresses associated with transitions from other systems and contexts; those transitional requirements do still arise and, since a system that accepts a user-provided email address cannot "know" whether that address is associated with a legacy system, the address forms must be accepted and passed into the email environment.
最初の2つの例が上に交互のフォームがありますか? これらをフォームがめったにお勧めでなく、実際には珍しいのを引用しますが、上で議論するように処理Eメールアドレスであるアプリケーションで支持しなければなりません。 特に、引用されたフォームはアドレスの文脈で他のシステムと文脈から変遷に関連しているようにしばしば見えます。 それらの過渡的な要件がまだ起こっていて、ユーザによって提供されたEメールアドレスを受け入れるシステムが、そのアドレスが遺産システムに関連しているかどうかを「知ることができない」ので、メール環境に呼びかけの形式を受け入れられて、通過しなければなりません。
Without quotes, local-parts may consist of any combination of alphabetic characters, digits, or any of the special characters
引用文がなければ、地方の部分は特殊文字の英字のどんな組み合わせ、ケタ、またはいずれからも成るかもしれません。
! # $ % & ' * + - / = ? ^ _ ` . { | } ~
! # $ % & ' * + - / = ? ^ _ ` . { | } ~
period (".") may also appear, but may not be used to start or end the
local part, nor may two or more consecutive periods appear. Stated
differently, any ASCII graphic (printing) character other than the
at-sign ("@"), backslash, double quote, comma, or square brackets may
appear without quoting. If any of that list of excluded characters
are to appear, they must be quoted. Forms such as
以上、(「」、)、また、現れるかもしれませんが、始まるか、または地方の部分を終わらせるために費やされないかもしれなくて、また2回以上の連続した期間が現れませんように。 異なって述べられていて、サインの("@")、バックスラッシュ、二重引用文、コンマ、または角括弧以外のどんなASCIIのグラフィック(印刷)キャラクタも引用なしで現れるかもしれません。 除かれたキャラクタのそのリストのどれかが現れることであるなら、彼らを引用しなければなりません。 形成します。
user+mailbox@example.com
ユーザ+ mailbox@example.com
Klensin Informational [Page 6] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[6ページ]のRFC3696の照合と変化
customer/department=shipping@example.com
顧客/部= shipping@example.com
$A12345@example.com
$A12345@example.com
!def!xyz%abc@example.com
!def!xyz%abc@example.com
_somename@example.com
_somename@example.com
are valid and are seen fairly regularly, but any of the characters
listed above are permitted. In the context of local parts,
apostrophe ("'") and acute accent ("`") are ordinary characters, not
quoting characters. Some of the characters listed above are used in
conventions about routing or other types of special handling by some
receiving hosts. But, since there is no way to know whether the
remote host is using those conventions or just treating these
characters as normal text, sending programs (and programs evaluating
address validity) must simply accept the strings and pass them on.
有効であり、公正に見られて、キャラクタでは、定期的に、しかし、いくらか、記載された上が受入れられるということです。 地方の部分、アポストロフィの文脈、(「'、「)、鋭アクセント、(「'、「)、キャラクタを引用するのではなく、普通のキャラクタがそうである、」、' 上に記載されたキャラクタの何人かがルーティングか他のタイプの特別な取り扱いに関してコンベンションに何人かの受信ホストによって使用されます。 しかし、リモートホストがそれらのコンベンションを使用するか、またはただ正常なテキストとしてこれらのキャラクタを扱っているかを知る方法が全くないので、送付プログラム(そして、アドレス妥当性を評価するプログラム)は、単にストリングを受け入れて、それらを伝えなければなりません。
In addition to restrictions on syntax, there is a length limit on email addresses. That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters. Systems that handle email should be prepared to process addresses which are that long, even though they are rarely encountered.
構文における制限に加えて、長さの限界がEメールアドレスにあります。 その限界は、「地方の部分」("@"の前の)の最大64のキャラクタ(八重奏)と320のキャラクタの全長のためのドメイン部分("@"の後の)の最大255のキャラクタ(八重奏)です。 メールを扱うシステムはめったに遭遇していませんが、そんなに長いアドレスを処理するように準備されるべきです。
4. URLs and URIs
4. URLとURI
4.1. URI syntax definitions and issues
4.1. URI構文定義と問題
The syntax for URLs (Uniform Resource Locators) is specified in
[RFC1738]. The syntax for the more general "URI" (Uniform Resource
Identifier) is specified in [RFC2396]. The URI syntax is extremely
general, with considerable variations permitted according to the type
of "scheme" (e.g., "http", "ftp", "mailto") that is being used.
While it is possible to use the general syntax rules of RFC 2396 to
perform syntax checks, they are general enough --essentially only
specifying the separation of the scheme name and "scheme specific
part" with a colon (":") and excluding some characters that must be
escaped if used-- to provide little significant filtering or
validation power.
URL(Uniform Resource Locator)のための構文は[RFC1738]で指定されます。 より一般的な「URI」(Uniform Resource Identifier)のための構文は[RFC2396]で指定されます。 URI構文は非常に一般的です、使用されている「計画」(例えば、"http"、"ftp""mailto")のタイプに応じてかなりの変化が受入れられている状態で。 構文チェックを実行するのにRFC2396の一般的なシンタックス・ルールを使用するのが可能である間、それらが本質的には計画名の分離を指定するだけであって、十分一般的であり、コロンで「特定の部分を計画する」、(「:」、)、何人かのキャラクタを除いて、使用されるなら、それから逃げなければなりません--小さい重要なフィルタリングか合法化権限を提供するために。
The following characters are reserved in many URIs -- they must be used for either their URI-intended purpose or must be encoded. Some particular schemes may either broaden or relax these restrictions (see the following sections for URLs applicable to "web pages" and electronic mail), or apply them only to particular URI component parts.
以下のキャラクタは多くのURIで予約されます--それらをそれらのURI本来の目的に使用しなければならないか、またはコード化しなければなりません。 いくつかの特定の計画が、これらの規制(「ウェブページ」と電子メールに適切なURLに関して以下のセクションを見る)を広くするか、緩和する、または特定のURIコンポーネント部分だけにそれらを当てるかもしれません。
Klensin Informational [Page 7] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[7ページ]のRFC3696の照合と変化
; / ? : @ & = + $ , ?
; / ? : @ & = + $ , ?
In addition, control characters, the space character, the double-
quote (") character, and the following special characters
添加、制御文字、間隔文字、二重引用文、(「)、キャラクタ、および以下の特殊文字、」
< > # %
<># %
are generally forbidden and must either be avoided or escaped, as discussed below.
以下で議論するように一般に、禁じられて、避けられなければならないか、または逃げなければなりません。
The colon after the scheme name, and the percent sign used to escape characters, are specifically reserved for those purposes, although ":" may also be used elsewhere in some schemes.
「計画名の後のコロン、および拡張文字に使用されるパーセント記号がそれらの目的のために明確に予約される、」、:、」 また、いくつかの計画におけるほかの場所で使用されるかもしれません。
When it is necessary to encode these, or other, characters, the
method used is to replace it with a percent-sign ("%") followed by
two hexidecimal digits representing its octet value. See section
2.4.1 of [RFC2396] for an exact definition. Unless it is used as a
delimiter of the URI scheme itself, any character may optionally be
encoded this way; systems that are testing URI syntax should be
prepared for these encodings to appear in any component of the URI
except the scheme name itself.
八重奏値を表す2hexidecimalケタに応じて、それをこれら、キャラクタ、何らかの、使用される方法がことである取り替えるのがいつパーセント記号(「%」)によってエンコードに必要であるかをいうことになりました。 正確な定義に関して.1セクション2.4[RFC2396]を見てください。 それがURI計画自体のデリミタとして使用されない場合、どんなキャラクタもこのように任意にコード化されるかもしれません。 URI構文をテストしているシステムは計画名自体以外のURIのあらゆるコンポーネントにこれらのencodingsを現れさせるように準備されるべきです。
A "generic URI" syntax is specified and is more restrictive, but using it to test URI strings requires that one know whether or not the particular scheme in use obeys that syntax. Consequently, applications that intend to check or validate URIs should normally identify the scheme name and then apply scheme-specific tests. The rules for two of those -- HTTP [RFC1738] and MAILTO [RFC2368] URLs -- are discussed below, but the author of an application which intends to make very precise checks, or to reject particular syntax rather than just warning the user, should consult the relevant scheme- definition documents for precise syntax and relationships.
「一般的なURI」構文は、指定されて、より制限していますが、URIストリングをテストするのにそれを使用するのは、人が、使用中の特定の計画がその構文に従うかどうかを知っているのを必要とします。 その結果、URIをチェックするつもりであるか、または有効にするつもりであるアプリケーションは、通常、計画名を特定して、次に、計画特有のテストを当てはまるべきです。 以下でそれらの2の規則(HTTP[RFC1738]とMAILTO[RFC2368]URL)について議論しますが、非常に正確なチェックをするつもりであるか、またはただユーザに警告するよりむしろ特定の構文を拒絶するつもりであるアプリケーションの作者は正確な構文と関係のための関連計画定義ドキュメントを参照するべきです。
4.2. The HTTP URL
4.2. HTTP URL
Absolute HTTP URLs consist of the scheme name, a host name (expressed
as a domain name or IP address), and optional port number, and then,
optionally, a path, a search part, and a fragment identifier. These
are separated, respectively, by a colon and the two slashes that
precede the host name, a colon, a slash, a question mark, and a hash
mark ("#"). So we have
絶対HTTP URLは計画名、ホスト名(ドメイン名かIPアドレスとして、言い表される)、および任意のポートナンバーから成ります、そして、経路でありそして任意に、検索は離れています、そして、aは識別子を断片化します。 これらはホスト名、コロン、スラッシュ、疑問符、および年功袖章(「#」)に先行するコロンと2つのスラッシュによってそれぞれ切り離されます。 私たちがそうして
http://host:port/path?search#fragment
http://host:port/path?search#fragment
http://host/path/
http://host/path/
http://host/path#fragment
http://host/path#fragment
Klensin Informational [Page 8] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[8ページ]のRFC3696の照合と変化
http://host/path?search
http://host/path?search
http://host
http://host
and other variations on that form. There is also a "relative" form, but it almost never appears in text that a user might, e.g., enter into a form. See [RFC2616] for details.
そして、それの他の変化は形成されます。 また、「相対的な」フォームがありますが、テキストにほとんどユーザがそうするかもしれないと載らないで、例えば、フォームに入ってください。 詳細に関して[RFC2616]を見てください。
The characters
キャラクタ
/ ; ?
/ ; ?
are reserved within the path and search parts and must be encoded; the first of these may be used unencoded, and is often used within the path, to designate hierarchy.
経路と検索の部品の中で予約されて、コード化しなければなりません。 これらの1番目が使用されるかもしれない、暗号化されていなさ、階層構造を指定するのに経路の中でしばしば使用されます。
4.3. The MAILTO URL
4.3. MAILTO URL
MAILTO is a URL type whose content is an email address. It can be used to encode any of the email address formats discussed in Section 3 above. It can also support multiple addresses and the inclusion of headers (e.g., Subject lines) within the body of the URL. MAILTO is authoritatively defined in RFC 2368 [RFC2368]; anyone expecting to accept and test multiple addresses or mail header or body formats should consult that document carefully.
MAILTOは内容がEメールアドレスであるURLタイプです。 上のセクション3で議論したEメールアドレス形式のどれかをコード化するのにそれを使用できます。 また、それはURLのボディーの中でヘッダー(例えば、Subject線)の複数のアドレスと包含をサポートできます。 MAILTOはRFC2368[RFC2368]で厳然と定義されます。 複数のアドレス、メールヘッダまたはボディー形式を受け入れて、テストすると予想するだれでも、慎重にそのドキュメントを参照するべきです。
In accepting text for, or validating, a MAILTO URL, it is important to note that, while it can be used to encode any valid email address, it is not sufficient to copy an email address into a MAILTO URL since email addresses may include a number of characters that are invalid in, or have reserved uses for, URLs. Those characters must be encoded, as outlined in Section 4.1 above, when the addresses are mapped into the URL form. Conversely, addresses in MAILTO URLs cannot, in general, be copied directly into email contexts, since few email programs will reverse the decodings (and doing so might be interpreted as a protocol violation).
中でテキストを受け入れる、有効にする、a MAILTO URL、Eメールアドレスには、URLのために多くの無効のキャラクタを含んでいるか、または予約された用途があるかもしれないので、どんな有効なEメールアドレスもコード化するのにそれを使用できますが、MAILTO URLにEメールアドレスをコピーするのが十分でないことに注意するのは重要です。 アドレスがURLフォームに写像されるとき、上のセクション4.1に概説されているようにそれらのキャラクタをコード化しなければなりません。 逆に、一般に、直接メール文脈にMAILTO URLのアドレスをコピーできません、わずかなメールプログラムしか逆符号化を逆にしないので(そうするのはプロトコル違反として解釈されるかもしれません)。
The following characters may appear in MAILTO URLs only with the specific defined meanings given. If they appear in an email address (i.e., for some other purpose), they must be encoded:
以下のキャラクタはMAILTO URLに特定の定義された意味だけを与えていて現れるかもしれません。 彼らがEメールアドレス(すなわち、ある他の目的のための)に現れるなら、それらをコード化しなければなりません:
: The colon in "mailto:"
: コロンは中で「以下をmailtoします」。
< > # " % { } | \ ^ ~ `
<># " % { } | \ ^ ~ `
These characters are "unsafe" in any URL, and must always be
encoded.
これらのキャラクタをどんなURLでも「危険であり」、いつもコード化しなければなりません。
Klensin Informational [Page 9] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[9ページ]のRFC3696の照合と変化
The following characters must also be encoded if they appear in a MAILTO URL
また、彼らがMAILTO URLに現れるなら、以下のキャラクタをコード化しなければなりません。
? & =
Used to delimit headers and their values when these are encoded
into URLs.
これらがURLにコード化されるとき、ヘッダーと彼らの値を区切るのに使用される=。
Some examples may be helpful:
いくつかの例が有用であるかもしれません:
+-------------------------+-----------------------------+-----------+ | Email address | MAILTO URL | Notes | +-------------------------+-----------------------------+-----------+ | Joe@example.com | mailto:joe@example.com | 1 | | | | | | user+mailbox@example | mailto: | 2 | | .com | user%2Bmailbox@example | | | | .com | | | | | | | customer/department= | mailto:customer%2F | 3 | | shipping@example.com | department=shipping@example | | | | .com | | | | | | | $A12345@example.com | mailto:$A12345@example | 4 | | | .com | | | | | | | !def!xyz%abc@example | mailto:!def!xyz%25abc | 5 | | .com | @example.com | | | | | | | _somename@example.com | mailto:_somename@example | 4 | | | .com | | +-------------------------+-----------------------------+-----------+
+-------------------------+-----------------------------+-----------+ | Eメールアドレス| MAILTO URL| 注意| +-------------------------+-----------------------------+-----------+ | Joe@example.com | mailto: joe@example.com | 1 | | | | | | ユーザ+ mailbox@example | mailto: | 2 | | .com| user%2Bmailbox@example | | | | .com| | | | | | | 顧客/部の=| mailto: 顧客%2F| 3 | | shipping@example.com | 部=の shipping@example | | | | .com| | | | | | | $A12345@example.com | mailto: $A12345@example | 4 | | | .com| | | | | | | !def!xyz%abc@example | mailto: クールで!、xyz%25abc| 5 | | .com| @example.com| | | | | | | _ somename@example.com | mailto: _somename@example | 4 | | | .com| | +-------------------------+-----------------------------+-----------+
Table 1
テーブル1
Notes on Table
テーブルでの注意
1. No characters appear in the email address that require escaping,
so the body of the MAILTO URL is identical to the email address.
1. どんなキャラクタも、Eメールアドレスに逃げるのを必要であってくださいのでMAILTO URLのボディーがEメールアドレスと同じであることを現れさせません。
2. There is actually some uncertainty as to whether or not the "+"
characters requires escaping in MAILTO URLs (the standards are
not precisely clear). But, since any character in the address
specification may optionally be encoded, it is probably safer to
encode it.
2. 「+」キャラクタが、MAILTO URLで逃げるのを必要とするかどうかに関して(規格は正確に明確ではありません)実際に何らかの不確実性があります。 しかし、アドレス指定によるどんなキャラクタも任意にコード化されるかもしれないので、それをコード化するのはたぶんより安全です。
3. The "/" character is generally reserved in URLs, and must be
encoded as %2F.
3. /、」 キャラクタを一般に、URLで予約されて、%として2Fコード化しなければなりません。
Klensin Informational [Page 10] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[10ページ]のRFC3696の照合と変化
4. Neither the "$" nor the "_" character are given any special
interpretation in MAILTO URLs, so need not be encoded.
4. どちらも「$」か"_"キャラクタが、MAILTO URLにおけるどんな特別な解釈もするので、コード化される必要はありません。
5. While the "!" character has no special interpretation, the "%"
character is used to introduce encoded sequences and hence it
must always be encoded.
5. “!"キャラクタにはどんな特別な解釈もない間、「%」キャラクタはコード化された系列を紹介するのに使用されます、そして、したがって、いつもそれをコード化しなければなりません。
4.4. Guessing domain names in web contexts
4.4. ウェブ文脈のドメイン名を推測します。
Several web browsers have adopted a practice that permits an incomplete domain name to be used as input instead of a complete URL. This has, for example, permitted users to type "microsoft" and have the browser interpret the input as "http://www.microsoft.com/". Other browser versions have gone even further, trying to build DNS names up through a series of heuristics, testing each variation in turn to see if it appears in the DNS, and accepting the first one found as the intended domain name. Still, others automatically invoke search engines if no period appears or if the reference fails. If any of these approaches are to be used, it is often critical that the browser recognize the complete list of TLDs. If an incomplete list is used, complete domain names may not be recognized as such and the system may try to turn them into completely different names. For example, "example.aero" is a fully-qualified name, since "AERO." is a TLD name. But, if the system doesn't recognize "AERO" as a TLD name, it is likely to try to look up "example.aero.com" and "www.example.aero.com" (and then fail or find the wrong host), rather than simply looking up the user-supplied name.
数個のウェブブラウザが完全なURLの代わりに入力されるように不完全なドメイン名が使用されることを許可する習慣を採用しました。 例えば、これは、ユーザが" http://www.microsoft.com/ "として"microsoft"をタイプして、ブラウザに入力を解釈させることを許可しました。 他のブラウザバージョンはさらにさえ行きました、一連の発見的教授法でDNS名を確立しようとして、それがDNSに現れるかどうかを見るために順番に各変化をテストして、1つが意図しているドメイン名として見つけた1番目を受け入れて。 それでも、期間が全く現れないか、または参照が失敗するなら、他のものは自動的にサーチエンジンを呼び出します。 これらのアプローチのどれかが使用されていることであるなら、ブラウザがTLDsに関する全リストを認めるのは、しばしば批判的です。 不完全なリストが使用されているなら、そのようなものとシステムがそれらを完全に異なった名前に変えようとするとき、完全なドメイン名は認識されないかもしれません。 例えば、「航空」であるので、"example.aero"は完全に修飾された名前です。TLDは名前ですか? しかし、システムが、TLD名として「航空」であり、それが"example.aero.com"を見上げようとしそうであると認めないか、そして、単に見るよりむしろ"www.example.aero.com"(次に、間違ったホストを失敗するか、または見つける)はユーザによって供給された名前を上げます。
As discussed in Section 2 above, there are dangers associated with software that attempts to "know" the list of top-level domain names locally and take advantage of that knowledge. These name-guessing heuristics are another example of that situation: if the lists are up-to-date and used carefully, the systems in which they are embedded may provide an easier, and more attractive, experience for at least some users. But finding the wrong host, or being unable to find a host even when its name is precisely known, constitute bad experiences by any measure.
上のセクション2で議論するように、局所的に最上位のドメイン名のリストを「知っ」て、その知識を利用するのを試みるソフトウェアに関連している危険があります。 これらの名前を推測する発見的教授法はその状況に関する別の例です: リストが慎重に最新であって、使用されているなら、それらが埋め込まれているシステムは、より簡単で、より魅力的な経験を少なくとも何人かのユーザに提供するかもしれません。 しかし、名前が正確に知られるときさえ、間違ったホストを見つけるか、またはホストを見つけることができないで、あらゆる測定で悪い経験を構成してください。
More generally, there have been bad experiences with attempts to "complete" domain names by adding additional information to them. These issues are described in some detail in RFC 1535 [RFC1535].
より一般に、それらに追加情報を加えることによってドメイン名を「完成する」試みには悪い経験がありました。 これらの問題はRFC1535[RFC1535]で何らかの詳細に説明されます。
5. Implications of internationalization
5. 国際化の含意
The IETF has adopted a series of proposals ([RFC3490] - [RFC3492]) whose purpose is to permit encoding internationalized (i.e., non- ASCII) names in the DNS. The primary standard, and the group generically, are known as "IDNA". The actual strings stored in the
すなわち、IETFがコード化が国際的にした許可証には目的がある一連の提案([RFC3490]--[RFC3492])を採用した、(非、-、ASCII) DNSの名前。 そして、原器、一般的に分類して、"IDNA"として知られています。 実際のストリングは中に格納しました。
Klensin Informational [Page 11] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[11ページ]のRFC3696の照合と変化
DNS are in an encoded form: the labels begin with the characters "xn--" followed by the encoded string. Applications should be prepared to accept and process the encoded form (those strings are consistent with the "LDH rule" (see Section 2) so should not raise any separate issues) and the use of local, and potentially other, characters as appropriate to local systems and circumstances.
DNSがコード化されたフォームにあります: ラベルはキャラクタと共に始まります。「xn--」 コード化で、ストリングに続けました。 アプリケーションは、適宜コード化されたフォーム(それらのストリングが「LDH規則」と一致しているので(セクション2を見てください)、少しの別個問題も提起するべきではありません、)と地方の、そして、潜在的に他のキャラクタの使用をローカルシステムと事情に受け入れて、処理するように準備されるべきです。
The IDNA specification describes the exact process to be used to validate a name or encoded string. The process is sufficiently complex that shortcuts or heuristics, especially for versions of labels written directly in Unicode or other coded character sets, are likely to fail and cause problems. In particular, the strings cannot be validated with syntax or semantic rules of any of the usual sorts: syntax validity is defined only in terms of the result of executing a particular function.
IDNA仕様は、名前かコード化されたストリングを有効にするのに使用されるために正確な過程について説明します。 過程は十分、普通の種類のどれかの構文か意味規則で近道か発見的教授法が問題特にストリングに失敗して、直接何らかのユニコードで書かれたラベルのバージョンが特に文字の組をコード化したので引き起こしそうである複合体を有効にすることができないということです: 単に特定の機能を実行するという結果で構文の正当性は定義されます。
In addition to the restrictions imposed by the protocols themselves, many domains are implementing rules about just which non-ASCII names they will permit to be registered (see, e.g., [JET], [RegRestr]). This work is still relatively new, and the rules and conventions are likely to be different for each domain, or at least each language or script group. Attempting to test for those rules in a client program to see if a user-supplied name might possibly exist in the relevant domain would almost certainly be ill-advised.
プロトコル自体によって課された制限に加えて、多くのドメインがそれらが、まさしくどの非ASCII名が登録されることを許可するかに関する(見てください、例えば、[JET]、[RegRestr])規則を実行しています。 この仕事はまだ比較的新しいです、そして、規則とコンベンションは少なくともそれぞれの各ドメイン、言語またはスクリプトグループにおいて異なる傾向があります。 クライアントプログラムにおけるそれらの規則が、ユーザによって供給された名前がことによると関連ドメインに存在するかもしれないかどうか確認するようにテストするのを試みるのはほぼ確実にあさはかでしょう。
One quick local test however, may be reasonable: as of the time of this writing, there should be no instances of labels in the DNS that start with two characters, followed by two hyphens, where the two characters are not "xn" (in, of course, either upper or lower case). Such label strings, if they appear, are probably erroneous or obsolete, and it may be reasonable to at least warn the user about them.
しかしながら、ある迅速なローカルがテストして、妥当であるかもしれません: この書くことの時現在、2つのハイフンがあとに続いた2つのキャラクタから始めるDNSのラベルの例が全く2つのキャラクタが"xn"(もちろん上側の、または、低い場合における)でないところにあるべきではありません。 現れるなら、そのようなラベルストリングは、たぶん誤るか、または時代遅れです、そして、それらに関してユーザに少なくとも警告するのは妥当であるかもしれません。
There is ongoing work in the IETF and elsewhere to define internationalized formats for use in other protocols, including email addresses. Those forms may or may not conform to existing rules for ASCII-only identifiers; anyone designing evaluators or filters should watch that work closely.
他のプロトコルにおける使用のための国際化している書式を定義するために、進行中の仕事がIETFとほかの場所にあります、Eメールアドレスを含んでいて。 それらのフォームはASCIIだけ識別子のための既存の規則に従うかもしれません。 評価者かフィルタを設計するだれでも密接にその仕事を見るべきです。
6. Summary
6. 概要
When an application accepts a string from the user and ultimately passes it on to an API for a protocol, the desirability of testing or filtering the text in any way not required by the protocol itself is hotly debated. If it must divide the string into its components, or otherwise interpret it, it obviously must make at least enough tests to validate that process. With, e.g., domain names or email addresses that can be passed on untouched, the appropriateness of
アプリケーションがユーザからストリングを受け入れて、結局プロトコルのためにAPIにそれを移るとき、プロトコル自体によって何らかの方法で必要とされなかったテキストをテストするか、またはフィルターにかける願わしさは熱心に討論されます。 ストリングをコンポーネントに分割しなければならないか、またはそうでなければ、それを解釈しなければならないなら、それは、その過程を有効にするために明らかに十分少なくともテストをしなければなりません。 例えば、ドメイン名か触れないところで通過できるEメールアドレス、適切さ
Klensin Informational [Page 12] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[12ページ]のRFC3696の照合と変化
trying to figure out which ones are valid and which ones are not requires a more complex decision, one that should include considerations of how to make exactly the correct tests and to keep information that changes and evolves up-to-date. A test containing obsolete information, can be extremely frustrating for potential correspondents or customers and may harm desired relationships.
どれが有効であるか、そして、1つがどれであるかを理解しようとするのが、より複雑な決定(まさに正しいテストをして、どう最新に変化して、発展する情報を保つかに関する問題を含むべきであるもの)を必要としません。 潜在的通信員か顧客には、時代遅れの情報を含むテストは非常にいらだたしい場合があります、そして、望ましい関係に害を及ぼすかもしれません。
7. Security Considerations
7. セキュリティ問題
Since this document merely summarizes the requirements of existing standards, it does not introduce any new security issues. However, many of the techniques that motivate the document raise important security concerns of their own. Rejecting valid forms of domain names, email addresses, or URIs often denies service to the user of those entities. Worse, guessing at the user's intent when an incomplete address, or other string, is given can result in compromises to privacy or accuracy of reference if the wrong target is found and returned. From a security standpoint, the optimum behavior is probably to never guess, but instead, to force the user to specify exactly what is wanted. When that position involves a tradeoff with an acceptable user experience, good judgment should be used and the fact that it is a tradeoff recognized.
このドキュメントが単に既存の規格の要件をまとめるので、それは少しの新しい安全保障問題も紹介しません。 しかしながら、ドキュメントを動機づけるテクニックの多くがそれら自身の重要な安全上の配慮を上げます。 有効なフォームのドメイン名、Eメールアドレス、またはURIを拒絶すると、それらの実体のユーザに対するサービスはしばしば否定されます。 よりひどく、間違った目標を見つけて、返すなら、ユーザの意図で不完全なアドレス、または他のストリングがいつ与えられるかを推測するのが参照のプライバシーか精度との妥協をもたらすことができます。 セキュリティ見地から、最適な振舞いはしかし、ユーザにまさに欲しいことを指定させるとたぶん決して代わりに推測しないことです。 その仕事が許容できるユーザー・エクスペリエンスに見返りにかかわるとき、良い判断は、使用されていてそれが認識された見返りであるという事実であるべきです。
Some characters have special or privileged meanings on some systems (i.e., ` on Unix). Applications should be careful to escape those locally if necessary. By the same token, they are valid, and should not be disallowed locally, or escaped when transmitted through Internet protocols, for such reasons if a remote site chooses to use them.
何人かのキャラクタがいくつかのシステムの上に特別であるか特権がある意味を持っている、(すなわち'、オンである、Unix)、' アプリケーションは必要なら、局所的にそれらから逃げるのに慎重であるはずです。 同様に、そのような理由でインターネットプロトコルを通して伝える場合、リモートサイトが、それらを使用するのを選ぶなら、それらを有効であり、局所的に禁じるべきではありませんし、また逃げるべきではありません。
The presence of local checking does not permit remote checking to be bypassed. Note that this can apply to a single machine; in particular, a local MTA should not assume that a local MUA has properly escaped locally-significant special characters.
地方の照合の存在は、リモート照合が迂回することを許可しません。 これは単一マシンに適用できることに注意してください。 特に、地方のMTAは、地方のMUAが適切に局所的に重要な特殊文字から逃げたと仮定するはずがありません。
8. Acknowledgements
8. 承認
The author would like to express his appreciation for helpful comments from Harald Alvestrand, Eric A. Hall, and the RFC Editor, and for partial support of this work from SITA. Responsibility for any errors remains, of course, with the author.
作者はサイタからハラルドAlvestrand、エリックA.Hall、およびRFC Editorからの役に立つコメント、およびこの仕事の部分的なサポートに対する彼の感謝を申し上げたがっています。 どんな誤りへの責任ももちろん作者と共に残っています。
The first Internet-Draft on this subject was posted in February 2003. The document was submitted to the RFC Editor on 20 June 2003, returned for revisions on 19 August, and resubmitted on 5 September 2003.
この話題における最初のインターネット草稿は2003年2月に掲示されました。 ドキュメントは、2003年6月20日の8月19日に改正のために返されたRFC Editorに提出して、2003年9月5日に再提出されました。
Klensin Informational [Page 13] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[13ページ]のRFC3696の照合と変化
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October
1989.
[RFC1123] ブレーデン、R.、エド、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC1535] Gavron, E., "A Security Problem and Proposed
Correction With Widely Deployed DNS Software", RFC
1535, October 1993.
[RFC1535] Gavronと、E.と、「広く配備されたDNSソフトウェアとの警備上の問題と提案された修正」、RFC1535、10月1993日
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill,
"Uniform Resource Locators (URL)", RFC 1738, December
1994.
[RFC1738] バーナーズ・リーとT.とMasinterとL.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[RFC2368] Hoffman, P., Masinter, L. and J. Zawinski, "The
mailto URL scheme", RFC 2368, July 1998.
[RFC2368] ホフマンとP.とMasinterとL.とJ.Zawinski、「mailto URL計画」、RFC2368、1998年7月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998.
[RFC2396] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC2821] Klensin、J.、エド、「簡単なメール転送プロトコル」、RFC2821、4月2001日
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC
2822, April 2001.
[RFC2822] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日
[RFC3490] Faltstrom, P., Hoffman, P. and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[RFC3490] FaltstromとP.とホフマンとP.とA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)",
RFC 3491, March 2003.
[RFC3491] ホフマン、P.、およびM.Blanchet、「Nameprep:」 「国際化ドメイン名(IDN)のためのStringprepプロフィール」、RFC3491、2003年3月。
Klensin Informational [Page 14] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[14ページ]のRFC3696の照合と変化
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of
Unicode for Internationalized Domain Names in
Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、「Punycode:」 「Applications(IDNA)のInternationalized Domain Namesのためにユニコードをコード化するBootstring」、RFC3492、2003年3月。
[ASCII] American National Standards Institute (formerly
United States of America Standards Institute), "USA
Code for Information Interchange", ANSI X3.4-1968.
ANSI X3.4-1968 has been replaced by newer versions
with slight modifications, but the 1968 version
remains definitive for the Internet.
[ASCII]American National Standards Institut(以前アメリカ合衆国規格研究所)、「米国情報交換用符号」、ANSI X3.4-1968。 わずかな変更でANSI X3.4-1968をより新しいバージョンに取り替えましたが、1968年のバージョンはインターネットに決定的に残っています。
[DomainList] Internet Assigned Numbers Authority (IANA), Untitled
alphabetical list of current top-level domains.
http://data.iana.org/TLD/tlds-alpha-by-domain.txt
ftp://data.iana.org/TLD/tlds-alpha-by-domain.txt
[DomainList] インターネットAssigned民数記Authority(IANA)、現在の最上位のドメイン http://data.iana.org/TLD/tlds-alpha-by-domain.txt ftp://data.iana.org/TLD/tlds-alpha-by-domain.txt のUntitledのアルファベット順リスト
9.2. Informative References
9.2. 有益な参照
[ISO.3166.1988] International Organization for Standardization,
"Codes for the representation of names of countries,
3rd edition", ISO Standard 3166, August 1988.
[ISO、.3166、.1988、]、国際標準化機構、「国の名前、3番目の版の表現のためのコード」、ISO Standard3166、8月1988日
[JET] Konishi, K., et al., "Internationalized Domain Names
Registration and Administration Guideline for
Chinese, Japanese and Korean", Work in Progress.
[JET] コニシと、K.と、他と、「中国語、日本語、および韓国語のための国際化ドメイン名登録と政権ガイドライン」、ProgressのWork。
[RFC1591] Postel, J., "Domain Name System Structure and
Delegation", RFC 1591, March 1994.
[RFC1591] ポステルと、J.と、「ドメインネームシステム構造と代表団」(RFC1591)は1994を行進させます。
[RegRestr] Klensin, J., "Registration of Internationalized
Domain Names: Overview and Method", Work in Progress,
February 2004.
[RegRestr]Klensin、J.、「国際化ドメイン名の登録:」 「概観と方法」は進歩、2004年2月に働いています。
10. Author's Address
10. 作者のアドレス
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 Informational [Page 15] RFC 3696 Checking and Transformation of Names February 2004
名前2004年2月のKlensinの情報[15ページ]のRFC3696の照合と変化
11. Full Copyright Statement
11. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Klensin Informational [Page 16]
Klensin情報です。[16ページ]
一覧
スポンサーリンク
