RFC3937 日本語訳

3937 A Uniform Resource Name (URN) Namespace for the InternationalPress Telecommunications Council (IPTC). M. Steidl. October 2004. (Format: TXT=15458 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          M. Steidl
Request for Comments: 3937                                          IPTC
Category: Informational                                     October 2004

Steidlがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3937年のIPTCカテゴリ: 情報の2004年10月

             A Uniform Resource Name (URN) Namespace for
       the International Press Telecommunications Council (IPTC)

国際新聞通信委員会のための一定のリソース名前(つぼ)名前空間(IPTC)

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).

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

Abstract

要約

   This document describes a URN (Uniform Resource Name) namespace for
   identifying persistent resources published by the International Press
   Telecommunications Council (IPTC).  These resources include XML Data
   Type Definition files (DTD), XML Schema, Namespaces in XML, XSL
   stylesheets, other XML based document and documents of other data
   formats like PDF documents, Microsoft Office documents and others.

このドキュメントは、国際新聞通信委員会(IPTC)によって発表されたしつこいリソースを特定するためにURN(一定のResource Name)名前空間について説明します。 これらのリソースはXML Data Type Definitionファイル(DTD)、他のデータのXML、XSLスタイルシート、他のXMLのベースのドキュメント、およびドキュメントのNamespacesがPDF文書、マイクロソフトオフィスドキュメント、および他のもののようにフォーマットするXML Schemaを含んでいます。

Steidl                       Informational                      [Page 1]

RFC 3937                 URN Namespace for IPTC             October 2004

IPTC2004年10月のためのSteidlの情報[1ページ]のRFC3937つぼの名前空間

Table of Contents

目次

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IANA URN Specification Template . . . . . . . . . . . . . . .   3
       2.1.  Namespace ID. . . . . . . . . . . . . . . . . . . . . .   3
       2.2.  Registration Information. . . . . . . . . . . . . . . .   3
       2.3.  Declaration of syntactic structure. . . . . . . . . . .   3
       2.4.  Relevant ancillary documentation. . . . . . . . . . . .   5
       2.5.  Identifier uniqueness considerations. . . . . . . . . .   5
       2.6.  Identifier persistence considerations . . . . . . . . .   5
       2.7.  Process of identifier assignment. . . . . . . . . . . .   5
       2.8.  Process for identifier resolution . . . . . . . . . . .   5
       2.9.  Rules for Lexical Equivalence . . . . . . . . . . . . .   5
       2.10. Conformance with URN Syntax . . . . . . . . . . . . . .   5
       2.11. Validation mechanism. . . . . . . . . . . . . . . . . .   5
       2.12. Scope . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Examples. . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Namespace Considerations and Community Considerations . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  References. . . . . . . . . . . . . . . . . . . . . . . . . .   7
       7.1.  Normative References. . . . . . . . . . . . . . . . . .   7
       7.2.  Informative References. . . . . . . . . . . . . . . . .   7
   Author's Address. . . . . . . . . . . . . . . . . . . . . . . . .   8
   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .   9

1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. IANAつぼの仕様テンプレート. . . . . . . . . . . . . . . 3 2.1。 名前空間ID。 . . . . . . . . . . . . . . . . . . . . . 3 2.2. レジスト情報。 . . . . . . . . . . . . . . . 3 2.3. 統語構造の宣言。 . . . . . . . . . . 3 2.4. 関連付属のドキュメンテーション。 . . . . . . . . . . . 5 2.5. 識別子ユニークさの問題。 . . . . . . . . . 5 2.6. 識別子固執問題. . . . . . . . . 5 2.7。 識別子課題の過程。 . . . . . . . . . . . 5 2.8. 識別子解決. . . . . . . . . . . 5 2.9のために、処理してください。 語彙等価性. . . . . . . . . . . . . 5 2.10のための規則。 つぼの構文. . . . . . . . . . . . . . 5 2.11との順応。 合法化メカニズム。 . . . . . . . . . . . . . . . . . 5 2.12. 範囲. . . . . . . . . . . . . . . . . . . . . . . . . 5 3。 例。 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. 名前空間問題と共同体問題. . . . 6 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 7 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 7 7。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. 引用規格。 . . . . . . . . . . . . . . . . . 7 7.2. 有益な参照。 . . . . . . . . . . . . . . . . 7作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . . 8 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . 9

