Clarification on 'subscriptionExpireTime' and 'expiresAt' Handling

[sachinvodafone]

I would like to clarify some points regarding "subscriptionExpireTime" and "expiresAt" as defined in our API guidelines:

Question 1: If "subscriptionExpireTime" is not provided in the POST request, will the API server withhold the "expiresAt" attribute in the server response? If not how it will be decided ?

Question 2: If the client includes a specific "subscriptionExpireTime" in the POST request, is it reasonable to expect that the server response will include an "expiresAt" attribute, likely set to the same value as the provided "subscriptionExpireTime"?

[bigludo7]

Thanks @sachinvodafone for triggering this discussion.

Back to the guideline:

subscriptionExpireTime: Date when the event subscription should end. Provided by API requester. The Server may reject the subscription if the period requested do not comply with Telco Operator policies
expiresAt: Date when the event subscription will expire. This attribute must not be present in the POST request as it is provided by API server.

So regarding your questions:
1/ this is fine to not have a subscriptionExpireTime in the request. Then if Telco has a policy to not allow subscription for more than 10 months for example, the expiresAt could be valued (current date + 10 months)
2/ Here we should be explicit. In the guideline we indicate that if the subscriptionExpireTime is not Ok for the server it may reject it... meaning that it could also accept it. In this case I expect the expiresAt values with the end date from server perspective and differ from subscriptionExpireTime. Perhaps we should shift from may to must ?

adding @PedroDiez @jlurien @rartych @shilpa-padgaonkar

[sachinvodafone]

Thanks @bigludo7 to add your valuable inputs,

1/ this is fine to not have a subscriptionExpireTime in the request. Then if Telco has a policy to not allow subscription for more than 10 months for example, the expiresAt could be valued (current date + 10 months)

In our guideline , "expireAT" is optional. If the API server autonomously determines the "expiresAt" based on policies or default rules when "subscriptionExpireTime" is not provided, making "expiresAt" mandatory in the API response could offer more clarity and consistency. This ensures that clients always receive information about the expiration, whether it is calculated by the server or aligned with the provided "subscriptionExpireTime."

2/ Here we should be explicit. In the guideline we indicate that if the subscriptionExpireTime is not Ok for the server it may reject it... meaning that it could also accept it. In this case I expect the expiresAt values with the end date from server perspective and differ from subscriptionExpireTime. Perhaps we should shift from may to must ?

I believe, if the server doesn't like the 'subscriptionExpireTime' provided by the client, it MUST reject it and send error response. Otherwise If the API server sends back an 'expiresAt' value different from the 'subscriptionExpireTime' (if it is not OK), it might confuse the client about what they did wrong and got different "expireAt"