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

inline.

Peterson, Jon wrote:
> 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?

I had a different interpretation.

In my mind, the document which Hisham has put forward is, in fact, 
valid, with a well defined meaning. It says that this presentity has two 
  tuples, one of which is open, and the other, is closed. Each tuple 
could be a phone, or a pager, or an IM client, or whatever. This 
presence document simply chooses not to reveal that information. As a 
result, its not a terribly valuable piece of presence, but its valid.

> 
> 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). 

RFC 2778 isn't trying to dictate a particular model of what a tuple 
might represent. Some systems might associate tuples with devices. 
Others, with users. Others, with identities. The point of 2778 is to 
provide a general framework which can be used to describe a variety of 
presence systems, not to dictate the structure of a particular system.



> 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?

No. Its merely an opaque identifier, as Mikko points out. The examples 
need to be aligned to that.


> 
> 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.

I think the guidance in 4.1.2 is sufficient.

I think it might be worthwhile to add some text discussing the various 
things you might use a tuple to describe, but I don't think it should 
present and normative text.


> 
> 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.

I do not think that is the meaning. If you want to represent the overall 
state of the presentity, you do that with a tuple (which might not 
contain a contact address).

Now, perhaps its a fault of PIDF that it doesn't convey quite enough 
information to usefully determine exactly WHAT the tuple is 
representing, but I think the space of such things is sufficiently broad 
that leaving it to extensions is sensible. I agree that, in the case of 
SIP (although it really is more general), having extension attributes 
that convey the information gleaned from things like caller preferences 
(media types supported, for example) is a worthwhile goal. Indeed, such 
an item is ALREADY on the charter of SIMPLE, and appears to be due this 
month....


-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email protected]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com




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