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

From: [email-masked]
Date: Mon, 3 Mar 2003 16:58:28 +0200

I basically agree with Aki about interface reuse, but since we are still at the stage of negotiating requirements, we need to agree if a requirement that mandates the solution to support hard state publication to be present in the requirements draft.

Now to the solution:
What about a PIDF extension that overrides the Expires-header value? or going back to the expires-like header that the first version of publish had (I can't remember the name of that header). This expires like header allows indicating hard state.

Regards,
Hisham

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 03, 2003 1:35 PM
> To: [email-masked]; Khartabil Hisham (NMP/Helsinki);
> [email-masked]; Isomaki Markus (NRC/Helsinki); Kiss 
> Krisztian
> (NRC/Tampere); [email-masked]
> Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00
> 
> 
> 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
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple