- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 18 Jul 2017 17:09:38 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Eric Rescorla <ekr@rtfm.com>, Patrick McManus <mcmanus@ducksong.com>, Emily Stark <estark@google.com>, Nick Sullivan <nicholas.sullivan@gmail.com>, Ilari Liusvaara <ilariliusvaara@welho.com>, Erik Nygren <erik@nygren.org>, Piotr Sikora <piotrsikora@google.com>, Ryan Hamilton <rch@google.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
I think that you might want to say that the client might want to stipulate some additional constraints on the validation of the certificate before it chooses not to make the request. This will be up to client policy. On 18 July 2017 at 17:01, Mark Nottingham <mnot@mnot.net> wrote: > >> On 18 Jul 2017, at 4:59 pm, Eric Rescorla <ekr@rtfm.com> wrote: >> >> This language seems a bit confusing. Usually, MUSTs are intended to impose requirements on the server, but there's no way for the server to know if they are meeting client expectations. One could of course invert this to make it a requirement on clients, but then it's just a tautology that the client has to enforce client policies. > > Yeah. Like I said, we don't usually specify this sort of detail in HTTP-land, hence the vagueness. We can change that, of course. > > -- > Mark Nottingham https://www.mnot.net/ > > >
Received on Tuesday, 18 July 2017 15:10:06 UTC