Re: PIDF issues summary (long)

Deepankar <[email protected]> Fri, 25 Oct 2002 17:57:28 +0800
Newsgroups gmane.ietf.impp
Message-ID <002a01c27c0c$edfb0ce0$ac064d0a@D70286>
Folks,

Pls. send me the link for the latest draft on PIDF.

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]