Hatena::ブログ(Diary)

Yet Another Hackadelic

2008-10-26

XRDS Document のメモ (6) - 4.2.6 Service Endpoint Selection Elements

The final set of service endpoint descriptor elements is used in XRI resolution for service endpoint selection. These all include two global attributes used for this purpose: match and select. 4.2.6 Service Endpoint Selection Elements

service endpoint descriptor 要素の最後のセットは service endpoint の選択の為の XRI resulution で使われるものです。これらは全て match と select と言うこの目的の為に使われるグローバル属性を含んでいます。

xrd:XRD/xrd:Service/xrd:Type

0 or more per xrd:XRD/xrd:Service element. A unique identifier of type xs:anyURI that identifies the type of capability available at this service endpoint. See section 3.1.2 for the resolution service types defined in this specification. If a service endpoint does not include at least one xrd:Type element, the service type is effectively described by the type of URI specified in the xrd:XRD/xrd:Service/xrd:URI element, i.e., an HTTP URI specifies an HTTP service. See section 13.3.6 for Type element matching rules. xrd:XRD/xrd:Service/xrd:Type

xrd:XRD/xrd:Service 要素に対して 0 以上存在します。この service endpoint における利用出来る能力の種別を識別する xs:anyURI 型のユニークな識別子です。この仕様で定義される resolution service 型 の為に 3.1.2 節を見て下さい。もし service endpoint が少なくとも一つ xrd:Type 要素を含まない場合、service type は事実上 xrd:XRD/xrd:Service/xrd:URI 要素の中で指定された URI の型によって記述されます。例えば HTTP URI は HTTP サービスであるという具合です。TYpe 要素のマッチングルールについては 13.3.6 節を見て下さい。

xrd:XRD/xrd:Service/xrd:Path

0 or more per xrd:XRD/xrd:Service element. Of type xs:string. Contains a string meeting the xri-path production defined in section 2.2.3 of [XRISyntax]. See section 13.3.7 for Path element matching rules. xrd:XRD/xrd:Service/xrd:Path

xrd:XRD/xrd:Service 要素に対して 0 以上存在します。[XRISyntax] の 2.2.3 節で定義される xri-path が提示する事を兼ね備える文字列を含みます。Path 要素のマッチングルールの為に 13.3.7 節を見て下さい。

xrd:XRD/xrd:Service/xrd:MediaType

0 or more per xrd:XRD/xrd:Service element. Of type xs:string. The media type of content available at this service endpoint. The value of this element MUST be of the form of a media type defined in [RFC2046]. See section 3.3 for the media types used in XRI resolution. See section 13.3.8 for MediaType element matching rules. xrd:XRD/xrd:Service/xrd:MediaType

xrd:XRD/xrd:Service 要素に対して 0 以上存在します。xs:string 型です。この service endpoint において利用可能なコンテンツのメディアタイプです。この要素の値は [RFC2046] で定められたメディアタイプの形式でなければなりません (MUST)。XRI resolution で利用されるメディアタイプについては 3.3 節を見て下さい。MediaType 要素のマッチングルールに関しては 13.3.8 節を見て下さい。

The XRD schema (Appendix B) allows other elements and attributes from other namespaces to be added throughout. As described in section 17.1.1, these points of extensibility can be used to deploy new XRI resolution schemes, new service description schemes, or other metadata about the described resource. 4.2.6 Service Endpoint Selection Elements

XRD schema (付録 B) ではいたるところに付け加えられる為の他のネームスペースからの他の要素や属性を許容します。17.1.1 節で記述されているものとして、これらの拡張性の要点は新しい XRI resolution schemes、新しい service description schemes、あるいは記述されたリソースに関するほかのメタデータを配置する為に使われる事ができます。

2008-10-24

XRDS Document のメモ (5) - 4.2.5 Service Endpoint Trust Elements

Similar to the XRD trust elements defined above, these elements enable trust to be established in the provider of the service endpoint. These elements are OPTIONAL for generic authority resolution (section 9), but REQUIRED for SAML trusted authority resolution (section 10.2). 4.2.5 Service Endpoint Trust Elements

上記で定義された XRD trust elements に似たもので、これらの要素は service endpoint のプロバイダ中で確立される為の信頼を可能にします。これらの要素は generic authority resolution (9節) では OPTIONAL ですが、SAML trusted authority resolution (10.2 節) では必須となります。

xrd:XRD/xrd:Service/xrd:ProviderID

0 or 1 per xrd:XRD/xrd:Service element. Identical to the xrd:XRD/xrd:ProviderID above, except this identifies the provider of the described service endpoint instead of the provider of the XRD. For an XRI authority resolution service endpoint, it identifies the child authority who will perform resolution of subsequent XRI subsegments. In SAML trusted resolution, when a resolution request is made to the child authority at this service endpoint, the contents of the xrd:XRD/xrd:ProviderID element in the response MUST match the content of this element for correlation as defined in section 10.2.5. The same usage MAY apply to other services not defined in this specification. Authors of other specifications employing XRD service endpoints SHOULD define the scope and usage of this element, particularly for trust verification. xrd:XRD/xrd:Service/xrd:ProviderID

xrd:XRD/xrd:Service 要素に対して 0 または 1つあります。上記の xrd:XRD/xrd:ProviderID とこれが XRD のプロバイダの代わりに記述された service endpoint のプロバイダを識別するという事以外は同じです。XRI authority resolution service endpoint の為に、それに続く XRI サブセグメントの解決を進めるであろう子 authority を識別し、resolution リクエストは service endpoint にある子 authority に対して作られ、レスポンス中の xrd:XRD/xrd:ProviderID の内容は 10.2.5 節で定義された相互作用の為のこの要素の内容を一致しなければなりません (MUST)。同じ使い方はこの仕様で定義された他のサービス適用される事は無い場合があります (MAY)。XRD service endpoints を採用する他の仕様の著者は範囲とこの要素の特に信頼性の検証における使用法を定義すべきです (SHOULD)。

xrd:XRD/xrd:Service/ds:KeyInfo

0 or 1 per xrd:XRD/xrd:Service element. This element provides the digital signature metadata necessary to validate interaction with the resource identified by the xrd:XRD/xrd:Service/xrd:ProviderID (above). In XRI resolution, this element comprises the key distribution method for SAML trusted authority resolution as defined in section 10.2.5. The same usage MAY apply to other services not defined in this specification. xrd:XRD/xrd:Service/ds:KeyInfo

xrd:XRD/xrd:Service 要素に対して 0 または 1つあります。この要素は xrd:XRD/xrd:Service/xrd:ProviderID (上記) によって識別されるリソースとの相互作用を検証する為に必要なデジタル署名メタデータを提供します。XRI resolution の中でこの要素は 10.2.5 節で定義された authority resolution で信頼された SAML の為にキー分割手法を含みます。同じ使い方はこの仕様で定義された他のサービス適用される事は無い場合があります (MAY)。

2008-10-23 疲れた、続きは明日以降。

XRDS Document のメモ (4) - 4.2.4 Service Endpoint Descriptor Elements

むぅ、、、いきなり長いな。

The next set of elements is used to describe service endpoints―the set of network endpoints advertised in an XRD for performing delegated resolution, obtaining further metadata, or interacting directly with the target resource. Again, because there can be more than one instance of a service endpoint that satisfies a service endpoint selection query, or more than one instance of these elements inside a service descriptor, these elements all accept the global priority attribute (section 4.3.3). IMPORTANT: Establishing unambiguous priority is especially important for service endpoints because they are used to control the direction of authority resolution, the order of Redirect and Ref processing, and the prioritization of the final service endpoint URIs selected (if any). See section 4.3.3 for rules and recommendations about usage of the priority attribute. Note that to prevent processing conflicts, the XRD schema permits only one of these element types in a service endpoint: xrd:URI, xrd:Redirect, or xrd:Ref. 4.2.4 Service Endpoint Descriptor Elements

次の要素セットは service endpoint 、delegated resolution、さらなるメタデータの取得、あるいは対象リソースと直接相互作用する為の XRD 中で公表されたネットワークエンドポイントのセット、の記述に用いられます。再び、service endpoint の選択クエリが満たされる service endpoint のインスタンスが一つ以上ある、あるいは service descriptor の中にそれらの要素のインスタンスが一つ以上あるので、これらの要素全てはグローバル priority 属性を受け付けます。(4.3.3 節)

重要: 明白な priority を確立する事はそれらが authority resolution の指示を操作し、Redirect と Ref の実行順序、さらに最終的な service endpoint URI の選択に対する優先付けの為に用いられるので service endpoint にとって重要です。priority 属性の使用に関する規則と推奨事項に関して 4.3.3 節を見て下さい。

重複実行を防ぐため、XRD スキーマはservice endpoint の中で次のいずれかの要素型、xrd:URI, xrd:Redirect, あるいは xrd:Ref の一つのみに許可しています。

xrd:XRD/xrd:Service

0 or more per xrd:XRD element. The container element for service endpoint metadata. Referred to by the abbreviation SEP. xrd:XRD/xrd:Service

