Fall 24 Documentation

[TEF-RicardoSerr]

What type of PR is this?

• documentation

What this PR does / why we need it:

As required by the release management project CHANGELOG with the existing version of the APIs is uploaded

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.02s
✅ OPENAPI	spectral	3		0	4.36s
✅ REPOSITORY	git_diff	yes		no	0.01s
✅ REPOSITORY	secretlint	yes		no	0.76s
✅ YAML	yamllint	3		0	0.46s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[hdamker]

@TEF-RicardoSerr I just recognized that you have already created the release tag v0.1.1 - there are several issues with that:

• release number are now independent of the the API Version. r1.1 would be correct within the current release cycle
• the API Version: a) should be release candidate now, b) are you sure it only a patch of 0.1.0 and shouldn't be v0.2.0-rc.1?
• the "release" does not contain the changelog and other release assets as these are not merged yet ... it has to be created after the merge of the reviewed release PR
• it should be created as a "pre-release", not a "latest" one

I suppose it is save to delete the current v0.1.1 tag and create the right one after the release assets are complete.

[soadeyemo]

• CHANGELOG.md is missing in the folder. Template is available from RM repo.
• this project is still missing Release Tracker. Add the Release tracker

[hdamker]

@camaraproject/web-rtc_maintainers: the webRTC wasn't registered with a release tracker page within the Fall24 release of CAMARA which was the reason that it wasn't full on the radar for this Meta-release.

Having a short, but closer look:

The three BYON APIs differ significantly from other CAMARA APIs and are in several points not aligned with the guidelines of Commonalities 0.4.0 and Identity and Consent Management (ICM) 0.2.0.

Just to mention a few points:

Developer friendliness:

• limited inline documentation (might be due the complexity of the APIs, but can be improved)
• many telco and webRTC specific terms and abbreviations which are often not even resolved in the document where they are used.
• API names, schemas and property names are using abbreviations. Just an example: exMTHold is the reference to an example ... why does that need to be abbreviated?

Formal points:

• info and server object are not following the Guidelines
• API versioning guidelines are not followed (e.g. v1 in path, update of version number with each PR, not only within release)
• Security requirement objects and scope names are not following the Security and Interoperability profile of ICM
• Notification API not aligned with CAMARA subscription model, notifications do not use the CloudEvent structure
• ...

As a result I would recommend to skip the Fall24 release and continue the good work on the initial versions of the APIs. For a participation within the Spring25 meta-release it would be good to start now to analyse the gaps between the API definitions and Guidelines of CAMARA. Not only to plan the changes for the webRTC APIs, but also the identify potential changes which are needed within the CAMARA Guidelines resulting out of these gaps. The kick-off M0 milestone for the Spring25 release is at September 30th, until then Commonalities has to define their scope for Spring25!.