Hi Mark,

On Thu, Jan 21, 2021 at 11:09:15AM +1100, Mark Nottingham wrote:
> Ben,
> 
> > On 21 Jan 2021, at 5:30 am, Benjamin Kaduk via Datatracker 
> > <[email protected]> wrote:
> > 
> > (discuss point 1)
> > Mike already filed https://github.com/quicwg/base-drafts/issues/4761
> > and I think we can keep the discussion there.
> > But to reiterate, we reference [SEMANTICS] for certificate validation
> > and use in determining authority for the "https" scheme, yet the
> > additional prose discussion we offer (with CN-ID and DNS-ID as the
> > certificate fields to validate against, though not by that name) does
> > not match what's currently present in [SEMANTICS].  Discussion so far on
> > the linked issue against [SEMANTICS] suggests that [SEMANTICS] will
> > change, but we should not go forward with this document until we've
> > resolved the disparity.
> 
> The only situation where that's useful is if you believe certificate 
> validation should operate in a different fashion for HTTP/3 from other 
> versions of the protocol; is that the case?

Well ... that depends on whether HTTP certificate validation is intended to
change from its historical behavior (which is what the current state of
[SEMANTICS] says).

I'm thinking about this from the angle of "we currently are in conflict
with [SEMANTICS], which is an internal inconsistency" and so we can't
publish.  If we wish to defer to [SEMANTICS], whatever it says, then we
would seem to fall under "has a normative reference to a work not at a
similar level of maturity" ... and we still can't publish.  Once we (I
assume) confirm that [SEMANTICS] is not actually intending to drastically
change how HTTP certificate validation works, then we're set.  That's all I
meant to imply.

> >  (One might also wonder whether we need to
> > duplicate the content ourselves or should just reference the other
> > document(s).)
> 
> If the content is indeed the same, I hope we can agree that it shouldn't be 
> duplicated; having every version of HTTP re-specify this isn't really 
> workable.

That would be my preference, yes, though I cannot speak for anyone else,
and I could perhaps imagine an argument being made that there is value in
repeating aspects of it in this document.

Thanks,

Ben

Reply via email to