[domainrep] Draft response set - further questions

[Steve Allam <[e-mail]>]

All,

Back at the Paris meeting, I promised that I would complete a draft 
vocab (now response set) and also some sort of primer for people 
thinking of implementing the standard.

I regret that this has taken me longer than I had planned, but I am 
making good progress, and should be able to post something in a few more 
days.

I do have some further questions, which I thought rather than direct at 
individuals, I would address to the list.

The draft states that a reputation server using the repute framework 
will make available a template at a well-known location, thus on one of 
our servers, you would be able to find the template at:

    http://tsserver.com/.well-known/repute-template

The template itself contains the URI-TEMPLATE for the reputation 
service.  The issue/question I have is with the template - I was hoping 
that URI-TEMPLATE defines a mechanism for quite detailed templating 
including mandatory and optional parameters, but find that it (seems to) 
stop short on that.

The issue I am having is that our reputation server currently supports 
two queries (assertions in repute speak), which require different 
parameters, some of which are mandatory, others are optional.  In order 
to provide a single template which covers both queries, it is not 
possible to cover this nuance, as uri-template only allows for a string 
of optional query components.  Here is an example:

First query would be:
http://tsserver.com/check_sender?i=1.1.1.1&s=[e-mail]&r=[e-mail]
Second:
   http://tsserver.com/check_ip?i=1.1.1.1

Both have additional optional parameters.  However, to represent these 
as a single template is not great:

   {scheme}://tsserver.com/{assertion}{?i,s,r}
    - this covers both, but gives the impression that both assertions 
will be happy to receive all three (optional) parameters, whereas in 
fact one would ignore 's' and 'r' and the other would fail if 's' and 
'r' were not supplied.

As I understand it, when parsing the template, the client is obliged to 
supply those parameters that it has available, rather than all 
parameters - again, there is no separation between mandatory and 
optional parameters.

This makes the template system much less useful than it could be, and in 
our case, doesn't help the client.  So I have two issues really:

1.  How to 'split' the template to give a different response per 
assertion, so that the correct parameter list can be given for each, like:
      {scheme}://tsserver.com/check_ip{?i}
      {scheme}://tsserver.com/check_sender{?i,s,r}

2.  How to tell the client about optional and mandatory parameters, - 
maybe this actually means the client implementor needs to refer to the 
implementation guide and not rely on the template at all, which beggers 
the question - why have the template??
I wondered about the validity of:

      {scheme}://tsserver.com/check_sender{?i,s,r}{&v,f}
  - to try and show that i,s, and r are mandatory and that v,f are 
optional - this is as NOT specified in the URI-TEMPLATE, the use of {&} 
is a continuation or further optional params, after a literal component, 
such as {?i}&app=test{&v}


Comments or advice please!


Regards,

Steve