Re: capabilities in <contact> (was RE: Communication means in draft-ietf-impp-cpim-pidf-05)

Jon,

First, thank you for being the devil's advocate, or perhaps the devil himself. :-)

It really is helpful to discover the different ways that things can be perceived. This should probably be taken to a different list. I am happy to do so, but am not certain which one. So in the meantime I continue here.

	Paul

"Peterson, Jon" wrote:
> 
> <SIP stuff>
> The fact that SIP is essentially a rendezvous protocol and not a means of
> carrying media is not a "problem" with putting a SIP URI in a <contact>
> address of PIDF. There is quite a great deal of value to be had just in
> knowing that someone with whom you wish to communicate is currently online
> and willing to interact with you,

I agree with the above.

> and a very strong argument can be made
> that once you know that, nothing about the way you use SIP would be improved
> by further knowing someone's capabilities - the INVITE and SDP offer that
> you send to them would never be tailored to what you believe their
> capabilities to be.
> </SIP stuff>

I think the argument for this is weak. I suspect the reason we differ on this may be because I an considering a different kind of sip device than you are. I am concerned with a single device, with one sip address, that can handle a wide variety of media, either together or separately in any given call.

Suppose I have such a device that can do both IM and voice. Sometimes I take it to meetings where taking voice calls would be distracting, so I disable acceptance of voice but leave IM enabled. Other times I enable both. You have a similar device, and want to communicate with me specifically using voice - IM won't do. (Maybe your carpal tunnel is acting up and you can't type.) So what you really want is to call me once I get out of my meeting and enable voice.

Of course we don't need presence to do this. You can just call, offering only IM media, and either you will get RINGING and eventually connect, or else you will get an error. But it was annoyance with this kind of polling that led to the desire for presence.

Presence is intended to be *dynamic* - to show changes in your presence status in a timely way. (Section 3.4 of 2779 says this explicitly.) If my COMMUNICATION MEANS is just SIP, and I can't express nuances in my status based on what media are enabled, then my presence doesn't change when I enable voice. Presence isn't of any value to you in deciding when would be a good time to call me. What has happened is that providing a single device with a variety of media capabilities has reduced the value of presence.

Of course an alternative is for me to public separate presence tuples for with contacts for IM and voice, each with its own status. The troubles with this are, as I mentioned earlier:

- I need a separate scheme (COMMUNICATIONS MEANS) for each medium. We don't have them now for lots of interesting media (e.g. voice, video, application sharing (T.120), gaming, etc.) 

- doing so obfuscates the fact that these media can be used together in a single call.

Because of the above it is important, WHEN USING SIP AS THE COMMUNICATIONS MEANS, to be able to indicate in the presence document a more precise specification of what the presentity is present for.

> 
> I don't believe that your assertion that the whole purpose of publishing
> presence is to communicate capabilities is substantiated by RFC2779, which
> merely says:
> 
>    3.1.3. The common presence format MUST include a means to encapsulate
>    contact information for the PRESENTITY's PRINCIPAL (if applicable),
>    such as email address, telephone number, postal address, or the like.

Interestingly those things effectively represent both different media and different means of communication. It is historical accident that they go hand in hand. But it doesn't mean it is a good thing. Lumping these all together under a presentity address is a way to give them a common address for presence purposes. Its even better if you can use a common address for communications purposes.

Those addresses also in general change infrequently. It would have been possible to define a service that maps a single address into a bunch of different types of communication address in a static rather than dynamic way. That way you could just phone or email using a single pres: address. And it they don't all work all the time, you could just find that out by trying periodically.

But that isn't what is being done. Instead, presence is dynamic, on the assumption that it will somehow be more useful for subscribers to be told when these values change. While in some cases it is the actual addresses that will change dynamically, it seems clear that more often it is the status that we expect to change.

> 
> I believe this contact information should be interpreted as 'address (and
> optionally protocol) I will use to contact you' - there is no implication
> I've been able to find elsewhere in RFC2778 or RFC2779 that this means
> something deeper. If you think this means detailed capability, then this
> could be impactful to plenty of protocols other than SIP as well. When I get
> a mailto: URI in <contact> header from you, then if I want to email you an
> MP3, I could need to know beforehand that you have an MP3 player on your
> terminal, and therefore you need to put a supported="MP3" attribute in your
> mailto <contact>. But even that isn't sufficient, because my MP3 is
> LAME-encoded, so I need to make sure your MP3-player supports LAME -
> support="MP3:LAME/MP3:...". Or before I send you an IM, I could need to know
> what international character sets you support, you should enumerate all such
> sets in 'supported' attributes. And so on. We don't really want to go there,
> do we?

Clearly this can be taken to extremes. I think what is important here is to represent the capabilities that change over time - that are of interest to a subscriber trying to decide when/if to place a call.

So whether you support MP3 mail might be significant if it changes moment to moment, but not otherwise. And in the case of mail, I think this would mean a change in the capability of your mail server to receive MP3, not your ability to play it.

> 
> I am not closed to exploring the placement of information related to SIP
> capabilities in PIDF, in some SIP-specific PIDF extension that we could
> define in SIMPLE.

Good. That is all I ask. 
(Well, I also need a clarification of whether the right venue is SIMPLE or SIPPING.)

> I am however closed to jumping to conclusions,

Fair enough.

> be they
> that we need mandatory 'communications means' beyond URIs in PIDF or that we
> need to jam SDP offers in PIDF (but I must say, if anyone believes that a
> presence notification is an SDP offer, they should sit out any subsequent
> discussion in SIMPLE).

OK - I promise not to suggest putting SDP offers in PIDF!


Now, to kill two birds with one message,
Adrian Bateman wrote:
> 
> On 30 August 2002 18:34, Paul Kyzivat wrote:
> > The logical conclusion of what Adrian is saying is that eventually
> there ought to be a bunch of url schemes:
> >
> >       im:     for instant messaging
> >       voice:  for voice with email style addresses
> >       tel:    for voice with e.164 style addresses
> >       video:  for video
> >       game:   for gaming
> 
> Well, yes,

I hope I have beaten this to death above.

> or else you define a more sophisticated URI scheme that
> conveys the information you want.

UGH !!!

> Or you apply open/closed to the
> contact address as a whole and extend this with application specific
> status values.

AMEN!

	Thanks,
	Paul



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