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

From: [email-masked]
Date: Wed, 26 Feb 2003 13:23:17 +0200

Hi,

Few comments inline. BTW, a good set of requirements.

Cheers,
Aki

 > -----Original Message-----
 > From: ext Peterson, Jon [mailto:[email-masked]]
 > Sent: 24 February, 2003 21:55
 > To: Isomaki Markus (NRC/Helsinki); Kiss Krisztian (NRC/Tampere);
 > [email-masked]
 > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00
 > 
 > 
 > 
 > 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?

I would imagine my email being always OPEN, with varying degrees of "availability", like "Gone to my summer cottage, only intermittent access" or "Actively reading". I hope the presence service isn't discriminatory against communication means that show a fairly good availability, i.e., OPEN all the time?

 > 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.

This is true. However, I think we're overlooking the fact that there is always a base line "hard state" at a registrar for a given AoR. And that is "no registered contacts". It's not like your AoR disappears if there are no active registrations. IMO, tuples shouldn't disappear either if there are no active publications. They should just show unavailability. I think this is the key issue here.
 
 > > 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.

Well, I think a reasonable implementation needs some tools to do garbage collection, so that the presence document bears some resemblance to real life availability.
 
 > > 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.

Hmm. I think that modeling the pool of published segments as a stack is actually quite elegant.

The operation would be:

	1) The stack is initiated by pushing a "default" value (usually CLOSED) which
	   is never popped.
	2) Whenever a publication arrives, the published segment is pushed 
	   on the stack. A push will also usually trigger a notification (depending 
	   on PS local policy, filters, etc)
	3) A topmost entry that has expired is always popped. If the stack
	   has many elements, it is popped until an un-expired element, or the 
	   "default" value appears. Usually this also results in a notification 
	   being generated, just as in case 2.

 > Maybe we do need a requirement to reflect this, though.

Maybe the lifetime of a segment should be considered separately from any crash recovery, or heartbeat type functionality of the publication process?

 > > 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 agree completely.

 > 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? 

The state, yes. About the tuple's themselves, I'm not so sure. To me these type of "temporary" tuples look more like leasing an AoR than registering a contact for an AoR to use the registrar analogy.

However, I fear I may have missed the discussion earlier about the meaning of a device in this context. I don't think each device should always have its own tuples, rather each separate device would usually publish state pertaining to a single tuple.

 > 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.

I completely agree. 
 
 > 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.
 
 > > (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.

I agree in that all RPC-type aspects (which I agree do exist) should not be in scope for the PUBLISH method. 
 
 > > 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 
 > > > related to these requirements concerning the issue which 
 > > > entity (PUA or compositor) assigns the identifiers and based 
 > > > on what. Even if it seems to be obvious that in case of 
 > > > carrying PIDF in the PUBLISH request, the invention of tuple 
 > > > ids is the PUA's responsibility. Having unique segment/tuple 
 > > > ids inside the presentity is the key to detect collisions 
 > > > from multiple PUAs. Related to the collision situation, I 
 > > > have a further comment:
 > > > 
 > > > - Assuming publishing partial or incremental presence 
 > > > information (as written in REQ10), there is also a need for 
 > > > the PUA to indicate whether it wants to overwrite existing 
 > > > segment or only add additional attributes to it. Based on 
 > > > this indication from the PUA, the compositor could decide to 
 > > > extend or replace the old segment with the newly published 
 > > > one, or reject the publication.
 > > > 
 > > > - REQ14 states that a PUA must be able to query the 
 > > > identifiers of all of the segments. Assuming the above 
 > > > described segment extension functionality, there would be 
 > > > also a need to query the actual content of the segments, so 
 > > > that the PUA could decide   which operation (segment 
 > > > extension or segment overwrite) to perform.
 > > > 
 > > > - Concerning partial publication (REQ10), there is also a 
 > > > need for the PUA to explicitly indicate if it intends to 
 > > > remove a certain segment from the presence information.
 > > > 
 > > > - REQ6 defines the need to order publishing sequences. Isn't 
 > > > there also a need for unique identification of PUAs?
 > > > 
 > > > Concerning section 1, some synchronization would be needed 
 > > > with section 3, as e.g. section 1 states that:
 > > > "each publication carries full state, and does not depend on 
 > > > previous states for the particular PUA.  A PUA does not need 
 > > > to know whether or not other PUAs are also publishing 
 > > > presence information to the compositor"
 > > > 
 > > > while section 3 states:
 > > > "there should also be a way for PUAs to send partial or 
 > > > incremental presence information" (REQ10); "The publication 
 > > > mechanism must support a means for a presence compositor to 
 > > > compose presence information received from multiple PUAs at 
 > > > different times into a single presence document." (REQ8)
 > > > 
 > > > Regards,
 > > > Krisztian
 > > > 
 > > > 
 > > > > -----Original Message-----
 > > > > From: ext Peterson, Jon [mailto:[email-masked]]
 > > > > Sent: Tuesday, February 11, 2003 10:31 PM
 > > > > To: Simpletons (E-mail)
 > > > > Subject: [Simple] draft-ietf-simple-publish-reqs-00
 > > > > 
 > > > > 
 > > > > 
 > > > > Aki is quite right that having these conversations about 
 > > > > PUBLISH in the
 > > > > absence of requirements is wrong-headed.
 > > > > 
 > > > > The authors of the PUBLISH proposal have fielded out some of 
 > > > > the sections
 > > > > relevant to framework, and added some requirements 
 > > language, to the
 > > > > following separate draft. The requirements in this draft were 
 > > > > also informed
 > > > > by recent email list discussion. Until it appears in the 
 > > repository:
 > > > > 
 > > > > http://www.unreason.com/jfp/ietf/draft-ietf-simple-publish-req
 > > > s-00.html
 > > > 
 > > > Comments welcome.
 > > > 
 > > > Jon Peterson
 > > > Neustar, Inc.
 > > > _______________________________________________
 > > > Simple mailing list
 > > > [email-masked]
 > > > https://www1.ietf.org/mailman/listinfo/simple
 > > > _______________________________________________
 > > > Simple mailing list
 > > > [email-masked]
 > > > https://www1.ietf.org/mailman/listinfo/simple
 > > > 
 > > 
 > _______________________________________________
 > Simple mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/simple
 > 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple