[IC3 ACS Telco Messaging Front-end ] Add optional parameter validityPeriodSeconds API Review

[azure-sdk]

New API Review meeting has been requested.

Service Name: IC3 ACS Telco Messaging Front-end Review Created By: Vitalie Besliu Review Date: 01/18/2024 08:00 AM PT Onboarding Record: PR: https://github.com/Azure/azure-rest-api-specs/pull/27067 Hero Scenarios Link: Not Provided Core Concepts Doc Link: Message Expiration Settings.docx

Description: Discussed with DevEx team on Internal Review. Main conclusion: Team to schedule ARB review for the new field and will also clarify below questions during the review

• The new field affects both ** How long we keep the msg and keep retrying ** How long we wait for the delivery report
• Suggested names were: processingTimeoutSeconds, deliveryTimeoutSeconds - pick one of those and add description/docs on what the semantics are ** Current description already explains this well
• Logistical GA questions ** Team wants to GA asap ** Should a new API version be created or can this field be added to an existing one? -> create new version ** Can GA be done without public preview? -> no, but will double-check

Detailed meeting information and documents provided can be accessed here For more information that will help prepare you for this review, the requirements, and office hours, visit the documentation here

[heaths]

There are problems with the swagger - breaking changes, actually - that need to be resolved first; however, for a single property, you really don't need to schedule a meeting. You can email the REST API board for an offline review and leave the hour open for larger API changes. Could you cancel the meeting and email us instead?

See https://aka.ms/azsdk/onboarding/restapischedule for contact details.

[mikekistler]

We're going to cancel this meeting to make space for another team that really needs an in person review. Please ping here when you've addressed Heath's comments so that we can complete the review offline.

[azure-sdk]

Cancelled by System Admin

[besh2014]

Thanks for explanation. @mikekistler, @heaths addressed your comments.

1. One question we had is about naming. Should the name contain that the deliveryReportTimeout is in seconds e.g. deliveryReportTimeoutInSeconds or should be more generic e,g, deliveryReportTimeout.
2. It shows Breaking change but it is because I had to add "format" tag to some attributes since LintDiff was generating following errors https://github.com/Azure/azure-rest-api-specs/pull/27067/checks?check_run_id=20615114884.

[mikekistler]

1. Our guidance says:

   ☑️ YOU SHOULD use a suffix of the unit of measurement for values with a clear unit of measurement (such as bytes, miles, and so on).

   so something like deliveryReportTimeoutInSeconds seems appropriate.

2. Format changes are usually not a major concern for breaking changes. If the change is just a more accurate description of the actual service behavior, these changes are fine.

[besh2014]

Thanks. Please review the PR: https://github.com/Azure/azure-rest-api-specs/pull/27067.