[6] [DFN[[CODE(URI)@en[[[tag:]]]]]] は、 任意の[[文字列]]を[[識別子]]として使うための [[URL scheme]] です。 [7] [[00年代]]中頃 ([[平成時代]]中期)、 [[Semantic Web]] や [[Atom]] などの世界で一時[[流行]]しました。 その後それらの衰退と共に使われなくなりました。 * 代替 [8] [CODE(URI)@en[[[tag:]]]] [[URL]] は[[廃止]]されたわけではありませんから、 現在でも必要があれば使うことができます。しかし互換性などの制約が無い限り、 ほとんど有用性は無いと思われます。 * 仕様書 [REFS[ - [11] [CITE@en[[[RFC 4151]] - The 'tag' URI Scheme]] ([TIME[2017-05-07 16:48:27 +09:00]]) - [12] [CITE[RFC Errata Report » [[RFC Editor]]]], [TIME[2021-07-14T03:39:30.000Z]] ]REFS] * 構文 [18] [CODE[tag:]] [[URL]] は、 [[URL scheme]] の後に [[tagging entity]] と [VAR[specific]] を [CODE[:]] で区切って記述したものです。 [[素片識別子]]を使うこともできます。 [SRC[>>11]] [FIG(railroad)[ [19] [CODE[tag:]] [[URL]] = [CODE[tag:]] = [[tagging entity]] = [CODE[:]] = [VAR[specific]] = ? == [CODE[#]] == [[素片][素片識別子]] ]FIG] ** tagging entity [24] [DFN[tagging entity]] (構文 [DFN[[VAR[taggingEntity]]]]) は、 [[authority name]] と[[日付]]を [CODE[,]] で連結したものです。 [CODE[tag:]] [[URL]] のうち[[名前空間]]として機能する部分です。 [SRC[>>11]] [56] ある[[日付]]の時点である [[authority name]] を保有する者は一意に定まることから、 この組み合わせによって [CODE[tag:]] [[URL]] を一意にすることが意図されています。 [SRC[>>11]] [FIG(railroad)[ [25] [VAR[taggingEntity]] = [[authority name]] = [CODE[,]] = [[日付]] ]FIG] [57] [[tagging entity]] は、 [[日付]]の [[UTC]] 0時0分時点で当該 [[authority name]] に割り当てられていた者を表します。 [[過去]]であっても構いません。 [SRC[>>11]] ;; [58] つまりこの[[日付]]は [CODE[tag:]] [[URL]] 全体が作られたり使われたりする[[日]]とは何の関係もありません。 既に失効した[[ドメイン名]]や解約済みの[[メールアドレス]]でも、 過去の利用権を有していた[[日付]]がわかれば利用できます。 ;; [59] [[ドメイン名]]が開発されるよりも前には遡り得ないことになります。 [65] [CODE[tag:]] URL を割り当てる者は、 [[日付]]の 0時0分 [[UTC]] 時点で他者に割り当てられた [[authority name]] を使っては[MUST[なりません]]。 [SRC[>>11]] [67] [CODE[tag:]] URL を割り当てる者は、 [[authority name]] を一旦手放して再取得した場合に、 その間も割り当てられていたものと扱うことが[MAY[できます]]。 ただし、その間に未割当だったとする根拠を有していなければ[MUST[なりません]]。 [SRC[>>11]] [66] [CODE[tag:]] URL を割り当てる者は、 [[将来の日付]]を使っては[MUST[なりません]]。 [SRC[>>11]] ;; [60] あくまで紳士協定的なものです。利用権限を確認したり、 利用権限のない者の利用を拒絶したりする仕組みはありません。 未到来の[[将来の日付]]の利用も仕組みとしては避けられません。 ;; [68] 誰にも割り当てられていない [[authority name]] の利用を認める意図があるとは思えませんが、明示的には禁止されていないようです。 [72] [CODE[tag:]] [[URL]] を扱うソフトウェアはそうした誤りを検出する補助機能を提供して[MAY[構いません]]。 [SRC[>>11]] ;; [73] 実際問題、有用な補助が提供できるか疑問ですし、そのようなソフトウェアが実在したかも不明です。 [74] 悪意ある者が1つの [[authority name]] を複数の者に割り当てられているように見せるかもしれませんから、 [[tagging entity]] となる者は評判の良い事業者を選んで注意して使う[SHOULD[べき]]とされます。 [SRC[>>11]] ;; [75] 事故により[[ドメイン名]]や[[メールアドレス]]が複数の者に一時的に割り当てられることや、 [[ドメイン名]]や[[メールアドレス]]を意図的に複数人で共有するサービスが提供されることはあるでしょうが、 それ以外に実際上そのようなことが起こり得るのでしょうか。 [CODE[tag:]] 以外の一般的な[[ドメイン名]]や[[メールアドレス]]の用途に支障が出るような悪意あるサービスは、 評判の良し悪し以前に実用に耐えない詐欺か何かではないでしょうか。 そんな状況で [CODE[tag:]] [[URL]] を割り当てようとする人が出てくる危険性より、 悪意ある者が自身が利用権を持たない [[authority name]] を悪用する危険性の方が大きそうかつ簡単そうですが、 [[RFC 4151]] はそちらには何も言及していません。 -*-*- [26] [DFN[authority name]] (構文 [DFN[[VAR[authorityName]]]]) は、 [[ドメイン名]]または[[メールアドレス]]です。 [SRC[>>11]] [FIG(railroad)[ [27] [VAR[authorityName]] = | == [VAR[[[DNSname]]]] == [VAR[[[emailAddress]]]] ]FIG] [40] 将来他の構文が認められるかもしれません。 処理するソフトウェアは、 構文に合致しないからといって拒絶しては[MUST[なりません]]。 [SRC[>>11]] ;; [41] 人々から忘れ去られつつあるので、そのような将来は到来しなそうですが。 -*-*- [33] [[メールアドレス]] (構文 [VAR[[[emailAddress]]]]) は、 1文字以上の[[ASCII英数字]]、 [CODE[-]], [CODE[.][FULL STOP]], [CODE[_]] の列の後に、 [CODE[@]] と [VAR[DNSname]] を連ねたものです。 [SRC[>>11]] [35] [[インターネットメール]]の[[電子メールアドレス]]であることは文脈上明らかですが、 仕様書は [[RFC 2821]] や [[RFC 2822]] を参照しておらず、 この構文がどのような意味を持つのか明らかにしていません。 [36] [[インターネットメール]]の[[電子メールアドレス]]と比べると、 [CODE[local-part]] 相当の部分はかなり厳しい制限が加わっています。 [[インターネットメール]]で使える記号類のほとんどが認められません。 [[非ASCII文字]]も使えません。 [[ドメイン名]]部分は[[インターネットメール]]で使える [[IPv6アドレス]]が認められません。 [42] [CODE[local-part]] 部分の[[大文字]]・[[小文字]]については明文規定がなく、 区別されるものと思われます。[[インターネットメール]]でも区別されます。 [FIG(railroad)[ [34] [VAR[emailAddress]] = + == | === [[ASCII英数字]] === [CODE[-]] === [CODE[.][FULL STOP]] === [CODE[_]] = [CODE[@]] = [VAR[DNSname]] ]FIG] [28] 構文 [VAR[[[DNSname]]]] は、 [[RFC 1035]] [[ドメイン名]]を [CODE[.][FULL STOP]] 区切りで0個以上の[[ラベル]] (構文 [VAR[[[DNScomp]]]]) を連結したものです。 [SRC[>>11]] ;; [29] [[RFC 1035]] を参照しつつも、構文は独自に規定されていました。 [[RFC 1123]] は参照されていませんが、 [[RFC 1123]] での[[ラベル]]の制限緩和が適用された構文となっていました。 [SEE[ [[DNSname]] ]] ;; [30] [[ドメイン名]]の[[ラベル]]の文字数制限が構文にも仕様書本文にも現れておらず、 適用されるのか不透明です。 ;; [31] [[末尾の点]]は認められていません。 ;; [32] [[IDN]] は言及されていません。構文上 [[Unicodeラベル]]は使えず (従って[[パーセント符号化]]しても書くことは出来ず)、 [[ASCIIラベル]]に変換してなら記述できます。 [37] 単体でも[[メールアドレス]]でも、 [[ドメイン名]]は[[完全修飾][FQDN]]でなければ[MUST[なりません]]。 [SRC[>>11]] [84] と規定されていますが、実際には [[FQDN]] になっていない謎の[[ホスト名]]なども使われています。 ;; [83] [[alternative root]]の利用には触れられていません。 ([[IETF]] 的には触れられないのでしょうか。) [38] [[ドメイン名]]は[[小文字]]とする[SHOULD[べきです]]。 [SRC[>>11]] [39] [CODE[tag:]] [[URL]] の比較では、[[ドメイン名]]の[[大文字と小文字は区別''されます''][大文字・小文字区別]]。 [SRC[>>11]] -*-*- [43] [DFN[日付]] (構文 [DFN[[VAR[date]]]]) は、[[グレゴリオ暦]]、 [[UTC]] の[[年月日]]を [CODE[-]] で連結したものです。 [SRC[>>11]] [45] [DFN[年]] (構文 [DFN[[VAR[year]]]]) は、4桁の[[ASCII数字]]です。 [DFN[月]] (構文 [DFN[[VAR[month]]]]) は、2桁の[[ASCII数字]]です。 [DFN[日]] (構文 [DFN[[VAR[day]]]]) は、2桁の[[ASCII数字]]です。 [SRC[>>11]] [61] この[[日付]]は [[ISO 8601の日時形式]]とされます [SRC[>>11]]。 [[年月日]]の[[値域]]の規定が [[RFC 4151]] にはありませんが、 [[ISO 8601]] の[[規定]]が適用されると思われます。 [[RFC 4151]] は [[RFC 3339]] も見よ、 と書いています [SRC[>>11]] が、 [[RFC 3339の日時形式]]の規定が適用されるとは書いておらず、 参照した理由は不明です。 [SRC[>>11]] [62] [[月日]]を省略すると、1月1日を表します。 [[日]]を省略すると、1日を表します。 [SRC[>>11]] [63] [CODE[tag:]] [[URL]] を割り当てる者は、 0時0分 [[UTC]] 時点で自身に [[authority name]] が割り当てられているような精度の[[日付]]を用いなければ[MUST[なりません]]。 [SRC[>>11]] [76] [[clock skew]] によるずれを鑑み、 できれば数日の猶予がある [[authority name]] を使う[SHOULD[べきです]]。 [SRC[>>11]] [64] [CODE[tag:]] [[URL]] の比較では、 省略形と非省略形は区別''されます''。 [SRC[>>11]] [FIG(railroad)[ [44] [VAR[date]] = [[年]] = ? == [CODE[-]] == [[月]] == ? === [CODE[-]] === [[日]] ]FIG] [77] [[Unix time]] のようなより単純な[[日時形式]]を使わなかったのは、 他の部分の規定にあるように「人間可読性」を重視したためでしょうか。 [78] ただしその「人間」は[[グレゴリオ暦]]と[[西暦]]に慣れ親しんだ[[欧米人]]に限られています。 [79] といっても[[欧米人]]には馴染みが薄い[[大エンディアン]] ([[年月日]]順) が採用されていますし、[[月名]]ではなく[[月番号]]が採用されています。 実はこの[[日付形式]]が最も受け入れやすいのは、 [[年月日]]順、[[グレゴリオ暦]]、[[西暦年]]のどれにも馴染んでいる[[日本人]]の[[情報技術者]]かもしれません。 [80] でも [[UTC]] の[[日付]]という罠があります。[[英国]]在住の[[日本人]]の[[情報技術者]]が冬季に使うには適しているかもしれませんが、 それ以外の地域の人はうっかり[[地方時]]で書いてしまいそうです。 [81] これ、本当に「人間に優しい」ものだといえるのでしょうか? [82] 機械は解釈しない、 人間が読み書きする、 人間に優しくするべきと言いながら構文の制限は厳しい、 という [CODE[tag:]] URL の矛盾した性質が凝縮されたのがこの日付の構文ではないでしょうか。 ** [VAR[specific]] [46] 構文 [DFN[[VAR[specific]]]] は、 [[RFC 3986]] [VAR[[[pchar]]]], [CODE[/]], [CODE[?]] の0文字以上の列です。 [SRC[>>11]] ;; [49] [CODE[pchar]] には[[パーセント符号化]]された[[オクテット]]も含まれます。 [48] [VAR[specific]] は[[名前空間]]固有の部分であり、 [[URL]] を決める人が任意の文字列で構成できます。 [RUBYB[[[人に優しく]]][human-friendly]]する[SHOULD[べきです]]。 [SRC[>>11]] [50] つまり簡潔な文字列でも構いませんし、 [CODE[/]] を使って [[path][URL path]] 風の階層構造を導入しても構いませんし、 [CODE[?]] を使って [[query][URL query]] 風の構造を導入しても構いません。 すべては [VAR[authorityName]] で表された名前空間の管理者の意志次第というわけです。 [51] [CODE[tag:]] [[URL]] を規定した [[RFC 4151]] が参照している、当時の [[URL]] 仕様である [[RFC 3986]] は[[非ASCII文字]]の直接利用を認めていませんでした。 従って [CODE[tag:]] の [VAR[specific]] でも[[非ASCII文字]]は構文上認められません。 [52] ただし [CODE[pchar]] には[[パーセント符号化]]が含まれていますので、 当時の [[IRI]] の仕様書 [[RFC 3987]] に従えば、 [[IRI]] としては[[非ASCII文字]]を使うことができ、 [[URI]] として解釈するときには [[UTF-8]] で[[パーセント符号化]]することになります。 しかしそのような変換を介した関係性を、 [CODE[tag:]] URL の比較 (>>71) の場面でどう扱うべきかは疑問が残ります。 ;; [53] 当時の [[URI]]/[[IRI]] 仕様はかくも難解でした。 [SEE[ [[IRI]] ]] [54] 一方で、 [CODE[tag:]] [[URL]] は[RUBYB[人間の扱いやすさ][tractability to humans]]のため[[パーセント符号化]]を使う[SHOULD[べきではない]]とされていました。 [SRC[>>11]] (この規定は [VAR[specific]] の他に[[素片識別子]]も対象と思われます。) ;; [55] [[非ASCII文字]]をほとんど使わない[[英語圏]]にあらずんば人にあらずという、 あまりに独善的な[[規定]]です。 この時代既に [[IETF]] では[[国際化]]の専門家と称する人々が幅を利かせて仕様制定手続きの過程でレビューしていたはずなのに、 どうしてこんな規定が平気で残存しているのですかね? [FIG(railroad)[ [47] [VAR[specific]] = * == | === [VAR[[[pchar]]]] === [CODE[/]] === [CODE[?]] ]FIG] [69] [[tagging entity]] は、その[[名前空間]]内の [VAR[specific]] の固有性を保証するために、 記録を残す手続きを用いる[SHOULD[べきです]]。 複数名で構成される [[tagging entity]] は、 グループの意思決定をも行って固有性を確保する[SHOULD[べきです]]。 意思決定に基づき [VAR[specific]] 内の階層構造の一部を移譲するような方法もあります。 [SRC[>>11]] ** 素片識別子 [20] [[素片識別子]]は、それが使えるということ以外特別の[[規定]]がなく、 当時の [[URL]] の仕様である [[RFC 3986]] の一般の規則が参照されているだけでした。 [SRC[>>11]] [SEE[ [[素片識別子]] ]] (ただし[[パーセント符号化]]は規制されていました (>>54)。) [21] 一般に[[素片識別子]]は、 [[URL]] で指定された[[資源]]を、 関係する[[プロトコル]]を通じて[[取得][retrieve]]して得られる[[表現]]に対して評価されるものです。 例えばそれが [[HTML文書]]だったなら、 [CODE[id][id=""]] [[属性値]]が一致する[[要素]]を探す、といった挙動を結び付いています。 [22] ところが [CODE[tag:]] は特定の[[プロトコル]]と結び付いておらず (>>9)、 [[素片識別子]]はほとんど解釈し得ないものとなります。 ;; [23] [CODE[tag:]] [[URL]] の開発に関与した人々がそのことをどう認識していたのかは不明です。 当時 [[Semantic Web]] 界隈の人々は [[RDF]] の世界において[[取得][retrieve]]操作が発生しない限りは任意の値が許されるといった超然的な解釈を導入していました。 [SEE[ [[素片識別子]] ]] [CODE[tag:]] [[URL]] も [[RDF URI参照]]と似た性質と近接した歴史背景を持ちますから、 同じような意識だったのかもしれません。 * 比較 [71] [CODE[tag:]] [[URLの比較]]は、単純な[[文字列の比較]]によります。 [SRC[>>11]] * プロトコル [9] [CODE(URI)@en[[[tag:]]]] [[URL]] は特定の[[プロトコル]]と関連付けられたものではありませんでした。 [[解決]] ([[resolution]]) などの操作も[[規定]]されていません [SRC[>>11]]。 [70] それは専ら[[識別子]]としての利用を想定したためで、 [[解決]]が必要なら他の [[URL scheme]] が適当とされました。 [SRC[>>11]] * 日時 [14] 先行する [CODE[tann:]] [[URL scheme]] が同じような構文と用法を提案していました。 [CODE[tag:]] の方の初期案 [SRC[>>5]] と比較すると現行の [CODE[tag:]] はむしろ [CODE[tann:]] の影響が強いことがわかります。 * 文脈 [13] [[Atom]] コミュニティーで好意的に受け入れられていました。 [CODE[atom:id]] などで積極的に使われました。 [17] [[YAML]] は [CODE[tag:]] を[[推奨]]していました [SRC[>>16]]。 [REFS[ - [16] [CITE[YAML Ain’t Markup Language ([[YAML]]™) Version 1.2]], [TIME[2021-06-13T20:39:49.000Z]], [TIME[2021-07-14T03:53:33.857Z]] ]REFS] * 歴史 - [1] [CITE[Tag URI]] -- [15] [CITE[Tag URI draft history]], [TIME[2009-01-06T16:25:13.000Z]], [TIME[2021-07-14T03:51:42.178Z]] - [2] [CITE[Webweavers - weavin' - [[Tag URI]] vs [[FOAF]] IFP]] -- 消滅確認 [TIME[2021-07-14T03:45:11.900Z]] -- [CITE[Webweavers - weavin' - [[Tag URI]] vs FOAF IFP]], [TIME[2021-07-14T03:44:56.000Z]], [TIME[2005-03-26T18:37:52.317Z]] [3] [CITE[【RDF】セマンティックウェブ【メタ情報】]] [FIG(quote)[ [FIGCAPTION[ [4] [CITE[Tag URI]] ([TIME[2011-03-23 23:32:27 +09:00]] 版) ]FIGCAPTION] > The tag algorithm lets people mint — create — identifiers that no one else using the same algorithm could ever mint. It is simple enough to do in your head, and the resulting identifiers can be easy to read, write, and remember. ]FIG] [5] [CITE[The tag: URI scheme]] ([TIME[2004-02-13 05:01:34 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [10] ([TIME[2016-05-06 12:26:53 +09:00]] 版) ]FIGCAPTION] > > tag:soundcloud,2010:tracks/262680218 ]FIG]