RE: number of tuples

I don't believe that the absence of a <tuple> necessarily implies that a
presence document is a partial notification. The sorts of uses that Mr.
Rosenberg described were actually cases of partial publication (which is
certainly a different problem than partial notification, and one that
clearly isn't currently in the scope of this WG). But moreover, I think it
is reasonable that a presence document could be disseminated to watchers
when no <tuple>s are available, and that this document might only contain an
informational note - this could be the entire, not partial, state of a
presentity.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Avshalom Houri [mailto:[email protected]]
Sent: Wednesday, November 27, 2002 8:41 AM
To: Jonathan Rosenberg
Cc: [email protected]; "Peterson"@il.ibm.com
Subject: 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]