RFC3912 日本語訳

3912 WHOIS Protocol Specification. L. Daigle. September 2004. (Format: TXT=7770 bytes) (Obsoletes RFC0954, RFC0812) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          L. Daigle
Request for Comments: 3912                                VeriSign, Inc.
Obsoletes: 954, 812                                       September 2004
Category: Standards Track

Daigleがコメントのために要求するワーキンググループL.をネットワークでつないでください: 3912 ベリサインInc.は以下を時代遅れにします。 954 812 2004年9月のカテゴリ: 標準化過程

                      WHOIS Protocol Specification

WHOISプロトコル仕様

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).

Copyright(C)インターネット協会(2004)。

Abstract

要約

   This document updates the specification of the WHOIS protocol,
   thereby obsoleting RFC 954.  The update is intended to remove the
   material from RFC 954 that does not have to do with the on-the-wire
   protocol, and is no longer applicable in today's Internet.  This
   document does not attempt to change or update the protocol per se, or
   document other uses of the protocol that have come into existence
   since the publication of RFC 954.

このドキュメントはWHOISプロトコルの仕様をアップデートして、その結果、RFC954を時代遅れにします。 アップデートがワイヤの上のプロトコルと関係がない、またもう今日のインターネットで適切でないRFC954から材料を取り除くことを意図します。 このドキュメントは、そういうものとしてプロトコルを変えるか、アップデートする、またはRFC954の公表以来生まれているプロトコルの他の用途を記録するのを試みません。

1.  Introduction

1. 序論

   WHOIS is a TCP-based transaction-oriented query/response protocol
   that is widely used to provide information services to Internet
   users.  While originally used to provide "white pages" services and
   information about registered domain names, current deployments cover
   a much broader range of information services.  The protocol delivers
   its content in a human-readable format.  This document updates the
   specification of the WHOIS protocol, thereby obsoleting RFC 954 [1].

WHOISは情報サービスをインターネットユーザに提供するのに広く使用されるTCPベースのトランザクション指向の質問/応答プロトコルです。 元々登録されたドメイン名のサービスと情報を「ホワイトページ」に提供するのにおいて使用されている間、現在の展開ははるかに広い範囲の情報サービスをカバーしています。 プロトコルは人間が読める形式で内容を提供します。 このドキュメントはWHOISプロトコルの仕様をアップデートして、その結果、RFC954[1]を時代遅れにします。

   For historic reasons, WHOIS lacks many of the protocol design
   attributes, for example internationalisation and strong security,
   that would be expected from any recently-designed IETF protocol.
   This document does not attempt to rectify any of those shortcomings.
   Instead, this memo documents the WHOIS protocol as it is.  In some
   areas, this document does document particular well known shortcomings
   of the WHOIS protocol.  The discussion of possible protocols to carry
   out these functions, with updated capabilities to address the

歴史的な理由で、WHOISは例えば、プロトコルデザイン属性、国際化、および強いセキュリティの多くを欠いて、それはどんな最近設計されたIETFプロトコルからも予想されるでしょう。 このドキュメントは、それらの短所のどれかを正すのを試みません。 代わりに、それがドキュメントであるようにこのメモはWHOISプロトコルを記録します。 いくつかの領域では、このドキュメントがWHOISプロトコルの特定のよく知られている短所を記録します。 これらを行う可能なプロトコルの議論は扱うアップデートされた能力で機能します。

Daigle                      Standards Track                     [Page 1]

RFC 3912              WHOIS Protocol Specification        September 2004

Daigle標準化過程[1ページ]RFC3912WHOISは仕様2004年9月に議定書を作ります。

   shortcomings, is being addressed in a separate IETF activity (CRISP
   Working Group).

短所は別々のIETF活動(CRISP作業部会)で扱うことにされます。

2.  Protocol Specification

2. プロトコル仕様

   A WHOIS server listens on TCP port 43 for requests from WHOIS
   clients.  The WHOIS client makes a text request to the WHOIS server,
   then the WHOIS server replies with text content.  All requests are
   terminated with ASCII CR and then ASCII LF.  The response might
   contain more than one line of text, so the presence of ASCII CR or
   ASCII LF characters does not indicate the end of the response.  The
   WHOIS server closes its connection as soon as the output is finished.
   The closed TCP connection is the indication to the client that the
   response has been received.

WHOISサーバはWHOISクライアントからの要求のためにTCPポート43の上で聴かれます。 WHOISクライアントはテキスト要求をWHOISサーバにして、次に、WHOISサーバはテキスト内容で返答します。 すべての要求がASCII CRと次に、ASCII LFと共に終えられます。 応答が1個以上のテキスト行を含むかもしれないので、ASCII CRかASCII LFキャラクタの存在は応答の終わりを示しません。 出力が完成しているとすぐに、WHOISサーバは接続を終えます。 閉じているTCP接続はクライアントへの応答を受けたという指示です。

3.  Protocol Example

