[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]