RFC2277 日本語訳

Network Working Group                                     H. Alvestrand
Request for Comments: 2277                                      UNINETT
BCP: 18                                                    January 1998
Category: Best Current Practice

Alvestrandがコメントのために要求するワーキンググループH.をネットワークでつないでください: 2277UNINETT BCP: 1998年1月18日のカテゴリ: 最も良い現在の習慣

              IETF Policy on Character Sets and Languages

文字コードと言語に関するIETF方針

Status of this Memo

このMemoの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

1.  Introduction

1. 序論

   The Internet is international.

インターネットは国際的です。

   With the international Internet follows an absolute requirement to
   interchange data in a multiplicity of languages, which in turn
   utilize a bewildering number of characters.

国際的なインターネットと共に、順番に目まぐるしい数のキャラクタを利用する言語の多様性におけるデータを交換するという絶対条件は続いています。

   This document is the current policies being applied by the Internet
   Engineering Steering Group (IESG) towards the standardization efforts
   in the Internet Engineering Task Force (IETF) in order to help
   Internet protocols fulfill these requirements.

このドキュメントはインターネットプロトコルがこれらの要件を実現させるのを助けるためにインターネットEngineering Steering Group(IESG)によってインターネット・エンジニアリング・タスク・フォース(IETF)で標準化取り組みに向かって適用される通貨政策です。

   The document is very much based upon the recommendations of the IAB
   Character Set Workshop of February 29-March 1, 1996, which is
   documented in RFC 2130 [WR].  This document attempts to be concise,
   explicit and clear; people wanting more background are encouraged to
   read RFC 2130.

ドキュメントは2月29日〜3月1日、RFC2130[WR]に記録される1996年のIAB文字コードWorkshopの推薦にたいへん基づいています。 このドキュメントは、簡潔で、明白で明確であることを試みます。 より多くのバックグラウンドが欲しい人々がRFC2130を読むよう奨励されます。

   The document uses the terms 'MUST', 'SHOULD' and 'MAY', and their
   negatives, in the way described in [RFC 2119].  In this case, 'the
   specification' as used by RFC 2119 refers to the processing of
   protocols being submitted to the IETF standards process.

ドキュメントは[RFC2119]に述べられた方法で用語'MUST'、'SHOULD'、および'5月'、およびそれらのネガを使用します。 この場合、RFC2119によって使用される'仕様'はIETF標準化過程に提出されるプロトコルの処理について言及します。

Alvestrand               Best Current Practice                  [Page 1]

RFC 2277                     Charset Policy                 January 1998

最も良い現在のAlvestrandの練習[1ページ]RFC2277Charset方針1998年1月

2.  Where to do internationalization

2. どこで、国際化しますか。

   Internationalization is for humans. This means that protocols are not
   subject to internationalization; text strings are. Where protocol
   elements look like text tokens, such as in many IETF application
   layer protocols, protocols MUST specify which parts are protocol and
   which are text. [WR 2.2.1.1]

国際化は人間のためのものです。 これは、プロトコルが国際化を被りやすくないことを意味します。 テキスト文字列はそうです。 プロトコル要素が多くのIETF応用層プロトコルなどのテキストトークンに似ているところでは、プロトコルはどの部分がプロトコルであるか、そして、どれがテキストであるかを指定しなければなりません。 [WR2.2.1、.1]

   Names are a problem, because people feel strongly about them, many of
   them are mostly for local usage, and all of them tend to leak out of
   the local context at times. RFC 1958 [RFC 1958] recommends US-ASCII
   for all globally visible names.

名前は問題です、人々が彼らに関して確信して、彼らの多くがほとんどローカルの用法のためのものであり、彼らが皆、時にはローカルの関係から漏れる傾向があるので。 RFC1958[RFC1958]はすべてのグローバルに目に見える名前のための米国-ASCIIを推薦します。

   This document does not mandate a policy on name internationalization,
   but requires that all protocols describe whether names are
   internationalized or US-ASCII.

このドキュメントは、名前国際化に関する方針を強制しませんが、すべてのプロトコルが名前が国際的にされるか、そして、米国-ASCIIについて説明するのを必要とします。

   NOTE: In the protocol stack for any given application, there is
   usually one or a few layers that need to address these problems.

