<#secure method=pgpmime mode=sign>
Qin Wu <bill.wu@xxxxxxxxxx> wrote:
> [Qin]: I get impression you change update RFC process, usually we have
> existing, published RFC first, and then make bis document and revise
> the existing RFC, now you progress multiple release in parallel, which
> is something I haven't seen before.
There are many processes.
The IETF has often published an Informational draft on an existing
"defacto" specification that is unchangeable because it is already deployed.
I believe this happened for POP3, IMAP, HTTP 0.9, and a number of other well
known protocols.
Then we do "v2.0" which is standards track, and which is subject to IETF
change control. Except that this time, it is 4.0 not 2.0.
[In fact, there is no v2 for ffv because it never got deployed]
(Such a process was not done, btw. for TACACS for reasons that were never
adequately explained to me)
jerome> FFV1 is a video coding format, like Opus is an audio coding
jerome> format, Opus does not specify transport too. FFV1 is intended to
jerome> be encapsulated in a container and we don't feel the need to have
jerome> a dedicated transport for FFV1, we use (de facto or not) standard
jerome> like MP4 (ISO standard) or Matroska (de facto standard and IETF
jerome> standard candidate) for the transport. Note that Opus is an IETF
jerome> standard (RFC 6716) without transport.
> [Qin]: We also see OPUS with RTP transport has been published as
> RFC7587. Anyway I leave this issue to you.
Yes, but RFC7587 does not define the OPUS CODEC.
The OPUS Codec is defined in RFC6716.
RFC7587 defines how to carry RFC6716 transmissions in RFC3550 format.
We have a document, draft-ietf-cellar-matroska, which is a bit equivalent to RFC7587.
But, not involving RTP. If there were interest in using ffv4 in the future
over RTP, then we'd have to explain how to do that.
CELLAR is focused on archival needs, not real time needs.
> [Qin]: which protocol is used to configure these parameters? How do you
> prevent misconfiguration from malicious client?
First, it's a data format, not a protocol.
So there is no configuration or negotiation involved.
The chosen parameters are either valid, and the decoder can deal with them,
or it can't.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
