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

Okay, now I think I get it. The problem is that the presentity is telling
the watcher that it has two forms of status information about the principal
that are represented in different tuples, one of which is OPEN and the other
of which is CLOSED. So is communication with the principal possible or not?
If so, how? Does the OPEN tuple imply that one avenue of communication is
open (say, telephone), and the CLOSED tuple that another avenue (say, IM) is
closed? Surely the meaning of these different tuples needs to be more
explicit (either within an 'id' attribute or a <contact> element), or
there's no point in having information in separate tuples. Have I got it
right this time?

The real question here is how tuples should be constructed and interpreted.
Unfortunately, RFC2779 defers this question to the model in RFC2778, and
RFC2778 offers absolutely no motivation for tuples or explanation for how
they should be used. We might assume that if you have multiple presence user
agents that are publishing presence information to the presentity, the
presentity composes each chunk of presence information into its own tuple
before publishing the composed presence information to a presence service
for distribution to watchers (I would be interested to hear the perpsective
of any RFC2778/RFC2779 authors on this matter if they feel there is some
other motivation for tuples). cpim-pidf-05 should certainly take the
opportunity to clarify the use of tuples; its examples (like 4.3.2) assume
roughly the model I describe, but some text in 4.1.2 is really necessary. As
you point out, the way that 'id' is defined in 4.1.2 entails no semantics
whatsoever - shouldn't this id should characterize the device that generated
the tuple?

But neither 'id' nor <contact> is actually intended to provide device
capability. An 'id' of 'mobile-phone' (which appears in the example in
4.2.2) implies that the device that generated this tuple could make voice
calls, but some mobile phones also support IM, and even video.
'mobile-phone' certainly isn't sufficient to communicate capability by
itself (a principal might also have several devices that could characterize
themselves as 'mobile-phone', which is another complication). Similarly, the
definition of <contact> in cpim-pidf-05 is much more restricted than that
given in RFC2778/RFC2779 - pidf-05 allows only a URI in a <contact> element,
whereas the framework and requirements RFCs speak to postal addresses and
the like.

So, I agree that the motivation for tuples needs to be made explicit in the
draft (probably in Section 2, as a clarification or expansion on 2.1 (a)),
and that some better guidance needs to be given on how the <tuple> 'id'
attribute should be constructed in 4.1.2.

But that much said, even in the absence of any capability data, I think it
is pretty obvious that if you have different tuples with <basic> statuses of
OPEN and CLOSED, even in your example, then the total state to the
presentity is OPEN. In other words, a watcher should be expected to take an
OR operation of all of the status values across tuples. If any one of them
suggests the target is online, then the GUI of the watcher should render
that the target is online (if the GUI displays this sort of binary 'on/off'
info). So I don't think the opaque tuples you described in your mail are
actually useless - tuples would be more useful if they contained more
information, I agree, but that's why the format is extensible. The OR-ing of
tuples could probably stand to be discussed briefly in cpim-pidf-05 as one
possible way of interpreting multiple tuples.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Monday, September 02, 2002 1:06 AM
> To: [email protected]; [email protected]
> Cc: [email protected]
> Subject: RE: Communication means in draft-ietf-impp-cpim-pidf-05
> 
> 
> Well, <contact> or any other element.
> 
> The example it meant to illustrate that pidf, as it stands, 
> does not carry any useful information to the watcher if only 
> the minimum mandatory elements as they are now are sent in 
> the pidf document.
> 
> If I, as a watcher, receive a pidf document that looks like 
> the example I included in earlier emails, I have no means of 
> understanding or using this information in a useful way. What 
> does it mean to have 2 tuples, one with ID 342jrmeklrm and 
> status open, and the other with ID jklejr983 and status closed.
> 
> e.g. (using sip)
> 
> SUBSCRIBE sip:[email protected] SIP/2.0
> From: sip:[email protected]
> To: "Jon Peterson " <sip:[email protected]>
> ....
> 
> 
> NOTIFY sip:[email protected] SIP/2.0
> From: sip:[email protected]
> To: "Jon Peterson " <sip:[email protected]>
> ....
> Content-type: application/cpim-pidf+xml
> 
> <tuple id="a67uyt76">
>    <status>
>       <basic>open</basic>
>    </status>
> </tuple>
> <tuple id="432kljsd">
>    <status>
>       <basic>closed</basic>
>    </status>
> </tuple>
> 
> What would u present to the watcher in the GUI in this case?
> 
> Jon Peterson
>            .... OPEN
>            .... CLOSED
> 
> No useful information at all.
> 
> Feel free to substitute sip: with pres: or any other scheme.
> 
> Regards,
> Hisham
> 
> > -----Original Message-----
> > From: ext Peterson, Jon [mailto:[email protected]]
> > Sent: Friday, August 30, 2002 11:47 PM
> > To: Khartabil Hisham (NMP/Helsinki); [email protected]
> > Cc: [email protected]
> > Subject: RE: Communication means in draft-ietf-impp-cpim-pidf-05
> > 
> > 
> > 
> > Um, like Adrian I think up until now I haven't been sure 
> > exactly what this
> > example is intended to illustrate - but I think I can venture 
> > a response.
> > You're arguing that <contact> should be mandatory, right?
> > 
> > In order to get a PIDF document, presumably a watcher performs a
> > subscription operation targeting a URI representing some 
> > presentity. The
> > watcher doesn't need any <contact> element in a response to 
> > know who that
> > presentity is - they sent a subscription to them (and of 
> > course there is the
> > 'entity' in <presence>). However it was that the watcher 
> > learned the URI to
> > which they subscribed, they may also have learnt contact 
> > information about
> > the principal. Also note that in some cases, the same URI 
> > could be used for
> > presence subscription and for subsequent communications (as 
> > in your favorite
> > and mine, the SIP URI). In that case there's no need for a <contact>
> > element.
> > 
> > Also, as Adrian said, for some forms of presentities, 
> > <contact> elements
> > really wouldn't make sense. We've talked a bit about 
> geolocation being
> > expressed in presence - geolocation data for a presentity 
> > could be consumed
> > without any assumption that watchers should or could 
> initiate further
> > communication with the target principal.
> > 
> > So, I think <contact> should remain optional.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > > -----Original Message-----
> > > From: [email protected] 
> [mailto:[email protected]]
> > > Sent: Friday, August 30, 2002 10:47 AM
> > > To: [email protected]
> > > Cc: [email protected]
> > > Subject: RE: Communication means in draft-ietf-impp-cpim-pidf-05
> > > 
> > > 
> > > 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.
> > > > 
> > > 
> > > 
> > > 
> > >   [reminder: [email protected] for non-technical 
> > > discussions, please]
> > > 
> > 
> 



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