この文書はインターネットドラフトの日本語訳(和訳)です。 翻訳者はこの文書の翻訳の正確さを保障しません。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 翻訳者はこの翻訳の配布に制限をしません。


Network Working Group                                          M. Koster
Internet-Draft                                Stalworthy Computing, Ltd.
Intended status: Draft Standard                                G. Illyes
Expires: January 9, 2020                                       H. Zeller
                                                               L. Harvey
                                                                  Google
                                                           July 07, 2019


                       Robots Exclusion Protocol
                       ロボット排除プロトコル
                         draft-koster-rep-00

Abstract
要約

   This document standardizes and extends the "Robots Exclusion
   Protocol" <http://www.robotstxt.org/> method originally defined by
   Martijn Koster in 1996 for service owners to control how content
   served by their services may be accessed, if at all, by automatic
   clients known as crawlers.
   この文書は1996年にMartijn Kosterによって最初に定義された
   "Robots Exclusion Protocol" <http://www.robotstxt.org/>メソッドを
   標準化し拡張して、サービス所有者が自分たちのサービスによって提供
   されるコンテンツへのクローラと呼ばれる自動クライアントによる
   アクセスを制御します。

Status of This Memo
このメモの状態

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.
   このインターネットドラフトは、BCP 78およびBCP 79の規定に完全に
   準拠して配布されます。


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.
   インターネットドラフトは、インターネット技術特別調査委員会(IETF)
   の作業文書です。他のグループも作業文書をインターネットドラフトとし
   て配布する可能性があることに注意してください。
   現在のインターネットドラフトの一覧は
   http://datatracker.ietf.org/drafts/current/にあります。

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   インターネットドラフトは最大6カ月間有効なドラフト文書で、いつでも他
   の文書によって、更新か、置換えか、時代遅れにされるかもしれません。イ
   ンターネットドラフトは、「進行中の仕事」として以外に、参照材料あるい
   は引用として用いることは不適当です。

   This document may not be modified, and derivative works of it may not
   be created, except to format it for publication as an RFC or to
   translate it into languages other than English.
   この文書は、RFCとして公開するためにフォーマットしたり、英語以外の言語
   に翻訳したりすることを除いて、修正したり、2次著作物を作成したりする
   ことはできません。

   This Internet-Draft will expire on January 9, 2020.
   このインターネットドラフトは、2020年1月9日に有効期限が切れます。

