@aboba, I am not sure of the scope of changes you are requesting here.
Do you have a particular proposal in mind on how to address this issue?

I believe there is consensus for SFrame transported over RTP as long as it is audio (SPacket == SFrame in that case) but not for video.
Would acknowledging the issue for video in the current draft be sufficient to address your concerns?

At IETF 111, SPacket was proposed as an alternative to SFrame.

I think there is some confusion here.
@murillo128 might confirm but SPacket was not proposed as an alternative at IETF 111.

In any case, SPacket and SFrame share the same format that SFrameTransform as a transform stream implements.
The SFrame format is adopted by the SFrame WG so we are on solid ground there.

@aboba mentioned in https://lists.w3.org/Archives/Public/public-webrtc/2021Aug/0028.html the following:

While the stack and protocol are evolving quickly, I'd prefer not to add a native transform specific to a protocol that hasn't been adopted by an IETF WG, particularly if that method can't accommodate automatic key management. That is just inviting interoperability problems.

I understand it that you would prefer not to add SFrameTransform to the spec as long as the SFrame current draft is not a SFrame WG draft. Is that correct?
An alternative is to make it clear in the spec that SFrameTransform is based on ongoing IETF work, that this work did not yet reach stability. We might thus remove SFrameTransform at any time based on the outcome of this ongoing work.
Would that be ok with you?

As discussed with @aboba today on editor's call, two things might help solving @aboba concerns to move the spec to FPWD:

• A note stating that SFrameTransform is still in flux both in terms of API and in terms of protocol definition
• A stable link to the SFrame draft that this spec would use, ideally owned by the SFrame WG

A suggestion for the NOTE:

"The API presented in this specification represents a preliminary proposal based on protocol proposals that have not been adopted by an IETF WG. As a result, both the API and underlying protocol are likely to change significantly going forward."

Note that there has been some discussion within the SFRAME WG relating to adoption.

We now have a WG draft for SFrame: https://datatracker.ietf.org/doc/draft-ietf-sframe-enc/