RE: PIDF issues summary (long)
<[email protected]> Thu, 17 Oct 2002 11:28:44 +0300
| Newsgroups | gmane.ietf.impp |
|---|---|
| Message-ID | <[email protected]> |
Hi, Couple comments inline: > -----Original Message----- > From: ext Peterson, Jon [mailto:[email protected]] > Sent: 16 October, 2002 22:33 > To: 'Hiroyasu Sugano'; [email protected] > Subject: RE: PIDF issues summary (long) > > > > Some more notes inline. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Hiroyasu Sugano [mailto:[email protected]] > > Sent: Wednesday, October 16, 2002 2:38 AM > > To: Peterson, Jon; [email protected] > > Subject: Re: PIDF issues summary (long) > > [snip] > > 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. I have understood this so that <status> represents the status of the <contact> and not the whole presentity. Could this be changed: then the presentity should be considered to be currently available. -> then the presentity at the URI expressed in <contact> element 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. > I do not understand why something like this would be needed in the document. It should be completely application dependant how applications want to treat the presence data that is received from different presentities. There could be text explaining that applications can decide not to present <contact>s with <status><basic> missing but SHOULD NOT seems to be too strong requirement. Best Regards - Mikko [reminder: [email protected] for non-technical discussions, please]