AW: [Sipping-tispan] ACR Requirements

["Jesske, R" <[e-mail]>]

Proposal:
[ACR-2] To avoid that the ACR rejects communications that have no 
originating Identity is unknown due to missing network capabilities providing a asserted identity  
and not restricted by a privacy service initiated or initiated 
on behalf by the originator of the communication a indication is needed 
to mark that this communication has no asserted identity included because of restricted network capabilities.

Is this acceptable?

More comments inline

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:[e-mail]] 
> Gesendet: Dienstag, 30. August 2005 00:18
> An: Jesske, Roland
> Cc: [e-mail]; [e-mail]
> Betreff: Re: [Sipping-tispan] ACR Requirements
> 
> 
> 
> 
> Jesske, R wrote:
> > Dear all,
> > After several discussions I had the last days regarding the ACR 
> > requirements I would like to propose the following:
> > 
> > 1. To define a requirement that marks a communication where 
> the ID is 
> > network restricted. The rest with regard to ACR is the 
> definition how 
> > the service will use such a network restricted information.
> > 
> > E.G
> > [ACR-2] To avoid that the ACR rejects communications that have no 
> > originating Identity due to the fact that this was 
> restricted by the 
> > network and not by a privacy service initiated or initiated 
> on behalf by 
> > the originator of the communication a indication is needed 
> to mark that 
> > communication as a network restricted communication.
> 
> I think I understand what you mean. But I am a little troubled by the 
> term "restricted" for this. I suppose it is enshrined by 
> prior use, but 
> it seems to convey the wrong implications to me. It implies 
> that the may 
> still be known to the network, but withheld at the whim of 
> the network 
> rather than at the whim of the user, and that somehow that is ok.
> 
> It would be more comforting to me if you were to use the term 
> "unknown" 
> rather than "restricted".
> 
> > 2. To delete the by-pass requirement for authorities.
> > 
> > Due to the bypass of ACR several issues were discussed. 
> Fact is it is 
> > not clear if this is required by regulation or not.
> 
> That would certainly simplify things.
> 
> > It was mentioned 
> > that a originating identification is needed. Due to the 
> fact that there 
> > is an other requirement ([REQ-CAT-1] For service applicability to 
> > special groups and interoperability with the PSTN/ISDN an 
> indication of 
> > the originating party category is needed. This is needed 
> due to the fact 
> > that some services apply a special behaviour to special user groups 
> > (e.g., like Pay-Phones). And [REQ-CAT-2] The originating 
> party category 
> > referred to in REQ-CAT-1 must be inserted by a trusted entity. )
> 
> At least this would move some of the discussion to another 
> topic, though 
> it probably won't make it go away.

I know but as I was told if such a requirement is existing than it is based on national solutions and will not described within the ACR service itself. Therefore from my point of view the Issue is disappeared. Of course such a service could be build upon such a originating category.

> 
> > it is 
> > proposed to use this functionality then if a bypass is needed. This 
> > requirement is independent from the ACR bypass, because a 
> originating 
> > user indication (Calling Party's Category) is needed anyway.
> 
> But this would then become just another requirement imposed 
> on ACR would 
> it not? 

For me it is not longer a requirement to ACR to have such a bypass for police ect.

>Using REQ-CAT-1 and REQ-CAT-2 will perhaps factor out the 
> determination of category, but the bypass of ACR based on category 
> remains. In fact it then becomes an issue to specify exactly which of 
> the categories are eligible to bypass ACR. (police:yes, fire:maybe, 
> pay-phone:no, prison:certainly.) That decision could be 
> defined for each 
> service, or it could be a user option. (But somehow I doubt 
> tispan would 
> let this be a user option.)

If such a service appear then it must be controlled by the network. 

With regard to the Calling Party's category we need the category for other purposes than bypassing. We need it as a selection criteria for services and routing.

Roland

> 
> 	Paul
> 
> > I hope we can go such a way and solve  the network 
> restricted problem.
> > 
> > Best Regards
> > 
> > Roland
> > 
> > 
> > 
> > Deutsche Telekom AG
> > T-Com Zentrale
> > Roland Jesske, TE332-2
> > Section TE33; Signalling, Gateways and Switching Systems
> > Am Kavalleriesand 3, 64295 Darmstadt, Germany
> > Phone:  [phone]
> > Fax:      [phone]
> > email:  _____ [e-mail]_
> > 
> > 
> > 
> --------------------------------------------------------------
> ----------
> > 
> > _______________________________________________
> > Sipping-tispan mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan