【注意】 このドキュメントは、W3CのWebmention W3C Recommendation 12 January 2017の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。
First Update: 2017年1月20日
公開以後に報告されたエラーや問題がないか正誤表を確認してください。
この仕様の英語版が唯一の規範のバージョンです。非規範の翻訳版も入手可能かもしれません。
Copyright © 2017 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
Webmentionは、自身のサイトで任意のURLについて言及する時に、そのことを通知するシンプルな方法です。受信者の観点から見れば、他のサイトで言及される時に通知をリクエストする方法の1つです。
この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスにあります。
このドキュメントは、ソーシャル・ウェブ・ワーキンググループによって勧告として公開されました。このドキュメントに関してコメントを行いたい場合には、public-socialweb@w3.org(購読、アーカイブ)にお送りください。どのようなコメントでも歓迎します。
ワーキンググループの実装報告書を参照してください。
このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。
このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。
W3Cは、この勧告で指定されている機能はFetchに対する変更の影響を受けないと予想しています。
このドキュメントは、2015年9月1日のW3Cプロセス・ドキュメントによって管理されています。
Webmentionは、あるURLが別のURLにリンクされているという通知です。例えば、アリス(Alice)が彼女のブログで面白い投稿を行ったとします。そして、ボブ(Bob)が彼自身のサイトで、彼女の投稿に対する応答を、アリスの元の投稿にリンクして書きます。ボブの公開用ソフトウェアにより、彼女の記事に応答があったことを通知するWebmentionがアリスに送信されると、アリスのソフトウェアは、その応答を元の投稿に関するコメントとして表示できます 。
Webmentionの送信はブログの投稿に限らず、その他の種類のコンテンツや応答にも使用できます。例えば、応答は、イベントへのRSVP(回答リクエスト)、他者の投稿に対する「お気に入り」の表示、他者の投稿の「ブックマーク」など、様々なものでありえます。Webmentionは、別々のウェブサイトでこれらの相互作用を可能にし、分散型のソーシャル・ウェブを可能にします。
この項は非規範的です。
Webmention仕様は、[Pingback]仕様を簡素化したバージョンとして始まりました。PingbackではソースとターゲットのURLをXML-RPCペイロードで送信する必要があったのを、Webmentionでは、フォーム・エンコードされたペイロードに簡素化しており(HTMLのフォームで容易に使用できるように)、フォーム・エンコードされたペイロードに対応するツールは多く存在しており、XML-RPCによるシステムの他の部分のコードの思いがけない露呈に弱くありませんでした。
その後、Webmentionは、リクエストの送信と検証の詳細についても引き続きより完全に規定し、ソース・ドキュメントが更新または削除された時の通知の送信をサポートするように拡張されました。より詳細な情報がIndieWeb wikiのWebmention FAQにあるもしれません。
この項は非規範的です。
典型的なWebmention流れは次の通りです。
この項は非規範的です。
Webmentionは、ターゲットについてソースURLで言及されたことをそのターゲットに通知するために、ソースURL「から」ターゲットURL「に」送信されます。
sourcetarget。targetがアーロンのブログ上の有効なpermalinkであるかを検証します(そうでなければ、プロセスを終了)。targetに対するハイパーリンクがWebmention(リダイレクト後の、検索時に[FETCH])のsourceに含まれているかを検証します(そうでなければ、プロセスを終了)。このドキュメントの「しなければならない(MUST)」、「してはならない(MUST NOT)」、「必須である／要求される(REQUIRED)」、「することになる(SHALL)」、「することはない(SHALL NOT)」、「すべきである／する必要がある(SHOULD)」、「すべきでない／する必要がない(SHOULD NOT)」、「推奨される(RECOMMENDED)」、「することができる／してもよい(MAY)」、「選択できる／任意である(OPTIONAL)」というキーワードは、[RFC2119]で記述されているように解釈されるべきです。
Webmentionの実装は、送信者か受信者のいずれかです。この項では両者に対する適合性基準について記述します。
下記は、既知の種類のWebmention実装です。
Webmention送信者(Webmention Sender)は、Webmentionを送信する実装です。送信者がWebmentionを送信するためには、受信者がアクセスできるURLに最初にドキュメントがなければなりません。
Webmention送信者の適合性基準については、Webmentionの送信で説明しています。
下記は、いくつかの既知の種類のWebmention送信者です。
Webmention受信者(Webmention Receiver)は、受信者のWebmentionエンドポイントが公言されている1つ以上のターゲットURLに対するWebmentionを受信する実装です。Webmentionを受信するためには、受信者のWebmentionエンドポイントを公言するURLがなければなりません。そのURLは、完全に別のシステムやドメインに存在しえるため、受信者の実装の一部とは見なされません。
Webmention受信者の適合性基準については、Webmentionの受信で説明しています。
下記は、いくつかの既知の種類のWebmention受信者です。
http://webmention.net/implementation-reports/で実装報告を提出してください。手順は当該URLで提供しています。実装報告テンプレートは、webmention.rocksで入手可能なテストを参照します。
webmention.rocksでは、自身の実装の実演テストを行うために用いることができる多くのテストケースが提供されています。エラー発生時に詳細なレスポンスが得られるため、Webmention実装の開発中に用いると有用なツールでもあります。
この仕様は、HTMLとHTTPの両方のリンク関係に関して[HTML5]で定義されているとおりにlink relレジストリを用います。
Webmentionは、ターゲットについてソースURLで言及されたことをそのターゲットに通知するために、ソースURL「から」ターゲットURL「に」送信されます。Webmentionが送信可能となる前に、Webmentionの送信先となるソースURLが存在している必要があり、それはブログの投稿であることが多いですが、どのような種類のコンテンツであってもかまいません。
例えば、https://waterpigs.example/post-by-barnabyのURLに、アーロンの投稿へのリンクを有する下記のHTMLを記述することができます。
<!doctype html>
<html>
<body>
<a href="https://aaronpk.example/post-by-aaron">This is a great post</a>
</body>
</html>
送信者は、ターゲットURLを取って来て(そして、リダイレクトに従い[FETCH])、webmentionというrelの値を持つHTTP Linkヘッダー[RFC5988]をチェックしなければなりません(MUST)。ドキュメントのコンテンツ・タイプがHTMLである場合、送信者は、webmentionというrelの値を持つHTMLの<link>と<a>要素を探さなければなりません(MUST)。これらが複数存在している場合は、最初のHTTP Linkヘッダーが優先され、その後にドキュメントの順に最初の<link>または<a>の要素が続きます。送信者は、3つのオプションをすべてサポートし、この順序でフォールバックを行わなければなりません(MUST)。
エンドポイントは相対URLでありえ(MAY)、その場合、送信者は[URL]に従ってtarget URLに対して相対的にそれを解決しなければなりません(MUST)。
エンドポイントにはクエリ文字列パラメータを含むことができ(MAY)、それは、クエリ文字列パラメータのまま保持されなければならず(MUST)、Webmentionリクエストの送信時にPOSTのBODYパラメータとして送信してはなりません(MUST NOT)。
送信者は、GETリクエストを行う前に最初にHTTP HEADリクエスト[RFC7231]を行ってLinkヘッダーをチェックすることができます(MAY)。
GET /post-by-aaron HTTP/1.1
Host: aaronpk.example
HTTP/1.1 200 OK
Link: <http://aaronpk.example/webmention-endpoint>; rel="webmention"
<html>
<head>
...
<link href="http://aaronpk.example/webmention-endpoint" rel="webmention" />
...
</head>
<body>
....
<a href="http://aaronpk.example/webmention-endpoint" rel="webmention">webmention</a>
...
</body>
</html>
送信者は、このリクエストがWebmention発見の一部として行われることを受取人に示すために、ターゲットURLを取って来る際に用いるHTTP User Agent[RFC7231]をカスタマイズすることができます(MAY)。その場合、User Agentに「Webmention」という文字列を含めることをお奨めします。これにより、なぜ発見のリクエストが行われたかを知るための示唆が与えられます。
送信者は、x-www-form-urlencoded[HTML5]形式のsourceとtargetのパラメータをWebmentionエンドポイントにポストしなければならず(MUST)、そのsourceはリンクを含んだ送信者ページのURLであり、targetはリンク先ページのURLです。
WebmentionエンドポイントURLにクエリ文字列パラメータが含まれている場合は、クエリ文字列パラメータはそのまま保持されなければならず(MUST)、POSTのBODYに送信されてはならない(MUST NOT)ことに注意してください。
Webmentionエンドポイントはリクエストを認証して処理し、HTTPステータス・コード[RFC7231]を返します。ほとんどの場合、202 Accepted(受理)か201 Created(生成)が返されます。これは、DoS(Denial of Service)攻撃を防止するために、リクエストがキューに入れられ、非同期的に処理されていることを示します。応答コードが201であれば、Locationヘッダーには、リクエストのステータスをモニターするために使用できるURLが含まれるでしょう。
あらゆる2xxの応答コードは成功とみなされなければなりません(MUST)。
POST /webmention-endpoint HTTP/1.1
Host: aaronpk.example
Content-Type: application/x-www-form-urlencoded
source=https://waterpigs.example/post-by-barnaby&
target=https://aaronpk.example/post-by-aaron
HTTP/1.1 202 Accepted
ソースURLが更新された場合は、送信者は以前に送信したWebmentionを再送信すべきで(SHOULD)(ドキュメントから削除された可能性があるURLに対するWebmentionの再送を含む)、そのURLで表示される新しいリンクにWebmentionを送信すべきです(SHOULD)。
これにより、Webmentionの受取人がソース・ドキュメントの表示を更新すること、または、URLのうちの1つについて言及した投稿が更新されたことを受取人に通知することが可能となります。
投稿が変更された際にWebmentionを送信する時には、送信者は、ターゲットがWebmentionエンドポイントを更新してしまっている場合に備え、各ターゲットURLのWebmentionエンドポイントの再発見を行わなければなりません(MUST)。
ソースURLへの応答がソースURLページで示されていれば(例えば、コメントとして)、送信者はそれをソースURLの更新として扱い、以前に送信したWebmentionを再送信すべきです(SHOULD)。
ソースURLが削除された場合は、送信者はそのURLに対してHTTP 410 Gone(消滅)のステータス・コードを返すべきで(SHOULD)、一般的に、投稿のプロパティーの値を空白にする、および／または、投稿の主要なコンテンツ(例えば、[h-entry]の名前および／またはコンテンツ)を「削除」に置き換えるなどの方法で、削除された投稿の「tombstone」(墓石。訳注:削除されたオブジェクトを表す)表現を表示すべきです(SHOULD)。その後、送信者はそのドキュメントに対し以前に送信したすべてのWebmentionにWebmentionを再送信すべきです(SHOULD)。
これにより、以前受信したWebmentionをコメントやその他の相互作用として表示していたであろう受信者は、削除をサポートしている場合には、更新のみをサポートしている受信者には妥当なフォールバックを提供しつつ、それを表示から削除することが可能となります。
sourceとtargetのパラメータが含まれているPOSTリクエストを受信した時には、受信者はそのパラメータを検証すべきで(SHOULD)(下記のリクエストの検証を参照)、DoS攻撃を防止するために、リクエストをキューに入れ、非同期的に処理すべきです(SHOULD)。受信者がそれを処理する方法により、リクエストへの応答は3種類ありえます。
ステータスをチェックするために送信者が使用できるステータス・ページを受信者が作成する場合、受信者は、ステータスURLを指し示すLocationヘッダーを持つHTTP 201 Created(生成)という応答で回答しなければなりません(MUST)。応答のBODYにはコンテンツを含むことができます(MAY)。
HTTP/1.1 201 Created
Location: http://aaronpk.example/webmention/DEhB9Jme
受信者がリクエストを非同期的に処理したにも関わらず、ステータスURLを返さない場合は、受信者はHTTP 202 Accepted(受理)という応答で回答しなければなりません(MUST)。応答のBODYにはコンテンツを含むことができ(MAY)、その場合、人間が読める応答が推奨されます。
HTTP/1.1 202 Accepted
受信者がリクエストを処理し、検証ステップを同期的に実行することを選択すれば(非推奨)、成功時に200 OK(OK)のステータスで応答しなければなりません(MUST)。
受信者は、sourceとtargetが有効なURL[URL]であり、受信者がサポートしているスキームであることをチェックしなければなりません(MUST)。(ほとんどの場合、これは、sourceとtargetのスキームがhttpまたはhttpsであることをチェックすることを意味します)。
ソースURLがターゲットURLと同じであれば、受信者はリクエストを拒否しなければなりません(MUST)。
受信者は、targetが、Webmentionを受け入れることができる有効な資源であるかをチェックすべきです(SHOULD)。より詳細な検証を開始する前に無効なWebmentionを拒否するために、このチェックは同期的に行われるべきです(SHOULD)。「有効な資源」が何を意味するかは、受信者次第です。例えば、複数のドメインに対してWebmentionを受け入れることができる受信者もいれば、エンドポイントが置かれているのと同じドメインに対してのみWebmentionを受け入れることができる受信者もいます。
ターゲットURLにフラグメント識別子が含まれているかもしれないことに注意してください。そして、どのURLがWebmentionを受信できるのかを受信者が制限している場合には、URLがサポートされているかどうかをチェックする時にフラグメントを無視すべきです(SHOULD)。
Webmentionの検証は、DoS(Denial of Service)攻撃を防止するために、非同期的な処理によるべきです(SHOULD)。
受信者が何らかの方法(投稿に関するコメントとして表示したり、「お気に入り」カウンターの数を増やしたり、投稿の著者を通知したり)でWebmentionを使おうとする場合、実際にそれがターゲットについて言及していることを確認するために、HTTPリダイレクトに従い(従うリダイレクトの数は制限すべき(SHOULD))、ソースにHTTP GETリクエストを実行しなければなりません(MUST)。受信者は、受け入れ可能なコンテンツ・タイプのプレファレンスを示すHTTP Acceptヘッダーを含めるべきです(SHOULD)。
受信者は、ソース・ドキュメントがターゲットURLについて言及しているかどうかを判断するためにper-media-typeの規則を用いるべきです(SHOULD)。例えば、[HTML5]ドキュメントでは、受信者は<a href="*">、<img href="*">、<video src="*">などのリンクを捜すべきです。JSON（[RFC7159]）ドキュメントでは、受信者は、値がURLに完全一致するプロパティーを捜すべきです。ドキュメントがプレーン・テキストである場合は、受信者は文字列を検索してURLを捜すべきです。その他のコンテンツ・タイプは実装者の裁量で処理できます。ソース・ドキュメントには、それが有効なWebmentionと見なされるために、target URLの完全一致が含まれていなければなりません(MUST)。
この段階で、受信者は、ソース・ページのコンテンツを、ソースから入手したその他のデータとともに、ターゲットのページやその他のページに掲載することができます(MAY)。例えば、受信者は、ソースのコンテンツを投稿に関するコメントとして表示したり、投稿を「お気に入り」にした人達のリストを表示するなど、同じようなWebmentionを送信した他の人達のリストに著者のプロフィール写真を表示したりすることができます。
ソース・ページのコンテンツを再掲載する時には、うっかりそのコンテンツの公開範囲を変更してしまわないように気をつけるべきです。例えば、制限された対象者にのみソース・ドキュメントを表示できる場合は、再掲載されたコンテンツが一般ユーザには決して表示されないようにすべきです。ソース・ドキュメントは、何らかの認証によって、または、受信者もその内側にいるファイアウォール内にソースURLがあるために、特定の対象者にに限定されているかもしれません。
送信者の行為が原因でWebmentionが成功しなかった場合は、400 Bad Request(不正リクエスト)のステータス・コードを返さなければならず(MUST)、応答本文にエラーの説明を含めることができます(MAY)。
ソースに対してGETリクエストを行う前に同期的に返される可能性のある送信者関連エラーは次のとおりです。
target URLが見つからない。target URLがWebmentionを受け入れない。source URLは不正またはサポートしていないURLスキーム(mailto:リンクなど)であった。ソースURLのコンテンツを取って来た後に生じる可能性のある送信者関連エラーは次のとおりです。
source URLが見つからない。source URLに、target URLへのリンクが含まれていない。受信者のサーバー側のエラーが原因でWebmentionが成功しなかった場合は、500 Internal Server Error(サーバー内部エラー)のステータス・コードを返すべきで(SHOULD)、応答本文にエラーの説明を含めることができます(MAY)。
受信者が、過去に同じsourceとtargetのWebmentionを受け取ったことがある場合は、次のとおりです。
sourceから入手した既存のデータを更新すべきです(SHOULD)。
410 Gone(消滅)のステータス・コードを受信したり、200 OK(OK)のステータス・コード受信したもののsourceにtargetについての言及がなかった場合は、既存のWebmention削除するか、削除されたと記述すべきです(SHOULD)。sourceとtargetに対して複数のWebmentionを受信しても、複数の応答として表示すべきではありません。Webmentionプロトコルは、受信者のエンドポイントを発見するためにGET(またはHEAD)リクエストを行う送信者に依存し、その後に、リンクを検証するために送信者のウェブ・ページに対してGETリクエストを行う受信者が続きます。これは、送信者が受信者に任意のURLへのGETリクエストを実行させることができることを意味し、DoS媒介者の可能性が広がります。
受信者は、リンクの検証時に最初のHTTP HEADリクエストを行い、コンテンツ・タイプ、長さ、またはその他の返されたHTTPヘッダーを最初に検証した後に完全なGETリクエストを行うかどうかを決定できます(MAY)。
受信者は、送信者がリダイレクトを送信し続けた場合に、リダイレクトのループから抜け出せなくなるのを防止するために、数を20に制限するなど、従うHTTPリダイレクトの数に制限を設けるべきです(SHOULD)。
受信者は、未検証ソースURLを取得するデータ量と時間に制限を設けるべきです(SHOULD)。例えば、ソースURLが5秒以内に応答しなければ、失敗とみなすことができます。同様に、受信者は、そのページの最初の1MBのみを取って来ることができます。なぜなら、妥当なHTMLやJSONページはそれより小さいからです。
送信者が受信者のWebmentionエンドポイントを発見した時に、そのエンドポイントがローカルホストやその他のループバック・アドレスであるというもっともな理由はほとんどありません。送信者が、認証が不要なローカルホストで動作するサービスを持っていれば、悪意のあるWebmention受信者は、送信者に任意のPOSTリクエストを行わせることができるWebmentionエンドポイントを作り出すことができます。
発見段階で、エンドポイントがローカルホストやループバックIPアドレス(127.0.0.0/8)であることに送信者が気づいた場合は、そのエンドポイントにWebmentionを送信すべきではありません(SHOULD NOT)。
この仕様は、認証ヘッダーやセッション・クッキーなどの追加のヘッダーやパラメータが含まれている可能性のあるWebmentionリクエストの特別な処理については定義していません。しかし、Webmentionエンドポイントが追加のヘッダーのあるリクエストを受け入れる場合は、クロスサイト・リクエスト・フォージェリ(CSRF)攻撃から自身を守るべきです(SHOULD)。CSRF攻撃を防止する1つの方法は、エンドポイントを発見する時にWebmention送信者がトークンを見つけられるように、Webmentionエンドポイントのクエリ文字列パラメータにCSRFトークンを含めることです。
例えば、ターゲットURLは、CSRFトークンが含まれているWebmentionエンドポイントを公言できます。
GET /post-by-aaron HTTP/1.1
Host: aaronpk.example
HTTP/1.1 200 OK
Link: <http://aaronpk.example/webmention?csrf=Q0NTVhYjI0NTVkNDA3M>; rel="webmention"
その結果、Webmentionエンドポイントがリクエストを処理する時には、他の処理の前にCSRFトークンの妥当性を最初にチェックできます。
攻撃者は、任意のURLを指し示すWebmentionエンドポイントを公言することができます。そのため、ファイアウォール内にあるサーバーや、通常は保護されている資源にアクセスできるサーバー上でWebmentionを送信するソフトウェアをインストールする場合、攻撃者がそのサーバーに対して、内部のサーバーにPOSTリクエストを送信させることができることを知っておくべきです。このサーバーが、次のどちらの場合も、保護されている資源にアクセスできないように予防策を講じるべきです(SHOULD)。
自己点検質問票: セキュリティとプライバシー([security-privacy-questionnaire])に従って、下記の質問で、この仕様のセキュリティとプライバシーに関する留意点の概要を把握できます。
ソース・ドキュメントがHTMLではなかったり(PDFなど)、シンプルなHTTP GETリクエストでは生のソースを取って来ることができなかったりする場合(ペイウォール内や、クリック・スルーのライセンス契約など)は、Webmentionを送信したいすべてのターゲットをリストアップしたHTMLの「ランディング・ページ」を設ける必要があります。このHTMLのランディング・ページを作成した後で、Webmentionの送信時に、そのURLをソースURLとして用いることができます。これにより、受信者は、完全なソース・ドキュメントの公表を避けながら、自身のターゲットURLに対するリンクを検証するために取って来ることができるURLを得ることができます。
HTMLのランディング・ページの作成は、学術論文などの制限的なコンテンツを参照する時のリンク先として便利な場所を提供することにより、自身のコンテンツに対するインバウンド・リンクの数を増大させるのに役立つ可能性があります。学術論文の場合、WebmentionターゲットURLとして使用できるように、ランディング・ページにはHTMLの参考文献リストが含まれているべきです。
Webmentionソース・ドキュメントが特に大きい場合は(表内に数千のレコードが含まれている大きなHTMLページや、非常に大きなJSONファイルなど)、そのソースURLを有するWebmentionを送信することは避けたいでしょう。それを行うと、自身の帯域幅の多くを用いて、受信者に全データセットをダウンロードさせることになります。あるいは、受信者は、自身の帯域幅の使用を限定するために、ファイルの最初の部分のみをダウンロードするかもれしず、潜在的に検証が失敗することになります。受信者があなたのソース・ドキュメントに再度リンクを掲載すれば、他の訪問者がそのリンクをたどり、不用意に全データセットをダウンロードするかもしれません。
ブラウザでの閲覧時には、大きなデータセットを複数のページに分割するのがよい慣行と考えられているのと同じくらい、Webmentionの送信時には、ソース・ドキュメントが大きければ、データのより小さなページからのみWebmentionを送信すべきです。データセットがHTMLであれば、(おそらく)既存のHTMLページをソースURLとして使用できます。データセットがJSONであれば、ソースURLとして使用できるページのより小さなJSONドキュメントでURLを作成する必要があるかもしれません。
Webmention発見の実行時に、送信者はターゲットURLから返されたHTTPキャッシュ・ヘッダー[RFC7234]を尊重し、ヘッダーが示す以上の頻度でターゲットURLを取りに行くことは避けるべきです((SHOULD))。
下記のリンク関係型が[RFC5988]の6.2.1項でIANAにより登録されています。
実装においてsourceとtargetのパラメータをURIとして扱いたい場合は、その用語にhttp://www.w3.org/ns/webmention#という接頭辞を付与できます。
この項は非規範的です。
下記のWebmention拡張仕様には、ウェブ上で実演できる2+相互運用が可能な実装があるため、ここで掲載しています。
[Vouch]プロトコルはWebmentionに対するアンチ・スパム拡張です。
[Salmention]プロトコルは、コメントやその他の相互作用を広めるためのWebmentionに対する拡張です。
[Private-Webmention]プロトコルは、アクセス制御を有する投稿に対するWebmentionの送信と検証をサポートするWebmentionに対する拡張です。
この項は非規範的です。
この項は非規範的です。
Webmentionに関する記事のリストはIndieWeb wikiで見つけることができます。
この項は非規範的です。
Webmention実装のリストはwebmention.netで見つけることができます。
編集者は、Webmentionの元のドラフト仕様の提供に関し、Sandeep Shettyに感謝を表します。
さらに、編集者は、サポート、激励および熱意に関し、IndieWebコミュニティおよびその他の実装者(Amy Guy、Benjamin Roberts、Ben Werdmuller、Dave Wilkinson、Rob SandersonおよびTantek Celikを含むがこれに限らない)に感謝を表します。
この項は非規範的です。
注: URLは様々な方法、様々なコンテキストで使用できます。厳密なURLを作成するためには、[RFC3986]と[RFC3987]を検討すると良いかもしれません。URLの仕様では、URLという用語、URLを扱うための様々なアルゴリズム、URLを構築、解析、解決するためのAPIが定義されています。開発者は、https://url.spec.whatwg.org/の進展を観察し、最新のURL開発についていくことをお奨めします。
警告として述べると、ウェブブ・ラウザと、HTMLコンテキストの外にあるその他のソフトウェアの山では、URLを処理する方法に著しい違いがあります。既存のWebコンテンツを壊すようなURL処理は受け入れられませんが、URL処理のある重要な部分は、実装に依存すると見なすべきです(例えば、file: URLの解析や、[RFC3986][RFC3987]構文下で構文エラーとなるようなURLの操作)。
1.1 ソーシャル・ウェブ・ワーキンググループ
この項は非規範的です。
Webmentionは、ソーシャル・ウェブ・ワーキンググループが作成しているいくつかの関連仕様の1つです。別のアプローチや補完的なプロトコルに興味がある実装者は、概要ドキュメント[social-web-protocols]を読むことから始めるべきです。