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]