Re: number of tuples

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]