Re: [Ppm] Versioning for DAP drafts

We've discussed this a bit before, in issue #61 [1]. At that time, ekr and
Martin Thomson pointed us to the precedent of ACME. In particular, we can
examine how Let's Encrypt handled the migration from what they call ACME v1
(implementing a draft of ACME from before it was published) to ACME v2
(mostly implements RFC 8555) [2]. The salient bit is that ACME v1 was (long
since deprecated and turned off) served from
https://acme-v01.api.letsencrypt.org/directory and ACME v2 is served from
https://acme-v02.api.letsencrypt.org/directory.

So basically: don't do anything "in-band" in the protocol to handle
versioning. Instead leave it up to deployments to serve different API
versions from different subdomains or different paths relative to whatever
domain they use.

Perhaps someday, the IETF will take on HTTP service discovery, and
versioning might be a key feature of such an effort. In the meantime, I am
wary of the PPM WG taking on that rather difficult problem.

Tim

[1]: https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/61
[2]: https://letsencrypt.org/docs/acme-protocol-updates/
[3]: https://divviup.org

On Wed, Aug 3, 2022 at 12:10 PM Christopher Patton <cpatton=
40cloudflare.com@dmarc.ietf.org> wrote:

> HI all,
>
> As we are in the midst of considering changes for DAP-02, some
> implementers (myself included) are finding themselves in the position of
> needing to support multiple drafts simultaneously. As such, I think it's
> time that we consider what our needs are for maintaining interop with older
> drafts.
>
> One option for deployments is to "lock" the Aggregator endpoints to
> specific drafts. For example, the Leader's base URL might be
> dap-01.leader.example.com, indicating that the leader supports DAP-01
> only. One downside is that this makes determining whether a peer speaks a
> given version happens out-of-band. I imagine this might lead to failure
> modes that are hard to diagnose.
>
> After kicking this round with a few people off-list, here are a few
> options:
> 1. We could version the MIME types for each of the messages. E.g., instead
> of "application/dap-report" (see [1]) we could have
> `application/dap-02-report".
> 2. We could send the version in a separate HTTP Header, e.g.,
> "DAP-Version: draft-02".
> 3. We could version the HTTP endpoints in-band. E.g., instead of POSTing
> reports to "/upload", clients would POST to "/02/upload".
> 4. We could encode the version number in the message payload itself.
>
> Thoughts on these options? Any alternatives?
>
> Best,
> Chris P.
>
>
> [1]
> https://ietf-wg-ppm.github.io/draft-ietf-ppm-dap/draft-ietf-ppm-dap.html#name-application-dap-report-medi
> --
> Ppm mailing list
> Ppm@ietf.org
> https://www.ietf.org/mailman/listinfo/ppm
>