XRI 2.0 Resolution Specification Changes

Contents

  1. XRI 2.0 Resolution Specification Changes
    1. Introduction
    2. Document Status
    3. Formatting Note
    4. Working Draft 09 Current Open Issues/Changes
      1. Issue #17: Resolution Flowchart
      2. Issue #18: QXRI Parameters
      3. Issue #19: Type Matching
      4. Issue #20: Control of URI Construction
      5. Issue #21: Changes to $res Namespace (replaces Issue #9)
      6. Issue #22: Rename XSynonym Element
    5. Pre-Working Draft 09 Open Issues/Changes
      1. I1: Priority Attribute in XRIDs
      2. I2: TTL Text
      3. Issue #3: XRI Redirect Handling
      4. Issue #4: Caching of 404s
      5. Issue #5: Normal Form for XRIs in XRIDs
      6. Issue #6: Clarification of MediaType Element
      7. Issue #7: Refactoring for Normative Content
      8. Issue #8: Refactoring for Local and Proxy Resolution
      9. Issue #9: Refactoring $res Namespace
      10. Issue #10: Refactoring XRID Schema
      11. Issue #11: Clarify SAML Assertion Meaning
      12. Issue #12: Future Work
      13. Issue #13: Add HXRI and QXRI
      14. Issue #14: Version Attribute
      15. Issue #15: URI Scheme Attribute
      16. Issue #16: ID Attribute
    6. Closed Issues/Changes
    7. Open Errata
      1. E4: XMLDSIG Prefix (Line 1363)
    8. Closed Errata
      1. E1: Typo (Line 585)
      2. E2: XRI Example (Line 864)
      3. E3: Missing NS ID

1. Introduction

This page tracks issues/changes to the current Working Draft of the XRI 2.0 Resolution Specification that will be incorporate into Committee Draft 02. (See Committee Draft 01 for the previous Committee Draft.)

2. Document Status

3. Formatting Note

Note that the updated naming convention for proposal pages is: Xri2Cd02/ReSolution/Issue[Number]

4. Working Draft 09 Current Open Issues/Changes

This section covers the current issues/changes with Working Draft 09 that will be incorporated into Working Draft 10.

4.1. Issue #17: Resolution Flowchart

The proposal is to simplify XRI resolution logic from that defined in Working Draft 09. The proposed flow is currently defined in the Simplified XRI Resolution Flowchart v01.

What needs to be added to this is:

This flowchart an accompanying text will be added as a new section following the XRDS section.

4.2. Issue #18: QXRI Parameters

The proposal is to enable QXRI authors to pass XRI resolution parameters in the local part of a QXRI. The specific mechanism proposed is:

Example:

4.3. Issue #19: Type Matching

  • Assigned to: Editors
  • Status: Proposal
  • Next due date: 2005/12/06
  • Proposal page:

Type matching is a proposal to consolidate the functionality of the Pattern element and the Type element for the purposes of selecting a service endpoint on the basis of the local part of a QXRI.

The proposal is:

  • Use the entire local part of the QXRI (not including the initial delimiter or the resolution parameters) as the type matching input.
  • Perform the match against the contents of the Type attribute.
  • Support exact, prefix, and suffix matching only in CD02.
  • Indicate prefix or suffix matching by appending or prepending a "*" to the contents of the Type element.

4.4. Issue #20: Control of URI Construction

  • Assigned to: Editors
  • Status: Proposal
  • Next due date: 2005/12/06
  • Proposal page:

The proposal is to enable decoupling URI construction from the Type of a service by specifying the following logic for selection of the URI construction algorithm:

  1. First priority is explicit inclusion of a "pass" parameter in the QXRI. See "QXRI Parameters" below.

  2. Second priority is an explicit xrd:Service/@pass attribute.

  3. Third priority is one of three default algorithms:
    1. For $res*authority service, follow spec-defined algorithm to append one or more of the remaining authority subsegments.
    2. For $res*local service, follow spec-defined algorithm to append the local part of the QXRI.
    3. For a type match against any other service, append the entire QXRI.

The proposed values of the pass parameter are:

