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

From: [email-masked]
Date: Thu, 27 Feb 2003 10:49:40 +0200

Hi,

I think we're on the same page here. Getting an error response or an empty notification to subscriptions is not valuable to the subscriber. Whether the composer acts as a PUA in the absence of any other PUAs and publishes unavailability, or whether the user can compose a default unavailability document, or something else - this is out of scope for PUBLISH. I also agree that it is probably an implementation question.

So it seems the main issue is garbage collection. I think there is a requirement here not yet covered in the reqs-draft, that the PUBLISH mechanism must provide the composer means to do garbage collection in case a PUA dies. I think this implies a hearbeat / refresh type function for the publications.

Then there's another question on how a composer does grabage collection. I think the two options presented in this thread are the "replace" model and the "stack" model. In theory, the stack model is better, but I can't think of an actual use case scenario where that would be striclty needed. So to avoid the complexity, I'm fine with the replace model.

Cheers,
Aki

 > -----Original Message-----
 > From: ext Peterson, Jon [mailto:[email-masked]]
 > Sent: 26 February, 2003 21:55
 > 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

---

From: Sean Olson <[email-masked]>
Date: Thu, 27 Feb 2003 01:27:20 -0800 (PST)

> So it seems the main issue is garbage collection. I
> think there is a requirement here not yet covered in
> the reqs-draft, that the PUBLISH mechanism must
> provide the composer means to do garbage collection
> in case a PUA dies. I think this implies a hearbeat
> / refresh type function for the publications.
> 
> Then there's another question on how a composer does
> grabage collection. I think the two options
> presented in this thread are the "replace" model and
> the "stack" model. In theory, the stack model is
> better, but I can't think of an actual use case
> scenario where that would be striclty needed. So to
> avoid the complexity, I'm fine with the replace
> model.

I'm confused about these two models. Are you speaking
about two different PUAs publishing to the same
tuple -or- are do you mean two different PUAs 
publishing to two different tuples that the 
composer aggregates? I'm trying to understand how
these models relate to garbage collection (and if
there are other models we need to consider)

I assume you are talking about 
two PUAs publishing to the same tuple.

In the stack model, when one
PUA dies its state is popped and the second PUA's
state becomes the new state for that tuple. 

In the replace model, I assume you mean latest
PUA wins and therefore when one PUA dies, the other
would have to re-PUBLISH its state for it to take
effect -- how does the second PUA know to re-PUBLISH
and when does that occur?

In a possible third model, local policy at the
composer
determines the "winner". It's not necessarily a stack
or a last-one-wins model. In this case, it may not
be necessary for the second PUA to re-PUBLISH.

__________________________________________________
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