Issues list (for XRI TC Telecon Friday 2006/2/3 10-11:30AM PT)

["Drummond Reed" <drummond.reed@cordance.net>]

I wanted to get this up on the XRI TC wiki before the call but haven't had
time, so following is list of XRI Resolution 2.0 issues to discuss on
today's call. After the call we'll transcribe this to the wiki.

    Dial In Number: 571-434-5750
    Conference ID: 5474

1) ADDITION OF XRD_NO_REF FLAG AS INPUT PARAMETER

Suggested by Wil and seconded by Steve. Parameter controls whether XRI
client resolver follows Refs. Will explain further on the call.

2) NAMING OF RESOLUTION PARAMETERS

Current list: 

xrd_res_type
xrd_service_type
xrd_media_type

Proposed list:

xrd_auth_media_type
xrd_service_type
xrd_service_media_type
xrd_no_ref


3) NEW PRIMARY ABSOLUTE XRI ELEMENT

Suggested by Steve. The motivation is to enable XRD authors to publish an
absolute XRI (usually a persistent XRI) intended to serve as the "primary
key" for applications such as SSO. Since it may not be a Ref, we can't use a
Ref element for this, and the Synonym element currently does not require an
absolute XRI. 

The proposal is to:

1) Change the definition of Synonym to specify that it is always relative to
the same parent as the current QXRI.

2) Add a new element called Primary that contains an absolute XRI intended
to serve as the primary key for the target Resource. Cardinality would be
identical to Synonym and Ref, i.e., zero to n, because (as Steve and I
discussed at great length yesterday), there are use cases that result in the
need for more than one Primary XRI in the same XRD (and XRD consuming
applications should plan for this.)


4) ADDITION OF IDREF ATTRIBUTE TO XRD ELEMENT

This was discussed on last week's call. It allows the same XRD to be
included in an nested XRDS document without needing a different xml:id
attribute value.


5) RECOMMENDED/REQUIRED VALUE OF XML:ID ATTRIBUTE

On last week's call it was recommended that the xml:id attribute value be a
UUID because that's a legal xml:id value. We need to close on this, as well
as determine what might be necessary to ensure a UUID will work as the
xml:id value (since it must be an NCName).


6) CONSTRUCTION OF URIS WHEN SEP URI INCLUDES A QUERY PARAMETER

Les suggests we just use raw concatenation on all cases.


7) CONSTRUCTION OF URIS FOR OTHER KNOWN SERVICE TYPES

What should be the default if a service type does not have a specified URI
construction algorithm?


8) HTTP X-HEADER INPUT PARAMETERS

Open issue as to whether we still need these.


9) THREE DIGIT ERROR CODES

Gabe suggests we adopt the same overall model as HTTP.