Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#185 closed defect (fixed)

Don't violate BCP 190

Reported by: rlb@… Owned by: eranm@…
Priority: major Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:


BCP 190 says basically that you shouldn't restrict the structure of URIs in a
specification, to allow server operators flexibility in how they deploy
HTTP-based services. This document runs directly counter to that advice, by
hard-coding URL paths.

The simplest solution here is probably to do what ACME does and have a
"directory" endpoint that tells you the URLs for the other endpoints.

Change History (6)

comment:1 Changed 6 years ago by rob.stradling@…

  • Component changed from client-behavior to to-be-decided

comment:2 Changed 5 years ago by eranm@…

From an in-person discussion and trans wg meeting:
Having a 'directory' endpoint may not be that useful because:
(1) Clients already need a fairly decent amount of metadata for communicating with a log, URI structure could be one of those. Dynamically discovering it won't enable that much flexibility.
(2) From V1 deployment we have not encountered any deployment problem with the current URI structure, since CT logs are not typically hosted with other web systems.

Two ways to address this (other than having a directory endpoint):

  • Explain why it's OK not to comply with BCP 190 (the rationale listed above).
  • Remove the 'ct/v2' portion from URIs specified in the document.

I have a preference for the latter but happy either way.

A PR implementing the first approach is

comment:3 Changed 5 years ago by eranm@…

  • Component changed from to-be-decided to rfc6962-bis
  • Owner changed from draft-ietf-trans-rfc6962-bis@… to eranm@…
  • Status changed from new to assigned

comment:4 Changed 5 years ago by eranm@…

  • Milestone set to review

comment:5 Changed 5 years ago by melinda.shore@…

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:6 Changed 5 years ago by melinda.shore@…

(Note that this isn't "fixed" in the sense that the protocol has not changed, but that some explanatory text has been added to the document)

Note: See TracTickets for help on using tickets.