Re: [Ppm] Seeking WG consensus on DAP changes for httpdir review

[Christopher Patton <[e-mail]>]

Hi Tim, thanks for leading this!



> # Upload request path and method
>
> Currently, report uploads consist of a PUT request to
> {leader}/tasks/{task-id}/reports. This isn't quite right because there's no
> GETtable resource that results from this. I have a PR up ([3]) which
> addresses this by hoisting the report ID into the request path and removes
> it from the request body. Another, simpler choice would be to change the
> request method to POST, note that the request is idempotent and change
> nothing else.
>
> See the linked PR for some discussion of the tradeoffs. At the moment, I'd
> say the consensus is leaning toward changing the method to POST but other
> opinions are welcome!
>

I think your first suggestion is a little tidier as it aligns with the rest
of the API, but a question: Does this add the requirement that the report
be GETtable?

Assuming it does not add any new requirements: I'd slightly favor PUT;
otherwise, I'd favor POST. In any case, POST is less invasive of a change,
so I'm fine changing to POST on that basis.


# RFC 6570 URI templates
>
> DAP defines a very simple syntax for URI templates in [4]. RFC 6570 ([5])
> defines a rich syntax for URI templates that is more than sufficient for
> DAP's needs but includes many features we wouldn't use. What we've got
> works fine so I am inclined to stick with it, but we could choose to use
> RFC 6570, too. At the moment, the consensus leans toward not doing this.
>
> Note that besides establishing consensus in favor of doing this, **we also
> would need a volunteer to make the DAP changes to adopt RFC 6570**.
>

I'm agnostic. I'd be happy to review the change if someone wants to make it.



> # Greater resource URI flexibility
>
> It was also suggested that instead of having DAP mandate specific URI
> templates, we could instead require aggregators to expose a JSON document
> which would contain URI templates, allowing individual implementations or
> deployments to use different request paths. This is akin to the directory
> resource in ACME ([6]). Personally I don't think this is necessary, and
> wouldn't want to introduce an extra HTTP roundtrip into interactions like
> report uploads. But the WG, especially members with more experience
> deploying HTTP servers than I have, should get a chance to weigh in. Once
> again, **a volunteer would be needed to design the new resource and write
> the new protocol text**. At the moment, I'd say the consensus is not to do
> this.
>

I also don't think this is needed.

Chris P.