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

Hi,

Jon Peterson wrote:
> SIP has unique properties that make this a little more 
> confusing - a SIP AoR
> doesn't identify any particular way to communicate; rather, 
> it identifies a
> resource that is capable of using SIP to negotiate the best way to
> communicate with you... this is what SIP is for. Again, I'm 

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.

> not terribly
> interested in arguing SIP theory in this forum, but I am 
> pretty sure that
> there isn't some information "missing" in SIP URIs that PIDF 
> needs to supply
> in order to meet our current IMPP requirements.

I agree IMPP should not go into details about the usage of the SIP URI, however I think that PIDF should provide a good enough standardized way to represent communication means. The SIP URI example somehow indicates that the type of the URI might not be enough. 
I imagine that a typical PIDF document will contain a mailto:, an im: and sip: URIs. If PIDF does not provide explicit indication for the communication means, there will be a need for other WGs/organizations to define "standardized extensions" to PIDF to represent communication means for SIP URIs.

Thanks,
Krisztian
 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > Sent: Friday, August 30, 2002 1:32 AM
> > To: [email protected]; [email protected]
> > Cc: [email protected]; [email protected]; [email protected]
> > Subject: RE: Communication means in draft-ietf-impp-cpim-pidf-05
> > 
> > 
> > A few points:
> > 
> > 
> > 1. In support for Krisztian, what does this tuple tell me?
> > 
> >      <tuple id="a67uyt76">
> >        <status>
> >          <basic>open</basic>
> >        </status>
> >      </tuple>
> > 
> > Or a better question: what does a tuple mean and represent?
> > 
> > 
> > 2. Contact element represents the communication address. As 
> > defined in RFC2778:
> > 
> >        - Communication address: communication means and contact
> >            address of this tuple. (optional)
> > 
> > I guess we need to answer the first one to answer this one: 
> > If there is no communication means, and there is nothing 
> > telling me what a tuple is supposed to represent, then what 
> > does this contact element tell me? I'm open for what?
> > 
> > 3. RFC2778 also states (section 2.4):
> > 
> > Each such element
> >    consists of a STATUS marker (which might convey 
> information such as
> >    online/offline/busy/away/do not disturb), an optional 
> COMMUNICATION
> >    ADDRESS, and optional OTHER PRESENCE MARKUP.  A 
> > COMMUNICATION ADDRESS
> >    includes a COMMUNICATION MEANS and a CONTACT ADDRESS. One type of
> >    COMMUNICATION MEANS, and the only one defined by this model, is
> >    INSTANT MESSAGE SERVICE.  One type of CONTACT ADDRESS, 
> and the only
> >    one defined by this model, is INSTANT INBOX ADDRESS. 
> However, other
> >    possibilities exist: a COMMUNICATION MEANS might 
> indicate some form
> >    of telephony, for example, with the corresponding CONTACT ADDRESS
> >    containing a telephone number.
> > 
> > This clearly states that communication means is required and 
> > that the AOR is not enough. How do I tell watchers that the 
> > tuple above is for IM or whatever communication means? I 
> > would actually go further stating that communication means to 
> > be mandatory in PIDF.
> > 
> > Regards,
> > Hisham
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: ext Peterson, Jon [mailto:[email protected]]
> > > Sent: Friday, August 30, 2002 1:13 AM
> > > To: 'Paul Kyzivat'
> > > Cc: Kiss Krisztian (NRC/Tampere); [email protected]; 
> [email protected]
> > > Subject: RE: Communication means in draft-ietf-impp-cpim-pidf-05
> > > 
> > > 
> > > As I said, and as you agree below, this really has no bearing 
> > > on PIDF. While
> > > I'm interested in this issue as an academic matter (we 
> > > encountered a similar
> > > question in ENUM), we have more pressing matters at hand in 
> > > the IMPP WG. I
> > > suggest you raise the matter in SIPPING or SIMPLE if you 
> > > really want to
> > > pursue it - at best, this is applicable to how SIP would 
> > use the PIDF
> > > format. That much said, despite your arguments below I don't 
> > > think there's
> > > any value in moving capability information out of the SIP and 
> > > SDP standards,
> > > where it is currently adequate in my opinion, and into 
> > > something like PIDF.
> > > 
> > > Jon Peterson
> > > NeuStar, Inc.
> > > 
> > > > -----Original Message-----
> > > > From: Paul Kyzivat [mailto:[email protected]]
> > > > Sent: Thursday, August 29, 2002 2:52 PM
> > > > To: Peterson, Jon
> > > > Cc: '[email protected]'; [email protected]; 
> [email protected]
> > > > Subject: 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]
> > > 
> > > 
> > 
> 



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