Re: [Sframe] WGLC for draft-ietf-sframe-enc-04

The minimum bar to me is to have one implementation and a test suite including the feature, which is currently met with the reference implementation I think.
Do you know of any additional implementation that supports it?

W3C SFrameTransform does not seem a blocker as we could probably extend the API to support it, should there be a need in the future.

I do not see any blocker that would strongly indicate to remove it (nor a strong indicator we should keep it).

I still find the spec a bit light on when users should use metadata and when they should not.
The RTP header extension case is a bit unclear to me and section 9.4 does not provide applicability guidance.
For the record, the past discussion summary is at https://github.com/sframe-wg/sframe/issues/63#issuecomment-1484641916 which indicates we should decide what to do at WGLC, now is the time.

> On 6 Nov 2023, at 17:17, Richard Barnes <rlb@ipv.sx> wrote:
> 
> Thanks, Youenn.
> 
> With regard to metadata: Given that we're about to finalize the spec, the time for "feature at risk" has passed.  We need to decide whether it's in or it's out.
> 
> Personally I would be inclined to keep it.  This is the classic "proactively add an extension point" (which inherently leaves it underspecified) vs. "YAGNI / add the extension point when it's needed" (thus requiring a code change later) argument.  My inclination for the former is based on this being a very simple extension point that doesn't change the behavior of the protocol much.  And it seems like there are some things like frame marking that might benefit from being bound into the metadata.
> 
> A comparable story from MLS/MIMI: We added an `authenticated_data` field to the MLS encrypted message structure, which has largely the same trade-offs we have here (except it *also* consumes space in the message).  When it was added, there wasn't an explicit use case for it, but it looks like MIMI is going to make a fair bit of use.
> 
> On Mon, Nov 6, 2023 at 10:34 AM Youenn Fablet <youenn=40apple.com@dmarc.ietf.org <mailto:40apple.com@dmarc.ietf.org>> wrote:
>> The document looks ready to advance.
>> 
>> About metadata, it is considered a feature at risk. It might still be a bit early to decide whether this is a useful addition. How are we planning to deal with it in the future?
>> 
>> Thanks,
>> 	Youenn
>> 
>>> On 23 Oct 2023, at 01:08, Martin Thomson <mt@lowentropy.net <mailto:mt@lowentropy.net>> wrote:
>>> 
>>> Hi All,
>>> 
>>> This starts a 3 week working group last call for draft-ietf-sframe-enc-04.
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-sframe-enc/
>>> 
>>> We've been somewhat slow about this, but progress has been steady and the discussions have all been very productive.  The editors tell me that this is ready.  Please let us know whether you agree.
>>> 
>>> This WGLC will end at about the end of the upcoming IETF meeting.
>>> 
>>> Cheers,
>>> Martin
>>> 
>>> -- 
>>> Sframe mailing list
>>> Sframe@ietf.org <mailto:Sframe@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/sframe
>> 
>> -- 
>> Sframe mailing list
>> Sframe@ietf.org <mailto:Sframe@ietf.org>
>> https://www.ietf.org/mailman/listinfo/sframe