Re: [art] On BCP 190

[Jacob Hoffman-Andrews <[e-mail]>]

I'd like to reiterate that CT does not squat on namespace elements, like
favicon or robots.txt. CT logs are specified by origin *and path prefix*:

https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-31.txt
>   The <log server> prefix, which is one of the log's parameters, MAY
>   include a path as well as a server name and a port.

So CT is totally fine with regards to this part of BCP 190 Section 2.3
<https://tools.ietf.org/html/bcp190#section-2.3>:

>    For example, an application ought not specify a fixed URI path
>   "/myapp", since this usurps the host's control of that space.

It's this part of BCP 190 Section 2.3 that is causing the issue:

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

To be clear, the "whatever" in this case is referred to as <log server> in
CT, and is discovered via the known logs list (
https://www.certificate-transparency.org/known-logs) and browser CT
programs.

On Tue, Jul 23, 2019 at 11:14 AM Mark Nottingham <[e-mail]> wrote:

> common practices for an API that's implemented once and deployed on one
> server that's under the control of the designer (e.g., api.twitter.com)
> are often not appropriate for an API that is implemented many times,
> deployed on many servers owned by different people, and sometimes evolved
> independently
>

This is a valuable and subtle point, and I think the crux of the matter.
It's actually surprisingly rare to see an HTTP API that is designed to be
implemented many times. But if you look at those that are (RFC 7482, RFC
7808, RFC 8040, Mastodon, and Git, for example), what they have in common
is that they are all organized around a hostname and path prefix, just like
CT.