Re: PIDF issues summary (long)

Jon, thanks very much. 

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

Although what I expected was some sort of reference to the Kerberos 
specification or document,  this is good to me.   Appreciated. 


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

Okay.  Agreed.


-- Hiroyasu Sugano



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