Re: [sipcore] 4244bis and privacy
Hans Erik van Elburg <ietf.hanserik@gmail.com> Thu, 02 July 2009 08:03 UTC
Return-Path: <ietf.hanserik@gmail.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94EE93A6A9D for <sipcore@core3.amsl.com>; Thu, 2 Jul 2009 01:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.972
X-Spam-Level:
X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, URI_HEX=0.368]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiXJWWoAnHwq for <sipcore@core3.amsl.com>; Thu, 2 Jul 2009 01:03:32 -0700 (PDT)
Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 7C9203A67B2 for <sipcore@ietf.org>; Thu, 2 Jul 2009 01:03:31 -0700 (PDT)
Received: by ewy6 with SMTP id 6so1864506ewy.37 for <sipcore@ietf.org>; Thu, 02 Jul 2009 01:03:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=PbLrNn4kLoc2/HTtD9mZvJGIKlqBG8KOE8AbA4Zn3/M=; b=aDxggdBpxu/1hcmKqElYPEHsIKIrqOu/wkVMcD1t+rJmJhJp7keu/IlqEXIEWz4GrU 5nG/Sgp5ZKiDcOgmkjjiCbgBQ0AMwL+T1/fghqcCwMr5uCUyDnuAqR1xkgl2b1F/CMh/ 1iYVBfiXxsUv9z2tnxjJShgKox5FI+tyRiuxQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UtGVS/wZmicsvX+ZBuS/ElxFQ6iWww7wxyNBAtdkZFmhosRNgqTg2sJjIMMrnCxx1s RLprF8rEMENQmY2/Qbn/WsOc2lRh9vORIWFZwUjxN+JRXiRrwaSxO7aKrXyB4NX9phnJ T4mx2186l0ai+/sosCXGbsRNmYXtf2Z0aueyw=
MIME-Version: 1.0
Received: by 10.210.70.8 with SMTP id s8mr543149eba.54.1246521819711; Thu, 02 Jul 2009 01:03:39 -0700 (PDT)
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EC8AD11@zrc2hxm0.corp.nortel.com>
References: <CA9998CD4A020D418654FCDEF4E707DF0B168320@esealmw113.eemea.ericsson.se> <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> <4A43DEC9.1020802@gmail.com> <9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D00213AA4C@GBNTHT12009MSX.gb002.siemens.net> <C0E80510684FE94DBDE3A4AF6B968D2D05F2F323@esealmw118.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF1EBE2181@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D00213B56F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1EC8AD11@zrc2hxm0.corp.nortel.com>
Date: Thu, 02 Jul 2009 10:03:39 +0200
Message-ID: <9ae56b1e0907020103s1cd95dc7jf61d26c025e14602@mail.gmail.com>
From: Hans Erik van Elburg <ietf.hanserik@gmail.com>
To: Francois Audet <audet@nortel.com>
Content-Type: multipart/alternative; boundary="0015174c3c6a44caaf046db47af7"
Cc: sipcore@ietf.org, R.Jesske@telekom.de, Ian Elz <ian.elz@ericsson.com>, shida@agnada.com
Subject: Re: [sipcore] 4244bis and privacy
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jul 2009 08:03:38 -0000
Yes I think I do agree with you. /Hans Erik van Elburg On Wed, Jul 1, 2009 at 8:42 PM, Francois Audet <audet@nortel.com> wrote: > I see another problem with Privacy in RFC 4244. > > Currently, it talks about "Session" Privacy impacting HI and says nothing > about > "User" privacy impacting HI. (see RFC 3323) > > This makes no sense to me. Session is supposed to relate strictly > to SDP-level information (i.e., IP address inside SDP, and maybe some > other fields). > > I don't see at all why "session" would mean don't do HI. > > On the other hand 4244 is silent about "User" Privacy. I belive if > "user privacy" is used, then defintively it implies the URIs representing > that user should be anonymized. > > Views? > > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, June 30, 2009 00:30 > > To: Audet, Francois (SC100:3055); Ian Elz; Barnes, Mary > > (RICH2:AR00); R.Jesske@telekom.de; ietf.hanserik@gmail.com > > Cc: sipcore@ietf.org; shida@agnada.com > > Subject: RE: [sipcore] 4244bis and privacy > > > > Yes, I think something like this makes sense. > > > > John > > > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: 30 June 2009 00:06 > > > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de; > > > ietf.hanserik@gmail.com > > > Cc: sipcore@ietf.org; shida@agnada.com > > > Subject: RE: [sipcore] 4244bis and privacy > > > > > > I think the current "interpretation" is not terribly > > useful. I prefer > > > your suggestion. The current RFC 4244 text is not very clear. > > > > > > It seems to me that: > > > - Privacy should associated with a specific hi-entry (and > > perhaps any > > > entry that corresponds to that same user), and not the header > > > itself. > > > - That way, it is possible that specific entries be > > anonymize, but not > > > others. For example, if you call me without privacy, and I call > > > forward > > > you to John with privacy setup for myself, John should > > see an entry > > > for > > > you and an anonymized entry for me. > > > - There is no reason why "none" couldn't be used in this context. > > > Again, > > > with the same example as above, John could requies "none" > > > for him, and > > > I could set privacy on for myself. > > > > > > I don't think this type of rule for 4244bis would require > > any change > > > whatsoever to RFC 3323. It would be completely self-contained in > > > 4244bis. > > > > > > Comments? > > > > > > > -----Original Message----- > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > Sent: Monday, June 29, 2009 03:26 > > > > To: Audet, Francois (SC100:3055); Elwell, John; Barnes, Mary > > > > (RICH2:AR00); R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > > Cc: sipcore@ietf.org; shida@agnada.com > > > > Subject: RE: [sipcore] 4244bis and privacy > > > > > > > > Francios, > > > > > > > > I agree that 4244bis should not specify the actions of > > proxies etc > > > > where this is a matter of local policy. > > > > > > > > My original proposed change was to allow the inclusion of > > the value > > > > "none" in the alongside the value "history" to be included in the > > > > Privacy header parameter escaped in the > > hi-targeted-to-uri. (RFC4244 > > > > section 4.1) > > > > > > > > It appears however that the current interpretation of the Privacy > > > > header means that the value included in the Privacy > > header, which is > > > > applicable to the originating rather than retargeting user is > > > > applied to the retargeting user rather than the explicit value > > > > included for the retargeting user. > > > > The escaped privacy value is only used if there is no > > Privacy header > > > > or the Privacy header only contains the value "user". > > > > > > > > The end result of this interpretation is that including > > an explicit > > > > value "none" escaped as a Privacy parameter would have no > > effect and > > > > would have the same meaning as not including a Privacy header > > > > parameter escaped in the hi-targeted-to-uri. > > > > > > > > 4244bis is not the place to extend the sip Privacy handling to > > > > specify how 3rd party identities in sip messages should > > have their > > > > own specific privacy maintained. > > > > > > > > Allowing the inclusion of the explicitly Privacy=none > > value in the > > > > hi-targeted-to-uri would not change any handling at this time but > > > > would make the new H-I RFC suitable for use if an updated privacy > > > > RFC is proposed which does have specific support for 3rd party > > > > identities. > > > > > > > > H-I is not the only place where the explicit privacy of 3rd party > > > > identities is required. The Referred-By header is one other case > > > > where a similar explicit privacy may need to be considered in the > > > > future. > > > > > > > > regards > > > > > > > > Ian > > > > > > > > -----Original Message----- > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > Sent: 26 June 2009 16:55 > > > > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de; > > > > ietf.hanserik@gmail.com > > > > Cc: sipcore@ietf.org; shida@agnada.com > > > > Subject: RE: [sipcore] 4244bis and privacy > > > > > > > > I do see things that we should fix right-away in History-Info, > > > > regarding privacy. > > > > > > > > I also think that History-Info shouldn't "overstrech" and get too > > > > deep into the nitty gritty of privacy. What should be in > > HI is high > > > > level guidance. > > > > > > > > In section 3.1, for example, it says that Privacy header will > > > > determine if a History-Info *header field* can be included by an > > > > intermediary. This does not make any sense. What it should say is > > > > that the Privacy header will determine if a history-info > > *entry* can > > > > be added for the UA inserting the Privacy header. > > > > > > > > So, in my opinion, we can go ahead and fix that right now. > > > > > > > > I don't think we need to get into super low-level procedural > > > > descriptions of the type "proxy MUST this and that if Privacy == > > > > this and that". I believe privacy matters are > > policy-level decisions > > > > that service providers and enteprises will have, and they are not > > > > going to be implemented by simplistic procedural rules > > from an RFC. > > > > > > > > Comments? > > > > > > > > > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Ian Elz > > > > > Sent: Friday, June 26, 2009 01:08 > > > > > To: Elwell, John; Barnes, Mary (RICH2:AR00); > > R.Jesske@telekom.de; > > > > > ietf.hanserik@gmail.com > > > > > Cc: sipcore@ietf.org; shida@agnada.com > > > > > Subject: Re: [sipcore] 4244bis and privacy > > > > > > > > > > John, > > > > > > > > > > Your statement " not anonymise or remove any information > > > > that the UAC > > > > > has already placed in the request " is the key here. > > > > > > > > > > The UAC has not included the H-I entry, particularly the one > > > > > containing the identity of the diverting party. > > > > > > > > > > This was not considered in RFC3323 and we have an issue > > where we > > > > > cannot determine which entity included which information. > > > > > This creates a problem where a restriction by the > > > originating party > > > > > will prevent a downstream identity from permitting > > > presentation of > > > > > their identity. > > > > > > > > > > I agree with Mary that this probably requires an update to > > > > > RFC3323 so we should start by updating RFC3323 and then > > > > move on to the > > > > > other impacted RFCs. The issue that this will raise for > > > H-I is that > > > > > there will be another change required after the Privacy RFC > > > > has been > > > > > agreed. > > > > > > > > > > This is far from ideal but the 4424bis draft contains a lot > > > > more than > > > > > just this issue. > > > > > > > > > > Ian > > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: 26 June 2009 08:30 > > > > > To: Mary Barnes; R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > > > Cc: Ian Elz; sipcore@ietf.org; shida@agnada.com > > > > > Subject: RE: [sipcore] 4244bis and privacy > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: sipcore-bounces@ietf.org > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > > > > > Sent: 25 June 2009 22:45 > > > > > > To: R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > > > > Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com > > > > > > Subject: Re: [sipcore] 4244bis and privacy > > > > > > > > > > > > Roland, > > > > > > > > > > > > The reason you can't have "none" at the request level and > > > > > "history" at > > > > > > the entry level is because RFC 3323 states that you MUST > > > > NOT apply > > > > > > privacy to the message. Even if you put "history" in the > > > > > entries, the > > > > > > privacy service would just ignore that - per RFC 3323. > > > > So, if you > > > > > > want to change that behavior, then RFC 3323 should be > > > > > changed - i.e., > > > > > > the MUST NOT for the "none" could be changed to a SHOULD > > > > > NOT and then > > > > > > a general statement about possible exceptions. Then, we > > > could add > > > > > > something to RFC 4244 for this case. But, changing RFC > > > > > > 3323 is totally out of scope for what we are currently > > > > working on. > > > > > [JRE] I would interpret privacy 'none' in RFC 3323 as > > > > meaning that a > > > > > downstream entity must not anonymise or remove any > > > information that > > > > > the UAC has already placed in the request. > > > > > If a downstream entity chooses: > > > > > - not to add H-I, > > > > > - to add anonymised H-I, or > > > > > - to anonymise an H-I entry that some intermediate entity > > > > has added, I > > > > > don't see that as being in violation of what the UAC has > > > requested. > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > That all said, I would sure think that if you are leaving a > > > > > "trusted > > > > > > network" that you have a B2BUA in there, as I've said > > in other > > > > > > threads. Thus, the B2BUA builds a new request and certainly > > > > > can add a > > > > > > privacy header that it believes is appropriate since > > > the outgoing > > > > > > request is done by the UAC function of a B2BUA. > > > > > > > > > > > > Mary. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > > > > > Sent: Thursday, June 25, 2009 4:32 PM > > > > > > To: ietf.hanserik@gmail.com > > > > > > Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com; > > > > > sipcore@ietf.org; > > > > > > shida@agnada.com > > > > > > Subject: AW: [sipcore] 4244bis and privacy > > > > > > > > > > > > Hi Hans Erik, > > > > > > We have also to take regulatory into consideration. In > > > > Germany the > > > > > > last trusted network is responsible for anonymising > > information. > > > > > > > > > > > > But nevertheless if Network provider A wants to have History > > > > > > completely private this operator will set privacy > > > history for the > > > > > > header. > > > > > > If the succeeding Operator want to present elements the AS > > > > > which adds > > > > > > a entry has then to re label all entries from the > > > > preceding network > > > > > > and the entries from it's own network will be unmarked > > > within the > > > > > > Header. > > > > > > > > > > > > But never the less I fully agree to your last sentence. > > > > > > > > > > > > The real Question is if this should really be allowed > > > > that a entry > > > > > > marked with "none" overrules the privacy statement > > > > > "history" for the > > > > > > complete header. > > > > > > > > > > > > I'm against this behaviour. > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Roland > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > > Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > > > > > Gesendet: Donnerstag, 25. Juni 2009 22:32 > > > > > > An: Jesske, Roland > > > > > > Cc: mary.barnes@nortel.com; ian.elz@ericsson.com; > > > > sipcore@ietf.org; > > > > > > shida@agnada.com > > > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > > > > > > > > > Hi Roland, > > > > > > > > > > > > I don't understand the argument, by the time that the > > > > History-Info > > > > > > leaves operator A that wishes complete privacy, all the > > > > > History-Info > > > > > > headers should be anonymised according to 4244 and 4244bis. > > > > > > > > > > > > What is the point in mandating that operator A to force > > > > > operator B to > > > > > > also anonymise the entries "owned" by operator B. > > > > > > > > > > > > It is of course without question that each operator has > > > > > full privacy > > > > > > control over its own added entries. And each operator can > > > > based on > > > > > > local policy decide to remove the entire history if it > > > > > things that is > > > > > > wise to do. > > > > > > > > > > > > /Hans Erik > > > > > > > > > > > > > > > > > > R.Jesske@telekom.de wrote: > > > > > > > Hi Marry and Ian, > > > > > > > The whole discussion puzzle me. We have specified CDIV > > > > > > within TISPAN and 3GPP. > > > > > > > There is described that privacy "none" can be used for > > > > > > entries. BUT assuming that each entry has its own privacy > > > > > statement if > > > > > > needed. > > > > > > > I fully agree on Mary's comment that a privacy "history" > > > > > > cannot overruled by a privacy value "none" within a entry. > > > > > > > There may be operators that would like to keep the whole > > > > > > History Info private even if entries has other > > > statements, so the > > > > > > entity could add privacy history to the whole header. > > > > > > Nothing more. > > > > > > > > > > > > > > On the other side a Application Server including a entry > > > > > > should have the possibility to rewrite the entries so that > > > > > instead of > > > > > > "history" for the whole header the all received entries > > > > within the > > > > > > History-Info header will be marked with "history" and the > > > > > added header > > > > > > (which shall be presented to the terminating user) will > > > either be > > > > > > marked with "none" or will not be marked. > > > > > > > > > > > > > > Perhaps a hint could be given, but I do not insist on it. > > > > > > > > > > > > > > Best Regards, > > > > > > > > > > > > > > Roland > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > > > Von: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] Im > > > > > > > Auftrag von Mary Barnes > > > > > > > Gesendet: Donnerstag, 25. Juni 2009 18:29 > > > > > > > An: Ian Elz > > > > > > > Cc: sipcore@ietf.org; Shida Schubert > > > > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > > > Responses inline below [MB2]. > > > > > > > > > > > > > > Mary. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > > Sent: Thursday, June 25, 2009 10:13 AM > > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > > Schubert; > > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > Mary, > > > > > > > > > > > > > > I am a little concerned about one answer that you gave: > > > > > > > > > > > > > > > > > > > > > If you have a Privacy header with a value of "none" and a > > > > > H-I entry > > > > > > > with Privacy header parameter with value "history" what is > > > > > > the privacy > > > > > > > of the individual H-I entry? > > > > > > > [MB] We did not explicitly address the "none" in RFC > > > > > 4244, but the > > > > > > > general statement is the privacy headers at the request > > > > > > level override > > > > > > > any at the hi-entry level. [/MB] > > > > > > > > > > > > > > This means that if privacy is required for an individual > > > > > > H-I entry but > > > > > > > the originating user included "Privacy:none" in the request > > > > > > then there > > > > > > > is no option to include the real URI in the H-I entry. > > > > > > > [MB2] I'm confused here - the "none" definition is as you > > > > > > note below, > > > > > > > thus "none" prohibits the removal or anonymization of the > > > > > entries, > > > > > > > thus I would think you would fine this functionality > > > desireable. > > > > > > > However, this does not prohibit an entity based on policy > > > > > > to anonymize > > > > > > > (or remove entries if privacy is required for that > > > > domain if the > > > > > > > entity does not have access to a privacy service). [/MB2] > > > > > > > > > > > > > > This occurs as RFC3323 states in section 4.3: "However, if > > > > > > the Privacy > > > > > > > header value of 'none' is specified in a message, privacy > > > > > services > > > > > > > MUST NOT perform any privacy function and MUST NOT remove > > > > > or modify > > > > > > > the Privacy header." > > > > > > > > > > > > > > The only option for an intermediate node including a H-I > > > > > > entry where > > > > > > > "Privacy:none" is specified and privacy for the H-I URI is > > > > > > required is > > > > > > > to include an anonymous entry or not include the H-I entry. > > > > > > > [MB2] If privacy is required then yes, you include > > > > > > anonymous entries > > > > > > > or don't include. That's the basic privacy mechanism > > > > for privacy > > > > > > > levels of "session" "header" and "history" in the R-URI or > > > > > > "history" > > > > > > > in the specific entries, as well as when there is a policy > > > > > > for privacy > > > > > > > for the entries added by a specific domain. The "none" > > > > > > really has no > > > > > > > influence on the later case per se. [/MB2] > > > > > > > > > > > > > > In your previous response you stated that we would violate > > > > > > RFC3323 if > > > > > > > we specified additional behaviour for privacy explicitly > > > > > > stated with a > > > > > > > URI -n the H-I entry. I don't believe that this is the case > > > > > > as RFC3323 > > > > > > > only considered privacy in a two party scenario and did not > > > > > > consider > > > > > > > third party identities being included in a message > > > between two > > > > > > > parties. H-I is not the only case where this occurs as the > > > > > > Referred-By > > > > > > > header when included in the INVITE (or other request) > > > > > which results > > > > > > > from the REFER has the same issue. > > > > > > > [MB2] I can't necessarily disagree on this one (we can > > > > debate it > > > > > > > either way). But to fix it requires an update to > > RFC 3323 and > > > > > > > shouldn't be something that we want to fix in > > 4244bis. [/MB2] > > > > > > > > > > > > > > RFC4244 was the first time that there was a recognition > > > > > > that privacy > > > > > > > for these individual third party identities may be > > > > > > required. To allow > > > > > > > this explicit statement of privacy to be overridden by > > > > a generic > > > > > > > statement which is applicable to a different user is > > > > > > counterintuitive. > > > > > > > [MB2] See my comment above. But, as I have consistently > > > > > > said, the idea > > > > > > > that an entity might want to override the "none" is > > > > > > entirely based on > > > > > > > policy and 4244 and 4244bis allow privacy to be applied to > > > > > > the entries > > > > > > > that are added by that entity if the policy dictates > > > so (and we > > > > > > > already say that). [/MB2] > > > > > > > > > > > > > > The original Privacy header is usually included by or on > > > > > > behalf of the > > > > > > > originating user and should not be allowed to specify the > > > > > > privacy of > > > > > > > the original called user, e.g. the 800 number, and > > > prevent this > > > > > > > identity being presented if this user does not have the > > > > > > same level of privacy. > > > > > > > [MB2] As I tried to say in a previous response, a random > > > > > > entity (i.e., > > > > > > > one for whom the R-URI is not in a domain under its > > > > > control) cannot > > > > > > > add a privacy header to the Request. Per RFC 3323 an > > > > > entity may add > > > > > > > the header to a request only if it has the appropriate > > > > > > > relationship/authorization with the original called user > > > > > > who intiated > > > > > > > the request. And, I would find it very surprising if an > > > > > entity that > > > > > > > did have responsibility would apply privacy since > > > that would be > > > > > > > counter intuitive and I would hope that SPs would be > > > > judicious in > > > > > > > specifying the appropriate and inappropriate manner in > > > > which the > > > > > > > proxies they deploy and interface with privatize the > > > > > messages. The > > > > > > > protocol CANNOT control this behavior and that's why > > > > there is the > > > > > > > policy clause in 4244 and 4244bis. [/MB2] > > > > > > > > > > > > > > The real issue with the 800 scenario is as you have stated > > > > > > is that the > > > > > > > answerer will not know the original called identity and > > > > > will not be > > > > > > > able to correctly handle the call. As more generic call > > > > > centres are > > > > > > > used which will answer calls on behalf of many different > > > > > > organizations > > > > > > > using CTI and the original called identity to have to > > > > implement a > > > > > > > generic system asking the caller who he originally > > > > called appear > > > > > > > unprofessional, is inefficient and unproductive. > > > > > > > [MB2] And, as I noted, it is rare for a call centre to > > > > > route a call > > > > > > > directly to an agent without a user providing some sort of > > > > > > input. Even > > > > > > > companies like American Airlines, even though they have the > > > > > > info that > > > > > > > I enter via the IVR, they still ask some basic questions > > > > > > and there are > > > > > > > times when they have to reroute me. I don't think we > > > > can totally > > > > > > > automate things. And, again, once the call hits the > > > > > domain that is > > > > > > > responsible for that 800 number the entities in that > > > > domain have > > > > > > > control over how they muck with the R-URI, such that they > > > > > should be > > > > > > > able to use any IVR info to appropriately direct the call - > > > > > > it's not > > > > > > > the number that's meaningful, but how the system gets the > > > > > > call to the > > > > > > > right user and the additional information they provide as > > > > > > the call is > > > > > > > presented to the agent. I would honestly think that having > > > > > > something > > > > > > > other than an 800 number show up on the display would > > > > be far more > > > > > > > useful and in my experience in the systems I developed > > > > > > we're usually > > > > > > > talking about CTI interfaces so you have a lot you can > > > > do. And, > > > > > > > actually all of this really doesn't matter in that you MUST > > > > > > be able to > > > > > > > handle this situation independent of the privacy since > > > > > > History-Info is > > > > > > > optional, you need default behavior assigned. [/MB2] > > > > > > > > > > > > > > We have an opportunity to allow presentation of specific > > > > > identities > > > > > > > and to solve this particular problem so we should take it. > > > > > > > [MB2] The most we can do is to document the risks/impacts > > > > > > of the use > > > > > > > of the Privacy headers at the R-URI level. There is > > > > > already general > > > > > > > text in > > > > > > > 4244 and 4244bis that the privacy may impact whether the > > > > > > applications > > > > > > > get the information. And, as I noted before, most > > > > > > commercial systems > > > > > > > are using B2BUAs which will allow you far more control over > > > > > > the use of > > > > > > > the Privacy headers in the network. But, again, I don't > > > > > > think that's > > > > > > > something that should be address in 4244bis. [/MB2] > > > > > > > > > > > > > > I hope that we can get some wider discussion on this issue > > > > > > so a more > > > > > > > general consensus can be obtained. > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > > Sent: 24 June 2009 17:27 > > > > > > > To: Ian Elz > > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > > Schubert; > > > > > > > sipcore@ietf.org; Francois Audet > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > > > Responses inline below [MB]. > > > > > > > > > > > > > > Mary. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > > Sent: Wednesday, June 24, 2009 10:37 AM > > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > > Schubert; > > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > Mary, > > > > > > > > > > > > > > I was not proposing that we change the handling of H-I > > > > > > which is based > > > > > > > upon local policy. If that causes an issue for a network > > > > > > operator then > > > > > > > they can modify their local policy accordingly or arrange > > > > > with the > > > > > > > proxy vendor to modify their equipment to be more > > > flexible with > > > > > > > regards to policy. > > > > > > > > > > > > > > Can you clarify for me: > > > > > > > > > > > > > > If you have a Privacy header with either "session" or > > > > > "header" doe > > > > > > > this impact the H-I entries or will only a value of > > > > > > "history" impact > > > > > > > the H-I entries? > > > > > > > [MB] Yes, both "session" and "header" level privacy, > > > > > > consistent with > > > > > > > RFC 3323, mandate that entries be anonymized or > > > > dropped, with the > > > > > > > latter being the recommendation for "session" level > > > > > > privacy. RFC 4244 > > > > > > > mandated that they be dropped and 4244bis > > recommends they be > > > > > > > anonymized. The original intent for the value of "history" > > > > > > was for the > > > > > > > tagging of the individual entries, but you end up getting > > > > > > the header > > > > > > > level functionality as well. [/MB] > > > > > > > > > > > > > > If you have a Privacy header with a value of "none" and a > > > > > H-I entry > > > > > > > with Privacy header parameter with value "history" what is > > > > > > the privacy > > > > > > > of the individual H-I entry? > > > > > > > [MB] We did not explicitly address the "none" in RFC > > > > > 4244, but the > > > > > > > general statement is the privacy headers at the request > > > > > > level override > > > > > > > any at the hi-entry level. [/MB] > > > > > > > > > > > > > > From reading RFC4244 a Privacy header with value > > > "history" will > > > > > > > effectively make all H-I entries private and there is > > > > > currently no > > > > > > > option to include a H-I Privacy header parameter with > > > > > value "none". > > > > > > > [MB] Correct, per my comment above. [/MB] > > > > > > > > > > > > > > H-I at present allows the inclusion of Privacy header > > > > > parameters to > > > > > > > explicitly express privacy for an individual H-I entry > > > > > but a single > > > > > > > node which includes a header "Privacy: history" makes all > > > > > > H-I entries > > > > > > > private even if this is not the requirements for the > > > > specific URI. > > > > > > > [MB] Correct, but the only node that should add the header > > > > > > is a node > > > > > > > which is responsible for the domain associated with the > > > > > > Request URI in > > > > > > > the incoming request or is authorized to do so. [/MB] > > > > > > > > > > > > > > I will admit that having worked in a telephony environment > > > > > > for a long > > > > > > > time I am used to having privacy of identities set on a > > > > > per number > > > > > > > basis and the relative inflexibility of the IETF Privacy > > > > > header is > > > > > > > relatively restrictive as to specifying which > > > identities may be > > > > > > > presented and which not. > > > > > > > [MB] Yes, this is an entirely different paradigm. I > > > developed > > > > > > > telephony s/w for over a decade and this is entirely > > > > > different - it > > > > > > > provides a lot more flexibility, which makes things > > > > far, far less > > > > > > > deterministic than what you have in telephony switches > > > > where your > > > > > > > routing and translations are configured for the most part, > > > > > > with just a > > > > > > > few capabilities for controlling the privacy and it's a > > > > > > closed network. > > > > > > > > > > > > > > With RFC4244/4244bis, there MUST be a mechanism at the > > > > UAS or end > > > > > > > application that can handle a request that doesn't have the > > > > > > > appropriate information either because nodes didn't support > > > > > > > History-Info or some random node in the network applied > > > > > > privacy (which > > > > > > > I think is highly > > > > > > > unlikely) - this is normative per section 5 of RFC > > > > 4244. So, the > > > > > > > worst case scenario I see for this 800 service (which will > > > > > > get to the > > > > > > > right UAS but without the exact 800 number that was dialed) > > > > > > is that it > > > > > > > goes to a default ACD group/customer service agent, > > > > etc. who then > > > > > > > needs to gather the appropriate information and in my > > > > > > experience this > > > > > > > is often an IVR system these days. So, the service is not > > > > > > broken when > > > > > > > privacy is applied in an undesireable manner, it's just not > > > > > > optimal. > > > > > > > This is something that should be addressed in the > > > > > target-uri draft > > > > > > > which has all the details of how specific services use > > > > > History-Info. > > > > > > > One other thing to consider is that most networks that are > > > > > > emulating > > > > > > > telephony type features use B2BUAs, which follow the > > > > > > UAS/UAC rules for > > > > > > > the header rather than the proxy rules, noting that the > > > > > UAC can set > > > > > > > the Privacy header to whatever value it sees as appropriate > > > > > > for the request. > > > > > > > [/MB] > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Ian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > > Sent: 24 June 2009 15:48 > > > > > > > To: Ian Elz > > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > > Schubert; > > > > > > > sipcore@ietf.org; Francois Audet > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > > > I do not believe we should do the "override" behavior as I > > > > > > think that > > > > > > > violates RFC 3323, as the "history" is really a subset of > > > > > the cases > > > > > > > whereby a UAC or proxy would add "session" or "header" to > > > > > > the request. > > > > > > > And, the latter two cases have the same (undesireable) > > > > > > result. I agree > > > > > > > this impacts your services, but we can't mandate that > > > > > > proxies provide > > > > > > > information that might violate their local policies and > > > > indeed a > > > > > > > proxy's local policies can result in the information being > > > > > > anonymized > > > > > > > (or removed if they can't anonymize) even in the > > "none" case. > > > > > > > > > > > > > > I do believe it's reasonable that we strongly recommend > > > > that the > > > > > > > request level (versus specific hi-entries) not be used > > > > > and if it is > > > > > > > used, the consequence is that some services will > > not have the > > > > > > > information they need - this was the gist of my previous > > > > > > response (to > > > > > > > which I did not get any additional feedback). Now, we could > > > > > > add some text that the "none" > > > > > > > case SHOULD be used (e.g., added by first hop proxy) if it > > > > > > is desired > > > > > > > that the information not be subject to privacy > > > > > > restrictions. I do not > > > > > > > think it is then particularly useful to add logic around > > > > > the proxy > > > > > > > then being able to tag the entries within their domain as > > > > > > subject to privacy. > > > > > > > I think that conflicts with the intent of the request > > > > > level "none". > > > > > > > However, as I mention above, per the current text, a proxy > > > > > > can (based > > > > > > > on local policy) remove entries - so a proxy can capture > > > > > hi within > > > > > > > their domain and not forward any of that information to the > > > > > > next hop > > > > > > > in another domain - you already have that functionality. > > > > > > But, I think > > > > > > > this introduces the general problem that you might be > > > > > > impacting other > > > > > > > services further down the line, which I thought was the > > > > > problem you > > > > > > > were wanting to solve - not specifically your example > > > > > > service but, for > > > > > > > example, in the case that someone is debugging and they > > > > want the > > > > > > > entire history, so depending upon the service, this is also > > > > > > > undesirable behavior. > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Mary. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > > Sent: Wednesday, June 24, 2009 2:57 AM > > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > > Schubert; > > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > > > > > > > > Mary, > > > > > > > > > > > > > > [I have added the list to this thread for wider comment.] > > > > > > > > > > > > > > In the previous discussions I commented that in RFC4424 > > > > > > that a Privacy > > > > > > > header with value "history" effectively makes all H-I > > > > > > entries private > > > > > > > with the result that the H-I entries may be removed. > > > > > > > > > > > > > > There has now been a comprehensive discussion on > > > > > indication of the > > > > > > > initial 'target' to the final recipient for call handling > > > > > purposes. > > > > > > > > > > > > > > The main use case related to a freephone example where the > > > > > > answering > > > > > > > location may be a call centre where the original freephone > > > > > > number may > > > > > > > be required for correct call handling. > > > > > > > > > > > > > > If you now consider the following example (modified from > > > > > Francois' > > > > > > > text in the latest draft - excuse any errors that I may > > > > > > have inserted) > > > > > > > > > > > > > > INVITE sip:sip:+18001234567@example.com<sip%3Asip%3A%2B18001234567@example.com> > ;user=phone;p=x > > > > > > > Privacy: history > > > > > > > History-Info: > > > > > > > > > > > > > <sip:+18001234567@example.com <sip%3A%2B18001234567@example.com> > ;user=phone;p=x>;index=1;rt;aor > > > > > > (1) > > > > > > > History-Info: <sip:bob@biloxi.example.com<sip%3Abob@biloxi.example.com> > >;index=1.1;mp;aor > > > > > > > (2) > > > > > > > History-Info: <sip:bob@192.0.2.3 <sip%3Abob@192.0.2.3> > >;index=1.1.1;rc > > > > > > > (3) > > > > > > > > > > > > > > In this case due to the Privacy header all of the H-I > > > > entries are > > > > > > > considered private and the +18001234567 will not be > > > > > > delivered to the > > > > > > > final destination with the result that call handling may > > > > > > not be correct. > > > > > > > The Privacy header may have been inserted by any of the > > > > > nodes which > > > > > > > routed the message and inserted a H-I entry. > > > > > > > > > > > > > > If however the H-I was allowed to include a header > > > parameter of > > > > > > > "?Privacy=none" in the H-I entry and that an explicit > > > H-I entry > > > > > > > privacy value would be considered to have precedence over > > > > > a Privacy > > > > > > > header with a value of "history" then the mapping of the > > > > > > +18001234567 > > > > > > > could be explicitly specified as not private and may be > > > > passed on. > > > > > > > > > > > > > > Thus when the mapping from sip:+18001234567@example.com<sip%3A%2B18001234567@example.com>to > > > > > > > sip:bob@biloxi.example.com <sip%3Abob@biloxi.example.com> when > H-I entry (2) above is > > > > > > included could > > > > > > > also insert the Privacy header parameter in H-I entry (1). > > > > > > > > > > > > > > Thus the message would appear as follows: > > > > > > > > > > > > > > INVITE sip:sip:+18001234567@example.com<sip%3Asip%3A%2B18001234567@example.com>; > user=phone;p=x > > > > > > > Privacy: history > > > > > > > History-Info: > > > > > > > > > > > > > > > > > > > > > > > > > > > <sip:+18001234567@example.com?Privacy=none;user=phone;p=x>;index=1;rt; > > > > > > > ao > > > > > > > r > > > > > > > History-Info: <sip:bob@biloxi.example.com<sip%3Abob@biloxi.example.com> > >;index=1.1;mp;aor > > > > > > > History-Info: <sip:bob@192.0.2.3 <sip%3Abob@192.0.2.3> > >;index=1.1.1;rc > > > > > > > > > > > > > > This would result in all the H-I entries except (1) being > > > > > > considered > > > > > > > private with the result that the =1800... Number is > > > > > passed for call > > > > > > > handling purposes. > > > > > > > > > > > > > > This change is backward compatible with the existing > > > > > > implementation as > > > > > > > any node using the existing functionality as defined in > > > > > > RFC4244 will > > > > > > > continue to be supported. > > > > > > > > > > > > > > The alternative is to remove the ability to include the > > > > > > value "history" > > > > > > > in the Privacy header and only allow this value in the > > > > > > Privacy header > > > > > > > parameter. This alternative is not backward compatible. > > > > > > > > > > > > > > Without this change a single node in the message path which > > > > > > includes a > > > > > > > header "Privacy: history" will prevent delivery of the > > > > > aor and thus > > > > > > > prevent proper call handling. > > > > > > > > > > > > > > Ian Elz > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > > > > > Sent: 23 June 2009 19:40 > > > > > > > To: 'Mary Barnes'; Francois Audet; Hans Erik van > > > Elburg; Shida > > > > > > > Schubert > > > > > > > Cc: Ian Elz > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I include Ian, so he can comment to your resposne himself. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > > Sent: Tuesday, June 23, 2009 9:40 PM > > > > > > > To: Christer Holmberg; Francois Audet; Hans Erik van > > > > > Elburg; Shida > > > > > > > Schubert > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > Here was the thread of response and the last comment was > > > > > > from Ian that > > > > > > > he would consider the response: > > > > > > > > > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > > > > > > > > > > > > > And, there was not agreement on the "none" but rather to > > > > > > qualify the > > > > > > > SHOULD NOT forward. However, in the sipcore-4244bis-00, > > > > > > rather than > > > > > > > changing the text such that the headers SHOULD be > > removed, we > > > > > > > recommend that they be anonymized (in section 4.3.3.3.1). > > > > > That is > > > > > > > entirely consistent with RFC 3324 and thus we have > > > removed the > > > > > > > recommendations to remove the headers entirely. However, > > > > > > that changed > > > > > > > never got done in section 3.2, so we would need to > > > change this: > > > > > > > "Thus, the History- Info header > > > > > > > SHOULD NOT be included in Requests where the requestor > > > > > > has indicated > > > > > > > a priv-value of Session- or Header-level privacy." > > > > > > > > > > > > > > But, I'm really beginning to be of the mindset that we > > > > > should just > > > > > > > remove all the subsections of section 3 (i.e., leave the > > > > > > text in the > > > > > > > upper level section), so we don't have to keep > > worrying about > > > > > > > consistency. > > > > > > > > > > > > > > So, lets either fixt the text in 3.2 or remove altogether > > > > > > and then I > > > > > > > think we are really at the point of needing to submit this > > > > > > version so > > > > > > > folks that actually have an interest in it can review > > > > the updated > > > > > > > document. > > > > > > > > > > > > > > Mary. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > [mailto:christer.holmberg@ericsson.com] > > > > > > > Sent: Tuesday, June 23, 2009 1:10 PM > > > > > > > To: Barnes, Mary (RICH2:AR00); Audet, Francois > > > > > > (SC100:3055); Hans Erik > > > > > > > van Elburg; Shida Schubert > > > > > > > Subject: 4244bis and privacy > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Below is a comment/proposal which one of my collegues (Ian > > > > > > Elz) gave > > > > > > > on the list a while ago, when the first version of > > > 4244bis was > > > > > > > submitted, but was not incorporated. Do you think it would > > > > > > be useful? > > > > > > > > > > > > > > ------- > > > > > > > > > > > > > > While the HI approach to target may solve the problem of > > > > > > being able to > > > > > > > deliver the target URI to the final destination there is no > > > > > > guarantee > > > > > > > that it will actually be delivered. > > > > > > > > > > > > > > The problem arises with how Privacy is defined for HI. > > > > > > > > > > > > > > 4424 defines a new Privacy value "history" which may be > > > > placed in > > > > > > > either the Privacy header or as a header parameter to the > > > > > HI entry. > > > > > > > > > > > > > > If one node uses the former option "Privacy: history" then > > > > > > this will > > > > > > > make all headers private and will result in all HI > > > > entries being > > > > > > > removed or made anonymous when the message containing > > > the HI is > > > > > > > delivered to the user. > > > > > > > > > > > > > > There is a simple solution to this and that is to also > > > > > > allow the use > > > > > > > of the "none" Privacy value as a header parameter in the > > > > > HI entry. > > > > > > > This would explicitly state that no privacy is required > > > > to the HI > > > > > > > entry and this would override a "history" value in the > > > > > > Privacy header. > > > > > > > > > > > > > > I pointed this out to Mary when the 4424bis draft was first > > > > > > published > > > > > > > but the change has not been made in the latest draft. > > > > > > > > > > > > > > The change is backward compatible and would not cause an > > > > > issue with > > > > > > > any existing implementations. > > > > > > > > > > > > > > ------ > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > sipcore mailing list > > > > > > > sipcore@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > _______________________________________________ > > > > > > > sipcore mailing list > > > > > > > sipcore@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > _______________________________________________ > > > > > > sipcore mailing list > > > > > > sipcore@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > _______________________________________________ > > > > > sipcore mailing list > > > > > sipcore@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > >
- Re: [sipcore] 4244bis and privacy Ian Elz
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy Ian Elz
- Re: [sipcore] 4244bis and privacy Ian Elz
- Re: [sipcore] 4244bis and privacy Hans Erik van Elburg
- Re: [sipcore] 4244bis and privacy Francois Audet
- Re: [sipcore] 4244bis and privacy Hans Erik van Elburg
- Re: [sipcore] 4244bis and privacy Hans Erik van Elburg
- Re: [sipcore] 4244bis and privacy Francois Audet
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy R.Jesske
- Re: [sipcore] 4244bis and privacy Hans Erik van Elburg
- Re: [sipcore] 4244bis and privacy R.Jesske
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy R.Jesske
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy Elwell, John
- Re: [sipcore] 4244bis and privacy Ian Elz
- Re: [sipcore] 4244bis and privacy Francois Audet
- Re: [sipcore] 4244bis and privacy Ian Elz
- Re: [sipcore] 4244bis and privacy Francois Audet
- Re: [sipcore] 4244bis and privacy Elwell, John
- Re: [sipcore] 4244bis and privacy Francois Audet
- Re: [sipcore] 4244bis and privacy Francois Audet
- Re: [sipcore] 4244bis and privacy Hans Erik van Elburg
- Re: [sipcore] 4244bis and privacy Ian Elz