RFC4151 日本語訳
4151 The 'tag' URI Scheme. T. Kindberg, S. Hawke. October 2005. (Format: TXT=22555 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Kindberg Request for Comments: 4151 Hewlett-Packard Corporation Category: Informational S. Hawke World Wide Web Consortium October 2005
Kindbergがコメントのために要求するワーキンググループT.をネットワークでつないでください: 4151年のヒューレット・パッカード社のカテゴリ: 情報のS.ホークワールドワイドウェブコンソーシアム2005年10月
The 'tag' URI Scheme
'タグ'URI計画
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 (2005).
Copyright(C)インターネット協会(2005)。
Disclaimer
注意書き
The views and opinions of authors expressed herein do not necessarily state or reflect those of the World Wide Web Consortium, and may not be used for advertising or product endorsement purposes. This proposal has not undergone technical review within the Consortium and must not be construed as a Consortium recommendation.
ここに言い表された作者の視点と意見は、必ずワールドワイドウェブコンソーシアムのものを述べるというわけではありませんし、また反映するというわけではなくて、広告か製品推奨目的に使用されないかもしれません。 この提案は、Consortiumの中で技術審査を受けていなくて、Consortium推薦に理解されてはいけません。
Abstract
要約
This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources.
このドキュメントは「タグ」Uniform Resource Identifier(URI)計画について説明します。 タグURI(また、「タグ」として、知られている)は、人間にとって御しやすい間、スペースと時間の向こう側に特有になるように設計されています。 それらは他のほとんどのURIとそれらにはどんな正式の解決メカニズムもないという点において異なっています。 タグはエンティティ識別名として純粋に使用されるかもしれません。 その上、タグを使用するのにおいて、アクセスしやすい非HTTPリソースに識別子として"http"URIを使用する一般的な習慣よりいくつかの利点があります。
Kindberg & Hawke Informational [Page 1] RFC 4151 Tag URIs October 2005
[1ページ]RFC4151タグURI2005年10月の情報のKindbergとホーク
Table of Contents
目次
1. Introduction ....................................................2 1.1. Terminology ................................................3 1.2. Further Information and Discussion of this Document ........4 2. Tag Syntax and Rules ............................................4 2.1. Tag Syntax and Examples ....................................4 2.2. Rules for Minting Tags .....................................5 2.3. Resolution of Tags .........................................7 2.4. Equality of Tags ...........................................7 3. Security Considerations .........................................7 4. IANA Considerations .............................................8 5. References ......................................................9 5.1. Normative References .......................................9 5.2. Informative References .....................................9
1. 序論…2 1.1. 用語…3 1.2. このDocumentのさらなる情報とDiscussion…4 2. 構文と規則にタグ付けをしてください…4 2.1. 構文と例にタグ付けをしてください…4 2.2. タグを造幣するための規則…5 2.3. タグの解決…7 2.4. タグの平等…7 3. セキュリティ問題…7 4. IANA問題…8 5. 参照…9 5.1. 標準の参照…9 5.2. 有益な参照…9
1. Introduction
1. 序論
A tag is a type of Uniform Resource Identifier (URI) [1] designed to meet the following requirements:
タグは以下の必要条件を満たすように設計された一種のUniform Resource Identifier(URI)[1]です:
1. Identifiers are likely to be unique across space and time, and come from a practically inexhaustible supply.
1. 識別子は、スペースと時間の向こう側にユニークであり、実際に根気のよい供給から来そうです。
2. Identifiers are relatively convenient for humans to mint (create), read, type, remember etc.
2. 人間が造幣すること(作成する)に識別子は比較的便利であり、読んでください、そして、タイプしてください、そして、などを覚えていてください。
3. No central registration is necessary, at least for holders of domain names or email addresses; and there is negligible cost to mint each new identifier.
3. どんな主要な登録も少なくともドメイン名かEメールアドレスの所有者に必要ではありません。 そして、それぞれの新しい識別子を造幣するために、取るにたらない費用があります。
4. The identifiers are independent of any particular resolution scheme.
4. 識別子はどんな特定の解決計画からも独立しています。
For example, the above requirements may apply in the case of a user who wants to place identifiers on their documents:
例えば、上記の要件はそれらのドキュメントに識別子を置きたがっているユーザの場合で適用されるかもしれません:
a. The user wants to be reasonably sure that the identifier is unique. Global uniqueness is valuable because it prevents identifiers from becoming unintentionally ambiguous.
a。 ユーザは、識別子がユニークであることを合理的に確信していたがっています。 識別子が何気なくあいまいになるのを防ぐので、グローバルなユニークさは貴重です。
b. The identifiers should be tractable to the user, who should, for example, be able to mint new identifiers conveniently, to memorise them, and to type them into emails and forms.
b。 ユーザにとって、識別子は御しやすいはずです。(そのユーザは、便利に新しい識別子を造幣して、それらを記憶して、例えば、メールとフォームにそれらをタイプできるべきです)。
c. The user does not want to have to communicate with anyone else in order to mint identifiers for their documents.
c。 ユーザは、それらのドキュメントのための識別子を造幣するために他の誰ともコミュニケートしなければならなくて欲しくはありません。
Kindberg & Hawke Informational [Page 2] RFC 4151 Tag URIs October 2005
[2ページ]RFC4151タグURI2005年10月の情報のKindbergとホーク
d. The user wants to avoid identifiers that might be taken to imply the existence of an electronic resource accessible via a default resolution mechanism, when no such electronic resource exists.
d。 ユーザはデフォルト解決メカニズムを通してアクセス可能な電子リソースの存在を含意するために取られるかもしれない識別子を避けたがっています、そのような何か電子リソースが存在していないと。
Existing identification schemes satisfy some, but not all, of the requirements above. For example:
既存の識別計画はすべてではなく、上記の要件のいくつかを満たします。 例えば:
UUIDs [5], [6] are hard for humans to read.
人間にとって、UUIDs[5]、[6]は読むのが困難です。
OIDs [7], [8] and Digital Object Identifiers [9] require entities to register as naming authorities, even in cases where the entity already holds a domain name registration.
OIDs[7]、[8]、およびDigital Object Identifiers[9]は当局を任命するとして登録するために実体を必要とします、実体が既にドメイン名登録を保持する場合でさえ。
URLs (in particular, "http" URLs) are sometimes used as identifiers that satisfy most of the above requirements. Many users and organisations have already registered a domain name, and the use of the domain name to mint identifiers comes at no additional cost. But there are drawbacks to URLs-as-identifiers:
URL(特に"http"URL)は上記の要件の大部分を満たす識別子として時々使用されます。 多くのユーザと機構は既にドメイン名を登録しました、そして、識別子を造幣するドメイン名の使用はどんな別途費用でも来ません。 しかし、識別子としてのURLへの欠点があります:
o An attempt may be made to resolve a URL-as-identifier, even though there is no resource accessible at the "location".
o 「位置」でアクセス可能などんなリソースもありませんが、識別子としてのURLを決議するのを試みをするかもしれません。
o Domain names change hands and the new assignee of a domain name can't be sure that they are minting new names. For example, if example.org is assigned first to a user Smith and then to a user Jones, there is no systematic way for Jones to tell whether Smith has already used a particular identifier such as http://example.org/9999.
o ドメイン名は持主が変わります、そして、ドメイン名の新しい指定代理人は新しい名前を造幣しているのを確信しているはずがありません。 例えば、example.orgが最初にユーザスミスと、そして、そして、ユーザジョーンズに割り当てられるなら、ジョーンズが、スミスが既に http://example.org/9999 などの特定の識別子を使用したかどうか言う系統立った方法が全くありません。
o Entities could rely on purl.org or a similar service as a (first-come, first-served) assigner of unique URIs; but a solution without reliance upon another entity such as the Online Computer Library Center (OCLC, which runs purl.org) may be preferable.
o 実体はユニークなURIの(先着順)指定人としてpurl.orgか同様のサービスに依存するかもしれません。 しかし、オンライン・コンピュータ図書館センター(purl.orgを走らせるOCLC)などの別の実体への信用のない解決策は望ましいかもしれません。
Lastly, many entities -- especially individuals -- are assignees of email addresses but not domain names. It would be preferable to enable those entities to mint unique identifiers.
最後に、多くの実体(特に個人)がドメイン名ではなく、Eメールアドレスの指定代理人です。 それらの実体がユニークな識別子を造幣するのを可能にするのは望ましいでしょう。
1.1. Terminology
1.1. 用語
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 RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
Kindberg & Hawke Informational [Page 3] RFC 4151 Tag URIs October 2005
[3ページ]RFC4151タグURI2005年10月の情報のKindbergとホーク
1.2. Further Information and Discussion of this Document
1.2. このDocumentのさらなる情報とDiscussion
Additional information about the tag URI scheme -- motivation, genesis, and discussion -- can be obtained from http://www.taguri.org.
http://www.taguri.org からタグURI計画に関する追加情報(動機、起源、および議論)を得ることができます。
Earlier versions of this document have been discussed on uri@w3.org. The authors welcome further discussion and comments.
uri@w3.org でこのドキュメントの以前のバージョンについて議論しました。 作者はさらなる議論とコメントを歓迎します。
2. Tag Syntax and Rules
2. タグ構文と規則
This section first specifies the syntax of tag URIs and gives examples. It then describes a set of rules for minting tags that is designed to make them unique. Finally, it discusses the resolution and comparison of tags.
このセクションは、最初に、タグURIの構文を指定して、例を挙げます。 そして、それはタグを造幣するためのそれらをユニークにするように設計されている1セットの規則について説明します。 最終的に、それはタグの解決と比較について議論します。
2.1. Tag Syntax and Examples
2.1. タグ構文と例
The general syntax of a tag URI, in ABNF [2], is:
ABNF[2]では、タグURIの一般的な構文は以下の通りです。
tagURI = "tag:" taggingEntity ":" specific [ "#" fragment ]
tagURI=は「以下にタグ付けをします」。 "taggingEntity":、」 特定[「#」断片]
Where:
どこ:
taggingEntity = authorityName "," date authorityName = DNSname / emailAddress date = year ["-" month ["-" day]] year = 4DIGIT month = 2DIGIT day = 2DIGIT DNSname = DNScomp *( "." DNScomp ) ; see RFC 1035 [3] DNScomp = alphaNum [*(alphaNum /"-") alphaNum] emailAddress = 1*(alphaNum /"-"/"."/"_") "@" DNSname alphaNum = DIGIT / ALPHA specific = *( pchar / "/" / "?" ) ; pchar from RFC 3986 [1] fragment = *( pchar / "/" / "?" ) ; same as RFC 3986 [1]
「taggingEntityはauthorityNameと等しいです」、DNSname / emailAddress日付=4DIGIT月=の2DIGIT日=の年=年[「-」月[「-」日]]の」 日付authorityName=2DIGIT DNSname=DNScomp*(「.」 DNScomp)。 「RFC1035[3]DNScompがalphaNumと等しいのを見てください、[*、(alphaNum/、」、--、」、)、alphaNum] emailAddress=1*、(alphaNum/、」、--、」 」 /」 . 」 /_、」、)、"@"DNSname alphaNumはケタ/アルファの特定の=*(pchar/」 /」 /“?")と等しいです。 「RFC3986[1]断片からのpcharは*(pchar/」 /」 /“?")と等しいです。 RFC3986と同じこと[1]
The component "taggingEntity" is the name space part of the URI. To avoid ambiguity, the domain name in "authorityName" (whether an email address or a simple domain name) MUST be fully qualified. It is RECOMMENDED that the domain name should be in lowercase form. Alternative formulations of the same authority name will be counted as distinct and, hence, tags containing them will be unequal (see Section 2.4). For example, tags beginning "tag:EXAMPLE.com,2000:" are never equal to those beginning "tag:example.com,2000:", even though they refer to the same domain name.
コンポーネント"taggingEntity"はURIの名前スペース一部です。 あいまいさを避けるために、完全に"authorityName"(Eメールアドレスか簡単なドメイン名であることにかかわらず)のドメイン名に資格がなければなりません。 ドメイン名が小文字のフォームにあるべきであるのは、RECOMMENDEDです。 同じ権威名の代替の定式化は異なるとして数えられるでしょう、そして、したがって、それらを含むタグは不平等でしょう(セクション2.4を見てください)。 例えば、タグ始めは「: EXAMPLE.com、2000に以下にタグ付けをします」。 決してそれらへのどんな同輩も始めていません。「タグ: example.com、2000:」 彼らは同じドメイン名を示しますが。
Kindberg & Hawke Informational [Page 4] RFC 4151 Tag URIs October 2005
[4ページ]RFC4151タグURI2005年10月の情報のKindbergとホーク
Authority names could, in principle, belong to any syntactically distinct namespaces whose names are assigned to a unique entity at a time. Those include, for example, certain IP addresses, certain MAC addresses, and telephone numbers. However, to simplify the tag scheme, we restrict authority names to domain names and email addresses. Future standards efforts may allow use of other authority names following syntax that is disjoint from this syntax. To allow for such developments, software that processes tags MUST NOT reject them on the grounds that they are outside the syntax defined above.
権威名は原則として名前が一度にユニークな実体に割り当てられるどんなシンタクス上異なった名前空間にも属すかもしれません。 ものは例えば、あるIPアドレス、あるMACアドレス、および電話番号を含んでいます。 しかしながら、タグ計画を簡素化するために、私たちは権威名をドメイン名とEメールアドレスに制限します。 努力が構文に従う他の権威名の使用を許すかもしれない将来の規格はこの構文からばらばらになります。 上で定義された構文の外でそれらがあるので、そのような開発を考慮するために、タグを処理するソフトウェアはそれらを拒絶してはいけません。
The component "specific" is the name-space-specific part of the URI: it is a string of URI characters (see restrictions in syntax specification) chosen by the minter of the URI. Note that the "specific" component allows for "query" subcomponents as defined in RFC 3986 [1]. It is RECOMMENDED that specific identifiers should be human-friendly.
コンポーネント「詳細」はURIの名前スペース詳細部分です: それはURIのminterによって選ばれた一連のURIキャラクタ(構文仕様で制限を見る)です。 「特定」のコンポーネントがRFC3986[1]で定義されるように「質問」サブコンポーネントを考慮することに注意してください。 特定の識別子が人間に優しいはずであるのは、RECOMMENDEDです。
Tag URIs may optionally end in a fragment identifier, in accordance with the general syntax of RFC 3986 [1].
RFC3986[1]の一般的な構文に応じて、タグURIは断片識別子に任意に終わるかもしれません。
In the interests of tractability to humans, tags SHOULD NOT be minted with percent-encoded parts. However, the tag syntax does allow percent-encoded characters in the "pchar" elements (defined in RFC 3986 [1]).
人間、タグSHOULD NOTに御しやすさであることのためにパーセントでコード化された部品で、造幣されてください。 しかしながら、タグ構文は"pchar"要素にパーセントでコード化されたキャラクタを許容します。(RFC3986[1])では、定義されます。
Examples of tag URIs are:
タグURIに関する例は以下の通りです。
tag:timothy@hpl.hp.com,2001:web/externalHome tag:sandro@w3.org,2004-05:Sandro tag:my-ids.com,2001-09-15:TimKindberg:presentations:UBath2004-05-19 tag:blogger.com,1999:blog-555 tag:yaml.org,2002:int
タグ: timothy@hpl.hp.com 、2001: ウェブ/externalHomeタグ: sandro@w3.org 、2004-05: サンドロスタグ:、私、-、ids.com、2001年9月15日:TimKindberg:プレゼンテーション: UBath2004-05-19タグ: blogger.com、1999: ブロッグ-555タグ: yaml.org、2002:、int
2.2. Rules for Minting Tags
2.2. タグを造幣するための規則
As Section 2.1 has specified, each tag includes a "tagging entity" followed, optionally, by a specific identifier. The tagging entity is designated by an "authority name" -- a fully qualified domain name or an email address containing a fully qualified domain name -- followed by a date. The date is chosen to make the tagging entity globally unique, exploiting the fact that domain names and email addresses are assigned to at most one entity at a time. That entity then ensures that it mints unique identifiers.
セクション2.1が指定したように、各タグは「タグ付け実体」を含んでいます、続いて、任意に特定の識別子を含んでいます。 日付までに続かれる「権威名」(完全修飾ドメイン名を含む完全修飾ドメイン名かEメールアドレス)によってタグ付け実体は指定されます。 日付はタグ付け実体をグローバルにユニークにするように選ばれています、ドメイン名とEメールアドレスが一度に高々1つの実体しか割り当てられないという事実を利用して。 そして、その実体は、ユニークな識別子を造幣するのを確実にします。
The date specifies, according to the Gregorian calendar and UTC, any particular day on which the authority name was assigned to the tagging entity at 00:00 UTC (the start of the day). The date MAY be a past or present date on which the authority name was assigned at
日付は指定します、グレゴリオ暦とUTCによると、権威名が協定世界時0時0分(1日の始まり)にタグ付け実体に割り当てられたどんな特定の日。 権威名がどれで割り当てられたかに関して、日付は、過去であるか日付を提示するかもしれません。
Kindberg & Hawke Informational [Page 5] RFC 4151 Tag URIs October 2005
[5ページ]RFC4151タグURI2005年10月の情報のKindbergとホーク
that moment. The date is specified using one of the "YYYY", "YYYY-MM" and "YYYY-MM-DD" formats allowed by the ISO 8601 standard [4] (see also RFC 3339 [10]). The tag specification permits no other formats. Tagging entities MUST ascertain the date with sufficient accuracy to avoid accidentally using a date on which the authority name was not, in fact, assigned (many computers and mobile devices have poorly synchronised clocks). The date MUST be reckoned from UTC, which may differ from the date in the tagging entity's local timezone at 00:00 UTC. That distinction can generally be safely ignored in practice, but not on the day of the authority name's assignment. In principle it would otherwise be possible on that day for the previous assignee and the new assignee to use the same date and, thus, mint the same tags.
その瞬間。 」 形式はISO8601で規格[4]を許容しました。そして、日付が"YYYY"の1つ、「YYYY-mm」を使用することで指定される、「YYYY mm DD、(また、RFC3339[10])を見てください。 タグ仕様は他の形式を全く可能にしません。 タグ付け実体は、偶然事実上、権威名が割り当てられなかった日付を使用するのを避けるために十分正確に日付を確かめなければなりません(多くのコンピュータとモバイル機器には、連動した時計が不十分にあります)。 UTCから日付を数えなければなりません。(UTCは協定世界時0時0分にタグ付け実体のローカルのタイムゾーンにおいて日付と異なるかもしれません)。 その区別は実際には一般に安全に無視されますが、権威名前の課題の日に無視できません。 そうでなければ、原則として、前の指定代理人と新しい指定代理人が同じ日付を使用して、その結果、同じタグを造幣するのは、当日、可能でしょう。
In the interests of brevity, the month and day default to "01". A day value of "01" MAY be omitted; a month value of "01" MAY be omitted unless it is followed by a day value other than "01". For example, "2001-07" is the date 2001-07-01 and "2000" is the date 2000-01-01. All date formulations specify a moment (00:00 UTC) of a single day, and not a period of a day or more such as "the whole of July 2001" or "the whole of 2000". Assignment at that moment is all that is required to use a given date.
簡潔さのために、月と日は「1インチ」をデフォルトとします。 「1インチは省略されるかもしれない」日の値。 月の値、「「1インチ」を除いた日の値がそれのあとに続いていない場合、1インチは省略されるかもしれません。 例えば、「2001、-7インチがそうである、2001年7月1日の日付と「2000年はインチ2000年1月1日の日付です」。 すべての日付の定式化が1日以上の期間ではなく、1日の「2001年7月の全体」か「2000年の全体」などの瞬間(協定世界時0時0分)を指定します。 その瞬間での課題は与えられた期日を使用するのに必要であるすべてです。
Tagging entities should be aware that alternative formulations of the same date will be counted as distinct and, hence, tags containing them will be unequal. For example, tags beginning "tag:example.com,2000:" are never equal to those beginning "tag:example.com,2000-01-01:", even though they refer to the same date (see Section 2.4).
タグ付け実体は同じ日付の代替の定式化が異なるとして数えられるのを意識しているべきです、そして、したがって、それらを含むタグが不平等になるでしょう。 例えばタグが始まる、「タグ: example.com、2000:」 決して等しくない、それらの始めまでの、「: example.com、2000年1月1日にタグ付けをしてください」、彼らは同じくらい言及しますが、デートしてください(セクション2.4を見てください)。
An entity MUST NOT mint tags under an authority name that was assigned to a different entity at 00:00 UTC on the given date, and it MUST NOT mint tags under a future date.
実体は与えられた期日協定世界時0時0分に異なった実体に割り当てられた権威名の下でタグを造幣してはいけません、そして、それは将来の期日の下でタグを造幣してはいけません。
An entity that acquires an authority name immediately after a period during which the name was unassigned MAY mint tags as if the entity were assigned the name during the unassigned period. This practice has considerable potential for error and MUST NOT be used unless the entity has substantial evidence that the name was unassigned during that period. The authors are currently unaware of any mechanism that would count as evidence, other than daily polling of the "whois" registry.
まるで名前が割り当てられなかった期間、実体に割り当てられるかのように名前が割り当てられなかった期間直後権威名を習得する実体はタグを造幣するかもしれません。 実体に名前がその期間割り当てられなかったという実質証拠がない場合、この習慣は、誤りのかなりの可能性を持って、使用されてはいけません。 作者は現在証拠にみなすどんなメカニズムにも気づきません、"whois"登録の毎日の世論調査を除いて。
For example, Hewlett-Packard holds the domain registration for hp.com and may mint any tags rooted at that name with a current or past date when it held the registration. It must not mint tags, such as "tag:champignon.net,2001:", under domain names not registered to it. It must not mint tags dated in the future, such as
例えば、ヒューレット・パッカードは、hp.comのためにドメインの取得を保持して、それが登録を開催した電流か過去の日付でその名前で根づいているどんなタグも造幣するかもしれません。 それ、ミントタグではなく、必須と、そのようなもの、それに登録されなかったドメイン名の下における「: champignon.net、2001にタグ付けをしてください。」 それは将来、そのようなものとして日付を入れられたタグを造幣してはいけません。
Kindberg & Hawke Informational [Page 6] RFC 4151 Tag URIs October 2005
[6ページ]RFC4151タグURI2005年10月の情報のKindbergとホーク
"tag:hp.com,2999:". If it obtains assignment of "extremelyunlikelytobeassigned.org" on 2001-05-01, then it must not mint tags under "extremelyunlikelytobeassigned.org,2001-04-01" unless it has evidence proving that name was continuously unassigned between 2001-04-01 and 2001-05-01.
「: hp.com、2999にタグ付けをしてください。」 2001年5月1日の"extremelyunlikelytobeassigned.org"の課題を得て、名前が2001年4月1日と2001年5月1日の間で絶え間なく割り当てられなかったと立証する証拠がない場合、それは「extremelyunlikelytobeassigned.org、2001年4月1日」の下のタグを造幣してはいけません。
A tagging entity mints specific identifiers that are unique within its context, in accordance with any internal scheme that uses only URI characters. Tagging entities SHOULD use record-keeping procedures to achieve uniqueness. Some tagging entities (e.g., corporations, mailing lists) consist of many people, in which case group decision-making SHOULD also be used to achieve uniqueness. The outcome of such decision-making could be to delegate control over parts of the namespace. For example, the assignees of example.com could delegate control over all tags with the prefixes "tag:example.com,2004:fred:" and "tag:example.com,2004:bill:", respectively, to the individuals with internal names "fred" and "bill" on 2004-01-01.
タグ付け実体は文脈の中でユニークな特定の識別子を造幣します、URIキャラクタだけを使用するどんな内部の計画通りに。 タグ付け実体SHOULDは、ユニークさを獲得するのに記録保存手順を用います。 いくつかのタグ付け実体(例えば、会社、メーリングリスト)が多くの人々から成ります、またユニークさを獲得するのにSHOULDを決定して使用させるどのケースグループに。 そのような意志決定の結果は名前空間の部品のコントロールを代表として派遣することであることができました。 例えば、example.comの指定代理人が接頭語があるすべてのタグのコントロールを代表として派遣することができた、「タグ: example.com、2004:、fred:、」 そして、「タグ: example.com、2004: 請求書:、」、それぞれ、2004年1月1日の内部名"fred"と「請求書」をもっている個人に。
2.3. Resolution of Tags
2.3. タグの解決
There is no authoritative resolution mechanism for tags. Unlike most other URIs, tags can only be used as identifiers, and are not designed to support resolution. If authoritative resolution is a desired feature, a different URI scheme should be used.
タグのためのどんな正式の解決メカニズムもありません。 他のほとんどのURIと異なって、タグは、識別子として使用できるだけであって、解決を支持するように設計されていません。 正式の解決が必要な特徴であるなら、異なったURI計画は使用されるべきです。
2.4. Equality of Tags
2.4. タグの平等
Tags are simply strings of characters and are considered equal if and only if they are completely indistinguishable in their machine representations when using the same character encoding. That is, one can compare tags for equality by comparing the numeric codes of their characters, in sequence, for numeric equality. This criterion for equality allows for simplification of tag-handling software, which does not have to transform tags in any way to compare them.
そして、タグが単にキャラクタのストリングであり、等しいと考えられる、同じキャラクタコード化を使用するとき、彼らがマシン表現において完全に区別がつかない場合にだけ。 すなわち、1つは平等のために彼らの性格の数字コードを比較することによって、タグを比較できます、連続して、数値平等のために。 平等のためのこの評価基準は、何らかの方法でタグを変える必要はないタグ取り扱いソフトウェアの簡素化がそれらを比較するのを許容します。
3. Security Considerations
3. セキュリティ問題
Minting a tag, by itself, is an operation internal to the tagging entity, and has no external consequences. The consequences of using an improperly minted tag (due to malice or error) in an application depends on the application, and must be considered in the design of any application that uses tags.
それ自体でタグを造幣するのは、タグ付け実体への内部の操作であり、どんな外部の結果も持っていません。 アプリケーションで不適切に造幣されたタグ(悪意か誤りによる)を使用する結果はアプリケーションによって、タグを使用するどんなアプリケーションの設計でも考えなければなりません。
There is a significant possibility of minting errors by people who fail to apply the rules governing dates, or who use a shared (organizational) authority-name without prior organization-wide agreement. Tag-aware software MAY help catch and warn against these
日付を決定する規則を適用しないか、または共有された(組織的な)権威名を使用する人々による誤りを造幣する重要な可能性が先の組織全体の協定なしであります。 タグ意識しているソフトウェアは、これらに対して捕らえて、警告するのを助けるかもしれません。
Kindberg & Hawke Informational [Page 7] RFC 4151 Tag URIs October 2005
[7ページ]RFC4151タグURI2005年10月の情報のKindbergとホーク
errors. As stated in Section 2, however, to allow for future expansion, software MUST NOT reject tags which do not conform to the syntax specified in Section 2.
誤り。 しかしながら、今後の拡大を考慮するためにセクション2に述べられているように、ソフトウェアはセクション2で指定された構文に一致していないタグを拒絶してはいけません。
A malicious party could make it appear that the same domain name or email address was assigned to each of two or more entities. Tagging entities SHOULD use reputable assigning authorities and verify assignment wherever possible.
悪意があるパーティーはそれが、同じドメイン名かEメールアドレスがそれぞれの2つ以上の実体に割り当てられたのを現れさせることができました。 タグ付け実体SHOULDは評判のよい割り当てている当局を使用して、どこでも、可能であるところで課題について確かめます。
Entities SHOULD also avoid the potential for malicious exploitation of clock skew, by using authority names that were assigned continuously from well before to well after 00:00 UTC on the date chosen for the tagging entity -- preferably by intervals in the order of days.
また、実体SHOULDは時計斜行の悪意がある開発の可能性を避けます、何日もの注文で望ましくはタグ付け実体に選ばれた日付、間隔で協定世界時0時0分以降以前井戸から井戸に絶え間なく割り当てられた権威名を使用することによって。
4. IANA Considerations
4. IANA問題
The IANA has registered the tag URI scheme as specified in this document and summarised in the following template:
IANAは本書では指定されて、以下のテンプレートで略言するようにタグURI計画を登録しました:
URI scheme name: tag
URI計画名: タグ
Status: permanent
状態: 永久的
URI scheme syntax: see Section 2
URI計画構文: セクション2を見てください。
Character encoding considerations: percent-encoding is allowed in 'specific' and 'fragment' components (see Section 2)
問題をコード化するキャラクター: パーセントコード化は'特定'と'断片'コンポーネントで許されています。(セクション2を見ます)
Intended usage: see Section 1 and Section 2.3
意図している用法: セクション1とセクション2.3を見てください。
Applications and/or protocols that use this URI scheme name: Any applications that use URIs as identifiers without requiring dereference, such as RDF, YAML, and Atom.
このURI計画名を使用するアプリケーション、そして/または、プロトコル: 識別子としてリモート・データ・ファシリティや、YAMLや、Atomなどの反参照を必要としないでURIを使用するどんなアプリケーション。
Interoperability considerations: none
相互運用性問題: なし
Security considerations: see Section 3
セキュリティ問題: セクション3を見てください。
Relevant publications: none
関連刊行物: なし
Contact: Tim Kindberg (timothy@hpl.hp.com) and Sandro Hawke (sandro@w3.org)
接触: ティムKindberg( timothy@hpl.hp.com )とサンドロスホーク( sandro@w3.org )
Author/Change controller: Tim Kindberg and Sandro Hawke
コントローラを書くか、または変えてください: ティムKindbergとサンドロスホーク
Kindberg & Hawke Informational [Page 8] RFC 4151 Tag URIs October 2005
[8ページ]RFC4151タグURI2005年10月の情報のKindbergとホーク
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[1]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[3] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[3]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[4] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO (International Organization for Standardization) ISO 8601:1988, 1988.
[4] 「データ要素と置き換えは日付と回の表現をフォーマット(情報交換)」、ISO(国際標準化機構)ISO。8601:1988 1988。
5.2. Informative References
5.2. 有益な参照
[5] Leach, P. and R. Salz, "UUIDs and GUIDs", Work in Progress, 1997.
[5] 「UUIDsとGUIDs」というリーチ、P.、およびR.ザルツは進歩、1997年に働いています。
[6] "Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)", ISO (International Organization for Standardization) ISO/IEC 11578:1996, 1996.
[6]「情報技術--オープン・システム・インターコネクション--リモートProcedure Call(RPC)」、ISO(国際標準化機構)ISO/IEC、11578:1996 1996。
[7] "Specification of abstract syntax notation one (ASN.1)", ITU-T recommendation X.208, (see also RFC 1778), 1988.
[7] 「抽象構文記法1(ASN.1)の仕様」、ITU-T推薦X.208、(参照、RFC1778)、1988
[8] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061, February 2001.
[8] 食事、M.、「物の識別子のつぼの名前空間」、RFC3061、2001年2月。
[9] Paskin, N., "Information Identifiers", Learned Publishing Vol. 10, No. 2, pp. 135-156, (see also www.doi.org), April 1997.
[9]Paskin、N.、「情報識別子」、Learned出版Vol.10、No.2、ページ 135-156 1997年4月の(参照、www.doi.org。)
[10] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[10] Klyne(G.とC.ニューマン)は「インターネットで以下の日付を入れて、調節します」。 「タイムスタンプ」、RFC3339、2002年7月。
Kindberg & Hawke Informational [Page 9] RFC 4151 Tag URIs October 2005
[9ページ]RFC4151タグURI2005年10月の情報のKindbergとホーク
Authors' Addresses
作者のアドレス
Tim Kindberg Hewlett-Packard Corporation Hewlett-Packard Laboratories Filton Road Stoke Gifford Bristol BS34 8QZ UK
ティム・Kindbergヒューレット・パッカード社のヒューレット・パッカード研究所Filton道路ストークギフォード・ブリストルBS34 8QZイギリス
Phone: +44 117 312 9920 EMail: timothy@hpl.hp.com
以下に電話をしてください。 +44 9920年の117 312メール: timothy@hpl.hp.com
Sandro Hawke World Wide Web Consortium 32 Vassar Street Building 32-G508 Cambridge, MA 02139 USA
サンドロスホークワールドワイドウェブコンソーシアム32ハッサー通りビル32-G508MA02139ケンブリッジ(米国)
Phone: +1 617 253-7288 EMail: sandro@w3.org
以下に電話をしてください。 +1 617 253-7288 メールしてください: sandro@w3.org
Kindberg & Hawke Informational [Page 10] RFC 4151 Tag URIs October 2005
[10ページ]RFC4151タグURI2005年10月の情報のKindbergとホーク
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kindberg & Hawke Informational [Page 11]
KindbergとホークInformationalです。[11ページ]
一覧
スポンサーリンク