xrd:XRD 要素に対して 0 以上あります。service endpoint メタデータの為のコンテナです。省略系として SEP と呼ばれます。

xrd:XRD/xrd:Service/xrd:LocalID

0 or more per xrd:XRD/xrd:Service element. Identical to the xrd:XRD/xrd:LocalID element defined above except this synonym is asserted by the provider of the service and not the parent authority for the XRD. MAY be used to provide one or more identifiers by which the target resource SHOULD be identified in the context of the service endpoint. See section 5.2.1 for detailed requirements. xrd:XRD/xrd:Service/xrd:LocalID

xrd:XRD/xrd:Service 要素に対して 0 以上あります。このシノニムがサービスのプロバイダによってアサートされるのと、その XRD に対する 親 authority では無いということを除いて上記で定義された xrd:XRD/xrd:LocalID とまったく同じです。service endpoint のコンテキスト中で識別されるべき対象リソースによって、一つ以上の identifier が 提供されるために用いられる場合があります (MAY)。詳細な要求は 5.2.1 節を見て下さい。

xrd:XRD/xrd:Service/xrd:URI

0 more per xrd:XRD/xrd:Service element. Type xs:anyURI. Choice between this or the xrd:XRD/xrd:Service/xrd:Redirect or xrd:XRD/xrd:Service/xrd:Ref elements. If present, it indicates a transport-level URI for accessing the capability described by the parent Service element. For the service types defined for XRI resolution in section 3.1.2, this URI MUST be an HTTP or HTTPS URI. Other services may use other transport protocols. xrd:XRD/xrd:Service/xrd:URI

xrd:XRD/xrd:Service 要素に対して 0 以上あります。xs:anyURI 型です。この要素または xrd:XRD/xrd:Service/xrd:Redirect または xrd:XRD/xrd:Service/xrd:Ref から選択します。もし存在するならば、親の Service 要素によって記述された可能性にアクセスするためのトランスポートレベルの URI を指し示します。3.1.2 節にある XRI resolution の為に定義されたサービス型は、この URI が HTTP あるいは HTTPS URI でなければならない (MUST)。他のサービスは他のトランスポートプロトコルが用いられる可能性があります。

xrd:XRD/xrd:Service/xrd:Redirect

0 more per xrd:XRD/xrd:Service element. Choice between this or the xrd:XRD/xrd:Service/xrd:URI or xrd:XRD/xrd:Service/xrd:Ref elements. Identical to the xrd:XRD/xrd:Redirect element defined above except processed only in the context of service endpoint selection. See section 12. xrd:XRD/xrd:Service/xrd:Redirect

xrd:XRD/xrd:Service 要素に対して 0 以上あります。この要素または xrd:XRD/xrd:Service/xrd:URI または xrd:XRD/xrd:Service/xrd:Ref から選択します。xrd:XRD/xrd:Redirect とまったく同じです。12 節を見て下さい。

xrd:XRD/xrd:Service/xrd:Ref

0 more per xrd:XRD/xrd:Service element. Choice between this or the xrd:XRD/xrd:Service/xrd:URI or xrd:XRD/xrd:Service/xrd:Redirect elements. Identical to the xrd:XRD/xrd:Ref element defined above except processed only in the context of service endpoint selection. See section 12. xrd:XRD/xrd:Service/xrd:Ref

xrd:XRD/xrd:Service 要素に対して 0 以上あります。この要素または xrd:XRD/xrd:Service/xrd:URI または xrd:XRD/xrd:Service/xrd:Redirect から選択します。service endpoint selection のコンテキストの中だけで処理される事を除いて、xrd:XRD/xrd:Ref とまったく同じです。12 節を見て下さい。

XRDS Document のメモ (3) - 4.2.3 Synonym Elements

In XRDS architecture, an identifier is a synonym of the query identifier (the identifier resolved to obtain the XRDS document) if it is not character-for-character equivalent but identifies the same target resource (the resource to which the identifier was assigned by the identifier authority). The normative rules for synonym usage are specified in section 5. 4.2.3 Synonym Elements

XRDS アーキテクチャの中で identifier は query identifier ( XRDS 文書を取得するために解決された identifier ) のシノニムであり、もしそれが文字と文字の間で同一でなかった場合でも同じ対象リソース (その identifier が identifier authority によって割り当てられたリソース) を指し示しています 。

xrd:XRD/xrd:LocalID

0 or more per xrd:XRD element. Type xs:anyURI. Asserts an interchangeable synonym for the value of the xrd:Query element. See section 5.2.1 for detailed requirements. xrd:XRD/xrd:LocalID

xrd:XRD 要素に対して 0 以上あります。xs:anyURI 型です。xrd:Query 要素の値の為に互換性のあるシノニムを主張 (assert) します。詳細な要求は 5.2.1 節を見て下さい。

xrd:XRD/xrd:EquivID

0 or more per xrd:XRD element. Type xs:anyURI. Asserts an absolute identifier for the target resource that is not equivalent to the CanonicalID or CanonicalEquivID (see below). See section 5.2.2 for detailed requirements. xrd:XRD/xrd:EquivID

xrd:XRD 要素に対して 0 以上あります。xs:anyURI 型です。CanonicalID あるいは CanonicalEquivID (下記参照) と一致しない対象リソースの為の絶対 identifier を主張します。詳細な要求は 5.2.2 節を見て下さい。

xrd:XRD/xrd:CanonicalID

0 or 1 per xrd:XRD element. Type xs:anyURI. Asserts the canonical identifier assigned to the target resource by the authority providing the XRD. See section 5.2.3 for detailed requirements. xrd:XRD/xrd:CanonicalID

xrd:XRD 要素に対して 0 または 1つあります。xs:anyURI 型です。XRD を提供する authority によって対象リソースに対して割り当てられた規範となる identifier を主張します (assert)。詳細な要求は 5.2.3 節を見て下さい。

xrd:XRD/xrd:CanonicalEquivID

0 or 1 per xrd:XRD element. Type xs:anyURI. Asserts the canonical identifier for the target resource assigned by any identifier authority. See section 5.2.4 for detailed requirements. xrd:XRD/xrd:CanonicalEquivID

xrd:XRD 要素に対して 0 または 1つあります。xs:anyURI 型です。任意の identifier authority によって割り当てられた対象リソースの為の規範となる identifier を主張 (assert) します。

XRDS Document のメモ (2) - 4.2.2 Trust Elements

The second set of elements are for applications where trust must be established in the identifier authority providing the XRD. These elements are OPTIONAL for generic authority resolution (section 9), but may be REQUIRED for specific types of trusted authority resolution (section 10) and CanonicalID verification (section 14.3). 4.2.2 Trust Elements

二番目の要素セットは XRD を提供する identifier authority で信頼が確立されていなければならないアプリケーションの為のものです。これらの要素は一般的な authority resolution (9節)に対しては OPTIONAL ですが、信頼された authority resolution (10節) や CanonicalID 検証 (14.3節) に対しては必須 (REQUIRED)となる場合があります。

xrd:XRD/xrd:ProviderID

0 or 1 per xrd:XRD element. A unique identifier of type xs:anyURI for the parent authority providing this XRD. The value of this element MUST be a persistent identifier. There MUST be negligible probability that the value of this element will be assigned as an identifier to any other authority. It is RECOMMENDED to use a fully persistent XRI as defined in [XRISyntax]. If a URN [RFC2141] or other persistent identifer is used, it is RECOMMENDED to express it as an XRI cross-reference as defined in [XRISyntax]. Note that for XRI authority resolution, the authority identified by this element is the parent authority (the provider of the current XRD), not the child authority (the target of the current XRD). The latter is identified by the xrd:XRD/xrd:Service/xrd:ProviderID element inside a authority resolution service endpoint (see below). xrd:XRD/xrd:ProviderID

xrd:XRD 要素に対して 0 または 1つあります。この XRD を提供する親 authority の為の xs:anyURI 型のユニークな識別子です。この要素の値は永続的な識別子でなければなりません (MUST)。この要素の値が如何なるほかの authority に対して identifier として割り当てられるであろうと言う、取るに足らない見込みでなければなりません。[XRISyntax] で定義された完全な永続的な XRI を用いる事が推奨されます (RECOMMENDED)。URN [RFC2141] やあるいは他の永続的な identifier が使われる場合、[XRISyntax] で定義された XRI クロスリファレンスとして表現される事が推奨されます (RECOMMENDED)*1。XRU authority resolution の為に、この要素によって識別される authority は 親 authority (現在の XRD のプロバイダ) であり、子 authority (現在の XRD の対象) ではありません。後者は authority resolution service endpoint の中の xrd:XRD/xrd:Service/xrd:ProviderID 要素によって識別されます。(下記参照)

xrd:XRD/saml:Assertion

0 or 1 per xrd:XRD element. A SAML assertion from the provider of the current XRD that asserts that the information contained in the current XRD is authoritative. Because the assertion is digitally signed and the digital signature encompasses the containing xrd:XRD element, it also provides a mechanism for the recipient to detect unauthorized changes since the last time the XRD was published. Note that while a saml:Issuer element is required within a saml:Assertion element, this specification makes no requirement as to the value of the saml:Issuer element. It is up to the XRI community root authority to place restrictions, if any, on the saml:Issuer element. A suitable approach is to use an XRI in URI-normal form that identifies the community root authority. See section 9.1.3. xrd:XRD/saml:Assertion

xrd:XRD 要素に対して 0 または 1つあります。現在の XRD の中に含まれる情報が信頼できると言う事を assert (主張)する、現在の XRD のプロバイダからの SAML アサーションです。そのアサーションはデジタル署名され、そのデジタル署名はその xrd:XRD 要素を含み、内包しているので、XRD が発行された最終時刻からの未認可な変更を判別する事は受信者に対するメカニズムを提供します。

saml:Issuer 要素が saml:Assertion 要素と共に要求されるが、一方でこの仕様は saml:Issuer 要素の値としてなんら要求をしていません。制約を置く事は XRI community root authority 次第であり、もしあったとしても、saml:Issuer 要素に対してである。適切な対処は community root authority を識別する URI 標準形式の中で XRI を用いる事である。9.1.3 節を見て下さい。

XRDS Document のメモ (1) - 4.2.1 Management Elements

XRI Resolution 2.0 で定義されている XRDS の定義をちゃんとまとめようかなと言う趣旨のメモです。

Spec でいう所の 4.2 付近の話です。相変わらず訳は保障しません。

あと属性の解説は省略しました。*2

前書き

The first set of elements are used to manage XRDs, particularly from the perspective of caching, error handling, and delegation. Note that to prevent processing conflicts, the XRD schema permits a choice of either xrd:XRD/xrd:Redirect elements or xrd:XRD/xrd:Ref elements but not both. 4.2.1 Management Elements

最初の要素セットは XRD を特にキャッシュやエラーハンドリング、委譲 (delegation) を観点とした管理を行うために用いられます。実行時の重複を防ぐために、XRD スキーマは xrd:XRD/xrd:Redirect 要素または xrd:XRD/xrd:Ref

要素のいずれかを選択する事が許されているが、両方を選択する事は許されていない。

xrd:XRD

Container element for all other XRD elements. Attributes: xrd:XRD

他全ての XRD 要素に対するコンテナです。

xrd:XRD/xrd:Type

0 or more per xrd:XRD element. A unique identifier of type xs:anyURI that identifies the type of this XRD. This element is provided to support XRD extensibility as described in section 17.1.1. If no instances of this element are present, the type is as defined by this specification. If one or more instances of this element are present, the requirements of the specified XRD type SHOULD be defined by an extension specification, which SHOULD be dereferenceable from the URI, IRI, or XRI used as the value of this element. In all cases XRD processors MAY ignore instances of this element and process the XRD as specified in this document. xrd:XRD/xrd:Type

xrd:XRD 要素に対して0個以上あります。この XRD の型を識別するユニークな xs:anyURI 型の識別子である。この要素は XRD に 17.1.1 節で記述された拡張性の対応の為に提供されます。もしこの要素のインスタンスが存在しない場合は、その型はこの仕様で定義されたものとなります。1個以上この要素のインスタンスがある場合は、特定の XRD 型の要求は拡張仕様によって定義されるべきであり (SHOULD)、その仕様はこの要素の値として用いられる URI、IRI あるいは XRI からデリファレンス可能であるべきです (SHOULD)。全ての場合において XRD プロセッサはこの要素のインスタンスを無視し、さらにこの文書で定められた XRD として実行する場合があります (MAY)。

xrd:XRD/xrd:Query

0 or 1 per xrd:XRD element. Expresses the XRI, IRI, or URI reference in URI-normal form whose resolution results in this xrd:XRD element. See section 5.1. xrd:XRD/xrd:Query

xrd:XRD 要素に対して 0 または 1つ存在します。レゾリューションがこの xrd:XRD をもたらすURI 標準形式の中で XRI, IRI または URI リファレンスを表明します。5.1 節を見て下さい。

xrd:XRD/xrd:Status

0 or 1 per xrd:XRD element. RECOMMENDED for all XRDs. REQUIRED if the resolver must report certain error conditions. The contents of the element are a human-readable message string describing the status of the response as determined by the resolver. For XRI resolution, values of the Status element are defined in section 15. xrd:XRD/xrd:Status

xrd:XRD 要素に対して 0 または 1つ存在します。全ての XRD に対して推奨されます (RECOMMENDED)。リゾルバは確かなエラー条件を報告しなければならない場合に必須となります (REQUIRED)。要素の内容は人間に解読可能なメッセージ文字としてリゾルバによって決定されたレスポンスのステータスを記述します。XRI resolution の為に、Status 要素の値は 15 節で定義されています。

xrd:XRD:xrd:ServerStatus

0 or 1 per xrd:XRD element. Used by an XRI authority server to report the status of a resolution request to an XRI resolver. See section 15.1. xrd:XRD/xrd:ServerStatus

xrd:XRD 要素に対して 0 または 1つ存在します。XRI リゾルバに対するレゾリューションリクエストのステータスの報告のために XRI authority サーバーによって用いられます。15.1 節を見て下さい。

xrd:XRD/xrd:Expires

0 or 1 per xrd:XRD element. The date/time, in the form of xs:dateTime, after which this XRD cannot be relied upon. To promote interoperability, this date/time value SHOULD use the UTC "Z" time zone and SHOULD NOT use fractional seconds. A resolver MUST NOT use an XRD after the time stated here. A resolver MAY discard this XRD before the time indicated in this result. If the HTTP transport caching semantics specify an expiry time earlier than the time expressed in this attribute, then a resolver MUST NOT use this XRD after the expiry time declared in the HTTP headers per section 13.2 of [RFC2616]. See section 16.2.1. xrd:XRD/xrd:Expires

xrd:XRD 要素に対して 0 または 1つ存在します。その日付/時刻は xs:dateTime 形式で、その日時の後はこの XRD は 信頼する事が出来ません。相互運用性を進めるために、この日付/時刻の値は UTC "Z" タイムゾーンを用いるべき (SHOULD) であり、秒より細かな値を用いるべきではありません (SHOULD)。リゾルバはここで示された時刻を過ぎた XRD を用いてはなりません (MUST)。HTTP トランスポートキャッシュがこの属性で表現された時刻よりも早い有効時刻を指定した場合、リゾルバは [RFC2616] の 13.2 節に対する HTTP ヘッダ中で宣言された有効時刻の後にこの XRD を用いてはなりません (MUST)。

xrd:XRD/xrd:Redirect

0 or more per xrd:XRD element. Type xs:anyURI. MUST contain an absolute HTTP(S) URI. Choice between this or the xrd:XRD/xrd:Ref element below. MUST be processed by a resolver to locate another XRDS document authorized to describe the target resource as defined in section 12. xrd:XRD/xrd:Expires

xrd:XRD 要素に対して 0 以上あります。xs:anyURI 型で、絶対 HTTP(S) URI を含めなければなりません (MUST)。この要素か、あるいは下記の xrd:XRD/xrd:Ref 要素のいずれかを選択して下さい。12節で定義された対象リソースを記述する為に、別の認可された XRDS 文書を指し示すようにリゾルバによって処理されなければなりません (MUST)。

xrd:XRD/xrd:Ref

0 or more more per xrd:XRD element. Type xs:anyURI. MUST contain an absolute XRI. Choice between this or the xrd:XRD/xrd:Redirect element above. MUST be processed by a resolver (depending on the value of the refs subparameter) to locate another XRDS document authorized to describe the target resource as defined in section 12 xrd:XRD/xrd:Expires

xrd:XRD 要素に対して 0 以上あります。xs:anyURI 型です。絶対 XRI を含めなければなりません (MUST)。この要素か上記の xrd:XRD/xrd:Redirect のいずれかを選んで下さい。12節で定義された対象リソースを記述する為に、別の認可された XRDS 文書を指し示すように (refsサブパラメータの値に依存する) リゾルバによって処理されなければなりません )(MUST)。

*1:なるほど、こんな所で使うのか

*2:後で追記するかも

2008-08-14 この欄はある意味 twitter みたいなもんです

XRI Resolution のメモ

まず PHP/Ruby/Python を開発言語としている場合、OpenID Enabled のライブラリを使っておけばほぼ間違いないと言う事を前提に。

@freeXRI で遊ぶ

忘れてたけど @freeXRI で @id*zigorou って Community i-name 取ってたのを思い出したのでふと触ってみた。

さて、早速なので curl コマンドにて、

$ curl "http://xri.net/@id*zigorou?_xrd_r=application/xrds+xml"

とすると次のような XRDS が返って来る。

