RE: PIDF issues summary (long)

Some more notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Hiroyasu Sugano [mailto:[email protected]]
> Sent: Wednesday, October 16, 2002 2:38 AM
> To: Peterson, Jon; [email protected]
> Subject: Re: PIDF issues summary (long)
> 
> 
> Thanks for your quick response. 
> 
> > > > presentities will be loosely synchronized."
> > > 
> > > Well, what is the exact meaning of  "loosely synchronized"?   I'm just

> > > asking if you used this with some special meaning.  I understant that 
> > > an exact definition may not be required because this is the overview 
> > > section, 
> > 
> > I am borrowing the term 'loosely synchronization' from Kerberos, which
uses
> > a similar way of timestamping without having some protocol mechanism for
> > keeping clocks in synch. What I really mean is that the timeframes for
> > considering data aged (which are recommended later in the document) are
> > large enough (on the order of an hour) that the lack of synchronization
of
> > clocks will not materially impact security.
> 
> Understood.  But, I think it would help better understanding if you can
give 
> some additional text for it. 

Okay, so I revise my previous suggestion with the following.

To the end of (b), I suggest adding: "Note that this mechanism does not
assume any global time synchronization system for watchers and presentities
(see Appendix A of RFC2779, 8.1.4 A7), but rather assures that the minimum
length of time that might pass before presence information is considered
stale is long enough that minor variations among system clocks will not lead
to misjudgments of the freshness of presence information."

Is that better?

[snip]
> > 
> > Let's say I have three devices (two cell phones and an IM client) that
> > publish their presence to the same presence service. Both cell phones
report
> > that I am offline (i.e. CLOSED). One IM client reports that I am online
> > (OPEN). What I am suggesting is that if any device I have is reporting
that
> > I am available, then my (total) presence status should be considered
OPEN -
> > just because some devices are reporting I am not available, that doesn't
> > override the device that says I am available.
> 
> I was confused because, in addition to my misreading, your texts read 
> about two things at the same time; one about handling two conflicting 
> tuples with the same <contact> address, and the other about reporting 
> presence information of the presentity level.  I think those are closely
> related but different stuff.
> 

Agreed.

> > The reason why this is confusing, I would imagine, is because the
concept of
> > a 'total presence state' that summarizes my presence across multiple
devices
> > is very application-specific - and my example assumes a very
> > application-specific meaning for tuples. I had hoped this would be a
> > clarifying way of looking at tuples, but if it is confusing, then we
> > shouldn't include it.
> 
> Now I understand your point.  I agree we need some clarifying texts
> on a general understanding of tuples.  But, I don't know I can agree 
> that we need explanation on how to summarize 'total presence state'
> from presence tuples...   Any comments? 
> 

I am fine removing the sentences related to 'total presence state' from my
original suggested text, which would probably be the following two (maybe
the second can stay, actually, although it is pretty self-evident):

If at least one tuple in the PIDF contains a <basic> <status>
element with a value of OPEN, then the presentity should be considered to be
currently available. <contact> elements in tuples that do not declare a
<basic> <status> of OPEN should not, however, be presented by the watcher as
ways to communicate with the presentity at this time.

[snip]



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