Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00

From: [email-masked]
Date: Fri, 28 Feb 2003 01:38:16 +0200

When you send a NOTIFY with status of CLOSED. Is that soft state? does it expire? I guess not. So, we have some sort of hard state. How else would I interpret a status of closed?

Could it be like the following:
- whatever is published in a tuple is soft state.
- When the state published expires, we default to the hard state (this could be open or closed).

Are you Sean suggesting that this hard state is not set using the PUBLISH message?

Regards,
Hisham

> -----Original Message-----
> From: ext Peterson, Jon [mailto:[email-masked]]
> Sent: Wednesday, February 26, 2003 9:55 PM
> To: Niemi Aki (NMP/Helsinki); Isomaki Markus (NRC/Helsinki); Kiss
> Krisztian (NRC/Tampere); [email-masked]
> Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00
> 
> 
> 
> The argument that there is some 'hard state' that exists in 
> the absence of
> any publications (namely, the state or document expressing 
> that the user is
> away) is in some ways attractive, yes. You are correct that a 
> registrar
> doesn't supply null contact addresses or something when the 
> user in question
> has no registration, but rather provides a specific failure 
> response. Of
> course, the events framework has a different semantics - 
> subscriptions are
> accepted when there is currently no published presence 
> information for a
> user. Sending a failure response wouldn't be workable.
> 
> There are, however, a couple of NOTIFY syntaxes that might 
> communicate that
> there is no available presence information. One is that a 
> NOTIFY might not
> contain any body. Another is that the presence agent or 
> compositor invents a
> simple tuple that contains a status of CLOSED. The latter 
> option may sound a
> lot like hard state, whereas the former does not. Whether or 
> not the latter
> option is really 'state' though is debatable - almost an 
> implementation
> question. Having a default response to queries in the absence 
> of state does
> not, in and of itself, constitute state in my opinion. It 
> does not require,
> for example, per-user tables in memory that have some 
> specific values, as
> far as I can imagine how it would be implemented.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, February 26, 2003 3:23 AM
> > To: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00
> > 
> > 
> > Hi,
> > 
> > Few comments inline. BTW, a good set of requirements.
> > 
> > Cheers,
> > Aki
> > 
> [snip]
> >  
> >  > Of course, some sort of management interface could be 
> >  > defined so that users
> >  > could do their own manual garbage collection. But that would 
> >  > be annoying.
> >  > The REGISTER model, in which stale information automatically 
> >  > goes away for
> >  > you, is much more suitable to real-time communications.
> > 
> > Similarly, when all devices are off, or out of coverage, I 
> > would like to see a presence document that says *something* 
> > even though that something is unavailable at the moment.
> > 
> > Just like when I get a 480 and not 404 back when the callee 
> > is in an unregistered state.
> >  
> > 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Sean Olson <[email-masked]>
Date: Fri, 28 Feb 2003 01:12:05 -0800 (PST)

--- [email-masked] wrote:
> When you send a NOTIFY with status of CLOSED. Is
> that soft state? does it expire? I guess not. So, we
> have some sort of hard state. How else would I
> interpret a status of closed?

Hmmm. Does this mean you would expect a PUA to 
store this status persistently? The NOTIFY is 
a snapshot of state at a particular point in time.
It can be considered to expire when the subscription
expires --- after your subscription expires, there is
no way to refresh this state other than
re-subscribing. I would interpret the state in the
NOTIFY to endure until another NOTIFY is received or
until the subscription expires, whichever comes first.

> - When the state published expires, we default to
> the hard state (this could be open or closed).

That is exactly what I had in mind. The only open
issue is how to set this hard state. I believe this
is best done through a separate administrative 
interface and not through PUBLISH. I'm open to other
opinions. If someone can come up with a simple
mechanism for indicating hard state in the PUBLISH
request, I don't have any strong objections to doing
this.

> set using the PUBLISH message?

That's my opinion. Again, I'm open to being proven
wrong. 

> > > is in an unregistered state.

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple