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

From: [email-masked]
Date: Fri, 21 Feb 2003 16:50:47 +0200

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

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.

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.

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.

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

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