Subject: RE: host-meta: template syntax hassles

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 6 Nov 2009 14:44:17 -0700

This subject was discussed at length this week at IIW. The strong consensus was that since the currently proposed template vocabulary isn't expressive enough, it should be made even less expressive (only define 'uri') and not more expressive (see one proposal below). The main argument were:

- A future (richer) template syntax will address empty variables and the proper assembling of URI components together. When it becomes available, host-meta could be updated to define the full set of variables to support such common transformations.

- Any vocabulary breaking the context URI into parts will need a complimentary method for applying links to resource subsets (at least based on the URI scheme). For example, it is not likely that a single template (using variables other than 'uri') will be able to properly address both 'http' and 'xmpp' URI transformation.

The second point is the most important in my view since it requires extending the proposed document format to directly support describing subsets of resources. I am more inclined to reduce the vocabulary to a single 'uri' variable than extend both the vocabulary and schema to support richer scheme or pattern specific transformation.

Since host-meta allows protocols to define their own 'rel'-specific template syntax and vocabulary, individual protocols with such needs will still be able to make use of the framework. In addition, servers can always use a simple redirection script to redirect a client to a more complex location than provided by a single 'uri' variable.

Comments?

EHL

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Manger, James H
> Sent: Tuesday, October 27, 2009 3:52 PM
> To: [email-masked]
> Subject: RE: host-meta: template syntax hassles
> 
> One solution (for simple, but correct, URI templates for common
> situations in host-meta) is to define more variables.
> 
> For instance, in addition to 'scheme', 'authority', 'path', 'query'...
> offer the following variables:
>
> 'toDir' — the URI up to, but excluding, the last '/' in the path
> 'afterDir' — the URI from the last segment of the path to the end, excluding the fragment
> 'toExt' — the URI up to, but excluding, the last '.' in the last segment of the path (or to the end of the path if there is no such dot)
> 'toPath' — the URI up to the end of the path
> 'afterPath' — the URI from after the path to the end, excluding the fragment
> 'toQueryPlus' — the URI excluding any fragment, followed by '&' if there is a query string or '?' otherwise (ie ready for a new query parameter to be appended)
> 'beforeHost' — the URI up to, but excluding, the host
> 'fromHost' — the URI from the host to the end, excluding the fragment
> 
> Template examples:
> {+toExt}.xrd{+afterPath} — replace, say, .html extension with .xrd to get metadata
> {+toQueryPlus}_=meta — add a query parameter named “_” with a value “meta” to get metadata
> {+toDir}/.meta/{+afterDir} — metadata is in a special .meta/ subdirectory of each directory
> {+toPath};meta{+afterPath} — append “;meta” to the path to get the metadata
> {+beforeHost}meta.{+fromHost} —metadata is hosted on a sub-domain
> 
> The to/after (and before/from) pairs basically offer easy access to
> different points in the URI to insert a new element. I think these
> examples are fairly simple ways to implement common URI manipulations
> safely.
> 
> James Manger
> [email-masked]
> Identity and security team — Chief Technology Office — Telstra

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 9 Nov 2009 13:27:06 +1100

> the currently proposed template vocabulary..
> should be made even less expressive (only define 'uri')

