Subject: RE: [Simple] PUBLISH requirements

From: [email-masked]
Date: Fri, 20 Dec 2002 17:26:54 +0200

Hi All,

In order to help to progress the PUBLISH requirements work, here is a collection of requirements as a discussion opener. Comments are more than welcome.

REQ1: It must be possible for the PUA to add elements to the presence information as well as remove or modify existing elements of the presence information. 

REQ2: The publish mechanism must allow a PUA to change only part of the presentity's presence information. For example, a PUA must be able to only publish one single <tuple> element of the presentity's PIDF document, while the document contains several <tuple> elements.

REQ3: There must be one default content type for the publish mechanism.  

REQ4: It must be possible for the presentity to publish multimedia contents along with their communication means. 

REQ5: The publication mechanism must allow publishing from multiple PUAs of a single presentity. 

REQ6: The PUA must be able to publish to a specific piece of presence, shared among many PUAs (the number of sources must neither be limited nor pre-defined). This means that the published tuples need to be identified across all of the PUAs of a presentity. 

REQ7: Presence information must be always available. This means that in case the PUAs do not refresh presence information, some information must remain available for watchers, as - for example - the remaining information is hard-state data by nature or soft-state data but it has default value when data expired. 

REQ8: The PUA must be able to receive feedback about the result of a publishing transaction, the feedback must contain enough information for the principal controlling the presentity to know that the published presence information was successfully composed into the presence document by the Presence Server.

Regards,
Krisztian

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, December 13, 2002 7:36 AM
> To: Niemi Aki (NET/Espoo)
> Cc: [email-masked]
> Subject: Re: [Simple] PUBLISH requirements
> 
> 
> 
> 
> [email-masked] wrote:
> 
>  > The discussion in the SIMPLE session in Atlanta lead us towards
>  > another round of PUBLISH requirements.  I think it would be good to
>  > look at some requirements that might be arising from the fact that
>  > the dynamics of publishing are distinctly different from 
> the dynamics
>  > of notification.
> 
> Yes, I agree. Makes you glad we didn't go for NOTIFY as the 
> publication 
> mechanism...
> 
>   In order for the composer to make a
>  > coherent, single presence document out of the information 
> coming from
>  > many sources, the composer should be able to identify the published
>  > information uniquely across all of the PUAs of a presentity.
> 
> The information is needed by others too. A presentity might want to 
> setup a policy that says "only Joe and Bob can see my cell 
> phone". That 
> requires some unique way for the composer to identify which 
> tuple is the 
> cell phone.
> 
>  >
>  > For example, if we say that a tuple is the base data unit of
>  > published presence information, then a specific tuple has to have a
>  > common ID across all PUAs of a presentity.  In other words, the
>  > tuple-id needs to have semantics associated with it.  This way the
>  > composer can merge two "im-inbox" publications into one single
>  > presence document tuple.  This seems like an additional requirement
>  > for PIDF when it is used in publishing presence state.
> 
> I think this is a slightly different issue than above. One 
> requirement 
> is just identification of the tuples whose scope is broader 
> than the id 
> attribute. What you are suggesting here, I think, is almost to define 
> different classes of tuples. THis way, if I have two PCs, 
> each of which 
> has an "im-inbox", the composer could know to combine (or 
> treat in the 
> appropriate manner) those two tuples. That seems more of a 
> slippery slope.
> 
>  >
>  > In addition to this, I think there may also be other requirements
>  > there related to expiration of state, and the fact that not all
>  > presence information is wrapped into a <tuple> element.  E.g., the
>  > presentity level <note> element is not dependent of any 
> tuples.  How
>  > does one only publish a <note>?  Or remove it?
> 
> Well, PIDF is going to change to allow a document with just a note. I 
> raised this issue in IMPP and folks were ok with the change.
> 
> Now, to remove a note, you'd presumably publish an empty document.
> 
> That is, the assumption is that, as far as each publication 
> instance is 
> concerned, each publication represents the complete presence 
> state from 
> that instance.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Dean Willis <[email-masked]>
Date: Sat, 28 Dec 2002 00:35:54 -0600

> REQ3: There must be one default content type for the publish 

I don't think I understand this one. Are you saying that, for example,
if we use MIME for the body, that if the body doesn't specifically SAY
that it is some particular MIME type, that we should assume it is anyhow?

> REQ4: It must be possible for the presentity to publish multimedia 
> contents along with their communication means.

I don't think I understand this one either. Can you give an example?

> REQ7: Presence information must be always available. This means that 
> in case the PUAs do not refresh presence information, some 
> information must remain available for watchers, as - for example - 
> the remaining information is hard-state data by nature or soft-state 
> data but it has default value when data expired.

I think what you mean here is that the invocation of the publishing
mechanism should not, by default, erase any previously published 
information. For example, if many different tuples exist for a 
presentity, that publishing a single new tuple should not normally cause 
the other previously published tuples to be discarded. Right?

--
Dean