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. 

> [snip]
> > > <contact> address. Tuples MAY contain conflicting presence information -
> one
> > > <tuple> might provide a <basic> <status> of OPEN, and another <tuple> in
> the
> > > same PIDF could contain a <basic> <status> of CLOSED, even if they both
> > > contain the same <contact> address."
> > 
> > "Tuples MAY contain conflicting presence status" sounds better.  But, 
> > how should the application treat such conflicting tuples?   The
> description
> > in the suggested paragraph below ("If at least one tuple ...") seems more 
> > confusing.  Could you give more text for better understanding? 
> > 
> 
> Agreed that 'MAY contain conflicting presence status' is better.
> 
> >From the recent threads about the degree to which we want to mandate a
> meaning for tuples, I didn't want to be too specific here. If the text seems
> confusing, then by all means we shouldn't include it - but I think what it
> is trying to express is valuable.
> 
> 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.

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


> > The second paragraph seems to imply the timestamp is associated with 
> > presence information, but it is actually with a tuple.   It would be more
> > precise if, for example, the fourth sentence is replaced by 
> > 
> >     Most significantly, if the newest timestamp in presence information is
> 
> >     older than the newest timestamp in the last received presence
> information, 
> >     it should be considered outdated.
> > 
> > Hmm... I'm tending to like a timestamp associated with the whole presence
> > information as well. 
> > 
> 
> I'm okay with your proposed text above.... as for whether timestamps should
> be in the scope of tuples or associated with all presence information, I
> could go either way. I think having per-tuple presence information doesn't
> hurt in any way I can see in the moment, and might actually be valuable. 
> 
> Any further assumptions about this might limit the ability of an application
> to define its own meaning for tuples, though. :)

Yes.  Okay, please forget my mumble above.  I think we shouldn't step 
into any change in the core specification at this time. 


-- Hiroyasu Sugano




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