4.5. Issue #21: Changes to $res Namespace (replaces Issue #9)

  • Assigned to: Editors
  • Status: Proposal
  • Next due date: 2005/12/06
  • Proposal page:

With the simplified resolution flowchart, following are the proposed Type names for the XRI resolution services defined in the XRI Resolution spec:

  • $res*authority
  • $res*local
  • $res*proxy

Note that $res*proxy is defined only so a community root can advertise one or more specific HTTP proxy servers.

No separate name for trusted authority resolution would be necessary because it would be indicated using a media type of application/xrds-saml+xml.

4.6. Issue #22: Rename XSynonym Element

  • Assigned to: Editors
  • Status: Proposal
  • Next due date: 2005/12/06
  • Proposal page:

The proposal is to rename the XSynonym element specified in Working Draft 09 to a better semantic name. Several choices are:

5. Pre-Working Draft 09 Open Issues/Changes

This section covers the issues/changes identified before the publication of Working Draft 09. Some of these have been superceded by new text in Working Draft 09. Issues that remain current will be pulled forward into each Working Draft as they are posted above.

The NewResolutionRequirements page summarizes some of the new requirements that motivated these issues/changes.

5.1. I1: Priority Attribute in XRIDs

Add a global Priority attribute to XRID elements which may occur more than once to allow authorities to control the priority in which clients process these elements. See http://lists.oasis-open.org/archives/xri/200505/msg00006.html and the proposal page.

5.2. I2: TTL Text

  • Assigned to: DrummondReed

  • Status: In drafting
  • Next due date:
  • Proposal page:

Discussed on XRI Editor's call on 25 May 2005. We need to add text explaining why TTL was not provided as an option for specifying XRID expiration. The reasons:

  • Two options exist already (XRID Expires element and HTTP header), so creating a third option would just be confusing.
  • Determining the effective start time can be ambiguous, and forcing the XRID to include the start time would defeat the purpose of a TTL option (presumably the TTL value could be static.)

5.3. Issue #3: XRI Redirect Handling

  • Assigned to: GabeWachob

  • Status: Needs discussion
  • Next due date:
  • Proposal page:

Discussed on XRI Editor's call on 5/25. The issue is how to represent a chain of XRIDs when an external synonym is followed in the resolution chain. The current proposal is:

  • In authority or local resolution, XRI redirects do not need specialized handling because the client XRI resolver (or its calling application) will make the decision about handing the XRI redirect, i.e., starting over in the XRI resolution chain.
  • In HTTP proxy resolution, the proxy will be making all intermediate decisions about XRI redirects on behalf of the HTTP client (browser). So if an HTTP proxy resolver receives an XRI redirect (an XRID with only one or more external redirect synonyms), the rule would be that the HTTP proxy resolver chooses the highest priority redirect synonym and continues.

5.4. Issue #4: Caching of 404s

In section 2.5.1, specify caching of 404 responses. See the proposal page.

5.5. Issue #5: Normal Form for XRIs in XRIDs

  • Assigned to: DaveMcAlpin

  • Status: Needs closure
  • Next due date:
  • Proposal page:

The issue is captured by the following email dialog between DaveMcAlpin and Wil Tan:

Wil: Should XRIs in the XRID be in IRI- or URI-normal form? This is an interop question, and whatever the answer turns out to be should be reflected in the spec. Syntax says you should use the least encoded form allowed by the context. Consequently, the way the document's written right now they should be in IRI-normal form since anyURI allows an IRI. That's not very convenient for the client, though. It seems like we should specify that they appear in URI-normal form, but if we do that we should also soften the language in Syntax to make it clear that usage is allowed.

Dave: I agree, having it in URI-normal form may be easier for matching by the client.

5.6. Issue #6: Clarification of MediaType Element

  • Assigned to: GabeWachob

  • Status: In drafting
  • Next due date:
  • Proposal page:

In explanation of MediaType element, clarify that the server MAY handle types other than those listed.

5.7. Issue #7: Refactoring for Normative Content

Per input from the public feedback process, refactor the Resolution spec to include only normative text, and move examples and other explanatory material to the non-normative Xri2Primer.