以下に注意してください。 どんな与えられたアプリケーションのためのプロトコル・スタックではも、これらのその問題を訴える必要がある通常ものかいくつかの層があります。

   It would, for instance, not be appropriate to define language tags
   for Ethernet frames. But it is the responsibility of the WGs to
   ensure that whenever responsibility for internationalization is left
   to "another layer", those responsible for that layer are in fact
   aware that they HAVE that responsibility.

例えば、言語タグをイーサネットフレームと定義するのは適切でないでしょう。 しかし、事実上、国際化への責任が「別の層」に残されるときはいつも、その層に責任があるそれらが意識しているのを保証するのが、WGsの責任である、それ、彼ら、HAVE、その責任。

3.  Definition of Terms

3. 用語の定義

   This document uses the term "charset" to mean a set of rules for
   mapping from a sequence of octets to a sequence of characters, such
   as the combination of a coded character set and a character encoding
   scheme; this is also what is used as an identifier in MIME "charset="
   parameters, and registered in the IANA charset registry [REG].  (Note
   that this is NOT a term used by other standards bodies, such as ISO).

このドキュメントはマッピングのために八重奏の系列からキャラクタの系列まで1セットの規則を意味するのに"charset"という用語を使用します、1つのコード化文字集合の組み合わせや文字符号化体系のように。 また、これは識別子としてMIME「charset=」パラメタで使用されて、IANA charset登録[REG]に登録されることです。 (これがISOなどの他の標準化団体によって使用される用語でないことに注意します。)

   For a definition of the term "coded character set", refer to the
   workshop report.

「コード化文字集合」という用語の定義について、ワークショップレポートを参照してください。

   A "name" is an identifier such as a person's name, a hostname, a
   domainname, a filename or an E-mail address; it is often treated as
   an identifier rather than as a piece of text, and is often used in
   protocols as an identifier for entities, without surrounding text.

「名前」は人の名前、ホスト名、ドメイン名、ファイル名またはEメールアドレスなどの識別子です。 それは、1つのテキストとしてというよりむしろ識別子としてしばしば扱われて、実体に識別子としてプロトコルにしばしば使用されます、周囲のテキストなしで。

3.1.  What charset to use

3.1. どんなcharsetを使用したらよいですか。

   All protocols MUST identify, for all character data, which charset is
   in use.

すべてのプロトコルが、すべてのキャラクタデータのためにどのcharsetが使用中であるかを特定しなければなりません。

Alvestrand               Best Current Practice                  [Page 2]

RFC 2277                     Charset Policy                 January 1998

最も良い現在のAlvestrandの練習[2ページ]RFC2277Charset方針1998年1月

   Protocols MUST be able to use the UTF-8 charset, which consists of
   the ISO 10646 coded character set combined with the UTF-8 character
   encoding scheme, as defined in [10646] Annex R (published in
   Amendment 2), for all text.

プロトコルはUTF-8文字符号化体系に結合されたISO10646コード化文字集合から成るUTF-8 charsetを使用できなければなりません、[10646] 別館R(Amendment2では、発行されます)で定義されるように、すべてのテキストのために。

   Protocols MAY specify, in addition, how to use other charsets or
   other character encoding schemes for ISO 10646, such as UTF-16, but
   lack of an ability to use UTF-8 is a violation of this policy; such a
   violation would need a variance procedure ([BCP9] section 9) with
   clear and solid justification in the protocol specification document
   before being entered into or advanced upon the standards track.

プロトコルは指定するかもしれません、さらに、ISO10646にどう他のcharsetsか他の文字符号化体系を使用するか、UTF-16などのように、しかし、UTF-8を使用する能力の不足はこの方針の違反です。 そのような違反は標準化過程で入られるか、または高度である前に、プロトコル仕様ドキュメントにおける明確で確実な正当化がある変化の手順([BCP9]セクション9)を必要とするでしょう。

   For existing protocols or protocols that move data from existing
   datastores, support of other charsets, or even using a default other
   than UTF-8, may be a requirement. This is acceptable, but UTF-8
   support MUST be possible.

既存のdatastoresからデータを動かす既存のプロトコルかプロトコルのために、他のcharsetsのサポート、またはUTF-8を除いて、デフォルトを使用さえするのが、要件であるかもしれません。 これは許容できますが、UTF-8サポートは可能であるに違いありません。

   When using other charsets than UTF-8, these MUST be registered in the
   IANA charset registry, if necessary by registering them when the
   protocol is published.

