Merge pull request #619 from w3c/wilaw-patch-2

Add notes on receiver-side stream availability

index.bs

@@ -994,11 +994,17 @@ these steps.
 : <dfn for="WebTransport" attribute>incomingBidirectionalStreams</dfn>
 :: Returns a {{ReadableStream}} of {{WebTransportBidirectionalStream}}s that have been
    received from the server.
+
+   Note: Whether the incoming streams already have data on them will depend on server behavior. 
+
    The getter steps for the `incomingBidirectionalStreams` attribute SHALL be:
      1. Return [=this=]'s {{[[IncomingBidirectionalStreams]]}}.
 : <dfn for="WebTransport" attribute>incomingUnidirectionalStreams</dfn>
 :: A {{ReadableStream}} of unidirectional streams, each represented by a
    {{WebTransportReceiveStream}}, that have been received from the server.
+
+   Note: Whether the incoming streams already have data on them will depend on server behavior. 
+
    The getter steps for `incomingUnidirectionalStreams` are:
      1. Return [=this=].{{[[IncomingUnidirectionalStreams]]}}.
 
@@ -1110,6 +1116,8 @@ the application will receive the number of streams it anticipates.
    stream.  Note that the mere creation of a stream is not immediately visible to the peer until
    it is used to send data.
 
+   Note: There is no expectation that the server will be aware of the stream until data is sent on it.
+
    When `createBidirectionalStream` is called, the user agent MUST run the
    following steps:
 
@@ -1148,6 +1156,8 @@ the application will receive the number of streams it anticipates.
    that the mere creation of a stream is not immediately visible to the server until it is used
    to send data.
 
+   Note: There is no expectation that the server will be aware of the stream until data is sent on it.
+
    When `createUnidirectionalStream()` method is called, the user agent MUST
    run the following steps:
      1. Let |transport| be [=this=].