Original text:
The Domain attribute specifies those hosts to which the cookie will be sent.  For example, if the value of the Domain attribute is <del> "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com.  (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.)  If the server omits the Domain attribute, the user agent will return the cookie only to the origin server. </del>  WARNING: Some existing user agents treat an absent Domain attribute as if the Domain attribute were present and contained the current <del> host name.  For example, if example.com returns a Set-Cookie header </del>  without a Domain attribute, these user agents will erroneously send <del> the cookie to www.example.com as well. </del>  The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server.  For example, the user agent will accept a cookie with a <del> Domain attribute of "example.com" or of "foo.example.com" from foo.example.com, but the user agent will not accept a cookie with a Domain attribute of "bar.example.com" or of "baz.foo.example.com". </del>  NOTE: For security reasons, many user agents are configured to reject Domain attributes that correspond to "public suffixes".  For example,

Reviewer comments:
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.

Revised text:
The Domain attribute specifies those hosts to which the cookie will be sent.  For example, if the value of the Domain attribute is  <ins> "site.example", the user agent will include the cookie in the Cookie header when making HTTP requests to site.example, www.site.example, and www.corp.site.example.  (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.)  If the server omits the Domain attribute, the user agent will return the cookie only to the origin server. </ins> WARNING: Some existing user agents treat an absent Domain attribute as if the Domain attribute were present and contained the current  <ins> host name.  For example, if site.example returns a Set-Cookie header </ins> without a Domain attribute, these user agents will erroneously send  <ins> the cookie to www.site.example as well. </ins> The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server.  For example, the user agent will accept a cookie with a  <ins> Domain attribute of "site.example" or of "foo.site.example" from foo.site.example, but the user agent will not accept a cookie with a Domain attribute of "bar.site.example" or of "baz.foo.site.example". </ins> NOTE: For security reasons, many user agents are configured to reject Domain attributes that correspond to "public suffixes".  For example,