Would it be sufficient to provide a URL template for each log, instead of a 
directory URL?
Possible text:

  The address of a log is defined by a URL template [RFC6570] that MUST include
  the following variables: action, first, second, hash, start, end.

  'action' identifies the client message, such as 'submit-entry' or 'get-sth'.
  'first' and 'second' are tree sizes. 'hash' is a base64-encoded v2 leaf hash.
  'start' and 'end' are 0-based entry indicies.

  Example: 
https://log.example.net/ct/v2/red/{action}{?first}{?second}{?hash}{?start}{?end}

--
James Manger

-----Original Message-----
From: Trans <[email protected]> On Behalf Of Rob Stradling
Sent: Tuesday, 25 June 2019 12:16 AM
To: Melinda Shore <[email protected]>; [email protected]
Subject: Re: [Trans] Directory instead of .well-known for URL structure

This sounds unanimous.  :-)

I'll go ahead and make this change, and I'll cancel the registration process 
for "ct" as a .well-known URI suffix.

On 24/06/2019 01:05, Melinda Shore wrote:
> On 6/23/19 3:28 PM, Martin Thomson wrote:
>> I agree with Jacob here. As I have expressed in the past, I believe 
>> that this is a better design than the well-known prefix.
> 
>> On Fri, Jun 21, 2019, at 08:33, Jacob Hoffman-Andrews wrote:
>>> The latest draft adopts a /.well-known/ path for CT as a way to get
>>>   around BCP 190 (URI Design and Ownership:
>>> https://tools.ietf.org/html/bcp190#section-3).
>>>
>>> Personally I think BCP 190 makes it needlessly painful to specify 
>>> HTTP-based APIs using techniques that are very common among 
>>> practitioners. However, given that it is still considered best 
>>> practice for IETF documents, I propose that CT should use a 
>>> different workaround, one used very successfully by ACME: Directory 
>>> URLs.
> 
> I have a fairly profound dislike for BCP 190, to be honest, and am in 
> agreement with the proposal.
> 
> Melinda
> 

--
Rob Stradling
Senior Research & Development Scientist
Email: [email protected]
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally privileged, 
confidential, or proprietary information. If you are not the intended 
recipient, you are not permitted to use, copy, or forward it, in whole or in 
part without the express consent of the sender. Please notify the sender by 
reply email, disregard the foregoing messages, and delete it immediately.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans

_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans

Reply via email to