UTF-8以外のcharsetsを使用するとき、IANA charset登録にこれらを登録しなければなりません、プロトコルが発表されるとき必要なら、それらを登録することによって。

   (Note: ISO 10646 calls the UTF-8 CES a "Transformation Format" rather
   than a "character encoding scheme", but it fits the charset workshop
   report definition of a character encoding scheme).

(注意: ISO10646は、UTF-8 CESを「文字符号化体系」よりむしろ「変換形式」と呼びますが、それは文字符号化体系のcharsetワークショップレポート定義に合います)。

3.2.  How to decide a charset

3.2. charsetについて決める方法

   When the protocol allows a choice of multiple charsets, someone must
   make a decision on which charset to use.

プロトコルが複数のcharsetsの選択を許すとき、だれかがどのcharsetを使用したらよいかに関して決定しなければなりません。

   In some cases, like HTTP, there is direct or semi-direct
   communication between the producer and the consumer of data
   containing text. In such cases, it may make sense to negotiate a
   charset before sending data.

いくつかの場合、生産者とデータの消費者とのテキストを含むコミュニケーションがHTTPにダイレクトであるか、または半直接で似ています。 そのような場合、それはデータを送る前にcharsetを交渉する意味になるかもしれません。

   In other cases, like E-mail or stored data, there is no such
   communication, and the best one can do is to make sure the charset is
   clearly identified with the stored data, and choosing a charset that
   is as widely known as possible.

他の場合では、メールか記憶されたデータに、どんなそのようなコミュニケーションも似ていません、そして、ものが尽くすことができるベストはcharsetが明確に同じくらい記憶されたデータと、広く知られているとしてあるcharsetを同じくらい選ぶのと可能な同一視されているのを確実にすることです。

   Note that a charset is an absolute; text that is encoded in a charset
   cannot be rendered comprehensibly without supporting that charset.

charsetが絶対的なものであることに注意してください。 そのcharsetをサポートしないで、charsetでコード化されるテキストはcomprehensiblyに表すことができません。

   (This also applies to English texts; charsets like EBCDIC do NOT have
   ASCII as a proper subset)

(また、これは英文に適用されます; EBCDICのようなcharsetsには、真部分集合としてASCIIがありません)

Alvestrand               Best Current Practice                  [Page 3]

RFC 2277                     Charset Policy                 January 1998

最も良い現在のAlvestrandの練習[3ページ]RFC2277Charset方針1998年1月

   Negotiating a charset may be regarded as an interim mechanism that is
   to be supported until support for interchange of UTF-8 is prevalent;
   however, the timeframe of "interim" may be at least 50 years, so
   there is every reason to think of it as permanent in practice.

charsetを交渉するのはUTF-8の置き換えのサポートが一般的になるまでサポートされることになっている当座のメカニズムと見なされるかもしれません。 しかしながら、「当座」の時間枠が少なくとも50年であるかもしれないので、実際には永久的であるとしてそれを考えるあらゆる理由があります。

4.  Languages

4. 言語

4.1.  The need for language information

4.1. 言語情報の必要性

   All human-readable text has a language.

すべての人間読み込み可能なテキストには、言語があります。

   Many operations, including high quality formatting, text-to-speech
   synthesis, searching, hyphenation, spellchecking and so on benefit
   greatly from access to information about the language of a piece of
   text. [WC 3.1.1.4].

多くの操作、高品質の形式を含んでいて、テキスト音声合成、探すこと、ハイフン付き、spellcheckingなどは大いに1つのテキストの言語の情報へのアクセスの利益を得ます。 [トイレ、3.1 .1 .4]。

   Humans have some tolerance for foreign languages, but are generally
   very unhappy with being presented text in a language they do not
   understand; this is why negotiation of language is needed.

彼らが理解していない言語で外国語のために何らかの寛容に持っていますが、一般に、人間はテキストが提示されるのに非常に不満です。 これは言語の交渉が必要である理由です。

   In most cases, machines will not be able to deduce the language of a
   transmitted text by themselves; the protocol must specify how to
   transfer the language information if it is to be available at all.

多くの場合、マシンは自分たちによる伝えられたテキストの言語を推論できないでしょう。 少しでも利用可能であるつもりであるなら、プロトコルは言語情報を移す方法を指定しなければなりません。

   The interaction between language and processing is complex; for
   instance, if I compare "name-of-thing(lang=en)" to "name-of-
   thing(lang=no)" for equality, I will generally expect a match, while
   the word "ask(no)" is a kind of tree, and is hardly useful as a
   command verb.

言語と処理との相互作用は複雑です。 例えば、私であるなら「ものの名前(langはアンと等しい)」を比較してください、「名前、-、もの、(langはいいえと等しいです) 」 平等には、一般に、私はマッチを予想するつもりです、「尋ねてください(いいえ)」という単語は、一種の木であり、コマンド動詞としてほとんど役に立ちませんが。

4.2.  Requirement for language tagging

4.2. 言語タグ付けのための要件

   Protocols that transfer text MUST provide for carrying information
   about the language of that text.

テキストを移すプロトコルはそのテキストの言語の情報を運ぶのに提供されなければなりません。

   Protocols SHOULD also provide for carrying information about the
   language of names, where appropriate.

また、プロトコルSHOULDは名前の用語の情報を適切であるところまで運ぶのに提供します。

   Note that this does NOT mean that such information must always be
   present; the requirement is that if the sender of information wishes
   to send information about the language of a text, the protocol
   provides a well-defined way to carry this information.

これが、そのような情報がいつも存在していなければならないことを意味しないことに注意してください。 要件は情報の送付者がテキストの言語の情報を送りたいなら、プロトコルがこの情報を運ぶ明確な方法を提供するということです。

Alvestrand               Best Current Practice                  [Page 4]

RFC 2277                     Charset Policy                 January 1998

最も良い現在のAlvestrandの練習[4ページ]RFC2277Charset方針1998年1月

4.3.  How to identify a language

4.3. 言語を特定する方法

   The RFC 1766 language tag is at the moment the most flexible tool
   available for identifying a language; protocols SHOULD use this, or
   provide clear and solid justification for doing otherwise in the
   document.

瞬間にRFC1766言語タグは言語を特定するのに利用可能な最もフレキシブルなツールです。 プロトコルSHOULDはこれを使用するか、または別の方法でするための明確で確実な正当化をドキュメントに供給します。

   Note also that a language is distinct from a POSIX locale; a POSIX
   locale identifies a set of cultural conventions, which may imply a
   language (the POSIX or "C" locale of course do not), while a language
   tag as described in RFC 1766 identifies only a language.

また、言語がPOSIX現場と異なっていることに注意してください。 POSIX現場は1セットの文化的なコンベンションを特定します、RFC1766で説明される言語タグが言語だけを特定しますが。(コンベンションは言語(現場がもちろんそうしないPOSIXか「C」)を含意するかもしれません)。

4.4.  Considerations for language negotiation

4.4. 言語交渉のための問題

   Protocols where users have text presented to them in response to user
   actions MUST provide for support of multiple languages.

ユーザがユーザ動作に対応してテキストを彼らに提示させるプロトコルは複数の言語のサポートに備えなければなりません。

   How this is done will vary between protocols; for instance, in some
   cases, a negotiation where the client proposes a set of languages and
   the server replies with one is appropriate; in other cases, a server
   may choose to send multiple variants of a text and let the client
   pick which one to display.

これがどう完了しているかはプロトコルの間で異なるでしょう。 例えば、いくつかの場合、クライアントが1で1セットの言語とサーバ回答を提案するところで交渉は適切です。 他の場合では、サーバは、テキストの複数の異形を送って、クライアントに表示するためにどれを選ばせるかを選ぶかもしれません。

   Negotiation is useful in the case where one side of the protocol
   exchange is able to present text in multiple languages to the other
   side, and the other side has a preference for one of these; the most
   common example is the text part of error responses, or Web pages that
   are available in multiple languages.

交渉はプロトコル交換の半面が複数の言語のテキストを反対側に提示できる場合で役に立ちます、そして、反対側には、これらの1つの優先があります。 最も一般的な例は複数の言語で利用可能な誤り応答、またはウェブページのテキスト地域です。

   Negotiating a language should be regarded as a permanent requirement
   of the protocol that will not go away at any time in the future.

言語を交渉するのは将来いつでも遠ざからないプロトコルの永久的な要件と見なされるべきです。

   In many cases, it should be possible to include it as part of the
   connection establishment, together with authentication and other
   preferences negotiation.

