Code change:
8.6. Cookies do not provide integrity guarantees for sibling domains (and <del> their subdomains).  For example, consider foo.example.com and bar.example.com.  The foo.example.com server can set a cookie with a Domain attribute of "example.com" (possibly overwriting an existing "example.com" cookie set by bar.example.com), and the user agent will include that cookie in HTTP requests to bar.example.com.  In the worst case, bar.example.com will be unable to distinguish this cookie from a cookie it set itself.  The foo.example.com server might be able to leverage this ability to mount an attack against bar.example.com. </del> <ins> their subdomains).  For example, consider foo.site.example and bar.site.example.  The foo.site.example server can set a cookie with a Domain attribute of "site.example" (possibly overwriting an existing "site.example" cookie set by bar.site.example), and the user agent will include that cookie in HTTP requests to bar.site.example. In the worst case, bar.site.example will be unable to distinguish this cookie from a cookie it set itself.  The foo.site.example server might be able to leverage this ability to mount an attack against bar.site.example. </ins> Even though the Set-Cookie header supports the Path attribute, the Path attribute does not provide any integrity protection because the user agent will accept an arbitrary Path attribute in a Set-Cookie header.  For example, an HTTP response to a request for <del> http://example.com/foo/bar can set a cookie with a Path attribute of </del> <ins> http://site.example/foo/bar can set a cookie with a Path attribute of </ins> "/qux".  Consequently, servers SHOULD NOT both run mutually distrusting services on different paths of the same host and use cookies to store security-sensitive information. An active network attacker can also inject cookies into the Cookie <del> header sent to https://example.com/ by impersonating a response from http://example.com/ and injecting a Set-Cookie header.  The HTTPS server at example.com will be unable to distinguish these cookies </del> <ins> header sent to https://site.example/ by impersonating a response from http://site.example/ and injecting a Set-Cookie header.  The HTTPS server at site.example will be unable to distinguish these cookies </ins> from cookies that it set itself in an HTTPS response.  An active network attacker might be able to leverage this ability to mount an <del> attack against example.com even if example.com uses HTTPS </del> <ins> attack against site.example even if site.example uses HTTPS </ins> exclusively. Servers can partially mitigate these attacks by encrypting and signing the contents of their cookies.  However, using cryptography does not mitigate the issue completely because an attacker can replay <del> a cookie he or she received from the authentic example.com server in </del> <ins> a cookie he or she received from the authentic site.example server in </ins> the user's session, with unpredictable results. Finally, an attacker might be able to force the user agent to delete

Related discussion:
text: This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.