[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 1) XRD Subject matching & 2) host meta URI
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]