RE: [Sipping] Re: Question on draft-rosenberg-sipping-acr-code-00

["Nataraju A B" <[e-mail]>]

Display name is being used only for the information being displayed to
user and not being used for automata - RIGHT ? 

Hence if the display name was set as anonymous and uri as some different
URI, then it should have processed as a non-anonymous URI...???

>From this point of understanding, I feel we should not do anything
logically based on user's display name, hence my earlier question...

Thanks & Regards,
Nataraju A.B.
-----Original Message-----
From: Jesske, R [mailto:[e-mail]] 
Sent: Monday, January 16, 2006 12:42 PM
To: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Cc: [e-mail]
Subject: AW: [Sipping] Re: Question on
draft-rosenberg-sipping-acr-code-00

Why should we change it?
If a user set the display name to anonymous, he would like to say the
identity given in From header is not my real identity.

Roland


> -----Ursprüngliche Nachricht-----
> Von: Nataraju A B [mailto:[e-mail]] 
> Gesendet: Sonntag, 15. Januar 2006 08:28
> An: Jesske, Roland; [e-mail]; 
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Betreff: RE: [Sipping] Re: Question on 
> draft-rosenberg-sipping-acr-code-00
> 
> 
> The draft draft-rosenberg-sipping-acr-code-00 specifies that 433
> response would be sent in case the from header carries display name -
> anonymous "OR" URI within the domain anonymous.invalid. 
> 
> This Does mean it would be rejected with 433 if display name is
> anonymous or URI domain anonymous.invalid. 
> 
> Sending 433 in case display name is anonymous whereas some 
> different URI
> (other than anonymous.invalid) is not a GOOD idea... 
> 
> Probably we can delete the mention the anonymity about display name...
> ???
> 
> Thanks & Regards,
> Nataraju A.B.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Jesske, R
> Sent: Friday, January 13, 2006 2:32 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: AW: [Sipping] Re: Question on
> draft-rosenberg-sipping-acr-code-00
> 
> John,
> I showed only how TISPAN handle the ACR service, of course other
> solutions are possible at least also for the UA.
> So I think that there is no problem also to use it as a generic
> solution.
> The RFC3323 gives guideline how to anonymise the identity of 
> the caller.
> So you can use the privacy header and the From header to do that.
> So from my understanding the privacy header can be sent to the UA so
> that there is a indication that privacy was required.
> An other possibility is that the URI in the From header is set to
> Anonymous. In both cases the call can be rejected with the 
> new response
> code.
> Of course as Paul said there are enough holes to bypass such 
> a mechanism
> using other names within the From header. Fore these cases I only see
> the possibility to use a barring mechanism (black/white list).
> 
> I think how it is described within draft-rosenberg-sipping-acr-code-00
> fits to the generic approach you are asking for.
> 
> Best Regards
> 
> Roland 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Elwell, John [mailto:[e-mail]] 
> > Gesendet: Freitag, 13. Januar 2006 09:04
> > An: Jesske, Roland; [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Betreff: RE: [Sipping] Re: Question on 
> > draft-rosenberg-sipping-acr-code-00
> > 
> > 
> > Roland,
> > 
> > The problem is, I thought the sipping-acr-code draft was 
> > intended to be
> > general purpose, not something that was restricted to use in TISPAN
> > networks. Adding something to the main SIP response code 
> > repertoire means
> > that anyone can use it, and we should have procedures that 
> > explain how it
> > should be used in reasonable situations. I think a reasonable 
> > situation is
> > where a UAS receives a request without an identity it can 
> > trust and where
> > that identity has been withheld for privacy reasons. I fail 
> > to see how I can
> > do this at present.
> > 
> > If we want a TISPAN specific solution, let's document it as 
> > such - I would
> > have no problem with that. Otherwise let's make sure we have 
> > a solution that
> > works elsewhere.
> > 
> > John 
> > 
> > > -----Original Message-----
> > > From: Jesske, R [mailto:[e-mail]] 
> > > Sent: 13 January 2006 05:56
> > > To: Elwell, John; [e-mail]; [e-mail]
> > > Cc: [e-mail]
> > > Subject: AW: [Sipping] Re: Question on 
> > > draft-rosenberg-sipping-acr-code-00
> > > 
> > > John,
> > > We have only specified the network based/application server 
> > > service. In Europe we have to provide this service within our 
> > > networks.
> > > 
> > > For a end device service this would be the best way to 
> > > forward the privacy header, so that a UA based ACR can reject 
> > > the communication. 
> > > 
> > > Best Regards
> > > 
> > > Roland
> > > 
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Elwell, John [mailto:[e-mail]] 
> > > > Gesendet: Donnerstag, 12. Januar 2006 21:31
> > > > An: Jesske, Roland; [e-mail]; [e-mail]
> > > > Cc: [e-mail]
> > > > Betreff: RE: [Sipping] Re: Question on 
> > > > draft-rosenberg-sipping-acr-code-00
> > > > 
> > > > 
> > > > Roland,
> > > > 
> > > > Thanks for the clarification. So in TISPAN networks ACR would 
> > > > apply when PAI
> > > > is missing due to privacy reasons. If a UAS receives a 
> > > > request without PAI,
> > > > how does it know whether it is for privacy reasons or not? Is 
> > > > the Privacy
> > > > header forwarded to the UAS?
> > > > 
> > > > John
> > > > 
> > > > > -----Original Message-----
> > > > > From: Jesske, R [mailto:[e-mail]] 
> > > > > Sent: 12 January 2006 12:51
> > > > > To: Elwell, John; [e-mail]; [e-mail]
> > > > > Cc: [e-mail]
> > > > > Subject: AW: [Sipping] Re: Question on 
> > > > > draft-rosenberg-sipping-acr-code-00
> > > > > 
> > > > > That what we specified within ETSI is based on the PAI and 
> > > > > the privacy header. When the user expresses his wish to 
> > > > > anonymise it's public ID the ACR service will be invoked.
> > > > > With regard to the from header there is no triggering for the 
> > > > > ACR service.
> > > > > 
> > > > > That is the same behaviour as for the equivalent PSTN/ISDN 
> > > > > service and the regarding requirements from regulation.
> > > > > 
> > > > > It is not the requirement to block calls where a PAI is 
> > > > > absent due to network reasons like interworking with analogue 
> > > > > networks.
> > > > > 
> > > > > The idea of an other response code for an untrusted identity 
> > > > > could be the basis for a new service that is not defined yet. 
> > > > > But thinkable.
> > > > > 
> > > > > Best Regards
> > > > > 
> > > > > Roland
> > > > > > -----Ursprüngliche Nachricht-----
> > > > > > Von: Elwell, John [mailto:[e-mail]] 
> > > > > > Gesendet: Donnerstag, 12. Januar 2006 08:49
> > > > > > An: Paul Kyzivat; Jonathan Rosenberg
> > > > > > Cc: sipping
> > > > > > Betreff: RE: [Sipping] Re: Question on 
> > > > > > draft-rosenberg-sipping-acr-code-00
> > > > > > 
> > > > > > 
> > > > > > The point that Paul makes about putting a fictitious or 
> > > > > > meaningless caller
> > > > > > ID in the From header was what I had in mind when I asked 
> > > > > my original
> > > > > > question. If I get an ACR response I just 
> substitute a caller 
> > > > > > ID at will,
> > > > > > and if this gets through my own domain then it will also 
> > > > > > avoid ACR. Without
> > > > > > PAI, Identity or AIB, the called domain or UAS has 
> no way of 
> > > > > > detecting this.
> > > > > > 
> > > > > > John
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Paul Kyzivat [mailto:[e-mail]] 
> > > > > > > Sent: 11 January 2006 22:45
> > > > > > > To: Jonathan Rosenberg
> > > > > > > Cc: Elwell, John; sipping
> > > > > > > Subject: Re: [Sipping] Re: Question on 
> > > > > > > draft-rosenberg-sipping-acr-code-00
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Jonathan Rosenberg wrote:
> > > > > > > > This is an old mail, my apologies for the really 
> > long time 
> > > > > > > to respond. 
> > > > > > > > This draft has started to get some attention 
> > again recently.
> > > > > > > > 
> > > > > > > > John raises an interesting point. This basic 
> question has 
> > > > > > > been discussed 
> > > > > > > > almost endlessly in the SIMPLE/GEOPRIV groups as 
> > well. The 
> > > > > > > issue there 
> > > > > > > > was that the common policy/presence policy 
> specs have had 
> > > > > > > fields that 
> > > > > > > > define an "anonymous" condition, and we've 
> > debated whether 
> > > > > > > > unauthenticated counts as anonymous.
> > > > > > > > 
> > > > > > > > Unfortunately this never really concluded; we just got 
> > > > > rid of the 
> > > > > > > > anonymous condition :(
> > > > > > > > 
> > > > > > > > In this particular case, I don't think it helps 
> to count 
> > > > > > > unauthenticated 
> > > > > > > > as anonymous. The reason is, the whole point of the 
> > > > > > > resposne code is 
> > > > > > > > that the caller can do something different in an 
> > attemtp to 
> > > > > > > get the call 
> > > > > > > > through. In this case, the caller has not actually 
> > > > TRIED to be 
> > > > > > > > anonymous; its just that their service provider didn't 
> > > > > do PAID or 
> > > > > > > > sip-identity. So, if the call is rejected as 
> > anonymous, the 
> > > > > > > caller will 
> > > > > > > > be surprised, since it wasn't anonymous as far as 
> > they were 
> > > > > > > concerned, 
> > > > > > > > and there is nothing they can do about it to 
> make it not 
> > > > > > anonymous.
> > > > > > > 
> > > > > > > The problem is that there is no good way to tell the 
> > > > > > > difference between 
> > > > > > > blocked and unavailable. When using Privacy, the Privacy 
> > > > > header is 
> > > > > > > removed before the request gets to the UAS.
> > > > > > > 
> > > > > > > While responding to this I noticed something missing from 
> > > > > > > draft-rosenberg-sipping-acr-code-00: it does not specify 
> > > > > > > proxy behavior. 
> > > > > > > This is significant because it is possible for the ACR 
> > > > > > feature to be 
> > > > > > > carried out by a proxy acting on behalf of the callee.
> > > > > > > 
> > > > > > > If that is happening, and the proxy is in the same trust 
> > > > > > > domain with the 
> > > > > > > caller, then the situation is a *little* 
> different, because 
> > > > > > > it can see 
> > > > > > > the Privacy header. So some blocked cases are 
> > > > > distinguishable from 
> > > > > > > unavailable cases. But that is still only a limited set, 
> > > > > > because the 
> > > > > > > caller could be in a different trust domain. So again, 
> > > > it becomes 
> > > > > > > necessary to fall back to reading the tea leaves to 
> > > > > decide between 
> > > > > > > blocked and unavailable. (Looking for Anonymous in the 
> > > > > From header.)
> > > > > > > 
> > > > > > > Note that looking at From isn't reliable either. 
> If I don't 
> > > > > > > want to be 
> > > > > > > blocked by ACR, I can just set my Privacy:id and set 
> > > my From to 
> > > > > > > something like: From: nobody 
> > > > > <sip:[e-mail]>. Then the 
> > > > > > > callee will treat me as having an unavailable 
> > address and let 
> > > > > > > the call 
> > > > > > > through.
> > > > > > > 
> > > > > > > I think the fundamental problem here is that 
> > > > > distinguishing between 
> > > > > > > unavailable and blocked can only work when all 
> callers and 
> > > > > > > callees are 
> > > > > > > linked to a single trust domain.
> > > > > > > 
> > > > > > > 	Paul
> > > > > > > 
> > > > > > > 
> > > > > > > > So, I'd suggest that we not include 
> > unauthenticated in the 
> > > > > > > list of cases.
> > > > > > > > 
> > > > > > > > -Jonathan R.
> > > > > > > > 
> > > > > > > > Elwell, John wrote:
> > > > > > > > 
> > > > > > > >> What if a UAS receives a request containing an 
> > > > unauthenticated 
> > > > > > > >> identity in the From header? If the UAS or user is not 
> > > > > > prepared to 
> > > > > > > >> trust the unauthenticated identity, the source of the 
> > > > > request is 
> > > > > > > >> basically anonymous. Is the new response code 
> > intended for 
> > > > > > > use in this 
> > > > > > > >> situation?
> > > > > > > >>
> > > > > > > >> John
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Sipping mailing list  
> > > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > > This list is for NEW development of the application of SIP
> > > > > > Use [e-mail] for questions on 
> > > current sip
> > > > > > Use [e-mail] 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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP