|
Hi Marc, all, We appreciate your review. Please see inline. Unless we hear otherwise, we will address the issues labelled as “FIX” only in our working copy. Stephan
From: Marc Blanchet via Datatracker <noreply@xxxxxxxx>
Reviewer: Marc Blanchet A comment like this has come up before, but we claim the sentence is clear to those implementing payload formats. To explain, all parameters defined in the media type registration
are optional. That means, they do not need to be included in the SDP that’s being used in negotiation, and senders who don’t plan to ever send an optional parameter obviously do not have to implement the sending of it. However, that does not mean that a
receiver is at the same liberty. A receiver really SHOULD implement receiving, and parsing all optional parameters and ideally have application logic that decides whether it can possibly accept a media stream advertised with a parameter that it’s sending
part would never send. It’s common implementation practice to take shortcuts here, which is why we provide the aforementioned guidance. However, nothing seriously breaks if an implementer does not follow the recommendation, as there are defaults for each
optional parameter. Worst case, the media would fall back to a basic interoperability mode (like: small picture size, relatively low frame rate). Also, there are valid reasons for not implementing the SDP part of the RFC at all, for example if the session
negotiation is conducted using Jingle or something. Therefore, SHOULD seems to be right.
- section 9: "the RTP packet is RECOMMENDED but FIX: RECOMMENDED and REQUIRED are both RFC2119 keywords. We should lower-case the “NOT” in “NOT REQUIRED”.
Otherwise, I think this is a style question only.
- section 9: "For example, it would be a bad FIX: I’m not an English native speaker, nor is any one of my co-authors. However, the sentence seems fine.
That said, we could rephrase to “For example, forwarding all received _javascript_ code detected by a decoder implementation to a web-browser unchecked would be a bad and insecure implementation practice.”. Does that work better for you? Note that there are
good and valid reasons for receiving and forwarding _javascript_. I have seen a prototype doing just that to get a display set up. But we want to guide away from a naïve implementation that find a string in an SEI message, figures out it may be _javascript_,
and forwards it without having a clear idea what’s going on and from whom that _javascript_ comes and what it is intended to do.
- section 10: Congestion Thanks. In this, like in many other places, we follow the VVC payload that became an RFC 9328 not a year ago. I don’t mind moving sections around, but also do not see a necessity.
FIX. Typo, will be fixed.
FIX: Leftover from RFC9328, VVC payload format. Will be removed.
We prefer the US spelling as that is what ISO/IEC is using—and this payload format is there to transport data according to an ISO/IEC spec.
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
