[art] Against BCP 190

[Rob Stradling <[e-mail]>]

During IESG review of RFC6962-bis (Certificate Transparency Version 
2.0), BCP 190 is creating significant problems in standardizing 
HTTP-based APIs.  Specifically, this paragraph of section 2.3 
(https://tools.ietf.org/html/bcp190#section-2.3):

    Specifying a fixed path relative to another (e.g., {whatever}/myapp)
    is also bad practice (even if "whatever" is discovered as suggested
    in Section 3); while doing so might prevent collisions, it does not
    avoid the potential for operational difficulties (for example, an
    implementation that prefers to use query processing instead, because
    of implementation constraints).

This paragraph should be struck.  It is out of date, since all modern 
web servers can trivially rewrite paths to query components and back 
again.  It also encourages inserting levels of indirection that add 
complexity and bugs.

In RFC6962, all paths are specified relative to a "log server" prefix 
that can contain a path as well as a server name and a port:

   POST https://<log server>/ct/v1/add-chain
   GET https://<log server>/ct/v1/get-sth
   GET https://<log server>/ct/v1/get-entries?start=1000&end=2000
   … 5 more request types defined similarly ...

This version of CT, which preceded BCP 190, has been in production use 
for several years, with multiple independent implementers on both the 
server side and the client side.  There have been no complaints that 
specifying paths in these ways is at all difficult or interferes with 
operation of other software.

A similar problem arose during ACME standardization.  At first it was 
solved by defining a "straight through" issuance path where each step 
provided a URL for the next step.  This was abandoned because there are 
plenty of issuance cases that are not straight-through - for instance, 
revocation.  Now ACME indirects all requests through a "directory" JSON 
object that maps, e.g. "newAuthz" to "https://example.com/newAuthz". 
This works moderately well, but adds complexity, increases the total 
number of requests, and as it turns out, may have bugs 
(https://www.rfc-editor.org/errata_search.php?eid=5771).

For 6962-bis, the TRANS WG has cycled through three different attempts 
to work around BCP 190: a .well-known path prefixing all the paths 
defined by the API, a directory, and treating the entire set of request 
types as parameters to a log definition delivered out of band.  All were 
found to be unsatisfactory.  The affected URI owners (log operators) are 
being prevented by BCP 190 from doing what they would prefer to do with 
their URI space, which is to use URIs constructed in the same manner as 
RFC6962 (with "/ct/v1" changed to "/ct/v2").

BCP 190 is standing in the way of standardizing simple, sensible HTTP 
APIs and should be amended.

Thanks,

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited