Change:
URL After some discussion with Max and Theresa, we believe the interface draft does not need any changes. This adds a UDP Multicast Receive protocol-specific section to outline the specific considerations for a UDP multicast receive connection.
Of course it's fantastic if we can keep things as simple as that! URL I must be missing something. E.g., from this PR: So this means that I can create a connection but never use a Send on it. Actually, I can't even use Initiate. Fine... but where in the process do I learn (or, rather, specify and then expect) that this is the case?
You need to specify a selection property requesting a unidirectional/receive connection, therefore you are aware of it when the connection is ready.
Sure, that's how I'd also do it - but that selection property doesn't exist AFAICT. So, that's the required change to the API then.
The way we are doing it is that we check if the address of the local endpoint is a mc group address. So thats where the distinction between unicast and multicast is made. If that is the case we also require the transport properties to include that the direction is unidirection receive.
Ah, sure. That makes the most sense. Still, that's also not written in the API document. I'm just saying this should be there.
Well, there is a Connection Property called "Direction of communication" (Section 5.2.13 in the API draft). Maybe this should be a Selection Property instead? Because those you have to specify before the Connection gets established. Also, do you think it's worth adding to that section that it's not supported to call Send() on a unidirectional receive Connection or Receive() on a unidirectional send Connection? Initiate() being unsupported is probably not something that applies to all unidirectional receive Connections, even though I haven't thought about use cases other than multicast yet.
Yes and yes. "Direction of communication" should be a selection property, as it's unlikely to make sense as something to change later. Also, just because that exists, there's no relationship to multicast in the text - the word "multicast" doesn't exist in the API draft right now. I'm thinking that somewhere, almost literally the statement from NAME above should be added. Something like this: If the address of the local endpoint is a multicast group address: The "Direction of communication" selection property must be set to unidirectional receive. Initiate, Send, ... (list them all here) are not supported. (whatever else should be said.)
Oh, I just realized that "Direction of communication" already is a Selection Property, so we don't need to change anything there. But yes, it probably makes sense to add a paragraph on multicast to the "Specifying Endpoints" section 5.1 in the API draft.
We did not make it a selection property, because it is not of Preference type it should be queryable and probably may change to bidi after establishment if the underlaying protocol is bi-directional it my be settable from bidi to recv to half-close connections. Yes, this is one of the properties where our categories do not work so great.
NAME - that's ok, then we leave the property type as it is.
I think this is the mapping that works best for multicast. Just to give a bit of context: First, we tried to fit multicast into Initiate() because the multicast receiver actively joins a group. However, this doesn't work for Any-source Multicast, as Initiate() requires a remote endpoint. Re-reading our definitions in the architecture draft for Listener, Connection, and so on, I think we don't need to change them, as they are already generic enough for multicast to fit in there. In the Implementation draft, at the beginning of Section 2 it says that a listener is "a passive waiting object". Here, "passive waiting" sounds a bit off to me if a listener can actively join a multicast group. So maybe we want to change that to just say that a listener is "an object that can receive incoming connections".I think this is fine besides a little nit.

Discussion:
10.3. <ins> Connectedness: Unconnected Data Unit: Datagram API mappings for Receiving Multicast UDP are as follows: Established UDP Multicast Receive connections represent a pair of specific IP addresses and ports.  The "unidirectional receive" transport property is required, and the local endpoint must be configured with a group IP address and a port. Calling "Initiate" on a UDP Multicast Receive Connection causes an immediate InitiateError.  This is an unsupported operation. Calling "InitiateWithSend" on a UDP Multicast Receive Connection causes an immediate InitiateError.  This is an unsupported operation. A UDP Multicast Receive Connection is ready once the system has received traffic for the appropriate group and port. UDP Multicast Receive Connections generate an InitiateError if Initiate is called. Once in use, UDP throws "soft errors" (ERROR.UDP(-Lite)) upon receiving ICMP notifications indicating failures in the network. LISTEN.UDP.  Calling "Listen" for UDP Multicast Receive binds a local port, prepares it to receive inbound UDP datagrams from peers, and issues a multicast host join.  If a remote endpoint with an address is supplied, the join is Source-specific Multicast, and the path selection is based on the route to the remote endpoint.  If a remote endpoint is not supplied, the join is Any-source Multicast, and the path selection is based on the outbound route to the group supplied in the local endpoint. UDP Multicast Receive Listeners will deliver new connections once they have received traffic from a new Remote Endpoint. Calling "Clone" on a UDP Multicast Receive Connection creates a new Connection with equivalent parameters.  The two Connections are otherwise independent. SEND.UDP(-Lite).  Calling "Send" on a UDP Multicast Receive connection causes an immediate SendError.  This is an unsupported operation. RECEIVE.UDP(-Lite).  The Receive operation in a UDP Multicast Receive connection only delivers complete Messages to "Received", each of which represents a single datagram received in a UDP packet.  Upon receiving a UDP datagram, the ECN flag from the IP header can be obtained (GET_ECN.UDP(-Lite)). Calling "Close" on a UDP Multicast Receive Connection (ABORT.UDP(- Lite)) releases the local port reservation and leaves the group. Calling "Abort" on a UDP Multicast Receive Connection (ABORT.UDP(- Lite)) is identical to calling "Close". 10.4. </ins> The mapping of a TLS stream abstraction into the application is equivalent to the contract provided by TCP (see tcp), and builds upon many of the actions of TCP connections.

Implementations do not need to wait to receive "close_notify" before delivering the "Closed" event. <del> 10.4. </del> <ins> 10.5. </ins> DTLS follows the same behavior as TLS (tls), with the notable exception of not inheriting behavior directly from TCP.  Differences

received DTLS datagram.  If a "close_notify" is received, a Message will be delivered that is marked as Final. <del> 10.5. </del> <ins> 10.6. </ins> HTTP requests and responses map naturally into Messages, since they are delineated chunks of data with metadata that can be sent over a

support multiplexing.  For HTTP/2, for example, closing the connection only closes a specific stream. <del> 10.6. </del> <ins> 10.7. </ins> QUIC provides a multi-streaming interface to an encrypted transport. Each stream can be viewed as equivalent to a TLS stream over TCP, so

Connection objects represent a single QUIC stream on a QUIC connection. <del> 10.7. </del> <ins> 10.8. </ins> Similar to QUIC (quic), HTTP/2 provides a multi-streaming interface. This will generally use HTTP as the unit of Messages over the

Connection objects represent a single HTTP/2 stream on a HTTP/2 connection. <del> 10.8. </del> <ins> 10.9. </ins> Connectedness: Connected