Original text:
clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it.  5. HTTP uses

Reviewer comments:
This is how it works in practice. RFC 6125 is due for an update, I guess. iPAddress subjectAltName has been supported for years and years, but it never managed to capture it properly. This is definitely a big change in that it now outlaws CN-ID. And the definition of IP-ID here is probably overreach, but I don't see how we can avoid that. I don't want to update RFC 6125 here (as much as it needs updating), so making the definition standalone seemed like the right way to handle it.
Discovered via a question NAME asked; it appears that 8aa1781d4fa7d25ab946f6cb1dd1b337435e0a17 made the change to require looking for URI-IDs in the certificate and I don't see any follow-up discussion on that in . However, I've never seen a certificate that offers a URI-ID for an HTTP endpoint. Shouldn't this be a DNS-ID to match current usage? Or perhaps either, with URI-ID preferred, if we believe that's the future?
Er, right, my mistake -- I was trying to describe it as verifying a URI as input, not as looking only at the certificate field for URI-ID. It should either be left unsaid, because it is defined by that RFC, or possibly specify DNS-ID with maybe URI-ID as a backup?
I am not entirely sure that there is need to mention URI-ID (I, for one, don't know of usage of it with HTTP; I barely know of usage of it at all). My understanding is that current practice prefers DNS-ID with a grudging tolerance for CN-ID as fallback (though there are efforts underway to fully deprecate use of CN-ID). Note also that when referencing the RFC 6125 procedures, the protocol document is expected not only to specify what name and type are to be used as input to verification, but also whether wildcard certificate are allowed. It is sometimes also useful to give instruction about what procedures are to be used for revocation checking, though 6125 does leave that explicitly out of its own scope. I am also trying to promote the definition and use of "IPADDR-ID" for the iPAddress SAN, but that's somewhat unrelated.
Do we want to state a position on adoption of URI-ID? If not, then I think we say DNS-ID and MAY consider CN-ID, plus the wildcard language. I'm not aware of anything to reference for IPADDR-ID, and this doesn't seem like the place to define it.
Please don't use CN for anything. Nor rfc822Address nor domainComponent.
I'll be happy to accept any change here that folks generally agree to, preferably in the form of a PR. I already tried just writing it myself and that's what we have now, but it's wrong because I haven't implemented this myself.
Sorry for the late comment; apparently my github notifications aren't set to send me email when a new PR references an issue I'm watching.I'll trust NAME :-)

Revised text:
clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. <ins> 4.3.5. A server that is identified using an IP address literal in the "host" field of an "https" URI has a reference identity of type IP-ID.  An IP version 4 address uses the "IPv4address" ABNF rule and an IP version 6 address uses the "IP-literal" production with the "IPv6address" option; see RFC3986.  A reference identity of IP-ID contains the decoded bytes of the IP address. An IP version 4 address is 4 octets and an IP version 6 address is 16 octets.  Use of IP-ID is not defined for any other IP version.  The iPAddress choice in the certificate subjectAltName extension does not explicitly include the IP version and so relies on the length of the address to distinguish versions; see RFC5280. A reference identity of type IP-ID matches if the address is identical to an iPAddress value of the subjectAltName extension of the certificate. </ins> 5. HTTP uses