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] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-07-16

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Tuesday, July 28, 2009 9:18 AM
> To: Eran Hammer-Lahav; xri@lists.oasis-open.org
> Subject: RE: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-07-16
> Eran Hammer-Lahav wrote on 2009-07-28:
> > If you want to keep that as an option, I would substitute it with a
> single
> > element like <SubjectBeginsWith> and drop the attribute. There is
> just no
> > need for all the child elements. This way it is still a fully
> qualified
> > which can be used exactly the same way as <Subject> for trust
> purposes.
> Couldn't one argue that if it's that easy to adopt the same matching
> rules
> for "trust purposes", that we might just as well use the framework
> being
> proposed for arbitrary subject matching and just use that for "trust
> purposes"?

I don't understand.

> > But I think this is a bit inconsistent with the overall extensible
> design
> we
> > have, and if people are going to 'creating custom rules all over the
> place',
> > shouldn't we give them a place to do it rather than create new
> elements
> like
> > <SubjectRegex> etc.?
> If that's a goal, then I think we should probably adopt an existing
> framework for expressing matching rules rather than create a new one.

Can you point to such existing framework that is consistent with the simplicity of XRD?

The POWDER framework is unacceptable in its richness/complexity (depending on your needs). Full regex for the entire subject is going to make it hard to extract an authority (even if you spell it out externally, it will still be a complicated matching process). I am not aware of any other options.

The goals are to:

1. Stay consistent with the overall XRD design
2. Allow the same trust profile being proposed for <Subject> to apply to the 'set' with minimal extra code
3. Stay within the constraints of the host-meta use case which is to describe all resources with the same URI scheme and authority


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]