---------- Forwarded message ---------- From: Elwell, John john.elwell@siemens-enterprise.com Date: Wed, Oct 20, 2010 at 9:45 AM Subject: Re: [dispatch] proposed SIXPAC charter To: Peter Saint-Andre stpeter@stpeter.im, "dispatch@ietf.org" dispatch@ietf.org
I find this a worthwhile topic to pursue. I had been wondering whether this activity would turn out to be more of a profiling exercise, and whether the IETF might not be the best choice of venue for such work.
From the current draft charter it looks like there will be at least
some protocol extension work, for which I believe the IETF is the correct venue. On the other hand, the Unified Communications Interoperability Forum (UCIF) is seeking to advance the state of play on XMPP interoperability, and if we were just talking about a profile or BCP, that might have been a better venue. Perhaps the IETF should focus on requirements and protocol extensions, and consider whether the BCP work would be better done elsewhere. Or at least, there should be some coordination with other activities relating to XMPP interoperability.
John
-----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Saint-Andre Sent: 19 October 2010 21:17 To: dispatch@ietf.org Subject: [dispatch] proposed SIXPAC charter
Earlier this year, some folks in the RAI area proposed an initiative to define a few small extensions to both SIP and XMPP that would make it easier to develop and deploy dual-stack SIP+XMPP endpoints. Based on feedback provided on the DISPATCH list and received from the RAI ADs, I've taken the liberty of rewriting the proposed charter, in the hopes that fresh text will spur a more conclusive discussion. I'm mostly just trying to help the proponents put their best foot forward, so if folks here have more feedback I'd expect that people like Simo Veikkolainen and Emil Ivov will be able to engage in further discussion.
/psa
###
SIXPAC (SIP Integration with XMPP in Presence Aware Clients)
===========
Problem Statement
Both the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) are widely deployed technologies for real-time communication over the Internet. In order to offer a complete suite of features as well as communication across multiple networks, several user-oriented software applications support both SIP and XMPP, and more software developers have expressed interest in building such "dual-stack" solutions. Unfortunately, it is difficult to provide a good end-user experience in such applications because SIP and XMPP are not aware of each other. For example:
- XMPP presence does not include availability states related to a SIP
voice call or video call (e.g., "on the phone"), thus preventing an a dual-stack endpoint from showing presence-based communication hints
- There is no correlation between an XMPP IM session and a SIP voice
or video session, thus preventing a dual-stack endpoint from providing integrated user interfaces and communications history
- SIP accounts and XMPP accounts are not directly correlated
in contact lists or vCards (and not all deployed services support storage of such information), thus preventing a dual-stack endpoint from knowing that a contact has both SIP and XMPP capabilities
Although some proprietary solutions exist to the foregoing problems, it would be preferable to define standardized solutions for the sake of improved interoperability.
Objectives
Because both SIP and XMPP are easily extended through new SIP headers and XMPP elements, it should be possible to provide tighter integration within dual-stack SIP/XMPP user agents to improve the user experience.
Any such extensions should meet the following criteria:
Be completely optional and backwards-compatible for all endpoints
Work without changes to deployed infrastructure such as existing
SIP and XMPP servers, B2BUAs, firewalls, etc.
The SIXPAC WG will define a small number of SIP and XMPP extensions to solve the following use cases in dual-stack endpoints:
- Including SIP-based availability states in XMPP presence (limited to
basic presence and availability states only, not the full range of PIDF extensions)
- Correlating an XMPP IM session with a SIP voice/video session, and
vice-versa
- Advertising a SIP account address over XMPP and an XMPP account
address over SIP
Additional use cases are out of scope, including anything related to or requiring server integration, multiparty communication, SIP-based IM and presence, XMPP-based voice and video, file transfer, generalized service discovery and capabilities exchange, full protocol translation in communication gateways, shared credentials across both SIP and XMPP accounts, rich presence extensions for features such as geolocation, etc. Although such topics are important and interesting, they are out of scope for this group.
However, in addition to the protocol extensions explicitly mentioned above, the group may also define best practices related to the implementation and deployment of dual-stack SIP/XMPP endpoints, including topics such as user agent configuration.
Deliverables
Use cases and protocol requirements
XMPP presence extension for SIP-based availability states
Media session correlation extensions for SIP and XMPP
Contact address advertisement extensions for SIP and XMPP
Best practices for implementation and deployment of dual-stack
endpoints
Milestones
Feb 2011 Submit use cases and protocol requirements document to IESG (Informational)
Oct 2011 Submit XMPP presence extension document to IESG (Standards Track)
Oct 2011 Submit media session correlation extensions document to IESG (Standards Track)
Oct 2011 Submit contact address advertisement extension document to IESG (Standards Track)
Oct 2011 Submit best practices document to IESG (Informational)
###
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
2010/10/20 Victor Pascual Avila victor.pascual.avila@gmail.com:
I find this a worthwhile topic to pursue. I had been wondering whether this activity would turn out to be more of a profiling exercise, and whether the IETF might not be the best choice of venue for such work. From the current draft charter it looks like there will be at least some protocol extension work, for which I believe the IETF is the correct venue. On the other hand, the Unified Communications Interoperability Forum (UCIF) is seeking to advance the state of play on XMPP interoperability, and if we were just talking about a profile or BCP, that might have been a better venue. Perhaps the IETF should focus on requirements and protocol extensions, and consider whether the BCP work would be better done elsewhere. Or at least, there should be some coordination with other activities relating to XMPP interoperability.
"Integrating" XMPP into SIP is a workaround IMHO, but the fact that some work is being done in this area confirms the failure of SIMPLE. IMHO it's better to define a new specification for presence in SIP *from scratch* forgetting all about SIMPLE (all means all).
El Wed, 20 Oct 2010 13:11:22 +0200 Iñaki Baz Castillo ibc@aliax.net escribió:
2010/10/20 Victor Pascual Avila victor.pascual.avila@gmail.com:
I find this a worthwhile topic to pursue. I had been wondering whether this activity would turn out to be more of a profiling exercise, and whether the IETF might not be the best choice of venue for such work. From the current draft charter it looks like there will be at least some protocol extension work, for which I believe the IETF is the correct venue. On the other hand, the Unified Communications Interoperability Forum (UCIF) is seeking to advance the state of play on XMPP interoperability, and if we were just talking about a profile or BCP, that might have been a better venue. Perhaps the IETF should focus on requirements and protocol extensions, and consider whether the BCP work would be better done elsewhere. Or at least, there should be some coordination with other activities relating to XMPP interoperability.
"Integrating" XMPP into SIP is a workaround IMHO, but the fact that some work is being done in this area confirms the failure of SIMPLE. IMHO it's better to define a new specification for presence in SIP *from scratch* forgetting all about SIMPLE (all means all).
Anyways, integrating such new specification with xmpp with extensions, gws or whatever method is a win-win strategy.
2010/10/20 Jon Bonilla manwe@aholab.ehu.es:
El Wed, 20 Oct 2010 13:11:22 +0200 Iñaki Baz Castillo ibc@aliax.net escribió:
"Integrating" XMPP into SIP is a workaround IMHO, but the fact that some work is being done in this area confirms the failure of SIMPLE. IMHO it's better to define a new specification for presence in SIP *from scratch* forgetting all about SIMPLE (all means all).
Anyways, integrating such new specification with xmpp with extensions, gws or whatever method is a win-win strategy.
IMHO it's a surrender. XMPP is doing nothing (at protocol/specifications level) to "integrate" with SIP. Istead they are developing VoIP features from scratch.
On 10/20/10 2:57 PM, Iñaki Baz Castillo wrote:
2010/10/20 Jon Bonillamanwe@aholab.ehu.es:
El Wed, 20 Oct 2010 13:11:22 +0200 Iñaki Baz Castilloibc@aliax.net escribió:
"Integrating" XMPP into SIP is a workaround IMHO, but the fact that some work is being done in this area confirms the failure of SIMPLE. IMHO it's better to define a new specification for presence in SIP *from scratch* forgetting all about SIMPLE (all means all).
Anyways, integrating such new specification with xmpp with extensions, gws or whatever method is a win-win strategy.
IMHO it's a surrender. XMPP is doing nothing (at protocol/specifications level) to "integrate" with SIP. Istead they are developing VoIP features from scratch.
I think it is just failure of one model over-complicated, the Presence Agent.
SIP has also end-to-end presence and it was/is working perfect in most of the cases. What is missing there is the ability to store/receive buddy list, but that can be fixed easy (via xcap or not).
Initially, SIP started as a protocol for end to end communication, where the power was in endpoint's hands. Later, when telcos and mobile operators came in, new standards were written to move "intelligence" in the core network, with the principle "smart core stupid endpoints". If you look at classic telephony, the devices are very cheap, even 5 bucks, suitable to pick up the receiver and just accept call or dial, no other functionality.
This was the wrong bet the big telephony companies did. The last years proved indubitable that people like smart tools in their hands -- look at smart phones market grow.
Another bad prediction was bandwidth in mobile networks. I remember the times when "sip compression" was seen as the only and mandatory solution to have -- just look at the specs for it and you can understand that PA specs are maybe nicer. SIP messages are less than 1% of a voice call, not to mention video where you can just completely ignore the signaling. In presence and im, SIP is a part of communication, but again, not much savings.
To have a future, the endpoints should have the power. Migration to voip happened because everyone wants just a carrier (IP network) and services, not a control of the network on capabilities of endpoints.
Cheers, Daniel
2010/10/21 Daniel-Constantin Mierla miconda@gmail.com:
I think it is just failure of one model over-complicated, the Presence Agent.
SIP has also end-to-end presence and it was/is working perfect in most of the cases.
Hi, I don't agree. SIP end-to-end presence fails when coming to privacy area as the watcher doens't receive the information from a server, but from the watched user itself (so the watcher knows if it's "online" or not). I've tryed end-to-end SIP presence and IMHO is just a toy.
Also, about XMPP and "ent-to-end" presence:
"distributing states" is done by sending <presence> stanzas. XMPP basic presence (online, offline and text note) works in this way. This is, a XMPP client gets online and sends <presence> stanza to all its non-blocked contacts to inform about its presence status. However, other presence features in XMPP as the avatar, advanced presence (like the music you are listening now), work with publish-subscribe mechanism. This mechanism is much more scalable.
Please read this short thread I open in XMPP-IETF about it: http://www.ietf.org/mail-archive/web/xmpp/current/msg01703.html
This is: publish-subscribe mechanism has also being adopted by XMPP. So IMHO this mechanism is the most suitable also for SIP, but it must be improved (the specs and features).
Regards.
Hello,
On 10/21/10 11:20 AM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin Mierlamiconda@gmail.com:
I think it is just failure of one model over-complicated, the Presence Agent.
SIP has also end-to-end presence and it was/is working perfect in most of the cases.
Hi, I don't agree. SIP end-to-end presence fails when coming to privacy area as the watcher doens't receive the information from a server, but from the watched user itself (so the watcher knows if it's "online" or not). I've tryed end-to-end SIP presence and IMHO is just a toy.
this kind of privacy is affecting the calls as well, for example. I can send you a call or other SIP request to discover you are online/offline. So this is another service that should be applied globally: black-white lists.
Having a mechanism just for presence is another bad design.
Also, about XMPP and "ent-to-end" presence:
"distributing states" is done by sending<presence> stanzas. XMPP basic presence (online, offline and text note) works in this way. This is, a XMPP client gets online and sends<presence> stanza to all its non-blocked contacts to inform about its presence status. However, other presence features in XMPP as the avatar, advanced presence (like the music you are listening now), work with publish-subscribe mechanism. This mechanism is much more scalable.
Please read this short thread I open in XMPP-IETF about it: http://www.ietf.org/mail-archive/web/xmpp/current/msg01703.html
This is: publish-subscribe mechanism has also being adopted by XMPP. So IMHO this mechanism is the most suitable also for SIP, but it must be improved (the specs and features).
With a model where client and server must develop in parallel you have always the chicken-egg problem.
While I said that some interaction between endpoint and core network has to be done (e.g., centralized rooster, hosting avatars, etc), it must be pretty much content agnostic. When the core network becomes an active player in the final content delivery of what I send, then innovation is slowed down considerably.
If you think about very popular solutions for real time communication out there, the patters is smart endpoint, dummy core network, and in most of the cases (skype, yahoo), same provider for both sides.
Telephony providers must understand they have to come with services provided by them in order for me to pay. If they put barriers because they want to charge the services I am capable alone to do, then I skip them.
Cheers, Daniel
Daniel-Constantin Mierla writes:
this kind of privacy is affecting the calls as well, for example. I can send you a call or other SIP request to discover you are online/offline. So this is another service that should be applied globally: black-white lists.
Having a mechanism just for presence is another bad design.
i agree and i implemented xcap_auth_status() function just in order to be able apply xcap rules also to MESSAGEs and INVITEs. there should be different events for those though.
-- juha
2010/10/21 Juha Heinanen jh@tutpro.com:
this kind of privacy is affecting the calls as well, for example. I can send you a call or other SIP request to discover you are online/offline. So this is another service that should be applied globally: black-white lists.
Having a mechanism just for presence is another bad design.
i agree and i implemented xcap_auth_status() function just in order to be able apply xcap rules also to MESSAGEs and INVITEs. there should be different events for those though.
There is no invite-rules neither message-rules specifications for XCAP, neither for XDM (OMA additions), just pres-rules. So we would end implementing a supposed "standard" but always introducing custom specifications to make it "logical". Then clients should also implement these custom extra layers of specs in order to interoperate properly.
When it's required to add custom specifications it means that:
- The core "standard" specifictions are not good or not enough. - Interoperability will be a pain.
For me SIMPLE/XCAP is dead many months ago.
On 10/21/10 12:09 PM, Iñaki Baz Castillo wrote:
2010/10/21 Juha Heinanenjh@tutpro.com:
this kind of privacy is affecting the calls as well, for example. I can send you a call or other SIP request to discover you are online/offline. So this is another service that should be applied globally: black-white lists.
Having a mechanism just for presence is another bad design.
i agree and i implemented xcap_auth_status() function just in order to be able apply xcap rules also to MESSAGEs and INVITEs. there should be different events for those though.
There is no invite-rules neither message-rules specifications for XCAP, neither for XDM (OMA additions), just pres-rules. So we would end implementing a supposed "standard" but always introducing custom specifications to make it "logical". Then clients should also implement these custom extra layers of specs in order to interoperate properly.
When it's required to add custom specifications it means that:
- The core "standard" specifictions are not good or not enough.
- Interoperability will be a pain.
For me SIMPLE/XCAP is dead many months ago.
if ever it was really born :-)
Still there are some good concepts that can be re-used.
I see xcap as a service offered by the telephony provider, maybe in the way CPL was designed and somehow forgotten -- iirc, with CPL you can block users.
Cheers, Daniel
2010/10/21 Daniel-Constantin Mierla miconda@gmail.com:
Hi, I don't agree. SIP end-to-end presence fails when coming to privacy area as the watcher doens't receive the information from a server, but from the watched user itself (so the watcher knows if it's "online" or not). I've tryed end-to-end SIP presence and IMHO is just a toy.
this kind of privacy is affecting the calls as well, for example. I can send you a call or other SIP request to discover you are online/offline. So this is another service that should be applied globally: black-white lists.
Having a mechanism just for presence is another bad design.
Good point. But the fail about this point is in SIMPLE specs.
I'm planning a spec for privacy rules in which a user stores in a server privacy attributes for each contact in his buddylist. These privacy attributes include "presence", "dialog", "voice", "im" along with filtering rules (for example, I want to show my presence status online/offline to a watcher, but I don't want to show him my geolocation data).
So when an INVITE or SUBSCRIBE arrives to the proxy/server, the privacy rules for this contact can be inspected so the presence/dialog SUBSCRIBE or the INVITE (voice, video, MSRP) can be allowed, rejected or "polite" blocked (480 User Not Online).
Also, about XMPP and "ent-to-end" presence:
"distributing states" is done by sending<presence> stanzas. XMPP basic presence (online, offline and text note) works in this way. This is, a XMPP client gets online and sends<presence> stanza to all its non-blocked contacts to inform about its presence status. However, other presence features in XMPP as the avatar, advanced presence (like the music you are listening now), work with publish-subscribe mechanism. This mechanism is much more scalable.
Please read this short thread I open in XMPP-IETF about it: http://www.ietf.org/mail-archive/web/xmpp/current/msg01703.html
This is: publish-subscribe mechanism has also being adopted by XMPP. So IMHO this mechanism is the most suitable also for SIP, but it must be improved (the specs and features).
With a model where client and server must develop in parallel you have always the chicken-egg problem.
But retrieving the contact avatar works in XMPP, doesn't it? :)
While I said that some interaction between endpoint and core network has to be done (e.g., centralized rooster, hosting avatars, etc), it must be pretty much content agnostic. When the core network becomes an active player in the final content delivery of what I send, then innovation is slowed down considerably.
Imagine you have 30 contacts. Having 30 presence subscriptions for each client is not very cool. This is solved with RLS subscription. The concept is good but the final specification is a pain as it requires a painful XCAP document pointintg to a painful list in a painful resource-list document, along with exotic constrains (the client must create a SIP URI unique in the server).
Now also imagine "distribute presence". You have 30 contacts. When you get online you must send 30 presentities for all your allowed contacts. Not very cool IMHO.
And worse: Not all the information a watcher wants to retrieves depends on the watched user itself. The avatar, the user profile (a vCard) is retrieved from the server (this is true in XMPP, MSN, Skype....), so "distribute presence" cannot work here. So, should we implement two mechanims for retrieving buddy's information (one for realtime presence status and other for permanent information stored in the server? I don't think this is a good design.
Regards.
On 10/21/10 12:20 PM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin Mierlamiconda@gmail.com:
Hi, I don't agree. SIP end-to-end presence fails when coming to privacy area as the watcher doens't receive the information from a server, but from the watched user itself (so the watcher knows if it's "online" or not). I've tryed end-to-end SIP presence and IMHO is just a toy.
this kind of privacy is affecting the calls as well, for example. I can send you a call or other SIP request to discover you are online/offline. So this is another service that should be applied globally: black-white lists.
Having a mechanism just for presence is another bad design.
Good point. But the fail about this point is in SIMPLE specs.
The fail is the SIP steering group, which divided to many subgroups which don't actually interact one with another. SIMPLE group looks as SIP as being the protocol only for im & p.
With xmpp, at least so far, there is the same group taking care of everything.
I'm planning a spec for privacy rules in which a user stores in a server privacy attributes for each contact in his buddylist. These privacy attributes include "presence", "dialog", "voice", "im" along with filtering rules (for example, I want to show my presence status online/offline to a watcher, but I don't want to show him my geolocation data).
So when an INVITE or SUBSCRIBE arrives to the proxy/server, the privacy rules for this contact can be inspected so the presence/dialog SUBSCRIBE or the INVITE (voice, video, MSRP) can be allowed, rejected or "polite" blocked (480 User Not Online).
Also, about XMPP and "ent-to-end" presence:
"distributing states" is done by sending<presence> stanzas. XMPP basic presence (online, offline and text note) works in this way. This is, a XMPP client gets online and sends<presence> stanza to all its non-blocked contacts to inform about its presence status. However, other presence features in XMPP as the avatar, advanced presence (like the music you are listening now), work with publish-subscribe mechanism. This mechanism is much more scalable.
Please read this short thread I open in XMPP-IETF about it: http://www.ietf.org/mail-archive/web/xmpp/current/msg01703.html
This is: publish-subscribe mechanism has also being adopted by XMPP. So IMHO this mechanism is the most suitable also for SIP, but it must be improved (the specs and features).
With a model where client and server must develop in parallel you have always the chicken-egg problem.
But retrieving the contact avatar works in XMPP, doesn't it? :)
Never tried to look deep at it :-) , probably the xmpp client does it ok.
On the other hand, this is just exchange of content, like voice call is. I can send to my peer a link to a web resource from where to download, or, the clients can start a machine-to-machine session for a file transfer. This actions are done upon my agreement on what to allow for the other peer, whether I decided to store the rules locally or used a remote storage engine like xcap or http server.
I don't like my provider to control everything related to my person. I may have different avatars for different persons or locations.
While I said that some interaction between endpoint and core network has to be done (e.g., centralized rooster, hosting avatars, etc), it must be pretty much content agnostic. When the core network becomes an active player in the final content delivery of what I send, then innovation is slowed down considerably.
Imagine you have 30 contacts. Having 30 presence subscriptions for each client is not very cool. This is solved with RLS subscription.
Indeed you reduce some traffic from client to server, but add complexity and limitations to the core of the network.
I see a business case for such services, where you get value-added features from the core. They exist for voice as well (e.g., transforming your voice). If the provider offers it and I want it, I can opt in.
But end-to-end freedom of communication must exist. Presence update is a communication to the other peer. Like we do with calls, e.g., permanent redirect, there can be static rules for im and presence. But requiring/imposing support of some functionality and control from core network would not be successful in long term.
The concept is good but the final specification is a pain as it requires a painful XCAP document pointintg to a painful list in a painful resource-list document, along with exotic constrains (the client must create a SIP URI unique in the server).
Now also imagine "distribute presence". You have 30 contacts. When you get online you must send 30 presentities for all your allowed contacts. Not very cool IMHO.
The server sends 30 notifies, so you save half of the communication. There is a feature called parallel forking, we can branch a request in as many destinations as we want. That doesn't imply states on server, just a list stored in db.
And worse: Not all the information a watcher wants to retrieves depends on the watched user itself. The avatar, the user profile (a vCard) is retrieved from the server (this is true in XMPP, MSN, Skype....), so "distribute presence" cannot work here. So, should we implement two mechanims for retrieving buddy's information (one for realtime presence status and other for permanent information stored in the server? I don't think this is a good design.
I will comment separately later, this is getting big.
Cheers, Daniel
2010/10/21 Daniel-Constantin Mierla miconda@gmail.com:
On the other hand, this is just exchange of content, like voice call is. I can send to my peer a link to a web resource from where to download
Then blocking a user not to view your avatar is not possible. Sending the image into a SIP message (as XMPP mainly does) is better IMHO.
clients can start a machine-to-machine session for a file transfer. This actions are done upon my agreement on what to allow for the other peer, whether I decided to store the rules locally or used a remote storage engine like xcap or http server.
I have a non very powerful phone, why should you send me advanced presence information if my device cannot render it? will you send a photo to my Linksys ATA? why should I receive information I'm not capable of rendering? why should I receive information I haven't asked? As I said before, XMPP solves this problem with publish-subscribe mechanism when coming to advanded presence (not just "online - I'm at home").
Subscriptions (including filters in the subscription) can help with this. Sending direct presence doesn't allow it. XMPP confirms this.
I don't like my provider to control everything related to my person. I may have different avatars for different persons or locations.
This is not impossible with centralized logic IMHO.
But end-to-end freedom of communication must exist. Presence update is a communication to the other peer.
Only if such peer has asked you for such information, am I wrong?
Like we do with calls, e.g., permanent redirect, there can be static rules for im and presence. But requiring/imposing support of some functionality and control from core network would not be successful in long term.
Yes, but as I said before, how can a watcher get information from you when you are offline (this is, you cannot send such information from your device to the watcher)? Couldn't the watcher get your vcard or your avatar neither your offline status information? if this feature makes sense (and IMHO it does as exists in all the IM/presence protocols) how to implement it without subscription?
The server sends 30 notifies, so you save half of the communication. There is a feature called parallel forking, we can branch a request in as many destinations as we want. That doesn't imply states on server, just a list stored in db.
So then I cannot filter some information to some specific watchers (i.e: I want a specific watcher not to see my geolocation).
And worse: Not all the information a watcher wants to retrieves depends on the watched user itself. The avatar, the user profile (a vCard) is retrieved from the server (this is true in XMPP, MSN, Skype....), so "distribute presence" cannot work here. So, should we implement two mechanims for retrieving buddy's information (one for realtime presence status and other for permanent information stored in the server? I don't think this is a good design.
I will comment separately later, this is getting big.
There is a lot to discuss about it, even more than the sum of RFC's about SIMPLE XD
Regards.
On 10/21/10 4:15 PM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin Mierlamiconda@gmail.com:
On the other hand, this is just exchange of content, like voice call is. I can send to my peer a link to a web resource from where to download
Then blocking a user not to view your avatar is not possible.
If you mean that by current specs, could be. I was referring to what seems better for me. Any kind of end-to-end content exchange should be processed by end device rules.
Sending the image into a SIP message (as XMPP mainly does) is better IMHO.
clients can start a machine-to-machine session for a file transfer. This actions are done upon my agreement on what to allow for the other peer, whether I decided to store the rules locally or used a remote storage engine like xcap or http server.
I have a non very powerful phone, why should you send me advanced presence information if my device cannot render it?
I send to you because you asked. If you don't subscribe to that resource, I don't send it.
Where did you get the I idea that everything is sent to everybody?
On the other hand, if your phone subscribes to my shoes-size-changes, my phone can notify you using 2d barcode payload, but the server does not know how to mix it, would you feel better paying NNNN bucks for the device and the provider tells you it is not supported?
will you send a photo to my Linksys ATA? why should I receive information I'm not capable of rendering? why should I receive information I haven't asked?
I have also many questions why you have such questions now. Nobody is sending anything if not asked.
As I said before, XMPP solves this problem with publish-subscribe mechanism when coming to advanded presence (not just "online - I'm at home").
Again, this is not presence specific, imo. If I call you and you are not registered, I get to your voicemail, or to your mobile, or ... If I am not online and you ask for my presence, the request can be replied with some default/predefined states.
When I become online, I have my list of buddies and take care to tell them.
Subscriptions (including filters in the subscription) can help with this. Sending direct presence doesn't allow it. XMPP confirms this.
I don't like my provider to control everything related to my person. I may have different avatars for different persons or locations.
This is not impossible with centralized logic IMHO.
Centralize logic should be the routing, not the content of communication. That can come extra, as additional service, if I want to opt in for it.
For me, a man-in-the-middle like presence server trying to understand everything would be like an English voice analyzer on server for each call dropping everything that couldn't be understood as good English. So if you want to talk with your parents and the provider does not support Spanish, you have two options: - screw the provider - tell your parents by snail mail they have to use english when in a call with you
But end-to-end freedom of communication must exist. Presence update is a communication to the other peer.
Only if such peer has asked you for such information, am I wrong?
There was not at all a discard of subscriptions. That must exist, the discussion was who and how should handle subscriptions.
Like we do with calls, e.g., permanent redirect, there can be static rules for im and presence. But requiring/imposing support of some functionality and control from core network would not be successful in long term.
Yes, but as I said before, how can a watcher get information from you when you are offline (this is, you cannot send such information from your device to the watcher)?
Do you get my ring-back tone from my phone when you call and I am offline? You get the voicebox service which I set for such cases. For presence you may get as well a pre-defined state or document.
Like with voicemail, I can record a message and say "Hi, you called XYZ, leave the message..." or simple "Leave the message after...". Same I can publish my vcard for such cases or not, combined with black-white lists, the privacy can be controlled in the same way for all SIP based services.
Couldn't the watcher get your vcard or your avatar neither your offline status information? if this feature makes sense (and IMHO it does as exists in all the IM/presence protocols) how to implement it without subscription?
The server sends 30 notifies, so you save half of the communication. There is a feature called parallel forking, we can branch a request in as many destinations as we want. That doesn't imply states on server, just a list stored in db.
So then I cannot filter some information to some specific watchers (i.e: I want a specific watcher not to see my geolocation).
If your client is able to send such details, then it has the list with who is allowed and disallowed.
As I said, this list can be stored on server, so you can retrieved. But I do not see the reason why the server must know what my client can publish and to mix/process it.
Rooting the debate: - subscription mechanism is good, the bad part now is who interprets it - storing various resources, being it your voicemail message, redirect number, white-black lists, is an useful service - all signaling optimization attempts were big failures (see sip compression) - today, more than ever, trends are for smart end devices - to be successful, a new technology has to be _simple_ : easy to implement and use, without complex dependency constraints to deploy
Failing again to see that by time an "optimization" spec is implemented, the bandwidth and processing power are far ahead, may be a safe bet for disaster.
Cheers, Daniel
On 10/21/10 4:15 PM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin Mierlamiconda@gmail.com:
On the other hand, this is just exchange of content, like voice call is. I can send to my peer a link to a web resource from where to download
Then blocking a user not to view your avatar is not possible.
If you mean that by current specs, could be. I was referring to what seems better for me. Any kind of end-to-end content exchange should be processed by end device rules.
Sending the image into a SIP message (as XMPP mainly does) is better IMHO.
clients can start a machine-to-machine session for a file transfer. This actions are done upon my agreement on what to allow for the other peer, whether I decided to store the rules locally or used a remote storage engine like xcap or http server.
I have a non very powerful phone, why should you send me advanced presence information if my device cannot render it?
I send to you because you asked. If you don't subscribe to that resource, I don't send it.
Where did you get the I idea that everything is sent to everybody?
On the other hand, if your phone subscribes to my shoes-size-changes, my phone can notify you using 2d barcode payload, but the server does not know how to mix it, would you feel better paying NNNN bucks for the device and the provider tells you it is not supported?
will you send a photo to my Linksys ATA? why should I receive information I'm not capable of rendering? why should I receive information I haven't asked?
I have also many questions why you have such questions now. Nobody is sending anything if not asked.
As I said before, XMPP solves this problem with publish-subscribe mechanism when coming to advanded presence (not just "online - I'm at home").
Again, this is not presence specific, imo. If I call you and you are not registered, I get to your voicemail, or to your mobile, or ... If I am not online and you ask for my presence, the request can be replied with some default/predefined states.
When I become online, I have my list of buddies and take care to tell them.
Subscriptions (including filters in the subscription) can help with this. Sending direct presence doesn't allow it. XMPP confirms this.
I don't like my provider to control everything related to my person. I may have different avatars for different persons or locations.
This is not impossible with centralized logic IMHO.
Centralize logic should be the routing, not the content of communication. That can come extra, as additional service, if I want to opt in for it.
For me, a man-in-the-middle like presence server trying to understand everything would be like an English voice analyzer on server for each call dropping everything that couldn't be understood as good English. So if you want to talk with your parents and the provider does not support Spanish, you have two options: - screw the provider - tell your parents by snail mail they have to use english when in a call with you
But end-to-end freedom of communication must exist. Presence update is a communication to the other peer.
Only if such peer has asked you for such information, am I wrong?
There was not at all a discard of subscriptions. That must exist, the discussion was who and how should handle subscriptions.
Like we do with calls, e.g., permanent redirect, there can be static rules for im and presence. But requiring/imposing support of some functionality and control from core network would not be successful in long term.
Yes, but as I said before, how can a watcher get information from you when you are offline (this is, you cannot send such information from your device to the watcher)?
Do you get my ring-back tone from my phone when you call and I am offline? You get the voicebox service which I set for such cases. For presence you may get as well a pre-defined state or document.
Like with voicemail, I can record a message and say "Hi, you called XYZ, leave the message..." or simple "Leave the message after...". Same I can publish my vcard for such cases or not, combined with black-white lists, the privacy can be controlled in the same way for all SIP based services.
Couldn't the watcher get your vcard or your avatar neither your offline status information? if this feature makes sense (and IMHO it does as exists in all the IM/presence protocols) how to implement it without subscription?
The server sends 30 notifies, so you save half of the communication. There is a feature called parallel forking, we can branch a request in as many destinations as we want. That doesn't imply states on server, just a list stored in db.
So then I cannot filter some information to some specific watchers (i.e: I want a specific watcher not to see my geolocation).
If your client is able to send such details, then it has the list with who is allowed and disallowed.
As I said, this list can be stored on server, so you can retrieved. But I do not see the reason why the server must know what my client can publish and to mix/process it.
Rooting the debate: - subscription mechanism is good, the bad part now is who interprets it - storing various resources, being it your voicemail message, redirect number, white-black lists, is an useful service - all signaling optimization attempts were big failures (see sip compression) - today, more than ever, trends are for smart end devices - to be successful, a new technology has to be _simple_ : easy to implement and use, without complex dependency constraints to deploy
Failing again to see that by time an "optimization" spec is implemented, the bandwidth and processing power are far ahead, may be a safe bet for disaster.
Cheers, Daniel
Daniel-Constantin Mierla writes:
I send to you because you asked. If you don't subscribe to that resource, I don't send it.
if all intelligence is in the UA, how about subscriptions themselves? do i need to receive them even when my UA does not implement SUBSCRIBE request or i don't want to get spammed by them from unknown sources?
in my opinion, some control in the network is useful especially when i have to pay per volume on my mobile device.
-- juha
On 10/21/10 5:35 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I send to you because you asked. If you don't subscribe to that resource, I don't send it.
if all intelligence is in the UA, how about subscriptions themselves? do i need to receive them even when my UA does not implement SUBSCRIBE request or i don't want to get spammed by them from unknown sources?
This is sorted out by location server. iirc, you implemented the filtering based on allowed methods.
in my opinion, some control in the network is useful especially when i have to pay per volume on my mobile device.
Going beyond the above consideration where a solution already exists and it is in place for many years, my concern was how long pay-per-volume will last thinking of current smart phone market pressure that worth to make a complex design costing fortunes to implement (e.g., IMS) and how much will turn in profit for a narrow niche.
There are other services sending shorter or longer notifications heavily used on mobiles, e.g., twitter, facebook. People are using them more than any presence system. Skype is largely used as well, with no intelligence in the network for processing the content.
Therefore, in the context of Inaki's building new specs for presence, the near future predictions and current market trends must play a major role.
Cheers, Daniel
Daniel-Constantin Mierla writes:
This is sorted out by location server. iirc, you implemented the filtering based on allowed methods.
yes, that takes care of sending subscribe to ua that does not support it. the sad thing is that there are UAs on the marker that don't advertise their supported methods in register request.
Going beyond the above consideration where a solution already exists and it is in place for many years, my concern was how long pay-per-volume will last thinking of current smart phone market pressure that worth to make a complex design costing fortunes to implement (e.g., IMS) and how much will turn in profit for a narrow niche.
just today i heard in radio news that some operators who currently have flat rate data service are planning to go for metered one. they claim that with current flat rates, it is not possible to keep on upgrading mobile network capacity. i don't think that vodafone, for example, is offering flat rate data service anywhere in the world. i hope that i'm wrong, but i would not at this stage count on flat rate mobile data. and it is not just the cost, i simply don't want to get SIP spammed by unauthorized sources.
-- juha
On 10/21/10 6:16 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
This is sorted out by location server. iirc, you implemented the filtering based on allowed methods.
yes, that takes care of sending subscribe to ua that does not support it. the sad thing is that there are UAs on the marker that don't advertise their supported methods in register request.
Fortunately is more present than xcap support and even better, easier to implement.
Going beyond the above consideration where a solution already exists and it is in place for many years, my concern was how long pay-per-volume will last thinking of current smart phone market pressure that worth to make a complex design costing fortunes to implement (e.g., IMS) and how much will turn in profit for a narrow niche.
just today i heard in radio news that some operators who currently have flat rate data service are planning to go for metered one. they claim that with current flat rates, it is not possible to keep on upgrading mobile network capacity. i don't think that vodafone, for example, is offering flat rate data service anywhere in the world. i hope that i'm wrong, but i would not at this stage count on flat rate mobile data. and it is not just the cost, i simply don't want to get SIP spammed by unauthorized sources.
This is true (ie, some mobile operators limiting the flat rate), but the main reason is voice/video communication over 3g, bypassing their voice services, whatever they say publicly.
Regarding the spam, I guess it would be more annoying to get calls from unauthorized sources, so should be no difference between authorizing voice, im, presence or something else via sip.
Cheers, Daniel
On 10/21/10 4:15 PM, Iñaki Baz Castillo wrote:
[...]
And worse: Not all the information a watcher wants to retrieves depends on the watched user itself. The avatar, the user profile (a vCard) is retrieved from the server (this is true in XMPP, MSN, Skype....), so "distribute presence" cannot work here. So, should we implement two mechanims for retrieving buddy's information (one for realtime presence status and other for permanent information stored in the server? I don't think this is a good design.
I will comment separately later, this is getting big.
There is a lot to discuss about it, even more than the sum of RFC's about SIMPLE XD
The problem with specs is like in life with ideas. Each of us has many ideas but either they prove unrealistics on a second thought or even they seem good sometime there is no enough time to implement all.
These specs are like ideas written down and published.
Back to first paragraph. Are XMPP, MSN, Skype doing processing to these documents, or are they just pure storage systems for them with a white/black list access policy? In other words, I can publish my vcard and then tell the server if X ask for it, don't send my email address, just my web site address?
Cheers, Daniel
2010/10/21 Daniel-Constantin Mierla miconda@gmail.com:
Back to first paragraph. Are XMPP, MSN, Skype doing processing to these documents, or are they just pure storage systems for them with a white/black list access policy? In other words, I can publish my vcard and then tell the server if X ask for it, don't send my email address, just my web site address?
In both XMPP and MSN the avatar and vcard are retrieved by a watcher from the server if the watched gives the watcher permissions, so the server *does* interpret the permissions rules in behalf of the user. How to achieve this logic in a non-centralized architecture? I cannot imagine it.
So, if we assume that the "server" must be active part on the subscription (it must interpret permissions and know about subscriptions) then, why to implement in other way (direct/end-to-end presence) presence status retrieval when the watched user is online? two mechanisms?
On 10/21/10 6:20 PM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin Mierlamiconda@gmail.com:
Back to first paragraph. Are XMPP, MSN, Skype doing processing to these documents, or are they just pure storage systems for them with a white/black list access policy? In other words, I can publish my vcard and then tell the server if X ask for it, don't send my email address, just my web site address?
In both XMPP and MSN the avatar and vcard are retrieved by a watcher from the server if the watched gives the watcher permissions, so the server *does* interpret the permissions rules in behalf of the user. How to achieve this logic in a non-centralized architecture? I cannot imagine it.
Maybe is a misunderstanding here. Hope you haven't understood that there will no server involved and is kind of peer-to-peer network like skype.
But everything in the server is just routing to resources. Authorizations rules exist and we apply them for many years for voice calls. But we don't authorize typically the content (e.g., not allowed to speak Spanish on a call).
So, if we assume that the "server" must be active part on the subscription (it must interpret permissions and know about subscriptions) then, why to implement in other way (direct/end-to-end presence) presence status retrieval when the watched user is online? two mechanisms?
Interpreting the permission of routing to a resource (being it my vcard, voicemail, my phone, etc) is there and should be reused. With some phones you have DND on it, or with some services you have it in the server (managed via ivr or web or a special key on the (Snom) phone sending an update to server).
The problem right now is interpreting the content - presence information is content. If the server does not understand the Event you subscribe to, bye bye...
Cheers, Daniel
Daniel-Constantin Mierla writes:
The problem right now is interpreting the content - presence information is content. If the server does not understand the Event you subscribe to, bye bye...
i agree with that. in one sip ua is was not possible to configure voicemail uri. it assumed that it is the same as ua's own uri and that sip proxy is "smart" enough route the subscribe to user's voicemail server based on "message-summary" in Event header. i argued that requests should be routed by proxy on r-uri only. they accepted that and made it possible to configure voicemail uri.
-- juha
2010/10/21 Juha Heinanen jh@tutpro.com:
i argued that requests should be routed by proxy on r-uri only.
Hi, this is not true in all cases. For example when a user sip:alice@dom.com sends a PUBLISH with presence information, the RURI MUST also si sip:alice@dom.com, so if the proxy routes it to the locations of Alice there would be a crazy loop.
The proxy must be ready to route a request not just based on the RURI but also on the method and also on the Event type (a PUBLISH for "presence" must be routed to the presence server while a PUBLISH for "dialog" must be routed to some other server).
Iñaki Baz Castillo writes:
The proxy must be ready to route a request not just based on the RURI but also on the method and also on the Event type (a PUBLISH for "presence" must be routed to the presence server while a PUBLISH for "dialog" must be routed to some other server).
inaki,
method is part of first line and could be used for routing, but never Event header, because then you are immediately in the situation that where innovation is killed when proxy has not heard of event "foo".
-- juha
2010/10/21 Juha Heinanen jh@tutpro.com:
method is part of first line and could be used for routing, but never Event header, because then you are immediately in the situation that where innovation is killed when proxy has not heard of event "foo".
Then how do you get the proxy routing "Event: presence" PUBLISH to a server-1 and "Event: dialog" PUBLISH to server-2?
Also, innovation would also be killed in case the proxy receives an initial request with unknown SIP method. This is: a proxy knows what to do with an INVITE, REGISTER, OPTIONS... but what should it do with CHICKEN? depending of the nature of the method, it's important/required that the proxy knows it to route it properly.
Iñaki Baz Castillo writes:
Then how do you get the proxy routing "Event: presence" PUBLISH to a server-1 and "Event: dialog" PUBLISH to server-2?
you cannot do it. it is not supported.
Also, innovation would also be killed in case the proxy receives an initial request with unknown SIP method. This is: a proxy knows what to do with an INVITE, REGISTER, OPTIONS... but what should it do with CHICKEN? depending of the nature of the method, it's important/required that the proxy knows it to route it properly.
i agree and therefore presence spec is badly broken when/if it says that request uri in publish should the same as the uri of presentity. request uri should be that of presence server for the event in question and from header should tell whose presence is being published.
-- juha
2010/10/21 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
Then how do you get the proxy routing "Event: presence" PUBLISH to a server-1 and "Event: dialog" PUBLISH to server-2?
you cannot do it. it is not supported.
Could you explain it please?
Also, innovation would also be killed in case the proxy receives an initial request with unknown SIP method. This is: a proxy knows what to do with an INVITE, REGISTER, OPTIONS... but what should it do with CHICKEN? depending of the nature of the method, it's important/required that the proxy knows it to route it properly.
i agree and therefore presence spec is badly broken when/if it says that request uri in publish should the same as the uri of presentity. request uri should be that of presence server for the event in question and from header should tell whose presence is being published.
Probably. Iasked exactly this question about PUbLISH and RURI in sip-implementors and got the response I've told to you in my previous mail.
The advantaje of PUBLISH having same RURI as From URI is the fact that the client doesn't require to be provisioned with a "presence server URI".
Iñaki Baz Castillo writes:
Then how do you get the proxy routing "Event: presence" PUBLISH to a server-1 and "Event: dialog" PUBLISH to server-2?
you cannot do it. it is not supported.
Could you explain it please?
there is not much to explain. request uri must tell where request is routed. if that is not enough, then proxy needs to get involved with application level stuff, which locks its use to well known applications.
The advantaje of PUBLISH having same RURI as From URI is the fact that the client doesn't require to be provisioned with a "presence server URI".
yes, and the disadvantage is that proxy needs to be provisioned for all possible events/headers people may ever invent, i.e., task impossible.
-- juha
2010/10/21 Juha Heinanen jh@tutpro.com:
Could you explain it please?
there is not much to explain. request uri must tell where request is routed. if that is not enough, then proxy needs to get involved with application level stuff, which locks its use to well known applications.
IMHO inspecting a specific header (Event) when the request is PUBLISH is not so much effort for a proxy. More below.
The advantaje of PUBLISH having same RURI as From URI is the fact that the client doesn't require to be provisioned with a "presence server URI".
yes, and the disadvantage is that proxy needs to be provisioned for all possible events/headers people may ever invent, i.e., task impossible.
The fact is that I agree with you. But note that with REGISTER the same occurs. It's very common an architecture in which the client is just provisioned with a domain name, which resolved to its proxy, and such proxy router the REGISTER to a registrar server (even if the RURI of the REGISTER just contains the proxy's domain).
Iñaki Baz Castillo writes:
The fact is that I agree with you. But note that with REGISTER the same occurs. It's very common an architecture in which the client is just provisioned with a domain name, which resolved to its proxy, and such proxy router the REGISTER to a registrar server (even if the RURI of the REGISTER just contains the proxy's domain).
rfc3261 allows that the ua is configured with address of registrar. in fact, there are sip UAs that allow configuring registrar differently from proxy. if proxy happens to know about registrar or some presence events, it is good luck. you cannot assume it.
-- juha
2010/10/21 Juha Heinanen jh@tutpro.com:
rfc3261 allows that the ua is configured with address of registrar. in fact, there are sip UAs that allow configuring registrar differently from proxy.
Yes, but isn't nicer provisioning a UA just with AoR, password and domain letting DNS NAPTR/SRV and routing in the proxy to do their magic? :)
if proxy happens to know about registrar or some presence events, it is good luck. you cannot assume it.
Typically if a provider offers presence service its proxy should be ready for that.
Iñaki Baz Castillo writes:
Yes, but isn't nicer provisioning a UA just with AoR, password and domain letting DNS NAPTR/SRV and routing in the proxy to do their magic? :)
you need to draw the line somewhere regarding how much magic proxy does and knows about. there are many levels to it: method, event, content, etc.
-- juha
2010/10/21 Juha Heinanen jh@tutpro.com:
Yes, but isn't nicer provisioning a UA just with AoR, password and domain letting DNS NAPTR/SRV and routing in the proxy to do their magic? :)
you need to draw the line somewhere regarding how much magic proxy does and knows about. there are many levels to it: method, event, content, etc.
Until now, I've only needed routing logic based on method and event (for PUBLISH). No more cases.
On 10/21/10 9:31 PM, Juha Heinanen wrote:
Iñaki Baz Castillo writes:
Yes, but isn't nicer provisioning a UA just with AoR, password and domain letting DNS NAPTR/SRV and routing in the proxy to do their magic? :)
you need to draw the line somewhere regarding how much magic proxy does and knows about. there are many levels to it: method, event, content, etc.
talking about provisioning, this is another PITA with SIP.
Why not providing just ip/domain, username and password? Then the reply of 200ok for register can contain the other details, like SIP AoR, outbound proxy address, even a new registrar address - first registration to be just service discovery (maybe using a different method first time). Simple format, keyword=value, if you understand the keyword, use the value, otherwise ignore.
Ok, ok, I know the answer, according to RFC you can use the SIP phone without a server and call by IP:port, so you have to be able to set your own details. Right ... we all use it this way and it is very easy to do such dialing with any of the hardware phones today...
Cheers, Daniel
2010/10/21 Daniel-Constantin Mierla miconda@gmail.com:
In both XMPP and MSN the avatar and vcard are retrieved by a watcher from the server if the watched gives the watcher permissions, so the server *does* interpret the permissions rules in behalf of the user. How to achieve this logic in a non-centralized architecture? I cannot imagine it.
Maybe is a misunderstanding here. Hope you haven't understood that there will no server involved and is kind of peer-to-peer network like skype.
But everything in the server is just routing to resources. Authorizations rules exist and we apply them for many years for voice calls. But we don't authorize typically the content (e.g., not allowed to speak Spanish on a call).
Daniel, after re-reading your mails I strongly think we agree more than we think ;)
I also *hate* the mechanism in which the server MUST inspect the document content in order to filter it and notify the watched with a filtered version. This is a pain, and that is the base of SIMPLE in which multiple presentities must be merged in the server, in which the server must inspect the XML nodes of the resulting presentity and filter it for each watched based on privady rules and deliver it via NOTIFY. I hate it.
So what I have in mind is a different approach. Imagine this case:
- Alice has two active resources, both of them publishing basic presence status ("online"/"busy".... "I'm at home" / "I'm at work very unhappy"). These PUBLISH have "Event: presence+status".
- There is also a geolocation presence agent which in some way get's the registration location of both resources of Alice and generates two PUBLISH "Event: presence+geolocation" (one in behalf of echa resource).
- The server DOESN'T merge these 4 presentities. Instead it stores in a database each one with fields "event", "content".
- Alice has a buddylist in the server in which there is a contact Bob for which Alice allows showing him "presence+status" information, but not "presence+geolocation".
- Bob susbcribes to Alice's presence by *indicating* in the SUBSCRIBE body he is interested in "presence+status" and "presence+geolocation" events (as Bob's device doesn't understand/implement other presence information and couldn't render it).
- The presence server accepts the subscription (as it checks in Alice's buddylist that Bob is authorized for "Event: presence").
- The presence server also inspects in Alice's buddylist that Bob is just allowed for "presence+status".
- So the presence server sends Bob just two NOTIFY's (never merging documents), the first one containing the presecen+status of Alice's resource-1 and the second one containing the presecen+status of Alice's resource-2.
Advantages of this model:
- The server NEVER NEVER NEVER inspects the content of a PUBLISH.
- The subscriber (Bob) can tell the server which events he is interested in (not to receive information it cannot render).
- The watched (Alice) can decide which events each watcher is allowed to.
Another subject is the permanent information (i.e. "vCard") which is stored in the server. How the client (Alice) stores its vCard/avatar into the server is out of the scope of this brief description, but for sure we don't want XCAP. IMHO a new SIP method is required (in my idea the new method STORE makes sense).
- Alice set privacy attributes for her buddy Bob, so it allows him to watch these information: - presence+status - vcard This information is stored within Bob buddy in Alice's buddylist (in the server).
- Alice uses STORE method to store a vcard in the server.
- Now Bob subscribes to "Event: vcard" of Alice.
- The server inspects Alice's buddylist and finds that Bob is allowed for retrieving the vcard of Alice.
- The server then sends Bob a NOTIFY containing the vCard of Alice.
- Alice's gets online and upload a new version of her vCard (or changes it offline via web...).
- The server then sends Bob a new NOTIFY with the new vCard.
Does this fit better your concept of presence? :)
Regards.
2010/10/21 Iñaki Baz Castillo ibc@aliax.net:
- Bob susbcribes to Alice's presence by *indicating* in the SUBSCRIBE
body he is interested in "presence+status" and "presence+geolocation" events (as Bob's device doesn't understand/implement other presence information and couldn't render it).
Posible example of such SUBSCRIBE:
------------------------- SUBSCRIBE sip:alice@dmain.com SIP/2.0 From: sip:bob@domain.net;tag=asdasd Event: presence Content-Type: application/subscription+json
{ "filter" : [ "status", "geolocation" ] } --------------------------
This tells the presnce server that the watched wants to subscribe to "presence" event of Alice, but just for "status" and "geolocation" information (maybe called sub-events). Just an idea.
On 10/21/10 7:34 PM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin Mierlamiconda@gmail.com:
In both XMPP and MSN the avatar and vcard are retrieved by a watcher from the server if the watched gives the watcher permissions, so the server *does* interpret the permissions rules in behalf of the user. How to achieve this logic in a non-centralized architecture? I cannot imagine it.
Maybe is a misunderstanding here. Hope you haven't understood that there will no server involved and is kind of peer-to-peer network like skype.
But everything in the server is just routing to resources. Authorizations rules exist and we apply them for many years for voice calls. But we don't authorize typically the content (e.g., not allowed to speak Spanish on a call).
Daniel, after re-reading your mails I strongly think we agree more than we think ;)
perhaps was more a misinterpretation of some of the comments send around from different points :-) .
I also *hate* the mechanism in which the server MUST inspect the document content in order to filter it and notify the watched with a filtered version. This is a pain, and that is the base of SIMPLE in which multiple presentities must be merged in the server, in which the server must inspect the XML nodes of the resulting presentity and filter it for each watched based on privady rules and deliver it via NOTIFY. I hate it.
So what I have in mind is a different approach. Imagine this case:
- Alice has two active resources, both of them publishing basic
presence status ("online"/"busy".... "I'm at home" / "I'm at work very unhappy"). These PUBLISH have "Event: presence+status".
- There is also a geolocation presence agent which in some way get's
the registration location of both resources of Alice and generates two PUBLISH "Event: presence+geolocation" (one in behalf of echa resource).
- The server DOESN'T merge these 4 presentities. Instead it stores in
a database each one with fields "event", "content".
- Alice has a buddylist in the server in which there is a contact Bob
for which Alice allows showing him "presence+status" information, but not "presence+geolocation".
- Bob susbcribes to Alice's presence by *indicating* in the SUBSCRIBE
body he is interested in "presence+status" and "presence+geolocation" events (as Bob's device doesn't understand/implement other presence information and couldn't render it).
- The presence server accepts the subscription (as it checks in
Alice's buddylist that Bob is authorized for "Event: presence").
- The presence server also inspects in Alice's buddylist that Bob is
just allowed for "presence+status".
- So the presence server sends Bob just two NOTIFY's (never merging
documents), the first one containing the presecen+status of Alice's resource-1 and the second one containing the presecen+status of Alice's resource-2.
Advantages of this model:
The server NEVER NEVER NEVER inspects the content of a PUBLISH.
The subscriber (Bob) can tell the server which events he is
interested in (not to receive information it cannot render).
- The watched (Alice) can decide which events each watcher is allowed to.
Another subject is the permanent information (i.e. "vCard") which is stored in the server. How the client (Alice) stores its vCard/avatar into the server is out of the scope of this brief description, but for sure we don't want XCAP. IMHO a new SIP method is required (in my idea the new method STORE makes sense).
- Alice set privacy attributes for her buddy Bob, so it allows him to
watch these information:
- presence+status
- vcard
This information is stored within Bob buddy in Alice's buddylist (in the server).
Alice uses STORE method to store a vcard in the server.
Now Bob subscribes to "Event: vcard" of Alice.
The server inspects Alice's buddylist and finds that Bob is allowed
for retrieving the vcard of Alice.
The server then sends Bob a NOTIFY containing the vCard of Alice.
Alice's gets online and upload a new version of her vCard (or
changes it offline via web...).
- The server then sends Bob a new NOTIFY with the new vCard.
Does this fit better your concept of presence? :)
Maybe we are poisoned by the current specs and still are stuck in some concepts here.
There are two aspects: 1) real time communication routing - voice, im, presence states 2) offline resource routing - vcard, predefined-content documents
1) can always have a correspondent in 2) while some things in 2) might not be in 1).
Normally every user wants to do 1), but if the peer is offline, then server can have the capability to re-route to corresponding resource in 2) (like now with redirect to voicemail).
The things that are in 2) without a correspondent in 1) are on-demand resources. Do I need to get a notification that you changed your vcard immediately you do it? I would say no, I need to do it when I need to email, send a snail mail, etc. which may happen when you are offline so the server storage comes in the picture and sends it to me upon my request and your authorization rules for that resource. That can be done very easy in the reply body, without a need to create a dialog state in the server and send notifies.
Cheers, Daniel
2010/10/21 Daniel-Constantin Mierla miconda@gmail.com:
There are two aspects:
real time communication routing - voice, im, presence states
offline resource routing - vcard, predefined-content documents
can always have a correspondent in 2) while some things in 2) might not
be in 1).
Normally every user wants to do 1), but if the peer is offline, then server can have the capability to re-route to corresponding resource in 2) (like now with redirect to voicemail).
The things that are in 2) without a correspondent in 1) are on-demand resources. Do I need to get a notification that you changed your vcard immediately you do it? I would say no, I need to do it when I need to email, send a snail mail, etc. which may happen when you are offline so the server storage comes in the picture and sends it to me upon my request and your authorization rules for that resource. That can be done very easy in the reply body, without a need to create a dialog state in the server and send notifies.
Interesting proposal. Let me some questions:
1) - Alice has two active resources (alice-1and alice-2). - alice-1 uploads a new vCard. How is alice-2 notified about that change if there is no possibility of subscription to the vcard?
2) IMHO avatar should be part of the vCard (as vCard already includes photo and so): - Alice is subscribed to Bob's presence (just presence). - Alice retrieves the vCard (including avatar) of Bob. But there is no subscription as you said. - Bob uploads a new version of his vCard with a new photo. How is Alice being notified about the change to display the new avatar?
3) Where is the limit to say "this info requires subscription but this one not"?
On 10/21/10 11:21 PM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin Mierlamiconda@gmail.com:
There are two aspects:
real time communication routing - voice, im, presence states
offline resource routing - vcard, predefined-content documents
can always have a correspondent in 2) while some things in 2) might not
be in 1).
Normally every user wants to do 1), but if the peer is offline, then server can have the capability to re-route to corresponding resource in 2) (like now with redirect to voicemail).
The things that are in 2) without a correspondent in 1) are on-demand resources. Do I need to get a notification that you changed your vcard immediately you do it? I would say no, I need to do it when I need to email, send a snail mail, etc. which may happen when you are offline so the server storage comes in the picture and sends it to me upon my request and your authorization rules for that resource. That can be done very easy in the reply body, without a need to create a dialog state in the server and send notifies.
Interesting proposal. Let me some questions:
- Alice has two active resources (alice-1and alice-2).
- alice-1 uploads a new vCard.
How is alice-2 notified about that change if there is no possibility of subscription to the vcard?
Why it needs to be notified immediately? I haven't said that there is no subscription, but for some cases are just kind of "stateless subscription".
Phone sends subscribe for a resource and gets the document in the reply if allowed or a negative reply if not allowed. Timestamps can be used to mark it has not be changed (like in http).
IMHO avatar should be part of the vCard (as vCard already includes photo and so):
- Alice is subscribed to Bob's presence (just presence).
- Alice retrieves the vCard (including avatar) of Bob. But there is no
subscription as you said.
- Bob uploads a new version of his vCard with a new photo.
How is Alice being notified about the change to display the new avatar?
Avatar and photo in vcard can be different, but anyhow, not the scope here.
In the light of useless traffic that can cost and not only that, would it bring benefits that the avatar is updated in realtime by your application even it is in standby and you don't want to communicate with that user? Or the application is asking for updates when is some activity related to that user? If there is no activity for a long time, it can do a periodic refresh, anyhow many SIP mechanisms require periodic actions.
Where is the limit to say "this info requires subscription but this one not"?
All require subscriptions, but in many cases is no state associated with, just one time pull of status/document. I haven't thought thoroughly, but I hope the servers don't need to know subscription states, only authorization rules, which are just stored documents and should be generic, not a language related to presence, but authorization for any kind of resources.
Cheers, Daniel
2010/10/22 Daniel-Constantin Mierla miconda@gmail.com:
- Alice has two active resources (alice-1and alice-2).
- alice-1 uploads a new vCard.
How is alice-2 notified about that change if there is no possibility of subscription to the vcard?
Why it needs to be notified immediately? I haven't said that there is no subscription, but for some cases are just kind of "stateless subscription".
Phone sends subscribe for a resource and gets the document in the reply if allowed or a negative reply if not allowed. Timestamps can be used to mark it has not be changed (like in http).
IMHO avatar should be part of the vCard (as vCard already includes photo and so):
- Alice is subscribed to Bob's presence (just presence).
- Alice retrieves the vCard (including avatar) of Bob. But there is no
subscription as you said.
- Bob uploads a new version of his vCard with a new photo.
How is Alice being notified about the change to display the new avatar?
Avatar and photo in vcard can be different, but anyhow, not the scope here.
In the light of useless traffic that can cost and not only that, would it bring benefits that the avatar is updated in realtime by your application even it is in standby and you don't want to communicate with that user? Or the application is asking for updates when is some activity related to that user? If there is no activity for a long time, it can do a periodic refresh, anyhow many SIP mechanisms require periodic actions.
Where is the limit to say "this info requires subscription but this one not"?
All require subscriptions, but in many cases is no state associated with, just one time pull of status/document. I haven't thought thoroughly, but I hope the servers don't need to know subscription states, only authorization rules, which are just stored documents and should be generic, not a language related to presence, but authorization for any kind of resources.
Hi Daniel, any "subscription" mechanism means PULL: the subscriber is informed *by the server* about changes, so the server notifies the user. In case of SIP this is achieved with a NOTIFY. But you are speaking about PUSH: the interested user sends a periodic request to the server to get possible new changes. IMHO this cannot be called "subscription" neither "stateless subscription".
So, when you say "Phone sends subscribe for a resource and gets the document in the reply" I would prefer "Phone sends a like-GET request for a resource and gets the document in the reply". There is no way in SIP to retrieve data without using subscription (which means the data is sent in the NOTIFY, never in the 200 to the SUBSCRIBE). But here we can introduce a new SIP method, As I told before, STORE method could be use for uploading content or retrieving it (depending on a header, URI parameter or whatever stil to define).
Do we agree here? :)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Jon Bonilla -
Juha Heinanen -
Victor Pascual Avila