Quoting from the same RFC2109 you read:
* A Set-Cookie from request-host x.foo.com for Domain=.foo.com would
subdomain.example.com can set a cookie for
.example.com. So far so good.
The following rules apply to choosing applicable cookie-values from
among all the cookies the user agent has.
The origin server's fully-qualified host name must domain-match
the Domain attribute of the cookie
So do we have a domain-match?
* A is a FQDN string and has the form NB, where N is a non-empty name
string, B has the form .B', and B' is a FQDN string. (So, x.y.com
domain-matches .y.com but not y.com.)
example.com wouldn't domain-match
.example.com according to the definition. But
www.example.com (or any other "non-empty name" in the domain) would. This RFC is in theory obsoleted by RFC2965, which dictated things about forcing a leading dot for domains on
More important, as noted by @Tony, is the real world. For a glimpse into what actual user agents are doing, see
Firefox 3's nsCookieService.cpp
For perspective into what actual sites are doing, try playing with
--debug to see what's going on.
You'll likely find that in fact most sites are using some combination of
Set-Cookie from the older RFC spec with "Host" values, implicitly without a leading dot (as twitter.com does) or setting Domain values (with a leading dot) and redirecting to a server like
www.example.com (as google.com does).