Re: [Sframe] Status of the SFRAME WG

Murray --

Standards work often slows down in August as people take vacation. So it is
not surprising to experience difficulty in getting a WG meeting together in
early September.  In the past I've had to cancel WG interims scheduled in
August or early September, and just last week we had to extend a WGLC due
to lack of responses. So some of what you are seeing may be the general
slowdown in August.

Aside from that though, I do think there is reason to take another look at
the problem definition in SFRAME WG.  During the pandemic the disparate
worlds of streaming and realtime communications have begun to merge, with
the new category of "low latency streaming" emerging. We've seen developers
taking a fresh look at problems such as video ingestion (e.g. RUSH, WISH)
and low latency streaming (e.g. media over QUIC or WebRTC data channel).
In the new architectures that are emerging, some of the traditional
streaming architectural elements are being rethought. As one example,
protocols such as WISH enable endpoints to upload simulcast or scalable
video coding, rather than requiring a transcoding service.  Also, APIs such
as WebCodecs make it possible to decode and render video without
containerization (as had been required when using MSE API).

As these new ideas take shape in newly chartered WGs or BOFs, it may be
appropriate to consider whether the SFRAME WG is targeting the right
problems.  Traditionally, streaming architectures have focused on the
generalized transport of frames whereas RTP has forsaken generic
encapsulations, choosing instead to customize packetization to each codec.
As a result, at the IETF 111 AVTCORE meeting, Sergio presented SPacket,
which while having quite a bit in common with SFrame, has security services
occurring after packetization rather than before.

However, even if SFrame turns out not to be suitable for use with RTP, it
still may prove useful in the new architectures.  As an example, in a low
latency streaming use case requiring support for content protection (e.g.
sports, concerts, etc.) it may be desirable for the downstream leg to
bypass traditional content protection schemes based on containerization,
just as next generation ingestion protocols may make it possible to bypass
transcoding services.  Could SFRAME play a role here? It may be worth
considering.

On Fri, Aug 27, 2021 at 9:40 PM Murray S. Kucherawy <superuser@gmail.com>
wrote:

> Colleagues,
>
> I'm concerned with what appears to be rather low energy in this working
> group.  There's been almost no activity on the list since IETF 110, and it
> looks like there's been little interest shown in an interim meeting despite
> efforts by the chairs to re-establish momentum.  It also looks like some of
> the work expected to be done in SFRAME is actually happening in AVTCORE.
>
> Is there still work to be done here and the energy and interest to do it?
> Should we propose moving the remaining document to AVTCORE or some other
> venue?  It had a milestone of June 2021, but that's now past without
> adopting any document to satisfy it.
>
> -MSK, ART AD
>
>
> --
> Sframe mailing list
> Sframe@ietf.org
> https://www.ietf.org/mailman/listinfo/sframe
>