Subject: RE: [SIP] draft-ietf-sip-handoff-00pre8.txt

From: Ben Campbell <[email-masked]>
Date: Tue, 30 Jan 2001 14:00:06 -0500

Hi Rick,

You appear to be arguing that the application you envision should not prompt
the user. I don't hold an opinion one way or another about that. Do you also
argue that _no_ implementation should ever prompt the user?

I was not suggesting that the draft should _mandate_ prompting the user,
only that it should not _prohibit_ it. It seems to me the developer or owner
of a UA is in a better position to decide if it makes sense to prompt the
user in a given implementation or situation than we are.

> -----Original Message-----
> From: Rick Dean [mailto:[email-masked]]
> Sent: Tuesday, January 30, 2001 11:14 AM
> To: Ben Campbell
> Cc: [email-masked]
> Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> 
> 
> 
> Amazon does sessions by a fake directory at the end of
> URL's.  This technique has the advantage of never eliciting
> a dialog box for any browser with any setting.  Please 
> do not underestimate how unfamiliar* an end user can be.
> 
> If a UA is worried about destinations which badly handle
> INVITEs with "handoff" headers.  That UA should deny 
> HANDOFFs.  This will force the transferor to B2BUA, try
> another strategy, or give up.  If the transferee already
> pops up a message this is too late, and transferors
> will B2BUA to begin with.  
> 
> We predict frequently the HANDOFF will be intercepted
> by a B2BUA call controller and thus hidden from the 
> transferee.  This is for privacy and reliability considerations,
> and works most like the existing PSTN.
> 
> We confess, our goal is to build a transfer which works exactly
> like the existing phone system, but happens to use SIP.  When
> we complete this task, feel free to build a phone system
> which works differently.  We hope you find some customers.
> 
> Yes, proxies should be able to administratively block
> HANDOFF requests like any other.  Good point.  Do we need another 
> sentence to cover this?  Are you proposing a special header or 
> response code to indicate the proxy and not the end UA blocked it?
> Does it make a difference to the HANDOFF sending UA?
> 
> We already have another method which is "prompt the remote human".
> REFER to a web page does this best.  An audible
> question does not need a SIP extension.  
> 
> Wouldn't the REFER request to a web page need two promptings?  
> The first one is do you want to follow the URL and the second is the 
> question on the web page.  I can do more damage
> with a HTTP GET than a SIP INVITE, but most browsers follow 
> 302 redirects automatically anyway.
> 
> BTW, I am scared of what
> a REFER with method=REFER prompt would look like to an end
> user.  Clearly, the designers don't intend this.
> 
> Yes, sophisticated UA's with 19" monitors in expert mode will 
> defy the 
> draft and prompt the user.  It is their choice, and the IETF 
> tries hard
> not to mandate this behavior outside the protocol.  Hopefully the 
> UA will prompt after the HANDOFF final response, but before the 
> handoff-status, for timing reasons as you stated.
> 
> Thanks for the feedback.  
> 
> --
> Rick
> 3Com
> 
> P.S.  I will be largely unreacable from Feb 1-6 due to
> a vacation.  (Jackson Hole Wyoming :-)   
> 
> On Mon, Jan 29, 2001 at 04:00:54PM -0500, Ben Campbell wrote:
> > Sorry for the lateness of my comments. I just came back 
> from back to back
> > vacation and flu.
> > 
> > I am concerned about the statement that a UA should 
> automatically process a
> > HANDOFF without asking the user. This seems dangerous to 
> me; I envision a
> > scenario where someone calls me, then transfers me to a 
> billable service
> > without my consent. 
> > 
> > I did notice the section about being able to 
> administratively block such
> > things at a proxy. I am still thinking about whether that 
> is sufficient
> > protection, as it would require some level of 
> administrative forethought. I
> > suspect we would find a lot of cases of closing the barn 
> door after the
> > horses have left.
> > 
> > I realize you added this requirement because of timing 
> issues, but it seems
> > to be a rather harsh presumption of decisions that at least 
> sometimes should
> > be left to the user.
> > 
> > > -----Original Message-----
> > > From: Rick Dean [mailto:[email-masked]]
> > > Sent: Wednesday, January 17, 2001 12:27 PM
> > > To: [email-masked]
> > > Subject: [SIP] draft-ietf-sip-handoff-00pre8.txt
> > > 
> > > 
> > > 
> > > Dear SIP list,
> > > 
> > > Although we would like more time to 
> > > edit this poor draft, we feel a sneak
> > > peek is warranted due to its urgent nature
> > > with the upcomming meeting.
> > > 
> > > http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt
> > > 
> > > Some significant differences from REFER are:
> > >   * narrower scope
> > >   * method completes without prompting
> > >   * referred-by like header generated by transferee
> > >   * location of headers for spawned invite
> > >   * error processing & final notification
> > > 
> > > Cheers,
> > > Rick
> > > [email-masked]
> > > 
> > > 
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to [email-masked] with
> > > "subscribe sip-implementors" in the body.
> > > 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to [email-masked] with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: Rick Dean <[email-masked]>
Date: Tue, 30 Jan 2001 14:51:18 -0600

Agreed.  Sorry for coming on so strong.  I didn't mean to
be critical.  Thank you for posting your concerns.  
They are needed to design the best protocols.  
We do appreciate your feedback.  :-)

Yes, we hope all implementations never prompt their 
humans. This is not just for timing.  We acknowledge a 
security concern.  Hopefully, the explicit guidelines 
help make SIP easier to implement.  

The current drafts
statement reads "should" not "must".
Maybe additional explanation should be included.

Agreed, because of timing, human prompting 
should be done inbetween HANDOFF response and handoff-status.
Unfortunately, including this guideline 
will probably increase the number of UAs which will.
Let the implementors who build prompting 
UAs bear the burden of making it work....most
importantly so average* human users do not call
it broken.

--
Rick