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

From: "Jesske, R" <[email-masked]>
Date: Mon, 8 May 2006 12:52:49 +0200

Hi,
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

> -----Ursprüngliche Nachricht-----
> Von: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Gesendet: Montag, 8. Mai 2006 11:12
> An: Elwell, John; Jeroen van Bemmel; Jesske, Roland; [email-masked]
> Cc: [email-masked]; [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 
> >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
> 
> 
> 
> > -----Original Message-----
> > From: Christer Holmberg (JO/LMF)
> > [mailto:[email-masked]]
> > Sent: 05 May 2006 08:39
> > To: Jeroen van Bemmel; Elwell, John; Jesske, R; [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [Sip] Issue 1 in 
> draft-ietf-sip-connected-identity-00.txt
> > 
> > 
> > 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,
> > 
> > >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???
> > 
> > I thought the changing of the URI was something that THIS GROUP has 
> > agreed is to be allowed.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Christer Holmberg (JO/LMF)
> > > [mailto:[email-masked]]
> > > Sent: 04 May 2006 21:55
> > > To: Elwell, John; Jesske, R; [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: RE: [Sip] Issue 1 in
> > draft-ietf-sip-connected-identity-00.txt
> > >
> > >
> > > 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
> > >
> > > > -----Original Message-----
> > > > 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
> > > >
> > > >
> > > > > -----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
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > >
> > >
> > > _______________________________________________
> > > 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

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Tue, 9 May 2006 12:37:17 -0500

Hello,

We have a similar need in ATIS. I support what Roland/TISPAN is proposing.

Cheers,

Martin 

-----Original Message-----
From: Jesske, R [mailto:[email-masked]] 
Sent: Monday, May 08, 2006 6:53 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: AW: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt

Hi,

Best Regards

Roland

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 May 2006 19:22:11 -0700

> header field in a response.

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.