[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
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</URI> <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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]