On Fri, 5 Jul 2019 11:44:38 +0000 Rob Stradling <[email protected]> wrote:
> James Manager commented on this PR [1]: > > "The log parameters are not URLs, but URL templates. > The variables that can appear in the templates need to be defined as > well. That is, 'first', 'second', 'hash', 'start, and 'end' for > various templates. > Otherwise the spec is still forcing URL structure on servers (ie > variables MUST be querystring fields with these given names)." > > How do folks feel about this? I'm opposed to using URL templates, as it would increase client complexity by forcing them to include template interpolation logic. This WG has already reached consensus that BCP 190 compliance is unnecessary for CT, as years of real-world experience with RFC6962 deployment has showed that no log operator needs the additional flexibility that BCP 190 aims to provide. I think we should go further and say that BCP 190 compliance is detrimental to CT, as we've explored several options to add compliance and they all make CT worse - by *reducing* flexibility for log operators in a way that actually causes them problems (well-known), increasing the load on logs (directories), or by adding complexity to clients (URL templates). I doubt that the intent of BCP 190 was to make protocols worse. I hope we can move forward without BCP 190 compliance in CT. Regards, Andrew _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
