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

From: [email-masked]
Date: Thu, 27 Feb 2003 17:30:28 +0200

Hi All,

A further thought on this. 

 > -----Original Message-----
 > From: ext Sean Olson [mailto:[email-masked]]
 > Sent: 26 February, 2003 11:56
 > To: Peterson, Jon; Isomaki Markus (NRC/Helsinki); Kiss Krisztian
 > (NRC/Tampere); [email-masked]
 > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00
 > 
 > 
 > I second Jon's interpretation of the requirements
 > for presence publication. While I think hard-state
 > for presence may be an interesting concerpt in
 > some scenarios, I believe it is entirely out of
 > scope for the PUBLISH mechanism. More to the point,
 > I believe hard-start for presence is a matter of 
 > local policy and is best handled in an implementation
 > specific manner. As a first approximation of 
 > "hard-state", a PUBLISH with a suitably large
 > Expires header value accomplishes much the same
 > effect. 

A suitably large Expires value would probably not work with any composer that wishes to do garbage collection in a reasonable way. It would instead lower the value to one that conforms with its local policy.

So instead, what if we define the semantics of a PUBLISH without an Expires header to accomplish this? In other words, a PUBLISH without an Expires header wouldn't expire, and would instead "initiate the composer" with a default status.

Cheers,
Aki

 > 
 > 
 > --- "Peterson, Jon" <[email-masked]> wrote:
 > > 
 > > Some more notes inline.
 > > 
 > > Jon Peterson
 > > NeuStar, Inc.
 > > 
 > > > -----Original Message-----
 > > > From: [email-masked]
 > > [mailto:[email-masked]]
 > > > Sent: Friday, February 21, 2003 6:51 AM
 > > > To: [email-masked];
 > > [email-masked]; 
 > > > [email-masked]
 > > > Subject: RE: [Simple]
 > > draft-ietf-simple-publish-reqs-00
 > > > 
 > > > 
 > > > Hi,
 > > > 
 > > > I have some further comments on the publish
 > > requirements:
 > > > 
 > > > My concern is the hard vs. soft state nature of
 > > the published 
 > > > information. The initial SIP PUBLISH based
 > > solution seemed to 
 > > > borrow its model (Expires header) from REGISTER.
 > > For REGISTER 
 > > > it seems clear that soft state is beneficial,
 > > since if the UA 
 > > > crashes, the registrar would like to get rid of
 > > the state, 
 > > > since that state is no longer valid.
 > > > 
 > > > However, presence information contains both hard
 > > state and 
 > > > soft state components. You would like to maintain
 > > some 
 > > > (relatively) persistent version of parts of your
 > > presence 
 > > > data, even if you have no PUAs connected to the
 > > network, and 
 > > > which you would very seldom update. This kind of
 > > information 
 > > > contains for instance your e-mail contact or web
 > > page URL. 
 > > > This seems to call for a hard state model, or a
 > > soft state 
 > > > with very long expiration (i.e., infinity). 
 > > > 
 > > 
 > > Well, hmm. Ordinarily, I think that presence
 > > information exists as a way to
 > > distribute a user's availability and disposition
 > > towards real-time
 > > communication, not to distribute persistent contact
 > > addresses. Would your
 > > web page, or email address, have associated
 > > 'presence'?  Are they busy,
 > > idle, etc?
 > > 
 > > You can also register HTTP or SMTP URLs as contact
 > > addresses in at a SIP
 > > registrar. We don't have any means of making these
 > > 'hard' state in that case
 > > either.
 > > 
 > > > Definitely there are some soft state looking
 > > information as 
 > > > well, such as tuples which are valid only as long
 > > as the PUA 
 > > > is running, e.g. for IM or voice status. For this
 > > kind of 
 > > > information there is some benefit in getting
 > > automatically 
 > > > rid of it, if the PUA crashes.
 > > 
 > > This is a question about the scope of presence
 > > itself, I gather.
 > > 
 > > > 
 > > > The minimum that seems to be needed is an
 > > expiration time 
 > > > associated separately for each segment of the
 > > published data. 
 > > > With this approach there is still one issue with
 > > one PUA 
 > > > overwriting the information set by the other: If
 > > the 
 > > > overwritten data has shorter expiry time than the
 > > original 
 > > > data, what should happen if the overwritten data
 > > expires? In 
 > > > other words, would the overwrite be a replace or a
 > > "stack 
 > > > push" operation. In the latter case if the
 > > published 
 > > > information expires, it will just "pop out of the
 > > stack" and 
 > > > reveal the previous value.
 > > > 
 > > 
 > > That is an interesting question. I assume that if a
 > > segment is overwritten,
 > > it is forgotten; it will not go back into effect if
 > > the overwriting segment
 > > expires. Doing otherwise is needlessly complicated,
 > > and moreover there are
 > > cases I can imagine in which this would be the wrong
 > > behavior altogether.
 > > 
 > > Maybe we do need a requirement to reflect this,
 > > though.
 > > 
 > > > Another point of view that people have expressed
 > > is that 
 > > > everything should be hard state. Watcher can
 > > evaluate the 
 > > > correctness of the state based on how long about
 > > it was 
 > > > published. Any refresh mechanism would only update
 > > this 
 > > > "timestamp", but a failure to refresh would not
 > > cause the 
 > > > data to disappear.
 > > > 
 > > 
 > > I doubt that we will move to a pure hard-state model
 > > for presence.
 > > Independent of any publication issues, there needs
 > > to be some way for old
 > > presence information to be garbage-collected and
 > > removed. I might use tens,
 > > or hundreds of different devices over the course of
 > > a year that might
 > > publish presence information for me, some of which I
 > > employ only very
 > > briefly. The tuples generated by these devices, with
 > > which I have a
 > > transient relationship, need to be removed from my
 > > presence state at some
 > > point, right? Watchers really don't need to get
 > > tuples from me saying that
 > > nine months ago, I was standing by this payphone in
 > > Tucson. It puts on
 > > enormous burden on watchers to sort through lots of
 > > trash to find relevant
 > > information. It also has potential privacy leaks.
 > > 
 > > 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.
 > > 
 > > > (My opinion is that the requirements for PUBLISH
 > > clearly 
 > > > point that what actually would be needed is an RPC
 > > mechanism 
 > > > (such as SOAP) on top of SIP. Both routing
 > > provided by SIP 
 > > > and manipulation operations provided by an RPC
 > > protocol are 
 > > > needed. But I know that this is banned in SIP for
 > > some 
 > > > reasons (which leaves us with no such protocol in
 > > the 
 > > > Internet...), so I'm happy to try with the current
 > > way.)
 > > > 
 > > 
 > > I don't think PUBLISH should be any more like an RPC
 > > system than REGISTER.
 > > 
 > > > Regards,
 > > > 	Markus
 > > >  
 > > > 
 > > > > -----Original Message-----
 > > > > From: ext [email-masked]
 > > [mailto:[email-masked]]
 > > > > Sent: 20 February, 2003 15:01
 > > > > To: [email-masked]; [email-masked]
 > > > > Subject: RE: [Simple]
 > > draft-ietf-simple-publish-reqs-00
 > > > > 
 > > > > 
 > > > > Jon et al,
 > > > > 
 > > > > I certainly welcome this document, especially
 > > section 3. 
 > > > > Please find some comments first concerning the
 > > actual requirements:
 > > > > 
 > > > > - REQ12 and REQ14 define the need for unique
 > > identifiers of 
 > > > > segments. I would prefer to see further
 > > clarifications 
 > > 
 > === message truncated ===
 > 
 > 
 > __________________________________________________
 > 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

---

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

> A suitably large Expires value would probably not
> work with any composer that wishes to do garbage
> collection in a reasonable way. It would instead
> lower the value to one that conforms with its local
> policy.

This I don't quite understand. Either the composer
is going to authorize you to store state for a 
long time or its not. Why would the composer be
more willing to store hard-state vs. state that
lasts a very long time?

> So instead, what if we define the semantics of a
> PUBLISH without an Expires header to accomplish
> this? In other words, a PUBLISH without an Expires
> header wouldn't expire, and would instead "initiate
> the composer" with a default status.

I would prefer that a PUBLISH without an Expires
header be reserved to mean that the client wishes
the server to choose an expiration value for the
publication.