Re: [Simple] draft-ietf-simple-partial-publish - composition rules

Aki Niemi <aki.niemi@nokia.com> Thu, 20 October 2005 13:59 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESax5-0006pd-Vr; Thu, 20 Oct 2005 09:59:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESax3-0006pW-UF for simple@megatron.ietf.org; Thu, 20 Oct 2005 09:59:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13235 for <simple@ietf.org>; Thu, 20 Oct 2005 09:59:15 -0400 (EDT)
Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESb8z-00018V-TR for simple@ietf.org; Thu, 20 Oct 2005 10:11:47 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9KDvCfu015342; Thu, 20 Oct 2005 16:57:15 +0300
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 16:59:20 +0300
Received: from [10.162.252.47] ([10.162.252.47]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 Oct 2005 16:59:20 +0300
Message-ID: <4357A2B7.90907@nokia.com>
Date: Thu, 20 Oct 2005 16:59:19 +0300
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Anat Angel <anatang@radvision.com>
Subject: Re: [Simple] draft-ietf-simple-partial-publish - composition rules
References: <E7D8D1A37669BA428A72828A4DD999AD0A3803@rvil-mail1.RADVISION.com>
In-Reply-To: <E7D8D1A37669BA428A72828A4DD999AD0A3803@rvil-mail1.RADVISION.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Oct 2005 13:59:20.0394 (UTC) FILETIME=[77E3CAA0:01C5D57E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: 7bit
Cc: simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

Again sorry for the late response. Inline.

ext Anat Angel wrote:
> Hi
> 
>  
> 
> I have a question regarding composition rules:
> 
>  
> 
> Does a composer need to treat a UA that published its state in a 
> pidf-diff method (inside MODIFY request), as if it is more updated in 
> ALL the information it previously published? That means to consider this 
> publisher more updated about information that he didn't publish in this 
> particular request as well.

As with ordinary diff and patch, the patch usually only updates part of 
the information; the rest of the document remains unchanged. The 
implication is however, that the resulting full presence document is 
still considered valid in its entirety. No part is less valid than another.

> 
> Or does the composer need to treat it as if only the patch is more updated?
> 
>  
> 
> The significance of this question is best explained in the following 
> scenario:
> 
>  
> 
> The composer gets 2 INITIAL PUBLISH requests to the same presentity.
> 
> The first one (called A1) include 3 tuples with id's: tuple1, tuple2, 
> tuple3.
> 
> The second one (called B and comes after A1) include 2 tuples with id's: 
> tuple1 and tuple2.
> 
>  
> 
> The composer sends a first NOTIFY with full-pidf of tuple1 & tuple2 from 
> B (because it's more recent) and tuple3 from A1.
> 
> This is based on approach that information inside a more recent PUBLISH 
> is more updated.
> 
>  
> 
> Now another PUBLISH is received which is MODIFY to the first PUBLISH 
> (we'll name it A2). It is pidf-diff document. This PUBLISH include only 
> a <replace> to the contents of tuple1.
> 
>  
> 
> What should now be the content of a pidf-diff NOTIFY sent by the composer?
> 
> Is it only tuple1 (identical to the received PUBLISH with pidf-diff 
> document)?
> 
> Or should it also include tuple2 from A1, because we assume that 
> publisher A is more updated about the situation of the presentity?

This seems to fall into the area of composition policy, for which the 
PUBLISH nor partial-publish doesn't intend to find solutions directly.

Instead, look at:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-05.txt

and the composition draft I pointed out in the previous email.

Cheers,
Aki

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple