RE: PIDF issues summary (long)

Some notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Hiroyasu Sugano [mailto:[email protected]]
> Sent: Tuesday, October 15, 2002 5:42 AM
> To: Peterson, Jon; [email protected]
> Subject: Re: PIDF issues summary (long)
> 
> 
> Jon,
> 
> Apology for my delayed response.  
> 

No problem; thanks for your attention to these comments.

[snip]
> > 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.

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

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.

[snip]
> > <basic> <status> of OPEN should not, however, be presented 
> by the watcher as
> > ways to communicate with the presentity at this time."
> 
> It seems there is confusion in the usage of the term "watcher", and some 
> of those should be substituted by "WATCHER USER AGENT", 
> e.g. in the last sentence.   Did you use the words "watcher"
intentionally? 
> 

I think that's actually a typo - I meant 'be presented TO the watcher'.

[snip]
> > <basic>. The extensibility mechanism provided here These extensions MUST
NOT
> > modify how <basic> is to be understood, nor change the the structure or
> > semantics of PIDF bodies themselves. These extensions merely allow
protocols
> > and applications to define richer presence data."
> 
> There seems to be an editing error in the third sentence.  Is it okay just
to
> delete "The extensibility mechanism provided here"? 
> 

Yes, please do so.

[snip]
> > paragraph: "If an agent receives PRESENCE INFORMATION with a <status>
block
> > containing an unrecognized element that has a mustUnderstand='true' (or
'1')
> > attribute, it should treat the entire element as unrecognized and not
> > attempt to process it."
> 
> It seems that your wording does not explicitly prohibid the usage
> of the "mustUnderstand" attribute in a direct child element of 
> non-extensions, i.e. non-nested extension.  I think it's better to 
> add a last paragraph provided by Graham with slight modification,
> as follows. 
> 
>     "Note that the mustUnderstand attribute MUST NOT be used in a way 
>     that might prevent a minimal implementation from understanding the
basic
>     PIDF information defined in this specification.  To ensure this, 
>     the mustUnderstand attribute may be used only in elements within
optional
>     extensions, so that non-recognition of a mandatory extension results
in no 
>     worse than ignoring the optional extension in which it is contained."
> 
> Comments? 
> 

Well, I recognize, reading my text, that you are correct, it doesn't really
explicitly prohibit the use of mustUnderstand in a direct child element of
non-extensions. The text you propose above would be fine, with one
amendation to the second sentence: 

"the mustUnderstand attribute MUST NOT be used outside elements within
optional"

[snip]
> > 
> > Note that the use of timestamps in PIDF (see section 4.1.7) can provide
some
> > rudimentary protection against replay attacks. If a watcher receives
> > presence information that is outdated, it SHOULD be ignored. A watcher
can
> > determine that presence information is outdated in a number of fashions.
> > Most significantly, if the timestamp on presence information is older
than
> > the last received presence information, it should be considered
outdated.
> > Applications and protocols also are advised to adopt their own rules for
> > determining how frequently presence information should be refreshed. For
> > example, if presence information appears to be more than one hour old,
it
> > could be considered outdated (a notification generated for this presence
> > information will not take such a long time to reach a watcher, and if a
> > presentity has not refreshed its presence state in the last hour, it is
> > probably offline)."
> 
> 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. :)

[snip]



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