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

I would think that SIMPLE is the appropriate forum for this question, since
you are considering the use of SIP with PIDF, which seems to fall roundly
under SIMPLE's general charter. I'm certainly not trying to advocate any
infernal position - I am attempting to sift through a lot of material to
find out if there is anything relevant in this thread to the work at hand in
IMPP. I'm going to try not to address SIP-specific questions here - but
replies to issues relevant to PIDF are below.

Overall as a consideration for IMPP, this capability issue is very
straightforward - it's another thing that isn't required in order to get
minimal interoperability. We all know we can extend PIDF to add
functionality that we need at a later time - but it doesn't seem that we
have to build anything further into PIDF to allow that extensibility.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email protected]]
> Sent: Friday, August 30, 2002 4:57 PM
> To: Peterson, Jon
> Cc: '[email protected]'; [email protected]
> Subject: Re: capabilities in <contact> (was RE: Communication means in
> draft-ietf-impp-cpim-pidf-05)
> 
> 
[snip]
> I think the argument for this is weak.

I didn't present my argument, I just suggested that I have one.

[snip]
> 
> 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. 

The inference that because presence is 'dynamic' it therefore must contain
detailed capability information is not supported by the draft - in fact, I
can say pretty definitively that our requirements only discuss contact
information that is NOT dynamic. The requirement that is in RFC2778/2779
speaks to postal addresses, telephone numbers and email addresses. None of
those change in real time, at least not in the way that SIP Contact
addresses associated with an address-of-record change. 

The dynamism associated with the presence states of OPEN and CLOSED is a
more likely inference. Surely those states impact when it would be a good
time for me to send you an INVITE - if you're in state CLOSED, it probably
isn't a good time. Your conclusion that in the SIP case <basic> presence
information "isn't of any value" just suggests to me that you're arguing in
bad faith. Instead, I think you speak to a way that presence information
could be even more valuable - if we added capability data to it. That could
be true, I don't know, we could do it with PIDF extensibility as it stands
in the cpim-pidf-05 draft today if it turned out this was a good idea, case
closed. We can explore this elsewhere (in SIMPLE), but it's not IMPP's
business. This has all been said before. Why are we still arging about it?

> What has happened is that 
> providing a single device with a variety of media 
> capabilities has reduced the value of presence.
> 

I understand why you say that - but I believe putting SIP Contact addresses
into PIDF along with detailed capability for devices changes the SIP model
in ways that some would say reduces SIP's value. There might be worthwile
compensation for developing this idea further, and I'll be glad to provide
some comment on it elsewhere, but it's not something to jump into naively,
and it doesn't seem to have any impact on PIDF.

> 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.) 
>

And even if this were a favorable approach, surely this too isn't IMPP's
problem. Other working groups might figure out URIs for gaming and the like.

> - 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.
> 

Again, sounds like you think we need an extension that is specific to SIP. 

[snip]
> > 
> >    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.

One might even say that they aren't obviously dynamic - but support for
these is our requirement, right?

> 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.
> 

Again, the idea that <contact> is intended to be dynamic is not well
supported by our requirements. It may be useful for some URI schemes, like
SIP, but there is also at least one SIP address that is not dynamic - an
address-of-record. 

[snip]
> > 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.

I think this slope is actually quite slippery.

So, whether the phone supports G.711 isn't important when you decide to
place a call? If I knew beforehand that we supported particular voice codecs
in common, I might be more likely to call you than otherwise. Same goes for
the interval of the G.711 codec - after all, if we don't support the same
intervals with that codec we could have problems. Different SIP phones that
you use over time might have different capabilites in this regard. However,
that doesn't seem to phase you. You're willing to send an INVITE to the
phone if you know it supports 'voice', and if there's no codecs in common,
then after all SDP negotiation will fall through and call setup won't work.
No big deal.

I think this is a reasonable argument. In fact, it is the same argument I'm
making for why we don't even need to specify capability down to the level of
'voice'. I think it is just as reasonable there.

> 
> 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 might pull my email from a Web client in a mall at one moment and from a
Eudora client at home at another - clearly my ability to render MP3 changes.
I don't think it matters if the mail server supports it - this is an
end-to-end issue, right? MAs sometimes apply length restrictions on bodies,
but they don't administer the contents of attachments. This is exactly the
same thing that is true of SIP - it isn't an issue of whether or not your
proxy server, say, supports G.711. I can become eligible to receive INVITEs
from a device that supports voice at one moment, and from a device that
doesn't support voice at another. There really isn't any difference here.

[snip]



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