Subject: RE: [Sipping] Comments on draft-ietf-sipping-conference-package-10.txt

From: "Orit Levin" <[email-masked]>
Date: Thu, 14 Apr 2005 07:43:23 -0700

I will reply to Brian's "small issues" in a separate mail. (I promise
that it will take me less than two weeks, so, Brian, please, don't
disappear from the list for too long :-)

Regarding the "big partial notification issue":

First, indeed, the dialog package uses the same (as the conferencing
package) original to SIPPING "classic" partial notification mechanism.
This mechanism is built into an application XML schema by defining the
"state" attribute to selected elements.

Secondly, please, let's keep the two important (but loosely coupled to
conferencing) questions:
(1) Why did SIMPLE take a separate route and define its own different
from SIPPING (but still application specific) partial notification
mechanism?
(2) Is some XCAP or general DIFF mechanism a better generic way to go
for all SIPPING and SIMPLE packages in the future?
separately from the basic conference package discussion.

I would like to stress out that a "conference package" mechanism without
partial notifications is useless due to the conference application
nature, which by definition involves multiple asynchronous participants
and, in many cases, a large number of these participants.

The Conference Package authors and the chairs just recently discussed
this issue and agreed that the solution captured in -10 is the most (and
probably the only) practical one at this point of time: 
"This specification defines a basic partial notifications mechanism by
using a 'state' attribute [as described below].  This mechanism MUST be
supported by all subscribing clients.  Additional general partial
notifications mechanisms can be defined and applied to this package in
the future."

Thanks,
Orit.

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Wednesday, April 13, 2005 11:32 PM
> To: Brian Rosen
> Cc: Orit Levin; [email-masked]
> Subject: Re: [Sipping] Comments on
draft-ietf-sipping-conference-package-
> 10.txt
> 
> 
> On Apr 13, 2005, at 9:02 PM, Brian Rosen wrote:
> 
> > I have reviewed this draft and have the following comments:
> >
> > First a large issue, and then a bunch of small ones.  The big one
is: I
> > wonder if it is appropriate for a specific package, like this one,
to
> > define
> > a partial notification scheme.  Is that not a generalized problem?
Do
> > we
> > want every package to define its own?  Is this particular model
> > peculiar to
> > conference information?
> > This something all of sipping, not just those interested in
> > conferencing
> > should consider.
> >
> 
> Doesn't this use the same mechanism as the dialog package, modulo a
> "delete" operation?
> 
> But, that question raised, I am getting a lot of questions from OMA
> relating to the differences in the partial notification models for
> presence and xcap. It looks like  we can send a whole PIDF in presence
> NOTIFYs, and only a diff (or an indirect to a document that must be
> fetched via xcap) for xcap. There would be a benefit to a more
> consistent model here.
> 
> 
> --
> dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Apr 2005 12:34:43 -0400

It used to be that we believed that the "S" in SIP implied "Simple", as in
not complex.  We gave up on that long ago, but there is a principal here.
We have several packages that have needed partial notification, and so far,
all of them have defined their mechanism inside the package definition, and
no two are exactly alike (allowing that dialog and conference are very
similar).

This is bad engineering design, and we're allowing it.
It is unnecessarily increasing the complexity of the protocol and all
implementations of these packages.

We have an identified need, and we should collapse this work and the
pidf/xcap work, go back and look at dialog, and define a single way to do
partial notification in SIP events.

Brian

-----Original Message-----
From: Orit Levin [mailto:[email-masked]] 
Sent: Thursday, April 14, 2005 10:43 AM
To: Dean Willis; Brian Rosen; [email-masked]
Subject: RE: [Sipping] Comments on
draft-ietf-sipping-conference-package-10.txt

Thanks,
Orit.

is: I
to
Do