[要約] RFC 4151は、タグURIスキームに関する仕様であり、タグURIを作成するための構文と解析方法を提供しています。その目的は、一意の識別子を作成し、リソースのタグ付けと参照を容易にすることです。
Network Working Group T. Kindberg
Request for Comments: 4151 Hewlett-Packard Corporation
Category: Informational S. Hawke
World Wide Web Consortium
October 2005
The 'tag' URI Scheme
「タグ」URIスキーム
Status of this 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）The Internet Society（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.
本書に記載されている著者の見解や意見は、必ずしもWorld Wide Web 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.
このドキュメントでは、「タグ」のURI（Uniform Resource Identifier）スキームについて説明します。タグURI（「タグ」とも呼ばれます）は、人間が扱いやすいように、空間と時間にわたって一意になるように設計されています。信頼できる解決メカニズムがないという点で、他のほとんどのURIとは異なります。タグは、純粋にエンティティ識別子として使用できます。さらに、タグを使用すると、HTTPでアクセスできないリソースの識別子として「http」URIを使用する一般的な方法よりもいくつかの利点があります。
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
A tag is a type of Uniform Resource Identifier (URI) [1] designed to meet the following requirements:
タグは、次の要件を満たすように設計されたURI（Uniform Resource Identifier）の一種です。
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. 少なくともドメイン名または電子メールアドレスを所有している場合は、集中登録は不要です。そして、それぞれの新しい識別子を作成するためのコストはごくわずかです。
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. ユーザーは、ドキュメントの識別子を作成するために他の人と通信する必要はありません。
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.
UUID [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.
OID [7]、[8]、およびデジタルオブジェクト識別子[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が最初にユーザーSmithに割り当てられ、次にユーザーJonesに割り当てられた場合、JonesがSmithが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.
最後に、多くのエンティティ（特に個人）は、電子メールアドレスの割り当て先ですが、ドメイン名ではありません。これらのエンティティが一意の識別子を作成できるようにすることをお勧めします。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119で説明されているように解釈されます。
Additional information about the tag URI scheme -- motivation, genesis, and discussion -- can be obtained from http://www.taguri.org.
タグのURIスキームに関する追加情報（動機、生成、およびディスカッション）は、http：//www.taguri.orgから入手できます。
Earlier versions of this document have been discussed on uri@w3.org. The authors welcome further discussion and comments.
このドキュメントの以前のバージョンは、uri @ w3.orgで議論されています。著者はさらなる議論とコメントを歓迎します。
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の構文を指定し、例を示します。次に、タグを一意にするために設計されたタグを作成するための一連のルールについて説明します。最後に、タグの解決と比較について説明します。
The general syntax of a tag URI, in ABNF [2], is:
ABNF [2]でのタグURIの一般的な構文は次のとおりです。
tagURI = "tag:" taggingEntity ":" specific [ "#" fragment ]
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]
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」のドメイン名（電子メールアドレスか単純なドメイン名かに関係なく）は完全修飾する必要があります。ドメイン名は小文字の形式にすることをお勧めします。同じオーソリティ名の別の定式化は個別として数えられるため、それらを含むタグは等しくありません（セクション2.4を参照）。たとえば、「tag：EXAMPLE.com、2000：」で始まるタグは、同じドメイン名を参照していても、「tag：example.com、2000：」で始まるタグと同じになることはありません。
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アドレス、電話番号などです。ただし、タグスキームを簡略化するために、権限名をドメイン名と電子メールアドレスに制限しています。将来の標準化の取り組みにより、この構文から切り離された構文に従って他の機関名を使用できるようになる可能性があります。そのような開発を可能にするために、タグを処理するソフトウェアは、上記で定義された構文の外にあるという理由でタグを拒否してはなりません。
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のミンターによって選択されたURI文字列（構文仕様の制限を参照）です。 「特定の」コンポーネントは、RFC 3986 [1]で定義されている「クエリ」サブコンポーネントを許可することに注意してください。特定の識別子は人にやさしいものであることが推奨されます。
Tag URIs may optionally end in a fragment identifier, in accordance with the general syntax of RFC 3986 [1].
タグURIは、RFC 3986 [1]の一般的な構文に従って、オプションでフラグメント識別子で終わる場合があります。
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]).
人間への扱いやすさのために、タグはパーセントエンコードされたパーツで作成しないでください。ただし、タグ構文では、「pchar」要素（RFC 3986 [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
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で指定されているように、各タグには「タグ付けエンティティ」が含まれ、オプションで特定の識別子が続きます。タグ付けエンティティは、「オーソリティ名」（完全修飾ドメイン名または完全修飾ドメイン名を含む電子メールアドレス）とそれに続く日付で指定されます。日付は、タグ付けエンティティをグローバルに一意にするために選択され、ドメイン名と電子メールアドレスが一度に最大で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 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.
日付は、グレゴリオ暦とUTCに従って、機関名がタグ付けエンティティに00:00 UTC（その日の開始）に割り当てられた特定の日を指定します。日付は、その時点で権限名が割り当てられた過去または現在の日付である場合があります。日付は、ISO 8601標準[4]で許可されている「YYYY」、「YYYY-MM」、「YYYY-MM-DD」のいずれかの形式を使用して指定されます（RFC 3339 [10]も参照）。タグの仕様では、他の形式は許可されていません。タグ付けエンティティは、権限名が実際に割り当てられていない日付を誤って使用しないように十分な精度で日付を確認する必要があります（多くのコンピューターとモバイルデバイスのクロックの同期が不十分です）。日付はUTCから計算する必要があります。これは、タグ付けエンティティのローカルタイムゾーンの00:00 UTCの日付とは異なる場合があります。その区別は、実際には一般的に安全に無視できますが、権限名の割り当て当日には無視できます。原則として、それ以外の場合は、前日に譲受人と新しい譲受人が同じ日付を使用して、同じタグを作成することが可能になります。
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.
簡潔にするため、月と日はデフォルトで "01"に設定されています。 「01」の日の値は省略できます。 「01」の月の値の後に「01」以外の日の値が続く場合を除いて、省略できます。たとえば、「2001-07」は日付2001-07-01であり、「2000」は日付2000-01-01です。すべての日付の定式化は、「2001年7月の全体」または「2000年の全体」などの1日以上の期間ではなく、1日の瞬間（00:00 UTC）を指定します。その時点での割り当ては、特定の日付を使用するために必要なすべてです。
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).
タグ付けエンティティは、同じ日付の別の定式化が個別としてカウントされるため、それらを含むタグは等しくないことを認識しておく必要があります。たとえば、「tag：example.com、2000：」で始まるタグは、「tag：example.com、2000-01-01：」で始まるタグと同じ日付を参照していても、決して等しくなることはありません（セクション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.
エンティティは、指定された日付の00:00 UTCに別のエンティティに割り当てられた機関名でタグを作成してはならず、将来の日付でタグを作成してはなりません。
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
たとえば、Hewlett-Packardはhp.comのドメイン登録を保持しており、その名前をルートとし、登録を保持した現在または過去の日付のタグを作成する場合があります。登録されていないドメイン名の下で、「tag：champignon.net、2001：」などのタグを作成してはなりません。次のような日付のタグを作成してはいけません。
"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.
「tag：hp.com、2999：」。 2001-05-01に「extremelyunlikelytobeassigned.org」の割り当てを取得した場合、2001-04-の間に名前が継続的に割り当てられていないことを証明する証拠がない限り、「extremelyunlikelytobeassigned.org、2001-04-01」の下のタグを作成してはなりません。 01および2001-05-01。
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）。このような意思決定の結果、名前空間の一部に対する制御を委任することができます。たとえば、example.comの担当者は、プレフィックスが「tag：example.com、2004：fred：」と「tag：example.com、2004：bill：」のすべてのタグの制御を、 2004-01-01の「fred」と「bill」の内部名。
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スキームを使用する必要があります。
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.
タグは単なる文字列であり、同じ文字エンコーディングを使用している場合、マシン表現で完全に区別できない場合にのみ等しいと見なされます。つまり、タグの文字の数値コードを順番に比較して、数値が等しいかどうかタグを比較できます。この同等性の基準により、タグを比較するためにタグを変換する必要のないタグ処理ソフトウェアの簡素化が可能になります。
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 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.
悪意のある者は、2つ以上のエンティティのそれぞれに同じドメイン名または電子メールアドレスが割り当てられているように見せかけることができます。タグ付けエンティティは、信頼できる割り当て機関を使用し、可能な限り割り当てを検証する必要があります。
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.
また、エンティティは、タグ付けエンティティ用に選択された日付のUTC 00:00 UTCの前から後まで継続的に割り当てられた機関名を使用することにより、悪意のあるクロックスキューの悪用の可能性を回避する必要があります。
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スキーム名を使用するアプリケーションやプロトコル：RDF、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)
Author/Change controller: Tim Kindberg and Sandro Hawke
著者/変更コントローラー：Tim KindbergとSandro Hawke
[1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[1] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、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」、RFC 2234、1997年11月。
[3] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[3] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[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] Leach, P. and R. Salz, "UUIDs and GUIDs", Work in Progress, 1997.
[5] リーチ、P.、R。サルツ、「UUIDとGUID」、Work in Progress、1997。
[6] "Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)", ISO (International Organization for Standardization) ISO/IEC 11578:1996, 1996.
[6] 「情報技術-オープンシステム相互接続-リモートプロシージャコール（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（RFC 1778も参照）、1988。
[8] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061, February 2001.
[8] Mealling、M。、「オブジェクト識別子のURN名前空間」、RFC 3061、2001年2月。
[9] Paskin, N., "Information Identifiers", Learned Publishing Vol. 10, No. 2, pp. 135-156, (see also www.doi.org), April 1997.
[9] パスキン、N。、「情報識別子」、学習出版Vol。 10、No。2、pp。135-156（www.doi.orgも参照）、1997年4月。
[10] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[10] Klyne、G.およびC. Newman、「Date and Time on the Internet：Timestamps」、RFC 3339、2002年7月。
Authors' Addresses
著者のアドレス
Tim Kindberg Hewlett-Packard Corporation Hewlett-Packard Laboratories Filton Road Stoke Gifford Bristol BS34 8QZ UK
Tim Kindberg Hewlett-Packard Corporation Hewlett-Packard Laboratories Filton Road Stoke Gifford Bristol BS34 8QZ UK
Phone: +44 117 312 9920
EMail: timothy@hpl.hp.com
Sandro Hawke World Wide Web Consortium 32 Vassar Street Building 32-G508 Cambridge, MA 02139 USA
Sandro Hawke World Wide Web Consortium 32 Vassar Street Building 32-G508 Cambridge、MA 02139 USA
Phone: +1 617 253-7288
EMail: sandro@w3.org
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（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.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または組織（ある場合）、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に後援します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
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は、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
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.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。