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

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 24 Feb 2003 14:37:18 -0500

Some notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 20, 2003 5:01 AM
> 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. 

OK, it doesn't seem unreasonable to me to discuss which entity might
generate the unique identifiers for segments. I can imagine formats other
than PIDF in which it might make sense for the compositor function to
generate these identifiers, but I don't know if we particularly need to
allow that or not.

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

This one I'm a little less sure about. First of all, the current scope of
the requirement discusses 'atomic segments' of presence. This atomicity
entails, I think, that a PUA cannot add to a segment - it can only overwrite
it. I think in order for the concept of a compositor to be sound, there has
to be some kind of atomic element on which the compositor operates.

It seems logical, in PIDF, to make the <tuple> element atomic. As Jonathan
pointed out in an earlier thread, however, this really just begs the
question about the meaning of tuples themselves. Until we arrive at a solid
semantic for <tuple>s, this will remain unclear, I fear.

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

Right, since I'm assuming that segments are atomic, only overwrite, not
extension, is necesary. In practice, I imagine that the way for a PUA to
learn of all existing segments will be to subscribe to its own presence
agent, in which case the PUA would get the content as well as the
identifiers.

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

Um... I've been envisioning that instead of 'removal', that segment would be
published with status of CLOSED (or with equivalent PIDF extension
semantics). Alternatively, the PUA could allow the segment to expire.
Ideally, both of these should show up the same way to subscribers.

> - REQ6 defines the need to order publishing sequences. Isn't 
> there also a need for unique identification of PUAs?
> 

Yes... but that is a core SIP requirement, though, rather than a publishing
requirement, I think. Is there any reason why the normal ways of identifying
user agents in SIP would be insufficient? If not, I don't think there is any
publication requirement we need for this.

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

Well, the question is, does section 1 by 'full state' mean 'full state of
the presentity' or 'full state of the PUA'? Clearly the former is what we
want, and I'll make that explicit in the text.

The statement about 'incremental' presence in requirement is 10 perhaps a
little ambitious, and should probably be removed.

> 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