> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 11, 2003 4:02 PM > To: Tolga Asveren > Cc: Robert Sparks; [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] Re: Clarification needed - event id in > REFER refreshes > > > > > Tolga Asveren wrote: > > > >>>Given the ambiguity in the current spec, implementations of both the > >>>REFERer and the NOTIFYer need to recognize an Event header with no > >>>id as equivalent to an Event header with the id equal to the CSeq > >>>of that first REFER with a given dialog identifier - even for > >>>refresh SUBSCRIBES. > >> > > [TOLGA]Is this ambiguity a bug or is this the way it should be? > I didn't interprete it as a bug till now, and so was interpreting > a NOTIFY/SUBSCRIBE with no "id" as sent for the subscription > established with the first REFER. Is there a problem with the > semantics defined in RFC? It seems working. > > Well, one person's bug is another person's feature... > > The problem with this is that it requires extra special casing in the > implementation of refer events vs other events. For all other events the > subscription without an id is different from any subscription with an > id. With this bug you have to handle the naming of refer events > differently. [TOLGA]I see your point, but with that approach one can also question the reason why do we have REFER method -and not just refer as event package name in Event header in SUBSCRIBE- and why REFER changes the semantics defined for SUBSCRIBE (for example about this "id" issue when multiple subscriptions created by REFER are present in a dialogue), rather than only extending them. > > Paul >
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
