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] RE: Subject of a host-meta XRD (was: <SubjectTemplate>)


I'm cool with using either <SubjectTemplate> with template URIs or multiple
XML elements as children.

I don't see a problem with using multiple <SubjectTemplate> elements because
it's very similar to using multiple XML child elements like POWDER does.
Both are just ways to describe the graph of all resources covered by the
template.

It seems to me that both options have the same challenge when it comes to
signatures, which is that since the XRD now covers a graph of resources
rather than a single resource, who signs it?

Unless I'm missing something, it seems the rule should be that the signing
authority must be the root of the graph. The sticky issue is that the graph
may have multiple roots. In this case should we require multiple signatures,
one by each root? Or should we limit a host-meta XRD to a single root, so it
can have only one signature?

=Drummond 

> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Wednesday, July 01, 2009 11:54 PM
> To: Drummond Reed; 'XRI TC'
> Subject: [xri] RE: Subject of a host-meta XRD (was: <SubjectTemplate>)
> 
> The main problem with <SubjectTemplate> is that we will need to invent a
> template syntax that does a lot of what regex does, but at the same time,
> allows clients to easily parse our the authority part so that they can
> verify the signature. That is not so easy to do, unless we do something
> like:
> 
> <SubjectTemplate>{http}://{example.com:8080}/{regex-
> path}</SubjectTemplate>
> 
> Which allows easy access to the various components and full regex where
> needed. But this is pretty ugly and complex and I think we are better off
> with a few more XML elements to accomplish the same thing.
> 
> The problem with multiple <SubjectTemplate>s is that which do you use as
> the signature authority?
> 
> EHL
> 
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Wednesday, July 01, 2009 10:51 PM
> > To: Eran Hammer-Lahav; 'XRI TC'
> > Subject: RE: Subject of a host-meta XRD (was: <SubjectTemplate>)
> >
> > Eran, I strongly prefer keeping host-meta as a standard XRD document,
> > i.e.,
> > the same as any other XRD except it happens to represent a root node in
> > the
> > graph of all XRD Subjects.
> >
> > What about your SubjectTemplate idea, i.e., offering the same option
> > with
> > Subject that we did with URI and URITemplate?
> >
> > If the cardinality of SubjectTemplate was 1-or-more, you could used
> > multipel
> > SubjectTemplate elements to describe the set of subjects that it
> > covered.
> > And if the XRD schema gave you a Choice of Subject or SubjectTemplate,
> > then
> > any root XRD (host-meta file) could simply use a SubjectTemplate
> > instead of
> > Subject.
> >
> > Everything else would remain the same.
> >
> > I'll put this on the agenda for tomorrow.
> >
> > =Drummond
> >
> > > -----Original Message-----
> > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> > > Sent: Wednesday, July 01, 2009 9:43 AM
> > > To: Drummond Reed; 'XRI TC'
> > > Subject: RE: Subject of a host-meta XRD (was: <SubjectTemplate>)
> > >
> > > I am looking for feedback from the TC about the questions below as
> > well as
> > > gauging the TC's appetite for venturing into URI sets and rules
> > (either
> > > via a URI template of some sort or a more structured XML schema
> > similar to
> > > POWDER).
> > >
> > > So our options are:
> > >
> > > 1. Define a new element(s) in XRD to allow a resource set as a
> > subject.
> > > This solves all the semantic issues because it eliminates the concept
> > of a
> > > host. The XRD in that case applies to any resource that matches its
> > rules.
> > > We can offer a very limited URI sets functionality that will be
> > useful for
> > > many simple use cases. Something like:
> > >
> > > <XRD>
> > >     <SubjectSet>
> > >             <Authority>example.com:80</Authority>
> > >             <Schemes>http https</Schemes>
> > >             <Suffix>*</Suffix>
> > >     </SubjectSet>
> > > </XRD>
> > >
> > > In which the authority is used to sign (wildcards are allowed the
> > same way
> > > they are allowed as certificate subjects), schemes are space
> > delimited,
> > > and suffix a regex (defaults to all omitted). This makes it easy to
> > take
> > > any URI and match it against the rules:
> > >
> > > http://example.com/resource/1 --> scheme: http, authority:
> > example.com:80,
> > > suffix: /resource/1
> > >
> > > 2. Define a new URI for the host (as a non network resource) and use
> > it as
> > > the subject of the host-meta XRD. LRDD (where this will be defined)
> > will
> > > make it clear that anything other than links with URI templates and a
> > > describedby relation (alone or in addition to others) are left
> > undefined.
> > > The problem is, while it was easy to do that using Link-Pattern, it
> > is not
> > > so easy with <Link>. Also, while LRDD can register the new URI
> > scheme, it
> > > will not go without resistance.
> > >
> > > 3. Use a different schema for host-meta that is compatible with XRD
> > for
> > > the purpose of signatures. Something like:
> > >
> > > <Host-Meta>
> > >     <Host>example.com:80</Host>
> > >     <!-- Signature stuff here same as XRD -->
> > >     <Link-Pattern rel="describedby"
> > > pattern="http://example.com/meta?uri={%uri}";
> > type="application/xrd+xml" />
> > > </Host-Meta>
> > >
> > > My vote is for #1 and then #3. While #3 is easier, #1 offers a more
> > > consistent framework and allows future uses for host-meta since it is
> > a
> > > fully featured XRD.
> > >
> > > EHL
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > > > Sent: Wednesday, July 01, 2009 8:37 AM
> > > > To: Eran Hammer-Lahav; 'XRI TC'
> > > > Subject: RE: Subject of a host-meta XRD (was: <SubjectTemplate>)
> > > >
> > > > Agreed on all points.
> > > >
> > > > So what's the gameplan for coming to closure on this issue? Should
> > I
> > > > put it
> > > > on the agenda for tomorrow's telecon?
> > > >
> > > > =Drummond
> > > >
> > > > > -----Original Message-----
> > > > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> > > > > Sent: Tuesday, June 30, 2009 11:00 PM
> > > > > To: Drummond Reed; 'XRI TC'
> > > > > Subject: RE: Subject of a host-meta XRD (was: <SubjectTemplate>)
> > > > >
> > > > > The issue is still open, but I am not sure we have nails the
> > exact
> > > > problem
> > > > > yet.
> > > > >
> > > > > If you recall about 6 months ago we had a discussion about
> > whether
> > > > Links
> > > > > in host-meta apply to individual resources belonging to the host
> > > > under
> > > > > LRDD. According to the host-meta spec, they do, but LRDD I
> > explicitly
> > > > > chose to ignore them for the purpose of looking for descriptors.
> > A
> > > > few
> > > > > days ago Dirk raised the same questions.
> > > > >
> > > > > We had all these issues before with the text-based host-meta but
> > they
> > > > were
> > > > > just not that obvious because we were unable to apply all the
> > > > thinking
> > > > > that went into XRD there. But now that we reformatted host-meta
> > to
> > > > use
> > > > > XRD, it all surfaced.
> > > > >
> > > > > The two main questions are:
> > > > >
> > > > > 1. What is a 'host' (or 'site' or 'authority' etc.)?
> > > > > 2. How do we identify it?
> > > > >
> > > > > So far we defined host as either:
> > > > >
> > > > > 1. Any resource belonging to the combination of
> > domain/port/protocol
> > > > (i.e.
> > > > > a set), or
> > > > > 2. An abstract concept of authority restricted by domain/port and
> > > > possibly
> > > > > protocol
> > > > >
> > > > > A Link to one has a very different meaning than the other. In
> > fact, I
> > > > > don't know what a Link means for #2...
> > > > >
> > > > > If we decide a host is a 'set', we should find a way to describe
> > a
> > > > set of
> > > > > URIs (which will be useful for other purposes). If we decide a
> > host
> > > > is a
> > > > > resource (of some sort), we should find a URI to identify it.
> > > > >
> > > > > I don't think there is right or wrong here. It is just a question
> > of
> > > > which
> > > > > option is easier/more productive/reusable.
> > > > >
> > > > > EHL
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > > > > > Sent: Tuesday, June 30, 2009 10:47 PM
> > > > > > To: Eran Hammer-Lahav; 'XRI TC'
> > > > > > Subject: Subject of a host-meta XRD (was: <SubjectTemplate>)
> > > > > >
> > > > > > Eran,
> > > > > >
> > > > > > I knew as soon as the question "What's the subject of a host-
> > meta
> > > > XRD?"
> > > > > > came
> > > > > > up that we were headed into W3C httpRange-14 territory. For
> > those
> > > > who
> > > > > > have
> > > > > > never heard about this "Web identity crisis", see:
> > > > > >
> > > > > >       http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-
> > > 31/HttpRange-
> > > > > > 14
> > > > > >       http://norman.walsh.name/2005/06/19/httpRange-14
> > > > > >       http://www.garshol.priv.no/blog/125.html
> > > > > >
> > > > > > There are dozens more references where those came from, as I'm
> > sure
> > > > > > those
> > > > > > who have stepped into this quicksand know. Just Google
> > "httpRange-
> > > > 14".
> > > > > >
> > > > > > So I'm not going to try to give any philosophical answers here,
> > > > only
> > > > > > practical ones. On that basis, my observations:
> > > > > >
> > > > > > 1) Both the <XRD:SubjectTemplate> suggestion (see below) and
> > the
> > > > Powder
> > > > > > approach (essentially another way of desribing a URI template
> > using
> > > > > > individual XML elements for each constraint) seem like
> > reasonable
> > > > > > options. I
> > > > > > prefer SubjectTemplate because it's less complex. But I'm not
> > sure
> > > > what
> > > > > > the
> > > > > > SubjectTemplate value would be that describes "the authority
> > for
> > > > this
> > > > > > domain" vs. any specific resource in that domain. Would it just
> > be
> > > > a
> > > > > > wildcard?
> > > > > >
> > > > > > 2) A second option is to use either a fragment, or an empty
> > > > fragment. I
> > > > > > prefer the latter for this particular use case. In other words,
> > if
> > > > > > http://example.com identifies a specific information resource
> > > > (e.g.,
> > > > > > the 200
> > > > > > response you get back), then http://example.com# could describe
> > the
> > > > > > abstract
> > > > > > concept of http://example.com (a non-information resource).
> > > > > >
> > > > > > 2) A third option -- mentioned frequently in the httpRange-14
> > > > debate --
> > > > > > is
> > > > > > using another URI scheme intended exclusively to represent non-
> > > > > > information
> > > > > > resources. (Hmmmm, where could we find something like that? ;-)
> > Of
> > > > > > course,
> > > > > > it's ironic that due to W3C TAG's input, XRI is no longer
> > actually
> > > > > > another
> > > > > > URI scheme, but an identifier syntax that is bound to a base
> > URI to
> > > > > > produce
> > > > > > a valid URI. I posted earlier about what the bound http: XRI
> > that
> > > > > > described
> > > > > > "the current authority" would look like: http://xri.net/$.
> > > > > >
> > > > > > In any case, all three of these options would appear to work.
> > Have
> > > > you
> > > > > > decided on one? Is the issue still open?
> > > > > >
> > > > > > =Drummond
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> > > > > > > Sent: Sunday, June 28, 2009 12:37 PM
> > > > > > > To: XRI TC
> > > > > > > Subject: [xri] <SubjectTemplate>
> > > > > > >
> > > > > > > This idea isn't new but given the need to solve the host-meta
> > > > Subject
> > > > > > use
> > > > > > > case, I would like to know what others here think about it.
> > > > > > >
> > > > > > > EHL
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: uri-request@w3.org [mailto:uri-request@w3.org] On
> > Behalf Of
> > > > > > Eran
> > > > > > > Hammer-Lahav
> > > > > > > Sent: Sunday, June 28, 2009 12:32 PM
> > > > > > > To: Erik Wilde; uri@w3.org
> > > > > > > Subject: RE: URI for abstract concepts (domain, host, origin,
> > > > site,
> > > > > > etc.)
> > > > > > >
> > > > > > > Using a URI template is one option being considered (XRD
> > already
> > > > has
> > > > > > a
> > > > > > > <URITemplate> element under <Link> so the syntax is already
> > part
> > > > of
> > > > > > XRD).
> > > > > > > However, that requires either creating a new element (like
> > > > > > > <SubjectTemplate>) or changing the XML schema type for
> > <Subject>
> > > > > > which
> > > > > > > currently does not allow anything but valid URIs.
> > > > > > >
> > > > > > > But before we consider that, I wanted to see if there was an
> > easy
> > > > > > solution
> > > > > > > for describing such resources with a URI.
> > > > > > >
> > > > > > > EHL
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: uri-request@w3.org [mailto:uri-request@w3.org] On
> > Behalf
> > > > Of
> > > > > > Erik
> > > > > > > > Wilde
> > > > > > > > Sent: Sunday, June 28, 2009 11:43 AM
> > > > > > > > To: uri@w3.org
> > > > > > > > Subject: Re: URI for abstract concepts (domain, host,
> > origin,
> > > > site,
> > > > > > > > etc.)
> > > > > > > >
> > > > > > > > hello.
> > > > > > > >
> > > > > > > > Eran Hammer-Lahav wrote:
> > > > > > > > > Let me try explaining my use case again, this time
> > without
> > > > any
> > > > > > > > overloaded terminology or proposed solutions.
> > > > > > > > > XRD is a document format for describing resources. It
> > looks
> > > > like
> > > > > > > > this:
> > > > > > > > > <XRD>
> > > > > > > > >         <Subject>http://example.com</Subject>
> > > > > > > > >         <Type>http://example.org/type/blog</Type>
> > > > > > > > >         <Link>
> > > > > > > > >                 <Rel>author</Rel>
> > > > > > > > >                 <URI>http://example.com/author</URI>
> > > > > > > > >         </URI>
> > > > > > > > > </XRD>
> > > > > > > > > Without getting too much into XRD, this short descriptor
> > > > > > describes
> > > > > > > > the resource identified by 'http://example.com'. It
> > includes
> > > > one
> > > > > > type
> > > > > > > > indicator (a made up example meant to mean this resource is
> > a
> > > > > > blog),
> > > > > > > > and one link to the author's page.
> > > > > > > > > I want to use this document format to describe rules that
> > > > apply
> > > > > > to
> > > > > > > > all resources which belong to an HTTP host (as defined by
> > 2616:
> > > > a
> > > > > > > > domain/address and port combination). The problem is,
> > <Subject>
> > > > > > > > requires a URI and currently there is no way to identify
> > this
> > > > set
> > > > > > of
> > > > > > > > resources (http://domain:port/*) as a valid URI.
> > > > > > > > > What I don't want to do is use an exception such as 'if
> > the
> > > > URI
> > > > > > > > begins with X, treat it as a rule and not a valid URI'...
> > > > > > > >
> > > > > > > > given this new description, isn't what you're looking for a
> > URI
> > > > > > > > template
> > > > > > > > language for XRD? maybe not exactly the one currently
> > proposed
> > > > by
> > > > > > > > http://tools.ietf.org/html/draft-gregorio-uritemplate-03,
> > but
> > > > isn't
> > > > > > > > that
> > > > > > > > close to what you want? a template notation would also
> > nicely
> > > > > > address
> > > > > > > > the case mentioned already where the host scope would be
> > too
> > > > > > general.
> > > > > > > > but then again, a URI template is not a URI, so you could
> > use
> > > > it in
> > > > > > the
> > > > > > > > context of XRD, but not as a standalone URI....
> > > > > > > >
> > > > > > > > cheers,
> > > > > > > >
> > > > > > > > erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
> > > > > > > >         dret@berkeley.edu  -  http://dret.net/netdret
> > > > > > > >         UC Berkeley - School of Information (ISchool)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -------------------------------------------------------------
> > ----
> > > > ----
> > > > > > > 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]