RFC2218 日本語訳
2218 A Common Schema for the Internet White Pages Service. T.Genovese, B. Jennings. October 1997. (Format: TXT=16258 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Genovese
Request for Comments: 2218 Microsoft
Category: Standards Track B. Jennings
Sandia National Laboratory
October 1997
Genoveseがコメントのために要求するワーキンググループT.をネットワークでつないでください: 2218年のマイクロソフトカテゴリ: 研究所1997年10月の国家の標準化過程B.ジョニングスSandia
A Common Schema for the Internet White Pages Service
インターネットホワイトページサービスのための一般的な図式
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This work is the result of the IETF Integrated Directory Services (IDS) Working Group. The IDS Working Group proposes a standard specification for a simple Internet White Pages service by defining a common schema for use by the various White Pages servers. This schema is independent of specific implementations of the White Pages service.
この仕事はIETF Integratedディレクトリサービス(IDS)作業部会の結果です。 IDS作業部会は、使用のために様々なホワイトページサーバで一般的な図式を定義することによって、簡単なインターネットホワイトページサービスのための標準の仕様を提案します。 この図式は特定のホワイトのページサービスの実装から独立しています。
This document specifies the minimum set of core attributes of a White Pages entry for an individual and describes how new objects with those attributes can be defined and published. It does not describe how to represent other objects in the White Pages service. Further, it does not address the search sort expectations within a particular service.
このドキュメントは、最小のセットのホワイトのページエントリーのコア属性を個人に指定して、どうそれらの属性がある新しいオブジェクトを定義して、発行できるかを説明します。 それはホワイトのページサービスで他のオブジェクトを表す方法を説明しません。 さらに、それは、特定のサービスの中で検索種類が期待であると扱いません。
1.0 Introduction to IWPS
1.0 IWPSへの紹介
The Internet community has stated a need for the development and deployment of a White Pages service for use in locating information about people in the Internet [PA94]. To facilitate interoperability and to provide a common user experience, the Internet White Pages Service (IWPS) must have a common set of information about each person.
インターネットコミュニティはインターネット[PA94]で人々の情報の場所を見つけることにおける使用のためのホワイトのページサービスの開発と展開の必要性を述べました。 相互運用性を容易にして、一般的なユーザー・エクスペリエンスを提供するために、インターネットホワイトページService(IWPS)には、各人の一般的な情報がなければなりません。
A common user object would allow a user to go between implementations of the service and to expect consistency in the types of information provided. A common user object would also provide developers with an unambigious method of representing the information managed by the service.
一般的なユーザオブジェクトで、ユーザをサービスの実装を取り持って、情報のタイプの一貫性が提供されたと予想するでしょう。 また、一般的なユーザオブジェクトはサービスで管理された情報を表すunambigiousメソッドを開発者に提供するでしょう。
Genovese & Jennings Standards Track [Page 1] RFC 2218 Common Schema for IWPS October 1997
GenoveseとジョニングスStandardsは1997年10月にIWPSのためにRFC2218の一般的な図式を追跡します[1ページ]。
This document will focus only on common information modeling issues to which all IWPS providers must conform.
このドキュメントはすべてのIWPSプロバイダーが従わなければならない一般的な情報モデリング問題だけに焦点を合わせるでしょう。
2.0 Scope
2.0 範囲
This document establishes the set of attributes that specify the Common User Information Object for the IWPS. It does not attempt to be an exhaustive specification of all objects that may be stored in the IWPS. The process used by this document to define the user object is recommended to be used to define other information objects used in the IWPS.
このドキュメントはCommon User情報ObjectをIWPSに指定する属性のセットを確証します。それは、IWPSに保存されるかもしれないすべてのオブジェクトの徹底的な仕様であることを試みません。IWPSで使用される他の情報オブジェクトを定義するのにこのドキュメントによって使用される、ユーザオブジェクトを定義するプロセスが使用されることが勧められます。
All conforming implementations must support at the minimum, the core attributes listed in Section 5.0. Implementations may include local attributes in addition to the core set and still be considered "in conformance".
実装が最小限、コア属性でサポートしなければならないすべて従うことがセクション5.0に記載しました。 実装は、巻き癖に加えて地方の属性を含んで、「順応」であるとまだ考えられているかもしれません。
This document will not specify rules with respect to information privacy. Each country has its own set of laws and practices. Previous work covering this area has been done by the North American Directory Forum (NADF), whose publication [NADF92] contain recommendations for registrants' rights in both the USA and Canada.
このドキュメントは情報プライバシーに関して規則を指定しないでしょう。 各国には、それ自身の法と習慣のセットがあります。 公表[NADF92]が米国とカナダの両方に記入者の権利のための推薦を保管している北米のディレクトリForum(NADF)はこの領域をカバーする前の仕事を完了していました。
This document does not specify a Directory access protocol (i.e. whois++, LDAP, DAP, etc.).
このドキュメントはディレクトリアクセス・プロトコル(すなわち、whois++、LDAP、DAPなど)を指定しません。
3.0 IWPS Schema Considerations
3.0 IWPS図式問題
The description of the IWPS information object consists of the following requirements:
IWPS情報オブジェクトの記述は以下の要件から成ります:
1. Syntax for definition/representation of information
object templates.
2. Publication of information object templates, etc.
3. Database structure or schema.
1. 情報オブジェクトテンプレートの定義/表現のための構文。 2. 情報オブジェクトテンプレートの公表など 3. データベース構造か図式。
Items 1 and 2 will be covered in this document. Because database structure can potentially restrict implementations (i.e. X.500 schema based versus DNS schema based) it will be treated as a separate research topic and will not be defined in this paper.
項目1と2は本書ではカバーされているでしょう。 データベース構造が潜在的に、実装(すなわち、図式が基礎づけたDNSに対して基づくX.500図式)を制限する場合があるので、それは、別々の研究話題として扱われて、この紙で定義されないでしょう。
4.0 Syntax for Definition/Representation of Information Object
Templates
情報オブジェクトテンプレートの定義/表現のための4.0構文
A clear, precise, and consistent method must be used when discussing information object templates and their associated attributes. Therefore, this document makes uses of the previously defined syntax used by LDAP. To avoid restrictions on implementations of the IWPS,
情報オブジェクトテンプレートとそれらの関連属性について議論するとき、明確で、正確で、一貫したメソッドを使用しなければなりません。 したがって、このドキュメントはLDAPによって使用された以前に定義された構文を利用します。 IWPSの実装で制限を避けるために
Genovese & Jennings Standards Track [Page 2] RFC 2218 Common Schema for IWPS October 1997
GenoveseとジョニングスStandardsは1997年10月にIWPSのためにRFC2218の一般的な図式を追跡します[2ページ]。
some syntax are listed as requirements vs specific encodings. The general IWPS syntax is included in section 6.0 for reference.
何らかの構文が要件として特定のencodingsに対して記載されています。 一般的なIWPS構文は参照のためのセクション6.0に含まれています。
The IWPS Person Object specifies a limited set of recommended attributes that a White Pages Service must include. Storage of user attributes are a local issue, therefore, this memo suggests storage sizes but not storage types.
IWPS Person ObjectはホワイトページServiceが含まなければならない限られたセットのお勧めの属性を指定します。 ユーザ属性のストレージがローカルの問題である、したがって、このメモはストレージタイプではなく、ストレージサイズを示します。
This document lists the syntax with the attributes for developers of user interface (UIs) to use as a reference, but it does not specify how the UI should display these attributes.
このドキュメントはユーザーインタフェース(UIs)の開発者が参照として使用する属性で構文を記載しますが、それはUIがどうこれらの属性を表示するはずであるかを指定しません。
Attributes that contain multiple-line text (i.e. Address) must use the procedure defined in RFC 822 in section 3.1.1 on "folding" long header lines [RFC-822].
複数の系列テキスト(すなわち、Address)を含む属性は「折りたたみ」の長いヘッダー系列[RFC-822]でセクション3.1.1でRFC822で定義された手順を用いなければなりません。
5.0 Information Object Template Definitions
5.0 情報オブジェクトテンプレート定義
This section describes the IWPS Person Information Object Template and its associated attributes. The Person Object is a simple list of attributes, no structure nor object inheritance is implied.
このセクションはIWPS Person情報Object Templateとその関連属性について説明します。 Person Objectは属性、構造がない単純並びであり、目的は継承です。含意されます。
IWPS client applications should use the following size recommendations as the maximum sizes of the attributes. However, applications should be able to handle attributes of arbitrary size, returned by a server which may not comply with these recommendation. All size recommendations are in characters.
IWPSクライアントアプリケーションは属性の最大サイズとして以下のサイズ推薦を使用するべきです。 しかしながら、アプリケーションはこれらの推薦に従わないかもしれないサーバによって返された任意のサイズの属性を扱うことができるべきです。 すべてのサイズ推薦がキャラクタにあります。
Note: Because many characters in many encodings require more than one byte, the size recommendations cannot be interpreted as sizes in bytes.
以下に注意してください。 多くのencodingsの多くのキャラクタが1バイト以上を必要とするので、バイトで表現されるサイズとしてサイズ推薦を解釈できません。
This set of attributes describes information types, and are not defined attributes in a particular schema. Any technology deploying a White Page service (WHOIS ++, LDAP, vCard, etc.) will need to publish as a companion document, their specific schema detailing how the general attributes of the White Pages schema are expressed.
このセットの属性は、情報タイプについて説明して、特定の図式の定義された属性ではありません。 ホワイトPageがサービス(WHOIS++、LDAP、vCardなど)であると配布するどんな技術も、仲間ドキュメント(ホワイトページ図式の一般属性がどう言い表されるかを詳しく述べる彼らの特定の図式)として発行する必要があるでしょう。
SPECIAL CONSIDERATIONS
特別な問題
Phone number: The full international form is recommended;
i.e. +1 206 703 0852. The field may contain
additional information following the phone
number. For example:
電話番号: 完全な国際的なフォームはお勧めです。 +1 すなわち、206 703、0852 電話番号に従って、分野は追加情報を含むかもしれません。 例えば:
+1 800 759 7243 #123456
+1 505 882 8080 ext. 30852
+1 7243#123456+1 505 882 8080がextする800 759。 30852
Genovese & Jennings Standards Track [Page 3] RFC 2218 Common Schema for IWPS October 1997
GenoveseとジョニングスStandardsは1997年10月にIWPSのためにRFC2218の一般的な図式を追跡します[3ページ]。
Email address: Is multivalued.
Eメールアドレス: 多値。
Certificate: Is multivalued.
以下を証明してください。 多値。
Common Name: Is multivalued.
一般的な名前: 多値。
Language Spoken: Is multivalued.
話された言語: 多値。
THE INFORMATION OBJECT TEMPLATE FOR THE IWPS PERSON
IWPS人のための情報オブジェクトテンプレート
--General Attributes --
--一般属性--
Field Name Size Syntax
フィールド名サイズ構文
Email 360 Mailbox
Cert 4000 Certificate
Home Page 128 URI
Common Name 64 WhitepageString
Given Name 48 WhitepageString
Surname 48 WhitepageString
Organization 64 WhitepageString
Locality 20 WhitepageString
Country 2 WhitepageString (ISO 3166)
Language Spoken 128 WhitepageString (RFC 1766)
メール360メールボックス本命4000証明書ホームページ128URI俗称64WhitepageString名48WhitepageString姓48のWhitepageString組織64WhitepageString場所20WhitepageString国の2WhitepageString(ISO3166)の言語の話された128WhitepageString(RFC1766)
--Personal Attributes
--個人的特質
Personal Phone 30 PrintableString
Personal Fax 30 PrintableString
Personal Mobile Phone 30 PrintableString
Personal Pager Number 30 PrintableString
Personal Postal Address 255 Address
Description 255 WhitepageString
個人的な電話30のPrintableStringの個人的なファックス30のPrintableStringの個人的な携帯電話30のPrintableStringの個人的なポケットベルNo.30のPrintableStringの個人的な郵便の宛先255アドレス記述255WhitepageString
--Organizational Attributes
--組織的な属性
Title 64 WhitepageString
Office Phone 30 PrintableString
Office Fax 30 PrintableString
Office Mobile Phone 30 PrintableString
Office Pager 30 PrintableString
Office Postal Address 255 Address
タイトル64WhitepageString会社の電話30PrintableStringオフィスファックス30PrintableStringオフィス携帯電話30PrintableStringオフィスポケットベル30PrintableStringオフィス郵便の宛先255アドレス
--Ancillary
--付属
Creation Date 24 GeneralizedTime
Creator Name 255 URI
Modified Date 24 GeneralizedTime
作成日付24のGeneralizedTime創造者名255のURIの変更された期日24GeneralizedTime
Genovese & Jennings Standards Track [Page 4] RFC 2218 Common Schema for IWPS October 1997
GenoveseとジョニングスStandardsは1997年10月にIWPSのためにRFC2218の一般的な図式を追跡します[4ページ]。
Modifier Name 255 URI
修飾語名255のURI
6.0 IWPS Person Information Object Template Syntax
6.0IWPS人の情報オブジェクトテンプレート構文
This section defines the syntax used by the IWPS person information object template. It is copied in whole from the LDAP attribute working document with some modification for completeness.
このセクションはIWPS人の情報オブジェクトテンプレートによって使用される構文を定義します。 それは完全性のための何らかの変更でドキュメントを扱うLDAP属性から全部コピーされます。
Certificate:
以下を証明してください。
The certificate field is intended to hold any kind of certificate;
X.509 certificates are one example. A specific implementation will
specify how to indicate the type of certificate when describing
the mapping of the IWPS schema onto the implementation schema.
証明書分野がどんな種類の証明書も保持することを意図します。 X.509証明書は1つの例です。 特定の実装はIWPS図式に関するマッピングについて実装図式に説明するとき、証明書のタイプを示す方法を指定するでしょう。
WhitepageString:
WhitepageString:
This syntax must be able to encode arbitrary ISO 10646 characters.
One such encoding is the UTF-8 encoding [UTF-8].
この構文は任意のISO10646キャラクタをコード化できなければなりません。 そのようなコード化の1つは[UTF-8]をコード化するUTF-8です。
GeneralizedTime:
GeneralizedTime:
Values of this syntax are encoded as printable strings,
represented as specified in X.208. Note that the time zone must
be specified. It is strongly recommended that Zulu time zone be
used. For example:
この構文の値はX.208で指定されるように表された印刷可能なストリングとしてコード化されます。 時間帯を指定しなければならないことに注意してください。 ズールー族の時間帯が使用されることが強く勧められます。 例えば:
199412161032Z
199412161032Z
Mailbox:
メールボックス:
here are many kinds of mailbox addresses, including X.400 and
Internet mailbox addresses. The implementation must clearly
distinguish between different types of mailbox address, for
instance by using a textual refix or a set of attribute types.
There must be a way to represent any mailbox type.
ここに、X.400とインターネットメールボックスアドレスを含んでいて、多くの種類のメールボックスアドレスがあります。 例えば、実装は、原文のrefixか属性タイプのセットを使用することによって、明確に異なったタイプのメールボックスアドレスを見分けなければなりません。 どんなメールボックスタイプも代理をする方法があるに違いありません。
Address:
アドレス:
According to Universal Postal Union standards, this field must be
able to represent at least 6 lines of 40 characters.
万国郵便連合規格によると、この分野は40のキャラクタの少なくとも6つの台詞を表すことができなければなりません。
PrintableString:
PrintableString:
The encoding of a value with PrintableString syntax is the string
value itself. PrintableString is limited to the characters in
production <p>. Where production <p> is described by the
following:
PrintableString構文による価値のコード化はストリング値自体です。 PrintableStringは生産<p>のキャラクタに制限されます。 生産<p>が以下によって説明されるところ:
Genovese & Jennings Standards Track [Page 5] RFC 2218 Common Schema for IWPS October 1997
GenoveseとジョニングスStandardsは1997年10月にIWPSのためにRFC2218の一般的な図式を追跡します[5ページ]。
<a> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' |
'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' |
's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' |
'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' |
'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' |
'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'
<a>:、:= 'a'| 'b'| 'c'| '、'であるだろう| 'e'| 'f'| 'g'| 'h'| 'i'| 'j'| 'k'| 'l'| '存在'| '、'| 'o'| 'p'| 'q'| 'r'| 's'| '、'| 'u'| 'v'| 'w'| 'x'| 'y'| 'z'| 'A'| 'B'| 'C'| '、'であるだろう| 'E'| 'F'| 'G'| 'H'| '私'| 'J'| 'K'| 'L'| '存在'| '、'| '○'| 'P'| 'Q'| 'R'| 's'| '、'| 'U'| 'V'| 'W'| 'X'| 'Y'| 'Z'
<d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
<d>:、:= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
<p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
'/' | ':' | '?' | ' '
<p>:、:= <は>です。| <d>。| ''' | '(' | ')' | '+' | ',' | '-' | '.' | '/' | ':' | '?' | ' '
7.0 Publication of IWPS Information Object Templates.
7.0 IWPS情報オブジェクトテンプレートの公表。
The Working Group recommends that all information object templates used for the IWPS be published.
作業部会は、IWPSに使用されるすべての情報オブジェクトテンプレートが発行されることを勧めます。
Individual organizations may define information object templates that are local in scope as required to meet local organizational needs. All information that the organization wishes to be part of the IWPS must use a published IWPS information object template.
個々の組織は、地方の組織的な需要を満たすために必要に応じて範囲で地方であることの情報オブジェクトテンプレートを定義するかもしれません。 組織がIWPSについて一部になりたがっているというすべての情報が発行されたIWPS情報オブジェクトテンプレートを使用しなければなりません。
8.0 Data Privacy
8.0 データプライバシー
Each country, and each state within the US, has legislation defining information privacy. The suggested attributes in Section 5.0 may be considered private and the directory administrator is strongly advised to verify the privacy legislation for his domain.
各国、および米国の中の各州には、情報プライバシーを定義する法律があります。 セクション5.0における提案された属性は個人的であると考えられるかもしれません、そして、ディレクトリ管理者が彼のドメインにプライバシー法律について確かめるように強くアドバイスされます。
As suggested in "Privacy and Accuracy in NIC Databases" [RFC-1355], each directory provider should provide a clear statement of the purpose of the directory, the information that should be contained in it, and a privacy policy associated with that information. This policy should include restrictions for data dissemination.
「NICデータベースのプライバシーと精度」[RFC-1355]で示されるように、それぞれのディレクトリプロバイダーはディレクトリの目的、それに含まれるべきである情報、およびその情報に関連しているプライバシーに関する方針の明確な声明を提供するべきです。 この方針はデータ配布のための制限を含むべきです。
This policy is strongly recommended for the US and Canada and required by many countries in the European Community for data sharing.
この方針は、強くアメリカとカナダに推薦されて、データ共有のためにヨーロッパ共同体における多くの国によって必要とされます。
9.0 Data Integrity
9.0 データの保全
Data Integrity was first addressed in RFC 1107 [KS89], which states "a White Pages service will not be used, if the information it provides is out of date or incorrect." Therefore, any production IWPS provider must insure that all data is reasonably correct and up-to-date.
データの保全は最初に、RFC1107[KS89]で扱われました。(RFCは「ホワイトのページサービスは利用されないでしょう、それが提供する情報が時代遅れであるか、または不正確であるなら。」と述べます)。 したがって、どんな生産IWPSプロバイダーも、すべてのデータがかなり正しくて、最新であることを保障しなければなりません。
Genovese & Jennings Standards Track [Page 6] RFC 2218 Common Schema for IWPS October 1997
GenoveseとジョニングスStandardsは1997年10月にIWPSのためにRFC2218の一般的な図式を追跡します[6ページ]。
The Ancillary Attributes of the IWPS person template denote the information's source and date of origin, and the source and date of its latest modification. They provide the user with some measurement of the quality of data making it easy to determine the owner and freshness of the data retrieved.
IWPS人のテンプレートのAncillary Attributesは最新の変更の情報の発生源のソースと日付、ソース、および日付を指示します。 彼らは所有者を決定するのが簡単になるデータの質の何らかの測定と検索されるデータの新しさにユーザを提供します。
The IWPS User Agent must be able to retrieve and display Ancillary Attributes. Retrieval and display may be done as separate operations.
IWPS Userエージェントは、Ancillary Attributesを検索して、表示できなければなりません。 別々の操作として検索とディスプレイをするかもしれません。
The Ancillary Attributes are recommended as the minimum set of attributes for any new information object template. Each IWPS server may individually decide whether to support the storage and retrieval of this data.
Ancillary Attributesはどんな新情報オブジェクトテンプレートのための最小のセットの属性としてお勧めです。 それぞれのIWPSサーバは、このデータのストレージと検索をサポートするかどうか個別に決めるかもしれません。
The Ancillary Attributes (also defined in Section 5.0) provide the following information about its associated information object:
Ancillary Attributes(また、セクション5.0で定義される)は関連情報オブジェクトの以下の情報を提供します:
1. The date and time the entry was created; Creation Date.
1. エントリーが作成された日時。 作成日付。
2. Owner or individual responsible for the data creation;
Creator Name.
2. データ作成に責任がある所有者か個人。 創造者名。
3. The date and time of the last modification;
Modified Date.
3. 最後の変更の日時。 変更された期日。
4. Individual responsible for the last modification;
Modifier Name.
4. 最後の変更に責任がある個人。 修飾語名。
10.0 Security Considerations
10.0 セキュリティ問題
Security is implementation and deployment specific and as such is not addressed in this memo. Security must ensure that the constraints mentioned in the Data Privacy Section 8.0 are complied with.
セキュリティは、実装と展開特有であり、このメモでそういうものとして扱われません。 セキュリティは、Data Privacyセクション8.0で言及された規制が従われるのを確実にしなければなりません。
11.0 References
11.0の参照箇所
[KS89] Sollins, K., "A Plan for Internet Directory Services", RFC 1107, Laboratory for Computer Science, MIT, July 1989.
[KS89] Sollins、K.、「インターネットディレクトリサービスのためのプラン」、RFC1107、コンピュータ科学研究所、MIT、1989年7月。
[NADF92] North American Directory Forum, "User Bill of Rights for entries and listings in the Public Directory', RFC 1295, North American Directory Forum, January 1992.
'[NADF92]北米のディレクトリForum、「Publicディレクトリにおけるエントリーとリストのためのユーザ権利の章典'、RFC1295、北米のディレクトリForum、1992年1月」。
Genovese & Jennings Standards Track [Page 7] RFC 2218 Common Schema for IWPS October 1997
GenoveseとジョニングスStandardsは1997年10月にIWPSのためにRFC2218の一般的な図式を追跡します[7ページ]。
[PA94] Postel, J., and C. Anderson, "WHITE PAGES MEETING REPORT", RFC 1588, University of Southern California, February 1994.
[PA94] ポステル、J.とC.アンダーソン、「ホワイトページミーティングレポート」、RFC1588、南カリフォルニア大学、1994年2月。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC-822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[RFC-1355] Curran, J., and A. Marine, "Privacy and Accuracy Issues in Network Information Center Databases", FYI 15, RFC 1355, August 1992.
[RFC-1355] カラン、J.、およびA.海兵隊員、「ネットワーク情報のプライバシーと精度問題はデータベースを中心に置きます」、FYI15、RFC1355、1992年8月。
[UCS] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1, 1993.
[UCS]普遍的な複数の八重奏は文字コード(UCS)をコード化しました--アーキテクチャと基本多言語水準、ISO/IEC10646-1、1993。
[RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC-1766]Alvestrand、H.、「言語の識別のためのタグ」、RFC1766、1995年3月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", Work in Progress.
[UTF-8]Yergeau、中のF.、「UTF-8、ISO10646の変換形式」Work、Progress。
11.0 Authors' Addresses
11.0 作者のアドレス
Tony Genovese The Microsoft Corporation One Microsoft Way Redmond, Washington 98007 USA
トニーGenoveseマイクロソフト社1マイクロソフト道、ワシントン98007・レッドモンド(米国)
Phone: (206) 703-0852 EMail: TonyG@Microsoft.com
以下に電話をしてください。 (206) 703-0852 メールしてください: TonyG@Microsoft.com
Barbara Jennings Sandia National Laboratories Albuquerque, New Mexico 87106 USA
バーバラ・ジョニングス・サンディア国立研究所ニューメキシコ87106アルバカーキ(米国)
Phone: (505) 845-8554 EMail: jennings@sandia.gov
以下に電話をしてください。 (505) 845-8554 メールしてください: jennings@sandia.gov
Genovese & Jennings Standards Track [Page 8]
Genoveseとジョニングス標準化過程[8ページ]
一覧
スポンサーリンク
