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

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.


Please post a new version at your convenience and I will ask IESG to
review it.

Best Regards,
Alexey

Received on Wednesday, 5 September 2018 14:22:59 UTC