[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
Gabe, Due to deadlines several of us (Les, Steve, and I) ended out working much of the weekend on this, so the thinking has already evolved -- very much motivated by trying to keep it simple. See my next email about the most recent proposal from Steve. =Drummond -----Original Message----- From: Wachob, Gabe [mailto:gwachob@visa.com] Sent: Monday, February 27, 2006 2:45 PM To: Tan, William; Drummond Reed; Chasen, Les; xri@lists.oasis-open.org 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 > > --------------------------------------------------------------------- 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]