OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Minutes of XRI TC Telecon Friday 2006/2/3


Following are minutes of the XRI TC Telecon Friday 2006/2/3 10-11:30AM PT.

Discussion is marked ***.
Decisions are marked ###.


***** TWO QUESTIONS FROM WIL TAN  ******

A) NEW ERROR CODE FOR TEMPORARY ERROR

Wil suggests we may need a code that allows a server to say "temporary error
- try again later, or try another equivalent authority server."

### Agreed. We also noted that if the server response is an HTTP 404, we
need to specify that the resolver SHOULD try another URI.

B) QXRI IN XRDS @REF ATTRIBUTE

Wil asked if the QXRI in the xrds:XRDS/@ref attribute should be normalized.

### No, it must be an exact copy of the QXRI that was used to request the
XRDS (modulo any portion that is not resolved by the XRDs contained in the
XRDS).


****** OTHER AGENDA ITEMS *********

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, so one resolver code base can serve both
authorities who are willing to follow Refs during lookahead resolution and
those that are not.

### Agreed. See also new resolution parameter naming below.

2) NAMING OF RESOLUTION PARAMETERS

Current list in Working Draft 09: 

xrd_res_type
xrd_service_type
xrd_media_type

Proposed list for Working Draft 10 going into the telecon:

xrd_auth_media_type
xrd_service_type
xrd_service_media_type
xrd_no_ref

*** The primary feedback on the telecon was that the parameter names needed
to be shorter because URL length is an important consideration.

### The decision was to compress them to six characters using the following
formula: "_xrd_x" where the final x is a single letter representing the
resolution parameter. Thus the four proposed parameter names are now:

_xrd_m	service media type
_xrd_a	authority resolution media type
_xrd_n	no follow references flag
_xrd_s	service type

(Notice the mnemonic for remembering these -- "mans").

3) BREAKING SYNONYM ELEMENT INTO ABSOLUTE AND RELATIVE

Steve has pointed out a compelling use case for being able to obtain an
absolute XRI (typically a persistent XRI) to serve as the "primary
key" for XRI applications (such as an SSO service). Even though the Ref
element currently requires an absolute XRI, the reason we can't use the Ref
element for this purpose is that the "primary key" may not in fact be a Ref.

Since the current definition of the Synonym element accepts either a
relative or absolute XRI, the proposal is to split the Synonym element into
two elements, AbsoluteXRI and RelativeXRI. The latter is always relative to
the same parent as the current QXRI; the former is absolute. Cardinality
would remain zero to n.

*** There was not time to discuss this on the call but a proposal will be
sent to the list.


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.

### Agreed that this solves the issue.


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).

### Agreed that UUID should serve this purpose. Gabe also pointed out this
element is only needed for trusted resolution.


***** DUE TO TIME CONSTRAINTS THE FOLLOWING ISSUES WERE NOT DISCUSSED ******

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.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]