Re: number of tuples

Should partial notification be a generic thing of CPIM or should every 
group create its own way of doing
partial notifications? If every group will do its partial notification 
protocol it means that there will be no way
to do partial notifications between different protocols. I am not sure it 
is really an issue.

Regarding data manipulation and notifications: we will need ways to 
address what part of the presence
document was changed and be able to modify it. I think that this is what I 
see as common thing between
data manipulation and publication. However, this commonality may be small 
enough so these two issues
should be dealt with separately anyway.

------------------------------------------------------------------------------
Avshalom Houri
Lotus Sametime, IBM







Jonathan Rosenberg <[email protected]>
01/12/2002 07:11
 
        To:     Avshalom Houri/Haifa/IBM@IBMIL
        cc:     [email protected]
        Subject:        Re: number of tuples

 

We are straying way off topic here, and wandering more into SIMPLE 
issues..... I will quickly add that the publication design team in 
SIMPLE went through long discussions on the relationship between this 
data manipulation and publication. The conclusion was that there were 
sufficient differences that publication was best done separately from 
data manipulation.

Anyway, I don't think that directly relates to the issue at hand here.

-Jonathan R.

Avshalom Houri wrote:
> 
> It seems that this should be part of a general solution of partial 
> notifications. You want to change only a single
> tuple or a string in your presence. It seems to me but I may be wrong 
> that the issue of partial notifications may be
> combined with the data manipulation issue as described in the following 
> drafts:
> 
> draft-ietf-simple-data-req-00.txt
> draft-isomaki-simple-list-man-sem-00.txt
> 
> In both cases we want to change only part of a data structure. It should 

> not matter if the data structure resides in
> the server and the client wishes to change it or the data structure 
> resides at the client and the server have a notification
> that should change only part of it.
> 
> Avshalom Houri
> Lotus Sametime, IBM
> 
> 
> 
> 
> 
> *Jonathan Rosenberg <[email protected]>*
> Sent by: [email protected]
> 
> 27/11/2002 17:12
> Please respond to Jonathan Rosenberg
> 
> 
>         To:        "Peterson, Jon" <[email protected]>
>         cc:        [email protected]
>         Subject:        Re: number of tuples
> 
> 
> 
> 
> 
> OK, let me elaborate some more on the motivation here.
> 
> The SIMPLE framework has the notion of publication, which allows a PUA
> to inform the presence server about the presentity state as it knows
> about it. The idea is that there can be multiple PUA for a presentity,
> each publishing a subset of the overall presence. My cell phone
> publishes its own state, my PC publishes its state, and so on. Each
> publication is a complete presence document, but complete only so far as
> that particular publisher (aka PUA) is concerned.
> 
> So, a reasonable case would be that I've got a cell phone and a PC, both
> of which are happily publishing their own tuples. At some point, from a
> web cafe, I decide to change my overall presentity note to "in a cafe".
> Since we allow a note to appear at the presentity level, it seems
> reasonable to allow the user to publish JUST the note at the presentity
> level. The presence server would then compose this with the tuples from
> the other devices.
> 
> This motivation aside, if we believe there is value of presentity-level
> information, such as the note, I don't see how we can mandate the usage
> of a tuple as required to convey that information.
> 
> -Jonathan R.
> 
> Peterson, Jon wrote:
>  > I do have one small reservation about this.
>  >
>  > Clearly, being "out to lunch" suggests that you are not available.
>  > Considering that an automaton, for whatever reason, might be 
> attempting to
>  > ascertain your presence, it would better to provide a more easily 
> digestible
>  > state - one could argue that "out to lunch" is reducible to CLOSED in 

> most
>  > circumstances, and that therefore it should appear in a <tuple>. 
While
>  > currently <note> can appear as a child of either <presence> or 
<tuple>, I
>  > don't think the possibility of using <note> in <presence> was 
intended to
>  > provide an alternative to <status>, a kind of out-of-band and
>  > non-interoperable means of expressing status info. I always assumed 
> <note>
>  > was comparable to an 'away message' in existing IM systems - but in 
PIDF
>  > that would presumably accompany an away <status> in a <tuple>.
>  >
>  > Are there other motivating examples in which a <note> would appear as 
a
>  > child of <presence> in which it does not effectively rephrase a 
<status>,
>  > and in which there would be no need for any <tuple>s?
>  >
>  > Jon Peterson
>  > NeuStar, Inc.
>  >
>  >
>  >>-----Original Message-----
>  >>From: Jonathan Rosenberg [mailto:[email protected]]
>  >>Sent: Monday, November 25, 2002 2:51 PM
>  >>To: [email protected]
>  >>Subject: number of tuples
>  >>
>  >>
>  >>I raised this issue during the IETF meeting, and was asked to take it 
to
>  >>the list.
>  >>
>  >>PIDF currently specifies that a presence document has to have ONE or
>  >>more tuples [emphasis added]. I requested a change so that this could 
be
>  >>ZERO or more tuples. Why? Because its reasonable to have presence 
state
>  >>which contains just a note:
>  >>
>  >><presence entity="im:[email protected]">
>  >>   <note>Out to Lunch</note>
>  >></presence>
>  >>
>  >>Does anyone see any problems with this?
>  >>
>  >>Thanks,
>  >>Jonathan R.
>  >>--
>  >>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>  >>Chief Scientist                             First Floor
>  >>dynamicsoft                                 East Hanover, NJ 07936
>  >>[email protected]                     FAX:   (973) 952-5050
>  >>http://www.jdrosen.net                      PHONE: (973) 952-5000
>  >>http://www.dynamicsoft.com
>  >>
>  >>
>  >>
>  >>
>  >>  [reminder: [email protected] for non-technical
>  >>discussions, please]
>  >>
>  >>
>  >
>  >
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email protected]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> 
> 
>  [reminder: [email protected] for non-technical discussions, please]
> 
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email protected]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com