tagging entity

[24] tagging entity (構文 taggingEntity) は、 authority name と日付を , で連結したものです。 tag: URL のうち名前空間として機能する部分です。 >>11

[56] ある日付の時点である authority name を保有する者は一意に定まることから、 この組み合わせによって tag: URL を一意にすることが意図されています。 >>11

[57] tagging entity は、 日付の UTC 0時0分時点で当該 authority name に割り当てられていた者を表します。 過去であっても構いません。 >>11

[65] tag: URL を割り当てる者は、 日付の 0時0分 UTC 時点で他者に割り当てられた authority name を使ってはなりません。 >>11

[67] tag: URL を割り当てる者は、 authority name を一旦手放して再取得した場合に、 その間も割り当てられていたものと扱うことができます。 ただし、その間に未割当だったとする根拠を有していなければなりません。 >>11

[66] tag: URL を割り当てる者は、 将来の日付を使ってはなりません。 >>11

[72] tag: URL を扱うソフトウェアはそうした誤りを検出する補助機能を提供して構いません。 >>11

[74] 悪意ある者が1つの authority name を複数の者に割り当てられているように見せるかもしれませんから、 tagging entity となる者は評判の良い事業者を選んで注意して使うべきとされます。 >>11

[26] authority name (構文 authorityName) は、 ドメイン名またはメールアドレスです。 >>11

[40] 将来他の構文が認められるかもしれません。 処理するソフトウェアは、 構文に合致しないからといって拒絶してはなりません。 >>11

[33] メールアドレス (構文 emailAddress) は、 1文字以上のASCII英数字、 -, ., _ の列の後に、 @ と DNSname を連ねたものです。 >>11

[35] インターネットメールの電子メールアドレスであることは文脈上明らかですが、 仕様書は RFC 2821 や RFC 2822 を参照しておらず、 この構文がどのような意味を持つのか明らかにしていません。

[36] インターネットメールの電子メールアドレスと比べると、 local-part 相当の部分はかなり厳しい制限が加わっています。 インターネットメールで使える記号類のほとんどが認められません。 非ASCII文字も使えません。 ドメイン名部分はインターネットメールで使える IPv6アドレスが認められません。

[42] local-part 部分の大文字・小文字については明文規定がなく、 区別されるものと思われます。インターネットメールでも区別されます。

[28] 構文 DNSname は、 RFC 1035 ドメイン名を . 区切りで0個以上のラベル (構文 DNScomp) を連結したものです。 >>11

[37] 単体でもメールアドレスでも、 ドメイン名は完全修飾でなければなりません。 >>11

[84] と規定されていますが、実際には FQDN になっていない謎のホスト名なども使われています。

[38] ドメイン名は小文字とするべきです。 >>11

[39] tag: URL の比較では、ドメイン名の大文字と小文字は区別されます。 >>11

[43] 日付 (構文 date) は、グレゴリオ暦、 UTC の年月日を - で連結したものです。 >>11

[45] 年 (構文 year) は、4桁のASCII数字です。 月 (構文 month) は、2桁のASCII数字です。 日 (構文 day) は、2桁のASCII数字です。 >>11

[61] この日付は ISO 8601の日時形式とされます >>11。 年月日の値域の規定が RFC 4151 にはありませんが、 ISO 8601 の規定が適用されると思われます。 RFC 4151 は RFC 3339 も見よ、 と書いています >>11 が、 RFC 3339の日時形式の規定が適用されるとは書いておらず、 参照した理由は不明です。 >>11

[62] 月日を省略すると、1月1日を表します。 日を省略すると、1日を表します。 >>11

[63] tag: URL を割り当てる者は、 0時0分 UTC 時点で自身に authority name が割り当てられているような精度の日付を用いなければなりません。 >>11

[76] clock skew によるずれを鑑み、 できれば数日の猶予がある authority name を使うべきです。 >>11

[64] tag: URL の比較では、 省略形と非省略形は区別されます。 >>11

[77] Unix time のようなより単純な日時形式を使わなかったのは、 他の部分の規定にあるように「人間可読性」を重視したためでしょうか。

[78] ただしその「人間」はグレゴリオ暦と西暦に慣れ親しんだ欧米人に限られています。

[79] といっても欧米人には馴染みが薄い大エンディアン (年月日順) が採用されていますし、月名ではなく月番号が採用されています。 実はこの日付形式が最も受け入れやすいのは、 年月日順、グレゴリオ暦、西暦年のどれにも馴染んでいる日本人の情報技術者かもしれません。

[80] でも UTC の日付という罠があります。英国在住の日本人の情報技術者が冬季に使うには適しているかもしれませんが、 それ以外の地域の人はうっかり地方時で書いてしまいそうです。

[81] これ、本当に「人間に優しい」ものだといえるのでしょうか?

[82] 機械は解釈しない、 人間が読み書きする、 人間に優しくするべきと言いながら構文の制限は厳しい、 という tag: URL の矛盾した性質が凝縮されたのがこの日付の構文ではないでしょうか。

specific

[46] 構文 specific は、 RFC 3986 pchar, /, ? の0文字以上の列です。 >>11

[48] specific は名前空間固有の部分であり、 URL を決める人が任意の文字列で構成できます。 人に優しく (human-friendly) するべきです。 >>11

[50] つまり簡潔な文字列でも構いませんし、 / を使って path 風の階層構造を導入しても構いませんし、 ? を使って query 風の構造を導入しても構いません。 すべては authorityName で表された名前空間の管理者の意志次第というわけです。

[51] tag: URL を規定した RFC 4151 が参照している、当時の URL 仕様である RFC 3986 は非ASCII文字の直接利用を認めていませんでした。 従って tag: の specific でも非ASCII文字は構文上認められません。

[52] ただし pchar にはパーセント符号化が含まれていますので、 当時の IRI の仕様書 RFC 3987 に従えば、 IRI としては非ASCII文字を使うことができ、 URI として解釈するときには UTF-8 でパーセント符号化することになります。 しかしそのような変換を介した関係性を、 tag: URL の比較 (>>71) の場面でどう扱うべきかは疑問が残ります。

[54] 一方で、 tag: URL は人間の扱いやすさ (tractability to humans) のためパーセント符号化を使うべきではないとされていました。 >>11 (この規定は specific の他に素片識別子も対象と思われます。)

[69] tagging entity は、その名前空間内の specific の固有性を保証するために、 記録を残す手続きを用いるべきです。 複数名で構成される tagging entity は、 グループの意思決定をも行って固有性を確保するべきです。 意思決定に基づき specific 内の階層構造の一部を移譲するような方法もあります。 >>11

素片識別子

[20] 素片識別子は、それが使えるということ以外特別の規定がなく、 当時の URL の仕様である RFC 3986 の一般の規則が参照されているだけでした。 >>11 素片識別子 (ただしパーセント符号化は規制されていました (>>54)。)

[21] 一般に素片識別子は、 URL で指定された資源を、 関係するプロトコルを通じて取得して得られる表現に対して評価されるものです。 例えばそれが HTML文書だったなら、 id 属性値が一致する要素を探す、といった挙動を結び付いています。

[22] ところが tag: は特定のプロトコルと結び付いておらず (>>9)、 素片識別子はほとんど解釈し得ないものとなります。