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

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.


>
> Please post a new version at your convenience and I will ask IESG to
> review it.
>
> Best Regards,
> Alexey
>