1.  Introduction

1. 序論

   The International Press Telecommunications Council (IPTC) is a non-
   profit consortium of the world's major news agencies and news
   industry vendors.  It develops and maintains technical standards for
   the news business that are used by virtually every major news
   organization in the world.  IPTC was established in 1965.

国際新聞通信委員会(IPTC)は世界の主要な通信社と報道界の業者の非利益の共同体です。 それは、ニュースビジネスのための世界の実際にはあらゆる主要な報道機関によって使用される規格を、開発して、維持します。 IPTCは1965年に設立されました。

   Since the 1990's IPTC's standardization work is based on open
   standards like first SGML, then the XML [W3CXML] family of standards,
   MIME, Unicode, and so on.

以来、1990年代のIPTCの標準化仕事は次に、最初のSGML、規格、MIME、ユニコードなどのXML[W3CXML]家のようなオープンスタンダードに基づいています。

   As some of these standards require identification of resources IPTC
   was looking for a technology for globally unique, persistent and
   location-independent identifiers and decided to implement URNs as
   described in "URN Syntax" [RFC2141] for this reason.

これらの規格のいくつかが必要であるように、リソースIPTCの識別は、グローバルにユニークで、しつこくて位置から独立している識別子のために技術を探していて、この理由で「つぼの構文」[RFC2141]で説明されるようにURNsを実行すると決めました。

   This namespace specification is for a formal namespace.

この名前空間仕様は正式な名前空間のためのものです。

Steidl                       Informational                      [Page 2]

RFC 3937                 URN Namespace for IPTC             October 2004

IPTC2004年10月のためのSteidlの情報[2ページ]のRFC3937つぼの名前空間

2.  IANA URN Specification Template

2. IANAつぼの仕様テンプレート

2.1.  Namespace ID

2.1. 名前空間ID

   "iptc" requested.

要求された"iptc"。

2.2.  Registration Information

2.2. レジスト情報

   Registration Version Number: 1
   Registration Date: 2003-11-11

登録バージョン番号: 1 登録日付: 2003-11-11

      Declared registrant of the namespace:

名前空間の宣言している記入者:

   Registering organization:
      International Press Telecommunications Council IPTC
      Royal Albert House
      Sheet Street
      Windsor, Berkshire SL4 1BE
      www.iptc.org

組織を登録します: 国際新聞通信委員会IPTCロイヤル・アルバート家のSheet通りウインザー、バークシャーSL4 1BE www.iptc.org

   Designated contact person:
      Michael Steidl
      Managing Director
      mdirector@iptc.org

指定された連絡窓口: マイケルSteidl専務理事 mdirector@iptc.org

2.3.  Declaration of syntactic structure

2.3. 統語構造の宣言

   All URNs assigned by IPTC will have a Namespace Specific String (NSS)
   of the following hierarchical structure:

IPTCによって割り当てられたすべてのURNsが以下の階層構造のNamespace Specific String(NSS)を持つでしょう:

   At the top of the hierarchy are three branches:
   - "std"
   - "std-draft"
   - "workdoc"

階層構造の最上部に、3つのブランチがあります: - "std"--「std-草稿」--"workdoc"

   The "std" branch hierarchy:

"std"ブランチ階層構造:

      The "std" branch URNs will be assigned to IPTC resources
      used for specifying and explaining any aspect of an IPTC
      standard.

"std"ブランチURNsは、IPTC規格のどんな局面も指定して、説明するためにIPTC運用資金に割り当てられるでしょう。

      The NSS in the "std" branch will have this general structure:

"std"ブランチにおけるNSSには、この一般構造体があるでしょう:

      urn:iptc:std:{std-name}:{std-version}:{res-group}
          {:res-name}?{:res-version}?

