Subject: [Sipping] (no subject)

From: William Marshall <[email-masked]>
Date: Fri, 8 Feb 2002 17:19:59 -0500 (EST)

Jonathan wrote:
> It can work between domains only if a trust relationship is there to
> make sure that the proper interpretation and treatment are given to this
> information. Generally, that won't be the case.

A few years ago we ran out of carrier codes (CIC-codes) for long
distance carriers.  It seems the numbering plan only allowed for
900 of them.  So you now have to dial 10-1-xxxx instead of 10-xxx
(usually advertised as 10-10-xxx, for the early carriers).

So its really hard to say anything about "generally" when there
are so many pairwise combinations.

It is likely that in a few deployments, like within 3GPP and within 
PacketCable to mention just two, this trust relationship will be 
there.  I think those few deployments are enough to make the solution 
interesting and useful.  But I think I'd have to agree 
that "generally, [the trust relationship] won't be the case."  

Bill Marshall
[email-masked]

-----original message-----
Date: Fri, 08 Feb 2002 14:27:54 -0500
From: Jonathan Rosenberg <[email-masked]>
To: Dean Willis <[email-masked]>
Cc: Michael Hammer <[email-masked]>, [email-masked]
Subject: Re: [Sipping] Status Check: Subscriber Identification

I think people get bent out of shape on the privacy drafts because they
think it is trying to solve problems it doesn't. Practically speaking,
IMHO, the privacy R-PID provides a way for a domain with a trust
relationship with a user, to authenticate that user (using digest or
whatever), and then pass on that identity to other elements within the
domain for use. Similarly, if a request comes in and is not
authenticated, it provides a way to convey that as well. 

It can work between domains only if a trust relationship is there to
make sure that the proper interpretation and treatment are given to this
information. Generally, that won't be the case.

-Jonathan R.

Dean Willis wrote:
> 
> Well, I don't know about the other guys, but I tend to request
> authentication headers (if not present, use 401/407 to get) rather than
> trust any kind of calling-party-ID header to provide positive
> identification
> of the user. That sort of implies that the authentication framework
> needs to
> be either global or provide an attributable and verifiable transitive
> model
> (Cisco's proxy said this guy was Mike Hammer, and I can prove Cisco's
> proxy
> said it).
> 
> --
> Dean
> 
> ----- Original Message -----
> From: "Michael Hammer" <[email-masked]>
> To: "Dean Willis" <[email-masked]>
> Cc: "Henning Schulzrinne" <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Sent: Thursday, February 07, 2002 2:36 PM
> Subject: Re: [Sipping] Status Check: Subscriber Identification
> 
> > Yes.  I am assuming that a service provider needs positive filtering
> (if I
> > understand that) to determine when to permit signaling and bearer
> > connections to proceed to use resources of their network.
> >
> > Mike
> >
> >
> > At 01:55 PM 2/7/2002 -0600, Dean Willis wrote:
> > >You mean "the stuff we do authentication for"?
> > >
> > >--
> > >Dean
> > >
> > >----- Original Message -----
> > >From: "Michael Hammer" <[email-masked]>
> > >To: "Henning Schulzrinne" <[email-masked]>
> > >Cc: <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> > >Sent: Wednesday, February 06, 2002 10:04 AM
> > >Subject: Re: [Sipping] Status Check: Subscriber Identification
> > >
> > >
> > > > OK, but what about billing and regulatory requirements?
> > > >
> > > > At 10:46 AM 2/6/2002 -0500, Henning Schulzrinne wrote:
> > > > >In many cases, what I care about is to identify a small subset of
> > > > >people. Except for malicious call tracing, I don't get much
> benefit
> of
> > > > >knowing that Alice Smith (as opposed to somebody impersonating
> Alice
> > > > >Smith), whom I have never met and don't know, calls. As long as
> > > > >identities are cheap, negative filtering doesn't work. For
> positive
> > > > >filtering, semi-closed user communities are not ideal, but
> workable.
> > > > >
> > > > >Michael Hammer wrote:
> > > > > >
> > > > > > Granted.  But, then there is no guarantee that a user can be
> > >authenticated
> > > > > > by anyone but the local service provider originally subscribed
> to.
> At
> > >that
> > > > > > point forget mobility.  The degree of universality of the
> supporting
> > > > > > mechanism will restrict the universality of the service.
> Think
> about
> > >what
> > > > > > roaming looked like in the first version of mobile networks.
> > > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> >
> >
> 
> _______________________________________________
> 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

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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