El Jueves, 19 de Noviembre de 2009, Adrian Georgescu escribió: > First of all, there is no correlation on protocols level between the > SIP Subscribe from a foreign domain and the HTTP GET requests the > watcher performs for fetching an icon stored in an XCAP server in a > foreign domain. So technically you cannot enforce a policy about who > is allowed to HTTP GET your icon.
At least you can implement a local policy. The SIP proxy and the HTTP proxy/server can ask for authentication just in case the "From" domain and the "X-XCAP-Preferred-Identity" domain is a provider local domain. Other domains (untrusted) can be considered as "others" and the local policy could be different for trusted and untrusted domains. > According to OMA everything is pipe between operators that have > agreements between them. So by proxying all HTTP requests to an > outbound proxy of operator A the HTTP request will arrive with some > extra asserted headers to operator B who will then trust them and > honor the HTTP request based on them. This is non-sense on the Internet. Sure. > Protecting an icon is also complete non-sense as once somebody fetched > it no matter by what means or credentials it can post it on Facebook > and the rest of the universe got it. Is a picture in the end, > something you display in a small area of a remote device, something > you published in the first place to be reachable and not some credit > card secret details. If you think you need high security for an icon > do not publish it in the first place. The icon is just an example. I expect there could be other kind of documents a user desires to share just to others. > The only reasonable thing you can do with the icon is to anonymize the > URL so that people cannot simply guess it. The ones who obtain the URL > from the Notify with presence Event can fetch it because they know > where it is. And he can also upload it to Facebook again. > This is what we are now building in OpenXCAP. Another propietary (even if it's open source) XCAP application? good, and which client will implement it (uploading an naming an icon in a propietary way)? Let me guess... Blink? I could agree with these kind of new features if they would be, at least, documented as proposed drafts. This is, now pres-dialog-rules has been released and supported by OpenSIPS, OpenXCAP and Blink. Will be a concise documentation of this custom format? or should I inspect the requests Blink generates to "imitate" them? The same for this new "XCAP icon storage application": which mime-type will be used? which format and size is allowed? which kind od transfer type? or should I do a ngrep? Please don't take wrong Adrian, I want to be constructive. Regards. -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
