Telephony services ids format

[marcoscaceres]

What's the standard format for a telephony service id? I.e., what do they look like as a string? Is there some standard that defines them?

[zolkis]

They are designed to be an opaque id, managed by the implementation. The spec does not specify the format, only the uniqueness of them.
In my implementation I use a generated part and a part specific to the backend, so that from an id the backend can connect to its own logic. Basically it is a JSON-serialized object of 3 attributes, kind (service or call), generated id, and platform-id.
I think the format should not be standardized. Is there any reason we should do that?

We agreed with Giri that in fact we'd have a better API with explicitly exposed TelephonyService objects. That would obsolete the use of id's. However, when I implemented both, it turned out that the current model with the id's makes a few corner cases simpler. Having said that, we will need to add TelephonyService objects anyway, in order to manage service-specific functionality (e.g. SIM info, network settings, etc).

[marcoscaceres]

Ok, we might need to provide some guidance as it could end up revealing privacy sensitive information.

[marcoscaceres]

Following up, do you think TelephonyService is in scope for 1.0?

[zolkis]

In strict sense, no. But it may be a design choice, especially since in Messaging introducing a MessagingService object would simplify many things (and was asked by Mounir on the F2F). Then having a similar concept for TelephonyService, would both align with Messaging, and would be compatible with future versions - since it will be needed in later versions of the spec. So it could make sense to include it already now.

It would also make it easier for telephony people to place/understand this API (e.g. Giri and our telephony people only understood the API when I presented them the TelephonyService concept, which handles all issues not handled yet in this spec). However, it's no free lunch, as you will see.

I can go through with you on how the API would change if we introduced a TelephonyService concept now. I am really interested on your opinion.

[zolkis]

To conclude, I suggest including a clause that implementations MUST use a unique id for serviceId, which MUST NOT reveal information usable for fingerprinting. This is independent from whether to use TelephonyService objects or not. This is also valid for other unique id's used in this spec, and in SysApps in general.
@marcoscaceres please comment - should we also raise issues in other specs along this line?

[marcoscaceres]

It's a bit hard to say MUST here without actually providing a solution. An implementer might try to do that, but could still screw it up. There would also be no way of testing this for conformance. So, the only way to achieve this would be to actually provide some kind of format to obscure this information.