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