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

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

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

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 5 May 2006 09:32:00 +0200

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."

Jeroen

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