<?xml version="1.0" encoding="UTF-8"?>
<XRDS ref="xri://@id*zigorou" xmlns="xri://$xrds">
 <XRD version="2.0" xmlns="xri://$xrd*($v*2.0)">
  <Query>*id</Query>
  <Status ceid="off" cid="verified" code="100"/>
  <Expires>2008-08-14T16:51:57.000Z</Expires>
  <ProviderID>xri://@</ProviderID>
  <LocalID>!b1e8.c27b.e41c.25c3</LocalID>
  <CanonicalID>@!B1E8.C27B.E41C.25C3</CanonicalID>
  <Service priority="10">
   <ProviderID>xri://@id</ProviderID>
   <Type select="true">xri://$res*auth*($v*2.0)</Type>
   <Type select="true">xri://$res*auth*($v*2.0)</Type>
   <MediaType select="true">application/xrds+xml</MediaType>
   <URI append="qxri" priority="2">http://resolve.freexri.com/ns/@id/</URI>
   <URI append="qxri" priority="1">https://resolve.freexri.com/ns/@id/</URI>
  </Service>
  <Service priority="10">
   <Type match="default" select="false"/>
   <Path match="default" select="false"/>
   <MediaType match="default" select="false"/>
   <URI append="none" priority="10">http://www.freexri.com</URI>
  </Service>
 </XRD>
 <XRD xmlns="xri://$xrd*($v*2.0)">
  <Query>*zigorou</Query>
  <Status cid="verified" code="241">Requested service endpoint not found</Status>
  <ServerStatus code="100">Success</ServerStatus>
  <Expires>2008-08-14T17:49:42.646Z</Expires>
  <ProviderID>@!B1E8.C27B.E41C.25C3</ProviderID>
  <LocalID>!A79D.5E1A.ED82.AD1F</LocalID>
  <CanonicalID>@!B1E8.C27B.E41C.25C3!A79D.5E1A.ED82.AD1F</CanonicalID>
  <Service>
   <ProviderID>@!7F6F.F50.A4E4.1133</ProviderID>
   <Type select="true">http://openid.net/signon/1.0</Type>
   <Path select="true">(+login)</Path>
   <Path match="default"/>
   <MediaType match="default"/>
   <URI append="none" priority="2">http://authn.freexri.com/authentication/</URI>
   <URI append="none" priority="1">https://authn.freexri.com/authentication/</URI>
  </Service>
  <HostedBy>@freeXRI</HostedBy>
  <ServedBy>OpenXRI</ServedBy>
 </XRD>
</XRDS>

さて、普通に取れたぜって思う次第なんだけど良く見ると、

Requested service endpoint not found

とか言われてる件。なんじゃこりゃ><

幸い @freeXRI には XRI Resolution と言うツールがあるので試して見る事に。

f:id:ZIGOROu:20080815005640j:image

みたいな感じ。良くみたら、"Resolve to" って項目があって、

  • Service Endpoint
  • Authority

ってのがある。Service Endpoint のままで*1実行すると curl の時と同じ結果が返って来るんだけど、こっちを Authority にすると期待通り OpenID に関する Service 要素を含んだ結果が返って来る。

XRI Resolution 2.0 を見る

どうやら 3.3 Media Types for XRI Resolution - XRI Resolution 2.0 にあるパラメータが関係してるらしい。sep=true でリクエストしてるとこうなるっぽぃ。

指定の仕方は 11.4 HXRI Encoding/Decoding Rules - XRI Resolution 2.0 辺りに書いてあって、Proxy Resolver に渡すクエリパラメータの一つである _xrd_r にメディアタイプを指定した後に、セミコロン(;)区切りで指定するようだ。

まぁここまでの話をまとめてさらに XRDS ではなく XRD のみで Authority を取得する場合、

$ curl "http://xri.net/@id*zigorou?_xrd_r=application/xrd+xml;sep=false"

のようにコマンドを打つと。

<?xml version="1.0" encoding="UTF-8"?>
<XRD xmlns="xri://$xrd*($v*2.0)">
 <Query>*zigorou</Query>
 <Status cid="verified" code="100">Success</Status>
 <ServerStatus code="100">Success</ServerStatus>
 <Expires>2008-08-14T18:06:48.939Z</Expires>
 <ProviderID>@!B1E8.C27B.E41C.25C3</ProviderID>
 <LocalID>!A79D.5E1A.ED82.AD1F</LocalID>
 <CanonicalID>@!B1E8.C27B.E41C.25C3!A79D.5E1A.ED82.AD1F</CanonicalID>
 <Service>
  <ProviderID>@!7F6F.F50.A4E4.1133</ProviderID>
  <Type select="true">http://openid.net/signon/1.0</Type>
  <Path select="true">(+login)</Path>
  <Path match="default"/>
  <MediaType match="default"/>
  <URI append="none" priority="2">http://authn.freexri.com/authentication/</URI>
  <URI append="none" priority="1">https://authn.freexri.com/authentication/</URI>
 </Service>
 <HostedBy>@freeXRI</HostedBy>
 <ServedBy>OpenXRI</ServedBy>
