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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.