Skip to content
This repository has been archived by the owner on Oct 2, 2019. It is now read-only.

Telephony services ids format #53

Open
marcoscaceres opened this issue May 22, 2013 · 6 comments
Open

Telephony services ids format #53

marcoscaceres opened this issue May 22, 2013 · 6 comments
Labels

Comments

@marcoscaceres
Copy link
Contributor

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
Copy link
Contributor

zolkis commented May 22, 2013

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
Copy link
Contributor Author

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

@marcoscaceres
Copy link
Contributor Author

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

@zolkis
Copy link
Contributor

zolkis commented May 24, 2013

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
Copy link
Contributor

zolkis commented Sep 27, 2013

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
Copy link
Contributor Author

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants