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

Really sorry but I still don't get it. Assume I'm being really dense and
try to be explicit. To me your point seems to be that if you *misuse*
the <basic> status value then the PIDF document doesn't make sense. I
would have thought that this was self-evident.

The thing is, there exist some types of status information that apply to
a presentity that are independent of the contact address. These status
values are logically placed in a tuple with no contact address so that
they don't have to be repeated in every tuple for example. One example
might be the location of the presentity, another might be whether I am
working, eating, sleeping, or whatever. The fact that my e-mail address
is set open and my IM address is set closed has no impact on my location
or current activity.

Adrian.

On 30 August 2002 18:47, [email protected] wrote:
> That's my point. The PIDF example below gives you nothing, no 
> information about what's open and what's closed. That's why we need 
> more info.
> 
> /Hisham
> 
> > -----Original Message-----
> > From: ext Adrian Bateman [mailto:[email protected]]
> > Sent: Friday, August 30, 2002 6:05 PM
> > To: Khartabil Hisham (NMP/Helsinki)
> > Cc: [email protected]
> > Subject: RE: Communication means in draft-ietf-impp-cpim-pidf-05
> > 
> > 
> > On 30 August 2002 10:27, [email protected] wrote:
> > > What meaningful information can you depict form this?
> > > 
> > >      <tuple id="a67uyt76">
> > >        <status>
> > >          <basic>open</basic>
> > >        </status>
> > >      </tuple>
> > >      <tuple id="432kljsd">
> > >        <status>
> > >          <basic>closed</basic>
> > >        </status>
> > >      </tuple>
> > 
> > > > This doesn't mean anything to me - I'm confused about the point 
> > > > you are making. The contact address is optional to enable status
> > > > values that are
> > > > independent of address to be included - clearly <basic> 
> > doesn't fall
> > > > into that case.
> > 
> > Still nothing. As I say, <basic> wouldn't be used in this sense.
> > 
> > Adrian.
> > 
>