Subject: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt

From: "Elwell, John" <[email-masked]>
Date: Tue, 02 May 2006 21:19:46 +0100

There are three open issues in this draft and a fourth that was raised
subsequently. This mail initiates discussion on the first issue. I will
initiate discussion on the other three issues in separate mails.

Issue 1 appears in section 5 and concerns the fact that this draft
intentionally does not address response identity, and therefore the identity
of a dialog-forming responder to an INVITE request is conveyed in a separate
request (e.g., UPDATE) in the reverse direction rather than in the response
to the INVITE request. The open issue is stated as:

      "OPEN ISSUE.  Should this be extended to allow a URI in the To
      header field of a response to change compared with the To header
      field in a request?  This could convey a connected identity in a
      response to an INVITE request, but it would not be authenticated.
      Authentication would have to rely on transitive trust, which might
      be feasible in a closed environment where the sips URI scheme is
      used."

There was considerable list discussion on this shortly after IETF65 with no
resolution. I won't attempt to summarise it. My opinion (for what it's
worth) is as follows.

1. Whereas RFC 3261 anticipates deprecating fixed To/From header field URIs
throughout a dialog (i.e., it anticipates that these will be allowed to
change mid-dialog), it says nothing to warn of any future removal of the
requirement that the To header field URI in the response be the same as that
in the request. Therefore I believe it would be dangerous to specify such a
change to the To header field URI.

2. The prime motivation for this draft was to provide authenticated
identity, i.e., to complement the sip-identity draft. An identity in the To
header field of a response cannot be authenticated, for reasons stated many
times on this list and at meetings. Therefore, at least in the Internet, a
response identity would have little value.

3. A comprehensive list of reasons for not going down that path were given
by Jon Peterson (editor of the Identity draft) in a message to this list on
5th April.

4. In closed environments an unauthenticated response identity might have
some value. But this could be achieved using P-Asserted-Identity, say,
rather than bending the rules for To headers in responses.

Therefore I am NOT in favour of enhancing the draft to provide identity in
the To header field URI of a response. Can people agree to this resolution
of the issue?

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 26 April 2006 20:50
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-00.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Session Initiation Protocol 
> Working Group of the IETF.
> 
> 	Title		: Connected Identity in the Session 
> Initiation Protocol (SIP)
> 	Author(s)	: J. Elwell
> 	Filename	: draft-ietf-sip-connected-identity-00.txt
> 	Pages		: 20
> 	Date		: 2006-4-26
> 	
>    Because of retargeting of a Session Initiation Protocol 
> (SIP) dialog-
>    forming request, the UAS can have a different identity from that in
>    the To header.  This document provides a means for that UA 
> to supply
>    its identity to the peer UA by means of a request in the reverse
>    direction and for that identity to be signed by an Authentication
>    Service.  The same mechanism can be used to indicate a change of
>    identity during a dialog, e.g., because of some action in a PSTN
>    behind a gateway.  This document normatively updates RFC 
> 3261 (SIP).
>    This work is being discussed on the [email-masked] mailing list.
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i
> dentity-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in 
> the body of the message.  
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-sip-connected-identity-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE 
> /internet-drafts/draft-ietf-sip-connected-identity-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

_______________________________________________
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

---

From: "Jesske, R" <[email-masked]>
Date: Thu, 4 May 2006 10:36:54 +0200

Dear John et all,
I'm sorry to go again into the opposite oppinion but I'm still  in favour of enhancing the draft to provide identity in the To header field URI of a response.

I don't know if we have to rediscuss all the possibilities and assumptions. But fact is that such a to header change would be useful for some services.

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Elwell, John [mailto:[email-masked]] 
> Gesendet: Dienstag, 2. Mai 2006 22:20
> An: [email-masked]
> Betreff: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 04 May 2006 11:39:29 +0100

Roland,

Well, you would need to convince the community that this is a worthwhile and
safe thing to do. Agreement to date is only to change From and To header
field URIs in mid-dialog requests. Changing the To header field URI in a
response would require separate agreement. I suggest you write an I-D and
try to get backing. However, I fear you will encounter strong opposition.

Regards,

John 

> From: Jesske, R [mailto:[email-masked]] 
> Sent: 04 May 2006 09:37
> To: Elwell, John; [email-masked]
> Cc: [email-masked]; 
> [email-masked]; Alexeitsev, D; [email-masked]
> Subject: AW: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt
> 
> Dear John et all,
> I'm sorry to go again into the opposite oppinion but I'm 
> still  in favour of enhancing the draft to provide identity 
> in the To header field URI of a response.
> 
> I don't know if we have to rediscuss all the possibilities 
> and assumptions. But fact is that such a to header change 
> would be useful for some services.
> 
> Best Regards
> 
> Roland
> 
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 4 May 2006 22:54:58 +0200

Hi,

>From the safeness point of view, I thought we already agreed (at least I haven't heard any disagreement) that doing it would not be unsafe, since the arguments that modifying the To and/or From header URI would affect the transaction logic were not true.

Regards,

Christer 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 4. toukokuuta 2006 13:39
To: Jesske, R; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt

Roland,

Well, you would need to convince the community that this is a worthwhile and safe thing to do. Agreement to date is only to change From and To header field URIs in mid-dialog requests. Changing the To header field URI in a response would require separate agreement. I suggest you write an I-D and try to get backing. However, I fear you will encounter strong opposition.

Regards,

John 

> I'm sorry to go again into the opposite oppinion but I'm still  in 
> favour of enhancing the draft to provide identity in the To header 
> field URI of a response.
> 
> I don't know if we have to rediscuss all the possibilities and 
> assumptions. But fact is that such a to header change would be useful 
> for some services.
> 
> Best Regards
> 
> Roland
> 
> 
> > subsequently. This mail initiates discussion on the first issue. I 
> > will initiate discussion on the other three issues in separate 
> > mails.
> > 
> > intentionally does not address response identity, and therefore the 
> > identity of a dialog-forming responder to an INVITE request is 
> > conveyed in a separate request (e.g., UPDATE) in the reverse 
> > direction rather than in the response to the INVITE request. The 
> > open issue is stated as:
> > 
> > 1. Whereas RFC 3261 anticipates deprecating fixed To/From header 
> > field URIs throughout a dialog (i.e., it anticipates that these will 
> > be allowed to change mid-dialog), it says nothing to warn of any 
> > future removal of the requirement that the To header field URI in 
> > the response be the same as that in the request. Therefore I believe 
> > it would be dangerous to specify such a change to the To header 
> > field URI.
> > 
> > identity, i.e., to complement the sip-identity draft. An identity in 
> > the To header field of a response cannot be authenticated, for 
> > reasons stated many times on this list and at meetings. Therefore, 
> > at least in the Internet, a response identity would have little 
> > value.
> > 
> > 3. A comprehensive list of reasons for not going down that path were 
> > given by Jon Peterson (editor of the Identity draft) in a message to 
> > this list on 5th April.
> > 
> > 4. In closed environments an unauthenticated response identity might 
> > have some value. But this could be achieved using
> P-Asserted-Identity, say,
> > Therefore I am NOT in favour of enhancing the draft to provide 
> > identity in the To header field URI of a response. Can people agree 
> > to this resolution of the issue?
> > 
> > John
> > 
> > > A New Internet-Draft is available from the on-line Internet-Drafts 
> > > directories.
> > >    the To header.  This document provides a means for that UA to 
> > > supply
> > > [email-masked] with the word unsubscribe in the 
> > > body of the message.
> > > You can also visit
> > > Internet-Drafts are also available by anonymous FTP. Login with 
> > > the username "anonymous" and a password of your e-mail address. 
> > > After
> logging in,
> > > http://www.ietf.org/shadow.html or 
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > 
> > > 
> > > 	a MIME-compliant mail reader.  Different MIME-compliant mail 
> > > readers
> > 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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 05 May 2006 07:08:38 +0100

Christer,

Technically it might work, but RFC3261 neither gives permission to change
the To header field URI in a response nor hints at a future lifting of this
restriction.

John

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: 04 May 2006 21:55
> To: Elwell, John; Jesske, R; [email-masked]
> From the safeness point of view, I thought we already agreed 
> (at least I haven't heard any disagreement) that doing it 
> would not be unsafe, since the arguments that modifying the 
> To and/or From header URI would affect the transaction logic 
> were not true.
> 
> Regards,
> 
> Christer 
> 
> 
> Well, you would need to convince the community that this is a 
> worthwhile and safe thing to do. Agreement to date is only to 
> change From and To header field URIs in mid-dialog requests. 
> Changing the To header field URI in a response would require 
> separate agreement. I suggest you write an I-D and try to get 
> backing. However, I fear you will encounter strong opposition.
> 
> Regards,
> 
> John 
> 
> > >       Authentication would have to rely on transitive 
> trust, which 
> > > might
> > > > Subject: [Sip] I-D 
> ACTION:draft-ietf-sip-connected-identity-00.txt
> > > > 
> [email-masked] for questions on current sip

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 5 May 2006 09:39:11 +0200

Hi, 

>RFC3261 Section 12.2.1.1: "[...]  It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a 
>subsequent revision of this specification."

Ok, I appologize for missing that.

However, that doesn't prevent us from also allowing to change the URI in responses in a "subsequence revision".

Regards,

Christer

----- Original Message -----
From: "Christer Holmberg (JO/LMF)" <[email-masked]>
To: "Elwell, John" <[email-masked]>; "Jesske, R" 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, May 05, 2006 9:22 AM
Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt

Hi,

>the To header field URI in a response nor hints at a future lifting of this

So, where does RFC3261 give permisson to change the To header field URI 
later in a request, then???

I thought the changing of the URI was something that THIS GROUP has agreed 
is to be allowed.

Regards,

Christer

> From the safeness point of view, I thought we already agreed (at least
> I haven't heard any disagreement) that doing it would not be unsafe,
> since the arguments that modifying the To and/or From header URI would
> affect the transaction logic were not true.
>
> Regards,
>
> Christer
>
>
> worthwhile and safe thing to do. Agreement to date is only to change
> From and To header field URIs in mid-dialog requests.
> Changing the To header field URI in a response would require separate
> agreement. I suggest you write an I-D and try to get backing. However,
> I fear you will encounter strong opposition.
>
> Regards,
>
> John
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 05 May 2006 08:31:16 +0100

Christer,

> Sent: 05 May 2006 08:23
> >Technically it might work, but RFC3261 neither gives 
> permission to change the To header field URI in a response 
> nor hints at a future lifting of this 
> >restriction.
> 
> So, where does RFC3261 give permisson to change the To header 
> field URI later in a request, then??? 
[JRE] The reference is given in section 5 of my draft.

> 
> I thought the changing of the URI was something that THIS 
> GROUP has agreed is to be allowed.
[JRE] Yes, this group agreed on what was anticipated by RFC3261. This
decision and the statement in RFC3261 apply only to mid-dialog requests.

John

> still  in

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 05 May 2006 08:52:57 +0100

Christer,

You are correct that it does not necessarily prevent us changing the URI in
a response in a "subsequent revision", but that is a different discussion
from the discussion we have already had and concluded on mid-dialog
requests. As I said before to Roland, if there is interest in doing this it
should be addressed in a separate I-D giving the background, requirements,
mechanism, etc.

John 

> Sent: 05 May 2006 08:39
> To: Jeroen van Bemmel; Elwell, John; Jesske, R; [email-masked]
> >RFC3261 Section 12.2.1.1: "[...]  It is expected that 
> mandatory reflection of the original To and From URI in 
> mid-dialog requests will be deprecated in a 
> However, that doesn't prevent us from also allowing to change 
> the URI in responses in a "subsequence revision".
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> permission to change

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 8 May 2006 11:12:23 +0200

Hi, 

>You are correct that it does not necessarily prevent us changing the URI in a response in a "subsequent revision", but 
>that is a different discussion from the discussion we have already had and concluded on mid-dialog requests.

I thought we now also have had a discussion about the responses, and agreed that it from a pure protocol logic perspective would cause no harm.

>As I said before to Roland, if there is interest in doing this it should be addressed in a separate I-D giving the 
>background, requirements, mechanism, etc.

Of course it can be done that way. But, isn't the issue that we then may end up with two mechanisms of doing the same way - the "request way" described in the connected identity draft, and the "response way" to be described in another draft? 

Regards,

Christer

> mandatory reflection of the original To and From URI in mid-dialog 
> requests will be deprecated in a
> However, that doesn't prevent us from also allowing to change the URI 
> in responses in a "subsequence revision".
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> So, where does RFC3261 give permisson to change the To header field 
> URI later in a request, then???
> 
> I thought the changing of the URI was something that THIS GROUP has 
> agreed is to be allowed.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> > > > > Title : Connected Identity in the Session Initiation Protocol 
> > > > > (SIP)
> > > > > Author(s) : J. Elwell
> > > > > Filename :
> > > > > type "cd internet-drafts" and then "get 
> > > > > draft-ietf-sip-connected-identity-00.txt".
> > > > >

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 08 May 2006 13:07:55 +0100

Roland,

I don't agree that discussion has shown that there is no harm in changing
the To header field URI in a response. There is no forewarning of this in
RFC3261. Even though we could use an option tag to ensure that a UA is
compliant, we can anticipate problems with proxies. I repeat that we need a
separate I-D to discuss such issues.

John 

> Sent: 08 May 2006 11:53
> To: [email-masked]; Elwell, John; 
> [email-masked]; [email-masked]
> As Christer said, I don't know if this is a straight way 
> forward to wait for an further document describing the other 
> way around.
> We  (seen from TISPAN purpose) have a requirement of an 
> additional connected identity in the response and that can be 
> fulfilled by changing the to header in the response. 
> The discussion showed it that there is no harm in changing 
> the to header field in a response.
> Why don't do it?
> 
> Best Regards
> 
> Roland
> 
> 
> > Von: Christer Holmberg (JO/LMF) 
> > Gesendet: Montag, 8. Mai 2006 11:12
> > An: Elwell, John; Jeroen van Bemmel; Jesske, Roland; [email-masked]
> > Betreff: RE: [Sip] Issue 1 in 
> draft-ietf-sip-connected-identity-00.txt
> > 
> > 
> > 
> > Hi, 
> > 
> > >You are correct that it does not necessarily prevent us 
> > changing the URI in a response in a "subsequent revision", but 
> > >that is a different discussion from the discussion we have 
> > already had and concluded on mid-dialog requests.
> > 
> > I thought we now also have had a discussion about the 
> > responses, and agreed that it from a pure protocol logic 
> > perspective would cause no harm.
> > 
> > >As I said before to Roland, if there is interest in doing 
> > this it should be addressed in a separate I-D giving the 
> > Of course it can be done that way. But, isn't the issue that 
> > we then may end up with two mechanisms of doing the same way 
> > - the "request way" described in the connected identity 
> > draft, and the "response way" to be described in another draft? 
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > Initiation Protocol

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 08 May 2006 13:08:47 +0100

Christer,

Concerning the harmfulness or otherwise of changing the To header field URI
in a response, see my reply to Roland.

Concerning your "two mechanisms" concern, that is exactly what I am trying
to avoid. We need the ability to send connected-identity in a mid-dialog
request because that is the only method we have at present of being able to
authenticate the identity, and also because of mid-dialog changes of
identity.

Concerning whether it is two documents or one, we can deal with that if and
when we have community consensus on response identity, provided that
consensus is achieved in time. The proper procedure is write in I-D, discuss
by email and at IETF66, and then, if consensus on the mechanism is achieved,
discuss how best to document it (by incorporating into the existing
connected-identity draft or keeping in a separate draft). I don't like
discussing documentation strategy before we have consensus on what we want
to document.

John 

> Sent: 08 May 2006 10:12
> To: Elwell, John; Jeroen van Bemmel; Jesske, R; [email-masked]

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 8 May 2006 17:33:57 +0200

Hi, 

>I agree with you that the argument that there is a hint in RFC3261 is not really an argument for not considering changing 
>the To header in a SIP response. The real argument that John did mention is that there is no mechanism for asserting a 
>response identity.

I don't think we have a requirement to assert the identity in a response. 

Regards,

Christer

On May 8, 2006, at 2:21 PM, Christer Holmberg ((JO/LMF)) wrote:

>
> Hi,
>
>> I don't agree that discussion has shown that there is no harm in 
>> changing the To header field URI in a response. There is no 
>> forewarning of this in RFC3261.
>
> I don't follow. Do you mean that we, in a current spec, need to "warn" 
> people about what will be changed/added in future revisions, and that 
> we are only allowed to do things in revision we have "warned" about in 
> earlier versions ?????? In most cases changes are done in revisions 
> because issues have been identified AFTER the previous version has 
> been released...
>
> And, EVEN if the current spec "warn" about something, that alone can 
> not be reason enough to say that it will cause no harm. If you expect 
> implementations to support something it shall be normative text - NOT 
> "hints" about what may happen in the future...
>
>> Even though we could use an option tag to ensure that a UA is 
>> compliant, we can anticipate problems with proxies. I repeat that we 
>> need a separate I-D to discuss such issues.
>
> I think the discussion has showed that there will be no problems with 
> proxies.
>
> The only argument I've heard is that it would mess up the transaction 
> logic, but we have shown that is not the case.
>
> Regards,
>
> Christer
>
>
>
>> To: [email-masked]; Elwell, John; [email-masked]; 
>> [email-masked]
>> As Christer said, I don't know if this is a straight way forward to 
>> wait for an further document describing the other way around.
>> We  (seen from TISPAN purpose) have a requirement of an additional 
>> connected identity in the response and that can be fulfilled by 
>> changing the to header in the response.
>> The discussion showed it that there is no harm in changing the to 
>> header field in a response.
>> Why don't do it?
>>
>> Best Regards
>>
>> Roland
>>
>>
>>> I thought we now also have had a discussion about the responses, and 
>>> agreed that it from a pure protocol logic perspective would cause no 
>>> harm.
>>>
>>> Of course it can be done that way. But, isn't the issue that we then 
>>> may end up with two mechanisms of doing the same way
>>> - the "request way" described in the connected identity draft, and 
>>> the "response way" to be described in another draft?
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 08 May 2006 21:10:13 +0100

Christer,

The main thrust of the connected-identity draft is providing an
authenticated connected identity. We have no mechanism for providing an
authenticated response identity, and an unauthenticated response identity
doesn't really fit with the rest of the draft and, in some people's opinion,
is not worthwhile. I must refer you again to Jon Peterson's email of 5th
April for a bunch of reasons why response identity is not viable. If you
wish to challenge that, I still think it would be more appropriate to put
forward your proposals in a separate draft, or at least reply to the points
made in that email.

John

> Sent: 08 May 2006 16:34
> To: Hisham Khartabil
> Cc: [email-masked]; Elwell, John
> >I agree with you that the argument that there is a hint in 
> RFC3261 is not really an argument for not considering changing 
> >the To header in a SIP response. The real argument that John 
> did mention is that there is no mechanism for asserting a 
> >response identity.
> 
> forward to 
> responses, and 
> draft, and

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 10 May 2006 17:31:54 +0100

Martin,

Noted, but why can't P-Asserted-Identity be used for your purposes? If some
new mechanism is required, why does it need to be tied to the present
connected-identity draft, which focuses on a cryptographically authenticated
identity?

John 

> From: Dolly, Martin C, ALABS [mailto:[email-masked]] 
> Sent: 09 May 2006 18:37
> To: Jesske, R; [email-masked]; Elwell, John; 
> Hello,
> We have a similar need in ATIS. I support what Roland/TISPAN 
> is proposing.
> 
> Cheers,
> 
> Martin 
> 
> Sent: Monday, May 08, 2006 6:53 AM
> To: [email-masked]; [email-masked];

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 31 May 2006 08:03:30 +0200

The problem is that we try to solve two different approaches.
1. The identity approach to get back an authenticated identity of the connected user
2. To get back an "additional connected identity" that is unauthenticated and provided by the user. 

Due to Jon's comments these are valid for the first case but does not harm the 2nd case.
So we need the "unanticipated respondent" problem does not exist, because we need only the "additional connected identity" in a final 200OK Response.

Looking on the second concern from Jon. That does not exist for our used cases, because we have also included a P-Asserted-Identity in our responses that identifies the Callee with a public identity so that the called user cannot cheat with the "additional connected identity".

The last problem of appearing the "additional connected identity" in Final responses like the 403 does not appear if we are using the "additional connected identity" only in 200 OK.

So at least we need only an "additional connected identity" when the called UA sends back a 200OK. Perhaps that was misleading in the past discussion that I didn't express this requirement well.

But nevertheless question for me is now how to go forward. Could we use the "dialogUriChange" for this narrowed scope or not.

Best Regards

Roland

> Von: Cullen Jennings [mailto:[email-masked]] 
> Gesendet: Dienstag, 23. Mai 2006 04:22
> An: Jesske, Roland
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Betreff: Re: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt
> 
> 
> 
> On May 8, 2006, at 3:52 AM, Jesske, R wrote:
> 
> I think there has been several emails that point out the 
> implications  
> of this do cause harm (check out pretty much any post on the subject  
> from Jon Peterson).
> 
> This has been a very long running debate and was discussed for  
> several years with agenda time at many meetings. The change the To  
> and put Identity in response solution has been considered and 
> I think  
> people have tried to explain the issues with it - I'm glad to spend  
> some more time explaining that. However, much more productive would  
> be trying to move off of this solution a little and look at the  
> requirements. What do we need to do - I think there are some straw- 
> man proposal that meet many of the requirements and do work.  
> Understanding what requirements they have issues would would be good  
> and help make them so they could be used.
>