RFC3688 日本語訳
3688 The IETF XML Registry. M. Mealling. January 2004. (Format: TXT=17325 bytes) (Also BCP0081) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Mealling Request for Comments: 3688 VeriSign, Inc. BCP: 81 January 2004 Category: Best Current Practice
コメントを求める要求を荒びきにして、作業部会M.をネットワークでつないでください: 3688ベリサインInc.BCP: 1月81日の2004カテゴリ: 最も良い現在の習慣
The IETF XML Registry
IETF XML登録
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 (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.
このドキュメントはNamespaces(Document Type Declarations(DTD)、Schemas、およびResource記述Framework(リモート・データ・ファシリティ)Schemas)などの拡張マークアップ言語の(XML)関連する項目を使用するIETF規格のために登録であると主張されたIANAについて説明します。
1. Introduction
1. 序論
Over the past few years, the Extensible Markup Language (XML) [W3C.REC-xml] has become a widely used method for data markup. There have already been several IETF Working Groups that have produced standards that define XML Document Type Definitions (DTDs), XML Namespaces [W3C.REC-xml-names], and XML Schemas [W3C.REC-xmlschema- 1]. Each one of these technologies uses Uniform Resource Identifiers (URIs) [RFC2396] and other standardized identifiers to identify various components.
過去数年間にわたって、拡張マークアップ言語(XML)[W3C. REC-xml]はデータマーク付けのための広く使用されたメソッドになっています。 既に、XML Document Type Definitions(DTD)、XML Namespaces[W3C. REC-xml-名前]、およびXML Schemas[W3C. REC-xmlschema1]を定義する規格を生産した数個のIETF Working Groupsがありました。 これらの技術の各々は、様々なコンポーネントを特定するのにUniform Resource Identifier(URI)[RFC2396]と他の標準化された識別子を使用します。
For example, while it has been the practice within some standards that use Document Type Definitions (DTDs) to forego the use of the PUBLIC identifiers in favor of 'well known' SYSTEM identifiers, it has proven to be more trouble than its worth to attempt to standardize SYSTEM identifiers. The result is that several IETF standards that have simply created non-resolvable URIs in order to simply identify but not resolve the DTD for some given XML document.
例えば、'よく知られている'SYSTEM識別子を支持してPUBLIC識別子の使用に先立つのが、Document Type Definitions(DTD)を使用するいくつかの規格の中の習慣ですが、それは、SYSTEM識別子を標準化するのを試みるために価値より多くの問題であると判明しました。 結果はそうしたいくつかのIETF規格が何らかの与えられたXMLドキュメントのためのDTDを絶対に特定しますが、決議しないように単に非溶解性のURIを作成したということです。
This document seeks to standardize and improve these practices by creating an IANA maintained registry of XML element identifiers so that document authors and implementors have a well maintained and
そしてこのドキュメントがドキュメント作者と作成者が井戸を維持させるようにXML要素識別子の登録であると主張されたIANAを作成することによってこれらの習慣を標準化して、改良しようとする。
Mealling Best Current Practice [Page 1] RFC 3688 The IETF XML Registry January 2004
IETF XML登録2004年1月に最も良い現在の習慣[1ページ]RFC3688を荒びきにします。
authoritative location for their XML elements. As part of this standard, the IANA will maintain:
それらのXML要素のための正式の位置。 この規格の一部として、IANAは以下を維持するでしょう。
o the public representation of the document,
o ドキュメントの公共の表現
o the URI for the elements if one is provided at the time of registration,
o 1であるなら登録時点で要素のためのURIを提供します。
o a registry of Public Identifiers as URIs.
o URIとしてのPublic Identifiersの登録。
In the case where the registrant does not request a particular URI, the IANA will assign it a Uniform Resource Name (URN) that follows [RFC3553].
記入者が特定のURIを要求しない場合では、IANAは続くUniform Resource Name(URN)[RFC3553]をそれに割り当てるでしょう。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
3. Registerable Documents
3. Registerableドキュメント
3.1. The Assigned/Registered URI
3.1. 割り当てられたか登録されたURI
All elements (except PUBLIC identifiers) in this registry will require a URI in order to be registered. If the registrant wishes to have a URI assigned, then a URN of the form
この登録のすべての要素(PUBLIC識別子を除いた)が、登録されるためにURIを必要とするでしょう。 記入者に割り当てられたURI、次に形式のURNがありたいなら
urn:ietf:params:xml:<class>:<id>
つぼ:ietf:params:xml:<のクラス>: <イド>。
will be assigned where <class> is the type of the document being registered (see below). <id> is a unique id generated by the IANA based on any means the IANA deems necessary to maintain uniqueness and persistence. NOTE: in order for a URN of this type to be assigned, the item being registered MUST have been through the IETF consensus process. Basically, this means that it must be documented in a RFC. The RFC 3553 [RFC3553] URN registration template is found in Section 6.
登録されていて、<のクラス>がドキュメントのタイプであるところに割り当てられるでしょう(以下を見てください)。 <イド>はIANAがユニークさと固執を維持するのに必要であると考えるどんな手段にも基づくIANAによって生成されたユニークなイドです。 以下に注意してください。 選任されるこのタイプのURNにおいて整然とします、登録される項目がIETFコンセンサスを得るためのプロセスであったに違いありません。 基本的に、これは、それをRFCに記録しなければならないことを意味します。 RFC3553[RFC3553]URN登録テンプレートはセクション6で見つけられます。
The IANA will also maintain a file server available via at least HTTP and FTP that contains all of the registered elements in some publicly accessible file space in the same way that all of the IANA's registered elements are available via http://www.iana.org/assignments/. While the directory structure of this server is up to the IANA, it is suggested that the files be organized by the <class> and the individual files have the <id> as their filename.
また、IANAは少なくともHTTPと何らかの公的にアクセスしやすいファイルのスペースに同じように登録された要素のすべてを保管しているFTPで利用可能に http://www.iana.org/assignments/ を通して利用可能な状態でファイルサーバーを維持するでしょう。このサーバのディレクトリ構造がIANA次第である間、ファイルが<のクラス>によって組織化されることが提案されて、個々のファイルはそれらのファイル名として<イド>を持っています。
Mealling Best Current Practice [Page 2] RFC 3688 The IETF XML Registry January 2004
IETF XML登録2004年1月に最も良い現在の習慣[2ページ]RFC3688を荒びきにします。
Implementors are warned that they should not programatically rely on those resources being available or the directory structure remaining static for any reason. It is explicitly recognized that some software tools attempt to download DTDs, schema, etc., 'on the fly' and that developers should understand when this is done and when to not reference IANA network resources as a 'schema download repository'. This is the reason that the IANA will not register or provide SYSTEM identifiers.
作成者は彼らがprogramaticallyにそれらの利用可能なリソースかどんな理由でも静的に残っているディレクトリ構造を当てにするべきでないのに注意されます。 いくつかのソフトウェアツールが、'急いでDTD、図式などをダウンロードするのを試みて、'開発者は、いつこれをするか、そして、何か参照に、'図式としてのIANAネットワーク資源がいつ倉庫をダウンロードしないかを理解するべきである'と明らかに認められます。 これはIANAが登録もしませんし、識別子をSYSTEMに供給もしない理由です。
3.2. Registerable Classes
3.2. Registerableのクラス
The list of types of XML elements that can be registered with the IANA are:
IANAに登録できるXML要素のタイプのリストは以下の通りです。
publicid -- An XML document that contains a DOCTYPE declaration or any other external reference can identify that reference via both a PUBLIC identifier and a SYSTEM identifier. The SYSTEM identifier is system-specific information that enables the entity manager of an XML system to locate the file, memory location, or pointer within a file where the entity can be found. It should also be noted that a system identifier could be an invocation of a program that controls access to an entity that is being identified. Thus, they are not registered items. In many cases, SYSTEM identifiers are also URIs. However, in these cases, the URI is still only used for system-specific information. In the case where a PUBLIC Identifier is also a URI, it is possible for the SYSTEM Identifier to contain the same URI but this behavior is not recommended unless its side effects are well known and understood to not cause any unacceptable harm.
publicid--DOCTYPE宣言かいかなる他の外部参照も含むXMLドキュメントはPUBLIC識別子とSYSTEM識別子の両方を通してその参照を特定できます。 SYSTEM識別子はXMLシステムの実体マネージャが実体を見つけることができるファイルの中でファイル、記憶域、または指針の場所を見つけるのを可能にするシステム特殊情報です。 また、システム識別子が特定されている実体へのアクセスを制御するプログラムの実施であるかもしれないことに注意されるべきです。 したがって、それらは登録された項目ではありません。多くの場合、また、SYSTEM識別子はURIです。 しかしながら、これらの場合では、URIはシステム特殊情報にまだ使用されているだけです。 またPUBLIC IdentifierがURIである場合では、SYSTEM Identifierが同じURIを含むのが、可能ですが、この振舞いは、副作用がよく知られていない場合推薦されて、少しの容認できない害も引き起こさないのが理解されていません。
A PUBLIC identifier is a name that is intended to be meaningful across systems and different user environments. Typically, it will be a name that has a registered owner associated with it, so that public identifiers will be guaranteed unique and no two entities will have the same public identifier. In practice, PUBLIC identifiers are typically Formal Public Identifiers [ISO.8879.1986] but they are not restricted to just that set. As said in [RFC3151]:
PUBLIC識別子はシステムと異なったユーザの環境の向こう側に重要であることを意図する名前です。 通常、名前になるでしょうそれに関連している登記済み所有主がいる、公共の識別子がユニーク、そして、いいえ、2つの実体には同じ公共の識別子があるのが保証されるように。 実際には、通常、PUBLIC識別子がFormal Public Identifiersである、[ISO、.8879、.1986、]、彼らだけがまさしくそのセットに制限されません。 [RFC3151]で言われているように:
"Any string which consists only of the public identifier characters (defined by Production 13 of Extensible Markup Language (XML) 1.0 Second Edition) is a legal public identifier."
「公共の識別子キャラクタ(拡張マークアップ言語(XML)1.0Second EditionのProduction13によって定義される)だけから成るどんなストリングも法的な公共の識別子です。」
Therefore, it is legal for a PUBLIC identifier to be a URN if it adheres to the character set restrictions.
したがって、文字集合制限を固く守るなら、PUBLIC識別子がURNであることは法的です。
Mealling Best Current Practice [Page 3] RFC 3688 The IETF XML Registry January 2004
IETF XML登録2004年1月に最も良い現在の習慣[3ページ]RFC3688を荒びきにします。
Thus, the identifier registered along with a DTD is its PUBLIC identifier. The only restriction being that it must adhere to the character set restrictions. In the case where the registrant does not provide one, the IANA will assign one of the form 'urn:ietf:params:xml:pi:<id>'. Registrants are encouraged to investigate RFC 3151 [RFC3151] as a recommended method for minting a URN that can also be represented as an FPI.
したがって、DTDと共に登録された識別子はそのPUBLIC識別子です。 文字集合制限を固く守らなければならないということである唯一の制限。 記入者が1つを提供しない場合では、IANAはフォーム'つぼ:ietf:params: xml:パイ:<イド>'の1つを割り当てるでしょう。 記入者がまた、FPIとして表すことができるURNを造幣するためのお勧めのメソッドとしてRFC3151[RFC3151]を調査するよう奨励されます。
ns -- XML Namespaces [W3C.REC-xml-names] are named by a URI. They have no real, machine-parseable representation. Thus, the registered document will be either the specification or a reference to it. In the case where a URI is not provided by the registrant, the IANA will assign a URN of the form 'urn:ietf:params:xml:ns:<id> which will be the XML Namespace's name.
ナノ秒--XML Namespaces[W3C. REC-xml-名前]はURIによって命名されます。 彼らには、本当でなくて、マシン分析可能な表現があります。 したがって、登録されたドキュメントは、それが、仕様か参照のどちらかになるでしょう。 URIが記入者によって提供されない場合では、IANAは'XML Namespaceの名前になるつぼ:ietf:params: xml:ナノ秒:<イド>'を形式のURNに割り当てるでしょう。
schema -- XML Schemas [W3C.REC-xmlschema-1] are also identified by a URI but their contents are machine parseable. The IANA registered document will be the XML Schema file. The URN the IANA assigns can be used as the URI for the schema and is of the form 'urn:ietf:params:xml:schema:<id>'.
図式--また、XML Schemas[W3C. REC-xmlschema-1]はURIによって特定されますが、彼らの内容はマシン分析可能です。 IANAはXML Schemaがファイルであるつもりであったならドキュメントを登録しました。 IANAが割り当てるURNは図式にURIとして使用できて、フォーム'つぼ:ietf:params: xml:図式:<イド>'のものです。
rdfschema -- The Resource Description Format (RDF) [W3C.CR-rdf-schema] is an XML serialization of a connected graph based data model used for metadata expression. RDF makes use of schemas for RDF that express grammars about relationships between URIs. These grammars are identified by URIs. The URN assigned by the IANA can be used as the identifying URI and is of the form 'urn:ietf:params:xml:rdfschema:<id>'.
rdfschema--Resource記述Format(リモート・データ・ファシリティ)[W3C. CR-rdf-図式]はベースのデータモデルがメタデータ式に使用した接続グラフのXML連載です。 リモート・データ・ファシリティはURIの間の関係に関する文法を表すリモート・データ・ファシリティにschemasを利用します。 これらの文法はURIによって特定されます。 IANAによって割り当てられたURNは特定URIとして使用できて、フォーム'つぼ:ietf:params:xml:rdfschema: <イド>'のものです。
4. Registration Procedures
4. 登録手順
Until the IANA requests or implements an automated process for the registration of these elements, any specifications must make that request part of the IANA considerations section of their respective documents. That request must be in the form of the following template:
IANAがこれらの要素の登録のために自動化されたプロセスを要求するか、または実装するまで、どんな仕様もそれらのそれぞれのドキュメントのIANA問題部のその要求地域を作らなければなりません。 その要求は以下のテンプレートの形にあるに違いありません:
URI The URI or PUBLIC identifier that identifies the XML component. If the registrant is requesting that the IANA assign a URI then this field should be specified as "please assign".
URI、XMLの部品を特定するURIかPUBLIC識別子。 記入者が、IANAがURIを割り当てるよう要求しているなら、「割り当ててくださいという」とき、この分野は指定されるべきです。
Registrant Contact The individual/organization that is the registration contact for the component being registered. Ideally, this will be the name and pertinent physical and network contact information. In the case of IETF developed standards, the Registrant will be the IESG.
登録されるコンポーネントに関する記入者登録である個人/組織のContact接触。 理想的に、これは、名前と物理的、そして、ネットワークの適切な問い合わせ先になるでしょう。 IETFの場合では、規格は展開していて、RegistrantはIESGになるでしょう。
Mealling Best Current Practice [Page 4] RFC 3688 The IETF XML Registry January 2004
IETF XML登録2004年1月に最も良い現在の習慣[4ページ]RFC3688を荒びきにします。
XML The exact XML to be stored in the registry. Unless the beginning and end of the file is obvious, the document should use the text "BEGIN" to mark the beginning of the file and "END" to mark the end of the file. The IANA will insert any text between those two strings (minus any page breaks and RFC formatting inserted by the RFC Editor) into the file kept in the repository.
登録に保存されるべきXMLの正確なXML。 ファイルの首尾が明白でない場合、ドキュメントは、ファイルの端を示すためにファイルと「終わり」の始まりを示すのにテキスト「始まってください」を使用するはずです。 IANAは倉庫に保たれたファイルの中へのそれらの2個のストリング(RFC Editorによって挿入されたどんなページブレークとRFC形式を引いた)の間にどんなテキストも挿入するでしょう。
5. Security Considerations
5. セキュリティ問題
The information maintained by the IANA will be authoritative and will be a target for attack. In some cases, such as XML Schema and DTDs, the content maintained by the IANA may be directly input into software. Thus, extra care should be taken by the IANA to maintain the security precautions required for an important reference location for the Internet.
IANAによって保守された情報は、正式であり、攻撃のために目標になるでしょう。 XML SchemaやDTDなどのいくつかの場合では、IANAによって維持された内容は直接ソフトウェアに入力されるかもしれません。 したがって、付加的な注意は、安全対策がインターネットに重要な参照位置に必要であると主張するためにIANAによって払われるはずです。
Beyond this concern, there are no other security considerations not already found with any other IANA registry.
この関心を超えて、いかなる他のIANA登録でも既に見つけられなかった他のセキュリティ問題は全くいません。
6. IANA Considerations
6. IANA問題
This document seeks to create a rather large registry for which the IANA (at the direction of the IESG) will be primarily responsible. The amount of effort required to maintain this registry is not insignificant and the policies and procedures surrounding any approval process are non-trivial. The registry is on a First Come First Served basis, but a Specification is Required. Once the IETF has some experience with this registry, these policies may change.
このドキュメントはIANA(IESGの方向の)は主として責任があるかなり大きい登録を作成しようとします。 取り組みの量がこの登録がわずかでないと主張するのが必要であり、どんな承認審査方式も囲む方針と手順は重要です。 登録がFirst Come First Servedベースにありますが、SpecificationはRequiredです。 IETFにこの登録の何らかの経験がいったんあると、これらの方針は変化するかもしれません。
RFC 3553 [RFC3553] specifies that any new registry requiring a name, to be assigned below the 'urn:ietf:params' namespace and must specify the structure of that space in template form. The IANA has created and will maintain this new sub-namespace:
RFC3553[RFC3553]は、どんな新しい登録も'つぼ:ietf:params'名前空間の下で割り当てられるために名前を必要として、テンプレートフォームのそのスペースの構造を指定しなければならないと指定します。 IANAは、作成して、この新しいサブ名前空間であることを支持するでしょう:
Registry-name: xml
登録名: xml
Specification: This document contains the registry specification. The namespace is organized with one sub-namespace which is the <id>.
仕様: このドキュメントは登録仕様を含んでいます。 名前空間は<イド>である1つのサブ名前空間で組織化されます。
Repository: To be assigned according to the guidelines found above.
倉庫: 上で見つけられたガイドラインによると、割り当てられるために。
Index value: The class name
値に索引をつけてください: クラス名
Mealling Best Current Practice [Page 5] RFC 3688 The IETF XML Registry January 2004
IETF XML登録2004年1月に最も良い現在の習慣[5ページ]RFC3688を荒びきにします。
7. Normative References
7. 引用規格
[ISO.8879.1986] International Organization for Standardization, "Information processing - Text and office systems - Standard generalized markup language (SGML)", ISO Standard 8879, 1986.
[ISO、.8879、.1986、]、国際標準化機構、「情報処理--テキストとオフィス・システム--マークアップ言語(SGML)」(ISO Standard8879、1986)
[RFC2119] 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月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[RFC3151] Walsh, N., Cowan, J. and P. Grosso, "A URN Namespace for Public Identifiers", RFC 3151, August 2001.
[RFC3151] ウォルシュとN.とカウァンとJ.とP.グロッソ、「公共の識別子のためのつぼの名前空間」、RFC3151、2001年8月。
[RFC3553] Mealling, M., Masinter, L., Hardie, T. and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[RFC3553] 食事とM.とMasinterとL.とハーディーとT.とG.Klyne、「登録されたプロトコルパラメタのためのサブ名前空間のIETFつぼ」、BCP73、RFC3553、2003年6月。
[W3C.CR-rdf-schema] Brickley, D. and R. Guha, "Resource Description Framework (RDF) Schema Specification 1.0", W3C CR-rdf-schema, March 2000, <http://www.w3.org/TR/2000/CR-rdf-schema- 20000327>.
[W3C. CR-rdf-図式] Brickley、D.、およびR.グーハ、「リソース記述フレームワーク(リモート・データ・ファシリティ)図式仕様1インチ(W3C CR-rdf-図式)は2000を行進させて、<はhttp://www.w3.org/TR/2000/CR-rdf図式-20000327>です」。
[W3C.REC-xml] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[W3C. REC-xml] ロバの鳴き声とT.とパオリとJ.とSperberg-マックィーンとC.とE.Maler、「拡張マークアップ言語(XML)1.0(2番目の教育)」、W3C REC-xml、2000年10月(<http://www.w3.org/TR/REC-xml>)。
[W3C.REC-xml-names] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.
「XMLの名前空間」という[W3C. REC-xml-名前]のロバの鳴き声、T.、オランダ人、D.、およびA.俗人は1999年1月に<http://www.w3.org/TR/REC-xml名を>にW3C REC-xml挙げます。
[W3C.REC-xmlschema-1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, <http://www.w3.org/TR/xmlschema-1/>.
[W3C. REC-xmlschema-1] トンプソン、H.、ぶな、D.、マローニー、M.、およびN.メンデルゾーン、「XML図式第1部:」 「構造」(W3C REC-xmlschema-1)は2001、<http://www.w3.org/TR/xmlschema-1/>がそうするかもしれません。
Mealling Best Current Practice [Page 6] RFC 3688 The IETF XML Registry January 2004
IETF XML登録2004年1月に最も良い現在の習慣[6ページ]RFC3688を荒びきにします。
8. Intellectual Property Statement
8. 知的所有権声明
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
9. Author's Address
9. 作者のアドレス
Michael Mealling VeriSign, Inc. Mountain View, CA USA
ベリサインInc.カリフォルニアマウンテンビュー(米国)を荒びきにするマイケル
EMail: michael@verisignlabs.com URI: http://www.research.verisignlabs.com
メール: michael@verisignlabs.com ユリ: http://www.research.verisignlabs.com
Mealling Best Current Practice [Page 7] RFC 3688 The IETF XML Registry January 2004
IETF XML登録2004年1月に最も良い現在の習慣[7ページ]RFC3688を荒びきにします。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 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 assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Mealling Best Current Practice [Page 8]
最も良い現在の習慣を荒びきにします。[8ページ]
一覧
スポンサーリンク