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

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

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, July 17, 2003 11:18 AM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: [email-masked]; [email-masked]; Niemi Aki
> (NMP/Helsinki); [email-masked]
> Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH:
> atomicity problem
> 
> 
> inline.
> 
> [email-masked] wrote:
> 
> > 
> >> -----Original Message----- From: ext Paul Kyzivat
> >> [mailto:[email-masked]] Sent: Wednesday, July 16, 2003 1:19
> >> AM To: Jonathan Rosenberg Cc: Robert Sparks; Niemi Aki
> >> (NMP/Helsinki); [email-masked] Subject: Re: Rethinking scope on
> >> publish, was Re: [Simple] PUBLISH: atomicity problem
> >> 
> >> 
> >> I generally like this idea, but maybe it is still too complex.
> >> 
> >> Why do we need the Pstream-ID? Simply say each publisher must
> >> choose unique tuple ids and leave it at that.
> >> 
> >> Regarding how to set up blocking of the ones you don't want, 
> >> instead of pstream, how about simply having each publisher
> >> include its identity in each tuple, as an attribute? This could
> >> be filtered out for most users.
> > 
> > 
> > tuple is presence specific. I was thinking of a time-stamp type
> > header (for presence, it probably carries the same info as in the
> > time-stamp element). But then Jonathan mentioned deleting a tuple.
> > 
> 
> My proposal is that deletion of a tuple is done using the 
> authorization stuff. Its not a publishing issue.

In an earlier post, you proposed using Expires: 0 and pstream header to delete a tuple. I was pointing out that having a time-stamp type header was sufficient enough to identify who published the most fresh information. Then I realised it was actually not sufficient enough due to your proposal to use the pstream header for deleting.

I was also objecting to having something in the tuple to identify the most recent publish since a tuple is presence specific.

> 
> The ID header is needed for soft-state. If the information being 
> published is represented by the content of the PUBLISH request, you 
> need an identifier in there to know when a PUBLISH updates/refreshes 
> something published previously, or its a new PUA. You cannot rely on 
> the From field or credentials for this disambiguation, since I may 
> have multiple devices acting on my behalf, all publishing for me, all 
> using my credentials and identity information.

Silly suggestion, but can we use contact-header for that?

> 
> I think that pstream-ID was rejected previously because we were ALSO 
> using tuple as semantically meaningful identifiers in publication 
> processing. I am proposing that this not be the case. The tuple IDs 
> only have meaning within the context of the published stream 
> (which is 
> pretty much the same semantic they have in a notification stream).
> 
> This also allows us to draw a clean line between the process of 
> composition, which is data-type specific, and this PUBLISH mechanism, 
> which is meant to not be specific to the data type. The "output" of 
> the publish mechanism, towards the compositor, is a series of N 
> published documents for a resource. The publish processor doesnt know 
> what these documents are, or what they represent. It only knows about 
> this pstream ID as a way of tagging them, so it can do the soft-state 
> management necessary.

That's exactly what I said on the mike in SIMPLE meeting, therefore I agree with you. The reply from one of the chairs was that we have to define the behaviour of the compositor anyway.

Regards,
Hisham

> 
> Also, consider further that deletion of published documents cannot 
> rely on some kind of data-type specific identifier, like a tuple. 
> Thats because the PUBLISH message with Expires:0 won't have any 
> content. So, you NEED to have an identifier in the header for this to 
> work.
> 
> -Jonathan R.
> 
> 
> -- 
> 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:27:42 -0400

inline.

[email-masked] wrote:

> 
>> -----Original Message----- From: ext Jonathan Rosenberg
>> [mailto:[email-masked]] Sent: Thursday, July 17, 2003
>> 11:18 AM To: Khartabil Hisham (NMP/Helsinki) Cc:
>> [email-masked]; [email-masked]; Niemi Aki 
>>>> [mailto:[email-masked]] Sent: Wednesday, July 16, 2003
>>>> 1:19 AM To: Jonathan Rosenberg Cc: Robert Sparks; Niemi Aki 
>>>> (NMP/Helsinki); [email-masked] Subject: Re: Rethinking scope
>>>> on publish, was Re: [Simple] PUBLISH: atomicity problem
>>>> 
>>>> 
>>>> include its identity in each tuple, as an attribute? This
>>>> could be filtered out for most users.
>>> 
>>> 
>>>  header (for presence, it probably carries the same info as in
>>> the time-stamp element). But then Jonathan mentioned deleting a
>>> tuple.
>>> 
>> 
> In an earlier post, you proposed using Expires: 0 and pstream
> header to delete a tuple.

Ah, sorry. By "deleting", I thought you meant the case where the home 
PC removes the tuple being published by the work PC, in our canonical 
example.

> I was pointing out that having a
> time-stamp type header was sufficient enough to identify who
> published the most fresh information. Then I realised it was
> actually not sufficient enough due to your proposal to use the
> pstream header for deleting.
> 
> I was also objecting to having something in the tuple to identify
> the most recent publish since a tuple is presence specific.

So we are in agreement, I think.

>>  published is represented by the content of the PUBLISH request,
>> you need an identifier in there to know when a PUBLISH
>> updates/refreshes something published previously, or its a new
>> PUA. You cannot rely on the From field or credentials for this
>> disambiguation, since I may have multiple devices acting on my
>> behalf, all publishing for me, all using my credentials and
>> identity information.
> 
> 

No. Its the same issue Ben had raised during sip in regards to the 
connection-reuse stuff. Consider two publishers behind different NATs, 
where both publishers have an address of 10.0.1.1. In that case, both 
of them might publish with this contact:

Contact: sip:10.0.1.1

which isnt unique. Generally, using IP addresses as unique identifiers 
is a bad idea.

> 
> 
>> I think that pstream-ID was rejected previously because we were
>> ALSO using tuple as semantically meaningful identifiers in
>> publication processing. I am proposing that this not be the case.
>> The tuple IDs only have meaning within the context of the
>> published stream (which is pretty much the same semantic they
>> have in a notification stream).
>> 
>> composition, which is data-type specific, and this PUBLISH
>> mechanism, which is meant to not be specific to the data type.
>> The "output" of the publish mechanism, towards the compositor, is
>> a series of N published documents for a resource. The publish
>> processor doesnt know what these documents are, or what they
>> represent. It only knows about this pstream ID as a way of
>> tagging them, so it can do the soft-state management necessary.
> 
> 
> That's exactly what I said on the mike in SIMPLE meeting, therefore
> I agree with you. The reply from one of the chairs was that we have
> to define the behaviour of the compositor anyway.

I remember Jon making that comment, but I dont think he was saying 
that we actually needed to specify what a compositor does.

Anyway, we are in agreement.

-Jonathan R.

---

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

inline.

Contact: sip:10.0.1.1

-Jonathan R.