Subject: AW: [Simple] Please comment: Do we want to take on partial public ation?

From: Schmidt Christian <[email-masked]>
Date: Fri, 13 Aug 2004 11:48:45 +0200

Hi Robert, 

mobile networks are always interested in increasing efficiency. Requirements for Presence Service in 3GPP Wireless Systems (draft-kiss-simple-presence-wireless-reqs-03) contains:
PUBL-REQ2: Partial publishing
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 publish one single <tuple> element of the presentity's PIDF document, while the document contains several <tuple> elements.

So, in general, I am interested in this work. Nevertheless, some information, concerning the possible increase in efficiency could be helpful for motivation.

Two short comments to the current version of the draft.

Section 4.2.
".. the PUA MUST NOT change the content type between full and partial event state publications."

is somehow in contradiction to Section 4.3. exceptional cases: "In case the PUA changes the content type..."

In Section 4.2 it is mentioned:
"When a presence user agent decides to use the partial publication machanism.."
What could be the basis for this decision? Keep in mind, that in case, the PA do not support partial publication, this decision could even decrease efficiency (fallback to full publication).

Best Regards,
Christian Schmidt

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Robert Sparks
Gesendet: Donnerstag, 12. August 2004 22:06
An: [email-masked]
Betreff: [Simple] Please comment: Do we want to take on partial publication?

Folks -

If you haven't already read it, please take a moment and
skim
http://www.ietf.org/internet-drafts/draft-lonnfors-simple-partial-publish-01.txt

We've had _very_ light list discussion on this draft. We talked
about it briefly at the interim in Boston, but it wasn't clear
that there was sufficient interest even in that room.

The primary question in that meeting was whether or not we
could meet the requirements this draft intends without doing
any additional standardization work (by having endpoints that
want to publish pieces act as one publisher per piece).

So speak up. Do you think this is a place SIMPLE needs to take
on more work? Who thinks we have a good enough solution for this
already? Who, in addition to the  authors of this draft, is willing
to spend time working on this problem?

Thanks,

RjS

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Adam Roach <[email-masked]>
Date: Mon, 16 Aug 2004 13:34:20 -0500

>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 publish one single <tuple> element of the presentity's…

I think Robert's question wasn't whether efficiency is important for 
wireless networks -- we all agree that it is -- but whether the existing 
mechanisms provided by the publication framework are sufficient. I argue 
that they are.

In particular, the requirement that you cite *is* already satisfied by 
the Etag handling in the base PUBLISH specification. Publication of a 
tuple without an indicated Etag generates a new stream of publications 
that can be composited by the presence server in any way it sees fit. 
So, one can trivially set up a system that accepts a new publication 
stream which represents a single tuple within a larger presence 
document; it is then possible to update that tuple and only that tuple 
without having to upload the entire presence document. This is all 
completely possible and expected with the current PUBLISH draft.

Personally, I have rather strong feelings that the partial publication 
work imposes substantial complexity on the system while providing an 
insignificant improvement in overall system efficiency. I believe that 
our efforts are best spent elsewhere.

/a

---

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Aug 2004 15:16:19 -0500

On Aug 16, 2004, at 1:34 PM, Adam Roach wrote:
[...]

> our efforts are best spent elsewhere.
At the risk of making a "me to" posting, I share Adam's concern about 
the complexity introduced by partial publication.

Ben.

---

From: Aki Niemi <[email-masked]>
Date: Tue, 17 Aug 2004 19:16:42 +0300

On Mon, 2004-08-16 at 21:34, ext Adam Roach wrote:
> Schmidt Christian wrote:
> 
> >mobile networks are always interested in increasing efficiency.
> Requirements for Presence Service in 3GPP Wireless Systems
> (draft-kiss-simple-presence-wireless-reqs-03) contains:
> >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 publish one single <tuple> element of the presentity's PIDF
> document, while the document contains several <tuple> elements.
> >  
> >
> 

Sure, of course you need to take into account the need to refresh each
of the per-tuple publications individually (and the overhead that
generates), plus the extra state required to handle those publications
and their etags. Just to say that there are costs in all optimisations,
generally.

> our efforts are best spent elsewhere.

Our efforts? While I agree with the complexity argument (seems like an
inevitable side-effect of optimisation), I have a hard time
understanding the reluctance to adopt or progress not only this but many
of the "optimisations", including partial-notify, event-filter, and
event throttle to name some of them. After all, these are all optional
features and no-one is required to implement them.

Since these drafts all have authors willing to work on them, it would
seem most of the concerns about scarce WG efforts spent on them are
already go away. They also seem to have community support (especially in
the mobile domain), so why not let them be progressed and get them over
with.

We could even progress them as experimental to reflect the fact that the
community had concerns about the cost vs. benefit of the mechanism?

Cheers,
AKi

---

From: Adam Roach <[email-masked]>
Date: Tue, 17 Aug 2004 11:39:51 -0500

>the mobile domain), so why not let them be progressed and get them over

These arguments could equally be applied to previous efforts to define a 
PHONECTRL verb (for IR remote control of phones), a TRANSFER verb (for a 
very limited subset of what REFER allows), an "Also" header for use with 
BYE (for a very limited subset of what TRANSFER would have allowed), a 
PING verb (which probably wouldn't have worked for its intended 
purpose), a DO verb (which would have allowed you to turn on and off 
your lamp, even if it roams onto another network -- because everyone 
knows that rendezvous is an important feature if you don't know where 
your appliances might end up), several different binary encodings for 
SIP, and a host of other ill-conceived ideas.

My point is that "people are willing to work on it" is a necessary 
condition for any work item, but it is far from sufficient. The work 
item must also represent a good idea that fits with the precepts of the 
protocol -- such as "generality over efficiency" (cf. TRANSFER).

/a

---

From: Aki Niemi <[email-masked]>
Date: Tue, 17 Aug 2004 20:02:06 +0300

> SIP, and a host of other ill-conceived ideas.

Each of which can demonstratively be shown to either be broken, or have
a more general solution. You have not shown either in this case. Yes,
partial-publish adds complexity, but is not broken. Per-tuple
publication is no more general (still presence-specific) - just
different.

> protocol -- such as "generality over efficiency" (cf. TRANSFER).

With the exception of course that there is no solution available that
would be more general, except the obvious one. (Personally, partial
*should* have been part of PIDF from the very beginning but that's too
late now...)

Cheers,
Aki

---

From: Adam Roach <[email-masked]>
Date: Tue, 17 Aug 2004 13:41:16 -0500

Aki Niemi wrote:

>a more general solution. You have not shown either in this case.
>

My argument is *precisely* that multiple publication streams for a 
resource is a more general solution that allows publication of part of a 
presence document.

/a

---

From: Aki Niemi <[email-masked]>
Date: Wed, 18 Aug 2004 12:24:15 +0300

> resource is a more general solution that allows publication of part of a 

And my argument is that it is no more general - just different. Even
worse, it makes things complicated. Consider those presence elements
that are siblings of <tuple> - does each PUA need to include them all,
or just one of them? How can the composer tell apart presence-level
attributes from completely different sources?

Each front-end PUA also needs to refresh its segment individually - even
if some other tuple has been updated in the mean time.

Also, the PUBLISH specification contains the notion of a PUA being an
entity, which is responsible for publication of all state it is aware
of. This property is confused by artificially creating a number of PUAs.
In practice, tuple-ids are no longer useful for identification, since
they are only supposed to be unique within a single PIDF document. This
complicates things for the composer.

None of these problems exist for the partial-publish, and in some sense
partial-publish is the more general solution, since it reuses the MIME
type and semantics of partial-notify.

Cheers,
Aki

---

From: Adam Roach <[email-masked]>
Date: Wed, 18 Aug 2004 14:36:03 -0500

Aki Niemi wrote:

>or just one of them?

These are general questions about presence publication that we're 
finally getting some traction on in the presence team. They're certainly 
not specific to the problem at hand.

> How can the composer tell apart presence-level

Isn't this part of the reason that we're moving towards having device 
identifiers in presence documents?

>type and semantics of partial-notify.

I guess I haven't been particularly clear in my logic in asserting *why* 
the existing solution is more general purpose. What you are proposing is 
specific to presence documents. If someone wanted to come up with some 
way to do the same thing for alternate event packages, they'd have to do 
a whole new partial publish specification for it. On the other hand, 
using the existing PUBLISH framework, contributing multiple streams of 
state for a single resource is built-in to the protocol. Exactly how 
these streams are composed into a single event state is the job of the 
notifier, and is completely a matter of local policy. This is precisely 
where different implementations can differentiate themselves.

So, in short, what's already specified for PUBLISH works for all event 
packages, both existing and future. The partial publication work you 
propose works for precisely one event package. The comparative 
generalities should be fairly obvious.

/a

---

From: Aki Niemi <[email-masked]>
Date: Thu, 19 Aug 2004 10:13:58 +0300

On Wed, 2004-08-18 at 22:36, ext Adam Roach wrote:
<<snip>>
> a whole new partial publish specification for it.

Are we talking about the same problem here? I want partial updates,
which PIDF doesn't support, unfortunately. Watcherinfo, for example,
already has that feature and it's built in to the document format, and
specified by the event package specs. And I would imagine any future
event package that needs partial updates would do the exact same thing.

>  On the other hand,

I'm not disagreeing with you in that multiple streams are part of the
publish framework. But if you "misuse" that feature to accomplish
something akin to partial updates for presence, then I have a problem.
IMHO, it's a hack that certainly doesn't avoid the complexity
partial-publish is said to introduce - it merely pushes it into the
composer. 

> generalities should be fairly obvious.

As I said above, the problem at hand is partial updates *specifically*
in presence. In perfect 20-20 hindsight, this problem would've best been
solved in PIDF already, by making it support partial state updates.
There is no need to look for generalities, since any future event
package need not make the same mistake.

Cheers,
Aki