subdomain.example.comは、example.comが読み取ることができるCookieを設定できますか？
これを判断するのが非常に難しいとは信じられません。
RFCを読んだとしても、subdomain.example.comのサーバーがexample.comが読み取ることができるCookieを設定できるかどうかは、私にはわかりません。
subdomain.example.comは、ドメイン属性が.example.comであるCookieを設定できます。 RFC 2965は、そのようなCookieがexample.comに送信されないことを明示的に述べているようですが、Domain = example.comを設定すると、.example.comと言ったかのように、ドットが前に付加されると等しく述べています。まとめると、example.comがドメイン= example.comのCookieを設定しても、そのCookieが返されないということです。それは正しくありません。
誰もがルールが実際に何であるかを明確にすることができますか？
同じから引用 RFC2109 あなたが読んだ：
* request-Host x.foo.comからのDomain = .foo.comに対するSet-Cookieは受け入れられます 。
したがって、subdomain.example.comは.example.comのCookieを設定できます。ここまでは順調ですね。
次のルールは、ユーザーエージェントが持つすべてのCookieの中から から適切なCookie値を選択する場合に適用されます。 ドメイン選択 オリジンサーバーの完全修飾ホスト名はドメインに一致する必要があります Cookieのドメイン属性
では、ドメインマッチはありますか？
* AはFQDN文字列であり、NBという形式です。Nは空ではない名前です。 文字列、Bは.B 'の形式、B'はFQDN文字列です。 （つまり、x.y.com ドメインは.y.comと一致しますが、y.comとは一致しません。）
しかし、今ではexample.comは、定義によれば.example.comとドメイン一致しません。しかし、www.example.com（またはドメイン内の他の「空でない名前」）はそうします。このRFCは理論的には RFC2965 によって廃止され、ドメインの先頭のドットをSet-Cookie2操作に強制することについて規定しました。
@Tonyが指摘しているように、より重要なのは現実の世界です。実際のユーザーエージェントの動作の概要については、以下を参照してください。
そして
実際のサイトで何が行われているかを把握するには、--save-cookies、--load-cookies、--debugを使用してwgetで遊んでみて、何が起こっているかを確認してください。
実際、ほとんどのサイトは古いRFC仕様のSet-Cookieと "Host"値の組み合わせを使用しており、暗黙的に先頭にドットがありません（ Twitter.com のように）または（先頭にドットを付けて）ドメイン値を設定し、www.example.com（ google.com のように）のようなサーバーにリダイレクトします。
ブラウザが RFC 6265 を実装している場合、この時点で最新のブラウザはこれを実行する必要があるため、.example.comは先頭のドットを無視し（セクション5.2.3）、Cookieはネイキッドドメインとすべてのサブドメインに送信されます。
古いブラウザからのトラフィックが多い場合は、この動作に依存しないでください。このRFCは2011年までさかのぼります。
それは不可能であるべきです。しかし、あなたが言ったように、これは広く文書化された標準ではないので、それはあなたが使用しているソフトウェアの部分に依存します。
最新のブラウザのほとんどは、定義された「Webセキュリティモデル」に準拠しています。このモデルは、Cookieのようなもの（具体的には、どのようにして特定のWebサイトに送り返されるか）に関して、セキュリティに関するブラウザの動作を効果的に管理します。このモデルには、「ブラウザーは、Cookieを設定していないドメイン名にCookieを送信しない」というルールもあります。
そうは言っても、domain.comはjs.domain.comにCookieを設定できるはずです。ただし、js.domain.comは、それ自体にのみCookieを設定できます。ただし、これはすべて、使用しているブラウザによって異なります。