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

"Peterson, Jon" wrote:
> 
> Although this probably isn't the right forum to dive into the details of
> this, I disagree strongly that the <contact> element in presence information
> should express the capability of any particular SIP user agent. The
> communication address for SIP in a PIDF <contact> element should be an
> address-of-record. SIP addresses-of-record URIs do not have capabilities.

I am in at least partial agreement with you. 

For one thing, no sip address has capabilities. Rather, the Contact header of a REGISTER message can associate capabilities with a sip address for purposes of that registration. Whether the address is an AoR or not is irrelevant. Being an AoR is not mutually exclusive with appearing in a Contact header of a REGISTER.

I only mentioned putting capabilities on the <contact> element for completeness, and because there is at least a passing resemblance to the Contact header in a register. In fact I think that capabilities are more suitably represented as part of the <status> of a tuple. Also, "capability" isn't quite right in this context either. Rather I think the right word might be "willingness", as in "I'm willing to chat and/or talk".

I also agree that, at least generally, the communication address for SIP in a PIDF <contact> element should be an AoR. But in the end this should be at the discretion of the presentity to decide.

> Devices that register under an address-of-record (like a phone, or an IM
> client) may have specific capabilities, but the relationship between devices
> and addresses-of-record is contingent. Registering device URIs in the
> <contact> element should be discouraged for a number of reasons.

If I have both a phone and an IM client registered under the same AoR, with the phone only doing voice and the IM client only doing (SIMPLE) IM (both sip), then I have a lot of different ways I could represent the presence information:

- Use one tuple with the AoR as the <contact>.
  Willingness to IM and/or Voice could be consolidated
  for the two devices and encoded as <status> values.

- Use two tuples, one for each device, but
  with each using the AoR as the <contact>.
  One would represent willingness to use IM, the
  other Voice, encoded in their respective <status>
  elements.

- Use two tuples, one for each device.
  For a <contact> one uses the AoR, modified with
  an Accept-Contact header that selects the IM device.
  The other uses an Aor modified with an Accept-Contact
  header selecting the phone. Each encodes the 
  corresponding willingness.

- Use two tuples, one for each device, using
  the actual device address in the <contact>.
  Each again represents its willingness for
  IM or Voice.

You may like some of these more than others,
but there is no particular reason to outlaw any of them.

It gets more interesting when you have single devices that
can do more than one medium. I may want my PC to be present
for both Voice and IM until I am on the phone. Then I may
want to remain present for IM but not voice. I don't want
to split the presence information into two tuples for this,
because some callers may want to know they can make a single
call and use both voice and IM.

> 
> In any event, I see no particular need to add any features to PIDF in
> support of this.

I think it is as important to know I am present for Voice but not IM,
or IM but not Voice, as it is to know that I am busy but willing to
accept urgent business calls.

This doesn't require any new features in PIDF,
because PIDF is open enough for this kind of willingness to
be expressed with proprietary extensions. 

This kind of capability goes beyond OPEN/CLOSED just as
IN-MEETING does. I think it is as important to know I am present
for Voice but not IM, or IM but not Voice, as it is to know that 
I am busy but willing to accept urgent business calls.

	Paul



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