60.2) Term consistency - RID identifiers

[ajeanmahoney]

"RID identifiers" and "rid-identifier": RFC 8851 (draft-ietf-mmusic-rid) defines "RID" as "restriction identifier." Should "RID identifiers" and "rid-identifier" be "rid-ids" and "rid-id" per RFC 8851 (draft-ietf-mmusic-rid), to avoid "identifier identifier(s)"?

Justin: Should we also do RID values? "rid-ids" seems like it is still a case of "identifier identifiers".

Jean: A restriction identifier ("a=rid" attribute) contains a rid-id, which identifies a unique RTP payload configuration, and one or more "a=rid" restrictions (the term used 8851), which are semicolon-separated, parameter-value pairs.

With that in mind:

Section 5.2.1, current:

If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line for each encoding specified. The "a=rid" line is specified in [RFC8851], and its direction MUST be "send". If the application has chosen a RID value, it MUST be used as the rid-identifier; otherwise, a RID value MUST be generated by the implementation. RID values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-PeerConnection counter (see guidance at the end of [RFC8852], Section 3.3), and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extensions defined in [RFC8852], Section 3.3. If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated.

If the RtpTransceiver has a sendrecv or sendonly direction and more than one "a=rid" line has been generated, an "a=simulcast" line, with direction "send", as defined in [RFC8853], Section 5.1. The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this "m=" section.

Section 5.2.1, perhaps:

If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified "a=rid" restrictions or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line for each encoding specified. The "a=rid" line is specified in [RFC8851], and its direction MUST be "send". If the application has chosen a rid-id, it MUST be used as the rid-id; otherwise, a rid-id MUST be generated by the implementation. A rid-id MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-PeerConnection counter (see guidance at the end of [RFC8852], Section 3.3), and SHOULD be 3 bytes or less, to allow it to efficiently fit into the RTP header extensions defined in [RFC8852], Section 3.3. If no encodings have been specified, or only one encoding is specified but without an "a=rid" restriction, then no "a=rid" lines are generated.

If the RtpTransceiver has a sendrecv or sendonly direction and more than one "a=rid" line has been generated, an "a=simulcast" line, with direction "send", as defined in [RFC8853], Section 5.1. The list of "a=rid" restrictions MUST include all of the restrictions used in the "a=rid" lines for this "m=" section.

Section 5.8.3, current:

All RID values referenced in an "a=simulcast" line MUST exist as "a=rid" lines.

Section 5.8.3, perhaps:

All "a=rid" restrictions referenced in an "a=simulcast" line MUST exist as "a=rid" lines.

Section 5.11, current:

Any RTP header extensions that were negotiated should be included in the outgoing RTP streams, using the extension mapping from the remote description; if the RID header extension has been negotiated and RID values are specified, include the RID header extension in the outgoing RTP streams, as indicated in [RFC8851], Section 4.

Section 5.11, perhaps:

Any RTP header extensions that were negotiated should be included in the outgoing RTP streams, using the extension mapping from the remote description; if the "a=rid" extension has been negotiated and "a=rid" restrictions are specified, include the "a=rid" attribute in the outgoing RTP streams, as indicated in [RFC8851], Section 4.

[juberti]

I went back and looked at https://tools.ietf.org/html/draft-ietf-mmusic-rid-15, and I see there that 'rid-id' is used largely synonymously with RtpStreamId, and RID is not used.

Similar to my comment on the thread regarding a=mid and MID, I would prefer to use RID in this cluster rather than "rid-id", but whatever we choose for mmusic-rid, we should update JSEP to match (iow, update all uses of rid-id, rid-identifier, and RID value to match the selected option).

[juberti]

@ajeanmahoney, what would you recommend?

[ajeanmahoney]

@juberti Taking another crack at this:

Section 5.2.1, current:

If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line for each encoding specified. The "a=rid" line is specified in [RFC8851], and its direction MUST be "send". If the application has chosen a RID value, it MUST be used as the rid-identifier; otherwise, a RID value MUST be generated by the implementation. RID values MUST be generated in a fashion that does not leak user information ... If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated.

If the RtpTransceiver has a sendrecv or sendonly direction and more than one "a=rid" line has been generated, an "a=simulcast" line, with direction "send", as defined in [RFC8853], Section 5.1. The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this "m=" section.

Section 5.2.1, perhaps (1 para: rid-identifier -> rid-id, 2nd para: RID identifiers - RID values):

If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line for each encoding specified. The "a=rid" line is specified in [RFC8851], and its direction MUST be "send". If the application has chosen a RID value, it MUST be used as the rid-id; otherwise, a RID value MUST be generated by the implementation. RID values MUST be generated in a fashion that does not leak user information ... If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated.

If the RtpTransceiver has a sendrecv or sendonly direction and more than one "a=rid" line has been generated, an "a=simulcast" line, with direction "send", as defined in [RFC8853], Section 5.1. The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this "m=" section.

Section 5.8.3, current: Keep as-is

All RID values referenced in an "a=simulcast" line MUST exist as "a=rid" lines.

Section 5.11, current:

Any RTP header extensions that were negotiated should be included in the outgoing RTP streams, using the extension mapping from the remote description; if the RID header extension has been negotiated and RID values are specified, include the RID header extension in the outgoing RTP streams, as indicated in [RFC8851], Section 4.

Section 5.11, perhaps (RID header -> "a=rid"):

Any RTP header extensions that were negotiated should be included in the outgoing RTP streams, using the extension mapping from the remote description; if the "a=rid" extension has been negotiated and RID values are specified, include the "a=rid" attribute in the outgoing RTP streams, as indicated in [RFC8851], Section 4.

[juberti]

Section 5.2.1, perhaps (1 para: rid-identifier -> rid-id, 2nd para: RID identifiers - RID values):

If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line for each encoding specified. The "a=rid" line is specified in [RFC8851], and its direction MUST be "send". If the application has chosen a RID value, it MUST be used as the rid-id; otherwise, a RID value MUST be generated by the implementation. RID values MUST be generated in a fashion that does not leak user information ... If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. If the RtpTransceiver has a sendrecv or sendonly direction and more than one "a=rid" line has been generated, an "a=simulcast" line, with direction "send", as defined in [RFC8853], Section 5.1. The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this "m=" section.

LGTM, although the changes to the second para that you mentioned still need to be applied.

Section 5.8.3, current: Keep as-is

All RID values referenced in an "a=simulcast" line MUST exist as "a=rid" lines.

OK

Section 5.11, perhaps (RID header -> "a=rid"):

Any RTP header extensions that were negotiated should be included in the outgoing RTP streams, using the extension mapping from the remote description; if the "a=rid" extension has been negotiated and RID values are specified, include the "a=rid" attribute in the outgoing RTP streams, as indicated in [RFC8851], Section 4.

Here we are talking about the RID RTP header extension discussed in https://tools.ietf.org/html/draft-ietf-avtext-rid-09#page-5, although it calls these values RtpStreamIds. So perhaps we should use that terminology in this paragraph rather than RID.

TBH, I'm a bit confused here what the difference is between rid-id and RtpStreamId, and our use of the term RID adds another layer of indirection. I'll look and see if there's an easy cleanup that can be done here.

[juberti]

I reviewed in depth and it's clear now that RID == RtpStreamId == rid-id. Let me see now what text changes should follow from this.

[juberti]

This is actually messier than I had thought, will draft a PR to try to sort this out now.

[fluffy]

following ...

[juberti]

PR sent for review. I still don't totally understand why the RID spec went with "rid-id" instead of "rid" or RID, but regardless I decided to adopt that terminology to make life easier for the reader.