Subject: RE: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem

From: [email-masked]
Date: Thu, 17 Jul 2003 12:04:02 +0300

Hi Jonathan,

In general, I like the proposal of simplifying things. 

If I understand the proposal you're making correctly, you want to remove all of the current discussion on segmenting presence state, and have each PUA publish their full view. Also, instead of using server-provided etags, you want a publication to be identified by a client-generated pstream-ID.

Firstly, I agree on removing segmentation, and the whole package that comes with it (collision detection, overriding, tuple-ID naming conventions etc.) As you say, this just complicates things unnecessaríly, and leaving these details to composer and publication authorization policy makes a lot of sense.

But about using PStream-ID instead of etags, I don't think it saves us a lot compared to the current usage of Etags. By having the server generate these identifiers (etags), their uniqueness within a presentity is guaranteed. With PStream-IDs, the EPA has to do some work in order to generate an ID that is guaranteed to be unique. Admittedly, this isn't a huge effort, but compared to having the server assign identifiers simply by incrementing a counter, may be slightly more complex. It anyway introduces the chance of colliding PStream-IDs, which we would have to deal with one way or another.

Also, with PStream-ID, you'd still need an error response in case no such PStrean-ID exists in the ESC. So all in all, we save the task of defining/implementing the If-Match header field, but need more to handle the PStream-ID generation/collision issues.

So my counter-proposal would be to simplify along the lines you described, removing all of the segmentation things,  but still keep the Etags, If-Match headers. The only change in their usage would be to remove the collision detection altogether, so that the only case when a refresh/deletion would fail with a 412 would be if the publication had already expired (i.e., the etag no longer existed).

Cheers,
Aki

 > -----Original Message-----
 > From: ext Jonathan Rosenberg [mailto:[email-masked]]
 > Sent: 15 July, 2003 22:42
 > To: Robert Sparks
 > Cc: Niemi Aki (NMP/Helsinki); [email-masked]
 > Subject: Rethinking scope on publish, was Re: [Simple] PUBLISH:
 > atomicity problem
 > 
 > 
 > I was about to post a note on agreeing with Aki.  I was also 
 > going to 
 > say that we might want the body to also be the atomic unit, so that 
 > when you publish a tuple, the body is an XML fragment for the tuple. 
 > Then, it ocurred to me that we were really far down the complexity 
 > ramp here. So, I thought about what we could do to really 
 > back out of 
 > this mess entirely. Here is my idea.
 > 
 > In the beginning, PUBLISH was easy. Each PUA published its 
 > own view of 
 > the presence of the presentity. It had no knowledge of other PUA. It 
 > published a complete presence document which represented what it 
 > thought was the full presence of the presentity. Indeed, if 
 > there was 
 > only one PUA, it would be the full presence of the presentity. There 
 > was no way for one PUA to overwrite the published data from another. 
 > The tuple IDs didn't need to have cross-PUA scope. No naming 
 > conventions or anything. The compositor could combine these 
 > and modify 
 > them as it chose. Each represented a unique and different piece of 
 > info about the presentity. A useful bit of information was this 
 > "Pstream-ID", which uniquely identified the publisher. You can think 
 > of the Pstream-ID as a way of scoping the tuple IDs. Each 
 > tuple ID is 
 > defined only within the scope of a Pstream-ID, and each 
 > publisher has 
 > to have a unique PStream-ID.

I'm not sure what type of temporal scope you are suggesting for the stream-ID. Is it very long term, like a device-ID? Or is it only persistent across a specific publication, over its refreshes, deletion, etc.?

If the only reason for stream-ID was to scope the tuple-IDs, then whatever uniqueness property we want for the stream-ID, can equally well be applied to the tuple-IDs, making the actual stream-ID not needed at all.

 > It all got complicated when we decided to try and solve a bigger 
 > problem, where PUA could override information about other PUA. That 
 > introduced all kinds of problems. We needed to define the atomic 
 > information of published presence. We need to resolve tuple 
 > naming. We 
 > need to worry about this issue about whether a publish has 
 > one or more 
 > tuples. We needed to add Etags and If-Modified-Since. We 
 > need to worry 
 > about how to figure out what it means for the system to "wait for 
 > human input" in cases where thats not possible. We don't know how to 
 > do that yet.

I agree, the overriding requirement lead us to the problems in atomicity, and tuple-ID naming.
 
 > Perhaps we should reconsider whether we want to solve this problem 
 > this way. We have only one use case - when I leave my PC at 
 > the office 
 > with a presence state that is wrong, and I want to fix it at home. 
 > Well, this is a nice feature, but is it worth all of the 
 > complexity at 
 > this point? There are other ways to deal with it. In fact, I 
 > can think 
 > of two alternatives:
 > 
 > 1. You could use the auth policy to simply disable the PC's 
 > data from 
 > being placed in notifications, and then publish a separate tuple 
 > (i.e., new piece of independent information) from home. Thats not as 
 > good (PC still refreshes useless state), but its lots 
 > simpler than the 
 > route we are on.

But how would you actually do that? If the only way a publisher can be identified (PStream-ID) is generated by the publisher itself, how can one set the appropriate authorization policy for disabling those publications?
 
 > 2. You could design a system which only allowed one PUA at a time 
 > (akin to the current model in AIM and YIM). This would 
 > manifest itself 
 > as composition policy. The compositor would only use the published 
 > document from the PUA which started publishing most recently - that 
 > is, when its Pstream-ID first appeared. This would also achieve the 
 > effect of disabling the work PC's state when you arrive at home.

 > 
 > 
 > So, to be concrete, I would propose the following:
 > 
 > 
 > 1. Publications carry complete presence documents, representing the 
 > complete presence state of the PUA as far as it knows.
 > 
 > 2. Publishers are identified by a unique PStream-ID, chosen by the 
 > publisher. Copying someone elses Pstream-ID is not allowed, and 
 > behavior in this case is not defined.
 > 
 > 3. There is no ability to overwrite someone elses presence 
 > document or 
 > their tuples. Each publisher publishes independent information.
 > 
 > 4. We eliminate the Etag, If-Modified-Since, and atomicity/segment 
 > discussions from Publish.
 > 
 > 5. Compositors can combine the publsihed information however they 
 > like. There is no need to carry through tuple IDs from 
 > publication to 
 > notifications.
 > 
 > 6. If you want to block a tuple from getting into a notify, you 
 > identify it by a distinguishing property rather than by tuple ID.
 > 
 > 
 > I believe this approach works nicely for other things too. 
 > In the case 
 > of winfo, where you have lots of presence servers, each publishing 
 > winfo for the subscriptions they have, its the same. Each 
 > publisher (a 
 > presence server), publishes the complete view of the state - its own 
 > subscriptions. There is no overlap between servers. The compositor 
 > combines these together using a basic policy (combine subscriptions 
 > together that are for the same presentity), and thats it.
 > 
 > I believe it works for mwi too.
 > 
 > I really feel that it is important that we make some simplifications 
 > so that we can make rapid progress here. I don't think we lose much 
 > since we can still get the desired feature; we just get it in a 
 > different way.
 > 
 > Thoughts?
 > 
 > -Jonathan R.
 > 
 > Robert Sparks wrote:
 > 
 > > Another way to state this conclusion is that we need to report
 > > success or failure of publishing each atomic element in an 
 > independent
 > > fashion. One quick and easy way to achieve that property 
 > is to allow
 > > only one atomic element per PUBLISH request.
 > > 
 > > I think I heard another way to do this mentioned during 
 > the meeting,
 > > where we move reporting the success/failure and any feedback from
 > > the attempt to publish each tuple into the message instead 
 > of trying
 > > to capture it all on the status line. For example (I think this is 
 > > what I heard suggested during the meeting), for presence, we could
 > > publish an entire pidf document with several tuples and in 
 > the presence
 > > response return an xml document with one element per tuple 
 > discussing
 > > the disposition of attempting to publish that tuple.
 > > 
 > > Something along the lines of the following (an example to 
 > convey the
 > > concept, not a proposal of a syntax)
 > > <publish-results>
 > >   <tuple id="023cfdsf3">
 > >    <success etag="39009sdf" expires="1800"/>
 > >   </tuple>
 > >   <tuple id="990429834">
 > >    <failure/>
 > >   </tuple>
 > > </publish>
 > > 
 > > If we were to pursue such an optimization, it might make sense to
 > > look at how to specify a separate etag value in the 
 > publish (currently
 > > what we put in an If-Match header) for each atom in the published
 > > document.
 > > 
 > > RjS
 > > 
 > > On Mon, 2003-07-14 at 19:58, [email-masked] wrote:
 > > 
 > >>All,
 > >>
 > >>I'll try to summarize the issues w.r.t. the atomicity of 
 > publication here in an attempt to converge the discussion 
 > towards a solution to this problem. BTW, I realized that my 
 > slides in the SIMPLE session were perhaps not crystal clear 
 > on what the problem at hand really was, so my apologies for that.
 > >>
 > >>The core problem is this: 
 > >>
 > >>EPA X sends a PUBLISH with {a, b, c}, after which EPA Y 
 > publishes {a, b}. When EPA X tries to refresh its 
 > publication of {a, b, c}, the request fails because of a 
 > collision, resulting in the EPA X quitting. EPA Y still 
 > refreshes its publication of {a, b}, which means {c} expires 
 > and goes away. As a result, the publication process has lost 
 > information of {c}. This is unacceptable, and with the 
 > current versioning mechanism, this can't be remedied by 
 > composer policy, for example.
 > >>
 > >>Instead, to get around the above problem, what you send in 
 > a PUBLISH needs to match the atomic element of the published 
 > information. So each PUBLISH needs to contain a single 
 > tuple, because the versioning and expiration all work on the 
 > single atomic element level anyway.
 > >>
 > >>This has the apparent drawback in that the PUA has to wait 
 > for a 200 OK after each PUBLISHed tuple before it can 
 > PUBLISH the next one. This occurs upon every refresh cycle, 
 > and in systems with high latency, may become a major issue 
 > in terms of performance.
 > >>
 > >>Ways to get around this inefficiency:
 > >>	- Remove the restriction on overlapping requests, i.e., 
 > allow "pipelining"
 > >>	  of PUBLISH requests
 > >>	- Treat the publisher of each tuple as a separate EPA, 
 > and therefore not
 > >>	  subject to this restriction in the first place (seems 
 > like cheating...) 
 > >>
 > >>In conclusion, my proposal is to go with having always a 
 > single tuple in a PUBLISH, and allow overlapping PUBLISH 
 > requests. To my knowledge, this would fulfill all the 
 > related requirements and solve the issue.
 > >>
 > >>Thoughts?
 > >>
 > >>Cheers,
 > >>Aki
 > >>
 > >>_______________________________________________
 > >>Simple mailing list
 > >>[email-masked]
 > >>https://www1.ietf.org/mailman/listinfo/simple
 > > 
 > > 
 > > 
 > > _______________________________________________
 > > Simple mailing list
 > > [email-masked]
 > > https://www1.ietf.org/mailman/listinfo/simple
 > > 
 > 
 > -- 
 > Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
 > Chief Technology Officer                    Parsippany, NJ 07054-2711
 > dynamicsoft
 > [email-masked]                     FAX:   (973) 952-5050
 > http://www.jdrosen.net                      PHONE: (973) 952-5000
 > http://www.dynamicsoft.com
 > 
 > 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jul 2003 05:22:36 -0400

inline.

[email-masked] wrote:

> If I understand the proposal you're making correctly, you want to
> remove all of the current discussion on segmenting presence state,
> and have each PUA publish their full view. Also, instead of using
> server-provided etags, you want a publication to be identified by a
> client-generated pstream-ID.

Right.

> 
> Firstly, I agree on removing segmentation, and the whole package
> that comes with it (collision detection, overriding, tuple-ID
> naming conventions etc.) As you say, this just complicates things
> unnecessaríly, and leaving these details to composer and
> publication authorization policy makes a lot of sense.
> 
> But about using PStream-ID instead of etags, I don't think it saves
> us a lot compared to the current usage of Etags. By having the
> server generate these identifiers (etags), their uniqueness within
> a presentity is guaranteed. With PStream-IDs, the EPA has to do
> some work in order to generate an ID that is guaranteed to be
> unique. Admittedly, this isn't a huge effort, but compared to
> having the server assign identifiers simply by incrementing a
> counter, may be slightly more complex. It anyway introduces the
> chance of colliding PStream-IDs, which we would have to deal with
> one way or another.

OK, this is a fair point.

> 
> Also, with PStream-ID, you'd still need an error response in case
> no such PStrean-ID exists in the ESC. So all in all, we save the
> task of defining/implementing the If-Match header field, but need
> more to handle the PStream-ID generation/collision issues.

Right.

Thinking about this more, I actually like etag more. With my proposed 
model that the published data from each PUA represents that PUA's 
"view" of the full presence state of the resource, this becomes a good 
match for the semantics of etag. Each published document just becomes 
one entity that represents the resource, using the http terminology. 
So, Etag becomes a reasonable candidate for this label.

> 
> So my counter-proposal would be to simplify along the lines you
> described, removing all of the segmentation things,  but still keep
> the Etags, If-Match headers. The only change in their usage would
> be to remove the collision detection altogether, so that the only
> case when a refresh/deletion would fail with a 412 would be if the
> publication had already expired (i.e., the etag no longer existed).

I agree with your counter proposal.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jul 2003 05:22:36 -0400

inline.

Right.

Right.

-Jonathan R.