RFC4505 日本語訳

Network Working Group                                   K. Zeilenga, Ed.
Request for Comments: 4505                           OpenLDAP Foundation
Obsoletes: 2245                                                June 2006
Category: Standards Track

ワーキンググループK.Zeilenga、エドをネットワークでつないでください。コメントのために以下を要求してください。 4505年のOpenLDAP財団は以下を時代遅れにします。 2245 2006年6月のカテゴリ: 標準化過程

  Anonymous Simple Authentication and Security Layer (SASL) Mechanism

匿名の簡易認証とセキュリティ層(SASL)のメカニズム

Status of This 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 (2006).

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

Abstract

要約

   On the Internet, it is common practice to permit anonymous access to
   various services.  Traditionally, this has been done with a plain-
   text password mechanism using "anonymous" as the user name and using
   optional trace information, such as an email address, as the
   password.  As plain-text login commands are not permitted in new IETF
   protocols, a new way to provide anonymous login is needed within the
   context of the Simple Authentication and Security Layer (SASL)
   framework.

インターネットにおける、様々なサービスへの匿名のアクセスを可能にするのは、一般的な習慣です。 伝統的に、ユーザ名としての「匿名」の明瞭なテキストパスワードメカニズム使用と任意のトレース情報を使用するのにこれをしました、Eメールアドレスのように、パスワードとして。 プレーンテキストログインコマンドが新しいIETFプロトコルで受入れられないとき、匿名のログインを提供する新しい方法がSimple AuthenticationとSecurity Layer(SASL)フレームワークの文脈の中で必要です。

1.  Introduction

1. 序論

   This document defines an anonymous mechanism for the Simple
   Authentication and Security Layer ([SASL]) framework.  The name
   associated with this mechanism is "ANONYMOUS".

このドキュメントはSimple AuthenticationとSecurity Layer([SASL])フレームワークのために匿名のメカニズムを定義します。 このメカニズムに関連している名前は「匿名です」。

   Unlike many other SASL mechanisms, whose purpose is to authenticate
   and identify the user to a server, the purpose of this SASL mechanism
   is to allow the user to gain access to services or resources without
   requiring the user to establish or otherwise disclose their identity
   to the server.  That is, this mechanism provides an anonymous login
   method.

目的は、それのためにサーバにユーザを認証して、特定することです。他の多くのSASLメカニズムと異なって、このSASLメカニズムの目的はユーザが彼らのアイデンティティを確立するか、またはそうでなければ、明らかにする必要でないユーザがサービスかリソースへのアクセスをサーバに得るのを許容することです。すなわち、このメカニズムは匿名のログインメソッドを前提とします。

   This mechanism does not provide a security layer.

このメカニズムはセキュリティ層を提供しません。

   This document replaces RFC 2245.  Changes since RFC 2245 are detailed
   in Appendix A.

このドキュメントはRFC2245を取り替えます。 RFC2245以来の変化はAppendix Aで詳細です。

Zeilenga                    Standards Track                     [Page 1]

RFC 4505                Anonymous SASL Mechanism               June 2006

SASLメカニズム2006年6月の匿名のZeilenga標準化過程[1ページ]RFC4505

2.  The Anonymous Mechanism

2. 匿名のメカニズム

   The mechanism consists of a single message from the client to the
   server.  The client may include in this message trace information in
   the form of a string of [UTF-8]-encoded [Unicode] characters prepared
   in accordance with [StringPrep] and the "trace" stringprep profile
   defined in Section 3 of this document.  The trace information, which
   has no semantical value, should take one of two forms: an Internet
   email address, or an opaque string that does not contain the '@'
   (U+0040) character and that can be interpreted by the system
   administrator of the client's domain.  For privacy reasons, an
   Internet email address or other information identifying the user
   should only be used with permission from the user.

メカニズムはただ一つのクライアントからサーバまでのメッセージから成ります。クライアントは[StringPrep]に従ってコード化された[ユニコード]キャラクタが準備した[UTF-8]のストリングのフォームとこのドキュメントのセクション3で定義された「跡」stringprepプロフィールでこのメッセージで跡の情報を入れるかもしれません。 トレース情報(どんな意味値も持っていない)は2つのフォームの1つを取るべきです: インターネットEメールアドレス、または'@'(U+0040)キャラクタを含まないで、クライアントのドメインのシステム管理者が解釈できる不透明なストリング。 プライバシー理由のために、ユーザを特定するインターネットEメールアドレスか他の情報が許可と共にユーザから使用されるだけであるべきです。

   A server that permits anonymous access will announce support for the
   ANONYMOUS mechanism and allow anyone to log in using that mechanism,
   usually with restricted access.

匿名のアクセスを可能にするサーバは、更生会メカニズムのサポートを発表して、そのメカニズムを使用することでログインするためにだれでも許容するでしょう、通常制限されたアクセサリーで

   A formal grammar for the client message using Augmented BNF [ABNF] is
   provided below as a tool for understanding this technical
   specification.

この技術仕様書を理解するためのツールとしてAugmented BNF[ABNF]を使用するクライアントメッセージのための形式文法を以下に提供します。

      message     = [ email / token ]
                    ;; to be prepared in accordance with Section 3

メッセージ=[メール/トークン]。 セクション3によると、準備されるために

      UTF1        = %x00-3F / %x41-7F ;; less '@' (U+0040)
      UTF2        = %xC2-DF UTF0
      UTF3        = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
                    %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
      UTF4        = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
                    %xF4 %x80-8F 2(UTF0)
      UTF0        = %x80-BF

UTF1は%x00とx41-7-3F/%F等しいです。 より少ない'@'(U+0040)UTF2=%xC2-DF UTF0 UTF3=%xE0%xA0-BF UTF0/%、xE1EC2(UTF0)/%xED%x80-9F UTF0/%xEE-EF2(UTF0)UTF4=%xF0%x90-BF2(UTF0)/%xF1-F3 3(UTF0)/%xF4%x80-8F2(UTF0)UTF0=%x80-BF

      TCHAR       = UTF1 / UTF2 / UTF3 / UTF4
                    ;; any UTF-8 encoded Unicode character
                    ;; except '@' (U+0040)

TCHARはUTF1/UTF2/UTF3/UTF4と等しいです。 どんなUTF-8もユニコード文字をコード化しました。 '@'を除いて(U+0040)

      email       = addr-spec
                    ;; as defined in [IMAIL]

メールはaddr-仕様と等しいです。 定義されたコネとして[IMAIL]

      token       = 1*255TCHAR

トークン=1*255TCHAR

   Note to implementors:
      The <token> production is restricted to 255 UTF-8-encoded Unicode
      characters.  As the encoding of a characters uses a sequence of 1
      to 4 octets, a token may be as long as 1020 octets.

作成者に以下に注意してください。 <トークン>生産はコード化された255UTF8ユニコード文字に制限されます。 キャラクタのコード化が1〜4つの八重奏の系列を使用するとき、トークンは1020の八重奏と同じくらい長いかもしれません。

Zeilenga                    Standards Track                     [Page 2]

RFC 4505                Anonymous SASL Mechanism               June 2006

SASLメカニズム2006年6月の匿名のZeilenga標準化過程[2ページ]RFC4505

3.  The "trace" Profile of "Stringprep"

3. "Stringprep"の「跡」プロフィール

   This section defines the "trace" profile of [StringPrep].  This
   profile is designed for use with the SASL ANONYMOUS Mechanism.
   Specifically, the client is to prepare the <message> production in
   accordance with this profile.

このセクションは[StringPrep]の「跡」プロフィールを定義します。 このプロフィールはSASL ANONYMOUS Mechanismとの使用のために設計されています。 明確に、このプロフィールによると、クライアントは<メッセージ>生産を準備することになっています。

   The character repertoire of this profile is Unicode 3.2 [Unicode].

このプロフィールのキャラクタレパートリーはユニコード3.2です[ユニコード]。

   No mapping is required by this profile.

写像はこのプロフィールによって必要とされません。

   No Unicode normalization is required by this profile.

ユニコード正常化は全くこのプロフィールによって必要とされません。

   The list of unassigned code points for this profile is that provided
   in Appendix A of [StringPrep].  Unassigned code points are not
   prohibited.

割り当てられなかったコード・ポイントのリストは、このプロフィールがそれであるので、[StringPrep]のAppendix Aに供給されました。 割り当てられなかったコード・ポイントは禁止されていません。

   Characters from the following tables of [StringPrep] are prohibited:

