Subject: RE: [Sipping] draft-watson-sipping-req-history-01

From: "Mary Barnes" <[email-masked]>
Date: Thu, 27 Jun 2002 14:54:52 -0500

Dean,

I'll avoid reacting to the tacky part of this email and go straight to your
last comment on the security/privacy mechanisms.  As I mention in the email
reponse to Frank's initial posting, we have added quite a bit to the updated
-02 draft on this topic.  We'd definitely appreciate feedback on whether
these requirements address these "really hideous interactions" to which you
refer.  Personally, I think these interactions are only slightly more
"hideous" than the "normal" security/privacy mechanisms which several other
drafts are also needing to address.

Mary. 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Thursday, June 27, 2002 1:29 PM
To: [email-masked]; [email-masked]
Subject: Re: [Sipping] draft-watson-sipping-req-history-01

On Thursday 27 June 2002 06:51 am, [email-masked] wrote:

> Take the following example. When Alice calls Bob and is diverted to
> Carol, it might be useful (depending on what you want to do) to have:
>
> - a way to inform Alice and Carol about what't going on. I.e. that
> the call
>   is being diverted and why it is being diverted.

A 302 Redirect returned to Alice lets her know that the call is being 
diverted. Even better it gives her the opportunity to decline being 
diverted.

> - a way to inform Carol about the party that was originally called

Carol knows who was originally called by looking at the value of the 
To: header field in the INVITE she receives.

> and the party that is diverting the call

an interesting concept that relates to the transitive identity question 
in use of REFER to effecta call transfer. Given that there are a number 
of different diversion mechanisms, there may be a number of different 
approaches here.

In the simple proxy scenario, the divertor is identified by a Via 
header field in the INVITE.

> - preventing this information from being presented

One must assume that any information handed to a client may be 
presented to the user, so PSTN "Here's some info but don't show it to 
anybody" doesn't work very well.

So how to hide it?

Bob's system proxies that call to Carol, thereby NOT sending a redirect 
to Alice (or telling her she's been diverted). If it really wants to 
hide the transference from Carol too, then it uses B2BUA mode. If it 
REALLY wants Carol to think the call is from Bob, it also does media 
relay.

> There are many more possibilities. These issues surfaced when we were
> trying to look at some interworking scenarios between QSIG
> supplementary services and SIP. The lack of this sort of
> functionality would reduce the QSIG functionality in an interworking
> scenarion
>
> Not surprising, this type of notifications, is also useful in a
> "pure" SIP environment. Which sort of brings me back to my original
> question.
>
> I support that the SIPPING and SIP groups should probably make this
> into an item to be addressed.

It's been hotly debated, and some variation on request history may be 
reasonable. The reason that it IS hotly debated is that people with a 
background in phone systems look at SIP and say "Hey, if we had this 
history thing, we could replicate all these existing services and make 
them work exactly the same way with SIP."  They generally do this 
without understanding how the Internet people building SIP intended it 
to work, how it could work without exactly replicating the phone 
system, or WHY it should work any differently from the phone system.

It's hard to say this without sounding tacky, but "request history" is 
often proclaimed as a requirement by new-to-SIP people arriving from 
the PSTN camp. Attempts to fend off inappropriate uses of history have 
probably obfuscated the effort of finding the real and reasonable core 
of value that I think is hiding in there somewhere.

There also tend to be really hideous interactions between request 
history mechanisms and privacy/security mechanisms, which further 
complicates things.

--
Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 27 Jun 2002 15:40:14 -0500

> I'll avoid reacting to the tacky part of this email and go 
> straight to your last comment on the security/privacy 
> mechanisms.  As I mention in the email reponse to Frank's 
> initial posting, we have added quite a bit to the updated -02 
> draft on this topic.  We'd definitely appreciate feedback on 
> whether these requirements address these "really hideous 
> interactions" to which you refer.  Personally, I think these 
> interactions are only slightly more "hideous" than the 
> "normal" security/privacy mechanisms which several other 

Thanks for your restraint, Mary, and for following up with the reference
to the new draft version. I do think we're making progess towards a
reasonable concept of history.

Ok, so I didn't manage to not sound tacky. I'm sorry.

Request-history can be used to replicate the PSTN, and many of us think
this is not a good idea and therefore react with instinctive horror
whenever somebody brings it up. However, the argument has been made (and
it seems plausible) that request-history can be used appropriately to
build new types of services, etc. 

My problem is that I don't know how to steer the discussion of
request-history toward such usages, as the PSTN-replication stuff keeps
popping up like the robot moles in the "whack a mole" game, and if it
doesn't get whacked pretty quickly somebody starts running with it and
the next thing we have is a standardized call model with ITU reference
triggers.

As for the security interactions -- if you don't consider the debate
we've had over the last two years about
privacy/security/confidentiality/identity/caller-ID to be in and of
itself "hideous" (or at least really complicated and painful) then
you're a dramatically more sympathetic and tolerant person than I am.
Clearly, information such as why a request was retargted is as sensitive
and and its protection as complex as is the identity of the party making
a request, and its interworking with PSTN suffers from the same "trusted
net, untrusted client" vs. "untrusted net, trusted client" schism that
affects identity. It's going to be interesting at the least.

--
Dean