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

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

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?

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. I am however closed to jumping to conclusions, 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).

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Friday, August 30, 2002 5:33 AM
> To: [email protected]
> Subject: RE: Communication means in draft-ietf-impp-cpim-pidf-05
> 
> 
> Krisztian wrote on 08/30/2002 10:35:13
> 
> > I feel it's very important for the presentity to publish her 
> > willingness additionally to the availability of a SIP URI. If SIP 
> > should be used to negotiate the communication means, this would 
> > mean that the SIP URI would always be "OPEN" whenever the 
> > presentity is availably for any communication, so she would be 
> > needed to reject those communication means from SIP invitations, 
> > which she is not willing to accept. I rather think that presence 
> > is supposed to be used to publish willingness, so the watchers 
> > know beforehand what is the way to contact the presentity.
> 
> I think that Krisztian has identified a real problem with SIP URIs in the 
> context of PIDF. To whit, SIP defines an interactive means of initiating 
> and controlling session/s between a SIP initiator and SIP end points 
> associated (registered) with a SIP AoR. It is intrinsically an interactive

> real-time protocol. The whole point of publishing presence information is 
> to allow, in this context, a SIP initiator to know in advance that a 
> presentity (SIP AoR) is available and with what capabilities. We can maybe

> punt for now, but I fear that we will need to revisit this issue. Sadly, 
> we may need to carry SIP header and SDP body text in PIDF.
> 
> Nick
> 
> 
> 
> 
> 
>   [reminder: [email protected] for non-technical 
> discussions, please]
> 



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