Subject: [Sip] RE: draft-ietf-sip-cc-transfer-05.txt

From: Robert Sparks <[email-masked]>
Date: Thu, 13 Sep 2001 11:17:42 -0400

The primary difference is whether or not you provide the transferee with
a URL that can be used to make the Transfer Target's phone ring at a 
later date. 
 
If the Transfer-Target is initiating a session, the SIP URL
that user agent provides in the contact _could_ be something only
valid for that session, or just something that it uses inside sessions
its agreed to participate in, but never accepts if it shows up in an
INVITE that is trying to establish a new session.
 
Of course, you're still ultimately supplying the IP address of the
transfer target, opening it up to all manner of other annoyances.
Real "protection" will involve something like an anonymizing sip and
media proxy.
 
The point to take away from the draft is that you can construct
a successful transfer by sending a REFER to either side, and
you should consider which way is appropriate for the environment.
 
RjS

-----Original Message-----
From: Sriram Parameswar [mailto:[email-masked]]
Sent: Thursday, September 13, 2001 10:00 AM
To: Robert Sparks; [email-masked]'
Subject: RE: draft-ietf-sip-cc-transfer-05.txt

Hi: 

In scenarios 7.1 and 7.2 (Exposing Transfer Target and Protecting Transfer
Target: When the Transferee contacts the Transfer Target (or vice versa) the
contact has to be sent during session setup. So how are we actually
protecting the Transfer Target from the Transferee?

Thanks in advance, 

Sriram 

__________________________________________ 
Sriram Parameswar              Phone: 972-685-8540 
Interactive Multimedia Server (IMS) Fax: 972-685-3563 
Nortel Networks, Richardson USA  Email: [email-masked] 

-----Original Message----- 
From: Robert Sparks [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, September 11, 2001 9:32 AM 
To: Parameswar, Sriram [NGB:B658:EXCH]; Robert Sparks; [email-masked]' 
Subject: RE: [Sip] FW: Submission: draft-ietf-sip-refer-01.txt 

I think we should leave it as sipfrag, even it it happens to be 
a full message (any message/sip part qualifies as a message/sipfrag 
part). 

I'm just referencing the security framework since I expect we'll 
be chewing on that for awhile. 

RjS 

-----Original Message----- 
From: Sriram Parameswar [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, September 10, 2001 4:03 PM 
To: 'Robert Sparks'; [email-masked]' 
Subject: RE: [Sip] FW: Submission: draft-ietf-sip-refer-01.txt 

Robert: 
Quick question - in section 3.6.2.2 you say --> Each NOTIFY MUST contain a 
body of type "message/sipfrag". 
My question if (ignoring the obvious security problems) a UA wants it may 
copy the entire SIP message into the NOTIFY and use "message/sip", this 
seems to be disallowed or am I reading it wrong? 
For the usage of RPI will you be adding more into this document either by 
way of requirements or examples, or simply referring back to the privacy 
document? 
Thanks, 
Sriram 
__________________________________________ 
Sriram Parameswar              Phone: 972-685-8540 
Interactive Multimedia Server (IMS) Fax: 972-685-3563 
Nortel Networks, Richardson USA  Email: [email-masked] 

-----Original Message----- 
From: Robert Sparks [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, September 04, 2001 2:59 PM 
To: [email-masked]' 
Subject: [Sip] FW: Submission: draft-ietf-sip-refer-01.txt 

I've submitted an update to the refer draft reflecting 
the directions discussed at IETF 51. 
Until it appears in the repository, the document is available at 
http://www.nostrum.com/~rjsparks/draft-ietf-sip-refer-01.txt
<http://www.nostrum.com/~rjsparks/draft-ietf-sip-refer-01.txt>  
_______________________________________________ 
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
<http://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