RE: Subject of a host-meta XRD (was: <SubjectTemplate>)

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

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
> > > >
> >