I (somewhat reluctantly) agree, as long as the '+' operator (don't %-escape reserved chars) is removed as well.

A decent aim is to support just the simplest case now (eg <URITemplate>http://example.com/meta?u={uri}</URITemplate>), and try to be compatible with a future fully-developed URI template spec. The behaviour with unrecognised variables, and unexpected syntax is more important than the list of variables defined.

The '+' operator should NOT be defined in hostmeta (if the only variable is 'uri'). It is not necessary for the simplest case. I don't think it can be used safely with the 'uri' variable. A template like "{+uri};by" almost looks sensible, but it isn't. The ";by" suffix may be appended to the path (if there are no query params), to the last query parameter value, to the top-level domain (if the path is empty) etc.

hostmeta-02 says to ignore <Link>s containing templates with unrecognised variables, eg {blurg}. A future template spec is more likely to say to substitute an empty string "" in this situation.
Ignoring <Link>s with unrecognised variables is ok in host-meta, though just giving them a lower priority than <Link>s with known variables may be better (substituting an empty string for the unrecognised variables). Priorities add a bit more complexity, and you can have any number of <Link>s with a given relation in host-meta, so I ignoring the whole <Link> is ok.

hostmeta-02 says to ignore <Link>s containing templates with an unexpected syntax (ie containing chars not allowed in a variable name, eg {/blurg}). I agree with this (it is unclear what a future template spec will say in this case). Since I think the '+' operator does not need to be defined at this point, any link with {+uri} would also be ignored.

James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 9 Nov 2009 00:20:30 -0700

I agree. I will remove the '+' operator in the next draft.

EHL

> Sent: Sunday, November 08, 2009 6:27 PM
> Cc: [email-masked]
> I (somewhat reluctantly) agree, as long as the '+' operator (don't %-
> escape reserved chars) is removed as well.
> 
> A decent aim is to support just the simplest case now (eg
> <URITemplate>http://example.com/meta?u={uri}</URITemplate>), and try to
> be compatible with a future fully-developed URI template spec. The
> behaviour with unrecognised variables, and unexpected syntax is more
> important than the list of variables defined.
> 
> The '+' operator should NOT be defined in hostmeta (if the only
> variable is 'uri'). It is not necessary for the simplest case. I don't
> think it can be used safely with the 'uri' variable. A template like
> "{+uri};by" almost looks sensible, but it isn't. The ";by" suffix may
> be appended to the path (if there are no query params), to the last
> query parameter value, to the top-level domain (if the path is empty)
> etc.
> 
> hostmeta-02 says to ignore <Link>s containing templates with
> unrecognised variables, eg {blurg}. A future template spec is more
> likely to say to substitute an empty string "" in this situation.
> Ignoring <Link>s with unrecognised variables is ok in host-meta, though
> just giving them a lower priority than <Link>s with known variables may
> be better (substituting an empty string for the unrecognised
> variables). Priorities add a bit more complexity, and you can have any
> number of <Link>s with a given relation in host-meta, so I ignoring the
> whole <Link> is ok.
> 
> hostmeta-02 says to ignore <Link>s containing templates with an
> unexpected syntax (ie containing chars not allowed in a variable name,
> eg {/blurg}). I agree with this (it is unclear what a future template
> spec will say in this case). Since I think the '+' operator does not
> need to be defined at this point, any link with {+uri} would also be
> ignored.
> 
> 
> James Manger
> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: John Panzer <[email-masked]>
Date: Fri, 6 Nov 2009 14:04:13 -0800

I'm +1 on simplifying to 'uri' alone, because there is a fully capable
workaround (server side rewriting/redirecting) that is well understood and
is guaranteed to solve any specific problem with a small roundtrip cost.

There was very strong consensus from the discussion at IIW, which included a
large # of the people who would depend on this spec.

On Fri, Nov 6, 2009 at 1:44 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> This subject was discussed at length this week at IIW. The strong consensus
> was that since the currently proposed template vocabulary isn't expressive
> enough, it should be made even less expressive (only define 'uri') and not
> more expressive (see one proposal below). The main argument were:
>
> - A future (richer) template syntax will address empty variables and the
> proper assembling of URI components together. When it becomes available,
> host-meta could be updated to define the full set of variables to support
> such common transformations.
>
> - Any vocabulary breaking the context URI into parts will need a
> complimentary method for applying links to resource subsets (at least based
> on the URI scheme). For example, it is not likely that a single template
> (using variables other than 'uri') will be able to properly address both
> 'http' and 'xmpp' URI transformation.
>
> The second point is the most important in my view since it requires
> extending the proposed document format to directly support describing
> subsets of resources. I am more inclined to reduce the vocabulary to a
> single 'uri' variable than extend both the vocabulary and schema to support
> richer scheme or pattern specific transformation.
>
> Since host-meta allows protocols to define their own 'rel'-specific
> template syntax and vocabulary, individual protocols with such needs will
> still be able to make use of the framework. In addition, servers can always
> use a simple redirection script to redirect a client to a more complex
> location than provided by a single 'uri' variable.
>
> Comments?
>
> EHL
>
>
> > 'toExt' — the URI up to, but excluding, the last '.' in the last segment
> of the path (or to the end of the path if there is no such dot)
> > 'toQueryPlus' — the URI excluding any fragment, followed by '&' if there
> is a query string or '?' otherwise (ie ready for a new query parameter to be
> appended)

-- 
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: Breno <[email-masked]>
Date: Sat, 7 Nov 2009 21:06:20 -0800

+1

The simpler syntax will allow us to get this done quicker and will not
commit us to a complex syntax. Server-side re-writing can keep us going
until we know exactly what syntax we want, with the hindsight of practical
deployment experience.

On Fri, Nov 6, 2009 at 2:04 PM, John Panzer <[email-masked]> wrote:

> There was very strong consensus from the discussion at IIW, which included
> a large # of the people who would depend on this spec.
>
>> This subject was discussed at length this week at IIW. The strong
>> consensus was that since the currently proposed template vocabulary isn't
>> expressive enough, it should be made even less expressive (only define
>> 'uri') and not more expressive (see one proposal below). The main argument
>> were:
>>

-- 
Breno de Medeiros