From: Paul Kyzivat <[EMAIL PROTECTED]> IIUC, the identification is mostly just for authorization, to prevent fraud - getting preferential treatment.
I don't think that even this mild form of fraud is a problem, as one's position in the queue is determined by when one makes the subscription. My concern is privacy -- having a CC subscription allows monitoring the alleged callee's presence/availability information without having placed a call to the callee first. Given current telephony usage (caller-ID), users are much more likely to be aware of someone calling them on a regular basis than someone continuously subscribed to the CC service. And given the near-anonymity of SIP requests, it would be hard to detect privacy-invasive exploitation of CC subscriptions. If you have two ways, and one of them provides an opportunity for fraud, and the other not, then those intent of fraud will use the one that supports it. There is then little motivation to implement the other method, since it will only be used by those who would do the right thing with the weaker mechanism. If you replace "fraud" with "invastion of privacy", this is my concern. Huelsemann, Martin wrote: Can't this be done by 2 different ways? First the normal way with delivering something like a CC identifier back to the CC agent which then ist used druring the subscription and the CC call. The other way would be the fallback for stateless UAs (and gateways) to reassemble the identifier from information available from the original call (first choice information about caller and callee). During design team discussion Dale also introduced a keying mechasim guarateeing privacy settings. The difficulty with a keying mechanism is that we cannot assume that the caller's agent and the callee's monitor share a key. I doubt that we could implement that in practice even in a walled-garden run by a bureaucratic service provider. Once we decide that the key is present only in the caller's agent, we have a need to transmit the key-derived identifier to the callee's monitor. But at that point there is a conflict -- we don't want to add to every INVITE an additional datum, but at the same time, all the data in an INVITE seem to be either easily guessable or intermediate B2BUAs feel free to change them. Perhaps we need to study more carefully whether this is needed to prevent abuse of privacy. Dale _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
