RE: host-meta: template syntax hassles

[Eran Hammer-Lahav <eran at hueniverse.com>]

> -----Original Message-----
> From: apps-discuss-bounces at ietf.org [mailto:apps-discuss-
> bounces at ietf.org] On Behalf Of Manger, James H
> Sent: Tuesday, October 27, 2009 12:04 AM
> To: apps-discuss at ietf.org
> Subject: RE: host-meta: template syntax hassles
> 
> Eran,
> 
> > The examples are obviously limited to URI with specific
> characteristics.
> > If the presence of these examples is misleading,
> 
> host-meta is explicitly not limited to URIs with specific
> characteristics (as it covers one or more entire hosts) so I think they
> are misleading.

I will change them to be more consistent with the scope. However, it is ultimately the job of the document author to make sure the templates are compatible with the URI namespace it covers. Suggestions to attribute specific schemes or resource subsets to links have been rejected in the past as too complex and without actual use cases, so I am not inclined to complicate the overall schema.

> [It may even be potentially dangerous: attacker sends
> “http://example.com/xxx?”; to victim; victim (& server) treat it as
> equivalent to “http://example.com/xxx”;; but meta-data is retrieved from
> a different source given {+uri};meta template: from /xxx (server
> ignores unexpected “?;meta” query string in this request) vs from
> /xxx;meta (that server recognizes).]

I think this is more about poor URI and template design than a security threat. This will always be the case unless the only variable allowed is the full URI string. Protocols making security-sensitive decisions based on URI templates should watch out for such manipulations. I will add this to the security section of the spec.
 
> > I will be happy to change them to put the {uri} at the end as a query
> parameter.
> 
> We can’t have the only realistic example in the spec being {uri} as a
> query parameter. It is no use having templates in that case.
> 
> Changing the extension (*.html to *.xrd), appending “;meta” to the
> path, adding an “_about” query parameter, using a metadata.example.com
> sub-domain etc all sound like realistic choices hosts might make. The
> spec should include examples for these sorts of choices. If the
> examples are too complex then the only answer is to simplify the
> syntax, not just omit the examples.
> 
> If examples like {+scheme}://{+authority}{+path};by?{+query} and
> {+scheme}://{+authority}{+path}?{+query}&test  are too complex we need
> a simpler syntax.

I don’t think they are too complex. I will add a more extensive section with such examples. You might be right that the syntax as currently proposed might not be able to accomplish all these use cases (due to empty parameters and inability to condition the inclusion of a separator - &, ?, etc. - for non-empty parameters). Roy's proposal handles these cases but at some point it becomes obscene to copy/paste larger chunks of that work. The simplest solution would be to define a few more variables which will include the separator when not empty.

I'll give it a try in the next draft.

Thanks,

EHL