Subject: RE: [SIP] More on privacy

From: "Mark Watson" <[email-masked]>
Date: Thu, 8 Feb 2001 17:50:08 -0000

Keith,

I had the same response as Flemming. The idea is that if information is
received from an untrusted source, the proxy sets rpi-screen to 'yes' for
the identities that it can verify to be correct and 'no' for those that it
can't. For identities received from a trusted source, the rpi-screen values
are maintained as received (though it could change some 'no's to 'yes's if
it can do the verification.

I guess your comment is whether we should be able to include two identities
both claiming to be of the same type and for the same party but with
different rpi-screen values. I think this would be a good idea as I don't
think we should be placing any unnecessary restrictions/dependencies in the
syntax at this point, as long as the semantics are clear.

...Mark

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: 06 February 2001 21:54
> To: Drage, Keith (Keith)
> Cc: [email-masked]'
> Subject: Re: [SIP] More on privacy
> 
> 
> There is currently an "rpi-screen" parameter defined in the 
> privacy draft which
> basically tags the Remote-Party-ID as verified/screened or 
> not. I'm not sure I
> understand why it doesn't address what you want to achieve here.
> 
> -- Flemming
> 
> 
> "Drage, Keith (Keith)" wrote:
> 
> > To add a further issue to the current discussions on privacy.
> >
> > The current specification of trusted versus untrusted 
> really only deals with
> > the presentation of information to untrusted entities.
> >
> > In the ISDN/PSTN world there is also the concept of 
> information being
> > provided by an untrusted source, for example an separate 
> enterprise network,
> > or a user attached to that separate enterprise network.
> >
> > In some cases the untrusted source may be the only entity 
> able to provide
> > truly accurate information. Therefore for Calling Line 
> Identification
> > Presentation there is a special indicator of user provided 
> unscreened.
> >
> > This means that in ISDN we have an either or situation for 
> CLIP, the user is
> > either told:
> >
> > -       this is the number for dialback purposes, but you 
> cannot trust the
> > reliability of this information because I cannot check it.
> >
> > or
> >
> > -       this is the number for dialback purposes, but I 
> have only provided
> > you with the information I can check, therefore it may not 
> get you back to
> > the real source of the call, but only to the enterprise 
> network that sourced
> > it.
> >
> > In SIP we could have the possibility of providing both, but 
> we would need to
> > discuss how we would identify these identifiers. For 
> example two different
> > identifier tags in the Remote-Party_ID header, or a common 
> identifier tag,
> > but a separate indication of level of screening.
> >
> > Keith
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: [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.
> 
> --
> Flemming Andreasen
> Cisco Systems
> 
> 
> 
> _______________________________________________
> 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.
>