つぼ:iptc:std: std-名前: std-バージョン: : : res-バージョンというres-名前をres分類してください。

Steidl                       Informational                      [Page 3]

RFC 3937                 URN Namespace for IPTC             October 2004

IPTC2004年10月のためのSteidlの情報[3ページ]のRFC3937つぼの名前空間

      where
      "std-name" is a unique identifier for an IPTC standard.
      "std-version" reflects the version of this standard.  The value
          'current' will be assigned to point at resources of the
          current version of a standard.
      "res-group": this field will take only three values:
         "spec" for all resources specifying a standard,
         "doc" for all resources used for additional documentation of
             and to support the use of a standard.
         "xmlns" for defining an XML namespace [W3CXMLNS].
      "res-name" is an identifier for a tangible resource; the name
      should describe the content or the use of the resource.  Since not
      all resources are tangible this value is optional.
      "res-version" reflects the version of this resource as long as it
      takes a physical format - like e.g., a file.  Since not all
      resources are of a physical kind this value is optional.

「std-名前」がIPTC規格のためのユニークな識別子であるところ。 「std-バージョン」はこの規格のバージョンを反映します。 値の'電流'は、規格の最新版に関するリソースを指し示すために割り当てられるでしょう。 「res-グループ」: この分野は3つの値だけを取るでしょう: 規格を指定するすべてのリソースのための「仕様」、すべてのリソースのための"doc"は追加のドキュメンテーションにサポートとサポートに規格の使用を使用しました。 XML名前空間[W3CXMLNS]を定義するための"xmlns"。 「res-名前」は触知できるリソースのための識別子です。 名前はリソースの内容か使用について説明するべきです。 すべてのリソースがどんな触知できるというわけではないので、この値は任意です。 例えば、ファイルのような物理的な形式がかかる限り、「res-バージョン」はこのリソースのバージョンを反映します。 すべてのリソースが物理的な種類のものであるというわけではないので、この値は任意です。

   The "std-draft" branch hierarchy:

「std-草稿」ブランチ階層構造:

      The "std-draft" branch URNs will be assigned to IPTC resources
      used for specifying and explaining any aspect of an IPTC standard
      while being in draft status, that is at a time when the resource
      is not formally approved by the IPTC Standards body.

「std-草稿」ブランチURNsは指定するためにIPTC運用資金に割り当てられるでしょう、そして、ドラフト状態にある間、IPTC規格のどんな局面についても説明して、リソースがIPTC Standardsボディーによって正式に承認されないとき、それはいます。

      The NSS in the "std" branch will have this general structure:

"std"ブランチにおけるNSSには、この一般構造体があるでしょう:

      urn:iptc:std-draft:{std-name}:{std-version}:{res-group}
          {:res-name}?{:res-version}?

つぼ: iptc: std-草稿: std-名前: std-バージョン: : : res-バージョンというres-名前をres分類してください。

      The substructure of "urn:iptc:std-draft" is identical to that of
      "urn:iptc:std", find all explanations there.

「つぼ: iptc: std-草稿」の基礎は「つぼ:iptc:std」のものと同じであり、掘り出し物はすべて、そこでの説明です。

   The "workdoc" branch hierarchy:

"workdoc"ブランチ階層構造:

      The "workdoc" branch URNs will be assigned to IPTC resources not
      directly related to IPTC standards but to the work of IPTC.

"workdoc"ブランチURNsは直接IPTC規格に関係づけられるのではなく、IPTCの仕事に関係づけられたIPTCリソースに割り当てられるでしょう。

      The NSS in the "doc" branch will have this general structure:

"doc"ブランチにおけるNSSには、この一般構造体があるでしょう:

      urn:iptc:workdoc:{group-id}:{doc-id}:{doc-version}{:doc-descr}?

つぼ:iptc:workdoc: グループイド: doc-イド: : doc-バージョンdoc-descr?

      where
      "group-id" is a unique identifier for working groups and working
         areas of IPTC and constitutes a document group.
      "doc-id" is a unique identifier for a document within a document
          group.

「グループイド」がIPTCのワーキンググループと働く領域のためのユニークな識別子であり、ドキュメントを構成するところでは、分類してください。 「doc-イド」はドキュメントグループの中のドキュメントのためのユニークな識別子です。

Steidl                       Informational                      [Page 4]

RFC 3937                 URN Namespace for IPTC             October 2004

IPTC2004年10月のためのSteidlの情報[4ページ]のRFC3937つぼの名前空間

      "doc-version" reflects the version of this work document.
      "doc-descr" is an optional concise description of the document
          content.

「doc-バージョン」はこの作業文書のバージョンを反映します。 "doc-descr"はドキュメント内容の任意の簡潔な説明です。

2.4.  Relevant ancillary documentation

2.4. 関連付属のドキュメンテーション

   None

なし

2.5.  Identifier uniqueness considerations

2.5. 識別子ユニークさの問題

   Identifier uniqueness will be enforced by the Managing Director of
   IPTC who will assign unique identifiers to all resources identified
   by a URN.

識別子のユニークさはURNによって特定されたすべてのリソースにユニークな識別子を割り当てるIPTCの専務理事によって励行されるでしょう。

2.6.  Identifier persistence considerations

2.6. 識別子固執問題

   IPTC is committed to maintaining the accessibility and persistence of
   all resources that are identified by an IPTC URN.

IPTCはIPTC URNによって特定されるすべてのリソースのアクセシビリティと固執を維持するよう心がけます。

2.7.  Process of identifier assignment

2.7. 識別子課題の過程

   Assignment is limited to the owner of this namespace and its
   authorities.

課題はこの名前空間の所有者とその当局に制限されます。

2.8.  Process for identifier resolution

2.8. 識別子解決のための過程

   IPTC will develop an appropriate mechanism that maps all assigned
   URNs to Uniform Resource Locators (URL), specifically to enable web
   based resolution of URNs.

IPTCは、特にURNsのウェブに基づいている解決を可能にするために、地図がすべて、URNsを割り当てた適切な手段をUniform Resource Locator(URL)に開発するでしょう。

2.9.  Rules for Lexical Equivalence

2.9. 語彙等価性のための規則

   No special considerations, the rules for lexical equivalence of RFC
   2141 apply.

特別な問題でなく、RFC2141の語彙等価性のための規則は適用されます。

2.10.  Conformance with URN Syntax

2.10. つぼの構文との順応

   No special considerations.

特別な問題がありません。

2.11.  Validation mechanism

2.11. 合法化メカニズム

   None specified.  IPTC will develop a mechanism for resolving URNs to
   URLs (see 2.8), this mechanism will also show whether a URN is valid.

なにも指定しませんでした。 IPTCはURLにURNsを決議するためにメカニズムを開発するでしょう(2.8を見てください)、とまた、URNが有効であるか否かに関係なく、このメカニズムは示すでしょう。

2.12.  Scope

2.12. 範囲

   Global.

グローバル。

Steidl                       Informational                      [Page 5]

RFC 3937                 URN Namespace for IPTC             October 2004

IPTC2004年10月のためのSteidlの情報[5ページ]のRFC3937つぼの名前空間

3.  Examples

3. 例

   The following examples are representative for IPTC URNs, but may not
   refer to actual resources.

以下の例は、IPTC URNsにおいて代表しますが、実際のリソースを示さないかもしれません。

   urn:iptc:std:NewsML:1.1:spec:DTD:1
      DTD version 1 to specify the IPTC standard "NewsML", version 1.1

つぼ:iptc:std:NewsML:1.1:仕様:DTD: IPTCの標準の"NewsML"を指定する1つのDTDバージョン1、バージョン1.1

   urn:iptc:std-draft:NITF:3.5:spec:xml-schema:2
      Second draft XML Schema  for the IPTC standard "NITF", version 3.5

つぼ: iptc: std-草稿: IPTCの標準の"NITF"のためのNITF:3.5:仕様: xml-図式: 2Second草稿XML Schema、バージョン3.5

   urn:iptc:std:SportsML:1.0:xmlns
      URN to identify an XML namespace for the IPTC standard "SportsML",
      version 1.0.  No "res-name" and "res-version" since an XML
      namespace is of no physical format.

つぼ:iptc:std: IPTCの標準の"SportsML"のためのXML名前空間、バージョン1.0を特定するSportsML:1.0:xmlns URN。 XML名前空間以来の「res-名前」と「res-バージョン」がないのはどんな物理的な形式のものではありません。

   urn:iptc:std:NewsML:1.1:doc:news-agency-guidelines:1.2
      Supporting document named "news-agency-guidelines", version 1,
      revision 2, based on the IPTC standard "NewsML" version 1.1.

つぼ:iptc:std: NewsML:1.1:doc: ニュース政府機関ガイドライン: 「ニュース政府機関ガイドライン」という1.2Supportingドキュメント(バージョン1、改正2)は標準の"NewsML"バージョン1.1をIPTCに基礎づけました。

   urn:iptc:workdoc:NMA:0315:1:srs-terms
      Work document of IPTC's News Metadata Working Party (NMA), version
      1, holding terms of the Subject Reference System

つぼ:iptc:workdoc: NMA: 0315:1 : Workが記録するIPTCのNews Metadata Workingパーティ(NMA)のsrs-用語、バージョン1、Subject Reference Systemの用語を保持すること。

4.  Namespace Considerations and Community Considerations

4. 名前空間問題と共同体問題

   The IPTC acknowledged already the use of URNs during the development
   of its XML based standard "NewsML".  This standard implements the use
   of URNs as unique identifiers for news items as described in "URN
   Namespace for NewsML resources" [RFC3085].

IPTCは、XMLの開発の間のURNsの使用が標準の"NewsML"を基礎づけたと既に認めました。 この規格は「NewsMLリソースのためのURN Namespace」[RFC3085]で説明されるようにユニークな識別子としてのURNsの新聞記事項目の使用を実行します。

   While developing additional XML based standards as siblings to
   NewsML, IPTC soon got aware that URNs have to be assigned to
   resources that fall beyond the scope of the NewsML namespace.  For
   this reason IPTC developed a new and very general hierarchical
   namespace structure to cover the needs of the currently developed
   standards as well as future standards and to be able to assign URNs
   to resources emanating from them.

展開している追加XMLはNewsMLの兄弟として規格を基礎づけましたが、IPTCは、すぐ、URNsがNewsML名前空間の範囲に下がるリソースに割り当てられなければならないのを意識していました。 この理由で、IPTCは、将来の規格と同様に現在開発された規格の必要性を隠して、それらから発するリソースにURNsを割り当てることができるように新しくて非常に一般的な階層的な名前空間構造を発生しました。

   In addition to resources relating directly to its standards, IPTC
   also produces and publishes other documents relevant to the news
   business.  As those resources are used by many organizations outside
   the IPTC membership and therefore could not be considered as internal
   documents IPTC decided to add a branch to the URN hierarchy to be
   assigned to these resources.

直接規格に関連するリソースに加えて、IPTCはまた、ニュースビジネスに関連している他のドキュメントを製作して、発表します。 それらのリソースをIPTC会員資格の外における多くの組織が使用して、したがって、内部文書であるとみなすことができなかったので、IPTCは、これらのリソースに割り当てられるURN階層構造にブランチを追加すると決めました。

Steidl                       Informational                      [Page 6]

RFC 3937                 URN Namespace for IPTC             October 2004

IPTC2004年10月のためのSteidlの情報[6ページ]のRFC3937つぼの名前空間

   IPTC maintains global activities and its standards as well as
   resources based on them are used world wide.  Since one focus of the
   activities of IPTC is on global exchange of news any system for
   unique identification of resources has to be considered under global
   aspects.

IPTCは、それらに基づくリソースと同様にグローバルな活動とその規格が世界中で使用されると主張します。 ニュースの置換にはIPTCの活動の1つの焦点があるので、リソースのユニークな識別のどんなシステムもグローバルな局面の下で考えられなければなりません。

   For this reason IPTC considers the introduction of a URN namespace
   for its resources as proper action to maintain globally unique,
   persistent and location-independent identifiers based on open
   standards.

この理由で、IPTCは、適切な動きとしてのリソースが維持するURN名前空間の導入がグローバルにユニークであると考えます、オープンスタンダードに基づくしつこくて位置から独立している識別子。

5.  Security Considerations

5. セキュリティ問題

   There are no additional security considerations other than those
   normally associated with the use and resolution of URNs in general.

通常、一般に、URNsの使用と解決に関連づけられたもの以外の追加担保問題が全くありません。

6.  IANA Considerations

6. IANA問題

   This document includes a URN Namespace registration that conforms to
   the "Uniform Resources Names (URN) Namespace Definition Mechanism"
   [RFC3406] and has been entered into the IANA registry for URN NIDs.

このドキュメントは「一定のリソース名(つぼ)の名前空間定義メカニズム」[RFC3406]に従って、URN NIDsのためにIANA登録に入れられたURN Namespace登録を含んでいます。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, May 1997.

[RFC2141]モウツ(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。

   [RFC3406]  Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
              "Uniform Resource Names (URN) Namespace Definition
              Mechanisms", BCP 66, RFC 3406, October 2002.

[RFC3406] Daigle、L.、バンGulik、D.、Iannella、R.、およびP.Faltstrom、「一定のリソースは(つぼ)名前空間定義をメカニズムと命名します」、BCP66、RFC3406、2002年10月。

7.2.  Informative References

7.2. 有益な参照

   [W3CXML]   W3C, XML WG, "Extensible Markup Language (XML) 1.0" (Third
              Edition), February 2004, <http://www.w3.org/TR/REC-xml>.

[W3CXML] W3C、XML WG、「拡張マークアップ言語(XML)1インチ(第3版)、2004年2月、<http://www.w3.org/TR/REC-xml>。」

   [W3CXMLNS] W3C, Namespaces WG, "Namespaces in XML", January 1999,
              <http://www.w3.org/TR/REC-xml-names>.

1999年1月に、[W3CXMLNS]W3C、名前空間WG、「XMLの名前空間」と、<は>とhttp://www.w3.org/TR/REC-xml命名します。

   [RFC3085]  Coates, A., Allen, D. and D. Rivers-Moore, "URN Namespace
              for NewsML Resources", RFC 3085, March 2001.

[RFC3085] コーツとA.とアレンとD.とD.川ムーア、「NewsMLリソースのためのつぼの名前空間」、RFC3085、2001年3月。

Steidl                       Informational                      [Page 7]

RFC 3937                 URN Namespace for IPTC             October 2004

IPTC2004年10月のためのSteidlの情報[7ページ]のRFC3937つぼの名前空間

Author's Address

作者のアドレス

   Michael Steidl
   IPTC (International Press Telecommunications Council)
   Royal Albert House
   Sheet Street
   Windsor SL4 1BE
   United Kingdom

マイケルSteidl IPTC(国際新聞通信委員会)ロイヤル・アルバート家のシート通りウインザー・SL4 1BEイギリス

   Phone: +44 (1753) 705 051
   EMail: mdirector@iptc.org

以下に電話をしてください。 +44(1753) 705 051はメールされます: mdirector@iptc.org

Steidl                       Informational                      [Page 8]

RFC 3937                 URN Namespace for IPTC             October 2004

IPTC2004年10月のためのSteidlの情報[8ページ]のRFC3937つぼの名前空間

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

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

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and 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 IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

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

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Steidl                       Informational                      [Page 9]

Steidl情報です。[9ページ]

一覧

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

スポンサーリンク

<INPUT> フォームの構成部品(入力欄・ボタン等)を作成する

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

上に戻る