5.8. Issue #8: Refactoring for Local and Proxy Resolution

Proposal to refactor the Resolution spec into four sections: Authority Resolution, Local Resolution, Trusted Resolution, and HTTP proxy resolution. See the proposal page and also this use cases and requirements document.

Further requirements analysis affecting I8, I9, I10, and I13 is at NewResolutionRequirements and suggests this issue may not require all the changes proposed.

5.9. Issue #9: Refactoring $res Namespace

Proposal to refactor the $res namespace to reflect addition of local and proxy resolution service types. See the proposal page and also this use cases and requirements document.

Further requirements analysis affecting I8, I9, I10, and I13 is at NewResolutionRequirements and suggests this issue may not require all the changes proposed.

5.10. Issue #10: Refactoring XRID Schema

Proposal to refactor XRID schema to solve a number of related issues including:

  • Reflecting addition of local and proxy resolution services.
  • Adding a mechanism for bootstraping service trust metadata.
  • Clarifying definition of Synonym elements.

See the proposal page for enumeration of specific issues/changes and also this use cases and requirements document.

Further requirements analysis affecting I8, I9, I10, and I13 is at NewResolutionRequirements and suggests this issue may not require all the changes proposed.

5.11. Issue #11: Clarify SAML Assertion Meaning

We need to clarify that in trusted resolution, the SAML assertion does not mean the signing authority is asserting that all the elements of the XRID (such as external synonyms) are "true" or "verified", simply that "these are the values on record". See the proposal page.

5.12. Issue #12: Future Work

Questions received during the public review process suggest that the Resolution specification should include a "Future Work" section describing how XRIs and XRI resolution might interoperate with endpoint references and other aspects of Web Services architecture. Any other identified tasks for future versions of the specification should also be mentioned here.

5.13. Issue #13: Add HXRI and QXRI

This issue was moved from the Syntax spec. It is a proposal to define the HTTP format of XRIs (and their embedded query XRIs) in ABNF. See the proposal page under Syntax and also this use cases and requirements document.

Further requirements analysis affecting I8, I9, I10, and I13 is at NewResolutionRequirements and suggests this issue may not require all the changes proposed.

5.14. Issue #14: Version Attribute

This issue was raised by Victor Grey in an 16 Sept. email to the XRI list. We need to clarify whether an XRIDescriptors element is versioned or only a contained XRIDescriptor element. See the proposal page.

5.15. Issue #15: URI Scheme Attribute

This issue was raised by Victor Grey in an 16 Sept. email to the XRI list. Victor suggests the addition of a “scheme” attribute to URI elements to simplify and expedite client processing. See the proposal page.

5.16. Issue #16: ID Attribute

This issue was raised by Dave McAlpin in an an email about promotion of xml:id at W3C and also offlist by Victor Grey. It concerns both updating the specification to reflect XML ID specification and clarifying how IDs are to be assigned during lookahead and proxy resolution. See the proposal page.

6. Closed Issues/Changes

None yet.

7. Open Errata

This section contains only minor errata discovered in the public review process.

7.1. E4: XMLDSIG Prefix (Line 1363)

Correct the prefix to the XMLDSIG on line 1363.

8. Closed Errata

8.1. E1: Typo (Line 585)

In the non-normative aside on line 585, “XRI-normal form” should be “URI-normal form”. See http://lists.oasis-open.org/archives/xri/200504/msg00033.html.

8.2. E2: XRI Example (Line 864)

Fix example. See http://lists.oasis-open.org/archives/xri/200503/msg00084.html.

8.3. E3: Missing NS ID

See http://lists.oasis-open.org/archives/xri/200505/msg00005.html.

Added explicit xmlns:xrid declaration in the example of section 2.2.2 - Note that because we have qualified attributes, we are always going to have to declare the namespace qualifier for the XRID namespace, whether or not there is a default namespace in effect that happens to be the XRID namespace.

This wiki is hosted by OASIS and powered by MoinMoin.

Xri2Cd02/ResolutionChanges (last edited 2009-08-12 18:07:20 by localhost)