[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
Wil, agreed very much on the first note. I will capture that in ED 07. On the second 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?", my answer is that the Query element should always contain the string designated by the protocol. Ironically, given that the XRI resolution protocol only "resolves" authority subsegments (it always "computes" service endpoints), and b) even during lookahead resolution, subsegments are always resolved one at a time, the Query element itself would never contain anything more than a single authority subsegment. Does everyone else agree with this? =Drummond -----Original Message----- From: Tan, William [mailto:William.Tan@neustar.biz] Sent: Monday, February 27, 2006 11:07 PM To: xri@lists.oasis-open.org 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 --------------------------------------------------------------------- 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]