Apoorva Deshpande

I have raised similar asks around not having reciever's metadata doc in earlier working group calls [here](https://hackmd.io/@oidf-wg-sse/wg-meeting-20230905#SSF-Service-general-reference-instead-of-Transmitter--Receiver) SET encryption should also be baked in the [SET - RFC8417](https://datatracker.ietf.org/doc/html/rfc8417) or outside...

I agree with @timcappalli. My preference is in the following order - Option 3 (Most favorable) Option 1 Option 2 (least)

Looking at the current description the stream updated event is purely used for communicating functional/operational status of the stream ie. `disabled`, `enabled`, `paused` etc. It does not deal with stream...

> The Event Transmitter MAY choose to silently ignore the request, for example if the subject has previously indicated to the Transmitter that they do not want events to be...

How would we handle the bloating of the event? Should there be a recommendation on the size? Restrictions on keys to avoid conflicts with optional/mandatory event fields etc

This event helps make risk-level communication generic for various subjects, as noted in the examples. The risk aspect is going to be subjective, but it's still very prevalent in the...

> The current language says "errors are reported...", which makes the current behavior the equivalent of a "MUST", changing this will break backward compatibility. There is no evidence right now...

> @appsdesh The text says that the Transmitter MAY send the 400 code if the delivery method is not available. But the intro to the table says "Errors are signaled"...

I am rethinking this one. Since Transmitter may initiate verification asynchronously, it may not know the status of the stream at the time of ack'ing the verification request. I suggest...

> Thanks Atul! After thinking about this more, a similar concept will be useful for PULL streams too - except expiring the stream it's for expiring the events themselves, so...