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

[Tim Geoghegan <[e-mail]>]

Hello all,

Late last year, the PPM chairs requested that the HTTP directorate review
DAP's utilization of HTTP. httpdir's Mark Nottingham was kind enough to
share the early review toward the end of the year ([1]), which has been
discussed in some detail in the list ([2]).

We've already taken some changes to DAP suggested in the review, but now
there's a few outstanding items where I (in my capacity as an editor of
DAP) feel there isn't yet sufficient WG consensus to either motivate a
change or determine which change we should choose. What I want to do here
is surface a few specific questions among the various things discussed in
[2] and get clear consensus to move forward with.

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

# 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**.

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

Looking forward to hearing from you all,
Tim

[1]:
https://datatracker.ietf.org/doc/review-ietf-ppm-dap-09-httpdir-early-nottingham-2023-12-29/
[2]: https://mailarchive.ietf.org/arch/msg/ppm/JaaD-6XqGP8GclS26-mtAC77tX8/
[3]: https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/pull/543
[4]:
https://datatracker.ietf.org/doc/html/draft-ietf-ppm-dap-09#name-resource-uris
[5]: https://datatracker.ietf.org/doc/html/rfc6570
[6]: https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.1