Re: [Sip] RE: Identity after reinvite

I have a strong preference for (1). I intensely dislike accumulated 
hacks and entropy in a protocol. Backward compatibility is an important 
property, but 2543 compatibility is fast becoming a a concrete block 
chained to our legs.

We should declare a day that 2543 SIP implementations don't have to 
work right any more. I suggest we make that when 3261 goes to draft 
standard. We can couple that to decreasing entropy in another way - 
don't make more entropic stuff proposed standard until SIP itself gets 
to draft. Then we'll see what existing junk gets pulled from SIP 
because nobody implements it and be moving forward from a stable common 
base.

Donning flame-retardant BVDs...

Dave.

On Nov 16, 2004, at 12:29 PM, Cullen Jennings wrote:

> On 11/16/04 12:05 AM, "Jonathan Rosenberg" <jdrosen@cisco.com> wrote:
>
>> The solution, which rfc3261 warns of, is that a UA has to put its 
>> actual
>> identity in the From field URI, not what it saw in the To field of the
>> original request. This will break all compatibility with rfc2543, but
>> will work with other rfc3261 compliant endpoints, since the URI is no
>> longer used for dialog identification.
>
> At this point, I really see two paths forward for the connected party
> problem.
>
> 1) We do as suggested above and allow everything in the From and To 
> other
> than the tags to be changed in a Re-INVITE or UPDATE.
>
> 2) We create a new thing that is like invite with replaces but add a 
> new tag
> that is called say "subsumes". So if A and B have a dialog, or early 
> dialog,
> and one of them wants to change a From. The UA sends an INVITE for a 
> new
> dialog, indicates it replaces the old dialog, and indicates that it 
> subsumes
> it. The subsumes flag would mean that any existing media session, qos
> reservations, etc did not change and got moved to the new dialog.
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: oran@cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip