Re: Communication means in draft-ietf-impp-cpim-pidf-05

Adrian Bateman wrote:
> 
> > As I see, sip: alone is not enough for defining the communication
> > mean. If I wanted to publish communication means like voice, video,
> > chat, game, etc., all of them would have probably SIP URIs. It would
> > be preferable to indicate for the watchers which SIP URI is for chat
> > and which one is for voice calls.
> 
> Isn't that a problem with the SIP URI? If I was making up a URI scheme
> and these things were important, I'd probably include them. If I don't,
> it probably means use whatever my device can do that the other end
> supports, maybe tending towards the highest fidelity.
> 
> I don't know about SIP specifically - what does the description of the
> SIP URI scheme say about this?

The sip uri explicitly does not say anything about the media it supports. That is negotiated via the exchange of SDP.

There is an ability when registering a contact address with a sip registrar to specify capabilities of the addressed endpoint, including the types of media it supports. But this is represented as header parameters on the contact header rather than as parameters of the sip url itself.

In pidf, the equivalent functionality could be achieved by either adding extra parameters to the <contact> element, or by adding new values to the <status> element.

Of course one possibility is to simply say it is up to the presence client to use the sip address from the contact, together with some sip messaging to discover the current capabilities of the endpoint. But that sounds like a very bad idea to me - you are essentially back to polling all buddies for presence information. I think it is important for the presence document to be able to represent what media the contact is prepared to use, so that can be displayed for the end user. (I want to be able to see at a glance whether you are present for IM or Voice, or both.

	Paul



  [reminder: [email protected] for non-technical discussions, please]