1) XRD Subject matching & 2) host meta URI

["Drummond Reed" <drummond.reed@cordance.net>]

I just had a long talk with John Bradley about both of these subjects (and
their relationship). 

We came out with 2 key points:

1) Do we really need #begins-with subject matching? Does anyone actually
have a use case for it? (Your own use case, not someone else's.)

John pointed out that if even a single resource within the subject set scope
needs its own XRD, then all resources within the subject set scope will need
their own XRDs, because we don't have a way of expressing, "all resources in
the example.com domain EXCEPT example.com/exception".

So who has a use case that requires subject sets? If not, let's drop it, and
do away with the match attribute.

2) Does the subject of a host-meta XRD just need a way to indicate that the
subject is not a concrete URI, but the abstract concept of the host for that
URI? 

If so, let's just specify that for a host meta URI, you add a blank hash
tag. Example:

	http://example.com	<== Concrete subject
	http://example.com#	<== Abstract host meta subject

It's a simple solution that happens to be consistent with the SemWeb but
doesn't require any SemWeb baggage.

=Drummond 

> -----Original Message-----
> From: John Bradley [mailto:jbradley@mac.com]
> Sent: Monday, August 24, 2009 4:06 PM
> To: Will Norris
> Cc: XRI TC
> Subject: Re: [xri] XRI subject matching
> 
> Remind me again why the dns: scheme URI for the host meta XRD was
> rejected.
> 
> We aren't limiting the URI schemes to http:.
> 
> I don't think match is needed for XRI resolution.   The trust profile
> is different from the HTTP one using SSL certs.
> 
> There is a separate question of how XRI proxy resolvers represent XRI
> as the subject and subsequently how that maps to the SSL trust model.
> 
> A proxy server is probably going to have to resign to make that work so.
> http://xri.net/=willnorris  will be signed by xri.net  etc
> 
> I have a hard time seeing clients using the proxy supporting anything
> else by default.
> 
> Clients that support XRI should use that trust model.
> 
> John B.
> 
> On 24-Aug-09, at 5:17 PM, Will Norris wrote:
> 
> > There has been a bit of discussion on the thread list XRD Subjects,
> > most around the ongoing problem of what to do for host-meta
> > documents.  To date, host-meta has been the only use-case for the
> > match attribute on Subject, but I wanted to remind everyone of
> > another -- XRI matching.  Drummond and John were supposed to talk
> > about this a bit offline, so I'll let them respond with what they've
> > come up with, but very preliminary discussions I had with Drummond
> > indicated that the match attribute would be very useful for XRI
> > matching.  I'll be the first to admit I don't fully grok XRI syntax,
> > much less the latest 3.0 draft, so someone can explain more if
> > necessary.  All I do know however, is that the following two URIs
> > represent the same "=willnorris" XRI:
> >
> >  http://xri.net/=willnorris
> >  http://xri.fullxri.com/=willnorris
> >
> > There is no way to know that these should be considered equivalent
> > without some special processing rules.  They are certainly not
> > equivalent strings, and a "beginswith" comparison doesn't work
> > either.  This means that XRI Resolution 3.0 will need to define a
> > new value for the match attribute that means, "This thing is an
> > XRI.  Compare it against other URIs using the following rules...".
> > If we drop the match attribute in favor of something like <Host> for
> > host-meta, then we're leaving XRI resolution out in the cold.  While
> > I believe that "beginswith" Subject matching for host-meta is the
> > worst possible solution (except of course for all the others), I
> > want to make sure folks remember that we do have at least one other
> > use case to keep in mind.
> >
> > -will
> >
> > ---------------------------------------------------------------------
> > 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
> 
> 
> ---------------------------------------------------------------------
> 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