Re: [quicwg/base-drafts] Massive batch of probably-editorial nits (#3805)

[Mike Bishop <[e-mail]>]

@MikeBishop commented on this pull request.



> +: When used without qualification, the tuple of IP version, IP address, and UDP
+  port number that represents one end of a network path.

QUIC is defined (per invariants) to run over UDP.  I don't think including a constant in the definition of the tuple gains you any uniqueness, and stating that it's a UDP port already emphasizes what the protocol has to be.

> +  endpoint.  Each endpoint sets one or more values for its peer to include in
+  packets sent towards the endpoint.

That's workable, but the point of my edit is not to imply the CID is 1:1 with the connection itself.  Perhaps we use similar words to the version change being proposed, "Opaque bytes that permit the recipient to associate a packet with a connection.  Each endpoint can supply one or more sequences of bytes for its peer to use in sending packets."?

>  
 An endpoint SHOULD copy the error code from the STOP_SENDING frame to the
 RESET_STREAM frame it sends, but MAY use any application error code.  The
 endpoint that sends a STOP_SENDING frame MAY ignore the error code carried in
 any RESET_STREAM frame it receives.
 
-If the STOP_SENDING frame is received on a stream that is already in the
-"Data Sent" state, an endpoint that wishes to cease retransmission of
-previously-sent STREAM frames on that stream MUST first send a RESET_STREAM
-frame.

I think the real point is that you don't have to send a RESET_STREAM immediately if you've already sent everything and closed the stream, but you SHOULD send a RESET_STREAM if any data later gets lost.  See if this new text works better.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3805#discussion_r448998529