As there were no more comments on this matter, and no issues were raised during WGLC I will go ahead and start writing up the proto writeup.
Regards Shida On Nov 20, 2009, at 11:04 AM, Raj Jain wrote: > 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 > > > > > On Thu, Nov 19, 2009 at 7:09 PM, Shida Schubert <[email protected]> wrote: >> >> 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 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 >>> >>> >>> _______________________________________________ >>> BLISS mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/bliss >> >> _______________________________________________ >> BLISS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/bliss >> _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