多くの場合、コネクション確立の一部としてそれを含んでいるのは可能であるべきです、認証と他の好みの交渉と共に。

4.5.  Default Language

4.5. デフォルト言語

   When human-readable text must be presented in a context where the
   sender has no knowledge of the recipient's language preferences (such
   as login failures or E-mailed warnings, or prior to language
   negotiation), text SHOULD be presented in Default Language.

人間読み込み可能なテキストを提示しなければならないとき、Default Languageに送付者が知識を全く持っていない受取人の言語好み(ログイン失敗かメールされた警告か、言語交渉の前の)、テキストSHOULDの文脈では、示されてください。

   Default Language is assigned the tag "i-default" according to the
   procedures of RFC 1766. It is not a specific language, but rather
   identifies the condition where the language preferences of the user
   cannot be established.

RFC1766の手順によると、タグ「i-デフォルト」はデフォルトLanguageに割り当てられます。 それは、特定の言語ではありませんが、むしろ、ユーザの言語好みを確立できない状態を特定します。

Alvestrand               Best Current Practice                  [Page 5]

RFC 2277                     Charset Policy                 January 1998

最も良い現在のAlvestrandの練習[5ページ]RFC2277Charset方針1998年1月

   Messages in Default Language MUST be understandable by an English-
   speaking person, since English is the language which, worldwide, the
   greatest number of people will be able to get adequate help in
   interpreting when working with computers.

人を話して、Default Languageのメッセージはイギリス人を理解できさせるに違いありません、英語がコンピュータで働いているとき解釈することにおいて世界中では、人々の最大数が適切な助けを得ることができる言語であるので。

   Note that negotiating English is NOT the same as Default Language;
   Default Language is an emergency measure in otherwise unmanageable
   situations.

英語を交渉するのがDefault Languageと同じでないことに注意してください。 デフォルトLanguageはそうでなければ、「非-処理しやす」状況で応急処置です。

   In many cases, using only English text is reasonable; in some cases,
   the English text may be augumented by text in other languages.

多くの場合、英文だけを使用するのは妥当です。 いくつかの場合、英文は他の言語のテキストによってaugumentedされるかもしれません。

5.  Locale

5. 現場

   The POSIX standard [POSIX] defines a concept called a "locale", which
   includes a lot of information about collating order for sorting, date
   format, currency format and so on.

POSIX規格[POSIX]はソーティングの注文、日付の形式、通貨形式などを照合することの多くの情報を含んでいる「現場」と呼ばれる概念を定義します。

   In some cases, and especially with text where the user is expected to
   do processing on the text, locale information may be usefully
   attached to the text; this would identify the sender's opinion about
   appropriate rules to follow when processing the document, which the
   recipient may choose to agree with or ignore.

いくつかの場合、そして、特にユーザがテキストで処理をすると予想されるテキストで、現場情報は有効にテキストに添付されるかもしれません。 文書(同意するか、または無視します受取人が、選ぶかもしれない)を処理するとき、これは、続くように適切な規則に関する送付者の意見を特定するでしょう。

   This document does not require the communication of locale
   information on all text, but encourages its inclusion when
   appropriate.

このドキュメントは、すべてのテキストの現場情報に関するコミュニケーションを必要としませんが、適切であるときに、包含を奨励します。

   Note that language and character set information will often be
   present as parts of a locale tag (such as no_NO.iso-8859-1; the
   language is before the underscore and the character set is after the
   dot); care must be taken to define precisely which specification of
   character set and language applies to any one text item.

言語と文字集合情報が現場タグ(_NO.がないiso-8859-1などのように; 強調の前に、言語があります、そして、ドットの後に、文字集合がある)の一部としてしばしば存在することに注意してください。 文字集合と言語のどの仕様が何かテキスト項目に適用されるかを正確に定義するために注意しなければなりません。

   The default locale is the "POSIX" locale.

デフォルト現場は"POSIX"現場です。

6.  Documenting internationalization decisions

6. 国際化決定を記録します。

   In documents that deal with internationalization issues at all, a
   synopsis of the approaches chosen for internationalization SHOULD be
   collected into a section called "Internationalization
   considerations", and placed next to the Security Considerations
   section.

