Delivery timeout cannot be expressed per subgroup

[fluffy]

TTL got moved into delivery timeout in subscribe OK but that lost the property to set a different timeout for different sub groups.

It is not clear where a max cache parameter can be in the protocol.

It is not clear interaction of max cache and delivery timeout in subscribe OK are both needed.

[afrind]

I renamed the issue to reflect the primary issue with the current draft.

It is not clear where a max cache parameter can be in the protocol.

This is true, let's file a separate issue. My understanding is that it's useful in both SUBSCRIBE_OK and FETCH_OK - does that seem right?

It is not clear interaction of max cache and delivery timeout in subscribe OK are both needed.

My understanding is:

DELIVERY_TIMEOUT only applies to SUBSCRIBE (not FETCH) -- how long should a relay attempt to deliver an object before dropping/resetting.
MAX_CACHE_DURATION tells a cache the max time to keep an object in cache (to serve via FETCH) before expiring it. A subsequent fetch after expiry would necessitate re-fetching from origin.

If that's right then having both in SUBSCRIBE_OK seems valid. If that's not right, let's file a separate issue for this too.

[suhasHere]

I wonder if we are talking about 3 different things here

• per subgroup TTL, set by the original publisher --> we don't have a way tp specify this today.
• subscriber requested delivery timeout -> @afrind i concur on your definition on this one
• cache duration ( set by the publisher, but can be effected by relay policy ?) --> @afrind aligning with you

Also I agree subscribe_ok should reflect these values as they serve different purposes .

[martinduke]

I don't understand the use case for different delivery timeouts. Surely the delivery timeout relates to when the media will be consumed, which is independent of priority?