[StringPrep]の以下のテーブルからのキャラクターは禁止されています:

      - C.2.1 (ASCII control characters)
      - C.2.2 (Non-ASCII control characters)
      - C.3 (Private use characters)
      - C.4 (Non-character code points)
      - C.5 (Surrogate codes)
      - C.6 (Inappropriate for plain text)
      - C.8 (Change display properties are deprecated)
      - C.9 (Tagging characters)

- C.2.1(ASCII制御文字)--C.2.2(非ASCII制御文字)--C.3(私用キャラクタ)--C.4(非キャラクタコード・ポイント)--C.5(代理のコード)--C.6(プレーンテキストに、不適当な)--C.8(変化ディスプレイの特性は推奨しない)--C.9(タグ付けキャラクタ)

   No additional characters are prohibited.

添字は全く禁止されていません。

   This profile requires bidirectional character checking per Section 6
   of [StringPrep].

このプロフィールはセクション6単位でチェックする双方向のキャラクタに[StringPrep]を要求します。

4.  Example

4. 例

   Here is a sample ANONYMOUS login between an IMAP client and server.
   In this example, "C:" and "S:" indicate lines sent by the client and
   server, respectively.  If such lines are wrapped without a new "C:"
   or "S:" label, then the wrapping is for editorial clarity and is not
   part of the command.

. IMAPクライアントとサーバの間のサンプル更生会ログインがここでの、コネである、この例、「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。 そのような系列が新しいaなしで包装される、「C:」 または、「S:」 次に、ラベル、ラッピングは、編集の明快ためにあって、コマンドの一部ではありません。

   Note that this example uses the IMAP profile [IMAP4] of SASL.  The
   base64 encoding of challenges and responses as well as the "+ "
   preceding the responses are part of the IMAP4 profile, not part of
   SASL itself.  Additionally, protocols with SASL profiles permitting
   an initial client response will be able to avoid the extra round trip
   below (the server response with an empty "+ ").

この例がSASLのIMAPプロフィール[IMAP4]を使用することに注意してください。 挑戦と応答が応答に先行する「+」と同じくらいよくコード化されると分けられるSASLの一部ではなく、IMAP4プロフィール自体のbase64。 さらに、SASLプロフィールが初期のクライアント応答を可能にしているプロトコルは(空の「+」があるサーバ応答)の下で付加的な周遊旅行を避けることができるでしょう。

Zeilenga                    Standards Track                     [Page 3]

RFC 4505                Anonymous SASL Mechanism               June 2006

SASLメカニズム2006年6月の匿名のZeilenga標準化過程[3ページ]RFC4505

   In this example, the trace information is "sirhc".

この例では、トレース情報は"sirhc"です。

      S: * OK IMAP4 server ready
      C: A001 CAPABILITY
      S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=ANONYMOUS
      S: A001 OK done
      C: A002 AUTHENTICATE ANONYMOUS
      S: +
      C: c2lyaGM=
      S: A003 OK Welcome, trace information has been logged.

S: * OK IMAP4のサーバ持ち合わせのC: A001能力S: * 能力IMAP4 IMAP4rev1 AUTH=ダイジェスト-MD5 AUTHは匿名のSと等しいです: Cが行われたA001 OK: A002は匿名のSを認証します: + C: c2lyaGMはSと等しいです: A003 OK Welcome、トレース情報を登録してあります。

5.  Security Considerations

5. セキュリティ問題

   The ANONYMOUS mechanism grants access to services and/or resources by
   anyone.  For this reason, it should be disabled by default so that
   the administrator can make an explicit decision to enable it.

更生会メカニズムはだれでもサービス、そして/または、リソースへのアクセスを承諾します。 この理由で、それは、管理者がそれを可能にするという明白な決定をすることができるように、デフォルトで無効にされるべきです。

   If the anonymous user has any write privileges, a denial-of-service
   attack is possible by filling up all available space.  This can be
   prevented by disabling all write access by anonymous users.

匿名のユーザがいずれかに特権を書かせるなら、サービス不能攻撃はすべての利用可能なスペースをふさぐことによって、可能です。 すべてが匿名のユーザによるアクセスを書く無効にすることでこれを防ぐことができます。

   If anonymous users have read and write access to the same area, the
   server can be used as a communication mechanism to exchange
   information anonymously.  Servers that accept anonymous submissions
   should implement the common "drop box" model, which forbids anonymous
   read access to the area where anonymous submissions are accepted.

