[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
On that note, we should make sure that it is stated clearly in the spec that while support for _xrd_r is optional, implementations MUST reject the request with 212 NOT_IMPLEMENTED immediately if the flag is present and the feature is not implemented. Otherwise, the the parameter was simply ignored, there would be no way for a client to tell if the returned XRDS contains only the selected Services or just raw XRDS. Also, I did not get an answer to my other question: > 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? Thanks. =wil (http://xri.net/=wil) > -----Original Message----- > From: Tan, William [mailto:William.Tan@neustar.biz] > Sent: Tuesday, February 28, 2006 6:00 PM > To: Drummond Reed; xri@lists.oasis-open.org > Subject: RE: [xri] Proposal for _xrd_r parameter and return format > > Agreed. NOT_IMPLEMENTED it is! > > =wil (http://xri.net/=wil) > > > > > -----Original Message----- > > From: Drummond Reed [mailto:drummond.reed@cordance.net] > > Sent: Tuesday, February 28, 2006 5:59 PM > > To: xri@lists.oasis-open.org > > Subject: RE: [xri] Proposal for _xrd_r parameter and return format > > > > Nope, I think you're right, generic is better. Given the HTTP pattern, > do > > you prefer NOT_IMPLEMENTED over NOT_SUPPORTED? > > > > I like the semantics of the former a little better because the latter > may > > sound like the feature is not supported by the *protocol*, while the > > former > > makes it clear that it is not implemented by the implementation. > > > > =Drummond > > > > -----Original Message----- > > From: Tan, William [mailto:William.Tan@neustar.biz] > > Sent: Monday, February 27, 2006 10:55 PM > > To: Drummond Reed; xri@lists.oasis-open.org > > Subject: RE: [xri] Proposal for _xrd_r parameter and return format > > > > I was thinking that it would be a generic "feature not > > supported/implemented" code (similar to HTTP 501 Not Implemented), > > though I'm not sure what other use cases there are for it. > > > > If you think that it is better to have a specific code for _xrd_r, > > that's fine with me too. > > > > =wil (http://xri.net/=wil) > > > > > > > > > -----Original Message----- > > > From: Drummond Reed [mailto:drummond.reed@cordance.net] > > > Sent: Tuesday, February 28, 2006 5:24 PM > > > To: xri@lists.oasis-open.org > > > Subject: RE: [xri] Proposal for _xrd_r parameter and return format > > > > > > Agreed. Should it be 212 RETURN_NOT_SUPPORTED? > > > > > > =Drummond > > > > > > -----Original Message----- > > > From: Chasen, Les [mailto:les.chasen@neustar.biz] > > > Sent: Monday, February 27, 2006 9:09 PM > > > To: Tan, William; Drummond Reed; xri@lists.oasis-open.org > > > Subject: RE: [xri] Proposal for _xrd_r parameter and return format > > > > > > This makes sense if we are going to have optional behavior in > > resolvers. > > > > > > > > > I-Name: =les.chasen > > > > > > > > > -----Original Message----- > > > From: Tan, William > > > Sent: Monday, February 27, 2006 11:35 PM > > > To: Drummond Reed; Chasen, Les; xri@lists.oasis-open.org > > > 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 > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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]