RE: Hole in XRD processing: Type matching

[Eran Hammer-Lahav <eran@hueniverse.com>]

If it wasn't clear, this is a blocking issue and we cannot publish another draft of the spec until it is resolved.

Will and I had a long conversation about it last night and here are some additional thoughts:

* We have two clear use cases:

- The ability to delegate XRD descriptor for a local resource to another provider. While this can be done at the links level, we need it to be signed for trust purposes which means we need the "redirection" to happen inside a signed document. Since we only have one mechanism to do so (XRD), we need to express this inside XRD. For example, a site can point consumers to another company to manage all its XRD needs.

- The ability to define a local XRD and include in it descriptors from other documents. This is needed to override or supplement the information in either the local XRD or the included XRDs. For example, being able to delegate XRD services to another service which does not support some new XRD feature, but still add that locally before including the delegated information.

Right now, we have a well-defined solution that does not meet the expectations. See-also links currently only import <Link> elements from other XRD documents, and anything else in the linked XRD is ignored, including the <Subject>, <Alias>, and <Type>. <Subject> may be used for trust verification but undefined for anything else when following a see-also. This fails both use cases.

More too follow.

EHL

> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Tuesday, September 15, 2009 9:32 PM
> To: 'XRI TC'
> Subject: [xri] Hole in XRD processing: Type matching
> 
> I brought this up before but I didn't realize how much bigger the issue
> is.
> 
> 
> Currently, we say nothing about how consumers should treat the see-also
> link in the context of Type matching (as opposed to Link selection).
> Basically, we do not include see-also links for the purpose of resource
> properties, only links. Furthermore, it doesn't address any extensions
> at the XRD level (link extensions are covered).
> 
> Consider this:
> 
> <XRD>
> 	<Type>http://example.com/type1</Type>
> 	<Link>
> 		<Rel>http://docs.oasis-open.org/xri/xrd/v1.0#see-also</Rel>
> 		<URI>http://example.com/xrd2<URI>
> 		<MediaType>application/xrd+xml</MediaType>
> 	</Link>
> </XRD>
> 
> And xrd2:
> 
> <XRD>
> 	<Type required="true">http://example.com/type2</Type>
> </XRD>
> 
> In the example above, the consumer will ignore the see-also type, and
> will continue to interact with the resource even if it doesn't
> understand 'type2'.
> 
> Another example:
> 
> <XRD>
> 	<Link>
> 		<Rel>http://docs.oasis-open.org/xri/xrd/v1.0#see-also</Rel>
> 		<URI>http://example.com/xrd2<URI>
> 		<MediaType>application/xrd+xml</MediaType>
> 	</Link>
> </XRD>
> 
> And xrd2:
> 
> <XRD>
> 	<Type>http://example.com/type1</Type>
> 	<Link>
> 		<Rel>http://example.com/rel1</Rel>
> 		<URI>http://example.com/endpoint<URI>
> 	</Link>
> </XRD>
> 
> In this case, the first XRD simply delegates its description to another
> XRD. However, this delegation is limited to link selection only which
> means a consumer looking for link of type 'rel1' will not process the
> 'type1' information. This will lead to either incomplete information at
> the time of processing the xrd2 link, or to failing to recognize (and
> hence even look for such link) that the resource supports the 'type1'
> functionality.
> 
> ---
> 
> None of the options to resolve this are great. This is the list I was
> able to come up with:
> 
> 1. Require the parsing of all linked XRDs for the purpose of
> determining the resource attributes (XRD level). This doesn't scale
> well, but might not be too bad since we are talking about building a
> flat list of single values. It also solves the issue of XRD level
> extensions which will also be collected.
> 
> 2. Limit consumers to use the types from the first XRD only. This goes
> against the architecture and breaks the main use case for see-also
> which is delegating the entire descriptor.
> 
> 3. Make the fetching of linked XRDs for the purpose of resource
> attribute optional, but that conflicts with the use of the 'required'
> attribute. It will create inconsistent behavior based on how a consumer
> obtained an XRD.
> 
> What makes <Type> so different from <Link> is that with links,
> consumers know what they are looking for (often thanks to the use of
> <Type>). But with XRD level resource attributes, the whole point is to
> go over the list and discovery what is familiar.
> 
> #1 is the only option that is consistent with the architecture but I am
> worries about its implementation. I am not sure what is the right
> solution.
> 
> Ideas?
> 
> EHL
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php