[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
I was not receiving email at the end of last week. I come in Monday and boy was I surprised to see almost 30 emails on the list. I must say that I agree wholeheartedly with Wil on this one. -Gabe > -----Original Message----- > From: Tan, William [mailto:William.Tan@neustar.biz] > Sent: Saturday, February 25, 2006 4:20 AM > To: Drummond Reed; Chasen, Les; xri@lists.oasis-open.org > Subject: RE: [xri] Proposal for _xrd_r parameter and return format > > Having cooked on it for a while, I feel that we don't necessarily have > to work this into the specs at this time. > > IMO, this will add complexity to the resolution spec without adding a > lot of value. And I would also point to Victor's suggested reading on > how partial implementation helped the web, as fragmented as > it is today > (http://www.shirky.com/writings/evolve.html) > > Don't get me wrong, I like the idea a lot, but to be > practical, I think > we could use a little bloat control and at least defer it to a later > revision or a separate document. > > Just my 2c. > > =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=xr > i://@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=xr > i://@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 > > > --------------------------------------------------------------------- > 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_workgr > oups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]