## Please edit system and help pages ONLY in the moinmaster wiki! For more
## information, please see MoinMaster:MoinPagesEditorGroup.
##master-page:FrontPage
#format wiki
#language en
#pragma section-numbers 2
= XRI Resolution 2.0 Working Draft 11 =
[[TableOfContents]]
== ARCHIVAL NOTE ==
XRI Resolution 2.0 Committee Draft 02 was unanimously approved by the XRI TC on 2007-11-25. This wiki page is now CLOSED and maintained only for archival purposes. A copy was also stored in the XRI TC document repository on 2007-30-2007.
== Introduction ==
This page tracks all proposed revisions/corrections to the current [http://www.oasis-open.org/committees/download.php/17293/xri-resolution-v2.0-wd-10.pdf Working Draft 10] of the XRI 2.0 Resolution Specification that will be incorporated into Working Draft 11. Our goal is for Working Draft 11 to be the final draft before going to Committee Draft 02 status.
== Status ==
In reverse chronological order (prior to the vote on Committee Draft 02):
* [http://www.oasis-open.org/committees/download.php/26114/xri-resolution-v2.0-wd-11-rc1.pdf Release Candidate 01] was posted 2007-11-15.
* [http://www.oasis-open.org/committees/download.php/26041/xri-resolution-v2.0-wd-11-ed-08.pdf Editor’s Draft 08] was posted 2007-11-08.
* [http://www.oasis-open.org/committees/download.php/25938/xri-resolution-v2.0-wd-11-ed-07.pdf Editor’s Draft 07] was posted 2007-11-01.
* [http://www.oasis-open.org/committees/download.php/25741/xri-resolution-v2.0-wd-11-ed-06.pdf Editor’s Draft 06 (ED06)] was posted 2007-10-16.
* [http://www.oasis-open.org/committees/download.php/25307/xri-resolution-v2.0-wd-11-ed-05.pdf Editor’s Draft 05 (ED05)] was posted 2007-09-17.
* [http://www.oasis-open.org/committees/download.php/25204/xri-resolution-v2.0-wd-11-ed-04.pdf Editor’s Draft 04 (ED04)] was posted 2007-09-06.
* [http://www.oasis-open.org/committees/download.php/24734/xri-resolution-v2.0-wd-11-ed-03-clean.pdf Editor’s Draft 03 (ED03)] was posted 2007-07-24.
*[http://www.oasis-open.org/committees/download.php/24286/xri-resolution-v2.0-wd-11-ed-02.doc Editor's Draft 02 (ED02)] was posted 2007-06-06.
* [http://www.oasis-open.org/committees/download.php/24096/xri-resolution-v2.0-wd-11-ed-01.doc Editor's Draft 01 (ED01)] was posted 2007-05-23.
== Open Issues ==
NONE.
----
== Closed Issues Included in ED07 ==
=== ED07 Section 1.6 – Front Matter ===
* Make all revisions as required by OASIS for new spec template format
=== ED07 Section 1.6 – Non-Normative References ===
* Add new references
=== EDO7 Section 2 – Conformance ===
* Add this section as required by OASIS
=== ED07 Appendix A – Acknowledgements ===
* Update this section per current OASIS guidelines
=== ED07 Appendix C – Revision History ===
* Update this section per current OASIS guidelines
=== ED07 Appendix D – XRDS and XRD Schema (XSD) ===
Make revisions to XSD version of XRD schema.
* Make xrd@id attribute optional.
=== ED07 Appendix E - XRDS and XRD Schema (RelaxNG) ===
Generate RelaxNG version of XRD schema.
=== #38 - ED07 Appendix H - Change order of the sepType argument for ops 3, 4, 5. ===
The sepType/sepMediaType arguments are a bit out of place for operations #3, #4, and #5. They should follow the qxri argument. Not only does the order make more sense, in C++ it allows us to use default parameters for all the args following sepType, as desired.
Proposed new order: qxri, sepType, sepMediaType, trustType, followRefs, etc...
''Note: this also needs to be reflected in implementations such as OpenXRI. Also note that trustType is changing per issue #27.''
CLOSURE (2007-04-12 telecon):
Steve and Wil will collaborate on final revised text for Appendix E based on the new parameter list. Also add “cid” and “nodefault”.
=== ED07 Misc ===
* Make sure spec refers to selection elements in the correct order: Type, Path, MediaType.
* Change "comparision" to "comparison".
* Throughout - decide about capitalization of "HTTP" and "HTTPS".
* Clarify that the ref attribute of the XRDS element is the responsibility of the resolver.
* Clarify that for both Refs and CanonicalIDs, resolvers MUST ignore anything but the authority segment, i.e., any local part is ignored.
* Ensure all sections are clear about default now being cid=true.
----
== Closed Issues Included in ED06 ==
=== #19 – ED03 Section 3.3.2 (and others) - Version Number Checking ===
Wil has the action item to confirm that WD10 text adequately addresses what a resolver should do with regard to when it should check an XRD version number and what it should do with it.
=== ED03 Section 3.3 and Others – Boolean Parameters ===
Specify that both "true" (case insensitive) and "1" are valid values for "true" and all other values are false.
=== #51 4.2.1 – Add ServerStatus Element ===
Add new ServerStatus element so a server reports its own status, and then the resolver adds the Status element. In most cases they will agree, but in certain cases they will not. The resolver Status element is NEVER included in the SAML signature because it is always generated by the resolver.
For backwards compatability, resolvers SHOULD create a ServerStatus element if an older server does not supply one. If the server supplied neither a ServerStatus or a Status element, the resolver SHOULD create a blank one.
=== ED03 Section 6.2.2 – Processing Instructions for XRDs when saml=true ===
Add instructions about ServerStatus element.
ACTION: No action taken – it did not affect this section.
=== #53 – ED05 Section 8 – Add Failover Section ===
Per the minutes of the 2007-0913 telecon.
=== #44 – ED03 Section 8.2.7 – Path Matching using Caseless Matching ===
ISSUE: An XRI path component is case-sensitive but XRI resolution service endpoint path matching algorithm currently uses caseless matching, which is inconsistent with the proposed rules for XRI syntax.
CLOSURE: We will keep path matching case insensitive.
=== #33 – ED03 Section 10.7 – Note About Usage of append= Attribute ===
ACTION: Include note in this section that uric=true can be used by consuming applications if they want append= processing to happen automatically.
BACKGROUND:
SEP URI elements that use the {{{append}}} attribute force XRDS-consuming applications to parse HXRIs. A service provider who wants to avoid pushing that requirement onto applications SHOULD build the necessary metadata into the SEP URI and avoid the use of the append attribute.
GabeWachob summarized it this way:
{{{I like the concept of ‘name-dependent’ service instances and ‘name-independent’ service instances.. Some services are inherently name-independent (e.g. openid auth) since the URI never needs to know about the xri (or http uri) associated with a given resolution result. Other services (e.g. forwarding service) can be deployed in a name-dependent or name-independent manners (e.g. whether or not the append attribute is present). Note that some services may actually be deployed in a way which asks for the some part of the QXRI to be appended, but only in an advisory or hint-like fashion (for example, a contact service may use this for the purpose of displaying the QXRI to the user).
Now, the contact service seems to be a third category (inherently independent, possibly independent) and now “inherently dependent” – the contact service at the very least will display a different iname on the HTML page to the contacting party based on how the contacting party got to that contact service. I’m not sure how the contact service could be designed otherwise…
So we really do have three types – inherently name-independent (e.g. openid), inherently dependent (e.g. contact service), and ones that can be deployed either way (e.g. forwarding service). Name dependent services basically have to be defined specifically to work with XRIs (at least the XRI part being added to the service URI is visible to the service). Name independent services have no such requirement (since there isn’t necessarily anything xri being added to the service URI).
I’d suggest that we put in text strongly pushing people to define name-independent services where possible, and to avoid deploying services in a name-dependent manner when it is possible to deploy them (ie describe them in service blocks) in a name-independent way.
I think this works with the “xri-ignorant web” consumers of XRDs because if they are ignorant of XRI, they probably can’t use a service that requires adding in parts of an XRI to the service URI (though I would have to think that through).}}}
Steve suggests that the spec also mention that even name-independent SEP URIs can optionally be name-sensitive. However if a SEP URI is not designed to be name-independent, then the service will break if the consuming application: a) does not understand append attribute processing, or b) the application is dependent on a name derived from an XRI and the identifier used to obtain the XRDS document is not an XRI.
=== #34 – ED03 Section 10.7 – Add uric=true Parameter ===
In the past Gabe and Steve suggested we add this parameter to instruct a resolver to perform URI construction when returning an XRD (and remove the append attribute from each SEP URI). This is exactly the same processing that would be performed for a return type of text/uri-list.
ACTION: Add uric parameter.
=== #54 - ED06 Section 12 - Redirect & Ref Processing ===
ACTION: Update per the final proposal on XriCd02/RefProcessing.
----
== Closed Issues Included in ED05 ==
=== #52 - ED03 Section 13 – Making Resolution Default cid=true ===
At the [http://datasharingsummit.com Data Sharing Summit], Victor Grey and Kermit Snelson made the suggestion that the default setting for the {{{cid}}} parameter (CanonicalID verification) should be {{{cid=true}}}, just as it is with the {{{refs}}} parameter. In this case, resolution requests that do NOT want cid verification MUST explicitly set the parameter to {{{cid=false}}}. There was consensus among the TC members present that this was a good policy; we just need to confirm this with the larger group.
CLOSURE: On the 2007-09-13 telecon, it was concluded we should do this IF it does not break too much backward compatability, i.e., if existing OpenID libraries do not key on the Status code. Subsequent research by Kermit Snelson indicated this was indeed the case. So we are making this change.
=== #47 – ED04 Sections 5 and 13 – Synonyms and Verification ===
We have consensus to remove section 5.1 as it contains non-normative text. We will move it to an informative document.
The remaining issues are:
# Should we use the synonym precedent order documented in section 5.3 ED04?
# Is another synonym element needed exclusively for the purpose of providing the verification backpointer for CanonicalEquivID, or is EquivID sufficient (as specified in ED04).
CLOSURE: #1) Yes, remove section 5.3 in favor of just clearly specifying the semantics of each synonym element and letting consuming applications apply their own policy for synonym selection. #2) No, do not add another synonym element, as no use case has been shown for not using EquivID.
=== #48 – ED04 Sections 13 – CID Status Codes ===
This ties into issue #47 above. We need final signoff on these error codes. See section 13.3 of ED04.
CLOSURE: The status codes are okay but the text recommending specific identifiers should be removed in favor of just specifying for each status code which identifiers are verified.
ACTION: The status codes were revised slightly to reflect a more logical order and the table was rewritten.
----
== Closed Issues Included in ED04 ==
=== ED03 Section 3.3 – Nodefault Parameter ===
'''TODO: DRUMMOND'''
Change nodefault to nodefault_t, nodefault_p, nodefault_r
----
== Closed Issues Included in ED03 ==
=== #1 – Section 4.1.3 - Add Explanation of Default Service Type ===
'''Added to 3.2.7, xrd:XRD/xrd:Service/xrd:Type definition.'''
Per Gabe's suggestion, specify that if no service type is defined for a service endpoint, the service is defined by the type of URI specified in the URI element, i.e., http service by http URIs.
=== #2 - Section 4.1 - Specify Percent Encoding for Resolution Parameters ===
'''Added new text in sections 5.1.1 and 8.3.'''
This issue is in reference to the email thread at...
http://lists.oasis-open.org/archives/xri/200607/msg00001.html
...regarding escaping of characters in XRI resolution query parameters.
Conclusions:
* We MUST NOT not do any escaping to query parameters that belong to the XRI being resolved (vs. query parameters named "_xrd_*" that are added only for XRI resolution). These non-XRI resolution query parameters MUST be passed straight through. We MUST only apply escaping rules to XRI resolution query parameters.
* We MUST specify that both + and %2B MUST be interpreted the same way by an XRI proxy resolver. Therefore spaces should not be encoded as + signs.
* We need to add a section to Working Draft 11 that deals with encoding rules for XRIs and in particular query segments when being passed to XRI local and proxy resolvers.
See also Wil Tan's separate summary posted at:
http://lists.oasis-open.org/archives/xri/200607/msg00005.html
=== #4 - Section 4.2.1.5 AND Appendix E.3 – XRDS Documents are Unfiltered ===
'''Added next text in sections 5.2.1 and Appendix E part 3.'''
Steve suggests these sections need to explicitly point out that a resolution request for a result of type application/xrds+xml will always be returned an "unfiltered" XRDS document, i.e., will all SEPs, regardless of the value of the "sep" parameter.
=== #6 - Sections 4.1.1 and 8.4 – QXRI Canonicalization and "xri://" Prefix ===
'''Added clarifying text in 8.2.'''
When constructing a service endpoint URI, we need to clarify if the QXRI should be normalized or not.
(Note: issue #15 has been folded into this issue. It's original text was: "The text is section 4.1.1 (referencing section 2.3.1 of XRI Syntax for conversion to URI normal form) should specify the "xri://" prefix for a QXRI is OPTIONAL.")
DISCUSSION – 2006-08-21 TELECON
It was suggested that we apply Postel's law: client should canonicalize, so resolver (whether local or proxy) should simply pass the QXRI as given.
There was consensus that a resolver MUST be able to deal with all three forms of XRI. However the issue of a canonical form is still an open issue, and must be addressed in XRI Syntax 2.01.
CLOSURE
Specify in WD11 that the canonical form of a QXRI is WITHOUT the "xri://" prefix. If a resolver receives a QXRI with the "xri://" prefix, it SHOULD remove it before passing it on.
=== #7 - Section 10 – Clarify Ref Processing ===
'''Added necessary text to 11.1.1 and 11.1.2.'''
* Clarify that a Ref value is only needed for a nested XRDS document, and that it should always contain exactly the XRI described by the contained XRD elements.
* Clarify that if Ref processing fails, the resolver's job is done and it should return an error.
* Clarify the wording that a resolver first needs to process the entire Ref, and then, if you’re composing an XRDS document, you nest it. Otherwise, if you are only returning an XRD or URI list, you just take the final XRD or URI list.
=== #9 - Section 11.4 – Specify Usage of LocalID and CanonicalID for Caching ===
'''Added section 14.4.2.'''
Add guidance about how resolvers can use cached LocalIDs and CanonicalIDs.
CLOSURE
* A resolution request for a cached LocalID from the correct ProviderID can return the cached XRD if it is within the cache duration.
* A resolution request for a CanonicalID for which the resolution return type is '''application/xrd+xml''' can return the cached XRD if it is within the cache duration AND if the CanonicalID is verified with cid=true.
Steve suggests we characterize this as "multiple indexes into the same XRD".
=== #12 - Section 5.1 – Authority Resolution Ignores Default SEPs ===
'''Added text in 6.1.2 bullet 5 and also 6.1.7.'''
(Note: this is related to issue #5.)
Per a message from Wil Tan to the XRI List on 2006/8/10, we should clarify that in the XRI authority resolution process, a resolver MUST ignore default service selection, i.e., it can't choose a SEP that is not of type xri://\$res*auth*(\$v*2.0).
=== #13 - Section 8.2.1 – Clarifying Definition of Null and Empty ===
'''For first para of CLOSURE, added new rules to end of text in section 5.1. For second second para of CLOSURE, see section 9.3.4 of the rewritten Service Endpoint Selection section.'''
Wil brought up the issue that WD10 is not necessarily clear or uniform about the relationship of empty element or parameters and null (missing) values. These conditions appear both in XRI resolution parameters and in XRDS elements.
From an email from Wil regarding section 8.2.1 point #2 of WD10 resolution spec:
***EXCERPT***
''If an xrd:Type, xrd:MediaType, or xrd:Path element is present but its contents are empty, the value of the element MUST be considered null.''
What is the significance of this statement?
This also brings up issues that I always had while reading the spec, i.e. what is the definition of "null" in the document? For example, the table in 8.2.1 under the Matching Rule for "content": "the xrd:match attribute is present but the attribute is omitted or its value is null." To me, this looks like you mean either of:
photos
photos
But match="" is not a valid enumerated value in the schema, so it should not even be considered.
It seems to me that an empty string ("") and null should be considered equivalent with respect to service selection. If that is the case, we probably should specify it in the doc.
***END EXCERPT***
DISCUSSION ON 2006-8-17 TELECON
Steve proposed that:
* We do not distinguish between the empty value and null.
* If an attribute or element is not present, the value is considered null.
* If the attribute or element is present but the value is the empty string, it is considered null.
Marty added that we should clarify that if an attribute or element is required, it is not satisfied by being null by the above rules.
Wil pointed out that to avoid confusion we should also clarify that the value "null" for the match attribute is an explicit value.
We should also be careful to distinguish between empty and null with regard to XML elements vs. query parameters.
CONCLUSION #1
There was concensus that for XRI resolution query parameters, we do NOT distinguish between a parameter having an empty value and null (null being the absence of a parameter). They are equivalent.
REMAINING OPEN ISSUE
What is still open is whether the same rule should apply to XML elements in an XRD, i.e., should an element with an empty value (and no attributes) be equivalent to the element being absent altogether?
Wil and Steve pointed out that this is not consistent with our rules for the match attribute, which is assumed to have one value (match="default") if an element is missing altogether, and another value (match="contents") if the element is present.
(Note: we subsequently solved this problem by eliminating "contents" as a value of the match attribute.)
CLOSURE
In WD11, make it consistent that throughout all aspects of XRI resolution, the presence of an XRD element or QXRI parameter with an empty value is treated as equivalent to the absence of that element or parameter, and from a programmatic standpoint, both conditions are considered as equivalent to setting the value of that element or parameter to null.
In addition, if an XRD element is present BUT: a) its value is empty, and b) it has no known XRD attributes, then it is treated as equivalent to the element being absent, i.e., it's value is considered to be null (and thus the value of the match attribute is assumed to be match="default").
=== #17 - Section 8.2.2 and 8.2.4 – Use of URI Normal Form ===
'''Added text in 9.3.6 and 9.3.7.'''
Wil has suggested we add a mention of section 3.4 (using URI normal form) in the sections on type matching (8.2.2 and 8.2.4).
=== #18 – Section 7 - Returning Community Root Authority XRD ===
'''Added section 6.1.4 on Self-Describing XRDS Documents. Also added references to this section in 6.1.2 list item 1.'''
Should an XRI resolution response from a resolver always include an XRD describing the root authority the resolver?
BACKGROUND EMAIL THREAD
http://lists.oasis-open.org/archives/xri/200608/msg00002.html
DISCUSSION ON 2006-8-17 TELECON
* There is a need to be able to get the XRD for a root authority.
* It is inefficient to have it returned in every reponse from a local or proxy resolver.
* But it should not require special behaviour to serve as a root – all all authorities should be able to be self-describing.
CLOSURE (2006-8-17 TELECON)
* Specify that when an XRI authority is asked for anything EXCEPT it’s own self-describing XRD, the authority MUST NOT include a self-describing XRD in the response. (This is consistent with WD10 and current practice.)
* Specify that any XRI authority that wants to function as a root authority SHOULD publish its own self-describing XRD.
* Specify that to request a self-describing XRD for an XRI authority, a resolver can ask for it by: a) querying the authority directly at its well-known http or https address with a null query string, or b) querying a proxy resolver (or any other XRI authority) for the well-known name of the root authority (i.e., either a GCS character or a cross-reference).
=== #23 - Section 8.2.2 and 8.2.4 – Trailing Forward Slash Normalization ===
'''Added to list item 1 in section 9.3.6 and added list item 2 in section 9.3.7.'''
Wil suggests we clearly specify that:
1. A trailing forward slash / is assumed after an XRI authority segment (the same as in RFC 3986).
1. A trailing forward slash is NOT assumed after a path segment, and is therefore significant when comparing path values.
However the current WD10 rules normalize out / as a trailing delimiter.
Which option do we want to take?
Drummond notes that if a SEP author wants a trailing slash to be insignificant they could include two Path elements, one with and one without the trailing value. But this seems like a lot of work to deal with a common ambiguity.
CLOSURE
Specify in WD11 that:
1. A trailing forward slash / is assumed after an XRI authority segment (the same as in RFC 3986).
1. A trailing forward slash is NOT assumed after a path segment, and is therefore significant when comparing path values. (This means NOT normalizing out / as a trailing delimiter.)
=== #24 - Section 7.2 – Simplifying HXRI Proxy Domain Algorithm ===
'''No action necessary.'''
The proposal is to simplify the algorithm to two conditions:
* http://xri.net or https://xri.net OR
* Any third- or lower-level domain that begins with "xri.*"
After some discussion, it was agreed to maintain the separation of operational aspects, so no change will be made to the current text (other than pure editorial improvements).
=== #26 – Section 3.2.5 -- Clarifying Scope of Provider ID in a SEP ===
'''Added verbiage to 3.2.6., xrd:XRD/xrd:Service/xrd:ProviderID definition.'''
Questions from Johannes Ernst on the Yadis list resulted in the suggestion that we clarify the scope of a ProviderID value in a SEP.
CLOSURE (2006-08-28)
In WD11, specify that the XRI Resolution 2.0 spec does NOT define the purpose of ProviderID for SEPs other than the SEP Types it defines (authority and proxy resolution). Instead it should say that the author of the specification for the service that uses this SEP SHOULD define the use/scope of ProviderID, particularly in trust usage.
=== #29 - Section 11.2.3 – Clarify "trust" parameter in Content-type ===
'''Added list item 8 in 6.1.2.'''
Wil suggests that we clarify if proxy or authority resolution server SHOULD/MUST return the "trust" media type parameter in HTTP response. Also clarify how should a client deal with the presence/absense of the parameter (should validate against the input trust type).
CLOSURE
WD11 will say that a server MUST return the content type and SHOULD NOT return the parameters, and client MUST ignore the parameters if they are present.
=== #30 - Section 2.3 – Should Application/xrd+xml Return SAML data? ===
'''Added text at end of list item 6 in 5.2.2.'''
Wil asks: the application/xrd+xml media type is meant to be filtered, which means that any SAML signature in there will probably fail verification. If so, should we specify that trust =~ /.*saml.*/ is not allowed? Section 4.2.2 #5 says that xrd+xml should only be filtered when sep=true, and that only Services are filtered and prioritizable elements are sorted. What about extensions and SAML signature?
CLOSURE
Clarify that the ONLY thing removed is SEPs that are not-selected; everything else is returned.
=== #31 - Section 1 (and others) – Best Practices for XRI Proxy Resolver Deployment? ===
'''Added new section 9.8.'''
Real-world deployment experience is teaching us that XRI proxy resolvers are very frequently the easiest option for developers, and are likely to produce the best performance from a caching perspective. The issue is how much text we should include, and with what best practices or recommendations, about XRI proxy resolver deployment?
CLOSURE
We should not tackle this subject in any depth in the spec, but we should point out that the tradeoff between deployment of proxy vs. local resolvers is one that should be taken into account when deploying XRI infrastructure.
=== #39 - Section 9 et al – Behaviour if a Ref Value is an HTTP(S) URI ===
'''Added steps 4 and 5 to 11.1.1.'''
Discussion on the 2006-12-07 XRI TC call brought up the possibility that the value of a Ref element is an http(s) URI. What should the behavior of a resolver be in this case? How does this affect CanonicalID validation? Trusted resolution?
ORIGINAL CLOSURE (2007-04-12 telecon):
Spec will say that authority ref containing anything but an XRI will be skipped in reference processing. We also agreed that the general rule should be that an XRI resolver should not error out when encountering an XRDS element that contains a URI or IRI when the XRI resolver expects an XRI, but should ignore that element, proceeding as it it were not present.
NEW CLOSURE: This changed after we added Section 4 (the Yadis section), so now there is a clear way to resolve HTTP(S) URIs in Refs. This was updated in section 11.1.1 as noted above.
=== #43 - Section 7.4 - Simplify Processing of Multiple Accept Headers ===
'''NO CHANGE.'''
Section 7.4 #1 says "A proxy resolver client SHOULD order media type identifiers according to the client’s preference and a proxy resolver SHOULD choose the first one it supports."
When used in HXRI, browsers could send fairly complicated Accept headers. For example, Firefox 2 sends the following:
{{{
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
}}}
Proxy shouldn't have to order the Accept header values according to "q" weightage.
According to section 7.4, if _xrd_m is not specified in the HXRI, it takes on the value of "text/xml". This is almost always not the intention of the user, who has no control over what is sent by the browser.
CLOSURE: Related to #41, the current rule that "proxy resolver SHOULD order the Accept header values according to weightage" stays.
=== #28 – Section 3.2.2 and Section 9 - Update Definition of Ref Element ===
'''Updated section 11.4 (Ref) in new Synonym section.'''
This definition needs to be updated to reflect the outcome of discussion about issue #10 and also explain the "union" semantics. Section 9 may also need to explain the graph model and explain how Refs represent polyarchical paths.
CLOSURE
Revise WD11 to explain the "union" semantics with a simple diagram that explains the essence of polyarchical paths without going deep into graph theory. The actual wording and diagram is TBD in the draft.
=== #45 - Section 11 - Add Formal Graph Model ===
'''Added section 11.1.'''
Add formal graph model to Canonical ID Verification section, per Steve's proposal to the list.
=== #46 Section 11 – Canonical ID Verification ===
'''Added necessary text to sections 11 and 12.'''
Comments/issues in this section:
* Add text describing importance of trusted resolution.
* Add examples – here or in appendix.
Action items from minutes of 2007-06-21 telecon:
* Add extended Canonical ID verification from XriCd02/CanonicalIdVerification.
* Add an explicit warning that Refs MUST be used only to represent synonyms for the resolved identifier assigned by an authority other than the authority producing the current XRD, and MUST NOT be used to express any other form of relationship between the authorities.
* Add warnings that:
1. As with DNS or any other registry-based identifier infrastructure, Canonical ID verification depends on trusting each authority in the resolution chain.
1. Any Canonical ID assigned by an XRI registry under its own authority SHOULD not be editable by a registrant.
1. Trusting a Canonical ID without verification can enable spoofing of Canonical IDs.
=== #49 - ED03 Section 3.3 – Media Type Parameters ===
Do we really get to define new media type parameters for text/uri-list?
CLOSURE (from 2007-10-04 telecon): The text/uri-list media type is rare enough that this should not cause problems.
=== #50 ED03 Section 5.3 – HTML version for Yadis Section ===
Is it necessary to specify what version of HTML can be used? If so, which version?
CLOSURE: No, it is not necessary to specify this.
== Closed Issues Included in ED01 (Editor’s Draft 01) or ED02 ==
=== #3 – New Section – Add Yadis Support ===
'''See ED01 Section 8.'''
From the minutes of the 2006/7/13 telecon (http://lists.oasis-open.org/archives/xri/200607/msg00009.html)
We discussed with our guests from the Yadis community (www.yadis.org) the proposed plan for incorporating the Yadis 1.0 spec into XRI Resolution 2.0 Working Draft 11. Because substantial portions of the Yadis spec reflect material that is already in the XRI Resolution spec, it was agreed that is the portion from section 6.2.3 to the end of section 6 that needs to be incorporated. It was agreed that the XRI Resolution Editors will do the first cut of this, then ask the Yadis community to review it.
=== #5 - Section 8.2.1, Table 20 – Revise Default Value for Append Attribute ===
'''See ED01 Section 9.7 Line 1511.'''
The proposal is to make the default "none" as this is more intuitive than the current default "local", in particular because local is no more common than any other value.
In addition, Wil proposes the following text: "URIs within a Service element that is meant to be used for authority resolution SHOULD NOT have the append attribute. If an append attribute is present, its value MUST be ignored by the client for the purpose of XRI resolution as defined in this specification."
=== #8 - Section 10.1, Table 22 – Add Error Code 224 INACTIVE ===
'''See ED01 Section 12.1 Line 1826.'''
This status code pertains to persistent XRIs. It means the authority assigned the XRI but no longer provides resolution metadata. The client should ignore anything that might be present in the XRD other than signature metadata.
=== #10 – New Section - CanonicalID Verification ===
'''See ED01 Section 11.'''
Add a new section specifying CanonicalID verification using a new parameter, cid="true".
See XriCd02/CanonicalIdVerification for the complete proposal.
=== #11 - Section 3.2.3 - Backref Element ===
'''See ED01 Section 3.2.3 Line 384; also Section 10.1.'''
The addition of support in WD11 for obtaining XRDS documents from URLs means that XRI authorities now need the ability to be able to make the following assertion in an XRDS document: "This identifier issued by another authority identifies the same target resource, but it refers back to me as the authoritative source of the XRDS."
In other words, this the exact opposite of the function of the Ref element, which allows an XRI authority to say, "This identifier issued by another authority identifies the same target resource, and you can go resolve it to get another authoritative XRDS."
DISCUSSION ON 2006-08-21 TELECON
We talked about this briefly and there was initial loose consensus that this element represented a different type of synonym than LocalID, CanonicalID, or Ref.
CLOSURE
In WD11, define a new XRD synonym element called Backref with the same datatype as a Ref element except there is no Backref processing defined. Verification of Backrefs is out-of-scope for WD11 but can easily be performed by consuming applications.
Note: still to determine capitalization, i.e., "Backref" or "BackRef". Drummond to check XRD schema section.
Note (2006-10-20): To enable easy verification of Backrefs, the Yadis section (issue #3) should specify the HTML link element value that can be inserted into an HTML page header to associate it with the XRDS document.
=== #14 - Section 8.4 – Append CID ===
'''NO CHANGE IN WD11.'''
It has been suggested that we consider adding two additional values of the append attribute of the URI element:
* append="cid" when the service provider wants the highest priority CanonicalID.
* append="cid+qxri" when the service provider wants the both the highest priority CanonicalID and QXRI.
On the 2006—10-12 TC telecon it was concluded that it was much better to encourage service providers to either bind the CanonicalID into the SEP URI value, or to make it available via a LocalID element within the SEP.
It also broke the rule we are currently following that "append" only appends values from the original QXRI.
CLOSURE
No change will be made in WD11.
=== #15 - Section 4.1.1 – "xri://" Prefix Optional ===
'''NO CHANGE IN WD11.'''
This issue was folded into #6 – CLOSED.
=== #16 - Section 8.2.4 – Revise Path Matching Rules ===
'''See ED01 Section 9.3.8, Line 1385.'''
Wil has proposed that item #3 of this section be struck, so that path matching only uses the exact string after normalization. If so we should add text recommending that proxy resolvers "autocorrect" by issuing redirects for XRIs that are not syntactically correct (e.g., that use +words without cross-reference syntax).
CLOSED – there is consensus that exact matching be used in WD11. The remaining open issue is #44, Caseless Matching.
=== #20 – Section 4.2 - Text/Plain Media Type ===
'''NO CHANGE IN WD11.'''
It was proposed that we include a text/plain media type that is equivalent to the application/XRDS+xml media type but returns it as text/plain for purposes of XRDS display and debugging.
It turns out this was primarily to address a bug in IE6 that has other workarounds, and is not in scope for XRI Resolution. CLOSED.
=== #21 - Section 8.2 – Documenting/Simplifying SEP Selection Logic ===
'''See ED01 Section 9 (completely rewritten).'''
The SEP selection process in section 8.2 of WD10 needs greater clarification.
CLOSURE
This issue was closed by producing a simple logical explanation along with detailed pseudocode. See XriCd02/SepSelection.
=== #22 - Section 8.2.1 – Drop match="none" Value ===
'''See ED01 Section 9.3.2, Line 1341.'''
Per Wil's explanation that this makes SEP selection process harder to code.
=== #25 - Section 7.2 – Move HXRI Definition to XRI Syntax 2.01 ===
'''OUT OF SCOPE FOR WD11.'''
We will make HXRI definition a part of XRI Syntax 3.0.
=== #27 – Section 2.3 et al – Revise trust= Parameters ===
'''See ED01 Section 2.3, Line 220.'''
The issue is potential combinatorial explosion of trust= parameters if the continue to be defined by adding current parameter values, e.g., trust=https+saml.
''(This issue is related to #10.)''
CLOSURE
Change to individual Boolean parameters that are each listed to request a specific trust type. These would become:
* https=true (or false)
* saml=true (or false)
So the combination of saml and https for trusted res of an XRDS would be:
{{{
application/xrds+xml;https=true;saml=true
}}}
With this approach, the proposed cid=true parameter can also be added, i.e.:
{{{
application/xrds+xml;https=true;saml=true;cid=true
}}}
The default value of all of these attributes is "false".
BACKWARDS COMPATABILITY: We will add a note in the spec explaining that a previous Working Draft used a different parameter name. That name is now deprecated, but existing code bases are encouraged to support it for a reasonable period of time.
=== #32 - Section 8.2 – Drop match="contents" ===
'''See ED01 Section 9.3.2, Line 1341.'''
In SEP selection, this value of the match attribute is not needed.
CLOSURE
In WD11, specify that any non-empty value of a SEP selection element (Type, MediaType, Path) automatically means match="contents", and conversely, if the match attribute is present, the contents MUST be ignored. Per issue #13, if the SEP selection element value is empty, it is treated as match="default". This reduces the values of the match attribute to just four:
* default
* null
* non-null
* any
IMPORTANT: Add a note about backwards-compatability with former attribute value, although "contents" as a value is deprecated. Note that due to a previous ambiguity about how "contents" was interpreted, complete backwards-compatability is not possible.
=== #35 - Section 3.3.3 – Clarification of Value of Priority Attribute ===
'''See ED01 Section 3.3.3, Line 497.'''
Per an XRI TC discussion on the 2006-09-07 TC call, in WD 11 we need to make it clear that a null value of the priority element = infinity (i.e., lowest possible priority). We should recommend that using the recommended default value of "10" (or a higher value indicating a lower priority) is better than a null value. We should also note the difference with DNS, where priority is an integer field and therefore the default must be an integer.
=== #36 - Section 3.2.5 – Add LocalID Element at SEP Level ===
'''See ED01 Section 3.3.5, Line 415.'''
The proposal is to: a) update the definition of LocalID element to be: "an absolute or relative XRI, IRI, or URI that identifies the target resource in the context of the ProviderID", and b) add the option of including zero or more LocalID elements at the SEP level just like we have ProviderID both at the XRD level and the SEP level. This would enable service providers to assert a LocalID in their own context – metadata that is useful in certain service protocols such as [http://openid.net OpenID].
CLOSURE (2006-10-12 TC telecon)
There is consensus to add this to WD11.
=== #37 - Section 7.6 et al – Service Refs ===
'''See ED01 Section 3.3.5, Line 420; also Section 10.3.'''
Discussion on the OpenID mailing list revealed a limitation in XRI resolution for resolving XRIs that include a local part. As defined in Working Draft 10, XRI resolution can only return XRDS documents describing XRI authorities (i.e., that describe resources whose XRI consists only of an authority segment). XRI resolution cannot return an XRDS describing a local resource because if an XRI has a local part, it is always treated as input to the SEP selection process.
The only workaround when an XRI has a local part is to formulate a different XRI resolution request that asks an XRI resolver to return a redirect to the URI for an XRDS document describing a local resource.
The OpenID list members pointed out should not be the case – you should just be able to hand the resolver the XRI you want resolved (with or without a local part) and tell it requested return type and "let it figure it out". Our challenge is to "make it so".
CLOSURE:
See the final proposal page at XriCd02/ServiceRefs.
=== #40 - Section 7.3 et al – New "nodefault" Subparameter for Resolution Media Type Parameter (xrd_r) ===
'''See ED01 Section 2.3, Line 220; also Section 3.3.2, Line 1340.'''
Developers have occasionally experienced unexpected behaviour when, due to the SEP matching logic options in XRDS documents, a SEP match results in selection of a SEP that is not in fact the desired SEP type.
CLOSURE: The decision was to add a new '''nodefault''' subparameter to the Resolution Media Type (_xrd_r) parameter. The values of this parameter would be:
* type
* mediatype
* path
If this parameter is present, it overrides a default match for the specified parameter type, i.e., a default match would instead be processed as a negative match.
=== #41 - Section 7.4 – Processing Rules for HTTP Accept Headers ===
'''See ED01 Section 7.4, Line 1193.'''
The Accept header taking on double meaning depending on its value (either as _xrd_r or _xrd_m) is confusing.
PROPOSAL: For proxy resolution, the Accept header should correspond to the _xrd_m parameter only. If _xrd_m is present, Accept header value should be ignored.
CLOSURE: Drummond to rewrite section 7.4 which should be greatly simplified.
=== #42 - Section TBD – Make id Attribute Optional ===
'''See new text in section 3.3.1.'''
Per http://lists.oasis-open.org/archives/xri/200701/msg00022.html, the consensus is to make the XRD id attribute optional, as it is only required in SAML trusted resolution.
## Mandatory OASIS footer, do not move or remove:
This wiki is hosted by [http://www.oasis-open.org/ OASIS] and powered by MoinMoin.
## end of mandatory text
4/21/2004 Page 22