【注意】 このドキュメントは、W3CのLinked Data Notifications W3C Recommendation 2 May 2017の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。
First Update: 2020年4月6日
公開以後に報告されたエラーや問題がないか正誤表を確認してください。
この仕様の英語版が唯一の規範のバージョンです。非規範の翻訳版も入手可能かもしれません。
Copyright © 2017 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
リンクト・データ通知は、アプリケーション(送信者)がサーバー(受信者)にメッセージをプッシュできる方法、および他のアプリケーション(利用者)がそのメッセージを取得できる方法を記述するプロトコルです。あらゆる資源は、メッセージ受信のエンドポイント(受信ボックス(Inbox))を公言(advertise)できます。メッセージはRDFで表され、あらゆるデータを含めることができます。
ステータスの更新(2017年5月): 2017年5月22日に概要図のリンクをインプレース修正しました。誤った内部アンカーを指していました。
ステータスの更新(2017年9月): 2017年9月5日22日(訳注: 誤記と思われる。)に概念のURIをインプレース修正しました。誤った内部URIを指していました。
この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、https://www.w3.org/TR/のW3C技術報告インデックスにあります。
このドキュメントは、ソーシャル・ウェブ・ワーキンググループによって勧告として公開されました。このドキュメントに関してコメントを行いたい場合には、[email protected](購読、アーカイブ)にお送りください。どのようなコメントでも歓迎します。
ワーキンググループの実装報告書を参照してください。
このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用したりすることができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。
このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。
このドキュメントは、2017年3月1日のW3Cプロセス・ドキュメントによって管理されています。
ウェブ上のデータは、特定のシステム内に閉じ込めたり、それを作成したアプリケーションでしか読めないようにしたりすべきではありません。ユーザは、アプリケーションを自由に切り替えて、それらの間でデータを共有できるべきです。アプリケーションは、活動、相互作用、新しい情報に関する通知を生成し、それをユーザに提示したり、さらに処理したりすることができます。
リンクト・データ通知(LDN;Linked Data Notifications)は、通知の生成方法に関係なく、アプリケーションにまたがる通知の共有と再利用をサポートします。これにより、より多くのモジュール型のシステムが可能になり、データを表示・利用するアプリケーションからデータ・ストレージを切り離すことができます。このプロトコルは、通知の送信者、受信者、利用者(これらは、別々に実装され、様々な技術スタック上で動作する)が、シームレスに連携し、ウェブ上の相互作用の分散化に貢献できるようにすることを目的としています。
この仕様では、通知を一時的または非永続的なエンティティーとして扱うのではなく、通知の概念を、独自のURIを持つ個別のエンティティーとして使用できるようにします。それによって、通知を取得して再利用することができます。我々は、ソーシャルなものであれ何であれ、様々なアプリケーション領域をサポートしているため、通知の内容は定義するアプリケーションに委ねられています。通知の認証と検証は推奨されますが、通知の種類やアプリケーション領域によってニーズが異なるため、それを行うメカニズムは受信者と利用者の裁量に委ねられています。
送信者は、人間または自動プロセスにより始動され、サーバーに通知を配信します。通知は、受信者の注意を喚起するためのデータで、例えば、友人からの個人的なメッセージ、ピンバック(pingback)リンク、ブログ投稿に関するコメント、コラボレーションへの招待、カレンダーのリマインダー、科学的観察などです。
送信者は、通知を送信するターゲット資源を選択します。次に、送信者はターゲットの受信ボックスの場所を発見し、そこに通知を送信します。あらゆる資源は受信ボックスを公言することができます。受信者は、利用者が使用できるように(適切なアクセス制御に従って)通知データを公開します。
利用者は、送信者と同じ方法で受信ボックスの場所を発見し、通知に対してさらに処理を実行したり、他のデータと組み合わせたり、適切な人間が読める方法でシンプルに提示したりできます。
送信者と利用者は、資源のHTTP Link
ヘッダーや本文のrelを通じて、資源の受信ボックスのURLを発見します。
送信者:
POST
リクエストを行うことにより、通知を受信ボックスのURLに送信します。受信者:
GET
リクエストに応答します。GET
リクエストに応答します。POST
リクエストを受け入れ、通知を作成します。利用者:
GET
リクエストで受信ボックスのURLのコンテンツを取得し、アプリケーションのニーズに応じて用います。LDNは、通知の送信と利用のためのリンクト・データ・プラットフォーム[LDP]の特殊な使い方です。これは、LDPの完全な実装に依存するものではなく、実装が容易なサブセットです。この仕様を理解するためには、LDPの知識を持っている必要はありませんが、知識がある人は、一部の概念を知っていることに気づくでしょう。このドキュメントでは、分散化された相互運用可能な方法で通知を容易に交換できるようにするために必要な特定の機能について説明します。LDNの受信ボックスはBasicContainer
に相当します。
このドキュメントの「しなければならない(MUST)」、「してはならない(MUST NOT)」、「必須である/要求される(REQUIRED)」、「することになる(SHALL)」、「することはない(SHALL NOT)」、「すべきである/する必要がある(SHOULD)」、「すべきでない/する必要がない(SHOULD NOT)」、「推奨される(RECOMMENDED)」、「することができる/してもよい(MAY)」、「選択できる/任意である(OPTIONAL)」というキーワードは、[RFC2119]で記述されているように解釈されるべきです。非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。
LDNの実装は、送信者、受信者、または利用者でありえます。これらのそれぞれの役割の適合基準については、この仕様の各項で記述しています。
この項では、通知の配信や読み取りが行われるURL(受信ボックス)の発見と配信の仕組みについて説明します。 通知内容はペイロードに記述されます。
通知の送信先または利用元のエンドポイントである受信ボックスは、ブログの投稿、ユーザ・プロファイル、データセット、動画などの資源から発見できます。発見の開始点は、通知の対象となる資源、つまりターゲットです。あらゆる資源(RDFであってもなくても)が独自の受信ボックスを持ちえるため、発見を開始するための最も適切なターゲット資源の選択は、送信者や利用者の裁量に委ねられています。
送信者と利用者は、受信ボックスのURLを発見するために次を行います。
HEAD
またはGET
リクエストを行い、rel
の値がhttp://www.w3.org/ns/ldp#inbox
であるLink
ヘッダーを用います。GET
リクエストを行い、エンコードされたRDFグラフにhttp://www.w3.org/ns/ldp#inbox
という型の関係を含んでいるRDF表現[RDF 1.1]を取得します。この関係の主語はターゲット、目的語は受信ボックスです。これらはどちらの順序でも実行できますが、最初の方法で受信ボックスが発見できなかった場合は、2番目の方法を試さなければなりません(MUST)。送信者と利用者は、特にフラグメント識別子を持つURIをターゲットとする場合には、Link
ヘッダーの発見を省略すべきです(SHOULD)。
ターゲットにフラグメント識別子が含まれている場合、そのフラグメントはサーバーに対するリクエストの一部ではありません。送信者と利用者は、Link
ヘッダーにある受信ボックスは、フラグメントのない、解決されたURLのものであることを認識しているべきです。[セマンティック・ウェブのためのクールなURI - ハッシュURI]を参照してください。
資源は受信ボックスを1つのみ公言しなければなりません(MUST)。例えば、すべてのブログ投稿への返信用とすべての自分の写真の共有用に同じ受信ボックスを用いるなど、1つの受信ボックスは、複数の資源で使用できます(MAY)。
発見の例1: リンク・ヘッダー
HEAD /article HTTP/1.1
Host: example.org
Accept: application/ld+json
HTTP/1.1 200 OK
Link: <http://example.org/inbox/>; rel="http://www.w3.org/ns/ldp#inbox"
HEAD
リクエストで受信ボックスを発見し、Link
ヘッダーを受信する場合のリクエストと応答。発見の例2: JSON-LD
GET /profile HTTP/1.1
Host: example.org
Accept: application/ld+json
HTTP/1.1 200 OK
Content-Type: application/ld+json
{
"@context": "http://www.w3.org/ns/ldp",
"@id": "http://example.org/profile",
"inbox": "http://example.org/inbox/"
}
GET
リクエストで受信ボックスを発見。JSON-LDコンパクト形式で応答。発見の例3: HTML(表示あり)
GET /event HTTP/1.1
Host: example.org
Accept: text/html, application/ld+json
HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
<p about="http://example.org/event" typeof="http://schema.org/Event" lang="en">
<a rel="http://www.w3.org/ns/ldp#inbox" href="/http/www.asahi-net.or.jp/inbox/">RSVP</a> to event
</p>
GET
リクエストで受信ボックスを発見。受信ボックスのリンクは人間に表示され、機械が受信ボックスのURLを発見できるようにRDFaでマークアップされている。発見の例4: HTML(表示なし)
GET /article HTTP/1.1
Host: example.org
Accept: text/html, application/ld+json
HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
<link href="/http/www.asahi-net.or.jp/inbox/" rel="http://www.w3.org/ns/ldp#inbox" />
GET
リクエストで受信ボックスを発見。機械による発見用にRDFaでマークアップし、link
要素で表している非表示の受信ボックス。発見の例5: HTML(表示なし)
GET /article HTTP/1.1
Host: example.org
Accept: text/html, application/ld+json
HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
<section id="results" about="#results"
property="http://www.w3.org/ns/ldp#inbox" resource="/inbox/">
</section>
GET
リクエストで受信ボックスを発見。フラグメントURIで識別される資源がターゲットになりえるように、RDFaのproperty
属性で表している非表示の受信ボックス。発見の例6: Turtle
GET / HTTP/1.1
Host: csarven.ca
Accept: text/turtle, application/ld+json
HTTP/1.1 200 OK
Content-Type: text/turtle;charset=utf-8
<http://csarven.ca/#i>
<http://www.w3.org/ns/ldp#inbox> <http://csarven.ca/inbox/> .
GET
リクエストで受信ボックスを発見。特にこのプロトコルを認識していない可能性があるサーバーを考慮した、発見の実行方法に関する推奨事項に関しては、ソーシャル・ウェブ・プロトコルを参照してください。
発見後、通知を送信したい送信者は、受信ボックスのURLにPOST
リクエストでその通知を配信しなければなりません(MUST)。送信者は、リクエストが成功したときの応答として、201 Created
(生成)(Location
Linkヘッダー付き)または202 Accepted
(受理)を期待できます。
送信者はOPTIONS
リクエストを用いてサーバーが受け入れるRDFコンテンツ・タイプを判断し、返されたAccept-Post
ヘッダー[Accept-Post]の値に従ってリクエスト本文の通知をシリアル化できます(MAY)。あるいは、POST
リクエストの本文に、Content-Type: application/ld+json
というヘッダーを持つJSON-LDの通知ペイロードが含まれていなければなりません(MUST)。Content-Type
ヘッダーには、profile
URI[RFC6906]を含めることができます(MAY)。
送信者は、認証や承認の目的で、Authorization: Bearer XXX
などの追加のヘッダーやコンテンツを含めることができます(MAY)。
認証を必要としないローカルホスト上でリッスンするサービスを送信者が持っている場合、悪意のあるスクリプトが受信ボックスのエンドポイントで実行され、送信者が自身に任意のPOST
リクエストを送信する可能性があります。送信者は、ローカルホストやループバックIPアドレスである受信ボックスにPOST
リクエストを行うべきではありません(SHOULD NOT)。
送信の例(リクエスト)
POST /inbox/ HTTP/1.1
Host: example.org
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en
{
"@context": "https://www.w3.org/ns/activitystreams",
"@id": "",
"@type": "Announce",
"actor": "https://rhiaro.co.uk/#me",
"object": "http://example.net/note",
"target": "http://example.org/article",
"updated": "2016-06-28T19:56:20.114Z"
}
送信の例(応答)
HTTP/1.1 201 Created
Location: http://example.org/inbox/5c6ca040
POST
リクエストへの応答の例。受信者は、受信ボックスのURLにおけるGET
とPOST
のリクエストをサポートしなければなりません(MUST)。LDPの用語では、受信ボックスはコンテナです。
POST
リクエストの受信時に、通知資源が正常に処理された場合、受信者は、201 Created
というステータス・コードと、通知データを取得できるURLに設定したLocation
ヘッダーで応答しなければなりません(MUST)(利用者を参照)。リクエストが非同期で処理されるようにキューに入れられた場合、受信者は202 Accepted
というステータス・コードで応答し、リクエストのステータスに関する情報を応答の本文に含めなければなりません(MUST)。
通知に制約を適用する受信者(制約を参照) は、制約が満たされなければ、通知の処理に失敗し、適切な4xx
のエラー・コードを返すべきです(SHOULD)。
受信者は、リクエストの本文がJSON-LDで、Content-Type: application/ld+json
を持つ通知を受け入れなければならず(MUST)、これにはprofile
URI[RFC6906]を含むことができます(MAY)。
受信者は他のRDFコンテンツ・タイプ(例えば、text/turtle
、text/html
)を受け入れることもでき(MAY)、その場合は、受信ボックスのURLのOPTIONS
リクエストへの応答として、受け入れるコンテンツ・タイプをAccept-Post
[Accept-Post]ヘッダーで公言すべきです(SHOULD)。
受信者の例1: optionsの応答
OPTIONS /inbox/ HTTP/1.1
Host: example.org
HTTP/1.1 200 OK
Allow: GET, HEAD, OPTIONS, POST
Accept-Post: application/ld+json, text/turtle
Accept-Post
でOPTIONS
リクエストに応答する受信者。受信者の例2: postの応答
POST /inbox/ HTTP/1.1
Host: example.org
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en
{
"@context": "https://www.w3.org/ns/activitystreams",
"@id": "",
"@type": "Announce",
"actor": "https://rhiaro.co.uk/#me",
"object": "http://example.net/note",
"target": "http://example.org/article",
"updated": "2016-06-28T19:56:20.114Z"
}
HTTP/1.1 201 Created
Location: http://example.org/inbox/92d72f00
POST
リクエストに応答する受信者。受信ボックスのGET
リクエストが成功した場合、リクエスト側がアクセスできることを前提として、通知のURIを含んだHTTP 200 OK
を返さなければなりません(MUST)(該当する場合は4xx
のエラー・コードを返す)。受信者は、利用者がアクセスできる受信ボックス内の通知のURIのみを列挙できます(MAY)。受信ボックスのURLでは、通知の参照用にhttp://www.w3.org/ns/ldp#contains
という述語を用いなければなりません(MUST)。
個々の通知はRDF情報源でなければなりません(MUST)。RDF以外の資源が返された場合は、利用者はそれを無視できます(MAY)。通知のURIのGET
リクエストが成功した場合、リクエスト側がアクセスできることを前提として、HTTP 200 OK
を返さなければなりません(MUST)(該当する場合は4xx
のエラー・コードを返す)。
JSON-LDのコンテンツ・タイプはすべての資源で利用できなければなりませんが(MUST)、クライアントは他のコンテンツ・タイプを優先するAccept
ヘッダーを送信することもできます(RFC7231の3.4項 - 内容交渉)。
クライアントがAccept
ヘッダーを送信しない場合は、サーバーは、JSON-LDや、同じ情報を忠実に伝える任意の形式(例えば、Turtle)でデータを送信できます。
受信ボックス自体に関する追加の記述が返される場合もあります(MAY)(制約)。
この仕様では、受信ボックスの通知のリストを提供するページングのメカニズムを定義していません。実装でページングを有効にしたい場合は、効率的な取得を可能とするために、リンクト・データ・プラットフォーム・ページング1.0、アクティビティ・ストリームズ2.0のコレクションなどの既存のメカニズムを用いるのが良いかもしれません。
受信者の例3: GETの応答
GET /inbox/ HTTP/1.1
Host: example.org
Accept: application/ld+json
Accept-Language: en-GB,en;q=0.8, en-US;q=0.6
HTTP/1.1 200 OK
Content-Type: application/ld+json
Content-Language: en
{
"@context": "http://www.w3.org/ns/ldp",
"@id": "http://example.org/inbox/",
"contains": [
"http://example.org/inbox/5c6ca040",
"http://example.org/inbox/92d72f00"
]
}
GET
リクエストに応答する受信者。受信者は、通知の送信者を検証すべきです(SHOULD)。例えば、次のような方法によります。
受信者は、不当な通知がサーバーで作成され、受信ボックスによって公開されないように、制約を用いてフィルタリングを行うべきです(SHOULD)。
受信者は、信頼できる送信者のホワイトリストへの書き込みを制限するために、受信ボックスのURLへのアクセス制御の実装を検討できます。
利用者は、受信ボックスのURLでGET
リクエストを行うことにより、受信ボックスの通知のURIを取得します(このURLの発見に関しては、発見を参照)。
通知のURIは、受信ボックスのURLのhttp://www.w3.org/ns/ldp#contains
という述語により発見できなければなりません(MUST)(受信ボックスのコンテンツの例を参照)。
受信ボックスや個々の通知を取得する際に、利用者は、Accept
ヘッダーを明示的に設定して、優先するコンテンツ・タイプを示すべきです(SHOULD)(JSON-LDを含む)。個々の通知 — あるのか、何件なのか、または特定の基準(例えば、コンテンツの長さ、タイムスタンプ)に従うのか — のフェッチは、利用者の裁量に委ねられています。
利用者は、認証や承認の目的で、追加のヘッダーやコンテンツを含めることができます(MAY)。
利用者は、自身の裁量で、ペイロードから情報を追加でフェッチしたり推論したりする(例えば、通知で参照されている資源を逆参照してコンテンツをフェッチする)ことができます(MAY)。利用者は、処理や使用をさらに行う前に、通知を、受信ボックスがアナウンスしている制約と照合したいかもしれません(MAY)。
通知のためにフェッチされるURIには、リクエストされたURI自体とは異なる1つ以上の主語であるIRIを持つRDFステートメントを含むことができます(may)。利用者はまた、リクエストされたURIを主語とする何らかのトリプルが通知に含まれていると仮定すべきではありません。これは、通知の本文で相対IRIを用いる場合にも当てはまります。実装が、通知のURIを、通知ペイロードからのRDFを含むグラフとして扱いたい場合があります。
利用者は、受信ボックスに何でもポストできることを認識しているべきです(受信者が設定する制限にもよるが、これに関しては、このプロトコルでは定義していない)。そのため、利用者は、通知データを利用する場合に、コンテンツの信憑性を確認する際に用心が必要かもしれません。
利用者の例: 通知の取得
GET /inbox/14a792f0 HTTP/1.1
Host: example.org
Accept: application/ld+json, text/turtle, application/xhtml+xml, text/html
Accept-Language: en-GB,en;q=0.8, en-US;q=0.6
HTTP/1.1 200 OK
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{ "@language": "en" }
],
"@id": "http://example.org/inbox/14a792f0",
"@type": "Announce",
"actor": {
"@id": "http://csarven.ca/#i",
"name": "Sarven Capadisli"
},
"object": {
"@context": "http://www.w3.org/ns/anno.jsonld",
"@id": "http://example.net/note",
"@type": "Annotation",
"motivation": "http://www.w3.org/ns/oa#assessing",
"rights": "http://creativecommons.org/licenses/by/4.0/"
},
"target": "http://example.org/article",
"updated": {
"@type": "http://www.w3.org/2001/XMLSchema#dateTime",
"@value": "2016-06-28T19:56:20.114Z"
}
}
受信者が別のRDF構文と交渉済みでない限り、通知のペイロードはJSON-LDでなければなりません(MUST)。様々なユースケースを可能とするために、ペイロードの実際の語彙はここでは意図的に規定していません。
この項は非規範的です。
ペイロードの例1
{
"@context": "http://schema.org/",
"@id": "http://example.net/note#foo",
"citation": { "@id": "http://example.org/article#results" }
}
ペイロードの例2
{
"@context": "https://www.w3.org/ns/activitystreams",
"@id": "",
"@type": "Announce",
"actor": "https://rhiaro.co.uk/#me",
"object": "http://example.net/note",
"target": "http://example.org/article",
"updated": "2016-06-28T19:56:20.114Z"
}
ペイロードの例3
{
"@context": { "pingback": "http://purl.org/net/pingback/" },
"@id": "",
"@type": "pingback:Item",
"pingback:source": { "@id": "http://example.net/note#foo" },
"pingback:target": { "@id": "http://example.org/article#results" }
}
ペイロードの例4
{
"@context": "http://schema.org/",
"@id": "",
"@type": "RsvpAction",
"event": { "@id": "http://example.org/event" },
"agent": { "@id": "https://rhiaro.co.uk/#me" }
}
通知には、データに関する特定の外部資源やオリジンを必ずしも参照せずに、独自のURIを持つ複数の資源への参照を含む、任意の情報を含めることができます。そのような通知を利用者がリクエストした場合には、受信者は、最初に送信されたすべてのトリプルを返すことが期待されています。
ペイロードの例5
{
"@context": {
"@language": "en",
"sioc": "http://rdfs.org/sioc/ns#",
"foaf": "http://xmlns.com/foaf/0.1/"
},
"@id": "",
"@type": "sioc:Comment",
"sioc:reply_of": { "@id": "http://example.org/article" },
"sioc:created_at": {
"@type": "http://www.w3.org/2001/XMLSchema#dateTime",
"@value": "2015-12-23T16:44:21Z"
},
"sioc:content": "This is a great article!",
"sioc:has_creator": {
"@id": "http://example.org/profile",
"@type": "sioc:UserAccount",
"sioc:account_of": { "@id": "http://example.org/profile#alice" },
"sioc:avatar": { "@id": "http://example.org/profile/avatar.png" },
"foaf:name": "Alice"
}
}
ペイロードの例6
{
"@context": [{"prov": "http://www.w3.org/ns/prov#"}],
"@id": "http://example.org/activity/804c4e7efaa828e146b4ada1c805617ffbc79dc7",
"@type": "prov:Activity",
"http://www.w3.org/2000/01/rdf-schema#label": {
"@language": "en",
"@value": "Make it so"
},
"prov:endedAtTime": {
"@type": "http://www.w3.org/2001/XMLSchema#dateTime",
"@value": "2016-06-14T20:57:39.000Z"
},
"prov:generated": {
"@id": "http://example.org/entity/804c4e7efaa828e146b4ada1c805617ffbc79dc7",
"@type": "prov:Entity",
"prov:specializationOf": { "@id": "http://example.org/entity/file" },
"prov:wasGeneratedBy": {
"@id": "http://example.org/activity/804c4e7efaa828e146b4ada1c805617ffbc79dc7"
}
},
"prov:wasAssociatedWith": {
"@id": "http://csarven.ca/#i",
"@type": "prov:Agent",
"http://xmlns.com/foaf/0.1/name": {
"@language": "hy",
"@value": "Սարվէն Չափատիշլի"
}
}
}
この項は非規範的です。セキュリティとプライバシーの規範的な要件は、それが最も該当する仕様の項で呼び掛けを行っています。
受信ボックスのURLは、HTTP Link
ヘッダーまたはhttp://www.w3.org/ns/ldp#constrainedBy
というrel
値を持つ資源の本文を介して、独自の制約(例えば、SHACL、ウェブ・アノテーション・プロトコル)をアナウンスできます。送信者は制約の仕様に準拠すべきで、そうしない場合は、受信者が通知を拒否して適切な4xx
エラー・コードを返す場合があります。
受信ボックス(ターゲット)を公言する資源の公開者は、信頼しているサーバーでこれを行う必要があります。公開者は、ヘッダーまたはコンテンツへの第三者のアクセスにより、通知がリダイレクトされる可能性があることを認識している必要があります。
この仕様では、利用者が受信者からの通知をプル(pull)によって読む方法について記述していますが、利用者は、着信型の通知や受信ボックスの内容の変更をプッシュしてもらいたいと思うかもしれません。同様に、受信者は特定の送信者からの通知をリクエストしたいと思うかもしれません。この種の購読メカニズムは範囲外ですが、送信者、受信者、利用者がそのようなアレンジを行うことは禁止されていません。購読を有効にしたい実装では、ActivityPub、WebSub、WebSocketプロトコル、HTTPウェブ・プッシュなどの既存のメカニズムを用いるのが良いかもしれません。
Activity Streams 2.0コアのサポートを希望する受信者の実装では、コンテンツ・タイプと語彙の同等性に関するソーシャル・ウェブ・プロトコル - Inbox Interopを参照できます。
連合型ネットワークでは、ユーザの国際的な基盤を構築することが重要です。一部のLDNの相互作用では、HTMLのフラグメントや要約フィールド(summary field)などの自然言語のテキストでコンテンツを返すことができます。各項目の表現を複数の言語で提供することは、すべての状況で実現できるとは限りません。実装では、HTTP Accept-Language
ヘッダーを用いて交渉し、与えられたリクエストに対して送信するために最も適切な言語表現を選択するなど、利用可能な言語の発見および/または返された言語の交渉を行う手段を提供することが推奨されます。
受信者が、送信者や利用者に認証を求める場合、受信者は、他のエラー・コードを含む他のデータを返す前に、彼らの証明書の有効性を確認すべきです。例えば、受信者は最初に受信ボックスの存在を確認すべきではなく、リクエストを行った者が未検証であれば404 Not Found
を返すべきです。
トークンの受け渡しを伴う認証は、HTTPS経由で行わなければなりません。
自己点検質問票: セキュリティとプライバシーに従って、下記の質問で、この仕様のセキュリティとプライバシーに関する留意点の概要を把握できます。
この仕様は、少なくとも2つの独立した相互運用可能な個々の機能の実装により、勧告案に進みました。個々の機能は、異なる製品によって実装されました。すべての機能を1つの製品で実装する必要はありませんでした。
終了基準を評価する目的で、次のそれぞれを機能と見なしました。
Link
ヘッダーにより、特定の資源の受信トレイを公言します。GET
リクエストに応答し、その表現を用いて個々の通知のGET
リクエストに応答します。この仕様への貢献に対して以下の方々に感謝申し上げます。
この項は非規範的です。
REC-ldn-20170502 ← PR-ldn-20170321 ← CR-ldn-20170223 ← CR-ldn-20161101 ← WD-ldn-20161011 ← WD-ldn-20160926 ← WD-ldn-20160913 ← WD-ldn-20160824 ← WD-ldn-20160726
1.1 ソーシャル・ウェブ・ワーキンググループ
LDNは、ソーシャル・ウェブ・ワーキンググループが作成しているいくつかの関連仕様の1つです。別のアプローチや補足的なプロトコルに関心のある実装者は、概要ドキュメントであるソーシャル・ウェブ・プロトコルを読むことから始めるべきです。拡張性や他のプロトコルとの相互運用性のポイントを強調するために、この仕様の至る所でソーシャル・ウェブ・プロトコルの特定の小項目を参照しています。