Creation of SMS API Family

[TEF-RicardoSerr]

Problem description
It has been proposed in the API backlog (Issue#372) a new API to receive SMS (application template available at PR#391). The team feels that this new proposal fits fairly well in a new API family alongside this one i wanted to query the owners of this ShortMessageService subproject to see if they are ok with including the new API withing this Github project

Expected action
@tcchiba @a-ramit Please show your view on this

CC
ReceiveSMS API Owners: @ailton-santana @adsjr2, TSC Member: @hdamker

[hdamker]

@TEF-RicardoSerr

My thoughts:

• Option 1: If the APIs will are very closely related (e.g. have shared schema definitions), will follow same life cycle, and will have joint releases, then it is ok to have them together within the same repository.
• Option 2: If this condition are not given then it might be better to develop the APIs in separate repositories to avoid complexity in release management. That still allows to maintain them together by one team (e.g. one call for both repositories). That would be in line with the notion of "API Family" as a working group across multiple sub projects.

For some more details on my thoughts you can have a look on https://wiki.camaraproject.org/display/CAM/2023-11-02+TSC+Minutes?preview=/4554757/4554780/TSC-2023-11-02-API_Families_and_APIs.pptx.pptx

[a-ramit]

Currently ShortMessageService sub-project includes APIs for Send SMS and SMS Delivery call back notification. By just looking at the name of this new API i.e. ‘Receive SMS’, it seems to be part of ShortMessageService family. However, I am not very clear on the use cases of this new API. Can someone point me to the use case of this please. Thanks & Regards, Ramit Chawla From: Herbert Damker ***@***.***> Sent: Wednesday, March 27, 2024 9:23 PM To: camaraproject/ShortMessageService ***@***.***> Cc: RAMIT CHAWLA ***@***.***>; Mention ***@***.***> Subject: Re: [camaraproject/ShortMessageService] Creation of SMS API Family (Issue camaraproject/WorkingGroups#9) [CAUTION: External Email] Do not click links or open attachments unless you recognize the sender and know the content is safe. @TEF-RicardoSerr<https://github.com/TEF-RicardoSerr> My thoughts: * Option 1: If the APIs will are very closely related (e.g. have shared schema definitions), will follow same life cycle, and will have joint releases, then it is ok to have them together within the same repository. * Option 2: If this condition are not given then it might be better to develop the APIs in separate repositories to avoid complexity in release management. That still allows to maintain them together by one team (e.g. one call for both repositories). That would be in line with the notion of "API Family" as a working group across multiple sub projects. For some more details on my thoughts you can have a look on https://wiki.camaraproject.org/display/CAM/2023-11-02+TSC+Minutes?preview=/4554757/4554780/TSC-2023-11-02-API_Families_and_APIs.pptx.pptx — Reply to this email directly, view it on GitHub<#9 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A5RGDJH3OCWTINIYWEPHXRLY2LMOJAVCNFSM6AAAAABFLBS54KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRTGEYTSNZVGE>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>> *********************************************************************************************************************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited . The information contained in this mail is propriety and strictly confidential. *********************************************************************************************************************************************************************** “CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.”

[adsjr2]

Receive SMS would allow interaction from the subscriber.
Example 1:
Dentist office sends a message to client:
'Your next appointment is scheduled for 12/04/2024. Reply Y to confirm'
Example 2:
Anti-spam regulations request that subscriber has the option to sign out.
"50% off at Old Navy this weekend. Reply 'STOP' to stop receiving our promotions"
Example 3:
Customer Service feedback
"How did we serve you today? On a scale from 1 to 5, 1 being the worst and 5 being the best, how do you rate our attendant?"
Example 4:
Additional security for bank transactions
"A withdrawal of $1,000 from your account has just happened. Confirm you are aware of this transaction, replying Y. N otherwise."

It would require:

• The phone number that replied
• A message field
• A webhook URL (this would have to be provided on the Send SMS if a reply is expected) : this is the URL where the A2P server is expecting any answer.
• HTTP method (POST or GET)

[TEF-RicardoSerr]

It is approved in Backlog camaraproject/APIBacklog#18 to extend scope of the subgroup (minutes here) to support receiveSMS use case. The following must be accomplished:

• Update README to include the new scope
• Update Codeowners and Maintainers files

@adsjr2 @ailton-santana recomend you to create a PR encompassing this

[jgarciahospital]

Hi @adsjr2, could you please review this pending AP from backlog? It implies the formalization of the Receive SMS functionality to be part of the ShortMessageService API.