Subject: RE: [Sip] Use of Require header field in connected-identity

From: "Elwell, John" <[email-masked]>
Date: Thu, 05 Oct 2006 08:02:01 +0100

Dean,

Good idea. I will include the following: "By sending a request with a
changed From header field URI only to targets that have indicated support
for this option, there should be no need to send this option tag in a
Require header field."

Also, following a suggestion from Cullen I will change the tag name to
"from-change".

John

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: 04 October 2006 22:13
> To: Elwell, John
> Cc: SIP; Paul Kyzivat
> Subject: Re: [Sip] Use of Require header field in connected-identity
> 
> 
> On Oct 2, 2006, at 2:39 PM, Elwell, John wrote:
> 
> > During WGLC I received a comment from Paul that when sending a mid- 
> > dialog request with a changed From header field URI, we 
> should also  
> > include a Require header field with option tag id-change. 
> In theory  
> > it should not be needed, because the peer UA will already have  
> > indicated id-change in the Supported header field, so it is known  
> > to support the capability. Paul's rationale was to include the  
> > Require header field in case something had gone wrong.
> >
> > I heard no other comment in favour of or against this. My opinion  
> > is that it is unnecessary - if something of this nature has gone  
> > wrong, then it is hard to be sure that simply including the 
> Require  
> > header field will be sufficient to avoid further problems.  
> > Furthermore, if we specify use of the Require header field, it  
> > would mean we have to specify what to do if we get back a 420. So  
> > on balance I am against making this change.
> >
> > Any other opinions?
> How about including in the draft a discussion of why the Require:  
> usage isn't useful? ;-)
> 
> --
> Dean
> 
> 

_______________________________________________
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