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