OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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


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]