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

Some other notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email protected]]
> Sent: Thursday, September 05, 2002 2:06 AM
> To: Peterson, Jon
> Cc: '[email protected]'; [email protected]; [email protected]
> Subject: Re: Communication means in draft-ietf-impp-cpim-pidf-05
> 
> 
[snip]
> 
> 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.
> 

So, why use tuples instead of, say, MIME multipart with a different PIDF
document in each of the multiple parts? Or different status elements in the
same tuple?

If RFC2778 was supposed to be an architectural framework, then I must say
that requiring tuples was dipping deep into mechanism and protocol. Defining
tuples without any semantics or motivation makes them hard to use.

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

Yeah, I'm fine with that. My studies of the archives suggested that this
issue wasn't totally resolved, but I think this is a reasonable resolution.

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

It's reasonable that it not be normative - as long as there is some idea of
how a watcher should react when it receives multiples tuples, as opposed to
not receiving multiple tuples (but having many different types of presence
in one tuple), as opposed to receiving separate PIDF messages in MIME
multipart, etc. Having all of these different ways to express 'composite'
presence information with no sense of why  it is composite is just
confusing. You don't know why a presentity has chosen to organize presence
information the way it has without some guidance about this matter. 

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

What I meant by 'the total state of the presentity is OPEN' is that the
presentity is telling you that it is possible to communicate with the
principal if at least one tuple in the PIDF contains presence information
stating that they are OPEN. Do you disagree with that?

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