Clarify subscription start and end times

[csarven]

As per #feature-expiration , clients can use notify:expiration in the #subscription-request to propose the expiration datetime of a subscription.

It'd help to clarify when the client wants a subscription to start.

Thus it may be preferable to favour the notions "start" and "end" datetimes, instead of "expiration" - meanwhile acknowledging that "expiration" is semantically equivalent to the "end" datetime.

The #subscription-response should indicate start and end datetimes that the server is committing to at the time of the message.

[csarven]

Clients can omit the start datetime in the subscription-request to indicate the subscription can start "as soon as possible".

Clients can omit the end datetime in the subscription-request to indicate the subscription can continue for unspecified period of time.

(There may be more useful interpretations for missing start and/or endTimes.)

[elf-pavlik]

I think it might be simpler to leave the expiration completely up to the notifications publisher and always provide a way for the subscriber to unsubscribe. I don't think we need to renew the subscription since a new one can be created instead.

What are the specific use cases which we are trying to solve with expiration/start/end?

I only can think of one that the client might want to end the subscription sooner than the server decided to expire it. And here unsubscribing seems simpler to me.

[csarven]

Again, it is optional. It is to clarify the model for the subscription period, which is an event in and itself, with an actual start/end times (including now and indefinitely). That information can be declarative (and recorded) or imperative (derived) from other values or activity elsewhere in the system. It most certainly plays a role in data auditing at least for the server, and it is certainly a "receipt" for the client. Client doesn't have to provide the start time but the server certainly knows when a subscription is active or valid from. Client can certainly provide the start time when it is actually capable of receiving updates. There is absolutely no need to couple the action to request a subscription with the desired datetime to receive updates. It is not always "now". Keep different subscription types in mind.

The current features, expiration and rate, are essentially trying to capture the rules around this. There are age old standards that describe events with start/end times, periodicity, recurring rules, among other things. See RFC5545 (DTSTART/DTEND), schema.org's Event (schema:startDate/schema:endDate) or ActivityStreams2 (as:startTime/as:endTime) for instance. Ditto "duration"...

I'm essentially proposing that we re-use terminology and modelling from existing stuff.

[elf-pavlik]

Client can certainly provide the start time when it is actually capable of receiving updates. There is absolutely no need to couple the action to request a subscription with the desired datetime to receive updates. It is not always "now". Keep different subscription types in mind.

I still can't see the reason why the subscriber would request a subscription that starts at some point in the future. Whenever the subscriber is ready to start receiving notifications they can subscribe at that time.

The current features, expiration and rate, are essentially trying to capture the rules around this.

https://solid.github.io/notifications/protocol#notification-features

rate An ISO 8601 duration value indicating the minimum amount of time to elapse between notifications sent to the client

I don't see the rate affecting the duration of the subscription. Only setting a limit on how often notifications are expected within that duration. For example, if the topic gets updated every couple of minutes, but subscriber only needs to update it once an hour, they wouldn't need to receive notifications every couple of minutes as the topic changes.

[elf-pavlik]

To clarify I think we should consider removing expiration as a feature and just leave it fully up to the publisher.

expiration An ISO 8601 datetime value indicating a proposed expiration point for a subscription. A server may choose another value.

Since the subscriber might want to end the subscription before it expires, the publisher should provide the subscriber with a way to unsubscribe.

[csarven]

Simply to enable the subscriber to request the desired subscription start/endTime. The information need not be tied or limited to "now" or "readiness" in real-time. Servers will need to record this information. It enables everyone to use the same language to negotiate, process, manage, and view subscriptions, declaratively.

[elf-pavlik]

I don't see any gains, while it seems to add complexity:

• Publisher needs a more sophisticated scheduler for subscriptions
• Both publisher and subscriber need to handle cases where features in the subscription request are not accepted by the publisher and the subscription response differs from what was requested.
• If the subscription type uses source, it might need to specify error when subscriber connects to the source before start

I think we should take a step back to see what exact use case we are trying to satisfy here. If it's only the one where the subscriber needs to end the subscription before it expires, I see mandating unsubscribing as a much simpler solution. Where we are reusing unsubscribe functionality in a consistent way.

If some publishers only support start end end, while others only support unsubscribe. The client will have to be able to handle both cases which add complexity.

For the mentioned use case I think we should require consistent unsubscribe.

In case start & end are trying to satisfy other use cases we should clarify them first.

Simply enable the subscriber to request the desired subscription start/endTime.

Let's take an example of a subscriber who makes a request with:

• start: 7 years from now
• end: 20000 years from now

What requirements should we place on the server when it comes to handling such requests?

The information need not be tied or limited to "now" or "readiness" in real-time. Servers will need to record this information.

Are you considering the start / end feature as required, or if supported by the publisher then it should work in some specific way?

I might be focusing on MUSTs which with 20% implementation effort should cover 80% of use cases. While the start & end feature fits more SHOULDs / MAYs which with the remaining 80% of implementation effort can cover the other 20% of use cases.

[csarven]

I am not talking about changing, e.g., undoing, unsubscribing, modifying, or deleting, the state of a subscription in this issue. There is no need to convolute this issue with what's orthogonal.

Different clients have differing capabilities, characteristics, or preferences that could influence the nature of the subscription.

There is already a negotiation taking place when there is a subscription request and a response.

When a request doesn't explicitly indicate a preferred start time, what's deemed to be implied or interpreted is that the subscription should start now, as soon as possible, whenever the server can, or something along those lines, upon server receiving the request. That information can also be explicit in the payload whether the start time value is now or same as the datetime of the request (or thereabouts), or in the future to indicate a desired period for the subscription, e.g., activities in the month of October or during the lifetime of a policy. When a server can't actually start a subscription now (or within a reasonable time frame) or for the requested time - for any reason - the server may reject or state the start time it can satisfy.

This is all good signal back to the client. It is same as responding back to a subscription request that's to start in 7 years and/or end in 20000 years. The server may be able to promise that request now, and do its best to fulfil that request, but it isn't at odds with wanting to cancel, undo or expire the subscription in the future.

Both client and server encoding the start/endTime allows an understanding of the effective subscription. This is a provenance record. Authoritative information. When a record of a subscription has its own URI - all information about the subscription agreement can be verified. It is also the identifier that can be used to refer to a subscription or a request to change the state of a subscription. We'll need to introduce a note or a requirement on that matter.

[csarven]

startAt/endAt incorporated: https://github.com/solid/notifications/pull/135#issuecomment-1366077555