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

From: [email-masked]
Date: Mon, 3 Mar 2003 13:35:07 +0200

Hi,

Comments inline.

 > -----Original Message-----
 > From: ext Sean Olson [mailto:[email-masked]]
 > Sent: 28 February, 2003 11:12
 > To: Khartabil Hisham (NMP/Helsinki); 
 > [email-masked]; Niemi Aki
 > (NMP/Helsinki); Isomaki Markus (NRC/Helsinki); Kiss Krisztian
 > (NRC/Tampere); [email-masked]
 > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00
 > 
 > 
 > 
 > --- [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.
 > 
 > > 
 > > 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).
 > 
 > 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.

I'm actually starting to lean towards using PUBLISH for this. The rationale being that this seems an integral part of publishing, and it doesn't seem useful to have to leave this bit out and to a separate administrative interface. If such an interface already existed, it surely could be reused. But mandating such an interface just for this purpose seems heavy. 

Also, as the main motivation for using PUBLISH in the first place was routing, and that surely applies here as well. I'm afraid if we don't solve the hard state with PUBLISH, it won't get solved at all.

So, I see a few possible options: 1) special case some Expires value for this, 2) add an Event param for hard state, or 3) create a Require option for this.

Does any one of these seem reasonable?

Cheers,
Aki  

 > 
 > > 
 > > Are you Sean suggesting that this hard state is not
 > > set using the PUBLISH message?
 > 
 > That's my opinion. Again, I'm open to being proven
 > wrong. 
 > 
 > > 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
 > 
 > 
 > __________________________________________________
 > 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