全く国際化問題に対処するドキュメント、国際化SHOULDに選ばれたアプローチの構文では、「国際化問題」と呼ばれて、Security Considerations部の横で置かれたセクションに集められてください。

   This provides an easy reference for those who are looking for advice
   on these issues when implementing the protocol.

これはプロトコルを実装するときこれらの問題に関するアドバイスを探している人の簡単な参照を提供します。

Alvestrand               Best Current Practice                  [Page 6]

RFC 2277                     Charset Policy                 January 1998

最も良い現在のAlvestrandの練習[6ページ]RFC2277Charset方針1998年1月

7.  Security Considerations

7. セキュリティ問題

   Apart from the fact that security warnings in a foreign language may
   cause inappropriate behaviour from the user, and the fact that
   multilingual systems usually have problems with consistency between
   language variants, no security considerations relevant have been
   identified.

外国語のセキュリティ警告がユーザにもかかわらず、通常、多言語システムには言語異形の間の一貫性に関する問題があるという事実、どんなセキュリティ問題からも関連していた状態で不適当なふるまいを引き起こさないかもしれないという事実は別として、特定されてください、そうした。

8.  References

8. 参照

   [10646]
        ISO/IEC, Information Technology - Universal Multiple-Octet Coded
        Character Set (UCS) - Part 1: Architecture and Basic
        Multilingual Plane, May 1993, with amendments

[10646] ISO/IEC、情報技術--普遍的な複数の八重奏コード化文字集合(UCS)--第1部: 修正があるアーキテクチャと基本多言語水準、1993年5月

   [RFC 2119]
        Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [WR] Weider, C., Preston, C., Simonsen, K., Alvestrand, H,
        Atkinson, R., Crispin, M., and P. Svanberg, "The Report of the
        IAB Character Set Workshop held 29 February - 1 March, 1996",
        RFC 2130, April 1997.

[WR] ワイダー、C.、プレストン、C.、シモンセン、K.、Alvestrand、H、アトキンソン、R.、クリスピン、M.、およびP.スバンベルク、「IAB文字コードWorkshopのReportは2月29日に成立しました--1996年3月1日」、RFC2130、1997年4月。

   [RFC 1958]
        Carpenter, B., "Architectural Principles of the Internet", RFC
        1958, June 1996.

[RFC1958] 1996年6月の大工、B.、「インターネットの建築プリンシプルズ」RFC1958。

   [POSIX]
        ISO/IEC 9945-2:1993 Information technology -- Portable Operating
        System Interface (POSIX) -- Part 2: Shell and Utilities

[POSIX]ISO/IEC9945-2: 1993年の情報技術--携帯用のOperating System Interface(POSIX)--第2部: シェルとユーティリティ

   [REG]
        Freed, N., and J. Postel, "IANA Charset Registration
        Procedures", BCP 19, RFC 2278, January 1998.

[REG] フリード、N.、およびJ.ポステル、「IANA Charset登録手順」、BCP19、RFC2278、1月1998。

   [UTF-8]
        Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.

[UTF-8]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。

   [BCP9]
        Bradner, S., "The Internet Standards Process -- Revision 3," BCP
        9, RFC 2026, October 1996.

[BCP9]ブラドナー、S.、「インターネット規格は処理されます--改正3インチ、BCP9、RFC2026、10月1996日。

Alvestrand               Best Current Practice                  [Page 7]

RFC 2277                     Charset Policy                 January 1998

最も良い現在のAlvestrandの練習[7ページ]RFC2277Charset方針1998年1月

9.  Author's Address

9. 作者のアドレス

   Harald Tveit Alvestrand
   UNINETT
   P.O.Box 6883 Elgeseter
   N-7002 TRONDHEIM
   NORWAY

ハラルドTveit Alvestrand UNINETT P.O.Box6883Elgeseter N-7002トロンヘイムノルウェー

   Phone: +47 73 59 70 94
   EMail: Harald.T.Alvestrand@uninett.no

以下に電話をしてください。 +47 73 59 70 94はメールされます: Harald.T.Alvestrand@uninett.no

Alvestrand               Best Current Practice                  [Page 8]

RFC 2277                     Charset Policy                 January 1998

最も良い現在のAlvestrandの練習[8ページ]RFC2277Charset方針1998年1月

10.  Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Alvestrand               Best Current Practice                  [Page 9]

Alvestrandの最も良い現在の習慣[9ページ]