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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Mar 2003 15:46:32 -0500

The problem here is this - do you expect the hard state of CLOSED for a
particular tuple to be part of what the compositor sends in presence
documents to watchers from now to the end of the world? If I am available at
a conference room at a company I visit for an hour, and then publish a state
of closed from that conference room, should that tuple (with a CLOSED
status) be available to people who subscribe to my presence nine months from
now? I don't think so. That's why this is not hard state. We want these
things to go away, not persist forever. I definitely think a NOTIFY of
CLOSED is soft state.

When I publish a tuple with CLOSED, that immediately lets all current
watchers know that I am no longer available at that contact address or what
have you. It is important that this notification is sent. However, I think
that CLOSED state should subsequently expire, just like any other state, for
the sake of garbage collection, so that watchers who subsequently subscribe
to my presence will not be overwhelmed with dozens of irrelevant and
outdated tuples.

In the case in which I have published no tuples recently, and all state for
me has expired, I agree that a compositor might generate a 'dummy' tuple of
CLOSED, and this is something like hard state (though whether it is per-user
state or not is debatable, and perhaps even implementation-specific). I'm
not sure PUBLISH is necessarily needed to manage this default response.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 3:38 PM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00
> 
> 
> 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