Subject: [XCON] Partial notifications for the XCON event package

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 23 Jan 2008 16:20:39 +0200

Hi,

as you know, the XCON data model is an extension of the format in the 
SIP event package for conference state specification [RFC 4575]. RFC 
4575 also specifies a partial notification mechanism that also applies 
to the XCON event package, given that the XCON data model is an 
extension of the data format defined in RFC 4575.

The thing is that, at present, there is a general partial notification 
mechanism that is defined in the following draft:

http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-04.txt

The XCON event package could be defined to use the conference-specific 
partial notification mechanism as the default and the newer and more 
general one as optional. I believe this is something the WG should 
consider doing. However, for documentation purposes, I would suggest 
that we do not include this type of partial notification in the XCON 
event package. Let's specify the event package first and, later, if 
there is enough energy in the WG, we can put together a new draft 
describing how to use XML patch operations with the XCON event package.

Comments?

Cheers,

Gonzalo

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 Jan 2008 12:04:15 +0200

Hi,

I have double checked the data model and the current event package draft 
and it seems that the plan was to define a partial notification 
mechanism based on the mechanism defined in RFC 4575 in the event 
package draft.

I believe that, instead of basing our partial notification mechanism on 
RFC 4575, we should use xml patch operations instead. What do people 
think about this?

If we decide to use xml patch operations, do we want to make its support 
mandatory or optional (i.e., one or two MIME types)?

Cheers,

Gonzalo

---

From: Oscar Novo <[email-masked]>
Date: Wed, 30 Jan 2008 13:27:25 +0200

Hi,

I believe xml patch operations are much more efficient than the partial
notification method defined in RFC4575 but (as well) I believe the XCON
event package should be 100% backward compatible with RFC4575.

So, I would say to use the xml patch operations as optional (improvement
of the old method) in XCON using a different MIME type. 

Oscar

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 Jan 2008 13:30:50 +0200

Hi Oscar

> event package should be 100% backward compatible with RFC4575.

what do you exactly mean by "100% backward compatible"? Do you mean that 
we should be using the same MIME type as in RFC 4575?

Cheers,

Gonzalo

---

From: Oscar Novo <[email-masked]>
Date: Wed, 30 Jan 2008 14:43:20 +0200

Yes, I believe we should use the same MIME type as in RFC4575 and a
different MIME type for the 'xml patch operation' option. 

Oscar

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 Jan 2008 18:59:50 +0200

Hi,

the current event package draft has a whole section explaining why a new 
MIME type is needed. The reason it gives is the presence of state 
attributes in new elements. However, if we do not define new state 
attributes by use xml patch operations instead, we could reuse the old 
MIME type, as you suggest. Of course, we would need to define a new one 
for partial notifications based on xml patch operations.

Does anybody else have an opinion on this issue?

Cheers,

Gonzalo

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 30 Jan 2008 19:06:48 +0200

Gonzalo,
The concern was that the server needs to allow SIPPING client supporting the current event package and XCON client supporting the new data structure to receive notifications.

The full notification will be different for the two cases since there are different data models. So my view is that you need two different types enabling to request full notification for SIPPING and for XCON users

Roni 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Wednesday, January 30, 2008 7:00 PM
> To: Oscar Novo
> Cc: XCON
> Subject: Re: [XCON] Partial notifications for the XCON event package
> 
> Hi,
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 Jan 2008 19:11:48 +0200

Hi Roni,

the problem with reusing the old MIME type for full XCON notifications 
is that a server may send notifications with a set of XML elements the 
legacy client will not understand (i.e., the new elements defined by the 
XCON data model). The client will ignore them and everything will work 
fine. However, bandwidth will be wasted because all those new elements 
will be transmitted to simply be ignored at their destination. Do you 
see any other problem in addition to this bandwidth problem?

Thanks,

Gonzalo

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 30 Jan 2008 20:01:13 +0200

Gonzalo,
It is not only a bandwidth problem. It is also a size problem (big conferences). So why not keep the two different MIME types as in the current draft
Roni

> Sent: Wednesday, January 30, 2008 7:12 PM
> To: Even, Roni
> Cc: Oscar Novo; XCON
> > The concern was that the server needs to allow SIPPING client supporting
> the current event package and XCON client supporting the new data
> structure to receive notifications.
> >
> > The full notification will be different for the two cases since there
> are different data models. So my view is that you need two different types
> enabling to request full notification for SIPPING and for XCON users
> >
> >
> > Roni
> >

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 Jan 2008 21:06:30 +0200

Hi Roni,

I am not arguing either way. I just want to understand the issues 
involved before we make a decision. Can you elaborate on the size 
problem you hint at below? What is the actual problem you have in mind?

Thanks,

Gonzalo

---

From: Oscar Novo <[email-masked]>
Date: Thu, 31 Jan 2008 10:12:41 +0200

True, I didn't remember the new state elements defined in the event
packages... So, if we define them, we need a new MIME type. 

Oscar

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 31 Jan 2008 13:22:30 +0200

Hi,

well, regarding new state elements, I'd rather use xml patch operations, 
which is a far more general mechanism.

Cheers,

Gonzalo