Re: PIDF issues summary (long)

Hi, 

> Folks,
> 
> Pls. send me the link for the latest draft on PIDF.

The latest draft on PIDF is draft-ietf-impp-cpim-pidf-05.txt, which can be
retreived from the IMPP WG page.

The authors are now working to update it for the next revision and it will 
be submitted shortly.  Please wait for it if you want the brand new one.


-- Hiroyasu Sugano

> Deeps
> ----- Original Message -----
> From: "Hiroyasu Sugano" <[email protected]>
> To: "Peterson, Jon" <[email protected]>; <[email protected]>
> Sent: Friday, October 18, 2002 4:11 PM
> Subject: 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]
> >
> >
> 
> 
> 
> 
>   [reminder: [email protected] for non-technical discussions, please]
> 
> 
> 



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