[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Proposal for _xrd_r parameter and return format
If the _xrd_r parameter is optional, I propose to add a separate error code for rejecting the request 212 NOT_SUPPORTED. When these types of error occurs (where the query failed to resolve), should the XRD element have the entire QXRI in the <Query> content or just the first subsegment of the QXRI? =wil (http://xri.net/=wil) > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Saturday, February 25, 2006 4:01 PM > To: Chasen, Les; xri@lists.oasis-open.org > Subject: RE: [xri] Proposal for _xrd_r parameter and return format > > Returning a "mini" or "stripped down" XRDS is certainly an option. If we > went that direction, though, returning just an XRD document might be > preferable. That way we still get the advantage of nothing needing to > change > in the schema, and CanonicalID staying where it is, but the client > receiving > just the final XRD and just the selected service endpoint. > > URIs would still be "fully exploded" per my earlier message. > > Example: > > <XRD xlmns="xri://$xrd*($v*2.0)"> > <CanonicalID>xri://=!A1B2.C3D4</CanonicalID> > <Service > > <ProviderID>xri://!!1000!1234.5678</ProviderID> > <Type select="true">xri://+contact*($v*1.0)</Type> > <Path match="null" /> > <URI > priority="10">http://example.com/contact/=!A1B2.C3D4?id=xri://@foo</URI> > <URI > priority="15">http://alt.example.com/contact/=!A1B2.C3D4?id=xri://@foo</ UR > I> > > <URI>https://example.com/contact/=!A1B2.C3D4?id=xri://@foo</URI> > </Service> > </XRD> > > What does everyone think? > > =Drummond > > -----Original Message----- > From: Chasen, Les [mailto:les.chasen@neustar.biz] > Sent: Friday, February 24, 2006 7:05 PM > To: Drummond Reed; xri@lists.oasis-open.org > Subject: RE: [xri] Proposal for _xrd_r parameter and return format > > It sounds confusing because some times I see it outside a service block > and sometimes I see it inside. BTW, if a client can parse a service > block why can't it just parse the xrds? How about we return an XRDS > document that simply includes the data points you want? In this case > the XRDS would not include the many XRDs or SEPs that were returned in > authority resolution. It would just return the CanonicalIds and service > block. > > > I-Name: =les.chasen > > > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Friday, February 24, 2006 9:43 PM > To: Chasen, Les; xri@lists.oasis-open.org > Subject: RE: [xri] Proposal for _xrd_r parameter and return format > > Les, > > Since Steve is out today I spoke with Andy Dale to better understand the > use > case. > > It turns out that ooTao does not have a strong use case for increasing > CanonicalID granularity, i.e., provisioning a CanonicalID directly with > a > service endpoint vs. the entire XRD. However Andy agreed that > CanonicalID > would be a very useful child element of Service in a service endpoint > output > document because it allows all the information relevant to a selected > service endpoint to be packaged and returned in a single Service > element. > > This then would be consistent across both a native client resolver API > and a > proxy resolver interface. > > So the rule would be simply to return CanonicalID(s) as a child element > of > Service when return of a service endpoint is requested vs. return of the > entire XRD. > > How does that sound? > > =Drummond > > -----Original Message----- > From: Chasen, Les [mailto:les.chasen@neustar.biz] > Sent: Friday, February 24, 2006 6:10 PM > To: Drummond Reed; xri@lists.oasis-open.org > Subject: RE: [xri] Proposal for _xrd_r parameter and return format > > On number 1 I am neutral (not in favor of but not against) as long as it > is optional. > > On number 3 ... wow that sounds like a totally new requirement/usecase > that has nothing to do with a proxy server having a more robust > interface. Why do we need a canonicalid with finer granularity? What > does override mean? > > I see the following two possible test cases. > > 1. If I have the following XRDS > > <XRDS> > .... > <CanoncialId> foo </canonicalid> > <service> > ... > </service> > </xrds> > > Then the proxy server would return > <service> > <CanoncialId> foo </canonicalid> > ... > </service> > > IMHO this is confusing. > > 2. If I have the following XRDS > > <XRDS> > ... > <canonicalId> foo </canonicalid> > <service> > <canonicalid> bar </caonnonicalid> > ... > </service> > > What does this mean? > > I think we need to understand the requirement here. Can someone please > explain the usecase? > > > I-Name: =les.chasen > > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Friday, February 24, 2006 6:35 PM > To: Chasen, Les; xri@lists.oasis-open.org > Subject: RE: [xri] Proposal for _xrd_r parameter and return format > > Les, see replies inline marked ###. > > =Drummond > > -----Original Message----- > From: Chasen, Les [mailto:les.chasen@neustar.biz] > Sent: Friday, February 24, 2006 2:12 PM > To: Drummond Reed; xri@lists.oasis-open.org > Subject: RE: [xri] Proposal for _xrd_r parameter and return format > > I have a few comments. > > 1. I am not in favor of adding this capability to the spec for http > proxy resolution servers. I feel that the capabilities already provided > for in the spec allow implementers to build edge resolution services > that support this type of functionality. I think implementers who need > this type of functionality should be encouraged to write to programmatic > interfaces not http proxy resolution servers. > > ### Ironically, this is a programmatic interface. It's a web service (in > the > broad definition of XML-over-HTTP.) But you're right that it's one > that's > better suited to the edges of the network than the core. ### > > 2. If you guys want to add this then this has to be optional behavior. > We discussed this on the call but I don't see it documented. > > ### My fault for not noting it -- this was just meant to be the > technical > proposal, not the full text going in the spec. It will be documented as > optional. ### > > 3. This proposal is adding CanonicalId to the service block. Is this > only used in the service block under these circumstances? If so is that > going to add confusion? I think it might because sometimes I will see > the canonical id in a service block sometimes I will see it outside the > service block depending on what I ask for. > > ### No, it's not just for this proposal. It solves another problem, > which is > how you can specify a CanonicalID at a lower level of granularity - the > service level instead of the XRD level. The CanonicalID at the XRD level > is > very useful but this gives you a way to override it at the Service level > if > needed. ### > > ### END ### > > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Friday, February 24, 2006 4:33 PM > To: xri@lists.oasis-open.org > Subject: [xri] Proposal for _xrd_r parameter and return format > > Per my second action item from yesterday's TC call minutes, this is a > proposal to add an _xrd_r (Return) input parameter to XRI Resolution 2.0 > Working Draft 10. > > Background: this originated in the decision that the standard output of > XRI > resolution when service endpoint selection is requested should be not > just a > prioritized list of URIs, but also a prioritized list of CanonicalIDs, > so > that XRD authors have the ability to tell consuming applications the > identifier(s) they should use for a resource at a specific service > endpoint. > > It's easy to see how such a return value can be returned via a local XRI > resolver API, and that's out of scope for the spec. But it raised the > question of how such a result could be returned via an XRI proxy > resolver > which has only an HTTP interface, and which is in scope of the spec. > > The proposed solution is two parts: > > PART ONE: _XRD_R PARAMETER > > Like _xrd_n, the _xrd_r (Return) parameter would be a Boolean flag. The > default if it is omitted or its value is null is the implied value of > "false", which means the return type is be governed by the _xrd_m > (MediaType) attribute. > > If _xrd_r="true", then the resolver MUST return an XML document > consisting > of only the selected service endpoint (part two). > > PART TWO: SERVICE ENDPOINT DESCRIPTOR > > 2) To keep it as simple as possible, the proposed return format if > _xrd_r="true is an XML document that reuses the xri://$xrd*($v*2.0) XML > namespace and just contains the selected Service element. Following is a > example: > > <Service xlmns="xri://$xrd*($v*2.0)" > > <ProviderID>xri://!!1000!1234.5678</ProviderID> > <CanonicalID>xri://=!A1B2.C3D4</CanonicalID> > <Type select="true">xri://+contact*($v*1.0)</Type> > <Path match="null" /> > <URI > priority="10">http://example.com/contact/=!A1B2.C3D4?id=xri://@foo</URI> > <URI > priority="15">http://alt.example.com/contact/=!A1B2.C3D4?id=xri://@foo</ > URI> > <URI>https://example.com/contact/=!A1B2.C3D4?id=xri://@foo</URI> > </Service> > > To support this return format would require that we add CanonicalID as > an > optional child of the XRD Service element. This means CanonicalID could > appear at both the XRD level and the Service level exactly the way > ProviderID can currently appear at both levels. This has the additional > benefit of allowing CanonicalID to be expressed on a more granular > service > level rather than just at the XRD level. > > The rule would be that CanonicalID would be used directly if present in > the > selected Service, or it would be "inherited" from the XRD level if it > was > not present for the selected Service. In other words, CanonicalID at the > XRD > level is the default for every Service unless the Service overrides it > by > including 1+ CanonicalID elements. > > In addition, in a Service document the values of the URI element would > be > "fully constructed", i.e., they will have had the "append" algorithm > executed to produce the final URI. > > ****** > > Again, the plan is to incorporate this into ED 07 to close this issue, > so > please send feedback on this proposal as soon as you can. > > =Drummond > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]