Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 4 Apr 2006 00:10:25 +0200

Hi John, 

>>1. Proxy impacts: There are no words on how the chaning of the URI 
>>will impact intermediate proxies (see separate thread). Normally our 
>>documents contains a "proxy impacts", but not in this. And, there is 
>>no agreed solution, so I consider that issue both MISSING TEXT and 
>>TECHNICAL.
>[JRE] Missing text can and will be added - I am already drafting it. 
>The main technical issue (i.e., needing to accommodate change of URI 
>mid-dialog, as anticipated in RFC3261) has been agreed since the 
>face-to-face in Vancouver. I don't see any other technical issue for 
>proxies (other than the impact on an authentication service, which is 
>minor in that it just means the Authentication Service can operate in 
>circumstances where previously it was unable to operate).
> 
>[CHH] The impact is that a RFC2543 uses, as far as I know, the whole 
>To header (not only the tag) to identify a dialog. So, if you send an 
>UPDATE with a new To header URI, such proxy will not recognize the 
>dialog.
> 
>Now, if you are saying that we don't need to take backward compability 
>into consideration
[JRE] Yes, that was the decision in Vancouver.

[CHH] Ok. Keith, just to clarify, is that now true for whatever
extensions we are going to work with in future?

>I don't agree with the statement that chaning the To header URI in a 
>response would break any transaction rules.
>Because, as I said earlier, the To header URI is not used for
transaction 
>identification in RFC3261. [/CHH]
[JRE] Yes, I stand corrected on that. I am willing to reconsider changes
to the To header field URI in a response, but somebody indicated during
the session in Dallas that there were dangers associated with that.  I
need to try to tease out the reasons for this on the mailing list.

[CHH] If there are dangers associated with the solution we should
document them.

>>2. Interworking (e.g. with PSTN): As was mentioned by Roland, this 
>>causes problems with interworking, ie it is not "backward compatible"
>>with the RFCs we have on interworking. Since we normally, when we 
>>define extension, try to consider existing extensions and
>>drafts/RFCs I think we shall do it also in this case - even if some
individuals 
>>(those thinking PSTN will be replaced by IP overnight) probably don't
>>care. So, I also consider that part both MISSING TEXT and TECHNICAL.
>[JRE] I consider specifying interworking with PSTN to be outside the 
>scope of this draft (an indeed outside the scope of all work items 
>other than those specifically aimed at PSTN interworking).
> 
>[CHH] I am not asking you to document PSTN interworking in the draft. 
>I am saying that draft won't work with our current PSTN interworking 
>specifications. Has there been a decission that we don't need to care 
>about that? [/CHH]
[JRE] No, there has not been such a decision. 
>>Introducing the ability to convey connected identity IMPROVES
interworking with PSTN compared with the situation at
>>present, because firstly connected identity can be conveyed on
establishment of a call to PSTN, and secondly a change of
>>connected identity can be conveyed mid-call.
> 
>[CHH] Ok, so if you think it improves interworking, how are you going
to signal the mid-call change in PSTN, after 
>you've sent CON/ANM (which the 200 OK triggers)? [/CHH]
[JRE] You would send whatever you would send in PSTN to indicate a call
transfer.
>>I admit that conveying connected identity during call establishment
from PSTN to SIP is more difficult than in the
>>opposite direction, but that does not make it worse than the present
situation. I see no reason to block something that
>>is useful just because it does not handle every situation when there
is
>>no proposed solution that is acceptable and solves all situations.
> 
>[CHH] Personally I think that a solution that does not handle the 
>interworking situation makes the solution pretty much unusable - 
>especially in networks where interworking occurs. Someone may say the 
>number of those networks is so small that we don't have to take that 
>use-case into consideration, but personally I disagree. [/CHH]
> 
>>Response identity, apart from not having a solution that finds favour
with the broader community, is unsuitable for mid-
>>dialog changes of identity.
> 
>[CHH] I am not saying that we shall disallow using UPDATE to change the
identity mid-call, as currently defined (you 
>wouldn't need to interwork that into PSTN, I believe). I am asking for
the possibility to also change it in responses, in 
>order to make it useful also with PSTN interworking. [/CHH]
[JRE] I understand your requirement, but there are also requirements to
change identity mid-call and we have a solution for that, so let's push
ahead with it. The response identity problem is harder (some people
think
impossible?) to solve, so why delay solving the problems we can solve
right now?

[CHH] I haven't heard of any technical problems. As far as I understand,
people have expressed some security concerns. Can't we just document
those and move on? I really think the best way is to have a single
document for this.

Regards,

Christer

> > 
> > > -----Original Message-----
> > > From: Christer Holmberg (JO/LMF)
> > > [mailto:[email-masked]]
> > > Sent: 31 March 2006 13:08
> > > To: Drage, Keith (Keith); [email-masked]
> > > Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt
> > > 
> > > 
> > > 
> > > Hi Keith,
> > > 
> > > I sent a mail within the "comments on sip-connected-identity" 
> > > thread. I
> > > presented some issues with the current solution, but also
> > pointed out
> > > that the draft currently does not talk about proxy impacts.
> > > 
> > > Regards,
> > > 
> > > Christer
> > > 
> > >  
> > > 
> > > -----Original Message-----
> > > From: Drage, Keith (Keith) [mailto:[email-masked]]
> > > Sent: 26. maaliskuuta 2006 19:25
> > > To: [email-masked]
> > > Subject: [Sip] draft-elwell-sip-connected-identity-01.txt
> > > 
> > > (As chair)
> > > 
> > > At the face-to-face meeting at IETF 65 we agreed that 
> > > http://www.ietf.org/internet-drafts/draft-elwell-sip-connected
> > -identity-
> > 01.txt formed the basis of part of our charter milestone to provide 
> > "Mechanism for Response Identity to IESG (PS).
> > 
> > This mail is to confirm that decision using the list. If you have 
> > issues with this decision, please respond to this mail.
> > 
> > Note: Please keep responses to this thread entirely separate to the 
> > thread on draft-cao-sip-response-identity
> > 
> > regards
> > 
> > Keith
> > 
> > Keith Drage
> > [email-masked]
> > 
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip