Subject: [BLISS] Shared Appearance use of Event header parameter

From: Alan Johnston <[email-masked]>
Date: Mon, 09 Nov 2009 01:38:27 -0600

Here's an issue Robert has raised that we should have some discussion on 
before sending this on the IESG.

The Shared Appearance draft defines a "shared" event parameter.

The question is whether this should instead be a SIP feature tag used in 
a Supported and Require header fields.

I've pulled out some text from the draft, RFC 3265, and a summary of how 
it is used.

What do people think?

Thanks,
Alan

- - - - -

 From draft-bliss-shared-appearance:

Section 12.1

   This specification defines a new event parameter 'shared' for the
   Dialog Package.  When used in a NOTIFY, it indicates that the
   notifier supports the shared appearance feature.  When used in a
   PUBLISH, it indicates that the publisher has explicit appearance
   information contained in the message body.  If not present in a
   PUBLISH, the Appearance Agent MAY assign an appearance number to any
   new dialogs in the message body.

 From RFC 3265:

4.4.2. Event Package Parameters

   If parameters are to be used on the "Event" header to modify the
   behavior of the event package, the syntax and semantics of such
   headers MUST be clearly defined.

Details on the usage:

- Appearance Agent discovery of non-Shared Appearance UA during 
subscriptions.  A NOTIFY sent without <appearance> elements does not 
necessarily mean the UA does not understand or support the extension, 
but a NOTIFY sent without the Event:dialog;shared does  indicate this.

- Sent by a UA and interpreted by an Appearance Agent to request no 
appearance number be assigned to a dialog (PUBLISH sent without 
<appearance> attribute but containing Event: dialog;shared

---

From: Raj Jain <[email-masked]>
Date: Thu, 19 Nov 2009 15:37:54 -0500

Hi Alan,

I think the Shared Appearances extensions of RFC 4235 do not really
match the semantics of SIP Supported:/Require: headers. I'd prefer the
way it is defined right now (Event: dialog;shared). The draft formally
extends the XML schema of RFC 4235 with a few attributes. These are
extensions to an event package, which is what (Event: dialog;shared)
communicates.

Your definition of the usage of the event package parameter sounds fine to me.

Thanks,
Raj

On Mon, Nov 9, 2009 at 2:38 AM, Alan Johnston <[email-masked]> wrote:
> The question is whether this should instead be a SIP feature tag used in a
> Supported and Require header fields.
>
> I've pulled out some text from the draft, RFC 3265, and a summary of how it
> is used.
>
> What do people think?
>
> Thanks,
> Alan
>
> - - - - -
>
> necessarily mean the UA does not understand or support the extension, but a
> NOTIFY sent without the Event:dialog;shared does  indicate this.
>
> appearance number be assigned to a dialog (PUBLISH sent without <appearance>
> attribute but containing Event: dialog;shared
>
>
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss
>

---

From: Shida Schubert <[email-masked]>
Date: Fri, 20 Nov 2009 09:09:38 +0900

I think option tag is necessary if UA that does not understand 
this specification barfs or breaks by receiving the parameter 
mentioned. 

 Regards
  Shida as an individual.

On Nov 9, 2009, at 4:38 PM, Alan Johnston wrote:

> Here's an issue Robert has raised that we should have some discussion on before sending this on the IESG.
> 
> The question is whether this should instead be a SIP feature tag used in a Supported and Require header fields.
> 
> I've pulled out some text from the draft, RFC 3265, and a summary of how it is used.
> 
> What do people think?
> 
> Thanks,
> Alan
> 
> - - - - -
> 
> - Appearance Agent discovery of non-Shared Appearance UA during subscriptions.  A NOTIFY sent without <appearance> elements does not necessarily mean the UA does not understand or support the extension, but a NOTIFY sent without the Event:dialog;shared does  indicate this.
> 
> - Sent by a UA and interpreted by an Appearance Agent to request no appearance number be assigned to a dialog (PUBLISH sent without <appearance> attribute but containing Event: dialog;shared
> 
>

---

From: Raj Jain <[email-masked]>
Date: Thu, 19 Nov 2009 21:04:07 -0500

Hi Shida,

I think the semantics in your question are about SIP protocol level
negotiation vs. event package level negotiation. The SA draft is
extending RFC 4235 for the shared appearences feature. I see it as
more of an event package extension as opposed to a SIP option tag
extension.

Just my 2 cents,
Raj