Subject: RE: [Sip] draft-ietfsip-sips Open Issues: Derived Sessions

From: "Elwell, John" <[email-masked]>
Date: Wed, 28 Feb 2007 09:28:39 +0000

Francois, Paul,

Don't forget that REFER can be used in a number of different ways, not all
of which result in replacement of one dialog by another. In fact the
semantics of REFER do NOT mean replace a dialog and it is up to the sender
of the REFER request to clear down the old dialog if appropriate (e.g., on
receiving a NOTIFY request indicating success of the referred request).
Admittedly the particular case where a REFER request is sent on an
INVITE-initiated dialog and causes a new INVITE-initiated dialog to be
established will generally result in replacement of the original dialog, but
REFER itself does not actually say that this must be so.

One example of the use of REFER is with a method that does not form another
INVITE-initiated dialog, e.g., method=SUBSCRIBE. Here it is arguable that
the SUBSCRIBE request-URI can be completely decoupled from the security
state of the existing dialog.

Another use is sending REFER outside the context of a dialog. In such a
case, I guess the REFER Request-URI could be SIPS and the Refer-To URI could
be SIP, or vice versa.

I support trying to put in some general words, rather than being
over-prescriptive. However, please make sure the words are general enough to
cover all REFER scenarios.

Another related topic is Replaces. I would presume that an INVITE/Replaces
request to a SIP URI would not be considered to match an existing
INVITE-initiated dialog on the UA concerned that uses a SIPS URI as contact,
or vice versa. Does this need spelling out?

John

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 28 February 2007 01:09
> To: Francois Audet
> Cc: SIP
> Subject: Re: [Sip] draft-ietfsip-sips Open Issues: Derived Sessions
> 
> Francois,
> 
> I agree as long as you get the wording right, which I think 
> you are on 
> track to do.
> 
> The fundamental thing is that a session to a UA never be downgraded 
> *from what the user of the UA thought it to be* without the express 
> permission of that user (directly or via configured policy.) Session 
> here is a bit loose, since we are talking about replacing one dialog 
> with another while thinking of it as a single session.
> 
> 	Paul
> 
> Francois Audet wrote:
> > I'd like to close on the few remaining issues in the To-Do list of
> > draft-ietf-sip-sips-01, as 
> > described in Annex B.
> > 
> > Most of the issues in Annex B are related to how to treat "derived
> > sessions" where there is a
> > missmatch between the URI scheme used by the different sessions.
> > 
> > For example, say a session started with SIPS, and then a 
> REFER is sent
> > using a Refer-to URI that
> > points to a sip sheme. A similar issue could occur with 
> third party call
> > control.
> > 
> > I am reluctant to write ultra precise procedures attempting 
> to cover all
> > prossible problems that 
> > could happen on this issue, because it just seems that it 
> would be too
> > complicated and arcane
> > to explain.
> > 
> > Rather, I would propose that I write some general guidelines on the
> > principle of not downgrading
> > security by allowing a derived session to effectively downgrade from
> > SIPS to SIP. And then, I'd add
> > an example or two of common cases.
> > 
> > For example, a REFER in a session using SIPS should not point to a
> > Refer-To that is SIP. The UAS 
> > that receives such a request should either
> > 1) Warn the user about the downgrade and as for persmission 
> to accept it
> > (similar to text alreay 
> >    in RFC 3515)
> > 2) Reject it, probably with 403 "Forbidden".
> > 
> > Do people agree with this approach?
> > Suggestions?
> > 
> > _______________________________________________
> > 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: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Feb 2007 09:46:31 -0500

John,

I agree that those cases when REFER is used to replace one session with 
another are a subset of the total set of uses for REFER. In responding 
to Francois I was only considering that subset. I do think that the 
parties involved know this is the case. Certainly when the REFER results 
in an INVITE/Replaces, both the sender and the recipient know this.

There may indeed be more that can be said, still in a general way, about 
other uses of REFER. I don't know if we want this draft to attempt that. 
I suspect not.

	Paul