匿名のユーザが読んで、同じ領域へのアクセスを書くなら、匿名で情報交換するのにコミュニケーションメカニズムとしてサーバを使用できます。 匿名の差出を受け入れるサーバは一般的な「荷物回収」モデルを実装するべきです。(モデルは匿名の差出が受け入れられる領域への匿名の読書アクセスを禁じます)。

   If the anonymous user can run many expensive operations (e.g., an
   IMAP SEARCH BODY command), this could enable a denial-of-service
   attack.  Servers are encouraged to reduce the priority of anonymous
   users or limit their resource usage.

匿名のユーザが多くの高価なオペレーション(例えば、IMAP SEARCH BODYコマンド)を実施できるなら、これはサービス不能攻撃を可能にするかもしれません。 サーバは、匿名のユーザの優先権を低下させるか、または彼らのリソース用法を制限するよう奨励されます。

   While servers may impose a limit on the number of anonymous users,
   note that such limits enable denial-of-service attacks and should be
   used with caution.

サーバが匿名のユーザの数で指し値するかもしれない間、そのような限界がサービス不能攻撃を可能にして、慎重に使用されるべきであることに注意してください。

   The trace information is not authenticated, so it can be falsified.
   This can be used as an attempt to get someone else in trouble for
   access to questionable information.  Administrators investigating
   abuse need to realize that this trace information may be falsified.

トレース情報が認証されないので、それを改竄できます。 他の誰かが疑わしい情報へのアクセスにおいて困ったことになるようになる試みとしてこれを使用できます。 乱用を調査している管理者は、このトレース情報が改竄されるかもしれないとわかる必要があります。

   A client that uses the user's correct email address as trace
   information without explicit permission may violate that user's
   privacy.  Anyone who accesses an anonymous archive on a sensitive
   subject (e.g., sexual abuse) likely has strong privacy needs.
   Clients should not send the email address without the explicit
   permission of the user and should offer the option of supplying no
   trace information, thus only exposing the source IP address and time.

トレース情報として明白な許可なしでユーザの正しいEメールアドレスを使用するクライアントはそのユーザのプライバシーに違反するかもしれません。 デリケートな話題(例えば、性的虐待)に関する匿名のアーカイブにアクセスするだれでもおそらく強いプライバシーの必要性を持っています。 クライアントは、ユーザの明白な許可なしでEメールアドレスを送るべきでなくて、トレース情報を全く提供しないオプションを提供するべきです、その結果、ソースIPにアドレスと時間を暴露するだけです。

Zeilenga                    Standards Track                     [Page 4]

RFC 4505                Anonymous SASL Mechanism               June 2006

SASLメカニズム2006年6月の匿名のZeilenga標準化過程[4ページ]RFC4505

   Anonymous proxy servers could enhance this privacy but would have to
   consider the resulting potential denial-of-service attacks.

匿名のプロキシサーバは、このプライバシーを高めることができましたが、結果になるのが潜在的サービス不能攻撃であると考えなければならないでしょう。

   Anonymous connections are susceptible to man-in-the-middle attacks
   that view or alter the data transferred.  Clients and servers are
   encouraged to support external data security services.

匿名の接続は移されたデータを見るか、または変更する介入者攻撃に影響されやすいです。 クライアントとサーバが外部のデータ機密保護サービスをサポートするよう奨励されます。

   Protocols that fail to require an explicit anonymous login are more
   susceptible to break-ins given certain common implementation
   techniques.  Specifically, Unix servers that offer user login may
   initially start up as root and switch to the appropriate user id
   after an explicit login command.  Normally, such servers refuse all
   data access commands prior to explicit login and may enter a
   restricted security environment (e.g., the Unix chroot(2) function)
   for anonymous users.  If anonymous access is not explicitly
   requested, the entire data access machinery is exposed to external
   security attacks without the chance for explicit protective measures.
   Protocols that offer restricted data access should not allow
   anonymous data access without an explicit login step.

不法侵入には、ある一般的な実装のテクニックを考えて、明白な匿名のログインを必要としないプロトコルは、より影響されやすいです。 明確に、ユーザログインを提供するUnixサーバーは、明白なログインコマンドの後に初めは、根として始動して、適切なユーザイドに切り替わるかもしれません。 通常、そのようなサーバは、明白なログインの前にすべてのデータ・アクセス命令を拒否して、匿名のユーザのために、制限された治安環境(例えば、Unix chroot(2)機能)に入るかもしれません。 匿名のアクセスが明らかに要求されないなら、全体のデータ・アクセス機械は明白な保護処分のために機会なしで対外安全保障攻撃に暴露されます。 秘密データアクセスを提供するプロトコルは明白なログイン手順なしで匿名のデータ・アクセスを許容するべきではありません。

   General [SASL] security considerations apply to this mechanism.

一般[SASL]セキュリティ問題はこのメカニズムに適用されます。

   [StringPrep] security considerations and [Unicode] security
   considerations discussed in [StringPrep] apply to this mechanism.
   [UTF-8] security considerations also apply.

[StringPrep]セキュリティ問題と[StringPrep]で議論した[ユニコード]セキュリティ問題はこのメカニズムに適用されます。 また、[UTF-8]セキュリティ問題は適用されます。

6.  IANA Considerations

6. IANA問題

   The SASL Mechanism registry [IANA-SASL] entry for the ANONYMOUS
   mechanism has been updated by the IANA to reflect that this document
   now provides its technical specification.

更生会メカニズムのためのSASL Mechanism登録[IANA-SASL]エントリーは、このドキュメントが現在技術仕様書を提供するのを反映するためにIANAによってアップデートされました。

      To: iana@iana.org
      Subject: Updated Registration of SASL mechanism ANONYMOUS

To: iana@iana.org Subject: SASLメカニズム更生会のアップデートされたRegistration

      SASL mechanism name: ANONYMOUS
      Security considerations: See RFC 4505.
      Published specification (optional, recommended): RFC 4505
      Person & email address to contact for further information:
           Kurt Zeilenga <Kurt@OpenLDAP.org>
           Chris Newman <Chris.Newman@sun.com>
      Intended usage: COMMON
      Author/Change controller: IESG <iesg@ietf.org>
      Note: Updates existing entry for ANONYMOUS

SASLメカニズム名: 更生会Security問題: RFC4505を見てください。 広められた仕様(任意の、そして、お勧めの): 詳細のために連絡するRFC4505PersonとEメールアドレス: カート Zeilenga <Kurt@OpenLDAP.org 、gt;、クリス Newman <Chris.Newman@sun.com 、gt;、意図している用法: COMMON Author/変化コントローラ: IESG <iesg@ietf.org 、gt;、注意: 更生会のために既存のエントリーをアップデートします。

Zeilenga                    Standards Track                     [Page 5]

RFC 4505                Anonymous SASL Mechanism               June 2006

SASLメカニズム2006年6月の匿名のZeilenga標準化過程[5ページ]RFC4505

   The [StringPrep] profile "trace", first defined in this RFC, has been
   registered:

「跡」という最初にこのRFCで定義された[StringPrep]プロフィールは登録されました:

      To: iana@iana.org
      Subject: Initial Registration of Stringprep "trace" profile

To: iana@iana.org Subject: Stringprep「跡」プロフィールの初期のRegistration

      Stringprep profile: trace
      Published specification: RFC 4505
      Person & email address to contact for further information:
          Kurt Zeilenga <kurt@openldap.org>

Stringprepは以下の輪郭を描きます。 Published仕様をたどってください: 詳細のために連絡するRFC4505PersonとEメールアドレス: カート Zeilenga <kurt@openldap.org 、gt。

7.  Acknowledgement

7. 承認

   This document is a revision of RFC 2245 by Chris Newman.  Portions of
   the grammar defined in Section 1 were borrowed from RFC 3629 by
   Francois Yergeau.

このドキュメントはクリス・ニューマンによるRFC2245の改正です。 セクション1で定義された文法の部分はフランソアYergeauによってRFC3629から借りられました。

   This document is a product of the IETF SASL WG.

このドキュメントはIETF SASL WGの製品です。

8.  Normative References

8. 引用規格

   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", RFC 4234, October 2005.

[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

   [IMAIL]      Resnick, P., "Internet Message Format", RFC 2822, April
                2001.

[IMAIL] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。

   [SASL]       Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
                Authentication and Security Layer (SASL)", RFC 4422,
                June 2006.

エド[SASL]メリニコフ、A.、K.Zeilenga、エド、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、6月2006日

   [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
                Internationalized Strings ('stringprep')", RFC 3454,
                December 2002.

[StringPrep] ホフマンとP.とM.Blanchet、「国際化しているストリング('stringprep')の準備」、RFC3454、2002年12月。

   [Unicode]    The Unicode Consortium, "The Unicode Standard, Version
                3.2.0" is defined by "The Unicode Standard, Version 3.0"
                (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
                as amended by the "Unicode Standard Annex #27: Unicode
                3.1" (http://www.unicode.org/reports/tr27/) and by the
                "Unicode Standard Annex #28: Unicode 3.2"
                (http://www.unicode.org/reports/tr28/).

[ユニコード] ユニコードConsortium、「ユニコード規格、バージョン、3.2、0インチ、定義される、「ユニコード規格、修正されるバージョン3インチ(読書、MA、アディソン-ウエスリー、2000ISBN0-201-61633-5)、「ユニコード規格別館#27:」 「ユニコード規格別館#28:」 ユニコード3.2インチ( http://www.unicode.org/reports/tr28/ )。

   [UTF-8]      Yergeau, F., "UTF-8, a transformation format of ISO
                10646", RFC 3629 (also STD 63), November 2003.

[UTF-8]Yergeau、2003年11月のF.、「UTF-8、ISO10646の変換形式」RFC3629(STD63も)。

Zeilenga                    Standards Track                     [Page 6]

RFC 4505                Anonymous SASL Mechanism               June 2006

SASLメカニズム2006年6月の匿名のZeilenga標準化過程[6ページ]RFC4505

9.  Informative References

9. 有益な参照

   [IMAP4]      Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
                4rev1", RFC 3501, March 2003.

[IMAP4] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」

   [IANA-SASL]  IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
                MECHANISMS", <http://www.iana.org/assignments/sasl-
                mechanisms>.

[IANA-SASL]IANA、「簡易認証とセキュリティ層(SASL)のメカニズム」、<http://www.iana.org/課題/saslメカニズム>。

Zeilenga                    Standards Track                     [Page 7]

RFC 4505                Anonymous SASL Mechanism               June 2006

SASLメカニズム2006年6月の匿名のZeilenga標準化過程[7ページ]RFC4505

Appendix A.  Changes since RFC 2245

RFC2245以来の付録A.変化

   This appendix is non-normative.

この付録は非規範的です。

   RFC 2245 allows the client to include optional trace information in
   the form of a human readable string.  RFC 2245 restricted this string
   to US-ASCII.  As the Internet is international, this document uses a
   string restricted to UTF-8 encoded Unicode characters.  A
   "stringprep" profile is defined to precisely define which Unicode
   characters are allowed in this string.  While the string remains
   restricted to 255 characters, the encoded length of each character
   may now range from 1 to 4 octets.

RFC2245はクライアントに人間の読み込み可能なストリングの形で任意のトレース情報を入れさせます。 RFC2245はこのストリングを米国-ASCIIに制限しました。 インターネットが国際的であるので、ストリングがUTF-8に制限したこのドキュメント用途はユニコード文字をコード化しました。 "stringprep"プロフィールは、どのユニコード文字がこのストリングに許容されているかを正確に定義するために定義されます。 ストリングが255のキャラクタに制限されたままで残っている間、それぞれのキャラクタのコード化された長さは現在、1〜4八重奏から変化するかもしれません。

   Additionally, a number of editorial changes were made.

さらに、多くの編集の変更が行われました。

Editor's Address

エディタのアドレス

   Kurt D. Zeilenga
   OpenLDAP Foundation

カートD.Zeilenga OpenLDAP財団

   EMail: Kurt@OpenLDAP.org

メール: Kurt@OpenLDAP.org

Zeilenga                    Standards Track                     [Page 8]

RFC 4505                Anonymous SASL Mechanism               June 2006

SASLメカニズム2006年6月の匿名のZeilenga標準化過程[8ページ]RFC4505

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

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

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

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

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the 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 provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Zeilenga                    Standards Track                     [Page 9]

Zeilenga標準化過程[9ページ]