XRDS-Simple 1.0 Draft 1:#5 : 俺訳/俺メモ

 

5.  Document Retrieval(ドキュメント取得)

The Consumer obtains the Resource Description Document by following the workflow defined in this section, starting with the Resource Endpoint. XRDS-Simple only defines a retrieval method for HTTP(S) Endpoints. While XRDS-Simple supports descriptions of non-HTTP(S) Endpoints, the method in which their associated Resource Description Document is retrieved is beyond the scope of this specification.

(ConsumerがRDDを取得。まずResource Endpointへ。XRDS-SimpleではHTTP/Sのみ。)

Document retrieval is performed in two steps. First the document’s location is obtained from the Endpoint, then the location obtained is used to request the Resource Description Document.

(まず、ドキュメントの場所をEndPointから教えてもらう。次にRDDをリクエストする。)



TOC


5.1.  Obtaining Location

The document’s location can be obtained using two protocols, originally specified in [Yadis] (Miller, J., “Yadis Specification 1.0,” .) and later adapted in [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0,” .), one uses HTTP HEAD while the other uses HTTP GET.

In both protocols, if the Endpoint contains a fragment, it MUST be removed prior to querying for the document’s location. This is important as the document’s location HTTP(S) URI MAY contain a fragment which carried a special meaning, and MUST NOT be confused with the Endpoint fragment (which is discarded for the purpose of performing discovery). (Endpointにフラグメントが含まれていたら、リクエストするまえに取り除くこと。)

Service Providers MUST support the GET protocol and MAY support the HEAD protocol. Consumers MAY attempt the HEAD protocol but MUST attempt the GET protocol if the HEAD protocol fails. There is no difference between the retrieval workflow of XRDS documents and that of XRDS-Simple documents. (GETはHEADでできることをかならずできること。HEADが失敗したらConsumerはかならずGETすること。ワークフローに違いはない。)

In all cases the HTTP(S) status messages and error codes defined in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol — HTTP/1.1,” .) SHALL apply. Consumers MUST be able to handle HTTP redirects when requesting the document’s location and the Resource Description Document. (ConsumerはHTTPリダイレクトをからなず処理すること。)

If the Service Provider supports HTTP content negotiation, its responses SHOULD include a Vary header to allow caches to properly interpret future requests. This header SHOULD be present even in the case where an HTML page is returned (instead of an XRDS document). (ServiceProviderがコンテントネゴシエーションをサポートするのであれば、Varyヘッダーを返してキャッシュできるようにしないと。XRDSの代わりにHTMLページが返されるときでも返すこと)



TOC


5.1.1.  HEAD Protocol

Using the HEAD protocol, the Consumer MUST issue an HTTP(S) HEAD request to the Endpoint. The request SHOULD include an Accept header specifying content type application/xrds+xml. The response from the Service Provider MUST include only headers, which MUST contain one of the following: (HEADリクエストにはAcceptヘッダーを入れてapplication/xrds+xmlを指定すること。)

  1. An X-XRDS-Location header where the value of the header MUST be an HTTP(S) URI which gives the document’s location. (X-XRDS-Location はドキュメントのHTTP/SのURIでなければいけない)
  2. A Content-Type header specifying the content type application/xrds+xml. In this case the document’s location is identical to the Endpoint, excluding any fragment. (Content-Typeヘッダはapplication/xrds+xml。この場合、ドキュメントの場所とEndPointが同じ。ただし、フラグメントは除く)

If both headers are present, the X-XRDS-Location header is used and the Content-Type header ignored. If neither header is present, the protocol fails and the Consumer MUST attempt the GET protocol (GET Protocol). (どっちも帰ったらX-XRDS-LocationをつかってContent-Typeは無視。どっちもない場合はプロトコルエラーで、ConsumerはGETで再度リクエストすること)



TOC


5.1.2.  GET Protocol

Using the GET protocol, the Consumer MUST issue an HTTP(S) GET request to the Endpoint. The request SHOULD include an Accept header specifying content type application/xrds+xml. The Service Provider response MUST be one of three options:

  1. A Valid XRDS document in the response body. The Response SHOULD include the Content-Type header with value application/xrds+xml. In this case, the response body contains the Resource Description Document and the workflow ends successfully skipping the step described in Section 5.2 (Requesting Document). (ValidなXRDSドキュメントがボディに変える。Content-Typeはapplicaton/xrds+xml。ボディにはRDDが入っていて処理はこれで終わり。)
  2. An X-XRDS-Location header where the value of the header MUST be an HTTP(S) URI which gives the document’s location. (X-XRDS-Locationがかえると、それがドキュメントの場所)
  3. A valid HTML document in the response body, with a <head> element that includes a <meta> element with an http-equiv attribute equals to X-XRDS-Location. The value of the <meta> element content attribute MUST be an HTTP(S) URI which gives the document’s location. (ValidなHTMLが帰れば、<head>の<meta>のhttp-quivでX-XRDS-Locationなタグを見る。contentがドキュメントの場所を示している)

The Consumer MUST check the Service Provider’s response for one of the three options in the order they are listed above, and MUST stop as soon as a match is found. If no match is found, the protocol fails and the discovery workflow ends unsuccessfully.



TOC


5.2.  Requesting Document

Once the document’s location has been obtains, the Consumer MUST check if it is identical to the Endpoint to avoid a loop (ignoring any differences in the URI fragments), in which case the discovery workflow ends unsuccessfully. Otherwise, the Consumer MUST request the XRDS document from the location URI using an HTTP(S) GET. This request SHOULD an Accept header specifying content type application/xrds+xml. (ConsuerはURIフラグメントの違いを無視して、むだなループを避けること。リクエストするときにはAcceptヘッダーを追加してあapplication/xrds+xmlを指定。)

The Service Provider MUST reply with a Valid XRDS document in the response body. The Response SHOULD include the Content-Type header with value application/xrds+xml. If the response is not a valid XRDS document, the discovery workflow ends unsuccessfully. (Service ProviderはValid XRDSをボディに返すこと。Content-Type : application/xrds+xmlを返すこと。ValidなXRDSドキュメントでない場合、エラーとしてワークフローを終了)

If the document’s location URI contains a fragment, it is used as an XRD identifier pointing to a specific element with an xml:id attribute of identical value. The XRD identifier is described in Section 7.1 (XRD Identification).(URIにフラグメントがあれば特定のエレメントをさすXRD識別子として使われる。xml:id に一致する。 #7参照)

Implementers’ Draft: XRDS-Simple 1.0 Draft 1

カテゴリー: 未分類 パーマリンク

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中