Copyright Notice
著作権表示

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.
   著作権(C)2008、IETF信託と文書の著者と認識される人々。す
   べての権利は当方に帰属します。

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
   この文書はBCP78とこの文書の出版の日付に実施されているIETF
   文書に関するIETF信託の法律条項(http://trustee.ietf.org/license-info)
   の適用を受けます。それらがこの文書に関するあなたの権利と制限を記述
   するので、慎重にこれらの文書を閲覧してください。本書から抽出された
   コードコンポーネントには、Trust Legal Provisionsのセクション4.eに
   記載されているSimplified BSD Licenseのテキストが含まれており、
   Simplified BSD Licenseに記載されているとおり無保証で提供されます。


Koster, et al.           Expires January 9, 2020                [Page 1]

Internet-Draft                     I-D                         July 2019

Table of Contents
目次

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Protocol definition . . . . . . . . . . . . . . . . . . .   3
     2.2.  Formal syntax . . . . . . . . . . . . . . . . . . . . . .   3
       2.2.1.  The user-agent line . . . . . . . . . . . . . . . . .   4
       2.2.2.  The Allow and Disallow lines  . . . . . . . . . . . .   4
       2.2.3.  Special characters  . . . . . . . . . . . . . . . . .   5
       2.2.4.  Other records . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Access method . . . . . . . . . . . . . . . . . . . . . .   6
       2.3.1.  Access results  . . . . . . . . . . . . . . . . . . .   7
     2.4.  Caching . . . . . . . . . . . . . . . . . . . . . . . . .   8
     2.5.  Limits  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     2.6.  Security Considerations . . . . . . . . . . . . . . . . .   8
     2.7.  IANA Considerations . . . . . . . . . . . . . . . . . . .   8
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Simple example  . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Longest Match . . . . . . . . . . . . . . . . . . . . . .   9
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     4.2.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   10

1.  Introduction
1.  はじめに

   This document applies to services that provide resources that clients
   can access through URIs as defined in RFC3986 [1].  For example, in
   the context of HTTP, a browser is a client that displays the content
   of a web page.
   この文書は、RFC3986 [1]で定義されている、URIを通してクライアントが
   リソースにアクセスするサービスに適用されます。たとえば、HTTPのコンテ
   キストで、ブラウザはウェブページの内容を表示するクライアントです。

   Crawlers are automated clients.  Search engines for instance have
   crawlers to recursively traverse links for indexing as defined in
   RFC8288 [2].
   クローラは自動化されたクライアントです。 例えば検索エンジンは、
   RFC8288 [2]で定義されているように、インデックスを作成するために再帰
   的にリンクをたどるクローラを持っています。

   It may be inconvenient for service owners if crawlers visit the
   entirety of their URI space.  This document specifies the rules that
   crawlers MUST obey when accessing URIs.
   クローラーがURI空間全体を訪問すると、サービス所有者が困る可能性が
   あります。この文書は、クローラがURIにアクセスするときに従わなけれ
   ばならない規則を指定します。

   These rules are not a form of access authorization.
   これらの規則はアクセス許可の規則ではありません。

1.1.  Terminology
1.1.  用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
   この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
   NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"NOT RECOMMENDED"と
   "MAY"と"OPTIONAL"は、ここにあるように大文字で書かれている場合、
   BCP 14 [RFC2119] [RFC8174]で記述されるように解釈します。




Koster, et al.           Expires January 9, 2020                [Page 2]

Internet-Draft                     I-D                         July 2019


2.  Specification
2.  仕様

2.1.  Protocol definition
2.1.  プロトコル定義

   The protocol language consists of rule(s) and group(s):
    プロトコル言語は、規則とグループで構成されています。

   o  *Rule*: A line with a key-value pair that defines how a crawler
      may access URIs. See section The Allow and Disallow lines.
   o  *ルール*:クローラがURIにアクセスする方法を定義するキーと値の
      ペアを含む行。許可行と不許可行を参照してください。

   o  *Group*: One or more user-agent lines that is followed by one or
      more rules. The group is terminated by a user-agent line or end
      of file. See User-agent line. The last group may have no rules,
      which means it implicitly allows everything.
   o  *グループ*:1つ以上のルールが後に続く1つ以上のユーザーエージェ
      ント行。グループはユーザーエージェント行またはファイルの終わり
      で終了します。ユーザーエージェント行を参照してください。 最後
      のグループにはルールがないかもしれず、すべて許可を暗示します。

2.2.  Formal syntax
2.2.  正式な構文

   Below is an Augmented Backus-Naur Form (ABNF) description, as
   described in RFC5234 [3].
   下記は、RFC5234 [3]で説明されている拡張バッカスナウア記法(ABNF)
   での説明です。

   robotstxt = *(group / emptyline)
   group = startgroupline                ; We start with a user-agent
           *(startgroupline / emptyline) ; ... and possibly more
                                         ; user-agents
           *(rule / emptyline)           ; followed by rules relevant
                                         ; for UAs
                                         ; ユーザーエージェントから始
                                         ; まり、さらにユーザーエー
                                         ; ジェントとそれに続くかもし
                                         ; れず、その後にUAに関連する
                                         ; ルールが続きます。

   startgroupline = *WS "user-agent" *WS ":" *WS product-token EOL

   rule = *WS ("allow" / "disallow") *WS ":"
          *WS (path-pattern / empty-pattern) EOL

   ; parser implementors: add additional lines you need (for
   ; example Sitemaps), and be lenient when reading lines that don't
   ; conform. Apply Postel's law.
   ; パーサの実装者:(サイトマップなどの)必要な行を追加できます、
   ;想定外の行を寛大に扱ってください。ポステルの法則を適用する。

   product-token = identifier / "*"
   path-pattern = "/" *(UTF8-char-noctl) ; valid URI path pattern
                                         ; 正しいURIパス形式
   empty-pattern = *WS

   identifier = 1*(%x2d / %x41-5a / %x5f / %x61-7a)
   comment = "#"*(UTF8-char-noctl / WS / "#")
   emptyline = EOL EOL = *WS [comment] NL ; end-of-line may have
                                          ; optional trailing comment
                                          ; 行末にコメントが書けます
   NL = %x0D / %x0A / %x0D.0A
   WS = %x20 / %x09


Koster, et al.           Expires January 9, 2020                [Page 3]

Internet-Draft                     I-D                         July 2019

   ; UTF8 derived from RFC3629, but excluding control characters
   ; RFC 3629から派生したUTF8、ただし制御文字は除く

   UTF8-char-noctl = UTF8-1-noctl / UTF8-2 / UTF8-3 / UTF8-4
   UTF8-1-noctl = %x21 / %x22 / %x24-7F ; excluding control, space, '#'
   UTF8-2 = %xC2-DF UTF8-tail
   UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
            %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
   UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
            %xF4 %x80-8F 2( UTF8-tail )

   UTF8-tail = %x80-BF

2.2.1.  The user-agent line
2.2.1.  ユーザーエージェント行

   Crawlers set a product token to find relevant groups.  The product
   token MUST contain only "a-zA-Z_-" characters.  The product token
   SHOULD be part of the identification string that the crawler sends
   to the service (for example, in the case of HTTP, the product name
   SHOULD be in the user-agent header).  The identification string
   SHOULD describe the purpose of the crawler.  Here's an example of an
   HTTP header with a link pointing to a page describing the purpose of
   the ExampleBot crawler which appears both in the HTTP header and as a
   product token:
   クローラは関係するグループを見つけるためにプロダクトトークンを規定
   します。プロダクトトークンは "a-zA-Z_-"の文字だけからなります(MUST)。
   プロダクトトークンは、クローラがサービスで送信する識別文字列の一部
   であるべきです(SHOULD)(たとえば、HTTPの場合、プロダクト名はユーザー
   エージェントヘッダーに含めるべきです(SHOULD))。識別文字列は、クロー
   ラの目的を説明するべきです(SHOULD)。下記は、ExampleBotクローラーの
   目的を説明するページを指すリンクを持つHTTPヘッダーの例で、HTTP
   ヘッダーとプロダクトトークンの両方に表示されます。
   +-------------------------------------------------+-----------------+
   | HTTP header                                     | robots.txt      |
   |                                                 | user-agent line |
   +-------------------------------------------------+-----------------+
   | user-agent: Mozilla/5.0 (compatible;            | user-agent:     |
   | ExampleBot/0.1;                                 | ExampleBot      |
   | https://www.example.com/bot.html)               |                 |
   +-------------------------------------------------+-----------------+

   Crawlers MUST find the group that matches the product token exactly,
   and then obey the rules of the group.  If there is more than one
   group matching the user-agent, the matching groups' rules MUST be
   combined into one group.  The matching MUST be case-insensitive.  If
   no matching group exists, crawlers MUST obey the first group with a
   user-agent line with a "*" value, if present.  If no group satisfies
   either condition, or no groups are present at all, no rules apply.
   クローラはプロダクトトークンと正確に一致するグループを見つけ(MUST)、
   そのグループの規則に従わなければなりません。 ユーザエージェントに一致
   するグループが複数ある場合は、一致するグループの規則を1つのグループ
   にまとめる必要があります(MUST)。 一致では大文字と小文字が区別されま
   せん。 一致するグループが存在しない場合、クローラは、 "*"値のユーザー
   エージェント行を持つグループがあれば、最初のその様なグループに従わな
   ければなりません(MUST)。 これらの条件を満たすグループが存在しない場
   合、またはグループがまったく存在しない場合、ルールは適用されません。

2.2.2.  The Allow and Disallow lines
2.2.2.  許可行と不許可行

   These lines indicate whether accessing a URI that matches the
   corresponding path is allowed or disallowed.
   これらの行は、対応するパスと一致するURIへのアクセスが許可されている
   かどうかを示します。

   To evaluate if access to a URI is allowed, a robot MUST match the
   paths in allow and disallow rules against the URI.  The matching
   SHOULD be case sensitive.  The most specific match found MUST be
   used.  The most specific match is the match that has the most octets.
   If an allow and disallow rule is equivalent, the allow SHOULD be
   used.  If no match is found amongst the rules in a group for a


Koster, et al.           Expires January 9, 2020                [Page 4]

Internet-Draft                     I-D                         July 2019


   matching user-agent, or there are no rules in the group, the URI is
   allowed.  The /robots.txt URI is implicitly allowed.
   URIへのアクセスが許可されているかを評価するために、ロボットはURI内の
   許可および拒否ルール内のパスを比較する必要があります(MUST)。 比較では
   大文字と小文字が区別されるべきです(SHOULD)。 見つかった中で最も具体的
   に一致したものを使わなければなりません(MUST)。 最も具体的な一致は、一
   致するオクテットが最も多いものです。 許可規則と不許可規則が等価な場合、
   許可を使用するべきです(SHOULD)。 一致するユーザエージェントのグループ
   内にURIに一致するルールが見つからない場合や、グループ内にルールがな
   い場合は、URIは許可されます。 /robots.txt URIは暗黙で許可されています。

   Octets in the URI and robots.txt paths outside the range of the US-
   ASCII coded character set, and those in the reserved range defined by
   RFC3986 [1], MUST be percent-encoded as defined by RFC3986 [1] prior
   to comparison.
   US-ASCII文字コードセットの範囲外のURIパスとrobots.txtパス内のオク
   テットと、RFC3986[1]で定義されている予約範囲内のオクテットは、比較を
   する前にRFC3986[1]で定義されているパーセントエンコードをしなければな
   りません(MUST)。

   If a percent-encoded US-ASCII octet is encountered in the URI, it
   MUST be unencoded prior to comparison, unless it is a reserved
   character in the URI as defined by RFC3986 [1] or the character is
   outside the unreserved character range.  The match evaluates
   positively if and only if the end of the path from the rule is
   reached before a difference in octets is encountered.
   URIでパーセントエンコードされたUS-ASCIIオクテットが見つかった場合は、
   それがRFC3986 [1]で定義されているURIの予約文字であるか、その文字が予
   約されていない文字の範囲外である場合を除き、比較前にデコードしなければ
   なりません(MUST)。一致しないオクテットが見つかる前に、ルールのパスの終
   わった場合に限り、一致は肯定的に評価されます。

   For example:
   例えば:

   +-------------------+-----------------------+-----------------------+
   | Path              | Encoded Path          | Path to match         |
   +-------------------+-----------------------+-----------------------+
   | /foo/bar?baz=quz  | /foo/bar?baz=quz      | /foo/bar?baz=quz      |
   |                   |                       |                       |
   | /foo/bar?baz=http | /foo/bar?baz=http%3A% | /foo/bar?baz=http%3A% |
   | ://foo.bar        | 2F%2Ffoo.bar          | 2F%2Ffoo.bar          |
   |                   |                       |                       |
   | /foo/bar/U+E38384 | /foo/bar/%E3%83%84    | /foo/bar/%E3%83%84    |
   |                   |                       |                       |
   | /foo/bar/%E3%83%8 | /foo/bar/%E3%83%84    | /foo/bar/%E3%83%84    |
   | 4                 |                       |                       |
   |                   |                       |                       |
   | /foo/bar/%62%61%7 | /foo/bar/%62%61%7A    | /foo/bar/baz          |
   | A                 |                       |                       |
   +-------------------+-----------------------+-----------------------+

   The crawler SHOULD ignore "disallow" and "allow" rules that are not
   in any group (for example, any rule that precedes the first user-
   agent line).
   クローラは、どのグループにも属していない"disallow"および "allow"ルー
   ル(たとえば、最初のユーザーエージェント行の前にあるルールなど)を無
   視するべきです(SHOULD)。

   Implementers MAY bridge encoding mismatches if they detect that the
   robots.txt file is not UTF8 encoded.
   robots.txtファイルがUTF8でエンコードされていないことを検出した場合、
   実装者は、エンコーディングの不一致を解消するかもしれません(MAY)。

2.2.3.  Special characters
2.2.3.  特殊キャラクター

   Crawlers SHOULD allow the following special characters:
   クローラは、次の特殊文字を許可するべきです(SHOULD):






Koster, et al.           Expires January 9, 2020                [Page 5]

Internet-Draft                     I-D                         July 2019


   +-----------+--------------------------------+----------------------+
   | Character | Description                    | Example              |
   +-----------+--------------------------------+----------------------+
   | "#"       | Designates an end of line      | "allow: / # comment  |
   |           | comment.                       | in line"             |
   |           | 行末のコメントを指定           |                      |
   |           |                                |                      |
   |           |                                | "# comment at the    |
   |           |                                | end"                 |
   |           |                                |                      |
   | "$"       | Designates the end of the      | "allow:              |
   |           | match pattern. A URI MUST end  | /this/path/exactly$" |
   |           | with a $.                      |                      |
   |           | 一致パターンの終わりを指定。   |                      |
   |           | URI$で終わること (MUST)        |                      |
   |           |                                |                      |
   | "*"       | Designates 0 or more instances | "allow:              |
   |           | of any character.              | /this/*/exactly"     |
   |           | 任意の文字の0個以上のインスタ |                      |
   |           | ンスを指定します。             |                      |
   +-----------+--------------------------------+----------------------+

   If crawlers match special characters verbatim in the URI, crawlers
   SHOULD use "%" encoding.  For example:
   クローラがURI内の特殊文字と一致する場合、クローラは "%"エンコーディ
   ングを使用すべきです(SHOULD)。 例えば:

   +------------------------+------------------------------------------+
   | Pattern                | URI                                      |
   +------------------------+------------------------------------------+
   | /path/file-            | https://www.example.com/path/file-       |
   | with-a-%2A.html        | with-a-*.html                            |
   |                        |                                          |
   | /path/foo-%24          | https://www.example.com/path/foo-$       |
   +------------------------+------------------------------------------+

2.2.4.  Other records
2.2.4.  その他のレコード

   Clients MAY interpret other records that are not part of the
   robots.txt protocol.  For example, 'sitemap' [4].
   クライアントは、robots.txtプロトコルの一部ではない他のレコードを解釈
   するかもしれませn(MAY)。たとえば、'sitemap'[4]です。

2.3.  Access method
2.3.  アクセス方法

   The rules MUST be accessible in a file named "/robots.txt" (all lower
   case) in the top level path of the service.  The file MUST be UTF-8
   encoded (as defined in RFC3629 [5]) and Internet Media Type "text/
   plain" (as defined in RFC2046 [6]).
   ルールは、サービスのトップレベルパスにある"/robots.txt"(すべて小文字)
   という名前のファイルでアクセス可能でなければなりません(MUST)。 ファイ
   ルは(RFC3629 [5]で定義されているように)UTF-8でエンコードされ、
   (RFC2046 [6]で定義されているように)インターネットメディアタイプ
   "text / plain"でなければなりません(MUAT)。

   As per RFC3986 [1], the URI of the robots.txt is:
   RFC3986 [1]に従うと、robots.txtのURIは次のとおりです。

   "scheme:[//authority]/robots.txt"

   For example, in the context of HTTP or FTP, the URI is:
   たとえば、HTTPまたはFTPのコンテキストでは、URIは次の
   とおりです:

       http://www.example.com/robots.txt



Koster, et al.           Expires January 9, 2020                [Page 6]

Internet-Draft                     I-D                         July 2019


       https://www.example.com/robots.txt

       ftp://ftp.example.com/robots.txt

2.3.1.  Access results
2.3.1.  アクセス結果

2.3.1.1.  Successful access
2.3.1.1.  アクセス成功

   If the crawler successfully downloads the robots.txt, the crawler
   MUST follow the parseable rules.
   クローラがrobots.txtのダウンロードに成功した場合、クローラは解析
   可能な規則に従う必要があります(MUST)。

2.3.1.2.  Redirects
2.3.1.2.  リダイレクト

   The server may respond to a robots.txt fetch request with a redirect,
   such as HTTP 301 and HTTP 302.  The crawlers SHOULD follow at least
   five consecutive redirects, even across authorities (for example
   hosts in case of HTTP), as defined in RFC1945 [7].
   サーバーは、HTTP 301やHTTP 302などのリダイレクトを使用して
   robots.txt読出要求に応答することがあります。RFC 1945[5]で定義されて
   いるように、オーソリティ(HTTPではホスト)が変わっても、クローラーは
   少なくとも5回リダイレクトすべきです(SHOULD)。

   If a robots.txt file is reached within five consecutive redirects,
   the robots.txt file MUST be fetched, parsed, and its rules followed
   in the context of the initial authority.
   5回以下のリダイレクトでrobots.txtファイルに到達した場合は、
   robots.txtファイルを読込み、解析し、その規則を最初のオーソリティの
   コンテキストに従って実行する必要があります(MUST)。

   If there are more than five consecutive redirects, crawlers MAY
   assume that the robots.txt is unavailable.
   5回以上の連続したリダイレクトがある場合、クローラはrobots.txtが利
   用できないと見なすかもしれません(MAY)。

2.3.1.3.  Unavailable status
2.3.1.3.  利用不可のステータス

   Unavailable means the crawler tries to fetch the robots.txt, and the
   server responds with unavailable status codes.  For example, in the
   context of HTTP, unavailable status codes are in the 400-499 range.
   利用不可とは、クローラがrobots.txtを取得しようとし、サーバーが利用不
   可のステータスコードで応答することを意味します。 例えば、HTTPのコン
   テキストでは、使用不可の状況コードは400から499の範囲です。

   If a server status code indicates that the robots.txt file is
   unavailable to the client, then crawlers MAY access any resources on
   the server or MAY use a cached version of a robots.txt file for up to
   24 hours.
   サーバーステータスコードがクライアントにrobots.txtファイルが利用でき
   ないことを示す場合、クローラーはサーバー上のすべてのリソースにアクセ
   スするか(MAY)、または最大24時間キャッシュ版のrobots.txtファイルを使
   用することができます(MAY)。

2.3.1.4.  Unreachable status
2.3.1.4.  到達不能ステータス

   If the robots.txt is unreachable due to server or network errors,
   this means the robots.txt is undefined and the crawler MUST assume
   complete disallow.  For example, in the context of HTTP, an
   unreachable robots.txt has a response code in the 500-599 range.  For
   other undefined status codes, the crawler MUST assume the robots.txt
   is unreachable.
   サーバーまたはネットワークのエラーのためにrobots.txtが読めない場合、
   これはrobots.txtが未定義であることを意味し、クローラーは完全な不許
   可を想定しなければなりません(MUST)。 たとえば、HTTPのコンテキストで
   は、到達不能なrobots.txtのレスポンスコードは500?599の範囲です。
   他の未定義のステータスコードの場合、クローラはrobots.txtが到達不能
   であると想定しなければなりません(MUST)。

   If the robots.txt is undefined for a reasonably long period of time
   (for example, 30 days), clients MAY assume the robots.txt is
   unavailable or continue to use a cached copy.
   robots.txtがかなり長い期間(たとえば、30日間)定義されていない場合、
   クライアントはrobots.txtが利用できないと想定するか、またはキャッ
   シュコピーを使用する可能性があります。


Koster, et al.           Expires January 9, 2020                [Page 7]

Internet-Draft                     I-D                         July 2019


2.3.1.5.  Parsing errors
2.3.1.5.  解析エラー

   Crawlers SHOULD try to parse each line of the robots.txt file.
   Crawlers MUST use the parseable rules.
   クローラは、robots.txtファイルの各行を解析するべきです(SHOULD)。ク
   ローラは解析可能な規則を使用しなければなりません(MUST)。

2.4.  Caching
2.4.  キャッシング

   Crawlers MAY cache the fetched robots.txt file's contents.  Crawlers
   MAY use standard cache control as defined in RFC2616 [8].  Crawlers
   SHOULD NOT use the cached version for more than 24 hours, unless the
   robots.txt is unreachable.
   クローラは、取得したrobots.txtファイルの内容をキャッシュすることがで
   きます(MAY)。 クローラはRFC2616 [8]で定義されている標準のキャッシュ制
   御を使用できます(MAY)。 robots.txtにアクセスできない場合を除き、
   クローラはキャッシュされたバージョンを24時間以上使用しないべきです
   (SHOULD NOT)。

2.5.  Limits
2.5.  限界

   Crawlers MAY impose a parsing limit that MUST be at least 500
   kibibytes (KiB).
   クローラは解析制限をするかもしれず(MAY)、制限は最小500キロバイト
   (KiB)でなければなりません(MUST)。

2.6.  Security Considerations
2.6.  セキュリティ上の考慮事項

   The Robots Exclusion Protocol MUST NOT be used as a form of security
   measures. Listing URIs in the robots.txt file exposes the URI
   publicly and thus making the URIs discoverable.
   ロボット排除プロトコルは、セキュリティ対策のとして使用してはなりませ
   ん(MUST NOT)。robots.txtファイルにURIをリストすると、そのURIが公開
   され、URIが検出可能になります。

2.7.  IANA Considerations.
2.7.  IANAに関する考慮

   This document has no actions for IANA.
   このドキュメントはIANAに何も求めません。

3.  Examples
3.  例

3.1.  Simple example
3.1.  簡単な例

   The following example shows:

   o  *foobot*: A regular case.  A single user-agent token followed by
      rules.
      *foobot*: 普通の事例です。単一のユーザーエージェントトークンと
      それに続くルール。
   o  *barbot and bazbot*: A group that's relevant for more than one
      user-agent.
      *barbot and bazbot*:複数のユーザーエージェントに関連するグループ。
   o  *quxbot:* Empty group at end of file.
      *quxbot:* ファイルの終わりの空のグループ。

Koster, et al.           Expires January 9, 2020                [Page 8]

Internet-Draft                     I-D                         July 2019

   <CODE BEGINS>
   User-Agent : foobot
   Disallow : /example/page.html
   Disallow : /example/disallowed.gif

   User-Agent : barbot
   User-Agent : bazbot
   Allow : /example/page.html
   Disallow : /example/disallowed.gif

   User-Agent: quxbot

   EOF
   <CODE ENDS>

3.2.  Longest Match
3.2.  最長一致

   The following example shows that in the case of a two rules, the
   longest one MUST be used for matching.  In the following case,
   /example/page/disallowed.gif MUST be used for the URI
   example.com/example/page/disallow.gif .
   次の例は、2つの規則の内で、最長一致を使用しなければならない
   (MUST)ことを示しています。 次の場合、URI 
   example.com/example/page/disallow.gifで
   /example/page/disallowed.gifを使用する必要があります。

   <CODE BEGINS>
   User-Agent : foobot
   Allow : /example/page/
   Disallow : /example/page/disallowed.gif
   <CODE ENDS>

4.  References
4.  参考文献

4.1.  Normative References
4.1.  参照する参考文献

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 2119, May 2017.

4.2.  URIs

   [1] https://tools.ietf.org/html/rfc3986

   [2] https://tools.ietf.org/html/rfc8288

   [3] https://tools.ietf.org/html/rfc5234

   [4] https://www.sitemaps.org/index.html

   [5] https://tools.ietf.org/html/rfc3629

   [6] https://tools.ietf.org/html/rfc2046

Koster, et al.           Expires January 9, 2020                [Page 9]

Internet-Draft                     I-D                         July 2019

   [7] https://tools.ietf.org/html/rfc1945

   [8] https://tools.ietf.org/html/rfc2616

Authors' Address
著者のアドレス


   Martijn Koster
   Stalworthy Manor Farm
   Suton Lane, NR18 9JG
   Wymondham, Norfolk
   United Kingdom
   Email: m.koster@greenhills.co.uk

   Gary Illyes
   Brandschenkestrasse 110
   8002, Zurich
   Switzerland
   Email: garyillyes@google.com

   Henner Zeller
   1600 Amphitheatre Pkwy
   Mountain View, CA 94043
   USA
   Email: henner@google.com

   Lizzi Harvey
   1600 Amphitheatre Pkwy
   Mountain View, CA 94043
   USA
   Email: lizzi@google.com



Koster, et al.           Expires January 9, 2020               [Page 10]

Japanese translation by Ishida So