Re: AD review of draft-ietf-httpbis-expect-ct-07

Hi Emily,

> On 29 Oct 2018, at 02:53, Emily Stark <estark@google.com> wrote:
> 
> 
> 
>> On Wed, Sep 5, 2018 at 7:14 AM Alexey Melnikov <alexey.melnikov@isode.com> wrote:
>> Hi Emily,
>> Sorry for the slow response:
>> 
>> On 07/08/2018 20:38, Emily Stark wrote:
>> > Thanks for the feedback! I've addressed this
>> > in https://github.com/httpwg/http-extensions/commit/c2ae923f03a25432c145292b0ceda5f99f750e22,
>> > with a couple clarifications inline.
>> > 
>> > On Tue, Jul 31, 2018 at 6:06 AM Alexey Melnikov
>> > <alexey.melnikov@isode.com <mailto:alexey.melnikov@isode.com>> wrote:
>> > 
>> >     Hi,
>> > 
>> >     The document is well written, but I have a short list of issues I
>> >     would like to discuss:
>> > 
>> >     2.1.  Response Header Field Syntax
>> > 
>> >        Expect-CT           = #expect-ct-directive
>> >        expect-ct-directive = directive-name [ "=" directive-value ]
>> >        directive-name      = token
>> >        directive-value     = token / quoted-string
>> > 
>> >                   Figure 1: Syntax of the Expect-CT header field
>> > 
>> >        Optional white space ("OWS") is used as defined in Section 3.2.3 of
>> > 
>> >     I don't see "OWS" used above. Should it be used around the "="
>> >     character?
>> > 
>> >     It looks like you've copied syntanx from RFC 6797, which used old
>> >     HTTP ABNF with "implied *LWS" rule.
>> >     So you need to update it to explicitly insert OWS. (It is already a
>> >     part of #expect-ct-directive construct though.)
>> > 
>> > This was leftover from mashing up RFC 6797 and 7469, and I think it's
>> > actually just not needed at all anymore (no OWS is intended around the "=").
>> 
>> Ok with me, as long as the WG is happy with this.
>> > 
>> >     2.1.1.  The report-uri Directive
>> > 
>> >     The first mention of HSTS in Section2.1.1 needs a reference to
>> >     [RFC6797].
>> > 
>> > 
>> >        UAs SHOULD limit the rate at which they send reports.  For example,
>> >        it is unnecessary to send the same report to the same "report-uri"
>> >        more than once.
>> > 
>> >     "More than once" in which period. Ever? I think you need to
>> >     elaborate/clarify here.
>> > 
>> > 
>> >     In Section 3.1:
>> > 
>> >          *  The "serialized_sct" key, with a string value.  If the value of
>> >              the "version" key is "1", the UA MUST set this value to the
>> >              base64 encoded [RFC4648] serialized
>> > 
>> >     Which base64 alphabet? There is one in section 4 and another one in
>> >     section 5 of that RFC.
>> > 
>> > Is this really needed? Happy to include it for clarity's sake, but
>> > Section 5 of RFC 4648 already says:
>> > 
>> > This encoding may be referred to as "base64url".  This encoding
>> > should not be regarded as the same as the "base64" encoding and
>> > should not be referred to as only "base64".  Unless clarified
>> > otherwise, "base64" refers to the base 64 in the previous section.
>> 
>> I prefer to be explicit, as there is big variety of things in use.
>> 
> 
> Sure -- addressed in https://github.com/httpwg/http-extensions/commit/94f47313b45538548830fcf253ed6e70eb1fbe97. I'll publish a new version after addressing some more review comments.

Sounds good. You might be unable to post new drafts before next Monday (pre-IETF meeting draft posting blackout), but I can authorise an exception. If you want to post new draft before Monday, send me .txt/.xml.
>  
>> 
>> Please post a new version at your convenience and I will ask IESG to
>> review it.
>> 
>> Best Regards,
>> Alexey