</XRD>

めでたく OpenID 用の Service 要素が取れました。この辺りはざっとソース見た感じでは OpenID Enabled のライブラリ*2はどうやら上手く処理出来ている模様です。

Proxy Resolver として使えるところ

などが使えます。他にも使えるところがあると思われる。

まとめ

XRI Resolution 2.0 はまったく読む気力が起きない。


じゃなくて、Proxy Resolver に指定するパラメータには細かな制御が出来たりするよと言うお話でした。

今度ちゃんと調べるので個人的なメモなのです。

んー、前に作った XRI::Resolution::Lite も色々直さないとなー。

*1: Result Type は XRDS or XRD にする

*2:正しくは php 版

2008-07-07

XRI は何故必要なのか?

そういえば最近、赤坂界隈のランチ事情にめっぽう詳しい tkudo さんがお勧めしてたのを思い出して、ざっと意味が通る程度に訳してみる。

英文読解力に難があるので、原文を見ながら各自判断の事w いつもどおり内容に保障はありません。

駄訳

Early Web architecture divided Web addresses (URIs) into two types: URLs (Uniform Resource Locators) and URNs (Uniform Resource Names). The former are “concrete” addresses that identify resources at a specific location on the Internet (and thus can “breakif a resource moves). The latter are “abstract” addresses that persistently identify resources independent of any specific location, domain, or application.

初期のウェブ設計者はウェブのアドレス (URIs) を二つの形式、URLs (Unicofm Resource Locators) と URNs (Uniform Resource Names)、に分けました。その形式はインターネット上の特定の場所にあるリソースを識別する (それゆえにリソースが移動した場合に壊れうる) "完全な" アドレスです。後者は如何なる特定の所在やドメイン、あるいはアプリケーションに依存しないリソースを恒久的に指し示す為の "抽象的な" アドレスです。

However the URN scheme addressed only two requirements that apply to some (but not all) abstract identifiers: persistence (identifiers that never change) and delegation (decentralized identifier management). Over the past decade a much wider set of requirements for abstract, cross-context identification has emerged.

しかしながら URN scheme は幾つかの (しかし全てではない) 抽象的な識別子に対して適用すると言う二つの要求、永続性 (識別子は決して変化しない) のと、委譲 (分散化された識別子の管理)、を規定するだけである。この10年にわたって抽象化に対する要求セットが非常に大きくなり、クロスコンテキストな身分証明が浮かび上がってきた。

They have led to the need for a new identifier scheme that was:

  • Compatible with URI and IRI.
  • Independent of any specific transport or access protocol.
  • Capable of expressing a wide variety of existing (and future) identifiers in a common, interoperable syntax (similar to what XML provides for data.)
  • Capable of expressing structured or “tagged” identifiers that can incorporate metadata useful in identifier parsing, comparison, and resolution.
  • Capable of fully qualifying local identifiers that otherwise may not be globally unique.
  • Capable of reflecting a variety of authority relationships (particularly authority delegated between organizations, hierarchies, and federated systems.)
  • Capable of expressing both human-friendly and machine-friendly identifiers.
  • Resolvable on the Internet.
  • Resolvable using a trustable resolution mechanism.

While other identifier schemes met some of these requirements, none met them all.

それらの事は以下のような新しい識別子のスキーマの必要性に至った、

  • URI と IRI との互換性がある
  • 如何なる特定のトランスポートあるいはアクセスプロトコルに依存しない
  • 標準として存在する (さらに将来そうなる) 識別子の広く多様な表現が可能となる相互運用出来る語彙 ( データに対して XML が提供するものに似ている )
  • 識別子のパース、比較、解決に便利なメタデータを盛り込む事が出来る構造化された、あるいは "タグ付けされた" 識別子を表現する事が出来る
  • オーソリティの関連性 (特にオーソリティが組織間、ヒエラルキ、さらに連携システム間で委譲されている場合) に対する多様性を反映出来る
  • 人にも読みやすく、かつ機械にも読みやすいと言う両方を兼ね備えた識別子を表現出来る
  • インターネット上で解決出来る
  • 信頼できる解決メカニズムを用いて解決出来る

他の識別子はそれらの要求の幾つかを兼ね備えていたが、全てではない。

まとめ

誰か添削してくだしあ。