3. プロトコルの例

   If one places a request of the WHOIS server located at whois.nic.mil
   for information about "Smith", the packets on the wire will look
   like:

1つが「スミス」の情報のためにwhois.nic.milに位置するWHOISサーバの要求を置くと、ワイヤの上のパケットに似るでしょう:

   client                           server at whois.nic.mil

whois.nic.milのクライアントサーバ

   open TCP   ---- (SYN) ------------------------------>
              <---- (SYN+ACK) -------------------------
   send query ---- "Smith<CR><LF>" -------------------->
   get answer <---- "Info about Smith<CR><LF>" ---------
              <---- "More info about Smith<CR><LF>" ----
   close      <---- (FIN) ------------------------------
              ----- (FIN) ----------------------------->

開いているTCP---- (syn) ------------------------------><。---- (SYN+ACK) ------------------------- 質問を送ってください。---- 「スミス<CR><LF>」-------------------->は答え<を手に入れます。---- 「スミス<CR><LF>に関するインフォメーション」--------- <、-、-、-- 「スミス<CR><LF>に関する詳しい情報」---- <を閉じてください。---- (フィン) ------------------------------ ----- (フィン) ----------------------------->。

4.  Internationalisation

4. 国際化

   The WHOIS protocol has not been internationalised.  The WHOIS
   protocol has no mechanism for indicating the character set in use.
   Originally, the predominant text encoding in use was US-ASCII.  In
   practice, some WHOIS servers, particularly those outside the USA,
   might be using some other character set either for requests, replies,
   or both.  This inability to predict or express text encoding has
   adversely impacted the interoperability (and, therefore, usefulness)
   of the WHOIS protocol.

WHOISプロトコルは国際的にされていません。 WHOISプロトコルには、使用中の文字集合を示すためのメカニズムが全くありません。 元々、使用中の支配的なテキストコード化は米国-ASCIIでした。 実際には、いくつかのWHOISサーバ(特に米国の外のそれら)が要求、回答、または両方にある他の文字集合を使用しているかもしれません。 テキストコード化を予測できないか、言い表すことができないこのことは逆に、WHOISプロトコルの相互運用性(したがって、有用性)に影響を与えました。

5.  Security Considerations

5. セキュリティ問題

   The WHOIS protocol has no provisions for strong security.  WHOIS
   lacks mechanisms for access control, integrity, and confidentiality.
   Accordingly, WHOIS-based services should only be used for information
   which is non-sensitive and intended to be accessible to everyone.

WHOISプロトコルには、強いセキュリティのための条項が全くありません。 WHOISはアクセスコントロール、保全、および秘密性のためのメカニズムを欠いています。 それに従って、WHOISベースのサービスは、非機密の情報に使用されて、皆にとってアクセスしやすいことを意図するだけであるべきです。

Daigle                      Standards Track                     [Page 2]

RFC 3912              WHOIS Protocol Specification        September 2004

Daigle標準化過程[2ページ]RFC3912WHOISは仕様2004年9月に議定書を作ります。

   The absence of such security mechanisms means this protocol would not
   normally be acceptable to the IETF at the time of this writing.

そのようなセキュリティー対策の欠如は、通常、このプロトコルがこの書くこと時点でIETFに許容できないことを意味します。

6.  Acknowledgements

6. 承認

   Ran Atkinson created an earlier version of this document.  Ken
   Harrenstien, Mary Stahl, and Elizabeth Feinler were the authors of
   the original Draft Standard for WHOIS.

走行、アトキンソンはこのドキュメントの以前のバージョンを作成しました。 ケンHarrenstien、Mary Stahl、およびエリザベスFeinlerはWHOISのためのオリジナルのDraft Standardの作者でした。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [1]  Harrenstien, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC
        954, October 1985.

1985年10月の[1]HarrenstienとK.とスタール、M.とE.Feinler、「NICNAME/WHOIS」RFC954。

Author's Address

作者のアドレス

   Leslie Daigle
   VeriSign, Inc.
   21355 Ridgetop Circle
   Dulles, VA  20166
   US

レスリーDaigleベリサインInc.21355屋根の頂円のヴァージニア20166ダレス(米国)

   EMail: leslie@verisignlabs.com; leslie@thinkingcat.com

メール: leslie@verisignlabs.com; leslie@thinkingcat.com

Daigle                      Standards Track                     [Page 3]

RFC 3912              WHOIS Protocol Specification        September 2004

Daigle標準化過程[3ページ]RFC3912WHOISは仕様2004年9月に議定書を作ります。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

Copyright(C)インターネット協会(2004)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and at www.rfc-editor.org, and except as set
   forth therein, the authors retain all their rights.

このドキュメントはBCP78と、www.rfc-editor.orgに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
   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.

彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。

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 ISOC's procedures with respect to rights in ISOC Documents can
   be found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Daigle                      Standards Track                     [Page 4]

Daigle標準化過程[4ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

北海道の電車路線、駅の一覧

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る